GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2364

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] RFC 2364 PPP Over AAL5 July 1998

 B-LLI IEs are encoded within a Broadband Repeat Indicator IE in the
 order of their preference.  The called implementation MUST be able to
 accept an incoming call that offers LLC-encapsulated PPP in the
 caller's request.  The called implementation MUST reject a call set
 up request that only offers an encapsulation that it does not
 support.  Implementations originating a call offering both protocol
 encapsulation techniques MUST be able to negotiate the use of LLC-
 encapsulated PPP.
 When originating a virtual circuit multiplexed call that is to carry
 a PPP payload, the ITU Q.2931 [9] B-LLI element user information
 layer 3 protocol field is encoded to select ISO/IEC TR 9577 [5] in
 octet 7.  The extension octets specify an IPI value of PPP (0xCF).
 By definition, the first bytes of the AAL5 frame's payload field will
 always contain a PPP header followed by a packet.
 When originating an LLC encapsulated call that is to carry a PPP
 payload, the ITU Q.2931 B-LLI element user information layer 2
 protocol field is encoded to select LAN Logical Link Control
 (ISO/IEC8802-2) in octet 6.  See RFC 1755 [8] appendix A for an
 example.  By definition, the first bytes of the AAL5 frame's payload
 field will contain an LLC header, followed by a NLPID and the PPP
 payload.

8. Detection And Recovery From Unsolicited PPP Encapsulation Transitions

 When the virtual connection loses state, the PPP encapsulation
 technique may uni-laterally and unexpectedly change across such
 transitions.  Detection and recovery procedures are defined for the
 following state transitions:
      VC-multiplexed PPP changing to LLC encapsulated PPP
      LLC encapsulated PPP changing to VC-multiplexed PPP
 When LLC-encapsulated PPP is being used, the inital 6 octets of the
 LCP packets contain the sequence: fe-fe-03-cf-c0-21.  This sequence
 constitutes the first 6 octets of the AAL5 frame.  In the case of
 VC-multiplexed PPP, initial LCP packets contain the sequence c0-21.
 This sequence constitutes the first 2 octets of an AAL5 frame.  When
 a LCP Configure-Request packet is received and recognized, the PPP
 link enters Link Establishment phase.
 Once PPP has entered the Network-layer Protocol phase, and
 successfully negotiated a particular NCP for a PPP Protocol, if a
 frame arrives using an alternate but equivalent data encapsulation as
 defined in [4], then the PPP Link MUST:

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

      For a SVC, immediately clear the call with the cause value 111,
      "protocol error, unspecified".
      For a PVC: tear down the active NCPs, SHOULD generate an error
      message, enter the Termination state, and silently drop all
      received packets.
 These policies prevent "black-holes" that occur when the peer loses
 state.  An implementation which requires PPP link configuration, and
 other PPP negotiated features (such as authentication), MAY enter
 Termination state when configuration fails.

9. LCP Configuration Options

 The Magic Number LCP configuration option is RECOMMENDED, and the
 Protocol Field Compression (PFC) option is NOT RECOMMENDED.  An
 implementation MUST NOT request any of the following options, and
 MUST reject a request for such an option:
      Field Check Sequence (FCS) Alternatives,
      Address-and-Control-Field-Compression (ACFC),
      Asynchronous-Control-Character-Map (ACCM)
 The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a
 larger size than the maximum CPCS-SDU size specified in the
 associated direction for the virtual connection's traffic contract.
 When viewed peer to peer, a PPP link may be bridged over multiple
 physical layer sections.  For each such AAL5 section, the LCP framing
 options MUST be actively negotiated by the bridging convertors
 independently of the LCP framing options in use by other physical
 layer sections.
 Implementation Note:
      When an ATM AAL5 PVC is in the "Stopped" state, it is
      RECOMMENDED that the implementation wait for Configure-Requests.
      See the implementation option in reference [1] section 4.2, the
      "Stopped State" sub-section.

