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

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