diff options
Diffstat (limited to 'doc/rfc/rfc2684.txt')
| -rw-r--r-- | doc/rfc/rfc2684.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc2684.txt b/doc/rfc/rfc2684.txt new file mode 100644 index 0000000..438910f --- /dev/null +++ b/doc/rfc/rfc2684.txt @@ -0,0 +1,1291 @@ + + + + + + +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 across + an ATM Permanent Virtual Connection (PVC), selection of the + multiplexing method is done by configuration. ATM connection control + signalling procedures are used to negotiate the encapsulation method + when ATM Switched Virtual Connections (SVCs) are to be used. [5] and + [8] specify how this negotiation is done. + +4. AAL5 PDU Format + + For both multiplexing methods, routed and bridged PDUs MUST be + encapsulated within the Payload field of an AAL5 CPCS-PDU. + + ITU-T Recomendation I.363.5 [2] provides the complete definition of + the AAL5 PDU format and procedures at the sender and receiver. The + AAL5 message mode service, in the non-assured mode of operation MUST + be used. The corrupted delivery option MUST NOT be used. A + reassembly timer MAY be used. The following description is provided + for information. + + The format of the AAL5 CPCS-PDU is shown below: + + AAL5 CPCS-PDU Format + +-------------------------------+ + | . | + | . | + | CPCS-PDU Payload | + | up to 2^16 - 1 octets) | + | . | + | . | + +-------------------------------+ + | PAD ( 0 - 47 octets) | + +-------------------------------+ ------- + | CPCS-UU (1 octet ) | + +-------------------------------+ + | CPI (1 octet ) | + +-------------------------------+CPCS-PDU Trailer + | Length (2 octets) | + +-------------------------------| + | CRC (4 octets) | + +-------------------------------+ ------- + + The Payload field contains user information up to 2^16 - 1 octets. + + The PAD field pads the CPCS-PDU to fit exactly into the ATM cells + such that the last 48 octet cell payload created by the SAR sublayer + will have the CPCS-PDU Trailer right justified in the cell. + + + + + +Grossman & Heinanen Standards Track [Page 3] + +RFC 2684 Multiprotocol Over AALS September 1999 + + + The CPCS-UU (User-to-User indication) field is used to transparently + transfer CPCS user to user information. The field is not used by the + multiprotocol ATM encapsulation described in this memo and MAY be set + to any value. + + The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer to + 64 bits. This field MUST be coded as 0x00. + + The Length field indicates the length, in octets, of the Payload + field. The maximum value for the Length field is 65535 octets. A + Length field coded as 0x00 is used for the abort function. + + The CRC field is used to detect bit errors in the CPCS-PDU. A CRC-32 + is used. + +5. LLC Encapsulation + + LLC Encapsulation is needed when more than one protocol might be + carried over the same VC. In order to allow the receiver to properly + process the incoming AAL5 CPCS-PDU, the Payload Field contains + information necessary to identify the protocol of the routed or + bridged PDU. In LLC Encapsulation, this information MUST be encoded + in an LLC header placed in front of the carried PDU. + + Although this memo only deals with protocols that operate over LLC + Type 1 (unacknowledged connectionless mode) service, the same + encapsulation principle also applies to protocols operating over LLC + Type 2 (connection-mode) service. In the latter case the format and + contents of the LLC header would be as described in IEEE 802.1 and + IEEE 802.2. + +5.1. LLC Encapsulation for Routed Protocols + + In LLC Encapsulation, the protocol type of routed PDUs MUST be + identified by prefixing an IEEE 802.2 LLC header to each PDU. In + some cases, the LLC header MUST be followed by an IEEE 802.1a + SubNetwork Attachment Point (SNAP) header. In LLC Type 1 operation, + the LLC header MUST consist of three one octet fields: + + +------+------+------+ + | DSAP | SSAP | Ctrl | + +------+------+------+ + + In LLC Encapsulation for routed protocols, the Control field MUST be + set to 0x03, specifying a Unnumbered Information (UI) Command PDU. + + + + + + +Grossman & Heinanen Standards Track [Page 4] + +RFC 2684 Multiprotocol Over AALS September 1999 + + + The LLC header value 0xFE-FE-03 MUST be used to identify a routed PDU + in the ISO NLPID format (see [6] and Appendix B). For NLPID-formatted + routed PDUs, the content of the AAL5 CPCS-PDU Payload field MUST be + as follows: + + Payload Format for Routed NLPID-formatted PDUs + +-------------------------------+ + | LLC 0xFE-FE-03 | + +-------------------------------+ + | NLPID (1 octet) | + +-------------------------------+ + | . | + | PDU | + | (up to 2^16 - 4 octets) | + | . | + +-------------------------------+ + + The routed protocol MUST be identified by a one octet NLPID field + that is part of Protocol Data. NLPID values are administered by ISO + and ITU-T. They are defined in ISO/IEC TR 9577 [6] and some of the + currently defined ones are listed in Appendix C. + + An NLPID value of 0x00 is defined in ISO/IEC TR 9577 as the Null + Network Layer or Inactive Set. Since it has no significance within + the context of this encapsulation scheme, a NLPID value of 0x00 MUST + NOT be used. + + Although there is a NLPID value (0xCC) that indicates IP, the NLPID + format MUST NOT be used for IP. Instead, IP datagrams MUST be + identified by a SNAP header, as defined below. + + The presence of am IEEE 802.1a SNAP header is indicated by the LLC + header value 0xAA-AA-03. A SNAP header is of the form + + +------+------+------+------+------+ + | OUI | PID | + +------+------+------+------+------+ + + The SNAP header consists of a three octet Organizationally Unique + Identifier (OUI) and a two octet Protocol Identifier (PID). The OUI + is administered by IEEE and identifies an organization which + administers the values which might be assigned to the PID. The SNAP + header thus uniquely identifies a routed or bridged protocol. The + OUI value 0x00-00-00 indicates that the PID is an EtherType. + + + + + + + +Grossman & Heinanen Standards Track [Page 5] + +RFC 2684 Multiprotocol Over AALS September 1999 + + + The format of the AAL5 CPCS-PDU Payload field for routed non-NLPID + Formatted PDUs MUST be as follows: + + Payload Format for Routed non-NLPID formatted PDUs + +-------------------------------+ + | LLC 0xAA-AA-03 | + +-------------------------------+ + | OUI 0x00-00-00 | + +-------------------------------+ + | EtherType (2 octets) | + +-------------------------------+ + | . | + | Non-NLPID formatted PDU | + | (up to 2^16 - 9 octets) | + | . | + +-------------------------------+ + + In the particular case of an IPv4 PDU, the Ethertype value is 0x08- + 00, and the payload format MUST be: + + Payload Format for Routed IPv4 PDUs + +-------------------------------+ + | LLC 0xAA-AA-03 | + +-------------------------------+ + | OUI 0x00-00-00 | + +-------------------------------+ + | EtherType 0x08-00 | + +-------------------------------+ + | . | + | IPv4 PDU | + | (up to 2^16 - 9 octets) | + | . | + +-------------------------------+ + + This format is consistent with that defined in RFC 1042 [7]. + +5.2. LLC Encapsulation for Bridged Protocols + + In LLC Encapsulation, bridged PDUs are encapsulated by identifying + the type of the bridged media in the SNAP header. The presence of + the SNAP header MUST be indicated by the LLC header value 0xAA-AA-03. + The OUI value in the SNAP header MUST be the 802.1 organization code + 0x00-80-C2. The type of the bridged media MUST be specified by the + two octet PID. The PID MUST also indicate whether the original Frame + Check Sequence (FCS) is preserved within the bridged PDU. Appendix B + provides a list of media type (PID) values that can be used in ATM + encapsulation. + + + + +Grossman & Heinanen Standards Track [Page 6] + +RFC 2684 Multiprotocol Over AALS September 1999 + + + The AAL5 CPCS-PDU Payload field carrying a bridged PDU MUST have one + of the following formats. The necessary number of padding octets + MUST be added after the PID field in order to align the + Ethernet/802.3 LLC Data field, 802.4 Data Unit field, 802.5 Info + field, FDDI Info field or 802.6 Info field (respectively) of the + bridged PDU to begin at a four octet boundary. The bit ordering of + the MAC address MUST be the same as it would be on the LAN or MAN + (e.g., in canoncial form for bridged Ethernet/IEEE 802.3 PDUs, but in + 802.5/FDDI format for bridged 802.5 PDUs). + + Payload Format for Bridged Ethernet/802.3 PDUs + +-------------------------------+ + | LLC 0xAA-AA-03 | + +-------------------------------+ + | OUI 0x00-80-C2 | + +-------------------------------+ + | PID 0x00-01 or 0x00-07 | + +-------------------------------+ + | PAD 0x00-00 | + +-------------------------------+ + | MAC destination address | + +-------------------------------+ + | | + | (remainder of MAC frame) | + | | + +-------------------------------+ + | LAN FCS (if PID is 0x00-01) | + +-------------------------------+ + + The Ethernet/802.3 physical layer requires padding of frames to a + minimum size. A bridge that uses uses the Bridged Ethernet/802.3 + encapsulation format with the preserved LAN FCS MUST include padding. + A bridge that uses the Bridged Ethernet/802.3 encapsulation format + without the preserved LAN FCS MAY either include padding, or omit it. + When a bridge receives a frame in this format without the LAN FCS, it + MUST be able to insert the necessary padding (if none is already + present) before forwarding to an Ethernet/802.3 subnetwork. + + + + + + + + + + + + + + +Grossman & Heinanen Standards Track [Page 7] + +RFC 2684 Multiprotocol Over AALS September 1999 + + + Payload Format for Bridged 802.4 PDUs + +-------------------------------+ + | LLC 0xAA-AA-03 | + +-------------------------------+ + | OUI 0x00-80-C2 | + +-------------------------------+ + | PID 0x00-02 or 0x00-08 | + +-------------------------------+ + | PAD 0x00-00-00 | + +-------------------------------+ + | Frame Control (1 octet) | + +-------------------------------+ + | MAC destination address | + +-------------------------------+ + | | + | (remainder of MAC frame) | + | | + +-------------------------------+ + | LAN FCS (if PID is 0x00-02) | + +-------------------------------+ + + Payload Format for Bridged 802.5 PDUs + +-------------------------------+ + | LLC 0xAA-AA-03 | + +-------------------------------+ + | OUI 0x00-80-C2 | + +-------------------------------+ + | PID 0x00-03 or 0x00-09 | + +-------------------------------+ + | PAD 0x00-00-XX | + +-------------------------------+ + | Frame Control (1 octet) | + +-------------------------------+ + | MAC destination address | + +-------------------------------+ + | | + | (remainder of MAC frame) | + | | + +-------------------------------+ + | LAN FCS (if PID is 0x00-03) | + +-------------------------------+ + + Since the 802.5 Access Control (AC) field has no significance outside + the local 802.5 subnetwork, it is treated by this encapsulation as + the last octet of the three octet PAD field. It MAY be set to any + value by the sending bridge and MUST be ignored by the receiving + bridge. + + + + +Grossman & Heinanen Standards Track [Page 8] + +RFC 2684 Multiprotocol Over AALS September 1999 + + + Payload Format for Bridged FDDI PDUs + +-------------------------------+ + | LLC 0xAA-AA-03 | + +-------------------------------+ + | OUI 0x00-80-C2 | + +-------------------------------+ + | PID 0x00-04 or 0x00-0A | + +-------------------------------+ + | PAD 0x00-00-00 | + +-------------------------------+ + | Frame Control (1 octet) | + +-------------------------------+ + | MAC destination address | + +-------------------------------+ + | | + | (remainder of MAC frame) | + | | + +-------------------------------+ + | LAN FCS (if PID is 0x00-04) | + +-------------------------------+ + + Payload Format for Bridged 802.6 PDUs + +-------------------------------+ + | LLC 0xAA-AA-03 | + +-------------------------------+ + | OUI 0x00-80-C2 | + +-------------------------------+ + | PID 0x00-0B | + +---------------+---------------+ ------ + | Reserved | BEtag | Common + +---------------+---------------+ PDU + | BAsize | Header + +-------------------------------+ ------- + | MAC destination address | + +-------------------------------+ + | | + | (remainder of MAC frame) | + | | + +-------------------------------+ + | | + | Common PDU Trailer | + | | + +-------------------------------+ + + In bridged 802.6 PDUs, the presence of a CRC-32 is indicated by the + CIB bit in the header of the MAC frame. Therefore, the same PID + value is used regardless of the presence or absence of the CRC-32 in + the PDU. + + + +Grossman & Heinanen Standards Track [Page 9] + +RFC 2684 Multiprotocol Over AALS September 1999 + + + The Common Protocol Data Unit (PDU) Header and Trailer are conveyed + to allow pipelining at the egress bridge to an 802.6 subnetwork. + Specifically, the Common PDU Header contains the BAsize field, which + contains the length of the PDU. If this field is not available to + the egress 802.6 bridge, then that bridge cannot begin to transmit + the segmented PDU until it has received the entire PDU, calculated + the length, and inserted the length into the BAsize field. If the + field is available, the egress 802.6 bridge can extract the length + from the BAsize field of the Common PDU Header, insert it into the + corresponding field of the first segment, and immediately transmit + the segment onto the 802.6 subnetwork. Thus, the bridge can begin + transmitting the 802.6 PDU before it has received the complete PDU. + + Note that the Common PDU Header and Trailer of the encapsulated frame + should not be simply copied to the outgoing 802.6 subnetwork because + the encapsulated BEtag value may conflict with the previous BEtag + value transmitted by that bridge. + + An ingress 802.6 bridge can abort an AAL5 CPCS-PDU by setting its + Length field to zero. If the egress bridge has already begun + transmitting segments of the PDU to an 802.6 subnetwork and then + notices that the AAL5 CPCS-PDU has been aborted, it may immediately + generate an EOM cell that causes the 802.6 PDU to be rejected at the + receiving bridge. Such an EOM cell could, for example, contain an + invalid value in the Length field of the Common PDU Trailer. + + Payload Format for BPDUs + +-------------------------------+ + | LLC 0xAA-AA-03 | + +-------------------------------+ + | OUI 0x00-80-C2 | + +-------------------------------+ + | PID 0x00-0E | + +-------------------------------+ + | | + | BPDU as defined by | + | 802.1(d) or 802.1(g) | + | | + +-------------------------------+ + +6. VC Multiplexing + + VC Multiplexing creates a binding between an ATM VC and the type of + the network protocol carried on that VC. Thus, there is no need for + protocol identification information to be carried in the payload of + each AAL5 CPCS-PDU. This reduces payload overhead and can reduce + per-packet processing. VC multiplexing can improve efficiency by + reducing the number of cells needed to carry PDUs of certain lengths. + + + +Grossman & Heinanen Standards Track [Page 10] + +RFC 2684 Multiprotocol Over AALS September 1999 + + + For ATM PVCs, the type of the protocol to be carried over each PVC + MUST be determined by configuration. For ATM SVCs, the negotiations + specified in RFC 1755 [5] MUST be used. + +6.1. VC Multiplexing of Routed Protocols + + PDUs of routed protocols MUST be carried as the only content of the + Payload of the AAL5 CPCS-PDU. The format of the AAL5 CPCS-PDU + Payload field thus becomes: + + Payload Format for Routed PDUs + +-------------------------------+ + | . | + | Carried PDU | + | (up to 2^16 - 1 octets) | + | . | + | . | + +-------------------------------+ + +6.2. VC Multiplexing of Bridged Protocols + + PDUs of bridged protocols MUST be carried in the Payload of the AAL5 + CPCS-PDU exactly as described in section 5.2, except that only the + fields after the PID field MUST be included. The AAL5 CPCS-PDU + Payload field carrying a bridged PDU MUST, therefore, have one of the + following formats. + + Payload Format for Bridged Ethernet/802.3 PDUs + +-------------------------------+ + | PAD 0x00-00 | + +-------------------------------+ + | MAC destination address | + +-------------------------------+ + | | + | (remainder of MAC frame) | + | | + +-------------------------------+ + | LAN FCS (VC dependent option) | + +-------------------------------+ + + + + + + + + + + + + +Grossman & Heinanen Standards Track [Page 11] + +RFC 2684 Multiprotocol Over AALS September 1999 + + + Payload Format for Bridged 802.4/802.5/FDDI PDUs + +-------------------------------+ + | PAD 0x00-00-00 or 0x00-00-XX | + +-------------------------------+ + | Frame Control (1 octet) | + +-------------------------------+ + | MAC destination address | + +-------------------------------+ + | | + | (remainder of MAC frame) | + | | + +-------------------------------+ + | LAN FCS (VC dependent option) | + +-------------------------------+ + + Note that the 802.5 Access Control (AC) field has no significance + outside the local 802.5 subnetwork. It can thus be regarded as the + last octet of the three octet PAD field, which in case of 802.5 can + be set to any value (XX). + + Payload Format for Bridged 802.6 PDUs + +---------------+---------------+ ------- + | Reserved | BEtag | Common + +---------------+---------------+ PDU + | BAsize | Header + +-------------------------------+ ------- + | MAC destination address | + +-------------------------------+ + | | + | (remainder of MAC frame) | + | | + +-------------------------------+ + | | + | Common PDU Trailer | + | | + +-------------------------------+ + + Payload Format for BPDUs + +-------------------------------+ + | | + | BPDU as defined by | + | 802.1(d) or 802.1(g) | + | | + +-------------------------------+ + + + + + + + +Grossman & Heinanen Standards Track [Page 12] + +RFC 2684 Multiprotocol Over AALS September 1999 + + + In case of Ethernet, 802.3, 802.4, 802.5, and FDDI PDUs the presense + or absence of the trailing LAN FCS shall be identified implicitly by + the VC, since the PID field is not included. PDUs with the LAN FCS + and PDUs without the LAN FCS are thus considered to belong to + different protocols even if the bridged media type would be the same. + +7. Bridging in an ATM Network + + A bridge with an ATM interface that serves as a link to one or more + other bridge MUST be able to flood, forward, and filter bridged PDUs. + + Flooding is performed by sending the PDU to all possible appropriate + destinations. In the ATM environment this means sending the PDU + through each relevant VC. This may be accomplished by explicitly + copying it to each VC or by using a point-to-multipoint VC. + + To forward a PDU, a bridge MUST be able to associate a destination + MAC address with a VC. It is unreasonable and perhaps impossible to + require bridges to statically configure an association of every + possible destination MAC address with a VC. Therefore, ATM bridges + must provide enough information to allow an ATM interface to + dynamically learn about foreign destinations beyond the set of ATM + stations. + + To accomplish dynamic learning, a bridged PDU MUST conform to the + encapsulation described in section 5. In this way, the receiving ATM + interface will know to look into the bridged PDU and learn the + association between foreign destination and an ATM station. + +8. Virtual Private Network (VPN) identification + + The encapsulation defined in this section applies only to Virtual + Private Networks (VPNs) that operate over an ATM subnet. + + A mechanism for globally unique identification of Virtual Private + multiprotocol networks is defined in [11]. The 7-octet VPN-Id + consists of a 3-octet VPN-related OUI (IEEE 802-1990 Organizationally + Unique Identifier), followed by a 4-octet VPN index which is + allocated by the owner of the VPN-related OUI. Typically, the VPN- + related OUI value is assigned to a VPN service provider, which then + allocates VPN index values for its customers. + + + + + + + + + + +Grossman & Heinanen Standards Track [Page 13] + +RFC 2684 Multiprotocol Over AALS September 1999 + + +8.1 VPN Encapsulation Header + + The format of the VPN encapsulation header is as follows: + + VPN Encapsulation Header + +-------------------------------+ + | LLC 0xAA-AA-03 | + +-------------------------------+ + | OUI 0x00-00-5E | + +-------------------------------+ + | PID 0x00-08 | + +-------------------------------+ + | PAD 0x00 | + +-------------------------------+ + | VPN related OUI (3 octets) | + +-------------------------------+ + | VPN Index (4 octets) | + +-------------------------------+ + | | + | (remainder of PDU) | + | | + +-------------------------------+ + + When the encapsulation header is used, the remainder of the PDU MUST + be structured according to the appropiate format described in section + 5 or 6 (i.e., the VPN encapsulation header is prepended to the PDU + within an AAL5 CPCS SDU). + +8.2 LLC-encapsulated routed or bridged PDUs within a VPN + + When a LLC-encapsulated routed or bridged PDU is sent within a VPN + using ATM over AAL5, a VPN encapsulation header MUST be prepended to + the appropriate routed or bridged PDU format defined in sections 5.1 + and 5.2, respectively. + +8.3 VC multiplexing of routed or bridged PDUs within a VPN + + When a routed or bridged PDU is sent within a VPN using VC + multiplexing, the VPN identifier MAY either be specified a priori, + using ATM connection control signalling or adminstrative assignment + to an ATM interface, or it MAY be indicated using an encapsulation + header. + + If the VPN is identified using ATM connection control signalling, all + PDUs carried by the ATM VC are associated with the same VPN. In this + case, the payload formats of routed and bridged PDUs MUST be as + defined in sections 6.1 and 6.2, respectively. If a PDU is received + containing a VPN encapsulation header when the VPN has been + + + +Grossman & Heinanen Standards Track [Page 14] + +RFC 2684 Multiprotocol Over AALS September 1999 + + + identified using ATM signalling, the receiver MAY drop it and/or take + other actions which are implementation specific. Specification of + the mechanism in ATM connection control signalling for carrying VPN + identifiers is outside the scope of this Memo. + + If a VPN identifier is administratively assigned to an ATM interface, + then all PDUs carried by any ATM VCs within that interface are + associated with that VPN. In this case, the payload formats of + routed and bridged PDUs MUST be as defined in sections 6.1 and 6.2, + respectively. If a PDU is received containing a VPN encapsulation + header when the VPN identifier has been administratively assigned, + the receiver MAY drop it and/or take other actions which are + implementation specific. Specification of mechanisms (such as MIBs) + for assigning VPN identifiers to ATM interfaces is outside the scope + of this memo. + + If the VPN identifier is to be indicated using an encapsulation + header, then a VPN encapsulation header MUST be prepended to the + appropriate routed or bridged PDU format defined in sections 6.1 and + 6.2, respectively. + +9. Security Considerations + + This memo defines mechanisms for multiprotocol encapsulation over + ATM. There is an element of trust in any encapsulation protocol: a + receiver must trust that the sender has correctly identified the + protocol being encapsulated. There is no way to ascertain that the + sender did use the proper protocol identification (nor would this be + desirable functionality). The encapsulation mechanisms described in + this memo are believed not to have any other properties that might be + exploited by an attacker. However, architectures and protocols + operating above the encapsulation layer may be subject to a variety + of attacks. In particular, the bridging architecture discussed in + section 7 has the same vulnerabilities as other bridging + architectures. + + System security may be affected by the properties of the underlying + ATM network. The ATM Forum has published a security framework [12] + and a security specification [13] which may be relevant. + + + + + + + + + + + + +Grossman & Heinanen Standards Track [Page 15] + +RFC 2684 Multiprotocol Over AALS September 1999 + + +Acknowledgements + + This memo replaces RFC 1483, which was developed by the IP over ATM + working group, and edited by Juha Heinanen (then at Telecom Finland, + now at Telia). The update was developed in the IP-over-NBMA (ION) + working group, and Dan Grossman (Motorola) was editor and also + contributed to the work on RFC 1483. + + This material evolved from RFCs [1] and [4] from which much of the + material has been adopted. Thanks to their authors Terry Bradley, + Caralyn Brown, Andy Malis, Dave Piscitello, and C. Lawrence. Other + key contributors to the work included Brian Carpenter (CERN), Rao + Cherukuri (IBM), Joel Halpern (then at Network Systems), Bob Hinden + (Sun Microsystems, presently at Nokia), and Gary Kessler (MAN + Technology). + + The material concerning VPNs was developed by Barbara Fox (Lucent) + and Bernhard Petri (Siemens). + +References + + [1] Piscitello, D. and C. Lawrence, "The Transmission of IP + Datagrams over the SMDS Service", RFC 1209, March 1991. + + [2] ITU-T Recommendation I.363.5, "B-ISDN ATM Adaptation Layer (AAL) + Type 5 Specification", August 1996. + + [3] ITU-T Recommendation I.365.1, "Frame Relaying Service Specific + Convergence Sublayer (SSCS), November 1993. + + [4] Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame + Relay", RFC 2427, September 1998. + + [5] Perez M., Liaw, F., Mankin, E., Grossman, D. and A. Malis, "ATM + Signalling Support for IP over ATM", RFC 1755, February 1995. + + [6] Information technology - Telecommunications and Information + Exchange Between Systems, "Protocol Identification in the + Network Layer". ISO/IEC TR 9577, October 1990. + + [7] Postel, J. and J. Reynolds, "A Standard for the Transmission of + IP Datagrams over IEEE 802 Networks", STD 43, RFC 1042, February + 1988. + + [8] Maher, M., "IP over ATM Signalling - SIG 4.0 Update", RFC 2331, + April 1998. + + + + + +Grossman & Heinanen Standards Track [Page 16] + +RFC 2684 Multiprotocol Over AALS September 1999 + + + [9] ITU-T Recommendation I.555, "Frame Relay Bearer Service + Interworking", September 1997. + + [10] Bradner, S. "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [11] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", + RFC 2685, September 1999. + + [12] The ATM Forum, "ATM Security Framework Version 1.0", af-sec- + 0096.000, February 1998. + + [13] The ATM Forum, "ATM Security Specification v1.0", af-sec- + 0100.001, February 1999. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Grossman & Heinanen Standards Track [Page 17] + +RFC 2684 Multiprotocol Over AALS September 1999 + + +Appendix A. Multiprotocol Encapsulation over FR-SSCS + + ITU-T Recommendation I.365.1 defines a Frame Relaying Specific + Convergence Sublayer (FR- SSCS) to be used on the top of the Common + Part Convergence Sublayer CPCS) of the AAL type 5 for Frame Relay/ATM + interworking. The service offered by FR-SSCS corresponds to the Core + service for Frame Relaying as described in I.233. + + An FR-SSCS-PDU consists of Q.922 Address field followed by Q.922 + Information field. The Q.922 flags and the FCS are omitted, since + the corresponding functions are provided by the AAL. The figure + below shows an FR-SSCS-PDU embedded in the Payload of an AAL5 CPCS- + PDU. + + FR-SSCS-PDU in Payload of AAL5 CPCS-PDU + +-------------------------------+ ------- + | Q.922 Address Field | FR-SSCS-PDU Header + | (2-4 octets) | + +-------------------------------+ ------- + | . | + | . | + | Q.922 Information field | FR-SSCS-PDU Payload + | . | + | . | + +-------------------------------+ ------- + | AAL5 CPCS-PDU Trailer | + +-------------------------------+ + + Routed and bridged PDUs are encapsulated inside the FR-SSCS-PDU as + defined in RFC 2427. The Q.922 Information field starts with a Q.922 + Control field followed by an optional Pad octet that is used to align + the remainder of the frame to a convenient boundary for the sender. + The protocol of the carried PDU is then identified by prefixing the + PDU by an ISO/IEC TR 9577 Network Layer Protocol ID (NLPID). + + + + + + + + + + + + + + + + + +Grossman & Heinanen Standards Track [Page 18] + +RFC 2684 Multiprotocol Over AALS September 1999 + + + In the particular case of an IP PDU, the NLPID is 0xCC and the FR- + SSCS-PDU has the following format: + + FR-SSCS-PDU Format for Routed IP PDUs + +-------------------------------+ + | Q.922 Addr Field | + | (2 or 4 octets) | + +-------------------------------+ + | 0x03 (Q.922 Control) | + +-------------------------------+ + | NLPID 0xCC | + +-------------------------------+ + | . | + | IP PDU | + | (up to 2^16 - 5 octets) | + | . | + +-------------------------------+ + + Note that according to RFC 2427, the Q.922 Address field MUST be + either 2 or 4 octets, i.e., a 3 octet Address field MUST NOT be used. + + In the particular case of a CLNP PDU, the NLPID is 0x81 and the FR- + SSCS-PDU has the following format: + + FR-SSCS-PDU Format for Routed CLNP PDUs + +-------------------------------+ + | Q.922 Addr Field | + | (2 or 4 octets) | + +-------------------------------+ + | 0x03 (Q.922 Control) | + +-------------------------------+ + | NLPID 0x81 | + +-------------------------------+ + | . | + | Rest of CLNP PDU | + | (up to 2^16 - 5 octets) | + | . | + +-------------------------------+ + + Note that in case of ISO protocols the NLPID field forms the first + octet of the PDU itself and MUST not be repeated. + + The above encapsulation applies only to those routed protocols that + have a unique NLPID assigned. For other routed protocols (and for + bridged protocols), it is necessary to provide another mechanism for + easy protocol identification. This can be achieved by using an NLPID + value 0x80 to indicate that an IEEE 802.1a SubNetwork Attachment + Point (SNAP) header follows. + + + +Grossman & Heinanen Standards Track [Page 19] + +RFC 2684 Multiprotocol Over AALS September 1999 + + + See RFC 2427 for more details related to multiprotocol encapsulation + over FRCS. + +Appendix B. List of Locally Assigned values of OUI 00-80-C2 + + with preserved FCS w/o preserved FCS Media + ------------------ ----------------- -------------- + 0x00-01 0x00-07 802.3/Ethernet + 0x00-02 0x00-08 802.4 + 0x00-03 0x00-09 802.5 + 0x00-04 0x00-0A FDDI + 0x00-05 0x00-0B 802.6 + 0x00-0D Fragments + 0x00-0E BPDUs + +Appendix C. Partial List of NLPIDs + + 0x00 Null Network Layer or Inactive Set (not used with ATM) + 0x80 SNAP + 0x81 ISO CLNP + 0x82 ISO ESIS + 0x83 ISO ISIS + 0xCC Internet IP + +Appendix D. Applications of multiprotocol encapsulation + + Mutiprotocol encapsulation is necessary, but generally not + sufficient, for routing and bridging over the ATM networks. Since + the publication of RFC 1483 (the predecessor of this memo), several + system specifications were developed by the IETF and the ATM Forum to + address various aspects of, or scenarios for, bridged or routed + protocols. This appendix summarizes these applications. + + 1) Point-to-point connection between routers and bridges -- + multiprotocol encapsulation over ATM PVCs has been used to provide + a simple point-to-point link between bridges and routers across an + ATM network. Some amount of manual configuration (e.g., in lieu + of INARP) was necessary in these scenarios. + + 2) Classical IP over ATM -- RFC 2225 (formerly RFC 1577) provides an + environment where the ATM network serves as a logical IP subnet + (LIS). ATM PVCs are supported, with address resolution provided by + INARP. For ATM SVCs, a new form of ARP, ATMARP, operates over the + ATM network between a host (or router) and an ATMARP server. + Where servers are replicated to provide higher availability or + performance, a Server Synchronization Cache Protocol (SCSP) + defined in RFC 2335 is used. Classical IP over ATM defaults to the + LLC/SNAP encapsulation. + + + +Grossman & Heinanen Standards Track [Page 20] + +RFC 2684 Multiprotocol Over AALS September 1999 + + + 3) LAN Emulation -- The ATM Forum LAN Emulation specification + provides an environment where the ATM network is enhanced by LAN + Emulation Server(s) to behave as a bridged LAN. Stations obtain + configuration information from, and register with, a LAN Emulation + Configuration Server; they resolve MAC addresses to ATM addresses + through the services of a LAN Emulation Server; they can send + broadcast and multicast frames, and also send unicast frames for + which they have no direct VC to a Broadcast and Unicast Server. + LANE uses the VC multiplexing encapsulation foramts for Bridged + Etherent/802.3 (without LAN FCS) or Bridged 802.5 (without LAN + FCS) for the Data Direct, LE Multicast Send and Multicast Forward + VCCS. However, the initial PAD field described in this memo is + used as an LE header, and might not be set to all '0'. + + 4) Next Hop Resolution Protocol (NHRP) -- In some cases, the + constraint that Classical IP over ATM serve a single LIS limits + performance. NHRP, as defined in RFC 2332, extends Classical to + allow 'shortcuts' over a an ATM network that supports several + LISs. + + 5) Multiprotocol over ATM (MPOA) -- The ATM Forum Multiprotocol over + ATM Specification integrates LANE and NHRP to provide a generic + bridging/routing environment. + + 6) IP Multicast -- RFC 2022 extends Classical IP to support IP + multicast. A multicast address resolution server (MARS) is used + possibly in conjunction with a multicast server to provide IP + multicast behavior over ATM point-to-multipoint and/or point to + point virtual connections. + + 7) PPP over ATM -- RFC 2364 extends multiprotocol over ATM to the + case where the encapsulated protocol is the Point-to-Point + protocols. Both the VC based multiplexing and LLC/SNAP + encapsulations are used. This approach is used when the ATM + network is used as a point-to-point link and PPP functions are + required. + +Appendix E Differences from RFC 1483 + + This memo replaces RFC 1483. It was intended to remove anachronisms, + provide clarifications of ambiguities discovered by implementors or + created by changes to the base standards, and advance this work + through the IETF standards track process. A number of editorial + improvements were made, the RFC 2119 [10] conventions applied, and + the current RFC boilerplate added. The following substantive changes + were made. None of them is believed to obsolete implementations of + RFC 1483: + + + + +Grossman & Heinanen Standards Track [Page 21] + +RFC 2684 Multiprotocol Over AALS September 1999 + + + -- usage of NLPID encapsulation is clarified in terms of the RFC 2119 + conventions + + -- a pointer to RFC 2364 is added to cover the case of PPP over ATM + + -- RFC 1755 and RFC 2331 are referenced to describe how + encapsulations are negotiated, rather than a long-obsolete CCITT + (now ITU-T) working document and references to work then in + progress + + -- usage of AAL5 is now a reference to ITU-T I.363.5. Options + created in AAL5 since the publication of RFC 1483 are selected. + + -- formatting of routed NLPID-formatted PDUs (which are called + "routed ISO PDUs" + in RFC 1483) is clarified + + -- clarification is provided concerning the use of padding between + the PID and MAC destination address in bridged PDUs and the bit + ordering of the MAC address. + + -- clarification is provided concerning the use of padding of + Ethernet/802.3 frames + + -- a new encapuslation for VPNs is added + + -- substantive security considerations were added + + -- a new appendix D provides a summary of applications of + multiprotocol over ATM + +Authors' Addresses + + Dan Grossman + Motorola, Inc. + 20 Cabot Blvd. + Mansfield, MA 02048 + + EMail: dan@dma.isg.mot.com + + + Juha Heinanen + Telia Finland + Myyrmaentie 2 + 01600 Vantaa, Finland + + EMail: jh@telia.fi + + + + +Grossman & Heinanen Standards Track [Page 22] + +RFC 2684 Multiprotocol Over AALS September 1999 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Grossman & Heinanen Standards Track [Page 23] + |