< draft-ietf-mpls-rsvp-te-p2mp-06.txt		draft-ietf-mpls-rsvp-te-p2mp-07.txt >
	Network Working Group R. Aggarwal (Editor)		Network Working Group R. Aggarwal (Editor)
	Internet Draft Juniper Networks		Internet Draft Juniper Networks
	Expiration Date: January 2007		Expiration Date: July 2007
	D. Papadimitriou (Editor)		D. Papadimitriou (Editor)
	Alcatel		Alcatel
	S. Yasukawa (Editor)		S. Yasukawa (Editor)
	NTT		NTT
	July 2006		January 2007
	Extensions to RSVP-TE for Point-to-Multipoint TE LSPs		Extensions to RSVP-TE for Point-to-Multipoint TE LSPs
	draft-ietf-mpls-rsvp-te-p2mp-06.txt		draft-ietf-mpls-rsvp-te-p2mp-07.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		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
	skipping to change at page 4, line 4 ¶		skipping to change at page 4, line 4 ¶
	8.2 ResvConf Messages ..................................... 24		8.2 ResvConf Messages ..................................... 24
	9 Refresh Reduction ..................................... 25		9 Refresh Reduction ..................................... 25
	10 State Management ...................................... 25		10 State Management ...................................... 25
	10.1 Incremental State Update .............................. 25		10.1 Incremental State Update .............................. 25
	10.2 Combining Multiple Path Messages ...................... 26		10.2 Combining Multiple Path Messages ...................... 26
	11 Error Processing ...................................... 27		11 Error Processing ...................................... 27
	11.1 PathErr Messages ...................................... 27		11.1 PathErr Messages ...................................... 27
	11.2 ResvErr Messages ...................................... 28		11.2 ResvErr Messages ...................................... 28
	11.3 Branch Failure Handling ............................... 29		11.3 Branch Failure Handling ............................... 29
	12 Admin Status Change ................................... 30		12 Admin Status Change ................................... 30
	13 Label Allocation on LANs with Multiple Downstream Nodes .30		13 Label Allocation on LANs with Multiple Downstream Nodes ..30
	14 P2MP LSP and Sub-LSP Re-optimization .................. 30		14 P2MP LSP and Sub-LSP Re-optimization .................. 30
	14.1 Make-before-break ..................................... 30		14.1 Make-before-break ..................................... 30
	14.2 Sub-Group Based Re-optimization ....................... 31		14.2 Sub-Group Based Re-optimization ....................... 31
	15 Fast Reroute .......................................... 31		15 Fast Reroute .......................................... 31
	15.1 Facility Backup ....................................... 32		15.1 Facility Backup ....................................... 32
	15.1.1 Link Protection ....................................... 32		15.1.1 Link Protection ....................................... 32
	15.1.2 Node Protection ....................................... 32		15.1.2 Node Protection ....................................... 32
	15.2 one-to-one Backup ..................................... 33		15.2 one-to-one Backup ..................................... 33
	16 Support for LSRs that are not P2MP Capable ............ 34		16 Support for LSRs that are not P2MP Capable ............ 34
	17 Reduction in Control Plane Processing with LSP Hierarchy .36		17 Reduction in Control Plane Processing with LSP Hierarchy. 36
	18 P2MP LSP Remerging and Cross-Over ..................... 36		18 P2MP LSP Remerging and Cross-Over ..................... 36
	18.1 Procedures ............................................ 37		18.1 Procedures ............................................ 37
	18.1.1 Re-Merge Procedures ................................... 38		18.1.1 Re-Merge Procedures ................................... 38
	19 New and Updated Message Objects ....................... 40		19 New and Updated Message Objects ....................... 40
	19.1 SESSION Object ........................................ 40		19.1 SESSION Object ........................................ 40
	19.1.1 P2MP LSP Tunnel IPv4 SESSION Object ................... 40		19.1.1 P2MP LSP Tunnel IPv4 SESSION Object ................... 40
	19.1.2 P2MP LSP Tunnel IPv6 SESSION Object ................... 41		19.1.2 P2MP LSP Tunnel IPv6 SESSION Object ................... 41
	19.2 SENDER_TEMPLATE object ................................ 41		19.2 SENDER_TEMPLATE object ................................ 41
	19.2.1 P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object ........... 42		19.2.1 P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object ........... 42
	19.2.2 P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object ........... 42		19.2.2 P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object ........... 42
	skipping to change at page 4, line 43 ¶		skipping to change at page 4, line 43 ¶
	20 IANA Considerations ................................... 45		20 IANA Considerations ................................... 45
	20.1 New Class Numbers ..................................... 45		20.1 New Class Numbers ..................................... 45
	20.2 New Class Types ....................................... 46		20.2 New Class Types ....................................... 46
	20.3 New Error Values ...................................... 46		20.3 New Error Values ...................................... 46
	20.4 LSP Attributes Flags .................................. 47		20.4 LSP Attributes Flags .................................. 47
	21 Security Considerations ............................... 47		21 Security Considerations ............................... 47
	22 Acknowledgements ...................................... 48		22 Acknowledgements ...................................... 48
	23 References ............................................ 48		23 References ............................................ 48
	23.1 Normative References .................................. 48		23.1 Normative References .................................. 48
	23.2 Informative References ................................ 49		23.2 Informative References ................................ 49
	24 Appendix .............................................. 49		24 Appendix .............................................. 50
	24.1 Example ............................................... 50		24.1 Example ............................................... 50
	25 Author Information .................................... 51		25 Author Information .................................... 51
	25.1 Editor Information .................................... 51		25.1 Editor Information .................................... 51
	25.2 Contributor Information ............................... 52		25.2 Contributor Information ............................... 52
	26 Intellectual Property ................................. 54		26 Intellectual Property ................................. 54
	27 Full Copyright Statement .............................. 54		27 Full Copyright Statement .............................. 54
	28 Acknowledgement ....................................... 55		28 Acknowledgement ....................................... 55
	1. Conventions used in this document		1. Conventions used in this document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	skipping to change at page 18, line 17 ¶		skipping to change at page 18, line 17 ¶
	<S2L sub-LSP flow descriptor> ::= <S2L_SUB_LSP>		<S2L sub-LSP flow descriptor> ::= <S2L_SUB_LSP>
	[ <P2MP_SECONDARY_RECORD_ROUTE> ]		[ <P2MP_SECONDARY_RECORD_ROUTE> ]
	FILTER_SPEC is defined in section 19.4.		FILTER_SPEC is defined in section 19.4.
	The S2L sub-LSP flow descriptor has the same format as S2L sub-LSP		The S2L sub-LSP flow descriptor has the same format as S2L sub-LSP
	descriptor in section 4.1 with the difference that a		descriptor in section 4.1 with the difference that a
	P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP		P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP
	SECONDARY_EXPLICIT_ROUTE object. The P2MP_SECONDARY_RECORD_ROUTE		SECONDARY_EXPLICIT_ROUTE object. The P2MP_SECONDARY_RECORD_ROUTE
	objects follow the same compression mechanism as the P2MP		objects follow the same compression mechanism as the P2MP
	SECONDARY_EXPLICIT_ROUTE objects. Note that that a Resv message can		SECONDARY_EXPLICIT_ROUTE objects. Note that a Resv message can signal
	signal multiple S2L sub-LSPs that may belong to the same FILTER_SPEC		multiple S2L sub-LSPs that may belong to the same FILTER_SPEC object
	object or different FILTER_SPEC objects. The same label SHOULD be		or different FILTER_SPEC objects. The same label SHOULD be allocated
	allocated if the <Sender Address, LSP-ID> fields of the FILTER_SPEC		if the <Sender Address, LSP-ID> fields of the FILTER_SPEC object are
	object are the same.		the same.
	However different labels MUST be allocated if the <Sender Address,		However different labels MUST be allocated if the <Sender Address,
	LSP-ID> of the FILTER_SPEC object is different as that implies that		LSP-ID> of the FILTER_SPEC object is different as that implies that
	the FILTER_SPEC refers to a different P2MP LSP.		the FILTER_SPEC refers to a different P2MP LSP.
	6.2. Resv Message Processing		6.2. Resv Message Processing
	The egress LSR MUST follow normal RSVP procedures while originating a		The egress LSR MUST follow normal RSVP procedures while originating a
	Resv message. The format of Resv messages is as defined in Section		Resv message. The format of Resv messages is as defined in Section
	6.1. As usual, the Resv message carries the label allocated by the		6.1. As usual, the Resv message carries the label allocated by the
	skipping to change at page 19, line 46 ¶		skipping to change at page 19, line 46 ¶
	whenever there is a change in a Resv message for an S2L sub-LSP		whenever there is a change in a Resv message for an S2L sub-LSP
	received from one of the downstream neighbors. This can result in		received from one of the downstream neighbors. This can result in
	excessive Resv messages sent upstream, particularly when the S2L sub-		excessive Resv messages sent upstream, particularly when the S2L sub-
	LSPs are first established. In order to mitigate this situation,		LSPs are first established. In order to mitigate this situation,
	branch nodes can limit their transmission of Resv messages.		branch nodes can limit their transmission of Resv messages.
	Specifically, in the case where the only change being sent in a Resv		Specifically, in the case where the only change being sent in a Resv
	message is in one or more SRRO objects, the branch node SHOULD		message is in one or more SRRO objects, the branch node SHOULD
	transmit the Resv message only after a delay time has passed since		transmit the Resv message only after a delay time has passed since
	the transmission of the previous Resv message for the same session.		the transmission of the previous Resv message for the same session.
	This delayed Resv message SHOULD include SRROs for all branches. A		This delayed Resv message SHOULD include SRROs for all branches. A
	suggested value for the delay time is thirty seconds. Specific		suggested value for the delay time is thirty seconds, and delay times
	mechanisms for Resv message throttling and delay timer settings are		SHOULD generally be longer than 1 second. Specific mechanisms for
	implementation dependent and are outside the scope of this document.		Resv message throttling and delay timer settings are implementation
			dependent and are outside the scope of this document.
	6.3. Route Recording		6.3. Route Recording
	6.3.1. RRO Processing		6.3.1. RRO Processing
	A Resv message for a P2P LSP contains a recorded route if the ingress		A Resv message for a P2P LSP contains a recorded route if the ingress
	LSR requested route recording by including an RRO in the original		LSR requested route recording by including an RRO in the original
	Path message. The same rule is used during signaling of P2MP LSPs.		Path message. The same rule is used during signaling of P2MP LSPs.
	That is, inclusion of an RRO in the Path message used to signal one		That is, inclusion of an RRO in the Path message used to signal one
	or more S2L sub-LSPs triggers the inclusion of a recorded route for		or more S2L sub-LSPs triggers the inclusion of a recorded route for
	skipping to change at page 23, line 12 ¶		skipping to change at page 23, line 12 ¶
	object on the received Notify message, and modify their values		object on the received Notify message, and modify their values
	in the Notify message that is forwarded to match the sub-group		in the Notify message that is forwarded to match the sub-group
	field values in the original Path message received from upstream.		field values in the original Path message received from upstream.
	The receiver of an (upstream) Notify message MUST identify the state		The receiver of an (upstream) Notify message MUST identify the state
	referenced in this message based on the SESSION and SENDER_TEMPLATE.		referenced in this message based on the SESSION and SENDER_TEMPLATE.
	2. Downstream Notification		2. Downstream Notification
	A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC		A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
	object(s) of a Resv message to the value, that was received in the		object(s) of a Resv message to the value that was received in the
	corresponding Path message. If the incoming Resv message carries a		corresponding Path message. If the incoming Resv message carries a
	Notify Request object then:		Notify Request object then:
	- If there is at least another incoming Resv message that carries a		- If there is at least another incoming Resv message that carries a
	Notify Request object and the LSR merges these Resv messages into a		Notify Request object and the LSR merges these Resv messages into a
	single Resv message that is sent upstream, the LSR MUST set the		single Resv message that is sent upstream, the LSR MUST set the
	Notify node address in the Notify Request object to its Router ID.		Notify node address in the Notify Request object to its Router ID.
	- Else if the LSR sets the Sub-Group Originator ID in the outgoing		- Else if the LSR sets the Sub-Group Originator ID in the outgoing
	Path message, that corresponds to the received Resv message, to its		Path message, that corresponds to the received Resv message, to its
	skipping to change at page 24, line 22 ¶		skipping to change at page 24, line 22 ¶
	confirmation of receipt of the Resv message in P2MP TE LSPs.		confirmation of receipt of the Resv message in P2MP TE LSPs.
	Processing not detailed in this section MUST comply to [RFC2205].		Processing not detailed in this section MUST comply to [RFC2205].
	A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC		A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
	object(s) of a Resv message to the value, that was received in the		object(s) of a Resv message to the value, that was received in the
	corresponding Path message. If any of the incoming Resv messages		corresponding Path message. If any of the incoming Resv messages
	corresponding to a single Path message carry a RESV_CONFIRM object		corresponding to a single Path message carry a RESV_CONFIRM object
	then the LSR MUST include a RESV_CONFIRM object in the corresponding		then the LSR MUST include a RESV_CONFIRM object in the corresponding
	Resv message that it sends upstream. If the sub-group originator ID		Resv message that it sends upstream. If the sub-group originator ID
	is its own address then it MUST set the receiver address in the		is its own address then it MUST set the receiver address in the
	RESV_CONFIRM object to this addresse, else it MUST propagate the		RESV_CONFIRM object to this address, else it MUST propagate the
	object unchanged.		object unchanged.
	A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC		A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
	object(s) of a Resv message to the value that was received in the		object(s) of a Resv message to the value that was received in the
	corresponding Path message. If an incoming Resv message corresponding		corresponding Path message. If an incoming Resv message corresponding
	to a single Path message carries a RESV_CONFIRM object then the LSR		to a single Path message carries a RESV_CONFIRM object then the LSR
	MUST include a RESV_CONFIRM object in the corresponding Resv message		MUST include a RESV_CONFIRM object in the corresponding Resv message
	that it sends upstream and:		that it sends upstream and:
	- If there is at least another incoming Resv message that carries a		- If there is at least another incoming Resv message that carries a
	skipping to change at page 30, line 16 ¶		skipping to change at page 30, line 16 ¶
	A branch node that receives an ADMIN_STATUS object processes it		A branch node that receives an ADMIN_STATUS object processes it
	normally and also relays the ADMIN_STATUS object in a Path on every		normally and also relays the ADMIN_STATUS object in a Path on every
	branch. All Path messages may be concurrently sent to the downstream		branch. All Path messages may be concurrently sent to the downstream
	neighbors.		neighbors.
	Downstream nodes process the change in the ADMIN_STATUS object per		Downstream nodes process the change in the ADMIN_STATUS object per
	[RFC3473], including generation of Resv messages. When the last		[RFC3473], including generation of Resv messages. When the last
	received upstream ADMIN_STATUS object had the R bit set, branch nodes		received upstream ADMIN_STATUS object had the R bit set, branch nodes
	wait for a Resv message with a matching ADMIN_STATUS object to be		wait for a Resv message with a matching ADMIN_STATUS object to be
	received (or a corresponding PathErr or ResvTear messsage) on all		received (or a corresponding PathErr or ResvTear message) on all
	branches before relaying a corresponding Resv message upstream.		branches before relaying a corresponding Resv message upstream.
	13. Label Allocation on LANs with Multiple Downstream Nodes		13. Label Allocation on LANs with Multiple Downstream Nodes
	A branch LSR of a P2MP LSP on an Ethernet LAN segment SHOULD send one		A branch LSR of a P2MP LSP on an Ethernet LAN segment SHOULD send one
	copy of the data traffic per downstream LSR connected on that LAN for		copy of the data traffic per downstream LSR connected on that LAN for
	that P2MP LSP. Procedures for preventing MPLS labelled traffic		that P2MP LSP. Procedures for preventing MPLS labelled traffic
	replication in such a case is beyond the scope of this document.		replication in such a case is beyond the scope of this document.
	14. P2MP LSP and Sub-LSP Re-optimization		14. P2MP LSP and Sub-LSP Re-optimization
	skipping to change at page 34, line 4 ¶		skipping to change at page 34, line 4 ¶
	particular S2L sub-LSP against link and next-hop failure. Protection		particular S2L sub-LSP against link and next-hop failure. Protection
	may be used for one or more S2L sub-LSPs between the PLR and the		may be used for one or more S2L sub-LSPs between the PLR and the
	next-hop. All the S2L sub-LSPs corresponding to the same instance of		next-hop. All the S2L sub-LSPs corresponding to the same instance of
	the P2MP tunnel, between the PLR and the next-hop SHOULD share the		the P2MP tunnel, between the PLR and the next-hop SHOULD share the
	same P2MP LSP label as per section 5.2.1. All such S2L sub-LSPs		same P2MP LSP label as per section 5.2.1. All such S2L sub-LSPs
	belonging to a P2MP LSP MUST be protected.		belonging to a P2MP LSP MUST be protected.
	The backup S2L sub-LSPs may traverse different next-hops at the PLR.		The backup S2L sub-LSPs may traverse different next-hops at the PLR.
	Thus the set of outgoing labels and next-hops for a P2MP LSP that was		Thus the set of outgoing labels and next-hops for a P2MP LSP that was
	using a single next-hop and label between the PLR and next-hop before		using a single next-hop and label between the PLR and next-hop before
	protection, may change once protection is triggerred. This MAY		protection, may change once protection is triggered. This MAY require
	require a PLR to be branch capable in the data plane. If the PLR is		a PLR to be branch capable in the data plane. If the PLR is not
	not branch capable, the one-to-one backup mechanisms described here		branch capable, the one-to-one backup mechanisms described here are
	are only applicable to those cases where all the backup S2L sub-LSPs		only applicable to those cases where all the backup S2L sub-LSPs pass
	pass through the same next-hop downstream of the PLR. Procedures for		through the same next-hop downstream of the PLR. Procedures for o
	one-to-one backup when a PLR is not branch capable and all the backup		one-to-one backup when a PLR is not branch capable and all the backup
	S2L sub-LSPs do not pass through the same downstream next-hop are for		S2L sub-LSPs do not pass through the same downstream next-hop are for
	further study.		further study.
	It is recommended that the path specific method be used to identify a		It is recommended that the path specific method be used to identify a
	backup S2L sub-LSP. Hence the DETOUR object SHOULD be inserted in the		backup S2L sub-LSP. Hence the DETOUR object SHOULD be inserted in the
	backup Path message. A backup S2L sub-LSP MUST be treated as		backup Path message. A backup S2L sub-LSP MUST be treated as
	belonging to a different P2MP tunnel instance than the one specified		belonging to a different P2MP tunnel instance than the one specified
	by the LSP-id. Furthermore multiple backup S2L sub-LSPs MUST be		by the LSP-id. Furthermore multiple backup S2L sub-LSPs MUST be
	treated as part of the same P2MP tunnel instance if they have the		treated as part of the same P2MP tunnel instance if they have the
	skipping to change at page 35, line 30 ¶		skipping to change at page 35, line 30 ¶
	and [RFC4206].		and [RFC4206].
	It may be an overhead for an operator to configure the P2P LSP		It may be an overhead for an operator to configure the P2P LSP
	segments in advance, when it is desired to support legacy LSRs. It		segments in advance, when it is desired to support legacy LSRs. It
	may be desirable to do this dynamically. The ingress can use IGP		may be desirable to do this dynamically. The ingress can use IGP
	extensions to determine P2MP capable LSRs [TE-NODE-CAP]. It can use		extensions to determine P2MP capable LSRs [TE-NODE-CAP]. It can use
	this information to compute S2L sub-LSP paths such that they avoid		this information to compute S2L sub-LSP paths such that they avoid
	legacy non-P2MP capable LSRs. The explicit route object of an S2L		legacy non-P2MP capable LSRs. The explicit route object of an S2L
	sub-LSP path may contain loose hops if there are legacy LSRs along		sub-LSP path may contain loose hops if there are legacy LSRs along
	the path. The corresponding explicit route contains a list of objects		the path. The corresponding explicit route contains a list of objects
	upto the P2MP capable LSR that is adjacent to a legacy LSR followed		up to the P2MP capable LSR that is adjacent to a legacy LSR followed
	by a loose object with the address of the next P2MP capable LSR. The		by a loose object with the address of the next P2MP capable LSR. The
	P2MP capable LSR expands the loose hop using its TED. When doing this		P2MP capable LSR expands the loose hop using its TED. When doing this
	it determines that the loose hop expansion requires a P2P LSP to		it determines that the loose hop expansion requires a P2P LSP to
	tunnel through the legacy LSR. If such a P2P LSP exists, it uses that		tunnel through the legacy LSR. If such a P2P LSP exists, it uses that
	P2P LSP. Else it establishes the P2P LSP. The P2MP Path message is		P2P LSP. Else it establishes the P2P LSP. The P2MP Path message is
	sent to the next P2MP capable LSR using non-adjacent signaling.		sent to the next P2MP capable LSR using non-adjacent signaling.
	The P2MP capable LSR that initiates the non-adjacent signaling		The P2MP capable LSR that initiates the non-adjacent signaling
	message to the next P2MP capable LSR may have to employ a fast		message to the next P2MP capable LSR may have to employ a fast
	detection mechanism such as [BFD] [BFD-MPLS] to the next P2MP capable		detection mechanism such as [BFD] [BFD-MPLS] to the next P2MP capable
	skipping to change at page 38, line 19 ¶		skipping to change at page 38, line 19 ¶
	allows the re-merge case to persist but data from all but one		allows the re-merge case to persist but data from all but one
	incoming interface is dropped at the re-merge node. In the second,		incoming interface is dropped at the re-merge node. In the second,
	the re-merge node initiates the removal of the re-merge branch(es)		the re-merge node initiates the removal of the re-merge branch(es)
	via signaling. Which approach is used is a matter of local policy. A		via signaling. Which approach is used is a matter of local policy. A
	node MUST support both approaches and MUST allow user configuration		node MUST support both approaches and MUST allow user configuration
	of which approach is to be used.		of which approach is to be used.
	When configured to allow a re-merge case to persist, the re-merge		When configured to allow a re-merge case to persist, the re-merge
	node MUST validate consistency between the objects included in the		node MUST validate consistency between the objects included in the
	received Path message and the matching P2MP LSP Path state. Any		received Path message and the matching P2MP LSP Path state. Any
	inconsistencies MUST result in an PathErr message sent to the		inconsistencies MUST result in a PathErr message sent to the previous
	previous hop of the received Path message. The Error Code is set to		hop of the received Path message. The Error Code is set to "Routing
	"Routing Problem" and the Error Value is set to "P2MP Re-Merge		Problem" and the Error Value is set to "P2MP Re-Merge Parameter
	Parameter Mistmatch".		Mismatch".
	If there are no inconsistencies, the node logically merges, from the		If there are no inconsistencies, the node logically merges, from the
	downstream perspective, the control state of incoming Path message		downstream perspective, the control state of incoming Path message
	with the matching P2MP LSP Path state. Specifically, procedures		with the matching P2MP LSP Path state. Specifically, procedures
	related to processing of messages received from upstream MUST NOT be		related to processing of messages received from upstream MUST NOT be
	modified from the upstream perspective; this includes refresh and		modified from the upstream perspective; this includes refresh and
	state timeout related processing. In addition to the standard		state timeout related processing. In addition to the standard
	upstream related procedures, the node MUST ensure that each object		upstream related procedures, the node MUST ensure that each object
	received from upstream is appropriately represented within the set of		received from upstream is appropriately represented within the set of
	Path messages sent downstream. For example, the received <S2L sub-LSP		Path messages sent downstream. For example, the received <S2L sub-LSP
	skipping to change at page 46, line 27 ¶		skipping to change at page 46, line 27 ¶
	C-Type		C-Type
	12 P2MP_LSP_IPv4 C-Type		12 P2MP_LSP_IPv4 C-Type
	13 P2MP_LSP_IPv6 C-Type		13 P2MP_LSP_IPv6 C-Type
	Class Name = FILTER_SPEC		Class Name = FILTER_SPEC
	C-Type		C-Type
	12 P2MP LSP_IPv4 C-Type		12 P2MP LSP_IPv4 C-Type
	13 P2MP LSP_IPv6 C-Type		13 P2MP LSP_IPv6 C-Type
	Class Name = SECONDARY_EXPLICIT_ROUTE		Class Name = SECONDARY_EXPLICIT_ROUTE (Defined in [RECOVERY])
	C-Type		C-Type
	2 P2MP SECONDARY_EXPLICIT_ROUTE C-Type		2 P2MP SECONDARY_EXPLICIT_ROUTE C-Type
	Class Name = SECONDARY_RECORD_ROUTE		Class Name = SECONDARY_RECORD_ROUTE (Defined in [RECOVERY])
	C-Type		C-Type
	2 P2MP_SECONDARY_RECORD_ROUTE C-Type		2 P2MP_SECONDARY_RECORD_ROUTE C-Type
	20.3. New Error Values		20.3. New Error Values
	Four new Error Values are defined for use with the Error Code		Four new Error Values are defined for use with the Error Code
	"Routing Problem". IANA is requested to assign values.		"Routing Problem". IANA is requested to assign values.
	The Error Value "Unable to Branch" indicates that a P2MP branch		The Error Value "Unable to Branch" indicates that a P2MP branch
	skipping to change at page 47, line 14 ¶		skipping to change at page 47, line 14 ¶
	Value.		Value.
	The Error Value "P2MP Re-Merge Parameter Mismatch" is described in		The Error Value "P2MP Re-Merge Parameter Mismatch" is described in
	section 18. IANA is requested to assign value 26 to this Error Value.		section 18. IANA is requested to assign value 26 to this Error Value.
	The Error Value "ERO Resulted in Remerge" is described in section 18.		The Error Value "ERO Resulted in Remerge" is described in section 18.
	IANA is requested to assign value 27 to this Error Value.		IANA is requested to assign value 27 to this Error Value.
	20.4. LSP Attributes Flags		20.4. LSP Attributes Flags
	IANA has been asked to manage the space of flags in the Attibutes		IANA has been asked to manage the space of flags in the Attributes
	Flags TLV carried in the LSP_REQUIRED_ATTRIBUTES Object [RFC4420].		Flags TLV carried in the LSP_REQUIRED_ATTRIBUTES Object [RFC4420].
	This document defines a new flag as follows:		This document defines a new flag as follows:
	Suggested Bit Number: 3		Suggested Bit Number: 3
	Meaning: LSP Integrity Required		Meaning: LSP Integrity Required
	Used in Attributes Flags on Path: Yes		Used in Attributes Flags on Path: Yes
	Used in Attributes Flags on Resv: No		Used in Attributes Flags on Resv: No
	Used in Attributes Flags on RRO: No		Used in Attributes Flags on RRO: No
	Referenced Section of this Doc: 5.2.4		Referenced Section of this Doc: 5.2.4
	skipping to change at page 47, line 44 ¶		skipping to change at page 47, line 44 ¶
	specified in this document, particularly in sections 16 and 17.		specified in this document, particularly in sections 16 and 17.
	An administration may wish to limit the domain over which P2MP TE		An administration may wish to limit the domain over which P2MP TE
	tunnels can be established. This can be accomplished by setting		tunnels can be established. This can be accomplished by setting
	filters on various ports to deny action on a RSVP path message with a		filters on various ports to deny action on a RSVP path message with a
	SESSION object of type P2MP_LSP_IPv4 or P2MP_LSP_IPv6.		SESSION object of type P2MP_LSP_IPv4 or P2MP_LSP_IPv6.
	The ingress LSR of a P2MP TE LSP, determines the leaves of the P2MP		The ingress LSR of a P2MP TE LSP, determines the leaves of the P2MP
	TE LSP based on the application of the P2MP TE LSP. The specification		TE LSP based on the application of the P2MP TE LSP. The specification
	of how such applications will use a P2MP TE LSP is outside the scope		of how such applications will use a P2MP TE LSP is outside the scope
	of this document. However these applications SHOULD provide		of this document. Applications MUST provide a mechanism to notify the
	mechanisms to ensure that unauthorized leaves are not added to the		ingress LSR of the appropriate leaves for the P2MP LSP.
	P2MP TE LSP.		Specifications of applications within the IETF MUST specify this
			mechanism in sufficient detail that an ingress LSR from one vendor
			can be used with an application implementation provided by another
			vendor. Manual configuration of security parameters when other
			parameters are auto-discovered is generally not sufficient to meet
			security and interoperability requirements of IETF specifications.
	22. Acknowledgements		22. Acknowledgements
	This document is the product of many people. The contributors are		This document is the product of many people. The contributors are
	listed in Section 27.2.		listed in Section 27.2.
	Thanks to Yakov Rekhter, Der-Hwa Gan, Arthi Ayyanger and Nischal		Thanks to Yakov Rekhter, Der-Hwa Gan, Arthi Ayyanger and Nischal
	Sheth for their suggestions and comments. Thanks also to Dino		Sheth for their suggestions and comments. Thanks also to Dino
	Farninacci and Benjamin Niven for their comments.		Farninacci and Benjamin Niven for their comments.
	23. References		23. References
	23.1. Normative References		23.1. Normative References
	[RFC4206] K. Kompella, Y. Rekhter, "LSP Hierarchy with Generalized		[RFC4206] K. Kompella, Y. Rekhter, "LSP Hierarchy with Generalized
	MPLS TE" [RFC4206]		MPLS TE" [RFC4206]
	[RFC4420] A. Farrel, et. al. , "Encoding of		[RFC4420] A. Farrel, et al. , "Encoding of
	Attributes for Multiprotocol Label Switching (MPLS)		Attributes for Multiprotocol Label Switching (MPLS)
	Label Switched Path (LSP) Establishment Using RSVP-TE",		Label Switched Path (LSP) Establishment Using RSVP-TE",
	RFC 4420, February 2006.		RFC 4420, February 2006.
	[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan,		[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan,
	G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",		G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
	RFC3209, December 2001, work in progress.		RFC3209, December 2001, work in progress.
	[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, work in		Requirement Levels", BCP 14, RFC 2119, March 1997, work in
	skipping to change at page 48, line 43 ¶		skipping to change at page 48, line 47 ¶
	[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and		[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and
	S. Jamin, "Resource ReSerVation Protocol (RSVP)		S. Jamin, "Resource ReSerVation Protocol (RSVP)
	-- Version 1, Functional Specification", RFC 2205,		-- Version 1, Functional Specification", RFC 2205,
	September 1997, work in progress.		September 1997, work in progress.
	[RFC3471] Lou Berger, et al., "Generalized MPLS - Signaling		[RFC3471] Lou Berger, et al., "Generalized MPLS - Signaling
	Functional Description", RFC 3471, January 2003, work in		Functional Description", RFC 3471, January 2003, work in
	progress.		progress.
	[RFC3473] L. Berger et.al., "Generalized MPLS Signaling - RSVP-TE		[RFC3473] L. Berger et al., "Generalized MPLS Signaling - RSVP-TE
	Extensions", RFC 3473, January 2003, work in progress.		Extensions", RFC 3473, January 2003, work in progress.
	[RFC2961] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi,		[RFC2961] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi,
	S. Molendini, "RSVP Refresh Overhead Reduction		S. Molendini, "RSVP Refresh Overhead Reduction
	Extensons", RFC 2961, April 2001, work in progress.		Extensions", RFC 2961, April 2001, work in progress.
	[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,
	work in progress.		work in progress.
	[RFC4090] P. Pan, G. Swallow, A. Atlas (Editors), "Fast Reroute		[RFC4090] P. Pan, G. Swallow, A. Atlas (Editors), "Fast Reroute
	Extensions to RSVP-TE for LSP Tunnels", work in progress.		Extensions to RSVP-TE for LSP Tunnels", work in progress.
	[RFC3477] K. Kompella, Y. Rekther, "Signalling Unnumbered Links in		[RFC3477] K. Kompella, Y. Rekther, "Signalling Unnumbered Links in
	Resource ReSerVation Protocol - Traffic Engineering		Resource ReSerVation Protocol - Traffic Engineering
	(RSVP-TE)", work in progress.		(RSVP-TE)", work in progress.
	[RFC4461] S. Yasukawa, Editor "Signaling Requirements for
	Point-to-Multipoint Traffic Engineered MPLS LSPs", RFC4461.
	[RECOVERY] "GMPLS Based Segment Recovery",		[RECOVERY] "GMPLS Based Segment Recovery",
	draft-ietf-ccamp-gmpls-segment-recovery-02.txt		draft-ietf-ccamp-gmpls-segment-recovery-03.txt
	23.2. Informative References		23.2. Informative References
			[RFC4461] S. Yasukawa, Editor "Signaling Requirements for
			Point-to-Multipoint Traffic Engineered MPLS LSPs", RFC4461.
	[BFD] D. Katz, D. Ward, "Bidirectional Forwarding Detection",		[BFD] D. Katz, D. Ward, "Bidirectional Forwarding Detection",
	draft-ietf-bfd-base-05.txt, work in progress.		draft-ietf-bfd-base-05.txt, work in progress.
	[BFD-MPLS] R. Aggarwal, K. Kompella, T. Nadeau, G. Swallow, "BFD for		[BFD-MPLS] R. Aggarwal, K. Kompella, T. Nadeau, G. Swallow, "BFD for
	MPLS LSPs", draft-ietf-bfd-mpls-02.txt, work in progress.		MPLS LSPs", draft-ietf-bfd-mpls-02.txt, work in progress.
	[LSP-STITCH] A. Ayyanger, J.P. Vasseur, "Label Switched Path		[LSP-STITCH] A. Ayyanger, J.P. Vasseur, "Label Switched Path
	Stitching with Generalized MPLS Traffic Engineering",		Stitching with Generalized MPLS Traffic Engineering",
	draft-ietf-ccamp-lsp-stitching-03.txt, March 2006		draft-ietf-ccamp-lsp-stitching-03.txt, March 2006
	work in progress		work in progress
	skipping to change at page 54, line 42 ¶		skipping to change at page 54, line 42 ¶
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at ietf-		this standard. Please address the information to the IETF at ietf-
	ipr@ietf.org.		ipr@ietf.org.
	27. Full Copyright Statement		27. Full Copyright Statement
	Copyright (C) The Internet Society (2006). This document is subject		Copyright (C) The Internet Society (2007). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
End of changes. 25 change blocks.
	41 lines changed or deleted		47 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/