draft-ietf-mpls-tp-nm-req-04.txt		draft-ietf-mpls-tp-nm-req-05.txt
	Network Working Group Hing-Kam Lam		Network Working Group Hing-Kam Lam
	Internet Draft Alcatel-Lucent		Internet Draft Alcatel-Lucent
	Expires: March, 2010 Scott Mansfield		Expires: March 18, 2010 Scott Mansfield
	Intended Status: Standards Track Eric Gray		Intended Status: Standards Track Eric Gray
	Ericsson		Ericsson
	September 1, 2009		September 18, 2009
	MPLS TP Network Management Requirements		MPLS TP Network Management Requirements
	draft-ietf-mpls-tp-nm-req-04.txt		draft-ietf-mpls-tp-nm-req-05.txt
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance		This Internet-Draft is submitted to IETF in full conformance
	with the provisions of BCP 78 and BCP 79.		with the provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet		Internet-Drafts are working documents of the Internet
	Engineering Task Force (IETF), its areas, and its working		Engineering Task Force (IETF), its areas, and its working
	groups. Note that other groups may also distribute working		groups. Note that other groups may also distribute working
	documents as Internet-Drafts.		documents as Internet-Drafts.
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	documents at any time. It is inappropriate to use Internet-		documents at any time. It is inappropriate to use Internet-
	Drafts as reference material or to cite them other than as "work		Drafts as reference material or to cite them other than as "work
	in progress."		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 1, 2010.		This Internet-Draft will expire on March 14, 2010.
	Abstract		Abstract
	This document specifies the requirements for the management of		This document specifies the requirements for the management of
	equipment used in networks supporting an MPLS Transport Profile		equipment used in networks supporting an MPLS Transport Profile
	(MPLS-TP). The requirements are defined for specification of		(MPLS-TP). The requirements are defined for specification of
	network management aspects of protocol mechanisms and procedures		network management aspects of protocol mechanisms and procedures
	that constitute the building blocks out of which the MPLS		that constitute the building blocks out of which the MPLS
	transport profile is constructed. That is, these requirements		transport profile is constructed. That is, these requirements
	indicate what management capabilities need to be available in		indicate what management capabilities need to be available in
	skipping to change at page 4, line 7		skipping to change at page 4, line 7
	cover fault, configuration, performance, and security management		cover fault, configuration, performance, and security management
	for MPLS-TP networks, and the requirements for object and		for MPLS-TP networks, and the requirements for object and
	information models needed to manage MPLS-TP Networks and Network		information models needed to manage MPLS-TP Networks and Network
	Elements.		Elements.
	In writing this document, the authors assume the reader is		In writing this document, the authors assume the reader is
	familiar with references [12] and [15].		familiar with references [12] and [15].
	1.1. Terminology		1.1. Terminology
	Although this document is not a protocol specification, the key		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in		document are to be interpreted as described in RFC 2119 [5]. Although
	this document are to be interpreted as described in RFC 2119 [5]		this document is not a protocol specification, the use of this
	and are to be interpreted as instructions to protocol designers		language clarifies the instructions to protocol designers producing
	producing solutions that satisfy the requirements set out in		solutions that satisfy the requirements set out in this document.
	this document.
	Anomaly: The smallest discrepancy which can be observed between		Anomaly: The smallest discrepancy which can be observed between
	actual and desired characteristics of an item. The occurrence of		actual and desired characteristics of an item. The occurrence of
	a single anomaly does not constitute an interruption in ability		a single anomaly does not constitute an interruption in ability
	to perform a required function. Anomalies are used as the input		to perform a required function. Anomalies are used as the input
	for the Performance Monitoring (PM) process and for detection of		for the Performance Monitoring (PM) process and for detection of
	defects (from [21], 3.7).		defects (from [21], 3.7).
	Communication Channel (CCh): A logical channel between network		Communication Channel (CCh): A logical channel between network
	elements (NEs) that can be used - e.g. - for management or		elements (NEs) that can be used - e.g. - for management or
	skipping to change at page 5, line 22		skipping to change at page 5, line 22
	Management Communication Channel (MCC): A CCh dedicated for		Management Communication Channel (MCC): A CCh dedicated for
	management plane communications.		management plane communications.
	Management Communication Network (MCN): A DCN supporting		Management Communication Network (MCN): A DCN supporting
	management plane communication is referred to as a Management		management plane communication is referred to as a Management
	Communication Network (MCN).		Communication Network (MCN).
	MPLS-TP NE: A network element (NE) that supports the functions		MPLS-TP NE: A network element (NE) that supports the functions
	of MPLS necessary to participate in an MPLS-TP based transport		of MPLS necessary to participate in an MPLS-TP based transport
	service. See [8] for further information on functionality		service. See [7] for further information on functionality
	required to support MPLS-TP.		required to support MPLS-TP.
	MPLS-TP network: a network in which MPLS-TP NEs are deployed.		MPLS-TP network: a network in which MPLS-TP NEs are deployed.
	OAM, On-Demand and Proactive: One feature of OAM that is largely		OAM, On-Demand and Proactive: One feature of OAM that is largely
	a management issue is control of OAM; on-demand and proactive		a management issue is control of OAM; on-demand and proactive
	are modes of OAM mechanism operation defined - for example - in		are modes of OAM mechanism operation defined - for example - in
	Y.1731 ([22] - 3.45 and 3.44 respectively) as:		Y.1731 ([22] - 3.45 and 3.44 respectively) as:
	. On-demand OAM - OAM actions which are initiated via manual		. On-demand OAM - OAM actions which are initiated via manual
	skipping to change at page 7, line 7		skipping to change at page 7, line 5
	provide the connection to an OS.		provide the connection to an OS.
	4. Management Communication Network (MCN) Requirements		4. Management Communication Network (MCN) Requirements
	Entities of the MPLS-TP management plane communicate via a DCN,		Entities of the MPLS-TP management plane communicate via a DCN,
	or more specifically via the MCN. The MCN connects management		or more specifically via the MCN. The MCN connects management
	systems with management systems, management systems with MPLS-TP		systems with management systems, management systems with MPLS-TP
	NEs, and (in the indirect connectivity case discussed in section		NEs, and (in the indirect connectivity case discussed in section
	3) MPLS-TP NEs with MPLS-TP NEs.		3) MPLS-TP NEs with MPLS-TP NEs.
	RFC 5586 (Error! Reference source not found.) defines a Generic		RFC 5586 [13] defines a Generic Associated Channel (G-ACh) to
	Associated Channel (G-ACh) to enable the realization of a		enable the realization of a communication channel (CCh) between
	communication channel (CCh) between adjacent MPLS-TP NEs for		adjacent MPLS-TP NEs for management and control. Reference [8]
	management and control. Reference [7] describes how the G-ACh		describes how the G-ACh may be used to provide infrastructure
	may be used to provide infrastructure that forms part of the MCN		that forms part of the MCN and SCN. It also explains how MCN and
	and SCN. It also explains how MCN and SCN messages are		SCN messages are encapsulated, carried on the G-ACh, and
	encapsulated, carried on the G-ACh, and decapsulated for		decapsulated for delivery to management or signaling/routing
	delivery to management or signaling/routing control plane		control plane components on a label switching router (LSR).
	components on a label switching router (LSR).
	ITU-T G.7712/Y.1703 [6], section 7, describes the transport DCN		ITU-T G.7712/Y.1703 [6], section 7, describes the transport DCN
	architecture and requirements. The MPLS-TP MCN MUST support the		architecture and requirements. The MPLS-TP MCN MUST support the
	requirements (in reference [6]) for:		requirements (in reference [6]) for:
	- CCh access functions specified in section 7.1.1;		- CCh access functions specified in section 7.1.1;
	- MPLS-TP SCC data-link layer termination functions specified		- MPLS-TP SCC data-link layer termination functions specified
	in section 7.1.2.3;		in section 7.1.2.3;
	skipping to change at page 8, line 4		skipping to change at page 7, line 47
	In order to have the MCN operate properly, a number of		In order to have the MCN operate properly, a number of
	management functions for the MCN are needed, including:		management functions for the MCN are needed, including:
	. Retrieval of DCN network parameters to ensure compatible		. Retrieval of DCN network parameters to ensure compatible
	functioning, e.g. packet size, timeouts, quality of		functioning, e.g. packet size, timeouts, quality of
	service, window size, etc.;		service, window size, etc.;
	. Establishment of message routing between DCN nodes;		. Establishment of message routing between DCN nodes;
	. Management of DCN network addresses;		. Management of DCN network addresses;
	. Retrieval of operational status of the DCN at a given node;
			. Retrieval of operational status of the DCN at a given node;
	. Capability to enable/disable access by an NE to the DCN.		. Capability to enable/disable access by an NE to the DCN.
	Note that this is to allow isolating a malfunctioning NE		Note that this is to allow isolating a malfunctioning NE
	from impacting the rest of the network.		from impacting the rest of the network.
	5. Fault Management Requirements		5. Fault Management Requirements
	The Fault Management functions within an MPLS-TP NE enable the		The Fault Management functions within an MPLS-TP NE enable the
	supervision, detection, validation, isolation, correction, and		supervision, detection, validation, isolation, correction, and
	reporting of abnormal operation of the MPLS-TP network and its		reporting of abnormal operation of the MPLS-TP network and its
	environment.		environment.
	skipping to change at page 12, line 36		skipping to change at page 12, line 36
	If a control plane is supported in an implementation of MPLS-TP,		If a control plane is supported in an implementation of MPLS-TP,
	the MPLS-TP NE MUST support the configuration of MPLS-TP control		the MPLS-TP NE MUST support the configuration of MPLS-TP control
	plane functions by the management plane. Further detailed		plane functions by the management plane. Further detailed
	requirements will be provided along with progress in defining		requirements will be provided along with progress in defining
	the MPLS-TP control plane in appropriate specifications.		the MPLS-TP control plane in appropriate specifications.
	6.3. Path Configuration		6.3. Path Configuration
	In addition to the requirement to support static provisioning of		In addition to the requirement to support static provisioning of
	transport paths (defined in [8], section 2.1 - General		transport paths (defined in [7], section 2.1 - General
	Requirements - requirement 18), an MPLS-TP NE MUST support the		Requirements - requirement 18), an MPLS-TP NE MUST support the
	configuration of required path performance characteristic		configuration of required path performance characteristic
	thresholds (e.g. - Loss Measurement [LM], Delay Measurement [DM]		thresholds (e.g. - Loss Measurement <LM>, Delay Measurement <DM>
	thresholds) necessary to support performance monitoring of the		thresholds) necessary to support performance monitoring of the
	MPLS-TP service(s).		MPLS-TP service(s).
	In order to accomplish this, an MPLS-TP NE MUST support		In order to accomplish this, an MPLS-TP NE MUST support
	configuration of LSP information (such as an LSP identifier of		configuration of LSP information (such as an LSP identifier of
	some kind) and/or any other information needed to retrieve LSP		some kind) and/or any other information needed to retrieve LSP
	status information, performance attributes, etc.		status information, performance attributes, etc.
	If a control plane is supported, and that control plane includes		If a control plane is supported, and that control plane includes
	support for control-plane/management-plane hand-off for LSP		support for control-plane/management-plane hand-off for LSP
	skipping to change at page 16, line 23		skipping to change at page 16, line 23
	For performance measurement mechanisms that support both		For performance measurement mechanisms that support both
	proactive and on-demand modes, the MPLS-TP NE MUST support the		proactive and on-demand modes, the MPLS-TP NE MUST support the
	capability to be configured to operate on-demand or proactively.		capability to be configured to operate on-demand or proactively.
	7.2.2. Measurement Scope		7.2.2. Measurement Scope
	On measurement of packet loss and loss ratio:		On measurement of packet loss and loss ratio:
	. For bidirectional (both co-routed and associated) P2P		. For bidirectional (both co-routed and associated) P2P
	connections -		connections:
	o on-demand measurement of single-ended packet loss, and		o on-demand measurement of single-ended packet loss, and
	loss ratio, measurement is REQUIRED;		loss ratio, measurement is REQUIRED;
	o proactive measurement of packet loss, and loss ratio,		o proactive measurement of packet loss, and loss ratio,
	measurement for each direction is REQUIRED.		measurement for each direction is REQUIRED.
	. for unidirectional (P2P and P2MP) connection, proactive		. for unidirectional (P2P and P2MP) connection, proactive
	measurement of packet loss, and loss ratio, is REQUIRED.		measurement of packet loss, and loss ratio, is REQUIRED.
	skipping to change at page 19, line 10		skipping to change at page 19, line 10
	12.1. Normative References		12.1. Normative References
	[1] ITU-T Recommendation G.7710/Y.1701, "Common equipment		[1] ITU-T Recommendation G.7710/Y.1701, "Common equipment
	management function requirements", July, 2007.		management function requirements", July, 2007.
	[2] Nadeau, T., et al, "Operations and Management (OAM)		[2] Nadeau, T., et al, "Operations and Management (OAM)
	Requirements for Multi-Protocol Label Switched (MPLS)		Requirements for Multi-Protocol Label Switched (MPLS)
	Networks", RFC 4377, February 2006.		Networks", RFC 4377, February 2006.
	[3] Vigoureux, M., et al, "Requirements for OAM in MPLS		[3] Vigoureux, M., et al, "Requirements for OAM in MPLS
	Transport Networks", work in progress.		Transport Networks", draft-ietf-mpls-tp-oam-requirements,
			work in progress.
	[4] Jones, G., "Operational Security Requirements for Large		[4] Jones, G., "Operational Security Requirements for Large
	Internet Service Provider (ISP) IP Network		Internet Service Provider (ISP) IP Network
	Infrastructure", RFC 3871, September 2004.		Infrastructure", RFC 3871, September 2004.
	[5] Bradner, S., "Key words for use in RFCs to Indicate		[5] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, March 1997.		Requirement Levels", RFC 2119, March 1997.
	[6] ITU-T Recommendation G.7712/Y.1703, "Architecture and		[6] ITU-T Recommendation G.7712/Y.1703, "Architecture and
	specification of data communication network", June 2008.		specification of data communication network", June 2008.
	[7] Beller, D., et al, "An Inband Data Communication Network		[7] Niven-Jenkins, B. et al, "MPLS-TP Requirements", draft-
	For the MPLS Transport Profile", draft-ietf-mpls-tp-gach-
	dcn, work in progress.
	[8] Niven-Jenkins, B. et al, "MPLS-TP Requirements", draft-
	ietf-mpls-tp-requirements, work in progress.		ietf-mpls-tp-requirements, work in progress.
	12.2. Informative References		12.2. Informative References
			[8] Beller, D., et al, "An Inband Data Communication Network
			For the MPLS Transport Profile", draft-ietf-mpls-tp-gach-
			dcn, work in progress.
	[9] Chisholm, S. and D. Romascanu, "Alarm Management		[9] Chisholm, S. and D. Romascanu, "Alarm Management
	Information Base (MIB)", RFC 3877, September 2004.		Information Base (MIB)", RFC 3877, September 2004.
	[10] ITU-T Recommendation M.20, "Maintenance philosophy for		[10] ITU-T Recommendation M.20, "Maintenance philosophy for
	telecommunication networks", October 1992.		telecommunication networks", October 1992.
	[11] Telcordia, "Network Maintenance: Network Element and		[11] Telcordia, "Network Maintenance: Network Element and
	Transport Surveillance Messages" (GR-833-CORE), Issue 5,		Transport Surveillance Messages" (GR-833-CORE), Issue 5,
	August 2004.		August 2004.
	skipping to change at page 20, line 9		skipping to change at page 20, line 9
	[14] Harrington, D., "Guidelines for Considering Operations and		[14] Harrington, D., "Guidelines for Considering Operations and
	Management of New Protocols and Protocol Extensions",		Management of New Protocols and Protocol Extensions",
	draft-ietf-opsawg-operations-and-management, work in		draft-ietf-opsawg-operations-and-management, work in
	progress.		progress.
	[15] Mansfield, S. et al, "MPLS-TP Network Management		[15] Mansfield, S. et al, "MPLS-TP Network Management
	Framework", draft-ietf-mpls-tp-nm-framework, work in		Framework", draft-ietf-mpls-tp-nm-framework, work in
	progress.		progress.
	[16] Enns, R. et al, "NETCONF Configuration Protocol", draft-		[16] Enns, R. et al, "NETCONF Configuration Protocol",
	ietf-netconf-4741bis, work in progress.		draft-ietf-netconf-4741bis, work in progress.
	[17] McCloghrie, K. et al, "Structure of Management Information		[17] McCloghrie, K. et al, "Structure of Management Information
	Version 2 (SMIv2)", RFC 2578, April 1999.		Version 2 (SMIv2)", RFC 2578, April 1999.
	[18] OMG Document formal/04-03-12, "The Common Object Request		[18] OMG Document formal/04-03-12, "The Common Object Request
	Broker: Architecture and Specification", Revision 3.0.3.		Broker: Architecture and Specification", Revision 3.0.3.
	March 12, 2004.		March 12, 2004.
	[19] Caviglia, D. et al, "Requirements for the Conversion		[19] Caviglia, D. et al, "Requirements for the Conversion
	between Permanent Connections and Switched Connections in		between Permanent Connections and Switched Connections in
	skipping to change at page 21, line 5		skipping to change at page 21, line 5
	[24] Lam, H., et al, "Alarm Reporting Control Management		[24] Lam, H., et al, "Alarm Reporting Control Management
	Information Base (MIB)", RFC 3878, September 2004.		Information Base (MIB)", RFC 3878, September 2004.
	[25] ITU-T Recommendation Y.1563, "Ethernet frame transfer and		[25] ITU-T Recommendation Y.1563, "Ethernet frame transfer and
	availability performance", January 2009.		availability performance", January 2009.
	[26] Handley, M., et al, "Internet Denial-of-Service		[26] Handley, M., et al, "Internet Denial-of-Service
	Considerations", RFC 4732, November 2006.		Considerations", RFC 4732, November 2006.
	Author's Addresses		Editors' Addresses
	Editors:
	Eric Gray		Eric Gray
	Ericsson		Ericsson
	900 Chelmsford Street		900 Chelmsford Street
	Lowell, MA, 01851		Lowell, MA, 01851
	Phone: +1 978 275 7470		Phone: +1 978 275 7470
	Email: Eric.Gray@Ericsson.com		Email: Eric.Gray@Ericsson.com
	Scott Mansfield		Scott Mansfield
	Ericsson		Ericsson
	skipping to change at page 21, line 30		skipping to change at page 21, line 28
	+1 724 931 9316		+1 724 931 9316
	EMail: Scott.Mansfield@Ericsson.com		EMail: Scott.Mansfield@Ericsson.com
	Hing-Kam (Kam) Lam		Hing-Kam (Kam) Lam
	Alcatel-Lucent		Alcatel-Lucent
	600-700 Mountain Ave		600-700 Mountain Ave
	Murray Hill, NJ, 07974		Murray Hill, NJ, 07974
	Phone: +1 908 582 0672		Phone: +1 908 582 0672
	Email: hklam@Alcatel-Lucent.com		Email: hklam@Alcatel-Lucent.com
	Author(s):		Contributor's Address
	Contributor(s):
	Adrian Farrel		Adrian Farrel
	Old Dog Consulting		Old Dog Consulting
	Email: adrian@olddog.co.uk		Email: adrian@olddog.co.uk
	Copyright Statement		Copyright Statement
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
End of changes. 18 change blocks.
	39 lines changed or deleted		34 lines changed or added
This html diff was produced by rfcdiff 1.36. The latest version is available from http://tools.ietf.org/tools/rfcdiff/