Request for Comments: 4420 Old Dog Consulting
Updates: 3209, 3473 D. Papadimitriou
Category: Standards Track Alcatel
J.-P. Vasseur
Cisco Systems, Inc.
A. Ayyangar
Juniper Networks
February 2006
Encoding of Attributes for Multiprotocol Label Switching (MPLS)
Label Switched Path (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) The Internet Society (2006).
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.
Table of Contents
1. Introduction and Problem Statement ..............................3
1.1. Applicability to Generalized MPLS ..........................4
1.2. A Rejected Alternate Solution ..............................4
2. Terminology .....................................................5
3. Attributes TLVs .................................................5
3.1. Attributes Flags TLV .......................................6
4. LSP_ATTRIBUTES Object ...........................................6
4.1. Format .....................................................7
4.2. Generic Processing Rules for Path Messages .................7
4.3. Generic Processing Rules for Resv Messages .................8
5. LSP_REQUIRED_ATTRIBUTES Object ..................................9
5.1. Format .....................................................9
5.2. Generic Processing Rules ...................................9
6. Inheritance Rules ..............................................10
7. Recording Attributes Per LSP ...................................11
7.1. Requirements ..............................................11
7.2. RRO Attributes Subobject ..................................11
7.3. Procedures ................................................12
7.3.1. Subobject Presence Rules ...........................12
7.3.2. Reporting Compliance with LSP Attributes ...........12
7.3.3. Reporting Per-Hop Attributes .......................13
7.3.4. Default Behavior ...................................13
8. Summary of Attribute Bit Allocation ............................13
9. Message Formats ................................................14
10. Guidance for Key Application Scenarios ........................14
10.1. Communicating to Egress LSRs .............................15
10.2. Communicating to Key Transit LSRs ........................15
10.3. Communicating to All LSRs ................................16
11. IANA Considerations ...........................................16
11.1. New RSVP C-Nums and C-Types ..............................16
11.2. New TLV Space ............................................17
11.3. Attributes Flags .........................................17
11.4. New Error Codes ..........................................18
11.5. New Record Route Subobject Identifier ....................18
12. Security Considerations .......................................18
13. Acknowledgements ..............................................19
14. Normative References ..........................................19
15. Informative References ........................................19
1. Introduction and Problem Statement
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.
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, and 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.
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.
Length
The length of the Value field in bytes. Thus, if no Value
field is present the Length field contains the value zero.
Each Value field must be zero padded at the end to take it up
to a four byte boundary -- the padding is not included in the
length so that a one byte value would be encoded in an eight
byte TLV with Length field set to one.
Value
The data for the TLV padded as described above.
3.1. Attributes Flags TLV
This document defines only one TLV type value. Type 1 indicates the
Attributes Flags TLV. Other TLV types may be defined in the future
with type values assigned by IANA (see Section 11.2).
The Attributes 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 or 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 4 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).
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 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.
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 Attributes Flags TLV, but does not recognize
a bit set in the Attributes Flags TLV, MUST forward the TLV
unchanged.
An LSR that supports the Attributes 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.
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.
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 Attributes 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 Attributes Flags.
An LSR that recognizes an attribute (however encoded), but that 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
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 Attributes 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