idnits 2.17.1 draft-ietf-pppext-funi-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-19) 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 212 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) -- 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 (~~), 2 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 FUNI 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 Frame User Network Interface 41 (FUNI) 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 FUNI 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 FUNI 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. FUNI Layer Service Interface 101 The PPP layer treats the underlying ATM FUNI layer service as a bit- 102 synchronous point-to-point link. In this context, the PPP link 103 corresponds to an ATM FUNI 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/FUNI service interface boundary MUST meet the 107 following requirements: 109 Interface Format - The PPP/FUNI layer boundary presents an octet 110 service interface to the FUNI 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 FUNI 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 a FUNI-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 FUNI, 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 FUNI end point is inter-operating with an RFC1973 end 164 point. 166 5. Virtual Circuit Multiplexed PPP Over FUNI 168 The FUNI protocol data unit (PDU) format [2] is as follows: 170 +-------------------------------+ 171 | Flag | 172 +-------------------------------+--------- 173 | FUNI Header | ^ 174 +-------------------------------+ | 175 | | | 176 | | | 177 | User SDU | FUNI PDU 178 | | | 179 | | | 180 +-------------------------------+ | 181 | FUNI FCS (2 or 4 octets) | v 182 +-------------------------------+--------- 183 | Flag | 184 +-------------------------------+ 185 Figure 1 187 The FUNI Header includes a 10-bit or 24-bit Frame Address (a.k.a. 188 VPI/VCI bits), a Congestion Notification bit, a Congestion Loss Priority 189 bit, and four Reserved bits. 191 The User SDU field contains user information up to 4096 (optionally up 192 to 64K) octets. 194 The FCS field protects the entire FUNI PDU except for the FCS field 195 itself. 197 A VC-multiplexed PPP frame SHALL constitute the User Service Data Unit 198 (SDU) field and is defined as shown in figure 2: 199 +-------------+-------------+---------+ 200 | Protocol ID | Information | Padding | 201 | 8/16 bits | | | 202 +-------------+-------------+---------+ 203 Figure 2 205 Each of these fields are specifically defined in [1]. 207 6. LLC Encapsulated PPP Over FUNI 209 LLC encapsulated PPP over FUNI is the alternative technique to VC- 210 multiplexed PPP over FUNI. 212 The FUNI SDU payload field is encoded as shown in figure 3. The 213 pertinent fields in that diagram are: 215 1. LLC header: 2 bytes encoded to specify a source SAP and 216 destination SAP of routed OSI PDU (values 0xFE 0xFE), followed by 217 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. See reference [1]. 225 4. followed by the PPP information field as per Figure 2. 227 +-------------------------+ -------- 228 | Destination SAP (0xFE) | ^ 229 +-------------------------+ | 230 | Source SAP (0xFE) | LLC header 231 +-------------------------+ | 232 | Frame Type = UI (0x03) | V 233 +-------------------------+ -------- 234 | NLPID = PPP (0xCF) | 235 +-------------------------+ -------- 236 | Protocol Identifier | ^ 237 | (8 or 16 bits) | | 238 +-------------------------+ PPP payload 239 | . | | 240 | . | | 241 | PPP information field | | 242 | . | | 243 | . | | 244 +-------------------------+ | 245 | padding | V 246 +-------------------------+ -------- 247 | FUNI FCS (2 or 4 octets)| FUNI trailer 248 +-------------------------+--------- 250 Figure 3 252 The end points MAY be bi-laterally provisioned to send other LLC- 253 encapsulated protocols besides PPP across the same virtual connection. 254 However, they MUST NOT send packets belonging to any protocol that has 255 an active NCP within the PPP session. Implementations SHOULD do packet 256 scheduling that minimizes the performance impact on the quality of 257 service commitments associated with both the LLC-encapsulated PPP and 258 non-PPP protocol flows. 260 7. Out-Of-Band Control Plane Signaling 262 When originating a switched virtual circuit FUNI connection, the caller 263 MUST request in the SETUP message either VC-multiplexed PPP, LLC- 264 encapsulated PPP, or else both VC-multiplexed and LLC-encapsulated PPP. 265 When a caller is offering both techniques, the two B-LLI IEs are encoded 266 within a Broadband Repeat Indicator IE in the order of their preference. 267 The called implementation MUST be able to accept an incoming call that 268 offers LLC-encapsulated PPP in the caller's request. The called 269 implementation MUST reject a call set up request that only offers an 270 encapsulation that it does not support. Implementations originating a 271 call offering both protocol encapsulation techniques MUST be able to 272 negotiate the use of LLC-encapsulated PPP. 274 When originating a virtual circuit multiplexed call that is to carry a 275 PPP payload, the ITU Q.2931 [9] B-LLI element user information layer 3 276 protocol field is encoded to select ISO/IEC TR 9577 [5] in octet 7. The 277 extension octets specify an IPI value of PPP (0xCF). By definition, the 278 first bytes of the FUNI frame's payload field will always contain a PPP 279 header followed by a packet. 281 When originating an LLC encapsulated call that is to carry a PPP 282 payload, the ITU Q.2931 B-LLI element user information layer 2 protocol 283 field is encoded to select LAN Logical Link Control (ISO/IEC8802-2) in 284 octet 6. See RFC 1755 [8] appendix A for an example. By definition, 285 the first bytes of the FUNI frame's payload field will contain an LLC 286 header, followed by a NLPID and the PPP payload. 288 8. Detection And Recovery From Unsolicited PPP Encapsulation Transitions 290 When the virtual connection loses state, the PPP encapsulation technique 291 may uni-laterally and unexpectedly change across such transitions. 292 Detection and recovery procedures are defined for the following state 293 transitions: 295 VC-multiplexed PPP changing to LLC encapsulated PPP 297 LLC encapsulated PPP changing to VC-multiplexed PPP 299 When LLC-encapsulated PPP is being used, the inital 6 octets of the LCP 300 packets contain the sequence: fe-fe-03-cf-c0-21. This sequence 301 constitutes the first 6 octets of the FUNI frame. In the case of VC- 302 multiplexed PPP, initial LCP packets contain the sequence c0-21. 304 In the case of FUNI, this sequence follows the FUNI Header. When a LCP 305 Configure-Request packet is received and recognized, the PPP link enters 306 Link Establishment phase. 308 Once PPP has entered the Network-layer Protocol phase, and successfully 309 negotiated a particular NCP for a PPP Protocol, if a frame arrives using 310 an alternate but equivalent data encapsulation as defined in [4], then 311 the PPP Link MUST: 313 For a SVC, immediately clear the call with the cause value 111, 314 "protocol error, unspecified". 316 For a PVC: tear down the active NCPs, SHOULD generate an error 317 message, enter the Termination state, and silently drop all 318 received packets. 320 These policies prevent "black-holes" that occur when the peer loses 321 state. An implementation which requires PPP link configuration, and 322 other PPP negotiated features (such as authentication), MAY enter 323 Termination state when configuration fails. 325 9. LCP Configuration Options 327 The Magic Number LCP configuration option is recommended, and the 328 Protocol Field Compression (PFC) option is not recommended. An 329 implementation MUST NOT request any of the following options, and MUST 330 reject a request for such an option: 332 Field Check Sequence (FCS) Alternatives, 334 Address-and-Control-Field-Compression (ACFC), 336 Asynchronous-Control-Character-Map (ACCM) 338 The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a larger 339 size than the maximum CPCS-SDU size specified in the associated 340 direction for the virtual connection's traffic contract. 342 When viewed peer to peer, a PPP link may be bridged over multiple 343 physical layer sections. For each such FUNI section, the LCP framing 344 options MUST be actively negotiated by the bridging convertors 345 independently of the LCP framing options in use by other physical layer 346 sections. 348 Implementation Note: 349 When an ATM FUNI PVC is in the "Stopped" state, it is recommended 350 that the implementation wait for Configure-Requests. See the 351 implementation option in reference [1] section 4.2, the "Stopped 352 State" sub-section. 354 10. Security Considerations 356 Generally, ATM networks are virtual circuit based, and security is 357 implicit in the public data networking service provider's administration 358 of Permanent Virtual Circuits (PVCs) between the network boundaries. 359 The probability of a security breach caused by mis-routed ATM cells is 360 considered to be negligible. 362 When a public ATM network supports Switched Virtual Circuits, the 363 protocol model becomes analogous to traditional voice band modem dial up 364 over the Public Telephone Switched Network (PTSN). The same PAP/CHAP 365 authentication protocols that are already widely in use for Internet 366 dial up access are leveraged. As a consequence, PPP over FUNI security 367 is at parity with those practices already established by the existing 368 Internet infrastructure. 370 Those applications that require stronger security are encouraged to use 371 authentication headers, or encrypted payloads, and/or ATM-layer security 372 services. 374 When using LLC-encapsulated PPP over a virtual connection, an end point 375 can not assume that the PPP session authentication and related security 376 mechanisms also secure the other LLC encapsulated flows on that same 377 virtual connection. 379 11. Acknowledgments 381 This design is based on work performed in ADSL Forum's Packet Mode 382 Working Group. It is inspired by "PPP in Frame Relay", RFC 1973, by 383 William Simpson. Special thanks to Phil Rakity of Flowpoint, Tim Kwok 384 of Microsoft, and David Allan of Nortel for their constructive review 385 and commentary. 387 12. References 389 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 390 51, RFC 1661, July 1994. 392 [2] The ATM Forum, "Frame based User-to-Network Interface (FUNI) 393 Specification v2", af-saa-0088.000, May 1997. 395 [3] Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, 396 RFC 1662, July 1994. 398 [4] Heinanen, J., "Multiprotocol Interconnect over AAL5", 399 RFC 1483, July 1993. 401 [5] ISO/IEC DTR 9577.2, "Information technology - 402 Telecommunications and Information exchange between systems - 403 Protocol Identification in the network layer", 1995-08-16. 405 [6] Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996. 407 [7] The Frame Relay Forum, "Frame Relay/ATM PVC Service Inter-working 408 Implementation Agreement", FRF.8, April 1995. 410 [8] M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman, A. Malis, 411 "ATM Signaling Support for IP over ATM", RFC 1755, February 1995. 413 [9] International Telecommunication Union, "Broadband Integrated Service 414 Digital Network (B-ISDN) Digital Subscriber Signaling System No.2 415 (DSS2) User Network Interface Layer 3 Specification for Basic 416 Call/Connection Control", ITU-T Recommendation Q.2931, (International 417 Telecommunication Union: Geneva, 2/95) 419 Chair's Address The working group can be contacted via the current 420 chair: 421 Karl Fox 422 Ascend Communications 423 3518 Riverside Drive, Suite 101 424 Columbus, Ohio 43221 426 EMail: karl@ascend.com 428 Author's Address 430 Questions about this memo can also be directed to: 432 George Gross 433 Lucent Technologies, Inc 434 184 Liberty Corner Road 435 Warren, NJ 07059 436 Tel: +1.908.580.4589 437 Email: gmgross@lucent.com 439 Manu Kaycee 440 Paradyne Corporation 441 21 Bear Meadow Road 442 Londonderry, NH 03053-2168 443 Tel: +1.603.434.6088 444 Email: mjk@nj.paradyne.com 446 Arthur Lin 447 Shasta Networks Inc. 448 249 Humboldt Court 449 Sunnyvale, CA 94089-1300 450 Tel: +1.408.747.5051 451 Email: alin@shastanets.com 453 Andrew Malis 454 Ascend Communications, Inc. 455 1 Robbins Road 456 Westford, MA 01886 457 Tel: +1.978.952.7414 458 Email: malis@ascend.com 460 John Stephens 461 Cayman Systems, Inc. 462 100 Maple Street 463 Stoneham, MA 02180 464 Tel: +1.617.279.1101 465 Email: john@cayman.com