draft-ietf-mpls-tp-nm-req-01.txt		draft-ietf-mpls-tp-nm-req-02.txt
	Network Working Group Hing-Kam Lam		Network Working Group Hing-Kam Lam
	Internet Draft Alcatel-Lucent		Internet Draft Alcatel-Lucent
	Expires: October, 2009 Scott Mansfield		Expires: December, 2009 Scott Mansfield
	Intended Status: Informational Eric Gray		Intended Status: Standards Track Eric Gray
	Ericsson		Ericsson
	April 15, 2009		June 24, 2009
	MPLS TP Network Management Requirements		MPLS TP Network Management Requirements
	draft-ietf-mpls-tp-nm-req-01.txt		draft-ietf-mpls-tp-nm-req-02.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 October 15, 2009.		This Internet-Draft will expire on December 24, 2009.
	Abstract		Abstract
	This document specifies the requirements necessary to manage the		This document specifies the requirements for the management of
	elements and networks that support an MPLS Transport Profile		equipment used in networks supporting an MPLS Transport Profile
	(MPLS-TP). This document is a product of a joint International		(MPLS-TP). The requirements are defined for specification of
	Telecommunications Union - Telecommunications Standardization		network management aspects of protocol mechanisms and procedures
	Sector (ITU-T) and Internet Engineering Task Force (IETF) effort		that constitute the building blocks out of which the MPLS
	to include a MPLS Transport Profile within the IETF MPLS		transport profile is constructed. That is, these requirements
	architecture. The requirements are driven by the management		indicate what management capabilities need to be available in
	functionality needs defined by ITU-T for packet transport		MPLS for use in managing the MPLS-TP. This document is intended
	networks.		to identify essential network management capabilities, not to
			specify what functions any particular MPLS implementation
			supports.
	Table of Contents		Table of Contents
	1. Introduction................................................3		1. Introduction................................................3
	1.1. Terminology............................................3		1.1. Terminology............................................4
	2. Management Interface Requirements...........................4		2. Management Interface Requirements...........................6
	3. Management Communication Channel (MCC) Requirements.........4		3. Management Communication Channel (MCC) Requirements.........6
	4. Management Communication Network (MCN) Requirements.........5		4. Management Communication Network (MCN) Requirements.........6
	5. Fault Management Requirements...............................5		5. Fault Management Requirements...............................8
	5.1. Supervision Function...................................5		5.1. Supervision Function...................................8
	5.2. Validation Function....................................6		5.2. Validation Function....................................9
	5.3. Alarm Handling Function................................7		5.3. Alarm Handling Function...............................10
	5.3.1. Alarm Severity Assignment.........................7		5.3.1. Alarm Severity Assignment........................10
	5.3.2. Alarm Suppression.................................7		5.3.2. Alarm Suppression................................10
	5.3.3. Alarm Reporting Control...........................8		5.3.3. Alarm Reporting..................................11
	5.3.4. Alarm Reporting...................................8		5.3.4. Alarm Reporting Control..........................11
	6. Configuration Management Requirements.......................8		6. Configuration Management Requirements......................11
	6.1. System Configuration...................................9		6.1. System Configuration..................................12
	6.2. Control Plane Configuration............................9		6.2. Control Plane Configuration...........................12
	6.3. Path Configuration.....................................9		6.3. Path Configuration....................................12
	6.4. Protection Configuration...............................9		6.4. Protection Configuration..............................13
	6.5. OAM Configuration.....................................10		6.5. OAM Configuration.....................................13
	7. Performance Management Requirements........................10		7. Performance Management Requirements........................14
	7.1. Path Characterization Performance Metrics.............10		7.1. Path Characterization Performance Metrics.............14
	7.2. Performance Measurement Instrumentation..............12		7.2. Performance Measurement Instrumentation...............15
	7.2.1. Measurement Frequency............................12		7.2.1. Measurement Frequency............................15
	7.2.2. Measurement Scope................................12		7.2.2. Measurement Scope................................16
	8. Security Management Requirements...........................13		8. Security Management Requirements...........................16
	8.1. Management Communication Channel Security.............13		8.1. Management Communication Channel Security.............16
	8.2. Signaling Communication Channel Security..............13		8.2. Signaling Communication Channel Security..............17
	8.3. Distributed Denial of Service.........................13		8.3. Distributed Denial of Service.........................17
	9. Security Considerations....................................14		9. Security Considerations....................................18
	10. IANA Considerations......................................14		10. IANA Considerations.......................................18
	11. Acknowledgments...........................................14		11. Acknowledgments...........................................18
	12. References................................................14		12. References................................................18
	12.1. Normative References.................................14		12.1. Normative References.................................18
	12.2. Informative References...............................15		12.2. Informative References...............................19
	13. Author's Addresses........................................16		Author's Addresses............................................21
	Copyright Statement...........................................16		Copyright Statement...........................................21
	Acknowledgment................................................17		Acknowledgment................................................22
	APPENDIX A: Communication Channel (CC) Examples...............18		APPENDIX A: Communication Channel (CCh) Examples..............23
	1. Introduction		1. Introduction
	This document describes the requirements necessary to manage the		This document specifies the requirements for the management of
	elements and networks that support an MPLS Transport Profile		equipment used in networks supporting an MPLS Transport Profile
	(MPLS-TP). It leverages the management requirements specified		(MPLS-TP). The requirements are defined for specification of
	in ITU-T G.7710/Y.1701 [1] and RFC 4377 [2]. ITU-T G.7710/Y.1701		network management aspects of protocol mechanisms and procedures
	[1] specifies generic management requirements for transport		that constitute the building blocks out of which the MPLS
	(including packet-based and circuit-based) networks. RFC 4377		transport profile is constructed. That is, these requirements
	specifies the OAM requirements, including OAM-related network		indicate what management capabilities need to be available in
	management requirements, for MPLS networks. This document		MPLS for use in managing the MPLS-TP. This document is intended
	expands on the requirements in [1] and [2] to cover fault,		to identify essential network management capabilities, not to
	configuration, performance, and security management for MPLS-TP		specify what functions any particular MPLS implementation
	networks, and the requirements for object and information models		supports.
	needed to manage MPLS-TP Networks and Network Elements.
			This document also leverages management requirements specified
			in ITU-T G.7710/Y.1701 [1] and RFC 4377 [2], and attempts to
			comply with best common practice as defined in [18].
			ITU-T G.7710/Y.1701 defines generic management requirements for
			transport networks. RFC 4377 specifies the OAM requirements,
			including OAM-related network management requirements, for MPLS
			networks.
			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
			and PWE3 architectures to support capabilities and functionality
			of a transport network as defined by ITU-T.
			The requirements in this document derive from two sources:
			1) MPLS and PWE3 architectures as defined by IETF, and
			2) packet transport networks as defined by ITU-T.
			Requirements for management of equipment in MPLS-TP networks are
			defined herein. Related functions of MPLS and PWE3 are defined
			elsewhere (and are out of scope in this document).
			This document expands on the requirements in [1] and [2] to
			cover fault, configuration, performance, and security management
			for MPLS-TP networks, and the requirements for object and
			information models needed to manage MPLS-TP Networks and Network
			Elements.
			In writing this document, the authors assume the reader is
			familiar with references [19] and [20].
	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 [6]
	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.
	MPLS-TP NE: a network element (NE) that supports MPLS-TP		Anomaly: The smallest discrepancy which can be observed between
	functions		actual and desired characteristics of an item. The occurrence of
			a single anomaly does not constitute an interruption in ability
			to perform a required function. Anomalies are used as the input
			for the Performance Monitoring (PM) process and for detection of
			defects ([27], 3.7).
	MPLS-TP network: a network in which MPLS-TP NEs are deployed		Communication Channel (CCh): A logical channel between network
			elements (NEs) that can be used - e.g. - for management or
			control plane applications. The physical channel supporting the
			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
			ability to perform a required function has been interrupted.
			Defects are used as input for performance monitoring, the
			control of consequent actions, and the determination of fault
			cause ([27], 3.24).
			Failure: The fault cause persisted long enough to consider the
			ability of an item to perform a required function to be
			terminated. The item may be considered as failed; a fault has
			now been detected ([27], 3.25).
			Fault: A fault is the inability of a function to perform a
			required action. This does not include an inability due to
			preventive maintenance, lack of external resources, or planned
			actions ([27], 3.26).
			Fault Cause: A single disturbance or fault may lead to the
			detection of multiple defects. A fault cause is the result of a
			correlation process which is intended to identify the defect
			that is representative of the disturbance or fault that is
			causing the problem ([27], 3.27).
			Fault Cause Indication (FCI): An indication of a fault cause.
			Management Communication Channel (MCC): A CCh dedicated for
			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).
	Signaling Communication Network (SCN): A DCN supporting control		MPLS-TP NE: A network element (NE) that supports the functions
	plane communication is referred to as a Signaling Communication		of MPLS necessary to participate in an MPLS-TP based transport
	Network (SCN).		service. See [24] for further information on functionality
			required to support MPLS-TP.
	Communication Channel (CC): a logical channel between network		MPLS-TP network: A network in which MPLS-TP NEs are deployed.
	elements (NEs) that can be used - e.g. - for management plane
	application or control plane applications. The physical channel
	supporting the CC is technology specific. See APPENDIX A:
	Management Communication Channel (MCC): a CC dedicated for		OAM, On-Demand and Proactive: One feature of OAM that is largely
	management plane communications.		a management issue is control of OAM; on-demand and proactive
			are modes of OAM mechanism operation defined - for example - in
			Y.1731 ([28] - 3.45 and 3.44 respectively) as:
	Signaling Communication Channel (SCC): a CC dedicated for		- On-demand OAM - OAM actions which are initiated via manual
	control plane communications. The SCC may be used for GMPLS/ASON		intervention for a limited time to carry out diagnostics.
	signaling and/or other control plane messages (e.g., routing		On-demand OAM can result in singular or periodic OAM
	messages).		actions during the diagnostic time interval.
			- Proactive OAM - OAM actions which are carried on
			continuously to permit timely reporting of fault and/or
			performance status.
			(Note that it is possible for specific OAM mechanisms to only
			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
	support customer access maintenance.		support customer access maintenance.
			Signaling Communication Channel (SCC): A CCh dedicated for
			control plane communications. The SCC may be used for GMPLS/ASON
			signaling and/or other control plane messages (e.g., routing
			messages).
			Signaling Communication Network (SCN): A DCN supporting control
			plane communication is referred to as a Signaling Communication
			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 the standard protocol for managing MPLS-TP		protocol should be used as the standard protocol for managing
	networks. Managing an end-to-end connection across multiple		MPLS-TP networks. Managing an end-to-end connection across
	operator domains where one domain is managed (for example) via		multiple operator domains where one domain is managed (for
	NETCONF/XML or SNMP/SMI, and another domain via CORBA/IDL, is		example) via NETCONF/XML ([21]) or SNMP/SMI ([22]), and another
	allowed.		domain via CORBA/IDL ([23]), 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
	An MPLS-TP management network SHOULD support seamless management		Specifications SHOULD define support for management connectivity
	connectivity with remote MPLS-TP domains and NEs as well as with		with remote MPLS-TP domains and NEs, as well as with termination
	termination points located in NEs under control by a third party		points located in NEs under the control of a third party network
	network operator. See ITU-T G.8601 [8] for example scenarios in		operator. See ITU-T G.8601 [8] for example scenarios in multi-
	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.
	either directly or indirectly via another MPLS-TP NE. When an		The connection MAY be direct (e.g. - via a software, hardware or
	MPLS-TP NE is connected indirectly to an OS, an MCC MUST be		proprietary protocol connection) or indirect (via another MPLS-
	supported between the MPLS-TP NE and the other MPLS-TP NE.		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.
	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 MPLS-TP NEs		or more specifically via the MCN. The MCN connects management
	with management systems, NEs with NEs, and management systems		systems with management systems, management systems with MPLS-TP
	with management systems. Transport DCN architecture and		NEs, and (in the indirect connectivity case discussed in section
	requirements are specified in ITU-T G.7712/Y.1703 [7], including		3) MPLS-TP NEs with MPLS-TP NEs.
	network layer protocols and their interworking.
	As a practical requirement, MCN connections require addressing.		RFC 5586 ([10]) defines a Generic Associated Channel (G-ACh) to
	See the section on addressing in [13] for further information.		enable the realization of a communication channel (CCh) between
			adjacent MPLS-TP NEs for management and control. Reference [11]
			describes how the G-ACh may be used to provide infrastructure
			that forms part of the MCN and a SCN. It also explains how MCN
			and SCN messages are encapsulated, carried on the G-ACh, and
			demultiplexed for 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
			architecture and requirements. The MPLS-TP MCN MUST support the
			requirements (in reference [7]) for:
			- CCh access functions specified in section 7.1.1;
			- MPLS-TP SCC data-link layer termination functions specified
			in section 7.1.2.3;
			- MPLS-TP MCC data-link layer termination functions specified
			in section 7.1.2.4;
			- Network layer PDU into CCh data-link frame encapsulation
			functions specified in section 7.1.3;
			- Network layer PDU forwarding (7.1.6), interworking (7.1.7)
			and encapsulation (7.1.8) functions, as well as tunneling
			(7.1.9) and routing (7.1.10) functions specified in [7].
			As a practical matter, MCN connections will typically have
			addresses. See the section on addressing in [15] for further
			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 required, 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;
	. Retrieval of operational status of the DCN at a given node;		- Management of DCN network addresses;
	. Capability to enable/disable access to the DCN.		- Retrieval of operational status of the DCN at a given node;
			- 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		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].		[3].
	The MPLS-TP NE MUST support the following transmission		The MPLS-TP NE MUST support the following data-plane forwarding
	supervision functions:		path supervision functions:
	. Supervision of looping check 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 the detection of failure in the sequence of		- Supervision of failure detection;
	a protocol exchange (e.g. automatic protection switching
	protocol);
	The MPLS-TP NE transmission-related supervision mechanisms MUST		The MPLS-TP NE MUST support the capability to configure data-
	support the flexibility to be configured to perform on-demand or		plane forwarding path related supervision mechanisms to perform
	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 fault, storage capacity problem, version		e.g., processing faults, storage capacity, version mismatch,
	mismatch, corrupted data, out of memory, 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
	interchangeable and non-interchangeable units, cable, and power		interchangeable and non-interchangeable unit, cable, and power
	problem.		problems.
	The MPLS-TP NE SHOULD support environment-related supervision		The MPLS-TP NE SHOULD support environment-related supervision
	for temperature, humidity, etc.		for temperature, humidity, etc.
	5.2. Validation Function		5.2. Validation Function
	Validation is concerned with the integration of Fault Causes		Validation is the process of integrating Fault Cause indications
	into Failures. A Fault Cause indicates a limited interruption of		into Failures. A Fault Cause Indication (FCI) indicates a
	the required transport function. A Fault Cause is not reported		limited interruption of the required transport function. A Fault
	to maintenance personnel because it could exist only for a very		Cause is not reported to maintenance personnel because it might
	short time. Note that some of these events however are summed up		exist only for a very short time. Note that some of these events
	in the Performance Monitoring process, and when this sum exceeds		are summed up in the Performance Monitoring process (see section
	a certain value, a Threshold Report can be generated.		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		When the Fault Cause lasts long enough, an inability to perform
	the required transport function arises. This Failure condition		the required transport function arises. This failure condition
	is subject to reporting to maintenance personnel and/or an OS		is subject to reporting to maintenance personnel and/or an OS
	because corrective action might be required. Conversely, when		because corrective action might be required. Conversely, when
	the Fault Cause ceases after a certain time, clearing of the		the Fault Cause ceases after a certain time, clearing of the
	Failure condition is also subject to reporting.		Failure condition is also subject to reporting.
	The MPLS-TP NE MUST perform persistency checks on fault causes		The MPLS-TP NE MUST perform persistency checks on fault causes
	before it declares a fault cause a failure.		before it declares a fault cause a failure.
	A transmission failure SHALL be declared if the fault cause		The MPLS-TP NE SHOULD provide a configuration capability for
	persists continuously for a configurable time (Time-D). The		control parameters associated with performing the persistency
	failure SHALL be cleared if the fault cause is absent		checks described above.
	continuously for a configurable time (Time-C). Typically the
	default time values would be as follows:		An MPLS-TP NE MAY provide configuration parameters to control
			reporting, and clearing, of failure conditions.
			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).
			Note: As an example, the default time values might be as
			follows:
	Time-D = 2.5 +/- 0.5 seconds		Time-D = 2.5 +/- 0.5 seconds
	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 -
			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. Examples of levels of
			granularity MAY include per-failure-cause and per-deduced-fault.
			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 of failure causes and deduced faults, and MAY be
			configurable per-interface on an NE or per individual failure
			cause or deduced fault.
	The failure declaration and clearing MUST be time stamped. The		The failure declaration and clearing MUST be time stamped. The
	time-stamp SHALL 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
	5.3.1. Alarm Severity Assignment		5.3.1. Alarm Severity Assignment
	Failures might be categorized to indicate the severity or		Failures can be categorized to indicate the severity or urgency
	urgency of the fault.		of the fault.
	An MPLS-TP NE SHOULD support the flexibility of assignment of		An MPLS-TP NE SHOULD support the ability to assign severity
	severity (e.g., Critical, Major, Minor, Warning) by the		(e.g., Critical, Major, Minor, Warning) to alarm conditions via
	management system.		configuration.
	See G.7710 [1] for more description about alarm severity		See G.7710 [1], section 7.2.2 for more detail on alarm severity
	assignment.		assignment.
	5.3.2. Alarm Suppression		5.3.2. Alarm Suppression
	Alarms may be generated from many sources, including OAM, device		Alarms can be generated from many sources, including OAM, device
	status, etc.		status, etc.
	An MPLS-TP NE MUST provide alarm suppression functionality that		An MPLS-TP NE MUST support suppression of alarms based on
	prevents the generation of superfluous alarms.		configuration.
	Examples of alarm suppression mechanisms include simply
	discarding the alarms (or not generating them in the first
	place), or aggregating the alarms together, thereby greatly
	reducing the number of alarm notifications to be emitted.
	Note: An MPLS-TP NE supporting the inter-working of one or more
	networking technologies (e.g., Ethernet, SDH/SONET, MPLS) with
	MPLS-TP needs to translate an MPLS-TP fault into an existing
	transport technology failure condition for reporting to the
	management system.
	See RFC 4377 [2] for more description.
	5.3.3. Alarm Reporting Control
	Alarm Reporting Control (ARC) supports an automatic in-service
	provisioning capability. Alarm reporting MAY 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.
	An MPLS-TP NE SHOULD support the Alarm Reporting Control
	function for controlling the reporting of alarm conditions.
	See G.7710 [1] and RFC 3878 [9] for more description of ARC.
	5.3.4. Alarm Reporting		5.3.3. Alarm Reporting
	Alarm Reporting is concerned with the reporting of relevant		Alarm Reporting is concerned with the reporting of relevant
	events and conditions, which occur in the network (including the		events and conditions, which occur in the network (including the
	NE, incoming signal, and external environment).		NE, incoming signal, and external environment).
	Local reporting is concerned with automatic alarming by means of		Local reporting is concerned with automatic alarming by means of
	audible and visual indicators near the failed equipment.		audible and visual indicators near the failed equipment.
	An MPLS-TP NE MUST support local reporting of alarms.		An MPLS-TP NE MUST support local reporting of alarms.
	The MPLS-TP NE MUST support reporting of alarms to an OS. These		The MPLS-TP NE MUST support reporting of alarms to an OS. These
	reports are either autonomous reports (notifications) or reports		reports are either autonomous reports (notifications) or reports
	on request by maintenance personnel. The MPLS-TP NE SHOULD		on request by maintenance personnel. The MPLS-TP NE SHOULD
	report local (environmental) alarms to a network management		report local (environmental) alarms to a network management
	system.		system.
			An MPLS-TP NE supporting one or more other networking
			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.
			5.3.4. Alarm Reporting Control
			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.
			An MPLS-TP NE SHOULD support the Alarm Reporting Control
			function for controlling the reporting of alarm conditions.
			See G.7710 [1] (section 7.1.3.2) and RFC 3878 [9] for more
			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
	integrity/connectivity and performance monitoring (i.e. - OAM).		integrity/connectivity and performance monitoring (i.e. - OAM).
	6.1. System Configuration		6.1. System Configuration
	The MPLS-TP NE MUST support the configuration requirements		The MPLS-TP NE MUST support the configuration requirements
	specified in G.7710 [1] for hardware, software, and date/time.		specified in G.7710 [1] section 8.1 for hardware.
			The MPLS-TP NE MUST support the configuration requirements
			specified in G.7710 [1] section 8.2 for software.
			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.
			The MPLS-TP NE MUST support the configuration requirements
			specified in G.7710 [1] section 8.13.2.2 for local real time
			clock alignment with external time reference.
			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.
	6.2. Control Plane Configuration		6.2. Control Plane Configuration
	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 might 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
	The MPLS-TP NE MUST support the capability of configuring		In addition to the requirement to support static provisioning of
	required path performance characteristic thresholds (e.g. - Loss		transport paths (defined in [24], section 2.1 - General
	Measurement [LM], Delay Measurement [DM] thresholds).		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).
	The MPLS-TP NE MUST support the capability of configuring		In order to accomplish this, an MPLS-TP NE MUST support
	required LSPs as follows:		configuration of LSP information (such as an LSP identifier of
			some kind) and/or any other information needed to retrieve LSP
			status information, performance attributes, etc.
	. configure LSP indentifier and/or other information		If a control plane is supported, and that control plane includes
	necessary to retrieve LSP status information.		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 [25] and
			[26].
			Further detailed requirements will be provided along with
			progress in defining the MPLS-TP control plane in appropriate
			specifications.
			If MPLS-TP transport paths cannot be statically provisioned
			using MPLS LSP and pseudo-wire management tools (either already
			defined in standards or under development), further management
			specifications MUST be provided as needed.
	6.4. Protection Configuration		6.4. Protection Configuration
	The MPLS-TP NE MUST support the capability of configuring		The MPLS-TP NE MUST support configuration of required path
	required path protection as follows:		protection information as follows:
	. Designate specifically identified LSPs as working or		- designate specifically identified LSPs as working or
	protection LSPs;		protection LSPs;
	. define associations of working and protection paths;
	. operate/release manual protection switching;		- define associations of working and protection paths;
	. operate/release force protection switching;
	. operate/release protection lockout;		- operate/release manual protection switching;
	. set/retrieve Automatic Protection Switching (APS)
			- operate/release force protection switching;
			- operate/release protection lockout;
			- set/retrieve Automatic Protection Switching (APS)
	parameters, including -		parameters, including -
	. Wait to Restore time,
	. Protection Switching threshold information.		o Wait to Restore time,
			o Protection Switching threshold information.
	6.5. OAM Configuration		6.5. OAM Configuration
	The MPLS-TP NE MUST provide the capability to configure the OAM		The MPLS-TP NE MUST support configuration of the OAM entities
	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 to apply them.		functions to use and which maintenance entity will apply them.
	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.
	The MPLS-TP NE MUST have the flexibility to configure OAM		The MPLS-TP NE MUST support configuration of OAM parameters to
	parameters to meet their specific operational requirements, such		meet their specific operational requirements, such as whether -
	as whether (1) one-time on-demand immediately or (2) one-time
	on-demand pre-scheduled or (3) on-demand periodically based on a		1) one-time on-demand immediately or
	specified schedule or (4) proactive on-going.
			2) one-time on-demand pre-scheduled or
			3) on-demand periodically based on a specified schedule or
			4) proactive on-going.
	The MPLS-TP NE MUST support the enabling/disabling of the		The MPLS-TP NE MUST support the enabling/disabling of the
	connectivity check processing. The connectivity check process of		connectivity check processing. The connectivity check process of
	the MPLS-TP NE MUST support provisioning of the identifiers to		the MPLS-TP NE MUST support provisioning of the identifiers to
	be transmitted and the expected identifiers.		be transmitted and the expected identifiers.
	7. Performance Management Requirements		7. Performance Management Requirements
	Performance Management provides functions to evaluate and report		Performance Management provides functions for the purpose of
	upon the behavior of the equipment, NE, and network for the		Maintenance, Bring-into-service, Quality of service, and
	purpose of Maintenance, Bring-into-service, Quality of service,		statistics gathering.
	and Performance monitoring for signal degradation. ITU-T
	Recommendation G.7710 [1] provides transport performance		This information could be used, for example, to compare behavior
			of the equipment, MPLS-TP NE or network at different moments in
			time to evaluate changes in network performance.
			ITU-T Recommendation G.7710 [1] provides transport performance
	monitoring requirements for packet-switched and circuit-switched		monitoring requirements for packet-switched and circuit-switched
	transport networks with the objective of providing coherent and		transport networks with the objective of providing coherent and
	consistent interpretation of the network behavior, in particular		consistent interpretation of the network behavior in a multi-
	for hybrid network which consists of multiple transport		technology environment. The performance management requirements
	technologies. The performance management requirements specified		specified in this document are driven by such an objective.
	in this document are driven by such an objective.
	7.1. Path Characterization Performance Metrics		7.1. Path Characterization Performance Metrics
	The MPLS-TP NE MUST support collection of loss measurement (LM)		It MUST be possible to determine when an MPLS-TP based transport
	so that they can be used to detect performance degradation.		service is available and when it is unavailable.
	The MPLS-TP NE MUST support collection of delay measurement (DM)
	so that they can be used to detect performance degradation.
	The MPLS-TP NE MUST support reporting of Performance degradation
	via fault management for corrective actions (e.g. protection
	switching).
	The MPLS-TP NE MUST support collection of loss ratio measurement
	so that they can be used to determine Severely Errored Second
	(SES).
	A SES is declared for a one second interval when the ratio of
	lost packets to total transmitted packets in that one second
	interval exceeds a predetermined threshold.
	The packet lost threshold for declaring SES MUST be		From a performance perspective, a service is unavailable if
	configurable.		there is an indication that performance has degraded to the
			extent that a configurable performance threshold has been
			crossed and the degradation persists long enough (i.e. - the
			indication persists for some amount of time - which is either
			configurable, or well-known) to be certain it is not a
			measurement anomaly.
	The number of SESs MUST be collected per configurable intervals		Methods, mechanisms and algorithms for exactly how
	(e.g. 15-minute and 24-hour).		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 of SES measurement so		For the purposes of this document, it is sufficient to state
	that they can be used to determine service unavailable time.		that an MPLS-TP NE MUST support collection, and reporting, of
			raw performance data that MAY be used in determining
			availability of a transport service, and that implementations
			SHOULD support some as yet to be defined mechanism for
			determining service availability.
	A period of unavailable time (UAT) begins at the onset of 10		The MPLS-TP NE MUST support collection of loss measurement (LM)
	consecutive SES events. These 10 seconds are considered to be		statistics.
	part of unavailable time. A new period of available time begins
	at the onset of 10 consecutive non-SES events. These 10 seconds
	are considered to be part of available time.
	The MPLS-TP NE MUST support collection of Unavailable Seconds		The MPLS-TP NE MUST support collection of delay measurement (DM)
	(UAS) so that they can be used to determine service		statistics.
	availability.
	The number of UAS MUST be collected per configurable intervals		The MPLS-TP NE MUST support reporting of Performance degradation
	(e.g. 15-minute and 24-hour).		via fault management for corrective actions. "Reporting" in this
			context could mean:
	SES and UAS history (the number of readings to be retained and		- reporting to an autonomous protection component to trigger
	available) is as defined in ITU and ANSI documents associated		protection switching,
	with specific transport technologies (for instance, ITU-T
	G.7710, and ANSI T1.231-2003 [T1.231.01-2003 for DSL,.02 for
	DS1,.03 for DS3 and T1.231.04-2003 for SONET] - see [1] and [14]
	respectively), however these are fairly consistently defined as
	follows:
	- Current and previous 1-day statistics		- reporting via a craft interface to allow replacement of a
	- Current and 16 recent 15-minute statistics (ITU-T)		faulty component (or similar manual intervention),
	- Current, previous and 31 recent 15-minute statistics (ANSI)		- etc.
	Note that - worst case (ANSI) requires 2 copies of 1-day		The MPLS-TP NE MUST support reporting of performance statistics
	statistics (current and previous) and 33 copies of 15-minute		on request from a management system.
	statistics (current, previous and 31 recent).
	7.2. Performance Measurement Instrumentation		7.2. Performance Measurement Instrumentation
	7.2.1. Measurement Frequency		7.2.1. Measurement Frequency
	The performance measurement mechanisms MUST support the		For performance measurement mechanisms that support both
	flexibility to be configured to operate on-demand or proactively		proactive and on-demand modes, the MPLS-TP NE MUST support the
	(i.e. continuously over a period of time).		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 -
	. on-demand measurement of single-ended packet loss,		o on-demand measurement of single-ended packet loss, and
	and loss ratio, measurement are required;		loss ratio, measurement is REQUIRED;
	. proactive measurement of packet loss, and loss
	ratio, measurement for each direction are required.
	Note: for associated bidirectional P2P connections, this data		o proactive measurement of packet loss, and loss ratio,
	can only be measured at end-points.		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, are 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 are 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 channels MUST be provided for all network traffic and		Secure communication channels MUST be supported for all network
	protocols used to support management functions. This MUST		traffic and protocols used to support management functions.
	include, at least, protocols used for configuration, monitoring,		This MUST include, at least, protocols used for configuration,
	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.
	If management communication security is provided, the MPLS-TP NE		The MPLS-TP NE MUST support the following:
	MUST support the following:
	- Use of open cryptographic algorithms (See RFC 3871 [5])		- Use of open cryptographic algorithms (See RFC 3871 [5])
	- 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 an		- Port Access Control - allow management activity received on
	authorized (management) port.		an authorized (management) port.
	8.2.Signaling Communication Channel Security		8.2.Signaling Communication Channel Security
	Security considerations for the SCC are similar to the		Security requirements for the SCC are driven by considerations
	considerations driving the requirements described in section		similar to MCC requirements described in section 8.1.
	8.1. Security Requirements for the control plane are out of
	scope for this document and are expected to be defined in the		Security Requirements for the control plane are out of scope for
	appropriate control plane specifications. Management of the		this document and are expected to be defined in the appropriate
	control plane security must also be defined at that time.		control plane specifications.
			Management of control plane security MUST also be defined at
			that time.
	8.3. Distributed Denial of Service		8.3. Distributed Denial of Service
	Denial of Service (DoS) attack is an attack which 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 DDOS by using secure protocols, turning off		and potential for DoS and DDoS by using secure protocols,
	unnecessary processes, logging and monitoring, and ingress		turning off unnecessary processes, logging and monitoring, and
	filtering. RFC 4732 [4] provides background on DOS in the		ingress filtering. RFC 4732 [4] provides background on DOS in
	context of the Internet.		the context of the Internet.
			An MPLS-TP NE MUST support secure management protocols and
			SHOULD do so in a manner the reduce potential impact of a DoS
			attack.
			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.
	9. Security Considerations		9. Security Considerations
	Section 8 includes a set of security requirements that apply to		Section 8 includes a set of security requirements that apply to
	MPLS-TP network management.		MPLS-TP network management.
	Solutions MUST provide mechanisms to prevent unauthorized and/or		Solutions MUST provide mechanisms to prevent unauthorized and/or
	unauthenticated access to private information by network		unauthenticated access to management capabilities and private
	elements, systems or users.		information by network elements, systems or users.
	Performance of diagnostic functions and path characterization		Performance of diagnostic functions and path characterization
	involves extracting a significant amount of information about		involves extracting a significant amount of information about
	network construction that the network operator MAY consider		network construction that the network operator might consider
	private.		private.
	10. IANA Considerations		10. IANA Considerations
	There are no IANA actions associated with this document.		There are no IANA actions associated with this document.
	11. Acknowledgments		11. Acknowledgments
	The authors/editors gratefully acknowledge the thoughtful		The authors/editors gratefully acknowledge the thoughtful
	review, comments and explanations provided by Adrian Farrel,		review, comments and explanations provided by Adrian Farrel,
	Andrea Maria Mazzini, Ben Niven-Jenkins, Bernd Zeuner, Diego		Alexander Vainshtein, Andrea Maria Mazzini, Ben Niven-Jenkins,
	Caviglia, Dieter Beller, He Jia, Leo Xiao, Maarten Vissers, Neil		Bernd Zeuner, Dan Romascanu, Daniele Ceccarelli, Diego Caviglia,
	Harrison and Rolf Winter.		Dieter Beller, He Jia, Leo Xiao, Maarten Vissers, Neil Harrison,
			Rolf Winter, Yoav Cohen and Yu Liang.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[1] ITU-T Recommendation G.7710/Y.1701, "Common equipment		[1] ITU-T Recommendation G.7710/Y.1701, "Common equipment
	management function requirements", July, 2007.		management function requirements", July, 2007.
	[2] Nadeau, T., et al, "Operations and Management (OAM)		[2] Nadeau, T., et al, "Operations and Management (OAM)
	Requirements for Multi-Protocol Label Switched (MPLS)		Requirements for Multi-Protocol Label Switched (MPLS)
	Networks", RFC 4377, February 2006.		Networks", RFC 4377, February 2006.
	[3] Vigoureus, 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] Handley, M., et al, "Internet Denial-of-Service
	Considerations", RFC 4732, November 2006.		Considerations", RFC 4732, November 2006.
	[5] Jones, G., "Operational Security Requirements for Large		[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		[6] Bradner, S., "Key words for use in RFCs to Indicate
	skipping to change at page 15, line 25		skipping to change at page 19, line 18
	[7] ITU-T Recommendation G.7712/Y.1703, "Architecture and		[7] 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		[8] ITU-T Recommendation G.8601, "Architecture of service
	management in multi bearer, multi carrier environment",		management in multi bearer, multi carrier environment",
	June 2006.		June 2006.
	[9] Lam, H., et al, "Alarm Reporting Control Management		[9] Lam, H., et al, "Alarm Reporting Control Management
	Information Base (MIB)", RFC 3878, September 2004.		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
			For the MPLS Transport Profile", draft-ietf-mpls-tp-gach-
			dcn, work in progress.
	12.2. Informative References		12.2. Informative References
	[10] Chisholm, S. and D. Romascanu, "Alarm Management		[12] Chisholm, S. and D. Romascanu, "Alarm Management
	Information Base (MIB)", RFC 3877, September 2004.		Information Base (MIB)", RFC 3877, September 2004.
	[11] ITU-T Recommendation M.20, "Maintenance Philosophy for		[13] ITU-T Recommendation M.20, "Maintenance Philosophy for
	Telecommunication Networks", October 1992.		Telecommunication Networks", October 1992.
	[12] Telcordia, "Network Maintenance: Network Element and		[14] 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.
	[13] Bocci, M. et al, "A Framework for MPLS in Transport		[15] Bocci, M. et al, "A Framework for MPLS in Transport
	Networks", Work in Progress, November 27, 2008.		Networks", Work in Progress, November 27, 2008.
	[14] ANSI T1.231-2003, "Layer 1 In-Service Transmission		[16] ANSI T1.231-2003, "Layer 1 In-Service Transmission
	Performance Monitoring", American National Standards		Performance Monitoring", American National Standards
	Institute, 2003.		Institute, 2003.
	[15] Vigoureux, M. et al, "MPLS Generic Associated Channel",		[17] Vigoureux, M. et al, "MPLS Generic Associated Channel",
	draft-ietf-mpls-tp-gach-gal, work in progress.		draft-ietf-mpls-tp-gach-gal, work in progress.
	13. Author's Addresses		[18] Harrington, D., "Guidelines for Considering Operations and
			Management of New Protocols and Protocol Extensions",
			draft-ietf-opsawg-operations-and-management, work in
			progress.
			[19] Mansfield, S. et al, "MPLS-TP Network Management
			Framework", draft-ietf-mpls-tp-nm-framework, work in
			progress.
			[20] Bocci, M. et al, "A Framework for MPLS in Transport
			Networks", draft-ietf-mpls-tp-framework, work in progress.
			[21] Enns, R. et al, "NETCONF Configuration Protocol", draft-
			ietf-netconf-4741bis, work in progress.
			[22] McCloghrie, K. et al, "Structure of Management Information
			Version 2 (SMIv2)", RFC 2578, April 1999.
			[23] OMG Document formal/04-03-12, "The Common Object Request
			Broker: Architecture and Specification", Revision 3.0.3.
			March 12, 2004.
			[24] Niven-Jenkins, B. et al, "MPLS-TP Requirements", draft-
			ietf-mpls-tp-requirements, work in progress.
			[25] Caviglia, D. et al, "Requirements for the Conversion
			between Permanent Connections and Switched Connections in
			a Generalized Multiprotocol Label Switching (GMPLS)
			Network", RFC 5493, April 2009.
			[26] Caviglia, D. et al, "RSVP-TE Signaling Extension For The
			Conversion Between Permanent Connections And Soft
			Permanent Connections In A GMPLS Enabled Transport
			Network", draft-ietf-ccamp-pc-spc-rsvpte-ext, work in
			progress.
			[27] ITU-T Recommendation G.806, "Characteristics of transport
			equipment - Description methodology and generic
			functionality", January, 2009.
			[28] ITU-T Recommendation Y.1731, "OAM Functions and Mechanisms
			for Ethernet Based Networks", February, 2008.
			Author's Addresses
	Editors:		Editors:
			Eric Gray
			Ericsson
			900 Chelmsford Street
			Lowell, MA, 01851
			Phone: +1 978 275 7470
			Email: Eric.Gray@Ericsson.com
	Scott Mansfield		Scott Mansfield
	Ericsson		Ericsson
	5000 Ericsson Drive		250 Holger Way
	Warrendale, PA, 15086		San Jose CA, 95134
	Phone: +1 724 742 6726		+1 724 931 9316
	EMail: Scott.Mansfield@Ericsson.com		EMail: Scott.Mansfield@Ericsson.com
	Hing-Kam (Kam) Lam		Hing-Kam (Kam) Lam
	Alcatel-Lucent		Alcatel-Lucent
	600-700 Mountain Ave		600-700 Mountain Ave
	Murray Hill, NJ, 07974		Murray Hill, NJ, 07974
	Phone: +1 908 582 0672		Phone: +1 908 582 0672
	Email: hklam@Alcatel-Lucent.com		Email: hklam@Alcatel-Lucent.com
	Eric Gray
	Ericsson
	900 Chelmsford Street
	Lowell, MA, 01851
	Phone: +1 978 275 7470
	Email: Eric.Gray@Ericsson.com
	Author(s):		Author(s):
	Contributor(s):		Contributor(s):
	Adrian Farrel		Adrian Farrel
	Old Dog Consulting		Old Dog Consulting
	Email: adrian@olddog.co.uk		Email: adrian@olddog.co.uk
	Copyright Statement		Copyright Statement
	skipping to change at page 18, 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 (CC) Examples		APPENDIX A: Communication Channel (CCh) Examples
	A CC may be realized in a number of ways.		A CCh may be realized in a number of ways.
	1. The CC 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 CC".		This is a "physically distinct out-of-band CCh".
	2. The CC 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 an 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 CC."		This is a "physically shared out-of-band CCh."
	3. The CC 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
	IP, the IP-based management traffic can be sent as native IP		IP, the IP-based management traffic can be sent as native IP
	packets on the interface.		packets on the interface.
	This is a "shared interface out-of-band CC".		This is a "shared interface out-of-band CCh".
	4. The CC may use overhead bytes available on a transport		4. The CCh may use overhead bytes available on a transport
	connection. For example, in TDM networks there are overhead		connection. For example, in TDM networks there are overhead
	bytes associated with a data channel, and these can be used to		bytes associated with a data channel, and these can be used to
	provide a CC. It is important to note that the use of overhead		provide a CCh. It is important to note that the use of overhead
	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 CC".		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 CC 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)
	[15] may be used to label DCC traffic being exchanged on a data		[17] 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 CC".		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 CC may be provided by a dedicated channel associated with		6. The CCh may be provided by a dedicated channel associated
	a data channel. For example, in MPLS-TP the GAL [15] may be		with a data channel. For example, in MPLS-TP the GAL [17] 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 CC 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 CC".		This is a "data channel associated CCh".
	7. The CC 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
	without deep-packet inspection. In MPLS-TP this could arise if		without deep-packet inspection. In MPLS-TP this could arise if
	there is a data-carrying LSP between two nodes, and management		there is a data-carrying LSP between two nodes, and management
	traffic is inserted into that LSP. This approach requires that		traffic is inserted into that LSP. This approach requires that
	the termination point of the LSP is able to demultiplex the		the termination point of the LSP is able to demultiplex the
	management and user traffic. Such might be possible in MPLS-TP		management and user traffic. Such might be possible in MPLS-TP
	if the MPLS-TP LSP was carrying IP user traffic.		if the MPLS-TP LSP was carrying IP user traffic.
	This is an "in-band CC".		This is an "in-band CCh".
	These realizations may be categorized as:		These realizations may be categorized as:
	A. Out-of-fiber, out-of-band (types 1 and 2)		A. Out-of-fiber, out-of-band (types 1 and 2)
	B. In-fiber, out-of-band (types 2, 3, 4, and 5)		B. In-fiber, out-of-band (types 2, 3, 4, and 5)
	C. In-band (types 6 and 7)		C. In-band (types 6 and 7)
	The MCN and SCN are logically separate networks and may be		The MCN and SCN are logically separate networks and may be
	realized by the same DCN or as separate networks. In practice,		realized by the same DCN or as separate networks. In practice,
	that means that, between any pair of nodes, the MCC and SCC may		that means that, between any pair of nodes, the MCC and SCC may
	skipping to change at page 20, 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 [10], ITU-T M.20 [11], and Telcordia document		See also RFC 3877 [12], ITU-T M.20 [13], and Telcordia document
	GR-833-CORE [12] for further information.		GR-833-CORE [14] for further information.
End of changes. 118 change blocks.
	336 lines changed or deleted		565 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/