The IP over ATM Mailing List Archive by date

[Curtis Villamizar <curtis@ans.net>]

In message <96013017364109@engr05.comsys.rockwell.com>, Albert E. Manfredi writ
es:
> > 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.

Yes it would.  You cannot run a routing protocol over a huge bridged
LAN, even a bridged ethernet beyond some relatively small size.
Without the routing protocol you can form loops.  This is well
accepted.  (See my previous response).

> 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.

Creating small LIS makes running a routing protocol feasible which is
required to keep loops with the outside world from forming.

> > 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?

You can do shortest path out of a low speed media and find the best
path through the fast media in the reverse direction that will make
the route symetric (or closer to symetric) using a variety of methods
including BGP MED, shortest BGP AS path, configured BGP local-pref,
BGP DPA.  All of these require you to run a routing protocol within
the faster media and therefore break up your flatnet into smaller LIS.

It might help if you understood IP inter-AS routing.  Try reading the
following RFCs for starters:

1520  I    Y. Rekhter, C. Topolcic, "Exchanging Routing Information Across
           Provider Boundaries in the CIDR Environment", 09/24/1993.
           (Pages=9) (Format=.txt)

1519  PS   V. Fuller, T. Li, J. Yu, K. Varadhan, "Classless Inter-Domain
           Routing (CIDR): an Address Assignment and Aggregation Strategy",
           09/24/1993. (Pages=24) (Format=.txt) (Obsoletes RFC1338)

1518  PS   Y. Rekhter, T. Li, "An Architecture for IP Address Allocation with
           CIDR", 09/24/1993. (Pages=27) (Format=.txt)

1517  PS   R. Hinden, "Applicability Statement for the Implementation of
           Classless Inter-Domain Routing (CIDR)", 09/24/1993. (Pages=4)
           (Format=.txt)

1774  I    P. Traina, "BGP-4 Protocol Analysis", 03/21/1995. (Pages=10)
           (Format=.txt)

1773  I    P. Traina, "Experience with the BGP-4 protocol", 03/21/1995.
           (Pages=9) (Format=.txt) (Obsoletes RFC1656)

1772  DS   Y. Rekhter, P. Gross, "Application of the Border Gateway Protocol
           in the Internet", 03/21/1995. (Pages=19) (Format=.txt)
           (Obsoletes  RFC1655)

1771  DS   Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)",
           03/21/1995. (Pages=57) (Format=.txt) (Obsoletes RFC1654)

Also take a look at:

1745  PS   K. Varadhan, S. Hares, Y. Rekhter, "BGP4/IDRP for IP---OSPF
           Interaction", 12/27/1994. (Pages=19) (Format=.txt)

1583  DS   J. Moy, "OSPF Version 2", 03/23/1994. (Pages=212)
           (Format=.txt, .ps) (Obsoletes RFC1247)

After you gain familiarity with the protocols, you can read the NANOG
and/or mailing list archives for a better idea of how they are applied
and what issues arise.

> > 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.

It starts in KC and expands to NY and SF.  It now connects in three
places and you take the shortest path out in NY and have to pay
someone for transit to get across the country to a provider that is
only peering in SF.  That's reality.

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

It's infeasible without routing loops so yau can stop waving your arms.

> > 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.

OK.  You don't see the issue.  We have measured 7,800 unique
destinations in a 90 second interval at about 12 Mb/s.  If increasing
to 120 Mb/s gives you 78,000 unique destinations, you may have more
VCs than you have in the 16 bit VCI space.

> > 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.

On top of the other issues mentioned here, you've got some details to
fill in.  VPs also lose QoS multiplexing gains.

> 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.

Nor will "such fast rates" be adequate.  Flows are typically well
under 100 packets on average with packet size averaging around 200
bytes on the Internet.  At 1/2 T3, pps rates are over 10kpps each
direction which is over 100 flow setups per second.  This has been
discussed on this list already.

Since the idea of setting up short-lived SVCs for DNS or web browsing
doesn't particularly bother you, it would appear that you are simply
unaware of issues already discussed on this list.

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

It is clear you are not familiar with issues discussed on this list
over the past two or three years.  You might want to read the IP over
ATM framework document and/or review the mail archives.  As I pointed
out above, understanding IP routing and the issues that arise in
practice before making comments or proposals concerning routing in a
very large scale network would also help.

Curtis