draft-ietf-mpls-tp-requirements-06.txt		draft-ietf-mpls-tp-requirements-07.txt
	MPLS Working Group B. Niven-Jenkins, Ed.		MPLS Working Group B. Niven-Jenkins, Ed.
	Internet-Draft BT		Internet-Draft BT
	Intended status: Standards Track D. Brungard, Ed.		Intended status: Standards Track D. Brungard, Ed.
	Expires: October 6, 2009 AT&T		Expires: November 19, 2009 AT&T
	M. Betts, Ed.		M. Betts, Ed.
	Nortel Networks		Nortel Networks
	N. Sprecher		N. Sprecher
	Nokia Siemens Networks		Nokia Siemens Networks
	S. Ueno		S. Ueno
	NTT		NTT
	April 4, 2009		May 18, 2009
	MPLS-TP Requirements		MPLS-TP Requirements
	draft-ietf-mpls-tp-requirements-06		draft-ietf-mpls-tp-requirements-07
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 39		skipping to change at page 1, line 39
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work 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 6, 2009.		This Internet-Draft will expire on November 19, 2009.
	Copyright Notice		Copyright Notice
	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 in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 3, line 18		skipping to change at page 3, line 18
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
	1.1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . 6		1.1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . 6
	1.1.2. Definitions . . . . . . . . . . . . . . . . . . . . . 8		1.1.2. Definitions . . . . . . . . . . . . . . . . . . . . . 8
	1.2. Transport network overview . . . . . . . . . . . . . . . . 11		1.2. Transport network overview . . . . . . . . . . . . . . . . 11
	1.3. Layer network overview . . . . . . . . . . . . . . . . . . 12		1.3. Layer network overview . . . . . . . . . . . . . . . . . . 12
	2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 13		2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 13
	2.1. General requirements . . . . . . . . . . . . . . . . . . . 13		2.1. General requirements . . . . . . . . . . . . . . . . . . . 13
	2.2. Layering requirements . . . . . . . . . . . . . . . . . . 16		2.2. Layering requirements . . . . . . . . . . . . . . . . . . 16
	2.3. Data plane requirements . . . . . . . . . . . . . . . . . 17		2.3. Data plane requirements . . . . . . . . . . . . . . . . . 17
	2.4. Control plane requirements . . . . . . . . . . . . . . . . 18		2.4. Control plane requirements . . . . . . . . . . . . . . . . 18
	2.5. Network Management (NM) requirements . . . . . . . . . . . 20		2.5. Network Management requirements . . . . . . . . . . . . . 20
	2.6. Operation, Administration and Maintenance (OAM)		2.6. Operation, Administration and Maintenance (OAM)
	requirements . . . . . . . . . . . . . . . . . . . . . . . 20		requirements . . . . . . . . . . . . . . . . . . . . . . . 20
	2.7. Network performance management (PM) requirements . . . . . 20		2.7. Network performance monitoring requirements . . . . . . . 20
	2.8. Recovery requirements . . . . . . . . . . . . . . . . . . 20		2.8. Recovery requirements . . . . . . . . . . . . . . . . . . 20
	2.8.1. Data plane behavior requirements . . . . . . . . . . . 21		2.8.1. Data plane behavior requirements . . . . . . . . . . . 21
	2.8.1.1. Protection . . . . . . . . . . . . . . . . . . . . 21		2.8.1.1. Protection . . . . . . . . . . . . . . . . . . . . 21
	2.8.1.2. Restoration . . . . . . . . . . . . . . . . . . . 22		2.8.1.2. Sharing of protection resources . . . . . . . . . 22
	2.8.1.3. Sharing of protection resources . . . . . . . . . 22		2.8.1.3. Reversion . . . . . . . . . . . . . . . . . . . . 22
	2.8.1.4. Reversion . . . . . . . . . . . . . . . . . . . . 23		2.8.2. Restoration . . . . . . . . . . . . . . . . . . . . . 22
	2.8.2. Triggers for protection, restoration, and reversion . 23		2.8.3. Triggers for protection, restoration, and reversion . 23
	2.8.3. Management plane operation of protection and		2.8.4. Management plane operation of protection and
	restoration . . . . . . . . . . . . . . . . . . . . . 23		restoration . . . . . . . . . . . . . . . . . . . . . 23
	2.8.4. Control plane and in-band OAM operation of recovery . 24		2.8.5. Control plane and in-band OAM operation of recovery . 24
	2.8.5. Topology-specific recovery mechanisms . . . . . . . . 25		2.8.6. Topology-specific recovery mechanisms . . . . . . . . 25
	2.8.5.1. Ring protection . . . . . . . . . . . . . . . . . 25		2.8.6.1. Ring protection . . . . . . . . . . . . . . . . . 25
	2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 28		2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 28
	2.10. Security requirements . . . . . . . . . . . . . . . . . . 28		2.10. Security requirements . . . . . . . . . . . . . . . . . . 28
	3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29		3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 29		4. Security Considerations . . . . . . . . . . . . . . . . . . . 29
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 29		6.1. Normative References . . . . . . . . . . . . . . . . . . . 29
	6.2. Informative References . . . . . . . . . . . . . . . . . . 30		6.2. Informative References . . . . . . . . . . . . . . . . . . 30
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
	1. Introduction		1. Introduction
	Bandwidth demand continues to grow worldwide, stimulated by the		Bandwidth demand continues to grow worldwide, stimulated by the
	skipping to change at page 5, line 35		skipping to change at page 5, line 35
	and it is already playing an important role in transport networks and		and it is already playing an important role in transport networks and
	services. However, not all of MPLS's capabilities and mechanisms are		services. However, not all of MPLS's capabilities and mechanisms are
	needed and/or consistent with transport network operations. There		needed and/or consistent with transport network operations. There
	are also transport technology characteristics that are not currently		are also transport technology characteristics that are not currently
	reflected in MPLS. There is therefore the need to define an MPLS		reflected in MPLS. There is therefore the need to define an MPLS
	Transport Profile (MPLS-TP) that supports the capabilities and		Transport Profile (MPLS-TP) that supports the capabilities and
	functionalities needed for packet transport network services and		functionalities needed for packet transport network services and
	operations through combining the packet experience of MPLS with the		operations through combining the packet experience of MPLS with the
	operational experience and practices of existing transport networks.		operational experience and practices of existing transport networks.
	MPLS-TP will enable the migration of transport networks to a packet-		MPLS-TP will enable the depoyment of packet based transport networks
	based network that will efficiently scale to support packet services		that will efficiently scale to support packet services in a simple
	in a simple and cost effective way. MPLS-TP needs to combine the		and cost effective way. MPLS-TP needs to combine the necessary
	necessary existing capabilities of MPLS with additional minimal		existing capabilities of MPLS with additional minimal mechanisms in
	mechanisms in order that it can be used in a transport role.		order that it can be used in a transport role.
	This document specifies the requirements of an MPLS Transport Profile		This document specifies the requirements of an MPLS Transport Profile
	(MPLS-TP). The requirements are for the behavior of the protocol		(MPLS-TP). The requirements are for the behavior of the protocol
	mechanisms and procedures that constitute building blocks out of		mechanisms and procedures that constitute building blocks out of
	which the MPLS transport profile is constructed. That is, the		which the MPLS transport profile is constructed. That is, the
	requirements indicate what features are to be available in the MPLS		requirements indicate what features are to be available in the MPLS
	toolkit for use by MPLS-TP. The requirements in this document do not		toolkit for use by MPLS-TP. The requirements in this document do not
	describe what functions an MPLS-TP implementation supports. The		describe what functions an MPLS-TP implementation supports. The
	purpose of this document is to identify the toolkit and any new		purpose of this document is to identify the toolkit and any new
	protocol work that is required.		protocol work that is required.
	skipping to change at page 6, line 31		skipping to change at page 6, line 31
	Although both static and dynamic configuration of MPLS-TP transport		Although both static and dynamic configuration of MPLS-TP transport
	paths (including Operations, Administration and Maintenance (OAM) and		paths (including Operations, Administration and Maintenance (OAM) and
	protection capabilities) is required by this document, it MUST be		protection capabilities) is required by this document, it MUST be
	possible for operators to be able to completely operate (including		possible for operators to be able to completely operate (including
	OAM and protection capabilities) an MPLS-TP network in the absence of		OAM and protection capabilities) an MPLS-TP network in the absence of
	any control plane protocols for dynamic configuration.		any control plane protocols for dynamic configuration.
	1.1. Terminology		1.1. Terminology
	Note: Mapping between the terms in this section and ITU-T terminology		Note: Mapping between the terms in this section and ITU-T terminology
	will be described in a subsequent document.		is described in [I-D.helvoort-mpls-tp-rosetta-stone].
	The recovery requirements in this document use the recovery		The recovery requirements in this document use the recovery
	terminology defined in RFC 4427 [RFC4427], this is applied to both		terminology defined in RFC 4427 [RFC4427], this is applied to both
	control plane and management plane based operations of MPLS-TP		control plane and management plane based operations of MPLS-TP
	transport paths.		transport paths.
	1.1.1. Abbreviations		1.1.1. Abbreviations
	ASON: Automatically Switched Optical Network		ASON: Automatically Switched Optical Network
	skipping to change at page 7, line 18		skipping to change at page 7, line 18
	IPTV: IP Television		IPTV: IP Television
	L2: Layer 2		L2: Layer 2
	L3: Layer 3		L3: Layer 3
	LSP: Label Switched Path		LSP: Label Switched Path
	LSR: Label Switching Router		LSR: Label Switching Router
	MEP: Maintenance End Point
	MIP: Maintenance Intermediate Point
	MPLS: Multi-Protocol Label Switching		MPLS: Multi-Protocol Label Switching
	OAM: Operations, Administration and Maintenance		OAM: Operations, Administration and Maintenance
	OPEX: Operational Expenditure		OPEX: Operational Expenditure
	OSI: Open Systems Interconnection		OSI: Open Systems Interconnection
	OTN: Optical Transport Network		OTN: Optical Transport Network
	P2MP: Point to Multi-Point		P2MP: Point to Multi-Point
	P2P: Point to Point		P2P: Point to Point
	PDU: Protocol Data Unit		PDU: Protocol Data Unit
	PM: Performance Management
	PSC: Protection State Coordination		PSC: Protection State Coordination
	PW: Pseudo Wire		PW: Pseudo Wire
	QoS: Quality of Service		QoS: Quality of Service
	RAN: Radio Access Network		RAN: Radio Access Network
	SDH: Synchronous Digital Hierarchy		SDH: Synchronous Digital Hierarchy
	skipping to change at page 8, line 46		skipping to change at page 8, line 40
	Client layer network: In a client/server relationship (see G.805		Client layer network: In a client/server relationship (see G.805
	[ITU.G805.2000]), the client layer network receives a (transport)		[ITU.G805.2000]), the client layer network receives a (transport)
	service from the lower server layer network (usually the layer		service from the lower server layer network (usually the layer
	network under consideration).		network under consideration).
	Concatenated Segment: A serial-compound link connection as defined in		Concatenated Segment: A serial-compound link connection as defined in
	G.805 [ITU.G805.2000]. A concatenated segment is a contiguous part		G.805 [ITU.G805.2000]. A concatenated segment is a contiguous part
	of an LSP or multi-segment PW that comprises a set of segments and		of an LSP or multi-segment PW that comprises a set of segments and
	their interconnecting nodes in sequence. See also "Segment".		their interconnecting nodes in sequence. See also "Segment".
			Control Plane: Within the scope of this document the control plane
			performs transport path control functions. Through signalling, the
			control plane sets up, modifies and releases transport paths, and may
			recover a transport path in case of a failure. The control plane
			also performs other functions in support of transport path control,
			such as routing information dissemination.
	Co-routed Bidirectional path: A path where the forward and backward		Co-routed Bidirectional path: A path where the forward and backward
	directions follow the same route (links and nodes) across the		directions follow the same route (links and nodes) across the
	network. Both directions are setup, monitored and protected as a		network. Both directions are setup, monitored and protected as a
	single entity.		single entity. A transport network path is typically co-routed.
	Domain: A domain represents a collection of entities (for example		Domain: A domain represents a collection of entities (for example
	network elements) that are grouped for a particular purpose, examples		network elements) that are grouped for a particular purpose, examples
	of which are administrative and/or managerial responsibilities, trust		of which are administrative and/or managerial responsibilities, trust
	relationships, addressing schemes, infrastructure capabilities,		relationships, addressing schemes, infrastructure capabilities,
	aggregation, survivability techniques, distributions of control		aggregation, survivability techniques, distributions of control
	functionality, etc. Examples of such domains include IGP areas and		functionality, etc. Examples of such domains include IGP areas and
	Autonomous Systems.		Autonomous Systems.
	Layer network: Layer network is defined in G.805 [ITU.G805.2000]. A		Layer network: Layer network is defined in G.805 [ITU.G805.2000]. A
	skipping to change at page 10, line 5		skipping to change at page 10, line 5
	MPLS-TP Ring Topology: In an MPLS-TP ring topology each LSR is		MPLS-TP Ring Topology: In an MPLS-TP ring topology each LSR is
	connected to exactly two other LSRs, each via a single point-to-point		connected to exactly two other LSRs, each via a single point-to-point
	bidirectional MPLS-TP capable link. A ring may also be constructed		bidirectional MPLS-TP capable link. A ring may also be constructed
	from only two LSRs where there are also exactly two links. Rings may		from only two LSRs where there are also exactly two links. Rings may
	be connected to other LSRs to form a larger network. Traffic		be connected to other LSRs to form a larger network. Traffic
	originating or terminating outside the ring may be carried over the		originating or terminating outside the ring may be carried over the
	ring. Client network nodes (such as CEs) may be connected directly		ring. Client network nodes (such as CEs) may be connected directly
	to an LSR in the ring.		to an LSR in the ring.
	Section Layer Network: A section is a server layer (which may be		Section Layer Network: A section layer is a server layer (which may
	MPLS-TP or a different technology) which provides for encapsulation		be MPLS-TP or a different technology) which provides for the transfer
	and OAM of a client layer network. A section layer may provide for		of the section layer client information between adjacent nodes in the
	aggregation of multiple MPLS-TP clients. Note that G.805		transport path layer or transport service layer. A section layer may
			provide for aggregation of multiple MPLS-TP clients. Note that G.805
	[ITU.G805.2000] defines the section layer as one of the two layer		[ITU.G805.2000] defines the section layer as one of the two layer
	networks in a transmission media layer network. The other layer		networks in a transmission media layer network. The other layer
	network is the physical media layer network.		network is the physical media layer network.
	Segment: A link connection as defined in G.805 [ITU.G805.2000]. A		Segment: A link connection as defined in G.805 [ITU.G805.2000]. A
	segment is the part of an LSP that traverses a single link or the		segment is the part of an LSP that traverses a single link or the
	part of a PW that traverses a single link (i.e. that connects a pair		part of a PW that traverses a single link (i.e. that connects a pair
	of adjacent {Switching|Terminating} Provider Edges). See also		of adjacent {Switching|Terminating} Provider Edges). See also
	"Concatenated Segment".		"Concatenated Segment".
	skipping to change at page 10, line 32		skipping to change at page 10, line 33
	under consideration).		under consideration).
	Sublayer: Sublayer is defined in G.805 [ITU.G805.2000]. The		Sublayer: Sublayer is defined in G.805 [ITU.G805.2000]. The
	distinction between a layer network and a sublayer is that a sublayer		distinction between a layer network and a sublayer is that a sublayer
	is not directly accessible to clients outside of its encapsulating		is not directly accessible to clients outside of its encapsulating
	layer network and offers no direct transport service for a higher		layer network and offers no direct transport service for a higher
	layer (client) network.		layer (client) network.
	Switching Provider Edge (S-PE): See [I-D.ietf-pwe3-ms-pw-arch].		Switching Provider Edge (S-PE): See [I-D.ietf-pwe3-ms-pw-arch].
	Tandem Connection: A tandem connection is an arbitrary part of a
	transport path that can be monitored (via OAM) independently from the
	end-to-end monitoring (OAM). It may be a monitored segment or a
	monitored concatenated segment of a transport path. The tandem
	connection may also include the forwarding engine(s) of the node(s)
	at the edge(s) of the segment or concatenated segment.
	Terminating Provider Edge (T-PE): See [I-D.ietf-pwe3-ms-pw-arch].		Terminating Provider Edge (T-PE): See [I-D.ietf-pwe3-ms-pw-arch].
	Transport Path: A network connection as defined in G.805		Transport Path: A network connection as defined in G.805
	[ITU.G805.2000]. In an MPLS-TP environment a transport path		[ITU.G805.2000]. In an MPLS-TP environment a transport path
	corresponds to an LSP or a PW.		corresponds to an LSP or a PW.
	Transport Path Layer: A layer network that provides point-to-point or		Transport Path Layer: A (sub-)layer network that provides point-to-
	point-to-multipoint transport paths that may be used to carry a		point or point-to-multipoint transport paths. It provides
	higher (client) layer network or aggregates of higher (client) layer
	networks, for example the transport service layer. It provides
	independent (of the client) OAM when transporting its clients.		independent (of the client) OAM when transporting its clients.
	Transport Service Layer: A layer network in which transport paths are		Transport Service Layer: A layer network in which transport paths are
	used to carry a customer's (individual or bundled) service (may be		used to carry a customer's (individual or bundled) service (may be
	point-to-point, point-to-multipoint or multipoint-to-multipoint		point-to-point, point-to-multipoint or multipoint-to-multipoint
	services).		services).
	Transmission Media Layer: A layer network, consisting of a section		Transmission Media Layer: A layer network, consisting of a section
	layer network and a physical layer network as defined in G.805		layer network and a physical layer network as defined in G.805
	[ITU.G805.2000], that provides sections (two-port point-to-point		[ITU.G805.2000], that provides sections (two-port point-to-point
	skipping to change at page 14, line 7		skipping to change at page 13, line 41
	2.1. General requirements		2.1. General requirements
	1 The MPLS-TP data plane MUST be a subset of the MPLS data plane as		1 The MPLS-TP data plane MUST be a subset of the MPLS data plane as
	defined by the IETF. When MPLS offers multiple options in this		defined by the IETF. When MPLS offers multiple options in this
	respect, MPLS-TP SHOULD select the minimum sub-set (necessary and		respect, MPLS-TP SHOULD select the minimum sub-set (necessary and
	sufficient subset) applicable to a transport network application.		sufficient subset) applicable to a transport network application.
	2 Any new functionality that is defined to fulfill the requirements		2 Any new functionality that is defined to fulfill the requirements
	for MPLS-TP MUST be agreed within the IETF through the IETF		for MPLS-TP MUST be agreed within the IETF through the IETF
	consensus process and MUST re-use (as far as practically		consensus process as per [RFC4929]
	possible) existing MPLS standards.
	3 Mechanisms and capabilities MUST be able to interoperate with		3 The MPLS-TP design SHOULD as far as reasonably possible re-use
			existing MPLS standards.
			4 Mechanisms and capabilities MUST be able to interoperate with
	existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] control and		existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] control and
	data planes where appropriate.		data planes where appropriate.
	A. Data plane interoperability MUST NOT require a gateway		A. Data plane interoperability MUST NOT require a gateway
	function.		function.
	4 MPLS-TP and its interfaces, both internal and external, MUST be		5 MPLS-TP and its interfaces, both internal and external, MUST be
	sufficiently well-defined that interworking equipment supplied by		sufficiently well-defined that interworking equipment supplied by
	multiple vendors will be possible both within a single domain,		multiple vendors will be possible both within a single domain,
	and between domains.		and between domains.
	5 MPLS-TP MUST be a connection-oriented packet switching technology		6 MPLS-TP MUST be a connection-oriented packet switching technology
	with traffic engineering capabilities that allow deterministic		with traffic engineering capabilities that allow deterministic
	control of the use of network resources.		control of the use of network resources.
	6 MPLS-TP MUST support traffic engineered point to point (P2P) and		7 MPLS-TP MUST support traffic engineered point to point (P2P) and
	point to multipoint (P2MP) transport paths.		point to multipoint (P2MP) transport paths.
	7 MPLS-TP MUST support the logical separation of the control and		8 MPLS-TP MUST support unidirectional, co-routed bidirectional and
			associated bidirectional point-to-point transport paths.
			9 The end points of a co-routed bidirectional transport path MUST
			be aware of the pairing relationship of the forward and reverse
			paths used to support the bidirectional service.
			10 The intermediate nodes of a co-routed bidirectional transport
			path at each (sub-)layer MUST be aware of the pairing
			relationship of the forward and the backward directions of that
			transport path.
			11 The end points of an associated bidirectional transport path MUST
			be aware of the pairing relationship of the forward and reverse
			paths used to support the bidirectional service.
			12 The intermediate nodes of an associated bidirectional transport
			path at each (sub-)layer SHOULD NOT be aware of the pairing
			relationship of the forward and the backward directions of that
			transport path.
			13 MPLS-TP MUST support bidirectional transport paths with symmetric
			bandwidth requirements, i.e. the amount of reserved bandwidth is
			the same between the forward and backward directions.
			14 MPLS-TP MUST support bidirectional transport paths with
			asymmetric bandwidth requirements, i.e. the amount of reserved
			bandwidth differs between the forward and backward directions.
			15 MPLS-TP MUST support the logical separation of the control and
	management planes from the data plane.		management planes from the data plane.
	8 MPLS-TP MUST support the physical separation of the control and		16 MPLS-TP MUST support the physical separation of the control and
	management planes from the data plane.		management planes from the data plane.
	9 MPLS-TP MUST support static provisioning of transport paths via		17 MPLS-TP MUST support static provisioning of transport paths via
	the management plane.		the management plane.
	10 Mechanisms in an MPLS-TP network that satisfy functional		18 Mechanisms in an MPLS-TP layer network that satisfy functional
	requirements that are common to general transport networks (i.e.,		requirements that are common to general transport layer networks
	independent of technology) SHOULD be operable in a way that is		(i.e., independent of technology) SHOULD be operable in a way
	similar to the way the equivalent mechanisms are operated in		that is similar to the way the equivalent mechanisms are operated
	other transport networks.		in other transport layer technologies.
	11 Static provisioning MUST NOT depend on the presence of any		19 Static provisioning MUST NOT depend on the presence of any
	element of a control plane.		element of a control plane.
	12 MPLS-TP MUST support the capability for network operation		20 MPLS-TP MUST support the capability for network operation
	(including OAM and recovery) via the management plane (without		(including OAM and recovery) via the management plane (without
	the use of any control plane protocols).		the use of any control plane protocols).
	13 A solution MUST be defined to support dynamic provisioning and		21 A solution MUST be defined to support dynamic provisioning and
	restoration of MPLS-TP transport paths via a control plane.		restoration of MPLS-TP transport paths via a control plane.
	14 MPLS-TP MUST support the co-existence of statically and		22 MPLS-TP MUST support the co-existence of statically and
	dynamically provisioned/managed MPLS-TP transport paths within		dynamically provisioned/managed MPLS-TP transport paths within
	the same layer network or domain.		the same layer network or domain.
	15 The MPLS-TP data plane MUST be capable of		23 The MPLS-TP data plane MUST be capable of
	A. forwarding data independent of the control or management		A. forwarding data independent of the control or management
	plane used to configure and operate the MPLS-TP layer		plane used to configure and operate the MPLS-TP layer
	network.		network.
	B. taking recovery actions independent of the control plane used		B. taking recovery actions independent of the control or
	to configure the MPLS-TP layer network. If the control plane		management plane used to configure the MPLS-TP layer network.
	does not restart, the data plane connections MUST be held and
	NOT time out.
	16 MPLS-TP MUST support mechanisms to avoid or minimize traffic		C. operating normally (i.e. forwarding, OAM and protection MUST
			continue to operate) if the management plane or control plane
			that configured the transport paths fails.
			24 MPLS-TP MUST support mechanisms to avoid or minimize traffic
	impact (e.g. packet delay, reordering and loss) during network		impact (e.g. packet delay, reordering and loss) during network
	reconfiguration.		reconfiguration.
	17 MPLS-TP MUST support transport paths through multiple homogeneous		25 MPLS-TP MUST support transport paths through multiple homogeneous
	domains.		domains.
	18 MPLS-TP SHOULD support transport paths through multiple non-		26 MPLS-TP SHOULD support transport paths through multiple non-
	homogeneous domains.		homogeneous domains.
	19 MPLS-TP MUST NOT dictate the deployment of any particular network		27 MPLS-TP MUST NOT dictate the deployment of any particular network
	topology either physical or logical, however:		topology either physical or logical, however:
	A. It MUST be possible to deploy MPLS-TP in rings.		A. It MUST be possible to deploy MPLS-TP in rings.
	B. It MUST be possible to deploy MPLS-TP in arbitrarily		B. It MUST be possible to deploy MPLS-TP in arbitrarily
	interconnected rings with one or two points of		interconnected rings with one or two points of
	interconnection.		interconnection.
	C. MPLS-TP MUST support rings of at least 16 nodes in order to		C. MPLS-TP MUST support rings of at least 16 nodes in order to
	support the upgrade of existing TDM rings to MPLS-TP.		support the upgrade of existing TDM rings to MPLS-TP.
	MPLS-TP SHOULD support rings with more than 16 nodes.		MPLS-TP SHOULD support rings with more than 16 nodes.
	20 MPLS-TP MUST be able to scale at least as well as existing		28 MPLS-TP MUST be able to scale at least as well as existing
	transport technologies with growing and increasingly complex		transport technologies with growing and increasingly complex
	network topologies as well as with increasing bandwidth demands,		network topologies as well as with increasing bandwidth demands,
	number of customers, and number of services.		number of customers, and number of services.
	21 MPLS-TP SHOULD support mechanisms to safeguard against the		29 MPLS-TP SHOULD support mechanisms to safeguard against the
	provisioning of transport paths which contain forwarding loops.		provisioning of transport paths which contain forwarding loops.
	2.2. Layering requirements		2.2. Layering requirements
	22 A generic and extensible solution MUST be provided to support the		30 A generic and extensible solution MUST be provided to support the
	transport of one or more client layer networks (e.g. MPLS-TP,		transport of one or more client layer networks (e.g. MPLS-TP,
	IP, MPLS, Ethernet, ATM, FR, etc.) over an MPLS-TP layer network.		IP, MPLS, Ethernet, ATM, FR, etc.) over an MPLS-TP layer network.
	23 A generic and extensible solution MUST be provided to support the		31 A generic and extensible solution MUST be provided to support the
	transport of MPLS-TP transport paths over one or more server		transport of MPLS-TP transport paths over one or more server
	layer networks (such as MPLS-TP, Ethernet, SONET/SDH, OTN, etc.).		layer networks (such as MPLS-TP, Ethernet, SONET/SDH, OTN, etc.).
	Requirements for bandwidth management within a server layer		Requirements for bandwidth management within a server layer
	network are outside the scope of this document.		network are outside the scope of this document.
	24 In an environment where an MPLS-TP layer network is supporting a		32 In an environment where an MPLS-TP layer network is supporting a
	client layer network, and the MPLS-TP layer network is supported		client layer network, and the MPLS-TP layer network is supported
	by a server layer network then operation of the MPLS-TP layer		by a server layer network then operation of the MPLS-TP layer
	network MUST be possible without any dependencies on the server		network MUST be possible without any dependencies on the server
	or client layer network.		or client layer network.
	A. The server layer MUST guarantee that the traffic loading		A. The server layer MUST guarantee that the traffic loading
	imposed by other clients does not cause the transport service		imposed by other clients does not cause the transport service
	provided to the MPLS-TP layer to fall bellow the agreed		provided to the MPLS-TP layer to fall bellow the agreed
	level. Mechanisms to achieve this are outside the scope of		level. Mechanisms to achieve this are outside the scope of
	these requirements.		these requirements.
	B. It MUST be possible to isolate the control and management		B. It MUST be possible to isolate the control and management
	planes of the MPLS-TP layer network from the control and		planes of the MPLS-TP layer network from the control and
	management planes of the client and server layer networks.		management planes of the client and server layer networks.
	25 A solution MUST be provided to support the transport of a client		33 A solution MUST be provided to support the transport of a client
	MPLS or MPLS-TP layer network over a server MPLS or MPLS-TP layer		MPLS or MPLS-TP layer network over a server MPLS or MPLS-TP layer
	network.		network.
	A. The level of co-ordination required between the client and		A. The level of co-ordination required between the client and
	server MPLS(-TP) layer networks MUST be minimized (preferably		server MPLS(-TP) layer networks MUST be minimized (preferably
	no co-ordination will be required).		no co-ordination will be required).
	B. The MPLS(-TP) server layer network MUST be capable of		B. The MPLS(-TP) server layer network MUST be capable of
	transporting the complete set of packets generated by the		transporting the complete set of packets generated by the
	client MPLS(-TP) layer network, which may contain packets		client MPLS(-TP) layer network, which may contain packets
	that are not MPLS packets (e.g. IP or CNLS packets used by		that are not MPLS packets (e.g. IP or CNLS packets used by
	the control/management plane of the client MPLS(-TP) layer		the control/management plane of the client MPLS(-TP) layer
	network).		network).
	26 It MUST be possible to operate the layers of a multi-layer		34 It MUST be possible to operate the layers of a multi-layer
	network that includes an MPLS-TP layer autonomously.		network that includes an MPLS-TP layer autonomously.
	The above are not only technology requirements, but also operational		The above are not only technology requirements, but also operational
	requirements. Different administrative groups may be responsible for		requirements. Different administrative groups may be responsible for
	the same layer network or different layer networks.		the same layer network or different layer networks.
	27 It MUST be possible to hide MPLS-TP layer network addressing and		35 It MUST be possible to hide MPLS-TP layer network addressing and
	other information (e.g. topology) from client layer networks.		other information (e.g. topology) from client layer networks.
	However, it SHOULD be possible, at the option of the operator, to		However, it SHOULD be possible, at the option of the operator, to
	leak a limited amount of summarized information (such as SRLGs or		leak a limited amount of summarized information (such as SRLGs or
	reachability) between layers.		reachability) between layers.
	2.3. Data plane requirements		2.3. Data plane requirements
	28 It MUST be possible for the end points of an MPLS-TP transport		36 It MUST be possible for the end points of an MPLS-TP transport
	path that is carrying an aggregate of client transport paths to		path that is carrying an aggregate of client transport paths to
	be able to decompose the aggregate transport path into its		be able to decompose the aggregate transport path into its
	component client transport paths.		component client transport paths.
	29 A transport path on a link MUST be uniquely identifiable by a		37 A transport path on a link MUST be uniquely identifiable by a
	single label on that link.		single label on that link.
	30 A transport path's source MUST be identifiable at its destination		38 A transport path's source MUST be identifiable at its destination
	within its layer network in coordination with the management		within its layer network.
	plane or control plane.
	31 MPLS-TP MUST be capable of using P2MP server (sub-)layer		39 MPLS-TP MUST be capable of using P2MP server (sub-)layer
	capabilities as well as P2P server (sub-)layer capabilities when		capabilities as well as P2P server (sub-)layer capabilities when
	supporting P2MP MPLS-TP transport paths.		supporting P2MP MPLS-TP transport paths.
	32 MPLS-TP MUST support unidirectional, co-routed bidirectional and		40 MPLS-TP MUST support unidirectional point-to-multipoint transport
	associated bidirectional point-to-point transport paths.
	33 The end points of a co-routed bidirectional transport path MUST
	be aware of the pairing relationship of the forward and reverse
	paths used to support the bidirectional service.
	34 The intermediate nodes (including MEPs, MIPs and other internal
	functions as appropriate) of a co-routed bidirectional transport
	path at each (sub-)layer MUST be aware of the pairing
	relationship of the forward and the backward directions of that
	transport path.
	35 The end points of an associated bidirectional transport path MUST
	be aware of the pairing relationship of the forward and reverse
	paths used to support the bidirectional service.
	36 The intermediate nodes (including MEPs, MIPs and other internal
	functions as appropriate) of an associated bidirectional
	transport path at each (sub-)layer SHOULD NOT be aware of the
	pairing relationship of the forward and the backward directions
	of that transport path.
	37 MPLS-TP MUST support bidirectional transport paths with
	asymmetric bandwidth requirements, i.e. the amount of reserved
	bandwidth differs between the forward and backward directions.
	38 MPLS-TP MUST support unidirectional point-to-multipoint transport
	paths.		paths.
	39 MPLS-TP MUST be extensible in order to accommodate new types of		41 MPLS-TP MUST be extensible in order to accommodate new types of
	client layer networks and services.		client layer networks and services.
	40 MPLS-TP SHOULD support mechanisms to enable the reserved		42 MPLS-TP SHOULD support mechanisms to enable the reserved
	bandwidth associated with a transport path to be increased		bandwidth associated with a transport path to be increased
	without impacting the existing traffic on that transport path		without impacting the existing traffic on that transport path
	provided enough resources are available.		provided enough resources are available.
	41 MPLS-TP SHOULD support mechanisms to enable the reserved		43 MPLS-TP SHOULD support mechanisms to enable the reserved
	bandwidth of a transport path to be decreased without impacting		bandwidth of a transport path to be decreased without impacting
	the existing traffic on that transport path, provided that the		the existing traffic on that transport path, provided that the
	level of existing traffic is smaller than the reserved bandwidth		level of existing traffic is smaller than the reserved bandwidth
	following the decrease.		following the decrease.
	42 MPLS-TP MUST support mechanisms which ensure the integrity of the		44 MPLS-TP MUST support mechanisms which ensure the integrity of the
	transported customer's service traffic as required by its		transported customer's service traffic as required by its
	associated SLA. Loss of integrity may be defined as packet		associated SLA. Loss of integrity may be defined as packet
	corruption, re-ordering or loss during normal network conditions.		corruption, re-ordering or loss during normal network conditions.
	43 MPLS-TP MUST support mechanisms to detect when loss of integrity		45 MPLS-TP MUST support mechanisms to detect when loss of integrity
	of the transported customer's service traffic has occurred.		of the transported customer's service traffic has occurred.
	44 MPLS-TP MUST support an unambiguous and reliable means of		46 MPLS-TP MUST support an unambiguous and reliable means of
	distinguishing users' (client) packets from MPLS-TP control		distinguishing users' (client) packets from MPLS-TP control
	packets (e.g. control plane, management plane, OAM and protection		packets (e.g. control plane, management plane, OAM and protection
	switching packets).		switching packets).
	2.4. Control plane requirements		2.4. Control plane requirements
	This section defines the requirements that apply to an MPLS-TP		This section defines the requirements that apply to an MPLS-TP
	control plane. Note that it MUST be possible to operate an MPLS-TP		control plane. Note that it MUST be possible to operate an MPLS-TP
	network without using a control plane.		network without using a control plane.
	The ITU-T has defined an architecture for Automatically Switched		The ITU-T has defined an architecture for Automatically Switched
	Optical and Transport Networks (ASON/ASTN) in G.8080 [ITU.G8080.2006]		Optical Networks (ASON) in G.8080 [ITU.G8080.2006] and G.8080 Amd1
	and G.8080 Amd1 [ITU.G8080.2008]. The control plane for MPLS-TP MUST		[ITU.G8080.2008]. The control plane for MPLS-TP MUST fit within the
	fit within the ASON/ASTN architecture.		ASON architecture.
	An interpretation of the ASON/ASTN signaling and routing requirements		An interpretation of the ASON/ASTN signaling and routing requirements
	in the context of GMPLS can be found in [RFC4139] and [RFC4258].		in the context of GMPLS can be found in [RFC4139] and [RFC4258].
	Additionally:		Additionally:
	45 It MUST be possible to operate and configure the MPLS-TP data		47 It MUST be possible to operate and configure the MPLS-TP data
	plane without any IP forwarding capability in the MPLS-TP data		plane without any IP forwarding capability in the MPLS-TP data
	plane.		plane. i.e. the data plane only operates on the MPLS label.
	46 The MPLS-TP control pane MUST support control plane topology and		48 The MPLS-TP control plane MUST support control plane topology and
	data plane topology independence. As a consequence a failure of		data plane topology independence. As a consequence a failure of
	the control plane does not imply that there has also been a		the control plane does not imply that there has also been a
	failure of the data plane.		failure of the data plane.
	47 The MPLS-TP control plane MUST be able to be operated independent		49 The MPLS-TP control plane MUST be able to be operated independent
	of any particular client or server layer control plane.		of any particular client or server layer control plane.
	48 MPLS-TP SHOULD define a solution to support an integrated control		50 MPLS-TP SHOULD define a solution to support an integrated control
	plane encompassing MPLS-TP together with its server and client		plane encompassing MPLS-TP together with its server and client
	layer networks when these layer networks belong to the same		layer networks when these layer networks belong to the same
	administrative domain.		administrative domain.
	49 The MPLS-TP control plane MUST support establishing all the		51 The MPLS-TP control plane MUST support establishing all the
	connectivity patterns defined for the MPLS-TP data plane (e.g.,		connectivity patterns defined for the MPLS-TP data plane (i.e.,
	unidirectional and bidirectional P2P, unidirectional P2MP, etc.)		unidirectional P2P, associated bidirectional P2P, co-routed
	including configuration of protection functions and any		bidirectional P2P, unidirectional P2MP) including configuration
	associated maintenance functions.		of protection functions and any associated maintenance functions.
	50 The MPLS-TP control plane MUST support the configuration and		52 The MPLS-TP control plane MUST support the configuration and
	modification of OAM maintenance points as well as the activation/		modification of OAM maintenance points as well as the activation/
	deactivation of OAM when the transport path or transport service		deactivation of OAM when the transport path or transport service
	is established or modified.		is established or modified.
	51 An MPLS-TP control plane MUST support operation of the recovery		53 An MPLS-TP control plane MUST support operation of the recovery
	functions described in Section 2.8.		functions described in Section 2.8.
	52 An MPLS-TP control plane MUST scale gracefully to support a large		54 An MPLS-TP control plane MUST scale gracefully to support a large
	number of transport paths, nodes and links.		number of transport paths, nodes and links.
	53 If a control plane is used for MPLS-TP, the control plane's		55 If a control plane is used for MPLS-TP, following a control plane
	graceful restart capabilities, if any, MUST be supported.		failure, the control plane MUST be capable of restarting and
			relearning its previous state without impacting forwarding.
	54 An MPLS-TP control plane MUST provide a mechanism for dynamic		56 An MPLS-TP control plane MUST provide a mechanism for dynamic
	ownership transfer of the control of MPLS-TP transport paths from		ownership transfer of the control of MPLS-TP transport paths from
	the management plane to the control plane and vice versa. The		the management plane to the control plane and vice versa. The
	number of reconfigurations required in the data plane MUST be		number of reconfigurations required in the data plane MUST be
	minimized (preferably no data plane reconfiguration will be		minimized (preferably no data plane reconfiguration will be
	required).		required).
	2.5. Network Management (NM) requirements		2.5. Network Management requirements
	For requirements related to NM functionality (Management Plane in		For requirements related to network management functionality
	ITU-T terminology) for MPLS-TP, see the MPLS-TP NM requirements		(Management Plane in ITU-T terminology) for MPLS-TP, see the MPLS-TP
	document [I-D.ietf-mpls-tp-nm-req].		Network Management requirements document [I-D.ietf-mpls-tp-nm-req].
	2.6. Operation, Administration and Maintenance (OAM) requirements		2.6. Operation, Administration and Maintenance (OAM) requirements
	For requirements related to OAM functionality for MPLS-TP, see the		For requirements related to OAM functionality for MPLS-TP, see the
	MPLS-TP OAM requirements document		MPLS-TP OAM requirements document
	[I-D.ietf-mpls-tp-oam-requirements].		[I-D.ietf-mpls-tp-oam-requirements].
	2.7. Network performance management (PM) requirements		2.7. Network performance monitoring requirements
	For requirements related to PM functionality for MPLS-TP, see the		For requirements related to performance monitoring functionality for
	MPLS-TP OAM requirements document		MPLS-TP, see the MPLS-TP OAM requirements document
	[I-D.ietf-mpls-tp-oam-requirements].		[I-D.ietf-mpls-tp-oam-requirements].
	2.8. Recovery requirements		2.8. Recovery requirements
	Network survivability plays a critical role in the delivery of		Network survivability plays a critical role in the delivery of
	reliable services. Network availability is a significant contributor		reliable services. Network availability is a significant contributor
	to revenue and profit. Service guarantees in the form of SLAs		to revenue and profit. Service guarantees in the form of SLAs
	require a resilient network that rapidly detects facility or node		require a resilient network that rapidly detects facility or node
	failures and restores network operation in accordance with the terms		failures and restores network operation in accordance with the terms
	of the SLA.		of the SLA.
	55 MPLS-TP MUST provide protection and restoration mechanisms.		57 MPLS-TP MUST provide protection and restoration mechanisms.
	A. MPLS-TP recovery techniques SHOULD be identical (or as		A. MPLS-TP recovery techniques SHOULD be identical (or as
	similar as possible) to those already used in existing		similar as possible) to those already used in existing
	transport networks to simplify implementation and operations.		transport networks to simplify implementation and operations.
	However, this MUST NOT override any other requirement.		However, this MUST NOT override any other requirement.
	B. Recovery techniques used for P2P and P2MP SHOULD be identical		B. Recovery techniques used for P2P and P2MP SHOULD be identical
	to simplify implementation and operation. However, this MUST		to simplify implementation and operation. However, this MUST
	NOT override any other requirement.		NOT override any other requirement.
	56 MPLS-TP recovery mechanisms MUST be applicable at various levels		58 MPLS-TP recovery mechanisms MUST be applicable at various levels
	throughout the network including support for link, transport		throughout the network including support for link, transport
	path, segment, concatenated segment and end to end recovery.		path, segment, concatenated segment and end to end recovery.
	57 MPLS-TP recovery paths MUST meet the SLA protection objectives of		59 MPLS-TP recovery paths MUST meet the SLA protection objectives of
	the service.		the service.
	A. MPLS-TP MUST provide mechanisms to guarantee 50ms recovery		A. MPLS-TP MUST provide mechanisms to guarantee 50ms recovery
	times from the moment of fault detection in networks with		times from the moment of fault detection in networks with
	spans less than 1200 km.		spans less than 1200 km.
	B. For protection it MUST be possible to require protection of		B. For protection it MUST be possible to require protection of
	100% of the traffic on the protected path.		100% of the traffic on the protected path.
	C. Recovery objectives SHOULD be configurable per transport		C. Recovery objectives SHOULD be configurable per transport
	path, and SHOULD support objectives for bandwidth and QoS.		path.
	D. Recovery MUST meet SLA requirements over multiple domains.		D. Recovery MUST meet SLA requirements over multiple domains.
	58 The recovery mechanisms SHOULD be applicable to any topology.		60 The recovery mechanisms SHOULD be applicable to any topology.
	59 The recovery mechanisms MUST support the means to operate in		61 The recovery mechanisms MUST support the means to operate in
	synergy with (including coordination of timing) the recovery		synergy with (including coordination of timing) the recovery
	mechanisms present in any client or server transport networks		mechanisms present in any client or server transport networks
	(for example, Ethernet, SDH, OTN, WDM) to avoid race conditions		(for example, Ethernet, SDH, OTN, WDM) to avoid race conditions
	between the layers.		between the layers.
	60 MPLS-TP recovery and reversion mechanisms MUST prevent frequent		62 MPLS-TP recovery and reversion mechanisms MUST prevent frequent
	operation of recovery in the event of an intermittent defect.		operation of recovery in the event of an intermittent defect.
	2.8.1. Data plane behavior requirements		2.8.1. Data plane behavior requirements
	General protection and survivability requirements are expressed in		General protection and survivability requirements are expressed in
	terms of the behavior in the data plane.		terms of the behavior in the data plane.
	2.8.1.1. Protection		2.8.1.1. Protection
	Note: Only nodes that are aware of the pairing relationship between		Note: Only nodes that are aware of the pairing relationship between
	the forward and backward directions of an associated bidirectional		the forward and backward directions of an associated bidirectional
	transport path can be used as end points to protect all or part of		transport path can be used as end points to protect all or part of
	that transport path.		that transport path.
	61 MPLS-TP MUST support 1+1 protection.		63 It MUST be possible to provide protection for the MPLS-TP data
			plane without any IP forwarding capability in the MPLS-TP data
			plane. i.e. the data plane only operates on the MPLS label.
			64 MPLS-TP MUST support 1+1 protection.
	A. Bidirectional 1+1 protection for P2P connectivity MUST be		A. Bidirectional 1+1 protection for P2P connectivity MUST be
	supported.		supported.
	B. Unidirectional 1+1 protection for P2P connectivity MUST be		B. Unidirectional 1+1 protection for P2P connectivity MUST be
	supported.		supported.
	C. Unidirectional 1+1 protection for P2MP connectivity MUST be		C. Unidirectional 1+1 protection for P2MP connectivity MUST be
	supported.		supported.
	62 MPLS-TP MUST support 1:n protection (including 1:1 protection).		65 MPLS-TP MUST support the ability to share protection resources
			amongst a number of transport paths.
	A. MPLS-TP 1:n protection MUST include bidirectional protection		66 MPLS-TP MUST support 1:n protection (including 1:1 protection).
	switching for P2P connectivity, and this SHOULD be the
	default behavior for 1:n protection.		A. Bidirectional 1:n protection for P2P connectivity MUST be
			supported, and SHOULD be the default behavior for 1:n
			protection.
	B. Unidirectional 1:n protection for P2MP connectivity MUST be		B. Unidirectional 1:n protection for P2MP connectivity MUST be
	supported.		supported.
	C. Unidirectional 1:n protection for P2P connectivity is not		C. Unidirectional 1:n protection for P2P connectivity is not
	required and MAY be omitted from the MPLS-TP specifications.		required and MAY be omitted from the MPLS-TP specifications.
	D. The action of protection switching MUST NOT cause user data		D. The action of protection switching MUST NOT cause user data
	to loop. Backtracking is allowed.		to loop. Backtracking is allowed.
	Note: Support for extra traffic (as defined in [RFC4427]) is not		Note: Support for extra traffic (as defined in [RFC4427]) is not
	required in MPLS-TP and MAY be omitted from the MPLS-TP		required in MPLS-TP and MAY be omitted from the MPLS-TP
	specifications.		specifications.
	2.8.1.2. Restoration		2.8.1.2. Sharing of protection resources
	63 The restoration transport path MUST be able to share resources
	with the transport path being replaced (sometimes known as soft
	rerouting).
	64 Restoration priority MUST be supported so that an implementation
	can determine the order in which transport paths should be
	restored (to minimize service restoration time as well as to gain
	access to available spare capacity on the best paths).
	65 Preemption priority MUST be supported to allow restoration to
	displace other transport paths in the event of resource
	constraint.
	2.8.1.3. Sharing of protection resources
	66 MPLS-TP SHOULD support 1:n (including 1:1) shared mesh
	restoration.
	67 MPLS-TP MUST support the definition of shared protection groups		67 MPLS-TP SHOULD support 1:n (including 1:1) shared mesh recovery.
	to allow the coordination of protection actions resulting from
	triggers caused by events at different locations in the network.
	68 MPLS-TP MUST support sharing of protection resources such that		68 MPLS-TP MUST support sharing of protection resources such that
	protection paths that are known not to be required concurrently		protection paths that are known not to be required concurrently
	can share the same resources.		can share the same resources.
	2.8.1.4. Reversion		2.8.1.3. Reversion
	69 MPLS-TP protection mechanisms MUST support revertive and non-		69 MPLS-TP protection mechanisms MUST support revertive and non-
	revertive behavior.		revertive behavior.
	70 MPLS-TP restoration mechanisms MUST support revertive and non-		70 MPLS-TP restoration mechanisms MUST support revertive and non-
	revertive behavior.		revertive behavior.
	2.8.2. Triggers for protection, restoration, and reversion		2.8.2. Restoration
			71 The restoration transport path MUST be able to share resources
			with the transport path being replaced (sometimes known as soft
			rerouting).
			72 Restoration priority MUST be supported so that an implementation
			can determine the order in which transport paths should be
			restored (to minimize service restoration time as well as to gain
			access to available spare capacity on the best paths).
			73 Preemption priority MUST be supported to allow restoration to
			displace other transport paths in the event of resource
			constraint.
			2.8.3. Triggers for protection, restoration, and reversion
	Recovery actions may be triggered from different places as follows:		Recovery actions may be triggered from different places as follows:
	71 MPLS-TP MUST support physical layer fault indication triggers.		74 MPLS-TP MUST support physical layer fault indication triggers.
	72 MPLS-TP MUST support OAM-based triggers.		75 MPLS-TP MUST support OAM-based triggers.
	73 MPLS-TP MUST support management plane triggers (e.g., forced		76 MPLS-TP MUST support management plane triggers (e.g., forced
	switch, etc.).		switch, etc.).
	74 There MUST be a mechanism to allow administrative recovery		77 There MUST be a mechanism to allow administrative recovery
	actions to be distinguished from recovery actions initiated by		actions to be distinguished from recovery actions initiated by
	other triggers.		other triggers.
	75 Where a control plane is present, MPLS-TP SHOULD support control		78 Where a control plane is present, MPLS-TP SHOULD support control
	plane triggers.		plane restoration triggers.
	76 MPLS-TP protection mechanisms MUST support priority logic to		79 MPLS-TP protection mechanisms MUST support priority logic to
	negotiate and accommodate coexisting requests (i.e., multiple		negotiate and accommodate coexisting requests (i.e., multiple
	requests) for protection switching (e.g., administrative requests		requests) for protection switching (e.g., administrative requests
	and requests due to link/node failures).		and requests due to link/node failures).
	2.8.3. Management plane operation of protection and restoration		2.8.4. Management plane operation of protection and restoration
	All functions described here are for control by the operator.		All functions described here are for control by the operator.
	77 It MUST be possible to configure protection paths and protection-		80 It MUST be possible to configure protection paths and protection-
	to-working path relationships (sometimes known as protection		to-working path relationships (sometimes known as protection
	groups).		groups).
	78 There MUST be support for pre-calculation of recovery paths.		81 There MUST be support for pre-calculation of recovery paths.
	79 There MUST be support for pre-provisioning of recovery paths.		82 There MUST be support for pre-provisioning of recovery paths.
	80 The external controls as defined in [RFC4427] MUST be supported.		83 The external controls as defined in [RFC4427] MUST be supported.
	A. External controls overruled by higher priority requests		A. External controls overruled by higher priority requests
	(e.g., administrative requests and requests due to link/node		(e.g., administrative requests and requests due to link/node
	failures) or unable to be signaled to the remote end (e.g.		failures) or unable to be signaled to the remote end (e.g.
	because of a protection state coordination fail) MUST be		because of a protection state coordination fail) MUST be
	dropped.		dropped.
	81 There MUST be support for the configuration of timers used for		84 It MUST be possible to test and validate any protection/
	recovery operation.		restoration mechanisms and protocols:
	82 Restoration resources MAY be pre-planned and selected a priori,		A. Including the integrity of the protection/recovery transport
			path.
			B. Without triggering the actual protection/restoration.
			C. While the working path is in service.
			D. While the working path is out of service.
			85 Restoration resources MAY be pre-planned and selected a priori,
	or computed after failure occurrence.		or computed after failure occurrence.
	83 When preemption is supported for restoration purposes, it MUST be		86 When preemption is supported for restoration purposes, it MUST be
	possible for the operator to configure it.		possible for the operator to configure it.
	84 The management plane MUST provide indications of protection		87 The management plane MUST provide indications of protection
	events and triggers.		events and triggers.
	85 The management plane MUST allow the current protection status of		88 The management plane MUST allow the current protection status of
	all transport paths to be determined.		all transport paths to be determined.
	2.8.4. Control plane and in-band OAM operation of recovery		2.8.5. Control plane and in-band OAM operation of recovery
	86 The MPLS-TP control plane (which is not mandatory in an MPLS-TP		89 The MPLS-TP control plane (which is not mandatory in an MPLS-TP
	implementation) MUST be capable of supporting:		implementation) MUST be capable of supporting:
	A. establishment and maintenance of all recovery entities and		A. establishment and maintenance of all recovery entities and
	functions		functions
	B. signaling of administrative control		B. signaling of administrative control
	C. protection state coordination (PSC). Since control plane		C. protection state coordination (PSC). Since control plane
	network topology is independent from the data plane network		network topology is independent from the data plane network
	topology, the PSC supported by the MPLS-TP control plane MAY		topology, the PSC supported by the MPLS-TP control plane MAY
	run on resources different than the data plane resources		run on resources different than the data plane resources
	handled within the recovery mechanism (e.g. backup).		handled within the recovery mechanism (e.g. backup).
	87 In-band OAM MUST be capable of supporting:		90 In-band OAM MUST be capable of supporting:
	A. signaling of administrative control		A. signaling of administrative control
	B. protection state coordination (PSC). Since in-band OAM tools		B. protection state coordination (PSC). Since in-band OAM tools
	share the data plane with the carried transport service, in		share the data plane with the carried transport service, in
	order to optimize the usage of network resources, the PSC		order to optimize the usage of network resources, the PSC
	supported by in-band OAM MUST run on protection resources.		supported by in-band OAM MUST run on protection resources.
	2.8.5. Topology-specific recovery mechanisms		2.8.6. Topology-specific recovery mechanisms
	88 MPLS-TP MAY support recovery mechanisms that are optimized for		91 MPLS-TP MAY support recovery mechanisms that are optimized for
	specific network topologies. These mechanisms MUST be		specific network topologies. These mechanisms MUST be
	interoperable with the mechanisms defined for arbitrary topology		interoperable with the mechanisms defined for arbitrary topology
	(mesh) networks to enable protection of end-to-end transport		(mesh) networks to enable protection of end-to-end transport
	paths.		paths.
	2.8.5.1. Ring protection		2.8.6.1. Ring protection
	Several service providers have expressed a high level of interest in		Several service providers have expressed a high level of interest in
	operating MPLS-TP in ring topologies and require a high level of		operating MPLS-TP in ring topologies and require a high level of
	survivability function in these topologies. The requirements listed		survivability function in these topologies. The requirements listed
	below have been collected from these service providers and from the		below have been collected from these service providers and from the
	ITU-T.		ITU-T.
	The main objective in considering a specific topology (such as a		The main objective in considering a specific topology (such as a
	ring) is to determine whether it is possible to optimize any		ring) is to determine whether it is possible to optimize any
	mechanisms such that the performance of those mechanisms within the		mechanisms such that the performance of those mechanisms within the
	skipping to change at page 26, line 14		skipping to change at page 26, line 8
	e. When a control plane is supported, minimize the impact on		e. When a control plane is supported, minimize the impact on
	signaling and routing information exchange during protection -		signaling and routing information exchange during protection -
	less than are required by other recovery mechanisms.		less than are required by other recovery mechanisms.
	It may be observed that the requirements in this section are fully		It may be observed that the requirements in this section are fully
	compatible with the generic requirements expressed above, and that no		compatible with the generic requirements expressed above, and that no
	requirements that are specific to ring topologies have been		requirements that are specific to ring topologies have been
	identified.		identified.
	89 MPLS-TP MUST include recovery mechanisms that operate in any		92 MPLS-TP MUST include recovery mechanisms that operate in any
	single ring supported in MPLS-TP, and continue to operate within		single ring supported in MPLS-TP, and continue to operate within
	the single rings even when the rings are interconnected.		the single rings even when the rings are interconnected.
	90 When a network is constructed from interconnected rings, MPLS-TP		93 When a network is constructed from interconnected rings, MPLS-TP
	MUST support recovery mechanisms that protect user data that		MUST support recovery mechanisms that protect user data that
	traverses more than one ring. This includes the possibility of		traverses more than one ring. This includes the possibility of
	failure of the ring-interconnect nodes and links.		failure of the ring-interconnect nodes and links.
	91 MPLS-TP recovery in a ring MUST protect unidirectional and		94 MPLS-TP recovery in a ring MUST protect unidirectional and
	bidirectional P2P transport paths.		bidirectional P2P transport paths.
	92 MPLS-TP recovery in a ring MUST protect unidirectional P2MP		95 MPLS-TP recovery in a ring MUST protect unidirectional P2MP
	transport paths.		transport paths.
	93 MPLS-TP 1+1 and 1:1 protection in a ring MUST support switching		96 MPLS-TP 1+1 and 1:1 protection in a ring MUST support switching
	time within 50 ms from the moment of fault detection in a		time within 50 ms from the moment of fault detection in a
	network with a 16 nodes ring with less than 1200 km of fiber.		network with a 16 nodes ring with less than 1200 km of fiber.
	94 The protection switching time in a ring MUST be independent of		97 The protection switching time in a ring MUST be independent of
	the number of LSPs crossing the ring.		the number of LSPs crossing the ring.
	95 Recovery actions in a ring MUST be data plane functions		98 The configuration and operation of recovery mechanisms in a ring
	triggered by different elements of control. The triggers are
	configured by management or control planes and are subject to
	configurable policy.
	96 The configuration and operation of recovery mechanisms in a ring
	MUST scale well with:		MUST scale well with:
	A. the number of transport paths (must be better than linear		A. the number of transport paths (must be better than linear
	scaling)		scaling)
	B. the number of nodes on the ring (must be at least as good as		B. the number of nodes on the ring (must be at least as good as
	linear scaling)		linear scaling)
	C. the number of ring interconnects (must be at least as good		C. the number of ring interconnects (must be at least as good
	as linear scaling)		as linear scaling)
	97 Recovery techniques used in a ring MUST NOT prevent the ring
			99 Recovery techniques used in a ring MUST NOT prevent the ring
	from being connected to a general MPLS-TP network in any		from being connected to a general MPLS-TP network in any
	arbitrary way, and MUST NOT prevent the operation of recovery		arbitrary way, and MUST NOT prevent the operation of recovery
	techniques in the rest of the network.		techniques in the rest of the network.
	98 MPLS-TP Recovery mechanisms applicable to a ring MUST be equally		100 MPLS-TP Recovery mechanisms applicable to a ring MUST be equally
	applicable in physical and logical rings.		applicable in physical and logical rings.
	99 Recovery techniques in a ring SHOULD be identical (or as similar		101 Recovery techniques in a ring SHOULD be identical (or as similar
	as possible) to those in general transport networks to simplify		as possible) to those in general transport networks to simplify
	implementation and operations. However, this MUST NOT override		implementation and operations. However, this MUST NOT override
	any other requirement.		any other requirement.
	100 Recovery techniques in logical and physical rings SHOULD be		102 Recovery techniques in logical and physical rings SHOULD be
	identical to simplify implementation and operation. However,		identical to simplify implementation and operation. However,
	this MUST NOT override any other requirement.		this MUST NOT override any other requirement.
	101 The default recovery scheme in a ring MUST be bidirectional		103 The default recovery scheme in a ring MUST be bidirectional
	recovery in order to simplify the recovery operation.		recovery in order to simplify the recovery operation.
	102 The recovery mechanism in a ring MUST support revertive		104 The recovery mechanism in a ring MUST support revertive
	switching, which MUST be the default behavior. This allows		switching, which MUST be the default behavior. This allows
	optimization of the use of the ring resources, and restores the		optimization of the use of the ring resources, and restores the
	preferred quality conditions for normal traffic (e.g., delay)		preferred quality conditions for normal traffic (e.g., delay)
	when the recovery mechanism is no longer needed.		when the recovery mechanism is no longer needed.
	103 The recovery mechanisms in a ring MUST support ways to allow		105 The recovery mechanisms in a ring MUST support ways to allow
	administrative protection switching, to be distinguished from		administrative protection switching, to be distinguished from
	protection switching initiated by other triggers.		protection switching initiated by other triggers.
	104 It MUST be possible to lockout (disable) protection mechanisms		106 It MUST be possible to lockout (disable) protection mechanisms
	on selected links (spans) in a ring (depending on operator's		on selected links (spans) in a ring (depending on operator's
	need). This may require lockout mechanisms to be applied to		need). This may require lockout mechanisms to be applied to
	intermediate nodes within a transport path.		intermediate nodes within a transport path.
	105 MPLS-TP recovery mechanisms in a ring:		107 MPLS-TP recovery mechanisms in a ring:
	A. MUST include a mechanism to allow an implementation to		A. MUST include a mechanism to allow an implementation to
	handle (including the coordination of) coexisting requests		handle (including the coordination of) coexisting requests
	or triggers (i.e., multiple requests - not necessarily		or triggers (i.e., multiple requests - not necessarily
	arriving simultaneously and located anywhere in the ring)		arriving simultaneously and located anywhere in the ring)
	for protection switching based on priority. Note that such		for protection switching based on priority. Note that such
	coordination is the ring equivalent of the definition of		coordination is the ring equivalent of the definition of
	shared protection groups.		shared protection groups.
	B. MAY support multiple failures without reconfiguring the		B. MAY support multiple failures without reconfiguring the
	protection actions.		protection actions.
	106 MPLS-TP recovery and reversion mechanisms in a ring MUST offer a		108 MPLS-TP recovery and reversion mechanisms in a ring MUST offer a
	way to prevent frequent operation of recovery in the event of an		way to prevent frequent operation of recovery in the event of an
	intermittent defect.		intermittent defect.
	107 MPLS-TP MUST support the sharing of protection bandwidth in a		109 MPLS-TP MUST support the sharing of protection bandwidth in a
	ring by allowing best effort traffic.		ring by allowing best effort traffic.
	108 MPLS-TP MUST support sharing of ring protection resources such		110 MPLS-TP MUST support sharing of ring protection resources such
	that protection paths that are known not to be required		that protection paths that are known not to be required
	concurrently can share the same resources.		concurrently can share the same resources.
	2.9. QoS requirements		2.9. QoS requirements
	Carriers require advanced traffic management capabilities to enforce		Carriers require advanced traffic management capabilities to enforce
	and guarantee the QoS parameters of customers' SLAs.		and guarantee the QoS parameters of customers' SLAs.
	Quality of service mechanisms are REQUIRED in an MPLS-TP network to		Quality of service mechanisms are REQUIRED in an MPLS-TP network to
	ensure:		ensure:
	109 Support for differentiated services and different traffic types		111 Support for differentiated services and different traffic types
	with traffic class separation associated with different traffic.		with traffic class separation associated with different traffic.
	110 Enabling the provisioning and the guarantee of Service Level		112 Enabling the provisioning and the guarantee of Service Level
	Specifications (SLS), with support for hard and relative end-to-		Specifications (SLS), with support for hard and relative end-to-
	end bandwidth guaranteed.		end bandwidth guaranteed.
	111 Support of services, which are sensitive to jitter and delay.		113 Support of services, which are sensitive to jitter and delay.
	112 Guarantee of fair access, within a particular class, to shared		114 Guarantee of fair access, within a particular class, to shared
	resources.		resources.
	113 Guaranteed resources for in-band control and management plane		115 Guaranteed resources for in-band control and management plane
	traffic regardless of the amount of data plane traffic.		traffic regardless of the amount of data plane traffic.
	114 Carriers are provided with the capability to efficiently support		116 Carriers are provided with the capability to efficiently support
	service demands over the MPLS-TP network. This MUST include		service demands over the MPLS-TP network. This MUST include
	support for a flexible bandwidth allocation scheme.		support for a flexible bandwidth allocation scheme.
	2.10. Security requirements		2.10. Security requirements
	For a description of the security threats relevant in the context of		For a description of the security threats relevant in the context of
	MPLS and GMPLS and the defensive techniques to combat those threats		MPLS and GMPLS and the defensive techniques to combat those threats
	see the Security Framework for MPLS & GMPLS Networks		see the Security Framework for MPLS & GMPLS Networks
	[I-D.ietf-mpls-mpls-and-gmpls-security-framework].		[I-D.ietf-mpls-mpls-and-gmpls-security-framework].
	skipping to change at page 30, line 6		skipping to change at page 29, line 45
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol		[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
	Label Switching Architecture", RFC 3031, January 2001.		Label Switching Architecture", RFC 3031, January 2001.
	[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-		[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
	Edge (PWE3) Architecture", RFC 3985, March 2005.		Edge (PWE3) Architecture", RFC 3985, March 2005.
	[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and		[RFC4929] Andersson, L. and A. Farrel, "Change Process for
	Restoration) Terminology for Generalized Multi-Protocol		Multiprotocol Label Switching (MPLS) and Generalized MPLS
	Label Switching (GMPLS)", RFC 4427, March 2006.		(GMPLS) Protocols and Procedures", BCP 129, RFC 4929,
			June 2007.
	[I-D.ietf-mpls-mpls-and-gmpls-security-framework]
	Fang, L. and M. Behringer, "Security Framework for MPLS
	and GMPLS Networks",
	draft-ietf-mpls-mpls-and-gmpls-security-framework-05 (work
	in progress), November 2008.
	[I-D.ietf-pwe3-ms-pw-arch]
	Bocci, M. and S. Bryant, "Requirements for OAM in MPLS
	Transport Networks", draft-ietf-pwe3-ms-pw-arch-06 (work
	in progress), September 2008.
	[ITU.G805.2000]		[ITU.G805.2000]
	International Telecommunications Union, "Generic		International Telecommunications Union, "Generic
	functional architecture of transport networks", ITU-		functional architecture of transport networks", ITU-
	T Recommendation G.805, March 2000.		T Recommendation G.805, March 2000.
	[ITU.G8080.2006]		[ITU.G8080.2006]
	International Telecommunications Union, "Architecture for		International Telecommunications Union, "Architecture for
	the automatically switched optical network (ASON)", ITU-		the automatically switched optical network (ASON)", ITU-
	T Recommendation G.8080, June 2006.		T Recommendation G.8080, June 2006.
	skipping to change at page 31, line 6		skipping to change at page 30, line 36
	[RFC4258] Brungard, D., "Requirements for Generalized Multi-Protocol		[RFC4258] Brungard, D., "Requirements for Generalized Multi-Protocol
	Label Switching (GMPLS) Routing for the Automatically		Label Switching (GMPLS) Routing for the Automatically
	Switched Optical Network (ASON)", RFC 4258, November 2005.		Switched Optical Network (ASON)", RFC 4258, November 2005.
	[RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the		[RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the
	Interpretation of Generalized Multiprotocol Label		Interpretation of Generalized Multiprotocol Label
	Switching (GMPLS) Terminology within the Context of the		Switching (GMPLS) Terminology within the Context of the
	ITU-T's Automatically Switched Optical Network (ASON)		ITU-T's Automatically Switched Optical Network (ASON)
	Architecture", RFC 4397, February 2006.		Architecture", RFC 4397, February 2006.
			[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and
			Restoration) Terminology for Generalized Multi-Protocol
			Label Switching (GMPLS)", RFC 4427, March 2006.
			[I-D.ietf-mpls-mpls-and-gmpls-security-framework]
			Fang, L. and M. Behringer, "Security Framework for MPLS
			and GMPLS Networks",
			draft-ietf-mpls-mpls-and-gmpls-security-framework-05 (work
			in progress), November 2008.
	[I-D.ietf-mpls-tp-nm-req]		[I-D.ietf-mpls-tp-nm-req]
	Lam, H., Mansfield, S., and E. Gray, "MPLS TP Network		Lam, H., Mansfield, S., and E. Gray, "MPLS TP Network
	Management Requirements", draft-ietf-mpls-tp-nm-req-00		Management Requirements", draft-ietf-mpls-tp-nm-req-01
	(work in progress), January 2009.		(work in progress), April 2009.
			[I-D.helvoort-mpls-tp-rosetta-stone]
			van Helvoort, H., Andersson, L., and N. Sprecher, "A
			Thesaurus for the Terminology used in Multiprotocol Label
			Switching Transport Profile (MPLS-TP) drafts/RFCs and
			ITU-T's Transport Network Recommendations.",
			draft-helvoort-mpls-tp-rosetta-stone-00 (work in
			progress), March 2009.
	[I-D.ietf-mpls-tp-oam-requirements]		[I-D.ietf-mpls-tp-oam-requirements]
	Vigoureux, M., Ward, D., and M. Betts, "Requirements for		Vigoureux, M., Ward, D., and M. Betts, "Requirements for
	OAM in MPLS Transport Networks",		OAM in MPLS Transport Networks",
	draft-ietf-mpls-tp-oam-requirements-01 (work in progress),		draft-ietf-mpls-tp-oam-requirements-01 (work in progress),
	November 2008.		November 2008.
			[I-D.ietf-pwe3-ms-pw-arch]
			Bocci, M. and S. Bryant, "Requirements for OAM in MPLS
			Transport Networks", draft-ietf-pwe3-ms-pw-arch-06 (work
			in progress), September 2008.
	[ITU.Y1401.2008]		[ITU.Y1401.2008]
	International Telecommunications Union, "Principles of		International Telecommunications Union, "Principles of
	interworking", ITU-T Recommendation Y.1401, February 2008.		interworking", ITU-T Recommendation Y.1401, February 2008.
	[ITU.Y2611.2006]		[ITU.Y2611.2006]
	International Telecommunications Union, "High-level		International Telecommunications Union, "High-level
	architecture of future packet-based networks", ITU-		architecture of future packet-based networks", ITU-
	T Recommendation Y.2611, December 2006.		T Recommendation Y.2611, December 2006.
	Authors' Addresses		Authors' Addresses
End of changes. 138 change blocks.
	250 lines changed or deleted		270 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/