rfc2364.txt

RFC 的详细文档！

Network Working Group                                           G. Gross
Request for Comments: 2364                           Lucent Technologies
Category: Standards Track                                      M. Kaycee
                                                                Paradyne
                                                                  A. Lin
                                                         Shasta Networks
                                                                A. Malis
                                                   Ascend Communications
                                                             J. Stephens
                                                          Cayman Systems
                                                               July 1998


                             PPP Over AAL5

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 (1998).  All Rights Reserved.

Abstract

   The Point-to-Point Protocol (PPP) [1] provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.

   This document describes the use of ATM Adaptation Layer 5 (AAL5) for
   framing PPP encapsulated packets.

Applicability

   This specification is intended for those implementations which desire
   to use the facilities which are defined for PPP, such as the Link
   Control Protocol, Network-layer Control Protocols, authentication,
   and compression.  These capabilities require a point-to-point
   relationship between the peers, and are not designed for the multi-
   point relationships which are available in ATM and other multi-access
   environments.







Gross, et. al.              Standards Track                     [Page 1]

RFC 2364                     PPP Over AAL5                     July 1998


1. Introduction

   ATM AAL5 protocol is designed to provide virtual connections between
   end stations attached to the same network.  These connections offer a
   packet delivery service that includes error detection, but does not
   do error correction.

   Most existing implementations of PPP use ISO 3309 HDLC as a basis for
   their framing [3].

   When an ATM network is configured with point-to-point connections,
   PPP can use AAL5 as a framing mechanism.

2. Conventions

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [10].

3. AAL5 Layer Service Interface

   The PPP layer treats the underlying ATM AAL5 layer service as a bit-
   synchronous point-to-point link.  In this context, the PPP link
   corresponds to an ATM AAL5 virtual connection.  The virtual
   connection MUST be full-duplex, point to point, and it MAY be either
   dedicated (i.e. permanent, set up by provisioning) or switched (set
   up on demand).  In addition, the PPP/AAL5 service interface boundary
   MUST meet the following requirements:

        Interface Format - The PPP/AAL5 layer boundary presents an octet
        service interface to the AAL5 layer.  There is no provision for
        sub-octets to be supplied or accepted.

        Transmission Rate - The PPP layer does not impose any
        restrictions regarding transmission rate or the underlying ATM
        layer traffic descriptor parameters.

        Control Signals - The AAL5 layer MUST provide control signals to
        the PPP layer which indicate when the virtual connection link
        has become connected or disconnected.  These provide the "Up"
        and

        "Down" events to the LCP state machine [1] within the PPP layer.








Gross, et. al.              Standards Track                     [Page 2]

RFC 2364                     PPP Over AAL5                     July 1998


4. Multi-Protocol Encapsulation

   This specification uses the principles, terminology, and frame
   structure described in "Multiprotocol Encapsulation over ATM
   Adaptation Layer 5" [4].

   The purpose of this specification is not to document what is already
   standardized in [4], but to specify how the mechanisms described in
   [4] are to be used to map PPP onto an AAL5-based  ATM network.
   Section 1 within [4] defines the two mechanisms for identifying the
   Protocol Data Unit (PDU) payload field's protocol type: virtual
   circuit based multiplexing, and Logical Link Control (LLC)
   encapsulation.  In the former technique, the payload's protocol type
   is implicitly agreed to by the end points for each virtual circuit
   using provisioning or control plane procedures.  When using the LLC
   encapsulation technique, the payload's protocol type is explicitly
   identified on a per PDU basis by an in-band LLC header, followed by
   the payload data.

   When transporting a PPP payload over AAL5, an implementation:

        1. MUST support virtual circuit multiplexed PPP payloads as
        described in section 5 below by mutual configuration or
        negotiation of both end points.  This technique is referred to
        as "VC-multiplexed PPP".

        2. MUST support LLC encapsulated PPP payloads on PVCs as
        described in section 6 below by mutual configuration or
        negotiation of both end points.  This technique is referred to
        as "LLC encapsulated PPP".

        3. For SVC set up, an implementation MUST negotiate using the
        Q.2931 [9] Annex C procedure, encoding the Broadband Lower Layer
        Interface (B-LLI) information element to signal either VC-
        multiplexed PPP or LLC encapsulated PPP.  The details of this
        control plane procedure are described in section 7.

   If an implementation is connecting through a Frame Relay/ATM FRF.8
   [7] service inter-working unit to an RFC 1973 [6] end point, then it
   MUST use LLC encapsulated PPP payloads.  Frame Relay/ATM FRF.8
   inter-working units are exempted from the requirement to support VC-
   multiplexed PPP.  This exemption allows the FR/ATM IWU to remain
   compliant with FRF.8 when the PPP over AAL5 end point is inter-
   operating with an RFC 1973 end point.







