idnits 2.17.1 draft-ietf-pppext-aal5-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 69: '...to point, and it MAY be either dedicat...' RFC 2119 keyword, line 71: '...rvice interface boundary MUST meet the...' RFC 2119 keyword, line 106: '... 1. MUST support virtual circuit m...' RFC 2119 keyword, line 110: '... 2. MAY use LLC encapsulated PPP ...' RFC 2119 keyword, line 116: '... then it MUST support LLC encapsul...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 190 has weird spacing: '...payload field...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 25, 1997) is 9772 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 313, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 1483 (ref. '4') (Obsoleted by RFC 2684) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPP Extensions Working Group Manu Kaycee, Paradyne 3 INTERNET DRAFT George Gross, Lucent Technologies 4 Expires February 25, 1998 Arthur Lin, Cisco Systems 5 Andrew Malis, Ascend Communications 6 John Stephens, Cayman Systems 7 July 25, 1997 9 PPP Over AAL5 11 13 Status Of This Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, and 17 its working groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as ``work in progress.'' 25 To learn the current status of any Internet-Draft, please check the 26 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Distribution of this memo is unlimited. 33 Abstract 35 The Point-to-Point Protocol (PPP) [1] provides a standard method 36 for transporting multi-protocol datagrams over point-to-point 37 links. 39 This document describes the use of ATM Adaptation Layer 5 (AAL5) 40 for framing PPP encapsulated packets. 42 Applicability 43 This specification is intended for those implementations which desire to 44 use the facilities which are defined for PPP, such as the Link Control 45 Protocol, Network-layer Control Protocols, authentication, and 46 compression. These capabilities require a point-to-point relationship 47 between the peers, and are not designed for the multi-point 48 relationships which are available in ATM and other multi-access 49 environments. 51 1. Introduction 53 ATM AAL5 protocol is designed to provide virtual connections between end 54 stations attached to the same network. These connections offer a packet 55 delivery service that includes error detection, but does not do error 56 correction. 58 Most existing implementations of PPP use ISO 3309 HDLC as a basis for 59 their framing [3]. 61 When an ATM network is configured with point-to-point connections, PPP 62 can use AAL5 as a framing mechanism, ignoring its other features. 64 2. AAL5 Layer Service Interface 66 The PPP layer treats the underlying ATM AAL5 layer service as a bit- 67 synchronous point-to-point link. In this context, the PPP link 68 corresponds to an ATM AAL5 virtual connection. The virtual connection 69 MUST be full-duplex, point to point, and it MAY be either dedicated 70 (i.e. permanent, set up by provisioning) or switched (set up on demand). 71 In addition, the PPP/AAL5 service interface boundary MUST meet the 72 following requirements: 74 Interface Format - The PPP/AAL5 layer boundary presents an octet 75 service interface to the AAL5 layer. There is no provision for 76 sub-octets to be supplied or accepted. 78 Transmission Rate - The PPP layer does not impose any restrictions 79 regarding transmission rate. 81 Control Signals - The AAL5 layer must provide control signals to 82 the PPP layer which indicate when the virtual connection link has 83 become connected or disconnected. These provide the "Up" and 84 "Down" events to the LCP state machine [1] within the PPP layer. 86 3. Multi-Protocol Encapsulation 88 This specification uses the principles, terminology, and frame structure 89 described in "Multiprotocol Encapsulation over ATM Adaptation Layer 5" 90 [4]. 92 The purpose of this specification is not to document what is already 93 standardized in [4], but to specify how the mechanisms described in [4] 94 are to be used to map PPP onto an AAL5-based ATM network. Section 1 95 within [4] defines the two mechanisms for identifying the Protocol Data 96 Unit (PDU) payload field's protocol type: virtual circuit based 97 multiplexing, and Logical Link Control (LLC) encapsulation. In the 98 former technique, the payload's protocol type is implicitly agreed to by 99 the end points for each virtual circuit using provisioning or control 100 plane procedures. When using the LLC encapsulation technique, the 101 payload's protocol type is explicitly identified on a per PDU basis by 102 an in-band LLC header, followed by the payload data. 104 When transporting a PPP payload over AAL5, an implementation: 106 1. MUST support virtual circuit multiplexed PPP payloads as 107 described in section 4. This technique is referred to as "VC- 108 multiplexed PPP". 110 2. MAY use LLC encapsulated PPP payloads on PVCs as described in 111 section 5 below by mutual configuration or negotiation of both end 112 points. This technique is referred to as "LLC encapsulated PPP". 114 3. If an implementation is connecting though a Frame Relay/ATM 115 FRF.8 [7] service inter-working unit to an RFC 1973 [6] end point, 116 then it MUST support LLC encapsulated PPP payloads. 118 4. For SVC set up, an implementation MUST negotiate using the 119 Q.2931 [9] Annex C procedure, encoding the Broadband Lower Layer 120 Interface (B-LLI) information element to signal either VC- 121 multiplexed PPP or LLC encapsulated PPP. The details of this 122 control plane procedure are described in section 6. 124 4. Virtual Circuit Multiplexed PPP Over AAL5 126 The AAL5 PDU format is shown in figure 1: 128 AAL5 CPCS-PDU Format 129 +-------------------------------+ 130 | . | 131 | . | 132 | CPCS-PDU Payload | 133 | up to 2^16 - 1 octets) | 134 | . | 135 | . | 136 +-------------------------------+ 137 | PAD ( 0 - 47 octets) | 138 +-------------------------------+ ------- 139 | CPCS-UU (1 octet ) | 140 +-------------------------------+ 141 | CPI (1 octet ) | 142 +-------------------------------+CPCS-PDU Trailer 143 | Length (2 octets) | 144 +-------------------------------| 145 | CRC (4 octets) | 146 +-------------------------------+ ------- 147 Figure 1 149 The Common Part Convergence Sub-layer (CPCS)-PDU Payload field contains 150 user information up to 2^16 - 1 octets. 152 The PAD field pads the CPCS-PDU to fit exactly into the ATM cells such 153 that the last 48 octet cell payload created by the SAR sublayer will 154 have the CPCS-PDU Trailer right justified in the cell. 156 The CPCS-UU (User-to-User indication) field is used to transparently 157 transfer CPCS user to user information. The field has no function under 158 the multi-protocol ATM encapsulation described in this memo and can be 159 set to any value. 161 The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer to 64 162 bits. Possible additional functions are for further study in ITU-T. 163 When only the 64 bit alignment function is used, this field shall be 164 coded as 0x00. 166 The Length field indicates the length, in octets, of the Payload field. 167 The maximum value for the Length field is 65535 octets. A Length field 168 coded as 0x00 is used for the abort function. 170 The CRC field protects the entire CPCS-PDU except the CRC field itself. 172 A VC-multiplexed PPP frame SHALL constitute the CPCS-PDU payload and is 173 defined as: 175 +----------+-------------+---------+ 176 | Protocol | Information | Padding | 177 | 8/16 bits| | | 178 +----------+-------------+---------+ 179 Figure 2 181 Each of these fields are specifically defined in [1]. 183 5. LLC Encapsulated PPP Over AAL5 185 LLC encapsulated PPP over AAL5 is the alternative technique to VC- 186 multiplexed PPP over AAL5. LLC encapsulated PPP minimizes the ATM/Frame 187 Relay inter-working translation complexity that occurs when a VCC is 188 connected to an RFC 1973 compliant end point. 190 The AAL5 CPCS-PDU payload field is encoded as shown in figure 3: 192 +-------------------------+ -------- 193 | Source SAP (0xFE) | ^ 194 +-------------------------+ | 195 | Destination SAP (0xFE) | LLC header 196 +-------------------------+ | 197 | Frame Type = UI (0x03) | V 198 +-------------------------+ -------- 199 | NLPID = PPP (0xCF) | 200 +-------------------------+ -------- 201 | Protocol Identifier | ^ 202 | (8 or 16 bits) | | 203 +-------------------------+ PPP payload 204 | . | | 205 | . | | 206 | PPP information field | | 207 | . | | 208 | . | V 209 +-------------------------+ -------- 211 Figure 3 213 The fields in the above diagram are: 215 1. LLC header: 2 bytes encoded to specify a source SAP and 216 destination SAP of non-OSI routed PDU (values 0xFE 0xFE), followed 217 by an Un-numbered Information (UI) frame type (value 0x03). 219 2. Network Layer Protocol IDentifier (NLPID) representing PPP, 220 (value 0xCF). 222 3. the PPP protocol identifier field, which can be either 1 or 2 223 octets long. 225 4. followed by the PPP information field. 227 6. Out-Of-Band Control Plane Signaling 229 When originating a switched virtual circuit AAL5 connection, the caller 230 MUST request in the SETUP message either one or else both of the RFC1483 231 protocol encapsulation techniques for PPP payload transport. When a 232 caller is offering both techniques, the two BLLI IEs are encoded within 233 a Broadband Repeat Indicator IE in the order of their preferance. The 234 called implementation MUST be able to accept an incoming call that 235 offers VC-multiplexed PPP in the caller's request. The called 236 implementation MAY reject a call set up request that only offers LLC 237 encapsulated PPP. Implementations originating a call offering both 238 protocol encapsulation techniques MUST be able to negotiate to the fall 239 back position of VC-multiplexed PPP and still inter-operate. 241 When originating a virtual circuit multiplexed call that is to carry a 242 PPP payload, the ITU Q.2931 [9] B-LLI element user information layer 3 243 protocol field is encoded to select ISO/IEC TR 9577 [5] in octet 7. The 244 extension octets specify an IPI value of PPP (0xCF). By definition, the 245 first bytes of the AAL5 frame's payload field will always contain a PPP 246 header followed by a packet. 248 When originating an LLC encapsulated call that is to carry a PPP 249 payload, the ITU Q.2931 B-LLI element user information layer 2 protocol 250 field is encoded to select LAN Logical Link Control (ISO/IEC8802-2) in 251 octet 6. See RFC 1755 [8] appendix A for an example. By definition, 252 the first bytes of the AAL5 frame's payload field will contain an LLC 253 header, followed by a NLPID and the PPP payload. 255 7. PPP Link Control Protocol Phase Transitions 257 Initial LCP packets contain the sequence cf-c0-21. In the case of VC- 258 multiplexed PPP, this sequence constitute the first three octets of an 259 AAL5 frame. When a LCP Configure-Request packet is received and 260 recognized, the PPP link enters Link Establishment phase. 262 Configuration requests received over multi-point connections SHOULD 263 result in (a) misconfiguration indication(s). This can be detected by 264 multiple responses to the LCP Configure-Request with the same 265 Identifier, coming from different framing addresses. Some 266 implementations might be physically unable to either log or report such 267 information. 269 Once PPP has entered the Network-layer Protocol phase, and successfully 270 negotiated a particular NCP for a PPP Protocol, if a frame arrives using 271 an alternate but equivalent data encapsulation defined in [4], the PPP 272 Link MUST re-enter Link Establishment phase and send a new LCP 273 Configure-Request. This prevents "black-holes" that occur when the peer 274 loses state. 276 An implementation which requires PPP link configuration, and other PPP 277 negotiated features (such as authentication), MAY enter Termination 278 phase when configuration fails. 280 8. Configuration Options 282 The following Configuration Options are recommended: 284 Magic Number 286 Protocol Field Compression 288 9. Security Considerations 290 Generally, ATM networks are virtual circuit based, and security is 291 implicit in the public data networking service provider's administration 292 of Permanent Virtual Circuits (PVCs) between the network boundaries. 293 The probability of a security breach caused by mis-routed ATM cells is 294 considered to be negligible. 296 When a public ATM network supports Switched Virtual Circuits, the 297 protocol model becomes analogous to traditional voice band modem dial up 298 over the Public Telephone Switched Network (PTSN). The same PAP/CHAP 299 authentication protocols that are already widely in use for Internet 300 dial up access are leveraged. As a consequence, PPP over AAL5 security 301 is at parity with those practices already established by the existing 302 Internet infrastructure. 304 Those applications that require stronger security are encouraged to use 305 authentication headers, or encrypted payloads, and/or ATM-layer security 306 services. 308 References 310 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 311 51, RFC 1661, July 1994. 313 [2] The ATM Forum, "Frame based User-to-Network Interface (FUNI) 314 Specification v2", af-saa-0088.000, May 1997. 316 [3] Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, 317 RFC 1662, July 1994. 319 [4] Hienanan, J., "Multiprotocol Interconnect over AAL5", 320 RFC 1483, July 1993. 322 [5] ISO/IEC DTR 9577.2, "Information technology - 323 Telecommunications and Information exchange between systems - 324 Protocol Identification in the network layer", 1995-08-16. 326 [6] Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996. 328 [7] The Frame Relay Forum, "Frame Relay/ATM PVC Service Inter-working 329 Implementation Agreement", FRF.8, April 1995. 331 [8] M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman, A. Malis, 332 "ATM Signaling Support for IP over ATM", RFC 1755, February 1995. 334 [9] International Telecommunication Union, "Broadband Integrated Service 335 Digital Network (B-ISDN) Digital Subscriber Signaling System No.2 336 (DSS2) User Network Interface Layer 3 Specification for Basic 337 Call/Connection Control", ITU-T Recommendation Q.2931, (International 338 Telecommunication Union: Geneva, 2/95) 340 10. Acknowledgments 342 This design is based on work performed in ADSL Forum's Packet Mode 343 Working Group. It is inspired by "PPP in Frame Relay", RFC 1973, by 344 William Simpson. 346 Chair's Address The working group can be contacted via the current 347 chair: 348 Karl Fox 349 Ascend Communications 350 3518 Riverside Drive, Suite 101 351 Columbus, Ohio 43221 353 EMail: karl@ascend.com 355 Author's Address 356 Questions about this memo can also be directed to: 358 Manu Kaycee 359 Paradyne Corporation 360 100 Shultz Drive 361 Red Bank, NJ 07701 362 Tel: +1.732.345.7664 363 Email: mjk@nj.paradyne.com 365 George Gross 366 Lucent Technologies, Inc 367 184 Liberty Corner Road 368 Warren, NJ 07059 369 Tel: +1.908.580.4589 370 Email: gmg@garage.lucent.com 372 Arthur Lin 373 Cisco Systems, Inc. 374 170 West Tasman Drive 375 San Jose, CA 95134 376 Tel: +1.408.526.8260 377 Email: alin@cisco.com 379 Andrew Malis 380 Ascend Communications, Inc. 381 5 Carlisle Road 382 Westford, MA 01886 383 Tel: +1.508.952.7414 384 Email: malis@casc.com 386 John Stephens 387 Cayman Systems, Inc. 388 100 Maple Street 389 Stoneham, MA 02180 390 Tel: +1.617.279.1101 391 Email: john@cayman.com