draft-ietf-mpls-tp-oam-analysis-05.txt   draft-ietf-mpls-tp-oam-analysis-06.txt 
Network Working Group N. Sprecher Network Working Group N. Sprecher
Internet-Draft Nokia Siemens Networks Internet-Draft Nokia Siemens Networks
Intended status: Informational L. Fang Intended status: Informational L. Fang
Expires: March 30, 2012 Cisco Expires: April 14, 2012 Cisco
September 27, 2011 October 12, 2011
An Overview of the OAM Tool Set for MPLS based Transport Networks An Overview of the OAM Tool Set for MPLS based Transport Networks
draft-ietf-mpls-tp-oam-analysis-05.txt draft-ietf-mpls-tp-oam-analysis-06.txt
Abstract Abstract
This document provides an overview of the OAM toolset for MPLS based This document provides an overview of the OAM toolset for MPLS based
Transport Networks. The toolset consists of a comprehensive set of Transport Networks. The toolset consists of a comprehensive set of
fault management and performance monitoring capabilities (operating fault management and performance monitoring capabilities (operating
in the data-plane) which are appropriate for transport networks as in the data-plane) which are appropriate for transport networks as
required in [MPLS-TP OAM Reqs] and support the network and services required in [MPLS-TP OAM Reqs] and support the network and services
at different nested levels. This overview includes a brief recap of at different nested levels. This overview includes a brief recap of
MPLS-TP OAM requirements and functions, and of generic mechanisms MPLS-TP OAM requirements and functions, and of generic mechanisms
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 30, 2012. This Internet-Draft will expire on April 14, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 27 skipping to change at page 3, line 27
3.3. Route Tracing . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Route Tracing . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1. Documents for Route Tracing . . . . . . . . . . . . . 9 3.3.1. Documents for Route Tracing . . . . . . . . . . . . . 9
3.4. Alarm Reporting . . . . . . . . . . . . . . . . . . . . . 9 3.4. Alarm Reporting . . . . . . . . . . . . . . . . . . . . . 9
3.4.1. Documents for Alarm Reporting . . . . . . . . . . . . 9 3.4.1. Documents for Alarm Reporting . . . . . . . . . . . . 9
3.5. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . 10 3.5. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . 10
3.5.1. Documents for Lock Instruct . . . . . . . . . . . . . 10 3.5.1. Documents for Lock Instruct . . . . . . . . . . . . . 10
3.6. Lock Reporting . . . . . . . . . . . . . . . . . . . . . . 10 3.6. Lock Reporting . . . . . . . . . . . . . . . . . . . . . . 10
3.6.1. Documents for Lock Reporting . . . . . . . . . . . . . 10 3.6.1. Documents for Lock Reporting . . . . . . . . . . . . . 10
3.7. Diagnostic . . . . . . . . . . . . . . . . . . . . . . . . 10 3.7. Diagnostic . . . . . . . . . . . . . . . . . . . . . . . . 10
3.7.1. Documents for Diagnostic Testing . . . . . . . . . . . 11 3.7.1. Documents for Diagnostic Testing . . . . . . . . . . . 11
3.8. Client Failure Indication . . . . . . . . . . . . . . . . 11 3.8. Packet Loss Measurement . . . . . . . . . . . . . . . . . 11
3.8.1. Documents for CFI . . . . . . . . . . . . . . . . . . 11 3.8.1. Documents for Packet Loss Measurement . . . . . . . . 11
3.9. Packet Loss Measurement . . . . . . . . . . . . . . . . . 11 3.9. Packet Delay Measurement . . . . . . . . . . . . . . . . . 11
3.9.1. Documents for Packet Loss Measurement . . . . . . . . 11 3.9.1. Documents for Delay Measurement . . . . . . . . . . . 12
3.10. Packet Delay Measurement . . . . . . . . . . . . . . . . . 11
3.10.1. Documents for Delay Measurement . . . . . . . . . . . 12
4. MPLS-TP OAM documents guide . . . . . . . . . . . . . . . . . 12 4. MPLS-TP OAM documents guide . . . . . . . . . . . . . . . . . 12
5. OAM Toolset Applicability and Utilization . . . . . . . . . . 14 5. OAM Toolset Applicability and Utilization . . . . . . . . . . 14
5.1. Connectivity Check and Connectivity Verification . . . . . 14 5.1. Connectivity Check and Connectivity Verification . . . . . 14
5.2. Diagnostic Tests and Lock Instruct . . . . . . . . . . . . 15 5.2. Diagnostic Tests and Lock Instruct . . . . . . . . . . . . 15
5.3. Lock Reporting . . . . . . . . . . . . . . . . . . . . . . 15 5.3. Lock Reporting . . . . . . . . . . . . . . . . . . . . . . 15
5.4. Alarm Reporting and Link down Indication . . . . . . . . . 16 5.4. Alarm Reporting and Link Down Indication . . . . . . . . . 16
5.5. Remote Defect Indication . . . . . . . . . . . . . . . . . 16 5.5. Remote Defect Indication . . . . . . . . . . . . . . . . . 16
5.6. Packet Loss and Delay Measurement . . . . . . . . . . . . 17 5.6. Packet Loss and Delay Measurement . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
skipping to change at page 4, line 41 skipping to change at page 4, line 41
to be fully inter-operable with existing MPLS OAM tools as to be fully inter-operable with existing MPLS OAM tools as
documented in [MPLS-TP OAM Reqs]. documented in [MPLS-TP OAM Reqs].
The MPLS-TP OAM toolset is based on the following existing tools: The MPLS-TP OAM toolset is based on the following existing tools:
o LSP-Ping as defined in [LSP Ping]. o LSP-Ping as defined in [LSP Ping].
o Bidirectional Forwarding Detection (BFD) as defined in [BASE BFD] o Bidirectional Forwarding Detection (BFD) as defined in [BASE BFD]
and refined in [MPLS BFD]. and refined in [MPLS BFD].
o ITU-T OAM for Ethernet toolset as defined in [Y.1731] this will be o ITU-T OAM for Ethernet toolset as defined in [Y.1731]. This has
used for functionality guidelines for the performance measurement been used for functionality guidelines for the performance
tools that are not currently supported in MPLS. measurement tools that were not previously supported in MPLS.
It should be noted that certain extensions and adjustments have been It should be noted that certain extensions and adjustments have been
specified relative to the existing MPLS tools, in order to conform to specified relative to the existing MPLS tools, in order to conform to
the transport environment and the requirements of MPLS-TP. However, the transport environment and the requirements of MPLS-TP. However,
compatibility with the existing tools has been maintained. compatibility with the existing tools has been maintained.
This document provides an overview of the MPLS-TP OAM toolset, which This document provides an overview of the MPLS-TP OAM toolset, which
consists of tools for MPLS-TP fault management and performance consists of tools for MPLS-TP fault management and performance
monitoring. This overview includes a brief recap of MPLS-TP OAM monitoring. This overview includes a brief recap of MPLS-TP OAM
requirements and functions, and of the generic mechanisms used to requirements and functions, and of the generic mechanisms used to
skipping to change at page 7, line 17 skipping to change at page 7, line 17
the form of IP addressing structure and be extensible to support the form of IP addressing structure and be extensible to support
additional identification schemes. additional identification schemes.
o OAM packets and the user traffic are congruent (i.e. OAM packets o OAM packets and the user traffic are congruent (i.e. OAM packets
are transmitted in-band) and there is a need to differentiate OAM are transmitted in-band) and there is a need to differentiate OAM
packets from user-plane packets. Inherent in this requirement is packets from user-plane packets. Inherent in this requirement is
the principle that full operation of the MPLS-TP OAM must be the principle that full operation of the MPLS-TP OAM must be
possible independently of the control or management plane used to possible independently of the control or management plane used to
operate the network. operate the network.
o a single OAM solution and consistent OAM capabilities for LSPs, o there is a single OAM solution and that OAM capabilities for LSPs,
PWs, and Sections. PWs, and Sections are consistent.
o MPLS-TP OAM supports point-to-point bidirectional PWs, point- to- o MPLS-TP OAM supports point-to-point bidirectional PWs, point-to-
point co-routed bidirectional LSPs, point-to-point bidirectional point co-routed bidirectional LSPs, point-to-point bidirectional
Sections, point-to-point associated bidirectional LSPs, point-to- Sections, point-to-point associated bidirectional LSPs, point-to-
point unidirectional LSPs, and point-to-multipoint LSPs. In point unidirectional LSPs, and point-to-multipoint LSPs. In
addition, MPLS-TP OAM supports these LSPs and PWs when they span addition, MPLS-TP OAM supports these LSPs and PWs when they span
either a single or multiple domains. either a single or multiple domains.
o OAM packets may be directed to an intermediate point of a LSP/PW. o OAM packets may be directed to an intermediate point of a LSP/PW.
The following document-set addresses the basic requirements listed The following document-set addresses the basic requirements listed
above: above:
skipping to change at page 7, line 42 skipping to change at page 7, line 42
o The [MPLS-TP OAM Frwk] document describes the architectural o The [MPLS-TP OAM Frwk] document describes the architectural
framework for conformance to the basic requirements listed above. framework for conformance to the basic requirements listed above.
It also defines the basic relationships between the MPLS It also defines the basic relationships between the MPLS
structures, e.g. LSP, PW, and the structures necessary for OAM structures, e.g. LSP, PW, and the structures necessary for OAM
functionality, i.e. the Managed Entity Group, its End-points, and functionality, i.e. the Managed Entity Group, its End-points, and
Intermediate Points. Intermediate Points.
o The [MPLS G-ACH] document specifies the use of the MPLS-TP in-band o The [MPLS G-ACH] document specifies the use of the MPLS-TP in-band
control channels. It generalizes the applicability of the control channels. It generalizes the applicability of the
Pseudowire (PW) Associated Channel Header (ACH) to MPLS LSPs and Pseudowire (PW) Associated Channel Header (ACH) to MPLS LSPs and
Section, by defining a Generic Associated Channel (G-ACh). The Sections, by defining a Generic Associated Channel (G-ACh). The
G-ACh allows control packets to be multiplexed transparently over G-ACh allows control packets to be multiplexed transparently over
LSPs and sections, similar to that of PW VCCV [PW VCCV]. The LSPs and sections, similar to that of PW VCCV [PW VCCV]. The
Generic Association Label (GAL) is defined by assigning a reserved Generic Association Label (GAL) is defined by assigning a reserved
MPLS label value and is used to identify the OAM control packets. MPLS label value and is used to identify the OAM control packets.
The value of the ACH Channel Type field indicates the specific The value of the ACH Channel Type field indicates the specific
protocol carried on the associated control channel. Each MPLS-TP protocol carried on the associated control channel. Each MPLS-TP
OAM protocol has an IANA assigned channel type allocated to it. OAM protocol has an IANA assigned channel type allocated to it.
o The creation of G-ACh and GAL provided the necessary mechanisms to o The creation of G-ACh and GAL provided the necessary mechanisms to
allow OAM packets run in-band and share their fate with data allow OAM packets run in-band and share their fate with data
packets. It is expected that all of the OAM protocols will be packets. It is expected that all of the OAM protocols will be
used in conjunction with this Generic Associated Channel. used in conjunction with this Generic Associated Channel.
o The [MPLS TP Idents] document addresses the need of MPLS-TP to o The [MPLS TP Idents] document provides an IP-based identifier set
support different addressing spaces. This document describes for MPLS-TP that can be used to identify the transport entities in
different formats for addresses that could be used to identify the the network and referanced by the different OAM protocols.
transport entities in the network and referenced by the different [TP-Loss-Delay-Profile] augments that set of identifiers to
OAM protocols. include identifier information in a format used by the ITU-T.
Other spaces may be deifned as well.
3. MPLS-TP OAM Functions 3. MPLS-TP OAM Functions
The following sections discuss the OAM functions that are required in The following sections discuss the OAM functions that are required in
[MPLS-TP OAM Reqs] and expanded upon in [MPLS-TP OAM Frwk]. [MPLS-TP OAM Reqs] and expanded upon in [MPLS-TP OAM Frwk].
3.1. Continuity Check and Connectivity Verification 3.1. Continuity Check and Connectivity Verification
Continuity Check and Connectivity Verification (CC-V) are OAM Continuity Check and Connectivity Verification (CC-V) are OAM
operations generally used in tandem, and complement each other. operations generally used in tandem, and complement each other.
skipping to change at page 10, line 10 skipping to change at page 10, line 10
MPLS-TP defines a new protocol to address this functionality that is MPLS-TP defines a new protocol to address this functionality that is
documented in [Fault Mng]. This protocol uses all of the basic documented in [Fault Mng]. This protocol uses all of the basic
mechanisms detailed in Section 2. mechanisms detailed in Section 2.
3.5. Lock Instruct 3.5. Lock Instruct
The Lock Instruct function is an administrative control tool that The Lock Instruct function is an administrative control tool that
allows a path end-point to instruct its peer end-point to lock the allows a path end-point to instruct its peer end-point to lock the
path (LSP, PW or section). The tool is necessary to support single- path (LSP, PW or section). The tool is necessary to support single-
side provisioning for administrative locking, according to . This side provisioning for administrative locking, according to [MPLS-TP
function is used on-demand. OAM Frwk]. This function is used on-demand.
3.5.1. Documents for Lock Instruct 3.5.1. Documents for Lock Instruct
The [LiLoopback] document describes the details of a new ACH based The [LiLoopback] document describes the details of a new ACH based
protocol format for this functionality. protocol format for this functionality.
3.6. Lock Reporting 3.6. Lock Reporting
Lock reporting, defined in [MPLS-TP OAM Reqs], is similar to the Lock reporting, defined in [MPLS-TP OAM Reqs], is similar to the
Alarm Reporting function described above. It is used by an Alarm Reporting function described above. It is used by an
skipping to change at page 11, line 12 skipping to change at page 11, line 12
back to the originating MEP. For targeting MIPs, a co-routed bi- back to the originating MEP. For targeting MIPs, a co-routed bi-
directional path is required. directional path is required.
3.7.1. Documents for Diagnostic Testing 3.7.1. Documents for Diagnostic Testing
The [LiLoopback] document describes the details of a new ACH based The [LiLoopback] document describes the details of a new ACH based
protocol format for the Data-plane loopback functionality. protocol format for the Data-plane loopback functionality.
The tool for Throughput Estimation tool is under study. The tool for Throughput Estimation tool is under study.
3.8. Client Failure Indication 3.8. Packet Loss Measurement
Client Failure Indication (CFI) is defined in [MPLS-TP OAM Reqs] to
allow the propagation information from one edge of the MPLS-TP
network to the other. The information concerns a defect to a client,
in the case that the client does not support alarm notification.
3.8.1. Documents for CFI
A new ACH-based protocol is described in [MPLS-TP CSF] that addresses
the functionality defined for client failure indication.
3.9. Packet Loss Measurement
Packet Loss Measurement is required, by [MPLS-TP OAM Reqs] to provide Packet Loss Measurement is required by [MPLS-TP OAM Reqs] to provide
a quantification of the packet loss ratio on a transport path. This a quantification of the packet loss ratio on a transport path. This
is the ratio of the number of user packets lost to the total number is the ratio of the number of user packets lost to the total number
of user packets during a defined time interval. To employ this of user packets during a defined time interval. To employ this
function, [MPLS-TP OAM Frwk] defines that the two end-points of the function, [MPLS-TP OAM Frwk] defines that the two end-points of the
transport path should exchange counters of messages transmitted and transport path should exchange counters of messages transmitted and
received within a time period bounded by loss-measurement messages. received within a time period bounded by loss-measurement messages.
The framework warns that there may be small errors in the computation The framework warns that there may be small errors in the computation
that result from various issues. that result from various issues.
3.9.1. Documents for Packet Loss Measurement 3.8.1. Documents for Packet Loss Measurement
The [Loss-Delay] document describes the protocol formats and The [Loss-Delay] document describes the protocol formats and
procedures for using the tool. The tool logic is based on the procedures for using the tool and enable efficient and accurate
behavior of the parallel function described in [Y.1731]. measurement of packet loss, delay, and throughput in MPLS networks.
[TP-Loss-Delay-Profile] describes a profile of the general MPLS loss,
delay, and throughput measurement techniques that suffices to meet
the specific requirements of MPLS-TP. Note that the tool logic is
based on the behavior of the parallel function described in [Y.1731].
3.10. Packet Delay Measurement 3.9. Packet Delay Measurement
Packet Delay Measurement is a function that is used to measure one- Packet Delay Measurement is a function that is used to measure one-
way or wo-way delay of a packet transmission between a pair of the way or two-way delay of a packet transmission between a pair of the
end-points of a path (PW, LSP, or Section), as described in [MPLS-TP end-points of a path (PW, LSP, or Section), as described in [MPLS-TP
OAM Reqs]. Where: OAM Reqs]. Where:
o One-way packet delay is the time elapsed from the start of o One-way packet delay is the time elapsed from the start of
transmission of the first bit of the packet by a source node until transmission of the first bit of the packet by a source node until
the reception of the last bit of that packet by the destination the reception of the last bit of that packet by the destination
node. node.
o Two-way packet delay is the time elapsed from the start of o Two-way packet delay is the time elapsed from the start of
transmission of the first bit of the packet by a source node until transmission of the first bit of the packet by a source node until
the reception of the last bit of the loop-backed packet by the the reception of the last bit of the loop-backed packet by the
same source node, when the loopback is performed at the packet's same source node, when the loopback is performed at the packet's
destination node. destination node.
[MPLS-TP OAM Frwk] describes how the tool could be performed (both in [MPLS-TP OAM Frwk] describes how the tool could be performed (both in
proactive and on-demand modes) for either one-way or two-way proactive and on-demand modes) for either one-way or two-way
measurement. However, it warns that the one-way delay option measurement. However, it warns that the one-way delay option
requires precise time synchronization between the end-points. requires precise time synchronization between the end-points.
3.10.1. Documents for Delay Measurement 3.9.1. Documents for Delay Measurement
The [Loss-Delay] document describes the protocol formats and The [Loss-Delay] document describes the protocol formats and
procedures for using the tool. The tool logic is based on the procedures for using the tool and enable efficient and accurate
behavior of the parallel function described in [Y.1731]. measurement of packet loss, delay, and throughput in MPLS networks.
[TP-Loss-Delay-Profile] describes a profile of the general MPLS loss,
delay, and throughput measurement techniques that suffices to meet
the specific requirements of MPLS-TP. Note that the tool logic is
based on the behavior of the parallel function described in [Y.1731].
4. MPLS-TP OAM documents guide 4. MPLS-TP OAM documents guide
The complete MPLS-TP OAM protocol suite is covered by a small set of The complete MPLS-TP OAM protocol suite is covered by a small set of
existing IETF documents. This set of documents may be expanded in existing IETF documents. This set of documents may be expanded in
the future to cover additional OAM functionality. In order to allow the future to cover additional OAM functionality. In order to allow
the reader to understand this set of documents, a cross-reference of the reader to understand this set of documents, a cross-reference of
the existing documents (IETF RFCs or Internet drafts while this the existing documents (IETF RFCs or Internet drafts while this
document is work in progress) for the initial phase of the document is work in progress) for the initial phase of the
specification of MPLS based transport networks is provided below. specification of MPLS based transport networks is provided below.
skipping to change at page 13, line 26 skipping to change at page 13, line 26
| | message | | | | message | |
+------------------------+----------------------------+-------------+ +------------------------+----------------------------+-------------+
| Alarm Indication | G-ACh bases AIS message | [Fault Mng] | | Alarm Indication | G-ACh bases AIS message | [Fault Mng] |
| Signal (AIS) | | | | Signal (AIS) | | |
+------------------------+----------------------------+-------------+ +------------------------+----------------------------+-------------+
| Link Down Indication | Flag in AIS message | [Fault Mng] | | Link Down Indication | Flag in AIS message | [Fault Mng] |
| (LDI) | | | | (LDI) | | |
+------------------------+----------------------------+-------------+ +------------------------+----------------------------+-------------+
| Lock Reporting (LKR) | G-ACh bases LKR message | [Fault Mng] | | Lock Reporting (LKR) | G-ACh bases LKR message | [Fault Mng] |
+------------------------+----------------------------+-------------+ +------------------------+----------------------------+-------------+
| Client Signal Fail | G-ACh based CSF message | [MPLS-TP |
| (CSF) | | CSF] |
+------------------------+----------------------------+-------------+
Proactive Fault Management OAM Toolset Proactive Fault Management OAM Toolset
Table 1 Table 1
The following table (Table 2) provides an overview of the on-demand The following table (Table 2) provides an overview of the on-demand
MPLS-TP OAM Fault Management toolset functions, associated tool/ MPLS-TP OAM Fault Management toolset functions, associated tool/
protocol, and the corresponding IETF RFCs or Internet drafts where protocol, and the corresponding IETF RFCs or Internet drafts where
they are defined. they are defined.
skipping to change at page 14, line 4 skipping to change at page 13, line 50
+----------------------+-----------------------------+--------------+ +----------------------+-----------------------------+--------------+
| Connectivity | LSP Ping | [Demand CV] | | Connectivity | LSP Ping | [Demand CV] |
| Verification | | | | Verification | | |
+----------------------+-----------------------------+--------------+ +----------------------+-----------------------------+--------------+
| Diagnostic: Loopback | (1) G-ACh based Loopback | [LiLoopback] | | Diagnostic: Loopback | (1) G-ACh based Loopback | [LiLoopback] |
| and Lock Instruct | and Lock Instruct, (2) LSP | | | and Lock Instruct | and Lock Instruct, (2) LSP | |
| | Ping | | | | Ping | |
+----------------------+-----------------------------+--------------+ +----------------------+-----------------------------+--------------+
| Lock Instruct(LI) | Flag in AIS message | [Fault Mng] | | Lock Instruct(LI) | Flag in AIS message | [Fault Mng] |
+----------------------+-----------------------------+--------------+ +----------------------+-----------------------------+--------------+
On Demand Fault Management OAM Toolset
On Demand Fault Management OAM Toolset
Table 2 Table 2
The following table (Table 3) provides the Performance Monitoring The following table (Table 3) provides the Performance Monitoring
Fuctions, asscociated tool/protocol definitions, and corresponding Fuctions, asscociated tool/protocol definitions, and corresponding
RFCs or Internet Drafts. RFCs or Internet Drafts.
+------------------+----------------------+-------------------------+ +------------------+----------------------+-------------------------+
| OAM Functions | OAM Tools/Protocols | RFCs / Internet Drafts | | OAM Functions | OAM Tools/Protocols | RFCs / Internet Drafts |
+------------------+----------------------+-------------------------+ +------------------+----------------------+-------------------------+
| Packet Loss | G-ACh based LM & DM | [Loss-Delay] | | Packet Loss | G-ACh based LM & DM | [Loss-Delay] |
skipping to change at page 15, line 4 skipping to change at page 14, line 49
functions are used to detect loss of continuity (LOC), and unintended functions are used to detect loss of continuity (LOC), and unintended
connectivity between two MEPs. Loss of connectivity, mis-merging, connectivity between two MEPs. Loss of connectivity, mis-merging,
mis-connectivity, or unexpected Maintenance Entity Group End Points mis-connectivity, or unexpected Maintenance Entity Group End Points
(MEPs) can be detected using the CC-V tools. (MEPs) can be detected using the CC-V tools.
The CC-V tools are used to support MPLS-TP fault management, The CC-V tools are used to support MPLS-TP fault management,
performance management, and protection switching. Proactive CC-V performance management, and protection switching. Proactive CC-V
control packets are sent by the source MEP to sink MEP. The sink MEP control packets are sent by the source MEP to sink MEP. The sink MEP
monitors the arrival of the CC-V control packets and detects the monitors the arrival of the CC-V control packets and detects the
defect. For bidirectional transport paths, the CC-V protocol is, defect. For bidirectional transport paths, the CC-V protocol is,
usually, transmitted simutaneously in both directions. usually, transmitted simultaneously in both directions.
The transmission interval of CC-V control packet can be configured. The transmission interval of CC-V control packet can be configured.
For example: For example:
o 3.3ms is the default interval for protection switching. o 3.3ms is the default interval for protection switching.
o 100ms is the default interval for performance monitoring. o 100ms is the default interval for performance monitoring.
o 1s is the default interval for fault management. o 1s is the default interval for fault management.
skipping to change at page 16, line 6 skipping to change at page 16, line 5
performance (loss, delay, delay variation, and throughput) of given performance (loss, delay, delay variation, and throughput) of given
LSP up to a specific node on the path of the LSP. LSP up to a specific node on the path of the LSP.
5.3. Lock Reporting 5.3. Lock Reporting
The Lock Report (LKR) function is used to communicate to the client The Lock Report (LKR) function is used to communicate to the client
(sub-) layer MEPs the administrative locking of a server (sub-) layer (sub-) layer MEPs the administrative locking of a server (sub-) layer
MEP, and consequential interruption of data traffic forwarding in the MEP, and consequential interruption of data traffic forwarding in the
client (sub-) layer. client (sub-) layer.
When operator is taking the LSP out of service for maintenance other When operator is taking the LSP out of service for maintenance or
operational reason, using the LKR function can help to distinguish other operational reason, using the LKR function can help to
the condition as administrative locking from defect condition. distinguish the condition as administrative locking from defect
condition.
The Lock Report function would also serve the purpose of alarm The Lock Report function would also serve the purpose of alarm
suppression in the MPLS-TP network above the level of the Lock is suppression in the MPLS-TP network above the level at which the Lock
occurred. The receipt of an LKR message MAY be treated as the has occurred. The receipt of an LKR message MAY be treated as the
equivalent of loss of continuity at the client layer. equivalent of loss of continuity at the client layer.
5.4. Alarm Reporting and Link down Indication 5.4. Alarm Reporting and Link Down Indication
Alarm Indication Signal (AIS) message serves the purpose of alarm Alarm Indication Signal (AIS) message serves the purpose of alarm
suppression upon the failure detection in the server (-sub) layer. suppression upon the failure detection in the server (-sub) layer.
When the Link Down Indication (RDI) is set, the AIS message MAY be When the Link Down Indication (RDI) is set, the AIS message MAY be
used to trigger recovery mechanisms. used to trigger recovery mechanisms.
When a server MEP detects the failure, it asserts Loss of Continuity When a server MEP detects the failure, it asserts Loss of Continuity
(LOC) or signal fail which sets the flag up to generate OAM packet (LOC) or signal fail which sets the flag up to generate OAM packet
with AIS message. The AIS message is forwarded to downstream sink with AIS message. The AIS message is forwarded to downstream sink
MEP in the client layer. This would enable the client layer to MEP in the client layer. This would enable the client layer to
skipping to change at page 16, line 38 skipping to change at page 16, line 38
A Link Down Indication (LDI) flag is defined in the AIS message. The A Link Down Indication (LDI) flag is defined in the AIS message. The
LDI flag is set in the AIS message in response to detecting a fatal LDI flag is set in the AIS message in response to detecting a fatal
failure in the server layer. Receipt of an AIS message with this failure in the server layer. Receipt of an AIS message with this
flag set MAY be interpreted by a MEP as an indication of signal fail flag set MAY be interpreted by a MEP as an indication of signal fail
at the client layer. at the client layer.
Fault OAM messages are generated by intermediate nodes where an LSP Fault OAM messages are generated by intermediate nodes where an LSP
is switched, and propagated to the end points (MEPs). is switched, and propagated to the end points (MEPs).
From a practical point of view, when both proactive Continuity Check From a practical point of view, when both proactive Continuity Check
functions and LDI are used, one may consider to run the proactive functions and LDI are used, one may consider running the proactive
Continuity Check functions at a slower rate (e.g. longer BFD hello Continuity Check functions at a slower rate (e.g. longer BFD hello
intervals), and reply on LDI to trigger fast protection switch over intervals), and reply on LDI to trigger fast protection switch over
upon failure detection in a given LSP. upon failure detection in a given LSP.
5.5. Remote Defect Indication 5.5. Remote Defect Indication
Remote Defect Indication (RDI) function enables an End Point to Remote Defect Indication (RDI) function enables an End Point to
report to the other End Point that a fault or defect condition is report to the other End Point that a fault or defect condition is
detected on the PW, LSP, or Section they are the End Points. detected on the PW, LSP, or Section for which they are the End
Points.
The RDI OAM function is supported by the use of Bidirectional The RDI OAM function is supported by the use of Bidirectional
Forwarding Detection (BFD) Control Packets [cc-cv]. RDI is only used Forwarding Detection (BFD) Control Packets [cc-cv]. RDI is only used
for bidirectional connections and is associated with proactive CC-V for bidirectional connections and is associated with proactive CC-V
activation. activation.
When an end point (MEP) detects a signal failure condition, it sets When an end point (MEP) detects a signal failure condition, it sets
the flag up by setting the diagnostic field of the BFD control packet the flag up by setting the diagnostic field of the BFD control packet
to a particular value to indicate the failure condition on the to a particular value to indicate the failure condition on the
associated PW, LSP, or Section, and transmitting the BFD control associated PW, LSP, or Section, and transmitting the BFD control
packet with the failure flag up to the other end point (its peer packet with the failure flag up to the other end point (its peer
MEP). MEP).
RDI function can be used to facilitate the protection switching by The RDI function can be used to facilitate protection switching by
synchronizing the two end points when unidirectional failure occurs synchronizing the two end points when unidirectional failure occurs
and is detected by one end. and is detected by one end.
5.6. Packet Loss and Delay Measurement 5.6. Packet Loss and Delay Measurement
The packet loss and delay measurement toolset enables operators to The packet loss and delay measurement toolset enables operators to
measure the quality of the packet transmission over a PW, LSP, or measure the quality of the packet transmission over a PW, LSP, or
Section. Section.
The loss and delay protocols have the following characteristics and The loss and delay protocols have the following characteristics and
capabilities: capabilities:
o Support measurement of packet loss, delay and throughput over o They support measurement of packet loss, delay and throughput over
Label Switched Paths (LSPs), pseudowires, and MPLS sections. Label Switched Paths (LSPs), pseudowires, and MPLS sections.
o The same LM and DM protocols can be used for both continuous/ o The same LM and DM protocols can be used for both continuous/
proactive and selective/on-demand measurement. proactive and selective/on-demand measurement.
o The LM and DM protocols use a simple query/response model for o The LM and DM protocols use a simple query/response model for
bidirectional measurement that allows a single node - the querier bidirectional measurement that allows a single node - the querier
- to measure the loss or delay in both directions. - to measure the loss or delay in both directions.
o The LM and DM protocols use query messages for unidirectional loss o The LM and DM protocols use query messages for unidirectional loss
skipping to change at page 18, line 15 skipping to change at page 18, line 15
o The LM protocol can be used to measure channel throughput as well o The LM protocol can be used to measure channel throughput as well
as packet loss. as packet loss.
o The DM protocol supports varying the measurement message size in o The DM protocol supports varying the measurement message size in
order to measure delays associated with different packet sizes. order to measure delays associated with different packet sizes.
6. IANA Considerations 6. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
The OAM tools and fucntions defined under G-ACh use IANA assigned The OAM tools and functions defined under G-ACh use IANA assigned
code points. the codes are defined in the corresponding IETF RFCs code points. the codes are defined in the corresponding IETF RFCs
Note to RFC Editor: Note to RFC Editor:
this section may be removed on publication as an RFC. this section may be removed on publication as an RFC.
7. Security Considerations 7. Security Considerations
This document does not by itself raise any particular security This document does not by itself raise any particular security
considerations. Security considerations for each function in the OAM considerations. Security considerations for each function in the OAM
skipping to change at page 19, line 15 skipping to change at page 19, line 15
[LSP Ping] [LSP Ping]
Kompella, K. and G. Swallow, "Detecting Multi-Protocol Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379, Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006. February 2006.
[PW ACH] Bryant, S., Swallow, G., Martini, L., and D. McPherson, [PW ACH] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, February 2006. Use over an MPLS PSN", RFC 4385, February 2006.
[PW VCCV] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007.
[MPLS G-ACH]
Bocci, M., Bryant, S., and M. Vigoureux, "MPLS Generic
Associated Channel", RFC 5586, June 2009.
[MPLS-TP Reqs]
Niven-Jenkins, B., Nadeau, T., and C. Pignataro,
"Requirements for the Transport Profile of MPLS",
RFC 5654, April 2009.
[MPLS-TP OAM Reqs]
Vigoureux, M., Betts, M., and D. Ward, "Requirements for
OAM in MPLS Transport Networks", RFC 5860, April 2009.
[BASE BFD] [BASE BFD]
Katz, D. and D. Ward, "Bidirectional Forwarding Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", RFC 5880, February 2009. Detection", RFC 5880, February 2009.
[MPLS BFD] [MPLS BFD]
Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"BFD For MPLS LSPs", RFC 5884, June 2008. "BFD For MPLS LSPs", RFC 5884, June 2008.
[PW VCCV] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007.
[MPLS TP Idents] [MPLS TP Idents]
Bocci, M., Swallow, G., and E. Gray, "MPLS-TP Bocci, M., Swallow, G., and E. Gray, "MPLS-TP
Identifiers", RFC 6370, September 2011. Identifiers", RFC 6370, September 2011.
[MPLS-TP OAM Frwk]
Busi, I., Niven-Jenkins, B., and D. Allan, "MPLS-TP OAM
Framework and Overview", RFC 6371, September 2011.
[Loss-Delay]
Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, September 2011.
[TP-Loss-Delay-Profile]
Frost, D. and S. Bryant, "A Packet Loss and Delay
Measurement Profile for MPLS-based Transport Networks",
RFC 6375, September 2011.
[Pro CC-V] [Pro CC-V]
Allan, D. and G. Swallow, "Proactive Connection Allan, D. and G. Swallow, "Proactive Connectivity
Verification, Continuity Check and Remote Defect Verification, Continuity Check and Remote Defect
indication for MPLS Transport Profile", indication for MPLS Transport Profile",
ID draft-ietf-mpls-tp-cc-cv-rdi-06, August 2011. ID draft-ietf-mpls-tp-cc-cv-rdi-06, August 2011.
[Demand CV] [Demand CV]
Bahadur, N., Aggarwal, R., Boutros, S., and E. Gray, "MPLS Bahadur, N., Aggarwal, R., Boutros, S., and E. Gray, "MPLS
on-demand Connectivity Verification, Route Tracing and on-demand Connectivity Verification, Route Tracing and
Adjacency Verification", Adjacency Verification",
ID draft-ietf-mpls-tp-on-demand-cv-06, August 2011. ID draft-ietf-mpls-tp-on-demand-cv-06, August 2011.
[MPLS-TP OAM Reqs]
Vigoureux, M., Betts, M., and D. Ward, "Requirements for
OAM in MPLS Transport Networks", RFC 5860, April 2009.
[MPLS-TP OAM Frwk]
Busi, I., Niven-Jenkins, B., and D. Allan, "MPLS-TP OAM
Framework and Overview", RFC 6371, September 2011.
[MPLS-TP Reqs]
Niven-Jenkins, B., Nadeau, T., and C. Pignataro,
"Requirements for the Transport Profile of MPLS",
RFC 5654, April 2009.
[MPLS G-ACH]
Bocci, M., Bryant, S., and M. Vigoureux, "MPLS Generic
Associated Channel", RFC 5586, June 2009.
[Fault Mng] [Fault Mng]
Swallow, G., Fulignoli, A., and M. Vigoureux, "MPLS Fault Swallow, G., Fulignoli, A., and M. Vigoureux, "MPLS Fault
Management OAM", ID draft-ietf-mpls-tp-fault-07, Management OAM", ID draft-ietf-mpls-tp-fault-07,
September 2011. September 2011.
[LiLoopback] [LiLoopback]
Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M.,
and X. Dai, "MPLS Transport Profile Lock Instruct and and X. Dai, "MPLS Transport Profile Lock Instruct and
Loopback Functions", ID draft-ietf-mpls-tp-li-lb-05, Loopback Functions", ID draft-ietf-mpls-tp-li-lb-05,
September 2011. September 2011.
[MPLS-TP CSF]
He, J., LI, H., and E. Bellagamba, "Indication of Client
Failure in MPLS-TP", ID draft-ietf-mpls-tp-csf-02,
September 2011.
[Loss-Delay]
Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, September 2011.
[TP-Loss-Delay-Profile]
Frost, D. and S. Bryant, "A Packet Loss and Delay
Measurement Profile for MPLS-based Transport Networks",
RFC 6375, September 2011.
9.2. Informative References 9.2. Informative References
[MPLS-TP Security Frwk] [MPLS-TP Security Frwk]
Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP
Security Framework", Security Framework",
ID draft-ietf-mpls-tp-security-framework-01, May 2011. ID draft-ietf-mpls-tp-security-framework-01, May 2011.
[MPLS and GMPLS Security Frwk] [MPLS and GMPLS Security Frwk]
Fang, L., "Security Framework for MPLS and GMPLS Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
[Y.1731] International Telecommunications Union - Standardization, [Y.1731] International Telecommunications Union - Standardization,
"OAM functions and mechanisms for Ethernet based "OAM functions and mechanisms for Ethernet based
networks", ITU Y.1731, May 2006. networks", ITU Y.1731, May 2006.
[MPLS TP ITU Idents]
Winter, R., van Helvoort, H., and M. Betts, "MPLS-TP
Identifiers Following ITU-T Conventions",
ID draft-ietf-mpls-tp-itu-t-identifiers-00, July 2011.
Authors' Addresses Authors' Addresses
Nurit Sprecher Nurit Sprecher
Nokia Siemens Networks Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B 3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241 Hod Hasharon, 45241
Israel Israel
Email: nurit.sprecher@nsn.com Email: nurit.sprecher@nsn.com
 End of changes. 38 change blocks. 
99 lines changed or deleted 93 lines changed or added

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