RFC 7260

GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration

📅 published June 2014, from ietf

RFC 7260 💖 Part 1 of 6

okay bestie, this one is all about GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration 🎀 It's a Standards Track doc from the IETF, and it's published as RFC 7260 in June 2014 ✨ ISSN 2070-1721. The authors are A. Takacs (Ericsson), D. Fedyk (Hewlett-Packard Company), and J. He (Huawei). It doesn't list anything it obsoletes or updates, so it stands on its own 🦋

Abstract ✨

okay so OAM is a huge part of transport connections 🔥 which means the OAM functions need to switch on and off in sync with when the connection gets commissioned or decommissioned. if they don't, you get spurious alarms and things get inconsistent, and nobody wants that 💀 some technologies set up their OAM entities automatically once the connection exists, but others need extra configuration first. this doc defines extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) so that OAM entities can be set up and configured together with Label Switched Path signaling 💜

Status of This Memo 🌸

this is an Internet Standards Track document 🫶

this doc comes from the Internet Engineering Task Force (IETF). it represents the consensus of the IETF community, received public review, and got 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, any errata, and ways to give feedback at http://www.rfc-editor.org/info/rfc7260 ✨

Copyright (c) 2014 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 they stand on the date of publication. please read these carefully, because they explain your rights and restrictions for this document 📜 Code Components pulled out of 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. Requirements Language ......................................4
   2. Technology-Specific OAM Requirements ............................4
   3. RSVP-TE-Based OAM Configuration .................................6
      3.1. Establishment of OAM Entities and Functions ................8
      3.2. Adjustment of OAM Parameters ..............................10
      3.3. Deleting OAM Entities .....................................11
   4. RSVP-TE Extensions .............................................11
      4.1. LSP Attribute Flags .......................................11
      4.2. OAM Configuration TLV .....................................13
           4.2.1. OAM Function Flags Sub-TLV .........................14
           4.2.2. Technology-Specific Sub-TLVs .......................15
      4.3. Administrative Status Information .........................15
      4.4. Handling OAM Configuration Errors .........................16
      4.5. Considerations on Point-to-Multipoint OAM Configuration ...16
   5. IANA Considerations ............................................18
      5.1. Admin_Status Object Bit Flags .............................18
      5.2. LSP Attribute Flags .......................................18
      5.3. New LSP Attributes ........................................19
      5.4. RSVP Error Code ...........................................19
      5.5. RSVP-TE OAM Configuration Registry ........................20
           5.5.1. OAM Types Sub-Registry .............................20
           5.5.2. OAM Sub-TLVs Sub-Registry ..........................20
           5.5.3. OAM Function Flags Sub-Registry ....................21
   6. Security Considerations ........................................21
   7. Acknowledgements ...............................................21
   8. References .....................................................22
      8.1. Normative References ......................................22
      8.2. Informative References ....................................22

1. Introduction ✨

okay so GMPLS is designed as an out-of-band control plane for dynamic connection provisioning on basically any suitable data-plane technology 🦋 that includes spatial switching (like incoming port or fiber to outgoing port or fiber), wavelength-division multiplexing (like Dense Wavelength Division Multiplexing (DWDM)), time-division multiplexing (like Synchronous Optical Networking and Synchronous Digital Hierarchy (SONET/SDH), G.709), and Ethernet Provider Backbone Bridging - Traffic Engineering (PBB-TE) and MPLS 🌈 in most of these technologies, there are Operations, Administration, and Maintenance (OAM) functions that monitor the health and performance of the connections and trigger data plane (DP) recovery mechanisms. like connection provisioning, OAM functions follow general principles, but they also have some technology-specific characteristics 💜

OAM is an integral part of transport connections, so it is required that OAM functions be activated/deactivated in sync with connection commissioning/decommissioning. this avoids spurious alarms and keeps everything consistent 🔥 in certain technologies, OAM entities are inherently established once the connection is set up, while other technologies need extra configuration to establish and configure OAM entities. in some situations, using OAM functions like Fault Management (FM) and Performance Management (PM) may be optional, depending on network management policies 🌸 so the network operator has to be able to choose which set of OAM functions to apply to specific connections, and which parameters should be configured and activated. to make that work, OAM entities and specific functions must be selectively configurable 🎀

in general, it is required that the management-plane and control-plane connection establishment mechanisms be synchronized with OAM establishment and activation 🫶 especially if the GMPLS control plane is in use, it is desirable to bind OAM setup and configuration to connection establishment signaling. that way you avoid two separate management/configuration steps (connection setup followed by OAM configuration). those separate steps add delay and processing time, and more importantly, they may be prone to misconfiguration errors 😭 once OAM entities are set up and configured, proactive as well as on-demand OAM functions can be activated via the management plane. on the other hand, it should be possible to activate/deactivate proactive OAM functions via the GMPLS control plane too. in some situations, it may be possible to use the GMPLS control plane to control on-demand OAM functions as well ✨

