RFC 6427

MPLS Fault Management Operations, Administration, and Maintenance (OAM)

📅 published November 2011, from ietf

Part 1 of 3, bestie, so more is coming 🎀

Title Block 💖

This is RFC 6427, titled MPLS Fault Management Operations, Administration, and Maintenance (OAM). It's a Standards Track doc with ISSN 2070-1721, published in November 2011 by the IETF. The editors are G. Swallow (Cisco Systems, Inc.), A. Fulignoli (Ericsson), and M. Vigoureux (Alcatel-Lucent). S. Boutros (Cisco Systems, Inc.) and D. Ward (Juniper Networks, Inc.) are also authors 🧚. The header doesn't list anything it obsoletes or updates, so there's no older RFC it replaces or patches here 📜.

Abstract 🌸

Okay so this doc spells out OAM messages that flag service disruptive conditions on MPLS-based transport network Label Switched Paths 🦋. The notification method is a generic way to get that news to a Maintenance Entity Group End Point 💅. It defines an MPLS OAM channel, plus messages that carry the different kinds of service disruptive conditions ✨.

Status of This Memo 📜

This is an Internet Standards Track document 💜.

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741 🌈.

You can find the current status of this document, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc6427 🎀.

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 💖.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date it was published. Please read these carefully, because they spell out your rights and restrictions for this document 🙈. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 📜.

Table of Contents 🧚

1. Introduction ....................................................3
   1.1. Terminology ................................................4
   1.2. Requirements Language ......................................5
2. MPLS Fault Management Messages ..................................5
   2.1. MPLS Alarm Indication Signal ...............................5
        2.1.1. MPLS Link Down Indication ...........................6
   2.2. MPLS Lock Report ...........................................6
   2.3. Propagation of MPLS Fault Messages .........................7
3. MPLS Fault Management Channel ...................................7
4. MPLS Fault Management Message Format ............................8
   4.1. Fault Management Message TLVs ..............................9
        4.1.1. Interface Identifier TLV ...........................10
        4.1.2. Global Identifier ..................................10
5. Sending and Receiving Fault Management Messages ................10
   5.1. Sending a Fault Management Message ........................10
   5.2. Clearing a Fault Management Indication ....................11
   5.3. Receiving a Fault Management Indication ...................11
6. Minimum Implementation Requirements ............................12
7. Security Considerations ........................................12
8. IANA Considerations ............................................13
   8.1. Pseudowire Associated Channel Type ........................13
   8.2. MPLS Fault OAM Message Type Registry ......................13
   8.3. MPLS Fault OAM Flag Registry ..............................14
   8.4. MPLS Fault OAM TLV Registry ...............................14
9. References .....................................................15
   9.1. Normative References ......................................15
   9.2. Informative References ....................................15
10. Contributing Authors ..........................................16

1. Introduction ✨

Okay bestie, a transport network only works if you can spot faults fast and find the root cause of the disruption 🔍. This doc defines MPLS Fault Management Operations, Administration, and Maintenance (OAM) messages 🦋. When a fault shows up in a server (sub-)layer, Fault Management OAM messages get sent to that server's clients 💌. That way, the alarms the clients would otherwise throw from the disruption can be suppressed. This stops an alarm storm and lets operators focus on the actually broken parts of the network 🫶.

In traditional transport networks, circuits like T1 lines usually get provisioned across multiple switches 🔌. When an event that causes disruption hits any link or node on that circuit's path, OAM indications get generated. Once they're received, they can be used to suppress alarms and/or switch on a backup circuit 💅. MPLS-based transport networks give you mechanisms equivalent to those traditional circuits, so a Fault Management (FM) capability must be defined for MPLS 👑. This doc defines FM capabilities to meet the MPLS-TP requirements in RFC 5654 [1] and the MPLS-TP Operations, Administration, and Maintenance requirements in RFC 5860 [2]. These mechanisms are meant to apply to other parts of MPLS too. Applicability to other types of LSPs, though, is beyond the scope of this document 🙈.

Two broad classes of service disruptive conditions get identified:

  1. Fault: The inability of a function to perform a required action. This doesn't cover an inability caused by preventive maintenance, lack of external resources, or planned actions 💀.
  2. Lock: An administrative status where it's expected that only test traffic (if any) and OAM dedicated to the LSP can be sent on an LSP 🔒.

This doc also defines one more term, server-failure. A server-failure happens when fault conditions have persisted long enough that the server (sub-)layer's required service function is considered terminated 😭. For a protected server, that means the working facilities and any protection facilities have all suffered faults of the required duration 🛡️.

