idnits 2.17.1 draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-16.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 (November 23, 2015) is 3070 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 4379 (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group E. Bellagamba 3 Internet-Draft 4 Intended status: Standards Track G. Mirsky 5 Expires: May 26, 2016 Ericsson 6 L. Andersson 7 Huawei Technologies 8 P. Skoldstrom 9 Acreo AB 10 D. Ward 11 Cisco 12 J. Drake 13 Juniper 14 November 23, 2015 16 Configuration of Proactive Operations, Administration, and Maintenance 17 (OAM) Functions for MPLS-based Transport Networks using LSP Ping 18 draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-16 20 Abstract 22 This specification describes the configuration of proactive MPLS-TP 23 Operations, Administration, and Maintenance (OAM) Functions for a 24 given Label Switched Path (LSP) using a set of TLVs that are carried 25 by the LSP-Ping protocol. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 26, 2016. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Conventions used in this document . . . . . . . . . . . . 4 63 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 4 64 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 5 65 2. Theory of Operations . . . . . . . . . . . . . . . . . . . . 5 66 2.1. MPLS OAM Configuration Operation Overview . . . . . . . . 5 67 2.1.1. Configuration of BFD Sessions . . . . . . . . . . . . 5 68 2.1.2. Configuration of Performance Monitoring . . . . . . . 6 69 2.1.3. Configuration of Fault Management Signals . . . . . . 6 70 2.2. MPLS OAM Functions TLV . . . . . . . . . . . . . . . . . 7 71 2.2.1. BFD Configuration Sub-TLV . . . . . . . . . . . . . . 9 72 2.2.2. Local Discriminator Sub-TLV . . . . . . . . . . . . . 11 73 2.2.3. Negotiation Timer Parameters Sub-TLV . . . . . . . . 11 74 2.2.4. BFD Authentication Sub-TLV . . . . . . . . . . . . . 12 75 2.2.5. Traffic Class Sub-TLV . . . . . . . . . . . . . . . . 13 76 2.2.6. Performance Measurement Sub-TLV . . . . . . . . . . . 14 77 2.2.7. PM Loss Measurement Sub-TLV . . . . . . . . . . . . . 16 78 2.2.8. PM Delay Measurement Sub-TLV . . . . . . . . . . . . 17 79 2.2.9. Fault Management Signal Sub-TLV . . . . . . . . . . . 18 80 2.2.10. Source MEP-ID Sub-TLV . . . . . . . . . . . . . . . . 20 81 3. Summary of MPLS OAM Configuration Errors . . . . . . . . . . 20 82 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 83 4.1. TLV and Sub-TLV Allocation . . . . . . . . . . . . . . . 22 84 4.2. MPLS OAM Function Flags Allocation . . . . . . . . . . . 23 85 4.3. OAM Configuration Errors . . . . . . . . . . . . . . . . 23 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24 87 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 88 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 89 7.1. Normative References . . . . . . . . . . . . . . . . . . 25 90 7.2. Informative References . . . . . . . . . . . . . . . . . 26 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 93 1. Introduction 95 The MPLS Transport Profile (MPLS-TP) describes a profile of MPLS that 96 enables operational models typical in transport networks, while 97 providing additional Operations, Administration, and Maintenance 98 (OAM), survivability and other maintenance functions not currently 99 supported by MPLS. [RFC5860] defines the requirements for the OAM 100 functionality of MPLS-TP. 102 This document describes the configuration of proactive MPLS-TP OAM 103 Functions for a given Label Switched Path (LSP) using TLVs carried in 104 LSP Ping [RFC4379]. In particular it specifies the mechanisms 105 necessary to establish MPLS-TP OAM entities at the maintenance points 106 for monitoring and performing measurements on an LSP, as well as 107 defining information elements and procedures to configure proactive 108 MPLS-TP OAM functions running between LERs. Initialization and 109 control of on-demand MPLS-TP OAM functions are expected to be carried 110 out by directly accessing network nodes via a management interface; 111 hence configuration and control of on-demand OAM functions are out- 112 of-scope for this document. 114 The Transport Profile of MPLS must, by definition [RFC5654], be 115 capable of operating without a control plane. Therefore there are 116 several options for configuring MPLS-TP OAM, without a control plane 117 by either using an NMS or LSP Ping, or with a control plane using 118 signaling protocols RSVP Traffic engineering (RSVP-TE) [RFC3209] and/ 119 or Targeted LDP [RFC5036]. 121 Proactive MPLS-TP OAM is performed by set of protocols, Bi- 122 directional Forwarding Detection (BFD) [RFC6428] for Continuity 123 Check/Connectivity Verification, the delay measurement protocol (DM) 124 [RFC6374], [RFC6375] for delay and delay variation (jitter) 125 measurements, and the loss measurement (LM) protocol [RFC6374], 126 [RFC6375] for packet loss and throughput measurements. Additionally, 127 there is a number of Fault Management Signals that can be configured 128 [RFC6427]. 130 BFD is a protocol that provides low-overhead, fast detection of 131 failures in the path between two forwarding engines, including the 132 interfaces, data link(s), and, to the extent possible, the forwarding 133 engines themselves. BFD can be used to detect the continuity and 134 mis-connection defects of MPLS-TP point-to-point and might also be 135 extended to support point-to-multipoint label switched paths (LSPs). 137 The delay and loss measurements protocols [RFC6374] and [RFC6375] use 138 a simple query/response model for performing both uni- and bi- 139 directional measurements that allow the originating node to measure 140 packet loss and delay in forward or forward and reverse directions. 142 By timestamping and/or writing current packet counters to the 143 measurement packets (four times, Transmit and Receive in both 144 directions), current delays and packet losses can be calculated. By 145 performing successive delay measurements, the delay and/or inter- 146 packet delay variation (jitter) can be calculated. Current 147 throughput can be calculated from the packet loss measurements by 148 dividing the number of packets sent/received with the time it took to 149 perform the measurement, given by the timestamp in LM header. 150 Combined with a packet generator the throughput measurement can be 151 used to measure the maximum capacity of a particular LSP. It should 152 be noted that this document does not specify how to configure on- 153 demand throughput estimates based on saturating the connection as 154 defined in [RFC6371]. Rather, only how to enable the estimation of 155 the current throughput based on loss measurements. 157 1.1. Conventions used in this document 159 1.1.1. Terminology 161 BFD - Bidirectional Forwarding Detection 163 DM - Delay Measurement 165 FMS - Fault Management Signal 167 G-ACh - Generic Associated Channel 169 LSP - Label Switched Path 171 LM - Loss Measurement 173 MEP - Maintenance Entity Group End Point 175 MPLS - Multi-Protocol Label Switching 177 MPLS-TP - MPLS Transport Profile 179 NMS - Network management System 181 PM - Performance Measurement 183 RSVP-TE - RSVP Traffic Engineering 185 TC - Traffic Class 187 1.1.2. Requirements Language 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in RFC 2119 [RFC2119]. 193 2. Theory of Operations 195 2.1. MPLS OAM Configuration Operation Overview 197 The MPLS-TP OAM tool set is described in the [RFC6669]. 199 LSP Ping, or alternatively RSVP-TE [RFC7487], can be used to simply 200 enable the different OAM functions, by setting the corresponding 201 flags in the MPLS OAM Functions TLV (refer to Section 2.2). For a 202 more detailed configuration, one may include sub-TLVs for the 203 different OAM functions in order to specify various parameters in 204 detail. 206 Typically intermediate nodes simply forward OAM configuration TLVs to 207 the end-node without any processing or modification. At least one 208 exception to this is if the FMS sub-TLV (refer to Section 2.2.9 ) is 209 present. This sub-TLV MUST be examined even by intermediate nodes 210 that support this extension. The sub-TLV MAY be present if a flag is 211 set in the MPLS OAM Functions TLV. 213 2.1.1. Configuration of BFD Sessions 215 For this specification, BFD MUST run in either one of the two modes: 217 - Asynchronous mode, where both sides are in active mode 219 - Unidirectional mode 221 In the simplest scenario, LSP Ping [RFC5884], or alternatively RSVP- 222 TE [RFC7487], is used only to bootstrap a BFD session for an LSP, 223 without any timer negotiation. 225 Timer negotiation can be performed either in subsequent BFD control 226 messages (in this case the operation is similar to LSP Ping based 227 bootstrapping described in [RFC5884]) or directly in the LSP-Ping 228 configuration messages. 230 When BFD Control packets are transported in the ACH encapsulation, 231 they are not protected by any end-to-end checksum, only lower-layers 232 are providing error detection/correction. A single bit error, e.g. a 233 flipped bit in the BFD State field could cause the receiving end to 234 wrongly conclude that the link is down and in turn trigger protection 235 switching. To prevent this from happening, the BFD Configuration 236 sub-TLV (refer to Section 2.2.1) has an Integrity flag that when set 237 enables BFD Authentication using Keyed SHA1 with an empty key (all 238 0s) [RFC5880]. This would make every BFD Control packet carry an 239 SHA1 hash of itself that can be used to detect errors. 241 If BFD Authentication using a pre-shared key/password is desired 242 (i.e. authentication and not only error detection), the BFD 243 Authentication sub-TLV (refer to Section 2.2.4) MUST be included in 244 the BFD Configuration sub-TLV. The BFD Authentication sub-TLV is 245 used to specify which authentication method that should be used and 246 which pre-shared key/ password that should be used for this 247 particular session. How the key exchange is performed is out of 248 scope of this document. 250 2.1.2. Configuration of Performance Monitoring 252 It is possible to configure Performance Monitoring functionalities 253 such as Loss, Delay, Delay/Interpacket Delay variation (jitter), and 254 Throughput as described in [RFC6374]. 256 When configuring Performance Monitoring functionalities, it is 257 possible to choose either the default configuration, by only setting 258 the respective flags in the MPLS OAM functions TLV, or a customized 259 configuration. To customize the configuration, one would set the 260 respective flags in the MPLS OAM functions TLV and include the 261 respective Loss and/or Delay sub-TLVs. 263 By setting the PM Loss flag in the MPLS OAM Functions TLV and 264 including the PM Loss sub-TLV (refer to Section 2.2.7) one can 265 configure the measurement interval and loss threshold values for 266 triggering protection. 268 Delay measurements are configured by setting the PM Delay flag in the 269 MPLS OAM Functions TLV and including the PM Delay sub-TLV (refer to 270 Section 2.2.8) one can configure the measurement interval and the 271 delay threshold values for triggering protection. 273 2.1.3. Configuration of Fault Management Signals 275 To configure Fault Management Signals (FMS) and their refresh time, 276 the FMS flag in the MPLS OAM Functions TLV MUST be set and the FMS 277 sub-TLV MUST be included. When configuring FMS, an implementation 278 can enable the default configuration by setting the FMS flag in the 279 OAM Function Flags sub-TLV. In order to modify the default 280 configuration, the MPLS OAM FMS sub-TLV MUST be included. 282 If an intermediate point is meant to originate fault management 283 signal messages, this means that such an intermediate point is 284 associated with a Server MEP through a co-located MPLS-TP client/ 285 server adaptation function, and the Fault Management subscription 286 flag in the MPLS OAM FMS sub-TLV has been set as indication of the 287 request to create the association at each intermediate node of the 288 client LSP. The corresponding Server MEP needs to be configured by 289 its own LSP-ping session or, alternatively, via a Network Management 290 system (NMS) or RSVP-TE. 292 2.2. MPLS OAM Functions TLV 294 The MPLS OAM Functions TLV presented in Figure 1 is carried as a TLV 295 of the MPLS Echo Request/Reply messages [RFC4379]. 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | MPLS OAM Func. Type (TBA1) | Length | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | MPLS OAM Function Flags | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | | 305 ~ sub-TLVs ~ 306 | | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Figure 1: MPLS OAM Functions TLV format 311 The MPLS OAM Functions TLV contains MPLS OAM Function Flags field. 312 The MPLS OAM Function Flags indicates which OAM functions should be 313 activated as well as OAM function specific sub-TLVs with 314 configuration parameters for the particular function. 316 Type: indicates the MPLS OAM Functions TLV Section 4. 318 Length: the length of the MPLS OAM Function Flags field including the 319 total length of the sub-TLVs in octets. 321 MPLS OAM Function Flags: a bitmap numbered from left to right as 322 shown in the Figure 2. These flags are managed by IANA (refer to 323 Section 4.2). Flags defined in this document are presented in 324 Table 2. Undefined flags MUST be set to zero and unknown flags MUST 325 be ignored. The flags indicate what OAM is being configured and 326 direct the presence of optional sub-TLVs as set out below. 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 |C|V|F|L|D|T| Unassigned (MBZ) |R| 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 Figure 2: MPLS OAM Function Flags format 336 Sub-TLVs corresponding to the different flags are as follows. No 337 meaning should be attached to the order of sub-TLVs. 339 - If a flag in the MPLS OAM Function Flags is set and the 340 corresponding sub-TLVs listed below is absent, then this MPLS OAM 341 function MUST be initialized according to its default settings. 342 Default settings of MPLS OAM functions are outside the scope of 343 this document. 345 - If any sub-TLV is present without the corresponding flag being 346 set, the sub-TLV SHOULD be ignored. 348 - BFD Configuration sub-TLV, which MUST be included if either the 349 CC, the CV or both MPLS OAM Function flags being set in the MPLS 350 OAM Functions TLV . 352 - Performance Monitoring sub-TLV MUST be used to carry PM Loss 353 sub-TLV and/or PM Delay sub-TLV. If neither one of these sub-TLVs 354 is present then Performance Monitoring sub-TLV SHOULD NOT be 355 included. Empty, i.e. no enclosed sub-TLVs, Performance 356 Monitoring sub-TLV SHOULD be ignored. 358 - PM Loss sub-TLV MAY be included if the PM/Loss OAM Function flag 359 is set. If the "PM Loss sub-TLV" is not included, default 360 configuration values are used. Such sub-TLV MAY also be included 361 in case the Throughput function flag is set and there is the need 362 to specify a measurement interval different from the default ones. 363 In fact, the throughput measurement makes use of the same tool as 364 the loss measurement, hence the same TLV is used. 366 - PM Delay sub-TLV MAY be included if the PM/Delay OAM Function 367 flag is set. If the "PM Delay sub-TLV" is not included, default 368 configuration values are used. 370 - FMS sub-TLV, which MAY be included if the FMS OAM Function flag 371 is set. If the "FMS sub-TLV" is not included, default 372 configuration values are used. 374 If all flags in the MPLS OAM Function Flags field have the same value 375 of zero, that MUST be interpreted as the MPLS OAM Functions TLV not 376 present in the MPLS Echo Request. If more than one MPLS OAM 377 Functions TLV is present in the MPLS Echo request packet, then the 378 first TLV SHOULD be processed and the rest be ignored. Any parsing 379 error within nested sub-TLVs that is not specified in Section 3 380 SHOULD be treated as described in [RFC4379]. 382 2.2.1. BFD Configuration Sub-TLV 384 The BFD Configuration sub-TLV, depicted in Figure 3, is defined for 385 BFD OAM specific configuration parameters. The "BFD Configuration 386 sub-TLV" is carried as a sub-TLV of the "OAM Functions TLV". 388 This TLV accommodates generic BFD OAM information and carries sub- 389 TLVs. 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | BFD Conf. sub-Type (100) | Length | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 |Vers.|N|S|I|G|U|B| Reserved (set to all 0s) | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | | 399 ~ sub-TLVs ~ 400 | | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 Figure 3: BFD Configuration sub-TLV format 405 Sub-type: indicates a new sub-type, the BFD Configuration sub-TLV 406 (value 100). 408 Length: indicates the length of the Value field in octets. 410 Version: identifies the BFD protocol version. If a node does not 411 support a specific BFD version an error must be generated: "OAM 412 Problem/Unsupported OAM Version". 414 BFD Negotiation (N): If set timer negotiation/re-negotiation via BFD 415 Control Messages is enabled, when cleared it is disabled and timer 416 configuration is achieved using Negotiation Timer Parameters sub-TLV 417 as described in Section 2.2.3. 419 Symmetric session (S): If set the BFD session MUST use symmetric 420 timing values. If cleared the BFD session MAY use any timing values 421 either negotiated or explicitly configured. 423 Integrity (I): If set BFD Authentication MUST be enabled. If the BFD 424 Configuration sub-TLV does not include a BFD Authentication sub-TLV 425 the authentication MUST use Keyed SHA1 with an empty pre-shared key 426 (all 0s). If the egress LSR does not support BFD Authentication an 427 error MUST be generated: "OAM Problem/BFD Authentication 428 unsupported". If the Integrity flag is clear, then Authentication 429 MUST NOT be used. 431 Encapsulation Capability (G): if set, it shows the capability of 432 encapsulating BFD messages into G-ACh channel. If both the G bit and 433 U bit are set, configuration gives precedence to the G bit. 435 Encapsulation Capability (U): if set, it shows the capability of 436 encapsulating BFD messages into IP/UDP packets. If both the G bit 437 and U bit are set, configuration gives precedence to the G bit. 439 If the egress LSR does not support any of the ingress LSR 440 Encapsulation Capabilities an error MUST be generated: "OAM Problem/ 441 Unsupported BFD Encapsulation format". 443 Bidirectional (B): if set, it configures BFD in the Bidirectional 444 mode. If it is not set it configures BFD in unidirectional mode. In 445 the second case, the source node does not expect any Discriminator 446 values back from the destination node. 448 Reserved: Reserved for future specification and set to 0 on 449 transmission and ignored when received. 451 The BFD Configuration sub-TLV MUST include the following sub-TLVs in 452 the MPLS Echo Request message: 454 - Local Discriminator sub-TLV, if B flag is set in the MPLS Echo 455 Request; 457 - Negotiation Timer Parameters sub-TLV if the N flag is cleared. 459 The BFD Configuration sub-TLV MUST include the following sub-TLVs in 460 the MPLS Echo Reply message: 462 - Local Discriminator sub-TLV; 464 - Negotiation Timer Parameters sub-TLV if: 466 - the N and S flags are cleared, or if: 468 - the N flag is cleared and the S flag is set, and the 469 Negotiation Timer Parameters sub-TLV received by the egress 470 contains unsupported values. In this case an updated 471 Negotiation Timer Parameters sub-TLV, containing values 472 supported by the egress node [RFC7419], is returned to the 473 ingress. 475 2.2.2. Local Discriminator Sub-TLV 477 The Local Discriminator sub-TLV is carried as a sub-TLV of the "BFD 478 Configuration sub-TLV" and is depicted in Figure 4. 480 0 1 2 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Locl. Discr. sub-Type (101) | Length | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Local Discriminator | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Figure 4: Local Discriminator sub-TLV format 490 Type: indicates a new type, the "Local Discriminator sub-TLV" (value 491 101). 493 Length: indicates the length of the Value field in octets . (4) 495 Local Discriminator: A nonzero discriminator value that is unique in 496 the context of the transmitting system that generates it. It is used 497 to demultiplex multiple BFD sessions between the same pair of 498 systems. 500 2.2.3. Negotiation Timer Parameters Sub-TLV 502 The Negotiation Timer Parameters sub-TLV is carried as a sub-TLV of 503 the BFD Configuration sub-TLV and is depicted in Figure 5. 505 0 1 2 3 506 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 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Nego. Timer sub-type (102) | Length | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Acceptable Min. Asynchronous TX interval | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Acceptable Min. Asynchronous RX interval | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Required Echo TX Interval | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 Figure 5: Negotiation Timer Parameters sub-TLV format 519 Sub-type: indicates a new sub-type, the Negotiation Timer Parameters 520 sub-TLV (value 102). 522 Length: indicates the length of the Value field in octets (12). 524 Acceptable Min. Asynchronous TX interval: in case of S (symmetric) 525 flag set in the BFD Configuration sub-TLV, defined in Section 2.2.1, 526 it expresses the desired time interval (in microseconds) at which the 527 ingress LER intends to both transmit and receive BFD periodic control 528 packets. If the receiving edge LSR cannot support such value, it 529 SHOULD reply with an interval greater than the one proposed. 531 In case of S (symmetric) flag cleared in the BFD Configuration sub- 532 TLV, this field expresses the desired time interval (in microseconds) 533 at which a edge LSR intends to transmit BFD periodic control packets 534 in its transmitting direction. 536 Acceptable Min. Asynchronous RX interval: in case of S (symmetric) 537 flag set in the BFD Configuration sub-TLV, Figure 3, this field MUST 538 be equal to Acceptable Min. Asynchronous TX interval and has no 539 additional meaning respect to the one described for "Acceptable Min. 540 Asynchronous TX interval". 542 In case of S (symmetric) flag cleared in the BFD Configuration sub- 543 TLV, it expresses the minimum time interval (in microseconds) at 544 which edge LSRs can receive BFD periodic control packets. In case 545 this value is greater than the value of Acceptable Min. Asynchronous 546 TX interval received from the other edge LSR, such edge LSR MUST 547 adopt the interval expressed in this Acceptable Min. Asynchronous RX 548 interval. 550 Required Echo TX Interval: the minimum interval (in microseconds) 551 between received BFD Echo packets that this system is capable of 552 supporting, less any jitter applied by the sender as described in 553 [RFC5880] sect. 6.8.9. This value is also an indication for the 554 receiving system of the minimum interval between transmitted BFD Echo 555 packets. If this value is zero, the transmitting system does not 556 support the receipt of BFD Echo packets. If the receiving system 557 cannot support this value the "Unsupported BFD TX Echo rate interval" 558 error MUST be generated. By default the value is set to 0. 560 2.2.4. BFD Authentication Sub-TLV 562 The "BFD Authentication sub-TLV" is carried as a sub-TLV of the "BFD 563 Configuration sub-TLV" and is depicted in Figure 6. 565 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | BFD Auth. sub-type (103) | Length | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Auth Type | Auth Key ID | Reserved (0s) | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 Figure 6: BFD Authentication sub-TLV format 575 Sub-type: indicates a new type, the BFD Authentication sub-TLV (value 576 103). 578 Length: indicates the length of the Value field in octets (4). 580 Auth Type: indicates which type of authentication to use. The same 581 values as are defined in section 4.1 of [RFC5880] are used. Simple 582 Password SHOULD NOT be used if other authentication types are 583 available. 585 Auth Key ID: indicates which authentication key or password 586 (depending on Auth Type) should be used. How the key exchange is 587 performed is out of scope of this document. If the egress LSR does 588 not support this Auth Key ID an "OAM Problem/Mismatch of BFD 589 Authentication Key ID" error MUST be generated. 591 Reserved: Reserved for future specification and set to 0 on 592 transmission and ignored when received. 594 An implementation MAY change mode of authentication if an operator 595 re-evaluates the security situation in and around the administrative 596 domain. If BFD Authentication sub-TLV used for a BFD session in Up 597 state, then the Sender of the MPLS LSP Echo Request SHOULD ensure 598 that old and new modes of authentication, i.e. combination of 599 Auth.Type and Auth. Key ID, are used to send and receive BFD control 600 packets, until the Sender can confirm that its peer has switched to 601 the new authentication. 603 2.2.5. Traffic Class Sub-TLV 605 The Traffic Class sub-TLV is carried as a sub-TLV of the "BFD 606 Configuration sub-TLV" and "Fault Management Signal sub-TLV" 607 Section 2.2.9 and is depicted in Figure 7. 609 0 1 2 3 610 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 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Traffic Class sub-Type (104) | Length | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | TC | Reserved (set to all 0s) | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 Figure 7: Traffic Class sub-TLV format 619 Type: indicates a new type, the "Traffic Class sub-TLV" (value 104). 621 Length: indicates the length of the Value field in octets . (4) 623 TC: Identifies the Traffic Class (TC) [RFC5462] for periodic 624 continuity monitoring messages or packets with fault management 625 information. 627 If the TC sub-TLV is present, then the sender of any periodic 628 continuity monitoring messages or packets with fault management 629 information on the LSP, with a FEC that corresponds to the FEC for 630 which fault detection is being performed, MUST use the value 631 contained in the TC field of the sub-TLV as the value of the TC field 632 in the top label stack entry of the MPLS label stack. If the TC sub- 633 TLV is absent from either "BFD Configuration sub-TLV" or "Fault 634 Management Signal sub-TLV", then selection of the TC value is local 635 decision. 637 2.2.6. Performance Measurement Sub-TLV 639 If the MPLS OAM Functions TLV has any of the L (Loss), D (Delay) and 640 T (Throughput) flag set, the Performance Measurement sub-TLV MUST be 641 present. Failure to include the correct sub-TLVs MUST result in an 642 "OAM Problem/ Configuration Error" error being generated. 644 The Performance Measurement sub-TLV provides the configuration 645 information mentioned in Section 7 of [RFC6374]. It includes support 646 for the configuration of quality thresholds and, as described in 647 [RFC6374], "the crossing of which will trigger warnings or alarms, 648 and result in reporting and exception notification will be integrated 649 into the system-wide network management and reporting framework." 651 In case the values need to be different than the default ones, the 652 Performance Measurement sub-TLV MAY include the following sub-TLVs: 654 - PM Loss sub-TLV if the L flag is set in the MPLS OAM Functions 655 TLV; 656 - PM Delay sub-TLV if the D flag is set in the MPLS OAM Functions 657 TLV. 659 The Performance Measurement sub-TLV depicted in Figure 8 is carried 660 as a sub-TLV of the MPLS OAM Functions TLV. 662 0 1 2 3 663 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Perf Monitoring Type (200) | Length | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | PM Configuration Flags | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | | 670 ~ sub-TLVs ~ 671 | | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 Figure 8: Performance Measurement sub-TLV format 676 Sub-type: indicates a new sub-type, the Performance Management sub- 677 TLV" (value 200). 679 Length: indicates the length of the Value field in octets, including 680 PM Configuration Flags and optional sub-TLVs. 682 0 1 2 3 683 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 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 |D|L|J|Y|K|C| Reserved (set to all 0s) | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 Figure 9: Performance Measurement sub-TLV format 690 PM Configuration Flags, format is presented in Figure 9, for the 691 specific function description please refer to [RFC6374]: 693 - D: Delay inferred/direct (0=INFERRED, 1=DIRECT). If the egress 694 LSR does not support specified mode an "OAM Problem/Unsupported 695 Delay Mode" error MUST be generated. 697 - L: Loss inferred/direct (0=INFERRED, 1=DIRECT). If the egress 698 LSR does not support specified mode an "OAM Problem/Unsupported 699 Loss Mode" error MUST be generated. 701 - J: Delay variation/jitter (1=ACTIVE, 0=NOT ACTIVE). If the 702 egress LSR does not support Delay variation measurements and the J 703 flag is set, an "OAM Problem/Delay variation unsupported" error 704 MUST be generated. 706 - Y: Dyadic (1=ACTIVE, 0=NOT ACTIVE). If the egress LSR does not 707 support Dyadic mode and the Y flag is set, an "OAM Problem/Dyadic 708 mode unsupported" error MUST be generated. 710 - K: Loopback (1=ACTIVE, 0=NOT ACTIVE). If the egress LSR does 711 not support Loopback mode and the K flag is set, an "OAM Problem/ 712 Loopback mode unsupported" error MUST be generated. 714 - C: Combined (1=ACTIVE, 0=NOT ACTIVE). If the egress LSR does 715 not support Combined mode and the C flag is set, an "OAM Problem/ 716 Combined mode unsupported" error MUST be generated. 718 Reserved: Reserved for future specification and set to 0 on 719 transmission and ignored when received. 721 2.2.7. PM Loss Measurement Sub-TLV 723 The PM Loss Measurement sub-TLV depicted in Figure 10 is carried as a 724 sub-TLV of the Performance Measurement sub-TLV. 726 0 1 2 3 727 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 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | PM Loss sub-type (201) | Length | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | OTF |T|B| Reserved (set to all 0s) | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Measurement Interval | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Test Interval | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Loss Threshold | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 Figure 10: PM Loss Measurement sub-TLV format 742 Sub-type: indicates a new sub-type, the PM Loss Measurement sub-TLV 743 (value 201). 745 Length: indicates the length of the Value field in octets (16). 747 OTF: Origin Timestamp Format of the Origin Timestamp field described 748 in [RFC6374]. By default it is set to IEEE 1588 version 1. If the 749 egress LSR cannot support this value an "OAM Problem/Unsupported 750 Timestamp Format" error MUST be generated. 752 Configuration Flags, please refer to [RFC6374] for further details: 754 - T: Traffic-class-specific measurement indicator. Set to 1 when 755 the measurement operation is scoped to packets of a particular 756 traffic class (DSCP value), and 0 otherwise. When set to 1, the 757 DS field of the message indicates the measured traffic class. By 758 default it is set to 1. 760 - B: Octet (byte) count. When set to 1, indicates that the 761 Counter 1-4 fields represent octet counts. When set to 0, 762 indicates that the Counter 1-4 fields represent packet counts. By 763 default it is set to 0. 765 Reserved: Reserved for future specification and set to 0 on 766 transmission and ignored when received. 768 Measurement Interval: the time interval (in milliseconds) at which 769 Loss Measurement query messages MUST be sent on both directions. If 770 the edge LSR receiving the Path message cannot support such value, it 771 SHOULD reply with a higher interval. By default it is set to (100) 772 as per [RFC6375]. 774 Test Interval: test messages interval in milliseconds as described in 775 [RFC6374]. By default it is set to (10) as per [RFC6375]. 777 Loss Threshold: the threshold value of measured lost packets per 778 measurement over which action(s) SHOULD be triggered. 780 2.2.8. PM Delay Measurement Sub-TLV 782 The "PM Delay Measurement sub-TLV" depicted in Figure 11 is carried 783 as a sub-TLV of the Performance Monitoring sub-TLV. 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 | PM Delay Type (202) | Length | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | OTF |T|B| Reserved (set to all 0s) | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Measurement Interval | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Test Interval | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Delay Threshold | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 Figure 11: PM Delay Measurement sub-TLV format 801 Sub-type: indicates a new sub-type, the "PM Delay Measurement sub- 802 TLV" (value 202). 804 Length: indicates the length of the Value field in octets (16). 806 OTF: Origin Timestamp Format of the Origin Timestamp field described 807 in [RFC6374]. By default it is set to IEEE 1588 version 1. If the 808 egress LSR cannot support this value, an "OAM Problem/Unsupported 809 Timestamp Format" error MUST be generated. 811 Configuration Flags, please refer to [RFC6374] for further details: 813 - T: Traffic-class-specific measurement indicator. Set to 1 when 814 the measurement operation is scoped to packets of a particular 815 traffic class (DSCP value), and 0 otherwise. When set to 1, the 816 DS field of the message indicates the measured traffic class. By 817 default it is set to 1. 819 - B: Octet (byte) count. When set to 1, indicates that the 820 Counter 1-4 fields represent octet counts. When set to 0, 821 indicates that the Counter 1-4 fields represent packet counts. By 822 default it is set to 0. 824 Reserved: Reserved for future specification and set to 0 on 825 transmission and ignored when received. 827 Measurement Interval: the time interval (in milliseconds) at which 828 Delay Measurement query messages MUST be sent on both directions. If 829 the edge LSR receiving the Path message cannot support such value, it 830 can reply with a higher interval. By default it is set to (1000) as 831 per [RFC6375]. 833 Test Interval: test messages interval (in milliseconds) as described 834 in [RFC6374]. By default it is set to (10) as per [RFC6375]. 836 Delay Threshold: the threshold value of measured two-way delay (in 837 milliseconds) over which action(s) SHOULD be triggered. 839 2.2.9. Fault Management Signal Sub-TLV 841 The FMS sub-TLV depicted in Figure 12 is carried as a sub-TLV of the 842 MPLS OAM Configuration sub-TLV. When both working and protection 843 paths are configured, both LSPs SHOULD be configured with identical 844 settings of the E flag, T flag, and the refresh timer. An 845 implementation MAY configure the working and protection LSPs with 846 different settings of these fields in case of 1:N protection. 848 0 1 2 3 849 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 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | FMS sub-type (300) | Length | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 |E|S|T| Reserved | Refresh Timer | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | | 856 ~ sub-TLVs ~ 857 | | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 Figure 12: Fault Management Signal sub-TLV format 862 Sub-type: indicates a new sub-type, the FMS sub-TLV (value 300). 864 Length: indicates the length of the Value field in octets. 866 FMS Signal Flags are used to enable the FMS signals at end point MEPs 867 and the Server MEPs of the links over which the LSP is forwarded. In 868 this document only the S flag pertains to Server MEPs. 870 The following flags are defined: 872 - E: Enable Alarm Indication Signal (AIS) and Lock Report (LKR) 873 signaling as described in [RFC6427]. Default value is 1 874 (enabled). If the egress MEP does not support FMS signal 875 generation, an "OAM Problem/Fault management signaling 876 unsupported" error MUST be generated. 878 - S: Indicate to a server MEP that it should transmit AIS and LKR 879 signals on the client LSP. Default value is 0 (disabled). If a 880 Server MEP which is capable of generating FMS messages is for some 881 reason unable to do so for the LSP being signaled, an "OAM 882 Problem/Unable to create fault management association" error MUST 883 be generated. 885 - T: Set timer value, enabled the configuration of a specific 886 timer value. Default value is 0 (disabled). 888 - Remaining bits: Reserved for future specification and set to 0. 890 Refresh Timer: indicates the refresh timer of fault indication 891 messages, in seconds. The value MUST be between 1 to 20 seconds as 892 specified for the Refresh Timer field in [RFC6427]. If the edge LSR 893 receiving the Path message cannot support the value it SHOULD reply 894 with a higher timer value. 896 FMS sub-TLV MAY include Traffic Class sub-TLV Section 2.2.5. If TC 897 sub-TLV is present, the value of the TC field MUST be used as the 898 value of the TC field of an MPLS label stack entry for FMS messages. 899 If the TC sub-TLV is absent, then selection of the TC value is local 900 decision. 902 2.2.10. Source MEP-ID Sub-TLV 904 The Source MEP-ID sub-TLV depicted in Figure 13 is carried as a sub- 905 TLV of the MPLS OAM Functions TLV. 907 Note that support of ITU IDs is out-of-scope. 909 0 1 2 3 910 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 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | Source MEP-ID sub-type (400) | Length | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | Source Node ID | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | Tunnel ID | LSP ID | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 Figure 13: Source MEP-ID sub-TLV format 921 Sub-type: indicates a new sub-type, the Source MEP-ID sub-TLV (value 922 400). 924 Length: indicates the length of the Value field in octets (8). 926 Source Node ID: 32-bit node identifier as defined in [RFC6370]. 928 Tunnel ID: a 16-bit unsigned integer unique to the node as defined in 929 [RFC6370]. 931 LSP ID: a 16-bit unsigned integer unique within the Tunnel_ID as 932 defined in [RFC6370]. 934 3. Summary of MPLS OAM Configuration Errors 936 This is the summary of Return Codes [RFC4379] defined in this 937 document: 939 - If an egress LSR does not support the specified BFD version, an 940 error MUST be generated: "OAM Problem/Unsupported BFD Version". 942 - If an egress LSR does not support the specified BFD 943 Encapsulation format, an error MUST be generated: "OAM Problem/ 944 Unsupported BFD Encapsulation format". 946 - If an egress LSR does not support BFD Authentication, and it is 947 requested, an error MUST be generated: "OAM Problem/BFD 948 Authentication unsupported". 950 - If an egress LSR does not support the specified BFD 951 Authentication Type, an error MUST be generated: "OAM Problem/ 952 Unsupported BFD Authentication Type". 954 - If an egress LSR is not able to use the specified Authentication 955 Key ID, an error MUST be generated: "OAM Problem/Mismatch of BFD 956 Authentication Key ID". 958 - If an egress LSR does not support the specified Timestamp 959 Format, an error MUST be generated: "OAM Problem/Unsupported 960 Timestamp Format". 962 - If an egress LSR does not support specified Delay mode, an "OAM 963 Problem/Unsupported Delay Mode" error MUST be generated. 965 - If an egress LSR does not support specified Loss mode, an "OAM 966 Problem/Unsupported Loss Mode" error MUST be generated. 968 - If an egress LSR does not support Delay variation measurements, 969 and it is requested, an "OAM Problem/Delay variation unsupported" 970 error MUST be generated. 972 - If an egress LSR does not support Dyadic mode, and it is 973 requested, an "OAM Problem/Dyadic mode unsupported" error MUST be 974 generated. 976 - If an egress LSR does not support Loopback mode, and it is 977 requested, an "OAM Problem/Loopback mode unsupported" error MUST 978 be generated. 980 - If an egress LSR does not support Combined mode, and it is 981 requested, an "OAM Problem/Combined mode unsupported" error MUST 982 be generated. 984 - If an egress LSR does not support Fault Monitoring Signals, and 985 it is requested, an "OAM Problem/Fault management signaling 986 unsupported" error MUST be generated. 988 - If an intermediate server MEP supports Fault Monitoring Signals 989 but is unable to create an association, when requested to do so, 990 an "OAM Problem/Unable to create fault management association" 991 error MUST be generated. 993 Ingress LSR MAY combine multiple MPLS OAM configuration TLVs and sub- 994 TLVs into single MPLS echo request. In case an egress LSR doesn't 995 support any of the requested modes it MUST set the return code to 996 report the first unsupported mode in the list of TLVs and sub-TLVs. 997 And if any of the requested OAM configuration is not supported the 998 egress LSR SHOULD NOT process OAM Configuration TLVs and sub-TLVs 999 listed in the MPLS echo request. 1001 4. IANA Considerations 1003 4.1. TLV and Sub-TLV Allocation 1005 IANA maintains the Multi-Protocol Label Switching (MPLS) Label 1006 Switched Paths (LSPs) Ping Parameters registry, and within that 1007 registry a sub-registry for TLVs and sub-TLVs. 1009 IANA is requested to allocate a new MPLS OAM Functions TLV from the 1010 standards action range (0-16383) and sub-TLVs as follows from sub- 1011 registry presented in Table 1, called "Sub-TLVs for TLV [TBA1]". 1013 Registration procedures for Sub-TLVs from ranges 0-16383 and 1014 32768-49161 are by Standards Action, and from ranges 16384-31743 and 1015 49162-64511 are through Specification Required (Experimental RFC 1016 Needed). 1018 +------+----------+---------------------------------+---------------+ 1019 | Type | Sub-type | Value Field | Reference | 1020 +------+----------+---------------------------------+---------------+ 1021 | TBA1 | | MPLS OAM Functions | This document | 1022 | | 100 | BFD Configuration | This document | 1023 | | 101 | BFD Local Discriminator | This document | 1024 | | 102 | BFD Negotiation Timer | This document | 1025 | | | Parameters | | 1026 | | 103 | BFD Authentication | This document | 1027 | | 104 | Traffic Class | This document | 1028 | | 200 | Performance Measurement | This document | 1029 | | 201 | PM Loss Measurement | This document | 1030 | | 202 | PM Delay Measurement | This document | 1031 | | 300 | Fault Management Signal | This document | 1032 | | 400 | Source MEP-ID | This document | 1033 +------+----------+---------------------------------+---------------+ 1035 Table 1: IANA TLV Type Allocation 1037 4.2. MPLS OAM Function Flags Allocation 1039 IANA is requested to create a new registry called the "MPLS OAM 1040 Function Flags" registry . Assignments of bit positions 0 through 31 1041 are via Standards Action. The new registry to be populated as 1042 follows. 1044 +------------+--------------------+---------------------------------+ 1045 | Bit | MPLS OAM Function | Description | 1046 | Position | Flag | | 1047 +------------+--------------------+---------------------------------+ 1048 | 0 | C | Continuity Check (CC) | 1049 | 1 | V | Connectivity Verification (CV) | 1050 | 2 | F | Fault Management Signal (FMS) | 1051 | 3 | L | Performance Measurement/Loss | 1052 | | | (PM/Loss) | 1053 | 4 | D | Performance Measurement/Delay | 1054 | | | (PM/Delay) | 1055 | 5 | T | Throughput Measurement | 1056 | 6-30 | | Unassigned (Must be zero) | 1057 | 31 | | Reserved | 1058 +------------+--------------------+---------------------------------+ 1060 Table 2: MPLS OAM Function Flags 1062 4.3. OAM Configuration Errors 1064 IANA maintains a registry "Multi-Protocol Label Switching (MPLS) 1065 Label Switched Paths (LSPs) Ping Parameters" registry, and within 1066 that registry a sub-registry "Return Codes". 1068 IANA is requested to assign new Return Codes from the Standards 1069 Action range (0-191) as follows: 1071 +---------------+-----------------------------------+---------------+ 1072 | Error Value | Description | Reference | 1073 | Sub-codes | | | 1074 +---------------+-----------------------------------+---------------+ 1075 | TBA3 | OAM Problem/Unsupported BFD | This document | 1076 | | Version | | 1077 | TBA4 | OAM Problem/Unsupported BFD | This document | 1078 | | Encapsulation format | | 1079 | TBA5 | OAM Problem/Unsupported BFD | This document | 1080 | | Authentication Type | | 1081 | TBA6 | OAM Problem/Mismatch of BFD | This document | 1082 | | Authentication Key ID | | 1083 | TBA7 | OAM Problem/Unsupported Timestamp | This document | 1084 | | Format | | 1085 | TBA8 | OAM Problem/Unsupported Delay | This document | 1086 | | Mode | | 1087 | TBA9 | OAM Problem/Unsupported Loss Mode | This document | 1088 | TBA10 | OAM Problem/Delay variation | This document | 1089 | | unsupported | | 1090 | TBA11 | OAM Problem/Dyadic mode | This document | 1091 | | unsupported | | 1092 | TBA12 | OAM Problem/Loopback mode | This document | 1093 | | unsupported | | 1094 | TBA13 | OAM Problem/Combined mode | This document | 1095 | | unsupported | | 1096 | TBA14 | OAM Problem/Fault management | This document | 1097 | | signaling unsupported | | 1098 | TBA15 | OAM Problem/Unable to create | This document | 1099 | | fault management association | | 1100 +---------------+-----------------------------------+---------------+ 1102 Table 3: IANA Return Codes Allocation 1104 5. Security Considerations 1106 The signaling of OAM related parameters and the automatic 1107 establishment of OAM entities introduces additional security 1108 considerations to those discussed in [RFC4379]. In particular, a 1109 network element could be overloaded if an attacker were to request 1110 high frequency liveliness monitoring of a large number of LSPs, 1111 targeting a single network element. Implementations must be made 1112 cognizant of available OAM resources and MAY refuse new OAM 1113 configurations that would overload a node. Additionally, policies to 1114 manage OAM resources may be used to provide some fairness in OAM 1115 resource distribution among monitored LSPs. 1117 Security of OAM protocols configured with extensions to LSP Ping 1118 described in this document are discussed in [RFC5880], [RFC5884], 1119 [RFC6374], [RFC6427], and [RFC6428]. 1121 In order that the configuration of OAM functionality can be achieved 1122 securely through the techniques described in this document, security 1123 mechanisms must already be in place and operational for LSP Ping. 1124 Thus the exchange of security parameters (such as keys) for use in 1125 securing OAM is outside the scope of this document and is assumed to 1126 use an off-line mechanism or an established secure key-exchange 1127 protocol. 1129 Additional discussion of security for MPLS protocols can be found in 1130 [RFC5920]. 1132 6. Acknowledgements 1134 The authors would like to thank Nobo Akiya, David Allan and Adrian 1135 Farrel for their thorough reviews and insightful comments. 1137 7. References 1139 7.1. Normative References 1141 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1142 Requirement Levels", BCP 14, RFC 2119, 1143 DOI 10.17487/RFC2119, March 1997, 1144 . 1146 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 1147 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1148 DOI 10.17487/RFC4379, February 2006, 1149 . 1151 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 1152 Sprecher, N., and S. Ueno, "Requirements of an MPLS 1153 Transport Profile", RFC 5654, DOI 10.17487/RFC5654, 1154 September 2009, . 1156 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1157 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 1158 . 1160 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 1161 "Bidirectional Forwarding Detection (BFD) for MPLS Label 1162 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 1163 June 2010, . 1165 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 1166 Profile (MPLS-TP) Identifiers", RFC 6370, 1167 DOI 10.17487/RFC6370, September 2011, 1168 . 1170 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 1171 Measurement for MPLS Networks", RFC 6374, 1172 DOI 10.17487/RFC6374, September 2011, 1173 . 1175 [RFC6427] Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed., 1176 Boutros, S., and D. Ward, "MPLS Fault Management 1177 Operations, Administration, and Maintenance (OAM)", 1178 RFC 6427, DOI 10.17487/RFC6427, November 2011, 1179 . 1181 [RFC6428] Allan, D., Ed., Swallow Ed., G., and J. Drake Ed., 1182 "Proactive Connectivity Verification, Continuity Check, 1183 and Remote Defect Indication for the MPLS Transport 1184 Profile", RFC 6428, DOI 10.17487/RFC6428, November 2011, 1185 . 1187 7.2. Informative References 1189 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1190 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1191 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1192 . 1194 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 1195 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 1196 October 2007, . 1198 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 1199 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 1200 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 1201 2009, . 1203 [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., 1204 "Requirements for Operations, Administration, and 1205 Maintenance (OAM) in MPLS Transport Networks", RFC 5860, 1206 DOI 10.17487/RFC5860, May 2010, 1207 . 1209 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 1210 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 1211 . 1213 [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, 1214 Administration, and Maintenance Framework for MPLS-Based 1215 Transport Networks", RFC 6371, DOI 10.17487/RFC6371, 1216 September 2011, . 1218 [RFC6375] Frost, D., Ed. and S. Bryant, Ed., "A Packet Loss and 1219 Delay Measurement Profile for MPLS-Based Transport 1220 Networks", RFC 6375, DOI 10.17487/RFC6375, September 2011, 1221 . 1223 [RFC6669] Sprecher, N. and L. Fang, "An Overview of the Operations, 1224 Administration, and Maintenance (OAM) Toolset for MPLS- 1225 Based Transport Networks", RFC 6669, DOI 10.17487/RFC6669, 1226 July 2012, . 1228 [RFC7419] Akiya, N., Binderberger, M., and G. Mirsky, "Common 1229 Interval Support in Bidirectional Forwarding Detection", 1230 RFC 7419, DOI 10.17487/RFC7419, December 2014, 1231 . 1233 [RFC7487] Bellagamba, E., Takacs, A., Mirsky, G., Andersson, L., 1234 Skoldstrom, P., and D. Ward, "Configuration of Proactive 1235 Operations, Administration, and Maintenance (OAM) 1236 Functions for MPLS-Based Transport Networks Using RSVP- 1237 TE", RFC 7487, DOI 10.17487/RFC7487, March 2015, 1238 . 1240 Authors' Addresses 1242 Elisa Bellagamba 1244 Email: elisa.bellagamba@gmail.com 1246 Gregory Mirsky 1247 Ericsson 1249 Email: Gregory.Mirsky@ericsson.com 1251 Loa Andersson 1252 Huawei Technologies 1254 Email: loa@mail01.huawei.com 1255 Pontus Skoldstrom 1256 Acreo AB 1257 Electrum 236 1258 Kista 164 40 1259 Sweden 1261 Phone: +46 8 6327731 1262 Email: pontus.skoldstrom@acreo.se 1264 Dave Ward 1265 Cisco 1267 Email: dward@cisco.com 1269 John Drake 1270 Juniper 1272 Email: jdrake@juniper.net