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 Attributes Flags TLV. The content
is the same as the Attribute Flags TLV -- that is, it is a series of
bit flags.
There is a one-to-one correspondence between bits in the Attributes
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 4 and must be at least 8.
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.
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 Attributes
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 Attribute 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 Attributes 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.
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 Attributes Flags TLV and the RRO Attributes subobject.
For example, an attribute may be requested using the Attributes 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
Attributes Flags TLV and the RRO Attributes subobject even though the
bit may be irrelevant in either the Attributes 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 those objects
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.
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,
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
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
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.
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
Recommended 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
Recommended 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 = Attributes Flags TLV
- allowed on LSP_ATTRIBUTES object
- allowed on LSP_REQUIRED_ATTRIBUTES object.
New TLV type values may be allocated only by an IETF Consensus
action.
11.3. Attributes 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 Attributes 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.
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.
14. 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.
15. Informative References
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "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.
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
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).