draft-ietf-mpls-tp-oam-framework-08.txt   draft-ietf-mpls-tp-oam-framework-09.txt 
MPLS Working Group I. Busi (Ed) MPLS Working Group I. Busi (Ed)
Internet Draft Alcatel-Lucent Internet Draft Alcatel-Lucent
Intended status: Informational D. Allan (Ed) Intended status: Informational D. Allan (Ed)
Ericsson Ericsson
Expires: March 17, 2011 September 17, 2010 Expires: April 7, 2011 October 7, 2010
Operations, Administration and Maintenance Framework for MPLS- Operations, Administration and Maintenance Framework for MPLS-
based Transport Networks based Transport Networks
draft-ietf-mpls-tp-oam-framework-08.txt draft-ietf-mpls-tp-oam-framework-09.txt
Abstract Abstract
The Transport Profile of Multi-Protocol Label Switching The Transport Profile of Multi-Protocol Label Switching
(MPLS-TP) is a packet-based transport technology based on the (MPLS-TP) is a packet-based transport technology based on the
MPLS Traffic Engineering (MPLS-TE) and Pseudowire (PW) data MPLS Traffic Engineering (MPLS-TE) and Pseudowire (PW) data
plane architectures. plane architectures.
This document describes a framework to support a comprehensive This document describes a framework to support a comprehensive
set of Operations, Administration and Maintenance (OAM) set of Operations, Administration and Maintenance (OAM)
skipping to change at page 2, line 11 skipping to change at page 2, line 11
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 March 17, 2011. This Internet-Draft will expire on April 7, 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 Simplified BSD License. without warranty as described in the Simplified 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.......................................10 3. Functional Components........................................10
3.1. Maintenance Entity and Maintenance Entity Group.........10 3.1. Maintenance Entity and Maintenance Entity Group.........10
3.2. Nested MEGs: SPMEs and Tandem Connection Monitoring.....12 3.2. Nested MEGs: SPMEs and Tandem Connection Monitoring.....12
3.3. MEG End Points (MEPs)..................................14 3.3. MEG End Points (MEPs)...................................14
3.4. MEG Intermediate Points (MIPs).........................17 3.4. MEG Intermediate Points (MIPs)..........................17
3.5. Server MEPs...........................................18 3.5. Server MEPs.............................................18
3.6. Configuration Considerations...........................19 3.6. Configuration Considerations............................19
3.7. P2MP considerations....................................19 3.7. P2MP considerations.....................................20
4. Reference Model............................................20 3.8. Further considerations of enhanced segment monitoring...21
4.1. MPLS-TP Section Monitoring (SME).......................23 4. Reference Model..............................................21
4.2. MPLS-TP LSP End-to-End Monitoring (LME)................24 4.1. MPLS-TP Section Monitoring (SME)........................23
4.3. MPLS-TP PW Monitoring (PME)............................24 4.2. MPLS-TP LSP End-to-End Monitoring (LME).................24
4.4. MPLS-TP LSP SPME Monitoring (LSME).....................25 4.3. MPLS-TP PW Monitoring (PME).............................25
4.5. MPLS-TP MS-PW SPME Monitoring (PSME)...................26 4.4. MPLS-TP LSP SPME Monitoring (LSME)......................25
4.6. Fate sharing considerations for multilink..............28 4.5. MPLS-TP MS-PW SPME Monitoring (PSME)....................27
5. OAM Functions for proactive monitoring......................29 4.6. Fate sharing considerations for multilink...............28
5. OAM Functions for proactive monitoring.......................29
5.1. Continuity Check and Connectivity Verification..........30 5.1. Continuity Check and Connectivity Verification..........30
5.1.1. Defects identified by CC-V........................31 5.1.1. Defects identified by CC-V.........................32
5.1.2. Consequent action.................................33 5.1.2. Consequent action..................................34
5.1.3. Configuration considerations......................34 5.1.3. Configuration considerations.......................35
5.2. Remote Defect Indication...............................36 5.2. Remote Defect Indication................................36
5.2.1. Configuration considerations......................36 5.2.1. Configuration considerations.......................37
5.3. Alarm Reporting........................................37 5.3. Alarm Reporting.........................................37
5.4. Lock Reporting........................................38 5.4. Lock Reporting..........................................39
5.5. Packet Loss Measurement................................39 5.5. Packet Loss Measurement.................................40
5.5.1. Configuration considerations......................40 5.5.1. Configuration considerations.......................41
5.5.2. Sampling skew.....................................40 5.5.2. Sampling skew......................................41
5.5.3. Multilink issues..................................40 5.5.3. Multilink issues...................................41
5.6. Packet Delay Measurement...............................41 5.6. Packet Delay Measurement................................42
5.6.1. Configuration considerations......................41 5.6.1. Configuration considerations.......................42
5.7. Client Failure Indication..............................42 5.7. Client Failure Indication...............................42
5.7.1. Configuration considerations......................42 5.7.1. Configuration considerations.......................43
6. OAM Functions for on-demand monitoring......................42 6. OAM Functions for on-demand monitoring.......................43
6.1. Connectivity Verification..............................43 6.1. Connectivity Verification...............................44
6.1.1. Configuration considerations......................44 6.1.1. Configuration considerations.......................45
6.2. Packet Loss Measurement................................45 6.2. Packet Loss Measurement.................................45
6.2.1. Configuration considerations......................45 6.2.1. Configuration considerations.......................46
6.2.2. Sampling skew.....................................45 6.2.2. Sampling skew......................................46
6.2.3. Multilink issues..................................45 6.2.3. Multilink issues...................................46
6.3. Diagnostic Tests.......................................46 6.3. Diagnostic Tests........................................47
6.3.1. Throughput Estimation.............................46 6.3.1. Throughput Estimation.............................47
6.3.2. Data plane Loopback...............................47 6.3.2. Data plane Loopback...............................48
6.4. Route Tracing.........................................48 6.4. Route Tracing..........................................49
6.4.1. Configuration considerations......................48 6.4.1. Configuration considerations......................50
6.5. Packet Delay Measurement...............................48 6.5. Packet Delay Measurement...............................50
6.5.1. Configuration considerations......................49 6.5.1. Configuration considerations......................51
7. OAM Functions for administration control....................49 7. OAM Functions for administration control....................51
7.1. Lock Instruct.........................................49 7.1. Lock Instruct..........................................51
7.1.1. Locking a transport path..........................50 7.1.1. Locking a transport path..........................51
7.1.2. Unlocking a transport path........................50 7.1.2. Unlocking a transport path........................52
8. Security Considerations.....................................51 8. Security Considerations.....................................52
9. IANA Considerations........................................51 9. IANA Considerations.........................................53
10. Acknowledgments...........................................51 10. Acknowledgments............................................53
11. References................................................53 11. References.................................................54
11.1. Normative References..................................53 11.1. Normative References..................................54
11.2. Informative References................................54 11.2. Informative References................................55
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.]
skipping to change at page 5, line 25 skipping to change at page 5, line 25
1. Introduction 1. Introduction
As noted in the multi-protocol label switching (MPLS-TP) Framework As noted in the multi-protocol label switching (MPLS-TP) Framework
RFCs (RFC 5921 [8] and [9]), MPLS-TP is a packet-based transport RFCs (RFC 5921 [8] and [9]), MPLS-TP is a packet-based transport
technology based on the MPLS Traffic Engineering (MPLS-TE) and Pseudo technology based on the MPLS Traffic Engineering (MPLS-TE) and Pseudo
Wire (PW) data plane architectures defined in RFC 3031 [1], RFC 3985 Wire (PW) data plane architectures defined in RFC 3031 [1], RFC 3985
[2] and RFC 5659 [4]. [2] and RFC 5659 [4].
MPLS-TP supports a comprehensive set of Operations, MPLS-TP supports a comprehensive set of Operations,
Administration and Maintenance (OAM) procedures for fault, Administration and Maintenance (OAM) procedures for fault,
performance and protection-switching management and that do not performance and protection-switching management that do not rely
rely on the presence of a control plane. on the presence of a control plane.
In line with [14], existing MPLS OAM mechanisms will be used In line with [14], 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 of RFC 5860 [11]. In this regard, it defines requirements of RFC 5860 [11]. In this regard, it defines
similar OAM functionality as for existing SONET/SDH and OTN OAM similar OAM functionality as for existing SONET/SDH and OTN OAM
mechanisms (e.g. [18]). mechanisms (e.g. [18]).
The MPLS-TP OAM framework is applicable to both LSPs and The MPLS-TP OAM framework is applicable to sections, 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.
skipping to change at page 6, line 18 skipping to change at page 6, line 18
Enrique Hernandez-Valencia, Lieven Levrau, Vincenzo Sestito, Enrique Hernandez-Valencia, Lieven Levrau, Vincenzo Sestito,
Nurit Sprecher, Huub van Helvoort, Martin Vigoureux, Yaacov Nurit Sprecher, Huub van Helvoort, Martin 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
AIS Alarm indication signal
CV Connectivity Verification
DBN Domain Border Node DBN Domain Border Node
LER Label Edge Router LER Label Edge Router
LKR Lock Report
LM Loss Measurement
LME LSP Maintenance Entity LME LSP Maintenance Entity
LMEG LSP ME Group LMEG LSP ME Group
LSP Label Switched Path LSP Label Switched Path
LSR Label Switching Router LSR Label Switching Router
LSME LSP SPME ME LSME LSP SPME ME
skipping to change at page 6, line 44 skipping to change at page 6, line 52
ME Maintenance Entity ME Maintenance Entity
MEG Maintenance Entity Group MEG Maintenance Entity Group
MEP Maintenance Entity Group End Point MEP Maintenance Entity Group End Point
MIP Maintenance Entity Group Intermediate Point MIP Maintenance Entity Group Intermediate Point
PHB Per-hop Behavior PHB Per-hop Behavior
PM Performance Monitoring
PME PW Maintenance Entity PME PW Maintenance Entity
PMEG PW ME Group PMEG PW ME Group
PSME PW SPME ME PSME PW SPME ME
PSMEG PW SPME ME Group PSMEG PW SPME ME Group
PW Pseudowire PW Pseudowire
SLA Service Level Agreement SLA Service Level Agreement
SME Section Maintenance Entity Group SME Section Maintenance Entity Group
SPME Sub-path Maintenance Element SPME Sub-path Maintenance Element
2.2. Definitions 2.2. Definitions
This document uses the terms defined in RFC 5654 [5]. This document uses the terms defined in RFC 5654 [5].
skipping to change at page 7, line 18 skipping to change at page 7, line 28
SPME Sub-path Maintenance Element SPME Sub-path Maintenance Element
2.2. Definitions 2.2. Definitions
This document uses the terms defined in RFC 5654 [5]. This document uses the terms defined in RFC 5654 [5].
This document uses the term 'Per-hop Behavior' as defined in RFC This document uses the term 'Per-hop Behavior' as defined in RFC
2474 [15]. 2474 [15].
This document uses the term LSP to indicate either a service LSP This document uses the term LSP to indicate either a service LSP
or a transport LSP (as defined in [8]). or a transport LSP (as defined in RFC 5921 [8]).
This document uses the term Sub Path Maintenance Entity (SPME)
as defined in RFC 5921 [8].
Where appropriate, the following definitions are aligned with Where appropriate, the following definitions are aligned with
ITU-T recommendation Y.1731 [20] in order to have a common, ITU-T recommendation Y.1731 [20] in order to have a common,
unambiguous terminology. They do not however intend to imply a unambiguous terminology. They do not however intend to imply a
certain implementation but rather serve as a framework to certain implementation but rather serve as a framework to
describe the necessary OAM functions for MPLS-TP. describe the necessary OAM functions for MPLS-TP.
Adaptation function: The adaptation function is the interface Adaptation function: The adaptation function is the interface
between the client (sub)-layer and the server (sub-layer). between the client (sub)-layer and the server (sub-)layer.
Data plane loopback: An out-of-service test where an interface Data plane loopback: An out-of-service test where a transport
at either an intermediate or terminating node in a path is path at either an intermediate or terminating node is placed
placed into a data plane loopback state, such that all traffic into a data plane loopback state, such that all traffic
(including user data and OAM) received on the looped back (including both payload and OAM) received on the looped back
interface is sent on the reverse direction of the transport interface is sent on the reverse direction of the transport
path. path.
Note - The only way to send an OAM packet to a node set in the data Note - The only way to send an OAM packet to a node that has been put
plane loopback mode is via TTL expiry, irrespectively on whether the into data plane loopback mode is via TTL expiry, irrespective of
node is hosting MIPs or MEPs. whether the node is hosting MIPs or MEPs.
Domain Border Node (DBN): An intermediate node in an MPLS-TP LSP Domain Border Node (DBN): An intermediate node in an MPLS-TP LSP
that is at the boundary between two MPLS-TP OAM domains. Such a that is at the boundary between two MPLS-TP OAM domains. Such a
node may be present on the edge of two domains or may be 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 connected by a link to the DBN at the edge of another OAM
domain. domain.
Down MEP: A MEP that receives OAM packets from, and transmits Down MEP: A MEP that receives OAM packets from, and transmits
them towards, the direction of a server layer. them towards, the direction of a server layer.
skipping to change at page 8, line 17 skipping to change at page 8, line 29
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 (called MEPs), and the requires management bounded by two points (called MEPs), and the
relationship between those points to which maintenance and relationship between those points to which maintenance and
monitoring 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 section or a
in an OAM domain. transport path 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 that are sent to this particular MIP and may generate messages that are sent to this particular MIP and may generate
OAM messages in reaction to received OAM messages. It never OAM messages in reaction to received OAM messages. It never
generates unsolicited OAM messages itself. A MIP resides within generates unsolicited OAM messages itself. A MIP resides within
a MEG between MEPs (details in 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 MPLS-TP Section: As defined in [8], it is a link that can be
an MPLS-TP LSP. traversed by one or more MPLS-TP LSPs.
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. An OAM domain contains zero or more MEGs.
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 (or
possibly both in the special case of dataplane loopback).
OAM information element: An atomic piece of information OAM information element: An atomic piece of information
exchanged between MEPs and/or MIPs in MEG used by an OAM exchanged between MEPs and/or MIPs in MEG used by an OAM
application. application.
OAM loopback: It is the capability of a node to be directed by a OAM loopback: The capability of a node to be directed by a
received OAM message to generate a reply back to the sender. OAM received OAM message to generate a reply back to the sender. OAM
loopback can work in-service and can support different OAM loopback can work in-service and can support different OAM
functions (e.g., bidirectional on-demand connectivity functions (e.g., bidirectional on-demand 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.
skipping to change at page 9, line 31 skipping to change at page 9, line 42
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 Signal Degrade: A condition declared by a MEP when the data
forwarding capability associated with a transport path has forwarding capability associated with a transport path has
deteriorated, as determined by PM. See also ITU-T recommendation deteriorated, as determined by performance monitoring (PM). See also
G.806 [13]. ITU-T recommendation G.806 [13].
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 ITU-T recommendation failed, e.g. loss of continuity. See also ITU-T recommendation
G.806 [13]. G.806 [13].
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
skipping to change at page 10, line 20 skipping to change at page 10, line 27
characteristics of information transfer between the transport characteristics of information transfer between the transport
path endpoints can be demonstrated to comply with certain path endpoints can be demonstrated to comply with certain
performance and quality guarantees. performance and quality guarantees.
In order to describe the required OAM functionality, this In order to describe the required OAM functionality, this
document introduces a set of 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 define a relationship between any two points of a (MEs) that define a relationship between 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). 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). MEPs and MIPs are
shared by more than one ME in a MEG. associated with the MEG and can be shared by more than one ME in
a MEG.
An abstract reference model for an ME is illustrated in Figure 1 An abstract reference model for an ME is illustrated in Figure 1
below: below:
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
|A|----|B|----|C|----|D| |A|----|B|----|C|----|D|
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
Figure 1 ME Abstract Reference Model Figure 1 ME Abstract Reference Model
The instantiation of this abstract model to different MPLS-TP The instantiation of this abstract model to different MPLS-TP
entities is described in section 4. In Figure 1, nodes A and D entities is described in section 4. In Figure 1, nodes A and D
can be LERs for an LSP or the T-PEs for a MS-PW, nodes B and C can be LERs for an LSP or the T-PEs for a MS-PW, nodes B and C
are LSRs for a LSP or S-PEs for a MS-PW. MEPs reside in nodes A are LSRs for a LSP or S-PEs for a MS-PW. MEPs reside in nodes A
and D while MIPs reside in nodes B and C and may reside in A and and D while MIPs reside in nodes B and C and may reside in A and
D. The links connecting adjacent nodes can be physical links, D. The links connecting adjacent nodes can be physical links,
(sub-)layer LSPs/SPMEs, or serving layer paths. (sub-)layer LSPs/SPMEs, or server layer paths.
This functional model defines the relationships between all OAM This functional model defines the relationships between all OAM
entities from a maintenance perspective, to allow each entities from a maintenance perspective and it allows 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 bound the scope of an OAM flows to the The MEPs that form a MEG bound the scope of an OAM flow to the
MEG (i.e. within the domain of the transport path that is being MEG (i.e. within the domain of the transport path that is being
monitored and managed). There are two exceptions to this: monitored and managed). There are two exceptions to this:
1) A misbranching fault may cause OAM packets to be delivered to 1) A misbranching fault may cause OAM packets to be delivered to
a MEP that is not in the MEG of 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 2) An out-of-band return path may be used between a MIP or a MEP
and the originating 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,
skipping to change at page 13, line 10 skipping to change at page 13, line 10
of instantiating SPMEs are out of scope of this memo. of instantiating SPMEs are out of scope of this memo.
SPMEs can also be employed to meet the requirement to provide SPMEs can also be employed to meet the requirement to provide
tandem connection monitoring (TCM). 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 an SPME that has a 1:1 association with the path by creating an SPME that has a 1:1 association with the path
segment of the transport path that is to be monitored. segment of the transport path that is to be monitored.
In the TCM case, this means that the SPME used to provide TCM In the TCM case, this means that the SPME used to provide TCM
can carry only one and only one transport path thus allowing can carry one and only one transport path thus allowing direct
direct correlation between all fault management and performance correlation between all fault management and performance
monitoring information gathered for the SPME and the monitored monitoring information gathered for the SPME and the monitored
path segment of the end-to-end transport path. The SPME 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 SPME would use the uniform model of TC code point copying 1) The SPME would use the uniform model [22] of TC code point
between sub-layers for diffserv such that the E2E markings copying between sub-layers for diffserv such that the E2E
and PHB treatment for the transport path was preserved by the markings and PHB treatment for the transport path was
SPMEs. preserved by the SPMEs.
2) The SPME normally would use the short-pipe model for TTL 2) The SPME normally would use the short-pipe model for TTL
handling [6] such that MIP addressing for the E2E entity handling [6] such that MIP addressing for the E2E entity
would be not be impacted by the presence of the SPME, but it would be not be impacted by the presence of the SPME, but it
should be possible for an operator to specify use of the should be possible for an operator to specify use of the
uniform model. 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 SPME sub-layer. overhead of the additional SPME sub-layer.
Note that points 1 an 2 above assume that the TTL copying mode Note that points 1 and 2 above assume that the TTL copying mode
and TC copying modes are independently configurable for an LSP. and TC copying modes are independently configurable for an LSP.
There are specific issues with the use of the uniform model of There are specific issues with the use of the uniform model of
TTL copying for an SPME: TTL copying for an SPME:
1. As any MIP in the SPME sub-layer is not part of the transport path 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. MEG, hence only an out of band return path for OAM originating in
the transport path MEG that addressed an SPME MIP might be
available.
2. The instantiation of a lower level MEG or protection switching 2. The instantiation of a lower level MEG or protection switching
actions within a lower level MEG may change the TTL distances to actions within a lower level MEG may change the TTL distances to
MIPs in the higher level MEGs. MIPs in the higher level MEGs.
The endpoints of the SPME are MEPs and limit the scope of an OAM The 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 flow within the MEG that the MEPs belong to (i.e. within the
domain of the SPME that is being monitored and managed). domain of the SPME that is being monitored and managed).
When considering SPMEs, it is important to consider that the When considering SPMEs, it is important to consider that the
following properties apply to all MPLS-TP MEGs: following properties apply to all MPLS-TP MEGs:
o They can be nested but not overlapped, e.g. a MEG may cover a o They can be nested but not overlapped, e.g. a MEG may cover a
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
skipping to change at page 14, line 31 skipping to change at page 14, line 28
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 [7] from the data traffic using the GAL and ACH constructs [7]
for LSP and Section or the ACH construct [3]and [7] for for LSP and Section or the ACH construct [3]and [7] for
(MS-)PW. (MS-)PW.
o When a SPME is instantiated after the transport path has been o When a SPME is instantiated after the transport path has been
instantiated the TTL addressing of the MIPs will change. instantiated the TTL addressing of the MIPs will change for
the pipe model of TTL copying, and will change for the
uniform model if the SPME is not co-routed with the original
path.
3.3. MEG End Points (MEPs) 3.3. MEG End Points (MEPs)
MEG End Points (MEPs) are the source and sink points of a MEG. MEG End Points (MEPs) are the source and sink points of a MEG.
In 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 an SPME LSRs for the MPLS-TP LSP can be while in the context of an SPME LSRs for the MPLS-TP LSP can be
LERs for SPMEs that contribute to the overall monitoring LERs for SPMEs that contribute to the overall monitoring
infrastructure for the transport path. Regarding PWs, only T-PEs infrastructure for the transport path. Regarding PWs, only T-PEs
can implement MEPs while for SPMEs supporting one or more PWs can implement MEPs while for SPMEs supporting one or more PWs
both T-PEs and S-PEs can implement SPME MEPs. Any MPLS-TP LSR both T-PEs and S-PEs can implement SPME MEPs. Any MPLS-TP LSR
can implement a MEP for an MPLS-TP Section. can implement a MEP for an MPLS-TP Section.
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 notifications (such as LKR and MEG. There is a separate class of notifications (such as Lock
AIS) that are originated by intermediate nodes and triggered by report (LKR) and Alarm indication signal (AIS)) that are
server layer events. A MEP is capable of originating and originated by intermediate nodes and triggered by server layer
terminating OAM messages for fault management and performance events. A MEP is capable of originating and terminating OAM
monitoring. These OAM messages are encapsulated into an OAM messages for fault management and performance monitoring. These
packet using the G-ACh as defined in RFC 5586 [7]. In this case OAM messages are encapsulated into an OAM packet using the G-ACh
the G-ACh message is an OAM message and the channel type with an appropriate channel type as defined in RFC 5586 [7]. A
indicates an OAM message. A MEP terminates all the OAM packets MEP terminates all the OAM packets it receives from the MEG it
it receives from the MEG it belongs to and silently discards belongs to and silently discards those that do not (note in the
those that do not (note in the case of a mis-connectivity defect particular case of Connectivity Verification (CV) processing a
there are further actions taken). The MEG the OAM packet belongs CV message from an incorrect MEG will result in a mis-
to is inferred from the MPLS or PW label or, in case of an connectivity defect and there are further actions taken). The
MPLS-TP section, the MEG is inferred from the port on which an MEG the OAM packet belongs to is inferred from the MPLS or PW
OAM packet was received with the GAL at the top of the label label or, in case of an MPLS-TP section, the MEG is inferred
stack. 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 [8]). 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 mechanism 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;
skipping to change at page 15, line 45 skipping to change at page 15, line 46
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 an SPME are not necessarily coincident with the The MEPs of an SPME are not necessarily coincident with the
termination of the MPLS-TP transport path and monitor a path termination of the MPLS-TP transport path. They are used to
segment of the transport path for failures or performance monitor a path segment of the transport path for failures or
degradation (e.g. based on packet counts) only within the performance degradation (e.g. based on packet counts) only
boundary of the MEG for the SPME. within the 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 as upstream or downstream relative to the forwarding
engine.
Source node Destination node Source node Up MEP Destination node Up MEP
------------------------ ------------------------ ------------------------ ------------------------
| | | | | | | |
|----- -----| |----- -----| |----- -----| |----- -----|
| MEP | | | | | | MEP | | MEP | | | | | | MEP |
| | ---- | | | | ---- | | | | ---- | | | | ---- | |
| In |->-| FW |->-| Out |->- ->-| In |->-| FW |->-| Out | | In |->-| FW |->-| Out |->- ->-| In |->-| FW |->-| Out |
| i/f | ---- | i/f | | i/f | ---- | i/f | | i/f | ---- | i/f | | i/f | ---- | i/f |
|----- -----| |----- -----| |----- -----| |----- -----|
| | | | | | | |
------------------------ ------------------------ ------------------------ ------------------------
(1) (2) (1) (2)
Figure 3 Example of per-interface Up MEPs Source node Down MEP Destination node Down MEP
------------------------ ------------------------
| | | |
|----- -----| |----- -----|
| | | MEP | | MEP | | |
| | ---- | | | | ---- | |
| In |->-| FW |->-| Out |->- ->-| In |->-| FW |->-| Out |
| i/f | ---- | i/f | | i/f | ---- | i/f |
|----- -----| |----- -----|
| | | |
------------------------ ------------------------
(3) (4)
Figure 3 describes two examples of per-interface Up MEPs: An Up Figure 3 Examples of per-interface MEPs
Source MEP in a source node (case 1) and an Up Sink MEP in a
destination node (case 2). Figure 3 describes four examples of per-interface Up MEPs: an Up
Source MEP in a source node (case 1), an Up Sink MEP in a
destination node (case 2), a Down Source MEP in a source node
(case 3) and a Down Sink MEP in a destination node (case 4).
The usage of per-interface Up MEPs extends the coverage of the 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.
skipping to change at page 17, line 24 skipping to change at page 17, line 41
3.4. MEG Intermediate Points (MIPs) 3.4. MEG Intermediate Points (MIPs)
A MEG Intermediate Point (MIP) is a function located at a point A MEG Intermediate Point (MIP) is a function located at a point
between the MEPs of a MEG for a PW, LSP or SPME. between the MEPs of a MEG for a PW, LSP or SPME.
A MIP is capable of reacting to some OAM packets and forwarding all A MIP is capable of reacting to some OAM packets and forwarding all
the other OAM packets while ensuring fate sharing with data plane the other OAM packets while ensuring fate sharing with data plane
packets. However, a MIP does not initiate unsolicited OAM packets, packets. However, a MIP does not initiate unsolicited OAM packets,
but may be addressed by OAM packets initiated by one of the MEPs of but may be addressed by OAM packets initiated by one of the MEPs of
the MEG. A MIP can generate OAM packets only in response to OAM the MEG. A MIP can generate OAM packets only in response to OAM
packets that are sent on the MEG it belongs to. The OAM messages packets that it receives from the MEG it belongs to. The OAM messages
generated by the MIP are sent in the direction of the source MEP and generated by the MIP are sent in the direction of the source MEP and
not forwarded to the sink MEP. 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).
skipping to change at page 18, line 38 skipping to change at page 19, line 6
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
layer being referenced. sub-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 provides server layer OAM indications to the A server MEP also provides server layer OAM indications to the
client/server adaptation function between the client (MPLS-TP) client/server adaptation function between the client (MPLS-TP)
(sub-)layer network and the server (sub-)layer network. The (sub-)layer network and the server (sub-)layer network. The
adaptation function maintains state on the mapping of MPLS-TP adaptation function maintains state on the mapping of MPLS-TP
transport paths that are setup over that server (sub-)layer's transport paths that are setup over that server (sub-)layer's
transport path. transport path.
skipping to change at page 19, line 52 skipping to change at page 20, line 19
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. Hence a single OAM packet can simultaneously
instrument all the MEs in a p2mp MEG.
o To send an OAM packet to a single leaf, the source MEP 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
skipping to change at page 20, line 25 skipping to change at page 20, line 42
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. processed only by the target MIP.
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. Aggregated or subsetting mechanisms are outside the leaves. Aggregated or sub setting mechanisms are outside
scope of this document. the 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 exhaustion 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.
3.8. Further considerations of enhanced segment monitoring
Segment monitoring in transport network should meet the
following network objectives:
1. The monitoring and maintenance of existing transport paths has to
be conducted in service without traffic disruption.
2. The monitored or managed transport path condition has to be
exactly the same irrespective of any configurations necessary for
maintenance.
SPMEs defined in section 3.2 meet the above two objectives, when
they are pre-configured or pre-instantiated as exemplified in
section 3.6. However, pre-design and pre-configuration of all
the considered patterns of SPME are not sometimes preferable in
real operation due to the burden of design works, a number of
header consumptions, bandwidth consumption and so on.
When SPMEs are configured or instantiated after the transport
path has been created, network objective (1) can be met, but
network objective (2) cannot be met due to new assignment of
MPLS labels.
Support for a more sophisticated segment monitoring mechanism
(temporal and hitless segment monitoring) to efficiently meet
the two network objectives may be necessary.
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 RFC 5860 [11]. the functional requirements specified in RFC 5860 [11].
The following MPLS-TP MEGs are specified in this document: The following MPLS-TP MEGs are specified in this document:
o A Section Maintenance Entity Group (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 SPME ME Group (LSMEG), allowing monitoring and o An LSP SPME ME Group (LSMEG), allowing monitoring and
management of an SPME (between any LERs/LSRs along an LSP). management of an SPME (between a given pair of LERs and/or
LSRs along an LSP).
o A PW SPME ME Group (PSMEG), allowing monitoring and o A PW SPME ME Group (PSMEG), allowing monitoring and
management of an SPME (between any T-PEs/S-PEs along the management of an SPME (between a given pair of T-PEs and/or
(MS-)PW). S-PEs along an (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 SPMEs. In Hierarchical LSPs are also supported in the form of SPMEs. In
this case, each LSP in the hierarchy is a different sub-layer this case, each LSP in the hierarchy is a different sub-layer
network that can be monitored, independently from higher and network that can be monitored, independently from higher and
lower level LSPs in the hierarchy, on an end-to-end basis (from lower level LSPs in the hierarchy, on an end-to-end basis (from
LER to LER) by a SPME. It is possible to monitor a portion of a LER to LER) by a SPME. It is possible to monitor a portion of a
hierarchical LSP by instantiating a hierarchical SPME between hierarchical LSP by instantiating a hierarchical SPME between
skipping to change at page 25, line 49 skipping to change at page 26, line 12
OAM packets must fate share with the user data packets sent over OAM packets must fate share with the user data packets sent over
the monitored LSP path segment. the monitored LSP path segment.
A LSME 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 LSME 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 behavior of a part of an LSP or set of
of LSPs rather than the entire LSP itself, for example when LSPs rather than the entire LSP itself, for example when there
there is a need to monitor a part of an LSP that extends beyond is a need to monitor a part of an LSP that extends beyond the
the administrative boundaries of an MPLS-TP enabled administrative boundaries of an MPLS-TP enabled administrative
administrative domain. 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 |
skipping to change at page 26, line 49 skipping to change at page 27, line 13
(LSPXZ LSME). (LSPXZ LSME).
It is worth noticing that LSMEs can coexist with the LME It is worth noticing that LSMEs can coexist with the LME
monitoring the end-to-end LSP and that LSME 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 LSME MEP). the LSP1Z LME MEP and the LSP13 LSME MEP).
4.5. MPLS-TP MS-PW SPME Monitoring (PSME) 4.5. MPLS-TP MS-PW SPME Monitoring (PSME)
An MPLS-TP MS-PW SPME Monitoring ME (PSME) is an MPLS-TP SPME An MPLS-TP MS-PW SPME Monitoring ME (PSME) is an MPLS-TP SPME
with associated maintenance entity intended to monitor an with associated maintenance entity intended to monitor an
arbitrary part of an MS-PW between the pair of MEPs instantiated arbitrary part of an MS-PW between the pair of MEPs instantiated
form the SPME independently from the end-to-end monitoring form the SPME independently from the end-to-end monitoring
(PME). A PSME can monitor a PW segment or concatenated segment (PME). A PSME can monitor a PW segment or concatenated segment
and it may also include the forwarding engine(s) of the node(s) and it may also include the forwarding engine(s) of the node(s)
at the edge(s) of the segment or concatenated segment. A PSME is at the edge(s) of the segment or concatenated segment. A PSME is
no different than an SPME, it is simply named as such to discuss no different than an SPME, it is simply named as such to discuss
SPMEs specifically in a PW context. SPMEs specifically in a PW context.
When SPME is established between non-adjacent S-PEs, the edges When SPME is established between non-adjacent S-PEs, the edges
of the SPME becomes adjacent at the MS-PW sub-layer network and of the SPME becomes adjacent at the MS-PW sub-layer network and
skipping to change at page 27, line 28 skipping to change at page 27, line 39
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 appear not to have the flexibility that architecture would appear not to have the flexibility that
arbitrary placement of SPME segments would imply. Support for an arbitrary placement of SPME segments would imply. Support for an
arbitrary placement of PSME would require the definition of arbitrary placement of PSME would require the definition of
additional PW sub-layering. additional PW sub-layering.
Multiple hierarchical PSMEs can be configured on any MS-PW. PSME Multiple hierarchical PSMEs can be configured on any MS-PW. PSME
OAM packets fate share with the user data packets sent over the OAM packets fate share with the user data packets sent over the
monitored PW path Segment. monitored PW path Segment.
A PSME does not add hierarchical components to the MPLS architecture,
it defines the role of existing components for the purposes of
discussing OAM functionality.
A PSME can be defined between the following entities: A PSME can be defined between the following entities:
o T-PE and any S-PE of a given MS-PW o T-PE and any S-PE of a given MS-PW
o Any two S-PEs of a given MS-PW. o Any two S-PEs of a given MS-PW.
Note that, in line with the SPME description in section 3.2, when a Note that, in line with the SPME description in section 3.2, when a
PW SPME is instantiated after the MS-PW has been instantiated, the PW SPME is instantiated after the MS-PW has been instantiated, the
TTL addressing of the MIPs may change and MIPs in the nested MEG are TTL addressing of the MIPs may change and MIPs in the nested MEG are
no longer part of the encompassing MEG. This means that the S-PE 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 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 LSP level. The consequences are that the S-PEs hosting the PSME MEPs
become adjacent S-PEs. This is no different than the operation of become adjacent S-PEs. This is no different than the operation of
SPMEs in general. SPMEs in general.
A PSME is intended to be deployed in scenarios where it is 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 behavior 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| +---+
skipping to change at page 29, line 14 skipping to change at page 29, line 25
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.
The implications for OAM is that not all components of a The implications for OAM is that not all components of a
multilink will be exercised, independent server layer OAM being multilink will be exercised, independent server layer OAM being
required to exercise the aggregated link components. This has required to exercise the aggregated link components. This has
further implications for MIP and MEP placement, as per-interface further implications for MIP and MEP placement, as per-interface
MIPs or "down" MEPs on a multilink interface are akin to a layer MIPs or "down" MEPs on a multilink interface are akin to a layer
violation, as they instrument at the granularity of the server violation, as they instrument at the granularity of the server
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 are 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 usually performed "in-service". Such Proactive monitoring is usually performed "in-service". Such
transactions are universally MEP to MEP in operation while transactions are universally MEP to MEP in operation while
notifications emerging from the serving layer are MIP to MEP or notifications can be node to node (e.g. some MS-PW transactions)
can be MIP to MIP. The control and measurement considerations or node to MEPs (e.g., AIS). The control and measurement
are: 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, Loss Measurement (LM) etc.) are
configured at the MEPs.
3. Server layer events are reported by transactions originating 3. Server layer events are reported by OAM messages originating
at intermediate nodes. at intermediate nodes.
4. The measurements resulting from proactive monitoring are 4. The measurements resulting from proactive monitoring are
typically only reported outside of the MEG as unsolicited typically reported outside of the MEG (e.g. to a management
notifications for "out of profile" events, such as faults or system) as notifications events such as faults or loss
loss measurement indication of excessive impairment of measurement indication of excessive impairment of information
information transfer capability. transfer capability.
5. The measurements resulting from proactive monitoring may be 5. The measurements resulting from proactive monitoring may be
periodically harvested by an EMS/NMS. periodically harvested by an EMS/NMS.
For statically provisioned transport paths the above information For statically provisioned transport paths the above information
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 may enable/disable some of the consequent actions
defined in section 5.1.1.4. defined in section 5.1.1.4.
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 RFC 5860 [11], are used to detect a loss of continuity 2.2.2 of RFC 5860 [11], are used to detect a loss of continuity
defect (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 RFC 5860 [11], are used to detect an unexpected section 2.2.3 of RFC 5860 [11], are used to detect an unexpected
skipping to change at page 31, line 5 skipping to change at page 31, line 21
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
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 co-routed or associated, bidirectional point-to-point
enabled to generate pro-active CC-V OAM packets with a transport path, when a MEP is enabled to generate pro-active
configured transmission rate, it also expects to receive pro- CC-V OAM packets with a configured transmission rate, it also
active CC-V OAM packets from its peer MEP at the same expects to receive pro-active CC-V OAM packets from its peer MEP
transmission rate as a common SLA applies to all components of at the same transmission rate as a common SLA applies to all
the transport path. In a unidirectional transport path (either components of the transport path. In a unidirectional transport
point-to-point or point-to-multipoint), only the source MEP is path (either point-to-point or point-to-multipoint), only the
enabled to generate CC-V OAM packets and only the sink MEP is source MEP is enabled to generate CC-V OAM packets and only the
configured to expect these packets at the configured rate. sink MEP is configured to expect these packets at the configured
rate.
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 pro-active CC-V information and forward are transparent to the pro-active CC-V information and forward
these pro-active CC-V OAM packets as regular data packets. these pro-active CC-V OAM packets as regular data packets.
During path setup and tear down, situations arise where CC-V During path setup and tear down, situations arise where CC-V
checks would give rise to alarms, as the path is not fully checks would give rise to alarms, as the path is not fully
instantiated. In order to avoid these spurious alarms the instantiated. In order to avoid these spurious alarms the
following procedures are recommended. At initialization, the MEP following procedures are recommended. At initialization, the MEP
source function (generating pro-active CC-V packets) should be source function (generating pro-active CC-V packets) should be
enabled prior to the corresponding MEP sink function (detecting enabled prior to the corresponding MEP sink function (detecting
continuity and connectivity defects). When disabling the CC-V continuity and connectivity defects). When disabling the CC-V
proactive functionality, the MEP sink function should be proactive functionality, the MEP sink function should be
disabled prior to the corresponding MEP source function. disabled prior to the corresponding MEP source function.
It should be noted that different encapsulations are possible
for CC-V packets and therefore it is possible that in case of
mis-configurations or mis-connectivity, CC-V packets are
received with an unexpected encapsulation.
There are practical limitations to detecting unexpected
encapsulation. It is possible that there are mis-configuration
or mis-connectivity scenarios where OAM packets can alias as
payload, e.g., when a transport path can carry an arbitrary
payload without a pseudo wire.
When CC-V packets are received with an unexpected encapsulation
that can be parsed by the sink MEP, the CC-V packet is processed
as it were received with the correct encapsulation and if it is
not a manifestation of a mis-connectivity defect a warning is
raised (see section 5.1.1.4). Otherwise the CC-V packet may be
silently discarded as unrecognized and a LOC defect may be
detected (see section 5.1.1.1).
The defect conditions are described in no specific order.
5.1.1. Defects identified by CC-V 5.1.1. Defects identified by CC-V
Pro-active CC-V functions allow a sink MEP to detect the defect 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 source 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
source MEP with the correct encapsulation (and in the case of source MEP (and in the case of CV, this includes the
CV, this includes the requirement to have a correct globally requirement to have the expected globally unique Source MEP
unique Source MEP identifier) are received within the identifier) are received within the interval equal to 3.5
interval equal to 3.5 times the receiving MEP's configured 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 source o Exit criteria: A pro-active CC-V OAM packet from the source
MEP with the correct encapsulation (and again in the case of MEP (and again in the case of CV, with the expected globally
CV, with the correct globally unique Source MEP identifier) unique Source MEP identifier) is 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) when the received packet misconnection or unintended looping) when the received packet
carries an incorrect globally unique Source MEP identifier. carries an unexpected globally unique Source MEP identifier.
o Entry criteria: The sink MEP receives a pro-active CC-V OAM o Entry criteria: The sink MEP receives a pro-active CC-V OAM
packet with an incorrect globally unique Source MEP packet with an unexpected globally unique Source MEP
identifier or receives a CC or CC/CV OAM packet with an identifier or receives a CC or CC/CV OAM packet with an
unexpected encapsulation. unexpected encapsulation.
o Exit criteria: The sink MEP does not receive any pro-active o Exit criteria: The sink MEP does not receive any pro-active
CC-V OAM packet with an incorrect globally unique Source MEP CC-V OAM packet with an unexpected globally unique Source MEP
identifier for an interval equal at least to 3.5 times the identifier for an interval equal at least to 3.5 times the
longest 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 unexpected globally unique Source
identifier since this defect has been raised. This requires MEP identifier since this defect has been raised. This
the OAM message to self identify the CC-V periodicity as not requires the OAM message to self identify the CC-V
all MEPs can be expected to have knowledge of all MEGs. periodicity as not 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 the expected
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 the expected 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 the expected 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 the
correct globally unique Source MEP identifier and an expected 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.1.4. Unexpected encapsulation defect 5.1.1.4. Unexpected encapsulation defect
If pro-active CC-V OAM packets are received with a correct If pro-active CC-V OAM packets are received with the expected
globally unique Source MEP identifier but with an unexpected globally unique Source MEP identifier but with an unexpected
encapsulation, then a CV unexpected encapsulation defect is encapsulation, then a CV unexpected encapsulation defect is
detected. detected.
o Entry criteria: A MEP receives a CC-V pro-active packet with It should be noted that there are practical limitations to
correct globally unique Source MEP identifier but with an detecting unexpected encapsulation (see section 5.1.1).
unexpected encapsulation.
It should be noted that there are practical limitations to o Entry criteria: A MEP receives a CC-V pro-active packet with
detecting unexpected encapsulation. It is possible that there the expected globally unique Source MEP identifier but with
are mis-connectivity scenarios where OAM frames can alias as an unexpected encapsulation.
payload if a transport path can carry an arbitrary payload
without a pseudo wire. In this case, the mis-connectivity
defect can not be detected but a LOC defect may be detected
instead.
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 the expected globally unique Source MEP
identifier and an unexpected encapsulation for an interval identifier and an unexpected encapsulation for an interval
equal at least to 3.5 times the longest transmission period equal at least to 3.5 times the longest transmission period
of the pro-active CC-V OAM packets received with a correct of the pro-active CC-V OAM packets received with the expected
globally unique Source MEP identifier and an unexpected globally unique Source MEP identifier and an unexpected
encapsulation since this defect has been raised. encapsulation since this defect has been raised.
5.1.2. Consequent action 5.1.2. Consequent action
A sink MEP that detects one of the defect conditions defined in A sink MEP that detects any of the defect conditions defined in
section 5.1.1 performs the following consequent actions. section 5.1.1 declares a defect condition and performs the
following consequent actions.
If a MEP detects an unexpected globally unique Source MEP If a MEP detects an unexpected globally unique Source MEP
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
skipping to change at page 34, line 35 skipping to change at page 35, line 17
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) it declares a signal mis-connectivity defect (section 5.1.1.2) 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 It is a matter if local policy if a MEP that detects a period
misconfiguration defect (section 5.1.1.3) declares a signal fail misconfiguration defect (section 5.1.1.3) declares a signal fail
condition at the transport path level. condition at the transport path level.
The detection of an unexpected encapsulation defect does not
have any consequent action: it is just a warning for the network
operator. An implementation able to detect an unexpected
encapsulation but not able to verify the source MEP ID may
choose to declare a mis-connectivity defect.
5.1.3. Configuration considerations 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 the other MEPs in 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 MEP ID from which the the list would consist of the single MEP ID from which the
OAM packets are expected. In case of the root MEP of a p2mp OAM packets are expected. In case of the root MEP of a p2mp
MEG, the list is composed by all the leaf MEP IDs inside the MEG, the list is composed by all the leaf MEP IDs inside 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 behavior 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):
skipping to change at page 36, line 17 skipping to change at page 36, line 49
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. Which consequent action can be consequent actions. Which consequent action can be
enabled/disabled are described in section 5.1.1.4. enabled/disabled are described in section 5.1.1.4.
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 RFC 5860 [11], is an indicator that is section 2.2.9 of RFC 5860 [11], is an indicator that is
transmitted by a sink MEP to communicate to its source MEP that transmitted by a sink MEP to communicate to its source MEP that
a signal fail condition exists. RDI is only used for a signal fail condition exists. RDI is only used for all
bidirectional connections and is associated with proactive CC-V. co-routed and associated bidirectional transport paths and is
The RDI indicator is piggy-backed onto the CC-V packet. associated with proactive CC-V. The RDI indicator can be 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. When incorporated into CC-V,
included in all pro-active CC-V packets that it generates for the RDI information will be included in all pro-active CC-V
the duration of the signal fail condition's existence. packets that it generates for the duration of the signal fail
condition's existence.
A MEP that receives packets from a peer MEP (as best can be A MEP that receives packets from a peer MEP with the RDI
validated with the CC or CV tool in use) with the RDI
information should determine that its peer MEP has encountered a information should determine that its peer MEP has encountered a
defect condition associated with a signal fail. 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 OAM packets
CC-V packets that include the RDI indicator as regular data that include the RDI indicator as regular data packets, i.e. the
packets, i.e. the MIP should not perform any actions nor examine 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- stop transmitting the RDI indicator to its peer MEP. When
active CC-V packets. A MEP should clear the RDI defect upon incorporated into CC-V, the RDI indicator will be cleared from
reception of a pro-active CC-V packet from the source MEP with subsequent transmission of pro-active CC-V packets. A MEP
the RDI indicator cleared. should clear the RDI defect upon reception of an RDI indicator
cleared.
5.2.1. Configuration considerations 5.2.1. Configuration considerations
In order to support RDI indication, this may be a unique OAM In order to support RDI indication, the indication may be a
message or an OAM information element embedded in a CV message. unique OAM message or an OAM information element embedded in a
In this case the RDI transmission rate and PHB of the OAM CV message; the RDI transmission rate and PHB of the OAM packets
packets carrying RDI should be the same as that configured for 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
RFC 5860 [11], relies upon an Alarm Indication Signal (AIS) RFC 5860 [11], relies upon an Alarm Indication Signal (AIS)
message to suppress alarms following detection of defect message to suppress alarms following detection of defect
conditions at the server (sub-)layer. conditions at the server (sub-)layer.
When a server MEP asserts signal fail, it notifies that to the When a server MEP asserts signal fail, it notifies that to the
co-located MPLS-TP client/server adaptation function which then co-located MPLS-TP client/server adaptation function which then
skipping to change at page 37, line 38 skipping to change at page 38, line 22
alarms associated with its peer MEP but does not block traffic alarms associated with its peer MEP but does not block traffic
received from the transport path. A MEP resumes loss of 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 MIPs, as well as intermediate nodes, do not process AIS
information and forward these AIS OAM packets as regular data information and forward these AIS OAM packets as regular data
packets. packets.
For example, let's consider a fiber cut between LSR 1 and LSR 2 For example, let's consider a fiber cut between 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 of the
described in Figure 5 have pro-active CC-V enabled, a LOC defect MEGs described in Figure 5 have pro-active CC-V enabled, a LOC
is detected by the MEPs of Sec12 SME, LSP13 LME, PW1 PSME and defect is detected by the MEPs of Sec12 SME, LSP13 LME, PW1 PSME
PW1Z PME, however in a transport network only the alarm and PW1Z PME, however in a transport network only the alarm
associated to the fiber cut needs to be reported to an NMS while associated to the fiber cut needs to be reported to an NMS while
all secondary alarms should be suppressed (i.e. not reported to all secondary alarms should be suppressed (i.e. not reported to
the 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
skipping to change at page 40, line 7 skipping to change at page 40, line 48
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 RFC 5860 [11]. LM is used path as required in section 2.2.11 of RFC 5860 [11]. LM is used
to 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 co-routed or associated bidirectional
time of the transport path. Each MEP performs measurements of transport path) during the life time of the transport path. Each
its transmitted and received packets. These measurements are MEP performs measurements of its transmitted and received
then correlated with the peer MEP in the ME to derive the impact packets. These measurements are then correlated in real time
of packet loss on a number of performance metrics for the ME in with the peer MEP in the ME to derive the impact of packet loss
the MEG. The LM transactions are issued such that the OAM on a number of performance metrics for the ME in the MEG. The LM
packets will experience the same queuing discipline as the transactions are issued such that the OAM packets will
measured traffic while transiting between the MEPs in the ME. experience the same queuing discipline as the measured traffic
while transiting between the MEPs in the ME.
For a MEP, near-end packet loss refers to packet loss associated For a MEP, near-end packet loss refers to packet loss associated
with 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 MIPs, as well as intermediate nodes, do not process the LM
information and forward these pro-active LM OAM packets as information and forward these pro-active LM OAM packets as
regular data packets. regular data packets.
skipping to change at page 41, line 20 skipping to change at page 42, line 16
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 RFC 5860 [11]. Specifically, pro-active DM is section 2.2.12 of RFC 5860 [11]. Specifically, pro-active DM is
used to measure the long-term packet delay and packet delay used to measure the long-term packet delay and packet delay
variation in 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 co-routed or associated bidirectional
configurable time interval. transport path) during a 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.
skipping to change at page 42, line 50 skipping to change at page 43, line 44
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
operations such as e.g. diagnostics to investigate into a defect operations such as diagnostics to investigate a defect
condition. condition.
On-demand monitoring covers a combination of "in-service" and On-demand monitoring covers a combination of "in-service" and
"out-of-service" monitoring functions. The control and "out-of-service" monitoring functions. The control and
measurement implications are: measurement implications are:
1. A MEG can be directed to perform an "on-demand" functions at 1. A MEG can be directed to perform an "on-demand" functions at
arbitrary times in the lifetime of a transport path. arbitrary times in the lifetime of a transport path.
2. "out-of-service" monitoring functions may require a-priori 2. "out-of-service" monitoring functions may require a-priori
skipping to change at page 45, line 9 skipping to change at page 46, line 4
should be configured. should be configured.
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 the diagnosis of QoS
for a transport path, as required in section 2.2.11 of RFC 5860 performances for a transport path, as required in section 2.2.11
[11]. As proactive LM, on-demand LM is used to exchange counter of RFC 5860 [11]. As proactive LM, on-demand LM is used to
values for the number of ingress and egress packets transmitted exchange counter values for the number of ingress and egress
and received by the transport path monitored by a pair of MEPs. packets transmitted and received by the transport path monitored
LM is not performed MEP to MIP or between a pair of MIPs. by a pair of MEPs. LM is only performed between a pair of MEPs.
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 co-routed or associated bidirectional
defined monitoring period. Each MEP performs measurements of its transport path) during a pre-defined monitoring period. Each MEP
transmitted and received packets. These measurements are then performs measurements of its transmitted and received packets.
correlated to evaluate the packet loss performance metrics of These measurements are then correlated to evaluate the packet
the transport path. loss performance metrics of 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 MIPs, as well as intermediate nodes, do not process the LM
information and forward these on-demand LM OAM packets as information and forward these on-demand LM OAM packets as
regular data packets. regular data packets.
6.2.1. Configuration considerations 6.2.1. Configuration considerations
skipping to change at page 46, line 17 skipping to change at page 47, line 17
Diagnostic tests are tests performed on a MEG that has been taken Diagnostic tests are tests performed on a MEG that has been taken
out-of-service. 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 RFC 5860 [11], that allows as required in section 2.2.5 of RFC 5860 [11], that allows
verifying the bandwidth/throughput of an MPLS-TP transport path verifying the bandwidth/throughput of an MPLS-TP transport path
(LSP or PW) 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 between MEP
performed in one-way or two-way modes. and MIP. It and can be performed in one-way or two-way modes.
According to RFC 2544 [12], this test is performed by sending According to RFC 2544 [12], this test is performed by sending
OAM test packets at increasing rate (up to the theoretical OAM test packets at increasing rate (up to the theoretical
maximum), graphing the percentage of OAM test packets received maximum), graphing the percentage of OAM test packets received
and reporting the rate at which OAM test packets begin to drop. and reporting the rate at which OAM test packets begin to drop.
In general, this rate is dependent 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 a specified packet size and transmission test packets with a specified packet size and transmission
pattern at a rate to exercise the throughput. pattern at a rate to exercise the throughput.
For a one-way test, the remote MEP sink receives the OAM test For a one-way test, the remote MEP sink receives the OAM test
packets and calculates the packet loss. For a two-way test, the packets and calculates the packet loss. For a two-way test, the
remote MEP loopbacks the OAM test packets back to original MEP remote MEP loopbacks the OAM test packets back to original MEP
and the local MEP sink calculates the packet loss. However, a and the local MEP sink calculates the packet loss.
two-way test will return the minimum of available throughput in
the two directions. Alternatively it is possible to run two
individual one-way tests to get a distinct measurement in the
two directions.
It is worth noting that two-way throughput estimation can only It is worth noting that two-way throughput estimation can only
evaluate the minimum of available throughput of the two evaluate the minimum of available throughput of the two
directions. In order to estimate the throughput of each directions. In order to estimate the throughput of each
direction uniquely, two one-way throughput estimation sessions direction uniquely, two one-way throughput estimation sessions
have to be setup. have to be setup.
MIPs, as well as intermediate nodes, do not process the MIPs that are not target by on-demand test OAM packets, as well
throughput test information and forward these on-demand test OAM as intermediate nodes, do not process the throughput test
packets as regular data packets. 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 an 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.
skipping to change at page 47, line 37 skipping to change at page 48, line 31
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 RFC 5860 [11], that permits all traffic in section 2.2.5 of RFC 5860 [11]. This function consists in
(including user data and OAM, with the exception of the disable placing a transport path, at either an intermediate or
loopback command) originated at the ingress of a transport path terminating node, into a data plane loopback state, such that
or inserted by the test equipment to be looped back unmodified all traffic (including both payload and OAM) received on the
(other than normal per hop processing such as TTL decrement) in looped back interface is sent on the reverse direction of the
the direction of the point of origin by an interface at either transport path. The traffic is looped back unmodified other than
an intermediate node or a terminating node. TTL is decremented normal per hop processing such as TTL decrement.
normally during this process. It is also normal to disable
proactive monitoring of the path as the source MEP will see all The data plane loopback function requires that the MEG is locked
source MEP originated OAM messages returned to it. such that user data traffic is prevented from entering/exiting
that MEG. Instead, test traffic is inserted at the ingress of
the MEG. This test traffic can be generated from an internal
process residing within the ingress node or injected by external
test equipment connected to the ingress node.
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.
The only way to send an OAM packet to a node set in the data
plane loopback mode is via TTL expiry, irrespectively on whether
the node is hosting MIPs or MEPs. It should also be noted that
MIPs can be addressed with more than one TTL value on a
co-routed bi-directional path set into dataplane loopback.
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 It should be noted that data plane loopback function itself is
whether it implements more than one point is implementation applied to data-plane loopback points that can resides on
dependent. different interfaces from MIPs/MEPs. Where a node implements
data plane loopback capability and whether it implements it in
more than one point is implementation dependent.
6.3.2.1. Configuration considerations
Data plane loopback is an out-of-service tool. The MEG which
defines a diagnosed transport path should be put into a locked
state before the diagnostic test is started. However, a means is
required to permit the originated test traffic to be inserted at
ingress MEP when data plane loopback is performed.
A transport path, at either an intermediate or terminating node,
can be put into data plane loopback state via an NMS action or
using an OAM tool for data plane loopback configuration.
If the data plane loopback point is set somewhere at an
intermediate point of a co-routed bidirectional transport path,
the side of loop back function (one side or both side) needs to
be configured.
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,
and may be conducted after provisioning an MPLS-TP transport and may be conducted after provisioning an MPLS-TP transport
path for, e.g., trouble shooting purposes such as fault path for, e.g., trouble shooting purposes such as fault
localization. localization.
The route tracing function, as required in section 2.2.4 of RFC The route tracing function, as required in section 2.2.4 of RFC
skipping to change at page 48, line 29 skipping to change at page 50, line 9
sharing requirement of OAM flows, i.e. OAM packets receive the sharing requirement of OAM flows, i.e. OAM packets receive the
same forwarding treatment as data packet, route tracing is a same forwarding treatment as data packet, route tracing is a
basic means to perform connectivity verification and, to a much basic means to perform connectivity verification and, to a much
lesser degree, continuity check. For this function to work lesser degree, continuity check. For this function to work
properly, a 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 exists, the route trace
function will only be able to tract up to the defect, and needs function will only be able to trace up to the defect, and needs
to be able to return the incomplete list of OAM entities that it to be able to return the incomplete list of OAM entities that it
was able to trace such that the fault can be localized. was able to trace such that the fault can be localized.
6.4.1. Configuration considerations 6.4.1. Configuration considerations
The configuration of the route trace function must at least The configuration of the route 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
skipping to change at page 49, line 4 skipping to change at page 50, line 32
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 RFC 5860 [11]. Specifically, on-demand DM in section 2.2.12 of RFC 5860 [11]. Specifically, on-demand DM
is used to measure packet delay and packet delay variation in is used to measure packet delay and packet delay variation in
the transport path monitored by a pair of MEPs during a pre- the transport path monitored by a pair of MEPs during a pre-
defined monitoring period. defined monitoring period.
On-Demand DM is performed by sending periodic DM OAM packets On-Demand DM is performed by sending periodic DM OAM packets
from a 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 co-routed or associated bidirectional
configurable time interval. transport path) during a configurable time interval.
On-demand DM can be operated in two ways: On-demand DM can be operated in two modes:
o One-way: a MEP sends DM OAM packet to its peer MEP containing o One-way: a MEP sends 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 an DM OAM packet as a DM peer MEP, which replies with an DM OAM packet as a DM
skipping to change at page 50, line 11 skipping to change at page 51, line 39
RFC 5860 [11], is a command allowing a MEP to instruct the peer RFC 5860 [11], is a command allowing a MEP to instruct the peer
MEP(s) to put the MPLS-TP transport path into a locked MEP(s) to put the MPLS-TP transport path into a locked
condition. condition.
This function allows single-side provisioning for This function allows single-side provisioning for
administratively 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 puts both MEPs into an
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 MIPs, as well as intermediate nodes, do not process the lock
instruct information and forward these on-demand LKI OAM packets instruct information and forward these on-demand LKI OAM packets
as regular data 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 an NMS, sends an LKI request OAM packet to its peer MEP(s). from an NMS, sends an LKI request OAM packet to its peer MEP(s).
It also puts the MPLS-TP transport path into a locked state and It also puts the MPLS-TP transport path into a locked state and
notifies its client (sub-)layer adaptation function upon the notifies its client (sub-)layer adaptation function upon the
locked condition. locked condition.
A MEP, upon receiving an LKI request from its peer MEP, can A MEP, upon receiving an LKI request from its peer MEP, can
accept or not the instruction and replies to the peer MEP with either accept or reject the instruction and replies to the peer
an LKI reply OAM packet indicating whether it has accepted or MEP with an LKI reply OAM packet indicating whether or not it
not the instruction. This requires either an in-band or out-of- has accepted the instruction. This requires either an in-band or
band return path. out-of-band return path.
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 notifies its client MPLS-TP transport path into a locked state and notifies its
(sub-)layer adaptation function upon the locked condition. client (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 either
or not the removal instruction and replies with an LKI removal accept or reject the removal instruction and replies with an LKI
reply OAM packet indicating whether it has accepted or not the removal reply OAM packet indicating whether or not it has
instruction. accepted the 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
notifies this event to its client (sub-)layer adaptation notifies this event to its client (sub-)layer adaptation
function. 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 notifies this event condition on the MPLS-TP transport path and notifies this event
to its client (sub-)layer adaptation function. to its client (sub-)layer adaptation function.
skipping to change at page 51, line 26 skipping to change at page 53, line 7
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.
OAM traffic can reveal sensitive information such as passwords, OAM traffic can reveal sensitive information such as passwords,
performance data and details about e.g. the network topology. performance data and details about e.g. the network topology.
The nature of OAM data therefore suggests to have some form of The nature of OAM data therefore suggests that some form of
authentication, authorization and encryption in place. This will authentication, authorization and encryption is in place. This
prevent unauthorized access to vital equipment and it will 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
skipping to change at page 54, line 35 skipping to change at page 55, line 35
[19] ITU-T Recommendation G.805 (03/00), "Generic functional [19] ITU-T Recommendation G.805 (03/00), "Generic functional
architecture of transport networks", March 2000 architecture of transport networks", March 2000
[20] ITU-T Recommendation Y.1731 (02/08), "OAM functions and [20] ITU-T Recommendation Y.1731 (02/08), "OAM functions and
mechanisms for Ethernet based networks", February 2008 mechanisms for Ethernet based networks", February 2008
[21] IEEE Standard 802.1AX-2008, "IEEE Standard for Local and [21] IEEE Standard 802.1AX-2008, "IEEE Standard for Local and
Metropolitan Area Networks - Link Aggregation", November Metropolitan Area Networks - Link Aggregation", November
2008 2008
[22] Le Faucheur et.al. " Multi-Protocol Label Switching (MPLS)
Support of Differentiated Services", RFC 3270, May 2002.
Authors' Addresses Authors' Addresses
Dave Allan Dave Allan
Ericsson Ericsson
Email: david.i.allan@ericsson.com Email: david.i.allan@ericsson.com
Italo Busi Italo Busi
Alcatel-Lucent Alcatel-Lucent
 End of changes. 111 change blocks. 
296 lines changed or deleted 422 lines changed or added

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