summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6669.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6669.txt')
-rw-r--r--doc/rfc/rfc6669.txt1179
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc6669.txt b/doc/rfc/rfc6669.txt
new file mode 100644
index 0000000..e00816b
--- /dev/null
+++ b/doc/rfc/rfc6669.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) N. Sprecher
+Request for Comments: 6669 Nokia Siemens Networks
+Category: Informational L. Fang
+ISSN: 2070-1721 Cisco Systems
+ July 2012
+
+
+ An Overview of the Operations, Administration, and Maintenance (OAM)
+ Toolset for MPLS-Based Transport Networks
+
+Abstract
+
+ This document provides an overview of the Operations, Administration,
+ and Maintenance (OAM) toolset for MPLS-based transport networks. The
+ toolset consists of a comprehensive set of fault management and
+ performance monitoring capabilities (operating in the data plane)
+ that are appropriate for transport networks as required in RFC 5860
+ and support the network and services at different nested levels.
+ This overview includes a brief recap of the MPLS Transport Profile
+ (MPLS-TP) OAM requirements and functions and the generic mechanisms
+ created in the MPLS data plane that allow the OAM packets to run
+ in-band and share their fate with data packets. The protocol
+ definitions for each of the MPLS-TP OAM tools are defined in separate
+ documents (RFCs or Working Group documents), which are referenced by
+ this document.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any
+ errata, and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6669.
+
+
+
+
+
+
+
+
+
+
+Sprecher & Fang Informational [Page 1]
+
+RFC 6669 OAM Toolset July 2012
+
+
+Copyright Notice
+
+ Copyright (c) 2012 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sprecher & Fang Informational [Page 2]
+
+RFC 6669 OAM Toolset July 2012
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 1.1. Scope ......................................................4
+ 1.2. Acronyms ...................................................5
+ 2. Basic OAM Infrastructure Functionality ..........................6
+ 3. MPLS-TP OAM Functions ...........................................8
+ 3.1. Continuity Check and Connectivity Verification .............8
+ 3.1.1. Documents for CC-CV Tools ...........................8
+ 3.2. Remote Defect Indication ...................................8
+ 3.2.1. Documents for RDI ...................................9
+ 3.3. Route Tracing ..............................................9
+ 3.3.1. Documents for Route Tracing .........................9
+ 3.4. Alarm Reporting ............................................9
+ 3.4.1. Documents for Alarm Reporting .......................9
+ 3.5. Lock Instruct ..............................................9
+ 3.5.1. Documents for Lock Instruct ........................10
+ 3.6. Lock Reporting ............................................10
+ 3.6.1. Documents for Lock Reporting .......................10
+ 3.7. Diagnostic ................................................10
+ 3.7.1. Documents for Diagnostic Testing ...................10
+ 3.8. Packet Loss Measurement ...................................10
+ 3.8.1. Documents for Packet Loss Measurement ..............11
+ 3.9. Packet Delay Measurement ..................................11
+ 3.9.1. Documents for Delay Measurement ....................11
+ 4. MPLS-TP OAM Documents Guide ....................................12
+ 5. OAM Toolset Applicability and Utilization ......................13
+ 5.1. Connectivity Check and Connectivity Verification ..........14
+ 5.2. Diagnostic Tests and Lock Instruct ........................14
+ 5.3. Lock Reporting ............................................15
+ 5.4. Alarm Reporting and Link Down Indication ..................15
+ 5.5. Remote Defect Indication ..................................16
+ 5.6. Packet Loss and Delay Measurement .........................17
+ 6. Security Considerations ........................................18
+ 7. Acknowledgements ...............................................18
+ 8. References .....................................................19
+ 8.1. Normative References ......................................19
+ 8.2. Informative References ....................................20
+ Contributors ......................................................21
+
+
+
+
+
+
+
+
+
+
+
+
+Sprecher & Fang Informational [Page 3]
+
+RFC 6669 OAM Toolset July 2012
+
+
+1. Introduction
+
+1.1. Scope
+
+ The MPLS Transport Profile (MPLS-TP) architectural framework is
+ defined in [RFC5921], and it describes a common set of protocol
+ functions that supports the operational models and capabilities
+ typical of such transport networks.
+
+ Operations, Administration, and Maintenance (OAM) plays a significant
+ role in carrier networks. It provides methods for fault management
+ and performance monitoring in both the transport and service layers,
+ in order to improve their ability to support services with guaranteed
+ and strict Service Level Agreements (SLAs) while reducing their
+ operational costs.
+
+ [RFC5654], in general, and [RFC5860], in particular, define a set of
+ requirements for the OAM functionality for MPLS-TP Label Switched
+ Paths (LSPs), Pseudowires (PWs), and Sections.
+
+ The OAM solution, developed by the joint IETF and ITU-T MPLS-TP
+ project, has three objectives:
+
+ o The OAM toolset should be developed based on existing MPLS
+ architecture, technology, and toolsets.
+
+ o The OAM operational experience should be similar to that in other
+ transport networks.
+
+ o The OAM toolset developed for MPLS-based transport networks needs
+ to be fully interoperable with existing MPLS OAM tools as
+ documented in Section 2.1.5. of [RFC5860].
+
+ The MPLS-TP OAM toolset is based on the following existing tools:
+
+ o LSP ping, as defined in [RFC4379].
+
+ o Bidirectional Forwarding Detection (BFD), as defined in [RFC5880]
+ and refined in [RFC5884].
+
+ o ITU-T OAM for the Ethernet toolset, as defined in [Y.1731]. This
+ has been used as functionality guidelines for the performance
+ measurement tools that were not previously supported in MPLS.
+
+ Note that certain extensions and adjustments have been specified,
+ relative to the existing MPLS tools, in order to conform to the
+ transport environment and the requirements of MPLS-TP. However,
+ compatibility with the existing MPLS tools has been maintained.
+
+
+
+Sprecher & Fang Informational [Page 4]
+
+RFC 6669 OAM Toolset July 2012
+
+
+ This document provides an overview of the MPLS-TP OAM toolset, which
+ consists of tools for MPLS-TP fault management and performance
+ monitoring. This overview includes a brief recap of MPLS-TP OAM
+ requirements, their functions, and the generic mechanisms used to
+ support the MPLS-TP OAM operation.
+
+ The protocol definitions for individual MPLS-TP OAM tools are
+ specified in separate RFCs (or Working Group documents), which are
+ referenced by this document.
+
+ In addition, this document includes a table that cross-references the
+ solution documents of the OAM functionality supported. Finally, the
+ document presents the applicability and utilization of each tool in
+ the MPLS-TP OAM toolset.
+
+1.2. Acronyms
+
+ This document uses the following acronyms:
+
+ ACH Associated Channel Header
+ AIS Alarm Indication Signal
+ BFD Bidirectional Forwarding Detection
+ CC-CV Continuity Check and Connectivity Verification
+ DM Delay Measurement
+ FM Fault Management
+ G-ACh Generic Associated Channel
+ GAL G-ACh Label
+ GMPLS Generalized Multiprotocol Label Switching
+ IANA Internet Assigned Numbers Authority
+ LDI Link Down Indication
+ LKR Lock Report
+ LM Loss Measurement
+ LOC Loss of Continuity
+ LSP Label Switched Path
+ MEP Maintenance Entity Group End Point
+ MEG Maintenance Entity Group
+ MIP Maintenance Entity Group Intermediate Point
+ MPLS Multiprotocol Label Switching
+ MPLS-TP Transport Profile for MPLS
+ OAM Operations, Administration, and Maintenance
+ PM Performance Monitoring
+ PW Pseudowire
+ RDI Remote Defect Indication
+ SLA Service Level Agreement
+ TLV Type, Length, Value
+ VCCV Virtual Circuit Connectivity Verification
+
+
+
+
+
+Sprecher & Fang Informational [Page 5]
+
+RFC 6669 OAM Toolset July 2012
+
+
+2. Basic OAM Infrastructure Functionality
+
+ [RFC5860] defines a set of requirements for OAM architecture and
+ general principles of operations, which are evaluated below:
+
+ [RFC5860] requires that --
+
+ o OAM mechanisms in MPLS-TP are independent of the transmission
+ media and the client service being emulated by the PW ([RFC5860],
+ Section 2.1.2).
+
+ o MPLS-TP OAM must be able to support both an IP-based and non-IP-
+ based environment. If the network is IP based, i.e., IP routing
+ and forwarding are available, then it must be possible to choose
+ to make use of IP capabilities. On the other hand, in
+ environments where IP functionality is not available, the OAM
+ tools must still be able to operate independent of IP forwarding
+ and routing ([RFC5860], Section 2.1.4). It is required to have
+ OAM interoperability between distinct domains materializing the
+ environments ([RFC5860], Section 2.1.5).
+
+ o All OAM protocols support identification information, at least in
+ the form of IP addressing structure, and are extensible to support
+ additional identification schemes ([RFC5860], Section 2.1.4).
+
+ 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
+ packets from user-plane packets [RFC5860], Section 2.1.3.
+ Inherent in this requirement is the principle that full operation
+ of the MPLS-TP OAM must be possible independently of the control
+ or management plane used to operate the network [RFC5860], Section
+ 2.1.3.
+
+ o MPLS-TP OAM supports point-to-point bidirectional PWs, point-to-
+ point co-routed bidirectional LSPs, and point-to-point
+ bidirectional Sections ([RFC5860], Section 2.1.1). The
+ applicability of particular MPLS-TP OAM functions to point-to-
+ point associated bidirectional LSPs, point-to-point unidirectional
+ LSPs, and point-to-multipoint LSPs, is described in [RFC5860],
+ Section 2.2. In addition, MPLS-TP OAM supports these LSPs and PWs
+ when they span either single or multiple domains ([RFC5860],
+ Section 2.1.1).
+
+ o OAM packets may be directed to an intermediate point of an LSP/PW
+ ([RFC5860], Sections 2.2.3, 2.2.4, and 2.2.5).
+
+
+
+
+
+
+Sprecher & Fang Informational [Page 6]
+
+RFC 6669 OAM Toolset July 2012
+
+
+ [RFC5860], Section 2.2 recommends that any protocol solution meeting
+ one or more functional requirement(s) be the same for PWs, LSPs, and
+ Sections.
+
+ The following document set addresses the basic requirements listed
+ above:
+
+ o [RFC6371] describes the architectural framework for conformance to
+ the basic requirements listed above. It also defines the basic
+ relationships between the MPLS structures, e.g., LSP, PW, and the
+ structures necessary for OAM functionality, i.e., the Maintenance
+ Entity Group (MEG), its end points, and intermediate points.
+
+ o [RFC5586] specifies the use of the MPLS-TP in-band control
+ channels. It generalizes the applicability of the PW ACH to MPLS
+ LSPs and Sections by defining a Generic Associated Channel
+ (G-ACh). The G-ACh allows control packets to be multiplexed
+ transparently over LSPs and Sections similar to that of PW VCCV
+ [RFC5085]. The Generic Association Label (GAL) is defined by
+ assigning a reserved MPLS label value and is used to identify the
+ OAM control packets. The value of the ACH Channel Type field
+ indicates the specific protocol carried on the associated control
+ channel. Each MPLS-TP OAM protocol has an IANA-assigned channel
+ type allocated to it.
+
+ [RFC5085] defines an Associated Channel Header (ACH) that provides a
+ PW associated control channel between a PW's end points, over which
+ OAM and other control messages can be exchanged. [RFC5586]
+ generalizes the PW Associated Channel Header (ACH) to provide common
+ in-band control channels also at the LSP and MPLS-TP link levels.
+ The G-ACh allows control packets to be multiplexed transparently over
+ the same LSP or MPLS-TP link as in PW VCCV. Multiple control
+ channels can exist between end points.
+
+ [RFC5085] also defines a label-based exception mechanism that helps a
+ Label Switching Router (LSR) to identify the control packets and
+ direct them to the appropriate entity for processing. The use of
+ G-ACh and GAL provides the necessary mechanisms to allow OAM packets
+ to run in-band and share their fate with data packets. It is
+ expected that all of the OAM protocols will be used in conjunction
+ with this Generic Associated Channel.
+
+ o [RFC6370] provides an IP-based identifier set for MPLS-TP that can
+ be used to identify the transport entities in the network and
+ referenced by the different OAM protocols.
+
+
+
+
+
+
+Sprecher & Fang Informational [Page 7]
+
+RFC 6669 OAM Toolset July 2012
+
+
+ Note: [MPLS-TP-ITU-Idents] augments that set of identifiers to
+ include identifier information in a format used by the ITU-T.
+ Other identifier sets may be defined as well.
+
+3. MPLS-TP OAM Functions
+
+ The following sections discuss the OAM functions that are required in
+ [RFC5860] and expanded upon in [RFC6371].
+
+3.1. Continuity Check and Connectivity Verification
+
+ Continuity Check and Connectivity Verification (CC-CV) are OAM
+ operations generally used in tandem and complement each other. These
+ functions are generally run proactively, but may also be used
+ on-demand for diagnoses of a specific condition. [RFC5860] states
+ that the function should allow the MEPs to proactively monitor the
+ liveliness and connectivity of a transport path (LSP, PW, or a
+ Section) between them. In on-demand mode, this function should
+ support monitoring between the MEPs and between a MEP and MIP. Note
+ that as specified in [RFC6371], Sections 3.3 and 3.4, a MEP and a MIP
+ can reside in an unspecified location within a node, or in a
+ particular interface on a specific side of the forwarding engine.
+
+ [RFC6371] highlights the need for the CC-CV messages to include
+ unique identification of the MEG that is being monitored and the MEP
+ that originated the message. The function, both proactively and in
+ on-demand mode, needs to be transmitted at regular transmission rates
+ pre-configured by the operator.
+
+3.1.1. Documents for CC-CV Tools
+
+ [RFC6428] defines BFD extensions to support proactive CC-CV
+ applications.
+
+ [RFC6426] provides LSP ping extensions that are used to implement
+ on-demand connectivity verification.
+
+ Both of these tools will be used within the basic functionality
+ framework described in Section 2.
+
+3.2. Remote Defect Indication
+
+ Remote Defect Indication (RDI) is used by a path end point to report
+ that a defect is detected on a bidirectional connection to its peer
+ end point. [RFC5860] points out that this function may be applied to
+ a unidirectional LSP only if a return path exists. [RFC6371] points
+ out that this function is associated with the proactive CC-CV
+ function.
+
+
+
+Sprecher & Fang Informational [Page 8]
+
+RFC 6669 OAM Toolset July 2012
+
+
+3.2.1. Documents for RDI
+
+ [RFC6428] provides an extension for BFD that includes the RDI
+ indication in the BFD format and a specification of how this
+ indication is to be used.
+
+3.3. Route Tracing
+
+ [RFC5860] defines the need for functionality that would allow a path
+ end point to identify the intermediate points (if any) and end
+ point(s) along the path (LSP, PW, or a Section). This function would
+ be used in on-demand mode. Normally, this path will be used for
+ bidirectional PW, LSP, and Sections; however, unidirectional paths
+ may be supported only if a return path exists.
+
+3.3.1. Documents for Route Tracing
+
+ [RFC6426] specifies that the LSP ping enhancements for MPLS-TP on-
+ demand connectivity verification include information on the use of
+ LSP ping for route tracing of an MPLS-TP path.
+
+3.4. Alarm Reporting
+
+ Alarm Reporting is a function used by an intermediate point of a path
+ (LSP or PW) to report to the end points of the path that a fault
+ exists on the path. [RFC6371] states that this may occur as a result
+ of a defect condition discovered at a server layer. The intermediate
+ point generates an Alarm Indication Signal (AIS) that continues until
+ the fault is cleared. The consequent action of this function is
+ detailed in [RFC6371].
+
+3.4.1. Documents for Alarm Reporting
+
+ MPLS-TP defines a new protocol to address this functionality that is
+ documented in [RFC6427]. This protocol uses all of the basic
+ mechanisms detailed in Section 2.
+
+3.5. Lock Instruct
+
+ The Lock Instruct function is an administrative control tool that
+ 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-
+ side provisioning for administrative locking, according to [RFC6371].
+ This function is used on-demand.
+
+
+
+
+
+
+
+Sprecher & Fang Informational [Page 9]
+
+RFC 6669 OAM Toolset July 2012
+
+
+3.5.1. Documents for Lock Instruct
+
+ [RFC6435] describes the details of a new ACH-based protocol format
+ for this functionality.
+
+3.6. Lock Reporting
+
+ Lock Reporting, defined in [RFC5860], is similar to the Alarm
+ Reporting function described above. It is used by an intermediate
+ point to notify the end points of a transport path (LSP or PW) that
+ an administrative lock condition exists for the transport path.
+
+3.6.1. Documents for Lock Reporting
+
+ MPLS-TP defines a new protocol to address this functionality that is
+ documented in [RFC6427]. This protocol uses all the basic mechanisms
+ detailed in Section 2.
+
+3.7. Diagnostic
+
+ [RFC5860] indicates a need to provide an OAM function that would
+ enable conducting different diagnostic tests on a PW, LSP, or
+ Section. [RFC6371] provides two types of specific tests to be used
+ through this functionality:
+
+ o Throughput estimation - allowing the provider to verify the
+ bandwidth/throughput of a transport path. This is an out-of-
+ service tool that uses special packets of varying sizes to test
+ the actual bandwidth and/or throughput of the path.
+
+ o Data-plane loopback - this out-of-service tool causes all traffic
+ that reaches the target node, either a MEP or MIP, to be looped
+ back to the originating MEP. For targeting MIPs, a co-routed
+ bidirectional path is required.
+
+3.7.1. Documents for Diagnostic Testing
+
+ [RFC6435] describes the details of a new ACH-based protocol format
+ for the data-plane loopback functionality.
+
+ The tool for throughput estimation is under study.
+
+3.8. Packet Loss Measurement
+
+ Packet Loss Measurement is required by [RFC5860] to provide 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 of
+ user packets during a defined time interval. To employ this
+
+
+
+Sprecher & Fang Informational [Page 10]
+
+RFC 6669 OAM Toolset July 2012
+
+
+ function, [RFC6371] defines that the two end points of the transport
+ path should exchange counters of messages transmitted and received
+ within a time period bounded by loss-measurement messages. The
+ framework warns that there may be small errors in the computation,
+ which result from various issues.
+
+3.8.1. Documents for Packet Loss Measurement
+
+ [RFC6374] describes the protocol formats and procedures for using the
+ tool and enabling efficient and accurate measurement of packet loss,
+ delay, and throughput in MPLS networks. [RFC6375] describes a
+ profile of the general MPLS loss, delay, and throughput measurement
+ techniques that suffice 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.9. Packet Delay Measurement
+
+ Packet Delay Measurement is a function that is used to measure the
+ one-way or two-way delay of packet transmission between a pair of the
+ end points of a path (PW, LSP, or Section), as described in
+ [RFC5860], where:
+
+ 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
+ the reception of the last bit of that packet by the destination
+ node.
+
+ 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
+ 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
+ destination node.
+
+ [RFC6371] describes how the tool could be used (both in proactive and
+ on-demand modes) for either one-way or two-way measurement. However,
+ it warns that the one-way delay option requires precise time
+ synchronization between the end points.
+
+3.9.1. Documents for Delay Measurement
+
+ [RFC6374] describes the protocol formats and procedures for using the
+ tool and enabling efficient and accurate measurement of packet loss,
+ delay, and throughput in MPLS networks. [RFC6375] 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].
+
+
+
+Sprecher & Fang Informational [Page 11]
+
+RFC 6669 OAM Toolset July 2012
+
+
+4. MPLS-TP OAM Documents Guide
+
+ 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
+ the future to cover additional OAM functionality. In order to allow
+ the reader to understand this set of documents, a cross-reference of
+ the existing documents (RFCs or Working Group documents) for the
+ initial phase of the specification of MPLS-based transport networks
+ is provided below.
+
+ [RFC5586] provides a specification of the basic structure of protocol
+ messages for in-band data-plane OAM in an MPLS environment.
+
+ [RFC6370] provides definitions of different formats that may be used
+ within OAM protocol messages to identify the network elements of an
+ MPLS-based transport network.
+
+ The following table (Table 1) provides the summary of proactive MPLS-
+ TP OAM Fault Management toolset functions, the associated
+ tool/protocol, and the corresponding RFCs in which they are defined.
+
+ +--------------------------+-------------------------------+---------+
+ | OAM Functions | OAM Tools/Protocols | RFCs |
+ +--------------------------+-------------------------------+---------+
+ | Continuity Check and | Bidirectional Forwarding |[RFC6428]|
+ | Connectivity | Detection (BFD) | |
+ | Verification | | |
+ +--------------------------+-------------------------------+---------+
+ | Remote Defect Indication | Flag in Bidirectional |[RFC6428]|
+ | (RDI) | Forwarding Detection (BFD) | |
+ | | message | |
+ +--------------------------+-------------------------------+---------+
+ | Alarm Indication Signal | G-ACh-based AIS message |[RFC6427]|
+ | (AIS) | | |
+ +--------------------------+-------------------------------+---------+
+ | Link Down Indication | Flag in AIS message |[RFC6427]|
+ | (LDI) | | |
+ +--------------------------+-------------------------------+---------+
+ | Lock Reporting (LKR) | G-ACh-based LKR message |[RFC6427]|
+ | | | |
+ +--------------------------+-------------------------------+---------+
+
+ Table 1. Proactive Fault Management OAM Toolset
+
+
+
+
+
+
+
+
+Sprecher & Fang Informational [Page 12]
+
+RFC 6669 OAM Toolset July 2012
+
+
+ The following table (Table 2) provides an overview of the on-demand
+ MPLS-TP OAM Fault Management toolset functions, the associated
+ tool/protocol, and the corresponding RFCs in which they are defined.
+
+ +------------------------+---------------------------------+---------+
+ | OAM Functions | OAM Tools/Protocols | RFCs |
+ +------------------------+---------------------------------+---------+
+ | Connectivity | LSP Ping |[RFC6426]|
+ | Verification | | |
+ +------------------------+---------------------------------+---------+
+ | Lock Instruct (LI) | (1) G-ACh-based Loopback, |[RFC6426]|
+ | | (2) Lock Instruct (LI) | |
+ +------------------------+---------------------------------+---------+
+ | Lock Report (LKR) | Flag in AIS message |[RFC6426]|
+ | | | |
+ +------------------------+---------------------------------+---------+
+
+ Table 2. On Demand Fault Management OAM Toolset
+
+ The following table (Table 3) provides the Performance Monitoring
+ Functions, the associated tool/protocol definitions, and the
+ corresponding RFCs in which they are defined.
+
+ +----------------------+--------------------------+-----------------+
+ | OAM Functions | OAM Tools/Protocols | RFCs |
+ +----------------------+--------------------------+-----------------+
+ | Packet Loss | G-ACh-based LM & DM | [RFC6374] |
+ | Measurement (LM) | query messages | [RFC6375] |
+ +----------------------+--------------------------+-----------------+
+ | Packet Delay | G-ACh-based LM & DM | [RFC6374] |
+ | Measurement (DM) | query messages | [RFC6375] |
+ +----------------------+--------------------------+-----------------+
+ | Throughput | derived from Loss | [RFC6374] |
+ | Measurement | Measurement | [RFC6375] |
+ +----------------------+--------------------------+-----------------+
+ | Delay Variation | derived from Delay | [RFC6374] |
+ | Measurement | Measurement | [RFC6375] |
+ +----------------------+--------------------------+-----------------+
+
+ Table 3. Performance Monitoring OAM Toolset
+
+5. OAM Toolset Applicability and Utilization
+
+ The following subsections present the MPLS-TP OAM toolset from the
+ perspective of the specified protocols and identifies the required
+ functionality that is supported by the particular protocol.
+
+
+
+
+
+Sprecher & Fang Informational [Page 13]
+
+RFC 6669 OAM Toolset July 2012
+
+
+5.1. Connectivity Check and Connectivity Verification
+
+ Proactive Continuity Check and Connectivity Verification (CC-CV)
+ functions are used to detect loss of continuity (LOC) and unintended
+ connectivity between two MEPs. Loss of connectivity, mis-merging,
+ mis-connectivity, or unexpected Maintenance Entity Group End Points
+ (MEPs) can be detected using the CC-CV tools. See Sections 3.1, 3.2,
+ 3.3 in this document for CC-CV protocol references.
+
+ The CC-CV tools are used to support MPLS-TP fault management,
+ performance management, and protection switching. Proactive CC-CV
+ control packets are sent by the source MEP to the sink MEP. The
+ sink-MEP monitors the arrival of the CC-CV control packets and
+ detects the defect. For bidirectional transport paths, the CC-CV
+ protocol is usually transmitted simultaneously in both directions.
+
+ The transmission interval of the CC-CV control packets can be
+ configured. For example:
+
+ o 3.3 ms is the default interval for protection switching.
+
+ o 100 ms is the default interval for performance monitoring.
+
+ o 1 s is the default interval for fault management.
+
+5.2. Diagnostic Tests and Lock Instruct
+
+ [RFC6435] describes a protocol that provides a mechanism to Lock and
+ Unlock traffic (e.g., data and control traffic or specific OAM
+ traffic) at a specific LSR on the path of the MPLS-TP LSP to allow
+ loopback of the traffic to the source.
+
+ These diagnostic functions apply to associated bidirectional MPLS-TP
+ LSPs, including MPLS-TP LSPs, bidirectional RSVP-Traffic Engineering
+ (RSVP-TE) tunnels (which is relevant for the MPLS-TP dynamic control-
+ plane option with GMPLS), and single-segment and multi-segment
+ Pseudowires. [RFC6435] provides the protocol definition for
+ diagnostic tests functions.
+
+ [RFC6435] defines a mechanism where a lock instruction is sent by a
+ management application to both ends of a point-to-point LSP,
+ requesting them to take the LSP out-of-service. When an end point
+ gets the management request, it locks the LSP and sends a Lock
+ Instruct message to the other end of the LSP. The Lock Instruct
+ message is carried in a Generic ACH message and is sent periodically.
+ The time between successive messages is no longer than the value set
+ in the Refresh Timer field of the Lock Instruct message. An LSP end
+ point keeps the LSP locked while it is either receiving the periodic
+
+
+
+Sprecher & Fang Informational [Page 14]
+
+RFC 6669 OAM Toolset July 2012
+
+
+ Lock Instruct messages or has an in-force lock instruction from the
+ management application.
+
+ Note that since the management application will receive a management
+ plane response from both ends of the LSP confirming that the LSP has
+ been locked, there is no requirement for the Lock Instruct message to
+ have a response. Therefore, [RFC6435] does not define a Lock
+ Instruct response message.
+
+ The loopback operations include:
+
+ o Lock: take an LSP out of service for maintenance.
+
+ o Unlock: Restore a previously locked LSP to service.
+
+ o Set_Full_Loopback and Set_OAM_Loopback.
+
+ o Unset_Full_Loopback and Set_OAM_Loopback.
+
+ Operators can use the loopback mode to test the connectivity or
+ performance (loss, delay, delay variation, and throughput) of a given
+ LSP up to a specific node on the path of the LSP.
+
+5.3. Lock Reporting
+
+ The Lock Report (LKR) function is used to communicate to the MEPS of
+ the client (sub-)layer MEPs the administrative locking of a server
+ (sub-)layer MEP, and consequential interruption of data traffic
+ forwarding in the client layer. See Section 3.6 in this document for
+ Lock Reporting protocol references.
+
+ When an operator is taking the LSP out of service for maintenance or
+ another operational reason, using the LKR function can help to
+ distinguish the condition as administrative locking from a defect
+ condition.
+
+ The Lock Report function may also serve the purpose of alarm
+ suppression in the MPLS-TP network above the level at which the Lock
+ has occurred. The receipt of an LKR message may be treated as the
+ equivalent of the loss of continuity at the client layer.
+
+5.4. Alarm Reporting and Link Down Indication
+
+ Alarm Indication Signal (AIS) message is used to suppress alarms
+ following detection of defect conditions at the server (sub-)layer.
+ When the Link Down Indication (LDI) is set, the AIS message may be
+ used to trigger recovery mechanisms.
+
+
+
+
+Sprecher & Fang Informational [Page 15]
+
+RFC 6669 OAM Toolset July 2012
+
+
+ When a server MEP detects the failure, it asserts LOC or signal fail,
+ which sets the flag up to generate an OAM packet with the AIS
+ message. The AIS message is forwarded to the downstream sink MEP in
+ the client layer. This enables the client layer to suppress the
+ generation of secondary alarms.
+
+ An LDI flag is defined in the AIS message. The 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 flag set may be
+ interpreted by a MEP as an indication of signal fail at the client
+ layer.
+
+ The protocols for AIS and LDI are defined in [RFC6427].
+
+ Fault OAM messages are generated by intermediate nodes where an LSP
+ is switched and propagated to the end points (MEPs).
+
+ From a practical point of view, when both proactive Continuity Check
+ functions and LDI are used, one may consider running the proactive
+ Continuity Check functions at a slower rate (e.g., longer BFD hello
+ intervals), and reply on LDI to trigger fast protection switch over
+ upon failure detection in a given LSP.
+
+5.5. Remote Defect Indication
+
+ The Remote Defect Indication (RDI) function enables an end point to
+ report to its peer end point that a fault or defect condition is
+ detected on the PW, LSP, or Section.
+
+ The RDI OAM function is supported by the use of BFD control packets
+ [RFC6428]. RDI is only used for bidirectional connections and is
+ associated with proactive CC-CV activation.
+
+ 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
+ to a particular value to indicate the failure condition on the
+ associated PW, LSP, or Section. Additionally, the BFD control packet
+ is transmitted with the failure flag up to the other end point (its
+ peer MEP).
+
+ The RDI function can be used to facilitate protection switching by
+ synchronizing the two end points when unidirectional failure occurs
+ and is detected by one end.
+
+
+
+
+
+
+
+
+Sprecher & Fang Informational [Page 16]
+
+RFC 6669 OAM Toolset July 2012
+
+
+5.6. Packet Loss and Delay Measurement
+
+ The packet loss and delay measurement toolset enables operators to
+ measure the quality of the packet transmission over a PW, LSP, or
+ Section. Section 3.8 in this document defines the protocols for
+ packet loss measurement, and Section 3.9 defines the protocols for
+ packet delay measurement.
+
+ The loss and delay protocols have the following characteristics and
+ capabilities:
+
+ o They support the measurement of packet loss, delay, and throughput
+ over Label Switched Paths (LSPs), Pseudowires, and MPLS Sections.
+
+ o The same LM and DM protocols can be used for both
+ continuous/proactive and selective/on-demand measurements.
+
+ o The LM and DM protocols use a simple query/response model for
+ bidirectional measurement that allows a single node -- the querier
+ -- to measure the loss or delay in both directions.
+
+ o The LM and DM protocols use query messages for unidirectional loss
+ and delay measurement. The measurement can either be carried out
+ at the downstream node(s), or at the querier if an out-of-band
+ return path is available.
+
+ o The LM and DM protocols do not require that the transmit-and-
+ receive interfaces be the same when performing bidirectional
+ measurement.
+
+ o The LM supports test-message-based measurement (i.e., inferred
+ mode) as well as measurement based on data-plane counters (i.e.,
+ direct mode).
+
+ o The LM protocol supports both 32-bit and 64-bit counters.
+
+ o The LM protocol supports measurement in terms of both packet
+ counts and octet counts; although for simplicity, only packet
+ counters are currently included in the MPLS-TP profile.
+
+ o The LM protocol can be used to measure channel throughput as well
+ as packet loss.
+
+ o The DM protocol supports varying the measurement message size in
+ order to measure delays associated with different packet sizes.
+
+ o The DM protocol uses IEEE 1588 timestamps [IEEE1588] by default
+ but also supports other timestamp formats, such as NTP.
+
+
+
+Sprecher & Fang Informational [Page 17]
+
+RFC 6669 OAM Toolset July 2012
+
+
+6. Security Considerations
+
+ This document, as an overview of MPLS OAM tools, does not by itself
+ raise any particular security considerations.
+
+ The general security considerations are provided in [RFC5920] and
+ [MPLS-TP-SEC]. Security considerations for each function within the
+ OAM toolset have been recorded in each document that specifies a
+ particular functionality.
+
+ In general, OAM is always an area where the security risk is high.
+ For example, confidential information may be intercepted by attackers
+ to gain access to networks; therefore, authentication, authorization,
+ and encryption must be enforced to prevent security breaches.
+
+ It is also important to strictly follow operational security
+ procedures. For example, in the case of MPLS-TP static provisioning,
+ the operator interacts directly with the Network Management System
+ (NMS) and devices, and it is critical in order to prevent human
+ errors and malicious attacks.
+
+ Since MPLS-TP OAM uses G-ACh, the security risks and mitigations
+ described in [RFC5085] also apply here. In short, messages on the
+ G-ACh could be intercepted, or false G-ACh packets could be inserted.
+
+ Additionally, DoS attacks can be mounted by flooding G-ACh messages
+ to peer devices. To mitigate this type of attack, throttling
+ mechanisms or rate limits can be used. For more details, please see
+ [RFC5085].
+
+7. Acknowledgements
+
+ The authors would like to thank the MPLS-TP experts from both the
+ IETF and ITU-T for their helpful comments. In particular, we would
+ like to thank Loa Andersson and the Area Directors for their
+ suggestions and enhancements to the text.
+
+ Thanks to Tom Petch for useful comments and discussions.
+
+ Thanks to Rui Costa for his review and comments, which helped improve
+ this document.
+
+
+
+
+
+
+
+
+
+
+Sprecher & Fang Informational [Page 18]
+
+RFC 6669 OAM Toolset July 2012
+
+
+8. References
+
+8.1. Normative References
+
+ [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
+ Label Switched (MPLS) Data Plane Failures", RFC 4379,
+ February 2006.
+
+ [RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire
+ Virtual Circuit Connectivity Verification (VCCV): A
+ Control Channel for Pseudowires", RFC 5085, December 2007.
+
+ [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
+ "MPLS Generic Associated Channel", RFC 5586, June 2009.
+
+ [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
+ Sprecher, N., and S. Ueno, "Requirements of an MPLS
+ Transport Profile", RFC 5654, September 2009.
+
+ [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
+ "Requirements for Operations, Administration, and
+ Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
+ May 2010.
+
+ [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
+ (BFD)", RFC 5880, June 2010.
+
+ [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
+ "Bidirectional Forwarding Detection (BFD) for MPLS Label
+ Switched Paths (LSPs)", RFC 5884, June 2010.
+
+ [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
+ L., and L. Berger, "A Framework for MPLS in Transport
+ Networks", RFC 5921, July 2010.
+
+ [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
+ Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
+
+ [RFC6371] Busi, I., Ed., and D. Allan, Ed., "Operations,
+ Administration, and Maintenance Framework for MPLS-Based
+ Transport Networks", RFC 6371, September 2011.
+
+ [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
+ Measurement for MPLS Networks", RFC 6374, September 2011.
+
+ [RFC6375] Frost, D., Ed., and S. Bryant, Ed., "A Packet Loss and
+ Delay Measurement Profile for MPLS-Based Transport
+ Networks", RFC 6375, September 2011.
+
+
+
+Sprecher & Fang Informational [Page 19]
+
+RFC 6669 OAM Toolset July 2012
+
+
+ [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
+ On-Demand Connectivity Verification and Route Tracing",
+ RFC 6426, November 2011.
+
+ [RFC6427] Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed.,
+ Boutros, S., and D. Ward, "MPLS Fault Management
+ Operations, Administration, and Maintenance (OAM)", RFC
+ 6427, November 2011.
+
+ [RFC6428] Allan, D., Ed., Swallow Ed., G., and J. Drake Ed.,
+ "Proactive Connectivity Verification, Continuity Check,
+ and Remote Defect Indication for the MPLS Transport
+ Profile", RFC 6428, November 2011.
+
+ [RFC6435] Boutros, S., Ed., Sivabalan, S., Ed., Aggarwal, R., Ed.,
+ Vigoureux, M., Ed., and X. Dai, Ed., "MPLS Transport
+ Profile Lock Instruct and Loopback Functions", RFC 6435,
+ November 2011.
+
+8.2. Informative References
+
+ [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock
+ Synchronization Protocol for Networked Measurement and
+ Control Systems", March 2008.
+
+ [MPLS-TP-ITU-Idents]
+ Winter, R., van Helvoort, H., and M. Betts, "MPLS-TP
+ Identifiers Following ITU-T Conventions", Work in
+ Progress, March 2012.
+
+ [MPLS-TP-SEC]
+ Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP
+ Security Framework", Work in Progress, March 2012.
+
+ [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
+ Networks", RFC 5920, July 2010.
+
+ [Y.1731] International Telecommunications Union - Standardization,
+ "OAM functions and mechanisms for Ethernet based
+ networks", ITU Y.1731, May 2006.
+
+
+
+
+
+
+
+
+
+
+
+Sprecher & Fang Informational [Page 20]
+
+RFC 6669 OAM Toolset July 2012
+
+
+Contributors
+
+ Elisa Bellagamba Ericsson
+ Yaacov Weingarten Nokia Siemens Networks
+ Dan Frost Cisco
+ Nabil Bitar Verizon
+ Raymond Zhang Alcatel Lucent
+ Lei Wang Telenor
+ Kam Lee Yap XO Communications
+ John Drake Juniper
+ Yaakov Stein RAD
+ Anamaria Fulignoli Ericsson
+ Italo Busi Alcatel Lucent
+ Huub van Helvoort Huawei
+ Thomas Nadeau Computer Associate
+ Henry Yu TW Telecom
+ Mach Chen Huawei
+ Manuel Paul Deutsche Telekom
+
+Authors' Addresses
+
+ Nurit Sprecher
+ Nokia Siemens Networks
+ 3 Hanagar St. Neve Ne'eman B
+ Hod Hasharon, 45241
+ Israel
+
+ EMail: nurit.sprecher@nsn.com
+
+
+ Luyuan Fang
+ Cisco Systems
+ 111 Wood Avenue South
+ Iselin, NJ 08830
+ USA
+
+ EMail: lufang@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sprecher & Fang Informational [Page 21]
+