idnits 2.17.1 draft-ietf-l2tpext-pwe3-fr-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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 628. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 618. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 632), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** 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 6790 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) == Outdated reference: A later version (-07) exists of draft-ietf-l2tpext-pwe3-hdlc-06 Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Mark Townsley 3 Internet-Draft George Wilkie 4 Category: Standards Track Skip Booth 5 Expiration Date: March 2006 Stewart Bryant 6 Cisco Systems 8 Jed Lau 10 September 2005 12 Frame-Relay over L2TPv3 14 draft-ietf-l2tpext-pwe3-fr-07.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). All Rights Reserved. 43 Abstract 45 The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a 46 protocol for tunneling a variety of data link protocols over IP 47 networks. This document describes the specifics of how to tunnel 48 Frame-Relay over L2TPv3, including frame encapsulation, virtual- 49 circuit creation, deletion, and status change notification. 51 Contents 53 Status of this Memo.......................................... 1 55 1. Introduction.............................................. 3 56 1.1 Abbreviations......................................... 3 58 2. Control Connection Establishment.......................... 3 60 3. PVC Status Notification and Session Establishment......... 4 61 3.1 L2TPv3 Session Establishment.......................... 4 62 3.2 L2TPv3 Session Teardown............................... 6 63 3.3 L2TPv3 Session Maintenance............................ 6 64 3.4 Use of the Circuit Status AVP for Frame-Relay......... 7 65 3.5 Frame-Relay Header Length AVP......................... 7 67 4. Encapsulation............................................. 8 68 4.1 Data Packet Encapsulation............................. 8 69 4.2 Data Packet Sequencing................................ 9 70 4.3 MTU Considerations.................................... 10 72 5. Applicability Statement................................... 10 74 6. Security Considerations................................... 11 76 7. IANA Considerations....................................... 11 77 7.1 Pseudowire Type....................................... 11 78 7.2 Result Code AVP Values................................ 11 79 7.3 Control Message Attribute Value Pairs (AVPs).......... 12 81 8. Acknowledgments........................................... 12 83 9. References................................................ 12 84 9.1 Normative References.................................. 12 85 9.2 Informative References................................ 12 87 10. Authors' Addresses....................................... 13 89 Specification of Requirements 91 In this document, several words are used to signify the requirements 92 of the specification. These words are often capitalized. The key 93 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 94 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 95 are to be interpreted as described in [RFC2119]. 97 1. Introduction 99 [RFC3931] defines a base protocol for Layer 2 Tunneling over IP 100 networks. This document defines the specifics necessary for tunneling 101 Frame-Relay over L2TPv3. Such emulated circuits are referred to as 102 Frame-Relay Pseudowires (FRPWs). 104 Protocol specifics defined in this document for L2TPv3 FRPWs 105 operating in a "virtual circuit to virtual circuit" mode include 106 those necessary for frame encapsulation, PVC creation, deletion, and 107 status change notification. Frame-Relay traffic may also be 108 transported in a "port to port" or "interface to interface" fashion 109 using HDLC Pseudowires as defined in [HDLC]. Support for Switched 110 Virtual Circuits (SVCs) and Switched/soft Permanent Virtual Circuits 111 (SPVCs) are outside the scope of this document. 113 The reader is expected to be very familiar with the terminology and 114 protocol constructs defined in [RFC3931]. 116 1.1 Abbreviations 118 FR Frame-Relay 119 FRPW Frame-Relay Pseudowire 120 LCCE L2TP Control Connection Endpoint (See [RFC3931]) 121 PVC Permanent virtual circuit 122 PW Pseudowire 123 VC Virtual circuit 125 2. Control Connection Establishment 127 In order to tunnel a Frame-Relay circuit over IP using L2TPv3, an 128 L2TPv3 Control Connection MUST first be established as described in 129 [RFC3931]. The L2TPv3 SCCRQ Control Message and corresponding SCCRP 130 Control Message MUST include the Frame-Relay DLCI PW Type of 0x0001 131 (See IANA Considerations Section), in the Pseudowire Capabilities 132 List as defined in 5.4.3 of [RFC3931]. This identifies the control 133 connection as able to establish L2TP sessions to support Frame-Relay 134 Pseudowires (FRPWs). 136 An LCCE MUST be able to uniquely identify itself in the SCCRQ and 137 SCCRP messages via a globally unique value. By default, this is 138 advertised via the structured Router ID AVP [RFC3931], though the 139 unstructured Hostname AVP [RFC3931] MAY be used to identify LCCEs as 140 well. 142 3. PVC Status Notification and Session Establishment 144 This section specifies how the status of a PVC is reported between 145 two LCCEs. This includes what should happen when a PVC is created, 146 deleted or when it changes state between ACTIVE and INACTIVE. When 147 emulating a Frame-Relay service, if the procedures for PVC status 148 management defined in [Q933] Annex A are being used between an LCCE 149 and the attached Remote System, an LCCE MUST participate in them (see 150 Section 3.3). 152 3.1 L2TPv3 Session Establishment 154 PVC creation (provisioning) results in establishment of an L2TP 155 session via the standard three-way handshake described in Section 156 3.4.1 of [RFC3931]. An LCCE MAY initiate the session immediately upon 157 PVC creation, or wait until the PVC state transitions to ACTIVE 158 before attempting to establish a session for the PVC. Waiting until 159 the PVC transitions to ACTIVE may be preferred as it delays 160 allocation of L2TP resources until absolutely necessary. 162 The Pseudowire Type AVP defined in Section 5.4.4 of [RFC3931], 163 Attribute Type 68, MUST be present in the ICRQ messages and MUST 164 include the Frame-Relay DLCI PW Type of 0x0001 for FRPWs. 166 The Circuit Status AVP (see Section 3.4) MUST be present in the ICRQ 167 and ICRP messages, and MAY be present in the SLI message for FRPWs. 169 The Frame-Relay Header Length AVP (see Section 3.5) MAY be present in 170 the ICRQ and ICRP messages. 172 Following is an example of the L2TP messages exchanged for an FRPW 173 which is initiated after a new PVC is provisioned and becomes ACTIVE. 175 LCCE (LAC) A LCCE (LAC) B 176 ------------------ ------------------ 177 FR PVC Provisioned 178 FR PVC Provisioned 179 FR PVC ACTIVE 181 ICRQ (status = 0x03) ----> 183 FR PVC ACTIVE 185 <---- ICRP (status = 0x03) 187 L2TP session established, 188 OK to send data into tunnel 190 ICCN -----> 191 L2TP session established, 192 OK to send data into tunnel 194 In the example above, an ICRQ is sent after the PVC is created and 195 becomes ACTIVE. The Circuit Status AVP indicates that this PVC is 196 ACTIVE and New (0x03). The Remote End ID AVP [RFC3931] MUST be 197 present in the ICRQ in order to identify the PVC (together with the 198 identity of the LCCE itself as defined in Section 2) to associate the 199 L2TP session with. The Remote End ID AVP defined in [RFC3931] is of 200 opaque form and variable length, though one MUST at a minimum support 201 use of an unstructured four-octet value that is known to both LCCEs 202 (either by direct configuration, or some other means). The exact 203 method of how this value is configured, retrieved, discovered, or 204 otherwise determined at each LCCE is outside the scope of this 205 document. 207 As with the ICRQ, the ICRP is sent only after the FR PVC transitions 208 to ACTIVE as well. If LCCE B had not been provisioned for the PVC 209 identified in the ICRQ, a CDN would have been immediately returned 210 indicating that the circuit was not provisioned or available at this 211 LCCE. LCCE A SHOULD then exhibit a periodic retry mechanism. If so, 212 the period and maximum number of retries MUST be configurable. 214 An Implementation MAY send an ICRQ or ICRP before a PVC is ACTIVE, as 215 long as the Circuit Status AVP reflects that the PVC is INACTIVE and 216 an SLI is sent when the PVC becomes ACTIVE (see Section 3.3). 218 The ICCN is the final stage in the session establishment, confirming 219 the receipt of the ICRP with acceptable parameters to allow 220 bidirectional traffic. 222 3.2 L2TPv3 Session Teardown 224 In the event a PVC is deleted (unprovisioned) at either LCCE, the 225 associated L2TP session MUST be torn down via the CDN message defined 226 in Section 3.4.3 of [RFC3931]. 228 General Result Codes regarding L2TP session establishment are defined 229 in [RFC3931]. Additional Frame-Relay result codes are defined as 230 follows: 232 17: FR PVC was deleted permanently (no longer provisioned) 233 18: FR PVC has been INACTIVE for an extended period of time 234 19: Mismatched FR Header Length 236 3.3 L2TPv3 Session Maintenance 238 FRPW over L2TP makes use of the Set Link Info (SLI) control message 239 defined in [RFC3931] to signal Frame-Relay link status notifications 240 between LCCEs. This includes ACTIVE or INACTIVE notifications of the 241 VC, or any other parameters that may need to be shared between the 242 tunnel endpoints or LCCEs in order to provide proper PW emulation. 243 The SLI message is a single message that is sent over the L2TP 244 control channel signaling the state change. Since the message is 245 delivered reliably, there is no additional response or action 246 required of the PW subsytem to ensure that the state change 247 notification was received by the tunnel peer. 249 The SLI message MUST be sent any time there is a circuit status 250 change which may be reported by any values identified in the Circuit 251 Status AVP. The only exception to this are the initial ICRQ, ICRP and 252 CDN messages which establish and teardown the L2TP session itself 253 when the PVC is created or deleted. The SLI message may be sent from 254 either LCCE at any time after the first ICRQ is sent (and perhaps 255 before an ICRP is received, requiring the peer to perform a reverse 256 Session ID lookup). 258 An LCCE participating in the procedures for PVC status management 259 defined in [Q933] Annex A, MUST transmit an SLI message including the 260 Circuit Status AVP (see Section 3.4) when it detects a change in the 261 status for a particular local FR PVC (i.e., when it detects a 262 service-affecting condition or the clearing of such condition). An 263 LCCE receiving an SLI message indicating a change in the status of a 264 particular FRPW SHOULD generate corresponding updates for the FR PVC 265 towards the Remote System as defined in [Q933] Annex A. 267 All sessions established by a given control connection utilize the 268 L2TP Hello facility defined in Section 4.4 of [RFC3931] for session 269 keepalive. This gives all sessions basic dead peer and path detection 270 between LCCEs. 272 3.4 Use of the Circuit Status AVP for Frame-Relay 274 Frame-relay circuit status is reported via the Circuit Status AVP 275 defined in [RFC3931], Attribute Type 71. For reference, this AVP is 276 shown below: 278 0 1 279 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Reserved |N|A| 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 The Value is a 16 bit mask with the two least significant bits 285 defined and the remaining bits reserved for future use. Reserved bits 286 MUST be set to 0 when sending, and ignored upon receipt. 288 The N (New) bit indicates whether the Circuit Status indication is 289 for a new FR PVC (1) or an existing FR PVC (0). 291 The A (Active) bit indicates whether the FR PVC is ACTIVE (1) or 292 INACTIVE (0). 294 3.5 Frame-Relay Header Length AVP 296 The "Frame-Relay Header Length AVP", Attribute type 85, indicates the 297 number of bytes in the Frame Relay header. The two peer LCCEs MUST 298 agree on the length of the Frame Relay header. 300 This AVP is exchanged during session negotiation (in ICRQ, ICRP). If 301 the other LCCE supports a different Frame Relay header length, the 302 associated L2TP session MUST be torn down via CDN message with result 303 code 19 (see Section 3.2). 305 If the Frame-Relay Header Length AVP is not signaled, it MUST be 306 assumed that the peer uses a 2-byte Frame Relay header. 308 The Attribute Value field for this AVP has the following format: 310 Frame-Relay Header Length (ICRQ, ICRP) 312 0 1 313 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Frame Relay Header Length | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 The Frame Relay Header Length Type is a 2-octet unsigned integer with 319 the following values defined in this document: 321 2 - Two-octet Frame Relay Header 322 4 - Four-octet Frame Relay Header 324 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 325 AVP MAY be set to 0, but MAY vary (see Section 5.2 of [RFC3931]). 326 The length (before hiding) of this AVP is 8. 328 4. Encapsulation 330 4.1 Data Packet Encapsulation 332 The FR PDU is transported in its entirety, excluding the opening and 333 closing HDLC flags and the FCS. Bit stuffing is undone. The L2TPv3 334 Session Header is that as defined in [RFC3931]. If sequencing or 335 other features require presence of an L2-Specific Sublayer, the 336 Default format defined in Section 4.6 of [RFC3931] MUST be used. 338 The FR header is defined in [Q922], however the notation used differs 339 from that used in IETF specifications. For reference the FR header 340 (referred to as Address Field in [Q922]) in IETF notation is: 342 0 1 343 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | hi dlci |C|0|lo dlci|F|B|D|1| 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Two-octet FR Header 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | hi dlci |C|0| dlci |F|B|D|0| dlci |0| dlci_lo |0|1| 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 Four-octet FR Header 358 C/R (bit 6) 359 FR frame C/R (command/response) bit [Q922]. 361 F - FECN (bit 12): 362 FR FECN (Forward Explicit Congestion Notification) bit [Q922]. 364 B - BECN (bit 13): 366 FR BECN (Backward Explicit Congestion Notification) bit [Q922]. 368 D - DE (bit 14) 369 FR DE bit indicates the discard eligibility [Q922]. 371 Usage of the C/R, FECN, BECN and DE bits is as specified in [Q922]. 373 The C/R bit is conveyed transparently. Its value MUST NOT be changed 374 by the LCCE. 376 The FECN bit MAY be set by the LCCE to notify the receiving end-user 377 that the frames it recieves have encountered congestion. The end-user 378 may use this indication for destination controlled transmit rate 379 adjustment. The bit must never be cleared by the LCCE. If the LCCE 380 does not support FECN it shall pass the bit unchanged. 382 The BECN bit MAY be set by the LCCE to notify the receiving end-user 383 that frames it transmits may encounter congestion. The end-user may 384 use this indication to adjust its transmit rate. The bit must never 385 be cleared by the LCCE. If the LCCE does not support BECN it shall 386 pass the bit unchanged. 388 The DE bit MAY be set by a policing function on the LCCE to indicate 389 that this frame SHOULD be discarded in preference to other frames in 390 a congestion situation. The bit must never be cleared by the LCCE. If 391 the LCCE does not support DE it shall pass the bit unchanged. 393 The encapsulation of Frame Relay frames with Two-octet FR Header is 394 REQUIRED. The encapsulation of Frame Relay frames with Four-octet FR 395 Header is OPTIONAL. The encapsulation of Frame Relay frames with 396 Three-octet FR Header is ouside the scope of this document. 398 4.2 Data Packet Sequencing 400 Data Packet Sequencing MAY be enabled for FRPWs. The sequencing 401 mechanisms described in [RFC3931] MUST be used for signaling 402 sequencing support. FRPW over L2TP MUST request the presence of the 403 L2TPv3 Default L2-Specific Sublayer when sequencing is enabled, and 404 MAY request its presence at all times. 406 If the FRPW is known to be carrying data which does not require 407 packet order to be strictly maintained (such as IP), then packet 408 sequencing for the FRPW SHOULD NOT be enabled. 410 4.3 MTU Considerations 412 With L2TPv3 as the tunneling protocol, the packet resulted from the 413 encapsulation is N bytes longer than Frame-Relay frame without the 414 opening and closing HDLC flags or FCS. The value of N depends on the 415 following fields: 417 L2TP Session Header: 418 Flags, Ver, Res - 4 octets (L2TPv3 over UDP only) 419 Session ID - 4 octets 420 Cookie Size - 0, 4 or 8 octets 421 L2-Specific Sublayer - 0 or 4 octets (i.e., using sequencing) 423 Hence the range for N in octets is: 425 N = 4-16, L2TPv3 data messages are over IP; 426 N = 16-28, L2TPv3 data messages are over UDP; 427 (N does not include the IP header). 429 The MTU and fragmentation implications resulting from this are 430 discussed in Section 4.1.4 of [RFC3931]. 432 5. Applicability Statement 434 The Frame Relay PW emulation described in this document allows a 435 service provider to offer a Frame Relay PVC based service across an 436 IP packet switched network (PSN). A Frame Relay port based service 437 can be offered using [HDLC]. 439 The FRPW emulation has the following characteristics in relationship 440 to the native service: 442 o There is a one-to-one mapping between a Frame Relay PVC and an 443 FRPW, supporting bi-directional transport of variable length 444 frames. The Frame Relay frame is transported in its entirety, 445 including the DLCI and the C/R, FECN, BECN, and DE bits, but 446 excluding the opening and closing flags and the FCS. The egress 447 LCCE re-writes the DLCI and regenerates the FCS. 449 o Two and Four octet address fields are supported. The length is 450 negotiated between LCCEs during session establishment (see 451 Section 3.5). 453 o The availability or unavailability of the PVC is signalled 454 between LCCEs using the Circuit Status AVP (see Section 3.4). 455 Loss of connectivity between LCCEs can be detected by the L2TPv3 456 keepalive mechanism (see Section 4.4 in [RFC3931]). These 457 indications can be used to determine the PVC status to be 458 signalled through [Q933] procedures at the Frame Relay 459 interface. 461 o The maximum frame size that can be supported is limited by the 462 PSN MTU, unless fragmentation and reassembly is used (see 463 Section 4.1.4 of [RFC3931]). 465 o Sequencing may be enabled on the FRPW to ensure frames are 466 delivered in order (see Section 4.2) 468 o Quality of Service characteristics such as throughput (CIR), 469 committed burst size (bc), excess burst size (be) and priority 470 can be provided by leveraging Quality of Service features of the 471 LCCEs and the underlying PSN. 473 6. Security Considerations 475 Frame Relay over L2TPv3 is subject to the security considerations 476 defined in [RFC3931]. There are no additional considerations specific 477 to carrying Frame Relay that are not present carrying other data link 478 types. 480 7. IANA Considerations 482 7.1 Pseudowire Type 484 The following value for the Frame Relay DLCI PW Type (see Pseudowire 485 Capabilities List as defined in 5.4.3 of [RFC3931] and L2TPv3 486 Pseudowire Types in 10.6 of [RFC3931]) is allocated by the IANA 487 (number space already created as part of publication of [RFC3931]): 489 L2TPv3 Pseudowire Types 490 ----------------------- 492 0x0001 - Frame Relay DLCI Pseudowire Type 494 7.2 Result Code AVP Values 496 This number space is managed by IANA as described in section 2.3 of 497 [BCP0068]. Three new L2TP Result Codes for the CDN message appear in 498 section 3.2. The following is a summary: 500 Result Code AVP (Attribute Type 1) Values 501 ----------------------------------------- 503 17 - PVC was deleted permanently (no longer provisioned) 504 18 - PVC has been INACTIVE for an extended period of time 505 19 - Mismatched FR Header Length 507 7.3 Control Message Attribute Value Pairs (AVPs) 509 This number space is managed by IANA as described in section 2.2 of 510 [BCP0068]. An additional AVP Attribute, specified in section 3.5, 511 was allocated for this specification: 513 Control Message Attribute Value Pairs 514 ------------------------------------- 516 85 - Frame-Relay Header Length 518 8. Acknowledgments 520 The first Frame Relay over L2TP document was published as 521 draft-vasavada-l2tpext-fr-svctype-00.txt, "Frame Relay Service Type 522 for L2TP", in Feburary of 2001 by Nishit Vasavada, Jim Boyle, Chris 523 Garner, Serge Maskalik, and Vijay Gill. This document is 524 substantially different, but the basic concept of carrying Frame 525 Relay over L2TP is the same. 527 Thanks to Lloyd Wood for a razor-sharp review. 529 Carlos Pignataro helped with review and editing of the document. 531 During IETF Last Call, Mark Lewis provided thorough review and 532 comments. 534 9. References 536 9.1 Normative References 538 [RFC3931] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling 539 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 541 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 542 Requirement Levels", BCP 14, RFC 2119, March 1997. 544 [HDLC] C. Pignataro, M. Townsley, "HDLC Frames over L2TPv3", 545 work in progress, draft-ietf-l2tpext-pwe3-hdlc-06.txt, 546 June 2005. 548 9.2 Informative References 550 [BCP0068] Townsley, W., "Layer Two Tunneling Protocol (L2TP) 551 Internet Assigned Numbers Authority (IANA) 552 Considerations Update", RFC3438, BCP0068, December 2002 554 [Q922] ITU-T Recommendation Q.922, "ISDN Data Link Layer 555 Specification for Frame Mode Bearer Services", ITU, 556 Geneva, 1992. 558 [Q933] ITU-T Recommendation Q.933, "Signalling specifications 559 for frame mode switched and permanent virtual connection 560 control and status monitoring", ITU, Geneva, 2003. 562 10. Authors' Addresses 564 W. Mark Townsley 565 Cisco Systems 566 7025 Kit Creek Road 567 PO Box 14987 568 Research Triangle Park, NC 27709 569 mark@townsley.net 571 George Wilkie 572 Cisco Systems 573 96 Commercial Street 574 Edinburgh, EH6 6LX 575 United Kingdom 576 gwilkie@cisco.com 578 Jed Lau 579 jedlau@gmail.com 581 Skip Booth 582 Cisco Systems 583 7025 Kit Creek Road 584 PO Box 14987 585 Research Triangle Park, NC 27709 586 ebooth@cisco.com 588 Stewart Bryant 589 Cisco Systems 590 250 Longwater Ave 591 Green Park 592 Reading RG2 6GB 593 United Kingdom 594 stbryant@cisco.com 596 Intellectual Property Statement 598 The IETF takes no position regarding the validity or scope of any 599 Intellectual Property Rights or other rights that might be claimed to 600 pertain to the implementation or use of the technology described in 601 this document or the extent to which any license under such rights 602 might or might not be available; nor does it represent that it has 603 made any independent effort to identify any such rights. Information 604 on the procedures with respect to rights in RFC documents can be 605 found in BCP 78 and BCP 79. 607 Copies of IPR disclosures made to the IETF Secretariat and any 608 assurances of licenses to be made available, or the result of an 609 attempt made to obtain a general license or permission for the use of 610 such proprietary rights by implementers or users of this 611 specification can be obtained from the IETF on-line IPR repository at 612 http://www.ietf.org/ipr. 614 The IETF invites any interested party to bring to its attention any 615 copyrights, patents or patent applications, or other proprietary 616 rights that may cover technology that may be required to implement 617 this standard. Please address the information to the IETF at 618 ietf-ipr@ietf.org. 620 Disclaimer of Validity 622 This document and the information contained herein are provided on 623 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 624 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 625 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 626 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 627 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 628 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 630 Copyright Statement 632 Copyright (C) The Internet Society (2005). 634 This document is subject to the rights, licenses and restrictions 635 contained in BCP 78, and except as set forth therein, the authors 636 retain all their rights. 638 Acknowledgment 640 Funding for the RFC Editor function is currently provided by the 641 Internet Society.