this doc describes requirements for OAM configuration and control via Resource Reservation Protocol - Traffic Engineering (RSVP-TE) 🧚 it specifies extensions to the RSVP-TE protocol that give you a framework to configure and control OAM entities, along with the ability to carry technology-specific information. the extensions split into generic elements that work with any OAM solution and technology, and technology-specific elements that add configuration parameters which may only be needed for one specific OAM technology 💅 this doc specifies the technology-agnostic elements, and it specifies how additional technology-specific OAM parameters get provided. it covers end-to-end OAM configuration, meaning the setup of OAM entities bound to an end-to-end Label Switched Path (LSP), plus the configuration and control of OAM functions running end-to-end in the LSP. configuring OAM entities for LSP segments and tandem connections is outside the scope of this doc 🙈

the mechanisms here give you an additional option for bootstrapping OAM. they are not meant to replace or deprecate other technology-specific OAM bootstrapping techniques, like LSP ping [RFC4379] for MPLS networks 🍓 the procedures in this document are only intended for environments where RSVP-TE signaling is used to set up the LSPs that get monitored with OAM 🌈

1.1. Requirements Language 🎀

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 [RFC2119] 💜

that's the end of part 1!! 🌈 part 2 is coming next, bestie 💖

2. Technology-Specific OAM Requirements 🎀

okay so this section is basically a highlight reel of the tech-specific OAM requirements that can be used as the foundation for an OAM configuration framework 💅 it's giving "here's your checklist, bestie" ✨

MPLS OAM requirements live in [RFC4377] 🧚 that doc is all about making OAM work consistently across MPLS networks. Here's the excerpt that's directly relevant to what we're talking about in this document:

  • lowkey it is desired that automation of LSP defect detection be supported 🤖 and it's especially important when a huge number of LSPs might be tested 😭
  • in particular, some LSPs may need automated testing from the ingress LSR (Label Switching Router) all the way to the egress LSR, while others may not 🫶
  • mechanisms are required to coordinate network responses to defects 🚨 these can include alarm suppression, translating defect signals at technology boundaries, and syncing defect detection times by setting appropriately bounded detection time frames ⏱️

The MPLS Transport Profile (MPLS-TP) is a profile of MPLS aimed at transport applications [RFC5921] 🚛 it adds the specific MPLS characteristics and extensions needed to meet transport requirements, including extra OAM, survivability, and other maintenance functions that plain MPLS doesn't currently support. The specific OAM requirements for MPLS-TP are in [RFC5654] and [RFC5860] 📋 and they pose these requirements on the control plane to configure and control OAM entities:

  • From [RFC5860]: OAM functions MUST operate and be configurable even in the absence of a control plane 💜 Conversely, it SHOULD be possible to configure as well as enable/disable the capability to operate OAM functions as part of connectivity management, and it SHOULD also be possible to configure as well as enable/disable the capability to operate OAM functions after connectivity has been established 🔥
  • From [RFC5654]: The MPLS-TP control plane MUST support the configuration and modification of OAM maintenance points, as well as the activation/deactivation of OAM when the transport path or transport service is established or modified 👑

Ethernet Connectivity Fault Management (CFM) is an adjunct OAM flow that monitors connectivity to check the liveliness of Ethernet networks [IEEE.802.1Q-2011] 🌸 With PBB-TE [IEEE.802.1Q-2011], Ethernet networks support explicitly routed Ethernet connections, and CFM can be used to track the liveliness of PBB-TE connections and detect data-plane failures 🦋 In the IETF, the GMPLS Ethernet Label Switching (GELS) work (see [RFC5828] and [RFC6060]) extended the GMPLS control plane to support setting up PBB-TE data-plane connections. Without control-plane support, you'd need separate management commands to configure and start CFM 🙈

GMPLS-based OAM configuration and control needs a general framework that works across a wide range of data-plane technologies and OAM solutions 🌈 There are three typical data-plane technologies for transport applications:

  • wavelength based, such as Wavelength Switched Optical Networks (WSON) ✨
  • Time-Division Multiplexing (TDM) based, such as Synchronous Digital Hierarchy (SDH) and Synchronous Optical Networking (SONET) 🍓
  • packet based, such as MPLS-TP [RFC5921] and Ethernet PBB-TE [IEEE.802.1Q-2011] 💖

For all of these data planes, the operator MUST be able to configure and control the following OAM functions:

  • it MUST be possible to explicitly request the setup of OAM entities for the signaled LSP, and to provide specific information for that setup if the technology requires it 🧚
  • control of alarms is important so you don't get false alarm indications being reported to the management system 🚨 It MUST be possible to enable/disable alarms generated by OAM functions. Sometimes selective alarm control is nice, like when the operator only cares about critical alarms 💅 Therefore, alarms that do not affect service should be inhibited.
  • when periodic messages are used for liveliness checks (Continuity Checks (CCs)) on LSPs, it MUST be possible to set the frequency of those messages ⏱️ This lets you properly configure things to meet the service requirements and/or the detection time boundaries set by possible congruent connectivity-check operations of higher-layer applications. For an operator to balance fast failure detection against data overhead, it's beneficial to configure the frequency of CC messages on a per-LSP basis 🫶
  • Proactive Performance Monitoring (PM) functions continuously collect information about specific characteristics of the connection 📊 For consistent measurement of Service Level Agreements (SLAs), it MUST be possible to set common configuration parameters for the LSP 👑
  • the extensions MUST allow the operator to use only a minimal set of OAM configuration and control features, if that's supported by the OAM solution or network management policy 🌸 Generic OAM parameters, as well as parameters specific to the data-plane technology or OAM technology, MUST be supported 🎀

