idnits 2.17.1 draft-ietf-l2tpext-pwe3-hdlc-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 490. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 467. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 474. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 480. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 494), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (September 2005) is 6769 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) No issues found here. Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Carlos Pignataro 3 Internet-Draft W. Mark Townsley 4 Category: Standards Track Cisco Systems 5 Expiration Date: March 2006 6 September 2005 8 HDLC Frames over L2TPv3 10 draft-ietf-l2tpext-pwe3-hdlc-07.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). All Rights Reserved. 39 Abstract 41 The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a 42 protocol for tunneling a variety of data link protocols over IP 43 networks. This document describes the specifics of how to tunnel 44 High-Level Data Link Control (HDLC) frames over L2TPv3. 46 Contents 48 Status of this Memo.......................................... 1 50 1. Introduction.............................................. 3 51 1.1 Abbreviations......................................... 3 53 2. Control Connection Establishment.......................... 3 55 3. HDLC Link Status Notification and Session Establishment... 3 56 3.1 L2TPv3 Session Establishment.......................... 4 57 3.2 L2TPv3 Session Teardown............................... 6 58 3.3 L2TPv3 Session Maintenance............................ 6 59 3.4 Use of Circuit Status AVP for HDLC.................... 6 61 4. Encapsulation............................................. 7 62 4.1 Data Packet Encapsulation............................. 7 63 4.2 Data Packet Sequencing................................ 8 64 4.3 MTU Considerations.................................... 8 66 5. Applicability Statement................................... 8 68 6. Security Considerations................................... 9 70 7. IANA Considerations....................................... 9 71 7.1 Pseudowire Type....................................... 9 72 7.2 Result Code AVP Values................................ 10 74 8. Acknowledgments........................................... 10 76 9. References................................................ 10 77 9.1 Normative References.................................. 10 78 9.2 Informative References................................ 10 80 10. Authors' Addresses....................................... 10 82 Specification of Requirements 84 In this document, several words are used to signify the requirements 85 of the specification. These words are often capitalized. The key 86 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 87 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 88 are to be interpreted as described in [RFC2119]. 90 1. Introduction 92 [RFC3931] defines a base protocol for Layer 2 Tunneling over IP 93 networks. This document defines the specifics necessary for tunneling 94 HDLC Frames over L2TPv3. Such emulated circuits are referred to as 95 HDLC Pseudowires (HDLCPWs). 97 Protocol specifics defined in this document for L2TPv3 HDLCPWs 98 include those necessary for simple point-to-point (e.g., between two 99 L2TPv3 nodes) frame encapsulation, and simple interface up and 100 interface down notifications. 102 The reader is expected to be very familiar with the terminology and 103 protocol constructs defined in [RFC3931]. 105 1.1 Abbreviations 107 HDLC High-Level Data Link Control 108 HDLCPW HDLC Pseudowire 109 LAC L2TP Access Concentrator (See [RFC3931]) 110 LCCE L2TP Control Connection Endpoint (See [RFC3931]) 111 PW Pseudowire 113 2. Control Connection Establishment 115 In order to tunnel an HDLC link over IP using L2TPv3, an L2TPv3 116 Control Connection MUST first be established as described in 117 [RFC3931]. The L2TPv3 SCCRQ Control Message and corresponding SCCRP 118 Control Message MUST include the HDLC Pseudowire Type of 0x0006 (See 119 IANA Considerations Section), in the Pseudowire Capabilities List as 120 defined in 5.4.3 of [RFC3931]. This identifies the control connection 121 as able to establish L2TP sessions to support HDLC Pseudowires 122 (HDLCPWs). 124 An LCCE MUST be able to uniquely identify itself in the SCCRQ and 125 SCCRP messages via a globally unique value. By default, this is 126 advertised via the structured Router ID AVP [RFC3931], though the 127 unstructured Hostname AVP [RFC3931] MAY be used to identify LCCEs as 128 well. 130 3. HDLC Link Status Notification and Session Establishment 132 This section specifies how the status of an HDLC interface is 133 reported between two LCCEs, and the associated L2TP session creation 134 and deletion that occurs. 136 3.1 L2TPv3 Session Establishment 138 Associating an HDLC serial interface with a PW and its transition to 139 "Ready" or "Up" results in the establishment of an L2TP session via 140 the standard three-way handshake described in Section 3.4.1 of 141 [RFC3931]. For purposes of this discussion, the action of locally 142 associating an interface running HDLC with a PW by local 143 configuration or otherwise is referred to as "provisioning" the HDLC 144 interface. The transition of the interface to "ready" or "up" will be 145 referred to as the interface becoming ACTIVE. The transition of the 146 interface to "not-ready" or "down" will be referred to as the 147 interfacing becoming INACTIVE. 149 An LCCE MAY initiate the session immediately upon association with an 150 HDLC interface, or wait until the interface becomes ACTIVE before 151 attempting to establish an L2TP session. Waiting until the interface 152 transitions to ACTIVE may be preferred as it delays allocation of 153 resources until absolutely necessary. 155 The Pseudowire Type AVP defined in Section 5.4.4 of [RFC3931], 156 Attribute Type 68, MUST be present in the ICRQ messages and MUST 157 include the Pseudowire Type of 0x0006 for HDLCPWs. 159 The Circuit Status AVP (see Section 3.4) MUST be present in the ICRQ, 160 ICRP messages and MAY be present in the SLI message for HDLCPWs. 162 Following is an example of the L2TP messages exchanged for an HDLCPW 163 which is initiated after an HDLC interface is provisioned and becomes 164 ACTIVE. 166 LCCE (LAC) A LCCE (LAC) B 167 ------------------ ------------------ 168 HDLC Interface Provisioned 169 HDLC Interface Provisioned 170 HDLC Interface ACTIVE 172 ICRQ (status = 0x03) ----> 174 HDLC Interface ACTIVE 176 <---- ICRP (status = 0x03) 178 L2TP session established, 179 OK to send data into tunnel 181 ICCN -----> 182 L2TP session established, 183 OK to send data into tunnel 185 In the example above, an ICRQ is sent after the interface is 186 provisioned and becomes ACTIVE. The Circuit Status AVP indicates that 187 this link is ACTIVE and New (0x03). The Remote End ID AVP [RFC3931] 188 MUST be present in the ICRQ in order to identify the HDLC link 189 (together with the identity of the LCCE itself as defined in Section 190 2) to associate the L2TP session with. The Remote End ID AVP defined 191 in [RFC3931] is of opaque form and variable length, though one MUST 192 at a minimum support use of an unstructured four-octet value that is 193 known to both LCCEs (either by direct configuration, or some other 194 means). The exact method of how this value is configured, retrieved, 195 discovered, or otherwise determined at each LCCE is outside the scope 196 of this document. 198 As with the ICRQ, the ICRP is sent only after the associated HDLC 199 interface transitions to ACTIVE as well. If LCCE B had not been 200 provisioned for the interface identified in the ICRQ, a CDN would 201 have been immediately returned indicating that the associated link 202 was not provisioned or available at this LCCE. LCCE A SHOULD then 203 exhibit a periodic retry mechanism. If so, the period and maximum 204 number of retries MUST be configurable. 206 An Implementation MAY send an ICRQ or ICRP before an HDLC interface 207 is ACTIVE, as long as the Circuit Status AVP reflects that the link 208 is INACTIVE and an SLI is sent when the HDLC interface becomes ACTIVE 209 (see Section 3.3). 211 The ICCN is the final stage in the session establishment, confirming 212 the receipt of the ICRP with acceptable parameters to allow 213 bidirectional traffic. 215 3.2 L2TPv3 Session Teardown 217 In the event a link is removed (unprovisioned) at either LCCE, the 218 associated L2TP session MUST be torn down via the CDN message defined 219 in Section 3.4.3 of [RFC3931]. 221 General Result Codes regarding L2TP session establishment are defined 222 in [RFC3931]. Additional HDLC result codes are defined as follows: 224 20 - HDLC Link was deleted permanently (no longer provisioned) 225 21 - HDLC Link has been INACTIVE for an extended period of time 227 3.3 L2TPv3 Session Maintenance 229 HDLCPWs over L2TP make use of the Set Link Info (SLI) control message 230 defined in [RFC3931] to signal HDLC link status notifications between 231 PEs. The SLI message is a single message that is sent over the L2TP 232 control channel, signaling the interface state change. 234 The SLI message MUST be sent any time there is a status change of any 235 values identified in the Circuit Status AVP. The only exception to 236 this are the initial ICRQ, ICRP and CDN messages which establish and 237 teardown the L2TP session itself. The SLI message may be sent from 238 either PE at any time after the first ICRQ is sent (and perhaps 239 before an ICRP is received, requiring the peer to perform a reverse 240 Session ID lookup). 242 All sessions established by a given control connection utilize the 243 L2TP Hello facility defined in Section 4.4 of [RFC3931] for session 244 keepalive. This gives all sessions basic dead peer and path detection 245 between PEs. 247 3.4 Use of Circuit Status AVP for HDLC 249 HDLC reports Circuit Status with the Circuit Status AVP defined in 250 [RFC3931], Attribute Type 71. For reference, this AVP is shown below: 252 0 1 253 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Reserved |N|A| 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 The Value is a 16 bit mask with the two least significant bits 259 defined and the remaining bits reserved for future use. Reserved bits 260 MUST be set to 0 when sending, and ignored upon receipt. 262 The N (New) bit SHOULD be set to one (1) if the Circuit Status 263 indication is for a new HDLC circuit, zero (0) otherwise. 265 The A (Active) bit indicates whether the HDLC interface is ACTIVE (1) 266 or INACTIVE (0). 268 4. Encapsulation 270 4.1 Data Packet Encapsulation 272 HDLCPWs use the default encapsulations defined in [RFC3931] for 273 demultiplexing, sequencing, and flags. The HDLCPW Type over L2TP is 274 intended to operate in an "interface to interface" or "port to port" 275 fashion, passing all HDLC data and control PDUs over the PW. The HDLC 276 PDU is stripped of flags and trailing FCS, bit/byte unstuffing is 277 performed, and the remaining data, including the address, control and 278 protocol fields, transported over the PW. 280 Since all packets are passed in a largely transparent manner over the 281 HDLCPW, any protocol which has HDLC-like framing may utilize the 282 HDLCPW mode, including PPP, Frame-Relay ("port to port" Frame-Relay 283 transport), X.25 (LAPB), etc. In such cases, the negotiations and 284 signaling of the specific protocols transported over the HDLCPW take 285 place between the Remote Systems. A non-exhaustive list of examples 286 and considerations of this transparent nature include: 288 o When the HDLCPW transports Point-to-Point Protocol (PPP) 289 traffic, PPP negotiations (Link Control Protocol, optional 290 authentication, and Network Control Protocols) are performed 291 between Remote Systems, and LCCEs do not participate in these 292 negotiations. 294 o When the HDLCPW transports Frame-Relay traffic, PVC status 295 management procedures (Local Management Interface) take place 296 between Remote Systems, and LCCEs do not participate in LMI. 297 Additionally, individual Frame-Relay virtual-circuits are not 298 visible to the LCCEs and the FECN, BECN and DE bits are 299 transported transparently. 301 o When the HDLCPW transports X.25 (LAPB) traffic, LCCEs do not 302 function as either LAPB DCE or DTE devices. 304 On the other hand, exceptions include cases where direct access to 305 the HDLC interface is required, or modes which operate on the flags, 306 FCS, or bit/byte unstuffing that is performed before sending the HDLC 307 PDU over the PW. An example of this is PPP ACCM negotiation. 309 4.2 Data Packet Sequencing 311 Data Packet Sequencing MAY be enabled for HDLCPWs. The sequencing 312 mechanisms described in Section 4.6.1 of [RFC3931] MUST be used for 313 signaling sequencing support. HDLCPWs over L2TP MUST request the 314 presence of the L2TPv3 Default L2-Specific Sublayer defined in 315 Section 4.6 of [RFC3931] when sequencing is enabled, and MAY request 316 its presence at all times. 318 4.3 MTU Considerations 320 With L2TPv3 as the tunneling protocol, the packet resulted from the 321 encapsulation is N bytes longer than HDLC frame without the flags or 322 FCS. The value of N depends on the following fields: 324 L2TP Session Header: 325 Flags, Ver, Res - 4 octets (L2TPv3 over UDP only) 326 Session ID - 4 octets 327 Cookie Size - 0, 4 or 8 octets 328 L2-Specific Sublayer - 0 or 4 octets (i.e., using sequencing) 330 Hence the range for N in octets is: 332 N = 4-16, L2TPv3 data messages are over IP; 333 N = 16-28, L2TPv3 data messages are over UDP; 334 (N does not include the IP header). 336 The MTU and fragmentation implications resulting from this are 337 discussed in Section 4.1.4 of [RFC3931]. 339 5. Applicability Statement 341 HDLC Pseudowires support a "port to port" or "interface to interface" 342 deployment model operating in a point-to-point fashion. In addition 343 to the transport of HDLC frames, a natural application of HDLCPWs 344 allows for the transport of any protocol using an HDLC-like framing. 346 The HDLCPW emulation over a packet switched network (PSN) has the 347 following characteristics in relationship to the native service: 349 o HDLC data and control fields are transported transparently (see 350 Section 4.1). The specific negotiations and signaling of the 351 protocol being transported are performed between Remote Systems 352 transparently, and the LCCE does not participate in them. 354 o The trailing FCS (Frame Check Sequence) containing a CRC (Cyclic 355 Redundancy Check) is stripped at the ingress LCCE and not 356 transported over HDLCPWs. It is therefore regenerated at the 357 egress LCCE (see Section 4.1). This means that the FCS may not 358 accurately reflect errors on the end-to-end HDLC link. Errors or 359 corruption introduced in the HDLCPW payload during encapsulation 360 or transit accross the packet switched network may not be 361 detected. This lack of integrity check transparency may not be 362 of concern if it is known that the inner payloads or upper 363 protocols transported perform their own error and integrity 364 checking. To allow for payload integrity checking transparency 365 on HDLCPWs using L2TP over IP or L2TP over UDP/IP, the L2TPv3 366 session can utilize IPSec as specified in Section 4.1.3 of 367 [RFC3931]. 369 o HDLC link status notification is provided using the Circuit 370 Status AVP in the SLI message (see Section 3.4). 372 o The length of the resulting L2TPv3 packet is longer than the 373 encpsulated HDLC frame without flags and FCS (see Section 4.3), 374 with resulting MTU and fragmentation implications discussed in 375 Section 4.1.4 of [RFC3931]. 377 o The packet switched network may reorder, duplicate, or silently 378 drop packets. Sequencing may be enabled in the HDLCPW for some 379 or all packets to detect lost, duplicate, or out-of-order 380 packets on a per-session basis (see Section 4.2). 382 o The faithfulness of an HDLCPW may be increased by leveraging 383 Quality of Service features of the LCCEs and the the underlying 384 PSN. 386 6. Security Considerations 388 HDLC over L2TPv3 is subject to the security considerations defined in 389 [RFC3931]. There are no additional considerations specific to 390 carrying HDLC that are not present carrying other data link types. 392 7. IANA Considerations 394 7.1 Pseudowire Type 396 The signaling mechanisms defined in this document rely upon the 397 allocation of an HDLC Pseudowire Type (see Pseudowire Capabilities 398 List as defined in 5.4.3 of [RFC3931] and L2TPv3 Pseudowire Types in 399 10.6 of [RFC3931]) by the IANA (number space created as part of 400 publication of [RFC3931]). The HDLC Pseudowire Type is defined in 401 Section 2 of this specification: 403 L2TPv3 Pseudowire Types 404 ----------------------- 406 0x0006 - HDLC Pseudowire Type 408 7.2 Result Code AVP Values 410 This number space is managed by IANA as described in section 2.3 of 411 [BCP0068]. Two new L2TP Result Codes for the CDN message appear in 412 section 3.2. The following is a summary: 414 Result Code AVP (Attribute Type 1) Values 415 ----------------------------------------- 417 20 - HDLC Link was deleted permanently (no longer provisioned) 418 21 - HDLC Link has been INACTIVE for an extended period of time 420 8. Acknowledgments 422 Thanks to Sudhir Rustogi and George Wilkie for valuable input. Maria 423 Alice Dos Santos provided helpful review and comment. Many thanks to 424 Mark Lewis for providing review and clarifying comments during IETF 425 Last Call. 427 9. References 429 9.1 Normative References 431 [RFC3931] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling 432 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 434 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 435 Requirement Levels", BCP 14, RFC 2119, March 1997. 437 9.2 Informative References 439 [BCP0068] Townsley, W., Layer Two Tunneling Protocol (L2TP) 440 Internet Assigned Numbers Authority (IANA) 441 Considerations Update", RFC3438, BCP0068, December 2002 443 10. Authors' Addresses 445 Carlos Pignataro 446 Cisco Systems 447 7025 Kit Creek Road 448 PO Box 14987 449 Research Triangle Park, NC 27709 450 cpignata@cisco.com 451 W. Mark Townsley 452 Cisco Systems 453 7025 Kit Creek Road 454 PO Box 14987 455 Research Triangle Park, NC 27709 456 mark@townsley.net 458 Intellectual Property Statement 460 The IETF takes no position regarding the validity or scope of any 461 Intellectual Property Rights or other rights that might be claimed to 462 pertain to the implementation or use of the technology described in 463 this document or the extent to which any license under such rights 464 might or might not be available; nor does it represent that it has 465 made any independent effort to identify any such rights. Information 466 on the procedures with respect to rights in RFC documents can be 467 found in BCP 78 and BCP 79. 469 Copies of IPR disclosures made to the IETF Secretariat and any 470 assurances of licenses to be made available, or the result of an 471 attempt made to obtain a general license or permission for the use of 472 such proprietary rights by implementers or users of this 473 specification can be obtained from the IETF on-line IPR repository at 474 http://www.ietf.org/ipr. 476 The IETF invites any interested party to bring to its attention any 477 copyrights, patents or patent applications, or other proprietary 478 rights that may cover technology that may be required to implement 479 this standard. Please address the information to the IETF at 480 ietf-ipr@ietf.org. 482 Disclaimer of Validity 484 This document and the information contained herein are provided on 485 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 486 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 487 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 488 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 489 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 490 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 492 Copyright Statement 494 Copyright (C) The Internet Society (2005). 496 This document is subject to the rights, licenses and restrictions 497 contained in BCP 78, and except as set forth therein, the authors 498 retain all their rights. 500 Acknowledgment 502 Funding for the RFC Editor function is currently provided by the 503 Internet Society.