This doc specifies an MPLS OAM channel called the "MPLS-OAM Fault Management (FM)" channel 🎀. It defines one message format and a set of procedures for communicating service disruptive conditions from where they happen to the end points of the affected LSPs 🌈. Multiple message types and flags are used to indicate and qualify each specific condition 💜.

Matching the two classes above, two messages are defined to communicate the type of condition 🍓. They're known as:

  • Alarm Indication Signal (AIS)
  • Lock Report (LKR)

1.1. Terminology 📖

Here's the abbreviation squad, periodt 💅:

  • ACH: Associated Channel Header
  • ACh: Associated Channel
  • CC: Continuity Check
  • FM: Fault Management
  • GAL: Generic Associated Channel Label
  • LOC: Loss of Continuity
  • LSP: Label Switched Path
  • MEP: Maintenance Entity Group End Point
  • MPLS: Multiprotocol Label Switching
  • MPLS-TP: MPLS Transport Profile
  • MS-PW: Multi-Segment Pseudowire
  • OAM: Operations, Administration, and Maintenance
  • PHP: Penultimate Hop Pop
  • PW: Pseudowire
  • TLV: Type, Length, Value

1.2. Requirements Language 🔥

This is where the key word rules live, so pay attention 👑. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3] ✨.

2. MPLS Fault Management Messages 🦋

This doc defines two messages for indicating service disruptive conditions: Alarm Indication Signal and Lock Report 💌. Each message's semantics get their own subsections below 🌸. Fault OAM messages apply to LSPs used in the MPLS Transport Profile. Those LSPs are bound to specific server layers, either through static configuration or through signaling in a client/server relationship 🫶.

Fault Management messages are carried in-band of the client LSP or MS-PW using the Associated Channel Header (ACH) 🔌. For LSPs other than PWs, the ACH is identified by the Generic Associated Channel Label (GAL) defined in RFC 5586 [4]. To make Fault Management messages easy to recognize and deliver, the Fault Management Channel is identified by a unique Associated Channel (ACh) code point 💖.

Fault OAM messages get generated by intermediate nodes where a client LSP is switched 🔁. When a server (sub-)layer that the client LSP uses fails (say, a link or a bidirectional LSP), the intermediate node sends Fault Management messages downstream toward the LSP's end point 🚀. The messages go to the client MEPs by getting inserted into the affected client LSPs, in the direction downstream of the fault location 💅. They keep being sent periodically until the condition is cleared ⏰.

2.1. MPLS Alarm Indication Signal 🚨

The MPLS Alarm Indication Signal (AIS) message is generated when faults are detected in the server (sub-)layer 🚨. The AIS message SHOULD be sent as soon as the condition is detected 🏃‍♀️. It MAY be delayed because of processing in an implementation, and it MAY be suppressed if protection is achieved very rapidly 🧠. For example, an AIS message may be sent during a protection switching event. If the protection switch successfully restores the link, the AIS message would stop being sent (or stop being forwarded by the protection switch selector) ✨. However, an implementation may instead wait to see whether the protection switch succeeds before sending any AIS messages 🤔.

The main job of the AIS message is to suppress alarms in the layer network above the level where the fault happened 🛑. When the Link Down Indication is set, the AIS message can be used to trigger recovery mechanisms 🌈.

okay bestie, the Link Down Indication (LDI) is communicated by setting the L-Flag to 1 🫶. A node sets the L-Flag in the AIS message when it detects a failure in the server layer ✨. But here's the tea: a node MUST NOT set the L-Flag until the fault has been determined to be a server-failure 🙅‍♀️. Once it's confirmed as a server-failure, the node MUST set the L-Flag 💅. For example, during a server layer protection switching event, a node MUST NOT set the L-Flag 🌸. However, if the protection switch doesn't restore the link within the expected repair time, the node MUST set the L-Flag 🔥.

The L-Flag can be predetermined based on the protection state 🦋. If a server layer is protected and both the working and protection paths are available, the node should send AIS with the L-Flag clear when it detects a fault condition 🎀. If the server layer is unprotected, or it's protected but only the active path is available, the node should send AIS with the L-Flag set when it detects a loss of continuity (LOC) condition 💜. Note again that the L-Flag isn't set until a server-failure has been declared 🙈. So if there's any hold-off timer tied to the LOC, the L-Flag stays unset until that timer has expired ⏳.

The receipt of an AIS message with the L-Flag set MAY be treated as the equivalent of LOC at the client layer 🧚. Which way you go depends on how fast the Continuity Check (CC) function is running 🏃‍♀️. In a normal transport environment, CC runs at a high rate so it can detect a failure within tens of milliseconds ⚡. In that setup the L-Flag MAY be ignored, and the AIS message is used solely for alarm suppression 🛡️.