Gross, et. al.              Standards Track                     [Page 3]

RFC 2364                     PPP Over AAL5                     July 1998


5. Virtual Circuit Multiplexed PPP Over AAL5

   The AAL5 PDU format is shown in figure 1:

                        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)        |    V
                  +-------------------------------+ -------
                                   Figure 1

   The Common Part Convergence Sub-layer (CPCS)-PDU 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.

   The CPCS-UU (User-to-User indication) field is used to transparently
   transfer CPCS user to user information.  The field has no function
   under the multi-protocol ATM encapsulation described in this memo and
   can be set to any value.

   The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer to
   64 bits.  Possible additional functions are for further study in
   ITU-T.  When only the 64 bit alignment function is used, this field
   shall 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 protects the entire CPCS-PDU except the CRC field
   itself.




Gross, et. al.              Standards Track                     [Page 4]

RFC 2364                     PPP Over AAL5                     July 1998


   A VC-multiplexed PPP frame SHALL constitute the CPCS-PDU payload and
   is defined as:

               +-------------+-------------+---------+
               | Protocol ID | Information | Padding |
               |  8/16 bits  |             |         |
               +-------------+-------------+---------+
                                Figure 2

   Each of these fields are specifically defined in [1].

6. LLC Encapsulated PPP Over AAL5

   LLC encapsulated PPP over AAL5 is the alternative technique to VC-
   multiplexed PPP over AAL5.

   The AAL5 CPCS-PDU payload  field is encoded as shown in figure 3.
   The pertinent fields in that diagram are:

        1. LLC header: 2 bytes encoded to specify a source SAP and
        destination SAP of routed OSI PDU (values 0xFE 0xFE), followed
        by an Un-numbered Information (UI) frame type (value 0x03).

        2. Network Layer Protocol IDentifier (NLPID) representing PPP,
        (value 0xCF).

        3. the PPP protocol identifier field, which can be either 1 or 2
        octets long.  See reference [1].

        4. followed by the PPP information field as per Figure 2.





















Gross, et. al.              Standards Track                     [Page 5]

RFC 2364                     PPP Over AAL5                     July 1998


                  +-------------------------+ --------
                  |  Destination SAP (0xFE) |     ^
                  +-------------------------+     |
                  |  Source SAP (0xFE)      | LLC header
                  +-------------------------+     |
                  |  Frame Type = UI (0x03) |     V
                  +-------------------------+ --------
                  |  NLPID = PPP (0xCF)     |
                  +-------------------------+ --------
                  |   Protocol Identifier   |     ^
                  |     (8 or 16 bits)      |     |
                  +-------------------------+ PPP payload
                  |          .              |     |
                  |          .              |     |
                  |  PPP information field  |     |
                  |          .              |     |
                  |          .              |     |
                  +-------------------------+     |
                  |        padding          |     V
                  +-------------------------+ --------
                  |  PAD ( 0 - 47 octets)   |
                  +-------------------------+ --------
                  |  CPCS-UU (1 octet )     |     ^
                  +-------------------------+     |
                  |    CPI (1 octet )       |     |
                  +-------------------------+CPCS-PDU Trailer
                  |   Length (2 octets)     |     |
                  +-------------------------|     |
                  |    CRC (4 octets)       |     V
                  +-------------------------+ --------


                             Figure 3

   The end points MAY be bi-laterally provisioned to send other LLC-
   encapsulated protocols besides PPP across the same virtual
   connection.  However, they MUST NOT send packets belonging to any
   protocol that has an active NCP within the PPP session.
   Implementations SHOULD do packet scheduling that minimizes the
   performance impact on the quality of service commitments associated
   with both the LLC-encapsulated PPP and non-PPP protocol flows.

7. Out-Of-Band Control Plane Signaling

   When originating a switched virtual circuit AAL5 connection, the
   caller MUST request in the SETUP message either VC-multiplexed PPP,
   LLC-encapsulated PPP, or else both VC-multiplexed and LLC-
   encapsulated PPP.  When a caller is offering both techniques, the two



Gross, et. al.              Standards Track                     [Page 6]