Multiprotocol Encapsulation over ATM Adaptation Layer 5
RFC 2684
Document | Type |
RFC - Proposed Standard
(September 1999; No errata)
Obsoletes RFC 1483
|
|
---|---|---|---|
Authors | Daniel Grossman , Juha Heinanen | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2684 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group D. Grossman Request for Comments: 2684 Motorola, Inc. Obsoletes: 1483 J. Heinanen Category: Standards Track Telia September 1999 Multiprotocol Encapsulation over ATM Adaptation Layer 5 Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This memo replaces RFC 1483. It describes two encapsulations methods for carrying network interconnect traffic over AAL type 5 over ATM. The first method allows multiplexing of multiple protocols over a single ATM virtual connection whereas the second method assumes that each protocol is carried over a separate ATM virtual connection. Applicability This specification is intended to be used in implementations which use ATM networks to carry multiprotocol traffic among hosts, routers and bridges which are ATM end systems. 1. Introduction Asynchronous Transfer Mode (ATM) wide area, campus and local area networks are used to transport IP datagrams and other connectionless traffic between hosts, routers, bridges and other networking devices. This memo describes two methods for carrying connectionless routed and bridged Protocol Data Units (PDUs) over an ATM network. The "LLC Encapsulation" method allows multiplexing of multiple protocols over a single ATM virtual connection (VC). The protocol type of each PDU is identified by a prefixed IEEE 802.2 Logical Link Control (LLC) header. In the "VC Multiplexing" method, each ATM VC carries PDUs of exactly one protocol type. When multiple protocols need to be transported, there is a separate VC for each. Grossman & Heinanen Standards Track [Page 1] RFC 2684 Multiprotocol Over AALS September 1999 The unit of transport in ATM is a 53 octet fixed length PDU called a cell. A cell consists of a 5 octet header and a 48 byte payload. Variable length PDUs, including those addressed in this memo, must be segmented by the transmitter to fit into the 48 octet ATM cell payload, and reassembled by the receiver. This memo specifies the use of the ATM Adaptation Layer type 5 (AAL5), as defined in ITU-T Recommendation I.363.5 [2] for this purpose. Variable length PDUs are carried in the Payload field of the AAL5 Common Part Convergence Sublayer (CPCS) PDU. This memo only describes how routed and bridged PDUs are carried directly over the AAL5 CPCS, i.e., when the Service Specific Convergence Sublayer (SSCS) of AAL5 is absent. If Frame Relay Service Specific Convergence Sublayer (FR-SSCS), as defined in ITU-T Recommendation I.365.1 [3], is used over the CPCS, then routed and bridged PDUs are carried using the NLPID multiplexing method described in RFC 2427 [4]. The RFC 2427 encapsulation MUST be used in the special case that Frame Relay Network Interworking or transparent mode Service Interworking [9] are used, but is NOT RECOMMENDED for other applications. Appendix A (which is for information only) shows the format of the FR-SSCS-PDU as well as how IP and CLNP PDUs are encapsulated over FR-SSCS according to RFC 2427. This memo also includes an optional encapsulation for use with Virtual Private Networks that operate over an ATM subnet. If it is desired to use the facilities which are designed for the Point-to-Point Protocol (PPP), and there exists a point-to-point relationship between peer systems, then RFC 2364, rather than this memo, applies. 2. Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [10]. 3. Selection of the Multiplexing Method The decision as to whether to use LLC encapsulation or VC- multiplexing depends on implementation and system requirements. In general, LLC encapsulation tends to require fewer VCs in a multiprotocol environment. VC multiplexing tends to reduce fragmentation overhead (e.g., an IPV4 datagram containing a TCP control packet with neither IP nor TCP options exactly fits into a single cell). Grossman & Heinanen Standards Track [Page 2] RFC 2684 Multiprotocol Over AALS September 1999 When two ATM end systems wish to exchange connectionless PDUs acrossShow full document text