In more general MPLS environments, the CC function may be running at a much slower rate 🐢. In that case the Link Down Indication enables faster switch-over when a failure happens along the client LSP 🚀.

2.2. MPLS Lock Report

The MPLS Lock Report (LKR) message is generated when a server (sub-)layer entity has been administratively locked 🔒. Its whole job is to tell the client-layer entities about that locked condition 📣. When a server layer is administratively locked, it's not available to carry client traffic 🚫. So the LKR message suppresses alarms in the layer network above the level where the administrative lock happens, and it lets clients tell a lock apart from an actual fault 🙌. Its main purpose is alarm suppression, but just like AIS with the LDI (L-Flag set), receiving an LKR message can be treated as the equivalent of loss of continuity at the client layer 💀.

2.3. Propagation of MPLS Fault Messages

okay so MPLS-TP allows for a hierarchy of LSPs 👑. When the client MEP of an LSP (which is also acting as a server layer) receives FM indications, these rules apply 🧚‍♀️. If the CC function is disabled for the server LSP, a node SHOULD generate AIS messages toward any clients when either the AIS or LKR indication is raised 🌈. Note that the L-Flag is NOT automatically propagated, and the rules of Section 2.1.1 apply ✨. In particular, the L-Flag isn't set until a server-failure has been declared 💖.

3. MPLS Fault Management Channel

The MPLS Fault Management channel is identified by the ACH as defined in RFC 5586 [4] 🎀. The Associated Channel Type is set to the MPLS Fault Management (FM) code point = 0x0058 🦋. The FM Channel does not use ACh TLVs, and it MUST NOT include the ACh TLV header 🙅‍♀️. Here's what the ACH with the FM ACh code point looks like 👇

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 1|Version|   Reserved    |       0x0058 FM Channel       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               ~
      ~                  MPLS Fault Management Message                ~
      ~                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: ACH Indication of the MPLS Fault Management Channel

The first three fields are defined in RFC 5586 [4] 📖. The Fault Management Channel is 0x0058 💜.

4. MPLS Fault Management Message Format

Here's the format of the Fault Management message 💅.

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Vers  | Resvd |   Msg Type    |     Flags     | Refresh Timer |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Total TLV Len |                                               ~
      +-+-+-+-+-+-+-+-+              TLVs                             ~
      ~                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: MPLS Fault OAM Message Format

Version 🔢 The Version Number is currently 1 ✨.

Reserved 🫧 This field MUST be set to zero on transmission and ignored on receipt 🙅‍♀️.

Message Type 🏷️ The Message Type tells you the type of condition, as listed in the table below 👀.

Msg Type           Description
--------           -----------------------------
   0               Reserved
   1               Alarm Indication Signal (AIS)
   2               Lock Report (LKR)

Flags 🚩 Two flags are defined. The reserved flags in this field MUST be set to zero on transmission and ignored on receipt 🫶.

            +-+-+-+-+-+-+-+-+
            | Reserved  |L|R|
            +-+-+-+-+-+-+-+-+

Figure 3: Flags

L-Flag ⚡ Link Down Indication. The L-Flag only has significance in the AIS message. For the LKR message, the L-Flag MUST be set to zero and ignored on receipt 🙃. See Section 2.1.1 for details on setting this bit 📍.

R-Flag 🔁 The R-Flag is clear to indicate the presence of an FM condition, and it's set to one to indicate the removal of a previously sent FM condition 💫.

Refresh Timer ⏰ The maximum time between successive FM messages, specified in seconds 🕰️. The range is 1 to 20 💅. The value 0 is not permitted 🚫.

Total TLV Length 📏 The total length in bytes of all included TLVs 🧮.

4.1. Fault Management Message TLVs

TLVs are used in Fault Management messages to carry information that may not pertain to all messages, and they also allow for extensibility 🧩. The TLVs currently defined are the IF_ID and the Global_ID 🎀. TLVs have the following format 👇

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               .
      |                                                               .
      .                             Value                             .
      .                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: Fault TLV Format

Type 🔤 Encodes how the Value field is to be interpreted 🧠.

Length 📐 Specifies the length of the Value field in octets 🔢.

Value 🎁 Octet string of Length octets that encodes information to be interpreted as specified by the Type field 💜.

4.1.1. Interface Identifier TLV

The Interface Identifier (IF_ID) TLV carries the IF_ID as defined in RFC 6370 [5] 🦋. The Type is 1, and the length is 0x8 🌸.

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    MPLS-TP Node Identifier                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    MPLS-TP Interface Number                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: Interface Identifier TLV Format