3. RSVP-TE-Based OAM Configuration 🦋

okay so in general there are two types of maintenance points: Maintenance Entity Group End Points (MEPs) and Maintenance Entity Group Intermediate Points (MIPs) 💜 MEPs sit at the ends of an LSP and can initiate and terminate OAM messages for Fault Management (FM) and Performance Monitoring (PM) ✨ MIPs live at transit nodes of an LSP and can react to some OAM messages, but otherwise they don't initiate messages 🧚 "Maintenance Entity" (ME) refers to an association of MEPs and MIPs that are provisioned to monitor an LSP 🔥

When an LSP is signaled, a forwarding association gets established between endpoints and transit nodes via label bindings 🌈 This association creates a context for the OAM entities monitoring the LSP. On top of that association, OAM entities may be configured to unambiguously identify MEs 🫶

Besides the ME identification parameters, proactive OAM functions (e.g., CC and PM) may also have additional parameters that need configuring 🍓 In particular, the frequency of periodic CC packets, and the measurement interval for loss and delay measurements, may need to be configured ⏱️

The above parameters can be derived from information related to LSP provisioning, or you can use pre-configured default values instead 💖 In the simplest case, the control plane MAY provide information on whether or not OAM entities need to be set up for the signaled LSP. If OAM entities do get created, control-plane signaling MUST also provide a means to activate/deactivate OAM message flows and associated alarms 🚨

OAM identifiers, and the configuration of OAM functions, are technology specific (they vary depending on the data-plane technology and the chosen OAM solution) 🌸 For any given data-plane technology, a set of OAM solutions may be applicable too 💅 So the OAM configuration framework lets you select a specific OAM solution for the signaled LSP, and gives you ways to carry detailed OAM configuration information in technology-specific TLVs 👑

Administrative Status Information is carried in the Admin_Status object 📋 It's described in [RFC3471], and the Admin_Status object is specified for RSVP-TE in [RFC3473]. Two bits are allocated for administrative control of OAM monitoring: the "OAM Flows Enabled" (M) bit and the "OAM Alarms Enabled" (O) bit 🎀

  • when the "OAM Flows Enabled" bit is set, OAM mechanisms MUST be enabled, and if it's cleared, OAM mechanisms MUST be disabled 🦋
  • when the "OAM Alarms Enabled" bit is set, OAM-triggered alarms are enabled and associated consequent actions MUST be executed, including the notification to the management system 🔥 When this bit is cleared, alarms are suppressed and no action SHOULD be executed, and the management system SHOULD NOT be notified 🙈

The LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects are defined in [RFC5420] to signal LSP attributes and options in the form of TLVs ✨ Options and attributes signaled in the LSP_ATTRIBUTES object can pass transparently through LSRs that don't support a particular option or attribute 🧚 But the contents of the LSP_REQUIRED_ATTRIBUTES object MUST be examined and processed by each LSR 💜

The "OAM MEP entities desired" bit is allocated in the Attribute Flags TLV [RFC5420] for use in the LSP_ATTRIBUTES object 🌈 If that bit is set, it means the establishment of OAM MEP entities is required at the endpoints of the signaled LSP 🫶 The "OAM MIP entities desired" bit is allocated in the Attribute Flags TLV for use in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects 🍓 If that bit is set in the Attribute Flags TLV inside the LSP_REQUIRED_ATTRIBUTES object, it means the establishment of OAM MIP entities is required at every transit node of the signaled LSP 💖 bestie, that's the whole vibe 😭🫶

3.1. Establishment of OAM Entities and Functions ✨

okay so, to avoid spurious alarms 🚨, OAM functions should be set up and enabled in the right order 💅. When the GMPLS control plane handles both LSP establishment and turning on OAM functions for the LSPs, both processes are bound to RSVP-TE message exchanges 🔗.

An LSP can be signaled and established without any OAM configuration first, and OAM entities can be added later with a later re-signaling of the LSP. Or the LSP can be set up with OAM entities from the very first signaling 🦋. The procedures below apply to both cases.

Before initiating a Path message with OAM configuration information, an initiating node MUST establish and configure the matching OAM entities locally. But until the LSP is established, OAM source functions MUST NOT start sending any OAM messages 🙅. In bidirectional connections, the initiator node MUST also set up the OAM sink function, in addition to the OAM source function, and prepare it to receive OAM messages. During this time the OAM alarms MUST be suppressed (e.g., due to missing or unidentified OAM messages) 🙈. To get that OAM alarm suppression, Path messages MUST be sent with the "OAM Alarms Enabled" Admin_Status flag cleared.

