draft-ietf-ccamp-rfc4420bis-03.txt   rfc5420.txt 
INTERNET-DRAFT Adrian Farrel (Editor)
Network Working Group Old Dog Consulting
Obsoletes: RFC4420 Dimitri Papadimitriou
Updates: RFC3209, RFC3473 Alcatel
Category: Standards Track Jean-Philippe Vasseur
Created: May 27, 2008 Cisco Systems, Inc.
Expires: November 27, 2008 Arthi Ayyangar
Juniper Networks
Encoding of Attributes for Multiprotocol Label Switching (MPLS)
Label Switched Path (LSP) Establishment Using RSVP-TE
draft-ietf-ccamp-rfc4420bis-03.txt Network Working Group A. Farrel, Ed.
Request for Comments: 5420 Old Dog Consulting
Obsoletes: 4420 D. Papadimitriou
Updates: 3209, 3473 Alcatel
Category: Standards Track JP. Vasseur
Cisco Systems, Inc.
A. Ayyangar
Juniper Networks
February 2009
Status of this Memo Encoding of Attributes for MPLS LSP Establishment Using
Resource Reservation Protocol Traffic Engineering (RSVP-TE)
By submitting this Internet-Draft, each author represents that any Status of This Memo
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document specifies an Internet standards track protocol for the
Task Force (IETF), its areas, and its working groups. Note that other Internet community, and requests discussion and suggestions for
groups may also distribute working documents as Internet-Drafts. improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six months Copyright Notice
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright (c) 2009 IETF Trust and the persons identified as the
http://www.ietf.org/ietf/1id-abstracts.txt. document authors. All rights reserved.
The list of Internet-Draft Shadow Directories can be This document is subject to BCP 78 and the IETF Trust's Legal
accessed at http://www.ietf.org/shadow.html. Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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 (RSVP-TE) extensions. This protocol includes an object Engineering (RSVP-TE) extensions. This protocol includes an object
(the SESSION_ATTRIBUTE object) that carries a Flags field used to (the SESSION_ATTRIBUTE object) that 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. Recent proposals in eight bits, allowing for eight options to be set. Recent proposals
many documents that extend RSVP-TE have suggested uses for each of in many documents that extend RSVP-TE have suggested uses for each of
the previously unused bits. 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 The object mechanisms defined in this document are equally applicable
to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to
GMPLS non-PSC LSPs. GMPLS non-PSC LSPs.
This document replaces and obsoletes the previous version of this This document replaces and obsoletes the previous version of this
work published as RFC 4420. The only change is in the encoding of the work, published as RFC 4420. The only change is in the encoding of
Type-Length-Variable (TLV) data structures. the Type-Length-Variable (TLV) data structures.
Contents Table of Contents
1. Introduction and Problem Statement ..............................3 1. Introduction and Problem Statement ..............................4
1.1. Applicability to Generalized MPLS ..........................4 1.1. Applicability to Generalized MPLS ..........................5
1.2. A Rejected Alternate Solution ..............................4 1.2. A Rejected Alternate Solution ..............................5
2. Terminology .....................................................5 2. Terminology .....................................................6
3. Attributes TLVs .................................................5 3. Attributes TLVs .................................................6
3.1. Attributes Flags TLV .......................................6 3.1. Attribute Flags TLV ........................................7
4. LSP_ATTRIBUTES Object ...........................................6 4. LSP_ATTRIBUTES Object ...........................................8
4.1. Format .....................................................7 4.1. Format .....................................................9
4.2. Generic Processing Rules for Path Messages .................7 4.2. Generic Processing Rules for Path Messages .................9
4.3. Generic Processing Rules for Resv Messages .................8 4.3. Generic Processing Rules for Resv Messages .................9
5. LSP_REQUIRED_ATTRIBUTES Object ..................................9 5. LSP_REQUIRED_ATTRIBUTES Object .................................10
5.1. Format .....................................................9 5.1. Format ....................................................11
5.2. Generic Processing Rules ...................................9 5.2. Generic Processing Rules ..................................11
6. Inheritance Rules ..............................................10 6. Inheritance Rules ..............................................11
7. Recording Attributes Per LSP ...................................11 7. Recording Attributes Per LSP ...................................12
7.1. Requirements ..............................................11 7.1. Requirements ..............................................12
7.2. RRO Attributes Subobject ..................................11 7.2. RRO Attributes Subobject ..................................12
7.3. Procedures ................................................12 7.3. Procedures ................................................13
7.3.1. Subobject Presence Rules ...........................12 7.3.1. Subobject Presence Rules ...........................13
7.3.2. Reporting Compliance with LSP Attributes ...........12 7.3.2. Reporting Compliance with LSP Attributes ...........14
7.3.3. Reporting Per-Hop Attributes .......................13 7.3.3. Reporting Per-Hop Attributes .......................14
7.3.4. Default Behavior ...................................13 7.3.4. Default Behavior ...................................14
8. Summary of Attribute Bit Allocation ............................13 8. Summary of Attribute Bit Allocation ............................14
9. Message Formats ................................................14 9. Message Formats ................................................15
10. Guidance for Key Application Scenarios ........................14 10. Guidance for Key Application Scenarios ........................16
10.1. Communicating to Egress LSRs .............................15 10.1. Communicating to Egress LSRs .............................16
10.2. Communicating to Key Transit LSRs ........................15 10.2. Communicating to Key Transit LSRs ........................17
10.3. Communicating to All LSRs ................................16 10.3. Communicating to All LSRs ................................17
11. IANA Considerations ...........................................16 11. IANA Considerations ...........................................17
11.1. New RSVP C-Nums and C-Types ..............................16 11.1. New RSVP C-Nums and C-Types ..............................17
11.2. New TLV Space ............................................17 11.2. New TLV Space ............................................18
11.3. Attributes Flags .........................................17 11.3. Attribute Flags ..........................................19
11.4. New Error Codes ..........................................18 11.4. New Error Codes ..........................................19
11.5. New Record Route Subobject Identifier ....................18 11.5. New Record Route Subobject Identifier ....................19
12. Security Considerations .......................................18 12. Security Considerations .......................................20
13. Acknowledgements ..............................................19 13. Acknowledgements ..............................................20
14. Changes from RFC 4420 to RFC XXXX .............................19 14. Changes from RFC 4420 to RFC 5420 .............................20
15. Normative References ..........................................19 15. Normative References ..........................................21
16. Informative References ........................................20 16. Informative References ........................................21
17. Authors' Addresses ............................................20
1. Introduction and Problem Statement 1. Introduction and Problem Statement
This document replaces and obsoletes the previous version of this This document replaces and obsoletes the previous version of this
work published as RFC 4420 [RFC4420]. The only change is in the work, published as RFC 4420 [RFC4420]. The only change is in the
encoding of the Type-Length-Variable (TLV) data structures presented encoding of the Type-Length-Variable (TLV) data structures presented
in Section 3. See Section 14 for a summary of changes. in Section 3. See Section 14 for a summary of changes.
Traffic-Engineered Multiprotocol Label Switching (MPLS) Label Traffic-Engineered Multiprotocol Label Switching (MPLS) Label
Switched Paths (LSPs) [RFC3031] may be set up using the Path message Switched Paths (LSPs) [RFC3031] may be set up using the Path message
of the RSVP-TE signaling protocol [RFC3209]. The Path message of the RSVP-TE signaling protocol [RFC3209]. The Path message
includes the SESSION_ATTRIBUTE object, which carries a Flags field includes the SESSION_ATTRIBUTE object, which carries a Flags field
used to indicate desired options and attributes of the LSP. used to indicate desired options and 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 three of those bits are assigned in [RFC3209]. A further two bits
are assigned in [RFC4090] for fast re-reroute functionality leaving are assigned in [RFC4090] for fast re-reroute functionality, leaving
only three bits available. Several recent proposals and Internet only three bits available. Several recent proposals and Internet
Drafts have demonstrated that there is a high demand for the use of Drafts have demonstrated that there is a high demand for the use of
the other three bits. Some, if not all, of those proposals are the other three bits. Some, if not all, of those proposals are
likely to go forward as RFCs resulting in depletion or near depletion likely to go forward as RFCs, resulting in depletion or near
of the Flags field and a consequent difficulty in signaling new depletion of the Flags field and a consequent difficulty in signaling
options and attributes that may be developed in the future. new options and 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. number of attributes bits.
The new RSVP-TE message object is quite flexible, due to the use of The new RSVP-TE message object is quite flexible, due to the use of
the TLV format and allows: the TLV format and allows:
- future specification of bit flags - future specification of bit flags
- additional options and attribute parameters carried in TLV - additional options and attribute parameters carried in TLV format
format.
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 with the same Tunnel ID between the same source and separate LSPs with the same Tunnel ID between the same source and
destination (that is, within the same session). destination (that is, within the same session).
It is noted that some options and attributes do not need to be acted It is noted that some options and attributes do not need to be acted
on by all Label Switched Routers (LSRs) along the path of the LSP. on by all Label Switched Routers (LSRs) along the path of the LSP.
In particular, these options and attributes may apply only to key In particular, these options and attributes may apply only to key
LSRs on the path such as the ingress LSR and egress LSR. Special LSRs on the path, such as the ingress LSR and egress LSR. Special
transit LSRs, such as Area or Autonomous System Border Routers (ABRs transit LSRs, such as Area or Autonomous System Border Routers (ABRs
or ASBRs), may also fall into this category. This means that the new or ASBRs), may also fall into this category. This means that the new
options and attributes should be signaled transparently, and only options and attributes should be signaled transparently, and only
examined at those points that need to act on them. examined at those points that need to act on them.
On the other hand, other options and attributes may require action at On the other hand, other options and attributes may require action at
all transit LSRs along the path of the LSP. Inability to support the all transit LSRs along the path of the LSP. Inability to support the
required attributes by one of those transit LSRs may require the LSR required attributes by one of those transit LSRs may require the LSR
to refuse the establishment of the LSP. to refuse the establishment of the LSP.
These considerations are particularly important in the context of These considerations are particularly important in the context of
backward compatibility. In general, it should be possible to provide backward 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.
Moreover, some features just require action on specific intermediate Moreover, some features just require action on specific intermediate
hops, and not on every visited LSR. hops, not on every visited LSR.
Note that options already specified for the SESSION_ATTRIBUTE object Note that options already specified for the SESSION_ATTRIBUTE object
in preexisting RFCs are not migrated to the new mechanisms described in preexisting RFCs are not migrated to the new mechanisms described
in this document. in this document.
RSVP includes a way for unrecognized objects to be transparently RSVP includes a way for unrecognized objects to be transparently
forwarded by transit nodes without them refusing the incoming forwarded by transit nodes without them refusing the incoming
protocol messages and without the objects being stripped from the protocol messages and without the objects being stripped from the
outgoing protocol message (see [RFC2205], Section 3.10). This outgoing protocol message (see [RFC2205], Section 3.10). This
capability extends to RSVP-TE and provides a good way to ensure that capability extends to RSVP-TE and provides a good way to ensure that
only those LSRs that understand a particular object examine it. 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: using the C-Num definition objects are defined in this document; using the C-Num definition
rules inherited from [RFC2205], the first is passed transparently by rules inherited from [RFC2205], the first is passed transparently by
LSRs that do not recognize it, and the second causes LSP setup LSRs that do not recognize it, and the second causes LSP setup
failure with the generation of a PathErr message with an appropriate failure with the generation of a PathErr message with an appropriate
Error Code if an LSR does not recognize it. Error Code if an LSR does not recognize it.
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 equally [RFC3473]. The extensions described in this document are equally
skipping to change at page 5, line 46 skipping to change at page 7, line 7
// Value // // Value //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
The identifier of the TLV. The identifier of the TLV.
Length Length
Indicates the total length of the TLV, i.e., 4 + the length of Indicates the total length of the TLV in octets. That is, the
the value field in octets. A value field whose length is not a combined length of the Type, Length, and Value fields, i.e.,
multiple of four MUST be zero-padded so that the TLV is four- four plus the length of the Value field in octets.
octet aligned.
The entire TLV MUST be padded with between zero and three
trailing zeros to make it four-octet aligned. The Length field
does not count any padding.
Value Value
The data for the TLV padded as described above. The data carried in the TLV.
3.1. Attributes Flags TLV 3.1. Attribute 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 the future Attribute Flags TLV. Other TLV types may be defined in the future
with type values assigned by IANA (see Section 11.2). with type values assigned by IANA (see Section 11.2).
The Attributes Flags TLV may be present in an LSP_ATTRIBUTES object The Attribute Flags TLV may be present in an LSP_ATTRIBUTES object
and/or an LSP_REQUIRED_ATTRIBUTES object defined in Sections 4 and 5. and/or an LSP_REQUIRED_ATTRIBUTES object, defined in Sections 4 and
The bits in the TLV represent the same attributes regardless of which 5. The bits in the TLV represent the same attributes regardless of
object carries the TLV. Documents that define individual bits MUST which object carries the TLV. Documents that define individual bits
specify whether the bit may be set in one object or the other, or MUST specify whether the bit may be set in one object, the other, or
both. It is not expected that a bit will be set in both objects on a 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 single Path message at the same time, but this is not ruled out by
this document. this document.
The Attribute Flags TLV Value field is an array of units of 32 flags The Attribute Flags TLV Value field is an array of units of 32 flags
numbered from the most significant bit as bit zero. The Length field numbered from the most significant bit as bit zero. The Length field
for this TLV is therefore always a multiple of 4 bytes, regardless of for this TLV is therefore always a multiple of four bytes, regardless
the number of bits carried and no padding is required. of the number of bits carried, and no padding is required.
Unassigned bits are considered as reserved and MUST be set to zero on Unassigned bits are considered as reserved and MUST be set to zero on
transmission by the originator of the object. Bits not contained in 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 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 either because it is not contained in the LSP_ATTRIBUTES or
LSP_REQUIRED_ATTRIBUTES object, or because those objects are LSP_REQUIRED_ATTRIBUTES object, or because those objects are
themselves absent, all processing MUST be performed as though the themselves absent, all processing MUST be performed as though the
bits were present and set to zero. That is to say, assigned bits bits were present and set to zero. That is to say, assigned bits
that are not present either because the TLV is deliberately that are not present either because the TLV is deliberately
foreshortened or because the TLV is not included MUST be treated as foreshortened or because the TLV is not included MUST be treated as
skipping to change at page 7, line 44 skipping to change at page 9, line 22
| | | |
// Attributes TLVs // // Attributes TLVs //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 for Path Messages 4.2. Generic Processing Rules for Path Messages
An LSR that does not support this object is required to pass it on An LSR that does not support this object is required to pass it on
unaltered as indicated by the C-Num and the rules defined in unaltered, as indicated by the C-Num and the rules defined in
[RFC2205]. [RFC2205].
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 unaltered in type code carried in this object MUST pass the TLV on unaltered in
the LSP_ATTRIBUTES object that it places in the Path message that it the LSP_ATTRIBUTES object that it places in the Path message that it
sends downstream. 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 not support the attribute defined by the TLV MUST act as specified in
in the document that defines the TLV. the document that defines the TLV.
An LSR that supports the Attributes Flags TLV, but does not recognize An LSR that supports the Attribute Flags TLV but does not recognize a
a bit set in the Attributes Flags TLV, MUST forward the TLV bit set in the Attribute Flags TLV MUST forward the TLV unchanged.
unchanged.
An LSR that supports the Attributes Flags TLV and recognizes a bit An LSR that supports the Attribute Flags TLV and recognizes a bit
that is set, but does not support the indicated attribute, MUST act that is set but does not support the indicated attribute MUST act as
as specified in the document that defines the bit. specified in the document that defines the bit.
4.3. Generic Processing Rules for Resv Messages 4.3. Generic Processing Rules for Resv Messages
An LSR that wishes to report operational status of an LSP may include An LSR that wishes to report operational status of an LSP may include
this object in a Resv message, or update the object that is already this object in a Resv message, or update the object that is already
carried in a Resv message. carried in a Resv message.
Note that this usage reports the state of the entire LSP and not the Note that this usage reports the state of the entire LSP and not the
state of the LSP at an individual LSR. This latter function is state of the LSP at an individual LSR. This latter function is
achieved using the LSP Attributes subobject of the Record Route achieved using the LSP Attributes subobject of the Record Route
skipping to change at page 9, line 21 skipping to change at page 10, line 40
LSP_REQUIRED_ATTRIBUTES object and MUST NOT forward the object LSP_REQUIRED_ATTRIBUTES object and MUST NOT forward the object
without acting on its contents. without acting on its contents.
This object effectively extends the Flags field in the This object effectively extends the Flags field in the
SESSION_ATTRIBUTE object and allows for the future inclusion of more SESSION_ATTRIBUTE object and allows for the future inclusion of more
complex objects through TLVs. It complements the LSP_ATTRIBUTES complex objects through TLVs. It complements the LSP_ATTRIBUTES
object. object.
The LSP_REQUIRED_ATTRIBUTES object class is 67 of the form 0bbbbbbb. The LSP_REQUIRED_ATTRIBUTES object class is 67 of the form 0bbbbbbb.
This C-Num value ensures that LSRs that do not recognize the object This C-Num value ensures that LSRs that do not recognize the object
reject the LSP setup effectively saying that they do not support the reject the LSP setup, effectively saying that they do not support the
attributes requested. This means that this object SHOULD only be attributes requested. This means that this object SHOULD only be
used for attributes that require support at some transit LSRs and so used for attributes that require support at some transit LSRs and so
require examination at all transit LSRs. See Section 4 for how end- require examination at all transit LSRs. See Section 4 for how end-
to-end and selective attributes are signaled. 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.
skipping to change at page 10, line 10 skipping to change at page 11, line 30
An LSR that does not support this object will use a PathErr to reject An LSR that does not support this object will use a PathErr to reject
the Path message based on the C-Num using the Error Code "Unknown the Path message based on the C-Num using the Error Code "Unknown
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 "Unknown MUST reject the Path message using a PathErr with Error Code "Unknown
Attributes TLV" and Error Value set to the value of the unknown TLV Attributes TLV" and Error Value set to the value of the unknown TLV
type code. type code.
An LSR that does not recognize a bit set in the Attributes Flags TLV An LSR that does not recognize a bit set in the Attribute Flags TLV
MUST reject the Path message using a PathErr with Error Code "Unknown MUST reject the Path message using a PathErr with Error Code "Unknown
Attributes Bit" and Error Value set to the bit number of the unknown Attributes Bit" and Error Value set to the bit number of the unknown
bit in the Attributes Flags. bit in the Attribute Flags.
An LSR that recognizes an attribute (however encoded), but that does An LSR that recognizes an attribute (however encoded) but does not
not support that attribute, MUST act according to the behavior support that attribute MUST act according to the behavior specified
specified in the document that defines that specific attribute. in the document that defines that specific attribute.
Note that this object is not used on a Resv. In order to report the Note that this object is not used on a Resv. In order to report the
status of an LSP, either the LSP_ATTRIBUTES object on a Resv or the status of an LSP, either the LSP_ATTRIBUTES object on a Resv or the
Attributes subobject in the Record Route object (see Section 7) must Attributes subobject in the Record Route object (see Section 7) must
be used. be used.
6. Inheritance Rules 6. Inheritance Rules
In certain circumstances, when reaching an LSP region boundary, a In certain circumstances, when reaching an LSP region boundary, a
forwarding adjacency LSP (FA-LSP; see [RFC4206]) is initially set up forwarding adjacency LSP (FA-LSP; see [RFC4206]) is initially set up
to allow the establishment of the LSP carrying the LSP_ATTRIBUTES to allow the establishment of the LSP carrying the LSP_ATTRIBUTES
and/or LSP_REQUIRED_ATTRIBUTES objects. In this case, when the and/or LSP_REQUIRED_ATTRIBUTES objects. In this case, when the
boundary LSR supports LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES boundary LSR supports LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES
processing, the FA-LSP MAY upon local policy inherit a subset of the processing, the FA-LSP MAY, upon local policy, inherit a subset of
Attributes TLVs, in particular when the FA-LSP belongs to the same the Attributes TLVs, in particular when the FA-LSP belongs to the
switching capability class as the triggering LSP. same switching capability class as the triggering LSP.
When these conditions are met, the LSP_ATTRIBUTES and/or When these conditions are met, the LSP_ATTRIBUTES and/or
LSP_REQUIRED_ATTRIBUTES objects are simply copied with the inherited LSP_REQUIRED_ATTRIBUTES objects are simply copied with the inherited
Attributes TLVs in the Path message used to establish the FA-LSP. By Attributes TLVs in the Path message used to establish the FA-LSP. By
default (and in order to simplify deployment), none of the incoming default (and in order to simplify deployment), none of the incoming
LSP Attributes TLVs are considered as inheritable. Note that when LSP Attributes TLVs are considered as inheritable. Note that when
the FA-LSP establishment itself requires one or more Attributes TLVs, the FA-LSP establishment itself requires one or more Attributes TLVs,
an 'OR' operation is performed with the inherited set of values. an 'OR' operation is performed with the inherited set of values.
Documents that define individual bits for the LSP Attributes Flags Documents that define individual bits for the LSP Attribute Flags TLV
TLV MUST specify whether or not these bits MAY be inherited MUST specify whether or not these bits MAY be inherited (including
(including the condition to be met in order for this inheritance to the condition to be met in order for this inheritance to occur). The
occur). The same applies for any other TLV that will be defined same applies for any other TLV that will be defined following the
following the rules specified in Section 3. rules specified in Section 3.
7. Recording Attributes Per LSP 7. Recording Attributes Per LSP
7.1. Requirements 7.1. Requirements
In some circumstances, it is useful to determine which of the In some circumstances, it is useful to determine which of the
requested LSP attributes have been applied at which LSRs along 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 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
skipping to change at page 11, line 26 skipping to change at page 12, line 44
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 be 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.
7.2. RRO Attributes Subobject 7.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 Attribute 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
bit flags. bit flags.
There is a one-to-one correspondence between bits in the Attributes There is a one-to-one correspondence between bits in the Attribute
Flags TLV and the RRO Attributes Subobject. If a bit is only 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. required in one of the two places, it is reserved in the other place.
See the procedures sections, below, for more information. See the procedures sections, below, for more information.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Attribute Flags // // Attribute Flags //
skipping to change at page 12, line 4 skipping to change at page 13, line 23
| Type | Length | Reserved | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Attribute Flags // // Attribute Flags //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
0x05 0x05
Length Length
The Length contains the total length of the subobject in bytes, The Length contains the total length of the subobject in bytes,
including the Type and Length fields. This length must be a including the Type and Length fields. This length must be a
multiple of 4 and must be at least 8. multiple of four and must be at least eight.
Attribute Flags Attribute Flags
The attribute flags recorded for the specific hop. The attribute flags recorded for the specific hop.
7.3. Procedures 7.3. Procedures
7.3.1. Subobject Presence Rules 7.3.1. Subobject Presence Rules
As will be clear from [RFC3209], the RECORD_ROUTE object is managed 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 as a "stack", with each LSR adding subobjects to the start of the
object. The Attributes subobject is pushed onto the RECORD_ROUTE object. The Attributes subobject is pushed onto the RECORD_ROUTE
object immediately prior to pushing the node's IP address or link object immediately prior to pushing the node's IP address or link
identifier. Thus, if label recording is being used, the Attributes identifier. Thus, if label recording is being used, the Attributes
subobject SHOULD be pushed onto the RECORD_ROUTE object after the subobject SHOULD be pushed onto the RECORD_ROUTE object after the
Record Label subobject(s). Record Label subobject(s).
A node MUST NOT push an Attributes subobject onto the RECORD_ROUTE A node MUST NOT push an Attributes subobject onto the RECORD_ROUTE
object without also pushing an IPv4, IPv6, or Unnumbered Interface ID object without also pushing an IPv4, IPv6, or Unnumbered Interface ID
subobject. subobject.
skipping to change at page 12, line 42 skipping to change at page 14, line 13
Attributes subobject. Attributes subobject.
If the new subobject causes the RRO to be too big to fit in a Path 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 (or Resv) message, the processing MUST be as described in Section
4.4.3 of [RFC3209]. 4.4.3 of [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 (that is, the 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 nearest to the top of the stack) SHALL have any meaning within the
context of this document. All such subobjects MUST be forwarded context of this document. All such subobjects MUST be forwarded
unmodified by transit LSRs unmodified by transit LSRs.
7.3.2. Reporting Compliance with LSP Attributes 7.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 Attribute
Flags TLV, an LSR MAY set the corresponding bit (see Section 8) in 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 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
statement of whether hop-by-hop acknowledgement is required. statement of whether hop-by-hop acknowledgement is required.
7.3.3. Reporting Per-Hop Attributes 7.3.3. Reporting Per-Hop Attributes
skipping to change at page 13, line 22 skipping to change at page 14, line 39
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.
7.3.4. Default Behavior 7.3.4. Default Behavior
By default, all bits in an Attributes subobject SHOULD be set to By default, all bits in an Attributes subobject SHOULD be set to
zero. zero.
If a received Attribute subobject is not long enough to include a If a received Attributes subobject is not long enough to include a
specific numbered bit, that bit MUST be treated as though present and specific numbered bit, that bit MUST be treated as though present and
as if set to zero. 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.
8. Summary of Attribute Bit Allocation 8. 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 Attribute 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 Attribute 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 Attribute 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 even though the Attribute Flags TLV and the RRO Attributes subobject, even though the
bit may be irrelevant in either the Attributes Flags or the RRO bit may be irrelevant in either the Attribute Flags or the RRO
Attributes subobject. The document that defines the usage of the new 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 bit MUST state in which places it is used and MUST handle a default
setting of zero. setting of zero.
9. Message Formats 9. 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. The LSP_ATTRIBUTES object MAY be be carried in a Path message. The LSP_ATTRIBUTES object MAY be
carried in a Resv message. carried in a Resv message.
skipping to change at page 14, line 29 skipping to change at page 15, line 44
LSP_REQUIRED_ATTRIBUTES objects are RECOMMENDED to be placed LSP_REQUIRED_ATTRIBUTES objects are RECOMMENDED to be placed
immediately after the SESSION_ATTRIBUTE object if it is present, or immediately after the SESSION_ATTRIBUTE object if it is present, or
otherwise immediately after the LABEL_REQUEST object. otherwise immediately 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 MUST be prepared to receive these objects in any order in any LSRs MUST be prepared to receive these objects in any order in any
position within a Path message. Subsequent instances of these position within a Path message. Subsequent instances of these
objects within a Path message SHOULD be ignored and those objects objects within a Path message SHOULD be ignored and MUST be forwarded
MUST be forwarded unchanged. unchanged.
On a Resv message, the LSP_ATTRIBUTES object is placed in the flow On a Resv message, the LSP_ATTRIBUTES object is placed in the flow
descriptor and is associated with the FILTER_SPEC object that descriptor and is associated with the FILTER_SPEC object that
precedes it. It is RECOMMENDED that the LSP_ATTRIBUTES object be precedes it. It is RECOMMENDED that the LSP_ATTRIBUTES object be
placed immediately after the LABEL object. placed immediately after the LABEL object.
LSRs MUST be prepared to receive this object in any order in any LSRs MUST be prepared to receive this object in any order in any
position within a Resv message subject to the previous note. Only position within a Resv message, subject to the previous note. Only
one instance of the LSP_ATTRIBUTES object is meaningful within the one instance of the LSP_ATTRIBUTES object is meaningful within the
context of a FILTER_SPEC object. Subsequent instances of the object context of a FILTER_SPEC object. Subsequent instances of the object
SHOULD be ignored and MUST be forwarded unchanged. SHOULD be ignored and MUST be forwarded unchanged.
10. Guidance for Key Application Scenarios 10. Guidance for Key Application Scenarios
As described in the Introduction section of this document, it may be 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 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 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 ASBRs), or by all LSRs along the LSP. This section briefly describes
skipping to change at page 15, line 35 skipping to change at page 16, line 50
LSP_ATTRIBUTES object. LSP_ATTRIBUTES object.
The remaining issue is how the ingress LSR can know whether the The remaining issue is how the ingress LSR can know whether the
egress LSR has acted correctly on the required LSP attribute. egress LSR has acted correctly on the required LSP attribute.
Another part of the definition of the attribute (in the defining RFC) Another part of the definition of the attribute (in the defining RFC)
is whether reporting is required. If reporting is required, the is whether reporting is required. If reporting is required, the
egress LSR is required to use the RRO Attributes subobject to report egress LSR is required to use the RRO Attributes subobject to report
whether it has acted on the received attribute. whether it has acted on the received attribute.
If an egress LSR understands a received attribute as mandatory for an 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 egress LSR but does not wish to satisfy the request, it will reject
the Path message. If an egress LSR understands the attribute, but the Path message. If an egress LSR understands the attribute but
believes it to be optional and does not wish to satisfy the request, believes it to be optional and does not wish to satisfy the request,
it will report its non-compliance in the RRO Attributes subobject. it will report its non-compliance in the RRO Attributes subobject.
If the egress LSR does not understand the received attribute, it may If the egress LSR does not understand the received attribute, it may
report non-compliance in the RRO Attributes subobject explicitly, or report non-compliance in the RRO Attributes subobject explicitly, or
may omit the RRO Attributes subobject implying that it has not it may omit the RRO Attributes subobject, implying that it has not
satisfied the request. satisfied the request.
10.2. Communicating to Key Transit LSRs 10.2. Communicating to Key Transit LSRs
Processing for key transit LSRs (such as ABRs and ASBRs) follows Processing for key transit LSRs (such as ABRs and ASBRs) follows
exactly as for egress LSR. The only difference is that the exactly as for egress LSR. The only difference is that the
definition of the LSP attribute in the defining RFC will state that definition of the LSP attribute in the defining RFC will state that
the attribute must be acted on by these transit LSRs. the attribute must be acted on by these transit LSRs.
10.3. Communicating to All LSRs 10.3. Communicating to All LSRs
In order to force all LSRs to examine the LSP attributes, the 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 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 such that any LSR that does not recognize the object must reject a
received Path message containing the object. received Path message containing the object.
An LSR that recognizes the LSP_REQUIRED_ATTRIBUTES object, but does An LSR that recognizes the LSP_REQUIRED_ATTRIBUTES object but does
not recognize an attribute, will reject the Path message. not recognize an attribute will reject the Path message.
An LSR that recognizes an attribute, but does not wish to support the An LSR that recognizes an attribute but does not wish to support the
attribute, reacts according to the definition of the attribute in the attribute reacts according to the definition of the attribute in the
defining RFC. This may allow the LSR to ignore the attribute and 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 forward it unchanged, or may require it to fail the LSP setup. The
LSR may additionally be required to report whether it supports the LSR may additionally be required to report whether it supports the
attribute using the RRO Attributes subobject. attribute using the RRO Attributes subobject.
11. IANA Considerations 11. IANA Considerations
The IANA allocations made for RFC 4420 [RFC4420] now apply to this The IANA allocations made for RFC 4420 [RFC4420] now apply to this
document and are listed here for completeness. document and are listed here for completeness.
This document makes no further requests for IANA action, but IANA IANA has updated the registry entries created for RFC 4420 to
should update the registry entries created for RFC 4420 to reference reference this document, which is now the normative reference for
this document which is now the normative reference for those entries. those entries. This document makes no further requests for IANA
action.
11.1. New RSVP C-Nums and C-Types 11.1. New RSVP C-Nums and C-Types
Two new RSVP C-Nums are defined in this document and have been Two new RSVP C-Nums are defined in this document and have been
assigned by IANA. assigned by IANA.
o LSP_ATTRIBUTES object o LSP_ATTRIBUTES object
The C-Num (value 197) is of the form 11bbbbbb so that LSRs that do 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, not 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.
One C-Type is defined for this object and has been assigned by One C-Type is defined for this object and has been assigned by
IANA. IANA.
o LSP Attributes TLVs o LSP Attributes TLVs
Recommended C-Type value 1. C-Type value 1.
o LSP_REQUIRED_ATTRIBUTES object o LSP_REQUIRED_ATTRIBUTES object
The C-Num (value 67) is of the form 0bbbbbbb so that LSRs that do 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 not recognize the object will reject the message that carries it
with an "Unknown Object Class" error. with an "Unknown Object Class" error.
One C-Type is defined for this object and has been assigned by One C-Type is defined for this object and has been assigned by
IANA. IANA.
o LSP Required Attributes TLVs o LSP Required Attributes TLVs
Recommended C-Type value 1. C-Type value 1.
11.2. New TLV Space 11.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 TLV includes a 16-bit type identifier (the T-field). The same
T-field values are applicable to both objects. T-field values are applicable to both objects.
The IANA has created a new registry and will manage TLV type The IANA has created a new registry and will manage TLV type
identifiers as follows: identifiers as follows:
- TLV Type (T-field value) - 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 = Attribute Flags TLV
- allowed on LSP_ATTRIBUTES object - allowed on LSP_ATTRIBUTES object
- allowed on LSP_REQUIRED_ATTRIBUTES object. - allowed on LSP_REQUIRED_ATTRIBUTES object
New TLV type values may be allocated only by an IETF Consensus New TLV type values may be allocated only by an IETF Consensus
action. action.
11.3. Attributes Flags 11.3. Attribute Flags
This document provides 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 Attributes Flags TLV referenced in the previous present in the Attribute Flags TLV referenced in the previous
section. section.
The IANA has created a new registry and will manage the space of The IANA has created a new registry and will manage the space of
attributes bit flags numbering them in the usual IETF notation attributes bit flags, numbering them in the usual IETF notation:
starting at zero and continuing at least through 31. starting at zero and continuing at least through 31.
New bit numbers may be allocated only by an IETF Consensus action. New bit numbers may be allocated only by an IETF Consensus action.
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 Attribute Flags TLV on a Path - 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 Attribute Flags TLV on a Resv
- Whether there is meaning in the RRO Attributes Subobject. - Whether there is meaning in the RRO Attributes subobject
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. (It would be meaningless in the 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 context of this document for a bit to have no meaning in either the
Attribute Flags TLV or the RRO Attributes Subobject.) Attribute Flags TLV or the RRO Attributes subobject.)
11.4. New Error Codes 11.4. 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 have been assigned by IANA. Numeric values have been assigned by IANA.
Error Code Error Value Error Code Error Value
29 "Unknown Attributes TLV" Identifies the unknown TLV type code. 29 "Unknown Attributes TLV" Identifies the unknown TLV type code.
30 "Unknown Attributes Bit" Identifies the unknown Attribute Bit. 30 "Unknown Attributes Bit" Identifies the unknown Attribute Bit.
skipping to change at page 18, line 48 skipping to change at page 20, line 22
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 secret. Although this document adds new objects for signaling
desired LSP attributes, it does not contribute to this issue, which desired LSP attributes, it does not contribute to this issue, which
can only be satisfactorily handled by encrypting the content of the can only be satisfactorily handled by encrypting the content of the
signaling message. signaling message.
Similarly, the addition of attribute recording information to the RRO Similarly, the addition of attribute-recording information to the RRO
may reveal information about the status of the LSP and the may reveal information about the status of the LSP and the
capabilities of individual LSRs that operators wish to keep secret. capabilities of individual LSRs that operators wish to keep secret.
The same strategy that applies to other RRO subobjects also applies The same strategy that applies to other RRO subobjects also applies
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.
13. Acknowledgements 13. 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. Thanks to Rahul Aggarwal for his careful to a similar problem. Thanks to Rahul Aggarwal for his careful
review and support of this work. Thanks also to Raymond Zhang, review and support of this work. Thanks also to Raymond Zhang,
skipping to change at page 19, line 21 skipping to change at page 20, line 41
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. Thanks to Rahul Aggarwal for his careful to a similar problem. Thanks to Rahul Aggarwal for his careful
review and support of this work. Thanks also to Raymond Zhang, review and support of this work. Thanks also to Raymond Zhang,
Kireeti Kompella, Philip Matthews, Jim Gibson, and Alan Kullberg for Kireeti Kompella, Philip Matthews, Jim Gibson, and Alan Kullberg for
their input. As so often, thanks to John Drake for useful offline their input. As so often, thanks to John Drake for useful offline
discussions. Thanks to Mike Shand for providing the Routing discussions. Thanks to Mike Shand for providing the Routing
Directorate review and to Joel Halpern for the General Area review -- Directorate review and to Joel Halpern for the General Area review --
both picked up on some unclarities. both picked up on some unclarities.
Thanks to the OIF for noticing the discrepency in RFC 4420 that is Thanks to the OIF for noticing the discrepancy in RFC 4420 that is
fixed in this document. Alfred Hoenes noted several typographical fixed in this document. Alfred Hoenes noted several typographical
errors. errors.
14. Changes from RFC 4420 to RFC XXXX 14. Changes from RFC 4420 to RFC 5420
[RFC Editor - Please replace "XXXX" with the RFC number assigned for
this work and remove this note.]
This document obsoletes RFC 4420 [RFC4420]. The only change is in This document obsoletes RFC 4420 [RFC4420]. The only change is in
Section 3. Section 3 describes the semantic of the Length field of Section 3. Section 3 describes the semantic of the Length field of
the Attributes TLV. the Attributes TLV.
Prior to the change, the Length field indicated the length of the Prior to the change, the Length field indicated the length of the
Value field only. After the change, as described in Section 3, the Value field only. After the change, as described in Section 3, the
Length field indicates the length of the whole TLV. This change means Length field indicates the length of the whole TLV. This change
that this document is consistent with the subobject format defined in means that this document is consistent with the subobject format
[RFC3209] and the TLV format defined in [RFC3471]. defined in [RFC3209] and the TLV format defined in [RFC3471].
In addition, the RFC Editor made many editorial changes to improve
the text and readability. These changes can be observed by comparing
the text of this document with that of [RFC4420].
15. Normative References 15. 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., and [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Version 1 Functional Specification", RFC 2205, September Functional Specification", RFC 2205, September 1997.
1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L. (Ed.), "Generalized Multi-Protocol Label [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003. 3471, January 2003.
[RFC3473] Berger, L. (Ed.), "Generalized Multi-Protocol Label [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003. 3473, January 2003.
16. Informative References 16. Informative References
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
2005. May 2005.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
2005.
[RFC4420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and [RFC4420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A.
A. Ayyangar, "Encoding of Attributes for Multiprotocol Ayyangar, "Encoding of Attributes for Multiprotocol Label
Label Switching (MPLS) Label Switched Path (LSP) Switching (MPLS) Label Switched Path (LSP) Establishment
Establishment Using Resource ReserVation Protocol-Traffic Using Resource ReserVation Protocol-Traffic Engineering
Engineering (RSVP-TE)", RFC 4420, February 2006. (RSVP-TE)", RFC 4420, February 2006.
17. Authors' Addresses 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 Dimitri Papadimitriou
Alcatel Alcatel
Fr. Wellesplein 1, Fr. Wellesplein 1,
skipping to change at page 21, line 19 skipping to change at line 970
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
18. Intellectual Property Statement
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.
19. Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
 End of changes. 79 change blocks. 
189 lines changed or deleted 185 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/