4.1.2. Global Identifier

The Global Identifier (Global_ID) TLV carries the Global_ID as defined in RFC 6370 [5] 🌍. The Type is 2, and the length is 0x4 🧚.

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   MPLS-TP Global Identifier                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 6: Global Identifier TLV Format

5. Sending and Receiving Fault Management Messages

5.1. Sending a Fault Management Message

Service disruptive conditions are indicated by sending FM messages 🚨. The message type is set to the value that matches 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 reporting the same incident 🔒. If the optional clearing procedures are not used, the default value is one second ⏱️. Otherwise, the default value is 20 seconds 💅.

A Global_ID MAY be included 🌏. If the R-Flag clearing procedures are going to be used, the IF_ID TLV MUST be included 🫶. Otherwise, the IF_ID TLV MAY be included 🌷.

The message is then sent ✈️. Assuming the condition persists, the message MUST be retransmitted two more times at an interval of one second 🔁. Further retransmissions follow the value of the Refresh Timer 🔄. Retransmissions continue until the condition is cleared 🎉.

5.2. Clearing a Fault Management Indication

When a fault is cleared, a node MUST cease sending the associated FM messages 🛑. Ceasing to send FM messages will clear the indication after 3.5 times the Refresh Timer ⌛. To clear an indication more quickly, the following procedure is used 🏎️. The R-Flag of the FM message is set to one. Other fields of the FM message SHOULD NOT be modified 🙅‍♀️. The message is sent immediately and then retransmitted two more times at an interval of one second 💨. Note, however, that if another fault occurs, the node MUST cease these retransmissions and generate new FM messages for the new fault 🫧.

5.3. Receiving a Fault Management Indication

When an FM message is received, a MEP examines it to make sure it's well formed 🔍. If the message type is reserved or unknown, the message is ignored 🙈. If the version number is unknown, the message is ignored too 🚫.

If the R-Flag is set to zero, the MEP checks whether a condition matching the message type exists 🕵️‍♀️. If it doesn't, the condition specific to the message type is entered 🌱. An Expiration timer is set to 3.5 times the Refresh Timer ⏳. If the message type matches an existing condition, the message is considered a refresh, and the Expiration timer is reset 🔄. In both cases, if an IF_ID TLV is present, it is recorded 📝.

If the R-Flag is set to one, the MEP checks whether a condition matching the message type and IF_ID exists 🔎. If it does, that condition is cleared 🧹. Otherwise, the message is ignored 🫠.

If the Expiration timer expires, the condition is cleared 💫.

6. Minimum Implementation Requirements ✨

okay so this is the bare minimum your implementation MUST support, no excuses 💅

  1. Sending AIS and LKR messages at a rate of one per second.
  2. Support of setting the L-Flag to indicate a server-failure.
  3. Receiving AIS and LKR messages with any allowed Refresh Timer value.

these ones are OPTIONAL to implement, so you can totally skip them if you want 🌸

  1. Sending AIS and LKR messages with values of the Refresh Timer other than one second.
  2. Support of receiving the L-Flag.
  3. Support of setting the R-Flag to a value other than zero.
  4. Support of receiving the R-Flag.
  5. All TLVs.

7. Security Considerations 🔥

okay bestie, this section is seriously important, so grab a snack and pay attention 🫶

MPLS-TP is a subset of MPLS, so it builds on a lot of the security model MPLS already has. MPLS networks assume it is very hard to inject traffic into the network, and equally hard to make traffic leave the network in the wrong direction 🙈 The control-plane protocols use hop-by-hop security and a "chain-of-trust" model, which means end-to-end control-plane security is not used. If you want the generic MPLS security stuff, go check RFC 5920 [8].

This document describes a protocol carried in the G-ACh (RFC 5586 [4]), so it depends on the security of the G-ACh itself. The G-ACh is a generalization of the Associated Channel defined in RFC 4385 [6], so this document leans really hard on the security mechanisms provided for the Associated Channel as described in those two documents 💜

A specific concern for the G-ACh is that it can be used to provide a covert channel. This problem is bigger than the scope of this document and doesn't need to be fixed here, but it should be noted that the channel provides end-to-end connectivity and SHOULD NOT be policed by transit nodes. So there's no simple way to stop traffic being carried in the G-ACh between consenting nodes 😭

A good discussion of the data-plane security of an Associated Channel may be found in RFC 5085 [9]. That document also describes some mitigation techniques ✨

Here's the scary-but-true part: the G-ACh is basically connection-oriented, so injecting or changing the control messages specified in this document requires subverting a transit node. That kind of subversion is generally considered hard to protect against in MPLS networks, and impossible to protect against at the protocol level 💀 Management-level techniques are a better fit here.

