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/