MPLS Working Group M. Vigoureux (Editor)
Internet Draft Alcatel-Lucent
Intended status: Informational
Expires: April 2009 D. Ward (Editor)
Cisco Systems, Inc.
M. Betts (Editor)
Nortel Networks
October 31, 2008
Requirements for OAM in MPLS Transport Networks
draft-vigoureux-mpls-tp-oam-requirements-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
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".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 31, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Vigoureux et al. Expires April 31, 2009 [Page 1]
Internet-Draft OAM Requirements for MPLS-TP October 2008
Abstract
This document lists the requirements for Operations, Administration
and Maintenance functionality in MPLS networks that are used for
packet transport services and network operations.
These requirements are derived from the set of requirements specified
by ITU-T and first published in the ITU-T Supplement Y.Sup4 [5].
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
Table of Contents
1. Introduction...................................................3
1.1. Terminology...............................................3
1.2. Definitions...............................................4
1.3. Context and Motivations...................................4
2. OAM Requirements...............................................5
2.1. Architectural Requirements................................6
2.2. Functional Requirements...................................7
2.2.1. General requirements.................................8
2.2.2. Connectivity and Continuity Verification.............8
2.2.3. Client Failure Indication............................8
2.2.4. Remote Defect Indication.............................8
2.2.5. Alarm Suppression....................................9
2.2.6. Packet Loss..........................................9
2.2.7. Delay Measurement....................................9
2.2.8. Route Determination.................................10
2.2.9. Diagnostic..........................................10
2.3. Operational Requirements.................................10
2.4. Performance Requirements.................................11
3. Security Considerations.......................................11
4. Congestion Considerations.....................................12
5. IANA Considerations...........................................12
6. Acknowledgments...............................................12
7. References....................................................13
7.1. Normative References.....................................13
7.2. Informative References...................................13
Authors' Addresses...............................................13
Contributing Authors' Addresses..................................14
Intellectual Property Statement..................................15
Disclaimer of Validity...........................................16
Vigoureux et al. Expires April 31, 2009 [Page 2]
Internet-Draft OAM Requirements for MPLS-TP October 2008
1. Introduction
This document lists the requirements for Operations, Administration
and Maintenance functionality in MPLS networks that are used for
packet transport services and network operations.
1.1. Terminology
AC Attachment Circuit
CSF Client Signal Fail
FCAPS Fault, Configuration, Accounting, Performance, Security
LER Label Edge Router
LSP Label Switched Path
LSR Label Switching Router
ME Maintenance Entity
MEP Maintenance End Point
MIP Maintenance Intermediate Point
MP Maintenance Point
MS-PW Multi Segment Pseudowire
OAM Operations, Administration and Maintenance
PE Provider Edge
PSN Packet Switched Network
PW Pseudowire
SLA Service Level Agreement
SS-PW Single Segment Pseudowire
S-PE PW Switching Provider Edge
T-PE PW Terminating Provider Edge
TCME Tandem Connection Maintenance Entity
Vigoureux et al. Expires April 31, 2009 [Page 3]
Internet-Draft OAM Requirements for MPLS-TP October 2008
1.2. Definitions
In this document we refer to a fault as the inability of a function
to perform a required action. This does not include an inability due
to preventive maintenance, lack of external resources, or planned
actions. See also ITU-T G.806 [3].
In this document we refer to a defect as the situation for which
density of anomalies has reached a level where the ability to perform
a required function has been interrupted. See also ITU-T G.806 [3].
In this document, we refer to MPLS Transport Profile (MPLS-TP) as the
set of MPLS functions used to support packet transport services and
network operations.
In this document we refer to a MPLS Section as a network segment
between two LSRs that are immediately adjacent at the MPLS layer.
For definitions of OAM functional components such as Maintenance
Point, Maintenance End Point and Maintenance Intermediate Point,
please refer to [7].
Additional definitions can also be found in [8].
1.3. Context and Motivations
Important attributes of MPLS-TP are that
o it is able to function regardless of which client signals are
using its connectivity service or over which transmission media it
is running. The client, transport network and server layers are,
from a functional point of view, independent layer networks. That
is, demarcation points exist between MPLS-TP and the client layer,
and between MPLS-TP and the underlying server layer.
o it provides means to commit to Service Level Agreements (SLAs)
negotiated with customers, as well as means to monitor compliance
with these SLAs.
o it is consistent with existing transport network OAM models.
In the context of MPLS-TP, the rationale for OAM mechanisms are
twofold as they can serve:
Vigoureux et al. Expires April 31, 2009 [Page 4]
Internet-Draft OAM Requirements for MPLS-TP October 2008
o as a network-oriented mechanism (used by a transport network
operator) to monitor his network infrastructure and to implement
internal mechanisms in order to enhance the general behaviour and
the level of performance of his network (e.g. protection mechanism
in case of node or link failure). For example fault localization
is typically associated to this use case.
o as a service-oriented mechanism (used by a transport service
provider) to monitor his offered services to end customers in
order to be able to react rapidly in case of a problem and to be
able to verify some of the SLA parameters (i.e. performance
monitoring) negotiated with the end customer. Note that a
transport service could be provided over several networks or
administrative domains that may not be all owned and managed by
the same transport service provider.
More generally, OAM is an important and fundamental functionality in
transport networks as it contributes to:
o the reduction of operational complexity and costs, by allowing
efficient and automatic detection, localisation, handling, and
diagnosis of defects, and by minimizing service interruptions and
operational repair times.
o the enhancement of network availability, by ensuring that defects,
for example resulting in misdirected customer traffic are
detected, diagnosed and dealt with before a customer reports the
problem.
o meet service and performance objectives, by running OAM
functionality which allows SLA verification in a multi-maintenance
domain environment and allows the determination of service
degradation due to, for example, packet delay or packet loss.
This is achieved through the support of FCAPS functionality, as
described in ITU-T M.3400 [2], itself relying on OAM related
information.
2. OAM Requirements
This section lists the requirements by which the OAM functionality of
MPLS-TP should abide. Some requirements for this application are
similar to some of those listed in RFC 4377 [6].
The requirements listed below may be met by one or more OAM
protocols, the definition or selection of these protocols is outside
Vigoureux et al. Expires April 31, 2009 [Page 5]
Internet-Draft OAM Requirements for MPLS-TP October 2008
the scope of this document. However, the specified solution MUST
inter-work with the existing MPLS and PW OAM protocols.
2.1. Architectural Requirements
OAM functions SHOULD be independent of the underlying tunnelling or
point-to-point technology or transmission media.
OAM functions SHOULD be independent of the service a pseudowire may
emulate.
The set of OAM functions operated on each Maintenance Entity SHOULD
be independent one from another.
Note that independence should not be understood here in terms of
isolation but in terms of separate running processes. There should be
one OAM process running per Maintenance Entity but different OAM
running processes could interact (e.g. alarm summarization).
OAM functionality MAY be deployed in a variety of environments. In
some of these IP routing and forwarding capabilities are inherently
present (e.g. IP/MPLS) and the OAM functionality MUST also support
their use. Other deployment scenarios exist where IP routing and
forwarding capabilities are not necessarily present (e.g. MPLS-TP).
In these latter cases, the operation of OAM functions MUST NOT rely
on IP routing and forwarding capabilities. Further, it is REQUIRED by
this document that OAM interoperability is achieved across these
environments. It is also REQUIRED by this document that the two above
requirements are still met and still hold when interoperability is
achieved.
Furthermore, in case OAM packets need to incorporate identification
information of source and/or destination nodes, an IP addressing
structure MUST be supported.
When MPLS-TP is run with IP routing and forwarding capabilities, all
existing IP/MPLS OAM functionality (e.g. LSP-Ping, BFD and VCCV) MUST
be able to operate seamlessly.
OAM functions MUST operate and be configurable even in the absence of
a control plane. Conversely, OAM functions SHOULD be configurable as
part of connectivity (LSP or PW) management. Note that means for
configuring OAM functions and for connectivity management are outside
the scope of this document.
The service emulated by a single segment or a multi-segment
pseudowire may span multiple domains. A LSP may also span multiple
domains. It MUST be possible to perform OAM functions on a per domain
Vigoureux et al. Expires April 31, 2009 [Page 6]
Internet-Draft OAM Requirements for MPLS-TP October 2008
basis and across multiple domains. More generally it MUST be possible
to perform OAM functions between any two switching elements of a PW
or of a LSP. This is referred to as segment (or tandem connection)
monitoring (see [7]). Furthermore, in case of a fault or defect on
the service, means MUST be available for the service provider to be
informed of the fault even if the fault is located outside of his
domain.
OAM functions operate in the data plane. OAM packets MUST run in-
band. That is, OAM packets for a specific Maintenance Entity MUST
follow the exact same data path as user traffic of that Maintenance
Entity. This is known as fate sharing.
It MUST be possible to discriminate data traffic from OAM packets.
This includes a means to differentiate OAM packets from user traffic
as well as the capability to apply specific treatment, to OAM
packets, at the MIPs or MEPs targeted by these OAM packets.
As part of the design of OAM mechanisms for MPLS-TP, a mechanism that
enables the realization of a channel for general purpose signalling,
e.g. for control, management and OAM information, associated with the
data plane paths, MUST be provided. Such mechanism SHOULD support the
operation of existing IP/MPLS OAM.
OAM functions MUST be able to be used for PWs, LSPs and Sections.
Furthermore, since LSPs MAY be stacked, OAM functions MUST be able to
run on each LSP, regardless of the label stack depth.
2.2. Functional Requirements
Hereafter are listed the required functions composing the MPLS-TP OAM
tool-set. The list may not be exhaustive and as such the OAM
mechanisms developed in support of the identified requirements SHALL
be extensible and thus SHALL NOT preclude the definition of
additional OAM functions in the future. Furthermore, the design of
OAM mechanisms for MPLS-TP MUST allow the ability to support vendor
specific and experimental OAM functions. Vendor specific and
experimental OAM functions MUST be disabled by default and explicitly
enabled by a service provider or network operator, between nodes that
support them.
Moreover, the use of OAM functions SHOULD be optional for the service
provider or network operator. A network operator or service provider
SHOULD be able to choose which OAM functions to use and which
Maintenance Entities to apply them to.
Vigoureux et al. Expires April 31, 2009 [Page 7]
Internet-Draft OAM Requirements for MPLS-TP October 2008
Note that the functions listed below can serve the purpose of fault
and/or performance management. For example, connectivity verification
can be used for fault management application by detecting failure
conditions, but may also be used for performance management
application through its contribution to the evaluation of performance
metrics (e.g. unavailability time). Nevertheless, it is outside the
scope of this document to specify which function should be used for
which application.
2.2.1. General requirements
If a defect or fault occurs, mechanisms MUST be provided to detect
it, diagnose it, localize it, and notify the appropriate entities.
Corrective actions SHOULD be taken according to the type of defect or
fault.
In the case of the PW Maintenance Entity, OAM mechanisms SHOULD be
provided to ensure that customers do not have to detect faults. The
OAM functions SHOULD allow the service provider to automatically
detect and notify the faults associated with a PW Maintenance Entity.
2.2.2. Connectivity and Continuity Verification
The MPLS-TP OAM tool-set MUST provide a function to enable service
providers to detect loss of continuity but also mis-connectivity
between two points of a Maintenance Entity.
2.2.3. Client Failure Indication
The MPLS-TP OAM tool-set MUST provide a function to enable a MEP to
propagate a client failure indication to its peer MEP when alarm
suppression in the client layer is not supported.
In cases where the OAM of the native service of an AC or a PW type
does not provide mechanisms to propagate failure condition
information, while a downstream indication of such state is needed,
MPLS-TP OAM SHOULD provide mechanisms for propagating AC failures and
their clearance across a MPLS-TP domain.
2.2.4. Remote Defect Indication
The MPLS-TP OAM tool-set MUST provide a function to enable a MEP to
notify its peer MEP of the detection of a defect on a bi-directional
connection between them.
Vigoureux et al. Expires April 31, 2009 [Page 8]
Internet-Draft OAM Requirements for MPLS-TP October 2008
2.2.5. Alarm Suppression
The MPLS-TP OAM tool-set MUST provide a function to enable a server
layer MEP to notify a failure condition or an administrative locking
to its client layer MEP(s) in order to suppress alarms that may be
generated by maintenance domains of the client layer as a result of
the failure condition or of the administrative locking in the server
layer.
The MPLS-TP OAM tool-set MUST allow the client layer to differentiate
between a defect condition and an administrative locking action at
the server layer ME.
The server layer MEP and the client layer MEPs MAY reside on the same
node or on different nodes. A mechanism MUST be provided for both
cases.
An alarm suppression and summarization mechanism MUST be provided.
For example, a fault detected at the LSP level MUST NOT trigger
various alarms at the PW level.
2.2.6. Packet Loss
The MPLS-TP OAM tool-set MUST provide a function to enable service
providers to measure packet loss ratio between a pair of MEPs. Packet
loss ratio is the ratio of the user-plane packets not delivered to
the total number of user-plane packets transmitted during a defined
time interval. The number of user-plane packets not delivered is the
difference between the number of user-plane packets transmitted by
the source node and the number of user-plane packets received at the
destination node.
2.2.7. Delay Measurement
The MPLS-TP OAM tool-set MUST provide a function to enable service
providers to measure the one-way or two-way delay of a packet
transmission between a pair of MEPs. 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.
Vigoureux et al. Expires April 31, 2009 [Page 9]
Internet-Draft OAM Requirements for MPLS-TP October 2008
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.
2.2.8. Route Determination
The MPLS-TP OAM tool-set MUST provide a function to enable service
providers to determine the route of a connection across the MPLS
transport network.
2.2.9. Diagnostic
The MPLS-TP OAM tool-set MUST provide a function to enable service
providers to verify bandwidth throughput (and other diagnostic tests)
between a pair of MEPs.
2.3. Operational Requirements
OAM functions such as connectivity and continuity verification MUST
NOT rely on user traffic. Dedicated OAM flows SHOULD be used to
detect connectivity and continuity defects. See also ITU-T G.806 .
[3].
This document does not mandate the use of a particular OAM function,
however, it is RECOMMENDED that connectivity and continuity
verification is performed on every Maintenance Entity in order to
reliably detect connectivity defects.
OAM functions MUST be applicable to bidirectional point-to-point
connections, and a subset of these OAM functions MUST be applicable
to unidirectional point-to-point and point-to-multipoint connections.
This subset is based on the nature of both the OAM functions and the
connections to which they can apply.
The following table describes how, on which Maintenance Entity and
between which points of the Maintenance Entity SHOULD the required
OAM functions be applied. In these tables, MEP stands for monitoring
from MEP to MEP, MIP stands for monitoring from MEP to MIP, U stands
for unidirectional, B stands for bidirectional. Crosses (x) indicate
the way the considered function should be applied, numbers indicate
the way the considered function should be applied while pointing to a
footnote providing additional details.
Vigoureux et al. Expires April 31, 2009 [Page 10]
Internet-Draft OAM Requirements for MPLS-TP October 2008
+-------------------------------------------+
| on-demand | proactive |
|---------------------+----------+----------|
| MEP | MIP | MEP | MIP |
|----------+----------+----------+----------|
| P2P |P2MP| P2P |P2MP| P2P |P2MP| P2P |P2MP|
|-----+----+----------+----------+-----+----|
|U |B | U |U |B | U |U |B | U |U |B | U |
+----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| cc verification | |x | | |x | |x |x | x | | | |
|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| client fail. indic. | | | | | | | |x | | | | |
|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| remote defect indic. | | | | | | | |x | | | | |
|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| alarm suppression | | | | | | |x |x | x | | | |
|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| packet loss measure | |1 | | | | |x |2 | x | | | |
|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| delay measurement |x |3 | x | | | | | | | | | |
|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| route determination | |x | | |x | | | | | | | |
|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| diagnostic |x |x | x | | | | | | | | | |
+----------------------+-------------------------------------------+
1: single-ended packet loss measurements
2: in both directions of the bi-directional connection
3: one-way and two-way packet delay measurements
Table 1 : OAM functions and their applicability scope
2.4. Performance Requirements
OAM functions SHOULD continue to meet their objectives regardless of
congestion conditions. See also ITU-T Y.1541 [4].
Additional requirements will be incorporated in a future revision of
this document.
3. Security Considerations
Mechanisms SHOULD be provided to ensure that unauthorized access is
prevented from triggering any OAM function.
Vigoureux et al. Expires April 31, 2009 [Page 11]
Internet-Draft OAM Requirements for MPLS-TP October 2008
OAM messages MAY be authenticated.
An OAM packet for a Maintenance Entity MUST NOT leak out of the ME,
i.e. go beyond the terminating MEP.
4. Congestion Considerations
A mechanism (e.g. rate limiting) MUST be provided to prevent OAM
messages from causing congestion in the PSN.
5. IANA Considerations
There are no IANA actions required by this draft.
6. Acknowledgments
The authors would like to thank all members of the teams (the Joint
Working Team, the MPLS Interoperability Design Team in IETF and the
T-MPLS Ad Hoc Group in ITU-T) involved in the definition and
specification of MPLS Transport Profile.
Vigoureux et al. Expires April 31, 2009 [Page 12]
Internet-Draft OAM Requirements for MPLS-TP October 2008
7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[2] ITU-T Recommendation M.3400 (2000), TMN management functions
[3] ITU-T Recommendation G.806 (2006), Characteristics of transport
equipment - Description methodology and generic functionality
[4] ITU-T Recommendation Y.1541 (2006), Network performance
objectives for IP-based services
[5] ITU-T Supplement Y.Sup4 (2008), Transport Requirements for T-
MPLS OAM and considerations for the application of IETF MPLS
Technology
7.2. Informative References
[6] Nadeau, T., et al., "Operations and Management (OAM)
Requirements for Multi-Protocol Label Switched (MPLS)
Networks", RFC 4377, February 2006
[7] Busi, I., Niven-Jenkins, B., "MPLS-TP OAM Framework and
Overview", draft-busi-mpls-tp-oam-framework, October 2008
[8] Niven-Jenkins, B., Brungard, D., Betts, M., "MPLS-TP
Requirements", draft-jenkins-mpls-mpls-tp-requirements, October
2008
Authors' Addresses
Martin Vigoureux
Alcatel-Lucent
Email: martin.vigoureux@alcatel-lucent.com
David Ward
Cisco Systems, Inc.
Email: dward@cisco.com
Vigoureux et al. Expires April 31, 2009 [Page 13]
Internet-Draft OAM Requirements for MPLS-TP October 2008
Malcolm Betts
Nortel Networks
Email: betts01@nortel.com
Contributing Authors' Addresses
Matthew Bocci
Alcatel-Lucent
Email: matthew.bocci@alcatel-lucent.com
Italo Busi
Alcatel-Lucent
Email: italo.busi@alcatel-lucent.it
Huub van Helvoort
Huawei Technologies Co.Ltd.
Email: hhelvoort@huawei.com
Marc Lasserre
Alcatel-Lucent
Email: mlasserre@alcatel-lucent.com
Lieven Levrau
Alcatel-Lucent
Email: llevrau@alcatel-lucent.com
Han Li
China Mobile Communications Corporation (CMCC)
Email: lihan@chinamobile.com
Vigoureux et al. Expires April 31, 2009 [Page 14]
Internet-Draft OAM Requirements for MPLS-TP October 2008
Julien Meuric
Orange
Email: julien.meuric@orange-ftgroup.com
Philippe Niger
Orange
Email: philippe.niger@orange-ftgroup.com
Benjamin Niven-Jenkins
BT
Email: benjamin.niven-jenkins@bt.com
Jing Ruiquan
China Telecom
Email: jingrq@ctbri.com.cn
Nurit Sprecher
Nokia-Siemens Networks
Email: nurit.sprecher@nsn.com
Yuji Tochio
Fujitsu
Email: tochio@jp.fujitsu.com
Yaacov Weingarten
Nokia-Siemens Networks
Email: yaacov.weingarten@nsn.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
Vigoureux et al. Expires April 31, 2009 [Page 15]
Internet-Draft OAM Requirements for MPLS-TP October 2008
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Vigoureux et al. Expires April 31, 2009 [Page 16]