RFC 6371
Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks
Internet Engineering Task Force (IETF) I. Busi, Ed. Request for Comments: 6371 Alcatel-Lucent Category: Informational D. Allan, Ed. ISSN: 2070-1721 Ericsson September 2011 Operations, Administration, and Maintenance Framework for MPLS-Based Transport NetworksAbstract
The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS Traffic Engineering (MPLS-TE) and pseudowire (PW) data-plane architectures. This document describes a framework to support a comprehensive set of Operations, Administration, and Maintenance (OAM) procedures that fulfill the MPLS-TP OAM requirements for fault, performance, and protection-switching management and that do not rely on the presence of a control plane. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6371.
Copyright Notice 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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to 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 are provided without warranty as described in the Simplified BSD License.Table of Contents
1. Introduction ....................................................3 2. Conventions Used in This Document ...............................5 2.1. Terminology ................................................5 2.2. Definitions ................................................7 3. Functional Components ..........................................10 3.1. Maintenance Entity and Maintenance Entity Group ...........10 3.2. MEG Nesting: SPMEs and Tandem Connection Monitoring .......13 3.3. MEG End Points (MEPs) .....................................14 3.4. MEG Intermediate Points (MIPs) ............................18 3.5. Server MEPs ...............................................20 3.6. Configuration Considerations ..............................21 3.7. P2MP Considerations .......................................21 3.8. Further Considerations of Enhanced Segment Monitoring .....22 4. Reference Model ................................................23 4.1. MPLS-TP Section Monitoring (SMEG) .........................26 4.2. MPLS-TP LSP End-to-End Monitoring Group (LMEG) ............27 4.3. MPLS-TP PW Monitoring (PMEG) ..............................27 4.4. MPLS-TP LSP SPME Monitoring (LSMEG) .......................28 4.5. MPLS-TP MS-PW SPME Monitoring (PSMEG) .....................30 4.6. Fate-Sharing Considerations for Multilink .................31 5. OAM Functions for Proactive Monitoring .........................32 5.1. Continuity Check and Connectivity Verification ............33 5.1.1. Defects Identified by CC-V .........................35 5.1.2. Consequent Action ..................................37 5.1.3. Configuration Considerations .......................38 5.2. Remote Defect Indication ..................................40 5.2.1. Configuration Considerations .......................40 5.3. Alarm Reporting ...........................................41 5.4. Lock Reporting ............................................42 5.5. Packet Loss Measurement ...................................44 5.5.1. Configuration Considerations .......................45
5.5.2. Sampling Skew ......................................45
5.5.3. Multilink Issues ...................................45
5.6. Packet Delay Measurement ..................................46
5.6.1. Configuration Considerations .......................46
5.7. Client Failure Indication .................................47
5.7.1. Configuration Considerations .......................47
6. OAM Functions for On-Demand Monitoring .........................48
6.1. Connectivity Verification .................................48
6.1.1. Configuration Considerations .......................49
6.2. Packet Loss Measurement ...................................50
6.2.1. Configuration Considerations .......................50
6.2.2. Sampling Skew ......................................50
6.2.3. Multilink Issues ...................................50
6.3. Diagnostic Tests ..........................................50
6.3.1. Throughput Estimation ..............................51
6.3.2. Data-Plane Loopback ................................52
6.4. Route Tracing .............................................54
6.4.1. Configuration Considerations .......................54
6.5. Packet Delay Measurement ..................................54
6.5.1. Configuration Considerations .......................55
7. OAM Functions for Administration Control .......................55
7.1. Lock Instruct .............................................55
7.1.1. Locking a Transport Path ...........................56
7.1.2. Unlocking a Transport Path .........................56
8. Security Considerations ........................................57
9. Acknowledgments ................................................58
10. References ....................................................58
10.1. Normative References .....................................58
10.2. Informative References ...................................59
11. Contributing Authors ..........................................60
1. Introduction
As noted in the MPLS Transport Profile (MPLS-TP) framework RFCs (RFC
5921 [8] and RFC 6215 [9]), MPLS-TP is a packet-based transport
technology based on the MPLS Traffic Engineering (MPLS-TE) and
pseudowire (PW) data-plane architectures defined in RFC 3031 [1], RFC
3985 [2], and RFC 5659 [4].
MPLS-TP utilizes a comprehensive set of Operations, Administration,
and Maintenance (OAM) procedures for fault, performance, and
protection-switching management that do not rely on the presence of a
control plane.
In line with [15], existing MPLS OAM mechanisms will be used wherever
possible, and extensions or new OAM mechanisms will be defined only
where existing mechanisms are not sufficient to meet the
requirements. Some extensions discussed in this framework may end up
as aspirational capabilities and may be determined to be not tractably realizable in some implementations. Extensions do not deprecate support for existing MPLS OAM capabilities. The MPLS-TP OAM framework defined in this document provides a protocol-neutral description of the required OAM functions and of the data-plane OAM architecture to support a comprehensive set of OAM procedures that satisfy the MPLS-TP OAM requirements of RFC 5860 [11]. In this regard, it defines similar OAM functionality as for existing Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Network (OTN) OAM mechanisms (e.g., [19]). The MPLS-TP OAM framework is applicable to Sections, Label Switched Paths (LSPs), Multi-Segment Pseudowires (MS-PWs), and Sub-Path Maintenance Elements (SPMEs). It supports co-routed and associated bidirectional P2P transport paths as well as unidirectional P2P and P2MP transport paths. OAM packets that instrument a particular direction of a transport path are subject to the same forwarding treatment (i.e., fate-share) as the user data packets and in some cases, where Explicitly TC- encoded-PSC LSPs (E-LSPs) are employed, may be required to have common per-hop behavior (PHB) Scheduling Class (PSC) End-to-End (E2E) with the class of traffic monitored. In case of Label-Only-Inferred- PSC LSP (L-LSP), only one class of traffic needs to be monitored, and therefore the OAM packets have common PSC with the monitored traffic class. OAM packets can be distinguished from the used data packets using the Generic Associated Channel Label (GAL) and Associated Channel Header (ACH) constructs of RFC 5586 [7] for LSP, SPME, and Section, or the ACH construct of RFC 5085 [3] and RFC 5586 [7] for (MS-)PW. OAM packets are never fragmented and are not combined with user data in the same packet payload. This framework makes certain assumptions as to the utility and frequency of different classes of measurement that naturally suggest different functions are implemented as distinct OAM flows or packets. This is dictated by the combination of the class of problem being detected and the need for timeliness of network response to the problem. For example, fault detection is expected to operate on an entirely different time base than performance monitoring, which is also expected to operate on an entirely different time base than in- band management transactions.
The remainder of this memo is structured as follows: Section 2 covers the definitions and terminology used in this memo. Section 3 describes the functional component that generates and processes OAM packets. Section 4 describes the reference models for applying OAM functions to Sections, LSP, MS-PW, and their SPMEs. Sections 5, 6, and 7 provide a protocol-neutral description of the OAM functions, defined in RFC 5860 [11], aimed at clarifying how the OAM protocol solutions will behave to achieve their functional objectives. Section 8 discusses the security implications of OAM protocol design in the MPLS-TP context. The OAM protocol solutions designed as a consequence of this document are expected to comply with the functional behavior described in Sections 5, 6, and 7. Alternative solutions to required functional behaviors may also be defined. OAM specifications following this OAM framework may be provided in different documents to cover distinct OAM functions. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.2. Conventions Used in This Document
2.1. Terminology
AC Attachment Circuit AIS Alarm Indication Signal CC Continuity Check CC-V Continuity Check and Connectivity Verification CV Connectivity Verification DBN Domain Border Node
E-LSP Explicitly TC-encoded-PSC LSP ICC ITU Carrier Code LER Label Edge Router LKR Lock Report L-LSP Label-Only-Inferred-PSC LSP LM Loss Measurement LME LSP Maintenance Entity LMEG LSP ME Group LSP Label Switched Path LSR Label Switching Router LSME LSP SPME ME LSMEG LSP SPME ME Group ME Maintenance Entity MEG Maintenance Entity Group MEP Maintenance Entity Group End Point MIP Maintenance Entity Group Intermediate Point NMS Network Management System PE Provider Edge PHB Per-Hop Behavior PM Performance Monitoring PME PW Maintenance Entity PMEG PW ME Group PSC PHB Scheduling Class PSME PW SPME ME
PSMEG PW SPME ME Group PW Pseudowire SLA Service Level Agreement SME Section Maintenance Entity SMEG Section ME Group SPME Sub-Path Maintenance Element S-PE Switching Provider Edge TC Traffic Class T-PE Terminating Provider Edge2.2. Definitions
This document uses the terms defined in RFC 5654 [5]. This document uses the term 'per-hop behavior' as defined in RFC 2474 [16]. This document uses the term 'LSP' to indicate either a service LSP or a transport LSP (as defined in RFC 5921 [8]). This document uses the term 'Section' exclusively to refer to the n=0 case of the term 'Section' defined in RFC 5960 [10]. This document uses the term 'Sub-Path Maintenance Element (SPME)' as defined in RFC 5921 [8]. This document uses the term 'traffic profile' as defined in RFC 2475 [13]. Where appropriate, the following definitions are aligned with ITU-T recommendation Y.1731 [21] in order to have a common, unambiguous terminology. They do not however intend to imply a certain implementation but rather serve as a framework to describe the necessary OAM functions for MPLS-TP. Adaptation function: The adaptation function is the interface between the client (sub-)layer and the server (sub-)layer. Branch Node: A node along a point-to-multipoint transport path that is connected to more than one downstream node.
Bud Node: A node along a point-to-multipoint transport path that is
at the same time a branch node and a leaf node for this transport
path.
Data-plane loopback: An out-of-service test where a transport path at
either an intermediate or terminating node is placed into a data-
plane loopback state, such that all traffic (including both payload
and OAM) received on the looped back interface is sent on the reverse
direction of the transport path.
Note: The only way to send an OAM packet to a node that has been
put into data-plane loopback mode is via Time to Live (TTL)
expiry, irrespective of whether the node is hosting MIPs or MEPs.
Domain Border Node (DBN): An intermediate node in an MPLS-TP LSP that
is at the boundary between two MPLS-TP OAM domains. Such a node may
be present on the edge of two domains or may be connected by a link
to the DBN at the edge of another OAM domain.
Down MEP: A MEP that receives OAM packets from, and transmits them
towards, the direction of a server layer.
Forwarding Engine: An abstract functional component, residing in an
LSR, that forwards the packets from an ingress interface toward the
egress interface(s).
In-Service: The administrative status of a transport path when it is
unlocked.
Interface: An interface is the attachment point to a server
(sub-)layer, e.g., a MPLS-TP Section or MPLS-TP tunnel.
Intermediate Node: An intermediate node transits traffic for an LSP
or a PW. An intermediate node may originate OAM flows directed to
downstream intermediate nodes or MEPs.
Loopback: See data-plane loopback and OAM loopback definitions.
Maintenance Entity (ME): Some portion of a transport path that
requires management bounded by two points (called MEPs), and the
relationship between those points to which maintenance and monitoring
operations apply (details in Section 3.1).
Maintenance Entity Group (MEG): The set of one or more maintenance
entities that maintain and monitor a section or a transport path in
an OAM domain.
MEP: A MEG End Point (MEP) is capable of initiating (source MEP) and terminating (sink MEP) OAM packets for fault management and performance monitoring. MEPs define the boundaries of an ME (details in Section 3.3). MIP: A MEG intermediate point (MIP) terminates and processes OAM packets that are sent to this particular MIP and may generate OAM packets in reaction to received OAM packets. It never generates unsolicited OAM packets itself. A MIP resides within a MEG between MEPs (details in Section 3.3). OAM domain: A domain, as defined in [5], whose entities are grouped for the purpose of keeping the OAM confined within that domain. An OAM domain contains zero or more MEGs. Note: Within the rest of this document, the term "domain" is used to indicate an "OAM domain". OAM flow: The set of all OAM packets originating with a specific source MEP that instrument one direction of a MEG (or possibly both in the special case of data-plane loopback). OAM loopback: The capability of a node to be directed by a received OAM packet to generate a reply back to the sender. OAM loopback can work in-service and can support different OAM functions (e.g., bidirectional on-demand connectivity verification). OAM Packet: A packet that carries OAM information between MEPs and/or MIPs in a MEG to perform some OAM functionality (e.g., connectivity verification). Originating MEP: A MEP that originates an OAM transaction packet (toward a target MIP/MEP) and expects a reply, either in-band or out- of-band, from that target MIP/MEP. The originating MEP always generates the OAM request packets in-band and expects and processes only OAM reply packets returned by the target MIP/MEP. Out-of-Service: The administrative status of a transport path when it is locked. When a path is in a locked condition, it is blocked from carrying client traffic. Path Segment: It is either a segment or a concatenated segment, as defined in RFC 5654 [5]. Signal Degrade: A condition declared by a MEP when the data forwarding capability associated with a transport path has deteriorated, as determined by performance monitoring (PM). See also ITU-T recommendation G.806 [14].
Signal Fail: A condition declared by a MEP when the data forwarding capability associated with a transport path has failed, e.g., loss of continuity. See also ITU-T recommendation G.806 [14]. Sink MEP: A MEP acts as a sink MEP for an OAM packet when it terminates and processes the packets received from its associated MEG. Source MEP: A MEP acts as source MEP for an OAM packet when it originates and inserts the packet into the transport path for its associated MEG. Tandem Connection: A tandem connection is an arbitrary part of a transport path that can be monitored (via OAM) independent of the end-to-end monitoring (OAM). The tandem connection may also include the forwarding engine(s) of the node(s) at the boundaries of the tandem connection. Tandem connections may be nested but cannot overlap. See also ITU-T recommendation G.805 [20]. Target MEP/MIP: A MEP or a MIP that is targeted by OAM transaction packets and that replies to the originating MEP that initiated the OAM transactions. The target MEP or MIP can reply either in-band or out-of-band. The target sink MEP function always receives the OAM request packets in-band, while the target source MEP function only generates the OAM reply packets that are sent in-band. Up MEP: A MEP that transmits OAM packets towards, and receives them from, the direction of the forwarding engine.3. Functional Components
MPLS-TP is a packet-based transport technology based on the MPLS and PW data plane architectures ([1], [2], and [4]) and is capable of transporting service traffic where the characteristics of information transfer between the transport path end points can be demonstrated to comply with certain performance and quality guarantees. In order to describe the required OAM functionality, this document introduces a set of functional components.3.1. Maintenance Entity and Maintenance Entity Group
MPLS-TP OAM operates in the context of Maintenance Entities (MEs) that define a relationship between two points of a transport path to which maintenance and monitoring operations apply. The two points that define a maintenance entity are called Maintenance Entity Group End Points (MEPs). The collection of one or more MEs that belongs to the same transport path and that are maintained and monitored as a
group are known as a Maintenance Entity Group (MEG). In between MEPs, there are zero or more intermediate points, called Maintenance Entity Group Intermediate Points (MIPs). MEPs and MIPs are associated with the MEG and can be shared by more than one ME in a MEG. An abstract reference model for an ME is illustrated in Figure 1 below. +-+ +-+ +-+ +-+ |A|----|B|----|C|----|D| +-+ +-+ +-+ +-+ Figure 1: ME Abstract Reference Model The instantiation of this abstract model to different MPLS-TP entities is described in Section 4. In Figure 1, nodes A and D can be Label Edge Routers (LERs) for an LSP or the Terminating Provider Edges (T-PEs) for an MS-PW, nodes B and C are LSRs for an LSP or Switching PEs (S-PEs) for an MS-PW. MEPs reside in nodes A and D, while MIPs reside in nodes B and C and may reside in A and D. The links connecting adjacent nodes can be physical links, (sub-)layer LSPs/SPMEs, or server-layer paths. This functional model defines the relationships between all OAM entities from a maintenance perspective and it allows each Maintenance Entity to provide monitoring and management for the (sub-)layer network under its responsibility and efficient localization of problems. An MPLS-TP Maintenance Entity Group may be defined to monitor the transport path for fault and/or performance management. The MEPs that form a MEG bound the scope of an OAM flow to the MEG (i.e., within the domain of the transport path that is being monitored and managed). There are two exceptions to this: 1) A misbranching fault may cause OAM packets to be delivered to a MEP that is not in the MEG of origin. 2) An out-of-band return path may be used between a MIP or a MEP and the originating MEP. In case of a unidirectional point-to-point transport path, a single unidirectional Maintenance Entity is defined to monitor it.
In case of associated bidirectional point-to-point transport paths, two independent unidirectional Maintenance Entities are defined to independently monitor each direction. This has implications for transactions that terminate at or query a MIP, as a return path from MIP to the originating MEP does not necessarily exist in the MEG. In case of co-routed bidirectional point-to-point transport paths, a single bidirectional Maintenance Entity is defined to monitor both directions congruently. In case of unidirectional point-to-multipoint transport paths, a single unidirectional Maintenance Entity for each leaf is defined to monitor the transport path from the root to that leaf. In all cases, portions of the transport path may be monitored by the instantiation of SPMEs (see Section 3.2). The reference model for the P2MP MEG is represented in Figure 2. +-+ /--|D| / +-+ +-+ /--|C| +-+ +-+/ +-+\ +-+ |A|----|B| \--|E| +-+ +-+\ +-+ +-+ \--|F| +-+ Figure 2: Reference Model for P2MP MEG In the case of P2MP transport paths, the OAM measurements are independent for each ME (A-D, A-E, and A-F): o Fault conditions - some faults may impact more than one ME depending on where the failure is located; o Packet loss - packet dropping may impact more than one ME depending from where the packets are lost; o Packet delay - will be unique per ME. Each leaf (i.e., D, E, and F) terminates OAM flows to monitor the ME between itself and the root while the root (i.e., A) generates OAM packets common to all the MEs of the P2MP MEG. All nodes may implement a MIP in the corresponding MEG.
3.2. MEG Nesting: SPMEs and Tandem Connection Monitoring
In order to verify and maintain performance and quality guarantees, there is a need to apply OAM functionality not only on a transport path granularity (e.g., LSP or MS-PW), but also on arbitrary parts of transport paths, defined as tandem connections, between any two arbitrary points along a transport path. Sub-Path Maintenance Elements (SPMEs), as defined in [8], are hierarchical LSPs instantiated to provide monitoring of a portion of a set of transport paths (LSPs or MS-PWs) that follow the same path between the ingress and the egress of the SPME. The operational aspects of instantiating SPMEs are out of scope of this memo. SPMEs can also be employed to meet the requirement to provide tandem connection monitoring (TCM), as defined by ITU-T Recommendation G.805 [20]. TCM for a given path segment of a transport path is implemented by creating an SPME that has a 1:1 association with the path segment of the transport path that is to be monitored. In the TCM case, this means that the SPME used to provide TCM can carry one and only one transport path, thus allowing direct correlation between all fault management and performance monitoring information gathered for the SPME and the monitored path segment of the end-to-end transport path. There are a number of implications to this approach: 1) The SPME would use the uniform model [23] of Traffic Class (TC) code point copying between sub-layers for Diffserv such that the E2E markings and PHB treatment for the transport path were preserved by the SPMEs. 2) The SPME normally would use the short-pipe model for TTL handling [6] (no TTL copying between sub-layers) such that the TTL distance to the MIPs for the E2E entity would not be impacted by the presence of the SPME, but it should be possible for an operator to specify use of the uniform model. Note that points 1 and 2 above assume that the TTL copying mode and TC copying modes are independently configurable for an LSP. The TTL distance to the MIPs plays a critical role for delivering packets to these MIPs as described in Section 3.4.
There are specific issues with the use of the uniform model of TTL
copying for an SPME:
1. A MIP in the SPME sub-layer is not part of the transport-path MEG;
hence, only an out-of-band return path for OAM originating in the
transport-path MEG that addressed an SPME MIP might be available.
2. The instantiation of a lower-level MEG or protection-switching
actions within a lower-level MEG may change the TTL distances to
MIPs in the higher-level MEGs.
The end points of the SPME are MEPs and limit the scope of an OAM
flow within the MEG that the MEPs belong to (i.e., within the domain
of the SPME that is being monitored and managed).
When considering SPMEs, it is important to consider that the
following properties apply to all MPLS-TP MEGs (regardless of whether
they instrument LSPs, SPMEs, or MS-PWs):
o They can be nested but not overlapped, e.g., a MEG may cover a
path segment of another MEG and may also include the forwarding
engine(s) of the node(s) at the edge(s) of the path segment.
However, when MEGs are nested, the MEPs and MIPs in the SPME are
no longer part of the encompassing MEG.
o It is possible that MEPs of MEGs that are nested reside on a
single node but again are implemented in such a way that they do
not overlap.
o Each OAM flow is associated with a single MEG.
o When an SPME is instantiated after the transport path has been
instantiated, the TTL distance to the MIPs may change for the
short-pipe model of TTL copying, and may change for the uniform
model if the SPME is not co-routed with the original path.
3.3. MEG End Points (MEPs)
MEG End Points (MEPs) are the source and sink points of a MEG. In
the context of an MPLS-TP LSP, only LERs can implement MEPs, while in
the context of an SPME, any LSR of the MPLS-TP LSP can be an LER of
SPMEs that contributes to the overall monitoring infrastructure of
the transport path. Regarding PWs, only T-PEs can implement MEPs;
while for SPMEs supporting one or more PWs, both T-PEs and S-PEs can
implement SPME MEPs. Any MPLS-TP LSR can implement a MEP for an
MPLS-TP Section.
MEPs are responsible for originating almost all of the proactive and on-demand monitoring OAM functionality for the MEG. There is a separate class of notifications (such as Lock Report (LKR) and Alarm Indication Signal (AIS)) that are originated by intermediate nodes and triggered by server-layer events. A MEP is capable of originating and terminating OAM packets for fault management and performance monitoring. These OAM packets are carried within the Generic Associated Channel (G-ACh) with the proper encapsulation and an appropriate channel type as defined in RFC 5586 [7]. A MEP terminates all the OAM packets it receives from the MEG it belongs to and silently discards those that do not. (Note that in the particular case of Connectivity Verification (CV) processing, a CV packet from an incorrect MEG will result in a mis-connectivity defect and there are further actions taken.) The MEG the OAM packet belongs to is associated with the MPLS or PW label, whether the label is used to infer the MEG or the content of the OAM packet is an implementation choice. In the case of an MPLS-TP Section, the MEG is inferred from the port on which an OAM packet was received with the GAL at the top of the label stack. OAM packets may require the use of an available "out-of-band" return path (as defined in [8]). In such cases, sufficient information is required in the originating transaction such that the OAM reply packet can be constructed and properly forwarded to the originating MEP (e.g., IP address). Each OAM solution document will further detail the applicability of the tools it defines as a proactive or on-demand mechanism as well as its usage when: o The "in-band" return path exists and it is used. o An "out-of-band" return path exists and it is used. o Any return path does not exist or is not used. Once a MEG is configured, the operator can configure which proactive OAM functions to use on the MEG, but the MEPs are always enabled. MEPs terminate all OAM packets received from the associated MEG. As the MEP corresponds to the termination of the forwarding path for a MEG at the given (sub-)layer, OAM packets never leak outside of a MEG in a properly configured fault-free implementation.
A MEP of an MPLS-TP transport path coincides with transport path termination and monitors it for failures or performance degradation (e.g., based on packet counts) in an end-to-end scope. Note that both the source MEP and sink MEP coincide with transport paths' source and sink terminations. The MEPs of an SPME are not necessarily coincident with the termination of the MPLS-TP transport path. They are used to monitor a path segment of the transport path for failures or performance degradation (e.g., based on packet counts) only within the boundary of the MEG for the SPME. An MPLS-TP sink MEP passes a fault indication to its client (sub-)layer network as a consequent action of fault detection. When the client layer is not MPLS-TP, the consequent actions in the client layer (e.g., ignore or generate client-layer-specific OAM notifications) are outside the scope of this document. A node hosting a MEP can either support per-node MEP or per-interface MEP(s). A per-node MEP resides in an unspecified location within the node, while a per-interface MEP resides on a specific side of the forwarding engine. In particular, a per-interface MEP is called an "Up MEP" or a "Down MEP" depending on its location relative to the forwarding engine. An "Up MEP" transmits OAM packets towards, and receives them from, the direction of the forwarding engine, while a "Down MEP" receives OAM packets from, and transmits them towards, the direction of a server layer.
Source node Up MEP Destination node Up MEP ------------------------ ------------------------ | | | | |----- -----| |----- -----| | MEP | | | | | | MEP | | | ---- | | | | ---- | | | In |->-| FW |->-| Out |->- ->-| In |->-| FW |->-| Out | | i/f | ---- | i/f | | i/f | ---- | i/f | |----- -----| |----- -----| | | | | ------------------------ ------------------------ (1) (2) Source node Down MEP Destination node Down MEP ------------------------ ------------------------ | | | | |----- -----| |----- -----| | | | MEP | | MEP | | | | | ---- | | | | ---- | | | In |->-| FW |->-| Out |->- ->-| In |->-| FW |->-| Out | | i/f | ---- | i/f | | i/f | ---- | i/f | |----- -----| |----- -----| | | | | ------------------------ ------------------------ (3) (4) Figure 3: Examples of Per-Interface MEPs Figure 3 describes four examples of per-interface Up MEPs: an Up Source MEP in a source node (case 1), an Up Sink MEP in a destination node (case 2), a Down Source MEP in a source node (case 3), and a Down Sink MEP in a destination node (case 4). The usage of per-interface Up MEPs extends the coverage of the ME for both fault and performance monitoring closer to the edge of the domain and determines that the location of a failure or performance degradation is within a node or on a link between two adjacent nodes. Each OAM solution document will further detail the implications of the tools it defines when used with per-interface or per-node MEPs, if necessary. It may occur that multiple MEPs for the same MEG are on the same node, and are all Up MEPs, each on one side of the forwarding engine, such that the MEG is entirely internal to the node.
It should be noted that an ME may span nodes that implement per-node MEPs and per-interface MEPs. This guarantees backward compatibility with most of the existing LSRs that can implement only a per-node MEP. In fact, in many current implementations, label operations are largely performed on the ingress interface; hence, the exposure of the GAL as top label will occur at the ingress interface. Note that a MEP can only exist at the beginning and end of a (sub-)layer in MPLS-TP. If there is a need to monitor some portion of that LSP or PW, a new sub-layer (in the form of an SPME) must be created that permits MEPs and associated MEGs to be created. In the case where an intermediate node sends an OAM packet to a MEP, it uses the top label of the stack at that point.3.4. MEG Intermediate Points (MIPs)
A MEG Intermediate Point (MIP) is a function located at a point between the MEPs of a MEG for a PW, LSP, or SPME. A MIP is capable of reacting to some OAM packets and forwarding all the other OAM packets while ensuring fate-sharing with user data packets. However, a MIP does not initiate unsolicited OAM packets, but may be addressed by OAM packets initiated by one of the MEPs of the MEG. A MIP can generate OAM packets only in response to OAM packets that it receives from the MEG it belongs to. The OAM packets generated by the MIP are sent to the originating MEP. An intermediate node within a MEG can either: o support per-node MIPs (i.e., a single MIP per node in an unspecified location within the node); or o support per-interface MIPs (i.e., two or more MIPs per node on both sides of the forwarding engine). Support of per-interface or per-node MIPs is an implementation choice. It is also possible that a node could support per-interface MIPs on some MEGs and per-node MIPs on other MEGs for which it is a transit node.
Intermediate node ------------------------ | | |----- -----| | MIP | | MIP | | | ---- | | ->-| In |->-| FW |->-| Out |->- | i/f | ---- | i/f | |----- -----| | | ------------------------ Figure 4: Example of Per-Interface MIPs Figure 4 describes an example of two per-interface MIPs at an intermediate node of a point-to-point MEG. Using per-interface MIPs allows the network operator to determine that the location of a failure or performance degradation is within a node or on a link between two adjacent nodes. When sending an OAM packet to a MIP, the source MEP should set the TTL field to indicate the number of hops necessary to reach the node where the MIP resides. The source MEP should also include target MIP information in the OAM packets sent to a MIP to allow proper identification of the MIP within the node. The MEG the OAM packet belongs to is associated with the MPLS label, whether the label is used to infer the MEG or the content of the OAM packet is an implementation choice. In the latter case, the MPLS label is checked to be the expected one. The use of TTL expiry to deliver OAM packets to a specific MIP is not a fully reliable delivery mechanism because the TTL distance of a MIP from a MEP can change. Any MPLS-TP node silently discards any OAM packet that is received with an expired TTL and that is not addressed to any of its MIPs or MEPs. An MPLS-TP node that does not support OAM is also expected to silently discard any received OAM packet. Packets directed to a MIP may not necessarily carry specific MIP identification information beyond that of TTL distance. In this case, a MIP would promiscuously respond to all MEP queries on its MEG. This capability could be used for discovery functions (e.g., route tracing as defined in Section 6.4) or when it is desirable to leave to the originating MEP the job of correlating TTL and MIP identifiers and noting changes or irregularities (via comparison with information previously extracted from the network).
MIPs are associated to the MEG they belong to, and their identity is unique within the MEG. However, their identity is not necessarily unique to the MEG, e.g., all nodal MIPs in a node can have a common identity. A node hosting a MEP can also support per-interface Up MEPs and per- interface MIPs on either side of the forwarding engine. Once a MEG is configured, the operator can enable/disable the MIPs on the nodes within the MEG. All the intermediate nodes and possibly the end nodes host MIP(s). Local policy allows them to be enabled per function and per MEG. The local policy is controlled by the management system, which may delegate it to the control plane. A disabled MIP silently discards any received OAM packets.3.5. Server MEPs
A server MEP is a MEP of a MEG that is either: o defined in a layer network that is "below", which is to say encapsulates and transports the MPLS-TP layer network being referenced; or o defined in a sub-layer of the MPLS-TP layer network that is "below", which is to say encapsulates and transports the sub-layer being referenced. A server MEP can coincide with a MIP or a MEP in the client (MPLS-TP) (sub-)layer network. A server MEP also provides server-layer OAM indications to the client/server adaptation function between the client (MPLS-TP) (sub-)layer network and the server (sub-)layer network. The adaptation function maintains state on the mapping of MPLS-TP transport paths that are set up over that server (sub-)layer's transport path. For example, a server MEP can be: o a non-MPLS MEP at a termination point of a physical link (e.g., 802.3, an SDH Virtual Circuit, or OTN Optical Data Unit (ODU)), for the MPLS-TP Section layer network, defined in Section 4.1; o an MPLS-TP Section MEP for MPLS-TP LSPs, defined in Section 4.2; o an MPLS-TP LSP MEP for MPLS-TP PWs, defined in Section 4.3;
o an MPLS-TP SPME MEP used for LSP path segment monitoring, as
defined in Section 4.4, for MPLS-TP LSPs or higher-level SPMEs
providing LSP path segment monitoring; or
o an MPLS-TP SPME MEP used for PW path segment monitoring, as
defined in Section 4.5, for MPLS-TP PWs or higher-level SPMEs
providing PW path segment monitoring.
The server MEP can run appropriate OAM functions for fault detection
within the server (sub-)layer network and provides a fault indication
to its client MPLS-TP layer network via the client/server adaptation
function. When the server layer is not MPLS-TP, server MEP OAM
functions are simply assumed to exist but are outside the scope of
this document.
3.6. Configuration Considerations
When a control plane is not present, the management plane configures
these functional components. Otherwise, they can be configured by
either the management plane or the control plane.
Local policy allows disabling the usage of any available "out-of-
band" return path, as defined in [8], irrespective of what is
requested by the node originating the OAM packet.
SPMEs are usually instantiated when the transport path is created by
either the management plane or the control plane (if present).
Sometimes an SPME can be instantiated after the transport path is
initially created.
3.7. P2MP Considerations
All the traffic sent over a P2MP transport path, including OAM
packets generated by a MEP, is sent (multicast) from the root to all
the leaves. As a consequence:
o To send an OAM packet to all leaves, the source MEP can send a
single OAM packet that will be delivered by the forwarding plane
to all the leaves and processed by all the leaves. Hence, a
single OAM packet can simultaneously instrument all the MEs in a
P2MP MEG.
o To send an OAM packet to a single leaf, the source MEP sends a
single OAM packet that will be delivered by the forwarding plane
to all the leaves but contains sufficient information to identify
a target leaf, and therefore is processed only by the target leaf
and can be silently discarded by the other leaves.
o To send an OAM packet to a single MIP, the source MEP sends a
single OAM packet with the TTL field indicating the number of hops
necessary to reach the node where the MIP resides. This packet
will be delivered by the forwarding plane to all intermediate
nodes at the same TTL distance of the target MIP and to any leaf
that is located at a shorter distance. The OAM packet must
contain sufficient information to identify the target MIP and
therefore is processed only by the target MIP and can be silently
discarded by the others.
o In order to send an OAM packet to M leaves (i.e., a subset of all
the leaves), the source MEP sends M different OAM packets targeted
to each individual leaf in the group of M leaves. Aggregating or
subsetting mechanisms are outside the scope of this document.
A bud node with a Down MEP or a per-node MEP will both terminate and
relay OAM packets. Similar to how fault coverage is maximized by the
explicit utilization of Up MEPs, the same is true for MEPs on a bud
node.
P2MP paths are unidirectional; therefore, any return path to an
originating MEP for on-demand transactions will be out-of-band. A
mechanism to target "on-demand" transactions to a single MEP or MIP
is required as it relieves the originating MEP of an arbitrarily
large processing load and of the requirement to filter and discard
undesired responses. This is because normally TTL exhaustion will
address all MIPs at a given distance from the source, and failure to
exhaust TTL will address all MEPs.
3.8. Further Considerations of Enhanced Segment Monitoring
Segment monitoring, like any in-service monitoring, in a transport
network should meet the following network objectives:
1. The monitoring and maintenance of existing transport paths has to
be conducted in service without traffic disruption.
2. Segment monitoring must not modify the forwarding of the segment
portion of the transport path.
SPMEs defined in Section 3.2 meet the above two objectives, when they
are pre-configured or pre-instantiated as exemplified in Section 3.6.
However, sometimes pre-design and pre-configuration of all the
considered patterns of SPME are not preferable in real operation due
to the burden of design works, a number of header consumptions,
bandwidth consumption, and so on.
When SPMEs are configured or instantiated after the transport path has been created, network objective (1) can be met: application and removal of SPME to a faultless monitored transport entity can be performed in such a way as not to introduce any loss of traffic, e.g., by using a non-disruptive "make before break" technique. However, network objective (2) cannot be met due to new assignment of MPLS labels. As a consequence, generally speaking, the results of SPME monitoring are not necessarily correlated with the behavior of traffic in the monitored entity when it does not use SPME. For example, application of SPME to a problematic/faulty monitoring entity might "fix" the problem encountered by the latter -- for as long as SPME is applied. And vice versa, application of SPME to a faultless monitored entity may result in making it faulty -- again, as long as SPME is applied. Support for a more sophisticated segment-monitoring mechanism (temporal and hitless segment monitoring) to efficiently meet the two network objectives may be necessary. One possible option to instantiate non-intrusive segment monitoring without the use of SPMEs would require the MIPs selected as monitoring end points to implement enhanced functionality and state for the monitored transport path. For example, the MIPs need to be configured with the TTL distance to the peer or with the address of the peer, when out-of-band return paths are used. A further issue that would need to be considered is events that result in changing the TTL distance to the peer monitoring entity, such as protection events that may temporarily invalidate OAM information gleaned from the use of this technique. Further considerations on this technique are outside the scope of this document.
(page 23 continued on part 2)
