draft-ietf-mpls-tp-nm-req-02.txt		draft-ietf-mpls-tp-nm-req-03.txt
	Network Working Group Hing-Kam Lam		Network Working Group Hing-Kam Lam
	Internet Draft Alcatel-Lucent		Internet Draft Alcatel-Lucent
	Expires: December, 2009 Scott Mansfield		Expires: March, 2010 Scott Mansfield
	Intended Status: Standards Track Eric Gray		Intended Status: Standards Track Eric Gray
	Ericsson		Ericsson
	June 24, 2009		August 31, 2009
	MPLS TP Network Management Requirements		MPLS TP Network Management Requirements
	draft-ietf-mpls-tp-nm-req-02.txt		draft-ietf-mpls-tp-nm-req-03.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 December 24, 2009.		This Internet-Draft will expire on March 31, 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.......6
	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 ..........................10
	5.3.3. Alarm Reporting..................................11		5.3.3. Alarm Reporting............................10
	5.3.4. Alarm Reporting Control..........................11		5.3.4. Alarm Reporting Control.....................11
	6. Configuration Management Requirements......................11		6. Configuration Management Requirements..................11
	6.1. System Configuration..................................12		6.1. System Configuration............................11
	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...............................13
	7. Performance Management Requirements........................14		7. Performance Management Requirements....................14
	7.1. Path Characterization Performance Metrics.............14		7.1. Path Characterization Performance Metrics..........14
	7.2. Performance Measurement Instrumentation...............15		7.2. Performance Measurement Instrumentation............16
	7.2.1. Measurement Frequency............................15		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......................16
	8.1. Management Communication Channel Security.............16		8.1. Management Communication Channel Security..........16
	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 ....................17
	9. Security Considerations....................................18		9. Security Considerations..............................18
	10. IANA Considerations.......................................18		10. IANA Considerations................................18
	11. Acknowledgments...........................................18		11. Acknowledgments....................................18
	12. References................................................18		12. References........................................18
	12.1. Normative References.................................18		12.1. Normative References...........................18
	12.2. Informative References...............................19		12.2. Informative References..........................19
	Author's Addresses............................................21		Author's Addresses.....................................21
	Copyright Statement...........................................21		Copyright Statement....................................21
	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 ITU-T G.7710/Y.1701 [1] and RFC 4377 [2], and attempts to		in ITU-T G.7710/Y.1701 [1] and RFC 4377 [2], and attempts to
	comply with best common practice as defined in [18].		comply with best common practice as defined in [14].
	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.
	skipping to change at page 3, line 49		skipping to change at page 3, line 49
	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 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 [19] and [20].		familiar with references [12] and [15].
	1.1. Terminology		1.1. Terminology
	Although this document is not a protocol specification, the key		Although this document is not a protocol specification, 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		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
	this document are to be interpreted as described in RFC 2119 [6]		this document are to be interpreted as described in RFC 2119 [5]
	and are to be interpreted as instructions to protocol designers		and are to be interpreted as instructions to protocol designers
	producing solutions that satisfy the requirements set out in		producing 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 ([27], 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 (physical layer), Layer 2 (data-link layer), and Layer 3		1 (physical layer), Layer 2 (data-link layer), and Layer 3
	(network layer) functionality for distributed management		(network layer) functionality for distributed management
	communications related to the management plane, for distributed		communications related to the management plane, for distributed
	signaling communications related to the control plane, and other		signaling communications related to the control plane, and other
	operations communications (e.g., order-wire/voice		operations communications (e.g., order-wire/voice
	communications, software downloads, etc.).		communications, software 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 of consequent actions, and the determination of fault		control of consequent actions, and the determination of fault
	cause ([27], 3.24).		cause (from [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 been detected ([27], 3.25).		now 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 ([27], 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 is representative of the disturbance or fault that is		that is representative of the disturbance or fault that is
	causing the problem ([27], 3.27).		causing the 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 MPLS necessary to participate in an MPLS-TP based transport		of MPLS necessary to participate in an MPLS-TP based transport
	service. See [24] for further information on functionality		service. See [8] 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 ([28] - 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 during the diagnostic time interval.		actions 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 support processing of information related to operations,		that 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
	skipping to change at page 6, line 17		skipping to change at page 6, line 17
	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 which management interface
	protocol should be used as the standard protocol for managing		protocol should be used as the standard protocol for managing
	MPLS-TP networks. Managing an end-to-end connection across		MPLS-TP networks. Managing an end-to-end connection across
	multiple operator domains where one domain is managed (for		multiple operator domains where one domain is managed (for
	example) via NETCONF/XML ([21]) or SNMP/SMI ([22]), and another		example) via NETCONF/XML ([16]) or SNMP/SMI ([17]), and another
	domain via CORBA/IDL ([23]), is allowed.		domain via CORBA/IDL ([18]), is allowed.
	For the management interface to the management system, an MPLS-		For the management interface to the management system, an MPLS-
	TP NE MAY actively support more than one management protocol in		TP NE MAY actively support more than one management protocol in
	any given deployment. For example, an MPLS-TP NE may use one		any given deployment. For example, an MPLS-TP NE may use one
	protocol for configuration and another for monitoring. The		protocol for configuration and another for monitoring. The
	protocols to be supported are at the discretion of the operator.		protocols to be supported are at the discretion of the operator.
	3. Management Communication Channel (MCC) Requirements		3. Management Communication Channel (MCC) Requirements
	Specifications SHOULD define support for management connectivity		Specifications SHOULD define support for management connectivity
	with remote MPLS-TP domains and NEs, as well as with termination		with remote MPLS-TP domains and NEs, as well as with termination
	points located in NEs under the control of a third party network		points located in NEs under the control of a third party network
	operator. See ITU-T G.8601 [8] for example scenarios in multi-		operator. See ITU-T G.8601 [23] for example scenarios in multi-
	carrier multi-transport-technology environments.		carrier multi-transport-technology environments.
	For management purpose, every MPLS-TP NE MUST connect to an OS.		For management purpose, every MPLS-TP NE MUST connect to an OS.
	The connection MAY be direct (e.g. - via a software, hardware or		The connection MAY be direct (e.g. - via a software, hardware or
	proprietary protocol connection) or indirect (via another MPLS-		proprietary protocol connection) or indirect (via another MPLS-
	TP NE). In this document, any management connection that is not		TP NE). In this document, any management connection that is not
	via another MPLS-TP NE is a direct management connection. When		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		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		supported between that MPLS-TP NE and any MPLS-TP NE(s) used to
	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 ([10]) defines a Generic Associated Channel (G-ACh) to		RFC 5586 (Error! Reference source not found.) defines a Generic
	enable the realization of a communication channel (CCh) between		Associated Channel (G-ACh) to enable the realization of a
	adjacent MPLS-TP NEs for management and control. Reference [11]		communication channel (CCh) between adjacent MPLS-TP NEs for
	describes how the G-ACh may be used to provide infrastructure		management and control. Reference [7] describes how the G-ACh
	that forms part of the MCN and a SCN. It also explains how MCN		may be used to provide infrastructure that forms part of the MCN
	and SCN messages are encapsulated, carried on the G-ACh, and		and SCN. It also explains how MCN and SCN messages are
	demultiplexed for delivery to management or signaling/routing		encapsulated, carried on the G-ACh, and decapsulated for
	control plane components on a label switching router (LSR).		delivery to management or signaling/routing control plane
			components on a label switching router (LSR).
	ITU-T G.7712/Y.1703 [7], 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 [7]) 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;
	- MPLS-TP MCC data-link layer termination functions specified		- MPLS-TP MCC data-link layer termination functions specified
	in section 7.1.2.4;		in section 7.1.2.4;
	- Network layer PDU into CCh data-link frame encapsulation		- Network layer PDU into CCh data-link frame encapsulation
	functions specified in section 7.1.3;		functions specified in section 7.1.3;
	- Network layer PDU forwarding (7.1.6), interworking (7.1.7)		- Network layer PDU forwarding (7.1.6), interworking (7.1.7)
	and encapsulation (7.1.8) functions, as well as tunneling		and encapsulation (7.1.8) functions, as well as tunneling
	(7.1.9) and routing (7.1.10) functions specified in [7].		(7.1.9) and routing (7.1.10) functions specified in [6].
	As a practical matter, MCN connections will typically have		As a practical matter, MCN connections will typically have
	addresses. See the section on addressing in [15] for further		addresses. See the section on addressing in [15] for further
	information.		information.
	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.
	5.1. Supervision Function		5.1. Supervision Function
	The supervision function analyses the actual occurrence of a		The supervision function analyses the actual occurrence of a
	disturbance or fault for the purpose of providing an appropriate		disturbance or fault for the purpose of providing an appropriate
	indication of performance and/or detected fault condition to		indication of performance and/or detected fault condition to
	maintenance personnel and operations systems.		maintenance personnel and operations systems.
	The MPLS-TP NE MUST support supervision of the OAM mechanisms		The MPLS-TP NE MUST support supervision of the OAM mechanisms
	that are deployed for supporting the OAM requirements defined in		that are deployed for supporting the OAM requirements defined in
	[3].		[1].
	The MPLS-TP NE MUST support the following data-plane forwarding		The MPLS-TP NE MUST support the following data-plane forwarding
	path supervision functions:		path supervision functions:
	- Supervision of loop-checking functions used to detect loops		. Supervision of loop-checking functions used to detect loops
	in the data-plane forwarding path (which result in non-		in the data-plane forwarding path (which result in non-
	delivery of traffic, wasting of forwarding resources and		delivery of traffic, wasting of forwarding resources and
	unintended self-replication of traffic);		unintended self-replication of traffic);
	- Supervision of failure detection;		. Supervision of failure detection;
	The MPLS-TP NE MUST support the capability to configure data-		The MPLS-TP NE MUST support the capability to configure data-
	plane forwarding path related supervision mechanisms to perform		plane forwarding path related supervision mechanisms to perform
	on-demand or proactively.		on-demand or proactively.
	The MPLS-TP NE MUST support supervision for software processing		The MPLS-TP NE MUST support supervision for software processing
	e.g., processing faults, storage capacity, version mismatch,		e.g., processing faults, storage capacity, version mismatch,
	corrupted data and out of memory problems, etc.		corrupted data and out of memory problems, etc.
	The MPLS-TP NE MUST support hardware-related supervision for		The MPLS-TP NE MUST support hardware-related supervision for
	skipping to change at page 10, line 5		skipping to change at page 10, line 8
	Time-C = 10 +/- 0.5 seconds		Time-C = 10 +/- 0.5 seconds
	These time values are as defined in G.7710 [1].		These time values are as defined in G.7710 [1].
	MIBs - or other object management semantics specifications -		MIBs - or other object management semantics specifications -
	defined to enable configuration of these timers SHOULD		defined to enable configuration of these timers SHOULD
	explicitly provide default values and MAY provide guidelines on		explicitly provide default values and MAY provide guidelines on
	ranges and value determination methods for scenarios where the		ranges and value determination methods for scenarios where the
	default value chosen might be inadequate. In addition, such		default value chosen might be inadequate. In addition, such
	specifications SHOULD define the level of granularity at which		specifications SHOULD define the level of granularity at which
	tables of these values are to be defined. Examples of levels of		tables of these values are to be defined.
	granularity MAY include per-failure-cause and per-deduced-fault.
	Implementations MUST provide the ability to configure the		Implementations MUST provide the ability to configure the
	preceding set of timers, and SHOULD provide default values to		preceding set of timers, and SHOULD provide default values to
	enable rapid configuration. Suitable default values, timer		enable rapid configuration. Suitable default values, timer
	ranges, and level of granularity are out of scope in this		ranges, and level of granularity are out of scope in this
	document and form part of the specification of fault management		document and form part of the specification of fault management
	details. Timers SHOULD be configurable per NE for broad		details. Timers SHOULD be configurable per NE for broad
	categories of failure causes and deduced faults, and MAY be		categories (for example, defects and/or fault causes), and MAY
	configurable per-interface on an NE or per individual failure		be configurable per-interface on an NE and/or per individual
	cause or deduced fault.		defect/fault cause.
	The failure declaration and clearing MUST be time stamped. The		The failure declaration and clearing MUST be time stamped. The
	time-stamp MUST indicate the time at which the fault cause is		time-stamp MUST indicate the time at which the fault cause is
	activated at the input of the fault cause persistency (i.e.		activated at the input of the fault cause persistency (i.e.
	defect-to-failure integration) function, and the time at which		defect-to-failure integration) function, and the time at which
	the fault cause is deactivated at the input of the fault cause		the fault cause is deactivated at the input of the fault cause
	persistency function.		persistency function.
	5.3. Alarm Handling Function		5.3. Alarm Handling Function
	skipping to change at page 11, line 40		skipping to change at page 11, line 40
	Alarm Reporting Control (ARC) supports an automatic in-service		Alarm Reporting Control (ARC) supports an automatic in-service
	provisioning capability. Alarm reporting can be turned off on a		provisioning capability. Alarm reporting can be turned off on a
	per-managed entity (e.g., LSP) basis to allow sufficient time		per-managed entity (e.g., LSP) basis to allow sufficient time
	for customer service testing and other maintenance activities in		for customer service testing and other maintenance activities in
	an "alarm free" state. Once a managed entity is ready, alarm		an "alarm free" state. Once a managed entity is ready, alarm
	reporting is automatically turned on.		reporting is automatically turned on.
	An MPLS-TP NE SHOULD support the Alarm Reporting Control		An MPLS-TP NE SHOULD support the Alarm Reporting Control
	function for controlling the reporting of alarm conditions.		function for controlling the reporting of alarm conditions.
	See G.7710 [1] (section 7.1.3.2) and RFC 3878 [9] for more		See G.7710 [1] (section 7.1.3.2) and RFC 3878 [24] for more
	information about ARC.		information about ARC.
	6.Configuration Management Requirements		6.Configuration Management Requirements
	Configuration Management provides functions to identify, collect		Configuration Management provides functions to identify, collect
	data from, provide data to and control NEs. Specific		data from, provide data to and control NEs. Specific
	configuration tasks requiring network management support include		configuration tasks requiring network management support include
	hardware and software configuration, configuration of NEs to		hardware and software configuration, configuration of NEs to
	support transport paths (including required working and		support transport paths (including required working and
	protection paths), and configuration of required path		protection paths), and configuration of required path
	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 [24], section 2.1 - General		transport paths (defined in [8], 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
	setup/maintenance, the MPLS-TP NE MUST support management of the		setup/maintenance, the MPLS-TP NE MUST support management of the
	hand-off of Path control. See, for example, references [25] and		hand-off of Path control. See, for example, references [19] and
	[26].		[20].
	Further detailed requirements will be provided along with		Further detailed requirements will be provided along with
	progress in defining the MPLS-TP control plane in appropriate		progress in defining the MPLS-TP control plane in appropriate
	specifications.		specifications.
	If MPLS-TP transport paths cannot be statically provisioned		If MPLS-TP transport paths cannot be statically provisioned
	using MPLS LSP and pseudo-wire management tools (either already		using MPLS LSP and pseudo-wire management tools (either already
	defined in standards or under development), further management		defined in standards or under development), further management
	specifications MUST be provided as needed.		specifications MUST be provided as needed.
	6.4. Protection Configuration		6.4. Protection Configuration
	The MPLS-TP NE MUST support configuration of required path		The MPLS-TP NE MUST support configuration of required path
	protection information as follows:		protection information as follows:
	- designate specifically identified LSPs as working or		. designate specifically identified LSPs as working or
	protection LSPs;		protecting LSPs;
	- define associations of working and protection paths;		. define associations of working and protecting paths;
	- operate/release manual protection switching;		. operate/release manual protection switching;
	- operate/release force protection switching;		. operate/release force protection switching;
	- operate/release protection lockout;		. operate/release protection lockout;
	- set/retrieve Automatic Protection Switching (APS)		. set/retrieve Automatic Protection Switching (APS)
	parameters, including -		parameters, including -
	o Wait to Restore time,		o Wait to Restore time,
	o Protection Switching threshold information.		o Protection Switching threshold information.
	6.5. OAM Configuration		6.5. OAM Configuration
	The MPLS-TP NE MUST support configuration of the OAM entities		The MPLS-TP NE MUST support configuration of the OAM entities
	and functions specified in [3].		and functions specified in [3].
	The MPLS-TP NE MUST support the capability to choose which OAM		The MPLS-TP NE MUST support the capability to choose which OAM
	functions to use and which maintenance entity will apply them.		functions are enabled.
			For enabled OAM functions, the MPLS-TP NE MUST support the
			ability to associate OAM functions with specific maintenance
			entities.
	The MPLS-TP NE MUST support the capability to configure the OAM		The MPLS-TP NE MUST support the capability to configure the OAM
	entities/functions as part of LSP setup and tear-down, including		entities/functions as part of LSP setup and tear-down, including
	co-routed bidirectional point-to-point, associated bidirectional		co-routed bidirectional point-to-point, associated bidirectional
	point-to-point, and uni-directional (both point-to-point and		point-to-point, and uni-directional (both point-to-point and
	point-to-multipoint) connections.		point-to-multipoint) connections.
	The MPLS-TP NE MUST support the configuration of maintenance		The MPLS-TP NE MUST support the configuration of maintenance
	entity identifiers (e.g. MEP ID and MIP ID) for the purpose of		entity identifiers (e.g. MEP ID and MIP ID) for the purpose of
	LSP connectivity checking.		LSP connectivity checking.
	skipping to change at page 15, line 14		skipping to change at page 15, line 17
	extent that a configurable performance threshold has been		extent that a configurable performance threshold has been
	crossed and the degradation persists long enough (i.e. - the		crossed and the degradation persists long enough (i.e. - the
	indication persists for some amount of time - which is either		indication persists for some amount of time - which is either
	configurable, or well-known) to be certain it is not a		configurable, or well-known) to be certain it is not a
	measurement anomaly.		measurement anomaly.
	Methods, mechanisms and algorithms for exactly how		Methods, mechanisms and algorithms for exactly how
	unavailability is to be determined - based on collection of raw		unavailability is to be determined - based on collection of raw
	performance data - are out of scope for this document.		performance data - are out of scope for this document.
	For the purposes of this document, it is sufficient to state		The MPLS-TP NE MUST support collection and reporting of raw
	that an MPLS-TP NE MUST support collection, and reporting, of		performance data that MAY be used in determining the
	raw performance data that MAY be used in determining		unavailability of a transport service.
	availability of a transport service, and that implementations
	SHOULD support some as yet to be defined mechanism for		MPLS-TP MUST support the determination of the unavailability of
	determining service availability.		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.
			Transport network unavailability is based on Severely Errored
			Seconds (SES) and Unavailable Seconds (UAS). ITU-T is
			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].
	The MPLS-TP NE MUST support collection of loss measurement (LM)		The MPLS-TP NE MUST support collection of loss measurement (LM)
	statistics.		statistics.
	The MPLS-TP NE MUST support collection of delay measurement (DM)		The MPLS-TP NE MUST support collection of delay measurement (DM)
	statistics.		statistics.
	The MPLS-TP NE MUST support reporting of Performance degradation		The MPLS-TP NE MUST support reporting of Performance degradation
	via fault management for corrective actions. "Reporting" in this		via fault management for corrective actions. "Reporting" in this
	context could mean:		context could mean:
	- reporting to an autonomous protection component to trigger		. reporting to an autonomous protection component to trigger
	protection switching,		protection switching,
	- reporting via a craft interface to allow replacement of a		. reporting via a craft interface to allow replacement of a
	faulty component (or similar manual intervention),		faulty component (or similar manual intervention),
			. etc.
	- etc.
	The MPLS-TP NE MUST support reporting of performance statistics		The MPLS-TP NE MUST support reporting of performance statistics
	on request from a management system.		on request from a management system.
	7.2. Performance Measurement Instrumentation		7.2. Performance Measurement Instrumentation
	7.2.1. Measurement Frequency		7.2.1. Measurement Frequency
	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.
	On Delay measurement:		On Delay measurement:
	- for unidirectional (P2P and P2MP) connection, on-demand		. for unidirectional (P2P and P2MP) connection, on-demand
	measurement of delay measurement is REQUIRED.		measurement of delay measurement is REQUIRED.
	- for co-routed bidirectional (P2P) connection, on-demand		. for co-routed bidirectional (P2P) connection, on-demand
	measurement of one-way and two-way delay is REQUIRED.		measurement of one-way and two-way delay is REQUIRED.
	- for associated bidirectional (P2P) connection, on-demand		. for associated bidirectional (P2P) connection, on-demand
	measurement of one-way delay is REQUIRED.		measurement of one-way delay is REQUIRED.
	8. Security Management Requirements		8. Security Management Requirements
	The MPLS-TP NE MUST support secure management and control		The MPLS-TP NE MUST support secure management and control
	planes.		planes.
	8.1. Management Communication Channel Security		8.1. Management Communication Channel Security
	Secure communication channels MUST be supported for all network		Secure communication channels MUST be supported for all network
	traffic and protocols used to support management functions.		traffic and protocols used to support management functions.
	This MUST include, at least, protocols used for configuration,		This MUST include, at least, protocols used for configuration,
	monitoring, configuration backup, logging, time synchronization,		monitoring, configuration backup, logging, time synchronization,
	authentication, and routing. The MCC MUST support application		authentication, and routing. The MCC MUST support application
	protocols that provide confidentiality and data integrity		protocols that provide confidentiality and data integrity
	protection.		protection.
	The MPLS-TP NE MUST support the following:		The MPLS-TP NE MUST support the following:
	- Use of open cryptographic algorithms (See RFC 3871 [5])		- Use of open cryptographic algorithms (See RFC 3871 [4])
	- Authentication - allow management connectivity only from		- Authentication - allow management connectivity only from
	authenticated entities.		authenticated entities.
	- Authorization - allow management activity originated by an		- Authorization - allow management activity originated by an
	authorized entity, using (for example) an Access Control		authorized entity, using (for example) an Access Control
	List (ACL).		List (ACL).
	- Port Access Control - allow management activity received on		- Port Access Control - allow management activity received on
	an authorized (management) port.		an authorized (management) port.
	skipping to change at page 17, line 37		skipping to change at page 18, line 4
	A Denial of Service (DoS) attack is an attack that tries to		A Denial of Service (DoS) attack is an attack that tries to
	prevent a target from performing an assigned task, or providing		prevent a target from performing an assigned task, or providing
	its intended service(s), through any means. A Distributed DoS		its intended service(s), through any means. A Distributed DoS
	(DDoS) can multiply attack severity (possibly by an arbitrary		(DDoS) can multiply attack severity (possibly by an arbitrary
	amount) by using multiple (potentially compromised) systems to		amount) by using multiple (potentially compromised) systems to
	act as topologically (and potentially geographically)		act as topologically (and potentially geographically)
	distributed attack sources. It is possible to lessen the impact		distributed attack sources. It is possible to lessen the impact
	and potential for DoS and DDoS by using secure protocols,		and potential for DoS and DDoS by using secure protocols,
	turning off unnecessary processes, logging and monitoring, and		turning off unnecessary processes, logging and monitoring, and
	ingress filtering. RFC 4732 [4] provides background on DOS in		ingress filtering. RFC 4732 [26] provides background on DOS in
	the context of the Internet.		the context of the Internet.
	An MPLS-TP NE MUST support secure management protocols and		An MPLS-TP NE MUST support secure management protocols and
	SHOULD do so in a manner the reduce potential impact of a DoS		SHOULD do so in a manner the reduce potential impact of a DoS
	attack.		attack.
	An MPLS-TP NE SHOULD support additional mechanisms that mitigate		An MPLS-TP NE SHOULD support additional mechanisms that mitigate
	a DoS (or DDoS) attack against the management component while		a DoS (or DDoS) attack against the management component while
	allowing the NE to continue to meet its primary functions.		allowing the NE to continue to meet its primary functions.
	skipping to change at page 18, line 46		skipping to change at page 19, line 12
	[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", work in progress.
	[4] Handley, M., et al, "Internet Denial-of-Service		[4] Jones, G., "Operational Security Requirements for Large
	Considerations", RFC 4732, November 2006.
	[5] 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.
	[6] 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.
	[7] 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.
	[8] ITU-T Recommendation G.8601, "Architecture of service
	management in multi bearer, multi carrier environment",
	June 2006.
	[9] Lam, H., et al, "Alarm Reporting Control Management
	Information Base (MIB)", RFC 3878, September 2004.
	[10] Bocci, M., et al, "MPLS Generic Associated Channel", RFC
	5586, June 2009.
	[11] Beller, D., et al, "An Inband Data Communication Network		[7] Beller, D., et al, "An Inband Data Communication Network
	For the MPLS Transport Profile", draft-ietf-mpls-tp-gach-		For the MPLS Transport Profile", draft-ietf-mpls-tp-gach-
	dcn, work in progress.		dcn, work in progress.
			[8] Niven-Jenkins, B. et al, "MPLS-TP Requirements", draft-
			ietf-mpls-tp-requirements, work in progress.
	12.2. Informative References		12.2. Informative References
	[12] 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.
	[13] 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.
	[14] 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.
	[15] Bocci, M. et al, "A Framework for MPLS in Transport		[12] Bocci, M. et al, "A Framework for MPLS in Transport
	Networks", Work in Progress, November 27, 2008.		Networks", draft-ietf-mpls-tp-framework, work in progress.
	[16] ANSI T1.231-2003, "Layer 1 In-Service Transmission
	Performance Monitoring", American National Standards
	Institute, 2003.
	[17] Vigoureux, M. et al, "MPLS Generic Associated Channel",		[13] Bocci, M. et al, "MPLS Generic Associated Channel", RFC
	draft-ietf-mpls-tp-gach-gal, work in progress.		5586, June 2009.
	[18] 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.
	[19] 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.
	[20] Bocci, M. et al, "A Framework for MPLS in Transport		[16] Enns, R. et al, "NETCONF Configuration Protocol", draft-
	Networks", draft-ietf-mpls-tp-framework, work in progress.
	[21] Enns, R. et al, "NETCONF Configuration Protocol", draft-
	ietf-netconf-4741bis, work in progress.		ietf-netconf-4741bis, work in progress.
	[22] 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.
	[23] 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.
	[24] Niven-Jenkins, B. et al, "MPLS-TP Requirements", draft-		[19] Caviglia, D. et al, "Requirements for the Conversion
	ietf-mpls-tp-requirements, work in progress.
	[25] Caviglia, D. et al, "Requirements for the Conversion
	between Permanent Connections and Switched Connections in		between Permanent Connections and Switched Connections in
	a Generalized Multiprotocol Label Switching (GMPLS)		a Generalized Multiprotocol Label Switching (GMPLS)
	Network", RFC 5493, April 2009.		Network", RFC 5493, April 2009.
	[26] Caviglia, D. et al, "RSVP-TE Signaling Extension For The		[20] Caviglia, D. et al, "RSVP-TE Signaling Extension For The
	Conversion Between Permanent Connections And Soft		Conversion Between Permanent Connections And Soft
	Permanent Connections In A GMPLS Enabled Transport		Permanent Connections In A GMPLS Enabled Transport
	Network", draft-ietf-ccamp-pc-spc-rsvpte-ext, work in		Network", draft-ietf-ccamp-pc-spc-rsvpte-ext, work in
	progress.		progress.
	[27] ITU-T Recommendation G.806, "Characteristics of transport		[21] ITU-T Recommendation G.806, "Characteristics of transport
	equipment - Description methodology and generic		equipment - Description methodology and generic
	functionality", January, 2009.		functionality", January, 2009.
	[28] ITU-T Recommendation Y.1731, "OAM Functions and Mechanisms		[22] ITU-T Recommendation Y.1731, "OAM functions and mechanisms
	for Ethernet Based Networks", February, 2008.		for Ethernet based networks", February, 2008.
			[23] ITU-T Recommendation G.8601, "Architecture of service
			management in multi bearer, multi carrier environment",
			June 2006.
			[24] Lam, H., et al, "Alarm Reporting Control Management
			Information Base (MIB)", RFC 3878, September 2004.
			[25] ITU-T Recommendation Y.1563, "Ethernet frame transfer and
			availability performance", January 2009.
			[26] Handley, M., et al, "Internet Denial-of-Service
			Considerations", RFC 4732, November 2006.
	Author's Addresses		Author's Addresses
	Editors:		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
	skipping to change at page 23, line 5		skipping to change at page 23, line 5
	publication of this document (http://trustee.ietf.org/license-		publication of this document (http://trustee.ietf.org/license-
	info). Please review these documents carefully, as they		info). Please review these documents carefully, as they
	describe your rights and restrictions with respect to this		describe your rights and restrictions with respect to this
	document.		document.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
	APPENDIX A: Communication Channel (CCh) Examples		Appendix A- Communication Channel (CCh) Examples
	A CCh may be realized in a number of ways.		A CCh may be realized in a number of ways.
	1. The CCh may be provided by a link in a physically distinct		1. The CCh may be provided by a link in a physically distinct
	network. That is, a link that is not part of the transport		network. That is, a link that is not part of the transport
	network that is being managed. For example, the nodes in the		network that is being managed. For example, the nodes in the
	transport network may be interconnected in two distinct physical		transport network may be interconnected in two distinct physical
	networks: the transport network and the DCN.		networks: the transport network and the DCN.
	This is a "physically distinct out-of-band CCh".		This is a "physically distinct out-of-band CCh".
	2. The CCh may be provided by a link in the transport network		2. The CCh may be provided by a link in the transport network
	that is terminated at the ends of the DCC and which is capable		that is terminated at the ends of the DCC and which is capable
	of encapsulating and terminating packets of the management		of encapsulating and terminating packets of the management
	protocols. For example, in MPLS-TP an single-hop LSP might be		protocols. For example, in MPLS-TP a single-hop LSP might be
	established between two adjacent nodes, and that LSP might be		established between two adjacent nodes, and that LSP might be
	capable of carrying IP traffic. Management traffic can then be		capable of carrying IP traffic. Management traffic can then be
	inserted into the link in an LSP parallel to the LSPs that carry		inserted into the link in an LSP parallel to the LSPs that carry
	user traffic.		user traffic.
	This is a "physically shared out-of-band CCh."		This is a "physically shared out-of-band CCh."
	3. The CCh may be supported as its native protocol on the		3. The CCh may be supported as its native protocol on the
	interface alongside the transported traffic. For example, if an		interface alongside the transported traffic. For example, if an
	interface is capable of sending and receiving both MPLS-TP and		interface is capable of sending and receiving both MPLS-TP and
	skipping to change at page 23, line 50		skipping to change at page 23, line 50
	bytes does not reduce the capacity of the associated data		bytes does not reduce the capacity of the associated data
	channel.		channel.
	This is an "overhead-based CCh".		This is an "overhead-based CCh".
	This alternative is not available in MPLS-TP because there is no		This alternative is not available in MPLS-TP because there is no
	overhead available.		overhead available.
	5. The CCh may provided by a dedicated channel associated with		5. The CCh may provided by a dedicated channel associated with
	the data link. For example, the generic associated label (GAL)		the data link. For example, the generic associated label (GAL)
	[17] may be used to label DCC traffic being exchanged on a data		[13] may be used to label DCC traffic being exchanged on a data
	link between adjacent transport nodes, potentially in the		link between adjacent transport nodes, potentially in the
	absence of any data LSP between those nodes.		absence of any data LSP between those nodes.
	This is a "data link associated CCh".		This is a "data link associated CCh".
	It is very similar to case 2, and by its nature can only span a		It is very similar to case 2, and by its nature can only span a
	single hop in the transport network.		single hop in the transport network.
	6. The CCh may be provided by a dedicated channel associated		6. The CCh may be provided by a dedicated channel associated
	with a data channel. For example, in MPLS-TP the GAL [17] may be		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		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		LSP to create a channel associated with the LSP that may carry
	management traffic. This CCh requires the receiver to be capable		management traffic. This CCh requires the receiver to be capable
	of demultiplexing management traffic from user traffic carried		of demultiplexing management traffic from user traffic carried
	on the same LSP by use of the GAL.		on the same LSP by use of the GAL.
	This is a "data channel associated CCh".		This is a "data channel associated CCh".
	7. The CCh may be provided by mixing the management traffic with		7. The CCh may be provided by mixing the management traffic with
	the user traffic such that is indistinguishable on the link		the user traffic such that is indistinguishable on the link
	skipping to change at page 25, line 23		skipping to change at page 25, line 23
	signaling protocol traffic while others carry routing protocol		signaling protocol traffic while others carry routing protocol
	traffic.		traffic.
	It should be noted that the DCN may be a routed network with		It should be noted that the DCN may be a routed network with
	forwarding capabilities, but that this is not a requirement. The		forwarding capabilities, but that this is not a requirement. The
	ability to support forwarding of management or control traffic		ability to support forwarding of management or control traffic
	within the DCN may substantially simplify the topology of the		within the DCN may substantially simplify the topology of the
	DCN and improve its resilience, but does increase the complexity		DCN and improve its resilience, but does increase the complexity
	of operating the DCN.		of operating the DCN.
	See also RFC 3877 [12], ITU-T M.20 [13], and Telcordia document		See also RFC 3877 [9], ITU-T M.20 [10], and Telcordia document
	GR-833-CORE [14] for further information.		GR-833-CORE [11] for further information.
End of changes. 79 change blocks.
	162 lines changed or deleted		172 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/