The IP over ATM Mailing List Archive by date

[Curtis Villamizar <curtis@ans.net>]

In message <96012620180347@engr05.comsys.rockwell.com>, Albert E. Manfredi writ
es:
> > From:	curtis@ans.net    26-JAN-1996 19:42
> > > > From:	asmith@baynetworks.com    25-JAN-1996 23:28
> > > > 
> > > > If you have such a deployment scenario then there is really no need for
> > > > an internetwork layer any more - you don't really need IP or LISs at al
> l,
> > > > let alone 1577 and ATMARP! Roll on TULIP and TUNIC ...
> > > 
> > > Exactly. Need for internetwork remains for compatibility with legacy, 
> > > non-ATM IP nets.
> > 
> > I think there was some sarcasm in the statement that you missed.  ;-)
> 
> Naw, not really. I didn't think it needed to be a sarcastic comment, 
> though.
> 
> > The need for internetworking only remains if you are willing to be an
> > island unconnected to the rest of the world or are willing to have a
> > static default route to the rest of the world.
> 
> In a sense, this is a detail. Use the premise that 90 percent of the 
> world is IP over ATM and the static routes between legacy IP-over-MAC 
> systems and their router to the world is not such a big deal. I'm simply 
> showing that a flat IP network for a huge number of hosts is not 
> inconceivable AS LONG AS that huge network is IP over ATM, and as long as 
> the remaining old style LANs are a small minority. (I'm not saying it
> will happen anytime soon or at all, but I'm proposing that it's perfectly
> conceivable to have very large LISs _en principe_.)

This has been discussed a great deal in this WG, but not for quite a
while.  This is thought to be so unrealistic that the few advocates
finally just let the argument rest.  (See below for some examples).

> > > I'm not sure I follow. You don't need to set up circuits at 8 AM for the 
> > > rest of the day, just as you don't need to dial up all your business 
> > > contacts at 8 AM and keep those lines open all day long.
> > 
> > The first issue is the size of VCI space.  We long ago (May 1994 I
> > think) measured 7,800 unique destination hosts on a 90 second IP
> > sampling on one spot on the Internet (at just about 12 Mb/s.  A factor
> > of 10 and there goes VCI space.  I haven't seen any idea on how to use
> > VPI space to make up for it.
> 
> Should this be a hard problem to solve? Do these 7800 destinations in 90 
> seconds each require a long-term VC? Would the "one spot in the Internet" 
> still be "one spot" if the backbone were ATM, or would the calls be routed 
> differently?

You just stated that 90% of the Internet was directly ATM connected
and even brought up TULIP and TUNIC which would require 1 VC per TCP
connection or UDP port pair.

The 7800 unique destination hosts (not src/dst pairs or port pairs)
measurement was taken on a light to moderately loaded DS3 link
supporting about 12 Mb/s on average, not a major traffic exchange.
Are you suggesting the ATM routing would be arranged so as not to
exceed 120 Mb/s on any link (to keep the number of VC below 2^16)?

> > The second issue is VC establishment time.  I think 8AM here was just
> > a guess at when peak time might be (chance are it would be later in
> > the day, but that's irrelevant).  Currently routers run in the 10s of
> > kpps per interface per direction or up to 100-200 kpps per box.
> > Estimates of flow duration (even when measured in terms of host pairs
> > that don't go idle more than 60 seconds) are well under 100 packets.
> > That would put current VC connect rate in the range already
> > approaching 1000 new VC per second.  Connection load could easily be
> > an issue.
> 
> Again, I don't think one can automatically assume that choke points 
> created by the current router/dedicated link topology would exist in a 
> large ATM mesh. The traffic would be routed differently, as it is for 
> telephone calls.

As I mentioned, this would require VP routing.  Do you know of any
proposals to do VP routing?  How is QoS supported within the VP?  This
has also been discussed.

> > > It is entirely conceivable, for the sake of argument, to have 90 percent 
> > > of all IP users in the world riding on a single IP "network," all over 
> > > ATM. The remaining 10 percent, over their little Ethernets, would have to
>  
> > > use different IP "networks" to be routable. Such a scheme would work 
> > > because ATM can provide all the management and routing needed using its 
> > > own mechanisms.
> > 
> > It just might work if all the connected networks were stubs, single
> > homed to the ATM network.  That is if the VC issues can be solved.
> 
> Right. Or even n-homed as long as n is small. 

Wrong.  If N > 1 loops can form.

> > The big flat ATM LIS is infeasible.  This has come up many times on
> > this list.  If you don't think so you are welcome to try to build one.
> 
> It would be quite easy to build one if ATM in the WAN were ubiquitous. I 
> mean, a public ATM in the WAN. Routing to/from legacy systems, I believe, 
> becomes difficult when both legacy IP nets and ATM nets are big. If one or 
> the other is small and isolated, then static routes would work fine.
> 
> Basically, small ATM LISs solve the problem of having packets from
> legacy IP nets routed efficiently between the old net and the ATM host. 
> But if we can accept circuitous paths to/from those legacy nets, it's not 
> such a big problem, is it? (As it is, my IP stuff has to cross the country 
> anyway, no matter where its destined, even though there's not a whiff of
> ATM on our enterprise net.)

Please read draft-ietf-ipatm-framework-doc-06.  Pay particular
attention to the example in Figure 4 (pick up the postscript version).
Yes it is a problem.  Routing loops could form.  If you had ubiquitous
ATM in the entire North American continent and Europe the rest of the
world would have to be single homed.  Would you like to tell Japan
they can't connect to Hawaii or the west coast because Israel already
connected to Europe or that if they really wanted to do that they
would have to break all connections between the Pacific Rim and India
and route the stuff around the world the long way so they would remain
single homed to the ATM network?  Which way should Japan point
default, East or West?  (Japan is just a example).

Routing would be needed.  Routing over an enormous LIS doesn't scale.
Other proposals over the enormous LIS form loops if used without
routing.  I think that is sufficient problem.

Instant global ATM has already discussed by this WG and the deployment
was seen as ... er ... more than somewhat problematic.  ;-)

> Bert
> manfredi@engr05.comsys.rockwell.com

These issues have been brought up before.  There are sound reasons
that this WG is going in the current direction.  The IP over ATM
Framework draft, draft-ietf-ipatm-framework-doc-06 makes an attempt
was made to highlight some of the past discussion so we don't have to
repeat it on the list too many times.  That draft is in IESG last call
and is expected to be advancing to Informational as soon as some some
wording wrt NHRP is finalized.

Curtis