The IP over ATM Mailing List Archive by date

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



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

Example of large IP flatnet

  • From: Paul Ferguson <pferguso@cisco.com>
  • Date: Mon, 29 Jan 1996 13:51:42 -0500
  • Cc: ip-atm@matmos.hpl.hp.com

I would concur with Albert -- with reinforced caveats, and only to a 
certain extent.

The two major caveats that immediately spring to mind is that
advertisement of the IP-ATM flatnet must be classless and would 
ideally appear externally as a single prefix [cidr supernet], and 
that it should not be a transit network.

Some of my reasoning for this is personal sentiment. For example, as a 
major Internet backbone provider, I could care less what the internal
mechanics of your [downstream] network look like, only that it is
a prefix [or less than ideally, a set of prefixes] which is available
via a specifc peer or gateway.

Conversely, from within the IP-ATM flatnet, a single default route
could exist which routes all traffic not contained in local routing
tables to the upstream provider.

If multihomed, this is another issue altogether.

The viability of a huge IP-ATM flatnet relies on the existence of
dynamic routing protocols within the IP-ATM fabric. If it is indeed
*flat* then it simply becomes an issue of scaling and performance.
I do not honestly believe that enough research and testing has
been done in this regard to quantify discussion, at least on my part.

I would enjoy the discussion nonetheless.   :-)

- paul


At 12:32 PM 1/29/96 -0500, Albert E. Manfredi wrote:

>If we start with the existing interconnected Internet, is it difficult to 
>add a huge, ATM-based IP flatnet to the Internet? I wouldn't think so, 
>unless we worry about efficient routing _through_ this flatnet.
>
>PREMISES
>
>The premise here is that the legacy IP nets are all interconnected via 
>current means (dedicated lines and routers). The IP-ATM flatnet (flat with 
>respect to IP only) is connected to the legacy Internet via any number of 
>routers at the edge. These edge routers, to keep things simple, do _not_ 
>advertize connectivity to other IP nets; only to the one huge flatnet.
>Also, each ATM host and edge router is configured with the ATM address of
>its DNS and ARP server.
>
>INBOUND TRAFFIC
>
>IP datagrams from legacy Internet networks destined to the IP-ATM flatnet
>find their way to the closest router connecting to the ATM medium, using 
>normal routing algorithms. The closest _edge router_, not necessarily the 
>shortest path to the destination host.
>
>The edge router queries its ARP server to find the ATM address of this 
>IP-ATM destination host. (These ARP servers must periodically transmit 
>their ARP tables to the other ARP servers and must cache the ARP tables 
>for this IP flatnet.)
>
>Then the IP datagrams are routed to the ATM destination efficiently by
>the PNNI or public NNI.
>
>OUTBOUND TRAFFIC
>
>The ATM network has to provide a DNS and ARP-like service.
>
>If an ATM host wants to open a session with another ATM host on the same 
>IP flatnet, the DNS will provide the ATM address of that other ATM host.
>The NNI takes care of routing.
>
>If an ATM host wants to communicate with a legacy IP host, the ATM-DNS
>query results in the ATM address of one (or more, for reliability) router 
>which is, for simplicity, the closest to that DNS server.
>
>Note that this DNS server can easily provide the minimal ARP function 
>required of it. Edge routers are not expected to change very often, and 
>each server only worries about one or very few edge routers. Also note 
>that I didn't make an unamiguous distinction between DNS server and ARP 
>server.
>
>TRAFFIC TO OTHER IP-ATM NETS
>
>An IP-ATM net which is not connected to this flatnet looks like a legacy 
>IP net to these ATM hosts and servers. If this other IP-ATM net _is_ 
>connected to the huge flatnet, then it can simply become part of the same 
>IP flatnet.
>
>THROUGH TRAFFIC
>
>Since the ATM edge routers do not advertize routes to other IP nets, in 
>this simplest implementation there is no through traffic. This simplest 
>scheme can be elaborated on, of course, to allow through traffic. The ATM 
>edge routers could communicate IP net reachability information among one 
>another, even if the ATM address of each of the other edge routers must be 
>statically configured.
>
>Just wanted to show that if we don't worry too much about routing
>algorithms to make Mssrs. Ford and Fulkerson proud, we can, I believe,
>build a huge and viable IP flatnet over ATM.
>
>Bert
>manfredi@engr05.comsys.rockwell.com
>

--
Paul Ferguson                                           ||        ||
Consulting Engineering                                  ||        ||
Reston, Virginia   USA                                 ||||      ||||
tel: +1.703.716.9538                               ..:||||||:..:||||||:..
e-mail: pferguso@cisco.com                         c i s c o S y s t e m s