draft-ietf-mpls-tp-nm-req-00.txt		draft-ietf-mpls-tp-nm-req-01.txt
	Network Working Group Hing-Kam Lam		Network Working Group Hing-Kam Lam
	Internet Draft Alcatel-Lucent		Internet Draft Alcatel-Lucent
	Expires: August, 2009 Scott Mansfield		Expires: October, 2009 Scott Mansfield
	Intended Status: Informational Eric Gray		Intended Status: Informational Eric Gray
	Ericsson		Ericsson
	February 23, 2009		April 15, 2009
	MPLS TP Network Management Requirements		MPLS TP Network Management Requirements
	draft-ietf-mpls-tp-nm-req-00.txt		draft-ietf-mpls-tp-nm-req-01.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 August 23, 2009.		This Internet-Draft will expire on October 15, 2009.
	Abstract		Abstract
	This document specifies the requirements necessary to manage the		This document specifies the requirements necessary to manage the
	elements and networks that support an MPLS Transport Profile		elements and networks that support an MPLS Transport Profile
	(MPLS-TP). This document is a product of a joint International		(MPLS-TP). This document is a product of a joint International
	Telecommunications Union - Telecommunications Standardization		Telecommunications Union - Telecommunications Standardization
	Sector (ITU-T) and Internet Engineering Task Force (IETF) effort		Sector (ITU-T) and Internet Engineering Task Force (IETF) effort
	to include a MPLS Transport Profile within the IETF MPLS		to include a MPLS Transport Profile within the IETF MPLS
	architecture. The requirements are driven by the management		architecture. The requirements are driven by the management
	skipping to change at page 2, line 14		skipping to change at page 2, line 14
	Table of Contents		Table of Contents
	1. Introduction................................................3		1. Introduction................................................3
	1.1. Terminology............................................3		1.1. Terminology............................................3
	2. Management Interface Requirements...........................4		2. Management Interface Requirements...........................4
	3. Management Communication Channel (MCC) Requirements.........4		3. Management Communication Channel (MCC) Requirements.........4
	4. Management Communication Network (MCN) Requirements.........5		4. Management Communication Network (MCN) Requirements.........5
	5. Fault Management Requirements...............................5		5. Fault Management Requirements...............................5
	5.1. Supervision Function...................................5		5.1. Supervision Function...................................5
	5.2. Validation Function....................................7		5.2. Validation Function....................................6
	5.3. Alarm Handling Function................................7		5.3. Alarm Handling Function................................7
	5.3.1. Alarm Severity Assignment.........................7		5.3.1. Alarm Severity Assignment.........................7
	5.3.2. Alarm Suppression.................................8		5.3.2. Alarm Suppression.................................7
	5.3.3. Alarm Reporting Control...........................8		5.3.3. Alarm Reporting Control...........................8
	5.3.4. Alarm Reporting...................................8		5.3.4. Alarm Reporting...................................8
	6. Configuration Management Requirements.......................9		6. Configuration Management Requirements.......................8
	6.1. System Configuration...................................9		6.1. System Configuration...................................9
	6.2. Control Plane Configuration............................9		6.2. Control Plane Configuration............................9
	6.3. Path Configuration.....................................9		6.3. Path Configuration.....................................9
	6.4. Protection Configuration..............................10		6.4. Protection Configuration...............................9
	6.5. OAM Configuration.....................................10		6.5. OAM Configuration.....................................10
	7. Performance Management Requirements........................11		7. Performance Management Requirements........................10
	7.1. Path Characterization Performance Metrics.............11		7.1. Path Characterization Performance Metrics.............10
	7.2. Performance Measurement Instrumentation..............12		7.2. Performance Measurement Instrumentation..............12
	7.2.1. Measurement Frequency............................12		7.2.1. Measurement Frequency............................12
	7.2.2. Measurement Scope................................12		7.2.2. Measurement Scope................................12
	8. Security Management Requirements...........................13		8. Security Management Requirements...........................13
	8.1. Management Communication Channel Security.............13		8.1. Management Communication Channel Security.............13
	8.1.1. Security of Management Communications............13		8.2. Signaling Communication Channel Security..............13
	8.2. Signaling Communication Channel Security..............14		8.3. Distributed Denial of Service.........................13
	8.3. Data Channel Security.................................14
	8.4. Distributed Denial of Service.........................14
	9. Security Considerations....................................14		9. Security Considerations....................................14
	10. IANA Considerations.......................................15		10. IANA Considerations......................................14
	11. Acknowledgments...........................................15		11. Acknowledgments...........................................14
	12. References................................................15		12. References................................................14
	12.1. Normative References.................................15		12.1. Normative References.................................14
	12.2. Informative References...............................16		12.2. Informative References...............................15
	13. Author's Addresses........................................16		13. Author's Addresses........................................16
	Copyright Statement...........................................17		Copyright Statement...........................................16
	Acknowledgment................................................17		Acknowledgment................................................17
	APPENDIX A: Communication Channel (CC) Examples...............18		APPENDIX A: Communication Channel (CC) Examples...............18
	1. Introduction		1. Introduction
	This document describes the requirements necessary to manage the		This document describes the requirements necessary to manage the
	elements and networks that support an MPLS Transport Profile		elements and networks that support an MPLS Transport Profile
	(MPLS-TP). It leverages the management requirements specified		(MPLS-TP). It leverages the management requirements specified
	in ITU-T G.7710/Y.1701 [1] and RFC 4377 [2]. ITU-T G.7710/Y.1701		in ITU-T G.7710/Y.1701 [1] and RFC 4377 [2]. ITU-T G.7710/Y.1701
	[1] specifies generic management requirements for transport		[1] specifies generic management requirements for transport
	(including packet-based and circuit-based) networks. RFC 4377		(including packet-based and circuit-based) networks. RFC 4377
	skipping to change at page 4, line 34		skipping to change at page 4, line 34
	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 the standard protocol for managing MPLS-TP
	networks. Managing an end-to-end connection across multiple		networks. Managing an end-to-end connection across multiple
	operator domains where one domain is managed (for example) via		operator domains where one domain is managed (for example) via
	NETCONF/XML or SNMP/SMI, and another domain via CORBA/IDL, is		NETCONF/XML or SNMP/SMI, and another domain via CORBA/IDL, is
	allowed.		allowed.
	For the management interface to the management system, an MPLS-		For the management interface to the management system, an MPLS-
	TP NE is not expected to actively support more than one		TP NE MAY actively support more than one management protocol in
	management protocol in any given deployment. The protocol to be		any given deployment. For example, an MPLS-TP NE may use one
	supported is at the discretion of the operator.		protocol for configuration and another for monitoring. The
			protocols to be supported are at the discretion of the operator.
	3. Management Communication Channel (MCC) Requirements		3. Management Communication Channel (MCC) Requirements
	An MPLS-TP management network SHOULD support seamless management		An MPLS-TP management network SHOULD support seamless management
	connectivity with remote MPLS-TP domains and NEs as well as with		connectivity with remote MPLS-TP domains and NEs as well as with
	termination points located in NEs under control by a third party		termination points located in NEs under control by a third party
	network operator. See ITU-T G.8601 [8] for example scenarios in		network operator. See ITU-T G.8601 [8] for example scenarios in
	multi-carrier multi-transport-technology environments.		multi-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
	skipping to change at page 5, line 18		skipping to change at page 5, line 18
	or more specifically via the MCN. The MCN connects MPLS-TP NEs		or more specifically via the MCN. The MCN connects MPLS-TP NEs
	with management systems, NEs with NEs, and management systems		with management systems, NEs with NEs, and management systems
	with management systems. Transport DCN architecture and		with management systems. Transport DCN architecture and
	requirements are specified in ITU-T G.7712/Y.1703 [7], including		requirements are specified in ITU-T G.7712/Y.1703 [7], including
	network layer protocols and their interworking.		network layer protocols and their interworking.
	As a practical requirement, MCN connections require addressing.		As a practical requirement, MCN connections require addressing.
	See the section on addressing in [13] for further information.		See the section on addressing in [13] 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:		management functions for the MCN are required, 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;
	skipping to change at page 5, line 46		skipping to change at page 5, line 46
	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
			that are deployed for supporting the OAM requirements defined in
			[3].
	The MPLS-TP NE MUST support the following transmission		The MPLS-TP NE MUST support the following transmission
	supervision functions:		supervision functions:
	. Supervision of continuity check functions used to detect a
	broken connection;
	. Supervision of connectivity check functions used to detect
	misconnection;
	. Supervision of looping check functions used to detect loops		. Supervision of looping check 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 Alarms based on native OAM, e.g., AIS (Alarm
	Indication Signal) and FDI (Forward Defect Indication)
	. Supervision of traffic loss measurement in both directions
	of the bidirectional connection;
	. Supervision of Misinsertion check function used to detect
	misinserted packet in the connection
	. Supervision of Diagnostic test;
	. Supervision of Route determination;
	. Supervision of Remote defect indication;
	. Supervision of the detection of failure in the sequence of		. Supervision of the detection of failure in the sequence of
	a protocol exchange (e.g. automatic protection switching		a protocol exchange (e.g. automatic protection switching
	protocol);		protocol);
	. Supervision of client failure indication.
	The MPLS-TP NE transmission-related supervision mechanisms MUST		The MPLS-TP NE transmission-related supervision mechanisms MUST
	support the flexibility to be configured to perform on-demand or		support the flexibility to be configured to perform on-demand or
	proactively.		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 fault, storage capacity problem, version
	mismatch, Corrupted data, Out of memory, etc.		mismatch, corrupted data, out of memory, 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 units, cable, and power
	problem.		problem.
	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.
	The MPLS-TP NE MUST support supervision of the OAM mechanisms
	that are deployed for supporting the OAM requirements defined in
	[3].
	5.2. Validation Function		5.2. Validation Function
	Validation is concerned with the integration of Fault Causes		Validation is concerned with the integration of Fault Causes
	into Failures. A Fault Cause indicates a limited interruption of		into Failures. A Fault Cause indicates a limited interruption of
	the required transport function. A Fault Cause is not reported		the required transport function. A Fault Cause is not reported
	to maintenance personnel because it could exist only for a very		to maintenance personnel because it could exist only for a very
	short time. Note that some of these events however are summed up		short time. Note that some of these events however are summed up
	in the Performance Monitoring process, and when this sum exceeds		in the Performance Monitoring process, and when this sum exceeds
	a certain value, a Threshold Report can be generated.		a certain value, a Threshold Report can be generated.
	skipping to change at page 8, line 18		skipping to change at page 7, line 44
	See G.7710 [1] for more description about alarm severity		See G.7710 [1] for more description about 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 may 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 provide alarm suppression functionality that
	prevents the generation of a superfluous alarms.		prevents the generation of superfluous alarms.
	Examples of alarm suppression mechanisms include simply		Examples of alarm suppression mechanisms include simply
	discarding the alarms (or not generating them in the first		discarding the alarms (or not generating them in the first
	place), or aggregating the alarms together, thereby greatly		place), or aggregating the alarms together, thereby greatly
	reducing the number of alarm notifications to be emitted.		reducing the number of alarm notifications to be emitted.
	Note: An MPLS-TP NE supporting the inter-working of one or more		Note: An MPLS-TP NE supporting the inter-working of one or more
	networking technologies (e.g., Ethernet, SDH/SONET, MPLS) with		networking technologies (e.g., Ethernet, SDH/SONET, MPLS) with
	MPLS-TP needs to translate an MPLS-TP fault into an existing		MPLS-TP needs to translate an MPLS-TP fault into an existing
	transport technology failure condition for reporting to the		transport technology failure condition for reporting to the
	skipping to change at page 9, line 12		skipping to change at page 8, line 40
	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 ME 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.
	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
	skipping to change at page 10, line 30		skipping to change at page 10, line 14
	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 provide the capability to configure the OAM
	entities and functions specified in [3].		entities 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 to 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, including bidirectional		entities/functions as part of LSP setup and tear-down, including
	point-to-point connections, associated uni-directional point-to-		co-routed bidirectional point-to-point, associated bidirectional
	point connections, and uni-directional point-to-multipoint		point-to-point, and uni-directional (both point-to-point and
	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 have the flexibility to configure OAM
	parameters to meet their specific operational requirements, such		parameters to meet their specific operational requirements, such
	as whether (1) one-time on-demand immediately or (2) one-time		as whether (1) one-time on-demand immediately or (2) one-time
	on-demand pre-scheduled or (3) on-demand periodically based on a		on-demand pre-scheduled or (3) on-demand periodically based on a
	specified schedule or (4) proactive on-going.		specified schedule or (4) proactive on-going.
	skipping to change at page 12, line 44		skipping to change at page 12, line 24
	7.2.1. Measurement Frequency		7.2.1. Measurement Frequency
	The performance measurement mechanisms MUST support the		The performance measurement mechanisms MUST support the
	flexibility to be configured to operate on-demand or proactively		flexibility to be configured to operate on-demand or proactively
	(i.e. continuously over a period of time).		(i.e. continuously over a period of time).
	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 P2P connections -		- For bidirectional (both co-routed and associated) P2P
			connections -
	. on-demand measurement of single-ended packet loss,
	and loss ratio, measurement are required;
	. proactive measurement of packet loss, and loss
	ratio, measurement for each direction are required.
	- For associated unidirectional P2P connections -
	. on-demand measurement of single-ended packet loss,		. on-demand measurement of single-ended packet loss,
	and loss ratio, measurement are required;		and loss ratio, measurement are required;
	. proactive measurement of packet loss, and loss		. proactive measurement of packet loss, and loss
	ratio, measurement for each direction are required.		ratio, measurement for each direction are required.
	Note: for associated unidirectional P2P connections, this data		Note: for associated bidirectional P2P connections, this data
	can only be measured at end-points.		can only be measured at end-points.
	- 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, are 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 bidirectional (P2P) connection, on-demand measurement		- For co-routed bidirectional (P2P) connection, on-demand
	of one-way and two-way delay are required.		measurement of one-way and two-way delay are required.
			- For associated bidirectional (P2P) connection, on-demand
			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 channels MUST be provided for all network traffic and
	protocols used to support management functions. This MUST		protocols used to support management functions. This MUST
	include, at least, protocols used for configuration, monitoring,		include, at least, protocols used for configuration, monitoring,
	configuration backup, logging, time synchronization,		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.
	8.1.1. Security of Management Communications
	If management communication security is provided, the MPLS-TP NE		If management communication security is provided, 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
	skipping to change at page 14, line 21		skipping to change at page 13, line 44
	8.2.Signaling Communication Channel Security		8.2.Signaling Communication Channel Security
	Security considerations for the SCC are similar to the		Security considerations for the SCC are similar to the
	considerations driving the requirements described in section		considerations driving the requirements described in section
	8.1. Security Requirements for the control plane are out of		8.1. Security Requirements for the control plane are out of
	scope for this document and are expected to be defined in the		scope for this document and are expected to be defined in the
	appropriate control plane specifications. Management of the		appropriate control plane specifications. Management of the
	control plane security must also be defined at that time.		control plane security must also be defined at that time.
	8.3. Data Channel Security		8.3. Distributed Denial of Service
	8.4.Distributed Denial of Service
	Denial of Service (DoS) attack is an attack which tries to		Denial of Service (DoS) attack is an attack which 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 DDOS by using secure protocols, turning off
	unnecessary processes, logging and monitoring, and ingress		unnecessary processes, logging and monitoring, and ingress
	filtering. RFC 4732 [4] provides background on DOS in the		filtering. RFC 4732 [4] provides background on DOS in the
	context of the Internet.		context of the Internet.
	9. Security Considerations		9. Security Considerations
	Section 8 lists 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.
	Provisions to any of the network mechanisms designed to satisfy		Solutions MUST provide mechanisms to prevent unauthorized and/or
	the requirements described herein are required to prevent their		unauthenticated access to private information by network
	unauthorized use. Likewise, these network mechanisms MUST		elements, systems or users.
	provide a means by which an operator can prevent denial of
	service attacks if those network mechanisms are used in such an
	attack.
	Solutions MUST provide mechanisms to prevent this private
	information from being accessed by unauthorized eavesdropping,
	or being directly obtained by an unauthenticated network
	element, system or user.
	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 MAY consider
	private.		private.
	10. IANA Considerations		10. IANA Considerations
	<insert IANA considerations, if any, here)		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		Andrea Maria Mazzini, Ben Niven-Jenkins, Bernd Zeuner, Diego
	Caviglia, Dieter Beller, He Jia, Leo Xiao and Maarten Vissers.		Caviglia, Dieter Beller, He Jia, Leo Xiao, Maarten Vissers, Neil
			Harrison and Rolf Winter.
	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] Vigoureus, 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
	Requirement Levels", RFC 2119, March 1997.		Requirement Levels", RFC 2119, March 1997.
	[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.
	12.2. Informative References		12.2. Informative References
	[10] Chisholm, S. and D. Romascanu, "Alarm Management		[10] 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		[11] ITU-T Recommendation M.20, "Maintenance Philosophy for
	Telecommunication Networks", October 1992.		Telecommunication Networks", October 1992.
	[12] Telcordia, "Network Maintenance: Network Element and		[12] 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		[13] 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		[14] 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",
			draft-ietf-mpls-tp-gach-gal, work in progress.
	13. Author's Addresses		13. Author's Addresses
	Editors:		Editors:
	Scott Mansfield		Scott Mansfield
	Ericsson		Ericsson
	5000 Ericsson Drive		5000 Ericsson Drive
	Warrendale, PA, 15086		Warrendale, PA, 15086
	Phone: +1 724 742 6726		Phone: +1 724 742 6726
	EMail: Scott.Mansfield@Ericsson.com		EMail: Scott.Mansfield@Ericsson.com
	skipping to change at page 17, line 12		skipping to change at page 16, line 34
	Ericsson		Ericsson
	900 Chelmsford Street		900 Chelmsford Street
	Lowell, MA, 01851		Lowell, MA, 01851
	Phone: +1 978 275 7470		Phone: +1 978 275 7470
	Email: Eric.Gray@Ericsson.com		Email: Eric.Gray@Ericsson.com
	Author(s):		Author(s):
	Contributor(s):		Contributor(s):
			Adrian Farrel
			Old Dog Consulting
			Email: adrian@olddog.co.uk
	Copyright Statement		Copyright Statement
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents in effect on the date of
	(http://trustee.ietf.org/license-info) in effect on the date of		publication of this document (http://trustee.ietf.org/license-
	publication of this document. Please review these documents		info). Please review these documents carefully, as they
	carefully, as they describe your rights and restrictions with		describe your rights and restrictions with respect to this
	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 (CC) Examples
	A CC may be realized in a number of ways.		A CC may be realized in a number of ways.
	skipping to change at page 18, line 50		skipping to change at page 18, 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 CC".		This is an "overhead-based CC".
	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 CC 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)
	[GAL-GACH] may be used to label DCC traffic being exchanged on a		[15] may be used to label DCC traffic being exchanged on a data
	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 CC".
	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 CC may be provided by a dedicated channel associated with
	a data channel. For example, in MPLS-TP the GAL [GAL-GACH] may		a data channel. For example, in MPLS-TP the GAL [15] may be
	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 CC 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 CC".
	7. The CC may be provided by mixing the management traffic with		7. The CC 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
End of changes. 42 change blocks.
	102 lines changed or deleted		71 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/