rfc2684.txt

RFC 的详细文档！

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