draft-ietf-mpls-tp-oam-framework-02.txt   draft-ietf-mpls-tp-oam-framework-03.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: April 2010 October 26, 2009 Expires: June 2010 December 3, 2009
MPLS-TP OAM Framework MPLS-TP OAM Framework
draft-ietf-mpls-tp-oam-framework-02.txt draft-ietf-mpls-tp-oam-framework-03.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance 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.
skipping to change at page 2, line 19 skipping to change at page 2, line 19
specified in the MPLS Traffic Engineering (MPLS-TE), pseudowire (PW) specified in the MPLS Traffic Engineering (MPLS-TE), pseudowire (PW)
and multi-segment PW (MS-PW) architectures complemented with and multi-segment PW (MS-PW) architectures complemented with
additional Operations, Administration and Maintenance (OAM) additional Operations, Administration and Maintenance (OAM)
procedures for fault, performance and protection-switching management procedures for fault, performance and protection-switching management
for packet transport applications that do not rely on the presence of for packet transport applications that do not rely on the presence of
a control plane. a control plane.
This document describes a framework to support a comprehensive set of This document describes a framework to support a comprehensive set of
OAM procedures that fulfills the MPLS-TP OAM requirements [12]. 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.....................................................3 1. Introduction..................................................5
1.1. Contributing Authors........................................4 1.1. Contributing Authors.....................................5
2. Conventions used in this document................................4 1.2. Editors Issues...........................................6
2.1. Terminology.................................................4 2. Conventions used in this document.............................8
2.2. Definitions.................................................5 2.1. Terminology..............................................8
3. Functional Components............................................8 2.2. Definitions..............................................9
3.1. Maintenance Entity (ME) and Maintenance Entity Group (MEG)..9 3. Functional Components........................................11
3.2. MEG End Points (MEPs)......................................12 3.1. Maintenance Entity and Maintenance Entity Group.........12
3.3. MEG Intermediate Points (MIPs).............................14 3.2. MEG End Points (MEPs)...................................15
3.4. Server MEPs................................................15 3.3. MEG Intermediate Points (MIPs)..........................18
3.5. Tandem Connection..........................................15 3.4. Server MEPs.............................................19
4. Reference Model.................................................16 3.5. Path Segment Tunnels and Tandem Connection Monitoring...20
4.1. MPLS-TP Section Monitoring.................................19 4. Reference Model..............................................20
4.2. MPLS-TP LSP End-to-End Monitoring..........................20 4.1. MPLS-TP Section Monitoring..............................22
4.3. MPLS-TP LSP Tandem Connection Monitoring...................21 4.2. MPLS-TP LSP End-to-End Monitoring.......................23
4.4. MPLS-TP PW Monitoring......................................23 4.3. MPLS-TP LSP Path Segment Tunnel Monitoring..............24
4.5. MPLS-TP MS-PW Tandem Connection Monitoring.................23 4.4. MPLS-TP PW Monitoring...................................26
5. OAM Functions for proactive monitoring..........................24 4.5. MPLS-TP MS-PW Path Segment Tunnel Monitoring............26
5.1. Continuity Check and Connectivity Verification.............25 5. OAM Functions for proactive monitoring.......................27
5.1.1. Defects identified by CC-V............................26 5.1. Continuity Check and Connectivity Verification..........28
5.1.2. Consequent action.....................................28 5.1.1. Defects identified by CC-V.........................29
5.1.3. Configuration considerations..........................29 5.1.2. Consequent action..................................30
5.1.4. Applications for proactive CC-V.......................29 5.1.3. Configuration considerations.......................31
5.2. Remote Defect Indication...................................30 5.1.4. Applications for proactive CC-V....................32
5.2.1. Configuration considerations..........................31 5.2. Remote Defect Indication................................33
5.2.2. Applications for Remote Defect Indication.............31 5.2.1. Configuration considerations.......................33
5.3. Alarm Reporting............................................31 5.2.2. Applications for Remote Defect Indication..........34
5.4. Lock Reporting.............................................33 5.3. Alarm Reporting.........................................34
5.5. Packet Loss Monitoring.....................................33 5.4. Lock Reporting..........................................35
5.5.1. Configuration considerations..........................33 5.5. Packet Loss Monitoring..................................35
5.5.2. Applications for Packet Loss Monitoring...............33 5.5.1. Configuration considerations.......................36
5.5.2. Applications for Packet Loss Monitoring............36
5.6. Client Signal Failure Indication........................37
5.6.1. Configuration considerations.......................37
5.6.2. Applications for Client Signal Failure Indication..37
5.7. Delay Measurement.......................................38
5.7.1. Configuration considerations.......................38
5.7.2. Applications for Delay Measurement.................39
6. OAM Functions for on-demand monitoring.......................39
6.1. Connectivity Verification...............................39
6.1.1. Configuration considerations.......................40
6.2. Packet Loss Monitoring..................................41
6.2.1. Configuration considerations.......................41
6.2.2. Applications for On-demand Packet Loss Monitoring..41
6.3. Diagnostic..............................................41
6.4. Route Tracing...........................................42
6.5. Delay Measurement.......................................43
6.5.1. Configuration considerations.......................43
6.5.2. Applications for Delay Measurement.................44
6.6. Lock Instruct...........................................44
7. Security Considerations......................................44
8. IANA Considerations..........................................44
9. Acknowledgments..............................................45
10. References..................................................46
10.1. Normative References...................................46
10.2. Informative References.................................46
5.6. Client Signal Failure Indication...........................34 Editors' Note:
5.6.1. Configuration considerations..........................34
5.6.2. Applications for Client Signal Failure Indication.....34 This Informational Internet-Draft is aimed at achieving IETF
5.7. Delay Measurement..........................................35 Consensus before publication as an RFC and will be subject to an IETF
5.7.1. Configuration considerations..........................35 Last Call.
5.7.2. Applications for Delay Measurement....................36
6. OAM Functions for on-demand monitoring..........................36 [RFC Editor, please remove this note before publication as an RFC and
6.1. Connectivity Verification..................................36 insert the correct Streams Boilerplate to indicate that the published
6.1.1. Configuration considerations..........................38 RFC has IETF Consensus.]
6.2. Packet Loss Monitoring.....................................38
6.2.1. Configuration considerations..........................38
6.2.2. Applications for On-demand Packet Loss Monitoring.....39
6.3. Diagnostic.................................................39
6.4. Route Tracing..............................................39
6.5. Delay Measurement..........................................40
6.5.1. Configuration considerations..........................40
6.5.2. Applications for Delay Measurement....................41
6.6. Lock Instruct..............................................41
7. Security Considerations.........................................41
8. IANA Considerations.............................................41
9. Acknowledgments.................................................41
10. References.....................................................43
10.1. Normative References......................................43
10.2. Informative References....................................43
1. Introduction 1. Introduction
As noted in [8], MPLS-TP defines a profile of the MPLS-TE and (MS-)PW As noted in [8], MPLS-TP defines a profile of the MPLS-TE and (MS-)PW
architectures defined in RFC 3031 [2], RFC 3985 [5] and [7] which is architectures defined in RFC 3031 [2], RFC 3985 [5] and [7] which is
complemented with additional OAM mechanisms and procedures for alarm, complemented with additional OAM mechanisms and procedures for alarm,
fault, performance and protection-switching management for packet fault, performance and protection-switching management for packet
transport applications. transport applications.
[Editor's note - The draft needs to be reviewed to ensure support of
OAM for p2mp transport paths]
In line with [13], existing MPLS OAM mechanisms will be used wherever In line with [13], existing MPLS OAM mechanisms will be used wherever
possible and extensions or new OAM mechanisms will be defined only possible and extensions or new OAM mechanisms will be defined only
where existing mechanisms are not sufficient to meet the where existing mechanisms are not sufficient to meet the
requirements. requirements.
The MPLS-TP OAM framework defined in this document provides a The MPLS-TP OAM framework defined in this document provides a
comprehensive set of OAM procedures that satisfy the MPLS-TP OAM comprehensive set of OAM procedures that satisfy the MPLS-TP OAM
requirements [12]. In this regard, it defines similar OAM requirements [12]. In this regard, it defines similar OAM
functionality as for existing SONET/SDH and OTN OAM mechanisms (e.g. functionality as for existing SONET/SDH and OTN OAM mechanisms (e.g.
[16]). [16]).
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
unidirectional p2p and p2mp transport paths.
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.
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.
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.
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.
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.
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.
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
DBN Domain Border Node DBN Domain Border Node
FDI Forward Defect Indication FDI Forward Defect Indication
LER Label Edge Router LER Label Edge Router
LME LSP Maintenance Entity LME LSP Maintenance Entity
LSP Label Switched Path LSP Label Switched Path
skipping to change at page 4, line 34 skipping to change at page 9, line 16
FDI Forward Defect Indication FDI Forward Defect Indication
LER Label Edge Router LER Label Edge Router
LME LSP Maintenance Entity LME LSP Maintenance Entity
LSP Label Switched Path LSP Label Switched Path
LSR Label Switch Router LSR Label Switch Router
LTCME LSP Tandem Connection Maintenance Entity LPSTME LSP packet segment tunnel ME
[Editor's note - Difference or similarity between tandem connection
monitoring (TCM)_and Path Segment Tunnel (PST) need to be defined and
agreed]
ME Maintenance Entity ME Maintenance Entity
MEG Maintenance Entity Group MEG Maintenance Entity Group
MEP Maintenance Entity Group End Point MEP Maintenance Entity Group End Point
MIP Maintenance Entity Group Intermediate Point MIP Maintenance Entity Group Intermediate Point
PHB Per-hop Behavior PHB Per-hop Behavior
PME PW Maintenance Entity PME PW Maintenance Entity
PTCME PW Tandem Connection Maintenance Entity
PPSTME PW path segment tunnel ME
PST Path Segment Tunnel
PSN Packet Switched Network PSN Packet Switched Network
PW Pseudowire PW Pseudowire
SLA Service Level Agreement SLA Service Level Agreement
SME Section Maintenance Entity SME Section Maintenance Entity
2.2. Definitions 2.2. Definitions
skipping to change at page 6, line 19 skipping to change at page 10, line 48
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 Message: One or more OAM information elements that when OAM Message: One or more OAM information elements that when exchanged
exchanged between MEPs or between MEPs and MIPs performs some OAM between MEPs or between MEPs and MIPs performs some OAM functionality
functionality (e.g. continuity check or 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
capability associated with a transport path has failed, e.g. loss of capability associated with a transport path has failed, e.g. loss of
continuity. continuity.
Tandem Connection: A tandem connection is an arbitrary part of a Tandem Connection: A tandem connection is an arbitrary part of a
transport path that can be monitored (via OAM) independently from the transport path that can be monitored (via OAM) independent of the
end-to-end monitoring (OAM). The tandem connection may also include end-to-end monitoring (OAM). The tandem connection may also include
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.
The following terms are defined in RFC 5654 [11] as follows: This document uses the terms defined in RFC 5654 [11].
Associated bidirectional path: A path that supports traffic flow in
both directions but that is constructed from a pair of unidirectional
paths (one for each direction) that are associated with one another
at the path's ingress/egress points. The forward and backward
directions are setup, monitored, and protected independently. As a
consequence, they may or may not follow the same route (links and
nodes) across the network.
Concatenated Segment: A serial-compound link connection as defined in
G.805 [17]. A concatenated segment is a contiguous part of an LSP or
multi-segment PW that comprises a set of segments and their
interconnecting nodes in sequence. See also "Segment".
Co-routed bidirectional path: A path where the forward and backward
directions follow the same route (links and nodes) across the
network. Both directions are setup, monitored and protected as a
single entity. A transport network path is typically co-routed.
Layer network: Layer network is defined in G.805 [17]. A layer
network provides for the transfer of client information and
independent operation of the client OAM. A layer network may be
described in a service context as follows: one layer network may
provide a (transport) service to higher client layer network and may,
in turn, be a client to a lower-layer network. A layer network is a
logical construction somewhat independent of arrangement or
composition of physical network elements. A particular physical
network element may topologically belong to more than one layer
network, depending on the actions it takes on the encapsulation
associated with the logical layers (e.g., the label stack), and thus
could be modeled as multiple logical elements. A layer network may
consist of one or more sublayers. Section 1.4 (of RFC 5654) provides
a more detailed overview of what constitutes a layer network. For
additional explanation of how layer networks relate to the OSI
concept of layering, see Appendix I of Y.2611 [19].
Section Layer Network: A section layer is a server layer (which may
be MPLS-TP or a different technology) that provides for the transfer
of the section-layer client information between adjacent nodes in the
transport-path layer or transport service layer. A section layer may
provide for aggregation of multiple MPLS-TP clients. Note that G.805
[17] defines the section layer as one of the two layer networks in a
transmission-media layer network. The other layer network is the
physical-media layer network.
Path: See Transport Path
Segment: A link connection as defined in G.805 [17]. A segment is the
part of an LSP that traverses a single link or the part of a PW that
traverses a single link (i.e., that connects a pair of adjacent
{Switching|Terminating} Provider Edges). See also "Concatenated
Segment". [editors: concept should be layer specific.. suggesting
that the part of a PW that traverses a single physical link is a
segment means a segment is pretty much bounded by duct ends, and by
devices completely clueless as to the existence of the PW, visibility
of the wrong layer, To group: we have a definition conflict between
G.805 and usage of segment in IETF (e.g. PWE3), not sure how to
resolve this, for discussion Nov 3]
Sublayer: Sublayer is defined in G.805 [17]. The distinction between
a layer network and a sublayer is that a sublayer is not directly
accessible to clients outside of its encapsulating layer network and
offers no direct transport service for a higher layer (client)
network. [editors: messy definition as it is context specific. Given
MPLS has no PID, the transport path will always exist in a sublayer
as the PW or PID label which has no forwarding context will be bottom
of stack. Whether or not you actually think of the PW label as being
a sublayer itself entirely dependant on usage SS or MS-PW, for
discussion Nov 3rd]
Transport Path: A network connection as defined in G.805 [17]. In an
MPLS-TP environment, a transport path corresponds to an LSP or a PW.
Transport Path Layer: A (sub)layer network that provides
point-to-point or point-to-multipoint transport paths. It is
instrumented with OAM mechanisms that are independent of the clients
it is transporting. [editor: if you look at the sublayer discussion
above, this term pretty much universally must be a transport path
sub-layer. The transport path cannot be a layer to itself in the
MPLS_TP architecture unless we are discussing multi-segment dry
martini, for discussion Nov 3rd]
Unidirectional path: A path that supports traffic flow in only one
direction.
The term 'Per-hop Behavior' is defined in [14] as follows:
Per-hop Behavior: a description of the externally observable This document uses the term 'Per-hop Behavior' as defined in [14].
forwarding treatment applied at a differentiated services-compliant
node to a behavior aggregate.
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 designed 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. In order to verify and maintain these performance
and quality guarantees, there is a need to not only apply OAM and quality guarantees, there is a need to not only apply OAM
functionality on a transport path granularity (e.g. LSP or MS-PW), functionality on a transport path granularity (e.g. LSP or MS-PW),
but also on arbitrary parts of transport paths, defined as Tandem but also on arbitrary parts of transport paths, defined as Tandem
Connections, between any two arbitrary points along a path. 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. [Note -
discussion in Munich -tues concluded that TCM not possible with PWs - discussion in Munich -tues concluded that TCM not possible with PWs -
can monitor a single PW segment - but attempting to monitor more than can monitor a single PW segment - but attempting to monitor more than
one segment converts the PW into an LSP and therefore the intervening 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 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 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 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, for MS-PW, else I have to control plane peer at two layers, pending
discussion Nov 3rd] resolution of discussion item 4 in section 1.2]
When a control plane is not present, the management plane configures When a control plane is not present, the management plane configures
these functional components. Otherwise they can be configured either these functional components. Otherwise they can be configured either
by the management plane or by the control plane. by the management plane or by the control plane.
These functional components should be instantiated when the path is These functional components should be instantiated when the path is
created by either the management plane or by the control plane (if created by either the management plane or by the control plane (if
present). Some components may be instantiated after the path is present). Some components may be instantiated after the path is
initially created (e.g. TCM). initially created (e.g. PST).
3.1. Maintenance Entity (ME) and Maintenance Entity Group (MEG) [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?]
[editors: rather than fight chicken and egg, we made two sections 3.1. Maintenance Entity and Maintenance Entity Group
into one]
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
[editors: why has this restriction been added, for discussion Nov 3rd] transport path or a root and a leaf of a point to multipoint
transport path to which maintenance and monitoring operations transport path to which maintenance and monitoring operations apply.
apply. These two points are called Maintenance Entity Group End These two points are called Maintenance Entity Group (MEG) End Points
Points (MEPs). In between these two points zero or more intermediate (MEPs). In between these two points zero or more intermediate points,
points, called Maintenance Entity Group MEG Intermediate Points called Maintenance Entity Group Intermediate Points (MIPs), MAY exist
(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 The MEPs that form an MEG are configured and managed to limit the
scope of an OAM flow within the MEG the MEPs belong to (i.e. within scope of an OAM flow within the MEG that the MEPs belong to (i.e.
the domain of the transport path or segment, in the specific layer within the domain of the transport path or segment, in the specific
network, that is being monitored and managed). A misbranching fault sub-layer of the MPLS layer network, that is being monitored and
may cause OAM packets to be delivered to a MEP that is not in the MEG managed). A misbranching fault may cause OAM packets to be delivered
of origin. 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, sub-layer LSPs or connecting adjacent nodes can be physical links, or sub-layer
lower layer TCMs. LSPs/PSTs.
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 layer network under its
responsibility and to localize problems efficiently. responsibility and to localize problems efficiently.
[Dave: given how these definitions are shaking out, should the MEG [Editor's note - MEG are sub-layers. Need to check the document for
and ME not be confined to a sub-layer, there is no such thing as a consistency with this agreement]
completely self contained "layer" in the architecture to which a MEG
can apply, for Nov 3rd]
An MPLS-TP maintenance entity group can cover either the whole end- An MPLS-TP maintenance entity group can cover either the whole end-
to-end or a Tandem Connection of the transport path. A Maintenance to-end path or a path segment tunnel supporting some portion of the
Entity Group may be defined to monitor the transport path for fault transport path. A Maintenance Entity Group may be defined to monitor
and/or performance management. the transport path for fault and/or performance management.
In case of associated bi-directional paths, two independent In case of associated bi-directional paths, two independent
Maintenance Entities are defined to independently monitor each Maintenance Entities are defined to independently monitor each
direction. This has implications for transactions that terminate at 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 or query a MIP as a return path from MIP to source MEP does not exist
in a unidirectional ME. in a unidirectional ME.
The following properties apply to all MPLS-TP MEs: The following properties apply to all MPLS-TP MEGs:
o They can be nested but not overlapped, e.g. an ME may cover a o They can be nested but not overlapped, e.g. an MEG may cover a
segment or a concatenated segment of another ME, and may also 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 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 the segment or concatenated segment, but all its MEPs and MIPs are
no longer part of the encompassing ME. It is possible that MEPs of no longer part of the encompassing MEG. It is possible that MEPs
nested MEs reside on a single node. of nested MEGs reside on a single node.
o Each OAM flow is associated with a single Maintenance Entity.
o OAM packets 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.
[Propose from Munich - rewrite to describe the MEG as collection of o Each OAM flow is associated with a single Maintenance Entity
one or more maint entities and then immediately define an ME. Group.
[editors: much of this comment is actually either ME or MEP/MIP o OAM packets that instrument a particular direction of an LSP are
specific, not MEG specific, hence we are struggling as to what to do subject to the same forwarding treatment (i.e. fate share) as the
with this, for discussion Nov 3rd] 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.
A key point in the definition of an ME is the end-points are defined [Editor's note: A key point in the definition of an ME is the end-
by location of the logical function MEP points are defined by location of the logical function MEP
Later in the framework we will discuss the precision with which we 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 can identify the location of a MEP/MIP i.e, ingress i/f, egress i/f
or node. or node.
We need to distinguish between the point of interception of an OAM We need to distinguish between the point of interception of an OAM
msg and the point where the action takes place. msg and the point where the action takes place.
Somewhere we need to distinguish between the OAM control function and Action: look at the text in the framework document regarding the
the OAM measurement function. i.e. we set up a loop back (a control location of the functional components (MEPs and MIPs).]
function, in which case the OAM message may be intercepted and
actioned anywhere convenient), and the measurement function (i.e. [Editors' note: Somewhere we need to distinguish between the OAM
looping the packet to determine that it reached a particular part of control function and the OAM measurement function. i.e. we set up a
the network) which needs to be actioned at a precisely know and loop back (a control function, in which case the OAM message may be
stipulated point in the network/equipment. 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 Note that not all functionality / processing of an OAM pkt needs to
take place at the point of measurement. 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 We considered that an OAM function can be decomposed into the
following components following components
- Instruction or command - Instruction or command
- Execution - Execution
- Addressing (node, interface etc) is ttl/LSP enough - do we need - Addressing (node, interface etc) is ttl/LSP enough - do we need
sub-addressing to cause execution on a specific component in the sub-addressing to cause execution on a specific component in the
node - i.e. egress interface node - i.e. egress interface
- Response via OAM - Response via OAM
- Reporting to mgt interface - Reporting to mgt interface]
[Editor's note: the MPLS-TP framework will describe how it is
possible to inject OAM packets on intermediate nodes. We need to
describe how this capability is used within the OAM framework and to
reference to the MPLS-TP framework for the description of this
capability]
It is useful to further decompose this into an initiator and a
responder in general an initiator is the source mep and the responder
is a mip or a sink mep. There are exceptions to this such as a mip
initiating an AIS msg or lock indication.]
Another OAM construct is referred to as Maintenance Entity Group, Another OAM construct is referred to as Maintenance Entity Group,
which is a collection of one or more MEs that belongs to the same 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. transport path and that are maintained and monitored as a group.
A use case for an MEG with more than one ME is point-to-multipoint A use case for an MEG with more than one ME is point-to-multipoint
OAM. 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|
/ +-+ / +-+
skipping to change at page 12, line 27 skipping to change at page 15, line 21
|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 - depending from where the failure is located o Fault conditions - some faults may impact more than one ME
depending from where the failure is located
o Packet loss - depending from where the packets are lost o Packet loss - packet dropping may impact more than one ME
depending from where the packets are lost
o Packet delay - depending on different paths o Packet delay - depending on different paths
Each leaf (i.e. D, E and F) terminates OAM messages to monitor its Each leaf (i.e. D, E and F) terminates OAM flows to monitor the ME
own [Root, Leaf] ME while the root (i.e. A) generates OAM messages to from itself and the root while the root (i.e. A) generates OAM
monitor all the MEs of the p2mp MEG. In this particular case, the messages common to all the MEs of the p2mp MEG. Nodes B and C MAY
p2mp transport path is monitored by a MEG that consists of three MEs. implement a MIP in the corresponding MEG.
Nodes B and C might implement a MIP in the corresponding MEGs.
3.2. MEG End Points (MEPs) 3.2. MEG End Points (MEPs)
MEG End Points (MEPs) are the end points of an MEG. In the context of MEG End Points (MEPs) are the source and sink points of an MEG. In
an MPLS-TP LSP, only LERs can implement MEPs while in the context of the context of an MPLS-TP LSP, only LERs can implement MEPs while in
an LSP Tandem Connection both LERs and LSRs can implement MEPs. the context of a path segment tunnel (PST) both LERs and LSRs can
Regarding MPLS-TP PW, only T-PEs can implement MEPs while for a PW implement MEPs that contribute to the overall monitoring
Tandem Connection both T-PEs and S-PEs can implement MEPs. In the infrastructure for the transport path. Regarding MPLS-TP PW, only T-
context of MPLS-TP Section, any MPLS-TP NE can implement MEPs. 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
MPLS-TP NE can implement a MEP.
[Munich: See note about PW Tandem monitoring earlier, and whether a [Munich: See note about PW Tandem monitoring earlier, and whether a
PW can be a tandem connection] 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 initiating 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 MPLS label identifies the MEG the OAM packet MEG it belongs to. The MEG the OAM packet belongs to is inferred from
belongs to. the MPLS or PW label.[Editors: given the discussion about alternative
return paths, is a GAL/GaCH always present ...?. For discussion on
the IETF review calls]
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 support a MEP. at the edge of an MEG always supports a MEP.
MEPs have to prevent OAM packets corresponding to a MEG from leaking
outside that MEG:
o A MEP sink terminates all the OAM packets that it receives
corresponding to its MEG and does not forward them further along
the path.
o A MEP in a tandem connection tunnels all the OAM packets that it
receives, upstream from the associated MEG to prevent them from
being processed within the associated MEG. The usage of the label
stacking mechanism allows all the MEPs and MIPs within the MEG to
distinguish tunneled OAM packets from OAM packets that belong to
that MEG.
MPLS-TP MEP passes a fault indication to its client (sub-)layer MEPs terminate all OAM packets received from the associated transport
network as a consequent action of fault detection. [ editor: path or path segment tunnel [Editors: the PST definition in the
interesting case, is this always sink, or are we considering framework should be augmented to clarity that the clients of a PST
loopbacks where inserting fault indication into the client (s)layer should always be LSPs or PWs]. As the MEP corresponds to the
is comparatively useless. We wrestled with same problem with RSVP termination of the forwarding path for an MEG at the given sub-level,
errors in the past ..., for Nov 3rd] 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.
A MEP of an MPLS-TP tandem connection is not necessarily coincident The MEPs of a path segment tunnel are not necessarily coincident with
with the termination of the MPLS-TP transport path (LSP or PW) and the termination of the MPLS-TP transport path (LSP or PW) and monitor
monitors the transport path for failures or performance degradation some portion of the transport path for failures or performance
(e.g. based on packet counts) within the boundary of the MEG for the degradation (e.g. based on packet counts) only within the boundary of
tandem connection. the MEG for the path segment tunnel.
It may occur in TCM that two MEPs are set on both sides of the An MPLS-TP MEP sink passes a fault indication to its client
forwarding engine such that the MEG is entirely internal to the node. (sub-)layer network as a consequent action of fault detection.
Note that a MEP can only exist at the beginning and end of a sub- It may occur that the MEPs of a path segment tunnel are set on both
layer i.e. an LSP or PW. If we need to add a monitoring point within sides of the forwarding engine such that the MEG is entirely internal
an LSP we create a new sub-layer. We need to describe the migration to the node.
process for adding a TCM segment.
Note that a MEP can only exist at the beginning and end of a
sub-layer i.e. an LSP or PW. If we need to monitor some portion of
that LSP or PW [editor: mention of PW in this context needs to be
revised after agreement on discussion point 4 in section 1.2], a new
sub-layer in the form of a path segment tunnel MUST be created which
permits MEPs and an associated MEG to be created.
[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 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. the LSP label - i.e. the top label of the stack at that point.
[editors: clarify in section 3.4] [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 17 November):
o bidirectional co-routed: MUST support and SHOULD use the
reverse path. It MAY use any other available return path if
requested by the OAM message triggering the reply. Clarify
that using the reverse path checks both forward and backward
directions while other return paths check only the forward
direction.
o unidirectional p2p and p2mp: no ability to support triggered
response OAM message unless other return paths are available
o associated bidirectional: MEPs like co-routed; MIPs like
unidirectional
Agreement (call 17 November) to use as a working assumption the same
MEP/MIP model in MS-PW OAM architecture. In order to validate this
working assumption we need to understand how to describe the PW
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.3. MEG Intermediate Points (MIPs)
A MEG Intermediate Point (MIP) is a point between the two MEPs of an A MEG Intermediate Point (MIP) is a point between the MEPs of an MEG.
ME.
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 - editors:
this text was removed in the commented .rtf document from Munich but this text was removed in the commented .rtf document from Munich but
not tracked as a revision, validate this change Nov 3rd] packets, but not tracked as a revision, validate this change after MIP/MEP
may be addressed by OAM packets initiated by one of the MEPs of the discussion (discussion point 5 in section 1.2)] packets, but may be
ME. A MIP can generate OAM packets only in response to OAM packets addressed by OAM packets initiated by one of the MEPs of the MEG. A
that are sent on the MEG it belongs to. MIP can generate OAM packets only in response to OAM packets that are
sent on the MEG it belongs to.
An intermediate node within an MEG can either: An intermediate node within a point-to-point MEG can either:
o not support MPLS-TP OAM (i.e. no MIPs per node) o not support MPLS-TP OAM (i.e. no MIPs per node)
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 MIPs per node on both sides of
the forwarding engine) the forwarding engine)
A node at the edge of an MEG can also support a MEP and a per- [Editor's note - Need to describe MIPs for p2mp MEGs]
interface MIP at the two sides of the forwarding engine.
[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" model of where the MIP resides. It is always assumed that the "pipe"/"short
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 belongs to is inferred from within the node. The MEG the OAM packet is associated with is
the MPLS label. inferred from the MPLS label.
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. on the nodes within the MEG. [Editors': review this paragraph after
discussion point 6 in section 1.2 is resolved]
3.4. Server MEPs 3.4. Server MEPs
A server MEP is a MEP of an ME that is either: A server MEP is a MEP of an MEG that is either:
o defined in a layer network below the MPLS-TP layer network being o defined in a layer network that is "below", which is to say
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 below o defined in a sub-layer of the MPLS-TP layer network that is
the sub-layer being referenced. "below" which is to say encapsulates and transports the sub-layer
being referenced.
A server MEP can coincide with a MIP or a MEP in the client (MPLS-TP) A server MEP can coincide with a MIP or a MEP in the client (MPLS-TP)
layer network. 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) layer network and the server function between the client (MPLS-TP) (sub-)layer network and the
layer network. The adaptation function maintaints state on the server (sub-)layer network. The adaptation function maintains state
mapping of MPLS-TP transport paths that are setup over that server on the mapping of MPLS-TP transport paths that are setup over that
layer's transport path. server 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
OTH 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 LSP Tandem Connection MEP for higher-level LTCMEs, o An MPLS-TP PST MEP for higher-level PSTs, defined in section 4.3;
defined in section 4.3;
o An MPLS-TP PW Tandem Connection MEP for higher-level PTCMEs, o An MPLS-TP PW Tandem Connection MEP for higher-level PTCMEs,
defined in section 4.5. defined in section 4.5. [Editor: update this bullet after the
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 notifies 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. Tandem Connection 3.5. Path Segment Tunnels and Tandem Connection Monitoring
A tandem connection is instantiated to support tandem connection Path segment tunnels (PSTs) are instantiated to provide monitoring of
monitoring (TCM). a portion of a set of co-routed transport paths. 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 TCM for a given portion of a transport path is implemented by first
creating a hierarchical LSP that that has a 1:1 association with creating a path segment tunnel that that has a 1:1 association with
portion of the transport path that is to be uniquely monitored such portion of the transport path that is to be uniquely monitored. This
that there is direct correlation between all FM and PM information means there is direct correlation between all FM and PM information
gathered for the tandem connection AND the monitored portion of the gathered for the PST AND the monitored portion of the E2E path. The
E2E path. The tandem connection is monitored using normal LSP PST is monitored using normal LSP monitoring.
monitoring. There are a number of implications to this approach:
1) The hierarchical LSP would use the uniform model of EXP code
point copying between sub-layers for diffserv such that the E2E
markings and PHB treatment was preserved in the tandem
connection.
2) The hierarchical LSP would use the pipe model for TTL handling There are a number of implications to this approach:
such that MIP addressing for the E2E entity would be distinct
from the tandem connection.
3) PM statistics need to be adjusted for the overhead of the 1) The PST would use the uniform model of EXP code point copying
additional sub-layer. between sub-layers for diffserv such that the E2E markings and
PHB treatment for the transport path was preserved by the PST.
4) The server sub-layer LSP is viewed as single hop by the client 2) The PST would use the pipe model for TTL handling such that MIP
LSP. The E2E ME source MEPs cannot direct transactions to tandem addressing for the E2E entity would be not be impacted by the
connection MIPs. presence of the PST.
[editors: the text from Munich suggested that a tandem connection 3) PM statistics need to be adjusted for the encapsulation overhead
could be N:1, we've stuck with 1:1 such that there would be direct of the additional PST sub-layer.
correlation of PM stats between the tandem connection and the
monitored portion of the transport path, a N:1 hierarchical LSP IF WE
INSIST on including, should be documented as a separate procedure]
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 MEs are specified in this document: The following MPLS-TP MEGs are specified in this document:
o A Section Maintenance Entity (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 (LME), allowing monitoring and management o A LSP Maintenance Entity Group (LME), allowing monitoring and
of an end-to-end LSP (between LERs). management of an end-to-end LSP (between LERs).
o A PW Maintenance Entity (PME), allowing monitoring and management o A PW Maintenance Entity Group (PME), allowing monitoring and
of an end-to-end SS/MS-PWs (between T-PEs). management of an end-to-end SS/MS-PWs (between T-PEs).
o An LSP Tandem Connection Maintenance Entity (LTCME), allowing o A PST Maintenance Entity Group (PSTME), allowing monitoring and
monitoring and management of an LSP Tandem Connection between any management of a path segment tunnel (between any LERs/LSRs along
LER/LSR along the LSP. [Munich: Please clarify that an LTCME is an LSP).
JUST an ordinary hierarchical LSP (RFC3031).
Note - TCM only makes sense for LSPs as previously noted.]The MEs o A MS-PW Tandem Connection Maintenance Entity (PTCME), allowing
specified in this MPLS-TP framework are compliant with the monitoring and management of a PW Tandem Connection (between any
architecture framework for MPLS MS-PWs [7] and MPLS LSPs [2]. T-PEs/S-PEs along the (MS-)PW) [Editors': update this bullet after
resolution of PW TCM discussion (discussion point 4 in section
1.2]
Hierarchical LSPs are also supported. In this case, each LSP Tunnel The MEGs specified in this MPLS-TP framework are compliant with the
in the hierarchy is a different sub-layer network that can be architecture framework for MPLS-TP MS-PWs [7] and LSPs [2].
monitored independently from higher and lower level LSP tunnels in
the hierarchy, end-to-end (from LER to LER) by an LME. Tandem
Connection monitoring via LTCME are applicable on each LSP Tunnel in
the hierarchy.
[Munich: There was discussion on above para - and it was suggested Hierarchical LSPs are also supported in the form of path segment
that it be removed.] [ for discussion Nov 3rd, TCM and hierarchical tunnels. In this case, each LSP Tunnel in the hierarchy is a
LSPs...] different sub-layer network that can be monitored, independently from
Native |<------------------- MS-PW1Z ------------------->| Native higher and lower level LSP tunnels in the hierarchy, on an end-to-end
Layer | | Layer basis (from LER to LER) by a PSTME. It is possible to monitor a
Service | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | Service portion of a hierarchical LSP by instantiating a hierarchical PSTME
(AC1) V V LSP V V LSP V V LSP V V (AC2) between any LERs/LSRs along the hierarchical LSP.
+----+ +-+ +----+ +----+ +-+ +----+
+----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+
| | | |=========| |=========| |=========| | | |
| CE1|--------|........PW13.......|...PW3X..|........PWXZ.......|-------|CE2 |
| | | |=========| |=========| |=========| | | |
+----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+
+----+ +-+ +----+ +----+ +-+ +----+
. . . .
| | | |
|<---- Domain 1 --->| |<---- Domain Z --->|
^------------------- PW1Z PME -------------------^
^---- PW13 PTCME ---^ ^---- PWXZ PTCME ---^
^---------^ ^---------^
PSN13 LME PSNXZ LME
^---^ ^---^ ^---------^ ^---^ ^---^ Native |<------------------- MS-PW1Z ------------------->| Native
Sec12 Sec23 Sec3X SecXY SecYZ Layer | | Layer
SME SME SME SME SME Service | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | Service
(AC1) V V LSP V V LSP V V LSP V V (AC2)
+----+ +-+ +----+ +----+ +-+ +----+
+----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+
| | | |=========| |=========| |=========| | | |
| CE1|---|........PW13.......|...PW3X..|........PWXZ.......|---|CE2 |
| | | |=========| |=========| |=========| | | |
+----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+
+----+ +-+ +----+ +----+ +-+ +----+
. . . .
| | | |
|<---- Domain 1 --->| |<---- Domain Z --->|
^------------------- PW1Z PME -------------------^
^---- PW13 PPSTME---^ ^---- PWXZ PPSTME---^
^---------^ ^---------^
PSN13 LME PSNXZ LME
TPE1: Terminating Provider Edge 1 SPE2: Switching Provider Edge 3 ^---^ ^---^ ^---------^ ^---^ ^---^
TPEX: Terminating Provider Edge X SPEZ: Switching Provider Edge Z Sec12 Sec23 Sec3X SecXY SecYZ
SME SME SME SME SME
^---^ ME ^ MEP ==== LSP .... PW TPE1: Terminating Provider Edge 1 SPE2: Switching Provider Edge 3
TPEX: Terminating Provider Edge X SPEZ: Switching Provider Edge Z
^---^ ME ^ MEP ==== LSP .... PW
Figure 3 Reference Model for the MPLS-TP OAM Framework Figure 3 Reference Model for the MPLS-TP OAM Framework
Figure 3 depicts a high-level reference model for the MPLS-TP OAM Figure 3 depicts a high-level reference model for the MPLS-TP OAM
framework. The figure depicts portions of two MPLS-TP enabled network framework. The figure depicts portions of two MPLS-TP enabled network
domains, Domain 1 and Domain Z. In Domain 1, LSR1 is adjacent to LSR2 domains, Domain 1 and Domain Z. In Domain 1, LSR1 is adjacent to LSR2
via the MPLS Section Sec12 and LSR2 is adjacent to LSR3 via the MPLS via the MPLS Section Sec12 and LSR2 is adjacent to LSR3 via the MPLS
Section Sec23. Similarly, in Domain Z, LSRX is adjacent to LSRY via Section Sec23. Similarly, in Domain Z, LSRX is adjacent to LSRY via
the MPLS Section SecXY and LSRY is adjacent to LSRZ via the MPLS the MPLS Section SecXY and LSRY is adjacent to LSRZ via the MPLS
Section SecYZ. In addition, LSR3 is adjacent to LSRX via the MPLS Section SecYZ. In addition, LSR3 is adjacent to LSRX via the MPLS
skipping to change at page 19, line 9 skipping to change at page 22, line 25
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 of a given transport
path are expected to operate independently from procedures on other path are expected to operate independently from procedures on other
MEGs of the same transport path and certainly MEGs of other transport MEGs of the same transport path and certainly MEGs of other transport
paths. Yet, this does not preclude that multiple MEGs may be affected paths. Yet, this does not preclude that multiple MEGs may be affected
simultaneously by the same network condition, for example, a fibre simultaneously by the same network condition, for example, a fiber
cut event. 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 PTCME because typically TCMs are Figure 3 does not describe a PW3X PPSTME because typically PSTs are
used to monitor an OAM domain (like PW13 and PWXZ PTCMEs) 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 TCM are instantiated as long does not pose any constraints on the way PSTs are instantiated as
as they are not overlapping. long as they are not overlapping.
The subsections below define the MEs 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 MEs references to domains, LSRs, MPLS Sections, LSPs, pseudowires and
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
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 ------------------->| |<------------------- MS-PW1Z ------------------->|
| | | |
| |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| |
V V LSP V V LSP V V LSP V V V V LSP V V LSP V V LSP V V
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
+----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+
| | AC1 | |=========| |=========| |=========| | AC2 | | | |AC1| |=========| |=========| |=========| |AC2| |
| CE1|--------|........PW13.......|...PW3X..|.......PWXZ........|-------|CE2 | | CE1|---|........PW13.......|...PW3X..|.......PWXZ........|---|CE2 |
| | | |=========| |=========| |=========| | | | | | | |=========| |=========| |=========| | | |
+----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
^--^ ^--^ ^---------^ ^---^ ^---^
^--^ ^--^ ^--------^ ^--^ ^--^ Sec12 Sec23 Sec3X SecXY SecYZ
Sec12 Sec23 Sec3X SecXY SecYZ SME SME SME SME SME
SME SME SME SME SME
Figure 4 Reference Example of MPLS-TP Section MEs (SME) Figure 4 Reference Example of MPLS-TP Section MEs (SME)
Figure 4 shows 5 Section MEs configured in the path between AC1 and 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 AC2:
LSR 2, 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 1. Sec12 ME associated with the MPLS Section between LSR 1 and LSR 2,
LSR X, 4) SecXY ME associated with the MPLS Section between LSR X and
LSR Y, and 5) SecYZ ME associated with the MPLS Section between LSR Y 2. Sec23 ME associated with the MPLS Section between LSR 2 and LSR 3,
and LSR Z.
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,
and
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
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 ------------------->| |<------------------- MS-PW1Z ------------------->|
| | | |
| |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| |
V V LSP V V LSP V V LSP V V V V LSP V V LSP V V LSP V V
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
+----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+
| | AC1 | |=========| |=========| |=========| | AC2 | | | |AC1| |=========| |=========| |=========| |AC2| |
| CE1|--------|........PW13.......|...PW3X..|........PWXZ.......|-------|CE2 | | CE1|---|........PW13.......|...PW3X..|........PWXZ.......|---|CE2 |
| | | |=========| |=========| |=========| | | | | | | |=========| |=========| |=========| | | |
+----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
^---------^ ^---------^
^---------^ ^---------^ PSN13 LME PSNXZ LME
PSN13 LME PSNXZ LME
Figure 5 Examples of MPLS-TP LSP MEs (LME) Figure 5 Examples of MPLS-TP LSP MEs (LME)
Figure 5 depicts 2 LMEs configured in the path between AC1 and AC2: 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 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 Tandem Connection Monitoring 4.3. MPLS-TP LSP Path Segment Tunnel Monitoring
An MPLS-TP LSP Tandem Connection Monitoring ME (LTCME) 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 LTCME can monitor an LSP segment or concatenated monitoring (LME). An LPSTMEE can monitor an LSP segment or
segment and it may also include the forwarding engine(s) of the concatenated segment and it may also include the forwarding engine(s)
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 LTCMEs MAY be configured on any LSP. The LSRs that terminate
the LTCME may or may not be immediately adjacent at the MPLS-TP
layer. LTCME OAM packets must fate share with the user data packets
sent over the monitored LSP segment.
A LTCME can be defined between the following entities: Multiple LPSTMEs MAY be configured on any LSP. The LSRs that
terminate the LPSTME may or may not be immediately adjacent at the
MPLS-TP layer. LPSTME OAM packets must fate share with the user data
packets sent over the monitored LSP segment.
o LER and any LSR of a given LSP. A LPSTME can be defined between the following entities:
o Any two LSRs of a given LSP. o LER and any LSR of a given LSP.
An LTCME is intended to be deployed in scenarios where it is o Any two LSRs of a given LSP.
preferable to monitor the behaviour of a part of an LSP rather than
the entire LSP itself, for example when there is a need to monitor a
part of an LSP that extends beyond the administrative boundaries of
an MPLS-TP enabled administrative domain.
Note that LTCMEs are equally applicable to hierarchical LSPs. 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
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
administrative boundaries of an MPLS-TP enabled administrative
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| |
| CE1|--------|......................PW1Z.......................|-------|CE2 | | CE1|---|......................PW1Z.......................|---|CE2 |
| | | |=======================================| | | | | | | |=======================================| | | |
+----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
. . . . . . . .
| | | | | | | |
|<---- Domain 1 --->| |<---- Domain Z --->| |<---- Domain 1 --->| |<---- Domain Z --->|
^---------^ ^---------^ ^---------^ ^---------^
PSN13 LTCME PSNXZ LTCME PSN13 LPSTME PSNXZ LPSTME
^---------------------------------------^ ^---------------------------------------^
PSN1Z LME PSN1Z LME
DBN: Domain Border Node DBN: Domain Border Node
Figure 6 MPLS-TP LSP Tandem Connection Monitoring ME (LTCME) Figure 6 MPLS-TP LSP Path Segment Tunnel ME (LPSTME)
Figure 6 depicts a variation of the reference model in Figure 3 where Figure 6 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 LTCMEs
configured to monitor the PSN1Z LSP: 1) a LTCME monitoring the PSN13 configured to monitor the PSN1Z LSP: 1) a LPSTME monitoring the PSN13
LSP Concatenated Segment on Domain 1 (PSN13 LTCME), and 2) a LTCME 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
LTCME). LPSTME).
It is worth noticing that LTCMEs 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 LTCME MEPs and LME MEPs can be coincident the end-to-end LSP and that LPSTME MEPs and LME MEPs can be
in the same node (e.g. PE1 node supports both the PSN1Z LME MEP and coincident in the same node (e.g. PE1 node supports both the PSN1Z
the PSN13 LTCME MEP). LME MEP and the PSN13 LPSTME MEP).
4.4. MPLS-TP PW Monitoring 4.4. MPLS-TP PW Monitoring
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.
|<------------------- MS-PW1Z ------------------->| |<------------------- MS-PW1Z ------------------->|
| | | |
| |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| |
V V LSP V V LSP V V LSP V V V V LSP V V LSP V V LSP V V
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
+----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+
| | AC1 | |=========| |=========| |=========| | AC2 | | | |AC1| |=========| |=========| |=========| |AC2| |
| CE1|--------|........PW13.......|...PW3X..|........PWXZ.......|-------|CE2 | | CE1|---|........PW13.......|...PW3X..|........PWXZ.......|---|CE2 |
| | | |=========| |=========| |=========| | | | | | | |=========| |=========| |=========| | | |
+----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
^---------------------PW1Z PME--------------------^ ^---------------------PW1Z PME--------------------^
Figure 7 MPLS-TP PW ME (PME) Figure 7 MPLS-TP PW ME (PME)
Figure 7 depicts a MS-PW (MS-PW1Z) consisting of three segments: Figure 7 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 Tandem Connection Monitoring 4.5. MPLS-TP MS-PW Path Segment Tunnel Monitoring
An MPLS-TP MS-PW Tandem Connection Monitoring ME (PTCME) is an MPLS- [Editors' note: revise this section after the discussion on PW TCM is
TP maintenance entity intended to monitor an arbitrary part of an MS- closed (discussion item 4 in section 1.2)]
PW between a given pair of PEs independently from the end-to-end
monitoring (PME). A PTCME can monitor a PW segment or concatenated
segment and it may also include the forwarding engine(s) of the
node(s) at the edge(s) of the segment or concatenated segment.
Multiple PTCMEs MAY be configured on any MS-PW. The PEs may or may An MPLS-TP MS-PW Path Segment Tunnel Monitoring ME (PPSTME) is an
not be immediately adjacent at the MS-PW layer. PTCME OAM packets 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-
end monitoring (PME). A PPSTME can monitor a PW segment or
concatenated segment and it may also include the forwarding engine(s)
of the node(s) at the edge(s) of the segment or concatenated segment.
Multiple 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
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 PTCME can be defined between the following entities: A PPSTME can be defined between the following entities:
o T-PE and any S-PE of a given MS-PW o T-PE and any S-PE of a given MS-PW
o Any two S-PEs of a given MS-PW. It can span several PW segments. o Any two S-PEs of a given MS-PW. It can span several PW segments.
A PTCME is intended to be deployed in scenarios where it is A PPSTME is intended to be deployed in scenarios where it is
preferable to monitor the behaviour of a part of a MS-PW rather than preferable to monitor the behaviour of a part of a MS-PW rather than
the entire end-to-end PW itself, for example to monitor an MS-PW the entire end-to-end PW itself, for example to monitor an MS-PW
Segment within a given network domain of an inter-domain MS-PW. Segment within a given network domain of an inter-domain MS-PW.
|<------------------- MS-PW1Z ------------------->| |<------------------- MS-PW1Z ------------------->|
| | | |
| |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| |
V V LSP V V LSP V V LSP V V V V LSP V V LSP V V LSP V V
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
+----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+
| | AC1 | |=========| |=========| |=========| | AC2 | | | |AC1| |=========| |=========| |=========| |AC2| |
| CE1|--------|........PW13.......|...PW3X..|........PWXZ.......|-------|CE2 | | CE1|---|........PW13.......|...PW3X..|........PWXZ.......|---|CE2 |
| | | |=========| |=========| |=========| | | | | | | |=========| |=========| |=========| | | |
+----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
^---- PW1 PTCME ----^ ^---- PW5 PTCME ----^ ^---- PW1 PPSTME----^ ^---- PW5 PPSTME----^
^---------------------PW1Z PME--------------------^ ^---------------------PW1Z PME--------------------^
Figure 8 MPLS-TP MS-PW Tandem Connection Monitoring (PTCME) Figure 8 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 8 depicts the same MS-PW (MS-PW1Z) between AC1 and AC2 as in
Figure 7. In this scenario there are two separate PTCMEs configured Figure 7. In this scenario there are two separate PPSTMEs configured
to monitor MS-PW1Z: 1) a PTCME monitoring the PW13 MS-PW Segment on to monitor MS-PW1Z: 1) a PPSTME monitoring the PW13 MS-PW Segment on
Domain 1 (PW13 PTCME), and 2) a PTCME monitoring the PWXZ MS-PW Domain 1 (PW13 PPSTME), and 2) a PTCME monitoring the PWXZ MS-PW
Segment on Domain Z with (PWXZ PTCME). Segment on Domain Z with (PWXZ PPSTME).
It is worth noticing that PTCMEs 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 PTCME 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 PTCME MEP). PME MEP and the PW13 PPSTME MEP).
5. OAM Functions for proactive monitoring 5. OAM Functions for proactive monitoring
[Munich: Note the fwk needs to be explicit about the mapping of [Editors' note: at the beginning of each section, reference the
functions to the tools we have chosen.] [editors: shouldn't it be the section in the OAM Requirements document and explicitly list
other way around?] 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.
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 are used to detect a loss of
continuity defect (LOC) between two MEPs in an MEG. continuity defect (LOC) between two MEPs in an MEG.
Proactive Connectivity Verification functions are used to detect an Proactive Connectivity Verification functions are used to detect an
skipping to change at page 25, line 23 skipping to change at page 28, line 26
with an unexpected MEP. 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 MEG identifier. function, the CC-V OAM packet MAY not include any globally unique
Source MEP identifier identifier. Different formats of MEP
Different formats of MEP identifiers are defined in [10] to address identifiers are defined in [10] to address different environments.
different applications. When MPLS-TP is deployed in transport network When MPLS-TP is deployed in transport network environments where IP
applications as defined by ITU-T, the ICC-based format for MEP addressing is not used in the forwarding plane, the ICC-based format
identification is the DEFAULT and MANDATORY identification scheme. for MEP identification is used. When MPLS-TP is deployed in IP-based
When MPLS-TP is deployed in IP-based environment, the IP-based MEP environment, the IP-based MEP identification is used.
identification is the DEFAULT and MANDATORY identification scheme.
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 while it is possible to detect
any misconnection between two MEGs monitored for Continuity and any misconnection between two MEGs monitored for Continuity and
Connectivity or between an MEG monitored for Continuity and Connectivity or between an MEG monitored for Continuity and
Connectivity and one MEG monitored only for Continuity. Connectivity and one MEG monitored only for Continuity.
[Editor's note - Rephrase the previous paragraph: describe the four
cases.]
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.4).
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. the network borders by the same function that translates it for user
data traffic.
[Editor's note - Describe the relation between the previous paragraph [Editor's note - Describe the relation between the previous paragraph
and the fate sharing requirement. Need to clarify also in the and the fate sharing requirement. Need to clarify also in the
requirement document that for proactive CC-V the fate sharing is requirement document that for proactive CC-V the fate sharing is
related to the forwarding behavior and not to the QoS behavior] 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. In a packets from its peer MEP at the same transmission rate as a common
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.
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 pro-active CC-V information and forward these pro- transparent to the pro-active CC-V information and forward these pro-
active CC-V OAM packets as regular data packets. active CC-V OAM packets as regular data packets.
To initialize the proactive CC-V monitoring on a configured ME It is desirable to not generate spurious alarms during initialization
without affecting traffic, the MEP source function (generating pro- or tear down; hence the following procedures are recommended. At
active CC-V packets) should be enabled prior to the corresponding MEP initialization, the MEP source function (generating pro-active CC-V
sink function (detecting continuity and connectivity defects). When packets) should be enabled prior to the corresponding MEP sink
function (detecting continuity and connectivity defects). When
disabling the CC-V proactive functionality, the MEP sink function disabling the CC-V proactive functionality, the MEP sink function
should be disabled prior to the corresponding MEP source function. should be disabled prior to the corresponding MEP source function.
5.1.1. Defects identified by CC-V 5.1.1. Defects identified by CC-V
Pro-active CC-V functions allow a sink MEP to detect the defect Pro-active CC-V functions allow a sink MEP to detect the defect
conditions described in the following sub-sections. For all of the conditions described in the following sub-sections. For all of the
described defect cases, the sink MEP SHOULD notify the equipment described defect cases, the sink MEP SHOULD notify the equipment
fault management process of the detected defect. fault management process of the detected defect.
5.1.1.1. Loss Of Continuity defect 5.1.1.1. Loss Of Continuity defect
When proactive CC-V is enabled, a sink MEP detects a loss of When proactive CC-V is enabled, a sink MEP detects a loss of
continuity (LOC) defect when it fails to receive pro-active CC-V OAM continuity (LOC) defect when it fails to receive pro-active CC-V OAM
packets from the peer MEP. packets from the peer MEP.
o Entry criteria: if no pro-active CC-V OAM packets from the peer o Entry criteria: if no pro-active CC-V OAM packets from the peer
MEP (i.e. with the correct ME and peer MEP identifiers) are MEP (i.e. with the correct globally unique Source MEP identifier)
received within the interval equal to 3.5 times the receiving are received within the interval equal to 3.5 times the receiving
MEP's configured CC-V transmission period. MEP's configured CC-V reception period.
o Exit criteria: a pro-active CC-V OAM packet from the peer MEP o Exit criteria: a pro-active CC-V OAM packet from the peer MEP
(i.e. with the correct ME and peer MEP identifiers) is received. (i.e. with the correct globally unique Source MEP identifier) is
received.
5.1.1.2. Mis-connectivity defect 5.1.1.2. Mis-connectivity defect
When a pro-active CC-V OAM packet is received, a sink MEP identifies When a pro-active CC-V OAM packet is received, a sink MEP identifies
a mis-connectivity defect (e.g. mismerge or misconnection) with its a mis-connectivity defect (e.g. mismerge, misconnection or unintended
peer source MEP when the received packet carries an incorrect ME looping) with its peer source MEP when the received packet carries an
identifier. incorrect globally unique Source MEP identifier.
o Entry criteria: the sink MEP receives a pro-active CC-V OAM packet o Entry criteria: the sink MEP receives a pro-active CC-V OAM packet
with an incorrect ME ID. with an incorrect globally unique Source MEP identifier.
o Exit criteria: the sink MEP does not receive any pro-active CC-V o Exit criteria: the sink MEP does not receive any pro-active CC-V
OAM packet with an incorrect ME ID for an interval equal at least OAM packet with an incorrect globally unique Source MEP identifier
to 3.5 times the longest transmission period of the pro-active for an interval equal at least to 3.5 times the longest
CC-V OAM packets received with an incorrect ME ID since this transmission period of the pro-active CC-V OAM packets received
with an incorrect globally unique Source MEP identifier since this
defect has been raised. This requires the OAM message to self defect has been raised. This requires the OAM message to self
identify the CC-V periodicity as not all MEPs can be expected to identify the CC-V periodicity as not all MEPs can be expected to
have knowledge of all MEs. have knowledge of all MEGs.
5.1.1.3. MEP misconfiguration defect
When a pro-active CC-V packet is received, a sink MEP identifies a
MEP misconfiguration defect with its peer source MEP when the
received packet carries a correct ME Identifier but an unexpected
peer MEP Identifier which includes the MEP's own MEP Identifier.
o Entry criteria: the sink MEP receives a CC-V pro-active packet
with correct ME ID but with unexpected MEP ID.
o Exit criteria: the sink MEP does not receive any pro-active CC-V
OAM packet with a correct ME ID and unexpected MEP ID for an
interval equal at least to 3.5 times the longest transmission
period of the pro-active CC-V OAM packets received with a correct
ME ID and unexpected MEP ID since this defect has been raised.
5.1.1.4. Period Misconfiguration defect 5.1.1.3. Period Misconfiguration defect
If pro-active CC-V OAM packets are received with correct ME and MEP If pro-active CC-V OAM packets are received with a correct globally
identifiers but with a transmission period different than its own unique Source MEP identifier but with a transmission period different
configured transmission period, then a CC-V period mis-configuration than the locally configured reception period, then a CV period mis-
defect is detected configuration defect is detected.
o Entry criteria: a MEP receives a CC-V pro-active packet with o Entry criteria: a MEP receives a CC-V pro-active packet with
correct ME ID and MEP ID but with a Period field value different correct globally unique Source MEP identifier but with a Period
than its own CC-V configured transmission period. field value different than its own CC-V configured transmission
period.
o Exit criteria: the sink MEP does not receive any pro-active CC-V o Exit criteria: the sink MEP does not receive any pro-active CC-V
OAM packet with a correct ME and MEP IDs and an incorrect OAM packet with a correct globally unique Source MEP identifier
transmission period for an interval equal at least to 3.5 times and an incorrect transmission period for an interval equal at
the longest transmission period of the pro-active CC-V OAM packets least to 3.5 times the longest transmission period of the pro-
received with a correct ME and MEP IDs and an incorrect active CC-V OAM packets received with a correct globally unique
transmission period since this defect has been raised. Source MEP identifier and an incorrect transmission period since
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 [editors: IMO this would be better folded into the specific defect
types, If agreed I will edit accordingly] 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. Some of
these consequent actions SHOULD be enabled/disabled by the operator these consequent actions SHOULD be enabled/disabled by the operator
depending upon the application used (see section 5.1.4). depending upon the application used (see section 5.1.4).
If a MEP detects an unexpected ME Identifier, or an unexpected MEP, 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 and the CC-V monitoring is enabled it If a MEP detects LOC defect that is not caused by a period
SHOULD block all the traffic (including also the user data packets) mis-configuration, it SHOULD block all the traffic (including also
that it receives from the transport path if this consequent action the user data packets) that it receives from the transport path, if
has been enabled by the operator. this consequent action has been enabled by the operator.
It is worth noticing that the OAM requirements document [12] It is worth noticing that the OAM requirements document [12]
recommends that CC-V proactive monitoring is enabled on every ME in recommends that CC-V proactive monitoring is enabled on every MEG in
order to reliably detect connectivity defects. However, CC-V order to reliably detect connectivity defects. However, CC-V
proactive monitoring MAY be disabled by an operator on an ME. In the proactive monitoring MAY be disabled by an operator on an MEG. In the
event of a misconnection between a transport path that is pro- event of a misconnection between a transport path that is pro-
actively monitored for CC-V and a transport path which is not, the actively monitored for CC-V and a transport path which is not, the
MEP of the former transport path will detect a LOC defect MEP of the former transport path will detect a LOC defect
representing a connectivity problem (e.g. a misconnection with a representing a connectivity problem (e.g. a misconnection with a
transport path where CC-V proactive monitoring is not enabled) transport path where CC-V proactive monitoring is not enabled)
instead of a continuity problem, with a consequent wrong traffic instead of a continuity problem, with a consequent wrong traffic
delivering. For these reasons, the traffic block consequent action is delivering. For these reasons, the traffic block consequent action is
applied even when a LOC condition occurs. This block consequent applied even when a LOC condition occurs. This block consequent
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, an unexpected ME Identifier, or an If a MEP detects a LOC defect (section 5.1.1.1), a mis-connectivity
unexpected MEP it MUST declare a signal fail condition at the defect (section 5.1.1.2) or a period misconfiguration defect (section
transport path level. 5.1.1.3), it MUST declare a signal fail condition at the transport
path level.
If a MEP detects an Unexpected Period defect it SHOULD declare a
signal fail condition at the transport path level.
[Editor's note - Transport equipment also performs defect correlation [Editor's note - Transport equipment also performs defect correlation
(as defined in G.806) in order to properly report failures to the (as defined in G.806) in order to properly report failures to the
transport NMS ]. The current working assumption, to be further transport NMS]. The current working assumption, to be further
investigated, is that defect correlations are outside the scope of investigated, is that defect correlations are outside the scope of
this document and to be defined in ITU-T documents.] 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 ME. In case of list is composed by all the leaf MEP IDs inside the MEG. In case
the leaf MEP of a p2mp MEG, the list is composed by the root MEP of the leaf MEP of a p2mp MEG, the list is composed by the root
ID (i.e. each leaf MUST know the root MEP ID from which it expect MEP ID (i.e. each leaf MUST know the root MEP ID from which it
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 o transmission rate; the default CC-V transmission periods are
application dependent (see section 5.1.4) 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 For statically provisioned transport paths the above information are
statically configured; for dynamically established transport paths statically configured; for dynamically established transport paths
the configuration information are signaled via the control plane. the configuration information are signaled via the control plane.
5.1.4. Applications for proactive CC-V 5.1.4. Applications for proactive CC-V
CC-V is applicable for fault management, performance monitoring, or CC-V is applicable for fault management, performance monitoring, or
protection switching applications. protection switching applications.
o Fault Management: default transmission period is 1s (i.e. o Fault Management: default transmission period is 1s (i.e.
transmission rate of 1 packet/second) transmission rate of 1 packet/second).
o Performance Monitoring: Performance monitoring is only relevant o Performance Monitoring: default transmission period is 100ms (i.e.
when the transport path is defect free. CC-V contributes to the transmission rate of 10 packets/second). Performance monitoring is
accuracy of PM statistics by permitting the defect free periods to only relevant when the transport path is defect free. CC-V
be properly distinguished. contributes to the accuracy of PM statistics by permitting the
defect free periods to be properly distinguished.
o Protection Switching: in order to achieve sub-50ms the defect o Protection Switching: default transmission period is 3.33ms (i.e.
entry criteria should resolve in less than 50msec, and should transmission rate of 300 packets/second), in order to achieve sub-
budget sufficient portion of the 50 msec. to be available for 50ms the CC-V defect entry criteria should resolve in less than
consequent action processing. In some cases, when a slower 10msec, and complete a protection switch within a subsequent
recovery time is acceptable, it is also possible to lengthen the period of 50 msec.
transmission rate.
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 In addition, the operator should be able to define the consequent
action to be performed for each of these applications. action to be performed for each of these applications.
5.2. Remote Defect Indication 5.2. Remote Defect Indication
skipping to change at page 31, line 33 skipping to change at page 34, line 26
the far-end defect condition is used as a contribution to the the far-end defect condition is used as a contribution to the
bidirectional performance monitoring process. 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 relies upon an Alarm Indication Signal
(AIS) message used to suppress alarms following detection of defect (AIS) message used to suppress alarms following detection of defect
conditions at the server (sub-)layer. 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, can generate packets with AIS information in a (sub-)layer, will notify the MPLS-TP client (sub-)layer adaptation
function, which can generate packets with AIS information in a
direction opposite to its peers MEPs to allow the suppression of 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
MEP upon fault detection in the server layer network to which the adaptation function upon fault detection in the server layer network
server MEP is associated. to which the server MEP is associated.
[editor: the above is confused. The server layer passes signal fail
or whatever notification to the adaptation function which has
knowledge of the client layer transport paths, otherwise we are
discussing a layer violation. These may be MEP co-located end points
or MIPs. It is the OAM functionality co-located with the adaptation
function that performs AIS insertion into the client layer MPLS-TP
paths.... If agreed I will re-word accordingly]
Only Server MEPs can issue MPLS-TP packets with AIS information. Upon Only the client layer adaptation function at an intermediate node
detection of a signal fail condition the Server MEP can immediately will issue MPLS-TP packets with AIS information. Upon receiving
start transmitting periodic packets with AIS information. These notification of a signal fail condition the adaptation function
periodic packets, with AIS information, continue to be transmitted SHOULD immediately start transmitting periodic packets with AIS
until the signal fail condition is cleared. [editor: SEE ABOVE] information. These periodic packets, with AIS information, continue
to be transmitted until the signal fail condition is cleared.
Upon receiving a packet with AIS information an MPLS-TP MEP detects Upon receiving a packet with AIS information an MPLS-TP MEP enters an
an AIS defect condition and suppresses loss of continuity alarms AIS defect condition and suppresses loss of continuity alarms
associated with all of its peer MEPs. [editor: There can only be one associated with its peer MEP. A MEP resumes loss of continuity alarm
MEP for the ME AIS has been received in association with] A MEP generation upon detecting loss of continuity defect conditions in the
resumes loss of continuity alarm generation upon detecting loss of absence of AIS condition.
continuity defect conditions in the absence of AIS condition.
For example, let's consider a fiber cut between LSR 1 and LSR 2 in For example, let's consider a fiber cut between LSR 1 and LSR 2 in
the reference network of Figure 3. Assuming that all the MEs 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 PTCME and PW1Z PME,
however in transport network only the alarm associate to the fiber however in transport network only the alarm associate to the fiber
cut needs to be reported to NMS while all these secondary alarms cut needs to be reported to NMS while all these secondary alarms
should be suppressed (i.e. not reported to the NMS or reported as should be suppressed (i.e. not reported to the NMS or reported as
secondary alarms). 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 generates AIS packets on In both cases, the MEP of Sec12 SME in LSR 2 notifies the adaptation
the PSN13 LME in order to allow its MEP in LSR3 to suppress the LOC function for PSN13 LME that then generates AIS packets on the PSN13
alarm. LSR3 can also suppress the secondary alarm on PW1 PTCME LME in order to allow its MEP in LSR3 to suppress the LOC alarm. LSR3
because the MEP of PW1 PTCME resides within the same node as the MEP can also suppress the secondary alarm on PW13 PPSTME because the MEP
of PSN13 LME. The MEP of PW1 PTCME in LSR3 also generates AIS packets of PW13 PPSTME resides within the same node as the MEP of PSN13 LME.
on PW1Z PME in order to allow its MEP in LSRZ to suppress the LOC The MEP of PW13 PPSTME in LSR3 also notifies the adaptation function
alarm. for PW1Z PME that then generates AIS packets on PW1Z PME in order to
allow its MEP in LSRZ to suppress the LOC alarm.
The generation of AIS packets for each ME in the client (sub-)layer The generation of AIS packets for each MEG in the client (sub-)layer
is configurable (i.e. the operator can enable/disable the AIS is configurable (i.e. the operator can enable/disable the AIS
generation). generation).
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.
skipping to change at page 34, line 28 skipping to change at page 37, line 17
The Client Signal Failure Indication (CSF) function is used to help The Client Signal Failure Indication (CSF) function is used to help
process client defects and propagate a client signal defect condition process client defects and propagate a client signal defect condition
from the process associated with the local attachment circuit where from the process associated with the local attachment circuit where
the defect was detected (typically the source adaptation function for the defect was detected (typically the source adaptation function for
the local client interface) to the process associated with the far- the local client interface) to the process associated with the far-
end attachment circuit (typically the source adaptation function for end attachment circuit (typically the source adaptation function for
the far-end client interface) for the same transmission path in case the far-end client interface) for the same transmission path in case
the client of the transmission path does not support a native the client of the transmission path does not support a native
defect/alarm indication mechanism, e.g. FDI/AIS. defect/alarm indication mechanism, e.g. FDI/AIS.
[Editor's note - The need to support this function on the LSP layer
(and not only at the PW layer) needs to be further investigated.
Pending discussion on MPLS-TP clients in the main framework
document.]
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.
Either there needs to be a 1:1 correspondence between the client and Either there needs to be a 1:1 correspondence between the client and
the ME, 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.6.2. Applications for Client Signal Failure Indication
skipping to change at page 36, line 23 skipping to change at page 39, line 19
o Single or double-end performance monitoring: determination of the o Single or double-end performance monitoring: determination of the
delay performance of a transport path for SLA verification delay performance of a transport path for SLA verification
purposes. purposes.
o Single or double-end performance monitoring: determination of the o Single or double-end performance monitoring: determination of the
delay performance of a PHB Scheduling Class or Ordered Aggregate delay performance of a PHB Scheduling Class or Ordered Aggregate
within a transport path within a transport path
6. OAM Functions for on-demand monitoring 6. OAM Functions for on-demand monitoring
[Munich: Note the fwk needs to be explicit about the mapping of [Editors' note: at the beginning of each section, reference the
functions to the tools we have chosen.] 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.
[editor: we would have to babysit a lot fewer words if we folded this
into section 5 and simply indicated which transactions existed in
both proactive and reactive forms... if agreed I will edit accordingly]
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.
Use of on-demand CV is dependent on the existence of a bi-directional Use of on-demand CV is dependent on the existence of a bi-directional
connection ME, because it requires the presence of a return path in MEG, because it requires the presence of a return path in the data
the data plane. 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 [Editor's note - Clarify in the sentence above and within the
paragraph that on-demand CV requires a return path to send back the paragraph that on-demand CV requires a return path to send back the
reply to on-demand CV packets] reply to on-demand CV packets]
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 ME that is being checked. The on-demand should uniquely identify the MEG that is being checked. The on-
functionality may be used to check either an entire ME (end-to-end) demand functionality may be used to check either an entire MEG (end-
or between a MEP to a specific MIP. This functionality may not be to-end) or between a MEP to a specific MIP. This functionality may
available for associated bidirectional paths as the MIP may not have not be available for associated bidirectional paths as the MIP may
a return path to the source MEP for the on-demand CV transaction. not have a return path to the source MEP for the on-demand CV
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 ME, the source MEP should issue When invoking a periodic check of the MEG, the source MEP should
a burst of on-demand CV packets that uniquely identifies the ME being issue a burst of on-demand CV packets that uniquely identifies the
verified. The number of packets and their transmission rate should MEG being verified. The number of packets and their transmission
be pre-configured and known to both the source MEP and the target MEP rate should be pre-configured and known to both the source MEP and
or MIP. The source MEP should use the TTL field to indicate the the target MEP or MIP. The source MEP should use the TTL field to
number of hops necessary, when targeting a MIP and use the default indicate the number of hops necessary, when targeting a MIP and use
value when performing an end-to-end check [IB => This is quite the default value when performing an end-to-end check [IB => This is
generic for addressing packets to MIPs and MEPs so it is better to quite generic for addressing packets to MIPs and MEPs so it is better
move this text in section 2]. The target MEP/MIP shall return a to move this text in section 2]. The target MEP/MIP shall return a
reply on-demand CV packet for each packet received. If the expected reply on-demand CV packet for each packet received. If the expected
number of on-demand CV reply packets is not received at source MEP, number of on-demand CV reply packets is not received at source MEP,
the LOC defect state is entered. the LOC defect state is entered.
[Editor's note - We need to add some text for the usage of on-demand [Editor's note - We need to add some text for the usage of on-demand
CV with different packet sizes, e.g. to discover MTU problems.] CV with different packet sizes, e.g. to discover MTU problems.]
When a connectivity problem is detected (e.g. via a proactive CC-V
OAM tool), an on-demand CV tool can be used to check the path. The
series should check CV from MEP to peer MEP on the path, and if a
fault is discovered, by lack of response, then additional checks may
be performed to each of the intermediate MIP to locate the fault.
[Dave: this seems a bit warped as the original discussion was about
not spending resources on proactive CC-V, so can we just be honest
about "when the incredibly pissed off customer calls, an on demand CV
tool..."]
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.
skipping to change at page 38, line 35 skipping to change at page 41, line 19
diagnostic of QoS performance for a transport path. As proactive LM, diagnostic of QoS performance for a transport path. As proactive LM,
on-demand LM is used to exchange counter values for the number of on-demand LM is used to exchange counter values for the number of
ingress and egress packets transmitted and received by the transport ingress and egress packets transmitted and received by the transport
path monitored by a pair of MEPs. 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. [Dave: again packet loss performance metrics of the transport path.
are we discussing simply discard eligibility and no other PHB
impacts?]
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
skipping to change at page 39, line 20 skipping to change at page 41, line 47
performance of a transport path for SLA trouble shooting purposes. performance of a transport path for SLA trouble shooting purposes.
o Single-end performance monitoring: diagnostic of the packet loss o Single-end performance monitoring: diagnostic of the packet loss
performance of a PHB Scheduling Class or Ordering Aggregate within performance of a PHB Scheduling Class or Ordering Aggregate within
a transport path for QoS trouble shooting purposes. a transport path for QoS trouble shooting purposes.
6.3. Diagnostic 6.3. Diagnostic
To be incorporated in a future revision of this document To be incorporated in a future revision of this document
[Editors' note: describe an OAM tool for throughput estimation (out-
of-service): works in one-way and two-way modes]
[Editors' note: Need further investigation about the need to support
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 [Munich: Need to describe the two types of loopback - LBM/LBR and
traffic loopback enhanced with variable sized packets in the on traffic loopback enhanced with variable sized packets in the on
demand cases. demand cases.
One objective of diags is fault location, we need to make clear how One objective of diags is fault location, we need to make clear how
we apply the tools to fault location. we apply the tools to fault location.
At the top of each section we need to describe the detailed At the top of each section we need to describe the detailed
requirements and then in the rest of the section describe how it is requirements and then in the rest of the section describe how it is
met.] met.]
6.4. Route Tracing 6.4. Route Tracing
[Editors' note: The framework needs to say what you need to trace and
not how you do it (remove the description of the solution).]
[Editors' note: Need to investigate if we need both tracing options:
describe why and a sketch of the two options and their properties.
Possible reasons for both options:
o TTL incremental tells whether the CP is correct or not
o the second one (path discovery) is ...
Action: check on the mailing list the need to support both modes of
operations.]
After e.g. provisioning an MPLS-TP LSP or for trouble shooting After e.g. provisioning an MPLS-TP LSP or for trouble shooting
purposes, it is often necessary to trace a route covered by an ME purposes, it is often necessary to trace a route covered by an ME
from a source MEP to the sink MEP including all the MIPs in-between. from a source MEP to the sink MEP including all the MIPs in-between.
The route tracing function is providing this functionality. Based on The route tracing function is providing this functionality. Based on
the fate sharing requirement of OAM flows, i.e. OAM packets receive the fate sharing requirement of OAM flows, i.e. OAM packets receive
the same forwarding treatment as data packet, route tracing is a the same forwarding treatment as data packet, route tracing is a
basic means to perform CV and, to a much lesser degree, CC. For this basic means to perform CV and, to a much lesser degree, CC. For this
function to work properly, a return path must be 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
skipping to change at page 43, line 34 skipping to change at page 46, 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-01 (work in progress), Networks", draft-ietf-mpls-tp-framework-06 (work in progress),
June 2009 October 2009
[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-swallow- [10] Swallow, G., Bocci, M., "MPLS-TP Identifiers", draft-ietf-mpls-
mpls-tp-identifiers-01 (work in progress), July 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 03 (work in progress), August 2009
[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-sprecher-mpls-tp-oam-analysis-04 "MPLS-TP OAM Analysis", draft-ietf-mpls-tp-oam-analysis-00
(work in progress), May 2009 (work in progress), November 2009
[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
skipping to change at page 44, line 47 skipping to change at page 47, line 47
Authors' Addresses Authors' Addresses
Dave Allan (Editor) Dave Allan (Editor)
Ericsson Ericsson
Email: david.i.allan@ericsson.com Email: david.i.allan@ericsson.com
Italo Busi (Editor) Italo Busi (Editor)
Alcatel-Lucent Alcatel-Lucent
Email: Italo.Busi@alcatel-lucent.it Email: Italo.Busi@alcatel-lucent.com
Ben Niven-Jenkins (Editor) Ben Niven-Jenkins (Editor)
BT BT
Email: benjamin.niven-jenkins@bt.com Email: benjamin.niven-jenkins@bt.com
Contributing Authors' Addresses Contributing Authors' Addresses
Annamaria Fulignoli Annamaria Fulignoli
Ericsson Ericsson
Email: annamaria.fulignoli@ericsson.com Email: annamaria.fulignoli@ericsson.com
Enrique Hernandez-Valencia Enrique Hernandez-Valencia
Alcatel-Lucent Alcatel-Lucent
Email: enrique@alcatel-lucent.com Email: Enrique.Hernandez@alcatel-lucent.com
Lieven Levrau Lieven Levrau
Alcatel-Lucent Alcatel-Lucent
Email: llevrau@alcatel-lucent.com Email: Lieven.Levrau@alcatel-lucent.com
Dinesh Mohan Dinesh Mohan
Nortel Nortel
Email: mohand@nortel.com Email: mohand@nortel.com
Vincenzo Sestito Vincenzo Sestito
Alcatel-Lucent Alcatel-Lucent
Email: vincenzo.sestito@alcatel-lucent.it Email: Vincenzo.Sestito@alcatel-lucent.com
Nurit Sprecher Nurit Sprecher
Nokia Siemens Networks Nokia Siemens Networks
Email: nurit.sprecher@nsn.com Email: nurit.sprecher@nsn.com
Huub van Helvoort Huub van Helvoort
Huawei Technologies Huawei Technologies
Email: hhelvoort@huawei.com Email: hhelvoort@huawei.com
Martin Vigoureux Martin Vigoureux
Alcatel-Lucent Alcatel-Lucent
Email: martin.vigoureux@alcatel-lucent.fr Email: Martin.Vigoureux@alcatel-lucent.com
Yaacov Weingarten Yaacov Weingarten
Nokia Siemens Networks Nokia Siemens Networks
Email: yaacov.weingarten@nsn.com Email: yaacov.weingarten@nsn.com
Rolf Winter Rolf Winter
NEC NEC
Email: Rolf.Winter@nw.neclab.eu Email: Rolf.Winter@nw.neclab.eu
 End of changes. 175 change blocks. 
678 lines changed or deleted 807 lines changed or added

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