From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5420.txt | 1235 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1235 insertions(+) create mode 100644 doc/rfc/rfc5420.txt (limited to 'doc/rfc/rfc5420.txt') 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] + -- cgit v1.2.3