idnits 2.17.1 draft-ietf-mpls-tp-fault-07.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 (September 2, 2011) is 4620 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 5226 (ref. '7') (Obsoleted by RFC 8126) 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 G. Swallow, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track A. Fulignoli, Ed. 5 Expires: March 5, 2012 Ericsson 6 M. Vigoureux, Ed. 7 Alcatel-Lucent 8 S. Boutros 9 Cisco Systems, Inc. 10 D. Ward 11 Juniper Networks, Inc. 12 September 2, 2011 14 MPLS Fault Management OAM 15 draft-ietf-mpls-tp-fault-07 17 Abstract 19 This document specifies Operations, Administration, and Maintenance 20 messages to indicate service disruptive conditions for MPLS based 21 Transport Network Label Switched Paths. The notification mechanism 22 employs a generic method for a service disruptive condition to be 23 communicated to a Maintenance Entity Group End Point. This document 24 defines an MPLS OAM channel, along with messages to communicate 25 various types of service disruptive conditions. 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 March 5, 2012. 44 Copyright Notice 46 Copyright (c) 2011 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 64 2. MPLS Fault Management Messages . . . . . . . . . . . . . . . . 5 65 2.1. MPLS Alarm Indication Signal . . . . . . . . . . . . . . . 5 66 2.1.1. MPLS Link Down Indication . . . . . . . . . . . . . . 6 67 2.2. MPLS Lock Report . . . . . . . . . . . . . . . . . . . . . 6 68 2.3. Propagation of MPLS Fault Messages . . . . . . . . . . . . 7 69 3. MPLS Fault Management Channel . . . . . . . . . . . . . . . . 7 70 4. MPLS Fault Management Message Format . . . . . . . . . . . . . 7 71 4.1. Fault Management Message TLVs . . . . . . . . . . . . . . 9 72 4.1.1. Interface Identifier TLV . . . . . . . . . . . . . . . 10 73 4.1.2. Global Identifier . . . . . . . . . . . . . . . . . . 10 74 5. Sending and Receiving Fault Management Messages . . . . . . . 11 75 5.1. Sending a Fault Management Message . . . . . . . . . . . . 11 76 5.2. Clearing a FM Indication . . . . . . . . . . . . . . . . . 11 77 5.3. Receiving a FM Indication . . . . . . . . . . . . . . . . 11 78 6. Minimum Implementation Requirements . . . . . . . . . . . . . 12 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 81 8.1. Pseudowire Associated Channel Type . . . . . . . . . . . . 13 82 8.2. MPLS Fault OAM Message Type Registry . . . . . . . . . . . 14 83 8.3. MPLS Fault OAM Flag Registry . . . . . . . . . . . . . . . 14 84 8.4. MPLS Fault OAM TLV Registry . . . . . . . . . . . . . . . 14 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 90 1. Introduction 92 Proper operation of a transport network depends on the ability to 93 quickly identify faults and focus attention on the root cause of the 94 disruption. This document defines MPLS Fault Management Operations, 95 Administration, and Maintenance (OAM) messages. When a fault occurs 96 in a server (sub-)layer, Fault Management OAM messages are sent to 97 clients of that server so that alarms, which otherwise would be 98 generated by the subsequent disruption of the clients, may be 99 suppressed. This prevents a storm of alarms and allows operations to 100 focus on the actual faulty elements of the network. 102 In traditional transport networks, circuits such as T1 lines are 103 typically provisioned on multiple switches. When an event that 104 causes disruption occurs on any link or node along the path of such a 105 transport circuit, OAM indications are generated. When received, 106 these indications may be used to suppress alarms and/or activate a 107 backup circuit. The MPLS based Transport Network provides mechanisms 108 equivalent to traditional transport circuits. Therefore a Fault 109 Management (FM) capability must be defined for MPLS. This document 110 defines FM capabilities to meet the MPLS-TP requirements as described 111 in RFC 5654 [1], and the MPLS-TP Operations, Administration, and 112 Maintenance Requirements as described in RFC 5860 [2]. These 113 mechanisms are intended to be applicable to other aspects of MPLS as 114 well. However, applicability to other types of LSPs is beyond the 115 scope of this document. 117 Two broad classes of service disruptive conditions are identified. 119 1. Fault: The inability of a function to perform a required action. 120 This does not include an inability due to preventive maintenance, 121 lack of external resources, or planned actions. 123 2. Lock: an administrative status in which it is expected that only 124 test traffic, if any, and OAM (dedicated to the LSP) can be sent 125 on an LSP. 127 Within this document a further term is defined, server-(sub-)layer- 128 failure, or more briefly server-failure. A server-failure occurs 129 when a fault condition or conditions have persisted long enough to 130 consider the required service function to have terminated. In the 131 case of a protected server, this would mean that both the working and 132 and any protection facilities have suffered faults of the required 133 duration. 135 This document specifies an MPLS OAM channel called an "MPLS-OAM Fault 136 Management (FM)" channel. A single message format and a set of 137 procedures are defined to communicate service disruptive conditions 138 from the location where they occur to the endpoints of LSPs which are 139 affected by those conditions. Multiple message types and flags are 140 used to indicate and qualify the particular condition. 142 Corresponding to the two classes of service disruptive conditions 143 listed above, two messages are defined to communicate the type of 144 condition. These are known as: 146 Alarm Indication Signal (AIS) 148 Lock Report (LKR) 150 1.1. Terminology 152 ACH: Associated Channel Header 154 ACh: Associated Channel 156 CC: Continuity Check 158 FM: Fault Management 160 GAL: Generic Associated Channel Label 162 LOC: Loss of Continuity 164 LSP: Label Switched Path 166 MEP: Maintenance Entity Group End Point 168 MPLS: Multi-Protocol Label Switching 170 MPLS-TP: MPLS Transport Profile 172 MS-PW: Multi-Segment Pseudowire 174 OAM: Operations, Administration, and Maintenance 176 PHP: Penultimate Hop Pop 178 PW: Pseudowire 180 TLV: Type, Length, Value 182 1.2. Requirements Language 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in RFC 2119 [3]. 188 2. MPLS Fault Management Messages 190 This document defines two messages to indicate service disruptive 191 conditions, Alarm Indication Signal, and Lock Report. The semantics 192 of the individual messages are described in subsections below. Fault 193 OAM messages are applicable to LSPs used in the MPLS Transport 194 Profile. Such LSPs are bound to specific server layers based upon 195 static configuration or signaling in a client/server relationship. 197 Fault Management messages are carried in-band of the client LSP or 198 MS-PW by using the Associated Channel Header (ACH). For LSPs other 199 than PWs, the ACH is identified by the Generic Associated Channel 200 Label (GAL) as defined in RFC5586 [4]. To facilitate recognition and 201 delivery of Fault Management messages, the Fault Management Channel 202 is identified by a unique Associated Channel (ACh) codepoint. 204 Fault OAM messages are generated by intermediate nodes where a client 205 LSP is switched. When a server (sub-)layer, (e.g. a link or 206 bidirectional LSP) used by the client LSP fails, the intermediate 207 node sends Fault Management messages downstream towards the endpoint 208 of the LSP. The messages are sent to the client MEPs by inserting 209 them into the affected client LSPs in the direction downstream of the 210 fault location. These messages are sent periodically until the 211 condition is cleared. 213 2.1. MPLS Alarm Indication Signal 215 The MPLS Alarm Indication Signal (AIS) message is generated in 216 response to detecting faults in the server (sub-)layer. The AIS 217 message SHOULD be sent as soon as the condition is detected, but MAY 218 be delayed owing to processing in an implementation, and MAY be 219 suppressed if protection is achieved very rapidly. For example, an 220 AIS message may be sent during a protection switching event and would 221 cease being sent (or cease being forwarded by the protection switch 222 selector) if the protection switch was successful in restoring the 223 link. However, an implementation may instead wait to see if the 224 protection switch is successful prior to sending any AIS messages. 226 The primary purpose of the AIS message is to suppress alarms in the 227 layer network above the level at which the fault occurs. When the 228 Link Down Indication is set, the AIS message MAY be used to trigger 229 recovery mechanisms. 231 2.1.1. MPLS Link Down Indication 233 The Link Down Indication (LDI) is communicated by setting the L-flag 234 to 1. A node sets the L-flag in the AIS message in response to 235 detecting a failure in the server layer. A node MUST NOT set the 236 L-flag until the fault has been determined to be a server-failure. A 237 node MUST set the L-flag if the fault has been determined to be a 238 server-failure. For example during a server layer protection 239 switching event, a node MUST NOT set the L-flag. However if the 240 protection switch was unsuccessful in restoring the link within the 241 expected repair time, the node MUST set the L-flag. 243 The setting of the L-flag can be predetermined based on the 244 protection state. For example, if a server layer is protected and 245 both the working and protection paths are available, the node should 246 send AIS with the L-flag clear upon detecting a fault condition. If 247 the server layer is unprotected or the server layer is protected but 248 only the active path is available, the node should send AIS with the 249 L-flag set upon detecting a loss of continuity (LOC) condition. Note 250 again that the L-flag is not set until a server-failure has been 251 declared. Thus if there is any hold-off timer associated with the 252 LOC, then the L-flag is not set until that timer has expired. 254 The receipt of an AIS message with the L-flag set MAY be treated as 255 the equivalent of LOC at the client layer. The choice of treatment 256 is related to the rate at which the Continuity Check (CC) function is 257 running. In a normal transport environment, CC is run at a high rate 258 in order to detect a failure within 10s of milliseconds. In such an 259 environment, the L-flag MAY be ignored and the AIS message is used 260 solely for alarm suppression. 262 In more general MPLS environments the CC function may be running at a 263 much slower rate. In this environment, the Link Down Indication 264 enables faster switch-over upon a failure occurring along the client 265 LSP. 267 2.2. MPLS Lock Report 269 The MPLS Lock Report (LKR) message is generated when a server 270 (sub-)layer entity has been administratively locked. Its purpose is 271 to communicate the locked condition to the client layer entities. 272 When a server layer is administratively locked it is not available to 273 carry client traffic. The purpose of the LKR message is to suppress 274 alarms in the layer network above the level at which the 275 administrative lock occurs and to allow the clients to differentiate 276 the lock condition from a fault condition. While the primary purpose 277 of the LKR message is to suppress alarms, similar to AIS with the LDI 278 (L-flag set), the receipt of an LKR message MAY be treated as the 279 equivalent of loss of continuity at the client layer. 281 2.3. Propagation of MPLS Fault Messages 283 MPLS-TP allows for a hierarchy of LSPs. When the client MEP of an 284 LSP which is also acting as a server layer receives FM indications, 285 the following rules apply. If the CC function is disabled for the 286 server LSP, a node SHOULD generate AIS messages toward any clients 287 when either the AIS or LKR indication is raised. Note that the 288 L-flag is not automatically propagated. The rules of Section 2.1.1 289 apply. In particular, the L-flag is not set until a server-failure 290 has been declared. 292 3. MPLS Fault Management Channel 294 The MPLS Fault Management channel is identified by the ACH as defined 295 in RFC 5586 [4] with the Associated Channel Type set to the MPLS 296 Fault Management (FM) code point = 0xHHHH. [HHHH to be assigned by 297 IANA from the PW Associated Channel Type registry.] The FM Channel 298 does not use ACh TLVs and MUST NOT include the ACh TLV header. The 299 ACH with the FM ACh code point is shown below. 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 |0 0 0 1|Version| Reserved | 0xHHHH FM Channel | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | ~ 307 ~ MPLS Fault Management Message ~ 308 ~ | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Figure 1: ACH Indication of the MPLS Fault Management Channel 313 The first three fields are defined in RFC 5586 [4]. 315 The Fault Management Channel is 0xHHHH (to be assigned by IANA). 317 4. MPLS Fault Management Message Format 319 The format of the Fault Management message is shown below. 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Vers | Resvd | Msg Type | Flags | Refresh Timer | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Total TLV Len | ~ 327 +-+-+-+-+-+-+-+-+ TLVs ~ 328 ~ | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Figure 2: MPLS Fault OAM Message Format 333 Version 335 The Version Number is currently 1. 337 Reserved 339 This field MUST be set to zero on transmission and ignored on 340 receipt. 342 Message Type 344 The Message Type indicates the type of condition as listed in the 345 table below. 347 Msg Type Description 348 -------- ----------------------------- 349 0x0 Reserved 350 0x1 Alarm Indication Signal (AIS) 351 0x2 Lock Report (LKR) 353 Flags 355 Two flags are defined. The reserved flags in this field MUST be 356 set to zero on transmission and ignored on receipt. 358 +-+-+-+-+-+-+-+-+ 359 | Reserved |L|R| 360 +-+-+-+-+-+-+-+-+ 362 Figure 3: Flags 364 L-flag 366 Link Down Indication. The L-flag only has significance in the 367 AIS message. For the LKR message the L-flag MUST be set to 368 zero and ignored on receipt. See Section 2.1.1 for details on 369 setting this bit. 371 R-flag 373 The R-flag is clear to indicate the presence of an FM condition 374 and is to one to indicate the removal of a previously sent FM 375 condition. 377 Refresh Timer 379 The maximum time between successive FM messages specified in 380 seconds. The range is 1 to 20. The value 0 is not permitted. 382 Total TLV Length 384 The total length in bytes of all included TLVs. 386 4.1. Fault Management Message TLVs 388 TLVs are used in Fault Management messages to carry information that 389 may not pertain to all messages as well as to allow for 390 extensibility. The TLVs currently defined are the IF_ID, and the 391 Global_ID. 393 TLVs (Type-Length-Value tuples) have the following format: 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Type | Length | | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 400 | . 401 . Value . 402 . | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Figure 4: Fault TLV Format 407 Type 408 Encodes how the Value field is to be interpreted. 410 Length 412 Specifies the length of the Value field in octets. 414 Value 416 Octet string of Length octets that encodes information to be 417 interpreted as specified by the Type field. 419 4.1.1. Interface Identifier TLV 421 The Interface Identifier (IF_ID) TLV carries the IF_ID as defined in 422 draft-ietf-mpls-tp-identifiers [5]. The Type is 0x1. The length is 423 0x8. 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | MPLS-TP Node Identifier | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | MPLS-TP Interface Number | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Figure 5: Interface Identifier TLV Format 435 4.1.2. Global Identifier 437 The Global Identifier (Global_ID) TLV carries the Global_ID as 438 defined in draft-ietf-mpls-tp-identifiers [5]. The Type is 0x2. The 439 length is 0x4. 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | MPLS-TP Global Identifier | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 Figure 6: Global Identifier TLV Format 449 5. Sending and Receiving Fault Management Messages 451 5.1. Sending a Fault Management Message 453 Service disruptive conditions are indicated by sending FM messages. 454 The message type is set to the value corresponding to the condition. 455 The refresh timer is set to the maximum time between successive FM 456 messages. This value MUST NOT be changed on successive FM messages 457 reporting the same incident. If the optional clearing procedures are 458 not used, then the default value is 1 second. Otherwise the default 459 value is 20 seconds. 461 A Global_ID MAY be included. If the R-flag clearing procedures are 462 to be used, the IF_ID TLV MUST be included. Otherwise, the IF_ID TLV 463 MAY be included. 465 The message is then sent. Assuming the condition persists, the 466 message MUST be retransmitted two more times at an interval of one 467 second. Further retransmissions are made according to the value of 468 the refresh timer. Retransmissions continue until the condition is 469 cleared. 471 5.2. Clearing a FM Indication 473 When a fault is cleared, a node MUST cease sending the associated FM 474 messages. Ceasing to send FM messages will clear the indication 475 after 3.5 times the refresh timer. To clear an indication more 476 quickly, the following procedure is used. The R-flag of the FM 477 message is set to one. Other fields of the FM message SHOULD NOT be 478 modified. The message is sent immediately and then retransmitted two 479 more times at an interval of one second. Note, however if another 480 fault occurs, the node MUST cease these retransmissions and a 481 generate new FM messages for the new fault. 483 5.3. Receiving a FM Indication 485 When a FM message is received, a MEP examines it to ensure that it is 486 well formed. If the message type is reserved or unknown, the message 487 is ignored. If the version number is unknown, the message is 488 ignored. 490 If the R-flag is set to zero, the MEP checks to see if a condition 491 matching the message type exists. If it does not, the condition 492 specific to the message type is entered. An expiration-timer is set 493 to 3.5 times the refresh timer. If the message type matches an 494 existing condition, the message is considered a refresh and the 495 expiration-timer is reset. In both cases, if an IF_ID tlv is 496 present, it is recorded. 498 If the R-flag is set to one, the MEP checks to see if a condition 499 matching the message type and IF_ID exists. If it does, that 500 condition is cleared. Otherwise the message is ignored. 502 If the expiration-time expires, the condition is cleared. 504 6. Minimum Implementation Requirements 506 At a minimum an implementation MUST support the following: 508 1. Sending AIS and LKR messages at a rate of 1 per second. 510 2. Support of setting the L-flag to indicate a server-failure. 512 3. Receiving AIS and LKR messages with any allowed Refresh Timer 513 value. 515 The following items are OPTIONAL to implement. 517 1. Sending AIS and LKR message with values of the Refresh Timer 518 other than 1 second. 520 2. Support of receiving the L-flag. 522 3. Support of setting the R-flag to a value other than zero. 524 4. Support of receiving the R-flag. 526 5. All TLVs. 528 7. Security Considerations 530 MPLS-TP is a subset of MPLS and so builds upon many of the aspects of 531 the security model of MPLS. MPLS networks make the assumption that 532 it is very hard to inject traffic into a network, and equally hard to 533 cause traffic to be directed outside the network. The control plane 534 protocols utilize hop-by-hop security, and assume a "chain-of-trust" 535 model such that end-to-end control plane security is not used. For 536 more information on the generic aspects of MPLS security, see RFC 537 5920 [8]. 539 This document describes a protocol carried in the G-ACh RFC 5586 [4], 540 and so is dependent on the security of the G-ACh, itself. The G-ACh 541 is a generalization of the Associated Channel defined in RFC 4385 542 [6]. Thus, this document relies heavily on the security mechanisms 543 provided for the Associated Channel and described in those two 544 documents. 546 A specific concern for the G-ACh is that is can be used to provide a 547 covert channel. This problem is wider than the scope of this 548 document and does not need to be addressed here, but it should be 549 noted that the channel provides end-to-end connectivity and SHOULD 550 NOT be policed by transit nodes. Thus, there is no simple way of 551 preventing any traffic being carried in the G-ACh between consenting 552 nodes. 554 A good discussion of the data plane security of an associated channel 555 may be found in RFC 5085 [9]. That document also describes some 556 mitigation techniques. 558 It should be noted that the G-ACh is essentially connection-oriented 559 so injection or modification of control messages specified in this 560 document requires the subversion of a transit node. Such subversion 561 is generally considered hard in MPLS networks, and impossible to 562 protect against at the protocol level. Management level techniques 563 are more appropriate. 565 Spurious fault OAM messages form a vector for a denial of service 566 attack. However, since these messages are carried in a control 567 channel, except for one case discussed below, one would have to gain 568 access to a node providing the service in order to effect such an 569 attack. Since transport networks are usually operated as a walled 570 garden, such threats are less likely. 572 If external MPLS traffic is mapped to an LSP via a PHP forwarding 573 operation, it is possible to insert a GAL followed by a fault OAM 574 message. In such a situation an operator SHOULD protect against this 575 attack by filtering any fault OAM messages with the GAL at the top of 576 the label stack. 578 8. IANA Considerations 580 8.1. Pseudowire Associated Channel Type 582 Fault OAM requires a unique Associated Channel Type which are 583 assigned by IANA from the Pseudowire Associated Channel Types 584 Registry. 586 Registry: 587 Value Description TLV Follows Reference 588 ----------- ----------------------- ----------- --------- 589 0xHHHH Fault OAM No (This Document) 591 [Note: An early codepoint allocation was made: 0x0058 Fault OAM 592 (TEMPORARY - expires 2012-07-20)] 594 8.2. MPLS Fault OAM Message Type Registry 596 This section details the MPLS Fault OAM Message Type Registry, a new 597 name space to be managed by IANA. The Type space is divided into 598 assignment ranges; the following terms are used in describing the 599 procedures by which IANA allocates values: "Standards Action" (as 600 defined in RFC 5226 [7]) and "Experimental Use". 602 MPLS Fault OAM Message Types take values in the range 0-255. 603 Assignments in the range 0-251 are via Standards Action; values in 604 the range 252-255 are for Experimental Use, and MUST NOT be 605 allocated. 607 Message Types defined in this document are: 609 Msg Type Description 610 -------- ----------------------------- 611 0x0 Reserved (not available for allocation) 612 0x1 Alarm Indication Signal (AIS) 613 0x2 Lock Report (LKR) 615 8.3. MPLS Fault OAM Flag Registry 617 This section details the MPLS Fault OAM Flag Registry, a new name 618 space to be managed by IANA. The Flag space ranges from 0-7. All 619 flags are allocated by "Standards Action". 621 Flags defined in this document are: 623 Bit Hex Value Description 624 --- --------- ----------- 625 0-5 Unassigned 626 6 0x2 L-Flag 627 7 0x1 R-Flag 629 8.4. MPLS Fault OAM TLV Registry 631 This sections details the MPLS Fault OAM TLV Registry, a new name 632 spaces to be managed by IANA. The Type space is divided into 633 assignment ranges; the following terms are used in describing the 634 procedures by which IANA allocates values: "Standards Action" (as 635 defined in RFC 5226 [7]), "Specification Required" and "Private Use". 637 MPLS Fault OAM TLVs which take values in the range 0-255. 638 Assignments in the range 0-191 are via Standards Action; assignments 639 in the range 192-247 are made via "Specification Required"; values in 640 the range 248-255 are for Experimental Use, and MUST NOT be 641 allocated. 643 TLVs defined in this document are: 645 Value TLV Name 646 ----- ------- 647 0 Reserved (not available for allocation) 648 1 Interface Identifier TLV 649 2 Global Identifier 651 9. References 653 9.1. Normative References 655 [1] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. 656 Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, 657 September 2009. 659 [2] Vigoureux, M., Ward, D., and M. Betts, "Requirements for 660 Operations, Administration, and Maintenance (OAM) in MPLS 661 Transport Networks", RFC 5860, May 2010. 663 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 664 Levels", BCP 14, RFC 2119, March 1997. 666 [4] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 667 Associated Channel", RFC 5586, June 2009. 669 [5] Bocci, M., Swallow, G., and E. Gray, "MPLS-TP Identifiers", 670 draft-ietf-mpls-tp-identifiers-07 (work in progress), July 2011. 672 [6] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 673 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use 674 over an MPLS PSN", RFC 4385, February 2006. 676 [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 677 Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 679 9.2. Informative References 681 [8] Fang, L., "Security Framework for MPLS and GMPLS Networks", 682 RFC 5920, July 2010. 684 [9] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 685 Connectivity Verification (VCCV): A Control Channel for 686 Pseudowires", RFC 5085, December 2007. 688 Authors' Addresses 690 George Swallow (editor) 691 Cisco Systems, Inc. 692 300 Beaver Brook Road 693 Boxborough, Massachusetts 01719 694 United States 696 Email: swallow@cisco.com 698 Annamaria Fulignoli (editor) 699 Ericsson 701 Email: annamaria.fulignoli@ericsson.com 703 Martin Vigoureux (editor) 704 Alcatel-Lucent 705 Route de Villejust 706 Nozay, 91620 707 France 709 Email: martin.vigoureux@alcatel-lucent.com 711 Sami Boutros 712 Cisco Systems, Inc. 713 3750 Cisco Way 714 San Jose, California 95134 715 USA 717 Email: sboutros@cisco.com 719 David Ward 720 Juniper Networks, Inc. 722 Email: dward@juniper.net 723 Stewart Bryant 724 Cisco Systems, Inc. 725 250, Longwater 726 Green Park, Reading RG2 6GB 727 UK 729 Email: stbryant@cisco.com 731 Siva Sivabalan 732 Cisco Systems, Inc. 733 2000 Innovation Drive 734 Kanata, Ontario K2K 3E8 735 Canada 737 Email: msiva@cisco.com