idnits 2.17.1 draft-ietf-pppext-aal5-03.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 68: '... MUST - This word, or the adjectiv...' RFC 2119 keyword, line 71: '... MUST NOT - This phrase means that...' RFC 2119 keyword, line 74: '... SHOULD - This word, or the adject...' RFC 2119 keyword, line 76: '...ull implications MUST be understood an...' RFC 2119 keyword, line 79: '... MAY - This word, or the adjective...' (20 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 210 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 (November 18, 1997) is 9653 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 373, 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. -------------------------------------------------------------------------------- 1 PPP Extensions Working Group George Gross, Lucent Technologies 2 INTERNET DRAFT Manu Kaycee, Paradyne 3 Expires May 18, 1998 Arthur Lin, Benchmark Capital 4 Andrew Malis, Ascend Communications 5 John Stephens, Cayman Systems 6 November 18, 1997 8 PPP Over AAL5 10 12 Status Of This Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, and 16 its working groups. Note that other groups may also distribute working 17 documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Distribution of this memo is unlimited. 32 Abstract 34 The Point-to-Point Protocol (PPP) [1] provides a standard method 35 for transporting multi-protocol datagrams over point-to-point 36 links. 38 This document describes the use of ATM Adaptation Layer 5 (AAL5) 39 for framing PPP encapsulated packets. 41 Applicability 42 This specification is intended for those implementations which desire to 43 use the facilities which are defined for PPP, such as the Link Control 44 Protocol, Network-layer Control Protocols, authentication, and 45 compression. These capabilities require a point-to-point relationship 46 between the peers, and are not designed for the multi-point 47 relationships which are available in ATM and other multi-access 48 environments. 50 1. Introduction 52 ATM AAL5 protocol is designed to provide virtual connections between end 53 stations attached to the same network. These connections offer a packet 54 delivery service that includes error detection, but does not do error 55 correction. 57 Most existing implementations of PPP use ISO 3309 HDLC as a basis for 58 their framing [3]. 60 When an ATM network is configured with point-to-point connections, PPP 61 can use AAL5 as a framing mechanism. 63 2. Specification of Requirements 65 In this document, several words are used to signify the requirements of 66 the specification. These words are often capitalized. 68 MUST - This word, or the adjective "required", means that the 69 definition is an absolute requirement of the specification. 71 MUST NOT - This phrase means that the definition is an absolute 72 prohibition of the specification. 74 SHOULD - This word, or the adjective "recommended", means that 75 there may exist valid reasons in particular circumstances to ignore 76 this item, but the full implications MUST be understood and 77 carefully weighed before choosing a different course. 79 MAY - This word, or the adjective "optional", means that this item 80 is one of an allowed set of alternatives. An implementation which 81 does not include this option MUST be prepared to interoperate with 82 another implementation which does include the option. 84 3. AAL5 Layer Service Interface 86 The PPP layer treats the underlying ATM AAL5 layer service as a bit- 87 synchronous point-to-point link. In this context, the PPP link 88 corresponds to an ATM AAL5 virtual connection. The virtual connection 89 MUST be full-duplex, point to point, and it MAY be either dedicated 90 (i.e. permanent, set up by provisioning) or switched (set up on demand). 91 In addition, the PPP/AAL5 service interface boundary MUST meet the 92 following requirements: 94 Interface Format - The PPP/AAL5 layer boundary presents an octet 95 service interface to the AAL5 layer. There is no provision for 96 sub-octets to be supplied or accepted. 98 Transmission Rate - The PPP layer does not impose any restrictions 99 regarding transmission rate. 101 Control Signals - The AAL5 layer must provide control signals to 102 the PPP layer which indicate when the virtual connection link has 103 become connected or disconnected. These provide the "Up" and 104 "Down" events to the LCP state machine [1] within the PPP layer. 106 4. Multi-Protocol Encapsulation 108 This specification uses the principles, terminology, and frame structure 109 described in "Multiprotocol Encapsulation over ATM Adaptation Layer 5" 110 [4]. 112 The purpose of this specification is not to document what is already 113 standardized in [4], but to specify how the mechanisms described in [4] 114 are to be used to map PPP onto an AAL5-based ATM network. Section 1 115 within [4] defines the two mechanisms for identifying the Protocol Data 116 Unit (PDU) payload field's protocol type: virtual circuit based 117 multiplexing, and Logical Link Control (LLC) encapsulation. In the 118 former technique, the payload's protocol type is implicitly agreed to by 119 the end points for each virtual circuit using provisioning or control 120 plane procedures. When using the LLC encapsulation technique, the 121 payload's protocol type is explicitly identified on a per PDU basis by 122 an in-band LLC header, followed by the payload data. 124 When transporting a PPP payload over AAL5, an implementation: 126 1. MUST support virtual circuit multiplexed PPP payloads as 127 described in section 5. This technique is referred to as "VC- 128 multiplexed PPP". 130 2. MAY use LLC encapsulated PPP payloads on PVCs as described in 131 section 6 below by mutual configuration or negotiation of both end 132 points. This technique is referred to as "LLC encapsulated PPP". 134 3. If an implementation is connecting though a Frame Relay/ATM 135 FRF.8 [7] service inter-working unit to an RFC 1973 [6] end point, 136 then it MUST support LLC encapsulated PPP payloads. 138 4. For SVC set up, an implementation MUST negotiate using the 139 Q.2931 [9] Annex C procedure, encoding the Broadband Lower Layer 140 Interface (B-LLI) information element to signal either VC- 141 multiplexed PPP or LLC encapsulated PPP. The details of this 142 control plane procedure are described in section 7. 144 5. Virtual Circuit Multiplexed PPP Over AAL5 146 The AAL5 PDU format is shown in figure 1: 148 AAL5 CPCS-PDU Format 149 +-------------------------------+ 150 | . | 151 | . | 152 | CPCS-PDU Payload | 153 | up to 2^16 - 1 octets) | 154 | . | 155 | . | 156 +-------------------------------+ 157 | PAD ( 0 - 47 octets) | 158 +-------------------------------+ ------- 159 | CPCS-UU (1 octet ) | 160 +-------------------------------+ 161 | CPI (1 octet ) | 162 +-------------------------------+CPCS-PDU Trailer 163 | Length (2 octets) | 164 +-------------------------------| 165 | CRC (4 octets) | 166 +-------------------------------+ ------- 167 Figure 1 169 The Common Part Convergence Sub-layer (CPCS)-PDU Payload field contains 170 user information up to 2^16 - 1 octets. 172 The PAD field pads the CPCS-PDU to fit exactly into the ATM cells such 173 that the last 48 octet cell payload created by the SAR sublayer will 174 have the CPCS-PDU Trailer right justified in the cell. 176 The CPCS-UU (User-to-User indication) field is used to transparently 177 transfer CPCS user to user information. The field has no function under 178 the multi-protocol ATM encapsulation described in this memo and can be 179 set to any value. 181 The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer to 64 182 bits. Possible additional functions are for further study in ITU-T. 183 When only the 64 bit alignment function is used, this field shall be 184 coded as 0x00. 186 The Length field indicates the length, in octets, of the Payload field. 187 The maximum value for the Length field is 65535 octets. A Length field 188 coded as 0x00 is used for the abort function. 190 The CRC field protects the entire CPCS-PDU except the CRC field itself. 192 A VC-multiplexed PPP frame SHALL constitute the CPCS-PDU payload and is 193 defined as: 195 +-------------+-------------+---------+ 196 | Protocol ID | Information | Padding | 197 | 8/16 bits | | | 198 +-------------+-------------+---------+ 199 Figure 2 201 Each of these fields are specifically defined in [1]. 203 6. LLC Encapsulated PPP Over AAL5 205 LLC encapsulated PPP over AAL5 is the alternative technique to VC- 206 multiplexed PPP over AAL5. LLC encapsulated PPP minimizes the ATM/Frame 207 Relay inter-working translation complexity that occurs when a VCC is 208 connected to an RFC 1973 compliant end point. 210 The AAL5 CPCS-PDU payload field is encoded as shown in figure 3: 212 +-------------------------+ -------- 213 | Destination SAP (0xFE) | ^ 214 +-------------------------+ | 215 | Source SAP (0xFE) | LLC header 216 +-------------------------+ | 217 | Frame Type = UI (0x03) | V 218 +-------------------------+ -------- 219 | NLPID = PPP (0xCF) | 220 +-------------------------+ -------- 221 | Protocol Identifier | ^ 222 | (8 or 16 bits) | | 223 +-------------------------+ PPP payload 224 | . | | 225 | . | | 226 | PPP information field | | 227 | . | | 228 | . | V 229 +-------------------------+ -------- 231 Figure 3 233 The fields in the above diagram are: 235 1. LLC header: 2 bytes encoded to specify a source SAP and 236 destination SAP of routed OSI PDU (values 0xFE 0xFE), followed by 237 an Un-numbered Information (UI) frame type (value 0x03). 239 2. Network Layer Protocol IDentifier (NLPID) representing PPP, 240 (value 0xCF). 242 3. the PPP protocol identifier field, which can be either 1 or 2 243 octets long. 245 4. followed by the PPP information field. 247 The end points MAY be bi-laterally provisioned to send other LLC- 248 encapsulated protocols besides PPP across the same virtual connection. 249 However, they MUST NOT send packets belonging to any protocol that has 250 an active NCP within the PPP session. Implementations SHOULD do packet 251 scheduling that minimizes the performance impact on the quality of 252 service commitments associated with both the LLC-encapsulated PPP and 253 non-PPP protocol flows. 255 7. Out-Of-Band Control Plane Signaling 257 When originating a switched virtual circuit AAL5 connection, the caller 258 MUST request in the SETUP message either VC-multiplexed PPP, LLC- 259 encapsulated PPP, or else both VC-multiplexed and LLC-encapsulated PPP. 260 Note that to guarantee inter-operability, it is suggested that VC- 261 multiplexed PPP always be requested. When a caller is offering both 262 techniques, the two B-LLI IEs are encoded within a Broadband Repeat 263 Indicator IE in the order of their preferance. The called 264 implementation MUST be able to accept an incoming call that offers VC- 265 multiplexed PPP in the caller's request. The called implementation MAY 266 reject a call set up request that only offers LLC encapsulated PPP. 267 Implementations originating a call offering both protocol encapsulation 268 techniques MUST be able to negotiate the use of VC-multiplexed PPP. 270 When originating a virtual circuit multiplexed call that is to carry a 271 PPP payload, the ITU Q.2931 [9] B-LLI element user information layer 3 272 protocol field is encoded to select ISO/IEC TR 9577 [5] in octet 7. The 273 extension octets specify an IPI value of PPP (0xCF). By definition, the 274 first bytes of the AAL5 frame's payload field will always contain a PPP 275 header followed by a packet. 277 When originating an LLC encapsulated call that is to carry a PPP 278 payload, the ITU Q.2931 B-LLI element user information layer 2 protocol 279 field is encoded to select LAN Logical Link Control (ISO/IEC8802-2) in 280 octet 6. See RFC 1755 [8] appendix A for an example. By definition, 281 the first bytes of the AAL5 frame's payload field will contain an LLC 282 header, followed by a NLPID and the PPP payload. 284 8. Detection And Recovery From Unsolicited PPP Encapsulation Transitions 286 When the virtual connection loses state, the PPP encapsulation technique 287 may uni-laterally and unexpectedly change across such transitions. 288 Detection and recovery procedures are defined for the following state 289 transitions: 291 VC-multiplexed PPP changing to LLC encapsulated PPP 293 LLC encapsulated PPP changing to VC-multiplexed PPP 295 When LLC-encapsulated PPP is being used, the inital 6 octets of the LCP 296 packets contain the sequence: fe-fe-03-cf-c0-21. This sequence 297 constitutes the first 6 octets of the AAL5 frame. In the case of VC- 298 multiplexed PPP, initial LCP packets contain the sequence c0-21. This 299 sequence constitutes the first 2 octets of an AAL5 frame. When a LCP 300 Configure-Request packet is received and recognized, the PPP link enters 301 Link Establishment phase. 303 Configuration requests received over multi-point connections SHOULD 304 result in a misconfiguration indication(s). This can be detected by 305 multiple responses to the LCP Configure-Request with the same 306 Identifier, coming from different framing addresses. Some 307 implementations might be physically unable to either log or report such 308 information. 310 Once PPP has entered the Network-layer Protocol phase, and successfully 311 negotiated a particular NCP for a PPP Protocol, if a frame arrives using 312 an alternate but equivalent data encapsulation defined in [4], the PPP 313 Link MUST re-enter Link Establishment phase and send a new LCP 314 Configure-Request. This prevents "black-holes" that occur when the peer 315 loses state. 317 An implementation which requires PPP link configuration, and other PPP 318 negotiated features (such as authentication), MAY enter Termination 319 phase when configuration fails. 321 9. LCP Configuration Options 323 The Magic Number LCP configuration option is recommended, and the 324 Protocol Field Compression (PFC) option is not recommended. An 325 implementation MUST NOT request any of the following options, and MUST 326 reject a request for such an option: 328 Field Check Sequence (FCS) Alternatives, 329 Address-and-Control-Field-Compression (ACFC), 331 Asynchronous-Control-Character-Map (ACCM) 333 The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a larger 334 size than the maximum CPCS-SDU size specified in the associated 335 direction for the virtual connection's traffic contract. 337 When viewed end to end, a PPP session may be bridged over multiple 338 physical layer segments. For a PPP session having AAL5 segments, for 339 each such AAL5 physical segment the LCP options MUST be negotiated by 340 the peer bridging convertors independently of the LCP framing options in 341 use by that session's other physical layer segments. 343 10. Security Considerations 345 Generally, ATM networks are virtual circuit based, and security is 346 implicit in the public data networking service provider's administration 347 of Permanent Virtual Circuits (PVCs) between the network boundaries. 348 The probability of a security breach caused by mis-routed ATM cells is 349 considered to be negligible. 351 When a public ATM network supports Switched Virtual Circuits, the 352 protocol model becomes analogous to traditional voice band modem dial up 353 over the Public Telephone Switched Network (PTSN). The same PAP/CHAP 354 authentication protocols that are already widely in use for Internet 355 dial up access are leveraged. As a consequence, PPP over AAL5 security 356 is at parity with those practices already established by the existing 357 Internet infrastructure. 359 Those applications that require stronger security are encouraged to use 360 authentication headers, or encrypted payloads, and/or ATM-layer security 361 services. 363 When using LLC-encapsulated PPP over a virtual connection, an end point 364 can not assume that the PPP session authentication and related security 365 mechanisms also secure the other LLC encapsulated flows on that same 366 virtual connection. 368 References 370 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 371 51, RFC 1661, July 1994. 373 [2] The ATM Forum, "Frame based User-to-Network Interface (FUNI) 374 Specification v2", af-saa-0088.000, May 1997. 376 [3] Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, 377 RFC 1662, July 1994. 379 [4] Hienanan, J., "Multiprotocol Interconnect over AAL5", 380 RFC 1483, July 1993. 382 [5] ISO/IEC DTR 9577.2, "Information technology - 383 Telecommunications and Information exchange between systems - 384 Protocol Identification in the network layer", 1995-08-16. 386 [6] Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996. 388 [7] The Frame Relay Forum, "Frame Relay/ATM PVC Service Inter-working 389 Implementation Agreement", FRF.8, April 1995. 391 [8] M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman, A. Malis, 392 "ATM Signaling Support for IP over ATM", RFC 1755, February 1995. 394 [9] International Telecommunication Union, "Broadband Integrated Service 395 Digital Network (B-ISDN) Digital Subscriber Signaling System No.2 396 (DSS2) User Network Interface Layer 3 Specification for Basic 397 Call/Connection Control", ITU-T Recommendation Q.2931, (International 398 Telecommunication Union: Geneva, 2/95) 400 11. Acknowledgments 402 This design is based on work performed in ADSL Forum's Packet Mode 403 Working Group. It is inspired by "PPP in Frame Relay", RFC 1973, by 404 William Simpson. Special thanks to Phil Rakity of Flowpoint, Tim Kwok 405 of Microsoft, and David Allan of Nortel for their constructive review 406 and commentary. 408 Chair's Address The working group can be contacted via the current 409 chair: 410 Karl Fox 411 Ascend Communications 412 3518 Riverside Drive, Suite 101 413 Columbus, Ohio 43221 415 EMail: karl@ascend.com 417 Author's Address 419 Questions about this memo can also be directed to: 421 George Gross 422 Lucent Technologies, Inc 423 184 Liberty Corner Road 424 Warren, NJ 07059 425 Tel: +1.908.580.4589 426 Email: gmgross@lucent.com 428 Manu Kaycee 429 Paradyne Corporation 430 21 Bear Meadow Road 431 Londonderry, NH 03053-2168 432 Tel: +1.603.434.6088 433 Email: mjk@nj.paradyne.com 435 Arthur Lin 436 Benchmark Capital 437 2480 Sand Hill Road 438 Suite 200 439 Menlo Park, CA 94025 440 Tel: +1.650.854.8180 441 Email: artlin@pacbell.net 443 Andrew Malis 444 Ascend Communications, Inc. 445 1 Robbins Road 446 Westford, MA 01886 447 Tel: +1.978.952.7414 448 Email: malis@ascend.com 450 John Stephens 451 Cayman Systems, Inc. 452 100 Maple Street 453 Stoneham, MA 02180 454 Tel: +1.617.279.1101 455 Email: john@cayman.com