RFC 5860

Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks

📅 published May 2010, from ietf

RFC 5860: Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks 🎀

okay bestie, this one is RFC 5860, published in May 2010 as an IETF Standards Track document (ISSN 2070-1721) 💖. Three editors wrote it: M. Vigoureux from Alcatel-Lucent, D. Ward from Juniper Networks, and M. Betts from M. C. Betts Consulting Ltd. (they're all marked "Ed." for editor 🫶). The header doesn't list anything it obsoletes or updates, so there's no drama there ✨.

Abstract

this doc lists the architectural and functional requirements for the Operations, Administration, and Maintenance of the MPLS Transport Profile 🦋. the requirements cover pseudowires, Label Switched Paths, and Sections 🧚.

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 got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check Section 2 of RFC 5741 📚.

info about the current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc5860 🌸.

Copyright (c) 2010 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 of publication. please read these carefully, because they spell out your rights and restrictions for this document 🙈. any Code Components pulled out of this document must include the 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.  Scope of This Document . . . . . . . . . . . . . . . . . .  3
  1.2.  Requirements Language and Terminology  . . . . . . . . . .  4
2.  OAM Requirements . . . . . . . . . . . . . . . . . . . . . . .  5
  2.1.  Architectural Requirements . . . . . . . . . . . . . . . .  6
    2.1.1.  Scope of OAM . . . . . . . . . . . . . . . . . . . . .  6
    2.1.2.  Independence . . . . . . . . . . . . . . . . . . . . .  6
    2.1.3.  Data Plane . . . . . . . . . . . . . . . . . . . . . .  7
    2.1.4.  OAM and IP Capabilities  . . . . . . . . . . . . . . .  7
    2.1.5.  Interoperability and Interworking  . . . . . . . . . .  8
    2.1.6.  Configuration  . . . . . . . . . . . . . . . . . . . .  8
  2.2.  Functional Requirements  . . . . . . . . . . . . . . . . .  9
    2.2.1.  General Requirements . . . . . . . . . . . . . . . . .  9
    2.2.2.  Continuity Checks  . . . . . . . . . . . . . . . . . . 10
    2.2.3.  Connectivity Verifications . . . . . . . . . . . . . . 10
    2.2.4.  Route Tracing  . . . . . . . . . . . . . . . . . . . . 11
    2.2.5.  Diagnostic Tests . . . . . . . . . . . . . . . . . . . 11
    2.2.6.  Lock Instruct  . . . . . . . . . . . . . . . . . . . . 11
    2.2.7.  Lock Reporting . . . . . . . . . . . . . . . . . . . . 12
    2.2.8.  Alarm Reporting  . . . . . . . . . . . . . . . . . . . 12
    2.2.9.  Remote Defect Indication . . . . . . . . . . . . . . . 13
    2.2.10. Client Failure Indication  . . . . . . . . . . . . . . 13
    2.2.11. Packet Loss Measurement  . . . . . . . . . . . . . . . 13
    2.2.12. Packet Delay Measurement . . . . . . . . . . . . . . . 14
3.  Congestion Considerations  . . . . . . . . . . . . . . . . . . 15
4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
  6.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
  6.2.  Informative References . . . . . . . . . . . . . . . . . . 16

1. Introduction ✨

so in the MPLS Transport Profile world (MPLS-TP, see [9] and [1]) 🌈, OAM (Operations, Administration, and Maintenance) has two big jobs. it can serve as:

  • a network-oriented thing 🛠️. a transport network operator uses it to keep an eye on their infrastructure and to run internal mechanisms that make the network work better and perform better. think protection mechanisms when a node or link goes down. fault localization is the classic example here 🔍.
  • a service-oriented thing 💼. a transport service provider uses it to watch the services they sell to end customers, so they can react fast when something goes wrong and check some of the Service Level Agreement (SLA) parameters negotiated with those customers (performance monitoring is a common way to do that). fun fact: a transport service can run across several networks or administrative domains that aren't all owned and managed by the same provider 🌍.

OAM is basically a main character in transport networks 👑, because it helps with:

  • cutting operational complexity and costs 💸. it lets you detect, locate, handle, and diagnose defects efficiently and automatically, and it keeps service interruptions and repair times short.
  • boosting network availability 📈. defects (like ones that send customer traffic to the wrong place) and faults get caught, diagnosed, and dealt with before a customer has to complain 🙌.
  • hitting service and performance goals 🎯. OAM lets you verify SLAs in a multi-maintenance domain environment and figure out when service is degrading, for example because of packet delay or packet loss.

1.1. Scope of This Document

this doc lists the architectural and functional requirements for OAM in MPLS-TP 💅. the requirements apply to pseudowires (PWs), Label Switched Paths (LSPs), and Sections 🦋.

these requirements come from the set that ITU-T specified and published in the ITU-T Supplement Y.Sup4 [10] 📖.

since they cover transport specifics, these requirements complement the ones in RFC 4377 [11]. still, some of them may look alike 🫶.

this document only lists architectural and functional OAM requirements. it doesn't go into how they apply to the different types of PWs, LSPs, and Sections (point-to-point, point-to-multipoint, unidirectional, bidirectional, and so on) 🙈. it also doesn't set requirements on how the protocol solution(s) should behave to hit the functional goals. for that, check out [12] 🔎.

the OAM functions in here can be used for fault management, performance monitoring, and/or protection switching 🔥. for example, connectivity verification can detect failure conditions for fault management, and it can also feed into performance monitoring by helping evaluate metrics like unavailability time 📊. but deciding which function goes with which application is outside this document's scope 🤷‍♀️.

one more thing: implementers may want to build OAM message handling into hardware 🔧. that's not a requirement, but it could be treated as a design consideration 💜.

1.2. Requirements Language and Terminology

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in RFC 2119 [2] 📝. this doc isn't a protocol spec, but using this language makes the instructions clearer for protocol designers building solutions that meet these requirements 🫶.

here's the vocab we're using 📚:

  • when a function can't do a required action, that's a fault 💥. this doesn't include an inability caused by preventive maintenance, a lack of external resources, or planned actions. see also ITU-T G.806 [3].
  • when anomalies get dense enough that a function can no longer perform a required function, that's a defect. see also ITU-T G.806 [3] 🚨.
  • OAM actions that run continuously, or at least over long stretches of time, and report fault and/or performance results before anyone asks are called proactive OAM 🌸.
  • OAM actions that someone starts by hand for a limited time to troubleshoot are called on-demand OAM 🧰.
  • for a given LSP or Section, a Label Edge Router (LER) counts as an End Point. for a given PW, a PW Terminating Provider Edge (T-PE) counts too 🏁. for a given LSP, a Label Switching Router (LSR) is an Intermediate Point, and for a given PW, a PW Switching Provider Edge (S-PE) is one too 🔁. this doc doesn't split End Points into source and destination, since you can usually tell from the context of the sentence 🙃.
  • "node" is the general term for End Points and Intermediate Points 🧩.
  • "segment" covers both segment and concatenated segments. for definitions of "segment" and other MPLS-TP terms, see [1] 🔗.
  • single segment PWs and multi-segment PWs both get called PWs 🎀.
  • bidirectional associated LSPs and bidirectional co-routed LSPs both get called bidirectional LSPs 💖.

2. OAM Requirements 🌷

this section lists the requirements that the OAM functionality of MPLS-TP should follow 🫶.

the requirements below can be met by one or more OAM protocols. picking or defining those protocols is outside this document's scope 🙌.

RFC 5654 [1] says (Requirement #2) that the MPLS-TP design, SHOULD as far as reasonably possible, reuse existing MPLS standards 💅. this general requirement applies to MPLS-TP OAM too. MPLS-TP OAM is defined in this document through a set of functional requirements, and those will be met by protocol solutions defined in other documents 🦋. the way those protocols get operated, and the way a network operator controls and uses the MPLS-TP OAM functions, SHOULD be as similar as possible to the mechanisms and techniques used to operate OAM in other transport technologies ✨.

2.1. Architectural Requirements

(more of the slay continues in part 2 🎀💖)

2.1.1. Scope of OAM ✨

okay bestie, so the protocol solution(s) we build for these requirements MUST at least work for point-to-point bidirectional PWs, point-to-point co-routed bidirectional LSPs, and point-to-point bidirectional Sections 💖. Section 2.2 has the extra tea on point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs 🦋.

The service a PW emulates can span multiple domains 🌈, and an LSP can span multiple domains too. The protocol solution(s) MUST be applicable to end-to-end and to segments. More generally, it MUST be possible to operate OAM functions on a per-domain basis and across multiple domains 👑.

Since LSPs can be stacked 🧚, the protocol solution(s) MUST be applicable on any LSP, regardless of the label stack depth. Furthermore, it MUST be possible to estimate OAM fault and performance metrics of a single PW or LSP segment, or of an aggregate of PW or LSP segments 📊.

2.1.2. Independence

The protocol solution(s) SHOULD be independent of the underlying tunneling or point-to-point technology or transmission media 🫶.

The protocol solution(s) SHOULD be independent of the service a PW may emulate 💅.

Any OAM function operated on a PW, LSP, or Section SHOULD be independent of the OAM function(s) operated on a different PW, LSP, or Section. In other words, only the OAM functions operated on a given LSP (for example) should be used to achieve the OAM objectives for that LSP 🎀.

The protocol solution(s) MUST support the capability to be concurrently and independently operated end-to-end and on segments. Therefore, any OAM function applied to segment(s) of a PW or LSP SHOULD be independent of the OAM function(s) operated on the end-to-end PW or LSP. It SHOULD also be possible to distinguish an OAM packet running over a segment of a PW or LSP from another OAM packet running on the end-to-end PW or LSP 🌸.

Furthermore, any OAM function applied to segment(s) of a PW or LSP SHOULD be independent of the OAM function(s) applied to other segment(s) of the same PW or LSP.

Note: Independence should not be understood in terms of isolation as there can be interactions between OAM functions operated, for example, on two different LSPs. 🙈

2.1.3. Data Plane

OAM functions operate in the data plane. OAM packets MUST run in-band. That is, OAM packets for a specific PW, LSP, or Section MUST follow the exact same data path as user traffic of that PW, LSP, or Section. This is often referred to as fate sharing 🍓.

It MUST be possible to discriminate user traffic from OAM packets. This includes a means to differentiate OAM packets from user traffic, as well as the capability to apply specific treatment to OAM packets at the nodes processing these OAM packets 🔥.

As part of the design of OAM protocol solution(s) for MPLS-TP, a mechanism for enabling the encapsulation and differentiation of OAM messages on a PW, LSP, or Section MUST be provided. Such mechanism SHOULD also support the encapsulation and differentiation of existing IP/MPLS and PW OAM messages 💜.

2.1.4. OAM and IP Capabilities

There are environments where IP capabilities are present in the data plane, and IP/MPLS environments are examples of such environments. There are also environments where IP capabilities may not be present in the data plane. MPLS-TP environments are examples of environments where IP capabilities might or might not be present 🦋.

Note: Presence or absence of IP capabilities is deployment scenario dependent. ✨

It MUST be possible to deploy the OAM functionality in any of these environments. As a result, it MUST be possible to operate OAM functions with or without relying on IP capabilities, and it MUST be possible to choose to make use of IP capabilities when these are present 💖.

Furthermore, the mechanism required for enabling the encapsulation and differentiation of OAM messages (see Section 2.1.3) MUST support the capability to differentiate OAM messages of an OAM function operated by relying on IP capabilities (e.g., using encapsulation in an IP header) from OAM messages of an OAM function operated without relying on any IP capability 👑.

Note that IP capabilities include the capability to form a standard IP header, to encapsulate a payload in an IP header, to parse and analyze the fields of an IP header, and to take actions based on the content of these fields 🧚.

For certain functions, OAM messages need to incorporate identification information (e.g., of source and/or destination nodes). The protocol solution(s) MUST at least support identification information in the form of an IP addressing structure, and MUST also be extensible to support additional identification schemes 🌈.

2.1.5. Interoperability and Interworking

It is REQUIRED that OAM interoperability is achieved between distinct domains materializing the environments described in Section 2.1.4. It is also REQUIRED that the first two requirements of Section 2.1.4 still hold and MUST still be met when interoperability is achieved 🫶.

When MPLS-TP is run with IP routing and forwarding capabilities, it MUST be possible to operate any of the existing IP/MPLS and PW OAM protocols (e.g., LSP-Ping [4], MPLS-BFD [13], VCCV [5], and VCCV-BFD [14]) 🔥.

2.1.6. Configuration

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 ⭐.

In the latter case, the customer MUST NOT perceive service degradation as a result of OAM enabling/disabling. Ideally, OAM enabling/disabling should take place without introducing any customer impairments (e.g., no customer packet losses). Procedures aimed to prevent any traffic impairment MUST be defined for the enabling/disabling of OAM functions 💅.

Means for configuring OAM functions and for connectivity management are outside the scope of this document.

2.2. Functional Requirements

Hereafter are listed the required functionalities composing the MPLS-TP OAM toolset. The list may not be exhaustive, and as such the OAM mechanisms developed in support of the identified requirements SHALL be extensible and thus SHALL NOT preclude the definition of additional OAM functionalities in the future 🌸.

The design of OAM mechanisms for MPLS-TP, MUST allow for the ability to support experimental OAM functions. These functions MUST be disabled by default 🙈.

The use of any OAM function MUST be optional, and it MUST be possible to select the set of OAM function(s) to use on any PW, LSP, or Section 🎀.

It is RECOMMENDED that any protocol solution, meeting one or more functional requirement(s), be the same for PWs, LSPs, and Sections 💜.

It is RECOMMENDED that any protocol solution, meeting one or more functional requirement(s), effectively provides a fully featured function; that is, a function that is applicable to all the cases identified for that functionality. In that context, protocol solution(s) MUST state their applicability 👑.

Unless otherwise stated, the OAM functionalities MUST NOT rely on user traffic. That is, only OAM messages MUST be used to achieve the objectives 🔥.

For the on-demand OAM functions, the result of which may vary depending on packet size, it SHOULD be possible to perform these functions using different packet sizes 🍓.

2.2.1. General Requirements

If a defect or fault occurs on a PW, LSP, or Section, mechanisms MUST be provided to detect it, diagnose it, localize it, and notify the appropriate nodes. Mechanisms SHOULD exist such that corrective actions can be taken 🧚.

Furthermore, mechanisms MUST be available for a service provider to be aware of a fault or defect affecting the service(s) he provides, even if the fault or defect is located outside of his domain 🌈.

Protocol solution(s) developed to meet these requirements may rely on information exchange. Information exchange between various nodes involved in the operation of an OAM function SHOULD be reliable, such that, for example, defects or faults are properly detected or that state changes are effectively known by the appropriate nodes 🫶.

2.2.2. Continuity Checks

The MPLS-TP OAM toolset MUST provide a function to enable an End Point to monitor the liveness of a PW, LSP, or Section 💖.

This function SHOULD be performed between End Points of PWs, LSPs, and Sections ✨.

This function SHOULD be performed proactively 🦋.

The protocol solution(s) developed to perform this function MUST also apply to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs 💅.

2.2.3. Connectivity Verifications

The MPLS-TP OAM toolset MUST provide a function to enable an End Point to determine whether or not it is connected to specific End Point(s) by means of the expected PW, LSP, or Section 🎀.

This function SHOULD be performed proactively between End Points of PWs, LSPs, and Sections 🌸.

This function SHOULD be performed on-demand between End Points and Intermediate Points of PWs and LSPs, and between End Points of PWs, LSPs, and Sections 💜.

The protocol solution(s) developed to perform this function proactively MUST also apply to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs 👑.

The protocol solution(s) developed to perform this function on-demand MAY also apply to point-to-point associated bidirectional LSPs, to point-to-point unidirectional LSPs, and point-to-multipoint LSPs in case a return path exists 🔥.

2.2.4. Route Tracing

The MPLS-TP OAM toolset MUST provide functionality to enable an End Point to discover the Intermediate (if any) and End Point(s) along a PW, LSP, or Section, and more generally to trace the route of a PW, LSP, or Section. The information collected MUST include identifiers related to the nodes and interfaces composing that route 🍓.

This function SHOULD be performed on-demand 🧚.

This function SHOULD be performed between End Points and Intermediate Points of PWs and LSPs, and between End Points of PWs, LSPs, and Sections 🌈.

The protocol solution(s) developed to perform this function MAY also apply to point-to-point associated bidirectional LSPs, to point-to-point unidirectional LSPs, and point-to-multipoint LSPs in case a return path exists 🫶.

2.2.5. Diagnostic Tests

The MPLS-TP OAM toolset MUST provide a function to enable conducting diagnostic tests on a PW, LSP, or Section. An example of such a diagnostic test consists of performing a loop-back function at a node such that all OAM and data traffic are looped back to the originating End Point. Another example of such diagnostic test consists in estimating the bandwidth of, e.g., an LSP 💖.

This function SHOULD be performed on-demand 🎀.

This function SHOULD be performed between End Points and Intermediate Points of PWs and LSPs, and between End Points of PWs, LSPs, and Sections 💅.

The protocol solution(s) developed to perform this function MAY also apply to point-to-point associated bidirectional LSPs, to point-to-point unidirectional LSPs and point-to-multipoint LSPs, in case a return path exists 👑.

2.2.6. Lock Instruct 🔒

Okay bestie, the MPLS-TP OAM toolset MUST give an End Point of a PW, LSP, or Section a way to tell its associated End Point(s) to lock that PW, LSP, or Section. Lock is an administrative status, and in that state only test traffic (if there is any) and OAM dedicated to that PW, LSP, or Section are expected to be mapped onto it. 🎀

This one SHOULD be done on-demand. ✨

It SHOULD be performed between End Points of PWs, LSPs, and Sections. 💖

The protocol solution(s) built for this MUST also work for point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs. 💅

2.2.7. Lock Reporting 🫶

Because of how MPLS tunneling works, sometimes an Intermediate Point of a PW or LSP lands on the same spot as an End Point of some other LSP that the first one is tunneled through. 🧚 And it can totally happen that the tunnel LSP goes out of service because someone locked it. Lowkey wild. 😭 Outside this document's scope, the Intermediate Point(s) of the PW or LSP might find out about this. The MPLS-TP OAM toolset MUST provide a function that lets an Intermediate Point of a PW or LSP report a lock condition that indirectly affects that PW or LSP to an End Point of that same PW or LSP. 🌸

This one SHOULD be done proactively. ⭐

It SHOULD be performed between Intermediate Points and End Points of PWs and LSPs. 🦋

The protocol solution(s) built for this MUST also work for point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs. 💜

2.2.8. Alarm Reporting 🚨

Same tunneling story as before: Intermediate Point(s) of a PW or LSP can end up coinciding with End Point(s) of another LSP that the former is mapped/tunneled onto. 🎀 The tunnel LSP might be out of service because of a fault on that tunnel LSP. Outside this document's scope, the Intermediate Point(s) of the PW or LSP may be aware of this. The MPLS-TP OAM toolset MUST provide functionality that lets an Intermediate Point of a PW or LSP report a fault or defect condition that indirectly affects that PW or LSP to an End Point of that same PW or LSP. 🔥

This one SHOULD be done proactively. 🌈

It SHOULD be performed between Intermediate Points and End Points of PWs and LSPs. 🍓

The protocol solution(s) built for this MUST also work for point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs. 👑

2.2.9. Remote Defect Indication 🧚‍♀️

The MPLS-TP OAM toolset MUST provide a function that lets an End Point tell its associated End Point about a fault or defect condition it detects on a PW, LSP, or Section they are both the End Points of. Basically, "hey bestie, I'm seeing a problem on our link" 💌

This one SHOULD be done proactively. ✨

It SHOULD be performed between End Points of PWs, LSPs, and Sections. 🦋

The protocol solution(s) built for this MUST also work for point-to-point associated bidirectional LSPs. It MAY also work for point-to-point unidirectional LSPs and point-to-multipoint LSPs, but only in case a return path exists. 🔙

2.2.10. Client Failure Indication 🎀

The MPLS-TP OAM toolset MUST provide a function that spreads information about a client defect or fault condition from edge to edge of an MPLS-TP network. The client here means something external to the MPLS-TP network, and the defect is one detected at an End Point of a PW or LSP. This only applies if the client layer OAM doesn't already have its own alarm notification/propagation. 💅

This one SHOULD be done proactively. 🌸

It SHOULD be performed between End Points of PWs and LSPs. 💖

The protocol solution(s) built for this MUST also work for point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs. 🌈

2.2.11. Packet Loss Measurement 📉

The MPLS-TP OAM toolset MUST provide a function that quantifies the packet loss ratio over a PW, LSP, or Section. 🧮

The loss of a packet is defined in RFC2680 [6] (see Section 2.4), and this document uses that definition. 📖

Packet-loss ratio is defined here as the ratio of the number of user packets lost to the total number of user packets sent during a defined time interval. 🍓

This function MAY be performed either proactively or on-demand. 🌙

This one SHOULD be performed between End Points of PWs, LSPs, and Sections. 💜

It SHOULD be possible to rely on user traffic to do this job. Honestly the best kind of free data. 🫶

The protocol solution(s) built for this MUST also work for point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs. 👑

2.2.12. Packet Delay Measurement ⏱️

The MPLS-TP OAM toolset MUST provide a function that quantifies the one-way and, when it makes sense, the two-way delay of a PW, LSP, or Section. ⏳

  • One-way delay is defined in [7]: the time from when an End Point starts sending the first bit of a packet until the other End Point receives the last bit of that packet. ➡️
  • Two-way delay is defined in [8]: the time from when an End Point starts sending the first bit of a packet until that same End Point receives the last bit of that packet. 🔁

Two-way delay can be measured using data traffic loopback at the remote End Point of the PW, LSP, or Section (see Section 2.2.5). Clever, right? 🧠

Accurate one-way delay measurement might need clock synchronization. The means for that are outside the scope of this document. ⏰

This one SHOULD be done on-demand and MAY also be done proactively. ✨

It SHOULD be performed between End Points of PWs, LSPs, and Sections. 🦋

The protocol solution(s) built for this MUST also work for point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs, but only to measure the one-way delay. 💖

3. Congestion Considerations 🚦

A mechanism (e.g., rate limiting) MUST be provided to stop OAM packets from causing congestion in the Packet Switched Network. Don't let your OAM become the drama. 🙅‍♀️

4. Security Considerations 🔐

This document, in itself, does not imply any security consideration, but OAM, as such, is subject to several security considerations. OAM messages can reveal sensitive information such as passwords, performance data, and details about, e.g., the network topology. Yikes. 💀

The nature of OAM therefore suggests having some form of authentication, authorization, and encryption in place. This will prevent unauthorized access to MPLS-TP equipment and will stop third parties from learning sensitive information about the transport network. Lock it down, babe. 🔒

OAM systems (network management stations) SHOULD be designed so that OAM functions cannot be accessed without authorization. 🛡️

OAM protocol solutions MUST include the facility for OAM messages to authenticated to prove their origin and to make sure that they are destined for the receiving node. The use of such facilities MUST be configurable. 🪪

An OAM packet received over a PW, LSP, or Section MUST NOT be forwarded beyond the End Point of that PW, LSP, or Section, so that the OAM packet does not leave the current administrative domain. Absolutely no leaking. 🚫

5. Acknowledgements 🫶

The editors gratefully acknowledge the contributions of Matthew Bocci, Italo Busi, Thomas Dietz, Annamaria Fulignoli, Huub van Helvoort, Enrique Hernandez-Valencia, Wataru Imajuku, Kam Lam, Marc Lasserre, Lieven Levrau, Han Li, Julien Meuric, Philippe Niger, Benjamin Niven-Jenkins, Jing Ruiquan, Nurit Sprecher, Yuji Tochio, Satoshi Ueno, and Yaacov Weingarten. Legends. 👑

The authors would like to thank all members of the teams (the Joint Working Team, the MPLS Interoperability Design Team in IETF, and the MPLS-TP Ad Hoc Group in ITU-T) who worked on defining and specifying MPLS-TP. Teamwork makes the dream work. 💕

6. References 📚

6.1. Normative References

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

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

[3] ITU-T Recommendation G.806, "Characteristics of transport equipment - Description methodology and generic functionality", 2009.

[4] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.

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

[6] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.

[7] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.

[8] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999.

6.2. Informative References

[9] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", Work in Progress, May 2010.

[10] ITU-T Supplement Y.Sup4, "ITU-T Y.1300-series: Supplement on transport requirements for T-MPLS OAM and considerations for the application of IETF MPLS technology", 2008.

[11] 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.

[12] Busi, I., Ed., Niven-Jenkins, B., Ed., and D. Allan, Ed., "MPLS-TP OAM Framework", Work in Progress, April 2010.

[13] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD For MPLS LSPs", Work in Progress, June 2008.

[14] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", Work in Progress, July 2009.

Authors' Addresses 💌

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

EMail: martin.vigoureux@alcatel-lucent.com

David Ward (editor) Juniper Networks

EMail: dward@juniper.net

Malcolm Betts (editor) M. C. Betts Consulting Ltd.

EMail: malcolm.betts@rogers.com 🧡

📦 where this page comes from