idnits 2.17.1 draft-ietf-pals-mpls-tp-oam-config-03.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: ---------------------------------------------------------------------------- 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 (July 20, 2015) is 3203 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) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-16) exists of draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-09 -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Zhang, Ed. 3 Internet-Draft Huawei 4 Intended status: Standards Track B. Wu, Ed. 5 Expires: January 21, 2016 ZTE Corporation 6 E. Bellagamba, Ed. 7 Ericsson 8 M. Chen, Ed. 9 Huawei 10 July 20, 2015 12 LDP Extensions for Proactive Operations, Administration and Maintenance 13 Configuration of Dynamic MPLS Transport Profile PseudoWire 14 draft-ietf-pals-mpls-tp-oam-config-03 16 Abstract 18 This document defines extensions to LDP to configure proactive OAM 19 functions for both SS-PW and MS-PW when the PW control plane is used. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 21, 2016. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions used in this document . . . . . . . . . . . . . . 3 57 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. PW OAM Configuration . . . . . . . . . . . . . . . . . . . . 5 59 3.1. OAM Configuration for SS-PW . . . . . . . . . . . . . . . 5 60 3.1.1. Establishment of OAM Entities and Functions . . . . . 5 61 3.1.2. Adjustment of OAM Parameters . . . . . . . . . . . . 7 62 3.1.3. Deleting OAM Entities . . . . . . . . . . . . . . . . 8 63 3.2. OAM Configuration for MS-PW . . . . . . . . . . . . . . . 8 64 3.2.1. Establishment of OAM Entities and Functions . . . . . 9 65 3.2.2. Adjustment of OAM Parameters . . . . . . . . . . . . 10 66 3.2.3. Deleting OAM Entities . . . . . . . . . . . . . . . . 12 67 4. LDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 12 68 4.1. PW OAM Administration TLV . . . . . . . . . . . . . . . . 12 69 4.2. PW OAM Functions TLV . . . . . . . . . . . . . . . . . . 13 70 4.2.1. BFD Configuration sub-TLV . . . . . . . . . . . . . . 15 71 4.2.1.1. Local Discriminator sub-TLV . . . . . . . . . . . 16 72 4.2.1.2. Negotiation Timer Parameters sub-TLV . . . . . . 17 73 4.2.1.3. BFD Authentication sub-TLV . . . . . . . . . . . 18 74 4.2.1.4. Traffic Class Sub-TLV . . . . . . . . . . . . . . 19 75 4.2.2. Performance Monitoring sub-TLV . . . . . . . . . . . 20 76 4.2.2.1. PM Loss Sub-TLV . . . . . . . . . . . . . . . . . 21 77 4.2.2.2. PM Delay Sub-TLV . . . . . . . . . . . . . . . . 23 78 4.2.3. Fault Management Signal Sub-TLV . . . . . . . . . . . 24 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 80 5.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 81 5.1.1. PW OAM Configuration Sub-TLV . . . . . . . . . . . . 26 82 5.1.1.1. BFD Configuration sub-TLVs . . . . . . . . . . . 26 83 5.1.1.2. Performance Monitoring sub-TLVs . . . . . . . . . 26 84 5.2. OAM Configuration Status Code . . . . . . . . . . . . . . 26 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 86 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 28 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 88 8.1. Normative references . . . . . . . . . . . . . . . . . . 28 89 8.2. Informative References . . . . . . . . . . . . . . . . . 28 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 92 1. Introduction 94 There are two documents that define MultiProtocol Label Switching 95 (MPLS) Pseudowire (PW). [RFC3985] defines Single Segment PW (SS-PW) 96 and [RFC5659] defines Multi-Segment PW (MS-PW). The two documents 97 explain how to provide emulated services over an MPLS Packet Switched 98 Network (PSN). The MPLS Transport Profile (MPLS-TP) is described in 99 [RFC5291], which describes a profile of MPLS that introduces the 100 operational models that were typically used in transport networks, 101 while providing additional Operations, Administration and Maintenance 102 (OAM), survivability and other maintenance functions that were not 103 previously supported by IP/MPLS network. The MPLS-TP requirements 104 are defined in [RFC5860]. 106 The MPLS-TP OAM mechanisms are described in [RFC6371], which can be 107 categorized into proactive and on-demand OAM. Proactive OAM refers 108 to OAM operations that are either configured to be carried out 109 periodically and continuously or preconfigured to act on certain 110 events (e.g., alarm signals). In contrast, on-demand OAM is 111 initiated manually and for a limited amount of time, usually for 112 operations such as diagnostics to investigate into a defect 113 condition. 115 When a control plane is not used the OAM functions are typically 116 configured from the Network Management System (NMS). When a control 117 plane is used, requirement 51 in [RFC5654] requires that it MUST be 118 able to support configuration of the OAM functions. The control 119 plane is also required to be able to configure, maintain and modify, 120 as well as activation/deactivation of maintenance points. 122 For MPLS-TP OAM configuration, two companion documents exists. 123 [RFC7260] and [RFC7487] define extensions to Resource Reservation 124 Protocol - Traffic Engineering (RSVP-TE) to support the establishment 125 and configuration of OAM entities along with Label Switched Path 126 (LSP) signaling. [I-D.ietf-mpls-lsp-ping-mpls-tp-oam-conf] defines 127 extensions to LSP Ping [RFC4379] to support the configuration of 128 proactive MPLS-TP OAM functions. 130 This document defines extensions to the Label Distribution Protocol 131 (LDP) to configure proactive MPLS-TP PW OAM functions for both Point 132 to Point SS-PW and MS-PW when the PW control plane is used. The 133 extensions defined in this document are aligned with those companion 134 documents. Extensions to Point to Multi-Point (P2MP) PW are for 135 future study and outside the scope of this document. 137 2. Conventions used in this document 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 2.1. Acronyms 145 AIS: Alarm indication signal 147 BFD: Bidirectional Forwarding Detection 149 CC: Continuity Check 151 CV: Connectivity Verification 153 DM: Delay Measurement 155 FEC: Forwarding Equivalence Class 157 FMS: Fault Management Signal 159 G-ACh: Generic Associated Channel 161 LDI: Link Down Indication 163 LDP: Label Distribution Protocol 165 LM: Loss Measurement 167 LSP: Label Switched Path 169 MEP: Maintenance Entity Group End Point 171 MIP: Maintenance Entity Group Intermediate Point 173 MPLS-TP: MPLS Transport Profile 175 MS-PW: Multi-Segment PseudoWire 177 NMS: Network Management System 179 OAM: Operations, Administration and Maintenance 181 P2MP: Point to Multi-Point 183 PE: Provider Edge 185 PHB: Per-Hop Behavior 187 PM: Performance Monitoring 189 PSN: Packet Switched Network 190 PW: Pseudowire 192 S-PE: Switching Provider Edge 194 SS-PW: Single-Segment Pseudo Wire 196 T-PE: Terminating Provider Edge 198 TLV: Type Length Value 200 3. PW OAM Configuration 202 This document defines two new TLVs, the PW OAM Administration TLV and 203 the PW OAM Functions TLV. 205 The PW OAM Administrations TLV is used to setup/remove MIP and MEP 206 functions and to control whether OAM alarm function should be 207 suppressed or not. 209 The PW OAM Functions TLV is used to configure, enable and disable OAM 210 functions that include Continuity Check (CC), Connectivity 211 Verification (CV), Packet Loss/Delay/Throught and PM and Fault 212 Management Signal(FMS). More details about the new TLVs can be found 213 in Section 4. 215 3.1. OAM Configuration for SS-PW 217 3.1.1. Establishment of OAM Entities and Functions 219 OAM entities and functions can be setup, configured and activated 220 either when the PW first is signalled or on an already established 221 PW. This section describes how the OAM entities and functions are 222 setup and configured with the signalling of a PW. 224 For the case where OAM entities and functions are setup and 225 configured after establishment of a PW, the procedures are identical 226 to the "adjustment of OAM parameters" procedures, more detail can be 227 found in Section 3.1.2. 229 Given that a SS-PW needs to be setup between PE1 and PE2 (see 230 Figure 1) . OAM functions MUST be setup and enabled in the 231 appropriate order so that spurious alarms can be avoided. 233 +-------+ +-------+ 234 | | | | 235 | |---------------| | 236 | | | | 237 +-------+ +-------+ 238 PE1 PE2 240 Figure 1 SS-PW OAM Configuration Scheme 242 Figure 1: SS-PW OAM Configuration Scheme 244 Fist, the ingress PE (e.g., PE1) must setup the OAM sink function and 245 prepare to receive OAM messages. Until the PW is fully established, 246 any OAM alarm SHOULD be suppressed. 248 To achieve this, a Label Mapping message with the "OAM Alarms 249 Enabled" flag cleared is sent. In the message, the "OAM MEP Entities 250 Desired" flag is set. Since there is no MIPs for a SS-PW, the "OAM 251 MIP Entities desired" flag MUST be cleared. In addition, to 252 configure and enable particular OAM functions, the PW OAM Functions 253 TLV and relevant sub-TLVs MUST be included. 255 When the Label Mapping message is received by PE2, PE2 needs to check 256 whether it supports the requested OAM configuration. If it does not 257 support the requested OAM configuration, a Label Release message MUST 258 be returned to PE1, with a Status Code set to "PW OAM Parameters 259 Rejected". The PW signalling is complete and the PW will not be 260 established. If the requested OAM parameters and configuration are 261 supported, PE2 will establish and configure the requested OAM 262 entities. 264 If PE2 fails to establish and configure the OAM entities, a Label 265 Release message will be returned to PE1, with a Status Code set to 266 "PW MEP Configuration Failed". The PW signalling is complete and the 267 PW will not be established. 269 If the OAM entities are setup and configured successfully, the OAM 270 sink and source functions is setup and the OAM sink function will be 271 configured to receive OAM messages. 273 Since the OAM alarm is disabled, no alarms will be generated. The 274 OAM source function can start to send OAM messages. PE2 will then 275 reply a Label Mapping message to PE1, the PW OAM Administration TLV 276 and PW OAM Configuration TLV from the received Label Mapping message 277 MUST be copied and carried in the Label Mapping message. 279 When PE1 receives this Label Mapping message, PE1 completes any 280 pending OAM configuration and enables the OAM source function to send 281 OAM messages. 283 For PE1, the OAM entities and functions are now setup and configured, 284 and OAM messages may be exchanged. The OAM alarms can be safely 285 enabled. The initiator PE (PE1) will send another Label Mapping 286 message with "OAM Alarms Enabled" flag set to PE2, this will allow 287 PE2 to enable the OAM alarm function. 289 When the Label Mapping message is received by PE2, the OAM alarm will 290 be enabled. PE2 then sends a Notification message with the Status 291 Code set to "PW OAM Alarms enabled" to PE1. 293 When the Notification message is received by PE1, PE1 enables the OAM 294 alarm function. At this point, data-plane OAM is fully functional. 296 3.1.2. Adjustment of OAM Parameters 298 Existing OAM parameters may be changed during the life time of a PW. 299 To achieve this, PE1 sends a Label Mapping message with the updated 300 OAM parameters to PE2. 302 To avoid spurious alarms, it is important that OAM sink and source 303 functions on both PEs are updated in a synchronized way. First, the 304 alarms of the OAM sink function should be suppressed. After that, 305 new OAM parameters can be adjusted. Subsequently, the parameters of 306 the OAM source function can be updated. Finally, the alarms can be 307 enabled again. 309 Consequently, the ingress PE needs to keep its OAM sink and source 310 functions running without any changes until the OAM parameters are 311 updated. However, in order to suppress spurious alarms, it also need 312 to disable the alarm functions before the Label Mapping message, with 313 the "OAM Alarms Enabled" flag cleared and the updated PW OAM Function 314 TLV, is sent. The OAM alarm function needs to be disabled until the 315 corresponding response message is received. 317 On receipt of the Label Mapping message, PE2 needs to check whether 318 the updated parameters can be supported. If they can be supported, 319 PE2 needs first disable the OAM alarms firstly and then update the 320 OAM parameters. When the update is done, a Notification message 321 needs to be sent to PE1, with the Status Code set to "PW MEP 322 Configuration Succeed", to acknowledge the update. If PE2 can not 323 support the update, a Notification message with Status Code set to 324 "PW OAM Parameters Rejected" will be sent to PE1. 326 When PE1 receives the Notification message with the Status Code set 327 to "PW MEP Configuration Succeed", PE1 will update using the new OAM 328 parameters. After the OAM parameters are updated and the OAM is 329 running with the new parameter settings, OAM alarms are still 330 disabled. A subsequent Label Mapping message with "OAM Alarms 331 Enabled" flag set will be sent to re-enable OAM alarms. If the 332 Status Code of the received Notification message is "PW OAM 333 Parameters Rejected", it will not update the OAM parameters. The OAM 334 alarms are just enabled again and the OAM will keep running with the 335 old parameters. PE1 can also re-try changing the OAM parameters 336 using a different set of parameters. 338 When PE2 received the Label Mapping message with "OAM Alarms Enabled" 339 flag set, it will enable the OAM alarms and reply a Notification 340 message with Status Code set to "PW OAM Alarms Enabled". When 341 received the Notification message, PE1 will enable the OAM alarms 342 again. 344 3.1.3. Deleting OAM Entities 346 In some cases it may be useful to remove all OAM entities and 347 functions from a PW without actually tearing down the connection. 348 The deleting procedures are defined as below: 350 First, the ingress PE (e.g., PE1) disables its own the OAM alarms and 351 then sends a Label Mapping message to the remote PE (e.g., PE2) with 352 the "OAM Alarms Enabled" flag set but with all other OAM 353 configurations unchanged. 355 When received the Label Mapping message, PE2 disables the OAM alarm 356 and then send a Notification message with Status Code set to "PW OAM 357 Alarms Disabled" to PE1. 359 When received the confirmation from PE2, it's safe to delete the OAM 360 entities. PE1 will delete the OAM entities related to the PW and 361 send another Label Mapping message with the "OAM MEP Entities 362 desired" flag cleared to PE2. 364 When PE2 received the Label Mapping message, it will delete all OAM 365 entities related to the PW and then reply a Notification message with 366 the Status Code set to "PW MEP Entities Disabled" to PE1. 368 3.2. OAM Configuration for MS-PW 369 3.2.1. Establishment of OAM Entities and Functions 371 Given that a MS-PW needs to be setup between T-PE1 and T-PE2, across 372 S-PE1 and S-PE2 (see Figure 2) . OAM functions MUST be setup and 373 enabled in the appropriate order so that spurious alarms can be 374 avoided. 376 +-------+ +-------+ +-------+ +-------+ 377 | | | | | | | | 378 | A|--------|B C|--------|D E|--------|F | 379 | | | | | | | | 380 +-------+ +-------+ +-------+ +-------+ 381 T-PE1 S-PE1 S-PE2 T-PE2 383 Figure 2 MS-PW Scenario 385 Figure 2: MS-PW OAM Configuration Scheme 387 Fist, T-PE1 must setup the OAM sink function and prepare to receive 388 OAM messages. Until the PW is fully established, any OAM alarm 389 SHOULD be suppressed. 391 To achieve this, a Label Mapping message with the "OAM Alarms 392 Enabled" flag cleared is sent. If the S-PEs are expected to setup 393 and configure the MIP entities, the "OAM MIP Entities desired" flag 394 MUST be set. In the message, the "OAM MEP Entities Desired" flag is 395 set. In addition, to configure and enable particular OAM functions, 396 the PW OAM Functions TLV and relevant sub-TLVs MUST be included. 398 On receipt of the Label Mapping message, S-PE(e.g., S-PE1) needs to 399 check whether it supports MIP function. If S-PE1 does not support 400 MIP function, a Notification message will be sent to T-PE1, with the 401 Status Code set to "PW MIP Configuration Failed". If S-PE1 supports 402 MIP function, it will establish and configure the MIP entities 403 according to the "OAM MIP Entities desired" flag in the PW OAM 404 Administration TLV. No matter whether S-PE1 supports MIP function, 405 it will relay the Label Mapping message downstream to the next S-PE. 406 All the subsequent S-PEs along the PW will perform the same 407 operations as S-PE1 does until the Label Mapping message reaches the 408 remote T-PE (T-PE2). 410 When the Label Mapping message is received by the remote T-PE 411 (T-PE2), T-PE2 needs to check whether it support the requested OAM 412 configuration. If it does not support the requested OAM 413 configuration, a Label Release message MUST be returned to its 414 upstream PE, with a Status Code set to "PW MEP Configuration Failed". 415 The signalling is complete and the PW will not be established. If 416 the requested OAM parameters and configuration are supported, T-PE2 417 will establish and configure requested OAM entities. 419 If T-PE2 fails to establish and configure the OAM entities, a Label 420 Release message MUST be replied to its upstream PE, with a Status 421 Code set to "PW MEP Configuration Failed". The signalling is 422 complete and the PW will not be established. 424 If the OAM entities established and configured successfully, the OAM 425 sink and source functions are setup and the OAM sink function will be 426 configured to receive OAM messages. Since the OAM alarm is disabled, 427 no alarms will be generated. The OAM source function can start to 428 send OAM messages. T-PE2 will then reply a Label Mapping message, 429 the PW OAM Administration TLV and PW OAM Function TLV from the 430 received Label Mapping message MUST be copied and carried in the 431 returned Label Mapping message. 433 S-PEs will relay the Label Mapping message upstream until it reaches 434 T-PE1. When the Label Mapping message is received by T-PE1, T-PE1 435 will complete any pending OAM configuration and enables the OAM 436 source function to send OAM messages. 438 For T-PE1, the OAM entities and functions are now setup and 439 configured, and OAM messages may be exchanged. The OAM alarms can be 440 safely enabled. T-PE1 will send another Label Mapping message with 441 "OAM Alarms Enabled" flag set to enable the OAM alarm function. 443 When the Label Mapping message is received by S-PEs, S-PEs will 444 enable the OAM alarm and relay the Label Mapping message downstream 445 until it reaches T-PE2. 447 When the Label Mapping message is received by T-PE2, the OAM alarm 448 will be enabled. T-PE2 then sends a Notification message to T-PE1, 449 with the Status Code set to "PW OAM Alarms Enabled". Once the 450 Notification message is received by T-PE1, T-PE1 enables the OAM 451 alarm function. At this point, data-plane OAM is fully functional. 453 3.2.2. Adjustment of OAM Parameters 455 Existing OAM parameters may be changed during the life time of a PW. 456 To achieve this, the T-PE1 needs to send a Label Mapping message with 457 the updated OAM parameters to adjust and update OAM parameters. 459 To avoid spurious alarms, it is important that OAM sink and source 460 functions on both sides are updated in a synchronized way. Fist, the 461 alarms of the OAM sink function should be suppressed. After that, 462 new OAM parameters can be adjusted. Subsequently, the parameters of 463 the OAM source function can be updated. Finally, the alarms can be 464 enabled again. 466 Consequently, T-PE1 needs to keep its OAM sink and source functions 467 running without any changes until the OAM parameters are updated. 468 However, in order to suppress spurious alarms, it also need to 469 disable the alarm functions before the Label Mapping message, with 470 the "OAM Alarms Enabled" flag cleared and the updated PW OAM Function 471 TLV, is sent. The OAM alarm function needs to be disabled until the 472 corresponding response message is received. 474 When the Label Mapping message is received by S-PEs, each S-PE just 475 disables the OAM alarm and relay the Label Mapping message downstream 476 until the Label Mapping message reaches the remote T-PE (T-PE2). 478 On receipt of the Label Mapping message, T-PE2 needs to check whether 479 the updated parameters can be supported. If they can be supported, 480 T-PE2 needs first disable the OAM alarms and then update the OAM 481 parameters. When the update is done, a Notification message needs to 482 be sent to T-PE1, with the Status Code set to "PW MEP Configuration 483 Succeed", to acknowledge the update. If T-PE2 can not support the 484 update, a Notification message with Status Code set to "PW OAM 485 Parameters Rejected" will be sent T-PE1. 487 When T-PE1 receives the Notification message with the Status Code set 488 to "PW MEP Configuration Succeed", T-PE1 will update using the new 489 OAM parameters. After the OAM parameters are updated and the OAM is 490 running with the new parameter settings, OAM alarms are still 491 disabled. A subsequent Label Mapping message with "OAM Alarms 492 Enabled" flag set will be sent to re-enable OAM alarms. If the 493 Status Code of the received Notification message is "PW OAM 494 Parameters Rejected", it will not update the OAM parameters. The OAM 495 alarms are just enabled again and the OAM will keep running with the 496 old parameters. T-PE1 can also re-try changing the OAM parameters 497 using a different set of parameters. 499 When S-PEs receives the Label Mapping message, they will enable the 500 OAM alarms and relay the Label Mapping message downstream. 502 When T-PE2 receives the Label Mapping message with the "OAM Alarms 503 Enabled" flag set, it will enable the OAM alarms and reply a 504 Notification message with Status Code set to "PW OAM Alarms Enabled". 505 When received the Notification message, T-PE1 will enable the OAM 506 alarms again. 508 3.2.3. Deleting OAM Entities 510 In some cases it may be useful to remove all OAM entities and 511 functions from a PW without actually tearing down the connection. 512 The deleting procedures are defined as below: 514 First, T-PE1disables its own the OAM alarms and then sends a Label 515 Mapping message to the remote PE (e.g., T-PE2) with the "OAM Alarms 516 Enabled" flag cleared but with all other OAM configurations 517 unchanged. 519 When received the Label Mapping message, S-PEs will disable the OAM 520 alarm and relay the Mapping message downstream until the Label 521 Mapping message reaches the remote T-PE (T-PE2). 523 When received the Label Mapping message, T-PE2 will disable the OAM 524 alarm and then reply a Notification message with Status Code set to 525 "PW OAM Alarms Disabled" to T-PE1. 527 When received the confirmation from T-PE2, it's safe to delete the 528 OAM entities. T-PE1 will delete the all OAM entities associated with 529 the PW and send another Label Mapping message with both the "OAM MEP 530 Entities desired" and "OAM MIP Entities desired" flags cleared to the 531 remote T-PE. 533 When received the Label Mapping message, S-PE (e.g., S-PE1) will 534 delete all the OAM entities associated with the PW and relay the 535 Label Mapping message downstream. Subsequent S-PEs will do the same 536 operations until the Label Mapping message reaches the remote T-PE. 538 When T-PE2 receives the Label Mapping message, it will delete all OAM 539 entities associated with the PW and then reply a Notification message 540 with the Status Code set to "PW MEP Entities Disabled" to T-PE1. 542 4. LDP Extensions 544 4.1. PW OAM Administration TLV 546 The PW OAM Administration TLV is used to configure and enable the 547 MEP, MIP and Alarm functions. It can be sent with the Label Mapping 548 message. The format of the TLV is as follows: 550 0 1 2 3 551 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 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 |0|0| Type | Length(=4) | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | OAM Administration Flags | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 PW OAM Administration TLV 560 The PW OAM Administration TLV type is TBD1. 562 The Length field is 2 octets in length. It defines the length in 563 octets of OAM Administration Flags filed, it's value is 4. 565 The OAM Administration Flags is a bitmap with the length of 4 octets. 567 This document defines the following flags: 569 OAM Administration Flags bit# Description 570 ----------------------------- -------------------------------- 571 0 OAM MIP Entities Desired 572 1 OAM MEP Entities Desired 573 2 OAM Alarms Enabled 574 3-31 Reserved 576 The "OAM MIP Entities Desired" flag is used to direct the S-PE(s) 577 along a PW to establish (when set) or delete (when cleared ) the OAM 578 MIP entities. This flag only applies to MS-PW scenario. For SS-PW 579 case, this flag MUST be cleared when sent, and SHOULD be ignored when 580 received. 582 The "OAM MEP Entities Desired" flag is used to request the remote 583 T-PE to establish (when set) or delete (when cleared) the OAM 584 entities. 586 The "OAM Alarms Enabled" flag is used to request the received PEs to 587 enable (when set) or disable (when cleared) OAM alarms function. 589 Reserved (3-31 bits): MUST be set to zero on transmission and SHOULD 590 be ignored on receipt. 592 4.2. PW OAM Functions TLV 594 The PW OAM Functions TLV is defined to configure and enable specific 595 OAM functions, it is carried in Label Mapping message when used. The 596 format of the TLV is as follows: 598 0 1 2 3 599 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 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 |0|0| Type | Length | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | OAM Function Flags | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 ~ sub-TLVs ~ 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 PW OAM Functions TLV 610 The PW OAM Functions TLV contains a number of flags indicating which 611 OAM functions should be activated and OAM function specific sub-TLVs 612 with configuration parameters for particular functions. 614 The PW OAM Functions TLV type is TBD2. 616 The Length field is 2 octets in length. It defines the length in 617 octets of OAM Function Flags and sub-TLVs fields. 619 The OAM Function Flags is a bitmap with the length of 4 octets. 621 This document defines the following flags: 623 OAM Function Flags bit# Description 624 --------------------- --------------------------- 625 0 Continuity Check (CC) 626 1 Connectivity Verification (CV) 627 2 Fault Management Signals (FMS) 628 3 Performance Monitoring (PM) Loss 629 4 Performance Monitoring (PM) Delay 630 5 Performance Monitoring (PM) Throughput 631 6-31 Reserved 633 The sub-TLVs corresponding to the different OAM function flags are as 634 follows. 636 o BFD Configuration sub-TLV MUST be included if the CC and/or the CV 637 OAM Function flag is set. Furthermore, if the CV flag is set, the 638 CC flag MUST be set as well. 640 o Performance Monitoring sub-TLV MUST be included if the PM Loss/ 641 Delay OAM Function flag is set. 643 o Fault Management Signal (FMS) sub-TLV MAY be included if the FMS 644 OAM Function flag is set. If the Fault Management Signal sub-TLV 645 is not included, the default configuration values are used. 647 4.2.1. BFD Configuration sub-TLV 649 The BFD Configuration Sub-TLV (depicted below) is defined for BFD- 650 OAM-specific configuration parameters. The BFD Configuration Sub-TLV 651 is carried as a sub-TLV of the PW OAM Functions TLV. 653 This sub-TLV accommodates generic BFD OAM information and carries 654 sub- TLVs. 656 0 1 2 3 657 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 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | BFD Conf. Type (1) | Length | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 |Vers.|N|S|I|G|U|B| Reserved (set to all 0s) | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | | 664 ~ sub-TLVs ~ 665 | | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 BFD Configuration sub-TLV 670 Type: indicates a new type, the BFD Configuration Sub-TLV (suggested 671 value 1). 673 Length: Indicates the length of the Value field in octets. 675 Version: Identifies the BFD protocol version. If the egress LSR does 676 not support the version, a Notification message MUST be generated, 677 with the Status Code set to "OAM Problem/ Unsupported BFD Version". 679 BFD Negotiation (N): If set, timer negotiation/re-negotiation via BFD 680 Control messages is enabled. When cleared, it is disabled. 682 Symmetric Session (S): If set, the BFD session MUST use symmetric 683 timing values. 685 Integrity (I): If set, BFD Authentication MUST be enabled. If the 686 BFD Configuration Sub-TLV does not include a BFD Authentication Sub- 687 TLV, the authentication MUST use Keyed SHA1 with an empty pre-shared 688 key (all 0s). If the egress LSR does not support BFD Authentication, 689 an Notification message MUST be generated, with Status Code set to 690 "OAM Problem/BFD Authentication unsupported". 692 Encapsulation Capability (G): If set, it shows the capability of 693 encapsulating BFD messages into The G-Ach channel. If both the G bit 694 and U bit are set, configuration gives precedence to the G bit. If 695 the egress LSR does not support any of the ingress LSR Encapsulation 696 Capabilities, an Notification message MUST be generated, with the 697 Status Code set to "OAM Problem/Unsupported BFD Encapsulation 698 format". 700 Encapsulation Capability (U): If set, it shows the capability of 701 encapsulating BFD messages into UDP packets. If both the G bit and U 702 bit are set, configuration gives precedence to the G bit. If the 703 egress LSR does not support any of the ingress LSR Encapsulation 704 Capabilities, a Notification message MUST be generated, with the 705 Status Code set to "OAM Problem/Unsupported BFD Encapsulation 706 Format". 708 Bidirectional (B): If set, it configures BFD in the Bidirectional 709 mode. If it is not set, it configures BFD in unidirectional mode. 710 In the second case, the source node does not expect any Discriminator 711 values back from the destination node. 713 Reserved: Reserved for future specifications; set to 0 on 714 transmission and ignored when received. 716 The BFD Configuration Sub-TLV MUST include the following sub-TLVs in 717 the Label Mapping message: 719 o BFD Identifiers Sub-TLV; and 721 o Negotiation Timer Parameters Sub-TLV if the N flag is cleared. 723 The BFD Configuration Sub-TLV MUST include the following sub-TLVs in 724 the "response" Label Mapping message: 726 o BFD Identifiers Sub-TLV; and 728 o Negotiation Timer Parameters Sub-TLV if: 730 * the N and S flags are cleared; or if 732 * the N flag is cleared and the S flag is set and the Negotiation 733 Timer Parameters Sub-TLV received by the egress contains 734 unsupported values. In this case, an updated Negotiation Timer 735 Parameters Sub-TLV containing values supported by the egress 736 LSR MUST be returned to the ingress. 738 4.2.1.1. Local Discriminator sub-TLV 740 The Local Discriminator sub-TLV is carried as a sub-TLV of the BFD 741 Configuration sub-TLV and is depicted below. 743 0 1 2 3 744 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 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Lcl. Discr. Type (1) (IANA) | Length (4) | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Local Discriminator | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 Local Discriminator sub-TLV 753 Type: indicates a new type, the Local Discriminator sub-TLV 754 (suggested value 1). 756 Length: indicates the length of the Value field in octets (4). 758 Local Discriminator: A unique, nonzero discriminator value generated 759 by the transmitting system and referring to itself, used to 760 demultiplex multiple BFD sessions between the same pair of systems. 762 4.2.1.2. Negotiation Timer Parameters sub-TLV 764 The Negotiation Timer Parameters sub-TLV is carried as a sub-TLV of 765 the BFD Configuration sub-TLV and is depicted below. 767 0 1 2 3 768 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 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Timer Neg. Type (2) (IANA) | Length (16) | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Acceptable Min. Asynchronous TX interval | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | Acceptable Min. Asynchronous RX interval | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | Required Echo TX Interval | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 Negotiation Timer Parameters sub-TLV 781 Type: indicates a new type, the Negotiation Timer Parameters sub-TLV 782 (suggested value 2). 784 Length: indicates the length of the Value field in octets (12). 786 Acceptable Min. Asynchronous TX interval: in case of S (symmetric) 787 flag set in the BFD Configuration sub-TLV, defined in Section 4.2.1, 788 it expresses the desired time interval (in microseconds) at which the 789 ingress PE intends to both transmit and receive BFD periodic control 790 packets. If the receiving PE cannot support such value, it SHOULD 791 reply with an interval greater than the one proposed. 793 In case of S (symmetric) flag cleared in the BFD Configuration sub- 794 TLV, this field expresses the desired time interval (in microseconds) 795 at which T-PE intends to transmit BFD periodic control packets in its 796 transmitting direction. 798 Acceptable Min. Asynchronous RX interval: in case of S (symmetric) 799 flag set in the BFD Configuration sub-TLV, this field MUST be equal 800 to Acceptable Min. Asynchronous TX interval and has no additional 801 meaning respect to the one described for "Acceptable Min. 802 Asynchronous TX interval". 804 In case of S (symmetric) flag cleared in the BFD Configuration sub- 805 TLV, it expresses the minimum time interval (in microseconds) at 806 which T-PEs can receive BFD periodic control packets. In case this 807 value is greater than the value of Acceptable Min. Asynchronous TX 808 interval received from the other edge LSR, such T-PE MUST adopt the 809 interval expressed in this Acceptable Min. Asynchronous RX interval. 811 Required Echo TX Interval: the minimum interval (in microseconds) 812 between received BFD Echo packets that this system is capable of 813 supporting, less any jitter applied by the sender as described in 814 [RFC5880] sect. 6.8.9. This value is also an indication for the 815 receiving system of the minimum interval between transmitted BFD Echo 816 packets. If this value is zero, the transmitting system does not 817 support the receipt of BFD Echo packets. If the receiving system 818 cannot support this value, a Notification message MUST be generated, 819 with the Status Code set to "Unsupported BFD TX Echo rate interval". 820 By default the value is set to 0. 822 4.2.1.3. BFD Authentication sub-TLV 824 The BFD Authentication sub-TLV is carried as a sub-TLV of the BFD 825 Configuration sub-TLV and is depicted below. 827 0 1 2 3 828 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 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | BFD Auth. Type (3) (IANA) | Length = 8 | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | Auth Type | Auth Key ID | Reserved (0s) | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 BFD Authentication sub-TLV 837 Type: indicates a new type, the BFD Authentication sub-TLV (suggested 838 value 3). 840 Length: indicates the length of the Value field in octets (4). 842 Auth Type: indicates which type of authentication to use. The same 843 values as are defined in section 4.1 of [RFC5880] are used. If the 844 egress PE does not support this type, an Notification message MUST be 845 generated, with the Status Code set to "OAM Problem/Unsupported BFD 846 Authentication Type". 848 Auth Key ID: indicates which authentication key or password 849 (depending on Auth Type) should be used. How the key exchange is 850 performed is out of scope of this document. If the egress PE does 851 not support this Auth Key ID, a Notification message MUST be 852 generated, with the Status Code set to "OAM Problem/Mismatch of BFD 853 Authentication Key ID". 855 Reserved: Reserved for future specification and set to 0 on 856 transmission and ignored when received. 858 4.2.1.4. Traffic Class Sub-TLV 860 The Traffic Class sub-TLV is carried as a sub-TLV of the BFD 861 Configuration sub-TLV or Fault Management Signal sub-TLV 862 (Section 4.2.3) and is depicted as below. 864 0 1 2 3 865 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 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | Traffic Class sub-Type (104) | Length | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | TC | Reserved (set to all 0s) | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 Type: indicates a new type, the Traffic Class sub-TLV (suggested 873 value 4). 875 Length: Indicates the length of the Value field in octets (4). 877 Traffic Class (TC): Identifies the TC [RFC5462] for periodic 878 continuity monitoring messages or packets with fault management 879 information. If the Traffic Class sub-TLV is present, then the value 880 of the TC field MUST be used as the value of the TC field of an MPLS 881 label stack entry. If the Traffic Class sub-TLV is absent from BFD 882 Configuration sub-TLV or Fault Management Signal sub-TLV, then 883 selection of the TC value is a local decision. 885 4.2.2. Performance Monitoring sub-TLV 887 If the PW OAM Functions TLV has either the L (Loss), D (Delay) or T 888 (Throughput) flag set, the Performance Measurement sub-TLV MUST be 889 present. Failure to include the correct sub-TLVs MUST result in a 890 Notification message (with the Status Code set to "OAM Problem/ 891 Configuration Error") being generated. The Performance Measurement 892 sub-TLV provides the configuration information mentioned in Section 7 893 of [RFC6374]. It includes support for the configuration of quality 894 thresholds and, as described in [RFC6374], "the crossing of which 895 will trigger warnings or alarms, and result reporting and exception 896 notification will be integrated into the system-wide network 897 management and reporting framework." In case the values need to be 898 different than the default ones the Performance Measurement sub-TLV 899 MAY include the following sub-TLVs: 901 o "MPLS-PW PM Loss sub-TLV" if the L flag is set in the "PW OAM 902 Functions TLV"; 904 o "MPLS-PW PM Delay sub-TLV" if the D flag is set in the "PW OAM 905 Functions TLV ". 907 The "Performance Monitoring sub-TLV" depicted below is carried as a 908 sub-TLV of the "PW OAM Functions TLV" 910 0 1 2 3 911 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 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | Perf Monitoring Type (IANA)| Length | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 |D|L|J|Y|K|C| Reserved (set to all 0s) | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | | 918 ~ sub-TLVs ~ 919 | | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 Performance Monitoring sub-TLV 924 Sub-type: indicates a new sub-type, the Performance Management sub- 925 TLV (suggested value 2). 927 Length: indicates the length of the Value field in octets (4). 928 Configuration Flags, for the specific function description please 929 refer to [RFC6374]: 931 o D: Delay inferred/direct (0=INFERRED, 1=DIRECT). If the egress 932 LSR does not support specified mode, a Notification message MUST 933 be generated, with the Status Code set to "OAM Problem/Unsupported 934 Delay Mode". 936 o L: Loss inferred/direct (0=INFERRED, 1=DIRECT). If the egress LSR 937 does not support specified mode, a Notification message MUST be 938 generated, with the Status Code set to "OAM Problem/Unsupported 939 Loss Mode". 941 o J: Delay variation/jitter (1=ACTIVE, 0=NOT ACTIVE). If the egress 942 LSR does not support Delay variation measurements and the J flag 943 is set, a Notification message MUST be generated, with the Status 944 Code set to "OAM Problem/Delay variation unsupported". 946 o Y: Dyadic (1=ACTIVE, 0=NOT ACTIVE). If the egress LSR does not 947 support Dyadic mode and the Y flag is set, a Notification message 948 MUST be generated, with the Status Code set to "OAM Problem/Dyadic 949 mode unsupported". 951 o K: Loopback (1=ACTIVE, 0=NOT ACTIVE). If the egress LSR does not 952 support Loopback mode and the K flag is set, a Notification 953 message MUST be generated, with the Status Code set to "OAM 954 Problem/ Loopback mode unsupported". 956 o C: Combined (1=ACTIVE, 0=NOT ACTIVE). If the egress LSR does not 957 support Combined mode and the C flag is set, a Notification 958 message MUST be generated, with the Status Code set to "OAM 959 Problem/ Combined mode unsupported". 961 Reserved: Reserved for future specification and set to 0 on 962 transmission and ignored when received. 964 4.2.2.1. PM Loss Sub-TLV 966 The PM Loss sub-TLV depicted below is carried as a sub-TLV of the 967 Performance Monitoring sub-TLV. 969 0 1 2 3 970 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 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | PM Loss Type (1) (IANA) | Length | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | OTF |T|B| RESERVED | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | Measurement Interval | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | Test Interval | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | Loss Threshold | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 PM Loss sub-TLV 985 Type: indicates a new type, the PM Loss sub-TLV (suggested value 1). 987 Length: indicates the length of the parameters in octets. 989 OTF: Origin Timestamp Format of the Origin Timestamp field described 990 in [RFC6374]. By default it is set to IEEE 1588 version 1. If the 991 egress PE cannot support this value, a Notification message MUST be 992 generated, with the Status Code set to "OAM Problem/Unsupported 993 Timestamp Format". 995 Configuration Flags, please refer to [RFC6374] for further details: 997 o T: Traffic-class-specific measurement indicator. Set to 1 when 998 the measurement operation is scoped to packets of a particular 999 traffic class (DSCP value), and 0 otherwise. When set to 1, the 1000 DS field of the message indicates the measured traffic class. By 1001 default it is set to 1. 1003 o B: Octet (byte) count. When set to 1, indicates that the Counter 1004 1-4 fields represent octet counts. When set to 0, indicates that 1005 the Counter 1-4 fields represent packet counts. By default it is 1006 set to 0. 1008 Measurement Interval: the time interval (in microseconds) at which LM 1009 query messages MUST be sent on both directions. If the T-PE 1010 receiving the Mapping message can not support such value, it can 1011 reply back with a higher interval. By default it is set to (100) as 1012 per [RFC6375].. 1014 Test Interval: test messages interval as described in [RFC6374]. By 1015 default it is set to (10) as per [RFC6375]. 1017 Loss Threshold: the threshold value of measured lost packets per 1018 measurement over which action(s) SHOULD be triggered. 1020 4.2.2.2. PM Delay Sub-TLV 1022 The PM Delay sub-TLV depicted below is carried as a sub-TLV of the PW 1023 OAM Functions TLV. 1025 0 1 2 3 1026 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 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | PM Delay Type (2) (IANA) | Length | 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 | OTF |T|B| RESERVED | 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 | Measurement Interval | 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | Test Interval | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Delay Threshold | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 PM Delay sub-TLV 1041 Type: indicates a new type, the PM Delay sub-TLV (suggested value 2). 1043 Length: indicates the length of the parameters in octets. 1045 OTF: Origin Timestamp Format of the Origin Timestamp field described 1046 in [RFC6374]. By default it is set to IEEE 1588 version 1. If the 1047 egress LSR cannot support this value, a Notification message MUST be 1048 generated, with the Status Code set to "OAM Problem/Unsupported 1049 Timestamp Format". 1051 Configuration Flags, please refer to [RFC6374] for further details: 1053 o T: Traffic-class-specific measurement indicator. Set to 1 when 1054 the measurement operation is scoped to packets of a particular 1055 traffic class (DSCP value), and 0 otherwise. When set to 1, the 1056 DS field of the message indicates the measured traffic class. By 1057 default it is set to 1. 1059 o B: Octet (byte) count. When set to 1, indicates that the Counter 1060 1-4 fields represent octet counts. When set to 0, indicates that 1061 the Counter 1-4 fields represent packet counts. By default it is 1062 set to 0. 1064 Measurement Interval: the time interval (in microseconds) at which LM 1065 query messages MUST be sent on both directions. If the T-PE 1066 receiving the Mapping message can not support such value, it can 1067 reply back with a higher interval. By default it is set to (1000) as 1068 per [RFC6375]. 1070 Test Interval: test messages interval as described in [RFC6374]. By 1071 default it is set to (10) as per [RFC6375]. 1073 Delay Threshold: the threshold value of measured two-way delay (in 1074 milliseconds) over which action(s) SHOULD be triggered. 1076 4.2.3. Fault Management Signal Sub-TLV 1078 The Fault Management Signal sub-TLV depicted below is carried as a 1079 sub-TLV of the PW OAM Functions TLV. When both working and 1080 protection paths are configured, both PWs SHOULD be configured with 1081 identical settings of the E flag, T flag, and the refresh timer. 1083 0 1 2 3 1084 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 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 | FMS sub-type (300) | Length | 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 |E|S|T| Reserved | Refresh Timer | 1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 | | 1091 ~ sub-TLVs ~ 1092 | | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 Fault Management Signal sub-TLV 1097 Type: indicates a new type, the Fault Management Signal sub-TLV 1098 (suggested value 4). 1100 Length: indicates the length of the parameters in octets (8). 1102 FMS Signal Flags are used to enable the FMS signals at end point MEPs 1103 and the Server MEPs of the links over which the PW is forwarded. In 1104 this document only the S flag pertains to Server MEPs. 1106 The following flags are defined: 1108 o E: Enable Alarm Indication Signal (AIS) and Lock Report (LKR) 1109 signaling as described in [RFC6427]. Default value is 1 1110 (enabled). If the egress MEP does not support FMS signal 1111 generation, a Notification message MUST be generated, with the 1112 Status Code set to "OAM Problem/Fault management signaling 1113 unsupported". 1115 o S: Indicate to a server MEP that it should transmit AIS and LKR 1116 signals on the client PW. Default value is 0 (disabled). If a 1117 Server MEP which is capable of generating FMS messages is for some 1118 reason unable to do so for the PW being signaled, a Notification 1119 message MUST be generated, with the Status Code set to "OAM 1120 Problem/ Unable to create fault management association". 1122 o T: Set timer value, enabled the configuration of a specific timer 1123 value. Default value is 0 (disabled). 1125 o Remaining bits: Reserved for future specification and set to 0. 1127 Refresh Timer: indicates the refresh timer of fault indication 1128 messages, in seconds. The value MUST be between 1 to 20 seconds as 1129 specified for the Refresh Timer field in [RFC6427]. If the egress PE 1130 receiving the Label Mapping message cannot support the value it 1131 SHOULD reply with a higher timer value. 1133 Fault Management Signal sub-TLV MAY include Traffic Class sub-TLV 1134 (Section 4.2.1.4). If TC sub-TLV is present, the value of the TC 1135 field MUST be used as the value of the TC field of a PW label stack 1136 entry for FMS messages. If the TC sub-TLV is absent, then selection 1137 of the TC value is local decision. 1139 5. IANA Considerations 1141 5.1. TLVs 1143 IANA is requested to assign two new TLV types from the registry "TLV 1144 Type Name Space" in the "Label Distribution Protocol (LDP) 1145 Parameters" registry. 1147 Value TLV References 1148 ----- -------- ---------- 1149 TBD1 PW OAM Administration TLV this document 1150 TBD2 PW OAM Functions TLV this document 1152 The sub-TLV space and assignments for the PW OAM Functions TLV will 1153 be the same as that for the MPLS OAM Functions TLV. Sub-types for 1154 the MPLS OAM Functions TLV and the PW OAM Functions TLV MUST be kept 1155 the same. Any new sub-type added to the MPLS OAM Functions TLV MUST 1156 apply to the PW OAM Functions TLV as well. 1158 5.1.1. PW OAM Configuration Sub-TLV 1160 IANA is requested to create a registry of "Pseudowire OAM 1161 Configuration Sub-TLV types". These are 16 bit values. Sub-TLV 1162 types 1 through 8 are specified in this document. Sub-TLV types 0 1163 and 65535 are reserved. Sub-TLV 9 through 65534 are to be assigned 1164 by IANA, using the "Expert Review" policy defined in [RFC5226]. 1166 Value Sub-TLV References 1167 ----- -------- ---------- 1168 1 BFD Configuration sub-TLV this document 1169 2 Performance Monitoring sub-TLV this document 1170 3 Fault Management Signal sub-TLV this document 1172 5.1.1.1. BFD Configuration sub-TLVs 1174 IANA is requested to create a registry of "Pseudowire OAM BFD 1175 Configuration Sub-TLV types". These are 16 bit values. Sub-TLV 1176 types 1 through 3 are specified in this document. Sub-TLV types 0 1177 and 65535 are reserved. Sub-TLV 4 through 65534 are to be assigned 1178 by IANA, using the "Expert Review" policy defined in [RFC5226]. 1180 Value Sub-TLV References 1181 ----- -------- ---------- 1182 1 Local Discriminator sub-TLV this document 1183 2 Negotiation Timer Parameters sub-TLV this document 1184 3 BFD Authentication sub-TLV this document 1185 4 Traffic Class Sub-TLV this document 1187 5.1.1.2. Performance Monitoring sub-TLVs 1189 IANA is requested to create a registry of "Pseudowire OAM Performance 1190 Monitoring Sub-TLV types". These are 16 bit values. Sub-TLV types 1 1191 through 2 are specified in this document. Sub-TLV types 0 and 65535 1192 are reserved. Sub-TLV 3 through 65534 are to be assigned by IANA, 1193 using the "Expert Review" policy defined in [RFC5226]. 1195 Value Sub-TLV References 1196 ----- -------- ---------- 1197 1 PM Loss TLV this document 1198 2 PM Delay TLV this document 1200 5.2. OAM Configuration Status Code 1202 IANA is requested to assign the following LDP status codes from the 1203 registry "STATUS CODE NAME SPACE" in the "Label Distribution Protocol 1204 (LDP) Parameters" registry. 1206 Range/Value E Description Reference 1207 ----------- ----- ------------------------------------- ------------- 1208 TBD3 0 "PW OAM Alarms Enabled" This document 1209 TBD4 0 "PW OAM Alarms Disabled" This document 1210 TBD5 0 "PW MEP Configuration Failed" This document 1211 TBD6 0 "PW MEP Configuration Succeed" This document 1212 TBD7 0 "PW MEP Entities Disabled" This document 1213 TBD8 0 "PW MIP Configuration Failed" This document 1214 TBD9 0 "PW OAM Parameters Rejected" This document 1215 TBD10 0 "OAM Problem/Unsupported BFD This document 1216 Version" 1217 TBD11 0 "OAM Problem/Unsupported BFD This document 1218 Encapsulation format" 1219 TBD12 0 "OAM Problem/Unsupported BFD This document 1220 Authentication Type" 1221 TBD13 0 "OAM Problem/Mismatch of BFD This document 1222 Authentication Key ID 1223 TBD14 0 "OAM Problem/Unsupported Timestamp This document 1224 Format" 1225 TBD15 0 "OAM Problem/Unsupported Delay This document 1226 Mode" 1227 TBD16 0 "OAM Problem/Unsupported Loss Mode" This document 1228 TBD17 0 "OAM Problem/Delay variation This document 1229 unsupported" 1230 TBD18 0 "OAM Problem/Dyadic mode This document 1231 unsupported" 1232 TBD19 0 "OAM Problem/Loopback mode This document 1233 unsupported" 1234 TBD20 0 "OAM Problem/Combined mode This document 1235 unsupported" 1236 TBD21 0 "OAM Problem/Fault management This document 1237 signaling unsupported" 1238 TBD22 0 "OAM Problem/Unable to create This document 1239 fault management association" 1241 6. Security Considerations 1243 Security considerations relating to LDP are described in section 5 of 1244 [RFC5036] and section 11 of [RFC5561]. Security considerations 1245 relating to use of LDP in setting up PWs is described in section 8 of 1246 [RFC4447]. 1248 This document defines new TLV/sub-TLV types, and OAM configuration 1249 procedures intended for use with MPLS-TP, which do not raise any 1250 additional security issues. 1252 7. Acknowledgement 1254 The authors would like to thank Andrew Malis, Greg Mirsky, Luca 1255 Martini, Matthew Bocci, Thomas Nadeau for their valuable comments and 1256 discussions, especially would like to thank Eric Gray for his review 1257 of this document. 1259 8. References 1261 8.1. Normative references 1263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1264 Requirement Levels", BCP 14, RFC 2119, March 1997. 1266 [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and 1267 G. Heron, "Pseudowire Setup and Maintenance Using the 1268 Label Distribution Protocol (LDP)", RFC 4447, 1269 DOI 10.17487/RFC4447, April 2006, 1270 . 1272 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 1273 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 1274 October 2007, . 1276 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 1277 Le Roux, "LDP Capabilities", RFC 5561, 1278 DOI 10.17487/RFC5561, July 2009, 1279 . 1281 8.2. Informative References 1283 [I-D.ietf-mpls-lsp-ping-mpls-tp-oam-conf] 1284 Bellagamba, E., Mirsky, G., Andersson, L., Skoldstrom, P., 1285 Ward, D., and J. Drake, "Configuration of Proactive 1286 Operations, Administration, and Maintenance (OAM) 1287 Functions for MPLS-based Transport Networks using LSP 1288 Ping", draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-09 (work 1289 in progress), January 2015. 1291 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 1292 Edge-to-Edge (PWE3) Architecture", RFC 3985, 1293 DOI 10.17487/RFC3985, March 2005, 1294 . 1296 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 1297 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1298 DOI 10.17487/RFC4379, February 2006, 1299 . 1301 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1302 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1303 DOI 10.17487/RFC5226, May 2008, 1304 . 1306 [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering 1307 Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291, 1308 August 2008, . 1310 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 1311 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 1312 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 1313 2009, . 1315 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 1316 Sprecher, N., and S. Ueno, "Requirements of an MPLS 1317 Transport Profile", RFC 5654, DOI 10.17487/RFC5654, 1318 September 2009, . 1320 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 1321 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 1322 DOI 10.17487/RFC5659, October 2009, 1323 . 1325 [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., 1326 "Requirements for Operations, Administration, and 1327 Maintenance (OAM) in MPLS Transport Networks", RFC 5860, 1328 DOI 10.17487/RFC5860, May 2010, 1329 . 1331 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1332 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 1333 . 1335 [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, 1336 Administration, and Maintenance Framework for MPLS-Based 1337 Transport Networks", RFC 6371, DOI 10.17487/RFC6371, 1338 September 2011, . 1340 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 1341 Measurement for MPLS Networks", RFC 6374, 1342 DOI 10.17487/RFC6374, September 2011, 1343 . 1345 [RFC6375] Frost, D., Ed. and S. Bryant, Ed., "A Packet Loss and 1346 Delay Measurement Profile for MPLS-Based Transport 1347 Networks", RFC 6375, DOI 10.17487/RFC6375, September 2011, 1348 . 1350 [RFC6427] Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed., 1351 Boutros, S., and D. Ward, "MPLS Fault Management 1352 Operations, Administration, and Maintenance (OAM)", 1353 RFC 6427, DOI 10.17487/RFC6427, November 2011, 1354 . 1356 [RFC7260] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE 1357 Extensions for Operations, Administration, and Maintenance 1358 (OAM) Configuration", RFC 7260, DOI 10.17487/RFC7260, June 1359 2014, . 1361 [RFC7487] Bellagamba, E., Takacs, A., Mirsky, G., Andersson, L., 1362 Skoldstrom, P., and D. Ward, "Configuration of Proactive 1363 Operations, Administration, and Maintenance (OAM) 1364 Functions for MPLS-Based Transport Networks Using RSVP- 1365 TE", RFC 7487, DOI 10.17487/RFC7487, March 2015, 1366 . 1368 Authors' Addresses 1370 Fei Zhang (editor) 1371 Huawei 1373 Email: zhangfei7@huawei.com 1375 Bo Wu (editor) 1376 ZTE Corporation 1378 Email: wu.bo@zte.com.cn 1380 Elisa Bellagamba (editor) 1381 Ericsson 1382 Farogatan 6 1383 Kista, 164 40 1384 Sweden 1386 Phone: +46 761440785 1387 Email: elisa.bellagamba@ericsson.com 1389 Mach(Guoyi) Chen (editor) 1390 Huawei 1392 Email: mach.chen@huawei.com