When the Path message reaches the receiver, the remote end MUST establish and configure OAM entities according to the OAM information in that Path message. If that isn't possible, a PathErr message SHOULD be sent, and neither the OAM entities nor the LSP SHOULD be established 💀. If the OAM entities get established successfully, the OAM sink function MUST be prepared to receive OAM messages but MUST NOT generate any OAM alarms (e.g., due to missing or unidentified OAM messages) 🌸. In bidirectional connections, an OAM source function MUST also be set up, in addition to the OAM sink function, and according to the requested configuration, the OAM source function MUST start sending OAM messages. After that, a Resv message MUST be sent back, including the Attribute Flags TLV, with the right setting of the "OAM MEP entities desired" and "OAM MIP entities desired" flags, plus the OAM Configuration TLV that matches the established and configured OAM entities and functions 🎀. Depending on the OAM technology, some elements of the OAM Configuration TLV MAY be updated/changed, i.e., if the remote end doesn't support a certain OAM configuration it may suggest an alternative setting, which may or may not be accepted by the initiator of the Path message. If it's accepted, the initiator will reconfigure its OAM functions according to the information received in the Resv message. If the alternate setting isn't acceptable, a ResvErr message MAY be sent, tearing down the LSP 😭. The details of this operation are technology specific and should be described in accompanying technology-specific documents.

When the initiating side receives the Resv message, it completes any pending OAM configuration and enables the OAM source function to send OAM messages 🍓.

After this exchange, OAM entities are established and configured for the LSP, and OAM messages are exchanged. OAM alarms can now be enabled. During the period when OAM alarms are disabled, the initiator sends a Path message with the "OAM Alarms Enabled" Admin_Status flag set. The receiving node enables OAM alarms after processing the Path message, and the initiator enables OAM alarms after it receives the Resv message. Data-plane OAM is now fully functional 👑.

If an egress LSR doesn't support the extensions defined in this document, according to [RFC5420], it will silently ignore the new LSP attribute flags as well as the TLVs carrying additional OAM configuration information. So no error gets raised to tell the ingress LSR about the missing OAM configuration actions on the egress side 🙃. However, as described above, an egress LSR that conforms to the specification of this document will set the LSP attribute flags and include the OAM Configuration TLV in the Resv message to indicate the configuration of the OAM mechanisms. So by detecting the missing information in the Resv message, an ingress LSR can recognize that the remote end doesn't support the OAM configuration functionality. In that case it SHOULD tear down the LSP and, if appropriate, signal the LSP without any OAM configuration information 🫶.

3.2. Adjustment of OAM Parameters

There may be a need to change the parameters of an already-established and configured OAM function during the lifetime of the LSP 🦋. To do that, the LSP needs to be re-signaled with the updated parameters. OAM parameters influence the content and timing of OAM messages, and they also decide how OAM defects and alarms are derived and generated. So to avoid spurious alarms, it's important that both sides (OAM sink and source) get updated in a synchronized way ⏰. First, the alarms of the OAM sink function should be suppressed, and only then should the expected OAM parameters be adjusted. After that, the parameters of the OAM source function can be updated. Finally, the alarms of the OAM sink side can be enabled again.

Following that operation, the LSP MUST first be re-signaled with the "OAM Alarms Enabled" Admin_Status flag cleared, including the updated OAM Configuration TLV that matches the new parameter settings 💜. The initiator MUST keep its OAM sink and source functions running unmodified, but it MUST suppress OAM alarms after the updated Path message is sent. The receiver MUST first disable all OAM alarms, then update the OAM parameters according to the information in the Path message, and reply with a Resv message that acknowledges the changes by including the OAM Configuration TLV. Note that the receiving side can adjust the requested OAM configuration parameters and reply with an updated OAM Configuration TLV in the Resv message, reflecting the values that are actually configured. However, to avoid a long negotiation phase, when adjusting OAM functions that are already configured, the receiving side SHOULD NOT update the parameters requested in the Path message to an extent that would give lower performance (e.g., a lower frequency of monitoring packets) than what was previously in place 🙅‍♀️.

The initiator MUST only update its OAM sink and source functions after it receives the Resv message. After this Path/Resv message exchange (in both unidirectional and bidirectional LSP cases), the OAM parameters are updated and OAM is running according to the new parameter settings. However, OAM alarms are still disabled. A subsequent Path/Resv message exchange with the "OAM Alarms Enabled" Admin_Status flag set is needed to enable OAM alarms again 🔔.

3.3. Deleting OAM Entities

Sometimes it may be useful to remove some or all OAM entities and functions from an LSP without actually tearing down the connection 🧹.

To avoid any spurious alarms, first the LSP MUST be re-signaled with the "OAM Alarms Enabled" Admin_Status flag cleared but with the OAM configuration unchanged. After that, the LSP is re-signaled with the "OAM MEP entities desired" and "OAM MIP entities desired" LSP attribute flags cleared, and without the OAM Configuration TLV. This MUST result in the deletion of all OAM entities associated with the LSP. All control-plane and data-plane resources in use by the OAM entities and functions SHOULD be freed up 💅. Alternatively, if only some OAM functions need to be removed, the LSP is re-signaled with the updated OAM Configuration TLV. The changes between the contents of the previously signaled OAM Configuration TLV and the currently received TLV show which functions MUST be removed/added.

OAM source functions MUST be deleted first, and only after "OAM Alarms Disabled" can the associated OAM sink functions be removed. This makes sure OAM messages don't leak outside the LSP 🛑. To do this, the initiator, before sending the Path message, MUST remove the OAM source, which terminates the OAM message flow associated with the downstream direction. In the case of a bidirectional connection, it MUST leave in place the OAM sink functions associated with the upstream direction. The remote end, after receiving the Path message, MUST remove all associated OAM entities and functions and reply with a Resv message without an OAM Configuration TLV. The initiator completely removes OAM entities and functions after the Resv message arrives 🌈.

4. RSVP-TE Extensions ✨

4.1. LSP Attribute Flags 💖

okay so in RSVP-TE, the Flags field of the SESSION_ATTRIBUTE object is how the LSP shows off its options and attributes 🎀. the catch is that it's only 8 bits, so it can only tell apart 8 options, which is lowkey not a lot 💀. [RFC5420] fixes this by defining new objects for RSVP-TE messages so you can signal arbitrary attribute parameters, which makes RSVP-TE super extensible for new applications ✨. it also allows options and attributes that don't need to be acted on by every Label Switching Router (LSR) along the path. they might only matter for key LSRs, like the ingress LSR and the egress LSR, so they can be signaled transparently and only looked at where they're actually needed 🦋. the LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects are defined in [RFC5420] to signal LSP attributes and options in the form of TLVs. options signaled in LSP_ATTRIBUTES can pass straight through LSRs that don't support them, while the contents of the LSP_REQUIRED_ATTRIBUTES object MUST be examined and processed by each LSR 🔥. only one TLV is defined in [RFC5420], and that's the Attribute Flags TLV.

bit number 10 is "OAM MEP entities desired", and it's allocated in the Attribute Flags TLV for use in the LSP_ATTRIBUTES object 🌸. if that bit is set, it means the endpoints of the signaled LSP need OAM MEP entities established. if MEP establishment isn't supported, an error MUST be generated: OAM Problem/MEP establishment not supported. bestie, that's a hard no 💀.

if the "OAM MEP entities desired" bit is set and extra parameters need configuring, an OAM Configuration TLV MAY be included in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object ✨.

bit number 11 is "OAM MIP entities desired", and it's allocated in the Attribute Flags TLV for use in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects 🧚. if the "OAM MEP entities desired" bit is not set, then this bit MUST NOT be set. if "OAM MIP entities desired" is set in the Attribute Flags TLV in the LSP_REQUIRED_ATTRIBUTES object, it means MIP entities are required at every transit node of the signaled LSP. if MIP establishment isn't supported, an error MUST be generated: OAM Problem/MIP establishment not supported. now the tea 🍵: if an intermediate LSR doesn't support the extensions in this document, it won't recognize the "OAM MIP entities desired" flag. even though LSP_REQUIRED_ATTRIBUTES was used, it won't configure MIP entities and won't raise any errors 😬. so if LSRs that don't support these extensions are assumed to be present in the network, the ingress LSR SHOULD collect per-hop information about the LSP attributes using the LSP Attributes sub-object of the Record Route object (RRO), as defined in [RFC5420]. when the Record Route object is received, the ingress SHOULD check whether all intermediate LSRs set the "OAM MIP entities desired" flag to show they support the function. if not, depending on operator policy, the LSP MAY need to be torn down 🫶.

4.2. OAM Configuration TLV 🎀

this TLV is the one that tells everyone which OAM technology/method should be used, and it carries sub-TLVs for any extra OAM configuration info 🌈. one OAM Configuration TLV MAY be carried in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and Resv messages. when it's carried in LSP_REQUIRED_ATTRIBUTES, it means intermediate nodes MUST recognize and react on the OAM configuration information 👑.

 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 (3)            |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    OAM Type   |                 Reserved                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                           sub-TLVs                            ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: it's a brand new type, the OAM Configuration TLV (3) 🍓.

OAM Type: this specifies the technology-specific OAM method 🦋. when it's carried in LSP_REQUIRED_ATTRIBUTES and the requested OAM method isn't supported at any given node, an error MUST be generated: OAM Problem/Unsupported OAM Type. when it's carried in LSP_ATTRIBUTES, intermediate nodes that don't support the OAM Type pass the object forward unchanged, as specified in [RFC5420]. ingress and egress nodes that support the OAM Configuration TLV but don't support a specific OAM Type MUST respond with an error indicating OAM Problem/Unsupported OAM Type.

       OAM Type             Description
     ------------      --------------------
        0-255               Reserved

this document defines no types. IANA maintains the values in a new "RSVP-TE OAM Configuration Registry" 📋.

Length: this is the total length of the TLV in octets. the TLV MUST be zero-padded so that it's 4-octet aligned 💅.

there are two groups of TLVs: generic sub-TLVs and technology-specific sub-TLVs 🌸. generic sub-TLVs carry info that's applicable no matter which OAM technology is in use, while technology-specific sub-TLVs provide configuration parameters for specific OAM technologies. this document defines one generic sub-TLV (see Section 4.2.1), and technology-specific sub-TLVs are going to be defined by separate documents ✨.

the receiving node, based on the OAM Type, checks whether a corresponding technology-specific OAM configuration sub-TLV is included in the OAM Configuration TLV. if the included technology-specific OAM configuration sub-TLV is different from what's specified in the OAM Type, an error MUST be generated: OAM Problem/OAM Type Mismatch. IANA maintains the sub-TLV space in the new "RSVP-TE OAM Configuration Registry" 🗂️.

there's a hierarchical dependency between the OAM configuration elements, so pay attention 🧐. first, the "OAM MEP entities desired" flag needs to be set. only when that flag is set MAY an OAM Configuration TLV be included in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object. when this TLV is present, based on the "OAM Type" field, it MAY carry a technology-specific OAM configuration sub-TLV. if this hierarchy is broken (for example, the "OAM MEP entities desired" flag isn't set but an OAM Configuration TLV is present), an error MUST be generated: OAM Problem/Configuration Error 💀.

4.2.1. OAM Function Flags Sub-TLV 🧚

the OAM Configuration TLV MUST always include a single instance of the OAM Function Flags Sub-TLV, and it MUST always be the first sub-TLV 👑. "OAM Function Flags" specifies which proactive OAM functions (for example, connectivity monitoring, loss and delay measurement) and which fault management signals MUST be established and configured. if the selected OAM Function or Functions aren't supported, an error MUST be generated: OAM Problem/Unsupported OAM Function.

 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 (1)            |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                      OAM Function Flags                       ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

OAM Function Flags is a bitmap with an extensible length, based on the Length field of the TLV 🌈. bits are numbered from left to right. the TLV is padded to 4-octet alignment, and the Length field indicates the size of the padded TLV in octets. IANA maintains the OAM Function Flags in the new "RSVP-TE OAM Configuration Registry". this document defines the following flags:

OAM Function Flag bit #      Description
----------------------- ---------------------------------------------
 0                      Continuity Check (CC)
 1                      Connectivity Verification (CV)
 2                      Fault Management Signal (FMS)
 3                      Performance Monitoring/Loss (PM/Loss)
 4                      Performance Monitoring/Delay (PM/Delay)
 5                      Performance Monitoring/Throughput Measurement
                        (PM/Throughput)

4.2.2. Technology-Specific Sub-TLVs 🦋

if technology-specific configuration info is needed for a specific "OAM Type", then that info is carried in a technology-specific sub-TLV 💖. these sub-TLVs are OPTIONAL, and an OAM Configuration TLV MUST NOT contain more than one technology-specific sub-TLV. IANA maintains the OAM technology-specific sub-TLV space in the new "RSVP-TE OAM Configuration Registry".

4.3. Administrative Status Information 🎀

Administrative Status Information is carried in the Admin_Status object, which is specified for RSVP-TE in [RFC3473]. it's described in [RFC3471] 📝.

two bits (bit numbers 23 and 24) are allocated by this document for administrative control of OAM monitoring: the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" (O) bits 🔥. when the "OAM Flows Enabled" bit is set, OAM mechanisms MUST be enabled, and if it's cleared, OAM mechanisms MUST be disabled. when the "OAM Alarms Enabled" bit is set, OAM-triggered alarms are enabled and the associated consequent actions MUST be executed, including the notification to the management system. when that bit is cleared, alarms are suppressed and no action SHOULD be executed. on top of that, the management system SHOULD NOT be notified 🙈. for a detailed description of how these flags are used, see Section 3.

4.4. Handling OAM Configuration Errors 🚨

to handle OAM configuration errors, a new Error Code "OAM Problem" (40) is introduced 🌸. a set of Error Values is defined under the "OAM Problem" error code so the specific problems can be called out.

if a node doesn't support the establishment of OAM MEP or MIP entities, it MUST use the error value MEP establishment not supported or MIP establishment not supported, respectively, in the PathErr message 🫶.

if a node doesn't support a specific OAM technology/solution, it MUST use the error value Unsupported OAM Type in the PathErr message ✨.

if a different technology-specific OAM Configuration TLV is included than what was specified in the OAM Type, an error MUST be generated with the error value OAM Type Mismatch in the PathErr message 😭.

there's a hierarchy between the OAM configuration elements. if this hierarchy is broken, the error value Configuration Error MUST be used in the PathErr message 💀.

if a node doesn't support a specific OAM Function, it MUST use the error value Unsupported OAM Function in the PathErr message 💅.

4.5. Considerations on Point-to-Multipoint OAM Configuration ✨

okay so P2MP LSP setup is specced in [RFC4875] 🌸. A P2MP LSP is basically a bunch of source-to-leaf (S2L) sub-LSPs. They run between the ingress and egress LSRs, and the branch LSRs glue them together with RSVP semantics to make one P2MP TE LSP 🦋. One Path message can signal one or several S2L sub-LSPs for the same P2MP LSP, so the S2L sub-LSPs can come in a single Path message or get split across a few of them 💅.

