draft-ietf-mpls-rsvpte-attributes-04.txt   draft-ietf-mpls-rsvpte-attributes-05.txt 
Network Working Group Adrian Farrel (Editor) Network Working Group Adrian Farrel (Editor)
Internet Draft Old Dog Consulting Updates: RFC3209 and RFC3473 Old Dog Consulting
Category: Standards Track Dimitri Papadimitriou Category: Standards Track Dimitri Papadimitriou
Expires: January 2005 Alcatel Expires: November 2005 Alcatel
Jean-Philippe Vasseur Jean-Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
Arthi Ayyangar Arthi Ayyangar
Juniper Networks Juniper Networks
July 2004 May 2005
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-04.txt draft-ietf-mpls-rsvpte-attributes-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
or will be disclosed, and any of which I become aware will be have been or will be disclosed, and any of which he or she becomes
disclosed, in accordance with RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
skipping to change at line 61 skipping to change at line 60
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.
0. Change History
This section to be removed before publication as an RFC.
0.1 Changes from 03 to 04 Version
- New IPR and copyright text
- Update referneces
0.2 Changes from 02 to 03 Version
- Allow LSP_ATTRIBUTES object on Resv message.
- Document inheritance rules.
- Add table of Contents.
- New IPR and Copyright boiler-plate.
0.3 Changes from 01 to 02 Version
- Minor typographical changes.
0.4 Changes from 00 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 Attributes 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.
Contents Contents
1. Introduction and Problem Statement 3 1. Introduction and Problem Statement 3
1.1 Applicability to Generalized MPLS 4 1.1 Applicability to Generalized MPLS 4
1.2 A Rejected Alternate Solution 4 1.2 A Rejected Alternate Solution 4
2. Terminology 5 2. Terminology 5
3. Attributes TLVs 5 3. Attributes TLVs 5
3.1 Attributes Flags TLV 5 3.1 Attributes Flags TLV 6
4. LSP_ATTRIBUTES Object 6 4. LSP_ATTRIBUTES Object 6
4.1 Format 7 4.1 Format 7
4.2 Generic Processing Rules for Path Messages 7 4.2 Generic Processing Rules for Path Messages 7
4.3 Generic Processing Rules for Resv Messages 7 4.3 Generic Processing Rules for Resv Messages 8
5. LSP_REQUIRED_ATTRIBUTES Object 8 5. LSP_REQUIRED_ATTRIBUTES Object 8
5.1 Format 8 5.1 Format 9
5.2 Generic Processing Rules 9 5.2 Generic Processing Rules 9
6. Inheritance Rules 9 6. Inheritance Rules 10
7. Recording Attributes Per-LSP 9 7. Recording Attributes Per-LSP 10
7.1 Requirements 9 7.1 Requirements 10
7.2 RRO Attributes Subobject 10 7.2 RRO Attributes Subobject 10
7.3 Procedures 10 7.3 Procedures 11
7.3.1 Subobject Presence Rules 10 7.3.1 Subobject Presence Rules 11
7.3.2 Reporting Compliance with LSP Attributes 11 7.3.2 Reporting Compliance with LSP Attributes 12
7.3.3 Reporting Per-Hop Attributes 11 7.3.3 Reporting Per-Hop Attributes 12
7.3.4 Default Behavior 11 7.3.4 Default Behavior 12
8. Summary of Attribute Bit Allocation 11 8. Summary of Attribute Bit Allocation 12
9. Message Formats 12 9. Message Formats 13
10. IANA Considerations 13 10. Guidance for Key Application Scenarios 14
10.1 New RSVP C-Nums and C-Types 13 10.1 Communicating to Egress LSRs 14
10.2 New TLV Space 13 10.2 Communicating to Key Transit LSRs 15
10.3 Attributes Flags 14 10.3 Communicating to All LSRs 15
10.4 SESSION_ATTRIBUTE Flags Field 14 11. IANA Considerations 15
10.5 New Error Codes 14 11.1 New RSVP C-Nums and C-Types 15
10.6 New Record Route Subobject Identifier 14 11.2 New TLV Space 16
11. Security Considerations 15 11.3 Attributes Flags 16
12. Acknowledgements 15 11.4 SESSION_ATTRIBUTE Flags Field 17
13. Intellectual Property Consideration 15 11.5 New Error Codes 17
13.1 IPR Disclosure Acknowledgement 16 11.6 New Record Route Subobject Identifier 17
14. Normative References 16 12. Security Considerations 17
15. Informative References 16 13. Acknowledgements 18
16. Authors' Addresses 16 14. Intellectual Property Consideration 18
17. Full Copyright Statement 17 15. Normative References 18
16. Informative References 19
17. Authors' Addresses 19
18. Disclaimer of Validity 20
19. Full Copyright Statement 20
1. Introduction and Problem Statement 1. Introduction and Problem Statement
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
skipping to change at line 161 skipping to change at line 127
three bits available. Several recent proposals and Internet Drafts three bits available. Several recent proposals and Internet Drafts
have demonstrated that there is a high demand for the use of the have demonstrated that there is a high demand for the use of the
other three bits. Some, if not all, of those proposals are likely to other three bits. Some, if not all, of those proposals are likely to
go forward as RFCs resulting in depletion or near depletion of the go forward as RFCs resulting in depletion or near depletion of the
flags field and a consequent difficulty in signaling new options and flags field and a consequent difficulty in signaling new options and
attributes that may be developed in the future. attributes that may be developed in the future.
This document defines a new object for RSVP-TE messages that allows This document defines a new object for RSVP-TE messages that allows
the signaling of further attributes bits. The new object is the signaling of further attributes bits. The new object is
constructed from TLVs, and a new TLV is defined to carry a variable constructed from TLVs, and a new TLV is defined to carry a variable
number of attributes bits. Because of the nature of the TLV number of attributes bits.
construction the object is flexible and allows the future definition The new RSVP-TE message object is quite flexible, due to the use of
of: the TLV format and allows:
- further bit flags if further, distinct uses are discovered - future specification of bit flags
- arbitrary options and attributes parameters carried as individual - additional options and atttribute paramerters carried in TLV
TLVs. 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 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 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 LSR and egress LSR. Special
LSRs, such as Area or AS Border Routers (ABRs/ASBRs) may also fall transit LSRs, such as Area or AS Border Routers (ABRs/ASBRs) may also
into this category. This means that the new options and attributes fall into this category. This means that the new options and
should be signaled transparently, and only examined at those points attributes should be signaled transparently, and only examined at
that need to act on them. those points that need to act on them.
On the other hand, other options and attributes may require action On the other hand, other options and attributes may require action
at all transit LSRs along the path of the LSP. Inability to support at all transit LSRs along the path of the LSP. Inability to support
the required attributes by one of those transit LSRs may require the the required attributes by one of those transit LSRs may require the
LSR to refuse the establishment of the LSP. LSR to refuse the establishment of the LSP.
These considerations are particularly important in the context of These considerations are particularly important in the context of
backwards compatibility. In general, it should be possible to provide backwards compatibility. In general, it should be possible to provide
new MPLS services across a legacy network without upgrading those new MPLS services across a legacy network without upgrading those
LSRs that do not need to participate actively in the new services. LSRs that do not need to participate actively in the new services.
skipping to change at line 208 skipping to change at line 175
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: the first may be passed objects are defined in this document: using the C-Num definition
transparently by LSRs that do not recognize it, the second must cause rules inherrited from [RFC2205], the first is passed transparently
LSP setup failure with the generation of a PathErr message with an by LSRs that do not recognize it, and the second causes LSP setup
failure with the generation of a PathErr message with an
appropriate Error Code if an LSR does not recognize it. appropriate 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 intended to [RFC3473]. The extensions described in this document are equally
be equally applicable to MPLS and GMPLS. applicable to MPLS and GMPLS.
1.2 A Rejected Alternate Solution 1.2 A Rejected Alternate Solution
A rejected alternate solution was to define a new C-Type for the A rejected alternate solution was to define a new C-Type for the
existing SESSION_ATTRIBUTE object. This new C-Type could allow a existing SESSION_ATTRIBUTE object. This new C-Type could allow a
larger Flags field and address the immediate problem. larger Flags field and address the immediate problem.
This solution was rejected because: This solution was rejected because:
- A new C-Type is not backward compatible with deployed - A new C-Type is not backward compatible with deployed
implementations that expect to see a C-Type of 1 or 7. It is implementations that expect to see a C-Type of 1 or 7. It is
skipping to change at line 289 skipping to change at line 256
eight byte TLV with length field set to one. eight byte TLV with length field set to one.
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 (see section 11.2).
The Attributes Flags TLV may be present in an LSP_ATTRIBUTES object The Attributes Flags TLV may be present in an LSP_ATTRIBUTES object
and/or an LSP_REQUIRED_ATTRIBUTES object defined in Sections 4 and 5. and/or an LSP_REQUIRED_ATTRIBUTES object defined in Sections 4 and 5.
The bits in the TLV represent the same attributes regardless of which The bits in the TLV represent the same attributes regardless of which
object carries the TLV. Documents that define individual bits MUST object carries the TLV. Documents that define individual bits MUST
specify whether the bit may be set in one object or the other, or specify whether the bit may be set in one object or the other, or
both. It is not expected that a bit will be set in both objects on a 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 Attributes Flags TLV value field is a variable length array of The Attribute Flags TLV value field is an array of units of 32 flags
flags numbered from the MSB as bit zero. The length field for this numbered from the MSB as bit zero. The length field for this TLV is
TLV is always a multiple of 4 bytes, regardless of the number bits therefore always a multiple of 4 bytes, regardless of the number of
carried. bits carried and no padding is required.
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 by the originator of the object. Bits not contained on transmission by the originator of the object. Bits not contained
in the TLV MUST be assumed to be set to zero. If the TLV is absent 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_ either because it is not contained in the LSP_ATTRIBUTES or
REQUIRED_ATTRIBUTES object, or because those objects are themselves LSP_REQUIRED_ATTRIBUTES object, or because those objects are
absent, all processing MUST be performed as though the bits were themselves absent, all processing MUST be performed as though the
present and set to zero. bits were present and set to zero. That is to say, assigned bits that
are not present either because the TLV is deliberatley forshortened,
or because the TLV is not included MUST be treated as though they are
present and are set to zero.
No bits are defined in this document. The assignment of bits is No bits are defined in this document. The assignment of bits is
managed by IANA. managed by IANA (see section 11.3).
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
unexamined and unchanged. This facilitates the exchange of attributes unexamined and unchanged. This facilitates the exchange of attributes
across legacy networks that do not support this new object. across legacy networks that do not support this new object.
skipping to change at line 367 skipping to change at line 337
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// 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 will pass it on unaltered An LSR that does not support this object is required to pass it on
because of the C-Num. unaltered as indicated by the C-Num and the rules defined in
[RFC2205].
An LSR that does support this object, but does not recognize a TLV 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 type code carried in this object MUST pass the TLV on unaltered
in the LSP_ATTRIBUTES object that it places in the Path message in the LSP_ATTRIBUTES object that it places in the Path message
that it sends downstream. that it sends downstream.
An LSR that does support this object and recognizes a TLV but does An LSR that does support this object and recognizes a TLV but does
not support the attribute defined by the TLV MUST act as specified in not support the attribute defined by the TLV MUST act as specified in
the document that defines the TLV. the document that defines the TLV.
skipping to change at line 399 skipping to change at line 370
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
object as described in Section 7. object as described in Section 7.
The bits in the Attributes TLV may be used to report operational The bits in the Attributes TLV may be used to report operational
status for the whole LSP. For example, an egress may report a status for the whole LSP. For example, an egress LSR may report a
particular status by setting a bit. LSRs within the network that particular status by setting a bit. LSRs within the network that
determine that this status has not been achieved may clear the bit determine that this status has not been achieved may clear the bit
as they forward the Resv message. as they forward the Resv message.
Observe that LSRs that do not support the object or do not support Observe that LSRs that do not support the object or do not support
the function characterized by a particular bit in the Attributes TLV the function characterized by a particular bit in the Attributes TLV
will not clear the bit when forwarding the Resv. Thus, care must be will not clear the bit when forwarding the Resv. Thus, care must be
taken in defining the usage of this object on a Resv. The usage of taken in defining the usage of this object on a Resv. The usage of
an individual bit in the Attributes TLV of the LSP_ATTRIBUTES object an individual bit in the Attributes TLV of the LSP_ATTRIBUTES object
on a Resv must be fully defined in the document that defines the bit. on a Resv must be fully defined in the document that defines the bit.
skipping to change at line 424 skipping to change at line 395
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.
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 an LSP, or to indicate the nature or use of required in support of an LSP, or to indicate the nature or use of
an LSP where that information MUST be inspected at each transit LSR. an LSP where that information MUST be inspected at each transit LSR.
Specifically, each transit LSR MUST examine the attributes in the Specifically, each transit LSR MUST examine the attributes in the
LSP_REQUIRED_ATTRIBUTES object and MUST NOT forward the object LSP_REQUIRED_ATTRIBUTES object and MUST NOT forward the object
transparently. without acting on its contents.
This object effectively extends the flags field in the SESSION_ This object effectively extends the flags field in the SESSION_
ATTRIBUTE object and allows for the future inclusion of more complex ATTRIBUTE object and allows for the future inclusion of more complex
objects through TLVs. It complements the LSP_ATTRIBUTES object. objects through TLVs. It complements the LSP_ATTRIBUTES object.
The LSP_REQUIRED_ATTRIBUTES object class is TBD of the form 0bbbbbbb. The LSP_REQUIRED_ATTRIBUTES object class is TBD of the form 0bbbbbbb.
This C-Num value 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 used attributes requested. This means that this object SHOULD only be used
for attributes that require support at some transit LSRs and so for attributes that require support at some transit LSRs and so
skipping to change at line 485 skipping to change at line 456
specified in the document that defines that specific attribute. specified 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
FA-LSP (see [MPLS-HIER]) is initially setup to allow the establishment FA-LSP (see [MPLS-HIER]) is initially setup to allow the
of the LSP carrying the LSP ATTRIBUTES and/or LSP_REQUIRED_ATTRIBUTES establishment of the LSP carrying the LSP ATTRIBUTES and/or
objects. In this case, when the boundary LSR supports LSP_ATTRIBUTES LSP_REQUIRED_ATTRIBUTES objects. In this case, when the boundary LSR
and LSP_REQUIRED_ATTRIBUTES processing, the FA-LSP MAY upon local supports LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES processing, the
policy inherit a subset of the Attributes TLVs, in particular when the FA-LSP MAY upon local policy inherit a subset of the Attributes TLVs,
FA-LSP belongs to the same switching capability class than the in particular when the FA-LSP belongs to the same switching
triggering LSP. 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 TLV are considered as inheritable. Note that when the LSP Attributes TLV are considered as inheritable. Note that when the
FA-LSP establishment itself requires one or more Attributes TLVs, an FA-LSP establishment itself requires one or more Attributes TLVs, an
'OR' operation is performed with the inherited set of values. '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 Attributes Flags
TLV MUST specify whether these bits MAY be inherited or not (including TLV MUST specify whether these bits MAY be inherited or not
the condition to be met in order for this inheritance to occur). The (including the condition to be met in order for this inheritance to
same applies for any other TLV that will be defined following the occur). The same applies for any other TLV that will be defined
rules specified in Section 3. following the 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 line 553 skipping to change at line 524
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Attribute Flags // // Attribute Flags //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
0x?? TBD RRO Attribute Subobject 0x?? TBD by IANA RRO Attribute Subobject (see section 11.6).
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 4 and must be at least 8.
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
The Attributes subobject is pushed onto the RECORD_ROUTE object As will be clear from [RFC3209], the RECORD_ROUTE object is managed
immediately prior to pushing the node's IP address or link as a "stack" with each LSR adding sub-objects to the start of the
object. The Attributes subobject is pushed onto the RECORD_ROUTE
object immediately prior to pushing the node's IP address or link
identifier. Thus, if label recording is being used, the Attributes 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 on to the RECORD_ROUTE A node MUST NOT push an Attributes subobject on to 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.
This means that an Attributes subobject is bound to the LSR This means that an Attributes subobject is bound to the LSR
identified by the subobject found in the RRO immediately before the identified by the subobject found in the RRO immediately before the
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 [RFC3209]. (or Resv) message, the processing MUST be as described in section
4.4.3 of [RFC3209].
If more than one Attributes subobject is found between a pair of 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 stop 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 Attributes
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.
skipping to change at line 667 skipping to change at line 641
On a Path message, the LSP_ATTRIBUTES object and LSP_REQUIRED_ On a Path message, 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 MUST 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 and those objects MUST be within a Path message SHOULD be ignored and those objects MUST be
forwarded unchanged. forwarded 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 SHOULD 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. IANA Considerations 10. Guidance for Key Application Scenarios
10.1 New RSVP C-Nums and C-Types As described in the Introduction section of this document, it may be
that requested LSP attributes need to be acted on by only the egress
LSR of the LSP, by certain key transit points (such as ABRs and
ASBRs) or by all LSRs along the LSP. This section briefly describes
how each of these scenarios is met. This section is informational and
does not define any new procedures.
10.1. Communicating to Egress LSRs
When communicating LSP attributes that must be acted on only by the
LSP egress LSR, the attributes should be communicated in the
LSP_ATTRIBUTES object. Because of its C-Num, this object may be
ignored (passed onwards, untouched) by transit LSRs that do not
understand it. This means that the Path message will not be rejected
by LSRs that do not understand the object. In this way, the requested
LSP attributes are guaranteed to reach the egress LSR.
Attributes are set within the LSP_ATTRIBUTES object according to
which LSP attributes are required. Each attribute is defined in some
RFC and is accompanied by a statement of what the expected behavior
is. This behavior will include whether the attribute must be acted on
by any LSR that recognises it, or specifically by the egress LSR.
Thus any attribute that must be acted on only by an egress LSR will
be defined in this way - any transit LSR seeing this attribute will
either understand the semantics of the attribute and ignore it
(forwarding it, unchanged), or will not understand the attribute and
will ignore it (forwarding it, unchanged) according to the rules of
the LSP_ATTRIBUTES object.
The remaining issue is how the ingress LSR can know whether the
egress LSR has acted correctly on the required LSP attribute. Another
part of the definition of the attribute (in the defining RFC) is
whether reporting is required. If reporting is required, the egress
LSR is required to use the RRO Attributes subobject to report whether
it has acted on the received attribute.
If an egress LSR understands a received attribute as mandatory for an
egress LSR, but does not wish to satisfy the request, it will reject
the Path message. If an egress LSR understands the attribute, but
believes it to be optional and does not wish to satisfy the request,
it will report its non-compliance in the RRO Attributes subobject. If
the egress LSR does not understand the received attribute, it may
report non-compliance in the RRO Attributes subobject explicitly, or
may omit the RRO Attributes subobject implying that it has not
satisfied the request.
10.2. Communicating to Key Transit LSRs
Processing for key transit LSRs (such as ABRs and ASBRs) follows
exactly as for egress LSR. The only difference is that the definition
of the LSP attribute in the defining RFC will state that the
attribute must be acted on by these transit LSRs.
10.3. Communicating to All LSRs
In order to force all LSRs to examine the LSP attributes, the
LSP_REQUIRED_ATTRIBUTES object is used. The C-Num of this object is
such that any LSR that does not recognise the object must reject a
received Path message containing the object.
An LSR that recognises the LSP_REQUIRED_ATTRIBUTES object, but that
does not recognize an attributes will reject the Path message.
An LSR that recognizes an attribute, but which does not wish to
support the attribute reacts according to the definition of the
attribute in the defining RFC. This may allow the LSR to ignore the
attribute and forward it unchanged, or may require it to fail the LSP
setup. The LSR may additionally be required to report whether it
supports the attribute using the RRO Attributes subobject.
11. IANA Considerations
11.1 New RSVP C-Nums and C-Types
Two new RSVP C-Nums are defined in this document and 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 717 skipping to change at line 763
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.
10.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 T-field TLV includes a 16-bit type identifier (the T-field). The same T-field
values are applicable to both objects. values are applicable to both objects.
IANA is requested to manage TLV type identifiers as follows: IANA is requested to manage TLV type identifiers as follows:
- TLV Type (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 = 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.
10.3 Attributes Flags New TLV type values may be allocated only by an IETF Consensus
action.
11.3 Attributes Flags
This document provides new attributes bit flags for use in other 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 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 and numbering them in the usual IETF notation starting at zero and
continuing through 2039. continuing at least through 31.
New bit numbers may be allocated only by an IETF Consensus action.
Each bit should be tracked with the following qualities: 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 neither the context of this document for a bit to have no meaning in neither the
Attribute Flags TLV nor the RRO Attributes Subobject.) Attribute Flags TLV nor the RRO Attributes Subobject.)
10.4 SESSION_ATTRIBUTE Flags Field 11.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.
10.5 New Error Codes It is suggested that new SESSION_ATTRIBUTE Flags be allocated only by
an IETF Consensus action.
11.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.
10.6 New Record Route Subobject Identifier 11.6 New Record Route Subobject Identifier
A new subobject is defined for inclusion in the RECORD_ROUTE object. A new subobject is defined for inclusion in the RECORD_ROUTE object.
The RRO Attributes subobject is identified by a Type value of TBD. The RRO Attributes subobject is identified by a Type value of TBD.
11. Security Considerations 12. 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, and a new subobject to the RECORD_ROUTE in MPLS and GMPLS signaling, and a new subobject to the RECORD_ROUTE
object carried on may RSVP messages. It does not introduce any new object carried on may RSVP messages. It does not introduce any new
direct security issues and the reader is referred to the security 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
skipping to change at line 813 skipping to change at line 867
signaling message. signaling message.
Similarly, the addition of attribute recording information to the Similarly, the addition of attribute recording information to the
RRO may reveal information about the status of the LSP and the RRO 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.
12. 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 review to a similar problem. Thanks to Rahul Aggarwal for his careful review
and support of this work. Thanks also to Raymond Zhang, Kireeti and support of this work. Thanks also to Raymond Zhang, Kireeti
Kompella, Philip Matthews, Jim Gibson and Alan Kullberg for their Kompella, Philip Matthews, Jim Gibson and Alan Kullberg for their
input. As so often, thanks to John Drake for useful offline input. As so often, thanks to John Drake for useful offline
discussions. discussions. Thanks to Mike Shand for providing the Routing
Directorate review and to Joel Halpern for the General Area review -
both picked up on some unclarities.
13. Intellectual Property Consideration 14. Intellectual Property Consideration
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at line 846 skipping to change at line 902
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
14. 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. [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.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 16. Informative References
RFC 3667, February 2004.
[RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
15. 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.
[FRR] Pan, P. (Ed.), "Fast Reroute Extensions to RSVP-TE for [FRR] Pan, P. (Ed.), "Fast Reroute Extensions to RSVP-TE for
LSP Tunnels", <draft-ietf-mpls-rsvp-lsp-fastreroute-06 LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute,
.txt>, Internet Draft, work in progress. work in progress.
[MPLS-HIER] Kompella, K. and Y. Rekhter, "LSP Hierarchy with [MPLS-HIER] Kompella, K. and Y. Rekhter, "LSP Hierarchy with
MPLS TE", Work in Progress. MPLS TE", draft-ietf-mpls-lsp-hierarchy, work in
progress.
16. Authors' Addresses 17. 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
skipping to change at line 915 skipping to change at line 966
USA USA
EMail: jpv@cisco.com EMail: jpv@cisco.com
Arthi Ayyangar Arthi Ayyangar
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N.Mathilda Ave 1194 N.Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
EMail: arthi@juniper.net EMail: arthi@juniper.net
17. Disclaimer of Validity 18. Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
18. Full Copyright Statement 19. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
 End of changes. 

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