idnits 2.17.1 draft-ietf-pwe3-mpls-tp-oam-config-00.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 (January 29, 2012) is 4468 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-03 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-tp-oam-analysis-07 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PWE3 Working Group F. Zhang, Ed. 3 Internet-Draft B. Wu, Ed. 4 Intended status: Standards Track ZTE Corporation 5 Expires: August 1, 2012 E. Bellagamba, Ed. 6 Ericsson 7 January 29, 2012 9 Label Distribution Protocol Extensions for Proactive Operations, 10 Administration and Maintenance Configuration of Dynamic MPLS Transport 11 Profile PseudoWire 12 draft-ietf-pwe3-mpls-tp-oam-config-00 14 Abstract 16 This document specifies extensions to the Label Distribution Protocol 17 (LDP) to configure and control proactive Operations, Adminstration 18 and Maintenance (OAM) functions, suitable for dynamic Single-Segment 19 PseudoWire (SS-PW) and Multi-Segment PseudoWire (MS-PW). 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 August 1, 2012. 38 Copyright Notice 40 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Conventions used in this document . . . . . . . . . . . . . . 4 57 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Analysis of Existing PW OAM Configuration . . . . . . . . . . 5 59 3.1. Virtual Circuit Connectivity Verification . . . . . . . . 6 60 3.2. VCCV Bidirectional Forwarding Detection . . . . . . . . . 6 61 3.3. PW Status . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4. Analysis of PW OAM Configuration Extended by MPLS-TP . . . . . 7 64 4.1. Continuity Check, Connectivity Verification and Remote 65 Defect Indication . . . . . . . . . . . . . . . . . . . . 7 66 4.2. Performance Monitoring Loss/Delay . . . . . . . . . . . . 8 67 4.3. FMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.4. On-demand OAM Functions . . . . . . . . . . . . . . . . . 8 69 4.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5. MPLS-TP PW OAM Capability Advertisement . . . . . . . . . . . 10 71 6. PW OAM Configuration Procedures . . . . . . . . . . . . . . . 10 72 6.1. OAM Configuration for MS-PW . . . . . . . . . . . . . . . 10 73 6.1.1. Establishment of OAM Entities and Functions . . . . . 10 74 6.1.2. Adjustment of OAM Parameters . . . . . . . . . . . . . 12 75 6.1.3. Deleting OAM Entities . . . . . . . . . . . . . . . . 12 76 6.2. OAM Configuration for SS-PW . . . . . . . . . . . . . . . 13 77 7. LDP extensions . . . . . . . . . . . . . . . . . . . . . . . . 13 78 7.1. MPLS-TP PW OAM Capability TLV . . . . . . . . . . . . . . 13 79 7.1.1. Backward Compatibility . . . . . . . . . . . . . . . . 14 80 7.2. MPLS-TP PW OAM Administration TLV . . . . . . . . . . . . 15 81 7.3. MPLS-TP PW OAM Configuration TLV . . . . . . . . . . . . . 15 82 7.3.1. BFD Configuration sub-TLV . . . . . . . . . . . . . . 17 83 7.3.1.1. Local Discriminator sub-TLV . . . . . . . . . . . 18 84 7.3.1.2. Negotiation Timer Parameters sub-TLV . . . . . . . 18 85 7.3.1.3. BFD Authentication sub-TLV . . . . . . . . . . . . 20 86 7.3.2. Performance Monitoring sub-TLV . . . . . . . . . . . . 20 87 7.3.2.1. MPLS-TP PW PM Loss TLV . . . . . . . . . . . . . . 21 88 7.3.2.2. MPLS-TP PW PM Delay TLV . . . . . . . . . . . . . 22 89 7.3.3. MPLS-TP PW FMS TLV . . . . . . . . . . . . . . . . . . 23 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 91 8.1. OAM Configuration Errors . . . . . . . . . . . . . . . . . 24 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 93 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 25 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 95 11.1. Normative references . . . . . . . . . . . . . . . . . . . 25 96 11.2. Informative References . . . . . . . . . . . . . . . . . . 26 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 99 1. Introduction 101 MPLS Pseudowire (PW) is defined in [RFC3985] and [RFC5659], which 102 provide for emulated services over an MPLS Packet Switched Network 103 (PSN). MPLS Transport Profile (MPLS-TP) describes a profile of MPLS 104 that enables operational models typical in transport networks, while 105 providing additional Operations, Administration and Maintenance 106 (OAM), survivability and other maintenance functions not previously 107 supported by IP/MPLS. The corresponding requirements are defined in 108 [RFC5860]. 110 The MPLS-TP OAM mechanisms that are operated to meet transport 111 requirements are described in [RFC6371], categorized into proactive 112 and on-demand monitoring. Proactive monitoring refers to OAM 113 operations that are either configured to be carried out periodically 114 and continuously or preconfigured to act on certain events such as 115 alarm signals. In contrast, on-demand monitoring is initiated 116 manually and for a limited amount of time, usually for operations 117 such as diagnostics to investigate into a defect condition. 119 The Network Management System (NMS) or Label Switched Path (LSP) Ping 120 [I-D.ietf-mpls-lsp-ping-mpls-tp-oam-conf] is used to configure these 121 OAM functionalities if a control plane is not instantiated. But if 122 the control plane is used, it MUST support the configuration and 123 modification of OAM maintenance points as well as the activation/ 124 deactivation of OAM when the transport path or transport service is 125 established or modified [RFC5654]. 127 This document specifies the extensions to the LDP protocol to 128 negotiate PW OAM capabilities, configure and bootstrap proactive PW 129 OAM functions, suitable for Point to Point (P2P) SS-PW and MS-PW. 130 The extensions to Point to Multi-Point (P2MP) PW will be studied in 131 the future. 133 2. Conventions used in this document 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 2.1. Acronyms 141 AC: Attachment Circuit 142 AIS: Alarm indication signal 143 BFD: Bidirectional Forwarding Detection 144 CC: Continuity Check 145 CV: Connectivity Verification 146 DM: Delay Measurement 147 FEC: Forwarding Equivalence Class 148 FMS: Fault Management Signal 149 ICMP: Internet Control Message Protocol 150 G-ACh: Generic Associated Channel 151 LDI: Link Down Indication 152 LDP: Label Distribution Protocol 153 LKR: Lock Reporting 154 LM: Loss Measurement 155 LSP: Label Switched Path 156 ME: Maintenance Entity 157 MEG: Maintenance Entity Group 158 MEP: Maintenance Entity Group End Point 159 MIP: Maintenance Entity Group Intermediate Point 160 MPLS-TP: MPLS Transport Profile 161 MS-PW: Multi-Segment PseudoWire 162 NMS: Network Management System 163 OAM: Operations, Adminstration and Maintenance 164 P2MP: Point to Multi-Point 165 PE: Provider Edge 166 PHB: Per-Hop Behavior 167 PM: Performance Monitoring 168 PSN: Packet Switched Network 169 PW: PseudoWire 170 S-PE: Switching Provider Edge 171 SPME: Sub-Path Maintenance Entity 172 SS-PW: Single-Segment Pseudo Wire 173 T-PE: Terminating Provider Edge 174 TLV: Type Length Value 175 VCCV: Virtual Circuit Connectivity Verification 177 3. Analysis of Existing PW OAM Configuration 179 Before MPLS-TP standards, PW OAM functions have been implemented by 180 [RFC5085], [RFC5885], [RFC4447] and [I-D.ietf-pwe3-static-pw-status]. 181 [RFC5085] defines Connectivity Verification (CV) function, which 182 belongs to on-demand PW monitoring. Continuity Check (CC), as well 183 as PW and Attachemnt Circuit (AC) status notification, are defined in 184 [RFC5885]. The documents [RFC4447] and 185 [I-D.ietf-pwe3-static-pw-status] give some other ways of PW/AC status 186 notification. 188 3.1. Virtual Circuit Connectivity Verification 190 Virtual Circuit Connectivity Verification (VCCV) is used to verify 191 and further diagnose PW forwarding path, and the VCCV capabilities 192 negotiation is defined in [RFC5085]. 194 3.2. VCCV Bidirectional Forwarding Detection 196 Four CV types based on Bidirectional Forwarding Detection (BFD) are 197 specified in [RFC5885], which describes the VCCV BFD capabilities 198 negotiation and the procedures of selecting one of them when multiple 199 BFD CV types are advertised. 201 3.3. PW Status 203 PW status codes provide a mechanism to signal the status of PW and AC 204 failure. When PW control plane exists, the PW Status TLV is carried 205 in the initial Label Mapping message and Notification message to 206 signal all PW status messages [RFC4447]. When an event occurs, an 207 update PW status will be sent. 209 3.4. Conclusion 211 In summary, IP/MPLS PW OAM functions and their relationship with LDP/ 212 LSP Ping/NMS are described in table 1. This document will not 213 replace or deprecate these existing functions(e.g., VCCV capability 214 advertisement and PW status negotiation for MPLS networks). 216 |-------------------------------------------------------------------| 217 | | | LDP | LSP Ping | NMS | 218 |-------------------------------------------------------------------| 219 | | VCCV | Capability | | Capability | 220 | | LSP ping | negotiation | |configuration&| 221 | On-demand | | | | Bootstrapping| 222 | OAM |-------------------------------------------------------| 223 | | VCCV | Capability | | Capability | 224 | | ICMP ping | negotiation | |configuration&| 225 | | | | | Bootstrapping| 226 |-------------------------------------------------------------------| 227 | | VCCV BFD | Capability | | Capability | 228 | | | negotiation& | |configuration&| 229 | | | Bootstrapping| | Bootstrapping| 230 | Proactive |-------------------------------------------------------| 231 | OAM | PW status | Capability | | Capability | 232 | | | negotiation& | |configuration&| 233 | | | Bootstrapping| | Bootstrapping| 234 |-------------------------------------------------------------------| 235 Table 1: IP/MPLS PW OAM Functions 237 4. Analysis of PW OAM Configuration Extended by MPLS-TP 239 4.1. Continuity Check, Connectivity Verification and Remote Defect 240 Indication 242 The Proactive CC, CV and Remote Defect Indication (RDI) functions of 243 MPLS-TP are based on the extensions to BFD [RFC6428], which addresses 244 the proactive CV gap that VCCV BFD does not support. The BFD packets 245 can be encapsulated by IP or non-IP in G-ACh, and operate in 246 coordinated or independent mode. 248 Timer negotiation, such as Transmitter (TX)/Receiver (RX) interval 249 can be performed in subsequent BFD control messages [RFC5880] or 250 directly in the LSP ping configuration messages, but it also can be 251 gotten by control plane signaling [RFC6371]. 253 The use of the VCCV control channel provides the context, based on 254 the MPLS-PW label, required to bind and bootstrap the BFD session to 255 a particular PW, so local discriminator values are not exchanged 256 [I-D.ietf-mpls-tp-oam-analysis]. However, in order to identify 257 certain extreme cases of mis-connectivity and fulfill the 258 requirements that the BFD mechanism MUST be the same for LSP, Single 259 Segment Pseudowire (SS-PW), Multi Segment Pseudowire (MS-PW) and 260 Section as well as for Sub-path Maintenance Element (SPME), BFD might 261 still need to use discriminator values to identify the connection 262 being verified at both ends of the PW. The discriminator values can 263 be statically configured, or signaled via LSP Ping or LDP extensions 264 defined in this document. 266 Per-hop Behavior (PHB), which identifies the per-hop behavior of BFD 267 packet, SHOULD be configured as well. This permits the verification 268 of correct operation of Quality of Serivce (QoS) queuing as well as 269 connectivity. 271 When BFD Control packets are transported in the G-ACh they are not 272 protected by any end-to-end checksum, only lower-layers are providing 273 error detection/correction. A single bit error, e.g. a flipped bit 274 in the BFD State field could cause the receiving end to wrongly 275 conclude that the link is down and in turn trigger protection 276 switching. To prevent this from happening the "BFD Configuration 277 sub-TLV" has an Integrity flag that when set enables BFD 278 Authentication using Keyed SHA1 with an empty key (all 0s) [RFC5880]. 279 This would make every BFD Control packet carry an SHA1 hash of itself 280 that can be used to detect errors. 282 If BFD Authentication using a shared key / password is desired (i.e. 283 actual authentication not only error detection) the "BFD 284 Authentication sub-TLV" MUST be included in the "BFD Configuration 285 sub-TLV". The "BFD Authentication sub-TLV" is used to specify which 286 authentication method that should be used and which shared key / 287 password that should be used for this particular session. How the 288 key exchange is performed is out of scope of this document. 290 4.2. Performance Monitoring Loss/Delay 292 Performance monitoring (PM) of PWs, especially for packet Loss 293 Measurement (LM) and packet Delay Measurement (DM), are specified in 294 [RFC6374], [RFC6375]. 296 When configuring Performance monitoring functionalities it can be 297 chosen either the default configuration (by only setting the 298 respective flags in the "MPLS-TP PW OAM Configuration TLV") or a 299 customized configuration (by including the respective MPLS-TP PW PM 300 Loss and/or Delay sub-TLVs). 302 By setting the PM Loss flag in the "MPLS-TP PW OAM Configuration TLV" 303 and including the "MPLS-TP PW PM Loss sub-TLV" one can configure the 304 measurement interval and loss threshold values for triggering 305 protection. 307 Delay measurements are configured by setting PM Delay flag in the 308 "MPLS-TP PW OAM Configuration TLV" and including the "MPLS-TP PW PM 309 Loss sub-TLV" one can configure the measurement interval and the 310 delay threshold values for triggering protection. 312 4.3. FMS 314 Fault Management Signals (FMS) are specified in [RFC6427], with which 315 a server PW can notify client PWs about various fault conditions to 316 suppress alarms or to be used as triggers for actions in the client 317 PWs. The following signals are defined: Alarm Indication Signal 318 (AIS), Link Down Indication (LDI) and Lock Reporting (LKR). 320 For each MEP of each Maintenance Entity Group (MEG), enabling/ 321 disabling the generation of FMS packets, the transmitted period and 322 PHB SHOULD be configured. This can be done independently, and the 323 values of configured parameters can be different, but for easy 324 maintenance, these setting SHOULD be consistent. 326 4.4. On-demand OAM Functions 328 The extended on-demand OAM functions MAY need capability negotiation 329 in the LDP Initialization message [RFC5561]. However, On-demand PW 330 OAM functions are expected to be carried out by directly accessing 331 network nodes via a management interface; hence configuration and 332 control of on-demand PW OAM functions are out-of-scope for this 333 document. 335 4.5. Conclusion 337 According to the analysis above, LDP needs to be extended to 338 negotiate PW OAM capabilities, configure and bootstrap proactive PW 339 OAM functions, such as, CC-CV-RDI, PM Loss/Delay, FMS. In this way, 340 OAM configuration is bound to PW signaling, avoiding two separate 341 management/configuration steps (PW establishment followed by OAM 342 configuration) which would increases delay, processing and more 343 importantly may be prune to mis-configuration errors. 345 Furthermore, LSP ping can be used to configure the proactive PW OAM 346 function extended by MPLS-TP also, suitable for dynamic and static 347 PW. For reference, the following table 2 describes the different 348 scope of different proactive OAM bootstrapping schemes of dynamic PW. 350 |------------------------------------------------------------------| 351 | | | LDP | LSP Ping | NMS | 352 |------------------------------------------------------------------| 353 | | |Capability | | Capability | 354 | | |negotiation& | |configuration&| 355 | | CC/CV/RDI |Function | Function | Function | 356 | | |configuration&|configuration&|configuration&| 357 | | |Bootstrapping |Bootstrapping | Bootstrapping| 358 | |--------------------------------------------------------| 359 |Proactive| |Capability | | Capability | 360 | OAM | |negotiation& | |configuration&| 361 | | FMS |Function | Function | Function | 362 | | |configuration&|configuration&|configuration&| 363 | | |Bootstrapping |Bootstrapping | Bootstrapping| 364 | |--------------------------------------------------------| 365 | | |Capability | | Capability | 366 | | |negotiation& | |configuration&| 367 | | PM Loss/ |Function | Function | Function | 368 | | Delay |configuration&|configuration&|configuration&| 369 | | |Bootstrapping |Bootstrapping | Bootstrapping| 370 |---------|--------------------------------------------------------| 372 Table 2: MPLS-TP PW OAM Functions 374 5. MPLS-TP PW OAM Capability Advertisement 376 When a PW is first set up, the PEs MUST attempt to negotiate the 377 usage of OAM functions. At the time of writing this specification, 378 there are PW status negotiation and VCCV capability advertisement. 379 For the proactive OAM functions extended by MPLS-TP, such as CC-CV- 380 RDI, PM loss/delay and FMS, the capability negotiation MAY be also 381 needed, so a PE that supports the MPLS-TP PW OAM capability MUST 382 include MPLS-TP PW OAM Capability TLV in the LDP Initialization 383 message. And if the peer has not advertised this capability, the 384 corresponding PW OAM configuration information will not be sent to 385 the peer. 387 6. PW OAM Configuration Procedures 389 A PE may play an active or passive role in the signaling of the PW. 390 There exist two situations: 392 a) Active/active: both PEs of a PW are active (SS-PW), they select PW 393 OAM configuration parameters and send with the Label Mapping message 394 to each other independently. 396 b) Active/passive: one PE is active and the others are passive 397 (MS-PW). The active/passive role election is defined in Section 398 7.2.1 of [RFC6073] and applies here, this document does not define 399 any new role election procedures. 401 The general rules of OAM configuration procedures are mostly 402 identical between MS-PW and SS-PW, except that SS-PW does not need to 403 configure MIP function and the Mapping message are sent out 404 independently. Section 6.1 takes MS-PW as an example to describe the 405 general OAM configuration procedures. As for SS-PW, the specific 406 differences would be addressed in section 6.2. 408 6.1. OAM Configuration for MS-PW 410 6.1.1. Establishment of OAM Entities and Functions 412 Assuming there is one PW that needs to be setup between T-PE1 and 413 T-PE2, across S-PE1 and S-PE2. OAM functions must be setup and 414 enabled in the appropriate order so that spurious alarms can be 415 avoided. 417 +-------+ +-------+ +-------+ +-------+ 418 | | | | | | | | 419 | A|--------|B C|--------|D E|--------|F | 420 | | | | | | | | 421 +-------+ +-------+ +-------+ +-------+ 422 T-PE1 S-PE1 S-PE2 T-PE2 424 Figure 1: MS-PW OAM Configuration Scheme 426 Fist of all, T-PE1 MUST setup the OAM sink function to be prepared to 427 receive OAM messages but MUST suppress any OAM alarms (e.g., due to 428 missing or unidentified OAM messages). The Mapping message MUST be 429 sent with the "OAM Alarms Enabled" cleared and "OAM MIP Entities 430 desired" set in the MPLS-TP PW OAM Administation TLV. 432 When the Mapping message arrives at the downstream S-PEs, such as 433 S-PE1 and S-PE2, they MUST establish and configure MIP entities 434 according to the set "I"flag in the MPLS-TP PW OAM Administration 435 TLV. If failure, a Notification message SHOULD be sent, with a 436 Status Code set to "MIP Configuration Failure". If OAM entities are 437 established successfully, the middle points (S-PE1 and S-PE2) MUST 438 forward the Mapping message downstream, the endpoint (T-PE2) MUST set 439 the OAM Source function and MUST be prepared to Send OAM messages. 441 The same rules are applied to the reverse direction (from T-PE2 to 442 T-PE1), that is to say, T-PE2 needs to setup the OAM sink function to 443 be prepared to receive OAM messages but MUST suppress any OAM alarms 444 (e.g., due to missing or unidentified OAM messages). The Mapping 445 message MUST be sent with the "OAM Alarms Enabled" cleared, "OAM MIP 446 Entities desired" set in the MPLS-TP PW OAM Administration TLV. When 447 T-PE1 receives the Mapping message, it completes any pending OAM 448 configuration and enables the OAM source function to send OAM 449 messages. 451 After this round, OAM entities are established and configured for the 452 PW and OAM messages MAY already be exchanged, and OAM alarms can now 453 be enabled. The T-PE nodes (T-PE1 and T-PE2), while still keeping 454 OAM alarms disabled send a Notification message with "OAM Alarms 455 Enabled" PW status flag set, and enable the OAM alarms after 456 processing the Notification message. At this point, data-plane OAM 457 is fully functional, and the MPLS-TP OAM PW configuration TLV MAY be 458 omitted in subsequent Notification messages 460 The PW MAY be setup with OAM entities right away with the first 461 signaling, as described above, but a PW MAY be signaled and 462 established without OAM configuration first, and OAM entities may be 463 added later. This can be done by sending a Notification message with 464 the related configuration parameters subsequently. 466 6.1.2. Adjustment of OAM Parameters 468 There may be a need to change the parameters of an already 469 established and configured OAM function during the lifetime of the 470 PW. To do so the T-PE nodes need to send a Notification message with 471 the updated parameters. OAM parameters that influence the content 472 and timing of OAM messages and identify the way OAM defects and 473 alarms are derived and generated. Hence, to avoid spurious alarms, 474 it is important that both sides, OAM sink and source, are updated in 475 a synchronized way. Firstly, the alarms of the OAM sink function 476 should be suppressed and only then should expected OAM parameters be 477 adjusted. Subsequently, the parameters of the OAM source function 478 can be updated. Finally, the alarms of the OAM sink side can be 479 enabled again. 481 In accordance with the above operation, T-PE1 MUST send a 482 Notification message with "OAM Alarms Enabled" cleared and including 483 the updated MPLS-TP PW OAM Configuration TLV corresponding to the new 484 parameter settings. The initiator (T-PE1) MUST keep its OAM sink and 485 source functions running unmodified, but it MUST suppress OAM alarms 486 after the updated Notification message is sent. The receiver (T-PE2) 487 MUST firstly disable all OAM alarms, then update the OAM parameters 488 according to the information in the Notification message and reply 489 with a Notification message acknowledging the changes by including 490 the MPLS-TP PW OAM Configuration TLV. Note that the receiving side 491 has the possibility to adjust the requested OAM configuration 492 parameters and reply with and updated MPLS-TP PW OAM Configuration 493 TLV in the Notification message, reflecting the actually configured 494 values. However, in order to avoid an extensive negotiation phase, 495 in the case of adjusting already configured OAM functions, the 496 receiving side SHOULD NOT update the parameters requested in the 497 Notification message to an extent that would provide lower 498 performance than what has been configured previously. 500 The initiator (T-PE1) MUST only update its OAM sink and source 501 functions when it has received the Notification message from the 502 peer. After the OAM parameters are updated and OAM is running 503 according the new parameter settings, OAM alarms are still disabled, 504 so a subsequent Notification messages exchanges with "OAM Alarms 505 Enabled" flag set are needed to enable OAM alarms again. 507 6.1.3. Deleting OAM Entities 509 In some cases it may be useful to remove some or all OAM entities and 510 functions from one PW without actually tearing down the connection. 511 To avoid any spurious alarm, the following procedure should be 512 followed: 514 The T-PE nodes disable OAM alarms and SHOULD send Notification 515 message to each other with "OAM Alarms Enabled" cleared but unchanged 516 OAM configuration and without the MPLS-TP PW OAM Configuration TLV. 517 After that, T-PE1 (T-PE2) SHOULD delete OAM source functions, then 518 send a Notification message with "OAM MIP Entities desired" cleared. 519 While T-PE2 (T-PE1) deletes OAM sink function, S-PE1 and S-PE2 delete 520 MIP configuration when they receive the Notification message with 521 "OAM MIP Entities desired" cleared. 523 Alternatively, if only some OAM functions need to be removed, the 524 T-PE node sends the Notification message with the updated OAM 525 Configuration TLV. Changes between the contents of the previously 526 signaled OAM Configuration TLV and the currently received TLV 527 represent which functions SHOULD be removed/added. 529 6.2. OAM Configuration for SS-PW 531 Assuming there is one PW that needs to be setup between T-PE1 and 532 T-PE2. 534 If the receiving PE (T-PE2) have initiated the MPLS-TP PW OAM 535 configuration request to the other PE (T-PE1), it MUST compare its 536 AII against T-PE1's. If it is numerically lower, will reply a 537 Notification message with the updated "MPLS-TP PW OAM Configuration 538 TLV", and the Status Code set to "Wrong MPLS-TP PW OAM Configuration 539 TLV". 541 On the other hand, if the T-PE2's AII is numerically higher than 542 T-PE1's, it MUST reply a Notification message with Status Code set to 543 "Rejected MPLS-TP PW OAM Configuration TLV". 545 7. LDP extensions 547 Below, LDP extensions to configure proactive MPLS-TP PW OAM functions 548 are defined. 550 7.1. MPLS-TP PW OAM Capability TLV 552 A new Capability Parameter TLV called the MPLS-TP PW OAM Capability 553 TLV is defined, and the format is as follows: 555 0 1 2 3 556 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 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 |1|0| Type (TBD) | Length (= 4) | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 |S| Reserved | Capability Data |F|D|L|V|C| 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 MPLS-TP PW OAM Capability TLV 565 The value of the U-bit for the MPLS-TP PW OAM Capability TLV MUST be 566 set to 1 so that a receiver MUST silently ignore this TLV if unknown 567 to it, and continue processing the rest of the message[RFC5036]. 568 Currently defined specific OAM Capability Flags in the "Capability 569 Data" field from right to left are: 571 One bit "C" (31, IANA to assign) CC mode supported 572 One bit "V" (30, IANA to assign) CV mode supported 573 One bit "L" (29, IANA to assign) PM Loss supported 574 One bit "D" (28, IANA to assign) PM Delay supported 575 One bit "F" (27, IANA to assign) FMS supported 576 Bits 8-26: This field MUST be set to zero 577 on transmission and MUST be ignored on receipt. 579 The above bits can be set individually to indicate more than one kind 580 of OAM capabilities at once, and the other reserved bits MUST be set 581 to zero on transmission and MUST be ignored on receipt. Moreover, if 582 CV flag is set, the CC flag MUST be set at the same time. 584 The MPLS-TP PW OAM Capability TLV MAY be included by a PE in an 585 Initialization message to signal its peer that it supports the 586 MPLS-TP PW OAM Capability. If the remote peer does not support the 587 MPLS-TP PW OAM Capability TLV or the Initialization message sent by 588 the remote peer does not include the MPLS-TP PW OAM Capability TLV, 589 the resulting negotiation does not support MPLS-TP PW OAM capability. 590 If instead the negotiation supports the MPLS-TP PW OAM capability, 591 then the subsequent LDP Mapping message will carry the information of 592 the MPLS-TP PW OAM configuration. 594 7.1.1. Backward Compatibility 596 If both the two T-PEs can recognize the MPLS-TP PW OAM Capability 597 TLV,and CC or CV mode is supported, the BFD configuration procedure 598 described in this document is adopted. Otherwise, if at least one of 599 the two T-PEs do not support the CC or CV mode, the old VCCV BFD 600 [RFC5885] will be performed. In this situation, the procedure 601 described in [RFC5885] MUST be followed: the C and V flags of MPLS-TP 602 PW OAM Configuration TLV MUST NOT be set and the BFD Configuration 603 sub-TLV MUST NOT be carried as a sub-TLV of MPLS-TP PW OAM 604 Configuration TLV also. 606 The described behavior ensures full compatibility with the existing 607 implementations. 609 7.2. MPLS-TP PW OAM Administration TLV 611 The format of the MPLS-TP PW OAM Administration TLV is as follows: 613 0 1 2 3 614 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 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 |0|0| Type (TBD) | Length | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 |I|A| Reserved | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 MPLS-TP PW OAM Administration TLV 623 One bit "I" (0, IANA to assign): "OAM MIP Entities Desired" is 624 allocated. If the "OAM MIP entities desired" bit is set, it is 625 indicating that the establishment of OAM MIP entities is required at 626 every transit node of the signaled PW. If the establishment of a MIP 627 is not supported, a Notification message MUST be sent with Status 628 Code set to "MIP Configuration Failure". 630 One bit "A" (1, IANA to assign): "OAM Alarms Enabled" is allocated. 631 If the "OAM Alarms Enabled" bit is set, it is indicating that the 632 T-PE needs to enable OAM alarms. 634 Reserved (2-31 bits): This field MUST be set to zero on transmission 635 and MUST be ignored on receipt. 637 7.3. MPLS-TP PW OAM Configuration TLV 639 The "MPLS-TP PW OAM Configuration TLV" is depicted in the following 640 figure. It may be carried in the Mapping and Notification messages, 641 just following the PW Status TLV. 643 0 1 2 3 644 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 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 |0|0| Type (TBD) | Length | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 |C|V|L|D|F| OAM Function Flags | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | | 651 ~ sub-TLVs ~ 652 | | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 MPLS-TP PW OAM Configuration TLV 657 The "MPLS-TP PW OAM Configuration TLV" contains a number of flags 658 indicating which OAM functions should be activated as well as OAM 659 function specific sub-TLVs with configuration parameters for the 660 particular functions. 662 Type: indicates a new type: the MPLS-TP PW OAM Configuration TLV 663 (IANA to assign). 665 Length: the length of the OAM Function Flags field including the 666 total length of the sub-TLVs in octets. 668 OAM Function Flags: a bitmap numbered from left to right as shown in 669 the figure. 671 These flags are defined in this document: 673 OAM Function Flag bit# Description 674 --------------------- --------------------------- 675 0 (C) Continuity Check (CC) 676 1 (V) Connectivity Verification (CV) 677 2 (L) Performance Monitoring/Loss (PM/Loss) 678 3 (D) Performance Monitoring/Delay (PM/Delay) 679 4 (F) Fault Management Signals (FMS) 680 5-31 Reserved (set all to 0s) 682 Sub-TLVs corresponding to the different flags are as follows. 683 o "BFD Configuration sub-TLV", which MUST be included if the CC 684 and/or the CV OAM Function flag is set. Furthermore, if the CV 685 flag is set, the CC flag MUST be set at the same time. 686 o "Performance Monitoring sub-TLV", which MUST be included if the 687 PM/Loss OAM Function flag is set. 688 o "MPLS-TP PW FMS sub-TLV", which MAY be included if the FMS OAM 689 Function flag is set. If the "MPLS-TP PW FMS sub-TLV" is not 690 included, default configuration values are used. 692 7.3.1. BFD Configuration sub-TLV 694 The "BFD Configuration sub-TLV is defined for BFD specific 695 configuration parameters, which accommodates generic BFD OAM 696 information and carries sub-TLVs. 698 0 1 2 3 699 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 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | BFD Conf. Type (1) (IANA) | Length | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 |Vers.| PHB |N|S|I|G|U|A| Reserved (set to all 0s) | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | | 706 ~ sub TLVs ~ 707 | | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 BFD Configuration sub-TLV 712 Type: indicates a new type, the "BFD Configuration sub-TLV" (IANA to 713 define, suggested value 1). 715 Length: indicates the length of the TLV including sub-TLVs but 716 excluding the Type and Length field, in octets. 718 Version: identifies the BFD protocol version. If a node does not 719 support a specific BFD version, a Notification message MUST be 720 generated with Status Code set to "Unsupported OAM Version". 722 PHB: Identifies the Per-Hop Behavior (PHB) to be used for periodic 723 continuity monitoring messages. 725 BFD Negotiation (N): If set timer negotiation/re-negotiation via BFD 726 Control Messages is enabled, when cleared it is disabled. 728 Symmetric session (S): If set the BFD session MUST use symmetric 729 timing values. 731 Integrity (I): If set BFD Authentication MUST be enabled. If the 732 "BFD Configuration sub-TLV" does not include a "BFD Authentication 733 sub-TLV" the authentication MUST use Keyed SHA1 with an empty pre- 734 shared key (all 0s). 736 Encapsulation Capability (G): if set, it shows the capability of 737 encapsulating BFD messages into G-Ach channel without IP/UDP headers. 738 If both the G bit and U bit are set, configuration gives precedence 739 to the G bit. 741 Encapsulation Capability (U): if set, it shows the capability of 742 encapsulating BFD messages into G-Ach channel with IP/UDP headers. 743 If both the G bit and U bit are set, configuration gives precedence 744 to the G bit. 746 Operation mode (A): if set, it configures BFD in the associated mode. 747 If it is not set it configures BFD in independent mode. 749 Reserved: Reserved for future specification and set to 0. 751 The "BFD Configuration sub-TLV" MUST include the following sub-TLVs 752 in the Mapping message: 753 o "Local Discriminator sub-TLV". 754 o "Negotiation Timer Parameters sub-TLV" if the N flag is cleared. 756 7.3.1.1. Local Discriminator sub-TLV 758 The "Local Discriminator sub-TLV" is carried as a sub-TLV of the "BFD 759 Configuration sub-TLV" and is depicted below. 761 0 1 2 3 762 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 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Lcl. Discr. Type (1) (IANA) | Length (4) | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Local Discriminator | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 Local Discriminator sub-TLV 771 Type: indicates a new type, the "Local Discriminator sub-TLV" (IANA 772 to define, suggested value 1). 774 Length: indicates the TLV total length in octets (4). 776 Local Discriminator: A unique, nonzero discriminator value generated 777 by the transmitting system and referring to itself, used to 778 demultiplex multiple BFD sessions between the same pair of systems. 780 7.3.1.2. Negotiation Timer Parameters sub-TLV 782 The "Negotiation Timer Parameters sub-TLV" is carried as a sub-TLV of 783 the "BFD Configuration sub-TLV" and is depicted below. 785 0 1 2 3 786 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 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | Timer Neg. Type (2) (IANA) | Length (16) | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Acceptable Min. Asynchronous TX interval | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Acceptable Min. Asynchronous RX interval | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Required Echo TX Interval | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 Negotiation Timer Parameters sub-TLV 799 Type: indicates a new type, the "Negotiation Timer Parameters sub- 800 TLV" (IANA to define, suggested value 2). 802 Length: indicates the TLV total length in octets (16). 804 Acceptable Min. Asynchronous TX interval: in case of S (symmetric) 805 flag set in the "BFD Configuration" TLV, it expresses the desired 806 time interval (in microseconds) at which the T-PE initiating the 807 signaling intends to both transmit and receive BFD periodic control 808 packets. If the receiving T-PE can not support such value, it is 809 allowed to reply back with an interval greater than the one proposed. 811 In case of S (symmetric) flag cleared in the "BFD Configuration sub- 812 TLV", this field expresses the desired time interval (in 813 microseconds) at which T-PE intends to transmit BFD periodic control 814 packets in its transmitting direction. 816 Acceptable Min. Asynchronous RX interval: in case of S (symmetric) 817 flag set in the "BFD Configuration sub-TLV", this field MUST be equal 818 to "Acceptable Min. Asynchronous TX interval" and has no additional 819 meaning respect to the one described for "Acceptable Min.Asynchronous 820 TX interval". 822 In case of S (symmetric) flag cleared in the "BFD Configuration sub- 823 TLV", it expresses the minimum time interval (in microseconds) at 824 which T-PE can receive BFD periodic control packets. In case this 825 value is greater than the "Acceptable Min. Asynchronous TX interval" 826 received from the other T-PE, such T-PE MUST adopt the interval 827 expressed in this "Acceptable Min. Asynchronous RX interval". 829 Required Echo TX Interval: the minimum interval (in microseconds) 830 between received BFD Echo packets that this system is capable of 831 supporting, less any jitter applied by the sender as described in 832 [RFC5880] sect. 6.8.9. This value is also an indication for the 833 receiving system of the minimum interval between transmitted BFD Echo 834 packets. If this value is zero, the transmitting system does not 835 support the receipt of BFD Echo packets. If the receiving system can 836 not support this value a Notification MUST be generated with Status 837 Code set to "Unsupported BFD TX Echo rate interval". By default the 838 value is set to 0. 840 7.3.1.3. BFD Authentication sub-TLV 842 The "BFD Authentication sub-TLV" is carried as a sub-TLV of the "BFD 843 Configuration sub-TLV" and is depicted below. 845 0 1 2 3 846 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 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | BFD Auth. Type (3) (IANA) | Length = 8 | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Auth Type | Auth Key ID | Reserved (0s) | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 BFD Authentication sub-TLV 855 Type: indicates a new type, the "BFD Authentication sub-TLV" (IANA to 856 define, suggested value 3). 858 Length: indicates the TLV total length in octets (8). 860 Auth Type: indicates which type of authentication to use. The same 861 values as are defined in section 4.1 of [RFC5880] are used. 863 Auth Key ID: indicates which authentication key or password 864 (depending on Auth Type) should be used. How the key exchange is 865 performed is out of scope of this document. 867 Reserved: Reserved for future specification and set to 0. 869 7.3.2. Performance Monitoring sub-TLV 871 If the "MPLS-TP PW OAM Configuration TLV" has either the L (Loss), D 872 (Delay) flag set, the "Performance Monitoring sub-TLV" MUST be 873 present. 875 In case the values need to be different than the default ones the 876 "MPLS-TP PW PM Loss sub-TLV, "MPLS-TP PW PM Delay sub-TLV" MAY be 877 included: 878 o "MPLS-PW PM Loss sub-TLV" if the L flag is set in the "MPLS-TP PW 879 OAM Configuration TLV"; 881 o "MPLS-PW PM Dealy sub-TLV" if the D flag is set in the "MPLS-TP PW 882 OAM Configuration TLV ". 884 The "Performance Monitoring sub-TLV" depicted below is carried as a 885 sub-TLV of the "MPLS-TP PW OAM Configuration TLV" 887 0 1 2 3 888 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 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Perf Monitoring Type (IANA)| Length | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 |D|L|J|Y|K|C| Reserved (set to all 0s) | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | | 895 ~ sub-TLVs ~ 896 | | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 Performance Monitoring sub-TLV 901 o D: Delay inferred/direct (0=INFERRED, 1=DIRECT) 902 o L: Loss inferred/direct (0=INFERRED, 1=DIRECT) 903 o J: Delay variation/jitter (1=ACTIVE, 0=NOT ACTIVE) 904 o Y: Dyadic (1=ACTIVE, 0=NOT ACTIVE) 905 o K: Loopback (1=ACTIVE, 0=NOT ACTIVE) 906 o C: Combined (1=ACTIVE, 0=NOT ACTIVE) 908 7.3.2.1. MPLS-TP PW PM Loss TLV 910 The "MPLS-TP PW PM Loss sub-TLV" depicted below is carried as a sub- 911 TLV of the "Performance Monitoring sub-TLV". 913 0 1 2 3 914 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 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | PM Loss Type (1) (IANA) | Length | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | OTF |T|B| RESERVED | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Measurement Interval | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | Test Interval | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | Loss Threshold | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 MPLS-TP PW PM Loss sub-TLV 929 Type: indicates a new type, the "MPLS-TP PW PM Loss sub-TLV" (IANA to 930 define, suggested value 1). 932 Length: indicates the length of the parameters in octets. 934 OTF: Origin Timestamp Format of the Origin Timestamp field described 935 in [RFC6374]. By default it is set to IEEE 1588 version 1. 937 Configuration Flags, please refer to [RFC6374] for further details: 938 o T: Traffic-class-specific measurement indicator. Set to 1 when 939 the measurement operation is scoped to packets of a particular 940 traffic class (DSCP value), and 0 otherwise. When set to 1, the 941 DS field of the message indicates the measured traffic class. By 942 default it is set to 1. 943 o B: Octet (byte) count. When set to 1, indicates that the Counter 944 1-4 fields represent octet counts. When set to 0, indicates that 945 the Counter 1-4 fields represent packet counts. By default it is 946 set to 0. 948 Measurement Interval: the time interval (in microseconds) at which LM 949 query messages MUST be sent on both directions. If the T-PE 950 receiving the Mapping message can not support such value, it can 951 reply back with a higher interval. By default it is set to (TBD). 953 Test Interval: test messages interval as described in [RFC6374]. By 954 default it is set to (TBD). 956 Loss Threshold: the threshold value of lost packets over which 957 protections MUST be triggered. By default it is set to (TBD). 959 7.3.2.2. MPLS-TP PW PM Delay TLV 961 The "MPLS-TP PW PM Delay sub-TLV" depicted below is carried as a sub- 962 TLV of the "MPLS-TP PW OAM Configuration TLV" 964 0 1 2 3 965 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 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | PM Delay Type (2) (IANA) | Length | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | OTF |T|B| RESERVED | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | Measurement Interval | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | Test Interval | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | Delay Threshold | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 MPLS-TP PW PM Delay sub-TLV 979 Type: indicates a new type, the "MPLS-TP PW PM Delay sub-TLV" (IANA 980 to define, suggested value 2). 982 Length: indicates the length of the parameters in octets. 984 OTF: Origin Timestamp Format of the Origin Timestamp field described 985 in [RFC6374]. By default it is set to IEEE 1588 version 1. 987 Configuration Flags, please refer to [RFC6374] for further details: 988 o T: Traffic-class-specific measurement indicator. Set to 1 when 989 the measurement operation is scoped to packets of a particular 990 traffic class (DSCP value), and 0 otherwise. When set to 1, the 991 DS field of the message indicates the measured traffic class. By 992 default it is set to 1. 993 o B: Octet (byte) count. When set to 1, indicates that the Counter 994 1-4 fields represent octet counts. When set to 0, indicates that 995 the Counter 1-4 fields represent packet counts. By default it is 996 set to 0. 998 Measurement Interval: the time interval (in microseconds) at which LM 999 query messages MUST be sent on both directions. If the T-PE 1000 receiving the Mapping message can not support such value, it can 1001 reply back with a higher interval. By default it is set to (TBD). 1003 Test Interval: test messages interval as described in [RFC6374]. By 1004 default it is set to (TBD). 1006 Delay Threshold: the threshold value of packet delay time over which 1007 protections MUST be triggered. By default it is set to (TBD). 1009 7.3.3. MPLS-TP PW FMS TLV 1011 The "MPLS-TP PW FMS sub-TLV" depicted below is carried as a sub-TLV 1012 of the "MPLS-TP PW OAM Configuration TLV". 1014 0 1 2 3 1015 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 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | Fault mgmt Type (4) (IANA) | Length (8) | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 |A|D|L| Reserved (set to all 0s) |E| PHB | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | Refresh Timer | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 MPLS-TP PW FMS sub-TLV 1026 Type: indicates a new type, the "MPLS-TP PW FMS sub-TLV" (IANA to 1027 define, suggested value 4). 1029 Length: indicates the length of the parameters in octets (8). 1031 Signal Flags: are used to enable the following signals: 1032 o A: Alarm Indication Signal (AIS) as described in [RFC6427] 1033 o D: Link Down Indication (LDI) as described in [RFC6427] 1034 o L: Locked Report (LKR) as described in [RFC6427] 1035 o Remaining bits: Reserved for future specification and set to 0. 1037 Configuration Flags: 1038 o E: used to enable/disable explicitly clearing faults 1039 o PHB: identifies the per-hop behavior of packets with fault 1040 management information 1042 Refresh Timer: indicates the refresh timer (in microseconds) of fault 1043 indication messages. If the T-PE receiving the Path message can not 1044 support such value, it can reply back with a higher interval. 1046 8. IANA Considerations 1048 This document specifies the following new LDP TLV types: 1049 o MPLS-TP PW OAM Capability TLV; 1050 o MPLS-TP PW OAM Administration TLV; 1051 o MPLS-TP PW OAM Configuration TLV; 1053 Sub-TLV types to be carried in the "MPLS-TP PW OAM Configuration 1054 TLV": 1055 o BFD Configuration sub-TLV; 1056 o Performance Monitoring sub-TLV 1057 o MPLS-TP PW FMS sub-TLV; 1059 Sub-TLV types to be carried in the "BFD Configuration sub-TLV": 1060 o Local Discriminator sub-TLV; 1061 o Negotiation Timer Parameters sub-TLV. 1062 o BFD Authentication sub-TLV 1064 Sub-TLV types to be carried in the "Performance Monitoring sub-TLV": 1065 o MPLS-TP PW PM Loss sub-TLV; 1066 o MPLS-TP PW PM Loss sub-TLV. 1068 8.1. OAM Configuration Errors 1070 This document defines several new LDP status codes, IANA already 1071 maintains the registry "STATUS CODE NAME SPACE" defined by [RFC5036]. 1072 The following values are required to be assigned: 1074 Range/Value E Description 1075 0x0000003C 0 "MIP Configuration Failure" 1076 0x0000003D 0 "Rejected MPLS-TP PW OAM Configuration TLV" 1077 0x0000003E 0 "Wrong MPLS-TP PW OAM Configuration TLV" 1078 0x0000003F 0 "Unsupported OAM Version" 1079 0x0000004A 0 "Unsupported BFD TX Echo rate interval" 1081 9. Security Considerations 1083 Security considerations relating to LDP are described in section 5 of 1084 [RFC5036] and section 11 of [RFC5561]. Security considerations 1085 relating to use of LDP in setting up PWs is described in section 8 of 1086 [RFC4447]. 1088 This document defines new TLV/sub-TLV types, and OAM configuration 1089 procedures intended for use with MPLS-TP, which do not raise any 1090 additional security issues. 1092 10. Acknowledgement 1094 The authors would like to thank Andew Malis, Greg Mirsky, Luca 1095 Martini, Matthew Bocci, Thomas Nadeau for their valuable comments and 1096 discussions, especially would like to thank Eric Gray for his review 1097 of this document. 1099 11. References 1101 11.1. Normative references 1103 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1104 Requirement Levels", BCP 14, RFC 2119, March 1997. 1106 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 1107 Heron, "Pseudowire Setup and Maintenance Using the Label 1108 Distribution Protocol (LDP)", RFC 4447, April 2006. 1110 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1111 Specification", RFC 5036, October 2007. 1113 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 1114 Le Roux, "LDP Capabilities", RFC 5561, July 2009. 1116 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 1117 Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. 1119 11.2. Informative References 1121 [I-D.ietf-mpls-lsp-ping-mpls-tp-oam-conf] 1122 Bellagamba, E., Andersson, L., Skoldstrom, P., Ward, D., 1123 and J. Drake, "Configuration of Pro-Active Operations, 1124 Administration, and Maintenance (OAM) Functions for MPLS- 1125 based Transport Networks using LSP Ping", 1126 draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-03 (work in 1127 progress), October 2011. 1129 [I-D.ietf-mpls-tp-oam-analysis] 1130 Sprecher, N. and L. Fang, "An Overview of the OAM Tool Set 1131 for MPLS based Transport Networks", 1132 draft-ietf-mpls-tp-oam-analysis-07 (work in progress), 1133 December 2011. 1135 [I-D.ietf-pwe3-static-pw-status] 1136 Martini, L., Swallow, G., Heron, G., and M. Bocci, 1137 "Pseudowire Status for Static Pseudowires", 1138 draft-ietf-pwe3-static-pw-status-10 (work in progress), 1139 November 2011. 1141 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 1142 Edge (PWE3) Architecture", RFC 3985, March 2005. 1144 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 1145 Connectivity Verification (VCCV): A Control Channel for 1146 Pseudowires", RFC 5085, December 2007. 1148 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 1149 and S. Ueno, "Requirements of an MPLS Transport Profile", 1150 RFC 5654, September 2009. 1152 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 1153 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 1154 October 2009. 1156 [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for 1157 Operations, Administration, and Maintenance (OAM) in MPLS 1158 Transport Networks", RFC 5860, May 2010. 1160 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1161 (BFD)", RFC 5880, June 2010. 1163 [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding 1164 Detection (BFD) for the Pseudowire Virtual Circuit 1165 Connectivity Verification (VCCV)", RFC 5885, June 2010. 1167 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 1168 Maintenance Framework for MPLS-Based Transport Networks", 1169 RFC 6371, September 2011. 1171 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 1172 Measurement for MPLS Networks", RFC 6374, September 2011. 1174 [RFC6375] Frost, D. and S. Bryant, "A Packet Loss and Delay 1175 Measurement Profile for MPLS-Based Transport Networks", 1176 RFC 6375, September 2011. 1178 [RFC6427] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S., 1179 and D. Ward, "MPLS Fault Management Operations, 1180 Administration, and Maintenance (OAM)", RFC 6427, 1181 November 2011. 1183 [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive 1184 Connectivity Verification, Continuity Check, and Remote 1185 Defect Indication for the MPLS Transport Profile", 1186 RFC 6428, November 2011. 1188 Authors' Addresses 1190 Fei Zhang (editor) 1191 ZTE Corporation 1193 Email: zhang.fei3@zte.com.cn 1195 Bo Wu (editor) 1196 ZTE Corporation 1198 Email: wu.bo@zte.com.cn 1200 Elisa Bellagamba (editor) 1201 Ericsson 1202 Farogatan 6 1203 Kista, 164 40 1204 Sweden 1206 Phone: +46 761440785 1207 Email: elisa.bellagamba@ericsson.com 1209 Attila Takacs 1210 Ericsson 1211 Laborc u. 1. 1212 Budapest, 1037 1213 Hungary 1215 Email: attila.takacs@ericsson.com 1217 Xuehui Dai 1218 ZTE Corporation 1220 Email: dai.xuehui@zte.com.cn 1222 Min Xiao 1223 ZTE Corporation 1225 Email: xiao.min2@zte.com.cn