draft-ietf-mpls-p2mp-sig-requirement-01.txt		draft-ietf-mpls-p2mp-sig-requirement-02.txt
	Network Working Group Seisho Yasukawa (NTT)		Network Working Group Seisho Yasukawa (NTT)
	Internet Draft Editor		Internet Draft Editor
	Category: Informational		Category: Informational
	Expiration Date: August 2005 February 2005		Expiration Date: August 2005 April 2005
	Signaling Requirements for Point to Multipoint		Signaling Requirements for Point to Multipoint
	Traffic Engineered MPLS LSPs		Traffic Engineered MPLS LSPs
	<draft-ietf-mpls-p2mp-sig-requirement-01.txt>		<draft-ietf-mpls-p2mp-sig-requirement-02.txt>
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, each author represents that any
	patent or other IPR claims of which I am aware have been disclosed,		applicable patent or other IPR claims of which he or she is aware
	or will be disclosed, and any of which I become aware will be		have been or will be disclosed, and any of which he or she becomes
	disclosed, in accordance with RFC 3668.		aware will be disclosed, in accordance with Section 6 of 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		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	skipping to change at page 1, line 46		skipping to change at page 1, line 46
	This document presents a set of requirements for the establishment		This document presents a set of requirements for the establishment
	and maintenance of Point-to-Multipoint (P2MP) Traffic Engineered (TE)		and maintenance of Point-to-Multipoint (P2MP) Traffic Engineered (TE)
	Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs).		Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs).
	There is no intent to specify solution specific details nor		There is no intent to specify solution specific details nor
	application specific requirements in this document.		application specific requirements in this document.
	It is intended that the requirements presented in this document are		It is intended that the requirements presented in this document are
	not limited to the requirements of packet switched networks, but also		not limited to the requirements of packet switched networks, but also
	encompass the requirements of L2SC, TDM, lambda and port switching		encompass the requirements of Layer two Switching (L2SC), Time
	networks managed by Generalized MPLS (GMPLS) protocols. Protocol		Division Multiplexing (TDM), lambda and port switching networks
	solutions developed to meet the requirements set out in this document		managed by Generalized MPLS (GMPLS) protocols. Protocol solutions
	must attempt to be equally applicable to MPLS and GMPLS.		developed to meet the requirements set out in this document must
			attempt to be equally applicable to MPLS and GMPLS.
	Table of Contents		Table of Contents
	1. Introduction .................................................. 03		1. Introduction .................................................. 03
	1.1 Non-Objectives ............................................ 05		1.1 Non-Objectives ............................................ 05
	2. Definitions ................................................... 06		2. Definitions ................................................... 06
	2.1 Acronyms .................................................. 06		2.1 Acronyms .................................................. 06
	2.2 Terminology ............................................... 06		2.2 Terminology ............................................... 06
	2.2.1 Terminology for Partial LSPs ......................... 07		2.2.1 Terminology for Partial LSPs ......................... 07
	2.3 Conventions ............................................... 08		2.3 Conventions ............................................... 08
	skipping to change at page 2, line 40		skipping to change at page 2, line 40
	4.11 Tree Remerge ............................................. 17		4.11 Tree Remerge ............................................. 17
	4.12 Data Duplication ......................................... 18		4.12 Data Duplication ......................................... 18
	4.13 IPv4/IPv6 support ........................................ 19		4.13 IPv4/IPv6 support ........................................ 19
	4.14 P2MP MPLS Label .......................................... 19		4.14 P2MP MPLS Label .......................................... 19
	4.15 Routing advertisement of P2MP capability ................. 19		4.15 Routing advertisement of P2MP capability ................. 19
	4.16 Multi-Area/AS LSP ........................................ 19		4.16 Multi-Area/AS LSP ........................................ 19
	4.17 Multi-access LANs ........................................ 20		4.17 Multi-access LANs ........................................ 20
	4.18 P2MP MPLS OAM ............................................ 20		4.18 P2MP MPLS OAM ............................................ 20
	4.19 Scalability .............................................. 20		4.19 Scalability .............................................. 20
	4.19.1 Absolute Limits ..................................... 21		4.19.1 Absolute Limits ..................................... 21
	4.20 Backwards Compatibility .................................. 22		4.20 Backwards Compatibility .................................. 23
	4.21 GMPLS .................................................... 23		4.21 GMPLS .................................................... 23
	4.22 Requirements for Hierarchical P2MP TE LSPs ............... 24		4.22 Requirements for Hierarchical P2MP TE LSPs ............... 24
	4.23 P2MP Crankback routing ................................... 24		4.23 P2MP Crankback routing ................................... 24
	5. Security Considerations ....................................... 24		5. Security Considerations ....................................... 24
	6. Acknowledgements .............................................. 25		6. IANA Considerations ........................................... 25
	7. References .................................................... 25		7. Acknowledgements .............................................. 25
	7.1 Normative References ...................................... 25		8. References .................................................... 25
	7.2 Informational References .................................. 26		8.1 Normative References ...................................... 25
	8. Editor's Address .............................................. 27		8.2 Informational References .................................. 26
	9. Authors' Addresses ............................................ 27		9. Editor's Address .............................................. 27
	10. Intellectual Property Consideration .......................... 28		10. Authors' Addresses ........................................... 27
	11. Full Copyright Statement ..................................... 29		11. Intellectual Property Consideration .......................... 28
			12. Full Copyright Statement ..................................... 29
	1. Introduction		1. Introduction
	Existing MPLS Traffic Engineering (MPLS-TE) allows for strict QoS		Existing MPLS Traffic Engineering (MPLS-TE) allows for strict QoS
	guarantees, resources optimization, and fast failure recovery, but is		guarantees, resources optimization, and fast failure recovery, but
	limited to point-to-point (P2P) applications. Requirements have been		is limited to point-to-point (P2P) applications. Requirements have
	expressed for the provision of services over point-to-multipoint		been expressed for the provision of services over
	(P2MP) traffic engineered tunnels and this clearly motivates		point-to-multipoint (P2MP) traffic engineered tunnels and this
	enhancements of the base MPLS-TE tool box in order to support P2MP		clearly motivates enhancements of the base MPLS-TE tool box in order
	MPLS-TE LSPs.		to support P2MP MPLS-TE LSPs.
	[RFC2702] specifies requirements for traffic engineering over MPLS.		[RFC2702] specifies requirements for traffic engineering over MPLS.
	It describes traffic engineering in some detail, and those		It describes traffic engineering in some detail, and those
	definitions and objectives are equally applicable to traffic		definitions and objectives are equally applicable to traffic
	engineering in a point-to-multipoint service environment. They are		engineering in a point-to-multipoint service environment. They are
	not repeated here, but it is assumed that the reader is fully		not repeated here, but it is assumed that the reader is fully
	familiar with them.		familiar with them.
	[RFC2702] also explains how MPLS is particularly suited to traffic		[RFC2702] also explains how MPLS is particularly suited to traffic
	engineering, and presents the following eight reason.		engineering, and presents the following eight reason.
	1. Explicit label switched paths which are not constrained by		1. Explicit label switched paths which are not constrained by
	the destination based forwarding paradigm can be easily created		the destination based forwarding paradigm can be easily
	through manual administrative action or through automated		created through manual administrative action or through
	action by the underlying protocols.		automated action by the underlying protocols.
	2. LSPs can potentially be efficiently maintained.		2. LSPs can potentially be efficiently maintained.
	3. Traffic trunks can be instantiated and mapped onto LSPs.		3. Traffic trunks can be instantiated and mapped onto LSPs.
	4. A set of attributes can be associated with traffic trunks		4. A set of attributes can be associated with traffic trunks
	which modulate their behavioral characteristics.		which modulate their behavioral characteristics.
	5. A set of attributes can be associated with resources which		5. A set of attributes can be associated with resources which
	constrain the placement of LSPs and traffic trunks across		constrain the placement of LSPs and traffic trunks across
	them.		them.
	6. MPLS allows for both traffic aggregation and disaggregation		6. MPLS allows for both traffic aggregation and disaggregation
	whereas classical destination only based IP forwarding		whereas classical destination only based IP forwarding
	permits only aggregation.		permits only aggregation.
	7. It is relatively easy to integrate a "constraint-based routing"		7. It is relatively easy to integrate a "constraint-based
	framework with MPLS.		routing" framework with MPLS.
	8. A good implementation of MPLS can offer significantly lower		8. A good implementation of MPLS can offer significantly lower
	overhead than competing alternatives for Traffic Engineering.		overhead than competing alternatives for Traffic Engineering.
	These points are equally applicable to point-to-multipoint		These points are equally applicable to point-to-multipoint
	traffic engineering. Points 1. and 7. are particularly important.		traffic engineering. Points 1. and 7. are particularly important.
	That is, the traffic flow for a point-to-multipoint LSP is not		That is, the traffic flow for a point-to-multipoint LSP is not
	constrained to the path or paths that it would follow during		constrained to the path or paths that it would follow during
	multicast routing or shortest path destination-based routing, but		multicast routing or shortest path destination-based routing, but
	can be explicitly controlled through manual or automated action.		can be explicitly controlled through manual or automated action.
	Further, the explicit paths that are used may be computed using		Further, the explicit paths that are used may be computed using
	algorithms based on a variety of constraints to produce all manner of		algorithms based on a variety of constraints to produce all manner
	tree shapes. For example, an explicit path may be cost-based		of tree shapes. For example, an explicit path may be cost-based
	[STEINER], shortest path, QoS-based, or may use some fair-cost QoS		[STEINER], shortest path, QoS-based, or may use some fair-cost QoS
	algorithm.		algorithm.
	[RFC2702] also describes the functional capabilities required to		[RFC2702] also describes the functional capabilities required to
	fully support Traffic Engineering over MPLS in large networks.		fully support Traffic Engineering over MPLS in large networks.
	1. A set of attributes associated with traffic trunks which		1. A set of attributes associated with traffic trunks which
	collectively specify their behavioral characteristics.		collectively specify their behavioral characteristics.
	2. A set of attributes associated with resources which constrain		2. A set of attributes associated with resources which constrain
	skipping to change at page 4, line 33		skipping to change at page 4, line 33
	tightly integrated together.		tightly integrated together.
	These basic requirements should also be supported by P2MP traffic		These basic requirements should also be supported by P2MP traffic
	engineering.		engineering.
	This document presents a set of requirements for		This document presents a set of requirements for
	Point-to-Multipoint(P2MP) Traffic Engineering (TE) extensions to		Point-to-Multipoint(P2MP) Traffic Engineering (TE) extensions to
	Multiprotocol Label Switching (MPLS). It specifies functional		Multiprotocol Label Switching (MPLS). It specifies functional
	requirements for solutions to deliver P2MP TE LSPs.		requirements for solutions to deliver P2MP TE LSPs.
	It is intended that solutions that specify procedures for P2MP TE LSP		It is intended that solutions that specify procedures for P2MP TE
	setup satisfy these requirements. There is no intent to specify		LSP setup satisfy these requirements. There is no intent to specify
	solution specific details nor application specific requirements in		solution specific details nor application specific requirements in
	this document.		this document.
	It is intended that the requirements presented in this document are		It is intended that the requirements presented in this document are
	not limited to the requirements of packet switched networks, but		not limited to the requirements of packet switched networks, but
	also encompass the requirements of TDM, lambda and port switching		also encompass the requirements of TDM, lambda and port switching
	networks managed by Generalized MPLS (GMPLS) protocols. Protocol		networks managed by Generalized MPLS (GMPLS) protocols. Protocol
	solutions developed to meet the requirements set out in this		solutions developed to meet the requirements set out in this
	document must attempt to be equally applicable to MPLS and GMPLS.		document must attempt to be equally applicable to MPLS and GMPLS.
	Existing MPLS TE mechanisms such as [RFC3209] do not support P2MP TE		Existing MPLS TE mechanisms such as [RFC3209] do not support P2MP TE
	LSPs so new mechanisms must be developed. This should be achieved		LSPs so new mechanisms must be developed. This should be achieved
	with maximum re-use of existing MPLS protocols.		with maximum re-use of existing MPLS protocols.
	Note that there is a separation between routing and signaling in		Note that there is a separation between routing and signaling in
	MPLS TE. In particular, the path of the MPLS TE LSP is determined by		MPLS TE. In particular, the path of the MPLS TE LSP is determined by
	performing a constraint-based computation (such as CSPF) on a traffic		performing a constraint-based computation (such as CSPF) on a
	engineering database (TED). The contents of the TED may be collected		traffic engineering database (TED). The contents of the TED may be
	through a variety of mechanism - extensions to the IGPs are a		collected through a variety of mechanism - extensions to the IGPs
	popular mechanism for P2P MPLS TE.		are a popular mechanism for P2P MPLS TE.
	This document focuses on requirements for establishing and		This document focuses on requirements for establishing and
	maintaining P2MP MPLS TE LSPs through signaling protocols; and		maintaining P2MP MPLS TE LSPs through signaling protocols; and
	routing protocols are out of scope. No assumptions are made about how		routing protocols are out of scope. No assumptions are made about
	the TED used as the basis for path computations for P2MP LSPs is		how the TED used as the basis for path computations for P2MP LSPs is
	formed.		formed.
	A P2MP TE LSP will be set up with TE constraints and will allow		A P2MP TE LSP will be set up with TE constraints and will allow
	efficient packet or data replication at various branching points in		efficient packet or data replication at various branching points in
	the network. Note that the notion of "efficient" packet replication		the network. Note that the notion of "efficient" packet replication
	is relative and may have different meanings depending on the		is relative and may have different meanings depending on the
	objectives (see section 4.2).		objectives (see section 4.2).
	P2MP TE LSP setup mechanisms MUST include the ability to add/remove		P2MP TE LSP setup mechanisms MUST include the ability to add/remove
	receivers to/from an existing P2MP TE LSP.		receivers to/from an existing P2MP TE LSP.
	skipping to change at page 9, line 18		skipping to change at page 9, line 18
	Hence, to provide P2MP MPLS TE services in a fully efficient manner		Hence, to provide P2MP MPLS TE services in a fully efficient manner
	it is necessary to specify specific requirements. These requirements		it is necessary to specify specific requirements. These requirements
	can then be used to define mechanisms for the use of existing		can then be used to define mechanisms for the use of existing
	protocols and/or extensions to existing protocols and/or new		protocols and/or extensions to existing protocols and/or new
	protocols.		protocols.
	3.2. Requirements Overview		3.2. Requirements Overview
	This document states basic requirements for the setup of P2MP TE		This document states basic requirements for the setup of P2MP TE
	LSPs. The requirements apply to the signaling techniques only, and no		LSPs. The requirements apply to the signaling techniques only, and
	assumptions are made about which routing protocols are run within the		no assumptions are made about which routing protocols are run within
	network, nor about how the information that is used to construct the		the network, nor about how the information that is used to construct
	Traffic Engineering Database (TED) is distributed. These factors are		the Traffic Engineering Database (TED) is distributed. These factors
	out of the scope of this document.		are out of the scope of this document.
	A P2MP TE LSP path will be computed taking into account various		A P2MP TE LSP path will be computed taking into account various
	constraints such as bandwidth, affinities, required level of		constraints such as bandwidth, affinities, required level of
	protection and so on. The solution MUST allow for the computation		protection and so on. The solution MUST allow for the computation
	of P2MP TE LSP paths satisfying constraints with the objective of		of P2MP TE LSP paths satisfying constraints with the objective of
	supporting various optimization criteria such as delays, bandwidth		supporting various optimization criteria such as delays, bandwidth
	consumption in the network, or any other combinations. This is likely		consumption in the network, or any other combinations. This is
	to require the presence of a TED, as well as the ability to signal		likely to require the presence of a TED, as well as the ability to
	the explicit path of an LSP.		signal the explicit path of an LSP.
	A desired requirement is also to maximize the re-use of existing		A desired requirement is also to maximize the re-use of existing
	MPLS TE techniques and protocols where doing so does not adversely		MPLS TE techniques and protocols where doing so does not adversely
	impact the function, simplicity or scalability of the solution.		impact the function, simplicity or scalability of the solution.
	This document does not restrict the choice of signaling protocol		This document does not restrict the choice of signaling protocol
	used to set up a P2MP TE LSP, but it should be noted that [RFC3468]		used to set up a P2MP TE LSP, but it should be noted that [RFC3468]
	states		states
	... the consensus reached by the Multiprotocol Label Switching		... the consensus reached by the Multiprotocol Label Switching
	(MPLS) Working Group within the IETF to focus its efforts on		(MPLS) Working Group within the IETF to focus its efforts on
	skipping to change at page 12, line 22		skipping to change at page 12, line 22
	Steiner P2MP tree SPF P2MP tree		Steiner P2MP tree SPF P2MP tree
	Figure 4 Examples of P2MP TE LSP topology		Figure 4 Examples of P2MP TE LSP topology
	One example is the Steiner P2MP tree (Cost minimum P2MP tree)		One example is the Steiner P2MP tree (Cost minimum P2MP tree)
	[STEINER]. This P2MP tree is suitable for constructing a cost		[STEINER]. This P2MP tree is suitable for constructing a cost
	minimum P2MP tree so as to minimize the bandwidth consumption in		minimum P2MP tree so as to minimize the bandwidth consumption in
	the core. To realize this P2MP tree, several intermediate LSRs must		the core. To realize this P2MP tree, several intermediate LSRs must
	be both MPLS data terminating LSRs and transit LSRs (LSRs E, F, G,		be both MPLS data terminating LSRs and transit LSRs (LSRs E, F, G,
	H, I, J and K in the figure 4). This means that the LSRs must perform		H, I, J and K in the figure 4). This means that the LSRs must
	both label swapping and popping at the same time. Therefore, the P2MP		perform both label swapping and popping at the same time. Therefore,
	TE solution MUST support a mechanism that can setup this kind of bud		the P2MP TE solution MUST support a mechanism that can setup this
	LSR between an ingress LSR and egress LSRs. Note that this includes		kind of bud LSR between an ingress LSR and egress LSRs. Note that
	constrained Steiner trees that allow for the computation of a minimal		this includes constrained Steiner trees that allow for the
	cost trees with some other constraints such as a bounded delay		computation of a minimal cost trees with some other constraints such
	between the source and every receiver.		as a bounded delay between the source and every receiver.
	Another example is a CSPF (Constraint Shortest Path First) P2MP		Another example is a CSPF (Constraint Shortest Path First) P2MP
	tree. By some metric (which can be set upon any specific criteria		tree. By some metric (which can be set upon any specific criteria
	like the delay, bandwidth, a combination of those), one can		like the delay, bandwidth, a combination of those), one can
	calculate a shortest path P2MP tree. This P2MP tree is suitable for		calculate a shortest path P2MP tree. This P2MP tree is suitable for
	carrying real time traffic.		carrying real time traffic.
	The solution MUST allow the operator to make use of any tree		The solution MUST allow the operator to make use of any tree
	computation technique. In the former case an efficient/optimal tree		computation technique. In the former case an efficient/optimal tree
	is defined as a minimal cost tree (Steiner tree) whereas in the		is defined as a minimal cost tree (Steiner tree) whereas in the
	skipping to change at page 13, line 31		skipping to change at page 13, line 31
	specified at the ingress where sufficient information exists to		specified at the ingress where sufficient information exists to
	allow the full tree to be computed.		allow the full tree to be computed.
	In all cases, the egress nodes of the P2MP TE LSP must be fully		In all cases, the egress nodes of the P2MP TE LSP must be fully
	specified.		specified.
	In case of a tree being computed by some downstream LSRs (e.g. the		In case of a tree being computed by some downstream LSRs (e.g. the
	case of hops specified as loose hops), the solution MUST provide		case of hops specified as loose hops), the solution MUST provide
	the ability for the ingress LSR of the P2MP TE LSP to learn the full		the ability for the ingress LSR of the P2MP TE LSP to learn the full
	P2MP tree. Note that this requirement MAY be relaxed in some		P2MP tree. Note that this requirement MAY be relaxed in some
	environments (e.g. Inter-AS) where confidentiality must be preserved.		environments (e.g. Inter-AS) where confidentiality must be
			preserved.
	4.4 P2MP TE LSP establishment, teardown, and modification mechanisms		4.4 P2MP TE LSP establishment, teardown, and modification mechanisms
	The P2MP TE solution MUST support establishment, maintenance and		The P2MP TE solution MUST support establishment, maintenance and
	teardown of P2MP TE LSPs in a scalable manner. This MUST include		teardown of P2MP TE LSPs in a scalable manner. This MUST include
	both the existence of very many LSPs at once, and the existence of		both the existence of very many LSPs at once, and the existence of
	very many destinations for a single P2MP LSP.		very many destinations for a single P2MP LSP.
	In addition to P2MP TE LSP establishment and teardown mechanism, it		In addition to P2MP TE LSP establishment and teardown mechanism, it
	SHOULD implement partial P2MP tree modification mechanism.		SHOULD implement partial P2MP tree modification mechanism.
	skipping to change at page 16, line 37		skipping to change at page 16, line 37
	and interoperate smoothly with current P2P DS-TE protocol		and interoperate smoothly with current P2P DS-TE protocol
	specifications.		specifications.
	Note that this requirement document does not make any assumption on		Note that this requirement document does not make any assumption on
	the type of bandwidth pool used for P2MP TE LSPs which can either be		the type of bandwidth pool used for P2MP TE LSPs which can either be
	shared with P2P TE LSP or be dedicated for P2MP use.		shared with P2P TE LSP or be dedicated for P2MP use.
	4.9 Variation of LSP Parameters		4.9 Variation of LSP Parameters
	Certain parameters (such as priority and bandwidth) are associated		Certain parameters (such as priority and bandwidth) are associated
	with an LSP. The parameters are installed by the signaling exchanges		with an LSP. The parameters are installed by the signaling
	associated with establishing and maintaining the LSP		exchanges associated with establishing and maintaining the LSP.
	Any solution MUST NOT allow for variance of these parameters within		Any solution MUST NOT allow for variance of these parameters within
	a single P2MP LSP. That is:		a single P2MP LSP. That is:
	- No attributes set and signaled by the ingress of a P2MP LSP may be		- No attributes set and signaled by the ingress of a P2MP LSP may
	varied by downstream LSRs.		be varied by downstream LSRs.
	- There MUST be homogeneous QoS from the root to all leaves of a		- There MUST be homogeneous QoS from the root to all leaves of a
	single P2MP LSP.		single P2MP LSP.
	Variation of parameters may be allowed so long as it applies to the		Variation of parameters may be allowed so long as it applies to the
	whole LSP from ingress to all egresses.		whole LSP from ingress to all egresses.
	4.10 Re-optimization of P2MP TE LSPs		4.10 Re-optimization of P2MP TE LSPs
	The detection of a more optimal path (for example, one with a lower		The detection of a more optimal path (for example, one with a lower
	overall cost) is an example of a situation where P2MP TE LSP		overall cost) is an example of a situation where P2MP TE LSP
	skipping to change at page 18, line 49		skipping to change at page 18, line 49
	inefficient) situation, it may be catastrophic in certain existing		inefficient) situation, it may be catastrophic in certain existing
	and deployed applications. In a non-packet environment this means		and deployed applications. In a non-packet environment this means
	the duplication in time of some part of the signal that may lead to		the duplication in time of some part of the signal that may lead to
	the replication of data or to the scrambling of data.		the replication of data or to the scrambling of data.
	Data duplication may legitimately arise in various scenarios		Data duplication may legitimately arise in various scenarios
	including re-optimization of active LSPs as described in the		including re-optimization of active LSPs as described in the
	previous section, and protection of LSPs. Thus, it is impractical to		previous section, and protection of LSPs. Thus, it is impractical to
	regulate against data duplication in this document.		regulate against data duplication in this document.
	Instead, the solution MUST provide a mechanism to resolve, limit or		Instead, the solution:
	avoid data duplication at either or both of:		- SHOULD limit to transitory conditions only the cases where
	- the point at which the data path diverges		network bandwidth is wasted by the existence of duplicate
	- the point at which the data paths converge.		delivery paths.
			- MUST limit the cases of delivery of duplicate data to an
	THE EXTENT TO WHICH DATA DUPLICATION MAY BE TOLERATED (in time or in		application to error cases or rare transitory conditions.
	a count of bits or packets) IS FOR FURTHER STUDY.
	4.13 IPv4/IPv6 support		4.13 IPv4/IPv6 support
	Any P2MP TE solution MUST be equally applicable to IPv4 and IPv6.		Any P2MP TE solution MUST be equally applicable to IPv4 and IPv6.
	4.14 P2MP MPLS Label		4.14 P2MP MPLS Label
	A P2MP TE solution MUST support establishment of both P2P and P2MP		A P2MP TE solution MUST support establishment of both P2P and P2MP
	TE LSPs and MUST NOT impede the operation of P2P TE LSPs within the		TE LSPs and MUST NOT impede the operation of P2P TE LSPs within the
	same network. A P2MP TE solution MUST be specified in such a way		same network. A P2MP TE solution MUST be specified in such a way
	skipping to change at page 21, line 8		skipping to change at page 21, line 8
	Scalability is a key requirement in P2MP MPLS systems. Solutions		Scalability is a key requirement in P2MP MPLS systems. Solutions
	MUST be designed to scale well with an increase in the number of any		MUST be designed to scale well with an increase in the number of any
	of the following:		of the following:
	- the number of recipients		- the number of recipients
	- the number of branch points		- the number of branch points
	- the number of branches.		- the number of branches.
	Both scalability of performance and operation MUST be considered.		Both scalability of performance and operation MUST be considered.
	Key considerations SHOULD include:		Key considerations MUST include:
	- the amount of refresh processing associated with maintaining		- the amount of refresh processing associated with maintaining
	a P2MP TE LSP.		a P2MP TE LSP.
	- the amount of protocol state that must be maintained by ingress		- the amount of protocol state that must be maintained by ingress
	and transit LSRs along a P2MP tree.		and transit LSRs along a P2MP tree.
	- the number of protocol messages required to set up or tear down a		- the number of protocol messages required to set up or tear down a
	P2MP LSP as a function of the number of egress LSRs.		P2MP LSP as a function of the number of egress LSRs.
	- the number of protocol messages required to repair a P2MP LSP		- the number of protocol messages required to repair a P2MP LSP
	after failure or perform make-before-break.		after failure or perform make-before-break.
	- the amount of protocol information transmitted to manage		- the amount of protocol information transmitted to manage
	a P2MP TE LSP (i.e. the message size).		a P2MP TE LSP (i.e. the message size).
	- the amount of potential routing extensions.		- the amount of potential routing extensions.
			- the amount of additional control plane processing required in
			the network to detect whether an add/delete of a new branch is
			required, and in particular, the amount of processing in steady
			state when no add/delete is requested
	- the amount of control plane processing required by the ingress,		- the amount of control plane processing required by the ingress,
	transit and egress LSRs to add/delete a branch LSP to/from an		transit and egress LSRs to add/delete a branch LSP to/from an
	existing P2MP LSP.		existing P2MP LSP.
	It is expected that the applicability of each solution will be		It is expected that the applicability of each solution will be
	evaluated with regards to the aforementioned scalability criteria.		evaluated with regards to the aforementioned scalability criteria.
	4.19.1 Absolute Limits		4.19.1 Absolute Limits
	THIS IS SECTION DESCRIBES PROVISIONAL REQUIREMENTS STILL OPEN FOR
	DISCUSSION.
	In order to achieve the best solution for the problem space it is		In order to achieve the best solution for the problem space it is
	helpful to clarify the boundaries for P2MP TE LSPs.		helpful to clarify the boundaries for P2MP TE LSPs.
	- Number of recipients.		- Number of recipients.
	A P2MP TE LSP MUST reduce to similar scaling properties as a P2P		A P2MP TE LSP MUST reduce to similar scaling properties as a P2P
	LSP when the number of recipients reduces to one.		LSP when the number of recipients reduces to one.
	It is important to classify the problem as a Traffic Engineering		It is important to classify the problem as a Traffic Engineering
	problem. It is anticipated that the initial deployments of P2MP TE		problem. It is anticipated that the initial deployments of P2MP TE
	LSPs may be limited to only several hundred recipients, but also		LSPs will be limited to a maximum of around a hundred recipients,
	that future deployments may require significantly larger numbers.		but that medium term deployments may increase this to several
			hundred, and that future deployments may require significantly
			larger numbers.
	An acceptable solution, therefore, is one that scales linearly		An acceptable solution, therefore, is one that scales linearly
	with the number of recipients.		with the number of recipients.
	Solutions that scale worse than linear (that is, exponential or		Solutions that scale worse than linear (that is, exponential or
	polynomial) are not acceptable whatever the number of recipients		polynomial) are not acceptable whatever the number of recipients
	they could support		they could support
	- Number of branch points.		- Number of branch points.
	Solutions MUST support all possibilities from one extreme of a		Solutions MUST support all possibilities from one extreme of a
	single branch point that forks to all leaves on a separate branch,		single branch point that forks to all leaves on a separate branch,
	to the greatest number of branch points which is (n-1) for n		to the greatest number of branch points which is (n-1) for n
	recipients. Assumptions MUST NOT be made in the solution regarding		recipients. Assumptions MUST NOT be made in the solution regarding
	which topology is more common, and the solution MUST be designed		which topology is more common, and the solution MUST be designed
	to ensure scalability in all topologies.		to ensure scalability in all topologies.
	- Dynamics of P2MP tree.		- Dynamics of P2MP tree.
	Recall that the mechanisms for determining which recipients should		Recall that the mechanisms for determining which recipients should
	skipping to change at page 22, line 16		skipping to change at page 22, line 19
	which topology is more common, and the solution MUST be designed		which topology is more common, and the solution MUST be designed
	to ensure scalability in all topologies.		to ensure scalability in all topologies.
	- Dynamics of P2MP tree.		- Dynamics of P2MP tree.
	Recall that the mechanisms for determining which recipients should		Recall that the mechanisms for determining which recipients should
	be added to an LSP, and for adding and removing recipients from		be added to an LSP, and for adding and removing recipients from
	that group are out of the scope of this document. Nevertheless, it		that group are out of the scope of this document. Nevertheless, it
	is useful to understand the expected rates of arrival and		is useful to understand the expected rates of arrival and
	departure of recipients since this can impact the selection of		departure of recipients since this can impact the selection of
	solution techniques.		solution techniques.
	Again, it must be recalled that this document is limited to Traffic		Again, it must be recalled that this document is limited to
	Engineering, and in this model the rate of change of recipients		Traffic Engineering, and in this model the rate of change of
	may be expected to be lower than in an IP multicast group.		recipients may be expected to be lower than in an IP multicast
			group.
	Although the absolute number of recipients coming and going is the		Although the absolute number of recipients coming and going is the
	important element for determining the scalability of a solution,		important element for determining the scalability of a solution,
	it may be noted that a percentage may be a more comprehensible		it may be noted that a percentage may be a more comprehensible
	measure but that this is not as significant for LSPs with a small		measure but that this is not as significant for LSPs with a small
	number of recipients.		number of recipients.
	A working figure for an established P2MP TE LSP is less than 10%		A working figure for an established P2MP TE LSP is less than 10%
	churn per day. That is, a relatively slow rate of churn.		churn per day. That is, a relatively slow rate of churn.
	We could say that a P2MP LSP would be shared by multiple multicast		We could say that a P2MP LSP would be shared by multiple multicast
	groups and dynamics of P2MP LSP would be relatively small.		groups and dynamics of P2MP LSP would be relatively small.
	Considering applicability that P2MP LSP to use L2 multi-access		Considering applicability that P2MP LSP to use L2 multi-access
	skipping to change at page 23, line 39		skipping to change at page 23, line 44
	working groups.		working groups.
	Solutions for MPLS P2MP TE-LSPs when applied to GMPLS P2MP PSC or		Solutions for MPLS P2MP TE-LSPs when applied to GMPLS P2MP PSC or
	non-PSC TE-LSPs MUST be backward and forward compatible with the		non-PSC TE-LSPs MUST be backward and forward compatible with the
	other features of GMPLS including:		other features of GMPLS including:
	- control and data plane separation (IF_ID RSVP_HOP and IF_ID		- control and data plane separation (IF_ID RSVP_HOP and IF_ID
	ERROR_SPEC),		ERROR_SPEC),
	- full support of numbered and unnumbered TE links (see [RFC 3477]		- full support of numbered and unnumbered TE links (see [RFC 3477]
	and [GMPLS-ROUTE]),		and [GMPLS-ROUTE]),
	- use of the GENERALIZED_LABEL_REQUEST, the GENERALIZED_LABEL		- use of the GENERALIZED_LABEL_REQUEST, the GENERALIZED_LABEL (C-Type
	(C-Type 2 and 3), the SUGGESTED_LABEL and the RECOVERY_LABEL,		2 and 3), the SUGGESTED_LABEL and the RECOVERY_LABEL, in
	in conjunction with the LABEL_SET and the ACCEPTABLE_LABEL_SET		conjunction with the LABEL_SET and the ACCEPTABLE_LABEL_SET object,
	object,
	- processing of the ADMIN_STATUS object,		- processing of the ADMIN_STATUS object,
	- processing of the PROTECTION object,		- processing of the PROTECTION object,
	- support of Explicit Label Control,		- support of Explicit Label Control,
	- processing of the Path_State_Removed Flag,		- processing of the Path_State_Removed Flag,
	- handling of Graceful Deletion procedures.		- handling of Graceful Deletion procedures.
	- E2E and Segment Recovery procedures.		- E2E and Segment Recovery procedures.
	- support of Graceful Restart		- support of Graceful Restart.
	In addition, since non-PSC TE-LSPs may have to be processed in		In addition, since non-PSC TE-LSPs may have to be processed in
	environments where the "P2MP capability" could be limited, specific		environments where the "P2MP capability" could be limited, specific
	constraints may also apply during the P2MP TE Path computation.		constraints may also apply during the P2MP TE Path computation.
	Being technology specific, these constraints are outside the scope		Being technology specific, these constraints are outside the scope
	of this document. However, technology independent constraints		of this document. However, technology independent constraints
	(i.e. constraints that are applicable independently of the LSP		(i.e. constraints that are applicable independently of the LSP
	class) SHOULD be allowed during P2MP TE LSP message processing.		class) SHOULD be allowed during P2MP TE LSP message processing.
	It has to be emphasized that path computation and management		It has to be emphasized that path computation and management
	techniques shall be as close as possible to those being used for		techniques shall be as close as possible to those being used for
	skipping to change at page 25, line 5		skipping to change at page 25, line 5
	It should be noted that P2MP signaling mechanisms built on P2P		It should be noted that P2MP signaling mechanisms built on P2P
	RSVP-TE signaling are likely to inherit all of the security		RSVP-TE signaling are likely to inherit all of the security
	techniques and problems associated with RSVP-TE. These problems may		techniques and problems associated with RSVP-TE. These problems may
	be exacerbated in P2MP situations where security relationships may		be exacerbated in P2MP situations where security relationships may
	need to maintained between an ingress and multiple egresses. Such		need to maintained between an ingress and multiple egresses. Such
	issues are similar to security issues for IP multicast.		issues are similar to security issues for IP multicast.
	It is a requirement that documents offering solutions for P2MP LSPs		It is a requirement that documents offering solutions for P2MP LSPs
	MUST have detailed security sections.		MUST have detailed security sections.
	6. Acknowledgements		6. IANA Considerations
			This informational draft does not introduce any new encodings or code
			points. It requires no action from IANA.
			7. Acknowledgements
	The authors would like to thank George Swallow, Ichiro Inoue, Dean		The authors would like to thank George Swallow, Ichiro Inoue, Dean
	Cheng, Lou Berger and Eric Rosen for their review and suggestions.		Cheng, Lou Berger and Eric Rosen for their review and suggestions.
	Thanks to Loa Andersson for his help resolving the final issues in		Thanks to Loa Andersson for his help resolving the final issues in
	this document.		this document.
	7. References		8. References
	7.1 Normative References		8.1 Normative References
	[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.
	[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.		[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
	and W. Weiss, "An Architecture for Differentiated		and W. Weiss, "An Architecture for Differentiated
	Services", RFC 2475, December 1998.		Services", RFC 2475, December 1998.
	[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,		[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
	"Assured Forwarding PHB Group", RFC 2597, June 1999.		"Assured Forwarding PHB Group", RFC 2597, June 1999.
	skipping to change at page 26, line 5		skipping to change at page 26, line 5
	Boudec, J.Y., Davari, S., Courtney, W., Firioiu, V. and		Boudec, J.Y., Davari, S., Courtney, W., Firioiu, V. and
	D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop		D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop
	Behavior)", RFC 3246, March 2002.		Behavior)", RFC 3246, March 2002.
	[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,		[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
	RFC 3667, February 2004.		RFC 3667, February 2004.
	[RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF		[RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF
	Technology", BCP 79, RFC 3668, February 2004.		Technology", BCP 79, RFC 3668, February 2004.
	7.2 Informational References		8.2 Informational References
	[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label		[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label
	Switching (GMPLS) Signaling Functional Description",		Switching (GMPLS) Signaling Functional Description",
	RFC 3471, January 2003.		RFC 3471, January 2003.
	[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label		[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label
	Switching (GMPLS) Signaling - Resource ReserVation		Switching (GMPLS) Signaling - Resource ReserVation
	Protocol-Traffic Engineering (RSVP-TE) Extensions",		Protocol-Traffic Engineering (RSVP-TE) Extensions",
	RFC 3473, January 2003.		RFC 3473, January 2003.
	skipping to change at page 26, line 30		skipping to change at page 26, line 30
	[RFC3564] F. Le Faucheur, W. Lai, "Requirements for Support of		[RFC3564] F. Le Faucheur, W. Lai, "Requirements for Support of
	Differentiated Services-aware MPLS Traffic		Differentiated Services-aware MPLS Traffic
	Engineering", RFC 3564, July 2003.		Engineering", RFC 3564, July 2003.
	[RFC3630] D. Katz, D. Yeung, K. Kompella, "Traffic Engineering		[RFC3630] D. Katz, D. Yeung, K. Kompella, "Traffic Engineering
	Extensions to OSPF Version 2", RFC 3630, September		Extensions to OSPF Version 2", RFC 3630, September
	2003.		2003.
	[GMPLS-ROUTE] K. Kompella, Y. Rekhter, Editor, "Routing Extensions		[GMPLS-ROUTE] K. Kompella, Y. Rekhter, Editor, "Routing Extensions
	in Support of Generalized Multi-Protocol Label		in Support of Generalized Multi-Protocol Label
	Switching", draft-ietf-ccamp-gmpls-routing-09.txt,		Switching", draft-ietf-ccamp-gmpls-routing, work in
	October 2003.		progress.
	[STEINER] H. Salama, et al., "Evaluation of Multicast Routing		[STEINER] H. Salama, et al., "Evaluation of Multicast Routing
	Algorithm for Real-Time Communication on High-Speed		Algorithm for Real-Time Communication on High-Speed
	Networks," IEEE Journal on Selected Area in		Networks," IEEE Journal on Selected Area in
	Communications, pp.332-345, 1997.		Communications, pp.332-345, 1997.
	[FRR] P. Pan, G. Swallow, A. Atlas, "Fast Reroute Extensions		[FRR] P. Pan, G. Swallow, A. Atlas, "Fast Reroute Extensions
	to RSVP-TE for LSP Tunnels",		to RSVP-TE for LSP Tunnels",
	draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt,		draft-ietf-mpls-rsvp-lsp-fastreroute, work in progress.
	August 2004.
	[IS-IS-TE] Henk Smit, Tony Li, "Intermediate System to		[IS-IS-TE] Henk Smit, Tony Li, "Intermediate System to
	Intermediate System (IS-IS) Extensions for Traffic		Intermediate System (IS-IS) Extensions for Traffic
	Engineering (TE)", RFC 3784, June 2004.		Engineering (TE)", RFC 3784, June 2004.
	[CRANKBACK] A. Farrel, A. Satyanarayana, A. Iwata, N. Fujita, G.		[CRANKBACK] A. Farrel, A. Satyanarayana, A. Iwata, N. Fujita, G.
	Ash, S. Marshall, "Crankback Signaling Extensions for		Ash, S. Marshall, "Crankback Signaling Extensions for
	MPLS Signaling", draft-ietf-ccamp-crankback-03.txt,		MPLS Signaling", draft-ietf-ccamp-crankback, work in
	July 2004.		progress.
	[LSP-HIER] K. Kompella, Y. Rekhter, "LSP Hierarchy with		[LSP-HIER] K. Kompella, Y. Rekhter, "LSP Hierarchy with
	Generalized MPLS TE",		Generalized MPLS TE",
	draft-ietf-mpls-lsp-hierarchy-08.txt, September 2002.		draft-ietf-mpls-lsp-hierarchy, work in progress.
	8. Editor's Address		9. Editor's Address
	Seisho Yasukawa		Seisho Yasukawa
	NTT Corporation		NTT Corporation
	9-11, Midori-Cho 3-Chome		9-11, Midori-Cho 3-Chome
	Musashino-Shi, Tokyo 180-8585,		Musashino-Shi, Tokyo 180-8585,
	Japan		Japan
	Phone: +81 422 59 4769		Phone: +81 422 59 4769
	Email: yasukawa.seisho@lab.ntt.co.jp		Email: yasukawa.seisho@lab.ntt.co.jp
	9. Authors' Addresses		10. Authors' Addresses
	Dimitri Papadimitriou		Dimitri Papadimitriou
	Alcatel		Alcatel
	Francis Wellensplein 1,		Francis Wellensplein 1,
	B-2018 Antwerpen,		B-2018 Antwerpen,
	Belgium		Belgium
	Phone : +32 3 240 8491		Phone : +32 3 240 8491
	Email: dimitri.papadimitriou@alcatel.be		Email: dimitri.papadimitriou@alcatel.be
	JP Vasseur		JP Vasseur
	skipping to change at page 28, line 35		skipping to change at page 28, line 35
	Phone: +1 408 383 7223		Phone: +1 408 383 7223
	Email: andy.malis@tellabs.com		Email: andy.malis@tellabs.com
	Jean-Louis Le Roux		Jean-Louis Le Roux
	France Telecom		France Telecom
	2, avenue Pierre-Marzin		2, avenue Pierre-Marzin
	22307 Lannion Cedex		22307 Lannion Cedex
	France		France
	Email: jeanlouis.leroux@francetelecom.com		Email: jeanlouis.leroux@francetelecom.com
	10. Intellectual Property Consideration		11. Intellectual Property Consideration
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed		Intellectual Property Rights or other rights that might be claimed
	to pertain to the implementation or use of the technology		to pertain to the implementation or use of the technology
	described in this document or the extent to which any license		described in this document or the extent to which any license
	under such rights might or might not be available; nor does it		under such rights might or might not be available; nor does it
	represent that it has made any independent effort to identify any		represent that it has made any independent effort to identify any
	such rights. Information on the procedures with respect to rights		such rights. Information on the procedures with respect to rights
	in RFC documents can be found in BCP 78 and BCP 79.		in RFC documents can be found in BCP 78 and BCP 79.
	skipping to change at page 29, line 11		skipping to change at page 29, line 11
	of such proprietary rights by implementers or users of this		of such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository		specification can be obtained from the IETF on-line IPR repository
	at http://www.ietf.org/ipr.		at http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention		The IETF invites any interested party to bring to its attention
	any copyrights, patents or patent applications, or other		any copyrights, patents or patent applications, or other
	proprietary rights that may cover technology that may be required		proprietary rights that may cover technology that may be required
	to implement this standard. Please address the information to the		to implement this standard. Please address the information to the
	IETF at ietf-ipr@ietf.org.		IETF at ietf-ipr@ietf.org.
	11. Full Copyright Statement		12. Full Copyright Statement
	Copyright (C) The Internet Society (2005). This document is		Copyright (C) The Internet Society (2005). This document is
	subject to the rights, licenses and restrictions contained in BCP		subject to the rights, licenses and restrictions contained in BCP
	78, and except as set forth therein, the authors retain all their		78, and except as set forth therein, the authors retain all their
	rights.		rights.
	This document and the information contained herein are provided		This document and the information contained herein are provided
	on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/