draft-ietf-mpls-tp-temporal-hitless-psm-04.txt		draft-ietf-mpls-tp-temporal-hitless-psm-05.txt
	MPLS Working Group A. D'Alessandro		MPLS Working Group A. D'Alessandro
	Internet Draft Telecom Italia		Internet Draft Telecom Italia
	M.Paul		M.Paul
	Deutsche Telekom		Deutsche Telekom
	Intended status: Informational S. Ueno		Intended status: Informational S. Ueno
	NTT Communications		NTT Communications
			K.Arai
	Y.Koike		Y.Koike
	NTT		NTT
	Expires: Mar. 20, 2014 Oct 21, 2013		Expires: July 30, 2014 January 31, 2014
	Temporal and hitless path segment monitoring		Temporal and hitless path segment monitoring
	draft-ietf-mpls-tp-temporal-hitless-psm-04.txt		draft-ietf-mpls-tp-temporal-hitless-psm-05.txt
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with
	provisions of BCP 78 and BCP 79.		the provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-Drafts.		other groups may also distribute working documents as Internet-
			Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six
	and may be updated, replaced, or obsoleted by other documents at any		months and may be updated, replaced, or obsoleted by other documents
	time. It is inappropriate to use Internet-Drafts as reference		at any time. It is inappropriate to use Internet-Drafts as
	material or to cite them other than as "work in progress."		reference 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 March 20, 2014.		This Internet-Draft will expire on July 30, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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 carefully,		publication of this document. Please review these documents
	as they describe your rights and restrictions with respect to this		carefully, as they describe your rights and restrictions with respect
	document. Code Components extracted from this document must include		to this document. Code Components extracted from this document must
	Simplified BSD License text as described in Section 4.e of the Trust		include Simplified BSD License text as described in Section 4.e of
	Legal Provisions and are provided without warranty as described in		the Trust Legal Provisions and are provided without warranty as
	the Simplified BSD License.		described in the Simplified BSD License.
	Abstract		Abstract
	The MPLS transport profile (MPLS-TP) is being standardized to enable		The MPLS transport profile (MPLS-TP) is being standardized to enable
	carrier-grade packet transport and complement converged packet		carrier-grade packet transport and complement converged packet
	network deployments. Among the most attractive features of MPLS-TP		network deployments. Among the most attractive features of MPLS-TP
	are OAM functions, which enable network operators or service		are OAM functions, which enable network operators or service
	providers to provide various maintenance characteristics, such as		providers to provide various maintenance characteristics, such as
	fault location, survivability, performance monitoring, and		fault location, survivability, performance monitoring, and
	preliminary or in-service measurements.		preliminary or in-service measurements.
	One of the most important mechanisms which is common for transport		One of the most important mechanisms which is common for transport
	network operation is fault location. A segment monitoring function of		network operation is fault location. A segment monitoring function
	a transport path is effective in terms of extension of the		of a transport path is effective in terms of extension of the
	maintenance work and indispensable particularly when the OAM function		maintenance work and indispensable particularly when the OAM
	is effective only between end points. However, the current approach		function is effective only between end points. However, the current
	defined for MPLS-TP for the segment monitoring (SPME) has some fatal		approach defined for MPLS-TP for the segment monitoring (SPME) has
	drawbacks. This document elaborates on the problem statement for the		some fatal drawbacks. This document elaborates on the problem
	Sub-path Maintenance Elements (SPMEs) which provides monitoring of a		statement for the Sub-path Maintenance Elements (SPMEs) which
	portion of a set of transport paths (LSPs or MS-PWs). Based on the		provides monitoring of a portion of a set of transport paths (LSPs
	problems, this document specifies new requirements to consider a new		or MS-PWs). Based on the problems, this document specifies new
	improved mechanism of hitless transport path segment monitoring.		requirements to consider a new improved mechanism of hitless
			transport path segment monitoring.
	This document is a product of a joint Internet Engineering Task Force		This document is a product of a joint Internet Engineering Task
	(IETF) / International Telecommunications Union Telecommunications		Force (IETF) / International Telecommunications Union
	Standardization Sector (ITU-T) effort to include an MPLS Transport		Telecommunications Standardization Sector (ITU-T) effort to include
	Profile within the IETF MPLS and PWE3 architectures to support the		an MPLS Transport Profile within the IETF MPLS and PWE3
	capabilities and functionalities of a packet transport network.		architectures to support the capabilities and functionalities of a
			packet transport network.
	Table of Contents		Table of Contents
	1. Introduction ................................................ 4		1. Introduction ................................................ 4
	2. Conventions used in this document............................ 4		2. Conventions used in this document ............................ 4
	2.1. Terminology ............................................ 5		2.1. Terminology ............................................ 5
	2.2. Definitions ............................................ 5		2.2. Definitions ............................................ 5
	3. Network objectives for monitoring............................ 5		3. Network objectives for monitoring ............................ 5
	4. Problem statement ........................................... 6		4. Problem statement ........................................... 6
	5. OAM functions using segment monitoring ...................... 10		5. OAM functions using segment monitoring ...................... 10
	6. Further consideration of requirements for enhanced segment		6. Further consideration of requirements for enhanced segment
	monitoring .................................................... 10		monitoring .................................................. 1110
	6.1. Necessity of on-demand single-level monitoring.......... 11		6.1. Necessity of on-demand single-level monitoring.......... 11
	6.2. Necessity of on-demand monitoring independent from end-to-end		6.2. Necessity of on-demand monitoring independent from end-to-
	proactive monitoring........................................ 11		end proactive monitoring .................................. 1211
	6.3. Necessity of arbitrary segment monitoring .............. 12		6.3. Necessity of arbitrary segment monitoring .............. 12
	6.4. Fault during HPSM in case of protection ................ 13		6.4. Fault during HPSM in case of protection .............. 1413
	7. Summary .................................................... 15		7. Summary .................................................. 1615
	8. Security Considerations..................................... 16		8. Security Considerations ..................................... 16
	9. IANA Considerations ........................................ 16		9. IANA Considerations ........................................ 16
	10. References ................................................ 16		10. References ................................................ 16
	10.1. Normative References.................................. 16		10.1. Normative References .................................. 16
	10.2. Informative References................................ 16		10.2. Informative References .............................. 1716
	11. Acknowledgments ........................................... 16		11. Acknowledgments ......................................... 1716
	1. Introduction		1. Introduction
	A packet transport network will enable carriers or service providers		A packet transport network will enable carriers or service providers
	to use network resources efficiently, reduce operational complexity		to use network resources efficiently, reduce operational complexity
	and provide carrier-grade network operation. Appropriate maintenance		and provide carrier-grade network operation. Appropriate maintenance
	functions, supporting fault location, survivability, performance		functions, supporting fault location, survivability, performance
	monitoring and preliminary or in-service measurements, are essential		monitoring and preliminary or in-service measurements, are essential
	to ensure quality and reliability of a network. They are essential in		to ensure quality and reliability of a network. They are essential
	transport networks and have evolved along with TDM, ATM, SDH and OTN.		in transport networks and have evolved along with TDM, ATM, SDH and
			OTN.
	Unlike in SDH or OTN networks, where OAM is an inherent part of every		Unlike in SDH or OTN networks, where OAM is an inherent part of
	frame and frames are also transmitted in idle mode, it is not per se		every frame and frames are also transmitted in idle mode, it is not
	possible to constantly monitor the status of individual connections		per se possible to constantly monitor the status of individual
	in packet networks. Packet-based OAM functions are flexible and		connections in packet networks. Packet-based OAM functions are
	selectively configurable according to operators' needs.		flexible and selectively configurable according to operators' needs.
	According to the MPLS-TP OAM requirements [1], mechanisms MUST be		According to the MPLS-TP OAM requirements [1], mechanisms MUST be
	available for alerting a service provider of a fault or defect		available for alerting a service provider of a fault or defect
	affecting the service(s) provided. In addition, to ensure that faults		affecting the service(s) provided. In addition, to ensure that
	or degradations can be localized, operators need a method to analyze		faults or degradations can be localized, operators need a method to
	or investigate the problem. From the fault localization perspective,		analyze or investigate the problem. From the fault localization
	end-to-end monitoring is insufficient. Using end-to-end OAM		perspective, end-to-end monitoring is insufficient. Using end-to-end
	monitoring, when one problem occurs in an MPLS-TP network, the		OAM monitoring, when one problem occurs in an MPLS-TP network, the
	operator can detect the fault, but is not able to localize it.		operator can detect the fault, but is not able to localize it.
	Thus, a specific segment monitoring function for detailed analysis,		Thus, a specific segment monitoring function for detailed analysis,
	by focusing on and selecting a specific portion of a transport path,		by focusing on and selecting a specific portion of a transport path,
	is indispensable to promptly and accurately localize the fault.		is indispensable to promptly and accurately localize the fault.
	For MPLS-TP, a path segment monitoring function has been defined to		For MPLS-TP, a path segment monitoring function has been defined to
	perform this task. However, as noted in the MPLS-TP OAM Framework[5],		perform this task. However, as noted in the MPLS-TP OAM Framework[5],
	the current method for segment monitoring function of a transport		the current method for segment monitoring function of a transport
	path has implications that hinder the usage in an operator network.		path has implications that hinder the usage in an operator network.
	skipping to change at page 6, line 13		skipping to change at page 6, line 17
	shall not change the forwarding behavior.		shall not change the forwarding behavior.
	4. Problem statement		4. Problem statement
	To monitor, protect, or manage portions of transport paths, such as		To monitor, protect, or manage portions of transport paths, such as
	LSPs in MPLS-TP networks, the Sub-Path Maintenance Element (SPME) is		LSPs in MPLS-TP networks, the Sub-Path Maintenance Element (SPME) is
	defined in [2]. The SPME is defined between the edges of the portion		defined in [2]. The SPME is defined between the edges of the portion
	of the transport path that needs to be monitored, protected, or		of the transport path that needs to be monitored, protected, or
	managed. This SPME is created by stacking the shim header (MPLS		managed. This SPME is created by stacking the shim header (MPLS
	header)[3] and is defined as the segment where the header is stacked.		header)[3] and is defined as the segment where the header is stacked.
	OAM messages can be initiated at the edge of the SPME and sent to the		OAM messages can be initiated at the edge of the SPME and sent to
	peer edge of the SPME or to a MIP along the SPME by setting the TTL		the peer edge of the SPME or to a MIP along the SPME by setting the
	value of the label stack entry (LSE) and interface identifier value		TTL value of the label stack entry (LSE) and interface identifier
	at the corresponding hierarchical LSP level in case of per-node model.		value at the corresponding hierarchical LSP level in case of per-node
			model.
	This method has the following general issues, which are fatal in		This method has the following general issues, which are fatal in
	terms of cost and operation.		terms of cost and operation.
	(P-1) Increasing the overhead by the stacking of shim header(s)		(P-1) Increasing the overhead by the stacking of shim header(s)
	(P-2) Increasing the address management complexity, as new MEPs and		(P-2) Increasing the address management complexity, as new MEPs and
	MIPs need to be configured for the SPME in the old MEG		MIPs need to be configured for the SPME in the old MEG
	Problem (P-1) leads to decreased efficiency as bandwidth is wasted		Problem (P-1) leads to decreased efficiency as bandwidth is wasted
	only for maintenance purposes. As the size of monitored segments		only for maintenance purposes. As the size of monitored segments
	increases, the size of the label stack grows. Moreover, if the		increases, the size of the label stack grows. Moreover, if the
	operator wants to monitor the portion of a transport path without		operator wants to monitor the portion of a transport path without
	service disruption, one or more SPMEs have to be set in advance until		service disruption, one or more SPMEs have to be set in advance
	the end of life of a transport path, which is not temporal or on-		until the end of life of a transport path, which is not temporal or
	demand. Consuming additional bandwidth permanently for only the		on-demand. Consuming additional bandwidth permanently for only the
	monitoring purpose should be avoided to maximize the available		monitoring purpose should be avoided to maximize the available
	bandwidth.		bandwidth.
	Problem (P-2) is related to an identifier-management issue. The		Problem (P-2) is related to an identifier-management issue. The
	identification of each layer in case of LSP label stacking is		identification of each layer in case of LSP label stacking is
	required in terms of strict sub-layer management for the segment		required in terms of strict sub-layer management for the segment
	monitoring in a MPLS-TP network. When SPME/TCM is applied for on-		monitoring in a MPLS-TP network. When SPME/TCM is applied for on-
	demand OAM functions in MPLS-TP networks in a similar manner to OTN		demand OAM functions in MPLS-TP networks in a similar manner to OTN
	or Ethernet transport networks, a possible rule of differentiating		or Ethernet transport networks, a possible rule of differentiating
	those SPME/TCMs operationally will be necessary at least within an		those SPME/TCMs operationally will be necessary at least within an
	skipping to change at page 7, line 16		skipping to change at page 7, line 20
	Connection Monitoring (TCM), which can for example be used for a		Connection Monitoring (TCM), which can for example be used for a
	carrier's carrier solution, as shown in Fig. 17 of the framework		carrier's carrier solution, as shown in Fig. 17 of the framework
	document[2]. However, in this case, the SPMEs have to be pre-		document[2]. However, in this case, the SPMEs have to be pre-
	configured. If this solution is applied to specific segment		configured. If this solution is applied to specific segment
	monitoring within one operator domain, all the necessary specific		monitoring within one operator domain, all the necessary specific
	segments have to be pre-configured. This setting increases the		segments have to be pre-configured. This setting increases the
	managed objects as well as the necessary bandwidth, shown as Problem		managed objects as well as the necessary bandwidth, shown as Problem
	(P-1) and (P-2). Moreover, as a result of these pre-configurations,		(P-1) and (P-2). Moreover, as a result of these pre-configurations,
	they impose operators to pre-design the structure of sub-path		they impose operators to pre-design the structure of sub-path
	maintenance elements, which is not preferable in terms of operators'		maintenance elements, which is not preferable in terms of operators'
	increased burden. These concerns are summarized in section 3.8 of [5].		increased burden. These concerns are summarized in section 3.8 of
			[5].
	Furthermore, in reality, all the possible patterns of path segment		Furthermore, in reality, all the possible patterns of path segment
	cannot be set in SPME, because overlapping of path segments is		cannot be set in SPME, because overlapping of path segments is
	limited to nesting relationship. As a result, possible SPME patterns		limited to nesting relationship. As a result, possible SPME patterns
	of portions of an original transport path are limited due to the		of portions of an original transport path are limited due to the
	characteristic of SPME shown in Figure.1, even if SPMEs are pre-		characteristic of SPME shown in Figure.1, even if SPMEs are pre-
	configured. This restriction is inconvenient when operators have to		configured. This restriction is inconvenient when operators have to
	fix issues in an on-demand manner. To avoid these issues, the		fix issues in an on-demand manner. To avoid these issues, the
	temporal and on-demand setting of the SPME(s) is needed and more		temporal and on-demand setting of the SPME(s) is needed and more
	efficient for monitoring in MPLS-TP transport network operation.		efficient for monitoring in MPLS-TP transport network operation.
	However, using currently defined methods, the temporal setting of		However, using currently defined methods, the temporal setting of
	SPMEs also causes the following problems due to label stacking, which		SPMEs also causes the following problems due to label stacking,
	are fatal in terms of intrinsic monitoring and service disruption.		which are fatal in terms of intrinsic monitoring and service
			disruption.
	(P'-1) Changing the condition of the original transport path by		(P'-1) Changing the condition of the original transport path by
	changing the length of all the MPLS frames and changing label		changing the length of all the MPLS frames and changing label
	value(s)		value(s)
	(P'-2) Disrupting client traffic over a transport path, if the SPME		(P'-2) Disrupting client traffic over a transport path, if the SPME
	is temporally configured.		is temporally configured.
	Problem (P'-1) is a fatal problem in terms of intrinsic monitoring.		Problem (P'-1) is a fatal problem in terms of intrinsic monitoring.
	As shown in network objective (2), the monitoring function needs to		As shown in network objective (2), the monitoring function needs to
	skipping to change at page 8, line 5		skipping to change at page 8, line 12
	transport path change, the measured value or observed data will also		transport path change, the measured value or observed data will also
	change. This can make the monitoring meaningless because the result		change. This can make the monitoring meaningless because the result
	of the monitoring would no longer reflect the reality of the		of the monitoring would no longer reflect the reality of the
	connection where the original fault or degradation occurred.		connection where the original fault or degradation occurred.
	Another aspect is that changing the settings of the original shim		Another aspect is that changing the settings of the original shim
	header should not be allowed because those changes correspond to		header should not be allowed because those changes correspond to
	creating a new portion of the original transport path, which differs		creating a new portion of the original transport path, which differs
	from the original data plane conditions.		from the original data plane conditions.
	Figure 1 shows an example of SPME setting. In the figure, X means the		Figure 1 shows an example of SPME setting. In the figure, X means
	one label expected on the tail-end node D of the original transport		the one label expected on the tail-end node D of the original
	path. "210" and "220" are label allocated for SPME. The label values		transport path. "210" and "220" are label allocated for SPME. The
	of the original path are modified as well as the values of stacked		label values of the original path are modified as well as the values
	label. As shown in Fig.1, SPME changes the length of all the MPLS		of stacked label. As shown in Fig.1, SPME changes the length of all
	frames and changes label value(s). This is no longer the monitoring		the MPLS frames and changes label value(s). This is no longer the
	of the original transport path but the monitoring of a different path.		monitoring of the original transport path but the monitoring of a
	Particularly, performance monitoring measurement (Delay measurement		different path. Particularly, performance monitoring measurement
	and loss measurement) are sensitive to those changes.		(Delay measurement and loss measurement) are sensitive to those
			changes.
	(Before SPME settings)		(Before SPME settings)
	--- --- --- --- ---		--- --- --- --- ---
	| | | | | | | | | |		| | | | | | | | | |
	| | | | | | | | | |		| | | | | | | | | |
	--- --- --- --- ---		--- --- --- --- ---
	A---100--B--110--C--120--D--130--E <= transport path		A---100--B--110--C--120--D--130--E <= transport path
	MEP MEP		MEP MEP
	(After SPME settings)		(After SPME settings)
	skipping to change at page 8, line 39		skipping to change at page 8, line 47
	MEP \ / MEP <= transport path		MEP \ / MEP <= transport path
	--210--C--220-- <= SPME		--210--C--220-- <= SPME
	MEP' MEP'		MEP' MEP'
	Figure 1 : An Example of a SPME setting		Figure 1 : An Example of a SPME setting
	Problem (P'-2) was not fully discussed, although the make-before-		Problem (P'-2) was not fully discussed, although the make-before-
	break procedure in the survivability document [4] seemingly supports		break procedure in the survivability document [4] seemingly supports
	the hitless configuration for monitoring according to the framework		the hitless configuration for monitoring according to the framework
	document [2]. The reality is the hitless configuration of SPME is		document [2]. The reality is the hitless configuration of SPME is
	impossible without affecting the conditions of the targeted transport		impossible without affecting the conditions of the targeted
	path, because the make-before-break procedure is premised on the		transport path, because the make-before-break procedure is premised
	change of the inner label value. This means changing one of the		on the change of the inner label value. This means changing one of
	settings in MPLS shim header.		the settings in MPLS shim header.
	Moreover, this might not be effective under the static model without		Moreover, this might not be effective under the static model without
	a control plane because the make-before-break is a restoration		a control plane because the make-before-break is a restoration
	application based on the control plane. The removal of SPME whose		application based on the control plane. The removal of SPME whose
	segment is monitored could have the same impact (disruption of client		segment is monitored could have the same impact (disruption of
	traffic) as the creation of an SPME on the same LSP.		client traffic) as the creation of an SPME on the same LSP.
	Note: (P'-2) will be removed when non-disruptive make-before-break		Note: (P'-2) will be removed when non-disruptive make-before-break
	(in both with and without Control Plane environment) is specified in		(in both with and without Control Plane environment) is specified in
	other MPLS-TP documents. However, (P'-2) could be replaced with the		other MPLS-TP documents. However, (P'-2) could be replaced with the
	following issue. Non-disruptive make-before-break, in other words,		following issue. Non-disruptive make-before-break, in other words,
	taking an action similar to switching just for monitoring is not an		taking an action similar to switching just for monitoring is not an
	ideal operation in transport networks.		ideal operation in transport networks.
	The other potential risks are also envisaged. Setting up a temporal		The other potential risks are also envisaged. Setting up a temporal
	SPME will result in the LSRs within the monitoring segment only		SPME will result in the LSRs within the monitoring segment only
	looking at the added (stacked) labels and not at the labels of the		looking at the added (stacked) labels and not at the labels of the
	original LSP. This means that problems stemming from incorrect (or		original LSP. This means that problems stemming from incorrect (or
	unexpected) treatment of labels of the original LSP by the nodes		unexpected) treatment of labels of the original LSP by the nodes
	within the monitored segment could not be found when setting up SPME.		within the monitored segment could not be found when setting up SPME.
	This might include hardware problems during label look-up, mis-		This might include hardware problems during label look-up, mis-
	configuration etc. Therefore operators have to pay extra attention to		configuration etc. Therefore operators have to pay extra attention
	correctly setting and checking the label values of the original LSP		to correctly setting and checking the label values of the original
	in the configuration. Of course, the inversion of this situation is		LSP in the configuration. Of course, the inversion of this situation
	also possible, .e.g., incorrect or unexpected treatment of SPME		is also possible, .e.g., incorrect or unexpected treatment of SPME
	labels can result in false detection of a fault where none of the		labels can result in false detection of a fault where none of the
	problem originally existed.		problem originally existed.
	The utility of SPMEs is basically limited to inter-carrier or inter-		The utility of SPMEs is basically limited to inter-carrier or inter-
	domain segment monitoring where they are typically pre-configured or		domain segment monitoring where they are typically pre-configured or
	pre-instantiated. SPME instantiates a hierarchical transport path		pre-instantiated. SPME instantiates a hierarchical transport path
	(introducing MPLS label stacking) through which OAM packets can be		(introducing MPLS label stacking) through which OAM packets can be
	sent. SPME construct monitoring function is particularly important		sent. SPME construct monitoring function is particularly important
	mainly for protecting bundles of transport paths and carriers'		mainly for protecting bundles of transport paths and carriers'
	carrier solutions. SPME is expected to be mainly used for protection		carrier solutions. SPME is expected to be mainly used for protection
	skipping to change at page 9, line 42		skipping to change at page 9, line 51
	To summarize, the problem statement is that the current sub-path		To summarize, the problem statement is that the current sub-path
	maintenance based on a hierarchical LSP (SPME) is problematic for		maintenance based on a hierarchical LSP (SPME) is problematic for
	pre-configuration in terms of increasing bandwidth by label stacking		pre-configuration in terms of increasing bandwidth by label stacking
	and managing objects by layer stacking and address management. A on-		and managing objects by layer stacking and address management. A on-
	demand/temporal configuration of SPME is one of the possible		demand/temporal configuration of SPME is one of the possible
	approaches for minimizing the impact of these issues. However, the		approaches for minimizing the impact of these issues. However, the
	current method is unfavorable because the temporal configuration for		current method is unfavorable because the temporal configuration for
	monitoring can change the condition of the original monitored		monitoring can change the condition of the original monitored
	transport path( and disrupt the in-service customer traffic). From		transport path( and disrupt the in-service customer traffic). From
	the perspective of monitoring in transport network operation, a		the perspective of monitoring in transport network operation, a
	solution avoiding those issues or minimizing their impact is required.		solution avoiding those issues or minimizing their impact is
	Another monitoring mechanism is therefore required that supports		required. Another monitoring mechanism is therefore required that
	temporal and hitless path segment monitoring. Hereafter it is called		supports temporal and hitless path segment monitoring. Hereafter it
	on-demand hitless path segment monitoring (HPSM).		is called on-demand hitless path segment monitoring (HPSM).
	Note: The above sentence "and disrupt the in-service customer		Note: The above sentence "and disrupt the in-service customer
	traffic" might need to be modified depending on the result of future		traffic" might need to be modified depending on the result of future
	discussion about (P'-2).		discussion about (P'-2).
	5. OAM functions using segment monitoring		5. OAM functions using segment monitoring
	OAM functions in which on-demand HPSM is required are basically		OAM functions in which on-demand HPSM is required are basically
	limited to on-demand monitoring which are defined in OAM framework		limited to on-demand monitoring which are defined in OAM framework
	document [5], because those segment monitoring functions are used to		document [5], because those segment monitoring functions are used to
	locate the fault/degraded point or to diagnose the status for		locate the fault/degraded point or to diagnose the status for
	detailed analyses, especially when a problem occurred. In other words,		detailed analyses, especially when a problem occurred. In other
	the characteristic of "on-demand" is generally temporal for		words, the characteristic of "on-demand" is generally temporal for
	maintenance operation. Conversely, this could be a good reason that		maintenance operation. Conversely, this could be a good reason that
	operations should not be based on pre-configuration and pre-design.		operations should not be based on pre-configuration and pre-design.
	Packet loss and packet delay measurements are OAM functions in which		Packet loss and packet delay measurements are OAM functions in which
	hitless and temporal segment monitoring are strongly required because		hitless and temporal segment monitoring are strongly required
	these functions are supported only between end points of a transport		because these functions are supported only between end points of a
	path. If a fault or defect occurs, there is no way to locate the		transport path. If a fault or defect occurs, there is no way to
	defect or degradation point without using the segment monitoring		locate the defect or degradation point without using the segment
	function. If an operator cannot locate or narrow the cause of the		monitoring function. If an operator cannot locate or narrow the
	fault, it is quite difficult to take prompt action to solve the		cause of the fault, it is quite difficult to take prompt action to
	problem. Therefore, on-demand HPSM for packet loss and packet delay		solve the problem. Therefore, on-demand HPSM for packet loss and
	measurements are indispensable for transport network operation.		packet delay measurements are indispensable for transport network
			operation.
	Regarding other on-demand monitoring functions path segment		Regarding other on-demand monitoring functions path segment
	monitoring is desirable, but not as urgent as for packet loss and		monitoring is desirable, but not as urgent as for packet loss and
	packet delay measurements.		packet delay measurements.
	Regarding out-of-service on-demand monitoring functions, such as		Regarding out-of-service on-demand monitoring functions, such as
	diagnostic tests, there seems no need for HPSM. However, specific		diagnostic tests, there seems no need for HPSM. However, specific
	segment monitoring should be applied to the OAM function of		segment monitoring should be applied to the OAM function of
	diagnostic test, because SPME doesn't meet network objective (2) in		diagnostic test, because SPME doesn't meet network objective (2) in
	section 3. See section 6.3.		section 3. See section 6.3.
	skipping to change at page 10, line 46		skipping to change at page 11, line 8
	Note:		Note:
	The solution for temporal and hitless segment monitoring should not		The solution for temporal and hitless segment monitoring should not
	be limited to label stacking mechanisms based on pre-configuration,		be limited to label stacking mechanisms based on pre-configuration,
	such as PST/TCM(label stacking), which can cause the issues (P-1)		such as PST/TCM(label stacking), which can cause the issues (P-1)
	and (P-2) described in Section 4.		and (P-2) described in Section 4.
	The solution for HPSM has to cover both per-node model and per-		The solution for HPSM has to cover both per-node model and per-
	interface model which are specified in [5].		interface model which are specified in [5].
	6. Further consideration of requirements for enhanced segment monitoring		6. Further consideration of requirements for enhanced segment
			monitoring
	6.1. Necessity of on-demand single-level monitoring		6.1. Necessity of on-demand single-level monitoring
	The new segment monitoring function is supposed to be applied mainly		The new segment monitoring function is supposed to be applied mainly
	for diagnostic purpose on-demand. We can differentiate this		for diagnostic purpose on-demand. We can differentiate this
	monitoring from the proactive segment monitoring as on-demand multi-		monitoring from the proactive segment monitoring as on-demand multi-
	level monitoring. The most serious problem at the moment is that		level monitoring. The most serious problem at the moment is that
	there is no way to localize the degradation point on a path without		there is no way to localize the degradation point on a path without
	changing the conditions of the original path. Therefore, as a first		changing the conditions of the original path. Therefore, as a first
	step, single layer segment monitoring not affecting the monitored		step, single layer segment monitoring not affecting the monitored
	path is required for a new on-demand and hitless segment monitoring		path is required for a new on-demand and hitless segment monitoring
	function.		function.
	A combination of multi-level and simultaneous monitoring is the most		A combination of multi-level and simultaneous monitoring is the most
	powerful tool for accurately diagnosing the performance of a		powerful tool for accurately diagnosing the performance of a
	transport path. However, considering the substantial benefits to		transport path. However, considering the substantial benefits to
	operators, a strict monitoring function which is required in such as		operators, a strict monitoring function which is required in such as
	a test environment of a laboratory does not seem to be necessary in		a test environment of a laboratory does not seem to be necessary in
	the field. To summarize, on-demand and in-service (hitless) single-		the field. To summarize, on-demand and in-service (hitless) single-
	level segment monitoring is required, on-demand and in-service multi-		level segment monitoring is required, on-demand and in-service
	level segment monitoring is desirable. Figure 2 shows an example of a		multi-level segment monitoring is desirable. Figure 2 shows an
	multi-level on-demand segment monitoring.		example of a multi-level on-demand segment monitoring.
	--- --- --- --- ---		--- --- --- --- ---
	| | | | | | | | | |		| | | | | | | | | |
	| A | | B | | C | | D | | E |		| A | | B | | C | | D | | E |
	--- --- --- --- ---		--- --- --- --- ---
	MEP MEP <= ME of a transport path		MEP MEP <= ME of a transport path
	+-----------------------------+ <= End-to-end monitoring		+-----------------------------+ <= End-to-end monitoring
	*------------------* <= segment monitoring level1		*------------------* <= segment monitoring level1
	*-------------* <= segment monitoring level2		*-------------* <= segment monitoring level2
	*-* <= segment monitoring level3		*-* <= segment monitoring level3
	skipping to change at page 11, line 47		skipping to change at page 12, line 14
	6.2. Necessity of on-demand monitoring independent from end-to-end		6.2. Necessity of on-demand monitoring independent from end-to-end
	proactive monitoring		proactive monitoring
	As multi-level simultaneous monitoring only for on-demand new path		As multi-level simultaneous monitoring only for on-demand new path
	segment monitoring was already discussed in section6.1, next we		segment monitoring was already discussed in section6.1, next we
	consider the necessity of simultaneous monitoring of end-to-end		consider the necessity of simultaneous monitoring of end-to-end
	current proactive monitoring and new on-demand path segment		current proactive monitoring and new on-demand path segment
	monitoring. Normally, the on-demand path segment monitoring is		monitoring. Normally, the on-demand path segment monitoring is
	configured in a segment of a maintenance entity of a transport path.		configured in a segment of a maintenance entity of a transport path.
	In this environment, on-demand single-level monitoring should be done		In this environment, on-demand single-level monitoring should be
	without disrupting pro-active monitoring of the targeted end-to-end		done without disrupting pro-active monitoring of the targeted end-
	transport path.		to-end transport path.
	If operators have to disable the pro-active monitoring during the on-		If operators have to disable the pro-active monitoring during the
	demand hitless path segment monitoring, the network operation system		on-demand hitless path segment monitoring, the network operation
	might miss any performance degradation of user traffic. This kind of		system might miss any performance degradation of user traffic. This
	inconvenience should be avoided in the network operations.		kind of inconvenience should be avoided in the network operations.
	Accordingly, the on-demand single lavel path segment monitoring is		Accordingly, the on-demand single lavel path segment monitoring is
	required without changing or interfering the proactive monitoring of		required without changing or interfering the proactive monitoring of
	the original end-to-end transport path.		the original end-to-end transport path.
	--- --- --- --- ---		--- --- --- --- ---
	| | | | | | | | | |		| | | | | | | | | |
	| A | | B | | C | | D | | E |		| A | | B | | C | | D | | E |
	--- --- --- --- ---		--- --- --- --- ---
	MEP MEP <= ME of a transport path		MEP MEP <= ME of a transport path
	+-----------------------------+ <= Proactive E2E monitoring		+-----------------------------+ <= Proactive E2E monitoring
	*------------------* <= On-demand segment monitoring		*------------------* <= On-demand segment monitoring
	Figure 3 : Independency between proactive end-to-end monitoring and		Figure 3 : Independency between proactive end-to-end monitoring and
	on-demand segment monitoring		on-demand segment monitoring
	6.3. Necessity of arbitrary segment monitoring		6.3. Necessity of arbitrary segment monitoring
	The main objective of on-demand segment monitoring is to diagnose the		The main objective of on-demand segment monitoring is to diagnose
	fault points. One possible diagnostic procedure is to fix one end		the fault points. One possible diagnostic procedure is to fix one
	point of a segment at the MEP of a transport path and change		end point of a segment at the MEP of a transport path and change
	progressively the length of the segment in order. This example is		progressively the length of the segment in order. This example is
	shown in Fig. 4. This approach is considered as a common and		shown in Fig. 4. This approach is considered as a common and
	realistic diagnostic procedure. In this case, one end point of a		realistic diagnostic procedure. In this case, one end point of a
	segment can be anchored at MEP at any time.		segment can be anchored at MEP at any time.
	Other scenarios are also considered, one shown in Fig. 5. In this		Other scenarios are also considered, one shown in Fig. 5. In this
	case, the operators want to diagnose a transport path from a transit		case, the operators want to diagnose a transport path from a transit
	node that is located at the middle, because the end nodes(A and E)		node that is located at the middle, because the end nodes(A and E)
	are located at customer sites and consist of cost effective small box		are located at customer sites and consist of cost effective small
	in which a subset of OAM functions are supported. In this case, if		box in which a subset of OAM functions are supported. In this case,
	one end point and an originator of the diagnostic packet are limited		if one end point and an originator of the diagnostic packet are
	to the position of MEP, on-demand segment monitoring will be		limited to the position of MEP, on-demand segment monitoring will be
	ineffective because all the segments cannot be diagnosed (For example,		ineffective because all the segments cannot be diagnosed (For
	segment monitoring 3 in Fig.5 is not available and it is not possible		example, segment monitoring 3 in Fig.5 is not available and it is
	to localize the fault point).		not possible to localize the fault point).
	--- --- --- --- ---		--- --- --- --- ---
	| | | | | | | | | |		| | | | | | | | | |
	| A | | B | | C | | D | | E |		| A | | B | | C | | D | | E |
	--- --- --- --- ---		--- --- --- --- ---
	MEP MEP <= ME of a transport path		MEP MEP <= ME of a transport path
	+-----------------------------+ <= Proactive E2E monitoring		+-----------------------------+ <= Proactive E2E monitoring
	*-----* <= 1st On-demand segment monitoring		*-----* <= 1st On-demand segment
	*-------* <= 2nd On-demand segment monitoring		monitoring
	*------------* <= 3rd On-demand segment monitoring		*-------* <= 2nd On-demand segment
			monitoring
			*------------* <= 3rd On-demand segment
			monitoring
	|		|
	|		|
	*-----------------------* <= 6th On-demand segment monitoring		*-----------------------* <= 6th On-demand segment
	*-----------------------------*<= 7th On-demand segment monitoring		monitoring
			*-----------------------------*<= 7th On-demand segment
			monitoring
	Figure 4 : One possible procedure to localize a fault point by		Figure 4 : One possible procedure to localize a fault point by
	sequential on-demand segment monitoring		sequential on-demand segment monitoring
	Accordingly, on-demand monitoring of arbitrary segments is mandatory		Accordingly, on-demand monitoring of arbitrary segments is mandatory
	in the case in Fig. 5. As a result, on-demand HSPM should be set in		in the case in Fig. 5. As a result, on-demand HSPM should be set in
	an arbitrary segment of a transport path and diagnostic packets		an arbitrary segment of a transport path and diagnostic packets
	should be inserted from at least any of intermediate maintenance		should be inserted from at least any of intermediate maintenance
	points of the original ME.		points of the original ME.
	--- --- ---		--- --- ---
	--- | | | | | | ---		--- | | | | | | ---
	| A | | B | | C | | D | | E |		| A | | B | | C | | D | | E |
	--- --- --- --- ---		--- --- --- --- ---
	MEP MEP <= ME of a transport path		MEP MEP <= ME of a transport path
	+-----------------------------+ <= Proactive E2E monitoring		+-----------------------------+ <= Proactive E2E monitoring
	*-----* <= On-demand segment monitoring 1		*-----* <= On-demand segment monitoring 1
	*-----------------------*<= On-demand segment monitoring 2		*-----------------------*<= On-demand segment monitoring 2
	*---------* <= On-demand segment monitoring 3		*---------* <= On-demand segment monitoring 3
	Figure 5 : Example where on-demand monitoring has to be configured in		Figure 5 : Example where on-demand monitoring has to be configured
	arbitrary segments		in arbitrary segments
	6.4. Fault during HPSM in case of protection		6.4. Fault during HPSM in case of protection
	Node or link failures may occur during the HPSM is activated. In that		Node or link failures may occur during the HPSM is activated. In
	case, the hitless path segment monitoring function should be		that case, the hitless path segment monitoring function should be
	suspended immediately and must not continue the monitoring on a new		suspended immediately and must not continue the monitoring on a new
	protected or restored path when a protection or restoration for the		protected or restored path when a protection or restoration for the
	fault path is available. Therefore a solution of HPSM should avoid		fault path is available. Therefore a solution of HPSM should avoid
	such a situation that a target node of the hitless segment monitoring		such a situation that a target node of the hitless segment
	is changed to unintended node when failures occur on the segment.		monitoring is changed to unintended node when failures occur on the
			segment.
	Fig.6 and Fig.7 exemplify one of the examples that should be avoided.		Fig.6 and Fig.7 exemplify one of the examples that should be avoided.
	However, this example is just for clarification of the problem that		However, this example is just for clarification of the problem that
	should be avoided. It does not intend to restrict any solution for		should be avoided. It does not intend to restrict any solution for
	meeting the requirements of HPSM. Protection scenario A is shown in		meeting the requirements of HPSM. Protection scenario A is shown in
	figure 6. In this scenario, a working LSP and a protection LSP are		figure 6. In this scenario, a working LSP and a protection LSP are
	separately set, in other words as independent LSPs. HPSM is set		separately set, in other words as independent LSPs. HPSM is set
	between A and E. Therefore, considering the case that a fault happens		between A and E. Therefore, considering the case that a fault
	between B and C, the HPSM doesn't continue in a protected path. As a		happens between B and C, the HPSM doesn't continue in a protected
	result, there is no issue.		path. As a result, there is no issue.
	A - B -- C -- D - E - F		A - B -- C -- D - E - F
	\ /		\ /
	G - H		G - H
	Where:		Where:
	- working LSP: A-B-C-D-E-F		- working LSP: A-B-C-D-E-F
	- protection LSP: A-B-G-H-D-E-F		- protection LSP: A-B-G-H-D-E-F
	- HPSM: A-E		- HPSM: A-E
	---------------		---------------
	Figure 6 : Protection scenario A having no issue when a fault		Figure 6 : Protection scenario A having no issue when a fault
	happens on HPSM		happens on HPSM
	On the other hand, figure 7 shows a scenario where only a portion of		On the other hand, figure 7 shows a scenario where only a portion of
	a transport path has different label assignments (sub-paths). In this		a transport path has different label assignments (sub-paths). In
	case, when a fault condition is identified on working sub-path B-C-D,		this case, when a fault condition is identified on working sub-path
	the sub-path is switched to protection sub-path B-G-H-D. As a result,		B-C-D, the sub-path is switched to protection sub-path B-G-H-D. As a
	the target node of HPSM changes from E to D due to the difference of		result, the target node of HPSM changes from E to D due to the
	hop counts between a route of working path(ABCDE: 4 hops) and that of		difference of hop counts between a route of working path(ABCDE: 4
	protection path(ABGHDE: 5 hops), because the forwarding and		hops) and that of protection path(ABGHDE: 5 hops), because the
	processing of HPSM OAM packets depend only on TTL value of MPLS label		forwarding and processing of HPSM OAM packets depend only on TTL
	header. In this case, some additional mechanisms to notify the fault		value of MPLS label header. In this case, some additional mechanisms
	on working path to the source of HPSM may be necessary to suspend the		to notify the fault on working path to the source of HPSM may be
	monitoring.		necessary to suspend the monitoring.
	A - B -- C -- D - E - F		A - B -- C -- D - E - F
	\ /		\ /
	G - H		G - H
	- e2e LSP: A-B...D-E-F		- e2e LSP: A-B...D-E-F
	- working sub-path: B-C-D		- working sub-path: B-C-D
	- protection sub-path: B-G-H-D		- protection sub-path: B-G-H-D
	- HPSM: A-E		- HPSM: A-E
	---------------		---------------
	Figure 7 : Protection scenario B having an issue when a fault happens		Figure 7 : Protection scenario B having an issue when a fault
	on HPSM		happens on HPSM
	6.5. Consideration of maintenance point for HPSM		6.5. Consideration of maintenance point for HPSM
	An intermediate maintenance point supporting the HPSM has to be able		An intermediate maintenance point supporting the HPSM has to be able
	to generate and inject OAM packets. Although maintenance points for		to generate and inject OAM packets. Although maintenance points for
	the HPSM do not necessarily have to coincide with MIPs or MEPs in		the HPSM do not necessarily have to coincide with MIPs or MEPs in
	terms of the architecture definition, the same identifier for MIPs or		terms of the architecture definition, the same identifier for MIPs
	MEPs could be applied to maintenance points of the HPSM.		or MEPs could be applied to maintenance points of the HPSM.
	7. Summary		7. Summary
	An enhanced monitoring mechanism is required to support temporal and		An enhanced monitoring mechanism is required to support temporal and
	hitless segment monitoring which meets the two network objectives		hitless segment monitoring which meets the two network objectives
	mentioned in Section 3 of this document that are described also in		mentioned in Section 3 of this document that are described also in
	section 3.8 of [5].		section 3.8 of [5].
	The enhancements should minimize the issues described in Section 4,		The enhancements should minimize the issues described in Section 4,
	i.e., P-1, P-2, P'-1( and P'-2), to meet those two network objectives.		i.e., P-1, P-2, P'-1( and P'-2), to meet those two network
			objectives.
	The solution for the temporal and hitless segment monitoring has to		The solution for the temporal and hitless segment monitoring has to
	cover both per-node model and per-interface model which are specified		cover both per-node model and per-interface model which are
	in [5]. In addition, the following requirements should be considered		specified in [5]. In addition, the following requirements should be
	for an enhanced temporal and hitless path segment monitoring		considered for an enhanced temporal and hitless path segment
	function:		monitoring function:
	- "On-demand and in-service" single level segment should be done		- "On-demand and in-service" single level segment should be done
	without changing or interfering any condition of pro-active		without changing or interfering any condition of pro-active
	monitoring of an original ME of a transport path.		monitoring of an original ME of a transport path.
	- On-demand and in-service segment monitoring should be able to be		- On-demand and in-service segment monitoring should be able to be
	set in an arbitrary segment of a transport path.		set in an arbitrary segment of a transport path.
	The temporal and hitless segment monitoring solutions is applicable		The temporal and hitless segment monitoring solutions is applicable
	to and needs to support several on-demand OAM functions, as follows:		to and needs to support several on-demand OAM functions, as follows:
	skipping to change at page 16, line 23		skipping to change at page 17, line 5
	There are no IANA actions required by this draft.		There are no IANA actions required by this draft.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[1] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in		[1] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in
	MPLS Transport Networks", RFC5860, May 2010		MPLS Transport Networks", RFC5860, May 2010
	[2] Bocci, M., et al., "A Framework for MPLS in Transport Networks",		[2] Bocci, M., et al., "A Framework for MPLS in Transport
	RFC5921, July 2010		Networks", RFC5921, July 2010
	[3] Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032,		[3] Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032,
	January 2001		January 2001
	[4] Sprecher, N., Farrel, A. , "Multiprotocol Label Switching		[4] Sprecher, N., Farrel, A. , "Multiprotocol Label Switching
	Transport Profile Survivability Framework", RFC6372, September		Transport Profile Survivability Framework", RFC6372, September
	2011		2011
	[5] Busi, I., Dave, A. , "Operations, Administration and		[5] Busi, I., Dave, A. , "Operations, Administration and
	Maintenance Framework for MPLS-based Transport Networks ",		Maintenance Framework for MPLS-based Transport Networks ",
	skipping to change at page 16, line 48		skipping to change at page 17, line 30
	None		None
	11. Acknowledgments		11. Acknowledgments
	The author would like to thank all members (including MPLS-TP		The author would like to thank all members (including MPLS-TP
	steering committee, the Joint Working Team, the MPLS-TP Ad Hoc Group		steering committee, the Joint Working Team, the MPLS-TP Ad Hoc Group
	in ITU-T) involved in the definition and specification of MPLS		in ITU-T) involved in the definition and specification of MPLS
	Transport Profile.		Transport Profile.
	The authors would also like to thank Alexander Vainshtein, Dave Allan,		The authors would also like to thank Alexander Vainshtein, Dave
	Fei Zhang, Huub van Helvoort, Italo Busi, Maarten Vissers, Malcolm		Allan, Fei Zhang, Huub van Helvoort, Italo Busi, Maarten Vissers,
	Betts, Nurit Sprecher and Jia He for their comments and enhancements		Malcolm Betts, Nurit Sprecher and Jia He for their comments and
	to the text.		enhancements to the text.
	This document was prepared using 2-Word-v2.0.template.dot.		This document was prepared using 2-Word-v2.0.template.dot.
	Authors' Addresses		Authors' Addresses
	Alessandro D'Alessandro		Alessandro D'Alessandro
	Telecom Italia		Telecom Italia
	Email: alessandro.dalessandro@telecomitalia.it		Email: alessandro.dalessandro@telecomitalia.it
	Manuel Paul		Manuel Paul
	Deutsche Telekom		Deutsche Telekom
	Email: Manuel.Paul@telekom.de		Email: Manuel.Paul@telekom.de
	Satoshi Ueno		Satoshi Ueno
	NTT Communications		NTT Communications
	Email: satoshi.ueno@ntt.com		Email: satoshi.ueno@ntt.com
			Kaoru Arai
			NTT
			Email: arai.kaoru@lab.ntt.co.jp
	Yoshinori Koike		Yoshinori Koike
	NTT		NTT
	Email: koike.yoshinori@lab.ntt.co.jp		Email: koike.yoshinori@lab.ntt.co.jp
End of changes. 50 change blocks.
	157 lines changed or deleted		180 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/