draft-ietf-ccamp-attribute-bnf-02.txt		rfc6510.txt
	Internet Draft Lou Berger (LabN)
	Updates: 4875, 5420
	Category: Standards Track George Swallow (Cisco)
	Expiration Date: February 19, 2012
	August 19, 2011
	LSP Attributes Related Routing Backus-Naur Form		Internet Engineering Task Force (IETF) L. Berger
			Request for Comments: 6510 LabN
			Updates: 4875, 5420 G. Swallow
			Category: Standards Track Cisco
			ISSN: 2070-1721 February 2012
	draft-ietf-ccamp-attribute-bnf-02.txt		Resource Reservation Protocol (RSVP) Message Formats for
			Label Switched Path (LSP) Attributes Objects
	Abstract		Abstract
	Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)		Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
	established using the Resource Reservation Protocol Traffic		established using the Resource Reservation Protocol Traffic
	Engineering (RSVP-TE) extensions may be signaled with a set of LSP		Engineering (RSVP-TE) extensions may be signaled with a set of LSP-
	specific attributes. These attributes may be carried in both Path		specific attributes. These attributes may be carried in both Path
	and Resv messages. This document specifies how LSP attribute are		and Resv messages. This document specifies how LSP attributes are to
	to be carried in RSVP Path and Resv messages using the Routing		be carried in RSVP Path and Resv messages using the Routing Backus-
	Backus-Naur Form, and clarifies related Resv message formats.		Naur Form and clarifies related Resv message formats. This document
	This document updates RFC 4875 and RFC 5420.		updates RFC 4875 and RFC 5420.
	Status of this Memo
	This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Status of This Memo
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		This is an Internet Standards Track document.
	http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at		This document is a product of the Internet Engineering Task Force
	http://www.ietf.org/shadow.html		(IETF). It represents the consensus of the IETF community. It has
			received public review and has been approved for publication by the
			Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 5741.
	This Internet-Draft will expire on February 19, 2012		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc6510.
	Copyright and License Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1 Introduction ........................................... 2		1. Introduction ....................................................2
	1.1 Conventions Used In This Document ...................... 3		1.1. Conventions Used in This Document ..........................3
	2 Path Messages .......................................... 3		2. Path Messages ...................................................3
	2.1 Path Message Format .................................... 4		2.1. Path Message Format ........................................3
	3 Resv Messages .......................................... 4		3. Resv Messages ...................................................4
	3.1 Resv Message Format -- Per LSP Operational Status ...... 5		3.1. Resv Message Format -- Per LSP Operational Status ..........5
	3.2 Resv Message Format -- Per S2L Operational Status ...... 6		3.2. Resv Message Format -- Per S2L Operational Status ..........6
	3.2.1 Compatibility .......................................... 6		3.2.1. Compatibility .......................................6
	4 Security Considerations ................................ 7		4. Security Considerations .........................................6
	5 IANA Considerations .................................... 7		5. Acknowledgments .................................................7
	6 Acknowledgments ........................................ 7		6. References ......................................................7
	7 References ............................................. 7		6.1. Normative References .......................................7
	7.1 Normative References ................................... 7		6.2. Informative References .....................................7
	7.2 Informative References ................................. 8
	8 Authors' Addresses ..................................... 8
	1. Introduction		1. Introduction
	Signaling in support of Multiprotocol Label Switching (MPLS) and		Signaling in support of Multiprotocol Label Switching (MPLS) and
	Generalized MPLS (GMPLS) point-to-point Label Switched Paths (LSPs)		Generalized MPLS (GMPLS) point-to-point Label Switched Paths (LSPs)
	is defined in [RFC3209] and [RFC3473]. [RFC4875] defines signaling		is defined in [RFC3209] and [RFC3473]. [RFC4875] defines signaling
	support for point-to-multipoint (P2MP) TE LSPs.		support for point-to-multipoint (P2MP) Traffic Engineering (TE) LSPs.
	Two LSP Attributes related objects are defined in [RFC5420]. These		Two LSP Attributes objects are defined in [RFC5420]. These objects
	objects may be used to provide additional information related to how		may be used to provide additional information related to how an LSP
	an LSP should be setup when carried in a Path message and, when		should be set up when carried in a Path message and, when carried in
	carried in a Resv message, how an LSP has been established. The		a Resv message, how an LSP has been established. The definition of
	definition of the objects includes a narrative description of related		the objects includes a narrative description of related message
	message formats, see Section 9 of [RFC5420]. This definition does		formats (see Section 9 of [RFC5420]). This definition does not
	not provide the related Routing Backus-Naur Form (BNF), [RFC5511],		provide the related Routing Backus-Naur Form (BNF) [RFC5511] that is
	that is typically used to define how messages are to be constructed		typically used to define how messages are to be constructed using
	using RSVP objects. The current message format description has led		RSVP objects. The current message format description has led to the
	to an issue in how the LSP Attributes related objects are to be		open question of how the LSP Attributes objects are to be processed
	processed in Resv messages of P2MP LSPs.		in Resv messages of P2MP LSPs (which are defined in [RFC4875]).
	This document provides the BNF for Path and Resv messages carrying		This document provides the BNF for Path and Resv messages carrying
	the LSP Attributes related object. The definition clarifies how the		the LSP Attributes object. The definition clarifies how the objects
	objects are to be carried for all LSP types. Both Path and Resv		are to be carried for all LSP types. Both Path and Resv message BNF
	message BNF is provided for completeness.		is provided for completeness.
	This document presents the RSVP message related formats as modified		This document presents the related RSVP message formats as modified
	by [RFC5420]. This document modifies formats defined in [RFC3209],		by [RFC5420]. This document modifies formats defined in [RFC3209],
	[RFC3473] and [RFC4875]. See [RFC5511] for the syntax used by RSVP.		[RFC3473], and [RFC4875]. See [RFC5511] for the syntax used by RSVP.
	Unmodified formats are not listed. An example of a case where the		Unmodified formats are not listed. An example of a case where the
	modified formats are applicable is described in [NO-PHP-OOB].		modified formats are applicable is described in [RFC6511].
	1.1. Conventions Used In This Document		1.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",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Path Messages		2. Path Messages
	This section updates [RFC4875]. Path message formatting is		This section updates [RFC4875]. Path message formatting is
	unmodified from the narrative description provided in Section 9 of		unmodified from the narrative description provided in Section 9 of
	[RFC5420]. As stated in [RFC5420]:		[RFC5420]:
	The LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object		The LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object
	MAY be carried in a Path message.		MAY be carried in a Path message....
	The order of objects in RSVP-TE messages is recommended, but		The order of objects in RSVP-TE messages is recommended, but
	implementations must be capable of receiving the objects in any		implementations must be capable of receiving the objects in any
	meaningful order.		meaningful order.
	On a Path message, the LSP_ATTRIBUTES object and		On a Path message, the LSP_ATTRIBUTES object and
	LSP_REQUIRED_ATTRIBUTES objects are RECOMMENDED to be placed		LSP_REQUIRED_ATTRIBUTES objects are RECOMMENDED to be placed
	immediately after the SESSION_ATTRIBUTE object if it is present,		immediately after the SESSION_ATTRIBUTE object if it is present,
	or otherwise immediately after the LABEL_REQUEST object.		or otherwise immediately after the LABEL_REQUEST object.
	If both the LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES		If both the LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES
	object are present, the LSP_REQUIRED_ATTRIBUTES object is		object are present, the LSP_REQUIRED_ATTRIBUTES object is
	RECOMMENDED to be placed first.		RECOMMENDED to be placed first.
	LSRs MUST be prepared to receive these objects in any order in any		LSRs MUST be prepared to receive these objects in any order in any
	position within a Path message. Subsequent instances of these		position within a Path message. Subsequent instances of these
	objects within a Path message SHOULD be ignored and MUST be		objects within a Path message SHOULD be ignored and MUST be
	forwarded unchanged.		forwarded unchanged.
	2.1. Path Message Format		2.1. Path Message Format
	This section presents the Path message format as modified by		This section presents the Path message format as modified by
	[RFC5420]. Unmodified formats are not listed.		[RFC5420]. Unmodified formats are not listed.
	<Path Message> ::= <Common Header> [ <INTEGRITY> ]		<Path Message> ::= <Common Header> [ <INTEGRITY> ]
	[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]		[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]
	[ <MESSAGE_ID> ]		[ <MESSAGE_ID> ]
	<SESSION> <RSVP_HOP>		<SESSION> <RSVP_HOP>
	<TIME_VALUES>		<TIME_VALUES>
	[ <EXPLICIT_ROUTE> ]		[ <EXPLICIT_ROUTE> ]
	skipping to change at page 4, line 29		skipping to change at page 4, line 19
	[ <SESSION_ATTRIBUTE> ]		[ <SESSION_ATTRIBUTE> ]
	[ <LSP_REQUIRED_ATTRIBUTES> ... ]		[ <LSP_REQUIRED_ATTRIBUTES> ... ]
	[ <LSP_ATTRIBUTES> ... ]		[ <LSP_ATTRIBUTES> ... ]
	[ <NOTIFY_REQUEST> ]		[ <NOTIFY_REQUEST> ]
	[ <ADMIN_STATUS> ]		[ <ADMIN_STATUS> ]
	[ <POLICY_DATA> ... ]		[ <POLICY_DATA> ... ]
	<sender descriptor>		<sender descriptor>
	[<S2L sub-LSP descriptor list>]		[<S2L sub-LSP descriptor list>]
	Note that PathErr and PathTear messages are not impacted by the		Note that PathErr and PathTear messages are not impacted by the
	introduction of the LSP attributed related objects.		introduction of the LSP Attributes objects.
	3. Resv Messages		3. Resv Messages
	This section updates [RFC4875] and [RFC5420]. Section 9 of [RFC5420]		This section updates [RFC4875] and [RFC5420]. Section 9 of [RFC5420]
	contains the following Resv message related text:		contains the following text regarding Resv messages:
	The LSP_ATTRIBUTES object MAY be carried in a Resv message.		The LSP_ATTRIBUTES object MAY be carried in a Resv message.
	The order of objects in RSVP-TE messages is recommended, but		The order of objects in RSVP-TE messages is recommended, but
	implementations must be capable of receiving the objects in any		implementations must be capable of receiving the objects in any
	meaningful order.		meaningful order.
			...
	On a Resv message, the LSP_ATTRIBUTES object is placed in the flow		On a Resv message, the LSP_ATTRIBUTES object is placed in the flow
	descriptor and is associated with the FILTER_SPEC object that		descriptor and is associated with the FILTER_SPEC object that
	precedes it. It is RECOMMENDED that the LSP_ATTRIBUTES object be		precedes it. It is RECOMMENDED that the LSP_ATTRIBUTES object be
	placed immediately after the LABEL object.		placed immediately after the LABEL object.
	LSRs MUST be prepared to receive this object in any order in any		LSRs MUST be prepared to receive this object in any order in any
	position within a Resv message, subject to the previous note.		position within a Resv message, subject to the previous note.
	Only one instance of the LSP_ATTRIBUTES object is meaningful		Only one instance of the LSP_ATTRIBUTES object is meaningful
	within the context of a FILTER_SPEC object. Subsequent instances		within the context of a FILTER_SPEC object. Subsequent instances
	of the object SHOULD be ignored and MUST be forwarded unchanged.		of the object SHOULD be ignored and MUST be forwarded unchanged.
	This means that LSP attributes may be present per sender (LSP) and		This means that LSP attributes may be present per sender (LSP) and
	allows for LSP attributes object to be modified using make-before-		allows for the LSP Attributes object to be modified using make-
	break, see RFC3209. This definition is sufficient for point-to-point		before-break (see [RFC3209]). This definition is sufficient for
	([RFC3209] and [RFC3473]) LSPs, and the special case where all point-		point-to-point ([RFC3209] and [RFC3473]) LSPs and the special case
	to-multipoint source-to-leaf (S2L) sub-LSPs ([RFC4875]) report the		where all point-to-multipoint source-to-leaf (S2L) sub-LSPs
	same operational status (as used in [RFC5420]). But, this definition		([RFC4875]) report the same operational status (as used in
	does not allow for different egress LSRs to report different		[RFC5420]). However, this definition does not allow for different
	operational status. In order to allow such reporting, this document		egress Label Switching Routers (LSRs) to report different operational
	adds the following definition:		statuses. In order to allow such reporting, this document adds the
			following definition:
	An LSR that wishes to report operational status of a (point-to-		An LSR that wishes to report the operational status of a (point-
	multipoint) S2L sub-LSP, it may include the LSP_ATTRIBUTES object		to-multipoint) S2L sub-LSP may include the LSP Attributes object
	in a Resv message, or update the object that is already carried in		in a Resv message or update the object that is already carried in
	a Resv message. LSP_ATTRIBUTES objects representing S2L sub-LSP		a Resv message. LSP Attributes objects representing S2L sub-LSP
	status MUST follow a S2L_SUB_LSP object. Only the first instance		status MUST follow a S2L_SUB_LSP object. Only the first instance
	of the LSP_ATTRIBUTES object is meaningful within the context of a		of the LSP Attributes object is meaningful within the context of a
	S2L_SUB_LSP object. Subsequent instances of the object SHOULD be		S2L_SUB_LSP object. Subsequent instances of the object SHOULD be
	ignored and MUST be forwarded unchanged.		ignored and MUST be forwarded unchanged.
	When an LSP_ATTRIBUTES object is present before the first		When an LSP Attributes object is present before the first
	S2L_SUB_LSP object, the LSP_ATTRIBUTES object represents the		S2L_SUB_LSP object, the LSP Attributes object represents the
	operational status of all S2L sub-LSPs identified in the message.		operational status of all S2L sub-LSPs identified in the message.
	Subsequent instances of the object (e.g, in the filter spec or the		Subsequent instances of the object (e.g., in the filter spec or
	S2L sub-LSP flow descriptor) SHOULD be ignored and MUST be		the S2L sub-LSP flow descriptor) SHOULD be ignored and MUST be
	forwarded unchanged. When a branch node is combining Resv state		forwarded unchanged. When a branch node is combining Resv state
	from multiple receivers into a single Resv message and an		from multiple receivers into a single Resv message and an LSP
	LSP_ATTRIBUTES object is present before the first S2L_SUB_LSP		Attributes object is present before the first S2L_SUB_LSP object
	object in a received Resv message, the received LSP_ATTRIBUTES		in a received Resv message, the received LSP Attributes object
	object SHOULD be moved to follow the first received S2L_SUB_LSP		SHOULD be moved to follow the first received S2L_SUB_LSP object
	object, and then SHOULD be duplicated for, and placed after, each		and then SHOULD be duplicated for, and placed after, each
	subsequent S2L_SUB_LSP object.		subsequent S2L_SUB_LSP object.
	3.1. Resv Message Format -- Per LSP Operational Status		3.1. Resv Message Format -- Per LSP Operational Status
	This section presents the Resv message format for LSPs as modified by		This section presents the Resv message format for LSPs as modified by
	[RFC5420], and can be used to report operational status per LSP.		[RFC5420] and can be used to report operational status per LSP.
	Unmodified formats are not listed. This following is based on		Unmodified formats are not listed. The following is based on
	[RFC4875].		[RFC4875].
	<FF flow descriptor list> ::= <FF flow descriptor>		<FF flow descriptor list> ::= <FF flow descriptor>
	[ <FF flow descriptor list> ]		[ <FF flow descriptor list> ]
	<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>		<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
	[ <LSP_ATTRIBUTES> ... ]		[ <LSP_ATTRIBUTES> ... ]
	[ <RECORD_ROUTE> ]		[ <RECORD_ROUTE> ]
	[ <S2L sub-LSP flow descriptor list> ]		[ <S2L sub-LSP flow descriptor list> ]
	<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>		<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
	<SE filter spec list> ::= <SE filter spec>		<SE filter spec list> ::= <SE filter spec>
	[ <SE filter spec list> ]		[ <SE filter spec list> ]
	<SE filter spec> ::= <FILTER_SPEC> <LABEL>		<SE filter spec> ::= <FILTER_SPEC> <LABEL>
	[ <LSP_ATTRIBUTES> ... ]		[ <LSP_ATTRIBUTES> ... ]
	[ <RECORD_ROUTE> ]		[ <RECORD_ROUTE> ]
	[ <S2L sub-LSP flow descriptor list> ]		[ <S2L sub-LSP flow descriptor list> ]
	3.2. Resv Message Format -- Per S2L Operational Status		3.2. Resv Message Format -- Per S2L Operational Status
	This section presents the Resv message format for LSPs as modified by		This section presents the Resv message format for LSPs as modified by
	this document and [RFC5420], and can be used to report operational		this document and [RFC5420], and can be used to report operational
	status per S2L sub-LSP. Unmodified formats are not listed. This		status per S2L sub-LSP. Unmodified formats are not listed. The
	following is based on [RFC4875].		following is based on [RFC4875].
	<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>		<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
	[ <RECORD_ROUTE> ]		[ <RECORD_ROUTE> ]
	[ <S2L sub-LSP flow descriptor list> ]		[ <S2L sub-LSP flow descriptor list> ]
	<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]		<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
	[ <S2L sub-LSP flow descriptor list> ]		[ <S2L sub-LSP flow descriptor list> ]
	<S2L sub-LSP flow descriptor list> ::=		<S2L sub-LSP flow descriptor list> ::=
	<S2L sub-LSP flow descriptor>		<S2L sub-LSP flow descriptor>
	[ <S2L sub-LSP flow descriptor list> ]		[ <S2L sub-LSP flow descriptor list> ]
	<S2L sub-LSP flow descriptor> ::= <S2L_SUB_LSP>		<S2L sub-LSP flow descriptor> ::= <S2L_SUB_LSP>
	[ <LSP_ATTRIBUTES> ... ]		[ <LSP_ATTRIBUTES> ... ]
	[ <P2MP_SECONDARY_RECORD_ROUTE> ]		[ <P2MP_SECONDARY_RECORD_ROUTE> ]
	3.2.1. Compatibility		3.2.1. Compatibility
	A node that does not support the LSP Attribute object formatting as		A node that supports [RFC4875] and [RFC5420], but not this document,
	defined in this section will interpret the first present LSP		will interpret the first LSP Attributes object present in a received
	Attribute object as representing LSP operational status even when it		message, which is formatted as described in this document, as
	is intended to represent S2L sub-LSP status. It is unclear if this		representing LSP operational status rather than S2L sub-LSP status.
	is a significant issue as the LSP Attribute object is currently		It is unclear if this is a significant issue as the LSP Attributes
	considered to be an unsuitable mechanism for reporting operational		object is currently considered to be an unsuitable mechanism for
	status of P2MP LSPs, for example see Section 2.1 of [NO-PHP-OOB].		reporting operational status of P2MP LSPs, for example, see Section
	The intent of this document is to correct this limitation and it is		2.1 of [RFC6511]. The intent of this document is to correct this
	expected that networks that wish to make use of such operational		limitation; it is expected that networks that wish to make use of
	reporting will deploy this extension.		such operational reporting will deploy this extension.
	4. Security Considerations		4. Security Considerations
	This document clarifies usage of objects defined in [RFC5420]. No		This document clarifies usage of objects defined in [RFC5420]. No
	new information is conveyed and therefore neither are there any		new information is conveyed; therefore, no additional security
	additional security considerations. For a general discussion on MPLS		considerations are included here. For a general discussion on MPLS-
	and GMPLS related security issues, see the MPLS/GMPLS security		and GMPLS-related security issues, see the MPLS/GMPLS security
	framework [RFC5920].		framework [RFC5920].
	5. IANA Considerations		5. Acknowledgments
	There are no new IANA considerations introduced by this document.
	6. Acknowledgments
	The authors would like to acknowledge the contributions of Adrian		The authors would like to acknowledge the contributions of Adrian
	Farrel.		Farrel.
	7. References		6. References
	7.1. Normative References		6.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.
	[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,		[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
	V., and G. Swallow, "RSVP-TE: Extensions to RSVP for		and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
	LSP Tunnels", RFC 3209, December 2001.		Tunnels", RFC 3209, December 2001.
	[RFC3473] Berger, L. Ed., "Generalized Multi-Protocol Label		[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
	Switching (GMPLS) Signaling Resource ReserVation		Switching (GMPLS) Signaling Resource ReserVation Protocol-
	Protocol-Traffic Engineering (RSVP-TE) Extensions",		Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
	January 2003.		January 2003.
	[RFC4875] R. Aggarwal, D. Papadimitriou, and S. Yasukawa,		[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
	"Extensions to Resource Reservation Protocol - Traffic		Yasukawa, Ed., "Extensions to Resource Reservation
	Engineering (RSVP-TE) for Point-to-Multipoint TE Label		Protocol - Traffic Engineering (RSVP-TE) for Point-to-
	Switched Paths (LSPs)", RFC4875, May 2007.		Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May
			2007.
	[RFC5420] Farrel, A., Ed. "Encoding of Attributes for MPLS LSP		[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A.
	Establishment Using Resource Reservation Protocol		Ayyangarps, "Encoding of Attributes for MPLS LSP
	Traffic Engineering (RSVP-TE)", RFC 5420, February 2009.		Establishment Using Resource Reservation Protocol Traffic
			Engineering (RSVP-TE)", RFC 5420, February 2009.
	[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax		[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
	Used to Form Encoding Rules in Various Routing Protocol		Used to Form Encoding Rules in Various Routing Protocol
	Specifications", RFC 5511, April 2009		Specifications", RFC 5511, April 2009.
	7.2. Informative References		6.2. Informative References
	[NO-PHP-OOB] Ali, Z., Swallow, G., "Non PHP Behavior and		[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
	out-of-band mapping for RSVP-TE LSPs", work in		Networks", RFC 5920, July 2010.
	progress, draft-ietf-mpls-rsvp-te-no-php-oob-mapping.
	[RFC5920] Fang, L.,		[RFC6511] Ali, Z., Swallow, G., and R. Aggarwal, "Non-Penultimate
	"Security Framework for MPLS and GMPLS Networks",		Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE
	RFC 5920, July 2010.		Label Switched Paths", RFC 6511, February 2012.
	8. Authors' Addresses		Authors' Addresses
	Lou Berger		Lou Berger
	LabN Consulting, L.L.C.		LabN Consulting, L.L.C.
	Phone: +1-301-468-9228		Phone: +1-301-468-9228
	Email: lberger@labn.net		EMail: lberger@labn.net
	George Swallow		George Swallow
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Email: swallow@cisco.com		EMail: swallow@cisco.com
	Generated on: Fri, Aug 19, 2011 10:14:59 AM
End of changes. 57 change blocks.
	150 lines changed or deleted		138 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/