idnits 2.17.1 draft-ietf-pppext-framerelay-ds-00.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. ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC-1661]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 1997) is 9659 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) == Missing Reference: 'DayDreamer' is mentioned on line 2, but not defined ** Obsolete normative reference: RFC 1490 (Obsoleted by RFC 2427) -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-ffff' Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W A Simpson [DayDreamer] 3 Internet Draft 4 expires in six months November 1997 6 PPP in Frame Relay 7 draft-ietf-pppext-framerelay-ds-00.txt 9 Status of this Memo 11 This document is an Internet-Draft. Internet Drafts are working doc- 12 uments of the Internet Engineering Task Force (IETF), its Areas, and 13 its Working Groups. Note that other groups may also distribute work- 14 ing documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months, and may be updated, replaced, or obsoleted by other documents 18 at any time. It is not appropriate to use Internet Drafts as refer- 19 ence material, or to cite them other than as a ``working draft'' or 20 ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 24 Directories on: 26 ftp.is.co.za (Africa) 27 nic.nordu.net (Europe) 28 ds.internic.net (US East Coast) 29 ftp.isi.edu (US West Coast) 30 munnari.oz.au (Pacific Rim) 32 Distribution of this memo is unlimited. 34 Abstract 36 The Point-to-Point Protocol (PPP) [RFC-1661] provides a standard 37 method for transporting multi-protocol datagrams over point-to-point 38 links. This document describes the use of Frame Relay for framing 39 PPP encapsulated packets. 41 Applicability 43 This specification is intended for those implementations that desire 44 to use facilities which are defined for PPP, such as the Link Control 45 Protocol, Network-layer Control Protocols, authentication, and com- 46 pression. These capabilities require a point-to-point relationship 47 between peers, and are not designed for multi-point or multi-access 48 environments. 50 1. Introduction 52 Frame Relay [Q.922] is a relative newcomer to the serial link commu- 53 nity. Like X.25, the protocol was designed to provide virtual cir- 54 cuits for connections between stations attached to the same Frame 55 Relay network. The improvement over X.25 is that Q.922 is restricted 56 to delivery of packets, and dispenses with sequencing and flow con- 57 trol, simplifying the service immensely. 59 At one time, it had been hoped that "PPP in HDLC-like Framing" 60 [RFC-1662] would co-exist with other Frame Relay transmissions on the 61 same links. Unfortunately, the Q.922 method for expanding the 62 address from 1 to 2 to 4 octets is not reliably distinguishable from 63 the ISO 3309 HDLC method, due to the structure of its Data Link Con- 64 nection Identifier (DLCI) subfields. Co-existance is precluded. 66 When Frame Relay is configured as a point-to-point circuit, PPP can 67 use Frame Relay as a framing mechanism, ignoring its other features. 68 This is equivalent to the technique used to carry SNAP headers over 69 Frame Relay [RFC-1490]. 71 1.1. Terminology 73 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 74 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 75 described in [RFC-2119]. 77 To remain consistent with standard Internet practice, and avoid con- 78 fusion for people used to reading RFCs, all binary numbers in the 79 following descriptions are in Most Significant Bit to Least Signifi- 80 cant Bit order, from Most Significant Byte to Least Significant Byte, 81 reading from left to right, unless otherwise indicated. Note that 82 this is contrary to ISO and ITU practice, which orders bits as trans- 83 mitted (network bit order). Keep this in mind when comparing this 84 document with the other documents. 86 2. Physical Layer Requirements 88 PPP is capable of operating across most Frame Relay interfaces. The 89 only absolute requirement imposed by PPP is the provision of a bi- 90 directional full-duplex circuit, either dedicated (permanent) or 91 frame-switched, that can operate in either a bit-synchronous, or 92 octet-synchronous mode, transparent to PPP Data Link Layer frames. 94 Interface Format 96 PPP presents an octet interface to the physical layer. There is 97 no provision for sub-octets to be supplied or accepted. 99 Transmission Rate 101 PPP does not impose any restrictions regarding transmission rate, 102 other than that of the particular Frame Relay interface. 104 Control Signals 106 Implementation of Frame Relay requires the provision of control 107 signals, that indicate when the link has become connected or dis- 108 connected. These in turn provide the Up and Down events to the 109 PPP LCP state machine. 111 Because PPP does not normally require the use of control signals, 112 the failure of such signals MUST NOT affect correct operation of 113 PPP. Implications are discussed in [RFC-1662]. 115 2.1. Transmission Considerations 117 The definition of various encodings is the responsibility of the 118 DTE/DCE equipment in use, and is outside the scope of this speci- 119 fication. 121 While PPP will operate without regard to the underlying represen- 122 tation of the octet stream, bit-synchronous Frame Relay requires 123 NRZ encoding. 125 In addition, this specification permits octet-synchronous Frame 126 Relay, with the same stuffing conventions as HDLC [RFC-1662]. 128 3. The Data Link Layer 130 This specification uses the principles, terminology, and frame 131 structure described in [RFC-1490]. 133 The purpose of this specification is not to document what is 134 already standardized in [RFC-1490]. Instead, this document 135 attempts to give a concise summary and point out specific options 136 and features used by PPP. 138 3.1. Frame Header 140 As described in [RFC-1490], Q.922 header address and control 141 fields are followed by a Network Layer Protocol Identifier (NLPID) 142 to identify the encapsulated packet. This specification describes 143 the PPP Protocol encapsulation. These fields are transmitted from 144 left to right. 146 +-+-+-+-+-+-+-+-+ 147 | Flag (0x7e) | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Q.922 Address | Control | NLPID(0xcf) | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | PPP Protocol | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 The PPP Protocol field and the following Information and Padding 155 fields are described in the Point-to-Point Protocol Encapsulation 156 [RFC-1661]. 158 3.2. Modification of the Basic Frame 160 The Link Control Protocol can negotiate modifications to the basic 161 frame structure. This is not compatible with Frame Relay. 163 Address-and-Control-Field-Compression 165 Since Frame Relay Address and Control field values are not con- 166 stant, are variable size, and are modified as the frame is 167 transported by the network switching fabric, Address-and- 168 Control-Field-Compression cannot affect the frame format. 170 FCS-Alternatives 172 Since Frame Relay requires a 16-bit FCS, which is modified as 173 the frame is transported by the network switching fabric, FCS- 174 Alternatives cannot affect the frame format. 176 In general, framing-related LCP Configuration Options are not rec- 177 ognizable, and are not acceptable for negotiation. The implemen- 178 tation MUST NOT send ineffectual options in a Configure-Request, 179 and SHOULD respond to such requested options with a Configure- 180 Reject. See [RFC-ffff] for details. 182 3.3. Modification of the Basic Packet 184 The Link Control Protocol can negotiate modifications to the basic 185 packet structure. These are transparent to Frame Relay. 187 Protocol-Field-Compression 189 The default Frame Relay header does not align the PPP Informa- 190 tion field on a 32-bit boundary. Alignment to a 32-bit bound- 191 ary occurs when the NLPID is removed and the PPP Protocol field 192 is compressed to a single octet. When this improves through- 193 put, Protocol-Field-Compression SHOULD be negotiated. 195 4. In-Band Protocol Demultiplexing 197 The PPP NLPID (CF hex) and PPP Protocol fields easily distinguish 198 the PPP encapsulation from the other NLPID encapsulations 199 described in [RFC-1490]. 201 The joining of the PPP and NLPID number space has an added advan- 202 tage, in that the LCP Protocol-Reject can be used to indicate 203 NLPIDs that are not recognized. This can eliminate "black-holes" 204 that occur when traffic is not supported. 206 For those network-layer protocols that have no PPP Protocol 207 assignment, or have not yet been implemented under the PPP encap- 208 sulation, or have not been successfully negotiated by a PPP NCP, 209 another method of encapsulation defined under [RFC-1490] SHOULD be 210 used. 212 Currently, there are no conflicts between NLPID and PPP Protocol 213 values. If a future implementation is configured to send a NLPID 214 value which is the same as a compressed Protocol field, that Pro- 215 tocol field MUST NOT be sent compressed. 217 On reception, the first octet following the Control field is exam- 218 ined: 220 - If the octet is zero, it MUST be assumed that the packet is 221 formatted according to [RFC-1490]. 223 - Initial LCP packets contain the sequence cf-c0-21 following the 224 Control field. When a LCP Configure-Request packet is received 225 and recognized, the PPP link enters Link Establishment phase. 227 - If the octet is not the PPP NLPID value, and Protocol-Field- 228 Compression is enabled, and the associated NCP has been 229 negotiated, then it is expected to be a compressed PPP Protocol 230 value. 232 - Otherwise, it MUST be assumed that the packet is formatted 233 according to [RFC-1490]. 235 Once PPP has entered the Link Establishment phase, packets with 236 other NLPID values MUST NOT be sent, and on receipt such packets 237 MUST be silently discarded, until the PPP link enters the Network- 238 Layer Protocol phase. 240 Once PPP has entered the Network-Layer Protocol phase, and suc- 241 cessfully negotiated a particular NCP for a PPP Protocol, if a 242 frame arrives using another equivalent data encapsulation defined 243 in [RFC-1490], the PPP Link MUST re-enter Link Establishment phase 244 and send a new LCP Configure-Request. This prevents "black-holes" 245 that occur when the peer loses state. 247 An implementation that requires PPP link configuration, and other 248 PPP negotiated features (such as authentication), MAY enter Termi- 249 nation phase when configuration fails. Otherwise, when the Con- 250 figure-Request sender reaches the Max-Configure limit, it MUST 251 fall back to send only frames encapsulated according to 252 [RFC-1490]. 254 Implementation Notes 256 The PPP Protocol field value 0x00cf is not allowed (reserved) 257 to avoid ambiguity when Protocol-Field-Compression is enabled. 258 For consistency, the NLPID value 0xcf MAY be treated as a com- 259 pressed PPP Protocol which indicates that another PPP Protocol 260 packet follows. 262 The accidental connection of a link to feed a multipoint net- 263 work (or multicast group) SHOULD result in a misconfiguration 264 indication. This can be detected by multiple responses to the 265 LCP Configure-Request with the same Identifier, coming from 266 different framing addresses. Some implementations might be 267 physically unable to either log or report such information. 269 5. Out-of-Band signaling 271 There is no generally agreed method of out-of-band signalling. 272 Until such a method is universally available, an implementation 273 MUST use In-Band Protocol Demultiplexing for both Permanent and 274 Switched Virtual Circuits. 276 6. Configuration Details 278 The following Configuration Options are recommended: 280 Magic Number 281 Protocol Field Compression 283 The standard LCP configuration defaults apply to Frame Relay 284 links, except Maximum-Receive-Unit (MRU). 286 To ensure interoperability with existing Frame Relay implementa- 287 tions, the initial MRU is 1600 octets [RFC-1490]. This only 288 affects the minimum required buffer space available for receiving 289 packets, not the size of packets sent. 291 The typical network feeding the link is likely to have a MRU of 292 either 1500, or 2048 or greater. To avoid fragmentation, the Max- 293 imum-Transmission-Unit (MTU) at the network layer SHOULD NOT 294 exceed 1500, unless a peer MRU of 2048 or greater is specifically 295 negotiated. 297 Some Frame Relay switches are only capable of 262 octet frames. 298 It is not recommended that anyone deploy or use a switch that is 299 capable of less than 1600 octet frames. However, PPP implementa- 300 tions MUST be configurable to limit the size of LCP packets that 301 are sent to 259 octets (leaving room for the NLPID and PPP Proto- 302 col fields), until LCP negotiation is complete. 304 XID negotiation is not required to be supported for links that are 305 capable of PPP negotiation. 307 Inverse ARP is not required to be supported for PPP links. That 308 function is provided by PPP NCP negotiation. 310 Security Considerations 312 This specification introduces no known security risks. 314 Acknowledgements 316 This design was inspired by the paper "Parameter Negotiation for 317 the Multiprotocol Interconnect", Keith Sklower and Clifford Frost, 318 University of California, Berkeley, 1992, unpublished. 320 Use of octet-synchronous interfaces, such as SONET/SDH, was first 321 proposed by John Bartell (BellSouth). 323 References 325 [Q.922] CCITT Recommendation Q.922, "ISDN Data Link Layer Speci- 326 fication for Frame Mode Bearer Services", International 327 Telegraph and Telephone Consultative Committee, 1992. 329 [RFC-1490] 330 Bradley, T., Brown, C., and Malis, A., "Multiprotocol 331 Interconnect over Frame Relay", July 1993. 333 [RFC-1661] 334 Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", 335 STD-51, DayDreamer, July 1994. 337 [RFC-1662] 338 Simpson, W., Editor, "PPP in HDLC-like Framing", STD-51, 339 DayDreamer, July 1994. 341 [RFC-2119] 342 Bradner, S., "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, Harvard University, March 344 1997. 346 [RFC-ffff] 347 Simpson, W., "PPP with Framing Conversion", work in 348 progress. 350 Contacts 352 Comments about this document should be discussed on the ietf- 353 ppp@merit.edu mailing list. 355 This document was reviewed by the Point-to-Point Protocol Working 356 Group of the Internet Engineering Task Force (IETF). The working 357 group can be contacted via the current chair: 359 Karl Fox 360 Ascend Communications 361 655 Metro Place South, Suite 370 362 Dublin, Ohio 43017 364 karl@Ascend.com 366 Questions about this document can also be directed to: 368 William Allen Simpson 369 DayDreamer 370 Computer Systems Consulting Services 371 1384 Fontaine 372 Madison Heights, Michigan 48071 374 wsimpson@UMich.edu 375 wsimpson@GreenDragon.com (preferred)