idnits 2.17.1 draft-ietf-pwe3-mpls-tp-oam-config-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 23) being 77 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 27, 2014) is 3591 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) == Unused Reference: 'RFC6073' is defined on line 961, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 966, but no explicit reference was found in the text == Unused Reference: 'RFC6478' is defined on line 1004, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PWE3 Working Group F. Zhang 3 Internet-Draft Huawei 4 Intended status: Standards Track B. Wu 5 Expires: December 29, 2014 ZTE Corporation 6 E. Bellagamba 7 Ericsson 8 M. Chen 9 Huawei 10 June 27, 2014 12 Label Distribution Protocol Extensions for Proactive Operations, 13 Administration and Maintenance Configuration of Dynamic MPLS Transport 14 Profile PseudoWire 15 draft-ietf-pwe3-mpls-tp-oam-config-01 17 Abstract 19 This document specifies extensions to the Label Distribution Protocol 20 (LDP) to configure and control proactive Operations, Administration 21 and Maintenance (OAM) functions, which are suitable for dynamic 22 Single-Segment PseudoWire (SS-PW) and Multi-Segment PseudoWire (MS- 23 PW). 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 29, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions used in this document . . . . . . . . . . . . . . 3 61 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. MPLS-TP PW OAM Configuration Overview . . . . . . . . . . . . 5 63 3.1. OAM Configuration for MS-PW . . . . . . . . . . . . . . . 5 64 3.1.1. Establishment of OAM Entities and Functions . . . . . 5 65 3.1.2. Adjustment of OAM Parameters . . . . . . . . . . . . 6 66 3.1.3. Deleting OAM Entities . . . . . . . . . . . . . . . . 7 67 3.2. OAM Configuration for SS-PW . . . . . . . . . . . . . . . 8 68 4. LDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.1. MPLS-TP PW OAM Capability TLV . . . . . . . . . . . . . . 8 70 4.1.1. Backward Compatibility . . . . . . . . . . . . . . . 9 71 4.2. MPLS-TP PW OAM Administration TLV . . . . . . . . . . . . 9 72 4.3. MPLS-TP PW OAM Configuration TLV . . . . . . . . . . . . 10 73 4.3.1. BFD Configuration sub-TLV . . . . . . . . . . . . . . 11 74 4.3.1.1. Local Discriminator sub-TLV . . . . . . . . . . . 13 75 4.3.1.2. Negotiation Timer Parameters sub-TLV . . . . . . 13 76 4.3.1.3. BFD Authentication sub-TLV . . . . . . . . . . . 15 77 4.3.2. Performance Monitoring sub-TLV . . . . . . . . . . . 15 78 4.3.2.1. MPLS-TP PW PM Loss TLV . . . . . . . . . . . . . 16 79 4.3.2.2. MPLS-TP PW PM Delay TLV . . . . . . . . . . . . . 18 80 4.3.3. MPLS-TP PW FMS TLV . . . . . . . . . . . . . . . . . 19 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 82 5.1. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 5.1.1. MPLS-TP PW OAM Configuration Sub-TLV . . . . . . . . 20 84 5.2. OAM Configuration Error Code . . . . . . . . . . . . . . 20 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 86 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 8.1. Normative references . . . . . . . . . . . . . . . . . . 21 89 8.2. Informative References . . . . . . . . . . . . . . . . . 21 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 92 1. Introduction 94 MultiProtocol Label Switching (MPLS) Pseudowire (PW) is defined in 95 [RFC3985] and [RFC5659], which provides emulated services over an 96 MPLS Packet Switched Network (PSN). MPLS Transport Profile (MPLS-TP) 97 describes a profile of MPLS that enables operational models typical 98 in transport networks, while providing additional Operations, 99 Administration and Maintenance (OAM), survivability and other 100 maintenance functions not previously supported by IP/MPLS. The 101 corresponding requirements are defined in [RFC5860]. 103 The MPLS-TP OAM mechanisms are described in [RFC6371], which can be 104 categorized into proactive and on-demand OAM. Proactive OAM refers 105 to OAM operations that are either configured to be carried out 106 periodically and continuously or preconfigured to act on certain 107 events such as alarm signals. In contrast, on-demand OAM is 108 initiated manually and for a limited amount of time, usually for 109 operations such as diagnostics to investigate into a defect 110 condition. 112 Normally, the Network Management System (NMS) is used to configure 113 these OAM functionalities when a control plane is not instantiated. 114 If the control plane is used, it MUST support the configuration and 115 modification of OAM maintenance points as well as the activation/ 116 deactivation of OAM when the transport path or transport service is 117 established or modified (Requirement 51)[RFC5654]. 119 This document defines extensions to the LDP protocol to negotiate PW 120 OAM capabilities, configure and bootstrap proactive PW OAM functions, 121 which are suitable for Point to Point (P2P) SS-PW and MS-PW. The 122 extensions to Point to Multi-Point (P2MP) PW will be studied in the 123 future. 125 2. Conventions used in this document 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 2.1. Acronyms 133 AC: Attachment Circuit 135 AIS: Alarm indication signal 137 BFD: Bidirectional Forwarding Detection 139 CC: Continuity Check 141 CV: Connectivity Verification 143 DM: Delay Measurement 144 FEC: Forwarding Equivalence Class 146 FMS: Fault Management Signal 148 ICMP: Internet Control Message Protocol 150 G-ACh: Generic Associated Channel 152 LDI: Link Down Indication 154 LDP: Label Distribution Protocol 156 LKR: Lock Reporting 158 LM: Loss Measurement 160 LSP: Label Switched Path 162 ME: Maintenance Entity 164 MEG: Maintenance Entity Group 166 MEP: Maintenance Entity Group End Point 168 MIP: Maintenance Entity Group Intermediate Point 170 MPLS-TP: MPLS Transport Profile 172 MS-PW: Multi-Segment PseudoWire 174 NMS: Network Management System 176 OAM: Operations, Administration and Maintenance 178 P2MP: Point to Multi-Point 180 PE: Provider Edge 182 PHB: Per-Hop Behavior 184 PM: Performance Monitoring 186 PSN: Packet Switched Network 188 PW: Pseudowire 190 S-PE: Switching Provider Edge 191 SPME: Sub-Path Maintenance Entity 193 SS-PW: Single-Segment Pseudo Wire 195 T-PE: Terminating Provider Edge 197 TLV: Type Length Value 199 VCCV: Virtual Circuit Connectivity Verification 201 3. MPLS-TP PW OAM Configuration Overview 203 When OAM functions are required for PWs, before starting to configure 204 and enable the OAM functions, the PEs SHOULD negotiate the OAM 205 capability when the PWs are first set up, hence to know what OAM 206 functions the PEs can support. To achieve this, a new LDP TLV, 207 MPLS-TP PW OAM Capability TLV is defined (Section 4.1), it is included 208 in the LDP Initialization message and used to carry the MPLS-TP PW OAM 209 capabilities that a PE support. So, if a PE does not receive any 210 MPLS-TP PW OAM Capability TLV from the remote PE, it SHOULD NOT send 211 the MPLS-TP PW OAM configuration information to the PE and try to 212 configure and enable related OAM functions. 214 Section 3.1 describes the general OAM configuration procedures. For 215 SS-PW and MS-PW, the OAM configuration procedures are mostly 216 identical. One exception is that SS-PW does not need to configure 217 the MIP function. Section 3.2 highlights the differences between the 218 two. 220 3.1. OAM Configuration for MS-PW 222 3.1.1. Establishment of OAM Entities and Functions 224 Assuming there is one PW that needs to be setup between T-PE1 and 225 T-PE2, across S-PE1 and S-PE2. OAM functions must be setup and 226 enabled in the appropriate order so that spurious alarms can be 227 avoided. 229 +-------+ +-------+ +-------+ +-------+ 230 | | | | | | | | 231 | A|--------|B C|--------|D E|--------|F | 232 | | | | | | | | 233 +-------+ +-------+ +-------+ +-------+ 234 T-PE1 S-PE1 S-PE2 T-PE2 236 Figure 1: MS-PW OAM Configuration Scheme 238 Fist of all, T-PE1 MUST setup the OAM sink function to be prepared to 239 receive OAM messages but MUST suppress any OAM alarms (e.g., due to 240 missing or unidentified OAM messages). The Mapping message MUST be 241 sent with the "OAM Alarms Enabled" cleared and "OAM MIP Entities 242 desired" set in the MPLS-TP PW OAM Administration TLV. 244 When the Mapping message arrives at the downstream S-PEs, such as 245 S-PE1 and S-PE2, they MUST establish and configure MIP entities 246 according to the set "I"flag in the MPLS-TP PW OAM Administration 247 TLV. If failure, a Notification message SHOULD be sent, with a 248 Status Code set to "MIP Configuration Failure". If OAM entities are 249 established successfully, the middle points (S-PE1 and S-PE2) MUST 250 forward the Mapping message downstream, the endpoint (T-PE2) MUST set 251 the OAM Source function and MUST be prepared to Send OAM messages. 253 The same rules are applied to the reverse direction (from T-PE2 to 254 T-PE1), that is to say, T-PE2 needs to setup the OAM sink function to 255 be prepared to receive OAM messages but MUST suppress any OAM alarms 256 (e.g., due to missing or unidentified OAM messages). The Mapping 257 message MUST be sent with the "OAM Alarms Enabled" cleared, "OAM MIP 258 Entities desired" set in the MPLS-TP PW OAM Administration TLV. When 259 T-PE1 receives the Mapping message, it completes any pending OAM 260 configuration and enables the OAM source function to send OAM 261 messages. 263 After this, OAM entities are established and configured for the PW 264 and OAM messages MAY already be exchanged, and OAM alarms can now be 265 enabled. The T-PE nodes (T-PE1 and T-PE2), while still keeping OAM 266 alarms disabled send a Notification message with "OAM Alarms Enabled" 267 PW status flag set, and enable the OAM alarms after processing the 268 Notification message. At this point, data-plane OAM is fully 269 functional, and the MPLS-TP OAM PW configuration TLV MAY be omitted 270 in subsequent Notification messages 272 The PW MAY be setup with OAM entities right away with the first 273 signalling, as described above, but a PW MAY be signalled and 274 established without OAM configuration first, and OAM entities may be 275 added later. This can be done by sending a Notification message with 276 the related configuration parameters subsequently. 278 3.1.2. Adjustment of OAM Parameters 280 There may be a need to change the parameters of an already 281 established and configured OAM function during the lifetime of the 282 PW. To do so the T-PE nodes need to send a Notification message with 283 the updated parameters. OAM parameters that influence the content 284 and timing of OAM messages and identify the way OAM defects and 285 alarms are derived and generated. Hence, to avoid spurious alarms, 286 it is important that both sides, OAM sink and source, are updated in 287 a synchronized way. Firstly, the alarms of the OAM sink function 288 should be suppressed and only then should expected OAM parameters be 289 adjusted. Subsequently, the parameters of the OAM source function 290 can be updated. Finally, the alarms of the OAM sink side can be 291 enabled again. 293 In accordance with the above operation, T-PE1 MUST send a 294 Notification message with "OAM Alarms Enabled" cleared and including 295 the updated MPLS-TP PW OAM Configuration TLV corresponding to the new 296 parameter settings. The initiator (T-PE1) MUST keep its OAM sink and 297 source functions running unmodified, but it MUST suppress OAM alarms 298 after the updated Notification message is sent. The receiver (T-PE2) 299 MUST firstly disable all OAM alarms, then update the OAM parameters 300 according to the information in the Notification message and reply 301 with a Notification message acknowledging the changes by including 302 the MPLS-TP PW OAM Configuration TLV. Note that the receiving side 303 has the possibility to adjust the requested OAM configuration 304 parameters and reply with and updated MPLS-TP PW OAM Configuration 305 TLV in the Notification message, reflecting the actually configured 306 values. However, in order to avoid an extensive negotiation phase, 307 in the case of adjusting already configured OAM functions, the 308 receiving side SHOULD NOT update the parameters requested in the 309 Notification message to an extent that would provide lower 310 performance than what has been configured previously. 312 The initiator (T-PE1) MUST only update its OAM sink and source 313 functions when it has received the Notification message from the 314 peer. After the OAM parameters are updated and OAM is running 315 according the new parameter settings, OAM alarms are still disabled, 316 so a subsequent Notification messages exchanges with "OAM Alarms 317 Enabled" flag set are needed to enable OAM alarms again. 319 3.1.3. Deleting OAM Entities 321 In some cases it may be useful to remove some or all OAM entities and 322 functions from one PW without actually tearing down the connection. 323 To avoid any spurious alarm, the following procedure should be 324 followed: 326 The T-PE nodes disable OAM alarms and SHOULD send Notification 327 message to each other with "OAM Alarms Enabled" cleared but unchanged 328 OAM configuration and without the MPLS-TP PW OAM Configuration TLV. 329 After that, T-PE1 (T-PE2) SHOULD delete OAM source functions, then 330 send a Notification message with "OAM MIP Entities desired" cleared. 331 While T-PE2 (T-PE1) deletes OAM sink function, S-PE1 and S-PE2 delete 332 MIP configuration when they receive the Notification message with 333 "OAM MIP Entities desired" cleared. 335 Alternatively, if only some OAM functions need to be removed, the 336 T-PE node sends the Notification message with the updated OAM 337 Configuration TLV. Changes between the contents of the previously 338 signalled OAM Configuration TLV and the currently received TLV 339 represent which functions SHOULD be removed/added. 341 3.2. OAM Configuration for SS-PW 343 Assuming there is one PW that needs to be setup between T-PE1 and 344 T-PE2. 346 If the receiving PE (T-PE2) have initiated the MPLS-TP PW OAM 347 configuration request to the other PE (T-PE1), it MUST compare its 348 AII against T-PE1's. If it is numerically lower, will reply a 349 Notification message with the updated "MPLS-TP PW OAM Configuration 350 TLV", and the Status Code set to "Wrong MPLS-TP PW OAM Configuration 351 TLV". 353 On the other hand, if the T-PE2's AII is numerically higher than 354 T-PE1's, it MUST reply a Notification message with Status Code set to 355 "Rejected MPLS-TP PW OAM Configuration TLV". 357 4. LDP Extensions 359 Below, LDP extensions to configure proactive MPLS-TP PW OAM functions 360 are defined. 362 4.1. MPLS-TP PW OAM Capability TLV 364 A new Capability Parameter TLV called the MPLS-TP PW OAM Capability 365 TLV is defined, and the format is as follows: 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 |1|0| Type (TBD) | Length (= 4) | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 |S| Reserved | Capability Data |F|D|L|V|C| 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 MPLS-TP PW OAM Capability TLV 377 The value of the U-bit for the MPLS-TP PW OAM Capability TLV MUST be 378 set to 1 so that a receiver MUST silently ignore this TLV if unknown 379 to it, and continue processing the rest of the message[RFC5036]. 380 Currently defined specific OAM Capability Flags in the "Capability 381 Data" field from right to left are: 383 One bit "C" (31, IANA to assign) CC mode supported 384 One bit "V" (30, IANA to assign) CV mode supported 385 One bit "L" (29, IANA to assign) PM Loss supported 386 One bit "D" (28, IANA to assign) PM Delay supported 387 One bit "F" (27, IANA to assign) FMS supported 388 Bits 8-26: This field MUST be set to zero 389 on transmission and MUST be ignored on receipt. 391 The above bits can be set individually to indicate more than one kind 392 of OAM capabilities at once, and the other reserved bits MUST be set 393 to zero on transmission and MUST be ignored on receipt. Moreover, if 394 CV flag is set, the CC flag MUST be set at the same time. 396 The MPLS-TP PW OAM Capability TLV MAY be included by a PE in an 397 Initialization message to signal its peer that it supports the MPLS- 398 TP PW OAM Capability. If the remote peer does not support the MPLS- 399 TP PW OAM Capability TLV or the Initialization message sent by the 400 remote peer does not include the MPLS-TP PW OAM Capability TLV, the 401 resulting negotiation does not support MPLS-TP PW OAM capability. If 402 instead the negotiation supports the MPLS-TP PW OAM capability, then 403 the subsequent LDP Mapping message will carry the information of the 404 MPLS-TP PW OAM configuration. 406 4.1.1. Backward Compatibility 408 If both the two T-PEs can recognize the MPLS-TP PW OAM Capability 409 TLV,and CC or CV mode is supported, the BFD configuration procedure 410 described in this document is adopted. Otherwise, if at least one of 411 the two T-PEs do not support the CC or CV mode, the old VCCV BFD 412 [RFC5885] will be performed. In this situation, the procedure 413 described in [RFC5885] MUST be followed: the C and V flags of MPLS-TP 414 PW OAM Configuration TLV MUST NOT be set and the BFD Configuration 415 sub-TLV MUST NOT be carried as a sub-TLV of MPLS-TP PW OAM 416 Configuration TLV also. 418 The described behavior ensures full compatibility with the existing 419 implementations. 421 4.2. MPLS-TP PW OAM Administration TLV 423 The format of the MPLS-TP PW OAM Administration TLV is as follows: 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 |0|0| Type (TBD) | Length | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 |I|A| Reserved | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 MPLS-TP PW OAM Administration TLV 435 One bit "I" (0, IANA to assign): "OAM MIP Entities Desired" is 436 allocated. If the "OAM MIP entities desired" bit is set, it is 437 indicating that the establishment of OAM MIP entities is required at 438 every transit node of the signalled PW. If the establishment of a 439 MIP is not supported, a Notification message MUST be sent with Status 440 Code set to "MIP Configuration Failure". 442 One bit "A" (1, IANA to assign): "OAM Alarms Enabled" is allocated. 443 If the "OAM Alarms Enabled" bit is set, it is indicating that the 444 T-PE needs to enable OAM alarms. 446 Reserved (2-31 bits): This field MUST be set to zero on transmission 447 and MUST be ignored on receipt. 449 4.3. MPLS-TP PW OAM Configuration TLV 451 The "MPLS-TP PW OAM Configuration TLV" is depicted in the following 452 figure. It may be carried in the Mapping and Notification messages, 453 just following the PW Status TLV. 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 |0|0| Type (TBD) | Length | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 |C|V|L|D|F| OAM Function Flags | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | | 463 ~ sub-TLVs ~ 464 | | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 MPLS-TP PW OAM Configuration TLV 469 The "MPLS-TP PW OAM Configuration TLV" contains a number of flags 470 indicating which OAM functions should be activated as well as OAM 471 function specific sub-TLVs with configuration parameters for the 472 particular functions. 474 Type: indicates a new type: the MPLS-TP PW OAM Configuration TLV 475 (IANA to assign). 477 Length: the length of the OAM Function Flags field including the 478 total length of the sub-TLVs in octets. 480 OAM Function Flags: a bitmap numbered from left to right as shown in 481 the figure. 483 These flags are defined in this document: 485 OAM Function Flag bit# Description 486 --------------------- --------------------------- 487 0 (C) Continuity Check (CC) 488 1 (V) Connectivity Verification (CV) 489 2 (L) Performance Monitoring/Loss (PM/Loss) 490 3 (D) Performance Monitoring/Delay (PM/Delay) 491 4 (F) Fault Management Signals (FMS) 492 5-31 Reserved (set all to 0s) 494 Sub-TLVs corresponding to the different flags are as follows. 496 o "BFD Configuration sub-TLV", which MUST be included if the CC and/ 497 or the CV OAM Function flag is set. Furthermore, if the CV flag 498 is set, the CC flag MUST be set at the same time. 500 o "Performance Monitoring sub-TLV", which MUST be included if the 501 PM/Loss OAM Function flag is set. 503 o "MPLS-TP PW FMS sub-TLV", which MAY be included if the FMS OAM 504 Function flag is set. If the "MPLS-TP PW FMS sub-TLV" is not 505 included, default configuration values are used. 507 4.3.1. BFD Configuration sub-TLV 509 The "BFD Configuration sub-TLV is defined for BFD specific 510 configuration parameters, which accommodates generic BFD OAM 511 information and carries sub-TLVs. 513 0 1 2 3 514 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 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | BFD Conf. Type (1) (IANA) | Length | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 |Vers.| PHB |N|S|I|G|U|A| Reserved (set to all 0s) | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | | 521 ~ sub TLVs ~ 522 | | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 BFD Configuration sub-TLV 527 Type: indicates a new type, the "BFD Configuration sub-TLV" (IANA to 528 define, suggested value 1). 530 Length: indicates the length of the TLV including sub-TLVs but 531 excluding the Type and Length field, in octets. 533 Version: identifies the BFD protocol version. If a node does not 534 support a specific BFD version, a Notification message MUST be 535 generated with Status Code set to "Unsupported OAM Version". 537 PHB: Identifies the Per-Hop Behavior (PHB) to be used for periodic 538 continuity monitoring messages. 540 BFD Negotiation (N): If set timer negotiation/re-negotiation via BFD 541 Control Messages is enabled, when cleared it is disabled. 543 Symmetric session (S): If set the BFD session MUST use symmetric 544 timing values. 546 Integrity (I): If set BFD Authentication MUST be enabled. If the 547 "BFD Configuration sub-TLV" does not include a "BFD Authentication 548 sub-TLV" the authentication MUST use Keyed SHA1 with an empty pre- 549 shared key (all 0s). 551 Encapsulation Capability (G): if set, it shows the capability of 552 encapsulating BFD messages into G-ACh channel without IP/UDP headers. 553 If both the G bit and U bit are set, configuration gives precedence 554 to the G bit. 556 Encapsulation Capability (U): if set, it shows the capability of 557 encapsulating BFD messages into G-ACh channel with IP/UDP headers. 558 If both the G bit and U bit are set, configuration gives precedence 559 to the G bit. 561 Operation mode (A): if set, it configures BFD in the associated mode. 562 If it is not set it configures BFD in independent mode. 564 Reserved: Reserved for future specification and set to 0. 566 The "BFD Configuration sub-TLV" MUST include the following sub-TLVs 567 in the Mapping message: 569 o "Local Discriminator sub-TLV". 571 o "Negotiation Timer Parameters sub-TLV" if the N flag is cleared. 573 4.3.1.1. Local Discriminator sub-TLV 575 The "Local Discriminator sub-TLV" is carried as a sub-TLV of the "BFD 576 Configuration sub-TLV" and is depicted below. 578 0 1 2 3 579 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 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Lcl. Discr. Type (1) (IANA) | Length (4) | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Local Discriminator | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 Local Discriminator sub-TLV 588 Type: indicates a new type, the "Local Discriminator sub-TLV" (IANA 589 to define, suggested value 1). 591 Length: indicates the TLV total length in octets (4). 593 Local Discriminator: A unique, nonzero discriminator value generated 594 by the transmitting system and referring to itself, used to 595 demultiplex multiple BFD sessions between the same pair of systems. 597 4.3.1.2. Negotiation Timer Parameters sub-TLV 599 The "Negotiation Timer Parameters sub-TLV" is carried as a sub-TLV of 600 the "BFD Configuration sub-TLV" and is depicted below. 602 0 1 2 3 603 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 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Timer Neg. Type (2) (IANA) | Length (16) | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Acceptable Min. Asynchronous TX interval | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Acceptable Min. Asynchronous RX interval | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Required Echo TX Interval | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 Negotiation Timer Parameters sub-TLV 616 Type: indicates a new type, the "Negotiation Timer Parameters sub- 617 TLV" (IANA to define, suggested value 2). 619 Length: indicates the TLV total length in octets (16). 621 Acceptable Min. Asynchronous TX interval: in case of S (symmetric) 622 flag set in the "BFD Configuration" TLV, it expresses the desired 623 time interval (in microseconds) at which the T-PE initiating the 624 signalling intends to both transmit and receive BFD periodic control 625 packets. If the receiving T-PE can not support such value, it is 626 allowed to reply back with an interval greater than the one proposed. 628 In case of S (symmetric) flag cleared in the "BFD Configuration sub- 629 TLV", this field expresses the desired time interval (in 630 microseconds) at which T-PE intends to transmit BFD periodic control 631 packets in its transmitting direction. 633 Acceptable Min. Asynchronous RX interval: in case of S (symmetric) 634 flag set in the "BFD Configuration sub-TLV", this field MUST be equal 635 to "Acceptable Min. Asynchronous TX interval" and has no additional 636 meaning respect to the one described for "Acceptable Min.Asynchronous 637 TX interval". 639 In case of S (symmetric) flag cleared in the "BFD Configuration sub- 640 TLV", it expresses the minimum time interval (in microseconds) at 641 which T-PE can receive BFD periodic control packets. In case this 642 value is greater than the "Acceptable Min. Asynchronous TX interval" 643 received from the other T-PE, such T-PE MUST adopt the interval 644 expressed in this "Acceptable Min. Asynchronous RX interval". 646 Required Echo TX Interval: the minimum interval (in microseconds) 647 between received BFD Echo packets that this system is capable of 648 supporting, less any jitter applied by the sender as described in 649 [RFC5880] sect. 6.8.9. This value is also an indication for the 650 receiving system of the minimum interval between transmitted BFD Echo 651 packets. If this value is zero, the transmitting system does not 652 support the receipt of BFD Echo packets. If the receiving system can 653 not support this value a Notification MUST be generated with Status 654 Code set to "Unsupported BFD TX Echo rate interval". By default the 655 value is set to 0. 657 4.3.1.3. BFD Authentication sub-TLV 659 The "BFD Authentication sub-TLV" is carried as a sub-TLV of the "BFD 660 Configuration sub-TLV" and is depicted below. 662 0 1 2 3 663 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 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | BFD Auth. Type (3) (IANA) | Length = 8 | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Auth Type | Auth Key ID | Reserved (0s) | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 BFD Authentication sub-TLV 672 Type: indicates a new type, the "BFD Authentication sub-TLV" (IANA to 673 define, suggested value 3). 675 Length: indicates the TLV total length in octets (8). 677 Auth Type: indicates which type of authentication to use. The same 678 values as are defined in section 4.1 of [RFC5880] are used. 680 Auth Key ID: indicates which authentication key or password 681 (depending on Auth Type) should be used. How the key exchange is 682 performed is out of scope of this document. 684 Reserved: Reserved for future specification and set to 0. 686 4.3.2. Performance Monitoring sub-TLV 688 If the "MPLS-TP PW OAM Configuration TLV" has either the L (Loss), D 689 (Delay) flag set, the "Performance Monitoring sub-TLV" MUST be 690 present. 692 In case the values need to be different than the default ones the 693 "MPLS-TP PW PM Loss sub-TLV, "MPLS-TP PW PM Delay sub-TLV" MAY be 694 included: 696 o "MPLS-PW PM Loss sub-TLV" if the L flag is set in the "MPLS-TP PW 697 OAM Configuration TLV"; 699 o "MPLS-PW PM Delay sub-TLV" if the D flag is set in the "MPLS-TP PW 700 OAM Configuration TLV ". 702 The "Performance Monitoring sub-TLV" depicted below is carried as a 703 sub-TLV of the "MPLS-TP PW OAM Configuration TLV" 705 0 1 2 3 706 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 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Perf Monitoring Type (IANA)| Length | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 |D|L|J|Y|K|C| Reserved (set to all 0s) | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | | 713 ~ sub-TLVs ~ 714 | | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 Performance Monitoring sub-TLV 719 o D: Delay inferred/direct (0=INFERRED, 1=DIRECT) 721 o L: Loss inferred/direct (0=INFERRED, 1=DIRECT) 723 o J: Delay variation/jitter (1=ACTIVE, 0=NOT ACTIVE) 725 o Y: Dyadic (1=ACTIVE, 0=NOT ACTIVE) 727 o K: Loopback (1=ACTIVE, 0=NOT ACTIVE) 729 o C: Combined (1=ACTIVE, 0=NOT ACTIVE) 731 4.3.2.1. MPLS-TP PW PM Loss TLV 733 The "MPLS-TP PW PM Loss sub-TLV" depicted below is carried as a sub- 734 TLV of the "Performance Monitoring sub-TLV". 736 0 1 2 3 737 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 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | PM Loss Type (1) (IANA) | Length | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | OTF |T|B| RESERVED | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Measurement Interval | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Test Interval | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Loss Threshold | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 MPLS-TP PW PM Loss sub-TLV 752 Type: indicates a new type, the "MPLS-TP PW PM Loss sub-TLV" (IANA to 753 define, suggested value 1). 755 Length: indicates the length of the parameters in octets. 757 OTF: Origin Timestamp Format of the Origin Timestamp field described 758 in [RFC6374]. By default it is set to IEEE 1588 version 1. 760 Configuration Flags, please refer to [RFC6374] for further details: 762 o T: Traffic-class-specific measurement indicator. Set to 1 when 763 the measurement operation is scoped to packets of a particular 764 traffic class (DSCP value), and 0 otherwise. When set to 1, the 765 DS field of the message indicates the measured traffic class. By 766 default it is set to 1. 768 o B: Octet (byte) count. When set to 1, indicates that the Counter 769 1-4 fields represent octet counts. When set to 0, indicates that 770 the Counter 1-4 fields represent packet counts. By default it is 771 set to 0. 773 Measurement Interval: the time interval (in microseconds) at which LM 774 query messages MUST be sent on both directions. If the T-PE 775 receiving the Mapping message can not support such value, it can 776 reply back with a higher interval. By default it is set to (TBD). 778 Test Interval: test messages interval as described in [RFC6374]. By 779 default it is set to (TBD). 781 Loss Threshold: the threshold value of lost packets over which 782 protections MUST be triggered. By default it is set to (TBD). 784 4.3.2.2. MPLS-TP PW PM Delay TLV 786 The "MPLS-TP PW PM Delay sub-TLV" depicted below is carried as a sub- 787 TLV of the "MPLS-TP PW OAM Configuration TLV" 789 0 1 2 3 790 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 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | PM Delay Type (2) (IANA) | Length | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | OTF |T|B| RESERVED | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Measurement Interval | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Test Interval | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | Delay Threshold | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 MPLS-TP PW PM Delay sub-TLV 805 Type: indicates a new type, the "MPLS-TP PW PM Delay sub-TLV" (IANA 806 to define, suggested value 2). 808 Length: indicates the length of the parameters in octets. 810 OTF: Origin Timestamp Format of the Origin Timestamp field described 811 in [RFC6374]. By default it is set to IEEE 1588 version 1. 813 Configuration Flags, please refer to [RFC6374] for further details: 815 o T: Traffic-class-specific measurement indicator. Set to 1 when 816 the measurement operation is scoped to packets of a particular 817 traffic class (DSCP value), and 0 otherwise. When set to 1, the 818 DS field of the message indicates the measured traffic class. By 819 default it is set to 1. 821 o B: Octet (byte) count. When set to 1, indicates that the Counter 822 1-4 fields represent octet counts. When set to 0, indicates that 823 the Counter 1-4 fields represent packet counts. By default it is 824 set to 0. 826 Measurement Interval: the time interval (in microseconds) at which LM 827 query messages MUST be sent on both directions. If the T-PE 828 receiving the Mapping message can not support such value, it can 829 reply back with a higher interval. By default it is set to (TBD). 831 Test Interval: test messages interval as described in [RFC6374]. By 832 default it is set to (TBD). 834 Delay Threshold: the threshold value of packet delay time over which 835 protections MUST be triggered. By default it is set to (TBD). 837 4.3.3. MPLS-TP PW FMS TLV 839 The "MPLS-TP PW FMS sub-TLV" depicted below is carried as a sub-TLV 840 of the "MPLS-TP PW OAM Configuration TLV". 842 0 1 2 3 843 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 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | Fault mgmt Type (4) (IANA) | Length (8) | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 |A|D|L| Reserved (set to all 0s) |E| PHB | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | Refresh Timer | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 MPLS-TP PW FMS sub-TLV 854 Type: indicates a new type, the "MPLS-TP PW FMS sub-TLV" (IANA to 855 define, suggested value 4). 857 Length: indicates the length of the parameters in octets (8). 859 Signal Flags: are used to enable the following signals: 861 o A: Alarm Indication Signal (AIS) as described in [RFC6427] 863 o D: Link Down Indication (LDI) as described in [RFC6427] 865 o L: Locked Report (LKR) as described in [RFC6427] 867 o Remaining bits: Reserved for future specification and set to 0. 869 Configuration Flags: 871 o E: used to enable/disable explicitly clearing faults 873 o PHB: identifies the per-hop behavior of packets with fault 874 management information 876 Refresh Timer: indicates the refresh timer (in microseconds) of fault 877 indication messages. If the T-PE receiving the Path message can not 878 support such value, it can reply back with a higher interval. 880 5. IANA Considerations 882 5.1. TLV 884 IANA is requested to assign three new TLV types from the registry 885 "TLV Type Name Space" in the "Label Distribution Protocol (LDP) 886 Parameters" registry. 888 Value TLV References 889 ----- -------- ---------- 890 TBD1 MPLS-TP PW OAM Capability TLV this document 891 TBD2 MPLS-TP PW OAM Administration TLV this document 892 TBD3 MPLS-TP PW OAM Configuration TLV this document 894 5.1.1. MPLS-TP PW OAM Configuration Sub-TLV 896 IANA is requested to create a registry of "MPLS-TP Pseudowire OAM 897 Configuration Sub-TLV types". These are 16 bit values. Sub-TLV 898 types 1 through 8 are specified in this document. Sub-TLV types 0 899 and 65535 are reserved. Sub-TLV 9 through 65534 are to be assigned 900 by IANA, using the "Expert Review" policy defined in RFC2434. 902 Value Sub-TLV References 903 ----- -------- ---------- 904 1 BFD Configuration sub-TLV this document 905 2 Performance Monitoring sub-TLV this document 906 3 MPLS-TP PW FMS sub-TLV this document 907 4 Local Discriminator sub-TLV this document 908 5 Negotiation Timer Parameters sub-TLV this document 909 6 BFD Authentication sub-TLV this document 910 7 MPLS-TP PW PM Loss sub-TLV this document 911 8 MPLS-TP PW PM Loss sub-TLV this document 913 5.2. OAM Configuration Error Code 915 IANA is requested to assign the following LDP status codes from the 916 registry "STATUS CODE NAME SPACE" in the "Label Distribution Protocol 917 (LDP) Parameters" registry. 919 Range/Value E Description 920 TBD4 0 "MIP Configuration Failure" 921 TBD5 0 "Rejected MPLS-TP PW OAM Configuration TLV" 922 TBD6 0 "Wrong MPLS-TP PW OAM Configuration TLV" 923 TBD7 0 "Unsupported OAM Version" 924 TBD8 0 "Unsupported BFD TX Echo rate interval" 926 6. Security Considerations 928 Security considerations relating to LDP are described in section 5 of 929 [RFC5036] and section 11 of [RFC5561]. Security considerations 930 relating to use of LDP in setting up PWs is described in section 8 of 931 [RFC4447]. 933 This document defines new TLV/sub-TLV types, and OAM configuration 934 procedures intended for use with MPLS-TP, which do not raise any 935 additional security issues. 937 7. Acknowledgement 939 The authors would like to thank Andrew Malis, Greg Mirsky, Luca 940 Martini, Matthew Bocci, Thomas Nadeau for their valuable comments and 941 discussions, especially would like to thank Eric Gray for his review 942 of this document. 944 8. References 946 8.1. Normative references 948 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 949 Requirement Levels", BCP 14, RFC 2119, March 1997. 951 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 952 Heron, "Pseudowire Setup and Maintenance Using the Label 953 Distribution Protocol (LDP)", RFC 4447, April 2006. 955 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 956 Specification", RFC 5036, October 2007. 958 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 959 Le Roux, "LDP Capabilities", RFC 5561, July 2009. 961 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 962 Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. 964 8.2. Informative References 966 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 967 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 968 October 1998. 970 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 971 Edge (PWE3) Architecture", RFC 3985, March 2005. 973 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 974 and S. Ueno, "Requirements of an MPLS Transport Profile", 975 RFC 5654, September 2009. 977 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 978 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 979 October 2009. 981 [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for 982 Operations, Administration, and Maintenance (OAM) in MPLS 983 Transport Networks", RFC 5860, May 2010. 985 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 986 (BFD)", RFC 5880, June 2010. 988 [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding 989 Detection (BFD) for the Pseudowire Virtual Circuit 990 Connectivity Verification (VCCV)", RFC 5885, June 2010. 992 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 993 Maintenance Framework for MPLS-Based Transport Networks", 994 RFC 6371, September 2011. 996 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 997 Measurement for MPLS Networks", RFC 6374, September 2011. 999 [RFC6427] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S., 1000 and D. Ward, "MPLS Fault Management Operations, 1001 Administration, and Maintenance (OAM)", RFC 6427, November 1002 2011. 1004 [RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, 1005 "Pseudowire Status for Static Pseudowires", RFC 6478, May 1006 2012. 1008 Authors' Addresses 1010 Fei Zhang 1011 Huawei 1013 Email: zhangfei7@huawei.com 1015 Bo Wu 1016 ZTE Corporation 1018 Email: wu.bo@zte.com.cn 1019 Elisa Bellagamba 1020 Ericsson 1021 Farogatan 6 1022 Kista, 164 40 1023 Sweden 1025 Phone: +46 761440785 1026 Email: elisa.bellagamba@ericsson.com 1028 Mach(Guoyi) Chen 1029 Huawei 1031 Email: mach.chen@huawei.com 1033 Attila Takacs 1034 Ericsson 1035 Laborc u. 1. 1036 Budapest, 1037 1037 Hungary 1039 Email: attila.takacs@ericsson.com 1041 Xuehui Dai 1042 ZTE Corporation 1044 Email: dai.xuehui@zte.com.cn 1046 Min Xiao 1047 ZTE Corporation 1049 Email: xiao.min2@zte.com.cn