draft-ietf-mpls-tp-oam-requirements-05.txt   draft-ietf-mpls-tp-oam-requirements-06.txt 
MPLS Working Group M. Vigoureux, Ed. MPLS Working Group M. Vigoureux, Ed.
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended status: Standards Track D. Ward, Ed. Intended status: Standards Track D. Ward, Ed.
Expires: August 21, 2010 Juniper Networks Expires: September 6, 2010 Juniper Networks
M. Betts, Ed. M. Betts, Ed.
ZTE Corporation M. C. Betts Consulting Ltd.
February 17, 2010 March 5, 2010
Requirements for OAM in MPLS Transport Networks Requirements for OAM in MPLS Transport Networks
draft-ietf-mpls-tp-oam-requirements-05 draft-ietf-mpls-tp-oam-requirements-06
Abstract Abstract
This document lists architectural and functional requirements for the This document lists architectural and functional requirements for the
Operations, Administration and Maintenance of MPLS Transport Profile. Operations, Administration and Maintenance of MPLS Transport Profile.
These requirements apply to pseudowires, Label Switched Paths, and These requirements apply to pseudowires, Label Switched Paths, and
Sections. Sections.
Status of this Memo Status of this Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 21, 2010. This Internet-Draft will expire on September 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 7 skipping to change at page 3, line 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
In the context of MPLS Transport Profile (MPLS-TP, see [8] and [1]), In the context of MPLS Transport Profile (MPLS-TP, see [9] and [1]),
the rationales for Operations, Administration and Maintenance (OAM) the rationales for Operations, Administration and Maintenance (OAM)
are twofold as it can serve: are twofold as it can serve:
o as a network-oriented functionality, used by a transport network o as a network-oriented functionality, used by a transport network
operator to monitor his network infrastructure and to implement operator to monitor his network infrastructure and to implement
internal mechanisms in order to enhance the general behaviour and internal mechanisms in order to enhance the general behaviour and
the level of performance of his network (e.g., protection the level of performance of his network (e.g., protection
mechanism in case of node or link failure). As an example, fault mechanism in case of node or link failure). As an example, fault
localization is typically associated with this use case. localization is typically associated with this use case.
skipping to change at page 3, line 52 skipping to change at page 3, line 52
domain environment and allows for the determination of service domain environment and allows for the determination of service
degradation due, for example, to packet delay or packet loss. degradation due, for example, to packet delay or packet loss.
1.1. Scope of this Document 1.1. Scope of this Document
This document lists architectural and functional requirements for the This document lists architectural and functional requirements for the
OAM functionality of MPLS-TP. These requirements apply to OAM functionality of MPLS-TP. These requirements apply to
pseudowires (PWs), Label Switched Paths (LSPs) and Sections. pseudowires (PWs), Label Switched Paths (LSPs) and Sections.
These requirements are derived from the set of requirements specified These requirements are derived from the set of requirements specified
by ITU-T and published in the ITU-T Supplement Y.Sup4 [9]. by ITU-T and published in the ITU-T Supplement Y.Sup4 [10].
By covering transport specificities, these requirements complement By covering transport specificities, these requirements complement
those identified in RFC 4377 [10], yet some requirements may be those identified in RFC 4377 [11], yet some requirements may be
similar. similar.
This document only lists architectural and functional OAM This document only lists architectural and functional OAM
requirements. It does not detail the implications of their requirements. It does not detail the implications of their
applicability to the various types (e.g., point-to-point, point-to- applicability to the various types (e.g., point-to-point, point-to-
multipoint, unidirectional, bidirectional ...) of PWs, LSPs and multipoint, unidirectional, bidirectional ...) of PWs, LSPs and
Sections. Furthermore, this document does not provide requirements Sections. Furthermore, this document does not provide requirements
on how the protocol solution(s) should behave to achieve the on how the protocol solution(s) should behave to achieve the
functional objectives. Please see [11] for further information. functional objectives. Please see [12] for further information.
Note that the OAM functions identified in this document may be used Note that the OAM functions identified in this document may be used
for fault management, performance monitoring and/or protection for fault management, performance monitoring and/or protection
switching applications. For example, connectivity verification can switching applications. For example, connectivity verification can
be used for fault management by detecting failure conditions, but may be used for fault management by detecting failure conditions, but may
also be used for performance monitoring through its contribution to also be used for performance monitoring through its contribution to
the evaluation of performance metrics (e.g., unavailability time). the evaluation of performance metrics (e.g., unavailability time).
Nevertheless, it is outside the scope of this document to specify Nevertheless, it is outside the scope of this document to specify
which function should be used for which application. which function should be used for which application.
Note also that it is anticipated that implementers may wish to Note also that it is anticipated that implementers may wish to
implement OAM message handling in hardware. Although not a implement OAM message handling in hardware. Although not a
requirement, this fact could be taken as a design consideration. requirement, this fact could be taken as a design consideration.
1.2. Requirements Language and Terminology 1.2. Requirements Language and Terminology
Although this document is not a protocol specification, the key words The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be document are to be interpreted as described in RFC 2119 [2].
interpreted as described in RFC 2119 [2] and are to be interpreted as Although this document is not a protocol specification, the use of
instructions to the protocol designers producing solutions that this language clarifies the instructions to protocol designers
satisfy the requirements set out in this document. producing solutions that satisfy the requirements set out in this
document.
In this document we refer to the inability of a function to perform a In this document we refer to the inability of a function to perform a
required action, as a fault. This does not include an inability due required action, as a fault. This does not include an inability due
to preventive maintenance, lack of external resources, or planned to preventive maintenance, lack of external resources, or planned
actions. See also ITU-T G.806 [3]. actions. See also ITU-T G.806 [3].
In this document we refer to the situation in which the density of In this document we refer to the situation in which the density of
anomalies has reached a level where the ability to perform a required anomalies has reached a level where the ability to perform a required
function has been interrupted, as a defect. See also ITU-T G.806 function has been interrupted, as a defect. See also ITU-T G.806
[3]. [3].
skipping to change at page 8, line 22 skipping to change at page 8, line 22
2.1.5. Interoperability and Interworking 2.1.5. Interoperability and Interworking
It is REQUIRED that OAM interoperability is achieved between distinct It is REQUIRED that OAM interoperability is achieved between distinct
domains materializing the environments described in Section 2.1.4. domains materializing the environments described in Section 2.1.4.
It is also REQUIRED that the first two requirements of Section 2.1.4 It is also REQUIRED that the first two requirements of Section 2.1.4
still hold and MUST still be met when interoperability is achieved. still hold and MUST still be met when interoperability is achieved.
When MPLS-TP is run with IP routing and forwarding capabilities, it When MPLS-TP is run with IP routing and forwarding capabilities, it
MUST be possible to operate any of the existing IP/MPLS and PW OAM MUST be possible to operate any of the existing IP/MPLS and PW OAM
protocols (e.g., LSP-Ping [4], MPLS-BFD [12], VCCV [5] and VCCV-BFD protocols (e.g., LSP-Ping [4], MPLS-BFD [13], VCCV [5] and VCCV-BFD
[13]). [14]).
2.1.6. Configuration 2.1.6. Configuration
OAM functions MUST operate and be configurable even in the absence of OAM functions MUST operate and be configurable even in the absence of
a control plane. Conversely, it SHOULD be possible to configure as a control plane. Conversely, it SHOULD be possible to configure as
well as enable/disable the capability to operate OAM functions as well as enable/disable the capability to operate OAM functions as
part of connectivity management and it SHOULD also be possible to part of connectivity management and it SHOULD also be possible to
configure as well as enable/disable the capability to operate OAM configure as well as enable/disable the capability to operate OAM
functions after connectivity has been established. functions after connectivity has been established.
skipping to change at page 9, line 50 skipping to change at page 9, line 50
Protocol solution(s) developed to meet these requirements may rely on Protocol solution(s) developed to meet these requirements may rely on
information exchange. Information exchange between various nodes information exchange. Information exchange between various nodes
involved in the operation of an OAM function SHOULD be reliable such involved in the operation of an OAM function SHOULD be reliable such
that, for example, defects or faults are properly detected or that that, for example, defects or faults are properly detected or that
state changes are effectively known by the appropriate nodes. state changes are effectively known by the appropriate nodes.
2.2.2. Continuity Checks 2.2.2. Continuity Checks
The MPLS-TP OAM toolset MUST provide a function to enable an End The MPLS-TP OAM toolset MUST provide a function to enable an End
Point to monitor the liveliness of a PW, LSP or Section. Point to monitor the liveness of a PW, LSP or Section.
This function SHOULD be performed between End Points of PWs, LSPs and This function SHOULD be performed between End Points of PWs, LSPs and
Sections. Sections.
This function SHOULD be performed pro-actively. This function SHOULD be performed pro-actively.
The protocol solution(s) developed to perform this function MUST also The protocol solution(s) developed to perform this function MUST also
apply to point-to-point associated bidirectional LSPs, point-to-point apply to point-to-point associated bidirectional LSPs, point-to-point
unidirectional LSPs and point-to-multipoint LSPs. unidirectional LSPs and point-to-multipoint LSPs.
skipping to change at page 13, line 32 skipping to change at page 13, line 32
The protocol solution(s) developed to perform this function MUST also The protocol solution(s) developed to perform this function MUST also
apply to point-to-point associated bidirectional LSPs, point-to-point apply to point-to-point associated bidirectional LSPs, point-to-point
unidirectional LSPs and point-to-multipoint LSPs. unidirectional LSPs and point-to-multipoint LSPs.
2.2.11. Packet Loss Measurement 2.2.11. Packet Loss Measurement
The MPLS-TP OAM toolset MUST provide a function to enable the The MPLS-TP OAM toolset MUST provide a function to enable the
quantification of packet loss ratio over a PW, LSP or Section. quantification of packet loss ratio over a PW, LSP or Section.
Packet loss ratio is defined to be the ratio of the user packets not The loss of a packet is defined in RFC2680 [6] (see section 2.4).
delivered to the total number of user packets transmitted during a This definition is used here.
defined time interval. The number of user packets not delivered is
the difference between the number of user packets transmitted by an
End Point and the number of user packets received at an End Point.
Note that RFC2680 [14] defines packet loss as well as provides Packet loss ratio is defined here to be the ratio of the number of
definitions for samples and statistics for packet loss. user packets lost to the total number of user packets sent during a
defined time interval.
This function MAY either be performed pro-actively or on-demand. This function MAY either be performed pro-actively or on-demand.
This function SHOULD be performed between End Points of PWs, LSPs and This function SHOULD be performed between End Points of PWs, LSPs and
Sections. Sections.
It SHOULD be possible to rely on user traffic to perform that It SHOULD be possible to rely on user traffic to perform that
functionality. functionality.
The protocol solution(s) developed to perform this function MUST also The protocol solution(s) developed to perform this function MUST also
apply to point-to-point associated bidirectional LSPs, point-to-point apply to point-to-point associated bidirectional LSPs, point-to-point
unidirectional LSPs and point-to-multipoint LSPs. unidirectional LSPs and point-to-multipoint LSPs.
2.2.12. Packet Delay Measurement 2.2.12. Packet Delay Measurement
The MPLS-TP OAM toolset MUST provide a function to enable the The MPLS-TP OAM toolset MUST provide a function to enable the
quantification of the one-way, and if appropriate, the two-way, delay quantification of the one-way, and if appropriate, the two-way, delay
of a PW, LSP or Section. of a PW, LSP or Section.
o The one-way delay is defined in [6] to be the time elapsed from o The one-way delay is defined in [7] to be the time elapsed from
the start of transmission of the first bit of a packet by an End the start of transmission of the first bit of a packet by an End
Point until the reception of the last bit of that packet by the Point until the reception of the last bit of that packet by the
other End Point. other End Point.
o The two-way delay is defined in [7] to be the time elapsed from o The two-way delay is defined in [8] to be the time elapsed from
the start of transmission of the first bit of a packet by an End the start of transmission of the first bit of a packet by an End
Point until the reception of the last bit of that packet by the Point until the reception of the last bit of that packet by the
same End Point. same End Point.
Two-way delay may be quantified using data traffic loopback at the Two-way delay may be quantified using data traffic loopback at the
remote End Point of the PW, LSP or Section (see Section 2.2.5). remote End Point of the PW, LSP or Section (see Section 2.2.5).
Accurate quantification of one-way delay may require clock Accurate quantification of one-way delay may require clock
synchronization, the means for which are outside the scope of this synchronization, the means for which are outside the scope of this
document. document.
skipping to change at page 15, line 31 skipping to change at page 15, line 31
avoid that the OAM packet leaves the current administrative domain. avoid that the OAM packet leaves the current administrative domain.
5. IANA Considerations 5. IANA Considerations
There are no IANA actions required by this draft. There are no IANA actions required by this draft.
6. Acknowledgements 6. Acknowledgements
The editors gratefully acknowledge the contributions of Matthew The editors gratefully acknowledge the contributions of Matthew
Bocci, Italo Busi, Thomas Dietz, Annamaria Fulignoli, Huub van Bocci, Italo Busi, Thomas Dietz, Annamaria Fulignoli, Huub van
Helvoort, Wataru Imajuku, Marc Lasserre, Lieven Levrau, Han Li, Helvoort, Enrique Hernandez-Valencia, Wataru Imajuku, Kam Lam, Marc
Julien Meuric, Philippe Niger, Benjamin Niven-Jenkins, Jing Ruiquan, Lasserre, Lieven Levrau, Han Li, Julien Meuric, Philippe Niger,
Nurit Sprecher, Yuji Tochio, Satoshi Ueno and Yaacov Weingarten. Benjamin Niven-Jenkins, Jing Ruiquan, Nurit Sprecher, Yuji Tochio,
Satoshi Ueno and Yaacov Weingarten.
The authors would like to thank all members of the teams (the Joint The authors would like to thank all members of the teams (the Joint
Working Team, the MPLS Interoperability Design Team in IETF and the Working Team, the MPLS Interoperability Design Team in IETF and the
MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and
specification of MPLS-TP. specification of MPLS-TP.
7. References 7. References
7.1. Normative References 7.1. Normative References
skipping to change at page 16, line 16 skipping to change at page 16, line 17
equipment - Description methodology and generic functionality", equipment - Description methodology and generic functionality",
2009. 2009.
[4] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label [4] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label
Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[5] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit [5] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007. Pseudowires", RFC 5085, December 2007.
[6] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay [6] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet
Loss Metric for IPPM", RFC 2680, September 1999.
[7] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay
Metric for IPPM", RFC 2679, September 1999. Metric for IPPM", RFC 2679, September 1999.
[7] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay [8] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
Metric for IPPM", RFC 2681, September 1999. Metric for IPPM", RFC 2681, September 1999.
7.2. Informative References 7.2. Informative References
[8] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A [9] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A
Framework for MPLS in Transport Networks", Framework for MPLS in Transport Networks",
draft-ietf-mpls-tp-framework-10 (work in progress), draft-ietf-mpls-tp-framework-10 (work in progress),
February 2010. February 2010.
[9] ITU-T Supplement Y.Sup4, "ITU-T Y.1300-series: Supplement on [10] ITU-T Supplement Y.Sup4, "ITU-T Y.1300-series: Supplement on
transport requirements for T-MPLS OAM and considerations for transport requirements for T-MPLS OAM and considerations for
the application of IETF MPLS technology", 2008. the application of IETF MPLS technology", 2008.
[10] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. [11] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
Matsushima, "Operations and Management (OAM) Requirements for Matsushima, "Operations and Management (OAM) Requirements for
Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, Multi-Protocol Label Switched (MPLS) Networks", RFC 4377,
February 2006. February 2006.
[11] Allan, D., Busi, I., and B. Niven-Jenkins, "MPLS-TP OAM [12] Allan, D., Busi, I., and B. Niven-Jenkins, "MPLS-TP OAM
Framework", draft-ietf-mpls-tp-oam-framework-04 (work in Framework", draft-ietf-mpls-tp-oam-framework-04 (work in
progress), December 2009. progress), December 2009.
[12] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD [13] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD
For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress), For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress),
June 2008. June 2008.
[13] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding [14] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Detection (BFD) for the Pseudowire Virtual Circuit Connectivity
Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-07 (work in Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-07 (work in
progress), July 2009. progress), July 2009.
[14] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet
Loss Metric for IPPM", RFC 2680, September 1999.
Authors' Addresses Authors' Addresses
Martin Vigoureux (editor) Martin Vigoureux (editor)
Alcatel-Lucent Alcatel-Lucent
Route de Villejust Route de Villejust
Nozay, 91620 Nozay, 91620
France France
Email: martin.vigoureux@alcatel-lucent.com Email: martin.vigoureux@alcatel-lucent.com
David Ward (editor) David Ward (editor)
Juniper Networks Juniper Networks
Email: dward@juniper.net Email: dward@juniper.net
Malcolm Betts (editor) Malcolm Betts (editor)
ZTE Corporation M. C. Betts Consulting Ltd.
Email: malcolm.betts@zte.com.cn Email: malcolm.betts@rogers.com
 End of changes. 27 change blocks. 
42 lines changed or deleted 42 lines changed or added

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