draft-ietf-mpls-tp-oam-framework-04.txt   draft-ietf-mpls-tp-oam-framework-05.txt 
MPLS Working Group I. Busi (Ed) MPLS Working Group I. Busi (Ed)
Internet Draft Alcatel-Lucent Internet Draft Alcatel-Lucent
Intended status: Informational B. Niven-Jenkins (Ed) Intended status: Informational B. Niven-Jenkins (Ed)
BT BT
D. Allan (Ed) D. Allan (Ed)
Ericsson Ericsson
Expires: June 2010 December 10, 2009 Expires: September 5, 2010 March 5, 2010
MPLS-TP OAM Framework MPLS-TP OAM Framework
draft-ietf-mpls-tp-oam-framework-04.txt draft-ietf-mpls-tp-oam-framework-05.txt
Status of this Memo Abstract
Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) is
based on a profile of the MPLS and pseudowire (PW) procedures as
specified in the MPLS Traffic Engineering (MPLS-TE), pseudowire (PW)
and multi-segment PW (MS-PW) architectures complemented with
additional Operations, Administration and Maintenance (OAM)
procedures for fault, performance and protection-switching management
for packet transport applications that do not rely on the presence of
a control plane.
This document describes a framework to support a comprehensive set of
OAM procedures that fulfills the MPLS-TP OAM requirements [12].
This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network as
defined by the ITU-T.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 5, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) is described in the BSD License.
based on a profile of the MPLS and pseudowire (PW) procedures as
specified in the MPLS Traffic Engineering (MPLS-TE), pseudowire (PW)
and multi-segment PW (MS-PW) architectures complemented with
additional Operations, Administration and Maintenance (OAM)
procedures for fault, performance and protection-switching management
for packet transport applications that do not rely on the presence of
a control plane.
This document describes a framework to support a comprehensive set of
OAM procedures that fulfills the MPLS-TP OAM requirements [12].
This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network.
Table of Contents Table of Contents
1. Introduction..................................................5 1. Introduction..................................................5
1.1. Contributing Authors.....................................5 1.1. Contributing Authors.....................................5
1.2. Editors Issues...........................................6 2. Conventions used in this document.............................6
2. Conventions used in this document.............................9 2.1. Terminology..............................................6
2.1. Terminology..............................................9 2.2. Definitions..............................................7
2.2. Definitions.............................................10 3. Functional Components.........................................8
3. Functional Components........................................12 3.1. Maintenance Entity and Maintenance Entity Group..........9
3.1. Maintenance Entity and Maintenance Entity Group.........13 3.2. Nested MEGs: Path Segment Tunnels and Tandem Connection
3.2. MEG End Points (MEPs)...................................16 Monitoring...................................................11
3.3. MEG Intermediate Points (MIPs)..........................19 3.3. MEG End Points (MEPs)...................................12
3.4. Server MEPs.............................................20 3.4. MEG Intermediate Points (MIPs)..........................13
3.5. Path Segment Tunnels and Tandem Connection Monitoring...21 3.5. Server MEPs.............................................14
4. Reference Model..............................................21 3.6. Configuration Considerations............................15
4.1. MPLS-TP Section Monitoring..............................23 3.7. P2MP considerations.....................................15
4.2. MPLS-TP LSP End-to-End Monitoring.......................24 4. Reference Model..............................................16
4.3. MPLS-TP LSP Path Segment Tunnel Monitoring..............25 4.1. MPLS-TP Section Monitoring (SME)........................18
4.4. MPLS-TP PW Monitoring...................................27 4.2. MPLS-TP LSP End-to-End Monitoring (LME).................19
4.5. MPLS-TP MS-PW Path Segment Tunnel Monitoring............27 4.3. MPLS-TP LSP Path Segment Tunnel Monitoring (LPSTME).....19
5. OAM Functions for proactive monitoring.......................28 4.4. MPLS-TP PW Monitoring (PME).............................21
5.1. Continuity Check and Connectivity Verification..........29 4.5. MPLS-TP MS-PW Path Segment Tunnel Monitoring (PPSTME)...21
5.1.1. Defects identified by CC-V.........................30 5. OAM Functions for proactive monitoring.......................22
5.1.2. Consequent action..................................31 5.1. Continuity Check and Connectivity Verification..........23
5.1.3. Configuration considerations.......................32 5.1.1. Defects identified by CC-V.........................25
5.1.4. Applications for proactive CC-V....................33 5.1.2. Consequent action..................................26
5.2. Remote Defect Indication................................34 5.1.3. Configuration considerations.......................27
5.2.1. Configuration considerations.......................34 5.2. Remote Defect Indication................................28
5.2.2. Applications for Remote Defect Indication..........35 5.2.1. Configuration considerations.......................29
5.3. Alarm Reporting.........................................35 5.3. Alarm Reporting.........................................29
5.4. Lock Reporting..........................................36 5.4. Lock Reporting..........................................30
5.5. Packet Loss Monitoring..................................36 5.5. Packet Loss Measurement.................................31
5.5.1. Configuration considerations.......................37 5.5.1. Configuration considerations.......................32
5.5.2. Applications for Packet Loss Monitoring............37 5.6. Client Failure Indication...............................32
5.6. Client Signal Failure Indication........................38 5.6.1. Configuration considerations.......................32
5.6.1. Configuration considerations.......................38 5.7. Packet Delay Measurement................................33
5.6.2. Applications for Client Signal Failure Indication..38 5.7.1. Configuration considerations.......................33
5.7. Delay Measurement.......................................39 6. OAM Functions for on-demand monitoring.......................33
5.7.1. Configuration considerations.......................39 6.1. Connectivity Verification...............................34
5.7.2. Applications for Delay Measurement.................40 6.1.1. Configuration considerations.......................35
6. OAM Functions for on-demand monitoring.......................40 6.2. Packet Loss Measurement.................................35
6.1. Connectivity Verification...............................40 6.2.1. Configuration considerations.......................36
6.1.1. Configuration considerations.......................41 6.3. Diagnostic Tests........................................36
6.2. Packet Loss Monitoring..................................42 6.3.1. Throughput Estimation..............................36
6.2.1. Configuration considerations.......................42 6.3.2. Data plane Loopback................................37
6.2.2. Applications for On-demand Packet Loss Monitoring..42 6.4. Route Tracing...........................................37
6.3. Diagnostic..............................................42 6.4.1. Configuration considerations.......................38
6.4. Route Tracing...........................................43
6.5. Delay Measurement.......................................44 6.5. Packet Delay Measurement...............................38
6.5.1. Configuration considerations.......................44 6.5.1. Configuration considerations......................38
6.5.2. Applications for Delay Measurement.................45 6.6. Lock Instruct..........................................39
6.6. Lock Instruct...........................................45 6.6.1. Locking a transport path..........................39
7. Security Considerations......................................45 6.6.2. Unlocking a transport path........................39
8. IANA Considerations..........................................45 7. Security Considerations.....................................40
9. Acknowledgments..............................................46 8. IANA Considerations.........................................40
10. References..................................................47 9. Acknowledgments.............................................40
10.1. Normative References...................................47 10. References.................................................42
10.2. Informative References.................................47 10.1. Normative References..................................42
10.2. Informative References................................42
Editors' Note: Editors' Note:
This Informational Internet-Draft is aimed at achieving IETF This Informational Internet-Draft is aimed at achieving IETF
Consensus before publication as an RFC and will be subject to an IETF Consensus before publication as an RFC and will be subject to an IETF
Last Call. Last Call.
[RFC Editor, please remove this note before publication as an RFC and [RFC Editor, please remove this note before publication as an RFC and
insert the correct Streams Boilerplate to indicate that the published insert the correct Streams Boilerplate to indicate that the published
RFC has IETF Consensus.] RFC has IETF Consensus.]
skipping to change at page 5, line 42 skipping to change at page 5, line 42
[16]). [16]).
The MPLS-TP OAM framework is applicable to both LSPs and (MS-)PWs and The MPLS-TP OAM framework is applicable to both LSPs and (MS-)PWs and
supports co-routed and bidirectional p2p transport paths as well as supports co-routed and bidirectional p2p transport paths as well as
unidirectional p2p and p2mp transport paths. unidirectional p2p and p2mp transport paths.
This document is a product of a joint Internet Engineering Task Force This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications (IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network. capabilities and functionalities of a packet transport network as
defined by the ITU-T.
1.1. Contributing Authors 1.1. Contributing Authors
Dave Allan, Italo Busi, Ben Niven-Jenkins, Annamaria Fulignoli, Dave Allan, Italo Busi, Ben Niven-Jenkins, Annamaria Fulignoli,
Enrique Hernandez-Valencia, Lieven Levrau, Dinesh Mohan, Vincenzo Enrique Hernandez-Valencia, Lieven Levrau, Dinesh Mohan, Vincenzo
Sestito, Nurit Sprecher, Huub van Helvoort, Martin Vigoureux, Yaacov Sestito, Nurit Sprecher, Huub van Helvoort, Martin Vigoureux, Yaacov
Weingarten, Rolf Winter Weingarten, Rolf Winter
1.2. Editors Issues
Editor's Note:
This section is to be removed prior to submission to the RFC editor.
1) ME architecture needs further discussion/clarification
Agreement (call 24 November):
o Co-routed bidirectional p2p transport entity: one bidirectional
ME
o Associated bidirectional p2p transport entity: two
unidirectional MEs
o Unidirectional p2p transport entity: one unidirectional ME
o Unidirectional p2mp (with N leaves) transport entity: N
unidirectional ME
Clarify that in a p2mp transport entity all the traffic (including
OAM packets) is sent (multicast) from the root to all the leaves. As
a consequence:
o To send an OAM packet to all leaves, it is required to send a
single OAM packet that will be delivered by the forwarding plane
to all the leaves and processed by all the leaves.
o To send an OAM packet to a single leaf, it is required to send a
single OAM packet that will be delivered by the forwarding plane
to all the leaves and processed only by the target leaf and
ignored by the other leaves.
o In order to send an OAM packet to M leaves (i.e., a subset of
all the leaves), the current working assumption is to send M
different (multicast) OAM packets targeted to each individual
leaf in the group of M leaves. Better mechanisms are under
investigation and might be added in future versions of this
draft.
2) Use of terms LTCME and PTCME, should these be genericised for
PSTs.
Agreement (call 24 November): the editors of the framework document
will make sure that the framework document is aligned with the
decision to use the term PST. This document will be aligned with this
decision.
3) CV refers to using an ME ID for misbranching detection. This does
not align with p2mp LSPs where a CV would then be required to
carry all the MEs in the MEG.
Agreement (call 24 November): we are going to use the term MEG ID in
the document. ME ID has been used in older versions of the document
and its use is legacy.
For pro-active CC-V (both p2p and p2mp), the globally unique MEP ID
information needs to be carried: section on pro-active CC-V needs to
be updated accordingly.
4) Discussions of PW monitoring and PW tandem connection monitoring
seem to be rendered out of scope by the layering decision at
Hiroshima.
Discussion points (call 24 November) - No agreement reached on this
issue
PW OAM architecture: based on the architecture defined in this
document using MEP and MIPs
PW TCM concept: just a specific application of the architecture of
the TP-LSP (1:1 mapped with the monitored PW) carrying a PW segment
in the MS-PW architecture.
Generic clarifications (to be added) [terminology based on RFC 5654]:
o before a TCM is setup, we can have a concatenated LSP
segment. After the TCM (that is a TP-LSP) is setup, we have a
single LSP segment between the TCM end-points;
o before a TCM is setup, we can have a concatenated PW segment.
After the TCM (that is a TP-LSP) is setup, we have a single
PW segment between the TCM end-points.
Problems with PW TCM are the implications of removing S-PEs from the
PW path. Need further discussion. It is not obvious to Dave that
removing an LSR from a path can be done hitlessly either ... by
slipping a PST under it ...
Action (Italo): check which requirements cannot be met if PW TCM
between non-adjacent PEs cannot be supported and whether this is a
showstopper issue or not.
Action (Italo): describe the PW TCM as an LSP and circulate the
description to the mailing list for review. If needed, another call
will be setup to finalize the discussion.
Action (Matthew, Italo): Develop a couple of diagrams showing how the
mechanism works for LSPs and PWs.
5) Concerns have been raised against the idea of having MIPs capable
to generate spontaneous messages. AIS/Lock Indication packets are
generated by the adaptation functions. This point needs
clarifying.
Agreement (9 December):
AIS/Lock Indication are generate by a MIP node (to be define as a
node hosting a MIP) w/o saying that they are generated by a MIP.
The general framework will describe the mechanism for intermediate
nodes to insert packets and each specific framework document (e.g.,
OAM framework) will describe the usage of this capability on a case-
by-case basis. When you provision bw between two end-points you must
allow enough bw for any additional traffic, including traffic from
MEPs and MIPs.
OAM framework will describe that a MIP node may insert OAM packets
into a LSP and this will be described on a function-by-function
basis. It will also describe the functions that require a MIP to
generate OAM packets (e.g., on-demand CV).
6) Presence or absence of MIPs is a bizarre point. At least one MIP
in every node is addressed by TTL, and gaps in the enablement of
MIPs would produce spurious test results. A convention of "MIPs
exist at any node on a transport path that has a return path to a
source MEP" would make sense vs. discussing manual
enable/disable/configuration of MIPs.
Note - the annotated text ("If the set of MIPs is actually sparse
(i.e. not every hop is a MIP), then it has to be intermediate nodes
to do some operations") needs further clarification.
Agreement (9 December):
All the intermediate nodes host MIP(s). Local policy allows them to
be enabled per function and per LSP. The local policy is controlled
by the management system, which may delegate it to the control plane.
7) Discussions in Hiroshima and subsequent calls have suggested use
of alternative return paths "if available", not all of which will
be GAL/GACH encapsulated? This point needs clarifying.
Agreement (9 December):
When the return path is not an MPLS-TP path, the reply message does
not need to be GAL/ACH encapsulated.
The request message needs to carry sufficient information to allow
the target MIP/MEP to reply when a non MPLS-TP return path is used.
8) Data plane loopback
Action (17 November): check on the mailing list (both ITU-T and IETF
to get inputs from both types of operators).
9) Review the draft to check that all the known implications related
to the support of p2mp transport paths have been described.
This check will be done in the next version after the current open
points/comments have been resolved.
10)Given layering discussion in Hiroshima, it is not very clear
whether MPLS TP is a sub layer network within the MPLS layer
network or a layer network by its own.
This issue should be resolved in the context of the MPLS TP Framework
draft but has impacts on this draft as well.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1]. document are to be interpreted as described in RFC-2119 [1].
2.1. Terminology 2.1. Terminology
AC Attachment Circuit AC Attachment Circuit
skipping to change at page 10, line 42 skipping to change at page 7, line 13
SME Section Maintenance Entity SME Section Maintenance Entity
2.2. Definitions 2.2. Definitions
Note - the definitions in this section are intended to be in line Note - the definitions in this section are intended to be in line
with ITU-T recommendation Y.1731 in order to have a common, with ITU-T recommendation Y.1731 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 describe certain implementation but rather serve as a framework to describe
the necessary OAM functions for MPLS-TP. the necessary OAM functions for MPLS-TP.
Data plane loopback: it is an out-of-service test where an interface
at either an intermediate or terminating node in a path is placed
into a data plane loopback state, such that it loops back all the
packets (including user data and OAM) it receives on a specific MPLS-
TP transport path.
Domain Border Node (DBN): An LSP intermediate MPLS-TP node (LSR) that Domain Border Node (DBN): An LSP intermediate MPLS-TP node (LSR) that
is at the boundary of an MPLS-TP OAM domain. Such a node may be is at the boundary of an MPLS-TP OAM domain. Such a node may be
present on the edge of two domains or may be connected by a link to present on the edge of two domains or may be connected by a link to
an MPLS-TP node in another OAM domain. an MPLS-TP node in another OAM domain.
Loopback: see data plane loopback and OAM loopback definitions.
Maintenance Entity (ME): Some portion of a transport path that Maintenance Entity (ME): Some portion of a transport path that
requires management bounded by two points, and the relationship requires management bounded by two points, and the relationship
between those points to which maintenance and monitoring operations between those points to which maintenance and monitoring operations
apply (details in section 3.1). apply (details in section 3.1).
Maintenance Entity Group (MEG): The set of one or more maintenance Maintenance Entity Group (MEG): The set of one or more maintenance
entities that maintain and monitor a transport path in an OAM domain. entities that maintain and monitor a transport path in an OAM domain.
MEP: A MEG end point (MEP) is capable of initiating (MEP Source) and MEP: A MEG end point (MEP) is capable of initiating (MEP Source) and
terminating (MEP Sink) OAM messages for fault management and terminating (MEP Sink) OAM messages for fault management and
performance monitoring. MEPs reside at the boundaries of an ME performance monitoring. MEPs reside at the boundaries of an ME
(details in section 3.2). (details in section 3.3).
MEP Source: A MEP acts as MEP source for an OAM message when it MEP Source: A MEP acts as MEP source for an OAM message when it
originates and inserts the message into the transport path for its originates and inserts the message into the transport path for its
associated MEG. associated MEG.
MEP Sink: A MEP acts as a MEP sink for an OAM message when it MEP Sink: A MEP acts as a MEP sink for an OAM message when it
terminates and processes the messages received from its associated terminates and processes the messages received from its associated
MEG. MEG.
MIP: A MEG intermediate point (MIP) terminates and processes OAM MIP: A MEG intermediate point (MIP) terminates and processes OAM
messages and may generate OAM messages in reaction to received OAM messages and may generate OAM messages in reaction to received OAM
messages. It never generates unsolicited OAM messages itself. A MIP messages. It never generates unsolicited OAM messages itself. A MIP
resides within an MEG between MEPs (details in section 3.2). resides within an MEG between MEPs (details in section 3.3).
OAM domain: A domain, as defined in [11], whose entities are grouped OAM domain: A domain, as defined in [11], whose entities are grouped
for the purpose of keeping the OAM confined within that domain. for the purpose of keeping the OAM confined within that domain.
Note - within the rest of this document the term "domain" is used to Note - within the rest of this document the term "domain" is used to
indicate an "OAM domain" indicate an "OAM domain"
OAM flow: Is the set of all OAM messages originating with a specific OAM flow: Is the set of all OAM messages originating with a specific
MEP that instrument one direction of a MEG. MEP that instrument one direction of a MEG.
OAM information element: An atomic piece of information exchanged OAM information element: An atomic piece of information exchanged
between MEPs in MEG used by an OAM application. between MEPs in MEG used by an OAM application.
OAM loopback: it is the capability of a node to intercepts some
specific OAM packets and to generate a reply back to their sender.
OAM loopback can work in-service and can support different OAM
functions (e.g., bidirectional on-demand connectivity verification).
OAM Message: One or more OAM information elements that when exchanged OAM Message: One or more OAM information elements that when exchanged
between MEPs or between MEPs and MIPs performs some OAM functionality between MEPs or between MEPs and MIPs performs some OAM functionality
(e.g. connectivity verification) (e.g. connectivity verification)
OAM Packet: A packet that carries one or more OAM messages (i.e. OAM OAM Packet: A packet that carries one or more OAM messages (i.e. OAM
information elements). information elements).
Path: See Transport Path Path: See Transport Path
Signal Fail: A condition declared by a MEP when the data forwarding Signal Fail: A condition declared by a MEP when the data forwarding
skipping to change at page 12, line 18 skipping to change at page 8, line 48
the forwarding engine(s) of the node(s) at the boundaries of the the forwarding engine(s) of the node(s) at the boundaries of the
tandem connection. tandem connection.
This document uses the terms defined in RFC 5654 [11]. This document uses the terms defined in RFC 5654 [11].
This document uses the term 'Per-hop Behavior' as defined in [14]. This document uses the term 'Per-hop Behavior' as defined in [14].
3. Functional Components 3. Functional Components
MPLS-TP defines a profile of the MPLS and PW architectures ([2], [5] MPLS-TP defines a profile of the MPLS and PW architectures ([2], [5]
and [7]) that is designed to transport service traffic where the and [7]) that is required to transport service traffic where the
characteristics of information transfer between the transport path characteristics of information transfer between the transport path
endpoints can be demonstrated to comply with certain performance and endpoints can be demonstrated to comply with certain performance and
quality guarantees. In order to verify and maintain these performance quality guarantees.
and quality 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 arbitrary parts of transport paths, defined as Tandem
Connections, between any two arbitrary points along a path.
In order to describe the required OAM functionality, this document In order to describe the required OAM functionality, this document
introduces a set of high-level functional components. [Note - introduces a set of high-level functional components.
discussion in Munich -tues concluded that TCM not possible with PWs -
can monitor a single PW segment - but attempting to monitor more than
one segment converts the PW into an LSP and therefore the intervening
SPEs are unable to see the PW as a PW due to the differences in how
OAM flows are disambiguated.] [editors: if true this IMO is a huge
problem as the one place I would really want TCM is a multi-domain
MS-PW, else I have to control plane peer at two layers, pending
resolution of discussion item 4 in section 1.2]
When a control plane is not present, the management plane configures
these functional components. Otherwise they can be configured either
by the management plane or by the control plane.
These functional components should be instantiated when the path is
created by either the management plane or by the control plane (if
present). Some components may be instantiated after the path is
initially created (e.g. PST).
[Dave: are we discussing the same issue for LSP PSTs as for PWs, an
S-PE cannot easily be removed, certainly not hitlessly, how is an LSP
different?]
3.1. Maintenance Entity and Maintenance Entity Group 3.1. Maintenance Entity and Maintenance Entity Group
MPLS-TP OAM operates in the context of Maintenance Entities (MEs) MPLS-TP OAM operates in the context of Maintenance Entities (MEs)
that are a relationship between two points of a point to point that are a relationship between two points of a point to point
transport path or a root and a leaf of a point to multipoint transport path or a root and a leaf of a point to multipoint
transport path to which maintenance and monitoring operations apply. transport path to which maintenance and monitoring operations apply.
These two points are called Maintenance Entity Group (MEG) End Points These two points are called Maintenance Entity Group (MEG) End Points
(MEPs). In between these two points zero or more intermediate points, (MEPs). In between these two points zero or more intermediate points,
called Maintenance Entity Group Intermediate Points (MIPs), MAY exist called Maintenance Entity Group Intermediate Points (MIPs), MAY exist
and can be shared by more than one ME in a MEG. and can be shared by more than one ME in a MEG.
The MEPs that form an MEG are configured and managed to limit the
scope of an OAM flow within the MEG that the MEPs belong to (i.e.
within the domain of the transport path or segment, in the specific
sub-layer of the MPLS layer network, that is being monitored and
managed). A misbranching fault may cause OAM packets to be delivered
to a MEP that is not in the MEG of origin.
The abstract reference model for an ME with MEPs and MIPs is The abstract reference model for an ME with MEPs and MIPs is
described in Figure 1 below: described in Figure 1 below:
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
|A|----|B|----|C|----|D| |A|----|B|----|C|----|D|
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
Figure 1 ME Abstract Reference Model Figure 1 ME Abstract Reference Model
The instantiation of this abstract model to different MPLS-TP The instantiation of this abstract model to different MPLS-TP
entities is described in section 4. In this model, nodes A, B, C and entities is described in section 4. In this model, nodes A, B, C and
D can be LER/LSR for an LSP or the {S|T}-PEs for a MS-PW. MEPs reside D can be LER/LSR for an LSP or the {S|T}-PEs for a MS-PW. MEPs reside
in nodes A and D while MIPs reside in nodes B and C. The links in nodes A and D while MIPs reside in nodes B and C. The links
connecting adjacent nodes can be physical links, or sub-layer connecting adjacent nodes can be physical links, (sub-)layer
LSPs/PSTs. LSPs/PSTs, or serving layer paths.
This functional model defines the relationships between all OAM This functional model defines the relationships between all OAM
entities from a maintenance perspective, to allow each Maintenance entities from a maintenance perspective, to allow each Maintenance
Entity to monitor and manage the layer network under its Entity to monitor and manage the (sub-)layer network under its
responsibility and to localize problems efficiently. responsibility and to localize problems efficiently.
[Editor's note - MEG are sub-layers. Need to check the document for Another OAM functional component is referred to as Maintenance Entity
consistency with this agreement] Group, which is a collection of one or more MEs that belongs to the
same transport path and that are maintained and monitored as a group.
An MPLS-TP maintenance entity group can cover either the whole end- An MPLS-TP Maintenance Entity Group may be defined to monitor the
to-end path or a path segment tunnel supporting some portion of the transport path for fault and/or performance management.
transport path. A Maintenance Entity Group may be defined to monitor
the transport path for fault and/or performance management.
In case of associated bi-directional paths, two independent
Maintenance Entities are defined to independently monitor each
direction. This has implications for transactions that terminate at
or query a MIP as a return path from MIP to source MEP does not exist
in a unidirectional ME.
The following properties apply to all MPLS-TP MEGs:
o They can be nested but not overlapped, e.g. an MEG may cover a
segment or a concatenated segment of another MEG, and may also
include the forwarding engine(s) of the node(s) at the edge(s) of
the segment or concatenated segment, but all its MEPs and MIPs are
no longer part of the encompassing MEG. It is possible that MEPs
of nested MEGs reside on a single node.
o Each OAM flow is associated with a single Maintenance Entity
Group.
o OAM packets that instrument a particular direction of an LSP are
subject to the same forwarding treatment (i.e. fate share) as the
data traffic and in some cases may be required to have common
queuing discipline E2E with the class of traffic monitored. OAM
packets can be distinguished from the data traffic using the GAL
and ACH constructs [9] for LSP and Section or the ACH construct
[6]and [9] for (MS-)PW.
[Editor's note: A key point in the definition of an ME is the end-
points are defined by location of the logical function MEP
Later in the framework we will discuss the precision with which we
can identify the location of a MEP/MIP i.e, ingress i/f, egress i/f
or node.
We need to distinguish between the point of interception of an OAM
msg and the point where the action takes place.
Action: look at the text in the framework document regarding the
location of the functional components (MEPs and MIPs).]
[Editors' note: Somewhere we need to distinguish between the OAM
control function and the OAM measurement function. i.e. we set up a
loop back (a control function, in which case the OAM message may be
intercepted and actioned anywhere convenient), and the measurement
function (i.e. looping the packet to determine that it reached a
particular part of the network) which needs to be actioned at a
precisely know and stipulated point in the network/equipment.
Action (Dave) - add some text on the subject.]
Note that not all functionality / processing of an OAM pkt needs to
take place at the point of measurement. [editors: this comment is not
clear. For discussion during revision call]
[Editors' note - Address this comment while addressing the control
and measurement issue above.
We considered that an OAM function can be decomposed into the
following components
- Instruction or command
- Execution
- Addressing (node, interface etc) is ttl/LSP enough - do we need The MEPs that form an MEG are configured and managed to limit the
sub-addressing to cause execution on a specific component in the scope of an OAM flow within the MEG that the MEPs belong to (i.e.
node - i.e. egress interface within the domain of the transport path that is being monitored and
managed). A misbranching fault may cause OAM packets to be delivered
to a MEP that is not in the MEG of origin.
- Response via OAM In case of unidirectional point-to-point transport paths, a single
unidirectional Maintenance Entity is defined to monitor it.
- Reporting to mgt interface] In case of associated bi-directional point-to-point transport paths,
two independent unidirectional Maintenance Entities are defined to
independently monitor each direction. This has implications for
transactions that terminate at or query a MIP as a return path from
MIP to source MEP does not necessarily exist in a unidirectional MEG.
[Editor's note: the MPLS-TP framework will describe how it is In case of co-routed bi-directional point-to-point transport paths, a
possible to inject OAM packets on intermediate nodes. We need to single bidirectional Maintenance Entity is defined to monitor both
describe how this capability is used within the OAM framework and to directions congruently.
reference to the MPLS-TP framework for the description of this
capability]
Another OAM construct is referred to as Maintenance Entity Group, In case of unidirectional point-to-multipoint transport paths, a
which is a collection of one or more MEs that belongs to the same single unidirectional Maintenance entity for each leaf is defined to
transport path and that are maintained and monitored as a group. monitor the transport path from the root to that leaf.
A use case for an MEG with more than one ME is point-to-multipoint The reference model for the p2mp MEG is represented in Figure 2.
OAM. The reference model for the p2mp MEG is represented in Figure 2.
+-+ +-+
/--|D| /--|D|
/ +-+ / +-+
+-+ +-+
/--|C| /--|C|
+-+ +-+/ +-+\ +-+ +-+ +-+/ +-+\ +-+
|A|----|B| \--|E| |A|----|B| \--|E|
+-+ +-+\ +-+ +-+ +-+ +-+\ +-+ +-+
\--|F| \--|F|
+-+ +-+
Figure 2 Reference Model for p2mp MEG Figure 2 Reference Model for p2mp MEG
In case of p2mp transport paths, the OAM operations are independent In case of p2mp transport paths, the OAM operations are independent
for each ME (A-D, A-E and A-F): for each ME (A-D, A-E and A-F):
o Fault conditions - some faults may impact more than one ME o Fault conditions - some faults may impact more than one ME
depending from where the failure is located depending from where the failure is located;
o Packet loss - packet dropping may impact more than one ME o Packet loss - packet dropping may impact more than one ME
depending from where the packets are lost depending from where the packets are lost;
o Packet delay - depending on different paths o Packet delay - will be unique per ME.
Each leaf (i.e. D, E and F) terminates OAM flows to monitor the ME Each leaf (i.e. D, E and F) terminates OAM flows to monitor the ME
from itself and the root while the root (i.e. A) generates OAM from itself and the root while the root (i.e. A) generates OAM
messages common to all the MEs of the p2mp MEG. Nodes B and C MAY messages common to all the MEs of the p2mp MEG. Nodes B and C MAY
implement a MIP in the corresponding MEG. implement a MIP in the corresponding MEG.
3.2. MEG End Points (MEPs) 3.2. Nested MEGs: Path Segment Tunnels and Tandem Connection Monitoring
In order to verify and maintain performance and quality 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 arbitrary parts of
transport paths, defined as Tandem Connections, between any two
arbitrary points along a transport path.
Path segment tunnels (PSTs), as defined in [8], are instantiated to
provide monitoring of a portion of a set of co-routed transport paths
(LSPs or MS-PWs). Path segment tunnels can also be employed to meet
the requirement to provide tandem connection monitoring (TCM).
TCM for a given portion of a transport path is implemented by first
creating a path segment tunnel that has a 1:1 association with
portion of the transport path that is to be uniquely monitored. This
means there is direct correlation between all FM and PM information
gathered for the PST AND the monitored portion of the E2E transport
path. The PST is monitored using normal LSP monitoring.
There are a number of implications to this approach:
1) The PST would use the uniform model of TC code point copying
between sub-layers for diffserv such that the E2E markings and
PHB treatment for the transport path was preserved by the PST.
2) The PST would use the pipe model for TTL handling such that MIP
addressing for the E2E entity would be not be impacted by the
presence of the PST.
3) PM statistics need to be adjusted for the encapsulation overhead
of the additional PST sub-layer.
A PST is instantiated to create an MEG that monitors a segment of a
transport path (LSP or PW). The endpoints of the PST are MEPs and
limit the scope of an OAM flow within the MEG the MEPs belong to
(i.e. within the domain of the PST that is being monitored and
managed).
The following properties apply to all MPLS-TP MEGs:
o They can be nested but not overlapped, e.g. an MEG may cover a
segment or a concatenated segment of another MEG, and may also
include the forwarding engine(s) of the node(s) at the edge(s) of
the segment or concatenated segment, but all its MEPs and MIPs are
no longer part of the encompassing MEG. It is possible that MEPs
of nested MEGs reside on a single node.
o It is possible for MEPs of nested MEGs to reside on a single node.
o Each OAM flow is associated with a single Maintenance Entity
Group.
o OAM packets that instrument a particular direction of a transport
path are subject to the same forwarding treatment (i.e. fate
share) as the data traffic and in some cases may be required to
have common queuing discipline E2E with the class of traffic
monitored. OAM packets can be distinguished from the data traffic
using the GAL and ACH constructs [9] for LSP and Section or the
ACH construct [6]and [9] for (MS-)PW.
3.3. MEG End Points (MEPs)
MEG End Points (MEPs) are the source and sink points of an MEG. In MEG End Points (MEPs) are the source and sink points of an MEG. In
the context of an MPLS-TP LSP, only LERs can implement MEPs while in the context of an MPLS-TP LSP, only LERs can implement MEPs while in
the context of a path segment tunnel (PST) both LERs and LSRs can the context of a path segment tunnel (PST) both LERs and LSRs can
implement MEPs that contribute to the overall monitoring implement MEPs that contribute to the overall monitoring
infrastructure for the transport path. Regarding MPLS-TP PW, only T- infrastructure for the transport path. Regarding MPLS-TP PW, only T-
PEs can implement MEPs while for PSTs supporting a PW both T-PEs and PEs can implement MEPs while for PSTs supporting a PW both T-PEs and
S-PEs can implement MEPs. In the context of MPLS-TP Section, any S-PEs can implement MEPs. In the context of MPLS-TP Section, any
MPLS-TP NE can implement a MEP. MPLS-TP LSR can implement a MEP.
[Munich: See note about PW Tandem monitoring earlier, and whether a
PW can be a tandem connection - for further discussion (discussion
point 4 in section 1.2)]
MEPs are responsible for activating and controlling all of the OAM MEPs are responsible for activating and controlling all of the OAM
functionality for the MEG. A MEP is capable of originating and functionality for the MEG. A MEP is capable of originating and
terminating OAM messages for fault management and performance terminating OAM messages for fault management and performance
monitoring. These OAM messages are encapsulated into an OAM packet monitoring. These OAM messages are encapsulated into an OAM packet
using the G-ACh as defined in RFC 5586 [9]: in this case the G-ACh using the G-ACh as defined in RFC 5586 [9]: in this case the G-ACh
message is an OAM message and the channel type indicates an OAM message is an OAM message and the channel type indicates an OAM
message. A MEP terminates all the OAM packets it receives from the message. A MEP terminates all the OAM packets it receives from the
MEG it belongs to. The MEG the OAM packet belongs to is inferred from MEG it belongs to. The MEG the OAM packet belongs to is inferred from
the MPLS or PW label.[Editors: given the discussion about alternative the MPLS or PW label or, in case of MPLS-TP section, the MPLS-TP port
return paths, is a GAL/GaCH always present ...?. For discussion on the OAM packet has been received with the GAL at the top of the label
the IETF review calls] stack.
OAM packets may require the use of an available "out-of-band" return
path (as defined in [8]). In such cases sufficient information is
required in the originating transaction such that the OAM reply
packet can be constructed (e.g. IP address).
Once an MEG is configured, the operator can configure which OAM Once an MEG is configured, the operator can configure which OAM
functions to use on the MEG but the MEPs are always enabled. A node functions to use on the MEG but the MEPs are always enabled. A node
at the edge of an MEG always supports a MEP. at the edge of an MEG always supports a MEP.
MEPs terminate all OAM packets received from the associated transport MEPs terminate all OAM packets received from the associated MEG. As
path or path segment tunnel [Editors: the PST definition in the the MEP corresponds to the termination of the forwarding path for an
framework should be augmented to clarity that the clients of a PST MEG at the given (sub-)layer, OAM packets never "leaks" outside of a
should always be LSPs or PWs]. As the MEP corresponds to the MEG in a fault free implementation.
termination of the forwarding path for an MEG at the given sub-level,
OAM packets never "leaks" outside of a MEG in a fault free
implementation.
A MEP of an MPLS-TP transport path (Section, LSP or PW) coincides A MEP of an MPLS-TP transport path (Section, LSP or PW) coincides
with transport path termination and monitors it for failures or with transport path termination and monitors it for failures or
performance degradation (e.g. based on packet counts) in an end-to- performance degradation (e.g. based on packet counts) in an end-to-
end scope. Note that both MEP source and MEP sink coincide with end scope. Note that both MEP source and MEP sink coincide with
transport paths' source and sink terminations. transport paths' source and sink terminations.
The MEPs of a path segment tunnel are not necessarily coincident with The MEPs of a path segment tunnel are not necessarily coincident with
the termination of the MPLS-TP transport path (LSP or PW) and monitor the termination of the MPLS-TP transport path (LSP or PW) and monitor
some portion of the transport path for failures or performance some portion of the transport path for failures or performance
degradation (e.g. based on packet counts) only within the boundary of degradation (e.g. based on packet counts) only within the boundary of
the MEG for the path segment tunnel. the MEG for the path segment tunnel.
An MPLS-TP MEP sink passes a fault indication to its client An MPLS-TP MEP sink passes a fault indication to its client
(sub-)layer network as a consequent action of fault detection. (sub-)layer network as a consequent action of fault detection.
It may occur that the MEPs of a path segment tunnel are set on both It may occur that the MEPs of a path segment tunnel are set on both
sides of the forwarding engine such that the MEG is entirely internal sides of the forwarding engine such that the MEG is entirely internal
to the node. to the node.
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 layer
sub-layer i.e. an LSP or PW. If we need to monitor some portion of i.e. an LSP or PW. If we need to monitor some portion of that LSP or
that LSP or PW [editor: mention of PW in this context needs to be PW, a new sub-layer in the form of a path segment tunnel MUST be
revised after agreement on discussion point 4 in section 1.2], a new created which permits MEPs and an associated MEG to be created.
sub-layer in the form of a path segment tunnel MUST be created which
permits MEPs and an associated MEG to be created.
[Editor: We need to describe the migration process for adding a path
segment tunnel.]
[Editor's note: Update the draft to capture the agreements below
after the discussion points 5, 6 and 7 in section 1.2 are resolved
(to maintain consistency):
We have the case of a MIP sending msg to a MEP. To do this it uses
the LSP label - i.e. the top label of the stack at that point.
[editors: move and clarify in section 3.3 - for further discuss.
If the set of MIPs is actually sparse (i.e. not every hop is a MIP),
then it has to be intermediate nodes to do some operations.]
Agreement (10 November): An intermediate node can send an OAM packet.
Clarify that we need to provide enough bandwidth on the transport
paths to support OAM traffic (throughout the framework document).
From IETF point of view no distinction between MIPs and adaptation
functions.
Lou question about how triggered response OAM packets are sent by
MIPs/MEPs.
Agreement (call 9 December):
o bidirectional co-routed: use the reverse path (thus checking
both the forward and backward directions of the transport
path). Co-routed bidirectional transport paths can have a
minimum bandwidth return path.
o unidirectional p2p and p2mp: no ability to support triggered
response OAM message
Non MPLS-TP LSP/PW return path MAY be requested by the OAM message
triggering the reply and the target MIP/MEP MAY attempt to reply
using the requested return path.
In this case, only the forward direction of the MPLS-TP transport
path is checked and the connectivity to the source MEP via the
requested return path is not guaranteed.
Agreement (call 17 November) to use as a working assumption the same We have the case of an intermediate node sending msg to a MEP. To do
MEP/MIP model in MS-PW OAM architecture. In order to validate this this it uses the LSP label - i.e. the top label of the stack at that
working assumption we need to understand how to describe the PW point.
Status information: this information is propagated on a hop-by-hop
basis between adjacent PEs using LDP (dynamic PW segments) or ACH
Status PW (static PW segments).]
3.3. MEG Intermediate Points (MIPs) 3.4. MEG Intermediate Points (MIPs)
A MEG Intermediate Point (MIP) is a point between the MEPs of an MEG. A MEG Intermediate Point (MIP) is a point between the MEPs of an MEG.
A MIP is capable of reacting to some OAM packets and forwarding all A MIP is capable of reacting to some OAM packets and forwarding all
the other OAM packets while ensuring fate sharing with data plane the other OAM packets while ensuring fate sharing with data plane
packets. However, a MIP does not initiate [unsolicited OAM - editors: packets. However, a MIP does not initiate unsolicited OAM packets,
this text was removed in the commented .rtf document from Munich but but may be addressed by OAM packets initiated by one of the MEPs of
not tracked as a revision, validate this change after MIP/MEP the MEG. A MIP can generate OAM packets only in response to OAM
discussion (discussion point 5 in section 1.2)] packets, but may be packets that are sent on the MEG it belongs to.
addressed by OAM packets initiated by one of the MEPs of the MEG. A
MIP can generate OAM packets only in response to OAM packets that are
sent on the MEG it belongs to.
An intermediate node within a point-to-point MEG can either:
o not support MPLS-TP OAM (i.e. no MIPs per node) An intermediate node within a MEG can either:
o support per-node MIP (i.e. a single MIP per node) o support per-node MIP (i.e. a single MIP per node)
o support per-interface MIP (i.e. two MIPs per node on both sides of o support per-interface MIP (i.e. two or more MIPs per node on both
the forwarding engine) sides of the forwarding engine)
[Editor's note - Need to describe MIPs for p2mp MEGs]
[Editor's note - Add a Figure to describe how the two options can be
support]
A node at the edge of an MEG can also support a MEP and a
per-interface MIP at the two sides of the forwarding engine.
When sending an OAM packet to a MIP, the source MEP should set the 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 node TTL field to indicate the number of hops necessary to reach the node
where the MIP resides. It is always assumed that the "pipe"/"short where the MIP resides. It is always assumed that the "pipe"/"short
pipe" model of TTL handling is used by the MPLS transport profile. pipe" model of TTL handling is used by the MPLS transport profile.
The source MEP should also include Target MIP information in the OAM The source MEP should also include Target MIP information in the OAM
packets sent to a MIP to allow proper identification of the MIP packets sent to a MIP to allow proper identification of the MIP
within the node. The MEG the OAM packet is associated with is within the node. The MEG the OAM packet is associated with is
inferred from the MPLS label. inferred from the MPLS label.
A node at the edge of an MEG can also support per-interface MEPs and
per-interface MIPs on either side of the forwarding engine.
Once an MEG is configured, the operator can enable/disable the MIPs Once an MEG is configured, the operator can enable/disable the MIPs
on the nodes within the MEG. [Editors': review this paragraph after on the nodes within the MEG. All the intermediate nodes host MIP(s).
discussion point 6 in section 1.2 is resolved] Local policy allows them to be enabled per function and per LSP. The
local policy is controlled by the management system, which may
delegate it to the control plane.
3.4. Server MEPs 3.5. Server MEPs
A server MEP is a MEP of an MEG that is either: A server MEP is a MEP of an MEG that is either:
o defined in a layer network that is "below", which is to say o defined in a layer network that is "below", which is to say
encapsulates and transports the MPLS-TP layer network being encapsulates and transports the MPLS-TP layer network being
referenced, or referenced, or
o defined in a sub-layer of the MPLS-TP layer network that is o defined in a sub-layer of the MPLS-TP layer network that is
"below" which is to say encapsulates and transports the sub-layer "below" which is to say encapsulates and transports the sub-layer
being referenced. being referenced.
A server MEP can coincide with a MIP or a MEP in the client (MPLS-TP) A server MEP can coincide with a MIP or a MEP in the client (MPLS-TP)
layer network. (sub-)layer network.
[Editors' note: review the text above pending discussion of whether
MPLS-TP is a sub-layer network within the MPLS layer network or a
layer network by its own (discussion point 10 in section 1.2)]
A server MEP also interacts with the client/server adaptation A server MEP also interacts with the client/server adaptation
function between the client (MPLS-TP) (sub-)layer network and the function between the client (MPLS-TP) (sub-)layer network and the
server (sub-)layer network. The adaptation function maintains state server (sub-)layer network. The adaptation function maintains state
on the mapping of MPLS-TP transport paths that are setup over that on the mapping of MPLS-TP transport paths that are setup over that
server layer's transport path. server (sub-)layer's transport path.
For example, a server MEP can be either: For example, a server MEP can be either:
o A termination point of a physical link (e.g. 802.3), an SDH VC or o A termination point of a physical link (e.g. 802.3), an SDH VC or
OTN ODU, for the MPLS-TP Section layer network, defined in section OTN ODU, for the MPLS-TP Section layer network, defined in section
4.1; 4.1;
o An MPLS-TP Section MEP for MPLS-TP LSPs, defined in section 4.2; o An MPLS-TP Section MEP for MPLS-TP LSPs, defined in section 4.2;
o An MPLS-TP LSP MEP for MPLS-TP PWs, defined in section 4.4; o An MPLS-TP LSP MEP for MPLS-TP PWs, defined in section 4.4;
o An MPLS-TP PST MEP for higher-level PSTs, defined in section 4.3; o An MPLS-TP PST MEP used for LSP segment monitoring, as defined in
section 4.3, for MPLS-TP LSPs or higher-level LSP PSTs;
o An MPLS-TP PW Tandem Connection MEP for higher-level PTCMEs, o An MPLS-TP PST MEP used for PW segment monitoring, as defined in
defined in section 4.5. [Editor: update this bullet after the section 4.5, for MPLS-TP PWs or higher-level PW PSTs.
discussion on PW TCM (discussion point 4 in section 1.2)]
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. Server MEP OAM indication to its client MPLS-TP layer network. Server MEP OAM
functions are outside the scope of this document. functions are outside the scope of this document.
3.5. Path Segment Tunnels and Tandem Connection Monitoring 3.6. Configuration Considerations
Path segment tunnels (PSTs) are instantiated to provide monitoring of When a control plane is not present, the management plane configures
a portion of a set of co-routed transport paths. Path segment tunnels these functional components. Otherwise they can be configured either
can also be employed to meet the requirement to provide tandem by the management plane or by the control plane.
connection monitoring (TCM).
TCM for a given portion of a transport path is implemented by first Local policy allows to disable the usage of any available "out-of-
creating a path segment tunnel that that has a 1:1 association with band" return path, as defined in [8], to generate OAM reply packets,
portion of the transport path that is to be uniquely monitored. This irrespectively on what is requested by the node originating the OAM
means there is direct correlation between all FM and PM information packet triggering the request.
gathered for the PST AND the monitored portion of the E2E path. The
PST is monitored using normal LSP monitoring.
There are a number of implications to this approach: PSTs are usually instantiated when the transport path is created by
either the management plane or by the control plane (if present).
Sometimes PST can be instantiated after the transport path is
initially created (e.g. PST).
1) The PST would use the uniform model of EXP code point copying 3.7. P2MP considerations
between sub-layers for diffserv such that the E2E markings and
PHB treatment for the transport path was preserved by the PST.
2) The PST would use the pipe model for TTL handling such that MIP All the traffic sent over a p2mp transport path, including OAM
addressing for the E2E entity would be not be impacted by the packets generated by a MEP, is sent (multicast) from the root to all
presence of the PST. the leaves. As a consequence:
3) PM statistics need to be adjusted for the encapsulation overhead o To send an OAM packet to all leaves, the source MEP can send a
of the additional PST sub-layer. single OAM packet that will be delivered by the forwarding plane
to all the leaves and processed by all the leaves.
o To send an OAM packet to a single leaf, the source MEP sends a
single OAM packet that will be delivered by the forwarding plane
to all the leaves but contains sufficient information to
identify a target leaf, and therefore is processed only by the
target leaf and ignored by the other leaves.
o In order to send an OAM packet to M leaves (i.e., a subset of
all the leaves), the source MEP sends M different OAM packets
targeted to each individual leaf in the group of M leaves.
Better mechanisms are outside the scope of this document.
P2MP paths are unidirectional, therefore any return path to a source
MEP for on demand transactions will be out of band.
A mechanism to scope the set of MEPs or MIPs expected to respond to a
given "on demand" transaction is useful as it relieves the source MEP
of the requirement to filter and discard undesired responses as
normally TTL exhaust will address all MIPs at a given distance from
the source, and failure to exhaust TTL will address all MEPs.
4. Reference Model 4. Reference Model
The reference model for the MPLS-TP framework builds upon the concept The reference model for the MPLS-TP framework builds upon the concept
of an MEG, and its associated MEPs and MIPs, to support the of an MEG, and its associated MEPs and MIPs, to support the
functional requirements specified in [12]. functional requirements specified in [12].
The following MPLS-TP MEGs are specified in this document: The following MPLS-TP MEGs are specified in this document:
o A Section Maintenance Entity Group (SME), allowing monitoring and o A Section Maintenance Entity Group (SME), allowing monitoring and
management of MPLS-TP Sections (between MPLS LSRs). management of MPLS-TP Sections (between MPLS LSRs).
o A LSP Maintenance Entity Group (LME), allowing monitoring and o A LSP Maintenance Entity Group (LME), allowing monitoring and
management of an end-to-end LSP (between LERs). management of an end-to-end LSP (between LERs).
o A PW Maintenance Entity Group (PME), allowing monitoring and o A PW Maintenance Entity Group (PME), allowing monitoring and
management of an end-to-end SS/MS-PWs (between T-PEs). management of an end-to-end SS/MS-PWs (between T-PEs).
o A PST Maintenance Entity Group (PSTME), allowing monitoring and o A LSP PST Maintenance Entity Group (LPSTME), allowing monitoring
management of a path segment tunnel (between any LERs/LSRs along and management of a path segment tunnel (between any LERs/LSRs
an LSP). along an LSP).
o A MS-PW Tandem Connection Maintenance Entity (PTCME), allowing o A MS-PW PST Maintenance Entity (PPSTME), allowing monitoring and
monitoring and management of a PW Tandem Connection (between any management of an MPLS-TP path segment tunnel (between any
T-PEs/S-PEs along the (MS-)PW) [Editors': update this bullet after T-PEs/S-PEs along the (MS-)PW).
resolution of PW TCM discussion (discussion point 4 in section
1.2]
The MEGs specified in this MPLS-TP framework are compliant with the The MEGs specified in this MPLS-TP framework are compliant with the
architecture framework for MPLS-TP MS-PWs [7] and LSPs [2]. architecture framework for MPLS-TP MS-PWs [7] and LSPs [2].
Hierarchical LSPs are also supported in the form of path segment Hierarchical LSPs are also supported in the form of path segment
tunnels. In this case, each LSP Tunnel in the hierarchy is a tunnels. In this case, each LSP Tunnel in the hierarchy is a
different sub-layer network that can be monitored, independently from different sub-layer network that can be monitored, independently from
higher and lower level LSP tunnels in the hierarchy, on an end-to-end higher and lower level LSP tunnels in the hierarchy, on an end-to-end
basis (from LER to LER) by a PSTME. It is possible to monitor a basis (from LER to LER) by a PSTME. It is possible to monitor a
portion of a hierarchical LSP by instantiating a hierarchical PSTME portion of a hierarchical LSP by instantiating a hierarchical PSTME
skipping to change at page 23, line 21 skipping to change at page 18, line 12
Section SecYZ. In addition, LSR3 is adjacent to LSRX via the MPLS Section SecYZ. In addition, LSR3 is adjacent to LSRX via the MPLS
Section 3X. Section 3X.
Figure 3 also shows a bi-directional MS-PW (PW1Z) between AC1 on TPE1 Figure 3 also shows a bi-directional MS-PW (PW1Z) between AC1 on TPE1
and AC2 on TPEZ. The MS-PW consists of three bi-directional PW and AC2 on TPEZ. The MS-PW consists of three bi-directional PW
Segments: 1) PW13 segment between T-PE1 and S-PE3 via the bi- Segments: 1) PW13 segment between T-PE1 and S-PE3 via the bi-
directional PSN13 LSP, 2) PW3X segment between S-PE3 and S-PEX, via directional PSN13 LSP, 2) PW3X segment between S-PE3 and S-PEX, via
the bi-directional PSN3X LSP, and 3) PWXZ segment between S-PEX and the bi-directional PSN3X LSP, and 3) PWXZ segment between S-PEX and
T-PEZ via the bi-directional PSNXZ LSP. T-PEZ via the bi-directional PSNXZ LSP.
The MPLS-TP OAM procedures that apply to an MEG of a given transport The MPLS-TP OAM procedures that apply to an MEG are expected to
path are expected to operate independently from procedures on other operate independently from procedures on other MEGs. Yet, this does
MEGs of the same transport path and certainly MEGs of other transport not preclude that multiple MEGs may be affected simultaneously by the
paths. Yet, this does not preclude that multiple MEGs may be affected same network condition, for example, a fiber cut event.
simultaneously by the same network condition, for example, a fiber
cut event.
Note that there are no constrains imposed by this OAM framework on Note that there are no constrains imposed by this OAM framework on
the number, or type (p2p, p2mp, LSP or PW), of MEGs that may be the number, or type (p2p, p2mp, LSP or PW), of MEGs that may be
instantiated on a particular node. In particular, when looking at instantiated on a particular node. In particular, when looking at
Figure 3, it should be possible to configure one or more MEPs on the Figure 3, it should be possible to configure one or more MEPs on the
same node if that node is the endpoint of one or more MEGs. same node if that node is the endpoint of one or more MEGs.
Figure 3 does not describe a PW3X PPSTME because typically PSTs are Figure 3 does not describe a PW3X PPSTME because typically PSTs are
used to monitor an OAM domain (like PW13 and PWXZ PPSTMEs) rather used to monitor an OAM domain (like PW13 and PWXZ PPSTMEs) rather
than the segment between two OAM domains. However the OAM framework than the segment between two OAM domains. However the OAM framework
does not pose any constraints on the way PSTs are instantiated as does not pose any constraints on the way PSTs are instantiated as
long as they are not overlapping. long as they are not overlapping.
The subsections below define the MEGs specified in this MPLS-TP OAM The subsections below define the MEGs specified in this MPLS-TP OAM
architecture framework document. Unless otherwise stated, all architecture framework document. Unless otherwise stated, all
references to domains, LSRs, MPLS Sections, LSPs, pseudowires and references to domains, LSRs, MPLS Sections, LSPs, pseudowires and
MEGs in this section are made in relation to those shown in Figure 3. MEGs in this section are made in relation to those shown in Figure 3.
4.1. MPLS-TP Section Monitoring 4.1. MPLS-TP Section Monitoring (SME)
An MPLS-TP Section ME (SME) is an MPLS-TP maintenance entity intended An MPLS-TP Section ME (SME) is an MPLS-TP maintenance entity intended
to an MPLS Section as defined in [11]. An SME may be configured on to an MPLS Section as defined in [11]. An SME may be configured on
any MPLS section. SME OAM packets must fate share with the user data any MPLS section. SME OAM packets must fate share with the user data
packets sent over the monitored MPLS Section. packets sent over the monitored MPLS Section.
An SME is intended to be deployed for applications where it is An SME is intended to be deployed for applications where it is
preferable to monitor the link between topologically adjacent (next preferable to monitor the link between topologically adjacent (next
hop in this layer network) MPLS (and MPLS-TP enabled) LSRs rather hop in this layer network) MPLS (and MPLS-TP enabled) LSRs rather
than monitoring the individual LSP or PW segments traversing the MPLS than monitoring the individual LSP or PW segments traversing the MPLS
Section and the server layer technology does not provide adequate OAM Section and the server layer technology does not provide adequate OAM
capabilities. capabilities.
|<------------------- MS-PW1Z ------------------->| Figure 3 shows 5 Section MEs configured in the network between AC1
| | and AC2:
| |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| |
V V LSP V V LSP V V LSP V V
+----+ +-+ +----+ +----+ +-+ +----+
+----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+
| |AC1| |=========| |=========| |=========| |AC2| |
| CE1|---|........PW13.......|...PW3X..|.......PWXZ........|---|CE2 |
| | | |=========| |=========| |=========| | | |
+----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+
+----+ +-+ +----+ +----+ +-+ +----+
^--^ ^--^ ^---------^ ^---^ ^---^
Sec12 Sec23 Sec3X SecXY SecYZ
SME SME SME SME SME
Figure 4 Reference Example of MPLS-TP Section MEs (SME)
Figure 4 shows 5 Section MEs configured in the path between AC1 and
AC2:
1. Sec12 ME associated with the MPLS Section between LSR 1 and LSR 2, 1. Sec12 ME associated with the MPLS Section between LSR 1 and LSR 2,
2. Sec23 ME associated with the MPLS Section between LSR 2 and LSR 3, 2. Sec23 ME associated with the MPLS Section between LSR 2 and LSR 3,
3. Sec3X ME associated with the MPLS Section between LSR 3 and LSR X, 3. Sec3X ME associated with the MPLS Section between LSR 3 and LSR X,
4. SecXY ME associated with the MPLS Section between LSR X and LSR Y, 4. SecXY ME associated with the MPLS Section between LSR X and LSR Y,
and and
5. SecYZ ME associated with the MPLS Section between LSR Y and LSR Z. 5. SecYZ ME associated with the MPLS Section between LSR Y and LSR Z.
4.2. MPLS-TP LSP End-to-End Monitoring 4.2. MPLS-TP LSP End-to-End Monitoring (LME)
An MPLS-TP LSP ME (LME) is an MPLS-TP maintenance entity intended to An MPLS-TP LSP ME (LME) is an MPLS-TP maintenance entity intended to
monitor an end-to-end LSP between two LERs. An LME may be configured monitor an end-to-end LSP between two LERs. An LME may be configured
on any MPLS LSP. LME OAM packets must fate share with user data on any MPLS LSP. LME OAM packets must fate share with user data
packets sent over the monitored MPLS-TP LSP. packets sent over the monitored MPLS-TP LSP.
An LME is intended to be deployed in scenarios where it is desirable An LME is intended to be deployed in scenarios where it is desirable
to monitor an entire LSP between its LERs, rather than, say, to monitor an entire LSP between its LERs, rather than, say,
monitoring individual PWs. monitoring individual PWs.
|<------------------- MS-PW1Z ------------------->| Figure 3 depicts 2 LMEs configured in the network between AC1 and
| | AC2: 1) the PSN13 LME between LER 1 and LER 3, and 2) the PSNXZ LME
| |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| |
V V LSP V V LSP V V LSP V V
+----+ +-+ +----+ +----+ +-+ +----+
+----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+
| |AC1| |=========| |=========| |=========| |AC2| |
| CE1|---|........PW13.......|...PW3X..|........PWXZ.......|---|CE2 |
| | | |=========| |=========| |=========| | | |
+----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+
+----+ +-+ +----+ +----+ +-+ +----+
^---------^ ^---------^
PSN13 LME PSNXZ LME
Figure 5 Examples of MPLS-TP LSP MEs (LME)
Figure 5 depicts 2 LMEs configured in the path between AC1 and AC2:
1) the PSN13 LME between LER 1 and LER 3, and 2) the PSNXZ LME
between LER X and LER Y. Note that the presence of a PSN3X LME in between LER X and LER Y. Note that the presence of a PSN3X LME in
such a configuration is optional, hence, not precluded by this such a configuration is optional, hence, not precluded by this
framework. For instance, the SPs may prefer to monitor the MPLS-TP framework. For instance, the SPs may prefer to monitor the MPLS-TP
Section between the two LSRs rather than the individual LSPs. Section between the two LSRs rather than the individual LSPs.
4.3. MPLS-TP LSP Path Segment Tunnel Monitoring 4.3. MPLS-TP LSP Path Segment Tunnel Monitoring (LPSTME)
An MPLS-TP LSP Path Segment Tunnel ME (LPSTME) is an MPLS-TP An MPLS-TP LSP Path Segment Tunnel ME (LPSTME) is an MPLS-TP
maintenance entity intended to monitor an arbitrary part of an LSP maintenance entity intended to monitor an arbitrary part of an LSP
between a given pair of LSRs independently from the end-to-end between a given pair of LSRs independently from the end-to-end
monitoring (LME). An LPSTMEE can monitor an LSP segment or monitoring (LME). An LPSTMEE can monitor an LSP segment or
concatenated segment and it may also include the forwarding engine(s) concatenated segment and it may also include the forwarding engine(s)
of the node(s) at the edge(s) of the segment or concatenated segment. of the node(s) at the edge(s) of the segment or concatenated segment.
Multiple LPSTMEs MAY be configured on any LSP. The LSRs that Multiple LPSTMEs MAY be configured on any LSP. The LSRs that
terminate the LPSTME may or may not be immediately adjacent at the terminate the LPSTME may or may not be immediately adjacent at the
MPLS-TP layer. LPSTME OAM packets must fate share with the user data MPLS-TP layer. LPSTME OAM packets must fate share with the user data
packets sent over the monitored LSP segment. packets sent over the monitored LSP segment.
A LPSTME can be defined between the following entities: A LPSTME can be defined between the following entities:
o LER and any LSR of a given LSP. o LER and any LSR of a given LSP.
o Any two LSRs of a given LSP. o Any two LSRs of a given LSP.
An LPSTME is intended to be deployed in scenarios where it is An LPSTME is intended to be deployed in scenarios where it is
preferable to monitor the behaviour of a part of an LSP or set of preferable to monitor the behaviour of a part of an LSP or set of
LSPs rather than the entire LSP itself, for example when there is a LSPs rather than the entire LSP itself, for example when there is a
need to monitor a part of an LSP that extends beyond the need to monitor a part of an LSP that extends beyond the
administrative boundaries of an MPLS-TP enabled administrative administrative boundaries of an MPLS-TP enabled administrative
domain. domain.
|<--------------------- PW1Z -------------------->| |<--------------------- PW1Z -------------------->|
| | | |
| |<--------------PSN1Z LSP-------------->| | | |<--------------PSN1Z LSP-------------->| |
| |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| |
V V S-LSP V V S-LSP V V S-LSP V V V V S-LSP V V S-LSP V V S-LSP V V
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
+----+ | PE1| | | |DBN3| |DBNX| | | | PEZ| +----+ +----+ | PE1| | | |DBN3| |DBNX| | | | PEZ| +----+
| |AC1| |=======================================| |AC2| | | |AC1| |=======================================| |AC2| |
skipping to change at page 26, line 35 skipping to change at page 20, line 35
| | | | | | | |
|<---- Domain 1 --->| |<---- Domain Z --->| |<---- Domain 1 --->| |<---- Domain Z --->|
^---------^ ^---------^ ^---------^ ^---------^
PSN13 LPSTME PSNXZ LPSTME PSN13 LPSTME PSNXZ LPSTME
^---------------------------------------^ ^---------------------------------------^
PSN1Z LME PSN1Z LME
DBN: Domain Border Node DBN: Domain Border Node
Figure 6 MPLS-TP LSP Path Segment Tunnel ME (LPSTME) Figure 4 MPLS-TP LSP Path Segment Tunnel ME (LPSTME)
Figure 6 depicts a variation of the reference model in Figure 3 where Figure 4 depicts a variation of the reference model in Figure 3 where
there is an end-to-end PSN LSP (PSN1Z LSP) between PE1 and PEZ. PSN1Z there is an end-to-end PSN LSP (PSN1Z LSP) between PE1 and PEZ. PSN1Z
LSP consists of, at least, three LSP Concatenated Segments: PSN13, LSP consists of, at least, three LSP Concatenated Segments: PSN13,
PSN3X and PSNXZ. In this scenario there are two separate LTCMEs PSN3X and PSNXZ. In this scenario there are two separate LPSTMEs
configured to monitor the PSN1Z LSP: 1) a LPSTME monitoring the PSN13 configured to monitor the PSN1Z LSP: 1) a LPSTME monitoring the PSN13
LSP Concatenated Segment on Domain 1 (PSN13 LPSTME), and 2) a LPSTME LSP Concatenated Segment on Domain 1 (PSN13 LPSTME), and 2) a LPSTME
monitoring the PSNXZ LSP Concatenated Segment on Domain Z (PSNXZ monitoring the PSNXZ LSP Concatenated Segment on Domain Z (PSNXZ
LPSTME). LPSTME).
It is worth noticing that LPSTMEs can coexist with the LME monitoring It is worth noticing that LPSTMEs can coexist with the LME monitoring
the end-to-end LSP and that LPSTME MEPs and LME MEPs can be the end-to-end LSP and that LPSTME MEPs and LME MEPs can be
coincident in the same node (e.g. PE1 node supports both the PSN1Z coincident in the same node (e.g. PE1 node supports both the PSN1Z
LME MEP and the PSN13 LPSTME MEP). LME MEP and the PSN13 LPSTME MEP).
4.4. MPLS-TP PW Monitoring 4.4. MPLS-TP PW Monitoring (PME)
An MPLS-TP PW ME (PME) is an MPLS-TP maintenance entity intended to An MPLS-TP PW ME (PME) is an MPLS-TP maintenance entity intended to
monitor a SS-PW or MS-PW between a pair of T-PEs. A PME MAY be monitor a SS-PW or MS-PW between a pair of T-PEs. A PME MAY be
configured on any SS-PW or MS-PW. PME OAM packets must fate share configured on any SS-PW or MS-PW. PME OAM packets must fate share
with the user data packets sent over the monitored PW. with the user data packets sent over the monitored PW.
A PME is intended to be deployed in scenarios where it is desirable A PME is intended to be deployed in scenarios where it is desirable
to monitor an entire PW between a pair of MPLS-TP enabled T-PEs to monitor an entire PW between a pair of MPLS-TP enabled T-PEs
rather than monitoring the LSP aggregating multiple PWs between PEs. rather than monitoring the LSP aggregating multiple PWs between PEs.
skipping to change at page 27, line 30 skipping to change at page 21, line 30
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
+----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+
| |AC1| |=========| |=========| |=========| |AC2| | | |AC1| |=========| |=========| |=========| |AC2| |
| CE1|---|........PW13.......|...PW3X..|........PWXZ.......|---|CE2 | | CE1|---|........PW13.......|...PW3X..|........PWXZ.......|---|CE2 |
| | | |=========| |=========| |=========| | | | | | | |=========| |=========| |=========| | | |
+----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
^---------------------PW1Z PME--------------------^ ^---------------------PW1Z PME--------------------^
Figure 7 MPLS-TP PW ME (PME) Figure 5 MPLS-TP PW ME (PME)
Figure 7 depicts a MS-PW (MS-PW1Z) consisting of three segments: Figure 5 depicts a MS-PW (MS-PW1Z) consisting of three segments:
PW13, PW3X and PWXZ and its associated end-to-end PME (PW1Z PME). PW13, PW3X and PWXZ and its associated end-to-end PME (PW1Z PME).
4.5. MPLS-TP MS-PW Path Segment Tunnel Monitoring 4.5. MPLS-TP MS-PW Path Segment Tunnel Monitoring (PPSTME)
[Editors' note: revise this section after the discussion on PW TCM is
closed (discussion item 4 in section 1.2)]
An MPLS-TP MS-PW Path Segment Tunnel Monitoring ME (PPSTME) is an An MPLS-TP MS-PW Path Segment Tunnel Monitoring ME (PPSTME) is an
MPLS-TP maintenance entity intended to monitor an arbitrary part of MPLS-TP maintenance entity intended to monitor an arbitrary part of
an MS-PW between a given pair of PEs independently from the end-to- an MS-PW between a given pair of PEs independently from the end-to-
end monitoring (PME). A PPSTME can monitor a PW segment or end monitoring (PME). A PPSTME can monitor a PW segment or
concatenated segment and it may also include the forwarding engine(s) concatenated segment and it may also include the forwarding engine(s)
of the node(s) at the edge(s) of the segment or concatenated segment. of the node(s) at the edge(s) of the segment or concatenated segment.
Multiple PPSTMEs MAY be configured on any MS-PW. The PEs may or may Multiple PPSTMEs MAY be configured on any MS-PW. The PEs may or may
not be immediately adjacent at the MS-PW layer. PPSTME OAM packets not be immediately adjacent at the MS-PW layer. PPSTME OAM packets
fate share with the user data packets sent over the monitored PW fate share with the user data packets sent over the monitored PW
Segment. Segment.
A PPSTME can be defined between the following entities: A PPSTME can be defined between the following entities:
skipping to change at page 28, line 31 skipping to change at page 22, line 26
+----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+
| |AC1| |=========| |=========| |=========| |AC2| | | |AC1| |=========| |=========| |=========| |AC2| |
| CE1|---|........PW13.......|...PW3X..|........PWXZ.......|---|CE2 | | CE1|---|........PW13.......|...PW3X..|........PWXZ.......|---|CE2 |
| | | |=========| |=========| |=========| | | | | | | |=========| |=========| |=========| | | |
+----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
^---- PW1 PPSTME----^ ^---- PW5 PPSTME----^ ^---- PW1 PPSTME----^ ^---- PW5 PPSTME----^
^---------------------PW1Z PME--------------------^ ^---------------------PW1Z PME--------------------^
Figure 8 MPLS-TP MS-PW Path Segment Tunnel Monitoring (PPSTME) Figure 6 MPLS-TP MS-PW Path Segment Tunnel Monitoring (PPSTME)
Figure 8 depicts the same MS-PW (MS-PW1Z) between AC1 and AC2 as in Figure 6 depicts the same MS-PW (MS-PW1Z) between AC1 and AC2 as in
Figure 7. In this scenario there are two separate PPSTMEs configured Figure 5. In this scenario there are two separate PPSTMEs configured
to monitor MS-PW1Z: 1) a PPSTME monitoring the PW13 MS-PW Segment on to monitor MS-PW1Z: 1) a PPSTME monitoring the PW13 MS-PW Segment on
Domain 1 (PW13 PPSTME), and 2) a PTCME monitoring the PWXZ MS-PW Domain 1 (PW13 PPSTME), and 2) a PPSTME monitoring the PWXZ MS-PW
Segment on Domain Z with (PWXZ PPSTME). Segment on Domain Z with (PWXZ PPSTME).
It is worth noticing that PPSTMEs can coexist with the PME monitoring It is worth noticing that PPSTMEs can coexist with the PME monitoring
the end-to-end MS-PW and that PPSTME MEPs and PME MEPs can be the end-to-end MS-PW and that PPSTME MEPs and PME MEPs can be
coincident in the same node (e.g. TPE1 node supports both the PW1Z coincident in the same node (e.g. TPE1 node supports both the PW1Z
PME MEP and the PW13 PPSTME MEP). PME MEP and the PW13 PPSTME MEP).
5. OAM Functions for proactive monitoring 5. OAM Functions for proactive monitoring
[Editors' note: at the beginning of each section, reference the
section in the OAM Requirements document and explicitly list
additional detailed requirements wrt the OAM Requirements document]
In this document, proactive monitoring refers to OAM operations that In this document, proactive monitoring refers to OAM operations that
are either configured to be carried out periodically and continuously are either configured to be carried out periodically and continuously
or preconfigured to act on certain events such as alarm signals. or preconfigured to act on certain events such as alarm signals.
Proactive monitoring is frequently "in service" monitoring. The
control and measurement implications are:
1. Proactive monitoring for a MEG is typically configured at
transport path creation time.
2. The operational characteristics of in-band measurement
transactions (e.g., CV, LM etc.) are configured at the MEPs.
3. Server layer events are reported by transactions originating at
intermediate nodes.
4. The measurements resulting from proactive monitoring are typically
only reported outside of the MEG as unsolicited notifications for
"out of profile" events, such as faults or loss measurement
indication of excessive impairment of information transfer
capability.
5. The measurements resulting from proactive monitoring may be
periodically harvested by an EMS/NMS.
5.1. Continuity Check and Connectivity Verification 5.1. Continuity Check and Connectivity Verification
Proactive Continuity Check functions are used to detect a loss of Proactive Continuity Check functions, as required in section 2.2.2 of
continuity defect (LOC) between two MEPs in an MEG. [12], are used to detect a loss of continuity defect (LOC) between
two MEPs in an MEG.
Proactive Connectivity Verification functions are used to detect an Proactive Connectivity Verification functions, as required in section
unexpected connectivity defect between two MEGs (e.g. mismerging or 2.2.3 of [12], are used to detect an unexpected connectivity defect
misconnection), as well as unexpected connectivity within the MEG between two MEGs (e.g. mismerging or misconnection), as well as
with an unexpected MEP. unexpected connectivity within the MEG with an unexpected MEP.
Both functions are based on the (proactive) generation of OAM packets Both functions are based on the (proactive) generation of OAM packets
by the source MEP that are processed by the sink MEP. As a by the source MEP that are processed by the sink MEP. As a
consequence these two functions are grouped together into Continuity consequence these two functions are grouped together into Continuity
Check and Connectivity Verification (CC-V) OAM packets. Check and Connectivity Verification (CC-V) OAM packets.
In order to perform pro-active Connectivity Verification function, In order to perform pro-active Connectivity Verification function,
each CC-V OAM packet MUST also include a globally unique Source MEP each CC-V OAM packet MUST also include a globally unique Source MEP
identifier. When used to perform only pro-active Continuity Check identifier. When used to perform only pro-active Continuity Check
function, the CC-V OAM packet MAY not include any globally unique function, the CC-V OAM packet MAY not include any globally unique
Source MEP identifier identifier. Different formats of MEP Source MEP identifier. Different formats of MEP identifiers are
identifiers are defined in [10] to address different environments. defined in [10] to address different environments. When MPLS-TP is
When MPLS-TP is deployed in transport network environments where IP deployed in transport network environments where IP addressing is not
addressing is not used in the forwarding plane, the ICC-based format used in the forwarding plane, the ICC-based format for MEP
for MEP identification is used. When MPLS-TP is deployed in IP-based identification is used. When MPLS-TP is deployed in IP-based
environment, the IP-based MEP identification is used. environment, the IP-based MEP identification is used.
As a consequence, it is not possible to detect misconnections between As a consequence, it is not possible to detect misconnections between
two MEGs monitored only for Continuity while it is possible to detect two MEGs monitored only for continuity as neither the OAM message
any misconnection between two MEGs monitored for Continuity and type nor OAM message content provides sufficient information to
Connectivity or between an MEG monitored for Continuity and disambiguate an invalid source. To expand:
Connectivity and one MEG monitored only for Continuity.
[Editor's note - Rephrase the previous paragraph: describe the four o For CC leaking into a CC monitored MEG - undetectable
cases.]
o For CV leaking into a CC monitored MEG - presence of additional
Source MEP identifier allows detecting the fault
o For CC leaking into a CV monitored MEG - lack of additional Source
MEP identifier allows detecting the fault.
o For CV leaking into a CV monitored MEG - different Source MEP
identifier permits fault to be identified.
CC-V OAM packets MUST be transmitted at a regular, operator's CC-V OAM packets MUST be transmitted at a regular, operator's
configurable, rate. The default CC-V transmission periods are configurable, rate. The default CC-V transmission periods are
application dependent (see section 5.1.4). application dependent (see section 5.1.3).
Proactive CC-V OAM packets are transmitted with the "minimum loss Proactive CC-V OAM packets are transmitted with the "minimum loss
probability PHB" within a single network operator. This PHB is probability PHB" within a single network operator. This PHB is
configurable on network operator's basis. PHBs can be translated at configurable on network operator's basis. PHBs can be translated at
the network borders by the same function that translates it for user the network borders by the same function that translates it for user
data traffic. data traffic. The implication is that CC-V fate shares with much of
the forwarding implementation, but not all aspects of PHB processing
[Editor's note - Describe the relation between the previous paragraph are exercised. On demand tools are used for finer grained fault
and the fate sharing requirement. Need to clarify also in the finding.
requirement document that for proactive CC-V the fate sharing is
related to the forwarding behavior and not to the QoS behavior]
In a bidirectional point-to-point transport path, when a MEP is In a bidirectional point-to-point transport path, when a MEP is
enabled to generate pro-active CC-V OAM packets with a configured enabled to generate pro-active CC-V OAM packets with a configured
transmission rate, it also expects to receive pro-active CC-V OAM transmission rate, it also expects to receive pro-active CC-V OAM
packets from its peer MEP at the same transmission rate as a common packets from its peer MEP at the same transmission rate as a common
SLA applies to all components of the transport path. In a SLA applies to all components of the transport path. In a
unidirectional transport path (either point-to-point or point-to- unidirectional transport path (either point-to-point or point-to-
multipoint), only the source MEP is enabled to generate CC-V OAM multipoint), only the source MEP is enabled to generate CC-V OAM
packets and only the sink MEP is configured to expect these packets packets and only the sink MEP is configured to expect these packets
at the configured rate. at the configured rate.
skipping to change at page 31, line 50 skipping to change at page 26, line 20
o Exit criteria: the sink MEP does not receive any pro-active CC-V o Exit criteria: the sink MEP does not receive any pro-active CC-V
OAM packet with a correct globally unique Source MEP identifier OAM packet with a correct globally unique Source MEP identifier
and an incorrect transmission period for an interval equal at and an incorrect transmission period for an interval equal at
least to 3.5 times the longest transmission period of the pro- least to 3.5 times the longest transmission period of the pro-
active CC-V OAM packets received with a correct globally unique active CC-V OAM packets received with a correct globally unique
Source MEP identifier and an incorrect transmission period since Source MEP identifier and an incorrect transmission period since
this defect has been raised. this defect has been raised.
5.1.2. Consequent action 5.1.2. Consequent action
[editors: IMO this would be better folded into the specific defect
types, If agreed I will edit accordingly]
A sink MEP that detects one of the defect conditions defined in A sink MEP that detects one of the defect conditions defined in
section 5.1.1 MUST perform the following consequent actions. Some of section 5.1.1 MUST perform the following consequent actions.
these consequent actions SHOULD be enabled/disabled by the operator
depending upon the application used (see section 5.1.4).
If a MEP detects an unexpected globally unique Source MEP Identifier, If a MEP detects an unexpected globally unique Source MEP Identifier,
it MUST block all the traffic (including also the user data packets) it MUST block all the traffic (including also the user data packets)
that it receives from the misconnected transport path. that it receives from the misconnected transport path.
If a MEP detects LOC defect that is not caused by a period If a MEP detects LOC defect that is not caused by a period
mis-configuration, it SHOULD block all the traffic (including also mis-configuration, it SHOULD block all the traffic (including also
the user data packets) that it receives from the transport path, if the user data packets) that it receives from the transport path, if
this consequent action has been enabled by the operator. this consequent action has been enabled by the operator.
skipping to change at page 32, line 40 skipping to change at page 27, line 7
action MAY be disabled through configuration. This deactivation of action MAY be disabled through configuration. This deactivation of
the block action may be used for activating or deactivating the the block action may be used for activating or deactivating the
monitoring when it is not possible to synchronize the function monitoring when it is not possible to synchronize the function
activation of the two peer MEPs. activation of the two peer MEPs.
If a MEP detects a LOC defect (section 5.1.1.1), a mis-connectivity If a MEP detects a LOC defect (section 5.1.1.1), a mis-connectivity
defect (section 5.1.1.2) or a period misconfiguration defect (section defect (section 5.1.1.2) or a period misconfiguration defect (section
5.1.1.3), it MUST declare a signal fail condition at the transport 5.1.1.3), it MUST declare a signal fail condition at the transport
path level. path level.
[Editor's note - Transport equipment also performs defect correlation
(as defined in G.806) in order to properly report failures to the
transport NMS]. The current working assumption, to be further
investigated, is that defect correlations are outside the scope of
this document and to be defined in ITU-T documents.]
5.1.3. Configuration considerations 5.1.3. Configuration considerations
At all MEPs inside a MEG, the following configuration information At all MEPs inside a MEG, the following configuration information
needs to be configured when a proactive CC-V function is enabled: needs to be configured when a proactive CC-V function is enabled:
o MEG ID; the MEG identifier to which the MEP belongs; o MEG ID; the MEG identifier to which the MEP belongs;
o MEP-ID; the MEP's own identity inside the MEG; o MEP-ID; the MEP's own identity inside the MEG;
o list of peer MEPs inside the MEG. For a point-to-point MEG the o list of peer MEPs inside the MEG. For a point-to-point MEG the
list would consist of the single peer MEP ID from which the OAM list would consist of the single peer MEP ID from which the OAM
packets are expected. In case of the root MEP of a p2mp MEG, the 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. In case 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 composed by the root of the leaf MEP of a p2mp MEG, the list is composed by the root
MEP ID (i.e. each leaf MUST know the root MEP ID from which it MEP ID (i.e. each leaf MUST know the root MEP ID from which it
expect to receive the CC-V OAM packets). expect to receive the CC-V OAM packets).
o transmission rate; the default CC-V transmission periods are
application dependent (see section 5.1.4)
Note that the reception period is the same as the configured
transmission rate.
o PHB; it identifies the per-hop behaviour of CC-V packet. Proactive o PHB; it identifies the per-hop behaviour of CC-V packet. Proactive
CC-V packets are transmitted with the "minimum loss probability CC-V packets are transmitted with the "minimum loss probability
PHB" previously configured within a single network operator. This PHB" previously configured within a single network operator. This
PHB is configurable on network operator's basis. PHBs can be PHB is configurable on network operator's basis. PHBs can be
translated at the network borders. translated at the network borders.
For statically provisioned transport paths the above information are o transmission rate; the default CC-V transmission periods are
statically configured; for dynamically established transport paths application dependent (depending on whether they are used to
the configuration information are signaled via the control plane. support fault management, performance monitoring, or protection
switching applications):
5.1.4. Applications for proactive CC-V
CC-V is applicable for fault management, performance monitoring, or
protection switching applications.
o Fault Management: default transmission period is 1s (i.e. o Fault Management: default transmission period is 1s (i.e.
transmission rate of 1 packet/second). transmission rate of 1 packet/second).
o Performance Monitoring: default transmission period is 100ms (i.e. o Performance Monitoring: default transmission period is 100ms
transmission rate of 10 packets/second). Performance monitoring is (i.e. transmission rate of 10 packets/second). Performance
only relevant when the transport path is defect free. CC-V monitoring is only relevant when the transport path is defect
contributes to the accuracy of PM statistics by permitting the free. CC-V contributes to the accuracy of PM statistics by
defect free periods to be properly distinguished. permitting the defect free periods to be properly
distinguished.
o Protection Switching: default transmission period is 3.33ms (i.e. o Protection Switching: default transmission period is 3.33ms
transmission rate of 300 packets/second), in order to achieve sub- (i.e. transmission rate of 300 packets/second), in order to
50ms the CC-V defect entry criteria should resolve in less than achieve sub-50ms the CC-V defect entry criteria should resolve
10msec, and complete a protection switch within a subsequent in less than 10msec, and complete a protection switch within a
period of 50 msec. subsequent period of 50 msec.
It SHOULD be possible for the operator to configure these It SHOULD be possible for the operator to configure these
transmission rates for all applications, to satisfy his internal transmission rates for all applications, to satisfy his internal
requirements. requirements.
In addition, the operator should be able to define the consequent Note that the reception period is the same as the configured
action to be performed for each of these applications. transmission rate.
For statically provisioned transport paths the above information are
statically configured; for dynamically established transport paths
the configuration information are signaled via the control plane.
The operator SHOULD be able to enable/disable some of the consequent
actions defined in section 5.1.2.
5.2. Remote Defect Indication 5.2. Remote Defect Indication
The Remote Defect Indication (RDI) is an indicator that is The Remote Defect Indication (RDI) function, as required in section
transmitted by a MEP to communicate to its peer MEPs that a signal 2.2.9 of [12], is an indicator that is transmitted by a MEP to
fail condition exists. RDI is only used for bidirectional communicate to its peer MEPs that a signal fail condition exists.
connections and is associated with proactive CC-V activation. The RDI RDI is only used for bidirectional connections and is associated with
indicator is piggy-backed onto the CC-V packet. proactive CC-V activation. The RDI indicator is piggy-backed onto the
CC-V packet.
When a MEP detects a signal fail condition (e.g. in case of a When a MEP detects a signal fail condition (e.g. in case of a
continuity or connectivity defect), it should begin transmitting an continuity or connectivity defect), it should begin transmitting an
RDI indicator to its peer MEP. The RDI information will be included RDI indicator to its peer MEP. The RDI information will be included
in all pro-active CC-V packets that it generates for the duration of in all pro-active CC-V packets that it generates for the duration of
the signal fail condition's existence. the signal fail condition's existence.
[Editor's note - Add some forward compatibility information to cover
the case where future OAM mechanisms that contributes to the signal
fail detection (and RDI generation) are defined.]
A MEP that receives the packets with the RDI information should A MEP that receives the packets with the RDI information should
determine that its peer MEP has encountered a defect condition determine that its peer MEP has encountered a defect condition
associated with a signal fail. associated with a signal fail.
MIPs as well as intermediate nodes not supporting MPLS-TP OAM are MIPs as well as intermediate nodes not supporting MPLS-TP OAM are
transparent to the RDI indicator and forward these proactive CC-V transparent to the RDI indicator and forward these proactive CC-V
packets that include the RDI indicator as regular data packets, i.e. packets that include the RDI indicator as regular data packets, i.e.
the MIP should not perform any actions nor examine the indicator. the MIP should not perform any actions nor examine the indicator.
When the signal fail defect condition clears, the MEP should clear When the signal fail defect condition clears, the MEP should clear
the RDI indicator from subsequent transmission of pro-active CC-V the RDI indicator from subsequent transmission of pro-active CC-V
packets. A MEP should clear the RDI defect upon reception of a pro- packets. A MEP should clear the RDI defect upon reception of a pro-
active CC-V packet from the source MEP with the RDI indicator active CC-V packet from the source MEP with the RDI indicator
cleared. cleared.
5.2.1. Configuration considerations 5.2.1. Configuration considerations
In order to support RDI indication, this may be a unique OAM message In order to support RDI indication, this may be a unique OAM message
or an OAM information element embedded in a CV message. In this case or an OAM information element embedded in a CV message. In this case
the RDI transmission rate and PHB of the OAM packets carrying RDI the RDI transmission rate and PHB of the OAM packets carrying RDI
should be the same as that configured for CC-V. should be the same as that configured for CC-V.
5.2.2. Applications for Remote Defect Indication
RDI is applicable for the following applications:
o Single-ended fault management - A MEP that receives an RDI
indication from its peer MEP, can report a far-end defect
condition (i.e. the peer MEP has detected a signal fail condition
in the traffic direction from the MEP that receives the RDI
indication to the peer MEP that has sent the RDI information).
o Contribution to far-end performance monitoring - The indication of
the far-end defect condition is used as a contribution to the
bidirectional performance monitoring process.
5.3. Alarm Reporting 5.3. Alarm Reporting
The Alarm Reporting function relies upon an Alarm Indication Signal The Alarm Reporting function, as required in section 2.2.8 of [12],
(AIS) message used to suppress alarms following detection of defect relies upon an Alarm Indication Signal (AIS) message used to suppress
conditions at the server (sub-)layer. alarms following detection of defect conditions at the server
(sub-)layer.
o A server MEP that detects a signal fail conditions in the server o A server MEP that detects a signal fail conditions in the server
(sub-)layer, will notify the MPLS-TP client (sub-)layer adaptation (sub-)layer, will notify the MPLS-TP client (sub-)layer adaptation
function, which can generate packets with AIS information in a function, which can generate packets with AIS information in a
direction opposite to its peers MEPs to allow the suppression of direction opposite to its peers MEPs to allow the suppression of
secondary alarms at the MEP in the client (sub-)layer. secondary alarms at the MEP in the client (sub-)layer.
A server MEP is responsible for notifying the MPLS-TP layer network A server MEP is responsible for notifying the MPLS-TP layer network
adaptation function upon fault detection in the server layer network adaptation function upon fault detection in the server layer network
to which the server MEP is associated. to which the server MEP is associated.
skipping to change at page 35, line 51 skipping to change at page 30, line 8
Upon receiving a packet with AIS information an MPLS-TP MEP enters an Upon receiving a packet with AIS information an MPLS-TP MEP enters an
AIS defect condition and suppresses loss of continuity alarms AIS defect condition and suppresses loss of continuity alarms
associated with its peer MEP. A MEP resumes loss of continuity alarm associated with its peer MEP. A MEP resumes loss of continuity alarm
generation upon detecting loss of continuity defect conditions in the generation upon detecting loss of continuity defect conditions in the
absence of AIS condition. absence of AIS condition.
For example, let's consider a fiber cut between LSR 1 and LSR 2 in For example, let's consider a fiber cut between LSR 1 and LSR 2 in
the reference network of Figure 3. Assuming that all the MEGs the reference network of Figure 3. Assuming that all the MEGs
described in Figure 3 have pro-active CC-V enabled, a LOC defect is described in Figure 3 have pro-active CC-V enabled, a LOC defect is
detected by the MEPs of Sec12 SME, PSN13 LME, PW1 PTCME and PW1Z PME, detected by the MEPs of Sec12 SME, PSN13 LME, PW1 PPSTME and PW1Z
however in transport network only the alarm associate to the fiber PME, however in transport network only the alarm associate to the
cut needs to be reported to NMS while all these secondary alarms fiber cut needs to be reported to NMS while all these secondary
should be suppressed (i.e. not reported to the NMS or reported as alarms should be suppressed (i.e. not reported to the NMS or reported
secondary alarms). as secondary alarms).
If the fiber cut is detected by the MEP in the physical layer (in If the fiber cut is detected by the MEP in the physical layer (in
LSR2), LSR2 can generate the proper alarm in the physical layer and LSR2), LSR2 can generate the proper alarm in the physical layer and
suppress the secondary alarm associated with the LOC defect detected suppress the secondary alarm associated with the LOC defect detected
on Sec12 SME. As both MEPs reside within the same node, this process on Sec12 SME. As both MEPs reside within the same node, this process
does not involve any external protocol exchange. Otherwise, if the does not involve any external protocol exchange. Otherwise, if the
physical layer has not enough OAM capabilities to detect the fiber physical layer has not enough OAM capabilities to detect the fiber
cut, the MEP of Sec12 SME in LSR2 will report a LOC alarm. cut, the MEP of Sec12 SME in LSR2 will report a LOC alarm.
In both cases, the MEP of Sec12 SME in LSR 2 notifies the adaptation In both cases, the MEP of Sec12 SME in LSR 2 notifies the adaptation
skipping to change at page 36, line 39 skipping to change at page 30, line 44
AIS packets are transmitted with the "minimum loss probability PHB" AIS packets are transmitted with the "minimum loss probability PHB"
within a single network operator. This PHB is configurable on network within a single network operator. This PHB is configurable on network
operator's basis. operator's basis.
A MIP is transparent to packets with AIS information and therefore A MIP is transparent to packets with AIS information and therefore
does not require any information to support AIS functionality. does not require any information to support AIS functionality.
5.4. Lock Reporting 5.4. Lock Reporting
To be incorporated in a future revision of this document The Lock Reporting function, as required in section 2.2.7 of [12],
relies upon a Locked Report (LKR) message used to suppress alarms
following administrative locking action in the server (sub-)layer.
5.5. Packet Loss Monitoring A server MEP is responsible for notifying the MPLS-TP layer network
adaption function upon locked condition applied to the server layer
network to which the server MEP is associated.
Packet Loss Monitoring (LM) is one of the capabilities supported by Only the client layer adaptation function at an intermediate node
will issue MPLS-TP packets with LKR information. Upon receiving
notification of a locked condition the adaptation function SHOULD
immediately start transmitting periodic packets with LKR information.
These periodic packets, with LKR information, will continue to be
transmitted until the locked condition is cleared.
Upon receiving a packet with LKR information an MPLS-TP MEP enters an
LKR defect condition and suppresses loss of continuity alarm
associated with its peer MEP. A MEP resumes loss of continuity alarm
generation upon detecting loss of continuity defect conditions in the
absence of LKR condition.
The generation of LKR packets is configurable in the server
(sub-)layer (i.e. the operator can enable/disable the LKR
generation).
LKR packets are transmitted with the "minimum loss probability PHB"
within a single network operator. This PHB is configurable on network
operator's basis.
A MIP is transparent to packets with LKR information and therefore
does not require any information to support LKR functionality.
5.5. Packet Loss Measurement
Packet Loss Measurement (LM) is one of the capabilities supported by
the MPLS-TP Performance Monitoring (PM) function in order to the MPLS-TP Performance Monitoring (PM) function in order to
facilitate reporting of QoS information for a transport path. LM is facilitate reporting of QoS information for a transport path as
used to exchange counter values for the number of ingress and egress required in section 2.2.11 of [12]. LM is used to exchange counter
packets transmitted and received by the transport path monitored by a values for the number of ingress and egress packets transmitted and
pair of MEPs. received by the transport path monitored by a pair of MEPs.
Proactive LM is performed by periodically sending LM OAM packets from Proactive LM is performed by periodically sending LM OAM packets from
a MEP to a peer MEP and by receiving LM OAM packets from the peer MEP a MEP to a peer MEP and by receiving LM OAM packets from the peer MEP
(if a bidirectional transport path) during the life time of the (if a bidirectional transport path) during the life time of the
transport path. Each MEP performs measurements of its transmitted and transport path. Each MEP performs measurements of its transmitted and
received packets. These measurements are then transactionally received packets. These measurements are then transactionally
correlated with the peer MEP in the ME to derive the impact of packet correlated with the peer MEP in the ME to derive the impact of packet
loss 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. The LM
transactions are issued such that the OAM packets will experience the transactions are issued such that the OAM packets will experience the
same queuing discipline as the measured traffic while transiting same queuing discipline as the measured traffic while transiting
skipping to change at page 37, line 26 skipping to change at page 32, line 12
For a MEP, near-end packet loss refers to packet loss associated with For a MEP, near-end packet loss refers to packet loss associated with
incoming data packets (from the far-end MEP) while far-end packet incoming data packets (from the far-end MEP) while far-end packet
loss refers to packet loss associated with egress data packets loss refers to packet loss associated with egress data packets
(towards the far-end MEP). (towards the far-end MEP).
5.5.1. Configuration considerations 5.5.1. Configuration considerations
In order to support proactive LM, the transmission rate and PHB In order to support proactive LM, the transmission rate and PHB
associated with the LM OAM packets originating from a MEP need be associated with the LM OAM packets originating from a MEP need be
configured as part of the LM provisioning procedures. LM OAM packets configured as part of the LM provisioning procedures. LM OAM packets
should be transmitted with the PHB that yields the lowest packet loss should be transmitted with the same PHB class that the LM is intended
performance among the PHB Scheduling Classes or Ordered Aggregates to measure. If that PHB is not an ordered aggregate where the
(see RFC 3260 [15]) in the monitored transport path for the relevant ordering constraint is all packets with the PHB being delivered in
network domain(s). order, LM can produce inconsistent results.
5.5.2. Applications for Packet Loss Monitoring
LM is relevant for the following applications:
o Single or double-end performance monitoring: determination of the
packet loss performance of a transport path for Service Level
Agreement (SLA) verification purposes.
o Single or double-end performance monitoring: determination of the
packet loss performance of a PHB Scheduling Class or Ordered
Aggregate within a transport path.
o Contribution to service unable time. Both near-end and far-end
packet loss measurements contribute to performance metrics such as
near-end severely errored seconds (Near-End SES) and far-end
severely errored seconds (Far-End SES) respectively, which
together contribute to unavailable time, in a manner similar to
Recommendation G.826 [19] and Recommendation G.7710 [20].
5.6. Client Signal Failure Indication
The Client Signal Failure Indication (CSF) function is used to help 5.6. Client Failure Indication
process client defects and propagate a client signal defect condition
from the process associated with the local attachment circuit where
the defect was detected (typically the source adaptation function for
the local client interface) to the process associated with the far-
end attachment circuit (typically the source adaptation function for
the far-end client interface) for the same transmission path in case
the client of the transmission path does not support a native
defect/alarm indication mechanism, e.g. FDI/AIS.
[Editor's note - The need to support this function on the LSP layer The Client Failure Indication (CSF) function, as required in section
(and not only at the PW layer) needs to be further investigated. 2.2.10 of [12], is used to help process client defects and propagate
Pending discussion on MPLS-TP clients in the main framework a client signal defect condition from the process associated with the
document.] local attachment circuit where the defect was detected (typically the
source adaptation function for the local client interface) to the
process associated with the far-end attachment circuit (typically the
source adaptation function for the far-end client interface) for the
same transmission path in case the client of the transport path does
not support a native defect/alarm indication mechanism, e.g. AIS.
A source MEP starts transmitting a CSF indication to its peer MEP A source MEP starts transmitting a CSF indication to its peer MEP
when it receives a local client signal defect notification via its when it receives a local client signal defect notification via its
local CSF function. Mechanisms to detect local client signal fail local CSF function. Mechanisms to detect local client signal fail
defects are technology specific. defects are technology specific.
A sink MEP that has received a CSF indication report this condition A sink MEP that has received a CSF indication report this condition
to its associated client process via its local CSF function. to its associated client process via its local CSF function.
Consequent actions toward the client attachment circuit are Consequent actions toward the client attachment circuit are
technology specific. technology specific.
skipping to change at page 38, line 43 skipping to change at page 33, line 5
the MEG, or when multiple clients are multiplexed over a transport the MEG, or when multiple clients are multiplexed over a transport
path, the CSF message requires additional information to permit the path, the CSF message requires additional information to permit the
client instance to be identified. client instance to be identified.
5.6.1. Configuration considerations 5.6.1. Configuration considerations
In order to support CSF indication, the CSF transmission rate and PHB In order to support CSF indication, the CSF transmission rate and PHB
of the CSF OAM message/information element should be configured as of the CSF OAM message/information element should be configured as
part of the CSF configuration. part of the CSF configuration.
5.6.2. Applications for Client Signal Failure Indication 5.7. Packet Delay Measurement
CSF is applicable for the following applications:
o Single-ended fault management - A MEP that receives a CSF
indication from its peer MEP, can report a far-end client defect
condition (i.e. the peer MEP has been informed of local client
signal fail condition in the traffic direction from the client to
the peer MEP that transmitted the CSF).
o Contribution to far-end performance monitoring - The indication of
the far-end defect condition may be used to account on network
operator contribution to the bidirectional performance monitoring
process.
CSF supports the application described in Appendix VIII of ITU-T
G.806 [18].
5.7. Delay Measurement
Delay Measurement (DM) is one of the capabilities supported by the Packet Delay Measurement (DM) is one of the capabilities supported by
MPLS-TP PM function in order to facilitate reporting of QoS the MPLS-TP PM function in order to facilitate reporting of QoS
information for a transport path. Specifically, pro-active DM is used information for a transport path as required in section 2.2.12 of
to measure the long-term packet delay and packet delay variation in [12]. Specifically, pro-active DM is used to measure the long-term
the transport path monitored by a pair of MEPs. packet delay and packet delay variation in the transport path
monitored by a pair of MEPs.
Proactive DM is performed by sending periodic DM OAM packets from a Proactive DM is performed by sending periodic DM OAM packets from a
MEP to a peer MEP and by receiving DM OAM packets from the peer MEP MEP to a peer MEP and by receiving DM OAM packets from the peer MEP
(if a bidirectional transport path) during a configurable time (if a bidirectional transport path) during a configurable time
interval. 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 all o One-way: a MEP sends DM OAM packet to its peer MEP containing all
the required information to facilitate one-way packet delay and/or the required information to facilitate one-way packet delay and/or
skipping to change at page 40, line 5 skipping to change at page 33, line 44
5.7.1. Configuration considerations 5.7.1. Configuration considerations
In order to support pro-active DM, the transmission rate and PHB In order to support pro-active DM, the transmission rate and PHB
associated with the DM OAM packets originating from a MEP need be associated with the DM OAM packets originating from a MEP need be
configured as part of the DM provisioning procedures. DM OAM packets configured as part of the DM provisioning procedures. DM OAM packets
should be transmitted with the PHB that yields the lowest packet loss should be transmitted with the PHB that yields the lowest packet loss
performance among the PHB Scheduling Classes or Ordered Aggregates performance among the PHB Scheduling Classes or Ordered Aggregates
(see RFC 3260 [15]) in the monitored transport path for the relevant (see RFC 3260 [15]) in the monitored transport path for the relevant
network domain(s). network domain(s).
5.7.2. Applications for Delay Measurement
DM is relevant for the following applications:
o Single or double-end performance monitoring: determination of the
delay performance of a transport path for SLA verification
purposes.
o Single or double-end performance monitoring: determination of the
delay performance of a PHB Scheduling Class or Ordered Aggregate
within a transport path
6. OAM Functions for on-demand monitoring 6. OAM Functions for on-demand monitoring
[Editors' note: at the beginning of each section, reference the
section in the OAM Requirements document and explicitly list
additional detailed requirements wrt the OAM Requirements document]
In contrast to proactive monitoring, on-demand monitoring is In contrast to proactive monitoring, on-demand monitoring is
initiated manually and for a limited amount of time, usually for initiated manually and for a limited amount of time, usually for
operations such as e.g. diagnostics to investigate into a defect operations such as e.g. diagnostics to investigate into a defect
condition. condition.
On-demand monitoring covers a combination of "in service" and "out-of
service" monitoring functions. The control and measurement
implications are:
1. A MEG can be directed to perform an "on demand" functions at
arbitrary times in the lifetime of a transport path.
2. "out of service" monitoring functions may require a-priori
configuration of both MEPs and intermediate nodes in the MEG
(e.g., data plane loopback) and the issuance of notifications into
client layers of the transport path being removed from service
(e.g., lock-reporting)
3. The measurements resulting from on-demand monitoring are typically
harvested in real time, as these are frequently craftsperson
initiated and attended. These do not necessarily require different
harvesting mechanisms that that for harvesting proactive
monitoring telemetry.
6.1. Connectivity Verification 6.1. Connectivity Verification
In order to preserve network resources, e.g. bandwidth, processing In order to preserve network resources, e.g. bandwidth, processing
time at switches, it may be preferable to not use proactive CC-V. In time at switches, it may be preferable to not use proactive CC-V. In
order to perform fault management functions, network management may order to perform fault management functions, network management may
invoke periodic on-demand bursts of on-demand CV packets. invoke periodic on-demand bursts of on-demand CV packets, as required
in section 2.2.3 of [12].
Use of on-demand CV is dependent on the existence of a bi-directional
MEG, because it requires the presence of a return path in the data
plane.[Editors': needs to be revised on the basis of the return path
discussion (discussion item 7 in section 1.2]
[Editor's note - Clarify in the sentence above and within the Use of on-demand CV is dependent on the existence of either a bi-
paragraph that on-demand CV requires a return path to send back the directional MEG, or the availability of an out of band return path
reply to on-demand CV packets] because it requires the ability for target MIPs and MEPs to direct
responses to the originating MEPs.
An additional use of on-demand CV would be to detect and locate a An additional use of on-demand CV would be to detect and locate a
problem of connectivity when a problem is suspected or known based on problem of connectivity when a problem is suspected or known based on
other tools. In this case the functionality will be triggered by the other tools. In this case the functionality will be triggered by the
network management in response to a status signal or alarm network management in response to a status signal or alarm
indication. indication.
On-demand CV is based upon generation of on-demand CV packets that On-demand CV is based upon generation of on-demand CV packets that
should uniquely identify the MEG that is being checked. The on- should uniquely identify the MEG that is being checked. The on-
demand functionality may be used to check either an entire MEG (end- demand functionality may be used to check either an entire MEG (end-
to-end) or between a MEP to a specific MIP. This functionality may to-end) or between a MEP to a specific MIP. This functionality may
not be available for associated bidirectional paths as the MIP may not be available for associated bidirectional transport paths, as the
not have a return path to the source MEP for the on-demand CV MIP may not have a return path to the source MEP for the on-demand CV
transaction. transaction.
On-demand CV may generate a one-time burst of on-demand CV packets, On-demand CV may generate a one-time burst of on-demand CV packets,
or be used to invoke periodic, non-continuous, bursts of on-demand CV or be used to invoke periodic, non-continuous, bursts of on-demand CV
packets. The number of packets generated in each burst is packets. The number of packets generated in each burst is
configurable at the MEPs, and should take into account normal packet- configurable at the MEPs, and should take into account normal packet-
loss conditions. loss conditions.
When invoking a periodic check of the MEG, the source MEP should When invoking a periodic check of the MEG, the source MEP should
issue a burst of on-demand CV packets that uniquely identifies the issue a burst of on-demand CV packets that uniquely identifies the
MEG being verified. The number of packets and their transmission MEG being verified. The number of packets and their transmission
rate should be pre-configured and known to both the source MEP and rate should be pre-configured and known to both the source MEP and
the target MEP or MIP. The source MEP should use the TTL field to the target MEP or MIP. The source MEP should use the mechanisms
indicate the number of hops necessary, when targeting a MIP and use defined in sections 3.3 and 3.4 when sending an on-demand CV packet
the default value when performing an end-to-end check [IB => This is to a target MEP or target MIP respectively. The target MEP/MIP shall
quite generic for addressing packets to MIPs and MEPs so it is better return a reply on-demand CV packet for each packet received. If the
to move this text in section 2]. The target MEP/MIP shall return a expected number of on-demand CV reply packets is not received at
reply on-demand CV packet for each packet received. If the expected source MEP, the LOC defect state is entered.
number of on-demand CV reply packets is not received at source MEP,
the LOC defect state is entered.
[Editor's note - We need to add some text for the usage of on-demand On demand CV should have the ability to carry padding such that a
CV with different packet sizes, e.g. to discover MTU problems.] variety of MTU sizes can be originated to verify the MTU capacity of
the transport path.
6.1.1. Configuration considerations 6.1.1. Configuration considerations
For on-demand CV the MEP should support the configuration of the For on-demand CV the MEP should support the configuration of the
number of packets to be transmitted/received in each burst of number of packets to be transmitted/received in each burst of
transmissions and their packet size. The transmission rate should be transmissions and their packet size. The transmission rate should be
configured between the different nodes. configured between the different nodes.
In addition, when the CV packet is used to check connectivity toward In addition, when the CV packet is used to check connectivity toward
a target MIP, the number of hops to reach the target MIP should be a target MIP, the number of hops to reach the target MIP should be
configured. configured.
The PHB of the on-demand CV packets should be configured as well. The PHB of the on-demand CV packets should be configured as well.
This permits the verification of correct operation of QoS queuing as
well as connectivity.
[Editor's note - We need to be better define the reason for such 6.2. Packet Loss Measurement
configuration]
6.2. Packet Loss Monitoring
On-demand Packet Loss (LM) is one of the capabilities supported by On-demand Packet Loss Measurement (LM) is one of the capabilities
the MPLS-TP Performance Monitoring function in order to facilitate supported by the MPLS-TP Performance Monitoring function in order to
diagnostic of QoS performance for a transport path. As proactive LM, facilitate diagnostic of QoS performance for a transport path, as
on-demand LM is used to exchange counter values for the number of required in section 2.2.11 of [12]. As proactive LM, on-demand LM is
ingress and egress packets transmitted and received by the transport used to exchange counter values for the number of ingress and egress
path monitored by a pair of MEPs. packets transmitted and received by the transport path monitored by a
pair of MEPs.
On-demand LM is performed by periodically sending LM OAM packets from On-demand LM is performed by periodically sending LM OAM packets from
a MEP to a peer MEP and by receiving LM OAM packets from the peer MEP a MEP to a peer MEP and by receiving LM OAM packets from the peer MEP
(if a bidirectional transport path) during a pre-defined monitoring (if a bidirectional transport path) during a pre-defined monitoring
period. Each MEP performs measurements of its transmitted and period. Each MEP performs measurements of its transmitted and
received packets. These measurements are then correlated evaluate the received packets. These measurements are then correlated evaluate the
packet loss performance metrics of the transport path. packet loss performance metrics of the transport path.
6.2.1. Configuration considerations 6.2.1. Configuration considerations
In order to support on-demand LM, the beginning and duration of the In order to support on-demand LM, the beginning and duration of the
LM procedures, the transmission rate and PHB associated with the LM LM procedures, the transmission rate and PHB associated with the LM
OAM packets originating from a MEP must be configured as part of the OAM packets originating from a MEP must be configured as part of the
on-demand LM provisioning procedures. LM OAM packets should be on-demand LM provisioning procedures. LM OAM packets should be
transmitted with the PHB that yields the lowest packet loss transmitted with the PHB that yields the lowest packet loss
performance among the PHB Scheduling Classes or Ordered Aggregates performance among the PHB Scheduling Classes or Ordered Aggregates
(see RFC 3260 [15]) in the monitored transport path for the relevant (see RFC 3260 [15]) in the monitored transport path for the relevant
network domain(s). network domain(s).
6.2.2. Applications for On-demand Packet Loss Monitoring 6.3. Diagnostic Tests
On-demand LM is relevant for the following applications: 6.3.1. Throughput Estimation
o Single-end performance monitoring: diagnostic of the packet loss Throughput estimation is an on-demand out-of-service function, as
performance of a transport path for SLA trouble shooting purposes. required in section 2.2.5 of [12], that allows verifying the
bandwidth/throughput of an MPLS-TP transport path (LSP or PW) before
it is put in-service.
o Single-end performance monitoring: diagnostic of the packet loss Throughput estimation is performed between MEPs and can be performed
performance of a PHB Scheduling Class or Ordering Aggregate within in one-way or two way modes.
a transport path for QoS trouble shooting purposes.
6.3. Diagnostic This test is performed by sending OAM test packets at increasing rate
(up to the theoretical maximum), graphing the percentage of OAM test
packets received and reporting the rate at which OAM test packets
start begin dropped. In general, this rate is dependent on the OAM
test packet size.
To be incorporated in a future revision of this document When configured to perform such tests, a MEP source inserts OAM test
packets with test information with specified throughput, packet size
and transmission patterns.
[Editors' note: describe an OAM tool for throughput estimation (out- For one way test, remote MEP sink receives the OAM test packets and
of-service): works in one-way and two-way modes] calculates the packet loss. For two way test, the remote MEP
loopbacks the OAM test packets back to original MEP and the local MEP
sink calculates the packet loss.
[Editors' note: Need further investigation about the need to support 6.3.1.1. Configuration considerations
a data-plane loopback. If needed, which layer does have to support
this function (i.e. the MPLS-TP layer or its server layer?) It is
also needed to understand whether it is needed to specify where this
data-plane loopback takes place within the equipment]
[Munich: Need to describe the two types of loopback - LBM/LBR and Throughput estimation is an out-of-service tool. The diagnosed MEG
traffic loopback enhanced with variable sized packets in the on should be put into a Lock status before the diagnostic test is
demand cases. started.
One objective of diags is fault location, we need to make clear how An MEG can be put into a Lock status either via NMS action or using
we apply the tools to fault location. the Lock Instruct OAM tool as defined in section 6.6.
At the top of each section we need to describe the detailed At the transmitting MEP, provisioning is required for a test signal
requirements and then in the rest of the section describe how it is generator, which is associated with the MEP. At a receiving MEP,
met.] provisioning is required for a test signal detector which is
associated with the MEP.
6.4. Route Tracing A MIP is transparent to the OAM test packets sent for throught
estimation and therefore does not require any provisioning to support
MPLS-TP throghtput estimation.
[Editors' note: The framework needs to say what you need to trace and 6.3.2. Data plane Loopback
not how you do it (remove the description of the solution).]
[Editors' note: Need to investigate if we need both tracing options: Data plane loopback is an out-of-service function, as required in
describe why and a sketch of the two options and their properties. section 2.2.5 of [12], that permits traffic originated at the ingress
of a transport path to be looped back to the point of origin by an
interface at either an intermediate node or a terminating node.
Possible reasons for both options: If the loopback function is to be performed at an intermediate 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 both co-
routed bi-directional or associated bi-directional paths.
o TTL incremental tells whether the CP is correct or not Where a node implements data plane loopback capability and whether it
implements more than one point is implementation dependent.
o the second one (path discovery) is ... 6.4. Route Tracing
Action: check on the mailing list the need to support both modes of It is often necessary to trace a route covered by an MEG from a
operations.] source MEP to the sink MEP including all the MIPs in-between after
e.g., provisioning an MPLS-TP transport path or for trouble shooting
purposes, it.
After e.g. provisioning an MPLS-TP LSP or for trouble shooting The route tracing function, as required in section 2.2.4 of [12], is
purposes, it is often necessary to trace a route covered by an ME providing this functionality. Based on the fate sharing requirement
from a source MEP to the sink MEP including all the MIPs in-between. of OAM flows, i.e. OAM packets receive the same forwarding treatment
The route tracing function is providing this functionality. Based on as data packet, route tracing is a basic means to perform
the fate sharing requirement of OAM flows, i.e. OAM packets receive connectivity verification and, to a much lesser degree, continuity
the same forwarding treatment as data packet, route tracing is a check. For this function to work properly, a return path must be
basic means to perform CV and, to a much lesser degree, CC. For this present.
function to work properly, a return path must be present.
Route tracing might be implemented in different ways and this Route tracing might be implemented in different ways and this
document does not preclude any of them. Route trace could be document does not preclude any of them.
implemented e.g. by an MPLS traceroute-like function [RFC4379].
However, route tracing should always return the full list of MIPs and Route tracing should always discover the full list of MIPs and of the
the peer MEP in it answer(s). In case a defect exist, the route trace peer MEPs. In case a defect exist, the route trace function needs to
function needs to be able to detect it and stop automatically be able to detect it and stop automatically returning the incomplete
returning the incomplete list of OAM entities that it was able to list of OAM entities that it was able to trace.
trace.
6.4.1. Configuration considerations
The configuration of the route trace function must at least support The configuration of the route trace function must at least support
the setting of the trace depth (number of hops)_and the number of the setting of the number of trace attempts before it gives up.
trace attempts before it gives up. Default setting need to be
configurable by the operator, too.
6.5. Delay Measurement 6.5. Packet Delay Measurement
Delay Measurement (DM) is one of the capabilities supported by the Packet Delay Measurement (DM) is one of the capabilities supported by
MPLS-TP PM function in order to facilitate reporting of QoS the MPLS-TP PM function in order to facilitate reporting of QoS
information for a transport path. Specifically, on-demand DM is used information for a transport path, as required in section 2.2.12 of
to measure packet delay and packet delay variation in the transport [12]. Specifically, on-demand DM is used to measure packet delay and
path monitored by a pair of MEPs during a pre-defined monitoring packet delay variation in the transport path monitored by a pair of
period. MEPs during a pre-defined monitoring period.
On-Demand DM is performed by sending periodic DM OAM packets from a On-Demand DM is performed by sending periodic DM OAM packets from a
MEP to a peer MEP and by receiving DM OAM packets from the peer MEP MEP to a peer MEP and by receiving DM OAM packets from the peer MEP
(if a bidirectional transport path) during a configurable time (if a bidirectional transport path) during a configurable time
interval. interval.
On-demand DM can be operated in two ways: On-demand DM can be operated in two ways:
o One-way: a MEP sends DM OAM packet to its peer MEP containing all o One-way: a MEP sends DM OAM packet to its peer MEP containing all
the required information to facilitate one-way packet delay and/or the required information to facilitate one-way packet delay and/or
skipping to change at page 45, line 9 skipping to change at page 39, line 11
OAM packets originating from a MEP need be configured as part of the OAM packets originating from a MEP need be configured as part of the
LM provisioning procedures. DM OAM packets should be transmitted with LM provisioning procedures. DM OAM packets should be transmitted with
the PHB that yields the lowest packet delay performance among the PHB the PHB that yields the lowest packet delay performance among the PHB
Scheduling Classes or Ordering Aggregates (see RFC 3260 [15]) in the Scheduling Classes or Ordering Aggregates (see RFC 3260 [15]) in the
monitored transport path for the relevant network domain(s). monitored transport path for the relevant network domain(s).
In order to verify different performances between long and short In order to verify different performances between long and short
packets (e.g., due to the processing time), it SHOULD be possible for packets (e.g., due to the processing time), it SHOULD be possible for
the operator to configure of the on-demand OAM DM packet. the operator to configure of the on-demand OAM DM packet.
6.5.2. Applications for Delay Measurement 6.6. Lock Instruct
DM is relevant for the following applications: Lock Instruct (LKI) function, as required in section 2.2.6 of [12],
is a command allowing a MEP to instruct the peer MEP(s) to put the
MPLS-TP transport path into a locked condition.
o Single or double-end performance monitoring: determination of the This function allows single-side provisioning for administratively
packet delay and/or delay variation performance of a transport locking (and unlocking) an MPLS-TP transport path.
path for SLA verification purposes.
o Single or double-end performance monitoring: determination of the Note that it is also possible to administratively lock (and unlock)
packet delay and/or delay variation a PHB Scheduling Class or an MPLS-TP transport path using two-side provisioning, where the NMS
Ordering Aggregate within a transport path administratively put both MEPs into ad administrative lock condition.
In this case, the LKI function is not required/used.
o Contribution to service unable time. Packet delay measurements may 6.6.1. Locking a transport path
contribute to performance metrics such as near-end severely
errored seconds (Near-End SES) and far-end severely errored
seconds (Far-End SES), which together contribute to unavailable
time.
6.6. Lock Instruct A MEP, upon receiving a single-side administrative lock command from
NMS, sends an LKI request OAM packet to its peer MEP(s). It also puts
the MPLS-TP transport path into a locked and notify its client
(sub-)layer adaptation function upon the locked condition.
To be incorporated in a future revision of this document A MEP, upon receiving an LKI request from its peer MEP, can accept or
not the instruction and MUST reply to the peer MEP with an LKI reply
OAM packet indicating whether it has accepted or not the instruction.
If the lock instruction has been accepted, it also puts the MPLS-TP
transport path into a locked and notify its client (sub-)layer
adaptation function upon the locked condition.
Note that if the client (sub-)layer is also MPLS-TP, Lock Reporting
(LKR) generation at the client MPLS-TP (sub-)layer is started, as
described in section 5.4.
6.6.2. Unlocking a transport path
A MEP, upon receiving a single-side administrative unlock command
from NMS, sends an LKI removal request OAM packet to its peer MEP(s).
The peer MEP, upon receiving an LKI removal request, can accept or
not the removal instruction and MUST reply with an LKI removal reply
OAM packet indicating whether it has accepted or not the instruction.
If the lock removal instruction has been accepted, it also clears the
locked condition on the MPLS-TP transport path and notify this event
to its client (sub-)layer adaptation function.
The MEP that has initiated the LKI clear procedure, upon receiving a
positive LKI removal reply, also clears the locked condition on the
MPLS-TP transport path and notify this event to its client
(sub-)layer adaptation function.
Note that if the client (sub-)layer is also MPLS-TP, Lock Reporting
(LKR) generation at the client MPLS-TP (sub-)layer is terminated, as
described in section 5.4.
7. Security Considerations 7. Security Considerations
A number of security considerations are important in the context of A number of security considerations are important in the context of
OAM applications. OAM applications.
OAM traffic can reveal sensitive information such as passwords, OAM traffic can reveal sensitive information such as passwords,
performance data and details about e.g. the network topology. The performance data and details about e.g. the network topology. The
nature of OAM data therefore suggests to have some form of nature of OAM data therefore suggests to have some form of
authentication, authorization and encryption in place. This will authentication, authorization and encryption in place. This will
skipping to change at page 46, line 12 skipping to change at page 40, line 49
No new IANA considerations. No new IANA considerations.
9. Acknowledgments 9. Acknowledgments
The authors would like to thank all members of the teams (the Joint The authors would like to thank all members of the teams (the Joint
Working Team, the MPLS Interoperability Design Team in IETF and the Working Team, the MPLS Interoperability Design Team in IETF and the
T-MPLS Ad Hoc Group in ITU-T) involved in the definition and T-MPLS Ad Hoc Group in ITU-T) involved in the definition and
specification of MPLS Transport Profile. specification of MPLS Transport Profile.
The editors gratefully acknowledge the contributions of Adrian
Farrel, Yoshinori Koike and Luca Martini for per-interface MIPs and
MEPs description.
The editors gratefully acknowledge the contributions of Malcolm
Betts, Yoshinori Koike, Xiao Min, and Maarten Vissers for the lock
report and lock instruction description.
The authors would also like to thank Malcolm Betts, Stewart Bryant,
Rui Costa, Adrian Farrel, Liu Gouman, Feng Huang, Yoshionori Koike,
Yuji Tochio, Maarten Vissers and Xuequin Wei for their comments and
enhancements to the text.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
10. References 10. References
10.1. Normative References 10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997 Levels", BCP 14, RFC 2119, March 1997
[2] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol Label [2] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol Label
skipping to change at page 47, line 34 skipping to change at page 42, line 34
[6] Nadeau, T., Pignataro, S., "Pseudowire Virtual Circuit [6] Nadeau, T., Pignataro, S., "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007 Pseudowires", RFC 5085, December 2007
[7] Bocci, M., Bryant, S., "An Architecture for Multi-Segment [7] Bocci, M., Bryant, S., "An Architecture for Multi-Segment
Pseudo Wire Emulation Edge-to-Edge", draft-ietf-pwe3-ms-pw- Pseudo Wire Emulation Edge-to-Edge", draft-ietf-pwe3-ms-pw-
arch-05 (work in progress), September 2008 arch-05 (work in progress), September 2008
[8] Bocci, M., et al., "A Framework for MPLS in Transport [8] Bocci, M., et al., "A Framework for MPLS in Transport
Networks", draft-ietf-mpls-tp-framework-06 (work in progress), Networks", draft-ietf-mpls-tp-framework-10 (work in progress),
October 2009 February 2010
[9] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, R., [9] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, R.,
"MPLS Generic Associated Channel", RFC 5586, June 2009 "MPLS Generic Associated Channel", RFC 5586, June 2009
[10] Swallow, G., Bocci, M., "MPLS-TP Identifiers", draft-ietf-mpls- [10] Swallow, G., Bocci, M., "MPLS-TP Identifiers", draft-ietf-mpls-
tp-identifiers-00 (work in progress), November 2009 tp-identifiers-00 (work in progress), November 2009
10.2. Informative References 10.2. Informative References
[11] Niven-Jenkins, B., Brungard, D., Betts, M., sprecher, N., Ueno, [11] Niven-Jenkins, B., Brungard, D., Betts, M., sprecher, N., Ueno,
S., "MPLS-TP Requirements", RFC 5654, September 2009 S., "MPLS-TP Requirements", RFC 5654, September 2009
[12] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in [12] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in
MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements- MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements-
03 (work in progress), August 2009 06 (work in progress), March 2010
[13] Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten, Y., [13] Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten, Y.,
"MPLS-TP OAM Analysis", draft-ietf-mpls-tp-oam-analysis-00 "MPLS-TP OAM Analysis", draft-ietf-mpls-tp-oam-analysis-01
(work in progress), November 2009 (work in progress), March 2010
[14] Nichols, K., Blake, S., Baker, F., Black, D., "Definition of [14] Nichols, K., Blake, S., Baker, F., Black, D., "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC 2474, December 1998 IPv6 Headers", RFC 2474, December 1998
[15] Grossman, D., "New terminology and clarifications for [15] Grossman, D., "New terminology and clarifications for
Diffserv", RFC 3260, April 2002. Diffserv", RFC 3260, April 2002.
[16] ITU-T Recommendation G.707/Y.1322 (01/07), "Network node [16] ITU-T Recommendation G.707/Y.1322 (01/07), "Network node
interface for the synchronous digital hierarchy (SDH)", January interface for the synchronous digital hierarchy (SDH)", January
 End of changes. 155 change blocks. 
875 lines changed or deleted 654 lines changed or added

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