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
`
`http://www.ietf.org/rfc/rfc2364[7/8/2011 8:29:13 PM]
`
`Petitioner RPX Corporation - Ex. 1037, p. 1
`
`

`

` 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.
`
`http://www.ietf.org/rfc/rfc2364[7/8/2011 8:29:13 PM]
`
`Petitioner RPX Corporation - Ex. 1037, p. 2
`
`

`

`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-
`
`http://www.ietf.org/rfc/rfc2364[7/8/2011 8:29:13 PM]
`
`Petitioner RPX Corporation - Ex. 1037, p. 3
`
`

`

` 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
`
`http://www.ietf.org/rfc/rfc2364[7/8/2011 8:29:13 PM]
`
`Petitioner RPX Corporation - Ex. 1037, p. 4
`
`

`

` 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
`
`http://www.ietf.org/rfc/rfc2364[7/8/2011 8:29:13 PM]
`
`Petitioner RPX Corporation - Ex. 1037, p. 5
`
`

`

` 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.
`
`http://www.ietf.org/rfc/rfc2364[7/8/2011 8:29:13 PM]
`
`Petitioner RPX Corporation - Ex. 1037, p. 6
`
`

`

` [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.
`
`http://www.ietf.org/rfc/rfc2364[7/8/2011 8:29:13 PM]
`
`Petitioner RPX Corporation - Ex. 1037, p. 7
`
`

`

` 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.
`
`http://www.ietf.org/rfc/rfc2364[7/8/2011 8:29:13 PM]
`
`Petitioner RPX Corporation - Ex. 1037, p. 8
`
`