📄 rfc1932.txt
字号:
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.2Cole, 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. WhenCole, 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 SDUCole, 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].⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -