Network Working Group N. Sprecher
Internet-Draft Nokia Siemens Networks
Intended status: Informational E. Bellagamba
Expires: July 6, 2011 Ericsson
Y. Weingarten
Nokia Siemens Networks
January 2, 2011
OAM functions in MPLS based transport network
draft-ietf-mpls-tp-oam-analysis-03.txt
Abstract
This document describes the outcome of the discussions on the
necessary OAM functionality for the first release of MPLS based
transport networks. The discussion is based on the set of
requirements for Operations, Administration, and Maintenance (OAM)
for MPLS based transport networks as defined in [MPLS-TP OAM Reqs].
An important aspect was to evaluate whether existing OAM tools from
the current MPLS protocol suite can be used to fulfill these
requirements. Eventually, the purpose of the document is to map the
set of functions to a set of tools based on the existing OAM tool-
set.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 6, 2011.
Copyright Notice
Copyright (c) 2011 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
Sprecher, et al. Expires July 6, 2011 [Page 1]
Internet-Draft OAM Functions January 2011
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Sprecher, et al. Expires July 6, 2011 [Page 2]
Internet-Draft OAM Functions January 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Organization of the document . . . . . . . . . . . . . . . 5
1.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 5
1.4. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Basic OAM infrastructure functionality . . . . . . . . . . . . 5
3. MPLS-TP OAM Functions . . . . . . . . . . . . . . . . . . . . 7
3.1. Continuity Check and Connectivity Verification . . . . . . 7
3.1.1. Documents for CC-V tools . . . . . . . . . . . . . . . 7
3.2. Remote Defect Indication . . . . . . . . . . . . . . . . . 7
3.2.1. Documents for RDI . . . . . . . . . . . . . . . . . . 8
3.3. Route Tracing . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1. Documents for Route Tracing . . . . . . . . . . . . . 8
3.4. Alarm Reporting . . . . . . . . . . . . . . . . . . . . . 8
3.4.1. Documents for Alarm Reporting . . . . . . . . . . . . 8
3.5. Lock Reporting . . . . . . . . . . . . . . . . . . . . . . 8
3.5.1. Documents for Lock Reporting . . . . . . . . . . . . . 8
3.6. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . 9
3.6.1. Documents for Lock Instruct . . . . . . . . . . . . . 9
3.7. Client Failure Indication . . . . . . . . . . . . . . . . 9
3.7.1. Documents for CFI . . . . . . . . . . . . . . . . . . 9
3.8. Packet Loss Measurement . . . . . . . . . . . . . . . . . 9
3.8.1. Documents for Packet Loss Measurement . . . . . . . . 9
3.9. Packet Delay Measurement . . . . . . . . . . . . . . . . . 10
3.9.1. Documents for Delay Measurement . . . . . . . . . . . 10
4. MPLS-TP OAM documents guide . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Sprecher, et al. Expires July 6, 2011 [Page 3]
Internet-Draft OAM Functions January 2011
1. Introduction
1.1. Scope
OAM (Operations, Administration, and Maintenance) plays a significant
role in carrier networks, providing methods for fault management and
performance monitoring in both the transport and the service layers
in order to improve their ability to support services with guaranteed
and strict Service Level Agreements (SLAs) while reducing their
operational costs.
[MPLS-TP Reqs] in general, and [MPLS-TP OAM Reqs] in particular
define a set of requirements for OAM functionality in MPLS-Transport
Profile (MPLS-TP) for MPLS-TP Segments, Label Switched Paths (LSPs)
(network infrastructure) and Pseudowires (PWs) (services).
The OAM solution developed by the joint IETF and ITU-T MPLS-TP
project has three objectives:
o The OAM tool-set should be developed based on existing MPLS
architecture, technology, and tool-sets.
o It should be verified that the OAM tool-set for MPLS transport
networks should be aligned with the comparable tool-set in legacy
transport networks as much as possible.
o The OAM tool-set developed for MPLS based transport networks needs
to be fully inter-operable with existing MPLS OAM tools as
documented in [MPLS-TP OAM Reqs].
The discussion on the needed OAM tool-set took place, mainly, in the
MPLS Interoperability Design Team (the MEAD). A tool-set was agreed
upon and was reported to the MPLS working group in Stockholm (July
2009) during the IETF meetings. This was also judged to be the
working group consensus.
This document outlines these recommendations for the tool-set that
should be defined to fulfill the OAM functionality requirements as
documented in [MPLS-TP OAM Reqs] and [MPLS-TP OAM Frwk]. Based on
the objectives cited above, it was determined to base the MPLS-TP OAM
tool-set on the following existing MPLS tools:
o LSP-Ping as defined in [LSP Ping].
o Bidirectional Forwarding Detection (BFD) as defined in [BASE BFD]
and refined in [MPLS BFD].
Sprecher, et al. Expires July 6, 2011 [Page 4]
Internet-Draft OAM Functions January 2011
o ITU-T OAM for Ethernet tool-set as defined in [Y.1731] this will
be used for functionality guidelines for the performance
measurement tools that are not currently supported in MPLS.
It should be noted that certain extensions and adjustments may be
made to the existing MPLS tools, in order to conform to the transport
environment and the requirements of MPLS based transport networks.
1.2. Organization of the document
Section 2 of the document reviews the requirements for MPLS-TP OAM
and shows how they are addressed by the top-level architectural RFCs
Section 3 outlines the different functional tools that are required
for MPLS-TP OAM and references the documents that define the
appropriate tools based on the principles outlined above.
Section 4 provides the user with a cross-reference, pointing out
which tools are addressed by each of the OAM solutions RFCs.
1.3. Contributing Authors
Yaakov Stein (Rad), Annamaria Fulignoli (Ericsson), Italo Busi
(Alcatel Lucent), Huub van Helvoort (Huawei)
1.4. Acronyms
This draft uses the following acronyms:
ACH Associated Channel Header
BFD Bidirectional Forwarding Detection
CC-V Continuity Check and Connectivity Verification
G-ACH Generic Associated Channel Header
LSP Label Switched Path
MPLS-TP Transport Profile for MPLS
OAM Operations, Administration, and Maintenance
PW Pseudowire
RDI Remote Defect Indication
SLA Service Level Agreement
TLV Type, Length, Value
VCCV Virtual Circuit Connectivity Verification
2. Basic OAM infrastructure functionality
[MPLS-TP OAM Reqs] defines a set of requirements on OAM architecture
and general principles of operations which are evaluated below:
Sprecher, et al. Expires July 6, 2011 [Page 5]
Internet-Draft OAM Functions January 2011
[MPLS-TP OAM Reqs] requires that
o OAM mechanisms in MPLS-TP are independent of the transmission
media and of the client service being emulated by the PW.
o the 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 the MPLS-TP OAM tool-
set should rely on the IP routing and forwarding capabilities. On
the other hand, in environments where IP functionality is not
available, the OAM tools must still be able to operate without
dependence on IP forwarding and routing.
o all OAM protocols support identification information, at least in
the form of IP addressing structure and be extensible to support
additional identification schemes.
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 ones. Inherent in this requirement is the
principle that MPLS-TP OAM be independent of any existing control-
plane, although it should not preclude use of the control-plane
functionality.
o a single OAM technology and consistent OAM capabilities for LSPs,
PWs, and Sections.
o OAM packets may be directed to an intermediate point of a LSP/PW.
The following comprise the document-set that addresses the basic
requirements listed above:
o The [MPLS-TP OAM Frwk] document 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 Managed Entity Group, its End-points, and
Intermediate Points.
o The [MPLS G-ACH] document specifies the use of the MPLS-TP in-
band control channel. This is modeled after the VCCV channel
described in [PW ACH] and allows transporting the OAM messages
congruently with the data traffic while allowing the required
identification of the packets. It is expected that all of the OAM
protocols will be used in conjunction with this Generic Associated
Channel.
Sprecher, et al. Expires July 6, 2011 [Page 6]
Internet-Draft OAM Functions January 2011
o The [MPLS TP Idents] document addresses the need of MPLS-TP to
support different addressing spaces. This document describes
different formats for addresses that could be used to identify the
transport entities in the network and referenced by the different
OAM protocols.
3. MPLS-TP OAM Functions
The following sections discuss the OAM functions that are required in
[MPLS-TP OAM Reqs] and expanded upon in [MPLS-TP OAM Frwk].
3.1. Continuity Check and Connectivity Verification
Continuity Check and Connectivity Verification (CC-V) are OAM
operations generally used in tandem, and compliment each other.
These functions are generally run pro-actively, but may also be used
on-demand, either due to bandwidth considerations or for diagnoses of
a specific condition. Pro-actively [MPLS-TP OAM Reqs] states that
the function should allow the MEPs to monitor the liveness and
connectivity of a transport path. In on-demand mode, this function
should support monitoring between the MEPs and, in addition, between
a MEP and MIP.
The [MPLS-TP OAM Frwk] highlights the need for the CC-V messages to
include unique identification of the MEG that is being monitored and
the MEP that originated the message. The function, both pro-actively
and in on-demand mode, needs to be transmitted at regular
transmission rates pre-configured by the operator.
3.1.1. Documents for CC-V tools
[Pro CC-V] defines the BFD extensions that will be used for proactive
CC-V applications. While [Demand CV] provides the LSP-Ping
extensions that will be used to implement on-demand Connectivity
Verification. Both of these tools will be used together with the
basic tools mentioned above in section 2.
3.2. Remote Defect Indication
Remote Defect Indication (RDI) is used by a path end-point to report
to its peer end-point that a defect is detected on a bi-directional
connection between them. [MPLS-TP OAM Reqs] points out that this
function may be applied to a unidirectional LSP only if there a
return path exists. [MPLS-TP OAM Frwk] points out that this function
is associated with the proactive CC-V function.
Sprecher, et al. Expires July 6, 2011 [Page 7]
Internet-Draft OAM Functions January 2011
3.2.1. Documents for RDI
The [Pro CC-V] document includes an extension for BFD that would
include the RDI indication in the BFD format, and a specification of
how this indication is to be used.
3.3. Route Tracing
[MPLS-TP OAM Reqs] defines that there is a need for functionality
that would allow a path end-point to identify the intermediate and
end-points of the path. 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
The [Demand CV] document that specifies the LSP-Ping enhancements for
MPLS-TP on-demand Connectivity Verification includes information on
the use of LSP-Ping for route tracing of a MPLS-TP transport path.
3.4. Alarm Reporting
Alarm Reporting is a function used by an intermediate point of a
path, that becomes aware of a fault on the path, to report to the
end-points of the path. [MPLS-TP OAM Frwk] states that this may
occur as a result of a defect condition discovered at a server sub-
layer. This generates an Alarm Indication Signal (AIS) that
continues until the fault is cleared. The consequent action of this
function is detailed in [MPLS-TP OAM Frwk].
3.4.1. Documents for Alarm Reporting
MPLS-TP defines a new protocol to address this functionality that is
documented in [Fault Mng]. This protocol uses all of the basic
mechanisms detailed in Section 2.
3.5. Lock Reporting
Lock reporting, defined in [MPLS-TP OAM Reqs], 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 that
an administrative lock condition exists for this transport path.
3.5.1. Documents for Lock Reporting
MPLS-TP defines a new protocol to address this functionality that is
documented in [Fault Mng]. This protocol uses all of the basic
Sprecher, et al. Expires July 6, 2011 [Page 8]
Internet-Draft OAM Functions January 2011
mechanisms detailed in Section 2.
3.6. 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. The tool is necessary to support single-side provisioning for
administrative locking, according to [MPLS-TP OAM Frwk]. This
function is used on-demand.
3.6.1. Documents for Lock Instruct
The [LiLoopback] document describes the details of a new ACH based
protocol format for this functionality.
3.7. Client Failure Indication
Client Failure Indication (CFI) is defined in [MPLS-TP OAM Reqs] to
allow the propagation information from one edge of the network to the
other. The information concerns a defect to a client, in the case
that the client does not support alarm notification.
3.7.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.8. Packet Loss Measurement
Packet Loss Measurement is required, by [MPLS-TP OAM Reqs] 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
function, [MPLS-TP OAM Frwk] 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
that result from various issues.
3.8.1. Documents for Packet Loss Measurement
The [Loss-Delay] document describes the protocol formats and
procedures for using the tool. The tool logic is based on the
behavior of the parallel function described in [Y.1731].
Sprecher, et al. Expires July 6, 2011 [Page 9]
Internet-Draft OAM Functions January 2011
3.9. Packet Delay Measurement
Packet Delay Measurement is a function that is used to measure one-
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
OAM Reqs]. 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.
[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
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
The [Loss-Delay] document describes the protocol formats and
procedures for using the tool. The tool logic is based on the
behavior of the parallel function described in [Y.1731].
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 for the initial phase of the specification of
MPLS based transport networks is provided.
[MPLS G-ACH] provides a specification of the basic structure of
protocol messages for in-band data plane OAM in an MPLS environment.
[MPLS TP Idents] provides definitions of different formats that may
be used within OAM protocol messages to identify the network elements
of a MPLS based transport network.
[Pro CC-V] addresses the requirements for proactive use of Continuity
Check, Connectivity Verification, and Remote Defect Indication
Sprecher, et al. Expires July 6, 2011 [Page 10]
Internet-Draft OAM Functions January 2011
functionality for MPLS transport networks.
[Demand CV] addresses the requirements for activation of the
Connectivity Verification functionality between endpoints or between
an endpoint and intermediate point of a monitored domain of a
transport path.
[Fault Mng] specifies protocol messages that support the
functionality required to support Alarm Indication Signal and Lock
Reporting required for MPLS transport networks.
[MPLS-TP CSF] addresses the requirements to support a Client Signal
Fail indication by clients that are being emulated by the MPLS
transport services.
[LiLoopback] specifies protocol messages that support the
functionality required for the Lock Instruct command and activation
of the Loopback functionality for transport paths in MPLS networks.
[Loss-Delay] addresses the requirements for performance measurement
functionality for MPLS transport networks. The protocol defined
supports both loss and delay measurement functions for the transport
paths.
5. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
6. Security Considerations
This document does not by itself raise any particular security
considerations. Security considerations for each function in the OAM
tool-set need to be documented in the document that specifies the
particular functionality.
7. Acknowledgements
The editors wish to thank the MPLS-TP Design Team members, from both
the IETF and ITU-T leadership teams, in formulating the
recommendations documented here. In particular, we would like to
thank Loa Andersson, Huub van Helvoort, and the Area Directors for
their suggestions and enhancements to the text.
Sprecher, et al. Expires July 6, 2011 [Page 11]
Internet-Draft OAM Functions January 2011
8. Normative References
[LSP Ping]
Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[PW ACH] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, February 2006.
[BASE BFD]
Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", RFC 5880, February 2009.
[MPLS BFD]
Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"BFD For MPLS LSPs", RFC 5884, June 2008.
[MPLS TP Idents]
Bocci, M. and G. Swallow, "MPLS-TP Identifiers",
ID draft-ietf-mpls-tp-identifiers-01.txt, March 2010.
[Pro CC-V]
Allan, D. and G. Swallow, "Proactive Connection
Verification, Continuity Check and Remote Defect
indication for MPLS Transport Profile",
ID draft-ietf-mpls-tp-cc-cv-rdi-00.txt, June 2010.
[Demand CV]
Bahadur, N., Aggarwal, R., Boutros, S., and E. Gray, "MPLS
on-demand Connectivity Verification, Route Tracing and
Adjacency Verification",
ID draft-ietf-mpls-tp-on-demand-cv-00, June 2010.
[MPLS-TP OAM Reqs]
Vigoureux, M., Betts, M., and D. Ward, "Requirements for
OAM in MPLS Transport Networks",
ID draft-ietf-mpls-tp-oam-requirements-05, April 2009.
[MPLS-TP OAM Frwk]
Busi, I., Niven-Jenkins, B., and D. Allan, "MPLS-TP OAM
Framework and Overview",
ID draft-ietf-mpls-tp-oam-framework-07, July 2010.
[MPLS-TP Reqs]
Niven-Jenkins, B., Nadeau, T., and C. Pignataro,
"Requirements for the Transport Profile of MPLS",
Sprecher, et al. Expires July 6, 2011 [Page 12]
Internet-Draft OAM Functions January 2011
ID draft-ietf-mpls-tp-requirements-06, April 2009.
[MPLS G-ACH]
Bocci, M., Bryant, S., and M. Vigoureux, "MPLS Generic
Associated Channel", RFC 5586, June 2009.
[Fault Mng]
Swallow, G., Fulignoli, A., and M. Vigoureux, "MPLS Fault
Management OAM", ID draft-ietf-mpls-tp-fault-00,
March 2010.
[LiLoopback]
Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M.,
and X. Dai, "MPLS Transport Profile Lock Instruct and
Loopback Functions", ID draft-ietf-mpls-tp-li-lb-00,
September 2010.
[MPLS-TP CSF]
He, J., LI, H., and E. Bellagamba, "Indication of Client
Failure in MPLS-TP", ID draft-he-mpls-tp-csf-00,
July 2010.
[Loss-Delay]
Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for the MPLS Transport Profile",
ID draft-ietf-mpls-tp-loss-delay-00, April 2010.
[Y.1731] International Telecommunications Union - Standardization,
"OAM functions and mechanisms for Ethernet based
networks", ITU Y.1731, May 2006.
Authors' Addresses
Nurit Sprecher
Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241
Israel
Email: nurit.sprecher@nsn.com
Sprecher, et al. Expires July 6, 2011 [Page 13]
Internet-Draft OAM Functions January 2011
Elisa Bellagamba
Ericsson
6 Farogatan St
Stockholm, 164 40
Sweden
Phone: +46 761440785
Email: elisa.bellagamba@ericsson.com
Yaacov Weingarten
Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241
Israel
Phone: +972-9-775 1827
Email: yaacov.weingarten@nsn.com
Sprecher, et al. Expires July 6, 2011 [Page 14]
