diff options
Diffstat (limited to 'doc/rfc/rfc2364.txt')
| -rw-r--r-- | doc/rfc/rfc2364.txt | 675 |
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc2364.txt b/doc/rfc/rfc2364.txt new file mode 100644 index 0000000..087acd3 --- /dev/null +++ b/doc/rfc/rfc2364.txt @@ -0,0 +1,675 @@ + + + + + + +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] + |