idnits 2.17.1 draft-ietf-pppext-frame-relay-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-24) 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 76: '... MUST be full-duplex, but MAY be eit...' RFC 2119 keyword, line 97: '... of such signals MUST NOT affect corre...' RFC 2119 keyword, line 153: '...-Control-Field-Compression MUST NOT be...' RFC 2119 keyword, line 162: '..., Protocol-Field-Compression SHOULD be...' RFC 2119 keyword, line 179: '... PPP NCP, another method of encapsulation defined under [4] SHOULD be...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (April 1994) is 10967 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: '5' is defined on line 292, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1548 (ref. '1') (Obsoleted by RFC 1661) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 1294 (ref. '4') (Obsoleted by RFC 1490, RFC 2427) -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W A Simpson 3 Internet Draft Daydreamer 4 expires in six months April 1994 6 PPP in Frame Relay 7 draft-ietf-pppext-frame-relay-03.txt 9 Status of this Memo 11 This document is a submission to the Point-to-Point Protocol Working 12 Group of the Internet Engineering Task Force (IETF). Comments should 13 be submitted to the ietf-ppp@merit.edu mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet Draft. Internet Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its Areas, 19 and its Working Groups. Note that other groups may also distribute 20 working documents as Internet Drafts. 22 Internet Drafts are draft documents valid for a maximum of six 23 months. Internet Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet 25 Drafts as reference material or to cite them other than as a 26 ``working draft'' or ``work in progress.'' 28 Please check the 1id-abstracts.txt listing contained in the 29 internet-drafts Shadow Directories on nic.ddn.mil, ds.internic.net, 30 venera.isi.edu, nic.nordu.net, or munnari.oz.au to learn the current 31 status of any Internet Draft. 33 Abstract 35 The Point-to-Point Protocol (PPP) [1] provides a standard method for 36 transporting multi-protocol datagrams over point-to-point links. 38 This document describes the use of Frame Relay for framing PPP 39 encapsulated packets. 41 Applicability 43 This specification is intended for those implementations which desire 44 to use 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 47 relationship between peers, and are not designed for multi-point or 48 multi-access environments. 50 1. Introduction 52 Frame Relay [2] is a relative newcomer to the serial link community. 53 Like X.25, the protocol was designed to provide virtual circuits for 54 connections between stations attached to the same Frame Relay 55 network. The improvement over X.25 is that Q.922 is restricted to 56 delivery of packets, and dispenses with sequencing and flow control, 57 simplifying the service immensely. 59 PPP uses ISO 3309 HDLC as a basis for its framing [3]. 61 When Frame Relay is configured as a point-to-point circuit, PPP can 62 use Frame Relay as a framing mechanism, ignoring its other features. 63 This is equivalent to the technique used to carry SNAP headers over 64 Frame Relay [4]. 66 At one time, it had been hoped that PPP in HDLC-like frames and Frame 67 Relay would co-exist on the same links. Unfortunately, the Q.922 68 method for expanding the address from 1 to 2 to 4 octets is not 69 indistinguishable from the ISO 3309 method, due to the structure of 70 its Data Link Connection Identifier (DLCI) subfields. Co-existance 71 is precluded. 73 2. Physical Layer Requirements 75 PPP treats Frame Relay framing as a bit-synchronous link. The link 76 MUST be full-duplex, but MAY be either dedicated (permanent) or 77 switched. 79 Interface Format 81 PPP presents an octet interface to the physical layer. There is 82 no provision for sub-octets to be supplied or accepted. 84 Transmission Rate 86 PPP does not impose any restrictions regarding transmission rate, 87 other than that of the particular Frame Relay interface. 89 Control Signals 91 Implementation of Frame Relay requires the provision of control 92 signals, which indicate when the link has become connected or 93 disconnected. These in turn provide the Up and Down events to the 94 LCP state machine. 96 Because PPP does not normally require the use of control signals, 97 the failure of such signals MUST NOT affect correct operation of 98 PPP. Implications are discussed in [2]. 100 Encoding 102 The definition of various encodings is the responsibility of the 103 DTE/DCE equipment in use, and is outside the scope of this 104 specification. 106 While PPP will operate without regard to the underlying 107 representation of the bit stream, Frame Relay requires NRZ 108 encoding. 110 3. The Data Link Layer 112 This specification uses the principles, terminology, and frame 113 structure described in "Multiprotocol Interconnect over Frame Relay" 114 [4]. 116 The purpose of this specification is not to document what is already 117 standardized in [4]. Instead, this document attempts to give a 118 concise summary and point out specific options and features used by 119 PPP. 121 3.1. Frame Format 123 As described in [4], Q.922 header address and control fields are 124 combined with the Network Layer Protocol Identifier (NLPID), which 125 identifies the encapsulation which follows. The fields are 126 transmitted from left to right. 128 0 1 2 3 129 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 130 +-+-+-+-+-+-+-+-+ 131 | Flag (0x7e) | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Q.922 Address | Control | NLPID(0xcf) | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | PPP Protocol | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 The PPP Protocol field and the following Information and Padding 139 fields are described in the Point-to-Point Protocol Encapsulation 141 [1]. 143 3.2. Modification of the Basic Frame 145 The Link Control Protocol can negotiate modifications to the basic 146 frame structure. However, modified frames will always be clearly 147 distinguishable from standard frames. 149 Address-and-Control-Field-Compression 151 Because the Address and Control field values are not constant, and 152 are modified as the frame is transported by the network switching 153 fabric, Address-and-Control-Field-Compression MUST NOT be 154 negotiated. 156 Protocol-Field-Compression 158 Note that unlike PPP in HDLC-like framing, the Frame Relay framing 159 does not align the Information field on a 32-bit boundary. 160 Alignment to a 32-bit boundary occurs when the NLPID is removed 161 and the Protocol field is compressed to a single octet. When this 162 improves throughput, Protocol-Field-Compression SHOULD be 163 negotiated. 165 4. In-Band Protocol Demultiplexing 167 The PPP NLPID (CF hex) and PPP Protocol fields easily distinguish the 168 PPP encapsulation from the other NLPID encapsulations described in 169 [4]. 171 The joining of the PPP and NLPID number space has an added advantage, 172 in that the LCP Protocol-Reject can be used to indicate NLPIDs that 173 are not recognized. This can eliminate "black-holes" that occur when 174 traffic is not supported. 176 For those network-layer protocols which have no PPP Protocol 177 assignment, or which have not yet been implemented under the PPP 178 encapsulation, or which have not been successfully negotiated by a 179 PPP NCP, another method of encapsulation defined under [4] SHOULD be 180 used. 182 Currently, there are no conflicts between NLPID and PPP Protocol 183 values. If a future implementation is configured to send a NLPID 184 value which is the same as a compressed Protocol field, that Protocol 185 field MUST NOT be sent compressed. 187 On reception, the first octet following the header is examined. If 188 the octet is zero, it MUST be assumed that the packet is formatted 189 according to [4]. 191 PPP encapsulated packets always have a non-zero octet following the 192 header. If the octet is not the PPP NLPID value (CF hex), and 193 Protocol-Field-Compression is enabled, and the associated NCP has 194 been negotiated, then it is expected to be a compressed PPP Protocol 195 value. Otherwise, it MUST be assumed that the packet is formatted 196 according to [4]. 198 The Protocol field value 0x00cf is not allowed (reserved) to avoid 199 ambiguity when Protocol-Field-Compression is enabled. The value MAY 200 be treated as a PPP Protocol that indicates that another PPP Protocol 201 packet follows. 203 Initial LCP packets contain the sequence cf-c0-21 following the 204 header. When a LCP Configure-Request packet is received and 205 recognized, the PPP link enters Link Establishment phase. 207 The accidental connection of a link to feed a multipoint network (or 208 multicast group) SHOULD result in a misconfiguration indication. 209 This can be detected by multiple responses to the LCP Configure- 210 Request with the same Identifier, coming from different framing 211 addresses. Some implementations might be physically unable to either 212 log or report such information. 214 Once PPP has entered the Link Establishment phase, packets with other 215 NLPID values MUST NOT be sent, and on receipt such packets MUST be 216 silently discarded, until the PPP link enters the Network-Layer 217 Protocol phase. 219 Once PPP has entered the Network-Layer Protocol phase, and 220 successfully negotiated a particular NCP for a PPP Protocol, if a 221 frame arrives using another equivalent data encapsulation defined in 222 [4], the PPP Link MUST re-enter Link Establishment phase and send a 223 new LCP Configure-Request. This prevents "black-holes" that occur 224 when the peer loses state. 226 An implementation which requires PPP link configuration, and other 227 PPP negotiated features (such as authentication), MAY enter 228 Termination phase when configuration fails. Otherwise, when the 229 Configure-Request sender reaches the Max-Configure limit, it MUST 230 fall back to send only frames encapsulated according to [4]. 232 5. Out-of-Band signaling 234 There is no generally agreed method of out-of-band signalling. Until 235 such a method is universally available, an implementation MUST use 236 In-Band Protocol Demultiplexing for both Permanent and Switched 237 Virtual Circuits. 239 6. Configuration Details 241 The following Configuration Options are recommended: 243 Magic Number 244 Protocol Field Compression 246 The standard LCP configuration defaults apply to Frame Relay links, 247 except Maximum-Receive-Unit (MRU). 249 To ensure interoperability with existing Frame Relay implementations, 250 the initial MRU is 1600 octets [4]. This only affects the minimum 251 required buffer space available for receiving packets, not the size 252 of packets sent. 254 The typical network feeding the link is likely to have a MRU of 255 either 1500, or 2048 or greater. To avoid fragmentation, the 256 Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT 257 exceed 1500, unless a peer MRU of 2048 or greater is specifically 258 negotiated. 260 Some Frame Relay switches are only capable of 262 octet frames. It 261 is not recommended that anyone deploy or use a switch which is 262 capable of less than 1600 octet frames. However, PPP implementations 263 MUST be configurable to limit the size of LCP packets which are sent 264 to 259 octets (which leaves room for the NLPID and Protocol fields), 265 until LCP negotiation is complete. 267 XID negotiation is not required to be supported for links which are 268 capable of PPP negotiation. 270 Inverse ARP is not required to be supported for PPP links. That 271 function is provided by PPP NCP negotiation. 273 Security Considerations 275 Security issues are not discussed in this memo. 277 References 279 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC 280 1548, December 1993. 282 [2] CCITT Recommendation Q.922, "ISDN Data Link Layer Specification 283 for Frame Mode Bearer Services", International Telegraph and 284 Telephone Consultative Committee, 1992. 286 [3] Simpson, W., Editor, "PPP in HDLC-like Framing", work in 287 progress. 289 [4] Bradley, T., Brown, C., and Malis, A., "Multiprotocol 290 Interconnect over Frame Relay", RFC 1294, January 1992. 292 [5] ISO/IEC TR 9577:1990(E), "Information technology - 293 Telecommunications and Information exchange between systems - 294 Protocol Identification in the network layer", 1990-10-15. 296 Acknowledgments 298 This design was inspired by the paper "Parameter Negotiation for the 299 Multiprotocol Interconnect", Keith Sklower and Clifford Frost, 300 University of California, Berkeley, 1992, unpublished. 302 Chair's Address 304 The working group can be contacted via the current chair: 306 Fred Baker 307 Advanced Computer Communications 308 315 Bollay Drive 309 Santa Barbara, California 93117 311 EMail: fbaker@acc.com 313 Author's Address 315 Questions about this memo can also be directed to: 317 William Allen Simpson 318 Daydreamer 319 Computer Systems Consulting Services 320 1384 Fontaine 321 Madison Heights, Michigan 48071 323 Bill.Simpson@um.cc.umich.edu 324 bsimpson@MorningStar.com 325 Table of Contents 327 1. Introduction .......................................... 1 329 2. Physical Layer Requirements ........................... 1 331 3. The Data Link Layer ................................... 2 332 3.1 Frame Format .................................... 2 333 3.2 Modification of the Basic Frame ................. 3 335 4. In-Band Protocol Demultiplexing ....................... 4 337 5. Out-of-Band signaling ................................. 5 339 6. Configuration Details ................................. 5 341 SECURITY CONSIDERATIONS ...................................... 7 343 REFERENCES ................................................... 7 345 ACKNOWLEDGEMENTS ............................................. 7 347 CHAIR'S ADDRESS .............................................. 8 349 AUTHOR'S ADDRESS ............................................. 8