draft-ietf-mpls-tp-oam-framework-11.txt   rfc6371.txt 
MPLS Working Group I. Busi (Ed)
Internet Draft Alcatel-Lucent
Intended status: Informational D. Allan (Ed)
Ericsson
Expires: August 11, 2011 February 11, 2011 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 Operations, Administration, and Maintenance Framework for
MPLS-based Transport Networks MPLS-Based Transport Networks
draft-ietf-mpls-tp-oam-framework-11.txt
Abstract Abstract
The Transport Profile of Multi-Protocol Label Switching The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a
(MPLS-TP) is a packet-based transport technology based on the packet-based transport technology based on the MPLS Traffic
MPLS Traffic Engineering (MPLS-TE) and Pseudowire (PW) data Engineering (MPLS-TE) and pseudowire (PW) data-plane architectures.
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 PWE3
architectures to support the capabilities and functionalities of
a packet transport network as defined by the ITU-T.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance This document describes a framework to support a comprehensive set of
with the provisions of BCP 78 and BCP 79. 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.
Internet-Drafts are working documents of the Internet This document is a product of a joint Internet Engineering Task Force
Engineering Task Force (IETF), its areas, and its working (IETF) / International Telecommunications Union Telecommunication
groups. Note that other groups may also distribute working Standardization Sector (ITU-T) effort to include an MPLS Transport
documents as Internet-Drafts. 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.
Internet-Drafts are draft documents valid for a maximum of six Status of This Memo
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress".
The list of current Internet-Drafts can be accessed at This document is not an Internet Standards Track specification; it is
http://www.ietf.org/ietf/1id-abstracts.txt. published for informational purposes.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (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.
This Internet-Draft will expire on August 11, 2011. 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 Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described include Simplified BSD License text as described in Section 4.e of
in Section 4.e of the Trust Legal Provisions and are provided the Trust Legal Provisions and are provided without warranty as
without warranty as described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction..................................................5 1. Introduction ....................................................3
1.1. Contributing Authors.....................................7 2. Conventions Used in This Document ...............................5
2. Conventions used in this document.............................7 2.1. Terminology ................................................5
2.1. Terminology..............................................7 2.2. Definitions ................................................7
2.2. Definitions..............................................9 3. Functional Components ..........................................10
3. Functional Components........................................12 3.1. Maintenance Entity and Maintenance Entity Group ...........10
3.1. Maintenance Entity and Maintenance Entity Group.........12 3.2. MEG Nesting: SPMEs and Tandem Connection Monitoring .......13
3.2. MEG Nesting: SPMEs and Tandem Connection Monitoring.....14 3.3. MEG End Points (MEPs) .....................................14
3.3. MEG End Points (MEPs)...................................16 3.4. MEG Intermediate Points (MIPs) ............................18
3.4. MEG Intermediate Points (MIPs)..........................20 3.5. Server MEPs ...............................................20
3.5. Server MEPs.............................................22 3.6. Configuration Considerations ..............................21
3.6. Configuration Considerations............................23 3.7. P2MP Considerations .......................................21
3.7. P2MP considerations.....................................23 3.8. Further Considerations of Enhanced Segment Monitoring .....22
3.8. Further considerations of enhanced segment monitoring...24 4. Reference Model ................................................23
4. Reference Model..............................................26 4.1. MPLS-TP Section Monitoring (SMEG) .........................26
4.1. MPLS-TP Section Monitoring (SMEG).......................28 4.2. MPLS-TP LSP End-to-End Monitoring Group (LMEG) ............27
4.2. MPLS-TP LSP End-to-End Monitoring Group (LMEG)..........29 4.3. MPLS-TP PW Monitoring (PMEG) ..............................27
4.3. MPLS-TP PW Monitoring (PMEG)............................29 4.4. MPLS-TP LSP SPME Monitoring (LSMEG) .......................28
4.4. MPLS-TP LSP SPME Monitoring (LSMEG).....................30 4.5. MPLS-TP MS-PW SPME Monitoring (PSMEG) .....................30
4.5. MPLS-TP MS-PW SPME Monitoring (PSMEG)...................31 4.6. Fate-Sharing Considerations for Multilink .................31
4.6. Fate sharing considerations for multilink...............33 5. OAM Functions for Proactive Monitoring .........................32
5. OAM Functions for proactive monitoring.......................33 5.1. Continuity Check and Connectivity Verification ............33
5.1. Continuity Check and Connectivity Verification..........34 5.1.1. Defects Identified by CC-V .........................35
5.1.1. Defects identified by CC-V.........................37 5.1.2. Consequent Action ..................................37
5.1.2. Consequent action..................................39 5.1.3. Configuration Considerations .......................38
5.1.3. Configuration considerations.......................40 5.2. Remote Defect Indication ..................................40
5.2. Remote Defect Indication................................42 5.2.1. Configuration Considerations .......................40
5.2.1. Configuration considerations.......................43 5.3. Alarm Reporting ...........................................41
5.3. Alarm Reporting.........................................43 5.4. Lock Reporting ............................................42
5.4. Lock Reporting..........................................44 5.5. Packet Loss Measurement ...................................44
5.5. Packet Loss Measurement.................................46 5.5.1. Configuration Considerations .......................45
5.5.1. Configuration considerations.......................47 5.5.2. Sampling Skew ......................................45
5.5.2. Sampling skew......................................48 5.5.3. Multilink Issues ...................................45
5.5.3. Multilink issues...................................48 5.6. Packet Delay Measurement ..................................46
5.6. Packet Delay Measurement................................48 5.6.1. Configuration Considerations .......................46
5.6.1. Configuration considerations.......................49 5.7. Client Failure Indication .................................47
5.7. Client Failure Indication...............................49 5.7.1. Configuration Considerations .......................47
5.7.1. Configuration considerations.......................50 6. OAM Functions for On-Demand Monitoring .........................48
6. OAM Functions for on-demand monitoring.......................50 6.1. Connectivity Verification .................................48
6.1. Connectivity Verification...............................51 6.1.1. Configuration Considerations .......................49
6.1.1. Configuration considerations.......................52 6.2. Packet Loss Measurement ...................................50
6.2. Packet Loss Measurement.................................52 6.2.1. Configuration Considerations .......................50
6.2.1. Configuration considerations.......................53 6.2.2. Sampling Skew ......................................50
6.2.2. Sampling skew......................................53 6.2.3. Multilink Issues ...................................50
6.2.3. Multilink issues...................................53 6.3. Diagnostic Tests ..........................................50
6.3. Diagnostic Tests........................................53 6.3.1. Throughput Estimation ..............................51
6.3.1. Throughput Estimation..............................53 6.3.2. Data-Plane Loopback ................................52
6.3.2. Data plane Loopback................................55 6.4. Route Tracing .............................................54
6.4. Route Tracing...........................................57 6.4.1. Configuration Considerations .......................54
6.4.1. Configuration considerations.......................57 6.5. Packet Delay Measurement ..................................54
6.5. Packet Delay Measurement................................57 6.5.1. Configuration Considerations .......................55
6.5.1. Configuration considerations.......................58 7. OAM Functions for Administration Control .......................55
7. OAM Functions for administration control.....................58 7.1. Lock Instruct .............................................55
7.1. Lock Instruct...........................................58 7.1.1. Locking a Transport Path ...........................56
7.1.1. Locking a transport path...........................59 7.1.2. Unlocking a Transport Path .........................56
7.1.2. Unlocking a transport path.........................59 8. Security Considerations ........................................57
8. Security Considerations......................................60 9. Acknowledgments ................................................58
9. IANA Considerations..........................................61 10. References ....................................................58
10. Acknowledgments.............................................61 10.1. Normative References .....................................58
11. References..................................................62 10.2. Informative References ...................................59
11.1. Normative References...................................62 11. Contributing Authors ..........................................60
11.2. Informative References.................................63
Editors' Note:
This Informational Internet-Draft is aimed at achieving IETF
Consensus before publication as an RFC and will be subject to an
IETF Last Call.
[RFC Editor, please remove this note before publication as an
RFC and insert the correct Streams Boilerplate to indicate that
the published RFC has IETF Consensus.]
1. Introduction 1. Introduction
As noted in the multi-protocol label switching (MPLS-TP) Framework As noted in the MPLS Transport Profile (MPLS-TP) framework RFCs (RFC
RFCs (RFC 5921 [8] and [9]), MPLS-TP is a packet-based transport 5921 [8] and RFC 6215 [9]), MPLS-TP is a packet-based transport
technology based on the MPLS Traffic Engineering (MPLS-TE) and Pseudo technology based on the MPLS Traffic Engineering (MPLS-TE) and
Wire (PW) data plane architectures defined in RFC 3031 [1], RFC 3985 pseudowire (PW) data-plane architectures defined in RFC 3031 [1], RFC
[2] and RFC 5659 [4]. 3985 [2], and RFC 5659 [4].
MPLS-TP supports a comprehensive set of Operations, MPLS-TP utilizes a comprehensive set of Operations, Administration,
Administration and Maintenance (OAM) procedures for fault, and Maintenance (OAM) procedures for fault, performance, and
performance and protection-switching management that do not rely protection-switching management that do not rely on the presence of a
on the presence of a control plane. control plane.
In line with [15], existing MPLS OAM mechanisms will be used In line with [15], existing MPLS OAM mechanisms will be used wherever
wherever possible and extensions or new OAM mechanisms will be possible, and extensions or new OAM mechanisms will be defined only
defined only where existing mechanisms are not sufficient to where existing mechanisms are not sufficient to meet the
meet the requirements. Some extensions discussed in this requirements. Some extensions discussed in this framework may end up
framework may end up as aspirational capabilities and may be as aspirational capabilities and may be determined to be not
determined to be not tractably realizable in some tractably realizable in some implementations. Extensions do not
implementations. Extensions do not deprecate support for deprecate support for existing MPLS OAM capabilities.
existing MPLS OAM capabilities.
The MPLS-TP OAM framework defined in this document provides a The MPLS-TP OAM framework defined in this document provides a
protocol neutral description of the required OAM functions and protocol-neutral description of the required OAM functions and of the
of the data plane OAM architecture to support a comprehensive data-plane OAM architecture to support a comprehensive set of OAM
set of OAM procedures that satisfy the MPLS-TP OAM requirements procedures that satisfy the MPLS-TP OAM requirements of RFC 5860
of RFC 5860 [11]. In this regard, it defines similar OAM [11]. In this regard, it defines similar OAM functionality as for
functionality as for existing SONET/SDH and OTN OAM mechanisms existing Synchronous Optical Network / Synchronous Digital Hierarchy
(e.g. [19]). (SONET/SDH) and Optical Transport Network (OTN) OAM mechanisms (e.g.,
[19]).
The MPLS-TP OAM framework is applicable to sections, Label The MPLS-TP OAM framework is applicable to Sections, Label Switched
Switched Paths (LSPs), Multi-Segment Pseudowires (MS-)PWs and Paths (LSPs), Multi-Segment Pseudowires (MS-PWs), and Sub-Path
Sub Path Maintenance Entities (SPMEs). It supports co-routed and Maintenance Elements (SPMEs). It supports co-routed and associated
associated bidirectional p2p transport paths as well as bidirectional P2P transport paths as well as unidirectional P2P and
unidirectional p2p and p2mp transport paths. P2MP transport paths.
OAM packets that instrument a particular direction of a OAM packets that instrument a particular direction of a transport
transport path are subject to the same forwarding treatment path are subject to the same forwarding treatment (i.e., fate-share)
(i.e. fate-share) as the user data packets and in some cases, as the user data packets and in some cases, where Explicitly TC-
where Explicitly TC-encoded-PSC LSPs (E-LSPs) are employed, may encoded-PSC LSPs (E-LSPs) are employed, may be required to have
be required to have common Per-hop Behavior (PHB) scheduling common per-hop behavior (PHB) Scheduling Class (PSC) End-to-End (E2E)
class (PSC) E2E with the class of traffic monitored. In case of with the class of traffic monitored. In case of Label-Only-Inferred-
Label-Only-Inferred-PSC LSP (L-LSP), only one class of traffic PSC LSP (L-LSP), only one class of traffic needs to be monitored, and
needs to be monitored and therefore the OAM packets have common therefore the OAM packets have common PSC with the monitored traffic
PSC with the monitored traffic class. class.
OAM packets can be distinguished from the used data packets OAM packets can be distinguished from the used data packets using the
using the GAL and ACH constructs of RFC 5586 [7] for LSP, SPME Generic Associated Channel Label (GAL) and Associated Channel Header
and Section or the ACH construct of RFC 5085 [3] and RFC 5586 (ACH) constructs of RFC 5586 [7] for LSP, SPME, and Section, or the
[7] for (MS-)PW. OAM packets are never fragmented and are not ACH construct of RFC 5085 [3] and RFC 5586 [7] for (MS-)PW. OAM
combined with user data in the same packet payload. 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 This framework makes certain assumptions as to the utility and
frequency of different classes of measurement that naturally frequency of different classes of measurement that naturally suggest
suggest different functions are implemented as distinct OAM different functions are implemented as distinct OAM flows or packets.
flows or packets. This is dictated by the combination of the This is dictated by the combination of the class of problem being
class of problem being detected and the need for timeliness of detected and the need for timeliness of network response to the
network response to the problem. For example fault detection is problem. For example, fault detection is expected to operate on an
expected to operate on an entirely different time base than entirely different time base than performance monitoring, which is
performance monitoring which is also expected to operate on an also expected to operate on an entirely different time base than in-
entirely different time base than in-band management band management transactions.
transactions.
The remainder of this memo is structured as follow: The remainder of this memo is structured as follows:
Section 2 covers the definitions and terminology used in this Section 2 covers the definitions and terminology used in this memo.
memo.
Section 3 describes the functional component that generates and Section 3 describes the functional component that generates and
processes OAM packets. processes OAM packets.
Section 4 describes the reference models for applying OAM Section 4 describes the reference models for applying OAM functions
functions to Sections, LSP, MS-PW and their SPMEs. 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 Sections 5, 6, and 7 provide a protocol-neutral description of the
document are expected to comply with the functional behavior OAM functions, defined in RFC 5860 [11], aimed at clarifying how the
described in sections 5, 6 and 7. Alternative solutions to OAM protocol solutions will behave to achieve their functional
required functional behaviors may also be defined. objectives.
OAM specifications following this OAM framework may be provided Section 8 discusses the security implications of OAM protocol design
in different documents to cover distinct OAM functions. in the MPLS-TP context.
This document is a product of a joint Internet Engineering Task The OAM protocol solutions designed as a consequence of this document
Force (IETF) / International Telecommunication Union are expected to comply with the functional behavior described in
Telecommunication Standardization Sector (ITU-T) effort to Sections 5, 6, and 7. Alternative solutions to required functional
include an MPLS Transport Profile within the IETF MPLS and PWE3 behaviors may also be defined.
architectures to support the capabilities and functionalities of
a packet transport network as defined by the ITU-T.
1.1. Contributing Authors OAM specifications following this OAM framework may be provided in
different documents to cover distinct OAM functions.
Dave Allan, Italo Busi, Ben Niven-Jenkins, Annamaria Fulignoli, This document is a product of a joint Internet Engineering Task Force
Enrique Hernandez-Valencia, Lieven Levrau, Vincenzo Sestito, (IETF) / International Telecommunication Union Telecommunication
Nurit Sprecher, Huub van Helvoort, Martin Vigoureux, Yaacov Standardization Sector (ITU-T) effort to include an MPLS Transport
Weingarten, Rolf Winter 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. Conventions Used in This Document
2.1. Terminology 2.1. Terminology
AC Attachment Circuit AC Attachment Circuit
AIS Alarm indication signal AIS Alarm Indication Signal
CC Continuity Check CC Continuity Check
CC-V Continuity Check and/or Connectivity Verification CC-V Continuity Check and Connectivity Verification
CV Connectivity Verification CV Connectivity Verification
DBN Domain Border Node DBN Domain Border Node
E-LSP Explicitly TC-encoded-PSC LSP
E-LSP Explicitly TC-encoded-PSC LSP ICC ITU Carrier Code
ICC ITU Carrier Code LER Label Edge Router
LER Label Edge Router LKR Lock Report
LKR Lock Report L-LSP Label-Only-Inferred-PSC LSP
L-LSP Label-Only-Inferred-PSC LSP LM Loss Measurement
LM Loss Measurement LME LSP Maintenance Entity
LME LSP Maintenance Entity LMEG LSP ME Group
LMEG LSP ME Group LSP Label Switched Path
LSP Label Switched Path
LSR Label Switching Router LSR Label Switching Router
LSME LSP SPME ME LSME LSP SPME ME
LSMEG LSP SPME ME Group LSMEG LSP SPME ME Group
ME Maintenance Entity ME Maintenance Entity
MEG Maintenance Entity Group MEG Maintenance Entity Group
MEP Maintenance Entity Group End Point MEP Maintenance Entity Group End Point
MIP Maintenance Entity Group Intermediate Point MIP Maintenance Entity Group Intermediate Point
NMS Network Management System NMS Network Management System
PE Provider Edge PE Provider Edge
PHB Per-hop Behavior PHB Per-Hop Behavior
PM Performance Monitoring PM Performance Monitoring
PME PW Maintenance Entity PME PW Maintenance Entity
PMEG PW ME Group PMEG PW ME Group
PSC PHB Scheduling Class PSC PHB Scheduling Class
PSME PW SPME ME PSME PW SPME ME
PSMEG PW SPME ME Group
PSMEG PW SPME ME Group PW Pseudowire
PW Pseudowire SLA Service Level Agreement
SLA Service Level Agreement SME Section Maintenance Entity
SME Section Maintenance Entity SMEG Section ME Group
SMEG Section ME Group SPME Sub-Path Maintenance Element
SPME Sub-path Maintenance Element S-PE Switching Provider Edge
S-PE Switching Provider Edge TC Traffic Class
TC Traffic Class T-PE Terminating Provider Edge
T-PE Terminating Provider Edge
2.2. Definitions 2.2. Definitions
This document uses the terms defined in RFC 5654 [5]. This document uses the terms defined in RFC 5654 [5].
This document uses the term 'Per-hop Behavior' as defined in RFC This document uses the term 'per-hop behavior' as defined in RFC 2474
2474 [16]. [16].
This document uses the term LSP to indicate either a service LSP This document uses the term 'LSP' to indicate either a service LSP or
or a transport LSP (as defined in RFC 5921 [8]). a transport LSP (as defined in RFC 5921 [8]).
This document uses the term Sub Path Maintenance Element (SPME) This document uses the term 'Section' exclusively to refer to the n=0
as defined in RFC 5921 [8]. case of the term 'Section' defined in RFC 5960 [10].
This document uses the term traffic profile as defined in RFC This document uses the term 'Sub-Path Maintenance Element (SPME)' as
2475 [13]. defined in RFC 5921 [8].
Where appropriate, the following definitions are aligned with This document uses the term 'traffic profile' as defined in RFC 2475
ITU-T recommendation Y.1731 [21] in order to have a common, [13].
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 Where appropriate, the following definitions are aligned with ITU-T
between the client (sub)-layer and the server (sub-)layer. 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.
Branch Node: A node along a point-to-multipoint transport path Adaptation function: The adaptation function is the interface between
that is connected to more than one downstream node. the client (sub-)layer and the server (sub-)layer.
Bud Node: A node along a point-to-multipoint transport path that Branch 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 is connected to more than one downstream node.
transport path.
Data plane loopback: An out-of-service test where a transport Bud Node: A node along a point-to-multipoint transport path that is
path at either an intermediate or terminating node is placed at the same time a branch node and a leaf node for this transport
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. path.
Note - The only way to send an OAM packet to a node that has been put Data-plane loopback: An out-of-service test where a transport path at
into data plane loopback mode is via TTL expiry, irrespective of either an intermediate or terminating node is placed into a data-
whether the node is hosting MIPs or MEPs. 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.
Domain Border Node (DBN): An intermediate node in an MPLS-TP LSP Note: The only way to send an OAM packet to a node that has been
that is at the boundary between two MPLS-TP OAM domains. Such a put into data-plane loopback mode is via Time to Live (TTL)
node may be present on the edge of two domains or may be expiry, irrespective of whether the node is hosting MIPs or MEPs.
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 Domain Border Node (DBN): An intermediate node in an MPLS-TP LSP that
them towards, the direction of a server layer. 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.
Forwarding Engine: An abstract functional component, residing in Down MEP: A MEP that receives OAM packets from, and transmits them
an LSR, that forwards the packets from an ingress interface towards, the direction of a server layer.
toward the egress interface(s).
In-Service: The administrative status of a transport path when Forwarding Engine: An abstract functional component, residing in an
it is unlocked. 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 Interface: An interface is the attachment point to a server
(sub-)layer e.g., MPLS-TP section or MPLS-TP tunnel. (sub-)layer, e.g., a MPLS-TP Section or MPLS-TP tunnel.
Intermediate Node: An intermediate node transits traffic for an Intermediate Node: An intermediate node transits traffic for an LSP
LSP or a PW. An intermediate node may originate OAM flows or a PW. An intermediate node may originate OAM flows directed to
directed to downstream intermediate nodes or MEPs. downstream intermediate nodes or MEPs.
Loopback: See data plane loopback and OAM loopback definitions. Loopback: See data-plane loopback and OAM loopback definitions.
Maintenance Entity (ME): Some portion of a transport path that Maintenance Entity (ME): Some portion of a transport path that
requires management bounded by two points (called MEPs), and the requires management bounded by two points (called MEPs), and the
relationship between those points to which maintenance and relationship between those points to which maintenance and monitoring
monitoring operations apply (details in section 3.1). operations apply (details in Section 3.1).
Maintenance Entity Group (MEG): The set of one or more Maintenance Entity Group (MEG): The set of one or more maintenance
maintenance entities that maintain and monitor a section or a entities that maintain and monitor a section or a transport path in
transport path in an OAM domain. an OAM domain.
MEP: A MEG end point (MEP) is capable of initiating (Source MEP) MEP: A MEG End Point (MEP) is capable of initiating (source MEP) and
and terminating (sink MEP) OAM packets for fault management and terminating (sink MEP) OAM packets for fault management and
performance monitoring. MEPs define the boundaries of an ME performance monitoring. MEPs define the boundaries of an ME (details
(details in section 3.3). in Section 3.3).
MIP: A MEG intermediate point (MIP) terminates and processes OAM MIP: A MEG intermediate point (MIP) terminates and processes OAM
packets that are sent to this particular MIP and may generate packets that are sent to this particular MIP and may generate OAM
OAM packets in reaction to received OAM packets. It never packets in reaction to received OAM packets. It never generates
generates unsolicited OAM packets itself. A MIP resides within a unsolicited OAM packets itself. A MIP resides within a MEG between
MEG between MEPs (details in section 3.3). MEPs (details in Section 3.3).
MPLS-TP Section: As defined in [8], it is a link that can be OAM domain: A domain, as defined in [5], whose entities are grouped
traversed by one or more MPLS-TP LSPs. for the purpose of keeping the OAM confined within that domain. An
OAM domain contains zero or more MEGs.
OAM domain: A domain, as defined in [5], whose entities are Note: Within the rest of this document, the term "domain" is used
grouped for the purpose of keeping the OAM confined within that to indicate an "OAM domain".
domain. An OAM domain contains zero or more MEGs.
Note - within the rest of this document the term "domain" is OAM flow: The set of all OAM packets originating with a specific
used to indicate an "OAM domain" source MEP that instrument one direction of a MEG (or possibly both
in the special case of data-plane loopback).
OAM flow: Is the set of all OAM packets originating with a OAM loopback: The capability of a node to be directed by a received
specific source MEP that instrument one direction of a MEG (or OAM packet to generate a reply back to the sender. OAM loopback can
possibly both in the special case of data plane loopback). work in-service and can support different OAM functions (e.g.,
bidirectional on-demand connectivity verification).
OAM loopback: The capability of a node to be directed by a OAM Packet: A packet that carries OAM information between MEPs and/or
received OAM packet to generate a reply back to the sender. OAM MIPs in a MEG to perform some OAM functionality (e.g., connectivity
loopback can work in-service and can support different OAM
functions (e.g., bidirectional on-demand connectivity
verification). verification).
OAM Packet: A packet that carries OAM information between MEPs
and/or MIPs in MEG to perform some OAM functionality (e.g.
connectivity verification).
Originating MEP: A MEP that originates an OAM transaction packet Originating MEP: A MEP that originates an OAM transaction packet
(toward a target MIP/MEP) and expects a reply, either in-band or (toward a target MIP/MEP) and expects a reply, either in-band or out-
out-of-band, from that target MIP/MEP. The originating MEP of-band, from that target MIP/MEP. The originating MEP always
always generates the OAM request packets in-band and expects and generates the OAM request packets in-band and expects and processes
processes only OAM reply packets returned by the target MIP/MEP. only OAM reply packets returned by the target MIP/MEP.
Out-of-Service: The administrative status of a transport path Out-of-Service: The administrative status of a transport path when it
when it is locked. When a path is in a locked condition, it is is locked. When a path is in a locked condition, it is blocked from
blocked from carrying client traffic. carrying client traffic.
Path Segment: It is either a segment or a concatenated segment, Path Segment: It is either a segment or a concatenated segment, as
as defined in RFC 5654 [5]. defined in RFC 5654 [5].
Signal Degrade: A condition declared by a MEP when the data Signal Degrade: A condition declared by a MEP when the data
forwarding capability associated with a transport path has forwarding capability associated with a transport path has
deteriorated, as determined by performance monitoring (PM). See also deteriorated, as determined by performance monitoring (PM). See also
ITU-T recommendation G.806 [14]. ITU-T recommendation G.806 [14].
Signal Fail: A condition declared by a MEP when the data Signal Fail: A condition declared by a MEP when the data forwarding
forwarding capability associated with a transport path has capability associated with a transport path has failed, e.g., loss of
failed, e.g. loss of continuity. See also ITU-T recommendation continuity. See also ITU-T recommendation G.806 [14].
G.806 [14].
Sink MEP: A MEP acts as a sink MEP for an OAM packet when it Sink MEP: A MEP acts as a sink MEP for an OAM packet when it
terminates and processes the packets received from its terminates and processes the packets received from its associated
associated MEG. MEG.
Source MEP: A MEP acts as source MEP for an OAM packet when it Source MEP: A MEP acts as source MEP for an OAM packet when it
originates and inserts the packet into the transport path for originates and inserts the packet into the transport path for its
its associated MEG. associated MEG.
Tandem Connection: A tandem connection is an arbitrary part of a Tandem Connection: A tandem connection is an arbitrary part of a
transport path that can be monitored (via OAM) independent of transport path that can be monitored (via OAM) independent of the
the end-to-end monitoring (OAM). The tandem connection may also end-to-end monitoring (OAM). The tandem connection may also include
include the forwarding engine(s) of the node(s) at the the forwarding engine(s) of the node(s) at the boundaries of the
boundaries of the tandem connection. Tandem connections may be tandem connection. Tandem connections may be nested but cannot
nested but cannot overlap. See also ITU-T recommendation G.805 overlap. See also ITU-T recommendation G.805 [20].
[20].
Target MEP/MIP: A MEP or a MIP that is targeted by OAM Target MEP/MIP: A MEP or a MIP that is targeted by OAM transaction
transaction packets and that replies to the originating MEP that packets and that replies to the originating MEP that initiated the
initiated the OAM transactions. The target MEP or MIP can reply OAM transactions. The target MEP or MIP can reply either in-band or
either in-band or out-of-band. The target sink MEP function out-of-band. The target sink MEP function always receives the OAM
always receives the OAM request packets in-band while the target request packets in-band, while the target source MEP function only
source MEP function only generates the OAM reply packets that generates the OAM reply packets that are sent in-band.
are sent in-band.
Up MEP: A MEP that transmits OAM packets towards, and receives Up MEP: A MEP that transmits OAM packets towards, and receives them
them from, the direction of the forwarding engine. from, the direction of the forwarding engine.
3. Functional Components 3. Functional Components
MPLS-TP is a packet-based transport technology based on the MPLS MPLS-TP is a packet-based transport technology based on the MPLS and
and PW data plane architectures ([1], [2] and [4]) and is PW data plane architectures ([1], [2], and [4]) and is capable of
capable of transporting service traffic where the transporting service traffic where the characteristics of information
characteristics of information transfer between the transport transfer between the transport path end points can be demonstrated to
path endpoints can be demonstrated to comply with certain comply with certain performance and quality guarantees.
performance and quality guarantees.
In order to describe the required OAM functionality, this In order to describe the required OAM functionality, this document
document introduces a set of functional components. introduces a set of functional components.
3.1. Maintenance Entity and Maintenance Entity Group 3.1. Maintenance Entity and Maintenance Entity Group
MPLS-TP OAM operates in the context of Maintenance Entities MPLS-TP OAM operates in the context of Maintenance Entities (MEs)
(MEs) that define a relationship between two points of a that define a relationship between two points of a transport path to
transport path to which maintenance and monitoring operations which maintenance and monitoring operations apply. The two points
apply. The two points that define a maintenance entity are that define a maintenance entity are called Maintenance Entity Group
called Maintenance Entity Group (MEG) End Points (MEPs). The End Points (MEPs). The collection of one or more MEs that belongs to
collection of one or more MEs that belongs to the same transport the same transport path and that are maintained and monitored as a
path and that are maintained and monitored as a group are known group are known as a Maintenance Entity Group (MEG). In between
as a maintenance entity group (MEG). In between MEPs, there are MEPs, there are zero or more intermediate points, called Maintenance
zero or more intermediate points, called Maintenance Entity Entity Group Intermediate Points (MIPs). MEPs and MIPs are
Group Intermediate Points (MIPs). MEPs and MIPs are associated associated with the MEG and can be shared by more than one ME in a
with the MEG and can be shared by more than one ME in a MEG. MEG.
An abstract reference model for an ME is illustrated in Figure 1 An abstract reference model for an ME is illustrated in Figure 1
below: below.
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
|A|----|B|----|C|----|D| |A|----|B|----|C|----|D|
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
Figure 1 ME Abstract Reference Model Figure 1: ME Abstract Reference Model
The instantiation of this abstract model to different MPLS-TP The instantiation of this abstract model to different MPLS-TP
entities is described in section 4. In Figure 1, nodes A and D entities is described in Section 4. In Figure 1, nodes A and D can
can be LERs for an LSP or the Terminating Provider Edges (T-PEs) be Label Edge Routers (LERs) for an LSP or the Terminating Provider
for a MS-PW, nodes B and C are LSRs for a LSP or Switching PEs Edges (T-PEs) for an MS-PW, nodes B and C are LSRs for an LSP or
(S-PEs) for a MS-PW. MEPs reside in nodes A and D while MIPs Switching PEs (S-PEs) for an MS-PW. MEPs reside in nodes A and D,
reside in nodes B and C and may reside in A and D. The links while MIPs reside in nodes B and C and may reside in A and D. The
connecting adjacent nodes can be physical links, (sub-)layer links connecting adjacent nodes can be physical links, (sub-)layer
LSPs/SPMEs, or server layer paths. LSPs/SPMEs, or server-layer paths.
This functional model defines the relationships between all OAM This functional model defines the relationships between all OAM
entities from a maintenance perspective and it allows each entities from a maintenance perspective and it allows each
Maintenance Entity to provide monitoring and management for the Maintenance Entity to provide monitoring and management for the
(sub-)layer network under its responsibility and efficient (sub-)layer network under its responsibility and efficient
localization of problems. localization of problems.
An MPLS-TP Maintenance Entity Group may be defined to monitor An MPLS-TP Maintenance Entity Group may be defined to monitor the
the transport path for fault and/or performance management. transport path for fault and/or performance management.
The MEPs that form a MEG bound the scope of an OAM flow to the The MEPs that form a MEG bound the scope of an OAM flow to the MEG
MEG (i.e. within the domain of the transport path that is being (i.e., within the domain of the transport path that is being
monitored and managed). There are two exceptions to this: monitored and managed). There are two exceptions to this:
1) A misbranching fault may cause OAM packets to be delivered to 1) A misbranching fault may cause OAM packets to be delivered to a
a MEP that is not in the MEG of origin. 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 2) An out-of-band return path may be used between a MIP or a MEP and
and the originating MEP. the originating MEP.
In case of unidirectional point-to-point transport paths, a In case of a unidirectional point-to-point transport path, a single
single unidirectional Maintenance Entity is defined to monitor unidirectional Maintenance Entity is defined to monitor it.
it.
In case of associated bi-directional point-to-point transport In case of associated bidirectional point-to-point transport paths,
paths, two independent unidirectional Maintenance Entities are two independent unidirectional Maintenance Entities are defined to
defined to independently monitor each direction. This has independently monitor each direction. This has implications for
implications for transactions that terminate at or query a MIP, transactions that terminate at or query a MIP, as a return path from
as a return path from MIP to originating MEP does not MIP to the originating MEP does not necessarily exist in the MEG.
necessarily exist in the MEG.
In case of co-routed bi-directional point-to-point transport In case of co-routed bidirectional point-to-point transport paths, a
paths, a single bidirectional Maintenance Entity is defined to single bidirectional Maintenance Entity is defined to monitor both
monitor both directions congruently. directions congruently.
In case of unidirectional point-to-multipoint transport paths, a In case of unidirectional point-to-multipoint transport paths, a
single unidirectional Maintenance entity for each leaf is single unidirectional Maintenance Entity for each leaf is defined to
defined to monitor the transport path from the root to that monitor the transport path from the root to that leaf.
leaf.
In all cases, portions of the transport path may be monitored by In all cases, portions of the transport path may be monitored by the
the instantiation of SPMEs (see section 3.2). instantiation of SPMEs (see Section 3.2).
The reference model for the p2mp MEG is represented in Figure 2. The reference model for the P2MP MEG is represented in Figure 2.
+-+ +-+
/--|D| /--|D|
/ +-+ / +-+
+-+ +-+
/--|C| /--|C|
+-+ +-+/ +-+\ +-+ +-+ +-+/ +-+\ +-+
|A|----|B| \--|E| |A|----|B| \--|E|
+-+ +-+\ +-+ +-+ +-+ +-+\ +-+ +-+
\--|F| \--|F|
+-+ +-+
Figure 2 Reference Model for p2mp MEG Figure 2: Reference Model for P2MP MEG
In case of p2mp transport paths, the OAM measurements are In the case of P2MP transport paths, the OAM measurements are
independent for each ME (A-D, A-E and A-F): independent for each ME (A-D, A-E, and A-F):
o Fault conditions - some faults may impact more than one ME o Fault conditions - some faults may impact more than one ME
depending from where the failure is located; depending on where the failure is located;
o Packet loss - packet dropping may impact more than one ME o Packet loss - packet dropping may impact more than one ME
depending from where the packets are lost; depending from where the packets are lost;
o Packet delay - will be unique per ME. o Packet delay - will be unique per ME.
Each leaf (i.e. D, E and F) terminates OAM flows to monitor the Each leaf (i.e., D, E, and F) terminates OAM flows to monitor the ME
ME between itself and the root while the root (i.e. A) generates between itself and the root while the root (i.e., A) generates OAM
OAM packets common to all the MEs of the p2mp MEG. All nodes may packets common to all the MEs of the P2MP MEG. All nodes may
implement a MIP in the corresponding MEG. implement a MIP in the corresponding MEG.
3.2. MEG Nesting: SPMEs and Tandem Connection Monitoring 3.2. MEG Nesting: SPMEs and Tandem Connection Monitoring
In order to verify and maintain performance and quality In order to verify and maintain performance and quality guarantees,
guarantees, there is a need to not only apply OAM functionality there is a need to apply OAM functionality not only on a transport
on a transport path granularity (e.g. LSP or MS-PW), but also on path granularity (e.g., LSP or MS-PW), but also on arbitrary parts of
arbitrary parts of transport paths, defined as Tandem transport paths, defined as tandem connections, between any two
Connections, between any two arbitrary points along a transport arbitrary points along a transport path.
path.
Sub-path Maintenance Elements (SPMEs), as defined in [8], are Sub-Path Maintenance Elements (SPMEs), as defined in [8], are
hierarchical LSPs instantiated to provide monitoring of a hierarchical LSPs instantiated to provide monitoring of a portion of
portion of a set of transport paths (LSPs or MS-PWs) that follow a set of transport paths (LSPs or MS-PWs) that follow the same path
the same path between the ingress and the egress of the SPME. between the ingress and the egress of the SPME. The operational
The operational aspects of instantiating SPMEs are out of scope aspects of instantiating SPMEs are out of scope of this memo.
of this memo.
SPMEs can also be employed to meet the requirement to provide SPMEs can also be employed to meet the requirement to provide tandem
tandem connection monitoring (TCM), as defined by ITU-T connection monitoring (TCM), as defined by ITU-T Recommendation G.805
Recommendation G.805 [20]. [20].
TCM for a given path segment of a transport path is implemented TCM for a given path segment of a transport path is implemented by
by creating an SPME that has a 1:1 association with the path creating an SPME that has a 1:1 association with the path segment of
segment of the transport path that is to be monitored. the transport path that is to be monitored.
In the TCM case, this means that the SPME used to provide TCM In the TCM case, this means that the SPME used to provide TCM can
can carry one and only one transport path thus allowing direct carry one and only one transport path, thus allowing direct
correlation between all fault management and performance correlation between all fault management and performance monitoring
monitoring information gathered for the SPME and the monitored information gathered for the SPME and the monitored path segment of
path segment of the end-to-end transport path. the end-to-end transport path.
There are a number of implications to this approach: There are a number of implications to this approach:
1) The SPME would use the uniform model [23] of Traffic Class 1) The SPME would use the uniform model [23] of Traffic Class (TC)
(TC) code point copying between sub-layers for diffserv such code point copying between sub-layers for Diffserv such that the
that the E2E markings and PHB treatment for the transport E2E markings and PHB treatment for the transport path were
path was preserved by the SPMEs. preserved by the SPMEs.
2) The SPME normally would use the short-pipe model for TTL 2) The SPME normally would use the short-pipe model for TTL handling
handling [6] (no TTL copying between sub-layer) such that the [6] (no TTL copying between sub-layers) such that the TTL distance
TTL distance to the MIPs for the E2E entity would not be to the MIPs for the E2E entity would not be impacted by the
impacted by the presence of the SPME, but it should be presence of the SPME, but it should be possible for an operator to
possible for an operator to specify use of the uniform model. specify use of the uniform model.
Note that points 1 and 2 above assume that the TTL copying mode Note that points 1 and 2 above assume that the TTL copying mode and
and TC copying modes are independently configurable for an LSP. TC copying modes are independently configurable for an LSP.
The TTL distance to the MIPs plays a critical role for The TTL distance to the MIPs plays a critical role for delivering
delivering packets to these MIPs as described in section 3.4. packets to these MIPs as described in Section 3.4.
There are specific issues with the use of the uniform model of There are specific issues with the use of the uniform model of TTL
TTL copying for an SPME: copying for an SPME:
1. A MIP in the SPME sub-layer is not part of the transport path MEG, 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 hence, only an out-of-band return path for OAM originating in the
transport path MEG that addressed an SPME MIP might be available. transport-path MEG that addressed an SPME MIP might be available.
2. The instantiation of a lower level MEG or protection switching 2. The instantiation of a lower-level MEG or protection-switching
actions within a lower level MEG may change the TTL distances to actions within a lower-level MEG may change the TTL distances to
MIPs in the higher level MEGs. MIPs in the higher-level MEGs.
The endpoints of the SPME are MEPs and limit the scope of an OAM 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 flow within the MEG that the MEPs belong to (i.e., within the domain
domain of the SPME that is being monitored and managed). of the SPME that is being monitored and managed).
When considering SPMEs, it is important to consider that the When considering SPMEs, it is important to consider that the
following properties apply to all MPLS-TP MEGs (regardless of following properties apply to all MPLS-TP MEGs (regardless of whether
whether they instrument LSPs, SPMEs or MS-PWs): they instrument LSPs, SPMEs, or MS-PWs):
o They can be nested but not overlapped, e.g. a MEG may cover a 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 path segment of another MEG and may also include the forwarding
forwarding engine(s) of the node(s) at the edge(s) of the engine(s) of the node(s) at the edge(s) of the path segment.
path segment. However when MEGs are nested, the MEPs and MIPs However, when MEGs are nested, the MEPs and MIPs in the SPME are
in the SPME are no longer part of the encompassing MEG. no longer part of the encompassing MEG.
o It is possible that MEPs of MEGs that are nested reside on a o It is possible that MEPs of MEGs that are nested reside on a
single node but again implemented in such a way that they do single node but again are implemented in such a way that they do
not overlap. not overlap.
o Each OAM flow is associated with a single MEG o Each OAM flow is associated with a single MEG.
o When a SPME is instantiated after the transport path has been o When an SPME is instantiated after the transport path has been
instantiated the TTL distance to the MIPs may change for the instantiated, the TTL distance to the MIPs may change for the
short-pipe model of TTL copying, and may change for the short-pipe model of TTL copying, and may change for the uniform
uniform model if the SPME is not co-routed with the original model if the SPME is not co-routed with the original path.
path.
3.3. MEG End Points (MEPs) 3.3. MEG End Points (MEPs)
MEG End Points (MEPs) are the source and sink points of a MEG. MEG End Points (MEPs) are the source and sink points of a MEG. In
In the context of an MPLS-TP LSP, only LERs can implement MEPs the context of an MPLS-TP LSP, only LERs can implement MEPs, while in
while in the context of an SPME, any LSR of the MPLS-TP LSP can the context of an SPME, any LSR of the MPLS-TP LSP can be an LER of
be an LER of SPMEs that contributes to the overall monitoring SPMEs that contributes to the overall monitoring infrastructure of
infrastructure of the transport path. Regarding PWs, only T-PEs the transport path. Regarding PWs, only T-PEs can implement MEPs;
can implement MEPs while for SPMEs supporting one or more PWs while for SPMEs supporting one or more PWs, both T-PEs and S-PEs can
both T-PEs and S-PEs can implement SPME MEPs. Any MPLS-TP LSR implement SPME MEPs. Any MPLS-TP LSR can implement a MEP for an
can implement a MEP for an MPLS-TP Section. MPLS-TP Section.
MEPs are responsible for originating almost all of the proactive MEPs are responsible for originating almost all of the proactive and
and on-demand monitoring OAM functionality for the MEG. There is on-demand monitoring OAM functionality for the MEG. There is a
a separate class of notifications (such as Lock report (LKR) and separate class of notifications (such as Lock Report (LKR) and Alarm
Alarm indication signal (AIS)) that are originated by Indication Signal (AIS)) that are originated by intermediate nodes
intermediate nodes and triggered by server layer events. A MEP and triggered by server-layer events. A MEP is capable of
is capable of originating and terminating OAM packets for fault originating and terminating OAM packets for fault management and
management and performance monitoring. These OAM packets are performance monitoring. These OAM packets are carried within the
carried within the G-ACh with the proper encapsulation and an Generic Associated Channel (G-ACh) with the proper encapsulation and
appropriate channel type as defined in RFC 5586 [7]. A MEP an appropriate channel type as defined in RFC 5586 [7]. A MEP
terminates all the OAM packets it receives from the MEG it terminates all the OAM packets it receives from the MEG it belongs to
belongs to and silently discards those that do not (note in the and silently discards those that do not. (Note that in the
particular case of Connectivity Verification (CV) processing a particular case of Connectivity Verification (CV) processing, a CV
CV packet from an incorrect MEG will result in a packet from an incorrect MEG will result in a mis-connectivity defect
mis-connectivity defect and there are further actions taken). and there are further actions taken.) The MEG the OAM packet belongs
The MEG the OAM packet belongs to is associated with the MPLS or to is associated with the MPLS or PW label, whether the label is used
PW label. Whether the label is used to infer the MEG or the to infer the MEG or the content of the OAM packet is an
content of the OAM packet is an implementation choice. In the implementation choice. In the case of an MPLS-TP Section, the MEG is
case of an MPLS-TP section, the MEG is inferred from the port on inferred from the port on which an OAM packet was received with the
which an OAM packet was received with the GAL at the top of the GAL at the top of the label stack.
label stack.
OAM packets may require the use of an available "out-of-band" OAM packets may require the use of an available "out-of-band" return
return path (as defined in [8]). In such cases sufficient path (as defined in [8]). In such cases, sufficient information is
information is required in the originating transaction such that required in the originating transaction such that the OAM reply
the OAM reply packet can be constructed and properly forwarded packet can be constructed and properly forwarded to the originating
to the originating MEP (e.g. IP address). MEP (e.g., IP address).
Each OAM solution document will further detail the applicability Each OAM solution document will further detail the applicability of
of the tools it defines as a pro-active or on-demand mechanism the tools it defines as a proactive or on-demand mechanism as well as
as well as its usage when: its usage when:
o The "in-band" return path exists and it is used; o The "in-band" return path exists and it is used.
o An "out-of-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. o Any return path does not exist or is not used.
Once a MEG is configured, the operator can configure which Once a MEG is configured, the operator can configure which proactive
proactive OAM functions to use on the MEG but the MEPs are OAM functions to use on the MEG, but the MEPs are always enabled.
always enabled.
MEPs terminate all OAM packets received from the associated MEG. MEPs terminate all OAM packets received from the associated MEG. As
As the MEP corresponds to the termination of the forwarding path the MEP corresponds to the termination of the forwarding path for a
for a MEG at the given (sub-)layer, OAM packets never leak MEG at the given (sub-)layer, OAM packets never leak outside of a MEG
outside of a MEG in a properly configured fault-free in a properly configured fault-free implementation.
implementation.
A MEP of an MPLS-TP transport path coincides with transport path A MEP of an MPLS-TP transport path coincides with transport path
termination and monitors it for failures or performance termination and monitors it for failures or performance degradation
degradation (e.g. based on packet counts) in an end-to-end (e.g., based on packet counts) in an end-to-end scope. Note that
scope. Note that both source MEP and sink MEP coincide with both the source MEP and sink MEP coincide with transport paths'
transport paths' source and sink terminations. source and sink terminations.
The MEPs of an SPME are not necessarily coincident with the The MEPs of an SPME are not necessarily coincident with the
termination of the MPLS-TP transport path. They are used to termination of the MPLS-TP transport path. They are used to monitor
monitor a path segment of the transport path for failures or a path segment of the transport path for failures or performance
performance degradation (e.g. based on packet counts) only degradation (e.g., based on packet counts) only within the boundary
within the boundary of the MEG for the SPME. of the MEG for the SPME.
An MPLS-TP sink MEP passes a fault indication to its client An MPLS-TP sink MEP passes a fault indication to its client
(sub-)layer network as a consequent action of fault detection. (sub-)layer network as a consequent action of fault detection. When
When the client layer is not MPLS TP, the consequent actions in the client layer is not MPLS-TP, the consequent actions in the client
the client layer (e.g., ignore or generate client layer specific layer (e.g., ignore or generate client-layer-specific OAM
OAM notifications) are outside the scope of this document. notifications) are outside the scope of this document.
A node hosting a MEP can either support per-node MEP or per- A node hosting a MEP can either support per-node MEP or per-interface
interface MEP(s). A per-node MEP resides in an unspecified MEP(s). A per-node MEP resides in an unspecified location within the
location within the node while a per-interface MEP resides on a node, while a per-interface MEP resides on a specific side of the
specific side of the forwarding engine. In particular a per- forwarding engine. In particular, a per-interface MEP is called an
interface MEP is called "Up MEP" or "Down MEP" depending on its "Up MEP" or a "Down MEP" depending on its location relative to the
location relative to the forwarding engine. An "Up MEP" forwarding engine. An "Up MEP" transmits OAM packets towards, and
transmits OAM packets towards, and receives them from, the receives them from, the direction of the forwarding engine, while a
direction of the forwarding engine, while a "Down MEP" receives "Down MEP" receives OAM packets from, and transmits them towards, the
OAM packets from, and transmits them towards, the direction of a direction of a server layer.
server layer.
Source node Up MEP Destination node Up MEP Source node Up MEP Destination node Up MEP
------------------------ ------------------------ ------------------------ ------------------------
| | | | | | | |
|----- -----| |----- -----| |----- -----| |----- -----|
| MEP | | | | | | MEP | | MEP | | | | | | MEP |
| | ---- | | | | ---- | | | | ---- | | | | ---- | |
| In |->-| FW |->-| Out |->- ->-| In |->-| FW |->-| Out | | In |->-| FW |->-| Out |->- ->-| In |->-| FW |->-| Out |
| i/f | ---- | i/f | | i/f | ---- | i/f | | i/f | ---- | i/f | | i/f | ---- | i/f |
|----- -----| |----- -----| |----- -----| |----- -----|
skipping to change at page 19, line 31 skipping to change at page 17, line 31
|----- -----| |----- -----| |----- -----| |----- -----|
| | | MEP | | MEP | | | | | | MEP | | MEP | | |
| | ---- | | | | ---- | | | | ---- | | | | ---- | |
| In |->-| FW |->-| Out |->- ->-| In |->-| FW |->-| Out | | In |->-| FW |->-| Out |->- ->-| In |->-| FW |->-| Out |
| i/f | ---- | i/f | | i/f | ---- | i/f | | i/f | ---- | i/f | | i/f | ---- | i/f |
|----- -----| |----- -----| |----- -----| |----- -----|
| | | | | | | |
------------------------ ------------------------ ------------------------ ------------------------
(3) (4) (3) (4)
Figure 3 Examples of per-interface MEPs Figure 3: Examples of Per-Interface MEPs
Figure 3 describes four examples of per-interface Up MEPs: an Up 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 Source MEP in a source node (case 1), an Up Sink MEP in a destination
destination node (case 2), a Down Source MEP in a source node node (case 2), a Down Source MEP in a source node (case 3), and a
(case 3) and a Down Sink MEP in a destination node (case 4). Down Sink MEP in a destination node (case 4).
The usage of per-interface Up MEPs extends the coverage of the The usage of per-interface Up MEPs extends the coverage of the ME for
ME for both fault and performance monitoring closer to the edge both fault and performance monitoring closer to the edge of the
of the domain and allows the isolation of failures or domain and determines that the location of a failure or performance
performance degradation to being within a node or either the degradation is within a node or on a link between two adjacent nodes.
link or interfaces.
Each OAM solution document will further detail the implications Each OAM solution document will further detail the implications of
of the tools it defines when used with per-interface or per-node the tools it defines when used with per-interface or per-node MEPs,
MEPs, if necessary. if necessary.
It may occur that multiple MEPs for the same MEG are on the same 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 node, and are all Up MEPs, each on one side of the forwarding engine,
engine, such that the MEG is entirely internal to the node. such that the MEG is entirely internal to the node.
It should be noted that a ME may span nodes that implement per It should be noted that an ME may span nodes that implement per-node
node MEPs and per-interface MEPs. This guarantees backward MEPs and per-interface MEPs. This guarantees backward compatibility
compatibility with most of the existing LSRs that can implement with most of the existing LSRs that can implement only a per-node
only a per-node MEP as in current implementations label MEP. In fact, in many current implementations, label operations are
operations are largely performed on the ingress interface, hence largely performed on the ingress interface; hence, the exposure of
the exposure of the GAL as top label will occur at the ingress the GAL as top label will occur at the ingress interface.
interface.
Note that a MEP can only exist at the beginning and end of a 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 (sub-)layer in MPLS-TP. If there is a need to monitor some portion
portion of that LSP or PW, a new sub-layer in the form of an of that LSP or PW, a new sub-layer (in the form of an SPME) must be
SPME must be created which permits MEPs and associated MEGs to created that permits MEPs and associated MEGs to be created.
be created.
In the case where an intermediate node sends an OAM packet to a In the case where an intermediate node sends an OAM packet to a MEP,
MEP, it uses the top label of the stack at that point. it uses the top label of the stack at that point.
3.4. MEG Intermediate Points (MIPs) 3.4. MEG Intermediate Points (MIPs)
A MEG Intermediate Point (MIP) is a function located at a point A MEG Intermediate Point (MIP) is a function located at a point
between the MEPs of a MEG for a PW, LSP or SPME. 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 A MIP is capable of reacting to some OAM packets and forwarding all
the other OAM packets while ensuring fate sharing with user data the other OAM packets while ensuring fate-sharing with user data
packets. However, a MIP does not initiate unsolicited OAM packets, packets. However, a MIP does not initiate unsolicited OAM packets,
but may be addressed by OAM packets initiated by one of the MEPs of 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 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 packets that it receives from the MEG it belongs to. The OAM packets
generated by the MIP are sent to the originating MEP. generated by the MIP are sent to the originating MEP.
An intermediate node within a MEG can either: An intermediate node within a MEG can either:
o Support per-node MIP (i.e. a single MIP per node in an o support per-node MIPs (i.e., a single MIP per node in an
unspecified location within the node); unspecified location within the node); or
o Support per-interface MIP (i.e. two or more MIPs per node on o support per-interface MIPs (i.e., two or more MIPs per node on
both sides of the forwarding engine). both sides of the forwarding engine).
Support of per-interface of per-node MIPs is an implementation Support of per-interface or per-node MIPs is an implementation
choice. It is also possible that a node support per-interface 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 MIPs on some MEGs and per-node MIPs on other MEGs for which it is a
is a transit node. transit node.
Intermediate node Intermediate node
------------------------ ------------------------
| | | |
|----- -----| |----- -----|
| MIP | | MIP | | MIP | | MIP |
| | ---- | | | | ---- | |
->-| In |->-| FW |->-| Out |->- ->-| In |->-| FW |->-| Out |->-
| i/f | ---- | i/f | | i/f | ---- | i/f |
|----- -----| |----- -----|
| | | |
------------------------ ------------------------
Figure 4 Example of per-interface MIPs
Figure 4: Example of Per-Interface MIPs
Figure 4 describes an example of two per-interface MIPs at an Figure 4 describes an example of two per-interface MIPs at an
intermediate node of a point-to-point MEG. intermediate node of a point-to-point MEG.
The usage of per-interface MIPs allows the isolation of failures Using per-interface MIPs allows the network operator to determine
or performance degradation to being within a node or either the that the location of a failure or performance degradation is within a
link or interfaces. node or on a link between two adjacent nodes.
When sending an OAM packet to a MIP, the source MEP should set When sending an OAM packet to a MIP, the source MEP should set the
the TTL field to indicate the number of hops necessary to reach TTL field to indicate the number of hops necessary to reach the node
the node where the MIP resides. where the MIP resides.
The source MEP should also include target MIP information in the The source MEP should also include target MIP information in the OAM
OAM packets sent to a MIP to allow proper identification of the packets sent to a MIP to allow proper identification of the MIP
MIP within the node. The MEG the OAM packet belongs to is within the node. The MEG the OAM packet belongs to is associated
associated with the MPLS label. Whether the label is used to with the MPLS label, whether the label is used to infer the MEG or
infer the MEG or the content of the OAM packet is an the content of the OAM packet is an implementation choice. In the
implementation choice. In the latter, the MPLS label is checked latter case, the MPLS label is checked to be the expected one.
to be the expected one.
The use of TTL expiry to deliver OAM packets to a specific MIP The use of TTL expiry to deliver OAM packets to a specific MIP is not
is not a fully reliable delivery mechanism because the TTL a fully reliable delivery mechanism because the TTL distance of a MIP
distance of a MIP from a MEP can change. Any MPLS-TP node from a MEP can change. Any MPLS-TP node silently discards any OAM
silently discards any OAM packet received with an expired TTL packet that is received with an expired TTL and that is not addressed
and that it is not addressed to any of its MIPs or MEPs. An to any of its MIPs or MEPs. An MPLS-TP node that does not support
MPLS-TP node that does not support OAM is also expected to OAM is also expected to silently discard any received OAM packet.
silently discard any received OAM packet.
Packets directed to a MIP may not necessarily carry specific MIP Packets directed to a MIP may not necessarily carry specific MIP
identification information beyond that of TTL distance. In this identification information beyond that of TTL distance. In this
case a MIP would promiscuously respond to all MEP queries on its case, a MIP would promiscuously respond to all MEP queries on its
MEG. This capability could be used for discovery functions MEG. This capability could be used for discovery functions (e.g.,
(e.g., route tracing as defined in section 6.4) or when it is route tracing as defined in Section 6.4) or when it is desirable to
desirable to leave to the originating MEP the job of correlating leave to the originating MEP the job of correlating TTL and MIP
TTL and MIP identifiers and noting changes or irregularities identifiers and noting changes or irregularities (via comparison with
(via comparison with information previously extracted from the information previously extracted from the network).
network).
MIPs are associated to the MEG they belong to and their identity MIPs are associated to the MEG they belong to, and their identity is
is unique within the MEG. However, their identity is not unique within the MEG. However, their identity is not necessarily
necessarily unique to the MEG: e.g. all nodal MIPs in a node can unique to the MEG, e.g., all nodal MIPs in a node can have a common
have a common identity. identity.
A node hosting a MEP can also support per-interface Up MEPs and A node hosting a MEP can also support per-interface Up MEPs and per-
per-interface MIPs on either side of the forwarding engine. interface MIPs on either side of the forwarding engine.
Once a MEG is configured, the operator can enable/disable the Once a MEG is configured, the operator can enable/disable the MIPs on
MIPs on the nodes within the MEG. All the intermediate nodes and the nodes within the MEG. All the intermediate nodes and possibly
possibly the end nodes host MIP(s). Local policy allows them to the end nodes host MIP(s). Local policy allows them to be enabled
be enabled per function and per MEG. The local policy is per function and per MEG. The local policy is controlled by the
controlled by the management system, which may delegate it to management system, which may delegate it to the control plane. A
the control plane. A disabled MIP silently discards any received disabled MIP silently discards any received OAM packets.
OAM packets.
3.5. Server MEPs 3.5. Server MEPs
A server MEP is a MEP of a MEG that is either: 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 o defined in a layer network that is "below", which is to say
encapsulates and transports the MPLS-TP layer network being encapsulates and transports the MPLS-TP layer network being
referenced, or referenced; or
o Defined in a sub-layer of the MPLS-TP layer network that is o defined in a sub-layer of the MPLS-TP layer network that is
"below" which is to say encapsulates and transports the "below", which is to say encapsulates and transports the sub-layer
sub-layer being referenced. being referenced.
A server MEP can coincide with a MIP or a MEP in the client A server MEP can coincide with a MIP or a MEP in the client (MPLS-TP)
(MPLS-TP) (sub-)layer network. (sub-)layer network.
A server MEP also provides server layer OAM indications to the A server MEP also provides server-layer OAM indications to the
client/server adaptation function between the client (MPLS-TP) client/server adaptation function between the client (MPLS-TP)
(sub-)layer network and the server (sub-)layer network. The (sub-)layer network and the server (sub-)layer network. The
adaptation function maintains state on the mapping of MPLS-TP adaptation function maintains state on the mapping of MPLS-TP
transport paths that are setup over that server (sub-)layer's transport paths that are set up over that server (sub-)layer's
transport path. transport path.
For example, a server MEP can be either: For example, a server MEP can be:
o A termination point of a physical link (e.g. 802.3), an SDH
VC or OTN 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 o a non-MPLS MEP at a termination point of a physical link (e.g.,
4.2; 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 LSP MEP for MPLS-TP PWs, defined in section 4.3; o an MPLS-TP Section MEP for MPLS-TP LSPs, defined in Section 4.2;
o An MPLS-TP SPME MEP used for LSP path segment monitoring, as o an MPLS-TP LSP MEP for MPLS-TP PWs, defined in Section 4.3;
defined in section 4.4, for MPLS-TP LSPs or higher-level o an MPLS-TP SPME MEP used for LSP path segment monitoring, as
SPMEs providing LSP path segment monitoring; 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 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 defined in Section 4.5, for MPLS-TP PWs or higher-level SPMEs
providing PW path segment monitoring. providing PW path segment monitoring.
The server MEP can run appropriate OAM functions for fault detection The server MEP can run appropriate OAM functions for fault detection
within the server (sub-)layer network, and provides a fault within the server (sub-)layer network and provides a fault indication
indication to its client MPLS-TP layer network via the client/server to its client MPLS-TP layer network via the client/server adaptation
adaptation function. When the server layer is not MPLS-TP, server MEP function. When the server layer is not MPLS-TP, server MEP OAM
OAM functions are simply assumed to exist but are outside the scope functions are simply assumed to exist but are outside the scope of
of this document. this document.
3.6. Configuration Considerations 3.6. Configuration Considerations
When a control plane is not present, the management plane configures When a control plane is not present, the management plane configures
these functional components. Otherwise they can be configured either these functional components. Otherwise, they can be configured by
by the management plane or by the control plane. either the management plane or the control plane.
Local policy allows disabling the usage of any available "out- Local policy allows disabling the usage of any available "out-of-
of-band" return path, as defined in [8], irrespective of what is band" return path, as defined in [8], irrespective of what is
requested by the node originating the OAM packet. requested by the node originating the OAM packet.
SPMEs are usually instantiated when the transport path is SPMEs are usually instantiated when the transport path is created by
created by either the management plane or by the control plane either the management plane or the control plane (if present).
(if present). Sometimes an SPME can be instantiated after the Sometimes an SPME can be instantiated after the transport path is
transport path is initially created. initially created.
3.7. P2MP considerations 3.7. P2MP Considerations
All the traffic sent over a p2mp transport path, including OAM All the traffic sent over a P2MP transport path, including OAM
packets generated by a MEP, is sent (multicast) from the root to packets generated by a MEP, is sent (multicast) from the root to all
all the leaves. As a consequence: the leaves. As a consequence:
o To send an OAM packet to all leaves, the source MEP can o To send an OAM packet to all leaves, the source MEP can send a
send a single OAM packet that will be delivered by the single OAM packet that will be delivered by the forwarding plane
forwarding plane to all the leaves and processed by all the to all the leaves and processed by all the leaves. Hence, a
leaves. Hence a single OAM packet can simultaneously single OAM packet can simultaneously instrument all the MEs in a
instrument all the MEs in a p2mp MEG. P2MP MEG.
o To send an OAM packet to a single leaf, the source MEP o To send an OAM packet to a single leaf, the source MEP sends a
sends a single OAM packet that will be delivered by the single OAM packet that will be delivered by the forwarding plane
forwarding plane to all the leaves but contains sufficient to all the leaves but contains sufficient information to identify
information to identify a target leaf, and therefore is a target leaf, and therefore is processed only by the target leaf
processed only by the target leaf and ignored by the other and can be silently discarded by the other leaves.
leaves.
o To send an OAM packet to a single MIP, the source MEP sends o To send an OAM packet to a single MIP, the source MEP sends a
a single OAM packet with the TTL field indicating the single OAM packet with the TTL field indicating the number of hops
number of hops necessary to reach the node where the MIP necessary to reach the node where the MIP resides. This packet
resides. This packet will be delivered by the forwarding will be delivered by the forwarding plane to all intermediate
plane to all intermediate nodes at the same TTL distance of nodes at the same TTL distance of the target MIP and to any leaf
the target MIP and to any leaf that is located at a shorter that is located at a shorter distance. The OAM packet must
distance. The OAM packet must contain sufficient contain sufficient information to identify the target MIP and
information to identify the target MIP and therefore is therefore is processed only by the target MIP and can be silently
processed only by the target MIP. discarded by the others.
o In order to send an OAM packet to M leaves (i.e., a subset o In order to send an OAM packet to M leaves (i.e., a subset of all
of all the leaves), the source MEP sends M different OAM the leaves), the source MEP sends M different OAM packets targeted
packets targeted to each individual leaf in the group of M to each individual leaf in the group of M leaves. Aggregating or
leaves. Aggregated or sub setting mechanisms are outside subsetting mechanisms are outside the scope of this document.
the scope of this document.
A bud node with a Down MEP or a per-node MEP will both terminate A bud node with a Down MEP or a per-node MEP will both terminate and
and relay OAM packets. Similar to how fault coverage is relay OAM packets. Similar to how fault coverage is maximized by the
maximized by the explicit utilization of Up MEPs, the same is explicit utilization of Up MEPs, the same is true for MEPs on a bud
true for MEPs on a bud node. node.
P2MP paths are unidirectional; therefore any return path to an P2MP paths are unidirectional; therefore, any return path to an
originating MEP for on-demand transactions will be out-of-band. originating MEP for on-demand transactions will be out-of-band. A
A mechanism to target "on-demand" transactions to a single MEP mechanism to target "on-demand" transactions to a single MEP or MIP
or MIP is required as it relieves the originating MEP of an is required as it relieves the originating MEP of an arbitrarily
arbitrarily large processing load and of the requirement to large processing load and of the requirement to filter and discard
filter and discard undesired responses as normally TTL undesired responses. This is because normally TTL exhaustion will
exhaustion will address all MIPs at a given distance from the address all MIPs at a given distance from the source, and failure to
source, and failure to exhaust TTL will address all MEPs. exhaust TTL will address all MEPs.
3.8. Further considerations of enhanced segment monitoring 3.8. Further Considerations of Enhanced Segment Monitoring
Segment monitoring, like any in-service monitoring, in a Segment monitoring, like any in-service monitoring, in a transport
transport network should meet the following network objectives: network should meet the following network objectives:
1. The monitoring and maintenance of existing transport paths has to 1. The monitoring and maintenance of existing transport paths has to
be conducted in service without traffic disruption. be conducted in service without traffic disruption.
2. Segment monitoring must not modify the forwarding of the segment 2. Segment monitoring must not modify the forwarding of the segment
portion of the transport path. portion of the transport path.
SPMEs defined in section 3.2 meet the above two objectives, when SPMEs defined in Section 3.2 meet the above two objectives, when they
they are pre-configured or pre-instantiated as exemplified in are pre-configured or pre-instantiated as exemplified in Section 3.6.
section 3.6. However, pre-design and pre-configuration of all However, sometimes pre-design and pre-configuration of all the
the considered patterns of SPME are not sometimes preferable in considered patterns of SPME are not preferable in real operation due
real operation due to the burden of design works, a number of to the burden of design works, a number of header consumptions,
header consumptions, bandwidth consumption and so on. bandwidth consumption, and so on.
When SPMEs are configured or instantiated after the transport When SPMEs are configured or instantiated after the transport path
path has been created, network objective (1) can be met: has been created, network objective (1) can be met: application and
application and removal of SPME to a faultless monitored removal of SPME to a faultless monitored transport entity can be
transport entity can be performed in such a way as not to performed in such a way as not to introduce any loss of traffic,
introduce any loss of traffic, e.g., by using non-disruptive e.g., by using a non-disruptive "make before break" technique.
"make before break" technique.
However, network objective (2) cannot be met due to new However, network objective (2) cannot be met due to new assignment of
assignment of MPLS labels. As a consequence, generally speaking, MPLS labels. As a consequence, generally speaking, the results of
the results of SPME monitoring are not necessarily correlated SPME monitoring are not necessarily correlated with the behavior of
with the behaviour of traffic in the monitored entity when it traffic in the monitored entity when it does not use SPME. For
does not use SPME. For example, application of SPME to a example, application of SPME to a problematic/faulty monitoring
problematic/faulty monitoring entity might "fix" the problem entity might "fix" the problem encountered by the latter -- for as
encountered by the latter - for as long as SPME is applied. And long as SPME is applied. And vice versa, application of SPME to a
vice versa, application of SPME to a faultless monitored entity faultless monitored entity may result in making it faulty -- again,
may result in making it faulty - again, as long as SPME is as long as SPME is applied.
applied.
Support for a more sophisticated segment monitoring mechanism Support for a more sophisticated segment-monitoring mechanism
(temporal and hitless segment monitoring) to efficiently meet (temporal and hitless segment monitoring) to efficiently meet the two
the two network objectives may be necessary. network objectives may be necessary.
One possible option to instantiate non-intrusive segment One possible option to instantiate non-intrusive segment monitoring
monitoring without the use of SPMEs would require the MIPs without the use of SPMEs would require the MIPs selected as
selected as monitoring endpoints to implement enhanced monitoring end points to implement enhanced functionality and state
functionality and state for the monitored transport path. for the monitored transport path.
For example the MIPs need to be configured with the TTL distance For example, the MIPs need to be configured with the TTL distance to
to the peer or with the address of the peer, when out-of-band the peer or with the address of the peer, when out-of-band return
return paths are used. paths are used.
A further issue that would need to be considered is events that A further issue that would need to be considered is events that
result in changing the TTL distance to the peer monitoring result in changing the TTL distance to the peer monitoring entity,
entity such as protection events that may temporarily invalidate such as protection events that may temporarily invalidate OAM
OAM information gleaned from the use of this technique. information gleaned from the use of this technique.
Further considerations on this technique are outside the scope Further considerations on this technique are outside the scope of
of this document. this document.
4. Reference Model 4. Reference Model
The reference model for the MPLS-TP OAM framework builds upon The reference model for the MPLS-TP OAM framework builds upon the
the concept of a MEG, and its associated MEPs and MIPs, to concept of a MEG, and its associated MEPs and MIPs, to support the
support the functional requirements specified in RFC 5860 [11]. functional requirements specified in RFC 5860 [11].
The following MPLS-TP MEGs are specified in this document: The following MPLS-TP MEGs are specified in this document:
o A Section Maintenance Entity Group (SMEG), allowing o A Section Maintenance Entity Group (SMEG), allowing monitoring and
monitoring and management of MPLS-TP Sections (between MPLS management of MPLS-TP Sections (between MPLS LSRs).
LSRs).
o An LSP Maintenance Entity Group (LMEG), allowing monitoring o An LSP Maintenance Entity Group (LMEG), allowing monitoring and
and management of an end-to-end LSP (between LERs). management of an end-to-end LSP (between LERs).
o A PW Maintenance Entity Group (PMEG), allowing monitoring and o A PW Maintenance Entity Group (PMEG), allowing monitoring and
management of an end-to-end SS/MS-PWs (between T-PEs). management of an end-to-end Single-Segment Pseudowire (SS-PW) or
MS-PW (between T-PEs).
o An LSP SPME ME Group (LSMEG), allowing monitoring and o An LSP SPME ME Group (LSMEG), allowing monitoring and management
management of an SPME (between a given pair of LERs and/or of an SPME (between a given pair of LERs and/or LSRs along an
LSRs along an LSP). LSP).
o A PW SPME ME Group (PSMEG), allowing monitoring and o A PW SPME ME Group (PSMEG), allowing monitoring and management of
management of an SPME (between a given pair of T-PEs and/or an SPME (between a given pair of T-PEs and/or S-PEs along an
S-PEs along an (MS-)PW). (MS-)PW).
The MEGs specified in this MPLS-TP OAM framework are compliant The MEGs specified in this MPLS-TP OAM framework are compliant with
with the architecture framework for MPLS-TP [8] that includes the architecture framework for MPLS-TP [8] that includes both MS-PWs
both MS-PWs [4] and LSPs [1]. [4] and LSPs [1].
Hierarchical LSPs are also supported in the form of SPMEs. In Hierarchical LSPs are also supported in the form of SPMEs. In this
this case, each LSP in the hierarchy is a different sub-layer case, each LSP in the hierarchy is a different sub-layer network that
network that can be monitored, independently from higher and can be monitored, independently from higher- and lower-level LSPs in
lower level LSPs in the hierarchy, on an end-to-end basis (from the hierarchy, on an end-to-end basis (from LER to LER) by an SPME.
LER to LER) by a SPME. It is possible to monitor a portion of a It is possible to monitor a portion of a hierarchical LSP by
hierarchical LSP by instantiating a hierarchical SPME between instantiating a hierarchical SPME between any LERs/LSRs along the
any LERs/LSRs along the hierarchical LSP. hierarchical LSP.
Native |<------------------ MS-PW1Z ---------------->| Native Native |<------------------ MS-PW1Z ---------------->| Native
Layer | | Layer Layer | | Layer
Service | |<LSP13>| |<-LSP3X->| |<LSPXZ>| | Service Service | |<LSP13>| |<-LSP3X->| |<LSPXZ>| | Service
(AC1) V V V V V V V V (AC2) (AC1) V V V V V V V V (AC2)
+----+ +---+ +----+ +----+ +---+ +----+ +----+ +---+ +----+ +----+ +---+ +----+
+----+ |T-PE| |LSR| |S-PE| |S-PE| |LSR| |T-PE| +----+ +----+ |T-PE| |LSR| |S-PE| |S-PE| |LSR| |T-PE| +----+
| | | 1 | | 2 | | 3 | | X | | Y | | Z | | | | | | 1 | | 2 | | 3 | | X | | Y | | Z | | |
| | | |=======| |=========| |=======| | | | | | | |=======| |=========| |=======| | | |
| CE1|--|.......PW13......|...PW3X..|......PWXZ.......|---|CE2 | | CE1|--|.......PW13......|...PW3X..|......PWXZ.......|---|CE2 |
skipping to change at page 27, line 34 skipping to change at page 25, line 34
LSP13 LMEG LSPXZ LMEG LSP13 LMEG LSPXZ LMEG
^--^ ^--^ ^---------^ ^--^ ^--^ ^--^ ^--^ ^---------^ ^--^ ^--^
Sec12 Sec23 Sec3X SecXY SecYZ Sec12 Sec23 Sec3X SecXY SecYZ
SMEG SMEG SMEG SMEG SMEG SMEG SMEG SMEG SMEG SMEG
^---^ ME ^---^ ME
^ MEP ^ MEP
==== LSP ==== LSP
.... PW .... PW
T-PE1: Terminating Provider Edge 1 T-PE 1: Terminating Provider Edge 1
LSR: Label Switching Router 2 LSR 2: Label Switching Router 2
S-PE3: Switching Provider Edge 3 S-PE 3: Switching Provider Edge 3
T-PEX: Terminating Provider Edge X S-PE X: Switching Provider Edge X
LSRY: Label Switching Router Y LSR Y: Label Switching Router Y
S-PEZ: Switching Provider Edge Z T-PE Z: Terminating Provider Edge Z
Figure 5 Reference Model for the MPLS-TP OAM Framework Figure 5: Reference Model for the MPLS-TP OAM Framework
Figure 5 depicts a high-level reference model for the MPLS-TP Figure 5 depicts a high-level reference model for the MPLS-TP OAM
OAM framework. The figure depicts portions of two MPLS-TP framework. The figure depicts portions of two MPLS-TP-enabled
enabled network domains, Domain 1 and Domain Z. In Domain 1, network domains, Domain 1 and Domain Z. In Domain 1, T-PE 1 is
LSR1 is adjacent to LSR2 via the MPLS-TP Section Sec12 and LSR2 adjacent to LSR 2 via the MPLS-TP Section Sec12, and LSR 2 is
is adjacent to LSR3 via the MPLS-TP Section Sec23. Similarly, in adjacent to S-PE 3 via the MPLS-TP Section Sec23. Similarly, in
Domain Z, LSRX is adjacent to LSRY via the MPLS-TP Section SecXY Domain Z, S-PE X is adjacent to LSR Y via the MPLS-TP Section SecXY,
and LSRY is adjacent to LSRZ via the MPLS-TP Section SecYZ. In and LSR Y is adjacent to T-PE Z via the MPLS-TP Section SecYZ. In
addition, LSR3 is adjacent to LSRX via the MPLS-TP Section 3X. addition, S-PE 3 is adjacent to S-PE X via the MPLS-TP Section Sec3X.
Figure 5 also shows a bi-directional MS-PW (PW1Z) between AC1 on Figure 5 also shows a bidirectional MS-PW (MS-PW1Z) between AC1 on
T-PE1 and AC2 on T-PEZ. The MS-PW consists of three T-PE1 and AC2 on T-PE Z. The MS-PW consists of three bidirectional
bi-directional PW path segments: 1) PW13 path segment between PW path segments: 1) PW13 path segment between T-PE 1 and S-PE 3 via
T-PE1 and S-PE3 via the bi-directional LSP13 LSP, 2) PW3X path the bidirectional LSP13 LSP, 2) PW3X path segment between S-PE 3 and
segment between S-PE3 and S-PEX, via the bi-directional LSP3X S-PE X via the bidirectional LSP3X LSP, and 3) PWXZ path segment
LSP, and 3) PWXZ path segment between S-PEX and T-PEZ via the between S-PE X and T-PE Z via the bidirectional LSPXZ LSP.
bi-directional LSPXZ LSP.
The MPLS-TP OAM procedures that apply to a MEG are expected to The MPLS-TP OAM procedures that apply to a MEG are expected to
operate independently from procedures on other MEGs. Yet, this operate independently from procedures on other MEGs. Yet, this does
does not preclude that multiple MEGs may be affected not preclude that multiple MEGs may be affected simultaneously by the
simultaneously by the same network condition, for example, a same network condition -- for example, a fiber cut event.
fiber cut event.
Note that there are no constrains imposed by this OAM framework Note that there are no constraints imposed by this OAM framework on
on the number, or type (p2p, p2mp, LSP or PW), of MEGs that may the number or type (P2P, P2MP, LSP, or PW), of MEGs that may be
be instantiated on a particular node. In particular, when instantiated on a particular node. In particular, when looking at
looking at Figure 5, it should be possible to configure one or Figure 5, it should be possible to configure one or more MEPs on the
more MEPs on the same node if that node is the endpoint of one same node if that node is the end point of one or more MEGs.
or more MEGs.
Figure 5 does not describe a PW3X PSMEG because typically SPMEs Figure 5 does not describe a PW3X PSMEG because typically SPMEs are
are used to monitor an OAM domain (like PW13 and PWXZ PSMEGs) used to monitor an OAM domain (like PW13 and PWXZ PSMEGs) rather than
rather than the segment between two OAM domains. However the OAM the segment between two OAM domains. However, the OAM framework does
framework does not pose any constraints on the way SPMEs are not pose any constraints on the way SPMEs are instantiated as long as
instantiated as long as they are not overlapping. they are not overlapping.
The subsections below define the MEGs specified in this MPLS-TP The subsections below define the MEGs specified in this MPLS-TP OAM
OAM architecture framework document. Unless otherwise stated, architecture framework document. Unless otherwise stated, all
all references to domains, LSRs, MPLS-TP Sections, LSPs, references to domains, LSRs, MPLS-TP Sections, LSPs, pseudowires, and
pseudowires and MEGs in this section are made in relation to MEGs in this section are made in relation to those shown in Figure 5.
those shown in Figure 5.
4.1. MPLS-TP Section Monitoring (SMEG) 4.1. MPLS-TP Section Monitoring (SMEG)
An MPLS-TP Section MEG (SMEG) is an MPLS-TP maintenance entity An MPLS-TP Section MEG (SMEG) is an MPLS-TP maintenance entity
intended to monitor an MPLS-TP Section as defined in RFC 5654 intended to monitor an MPLS-TP Section. An SMEG may be configured on
[5]. An SMEG may be configured on any MPLS-TP section. SMEG OAM any MPLS-TP section. SMEG OAM packets must fate-share with the user
packets must fate-share with the user data packets sent over the data packets sent over the monitored MPLS-TP Section.
monitored MPLS-TP Section.
An SMEG is intended to be deployed for applications where it is An SMEG is intended to be deployed for applications where it is
preferable to monitor the link between topologically adjacent preferable to monitor the link between topologically adjacent (next
(next hop in this layer network) MPLS-TP LSRs rather than hop in this layer network) MPLS-TP LSRs rather than monitoring the
monitoring the individual LSP or PW path segments traversing the individual LSP or PW path segments traversing the MPLS-TP Section and
MPLS-TP Section and the server layer technology does not provide where the server-layer technology does not provide adequate OAM
adequate OAM capabilities. capabilities.
Figure 5 shows five Section MEGs configured in the network Figure 5 shows five Section MEGs configured in the network between
between AC1 and AC2: AC1 and AC2:
1. Sec12 MEG associated with the MPLS-TP Section between LSR 1 1. Sec12 MEG associated with the MPLS-TP Section between T-PE 1 and
and LSR 2, LSR 2,
2. Sec23 MEG associated with the MPLS-TP Section between LSR 2 2. Sec23 MEG associated with the MPLS-TP Section between LSR 2 and
and LSR 3, S-PE 3,
3. Sec3X MEG associated with the MPLS-TP Section between LSR 3 3. Sec3X MEG associated with the MPLS-TP Section between S-PE 3 and
and LSR X, S-PE X,
4. SecXY MEG associated with the MPLS-TP Section between LSR X 4. SecXY MEG associated with the MPLS-TP Section between S-PE X and
and LSR Y, and LSR Y, and
5. SecYZ MEG associated with the MPLS-TP Section between LSR Y 5. SecYZ MEG associated with the MPLS-TP Section between LSR Y and
and LSR Z. T-PE Z
4.2. MPLS-TP LSP End-to-End Monitoring Group (LMEG) 4.2. MPLS-TP LSP End-to-End Monitoring Group (LMEG)
An MPLS-TP LSP MEG (LMEG) is an MPLS-TP maintenance entity group An MPLS-TP LSP MEG (LMEG) is an MPLS-TP maintenance entity group
intended to monitor an end-to-end LSP between its LERs. An LMEG intended to monitor an end-to-end LSP between its LERs. An LMEG may
may be configured on any MPLS LSP. LMEG OAM packets must be configured on any MPLS LSP. LMEG OAM packets must fate-share with
fate-share with user data packets sent over the monitored MPLS- user data packets sent over the monitored MPLS-TP LSP.
TP LSP.
An LMEG is intended to be deployed in scenarios where it is An LMEG is intended to be deployed in scenarios where it is desirable
desirable to monitor an entire LSP between its LERs, rather to monitor an entire LSP between its LERs, rather than, say,
than, say, monitoring individual PWs. monitoring individual PWs.
Figure 5 depicts two LMEGs configured in the network between AC1 Figure 5 depicts two LMEGs configured in the network between AC1 and
and AC2: 1) the LSP13 LMEG between LER 1 and LER 3, and 2) the AC2: 1) the LSP13 LMEG between T-PE 1 and S-PE 3, and 2) the LSPXZ
LSPXZ LMEG between LER X and LER Y. Note that the presence of a LMEG between S-PE X and T-PE Z. Note that the presence of a LSP3X
LSP3X LMEG in such a configuration is optional, hence, not LMEG in such a configuration is optional, and hence, not precluded by
precluded by this framework. For instance, the SPs may prefer to this framework. For instance, the network operator may prefer to
monitor the MPLS-TP Section between the two LSRs rather than the monitor the MPLS-TP Section between the two LSRs rather than the
individual LSPs. individual LSPs.
4.3. MPLS-TP PW Monitoring (PMEG) 4.3. MPLS-TP PW Monitoring (PMEG)
An MPLS-TP PW MEG (PMEG) is an MPLS-TP maintenance entity An MPLS-TP PW MEG (PMEG) is an MPLS-TP maintenance entity intended to
intended to monitor a SS-PW or MS-PW between its T-PEs. A PMEG monitor a SS-PW or MS-PW between its T-PEs. A PMEG can be configured
can be configured on any SS-PW or MS-PW. PMEG OAM packets must on any SS-PW or MS-PW. PMEG OAM packets must fate-share with the
fate-share with the user data packets sent over the monitored user data packets sent over the monitored PW.
PW.
A PMEG is intended to be deployed in scenarios where it is A PMEG is intended to be deployed in scenarios where it is desirable
desirable to monitor an entire PW between a pair of MPLS-TP to monitor an entire PW between a pair of MPLS-TP-enabled T-PEs
enabled T-PEs rather than monitoring the LSP aggregating rather than monitoring the LSP that aggregates multiple PWs between
multiple PWs between PEs. PEs.
Figure 5 depicts a MS-PW (MS-PW1Z) consisting of three path Figure 5 depicts an MS-PW (MS-PW1Z) consisting of three path segments
segments: PW13, PW3X and PWXZ and its associated end-to-end PMEG (PW13, PW3X, and PWXZ) and its associated end-to-end PMEG (PW1Z
(PW1Z PMEG). PMEG).
4.4. MPLS-TP LSP SPME Monitoring (LSMEG) 4.4. MPLS-TP LSP SPME Monitoring (LSMEG)
An MPLS-TP LSP SPME MEG (LSMEG) is an MPLS-TP SPME with an An MPLS-TP LSP SPME MEG (LSMEG) is an MPLS-TP SPME with an associated
associated maintenance entity group intended to monitor an maintenance entity group intended to monitor an arbitrary part of an
arbitrary part of an LSP between the MEPs instantiated for the LSP between the MEPs instantiated for the SPME, independent from the
SPME independent from the end-to-end monitoring (LMEG). An LSMEG end-to-end monitoring (LMEG). An LSMEG can monitor an LSP path
can monitor an LSP path segment and it may also include the segment, and it may also include the forwarding engine(s) of the
forwarding engine(s) of the node(s) at the edge(s) of the path node(s) at the edge(s) of the path segment.
segment.
When SPME is established between non-adjacent LSRs, the edges of When an SPME is established between non-adjacent LSRs, the edges of
the SPME becomes adjacent at the LSP sub-layer network and any the SPME become adjacent at the LSP sub-layer network and any LSR
LSR that were previously in between becomes an LSR for the SPME. that was previously in between becomes an LSR for the SPME.
Multiple hierarchical LSMEGs can be configured on any LSP. LSMEG Multiple hierarchical LSMEGs can be configured on any LSP. LSMEG OAM
OAM packets must fate-share with the user data packets sent over packets must fate-share with the user data packets sent over the
the monitored LSP path segment. monitored LSP path segment.
A LSME can be defined between the following entities: A LSME can be defined between the following entities:
o The LER and LSR of a given LSP. o The LER and LSR of a given LSP.
o Any two LSRs of a given LSP. o Any two LSRs of a given LSP.
An LSMEG is intended to be deployed in scenarios where it is An LSMEG is intended to be deployed in scenarios where it is
preferable to monitor the behavior of a part of an LSP or set of preferable to monitor the behavior of a part of an LSP or set of LSPs
LSPs rather than the entire LSP itself, for example when there rather than the entire LSP itself, for example, when there is a need
is a need to monitor a part of an LSP that extends beyond the to monitor a part of an LSP that extends beyond the administrative
administrative boundaries of an MPLS-TP enabled administrative boundaries of an MPLS-TP-enabled administrative domain.
domain.
|<-------------------- PW1Z ------------------->| |<-------------------- PW1Z ------------------->|
| | | |
| |<-------------LSP1Z LSP------------->| | | |<-------------LSP1Z LSP------------->| |
| |<-LSP13->| |<LSP3X>| |<-LSPXZ->| | | |<-LSP13->| |<LSP3X>| |<-LSPXZ->| |
V V V V V V V V V V V V V V V V
+----+ +---+ +----+ +----+ +---+ +----+ +----+ +---+ +----+ +----+ +---+ +----+
+----+ | PE | |LSR| |DBN | |DBN | |LSR| | PE | +----+ +----+ | PE | |LSR| |DBN | |DBN | |LSR| | PE | +----+
| | | 1 | | 2 | | 3 | | X | | Y | | Z | | | | | | 1 | | 2 | | 3 | | X | | Y | | Z | | |
| |AC1| |=====================================| |AC2| | | |AC1| |=====================================| |AC2| |
| CE1|---|.....................PW1Z......................|---|CE2 | | CE1|---|.....................PW1Z......................|---|CE2 |
| | | |=====================================| | | | | | | |=====================================| | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
+----+ | | | | | | | | | | | | +----+ +----+ | | | | | | | | | | | | +----+
+----+ +---+ +----+ +----+ +---+ +----+ +----+ +---+ +----+ +----+ +---+ +----+
. . . . . . . .
| | | | | | | |
|<---- Domain 1 --->| |<---- Domain Z --->| |<---- Domain 1 --->| |<---- Domain Z --->|
^---------^ ^---------^ ^---------^ ^---------^
LSP13 LSMEG LSPXZ LSMEG LSP13 LSMEG LSPXZ LSMEG
^-------------------------------------^ ^-------------------------------------^
LSP1Z LMEG LSP1Z LMEG
DBN: Domain Border Node DBN: Domain Border Node
Figure 6 MPLS-TP LSP SPME MEG (LSMEG) PE 1: Provider Edge 1
LSR 2: Label Switching Router 2
DBN 3: Domain Border Node 3
DBN X: Domain Border Node X
LSR Y: Label Switching Router Y
PE Z: Provider Edge Z
Figure 6 depicts a variation of the reference model in Figure 5 Figure 6: MPLS-TP LSP SPME MEG (LSMEG)
where there is an end-to-end LSP (LSP1Z) between PE1 and PEZ.
LSP1Z consists of, at least, three LSP Concatenated Segments:
LSP13, LSP3X and LSPXZ. In this scenario there are two separate
LSMEGs configured to monitor the LSP1Z: 1) a LSMEG monitoring
the LSP13 Concatenated Segment on Domain 1 (LSP13 LSMEG), and 2)
a LSMEG monitoring the LSPXZ Concatenated Segment on Domain Z
(LSPXZ LSMEG).
It is worth noticing that LSMEGs can coexist with the LMEG Figure 6 depicts a variation of the reference model in Figure 5 where
monitoring the end-to-end LSP and that LSMEG MEPs and LMEG MEPs there is an end-to-end LSP (LSP1Z) between PE 1 and PE Z. LSP1Z
can be coincident in the same node (e.g. PE1 node supports both consists of, at least, three LSP Concatenated Segments: LSP13, LSP3X,
the LSP1Z LMEG MEP and the LSP13 LSMEG MEP). and LSPXZ. In this scenario, there are two separate LSMEGs
configured to monitor the LSP1Z: 1) a LSMEG monitoring the LSP13
Concatenated Segment on Domain 1 (LSP13 LSMEG), and 2) a LSMEG
monitoring the LSPXZ Concatenated Segment on Domain Z (LSPXZ LSMEG).
4.5. MPLS-TP MS-PW SPME Monitoring (PSMEG) It is worth noticing that LSMEGs can coexist with the LMEG monitoring
the end-to-end LSP and that LSMEG MEPs and LMEG MEPs can be
coincident in the same node (e.g., PE 1 node supports both the LSP1Z
LMEG MEP and the LSP13 LSMEG MEP).
An MPLS-TP MS-PW SPME Monitoring MEG (PSMEG) is an MPLS-TP SPME 4.5. MPLS-TP MS-PW SPME Monitoring (PSMEG)
with an associated maintenance entity group intended to monitor
an arbitrary part of an MS-PW between the MEPs instantiated for
the SPME independently of the end-to-end monitoring (PMEG). A
PSMEG can monitor a PW path segment and it may also include the
forwarding engine(s) of the node(s) at the edge(s) of the path
segment. A PSMEG is no different than an SPME, it is simply
named as such to discuss SPMEs specifically in a PW context.
When SPME is established between non-adjacent S-PEs, the edges An MPLS-TP MS-PW SPME Monitoring MEG (PSMEG) is an MPLS-TP SPME with
of the SPME becomes adjacent at the MS-PW sub-layer network and an associated maintenance entity group intended to monitor an
any S-PEs that were previously in between becomes an LSR for the arbitrary part of an MS-PW between the MEPs instantiated for the
SPME. SPME, independently of the end-to-end monitoring (PMEG). A PSMEG can
monitor a PW path segment, and it may also include the forwarding
engine(s) of the node(s) at the edge(s) of the path segment. A PSMEG
is no different than an SPME; it is simply named as such to discuss
SPMEs specifically in a PW context.
S-PE placement is typically dictated by considerations other When SPME is established between non-adjacent S-PEs, the edges of the
than OAM. S-PEs will frequently reside at operational boundaries SPME become adjacent at the MS-PW sub-layer network, and any S-PE
such as the transition from distributed control plane (CP) to that was previously in between becomes an LSR for the SPME.
centralized Network Management System (NMS) control or at a
routing area boundary. As such the architecture would appear not S-PE placement is typically dictated by considerations other than
to have the flexibility that arbitrary placement of SPME OAM. S-PEs will frequently reside at operational boundaries such as
segments would imply. Support for an arbitrary placement of the transition from distributed control plane (CP) to centralized
PSMEG would require the definition of additional PW Network Management System (NMS) control or at a routing area
sub-layering. boundary. As such, the architecture would appear not to have the
Multiple hierarchical PSMEGs can be configured on any MS-PW. flexibility that arbitrary placement of SPME segments would imply.
PSMEG OAM packets fate-share with the user data packets sent Support for an arbitrary placement of PSMEG would require the
over the monitored PW path Segment. definition of additional PW sub-layering. Multiple hierarchical
PSMEGs can be configured on any MS-PW. PSMEG OAM packets fate-share
with the user data packets sent over the monitored PW path Segment.
A PSMEG does not add hierarchical components to the MPLS A PSMEG does not add hierarchical components to the MPLS
architecture, it defines the role of existing components for the architecture; it defines the role of existing components for the
purposes of discussing OAM functionality. purposes of discussing OAM functionality.
A PSME can be defined between the following entities: A PSME can be defined between the following entities:
o T-PE and any S-PE of a given MS-PW o The T-PE and any S-PE of a given MS-PW.
o Any two S-PEs of a given MS-PW. o Any two S-PEs of a given MS-PW.
Note that, in line with the SPME description in section 3.2, when a Note that, in line with the SPME description in Section 3.2, when a
PW SPME is instantiated after the MS-PW has been instantiated, the PW SPME is instantiated after the MS-PW has been instantiated, the
TTL distance of the MIPs may change and MIPs in the PW SPME are no TTL distance of the MIPs may change and MIPs in the PW SPME are no
longer part of the encompassing MEG. This means that the S-PE nodes longer part of the encompassing MEG. This means that the S-PE nodes
hosting these MIPs are no longer S-PEs but P nodes at the SPME LSP hosting these MIPs are no longer S-PEs but P nodes at the SPME LSP
level. The consequences are that the S-PEs hosting the PSMEG MEPs level. The consequences are that the S-PEs hosting the PSMEG MEPs
become adjacent S-PEs. This is no different than the operation of become adjacent S-PEs. This is no different than the operation of
SPMEs in general. SPMEs in general.
A PSMEG is intended to be deployed in scenarios where it is A PSMEG is intended to be deployed in scenarios where it is
preferable to monitor the behavior of a part of a MS-PW rather preferable to monitor the behavior of a part of an MS-PW rather than
than the entire end-to-end PW itself, for example to monitor an the entire end-to-end PW itself, for example, when monitoring an MS-
MS-PW path segment within a given network domain of an inter- PW path segment within a given network domain of an inter-domain MS-
domain MS-PW. PW.
Figure 5 depicts a MS-PW (MS-PW1Z) consisting of three path Figure 5 depicts an MS-PW (MS-PW1Z) consisting of three path
segments: PW13, PW3X and PWXZ with two separate PSMEGs: 1) a segments: PW13, PW3X, and PWXZ with two separate PSMEGs: 1) a PSMEG
PSMEG monitoring the PW13 MS-PW path segment on Domain 1 (PW13 monitoring the PW13 MS-PW path segment on Domain 1 (PW13 PSMEG) and
PSMEG), and 2) a PSMEG monitoring the PWXZ MS-PW path segment on 2) a PSMEG monitoring the PWXZ MS-PW path segment on Domain Z with
Domain Z with (PWXZ PSMEG). (PWXZ PSMEG).
It is worth noticing that PSMEGs can coexist with the PMEG It is worth noticing that PSMEGs can coexist with the PMEG monitoring
monitoring the end-to-end MS-PW and that PSMEG MEPs and PMEG the end-to-end MS-PW and that PSMEG MEPs and PMEG MEPs can be
MEPs can be coincident in the same node (e.g. T-PE1 node coincident in the same node (e.g., T-PE 1 node supports both the PW1Z
supports both the PW1Z PMEG MEP and the PW13 PSMEG MEP). PMEG MEP and the PW13 PSMEG MEP).
4.6. Fate sharing considerations for multilink 4.6. Fate-Sharing Considerations for Multilink
Multilink techniques are in use today and are expected to Multilink techniques are in use today and are expected to continue to
continue to be used in future deployments. These techniques be used in future deployments. These techniques include Ethernet
include Ethernet Link Aggregation [22] and the use of Link link aggregation [22] and the use of link bundling for MPLS [18]
Bundling for MPLS [18] where the option to spread traffic over where the option to spread traffic over component links is supported
component links is supported and enabled. While the use of Link and enabled. While the use of link bundling can be controlled at the
Bundling can be controlled at the MPLS-TP layer, use of Link MPLS-TP layer, use of link aggregation (or any server-layer-specific
Aggregation (or any server layer specific multilink) is not multilink) is not necessarily under the control of the MPLS-TP layer.
necessarily under control of the MPLS-TP layer. Other techniques Other techniques may emerge in the future. These techniques
may emerge in the future. These techniques frequently share the frequently share the characteristic that an LSP may be spread over a
characteristic that an LSP may be spread over a set of component set of component links and therefore be reordered, but no flow within
links and therefore be reordered but no flow within the LSP is the LSP is reordered (except when very infrequent and minimally
reordered (except when very infrequent and minimally disruptive disruptive load rebalancing occurs).
load rebalancing occurs).
The use of multilink techniques may be prohibited or permitted The use of multilink techniques may be prohibited or permitted in any
in any particular deployment. If multilink techniques are used, particular deployment. If multilink techniques are used, the
the deployment can be considered to be only partially MPLS-TP deployment can be considered to be only partially MPLS-TP compliant;
compliant, however this is unlikely to prevent its use. however, this is unlikely to prevent their use.
The implications for OAM are that not all components of a The implications for OAM are that not all components of a multilink
multilink will be exercised, independent server layer OAM being will be exercised, independent server-layer OAM being required to
required to exercise the aggregated link components. This has exercise the aggregated link components. This has further
further implications for MIP and MEP placement, as per-interface implications for MIP and MEP placement, as per-interface MIPs or Down
MIPs or "down" MEPs on a multilink interface are akin to a layer MEPs on a multilink interface are akin to a layer violation, as they
violation, as they instrument at the granularity of the server instrument at the granularity of the server layer. The implications
layer. The implications for reduced OAM loss measurement for reduced OAM loss measurement functionality are documented in
functionality are documented in sections 5.5.3 and 6.2.3. Sections 5.5.3 and 6.2.3.
5. OAM Functions for proactive monitoring 5. OAM Functions for Proactive Monitoring
In this document, proactive monitoring refers to OAM operations In this document, proactive monitoring refers to OAM operations that
that are either configured to be carried out periodically and are either configured to be carried out periodically and continuously
continuously or preconfigured to act on certain events such as or preconfigured to act on certain events such as alarm signals.
alarm signals.
Proactive monitoring is usually performed "in-service". Such Proactive monitoring is usually performed "in-service". Such
transactions are universally MEP to MEP in operation while transactions are universally MEP to MEP in operation, while
notifications can be node to node (e.g. some MS-PW transactions) notifications can be node to node (e.g., some MS-PW transactions) or
or node to MEPs (e.g., AIS). The control and measurement node to MEPs (e.g., AIS). The control and measurement considerations
considerations are: are:
1. Proactive monitoring for a MEG is typically configured at 1. Proactive monitoring for a MEG is typically configured at the
transport path creation time. creation time of the transport path.
2. The operational characteristics of in-band measurement 2. The operational characteristics of in-band measurement
transactions (e.g., CV, Loss Measurement (LM) etc.) are transactions (e.g., CV, Loss Measurement (LM), etc.) are
configured at the MEPs. configured at the MEPs.
3. Server layer events are reported by OAM packets originating 3. Server-layer events are reported by OAM packets originating at
at intermediate nodes. intermediate nodes.
4. The measurements resulting from proactive monitoring are 4. The measurements resulting from proactive monitoring are typically
typically reported outside of the MEG (e.g. to a management reported outside of the MEG (e.g., to a management system) as
system) as notifications events such as faults or indications notification events such as faults or indications of performance
of performance degradations (such as signal degrade degradations (such as signal degrade conditions).
conditions).
5. The measurements resulting from proactive monitoring may be 5. The measurements resulting from proactive monitoring may be
periodically harvested by an NMS. periodically harvested by an NMS.
Pro-active fault reporting is assumed to be subject to Proactive fault reporting is assumed to be subject to unreliable
unreliable delivery, soft-state and need to operate also in delivery and soft-state, and it needs to operate in cases where a
cases where a return path is not available or faulty. Therefore return path is not available or faulty. Therefore, periodic
periodic repetition is assumed to be used for reliability, repetition is assumed to be used for reliability, instead of
instead of handshaking. handshaking.
Delay measurement requires periodic repetition also to allow Delay measurement also requires periodic repetition to allow
estimation of the packet delay variation for the MEG. estimation of the packet delay variation for the MEG.
For statically provisioned transport paths the above information For statically provisioned transport paths, the above information is
is statically configured; for dynamically established transport statically configured; for dynamically established transport paths,
paths the configuration information is signaled via the control the configuration information is signaled via the control plane or
plane or configured via the management plane. configured via the management plane.
The operator may enable/disable some of the consequent actions The operator may enable/disable some of the consequent actions
defined in section 5.1.2. defined in Section 5.1.2.
5.1. Continuity Check and Connectivity Verification 5.1. Continuity Check and Connectivity Verification
Proactive Continuity Check functions, as required in section Proactive Continuity Check functions, as required in Section 2.2.2 of
2.2.2 of RFC 5860 [11], are used to detect a loss of continuity RFC 5860 [11], are used to detect a loss of continuity (LOC) defect
defect (LOC) between two MEPs in a MEG. between two MEPs in a MEG.
Proactive Connectivity Verification functions, as required in Proactive Connectivity Verification functions, as required in Section
section 2.2.3 of RFC 5860 [11], are used to detect an unexpected 2.2.3 of RFC 5860 [11], are used to detect an unexpected connectivity
connectivity defect between two MEGs (e.g. mismerging or defect between two MEGs (e.g., mismerging or misconnection), as well
misconnection), as well as unexpected connectivity within the as unexpected connectivity within the MEG with an unexpected MEP.
MEG with an unexpected MEP.
Both functions are based on the (proactive) generation, at the Both functions are based on the (proactive) generation, at the same
same rate, of OAM packets by the source MEP that are processed rate, of OAM packets by the source MEP that are processed by the peer
by the peer sink MEP(s). As a consequence, in order to save OAM sink MEP(s). As a consequence, in order to save OAM bandwidth
bandwidth consumption, CV, when used, is linked with CC into consumption, CV, when used, is linked with CC into Continuity Check
Continuity Check and Connectivity Verification (CC-V) OAM and Connectivity Verification (CC-V) OAM packets.
packets.
In order to perform pro-active Connectivity Verification, each In order to perform proactive Connectivity Verification, each CC-V
CC-V OAM packet also includes a globally unique Source MEP OAM packet also includes a globally unique Source MEP identifier,
identifier, whose value needs to be configured on the source MEP whose value needs to be configured on the source MEP and on the peer
and on the peer sink MEP(s). In some cases, to avoid the need to sink MEP(s). In some cases, to avoid the need to configure the
configure the globally unique Source MEP identifier, it is globally unique Source MEP identifier, it is preferable to perform
preferable to perform only pro-active Continuity Check. In this only proactive Continuity Check. In this case, the CC-V OAM packet
case, the CC-V OAM packet does not need to include any globally does not need to include any globally unique Source MEP identifier.
unique Source MEP identifier. Therefore, an MEG can be monitored Therefore, a MEG can be monitored only for CC or for both CC and CV.
only for CC or for both CC and CV. CC-V OAM packets used for CC- CC-V OAM packets used for CC-only monitoring are called CC OAM
only monitoring are called CC OAM packets while CC-V OAM packets packets, while CC-V OAM packets used for both CC and CV are called CV
used for both CC and CV are called CV OAM packets. OAM packets.
As a consequence, it is not possible to detect misconnections As a consequence, it is not possible to detect misconnections between
between two MEGs monitored only for continuity as neither the two MEGs monitored only for continuity as neither the OAM packet type
OAM packet type nor the OAM packet content provides sufficient nor the OAM packet content provides sufficient information to
information to disambiguate an invalid source. To expand: disambiguate an invalid source. To expand:
o For CC OAM packet leaking into a CC monitored MEG - o For a CC OAM packet leaking into a CC monitored MEG -
undetectable. undetectable.
o For CV OAM packet leaking into a CC monitored MEG - reception o For a CV OAM packet leaking into a CC monitored MEG - reception of
of CV OAM packets instead of a CC OAM packets (e.g., with the CV OAM packets instead of a CC OAM packets (e.g., with the
additional Source MEP identifier) allows detecting the fault. additional Source MEP identifier) allows detecting the fault.
o For CC OAM packet leaking into a CV monitored MEG - reception o For a CC OAM packet leaking into a CV monitored MEG - reception of
of CC OAM packets instead of CV OAM packets (e.g., lack of CC OAM packets instead of CV OAM packets (e.g., lack of additional
additional Source MEP identifier) allows detecting the fault. Source MEP identifier) allows detecting the fault.
o For CV OAM packet leaking into a CV monitored MEG - reception o For a CV OAM packet leaking into a CV monitored MEG - reception of
of CV OAM packets with different Source MEP identifier CV OAM packets with different Source MEP identifier permits fault
permits fault to be identified. to be identified.
Having a common packet format for CC-V OAM packets would Having a common packet format for CC-V OAM packets would simplify
simplify parsing in a sink MEP to properly detect all the parsing in a sink MEP to properly detect all the misconfiguration
mis-configuration cases described above. cases described above.
Different formats of MEP identifiers are defined in [10] to MPLS-TP OAM supports different formats of MEP identifiers to address
address different environments. When an alternative to IP different environments. When an alternative to IP addressing is
addressing is desired (e.g., MPLS-TP is deployed in transport desired (e.g., MPLS-TP is deployed in transport network environments
network environments where consistent operations with other where consistent operations with other transport technologies defined
transport technologies defined by the ITU-T are required), the by the ITU-T are required), the ITU Carrier Code (ICC)-based format
ITU Carrier Code (ICC)-based format for MEP identification is for MEP identification is used: this format is under definition in
used. When MPLS-TP is deployed in an environment where IP [25]. When MPLS-TP is deployed in an environment where IP
capabilities are available and desired for OAM, the IP-based MEP capabilities are available and desired for OAM, the IP-based MEP
identification is used. identification is used: this format is described in [24].
CC-V OAM packets are transmitted at a regular, operator CC-V OAM packets are transmitted at a regular, operator-configurable
configurable, rate. The default CC-V transmission periods are rate. The default CC-V transmission periods are application
application dependent (see section 5.1.3). dependent (see Section 5.1.3).
Proactive CC-V OAM packets are transmitted with the "minimum Proactive CC-V OAM packets are transmitted with the "minimum loss
loss probability PHB" within the transport path (LSP, PW) they probability PHB" within the transport path (LSP, PW) they are
are monitoring. For E-LSPs, this PHB is configurable on network monitoring. For E-LSPs, this PHB is configurable on the network
operator's basis while for L-LSPs this is determined as per RFC operator's basis, while for L-LSPs this is determined as per RFC 3270
3270 [23]. PHBs can be translated at the network borders by the [23]. PHBs can be translated at the network borders by the same
same function that translates it for user data traffic. The function that translates them for user data traffic. The implication
implication is that CC-V fate-shares with much of the forwarding is that CC-V fate-shares with much of the forwarding implementation,
implementation, but not all aspects of PHB processing are but not all aspects of PHB processing are exercised. Either on-
exercised. Either on-demand tools are used for finer grained demand tools are used for finer-grained fault finding or an
fault finding or an implementation may utilize a CC-V flow per implementation may utilize a CC-V flow per PHB to ensure a CC-V flow
PHB to ensure a CC-V flow fate-shares with each individual PHB. fate-shares with each individual PHB.
In a co-routed or associated, bidirectional point-to-point In a co-routed or associated, bidirectional point-to-point transport
transport path, when a MEP is enabled to generate pro-active path, when a MEP is enabled to generate proactive CC-V OAM packets
CC-V OAM packets with a configured transmission rate, it also with a configured transmission rate, it also expects to receive
expects to receive pro-active CC-V OAM packets from its peer MEP proactive CC-V OAM packets from its peer MEP at the same transmission
at the same transmission rate as a common SLA applies to all rate. This is because a common SLA applies to all components of the
components of the transport path. In a unidirectional transport transport path. In a unidirectional transport path (either point-to-
path (either point-to-point or point-to-multipoint), the source point or point-to-multipoint), the source MEP is enabled only to
MEP is enabled only to generate CC-V OAM packets while each sink generate CC-V OAM packets, while each sink MEP is configured to
MEP is configured to expect these packets at the configured expect these packets at the configured rate.
rate.
MIPs, as well as intermediate nodes not supporting MPLS-TP OAM, MIPs, as well as intermediate nodes not supporting MPLS-TP OAM, are
are transparent to the pro-active CC-V information and forward transparent to the proactive CC-V information and forward these
these pro-active CC-V OAM packets as regular data packets. proactive CC-V OAM packets as regular data packets.
During path setup and tear down, situations arise where CC-V During path setup and tear down, situations arise where CC-V checks
checks would give rise to alarms, as the path is not fully would give rise to alarms, as the path is not fully instantiated. In
instantiated. In order to avoid these spurious alarms the order to avoid these spurious alarms, the following procedures are
following procedures are recommended. At initialization, the recommended. At initialization, the source MEP function (generating
source MEP function (generating pro-active CC-V packets) should proactive CC-V packets) should be enabled prior to the corresponding
be enabled prior to the corresponding sink MEP function sink MEP function (detecting continuity and connectivity defects).
(detecting continuity and connectivity defects). When disabling When disabling the CC-V proactive functionality, the sink MEP
the CC-V proactive functionality, the sink MEP function should function should be disabled prior to the corresponding source MEP
be disabled prior to the corresponding source MEP function. function.
It should be noted that different encapsulations are possible It should be noted that different encapsulations are possible for
for CC-V packets and therefore it is possible that in case of CC-V packets, and therefore it is possible that in case of
mis-configurations or mis-connectivity, CC-V packets are misconfigurations or mis-connectivity, CC-V packets are received with
received with an unexpected encapsulation. an unexpected encapsulation.
There are practical limitations to detecting unexpected There are practical limitations to detecting unexpected
encapsulation. It is possible that there are mis-configuration encapsulation. It is possible that there are misconfiguration or
or mis-connectivity scenarios where OAM packets can alias as mis-connectivity scenarios where OAM packets can alias as payload,
payload, e.g., when a transport path can carry an arbitrary e.g., when a transport path can carry an arbitrary payload without a
payload without a pseudo wire. pseudowire.
When CC-V packets are received with an unexpected encapsulation When CC-V packets are received with an unexpected encapsulation that
that can be parsed by a sink MEP, the CC-V packet is processed can be parsed by a sink MEP, the CC-V packet is processed as if it
as it were received with the correct encapsulation and if it is were received with the correct encapsulation. If it is not a
not a manifestation of a mis-connectivity defect a warning is manifestation of a mis-connectivity defect, a warning is raised (see
raised (see section 5.1.1.4). Otherwise the CC-V packet may be Section 5.1.1.4). Otherwise, the CC-V packet may be silently
silently discarded as unrecognized and a LOC defect may be discarded as unrecognized and a LOC defect may be detected (see
detected (see section 5.1.1.1). Section 5.1.1.1).
The defect conditions are described in no specific order. The defect conditions are described in no specific order.
5.1.1. Defects identified by CC-V 5.1.1. Defects Identified by CC-V
Pro-active CC-V functions allow a sink MEP to detect the defect Proactive CC-V functions allow a sink MEP to detect the defect
conditions described in the following sub-sections. For all of conditions described in the following subsections. For all of the
the described defect cases, a sink MEP should notify the described defect cases, a sink MEP should notify the equipment fault
equipment fault management process of the detected defect. management process of the detected defect.
Sequential consecutive loss of CC-V packets is considered Sequential consecutive loss of CC-V packets is considered indicative
indicative of an actual break and not congestive loss or of an actual break and not of congestive loss or physical-layer
physical layer degradation. The loss of 3 packets in a row degradation. The loss of 3 packets in a row (implying a detection
(implying a 3.5 insertion time detection interval) is interval that is 3.5 times the insertion time) is interpreted as a
interpreted as a true break and a condition that will not clear true break and a condition that will not clear by itself.
by itself.
A CC-V OAM packet is considered to carry an unexpected globally A CC-V OAM packet is considered to carry an unexpected globally
unique Source MEP identifier if it is a CC OAM packet received unique Source MEP identifier if it is a CC OAM packet received by a
by a sink MEP monitoring the MEG for CV; it is a CV OAM packet sink MEP monitoring the MEG for CV; it is a CV OAM packet received by
received by a sink MEP monitoring the MEG for CC or it is a CV a sink MEP monitoring the MEG for CC, or it is a CV OAM packet
OAM packet received by a sink MEP monitoring the MEG for CV but received by a sink MEP monitoring the MEG for CV but carrying a
carrying a unique Source MEP identifier that is different that unique Source MEP identifier that is different that the expected one.
the expected one. Conversely, the CC-V packet is considered to Conversely, the CC-V packet is considered to have an expected
have an expected globally unique Source MEP identifier where it globally unique Source MEP identifier; it is a CC OAM packet received
is a CC OAM packet received by a sink MEP monitoring the MEG for by a sink MEP monitoring the MEG for CC, or it is a CV OAM packet
CC or it is a it is a CV OAM packet received by a sink MEP received by a sink MEP monitoring the MEG for CV and carrying a
monitoring the MEG for CV and carrying a unique Source MEP unique Source MEP identifier that is equal to the expected one.
identifier that is equal to the expected one.
5.1.1.1. Loss Of Continuity defect 5.1.1.1. Loss of Continuity Defect
When proactive CC-V is enabled, a sink MEP detects a loss of When proactive CC-V is enabled, a sink MEP detects a loss of
continuity (LOC) defect when it fails to receive pro-active CC-V continuity (LOC) defect when it fails to receive proactive CC-V OAM
OAM packets from the source MEP. packets from the source MEP.
o Entry criteria: If no pro-active CC-V OAM packets from the o Entry criteria: If no proactive CC-V OAM packets from the source
source MEP (and in the case of CV, this includes the MEP (and in the case of CV, this includes the requirement to have
requirement to have the expected globally unique Source MEP the expected globally unique Source MEP identifier) are received
identifier) are received within the interval equal to 3.5 within the interval equal to 3.5 times the receiving MEP's
times the receiving MEP's configured CC-V reception period. configured CC-V reception period.
o Exit criteria: A pro-active CC-V OAM packet from the source o Exit criteria: A proactive CC-V OAM packet from the source MEP
MEP (and again in the case of CV, with the expected globally (and again in the case of CV, with the expected globally unique
unique Source MEP identifier) is received. Source MEP identifier) is received.
5.1.1.2. Mis-connectivity defect 5.1.1.2. Mis-Connectivity Defect
When a pro-active CC-V OAM packet is received, a sink MEP When a proactive CC-V OAM packet is received, a sink MEP identifies a
identifies a mis-connectivity defect (e.g. mismerge, mis-connectivity defect (e.g., mismerge, misconnection, or unintended
misconnection or unintended looping) when the received packet looping) when the received packet carries an unexpected globally
carries an unexpected globally unique Source MEP identifier. unique Source MEP identifier.
o Entry criteria: The sink MEP receives a pro-active CC-V OAM o Entry criteria: The sink MEP receives a proactive CC-V OAM packet
packet with an unexpected globally unique Source MEP with an unexpected globally unique Source MEP identifier or with
identifier or with an unexpected encapsulation. an unexpected encapsulation.
o Exit criteria: The sink MEP does not receive any pro-active o Exit criteria: The sink MEP does not receive any proactive CC-V
CC-V OAM packet with an unexpected globally unique Source MEP OAM packet with an unexpected globally unique Source MEP
identifier for an interval equal at least to 3.5 times the identifier for an interval equal at least to 3.5 times the longest
longest transmission period of the pro-active CC-V OAM transmission period of the proactive CC-V OAM packets received
packets received with an unexpected globally unique Source with an unexpected globally unique Source MEP identifier since
MEP identifier since this defect has been raised. This this defect has been raised. This requires the OAM packet to
requires the OAM packet to self identify the CC-V periodicity self-identify the CC-V periodicity, as not all MEPs can be
as not all MEPs can be expected to have knowledge of all expected to have knowledge of all MEGs.
MEGs.
5.1.1.3. Period Misconfiguration defect 5.1.1.3. Period Misconfiguration Defect
If pro-active CC-V OAM packets are received with the expected If proactive CC-V OAM packets are received with the expected globally
globally unique Source MEP identifier but with a transmission unique Source MEP identifier but with a transmission period different
period different than the locally configured reception period, than the locally configured reception period, then a CC-V period
then a CC-V period mis-configuration defect is detected. misconfiguration defect is detected.
o Entry criteria: A MEP receives a CC-V pro-active packet with o Entry criteria: A MEP receives a CC-V proactive packet with the
the expected globally unique Source MEP identifier but with a expected globally unique Source MEP identifier but with a
transmission period different than its own CC-V configured transmission period different than its own CC-V-configured
transmission period. transmission period.
o Exit criteria: The sink MEP does not receive any pro-active o Exit criteria: The sink MEP does not receive any proactive CC-V
CC-V OAM packet with the expected globally unique Source MEP OAM packet with the expected globally unique Source MEP identifier
identifier and an incorrect transmission period for an and an incorrect transmission period for an interval equal at
interval equal at least to 3.5 times the longest transmission least to 3.5 times the longest transmission period of the
period of the pro-active CC-V OAM packets received with the proactive CC-V OAM packets received with the expected globally
expected globally unique Source MEP identifier and an unique Source MEP identifier and an incorrect transmission period
incorrect transmission period since this defect has been since this defect has been raised.
raised.
5.1.1.4. Unexpected encapsulation defect 5.1.1.4. Unexpected Encapsulation Defect
If pro-active CC-V OAM packets are received with the expected If proactive CC-V OAM packets are received with the expected globally
globally unique Source MEP identifier but with an unexpected unique Source MEP identifier but with an unexpected encapsulation,
encapsulation, then a CC-V unexpected encapsulation defect is then a CC-V unexpected encapsulation defect is detected.
detected.
It should be noted that there are practical limitations to It should be noted that there are practical limitations to detecting
detecting unexpected encapsulation (see section 5.1.1). unexpected encapsulation (see Section 5.1.1).
o Entry criteria: A MEP receives a CC-V pro-active packet with o Entry criteria: A MEP receives a CC-V proactive packet with the
the expected globally unique Source MEP identifier but with expected globally unique Source MEP identifier but with an
an unexpected encapsulation. unexpected encapsulation.
o Exit criteria: The sink MEP does not receive any pro-active o Exit criteria: The sink MEP does not receive any proactive CC-V
CC-V OAM packet with the expected globally unique Source MEP OAM packet with the expected globally unique Source MEP identifier
identifier and an unexpected encapsulation for an interval and an unexpected encapsulation for an interval equal at least to
equal at least to 3.5 times the longest transmission period 3.5 times the longest transmission period of the proactive CC-V
of the pro-active CC-V OAM packets received with the expected OAM packets received with the expected globally unique Source MEP
globally unique Source MEP identifier and an unexpected identifier and an unexpected encapsulation since this defect has
encapsulation since this defect has been raised. been raised.
5.1.2. Consequent action 5.1.2. Consequent Action
A sink MEP that detects any of the defect conditions defined in A sink MEP that detects any of the defect conditions defined in
section 5.1.1 declares a defect condition and performs the Section 5.1.1 declares a defect condition and performs the following
following consequent actions. consequent actions.
If a MEP detects a mis-connectivity defect, it blocks all the If a MEP detects a mis-connectivity defect, it blocks all the traffic
traffic (including also the user data packets) that it receives (including also the user data packets) that it receives from the
from the misconnected transport path. misconnected transport path.
If a MEP detects LOC defect that is not caused by a period If a MEP detects a LOC defect that is not caused by a period
mis-configuration, it should block all the traffic (including misconfiguration, it should block all the traffic (including also the
also the user data packets) that it receives from the transport user data packets) that it receives from the transport path, if this
path, if this consequent action has been enabled by the consequent action has been enabled by the operator.
operator.
It is worth noticing that the OAM requirements document [11] It is worth noticing that the OAM requirements document [11]
recommends that CC-V proactive monitoring be enabled on every recommends that CC-V proactive monitoring be enabled on every MEG in
MEG in order to reliably detect connectivity defects. However, order to reliably detect connectivity defects. However, CC-V
CC-V proactive monitoring can be disabled by an operator for a proactive monitoring can be disabled by an operator for a MEG. In
MEG. In the event of a misconnection between a transport path the event of a misconnection between a transport path that is
that is pro-actively monitored for CC-V and a transport path proactively monitored for CC-V and a transport path that is not, the
which is not, the MEP of the former transport path will detect a MEP of the former transport path will detect a LOC defect
LOC defect representing a connectivity problem (e.g. a representing a connectivity problem (e.g., a misconnection with a
misconnection with a transport path where CC-V proactive transport path where CC-V proactive monitoring is not enabled)
monitoring is not enabled) instead of a continuity problem, with instead of a continuity problem, with a consequence of delivery of
a consequent wrong traffic delivering. For these reasons, the traffic to an incorrect destination. For these reasons, the traffic
traffic block consequent action is applied even when a LOC block consequent action is applied even when a LOC condition occurs.
condition occurs. This block consequent action can be disabled This block consequent action can be disabled through configuration.
through configuration. This deactivation of the block action may This deactivation of the block action may be used for activating or
be used for activating or deactivating the monitoring when it is deactivating the monitoring when it is not possible to synchronize
not possible to synchronize the function activation of the two the function activation of the two peer MEPs.
peer MEPs.
If a MEP detects a LOC defect (section 5.1.1.1), a If a MEP detects a LOC defect (Section 5.1.1.1) or a mis-connectivity
mis-connectivity defect (section 5.1.1.2) it declares a signal defect (Section 5.1.1.2), it declares a signal fail condition of the
ME.
It is a matter of local policy whether or not a MEP that detects a
period misconfiguration defect (Section 5.1.1.3) declares a signal
fail condition of the ME. fail condition of the ME.
It is a matter if local policy if a MEP that detects a period The detection of an unexpected encapsulation defect does not have any
misconfiguration defect (section 5.1.1.3) declares a signal fail consequent action: it is just a warning for the network operator. An
condition of the ME. implementation able to detect an unexpected encapsulation but not
able to verify the source MEP ID may choose to declare a mis-
connectivity defect.
The detection of an unexpected encapsulation defect does not 5.1.3. Configuration Considerations
have any consequent action: it is just a warning for the network
operator. An implementation able to detect an unexpected
encapsulation but not able to verify the source MEP ID may
choose to declare a mis-connectivity defect.
5.1.3. Configuration considerations At all MEPs inside a MEG, the following configuration information
needs to be configured when a proactive CC-V function is enabled:
At all MEPs inside a MEG, the following configuration o MEG-ID: the MEG identifier to which the MEP belongs.
information needs to be configured when a proactive CC-V
function is enabled:
o MEG ID; the MEG identifier to which the MEP belongs; o MEP-ID: the MEP's own identity inside the MEG.
o MEP-ID; the MEP's own identity inside the MEG; o list of the other MEPs in the MEG. For a point-to-point MEG, the
o list of the other MEPs in the MEG. For a point-to-point MEG list would consist of the single MEP ID from which the OAM packets
the list would consist of the single MEP ID from which the are expected. In case of the root MEP of a P2MP MEG, the list is
OAM packets are expected. In case of the root MEP of a p2mp composed of all the leaf MEP IDs inside the MEG. In case of the
MEG, the list is composed by all the leaf MEP IDs inside the leaf MEP of a P2MP MEG, the list is composed of the root MEP ID
MEG. In case of the leaf MEP of a p2mp MEG, the list is (i.e., each leaf needs to know the root MEP ID from which it
composed by the root MEP ID (i.e. each leaf needs to know the expects to receive the CC-V OAM packets).
root MEP ID from which it expect to receive the CC-V OAM
packets).
o PHB for E-LSPs; it identifies the per-hop behavior of CC-V o PHB for E-LSPs. It identifies the per-hop behavior of a CC-V
packet. Proactive CC-V packets are transmitted with the packet. Proactive CC-V packets are transmitted with the "minimum
"minimum loss probability PHB" previously configured within a loss probability PHB" previously configured within a single
single network operator. This PHB is configurable on network network operator. This PHB is configurable on network operator's
operator's basis. PHBs can be translated at the network basis. PHBs can be translated at the network borders.
borders.
o transmission rate; the default CC-V transmission periods are o transmission rate. The default CC-V transmission periods are
application dependent (depending on whether they are used to application dependent (depending on whether they are used to
support fault management, performance monitoring, or support fault management, performance monitoring, or protection-
protection switching applications): switching applications):
o Fault Management: default transmission period is 1s (i.e. * Fault Management: default transmission period is 1 s (i.e.,
transmission rate of 1 packet/second). transmission rate of 1 packet/second).
o Performance Management: default transmission period is * Performance Management: default transmission period is 100 ms
100ms (i.e. transmission rate of 10 packets/second). CC-V (i.e., transmission rate of 10 packets/second). CC-V
contributes to the accuracy of performance monitoring contributes to the accuracy of performance monitoring
(PM) statistics by permitting the defect free periods to statistics by permitting the defect-free periods to be properly
be properly distinguished as described in sections 5.5.1 distinguished as described in Sections 5.5.1 and 5.6.1.
and 5.6.1.
o Protection Switching: If protection switching with CC-V * Protection Switching: If protection switching with CC-V, defect
defect entry criteria of 12ms is required (for example, entry criteria of 12 ms is required (for example, in
in conjunction with the requirement to support 50ms conjunction with the requirement to support 50 ms recovery time
recovery time as indicated in RFC 5654 [5]), then an as indicated in RFC 5654 [5]), then an implementation should
implementation should use a default transmission period use a default transmission period of 3.33 ms (i.e.,
of 3.33ms (i.e., transmission rate of 300 transmission rate of 300 packets/second). Sometimes, the
packets/second). Sometimes, the requirement of 50ms requirement of 50 ms recovery time is associated with the
recovery time is associated with the requirement for a requirement for a CC-V defect entry criteria period of 35 ms;
CC-V defect entry criteria period of 35 ms: in these in these cases a transmission period of 10 ms (i.e.,
cases a transmission period of 10ms (i.e., transmission transmission rate of 100 packets/second) can be used.
rate of 100 packets/second) can be used. Furthermore, Furthermore, when there is no need for so small CC-V defect
when there is no need for so small CC-V defect entry entry criteria periods, a larger transmission period can be
criteria periods, larger transmission period can be used. used.
It should be possible for the operator to configure these It should be possible for the operator to configure these
transmission rates for all applications, to satisfy specific transmission rates for all applications, to satisfy specific network
network requirements. requirements.
Note that the reception period is the same as the configured Note that the reception period is the same as the configured
transmission rate. transmission rate.
For management provisioned transport paths the above parameters For management-provisioned transport paths, the above parameters are
are statically configured; for dynamically signaled transport statically configured; for dynamically signaled transport paths, the
paths the configuration information are distributed via the configuration information is distributed via the control plane.
control plane.
The operator should be able to enable/disable some of the The operator should be able to enable/disable some of the consequent
consequent actions. Which consequent action can be actions. Which consequent actions can be enabled/disabled is
enabled/disabled are described in section 5.1.2. described in Section 5.1.2.
5.2. Remote Defect Indication 5.2. Remote Defect Indication
The Remote Defect Indication (RDI) function, as required in The Remote Defect Indication (RDI) function, as required in Section
section 2.2.9 of RFC 5860 [11], is an indicator that is 2.2.9 of RFC 5860 [11], is an indicator that is transmitted by a sink
transmitted by a sink MEP to communicate to its source MEP that MEP to communicate to its source MEP that a signal fail condition
a signal fail condition exists. In case of co-routed and exists. In case of co-routed and associated bidirectional transport
associated bidirectional transport paths, RDI is associated with paths, RDI is associated with proactive CC-V, and the RDI indicator
proactive CC-V and the RDI indicator can be piggy-backed onto can be piggy-backed onto the CC-V packet. In case of unidirectional
the CC-V packet. In case of unidirectional transport paths, the transport paths, the RDI indicator can be sent only using an out-of-
RDI indicator can be sent only using an out-of-band return path band return path if it exists and its usage is enabled by policy
if it exists and its usage is enabled by policy actions. actions.
When a MEP detects a signal fail condition (e.g. in case of a When a MEP detects a signal fail condition (e.g., in case of a
continuity or connectivity defect), it should begin transmitting continuity or connectivity defect), it should begin transmitting an
an RDI indicator to its peer MEP. When incorporated into CC-V, RDI indicator to its peer MEP. When incorporated into CC-V, the RDI
the RDI information will be included in all pro-active CC-V information will be included in all proactive CC-V packets that it
packets that it generates for the duration of the signal fail generates for the duration of the signal fail condition's existence.
condition's existence.
A MEP that receives packets from a peer MEP with the RDI A MEP that receives packets from a peer MEP with the RDI information
information should determine that its peer MEP has encountered a should determine that its peer MEP has encountered a defect condition
defect condition associated with a signal fail condition. associated with a signal fail condition.
MIPs as well as intermediate nodes not supporting MPLS-TP OAM MIPs as well as intermediate nodes not supporting MPLS-TP OAM are
are transparent to the RDI indicator and forward OAM packets transparent to the RDI indicator and forward OAM packets that include
that include the RDI indicator as regular data packets, i.e. the the RDI indicator as regular data packets, i.e., the MIP should not
MIP should not perform any actions nor examine the indicator. perform any actions nor examine the indicator.
When the signal fail condition clears, the MEP should stop When the signal fail condition clears, the MEP should stop
transmitting the RDI indicator to its peer MEP. When transmitting the RDI indicator to its peer MEP. When incorporated
incorporated into CC-V, the RDI indicator will be cleared from into CC-V, the RDI indicator will not be set for subsequent
subsequent transmission of pro-active CC-V packets. A MEP transmission of proactive CC-V packets. A MEP should clear the RDI
should clear the RDI defect upon reception of an RDI indicator defect upon reception of an RDI indicator cleared.
cleared.
5.2.1. Configuration considerations 5.2.1. Configuration Considerations
In order to support RDI indication, the indication may be In order to support RDI, the indication may be carried in a unique
carried in a unique OAM packet or may be embedded in a CC-V OAM packet or may be embedded in a CC-V packet. The in-band RDI
packet. The in-band RDI transmission rate and PHB of the OAM transmission rate and PHB of the OAM packets carrying RDIs should be
packets carrying RDI should be the same as that configured for the same as that configured for CC-V to allow both far-end and near-
CC-V to allow both far-end and near-end defect conditions being end defect conditions being resolved in a timeframe that has the same
resolved in a timeframe that has the same order of magnitude. order of magnitude. This timeframe is application specific as
This timeframe is application specific as described in section described in Section 5.1.3. Methods of the out-of-band return paths
5.1.3. Methods of the out-of-band return paths will dictate how will dictate how out-of-band RDIs are transmitted.
out-of-band RDI indications are transmitted.
5.3. Alarm Reporting 5.3. Alarm Reporting
The Alarm Reporting function, as required in section 2.2.8 of The Alarm Reporting function, as required in Section 2.2.8 of RFC
RFC 5860 [11], relies upon an Alarm Indication Signal (AIS) 5860 [11], relies upon an Alarm Indication Signal (AIS) packet to
packet to suppress alarms following detection of defect suppress alarms following detection of defect conditions at the
conditions at the server (sub-)layer. server (sub-)layer.
When a server MEP asserts a signal fail condition, it notifies When a server MEP asserts a signal fail condition, it notifies that
that to the co-located MPLS-TP client/server adaptation function to the co-located MPLS-TP client/server adaptation function that then
which then generates OAM packets with AIS information in the generates OAM packets with AIS information in the downstream
downstream direction to allow the suppression of secondary direction to allow the suppression of secondary alarms at the MPLS-TP
alarms at the MPLS-TP MEP in the client (sub-)layer. MEP in the client (sub-)layer.
The generation of packets with AIS information starts The generation of packets with AIS information starts immediately
immediately when the server MEP asserts a signal fail condition. when the server MEP asserts a signal fail condition. These periodic
These periodic OAM packets, with AIS information, continue to be OAM packets, with AIS information, continue to be transmitted until
transmitted until the signal fail condition is cleared. the signal fail condition is cleared.
It is assumed that to avoid spurious alarm generation a MEP It is assumed that to avoid spurious alarm generation a MEP detecting
detecting a loss of continuity defect (see section 5.1.1.1) will a loss of continuity defect (see Section 5.1.1.1) will wait for a
wait for a hold off interval prior to asserting an alarm to the hold-off interval prior to asserting an alarm to the management
management system. Therefore, upon receiving an OAM packet with system. Therefore, upon receiving an OAM packet with AIS
AIS information an MPLS-TP MEP enters an AIS defect condition information, an MPLS-TP MEP enters an AIS defect condition and
and suppresses reporting of alarms to the NMS on the loss of suppresses reporting of alarms to the NMS on the loss of continuity
continuity with its peer MEP but does not block traffic received with its peer MEP, but it does not block traffic received from the
from the transport path. A MEP resumes loss of continuity alarm transport path. A MEP resumes loss of continuity alarm generation
generation upon detecting loss of continuity defect conditions upon detecting loss of continuity defect conditions in the absence of
in the absence of AIS condition. AIS condition.
MIPs, as well as intermediate nodes, do not process AIS MIPs, as well as intermediate nodes, do not process AIS information
information and forward these AIS OAM packets as regular data and forward these AIS OAM packets as regular data packets.
packets.
For example, let's consider a fiber cut between LSR 1 and LSR 2 For example, let's consider a fiber cut between T-PE 1 and LSR 2 in
in the reference network of Figure 5. Assuming that all of the the reference network of Figure 5. Assuming that all of the MEGs
MEGs described in Figure 5 have pro-active CC-V enabled, a LOC described in Figure 5 have proactive CC-V enabled, a LOC defect is
defect is detected by the MEPs of Sec12 SMEG LSP13 LMEG, PW1 detected by the MEPs of Sec12 SMEG, LSP13 LMEG, PW1 PSMEG, and PW1Z
PSMEG and PW1Z PMEG, however in a transport network only the PMEG; however, in a transport network, only the alarm associated to
alarm associated to the fiber cut needs to be reported to an NMS the fiber cut needs to be reported to an NMS, while all secondary
while all secondary alarms should be suppressed (i.e. not alarms should be suppressed (i.e., not reported to the NMS or
reported to the NMS or reported as secondary alarms). reported as secondary alarms).
If the fiber cut is detected by the MEP in the physical layer If the fiber cut is detected by the MEP in the physical layer (in LSR
(in LSR2), LSR2 can generate the proper alarm in the physical 2), LSR 2 can generate the proper alarm in the physical layer and
layer and suppress the secondary alarm associated with the LOC suppress the secondary alarm associated with the LOC defect detected
defect detected on Sec12 SMEG. As both MEPs reside within the on Sec12 SMEG. As both MEPs reside within the same node, this
same node, this process does not involve any external protocol process does not involve any external protocol exchange. Otherwise,
exchange. Otherwise, if the physical layer has not enough OAM if the physical layer does not have enough OAM capabilities to detect
capabilities to detect the fiber cut, the MEP of Sec12 SMEG in the fiber cut, the MEP of Sec12 SMEG in LSR 2 will report a LOC
LSR2 will report a LOC alarm. alarm.
In both cases, the MEP of Sec12 SMEG in LSR 2 notifies the In both cases, the MEP of Sec12 SMEG in LSR 2 notifies the adaptation
adaptation function for LSP13 LMEG that then generates AIS function for LSP13 LMEG that then generates AIS packets on the LSP13
packets on the LSP13 LMEG in order to allow its MEP in LSR3 to LMEG in order to allow its MEP in S-PE 3 to suppress the LOC alarm.
suppress the LOC alarm. LSR3 can also suppress the secondary S-PE 3 can also suppress the secondary alarm on PW13 PSMEG because
alarm on PW13 PSMEG because the MEP of PW13 PSMEG resides within the MEP of PW13 PSMEG resides within the same node as the MEP of
the same node as the MEP of LSP13 LMEG. The MEP of PW13 PSMEG in LSP13 LMEG. The MEP of PW13 PSMEG in S-PE 3 also notifies the
LSR3 also notifies the adaptation function for PW1Z PMEG that adaptation function for PW1Z PMEG that then generates AIS packets on
then generates AIS packets on PW1Z PMEG in order to allow its PW1Z PMEG in order to allow its MEP in T-PE Z to suppress the LOC
MEP in LSRZ to suppress the LOC alarm. alarm.
The generation of AIS packets for each MEG in the MPLS-TP client The generation of AIS packets for each MEG in the MPLS-TP client
(sub-)layer is configurable (i.e. the operator can (sub-)layer is configurable (i.e., the operator can enable/disable
enable/disable the AIS generation). the AIS generation).
AIS condition is cleared if no AIS packet has been received in The AIS condition is cleared if no AIS packet has been received in
3.5 times the AIS transmission period. 3.5 times the AIS transmission period.
The AIS transmission period is traditionally one per second but The AIS transmission period is traditionally one per second, but an
an option to configure longer periods would be also desirable. option to configure longer periods would be also desirable. As a
As a consequence, OAM packets need to self-identify the consequence, OAM packets need to self-identify the transmission
transmission period such that proper exit criteria can be period such that proper exit criteria can be established.
established.
AIS packets are transmitted with the "minimum loss probability AIS packets are transmitted with the "minimum loss probability PHB"
PHB" within a single network operator. For E-LSPs, this PHB is within a single network operator. For E-LSPs, this PHB is
configurable on network operator's basis, while for L-LSPs, this configurable on network operator's basis, while for L-LSPs, this is
is determined as per RFC 3270 [23]. determined as per RFC 3270 [23].
5.4. Lock Reporting 5.4. Lock Reporting
The Lock Reporting function, as required in section 2.2.7 of RFC The Lock Reporting function, as required in Section 2.2.7 of RFC 5860
5860 [11], relies upon a Locked Report (LKR) packet used to [11], relies upon a Lock Report (LKR) packet used to suppress alarms
suppress alarms following administrative locking action in the following administrative locking action in the server (sub-)layer.
server (sub-)layer.
When a server MEP is locked, the MPLS-TP client (sub-)layer When a server MEP is locked, the MPLS-TP client (sub-)layer
adaptation function generates packets with LKR information to adaptation function generates packets with LKR information to allow
allow the suppression of secondary alarms at the MEPs in the the suppression of secondary alarms at the MEPs in the client
client (sub-)layer. Again it is assumed that there is a hold off (sub-)layer. Again, it is assumed that there is a hold-off for any
for any loss of continuity alarms in the client layer MEPs loss of continuity alarms in the client-layer MEPs downstream of the
downstream of the node originating the locked report. In case of node originating the Lock Report. In case of client (sub-)layer co-
client (sub-)layer co-routed bidirectional transport paths, the routed bidirectional transport paths, the LKR information is sent on
LKR information is sent on both directions. In case of client both directions. In case of client (sub-)layer unidirectional
(sub-)layer unidirectional transport paths, the LKR information transport paths, the LKR information is sent only in the downstream
is sent only in the downstream direction. As a consequence, in direction. As a consequence, in case of client (sub-)layer point-to-
case of client (sub-)layer point-to-multipoint transport paths, multipoint transport paths, the LKR information is sent only to the
the LKR information is sent only to the MEPs that are downstream MEPs that are downstream from the server (sub-)layer that has been
to the server (sub-)layer that has been administratively locked. administratively locked. Client (sub-)layer associated bidirectional
Client (sub-)layer associated bidirectional transport paths transport paths behave like co-routed bidirectional transport paths
behave like co-routed bidirectional transport paths if the if the server (sub-)layer that has been administratively locked is
server (sub-)layer that has been administratively locked is used used by both directions; otherwise, they behave like unidirectional
by both directions; otherwise they behave like unidirectional
transport paths. transport paths.
The generation of packets with LKR information starts The generation of packets with LKR information starts immediately
immediately when the server MEP is locked. These periodic when the server MEP is locked. These periodic packets, with LKR
packets, with LKR information, continue to be transmitted until information, continue to be transmitted until the locked condition is
the locked condition is cleared. cleared.
Upon receiving a packet with LKR information an MPLS-TP MEP Upon receiving a packet with LKR information, an MPLS-TP MEP enters
enters an LKR defect condition and suppresses loss of continuity an LKR defect condition and suppresses the loss of continuity alarm
alarm associated with its peer MEP but does not block traffic associated with its peer MEP but does not block traffic received from
received from the transport path. A MEP resumes loss of the transport path. A MEP resumes loss of continuity alarm
continuity alarm generation upon detecting loss of continuity generation upon detecting loss of continuity defect conditions in the
defect conditions in the absence of LKR condition. absence of the LKR condition.
MIPs, as well as intermediate nodes, do not process the LKR MIPs, as well as intermediate nodes, do not process the LKR
information and forward these LKR OAM packets as regular data information; they forward these LKR OAM packets as regular data
packets. packets.
For example, let's consider the case where the MPLS-TP Section For example, let's consider the case where the MPLS-TP Section
between LSR 1 and LSR 2 in the reference network of Figure 5 is between T-PE 1 and LSR 2 in the reference network of Figure 5 is
administrative locked at LSR2 (in both directions). administratively locked at LSR 2 (in both directions).
Assuming that all the MEGs described in Figure 5 have pro-active Assuming that all the MEGs described in Figure 5 have proactive CC-V
CC-V enabled, a LOC defect is detected by the MEPs of LSP13 enabled, a LOC defect is detected by the MEPs of LSP13 LMEG, PW1
LMEG, PW1 PSMEG and PW1Z PMEG, however in a transport network PSMEG, and PW1Z PMEG; however, in a transport network all these
all these secondary alarms should be suppressed (i.e. not secondary alarms should be suppressed (i.e., not reported to the NMS
reported to the NMS or reported as secondary alarms). or reported as secondary alarms).
The MEP of Sec12 SMEG in LSR 2 notifies the adaptation function The MEP of Sec12 SMEG in LSR 2 notifies the adaptation function for
for LSP13 LMEG that then generates LKR packets on the LSP13 LMEG LSP13 LMEG that then generates LKR packets on the LSP13 LMEG in order
in order to allow its MEPs in LSR1 and LSR3 to suppress the LOC to allow its MEPs in T-PE 1 and S-PE 3 to suppress the LOC alarm.
alarm. LSR3 can also suppress the secondary alarm on PW13 PSMEG S-PE 3 can also suppress the secondary alarm on PW13 PSMEG because
because the MEP of PW13 PSMEG resides within the same node as the MEP of PW13 PSMEG resides within the same node as the MEP of
the MEP of LSP13 LMEG. The MEP of PW13 PSMEG in LSR3 also LSP13 LMEG. The MEP of PW13 PSMEG in S-PE 3 also notifies the
notifies the adaptation function for PW1Z PMEG that then adaptation function for PW1Z PMEG that then generates AIS packets on
generates AIS packets on PW1Z PMEG in order to allow its MEP in PW1Z PMEG in order to allow its MEP in T-PE Z to suppress the LOC
LSRZ to suppress the LOC alarm. alarm.
The generation of LKR packets for each MEG in the MPLS-TP client The generation of LKR packets for each MEG in the MPLS-TP client
(sub-)layer is configurable (i.e. the operator can (sub-)layer is configurable (i.e., the operator can enable/disable
enable/disable the LKR generation). the LKR generation).
Locked condition is cleared if no LKR packet has been received The locked condition is cleared if no LKR packet has been received
for 3.5 times the transmission period. for 3.5 times the transmission period.
The LKR transmission period is traditionally one per second but The LKR transmission period is traditionally one per second, but an
an option to configure longer periods would be also desirable. option to configure longer periods would be also desirable. As a
As a consequence, OAM packets need to self-identify the consequence, OAM packets need to self-identify the transmission
transmission period such that proper exit criteria can be period such that proper exit criteria can be established.
established.
LKR packets are transmitted with the "minimum loss probability LKR packets are transmitted with the "minimum loss probability PHB"
PHB" within a single network operator. For E-LSPs, this PHB is within a single network operator. For E-LSPs, this PHB is
configurable on network operator's basis, while for L-LSPs, this configurable on network operator's basis, while for L-LSPs, this is
is determined as per RFC 3270 [23]. determined as per RFC 3270 [23].
5.5. Packet Loss Measurement 5.5. Packet Loss Measurement
Packet Loss Measurement (LM) is one of the capabilities Packet Loss Measurement (LM) is one of the capabilities supported by
supported by the MPLS-TP Performance Monitoring (PM) function in the MPLS-TP Performance Monitoring (PM) function in order to
order to facilitate reporting of QoS information for a transport facilitate reporting of Quality of Service (QoS) information for a
path as required in section 2.2.11 of RFC 5860 [11]. LM is used transport path as required in Section 2.2.11 of RFC 5860 [11]. LM is
to exchange counter values for the number of ingress and egress used to exchange counter values for the number of ingress and egress
packets transmitted and received by the transport path monitored packets transmitted and received by the transport path monitored by a
by a pair of MEPs. pair of MEPs.
Proactive LM is performed by periodically sending LM OAM packets Proactive LM is performed by periodically sending LM OAM packets from
from a MEP to a peer MEP and by receiving LM OAM packets from a MEP to a peer MEP and by receiving LM OAM packets from the peer MEP
the peer MEP (if a co-routed or associated bidirectional (if a co-routed or associated bidirectional transport path) during
transport path) during the life time of the transport path. Each the lifetime of the transport path. Each MEP performs measurements
MEP performs measurements of its transmitted and received user of its transmitted and received user data packets. These
data packets. These measurements are then correlated in real measurements are then correlated in real time with the peer MEP in
time with the peer MEP in the ME to derive the impact of packet the ME to derive the impact of packet loss on a number of performance
loss on a number of performance metrics for the ME in the MEG. metrics for the ME in the MEG. The LM transactions are issued such
The LM transactions are issued such that the OAM packets will that the OAM packets will experience the same PHB scheduling class as
experience the same PHB scheduling class as the measured traffic the measured traffic while transiting between the MEPs in the ME.
while transiting between the MEPs in the ME.
For a MEP, near-end packet loss refers to packet loss associated For a MEP, near-end packet loss refers to packet loss associated with
with incoming data packets (from the far-end MEP) while far-end incoming data packets (from the far-end MEP), while far-end packet
packet loss refers to packet loss associated with egress data loss refers to packet loss associated with egress data packets
packets (towards the far-end MEP). (towards the far-end MEP).
Pro-active LM can be operated in two ways: Proactive LM can be operated in two ways:
o One-way: a MEP sends LM OAM packet to its peer MEP containing o One-way: a MEP sends an LM OAM packet to its peer MEP containing
all the required information to facilitate near-end packet all the required information to facilitate near-end packet loss
loss measurements at the peer MEP. measurements at the peer MEP.
o Two-way: a MEP sends LM OAM packet with a LM request to its o Two-way: a MEP sends an LM OAM packet with an LM request to its
peer MEP, which replies with a LM OAM packet as a LM peer MEP, which replies with an LM OAM packet as an LM response.
response. The request/response LM OAM packets containing all The request/response LM OAM packets contain all the required
the required information to facilitate both near-end and information to facilitate both near-end and far-end packet loss
far-end packet loss measurements from the viewpoint of the measurements from the viewpoint of the originating MEP.
originating MEP.
One-way LM is applicable to both unidirectional and One-way LM is applicable to both unidirectional and bidirectional
bidirectional (co-routed or associated) transport paths while (co-routed or associated) transport paths, while two-way LM is
two-way LM is applicable only to bidirectional (co-routed or applicable only to bidirectional (co-routed or associated) transport
associated) transport paths. paths.
MIPs, as well as intermediate nodes, do not process the LM MIPs, as well as intermediate nodes, do not process the LM
information and forward these pro-active LM OAM packets as information; they forward these proactive LM OAM packets as regular
regular data packets. data packets.
5.5.1. Configuration considerations 5.5.1. Configuration Considerations
In order to support proactive LM, the transmission rate and, for In order to support proactive LM, the transmission rate and, for
E-LSPs, the PHB class associated with the LM OAM packets E-LSPs, the PHB class (associated with the LM OAM packets originating
originating from a MEP need be configured as part of the LM from a MEP) need to be configured as part of the LM provisioning. LM
provisioning. LM OAM packets should be transmitted with the PHB OAM packets should be transmitted with the PHB that yields the lowest
that yields the lowest drop precedence within the measured PHB drop precedence within the measured PHB Scheduling Class (see RFC
Scheduling Class (see RFC 3260 [17]), in order to maximize 3260 [17]), in order to maximize reliability of measurement within
reliability of measurement within the traffic class. the traffic class.
If that PHB class is not an ordered aggregate where the ordering If that PHB class is not an ordered aggregate where the ordering
constraint is all packets with the PHB class being delivered in constraint is all packets with the PHB class being delivered in
order, LM can produce inconsistent results. order, LM can produce inconsistent results.
Performance monitoring (e.g., LM) is only relevant when the Performance monitoring (e.g., LM) is only relevant when the transport
transport path is defect free. CC-V contributes to the accuracy path is defect free. CC-V contributes to the accuracy of PM
of PM statistics by permitting the defect free periods to be statistics by permitting the defect-free periods to be properly
properly distinguished. Therefore support of pro-active LM has distinguished. Therefore, support of proactive LM has implications
implications on the CC-V transmission period (see section on the CC-V transmission period (see Section 5.1.3).
5.1.3).
5.5.2. Sampling skew 5.5.2. Sampling Skew
If an implementation makes use of a hardware forwarding path If an implementation makes use of a hardware forwarding path that
which operates in parallel with an OAM processing path, whether operates in parallel with an OAM processing path, whether hardware or
hardware or software based, the packet and byte counts may be software based, the packet and byte counts may be skewed if one or
skewed if one or more packets can be processed before the OAM more packets can be processed before the OAM processing samples
processing samples counters. If OAM is implemented in software counters. If OAM is implemented in software, this error can be quite
this error can be quite large. large.
5.5.3. Multilink issues 5.5.3. Multilink Issues
If multilink is used at the LSP ingress or egress, there may be If multilink is used at the ingress or egress of a transport path,
no single packet processing engine where to inject or extract a there may not be a single packet-processing engine where an LM packet
LM packet as an atomic operation to which accurate packet and can be injected or extracted as an atomic operation while having
byte counts can be associated with the packet. accurate packet and byte counts associated with the packet.
In the case where multilink is encountered in the LSP path, the In the case where multilink is encountered along the route of the
reordering of packets within the LSP can cause inaccurate LM transport path, the reordering of packets within the transport path
results. can cause inaccurate LM results.
5.6. Packet Delay Measurement 5.6. Packet Delay Measurement
Packet Delay Measurement (DM) is one of the capabilities Packet Delay Measurement (DM) is one of the capabilities supported by
supported by the MPLS-TP PM function in order to facilitate the MPLS-TP PM function in order to facilitate reporting of QoS
reporting of QoS information for a transport path as required in information for a transport path as required in Section 2.2.12 of RFC
section 2.2.12 of RFC 5860 [11]. Specifically, pro-active DM is 5860 [11]. Specifically, proactive DM is used to measure the long-
used to measure the long-term packet delay and packet delay term packet delay and packet delay variation in the transport path
variation in the transport path monitored by a pair of MEPs. monitored by a pair of MEPs.
Proactive DM is performed by sending periodic DM OAM packets Proactive DM is performed by sending periodic DM OAM packets from a
from a MEP to a peer MEP and by receiving DM OAM packets from MEP to a peer MEP and by receiving DM OAM packets from the peer MEP
the peer MEP (if a co-routed or associated bidirectional (if a co-routed or associated bidirectional transport path) during a
transport path) during a configurable time interval. configurable time interval.
Pro-active DM can be operated in two ways: Proactive DM can be operated in two ways:
o One-way: a MEP sends DM OAM packet to its peer MEP containing o One-way: a MEP sends a DM OAM packet to its peer MEP containing
all the required information to facilitate one-way packet all the required information to facilitate one-way packet delay
delay and/or one-way packet delay variation measurements at and/or one-way packet delay variation measurements at the peer
the peer MEP. Note that this requires precise time MEP. Note that this requires precise time synchronization at
synchronisation at either MEP by means outside the scope of either MEP by means outside the scope of this framework.
this framework.
o Two-way: a MEP sends DM OAM packet with a DM request to its o Two-way: a MEP sends a DM OAM packet with a DM request to its peer
peer MEP, which replies with a DM OAM packet as a DM MEP, which replies with a DM OAM packet as a DM response. The
response. The request/response DM OAM packets containing all request/response DM OAM packets contain all the required
the required information to facilitate two-way packet delay information to facilitate two-way packet delay and/or two-way
and/or two-way packet delay variation measurements from the packet delay variation measurements from the viewpoint of the
viewpoint of the originating MEP. originating MEP.
One-way DM is applicable to both unidirectional and One-way DM is applicable to both unidirectional and bidirectional
bidirectional (co-routed or associated) transport paths while (co-routed or associated) transport paths, while two-way DM is
two-way DM is applicable only to bidirectional (co-routed or applicable only to bidirectional (co-routed or associated) transport
associated) transport paths. paths.
MIPs, as well as intermediate nodes, do not process the DM MIPs, as well as intermediate nodes, do not process the DM
information and forward these pro-active DM OAM packets as information; they forward these proactive DM OAM packets as regular
regular data packets. data packets.
5.6.1. Configuration considerations 5.6.1. Configuration Considerations
In order to support pro-active DM, the transmission rate and, In order to support proactive DM, the transmission rate and, for
for E-LSPs, the PHB associated with the DM OAM packets E-LSPs, the PHB (associated with the DM OAM packets originating from
originating from a MEP need be configured as part of the DM a MEP) need to be configured as part of the DM provisioning. DM OAM
provisioning. DM OAM packets should be transmitted with the PHB packets should be transmitted with the PHB that yields the lowest
that yields the lowest drop precedence within the measured PHB drop precedence within the measured PHB Scheduling Class (see RFC
Scheduling Class (see RFC 3260 [17]). 3260 [17]).
Performance monitoring (e.g., DM) is only relevant when the Performance monitoring (e.g., DM) is only relevant when the transport
transport path is defect free. CC-V contributes to the accuracy path is defect free. CC-V contributes to the accuracy of PM
of PM statistics by permitting the defect free periods to be statistics by permitting the defect-free periods to be properly
properly distinguished. Therefore support of pro-active DM has distinguished. Therefore, support of proactive DM has implications
implications on the CC-V transmission period (see section on the CC-V transmission period (see Section 5.1.3).
5.1.3).
5.7. Client Failure Indication 5.7. Client Failure Indication
The Client Failure Indication (CFI) function, as required in The Client Failure Indication (CFI) function, as required in Section
section 2.2.10 of RFC 5860 [11], is used to help process client 2.2.10 of RFC 5860 [11], is used to help process client defects and
defects and propagate a client signal defect condition from the propagate a client signal defect condition from the process
process associated with the local attachment circuit where the associated with the local attachment circuit where the defect was
defect was detected (typically the source adaptation function detected (typically the source adaptation function for the local
for the local client interface) to the process associated with client interface). It is propagated to the process associated with
the far-end attachment circuit (typically the source adaptation the far-end attachment circuit (typically the source adaptation
function for the far-end client interface) for the same function for the far-end client interface) for the same transmission
transmission path in case the client of the transport path does path, in case the client of the transport path does not support a
not support a native defect/alarm indication mechanism, e.g. native defect/alarm indication mechanism, e.g., AIS.
AIS.
A source MEP starts transmitting a CFI indication to its peer A source MEP starts transmitting a CFI to its peer MEP when it
MEP when it receives a local client signal defect notification receives a local client signal defect notification via its local
via its local CSF function. Mechanisms to detect local client client signal fail indication. Mechanisms to detect local client
signal fail defects are technology specific. Similarly signal fail defects are technology specific. Similarly, mechanisms
mechanisms to determine when to cease originating client signal to determine when to cease originating client signal fail indication
fail indication are also technology specific. are also technology specific.
A sink MEP that has received a CFI indication report this A sink MEP that has received a CFI reports this condition to its
condition to its associated client process via its local CFI associated client process via its local CFI function. Consequent
function. Consequent actions toward the client attachment actions toward the client attachment circuit are technology specific.
circuit are technology specific.
Either there needs to be a 1:1 correspondence between the client There needs to be a 1:1 correspondence between the client and the
and the MEG, or when multiple clients are multiplexed over a MEG; otherwise, when multiple clients are multiplexed over a
transport path, the CFI packet requires additional information transport path, the CFI packet requires additional information to
to permit the client instance to be identified. permit the client instance to be identified.
MIPs, as well as intermediate nodes, do not process the CFI MIPs, as well as intermediate nodes, do not process the CFI
information and forward these pro-active CFI OAM packets as information; they forward these proactive CFI OAM packets as regular
regular data packets. data packets.
5.7.1. Configuration considerations 5.7.1. Configuration Considerations
In order to support CFI indication, the CFI transmission rate In order to support CFI indication, the CFI transmission rate and,
and, for E-LSPs, the PHB of the CFI OAM packets should be for E-LSPs, the PHB of the CFI OAM packets should be configured as
configured as part of the CFI configuration. part of the CFI configuration.
6. OAM Functions for on-demand monitoring 6. OAM Functions for On-Demand Monitoring
In contrast to proactive monitoring, on-demand monitoring is In contrast to proactive monitoring, on-demand monitoring is
initiated manually and for a limited amount of time, usually for initiated manually and for a limited amount of time, usually for
operations such as diagnostics to investigate a defect operations such as diagnostics to investigate a defect condition.
condition.
On-demand monitoring covers a combination of "in-service" and On-demand monitoring covers a combination of "in-service" and "out-
"out-of-service" monitoring functions. The control and of-service" monitoring functions. The control and measurement
measurement implications are: implications are:
1. A MEG can be directed to perform an "on-demand" functions at 1. A MEG can be directed to perform an "on-demand" functions at
arbitrary times in the lifetime of a transport path. arbitrary times in the lifetime of a transport path.
2. "out-of-service" monitoring functions may require a-priori 2. "Out-of-service" monitoring functions may require a priori
configuration of both MEPs and intermediate nodes in the MEG configuration of both MEPs and intermediate nodes in the MEG
(e.g., data plane loopback) and the issuance of notifications (e.g., data-plane loopback) and the issuance of notifications into
into client layers of the transport path being removed from client layers of the transport path being removed from service
service (e.g., lock-reporting) (e.g., lock reporting)
3. The measurements resulting from on-demand monitoring are 3. The measurements resulting from "on-demand" monitoring are
typically harvested in real time, as these are frequently typically harvested in real time, as they are frequently initiated
initiated manually. These do not necessarily require manually. These do not necessarily require different harvesting
different harvesting mechanisms that for harvesting proactive mechanisms than for harvesting proactive monitoring telemetry.
monitoring telemetry.
The functions that are exclusively out-of-service are those The functions that are exclusively out-of-service are those described
described in section 6.3. The remainder are applicable to both in Section 6.3. The remainder are applicable to both in-service and
in-service and out-of-service transport paths. out-of-service transport paths.
6.1. Connectivity Verification 6.1. Connectivity Verification
On demand connectivity verification function, as required in The on-demand connectivity verification function, as required in
section 2.2.3 of RFC 5860 [11], is a transaction that flows from Section 2.2.3 of RFC 5860 [11], is a transaction that flows from the
the originating MEP to a target MIP or MEP to verify the originating MEP to a target MIP or MEP to verify the connectivity
connectivity between these points. between these points.
Use of on-demand CV is dependent on the existence of either a Use of on-demand CV is dependent on the existence of a bidirectional
bi-directional ME, or an associated return ME, or the ME or an associated return ME, or the availability of an out-of-band
availability of an out-of-band return path because it requires return path, because it requires the ability for target MIPs and MEPs
the ability for target MIPs and MEPs to direct responses to the to direct responses to the originating MEPs.
originating MEPs.
One possible use of on-demand CV would be to perform fault One possible use of on-demand CV would be to perform fault management
management without using proactive CC-V, in order to preserve without using proactive CC-V, in order to preserve network resources,
network resources, e.g. bandwidth, processing time at switches. e.g., bandwidth, processing time at switches. In this case, network
In this case, network management periodically invokes on-demand management periodically invokes on-demand CV.
CV.
An additional use of on-demand CV would be to detect and locate An additional use of on-demand CV would be to detect and locate a
a problem of connectivity when a problem is suspected or known problem of connectivity when a problem is suspected or known to be
based on other tools. In this case the functionality will be based on other tools. In this case, the functionality will be
triggered by the network management in response to a status triggered by the network management in response to a status signal or
signal or alarm indication. alarm indication.
On-demand CV is based upon generation of on-demand CV packets On-demand CV is based upon generation of on-demand CV packets that
that should uniquely identify the MEG that is being checked. should uniquely identify the MEG that is being checked. The on-
The on-demand functionality may be used to check either an demand functionality may be used to check either an entire MEG (end-
entire MEG (end-to-end) or between the originating MEP and a to-end) or between the originating MEP and a specific MIP. This
specific MIP. This functionality may not be available for functionality may not be available for associated bidirectional
associated bidirectional transport paths or unidirectional transport paths or unidirectional paths, as the MIP may not have a
paths, as the MIP may not have a return path to the originating return path to the originating MEP for the on-demand CV transaction.
MEP for the on-demand CV transaction.
When on-demand CV is invoked, the originating MEP issues a When on-demand CV is invoked, the originating MEP issues a sequence
sequence of on-demand CV packets that uniquely identifies the of on-demand CV packets that uniquely identifies the MEG being
MEG being verified. The number of packets and their verified. The number of packets and their transmission rate should
transmission rate should be pre-configured at the originating be pre-configured at the originating MEP to take into account normal
MEP, to take into account normal packet-loss conditions. The packet-loss conditions. The source MEP should use the mechanisms
source MEP should use the mechanisms defined in sections 3.3 and defined in Sections 3.3 and 3.4 when sending an on-demand CV packet
3.4 when sending an on-demand CV packet to a target MEP or to a target MEP or target MIP, respectively. The target MEP/MIP
target MIP respectively. The target MEP/MIP shall return a reply shall return a reply on-demand CV packet for each packet received.
on-demand CV packet for each packet received. If the expected If the expected number of on-demand CV reply packets is not received
number of on-demand CV reply packets is not received at at the originating MEP, this is an indication that a connectivity
originating MEP, this is an indication that a connectivity
problem may exist. problem may exist.
On-demand CV should have the ability to carry padding such that On-demand CV should have the ability to carry padding such that a
a variety of MTU sizes can be originated to verify the MTU variety of MTU sizes can be originated to verify the MTU transport
transport capability of the transport path. capability of the transport path.
MIPs that are not targeted by on-demand CV packets, as well as MIPs that are not targeted by on-demand CV packets, as well as
intermediate nodes, do not process the CV information and intermediate nodes, do not process the CV information; they forward
forward these on-demand CV OAM packets as regular data packets. these on-demand CV OAM packets as regular data packets.
6.1.1. Configuration considerations 6.1.1. Configuration Considerations
For on-demand CV the originating MEP should support the For on-demand CV, the originating MEP should support the
configuration of the number of packets to be configuration of the number of packets to be transmitted/received in
transmitted/received in each sequence of transmissions and their each sequence of transmissions and their packet size.
packet size.
In addition, when the CV packet is used to check connectivity In addition, when the CV packet is used to check connectivity toward
toward a target MIP, the number of hops to reach the target MIP a target MIP, the number of hops to reach the target MIP should be
should be configured. configured.
For E-LSPs, the PHB of the on-demand CV packets should be For E-LSPs, the PHB of the on-demand CV packets should be configured
configured as well. This permits the verification of correct as well. This permits the verification of correct operation of QoS
operation of QoS queuing as well as connectivity. queuing as well as connectivity.
6.2. Packet Loss Measurement 6.2. Packet Loss Measurement
On-demand Packet Loss Measurement (LM) is one of the On-demand Packet Loss Measurement (LM) is one of the capabilities
capabilities supported by the MPLS-TP Performance Monitoring supported by the MPLS-TP Performance Monitoring function in order to
function in order to facilitate the diagnosis of QoS facilitate the diagnosis of QoS performance for a transport path, as
performances for a transport path, as required in section 2.2.11 required in Section 2.2.11 of RFC 5860 [11].
of RFC 5860 [11].
On-demand LM is very similar to pro-active LM described in On-demand LM is very similar to proactive LM described in Section
section 5.5. This section focuses on the differences between on- 5.5. This section focuses on the differences between on-demand and
demand and pro-active LM. proactive LM.
On-demand LM is performed by periodically sending LM OAM packets On-demand LM is performed by periodically sending LM OAM packets from
from a MEP to a peer MEP and by receiving LM OAM packets from a MEP to a peer MEP and by receiving LM OAM packets from the peer MEP
the peer MEP (if a co-routed or associated bidirectional (if a co-routed or associated bidirectional transport path) during a
transport path) during a pre-defined monitoring period. Each MEP pre-defined monitoring period. Each MEP performs measurements of its
performs measurements of its transmitted and received user data transmitted and received user data packets. These measurements are
packets. These measurements are then correlated to evaluate the then correlated to evaluate the packet-loss performance metrics of
packet loss performance metrics of the transport path. the transport path.
Use of packet loss measurement in an out-of-service transport Use of packet loss measurement in an out-of-service transport path
path requires a traffic source such as a test device that can requires a traffic source such as a test device that can inject
inject synthetic traffic. synthetic traffic.
6.2.1. Configuration considerations 6.2.1. Configuration Considerations
In order to support on-demand LM, the beginning and duration of In order to support on-demand LM, the beginning and duration of the
the LM procedures, the transmission rate and, for E-LSPs, the LM procedures, the transmission rate, and, for E-LSPs, the PHB class
PHB class associated with the LM OAM packets originating from a (associated with the LM OAM packets originating from a MEP) must be
MEP must be configured as part of the on-demand LM provisioning. configured as part of the on-demand LM provisioning. LM OAM packets
LM OAM packets should be transmitted with the PHB that yields should be transmitted with the PHB that yields the lowest drop
the lowest drop precedence as described in section 5.5.1. precedence as described in Section 5.5.1.
6.2.2. Sampling skew 6.2.2. Sampling Skew
The same considerations described in section 5.5.2 for the The same considerations described in Section 5.5.2 for the proactive
pro-active LM are also applicable to on-demand LM LM are also applicable to on-demand LM implementations.
implementations.
6.2.3. Multilink issues 6.2.3. Multilink Issues
Multi-link Issues are as described in section 5.5.3. Multilink issues are as described in Section 5.5.3.
6.3. Diagnostic Tests 6.3. Diagnostic Tests
Diagnostic tests are tests performed on a MEG that has been taken Diagnostic tests are tests performed on a MEG that has been taken out
out-of-service. of service.
6.3.1. Throughput Estimation 6.3.1. Throughput Estimation
Throughput estimation is an on-demand out-of-service function, Throughput estimation is an on-demand out-of-service function, as
as required in section 2.2.5 of RFC 5860 [11], that allows required in Section 2.2.5 of RFC 5860 [11], that allows verifying the
verifying the bandwidth/throughput of an MPLS-TP transport path bandwidth/throughput of an MPLS-TP transport path (LSP or PW) before
(LSP or PW) before it is put in-service. it is put in service.
Throughput estimation is performed between MEPs and between MEP Throughput estimation is performed between MEPs and between a MEP and
and MIP. It can be performed in one-way or two-way modes. a MIP. It can be performed in one-way or two-way modes.
According to RFC 2544 [12], this test is performed by sending According to RFC 2544 [12], this test is performed by sending OAM
OAM test packets at increasing rate (up to the theoretical test packets at increasing rates (up to the theoretical maximum),
maximum), computing the percentage of OAM test packets received computing the percentage of OAM test packets received, and reporting
and reporting the rate at which OAM test packets begin to drop. the rate at which OAM test packets begin to drop. In general, this
In general, this rate is dependent on the OAM test packet size. rate is dependent on the OAM test packet size.
When configured to perform such tests, a source MEP inserts OAM When configured to perform such tests, a source MEP inserts OAM test
test packets with a specified packet size and transmission packets with a specified packet size and transmission pattern at a
pattern at a rate to exercise the throughput. rate to exercise the throughput.
The throughput test can create congestion within the network The throughput test can create congestion within the network, thus
impacting other transport paths. However, the test traffic impacting other transport paths. However, the test traffic should
should comply with the traffic profile of the transport path comply with the traffic profile of the transport path under test, so
under test, so the impact of the test will not be worst than the the impact of the test will not be worse than the impact caused by
impact caused by the customers, whose traffic would be sent over the customers, whose traffic would be sent over that transport path,
that transport path, sending the traffic at the maximum rate sending the traffic at the maximum rate allowed by their traffic
allowed by their traffic profiles. Therefore, throughput tests profiles. Therefore, throughput tests are not applicable to
are not applicable to transport paths that do not have a defined transport paths that do not have a defined traffic profile, such as
traffic profile, such as for instance, LSPs in a context where LSPs in a context where statistical multiplexing is leveraged for
statistical multiplexing is leveraged for network capacity network capacity dimensioning.
dimensioning.
For a one-way test, the remote sink MEP receives the OAM test For a one-way test, the remote sink MEP receives the OAM test packets
packets and calculates the packet loss. For a two-way test, the and calculates the packet loss. For a two-way test, the remote MEP
remote MEP loopbacks the OAM test packets back to original MEP loops the OAM test packets back to the original MEP, and the local
and the local sink MEP calculates the packet loss. sink MEP calculates the packet loss.
It is worth noting that two-way throughput estimation is only It is worth noting that two-way throughput estimation is only
applicable to bidirectional (co-routed or associated) transport applicable to bidirectional (co-routed or associated) transport paths
paths and can only evaluate the minimum of available throughput and can only evaluate the minimum of available throughput of the two
of the two directions. In order to estimate the throughput of directions. In order to estimate the throughput of each direction
each direction uniquely, two one-way throughput estimation uniquely, two one-way throughput estimation sessions have to be set
sessions have to be setup. One-way throughput estimation up. One-way throughput estimation requires coordination between the
requires coordination between the transmitting and receiving transmitting and receiving test devices as described in Section 6 of
test devices as described in section 6 of RFC 2544 [12]. RFC 2544 [12].
It is also worth noting that if throughput estimation is It is also worth noting that if throughput estimation is performed on
performed on transport paths that transit oversubscribed links, transport paths that transit oversubscribed links, the test may not
the test may not produce comprehensive results if viewed in produce comprehensive results if viewed in isolation because the
isolation because the impact of the test on the surrounding impact of the test on the surrounding traffic needs to also be
traffic needs to also be considered. Moreover, the estimation considered. Moreover, the estimation will only reflect the bandwidth
will only reflect the bandwidth available at the moment when the available at the moment when the measure is made.
measure is made.
MIPs that are not target by on-demand test OAM packets, as well MIPs that are not targeted by on-demand test OAM packets, as well as
as intermediate nodes, do not process the throughput test intermediate nodes, do not process the throughput test information;
information and forward these on-demand test OAM packets as they forward these on-demand test OAM packets as regular data
regular data packets. packets.
6.3.1.1. Configuration considerations 6.3.1.1. Configuration Considerations
Throughput estimation is an out-of-service tool. The diagnosed Throughput estimation is an out-of-service tool. The diagnosed MEG
MEG should be put into a Lock status before the diagnostic test should be put into a locked state before the diagnostic test is
is started. started.
A MEG can be put into a Lock status either via an NMS action or A MEG can be put into a locked state either via an NMS action or
using the Lock Instruct OAM tool as defined in section 7. using the Lock Instruct OAM tool as defined in Section 7.
At the transmitting MEP, provisioning is required for a test At the transmitting MEP, provisioning is required for a test signal
signal generator, which is associated with the MEP. At a generator that is associated with the MEP. At a receiving MEP,
receiving MEP, provisioning is required for a test signal provisioning is required for a test signal detector that is
detector which is associated with the MEP. associated with the MEP.
In order to ensure accurate measurement, care needs to be taken In order to ensure accurate measurement, care needs to be taken to
to enable throughput estimation only if all the MEPs within the enable throughput estimation only if all the MEPs within the MEG can
MEG can process OAM test packets at the same rate as the payload process OAM test packets at the same rate as the payload data rates
data rates (see section 6.3.1.2). (see Section 6.3.1.2).
6.3.1.2. Limited OAM processing rate 6.3.1.2. Limited OAM Processing Rate
If an implementation is able to process payload at much higher If an implementation is able to process payload at much higher data
data rates than OAM test packets, then accurate measurement of rates than OAM test packets, then accurate measurement of throughput
throughput using OAM test packets is not achievable. Whether using OAM test packets is not achievable. Whether OAM packets can be
OAM packets can be processed at the same rate as payload is processed at the same rate as payload is implementation dependent.
implementation dependent.
6.3.1.3. Multilink considerations 6.3.1.3. Multilink Considerations
If multilink is used, then it may not be possible to perform If multilink is used, then it may not be possible to perform
throughput measurement, as the throughput test may not have a throughput measurement, as the throughput test may not have a
mechanism for utilizing more than one component link of the mechanism for utilizing more than one component link of the
aggregated link. aggregated link.
6.3.2. Data plane Loopback 6.3.2. Data-Plane Loopback
Data plane loopback is an out-of-service function, as required Data-plane loopback is an out-of-service function, as required in
in section 2.2.5 of RFC 5860 [11]. This function consists in Section 2.2.5 of RFC 5860 [11]. This function consists in placing a
placing a transport path, at either an intermediate or transport path, at either an intermediate or terminating node, into a
terminating node, into a data plane loopback state, such that data-plane loopback state, such that all traffic (including both
all traffic (including both payload and OAM) received on the payload and OAM) received on the looped back interface is sent on the
looped back interface is sent on the reverse direction of the reverse direction of the transport path. The traffic is looped back
transport path. The traffic is looped back unmodified other than unmodified except for normal per-hop processing such as TTL
normal per hop processing such as TTL decrement. decrement.
The data plane loopback function requires that the MEG is locked The data-plane loopback function requires that the MEG is locked such
such that user data traffic is prevented from entering/exiting that user data traffic is prevented from entering/exiting that MEG.
that MEG. Instead, test traffic is inserted at the ingress of Instead, test traffic is inserted at the ingress of the MEG. This
the MEG. This test traffic can be generated from an internal test traffic can be generated from an internal process residing
process residing within the ingress node or injected by external within the ingress node or injected by external test equipment
test equipment connected to the ingress node. connected to the ingress node.
It is also normal to disable proactive monitoring of the path as It is also normal to disable proactive monitoring of the path as the
the MEP located upstream with respect to the node set in the MEP located upstream with respect to the node set in the data-plane
data plane loopback mode will see all the OAM packets, loopback mode will see all the OAM packets originated by itself, and
originated by itself and this may interfere with other this may interfere with other measurements.
measurements.
The only way to send an OAM packet (e.g., to remove the data The only way to send an OAM packet (e.g., to remove the data-plane
plane loopback state) to the MIPs or MEPs hosted by a node set loopback state) to the MIPs or MEPs hosted by a node set in the data-
in the data plane loopback mode is via TTL expiry. It should plane loopback mode is via TTL expiry. It should also be noted that
also be noted that MIPs can be addressed with more than one TTL MIPs can be addressed with more than one TTL value on a co-routed
value on a co-routed bi-directional path set into data plane bidirectional path set into data-plane loopback.
loopback.
If the loopback function is to be performed at an intermediate If the loopback function is to be performed at an intermediate node,
node it is only applicable to co-routed bi-directional paths. If it is only applicable to co-routed bidirectional paths. If the
the loopback is to be performed end to end, it is applicable to loopback is to be performed end to end, it is applicable to both co-
both co-routed bi-directional or associated bi-directional routed bidirectional and associated bidirectional paths.
paths.
It should be noted that data plane loopback function itself is It should be noted that data-plane loopback function itself is
applied to data plane loopback points that can resides on applied to data-plane loopback points that can reside on different
different interfaces from MIPs/MEPs. Where a node implements interfaces from MIPs/MEPs. Where a node implements data-plane
data plane loopback capability and whether it implements it in loopback capability and whether it implements it in more than one
more than one point is implementation dependent. point is implementation dependent.
6.3.2.1. Configuration considerations 6.3.2.1. Configuration Considerations
Data plane loopback is an out-of-service tool. The MEG which Data-plane loopback is an out-of-service tool. The MEG that defines
defines a diagnosed transport path should be put into a locked a diagnosed transport path should be put into a locked state before
state before the diagnostic test is started. However, a means is the diagnostic test is started. However, a means is required to
required to permit the originated test traffic to be inserted at permit the originated test traffic to be inserted at the ingress MEP
ingress MEP when data plane loopback is performed. when data-plane loopback is performed.
A transport path, at either an intermediate or terminating node, A transport path, at either an intermediate or terminating node, can
can be put into data plane loopback state via an NMS action or be put into data-plane loopback state via an NMS action or using an
using an OAM tool for data plane loopback configuration. OAM tool for data-plane loopback configuration.
If the data plane loopback point is set somewhere at an If the data-plane loopback point is set somewhere at an intermediate
intermediate point of a co-routed bidirectional transport path, point of a co-routed bidirectional transport path, the side of the
the side of loop back function (one side or both side) needs to loopback function (east/west side or both sides) needs to be
be configured. configured.
6.4. Route Tracing 6.4. Route Tracing
It is often necessary to trace a route covered by a MEG from an It is often necessary to trace a route covered by a MEG from an
originating MEP to the peer MEP(s) including all the MIPs in- originating MEP to the peer MEP(s) including all the MIPs in between.
between, and may be conducted after provisioning an MPLS-TP This may be conducted after provisioning an MPLS-TP transport path
transport path for, e.g., trouble shooting purposes such as for, e.g., troubleshooting purposes such as fault localization.
fault localization.
The route tracing function, as required in section 2.2.4 of RFC The route tracing function, as required in Section 2.2.4 of RFC 5860
5860 [11], is providing this functionality. Based on the fate [11], is providing this functionality. Based on the fate-sharing
sharing requirement of OAM flows, i.e. OAM packets receive the requirement of OAM flows, i.e., OAM packets receive the same
same forwarding treatment as data packet, route tracing is a forwarding treatment as data packets, route tracing is a basic means
basic means to perform connectivity verification and, to a much to perform connectivity verification and, to a much lesser degree,
lesser degree, continuity check. For this function to work continuity check. For this function to work properly, a return path
properly, a return path must be present. must be present.
Route tracing might be implemented in different ways and this Route tracing might be implemented in different ways, and this
document does not preclude any of them. document does not preclude any of them.
Route tracing should always discover the full list of MIPs and Route tracing should always discover the full list of MIPs and of
of the peer MEPs. In case a defect exists, the route trace peer MEPs. In case a defect exists, the route tracing function will
function will only be able to trace up to the defect, and needs only be able to trace up to the defect, and it needs to be able to
to be able to return the incomplete list of OAM entities that it return the incomplete list of OAM entities that it was able to trace
was able to trace such that the fault can be localized. so that the fault can be localized.
6.4.1. Configuration considerations 6.4.1. Configuration Considerations
The configuration of the route trace function must at least The configuration of the route tracing function must at least support
support the setting of the number of trace attempts before it the setting of the number of trace attempts before it gives up.
gives up.
6.5. Packet Delay Measurement 6.5. Packet Delay Measurement
Packet Delay Measurement (DM) is one of the capabilities Packet Delay Measurement (DM) is one of the capabilities supported by
supported by the MPLS-TP PM function in order to facilitate the MPLS-TP PM function in order to facilitate reporting of QoS
reporting of QoS information for a transport path, as required information for a transport path, as required in Section 2.2.12 of
in section 2.2.12 of RFC 5860 [11]. Specifically, on-demand DM RFC 5860 [11]. Specifically, on-demand DM is used to measure packet
is used to measure packet delay and packet delay variation in delay and packet delay variation in the transport path monitored by a
the transport path monitored by a pair of MEPs during a pre- pair of MEPs during a pre-defined monitoring period.
defined monitoring period.
On-Demand DM is performed by sending periodic DM OAM packets On-demand DM is performed by sending periodic DM OAM packets from a
from a MEP to a peer MEP and by receiving DM OAM packets from MEP to a peer MEP and by receiving DM OAM packets from the peer MEP
the peer MEP (if a co-routed or associated bidirectional (if a co-routed or associated bidirectional transport path) during a
transport path) during a configurable time interval. configurable time interval.
On-demand DM can be operated in two modes: On-demand DM can be operated in two modes:
o One-way: a MEP sends DM OAM packet to its peer MEP containing o One-way: a MEP sends a DM OAM packet to its peer MEP containing
all the required information to facilitate one-way packet all the required information to facilitate one-way packet delay
delay and/or one-way packet delay variation measurements at and/or one-way packet delay variation measurements at the peer
the peer MEP. Note that this requires precise time MEP. Note that this requires precise time synchronization at
synchronisation at either MEP by means outside the scope of either MEP by means outside the scope of this framework.
this framework.
o Two-way: a MEP sends DM OAM packet with a DM request to its o Two-way: a MEP sends a DM OAM packet with a DM request to its peer
peer MEP, which replies with an DM OAM packet as a DM MEP, which replies with a DM OAM packet as a DM response. The
response. The request/response DM OAM packets containing all request/response DM OAM packets contain all the required
the required information to facilitate two-way packet delay information to facilitate two-way packet delay and/or two-way
and/or two-way packet delay variation measurements from the packet delay variation measurements from the viewpoint of the
viewpoint of the originating MEP. originating MEP.
MIPs, as well as intermediate nodes, do not process the DM MIPs, as well as intermediate nodes, do not process the DM
information and forward these on-demand DM OAM packets as information; they forward these on-demand DM OAM packets as regular
regular data packets. data packets.
6.5.1. Configuration considerations 6.5.1. Configuration Considerations
In order to support on-demand DM, the beginning and duration of In order to support on-demand DM, the beginning and duration of the
the DM procedures, the transmission rate and, for E-LSPs, the DM procedures, the transmission rate and, for E-LSPs, the PHB
PHB associated with the DM OAM packets originating from a MEP (associated with the DM OAM packets originating from a MEP) need to
need be configured as part of the DM provisioning. DM OAM be configured as part of the DM provisioning. DM OAM packets should
packets should be transmitted with the PHB that yields the be transmitted with the PHB that yields the lowest drop precedence
lowest drop precedence within the measured PHB Scheduling Class within the measured PHB Scheduling Class (see RFC 3260 [17]).
(see RFC 3260 [17]).
In order to verify different performances between long and short In order to verify different performances between long and short
packets (e.g., due to the processing time), it should be packets (e.g., due to the processing time), it should be possible for
possible for the operator to configure the packet size of the the operator to configure the packet size of the on-demand OAM DM
on-demand OAM DM packet. packet.
7. OAM Functions for administration control 7. OAM Functions for Administration Control
7.1. Lock Instruct 7.1. Lock Instruct
Lock Instruct (LKI) function, as required in section 2.2.6 of The Lock Instruct (LKI) function, as required in Section 2.2.6 of RFC
RFC 5860 [11], is a command allowing a MEP to instruct the peer 5860 [11], is a command allowing a MEP to instruct the peer MEP(s) to
MEP(s) to put the MPLS-TP transport path into a locked put the MPLS-TP transport path into a locked condition.
condition.
This function allows single-side provisioning for This function allows single-side provisioning for administratively
administratively locking (and unlocking) an MPLS-TP transport locking (and unlocking) an MPLS-TP transport path.
path.
Note that it is also possible to administratively lock (and Note that it is also possible to administratively lock (and unlock)
unlock) an MPLS-TP transport path using two-side provisioning, an MPLS-TP transport path using two-side provisioning, where the NMS
where the NMS administratively puts both MEPs into an administratively puts both MEPs into an administrative lock
administrative lock condition. In this case, the LKI function is condition. In this case, the LKI function is not required/used.
not required/used.
MIPs, as well as intermediate nodes, do not process the lock MIPs, as well as intermediate nodes, do not process the Lock Instruct
instruct information and forward these on-demand LKI OAM packets information; they forward these on-demand LKI OAM packets as regular
as regular data packets. data packets.
7.1.1. Locking a transport path 7.1.1. Locking a Transport Path
A MEP, upon receiving a single-side administrative lock command A MEP, upon receiving a single-side administrative lock command from
from an NMS, sends an LKI request OAM packet to its peer MEP(s). an NMS, sends an LKI request OAM packet to its peer MEP(s). It also
It also puts the MPLS-TP transport path into a locked state and puts the MPLS-TP transport path into a locked state and notifies its
notifies its client (sub-)layer adaptation function upon the client (sub-)layer adaptation function upon the locked condition.
locked condition.
A MEP, upon receiving an LKI request from its peer MEP, can A MEP, upon receiving an LKI request from its peer MEP, can either
either accept or reject the instruction and replies to the peer accept or reject the instruction and replies to the peer MEP with an
MEP with an LKI reply OAM packet indicating whether or not it LKI reply OAM packet indicating whether or not it has accepted the
has accepted the instruction. This requires either an in-band or instruction. This requires either an in-band or out-of-band return
out-of-band return path. The LKI reply is needed to allow the path. The LKI reply is needed to allow the MEP to properly report to
MEP to properly report to the NMS the actual result of the the NMS the actual result of the single-side administrative lock
single-side administrative lock command. command.
If the lock instruction has been accepted, it also puts the If the lock instruction has been accepted, it also puts the MPLS-TP
MPLS-TP transport path into a locked state and notifies its transport path into a locked state and notifies its client
client (sub-)layer adaptation function upon the locked (sub-)layer adaptation function upon the locked condition.
condition.
Note that if the client (sub-)layer is also MPLS-TP, Lock Note that if the client (sub-)layer is also MPLS-TP, Lock Report
Reporting (LKR) generation at the client MPLS-TP (sub-)layer is (LKR) generation at the client MPLS-TP (sub-)layer is started, as
started, as described in section 5.4. described in Section 5.4.
7.1.2. Unlocking a transport path 7.1.2. Unlocking a Transport Path
A MEP, upon receiving a single-side administrative unlock A MEP, upon receiving a single-side administrative unlock command
command from NMS, sends an LKI removal request OAM packet to its from NMS, sends an LKI removal request OAM packet to its peer MEP(s).
peer MEP(s).
The peer MEP, upon receiving an LKI removal request, can either The peer MEP, upon receiving an LKI removal request, can either
accept or reject the removal instruction and replies with an LKI accept or reject the removal instruction and replies with an LK
removal reply OAM packet indicating whether or not it has removal reply OAM packet indicating whether or not it has accepted
accepted the instruction. The LKI removal reply is needed to the instruction. The LKI removal reply is needed to allow the MEP to
allow the MEP to properly report to the NMS the actual result of properly report to the NMS the actual result of the single-side
the single-side administrative unlock command. administrative unlock command.
If the lock removal instruction has been accepted, it also
clears the locked condition on the MPLS-TP transport path and
notifies this event to its client (sub-)layer adaptation
function.
The MEP that has initiated the LKI clear procedure, upon
receiving a positive LKI removal reply, also clears the locked
condition on the MPLS-TP transport path and notifies this event
to its client (sub-)layer adaptation function.
Note that if the client (sub-)layer is also MPLS-TP, Lock If the lock removal instruction has been accepted, it also clears the
Reporting (LKR) generation at the client MPLS-TP (sub-)layer is locked condition on the MPLS-TP transport path and notifies its
terminated, as described in section 5.4. client (sub-)layer adaptation function of this event.
8. Security Considerations The MEP that has initiated the LKI clear procedure, upon receiving a
positive LKI removal reply, also clears the locked condition on the
MPLS-TP transport path and notifies this event to its client
(sub-)layer adaptation function.
A number of security considerations are important in the context Note that if the client (sub-)layer is also MPLS-TP, Lock Report
of OAM applications. (LKR) generation at the client MPLS-TP (sub-)layer is terminated, as
described in Section 5.4.
OAM traffic can reveal sensitive information such as performance 8. Security Considerations
data and details about the current state of the network.
Insertion of, or modifications to OAM transactions can mask the
true operational state of the network and in the case of
transactions for administration control, such as Lock or data
plane loopback instructions, these can be used for explicit
denial of service attacks. The effect of such attacks is
mitigated only by the fact that, for in-band messaging, the
managed entities whose state can be masked is limited to those
that transit the point of malicious access to the network
internals due to the fate sharing nature of OAM messaging. This
is not true when an out of band return path is employed.
The sensitivity of OAM data therefore suggests that one solution A number of security considerations are important in the context of
is that some form of authentication, authorization and OAM applications.
encryption is in place. This will prevent unauthorized access to
vital equipment and it will prevent third parties from learning
about sensitive information about the transport network. However
it should be observed that the combination of the frequency of
some OAM transactions, the need for timeliness of OAM
transaction exchange and all permutations of unique MEP to MEP,
MEP to MIP, and intermediate system originated transactions
mitigates against the practical establishment and maintenance of
a large number of security associations per MEG either in
advance or as required.
For this reason it is assumed that the internal links of the OAM traffic can reveal sensitive information, such as performance
network is physically secured from malicious access such that data and details, about the current state of the network. Insertion
OAM transactions scoped to fault and performance management of or modification of OAM transactions can mask the true operational
individual MEGs are not encumbered with additional security. state of the network, and in the case of transactions for
Further it is assumed in multi-provider cases where OAM administration control, such as lock or data-plane loopback
transactions originate outside of an individual providers instructions, these can be used for explicit denial-of-service
trusted domain that filtering mechanisms or further attacks. The effect of such attacks is mitigated only by the fact
encapsulation will need to constrain the potential impact of that, for in-band messaging, the managed entities whose state can be
malicious transactions. Mechanisms that the framework does not masked is limited to those that transit the point of malicious access
specify might be subject to additional security considerations. to the network internals due to the fate-sharing nature of OAM
messaging. This is not true when an out-of-band return path is
employed.
In case of mis-configuration, some nodes can receive OAM packets The sensitivity of OAM data therefore suggests that one solution is
that they cannot recognize. In such a case, these OAM packets that some form of authentication, authorization, and encryption is in
should be silently discarded in order to avoid malfunctions place. This will prevent unauthorized access to vital equipment, and
whose effect may be similar to malicious attacks (e.g., degraded it will prevent third parties from learning about sensitive
performance or even failure). Further considerations about data information about the transport network. However, it should be
plane attacks via G-ACh are provided in RFC 5921 [8]. observed that the combination of the frequency of some OAM
transactions, the need for timeliness of OAM transaction exchange,
and all permutations of unique MEP to MEP, MEP to MIP, and
intermediate-system-originated transactions mitigates against the
practical establishment and maintenance of a large number of security
associations per MEG either in advance or as required.
9. IANA Considerations For this reason, it is assumed that the internal links of the network
are physically secured from malicious access such that OAM
transactions scoped to fault and performance management of individual
MEGs are not encumbered with additional security. Further, it is
assumed in multi-provider cases where OAM transactions originate
outside of an individual provider's trusted domain that filtering
mechanisms or further encapsulation will need to constrain the
potential impact of malicious transactions. Mechanisms that the
framework does not specify might be subject to additional security
considerations.
This memo does not have any IANA considerations. In case of misconfiguration, some nodes can receive OAM packets that
they cannot recognize. In such a case, these OAM packets should be
silently discarded in order to avoid malfunctions whose effects may
be similar to malicious attacks (e.g., degraded performance or even
failure). Further considerations about data-plane attacks via G-ACh
are provided in RFC 5921 [8].
10. Acknowledgments 9. Acknowledgments
The authors would like to thank all members of the teams (the The authors would like to thank all members of the teams (the Joint
Joint Working Team, the MPLS Interoperability Design Team in Working Team, the MPLS Interoperability Design Team in IETF, and the
IETF and the Ad Hoc Group on MPLS-TP in ITU-T) involved in the Ad Hoc Group on MPLS-TP in ITU-T) involved in the definition and
definition and specification of MPLS Transport Profile. specification of the MPLS Transport Profile.
The editors gratefully acknowledge the contributions of Adrian The editors gratefully acknowledge the contributions of Adrian
Farrel, Yoshinori Koike, Luca Martini, Yuji Tochio and Manuel Farrel, Yoshinori Koike, Luca Martini, Yuji Tochio, and Manuel Paul
Paul for the definition of per-interface MIPs and MEPs. for the definition of per-interface MIPs and MEPs.
The editors gratefully acknowledge the contributions of Malcolm The editors gratefully acknowledge the contributions of Malcolm
Betts, Yoshinori Koike, Xiao Min, and Maarten Vissers for the Betts, Yoshinori Koike, Xiao Min, and Maarten Vissers for the Lock
lock report and lock instruction description. Report and Lock Instruct descriptions.
The authors would also like to thank Alessandro D'Alessandro,
Loa Andersson, Malcolm Betts, Dave Black, Stewart Bryant, Rui
Costa, Xuehui Dai, John Drake, Adrian Farrel, Dan Frost, Xia
Liang, Liu Gouman, Peng He, Russ Housley, Feng Huang, Su Hui,
Yoshionori Koike, Thomas Morin, George Swallow, Yuji Tochio,
Curtis Villamizar, Maarten Vissers and Xuequin Wei for their
comments and enhancements to the text.
This document was prepared using 2-Word-v2.0.template.dot. The authors would also like to thank Alessandro D'Alessandro, Loa
Andersson, Malcolm Betts, Dave Black, Stewart Bryant, Rui Costa,
Xuehui Dai, John Drake, Adrian Farrel, Dan Frost, Xia Liang, Liu
Gouman, Peng He, Russ Housley, Feng Huang, Su Hui, Yoshionori Koike,
Thomas Morin, George Swallow, Yuji Tochio, Curtis Villamizar, Maarten
Vissers, and Xuequin Wei for their comments and enhancements to the
text.
11. References 10. References
11.1. Normative References 10.1. Normative References
[1] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol [1] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label
Label Switching Architecture", RFC 3031, January 2001 Switching Architecture", RFC 3031, January 2001.
[2] Bryant, S., Pate, P., "Pseudo Wire Emulation Edge-to-Edge [2] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-
(PWE3) Architecture", RFC 3985, March 2005 to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[3] Nadeau, T., Pignataro, S., "Pseudowire Virtual Circuit [3] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual
Connectivity Verification (VCCV): A Control Channel for Circuit Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007 Pseudowires", RFC 5085, December 2007.
[4] Bocci, M., Bryant, S., "An Architecture for Multi-Segment [4] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment
Pseudo Wire Emulation Edge-to-Edge", RFC 5659, October Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009.
2009
[5] Niven-Jenkins, B., Brungard, D., Betts, M., sprecher, N., [5] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
Ueno, S., "MPLS-TP Requirements", RFC 5654, September 2009 Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport
Profile", RFC 5654, September 2009.
[6] Agarwal, P., Akyol, B., "Time To Live (TTL) Processing in [6] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in
Multiprotocol Label Switching (MPLS) Networks", RFC 3443, Multi-Protocol Label Switching (MPLS) Networks", RFC 3443,
January 2003 January 2003.
[7] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, [7] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS
R., "MPLS Generic Associated Channel", RFC 5586, June 2009 Generic Associated Channel", RFC 5586, June 2009.
[8] Bocci, M., et al., "A Framework for MPLS in Transport [8] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and
Networks", RFC 5921, July 2010 L. Berger, "A Framework for MPLS in Transport Networks", RFC
5921, July 2010.
[9] Bocci, M., et al., " MPLS Transport Profile User-to-Network and [9] Bocci, M., Levrau, L., and D. Frost, "MPLS Transport Profile
Network-to-Network Interfaces", draft-ietf-mpls-tp-uni-nni-03 User-to-Network and Network-to-Network Interfaces", RFC 6215,
(work in progress), January 2011 April 2011.
[10] Swallow, G., Bocci, M., "MPLS-TP Identifiers", draft-ietf- [10] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS
mpls-tp-identifiers-03 (work in progress), October 2010 Transport Profile Data Plane Architecture", RFC 5960, August
2010.
[11] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM [11] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
in MPLS Transport Networks", RFC 5860, May 2010 "Requirements for Operations, Administration, and Maintenance
(OAM) in MPLS Transport Networks", RFC 5860, May 2010.
[12] Bradner, S., McQuaid, J., "Benchmarking Methodology for [12] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999 Network Interconnect Devices", RFC 2544, March 1999.
[13] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [13] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W.
Weiss, W., "An Architecture for Differentiated Services", Weiss, "An Architecture for Differentiated Service", RFC 2475,
RFC 2475, December 1998 December 1998.
[14] ITU-T Recommendation G.806 (01/09), "Characteristics of [14] ITU-T Recommendation G.806 (01/09), "Characteristics of
transport equipment - Description methodology and generic transport equipment - Description methodology and generic
functionality ", January 2009 functionality", January 2009.
11.2. Informative References 10.2. Informative References
[15] Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten, [15] Sprecher, N. and L. Fang, "An Overview of the OAM Tool Set for
Y., "MPLS-TP OAM Analysis", draft-ietf-mpls-tp-oam- MPLS based Transport Networks", Work in Progress, June 2011.
analysis-03 (work in progress), January 2011
[16] Nichols, K., Blake, S., Baker, F., Black, D., "Definition [16] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of
of the Differentiated Services Field (DS Field) in the the Differentiated Services Field (DS Field) in the IPv4 and
IPv4 and IPv6 Headers", RFC 2474, December 1998 IPv6 Headers", RFC 2474, December 1998.
[17] Grossman, D., "New terminology and clarifications for [17] Grossman, D., "New Terminology and Clarifications for Diffserv",
Diffserv", RFC 3260, April 2002. RFC 3260, April 2002.
[18] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in [18] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS
MPLS Traffic Engineering (TE)", RFC 4201, October 2005 Traffic Engineering (TE)", RFC 4201, October 2005.
[19] ITU-T Recommendation G.707/Y.1322 (01/07), "Network node [19] ITU-T Recommendation G.707/Y.1322 (01/07), "Network node
interface for the synchronous digital hierarchy (SDH)", interface for the synchronous digital hierarchy (SDH)", January
January 2007 2007.
[20] ITU-T Recommendation G.805 (03/00), "Generic functional [20] ITU-T Recommendation G.805 (03/00), "Generic functional
architecture of transport networks", March 2000 architecture of transport networks", March 2000.
[21] ITU-T Recommendation Y.1731 (02/08), "OAM functions and [21] ITU-T Recommendation Y.1731 (02/08), "OAM functions and
mechanisms for Ethernet based networks", February 2008 mechanisms for Ethernet based networks", February 2008.
[22] IEEE Standard 802.1AX-2008, "IEEE Standard for Local and [22] IEEE Standard 802.1AX-2008, "IEEE Standard for Local and
Metropolitan Area Networks - Link Aggregation", November Metropolitan Area Networks - Link Aggregation", November 2008.
2008
[23] Le Faucheur et.al., "Multi-Protocol Label Switching (MPLS)
Support of Differentiated Services", RFC 3270, May 2002.
Authors' Addresses [23] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P.,
Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label
Switching (MPLS) Support of Differentiated Services", RFC 3270,
May 2002.
Dave Allan [24] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile
Ericsson (MPLS-TP) Identifiers", RFC 6370, September 2011.
Email: david.i.allan@ericsson.com [25] Winter, R., Ed., van Helvoort, H., and M. Betts, "MPLS-TP
Italo Busi Identifiers Following ITU-T Conventions", Work in Progress, July
Alcatel-Lucent 2011.
Email: Italo.Busi@alcatel-lucent.com 11. Contributing Authors
Ben Niven-Jenkins Ben Niven-Jenkins
Velocix Velocix
Email: ben@niven-jenkins.co.uk EMail: ben@niven-jenkins.co.uk
Annamaria Fulignoli Annamaria Fulignoli
Ericsson Ericsson
Email: annamaria.fulignoli@ericsson.com EMail: annamaria.fulignoli@ericsson.com
Enrique Hernandez-Valencia Enrique Hernandez-Valencia
Alcatel-Lucent Alcatel-Lucent
Email: Enrique.Hernandez@alcatel-lucent.com EMail: Enrique.Hernandez@alcatel-lucent.com
Lieven Levrau Lieven Levrau
Alcatel-Lucent Alcatel-Lucent
Email: Lieven.Levrau@alcatel-lucent.com EMail: Lieven.Levrau@alcatel-lucent.com
Vincenzo Sestito Vincenzo Sestito
Alcatel-Lucent Alcatel-Lucent
Email: Vincenzo.Sestito@alcatel-lucent.com EMail: Vincenzo.Sestito@alcatel-lucent.com
Nurit Sprecher Nurit Sprecher
Nokia Siemens Networks Nokia Siemens Networks
Email: nurit.sprecher@nsn.com EMail: nurit.sprecher@nsn.com
Huub van Helvoort Huub van Helvoort
Huawei Technologies Huawei Technologies
Email: hhelvoort@huawei.com EMail: hhelvoort@huawei.com
Martin Vigoureux Martin Vigoureux
Alcatel-Lucent Alcatel-Lucent
Email: Martin.Vigoureux@alcatel-lucent.com EMail: Martin.Vigoureux@alcatel-lucent.com
Yaacov Weingarten Yaacov Weingarten
Nokia Siemens Networks Nokia Siemens Networks
Email: yaacov.weingarten@nsn.com EMail: yaacov.weingarten@nsn.com
Rolf Winter Rolf Winter
NEC NEC
Email: Rolf.Winter@nw.neclab.eu EMail: Rolf.Winter@nw.neclab.eu
Authors' Addresses
Dave Allan
Ericsson
EMail: david.i.allan@ericsson.com
Italo Busi
Alcatel-Lucent
EMail: Italo.Busi@alcatel-lucent.com
 End of changes. 578 change blocks. 
2088 lines changed or deleted 1959 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/