P2MP OAM mechanisms are super specific to the data-plane technology, so this document only covers the basic vibes of P2MP OAM configuration 🧚. We only look at root-to-leaf OAM flows, which means return paths are not our problem here 🙈. We also assume that every leaf has to successfully set up OAM entities with an identical configuration, or the whole P2MP OAM setup doesn't count as successful 💀. Honestly, the guidance below is just guidance 🫶. Still, at a minimum, the procedures below SHOULD be specified for P2MP OAM configuration in a technology-specific document 🔥.

The root node can use a single Path message or several Path messages to build the whole P2MP tree 🌈. If it uses several, the root is in charge of keeping the OAM configuration info consistent across every Path message it sends. Basically, the same info MUST be included in all Path messages used to build the multicast tree 👑. Each branching node forwards the Path message downstream on each of its branches. When it builds a Path message, the OAM configuration info MUST be copied unchanged from the Path message it received. That includes the related Admin_Status bits, the LSP attribute flags, and the OAM Configuration TLV ✨. Those last two also mean the LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects MUST be copied from the upstream Path message into the downstream Path messages 💖.

Leaves MUST create and configure OAM sink functions based on the parameters in the Path message 🎀. For P2MP OAM configuration there's no parameter negotiation per leaf, no exceptions 😭. Why? The OAM source function lives at the root of the tree and runs with one single configuration, and every leaf has to obey it 🍓. If a leaf can't accept the OAM parameters, it MUST use the RRO Attributes sub-object [RFC5420] to tell the root what went wrong 🚨. If the OAM configuration worked out, the leaf sets the "OAM MEP entities desired" flag in the RRO Attributes sub-object of the Resv message ✅. If the OAM entities couldn't be established, the Resv message should be sent with the "OAM MEP entities desired" bit cleared in the RRO Attributes sub-object 🙃. Branching nodes should collect and merge the received RROs following the procedures in [RFC4875] 🧩. That way, when the root gets the Resv message (or messages, if it used multiple Path messages to build the tree), it knows exactly which leaves managed to set up OAM 👀.

If every leaf set up OAM entities successfully, the root can switch on the OAM message flow 🥳. If some leaves failed, the OAM message flow needs extra steps before it can start 😬. One option is to set up two independent P2MP LSPs 💜:

  • One LSP carries the OAM configuration info toward the leaves that can support the OAM function. You get this by pruning the leaves that failed to set up OAM from the previously signaled P2MP LSP 🦋.
  • The other P2MP LSP is built for the leaves without OAM entities 🌸.

The exact procedures will be described in technology-specific documents 💅.

5. IANA Considerations 📋

5.1. Admin_Status Object Bit Flags

IANA maintains a registry called "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" 🗂️, and inside it there's a sub-registry called "Administrative Status Information Flags" ✨.

IANA has allocated two new flags, and here they are 👇:

   Bit Number |  Hex Value | Name                     | Reference
   -----------+------------+--------------------------+-----------
      23      | 0x00000100 | OAM Flows Enabled (M)    | [RFC7260]
      24      | 0x00000080 | OAM Alarms Enabled (O)   | [RFC7260]

5.2. LSP Attribute Flags

IANA maintains a registry called "Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" 🎀, with a sub-registry called "Attribute Flags" 💖.

IANA has allocated two new flags as follows 🥰:

Bit |                  | Attribute  | Attribute  |     |
No. | Name             | Flags Path | Flags Resv | RRO | Reference
----+------------------+------------+------------+-----+----------
 10 | OAM MEP          |            |            |     |
    | entities desired |   Yes      |    Yes     | Yes | [RFC7260]
    |                  |            |            |     |
 11 | OAM MIP          |            |            |     |
    | entities desired |   Yes      |    Yes     | Yes | [RFC7260]

5.3. New LSP Attributes

IANA maintains a registry called "Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" 🌷, with a sub-registry called "Attributes TLV Space" 🧁.

IANA has allocated one new TLV type 🫧:

    |                      |              |Allowed on   |
    |                      |Allowed on    |LSP_REQUIRED_|
Type| Name                 |LSP_ATTRIBUTES|ATTRIBUTES   |Reference
----+----------------------+--------------+-------------+---------
 3  | OAM Configuration TLV|    Yes       |    Yes      |[RFC7260]

5.4. RSVP Error Code

IANA maintains a registry called "Resource Reservation Protocol (RSVP) Parameters" 📚, with a sub-registry called "Error Codes and Globally-Defined Error Value Sub-Codes" 🧐.

IANA has allocated one new Error Code 🚨:

   Error Code | Meaning     | Reference
   -----------+-------------+-------------
       40     | OAM Problem | [RFC7260]

The following Error Value sub-codes are defined for this new Error Code 🔍:

   Value   | Description                     | Reference
-----------+---------------------------------+--------------
     0     | Reserved                        | [RFC7260]
     1     | MEP establishment not supported | [RFC7260]
     2     | MIP establishment not supported | [RFC7260]
     3     | Unsupported OAM Type            | [RFC7260]
     4     | Configuration Error             | [RFC7260]
     5     | OAM Type Mismatch               | [RFC7260]
     6     | Unsupported OAM Function        | [RFC7260]
  7-32767  | Unassigned                      |
