draft-ietf-mpls-tp-oam-framework-07.txt   draft-ietf-mpls-tp-oam-framework-08.txt 
MPLS Working Group I. Busi (Ed) MPLS Working Group I. Busi (Ed)
Internet Draft Alcatel-Lucent Internet Draft Alcatel-Lucent
Intended status: Informational B. Niven-Jenkins (Ed) Intended status: Informational D. Allan (Ed)
BT
D. Allan (Ed)
Ericsson Ericsson
Expires: January 12, 2011 July 12, 2010 Expires: March 17, 2011 September 17, 2010
MPLS-TP OAM Framework Operations, Administration and Maintenance Framework for MPLS-
draft-ietf-mpls-tp-oam-framework-07.txt based Transport Networks
draft-ietf-mpls-tp-oam-framework-08.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 13 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 January 12, 2011. This Internet-Draft will expire on March 17, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described document must include Simplified BSD License text as described
in Section 4.e of the Trust Legal Provisions and are provided in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the BSD License. without warranty as described in the 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....................................20 3.7. P2MP considerations....................................19
4. Reference Model............................................21 4. Reference Model............................................20
4.1. MPLS-TP Section Monitoring (SME).......................23 4.1. MPLS-TP Section Monitoring (SME).......................23
4.2. MPLS-TP LSP End-to-End Monitoring (LME)................24 4.2. MPLS-TP LSP End-to-End Monitoring (LME)................24
4.3. MPLS-TP PW Monitoring (PME)............................24 4.3. MPLS-TP PW Monitoring (PME)............................24
4.4. MPLS-TP LSP SPME Monitoring (LSME).....................25 4.4. MPLS-TP LSP SPME Monitoring (LSME).....................25
4.5. MPLS-TP MS-PW SPME Monitoring (PSME)...................26 4.5. MPLS-TP MS-PW SPME Monitoring (PSME)...................26
4.6. Fate sharing considerations for multilink..............28 4.6. Fate sharing considerations for multilink..............28
5. OAM Functions for proactive monitoring......................29 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........................31
5.1.2. Consequent action.................................33 5.1.2. Consequent action.................................33
5.1.3. Configuration considerations......................34 5.1.3. Configuration considerations......................34
5.2. Remote Defect Indication...............................35 5.2. Remote Defect Indication...............................36
5.2.1. Configuration considerations......................36 5.2.1. Configuration considerations......................36
5.3. Alarm Reporting........................................36 5.3. Alarm Reporting........................................37
5.4. Lock Reporting........................................38 5.4. Lock Reporting........................................38
5.5. Packet Loss Measurement................................39 5.5. Packet Loss Measurement................................39
5.5.1. Configuration considerations......................40 5.5.1. Configuration considerations......................40
5.5.2. Sampling skew.....................................40 5.5.2. Sampling skew.....................................40
5.5.3. Multilink issues..................................40 5.5.3. Multilink issues..................................40
5.6. Packet Delay Measurement...............................41 5.6. Packet Delay Measurement...............................41
5.6.1. Configuration considerations......................41 5.6.1. Configuration considerations......................41
5.7. Client Failure Indication..............................41 5.7. Client Failure Indication..............................42
5.7.1. Configuration considerations......................42 5.7.1. Configuration considerations......................42
6. OAM Functions for on-demand monitoring......................42 6. OAM Functions for on-demand monitoring......................42
6.1. Connectivity Verification..............................43 6.1. Connectivity Verification..............................43
6.1.1. Configuration considerations......................44 6.1.1. Configuration considerations......................44
6.2. Packet Loss Measurement................................45 6.2. Packet Loss Measurement................................45
6.2.1. Configuration considerations......................45 6.2.1. Configuration considerations......................45
6.2.2. Sampling skew.....................................45 6.2.2. Sampling skew.....................................45
6.2.3. Multilink issues..................................46 6.2.3. Multilink issues..................................45
6.3. Diagnostic Tests.......................................46 6.3. Diagnostic Tests.......................................46
6.3.1. Throughput Estimation.............................46 6.3.1. Throughput Estimation.............................46
6.3.2. Data plane Loopback...............................47 6.3.2. Data plane Loopback...............................47
6.4. Route Tracing.........................................48 6.4. Route Tracing.........................................48
6.4.1. Configuration considerations......................48 6.4.1. Configuration considerations......................48
6.5. Packet Delay Measurement...............................48 6.5. Packet Delay Measurement...............................48
6.5.1. Configuration considerations......................49 6.5.1. Configuration considerations......................49
7. OAM Functions for administration control....................49 7. OAM Functions for administration control....................49
7.1. Lock Instruct.........................................49 7.1. Lock Instruct.........................................49
7.1.1. Locking a transport path..........................50 7.1.1. Locking a transport path..........................50
7.1.2. Unlocking a transport path........................50 7.1.2. Unlocking a transport path........................50
8. Security Considerations.....................................51 8. Security Considerations.....................................51
9. IANA Considerations........................................51 9. IANA Considerations........................................51
10. Acknowledgments...........................................52 10. Acknowledgments...........................................51
11. References................................................53 11. References................................................53
11.1. Normative References..................................53 11.1. Normative References..................................53
11.2. Informative References................................54 11.2. Informative References................................54
Editors' Note: Editors' Note:
This Informational Internet-Draft is aimed at achieving IETF This Informational Internet-Draft is aimed at achieving IETF
Consensus before publication as an RFC and will be subject to an Consensus before publication as an RFC and will be subject to an
IETF Last Call. IETF Last Call.
[RFC Editor, please remove this note before publication as an [RFC Editor, please remove this note before publication as an
RFC and insert the correct Streams Boilerplate to indicate that RFC and insert the correct Streams Boilerplate to indicate that
the published RFC has IETF Consensus.] the published RFC has IETF Consensus.]
1. Introduction 1. Introduction
As noted in [8], the transport profile of multi-protocol label As noted in the multi-protocol label switching (MPLS-TP) Framework
switching (MPLS-TP) is a packet-based transport technology based on RFCs (RFC 5921 [8] and [9]), MPLS-TP is a packet-based transport
the MPLS Traffic Engineering (MPLS-TE) and Pseudo Wire (PW) data technology based on the MPLS Traffic Engineering (MPLS-TE) and Pseudo
plane architectures defined in RFC 3031 [1], RFC 3985 [2] and RFC Wire (PW) data plane architectures defined in RFC 3031 [1], RFC 3985
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 and that do not
rely on the presence of a control plane. rely on the presence of a control plane.
In line with [13], 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 [10]. 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. [17]). mechanisms (e.g. [18]).
The MPLS-TP OAM framework is applicable to both LSPs and The MPLS-TP OAM framework is applicable to both LSPs and
(MS-)PWs and supports co-routed and associated bidirectional p2p (MS-)PWs and supports co-routed and associated bidirectional p2p
transport paths as well as unidirectional p2p and p2mp transport transport paths as well as unidirectional p2p and p2mp transport
paths. paths.
This document is a product of a joint Internet Engineering Task This document is a product of a joint Internet Engineering Task
Force (IETF) / International Telecommunication Union Force (IETF) / International Telecommunication Union
Telecommunication Standardization Sector (ITU-T) effort to Telecommunication Standardization Sector (ITU-T) effort to
include an MPLS Transport Profile within the IETF MPLS and PWE3 include an MPLS Transport Profile within the IETF MPLS and PWE3
skipping to change at page 7, line 4 skipping to change at page 6, line 51
PHB Per-hop Behavior PHB Per-hop Behavior
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].
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 [14]. 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 [8]).
Where appropriate, the following definitions are aligned with Where appropriate, the following definitions are aligned with
ITU-T recommendation Y.1731 [19] 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 an interface
at either an intermediate or terminating node in a path is at either an intermediate or terminating node in a path is
placed into a data plane loopback state, such that all traffic placed into a data plane loopback state, such that all traffic
skipping to change at page 9, line 34 skipping to change at page 9, line 32
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 PM. See also ITU-T recommendation
G.806 [12]. 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 [12]. 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
boundaries of the tandem connection. Tandem connections may be boundaries of the tandem connection. Tandem connections may be
nested but cannot overlap. See also ITU-T recommendation G.805 nested but cannot overlap. See also ITU-T recommendation G.805
[18]. [19].
Up MEP: A MEP that transmits OAM packets towards, and receives Up MEP: A MEP that transmits OAM packets towards, and receives
them from, the direction of the forwarding engine. them from, the direction of the forwarding engine.
3. Functional Components 3. Functional Components
MPLS-TP is a packet-based transport technology based on the MPLS MPLS-TP is a packet-based transport technology based on the MPLS
and PW data plane architectures ([1], [2] and [4]) and is and PW data plane architectures ([1], [2] and [4]) and is
capable of transporting service traffic where the capable of transporting service traffic where the
characteristics of information transfer between the transport characteristics of information transfer between the transport
skipping to change at page 11, line 14 skipping to change at page 11, line 12
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 flows 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 12, line 30 skipping to change at page 12, line 30
o Fault conditions - some faults may impact more than one ME o Fault conditions - some faults may impact more than one ME
depending from where the failure is located; depending from where the failure is located;
o Packet loss - packet dropping may impact more than one ME o Packet loss - packet dropping may impact more than one ME
depending from where the packets are lost; depending from where the packets are lost;
o Packet delay - will be unique per ME. o Packet delay - will be unique per ME.
Each leaf (i.e. D, E and F) terminates OAM flows to monitor the Each leaf (i.e. D, E and F) terminates OAM flows to monitor the
ME from itself and the root while the root (i.e. A) generates ME between itself and the root while the root (i.e. A) generates
OAM messages common to all the MEs of the p2mp MEG. All nodes OAM messages common to all the MEs of the p2mp MEG. All nodes
may implement a MIP in the corresponding MEG. may implement a MIP in the corresponding MEG.
3.2. Nested MEGs: SPMEs and Tandem Connection Monitoring 3.2. Nested MEGs: SPMEs and Tandem Connection Monitoring
In order to verify and maintain performance and quality In order to verify and maintain performance and quality
guarantees, there is a need to not only apply OAM functionality guarantees, there is a need to not only apply OAM functionality
on a transport path granularity (e.g. LSP or MS-PW), but also on on a transport path granularity (e.g. LSP or MS-PW), but also on
arbitrary parts of transport paths, defined as Tandem arbitrary parts of transport paths, defined as Tandem
Connections, between any two arbitrary points along a transport Connections, between any two arbitrary points along a transport
skipping to change at page 14, line 35 skipping to change at page 14, line 31
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 addressing of the MIPs will change. instantiated the TTL addressing of the MIPs will change.
3.3. MEG End Points (MEPs) 3.3. MEG End Points (MEPs)
MEG End Points (MEPs) are the source and sink points of a MEG. MEG End Points (MEPs) are the source and sink points of a MEG.
In the context of an MPLS-TP LSP, only LERs can implement MEPs In the context of an MPLS-TP LSP, only LERs can implement MEPs
while in the context of 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
skipping to change at page 18, line 27 skipping to change at page 18, line 11
Figure 4 describes an example of two per-interface MIPs at an Figure 4 describes an example of two per-interface MIPs at an
intermediate node of a point-to-point MEG. intermediate node of a point-to-point MEG.
The usage of per-interface MIPs allows the isolation of failures The usage of per-interface MIPs allows the isolation of failures
or performance degradation to being within a node or either the or performance degradation to being within a node or either the
link or interfaces. link or interfaces.
When sending an OAM packet to a MIP, the source MEP should set When sending an OAM packet to a MIP, the source MEP should set
the TTL field to indicate the number of hops necessary to reach the TTL field to indicate the number of hops necessary to reach
the node where the MIP resides. It is always assumed that the the node where the MIP resides.
"short pipe" model of TTL handling is used by the MPLS transport
profile.
The source MEP should also include Target MIP information in the The source MEP should also include Target MIP information in the
OAM packets sent to a MIP to allow proper identification of the OAM packets sent to a MIP to allow proper identification of the
MIP within the node. The MEG the OAM packet is associated with MIP within the node. The MEG the OAM packet is associated with
is inferred from the MPLS label. is inferred from the MPLS label.
A node at the edge of a MEG can also support per-interface Up A node at the edge of a MEG can also support per-interface Up
MEPs and per-interface MIPs on either side of the forwarding MEPs and per-interface MIPs on either side of the forwarding
engine. engine.
skipping to change at page 19, line 16 skipping to change at page 18, line 44
encapsulates and transports the MPLS-TP layer network being encapsulates and transports the MPLS-TP layer network being
referenced, or referenced, or
o Defined in a sub-layer of the MPLS-TP layer network that is o Defined in a sub-layer of the MPLS-TP layer network that is
"below" which is to say encapsulates and transports the sub- "below" which is to say encapsulates and transports the sub-
layer being referenced. layer being referenced.
A server MEP can coincide with a MIP or a MEP in the client A server MEP can coincide with a MIP or a MEP in the client
(MPLS-TP) (sub-)layer network. (MPLS-TP) (sub-)layer network.
A server MEP also interacts with the client/server adaptation A server MEP also provides server layer OAM indications to the
function between the client (MPLS-TP) (sub-)layer network and client/server adaptation function between the client (MPLS-TP)
the server (sub-)layer network. The adaptation function (sub-)layer network and the server (sub-)layer network. The
maintains state on the mapping of MPLS-TP transport paths that adaptation function maintains state on the mapping of MPLS-TP
are setup over that server (sub-)layer's transport path. transport paths that are setup over that server (sub-)layer's
transport path.
For example, a server MEP can be either: For example, a server MEP can be either:
o A termination point of a physical link (e.g. 802.3), an SDH o A termination point of a physical link (e.g. 802.3), an SDH
VC or OTN ODU, for the MPLS-TP Section layer network, defined VC or OTN ODU, for the MPLS-TP Section layer network, defined
in section 4.1; in section 4.1;
o An MPLS-TP Section MEP for MPLS-TP LSPs, defined in section o An MPLS-TP Section MEP for MPLS-TP LSPs, defined in section
4.2; 4.2;
o An MPLS-TP LSP MEP for MPLS-TP PWs, defined in section 4.3; o An MPLS-TP LSP MEP for MPLS-TP PWs, defined in section 4.3;
o An MPLS-TP SPME MEP used for LSP path segment monitoring, as o An MPLS-TP SPME MEP used for LSP path segment monitoring, as
defined in section 4.4, for MPLS-TP LSPs or higher-level defined in section 4.4, for MPLS-TP LSPs or higher-level
SPMEs providing LSP path segment monitoring; SPMEs providing LSP path segment monitoring;
o An MPLS-TP SPME MEP used for PW path segment monitoring, as o An MPLS-TP SPME MEP used for PW path segment monitoring, as
defined in section 4.5, for MPLS-TP PWs or higher-level SPMEs defined in section 4.5, for MPLS-TP PWs or higher-level SPMEs
providing PW path segment monitoring. providing PW path segment monitoring.
The server MEP can run appropriate OAM functions for fault The server MEP can run appropriate OAM functions for fault detection
detection within the server (sub-)layer network, and provides a within the server (sub-)layer network, and provides a fault
fault indication to its client MPLS-TP layer network. Server MEP indication to its client MPLS-TP layer network via the client/server
adaptation function. When the server layer is not MPLS-TP, server MEP
OAM functions are outside the scope of this document. OAM functions are outside the scope of this document.
3.6. Configuration Considerations 3.6. Configuration Considerations
When a control plane is not present, the management plane When a control plane is not present, the management plane configures
configures these functional components. Otherwise they can be these functional components. Otherwise they can be configured either
configured either by the management plane or by the control by the management plane or by the control plane.
plane.
Local policy allows disabling the usage of any available "out- Local policy allows disabling the usage of any available "out-
of-band" return path, as defined in [8], irrespective of what is of-band" return path, as defined in [8], irrespective of what is
requested by the node originating the OAM packet. requested by the node originating the OAM packet.
SPMEs are usually instantiated when the transport path is SPMEs are usually instantiated when the transport path is
created by either the management plane or by the control plane created by either the management plane or by the control plane
(if present). Sometimes an SPME can be instantiated after the (if present). Sometimes an SPME can be instantiated after the
transport path is initially created. transport path is initially created.
skipping to change at page 21, line 13 skipping to change at page 20, line 41
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.
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 [10]. 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
skipping to change at page 22, line 24 skipping to change at page 22, line 24
+----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
. . . . . . . .
| | | | | | | |
|<--- Domain 1 -->| |<--- Domain Z -->| |<--- Domain 1 -->| |<--- Domain Z -->|
^----------------- PW1Z PME -----------------^ ^----------------- PW1Z PME -----------------^
^--- PW13 PSME ---^ ^--- PWXZ PSME ---^ ^--- PW13 PSME ---^ ^--- PWXZ PSME ---^
^-------^ ^-------^ ^-------^ ^-------^
LSP13 LME LSPXZ LME LSP13 LME LSPXZ LME
^--^ ^--^ ^---------^ ^--^ ^--^ ^--^ ^--^ ^---------^ ^--^ ^--^
Sec12 Sec23 Sec3X SecXY SecYZ Sec12 Sec23 Sec3X SecXY SecYZ
SME SME SME SME SME SME SME SME SME SME
TPE1: Terminating Provider Edge 1 SPE2: Switching Provider Edge TPE1: Terminating Provider Edge 1 SPE2: Switching Provider Edge
3 3
TPEX: Terminating Provider Edge X SPEZ: Switching Provider Edge TPEX: Terminating Provider Edge X SPEZ: Switching Provider Edge
Z Z
^---^ ME ^ MEP ==== LSP .... PW ^---^ ME ^ MEP ==== LSP .... PW
Figure 5 Reference Model for the MPLS-TP OAM Framework Figure 5 Reference Model for the MPLS-TP OAM Framework
skipping to change at page 25, line 26 skipping to change at page 25, line 26
^-------------------PW1Z PME------------------^ ^-------------------PW1Z PME------------------^
Figure 6 MPLS-TP PW ME (PME) Figure 6 MPLS-TP PW ME (PME)
Figure 6 depicts a MS-PW (MS-PW1Z) consisting of three path Figure 6 depicts a MS-PW (MS-PW1Z) consisting of three path
segments: PW13, PW3X and PWXZ and its associated end-to-end PME segments: PW13, PW3X and PWXZ and its associated end-to-end PME
(PW1Z PME). (PW1Z PME).
4.4. MPLS-TP LSP SPME Monitoring (LSME) 4.4. MPLS-TP LSP SPME Monitoring (LSME)
An MPLS-TP LSP SPME ME (LSME) is an MPLS-TP LSP with associated An MPLS-TP LSP SPME ME (LSME) is an MPLS-TP SPME with associated
maintenance entity intended to monitor an arbitrary part of an maintenance entity intended to monitor an arbitrary part of an
LSP between the pair of MEPs instantiated for the SPME LSP between the pair of MEPs instantiated for the SPME
independent from the end-to-end monitoring (LME). An LSME can independent from the end-to-end monitoring (LME). An LSME can
monitor an LSP segment or concatenated segment and it may also monitor an LSP segment or concatenated segment and it may also
include the forwarding engine(s) of the node(s) at the edge(s) include the forwarding engine(s) of the node(s) at the edge(s)
of the segment or concatenated segment. of the segment or concatenated segment.
Multiple LSMEs can be configured on any LSP. The LSRs that When SPME is established between non-adjacent LSRs, the edges of
terminate the LSME may or may not be immediately adjacent at the the SPME becomes adjacent at the LSP sub-layer network and any
MPLS-TP layer. LSME OAM packets must fate share with the user LSR that were previously in between becomes an LSR for the SPME.
data packets sent over the monitored LSP path segment.
Multiple hierarchical LSMEs can be configured on any LSP. LSME
OAM packets must fate share with the user data packets sent over
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 behaviour of a part of an LSP or set
of LSPs rather than the entire LSP itself, for example when of LSPs rather than the entire LSP itself, for example when
skipping to change at page 26, line 46 skipping to change at page 26, line 48
LSME monitoring the LSPXZ Concatenated Segment on Domain Z LSME monitoring the LSPXZ Concatenated Segment on Domain Z
(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 An MPLS-TP MS-PW SPME Monitoring ME (PSME) is an MPLS-TP SPME
maintenance entity intended to monitor an arbitrary part of an with associated maintenance entity intended to monitor an
MS-PW between a given pair of PEs independently from the end-to- arbitrary part of an MS-PW between the pair of MEPs instantiated
end monitoring (PME). A PSME can monitor a PW segment or form the SPME independently from the end-to-end monitoring
concatenated segment and it may also include the forwarding (PME). A PSME can monitor a PW segment or concatenated segment
engine(s) of the node(s) at the edge(s) of the segment or and it may also include the forwarding engine(s) of the node(s)
concatenated segment. 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
SPMEs specifically in a PW context.
When SPME is established between non-adjacent S-PEs, the edges
of the SPME becomes adjacent at the MS-PW sub-layer network and
any S-PEs that were previously in between becomes an LSR for the
SPME.
S-PE placement is typically dictated by considerations other S-PE placement is typically dictated by considerations other
than OAM. S-PEs will frequently reside at operational boundaries than OAM. S-PEs will frequently reside at operational boundaries
such as the transition from distributed (CP) to centralized such as the transition from distributed (CP) to centralized
(NMS) control or at a routing area boundary. As such the (NMS) control or at a routing area boundary. As such the
architecture would superficially appear not to have the architecture would appear not to have the flexibility that
flexibility that arbitrary placement of SPME segments would arbitrary placement of SPME segments would imply. Support for an
imply. More arbitrary placement of MEs for a PW would require arbitrary placement of PSME would require the definition of
additional hierarchical components, beyond the SPMEs between PEs additional PW sub-layering.
Multiple PSMEs can be configured on any MS-PW. The PEs may or Multiple hierarchical PSMEs can be configured on any MS-PW. PSME
may not be immediately adjacent at the MS-PW layer. PSME OAM OAM packets fate share with the user data packets sent over the
packets fate share with the user data packets sent over the
monitored PW path Segment. monitored PW path Segment.
A 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. It can span several PW o Any two S-PEs of a given MS-PW.
segments.
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
addressing of the MIPs will change and MIPs in the nested MEG are no TTL addressing of the MIPs may change and MIPs in the nested MEG are
longer part of the encompassing MEG. This means that the S-PE nodes no longer part of the encompassing MEG. This means that the S-PE
hosting these MIPs are no longer S-PEs but P nodes at the SPME LSP nodes hosting these MIPs are no longer S-PEs but P nodes at the SPME
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. become adjacent S-PEs. This is no different than the operation of
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 behaviour of a part of a MS-PW rather
than the entire end-to-end PW itself, for example to monitor an than the entire end-to-end PW itself, for example to monitor an
MS-PW path segment within a given network domain of an inter- MS-PW path segment within a given network domain of an inter-
domain MS-PW. domain MS-PW.
|<----------------- MS-PW1Z ----------------->| |<----------------- MS-PW1Z ------------------>|
| | | |
| |<LSP13>| |<-LSP3X->| |<LSPXZ>| | | |<LSP13>| |<-LSP3X-->| |<LSPXZ>| |
V V LSP V V LSP V V LSP V V V V LSP V V LSP V V LSP V V
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
+---+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +---+ +---+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +---+
| |AC1| |=======| |=========| |=======| |AC2| | | |AC1| |=======| |==========| |=======| |AC2| |
|CE1|---|.......PW13......|...PW3X..|.......PWXZ......|---|CE2| |CE1|---|.......PW13......|...PW3X...|.......PWXZ......|---|CE2|
| | | |=======| |=========| |=======| | | | | | | |=======| |==========| |=======| | | |
+---+ | 1 | |2| | 3 | | X | |Y| | Z | +---+ +---+ | 1 | |2| | 3 | | X | |Y| | Z | +---+
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
^--- PW1 PSME ----^ ^--- PW5 PSME ----^ ^--- PW13 PSME ---^ ^--- PWXZ PSME ----^
^-------------------PW1Z PME------------------^ ^-------------------PW1Z PME-------------------^
Figure 8 MPLS-TP MS-PW SPME Monitoring (PSME) Figure 8 MPLS-TP MS-PW SPME Monitoring (PSME)
Figure 8 depicts the same MS-PW (MS-PW1Z) between AC1 and AC2 as Figure 8 depicts the same MS-PW (MS-PW1Z) between AC1 and AC2 as
in Figure 6. In this scenario there are two separate PSMEs in Figure 6. In this scenario there are two separate PSMEs
configured to monitor MS-PW1Z: 1) a PSME monitoring the PW13 MS- configured to monitor MS-PW1Z: 1) a PSME monitoring the PW13
PW path segment on Domain 1 (PW13 PSME), and 2) a PSME MS-PW path segment on Domain 1 (PW13 PSME), and 2) a PSME
monitoring the PWXZ MS-PW path segment on Domain Z with (PWXZ monitoring the PWXZ MS-PW path segment on Domain Z with (PWXZ
PSME). PSME).
It is worth noticing that PSMEs can coexist with the PME It is worth noticing that PSMEs can coexist with the PME
monitoring the end-to-end MS-PW and that PSME MEPs and PME MEPs monitoring the end-to-end MS-PW and that PSME MEPs and PME MEPs
can be coincident in the same node (e.g. TPE1 node supports both can be coincident in the same node (e.g. TPE1 node supports both
the PW1Z PME MEP and the PW13 PSME MEP). the PW1Z PME MEP and the PW13 PSME MEP).
4.6. Fate sharing considerations for multilink 4.6. Fate sharing considerations for multilink
Multilink techniques are in use today and are expected to Multilink techniques are in use today and are expected to
continue to be used in future deployments. These techniques continue to be used in future deployments. These techniques
include Ethernet Link Aggregations [20], the use of Link include Ethernet Link Aggregations [21], the use of Link
Bundling for MPLS [16] where the option to spread traffic over Bundling for MPLS [17] where the option to spread traffic over
component links is supported and enabled. While the use of Link component links is supported and enabled. While the use of Link
Bundling can be controlled at the MPLS-TP layer, use of Link Bundling can be controlled at the MPLS-TP layer, use of Link
Aggregation (or any server layer specific multilink) is not Aggregation (or any server layer specific multilink) is not
necessarily under control of the MPLS-TP layer. Other techniques necessarily under control of the MPLS-TP layer. Other techniques
may emerge in the future. These techniques share the may emerge in the future. These techniques share the
characteristic that an LSP may be spread over a set of component characteristic that an LSP may be spread over a set of component
links and therefore be reordered but no flow within the LSP is links and therefore be reordered but no flow within the LSP is
reordered (except when very infrequent and minimally disruptive reordered (except when very infrequent and minimally disruptive
load rebalancing occurs). load rebalancing occurs).
skipping to change at page 30, line 6 skipping to change at page 30, line 6
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 enables/disables some of the consequent actions
defined in section 5.1.2. 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 [10], 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 [10], are used to detect an unexpected section 2.2.3 of RFC 5860 [11], are used to detect an unexpected
connectivity defect between two MEGs (e.g. mismerging or connectivity defect between two MEGs (e.g. mismerging or
misconnection), as well as unexpected connectivity within the misconnection), as well as unexpected connectivity within the
MEG with an unexpected MEP. MEG with an unexpected MEP.
Both functions are based on the (proactive) generation of OAM Both functions are based on the (proactive) generation of OAM
packets by the source MEP that are processed by the sink MEP. As packets by the source MEP that are processed by the sink MEP. As
a consequence these two functions are grouped together into a consequence these two functions are grouped together into
Continuity Check and Connectivity Verification (CC-V) OAM Continuity Check and Connectivity Verification (CC-V) OAM
packets. packets.
In order to perform pro-active Connectivity Verification, each In order to perform pro-active Connectivity Verification, each
CC-V OAM packet also includes a globally unique Source MEP CC-V OAM packet also includes a globally unique Source MEP
identifier. When used to perform only pro-active Continuity identifier. When used to perform only pro-active Continuity
Check, the CC-V OAM packet will not include any globally unique Check, the CC-V OAM packet will not include any globally unique
Source MEP identifier. Different formats of MEP identifiers are Source MEP identifier. Different formats of MEP identifiers are
defined in [9] to address different environments. When MPLS-TP defined in [10] to address different environments. When MPLS-TP
is deployed in transport network environments where IP is deployed in transport network environments where IP
addressing is not used in the forwarding plane, the ICC-based addressing is not used in the forwarding plane, the ICC-based
format for MEP identification is used. When MPLS-TP is deployed format for MEP identification is used. When MPLS-TP is deployed
in an IP-based environment, the IP-based MEP identification is in an IP-based environment, the IP-based MEP identification is
used. used.
As a consequence, it is not possible to detect misconnections As a consequence, it is not possible to detect misconnections
between two MEGs monitored only for continuity as neither the between two MEGs monitored only for continuity as neither the
OAM message type nor OAM message content provides sufficient OAM message type nor OAM message content provides sufficient
information to disambiguate an invalid source. To expand: information to disambiguate an invalid source. To expand:
skipping to change at page 32, line 37 skipping to change at page 32, line 35
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 incorrect 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 incorrect 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.
It should be noted that there are practical limitations to
detecting unexpected encapsulation. It is possible that there
are mis-connectivity scenarios where OAM frames can alias as
payload IF a transport path can carry an arbitrary payload
without a pseudo wire.
o Exit criteria: The sink MEP does not receive any pro-active o Exit criteria: The sink MEP does not receive any pro-active
CC-V OAM packet with an incorrect globally unique Source MEP CC-V OAM packet with an incorrect globally unique Source MEP
identifier for an interval equal at least to 3.5 times the identifier for an interval equal at least to 3.5 times the
longest transmission period of the pro-active CC-V OAM longest transmission period of the pro-active CC-V OAM
packets received with an incorrect globally unique Source MEP packets received with an incorrect globally unique Source MEP
identifier since this defect has been raised. This requires identifier since this defect has been raised. This requires
the OAM message to self identify the CC-V periodicity as not the OAM message to self identify the CC-V periodicity as not
all MEPs can be expected to have knowledge of all MEGs. all MEPs can be expected to have knowledge of all MEGs.
5.1.1.3. Period Misconfiguration defect 5.1.1.3. Period Misconfiguration defect
skipping to change at page 33, line 26 skipping to change at page 33, line 19
o Exit criteria: The sink MEP does not receive any pro-active o Exit criteria: The sink MEP does not receive any pro-active
CC-V OAM packet with a correct globally unique Source MEP CC-V OAM packet with a correct globally unique Source MEP
identifier and an incorrect transmission period for an identifier and an incorrect transmission period for an
interval equal at least to 3.5 times the longest transmission interval equal at least to 3.5 times the longest transmission
period of the pro-active CC-V OAM packets received with a period of the pro-active CC-V OAM packets received with a
correct globally unique Source MEP identifier and an correct globally unique Source MEP identifier and an
incorrect transmission period since this defect has been incorrect transmission period since this defect has been
raised. raised.
5.1.1.4. Unexpected encapsulation defect
If pro-active CC-V OAM packets are received with a correct
globally unique Source MEP identifier but with an unexpected
encapsulation, then a CV unexpected encapsulation defect is
detected.
o Entry criteria: A MEP receives a CC-V pro-active packet with
correct globally unique Source MEP identifier but with an
unexpected encapsulation.
It should be noted that there are practical limitations to
detecting unexpected encapsulation. It is possible that there
are mis-connectivity scenarios where OAM frames can alias as
payload if a transport path can carry an arbitrary payload
without a pseudo wire. 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
CC-V OAM packet with a correct globally unique Source MEP
identifier and an unexpected encapsulation for an interval
equal at least to 3.5 times the longest transmission period
of the pro-active CC-V OAM packets received with a correct
globally unique Source MEP identifier and an unexpected
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 one of the defect conditions defined in
section 5.1.1 performs the following consequent actions. section 5.1.1 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
operator. operator.
It is worth noticing that the OAM requirements document [10] It is worth noticing that the OAM requirements document [11]
recommends that CC-V proactive monitoring be enabled on every recommends that CC-V proactive monitoring be enabled on every
MEG in order to reliably detect connectivity defects. However, MEG in order to reliably detect connectivity defects. However,
CC-V proactive monitoring can be disabled by an operator for a CC-V proactive monitoring can be disabled by an operator for a
MEG. In the event of a misconnection between a transport path MEG. In the event of a misconnection between a transport path
that is pro-actively monitored for CC-V and a transport path that is pro-actively monitored for CC-V and a transport path
which is not, the MEP of the former transport path will detect a which is not, the MEP of the former transport path will detect a
LOC defect representing a connectivity problem (e.g. a LOC defect representing a connectivity problem (e.g. a
misconnection with a transport path where CC-V proactive misconnection with a transport path where CC-V proactive
monitoring is not enabled) instead of a continuity problem, with monitoring is not enabled) instead of a continuity problem, with
a consequent wrong traffic delivering. For these reasons, the a consequent wrong traffic delivering. For these reasons, the
skipping to change at page 35, line 39 skipping to change at page 36, line 12
Note that the reception period is the same as the configured Note that the reception period is the same as the configured
transmission rate. transmission rate.
For statically provisioned transport paths the above parameters For statically provisioned transport paths the above parameters
are statically configured; for dynamically established transport are statically configured; for dynamically established transport
paths the configuration information are signaled via the control paths the configuration information are signaled via the control
plane. plane.
The operator should be able to enable/disable some of the The operator should be able to enable/disable some of the
consequent actions. Which consequent action can be consequent actions. Which consequent action can be
enabled/disabled are described in section 5.1.2. 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 [10], 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
bidirectional connections and is associated with proactive CC-V. bidirectional connections and is associated with proactive CC-V.
The RDI indicator is piggy-backed onto the CC-V packet. The RDI indicator is piggy-backed onto the CC-V packet.
When a MEP detects a signal fail condition (e.g. in case of a When a MEP detects a signal fail condition (e.g. in case of a
continuity or connectivity defect), it should begin transmitting continuity or connectivity defect), it should begin transmitting
an RDI indicator to its peer MEP. The RDI information will be an RDI indicator to its peer MEP. The RDI information will be
included in all pro-active CC-V packets that it generates for included in all pro-active CC-V packets that it generates for
the duration of the signal fail condition's existence. the duration of the signal fail condition's existence.
skipping to change at page 36, line 36 skipping to change at page 37, line 8
In order to support RDI indication, this may be a unique OAM In order to support RDI indication, this may be a unique OAM
message or an OAM information element embedded in a CV message. message or an OAM information element embedded in a CV message.
In this case the RDI transmission rate and PHB of the OAM In this case the RDI transmission rate and PHB of the OAM
packets carrying RDI should be the same as that configured for packets carrying RDI should be the same as that configured for
CC-V. CC-V.
5.3. Alarm Reporting 5.3. Alarm Reporting
The Alarm Reporting function, as required in section 2.2.8 of The Alarm Reporting function, as required in section 2.2.8 of
RFC 5860 [10], 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, the co-located MPLS-TP When a server MEP asserts signal fail, it notifies that to the
client (sub-)layer adaptation function generates packets with co-located MPLS-TP client/server adaptation function which then
AIS information in the downstream direction to allow the generates packets with AIS information in the downstream
suppression of secondary alarms at the MEP in the client (sub- direction to allow the suppression of secondary alarms at the
)layer. MPLS-TP MEP in the client (sub-)layer.
The generation of packets with AIS information starts The generation of packets with AIS information starts
immediately when the server MEP asserts signal fail. These immediately when the server MEP asserts signal fail. These
periodic packets, with AIS information, continue to be periodic packets, with AIS information, continue to be
transmitted until the signal fail condition is cleared. It is transmitted until the signal fail condition is cleared. It is
assumed that to avoid race conditions a MEP detecting loss of assumed that to avoid spurious alarm generation a MEP detecting
continuity will wait for a hold off interval prior to asserting loss of continuity will wait for a hold off interval prior to
an alarm to the management system. asserting an alarm to the management system.
Upon receiving a packet with AIS information an MPLS-TP MEP Upon receiving a packet with AIS information an MPLS-TP MEP
enters an AIS defect condition and suppresses loss of continuity enters an AIS defect condition and suppresses loss of continuity
alarms associated with its peer MEP 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
skipping to change at page 38, line 15 skipping to change at page 38, line 31
AIS packets are transmitted with the "minimum loss probability AIS packets are transmitted with the "minimum loss probability
PHB" within a single network operator. This PHB is configurable PHB" within a single network operator. This PHB is configurable
on network operator's basis. on network operator's basis.
AIS condition is cleared if no AIS message has been received in AIS condition is cleared if no AIS message has been received in
3.5 times the AIS transmission period. 3.5 times the AIS transmission period.
5.4. Lock Reporting 5.4. Lock Reporting
The Lock Reporting function, as required in section 2.2.7 of RFC The Lock Reporting function, as required in section 2.2.7 of RFC
5860 [10], relies upon a Locked Report (LKR) message used to 5860 [11], relies upon a Locked Report (LKR) message used to
suppress alarms following administrative locking action in the suppress alarms following administrative locking action in the
server (sub-)layer. server (sub-)layer.
When a server MEP is locked, the MPLS-TP client (sub-)layer When a server MEP is locked, the MPLS-TP client (sub-)layer
adaptation function generates packets with LKR information in adaptation function generates packets with LKR information in
both directions to allow the suppression of secondary alarms at both directions to allow the suppression of secondary alarms at
the MEPs in the client (sub-)layer. Again it is assumed that the MEPs in the client (sub-)layer. Again it is assumed that
there is a hold off for any loss of continuity alarms in the there is a hold off for any loss of continuity alarms in the
client layer MEPs downstream of the node originating the locked client layer MEPs downstream of the node originating the locked
report. report.
skipping to change at page 39, line 41 skipping to change at page 39, line 47
on network operator's basis. on network operator's basis.
Locked condition is cleared if no LKR packet has been received Locked condition is cleared if no LKR packet has been received
for 3.5 times the transmission period. for 3.5 times the transmission period.
5.5. Packet Loss Measurement 5.5. Packet Loss Measurement
Packet Loss Measurement (LM) is one of the capabilities Packet Loss Measurement (LM) is one of the capabilities
supported by the MPLS-TP Performance Monitoring (PM) function in supported by the MPLS-TP Performance Monitoring (PM) function in
order to facilitate reporting of QoS information for a transport order to facilitate reporting of QoS information for a transport
path as required in section 2.2.11 of RFC 5860 [10]. 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 bidirectional transport path) during the life
time of the transport path. Each MEP performs measurements of time of the transport path. Each MEP performs measurements of
its transmitted and received packets. These measurements are its transmitted and received packets. These measurements are
then correlated with the peer MEP in the ME to derive the impact then correlated with the peer MEP in the ME to derive the impact
skipping to change at page 40, line 25 skipping to change at page 40, line 32
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.
5.5.1. Configuration considerations 5.5.1. Configuration considerations
In order to support proactive LM, the transmission rate and PHB In order to support proactive LM, the transmission rate and PHB
class associated with the LM OAM packets originating from a MEP class associated with the LM OAM packets originating from a MEP
need be configured as part of the LM provisioning. LM OAM need be configured as part of the LM provisioning. LM OAM
packets should be transmitted with the PHB that yields the packets should be transmitted with the PHB that yields the
lowest discard probability within the measured PHB Scheduling lowest discard probability within the measured PHB Scheduling
Class (see RFC 3260 [15]). Class (see RFC 3260 [16]).
If that PHB class is not an ordered aggregate where the ordering If that PHB class is not an ordered aggregate where the ordering
constraint is all packets with the PHB class being delivered in constraint is all packets with the PHB class being delivered in
order, LM can produce inconsistent results. order, LM can produce inconsistent results.
5.5.2. Sampling skew 5.5.2. Sampling skew
If an implementation makes use of a hardware forwarding path If an implementation makes use of a hardware forwarding path
which operates in parallel with an OAM processing path, whether which operates in parallel with an OAM processing path, whether
hardware or software based, the packet and byte counts may be hardware or software based, the packet and byte counts may be
skipping to change at page 41, line 10 skipping to change at page 41, line 14
In the case where multilink is encountered in the LSP path, the In the case where multilink is encountered in the LSP path, the
reordering of packets within the LSP can cause inaccurate LM reordering of packets within the LSP can cause inaccurate LM
results. results.
5.6. Packet Delay Measurement 5.6. Packet Delay Measurement
Packet Delay Measurement (DM) is one of the capabilities Packet Delay Measurement (DM) is one of the capabilities
supported by the MPLS-TP PM function in order to facilitate supported by the MPLS-TP PM function in order to facilitate
reporting of QoS information for a transport path as required in reporting of QoS information for a transport path as required in
section 2.2.12 of RFC 5860 [10]. 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 bidirectional transport path) during a
configurable time interval. configurable time interval.
Pro-active DM can be operated in two ways: Pro-active DM can be operated in two ways:
skipping to change at page 41, line 46 skipping to change at page 41, line 50
information and forward these pro-active DM OAM packets as information and forward these pro-active DM OAM packets as
regular data packets. regular data packets.
5.6.1. Configuration considerations 5.6.1. Configuration considerations
In order to support pro-active DM, the transmission rate and PHB In order to support pro-active DM, the transmission rate and PHB
associated with the DM OAM packets originating from a MEP need associated with the DM OAM packets originating from a MEP need
be configured as part of the DM provisioning. DM OAM packets be configured as part of the DM provisioning. DM OAM packets
should be transmitted with the PHB that yields the lowest should be transmitted with the PHB that yields the lowest
discard probability within the measured PHB Scheduling Class discard probability within the measured PHB Scheduling Class
(see RFC 3260 [15]). (see RFC 3260 [16]).
5.7. Client Failure Indication 5.7. Client Failure Indication
The Client Failure Indication (CFI) function, as required in The Client Failure Indication (CFI) function, as required in
section 2.2.10 of RFC 5860 [10], is used to help process client section 2.2.10 of RFC 5860 [11], is used to help process client
defects and propagate a client signal defect condition from the defects and propagate a client signal defect condition from the
process associated with the local attachment circuit where the process associated with the local attachment circuit where the
defect was detected (typically the source adaptation function defect was detected (typically the source adaptation function
for the local client interface) to the process associated with for the local client interface) to the process associated with
the far-end attachment circuit (typically the source adaptation the far-end attachment circuit (typically the source adaptation
function for the far-end client interface) for the same function for the far-end client interface) for the same
transmission path in case the client of the transport path does transmission path in case the client of the transport path does
not support a native defect/alarm indication mechanism, e.g. not support a native defect/alarm indication mechanism, e.g.
AIS. AIS.
skipping to change at page 43, line 31 skipping to change at page 43, line 35
described in section 6.3. The remainder are applicable to both described in section 6.3. The remainder are applicable to both
in-service and out-of-service transport paths. in-service and out-of-service transport paths.
6.1. Connectivity Verification 6.1. Connectivity Verification
In order to preserve network resources, e.g. bandwidth, In order to preserve network resources, e.g. bandwidth,
processing time at switches, it may be preferable to not use processing time at switches, it may be preferable to not use
proactive CC-V. In order to perform fault management functions, proactive CC-V. In order to perform fault management functions,
network management may invoke periodic on-demand bursts of on- network management may invoke periodic on-demand bursts of on-
demand CV packets, as required in section 2.2.3 of RFC 5860 demand CV packets, as required in section 2.2.3 of RFC 5860
[10]. [11].
On demand connectivity verification is a transaction that flows On demand connectivity verification is a transaction that flows
from the source MEP to a target MIP or MEP. from the source MEP to a target MIP or MEP.
Use of on-demand CV is dependent on the existence of either a Use of on-demand CV is dependent on the existence of either a
bi-directional ME, or an associated return ME, or the bi-directional ME, or an associated return ME, or the
availability of an out-of-band return path because it requires availability of an out-of-band return path because it requires
the ability for target MIPs and MEPs to direct responses to the the ability for target MIPs and MEPs to direct responses to the
originating MEPs. originating MEPs.
skipping to change at page 44, line 18 skipping to change at page 44, line 23
On-demand CV may generate a one-time burst of on-demand CV On-demand CV may generate a one-time burst of on-demand CV
packets, or be used to invoke periodic, non-continuous, bursts packets, or be used to invoke periodic, non-continuous, bursts
of on-demand CV packets. The number of packets generated in of on-demand CV packets. The number of packets generated in
each burst is configurable at the MEPs, and should take into each burst is configurable at the MEPs, and should take into
account normal packet-loss conditions. account normal packet-loss conditions.
When invoking a periodic check of the MEG, the source MEP should When invoking a periodic check of the MEG, the source MEP should
issue a burst of on-demand CV packets that uniquely identifies issue a burst of on-demand CV packets that uniquely identifies
the MEG being verified. The number of packets and their the MEG being verified. The number of packets and their
transmission rate should be pre-configured and known to both the transmission rate should be pre-configured at the source MEP.
source MEP and the target MEP or MIP. The source MEP should use The source MEP should use the mechanisms defined in sections 3.3
the mechanisms defined in sections 3.3 and 3.4 when sending an and 3.4 when sending an on-demand CV packet to a target MEP or
on-demand CV packet to a target MEP or target MIP respectively. target MIP respectively. The target MEP/MIP shall return a reply
The target MEP/MIP shall return a reply on-demand CV packet for on-demand CV packet for each packet received. If the expected
each packet received. If the expected number of on-demand CV number of on-demand CV reply packets is not received at source
reply packets is not received at source MEP, the LOC defect MEP, this is an indication that a connectivity problem may
state is entered. exist.
On-demand CV should have the ability to carry padding such that On-demand CV should have the ability to carry padding such that
a variety of MTU sizes can be originated to verify the MTU a variety of MTU sizes can be originated to verify the MTU
transport capability of the transport path. transport capability of the transport path.
MIPs that are not target by on-demand CV packets, as well as MIPs that are not target by on-demand CV packets, as well as
intermediate nodes, do not process the CV information and intermediate nodes, do not process the CV information and
forward these on-demand CV OAM packets as regular data packets. forward these on-demand CV OAM packets as regular data packets.
6.1.1. Configuration considerations 6.1.1. Configuration considerations
For on-demand CV the MEP should support the configuration of the For on-demand CV the source MEP should support the configuration
number of packets to be transmitted/received in each burst of of the number of packets to be transmitted/received in each
transmissions and their packet size. The transmission rate burst of transmissions and their packet size.
should be configured between the different nodes.
In addition, when the CV packet is used to check connectivity In addition, when the CV packet is used to check connectivity
toward a target MIP, the number of hops to reach the target MIP toward a target MIP, the number of hops to reach the target MIP
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 diagnostic of QoS performance
for a transport path, as required in section 2.2.11 of RFC 5860 for a transport path, as required in section 2.2.11 of RFC 5860
[10]. As proactive LM, on-demand LM is used to exchange counter [11]. As proactive LM, on-demand LM is used to exchange counter
values for the number of ingress and egress packets transmitted values for the number of ingress and egress packets transmitted
and received by the transport path monitored by a pair of MEPs. and received by the transport path monitored by a pair of MEPs.
LM is not performed MEP to MIP or between a pair of MIPs. LM is not performed MEP to MIP or between a pair of MIPs.
On-demand LM is performed by periodically sending LM OAM packets On-demand LM is performed by periodically sending LM OAM packets
from a MEP to a peer MEP and by receiving LM OAM packets from from a MEP to a peer MEP and by receiving LM OAM packets from
the peer MEP (if a bidirectional transport path) during a pre- the peer MEP (if a bidirectional transport path) during a pre-
defined monitoring period. Each MEP performs measurements of its defined monitoring period. Each MEP performs measurements of its
transmitted and received packets. These measurements are then transmitted and received packets. These measurements are then
correlated to evaluate the packet loss performance metrics of correlated to evaluate the packet loss performance metrics of
skipping to change at page 45, line 39 skipping to change at page 45, line 39
regular data packets. regular data packets.
6.2.1. Configuration considerations 6.2.1. Configuration considerations
In order to support on-demand LM, the beginning and duration of In order to support on-demand LM, the beginning and duration of
the LM procedures, the transmission rate and PHB associated with the LM procedures, the transmission rate and PHB associated with
the LM OAM packets originating from a MEP must be configured as the LM OAM packets originating from a MEP must be configured as
part of the on-demand LM provisioning. LM OAM packets should be part of the on-demand LM provisioning. LM OAM packets should be
transmitted with the PHB that yields the lowest discard transmitted with the PHB that yields the lowest discard
probability within the measured PHB Scheduling Class (see RFC probability within the measured PHB Scheduling Class (see RFC
3260 [15]). 3260 [16]).
6.2.2. Sampling skew 6.2.2. Sampling skew
If an implementation makes use of a hardware forwarding path If an implementation makes use of a hardware forwarding path
which operates in parallel with an OAM processing path, whether which operates in parallel with an OAM processing path, whether
hardware or software based, the packet and byte counts may be hardware or software based, the packet and byte counts may be
skewed if one or more packets can be processed before the OAM skewed if one or more packets can be processed before the OAM
processing samples counters. If OAM is implemented in software processing samples counters. If OAM is implemented in software
this error can be quite large. this error can be quite large.
skipping to change at page 46, line 17 skipping to change at page 46, line 13
Multi-link Issues are as described in section 5.5.3. Multi-link Issues are as described in section 5.5.3.
6.3. Diagnostic Tests 6.3. Diagnostic Tests
Diagnostic tests are tests performed on a MEG that has been taken 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 [10], 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 can be
performed in one-way or two-way modes. performed in one-way or two-way modes.
According to RFC 2544 [11], 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
skipping to change at page 47, line 37 skipping to change at page 47, line 37
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 [10], that permits all traffic in section 2.2.5 of RFC 5860 [11], that permits all traffic
(including user data and OAM, with the exception of the disable (including user data and OAM, with the exception of the disable
loopback command) originated at the ingress of a transport path loopback command) originated at the ingress of a transport path
or inserted by the test equipment to be looped back unmodified or inserted by the test equipment to be looped back unmodified
(other than normal per hop processing such as TTL decrement) in (other than normal per hop processing such as TTL decrement) in
the direction of the point of origin by an interface at either the direction of the point of origin by an interface at either
an intermediate node or a terminating node. TTL is decremented an intermediate node or a terminating node. TTL is decremented
normally during this process. It is also normal to disable normally during this process. It is also normal to disable
proactive monitoring of the path as the source MEP will see all proactive monitoring of the path as the source MEP will see all
source MEP originated OAM messages returned to it. source MEP originated OAM messages returned to it.
skipping to change at page 48, line 14 skipping to change at page 48, line 12
both co-routed bi-directional or associated bi-directional both co-routed bi-directional or associated bi-directional
paths. paths.
Where a node implements data plane loopback capability and Where a node implements data plane loopback capability and
whether it implements more than one point is implementation whether it implements more than one point is implementation
dependent. dependent.
6.4. Route Tracing 6.4. Route Tracing
It is often necessary to trace a route covered by a MEG from a It is often necessary to trace a route covered by a MEG from a
source MEP to the sink MEP including all the MIPs in-between source MEP to the sink MEP including all the MIPs in-between,
after e.g., provisioning an MPLS-TP transport path or for and may be conducted after provisioning an MPLS-TP transport
trouble shooting purposes such as fault localization. path for, e.g., trouble shooting purposes such as fault
localization.
The route tracing function, as required in section 2.2.4 of RFC The route tracing function, as required in section 2.2.4 of RFC
5860 [10], is providing this functionality. Based on the fate 5860 [11], is providing this functionality. Based on the fate
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 exist, the route trace
function needs to be able to detect it and stop automatically function will only be able to tract up to the defect, and needs
returning the incomplete list of OAM entities that it was able to be able to return the incomplete list of OAM entities that it
to trace. 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
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 [10]. 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 bidirectional transport path) during a
configurable time interval. configurable time interval.
On-demand DM can be operated in two ways: On-demand DM can be operated in two ways:
skipping to change at page 49, line 38 skipping to change at page 49, line 35
regular data packets. regular data packets.
6.5.1. Configuration considerations 6.5.1. Configuration considerations
In order to support on-demand DM, the beginning and duration of In order to support on-demand DM, the beginning and duration of
the DM procedures, the transmission rate and PHB associated with the DM procedures, the transmission rate and PHB associated with
the DM OAM packets originating from a MEP need be configured as the DM OAM packets originating from a MEP need be configured as
part of the DM provisioning. DM OAM packets should be part of the DM provisioning. DM OAM packets should be
transmitted with the PHB that yields the lowest discard transmitted with the PHB that yields the lowest discard
probability within the measured PHB Scheduling Class (see RFC probability within the measured PHB Scheduling Class (see RFC
3260 [15]). 3260 [16]).
In order to verify different performances between long and short In order to verify different performances between long and short
packets (e.g., due to the processing time), it should be packets (e.g., due to the processing time), it should be
possible for the operator to configure the packet size of the possible for the operator to configure the packet size of the
on-demand OAM DM packet. on-demand OAM DM packet.
7. OAM Functions for administration control 7. OAM Functions for administration control
7.1. Lock Instruct 7.1. Lock Instruct
Lock Instruct (LKI) function, as required in section 2.2.6 of Lock Instruct (LKI) function, as required in section 2.2.6 of
RFC 5860 [10], 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 put both MEPs into ad
skipping to change at page 50, line 32 skipping to change at page 50, line 30
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 accept or not the instruction and replies to the peer MEP with
an LKI reply OAM packet indicating whether it has accepted or an LKI reply OAM packet indicating whether it has accepted or
not the instruction. not the instruction. This requires either an in-band or 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 and notifies its client
(sub-)layer adaptation function upon the locked condition. (sub-)layer adaptation function upon the locked condition.
Note that if the client (sub-)layer is also MPLS-TP, Lock Note that if the client (sub-)layer is also MPLS-TP, Lock
Reporting (LKR) generation at the client MPLS-TP (sub-)layer is Reporting (LKR) generation at the client MPLS-TP (sub-)layer is
started, as described in section 5.4. started, as described in section 5.4.
7.1.2. Unlocking a transport path 7.1.2. Unlocking a transport path
skipping to change at page 52, line 22 skipping to change at page 52, line 17
The editors gratefully acknowledge the contributions of Adrian The editors gratefully acknowledge the contributions of Adrian
Farrel, Yoshinori Koike, Luca Martini, Yuji Tochio and Manuel Farrel, Yoshinori Koike, Luca Martini, Yuji Tochio and Manuel
Paul for the definition of per-interface MIPs and MEPs. Paul for the definition of per-interface MIPs and MEPs.
The editors gratefully acknowledge the contributions of Malcolm The editors gratefully acknowledge the contributions of Malcolm
Betts, Yoshinori Koike, Xiao Min, and Maarten Vissers for the Betts, Yoshinori Koike, Xiao Min, and Maarten Vissers for the
lock report and lock instruction description. lock report and lock instruction description.
The authors would also like to thank Alessandro D'Alessandro, The authors would also like to thank Alessandro D'Alessandro,
Loa Andersson, Malcolm Betts, Stewart Bryant, Rui Costa, Xuehui Loa Andersson, Malcolm Betts, Stewart Bryant, Rui Costa, Xuehui
Dai, John Drake, Adrian Farrel, Dan Frost, Liu Gouman, Peng He, Dai, John Drake, Adrian Farrel, Dan Frost, Xia Liang, Liu
Feng Huang, Su Hui, Yoshionori Koike, George Swallow, Yuji Gouman, Peng He, Feng Huang, Su Hui, Yoshionori Koike, George
Tochio, Curtis Villamizar, Maarten Vissers and Xuequin Wei for Swallow, Yuji Tochio, Curtis Villamizar, Maarten Vissers and
their comments and enhancements to the text. Xuequin Wei for their comments and enhancements to the text.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
11. References 11. References
11.1. Normative References 11.1. Normative References
[1] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol [1] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001 Label Switching Architecture", RFC 3031, January 2001
skipping to change at page 53, line 36 skipping to change at page 53, line 36
[6] Agarwal, P., Akyol, B., "Time To Live (TTL) Processing in [6] Agarwal, P., Akyol, B., "Time To Live (TTL) Processing in
Multiprotocol Label Switching (MPLS) Networks", RFC 3443, Multiprotocol Label Switching (MPLS) Networks", RFC 3443,
January 2003 January 2003
[7] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, [7] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal,
R., "MPLS Generic Associated Channel", RFC 5586, June 2009 R., "MPLS Generic Associated Channel", RFC 5586, June 2009
[8] Bocci, M., et al., "A Framework for MPLS in Transport [8] Bocci, M., et al., "A Framework for MPLS in Transport
Networks", RFC 5921, July 2010 Networks", RFC 5921, July 2010
[9] Swallow, G., Bocci, M., "MPLS-TP Identifiers", draft-ietf- [9] Bocci, M., et al., " MPLS Transport Profile User-to-Network and
mpls-tp-identifiers-01 (work in progress), April 2010 Network-to-Network Interfaces", draft-ietf-mpls-tp-uni-nni-00
(work in progress), August 2010
[10] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM [10] Swallow, G., Bocci, M., "MPLS-TP Identifiers", draft-ietf-
mpls-tp-identifiers-02 (work in progress), July 2010
[11] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM
in MPLS Transport Networks", RFC 5860, May 2010 in MPLS Transport Networks", RFC 5860, May 2010
[11] Bradner, S., McQuaid, J., "Benchmarking Methodology for [12] Bradner, S., McQuaid, J., "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999 Network Interconnect Devices", RFC 2544, March 1999
[12] ITU-T Recommendation G.806 (01/09), "Characteristics of [13] ITU-T Recommendation G.806 (01/09), "Characteristics of
transport equipment - Description methodology and generic transport equipment - Description methodology and generic
functionality ", January 2009 functionality ", January 2009
11.2. Informative References 11.2. Informative References
[13] Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten, [14] Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten,
Y., "MPLS-TP OAM Analysis", draft-ietf-mpls-tp-oam- Y., "MPLS-TP OAM Analysis", draft-ietf-mpls-tp-oam-
analysis-02 (work in progress), July 2010 analysis-02 (work in progress), July 2010
[14] Nichols, K., Blake, S., Baker, F., Black, D., "Definition [15] Nichols, K., Blake, S., Baker, F., Black, D., "Definition
of the Differentiated Services Field (DS Field) in the of the Differentiated Services Field (DS Field) in the
IPv4 and IPv6 Headers", RFC 2474, December 1998 IPv4 and IPv6 Headers", RFC 2474, December 1998
[15] Grossman, D., "New terminology and clarifications for [16] Grossman, D., "New terminology and clarifications for
Diffserv", RFC 3260, April 2002. Diffserv", RFC 3260, April 2002.
[16] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in [17] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in
MPLS Traffic Engineering (TE)", RFC 4201, October 2005 MPLS Traffic Engineering (TE)", RFC 4201, October 2005
[17] ITU-T Recommendation G.707/Y.1322 (01/07), "Network node [18] ITU-T Recommendation G.707/Y.1322 (01/07), "Network node
interface for the synchronous digital hierarchy (SDH)", interface for the synchronous digital hierarchy (SDH)",
January 2007 January 2007
[18] 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
[19] 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
[20] 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
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
Email: Italo.Busi@alcatel-lucent.com Email: Italo.Busi@alcatel-lucent.com
Ben Niven-Jenkins Ben Niven-Jenkins
BT Velocix
Email: benjamin.niven-jenkins@bt.com Email: ben@niven-jenkins.co.uk
Annamaria Fulignoli Annamaria Fulignoli
Ericsson Ericsson
Email: annamaria.fulignoli@ericsson.com Email: annamaria.fulignoli@ericsson.com
Enrique Hernandez-Valencia Enrique Hernandez-Valencia
Alcatel-Lucent Alcatel-Lucent
Email: Enrique.Hernandez@alcatel-lucent.com Email: Enrique.Hernandez@alcatel-lucent.com
 End of changes. 90 change blocks. 
170 lines changed or deleted 203 lines changed or added

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