idnits 2.17.1 draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 25 pages 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 11, 2015) is 3393 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 (~~), 2 warnings (==), 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 G. Mirsky 4 Intended status: Standards Track Ericsson 5 Expires: July 15, 2015 L. Andersson 6 Huawei Technologies 7 P. Skoldstrom 8 Acreo AB 9 D. Ward 10 Cisco 11 J. Drake 12 Juniper 13 January 11, 2015 15 Configuration of Pro-Active Operations, Administration, and Maintenance 16 (OAM) Functions for MPLS-based Transport Networks using LSP Ping 17 draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08 19 Abstract 21 This specification describes the configuration of pro-active MPLS-TP 22 Operations, Administration, and Maintenance (OAM) Functions for a 23 given LSP using a set of TLVs that are carried by the LSP-Ping 24 protocol. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 15, 2015. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Conventions used in this document . . . . . . . . . . . . 4 62 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 4 63 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4 64 2. Theory of Operations . . . . . . . . . . . . . . . . . . . . 4 65 2.1. MPLS OAM Configuration Operation Overview . . . . . . . . 4 66 2.1.1. Configuration of BFD sessions . . . . . . . . . . . . 5 67 2.1.2. Configuration of Performance Monitoring . . . . . . . 6 68 2.1.3. Configuration of Fault Management Signals . . . . . . 6 69 2.2. MPLS OAM Functions TLV . . . . . . . . . . . . . . . . . 6 70 2.2.1. BFD Configuration sub-TLV . . . . . . . . . . . . . . 8 71 2.2.2. Local Discriminator sub-TLV . . . . . . . . . . . . . 10 72 2.2.3. Negotiation Timer Parameters sub-TLV . . . . . . . . 10 73 2.2.4. BFD Authentication sub-TLV . . . . . . . . . . . . . 12 74 2.2.5. Traffic Class sub-TLV . . . . . . . . . . . . . . . . 12 75 2.2.6. Performance Measurement sub-TLV . . . . . . . . . . . 13 76 2.2.7. PM Loss Measurement sub-TLV . . . . . . . . . . . . . 15 77 2.2.8. PM Delay Measurement sub-TLV . . . . . . . . . . . . 16 78 2.2.9. Fault Management Signal sub-TLV . . . . . . . . . . . 17 79 2.2.10. Source MEP-ID sub-TLV . . . . . . . . . . . . . . . . 18 80 3. Summary of MPLS OAM configuration errors . . . . . . . . . . 19 81 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 82 4.1. TLV and sub-TLV Allocation . . . . . . . . . . . . . . . 20 83 4.2. OAM configuration errors . . . . . . . . . . . . . . . . 21 84 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 86 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 7.1. Normative References . . . . . . . . . . . . . . . . . . 23 88 7.2. Informative References . . . . . . . . . . . . . . . . . 24 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 91 1. Introduction 93 This document describes the configuration of pro-active MPLS-TP 94 Operations, Administration, and Maintenance (OAM) Functions for a 95 given LSP using TLVs carried in LSP-Ping [RFC4379]. In particular it 96 specifies the mechanisms necessary to establish MPLS-TP OAM entities 97 at the maintenance points for monitoring and performing measurements 98 on an LSP, as well as defining information elements and procedures to 99 configure pro-active MPLS-TP OAM functions running between LERs. 100 Initialization and control of on-demand MPLS-TP OAM functions are 101 expected to be carried out by directly accessing network nodes via a 102 management interface; hence configuration and control of on-demand 103 OAM functions are out-of-scope for this document. 105 The Transport Profile of MPLS must, by definition [RFC5654], be 106 capable of operating without a control plane. Therefore there are 107 several options for configuring MPLS-TP OAM, without a control plane 108 by either using an NMS or LSP Ping, or with a control plane using 109 signaling protocols RSVP-TE [RFC3209] and/or T-LDP [RFC5036]. 111 MPLS Transport Profile (MPLS-TP) describes a profile of MPLS that 112 enables operational models typical in transport networks, while 113 providing additional OAM, survivability and other maintenance 114 functions not currently supported by MPLS. [RFC5860] defines the 115 requirements for the OAM functionality of MPLS-TP. 117 Pro-active MPLS-TP OAM is performed by set of protocols, Bi- 118 directional Forwarding Detection (BFD) [RFC6428] for Continuity 119 Check/Connectivity Verification, the delay measurement protocol (DM) 120 [RFC6374], [RFC6375] for delay and delay variation (jitter) 121 measurements, and the loss measurement (LM) protocol [RFC6374], 122 [RFC6375] for packet loss and throughput measurements. Additionally 123 there is a number of Fault Management Signals that can be configured. 125 BFD is a protocol that provides low-overhead, fast detection of 126 failures in the path between two forwarding engines, including the 127 interfaces, data link(s), and, to the extent possible, the forwarding 128 engines themselves. BFD can be used to detect the continuity and 129 mis-connection defects of MPLS-TP point-to-point and might also be 130 extended to support point-to-multipoint label switched paths (LSPs). 132 The delay and loss measurements protocols [RFC6374], [RFC6375] use a 133 simple query/response model for performing both uni- and bi- 134 directional measurements that allow the originating node to measure 135 packet loss and delay in forward or forward and reverse directions. 136 By timestamping and/or writing current packet counters to the 137 measurement packets at four times (Tx and Rx in both directions) 138 current delays and packet losses can be calculated. By performing 139 successive delay measurements the delay and/or inter-packet delay 140 variation (jitter) can be calculated. Current throughput can be 141 calculated from the packet loss measurements by dividing the number 142 of packets sent/received with the time it took to perform the 143 measurement, given by the timestamp in LM header. Combined with a 144 packet generator the throughput measurement can be used to measure 145 the maximum capacity of a particular LSP. It should be noted that 146 here we are not configuring on-demand throughput estimates based on 147 saturating the connection as defined in [RFC6371]. Rather, we only 148 enable the estimation of the current throughput based on loss 149 measurements. 151 1.1. Conventions used in this document 153 1.1.1. Terminology 155 BFD - Bidirectional Forwarding Detection 157 DM - Delay Measurement 159 FMS - Fault Management Signal 161 G-ACh - Generic Associated Channel 163 LSP - Label Switched Path 165 LM - Loss Measurement 167 MEP - Maintenance Entity Group End Point 169 MPLS - Multi-Protocol Label Switching 171 MPLS-TP - MPLS Transport Profile 173 PM - Performance Measurement 175 TC - Traffic Class 177 1.1.2. Requirements Language 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 181 document are to be interpreted as described in RFC 2119 [RFC2119]. 183 2. Theory of Operations 185 2.1. MPLS OAM Configuration Operation Overview 187 The MPLS-TP OAM tool set is described in the [RFC6669]. 189 LSP Ping, or alternatively RSVP-TE [RSVP-TE-CONF], can be used to 190 simply enable the different OAM functions, by setting the 191 corresponding flags in the MPLS OAM Functions TLV, Section 2.2. For 192 a more detailed configuration one may include sub-TLVs for the 193 different OAM functions in order to specify various parameters in 194 detail. 196 Typically intermediate nodes simply forward OAM configuration TLVs to 197 the end-node without any processing or modification At least one 198 exception to this is if the FMS sub-TLV Section 2.2.9 is present. 199 This sub-TLV has to be examined even by intermediate nodes. The sub- 200 TLV MAY be present if a flag is set in the MPLS OAM Functions TLV. 202 2.1.1. Configuration of BFD sessions 204 For this specification, BFD MUST run in either one of the two modes: 206 - Asynchronous mode, where both sides should be in active mode 208 - Unidirectional mode 210 In the simplest scenario LSP Ping [RFC5884], or alternatively RSVP-TE 211 [RSVP-TE-CONF], is used only to bootstrap a BFD session for an LSP, 212 without any timer negotiation. 214 Timer negotiation can be performed either in subsequent BFD control 215 messages (in this case the operation is similar to LSP Ping based 216 bootstrapping described in [RFC5884]) or directly in the LSP-Ping 217 configuration messages. 219 When BFD Control packets are transported in the ACH encapsulation 220 they are not protected by any end-to-end checksum, only lower-layers 221 are providing error detection/correction. A single bit error, e.g. a 222 flipped bit in the BFD State field could cause the receiving end to 223 wrongly conclude that the link is down and in turn trigger protection 224 switching. To prevent this from happening the BFD Configuration sub- 225 TLV, Section 2.2.1, has an Integrity flag that when set enables BFD 226 Authentication using Keyed SHA1 with an empty key (all 0s) [RFC5880]. 227 This would make every BFD Control packet carry an SHA1 hash of itself 228 that can be used to detect errors. 230 If BFD Authentication using a pre-shared key/password is desired 231 (i.e. authentication and not only error detection) the BFD 232 Authentication sub-TLV, Section 2.2.4, MUST be included in the BFD 233 Configuration sub-TLV. The BFD Authentication sub-TLV is used to 234 specify which authentication method that should be used and which 235 pre-shared key/ password that should be used for this particular 236 session. How the key exchange is performed is out of scope of this 237 document. 239 2.1.2. Configuration of Performance Monitoring 241 It is possible to configure Performance Monitoring functionalities 242 such as Loss, Delay, Delay/Interpacket Delay variation (jitter), and 243 Throughput as described in [RFC6374]. 245 When configuring Performance monitoring functionalities it is 246 possible to choose either the default configuration, by only setting 247 the respective flags in the MPLS OAM functions TLV, or a customized 248 configuration. To customize the configuration one would set the 249 respective flags in the including the respective Loss and/or Delay 250 sub-TLVs). 252 By setting the PM Loss flag in the MPLS OAM Functions TLV and 253 including the PM Loss sub-TLV, Section 2.2.7, one can configure the 254 measurement interval and loss threshold values for triggering 255 protection. 257 Delay measurements are configured by setting PM Delay flag in the 258 MPLS OAM Functions TLV and including the PM Delay sub-TLV, 259 Section 2.2.8, one can configure the measurement interval and the 260 delay threshold values for triggering protection. 262 2.1.3. Configuration of Fault Management Signals 264 To configure Fault Management Signals (FMS) and their refresh time 265 the FMS flag in the MPLS OAM Functions TLV MUST be set and the FMS 266 sub-TLV MUST be included. When configuring FMS, an implementation 267 can enable the default configuration by setting the FMS flag in the 268 OAM Function Flags sub-TLV. In order to modify the default 269 configuration the MPLS OAM FMS sub-TLV MUST be included. 271 If an intermediate point is meant to originate fault management 272 signal messages this means that such an intermediate point is 273 associated with a Server MEP through a co-located MPLS-TP client/ 274 server adaptation function and the Fault Management subscription flag 275 in the MPLS OAM FMS sub-TLV been set as indication of the request to 276 create the association at each intermediate node of the client LSP. 277 Corresponding Server MEP needs to be configured by its own LSP-ping 278 session or, alternatively, via an NMS or RSVP-TE. 280 2.2. MPLS OAM Functions TLV 282 The MPLS OAM Functions TLV presented in Figure 1 is carried as a TLV 283 of the MPLS Echo Request/Reply messages [RFC4379]. 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | MPLS OAM Func. Type (TBA1) | Length | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 |C|V|F|L|D|T| Reserved (MBZ) | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | | 293 ~ sub-TLVs ~ 294 | | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 Figure 1: MPLS OAM Functions TLV format 299 The MPLS OAM Functions TLV contains a number of flags indicating 300 which OAM functions should be activated as well as OAM function 301 specific sub-TLVs with configuration parameters for the particular 302 function. 304 Type: indicates the MPLS OAM Functions TLV Section 4. 306 Length: the length of the MPLS OAM Function Flags field including the 307 total length of the sub-TLVs in octets. 309 MPLS OAM Function Flags: a bitmap numbered from left to right as 310 shown in the figure. 312 These flags are defined in this document as presented in Table 1: 314 +------------+--------------------+---------------------------------+ 315 | Bit | MPLS OAM Function | Description | 316 | Position | Flag | | 317 +------------+--------------------+---------------------------------+ 318 | 0 | C | Continuity Check (CC) | 319 | 1 | V | Connectivity Verification (CV) | 320 | 2 | F | Fault Management Signal (FMS) | 321 | 3 | L | Performance Measurement/Loss | 322 | | | (PM/Loss) | 323 | 4 | D | Performance Measurement/Delay | 324 | | | (PM/Delay) | 325 | 5 | T | Throughput Measurement) | 326 | 6-31 | | Reserved | 327 +------------+--------------------+---------------------------------+ 329 Table 1: MPLS OAM TLV Flags 331 Sub-TLVs corresponding to the different flags are as follows: 333 - BFD Configuration sub-TLV, which MUST be included if the CC and/ 334 or the CV OAM Function flag is set. This sub-TLV MUST carry a 335 "BFD Local Discriminator sub-TLV" and a "Timer Negotiation 336 Parameters sub-TLV" if the N flag is cleared. The "Source MEP-ID 337 sub-TLV" MUST also be included. If the I flag is set, the "BFD 338 Authentication sub-TLV" MAY be included. 340 - PM Loss sub-TLV within the "Performance Monitoring sub-TLV", 341 which MAY be included if the PM/Loss OAM Function flag is set. If 342 the "PM Loss sub-TLV" is not included, default configuration 343 values are used. Such sub-TLV MAY also be included in case the 344 Throughput function flag is set and there is the need to specify 345 measurement interval different from the default ones. In fact the 346 throughput measurement make use of the same tool as the loss 347 measurement, hence the same TLV is used. 349 - PM Delay sub-TLV within the "Performance Monitoring sub-TLV", 350 which MAY be included if the PM/Delay OAM Function flag is set. 351 If the "PM Delay sub-TLV" is not included, default configuration 352 values are used. 354 - FMS sub-TLV, which MAY be included if the FMS OAM Function flag 355 is set. If the "FMS sub-TLV" is not included, default 356 configuration values are used. 358 2.2.1. BFD Configuration sub-TLV 360 The BFD Configuration sub-TLV, depicted Figure 2, is defined for BFD 361 OAM specific configuration parameters. The "BFD Configuration sub- 362 TLV" is carried as a sub-TLV of the "OAM Functions TLV". 364 This TLV accommodates generic BFD OAM information and carries sub- 365 TLVs. 367 0 1 2 3 368 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | BFD Conf. sub-Type (100) | Length | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 |Vers.|N|S|I|G|U|B| Reserved (set to all 0s) | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | | 375 ~ sub-TLVs ~ 376 | | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 Figure 2: BFD Configuration sub-TLV format 381 Sub-type: indicates a new sub-type, the BFD Configuration sub-TLV 382 (value 100). 384 Length: indicates the length of the Value field in octets (4). 386 Version: identifies the BFD protocol version. If a node does not 387 support a specific BFD version an error must be generated: "OAM 388 Problem/Unsupported OAM Version". 390 BFD Negotiation (N): If set timer negotiation/re-negotiation via BFD 391 Control Messages is enabled, when cleared it is disabled. 393 Symmetric session (S): If set the BFD session MUST use symmetric 394 timing values. 396 Integrity (I): If set BFD Authentication MUST be enabled. If the BFD 397 Configuration sub-TLV does not include a BFD Authentication sub-TLV 398 the authentication MUST use Keyed SHA1 with an empty pre-shared key 399 (all 0s). If the egress LSR does not support BFD Authentication an 400 error MUST be generated: "OAM Problem/BFD Authentication 401 unsupported". 403 Encapsulation Capability (G): if set, it shows the capability of 404 encapsulating BFD messages into G-ACh channel. If both the G bit and 405 U bit are set, configuration gives precedence to the G bit. 407 Encapsulation Capability (U): if set, it shows the capability of 408 encapsulating BFD messages into IP/UDP packets. If both the G bit 409 and U bit are set, configuration gives precedence to the G bit. 411 If the egress LSR does not support any of the ingress LSR 412 Encapsulation Capabilities an error MUST be generated: "OAM Problem/ 413 Unsupported BFD Encapsulation format". 415 Bidirectional (B): if set, it configures BFD in the Bidirectional 416 mode. If it is not set it configures BFD in unidirectional mode. In 417 the second case, the source node does not expect any Discriminator 418 values back from the destination node. 420 Reserved: Reserved for future specification and set to 0 on 421 transmission and ignored when received. 423 The BFD Configuration sub-TLV MUST include the following sub-TLVs in 424 the MPLS Echo Request message: 426 - Local Discriminator sub-TLV, if B flag is set in the MPLS Echo 427 Request; 428 - Negotiation Timer Parameters sub-TLV if the N flag is cleared. 430 The BFD Configuration sub-TLV MUST include the following sub-TLVs in 431 the MPLS Echo Reply message: 433 - Local Discriminator sub-TLV; 435 - Negotiation Timer Parameters sub-TLV if: 437 - the N and S flags are cleared, or if: 439 - the N flag is cleared and the S flag is set, and the 440 Negotiation Timer Parameters sub-TLV received by the egress 441 contains unsupported values. In this case an updated 442 Negotiation Timer Parameters sub-TLV, containing values 443 supported by the egress node, is returned to the ingress. 445 2.2.2. Local Discriminator sub-TLV 447 The Local Discriminator sub-TLV is carried as a sub-TLV of the "BFD 448 Configuration sub-TLV" and is depicted in Figure 3. 450 0 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Lcl. Discr. sub-Type (101) | Length | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Local Discriminator | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Figure 3: Local Discriminator sub-TLV format 460 Type: indicates a new type, the "Local Discriminator sub-TLV" (value 461 101). 463 Length: indicates the length of the Value field in octets . (4) 465 Local Discriminator: A unique, nonzero discriminator value generated 466 by the transmitting system and referring to itself, used to 467 demultiplex multiple BFD sessions between the same pair of systems. 469 2.2.3. Negotiation Timer Parameters sub-TLV 471 The Negotiation Timer Parameters sub-TLV is carried as a sub-TLV of 472 the BFD Configuration sub-TLV and is depicted in Figure 4. 474 0 1 2 3 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Nego. Timer sub-type (102) | Length | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Acceptable Min. Asynchronous TX interval | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Acceptable Min. Asynchronous RX interval | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Required Echo TX Interval | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Figure 4: Negotiation Timer Parameters sub-TLV format 488 Sub-type: indicates a new sub-type, the Negotiation Timer Parameters 489 sub-TLV (value 102). 491 Length: indicates the length of the Value field in octets (12). 493 Acceptable Min. Asynchronous TX interval: in case of S (symmetric) 494 flag set in the BFD Configuration sub-TLV, defined in Section 2.2.1, 495 it expresses the desired time interval (in microseconds) at which the 496 ingress LER intends to both transmit and receive BFD periodic control 497 packets. If the receiving edge LSR cannot support such value, it 498 SHOULD reply with an interval greater than the one proposed. 500 In case of S (symmetric) flag cleared in the BFD Configuration sub- 501 TLV, this field expresses the desired time interval (in microseconds) 502 at which a edge LSR intends to transmit BFD periodic control packets 503 in its transmitting direction. 505 Acceptable Min. Asynchronous RX interval: in case of S (symmetric) 506 flag set in the BFD Configuration sub-TLV, Figure 2, this field MUST 507 be equal to Acceptable Min. Asynchronous TX interval and has no 508 additional meaning respect to the one described for "Acceptable Min. 509 Asynchronous TX interval". 511 In case of S (symmetric) flag cleared in the BFD Configuration sub- 512 TLV, it expresses the minimum time interval (in microseconds) at 513 which edge LSRs can receive BFD periodic control packets. In case 514 this value is greater than the value of Acceptable Min. Asynchronous 515 TX interval received from the other edge LSR, such edge LSR MUST 516 adopt the interval expressed in this Acceptable Min. Asynchronous RX 517 interval. 519 Required Echo TX Interval: the minimum interval (in microseconds) 520 between received BFD Echo packets that this system is capable of 521 supporting, less any jitter applied by the sender as described in 523 [RFC5880] sect. 6.8.9. This value is also an indication for the 524 receiving system of the minimum interval between transmitted BFD Echo 525 packets. If this value is zero, the transmitting system does not 526 support the receipt of BFD Echo packets. If the receiving system 527 cannot support this value the "Unsupported BFD TX Echo rate interval" 528 error MUST be generated. By default the value is set to 0. 530 2.2.4. BFD Authentication sub-TLV 532 The "BFD Authentication sub-TLV" is carried as a sub-TLV of the "BFD 533 Configuration sub-TLV" and is depicted in Figure 5. 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | BFD Auth. sub-type (103) | Length | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Auth Type | Auth Key ID | Reserved (0s) | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 Figure 5: BFD Authentication sub-TLV format 545 Sub-type: indicates a new type, the BFD Authentication sub-TLV (value 546 103). 548 Length: indicates the length of the Value field in octets (4). 550 Auth Type: indicates which type of authentication to use. The same 551 values as are defined in section 4.1 of [RFC5880] are used. 553 Auth Key ID: indicates which authentication key or password 554 (depending on Auth Type) should be used. How the key exchange is 555 performed is out of scope of this document. If the egress LSR does 556 not support this Auth Key ID an "OAM Problem/Mismatch of BFD 557 Authentication Key ID" error MUST be generated. 559 Reserved: Reserved for future specification and set to 0 on 560 transmission and ignored when received. 562 2.2.5. Traffic Class sub-TLV 564 The Traffic Class sub-TLV is carried as a sub-TLV of the "BFD 565 Configuration sub-TLV" or "Fault Management Signal sub-TLV" 566 Section 2.2.9 and is depicted in Figure 6. 568 0 1 2 3 569 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 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Traffic Class sub-Type (104) | Length | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | TC | Reserved (set to all 0s) | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 Figure 6: Traffic Class sub-TLV format 578 Type: indicates a new type, the "Traffic Class sub-TLV" (value 104). 580 Length: indicates the length of the Value field in octets . (4) 582 TC: Identifies the Traffic Class (TC) [RFC5462] for periodic 583 continuity monitoring messages or packets with fault management 584 information. 586 If TC sub-TLV is present, then the value of the TC field MUST be used 587 as the value of the TC field of an MPLS label stack entry. If the TC 588 sub-TLV is absent from "BFD Configuration sub-TLV" or "Fault 589 Management Signal sub-TLV", then selection of the TC value is local 590 decision. 592 2.2.6. Performance Measurement sub-TLV 594 If the MPLS OAM Functions TLV has either the L (Loss), D (Delay) or T 595 (Throughput) flag set, the Performance Measurement sub-TLV MUST be 596 present. Failure to include the correct sub-TLVs MUST result in an 597 "OAM Problem/ Configuration Error" error being generated. 599 The Performance Measurement sub-TLV provides the configuration 600 information mentioned in Section 7 of [RFC6374]. It includes support 601 for the configuration of quality thresholds and, as described in 602 [RFC6374], "the crossing of which will trigger warnings or alarms, 603 and result reporting and exception notification will be integrated 604 into the system-wide network management and reporting framework." 606 In case the values need to be different than the default ones the 607 Performance Measurement sub-TLV MAY include the following sub-TLVs: 609 - PM Loss sub-TLV if the L flag is set in the MPLS OAM Functions 610 TLV; 612 - PM Delay sub-TLV if the D flag is set in the MPLS OAM Functions 613 TLV. 615 The Performance Measurement sub-TLV depicted in Figure 7 is carried 616 as a sub-TLV of the MPLS OAM Functions TLV. 618 0 1 2 3 619 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 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Perf Monitoring Type (200) | Length | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 |D|L|J|Y|K|C| Reserved (set to all 0s) | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 Figure 7: Performance Measurement sub-TLV format 628 Sub-type: indicates a new sub-type, the Performance Management sub- 629 TLV" (value 200). 631 Length: indicates the length of the Value field in octets (4). 633 Configuration Flags, for the specific function description please 634 refer to [RFC6374]: 636 - D: Delay inferred/direct (0=INFERRED, 1=DIRECT). If the egress 637 LSR does not support specified mode an "OAM Problem/Unsupported 638 Delay Mode" error MUST be generated. 640 - L: Loss inferred/direct (0=INFERRED, 1=DIRECT). If the egress 641 LSR does not support specified mode an "OAM Problem/Unsupported 642 Loss Mode" error MUST be generated. 644 - J: Delay variation/jitter (1=ACTIVE, 0=NOT ACTIVE). If the 645 egress LSR does not support Delay variation measurements and the J 646 flag is set, an "OAM Problem/Delay variation unsupported" error 647 MUST be generated. 649 - Y: Dyadic (1=ACTIVE, 0=NOT ACTIVE). If the egress LSR does not 650 support Dyadic mode and the Y flag is set, an "OAM Problem/Dyadic 651 mode unsupported" error MUST be generated. 653 - K: Loopback (1=ACTIVE, 0=NOT ACTIVE). If the egress LSR does 654 not support Loopback mode and the K flag is set, an "OAM Problem/ 655 Loopback mode unsupported" error MUST be generated. 657 - C: Combined (1=ACTIVE, 0=NOT ACTIVE). If the egress LSR does 658 not support Combined mode and the C flag is set, an "OAM Problem/ 659 Combined mode unsupported" error MUST be generated. 661 Reserved: Reserved for future specification and set to 0 on 662 transmission and ignored when received. 664 2.2.7. PM Loss Measurement sub-TLV 666 The PM Loss Measurement sub-TLV depicted in Figure 8 is carried as a 667 sub-TLV of the Performance Measurement sub-TLV. 669 0 1 2 3 670 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 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | PM Loss sub-type (201) | Length | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | OTF |T|B| Reserved (set to all 0s) | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | Measurement Interval | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Test Interval | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | Loss Threshold | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 Figure 8: PM Loss Measurement sub-TLV format 685 Sub-type: indicates a new sub-type, the PM Loss Measurement sub-TLV 686 (value 201). 688 Length: indicates the length of the Value field in octets (16). 690 OTF: Origin Timestamp Format of the Origin Timestamp field described 691 in [RFC6374]. By default it is set to IEEE 1588 version 1. If the 692 egress LSR cannot support this value an "OAM Problem/Unsupported 693 Timestamp Format" error MUST be generated. 695 Configuration Flags, please refer to [RFC6374] for further details: 697 - T: Traffic-class-specific measurement indicator. Set to 1 when 698 the measurement operation is scoped to packets of a particular 699 traffic class (DSCP value), and 0 otherwise. When set to 1, the 700 DS field of the message indicates the measured traffic class. By 701 default it is set to 1. 703 - B: Octet (byte) count. When set to 1, indicates that the 704 Counter 1-4 fields represent octet counts. When set to 0, 705 indicates that the Counter 1-4 fields represent packet counts. By 706 default it is set to 0. 708 Reserved: Reserved for future specification and set to 0 on 709 transmission and ignored when received. 711 Measurement Interval: the time interval (in milliseconds) at which 712 Loss Measurement query messages MUST be sent on both directions. If 713 the edge LSR receiving the Path message cannot support such value, it 714 SHOULD reply with a higher interval. By default it is set to (100) 715 as per [RFC6375]. 717 Test Interval: test messages interval in milliseconds as described in 718 [RFC6374]. By default it is set to (10) as per [RFC6375]. 720 Loss Threshold: the threshold value of measured lost packets per 721 measurement over which action(s) SHOULD be triggered. 723 2.2.8. PM Delay Measurement sub-TLV 725 The PM Delay Measurement sub-TLV" depicted in Figure 9 is carried as 726 a sub-TLV of the Performance Monitoring sub-TLV. 728 0 1 2 3 729 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 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | PM Delay Type (202) | Length | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | OTF |T|B| Reserved (set to all 0s) | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Measurement Interval | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Test Interval | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Delay Threshold | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 Figure 9: PM Delay Measurement sub-TLV format 744 Sub-type: indicates a new sub-type, the PM Delay Measurement sub-TLV" 745 (value 202). 747 Length: indicates the length of the Value field in octets (16). 749 OTF: Origin Timestamp Format of the Origin Timestamp field described 750 in [RFC6374]. By default it is set to IEEE 1588 version 1. If the 751 egress LSR cannot support this value an "OAM Problem/Unsupported 752 Timestamp Format" error MUST be generated. 754 Configuration Flags, please refer to [RFC6374] for further details: 756 - T: Traffic-class-specific measurement indicator. Set to 1 when 757 the measurement operation is scoped to packets of a particular 758 traffic class (DSCP value), and 0 otherwise. When set to 1, the 759 DS field of the message indicates the measured traffic class. By 760 default it is set to 1. 762 - B: Octet (byte) count. When set to 1, indicates that the 763 Counter 1-4 fields represent octet counts. When set to 0, 764 indicates that the Counter 1-4 fields represent packet counts. By 765 default it is set to 0. 767 Reserved: Reserved for future specification and set to 0 on 768 transmission and ignored when received. 770 Measurement Interval: the time interval (in milliseconds) at which 771 Delay Measurement query messages MUST be sent on both directions. If 772 the edge LSR receiving the Path message cannot support such value, it 773 can reply with a higher interval. By default it is set to (1000) as 774 per [RFC6375]. 776 Test Interval: test messages interval (in milliseconds) as described 777 in [RFC6374]. By default it is set to (10) as per [RFC6375]. 779 Delay Threshold: the threshold value of measured two-way delay (in 780 milliseconds) over which action(s) SHOULD be triggered. 782 2.2.9. Fault Management Signal sub-TLV 784 The FMS sub-TLV depicted in Figure 10 is carried as a sub-TLV of the 785 MPLS OAM Configuration sub-TLV. When both working and protection 786 paths are configured, both LSPs SHOULD be configured with identical 787 settings of the E flag, T flag, and the refresh timer. 789 0 1 2 3 790 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | FMS sub-type (300) | Length | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 |E|S|T| Reserved | Refresh Timer | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | | 797 ~ sub-TLVs ~ 798 | | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 Figure 10: Fault Management Signal sub-TLV format 803 Sub-type: indicates a new sub-type, the FMS sub-TLV (value 300). 805 Length: indicates the length of the Value field in octets (4). 807 FMS Signal Flags are used to enable the FMS signals at end point MEPs 808 and the Server MEPs of the links over which the LSP is forwarded. In 809 this document only the S flag pertains to Server MEPs. 811 The following flags are defined: 813 - E: Enable Alarm Indication Signal (AIS) and Lock Report (LKR) 814 signaling as described in [RFC6427]. Default value is 1 815 (enabled). If the egress MEP does not support FMS signal 816 generation an "OAM Problem/Fault management signaling unsupported" 817 error MUST be generated. 819 - S: Indicate to a server MEP that it should transmit AIS and LKR 820 signals on the client LSP. Default value is 0 (disabled). If a 821 Server MEP which is capable of generating FMS messages is for some 822 reason unable to do so for the LSP being signaled an "OAM Problem/ 823 Unable to create fault management association" error MUST be 824 generated. 826 - T: Set timer value, enabled the configuration of a specific 827 timer value. Default value is 0 (disabled). 829 - Remaining bits: Reserved for future specification and set to 0. 831 Refresh Timer: indicates the refresh timer of fault indication 832 messages, in seconds. The value MUST be between 1 to 20 seconds as 833 specified for the Refresh Timer field in [RFC6427]. If the edge LSR 834 receiving the Path message cannot support the value it SHOULD reply 835 with a higher timer value. 837 FMS sub-TLV MAY include Traffic Class sub-TLV Section 2.2.5. If TC 838 sub-TLV is present, the value of the TC field MUST be used as the 839 value of the TC field of an MPLS label stack entry for FMS messages. 840 If the TC sub-TLV is absent, then selection of the TC value is local 841 decision. 843 2.2.10. Source MEP-ID sub-TLV 845 The Source MEP-ID sub-TLV depicted in Figure 11 is carried as a sub- 846 TLV of the MPLS OAM Functions TLV. 848 Note that support of ITU IDs is out-of-scope. 850 0 1 2 3 851 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 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Source MEP-ID sub-type (400) | Length | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Source Node ID | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Tunnel ID | LSP ID | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 Figure 11: Source MEP-ID sub-TLV format 862 Sub-type: indicates a new sub-type, the Source MEP-ID sub-TLV (value 863 400). 865 Length: indicates the length of the Value field in octets (8). 867 Source Node ID: 32-bit node identifier as defined in [RFC6370]. 869 Tunnel ID: a 16-bit unsigned integer unique to the node as defined in 870 [RFC6370]. 872 LSP ID: a 16-bit unsigned integer unique within the Tunnel_ID as 873 defined in [RFC6370]. 875 3. Summary of MPLS OAM configuration errors 877 This is the summary of Return Codes [RFC4379] defined in this 878 document: 880 - If an egress LSR does not support the specified BFD version, an 881 error MUST be generated: "OAM Problem/Unsupported BFD Version". 883 - If an egress LSR does not support the specified BFD 884 Encapsulation format, an error MUST be generated: "OAM Problem/ 885 Unsupported BFD Encapsulation format". 887 - If an egress LSR does not support BFD Authentication, and it is 888 requested, an error MUST be generated: "OAM Problem/BFD 889 Authentication unsupported". 891 - If an egress LSR does not support the specified BFD 892 Authentication Type, an error MUST be generated: "OAM Problem/ 893 Unsupported BFD Authentication Type". 895 - If an egress LSR is not able to use the specified Authentication 896 Key ID, an error MUST be generated: "OAM Problem/Mismatch of BFD 897 Authentication Key ID". 899 - If an egress LSR does not support the specified Timestamp 900 Format, an error MUST be generated: "OAM Problem/Unsupported 901 Timestamp Format". 903 - If an egress LSR does not support specified Delay mode, an "OAM 904 Problem/Unsupported Delay Mode" error MUST be generated. 906 - If an egress LSR does not support specified Loss mode, an "OAM 907 Problem/Unsupported Loss Mode" error MUST be generated. 909 - If an egress LSR does not support Delay variation measurements, 910 and it is requested, an "OAM Problem/Delay variation unsupported" 911 error MUST be generated. 913 - If an egress LSR does not support Dyadic mode, and it is 914 requested, an "OAM Problem/Dyadic mode unsupported" error MUST be 915 generated. 917 - If an egress LSR does not support Loopback mode, and it is 918 requested, an "OAM Problem/Loopback mode unsupported" error MUST 919 be generated. 921 - If an egress LSR does not support Combined mode, and it is 922 requested, an "OAM Problem/Combined mode unsupported" error MUST 923 be generated. 925 - If an egress LSR does not support Fault Monitoring Signals, and 926 it is requested, an "OAM Problem/Fault management signaling 927 unsupported" error MUST be generated. 929 - If an intermediate server MEP supports Fault Monitoring Signals 930 but is unable to create an association, when requested to do so, 931 an "OAM Problem/Unable to create fault management association" 932 error MUST be generated. 934 4. IANA Considerations 936 4.1. TLV and sub-TLV Allocation 938 IANA maintains the Multi-Protocol Label Switching (MPLS) Label 939 Switched Paths (LSPs) Ping Parameters registry, and within that 940 registry a sub-registry for TLVs and sub-TLVs. 942 IANA is requested a new TLV from the standards action range (0-16383) 943 and sub-TLVs as follows from this sub-registry. 945 +------+----------+---------------------------------+---------------+ 946 | Type | Sub-type | Value Field | Reference | 947 +------+----------+---------------------------------+---------------+ 948 | TBA1 | | MPLS OAM Functions | This document | 949 | | 100 | BFD Configuration | This document | 950 | | 101 | BFD Local Discriminator | This document | 951 | | 102 | BFD Negotiation Timer | This document | 952 | | | Parameters | | 953 | | 103 | BFD Authentication | This document | 954 | | 104 | Traffic Class | This document | 955 | | 200 | Performance Measurement | This document | 956 | | 201 | PM Loss Measurement | This document | 957 | | 202 | PM Delay Measurement | This document | 958 | | 203 | Fault Management Signal | This document | 959 | | 204 | Source MEP-ID | This document | 960 +------+----------+---------------------------------+---------------+ 962 Table 2: IANA TLV Type Allocation 964 4.2. OAM configuration errors 966 IANA maintains a registry "Multi-Protocol Label Switching (MPLS) 967 Label Switched Paths (LSPs) Ping Parameters" registry, and within 968 that registry a sub-registry "Return Codes". 970 IANA is requested to assign new Return Codes from the Standards 971 Action range (0-191) as follows: 973 +---------------+-----------------------------------+---------------+ 974 | Error Value | Description | Reference | 975 | Sub-codes | | | 976 +---------------+-----------------------------------+---------------+ 977 | TBA3 | OAM Problem/Unsupported BFD | This document | 978 | | Version | | 979 | TBA4 | OAM Problem/Unsupported BFD | This document | 980 | | Encapsulation format | | 981 | TBA5 | OAM Problem/Unsupported BFD | This document | 982 | | Authentication Type | | 983 | TBA6 | OAM Problem/Mismatch of BFD | This document | 984 | | Authentication Key ID | | 985 | TBA7 | OAM Problem/Unsupported Timestamp | This document | 986 | | Format | | 987 | TBA8 | OAM Problem/Unsupported Delay | This document | 988 | | Mode | | 989 | TBA9 | OAM Problem/Unsupported Loss Mode | This document | 990 | TBA10 | OAM Problem/Delay variation | This document | 991 | | unsupported | | 992 | TBA11 | OAM Problem/Dyadic mode | This document | 993 | | unsupported | | 994 | TBA12 | OAM Problem/Loopback mode | This document | 995 | | unsupported | | 996 | TBA13 | OAM Problem/Combined mode | This document | 997 | | unsupported | | 998 | TBA14 | OAM Problem/Fault management | This document | 999 | | signaling unsupported | | 1000 | TBA15 | OAM Problem/Unable to create | This document | 1001 | | fault management association | | 1002 +---------------+-----------------------------------+---------------+ 1004 Table 3: IANA Return Codes Allocation 1006 5. Acknowledgements 1008 The authors would like to thank Nobo Akiya for his useful comments. 1010 6. Security Considerations 1012 The signaling of OAM related parameters and the automatic 1013 establishment of OAM entities introduces additional security 1014 considerations to those discussed in [RFC3473]. In particular, a 1015 network element could be overloaded if an attacker were to request 1016 high frequency liveliness monitoring of a large number of LSPs, 1017 targeting a single network element. 1019 7. References 1021 7.1. Normative References 1023 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1024 Requirement Levels", BCP 14, RFC 2119, March 1997. 1026 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 1027 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1028 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 1030 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 1031 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1032 February 2006. 1034 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 1035 and S. Ueno, "Requirements of an MPLS Transport Profile", 1036 RFC 5654, September 2009. 1038 [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for 1039 Operations, Administration, and Maintenance (OAM) in MPLS 1040 Transport Networks", RFC 5860, May 2010. 1042 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1043 (BFD)", RFC 5880, June 2010. 1045 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 1046 "Bidirectional Forwarding Detection (BFD) for MPLS Label 1047 Switched Paths (LSPs)", RFC 5884, June 2010. 1049 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 1050 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 1052 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 1053 Measurement for MPLS Networks", RFC 6374, September 2011. 1055 [RFC6427] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S., 1056 and D. Ward, "MPLS Fault Management Operations, 1057 Administration, and Maintenance (OAM)", RFC 6427, November 1058 2011. 1060 [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive 1061 Connectivity Verification, Continuity Check, and Remote 1062 Defect Indication for the MPLS Transport Profile", RFC 1063 6428, November 2011. 1065 7.2. Informative References 1067 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1068 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1069 Tunnels", RFC 3209, December 2001. 1071 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1072 Specification", RFC 5036, October 2007. 1074 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 1075 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 1076 Class" Field", RFC 5462, February 2009. 1078 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 1079 Maintenance Framework for MPLS-Based Transport Networks", 1080 RFC 6371, September 2011. 1082 [RFC6375] Frost, D. and S. Bryant, "A Packet Loss and Delay 1083 Measurement Profile for MPLS-Based Transport Networks", 1084 RFC 6375, September 2011. 1086 [RFC6669] Sprecher, N. and L. Fang, "An Overview of the Operations, 1087 Administration, and Maintenance (OAM) Toolset for MPLS- 1088 Based Transport Networks", RFC 6669, July 2012. 1090 [RSVP-TE-CONF] 1091 Bellagamba, E., Andersson, L., Ward, D., and P. 1092 Skoldstrom, "Configuration of pro-active MPLS-TP 1093 Operations, Administration, and Maintenance (OAM) 1094 Functions Using RSVP-TE", 2012, . 1097 Authors' Addresses 1099 Elisa Bellagamba 1100 Ericsson 1102 Email: elisa.bellagamba@ericsson.com 1104 Gregory Mirsky 1105 Ericsson 1107 Email: Gregory.Mirsky@ericsson.com 1108 Loa Andersson 1109 Huawei Technologies 1111 Email: loa@mail01.huawei.com 1113 Pontus Skoldstrom 1114 Acreo AB 1115 Electrum 236 1116 Kista 164 40 1117 Sweden 1119 Phone: +46 8 6327731 1120 Email: pontus.skoldstrom@acreo.se 1122 Dave Ward 1123 Cisco 1125 Email: dward@cisco.com 1127 John Drake 1128 Juniper 1130 Email: jdrake@juniper.net