draft-ietf-mpls-tp-nm-req-05.txt		draft-ietf-mpls-tp-nm-req-06.txt
	Network Working Group Hing-Kam Lam		Network Working Group Hing-Kam Lam
	Internet Draft Alcatel-Lucent		Internet Draft Alcatel-Lucent
	Expires: March 18, 2010 Scott Mansfield		Expires: March, 2010 Scott Mansfield
	Intended Status: Standards Track Eric Gray		Intended Status: Standards Track Eric Gray
	Ericsson		Ericsson
	September 18, 2009		October 21, 2009
	MPLS TP Network Management Requirements		MPLS TP Network Management Requirements
	draft-ietf-mpls-tp-nm-req-05.txt		draft-ietf-mpls-tp-nm-req-06.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
	with the provisions of BCP 78 and BCP 79.		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
	Engineering Task Force (IETF), its areas, and its working		Task Force (IETF), its areas, and its working groups. Note that
	groups. Note that other groups may also distribute working		other groups may also distribute working documents as Internet-
	documents as Internet-Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other		months and may be updated, replaced, or obsoleted by other
	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 14, 2010.		This Internet-Draft will expire on April 21, 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
	MPLS for use in managing the MPLS-TP. This document is intended		MPLS for use in managing the MPLS-TP. This document is intended
	to identify essential network management capabilities, not to		to identify essential network management capabilities, not to
	specify what functions any particular MPLS implementation		specify what functions any particular MPLS implementation
	supports.		supports.
	Table of Contents		Table of Contents
	1. Introduction..............................................3		1. Introduction................................................3
	1.1. Terminology..........................................4		1.1. Terminology............................................4
	2. Management Interface Requirements.........................6		2. Management Interface Requirements...........................6
	3. Management Communication Channel (MCC) Requirements.......6		3. Management Communication Channel (MCC) Requirements.........6
	4. Management Communication Network (MCN) Requirements.......6		4. Management Communication Network (MCN) Requirements.........7
	5. Fault Management Requirements.............................8		5. Fault Management Requirements...............................8
	5.1. Supervision Function.................................8		5.1. Supervision Function...................................8
	5.2. Validation Function..................................9		5.2. Validation Function....................................9
	5.3. Alarm Handling Function.............................10		5.3. Alarm Handling Function...............................10
	5.3.1. Alarm Severity Assignment......................10		5.3.1. Alarm Severity Assignment........................10
	5.3.2. Alarm Suppression .............................10		5.3.2. Alarm Suppression................................11
	5.3.3. Alarm Reporting................................11		5.3.3. Alarm Reporting..................................11
	5.3.4. Alarm Reporting Control........................11		5.3.4. Alarm Reporting Control..........................11
	6. Configuration Management Requirements....................11		6. Configuration Management Requirements......................12
	6.1. System Configuration................................12		6.1. System Configuration..................................12
	6.2. Control Plane Configuration.........................12		6.2. Control Plane Configuration...........................12
	6.3. Path Configuration..................................12		6.3. Path Configuration....................................12
	6.4. Protection Configuration............................13		6.4. Protection Configuration..............................13
	6.5. OAM Configuration...................................13		6.5. OAM Configuration.....................................14
	7. Performance Management Requirements......................14		7. Performance Management Requirements........................14
	7.1. Path Characterization Performance Metrics...........14		7.1. Path Characterization Performance Metrics.............15
	7.2. Performance Measurement Instrumentation.............16		7.2. Performance Measurement Instrumentation...............16
	7.2.1. Measurement Frequency..........................16		7.2.1. Measurement Frequency............................16
	7.2.2. Measurement Scope .............................16		7.2.2. Measurement Scope................................16
	8. Security Management Requirements.........................16		8. Security Management Requirements...........................17
	8.1. Management Communication Channel Security...........17		8.1. Management Communication Channel Security.............17
	8.2. Signaling Communication Channel Security............17		8.2. Signaling Communication Channel Security..............17
	8.3. Distributed Denial of Service ......................17		8.3. Distributed Denial of Service.........................18
	9. Security Considerations..................................18		9. Security Considerations....................................18
	10. IANA Considerations.....................................18		10. IANA Considerations.......................................19
	11. Acknowledgments.........................................18		11. Acknowledgments...........................................19
	12. References..............................................18		12. References................................................19
	12.1. Normative References...............................18		12.1. Normative References.................................19
	12.2. Informative References.............................19		12.2. Informative References...............................20
	Author's Addresses..........................................21		Author's Addresses............................................21
	Copyright Statement.........................................21		Copyright Statement...........................................22
	Acknowledgment..............................................22		Acknowledgment................................................22
	Appendix A - Communication Channel (CCh) Examples...........23		Appendix A - Communication Channel (CCh) Examples.............23
	1. Introduction		1. Introduction
	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
	MPLS for use in managing the MPLS-TP. This document is intended		MPLS for use in managing the MPLS-TP. This document is intended
	to identify essential network management capabilities, not to		to identify essential network management capabilities, not to
	specify what functions any particular MPLS implementation		specify what functions any particular MPLS implementation
	supports.		supports.
	This document also leverages management requirements specified		This document also leverages management requirements specified in
	in ITU-T G.7710/Y.1701 [1] and RFC 4377 [2], and attempts to		ITU-T G.7710/Y.1701 [1] and RFC 4377 [2], and attempts to comply
	comply with best common practice as defined in [14].		with best common practice as defined in [15].
	ITU-T G.7710/Y.1701 defines generic management requirements for		ITU-T G.7710/Y.1701 defines generic management requirements for
	transport networks. RFC 4377 specifies the OAM requirements,		transport networks. RFC 4377 specifies the OAM requirements,
	including OAM-related network management requirements, for MPLS		including OAM-related network management requirements, for MPLS
	networks.		networks.
	This document is a product of a joint ITU-T and IETF effort to		This document is a product of a joint ITU-T and IETF effort to
	include an MPLS Transport Profile (MPLS-TP) within the IETF MPLS		include an MPLS Transport Profile (MPLS-TP) within the IETF MPLS
	and PWE3 architectures to support capabilities and functionality		and PWE3 architectures to support capabilities and functionality
	of a transport network as defined by ITU-T.		of a transport network as defined by ITU-T.
	The requirements in this document derive from two sources:		The requirements in this document derive from two sources:
	1) MPLS and PWE3 architectures as defined by IETF, and		1) MPLS and PWE3 architectures as defined by IETF, and
	2) packet transport networks as defined by ITU-T.		2) packet transport networks as defined by ITU-T.
	Requirements for management of equipment in MPLS-TP networks are		Requirements for management of equipment in MPLS-TP networks are
	defined herein. Related functions of MPLS and PWE3 are defined		defined herein. Related functions of MPLS and PWE3 are defined
	elsewhere (and are out of scope in this document).		elsewhere (and are out of scope in this document).
	This document expands on the requirements in [1] and [2] to		This document expands on the requirements in [1] and [2] to cover
	cover fault, configuration, performance, and security management		fault, configuration, performance, and security management for
	for MPLS-TP networks, and the requirements for object and		MPLS-TP networks, and the requirements for object and information
	information models needed to manage MPLS-TP Networks and Network		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 [8] and [9].
	1.1. Terminology		1.1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
	document are to be interpreted as described in RFC 2119 [5]. Although		"OPTIONAL" in this document are to be interpreted as described in
	this document is not a protocol specification, the use of this		RFC 2119 [5]. Although this document is not a protocol
	language clarifies the instructions to protocol designers producing		specification, the use of this language clarifies the
	solutions that satisfy the requirements set out in this document.		instructions to protocol designers producing solutions that
			satisfy the requirements set out in 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
	control plane applications. The physical channel supporting the		control plane applications. The physical channel supporting the
	CCh is technology specific. See Appendix A.		CCh is technology specific. See Appendix A.
	Data Communication Network (DCN): A network that supports Layer		Data Communication Network (DCN): A network that supports Layer 1
	1 (physical layer), Layer 2 (data-link layer), and Layer 3		(physical layer), Layer 2 (data-link layer), and Layer 3 (network
	(network layer) functionality for distributed management		layer) functionality for distributed management communications
	communications related to the management plane, for distributed		related to the management plane, for distributed signaling
	signaling communications related to the control plane, and other		communications related to the control plane, and other operations
	operations communications (e.g., order-wire/voice		communications (e.g., order-wire/voice communications, software
	communications, software downloads, etc.).		downloads, etc.).
	Defect: The density of anomalies has reached a level where the		Defect: The density of anomalies has reached a level where the
	ability to perform a required function has been interrupted.		ability to perform a required function has been interrupted.
	Defects are used as input for performance monitoring, the		Defects are used as input for performance monitoring, the control
	control of consequent actions, and the determination of fault		of consequent actions, and the determination of fault cause (from
	cause (from [21], 3.24).		[21], 3.24).
	Failure: The fault cause persisted long enough to consider the		Failure: The fault cause persisted long enough to consider the
	ability of an item to perform a required function to be		ability of an item to perform a required function to be
	terminated. The item may be considered as failed; a fault has		terminated. The item may be considered as failed; a fault has now
	now been detected (from [21], 3.25).		been detected (from [21], 3.25).
	Fault: A fault is the inability of a function to perform a		Fault: A fault is the inability of a function to perform a
	required action. This does not include an inability due to		required action. This does not include an inability due to
	preventive maintenance, lack of external resources, or planned		preventive maintenance, lack of external resources, or planned
	actions (from [21], 3.26).		actions (from [21], 3.26).
	Fault Cause: A single disturbance or fault may lead to the		Fault Cause: A single disturbance or fault may lead to the
	detection of multiple defects. A fault cause is the result of a		detection of multiple defects. A fault cause is the result of a
	correlation process which is intended to identify the defect		correlation process which is intended to identify the defect that
	that is representative of the disturbance or fault that is		is representative of the disturbance or fault that is causing the
	causing the problem (from [21], 3.27).		problem (from [21], 3.27).
	Fault Cause Indication (FCI): An indication of a fault cause.		Fault Cause Indication (FCI): An indication of a fault cause.
	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
	of MPLS necessary to participate in an MPLS-TP based transport		MPLS necessary to participate in an MPLS-TP based transport
	service. See [7] 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
	are modes of OAM mechanism operation defined - for example - in		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
	intervention for a limited time to carry out diagnostics.		intervention for a limited time to carry out diagnostics.
	On-demand OAM can result in singular or periodic OAM		On-demand OAM can result in singular or periodic OAM actions
	actions during the diagnostic time interval.		during the diagnostic time interval.
	. Proactive OAM - OAM actions which are carried on		. Proactive OAM - OAM actions which are carried on
	continuously to permit timely reporting of fault and/or		continuously to permit timely reporting of fault and/or
	performance status.		performance status.
	(Note that it is possible for specific OAM mechanisms to only		(Note that it is possible for specific OAM mechanisms to only
	have a sensible use in either on-demand or proactive mode.)		have a sensible use in either on-demand or proactive mode.)
	Operations System (OS): A system that performs the functions		Operations System (OS): A system that performs the functions that
	that support processing of information related to operations,		support processing of information related to operations,
	administration, maintenance, and provisioning (OAM&P) for the		administration, maintenance, and provisioning (OAM&P) for the
	networks, including surveillance and testing functions to		networks, including surveillance and testing functions to support
	support customer access maintenance.		customer access maintenance.
	Signaling Communication Channel (SCC): A CCh dedicated for		Signaling Communication Channel (SCC): A CCh dedicated for
	control plane communications. The SCC may be used for GMPLS/ASON		control plane communications. The SCC can be used for GMPLS/ASON
	signaling and/or other control plane messages (e.g., routing		signaling and/or other control plane messages (e.g., routing
	messages).		messages).
	Signaling Communication Network (SCN): A DCN supporting control		Signaling Communication Network (SCN): A DCN supporting control
	plane communication is referred to as a Signaling Communication		plane communication is referred to as a Signaling Communication
	Network (SCN).		Network (SCN).
	2. Management Interface Requirements		2. Management Interface Requirements
	This document does not specify which management interface		This document does not specify a preferred management interface
	protocol should be used as the standard protocol for managing		protocol to be used as the standard protocol for managing MPLS-TP
	MPLS-TP networks. Managing an end-to-end connection across		networks. Managing an end-to-end connection across multiple
	multiple operator domains where one domain is managed (for		operator domains where one domain is managed (for example) via
	example) via NETCONF/XML ([16]) or SNMP/SMI ([17]), and another		NETCONF ([16]) or SNMP ([17]), and another domain via CORBA
	domain via CORBA/IDL ([18]), is allowed.		([18]), is allowed.
	For the management interface to the management system, an MPLS-		1) For the management interface to the management system, an
	TP NE MAY actively support more than one management protocol in		MPLS-TP NE MAY actively support more than one management
	any given deployment. For example, an MPLS-TP NE may use one		protocol in any given deployment.
	protocol for configuration and another for monitoring. The
	protocols to be supported are at the discretion of the operator.
	3. Management Communication Channel (MCC) Requirements		For example, an operator can use one protocol for configuration
			of an MPLS-TP NE and another for monitoring. The protocols to be
			supported are at the discretion of the operator.
	Specifications SHOULD define support for management connectivity		3. Management Communication Channel (MCC) Requirements
	with remote MPLS-TP domains and NEs, as well as with termination
	points located in NEs under the control of a third party network
	operator. See ITU-T G.8601 [23] for example scenarios in multi-
	carrier multi-transport-technology environments.
	For management purpose, every MPLS-TP NE MUST connect to an OS.		1) Specifications SHOULD define support for management
	The connection MAY be direct (e.g. - via a software, hardware or		connectivity with remote MPLS-TP domains and NEs, as well as
	proprietary protocol connection) or indirect (via another MPLS-		with termination points located in NEs under the control of
	TP NE). In this document, any management connection that is not		a third party network operator. See ITU-T G.8601 [23] for
	via another MPLS-TP NE is a direct management connection. When		example scenarios in multi-carrier multi-transport-
	an MPLS-TP NE is connected indirectly to an OS, an MCC MUST be		technology environments.
	supported between that MPLS-TP NE and any MPLS-TP NE(s) used to
	provide the connection to an OS.
	4. Management Communication Network (MCN) Requirements		2) For management purpose, every MPLS-TP NE MUST connect to an
			OS. The connection MAY be direct (e.g. - via a software,
			hardware or proprietary protocol connection) or indirect
			(via another MPLS-TP NE). In this document, any management
			connection that is not via another MPLS-TP NE is a direct
			management connection. When an MPLS-TP NE is connected
			indirectly to an OS, an MCC MUST be supported between that
			MPLS-TP NE and any MPLS-TP NE(s) used to provide the
			connection to an OS.
	Entities of the MPLS-TP management plane communicate via a DCN,		4. Management Communication Network (MCN) Requirements
	or more specifically via the MCN. The MCN connects management
	systems with management systems, management systems with MPLS-TP
	NEs, and (in the indirect connectivity case discussed in section
	3) MPLS-TP NEs with MPLS-TP NEs.
	RFC 5586 [13] defines a Generic Associated Channel (G-ACh) to		Entities of the MPLS-TP management plane communicate via a DCN,
	enable the realization of a communication channel (CCh) between		or more specifically via the MCN. The MCN connects management
	adjacent MPLS-TP NEs for management and control. Reference [8]		systems with management systems, management systems with MPLS-TP
	describes how the G-ACh may be used to provide infrastructure		NEs, and (in the indirect connectivity case discussed in section
	that forms part of the MCN and SCN. It also explains how MCN and		3) MPLS-TP NEs with MPLS-TP NEs.
	SCN messages are encapsulated, carried on the G-ACh, and
	decapsulated for delivery to management or signaling/routing
	control plane components on a label switching router (LSR).
	ITU-T G.7712/Y.1703 [6], section 7, describes the transport DCN		RFC 5586 [14] defines a Generic Associated Channel (G-ACh) to
	architecture and requirements. The MPLS-TP MCN MUST support the		enable the realization of a communication channel (CCh) between
	requirements (in reference [6]) for:		adjacent MPLS-TP NEs for management and control. Reference [10]
			describes how the G-ACh can be used to provide infrastructure
			that forms part of the MCN and SCN. It also explains how MCN and
			SCN messages are encapsulated, carried on the G-ACh, and
			decapsulated for delivery to management or signaling/routing
			control plane components on a label switching router (LSR).
	- CCh access functions specified in section 7.1.1;		ITU-T G.7712/Y.1703 [6], section 7, describes the transport DCN
			architecture and requirements.
	- MPLS-TP SCC data-link layer termination functions specified		1) The MPLS-TP MCN MUST support the requirements (in reference
	in section 7.1.2.3;		[6]) for:
	- MPLS-TP MCC data-link layer termination functions specified		a) CCh access functions specified in section 7.1.1;
	in section 7.1.2.4;
	- Network layer PDU into CCh data-link frame encapsulation		b) MPLS-TP SCC data-link layer termination functions
	functions specified in section 7.1.3;		specified in section 7.1.2.3;
	- Network layer PDU forwarding (7.1.6), interworking (7.1.7)		c) MPLS-TP MCC data-link layer termination functions
	and encapsulation (7.1.8) functions, as well as tunneling		specified in section 7.1.2.4;
	(7.1.9) and routing (7.1.10) functions specified in [6].
	As a practical matter, MCN connections will typically have		d) Network layer PDU into CCh data-link frame encapsulation
	addresses. See the section on addressing in [15] for further		functions specified in section 7.1.3;
	information.
	In order to have the MCN operate properly, a number of		e) Network layer PDU forwarding (7.1.6), interworking (7.1.7)
	management functions for the MCN are needed, including:		and encapsulation (7.1.8) functions, as well as tunneling
			(7.1.9) and routing (7.1.10) functions specified in [6].
	. Retrieval of DCN network parameters to ensure compatible		As a practical matter, MCN connections will typically have
	functioning, e.g. packet size, timeouts, quality of		addresses. See the section on Identifiers in [8] for further
	service, window size, etc.;		information.
	. Establishment of message routing between DCN nodes;		In order to have the MCN operate properly, a number of management
			functions for the MCN are needed, including:
	. Management of DCN network addresses;		. Retrieval of DCN network parameters to ensure compatible
			functioning, e.g. packet size, timeouts, quality of service,
			window size, etc.;
	. Retrieval of operational status of the DCN at a given node;		. Establishment of message routing between DCN nodes;
	. Capability to enable/disable access by an NE to the DCN.
	Note that this is to allow isolating a malfunctioning NE
	from impacting the rest of the network.
	5. Fault Management Requirements		. Management of DCN network addresses;
	The Fault Management functions within an MPLS-TP NE enable the		. Retrieval of operational status of the DCN at a given node;
	supervision, detection, validation, isolation, correction, and
	reporting of abnormal operation of the MPLS-TP network and its
	environment.
	5.1. Supervision Function		. Capability to enable/disable access by an NE to the DCN.
			Note that this is to allow isolating a malfunctioning NE
			from impacting the rest of the network.
	The supervision function analyses the actual occurrence of a		5. Fault Management Requirements
	disturbance or fault for the purpose of providing an appropriate
	indication of performance and/or detected fault condition to
	maintenance personnel and operations systems.
	The MPLS-TP NE MUST support supervision of the OAM mechanisms		The Fault Management functions within an MPLS-TP NE enable the
	that are deployed for supporting the OAM requirements defined in		supervision, detection, validation, isolation, correction, and
	[1].		reporting of abnormal operation of the MPLS-TP network and its
			environment.
	The MPLS-TP NE MUST support the following data-plane forwarding		5.1. Supervision Function
	path supervision functions:
	. Supervision of loop-checking functions used to detect loops		The supervision function analyses the actual occurrence of a
	in the data-plane forwarding path (which result in non-		disturbance or fault for the purpose of providing an appropriate
	delivery of traffic, wasting of forwarding resources and		indication of performance and/or detected fault condition to
	unintended self-replication of traffic);		maintenance personnel and operations systems.
	. Supervision of failure detection;		1) The MPLS-TP NE MUST support supervision of the OAM
			mechanisms that are deployed for supporting the OAM
			requirements defined in [3].
	The MPLS-TP NE MUST support the capability to configure data-		2) The MPLS-TP NE MUST support the following data-plane
	plane forwarding path related supervision mechanisms to perform		forwarding path supervision functions:
	on-demand or proactively.
	The MPLS-TP NE MUST support supervision for software processing		a) Supervision of loop-checking functions used to detect
	e.g., processing faults, storage capacity, version mismatch,		loops in the data-plane forwarding path (which result in
	corrupted data and out of memory problems, etc.		non-delivery of traffic, wasting of forwarding resources
			and unintended self-replication of traffic);
	The MPLS-TP NE MUST support hardware-related supervision for		b) Supervision of failure detection;
	interchangeable and non-interchangeable unit, cable, and power
	problems.
	The MPLS-TP NE SHOULD support environment-related supervision		3) The MPLS-TP NE MUST support the capability to configure
	for temperature, humidity, etc.		data-plane forwarding path related supervision mechanisms to
			perform on-demand or proactively.
	5.2. Validation Function		4) The MPLS-TP NE MUST support supervision for software
			processing - e.g., processing faults, storage capacity,
			version mismatch, corrupted data and out of memory problems,
			etc.
	Validation is the process of integrating Fault Cause indications		5) The MPLS-TP NE MUST support hardware-related supervision for
	into Failures. A Fault Cause Indication (FCI) indicates a		interchangeable and non-interchangeable unit, cable, and
	limited interruption of the required transport function. A Fault		power problems.
	Cause is not reported to maintenance personnel because it might
	exist only for a very short time. Note that some of these events
	are summed up in the Performance Monitoring process (see section
	7), and when this sum exceeds a configured value, a threshold
	crossing alert (report) can be generated.
	When the Fault Cause lasts long enough, an inability to perform		6) The MPLS-TP NE SHOULD support environment-related
	the required transport function arises. This failure condition		supervision for temperature, humidity, etc.
	is subject to reporting to maintenance personnel and/or an OS
	because corrective action might be required. Conversely, when
	the Fault Cause ceases after a certain time, clearing of the
	Failure condition is also subject to reporting.
	The MPLS-TP NE MUST perform persistency checks on fault causes		5.2. Validation Function
	before it declares a fault cause a failure.
	The MPLS-TP NE SHOULD provide a configuration capability for		Validation is the process of integrating Fault Cause indications
	control parameters associated with performing the persistency		into Failures. A Fault Cause Indication (FCI) indicates a limited
	checks described above.		interruption of the required transport function. A Fault Cause is
			not reported to maintenance personnel because it might exist only
			for a very short time. Note that some of these events are summed
			up in the Performance Monitoring process (see section 7), and
			when this sum exceeds a configured value, a threshold crossing
			alert (report) can be generated.
	An MPLS-TP NE MAY provide configuration parameters to control		When the Fault Cause lasts long enough, an inability to perform
	reporting, and clearing, of failure conditions.		the required transport function arises. This failure condition is
			subject to reporting to maintenance personnel and/or an OS
			because corrective action might be required. Conversely, when the
			Fault Cause ceases after a certain time, clearing of the Failure
			condition is also subject to reporting.
	A data-plane forwarding path failure MUST be declared if the		1) The MPLS-TP NE MUST perform persistency checks on fault
	fault cause persists continuously for a configurable time (Time-		causes before it declares a fault cause a failure.
	D). The failure MUST be cleared if the fault cause is absent
	continuously for a configurable time (Time-C).
	Note: As an example, the default time values might be as		2) The MPLS-TP NE SHOULD provide a configuration capability for
	follows:		control parameters associated with performing the
			persistency checks described above.
	Time-D = 2.5 +/- 0.5 seconds		3) An MPLS-TP NE MAY provide configuration parameters to
			control reporting, and clearing, of failure conditions.
	Time-C = 10 +/- 0.5 seconds		4) A data-plane forwarding path failure MUST be declared if the
			fault cause persists continuously for a configurable time
			(Time-D). The failure MUST be cleared if the fault cause is
			absent continuously for a configurable time (Time-C).
	These time values are as defined in G.7710 [1].		Note: As an example, the default time values might be as follows:
	MIBs - or other object management semantics specifications -		Time-D = 2.5 +/- 0.5 seconds
	defined to enable configuration of these timers SHOULD
	explicitly provide default values and MAY provide guidelines on
	ranges and value determination methods for scenarios where the
	default value chosen might be inadequate. In addition, such
	specifications SHOULD define the level of granularity at which
	tables of these values are to be defined.
	Implementations MUST provide the ability to configure the		Time-C = 10 +/- 0.5 seconds
	preceding set of timers, and SHOULD provide default values to
	enable rapid configuration. Suitable default values, timer
	ranges, and level of granularity are out of scope in this
	document and form part of the specification of fault management
	details. Timers SHOULD be configurable per NE for broad
	categories (for example, defects and/or fault causes), and MAY
	be configurable per-interface on an NE and/or per individual
	defect/fault cause.
	The failure declaration and clearing MUST be time stamped. The		These time values are as defined in G.7710 [1].
	time-stamp MUST indicate the time at which the fault cause is
	activated at the input of the fault cause persistency (i.e.
	defect-to-failure integration) function, and the time at which
	the fault cause is deactivated at the input of the fault cause
	persistency function.
	5.3. Alarm Handling Function		5) MIBs - or other object management semantics specifications -
			defined to enable configuration of these timers SHOULD
			explicitly provide default values and MAY provide guidelines
			on ranges and value determination methods for scenarios
			where the default value chosen might be inadequate. In
			addition, such specifications SHOULD define the level of
			granularity at which tables of these values are to be
			defined.
	5.3.1. Alarm Severity Assignment		6) Implementations MUST provide the ability to configure the
			preceding set of timers, and SHOULD provide default values
			to enable rapid configuration. Suitable default values,
			timer ranges, and level of granularity are out of scope in
			this document and form part of the specification of fault
			management details. Timers SHOULD be configurable per NE for
			broad categories (for example, defects and/or fault causes),
			and MAY be configurable per-interface on an NE and/or per
			individual defect/fault cause.
	Failures can be categorized to indicate the severity or urgency		7) The failure declaration and clearing MUST be time stamped.
	of the fault.		The time-stamp MUST indicate the time at which the fault
			cause is activated at the input of the fault cause
			persistency (i.e. defect-to-failure integration) function,
			and the time at which the fault cause is deactivated at the
			input of the fault cause persistency function.
	An MPLS-TP NE SHOULD support the ability to assign severity		5.3. Alarm Handling Function
	(e.g., Critical, Major, Minor, Warning) to alarm conditions via
	configuration.
	See G.7710 [1], section 7.2.2 for more detail on alarm severity		5.3.1. Alarm Severity Assignment
	assignment.
	5.3.2. Alarm Suppression		Failures can be categorized to indicate the severity or urgency
			of the fault.
	Alarms can be generated from many sources, including OAM, device		1) An MPLS-TP NE SHOULD support the ability to assign severity
	status, etc.		(e.g., Critical, Major, Minor, Warning) to alarm conditions
			via configuration.
	An MPLS-TP NE MUST support suppression of alarms based on		See G.7710 [1], section 7.2.2 for more detail on alarm severity
	configuration.		assignment. For additional discussion of Alarm Severity
			management, see discussion of alarm severity in RFC 3877 [11].
	5.3.3. Alarm Reporting		5.3.2. Alarm Suppression
	Alarm Reporting is concerned with the reporting of relevant		Alarms can be generated from many sources, including OAM, device
	events and conditions, which occur in the network (including the		status, etc.
	NE, incoming signal, and external environment).
	Local reporting is concerned with automatic alarming by means of		1) An MPLS-TP NE MUST support suppression of alarms based on
	audible and visual indicators near the failed equipment.		configuration.
	An MPLS-TP NE MUST support local reporting of alarms.		5.3.3. Alarm Reporting
	The MPLS-TP NE MUST support reporting of alarms to an OS. These		Alarm Reporting is concerned with the reporting of relevant
	reports are either autonomous reports (notifications) or reports		events and conditions, which occur in the network (including the
	on request by maintenance personnel. The MPLS-TP NE SHOULD		NE, incoming signal, and external environment).
	report local (environmental) alarms to a network management
	system.
	An MPLS-TP NE supporting one or more other networking		Local reporting is concerned with automatic alarming by means of
	technologies (e.g. - Ethernet, SDH/SONET, MPLS) over MPLS-TP		audible and visual indicators near the failed equipment.
	MUST be capable of translating an MPLS-TP defects into failure
	conditions that are meaningful to the client layer, as described
	in RFC 4377 [2], section 4.7.
	5.3.4. Alarm Reporting Control		1) An MPLS-TP NE MUST support local reporting of alarms.
	Alarm Reporting Control (ARC) supports an automatic in-service		2) The MPLS-TP NE MUST support reporting of alarms to an OS.
	provisioning capability. Alarm reporting can be turned off on a		These reports are either autonomous reports (notifications)
	per-managed entity (e.g., LSP) basis to allow sufficient time		or reports on request by maintenance personnel. The MPLS-TP
	for customer service testing and other maintenance activities in		NE SHOULD report local (environmental) alarms to a network
	an "alarm free" state. Once a managed entity is ready, alarm		management system.
	reporting is automatically turned on.
	An MPLS-TP NE SHOULD support the Alarm Reporting Control		3) An MPLS-TP NE supporting one or more other networking
	function for controlling the reporting of alarm conditions.		technologies (e.g. - Ethernet, SDH/SONET, MPLS) over MPLS-TP
			MUST be capable of translating an MPLS-TP defects into
			failure conditions that are meaningful to the client layer,
			as described in RFC 4377 [2], section 4.7.
	See G.7710 [1] (section 7.1.3.2) and RFC 3878 [24] for more		5.3.4. Alarm Reporting Control
	information about ARC.
	6. Configuration Management Requirements		Alarm Reporting Control (ARC) supports an automatic in-service
			provisioning capability. Alarm reporting can be turned off on a
			per-managed entity (e.g., LSP) basis to allow sufficient time for
			customer service testing and other maintenance activities in an
			"alarm free" state. Once a managed entity is ready, alarm
			reporting is automatically turned on.
	Configuration Management provides functions to identify, collect		1) An MPLS-TP NE SHOULD support the Alarm Reporting Control
	data from, provide data to and control NEs. Specific		function for controlling the reporting of alarm conditions.
	configuration tasks requiring network management support include
	hardware and software configuration, configuration of NEs to
	support transport paths (including required working and
	protection paths), and configuration of required path
	integrity/connectivity and performance monitoring (i.e. - OAM).
	6.1. System Configuration		See G.7710 [1] (section 7.1.3.2) and RFC 3878 [24] for more
			information about ARC.
	The MPLS-TP NE MUST support the configuration requirements		6. Configuration Management Requirements
	specified in G.7710 [1] section 8.1 for hardware.
	The MPLS-TP NE MUST support the configuration requirements		Configuration Management provides functions to identify, collect
	specified in G.7710 [1] section 8.2 for software.		data from, provide data to and control NEs. Specific
			configuration tasks requiring network management support include
			hardware and software configuration, configuration of NEs to
			support transport paths (including required working and
			protection paths), and configuration of required path
			integrity/connectivity and performance monitoring (i.e. - OAM).
	The MPLS-TP NE MUST support the configuration requirements		6.1. System Configuration
	specified in G.7710 [1] section 8.13.2.1 for local real time
	clock functions.
	The MPLS-TP NE MUST support the configuration requirements		1) The MPLS-TP NE MUST support the configuration requirements
	specified in G.7710 [1] section 8.13.2.2 for local real time		specified in G.7710 [1] section 8.1 for hardware.
	clock alignment with external time reference.
	The MPLS-TP NE MUST support the configuration requirements		2) The MPLS-TP NE MUST support the configuration requirements
	specified in G.7710 [1] section 8.13.2.3 for performance		specified in G.7710 [1] section 8.2 for software.
	monitoring of the clock function.
	6.2. Control Plane Configuration		3) The MPLS-TP NE MUST support the configuration requirements
			specified in G.7710 [1] section 8.13.2.1 for local real time
			clock functions.
	If a control plane is supported in an implementation of MPLS-TP,		4) The MPLS-TP NE MUST support the configuration requirements
	the MPLS-TP NE MUST support the configuration of MPLS-TP control		specified in G.7710 [1] section 8.13.2.2 for local real time
	plane functions by the management plane. Further detailed		clock alignment with external time reference.
	requirements will be provided along with progress in defining
	the MPLS-TP control plane in appropriate specifications.
	6.3. Path Configuration		5) The MPLS-TP NE MUST support the configuration requirements
			specified in G.7710 [1] section 8.13.2.3 for performance
			monitoring of the clock function.
	In addition to the requirement to support static provisioning of		6.2. Control Plane Configuration
	transport paths (defined in [7], section 2.1 - General
	Requirements - requirement 18), an MPLS-TP NE MUST support the
	configuration of required path performance characteristic
	thresholds (e.g. - Loss Measurement <LM>, Delay Measurement <DM>
	thresholds) necessary to support performance monitoring of the
	MPLS-TP service(s).
	In order to accomplish this, an MPLS-TP NE MUST support		1) If a control plane is supported in an implementation of
	configuration of LSP information (such as an LSP identifier of		MPLS-TP, the MPLS-TP NE MUST support the configuration of
	some kind) and/or any other information needed to retrieve LSP		MPLS-TP control plane functions by the management plane.
	status information, performance attributes, etc.		Further detailed requirements will be provided along with
			progress in defining the MPLS-TP control plane in
			appropriate specifications.
	If a control plane is supported, and that control plane includes		6.3. Path Configuration
	support for control-plane/management-plane hand-off for LSP
	setup/maintenance, the MPLS-TP NE MUST support management of the
	hand-off of Path control. See, for example, references [19] and
	[20].
	Further detailed requirements will be provided along with		1) In addition to the requirement to support static
	progress in defining the MPLS-TP control plane in appropriate		provisioning of transport paths (defined in [7], section 2.1
	specifications.		- General Requirements - requirement 18), an MPLS-TP NE MUST
			support the configuration of required path performance
			characteristic thresholds (e.g. - Loss Measurement <LM>,
			Delay Measurement <DM> thresholds) necessary to support
			performance monitoring of the MPLS-TP service(s).
	If MPLS-TP transport paths cannot be statically provisioned		2) In order to accomplish this, an MPLS-TP NE MUST support
	using MPLS LSP and pseudo-wire management tools (either already		configuration of LSP information (such as an LSP identifier
	defined in standards or under development), further management		of some kind) and/or any other information needed to
	specifications MUST be provided as needed.		retrieve LSP status information, performance attributes,
			etc.
	6.4. Protection Configuration		3) If a control plane is supported, and that control plane
			includes support for control-plane/management-plane hand-off
			for LSP setup/maintenance, the MPLS-TP NE MUST support
			management of the hand-off of Path control. See, for
			example, references [19] and [20].
	The MPLS-TP NE MUST support configuration of required path		4) Further detailed requirements SHALL be provided along with
	protection information as follows:		progress in defining the MPLS-TP control plane in
			appropriate specifications.
	. designate specifically identified LSPs as working or		5) If MPLS-TP transport paths cannot be statically provisioned
	protecting LSPs;		using MPLS LSP and pseudo-wire management tools (either
			already defined in standards or under development), further
			management specifications MUST be provided as needed.
	. define associations of working and protecting paths;		6.4. Protection Configuration
	. operate/release manual protection switching;		1) The MPLS-TP NE MUST support configuration of required path
			protection information as follows:
	. operate/release force protection switching;		. designate specifically identified LSPs as working or
			protecting LSPs;
	. operate/release protection lockout;		. define associations of working and protecting paths;
	. set/retrieve Automatic Protection Switching (APS)		. operate/release manual protection switching;
	parameters, including -
	o Wait to Restore time,		. operate/release force protection switching;
	o Protection Switching threshold information.		. operate/release protection lockout;
	6.5. OAM Configuration		. set/retrieve Automatic Protection Switching (APS)
			parameters, including -
	The MPLS-TP NE MUST support configuration of the OAM entities		o Wait to Restore time,
	and functions specified in [3].
	The MPLS-TP NE MUST support the capability to choose which OAM		o Protection Switching threshold information.
	functions are enabled.
	For enabled OAM functions, the MPLS-TP NE MUST support the		6.5. OAM Configuration
	ability to associate OAM functions with specific maintenance
	entities.
	The MPLS-TP NE MUST support the capability to configure the OAM		1) The MPLS-TP NE MUST support configuration of the OAM
	entities/functions as part of LSP setup and tear-down, including		entities and functions specified in [3].
	co-routed bidirectional point-to-point, associated bidirectional
	point-to-point, and uni-directional (both point-to-point and
	point-to-multipoint) connections.
	The MPLS-TP NE MUST support the configuration of maintenance		2) The MPLS-TP NE MUST support the capability to choose which
	entity identifiers (e.g. MEP ID and MIP ID) for the purpose of		OAM functions are enabled.
	LSP connectivity checking.
	The MPLS-TP NE MUST support configuration of OAM parameters to		3) For enabled OAM functions, the MPLS-TP NE MUST support the
	meet their specific operational requirements, such as whether -		ability to associate OAM functions with specific maintenance
			entities.
	1) one-time on-demand immediately or		4) The MPLS-TP NE MUST support the capability to configure the
			OAM entities/functions as part of LSP setup and tear-down,
			including co-routed bidirectional point-to-point, associated
			bidirectional point-to-point, and uni-directional (both
			point-to-point and point-to-multipoint) connections.
	2) one-time on-demand pre-scheduled or		5) The MPLS-TP NE MUST support the configuration of maintenance
			entity identifiers (e.g. MEP ID and MIP ID) for the purpose
			of LSP connectivity checking.
	3) on-demand periodically based on a specified schedule or		6) The MPLS-TP NE MUST support configuration of OAM parameters
			to meet their specific operational requirements, such as
			whether -
	4) proactive on-going.		a) one-time on-demand immediately or
	The MPLS-TP NE MUST support the enabling/disabling of the		b) one-time on-demand pre-scheduled or
	connectivity check processing. The connectivity check process of
	the MPLS-TP NE MUST support provisioning of the identifiers to
	be transmitted and the expected identifiers.
	7. Performance Management Requirements		c) on-demand periodically based on a specified schedule or
	Performance Management provides functions for the purpose of		d) proactive on-going.
	Maintenance, Bring-into-service, Quality of service, and
	statistics gathering.
	This information could be used, for example, to compare behavior		7) The MPLS-TP NE MUST support the enabling/disabling of the
	of the equipment, MPLS-TP NE or network at different moments in		connectivity check processing. The connectivity check
	time to evaluate changes in network performance.		process of the MPLS-TP NE MUST support provisioning of the
			identifiers to be transmitted and the expected identifiers.
	ITU-T Recommendation G.7710 [1] provides transport performance		7. Performance Management Requirements
	monitoring requirements for packet-switched and circuit-switched
	transport networks with the objective of providing coherent and
	consistent interpretation of the network behavior in a multi-
	technology environment. The performance management requirements
	specified in this document are driven by such an objective.
	7.1. Path Characterization Performance Metrics		Performance Management provides functions for the purpose of
			Maintenance, Bring-into-service, Quality of service, and
			statistics gathering.
	It MUST be possible to determine when an MPLS-TP based transport		This information could be used, for example, to compare behavior
	service is available and when it is unavailable.		of the equipment, MPLS-TP NE or network at different moments in
			time to evaluate changes in network performance.
	From a performance perspective, a service is unavailable if		ITU-T Recommendation G.7710 [1] provides transport performance
	there is an indication that performance has degraded to the		monitoring requirements for packet-switched and circuit-switched
	extent that a configurable performance threshold has been		transport networks with the objective of providing coherent and
	crossed and the degradation persists long enough (i.e. - the		consistent interpretation of the network behavior in a multi-
	indication persists for some amount of time - which is either		technology environment. The performance management requirements
	configurable, or well-known) to be certain it is not a		specified in this document are driven by such an objective.
	measurement anomaly.
	Methods, mechanisms and algorithms for exactly how		7.1. Path Characterization Performance Metrics
	unavailability is to be determined - based on collection of raw
	performance data - are out of scope for this document.
	The MPLS-TP NE MUST support collection and reporting of raw		1) It MUST be possible to determine when an MPLS-TP based
	performance data that MAY be used in determining the		transport service is available and when it is unavailable.
	unavailability of a transport service.
	MPLS-TP MUST support the determination of the unavailability of		From a performance perspective, a service is unavailable if there
	the transport service. The result of this determination MUST be		is an indication that performance has degraded to the extent that
	available via the MPLS-TP NE (at service termination points),		a configurable performance threshold has been crossed and the
	and determination of unavailability MAY be supported by the		degradation persists long enough (i.e. - the indication persists
	MPLS-TP NE directly. To support this requirement, the MPLS-TP NE		for some amount of time - which is either configurable, or well-
	management information model MUST include objects corresponding		known) to be certain it is not a measurement anomaly.
	to availability-state of services.
	Transport network unavailability is based on Severely Errored		Methods, mechanisms and algorithms for exactly how unavailability
	Seconds (SES) and Unavailable Seconds (UAS). ITU-T is		is to be determined - based on collection of raw performance data
	establishing definitions of unavailability generically		- are out of scope for this document.
	applicable to packet transport technologies, including MPLS-TP,
	based on SES and UAS. Note that SES and UAS are already defined
	for Ethernet transport networks in ITU-T Recommendation Y.1563
	[25].
	The MPLS-TP NE MUST support collection of loss measurement (LM)		2) The MPLS-TP NE MUST support collection and reporting of raw
	statistics.		performance data that MAY be used in determining the
			unavailability of a transport service.
	The MPLS-TP NE MUST support collection of delay measurement (DM)		3) MPLS-TP MUST support the determination of the unavailability
	statistics.		of the transport service. The result of this determination
			MUST be available via the MPLS-TP NE (at service termination
			points), and determination of unavailability MAY be
			supported by the MPLS-TP NE directly. To support this
			requirement, the MPLS-TP NE management information model
			MUST include objects corresponding to availability-state of
			services.
	The MPLS-TP NE MUST support reporting of Performance degradation		Transport network unavailability is based on Severely Errored
	via fault management for corrective actions. "Reporting" in this		Seconds (SES) and Unavailable Seconds (UAS). ITU-T is
	context could mean:		establishing definitions of unavailability generically applicable
			to packet transport technologies, including MPLS-TP, based on SES
			and UAS. Note that SES and UAS are already defined for Ethernet
			transport networks in ITU-T Recommendation Y.1563 [25].
	. reporting to an autonomous protection component to trigger		4) The MPLS-TP NE MUST support collection of loss measurement
	protection switching,		(LM) statistics.
	. reporting via a craft interface to allow replacement of a		5) The MPLS-TP NE MUST support collection of delay measurement
	faulty component (or similar manual intervention),		(DM) statistics.
	. etc.		6) The MPLS-TP NE MUST support reporting of Performance
			degradation via fault management for corrective actions.
	The MPLS-TP NE MUST support reporting of performance statistics		"Reporting" in this context could mean:
	on request from a management system.
	7.2. Performance Measurement Instrumentation		. reporting to an autonomous protection component to
			trigger protection switching,
	7.2.1. Measurement Frequency		. reporting via a craft interface to allow replacement of a
			faulty component (or similar manual intervention),
	For performance measurement mechanisms that support both		. etc.
	proactive and on-demand modes, the MPLS-TP NE MUST support the
	capability to be configured to operate on-demand or proactively.
	7.2.2. Measurement Scope		7) The MPLS-TP NE MUST support reporting of performance
			statistics on request from a management system.
	On measurement of packet loss and loss ratio:		7.2. Performance Measurement Instrumentation
	. For bidirectional (both co-routed and associated) P2P		7.2.1. Measurement Frequency
	connections:
	o on-demand measurement of single-ended packet loss, and		1) For performance measurement mechanisms that support both
	loss ratio, measurement is REQUIRED;		proactive and on-demand modes, the MPLS-TP NE MUST support
			the capability to be configured to operate on-demand or
			proactively.
	o proactive measurement of packet loss, and loss ratio,		7.2.2. Measurement Scope
	measurement for each direction is REQUIRED.
	. for unidirectional (P2P and P2MP) connection, proactive		On measurement of packet loss and loss ratio:
	measurement of packet loss, and loss ratio, is REQUIRED.
	On Delay measurement:		1) For bidirectional (both co-routed and associated) P2P
			connections -
	. for unidirectional (P2P and P2MP) connection, on-demand		a) on-demand measurement of single-ended packet loss, and
	measurement of delay measurement is REQUIRED.		loss ratio, measurement is REQUIRED;
	. for co-routed bidirectional (P2P) connection, on-demand		b) proactive measurement of packet loss, and loss ratio,
	measurement of one-way and two-way delay is REQUIRED.		measurement for each direction is REQUIRED.
	. for associated bidirectional (P2P) connection, on-demand		2) For unidirectional (P2P and P2MP) connection, proactive
	measurement of one-way delay is REQUIRED.		measurement of packet loss, and loss ratio, is REQUIRED.
	8. Security Management Requirements		On Delay measurement:
	The MPLS-TP NE MUST support secure management and control		3) For unidirectional (P2P and P2MP) connection, on-demand
	planes.		measurement of delay measurement is REQUIRED.
	8.1. Management Communication Channel Security		4) For co-routed bidirectional (P2P) connection, on-demand
			measurement of one-way and two-way delay is REQUIRED.
	Secure communication channels MUST be supported for all network		5) For associated bidirectional (P2P) connection, on-demand
	traffic and protocols used to support management functions.		measurement of one-way delay is REQUIRED.
	This MUST include, at least, protocols used for configuration,
	monitoring, configuration backup, logging, time synchronization,
	authentication, and routing. The MCC MUST support application
	protocols that provide confidentiality and data integrity
	protection.
	The MPLS-TP NE MUST support the following:		8. Security Management Requirements
	- Use of open cryptographic algorithms (See RFC 3871 [4])		1) The MPLS-TP NE MUST support secure management and control
			planes.
	- Authentication - allow management connectivity only from		8.1. Management Communication Channel Security
	authenticated entities.
	- Authorization - allow management activity originated by an		1) Secure communication channels MUST be supported for all
	authorized entity, using (for example) an Access Control		network traffic and protocols used to support management
	List (ACL).		functions. This MUST include, at least, protocols used for
			configuration, monitoring, configuration backup, logging,
			time synchronization, authentication, and routing.
	- Port Access Control - allow management activity received on		2) The MCC MUST support application protocols that provide
	an authorized (management) port.		confidentiality and data integrity protection.
	8.2. Signaling Communication Channel Security		3) The MPLS-TP NE MUST support the following:
	Security requirements for the SCC are driven by considerations		a) Use of open cryptographic algorithms (See RFC 3871 [4])
	similar to MCC requirements described in section 8.1.
	Security Requirements for the control plane are out of scope for		b) Authentication - allow management connectivity only from
	this document and are expected to be defined in the appropriate		authenticated entities.
	control plane specifications.
	Management of control plane security MUST also be defined at		c) Authorization - allow management activity originated by an
	that time.		authorized entity, using (for example) an Access Control
			List (ACL).
	8.3. Distributed Denial of Service		d) Port Access Control - allow management activity received
			on an authorized (management) port.
	A Denial of Service (DoS) attack is an attack that tries to		8.2. Signaling Communication Channel Security
	prevent a target from performing an assigned task, or providing
	its intended service(s), through any means. A Distributed DoS
	(DDoS) can multiply attack severity (possibly by an arbitrary
	amount) by using multiple (potentially compromised) systems to
	act as topologically (and potentially geographically)
	distributed attack sources. It is possible to lessen the impact
	and potential for DoS and DDoS by using secure protocols,
	turning off unnecessary processes, logging and monitoring, and
	ingress filtering. RFC 4732 [26] provides background on DOS in
	the context of the Internet.
	An MPLS-TP NE MUST support secure management protocols and		Security requirements for the SCC are driven by considerations
	SHOULD do so in a manner the reduce potential impact of a DoS		similar to MCC requirements described in section 8.1.
	attack.
	An MPLS-TP NE SHOULD support additional mechanisms that mitigate		Security Requirements for the control plane are out of scope for
	a DoS (or DDoS) attack against the management component while		this document and are expected to be defined in the appropriate
	allowing the NE to continue to meet its primary functions.		control plane specifications.
	9. Security Considerations		1) Management of control plane security MUST be defined in the
			appropriate control plane specifications..
	Section 8 includes a set of security requirements that apply to		8.3. Distributed Denial of Service
	MPLS-TP network management.
	Solutions MUST provide mechanisms to prevent unauthorized and/or		A Denial of Service (DoS) attack is an attack that tries to
	unauthenticated access to management capabilities and private		prevent a target from performing an assigned task, or providing
	information by network elements, systems or users.		its intended service(s), through any means. A Distributed DoS
			(DDoS) can multiply attack severity (possibly by an arbitrary
			amount) by using multiple (potentially compromised) systems to
			act as topologically (and potentially geographically) distributed
			attack sources. It is possible to lessen the impact and potential
			for DoS and DDoS by using secure protocols, turning off
			unnecessary processes, logging and monitoring, and ingress
			filtering. RFC 4732 [26] provides background on DoS in the
			context of the Internet.
	Performance of diagnostic functions and path characterization		1) An MPLS-TP NE MUST support secure management protocols and
	involves extracting a significant amount of information about		SHOULD do so in a manner that reduces potential impact of a
	network construction that the network operator might consider		DoS attack.
	private.
	10. IANA Considerations		2) An MPLS-TP NE SHOULD support additional mechanisms that
			mitigate a DoS (or DDoS) attack against the management
			component while allowing the NE to continue to meet its
			primary functions.
	There are no IANA actions associated with this document.		9. Security Considerations
	11. Acknowledgments		Section 8 includes a set of security requirements that apply to
			MPLS-TP network management.
	The authors/editors gratefully acknowledge the thoughtful		1) Solutions MUST provide mechanisms to prevent unauthorized
	review, comments and explanations provided by Adrian Farrel,		and/or unauthenticated access to management capabilities and
	Alexander Vainshtein, Andrea Maria Mazzini, Ben Niven-Jenkins,		private information by network elements, systems or users.
	Bernd Zeuner, Dan Romascanu, Daniele Ceccarelli, Diego Caviglia,
	Dieter Beller, He Jia, Leo Xiao, Maarten Vissers, Neil Harrison,
	Rolf Winter, Yoav Cohen and Yu Liang.
	12. References		Performance of diagnostic functions and path characterization
			involves extracting a significant amount of information about
			network construction that the network operator might consider
			private.
	12.1. Normative References		10. IANA Considerations
	[1] ITU-T Recommendation G.7710/Y.1701, "Common equipment		There are no IANA actions associated with this document.
	management function requirements", July, 2007.
	[2] Nadeau, T., et al, "Operations and Management (OAM)		11. Acknowledgments
	Requirements for Multi-Protocol Label Switched (MPLS)
	Networks", RFC 4377, February 2006.
	[3] Vigoureux, M., et al, "Requirements for OAM in MPLS		The authors/editors gratefully acknowledge the thoughtful review,
	Transport Networks", draft-ietf-mpls-tp-oam-requirements,		comments and explanations provided by Adrian Farrel, Alexander
	work in progress.		Vainshtein, Andrea Maria Mazzini, Ben Niven-Jenkins, Bernd
			Zeuner, Dan Romascanu, Daniele Ceccarelli, Diego Caviglia, Dieter
			Beller, He Jia, Leo Xiao, Maarten Vissers, Neil Harrison, Rolf
			Winter, Yoav Cohen and Yu Liang.
	[4] Jones, G., "Operational Security Requirements for Large		12. References
	Internet Service Provider (ISP) IP Network
	Infrastructure", RFC 3871, September 2004.
	[5] Bradner, S., "Key words for use in RFCs to Indicate		12.1. Normative References
	Requirement Levels", RFC 2119, March 1997.
	[6] ITU-T Recommendation G.7712/Y.1703, "Architecture and		[1] ITU-T Recommendation G.7710/Y.1701, "Common equipment
	specification of data communication network", June 2008.		management function requirements", July, 2007.
	[7] Niven-Jenkins, B. et al, "MPLS-TP Requirements", draft-		[2] Nadeau, T., et al, "Operations and Management (OAM)
	ietf-mpls-tp-requirements, work in progress.		Requirements for Multi-Protocol Label Switched (MPLS)
			Networks", RFC 4377, February 2006.
	12.2. Informative References		[3] Vigoureux, M., et al, "Requirements for OAM in MPLS
			Transport Networks", draft-ietf-mpls-tp-oam-requirements,
			work in progress.
	[8] Beller, D., et al, "An Inband Data Communication Network		[4] Jones, G., "Operational Security Requirements for Large
	For the MPLS Transport Profile", draft-ietf-mpls-tp-gach-		Internet Service Provider (ISP) IP Network Infrastructure",
	dcn, work in progress.		RFC 3871, September 2004.
	[9] Chisholm, S. and D. Romascanu, "Alarm Management		[5] Bradner, S., "Key words for use in RFCs to Indicate
	Information Base (MIB)", RFC 3877, September 2004.		Requirement Levels", RFC 2119, March 1997.
	[10] ITU-T Recommendation M.20, "Maintenance philosophy for		[6] ITU-T Recommendation G.7712/Y.1703, "Architecture and
	telecommunication networks", October 1992.		specification of data communication network", June 2008.
	[11] Telcordia, "Network Maintenance: Network Element and		[7] Niven-Jenkins, B. et al, "MPLS-TP Requirements", draft-
	Transport Surveillance Messages" (GR-833-CORE), Issue 5,		ietf-mpls-tp-requirements, work in progress.
	August 2004.
	[12] Bocci, M. et al, "A Framework for MPLS in Transport		[8] Bocci, M. et al, "A Framework for MPLS in Transport
	Networks", draft-ietf-mpls-tp-framework, work in progress.		Networks", draft-ietf-mpls-tp-framework, work in progress.
	[13] Bocci, M. et al, "MPLS Generic Associated Channel", RFC		[9] Mansfield, S. et al, "MPLS-TP Network Management
	5586, June 2009.		Framework", draft-ietf-mpls-tp-nm-framework, work in
			progress.
	[14] Harrington, D., "Guidelines for Considering Operations and		12.2. Informative References
	Management of New Protocols and Protocol Extensions",
	draft-ietf-opsawg-operations-and-management, work in
	progress.
	[15] Mansfield, S. et al, "MPLS-TP Network Management		[10] Beller, D., et al, "An Inband Data Communication Network
	Framework", draft-ietf-mpls-tp-nm-framework, work in		For the MPLS Transport Profile", draft-ietf-mpls-tp-gach-
	progress.		dcn, work in progress.
	[16] Enns, R. et al, "NETCONF Configuration Protocol",		[11] Chisholm, S. and D. Romascanu, "Alarm Management
	draft-ietf-netconf-4741bis, work in progress.		Information Base (MIB)", RFC 3877, September 2004.
	[17] McCloghrie, K. et al, "Structure of Management Information		[12] ITU-T Recommendation M.20, "Maintenance philosophy for
	Version 2 (SMIv2)", RFC 2578, April 1999.		telecommunication networks", October 1992.
	[18] OMG Document formal/04-03-12, "The Common Object Request		[13] Telcordia, "Network Maintenance: Network Element and
	Broker: Architecture and Specification", Revision 3.0.3.		Transport Surveillance Messages" (GR-833-CORE), Issue 5,
	March 12, 2004.		August 2004.
	[19] Caviglia, D. et al, "Requirements for the Conversion		[14] Bocci, M. et al, "MPLS Generic Associated Channel", RFC
	between Permanent Connections and Switched Connections in		5586, June 2009.
	a Generalized Multiprotocol Label Switching (GMPLS)
	Network", RFC 5493, April 2009.
	[20] Caviglia, D. et al, "RSVP-TE Signaling Extension For The		[15] Harrington, D., "Guidelines for Considering Operations and
	Conversion Between Permanent Connections And Soft		Management of New Protocols and Protocol Extensions",
	Permanent Connections In A GMPLS Enabled Transport		draft-ietf-opsawg-operations-and-management, work in
	Network", draft-ietf-ccamp-pc-spc-rsvpte-ext, work in		progress.
	progress.
	[21] ITU-T Recommendation G.806, "Characteristics of transport		[16] Enns, R. et al, "NETCONF Configuration Protocol", draft-
	equipment - Description methodology and generic		ietf-netconf-4741bis, work in progress.
	functionality", January, 2009.
	[22] ITU-T Recommendation Y.1731, "OAM functions and mechanisms		[17] Presuhn, R. et al, "Version 2 of the Protocol Operations
	for Ethernet based networks", February, 2008.		for the Simple Network Management Protocol (SNMP)", RFC
			3416, December 2002.
	[23] ITU-T Recommendation G.8601, "Architecture of service		[18] OMG Document formal/04-03-12, "The Common Object Request
	management in multi bearer, multi carrier environment",		Broker: Architecture and Specification", Revision 3.0.3.
	June 2006.		March 12, 2004.
	[24] Lam, H., et al, "Alarm Reporting Control Management		[19] Caviglia, D. et al, "Requirements for the Conversion
	Information Base (MIB)", RFC 3878, September 2004.		between Permanent Connections and Switched Connections in a
			Generalized Multiprotocol Label Switching (GMPLS) Network",
			RFC 5493, April 2009.
	[25] ITU-T Recommendation Y.1563, "Ethernet frame transfer and		[20] Caviglia, D. et al, "RSVP-TE Signaling Extension For The
	availability performance", January 2009.		Conversion Between Permanent Connections And Soft Permanent
			Connections In A GMPLS Enabled Transport Network", draft-
			ietf-ccamp-pc-spc-rsvpte-ext, work in progress.
	[26] Handley, M., et al, "Internet Denial-of-Service		[21] ITU-T Recommendation G.806, "Characteristics of transport
	Considerations", RFC 4732, November 2006.		equipment - Description methodology and generic
			functionality", January, 2009.
	Editors' Addresses		[22] ITU-T Recommendation Y.1731, "OAM functions and mechanisms
			for Ethernet based networks", February, 2008.
	Eric Gray		[23] ITU-T Recommendation G.8601, "Architecture of service
	Ericsson		management in multi bearer, multi carrier environment",
	900 Chelmsford Street		June 2006.
	Lowell, MA, 01851
	Phone: +1 978 275 7470
	Email: Eric.Gray@Ericsson.com
	Scott Mansfield		[24] Lam, H., et al, "Alarm Reporting Control Management
	Ericsson		Information Base (MIB)", RFC 3878, September 2004.
	250 Holger Way
	San Jose CA, 95134
	+1 724 931 9316
	EMail: Scott.Mansfield@Ericsson.com
	Hing-Kam (Kam) Lam		[25] ITU-T Recommendation Y.1563, "Ethernet frame transfer and
	Alcatel-Lucent		availability performance", January 2009.
	600-700 Mountain Ave
	Murray Hill, NJ, 07974
	Phone: +1 908 582 0672
	Email: hklam@Alcatel-Lucent.com
	Contributor's Address		[26] Handley, M., et al, "Internet Denial-of-Service
			Considerations", RFC 4732, November 2006.
	Adrian Farrel		Authors' Addresses
	Old Dog Consulting
	Email: adrian@olddog.co.uk
	Copyright Statement		Eric Gray
			Ericsson
			900 Chelmsford Street
			Lowell, MA, 01851
			Phone: +1 978 275 7470
			Email: Eric.Gray@Ericsson.com
	Copyright (c) 2009 IETF Trust and the persons identified as the		Scott Mansfield
	document authors. All rights reserved.		Ericsson
			250 Holger Way
			San Jose CA, 95134
			+1 724 931 9316
			EMail: Scott.Mansfield@Ericsson.com
	This document is subject to BCP 78 and the IETF Trust's Legal		Hing-Kam (Kam) Lam
	Provisions Relating to IETF Documents in effect on the date of		Alcatel-Lucent
	publication of this document (http://trustee.ietf.org/license-		600-700 Mountain Ave
	info). Please review these documents carefully, as they		Murray Hill, NJ, 07974
	describe your rights and restrictions with respect to this		Phone: +1 908 582 0672
	document.		Email: hklam@Alcatel-Lucent.com
	Acknowledgment		Contributor's Address
	Funding for the RFC Editor function is currently provided by the		Adrian Farrel
	Internet Society.		Old Dog Consulting
			Email: adrian@olddog.co.uk
	Appendix A- Communication Channel (CCh) Examples		Copyright Statement
	A CCh may be realized in a number of ways.		Copyright (c) 2009 IETF Trust and the persons identified as the
			document authors. All rights reserved.
	1. The CCh may be provided by a link in a physically distinct		This document is subject to BCP 78 and the IETF Trust's Legal
	network. That is, a link that is not part of the transport		Provisions Relating to IETF Documents in effect on the date of
	network that is being managed. For example, the nodes in the		publication of this document (http://trustee.ietf.org/license-
	transport network may be interconnected in two distinct physical		info). Please review these documents carefully, as they describe
	networks: the transport network and the DCN.		your rights and restrictions with respect to this document.
	This is a "physically distinct out-of-band CCh".		Acknowledgment
	2. The CCh may be provided by a link in the transport network		Funding for the RFC Editor function is currently provided by the
	that is terminated at the ends of the CCh and which is capable		Internet Society.
	of encapsulating and terminating packets of the management
	protocols. For example, in MPLS-TP a single-hop LSP might be
	established between two adjacent nodes, and that LSP might be
	capable of carrying IP traffic. Management traffic can then be
	inserted into the link in an LSP parallel to the LSPs that carry
	user traffic.
	This is a "physically shared out-of-band CCh."		Appendix A- Communication Channel (CCh) Examples
	3. The CCh may be supported as its native protocol on the		A CCh can be realized in a number of ways.
	interface alongside the transported traffic. For example, if an
	interface is capable of sending and receiving both MPLS-TP and
	IP, the IP-based management traffic can be sent as native IP
	packets on the interface.
	This is a "shared interface out-of-band CCh".		1. The CCh can be provided by a link in a physically distinct
			network. That is, a link that is not part of the transport
			network that is being managed. For example, the nodes in the
			transport network can be interconnected in two distinct physical
			networks: the transport network and the DCN.
	4. The CCh may use overhead bytes available on a transport		This is a "physically distinct out-of-band CCh".
	connection. For example, in TDM networks there are overhead
	bytes associated with a data channel, and these can be used to
	provide a CCh. It is important to note that the use of overhead
	bytes does not reduce the capacity of the associated data
	channel.
	This is an "overhead-based CCh".		2. The CCh can be provided by a link in the transport network
			that is terminated at the ends of the DCC and which is capable of
			encapsulating and terminating packets of the management
			protocols. For example, in MPLS-TP a single-hop LSP might be
			established between two adjacent nodes, and that LSP might be
			capable of carrying IP traffic. Management traffic can then be
			inserted into the link in an LSP parallel to the LSPs that carry
			user traffic.
	This alternative is not available in MPLS-TP because there is no		This is a "physically shared out-of-band CCh."
	overhead available.
	5. The CCh may provided by a dedicated channel associated with		3. The CCh can be supported as its native protocol on the
	the data link. For example, the generic associated label (GAL)		interface alongside the transported traffic. For example, if an
	[13] may be used to label CCh traffic being exchanged on a data		interface is capable of sending and receiving both MPLS-TP and
	link between adjacent transport nodes, potentially in the		IP, the IP-based management traffic can be sent as native IP
	absence of any data LSP between those nodes.		packets on the interface.
	This is a "data link associated CCh".		This is a "shared interface out-of-band CCh".
	It is very similar to case 2, and by its nature can only span a		4. The CCh can use overhead bytes available on a transport
	single hop in the transport network.		connection. For example, in TDM networks there are overhead bytes
			associated with a data channel, and these can be used to provide
			a CCh. It is important to note that the use of overhead bytes
			does not reduce the capacity of the associated data channel.
	6. The CCh may be provided by a dedicated channel associated		This is an "overhead-based CCh".
	with a data channel. For example, in MPLS-TP the GAL [13] may be
	imposed under the top label in the label stack for an MPLS-TP
	LSP to create a channel associated with the LSP that may carry
	management traffic. This CCh requires the receiver to be capable
	of demultiplexing management traffic from user traffic carried
	on the same LSP by use of the GAL.
	This is a "data channel associated CCh".		This alternative is not available in MPLS-TP because there is no
			overhead available.
	7. The CCh may be provided by mixing the management traffic with		5. The CCh can provided by a dedicated channel associated with
	the user traffic such that is indistinguishable on the link		the data link. For example, the generic associated label (GAL)
	without deep-packet inspection. In MPLS-TP this could arise if		[14] can be used to label DCC traffic being exchanged on a data
	there is a data-carrying LSP between two nodes, and management		link between adjacent transport nodes, potentially in the absence
	traffic is inserted into that LSP. This approach requires that		of any data LSP between those nodes.
	the termination point of the LSP is able to demultiplex the
	management and user traffic. Such might be possible in MPLS-TP
	if the MPLS-TP LSP was carrying IP user traffic.
	This is an "in-band CCh".		This is a "data link associated CCh".
	These realizations may be categorized as:		It is very similar to case 2, and by its nature can only span a
			single hop in the transport network.
	A. Out-of-fiber, out-of-band (types 1 and 2)		6. The CCh can be provided by a dedicated channel associated with
	B. In-fiber, out-of-band (types 2, 3, 4, and 5)		a data channel. For example, in MPLS-TP the GAL [14] can be
	C. In-band (types 6 and 7)		imposed under the top label in the label stack for an MPLS-TP LSP
			to create a channel associated with the LSP that can carry
			management traffic. This CCh requires the receiver to be capable
			of demultiplexing management traffic from user traffic carried on
			the same LSP by use of the GAL.
	The MCN and SCN are logically separate networks and may be		This is a "data channel associated CCh".
	realized by the same DCN or as separate networks. In practice,
	that means that, between any pair of nodes, the MCC and SCC may
	be the same link or separate links.
	It is also important to note that the MCN and SCN do not need to		7. The CCh can be provided by mixing the management traffic with
	be categorised as in-band, out-of-band, etc. This definition		the user traffic such that is indistinguishable on the link
	only applies to the individual links, and it is possible for		without deep-packet inspection. In MPLS-TP this could arise if
	some nodes to be connected in the MCN or SCN by one type of		there is a data-carrying LSP between two nodes, and management
	link, and other nodes by other types of link. Furthermore, a		traffic is inserted into that LSP. This approach requires that
	pair of adjacent nodes may be connected by multiple links of		the termination point of the LSP is able to demultiplex the
	different types.		management and user traffic. Such might be possible in MPLS-TP if
			the MPLS-TP LSP was carrying IP user traffic.
	Lastly note that the division of DCN traffic between links		This is an "in-band CCh".
	between a pair of adjacent nodes is purely an implementation
	choice. Parallel links may be deployed for DCN resilience or
	load sharing. Links may be designated for specific use. For
	example, so that some links carry management traffic and some
	carry control plane traffic, or so that some links carry
	signaling protocol traffic while others carry routing protocol
	traffic.
	It should be noted that the DCN may be a routed network with		These realizations can be categorized as:
	forwarding capabilities, but that this is not a requirement. The
	ability to support forwarding of management or control traffic
	within the DCN may substantially simplify the topology of the
	DCN and improve its resilience, but does increase the complexity
	of operating the DCN.
	See also RFC 3877 [9], ITU-T M.20 [10], and Telcordia document		A. Out-of-fiber, out-of-band (types 1 and 2)
	GR-833-CORE [11] for further information.		B. In-fiber, out-of-band (types 2, 3, 4, and 5)
			C. In-band (types 6 and 7)
			The MCN and SCN are logically separate networks and can be
			realized by the same DCN or as separate networks. In practice,
			that means that, between any pair of nodes, the MCC and SCC can
			be the same link or separate links.
			It is also important to note that the MCN and SCN do not need to
			be categorised as in-band, out-of-band, etc. This definition only
			applies to the individual links, and it is possible for some
			nodes to be connected in the MCN or SCN by one type of link, and
			other nodes by other types of link. Furthermore, a pair of
			adjacent nodes can be connected by multiple links of different
			types.
			Lastly note that the division of DCN traffic between links
			between a pair of adjacent nodes is purely an implementation
			choice. Parallel links can be deployed for DCN resilience or load
			sharing. Links can be designated for specific use. For example,
			so that some links carry management traffic and some carry
			control plane traffic, or so that some links carry signaling
			protocol traffic while others carry routing protocol traffic.
			It is important to note that the DCN can be a routed network with
			forwarding capabilities, but that this is not a requirement. The
			ability to support forwarding of management or control traffic
			within the DCN can substantially simplify the topology of the DCN
			and improve its resilience, but does increase the complexity of
			operating the DCN.
			See also RFC 3877 [11], ITU-T M.20 [12], and Telcordia document
			GR-833-CORE [13] for further information.
End of changes. 269 change blocks.
	810 lines changed or deleted		790 lines changed or added
This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/