idnits 2.17.00 (12 Aug 2021) /tmp/idnits6638/draft-vasavada-l2tpext-fr-svctype-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 3) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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 ([2], [3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (February 2001) is 7765 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) -- Looks like a reference, but probably isn't: 'TBD' on line 156 -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Nishit Vasavada 2 INTERNET DRAFT Amber Networks, Inc. 3 Jim Boyle 4 Level 3 Communications, LLC. 5 Chris Garner 6 Qwest Communications 7 Serge Maskalik 8 iVMG, Inc. 9 Vijay Gill 10 Metromedia Fiber Network, Inc. 12 February 2001 14 Frame Relay Service Type for L2TP 15 17 1. Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC 2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet- Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 2. Abstract 40 The Layer Two Tunneling Protocol (L2TP) [1] provides a standard 41 method for tunneling PPP [2] packets. In accordance with the L2TP 42 Service Type specification [3], this document provides a solution 43 for transporting Frame Relay (FR) [4] over a session in an L2TP 44 tunnel. 46 3. Specification of Requirements 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC 2119 [5]. 52 4. Introduction 54 The Layer Two Tunneling Protocol (L2TP) [1] provides a standard 55 method for tunneling PPP [2] packets. The L2TP Service Type [3] 56 allows layer 1 and layer 2 traffic to be tunneled through an L2TP 57 tunnel. 59 This document presents a solution to carry the ever popular Frame 60 Relay circuit traffic over the IP network through the features 61 offered by L2TP and the Service Type attribute. 63 It talks about the use of [3] for setting up an L2TP tunnel and 64 session containing FR traffic, and the signaling of some of the 65 Frame Relay parameters. 67 5. FR Service Type 69 A FR Service Type value of [TBD] MUST be used. The encoding of the 70 Service Type AVP remains as specified in [3]. 72 6. Tunnel Establishment 74 The basic tunnel establishment procedures defined in [1] and [3] are 75 unchanged. The FR Service Type value [TBD] MUST be included in the 76 Service Capabilities List AVP. 78 7. Session Establishment 80 The basic call establishment procedures defined in [1] and [3] remain 81 unchanged. The FR Service Type value [TBD] MUST be used in the 82 Service Type AVP of an ICRQ or OCRQ. 84 7.1. Use of the Sub-Address AVP 86 As specified in [1], the Sub-Address AVP, Attribute Type 23, is 87 included in ICRQ or OCRQ and is used to encode additional dialing 88 information. For the purpose of this specification, the Sub-Address 89 AVP will be used to encode the source and destination DLCI numbers, 90 and interface information. 92 Additional non-addressing information is discussed in the following 93 sections. 95 The Sub-Address AVP is encoded as follows: 97 0 1 2 3 98 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 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 |1|H| rsvd | Length | 0 | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | 23 | Attribute Value... 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 [until Length is reached]... | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 The attribute value may be a simple ASCII string. For example, a 108 source interface serial 1/1 and DLCI 100, and a destination interface 109 serial 1/1 with DLCI 200 could be represented as "serial 1/1 DLCI 110 100, serial 1/1 DLCI 200". The format of the information contained 111 in this AVP should be agreed on by the administrators at the two L2TP 112 peers. 114 When employing the Sub-Address AVP for this purpose, the AVP is 115 mandatory (the M-bit MUST be set to 1). The AVP MAY be hidden (the 116 H-bit set to 0 or 1). 118 7.2. FR Payload Message Format 120 The L2TP payload header format defined in [1] remains unchanged while 121 carrying data for a Frame Relay circuit. Entire Frame Relay PDU 122 will be carried, subject to the following requirements: 124 When transporting FR frames over an L2TP session the following rules 125 MUST be followed: 127 o All the Frame Relay packets will be preceded by a four byte code 128 [TBD] in the L2TP payload packet. This code will allow L2TP to 129 de-multiplex if additional functionality has to be added in future 130 for signaling (please see the signaling and LMI sections). 132 o The beginning and ending FR 'Flag' fields (one octet each) MUST be 133 removed from the FR frame before it is encapsulated as L2TP 134 payload. The destination LAC/LNS MUST insert new flags when 135 reconstructing the FR frame for transmission to the FRAD. 137 o The FCS field MUST be removed from the FR frame before it is 138 carried in L2TP It MUST be recalculated at the other end. This 139 does create a potential problem since L2TP does not offer checksum, 140 and UDP checksum is optional. Work is needed in this area to 141 guarantee integrity of the packet on the remote side. 143 The encapsulated Frame Relay packet looks like this: 145 0 1 2 3 146 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 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 |T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Tunnel ID | Session ID | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Ns (opt) | Nr (opt) | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Offset Size (opt) | Offset pad... (opt) 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Four byte code [TBD] | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | FR Header 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | FR Payload... 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 As is true for the PPP traffic carried by L2TP, the frame size should 167 consider the MTU and the additional headers to avoid IP 168 fragmentation. 170 7.3. FR Local Management Interface (LMI) 172 This draft does not discuss the LMI implications. Future work is 173 necessary in this area. 175 8. Effects on Standard AVPs 177 If FR frames are being tunneled in accordance with this document, 178 then the following Call Management AVPs MAY be ignored: 180 Bearer Type 181 Framing Type 182 Called Number 183 Calling Number 184 Initial Received LCP CONFREQ 185 Last Sent LCP CONFREQ 186 Last Received LCP CONFREQ 187 Proxy Authen Type 188 Proxy Authen Name 189 Proxy Authen Challenge 190 Proxy Authen ID 191 Proxy Authen Response 192 ACCM 194 9. Future work 196 This section provides a list of things we need work on: 198 o Signaling: The interface and DLCI information is conveyed through 199 L2TP control packets. However, the frame parameters such as CIR, 200 Be, and Bc related information is not covered. 202 o LMI through the network 204 o Data integrity (as mentioned in FR Payload Message Format section, 205 currently there is no way to verify the data integrity due to 206 lack of FR FCS, L2TP checksum, and optional UDP checksum. 208 10. Security Considerations 210 All the underlying L2TP Security considerations remain, though no 211 'new' ones are introduced? 213 11. IANA Considerations 215 To be completed. 217 12. Acknowledgments 219 Many thanks to Danny McPherson, Chi Fai Ho and Himansu Sahu for 220 their help in reviewing this draft. 222 13. References 224 [1] Townsley, et. al., "Layer Two Tunneling Protocol L2TP", RFC 225 2661, February 1999. 227 [2] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 228 RFC 1661, July 1994. 230 [3] McPherson D., Nanji S., "L2TP Service Type", "Work in 231 Progress", August 2000. 233 [4] Frame Relay, ANSI T1.618 235 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 236 Levels", RFC 2119, March 1997. 238 14. Authors' Addresses 240 Nishit Vasavada 241 Amber Networks, Inc. 242 48664 Milmont Drive 243 Fremont, CA 94538 244 Phone: +1 510.683.8698 245 Email: nishit@ambernetworks.com 247 Jim Boyle 248 Level 3 Communications, LLC. 249 1025 Eldorado Blvd. 250 Broomfield, CO 80021 251 Phone: +1 720.888.1192 252 Email: jboyle@level3.net 254 Serge Maskalik 255 iVMG, Inc. 256 1020 Rincon Circle 257 San Jose, CA 95131 258 Phone: +1 408.468.0480 259 Email: serge@ivmg.net 261 Chris Garner 262 Qwest Communications 263 950 Seventeenth Street, 21 Floor 264 Denver, CO 80202 265 Email: cgarner@qwest.net 267 Vijay Gill 268 Metromedia Fiber Network, Inc. 269 8075 Leesburg Pike 270 Vienna, VA 22182 271 Phone: +1 410.262.0660 272 Email: vgill@mfnx.net