draft-ietf-mpls-tp-oam-framework-06.txt   draft-ietf-mpls-tp-oam-framework-07.txt 
MPLS Working Group I. Busi (Ed) MPLS Working Group I. Busi (Ed)
Internet Draft Alcatel-Lucent Internet Draft Alcatel-Lucent
Intended status: Informational B. Niven-Jenkins (Ed) Intended status: Informational B. Niven-Jenkins (Ed)
BT BT
D. Allan (Ed) D. Allan (Ed)
Ericsson Ericsson
Expires: October 21, 2010 April 21, 2010 Expires: January 12, 2011 July 12, 2010
MPLS-TP OAM Framework MPLS-TP OAM Framework
draft-ietf-mpls-tp-oam-framework-06.txt draft-ietf-mpls-tp-oam-framework-07.txt
Abstract Abstract
Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS- The Transport Profile of Multi-Protocol Label Switching
TP) is based on a profile of the MPLS and pseudowire (PW) (MPLS-TP) is a packet-based transport technology based on the
procedures as specified in the MPLS Traffic Engineering (MPLS- MPLS Traffic Engineering (MPLS-TE) and Pseudowire (PW) data
TE), PW and multi-segment PW (MS-PW) architectures complemented plane architectures.
with additional Operations, Administration and Maintenance (OAM)
procedures for fault, performance and protection-switching
management for packet transport applications that do not rely on
the presence of a control plane.
This document describes a framework to support a comprehensive This document describes a framework to support a comprehensive
set of OAM procedures that fulfill the MPLS-TP OAM requirements. 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 This document is a product of a joint Internet Engineering Task
Force (IETF) / International Telecommunications Union Force (IETF) / International Telecommunications Union
Telecommunication Standardization Sector (ITU-T) effort to Telecommunication Standardization Sector (ITU-T) effort to
include an MPLS Transport Profile within the IETF MPLS and PWE3 include an MPLS Transport Profile within the IETF MPLS and PWE3
architectures to support the capabilities and functionalities of architectures to support the capabilities and functionalities of
a packet transport network as defined by the ITU-T. a packet transport network as defined by the ITU-T.
Status of this Memo Status of this Memo
skipping to change at page 2, line 13 skipping to change at page 2, line 13
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work Drafts as reference material or to cite them other than as "work
in progress". in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 21, 2010. This Internet-Draft will expire on January 12, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described document must include Simplified BSD License text as described
in Section 4.e of the Trust Legal Provisions and are provided in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the BSD License. without warranty as described in the BSD License.
Table of Contents Table of Contents
1. Introduction...................................................5 1. Introduction................................................5
1.1. Contributing Authors......................................6 1.1. Contributing Authors....................................6
2. Conventions used in this document..............................6 2. Conventions used in this document............................6
2.1. Terminology...............................................6 2.1. Terminology............................................6
2.2. Definitions...............................................7 2.2. Definitions............................................7
3. Functional Components..........................................9 3. Functional Components.......................................10
3.1. Maintenance Entity and Maintenance Entity Group...........9 3.1. Maintenance Entity and Maintenance Entity Group.........10
3.2. Nested MEGs: Path Segment Tunnels and Tandem Connection 3.2. Nested MEGs: SPMEs and Tandem Connection Monitoring.....12
Monitoring....................................................11 3.3. MEG End Points (MEPs)..................................14
3.3. MEG End Points (MEPs)....................................13 3.4. MEG Intermediate Points (MIPs).........................17
3.4. MEG Intermediate Points (MIPs)...........................15 3.5. Server MEPs...........................................18
3.5. Server MEPs..............................................17 3.6. Configuration Considerations...........................19
3.6. Configuration Considerations.............................18 3.7. P2MP considerations....................................20
3.7. P2MP considerations......................................18 4. Reference Model............................................21
4. Reference Model...............................................19 4.1. MPLS-TP Section Monitoring (SME).......................23
4.1. MPLS-TP Section Monitoring (SME).........................21 4.2. MPLS-TP LSP End-to-End Monitoring (LME)................24
4.2. MPLS-TP LSP End-to-End Monitoring (LME)..................22 4.3. MPLS-TP PW Monitoring (PME)............................24
4.3. MPLS-TP PW Monitoring (PME)..............................23 4.4. MPLS-TP LSP SPME Monitoring (LSME).....................25
4.4. MPLS-TP LSP Path Segment Tunnel Monitoring (LPSTME)......23 4.5. MPLS-TP MS-PW SPME Monitoring (PSME)...................26
4.5. MPLS-TP MS-PW Path Segment Tunnel Monitoring (PPSTME)....25 4.6. Fate sharing considerations for multilink..............28
4.6. Fate sharing considerations for multilink................26 5. OAM Functions for proactive monitoring......................29
5. OAM Functions for proactive monitoring........................27 5.1. Continuity Check and Connectivity Verification..........30
5.1. Continuity Check and Connectivity Verification...........28 5.1.1. Defects identified by CC-V........................31
5.1.1. Defects identified by CC-V..........................29 5.1.2. Consequent action.................................33
5.1.2. Consequent action...................................31 5.1.3. Configuration considerations......................34
5.1.3. Configuration considerations........................32 5.2. Remote Defect Indication...............................35
5.2. Remote Defect Indication.................................33 5.2.1. Configuration considerations......................36
5.2.1. Configuration considerations........................34 5.3. Alarm Reporting........................................36
5.3. Alarm Reporting..........................................34 5.4. Lock Reporting........................................38
5.4. Lock Reporting...........................................35 5.5. Packet Loss Measurement................................39
5.5. Packet Loss Measurement..................................36 5.5.1. Configuration considerations......................40
5.5.1. Configuration considerations........................37 5.5.2. Sampling skew.....................................40
5.5.2. Sampling skew.......................................37 5.5.3. Multilink issues..................................40
5.5.3. Multilink issues....................................37 5.6. Packet Delay Measurement...............................41
5.6. Packet Delay Measurement.................................37 5.6.1. Configuration considerations......................41
5.6.1. Configuration considerations........................38 5.7. Client Failure Indication..............................41
5.7. Client Failure Indication................................38 5.7.1. Configuration considerations......................42
5.7.1. Configuration considerations........................39 6. OAM Functions for on-demand monitoring......................42
6. OAM Functions for on-demand monitoring........................39 6.1. Connectivity Verification..............................43
6.1. Connectivity Verification................................40 6.1.1. Configuration considerations......................44
6.1.1. Configuration considerations........................41 6.2. Packet Loss Measurement................................45
6.2. Packet Loss Measurement..................................41 6.2.1. Configuration considerations......................45
6.2.1. Configuration considerations........................42 6.2.2. Sampling skew.....................................45
6.2.2. Sampling skew.......................................42 6.2.3. Multilink issues..................................46
6.2.3. Multilink issues....................................42 6.3. Diagnostic Tests.......................................46
6.3.1. Throughput Estimation.............................46
6.3. Diagnostic Tests.........................................42 6.3.2. Data plane Loopback...............................47
6.3.1. Throughput Estimation...............................42 6.4. Route Tracing.........................................48
6.3.2. Data plane Loopback.................................43 6.4.1. Configuration considerations......................48
6.4. Route Tracing............................................44 6.5. Packet Delay Measurement...............................48
6.4.1. Configuration considerations........................44 6.5.1. Configuration considerations......................49
6.5. Packet Delay Measurement.................................45 7. OAM Functions for administration control....................49
6.5.1. Configuration considerations........................45 7.1. Lock Instruct.........................................49
7. OAM Functions for administration control......................46 7.1.1. Locking a transport path..........................50
7.1. Lock Instruct............................................46 7.1.2. Unlocking a transport path........................50
7.1.1. Locking a transport path............................46 8. Security Considerations.....................................51
7.1.2. Unlocking a transport path..........................46 9. IANA Considerations........................................51
8. Security Considerations.......................................47 10. Acknowledgments...........................................52
9. IANA Considerations...........................................47 11. References................................................53
10. Acknowledgments..............................................48 11.1. Normative References..................................53
11. References...................................................49 11.2. Informative References................................54
11.1. Normative References....................................49
11.2. Informative References..................................49
Editors' Note: Editors' Note:
This Informational Internet-Draft is aimed at achieving IETF This Informational Internet-Draft is aimed at achieving IETF
Consensus before publication as an RFC and will be subject to an Consensus before publication as an RFC and will be subject to an
IETF Last Call. IETF Last Call.
[RFC Editor, please remove this note before publication as an [RFC Editor, please remove this note before publication as an
RFC and insert the correct Streams Boilerplate to indicate that RFC and insert the correct Streams Boilerplate to indicate that
the published RFC has IETF Consensus.] the published RFC has IETF Consensus.]
1. Introduction 1. Introduction
As noted in [5], the multi protocol label switching (MPLS) As noted in [8], the transport profile of multi-protocol label
transport profile (MPLS-TP) defines a profile of the MPLS- switching (MPLS-TP) is a packet-based transport technology based on
Traffic Engineering (MPLS-TE) and Multi-segment Pseudo Wire the MPLS Traffic Engineering (MPLS-TE) and Pseudo Wire (PW) data
(MS-PW) architectures defined in RFC 3031 [1], RFC 3985 [2] and plane architectures defined in RFC 3031 [1], RFC 3985 [2] and RFC
RFC 5659 [4] which is complemented with additional OAM 5659 [4].
mechanisms and procedures for alarm, fault, performance and
protection-switching management for packet transport
applications.
In line with [10], existing MPLS OAM mechanisms will be used MPLS-TP supports a comprehensive set of Operations,
Administration and Maintenance (OAM) procedures for fault,
performance and protection-switching management and that do not
rely on the presence of a control plane.
In line with [13], existing MPLS OAM mechanisms will be used
wherever possible and extensions or new OAM mechanisms will be wherever possible and extensions or new OAM mechanisms will be
defined only where existing mechanisms are not sufficient to defined only where existing mechanisms are not sufficient to
meet the requirements. Extensions do not deprecate support for meet the requirements. Extensions do not 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
comprehensive set of OAM procedures that satisfy the MPLS-TP OAM comprehensive set of OAM procedures that satisfy the MPLS-TP OAM
requirements [8]. In this regard, it defines similar OAM requirements of RFC 5860 [10]. In this regard, it defines
functionality as for existing SONET/SDH and OTN OAM mechanisms similar OAM functionality as for existing SONET/SDH and OTN OAM
(e.g. [13]). mechanisms (e.g. [17]).
The MPLS-TP OAM framework is applicable to both LSPs and The MPLS-TP OAM framework is applicable to both LSPs and
(MS-)PWs and supports co-routed and associated bidirectional p2p (MS-)PWs and supports co-routed and associated bidirectional p2p
transport paths as well as unidirectional p2p and p2mp transport transport paths as well as unidirectional p2p and p2mp transport
paths. paths.
This document is a product of a joint Internet Engineering Task This document is a product of a joint Internet Engineering Task
Force (IETF) / International Telecommunication Union Force (IETF) / International Telecommunication Union
Telecommunication Standardization Sector (ITU-T) effort to Telecommunication Standardization Sector (ITU-T) effort to
include an MPLS Transport Profile within the IETF MPLS and PWE3 include an MPLS Transport Profile within the IETF MPLS and PWE3
architectures to support the capabilities and functionalities of architectures to support the capabilities and functionalities of
a packet transport network as defined by the ITU-T. a packet transport network as defined by the ITU-T.
1.1. Contributing Authors 1.1. Contributing Authors
Dave Allan, Italo Busi, Ben Niven-Jenkins, Annamaria Fulignoli, Dave Allan, Italo Busi, Ben Niven-Jenkins, Annamaria Fulignoli,
Enrique Hernandez-Valencia, Lieven Levrau, Dinesh Mohan, Enrique Hernandez-Valencia, Lieven Levrau, Vincenzo Sestito,
Vincenzo Sestito, Nurit Sprecher, Huub van Helvoort, Martin Nurit Sprecher, Huub van Helvoort, Martin Vigoureux, Yaacov
Vigoureux, Yaacov Weingarten, Rolf Winter Weingarten, Rolf Winter
2. Conventions used in this document 2. Conventions used in this document
2.1. Terminology 2.1. Terminology
AC Attachment Circuit AC Attachment Circuit
DBN Domain Border Node DBN Domain Border Node
LER Label Edge Router LER Label Edge Router
LME LSP Maintenance Entity Group LME LSP Maintenance Entity
LSP Label Switched Path LMEG LSP ME Group
LSR Label Switching Router LSP Label Switched Path
LPSTME LSP path segment tunnel ME Group LSR Label Switching Router
ME Maintenance Entity LSME LSP SPME ME
MEG Maintenance Entity Group LSMEG LSP SPME ME Group
MEP Maintenance Entity Group End Point ME Maintenance Entity
MIP Maintenance Entity Group Intermediate Point MEG Maintenance Entity Group
PHB Per-hop Behavior MEP Maintenance Entity Group End Point
PME PW Maintenance Entity Group MIP Maintenance Entity Group Intermediate Point
PPSTME PW path segment tunnel ME Group PHB Per-hop Behavior
PST Path Segment Tunnel PME PW Maintenance Entity
PW Pseudowire PMEG PW ME Group
SLA Service Level Agreement PSME PW SPME ME
SME Section Maintenance Entity Group PSMEG PW SPME ME Group
PW Pseudowire
SLA Service Level Agreement
SME Section Maintenance Entity Group
SPME Sub-path Maintenance Element
2.2. Definitions 2.2. Definitions
Note - the definitions in this section are aligned with ITU-T This document uses the terms defined in RFC 5654 [5].
recommendation Y.1731 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.
Data plane loopback: it is an out-of-service test where an This document uses the term 'Per-hop Behavior' as defined in RFC
interface at either an intermediate or terminating node in a 2474 [14].
path is placed into a data plane loopback state, such that all
traffic (including user data and OAM) received on the looped This document uses the term LSP to indicate either a service LSP
back interface is sent on the reverse direction of the transport or a transport LSP (as defined in [8]).
Where appropriate, the following definitions are aligned with
ITU-T recommendation Y.1731 [19] in order to have a common,
unambiguous terminology. They do not however intend to imply a
certain implementation but rather serve as a framework to
describe the necessary OAM functions for MPLS-TP.
Adaptation function: The adaptation function is the interface
between the client (sub)-layer and the server (sub-layer).
Data plane loopback: An out-of-service test where an interface
at either an intermediate or terminating node in a path is
placed into a data plane loopback state, such that all traffic
(including user data and OAM) received on the looped back
interface is sent on the reverse direction of the transport
path. path.
Domain Border Node (DBN): An LSP intermediate MPLS-TP node (LSR) Note - The only way to send an OAM packet to a node set in the data
that is at the boundary of an MPLS-TP OAM domain. Such a node plane loopback mode is via TTL expiry, irrespectively on whether the
may be present on the edge of two domains or may be connected by node is hosting MIPs or MEPs.
a link to an MPLS-TP node in another OAM domain.
Down MEP: A MEP residing in a node that receives OAM packets Domain Border Node (DBN): An intermediate node in an MPLS-TP LSP
from, and transmits them towards, the direction of a server that is at the boundary between two MPLS-TP OAM domains. Such a
layer. 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.
In-Service: the administrative status of a transport path when Down MEP: A MEP that receives OAM packets from, and transmits
them towards, the direction of a server layer.
In-Service: The administrative status of a transport path when
it is unlocked. it is unlocked.
Intermediate Node: An intermediate node transits traffic for an Intermediate Node: An intermediate node transits traffic for an
LSP or a PW. An intermediate node may originate OAM flows LSP or a PW. An intermediate node may originate OAM flows
directed to downstream intermediate nodes or MEPs. directed to 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, and the relationship requires management bounded by two points (called MEPs), and the
between those points to which maintenance and monitoring relationship between those points to which maintenance and
operations apply (details in section 3.1). monitoring 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 entities that maintain and monitor a transport path maintenance entities that maintain and monitor a transport path
in an OAM domain. in an OAM domain.
MEP: A MEG end point (MEP) is capable of initiating (MEP Source) MEP: A MEG end point (MEP) is capable of initiating (MEP Source)
and terminating (MEP Sink) OAM messages for fault management and and terminating (MEP Sink) OAM messages for fault management and
performance monitoring. MEPs define the boundaries of an ME performance monitoring. MEPs define the boundaries of an ME
(details in section 3.3). (details in section 3.3).
MEP Source: A MEP acts as MEP source for an OAM message when it MEP Source: A MEP acts as MEP source for an OAM message when it
originates and inserts the message into the transport path for originates and inserts the message into the transport path for
its associated MEG. its associated MEG.
MEP Sink: A MEP acts as a MEP sink for an OAM message when it MEP Sink: A MEP acts as a MEP sink for an OAM message when it
terminates and processes the messages received from its terminates and processes the messages received from its
associated MEG. associated MEG.
MIP: A MEG intermediate point (MIP) terminates and processes OAM MIP: A MEG intermediate point (MIP) terminates and processes OAM
messages and may generate OAM messages in reaction to received messages that are sent to this particular MIP and may generate
OAM messages. It never generates unsolicited OAM messages OAM messages in reaction to received OAM messages. It never
itself. A MIP resides within a MEG between MEPs (details in generates unsolicited OAM messages itself. A MIP resides within
section 3.3). a MEG between MEPs (details in section 3.3).
MPLS-TP Section: As defined in [8], it is the link traversed by
an MPLS-TP LSP.
OAM domain: A domain, as defined in [5], whose entities are OAM domain: A domain, as defined in [5], whose entities are
grouped for the purpose of keeping the OAM confined within that grouped for the purpose of keeping the OAM confined within that
domain. domain.
Note - within the rest of this document the term "domain" is Note - within the rest of this document the term "domain" is
used to indicate an "OAM domain" used to indicate an "OAM domain"
OAM flow: Is the set of all OAM messages originating with a OAM flow: Is the set of all OAM messages originating with a
specific MEP source that instrument one direction of a MEG. specific MEP source that instrument one direction of a MEG.
OAM information element: An atomic piece of information OAM information element: An atomic piece of information
exchanged between MEPs in MEG used by an OAM application. exchanged between MEPs and/or MIPs in MEG used by an OAM
application.
OAM loopback: it is the capability of a node to intercepts some OAM loopback: It is the capability of a node to be directed by a
specific OAM packets and to generate a reply back to their received OAM message to generate a reply back to the sender. OAM
sender. OAM loopback can work in-service and can support loopback can work in-service and can support different OAM
different OAM functions (e.g., bidirectional on-demand functions (e.g., bidirectional on-demand connectivity
connectivity verification). verification).
OAM Message: One or more OAM information elements that when OAM Message: One or more OAM information elements that when
exchanged between MEPs or between MEPs and MIPs performs some exchanged between MEPs or between MEPs and MIPs performs some
OAM functionality (e.g. connectivity verification) OAM functionality (e.g. connectivity verification)
OAM Packet: A packet that carries one or more OAM messages (i.e. OAM Packet: A packet that carries one or more OAM messages (i.e.
OAM information elements). OAM information elements).
Out-of-Service: the administrative status of a transport path Out-of-Service: The administrative status of a transport path
when it is locked. When a path is in a locked condition, it is when it is locked. When a path is in a locked condition, it is
blocked from carrying client traffic. blocked from 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 defined in RFC 5654 [5]. as defined in RFC 5654 [5].
Signal Degrade: A condition declared by a MEP when the data
forwarding capability associated with a transport path has
deteriorated, as determined by PM. See also ITU-T recommendation
G.806 [12].
Signal Fail: A condition declared by a MEP when the data Signal Fail: 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
failed, e.g. loss of continuity. See also [9]. failed, e.g. loss of continuity. See also ITU-T recommendation
G.806 [12].
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 end-to-end monitoring (OAM). The tandem connection may also the end-to-end monitoring (OAM). The tandem connection may also
include the forwarding engine(s) of the node(s) at the include the forwarding engine(s) of the node(s) at the
boundaries of the tandem connection. boundaries of the tandem connection. Tandem connections may be
nested but cannot overlap. See also ITU-T recommendation G.805
Up MEP: A MEP residing in a node that transmits OAM packets [18].
towards, and receives them from, the direction of the forwarding
engine.
This document uses the terms defined in RFC 5654 [5].
This document uses the term 'Per-hop Behavior' as defined in
[11].
This document uses the term LSP to indicate either a service LSP Up MEP: A MEP that transmits OAM packets towards, and receives
or a transport LSP (as defined in [5]). them from, the direction of the forwarding engine.
3. Functional Components 3. Functional Components
MPLS-TP defines a profile of the MPLS and PW architectures ([1], MPLS-TP is a packet-based transport technology based on the MPLS
[2] and [4]) that is required to transport service traffic where and PW data plane architectures ([1], [2] and [4]) and is
the characteristics of information transfer between the capable of transporting service traffic where the
transport path endpoints can be demonstrated to comply with characteristics of information transfer between the transport
certain performance and quality guarantees. path endpoints can be demonstrated to comply with certain
performance and quality guarantees.
In order to describe the required OAM functionality, this In order to describe the required OAM functionality, this
document introduces a set of high-level functional components. document 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) that are a relationship between any two points of a (MEs) that define a relationship between any two points of a
transport path to which maintenance and monitoring operations transport path to which maintenance and monitoring operations
apply. The collection of one or more MEs that belongs to the apply. The collection of one or more MEs that belongs to the
same transport path and that are maintained and monitored as a same transport path and that are maintained and monitored as a
group are known as a maintenance entity group (MEG) and the two group are known as a maintenance entity group (MEG) and the two
points that define a maintenance entity are called Maintenance points that define a maintenance entity are called Maintenance
Entity Group (MEG) End Points (MEPs). In between these two Entity Group (MEG) End Points (MEPs). In between these two
points zero or more intermediate points, called Maintenance points zero or more intermediate points, called Maintenance
Entity Group Intermediate Points (MIPs), can exist and can be Entity Group Intermediate Points (MIPs), can exist and can be
shared by more than one ME in a MEG. shared by more than one ME in a MEG.
The abstract reference model for an ME with MEPs and MIPs is An abstract reference model for an ME is illustrated in Figure 1
described 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 this model, nodes A, B, C entities is described in section 4. In Figure 1, nodes A and D
and D can be LER/LSR for an LSP or the {S|T}-PEs for a MS-PW. can be LERs for an LSP or the T-PEs for a MS-PW, nodes B and C
MEPs reside in nodes A and D while MIPs reside in nodes B and C are LSRs for a LSP or S-PEs for a MS-PW. MEPs reside in nodes A
and may reside in A and D. The links connecting adjacent nodes and D while MIPs reside in nodes B and C and may reside in A and
can be physical links, (sub-)layer LSPs/PSTs, or serving layer D. The links connecting adjacent nodes can be physical links,
paths. (sub-)layer LSPs/SPMEs, or serving 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, to allow each entities from a maintenance perspective, to allow each
Maintenance Entity to monitor and manage the (sub-)layer network Maintenance Entity to monitor and manage the (sub-)layer network
under its responsibility and to localize problems efficiently. under its responsibility and to localize problems efficiently.
An MPLS-TP Maintenance Entity Group may be defined to monitor An MPLS-TP Maintenance Entity Group may be defined to monitor
the transport path for fault and/or performance management. the transport path for fault and/or performance management.
The MEPs that form a MEG are configured and managed to limit the The MEPs that form a MEG bound the scope of an OAM flows to the
scope of an OAM flow within the MEG that the MEPs belong to 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). A misbranching fault may cause OAM
packets to be delivered to a MEP that is not in the MEG of 1) A misbranching fault may cause OAM packets to be delivered to
origin. a MEP that is not in the MEG of origin.
2) An out-of-band return path may be used between a MIP or a MEP
and the originating MEP.
In case of unidirectional point-to-point transport paths, a In case of unidirectional point-to-point transport paths, a
single unidirectional Maintenance Entity is defined to monitor single unidirectional Maintenance Entity is defined to monitor
it. it.
In case of associated bi-directional point-to-point transport In case of associated bi-directional point-to-point transport
paths, two independent unidirectional Maintenance Entities are paths, two independent unidirectional Maintenance Entities are
defined to independently monitor each direction. This has defined to independently monitor each direction. This has
implications for transactions that terminate at or query a MIP, implications for transactions that terminate at or query a MIP,
as a return path from MIP to source MEP does not necessarily as a return path from MIP to source MEP does not necessarily
skipping to change at page 11, line 10 skipping to change at page 11, line 40
In case of co-routed bi-directional point-to-point transport In case of co-routed bi-directional point-to-point transport
paths, a single bidirectional Maintenance Entity is defined to paths, a single bidirectional Maintenance Entity is defined to
monitor both directions congruently. monitor both 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 monitor the transport path from the root to that defined to monitor the transport path from the root to that
leaf. leaf.
In all cases, portions of the transport path may be monitored by
the instantiation of SPMEs (see section 3.2).
The reference model for the p2mp MEG is represented in Figure 2. 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 operations are In 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 from 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 from itself and the root while the root (i.e. A) generates ME from itself and the root while the root (i.e. A) generates
OAM messages common to all the MEs of the p2mp MEG. All nodes OAM messages common to all the MEs of the p2mp MEG. All nodes
may implement a MIP in the corresponding MEG. may implement a MIP in the corresponding MEG.
3.2. Nested MEGs: Path Segment Tunnels and Tandem Connection 3.2. Nested MEGs: SPMEs and Tandem Connection Monitoring
Monitoring
In order to verify and maintain performance and quality In order to verify and maintain performance and quality
guarantees, there is a need to not only apply OAM functionality guarantees, there is a need to not only apply OAM functionality
on a transport path granularity (e.g. LSP or MS-PW), but also on on a transport path granularity (e.g. LSP or MS-PW), but also on
arbitrary parts of transport paths, defined as Tandem arbitrary parts of transport paths, defined as Tandem
Connections, between any two arbitrary points along a transport Connections, between any two arbitrary points along a transport
path. path.
Path segment tunnels (PSTs), as defined in [5], are instantiated Sub-path Maintenance Elements (SPMEs), as defined in [8], are
to provide monitoring of a portion of a set of co-routed instantiated to provide monitoring of a portion of a set of co-
transport paths (LSPs or MS-PWs). Path segment tunnels can also routed transport paths (LSPs or MS-PWs). The operational aspects
be employed to meet the requirement to provide tandem connection of instantiating SPMEs are out of scope of this memo.
monitoring (TCM).
SPMEs can also be employed to meet the requirement to provide
tandem connection monitoring (TCM).
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 creating a path segment tunnel that has a 1:1 association by creating an SPME that has a 1:1 association with the path
with the path segment of the transport path that is to be segment of the transport path that is to be monitored.
uniquely monitored. This means that the PST used to provide TCM
In the TCM case, this means that the SPME used to provide TCM
can carry only one and only one transport path thus allowing can carry only one and only one transport path thus allowing
direct correlation between all fault management and performance direct correlation between all fault management and performance
monitoring information gathered for the PST and the monitored monitoring information gathered for the SPME and the monitored
path segment of the end-to-end transport path. The PST is path segment of the end-to-end transport path. The SPME is
monitored using normal LSP monitoring. monitored using normal LSP monitoring.
Where resiliency is required across an arbitrary portion of a
transport path, this may be implemented by more than one
diversely routed SPMEs with common end points where only one
SPME is active at any given time.
There are a number of implications to this approach: There are a number of implications to this approach:
1) The PST would use the uniform model of TC code point copying 1) The SPME would use the uniform model of TC code point copying
between sub-layers for diffserv such that the E2E markings between sub-layers for diffserv such that the E2E markings
and PHB treatment for the transport path was preserved by the and PHB treatment for the transport path was preserved by the
PST. SPMEs.
2) The PST would use the pipe model for TTL handling such that 2) The SPME normally would use the short-pipe model for TTL
MIP addressing for the E2E entity would be not be impacted by handling [6] such that MIP addressing for the E2E entity
the presence of the PST. would be not be impacted by the presence of the SPME, but it
should be possible for an operator to specify use of the
uniform model.
3) PM statistics need to be adjusted for the encapsulation 3) PM statistics need to be adjusted for the encapsulation
overhead of the additional PST sub-layer. overhead of the additional SPME sub-layer.
A PST is instantiated to create a MEG that monitors a path Note that points 1 an 2 above assume that the TTL copying mode
segment of a transport path (LSP or PW). The endpoints of the and TC copying modes are independently configurable for an LSP.
PST are MEPs and limit the scope of an OAM flow within the MEG
the MEPs belong to (i.e. within the domain of the PST that is
being monitored and managed).
The following properties apply to all MPLS-TP MEGs: There are specific issues with the use of the uniform model of
TTL copying for an SPME:
o They can be nested but not overlapped, e.g. a MEG may cover a 1. As any MIP in the SPME sub-layer is not part of the transport path
MEG, hence only an out of band return path would be available.
2. The instantiation of a lower level MEG or protection switching
actions within a lower level MEG may change the TTL distances to
MIPs in the higher level MEGs.
The endpoints of the SPME are MEPs and limit the scope of an OAM
flow within each MEG to the MEPs belong to (i.e. within the
domain of the SPME that is being monitored and managed).
When considering SPMEs, it is important to consider that the
following properties apply to all MPLS-TP MEGs:
o They can be nested but not overlapped, e.g. a MEG may cover a
segment or a concatenated segment of another MEG, and may segment or a concatenated segment of another MEG, and may
also include the forwarding engine(s) of the node(s) at the also include the forwarding engine(s) of the node(s) at the
edge(s) of the segment or concatenated segment. However when edge(s) of the segment or concatenated segment. However when
MEGs are nested, the MEPs and MIPs in the nested MEG are no MEGs are nested, the MEPs and MIPs in the nested MEG are no
longer part of the encompassing MEG. longer part of the encompassing MEG.
o It is possible that MEPs of nested MEGs reside on a single o It is possible that MEPs of nested MEGs reside on a single
node but again implemented in such a way that they do not node but again implemented in such a way that they do not
overlap. overlap.
o Each OAM flow is associated with a single Maintenance Entity o Each OAM flow is associated with a single MEG
Group.
o OAM packets that instrument a particular direction of a o OAM packets that instrument a particular direction of a
transport path are subject to the same forwarding treatment transport path are subject to the same forwarding treatment
(i.e. fate share) as the data traffic and in some cases may (i.e. fate share) as the data traffic and in some cases may
be required to have common queuing discipline E2E with the be required to have common queuing discipline E2E with the
class of traffic monitored. OAM packets can be distinguished class of traffic monitored. OAM packets can be distinguished
from the data traffic using the GAL and ACH constructs [6] from the data traffic using the GAL and ACH constructs [7]
for LSP and Section or the ACH construct [3]and [6] for for LSP and Section or the ACH construct [3]and [7] for
(MS-)PW. (MS-)PW.
o When a PST is instantiated after the transport path has been o When a SPME is instantiated after the transport path has been
instantiated the addressing of the MIPs will change. instantiated the addressing of the MIPs will change.
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 the context of an MPLS-TP LSP, only LERs can implement MEPs In the context of an MPLS-TP LSP, only LERs can implement MEPs
while in the context of a path segment tunnel (PST) LSRs for the while in the context of an SPME LSRs for the MPLS-TP LSP can be
MPLS-TP LSP can be LERs for PSTs that contribute to the overall LERs for SPMEs that contribute to the overall monitoring
monitoring infrastructure for the transport path. Regarding infrastructure for the transport path. Regarding PWs, only T-PEs
MPLS-TP PW, only T-PEs can implement MEPs while for PSTs can implement MEPs while for SPMEs supporting one or more PWs
supporting a PW both T-PEs and S-PEs can implement MEPs. In the both T-PEs and S-PEs can implement SPME MEPs. Any MPLS-TP LSR
context of MPLS-TP Section, any MPLS-TP LSR can implement a MEP can implement a MEP for an MPLS-TP Section.
for a serving (sub-)layer PST.
MEPs are responsible for activating and controlling all of the MEPs are responsible for activating and controlling all of the
proactive and on demand monitoring OAM functionality for the proactive and on-demand monitoring OAM functionality for the
MEG. There is a separate class of server layer originated MEG. There is a separate class of notifications (such as LKR and
notifications (such as LKR and AIS) that are originated by AIS) that are originated by intermediate nodes and triggered by
intermediate nodes. A MEP is capable of originating and server layer events. A MEP is capable of originating and
terminating OAM messages for fault management and performance terminating OAM messages for fault management and performance
monitoring. These OAM messages are encapsulated into an OAM monitoring. These OAM messages are encapsulated into an OAM
packet using the G-ACh as defined in RFC 5586 [6]: in this case packet using the G-ACh as defined in RFC 5586 [7]. In this case
the G-ACh message is an OAM message and the channel type the G-ACh message is an OAM message and the channel type
indicates an OAM message. A MEP terminates all the OAM packets indicates an OAM message. A MEP terminates all the OAM packets
it receives from the MEG it belongs to. The MEG the OAM packet it receives from the MEG it belongs to and silently discards
belongs to is inferred from the MPLS or PW label or, in case of those that do not (note in the case of a mis-connectivity defect
MPLS-TP section, the MPLS-TP port the OAM packet has been there are further actions taken). The MEG the OAM packet belongs
received with the GAL at the top of the label stack. to is inferred from the MPLS or PW label or, in case of an
MPLS-TP section, the MEG is inferred from the port on which an
OAM packet was received with the GAL at the top of the label
stack.
OAM packets may require the use of an available "out-of-band" OAM packets may require the use of an available "out-of-band"
return path (as defined in [5]). In such cases sufficient return path (as defined in [8]). In such cases sufficient
information is required in the originating transaction such that information is required in the originating transaction such that
the OAM reply packet can be constructed (e.g. IP address). the OAM reply packet can be constructed (e.g. IP address).
Each OAM solution will further detail its applicability as a Each OAM solution will further detail its applicability as a
pro-active or on-demand measurement as well as its usage when: pro-active or on-demand mechanism as well as 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 OAM functions to use on the MEG but the MEPs are proactive OAM functions to use on the MEG but the MEPs are
always enabled. A node at the edge of a MEG always supports a always enabled. A node at the edge of a MEG always supports a
MEP. MEP.
MEPs terminate all OAM packets received from the associated MEG. MEPs terminate all OAM packets received from the associated MEG.
As the MEP corresponds to the termination of the forwarding path As the MEP corresponds to the termination of the forwarding path
for a MEG at the given (sub-)layer, OAM packets never leak for a MEG at the given (sub-)layer, OAM packets never leak
outside of a MEG in a properly configured fault free outside of a MEG 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 (e.g. based on packet counts) in an end-to-end degradation (e.g. based on packet counts) in an end-to-end
scope. Note that both MEP source and MEP sink coincide with scope. Note that both MEP source and MEP sink coincide with
transport paths' source and sink terminations. transport paths' source and sink terminations.
The MEPs of a path segment tunnel are not necessarily coincident The MEPs of an SPME are not necessarily coincident with the
with the termination of the MPLS-TP transport path and monitor a termination of the MPLS-TP transport path and monitor a path
path segment of the transport path for failures or performance segment of the transport path for failures or performance
degradation (e.g. based on packet counts) only within the degradation (e.g. based on packet counts) only within the
boundary of the MEG for the path segment tunnel. boundary of the MEG for the SPME.
An MPLS-TP MEP sink passes a fault indication to its client An MPLS-TP MEP sink 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.
A node at the edge of a MEG can either support per-node MEP or A node at the edge of a MEG can either support per-node MEP or
per-interface MEP(s). A per-node MEP resides in an unspecified per-interface MEP(s). A per-node MEP resides in an unspecified
location within the node while a per-interface MEP resides on a location within the node while a per-interface MEP resides on a
specific side of the forwarding engine. In particular a per- specific side of the forwarding engine. In particular a per-
interface MEP is called "Up MEP" or "Down MEP" depending on its interface MEP is called "Up MEP" or "Down MEP" depending on its
location relative to the forwarding engine. location relative to the forwarding engine.
Source node Destination node Source node Destination node
------------------------ ------------------------ ------------------------ ------------------------
| | | | | | | |
|----- -----| |----- -----| |----- -----| |----- -----|
| 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 |
|----- -----| |----- -----| |----- -----| |----- -----|
| | | | | | | |
------------------------ ------------------------ ------------------------ ------------------------
(1) (2) (1) (2)
Figure 3 Example of per-interface Up MEPs Figure 3 Example of per-interface Up MEPs
Figure 3 describes two examples of per-interface Up MEPs: an Up Figure 3 describes two examples of per-interface Up MEPs: An Up
Source MEP in a source node (case 1) and an Up Sink MEP in a Source MEP in a source node (case 1) and an Up Sink MEP in a
destination node (case 2). destination node (case 2).
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 both fault and performance monitoring closer to the edge ME for both fault and performance monitoring closer to the edge
of the domain and allows the isolation of failures or of the domain and allows the isolation of failures or
performance degradation to being within a node or either the performance degradation to being within a node or either the
link or interfaces. link or interfaces.
Each OAM solution will further detail the implications when used Each OAM solution will further detail the implications when used
with per-interface or per-node MEPs, if necessary. with per-interface or per-node MEPs, if necessary.
It may occur that the Up MEPs of a path segment tunnel are set It may occur that the Up MEPs of an SPME are set on both sides
on both sides of the forwarding engine such that the MEG is of the forwarding engine such that the MEG is entirely internal
entirely internal to the node. to the node.
It should be noted that a ME may span nodes that implement per
node MEPs and per-interface MEPs. This guarantees backward
compatibility with most of the existing LSRs that can implement
only a per-node MEP as in current implementations label
operations are largely performed on the ingress interface, hence
the exposure of the GAL as top label will occur at the ingress
interface.
Note that a MEP can only exist at the beginning and end of a 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 of that LSP or PW, a new sub-layer in the form of a path portion of that LSP or PW, a new sub-layer in the form of an
segment tunnel is created which permits MEPs and an associated SPME is created which permits MEPs and associated MEGs to be
MEG to be created. created.
In the case where an intermediate node sends a message to a MEP, In the case where an intermediate node sends a message to a 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 PST. between the MEPs of a MEG for a PW, LSP or SPME.
A MIP is capable of reacting to some OAM packets and forwarding A MIP is capable of reacting to some OAM packets and forwarding all
all the other OAM packets while ensuring fate sharing with data the other OAM packets while ensuring fate sharing with data plane
plane packets. However, a MIP does not initiate unsolicited OAM packets. However, a MIP does not initiate unsolicited OAM packets,
packets, but may be addressed by OAM packets initiated by one of but may be addressed by OAM packets initiated by one of the MEPs of
the MEPs of the MEG. A MIP can generate OAM packets only in the MEG. A MIP can generate OAM packets only in response to OAM
response to OAM packets that are sent on the MEG it belongs to. packets that are sent on the MEG it belongs to. The OAM messages
generated by the MIP are sent in the direction of the source MEP and
not forwarded to the sink 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 MIP (i.e. a single MIP per node in an
unspecified location within the node); unspecified location within the node);
o support per-interface MIP (i.e. two or more MIPs per node on o Support per-interface MIP (i.e. two or more MIPs per node on
both sides of the forwarding engine). both sides of the forwarding engine).
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 The usage of per-interface MIPs allows the isolation of failures
or performance degradation to being within a node or either the or performance degradation to being within a node or either the
link or interfaces. link or interfaces.
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 TTL field to indicate the number of hops necessary to reach the TTL field to indicate the number of hops necessary to reach
the node where the MIP resides. It is always assumed that the the node where the MIP resides. It is always assumed that the
"pipe"/"short pipe" model of TTL handling is used by the MPLS "short pipe" model of TTL handling is used by the MPLS transport
transport profile. profile.
The source MEP should also include Target MIP information in the The source MEP should also include Target MIP information in the
OAM packets sent to a MIP to allow proper identification of the OAM packets sent to a MIP to allow proper identification of the
MIP within the node. The MEG the OAM packet is associated with MIP within the node. The MEG the OAM packet is associated with
is inferred from the MPLS label. is inferred from the MPLS label.
A node at the edge of a MEG can also support per-interface Up A node at the edge of a MEG can also support per-interface Up
MEPs and per-interface MIPs on either side of the forwarding MEPs and per-interface MIPs on either side of the forwarding
engine. engine.
skipping to change at page 17, line 20 skipping to change at page 19, line 5
MIPs on the nodes within the MEG. All the intermediate nodes and MIPs on the nodes within the MEG. All the intermediate nodes and
possibly the end nodes host MIP(s). Local policy allows them to possibly the end nodes host MIP(s). Local policy allows them to
be enabled per function and per MEG. The local policy is be enabled per function and per MEG. The local policy is
controlled by the management system, which may delegate it to controlled by the management system, which may delegate it to
the control plane. the control plane.
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 sub- "below" which is to say encapsulates and transports the sub-
layer being referenced. layer 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) (sub-)layer network. (MPLS-TP) (sub-)layer network.
A server MEP also interacts with the client/server adaptation A server MEP also interacts with the client/server adaptation
function between the client (MPLS-TP) (sub-)layer network and function between the client (MPLS-TP) (sub-)layer network and
the server (sub-)layer network. The adaptation function the server (sub-)layer network. The adaptation function
maintains state on the mapping of MPLS-TP transport paths that maintains state on the mapping of MPLS-TP transport paths that
are setup over that server (sub-)layer's transport path. are setup over that server (sub-)layer's transport path.
For example, a server MEP can be either: For example, a server MEP can be either:
o A termination point of a physical link (e.g. 802.3), an SDH 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 VC or OTN ODU, for the MPLS-TP Section layer network, defined
in section 4.1; in section 4.1;
o An MPLS-TP Section MEP for MPLS-TP LSPs, defined in section o An MPLS-TP Section MEP for MPLS-TP LSPs, defined in section
4.2; 4.2;
o An MPLS-TP LSP MEP for MPLS-TP PWs, defined in section 4.3; o An MPLS-TP LSP MEP for MPLS-TP PWs, defined in section 4.3;
o An MPLS-TP PST MEP used for LSP path segment monitoring, as o An MPLS-TP SPME MEP used for LSP path segment monitoring, as
defined in section 4.4, for MPLS-TP LSPs or higher-level PSTs defined in section 4.4, for MPLS-TP LSPs or higher-level
providing LSP path segment monitoring; SPMEs providing LSP path segment monitoring;
o An MPLS-TP PST 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 PSTs 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 The server MEP can run appropriate OAM functions for fault
detection within the server (sub-)layer network, and provides a detection within the server (sub-)layer network, and provides a
fault indication to its client MPLS-TP layer network. Server MEP fault indication to its client MPLS-TP layer network. Server MEP
OAM functions are outside the scope of this document. OAM functions are outside the scope of this document.
3.6. Configuration Considerations 3.6. Configuration Considerations
When a control plane is not present, the management plane When a control plane is not present, the management plane
configures these functional components. Otherwise they can be configures these functional components. Otherwise they can be
configured either by the management plane or by the control configured either by the management plane or by the control
plane. plane.
Local policy allows to disable the usage of any available "out- Local policy allows disabling the usage of any available "out-
of-band" return path, as defined in [5], to generate OAM reply of-band" return path, as defined in [8], irrespective of what is
packets, irrespectively on what is requested by the node requested by the node originating the OAM packet.
originating the OAM packet triggering the request.
PSTs are usually instantiated when the transport path is created SPMEs are usually instantiated when the transport path is
by either the management plane or by the control plane (if created by either the management plane or by the control plane
present). Sometimes PST can be instantiated after the transport (if present). Sometimes an SPME can be instantiated after the
path is initially created (e.g. PST). transport path is 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 the leaves. As a consequence: all 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 single OAM packet that will be delivered by the send a single OAM packet that will be delivered by the
forwarding plane to all the leaves and processed by all the forwarding plane to all the leaves and processed by all the
leaves. leaves.
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 single OAM packet that will be delivered by the sends a single OAM packet that will be delivered by the
forwarding plane to all the leaves but contains sufficient forwarding plane to all the leaves but contains sufficient
information to identify a target leaf, and therefore is information to identify a target leaf, and therefore is
processed only by the target leaf and ignored by the other processed only by the target leaf and ignored 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 single OAM packet with the TTL field indicating the a single OAM packet with the TTL field indicating the
number of hops necessary to reach the node where the MIP number of hops necessary to reach the node where the MIP
resides. This packet will be delivered by the forwarding resides. This packet will be delivered by the forwarding
plane to all intermediate nodes at the same TTL distance of plane to all intermediate nodes at the same TTL distance of
the target MIP and to any leaf that is located at a shorter the target MIP and to any leaf that is located at a shorter
distance. The OAM message must contain sufficient distance. The OAM message must contain sufficient
information to identify the target MIP and therefore is information to identify the target MIP and therefore is
processed only by the target MIP. The source MEP should processed only by the target MIP.
also include Target MIP information in the OAM packet to
allow proper identification of the node and the MIP the OAM
packet is addressed to.
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 the leaves), the source MEP sends M different OAM of all the leaves), the source MEP sends M different OAM
packets targeted to each individual leaf in the group of M packets targeted to each individual leaf in the group of M
leaves. Better mechanisms are outside the scope of this leaves. Aggregated or subsetting mechanisms are outside the
document. scope of this document.
P2MP paths are unidirectional, therefore any return path to a P2MP paths are unidirectional, therefore any return path to a
source MEP for on demand transactions will be out of band. A source MEP for on-demand transactions will be out-of-band. A
mechanism to scope the set of MEPs or MIPs expected to respond mechanism to scope the set of MEPs or MIPs expected to respond
to a given "on demand" transaction is useful as it relieves the to a given "on-demand" transaction is useful as it relieves the
source MEP of the requirement to filter and discard undesired source MEP of the requirement to filter and discard undesired
responses as normally TTL exhaust will address all MIPs at a responses as normally TTL exhaustion will address all MIPs at a
given distance from the source, and failure to exhaust TTL will given distance from the source, and failure to exhaust TTL will
address all MEPs. address all MEPs.
4. Reference Model 4. Reference Model
The reference model for the MPLS-TP framework builds upon the The reference model for the MPLS-TP framework builds upon the
concept of a MEG, and its associated MEPs and MIPs, to support concept of a MEG, and its associated MEPs and MIPs, to support
the functional requirements specified in [8]. the functional requirements specified in RFC 5860 [10].
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 (SME), allowing monitoring o A Section Maintenance Entity Group (SME), allowing monitoring
and management of MPLS-TP Sections (between MPLS LSRs). and management of MPLS-TP Sections (between MPLS LSRs).
o An LSP Maintenance Entity Group (LME), allowing monitoring o An LSP Maintenance Entity Group (LME), allowing monitoring
and management of an end-to-end LSP (between LERs). and management of an end-to-end LSP (between LERs).
o A PW Maintenance Entity Group (PME), allowing monitoring and o A PW Maintenance Entity Group (PME), allowing monitoring and
management of an end-to-end SS/MS-PWs (between T-PEs). management of an end-to-end SS/MS-PWs (between T-PEs).
o An LSP Path Segment Tunnel ME Group (LPSTME), allowing o An LSP SPME ME Group (LSMEG), allowing monitoring and
monitoring and management of a path segment tunnel (between management of an SPME (between any LERs/LSRs along an LSP).
any LERs/LSRs along an LSP).
o A PW Path Segment Tunnel ME Group (PPSTME), allowing o A PW SPME ME Group (PSMEG), allowing monitoring and
monitoring and management of an MPLS-TP path segment tunnel management of an SPME (between any T-PEs/S-PEs along the
(between any T-PEs/S-PEs along the (MS-)PW). (MS-)PW).
The MEGs specified in this MPLS-TP framework are compliant with The MEGs specified in this MPLS-TP framework are compliant with
the architecture framework for MPLS-TP MS-PWs [4] and LSPs [1]. the architecture framework for MPLS-TP MS-PWs [4] and LSPs [1].
Hierarchical LSPs are also supported in the form of path segment Hierarchical LSPs are also supported in the form of SPMEs. In
tunnels. In this case, each LSP in the hierarchy is a different this case, each LSP in the hierarchy is a different sub-layer
sub-layer network that can be monitored, independently from network that can be monitored, independently from higher and
higher and lower level LSPs in the hierarchy, on an end-to-end lower level LSPs in the hierarchy, on an end-to-end basis (from
basis (from LER to LER) by a PSTME. It is possible to monitor a LER to LER) by a SPME. It is possible to monitor a portion of a
portion of a hierarchical LSP by instantiating a hierarchical hierarchical LSP by instantiating a hierarchical SPME between
PSTME between any LERs/LSRs along the hierarchical LSP. any LERs/LSRs along the 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 LSP V V LSP V V LSP V V (AC2) (AC1) V V LSP V V LSP V V LSP V V (AC2)
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
+----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+
| | | |=========| |=========| |=========| | | | | | | |=======| |=========| |=======| | | |
| CE1|---|........PW13.......|...PW3X..|........PWXZ.......|---|CE2 | | CE1|--|.......PW13......|...PW3X..|......PWXZ.......|---|CE2 |
| | | |=========| |=========| |=========| | | | | | | |=======| |=========| |=======| | | |
+----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
. . . . . . . .
| | | | | | | |
|<---- Domain 1 --->| |<---- Domain Z --->| |<--- Domain 1 -->| |<--- Domain Z -->|
^------------------- PW1Z PME -------------------^ ^----------------- PW1Z PME -----------------^
^---- PW13 PPSTME---^ ^---- PWXZ PPSTME---^ ^--- PW13 PSME ---^ ^--- PWXZ PSME ---^
^---------^ ^---------^ ^-------^ ^-------^
LSP13 LME LSPXZ LME LSP13 LME LSPXZ LME
^---^ ^---^ ^---------^ ^---^ ^---^ ^--^ ^--^ ^---------^ ^--^ ^--^
Sec12 Sec23 Sec3X SecXY SecYZ Sec12 Sec23 Sec3X SecXY SecYZ
SME SME SME SME SME SME SME SME SME SME
TPE1: Terminating Provider Edge 1 SPE2: Switching Provider Edge 3 TPE1: Terminating Provider Edge 1 SPE2: Switching Provider Edge
TPEX: Terminating Provider Edge X SPEZ: Switching Provider Edge Z 3
TPEX: Terminating Provider Edge X SPEZ: Switching Provider Edge
Z
^---^ ME ^ MEP ==== LSP .... PW ^---^ ME ^ MEP ==== LSP .... PW
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 framework. The figure depicts portions of two MPLS-TP OAM framework. The figure depicts portions of two MPLS-TP
enabled network domains, Domain 1 and Domain Z. In Domain 1, enabled network domains, Domain 1 and Domain Z. In Domain 1,
LSR1 is adjacent to LSR2 via the MPLS Section Sec12 and LSR2 is LSR1 is adjacent to LSR2 via the MPLS-TP Section Sec12 and LSR2
adjacent to LSR3 via the MPLS Section Sec23. Similarly, in is adjacent to LSR3 via the MPLS-TP Section Sec23. Similarly, in
Domain Z, LSRX is adjacent to LSRY via the MPLS Section SecXY Domain Z, LSRX is adjacent to LSRY via the MPLS-TP Section SecXY
and LSRY is adjacent to LSRZ via the MPLS Section SecYZ. In and LSRY is adjacent to LSRZ via the MPLS-TP Section SecYZ. In
addition, LSR3 is adjacent to LSRX via the MPLS Section 3X. addition, LSR3 is adjacent to LSRX via the MPLS-TP Section 3X.
Figure 5 also shows a bi-directional MS-PW (PW1Z) between AC1 on Figure 5 also shows a bi-directional MS-PW (PW1Z) between AC1 on
TPE1 and AC2 on TPEZ. The MS-PW consists of three bi-directional TPE1 and AC2 on TPEZ. The MS-PW consists of three bi-directional
PW path segments: 1) PW13 path segment between T-PE1 and S-PE3 PW path segments: 1) PW13 path segment between T-PE1 and S-PE3
via the bi-directional LSP13 LSP, 2) PW3X path segment between via the bi-directional LSP13 LSP, 2) PW3X path segment between
S-PE3 and S-PEX, via the bi-directional LSP3X LSP, and 3) PWXZ S-PE3 and S-PEX, via the bi-directional LSP3X LSP, and 3) PWXZ
path segment between S-PEX and T-PEZ via the bi-directional path segment between S-PEX and T-PEZ via the bi-directional
LSPXZ LSP. 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 not preclude that multiple MEGs may be affected does not preclude that multiple MEGs may be affected
simultaneously by the same network condition, for example, a simultaneously by the 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 constrains imposed by this OAM framework
on the number, or type (p2p, p2mp, LSP or PW), of MEGs that may on the number, or type (p2p, p2mp, LSP or PW), of MEGs that may
be instantiated on a particular node. In particular, when be instantiated on a particular node. In particular, when
looking at Figure 3, it should be possible to configure one or looking at Figure 5, it should be possible to configure one or
more MEPs on the same node if that node is the endpoint of one more MEPs on the same node if that node is the endpoint of one
or more MEGs. or more MEGs.
Figure 5 does not describe a PW3X PPSTME because typically PSTs Figure 5 does not describe a PW3X PSME because typically SPMEs
are used to monitor an OAM domain (like PW13 and PWXZ PPSTMEs) are used to monitor an OAM domain (like PW13 and PWXZ PSMEs)
rather than the segment between two OAM domains. However the OAM rather than the segment between two OAM domains. However the OAM
framework does not pose any constraints on the way PSTs are framework does not pose any constraints on the way SPMEs are
instantiated as long as they are not overlapping. instantiated as long as 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 architecture framework document. Unless otherwise stated, OAM architecture framework document. Unless otherwise stated,
all references to domains, LSRs, MPLS Sections, LSPs, all references to domains, LSRs, MPLS-TP Sections, LSPs,
pseudowires and MEGs in this section are made in relation to pseudowires and 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 (SME) 4.1. MPLS-TP Section Monitoring (SME)
An MPLS-TP Section ME (SME) is an MPLS-TP maintenance entity An MPLS-TP Section ME (SME) is an MPLS-TP maintenance entity
intended to an MPLS Section as defined in [5]. An SME may be intended to monitor an MPLS-TP Section as defined in RFC 5654
configured on any MPLS section. SME OAM packets must fate share [5]. An SME may be configured on any MPLS-TP section. SME OAM
with the user data packets sent over the monitored MPLS Section. packets must fate share with the user data packets sent over the
monitored MPLS-TP Section.
An SME is intended to be deployed for applications where it is An SME 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 hop in this layer network) MPLS (and MPLS-TP enabled) LSRs (next hop in this layer network) MPLS-TP LSRs rather than
rather than monitoring the individual LSP or PW path segments monitoring the individual LSP or PW path segments traversing the
traversing the MPLS Section and the server layer technology does MPLS-TP Section and the server layer technology does not provide
not provide adequate OAM capabilities. adequate OAM capabilities.
Figure 5 shows 5 Section MEs configured in the network between Figure 5 shows five Section MEs configured in the network
AC1 and AC2: between AC1 and AC2:
1. Sec12 ME associated with the MPLS Section between LSR 1 and 1. Sec12 ME associated with the MPLS-TP Section between LSR 1
LSR 2, and LSR 2,
2. Sec23 ME associated with the MPLS Section between LSR 2 and 2. Sec23 ME associated with the MPLS-TP Section between LSR 2
LSR 3, and LSR 3,
3. Sec3X ME associated with the MPLS Section between LSR 3 and 3. Sec3X ME associated with the MPLS-TP Section between LSR 3
LSR X, and LSR X,
4. SecXY ME associated with the MPLS Section between LSR X and 4. SecXY ME associated with the MPLS-TP Section between LSR X
LSR Y, and and LSR Y, and
5. SecYZ ME associated with the MPLS Section between LSR Y and 5. SecYZ ME associated with the MPLS-TP Section between LSR Y
LSR Z. and LSR Z.
4.2. MPLS-TP LSP End-to-End Monitoring (LME) 4.2. MPLS-TP LSP End-to-End Monitoring (LME)
An MPLS-TP LSP ME (LME) is an MPLS-TP maintenance entity An MPLS-TP LSP ME (LME) is an MPLS-TP maintenance entity
intended to monitor an end-to-end LSP between two LERs. An LME intended to monitor an end-to-end LSP between two LERs. An LME
may be configured on any MPLS LSP. LME OAM packets must fate may be configured on any MPLS LSP. LME OAM packets must fate
share with user data packets sent over the monitored MPLS-TP share with user data packets sent over the monitored MPLS-TP
LSP. LSP.
An LME is intended to be deployed in scenarios where it is An LME is intended to be deployed in scenarios where it is
desirable to monitor an entire LSP between its LERs, rather desirable to monitor an entire LSP between its LERs, rather
than, say, monitoring individual PWs. than, say, monitoring individual PWs.
Figure 5 depicts 2 LMEs configured in the network between AC1 Figure 5 depicts two LMEs configured in the network between AC1
and AC2: 1) the LSP13 LME between LER 1 and LER 3, and 2) the and AC2: 1) the LSP13 LME between LER 1 and LER 3, and 2) the
LSPXZ LME between LER X and LER Y. Note that the presence of a LSPXZ LME between LER X and LER Y. Note that the presence of a
LSP3X LME in such a configuration is optional, hence, not LSP3X LME in such a configuration is optional, hence, not
precluded by this framework. For instance, the SPs may prefer to precluded by this framework. For instance, the SPs 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 (PME) 4.3. MPLS-TP PW Monitoring (PME)
An MPLS-TP PW ME (PME) is an MPLS-TP maintenance entity intended An MPLS-TP PW ME (PME) is an MPLS-TP maintenance entity intended
to monitor a SS-PW or MS-PW between a pair of T-PEs. A PME can to monitor a SS-PW or MS-PW between a pair of T-PEs. A PME can
be configured on any SS-PW or MS-PW. PME OAM packets must fate be configured on any SS-PW or MS-PW. PME OAM packets must fate
share with the user data packets sent over the monitored PW. share with the user data packets sent over the monitored PW.
A PME is intended to be deployed in scenarios where it is A PME is intended to be deployed in scenarios where it is
desirable to monitor an entire PW between a pair of MPLS-TP desirable to monitor an entire PW between a pair of MPLS-TP
enabled T-PEs rather than monitoring the LSP aggregating enabled T-PEs rather than monitoring the LSP aggregating
multiple PWs between PEs. multiple PWs between PEs.
|<------------------- MS-PW1Z ------------------->| |<----------------- MS-PW1Z ----------------->|
| | | |
| |<-LSP13->| |<-LSP3X->| |<-LSPXZ->| | | |<LSP13>| |<-LSP3X->| |<LSPXZ>| |
V V LSP V V LSP V V LSP V V V V LSP V V LSP V V LSP V V
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
+----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ +---+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +---+
| |AC1| |=========| |=========| |=========| |AC2| | | |AC1| |=======| |=========| |=======| |AC2| |
| CE1|---|........PW13.......|...PW3X..|........PWXZ.......|---|CE2 | |CE1|---|.......PW13......|...PW3X..|.......PWXZ......|---|CE2|
| | | |=========| |=========| |=========| | | | | | | |=======| |=========| |=======| | | |
+----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ +---+ | 1 | |2| | 3 | | X | |Y| | Z | +---+
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
^-------------------PW1Z PME------------------^
^---------------------PW1Z PME--------------------^
Figure 6 MPLS-TP PW ME (PME) Figure 6 MPLS-TP PW ME (PME)
Figure 6 depicts a MS-PW (MS-PW1Z) consisting of three path Figure 6 depicts a MS-PW (MS-PW1Z) consisting of three path
segments: PW13, PW3X and PWXZ and its associated end-to-end PME segments: PW13, PW3X and PWXZ and its associated end-to-end PME
(PW1Z PME). (PW1Z PME).
4.4. MPLS-TP LSP Path Segment Tunnel Monitoring (LPSTME) 4.4. MPLS-TP LSP SPME Monitoring (LSME)
An MPLS-TP LSP Path Segment Tunnel ME (LPSTME) is an MPLS-TP LSP An MPLS-TP LSP SPME ME (LSME) is an MPLS-TP LSP with associated
with associated maintenance entity intended to monitor an maintenance entity intended to monitor an arbitrary part of an
arbitrary part of an LSP between the pair of MEPs instantiated LSP between the pair of MEPs instantiated for the SPME
for the PST independent from the end-to-end monitoring (LME). An independent from the end-to-end monitoring (LME). An LSME can
LPSTMEE can monitor an LSP segment or concatenated segment and monitor an LSP segment or concatenated segment and it may also
it may also include the forwarding engine(s) of the node(s) at include the forwarding engine(s) of the node(s) at the edge(s)
the edge(s) of the segment or concatenated segment. of the segment or concatenated segment.
Multiple LPSTMEs can be configured on any LSP. The LSRs that Multiple LSMEs can be configured on any LSP. The LSRs that
terminate the LPSTME may or may not be immediately adjacent at terminate the LSME may or may not be immediately adjacent at the
the MPLS-TP layer. LPSTME OAM packets must fate share with the MPLS-TP layer. LSME OAM packets must fate share with the user
user data packets sent over the monitored LSP path segment. data packets sent over the monitored LSP path segment.
A LPSTME can be defined between the following entities: A LSME can be defined between the following entities:
o The end node and any intermediate node of a given LSP. o The end node and any intermediate node of a given LSP.
o Any two intermediate nodes of a given LSP. o Any two intermediate nodes of a given LSP.
An LPSTME is intended to be deployed in scenarios where it is An LSME is intended to be deployed in scenarios where it is
preferable to monitor the behaviour of a part of an LSP or set preferable to monitor the behaviour of a part of an LSP or set
of LSPs rather than the entire LSP itself, for example when of LSPs rather than the entire LSP itself, for example when
there is a need to monitor a part of an LSP that extends beyond there is a need to monitor a part of an LSP that extends beyond
the administrative boundaries of an MPLS-TP enabled the administrative boundaries of an MPLS-TP enabled
administrative domain. administrative domain.
|<--------------------- PW1Z -------------------->| |<-------------------- PW1Z ------------------->|
| | | |
| |<--------------LSP1Z LSP-------------->| | | |<-------------LSP1Z LSP------------->| |
| |<-LSP13->| |<-LSP3X->| |<-LSPXZ->| | | |<-LSP13->| |<LSP3X>| |<-LSPXZ->| |
V V S-LSP V V S-LSP V V S-LSP V V V V S-LSP V V S-LSP V V S-LSP V V
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
+----+ | PE1| | | |DBN3| |DBNX| | | | PEZ| +----+ +----+ | PE1| | | |DBN3| |DBNX| | | | PEZ| +----+
| |AC1| |=======================================| |AC2| | | |AC1| |=====================================| |AC2| |
| CE1|---|......................PW1Z.......................|---|CE2 | | CE1|---|.....................PW1Z......................|---|CE2 |
| | | |=======================================| | | | | | | |=====================================| | | |
+----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
. . . . . . . .
| | | | | | | |
|<---- Domain 1 --->| |<---- Domain Z --->| |<---- Domain 1 --->| |<---- Domain Z --->|
^---------^ ^---------^ ^---------^ ^---------^
LSP13 LPSTME LSPXZ LPSTME LSP13 LSME LSPXZ LSME
^---------------------------------------^ ^-------------------------------------^
LSP1Z LME LSP1Z LME
DBN: Domain Border Node DBN: Domain Border Node
Figure 7 MPLS-TP LSP Path Segment Tunnel ME (LPSTME) Figure 7 MPLS-TP LSP SPME ME (LSME)
Figure 7 depicts a variation of the reference model in Figure 5 Figure 7 depicts a variation of the reference model in Figure 5
where there is an end-to-end LSP (LSP1Z) between PE1 and PEZ. where there is an end-to-end LSP (LSP1Z) between PE1 and PEZ.
LSP1Z consists of, at least, three LSP Concatenated Segments: LSP1Z consists of, at least, three LSP Concatenated Segments:
LSP13, LSP3X and LSPXZ. In this scenario there are two separate LSP13, LSP3X and LSPXZ. In this scenario there are two separate
LPSTMEs configured to monitor the LSP1Z: 1) a LPSTME monitoring LSMEs configured to monitor the LSP1Z: 1) a LSME monitoring the
the LSP13 Concatenated Segment on Domain 1 (LSP13 LPSTME), and LSP13 Concatenated Segment on Domain 1 (LSP13 LSME), and 2) a
2) a LPSTME monitoring the LSPXZ Concatenated Segment on Domain LSME monitoring the LSPXZ Concatenated Segment on Domain Z
Z (LSPXZ LPSTME). (LSPXZ LSME).
It is worth noticing that LPSTMEs can coexist with the LME It is worth noticing that LSMEs can coexist with the LME
monitoring the end-to-end LSP and that LPSTME MEPs and LME MEPs monitoring the end-to-end LSP and that LSME MEPs and LME MEPs
can be coincident in the same node (e.g. PE1 node supports both can be coincident in the same node (e.g. PE1 node supports both
the LSP1Z LME MEP and the LSP13 LPSTME MEP). the LSP1Z LME MEP and the LSP13 LSME MEP).
4.5. MPLS-TP MS-PW Path Segment Tunnel Monitoring (PPSTME) 4.5. MPLS-TP MS-PW SPME Monitoring (PSME)
An MPLS-TP MS-PW Path Segment Tunnel Monitoring ME (PPSTME) is An MPLS-TP MS-PW SPME Monitoring ME (PSME) is an MPLS-TP
an MPLS-TP maintenance entity intended to monitor an arbitrary maintenance entity intended to monitor an arbitrary part of an
part of an MS-PW between a given pair of PEs independently from MS-PW between a given pair of PEs independently from the end-to-
the end-to-end monitoring (PME). A PPSTME can monitor a PW end monitoring (PME). A PSME can monitor a PW segment or
segment or concatenated segment and it may also include the concatenated segment and it 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 segment or
segment or concatenated segment. concatenated segment.
S-PE placement is typically dictated by considerations other S-PE placement is typically dictated by considerations other
than OAM. S-PEs will frequently reside at operational boundaries than OAM. S-PEs will frequently reside at operational boundaries
such as the transition from distributed (CP) to centralized such as the transition from distributed (CP) to centralized
(NMS) control or at a routing area boundary. As such the (NMS) control or at a routing area boundary. As such the
architecture would superficially appear not to have the architecture would superficially appear not to have the
flexibility that arbitrary placement of PST segments would flexibility that arbitrary placement of SPME segments would
imply. More arbitrary placement of MEs for a PW would require imply. More arbitrary placement of MEs for a PW would require
additional hierarchical components, beyond the PSTs between PEs additional hierarchical components, beyond the SPMEs between PEs
Multiple PPSTMEs can be configured on any MS-PW. The PEs may or Multiple PSMEs can be configured on any MS-PW. The PEs may or
may not be immediately adjacent at the MS-PW layer. PPSTME OAM may not be immediately adjacent at the MS-PW layer. PSME OAM
packets fate share with the user data packets sent over the packets fate share with the user data packets sent over the
monitored PW path Segment. monitored PW path Segment.
A PPSTME 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 T-PE and any S-PE of a given MS-PW
o Any two S-PEs of a given MS-PW. It can span several PW o Any two S-PEs of a given MS-PW. It can span several PW
segments. segments.
A PPSTME is intended to be deployed in scenarios where it is 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
addressing of the MIPs will change and MIPs in the nested MEG are no
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
level. The consequences are that the S-PEs hosting the PSME MEPs
become adjacent S-PEs.
A PSME is intended to be deployed in scenarios where it is
preferable to monitor the behaviour of a part of a MS-PW rather preferable to monitor the behaviour of a part of a MS-PW rather
than the entire end-to-end PW itself, for example to monitor an than the entire end-to-end PW itself, for example to monitor an
MS-PW path segment within a given network domain of an inter- MS-PW path segment within a given network domain of an inter-
domain MS-PW. domain MS-PW.
|<------------------- MS-PW1Z ------------------->| |<----------------- MS-PW1Z ----------------->|
| | | |
| |<-LSP13->| |<-LSP3X->| |<-LSPXZ->| | | |<LSP13>| |<-LSP3X->| |<LSPXZ>| |
V V LSP V V LSP V V LSP V V V V LSP V V LSP V V LSP V V
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
+----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ +---+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +---+
| |AC1| |=========| |=========| |=========| |AC2| | | |AC1| |=======| |=========| |=======| |AC2| |
| CE1|---|........PW13.......|...PW3X..|........PWXZ.......|---|CE2 | |CE1|---|.......PW13......|...PW3X..|.......PWXZ......|---|CE2|
| | | |=========| |=========| |=========| | | | | | | |=======| |=========| |=======| | | |
+----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ +---+ | 1 | |2| | 3 | | X | |Y| | Z | +---+
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
^---- PW1 PPSTME----^ ^---- PW5 PPSTME----^ ^--- PW1 PSME ----^ ^--- PW5 PSME ----^
^---------------------PW1Z PME--------------------^ ^-------------------PW1Z PME------------------^
Figure 8 MPLS-TP MS-PW Path Segment Tunnel Monitoring (PPSTME) Figure 8 MPLS-TP MS-PW SPME Monitoring (PSME)
Figure 8 depicts the same MS-PW (MS-PW1Z) between AC1 and AC2 as Figure 8 depicts the same MS-PW (MS-PW1Z) between AC1 and AC2 as
in Figure 6. In this scenario there are two separate PPSTMEs in Figure 6. In this scenario there are two separate PSMEs
configured to monitor MS-PW1Z: 1) a PPSTME monitoring the PW13 configured to monitor MS-PW1Z: 1) a PSME monitoring the PW13 MS-
MS-PW path segment on Domain 1 (PW13 PPSTME), and 2) a PPSTME PW path segment on Domain 1 (PW13 PSME), and 2) a PSME
monitoring the PWXZ MS-PW path segment on Domain Z with (PWXZ monitoring the PWXZ MS-PW path segment on Domain Z with (PWXZ
PPSTME). PSME).
It is worth noticing that PPSTMEs can coexist with the PME It is worth noticing that PSMEs can coexist with the PME
monitoring the end-to-end MS-PW and that PPSTME MEPs and PME monitoring the end-to-end MS-PW and that PSME MEPs and PME MEPs
MEPs can be coincident in the same node (e.g. TPE1 node supports can be coincident in the same node (e.g. TPE1 node supports both
both the PW1Z PME MEP and the PW13 PPSTME MEP). the PW1Z PME MEP and the PW13 PSME 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 be used in future deployments. These techniques continue to be used in future deployments. These techniques
include Ethernet Link Aggregations [14], the use of Link include Ethernet Link Aggregations [20], the use of Link
Bundling for MPLS [13] where the option to spread traffic over Bundling for MPLS [16] where the option to spread traffic over
component links is supported and enabled. While the use of Link component links is supported and enabled. While the use of Link
Bundling can be controlled at the MPLS-TP layer, use of Link Bundling can be controlled at the MPLS-TP layer, use of Link
Aggregation (or any server layer specific multilink) is not Aggregation (or any server layer specific multilink) is not
necessarily under control of the MPLS-TP layer. Other techniques necessarily under control of the MPLS-TP layer. Other techniques
may emerge in the future. These techniques share in common the may emerge in the future. These techniques share the
characteristic that an LSP may be spread over a set of component characteristic that an LSP may be spread over a set of component
links and therefore be reordered but no flow within the LSP is links and therefore be reordered but no flow within the LSP is
reordered (except when very infrequent and minimally disruptive reordered (except when very infrequent and minimally 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 particular deployment. If multilink techniques are used, in any particular deployment. If multilink techniques are used,
the deployment can be considered to be only partially MPLS-TP the deployment can be considered to be only partially MPLS-TP
compliant, however this is unlikely to prevent its use. compliant, however this is unlikely to prevent its use.
skipping to change at page 27, line 23 skipping to change at page 29, line 23
layer. The implications for reduced OAM loss measurement layer. The implications for reduced OAM loss measurement
functionality is documented in sections 5.5.3 and 6.2.3. functionality is documented in 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 are either configured to be carried out periodically and that are either configured to be carried out periodically and
continuously or preconfigured to act on certain events such as continuously or preconfigured to act on certain events such as
alarm signals. alarm signals.
Proactive monitoring is frequently "in-service" monitoring. The Proactive monitoring is usually performed "in-service". Such
control and measurement implications are: transactions are universally MEP to MEP in operation while
notifications emerging from the serving layer are MIP to MEP or
can be MIP to MIP. The control and measurement considerations
are:
1. Proactive monitoring for a MEG is typically configured at 1. Proactive monitoring for a MEG is typically configured at
transport path creation time. transport path creation time.
2. The operational characteristics of in-band measurement 2. The operational characteristics of in-band measurement
transactions (e.g., CV, LM etc.) are configured at the MEPs. transactions (e.g., CV, LM etc.) are configured at the MEPs.
3. Server layer events are reported by transactions originating 3. Server layer events are reported by transactions originating
at intermediate nodes. at intermediate nodes.
skipping to change at page 28, line 8 skipping to change at page 30, line 11
is statically configured; for dynamically established transport is statically configured; for dynamically established transport
paths the configuration information is signaled via the control paths the configuration information is signaled via the control
plane or configured via the management plane. plane or configured via the management plane.
The operator enables/disables some of the consequent actions The operator enables/disables 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 [8], are used to detect a loss of continuity defect 2.2.2 of RFC 5860 [10], are used to detect a loss of continuity
(LOC) between two MEPs in a MEG. defect (LOC) between two MEPs in a MEG.
Proactive Connectivity Verification functions, as required in Proactive Connectivity Verification functions, as required in
section 2.2.3 of [8], are used to detect an unexpected section 2.2.3 of RFC 5860 [10], are used to detect an unexpected
connectivity defect between two MEGs (e.g. mismerging or connectivity defect between two MEGs (e.g. mismerging or
misconnection), as well as unexpected connectivity within the misconnection), as well as unexpected connectivity within the
MEG with an unexpected MEP. MEG with an unexpected MEP.
Both functions are based on the (proactive) generation of OAM Both functions are based on the (proactive) generation of OAM
packets by the source MEP that are processed by the sink MEP. As packets by the source MEP that are processed by the sink MEP. As
a consequence these two functions are grouped together into a consequence these two functions are grouped together into
Continuity Check and Connectivity Verification (CC-V) OAM Continuity Check and Connectivity Verification (CC-V) OAM
packets. packets.
In order to perform pro-active Connectivity Verification In order to perform pro-active Connectivity Verification, each
function, each CC-V OAM packet also includes a globally unique CC-V OAM packet also includes a globally unique Source MEP
Source MEP identifier. When used to perform only pro-active identifier. When used to perform only pro-active Continuity
Continuity Check function, the CC-V OAM packet will not include Check, the CC-V OAM packet will not include any globally unique
any globally unique Source MEP identifier. Different formats of Source MEP identifier. Different formats of MEP identifiers are
MEP identifiers are defined in [7] to address different defined in [9] to address different environments. When MPLS-TP
environments. When MPLS-TP is deployed in transport network is deployed in transport network environments where IP
environments where IP addressing is not used in the forwarding addressing is not used in the forwarding plane, the ICC-based
plane, the ICC-based format for MEP identification is used. When format for MEP identification is used. When MPLS-TP is deployed
MPLS-TP is deployed in IP-based environment, the IP-based MEP in an IP-based environment, the IP-based MEP identification is
identification is used. used.
As a consequence, it is not possible to detect misconnections As a consequence, it is not possible to detect misconnections
between two MEGs monitored only for continuity as neither the between two MEGs monitored only for continuity as neither the
OAM message type nor OAM message content provides sufficient OAM message type nor OAM message content provides sufficient
information to disambiguate an invalid source. To expand: information to disambiguate an invalid source. To expand:
o For CC leaking into a CC monitored MEG - undetectable o For CC leaking into a CC monitored MEG - undetectable
o For CV leaking into a CC monitored MEG - presence of o For CV leaking into a CC monitored MEG - presence of
additional Source MEP identifier allows detecting the fault additional Source MEP identifier allows detecting the fault
o For CC leaking into a CV monitored MEG - lack of additional o For CC leaking into a CV monitored MEG - lack of additional
Source MEP identifier allows detecting the fault. Source MEP identifier allows detecting the fault.
o For CV leaking into a CV monitored MEG - different Source MEP o For CV leaking into a CV monitored MEG - different Source MEP
identifier permits fault to be identified. identifier permits fault to be identified.
CC-V OAM packets are transmitted at a regular, operator's CC-V OAM packets are transmitted at a regular, operator's
configurable, rate. The default CC-V transmission periods are configurable, rate. The default CC-V transmission periods are
application dependent (see section 5.1.3). application 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 probability PHB" within the transport path (LSP, PW) they loss probability PHB" within the transport path (LSP, PW) they
are monitoring. This PHB is configurable on network operator's are monitoring. This PHB is configurable on network operator's
basis. PHBs can be translated at the network borders by the same basis. PHBs can be translated at the network borders by the same
function that translates it for user data traffic. The function that translates it for user data traffic. The
implication is that CC-V fate shares with much of the forwarding implication is that CC-V fate shares with much of the forwarding
implementation, but not all aspects of PHB processing are implementation, but not all aspects of PHB processing are
exercised. Either on demand tools are used for finer grained exercised. Either on-demand tools are used for finer grained
fault finding or an implementation may utilize a CC-V flow per fault finding or an implementation may utilize a CC-V flow per
PHB with the entire E-LSP fate sharing with any individual PHB. PHB with the entire E-LSP fate sharing with any individual PHB.
In a bidirectional point-to-point transport path, when a MEP is In a bidirectional point-to-point transport path, when a MEP is
enabled to generate pro-active CC-V OAM packets with a enabled to generate pro-active CC-V OAM packets with a
configured transmission rate, it also expects to receive pro- configured transmission rate, it also expects to receive pro-
active CC-V OAM packets from its peer MEP at the same active CC-V OAM packets from its peer MEP at the same
transmission rate as a common SLA applies to all components of transmission rate as a common SLA applies to all components of
the transport path. In a unidirectional transport path (either the transport path. In a unidirectional transport path (either
point-to-point or point-to-multipoint), only the source MEP is point-to-point or point-to-multipoint), only the source MEP is
skipping to change at page 30, line 9 skipping to change at page 32, line 11
Pro-active CC-V functions allow a sink MEP to detect the defect Pro-active 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 sub-sections. For all of
the described defect cases, the sink MEP should notify the the described defect cases, the sink MEP should notify the
equipment fault management process of the detected defect. equipment fault management process of the detected defect.
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 pro-active CC-V
OAM packets from the peer MEP. OAM packets from the source MEP.
o Entry criteria: if no pro-active CC-V OAM packets from the o Entry criteria: If no pro-active CC-V OAM packets from the
peer MEP with the correct encapsulation (and in the case of source MEP with the correct encapsulation (and in the case of
CV, this includes the requirement to have a correct globally CV, this includes the requirement to have a correct globally
unique Source MEP identifier) are received within the unique Source MEP identifier) are received within the
interval equal to 3.5 times the receiving MEP's configured interval equal to 3.5 times the receiving MEP's configured
CC-V reception period. CC-V reception period.
o Exit criteria: a pro-active CC-V OAM packet from the peer MEP o Exit criteria: A pro-active CC-V OAM packet from the source
with the correct encapsulation (and again in the case of CV, MEP with the correct encapsulation (and again in the case of
with the correct globally unique Source MEP identifier) is CV, with the correct globally unique Source MEP identifier)
received. 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 pro-active CC-V OAM packet is received, a sink MEP
identifies a mis-connectivity defect (e.g. mismerge, identifies a mis-connectivity defect (e.g. mismerge,
misconnection or unintended looping) with its peer source MEP misconnection or unintended looping) when the received packet
when the received packet carries an incorrect globally unique carries an incorrect globally unique Source MEP identifier.
Source MEP identifier.
o Entry criteria: the sink MEP receives a pro-active CC-V OAM o Entry criteria: The sink MEP receives a pro-active CC-V OAM
packet with an incorrect globally unique Source MEP packet with an incorrect globally unique Source MEP
identifier. identifier or receives a CC or CC/CV OAM packet with an
unexpected encapsulation.
o Exit criteria: the sink MEP does not receive any pro-active It should be noted that there are practical limitations to
detecting unexpected encapsulation. It is possible that there
are mis-connectivity scenarios where OAM frames can alias as
payload IF a transport path can carry an arbitrary payload
without a pseudo wire.
o Exit criteria: The sink MEP does not receive any pro-active
CC-V OAM packet with an incorrect globally unique Source MEP CC-V OAM packet with an incorrect 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 transmission period of the pro-active CC-V OAM longest transmission period of the pro-active CC-V OAM
packets received with an incorrect globally unique Source MEP packets received with an incorrect globally unique Source MEP
identifier since this defect has been raised. This requires identifier since this defect has been raised. This requires
the OAM message to self identify the CC-V periodicity as not the OAM message to self identify the CC-V periodicity as not
all MEPs can be expected to have knowledge of all MEGs. all MEPs can be expected to have knowledge of all 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 a correct If pro-active CC-V OAM packets are received with a correct
globally unique Source MEP identifier but with a transmission globally unique Source MEP identifier but with a transmission
period different than the locally configured reception period, period different than the locally configured reception period,
then a CV period mis-configuration defect is detected. then a CV period mis-configuration 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 pro-active packet with
correct globally unique Source MEP identifier but with a correct globally unique Source MEP identifier but with a
Period field value different than its own CC-V configured Period field value 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 pro-active
CC-V OAM packet with a correct globally unique Source MEP CC-V OAM packet with a correct globally unique Source MEP
identifier and an incorrect transmission period for an identifier and an incorrect transmission period for an
interval equal at least to 3.5 times the longest transmission interval equal at least to 3.5 times the longest transmission
period of the pro-active CC-V OAM packets received with a period of the pro-active CC-V OAM packets received with a
correct globally unique Source MEP identifier and an correct globally unique Source MEP identifier and an
incorrect transmission period since this defect has been incorrect transmission period since this defect has been
raised. raised.
5.1.2. Consequent action 5.1.2. Consequent action
skipping to change at page 31, line 35 skipping to change at page 33, line 42
Identifier, it blocks all the traffic (including also the user Identifier, it blocks all the traffic (including also the user
data packets) that it receives from the misconnected transport data packets) that it receives from the misconnected transport
path. path.
If a MEP detects LOC defect that is not caused by a period If a MEP detects LOC defect that is not caused by a period
mis-configuration, it should block all the traffic (including mis-configuration, it should block all the traffic (including
also the user data packets) that it receives from the transport also the user data packets) that it receives from the transport
path, if this consequent action has been enabled by the path, if this consequent action has been enabled by the
operator. operator.
It is worth noticing that the OAM requirements document [8] It is worth noticing that the OAM requirements document [10]
recommends that CC-V proactive monitoring be enabled on every recommends that CC-V proactive monitoring be enabled on every
MEG in order to reliably detect connectivity defects. However, MEG in order to reliably detect connectivity defects. However,
CC-V proactive monitoring can be disabled by an operator for a CC-V proactive monitoring can be disabled by an operator for a
MEG. In the event of a misconnection between a transport path MEG. In the event of a misconnection between a transport path
that is pro-actively monitored for CC-V and a transport path that is pro-actively monitored for CC-V and a transport path
which is not, the MEP of the former transport path will detect a which is not, the MEP of the former transport path will detect a
LOC defect representing a connectivity problem (e.g. a LOC defect representing a connectivity problem (e.g. a
misconnection with a transport path where CC-V proactive misconnection with a transport path where CC-V proactive
monitoring is not enabled) instead of a continuity problem, with monitoring is not enabled) instead of a continuity problem, with
a consequent wrong traffic delivering. For these reasons, the a consequent wrong traffic delivering. For these reasons, the
traffic block consequent action is applied even when a LOC traffic block consequent action is applied even when a LOC
condition occurs. This block consequent action can be disabled condition occurs. This block consequent action can be disabled
through configuration. This deactivation of the block action may through configuration. This deactivation of the block action may
be used for activating or deactivating the monitoring when it is be used for activating or deactivating the monitoring when it is
not possible to synchronize the function activation of the two not possible to synchronize 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), a
mis-connectivity defect (section 5.1.1.2) or a period mis-connectivity defect (section 5.1.1.2) it declares a signal
misconfiguration defect (section 5.1.1.3), it declares a signal
fail condition at the transport path level. fail condition at the transport path level.
It is a matter if local policy if a MEP detecting a period
misconfiguration defect (section 5.1.1.3) declares a signal fail
condition at the transport path level.
5.1.3. Configuration considerations 5.1.3. Configuration considerations
At all MEPs inside a MEG, the following configuration At all MEPs inside a MEG, the following configuration
information needs to be configured when a proactive CC-V information needs to be configured when a proactive CC-V
function is enabled: function is enabled:
o MEG ID; the MEG identifier to which the MEP belongs; 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 peer MEPs inside the MEG. For a point-to-point MEG o list of the other MEPs in the MEG. For a point-to-point MEG
the list would consist of the single peer MEP ID from which the list would consist of the single MEP ID from which the
the OAM packets are expected. In case of the root MEP of a OAM packets are expected. In case of the root MEP of a p2mp
p2mp MEG, the list is composed by all the leaf MEP IDs inside MEG, the list is composed by all the leaf MEP IDs inside the
the MEG. In case of the leaf MEP of a p2mp MEG, the list is MEG. In case of the leaf MEP of a p2mp MEG, the list is
composed by the root MEP ID (i.e. each leaf needs to know the composed by the root MEP ID (i.e. each leaf needs to know the
root MEP ID from which it expect to receive the CC-V OAM root MEP ID from which it expect to receive the CC-V OAM
packets). packets).
o PHB; it identifies the per-hop behaviour of CC-V packet. o PHB; it identifies the per-hop behaviour of CC-V packet.
Proactive CC-V packets are transmitted with the "minimum loss Proactive CC-V packets are transmitted with the "minimum loss
probability PHB" previously configured within a single probability PHB" previously configured within a single
network operator. This PHB is configurable on network network operator. This PHB is configurable on network
operator's basis. PHBs can be translated at the network operator's 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 switching applications): protection switching applications):
o Fault Management: default transmission period is 1s (i.e. o Fault Management: default transmission period is 1s (i.e.
transmission rate of 1 packet/second). transmission rate of 1 packet/second).
o Performance Monitoring: default transmission period is o Performance Monitoring: default transmission period is
100ms (i.e. transmission rate of 10 packets/second). 100ms (i.e. transmission rate of 10 packets/second).
Performance monitoring is only relevant when the Performance monitoring is only relevant when the
transport path is defect free. CC-V contributes to the transport path is defect free. CC-V contributes to the
accuracy of PM statistics by permitting the defect free accuracy of PM statistics by permitting the defect free
periods to be properly distinguished. periods to be properly distinguished.
o Protection Switching: default transmission period is o Protection Switching: default transmission period is
3.33ms (i.e. transmission rate of 300 packets/second), in 3.33ms (i.e. transmission rate of 300 packets/second), in
order to achieve sub-50ms the CC-V defect entry criteria order to achieve sub-50ms the CC-V defect entry criteria
should resolve in less than 10msec, and complete a should resolve in less than 10msec, and complete a
protection switch within a subsequent period of 50 msec. protection switch within a subsequent period of 50 msec.
It is also possible to lengthen the transmission period It is also possible to lengthen the transmission period
to 10ms (i.e. transmission rate of 100 packets/second): to 10ms (i.e. transmission rate of 100 packets/second):
in this case the CC-V defect entry criteria resolves is in this case the CC-V defect entry criteria is reached
longer (i.e. 30msec). later (i.e. 30msec).
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 his internal transmission rates for all applications, to satisfy his internal
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 statically provisioned transport paths the above information For statically provisioned transport paths the above parameters
are statically configured; for dynamically established transport are statically configured; for dynamically established transport
paths the configuration information are signaled via the control paths the configuration information are signaled via the control
plane. plane.
The operator should be able to enable/disable some of the The operator should be able to enable/disable some of the
consequent actions defined in section 5.1.2. consequent actions. Which consequent action can be
enabled/disabled are 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 2.2.9 of [8], is an indicator that is transmitted by a section 2.2.9 of RFC 5860 [10], is an indicator that is
MEP to communicate to its peer MEPs that a signal fail condition transmitted by a sink MEP to communicate to its source MEP that
exists. RDI is only used for bidirectional connections and is a signal fail condition exists. RDI is only used for
associated with proactive CC-V activation. The RDI indicator is bidirectional connections and is associated with proactive CC-V.
piggy-backed onto the CC-V packet. The RDI indicator is piggy-backed onto the CC-V packet.
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 RDI indicator to its peer MEP. The RDI information will be an RDI indicator to its peer MEP. The RDI information will be
included in all pro-active CC-V packets that it generates for included in all pro-active CC-V packets that it generates for
the duration of the signal fail condition's existence. the duration of the signal fail condition's existence.
A MEP that receives the packets with the RDI information should A MEP that receives packets from a peer MEP (as best can be
determine that its peer MEP has encountered a defect condition validated with the CC or CV tool in use) with the RDI
associated with a signal fail. information should determine that its peer MEP has encountered a
defect condition associated with a signal fail.
MIPs as well as intermediate nodes not supporting MPLS-TP OAM MIPs as well as intermediate nodes not supporting MPLS-TP OAM
are transparent to the RDI indicator and forward these proactive are transparent to the RDI indicator and forward these proactive
CC-V packets that include the RDI indicator as regular data CC-V packets that include the RDI indicator as regular data
packets, i.e. the MIP should not perform any actions nor examine packets, i.e. the MIP should not perform any actions nor examine
the indicator. the indicator.
When the signal fail defect condition clears, the MEP should When the signal fail defect condition clears, the MEP should
clear the RDI indicator from subsequent transmission of pro- clear the RDI indicator from subsequent transmission of pro-
active CC-V packets. A MEP should clear the RDI defect upon active CC-V packets. A MEP should clear the RDI defect upon
skipping to change at page 34, line 24 skipping to change at page 36, line 36
In order to support RDI indication, this may be a unique OAM In order to support RDI indication, this may be a unique OAM
message or an OAM information element embedded in a CV message. message or an OAM information element embedded in a CV message.
In this case the RDI transmission rate and PHB of the OAM In this case the RDI transmission rate and PHB of the OAM
packets carrying RDI should be the same as that configured for packets carrying RDI should be the same as that configured for
CC-V. CC-V.
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
[8], relies upon an Alarm Indication Signal (AIS) message to RFC 5860 [10], relies upon an Alarm Indication Signal (AIS)
suppress alarms following detection of defect conditions at the message to suppress alarms following detection of defect
server (sub-)layer. conditions at the server (sub-)layer.
When a server MEP asserts signal fail, the MPLS-TP client When a server MEP asserts signal fail, the co-located MPLS-TP
(sub-)layer adaptation function generates packets with AIS client (sub-)layer adaptation function generates packets with
information in the downstream direction to allow the suppression AIS information in the downstream direction to allow the
of secondary alarms at the MEP in the client (sub-)layer. suppression of secondary alarms at the MEP in the client (sub-
)layer.
The generation of packets with AIS information starts The generation of packets with AIS information starts
immediately when the server MEP asserts signal fail. These immediately when the server MEP asserts signal fail. These
periodic packets, with AIS information, continue to be periodic packets, with AIS information, continue to be
transmitted until the signal fail condition is cleared. transmitted until the signal fail condition is cleared. It is
assumed that to avoid race conditions a MEP detecting loss of
continuity will wait for a hold off interval prior to asserting
an alarm to the management system.
Upon receiving a packet with AIS information an MPLS-TP MEP Upon receiving a packet with AIS information an MPLS-TP MEP
enters an AIS defect condition and suppresses loss of continuity enters an AIS defect condition and suppresses loss of continuity
alarms associated with its peer MEP. A MEP resumes loss of alarms associated with its peer MEP but does not block traffic
received from the transport path. A MEP resumes loss of
continuity alarm generation upon detecting loss of continuity continuity alarm generation upon detecting loss of continuity
defect conditions in the absence of AIS condition. defect conditions in the absence of AIS condition.
MIPs, as well as intermediate nodes, do not process AIS
information and forward these AIS OAM packets as regular data
packets.
For example, let's consider a fiber cut between LSR 1 and LSR 2 For example, let's consider a fiber cut between LSR 1 and LSR 2
in the reference network of Figure 5. Assuming that all the MEGs in the reference network of Figure 5. Assuming that all the MEGs
described in Figure 5 have pro-active CC-V enabled, a LOC defect described in Figure 5 have pro-active CC-V enabled, a LOC defect
is detected by the MEPs of Sec12 SME, LSP13 LME, PW1 PPSTME and is detected by the MEPs of Sec12 SME, LSP13 LME, PW1 PSME and
PW1Z PME, however in transport network only the alarm associate PW1Z PME, however in a transport network only the alarm
to the fiber cut needs to be reported to NMS while all these associated to the fiber cut needs to be reported to an NMS while
secondary alarms should be suppressed (i.e. not reported to the all secondary alarms should be suppressed (i.e. not reported to
NMS or reported as secondary alarms). the NMS or 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 LSR2), LSR2 can generate the proper alarm in the physical (in LSR2), LSR2 can generate the proper alarm in the physical
layer and suppress the secondary alarm associated with the LOC layer and suppress the secondary alarm associated with the LOC
defect detected on Sec12 SME. As both MEPs reside within the defect detected on Sec12 SME. As both MEPs reside within the
same node, this process does not involve any external protocol same node, this process does not involve any external protocol
exchange. Otherwise, if the physical layer has not enough OAM exchange. Otherwise, if the physical layer has not enough OAM
capabilities to detect the fiber cut, the MEP of Sec12 SME in capabilities to detect the fiber cut, the MEP of Sec12 SME in
LSR2 will report a LOC alarm. LSR2 will report a LOC alarm.
In both cases, the MEP of Sec12 SME in LSR 2 notifies the In both cases, the MEP of Sec12 SME in LSR 2 notifies the
adaptation function for LSP13 LME that then generates AIS adaptation function for LSP13 LME that then generates AIS
packets on the LSP13 LME in order to allow its MEP in LSR3 to packets on the LSP13 LME in order to allow its MEP in LSR3 to
suppress the LOC alarm. LSR3 can also suppress the secondary suppress the LOC alarm. LSR3 can also suppress the secondary
alarm on PW13 PPSTME because the MEP of PW13 PPSTME resides alarm on PW13 PSME because the MEP of PW13 PSME resides within
within the same node as the MEP of LSP13 LME. The MEP of PW13 the same node as the MEP of LSP13 LME. The MEP of PW13 PSME in
PPSTME in LSR3 also notifies the adaptation function for PW1Z LSR3 also notifies the adaptation function for PW1Z PME that
PME that then generates AIS packets on PW1Z PME in order to then generates AIS packets on PW1Z PME in order to allow its MEP
allow its MEP in LSRZ to suppress the LOC alarm. in LSRZ to suppress the LOC 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 the AIS generation). enable/disable the AIS generation).
AIS packets are transmitted with the "minimum loss probability AIS packets are transmitted with the "minimum loss probability
PHB" within a single network operator. This PHB is configurable PHB" within a single network operator. This PHB is configurable
on network operator's basis. on network operator's basis.
A MIP is transparent to packets with AIS information and AIS condition is cleared if no AIS message has been received in
therefore does not require any information to support AIS 3.5 times the AIS transmission period.
functionality.
5.4. Lock Reporting 5.4. Lock Reporting
The Lock Reporting function, as required in section 2.2.7 of The Lock Reporting function, as required in section 2.2.7 of RFC
[8], relies upon a Locked Report (LKR) message used to suppress 5860 [10], relies upon a Locked Report (LKR) message used to
alarms following administrative locking action in the server suppress alarms following administrative locking action in the
(sub-)layer. server (sub-)layer.
When a server MEP is locked or receives a lock report, the When a server MEP is locked, the MPLS-TP client (sub-)layer
MPLS-TP client (sub-)layer adaptation function generates packets adaptation function generates packets with LKR information in
with LKR information in both directions to allow the suppression both directions to allow the suppression of secondary alarms at
of secondary alarms at the MEPs in the client (sub-)layer. the MEPs in the client (sub-)layer. Again it is assumed that
there is a hold off for any loss of continuity alarms in the
client layer MEPs downstream of the node originating the locked
report.
The generation of packets with LKR information starts The generation of packets with LKR information starts
immediately when the server MEP is locked. These periodic immediately when the server MEP is locked. These periodic
packets, with LKR information, continue to be transmitted until packets, with LKR information, continue to be transmitted until
the locked condition is cleared. the locked condition is cleared.
Upon receiving a packet with LKR information an MPLS-TP MEP Upon receiving a packet with LKR information an MPLS-TP MEP
enters an LKR defect condition and suppresses loss of continuity enters an LKR defect condition and suppresses loss of continuity
alarm associated with its peer MEP. A MEP resumes loss of alarm associated with its peer MEP but does not block traffic
received from the transport path. A MEP resumes loss of
continuity alarm generation upon detecting loss of continuity continuity alarm generation upon detecting loss of continuity
defect conditions in the absence of LKR condition. defect conditions in the absence of LKR condition.
MIPs, as well as intermediate nodes, do not process the LKR
information and forward these LKR OAM packets as regular data
packets.
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
administrative locked at LSR2 (in both directions).
Assuming that all the MEGs described in Figure 5 have pro-active
CC-V enabled, a LOC defect is detected by the MEPs of LSP13 LME,
PW1 PSME and PW1Z PME, however in a transport network all these
secondary alarms should be suppressed (i.e. not reported to the
NMS or reported as secondary alarms).
The MEP of Sec12 SME in LSR 2 notifies the adaptation function
for LSP13 LME that then generates LKR packets on the LSP13 LME
in order to allow its MEPs in LSR1 and LSR3 to suppress the LOC
alarm. LSR3 can also suppress the secondary alarm on PW13 PSME
because the MEP of PW13 PSME resides within the same node as the
MEP of LSP13 LME. The MEP of PW13 PSME in LSR3 also notifies the
adaptation function for PW1Z PME that then generates AIS packets
on PW1Z PME in order to allow its MEP in LSRZ to suppress the
LOC 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 the LKR generation). enable/disable the LKR generation).
LKR packets are transmitted with the "minimum loss probability LKR packets are transmitted with the "minimum loss probability
PHB" within a single network operator. This PHB is configurable PHB" within a single network operator. This PHB is configurable
on network operator's basis. on network operator's basis.
A MIP is transparent to packets with LKR information and Locked condition is cleared if no LKR packet has been received
therefore does not require any information to support LKR for 3.5 times the transmission period.
functionality.
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 the MPLS-TP Performance Monitoring (PM) function in supported by the MPLS-TP Performance Monitoring (PM) function in
order to facilitate reporting of QoS information for a transport order to facilitate reporting of QoS information for a transport
path as required in section 2.2.11 of [8]. LM is used to path as required in section 2.2.11 of RFC 5860 [10]. LM is used
exchange counter values for the number of ingress and egress 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 pair of MEPs. by a pair of MEPs.
Proactive LM is performed by periodically sending LM OAM packets Proactive LM is performed by periodically sending LM OAM packets
from a MEP to a peer MEP and by receiving LM OAM packets from from a MEP to a peer MEP and by receiving LM OAM packets from
the peer MEP (if a bidirectional transport path) during the life the peer MEP (if a bidirectional transport path) during the life
time of the transport path. Each MEP performs measurements of time of the transport path. Each MEP performs measurements of
its transmitted and received packets. These measurements are its transmitted and received packets. These measurements are
then transactionally correlated with the peer MEP in the ME to then correlated with the peer MEP in the ME to derive the impact
derive the impact of packet loss on a number of performance of packet loss on a number of performance metrics for the ME in
metrics for the ME in the MEG. The LM transactions are issued the MEG. The LM transactions are issued such that the OAM
such that the OAM packets will experience the same queuing packets will experience the same queuing discipline as the
discipline as the measured traffic while transiting between the measured traffic while transiting between the MEPs in the ME.
MEPs in the ME.
In order to support proactive LM, the transmission rate and PHB
associated with the LM OAM packets originating from a MEP need
be configured as part of the LM provisioning procedures. LM OAM
packets are transmitted with the same PHB class that the LM is
intended to measure. If that PHB is not an ordered aggregate
where the ordering constraint is all packets with the PHB class
being delivered in order, LM can produce inconsistent results.
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 incoming data packets (from the far-end MEP) while far-end with incoming data packets (from the far-end MEP) while far-end
packet loss refers to packet loss associated with egress data packet loss refers to packet loss associated with egress data
packets (towards the far-end MEP). packets (towards the far-end MEP).
MIPs, as well as intermediate nodes, do not process the LM
information and forward these pro-active LM OAM packets as
regular data packets.
5.5.1. Configuration considerations 5.5.1. Configuration considerations
In order to support proactive LM, the transmission rate and PHB In order to support proactive LM, the transmission rate and PHB
associated with the LM OAM packets originating from a MEP need class associated with the LM OAM packets originating from a MEP
be configured as part of the LM provisioning procedures. LM OAM need be configured as part of the LM provisioning. LM OAM
packets should be transmitted with the same PHB class that the packets should be transmitted with the PHB that yields the
LM is intended to measure. If that PHB is not an ordered lowest discard probability within the measured PHB Scheduling
aggregate where the ordering constraint is all packets with the Class (see RFC 3260 [15]).
PHB being delivered in order, LM can produce inconsistent
results. If that PHB class is not an ordered aggregate where the ordering
constraint is all packets with the PHB class being delivered in
order, LM can produce inconsistent results.
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
which operates in parallel with an OAM processing path, whether which operates in parallel with an OAM processing path, whether
hardware or software based, the packet and byte counts may be hardware or software based, the packet and byte counts may be
skewed if one or more packets can be processed before the OAM skewed if one or more packets can be processed before the OAM
processing samples counters. If OAM is implemented in software processing samples counters. If OAM is implemented in software
this error can be quite large. this error can be quite large.
skipping to change at page 38, line 4 skipping to change at page 41, line 10
In the case where multilink is encountered in the LSP path, the In the case where multilink is encountered in the LSP path, the
reordering of packets within the LSP can cause inaccurate LM reordering of packets within the LSP can cause inaccurate LM
results. 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 the MPLS-TP PM function in order to facilitate supported by the MPLS-TP PM function in order to facilitate
reporting of QoS information for a transport path as required in reporting of QoS information for a transport path as required in
section 2.2.12 of [8]. Specifically, pro-active DM is used to section 2.2.12 of RFC 5860 [10]. Specifically, pro-active DM is
measure the long-term packet delay and packet delay variation in used to measure the long-term packet delay and packet delay
the transport path monitored by a pair of MEPs. variation in the transport path 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 MEP to a peer MEP and by receiving DM OAM packets from from a MEP to a peer MEP and by receiving DM OAM packets from
the peer MEP (if a bidirectional transport path) during a the peer MEP (if a bidirectional transport path) during a
configurable time interval. configurable time interval.
Pro-active DM can be operated in two ways: Pro-active 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 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 and/or one-way packet delay variation measurements at delay and/or one-way packet delay variation measurements at
the peer MEP. Note that this requires synchronized precision the peer MEP. Note that this requires synchronized precision
time at either MEP by means outside the scope of this time at either MEP by means outside the scope of this
framework. framework.
o Two-way: a MEP sends DM OAM packet with a DM request to its o Two-way: a MEP sends DM OAM packet with a DM request to its
peer MEP, which replies with a DM OAM packet as a DM peer MEP, which replies with a DM OAM packet as a DM
response. The request/response DM OAM packets containing all response. The request/response DM OAM packets containing all
the required information to facilitate two-way packet delay the required information to facilitate two-way packet delay
and/or two-way packet delay variation measurements from the and/or two-way packet delay variation measurements from the
viewpoint of the source MEP. viewpoint of the source MEP.
MIPs, as well as intermediate nodes, do not process the DM
information and forward these pro-active DM OAM packets as
regular data packets.
5.6.1. Configuration considerations 5.6.1. Configuration considerations
In order to support pro-active DM, the transmission rate and PHB In order to support pro-active DM, the transmission rate and PHB
associated with the DM OAM packets originating from a MEP need associated with the DM OAM packets originating from a MEP need
be configured as part of the DM provisioning procedures. DM OAM be configured as part of the DM provisioning. DM OAM packets
packets should be transmitted with the PHB that yields the should be transmitted with the PHB that yields the lowest
lowest packet loss performance among the PHB Scheduling Classes discard probability within the measured PHB Scheduling Class
or Ordered Aggregates (see RFC 3260 [12]) in the monitored (see RFC 3260 [15]).
transport path for the relevant network domain(s).
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 2.2.10 of [8], is used to help process client defects section 2.2.10 of RFC 5860 [10], is used to help process client
and propagate a client signal defect condition from the process defects and propagate a client signal defect condition from the
associated with the local attachment circuit where the defect process associated with the local attachment circuit where the
was detected (typically the source adaptation function for the defect was detected (typically the source adaptation function
local client interface) to the process associated with the far- for the local client interface) to the process associated with
end attachment circuit (typically the source adaptation function the far-end attachment circuit (typically the source adaptation
for the far-end client interface) for the same transmission path function for the far-end client interface) for the same
in case the client of the transport path does not support a transmission path in case the client of the transport path does
native defect/alarm indication mechanism, e.g. AIS. not support a native defect/alarm indication mechanism, e.g.
AIS.
A source MEP starts transmitting a CFI indication to its peer A source MEP starts transmitting a CFI indication to its peer
MEP when it receives a local client signal defect notification MEP when it receives a local client signal defect notification
via its local CSF function. Mechanisms to detect local client via its local CSF function. Mechanisms to detect local client
signal fail defects are technology specific. signal fail defects are technology specific. Similarly
mechanisms to determine when to cease originating client signal
fail indication are also technology specific.
A sink MEP that has received a CFI indication report this A sink MEP that has received a CFI indication report this
condition to its associated client process via its local CFI condition to its associated client process via its local CFI
function. Consequent actions toward the client attachment function. Consequent 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 Either there needs to be a 1:1 correspondence between the client
and the MEG, or when multiple clients are multiplexed over a and the MEG, or when multiple clients are multiplexed over a
transport path, the CFI message requires additional information transport path, the CFI message requires additional information
to permit the client instance to be identified. to permit the client instance to be identified.
MIPs, as well as intermediate nodes, do not process the CFI
information and forward these pro-active CFI OAM packets as
regular 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 PHB of the CFI OAM message/information element should be and PHB of the CFI OAM message/information element should be
configured as part of the CFI configuration. configured as 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
skipping to change at page 39, line 48 skipping to change at page 43, line 16
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 client layers of the transport path being removed from into client layers of the transport path being removed from
service (e.g., lock-reporting) service (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 these are frequently
craftsperson initiated and attended. These do not necessarily initiated manually. These do not necessarily require
require different harvesting mechanisms that that for different harvesting mechanisms that for harvesting proactive
harvesting proactive monitoring telemetry. monitoring telemetry.
The functions that are exclusive out-of-service are those The functions that are exclusive out-of-service are those
described in section 6.3. The remainder are applicable to both described in section 6.3. The remainder are applicable to both
in-service and out-of-service transport paths. in-service and out-of-service transport paths.
6.1. Connectivity Verification 6.1. Connectivity Verification
In order to preserve network resources, e.g. bandwidth, In order to preserve network resources, e.g. bandwidth,
processing time at switches, it may be preferable to not use processing time at switches, it may be preferable to not use
proactive CC-V. In order to perform fault management functions, proactive CC-V. In order to perform fault management functions,
network management may invoke periodic on-demand bursts of on- network management may invoke periodic on-demand bursts of on-
demand CV packets, as required in section 2.2.3 of [8]. demand CV packets, as required in section 2.2.3 of RFC 5860
[10].
On demand connectivity verification is a transaction that flows
from the source MEP to a target MIP or MEP.
Use of on-demand CV is dependent on the existence of either a Use of on-demand CV is dependent on the existence of either a
bi-directional ME, or an associated return ME, or the bi-directional ME, or an associated return ME, or the
availability of an out of band return path because it requires availability of an out-of-band return path because it requires
the ability for target MIPs and MEPs to direct responses to the the ability for target MIPs and MEPs to direct responses to the
originating MEPs. originating MEPs.
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 problem of connectivity when a problem is suspected or known a problem of connectivity when a problem is suspected or known
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 alarm indication. signal or 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 should uniquely identify the MEG that is being checked. that should uniquely identify the MEG that is being checked.
The on-demand functionality may be used to check either an The on-demand functionality may be used to check either an
entire MEG (end-to-end) or between a MEP to a specific MIP. This entire MEG (end-to-end) or between a source MEP and a specific
functionality may not be available for associated bidirectional MIP. This functionality may not be available for associated
transport paths or unidirectional paths, as the MIP may not have bidirectional transport paths or unidirectional paths, as the
a return path to the source MEP for the on-demand CV MIP may not have a return path to the source MEP for the on-
transaction. demand CV transaction.
On-demand CV may generate a one-time burst of on-demand CV On-demand CV may generate a one-time burst of on-demand CV
packets, or be used to invoke periodic, non-continuous, bursts packets, or be used to invoke periodic, non-continuous, bursts
of on-demand CV packets. The number of packets generated in of on-demand CV packets. The number of packets generated in
each burst is configurable at the MEPs, and should take into each burst is configurable at the MEPs, and should take into
account normal packet-loss conditions. account normal packet-loss conditions.
When invoking a periodic check of the MEG, the source MEP should When invoking a periodic check of the MEG, the source MEP should
issue a burst of on-demand CV packets that uniquely identifies issue a burst of on-demand CV packets that uniquely identifies
the MEG being verified. The number of packets and their the MEG being verified. The number of packets and their
transmission rate should be pre-configured and known to both the transmission rate should be pre-configured and known to both the
source MEP and the target MEP or MIP. The source MEP should use source MEP and the target MEP or MIP. The source MEP should use
the mechanisms defined in sections 3.3 and 3.4 when sending an the mechanisms defined in sections 3.3 and 3.4 when sending an
on-demand CV packet to a target MEP or target MIP respectively. on-demand CV packet to a target MEP or target MIP respectively.
The target MEP/MIP shall return a reply on-demand CV packet for The target MEP/MIP shall return a reply on-demand CV packet for
each packet received. If the expected number of on-demand CV each packet received. If the expected number of on-demand CV
reply packets is not received at source MEP, the LOC defect reply packets is not received at source MEP, the LOC defect
state is entered. state is entered.
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 variety of MTU sizes can be originated to verify the MTU a variety of MTU sizes can be originated to verify the MTU
capacity of the transport path. transport capability of the transport path.
MIPs that are not target by on-demand CV packets, as well as
intermediate nodes, do not process the CV information and
forward 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 MEP should support the configuration of the For on-demand CV the MEP should support the configuration of the
number of packets to be transmitted/received in each burst of number of packets to be transmitted/received in each burst of
transmissions and their packet size. The transmission rate transmissions and their packet size. The transmission rate
should be configured between the different nodes. should be configured between the different nodes.
In addition, when the CV packet is used to check connectivity In addition, when the CV packet is used to check connectivity
toward a target MIP, the number of hops to reach the target MIP toward a target MIP, the number of hops to reach the target MIP
skipping to change at page 41, line 32 skipping to change at page 45, line 10
The PHB of the on-demand CV packets should be configured as The PHB of the on-demand CV packets should be configured as
well. This permits the verification of correct operation of QoS well. This permits the verification of correct 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 supported by the MPLS-TP Performance Monitoring capabilities supported by the MPLS-TP Performance Monitoring
function in order to facilitate diagnostic of QoS performance function in order to facilitate diagnostic of QoS performance
for a transport path, as required in section 2.2.11 of [8]. As for a transport path, as required in section 2.2.11 of RFC 5860
proactive LM, on-demand LM is used to exchange counter values [10]. As proactive LM, on-demand LM is used to exchange counter
for the number of ingress and egress packets transmitted and values for the number of ingress and egress packets transmitted
received by the transport path monitored by a pair of MEPs. and received by the transport path monitored by a pair of MEPs.
LM is not performed MEP to MIP or between a pair of MIPs.
On-demand LM is performed by periodically sending LM OAM packets On-demand LM is performed by periodically sending LM OAM packets
from a MEP to a peer MEP and by receiving LM OAM packets from from a MEP to a peer MEP and by receiving LM OAM packets from
the peer MEP (if a bidirectional transport path) during a pre- the peer MEP (if a bidirectional transport path) during a pre-
defined monitoring period. Each MEP performs measurements of its defined monitoring period. Each MEP performs measurements of its
transmitted and received packets. These measurements are then transmitted and received packets. These measurements are then
correlated evaluate the packet loss performance metrics of the correlated to evaluate the packet loss performance metrics of
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 requires a traffic source such as a tester. path requires a traffic source such as a tester.
MIPs, as well as intermediate nodes, do not process the LM
information and forward these on-demand LM OAM packets as
regular data packets.
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 LM procedures, the transmission rate and PHB associated with the LM procedures, the transmission rate and PHB associated with
the LM OAM packets originating from a MEP must be configured as the LM OAM packets originating from a MEP must be configured as
part of the on-demand LM provisioning procedures. LM OAM packets part of the on-demand LM provisioning. LM OAM packets should be
should be transmitted with the PHB that yields the lowest packet transmitted with the PHB that yields the lowest discard
loss performance among the PHB Scheduling Classes or Ordered probability within the measured PHB Scheduling Class (see RFC
Aggregates (see RFC 3260 [12]) in the monitored transport path 3260 [15]).
for the relevant network domain(s).
6.2.2. Sampling skew 6.2.2. Sampling skew
If an implementation makes use of a hardware forwarding path If an implementation makes use of a hardware forwarding path
which operates in parallel with an OAM processing path, whether which operates in parallel with an OAM processing path, whether
hardware or software based, the packet and byte counts may be hardware or software based, the packet and byte counts may be
skewed if one or more packets can be processed before the OAM skewed if one or more packets can be processed before the OAM
processing samples counters. If OAM is implemented in software processing samples counters. If OAM is implemented in software
this error can be quite large. this error can be quite large.
6.2.3. Multilink issues 6.2.3. Multilink issues
Multi-link Issues are as described in section 5.5.3. Multi-link 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
out-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 required in section 2.2.5 of [8], that allows verifying the as required in section 2.2.5 of RFC 5860 [10], that allows
bandwidth/throughput of an MPLS-TP transport path (LSP or PW) verifying the bandwidth/throughput of an MPLS-TP transport path
before it is put in-service. (LSP or PW) before it is put in-service.
Throughput estimation is performed between MEPs and can be Throughput estimation is performed between MEPs and can be
performed in one-way or two-way modes. performed in one-way or two-way modes.
This test is performed by sending OAM test packets at increasing According to RFC 2544 [11], this test is performed by sending
rate (up to the theoretical maximum), graphing the percentage of OAM test packets at increasing rate (up to the theoretical
OAM test packets received and reporting the rate at which OAM maximum), graphing the percentage of OAM test packets received
test packets begin to drop. In general, this rate is dependent and reporting the rate at which OAM test packets begin to drop.
on the OAM test packet size. In general, this rate is dependent on the OAM test packet size.
When configured to perform such tests, a MEP source inserts OAM When configured to perform such tests, a MEP source inserts OAM
test packets with test information with specified throughput, test packets with a specified packet size and transmission
packet size and transmission patterns. pattern at a rate to exercise the throughput.
For one-way test, remote MEP sink receives the OAM test packets For a one-way test, the remote MEP sink receives the OAM test
and calculates the packet loss. For two-way test, the remote MEP packets and calculates the packet loss. For a two-way test, the
loopbacks the OAM test packets back to original MEP and the remote MEP loopbacks the OAM test packets back to original MEP
local MEP sink calculates the packet loss. However, a two-way and the local MEP sink calculates the packet loss. However, a
test will return the minimum of available throughput in the two two-way test will return the minimum of available throughput in
directions. Alternatively it is possible to run two individual the two directions. Alternatively it is possible to run two
one-way tests to get a distinct measurement in the two individual one-way tests to get a distinct measurement in the
directions. two directions.
It is worth noting that two-way throughput estimation can only
evaluate the minimum of available throughput of the two
directions. In order to estimate the throughput of each
direction uniquely, two one-way throughput estimation sessions
have to be setup.
MIPs, as well as intermediate nodes, do not process the
throughput test information and forward these on-demand test OAM
packets as regular data 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 should be put into a Lock status before the diagnostic test MEG should be put into a Lock status before the diagnostic test
is started. is started.
A MEG can be put into a Lock status either via NMS action or A MEG can be put into a Lock status 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 generator, which is associated with the MEP. At a signal generator, which is associated with the MEP. At a
receiving MEP, provisioning is required for a test signal receiving MEP, provisioning is required for a test signal
detector which is associated with the MEP. detector which is associated with the MEP.
A MIP is transparent to the OAM test packets sent for throught
estimation and therefore does not require any provisioning to
support MPLS-TP throughput estimation.
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 rates than OAM packets, then accurate measurement of data rates than OAM packets, then accurate measurement of
throughput using OAM packets is not achievable. Whether OAM throughput using OAM packets is not achievable. Whether OAM
packets can be processed at the same rate as payload is packets can be 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 section 2.2.5 of [8], that permits all traffic (including in section 2.2.5 of RFC 5860 [10], that permits all traffic
user data and OAM) originated at the ingress of a transport path (including user data and OAM, with the exception of the disable
or inserted by the test equipment to be looped back in the loopback command) originated at the ingress of a transport path
direction of the point of origin by an interface at either an or inserted by the test equipment to be looped back unmodified
intermediate node or a terminating node. TTL is decremented (other than normal per hop processing such as TTL decrement) in
normally during this process. the direction of the point of origin by an interface at either
an intermediate node or a terminating node. TTL is decremented
normally during this process. It is also normal to disable
proactive monitoring of the path as the source MEP will see all
source MEP originated OAM messages returned to it.
If the loopback function is to be performed at an intermediate If the loopback function is to be performed at an intermediate
node it is only applicable to co-routed bi-directional paths. If node it is only applicable to co-routed bi-directional paths. If
the loopback is to be performed end to end, it is applicable to the loopback is to be performed end to end, it is applicable to
both co-routed bi-directional or associated bi-directional both co-routed bi-directional or associated bi-directional
paths. paths.
Where a node implements data plane loopback capability and Where a node implements data plane loopback capability and
whether it implements more than one point is implementation whether it implements more than one point is implementation
dependent. dependent.
6.4. Route Tracing 6.4. Route Tracing
It is often necessary to trace a route covered by a MEG from a It is often necessary to trace a route covered by a MEG from a
source MEP to the sink MEP including all the MIPs in-between source MEP to the sink MEP including all the MIPs in-between
after e.g., provisioning an MPLS-TP transport path or for after e.g., provisioning an MPLS-TP transport path or for
trouble shooting purposes, it. trouble shooting purposes such as fault localization.
The route tracing function, as required in section 2.2.4 of [8], The route tracing function, as required in section 2.2.4 of RFC
is providing this functionality. Based on the fate sharing 5860 [10], is providing this functionality. Based on the fate
requirement of OAM flows, i.e. OAM packets receive the same sharing requirement of OAM flows, i.e. OAM packets receive the
forwarding treatment as data packet, route tracing is a basic same forwarding treatment as data packet, route tracing is a
means to perform connectivity verification and, to a much lesser basic means to perform connectivity verification and, to a much
degree, continuity check. For this function to work properly, a lesser degree, continuity check. For this function to work
return path must be present. properly, a return path 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 the peer MEPs. In case a defect exist, the route trace of the peer MEPs. In case a defect exist, the route trace
function needs to be able to detect it and stop automatically function needs to be able to detect it and stop automatically
returning the incomplete list of OAM entities that it was able returning the incomplete list of OAM entities that it was able
to trace. to trace.
skipping to change at page 45, line 10 skipping to change at page 48, line 46
The configuration of the route trace function must at least The configuration of the route trace function must at least
support the setting of the number of trace attempts before it support 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 the MPLS-TP PM function in order to facilitate supported by the MPLS-TP PM function in order to facilitate
reporting of QoS information for a transport path, as required reporting of QoS information for a transport path, as required
in section 2.2.12 of [8]. Specifically, on-demand DM is used to in section 2.2.12 of RFC 5860 [10]. Specifically, on-demand DM
measure packet delay and packet delay variation in the transport is used to measure packet delay and packet delay variation in
path monitored by a pair of MEPs during a pre-defined monitoring the transport path monitored by a pair of MEPs during a pre-
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 MEP to a peer MEP and by receiving DM OAM packets from from a MEP to a peer MEP and by receiving DM OAM packets from
the peer MEP (if a bidirectional transport path) during a the peer MEP (if a bidirectional transport path) during a
configurable time interval. configurable time interval.
On-demand DM can be operated in two ways: On-demand 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 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 and/or one-way packet delay variation measurements at delay and/or one-way packet delay variation measurements at
the peer MEP. the peer MEP. Note that this requires synchronized precision
time at either MEP by means outside the scope of this
framework.
o Two-way: a MEP sends DM OAM packet with a DM request to its o Two-way: a MEP sends DM OAM packet with a DM request to its
peer MEP, which replies with an DM OAM packet as a DM peer MEP, which replies with an DM OAM packet as a DM
response. The request/response DM OAM packets containing all response. The request/response DM OAM packets containing all
the required information to facilitate two-way packet delay the required information to facilitate two-way packet delay
and/or two-way packet delay variation measurements from the and/or two-way packet delay variation measurements from the
viewpoint of the source MEP. viewpoint of the source MEP.
MIPs, as well as intermediate nodes, do not process the DM
information and forward these on-demand DM OAM packets as
regular 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 DM procedures, the transmission rate and PHB associated with the DM procedures, the transmission rate and PHB associated with
the DM OAM packets originating from a MEP need be configured as the DM OAM packets originating from a MEP need be configured as
part of the LM provisioning procedures. DM OAM packets should be part of the DM provisioning. DM OAM packets should be
transmitted with the PHB that yields the lowest packet delay transmitted with the PHB that yields the lowest discard
performance among the PHB Scheduling Classes or Ordering probability within the measured PHB Scheduling Class (see RFC
Aggregates (see RFC 3260 [12]) in the monitored transport path 3260 [15]).
for the relevant network domain(s).
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 the operator to configure of the on-demand OAM DM possible for the operator to configure the packet size of the
packet. on-demand OAM DM 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 Lock Instruct (LKI) function, as required in section 2.2.6 of
[8], is a command allowing a MEP to instruct the peer MEP(s) to RFC 5860 [10], is a command allowing a MEP to instruct the peer
put the MPLS-TP transport path into a locked condition. MEP(s) to put the MPLS-TP transport path into a locked
condition.
This function allows single-side provisioning for This function allows single-side provisioning for
administratively locking (and unlocking) an MPLS-TP transport administratively 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) an MPLS-TP transport path using two-side provisioning, unlock) an MPLS-TP transport path using two-side provisioning,
where the NMS administratively put both MEPs into ad where the NMS administratively put both MEPs into ad
administrative lock condition. In this case, the LKI function is administrative lock 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
instruct information and forward these on-demand LKI OAM packets
as regular 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 NMS, sends an LKI request OAM packet to its peer MEP(s). It from an NMS, sends an LKI request OAM packet to its peer MEP(s).
also puts the MPLS-TP transport path into a locked and notify It also puts the MPLS-TP transport path into a locked state and
its client (sub-)layer adaptation function upon the locked notifies its client (sub-)layer adaptation function upon the
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
accept or not the instruction and replies to the peer MEP with accept or not the instruction and replies to the peer MEP with
an LKI reply OAM packet indicating whether it has accepted or an LKI reply OAM packet indicating whether it has accepted or
not the instruction. not the instruction.
If the lock instruction has been accepted, it also puts the If the lock instruction has been accepted, it also puts the
MPLS-TP transport path into a locked and notify its client MPLS-TP transport path into a locked and notifies its client
(sub-)layer adaptation function upon the locked condition. (sub-)layer adaptation function upon the locked 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
Reporting (LKR) generation at the client MPLS-TP (sub-)layer is Reporting (LKR) generation at the client MPLS-TP (sub-)layer is
started, as described in section 5.4. started, as 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 from NMS, sends an LKI removal request OAM packet to its command 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 accept The peer MEP, upon receiving an LKI removal request, can accept
or not the removal instruction and replies with an LKI removal or not the removal instruction and replies with an LKI removal
reply OAM packet indicating whether it has accepted or not the reply OAM packet indicating whether it has accepted or not the
instruction. instruction.
If the lock removal instruction has been accepted, it also If the lock removal instruction has been accepted, it also
clears the locked condition on the MPLS-TP transport path and clears the locked condition on the MPLS-TP transport path and
notify this event to its client (sub-)layer adaptation function. notifies this event to its client (sub-)layer adaptation
function.
The MEP that has initiated the LKI clear procedure, upon The MEP that has initiated the LKI clear procedure, upon
receiving a positive LKI removal reply, also clears the locked receiving a positive LKI removal reply, also clears the locked
condition on the MPLS-TP transport path and notify this event to condition on the MPLS-TP transport path and notifies this event
its client (sub-)layer adaptation function. to its client (sub-)layer adaptation function.
Note that if the client (sub-)layer is also MPLS-TP, Lock Note that if the client (sub-)layer is also MPLS-TP, Lock
Reporting (LKR) generation at the client MPLS-TP (sub-)layer is Reporting (LKR) generation at the client MPLS-TP (sub-)layer is
terminated, as described in section 5.4. terminated, as described in section 5.4.
8. Security Considerations 8. Security Considerations
A number of security considerations are important in the context A number of security considerations are important in the context
of OAM applications. of OAM applications.
skipping to change at page 47, line 38 skipping to change at page 51, line 39
authentication, authorization and encryption in place. This will authentication, authorization and encryption in place. This will
prevent unauthorized access to vital equipment and it will prevent unauthorized access to vital equipment and it will
prevent third parties from learning about sensitive information prevent third parties from learning about sensitive information
about the transport network. However it should be observed that about the transport network. However it should be observed that
the combination of all permutations of unique MEP to MEP, MEP to the combination of all permutations of unique MEP to MEP, MEP to
MIP, and intermediate system originated transactions mitigates MIP, and intermediate system originated transactions mitigates
against the practical establishment and maintenance of a large against the practical establishment and maintenance of a large
number of security associations per MEG. number of security associations per MEG.
For this reason it is assumed that the network is physically For this reason it is assumed that the network is physically
secured against man in the middle attacks. Further, this secured against man-in-the-middle attacks. Further, this
document describes OAM functions that, if a man in the middle document describes OAM functions that, if a man-in-the-middle
attack was possible, could be exploited to significantly disrupt attack was possible, could be exploited to significantly disrupt
proper operation of the network. proper operation of the network.
Mechanisms that the framework does not specify might be subject Mechanisms that the framework does not specify might be subject
to additional security considerations. to additional security considerations.
9. IANA Considerations 9. IANA Considerations
No new IANA considerations. No new IANA considerations.
skipping to change at page 48, line 20 skipping to change at page 52, line 20
definition and specification of MPLS Transport Profile. definition and specification of 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 for the definition of per-interface MIPs and MEPs. Paul 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 report and lock instruction description. lock report and lock instruction description.
The authors would also like to thank Loa Andersson, Malcolm The authors would also like to thank Alessandro D'Alessandro,
Betts, Stewart Bryant, Rui Costa, Xuehui Dai, John Drake, Adrian Loa Andersson, Malcolm Betts, Stewart Bryant, Rui Costa, Xuehui
Farrel, Liu Gouman, Feng Huang, Yoshionori Koike, George Dai, John Drake, Adrian Farrel, Dan Frost, Liu Gouman, Peng He,
Swallow, Yuji Tochio, Curtis Villamizar, Maarten Vissers and Feng Huang, Su Hui, Yoshionori Koike, George Swallow, Yuji
Xuequin Wei for their comments and enhancements to the text. 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. This document was prepared using 2-Word-v2.0.template.dot.
11. References 11. References
11.1. Normative References 11.1. Normative References
[1] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol [1] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001 Label Switching Architecture", RFC 3031, January 2001
[2] Bryant, S., Pate, P., "Pseudo Wire Emulation Edge-to-Edge [2] Bryant, S., Pate, P., "Pseudo Wire Emulation Edge-to-Edge
(PWE3) Architecture", RFC 3985, March 2005 (PWE3) Architecture", RFC 3985, March 2005
[3] Nadeau, T., Pignataro, S., "Pseudowire Virtual Circuit [3] Nadeau, T., Pignataro, S., "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for 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., Bryant, S., "An Architecture for Multi-Segment
Pseudo Wire Emulation Edge-to-Edge", RFC 5659, October Pseudo Wire Emulation Edge-to-Edge", RFC 5659, October
2009 2009
[5] Niven-Jenkins, B., Brungard, D., Betts, M., sprecher, N., [5] Niven-Jenkins, B., Brungard, D., Betts, M., sprecher, N.,
Ueno, S., "MPLS-TP Requirements", RFC 5654, September 2009 Ueno, S., "MPLS-TP Requirements", RFC 5654, September 2009
[6] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, [6] Agarwal, P., Akyol, B., "Time To Live (TTL) Processing in
Multiprotocol Label Switching (MPLS) Networks", RFC 3443,
January 2003
[7] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal,
R., "MPLS Generic Associated Channel", RFC 5586, June 2009 R., "MPLS Generic Associated Channel", RFC 5586, June 2009
[7] Swallow, G., Bocci, M., "MPLS-TP Identifiers", draft-ietf- [8] Bocci, M., et al., "A Framework for MPLS in Transport
Networks", RFC 5921, July 2010
[9] Swallow, G., Bocci, M., "MPLS-TP Identifiers", draft-ietf-
mpls-tp-identifiers-01 (work in progress), April 2010 mpls-tp-identifiers-01 (work in progress), April 2010
[8] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM [10] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM
in MPLS Transport Networks", draft-ietf-mpls-tp-oam- in MPLS Transport Networks", RFC 5860, May 2010
requirements-06 (work in progress), March 2010
[9] ITU-T Recommendation G.806 (01/09), "Characteristics of [11] Bradner, S., McQuaid, J., "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999
[12] 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 11.2. Informative References
[10] Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten, [13] Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten,
Y., "MPLS-TP OAM Analysis", draft-ietf-mpls-tp-oam- Y., "MPLS-TP OAM Analysis", draft-ietf-mpls-tp-oam-
analysis-01 (work in progress), March 2010 analysis-02 (work in progress), July 2010
[11] Nichols, K., Blake, S., Baker, F., Black, D., "Definition [14] Nichols, K., Blake, S., Baker, F., Black, D., "Definition
of the Differentiated Services Field (DS Field) in the of the Differentiated Services Field (DS Field) in the
IPv4 and IPv6 Headers", RFC 2474, December 1998 IPv4 and IPv6 Headers", RFC 2474, December 1998
[12] Grossman, D., "New terminology and clarifications for [15] Grossman, D., "New terminology and clarifications for
Diffserv", RFC 3260, April 2002. Diffserv", RFC 3260, April 2002.
[13] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in [16] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in
MPLS Traffic Engineering (TE)", RFC 4201, October 2005 MPLS Traffic Engineering (TE)", RFC 4201, October 2005
[14] IEEE Standard 802.1AX-2008, "IEEE Standard for Local and [17] ITU-T Recommendation G.707/Y.1322 (01/07), "Network node
interface for the synchronous digital hierarchy (SDH)",
January 2007
[18] ITU-T Recommendation G.805 (03/00), "Generic functional
architecture of transport networks", March 2000
[19] ITU-T Recommendation Y.1731 (02/08), "OAM functions and
mechanisms for Ethernet based networks", February 2008
[20] IEEE Standard 802.1AX-2008, "IEEE Standard for Local and
Metropolitan Area Networks - Link Aggregation", November Metropolitan Area Networks - Link Aggregation", November
2008 2008
Authors' Addresses Authors' Addresses
Dave Allan Dave Allan
Ericsson Ericsson
Email: david.i.allan@ericsson.com Email: david.i.allan@ericsson.com
skipping to change at page 51, line 4 skipping to change at page 55, line 23
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
Dinesh Mohan
Nortel
Email: mohand@nortel.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
 End of changes. 281 change blocks. 
747 lines changed or deleted 922 lines changed or added

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