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

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