Cell Relay Archive

[rcallon@alpo.casc.com (Ross Callon)]

> >>>	1. similarities between tag switching and i-pnni which is a
> >>>	   very atm-focused protocol.
> >>
> >>There a *couple* of similarities, but overall, they are quite
> >>different.
> >
> >could you be a bit more specific?  for instance, is tag switching *not*
> >based upon the notion of a router-centric peer group as described in the
> >i-pnni document?  if so, maybe a discussion of the differences could be
> >made using that as a base.
> 
> Architecturally, I-PNNI, Tag Switching, ARIS, Ipsilon, CRS etc are all
> similar in that they are all examples of peer models, in which the same
> routing protocol is used both within the switched (e.g. ATM) and external
> (e.g. router) networks (as opposed to the current overlay model, where
> P-NNI/IISP runs within the ATM network, and external protocols like OSPF run
> transparently over and across the ATM network).  Now, having said that, they
> are also very different in detail.  In particular, I-PNNI intends running
> the ATM routing protocol (P-NNI) on packet routers, whereas tag switching
> (and all the other schemes listed above), intend using packet oriented
> routing protocols (eg. OSPF, BGP) on switches (e.g. ATM switches), as
> opposed to using switch specific routing protocols like P-NNI.  
> 
> ...Since the chief architect and
> proponent of I-PNNI is a member of the tagswitch alias, perhaps he could add
> more detail, if he so chooses. :-)

Anthony would appear to be referring to me in the sentence above ;-).
I half agree with Anthony and half disagree (but only in sort of 
"value judgement" ways). 

I think that the similarities are pretty large. OSPF and PNNI
(and by implication I-PNNI) are all link state routing protocols.
Both allow at least two levels of hierarchy (and I think it will
be a while before anyone uses more than two levels with PNNI). 
By the time that you add connection support and QoS routing 
capabilities to OSPF, and also add signalling support, you are 
at least a good part of the way to re-inventing PNNI. Also, tag
switching does not imply use of any one particular routing protocol, 
and I don't see any reason why it couldn't be used with I-PNNI just 
as well as with OSPF and BGP. 

I disagree that PNNI is in some sense fundamentally connection 
oriented. There are ***some parts*** of PNNI which are fundamentally
connection oriented (such as the signalling protocol). However, the
routing / topology determination part can be used with either 
connectionless or connection oriented protocols.

In terms of what the differences are: A big advantage of using 
OSPF as the routing protocol (which is allowed by both Tag switching
and by Cascade's current IP Navigator product), as Anthony mentioned,
is backward compatibility with existing routers. This also implies
a very stable software base (people tend to forget how long it takes
to get routing protocol specifications and software to be sufficiently
bug free). One advantage of I-PNNI is that if you have an environment
in which you want to offer both native ATM and IP service over the 
same ATM infrastructure, plus full routing support for the full 
generality of the ATM UNI signalling stuff, then I-PNNI can handle 
this. Another difference (I won't speculate on which way this helps) 
is that I-PNNI assumes that ATM switches use standard ATM signalling 
(PNNI signalling is an extension of UNI signalling), whereas tag 
switching and IP navigator can make use of a simpler signalling 
protocol. The tag switching standard is not done yet, of course, but 
in principle this also allows for multipoint-to-point (VC merging) 
which is a big scaling advantage (IP Navigator offers this). I-PNNI 
will (probably, the standard is not done yet) allow advertisement of 
existing VCs, thereby allowing routing to work over O(n) VCs (ie, an 
incomplete mesh of VCs) in cases where it is not feasible to set up 
a full n-squared mesh. 

Finally, there are two big similarities between tag switching and
I-PNNI: (i) Both are intended to be open multi-vendor standards. This
is a good thing; (ii) Neither of the standards are done yet. 

I would suggest that it is generally a futile effort to try to 
compare standards which are not done **for the purpose of figuring
out which is better**. Rather, the IETF is most successful when it 
forgets about "my protocol is better than your protocol" mud fights, 
and instead works out the standards in detail. The presence of two 
pretty similar (though not identical) efforts will tend to make both 
better. To the extent that we can adopt good ideas back and forth 
between the two efforts, we will be better off. I intend to be 
working constructively on both efforts over the next year or so, 
and think that the interplay between the two will help make both 
standards better.

> ...  Both will have roles in real networks, hence the
> reason why our drafts (and scope) require that both be allowed to be
> supported concurrently in ATM networks.
> 
> Anthony

Here we agree. I think that we will see all of MISR and PNNI and 
I-PNNI deployed in some networks. In some cases we may see PNNI 
and MISR based on OSPF working at the same time in the same 
network (PNNI to support ATM, and MISR/OSPF to support IP, in 
"ships in the night" mode). In the same sense, we current see all 
of OSPF, RIP, IGRP, and I.IS-IS deployed in networks today 
(I.IS-IS seems "quiet" to the casual observer, but there is a 
reasonable amount of it actually in use today -- the rest are all 
obviously in common use). 

The good news is the commitment to work together to make fully 
open standards, plus the willingness to borrow good ideas wherever
they come from. 

Ross