10. Security Considerations

 Generally, ATM networks are virtual circuit based, and security is
 implicit in the public data networking service provider's
 administration of Permanent Virtual Circuits (PVCs) between the
 network boundaries.  The probability of a security breach caused by
 mis-routed ATM cells is considered to be negligible.

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

 When a public ATM network supports Switched Virtual Circuits, the
 protocol model becomes analogous to traditional voice band modem dial
 up over the Public Telephone Switched Network (PTSN).  The same
 PAP/CHAP authentication protocols that are already widely in use for
 Internet dial up access are leveraged.  As a consequence, PPP over
 AAL5 security is at parity with those practices already established
 by the existing Internet infrastructure.
 Those applications that require stronger security are encouraged to
 use authentication headers, or encrypted payloads, and/or ATM-layer
 security services.
 When using LLC-encapsulated PPP over a virtual connection, an end
 point can not assume that the PPP session authentication and related
 security mechanisms also secure the other LLC encapsulated flows on
 that same virtual connection.

11. Acknowledgments

 This design is based on work performed in ADSL Forum's Packet Mode
 Working Group.  It is inspired by  "PPP in Frame Relay", RFC 1973, by
 William Simpson.  Special thanks to Phil Rakity of Flowpoint, Tim
 Kwok of Microsoft, and David Allan of Nortel for their constructive
 review and commentary.

12. References

 [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
       51, RFC 1661, July 1994.
 [2]   The ATM Forum, "Frame based User-to-Network Interface (FUNI)
       Specification v2", af-saa-0088.000, May 1997.
 [3]   Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, RFC
       1662, July 1994.
 [4]   Heinanen, J., "Multiprotocol Interconnect over AAL5", RFC 1483,
       July 1993.
 [5]   ISO/IEC DTR 9577.2, "Information technology -
       Telecommunications and Information exchange between systems -
       Protocol Identification in the network layer", 1995-08-16.
 [6]   Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996.
 [7]   The Frame Relay Forum, "Frame Relay/ATM PVC Service Inter-
       working Implementation Agreement", FRF.8, April 1995.

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

 [8]   Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D., and
       A. Malis, "ATM Signaling Support for IP over ATM", RFC 1755,
       February 1995.
 [9]   International Telecommunication Union, "Broadband Integrated
       Service Digital Network (B-ISDN) Digital Subscriber Signaling
       System No.2 (DSS2) User Network Interface Layer 3 Specification
       for Basic Call/Connection Control", ITU-T Recommendation
       Q.2931, (International Telecommunication Union: Geneva, 2/95)
 [10]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

Chair's Address

 The working group can be contacted via the current chair:
 Karl Fox
 Ascend Communications
 3518 Riverside Drive, Suite 101
 Columbus, Ohio 43221
 EMail: karl@ascend.com

Authors' Addresses

 Questions about this memo can also be directed to:
 George Gross
 Lucent Technologies, Inc
 184 Liberty Corner Road
 Warren, NJ 07059
 Phone:   +1.908.580.4589
 EMail: gmgross@lucent.com
 Manu Kaycee
 Paradyne Corporation
 21 Bear Meadow Road
 Londonderry, NH 03053-2168
 Phone: +1.603.434.6088
 EMail: mjk@nj.paradyne.com

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

 Arthur Lin
 Shasta Networks Inc.
 249 Humboldt Court
 Sunnyvale, CA 94089-1300
 Phone: +1.408.747.5051
 EMail: alin@shastanets.com
 Andrew Malis
 Ascend Communications, Inc.
 1 Robbins Road
 Westford, MA 01886
 Phone: +1.978.952.7414
 EMail: malis@ascend.com
 John Stephens
 Cayman Systems, Inc.
 100 Maple Street
 Stoneham, MA 02180
 Phone: +1.617.279.1101
 EMail: john@cayman.com

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

Full Copyright Statement

 Copyright (C) The Internet Society (1998).  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.

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

/data/webs/external/dokuwiki/data/pages/rfc/rfc2364.txt · Last modified: 1998/07/01 16:01 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki