idnits 2.17.1 draft-ietf-mpls-tp-fault-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The MPLS Fault Management channel is identified by the ACH as defined in RFC 5586 [4] with the Channel Type set to the MPLS Fault Management (FM) code point = 0xHH. [HH to be assigned by IANA from the PW Associated Channel Type registry. Note: An early codepoint allocation has made: 0x0058 Fault OAM (TEMPORARY - expires 2011-07-16)] The FM Channel does not use ACH TLVs and MUST not include the ACH TLV header. The FM ACH Channel is shown below. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Service disruptive conditions are indicated by sending FM messages. The message type is set to the value corresponding to the condition. The refresh timer is set to the maximum time between successive FM messages. This value MUST not be changed on successive FM messages. If the optional clearing procedures are not used, then the default value is 1. Otherwise the default value is 20. -- The document date (October 25, 2010) is 4929 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) == Outdated reference: A later version (-07) exists of draft-ietf-mpls-tp-identifiers-03 ** Obsolete normative reference: RFC 5226 (ref. '6') (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group G. Swallow, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track A. Fulignoli, Ed. 5 Expires: April 28, 2011 Ericsson 6 M. Vigoureux, Ed. 7 Alcatel-Lucent 8 S. Boutros 9 Cisco Systems, Inc. 10 D. Ward 11 Juniper Networks, Inc. 13 October 25, 2010 15 MPLS Fault Management OAM 16 draft-ietf-mpls-tp-fault-03 18 Abstract 20 This draft specifies OAM messages to indicate service disruptive 21 conditions for MPLS Transport Profile (MPLS-TP) Label Switched Paths 22 (LSPs). The notification mechanism employs a generic method for a 23 service disruptive condition to be communicated to a Maintenance End 24 Point (MEP). An MPLS Operation, Administration, and Maintenance 25 (OAM) channel is defined along with messages to communicate various 26 types of service disruptive conditions. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 28, 2011. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. MPLS Fault Management Messages . . . . . . . . . . . . . . . . 4 65 2.1. MPLS-TP Alarm Indication Signal . . . . . . . . . . . . . 5 66 2.1.1. MPLS-TP Link Down Indication . . . . . . . . . . . . . 5 67 2.2. MPLS-TP Lock Report . . . . . . . . . . . . . . . . . . . 6 68 3. MPLS Fault Management Channel . . . . . . . . . . . . . . . . 6 69 4. MPLS Fault Management Message Format . . . . . . . . . . . . . 7 70 4.1. Fault Management Message TLVs . . . . . . . . . . . . . . 8 71 4.1.1. Interface Identifier TLV . . . . . . . . . . . . . . . 9 72 4.1.2. Global Identifier . . . . . . . . . . . . . . . . . . 10 73 4.1.3. International Carrier Code . . . . . . . . . . . . . . 10 74 5. Sending and Receiving Fault Management Messages . . . . . . . 10 75 5.1. Sending a Fault Management Message . . . . . . . . . . . . 10 76 5.2. Clearing a FM Indication . . . . . . . . . . . . . . . . . 11 77 5.3. Receiving a FM Indication . . . . . . . . . . . . . . . . 11 78 6. Minimum Implementation Requirements . . . . . . . . . . . . . 11 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 8.1. Pseudowire Associated Channel Type . . . . . . . . . . . . 12 82 8.2. MPLS Fault OAM Message Type Registry . . . . . . . . . . . 12 83 8.3. MPLS Fault OAM TLV Registry . . . . . . . . . . . . . . . 13 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 86 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 89 1. Introduction 91 In traditional transport networks, circuits such as T1 lines are 92 provisioned on multiple switches. When a disruption occurs on any 93 link or node along the path of such a transport circuit, OAM are 94 generated which may in turn suppress alarms and/or activate a backup 95 circuit. The MPLS Transport Profile (MPLS-TP) provides mechanisms to 96 emulate traditional transport circuits. Therefore a Fault Management 97 (FM) capability must be defined for MPLS. This capability is being 98 defined to meet the MPLS-TP requirements as defined in RFC 5654 [1], 99 and the MPLS-TP Operations, Administration and Maintenance 100 Requirements as defined in RFC 5860 [2]. However, this mechanism is 101 intended to be applicable to other aspects of MPLS as well. 103 Two broad classes of service disruptive conditions are identified. 105 1. Defect: the situation in which the density of anomalies has 106 reached a level where the ability to perform a required function 107 has been interrupted. 109 2. Lock: an administrative status in which it is expected that only 110 test traffic, if any, and OAM (dedicated to the LSP) can be sent 111 on an LSP. 113 Within the Defect class, a further category, Fault is identified. A 114 fault is the inability of a function to perform a required action. A 115 fault is a persistent defect. 117 This document specifies an MPLS OAM channel called an "MPLS-OAM Fault 118 Management (FM)" channel. A single message format and a set of 119 procedures are defined to communicate service disruptive conditions 120 from the location where they occur to the endpoints of LSPs which are 121 affected by those conditions. Multiple message types and flags are 122 used to indicate and qualify the particular condition. 124 Corresponding to the two classes of service disruptive conditions 125 listed above, two messages are defined to communicate the type of 126 condition. These are known as: 128 Alarm Indication Signal (AIS) 130 Lock Report (LKR) 132 1.1. Terminology 134 ACH: Associated Channel Header 136 ASN: Autonomous System Number 137 CC: Continuity Check 139 FM: Fault Management 141 GAL: Generic Associated Channel Label 143 LOC: Loss of Continuity 145 LSP: Label Switched Path 147 LSR: Label Switching Router 149 MEP: Maintenance End Point 151 MIP: Maintenance Intermediate Point 153 MPLS: Multi-Protocol Label Switching 155 MPLS-TP: MPLS Transport Profile 157 OAM: Operations, Administration and Maintenance 159 P2MP: Point to Multi-Point 161 P2P: Point to Point 163 PSC: Protection State Coordination 165 PW: Pseudowire 167 TLV: Type Length Value 169 TTL: Time To Live 171 Requirements Language 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in RFC 2119 [3]. 177 2. MPLS Fault Management Messages 179 This document defines messages to indicate service disruptive 180 conditions. Two messages are defined, Alarm Indication Signal, and 181 Lock Report. These semantics of the individual messages are 182 described in subsections below. 184 Fault Management messages are carried in-band by using the Associated 185 Channel Header (ACH) and Generic Associated Channel Label (GAL) as 186 defined in RFC5586 [4]. To facilitate recognition and delivery of 187 Fault Management messages, the Fault Management Channel is identified 188 by a unique ACH codepoint. 190 Fault OAM messages are generated by intermediate nodes where an LSP 191 is switched. When a server layer, (e.g. a link) used by the LSP 192 fails, the intermediate node sends Fault Management messages using 193 the LSP's Fault associated channel back to the endpoint of the LSP. 194 Strictly speaking, when a server MEP detects a service disruptive 195 condition, Fault Management messages are generated by the convergence 196 server-to-client adaptation function. The messages are sent to the 197 client MEPs by inserting them into the affected LSPs in the direction 198 opposite to the detecting MEP's peer server MEP(s). The message is 199 sent periodically until the condition is cleared. 201 2.1. MPLS-TP Alarm Indication Signal 203 The MPLS-TP Alarm Indication Signal (AIS) message is generated in 204 response to detecting defects in the server layer. The AIS message 205 SHOULD be sent as soon as the condition is detected, that is before 206 any determination has been made as to whether the condition is 207 persistent and therefore fatal. For example, an AIS message may be 208 sent during a protection switching event and would cease being sent 209 (or cease being forwarded by the protection switch selector) if the 210 protection switch was successful in restoring the link. 212 The primary purpose of the AIS message is to suppress alarms in the 213 MPLS-TP layer network above the level at which the defect occurs. 214 When the Link Down Indication is set, the AIS message MAY be used to 215 trigger recovery mechanisms. 217 2.1.1. MPLS-TP Link Down Indication 219 The LDI flag is set in response to detecting a fatal failure in the 220 server layer. The LDI flag MUST NOT be set until the defect has been 221 determined to be fatal. The LDI flag MUST be set if the defect has 222 been determined to be fatal. For example during a protection 223 switching event the LDI flag is not set. However if the protection 224 switch was unsuccessful in restoring the link within the expected 225 repair time, the LDI flag MUST be set. 227 The setting of the LDI flag can be predetermined based on the 228 protection state. If the Server Layer is protected and both the 229 working and protection paths are available, both the active and 230 standby MEPs should be programmed to send AIS with LDI clear upon 231 detecting a defect condition. If the Server Layer is unprotected or 232 the Server Layer is protected but only the active path is available, 233 the active MEP should be programmed to send AIS with LDI set upon 234 detecting a defect condition. 236 The receipt of an AIS message with the LDI flag set MAY be treated as 237 the equivalent of loss of continuity (LOC) at the client layer. The 238 choice of treatment is related to the rate at which the Continuity 239 Check (CC) function is running. In a normal transport environment, 240 CC is run at a high rate in order to detect a failure within 10s of 241 milliseconds. In such an environment, the LDI flag may be ignored. 242 AIS messages with the LDI flag set SHOULD be treated the same as any 243 other AIS message, that is, used solely for alarm suppression. 245 In more general MPLS environments the CC function may be running at a 246 much slower rate. In this environment, the LDI flag enables faster 247 switch-over upon a failure occurring along the LSP. 249 2.2. MPLS-TP Lock Report 251 The MPLS-TP Lock Report (LKR) message is generated when a server 252 layer entity has been administratively locked to communicated that 253 condition to inform the client layer entities of that condition. 254 When an MPLS-TP LSP is administratively locked it is not available to 255 carry client traffic. The purpose of the LKR message is to suppress 256 alarms in the MPLS-TP layer network above the level at which the 257 defect occurs and to allow the clients to differentiate the lock 258 condition from a defect condition. 260 The primary purpose of the LKR message is to suppress alarms in the 261 MPLS-TP layer network above the level at which the defect occurs. 262 Like AIS with the LDI flag set, the receipt of an LKR message MAY be 263 treated as the equivalent of loss of continuity at the client layer. 265 3. MPLS Fault Management Channel 267 The MPLS Fault Management channel is identified by the ACH as defined 268 in RFC 5586 [4] with the Channel Type set to the MPLS Fault 269 Management (FM) code point = 0xHH. [HH to be assigned by IANA from 270 the PW Associated Channel Type registry. Note: An early codepoint 271 allocation has made: 0x0058 Fault OAM (TEMPORARY - expires 272 2011-07-16)] The FM Channel does not use ACH TLVs and MUST not 273 include the ACH TLV header. The FM ACH Channel is shown below. 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 |0 0 0 1|Version| Reserved | 0xHH Fault Management Channel | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | ~ 281 ~ MPLS Fault Management Message ~ 282 ~ | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Figure 1: ACH Indication of the MPLS-TP Fault Management Channel 287 The Fault Management Channel is 0xHH (to be assigned by IANA) 289 4. MPLS Fault Management Message Format 291 The format of the Fault Management message is shown below. 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Vers | Resvd | Msg Type | Flags | Refresh Timer | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Total TLV Len | ~ 299 +-+-+-+-+-+-+-+-+ TLVs ~ 300 ~ | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Figure 2: MPLS-TP OAM Message Format 305 Version 307 The Version Number is currently 1. 309 Reserved 311 This field MUST be set to zero on transmission and ignored on 312 receipt. 314 Message Type 316 The Message Type indicates the type of condition as listed in the 317 table below. 319 Msg Type Description 320 -------- ----------------------------- 321 0x0 Reserved 322 0x1 Alarm Indication Signal (AIS) 323 0x2 Lock Report (LKR) 325 Refresh Timer 327 The maximum time between successive FM messages specified in 328 seconds. The range is 1 to 20. The value 0 is not permitted. 330 Total TLV Length 332 The total TLV length is the total of all included TLVs. 334 Flags 336 Two flags are defined. The reserved flags in this field MUST be 337 set to zero on transmission and ignored on receipt. 339 +-+-+-+-+-+-+-+-+ 340 | Reserved |L|R| 341 +-+-+-+-+-+-+-+-+ 343 Figure 3: Flags 345 L-flag 347 Link Down Indication. See section Section 2.1.1 for details on 348 setting this bit. 350 R-flag 352 The R-flag is normally set to zero. A setting of one indicates 353 the removal of a previously sent FM condition. 355 4.1. Fault Management Message TLVs 357 TLVs are used in fault OAM to carry information that may not pertain 358 to all messages as well as to allow for extensibility. The TLVs 359 currently defined are the IF_ID, Global-ID, and ICC. 361 TLVs (Type-Length-Value tuples) have the following format: 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Type | Length | | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 368 | . 369 . Value . 370 . | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 Figure 4: Fault TLV Format 375 Type 377 Encodes how the Value field is to be interpreted. 379 Length 381 Specifies the length of the Value field in octets. 383 Value 385 Octet string of Length octets that encodes information to be 386 interpreted as specified by the Type field. 388 4.1.1. Interface Identifier TLV 390 This TLV carries the Interface Identifier as defined in 391 draft-ietf-mpls-tp-identifiers [5]. The Type is 0x1. The length is 392 0x8. 394 0 1 2 3 395 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 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | MPLS-TP Node Identifier | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | MPLS-TP Interface Number | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 Figure 5: Interface Identifier TLV Format 404 4.1.2. Global Identifier 406 This TLV carries the Interface Identifier as defined in 407 draft-ietf-mpls-tp-identifiers [5]. The Type is 0x2. The length is 408 0x4. 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | MPLS-TP Global Identifier | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 Figure 6: Global Identifier TLV Format 418 4.1.3. International Carrier Code 420 This TLV carries the International Carrier Code. The Type is 0x3. 421 The length is 0x8. The value is an Octet string padded with nulls. 423 0 1 2 3 424 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 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | International Carrier Code | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | International Carrier Code (Cont.) | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 Figure 7: International Carrier Code 433 5. Sending and Receiving Fault Management Messages 435 5.1. Sending a Fault Management Message 437 Service disruptive conditions are indicated by sending FM messages. 438 The message type is set to the value corresponding to the condition. 439 The refresh timer is set to the maximum time between successive FM 440 messages. This value MUST not be changed on successive FM messages. 441 If the optional clearing procedures are not used, then the default 442 value is 1. Otherwise the default value is 20. 444 A Global-ID TLV or an ICC TLV MAY be included. The IF_ID TLV SHOULD 445 be included. If the R-Flag clearing procedures are to be used, the 446 IF_ID TLV MUST be included. 448 The message is then sent. The message MUST be refreshed two more 449 times at an interval of one second. Further refreshes are sent 450 according to the value of the refresh timer. Refreshing continues 451 until the condition is cleared. 453 5.2. Clearing a FM Indication 455 Ceasing to send FM messages will clear the indication after 3.5 times 456 the Refresh Timer. To clear an indication more quickly, the 457 following procedure is used. The R-Flag of the FM message is set to 458 one. Other fields of the FM message SHOULD NOT be modified. The 459 message is sent immediately and then refreshed two more times at an 460 interval of one second. 462 5.3. Receiving a FM Indication 464 When a FM message is received, a MEP examines it to ensure that that 465 it is well formed. If the message type is unknown, the message is 466 ignored. If the R-Flag is zero, the condition corresponding to the 467 message type is entered. A timer is set to 3.5 times the refresh 468 timer. If the message is not refreshed within this period, the 469 condition is cleared. A message is considered a refresh if the 470 message type and IF_ID match an existing condition and the R-Flag is 471 set to zero. 473 If the R-Flag is set to one, the MEP checks to see if a condition 474 matching the message type and IF_ID exists. If it does, that 475 condition is cleared. Otherwise the message is ignored. 477 6. Minimum Implementation Requirements 479 At a minimum an implementation MUST support the following: 481 1. Sending AIS and LKR messages at a rate of 1 per second. In 482 particular other values of the Refresh Timer and setting the R 483 bit to value other than zero need not be supported. 485 2. Support of the sending the LDI flag. 487 3. Receiving AIS and LKR messages with any allowed Refresh Timer 488 value. 490 The following items are optional to implement. 492 1. Support of receiving the LDI flag. 494 2. Support of receiving the R flag. 496 3. All TLVs. 498 7. Security Considerations 500 Spurious fault OAM messages form a vector for a denial of service 501 attack. However, since these messages are carried in a control 502 channel, one would have to gain access to a node providing the 503 service in order to effect such an attack. Since transport networks 504 are usually operated as a walled garden, such threats are less 505 likely. 507 8. IANA Considerations 509 8.1. Pseudowire Associated Channel Type 511 Fault OAM requires a unique Associated Channel Type which are 512 assigned by IANA from the Pseudowire Associated Channel Types 513 Registry. 515 Registry: 516 Value Description TLV Follows Reference 517 ----------- ----------------------- ----------- --------- 518 0xHHHH Fault OAM No (This Document) 520 8.2. MPLS Fault OAM Message Type Registry 522 This sections details the MPLS Fault OAM TLV Registry, a new name 523 spaces to be managed by IANA. The Type space is divided into 524 assignment ranges; the following terms are used in describing the 525 procedures by which IANA allocates values: "Standards Action" (as 526 defined in RFC 5226 [6]) and "Private Use". 528 MPLS Fault OAM Message Types take values in the range 0-255. 529 Assignments in the range 0-251 are via Standards Action; values in 530 the range 251-255 are for Private Use, and MUST NOT be allocated. 532 Message Types defined in this document are: 534 Msg Type Description 535 -------- ----------------------------- 536 0x0 Reserved 537 0x1 Alarm Indication Signal (AIS) 538 0x2 Lock Report (LKR) 540 8.3. MPLS Fault OAM TLV Registry 542 This sections details the MPLS Fault OAM TLV Registry, a new name 543 spaces to be managed by IANA. The Type space is divided into 544 assignment ranges; the following terms are used in describing the 545 procedures by which IANA allocates values: "Standards Action" (as 546 defined in RFC 5226 [6]), "Specification Required" and "Private Use". 548 MPLS Fault OAM TLVs which take values in the range 0-255. 549 Assignments in the range 0-191 are via Standards Action; assignments 550 in the range 192-248 are made via "Specification Required"; values in 551 the range 248-255 are for Private Use, and MUST NOT be allocated. 553 TLVs defined in this document are: 555 Value TLV Name 556 ----- ------- 557 0 Reserved 558 1 Interface Identifier TLV 559 2 Global Identifier 560 3 International Carrier Code 562 9. References 564 9.1. Normative References 566 [1] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. 567 Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, 568 September 2009. 570 [2] Vigoureux, M., Ward, D., and M. Betts, "Requirements for 571 Operations, Administration, and Maintenance (OAM) in MPLS 572 Transport Networks", RFC 5860, May 2010. 574 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 575 Levels", BCP 14, RFC 2119, March 1997. 577 [4] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 578 Associated Channel", RFC 5586, June 2009. 580 [5] Bocci, M., Swallow, G., and E. Gray, "MPLS-TP Identifiers", 581 draft-ietf-mpls-tp-identifiers-03 (work in progress), 582 October 2010. 584 [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 585 Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 587 9.2. Informative References 589 Authors' Addresses 591 George Swallow (editor) 592 Cisco Systems, Inc. 593 300 Beaver Brook Road 594 Boxborough, Massachusetts 01719 595 United States 597 Email: swallow@cisco.com 599 Annamaria Fulignoli (editor) 600 Ericsson 602 Email: annamaria.fulignoli@ericsson.com 604 Martin Vigoureux (editor) 605 Alcatel-Lucent 606 Route de Villejust 607 Nozay, 91620 608 France 610 Email: martin.vigoureux@alcatel-lucent.com 612 Sami Boutros 613 Cisco Systems, Inc. 614 3750 Cisco Way 615 San Jose, California 95134 616 USA 618 Email: sboutros@cisco.com 620 David Ward 621 Juniper Networks, Inc. 623 Email: dward@juniper.net 624 Stewart Bryant 625 Cisco Systems, Inc. 626 250, Longwater 627 Green Park, Reading RG2 6GB 628 UK 630 Email: stbryant@cisco.com 632 Siva Sivabalan 633 Cisco Systems, Inc. 634 2000 Innovation Drive 635 Kanata, Ontario K2K 3E8 636 Canada 638 Email: msiva@cisco.com