idnits 2.17.1 draft-ietf-l2tpext-circuit-status-extensions-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 draft header indicates that this document updates RFC3931, but the abstract doesn't seem to directly say this. It does mention RFC3931 though, so this could be OK. -- The draft header indicates that this document updates RFC4591, but the abstract doesn't seem to directly say this. It does mention RFC4591 though, so this could be OK. -- The draft header indicates that this document updates RFC4349, but the abstract doesn't seem to directly say this. It does mention RFC4349 though, so this could be OK. -- The draft header indicates that this document updates RFC4454, but the abstract doesn't seem to directly say this. It does mention RFC4454 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3931, updated by this document, for RFC5378 checks: 2001-07-18) -- 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 (July 12, 2009) is 5394 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: 'PSN' is mentioned on line 260, but not defined == Outdated reference: A later version (-09) exists of draft-ietf-pwe3-redundancy-bit-01 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-vccv-bfd-05 -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. McGill 3 Internet-Draft C. Pignataro 4 Updates: 3931, 4349, 4454, 4591, Cisco Systems 5 4719 (if approved) July 12, 2009 6 Intended status: Standards Track 7 Expires: January 13, 2010 9 L2TPv3 Extended Circuit Status Values 10 draft-ietf-l2tpext-circuit-status-extensions-05 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 13, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document defines additional Layer 2 Tunneling Protocol Version 3 49 (L2TPv3) bit values to be used within the "Circuit Status" Attribute 50 Value Pair (AVP) to communicate finer-grained error states for 51 Attachment Circuits (ACs) and Pseudowires (PWs). It also generalizes 52 the Active bit and deprecates the use of the New bit in the "Circuit 53 Status" AVP, updating RFC3931, RFC4349, RFC4454, RFC4591, and 54 RFC4719. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Specification of Requirements . . . . . . . . . . . . . . 3 60 2. L2TPv3 Extended Circuit Status Values . . . . . . . . . . . . 3 61 3. Circuit Status Usage and Clarifications . . . . . . . . . . . 8 62 4. Updates to Existing RFCs . . . . . . . . . . . . . . . . . . . 9 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 71 1. Introduction 73 Currently the L2TPv3 Circuit Status AVP [RFC3931] is able to convey 74 the UP/DOWN status of an access circuit. However, a finer 75 granularity is often useful to determine the direction of the fault 76 as has been added for MPLS-based pseudowires and used in the 77 pseudowire control protocol using the Label Distribution Protocol 78 (LDP), see Section 3.5 of [RFC4446] and Section 5.4.2 of [RFC4447]. 80 Additionally, it is useful (in session-level redundancy scenarios) to 81 be able to indicate if a pseudowire is in a standby state, where it 82 is fully established by signaling and allows OAM, but is not 83 switching data. Again, such functionality is available for MPLS- 84 based pseudowires using LDP, see [I-D.ietf-pwe3-redundancy-bit]. 86 This document provides extended circuit status bit values for L2TPv3 87 and adds them in a manner such that it is backwards compatible with 88 the current Circuit Status AVP. These new bits are applicable to all 89 pseudowires types that use the Circuit Status AVP. 91 1.1. Specification of Requirements 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 2. L2TPv3 Extended Circuit Status Values 99 The Circuit Status AVP (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, SLI), 100 Attribute Type 71, indicates the initial status of or a status change 101 in the circuit to which the session is bound. 103 The Attribute Value field for this AVP currently defined in [RFC3931] 104 has the following format: 106 0 1 107 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Reserved |N|A| 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 Bit Bit-Value Name 113 ---------------------------------------------------------------- 114 (A) 15 0x0001 Active 115 (N) 14 0x0002 New 117 As currently defined in [RFC3931] and replicated in [RFC4349], 119 [RFC4454], [RFC4591], and [RFC4719], the two bits have the following 120 meanings: 122 o The A (Active) bit indicates whether the circuit is up/active/ 123 ready (1) or down/inactive/not-ready (0). 125 o The N (New) bit indicates whether the circuit status indication is 126 for a new circuit (1) or an existing circuit (0). 128 This document updates the semantics of the A and N bits as follows 129 (see also Section 4): 131 The A (Active) bit indicates whether the local pseudowire endpoint 132 (both local Attachment Circuit (AC) and local Packet Switched Network 133 (PSN) facing pseudowire) has no faults present and is up/active/ready 134 (1) or has faults present and is down/inactive/not-ready (0). 136 The N (New) bit indicates if the notification is for a new circuit 137 (1) or an existing circuit (0), and is provided to emulate (Frame 138 Relay) NNI signaling between Provider Edge (PE) routers. It MAY be 139 used to convey that a circuit has been re-provisioned or newly 140 provisioned at the PE, which can already be inferred from the L2TP 141 control message type. It is therefore uncertain as to what use the 142 receiving PE can make of this bit, although it MAY include logging. 143 This document deprecates this bit as it is of little or no use, hence 144 this bit SHOULD be ignored on receipt and is OPTIONAL to set on 145 sending. For reference, see Section 3.4 of [RFC4591] which does not 146 specify any additional usage beyond the setting of the N bit in the 147 ICRQ, ICRP (and OCRQ, OCRP) and clearing in all other control 148 messages. 150 This document also extends this bitmap of values to allow for finer 151 granularity of local pseudowire (i.e., access circuit or PSN-facing 152 endpoint) status reporting. 154 The Attribute Value field for the Circuit Status AVP including the 155 new values has the following format: 157 0 1 158 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Reserved |S|E|I|T|R|N|A| 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 Bit Bit-Value Name 164 ----------------------------------------------------------------- 165 (A) 15 0x0001 Active: Pseudowire has no faults 166 (N) 14 0x0002 New [use deprecated] 167 (R) 13 0x0004 Local Attachment Circuit (ingress) Receive Fault 168 (T) 12 0x0008 Local Attachment Circuit (egress) Transmit Fault 169 (I) 11 0x0010 Local PSN-facing PW (ingress) Receive Fault 170 (E) 10 0x0020 Local PSN-facing PW (egress) Transmit Fault 171 (S) 9 0x0040 Pseudowire is in Standby mode 173 The new bits values have the following meanings: 175 (R), Local Attachment Circuit (ingress) Receive Fault 177 Fault Here 178 | 179 | 180 | +----------------------+ +----------------------+ 181 | Rx| LCCE |Egress | Peer LCCE | 182 --X-->| |-------->| | 183 | L2TPv3 | [PSN] | L2TPv3 | 184 Tx| Circuit Pseudowire |Ingress | Pseudowire Circuit | 185 <-----| |<--------| | 186 +----------------------+ +----------------------+ 188 An alarm or fault has occurred at the local attachment circuit 189 such that it is unable to receive traffic. It can still transmit 190 traffic. 192 (T), Local Attachment Circuit (egress) Transmit Fault 194 +----------------------+ +----------------------+ 195 Rx| LCCE |Egress | Peer LCCE | 196 ----->| |-------->| | 197 | L2TPv3 | [PSN] | L2TPv3 | 198 Tx| Circuit Pseudowire |Ingress | Pseudowire Circuit | 199 <--X--| |<--------| | 200 | +----------------------+ +----------------------+ 201 | 202 | 203 Fault Here 205 A fault has occurred at the local attachment circuit such that it 206 is unable to transmit traffic. It can still receive traffic. 208 (I), Local PSN-facing PW (ingress) Receive Fault 210 +----------------------+ +----------------------+ 211 Rx| LCCE |Egress | Peer LCCE | 212 ----->| |-------->| | 213 | L2TPv3 | [PSN] | L2TPv3 | 214 Tx| Circuit Pseudowire |Ingress | Pseudowire Circuit | 215 <-----| |<---X----| | 216 +----------------------+ | +----------------------+ 217 | 218 | 219 Fault Here 221 A fault has occurred in the receive direction between the local 222 endpoint and the remote L2TP endpoint. 224 Note that a fault at the session level would not necessarily 225 trigger an L2TP control connection timeout. The means of 226 detecting this fault are outside the scope of this document; as an 227 example, detection may be via PW Type-specific means, 228 Bidirectional Forwarding Detection (BFD), or other methods. 230 (E), Local PSN-facing PW (egress) Transmit Fault 232 Fault Here 233 | 234 | 235 +----------------------+ | +----------------------+ 236 Rx| LCCE |Egress| | Peer LCCE | 237 ----->| |------X->| | 238 | L2TPv3 | [PSN] | L2TPv3 | 239 Tx| Circuit Pseudowire |Ingress | Pseudowire Circuit | 240 <-----| |<--------| | 241 +----------------------+ +----------------------+ 243 A fault has occurred in the transmit direction between the local 244 endpoint and the remote L2TP endpoint. 246 Note that a fault at the session level would not necessarily 247 trigger an L2TP control connection timeout. The means of 248 detecting this fault are outside the scope of this document; as an 249 example, detection may be via PW Type-specific means, BFD, or 250 other methods. 252 (S), Pseudowire is in Standby mode 254 Standby 255 | 256 | 257 +----------------------+ | +----------------------+ 258 Rx| LCCE |Egress | Peer LCCE | 259 ----->| |---X---->| | 260 | L2TPv3 | [PSN] | L2TPv3 | 261 Tx| Circuit Pseudowire |Ingress | Pseudowire Circuit | 262 <-----| |<--X-----| | 263 +----------------------+ | +----------------------+ 264 | 265 | 266 Standby 268 The pseudowire has been placed into a standby mode which means 269 that although it was signaled (setup of the PW) and is 270 operational, it is NOT switching user traffic. Any received user 271 traffic SHOULD be dropped. User traffic MUST NOT be transmitted. 273 A standby pseudowire also allows for means to check its data plane 274 liveness, to ensure its ability to switch data packets end-to-end. 275 This is achieved for example as detailed in [RFC5085] or 276 [I-D.ietf-pwe3-vccv-bfd]. However, data is not forwarded from an 277 Access Circuit (AC) into the L2TPv3 session, or from the L2TPv3 278 session out of the AC. 280 3. Circuit Status Usage and Clarifications 282 In implementations prior to this specification, bits 0-13 MUST be set 283 to zero (see Section 5.4.5 of [RFC3931]). This allows for legacy 284 implementations to interwork properly with new implementations. 286 The following are clarifications regarding the usage of the Circuit 287 Status AVP bits as defined in this specification: 289 o The (R), (T), (I) and (E) bits are collectively referred to as 290 "fault status bits". 292 o [RFC3931] defined the (A) bit as pertaining to local access 293 circuit state only. This draft redefines it as meaning that "no 294 faults are present on the local pseudowire endpoint." 296 o If multiple faults occur, all the fault status bits corresponding 297 to each fault MUST be set (i.e., they MUST be bitwise-OR-d 298 together). 300 o The (A) bit MUST NOT be set until all fault status bits are 301 cleared. This behavior allows an endpoint to be backwards 302 compatible with a remote endpoint that does not understand these 303 new status bits. 305 o If any of the fault status bits are set, then the (A) bit MUST be 306 cleared. That is, the fault status bits (R, T, I, E) are a more 307 granular definition of (A), such that OR-ing the bits provides an 308 inverted (A). 310 o If (A) is clear and the fault status bits (R, T, I, E) are clear, 311 it means that there is no extended circuit status. That is, the 312 circuit is down/inactive/not-ready (from the (A) bit), without a 313 more granular (extended) indication. 315 o The (S) bit can be set in conjunction with any other bit, 316 including (A). A pseudowire endpoint in Standby (S bit set) can 317 be up/active/ready (A bit set) or experiencing a fault (A bit 318 cleared and (R, T, I, E) bit(s) set). 320 o Leaving standby mode is indicated by the clearing of the (S) bit. 322 o The usage of the (N) bit has been deprecated. 324 4. Updates to Existing RFCs 326 This document updates existing RFCs that define (either generically 327 or in the context of a specific set of PW Types) the Active and New 328 bits of the Circuit Status AVP. The Active and New bits of the 329 Circuit Status AVP are specified in Section 5.4.5 of [RFC3931]. 330 Those definitions are adapted to specific Attachment Circuits and 331 replicated in Section 3.4 of [RFC4349] (HDLC Frames over L2TPv3), 332 Section 8 of [RFC4454] (ATM over L2TPv3), Section 3.4 of [RFC4591] 333 (Frame Relay over L2TPv3), and Section 2.3.3 of [RFC4719] (Ethernet 334 Frames over L2TPv3). This document updates the definitions in all 335 these five references to say: 337 The A (Active) bit indicates whether the local pseudowire endpoint 338 (both local attachment circuit and local PSN-facing pseudowire) 339 has no faults present and is up/active/ready (1) or has faults 340 present and is down/inactive/not-ready (0). 342 The N (New) bit usage is deprecated, it SHOULD be ignored on 343 receipt and is OPTIONAL to set on sending. 345 This document also updates Section 2.2 (bullet c) of [RFC4719], 346 removing the following two sentences: 348 For ICRQ and ICRP, the Circuit Status AVP MUST indicate that the 349 circuit status is for a new circuit (refer to N bit in Section 350 2.3.3). 352 For ICCN and SLI (refer to Section 2.3.2), the Circuit Status AVP 353 MUST indicate that the circuit status is for an existing circuit 354 (refer to N bit in Section 2.3.3) and reflect the current status 355 of the link (refer to A bit in Section 2.3.3). 357 And finally, updates Section 3.1 of [RFC4349], Section 3.1 of 358 [RFC4454], Section 3.1 of [RFC4591], and Section 2.2 of [RFC4719] 359 with the following paragraph addition: 361 The usage of the N bit in the Circuit Status AVP is deprecated. 362 Therefore, for ICRQ and ICRP the Circuit Status AVP need not 363 indicate on sending (nor check on receipt) that the circuit status 364 is for a new circuit, and for ICCN and SLI the Circuit Status AVP 365 need not indicate on sending (nor check on receipt) that the 366 circuit status is for an existing circuit. 368 5. Security Considerations 370 Security considerations for the Circuit Status AVP are covered in the 371 base L2TPv3 specitication (see Section 8 of [RFC3931]). No 372 additional security considerations exist with extending this 373 attribute. 375 6. IANA Considerations 377 The Circuit Status Bits number space reachable at 378 [IANA.l2tp-parameters] is managed by IANA as per Section 10.7 of 379 [RFC3931]. Five new bits (bits 9 through 13) and one updated bit 380 (bit 14) are requested to be assigned as follows: 382 Circuit Status Bits - per [RFC3931] 383 ------------------- 385 Bit 9 - S (Standby) bit 386 Bit 10 - E (Local PSN-facing PW (egress) Tx Fault) bit 387 Bit 11 - I (Local PSN-facing PW (ingress) Rx Fault) bit 388 Bit 12 - T (Local AC (egress) Tx Fault) bit 389 Bit 13 - R (Local AC (ingress) Rx Fault) bit 390 Bit 14 - N (New) bit [use deprecated] 392 7. Acknowledgements 394 The authors wish to thank Muhammad Yousuf, Mark Townsley, George 395 Wilkie, Prashant Jhingran, Pawel Sowinski, and Ignacio Goyret for 396 useful comments received. 398 8. References 400 8.1. Normative References 402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 403 Requirement Levels", BCP 14, RFC 2119, March 1997. 405 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 406 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 408 [RFC4349] Pignataro, C. and M. Townsley, "High-Level Data Link 409 Control (HDLC) Frames over Layer 2 Tunneling Protocol, 410 Version 3 (L2TPv3)", RFC 4349, February 2006. 412 [RFC4454] Singh, S., Townsley, M., and C. Pignataro, "Asynchronous 413 Transfer Mode (ATM) over Layer 2 Tunneling Protocol 414 Version 3 (L2TPv3)", RFC 4454, May 2006. 416 [RFC4591] Townsley, M., Wilkie, G., Booth, S., Bryant, S., and J. 417 Lau, "Frame Relay over Layer 2 Tunneling Protocol Version 418 3 (L2TPv3)", RFC 4591, August 2006. 420 [RFC4719] Aggarwal, R., Townsley, M., and M. Dos Santos, "Transport 421 of Ethernet Frames over Layer 2 Tunneling Protocol Version 422 3 (L2TPv3)", RFC 4719, November 2006. 424 8.2. Informative References 426 [I-D.ietf-pwe3-redundancy-bit] 427 Muley, P., Bocci, M., and L. Martini, "Preferential 428 Forwarding Status bit definition", 429 draft-ietf-pwe3-redundancy-bit-01 (work in progress), 430 September 2008. 432 [I-D.ietf-pwe3-vccv-bfd] 433 Nadeau, T. and C. Pignataro, "Bidirectional Forwarding 434 Detection (BFD) for the Pseudowire Virtual Circuit 435 Connectivity Verification (VCCV)", 436 draft-ietf-pwe3-vccv-bfd-05 (work in progress), June 2009. 438 [IANA.l2tp-parameters] 439 Internet Assigned Numbers Authority, "Layer Two Tunneling 440 Protocol "L2TP"", March 2009, 441 . 443 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 444 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 446 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 447 Heron, "Pseudowire Setup and Maintenance Using the Label 448 Distribution Protocol (LDP)", RFC 4447, April 2006. 450 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 451 Connectivity Verification (VCCV): A Control Channel for 452 Pseudowires", RFC 5085, December 2007. 454 Authors' Addresses 456 Neil McGill 457 Cisco Systems 458 7025-4 Kit Creek Rd 459 PO Box 14987 460 Research Triangle Park, NC 27709 461 USA 463 Email: nmcgill@cisco.com 465 Carlos Pignataro 466 Cisco Systems 467 7200-12 Kit Creek Road 468 PO Box 14987 469 Research Triangle Park, NC 27709 470 USA 472 Email: cpignata@cisco.com