doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc5420.txt b/doc/rfc/rfc5420.txt
new file mode 100644
index 0000000..1d3a90d
--- /dev/null
+++ b/doc/rfc/rfc5420.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Network Working Group                                     A. Farrel, Ed.
+Request for Comments: 5420                            Old Dog Consulting
+Obsoletes: 4420                                         D. Papadimitriou
+Updates: 3209, 3473                                              Alcatel
+Category: Standards Track                                    JP. Vasseur
+                                                     Cisco Systems, Inc.
+                                                             A. Ayyangar
+                                                        Juniper Networks
+                                                           February 2009
+
+
+        Encoding of Attributes for MPLS LSP Establishment Using
+      Resource Reservation Protocol Traffic Engineering (RSVP-TE)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents (http://trustee.ietf.org/
+   license-info) in effect on the date of publication of this document.
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrel, et al.              Standards Track                     [Page 1]
+
+RFC 5420        Attributes for MPLS LSPs Using RSVP-TE     February 2009
+
+
+Abstract
+
+   Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may
+   be established using the Resource Reservation Protocol Traffic
+   Engineering (RSVP-TE) extensions.  This protocol includes an object
+   (the SESSION_ATTRIBUTE object) that carries a Flags field used to
+   indicate options and attributes of the LSP.  That Flags field has
+   eight bits, allowing for eight options to be set.  Recent proposals
+   in many documents that extend RSVP-TE have suggested uses for each of
+   the previously unused bits.
+
+   This document defines a new object for RSVP-TE messages that allows
+   the signaling of further attribute bits and also the carriage of
+   arbitrary attribute parameters to make RSVP-TE easily extensible to
+   support new requirements.  Additionally, this document defines a way
+   to record the attributes applied to the LSP on a hop-by-hop basis.
+
+   The object mechanisms defined in this document are equally applicable
+   to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to
+   GMPLS non-PSC LSPs.
+
+   This document replaces and obsoletes the previous version of this
+   work, published as RFC 4420.  The only change is in the encoding of
+   the Type-Length-Variable (TLV) data structures.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrel, et al.              Standards Track                     [Page 2]
+
+RFC 5420        Attributes for MPLS LSPs Using RSVP-TE     February 2009
+
+
+Table of Contents
+
+   1. Introduction and Problem Statement ..............................4
+      1.1. Applicability to Generalized MPLS ..........................5
+      1.2. A Rejected Alternate Solution ..............................5
+   2. Terminology .....................................................6
+   3. Attributes TLVs .................................................6
+      3.1. Attribute Flags TLV ........................................7
+   4. LSP_ATTRIBUTES Object ...........................................8
+      4.1. Format .....................................................9
+      4.2. Generic Processing Rules for Path Messages .................9
+      4.3. Generic Processing Rules for Resv Messages .................9
+   5. LSP_REQUIRED_ATTRIBUTES Object .................................10
+      5.1. Format ....................................................11
+      5.2. Generic Processing Rules ..................................11
+   6. Inheritance Rules ..............................................11
+   7. Recording Attributes Per LSP ...................................12
+      7.1. Requirements ..............................................12
+      7.2. RRO Attributes Subobject ..................................12
+      7.3. Procedures ................................................13
+           7.3.1. Subobject Presence Rules ...........................13
+           7.3.2. Reporting Compliance with LSP Attributes ...........14
+           7.3.3. Reporting Per-Hop Attributes .......................14
+           7.3.4. Default Behavior ...................................14
+   8. Summary of Attribute Bit Allocation ............................14
+   9. Message Formats ................................................15
+   10. Guidance for Key Application Scenarios ........................16
+      10.1. Communicating to Egress LSRs .............................16
+      10.2. Communicating to Key Transit LSRs ........................17
+      10.3. Communicating to All LSRs ................................17
+   11. IANA Considerations ...........................................17
+      11.1. New RSVP C-Nums and C-Types ..............................17
+      11.2. New TLV Space ............................................18
+      11.3. Attribute Flags ..........................................19
+      11.4. New Error Codes ..........................................19
+      11.5. New Record Route Subobject Identifier ....................19
+   12. Security Considerations .......................................20
+   13. Acknowledgements ..............................................20
+   14. Changes from RFC 4420 to RFC 5420 .............................20
+   15. Normative References ..........................................21
+   16. Informative References ........................................21
+
+
+
+
+
+
+
+
+
+
+Farrel, et al.              Standards Track                     [Page 3]
+
+RFC 5420        Attributes for MPLS LSPs Using RSVP-TE     February 2009
+
+
+1.  Introduction and Problem Statement
+
+   This document replaces and obsoletes the previous version of this
+   work, published as RFC 4420 [RFC4420].  The only change is in the
+   encoding of the Type-Length-Variable (TLV) data structures presented
+   in Section 3.  See Section 14 for a summary of changes.
+
+   Traffic-Engineered Multiprotocol Label Switching (MPLS) Label
+   Switched Paths (LSPs) [RFC3031] may be set up using the Path message
+   of the RSVP-TE signaling protocol [RFC3209].  The Path message
+   includes the SESSION_ATTRIBUTE object, which carries a Flags field
+   used to indicate desired options and attributes of the LSP.
+
+   The Flags field in the SESSION_ATTRIBUTE object has eight bits.  Just
+   three of those bits are assigned in [RFC3209].  A further two bits
+   are assigned in [RFC4090] for fast re-reroute functionality, leaving
+   only three bits available.  Several recent proposals and Internet
+   Drafts have demonstrated that there is a high demand for the use of
+   the other three bits.  Some, if not all, of those proposals are
+   likely to go forward as RFCs, resulting in depletion or near
+   depletion of the Flags field and a consequent difficulty in signaling
+   new options and attributes that may be developed in the future.
+
+   This document defines a new object for RSVP-TE messages that allows
+   the signaling of further attributes bits.  The new object is
+   constructed from TLVs, and a new TLV is defined to carry a variable
+   number of attributes bits.
+
+   The new RSVP-TE message object is quite flexible, due to the use of
+   the TLV format and allows:
+
+   - future specification of bit flags
+   - additional options and attribute parameters carried in TLV format
+
+   Note that the LSP Attributes defined in this document are
+   specifically scoped to an LSP.  They may be set differently on
+   separate LSPs with the same Tunnel ID between the same source and
+   destination (that is, within the same session).
+
+   It is noted that some options and attributes do not need to be acted
+   on by all Label Switched Routers (LSRs) along the path of the LSP.
+   In particular, these options and attributes may apply only to key
+   LSRs on the path, such as the ingress LSR and egress LSR.  Special
+   transit LSRs, such as Area or Autonomous System Border Routers (ABRs
+   or ASBRs), may also fall into this category.  This means that the new
+   options and attributes should be signaled transparently, and only
+   examined at those points that need to act on them.
+
+
+
+
+Farrel, et al.              Standards Track                     [Page 4]
+
+RFC 5420        Attributes for MPLS LSPs Using RSVP-TE     February 2009
+
+
+   On the other hand, other options and attributes may require action at
+   all transit LSRs along the path of the LSP.  Inability to support the
+   required attributes by one of those transit LSRs may require the LSR
+   to refuse the establishment of the LSP.
+
+   These considerations are particularly important in the context of
+   backward compatibility.  In general, it should be possible to provide
+   new MPLS services across a legacy network without upgrading those
+   LSRs that do not need to participate actively in the new services.
+   Moreover, some features just require action on specific intermediate
+   hops, not on every visited LSR.
+
+   Note that options already specified for the SESSION_ATTRIBUTE object
+   in preexisting RFCs are not migrated to the new mechanisms described
+   in this document.
+
+   RSVP includes a way for unrecognized objects to be transparently
+   forwarded by transit nodes without them refusing the incoming
+   protocol messages and without the objects being stripped from the
+   outgoing protocol message (see [RFC2205], Section 3.10).  This
+   capability extends to RSVP-TE and provides a good way to ensure that
+   only those LSRs that understand a particular object examine it.
+
+   This document distinguishes between options and attributes that are
+   only required at key LSRs along the path of the LSP, and those that
+   must be acted on by every LSR along the LSP.  Two LSP Attributes
+   objects are defined in this document; using the C-Num definition
+   rules inherited from [RFC2205], the first is passed transparently by
+   LSRs that do not recognize it, and the second causes LSP setup
+   failure with the generation of a PathErr message with an appropriate
+   Error Code if an LSR does not recognize it.
+
+1.1.  Applicability to Generalized MPLS
+
+   The RSVP-TE signaling protocol also forms the basis of a signaling
+   protocol for Generalized MPLS (GMPLS) as described in [RFC3471] and
+   [RFC3473].  The extensions described in this document are equally
+   applicable to MPLS and GMPLS.
+
+1.2.  A Rejected Alternate Solution
+
+   A rejected alternate solution was to define a new C-Type for the
+   existing SESSION_ATTRIBUTE object.  This new C-Type could allow a
+   larger Flags field and address the immediate problem.
+
+
+
+
+
+
+
+Farrel, et al.              Standards Track                     [Page 5]
+
+RFC 5420        Attributes for MPLS LSPs Using RSVP-TE     February 2009
+
+
+   This solution was rejected because:
+
+   - A new C-Type is not backward compatible with deployed
+     implementations that expect to see a C-Type of 1 or 7.  It is
+     important that any solution be capable of carrying new attributes
+     transparently across legacy LSRs if those LSRs are not required to
+     act on the attributes.
+
+   - Support for arbitrary attributes parameters through TLVs would have
+     meant a significant change of substance to the existing object.
+
+2.  Terminology
+
+   This document uses terminology from the MPLS architecture document
+   [RFC3031] and from the RSVP-TE protocol specification [RFC3209],
+   which inherits from the RSVP specification [RFC2205].  It also makes
+   use of the Generalized MPLS RSVP-TE terminology introduced in
+   [RFC3471] and [RFC3473].
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+3.  Attributes TLVs
+
+   Attributes carried by the new objects defined in this document are
+   encoded within TLVs.  One or more TLVs may be present in each object.
+   There are no ordering rules for TLVs, and no interpretation should be
+   placed on the order in which TLVs are received.
+
+   Each TLV is encoded as follows.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |             Type              |           Length              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   //                            Value                            //
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Type
+
+         The identifier of the TLV.
+
+
+
+
+
+
+Farrel, et al.              Standards Track                     [Page 6]
+
+RFC 5420        Attributes for MPLS LSPs Using RSVP-TE     February 2009
+
+
+      Length
+
+         Indicates the total length of the TLV in octets.  That is, the
+         combined length of the Type, Length, and Value fields, i.e.,
+         four plus the length of the Value field in octets.
+
+         The entire TLV MUST be padded with between zero and three
+         trailing zeros to make it four-octet aligned.  The Length field
+         does not count any padding.
+
+      Value
+
+         The data carried in the TLV.
+
+3.1.  Attribute Flags TLV
+
+   This document defines only one TLV type value.  Type 1 indicates the
+   Attribute Flags TLV.  Other TLV types may be defined in the future
+   with type values assigned by IANA (see Section 11.2).
+
+   The Attribute Flags TLV may be present in an LSP_ATTRIBUTES object
+   and/or an LSP_REQUIRED_ATTRIBUTES object, defined in Sections 4 and
+   5.  The bits in the TLV represent the same attributes regardless of
+   which object carries the TLV.  Documents that define individual bits
+   MUST specify whether the bit may be set in one object, the other, or
+   both.  It is not expected that a bit will be set in both objects on a
+   single Path message at the same time, but this is not ruled out by
+   this document.
+
+   The Attribute Flags TLV Value field is an array of units of 32 flags
+   numbered from the most significant bit as bit zero.  The Length field
+   for this TLV is therefore always a multiple of four bytes, regardless
+   of the number of bits carried, and no padding is required.
+
+   Unassigned bits are considered as reserved and MUST be set to zero on
+   transmission by the originator of the object.  Bits not contained in
+   the TLV MUST be assumed to be set to zero.  If the TLV is absent
+   either because it is not contained in the LSP_ATTRIBUTES or
+   LSP_REQUIRED_ATTRIBUTES object, or because those objects are
+   themselves absent, all processing MUST be performed as though the
+   bits were present and set to zero.  That is to say, assigned bits
+   that are not present either because the TLV is deliberately
+   foreshortened or because the TLV is not included MUST be treated as
+   though they are present and are set to zero.
+
+   No bits are defined in this document.  The assignment of bits is
+   managed by IANA (see Section 11.3).
+
+
+
+
+Farrel, et al.              Standards Track                     [Page 7]
+
+RFC 5420        Attributes for MPLS LSPs Using RSVP-TE     February 2009
+
+
+4.  LSP_ATTRIBUTES Object
+
+   The LSP_ATTRIBUTES object is used to signal attributes required in
+   support of an LSP, or to indicate the nature or use of an LSP where
+   that information is not required to be acted on by all transit LSRs.
+   Specifically, if an LSR does not support the object, it forwards it
+   unexamined and unchanged.  This facilitates the exchange of
+   attributes across legacy networks that do not support this new
+   object.
+
+   This object effectively extends the Flags field in the
+   SESSION_ATTRIBUTE object and allows for the future inclusion of more
+   complex objects through TLVs.
+
+   Note that some function may require an LSR to inspect both the
+   SESSION_ATTRIBUTE object and the LSP_ATTRIBUTES or
+   LSP_REQUIRED_ATTRIBUTES object.
+
+   The LSP_ATTRIBUTES object may also be used to report LSP operational
+   state on a Resv message even when no LSP_ATTRIBUTES or
+   LSP_REQUIRED_ATTRIBUTES object was carried on the corresponding Path
+   message.  The object is added or updated by LSRs that support the
+   object.  LSRs that do not understand the object or have nothing to
+   report do not add the object and forward it unchanged on Resv
+   messages that they generate.
+
+   The LSP_ATTRIBUTES object class is 197 of the form 11bbbbbb.  This
+   C-Num value (see [RFC2205], Section 3.10) ensures that LSRs that do
+   not recognize the object pass it on transparently.
+
+   One C-Type is defined, C-Type = 1 for LSP Attributes.
+
+   This object is optional and may be placed on Path messages to convey
+   additional information about the desired attributes of the LSP, and
+   on Resv messages to report operational state.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrel, et al.              Standards Track                     [Page 8]
+
+RFC 5420        Attributes for MPLS LSPs Using RSVP-TE     February 2009
+
+
+4.1.  Format
+
+   LSP_ATTRIBUTES class = 197, C-Type = 1
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   //                       Attributes TLVs                       //
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The Attributes TLVs are encoded as described in Section 3.
+
+4.2.  Generic Processing Rules for Path Messages
+
+   An LSR that does not support this object is required to pass it on
+   unaltered, as indicated by the C-Num and the rules defined in
+   [RFC2205].
+
+   An LSR that does support this object but does not recognize a TLV
+   type code carried in this object MUST pass the TLV on unaltered in
+   the LSP_ATTRIBUTES object that it places in the Path message that it
+   sends downstream.
+
+   An LSR that does support this object and recognizes a TLV but does
+   not support the attribute defined by the TLV MUST act as specified in
+   the document that defines the TLV.
+
+   An LSR that supports the Attribute Flags TLV but does not recognize a
+   bit set in the Attribute Flags TLV MUST forward the TLV unchanged.
+
+   An LSR that supports the Attribute Flags TLV and recognizes a bit
+   that is set but does not support the indicated attribute MUST act as
+   specified in the document that defines the bit.
+
+4.3.  Generic Processing Rules for Resv Messages
+
+   An LSR that wishes to report operational status of an LSP may include
+   this object in a Resv message, or update the object that is already
+   carried in a Resv message.
+
+   Note that this usage reports the state of the entire LSP and not the
+   state of the LSP at an individual LSR.  This latter function is
+   achieved using the LSP Attributes subobject of the Record Route
+   object (RRO) as described in Section 7.
+
+
+
+
+
+Farrel, et al.              Standards Track                     [Page 9]
+
+RFC 5420        Attributes for MPLS LSPs Using RSVP-TE     February 2009
+
+
+   The bits in the Attributes TLV may be used to report operational
+   status for the whole LSP.  For example, an egress LSR may report a
+   particular status by setting a bit.  LSRs within the network that
+   determine that this status has not been achieved may clear the bit as
+   they forward the Resv message.
+
+   Observe that LSRs that do not support the object or do not support
+   the function characterized by a particular bit in the Attributes TLV
+   will not clear the bit when forwarding the Resv.  Thus, care must be
+   taken in defining the usage of this object on a Resv.  The usage of
+   an individual bit in the Attributes TLV of the LSP_ATTRIBUTES object
+   on a Resv must be fully defined in the document that defines the bit.
+
+   Additional TLVs may also be defined to be carried in this object on a
+   Resv.
+
+   An LSR that does not support this object will pass it on unaltered
+   because of the C-Num.
+
+5.  LSP_REQUIRED_ATTRIBUTES Object
+
+   The LSP_REQUIRED_ATTRIBUTES object is used to signal attributes
+   required in support of an LSP, or to indicate the nature or use of an
+   LSP where that information MUST be inspected at each transit LSR.
+   Specifically, each transit LSR MUST examine the attributes in the
+   LSP_REQUIRED_ATTRIBUTES object and MUST NOT forward the object
+   without acting on its contents.
+
+   This object effectively extends the Flags field in the
+   SESSION_ATTRIBUTE object and allows for the future inclusion of more
+   complex objects through TLVs.  It complements the LSP_ATTRIBUTES
+   object.
+
+   The LSP_REQUIRED_ATTRIBUTES object class is 67 of the form 0bbbbbbb.
+   This C-Num value ensures that LSRs that do not recognize the object
+   reject the LSP setup, effectively saying that they do not support the
+   attributes requested.  This means that this object SHOULD only be
+   used for attributes that require support at some transit LSRs and so
+   require examination at all transit LSRs.  See Section 4 for how end-
+   to-end and selective attributes are signaled.
+
+   One C-Type is defined, C-Type = 1 for LSP Required Attributes.
+
+   This object is optional and may be placed on Path messages to convey
+   additional information about the desired attributes of the LSP.
+
+
+
+
+
+
+Farrel, et al.              Standards Track                    [Page 10]
+
+RFC 5420        Attributes for MPLS LSPs Using RSVP-TE     February 2009
+
+
+5.1.  Format
+
+   LSP_REQUIRED_ATTRIBUTES class = 67, C-Type = 1
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   //                      Attributes TLVs                        //
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The Attributes TLVs are encoded as described in Section 3.
+
+5.2.  Generic Processing Rules
+
+   An LSR that does not support this object will use a PathErr to reject
+   the Path message based on the C-Num using the Error Code "Unknown
+   Object Class".
+
+   An LSR that does not recognize a TLV type code carried in this object
+   MUST reject the Path message using a PathErr with Error Code "Unknown
+   Attributes TLV" and Error Value set to the value of the unknown TLV
+   type code.
+
+   An LSR that does not recognize a bit set in the Attribute Flags TLV
+   MUST reject the Path message using a PathErr with Error Code "Unknown
+   Attributes Bit" and Error Value set to the bit number of the unknown
+   bit in the Attribute Flags.
+
+   An LSR that recognizes an attribute (however encoded) but does not
+   support that attribute MUST act according to the behavior specified
+   in the document that defines that specific attribute.
+
+   Note that this object is not used on a Resv.  In order to report the
+   status of an LSP, either the LSP_ATTRIBUTES object on a Resv or the
+   Attributes subobject in the Record Route object (see Section 7) must
+   be used.
+
+6.  Inheritance Rules
+
+   In certain circumstances, when reaching an LSP region boundary, a
+   forwarding adjacency LSP (FA-LSP; see [RFC4206]) is initially set up
+   to allow the establishment of the LSP carrying the LSP_ATTRIBUTES
+   and/or LSP_REQUIRED_ATTRIBUTES objects.  In this case, when the
+
+
+
+
+
+
+Farrel, et al.              Standards Track                    [Page 11]
+
+RFC 5420        Attributes for MPLS LSPs Using RSVP-TE     February 2009
+
+
+   boundary LSR supports LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES
+   processing, the FA-LSP MAY, upon local policy, inherit a subset of
+   the Attributes TLVs, in particular when the FA-LSP belongs to the
+   same switching capability class as the triggering LSP.
+
+   When these conditions are met, the LSP_ATTRIBUTES and/or
+   LSP_REQUIRED_ATTRIBUTES objects are simply copied with the inherited
+   Attributes TLVs in the Path message used to establish the FA-LSP.  By
+   default (and in order to simplify deployment), none of the incoming
+   LSP Attributes TLVs are considered as inheritable.  Note that when
+   the FA-LSP establishment itself requires one or more Attributes TLVs,
+   an 'OR' operation is performed with the inherited set of values.
+
+   Documents that define individual bits for the LSP Attribute Flags TLV
+   MUST specify whether or not these bits MAY be inherited (including
+   the condition to be met in order for this inheritance to occur).  The
+   same applies for any other TLV that will be defined following the
+   rules specified in Section 3.
+
+7.  Recording Attributes Per LSP
+
+7.1.  Requirements
+
+   In some circumstances, it is useful to determine which of the
+   requested LSP attributes have been applied at which LSRs along the
+   path of the LSP.  For example, an attribute may be requested in the
+   LSP_ATTRIBUTES object such that LSRs that do not support the object
+   are not required to support the attribute or provide the requested
+   function.  In this case, it may be useful to the ingress LSR to know
+   which LSRs acted on the request and which ignored it.
+
+   Additionally, there may be other qualities that need to be reported
+   on a hop-by-hop basis.  These are currently indicated in the Flags
+   field of RRO subobjects.  Since there are only eight bits available
+   in this field, and since some are already assigned and there is also
+   likely to be an increase in allocations in new documents, there is a
+   need for some other method to report per-hop attributes.
+
+7.2.  RRO Attributes Subobject
+
+   The RRO Attributes subobject may be carried in the RECORD_ROUTE
+   object if it is present.  The subobject uses the standard format of
+   an RRO subobject.
+
+   The length is variable, as for the Attribute Flags TLV.  The content
+   is the same as the Attribute Flags TLV -- that is, it is a series of
+   bit flags.
+
+
+
+
+Farrel, et al.              Standards Track                    [Page 12]
+
+RFC 5420        Attributes for MPLS LSPs Using RSVP-TE     February 2009
+
+
+   There is a one-to-one correspondence between bits in the Attribute
+   Flags TLV and the RRO Attributes subobject.  If a bit is only
+   required in one of the two places, it is reserved in the other place.
+   See the procedures sections, below, for more information.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Type     |     Length    |           Reserved            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   //                       Attribute Flags                       //
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Type
+
+         0x05
+
+      Length
+
+         The Length contains the total length of the subobject in bytes,
+         including the Type and Length fields.  This length must be a
+         multiple of four and must be at least eight.
+
+      Attribute Flags
+
+         The attribute flags recorded for the specific hop.
+
+7.3.  Procedures
+
+7.3.1.  Subobject Presence Rules
+
+   As will be clear from [RFC3209], the RECORD_ROUTE object is managed
+   as a "stack", with each LSR adding subobjects to the start of the
+   object.  The Attributes subobject is pushed onto the RECORD_ROUTE
+   object immediately prior to pushing the node's IP address or link
+   identifier.  Thus, if label recording is being used, the Attributes
+   subobject SHOULD be pushed onto the RECORD_ROUTE object after the
+   Record Label subobject(s).
+
+   A node MUST NOT push an Attributes subobject onto the RECORD_ROUTE
+   object without also pushing an IPv4, IPv6, or Unnumbered Interface ID
+   subobject.
+
+   This means that an Attributes subobject is bound to the LSR
+   identified by the subobject found in the RRO immediately before the
+   Attributes subobject.
+
+
+
+Farrel, et al.              Standards Track                    [Page 13]
+
+RFC 5420        Attributes for MPLS LSPs Using RSVP-TE     February 2009
+
+
+   If the new subobject causes the RRO to be too big to fit in a Path
+   (or Resv) message, the processing MUST be as described in Section
+   4.4.3 of [RFC3209].
+
+   If more than one Attributes subobject is found between a pair of
+   subobjects that identify LSRs, only the first one found (that is, the
+   nearest to the top of the stack) SHALL have any meaning within the
+   context of this document.  All such subobjects MUST be forwarded
+   unmodified by transit LSRs.
+
+7.3.2.  Reporting Compliance with LSP Attributes
+
+   To report compliance with an attribute requested in the Attribute
+   Flags TLV, an LSR MAY set the corresponding bit (see Section 8) in
+   the Attributes subobject.  To report non-compliance, an LSR MAY clear
+   the corresponding bit in the Attributes subobject.
+
+   The requirement to report compliance MUST be specified in the
+   document that defines the usage of any bit.  This will reduce to a
+   statement of whether hop-by-hop acknowledgement is required.
+
+7.3.3.  Reporting Per-Hop Attributes
+
+   To report a per-hop attribute, an LSR sets the appropriate bit in the
+   Attributes subobject.
+
+   The requirement to report a per-hop attribute MUST be specified in
+   the document that defines the usage of the bit.
+
+7.3.4.  Default Behavior
+
+   By default, all bits in an Attributes subobject SHOULD be set to
+   zero.
+
+   If a received Attributes subobject is not long enough to include a
+   specific numbered bit, that bit MUST be treated as though present and
+   as if set to zero.
+
+   If the RRO subobject is not present for a hop in the LSP, all bits
+   MUST be assumed to be set to zero.
+
+8.  Summary of Attribute Bit Allocation
+
+   This document defines two uses of per-LSP attribute flag bit fields.
+   The bit numbering in the Attribute Flags TLV and the RRO Attributes
+   subobject is identical.  That is, the same attribute is indicated by
+   the same bit in both places.  This means that only a single registry
+   of bits is maintained.
+
+
+
+Farrel, et al.              Standards Track                    [Page 14]
+
+RFC 5420        Attributes for MPLS LSPs Using RSVP-TE     February 2009
+
+
+   The consequence is a degree of clarity in implementation and
+   registration.
+
+   Note, however, that it is not always the case that a bit will be used
+   in both the Attribute Flags TLV and the RRO Attributes subobject.
+   For example, an attribute may be requested using the Attribute Flags
+   TLV, but there is no requirement to report the handling of the
+   attribute on a hop-by-hop basis.  Conversely, there may be a
+   requirement to report the attributes of an LSP on a hop-by-hop basis,
+   but there is no corresponding request attribute.
+
+   In these cases, a single bit number is still assigned for both the
+   Attribute Flags TLV and the RRO Attributes subobject, even though the
+   bit may be irrelevant in either the Attribute Flags or the RRO
+   Attributes subobject.  The document that defines the usage of the new
+   bit MUST state in which places it is used and MUST handle a default
+   setting of zero.
+
+9.  Message Formats
+
+   The LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object MAY
+   be carried in a Path message.  The LSP_ATTRIBUTES object MAY be
+   carried in a Resv message.
+
+   The order of objects in RSVP-TE messages is recommended, but
+   implementations must be capable of receiving the objects in any
+   meaningful order.
+
+   On a Path message, the LSP_ATTRIBUTES object and
+   LSP_REQUIRED_ATTRIBUTES objects are RECOMMENDED to be placed
+   immediately after the SESSION_ATTRIBUTE object if it is present, or
+   otherwise immediately after the LABEL_REQUEST object.
+
+   If both the LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES
+   object are present, the LSP_REQUIRED_ATTRIBUTES object is RECOMMENDED
+   to be placed first.
+
+   LSRs MUST be prepared to receive these objects in any order in any
+   position within a Path message.  Subsequent instances of these
+   objects within a Path message SHOULD be ignored and MUST be forwarded
+   unchanged.
+
+   On a Resv message, the LSP_ATTRIBUTES object is placed in the flow
+   descriptor and is associated with the FILTER_SPEC object that
+   precedes it.  It is RECOMMENDED that the LSP_ATTRIBUTES object be
+   placed immediately after the LABEL object.
+
+
+
+
+
+Farrel, et al.              Standards Track                    [Page 15]
+
+RFC 5420        Attributes for MPLS LSPs Using RSVP-TE     February 2009
+
+
+   LSRs MUST be prepared to receive this object in any order in any
+   position within a Resv message, subject to the previous note.  Only
+   one instance of the LSP_ATTRIBUTES object is meaningful within the
+   context of a FILTER_SPEC object.  Subsequent instances of the object
+   SHOULD be ignored and MUST be forwarded unchanged.
+
+10.  Guidance for Key Application Scenarios
+
+   As described in the Introduction section of this document, it may be
+   that requested LSP attributes need to be acted on by only the egress
+   LSR of the LSP, by certain key transit points (such as ABRs and
+   ASBRs), or by all LSRs along the LSP.  This section briefly describes
+   how each of these scenarios is met.  This section is informational
+   and does not define any new procedures.
+
+10.1.  Communicating to Egress LSRs
+
+   When communicating LSP attributes that must be acted on only by the
+   LSP egress LSR, the attributes should be communicated in the
+   LSP_ATTRIBUTES object.  Because of its C-Num, this object may be
+   ignored (passed onwards, untouched) by transit LSRs that do not
+   understand it.  This means that the Path message will not be rejected
+   by LSRs that do not understand the object.  In this way, the
+   requested LSP attributes are guaranteed to reach the egress LSR.
+
+   Attributes are set within the LSP_ATTRIBUTES object according to
+   which LSP attributes are required.  Each attribute is defined in some
+   RFC and is accompanied by a statement of what the expected behavior
+   is.  This behavior will include whether the attribute must be acted
+   on by any LSR that recognizes it, or specifically by the egress LSR.
+   Thus, any attribute that must be acted on only by an egress LSR will
+   be defined in this way -- any transit LSR seeing this attribute
+   either will understand the semantics of the attribute and ignore it
+   (forwarding it, unchanged) or will not understand the attribute and
+   ignore it (forwarding it, unchanged) according to the rules of the
+   LSP_ATTRIBUTES object.
+
+   The remaining issue is how the ingress LSR can know whether the
+   egress LSR has acted correctly on the required LSP attribute.
+   Another part of the definition of the attribute (in the defining RFC)
+   is whether reporting is required.  If reporting is required, the
+   egress LSR is required to use the RRO Attributes subobject to report
+   whether it has acted on the received attribute.
+
+   If an egress LSR understands a received attribute as mandatory for an
+   egress LSR but does not wish to satisfy the request, it will reject
+   the Path message.  If an egress LSR understands the attribute but
+   believes it to be optional and does not wish to satisfy the request,
+
+
+
+Farrel, et al.              Standards Track                    [Page 16]
+
+RFC 5420        Attributes for MPLS LSPs Using RSVP-TE     February 2009
+
+
+   it will report its non-compliance in the RRO Attributes subobject.
+   If the egress LSR does not understand the received attribute, it may
+   report non-compliance in the RRO Attributes subobject explicitly, or
+   it may omit the RRO Attributes subobject, implying that it has not
+   satisfied the request.
+
+10.2.  Communicating to Key Transit LSRs
+
+   Processing for key transit LSRs (such as ABRs and ASBRs) follows
+   exactly as for egress LSR.  The only difference is that the
+   definition of the LSP attribute in the defining RFC will state that
+   the attribute must be acted on by these transit LSRs.
+
+10.3.  Communicating to All LSRs
+
+   In order to force all LSRs to examine the LSP attributes, the
+   LSP_REQUIRED_ATTRIBUTES object is used.  The C-Num of this object is
+   such that any LSR that does not recognize the object must reject a
+   received Path message containing the object.
+
+   An LSR that recognizes the LSP_REQUIRED_ATTRIBUTES object but does
+   not recognize an attribute will reject the Path message.
+
+   An LSR that recognizes an attribute but does not wish to support the
+   attribute reacts according to the definition of the attribute in the
+   defining RFC.  This may allow the LSR to ignore the attribute and
+   forward it unchanged, or may require it to fail the LSP setup.  The
+   LSR may additionally be required to report whether it supports the
+   attribute using the RRO Attributes subobject.
+
+11.  IANA Considerations
+
+   The IANA allocations made for RFC 4420 [RFC4420] now apply to this
+   document and are listed here for completeness.
+
+   IANA has updated the registry entries created for RFC 4420 to
+   reference this document, which is now the normative reference for
+   those entries.  This document makes no further requests for IANA
+   action.
+
+11.1.  New RSVP C-Nums and C-Types
+
+   Two new RSVP C-Nums are defined in this document and have been
+   assigned by IANA.
+
+
+
+
+
+
+
+Farrel, et al.              Standards Track                    [Page 17]
+
+RFC 5420        Attributes for MPLS LSPs Using RSVP-TE     February 2009
+
+
+   o LSP_ATTRIBUTES object
+
+     The C-Num (value 197) is of the form 11bbbbbb so that LSRs that do
+     not recognize the object will ignore the object but forward it,
+     unexamined and unmodified, in all messages resulting from this
+     message.
+
+     One C-Type is defined for this object and has been assigned by
+     IANA.
+
+     o LSP Attributes TLVs
+
+       C-Type value 1.
+
+   o LSP_REQUIRED_ATTRIBUTES object
+
+     The C-Num (value 67) is of the form 0bbbbbbb so that LSRs that do
+     not recognize the object will reject the message that carries it
+     with an "Unknown Object Class" error.
+
+     One C-Type is defined for this object and has been assigned by
+     IANA.
+
+     o LSP Required Attributes TLVs
+
+       C-Type value 1.
+
+11.2.  New TLV Space
+
+   The two new objects referenced above are constructed from TLVs.  Each
+   TLV includes a 16-bit type identifier (the T-field).  The same
+   T-field values are applicable to both objects.
+
+   The IANA has created a new registry and will manage TLV type
+   identifiers as follows:
+
+   - TLV Type (T-field value)
+   - TLV Name
+   - Whether allowed on LSP_ATTRIBUTES object
+   - Whether allowed on LSP_REQUIRED_ATTRIBUTES object
+
+   This document defines one TLV type as follows:
+
+   - TLV Type = 1
+   - TLV Name = Attribute Flags TLV
+   - allowed on LSP_ATTRIBUTES object
+   - allowed on LSP_REQUIRED_ATTRIBUTES object
+
+
+
+
+Farrel, et al.              Standards Track                    [Page 18]
+
+RFC 5420        Attributes for MPLS LSPs Using RSVP-TE     February 2009
+
+
+   New TLV type values may be allocated only by an IETF Consensus
+   action.
+
+11.3.  Attribute Flags
+
+   This document provides new attributes bit flags for use in other
+   documents that specify new RSVP-TE attributes.  These flags are
+   present in the Attribute Flags TLV referenced in the previous
+   section.
+
+   The IANA has created a new registry and will manage the space of
+   attributes bit flags, numbering them in the usual IETF notation:
+   starting at zero and continuing at least through 31.
+
+   New bit numbers may be allocated only by an IETF Consensus action.
+
+   Each bit should be tracked with the following qualities:
+
+   - Bit number
+   - Defining RFC
+   - Name of bit
+   - Whether there is meaning in the Attribute Flags TLV on a Path
+   - Whether there is meaning in the Attribute Flags TLV on a Resv
+   - Whether there is meaning in the RRO Attributes subobject
+
+   Note that this means that all bits in the Attribute Flags TLV and the
+   RRO Attributes subobject use the same bit number, regardless of
+   whether they are used in one or both places.  Thus, only one list of
+   bits is required to be maintained.  (It would be meaningless in the
+   context of this document for a bit to have no meaning in either the
+   Attribute Flags TLV or the RRO Attributes subobject.)
+
+11.4.  New Error Codes
+
+   This document defines the following new Error Codes and Error Values.
+   Numeric values have been assigned by IANA.
+
+   Error Code                     Error Value
+   29 "Unknown Attributes TLV"    Identifies the unknown TLV type code.
+   30 "Unknown Attributes Bit"    Identifies the unknown Attribute Bit.
+
+11.5.  New Record Route Subobject Identifier
+
+   A new subobject is defined for inclusion in the RECORD_ROUTE object.
+
+   The RRO Attributes subobject is identified by a Type value of 5.
+
+
+
+
+
+Farrel, et al.              Standards Track                    [Page 19]
+
+RFC 5420        Attributes for MPLS LSPs Using RSVP-TE     February 2009
+
+
+12.  Security Considerations
+
+   This document adds two new objects to the RSVP Path message as used
+   in MPLS and GMPLS signaling, and a new subobject to the RECORD_ROUTE
+   object carried on many RSVP messages.  It does not introduce any new
+   direct security issues, and the reader is referred to the security
+   considerations expressed in [RFC2205], [RFC3209], and [RFC3473].
+
+   It is of passing note that any signaling request that indicates the
+   functional preferences or attributes of an MPLS LSP may provide
+   anyone with unauthorized access to the contents of the message with
+   information about the LSP that an administrator may wish to keep
+   secret.  Although this document adds new objects for signaling
+   desired LSP attributes, it does not contribute to this issue, which
+   can only be satisfactorily handled by encrypting the content of the
+   signaling message.
+
+   Similarly, the addition of attribute-recording information to the RRO
+   may reveal information about the status of the LSP and the
+   capabilities of individual LSRs that operators wish to keep secret.
+   The same strategy that applies to other RRO subobjects also applies
+   here.  Note, however, that there is a tension between notifying the
+   head end of the LSP status at transit LSRs, and hiding the existence
+   or identity of the transit LSRs.
+
+13.  Acknowledgements
+
+   Credit to the OSPF Working Group for inspiration from their solution
+   to a similar problem.  Thanks to Rahul Aggarwal for his careful
+   review and support of this work.  Thanks also to Raymond Zhang,
+   Kireeti Kompella, Philip Matthews, Jim Gibson, and Alan Kullberg for
+   their input.  As so often, thanks to John Drake for useful offline
+   discussions.  Thanks to Mike Shand for providing the Routing
+   Directorate review and to Joel Halpern for the General Area review --
+   both picked up on some unclarities.
+
+   Thanks to the OIF for noticing the discrepancy in RFC 4420 that is
+   fixed in this document.  Alfred Hoenes noted several typographical
+   errors.
+
+14.  Changes from RFC 4420 to RFC 5420
+
+   This document obsoletes RFC 4420 [RFC4420].  The only change is in
+   Section 3.  Section 3 describes the semantic of the Length field of
+   the Attributes TLV.
+
+
+
+
+
+
+Farrel, et al.              Standards Track                    [Page 20]
+
+RFC 5420        Attributes for MPLS LSPs Using RSVP-TE     February 2009
+
+
+   Prior to the change, the Length field indicated the length of the
+   Value field only.  After the change, as described in Section 3, the
+   Length field indicates the length of the whole TLV.  This change
+   means that this document is consistent with the subobject format
+   defined in [RFC3209] and the TLV format defined in [RFC3471].
+
+   In addition, the RFC Editor made many editorial changes to improve
+   the text and readability. These changes can be observed by comparing
+   the text of this document with that of [RFC4420].
+
+15.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
+              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
+              Functional Specification", RFC 2205, September 1997.
+
+   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+              Tunnels", RFC 3209, December 2001.
+
+   [RFC3471]  Berger, L., Ed., "Generalized Multi-Protocol Label
+              Switching (GMPLS) Signaling Functional Description", RFC
+              3471, January 2003.
+
+   [RFC3473]  Berger, L., Ed., "Generalized Multi-Protocol Label
+              Switching (GMPLS) Signaling Resource ReserVation
+              Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
+              3473, January 2003.
+
+16.  Informative References
+
+   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
+              Label Switching Architecture", RFC 3031, January 2001.
+
+   [RFC4090]  Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
+              Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
+              May 2005.
+
+   [RFC4206]  Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
+              Hierarchy with Generalized Multi-Protocol Label Switching
+              (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
+
+
+
+
+
+
+
+Farrel, et al.              Standards Track                    [Page 21]
+
+RFC 5420        Attributes for MPLS LSPs Using RSVP-TE     February 2009
+
+
+   [RFC4420]  Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A.
+              Ayyangar, "Encoding of Attributes for Multiprotocol Label
+              Switching (MPLS) Label Switched Path (LSP) Establishment
+              Using Resource ReserVation Protocol-Traffic Engineering
+              (RSVP-TE)", RFC 4420, February 2006.
+
+Authors' Addresses
+
+   Adrian Farrel
+   Old Dog Consulting
+
+   Phone:  +44 (0) 1978 860944
+   EMail:  adrian@olddog.co.uk
+
+
+   Dimitri Papadimitriou
+   Alcatel
+   Fr. Wellesplein 1,
+   B-2018 Antwerpen, Belgium
+
+   Phone:  +32 3 240-8491
+   EMail:  dimitri.papadimitriou@alcatel.be
+
+
+   Jean Philippe Vasseur
+   Cisco Systems, Inc.
+   1414 Massachusetts Avenue
+   Boxborough, MA - 01719
+   USA
+
+   EMail: jpv@cisco.com
+
+
+   Arthi Ayyangar
+   Juniper Networks, Inc.
+   1194 N.Mathilda Ave
+   Sunnyvale, CA 94089
+   USA
+
+   EMail: arthi@juniper.net
+
+
+
+
+
+
+
+
+
+
+
+Farrel, et al.              Standards Track                    [Page 22]
+