draft-ietf-mpls-rsvpte-attributes-01.txt   draft-ietf-mpls-rsvpte-attributes-02.txt 
Network Working Group Adrian Farrel (Editor) Network Working Group Adrian Farrel (Editor)
Internet Draft Old Dog Consulting Internet Draft Old Dog Consulting
Category: Standards Track Category: Standards Track
Expires: June 2004 Dimitri Papadimitriou Expires: July 2004 Dimitri Papadimitriou
Alcatel Alcatel
Jean-Philippe Vasseur Jean-Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
Arthi Ayyangar Arthi Ayyangar
Juniper Networks Juniper Networks
December 2003 January 2004
Encoding of Attributes for Multiprotocol Label Switching (MPLS) Encoding of Attributes for Multiprotocol Label Switching (MPLS)
Label Switched Path (LSP) Establishment Using RSVP-TE Label Switched Path (LSP) Establishment Using RSVP-TE
draft-ietf-mpls-rsvpte-attributes-01.txt draft-ietf-mpls-rsvpte-attributes-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC 2026 [RFC2026]. with all provisions of Section 10 of RFC 2026 [RFC2026].
Internet-Drafts are working documents of the Internet Internet-Drafts are working documents of the Internet Engineering
Engineering Task Force (IETF), its areas, and its working Task Force (IETF), its areas, and its working groups. Note that other
groups. Note that other groups may also distribute working groups may also distribute working documents as Internet-Drafts.
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of Internet-Drafts are draft documents valid for a maximum of six months
six months and may be updated, replaced, or obsoleted by and may be updated, replaced, or obsoleted by other documents at any
other documents at any time. It is inappropriate to use time. It is inappropriate to use Internet-Drafts as reference
Internet-Drafts as reference material or to cite them other material or to cite them other than as "work in progress."
than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be The list of Internet-Draft Shadow Directories can be
accessed at http://www.ietf.org/shadow.html. accessed at http://www.ietf.org/shadow.html.
Abstract Abstract
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may
be established using the Resource Reservation Protocol Traffic be established using the Resource Reservation Protocol Traffic
Engineering extensions (RSVP-TE). This protocol includes an object Engineering extensions (RSVP-TE). This protocol includes an object
(the SESSION_ATTRIBUTE object) which carries a flags field used to (the SESSION_ATTRIBUTE object) which carries a flags field used to
indicate options and attributes of the LSP. That flags field has indicate options and attributes of the LSP. That flags field has
eight bits allowing for eight options to be set. eight bits allowing for eight options to be set. Recent proposals in
many documents that extend RSVP-TE have suggested uses for each of
Recent proposals in many documents that extend RSVP-TE for signaling the previously unused bits.
additional features and function for MPLS LSPs have suggested uses
for each of the previously unused bits.
This document defines a new object for RSVP-TE messages that allows This document defines a new object for RSVP-TE messages that allows
the signaling of further attribute bits and also the carriage of the signaling of further attribute bits and also the carriage of
arbitrary attribute parameters to make RSVP-TE easily extensible to arbitrary attribute parameters to make RSVP-TE easily extensible to
support new requirements. Additionally, this document defines a way support new requirements. Additionally, this document defines a way
to record the attributes applied to the LSP on a hop-by-hop basis. 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.
0. Change History 0. Change History
This section to be removed before publication. This section to be removed before publication.
0.1 Changes to 01 Version 0.1 Changes from 01 to 02 Version
- Minor typographical changes.
0.2 Changes from 00 to 01 Version
- Change Attributes Flags TLV to be variable length so that more bits - Change Attributes Flags TLV to be variable length so that more bits
can easily be added in the future. can easily be added in the future.
- Define default behaviors for bits absent from the TLV and for - Define default behaviors for bits absent from the TLV and for
absence of the TLV. absence of the TLV.
- Clarify the IANA requirements for tracking Attributes Flags bits. - Clarify the IANA requirements for tracking Attributes Flags bits.
- Introduce RRO Attibutes Subobject and describe usage. - Introduce RRO Attibutes Subobject and describe usage.
- Move Fast Reroute reference to informational. - Move Fast Reroute reference to informational.
- Update security considerations to handle new RRO subobject - Update security considerations to handle new RRO subobject
- Remove section that explained the need for this document in - Remove section that explained the need for this document in
advance of any definitive bit definitions. advance of any definitive bit definitions.
- Tighten rules for processing LSP_ATTRIBUTES object in cases where - Tighten rules for processing LSP_ATTRIBUTES object in cases where
TLVs are unknown or unsupported. TLVs are unknown or unsupported.
- Clarify that LSP Attributes apply to individual LSPs and not to - Clarify that LSP Attributes apply to individual LSPs and not to
entire sessions. entire sessions.
1. Introduction and Problem Statement 1. Introduction and Problem Statement
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Traffic Engineered Multiprotocol Label Switching (MPLS) Label
[RFC3031] may be established using the RSVP-TE signaling protocol Switched Paths (LSPs) [RFC3031] may be set up using the Path message
[RFC3209]. This protocol uses the Path message to request that a LSP of the RSVP-TE signaling protocol [RFC3209]. The Path message
be set up. The Path message includes the SESSION_ATTRIBUTE object includes the SESSION_ATTRIBUTE object which carries a flags field
which carries a flags field used to indicate desired options and used to indicate desired options and attributes of the LSP.
attributes of the LSP.
The flags field in the SESSION_ATTRIBUTE object has eight bits. Just 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 three of those bits are assigned in [RFC3209]. A further two bits are
assigned in [FRR] for fast re-reroute functionality leaving only assigned in [FRR] for fast re-reroute functionality leaving only
three bits available. Several recent proposals and Internet Drafts three bits available. Several recent proposals and Internet Drafts
have demonstrated that there is a high demand for the use of the 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 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 go forward as RFCs resulting in depletion or near depletion of the
flags field and a consequent difficulty in signaling new options and flags field and a consequent difficulty in signaling new options and
attributes that may be developed in the future. attributes that may be developed in the future.
This document defines a new object for RSVP-TE messages that allows This document defines a new object for RSVP-TE messages that allows
the signaling of further attributes bits. The new object is the signaling of further attributes bits. The new object is
constructed from TLVs, and a new TLV is defined to carry a variable constructed from TLVs, and a new TLV is defined to carry a variable
number of attributes bits. Because of the nature of the TLV number of attributes bits. Because of the nature of the TLV
construction the object is flexible and allows the future definition construction the object is flexible and allows the future definition
of: of:
- further sets of bits flags if further, distinct uses are discovered - further bit flags if further, distinct uses are discovered
- arbitrary options and attributes parameters carried as individual - arbitrary options and attributes parameters carried as individual
TLVs. TLVs.
Note that the LSP Attributes defined in this document are Note that the LSP Attributes defined in this document are
specifically scoped to an LSP. They may be set differently on specifically scoped to an LSP. They may be set differently on
separate LSPs within the same Session. separate LSPs with the same Tunnel ID between the same source and
destination (that is, within the same Session).
It is noted that that some options and attributes do not need to be It is noted that that some options and attributes do not need to be
acted on by all Label Switched Routers (LSRs) along the path of the acted on by all Label Switched Routers (LSRs) along the path of the
LSP. In particular, these options and attributes may apply only to LSP. In particular, these options and attributes may apply only to
key LSRs on the path such as the ingress and egress. Special transit key LSRs on the path such as the ingress and egress. Special transit
LSRs, such as AS Border Routers (ASBRs) may also fall into this LSRs, such as area or AS Border Routers (ABR/ASBRs) may also fall
category. This means that the new options and attributes should be into this category. This means that the new options and attributes
signaled transparently, and only examined at those points that need should be signaled transparently, and only examined at those points
to act on them. that need to act on them.
On the other hand, other options and attributes may require action On the other hand, other options and attributes may require action
at all transit LSRs along the path of the LSP. Inability to support 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 the required attributes by one of those transit LSRs may require the
LSR to refuse the establishment of the LSP. LSR to refuse the establishment of the LSP.
These considerations are particularly important in the context These considerations are particularly important in the context of
backwards compatibility. In general, it should be possible to provide backwards compatibility. In general, it should be possible to provide
new MPLS services across a legacy network without upgrading those new MPLS services across a legacy network without upgrading those
LSRs that do not need to participate actively in the new services. LSRs that do not need to participate actively in the new services.
RSVP includes a way for unrecognized objects to be forwarded by Note that options already specified for the SESSION_ATTRIBUTE object
transit nodes without them refusing the protocol message and with the in pre-existing RFCs are not migrated to the new mechanisms described
objects being stripped from the protocol message (see [RFC2205] in this documnet.
section 3.10). This extends to RSVP-TE and provides a good way to
ensure that only those LSRs that understand a particular object RSVP includes a way for unrecognized objects to be transparently
examine it. forwarded by transit nodes without them refusing the incoming
protocol messages and with 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 This document distinguishes between options and attributes that are
only required at key LSRs along the path of the LSP, and those that 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 must be acted on by every LSR along the LSP. Two LSP Attributes
objects are defined in this document: the first may be passed objects are defined in this document: the first may be passed
transparently by LSRs that do not recognize it, the second must cause transparently by LSRs that do not recognize it, the second must cause
LSP setup failure with the generation of a PathErr message if an LSR LSP setup failure with the generation of a PathErr message with an
does not recognize it. appropriate Error Code if an LSR does not recognize it.
Comments on this document should be made direct to the MPLS mailing
list at mpls@uu.net.
1.1 Applicability to Generalized MPLS 1.1 Applicability to Generalized MPLS
The RSVP-TE signaling protocol also forms the basis of a signaling The RSVP-TE signaling protocol also forms the basis of a signaling
protocol for Generalized MPLS (GMPLS) as described in [RFC3471] and protocol for Generalized MPLS (GMPLS) as described in [RFC3471] and
[RFC3473]. The extensions described in this document are intended to [RFC3473]. The extensions described in this document are intended to
be equally applicable to MPLS and GMPLS. be equally applicable to MPLS and GMPLS.
1.2 A Rejected Alternate Solution 1.2 A Rejected Alternate Solution
A rejected alternate solution was to define a new C-Type for the A rejected alternate solution was to define a new C-Type for the
existing SESSION_ATTRIBUTE object. This new C-Type could allow a existing SESSION_ATTRIBUTE object. This new C-Type could allow a
larger Flags field and address the immediate problem. larger Flags field and address the immediate problem.
This solution was rejected because: This solution was rejected because:
- A new C-Type is not backward compatible with deployed
- A C-Type is not backward compatible with deployed implementations implementations that expect to see a C-Type of 1 or 7. It is
that expect to see a C-Type of 1 or 7. It is important that any important that any solution be capable of carrying new attributes
solution be capable of carrying new attributes transparently transparently across legacy LSRs if those LSRs are not required to
across legacy LSRs if those LSRs are not required to act on the act on the attributes.
attributes.
- Support for arbitrary attributes parameters through TLVs would - Support for arbitrary attributes parameters through TLVs would
have meant a significant change of substance to the existing have meant a significant change of substance to the existing
object. object.
2. Terminology 2. Terminology
This document uses terminology from the MPLS architecture document This document uses terminology from the MPLS architecture document
[RFC3031] and from the RSVP-TE protocol specification [RFC3209] which [RFC3031] and from the RSVP-TE protocol specification [RFC3209] which
inherits from the RSVP specification [RFC2205]. inherits from the RSVP specification [RFC2205].
skipping to change at line 230 skipping to change at line 234
Value Value
The data for the TLV padded as described above. The data for the TLV padded as described above.
3.1 Attributes Flags TLV 3.1 Attributes Flags TLV
This document defines only one TLV type value. Type 1 indicates the This document defines only one TLV type value. Type 1 indicates the
Attributes Flags TLV. Other TLV types may be defined in future with Attributes Flags TLV. Other TLV types may be defined in future with
type values assigned by IANA. type values assigned by IANA.
The Attibutes Flags TLV may be present in an LSP_ATTRIBUTES object The Attributes Flags TLV may be present in an LSP_ATTRIBUTES object
and/or an LSP_REQUIRED_ATTRIBUTES object. The bits in the TLV and/or an LSP_REQUIRED_ATTRIBUTES object. The bits in the TLV
represent the same attributes regardeless of which object carries the represent the same attributes regardless of which object carries the
TLV. Documents that define individual bits MUST specify whether the TLV. Documents that define individual bits MUST specify whether the
bit may be set in one object or the other, or both. 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 Attributes Flags TLV value field is a variable length array of The Attributes Flags TLV value field is a variable length array of
flags numbered from the MSB as bit zero. The length field for this flags numbered from the MSB as bit zero. The length field for this
TLV is always a multiple of 4 bytes, regardless of the number bits TLV is always a multiple of 4 bytes, regardless of the number bits
carried. carried.
Unassigned bits are considered as reserved and MUST be set to zero Unassigned bits are considered as reserved and MUST be set to zero
on transmission and ignored on receipt. Bits not contained in the 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 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_ because it is not contained in the LSP_ATTRIBUTES or LSP_REQUIRED_
ATTRIBUTES object, or because those objects are themselves absent, ATTRIBUTES object, or because those objects are themselves absent,
all processing MUST be performed as though the bits were present all processing MUST be performed as though the bits were present
and set to zero. and set to zero.
No bits are defined in this document. The assignment of bits is No bits are defined in this document. The assignment of bits is
managed by IANA. managed by IANA.
4. LSP_ATTRIBUTES Object 4. LSP_ATTRIBUTES Object
skipping to change at line 265 skipping to change at line 271
support of an LSP, or to indicate the nature or use of an LSP where 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. 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 Specifically, if an LSR does not support the object, it forwards it
unexamined and unchanged. This facilitates the exchange of attributes unexamined and unchanged. This facilitates the exchange of attributes
across legacy networks that do not support this new object. across legacy networks that do not support this new object.
This object effectively extends the flags field in the SESSION_ This object effectively extends the flags field in the SESSION_
ATTRIBUTE object and allows for the future inclusion of more complex ATTRIBUTE object and allows for the future inclusion of more complex
objects through TLVs. 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_ATTIBUTES object.
The LSP_ATTRIBUTES object class is TBD of the form 11bbbbbb. This The LSP_ATTRIBUTES object class is TBD of the form 11bbbbbb. This
C-Num value (see section 7) ensures that LSRs that do not recognize C-Num value (see section 7) ensures that LSRs that do not recognize
the object pass it on transparently. the object pass it on transparently.
One C-Type is defined, C-Type = 1 for LSP Attributes. One C-Type is defined, C-Type = 1 for LSP Attributes.
This object is optional and may be placed on Path messages to convey This object is optional and may be placed on Path messages to convey
additional information about the desired attributes of the LSP. additional information about the desired attributes of the LSP.
4.1 Format 4.1 Format
skipping to change at line 294 skipping to change at line 304
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Attributes TLVs are encoded as described in section 3. The Attributes TLVs are encoded as described in section 3.
4.2 Generic Processing Rules 4.2 Generic Processing Rules
An LSR that does not support this object will pass it on unaltered An LSR that does not support this object will pass it on unaltered
because of the C-Num. because of the C-Num.
An LSR that does support this object, but does not recognize a TLV An LSR that does support this object, but does not recognize a TLV
type code carried in this object MUST pass the TLV on un-altered type code carried in this object MUST pass the TLV on unaltered
in the LSP_ATTRIBUTES object that it places in the Path message in the LSP_ATTRIBUTES object that it places in the Path message
that it sends downstream. that it sends downstream.
An LSR that does support this object and recognizes a TLV but does 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 not support the attribute defined by the TLV MUST act as specified in
the document that defines the TLV. the document that defines the TLV.
An LSR that supports the Attributes Flags TLV, but does not An LSR that supports the Attributes Flags TLV, but does not
recognize a bit set in the Attributes Flags TLV MUST forward the recognize a bit set in the Attributes Flags TLV MUST forward the
TLV unchanged. TLV unchanged.
An LSR that supports the Attributes Flags TLV and recognizes a bit 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 that is set but does not support the indicated attribute MUST act as
specified in the document that defines the bit. specified in the document that defines the bit.
5. LSP_REQUIRED_ATTRIBUTES Object 5. LSP_REQUIRED_ATTRIBUTES Object
The LSP_REQUIRED_ATTRIBUTES object is used to signal attributes The LSP_REQUIRED_ATTRIBUTES object is used to signal attributes
required in support of a LSP, or to indicate the nature or use of required in support of an LSP, or to indicate the nature or use of
a LSP where that information MUST be inspected at each transit LSR. an LSP where that information MUST be inspected at each transit LSR.
Specifically, each transit LSR MUST examine the attributes in the Specifically, each transit LSR MUST examine the attributes in the
LSP_REQUIRED_ATTRIBUTES object and MUST NOT forward the object LSP_REQUIRED_ATTRIBUTES object and MUST NOT forward the object
transparently. transparently.
This object effectively extends the flags field in the SESSION_ This object effectively extends the flags field in the SESSION_
ATTRIBUTE object and allows for the future inclusion of more complex ATTRIBUTE object and allows for the future inclusion of more complex
objects through TLVs. It complements the LSP_ATTRIBUTES object. objects through TLVs. It complements the LSP_ATTRIBUTES object.
The LSP_REQUIRED_ATTRIBUTES object class is TBD of the form 0bbbbbbb. The LSP_REQUIRED_ATTRIBUTES object class is TBD of the form 0bbbbbbb.
This C-Num value (see section 7) ensures that LSRs that do not This C-Num value ensures that LSRs that do not
recognize the object reject the LSP setup effectively saying that recognize the object reject the LSP setup effectively saying that
they do not support the attributes requested. This means that this they do not support the attributes requested. This means that this
object should only be used for attributes that require support at object SHOULD only be used for attributes that require support at
some transit LSRs and so require examination at all transit LSRs. See some transit LSRs and so require examination at all transit LSRs. See
section 4 for how end-to-end and selective attributes are signaled. section 4 for how end-to-end and selective attributes are signaled.
One C-Type is defined, C-Type = 1 for LSP Required Attributes. 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 This object is optional and may be placed on Path messages to convey
additional information about the desired attributes of the LSP. additional information about the desired attributes of the LSP.
5.1 Format 5.1 Format
skipping to change at line 386 skipping to change at line 396
path of the LSP. For example, an attribute may be requested in 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 LSP_ATTRIBUTES object such that LSRs that do not support the object
are not required to support the attribute or provide the requested 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 function. In this case, it may be useful to the ingress LSR to know
which LSRs acted on the request and which ignored it. which LSRs acted on the request and which ignored it.
Additionally, there may be other qualities that need to be reported Additionally, there may be other qualities that need to be reported
on a hop-by-hop basis. These are currently indicated in the Flags on a hop-by-hop basis. These are currently indicated in the Flags
field of RRO subobjects. Since there are only eight bits available field of RRO subobjects. Since there are only eight bits available
in this field, and since some are already assigned and there is also in this field, and since some are already assigned and there is also
likely to an increase in allocations in new documents, there is a likely to be an increase in allocations in new documents, there is a
need for some other method to report per-hop attributes. need for some other method to report per-hop attributes.
6.2 RRO Attributes Subobject 6.2 RRO Attributes Subobject
The RRO Attributes Subobject may be carried in the RECORD_ROUTE The RRO Attributes Subobject may be carried in the RECORD_ROUTE
object if it is present. The subobject uses the standard format of object if it is present. The subobject uses the standard format of
an RRO subobject. an RRO subobject.
The length is variable as for the Attributes Flags TLV. The content 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 is the same as the Attribute Flags TLV - that is, it is a series of
skipping to change at line 433 skipping to change at line 443
Attribute Flags Attribute Flags
The attribute flags recorded for the specific hop. The attribute flags recorded for the specific hop.
6.3 Procedures 6.3 Procedures
6.3.1 Subobject Presence Rules 6.3.1 Subobject Presence Rules
The Attributes subobject is pushed onto the RECORD_ROUTE object The Attributes subobject is pushed onto the RECORD_ROUTE object
immediately prior to pushing on the node's IP address. Thus, if immediately prior to pushing the node's IP address or link
label recording is being used, the Attributes subobject SHOULD be identifier. Thus, if label recording is being used, the Attributes
pushed onto the RECORD_ROUTE object after the Record Label subobject SHOULD be pushed onto the RECORD_ROUTE object after the
subobject(s). Record Label subobject(s).
A node MUST NOT push on a Attributes subobject without also A node MUST NOT push an Attributes subobject on to the RECORD_ROUTE
pushing on an IPv4 or IPv6 subobject. object without also pushing an IPv4, IPv6 or Unnumbered Interface ID
subobject.
This means that an Attributes subobject is bound to the LSR This means that an Attributes subobject is bound to the LSR
identified by the IP address subobject found in the RRO immediately identified by the subobject found in the RRO immediately before the
before the Attributes subobject. Attributes subobject.
If the newly added subobject causes the RRO to be too big to fit in a If the new subobject causes the RRO to be too big to fit in a Path
Path (or Resv) message, the processing SHALL be as described in (or Resv) message, the processing MUST be as described in [RFC3209].
[RFC3209].
If more than one Attributes subobject is found between a pair of If more than one Attributes subobject is found between a pair of
subobjects that identify LSRs, only the first one found SHALL have subobjects that identify LSRs, only the first one found (that is, the
any meaning within the context of this document. All such subobjects nearest to the stop of the stack) SHALL have any meaning within the
shall be forwarded unmodified by transit LSRs. context of this document. All such subobjects MUST be forwarded
unmodified by transit LSRs.
6.3.2 Reporting Compliance with LSP Attributes 6.3.2 Reporting Compliance with LSP Attributes
To report compliance with an attribute requested in the Attributes To report compliance with an attribute requested in the Attributes
Flags TLV, an LSR MAY set the corresponding bit (see section 7) in Flags TLV, an LSR MAY set the corresponding bit (see section 7) in
the Attributes subobject. To report non-compliance, an LSR MAY clear the Attributes subobject. To report non-compliance, an LSR MAY clear
the corresponding bit in the Attributes subobject. the corresponding bit in the Attributes subobject.
The requirement to report compliance MUST be specified in the The requirement to report compliance MUST be specified in the
document that defines the usage of any bit. This will reduce to a document that defines the usage of any bit. This will reduce to a
skipping to change at line 477 skipping to change at line 488
To report a per-hop attribute, an LSR sets the appropriate bit in the To report a per-hop attribute, an LSR sets the appropriate bit in the
Attributes subobject. Attributes subobject.
The requirement to report a per-hop attribute MUST be specified in The requirement to report a per-hop attribute MUST be specified in
the document that defines the usage of the bit. the document that defines the usage of the bit.
6.3.4 Default Behavior 6.3.4 Default Behavior
By default all bits in an Attibutes subobject SHOULD be set to zero. By default all bits in an Attibutes subobject SHOULD be set to zero.
If an Attribute subobject is not long enough to include a specific If a received Attribute subobject is not long enough to include a
bit, the bit MUST be assumed to be set to zero. 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 If the RRO subobject is not present for a hop in the LSP, all bits
MUST be assumed to be set to zero. MUST be assumed to be set to zero.
7. Summary of Attribute Bit Allocation 7. Summary of Attribute Bit Allocation
This document defines two uses of per-LSP attribute flag bit fields. This document defines two uses of per-LSP attribute flag bit fields.
The bit numbering in the Attributes Flags TLV and the RRO Attributes The bit numbering in the Attributes Flags TLV and the RRO Attributes
subobject is identical. That is the same attribute is indicated by subobject is identical. That is, the same attribute is indicated by
the same bit in both places. This means that only a single registry the same bit in both places. This means that only a single registry
of bits is maintained. of bits is maintained.
The consequence is a degree of clarity in implementation and The consequence is a degree of clarity in implementation and
registration. registration.
Note, however, that it is not always the case that a bit will be used 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. in both the Attributes Flags TLV and the RRO Attributes subobject.
For example, an attribute may be requested using the Attributes Flags For example, an attribute may be requested using the Attributes Flags
TLV, but there is no requirement to report the handling of the TLV, but there is no requirement to report the handling of the
attribute on a hop-by-hop basis. Conversely, there may be a 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, requirement to report the attributes of an LSP on a hop-by-hop basis,
but there is no corresponding request attribute. but there is no corresponding request attribute.
In these cases, a single bit number is still assigned for both the In these cases, a single bit number is still assigned for both the
Attributes Flags TLV and the RRO Attributes subobject. The document Attributes Flags TLV and the RRO Attributes subobject even though the
that defines the usage of the new bit MUST state in which places bit may be irrelevant in either the Attributes Flags or the RRO
it is used and MUST handle a default setting of zero. 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.
8. Message Formats 8. Message Formats
The LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object MAY The LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object MAY
be carried in a Path message. be carried in a Path message.
The order of objects in RSVP-TE messages is recommended, but The order of objects in RSVP-TE messages is recommended, but
implementations must be capable of receiving the objects in any implementations must be capable of receiving the objects in any
meaningful order. The LSP_ATTRIBUTES object and LSP_REQUIRED_ meaningful order. The LSP_ATTRIBUTES object and LSP_REQUIRED_
ATTRIBUTES objects are RECOMMENDED to be placed immediately after the ATTRIBUTES objects are RECOMMENDED to be placed immediately after the
SESSION_ATTRIBUTE object if it is present, or otherwise immediately SESSION_ATTRIBUTE object if it is present, or otherwise immediately
after the LABEL_REQUEST object. after the LABEL_REQUEST object.
If both the LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES If both the LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES
object are present, the LSP_REQUIRED_ATTRIBUTES object is RECOMMENDED object are present, the LSP_REQUIRED_ATTRIBUTES object is RECOMMENDED
to be placed first. to be placed first.
LSRs should be prepared to receive these objects in any order in any LSRs SHOULD be prepared to receive these objects in any order in any
position within a Path message. Subsequent instances of these objects position within a Path message. Subsequent instances of these objects
within a Path message SHOULD be ignored. within a Path message SHOULD be ignored and those objects MUST be
forwarded unchanged transparently.
9. IANA Considerations 9. IANA Considerations
9.1 New RSVP C-Nums and C-Types 9.1 New RSVP C-Nums and C-Types
Two new RSVP C-Nums are defined in this document and should be Two new RSVP C-Nums are defined in this document and should be
assigned by IANA. assigned by IANA.
o LSP_ATTRIBUTES object o LSP_ATTRIBUTES object
skipping to change at line 569 skipping to change at line 584
Recommended C-Type value 1. Recommended C-Type value 1.
9.2 New TLV Space 9.2 New TLV Space
The two new objects referenced above are constructed from TLVs. Each 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 TLV includes a 16-bit type identifier (the T-field). The same T-field
values are applicable to both objects. values are applicable to both objects.
IANA is requested to manage TLV type identifiers as follows: IANA is requested to manage TLV type identifiers as follows:
- TLV Type - TLV Type (T-field value)
- TLV Name - TLV Name
- Whether allowed on LSP_ATTRIBUTES object - Whether allowed on LSP_ATTRIBUTES object
- Whether allowed on LSP_REQUIRED_ATTRIBUTES object. - Whether allowed on LSP_REQUIRED_ATTRIBUTES object.
This document defines one TLV type as follows: This document defines one TLV type as follows:
- TLV Type = 1 - TLV Type = 1
- TLV Name = Attributes Flags TLV - TLV Name = Attributes Flags TLV
- allowed on LSP_ATTRIBUTES object - allowed on LSP_ATTRIBUTES object
- allowed on LSP_REQUIRED_ATTRIBUTES object. - allowed on LSP_REQUIRED_ATTRIBUTES object.
skipping to change at line 601 skipping to change at line 616
Each bit should be tracked with the following qualities: Each bit should be tracked with the following qualities:
- Bit number - Bit number
- Defining RFC - Defining RFC
- Name of bit - Name of bit
- Whether there is meaning in the Attibute Flags TLV (yes/no) - Whether there is meaning in the Attibute Flags TLV (yes/no)
- Whether there is meaning in the RRO Attributes Subobject (yes/no). - Whether there is meaning in the RRO Attributes Subobject (yes/no).
Note that this means that all bits in the Attribute Flags TLV and the Note that this means that all bits in the Attribute Flags TLV and the
RRO Attributes Subobject use the same bit number regardless of RRO Attributes Subobject use the same bit number regardless of
whether they are used in one or both places. Thus, only one list of whether they are used in one or both places. Thus, only one list of
bits is required to be maintained. bits is required to be maintained. (It would be meaningless in the
context of this document for a bit to have no meaning in neither the
Attribute Flags TLV nor the RRO Attributes Subobject.)
9.4 SESSION_ATTRIBUTE Flags Field 9.4 SESSION_ATTRIBUTE Flags Field
This document does not make any alterations to the definition of the This document does not make any alterations to the definition of the
existing SESSION_ATTRIBUTE object nor to the definition of meanings existing SESSION_ATTRIBUTE object nor to the definition of meanings
assigned to the flags in the Flags field of that object. These flags assigned to the flags in the Flags field of that object. These flags
are assigned meanings in various other RFCs and Internet Drafts. are assigned meanings in various other RFCs and Internet Drafts.
It is suggested that IANA manage the allocation of meaning to the It is suggested that IANA manage the allocation of meaning to the
bits in the Flags field of the SESSION_ATTRIBUTE object to prevent bits in the Flags field of the SESSION_ATTRIBUTE object to prevent
skipping to change at line 660 skipping to change at line 677
here. Note, however, that there is a tension between notifying the here. Note, however, that there is a tension between notifying the
head end of the LSP status at transit LSRs, and hiding the existence head end of the LSP status at transit LSRs, and hiding the existence
or identity of the transit LSRs. or identity of the transit LSRs.
11. Acknowledgements 11. Acknowledgements
Credit to the OSPF Working Group for inspiration from their solution Credit to the OSPF Working Group for inspiration from their solution
to a similar problem. to a similar problem.
Thanks to Rahul Aggarwal for his careful review and support of this Thanks to Rahul Aggarwal for his careful review and support of this
work. Thanks also to Raymond Zhang, Kireeti Kompella and Philip work. Thanks also to Raymond Zhang, Kireeti Kompella, Philip Matthews
Matthews for their input. and Jim Gibson for their input.
12. Intellectual Property Consideration 12. Intellectual Property Consideration
The IETF takes no position regarding the validity or scope The IETF takes no position regarding the validity or scope
of any intellectual property or other rights that might be of any intellectual property or other rights that might be
claimed to pertain to the implementation or use of the claimed to pertain to the implementation or use of the
technology described in this document or the extent to technology described in this document or the extent to
which any license under such rights might or might not be which any license under such rights might or might not be
available; neither does it represent that it has made any available; neither does it represent that it has made any
effort to identify any such rights. Information on the effort to identify any such rights. Information on the
skipping to change at line 718 skipping to change at line 735
14. Informative References 14. Informative References
[RFC2026] Bradner, S., "The Internet Standards Process [RFC2026] Bradner, S., "The Internet Standards Process
-- Revision 3", RFC 2026, October 1996. -- Revision 3", RFC 2026, October 1996.
[RFC3031] Rosen, E., Viswanathan, A., and Callon, R., [RFC3031] Rosen, E., Viswanathan, A., and Callon, R.,
"Multiprotocol Label Switching "Multiprotocol Label Switching
Architecture", RFC 3031, January 2001. Architecture", RFC 3031, January 2001.
[INTER-AS] Vasseur, JP., Zhang, R., "Inter-AS MPLS Traffic [INTER-AS] Vasseur, JP., Zhang, R., "Inter-AS MPLS Traffic
Engineering", <draft-vasseur-inter-as-te-01.txt>, Engineering", <draft-vasseur-inter-as-te-03.txt>,
Internet Draft, work in progress. Internet Draft, work in progress.
[FRR] Pan, P. (Ed.), "Fast Reroute Extensions to RSVP-TE for [FRR] Pan, P. (Ed.), "Fast Reroute Extensions to RSVP-TE for
LSP Tunnels", <draft-ietf-mpls-rsvp-lsp-fastreroute-03 LSP Tunnels", <draft-ietf-mpls-rsvp-lsp-fastreroute-03
.txt>, Internet Draft, work in progress. .txt>, Internet Draft, work in progress.
[OSPF-CAPS] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., [OSPF-CAPS] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S.,
Vasseur, JP., "Extensions to OSPF for Advertising Vasseur, JP., "Extensions to OSPF for Advertising
Optional Router Capabilities", <draft-ietf-ospf-cap- Optional Router Capabilities", <draft-ietf-ospf-cap-
00.txt>, Internet Draft, work in progress. 00.txt>, Internet Draft, work in progress.
skipping to change at line 750 skipping to change at line 767
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
Dimitri Papadimitriou (Alcatel) Dimitri Papadimitriou (Alcatel)
Fr. Wellesplein 1, Fr. Wellesplein 1,
B-2018 Antwerpen, Belgium B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491 Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be EMail: dimitri.papadimitriou@alcatel.be
Jean Philippe Vasseur Jean Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
300 Apollo Drive
Chelmsford, MA 01824
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough , MA - 01719 Boxborough , MA - 01719
USA USA
EMail: jpv@cisco.com EMail: jpv@cisco.com
Arthi Ayyangar Arthi Ayyangar
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N.Mathilda Ave 1194 N.Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
EMail: arthi@juniper.net EMail: arthi@juniper.net
16. Full Copyright Statement 16. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Copyright (C) The Internet Society (2004). All Rights
Reserved. Reserved.
This document and translations of it may be copied and This document and translations of it may be copied and
furnished to others, and derivative works that comment on furnished to others, and derivative works that comment on
or otherwise explain it or assist in its implementation may or otherwise explain it or assist in its implementation may
be prepared, copied, published and distributed, in whole or be prepared, copied, published and distributed, in whole or
in part, without restriction of any kind, provided that the in part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on above copyright notice and this paragraph are included on
all such copies and derivative works. However, this all such copies and derivative works. However, this
document itself may not be modified in any way, such as by document itself may not be modified in any way, such as by
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/