The IP over ATM Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1996-Jan> msg00272



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Example of large IP flatnet

  • From: Curtis Villamizar <curtis@ans.net>
  • Date: Tue, 30 Jan 1996 19:24:40 -0500
  • Cc: ip-atm@matmos.hpl.hp.com, rcoltun@fore.com


In message <96012914502202@engr05.comsys.rockwell.com>, Albert E. Manfredi writ
es:
> 
> What I was trying to show, though, is that the IP prefix is not necessary
> for routing messages within an ATM framework. The IP prefix would be used 
> for routing outside datagrams _to_ the ATM periphery, and then the prefix 
> becomes just overhead. Unless we have no faith in the NNI, the IP prefix
> is unnecessary within the ATM medium. What I find interesting is that ATM
> _can_ provide, all by itself, the mechanisms for routing traffic over very 
> large areas, so that to an IP user this would look like a gargantuan 
> flatnet. Further, if we allow ourselves some routing inefficiencies (not 
> loops, mind you, but the possibility of longer data paths than perfect 
> routing might create), this IP-ATM net can also be interconnected with the
> normal Internet.
> 
> My faith in the NNI, especially a public NNI, comes from the fact that the 
> global telephone system works remarkably well with an enormous number of 
> subscribers. Much greater than the number of Internet hosts, so far at 
> least. Now, one could certainly protest here, pointing out that the 
> telephone routing of today doesn't have to worry about multiple QoS levels 
> and the like. Agreed, but then again IP routing doesn't either.

Your faith may be miguided.  The telephone network is not operating as
a result of NNI working, in fact NNI has nothing to do with the
current almost entirely TDM based telephone network.  Penetration of
voice over ATM is almost nill.  Most of the telephone netowrk relies
primarily on a form of static routing known to the telco industry as
provisioning of trunk circuits.  For the most part, this is extremely
static, using fiber multiplexors, to multiplex up DS3, OC3, OC12, and
OC48, usually in stages.  Below that, DS1 circuits are multiplexed
onto DS3 by M13 multiplexors, and below that channel banks multiplex
DS0 into DS1.  At small COs, the switch just figures out if the call
is local to the switch, or local and if so puts it on a trunk group to
a nearby switch, or figures out which IEC you've picked and puts it on
a trunk group to that IXC, no ATM NNI.  SS7 no doubt is used to launch
a query that returns the "treatment" of your call, specifically, which
trunk groups head toward your IXC.  At the IXC, a similar process
happens where your call finds its way onto a trunk group based on the
area code, until it becomes local and eventually finds a trunk headed
toward the destination CO and then finally the right line card.

All this does involve SS7 and more recently involves AIN, particularly
for newer services like 800 and 900 and 911 and services that start
with "*", and so on.  I don't think anything resembling ATM NNI is
involved when a call finds its way to a trunk within this frameowrk
and then finds it's way to another switch.  There is certainly no LS
routing protocol like PNNI.

This very static routing and TDM is extremely wasteful of bandwidth.
Therefore the motivation for ATM.  Of course, if you just use VPs to
multiplex as is done for TDM, you lose a major part of the
multiplexing bandwidth gains.  If you don't make use of VPs, you run
out of VCI space very quickly.  Therefore the motivation for doing at
least data using IP over ATM.  If RSVP and gigabit routers become a
reality it may make sense to do voice over IP too.  You aren't the
first person to ask "so why do we need ATM"?  For many people, the
answer is simply "we don't".  For others the answer is "for better or
worse, that's what the carriers intend to sell us so we have to figure
out how to make effective use of it" (you'll find me in that camp).
And then there are also the true believers in ATM.

I don't think there is any form of existance proof for ATM NNI, but
I'd certainly be open hearing any word of such.  I think PNNI is still
being drafted by the ATMF, although interoperability testing has
occurred.  Last I heard PNNI doesn't have strong support from the
carriers for the idea of putting PNNI in a PDN.

Curtis

ps- Please feel free to correct me if my account of the state of
telephony is seriously flawed.