idnits 2.17.1 draft-ietf-pppext-aal5-05.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-23) 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 70: '... 1. MUST This word, or the terms...' RFC 2119 keyword, line 73: '... 2. MUST NOT This phrase, or the...' RFC 2119 keyword, line 76: '... 3. SHOULD This word, or the adj...' RFC 2119 keyword, line 81: '... 4. SHOULD NOT This phrase, or t...' RFC 2119 keyword, line 87: '... 5. MAY This word, or the adject...' (20 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 229 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 416, 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 George Gross, Lucent Technologies 3 INTERNET DRAFT Manu Kaycee, Paradyne 4 Expires October 5, 1998 Arthur Lin, Shasta Networks 5 Andrew Malis, Ascend Communications 6 John Stephens, Cayman Systems 7 April 5th, 1998 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 view the entire list of current Internet-Drafts, please check 26 the "1id-abstracts.txt" listing contained in the Internet-Drafts 27 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 28 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 29 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 30 (US West Coast). 32 Distribution of this memo is unlimited. 34 Abstract 36 The Point-to-Point Protocol (PPP) [1] provides a standard method 37 for transporting multi-protocol datagrams over point-to-point 38 links. 40 This document describes the use of ATM Adaptation Layer 5 (AAL5) 41 for framing PPP encapsulated packets. 43 Applicability 44 This specification is intended for those implementations which desire to 45 use the facilities which are defined for PPP, such as the Link Control 46 Protocol, Network-layer Control Protocols, authentication, and 47 compression. These capabilities require a point-to-point relationship 48 between the peers, and are not designed for the multi-point 49 relationships which are available in ATM and other multi-access 50 environments. 52 1. Introduction 54 ATM AAL5 protocol is designed to provide virtual connections between end 55 stations attached to the same network. These connections offer a packet 56 delivery service that includes error detection, but does not do error 57 correction. 59 Most existing implementations of PPP use ISO 3309 HDLC as a basis for 60 their framing [3]. 62 When an ATM network is configured with point-to-point connections, PPP 63 can use AAL5 as a framing mechanism. 65 2. Specification of Requirements 67 In this document, several words are used to signify the requirements of 68 the specification. These words are often capitalized. 70 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that 71 the definition is an absolute requirement of the specification. 73 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the 74 definition is an absolute prohibition of the specification. 76 3. SHOULD This word, or the adjective "RECOMMENDED", mean that 77 there may exist valid reasons in particular circumstances to ignore 78 a particular item, but the full implications must be understood and 79 carefully weighed before choosing a different course. 81 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean 82 that there may exist valid reasons in particular circumstances when 83 the particular behavior is acceptable or even useful, but the full 84 implications should be understood and the case carefully weighed 85 before implementing any behavior described with this label. 87 5. MAY This word, or the adjective "OPTIONAL", mean that an item 88 is truly optional. One vendor may choose to include the item 89 because a particular marketplace requires it or because the vendor 90 feels that it enhances the product while another vendor may omit 91 the same item. An implementation which does not include a 92 particular option MUST be prepared to interoperate with another 93 implementation which does include the option, though perhaps with 94 reduced functionality. In the same vein an implementation which 95 does include a particular option MUST be prepared to interoperate 96 with another implementation which does not include the option 97 (except, of course, for the feature the option provides.) 99 3. AAL5 Layer Service Interface 101 The PPP layer treats the underlying ATM AAL5 layer service as a bit- 102 synchronous point-to-point link. In this context, the PPP link 103 corresponds to an ATM AAL5 virtual connection. The virtual connection 104 MUST be full-duplex, point to point, and it MAY be either dedicated 105 (i.e. permanent, set up by provisioning) or switched (set up on demand). 106 In addition, the PPP/AAL5 service interface boundary MUST meet the 107 following requirements: 109 Interface Format - The PPP/AAL5 layer boundary presents an octet 110 service interface to the AAL5 layer. There is no provision for 111 sub-octets to be supplied or accepted. 113 Transmission Rate - The PPP layer does not impose any restrictions 114 regarding transmission rate or the underlying ATM layer traffic 115 descriptor parameters. 117 Control Signals - The AAL5 layer must provide control signals to 118 the PPP layer which indicate when the virtual connection link has 119 become connected or disconnected. These provide the "Up" and 120 "Down" events to the LCP state machine [1] within the PPP layer. 122 4. Multi-Protocol Encapsulation 124 This specification uses the principles, terminology, and frame structure 125 described in "Multiprotocol Encapsulation over ATM Adaptation Layer 5" 126 [4]. 128 The purpose of this specification is not to document what is already 129 standardized in [4], but to specify how the mechanisms described in [4] 130 are to be used to map PPP onto an AAL5-based ATM network. Section 1 131 within [4] defines the two mechanisms for identifying the Protocol Data 132 Unit (PDU) payload field's protocol type: virtual circuit based 133 multiplexing, and Logical Link Control (LLC) encapsulation. In the 134 former technique, the payload's protocol type is implicitly agreed to by 135 the end points for each virtual circuit using provisioning or control 136 plane procedures. When using the LLC encapsulation technique, the 137 payload's protocol type is explicitly identified on a per PDU basis by 138 an in-band LLC header, followed by the payload data. 140 When transporting a PPP payload over AAL5, an implementation: 142 1. MUST support virtual circuit multiplexed PPP payloads as 143 described in section 5 below by mutual configuration or negotiation 144 of both end points. This technique is referred to as "VC- 145 multiplexed PPP". 147 2. MUST support LLC encapsulated PPP payloads on PVCs as described 148 in section 6 below by mutual configuration or negotiation of both 149 end points. This technique is referred to as "LLC encapsulated 150 PPP". 152 3. For SVC set up, an implementation MUST negotiate using the 153 Q.2931 [9] Annex C procedure, encoding the Broadband Lower Layer 154 Interface (B-LLI) information element to signal either VC- 155 multiplexed PPP or LLC encapsulated PPP. The details of this 156 control plane procedure are described in section 7. 158 If an implementation is connecting through a Frame Relay/ATM FRF.8 [7] 159 service inter-working unit to an RFC 1973 [6] end point, then it MUST 160 use LLC encapsulated PPP payloads. Frame Relay/ATM FRF.8 inter-working 161 units are exempted from the requirement to support VC-multiplexed PPP. 162 This exemption allows the FR/ATM IWU to remain compliant with FRF.8 when 163 the PPP over AAL5 end point is inter-operating with an RFC1973 end 164 point. 166 5. Virtual Circuit Multiplexed PPP Over AAL5 168 The AAL5 PDU format is shown in figure 1: 170 AAL5 CPCS-PDU Format 171 +-------------------------------+ 172 | . | 173 | . | 174 | CPCS-PDU Payload | 175 | up to 2^16 - 1 octets) | 176 | . | 177 +-------------------------------+ 178 | PAD ( 0 - 47 octets) | 179 +-------------------------------+ ------- 180 | CPCS-UU (1 octet ) | ^ 181 +-------------------------------+ | 182 | CPI (1 octet ) | | 183 +-------------------------------+CPCS-PDU Trailer 184 | Length (2 octets) | | 185 +-------------------------------| | 186 | CRC (4 octets) | V 187 +-------------------------------+ ------- 188 Figure 1 190 The Common Part Convergence Sub-layer (CPCS)-PDU Payload field contains 191 user information up to 2^16 - 1 octets. 193 The PAD field pads the CPCS-PDU to fit exactly into the ATM cells such 194 that the last 48 octet cell payload created by the SAR sublayer will 195 have the CPCS-PDU Trailer right justified in the cell. 197 The CPCS-UU (User-to-User indication) field is used to transparently 198 transfer CPCS user to user information. The field has no function under 199 the multi-protocol ATM encapsulation described in this memo and can be 200 set to any value. 202 The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer to 64 203 bits. Possible additional functions are for further study in ITU-T. 204 When only the 64 bit alignment function is used, this field shall be 205 coded as 0x00. 207 The Length field indicates the length, in octets, of the Payload field. 208 The maximum value for the Length field is 65535 octets. A Length field 209 coded as 0x00 is used for the abort function. 211 The CRC field protects the entire CPCS-PDU except the CRC field itself. 213 A VC-multiplexed PPP frame SHALL constitute the CPCS-PDU payload and is 214 defined as: 216 +-------------+-------------+---------+ 217 | Protocol ID | Information | Padding | 218 | 8/16 bits | | | 219 +-------------+-------------+---------+ 220 Figure 2 222 Each of these fields are specifically defined in [1]. 224 6. LLC Encapsulated PPP Over AAL5 226 LLC encapsulated PPP over AAL5 is the alternative technique to VC- 227 multiplexed PPP over AAL5. 229 The AAL5 CPCS-PDU payload field is encoded as shown in figure 3. The 230 pertinent fields in that diagram are: 232 1. LLC header: 2 bytes encoded to specify a source SAP and 233 destination SAP of routed OSI PDU (values 0xFE 0xFE), followed by 234 an Un-numbered Information (UI) frame type (value 0x03). 236 2. Network Layer Protocol IDentifier (NLPID) representing PPP, 237 (value 0xCF). 239 3. the PPP protocol identifier field, which can be either 1 or 2 240 octets long. See reference [1]. 242 4. followed by the PPP information field as per Figure 2. 244 +-------------------------+ -------- 245 | Destination SAP (0xFE) | ^ 246 +-------------------------+ | 247 | Source SAP (0xFE) | LLC header 248 +-------------------------+ | 249 | Frame Type = UI (0x03) | V 250 +-------------------------+ -------- 251 | NLPID = PPP (0xCF) | 252 +-------------------------+ -------- 253 | Protocol Identifier | ^ 254 | (8 or 16 bits) | | 255 +-------------------------+ PPP payload 256 | . | | 257 | . | | 258 | PPP information field | | 259 | . | | 260 | . | | 261 +-------------------------+ | 262 | padding | V 263 +-------------------------+ -------- 264 | PAD ( 0 - 47 octets) | 265 +-------------------------+ -------- 266 | CPCS-UU (1 octet ) | ^ 267 +-------------------------+ | 268 | CPI (1 octet ) | | 269 +-------------------------+CPCS-PDU Trailer 270 | Length (2 octets) | | 271 +-------------------------| | 272 | CRC (4 octets) | V 273 +-------------------------+ -------- 275 Figure 3 277 The end points MAY be bi-laterally provisioned to send other LLC- 278 encapsulated protocols besides PPP across the same virtual connection. 279 However, they MUST NOT send packets belonging to any protocol that has 280 an active NCP within the PPP session. Implementations SHOULD do packet 281 scheduling that minimizes the performance impact on the quality of 282 service commitments associated with both the LLC-encapsulated PPP and 283 non-PPP protocol flows. 285 7. Out-Of-Band Control Plane Signaling 287 When originating a switched virtual circuit AAL5 connection, the caller 288 MUST request in the SETUP message either VC-multiplexed PPP, LLC- 289 encapsulated PPP, or else both VC-multiplexed and LLC-encapsulated PPP. 290 When a caller is offering both techniques, the two B-LLI IEs are encoded 291 within a Broadband Repeat Indicator IE in the order of their preference. 292 The called implementation MUST be able to accept an incoming call that 293 offers LLC-encapsulated PPP in the caller's request. The called 294 implementation MUST reject a call set up request that only offers an 295 encapsulation that it does not support. Implementations originating a 296 call offering both protocol encapsulation techniques MUST be able to 297 negotiate the use of LLC-encapsulated PPP. 299 When originating a virtual circuit multiplexed call that is to carry a 300 PPP payload, the ITU Q.2931 [9] B-LLI element user information layer 3 301 protocol field is encoded to select ISO/IEC TR 9577 [5] in octet 7. The 302 extension octets specify an IPI value of PPP (0xCF). By definition, the 303 first bytes of the AAL5 frame's payload field will always contain a PPP 304 header followed by a packet. 306 When originating an LLC encapsulated call that is to carry a PPP 307 payload, the ITU Q.2931 B-LLI element user information layer 2 protocol 308 field is encoded to select LAN Logical Link Control (ISO/IEC8802-2) in 309 octet 6. See RFC 1755 [8] appendix A for an example. By definition, 310 the first bytes of the AAL5 frame's payload field will contain an LLC 311 header, followed by a NLPID and the PPP payload. 313 8. Detection And Recovery From Unsolicited PPP Encapsulation Transitions 315 When the virtual connection loses state, the PPP encapsulation technique 316 may uni-laterally and unexpectedly change across such transitions. 317 Detection and recovery procedures are defined for the following state 318 transitions: 320 VC-multiplexed PPP changing to LLC encapsulated PPP 322 LLC encapsulated PPP changing to VC-multiplexed PPP 324 When LLC-encapsulated PPP is being used, the inital 6 octets of the LCP 325 packets contain the sequence: fe-fe-03-cf-c0-21. This sequence 326 constitutes the first 6 octets of the AAL5 frame. In the case of VC- 327 multiplexed PPP, initial LCP packets contain the sequence c0-21. This 328 sequence constitutes the first 2 octets of an AAL5 frame. When a LCP 329 Configure-Request packet is received and recognized, the PPP link enters 330 Link Establishment phase. 332 Once PPP has entered the Network-layer Protocol phase, and successfully 333 negotiated a particular NCP for a PPP Protocol, if a frame arrives using 334 an alternate but equivalent data encapsulation as defined in [4], then 335 the PPP Link MUST: 337 For a SVC, immediately clear the call with the cause value 111, 338 "protocol error, unspecified". 340 For a PVC: tear down the active NCPs, SHOULD generate an error 341 message, enter the Termination state, and silently drop all 342 received packets. 344 These policies prevent "black-holes" that occur when the peer loses 345 state. An implementation which requires PPP link configuration, and 346 other PPP negotiated features (such as authentication), MAY enter 347 Termination state when configuration fails. 349 9. LCP Configuration Options 351 The Magic Number LCP configuration option is recommended, and the 352 Protocol Field Compression (PFC) option is not recommended. An 353 implementation MUST NOT request any of the following options, and MUST 354 reject a request for such an option: 356 Field Check Sequence (FCS) Alternatives, 358 Address-and-Control-Field-Compression (ACFC), 360 Asynchronous-Control-Character-Map (ACCM) 362 The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a larger 363 size than the maximum CPCS-SDU size specified in the associated 364 direction for the virtual connection's traffic contract. 366 When viewed peer to peer, a PPP link may be bridged over multiple 367 physical layer sections. For each such AAL5 section, the LCP framing 368 options MUST be actively negotiated by the bridging convertors 369 independently of the LCP framing options in use by other physical layer 370 sections. 372 Implementation Note: 373 When an ATM AAL5 PVC is in the "Stopped" state, it is recommended 374 that the implementation wait for Configure-Requests. See the 375 implementation option in reference [1] section 4.2, the "Stopped 376 State" sub-section. 378 10. Security Considerations 380 Generally, ATM networks are virtual circuit based, and security is 381 implicit in the public data networking service provider's administration 382 of Permanent Virtual Circuits (PVCs) between the network boundaries. 383 The probability of a security breach caused by mis-routed ATM cells is 384 considered to be negligible. 386 When a public ATM network supports Switched Virtual Circuits, the 387 protocol model becomes analogous to traditional voice band modem dial up 388 over the Public Telephone Switched Network (PTSN). The same PAP/CHAP 389 authentication protocols that are already widely in use for Internet 390 dial up access are leveraged. As a consequence, PPP over AAL5 security 391 is at parity with those practices already established by the existing 392 Internet infrastructure. 394 Those applications that require stronger security are encouraged to use 395 authentication headers, or encrypted payloads, and/or ATM-layer security 396 services. 398 When using LLC-encapsulated PPP over a virtual connection, an end point 399 can not assume that the PPP session authentication and related security 400 mechanisms also secure the other LLC encapsulated flows on that same 401 virtual connection. 403 11. Acknowledgments 405 This design is based on work performed in ADSL Forum's Packet Mode 406 Working Group. It is inspired by "PPP in Frame Relay", RFC 1973, by 407 William Simpson. Special thanks to Phil Rakity of Flowpoint, Tim Kwok 408 of Microsoft, and David Allan of Nortel for their constructive review 409 and commentary. 411 12. References 413 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 414 51, RFC 1661, July 1994. 416 [2] The ATM Forum, "Frame based User-to-Network Interface (FUNI) 417 Specification v2", af-saa-0088.000, May 1997. 419 [3] Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, 420 RFC 1662, July 1994. 422 [4] Heinanen, J., "Multiprotocol Interconnect over AAL5", 423 RFC 1483, July 1993. 425 [5] ISO/IEC DTR 9577.2, "Information technology - 426 Telecommunications and Information exchange between systems - 427 Protocol Identification in the network layer", 1995-08-16. 429 [6] Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996. 431 [7] The Frame Relay Forum, "Frame Relay/ATM PVC Service Inter-working 432 Implementation Agreement", FRF.8, April 1995. 434 [8] M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman, A. Malis, 435 "ATM Signaling Support for IP over ATM", RFC 1755, February 1995. 437 [9] International Telecommunication Union, "Broadband Integrated Service 438 Digital Network (B-ISDN) Digital Subscriber Signaling System No.2 439 (DSS2) User Network Interface Layer 3 Specification for Basic 440 Call/Connection Control", ITU-T Recommendation Q.2931, (International 441 Telecommunication Union: Geneva, 2/95) 443 Chair's Address The working group can be contacted via the current 444 chair: 445 Karl Fox 446 Ascend Communications 447 3518 Riverside Drive, Suite 101 448 Columbus, Ohio 43221 450 EMail: karl@ascend.com 452 Author's Address 454 Questions about this memo can also be directed to: 456 George Gross 457 Lucent Technologies, Inc 458 184 Liberty Corner Road 459 Warren, NJ 07059 460 Tel: +1.908.580.4589 461 Email: gmgross@lucent.com 463 Manu Kaycee 464 Paradyne Corporation 465 21 Bear Meadow Road 466 Londonderry, NH 03053-2168 467 Tel: +1.603.434.6088 468 Email: mjk@nj.paradyne.com 470 Arthur Lin 471 Shasta Networks Inc. 472 249 Humboldt Court 473 Sunnyvale, CA 94089-1300 474 Tel: +1.408.747.5051 475 Email: alin@shastanets.com 477 Andrew Malis 478 Ascend Communications, Inc. 479 1 Robbins Road 480 Westford, MA 01886 481 Tel: +1.978.952.7414 482 Email: malis@ascend.com 484 John Stephens 485 Cayman Systems, Inc. 486 100 Maple Street 487 Stoneham, MA 02180 488 Tel: +1.617.279.1101 489 Email: john@cayman.com