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/