Spurious fault OAM messages are a vector for a denial-of-service attack. However, since these messages are carried in a control channel, one would have to gain access to a node providing the service to pull this off, except for one case discussed below. Since transport networks are usually run as a walled garden, these threats are less likely 🏰

If external MPLS traffic is mapped to an LSP via a PHP forwarding operation, it is possible to insert a GAL followed by a fault OAM message. In that situation, an operator SHOULD protect against this attack by filtering any fault OAM messages with the GAL at the top of the label stack. Major warning, operators 🚨

⚠️ PHP + a GAL + a fake fault OAM message is the one case where it's not locked down. Filter the GAL at the top of the label stack!

8. IANA Considerations 🎀

8.1. Pseudowire Associated Channel Type

Fault OAM needs a unique Associated Channel Type that IANA has assigned from the Pseudowire Associated Channel Types registry 🦋

Registry:
Value        Description              TLV Follows  Reference
-----------  -----------------------  -----------  ---------
0x0058       Fault OAM                No           (This Document)

8.2. MPLS Fault OAM Message Type Registry

This section details the "MPLS Fault OAM Message Type Registry", a brand new sub-registry of the "Multiprotocol Label Switching (MPLS) Operations, Administration, and Management (OAM) Parameters" registry. The Type space is split into assignment ranges, and the procedures IANA uses to allocate values (as defined in RFC 5226 [7]) use the terms "Standards Action" and "Experimental Use" 📋

MPLS Fault OAM Message Types take values in the range 0-255. Assignments in the range 0-251 are made via Standards Action, and values in the range 252-255 are for Experimental Use and MUST NOT be allocated 🙅‍♀️

The Message Types defined in this document are:

   Msg Type           Description
   --------           -----------------------------
      0               Reserved (not available for allocation)
      1               Alarm Indication Signal (AIS)
      2               Lock Report (LKR)

8.3. MPLS Fault OAM Flag Registry

This section details the "MPLS Fault OAM Flag Registry", another new sub-registry of the "Multiprotocol Label Switching (MPLS) Operations, Administration, and Management (OAM) Parameters" registry. The Flag space ranges from 0-7, and all flags are allocated by "Standards Action" (as defined in RFC 5226 [7]) 🌈

The Flags defined in this document are:

   Bit        Hex Value         Description
   ---        ---------         -----------
   0-5                          Unassigned
    6            0x2            L-Flag
    7            0x1            R-Flag

8.4. MPLS Fault OAM TLV Registry

This section details the "MPLS Fault OAM TLV Registry", a new sub-registry of the "Multiprotocol Label Switching (MPLS) Operations, Administration, and Management (OAM) Parameters" registry. The Type space is split into assignment ranges, and the procedures IANA uses to allocate values (as defined in RFC 5226 [7]) use the terms "Standards Action", "Specification Required", and "Experimental Use" 🍓

MPLS Fault OAM TLVs take values in the range 0-255. Assignments in the range 0-191 are made via Standards Action, assignments in the range 192-247 are made via "Specification Required", and values in the range 248-255 are for Experimental Use and MUST NOT be allocated 🙅‍♀️

The TLVs defined in this document are:

    Value    TLV Name
    -----    -------
        0    Reserved (not available for allocation)
        1    Interface Identifier TLV
        2    Global Identifier

9. References 📚

9.1. Normative References

[1] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.

[2] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010.

[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[4] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.

[5] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.

[6] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.

[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

9.2. Informative References

[8] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.

[9] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.

10. Contributing Authors 🫶

Stewart Bryant
Cisco Systems, Inc.
250, Longwater
Green Park, Reading  RG2 6GB
UK

EMail: stbryant@cisco.com


Siva Sivabalan
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario  K2K 3E8
Canada

EMail: msiva@cisco.com

Authors' Addresses 💖

George Swallow (editor)
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, Massachusetts  01719
United States

EMail: swallow@cisco.com


Annamaria Fulignoli (editor)
Ericsson
Via Moruzzi
Pisa  56100
Italy

EMail: annamaria.fulignoli@ericsson.com


Martin Vigoureux (editor)
Alcatel-Lucent
Route de Villejust
Nozay  91620
France

EMail: martin.vigoureux@alcatel-lucent.com


Sami Boutros
Cisco Systems, Inc.
3750 Cisco Way
San Jose, California  95134
USA

EMail: sboutros@cisco.com


David Ward
Juniper Networks, Inc.

EMail: dward@juniper.net
📦 where this page comes from