The IP over ATM Mailing List Archive by date

[manfredi@engr05.comsys.rockwell.com (Albert E. Manfredi)]

> From:	curtis@ans.net    30-JAN-1996 13:52
> 
> To summarize your proposal: The ATM flatnet is then using "shortest
> path out" routing and essentially using default routing as well.  The
> other media is also doing "shortest path out" to the ATM flatnet LIS.
> There is no transit of non-ATM across ATM flatnets, but there can be
> transit across non-ATM media to reach disjoint ATM flatnets.

Sorry for the previous, uh, abortion.

Good summary. Except that the avoidance of transit traffic was not an 
absolute requirement but rather a simplifying assumption to show that 
huge IP flatnets can work: what's flat to IP need not be flat to ATM. If 
we were talking a MAC LAN, such as a huge Ethernet, this would not be the 
case.

With elaboration, transit traffic can be added in. Of course, then you 
have to worry about loops and all the rest. But creating small LISs in the 
ATM flatnet would not help in that regard.

> If there is significant traffic between the ATM flatnet and the other
> media and the traffic is near symetric (approximately equal amount of
> traffic in both directions), then there needs to be equal bandwidth
> for this on the other media as there is on the ATM media.  There is
> also no hope to transit the ATM flatnet.

I don't think this is different from any network, is it?

> Now lets look at transition.
> 
> This would mean that initially a provider hoping to become a player in
> the Internet market in some portion of the world) would have to either
> build two infrastructures, one ATM, and one not using ATM, or pay
> other providers for transit.

Actually, I had in mind a different scenario. I was thinking of the small, 
isolated RFC-1577 IP-ATM LAN growing. It starts in an office in Kansas 
City and it expands out. The existing IP net is already there. So the 
question is, "How far can this growing ATM net with IP on it expand?" And 
the answer is, "Go for it." On that same "IP net," assuming you use ATM 
management tools, you can add a huge number of IP-ATM hosts without being 
forced to create many small LISs. The small local nets would be organized, 
for instance, by exchange number.

Yes, as you say, adding transit traffic would make this more appealing. 
But less easy to show how ATM can support large IP flatnets.

> ps- Even if you do have the capital, you still haven't addressed the
> issue of how the limited VC space problem gets solved for a large ATM
> flatnet (which would presumably make host to host connections that get
> concentrated into OC12 and OC48 or higher).

Sorry, but in a large interconnected mesh, with the appropriate public NNI 
protocols, I just don't see this "VC space problem." I'm certainly not 
thinking that a public (or very large) ATM net would be limited to OC-3 or 
OC-12 switches. And I also don't think we can make reasonable use of ATM 
by dedicating VCs to any one path for very long periods of time.

> You also haven't solved
> the problem of connection setup overhead for all these very short
> lived host to host connections (DNS packets, short lived WWW flows,
> etc).  Carving small VPs either destroys QoS capability or brings back
> the inefficiency of TDM by fixing the VP bandwidth allocations and
> rate shaping the VPs.

Interesting details that must be worked out. A couple of thoughts that 
might be relevant:

I'm thinking that VPs would correlate with pre-established SONET pipes 
through this network. They would be stable and would be of various 
different bandwidths.

I agree that something has to be done to Q.2931 to make SVC setup as 
efficient as possible. The virtual channels we set up in the hardware
I've been dealing with for several years, hardware we designed and
build for the USN, take 10s to low 100s of microseconds to set up, and
are torn down if there's no traffic for 10s of microseconds. I've
resigned myself that such fast rates won't be possible over ATM, in
part because we're talking much larger distances than what I'm
involved with now, but the idea of setting up short-lived SVCs for DNS
or web browsing doesn't particularly bother me yet.

Bert
manfredi@engr05.comsys.rockwell.com