draft-ietf-mpls-rsvpte-attributes-00.txt   draft-ietf-mpls-rsvpte-attributes-01.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: May 2004 Dimitri Papadimitriou Expires: June 2004 Dimitri Papadimitriou
Alcatel Alcatel
Jean-Philippe Vasseur Jean-Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
November 2003 Arthi Ayyangar
Juniper Networks
December 2003
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-00.txt draft-ietf-mpls-rsvpte-attributes-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full This document is an Internet-Draft and is in full conformance
conformance with all provisions of Section 10 of RFC 2026 with all provisions of Section 10 of RFC 2026 [RFC2026].
[RFC2026].
Internet-Drafts are working documents of the Internet Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working groups. Note that other 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 and may be updated, replaced, or obsoleted by six months and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use other documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other Internet-Drafts as reference material or to cite them other
skipping to change at line 56 skipping to change at line 58
(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 for signaling Recent proposals in many documents that extend RSVP-TE for signaling
additional features and function for MPLS LSPs have suggested uses additional features and function for MPLS LSPs have suggested uses
for each of the previously unused bits. 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. This makes RSVP-TE easily extensible arbitrary attribute parameters to make RSVP-TE easily extensible to
to support new requirements. support new requirements. Additionally, this document defines a way
to record the attributes applied to the LSP on a hop-by-hop basis.
0. Change History
This section to be removed before publication.
0.1 Changes to 01 Version
- Change Attributes Flags TLV to be variable length so that more bits
can easily be added in the future.
- Define default behaviors for bits absent from the TLV and for
absence of the TLV.
- Clarify the IANA requirements for tracking Attributes Flags bits.
- Introduce RRO Attibutes Subobject and describe usage.
- Move Fast Reroute reference to informational.
- Update security considerations to handle new RRO subobject
- Remove section that explained the need for this document in
advance of any definitive bit definitions.
- Tighten rules for processing LSP_ATTRIBUTES object in cases where
TLVs are unknown or unsupported.
- Clarify that LSP Attributes apply to individual LSPs and not to
entire sessions.
1. Introduction and Problem Statement 1. Introduction and Problem Statement
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
[RFC3031] may be established using the RSVP-TE signaling protocol [RFC3031] may be established using the RSVP-TE signaling protocol
[RFC3209]. This protocol uses the Path message to request that a LSP [RFC3209]. This protocol uses the Path message to request that a LSP
be set up. The Path message includes the SESSION_ATTRIBUTE object be set up. The Path message includes the SESSION_ATTRIBUTE object
which carries a flags field used to indicate desired options and which carries a flags field used to indicate desired options and
attributes of the LSP. attributes of the LSP.
skipping to change at line 80 skipping to change at line 104
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 up to thirty constructed from TLVs, and a new TLV is defined to carry a variable
two new 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 thirty two bits if more flags are needed to carry - further sets of bits flags if further, distinct uses are discovered
yet more attributes
- 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
specifically scoped to an LSP. They may be set differently on
separate LSPs 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 AS Border Routers (ASBRs) may also fall into this
category. This means that the new options and attributes should be category. This means that the new options and attributes should be
signaled transparently, and only examined at those points that need signaled transparently, and only examined at those points that need
to act on them. 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
skipping to change at line 151 skipping to change at line 178
- A C-Type is not backward compatible with deployed implementations - A 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 that expect to see a C-Type of 1 or 7. It is important that any
solution be capable of carrying new attributes transparently solution be capable of carrying new attributes transparently
across legacy LSRs if those LSRs are not required to act on the across legacy LSRs if those LSRs are not required to 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.
1.3 Protocol Developments Without an Explicit Need
[This section to be removed if this draft proceeds towards an RFC.
References in this section are not intended to be normative.]
It is unusual and inadvised for the IETF to accept a speculative
change to a protocol without an explicit need. That is, in this case,
although there is an obvious problem identified, there is no existing
Working Group proposal that requires further option bits. For today,
the existing protocol objects are adequate.
There are, however, several Internet Drafts that propose additional
attributes associated with LSP setup. These include [CRANKBACK],
[REOPT] and [INTER-AS]. In view of the likelihood of one or more of
these drafts advancing to RFC, and considering the probable
requirement to be able to signal further options and attributes for
other purposes in the very near future, it is proposed that this
document be debated within the MPLS Working Group so that a solution
will be available should the need arise.
Further, the lack of a considered approach to handle the shortage of
SESSION_ATTRIBUTE flags might give rise to a range of diverse
solutions each developed within the context of a single protocol
extension. Clearly a single coherent solution is better.
[This section to be removed if this draft proceeds towards an RFC.]
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].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [6]. document are to be interpreted as described in RFC2119 [6].
skipping to change at line 230 skipping to change at line 230
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 Attributes Flags TLV value field is a 32 bit array of flags The Attibutes Flags TLV may be present in an LSP_ATTRIBUTES object
numbered from the MSB as bit zero. The length field for this TLV is and/or an LSP_REQUIRED_ATTRIBUTES object. The bits in the TLV
set to 4. represent the same attributes regardeless 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.
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
TLV is always a multiple of 4 bytes, regardless of the number bits
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. on transmission and ignored on receipt. 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.
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
The LSP_ATTRIBUTES object is used to signal attributes required in 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 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
skipping to change at line 282 skipping to change at line 294
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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, or recognizes the TLV but does not type code carried in this object MUST pass the TLV on un-altered
support the attribute MUST act as specified in the document that in the LSP_ATTRIBUTES object that it places in the Path message
defines the TLV. 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 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
object 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 a LSP, or to indicate the nature or use of
a LSP where that information MUST be inspected at each transit LSR. a LSP where that information MUST be inspected at each transit LSR.
skipping to change at line 322 skipping to change at line 338
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
LSP_REAQUIRED_ATTRIBUTES class = TBD, C-Type = 1 LSP_REQUIRED_ATTRIBUTES class = TBD, C-Type = 1
0 1 2 3 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 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 // // Attributes TLVs //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Attributes TLVs are encoded as described in section 3. The Attributes TLVs are encoded as described in section 3.
skipping to change at line 348 skipping to change at line 364
Object Class". Object Class".
An LSR that does not recognize a TLV type code carried in this object 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 MUST reject the Path message using a PathErr with Error Code
"Unknown Attributes TLV" and Error Value set to the value of the "Unknown Attributes TLV" and Error Value set to the value of the
unknown TLV type code. unknown TLV type code.
An LSR that does not recognize a bit set in the Attributes Flags 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 TLV MUST reject the Path message using a PathErr with Error Code
"Unknown Attributes Bit" and Error Value set to the bit number of "Unknown Attributes Bit" and Error Value set to the bit number of
the unknown bit in the Attributes Flags (that is a number between 0 the unknown bit in the Attributes Flags.
and 32).
An LSR that recognizes an attribute, however encoded, but which does An LSR that recognizes an attribute, however encoded, but which does
not support that attribute MUST act according to the behavior not support that attribute MUST act according to the behavior
specified in the document that defines that specific attribute. specified in the document that defines that specific attribute.
6. Message Formats 6. Recording Attributes
6.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 an increase in allocations in new documents, there is a
need for some other method to report per-hop attributes.
6.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 correspondance 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
0x?? TBD RRO Attribute Subobject
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.
6.3 Procedures
6.3.1 Subobject Presence Rules
The Attributes subobject is pushed onto the RECORD_ROUTE object
immediately prior to pushing on the node's IP address. 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 on a Attributes subobject without also
pushing on an IPv4 or IPv6 subobject.
This means that an Attributes subobject is bound to the LSR
identified by the IP address subobject found in the RRO immediately
before the Attributes subobject.
If the newly added subobject causes the RRO to be too big to fit in a
Path (or Resv) message, the processing SHALL be as described in
[RFC3209].
If more than one Attributes subobject is found between a pair of
subobjects that identify LSRs, only the first one found SHALL have
any meaning within the context of this document. All such subobjects
shall be forwarded unmodified by transit LSRs.
6.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 7) 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.
6.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.
6.3.4 Default Behavior
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
bit, the bit MUST be assumed to be 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.
7. 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. 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
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.
7. IANA Considerations 9. IANA Considerations
7.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
The C-Num should be of the form 11bbbbbb so that LSRs that do not The C-Num should be of the form 11bbbbbb so that LSRs that do not
recognize the object will ignore the object but forward it, recognize the object will ignore the object but forward it,
unexamined and unmodified, in all messages resulting from this unexamined and unmodified, in all messages resulting from this
message. message.
skipping to change at line 409 skipping to change at line 561
recognize the object will reject the message that carries it with recognize the object will reject the message that carries it with
an "Unknown Object Class" error. an "Unknown Object Class" error.
One C-Type is defined for this object and should be assigned by One C-Type is defined for this object and should be assigned by
IANA. IANA.
o LSP Required Attributes TLVs o LSP Required Attributes TLVs
Recommended C-Type value 1. Recommended C-Type value 1.
7.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 the space of TLV type identifiers as IANA is requested to manage TLV type identifiers as follows:
follows:
- TLV Type - TLV Type
- 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 = LSP Attributes Flags - 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.
7.3 Attributes Flags 9.3 Attributes Flags
This document provides 32 new attributes bit flags for use in other This document provides new attributes bit flags for use in other
documents that specify new RSVP-TE attributes. These flags are documents that specify new RSVP-TE attributes. These flags are
present in the LSP Attributes Flags TLV referenced in the previous present in the Attributes Flags TLV referenced in the previous
section. section.
IANA is requested to manage the space of attributes bit flags IANA is requested to manage the space of attributes bit flags
numbering them in the usual IETF notation starting at zero. numbering them in the usual IETF notation starting at zero and
continuing through 2039.
7.4 SESSION_ATTRIBUTE Flags Field Each bit should be tracked with the following qualities:
- Bit number
- Defining RFC
- Name of bit
- Whether there is meaning in the Attibute Flags TLV (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
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.
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
accidental double allocation of any one bit. accidental double allocation of any one bit.
7.5 New Error Codes 9.5 New Error Codes
This document defines the following new error codes and error values. This document defines the following new error codes and error values.
Numeric values should be assigned by IANA. Numeric values should be assigned by IANA.
Error Code Error Value Error Code Error Value
"Unknown Attributes TLV" Identifies the unknown TLV type code. "Unknown Attributes TLV" Identifies the unknown TLV type code.
"Unknown Attributes Bit" Identifies the unknown Attribute Bit. "Unknown Attributes Bit" Identifies the unknown Attribute Bit.
8. Security Considerations 9.6 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 TBD.
10. Security Considerations
This document adds two new objects to the RSVP Path message as used This document adds two new objects to the RSVP Path message as used
in MPLS and GMPLS signaling. It does not introduce any new direct in MPLS and GMPLS signaling, and a new subobject to the RECORD_ROUTE
security issues and the reader is referred to the security object carried on may 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]. considerations expressed in [RFC2205], [RFC3209] and [RFC3473].
It is of passing note that any signaling request that indicates the It is of passing note that any signaling request that indicates the
functional preferences or attributes of an MPLS LSP may provide functional preferences or attributes of an MPLS LSP may provide
anyone with unauthorized access to the contents of the message with anyone with unauthorized access to the contents of the message with
information about the LSP that an administrator may wish to keep information about the LSP that an administrator may wish to keep
secret. Although this document adds new objects for signaling desired secret. Although this document adds new objects for signaling desired
LSP attributes, it does not contribute to this issue which can LSP attributes, it does not contribute to this issue which can
only be satisfactorily handled by encrypting the content of the only be satisfactorily handled by encrypting the content of the
signaling message. signaling message.
9. Acknowledgements 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.
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 for his input. work. Thanks also to Raymond Zhang, Kireeti Kompella and Philip
Matthews for their input.
10. 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
IETF's procedures with respect to rights in standards-track IETF's procedures with respect to rights in standards-track
and standards-related documentation can be found in BCP-11. and standards-related documentation can be found in BCP-11.
skipping to change at line 507 skipping to change at line 687
permission for the use of such proprietary rights by permission for the use of such proprietary rights by
implementors or users of this specification can be obtained implementors or users of this specification can be obtained
from the IETF Secretariat. from the IETF Secretariat.
The IETF invites any interested party to bring to its The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, or attention any copyrights, patents or patent applications, or
other proprietary rights which may cover technology that may other proprietary rights which may cover technology that may
be required to practice this standard. Please address the be required to practice this standard. Please address the
information to the IETF Executive Director. information to the IETF Executive Director.
11. Normative References 13. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S.
and S. Jamin, "Resource ReserVation Protocol -- and S. Jamin, "Resource ReserVation Protocol --
Version 1 Functional Specification", RFC 2205, Version 1 Functional Specification", RFC 2205,
September 1997. September 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions
to RSVP for LSP Tunnels", RFC 3209, December 2001. to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", Switching (GMPLS) Signaling Functional Description",
RFC 3471, January 2003. RFC 3471, January 2003.
[RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling -
RSVP-TE Extensions", RFC 3473 January 2003. RSVP-TE Extensions", RFC 3473 January 2003.
[FRR] Pan, P. (Ed.), "Fast Reroute Extensions to RSVP-TE for 14. Informative References
LSP Tunnels", <draft-ietf-mpls-rsvp-lsp-fastreroute-03
.txt>, Internet Draft, work in progress.
12. 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-01.txt>,
Internet Draft, work in progress. Internet Draft, work in progress.
[FRR] Pan, P. (Ed.), "Fast Reroute Extensions to RSVP-TE for
LSP Tunnels", <draft-ietf-mpls-rsvp-lsp-fastreroute-03
.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.
[REOPT] Vasseur, JP., Ikejiri, Y., "Reoptimization of MPLS [REOPT] Vasseur, JP., Ikejiri, Y., "Reoptimization of MPLS
Traffic Engineering loosely routed explicit LSP path", Traffic Engineering loosely routed explicit LSP path",
<draft-vasseur-mpls-loose-path-reopt-02.txt>, Internet <draft-vasseur-mpls-loose-path-reopt-02.txt>, Internet
Draft, work in progress. Draft, work in progress.
13. Authors' Addresses 15. Authors' Addresses
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
Phone: +44 (0) 1978 860944 Phone: +44 (0) 1978 860944
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 300 Apollo Drive
Chelmsford, MA 01824 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
14. Full Copyright Statement Arthi Ayyangar
Juniper Networks, Inc.
1194 N.Mathilda Ave
Sunnyvale, CA 94089
USA
EMail: arthi@juniper.net
16. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Copyright (C) The Internet Society (2003). 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
 End of changes. 

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