diff options
Diffstat (limited to 'doc/rfc/rfc1932.txt')
| -rw-r--r-- | doc/rfc/rfc1932.txt | 1739 |
1 files changed, 1739 insertions, 0 deletions
diff --git a/doc/rfc/rfc1932.txt b/doc/rfc/rfc1932.txt new file mode 100644 index 0000000..9b15ee6 --- /dev/null +++ b/doc/rfc/rfc1932.txt @@ -0,0 +1,1739 @@ + + + + + + +Network Working Group R. Cole +Request for Comments: 1932 D. Shur +Category: Informational AT&T Bell Laboratories + C. Villamizar + ANS + April 1996 + + + IP over ATM: A Framework Document + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + + Abstract + + The discussions of the IP over ATM working group over the last + several years have produced a diverse set of proposals, some of which + are no longer under active consideration. A categorization is + provided for the purpose of focusing discussion on the various + proposals for IP over ATM deemed of primary interest by the IP over + ATM working group. The intent of this framework is to help clarify + the differences between proposals and identify common features in + order to promote convergence to a smaller and more mutually + compatible set of standards. In summary, it is hoped that this + document, in classifying ATM approaches and issues will help to focus + the IP over ATM working group's direction. + +1. Introduction + + The IP over ATM Working Group of the Internet Engineering Task Force + (IETF) is chartered to develop standards for routing and forwarding + IP packets over ATM sub-networks. This document provides a + classification/taxonomy of IP over ATM options and issues and then + describes various proposals in these terms. + + The remainder of this memorandum is organized as follows: + + o Section 2 defines several terms relating to networking and + internetworking. + + o Section 3 discusses the parameters for a taxonomy of the + different ATM models under discussion. + + o Section 4 discusses the options for low level encapsulation. + + + + +Cole, Shur & Villamizar Informational [Page 1] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + + o Section 5 discusses tradeoffs between connection oriented and + connectionless approaches. + + o Section 6 discusses the various means of providing direct + connections across IP subnet boundaries. + + o Section 7 discusses the proposal to extend IP routing to better + accommodate direct connections across IP subnet boundaries. + + o Section 8 identifies several prominent IP over ATM proposals that + have been discussed within the IP over ATM Working Group and + their relationship to the framework described in this document. + + o Section 9 addresses the relationship between the documents + developed in the IP over ATM and related working groups and the + various models discussed. + +2. Definitions and Terminology + + We define several terms: + + A Host or End System: A host delivers/receives IP packets to/from + other systems, but does not relay IP packets. + + A Router or Intermediate System: A router delivers/receives IP + packets to/from other systems, and relays IP packets among + systems. + + IP Subnet: In an IP subnet, all members of the subnet are able to + transmit packets to all other members of the subnet directly, + without forwarding by intermediate entities. No two subnet + members are considered closer in the IP topology than any other. + From an IP routing and IP forwarding standpoint a subnet is + atomic, though there may be repeaters, hubs, bridges, or switches + between the physical interfaces of subnet members. + + Bridged IP Subnet: A bridged IP subnet is one in which two or + more physically disjoint media are made to appear as a single IP + subnet. There are two basic types of bridging, media access + control (MAC) level, and proxy ARP (see section 6). + + A Broadcast Subnet: A broadcast network supports an arbitrary + number of hosts and routers and additionally is capable of + transmitting a single IP packet to all of these systems. + + A Multicast Capable Subnet: A multicast capable subnet supports + a facility to send a packet which reaches a subset of the + destinations on the subnet. Multicast setup may be sender + + + +Cole, Shur & Villamizar Informational [Page 2] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + + initiated, or leaf initiated. ATM UNI 3.0 [4] and UNI 3.1 + support only sender initiated while IP supports leaf initiated + join. UNI 4.0 will support leaf initiated join. + + A Non-Broadcast Multiple Access (NBMA) Subnet: An NBMA supports + an arbitrary number of hosts and routers but does not + natively support a convenient multi-destination connectionless + transmission facility, as does a broadcast or multicast capable + subnetwork. + + An End-to-End path: An end-to-end path consists of two hosts which + can communicate with one another over an arbitrary number of + routers and subnets. + + An internetwork: An internetwork (small "i") is the concatenation + of networks, often of various different media and lower level + encapsulations, to form an integrated larger network supporting + communication between any of the hosts on any of the component + networks. The Internet (big "I") is a specific well known + global concatenation of (over 40,000 at the time of writing) + component networks. + + IP forwarding: IP forwarding is the process of receiving a packet + and using a very low overhead decision process determining how + to handle the packet. The packet may be delivered locally + (for example, management traffic) or forwarded externally. For + traffic that is forwarded externally, the IP forwarding process + also determines which interface the packet should be sent out on, + and if necessary, either removes one media layer encapsulation + and replaces it with another, or modifies certain fields in the + media layer encapsulation. + + IP routing: IP routing is the exchange of information that takes + place in order to have available the information necessary to + make a correct IP forwarding decision. + + IP address resolution: A quasi-static mapping exists between IP + address on the local IP subnet and media address on the local + subnet. This mapping is known as IP address resolution. + An address resolution protocol (ARP) is a protocol supporting + address resolution. + + In order to support end-to-end connectivity, two techniques are used. + One involves allowing direct connectivity across classic IP subnet + boundaries supported by certain NBMA media, which includes ATM. The + other involves IP routing and IP forwarding. In essence, the former + technique is extending IP address resolution beyond the boundaries of + the IP subnet, while the latter is interconnecting IP subnets. + + + +Cole, Shur & Villamizar Informational [Page 3] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + + Large internetworks, and in particular the Internet, are unlikely to + be composed of a single media, or a star topology, with a single + media at the center. Within a large network supporting a common + media, typically any large NBMA such as ATM, IP routing and IP + forwarding must always be accommodated if the internetwork is larger + than the NBMA, particularly if there are multiple points of + interconnection with the NBMA and/or redundant, diverse + interconnections. + + Routing information exchange in a very large internetwork can be + quite dynamic due to the high probability that some network elements + are changing state. The address resolution space consumption and + resource consumption due to state change, or maintenance of state + information is rarely a problem in classic IP subnets. It can become + a problem in large bridged networks or in proposals that attempt to + extend address resolution beyond the IP subnet. Scaling properties + of address resolution and routing proposals, with respect to state + information and state change, must be considered. + +3. Parameters Common to IP Over ATM Proposals + + In some discussion of IP over ATM distinctions have made between + local area networks (LANs), and wide area networks (WANs) that do not + necessarily hold. The distinction between a LAN, MAN and WAN is a + matter of geographic dispersion. Geographic dispersion affects + performance due to increased propagation delay. + + LANs are used for network interconnections at the the major Internet + traffic interconnect sites. Such LANs have multiple administrative + authorities, currently exclusively support routers providing transit + to multihomed internets, currently rely on PVCs and static address + resolution, and rely heavily on IP routing. Such a configuration + differs from the typical LANs used to interconnect computers in + corporate or campus environments, and emphasizes the point that prior + characterization of LANs do not necessarily hold. Similarly, WANs + such as those under consideration by numerous large IP providers, do + not conform to prior characterizations of ATM WANs in that they have + a single administrative authority and a small number of nodes + aggregating large flows of traffic onto single PVCs and rely on IP + routers to avoid forming congestion bottlenecks within ATM. + + The following characteristics of the IP over ATM internetwork may be + independent of geographic dispersion (LAN, MAN, or WAN). + + o The size of the IP over ATM internetwork (number of nodes). + + o The size of ATM IP subnets (LIS) in the ATM Internetwork. + + + + +Cole, Shur & Villamizar Informational [Page 4] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + + o Single IP subnet vs multiple IP subnet ATM internetworks. + + o Single or multiple administrative authority. + + o Presence of routers providing transit to multihomed internets. + + o The presence or absence of dynamic address resolution. + + o The presence or absence of an IP routing protocol. + +IP over ATM should therefore be characterized by: + + o Encapsulations below the IP level. + + o Degree to which a connection oriented lower level is available + and utilized. + + o Type of address resolution at the IP subnet level (static or + dynamic). + + o Degree to which address resolution is extended beyond the IP + subnet boundary. + + o The type of routing (if any) supported above the IP level. + +ATM-specific attributes of particular importance include: + + o The different types of services provided by the ATM Adaptation + Layers (AAL). These specify the Quality-of-Service, the + connection-mode, etc. The models discussed within this document + assume an underlying connection-oriented service. + + o The type of virtual circuits used, i.e., PVCs versus SVCs. The + PVC environment requires the use of either static tables for + ATM-to-IP address mapping or the use of inverse ARP, while the + SVC environment requires ARP functionality to be provided. + + o The type of support for multicast services. If point-to-point + services only are available, then a server for IP multicast is + required. If point-to-multipoint services are available, then + IP multicast can be supported via meshes of point-to-multipoint + connections (although use of a server may be necessary due to + limits on the number of multipoint VCs able to be supported or to + maintain the leaf initiated join semantics). + + o The presence of logical link identifiers (VPI/VCIs) and the + various information element (IE) encodings within the ATM SVC + signaling specification, i.e., the ATM Forum UNI version 3.1. + + + +Cole, Shur & Villamizar Informational [Page 5] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + + This allows a VC originator to specify a range of "layer" + entities as the destination "AAL User". The AAL specifications + do not prohibit any particular "layer X" from attaching + directly to a local AAL service. Taken together these points + imply a range of methods for encapsulation of upper layer + protocols over ATM. For example, while LLC/SNAP encapsulation is + one approach (the default), it is also possible to bind virtual + circuits to higher level entities in the TCP/IP protocol stack. + Some examples of the latter are single VC per protocol binding, + TULIP, and TUNIC, discussed further in Section 4. + + o The number and type of ATM administrative domains/networks, and + type of addressing used within an administrative domain/network. + In particular, in the single domain/network case, all attached + systems may be safely assumed to be using a single common + addressing format, while in the multiple domain case, attached + stations may not all be using the same common format, + with corresponding implications on address resolution. (See + Appendix A for a discussion of some of the issues that arise + when multiple ATM address formats are used in the same logical + IP subnet (LIS).) Also security/authentication is much more of a + concern in the multiple domain case. + + IP over ATM proposals do not universally accept that IP routing over + an ATM network is required. Certain proposals rely on the following + assumptions: + + o The widespread deployment of ATM within premises-based networks, + private wide-area networks and public networks, and + + o The definition of interfaces, signaling and routing protocols + among private ATM networks. + + The above assumptions amount to ubiquitous deployment of a seamless + ATM fabric which serves as the hub of a star topology around which + all other media is attached. There has been a great deal of + discussion over when, if ever, this will be a realistic assumption + for very large internetworks, such as the Internet. Advocates of + such approaches point out that even if these are not relevant to very + large internetworks such as the Internet, there may be a place for + such models in smaller internetworks, such as corporate networks. + + The NHRP protocol (Section 8.2), not necessarily specific to ATM, + would be particularly appropriate for the case of ubiquitous ATM + deployment. NHRP supports the establishment of direct connections + across IP subnets in the ATM domain. The use of NHRP does not + require ubiquitous ATM deployment, but currently imposes topology + constraints to avoid routing loops (see Section 7). Section 8.2 + + + +Cole, Shur & Villamizar Informational [Page 6] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + + describes NHRP in greater detail. + + The Peer Model assumes that internetwork layer addresses can be + mapped onto ATM addresses and vice versa, and that reachability + information between ATM routing and internetwork layer routing can be + exchanged. This approach has limited applicability unless ubiquitous + deployment of ATM holds. The peer model is described in Section 8.4. + + The Integrated Model proposes a routing solution supporting an + exchange of routing information between ATM routing and higher level + routing. This provides timely external routing information within + the ATM routing and provides transit of external routing information + through the ATM routing between external routing domains. Such + proposals may better support a possibly lengthy transition during + which assumptions of ubiquitous ATM access do not hold. The + Integrated Model is described in Section 8.5. + + The Multiprotocol over ATM (MPOA) Sub-Working Group was formed by the + ATM Forum to provide multiprotocol support over ATM. The MPOA effort + is at an early stage at the time of this writing. An MPOA baseline + document has been drafted, which provides terminology for further + discussion of the architecture. This document is available from the + FTP server ftp.atmforum.com in pub/contributions as the file atm95- + 0824.ps or atm95-0824.txt. + +4. Encapsulations and Lower Layer Identification + + Data encapsulation, and the identification of VC endpoints, + constitute two important issues that are somewhat orthogonal to the + issues of network topology and routing. The relationship between + these two issues is also a potential sources of confusion. In + conventional LAN technologies the 'encapsulation' wrapped around a + packet of data typically defines the (de)multiplexing path within + source and destination nodes (e.g. the Ethertype field of an + Ethernet packet). Choice of the protocol endpoint within the + packet's destination node is essentially carried 'in-band'. + + As the multiplexing is pushed towards ATM and away from LLC/SNAP + mechanism, a greater burden will be placed upon the call setup and + teardown capacity of the ATM network. This may result in some + questions being raised regarding the scalability of these lower level + multiplexing options. + + With the ATM Forum UNI version 3.1 service the choice of endpoint + within a destination node is made 'out of band' - during the Call + Setup phase. This is quite independent of any in-band encapsulation + mechanisms that may be in use. The B-LLI Information Element allows + Layer 2 or Layer 3 entities to be specified as a VC's endpoint. When + + + +Cole, Shur & Villamizar Informational [Page 7] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + + faced with an incoming SETUP message the Called Party will search + locally for an AAL User that claims to provide the service of the + layer specified in the B-LLI. If one is found then the VC will be + accepted (assuming other conditions such as QoS requirements are also + met). + + An obvious approach for IP environments is to simply specify the + Internet Protocol layer as the VCs endpoint, and place IP packets + into AAL--SDUs for transmission. This is termed 'VC multiplexing' or + 'Null Encapsulation', because it involves terminating a VC (through + an AAL instance) directly on a layer 3 endpoint. However, this + approach has limitations in environments that need to support + multiple layer 3 protocols between the same two ATM level endpoints. + Each pair of layer 3 protocol entities that wish to exchange packets + require their own VC. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Cole, Shur & Villamizar Informational [Page 8] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + + RFC-1483 [6] notes that VC multiplexing is possible, but focuses on + describing an alternative termed 'LLC/SNAP Encapsulation'. This + allows any set of protocols that may be uniquely identified by an + LLC/SNAP header to be multiplexed onto a single VC. Figure 1 shows + how this works for IP packets - the first 3 bytes indicate that the + payload is a Routed Non-ISO PDU, and the Organizationally Unique + Identifier (OUI) of 0x00-00-00 indicates that the Protocol Identifier + (PID) is derived from the EtherType associated with IP packets + (0x800). ARP packets are multiplexed onto a VC by using a PID of + 0x806 instead of 0x800. + .---------------. + : : + : IP Packet : + : : + --------------- + : : + : : + 8 byte header V V + .-------------.-------------.------------.---------------. + : : : : : + : : : : Encapsulated : + : 0xAA-AA-03 : 0x00-00-00 : 0x08-00 : Payload : + : : : : : + -------------^-------------^------------^--------------- + : : : : + : (LLC) (OUI) (PID) : : : + V V V V + .----------------------------------------------------------. + : : + : AAL SDU : + : : + ---------------------------------------------------------- + Figure 1: IP packet encapsulated in an AAL5 SDU + + + + + + + + + + + + + + + + + + +Cole, Shur & Villamizar Informational [Page 9] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + + .----------. .----------. .---------. .----------. + : : : : : : : : + : IP : : ARP : :AppleTalk: : etc... : + : : : : : : : : + ---------- ---------- --------- ---------- + ^ : ^ : ^ : ^ : + : : : : : : : : + : V : V : V : V + .-----------------------------------------------------------. + : : + : 0x800 0x806 0x809 other : + : : + : Instance of layer using LLC/SNAP header to : + : perform multiplexing/demultiplexing : + : : + ----------------------------------------------------------- + ^ : + : : + : V + .------------------. + : : + : Instance of AAL5 : + : terminating : + : one VCC : + : : + ------------------ + + Figure 2: LLC/SNAP encapsulation allows more than just + IP or ARP per VC. + + Whatever layer terminates a VC carrying LLC/SNAP encapsulated traffic + must know how to parse the AAL--SDUs in order to retrieve the + packets. The recently approved signalling standards for IP over ATM + are more explicit, noting that the default SETUP message used to + establish IP over ATM VCs must carry a B-LLI specifying an ISO 8802/2 + Layer 2 (LLC) entity as each VCs endpoint. More significantly, there + is no information carried within the SETUP message about the identity + of the layer 3 protocol that originated the request - until the + packets begin arriving the terminating LLC entity cannot know which + one or more higher layers are packet destinations. + + Taken together, this means that hosts require a protocol entity to + register with the host's local UNI 3.1 management layer as being an + LLC entity, and this same entity must know how to handle and generate + LLC/SNAP encapsulated packets. The LLC entity will also require + mechanisms for attaching to higher layer protocols such as IP and + ARP. Figure 2 attempts to show this, and also highlights the fact + that such an LLC entity might support many more than just IP and ARP. + + + +Cole, Shur & Villamizar Informational [Page 10] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + + In fact the combination of RFC 1483 LLC/SNAP encapsulation, LLC + entities terminating VCs, and suitable choice of LLC/SNAP values, can + go a long way towards providing an integrated approach to building + multiprotocol networks over ATM. + + The processes of actually establishing AAL Users, and identifying + them to the local UNI 3.1 management layers, are still undefined and + are likely to be very dependent on operating system environments. + + Two encapsulations have been discussed within the IP over ATM working + group which differ from those given in RFC-1483 [6]. These have the + characteristic of largely or totally eliminating IP header overhead. + These models were discussed in the July 1993 IETF meeting in + Amsterdam, but have not been fully defined by the working group. + + TULIP and TUNIC assume single hop reachability between IP entities. + Following name resolution, address resolution, and SVC signaling, an + implicit binding is established between entities in the two hosts. + In this case full IP headers (and in particular source and + destination addresses) are not required in each data packet. + + o The first model is "TCP and UDP over Lightweight IP" (TULIP) + in which only the IP protocol field is carried in each packet, + everything else being bound at call set-up time. In this + case the implicit binding is between the IP entities in each + host. Since there is no further routing problem once the binding + is established, since AAL5 can indicate packet size, since + fragmentation cannot occur, and since ATM signaling will handle + exception conditions, the absence of all other IP header fields + and of ICMP should not be an issue. Entry to TULIP mode would + occur as the last stage in SVC signaling, by a simple extension + to the encapsulation negotiation described in RFC-1755 [10]. + + TULIP changes nothing in the abstract architecture of the IP + model, since each host or router still has an IP address which is + resolved to an ATM address. It simply uses the point-to-point + property of VCs to allow the elimination of some per-packet + overhead. The use of TULIP could in principle be negotiated on a + per-SVC basis or configured on a per-PVC basis. + + o The second model is "TCP and UDP over a Nonexistent IP + Connection" (TUNIC). In this case no network-layer information + is carried in each packet, everything being bound at virtual + circuit set-up time. The implicit binding is between two + applications using either TCP or UDP directly over AAL5 on a + dedicated VC. If this can be achieved, the IP protocol field has + no useful dynamic function. However, in order to achieve binding + between two applications, the use of a well-known port number + + + +Cole, Shur & Villamizar Informational [Page 11] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + + in classical IP or in TULIP mode may be necessary during call + set-up. This is a subject for further study and would require + significant extensions to the use of SVC signaling described in + RFC-1755 [10]. + + Encapsulation In setup message Demultiplexing + -------------+--------------------------+------------------------ + SNAP/LLC _ nothing _ source and destination + _ _ address, protocol + _ _ family, protocol, ports + _ _ + NULL encaps _ protocol family _ source and destination + _ _ address, protocol, ports + _ _ + TULIP _ source and destination _ protocol, ports + _ address, protocol family _ + _ _ + TUNIC - A _ source and destination _ ports + _ address, protocol family _ + _ protocol _ + _ _ + TUNIC - B _ source and destination _ nothing + _ address, protocol family _ + _ protocol, ports _ + + + Table 1: Summary of Encapsulation Types + +TULIP/TUNIC can be presented as being on one end of a continuum opposite +the SNAP/LLC encapsulation, with various forms of null encapsulation +somewhere in the middle. The continuum is simply a matter of how much +is moved from in-stream demultiplexing to call setup demultiplexing. +The various encapsulation types are presented in Table 1. + +Encapsulations such as TULIP and TUNIC make assumptions with regard to +the desirability to support connection oriented flow. The tradeoffs +between connection oriented and connectionless are discussed in Section +5. + + + + + + + + + + + + + +Cole, Shur & Villamizar Informational [Page 12] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + +5. Connection Oriented and Connectionless Tradeoffs + +The connection oriented and connectionless approaches each offer +advantages and disadvantages. In the past, strong advocates of pure +connection oriented and pure connectionless architectures have argued +intensely. IP over ATM does not need to be purely connectionless or +purely connection oriented. + + APPLICATION Pure Connection Oriented Approach + ----------------+------------------------------------------------- + General _ Always set up a VC + _ + Short Duration _ Set up a VC. Either hold the packet during VC + UDP (DNS) _ setup or drop it and await a retransmission. + _ Teardown on a timer basis. + _ + Short Duration _ Set up a VC. Either hold packet(s) during VC + TCP (SMTP) _ setup or drop them and await retransmission. + _ Teardown on detection of FIN-ACK or on a timer + _ basis. + _ + Elastic (TCP) _ Set up a VC same as above. No clear method to + Bulk Transfer _ set QoS parameters has emerged. + _ + Real Time _ Set up a VC. QoS parameters are assumed to + (audio, video) _ precede traffic in RSVP or be carried in some + _ form within the traffic itself. + + + Table 2: Connection Oriented vs. Connectionless - a) a pure + connection oriented approach + +ATM with basic AAL 5 service is connection oriented. The IP layer +above ATM is connectionless. On top of IP much of the traffic is +supported by TCP, a reliable end-to-end connection oriented protocol. +A fundamental question is to what degree is it beneficial to map +different flows above IP into separate connections below IP. There is +a broad spectrum of opinion on this. + +As stated in section 4, at one end of the spectrum, IP would remain +highly connectionless and set up single VCs between routers which are +adjacent on an IP subnet and for which there was active traffic flow. +All traffic between the such routers would be multiplexed on a single +ATM VC. At the other end of the spectrum, a separate ATM VC would be +created for each identifiable flow. For every unique TCP or UDP +address and port pair encountered a new VC would be required. Part of +the intensity of early arguments has been over failure to recognize +that there is a middle ground. + + + +Cole, Shur & Villamizar Informational [Page 13] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + +ATM offers QoS and traffic management capabilities that are well +suited for certain types of services. It may be advantageous to use +separate ATM VC for such services. Other IP services such as DNS, are +ill suited for connection oriented delivery, due to their normal very +short duration (typically one packet in each direction). Short +duration transactions, even many using TCP, may also be poorly suited +for a connection oriented model due to setup and state overhead. ATM +QoS and traffic management capabilities may be poorly suited for +elastic traffic. + + APPLICATION Middle Ground + ----------------+------------------------------------------------- + General _ Use RSVP or other indication which clearly + _ indicate a VC is needed and what QoS parameters + _ are appropriate. + _ + Short Duration _ Forward hop by hop. RSVP is unlikely to precede + UDP (DNS) _ this type of traffic. + _ + Short Duration _ Forward hop by hop unless RSVP indicates + TCP (SMTP) _ otherwise. RSVP is unlikely to precede this + _ type of traffic. + _ + Elastic (TCP) _ By default hop by hop forwarding is used. + Bulk Transfer _ However, RSVP information, local configuration + _ about TCP port number usage, or a locally + _ implemented method for passing QoS information + _ from the application to the IP/ATM driver may + _ allow/suggest the establishment of direct VCs. + _ + Real Time _ Forward hop by hop unless RSVP indicates + (audio, video) _ otherwise. RSVP will indicate QoS requirements. + _ It is assumed RSVP will generally be used for + _ this case. A local decision can be made as to + _ whether the QoS is better served by a separate + _ VC. + + Table 3: Connection Oriented vs. Connectionless - b) a middle ground + approach + + + + + + + + + + + + +Cole, Shur & Villamizar Informational [Page 14] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + + APPLICATION Pure Connectionless Approach + ----------------+------------------------------------------------- + General _ Always forward hop by hop. Use queueing + _ algorithms implemented at the IP layer to + _ support reservations such as those specified by + _ RSVP. + _ + Short Duration _ Forward hop by hop. + UDP (DNS) _ + _ + Short Duration _ Forward hop by hop. + TCP (SMTP) _ + _ + Elastic (TCP) _ Forward hop by hop. Assume ability of TCP to + Bulk Transfer _ share bandwidth (within a VBR VC) works as well + _ or better than ATM traffic management. + _ + Real Time _ Forward hop by hop. Assume that queueing + (audio, video) _ algorithms at the IP level can be designed to + _ work with sufficiently good performance + _ (e.g., due to support for predictive + _ reservation). + + + Table 4: Connection Oriented vs. Connectionless - c) a pure + connectionless approach + + Work in progress is addressing how QoS requirements might be + expressed and how the local decisions might be made as to whether + those requirements are best and/or most cost effectively accomplished + using ATM or IP capabilities. Table 2, Table 3, and Table 4 describe + typical treatment of various types of traffic using a pure connection + oriented approach, middle ground approach, and pure connectionless + approach. + + The above qualitative description of connection oriented vs + connectionless service serve only as examples to illustrate differing + approaches. Work in the area of an integrated service model, QoS and + resource reservation are related to but outside the scope of the IP + over ATM Work Group. This work falls under the Integrated Services + Work Group (int-serv) and Reservation Protocol Work Group (rsvp), and + will ultimately determine when direct connections will be + established. The IP over ATM Work Group can make more rapid progress + if concentrating solely on how direct connections are established. + + + + + + + +Cole, Shur & Villamizar Informational [Page 15] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + +6. Crossing IP Subnet Boundaries + + A single IP subnet will not scale well to a large size. Techniques + which extend the size of an IP subnet in other media include MAC + layer bridging, and proxy ARP bridging. + + MAC layer bridging alone does not scale well. Protocols such as ARP + rely on the media broadcast to exchange address resolution + information. Most bridges improve scaling characteristics by + capturing ARP packets and retaining the content, and distributing the + information among bridging peers. The ARP information gathered from + ARP replies is broadcast only where explicit ARP requests are made. + This technique is known as proxy ARP. + + Proxy ARP bridging improves scaling by reducing broadcast traffic, + but still suffers scaling problems. If the bridged IP subnet is part + of a larger internetwork, a routing protocol is required to indicate + what destinations are beyond the IP subnet unless a statically + configured default route is used. A default route is only applicable + to a very simple topology with respect to the larger internet and + creates a single point of failure. Because internets of enormous + size create scaling problems for routing protocols, the component + networks of such large internets are often partitioned into areas, + autonomous systems or routing domains, and routing confederacies. + + The scaling limits of the simple IP subnet require a large network to + be partitioned into smaller IP subnets. For NBMA media like ATM, + there are advantages to creating direct connections across the entire + underlying NBMA network. This leads to the need to create direct + connections across IP subnet boundaries. + + + + + + + + + + + + + + + + + + + + + +Cole, Shur & Villamizar Informational [Page 16] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + + .----------. + ---------< Non-ATM : + .-------. / /-< Subnet >-\ + :Sub-ES >--/ : ---------- : + ------- : : + : : + .--^---. .--^---. + :Router: :Router: + -v-v-- -v-v-- + : : : : + .--------. : : .--------. : : .--------. + .-------. : >-/ \-< >-/ \-< : .-------. + :Sub-ES :---: Subnet :-----: Subnet :-----: Subnet :---:Sub-ES : + ------- : : : : : : ------- + -------- ---v---- -------- + : + .--^----. + :Sub-ES : + ------- + + Figure 3: A configuration with both ATM-based and non-ATM based + subnets. + + For example, figure 3 shows an end-to-end configuration consisting of + four components, three of which are ATM technology based, while the + fourth is a standard IP subnet based on non-ATM technology. End- + systems (either hosts or routers) attached to the ATM-based networks + may communicate either using the Classical IP model or directly via + ATM (subject to policy constraints). Such nodes may communicate + directly at the IP level without necessarily needing an intermediate + router, even if end-systems do not share a common IP-level network + prefix. Communication with end-systems on the non-ATM-based + Classical IP subnet takes place via a router, following the Classical + IP model (see Section 8.1 below). + + Many of the problems and issues associated with creating such direct + connections across subnet boundaries were originally being addressed + in the IETF's IPLPDN working group and the IP over ATM working group. + This area is now being addressed in the Routing over Large Clouds + working group. Examples of work performed in the IPLPDN working + group include short-cut routing (proposed by P. Tsuchiya) and + directed ARP RFC-1433 [5] over SMDS networks. The ROLC working group + has produced the distributed ARP server architectures and the NBMA + Address Resolution Protocol (NARP) [7]. The Next Hop Resolution + Protocol (NHRP) is still work in progress, though the ROLC WG is + considering advancing the current document. Questions/issues + specifically related to defining a capability to cross IP subnet + boundaries include: + + + +Cole, Shur & Villamizar Informational [Page 17] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + + o How can routing be optimized across multiple logical IP subnets + over both a common ATM based and a non-ATM based infrastructure. + For example, in Figure 3, there are two gateways/routers between + the non-ATM subnet and the ATM subnets. The optimal path + from end-systems on any ATM-based subnet to the non ATM-based + subnet is a function of the routing state information of the two + routers. + + o How to incorporate policy routing constraints. + + o What is the proper coupling between routing and address + resolution particularly with respect to off-subnet communication. + + o What are the local procedures to be followed by hosts and + routers. + + o Routing between hosts not sharing a common IP-level (or L3) + network prefix, but able to be directly connected at the NBMA + media level. + + o Defining the details for an efficient address resolution + architecture including defining the procedures to be followed by + clients and servers (see RFC-1433 [5], RFC-1735 [7] and NHRP). + + o How to identify the need for and accommodate special purpose SVCs + for control or routing and high bandwidth data transfers. + + For ATM (unlike other NBMA media), an additional complexity in + supporting IP routing over these ATM internets lies in the + multiplicity of address formats in UNI 3.0 [4]. NSAP modeled address + formats only are supported on "private ATM" networks, while either 1) + E.164 only, 2) NSAP modeled formats only, or 3) both are supported on + "public ATM" networks. Further, while both the E.164 and NSAP + modeled address formats are to be considered as network points of + attachment, it seems that E.164 only networks are to be considered as + subordinate to "private networks", in some sense. This leads to some + confusion in defining an ARP mechanism in supporting all combinations + of end-to-end scenarios (refer to the discussion in Appendix A on the + possible scenarios to be supported by ARP). + +7. Extensions to IP Routing + + RFC-1620 [3] describes the problems and issues associated with direct + connections across IP subnet boundaries in greater detail, as well as + possible solution approaches. The ROLC WG has identified persistent + routing loop problems that can occur if protocols which lose + information critical to path vector routing protocol loop suppression + are used to accomplish direct connections across IP subnet + + + +Cole, Shur & Villamizar Informational [Page 18] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + + boundaries. + + The problems may arise when a destination network which is not on the + NBMA network is reachable via different routers attached to the NBMA + network. This problem occurs with proposals that attempt to carry + reachability information, but do not carry full path attributes (for + path vector routing) needed for inter-AS path suppression, or full + metrics (for distance vector or link state routing even if path + vector routing is not used) for intra-AS routing. + + For example, the NHRP protocol may be used to support the + establishment of direct connections across subnetwork boundaries. + NHRP assumes that routers do run routing protocols (intra and/or + inter domain) and/or static routing. NHRP further assumes that + forwarding tables constructed by these protocols result in a steady + state loop-free forwarding. Note that these two assumptions do not + impose any additional requirements on routers, beyond what is + required in the absence of NHRP. + + NHRP runs in addition to routing protocols, and provides the + information that allows the elimination of multiple IP hops (the + multiple IP hops result from the forwarding tables constructed by the + routing protocols) when traversing an NBMA network. The IPATM and + ROLC WGs have both expended considerable effort in discussing and + coming to understand these limitations. + + It is well-known that truncating path information in Path Vector + protocols (e.g., BGP) or losing metric information in Distance Vector + protocols (e.g., RIP) could result in persistent forwarding loops. + These loops could occur without ATM and without NHRP. + + The combination of NHRP and static routing alone cannot be used in + some topologies where some of the destinations are served by multiple + routers on the NBMA. The combination of NHRP and an intra-AS routing + protocol that does not carry inter-AS routing path attributes alone + cannot be used in some topologies in which the NBMA will provide + inter-AS transit connectivity to destinations from other AS served by + multiple routers on the NBMA. + + Figure 4 provides an example of the routing loops that may be formed + in these circumstances. The example illustrates how the use of NHRP + in the environment where forwarding loops could exist even without + NHRP (due to either truncated path information or loss of metric + information) would still produce forwarding loops. + + There are many potential scenarios for routing loops. An example is + given in Figure 4. It is possible to produce a simpler example where + a loop can form. The example in Figure 4 illustrates a loop which + + + +Cole, Shur & Villamizar Informational [Page 19] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + + will persist even if the protocol on the NBMA supports redirects or + can invalidate any route which changes in any way, but does not + support the communication of full metrics or path attributes. + + .----. .----. + : H1 >----< S1 : Notes: + ---- vvvv H#n == host #n + / : \ R#n == router #n + / : \ S#n == subnet #n + /------/ : \ + : : \ S2 to R3 breaks + .--^---. .----. .-^--. + : : : R4 : : R6 : + : NBMA : --v- --v- See the text for + : : : : details of the + -v--v- = = looping conditions + : \ = SLOW = and mechanisms + : .-^--. = LINK = + : : R2 : = = + : --v- : : + : : .--^-. .--^-. + .-^--. : : R5 : : R7 : + : R8 : : --v- --v- + --v- \ : : + : \ / : + \ .-^^-. .--^-. + \ : S2 : : S4 : + \ --v- --v- + \ \ / + \ \ / + \ .^--^. + \ : R3 : path before the break is + \ -v-- H1->S1->R1->NBMA->R2->S2->R3->H2 + \ / + .----. .-^^-. path after the break is + : H2 >---< S3 : H1->S1->R1->NBMA->R2->S2->R5->R4->S1 + ---- ---- \------<--the-loop--<-------/ + + Figure 4: A Routing Loop Due to Lost PV Routing Attributes. + + In the example in Figure 4, Host 1 is sending traffic toward Host 2. + In practice, host routes would not be used, so the destination for + the purpose of routing would be Subnet 3. The traffic travels by way + of Router 1 which establishes a "cut-through" SVC to the NBMA next- + hop, shown here as Router 2. Router 2 forwards traffic destined for + Subnet 3 through Subnet 2 to Router 3. Traffic from Host 1 would + then reach Host 2. + + + + +Cole, Shur & Villamizar Informational [Page 20] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + + Router 1's cut-through routing implementation caches an association + between Host 2's IP address (or more likely all of Subnet 3) and + Router 2's NBMA address. While the cut-through SVC is still up, Link + 1 fails. Router 5 loses it's preferred route through Router 3 and + must direct traffic in the other direction. Router 2 loses a route + through Router 3, but picks up an alternate route through Router 5. + Router 1 is still directing traffic toward Router 2 and advertising a + means of reaching Subnet 3 to Subnet 1. Router 5 and Router 2 will + see a route, creating a loop. + + This loop would not form if path information normally carried by + interdomain routing protocols such as BGP and IDRP were retained + across the NBMA. Router 2 would reject the initial route from Router + 5 due to the path information. When Router 2 declares the route to + Subnet 3 unreachable, Router 1 withdraws the route from routing at + Subnet 1, leaving the route through Router 4, which would then reach + Router 5, and would reach Router 2 through both Router 1 and Router + 5. Similarly, a link state protocol would not form such a loop. + + Two proposals for breaking this form of routing loop have been + discussed. Redirect in this example would have no effect, since + Router 2 still has a route, just has different path attributes. A + second proposal is that is that when a route changes in any way, the + advertising NBMA cut-through router invalidates the advertisement for + some time period. This is similar to the notion of Poison Reverse in + distance vector routing protocols. In this example, Router 2 would + eventually readvertise a route since a route through Router 6 exists. + When Router 1 discovers this route, it will advertise it to Subnet 1 + and form the loop. Without path information, Router 1 cannot + distinguish between a loop and restoration of normal service through + the link L1. + + The loop in Figure 4 can be prevented by configuring Router 4 or + Router 5 to refuse to use the reverse path. This would break backup + connectivity through Router 8 if L1 and L3 failed. The loop can also + be broken by configuring Router 2 to refuse to use the path through + Router 5 unless it could not reach the NBMA. Special configuration of + Router 2 would work as long as Router 2 was not distanced from Router + 3 and Router 5 by additional subnets such that it could not determine + which path was in use. If Subnet 1 is in a different AS or RD than + Subnet 2 or Subnet 4, then the decision at Router 2 could be based on + path information. + + + + + + + + + +Cole, Shur & Villamizar Informational [Page 21] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + + .--------. .--------. + : Router : : Router : + --v-v--- ---v-v-- + : : : : + .--------. .--------. : : .--------. : : .--------. .--------. + : Sub-ES :---: Subnet :-/ \-: Subnet :-/ \-: Subnet :---: Sub-ES : + -------- -------- -------- -------- -------- + + Figure 5: The Classical IP model as a concatenation of three separate + ATM IP subnets. + + In order for loops to be prevented by special configuration at the + NBMA border router, that router would need to know all paths that + could lead back to the NBMA. The same argument that special + configuration could overcome loss of path information was posed in + favor of retaining the use of the EGP protocol defined in the now + historic RFC-904 [11]. This turned out to be unmanageable, with + routing problems occurring when topology was changed elsewhere. + +8. IP Over ATM Proposals + +8.1 The Classical IP Model + + The Classical IP Model was suggested at the Spring 1993 IETF meeting + [8] and retains the classical IP subnet architecture. This model + simply consists of cascading instances of IP subnets with IP-level + (or L3) routers at IP subnet borders. An example realization of this + model consists of a concatenation of three IP subnets. This is shown + in Figure 5. Forwarding IP packets over this Classical IP model is + straight forward using already well established routing techniques + and protocols. + + SVC-based ATM IP subnets are simplified in that they: + + o limit the number of hosts which must be directly connected at any + given time to those that may actually exchange traffic. + + o The ATM network is capable of setting up connections between + any pair of hosts. Consistent with the standard IP routing + algorithm [2] connectivity to the "outside" world is achieved + only through a router, which may provide firewall functionality + if so desired. + + o The IP subnet supports an efficient mechanism for address + resolution. + + Issues addressed by the IP Over ATM Working Group, and some of the + resolutions, for this model are: + + + +Cole, Shur & Villamizar Informational [Page 22] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + + o Methods of encapsulation and multiplexing. This issue is + addressed in RFC-1483 [6], in which two methods of encapsulation + are defined, an LLC/SNAP and a per-VC multiplexing option. + + o The definition of an address resolution server (defined in + RFC-1577). + + o Defining the default MTU size. This issue is addressed in + RFC-1626 [1] which proposes the use of the MTU discovery + protocol (RFC-1191 [9]). + + o Support for IP multicasting. In the summer of 1994, work began + on the issue of supporting IP multicasting over the SVC LATM + model. The proposal for IP multicasting is currently defined by + a set of IP over ATM WG Works in Progress, referred to collectively + as the IPMC documents. In order to support IP multicasting the + ATM subnet must either support point-to- multipoint SVCs, or + multicast servers, or both. + + o Defining interim SVC parameters, such as QoS parameters and + time-out values. + + o Signaling and negotiations of parameters such as MTU size + and method of encapsulation. RFC-1755 [10] describes an + implementation agreement for routers signaling the ATM network + to establish SVCs initially based upon the ATM Forum's UNI + version 3.0 specification [4], and eventually to be based + upon the ATM Forum's UNI version 3.1 and later specifications. + Topics addressed in RFC-1755 include (but are not limited to) + VC management procedures, e.g., when to time-out SVCs, QOS + parameters, service classes, explicit setup message formats for + various encapsulation methods, node (host or router) to node + negotiations, etc. + + RFC-1577 is also applicable to PVC-based subnets. Full mesh PVC + connectivity is required. + + For more information see RFC-1577 [8]. + +8.2 The ROLC NHRP Model + + The Next Hop Resolution Protocol (NHRP), currently a work in progress + defined by the Routing Over Large Clouds Working Group (ROLC), + performs address resolution to accomplish direct connections across + IP subnet boundaries. NHRP can supplement RFC-1577 ARP. There has + been recent discussion of replacing RFC-1577 ARP with NHRP. NHRP can + also perform a proxy address resolution to provide the address of the + border router serving a destination off of the NBMA which is only + + + +Cole, Shur & Villamizar Informational [Page 23] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + + served by a single router on the NBMA. NHRP as currently defined + cannot be used in this way to support addresses learned from routers + for which the same destinations may be heard at other routers, + without the risk of creating persistent routing loops. + +8.3 "Conventional" Model + + The "Conventional Model" assumes that a router can relay IP packets + cell by cell, with the VPI/VCI identifying a flow between adjacent + routers rather than a flow between a pair of nodes. A latency + advantage can be provided if cell interleaving from multiple IP + packets is allowed. Interleaving frames within the same VCI requires + an ATM AAL such as AAL3/4 rather than AAL5. Cell forwarding is + accomplished through a higher level mapping, above the ATM VCI layer. + + The conventional model is not under consideration by the IP/ATM WG. + The COLIP WG has been formed to develop protocols based on the + conventional model. + +8.4 The Peer Model + + The Peer Model places IP routers/gateways on an addressing peer basis + with corresponding entities in an ATM cloud (where the ATM cloud may + consist of a set of ATM networks, inter-connected via UNI or P-NNI + interfaces). ATM network entities and the attached IP hosts or + routers exchange call routing information on a peer basis by + algorithmically mapping IP addressing into the NSAP space. Within + the ATM cloud, ATM network level addressing (NSAP-style), call + routing and packet formats are used. + + In the Peer Model no provision is made for selection of primary path + and use of alternate paths in the event of primary path failure in + reaching multihomed non-ATM destinations. This will limit the + topologies for which the peer model alone is applicable to only those + topologies in which non-ATM networks are singly homed, or where loss + of backup connectivity is not an issue. The Peer Model may be used + to avoid the need for an address resolution protocol and in a proxy- + ARP mode for stub networks, in conjunction with other mechanisms + suitable to handle multihomed destinations. + + During the discussions of the IP over ATM working group, it was felt + that the problems with the end-to-end peer model were much harder + than any other model, and had more unresolved technical issues. + While encouraging interested individuals/companies to research this + area, it was not an initial priority of the working group to address + these issues. The ATM Forum Network Layer Multiprotocol Working + Group has reached a similar conclusion. + + + + +Cole, Shur & Villamizar Informational [Page 24] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + +8.5 The PNNI and the Integrated Models + + The Integrated model (proposed and under study within the + Multiprotocol group of ATM Forum) considers a single routing protocol + to be used for both IP and for ATM. A single routing information + exchange is used to distribute topological information. The routing + computation used to calculate routes for IP will take into account + the topology, including link and node characteristics, of both the IP + and ATM networks and calculates an optimal route for IP packets over + the combined topology. + + The PNNI is a hierarchical link state routing protocol with multiple + link metrics providing various available QoS parameters given current + loading. Call route selection takes into account QoS requirements. + Hysteresis is built into link metric readvertisements in order to + avoid computational overload and topological hierarchy serves to + subdivide and summarize complex topologies, helping to bound + computational requirements. + + Integrated Routing is a proposal to use PNNI routing as an IP routing + protocol. There are several sets of technical issues that need to be + addressed, including the interaction of multiple routing protocols, + adaptation of PNNI to broadcast media, support for NHRP, and others. + These are being investigated. However, the ATM Forum MPOA group is + not currently performing this investigation. Concerned individuals + are, with an expectation of bringing the work to the ATM Forum and + the IETF. + + PNNI has provisions for carrying uninterpreted information. While + not yet defined, a compatible extension of the base PNNI could be + used to carry external routing attributes and avoid the routing loop + problems described in Section 7. + + + + + + + + + + + + + + + + + + + +Cole, Shur & Villamizar Informational [Page 25] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + + ++++++++++++++++++++++++++++++++++++++++++ + + .------------. .------------. + + .---------. + .-: :-. .-: :-. + + : Host or >-+-< : Single ATM : >--< : Single ATM : >-+-----\ + : Router : + : : Domain : : : : Domain : : + : + --------- + -: :- -: :- + .---^----. + + ------------ ------------ + : Router : + + .------------. + ---v---- + .---------. + .-: :-. + : + : Host or >-+- ... ... --< : Single ATM : >-+-----/ + : Router : + : : Domain : : + + --------- + ATM Cloud -: :- + + + ------------ + + ++++++++++++++++++++++++++++++++++++++++++ + + Note: IS within ATM cloud are ATM IS + + Figure 6: The ATM transition model assuming the presence of gateways + or routers between the ATM networks and the ATM peer networks. + +8.6 Transition Models + + Finally, it is useful to consider transition models, lying somewhere + between the Classical IP Models and the Peer and Integrated Models. + Some possible architectures for transition models have been suggested + by Fong Liaw. Others are possible, for example Figure 6 showing a + Classical IP transition model which assumes the presence of gateways + between ATM networks and ATM Peer networks. + + Some of the models described in the prior sections, most notably the + Integrated Model, anticipate the need for mixed environment with + complex routing topologies. These inherently support transition + (possibly with an indefinite transition period). Models which + provide no transition support are primarily of interest to new + deployments which make exclusive, or near exclusive use of ATM or + deployments capable of wholesale replacement of existing networks or + willing to retain only non-ATM stub networks. + + For some models, most notably the Peer Model, the ability to attach + to a large non-ATM or mixed internetwork is infeasible without + routing support at a higher level, or at best may pose + interconnection topology constraints (for example: single point of + attachment and a static default route). If a particular model + requires routing support at a higher level a large deployment will + need to be subdivided to provide scalability at the higher level, + which for some models degenerates back to the Classical model. + + + + + +Cole, Shur & Villamizar Informational [Page 26] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + +9. Application of the Working Group's and Related Documents + + The IP Over ATM Working Group has generated several Works in Progress + and RFCs. This section identifies the relationship of these and + other related documents to the various IP Over ATM Models identified + in this document. The documents and RFCs produced to date are the + following references, RFC-1483 [6], RFC-1577 [8], RFC-1626 [1], RFC- + 1755 [10] and the IPMC documents. The ROLC WG has produced the NHRP + document. Table 5 gives a summary of these documents and their + relationship to the various IP Over ATM Models. + +Acknowledgments + + This memo is the direct result of the numerous discussions of the IP + over ATM Working Group of the Internet Engineering Task Force. The + authors also had the benefit of several private discussions with H. + Nguyen of AT&T Bell Laboratories. Brian Carpenter of CERN was kind + enough to contribute the TULIP and TUNIC sections to this memo. + Grenville Armitage of Bellcore was kind enough to contribute the + sections on VC binding, encapsulations and the use of B-LLI + information elements to signal such bindings. The text of Appendix A + was pirated liberally from Anthony Alles' of Cisco posting on the IP + over ATM discussion list (and modified at the authors' discretion). + M. Ohta provided a description of the Conventional Model (again which + the authors modified at their discretion). This memo also has + benefitted from numerous suggestions from John T. Amenyo of ANS, Joel + Halpern of Newbridge, and Andy Malis of Ascom-Timplex. Yakov Rekhter + of Cisco provided valuable comments leading to the clarification of + normal loop free NHRP operation and the potential for routing loop + problems only with the improper use of NHRP. + + Documents Summary + ----------------+------------------------------------------------- + RFC-1483 _ How to identify/label multiple + _ packet/frame-based protocols multiplexed over + _ ATM AAL5. Applies to any model dealing with IP + _ over ATM AAL5. + _ + RFC-1577 _ Model for transporting IP and ARP over ATM AAL5 + _ in an IP subnet where all nodes share a common + _ IP network prefix. Includes ARP server/Inv-ARP + _ packet formats and procedures for SVC/PVC + _ subnets. + _ + RFC-1626 _ Specifies default IP MTU size to be used with + _ ATM AAL5. Requires use of PATH MTU discovery. + _ Applies to any model dealing with IP over ATM + _ AAL5 + + + +Cole, Shur & Villamizar Informational [Page 27] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + + _ + RFC-1755 _ Defines how implementations of IP over ATM + _ should use ATM call control signaling + _ procedures, and recommends values of mandatory + _ and optional IEs focusing particularly on the + _ Classical IP model. + _ + IPMC _ Defines how to support IP multicast in Classical + _ IP model using either (or both) meshes of + _ point-to-multipoint ATM VCs, or multicast + _ server(s). IPMC is work in progress. + _ + NHRP _ Describes a protocol that can be used by hosts + _ and routers to determine the NBMA next hop + _ address of a destination in "NBMA + _ connectivity" + _ of the sending node. If the destination is not + _ connected to the NBMA fabric, the IP and NBMA + _ addresses of preferred egress points are + _ returned. NHRP is work in progress (ROLC WG). + + + Table 5: Summary of WG Documents + +References + + [1] Atkinson, R., "Default IP MTU for use over ATM AAL5", RFC 1626, + Naval Research Laboratory, May 1994. + + [2] Braden, R., and J. Postel, "Requirements for Internet Gateways", + STD 4, RFC 1009, USC/Information Sciences Institute, June 1987. + + [3] Braden, R., Postel, J., and Y. Rekhter, "Internet Architecture + Extensions for Shared Media", RFC 1620, USC/Information Sciences + Institute, IBM Research, May 1994. + + [4] ATM Forum, "ATM User-Network Interface Specification", Prentice + Hall, September 1993. + + [5] Garrett, J., Hagan, J., and J. Wong, "Directed ARP", RFC 1433, + AT&T Bell Labs, University of Pennsylvania, March 1993. + + [6] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation + Layer 5", RFC 1483, Telecom Finland, July 1993. + + [7] Heinanen, J., and R. Govindan, "NBMA Address Resolution Protocol + (NARP)", RFC 1735, Telecom Finland, USC/Information Sciences + Institute, December 1994. + + + +Cole, Shur & Villamizar Informational [Page 28] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + + [8] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, + Hewlett-Packard Laboratories, January 1994. + + [9] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, + DECWRL, Stanford University, November 1990. + + [10] Perez, M., Liaw, F., Grossman, D., Mankin, A., and A. Hoffman, + "ATM signalling support for IP over ATM", RFC 1755, + USC/Information Sciences Institute, FORE Systems, Inc., Motorola + Codex, Ascom Timeplex, Inc., January 1995. + + [11] Mills, D., "Exterior Gateway Protocol Formal Specification", + STD 18, RFC 904, BBN, April 1984. + +A Potential Interworking Scenarios to be Supported by ARP + + The architectural model of the VC routing protocol, being defined by + the Private Network-to-Network Interface (P-NNI) working group of the + ATM Forum, categorizes ATM networks into two types: + + o Those that participate in the VC routing protocols and use NSAP + modeled addresses UNI 3.0 [4] (referred to as private networks, + for short), and + + o Those that do not participate in the VC routing protocol. + Typically, but possibly not in all cases, public ATM networks + that use native mode E.164 addresses UNI 3.0 [4] will fall into + this later category. + + The issue for ARP, then is to know what information must be returned + to allow such connectivity. Consider the following scenarios: + + o Private host to Private Host, no intervening public transit + network(s): Clearly requires that ARP return only the NSAP + modeled address format of the end host. + + o Private host to Private host, through intervening public + networks: In this case, the connection setup from host A to host + B must transit the public network(s). This requires that at + each ingress point to the public network that a routing decision + be made as to which is the correct egress point from that public + network to the next hop private ATM switch, and that the native + E.164 address of that egress point be found (finding this is a VC + routing problem, probably requiring configuration of the public + network links and connectivity information). ARP should return, + at least, the NSAP address of the endpoint in which case the + mapping of the NSAP addresses to the E.164 address, as specified + in [4], is the responsibility of ingress switch to the public + + + +Cole, Shur & Villamizar Informational [Page 29] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + + network. + + o Private Network Host to Public Network Host: To get connectivity + between the public node and the private nodes requires the + same kind of routing information discussed above - namely, the + directly attached public network needs to know the (NSAP format) + ATM address of the private station, and the native E.164 address + of the egress point from the public network to that private + network (or to that of an intervening transit private network + etc.). There is some argument, that the ARP mechanism could + return this egress point native E.164 address, but this may + be considered inconsistent for ARP to return what to some is + clearly routing information, and to others is required signaling + information. + + In the opposite direction, the private network node can use, and + should only get, the E.164 address of the directly attached public + node. What format should this information be carried in? This + question is clearly answered, by Note 9 of Annex A of UNI 3.0 [4], + vis: + + "A call originated on a Private UNI destined for an host which + only has a native (non-NSAP) E.164 address (i.e. a system + directly attached to a public network supporting the native E.164 + format) will code the Called Party number information element in + the (NSAP) E.164 private ATM Address Format, with the RD, AREA, + and ESI fields set to zero. The Called Party Subaddress + information element is not used." + + Hence, in this case, ARP should return the E.164 address of the + public ATM station in NSAP format. This is essentially implying an + algorithmic resolution between the native E.164 and NSAP addresses of + directly attached public stations. + + o Public network host to Public network host, no intervening + private network: In this case, clearly the Q.2931 requests would + use native E.164 address formats. + + o Public network host to Public network host, intervening private + network: same as the case immediately above, since getting + to and through the private network is a VC routing, not an + addressing issue. + + So several issues arise for ARP in supporting arbitrary connections + between hosts on private and public network. One is how to + distinguish between E.164 address and E.164 encoded NSAP modeled + address. Another is what is the information to be supplied by ARP, + e.g., in the public to private scenario should ARP return only the + + + +Cole, Shur & Villamizar Informational [Page 30] + +RFC 1932 IP over ATM: A Framework Document April 1996 + + + private NSAP modeled address or both an E.164 address, for a point of + attachment between the public and private networks, along with the + private NSAP modeled address. + +Authors' Addresses + + Robert G. Cole + AT&T Bell Laboratories + 101 Crawfords Corner Road, Rm. 3L-533 + Holmdel, NJ 07733 + + Phone: (908) 949-1950 + Fax: (908) 949-8887 + EMail: rgc@qsun.att.com + + + David H. Shur + AT&T Bell Laboratories + 101 Crawfords Corner Road, Rm. 1F-338 + Holmdel, NJ 07733 + + Phone: (908) 949-6719 + Fax: (908) 949-5775 + EMail: d.shur@att.com + + + Curtis Villamizar + ANS + 100 Clearbrook Road + Elmsford, NY 10523 + + EMail: curtis@ans.net + + + + + + + + + + + + + + + + + + + +Cole, Shur & Villamizar Informational [Page 31] + |