32768-65535| Reserved for Private Use        | [RFC7260]

5.5. RSVP-TE OAM Configuration Registry

IANA has created a brand new registry called "RSVP-TE OAM Configuration Registry" 🦋.

IANA has also created sub-registries, as defined in the subsections that follow 🫶. The registration procedures are the ones defined in [RFC5226] 📝.

5.5.1. OAM Types Sub-Registry

IANA has created the "OAM Types" sub-registry of the "RSVP-TE OAM Configuration Registry" like this 🍰:

    Range | Registration Procedures
   -------+-------------------------
    0-255 | IETF Review

There are no initial values in this registry. IANA shows the registry as follows 🌙:

    OAM Type Number | OAM Type Description | Reference
    ----------------+----------------------+--------------
     0-255          | Unassigned           |

5.5.2. OAM Sub-TLVs Sub-Registry

IANA has created the "OAM Sub-TLVs" sub-registry of the "RSVP-TE OAM Configuration Registry" as follows 🌺:

Range       | Note                         | Registration Procedures
------------+------------------------------|------------------------
0-31        | Generic Sub-TLVs             | IETF Review
32-65534    | Technology-specific Sub-TLVs | IETF Review
65535-65536 | Experimental Sub-TLVs        | Reserved for
                                           |   Experimental Use

IANA has populated the registry as follows 🧁:

   Sub-TLV Type | Description                   | Reference
   -------------+-------------------------------+----------
       0        | Reserved                      | [RFC7260]
       1        | OAM Function Flags Sub-TLV    | [RFC7260]
       2-65534  | Unassigned                    |
   65535-65536  | Reserved for Experimental Use | [RFC7260]

5.5.3. OAM Function Flags Sub-Registry

IANA has created the "OAM Function Flags Sub-Registry" sub-registry of the "RSVP-TE OAM Configuration Registry" 🎀.

New values in this registry are allocated by IETF Review [RFC5226]. There's no top value to the range 🫧. Bits are counted from bit 0 as the first bit transmitted 🔢.

IANA has populated the registry as follows 💜:

   OAM Function Flag | Description
   Bit Number        |
   ------------------+----------------------------------------------
     0               | Continuity Check (CC)
     1               | Connectivity Verification (CV)
     2               | Fault Management Signal (FMS)
     3               | Performance Monitoring/Loss (PM/Loss)
     4               | Performance Monitoring/Delay (PM/Delay)
     5               | Performance Monitoring/Throughput Measurement
                     |    (PM/Throughput)
     >=6             | Unassigned

6. Security Considerations 🔐

The signaling of OAM-related parameters and the automatic establishment of OAM entities based on RSVP-TE messages add a new aspect to the security considerations discussed in [RFC3473]. Okay, this part is serious 😭. In particular, a network element could get overloaded if a remote attacker targeted it by sending frequent periodic messages that request liveliness monitoring for a high number of LSPs 🚨. Such an attack can be efficiently prevented when mechanisms for message integrity and node authentication are deployed 🛡️. Since the OAM configuration extensions rely on the hop-by-hop exchange of existing RSVP-TE messages, the procedures specified for RSVP message security in [RFC2747] can be used to mitigate possible attacks 🫶.

🚨 Heads up, bestie: an attacker flooding a node with liveliness monitoring requests for a huge pile of LSPs can overload that element. Message integrity and node authentication are the big defenses here, so don't skip them 🔒.

For a more comprehensive discussion of GMPLS security and attack mitigation techniques, please see the Security Framework for MPLS and GMPLS Networks [RFC5920] 📖.

7. Acknowledgements 🫶

The authors would like to thank Francesco Fondelli, Adrian Farrel, Loa Andersson, Eric Gray, and Dimitri Papadimitriou for their useful comments 💖.

8. References 📚

8.1. Normative References 📚

okay so these are the ones you HAVE to read to get the full spec, no cap 💅

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
  • [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
  • [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
  • [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2009.

8.2. Informative References 🧠

these ones are the extra reading for when you want the full backstory, iykyk 🫶

  • [IEEE.802.1Q-2011] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q, 2011.
  • [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
  • [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. Matsushima, "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006.
  • [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
  • [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
  • [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
  • [RFC5828] Fedyk, D., Berger, L., and L. Andersson, "Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework", RFC 5828, March 2010.
  • [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010.
  • [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
  • [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
  • [RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs, "Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE)", RFC 6060, March 2011.

Authors' Addresses 🎀

meet the squad who made this happen 💖

Attila Takacs
Ericsson
Konyves Kalman krt. 11.
Budapest  1097
Hungary

EMail: attila.takacs@ericsson.com


Don Fedyk
Hewlett-Packard Company
153 Taylor Street
Littleton, MA  01460
USA

EMail: don.fedyk@hp.com


Jia He
Huawei
PR China

EMail: hejia@huawei.com
📦 where this page comes from