The IP over ATM Mailing List Archive by date[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Example of large IP flatnet
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 |
|