idnits 2.17.1 draft-ietf-mpls-tp-oam-requirements-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 28, 2009) is 5409 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) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 4379 (ref. '3') (Obsoleted by RFC 8029) == Outdated reference: A later version (-12) exists of draft-ietf-mpls-tp-framework-00 == Outdated reference: A later version (-10) exists of draft-ietf-mpls-tp-requirements-09 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-vccv-bfd-05 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group M. Vigoureux, Ed. 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track D. Ward, Ed. 5 Expires: December 30, 2009 Cisco Systems, Inc. 6 M. Betts, Ed. 7 Huawei 8 June 28, 2009 10 Requirements for OAM in MPLS Transport Networks 11 draft-ietf-mpls-tp-oam-requirements-02 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 30, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document lists the requirements for the Operations, 50 Administration and Maintenance functionality of MPLS Transport 51 Profile. These requirements apply to pseudowires, Label Switched 52 Paths, and Sections. Architectural and functional requirements are 53 covered in this document. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language and Terminology . . . . . . . . . . 4 59 2. OAM Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Architectural Requirements . . . . . . . . . . . . . . . . 5 61 2.1.1. Scope of OAM . . . . . . . . . . . . . . . . . . . . . 5 62 2.1.2. Independence . . . . . . . . . . . . . . . . . . . . . 5 63 2.1.3. Addressing, Routing and Forwarding . . . . . . . . . . 6 64 2.1.4. Interoperability and Interworking . . . . . . . . . . 6 65 2.1.5. Data Plane . . . . . . . . . . . . . . . . . . . . . . 7 66 2.2. Functional Requirements . . . . . . . . . . . . . . . . . 7 67 2.2.1. General Requirements . . . . . . . . . . . . . . . . . 8 68 2.2.2. Continuity Checks . . . . . . . . . . . . . . . . . . 8 69 2.2.3. Connectivity Verifications . . . . . . . . . . . . . . 8 70 2.2.4. Diagnostic . . . . . . . . . . . . . . . . . . . . . . 8 71 2.2.5. Route Tracing . . . . . . . . . . . . . . . . . . . . 9 72 2.2.6. Lock Instruct . . . . . . . . . . . . . . . . . . . . 9 73 2.2.7. Lock Reporting . . . . . . . . . . . . . . . . . . . . 9 74 2.2.8. Alarm Reporting . . . . . . . . . . . . . . . . . . . 10 75 2.2.9. Remote Defect Indication . . . . . . . . . . . . . . . 10 76 2.2.10. Client Failure Indication . . . . . . . . . . . . . . 10 77 2.2.11. Packet Loss . . . . . . . . . . . . . . . . . . . . . 10 78 2.2.12. Delay Measurement . . . . . . . . . . . . . . . . . . 11 79 3. Congestion Considerations . . . . . . . . . . . . . . . . . . 11 80 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 85 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 88 1. Introduction 90 In the context of MPLS Transport Profile (MPLS-TP, see [5] and [6]), 91 the rationales for Operations, Administration and Maintenance (OAM) 92 mechanisms are twofold as they can serve: 94 o as a network-oriented mechanism (used by a transport network 95 operator) to monitor his network infrastructure and to implement 96 internal mechanisms in order to enhance the general behaviour and 97 the level of performance of his network (e.g., protection 98 mechanism in case of node or link failure). For example, fault 99 localization is typically associated with this use case. 101 o as a service-oriented mechanism (used by a transport service 102 provider) to monitor services offered to end customers in order to 103 be able to react rapidly in case of a problem and to be able to 104 verify some of the Service Level Agreements (SLAs) parameters 105 (e.g., using performance monitoring) negotiated with the end 106 customers. Note that a transport service could be provided over 107 several networks or administrative domains that may not all be 108 owned and managed by the same transport service provider. 110 More generally, OAM is an important and fundamental functionality in 111 transport networks as it contributes to: 113 o the reduction of operational complexity and costs, by allowing for 114 efficient and automatic detection, localisation, handling, and 115 diagnosis of defects, and by minimizing service interruptions and 116 operational repair times. 118 o the enhancement of network availability, by ensuring that defects, 119 for example resulting in misdirected customer traffic, and faults, 120 are detected, diagnosed and dealt with before a customer reports 121 the problem. 123 o meet service and performance objectives, as the OAM functionality 124 allows for SLA verification in a multi-maintenance domain 125 environment and allows for the determination of service 126 degradation due, for example, to packet delay or packet loss. 128 This document lists the requirements for the OAM functionality of 129 MPLS-TP. These requirements apply to pseudowires (PWs), Label 130 Switched Paths (LSPs), and Sections. 132 These requirements are derived from the set of requirements specified 133 by ITU-T and published in the ITU-T Supplement Y.Sup4 [7]. 135 By covering transport specificities, these requirements complement 136 those identified in RFC 4377 [8]. 138 Note that the OAM functionalities identified in this document may be 139 used for fault management, performance monitoring and/or protection 140 switching applications. For example, connectivity verification can 141 be used for fault management application by detecting failure 142 conditions, but may also be used for performance monitoring 143 application through its contribution to the evaluation of performance 144 metrics (e.g., unavailability time). Nevertheless, it is outside the 145 scope of this document to specify which functionality should be used 146 for which application. 148 1.1. Requirements Language and Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [1]. 154 In this document we refer to the inability of a function to perform a 155 required action, as a fault. This does not include an inability due 156 to preventive maintenance, lack of external resources, or planned 157 actions. See also ITU-T G.806 [2]. 159 In this document we refer to the situation in which the density of 160 anomalies has reached a level where the ability to perform a required 161 function has been interrupted, as a defect. See also ITU-T G.806 162 [2]. 164 In this document we refer to a Label Edge Router (LER), for a given 165 LSP or Section, and to a PW Terminating Provider Edge (T-PE), for a 166 given PW, as an End Point. Further, we refer to a Label Switching 167 Router (LSR), for a given LSP, and to a PW Switching Provider Edge 168 (S-PE), for a given PW, as an Intermediate Point. This document does 169 not make a distinction between End Points (e.g., source and 170 destination) as it can be inferred from the context of the sentences. 172 In this document we use the term "node" as a general reference to End 173 Points and Intermediate Points. 175 In this document we refer to both segment and concatenated segments 176 as segments (see [6] for definitions relating to the term "segment" 177 as well as for other definitions relating to MPLS-TP). 179 2. OAM Requirements 181 This section lists the requirements by which the OAM functionality of 182 MPLS-TP should abide. Note that some requirements for this 183 application of MPLS are similar to some of those listed in RFC 4377 184 [8]. 186 The requirements listed below may be met by one or more OAM 187 protocols; the definition or selection of these protocols is outside 188 the scope of this document. 190 2.1. Architectural Requirements 192 2.1.1. Scope of OAM 194 The protocol solutions developed to meet the requirements identified 195 in this document MUST be applicable to point-to-point bidirectional 196 PWs, point-to-point bidirectional LSPs, and point-to-point 197 bidirectional Sections and SHOULD additionaly be applicable to 198 unidirectional point-to-point and point-to-multipoint LSPs. 200 The service emulated by a single segment or a multi-segment PW may 201 span multiple domains. An LSP may also span multiple domains. It 202 MUST be possible to operate OAM functions on a per domain basis. 203 More generally, the protocol solutions MUST be applicable end-to-end 204 and to segments. 206 Since LSPs may be stacked, the protocol solutions MUST be applicable 207 on any LSP, regardless of the label stack depth. Furthermore it MUST 208 be possible to estimate OAM fault and performance metrics of a single 209 PW or LSP segment or of an aggregate of PWs or LSPs segments. 211 2.1.2. Independence 213 The protocol solutions SHOULD be independent of the underlying 214 tunnelling or point-to-point technology or transmission media. 216 The protocol solutions SHOULD be independent of the service a PW may 217 emulate. 219 Any OAM function operated on a PW, LSP or Section SHOULD be 220 independent of the OAM function(s) operated on a different PW, LSP or 221 Section. In other words, only the OAM functions operated on e.g., a 222 given LSP should be used to achieve the OAM objectives for that LSP. 223 Note that independence should not be understood here in terms of 224 isolation as there can be interactions between OAM functions operated 225 on e.g., an LSP, and on another LSP or a PW. 227 Likewise, any OAM function applied to segment(s) of a PW or LSP 228 SHOULD be independent of the OAM function(s) operated on the end-to- 229 end PW or LSP. It SHOULD also be possible to distinguish an OAM 230 packet running over a segment of a PW or LSP from another OAM packet 231 running on the end-to-end PW or LSP. Furthermore, any OAM function 232 applied to segment(s) of a PW or LSP SHOULD be independent of the OAM 233 function(s) applied to other segment(s) of the same PW or LSP. 234 Finally, the protocol solutions MUST support the capability to be 235 concurrently and independently operated end-to-end and on segments. 237 OAM functions MUST operate and be configurable even in the absence of 238 a control plane. Conversely, it SHOULD be possible to enable/disable 239 the capability to operate OAM functions as part of connectivity 240 management and it SHOULD also be possible to enable/disable the 241 capability to operate OAM functions after connectivity has been 242 established. In the latter case, the customer MUST NOT perceive 243 service degradation as a result of OAM enabling/disabling. Ideally 244 OAM enabling/disabling should take place without introducing any 245 customer impairments (e.g., no customer packet losses). Procedures 246 aimed to prevent any traffic impairment MUST be defined for the 247 enabling/disabling of OAM functions. Means for configuring OAM 248 functions and for connectivity management are outside the scope of 249 this document. 251 2.1.3. Addressing, Routing and Forwarding 253 The OAM functionality may be deployed in a variety of environments. 255 o In some environments (e.g., IP/MPLS environments), IP routing and 256 forwarding capabilities are inherently present in the forwarding 257 plane. In this case, it MUST be possible to operate the OAM 258 functions by relying on IP routing and forwarding capabilities. 260 o In some environments (e.g., MPLS-TP environments), IP routing and 261 forwarding capabilities may not necessarily be present in the user 262 plane. In this case, it MUST be possible to operate the OAM 263 functions without relying on IP routing and forwarding 264 capabilities. 266 In cases where OAM messages need to incorporate identification 267 information (e.g., source and/or destination nodes), the protocol 268 solution(s) MUST at least support an IP addressing structure and MUST 269 also be extensible to support additional identification schemes. 271 2.1.4. Interoperability and Interworking 273 It is REQUIRED that OAM interoperability is achieved across the 274 environments described in Section 2.1.3. It is also REQUIRED that 275 the two first requirements of Section 2.1.3 still hold and MUST still 276 be met when interoperability is achieved. 278 When MPLS-TP is run with IP routing and forwarding capabilities, it 279 MUST be possible to operate any of the existing IP/MPLS and PW OAM 280 protocols (e.g., LSP-Ping [3], MPLS-BFD [9], VCCV [4] and VCCV-BFD 281 [10]). 283 2.1.5. Data Plane 285 OAM functions operate in the data plane. OAM packets MUST run in- 286 band; that is, OAM packets for a specific PW, LSP or Section MUST 287 follow the exact same data path as user traffic of that PW, LSP or 288 Section. This is often referred to as fate sharing. 290 It MUST be possible to discriminate user traffic from OAM packets. 291 This includes a means to differentiate OAM packets from user traffic 292 as well as the capability to apply specific treatment to OAM packets, 293 at the nodes targeted by these OAM packets. 295 As part of the design of OAM protocol solution(s) for MPLS-TP, a 296 mechanism, for enabling the encapsulation and differentiation of OAM 297 messages on a PW, LSP or Section, MUST be provided. Such mechanism 298 SHOULD also support the encapsulation and differentiation of existing 299 IP/MPLS and PW OAM messages. 301 2.2. Functional Requirements 303 Hereafter are listed the required functionalities composing the 304 MPLS-TP OAM toolset. The list may not be exhaustive and as such the 305 OAM mechanisms developed in support of the identified requirements 306 SHALL be extensible and thus SHALL NOT preclude the definition of 307 additional OAM functionalities, in the future. 309 The design of OAM mechanisms for MPLS-TP, MUST allow for the ability 310 to support experimental OAM functions. These functions MUST be 311 disabled by default. 313 The use of any OAM function MUST be optional and it MUST be possible 314 to choose which OAM function(s) to use and on which PW, LSP or 315 Section to apply it(them) to. 317 It is RECOMMENDED that the protocol solution, meeting one or more 318 functional requirement(s), be the same for PWs, LSPs and Sections. 320 It is RECOMMENDED that the protocol solution, meeting one or more 321 functional requirement(s), effectively provides a fully featured 322 function; that is, a function which is applicable to all the cases 323 identified for that functionality. In that context, protocol 324 solution(s) MUST state their applicability. 326 Unless otherwise stated, the OAM functionalities MUST NOT rely on 327 user traffic; that is, only OAM messages MUST be used to achieve the 328 objectives. 330 2.2.1. General Requirements 332 If a defect or fault occurs on a PW, LSP or Section, mechanisms MUST 333 be provided to detect it, diagnose it, localize it, and notify the 334 appropriate nodes. Mechanisms SHOULD exist such that corrective 335 actions can be taken. 337 Furthermore, mechanisms MUST be available for a service provider to 338 be informed of a fault or defect affecting the service(s) it 339 provides, even if the fault or defect is located outside of his 340 domain. 342 The protocol solution(s) developed to meet these requirements may 343 rely on information exchange. Information exchange between various 344 nodes involved in the operation of an OAM function SHOULD be reliable 345 such that, for example, defects or faults are properly detected or 346 that state changes are effectively known by the appropriate nodes. 348 2.2.2. Continuity Checks 350 The MPLS-TP OAM toolset MUST provide functionality to enable the 351 verification of the continuity of a PW, LSP or Section. 353 This function SHOULD be performed between End Points of PWs, LSPs and 354 Sections. 356 This function SHOULD be performed pro-actively. 358 2.2.3. Connectivity Verifications 360 The MPLS-TP OAM toolset MUST provide functionality to enable the 361 verification of the connectivity of a PW, LSP or Section. 363 This function SHOULD be performed between End Points and Intermediate 364 Points of PWs and LSPs, and between End Points of PWs, LSPs and 365 Sections. 367 This function SHOULD be performed on-demand. This function SHOULD be 368 performed pro-actively only between End Points of PWs, LSPs and 369 Sections. 371 2.2.4. Diagnostic 373 The MPLS-TP OAM toolset MAY provide functionality to enable the 374 conduction of diagnostic tests on a PW, LSP or Section. An example 375 of such diagnotic test would consist in looping the traffic at an 376 Intermediate Point, back to the End Point it originates from. 377 Another example of such diagnotic test would consist in estimating 378 the bandwidth of e.g., an LSP. 380 This function SHOULD be performed on-demand. 382 This function SHOULD be performed between End Points and Intermediate 383 Points of PWs and LSPs, and between End Points of PWs, LSPs and 384 Sections. 386 2.2.5. Route Tracing 388 The MPLS-TP OAM toolset MUST provide functionality to enable an End 389 Point to discover the Intermediate (if any) and End Point(s) along a 390 PW, LSP or Section, and more generaly to trace the route of a PW, LSP 391 or Section. The information collected MUST include identifiers 392 related to the nodes and interfaces composing that route. 394 This function SHOULD be performed on-demand. 396 This function SHOULD be performed between End Points and Intermediate 397 Points of PWs and LSPs, and between End Points of PWs, LSPs and 398 Sections. 400 2.2.6. Lock Instruct 402 The MPLS-TP OAM toolset MUST provide functionality to enable an End 403 Point of a PW, LSP or Section to instruct its associated End Point(s) 404 to lock the PW, LSP or Section. Note that lock corresponds to an 405 administrative status in which forwarding traffic on and from the PW, 406 LSP or Section is disabled. 408 This function SHOULD be performed on-demand. 410 This function SHOULD be performed between End Points of PWs, LSPs and 411 Sections. 413 2.2.7. Lock Reporting 415 The MPLS-TP OAM toolset MUST provide functionality to enable an 416 Intermediate Point of a PW or LSP to report, to an End Point of that 417 same PW or LSP, an external lock condition affecting that PW or LSP. 419 This function SHOULD be performed pro-actively. 421 This function SHOULD be performed between Intermediate Points and End 422 Points of PWs and LSPs. 424 2.2.8. Alarm Reporting 426 The MPLS-TP OAM toolset MUST provide functionality to enable an 427 Intermediate Point of a PW or LSP to report, to an End Point of that 428 same PW or LSP, a fault or defect condition affecting that PW or LSP. 430 This function SHOULD be performed pro-actively. 432 This function SHOULD be performed between Intermediate Points and End 433 Points of PWs and LSPs. 435 2.2.9. Remote Defect Indication 437 The MPLS-TP OAM toolset MUST provide functionality to enable an End 438 Point to report, to its associated End Point, a fault or defect 439 condition that it detects on a PW, LSP or Section for which they are 440 the End Points. 442 This function SHOULD be performed pro-actively. 444 This function SHOULD be performed between End Points of PWs, LSPs and 445 Sections. 447 2.2.10. Client Failure Indication 449 The MPLS-TP OAM toolset MUST provide functionality to enable the 450 propagation, across an MPLS-TP network, of information pertaining to 451 a client defect of fault condition detected at an End Point of a PW 452 or LSP, if the client layer OAM mechanisms do not provide an alarm 453 notification/propagation mechanism. 455 This function SHOULD be performed pro-actively. 457 This function SHOULD be performed between End Points of PWs and LSPs. 459 2.2.11. Packet Loss 461 The MPLS-TP OAM toolset MUST provide functionality to enable the 462 quantification of packet loss ratio over a PW, LSP or Section. 464 Note that packet loss ratio is the ratio of the user packets not 465 delivered to the total number of user packets transmitted during a 466 defined time interval. The number of user packets not delivered is 467 the difference between the number of user packets transmitted by an 468 End Point and the number of user packets received at an End Point. 470 This function MAY either be performed pro-actively or on-demand. 472 This function SHOULD be performed between End Points of PWs, LSPs and 473 Sections. 475 It SHOULD be possible to rely on user-plane traffic to achieve that 476 functionality. 478 2.2.12. Delay Measurement 480 The MPLS-TP OAM toolset MUST provide functionality to enable the 481 quantification of the one-way, and if appropriate, the two-way, delay 482 of a PW, LSP or Section. 484 o One-way delay is the time elapsed from the start of transmission 485 of the first bit of a packet by an End Point until the reception 486 of the last bit of that packet by the other End Point. 488 o Two-way delay is the time elapsed from the start of transmission 489 of the first bit of a packet by a End Point until the reception of 490 the last bit of that packet by the same End Point, when loopback 491 is performed at the other End Point. 493 This function SHOULD be performed on-demand and MAY be perform pro- 494 actively. 496 This function SHOULD be performed between End Points of PWs, LSPs and 497 Sections. 499 It SHOULD be possible to rely on user-plane traffic to achieve that 500 functionality. 502 3. Congestion Considerations 504 A mechanism (e.g., rate limiting) MUST be provided to prevent OAM 505 packets from causing congestion in the PSN. 507 4. Security Considerations 509 This document, as itself, does not imply any security consideration 510 but OAM, as such, is subject to several security considerations. OAM 511 messages can reveal sensitive information such as passwords, 512 performance data and details about e.g., the network topology. 514 The nature of OAM therefore suggests having some form of 515 authentication, authorization and encryption in place. This will 516 prevent unauthorized access to MPLS-TP equipment and it will prevent 517 third parties from learning about sensitive information about the 518 transport network. 520 In general, mechanisms SHOULD be provided to ensure that OAM 521 functions cannot be accessed unauthorized. 523 Further, OAM messages MAY be authenticated to prove their origin and 524 to make sure that they are destined for the receiving node. 526 An OAM packet received over a PW, LSP or Section MUST NOT be 527 forwarded beyond the End Point of that PW, LSP or Section, so as to 528 avoid that the OAM packet leaves the current administrative domain. 530 5. IANA Considerations 532 There are no IANA actions required by this draft. 534 6. Acknowledgements 536 The editors gratefully acknowledge the contributions of Matthew 537 Bocci, Italo Busi, Thomas Dietz, Huub van Helvoort, Wataru Imajuku, 538 Marc Lasserre, Lieven Levrau, Han Li, Julien Meuric, Philippe Niger, 539 Benjamin Niven-Jenkins, Jing Ruiquan, Nurit Sprecher, Yuji Tochio, 540 Satoshi Ueno and Yaacov Weingarten. 542 The authors would like to thank all members of the teams (the Joint 543 Working Team, the MPLS Interoperability Design Team in IETF and the 544 MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and 545 specification of MPLS-TP. 547 7. References 549 7.1. Normative References 551 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 552 Levels", BCP 14, RFC 2119, March 1997. 554 [2] ITU-T Recommendation G.806, "Characteristics of transport 555 equipment - Description methodology and generic functionality", 556 2009. 558 [3] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label 559 Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. 561 [4] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 562 Connectivity Verification (VCCV): A Control Channel for 563 Pseudowires", RFC 5085, December 2007. 565 7.2. Informative References 567 [5] Bocci, M., Bryant, S., and L. Levrau, "A Framework for MPLS in 568 Transport Networks", draft-ietf-mpls-tp-framework-00 (work in 569 progress), November 2008. 571 [6] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and 572 S. Ueno, "MPLS-TP Requirements", 573 draft-ietf-mpls-tp-requirements-09 (work in progress), 574 June 2009. 576 [7] ITU-T Supplement Y.Sup4, "ITU-T Y.1300-series: Supplement on 577 transport requirements for T-MPLS OAM and considerations for 578 the application of IETF MPLS technology", 2008. 580 [8] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. 581 Matsushima, "Operations and Management (OAM) Requirements for 582 Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, 583 February 2006. 585 [9] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD 586 For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress), 587 June 2008. 589 [10] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding 590 Detection (BFD) for the Pseudowire Virtual Circuit 591 Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-05 592 (work in progress), June 2009. 594 Authors' Addresses 596 Martin Vigoureux (editor) 597 Alcatel-Lucent 598 Route de Villejust 599 Nozay, 91620 600 France 602 Email: martin.vigoureux@alcatel-lucent.com 603 David Ward (editor) 604 Cisco Systems, Inc. 605 170 W. Tasman Dr. 606 San Jose, CA 95134 607 USA 609 Email: dward@cisco.com 611 Malcolm Betts (editor) 612 Huawei 614 Email: malcolm.betts@huawei.com