draft-ietf-mpls-generalized-rsvp-te-07.txt   draft-ietf-mpls-generalized-rsvp-te-08.txt 
Network Working Group Lou Berger - Editor (Movaz Networks) Network Working Group Lou Berger - Editor (Movaz Networks)
Internet Draft Peter Ashwood-Smith (Nortel Networks) Internet Draft
Expiration Date: October 2002 Ayan Banerjee (Calient Networks) Expiration Date: February 2003
Greg Bernstein (Ciena Corporation)
John Drake (Calient Networks)
Yanhe Fan (Axiowave Networks)
Kireeti Kompella (Juniper Networks)
Jonathan P. Lang (Calient Networks)
Fong Liaw (Solas Research)
Eric Mannie (KPNQwest)
Ping Pan (Juniper Networks, Inc.)
Bala Rajagopalan (Tellium)
Yakov Rekhter (Juniper Networks)
Debanjan Saha (Tellium)
Vishal Sharma (Metanoia)
George Swallow (Cisco Systems)
Z. Bo Tang (Tellium)
April 2002 August 2002
Generalized MPLS Signaling - RSVP-TE Extensions Generalized MPLS Signaling - RSVP-TE Extensions
draft-ietf-mpls-generalized-rsvp-te-07.txt draft-ietf-mpls-generalized-rsvp-te-08.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. 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."
To view the current status of any Internet-Draft, please check the To view the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
Directory, see http://www.ietf.org/shadow.html. Directory, see http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes extensions to RSVP-TE signaling required to This document describes extensions to MPLS (Multi-Protocol Label
support Generalized MPLS. Generalized MPLS extends MPLS to encompass Switching) RSVP-TE (Resource ReserVation Protocol - Traffic
time-division (e.g. SONET/SDH ADMs), wavelength (optical lambdas) and Engineering) signaling required to support Generalized MPLS.
spatial switching (e.g. incoming port or fiber to outgoing port or Generalized MPLS extends the MPLS control plane to encompass time-
fiber). This document presents an RSVP-TE specific description of division (e.g., Synchronous Optical Network and Synchronous Digital
the extensions. A generic functional description and a CR-LDP Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial
specific description can be found in separate documents. switching (e.g. incoming port or fiber to outgoing port or fiber).
This document presents a RSVP-TE specific description of the
extensions. A generic functional description can be found in
separate documents.
Contents Contents
1 Introduction ................................................ 3 1 Introduction ................................................ 3
2 Label Related Formats ...................................... 3 2 Label Related Formats ...................................... 3
2.1 Generalized Label Request Object ............................ 3 2.1 Generalized Label Request Object ............................ 3
2.2 Generalized Label Object .................................... 5 2.2 Bandwidth Encoding .......................................... 5
2.3 Waveband Switching .......................................... 6 2.3 Generalized Label Object .................................... 5
2.4 Suggested Label ............................................. 7 2.4 Waveband Switching .......................................... 6
2.5 Label Set ................................................... 7 2.5 Suggested Label ............................................. 7
2.6 Label Set ................................................... 7
3 Bidirectional LSPs .......................................... 9 3 Bidirectional LSPs .......................................... 9
3.1 Procedures .................................................. 9 3.1 Procedures .................................................. 9
3.2 Contention Resolution ....................................... 10 3.2 Contention Resolution ....................................... 10
4 Notification ................................................ 10 4 Notification ................................................ 10
4.1 Acceptable Label Set Object ................................. 10 4.1 Acceptable Label Set Object ................................. 10
4.2 Notify Request Objects ...................................... 11 4.2 Notify Request Objects ...................................... 11
4.3 Notify Message .............................................. 12 4.3 Notify Message .............................................. 12
4.4 Removing State with a PathErr message ....................... 14 4.4 Removing State with a PathErr message ....................... 14
5 Explicit Label Control ...................................... 15 5 Explicit Label Control ...................................... 15
5.1 Label ERO subobject ......................................... 15 5.1 Label ERO subobject ......................................... 15
skipping to change at page 2, line 44 skipping to change at page 2, line 45
9 Fault Handling .............................................. 25 9 Fault Handling .............................................. 25
9.1 Restart_Cap Object .......................................... 26 9.1 Restart_Cap Object .......................................... 26
9.2 Processing of Restart_Cap Object ............................ 27 9.2 Processing of Restart_Cap Object ............................ 27
9.3 Modification to Hello Processing to Support State Recovery .. 27 9.3 Modification to Hello Processing to Support State Recovery .. 27
9.4 Control Channel Faults ...................................... 28 9.4 Control Channel Faults ...................................... 28
9.5 Nodal Faults ................................................ 28 9.5 Nodal Faults ................................................ 28
10 RSVP Message Formats and Handling ........................... 31 10 RSVP Message Formats and Handling ........................... 31
10.1 RSVP Message Formats ........................................ 31 10.1 RSVP Message Formats ........................................ 31
10.2 Addressing Path and PathTear Messages ...................... 33 10.2 Addressing Path and PathTear Messages ...................... 33
11 Acknowledgments ............................................. 33 11 Acknowledgments ............................................. 33
12 Security Considerations ..................................... 33 12 Security Considerations ..................................... 34
13 IANA Considerations ......................................... 34 13 IANA Considerations ......................................... 34
13.1 IANA [Suggestions /] Assignments ............................ 35 13.1 IANA [Suggestions /] Assignments ............................ 35
14 References .................................................. 36 14 Intellectual Property Considerations ........................ 37
14.1 Normative References ........................................ 37 15 References .................................................. 37
14.2 Informative References ...................................... 37 15.1 Normative References ........................................ 37
15 Authors' Addresses .......................................... 38 15.2 Informative References ...................................... 38
16 Contributors ................................................ 38
[Editor's note: changes to be removed prior to publication as an RFC.] 17 Contact Address ............................................. 41
Changes from previous version:
o Reorder author's list to indicate primary contact
o Fixed indication of infinite restart time
o Added IANA [Suggestions /] Assignments Section
o Split references section
o Minor editorial changes and clarifications
1. Introduction 1. Introduction
Generalized MPLS extends MPLS from supporting packet (PSC) interfaces Generalized MPLS extends MPLS from supporting packet (PSC) interfaces
and switching to include support of three new classes of interfaces and switching to include support of three new classes of interfaces
and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and
Fiber-Switch (FSC). A functional description of the extensions to Fiber-Switch (FSC). A functional description of the extensions to
MPLS signaling needed to support the new classes of interfaces and MPLS signaling needed to support the new classes of interfaces and
switching is provided in [GMPLS-SIG]. This document presents RSVP-TE switching is provided in [GMPLS-SIG]. This document presents RSVP-TE
specific formats and mechanisms needed to support all four classes of specific formats and mechanisms needed to support all four classes of
interfaces. CR-LDP extensions can be found in [GMPLS-LDP]. interfaces.
[GMPLS-SIG] should be viewed as a companion document to this [GMPLS-SIG] should be viewed as a companion document to this
document. The format of this document parallels [GMPLS-SIG]. In document. The format of this document parallels [GMPLS-SIG]. In
addition to the other features of Generalized MPLS, this document addition to the other features of Generalized MPLS, this document
also defines RSVP-TE specific features to support rapid failure also defines RSVP-TE specific features to support rapid failure
notification, see Sections 4.2 and 4.3. notification, see Sections 4.2 and 4.3.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Label Related Formats 2. Label Related Formats
This section defines formats for a generalized label request, a This section defines formats for a generalized label request, a
generalized label, support for waveband switching, suggested label generalized label, support for waveband switching, suggested label
and label sets. and label sets.
2.1. Generalized Label Request Object 2.1. Generalized Label Request Object
A Path message SHOULD contain as specific an LSP Encoding Type as A Path message SHOULD contain as specific an LSP (Label Switched
possible to allow the maximum flexibility in switching by transit Path) Encoding Type as possible to allow the maximum flexibility in
LSRs. A Generalized Label Request object is set by the ingress node, switching by transit LSRs. A Generalized Label Request object is set
transparently passed by transit nodes, and used by the egress node. by the ingress node, transparently passed by transit nodes, and used
The Switching Type field may also be updated hop-by-hop. by the egress node. The Switching Type field may also be updated
hop-by-hop.
The format of a Generalized Label Request object is: The format of a Generalized Label Request object is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (19)|C-Type (4)[TBA]| | Length | Class-Num (19)|C-Type (4)[TBA]|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | G-PID | | LSP Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 12 skipping to change at page 5, line 5
G-PID is not supported, then the penultimate hop MUST generate a G-PID is not supported, then the penultimate hop MUST generate a
ResvErr message with a "Routing problem/Unacceptable label value" ResvErr message with a "Routing problem/Unacceptable label value"
indication. The generated ResvErr message MAY include an Acceptable indication. The generated ResvErr message MAY include an Acceptable
Label Set, see Section 4.1. Label Set, see Section 4.1.
When an error message is not generated, normal processing occurs. In When an error message is not generated, normal processing occurs. In
the transit case this will typically result in a Path message being the transit case this will typically result in a Path message being
propagated. In the egress case and PHP special case this will propagated. In the egress case and PHP special case this will
typically result in a Resv message being generated. typically result in a Resv message being generated.
2.1.2. Bandwidth Encoding 2.2. Bandwidth Encoding
Bandwidth encodings are carried in the SENDER_TSPEC and FLOWSPEC Bandwidth encodings are carried in the SENDER_TSPEC and FLOWSPEC
objects. See [GMPLS-SIG] for a definition of values to be used for objects. See [GMPLS-SIG] for a definition of values to be used for
specific signal types. These values are set in the Peak Data Rate specific signal types. These values are set in the Peak Data Rate
field of Int-Serv objects. Other bandwidth/service related field of Int-Serv objects, see [RFC2210]. Other bandwidth/service
parameters in the object are ignored and carried transparently. related parameters in the object are ignored and carried
transparently.
2.2. Generalized Label Object 2.3. Generalized Label Object
The format of a Generalized Label object is: The format of a Generalized Label object is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (16)| C-Type (2) | | Length | Class-Num (16)| C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | | Label |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of parameters and encoding of See [GMPLS-SIG] for a description of parameters and encoding of
labels. labels.
2.2.1. Procedures 2.3.1. Procedures
The Generalized Label travels in the upstream direction in Resv The Generalized Label travels in the upstream direction in Resv
messages. messages.
The presence of both a generalized and normal label object in a Resv The presence of both a generalized and normal label object in a Resv
message is a protocol error and should treated as a malformed message message is a protocol error and should treated as a malformed message
by the recipient. by the recipient.
The recipient of a Resv message containing a Generalized Label The recipient of a Resv message containing a Generalized Label
verifies that the values passed are acceptable. If the label is verifies that the values passed are acceptable. If the label is
unacceptable then the recipient MUST generate a ResvErr message with unacceptable then the recipient MUST generate a ResvErr message with
a "Routing problem/MPLS label allocation failure" indication. a "Routing problem/MPLS label allocation failure" indication.
2.3. Waveband Switching 2.4. Waveband Switching
Waveband switching uses the same format as the generalized label, see Waveband switching uses the same format as the generalized label, see
section 2.2. Waveband Label uses C-Type (3), section 2.2. Waveband Label uses C-Type (3),
In the context of waveband switching, the generalized label has the In the context of waveband switching, the generalized label has the
following format: following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 29 skipping to change at page 6, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Waveband Id | | Waveband Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Label | | Start Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Label | | End Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of parameters. See [GMPLS-SIG] for a description of parameters.
2.3.1. Procedures 2.4.1. Procedures
The procedures defined in Section 2.2.1 apply to waveband switching. The procedures defined in Section 2.2.1 apply to waveband switching.
This includes generating a ResvErr message with a "Routing This includes generating a ResvErr message with a "Routing
problem/MPLS label allocation failure" indication if any of the label problem/MPLS label allocation failure" indication if any of the label
fields are unrecognized or unacceptable. fields are unrecognized or unacceptable.
Additionally, when a waveband is switched to another waveband, it is Additionally, when a waveband is switched to another waveband, it is
possible that the wavelengths within the waveband will be mirrored possible that the wavelengths within the waveband will be mirrored
about a center frequency. When this type of switching is employed, about a center frequency. When this type of switching is employed,
the start and end label in the waveband label object MUST be flipped the start and end label in the waveband label object MUST be flipped
before forwarding the label object with the new waveband Id. In this before forwarding the label object with the new waveband Id. In this
manner an egress/ingress LSR which receives a waveband label which manner an egress/ingress LSR which receives a waveband label which
has these values inverted, knows that it must also invert its egress has these values inverted, knows that it must also invert its egress
association to pick up the proper wavelengths. association to pick up the proper wavelengths.
This operation MUST be performed in both directions when a This operation MUST be performed in both directions when a
bidirectional waveband tunnel is being established. bidirectional waveband tunnel is being established.
2.4. Suggested Label 2.5. Suggested Label
The format of a Suggested_Label object is identical to a generalized The format of a Suggested_Label object is identical to a generalized
label. It is used in Path messages. A Suggested_Label object uses label. It is used in Path messages. A Suggested_Label object uses
Class-Number TBA (of form 10bbbbbb) and the C-Type of the label being Class-Number TBA (of form 10bbbbbb) and the C-Type of the label being
suggested. suggested.
Errors in received Suggested_Label objects MUST be ignored. This Errors in received Suggested_Label objects MUST be ignored. This
includes any received inconsistent or unacceptable values. includes any received inconsistent or unacceptable values.
Per [GMPLS-SIG], if a downstream node passes a label value that Per [GMPLS-SIG], if a downstream node passes a label value that
differs from the suggested label upstream, the upstream LSR MUST differs from the suggested label upstream, the upstream LSR MUST
either reconfigure itself so that it uses the label specified by the either reconfigure itself so that it uses the label specified by the
downstream node or generate a ResvErr message with a "Routing downstream node or generate a ResvErr message with a "Routing
problem/Unacceptable label value" indication. Furthermore, an problem/Unacceptable label value" indication. Furthermore, an
ingress node SHOULD NOT transmit data traffic using a suggested label ingress node SHOULD NOT transmit data traffic using a suggested label
until the downstream node passes a corresponding label upstream. until the downstream node passes a corresponding label upstream.
2.5. Label Set 2.6. Label Set
The Label_Set object uses Class-Number TBA (of form 0bbbbbbb) and the The Label_Set object uses Class-Number TBA (of form 0bbbbbbb) and the
C-Type of 1. It is used in Path messages. C-Type of 1. It is used in Path messages.
The format of a Label_Set is: The format of a Label_Set is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(TBA)| C-Type (1) | | Length | Class-Num(TBA)| C-Type (1) |
skipping to change at page 8, line 12 skipping to change at page 8, line 12
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label Type: 14 bits Label Type: 14 bits
Indicates the type and format of the labels carried in the Indicates the type and format of the labels carried in the
object. Values match the C-Type of the appropriate Label object. Values match the C-Type of the appropriate Label
object. Only the low order 8 bits are used in this field. object. Only the low order 8 bits are used in this field.
See [GMPLS-SIG] for a description of other parameters. See [GMPLS-SIG] for a description of other parameters.
2.5.1. Procedures 2.6.1. Procedures
A Label Set is defined via one or more Label_Set objects. Specific A Label Set is defined via one or more Label_Set objects. Specific
labels/subchannels can be added to or excluded from a Label Set via labels/subchannels can be added to or excluded from a Label Set via
Action zero (0) and one (1) objects respectively. Ranges of Action zero (0) and one (1) objects respectively. Ranges of
labels/subchannels can be added to or excluded from a Label Set via labels/subchannels can be added to or excluded from a Label Set via
Action two (2) and three (3) objects respectively. When the Action two (2) and three (3) objects respectively. When the
Label_Set objects only list labels/subchannels to exclude, this Label_Set objects only list labels/subchannels to exclude, this
implies that all other labels are acceptable. implies that all other labels are acceptable.
The absence of any Label_Set objects implies that all labels are The absence of any Label_Set objects implies that all labels are
skipping to change at page 10, line 32 skipping to change at page 10, line 32
extension, the Notify Request object, identifies where event extension, the Notify Request object, identifies where event
notifications are to be sent. The third extension, the Notify notifications are to be sent. The third extension, the Notify
message, provides for general event notification.) The final message, provides for general event notification.) The final
notification related extension allows for the removal of Path state notification related extension allows for the removal of Path state
on handling of PathErr messages. on handling of PathErr messages.
4.1. Acceptable Label Set Object 4.1. Acceptable Label Set Object
Acceptable_Label_Set objects use a Class-Number TBA (of form Acceptable_Label_Set objects use a Class-Number TBA (of form
10bbbbbb). The remaining contents of the object, including C-Type, 10bbbbbb). The remaining contents of the object, including C-Type,
have the identical format as the Label_Set object, see Section 2.5. have the identical format as the Label_Set object, see Section 2.6.
Acceptable_Label_Set objects may be carried in PathErr and ResvErr Acceptable_Label_Set objects may be carried in PathErr and ResvErr
messages. The procedures for defining an Acceptable Label Set follow messages. The procedures for defining an Acceptable Label Set follow
the procedures for defining a Label Set, see Section 2.5.1. the procedures for defining a Label Set, see Section 2.6.1.
Specifically, an Acceptable Label Set is defined via one or more Specifically, an Acceptable Label Set is defined via one or more
Acceptable_Label_Set objects. Specific labels/subchannels can be Acceptable_Label_Set objects. Specific labels/subchannels can be
added to or excluded from an Acceptable Label Set via Action zero added to or excluded from an Acceptable Label Set via Action zero
(0) and one (1) objects respectively. Ranges of labels/subchannels (0) and one (1) objects respectively. Ranges of labels/subchannels
can be added to or excluded from an Acceptable Label Set via Action can be added to or excluded from an Acceptable Label Set via Action
two (2) and three (3) objects respectively. When the two (2) and three (3) objects respectively. When the
Acceptable_Label_Set objects only list labels/subchannels to exclude, Acceptable_Label_Set objects only list labels/subchannels to exclude,
this implies that all other labels are acceptable. this implies that all other labels are acceptable.
The inclusion of Acceptable_Label_Set objects is optional. If The inclusion of Acceptable_Label_Set objects is optional. If
skipping to change at page 12, line 36 skipping to change at page 12, line 36
The Notify message provides a mechanism to inform non-adjacent nodes The Notify message provides a mechanism to inform non-adjacent nodes
of LSP related events. Notify messages are normally generated only of LSP related events. Notify messages are normally generated only
after a Notify Request object has been received. The Notify message after a Notify Request object has been received. The Notify message
differs from the currently defined error messages (i.e., PathErr and differs from the currently defined error messages (i.e., PathErr and
ResvErr messages) in that it can be "targeted" to a node other than ResvErr messages) in that it can be "targeted" to a node other than
the immediate upstream or downstream neighbor and that it is a the immediate upstream or downstream neighbor and that it is a
generalized notification mechanism. The Notify message does not generalized notification mechanism. The Notify message does not
replace existing error messages. The Notify message may be sent replace existing error messages. The Notify message may be sent
either (a) normally, where non-target nodes just forward the Notify either (a) normally, where non-target nodes just forward the Notify
message to the target node, similar to ResvConf processing in [RSVP]; message to the target node, similar to ResvConf processing in
or (b) encapsulated in a new IP header whose destination is equal to [RFC2205]; or (b) encapsulated in a new IP header whose destination
the target IP address. Regardless of the transmission mechanism, is equal to the target IP address. Regardless of the transmission
nodes receiving a Notify message not destined to the node forward the mechanism, nodes receiving a Notify message not destined to the node
message, unmodified, towards the target. forward the message, unmodified, towards the target.
To support reliable delivery of the Notify message, an Ack Message To support reliable delivery of the Notify message, an Ack Message
[RFC2961] is used to acknowledge the receipt of a Notify Message. [RFC2961] is used to acknowledge the receipt of a Notify Message.
See [RFC2961] for details on reliable RSVP message delivery. See [RFC2961] for details on reliable RSVP message delivery.
4.3.1. Required Information 4.3.1. Required Information
The Notify message is a generalized notification message. The IP The Notify message is a generalized notification message. The IP
destination address is set to the IP address of the intended destination address is set to the IP address of the intended
receiver. The Notify message is sent without the router alert receiver. The Notify message is sent without the router alert
skipping to change at page 15, line 23 skipping to change at page 15, line 23
an error with the Path_State_Removed flag set to zero MUST NOT set an error with the Path_State_Removed flag set to zero MUST NOT set
this flag unless it also generates a corresponding PathTear message. this flag unless it also generates a corresponding PathTear message.
Note that the use of this flag does not result in any Note that the use of this flag does not result in any
interoperability incompatibilities. interoperability incompatibilities.
5. Explicit Label Control 5. Explicit Label Control
The Label ERO and RRO subobjects are defined to support Explicit The Label ERO and RRO subobjects are defined to support Explicit
Label Control. Note that the Label RRO subobject was defined in Label Control. Note that the Label RRO subobject was defined in
[RFC3209] and is being revised to support bidirectional LSPs. [RFC3209] and is being extended to support bidirectional LSPs.
5.1. Label ERO subobject 5.1. Label ERO subobject
The Label ERO subobject is defined as follows: The Label ERO subobject is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length |U| Reserved | C-Type | |L| Type | Length |U| Reserved | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 23 skipping to change at page 16, line 23
Object. Object.
5.1.1. Procedures 5.1.1. Procedures
The Label subobject follows a subobject containing the IP address, or The Label subobject follows a subobject containing the IP address, or
the interface identifier [MPLS-UNNUM], associated with the link on the interface identifier [MPLS-UNNUM], associated with the link on
which it is to be used. Up to two label subobjects may be present, which it is to be used. Up to two label subobjects may be present,
one for the downstream label and one for the upstream label. The one for the downstream label and one for the upstream label. The
following SHOULD result in "Bad EXPLICIT_ROUTE object" errors: following SHOULD result in "Bad EXPLICIT_ROUTE object" errors:
- If the first label subobject is not preceded by a subobject - If the first label subobject is not preceded by a subobject
containing an IP address, or a interface identifier containing an IP address, or an interface identifier
[MPLS-UNNUM], associated with an output link. [MPLS-UNNUM], associated with an output link.
- For a label subobject to follow a subobject that has the L-bit - For a label subobject to follow a subobject that has the L-bit
set set
- On unidirectional LSP setup, for there to be a label subobject - On unidirectional LSP setup, for there to be a label subobject
with the U-bit set with the U-bit set
- For there to be two label subobjects with the same U-bit values - For there to be two label subobjects with the same U-bit values
To support the label subobject, a node must check to see if the To support the label subobject, a node must check to see if the
subobject following its associate address/interface is a label subobject following its associate address/interface is a label
subobject. If it is, one subobject is examined for unidirectional subobject. If it is, one subobject is examined for unidirectional
skipping to change at page 23, line 49 skipping to change at page 23, line 49
bidirectional LSP that traverses a bundled link, it is possible to bidirectional LSP that traverses a bundled link, it is possible to
specify a downstream data channel that differs from the upstream data specify a downstream data channel that differs from the upstream data
channel. Data channels are specified from the view point of the channel. Data channels are specified from the view point of the
sender of the Path message. The IF_ID RSVP_HOP object SHOULD NOT be sender of the Path message. The IF_ID RSVP_HOP object SHOULD NOT be
used when no TLVs are needed. used when no TLVs are needed.
A node receiving one or more TLVs in a Path message saves their A node receiving one or more TLVs in a Path message saves their
values and returns them in the HOP objects of subsequent Resv values and returns them in the HOP objects of subsequent Resv
messages sent to the node that originated the TLVs. messages sent to the node that originated the TLVs.
As with [MPLS-TE], the node originating an IF_ID object must ensure Note, the node originating an IF_ID object MUST ensure that the
that the selected outgoing interface is consistent with the outgoing selected outgoing interface, as specified in the IF_ID object, is
ERO. A node that receives an IF_ID object SHOULD check whether the consistent with an ERO. A node that receives an IF_ID object SHOULD
information carried in this object is consistent with the information check whether the information carried in this object is consistent
carried in a received ERO, and if not it MUST send a PathErr with the with the information carried in a received ERO, and if not it MUST
error code "Routing Error" and error value of "Bad Explicit Route send a PathErr Message with the error code "Routing Error" and error
Object" toward the sender. value of "Bad Explicit Route Object" toward the sender. This check
CANNOT be performed when the initial ERO subobject is not the
incoming interface.
8.2. Errored Interface Identification 8.2. Errored Interface Identification
There are cases where it is useful to indicate a specific interface There are cases where it is useful to indicate a specific interface
associated with an error. To support these cases the IF_ID associated with an error. To support these cases the IF_ID
ERROR_SPEC Objects are defined. ERROR_SPEC Objects are defined.
8.2.1. IF_ID ERROR_SPEC Objects 8.2.1. IF_ID ERROR_SPEC Objects
The format of the IPv4 IF_ID ERROR_SPEC Object is: The format of the IPv4 IF_ID ERROR_SPEC Object is:
skipping to change at page 25, line 25 skipping to change at page 25, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value | | Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ TLVs ~ ~ TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC2205] for a description of address, flags, error code and See [RFC2205] for a description of address, flags, error code and
error value fields. See [GMPLS-SIG] for a description of error value fields. See [GMPLS-SIG] for a description of
parameters and encoding of TLVs.n parameters and encoding of TLVs.
8.2.2. Procedures 8.2.2. Procedures
Nodes wishing to indicate that an error is related to a specific Nodes wishing to indicate that an error is related to a specific
interface SHOULD use the appropriate IF_ID ERROR_SPEC Object in the interface SHOULD use the appropriate IF_ID ERROR_SPEC Object in the
corresponding PathErr or ResvErr message. IF_ID ERROR_SPEC Objects corresponding PathErr or ResvErr message. IF_ID ERROR_SPEC Objects
SHOULD be generated and processed as any other ERROR_SPEC Object, see SHOULD be generated and processed as any other ERROR_SPEC Object, see
[RFC2205]. [RFC2205].
9. Fault Handling 9. Fault Handling
skipping to change at page 27, line 23 skipping to change at page 27, line 23
When a node receives a Hello message with the Restart_Cap object, it When a node receives a Hello message with the Restart_Cap object, it
SHOULD record the values of the parameters received. SHOULD record the values of the parameters received.
9.3. Modification to Hello Processing to Support State Recovery 9.3. Modification to Hello Processing to Support State Recovery
When a node determines that RSVP communication with a neighbor has When a node determines that RSVP communication with a neighbor has
been lost, and the node previously learned that the neighbor supports been lost, and the node previously learned that the neighbor supports
state recovery, the node SHOULD wait at least the amount of time state recovery, the node SHOULD wait at least the amount of time
indicated by the Restart Time indicated by the neighbor before indicated by the Restart Time indicated by the neighbor before
invoking procedures related to communication loss. A node MAY wait invoking procedures related to communication loss. A node MAY wait a
longer based on local policy or configuration information. different amount of time based on local policy or configuration
information.
During this waiting period, all Hello messages MUST be sent with a During this waiting period, all Hello messages MUST be sent with a
Dst_Instance value set to zero (0), and Src_Instance should be Dst_Instance value set to zero (0), and Src_Instance should be
unchanged. While waiting, the node SHOULD also preserve the RSVP and unchanged. While waiting, the node SHOULD also preserve the RSVP and
MPLS forwarding state for (already) established LSPs that traverse MPLS forwarding state for (already) established LSPs that traverse
the link(s) between the node and the neighbor. In a sense with the link(s) between the node and the neighbor. In a sense with
respect to established LSPs the node behaves as if it continues to respect to established LSPs the node behaves as if it continues to
receive periodic RSVP refresh messages from the neighbor. The node receive periodic RSVP refresh messages from the neighbor. The node
MAY clear RSVP and forwarding state for the LSPs that are in the MAY clear RSVP and forwarding state for the LSPs that are in the
process of being established when their refresh timers expire. process of being established when their refresh timers expire.
skipping to change at page 36, line 42 skipping to change at page 37, line 5
o "Routing problem/Label Set" (Suggested value =11) o "Routing problem/Label Set" (Suggested value =11)
o "Routing problem/Switching Type" (Suggested value =12) o "Routing problem/Switching Type" (Suggested value =12)
(duplicate code 13 dropped) (duplicate code 13 dropped)
o "Routing problem/Unsupported Encoding" (Suggested value =14) o "Routing problem/Unsupported Encoding" (Suggested value =14)
o "Routing problem/Unsupported Link Protection" (Suggested value =15) o "Routing problem/Unsupported Link Protection" (Suggested value =15)
o "Notify Error/Control Channel Active State" (Suggested value =4) o "Notify Error/Control Channel Active State" (Suggested value =4)
o "Notify Error/Control Channel Degraded State" (Suggested value =5) o "Notify Error/Control Channel Degraded State" (Suggested value =5)
--------------------------------------------------------------------- ---------------------------------------------------------------------
14. References 14. Intellectual Property Considerations
14.1. Normative References This section is taken from Section 10.4 of [RFC2026].
[MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links The IETF takes no position regarding the validity or scope of any
in RSVP-TE", Internet Draft, intellectual property or other rights that might be claimed to
draft-ietf-mpls-rsvp-unnum-02.txt, August 2001 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
15. References
15.1. Normative References
[GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS - [GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS -
Signaling Functional Description", Internet Draft, Signaling Functional Description", Internet Draft,
draft-ietf-mpls-generalized-signaling-08.txt, draft-ietf-mpls-generalized-signaling-09.txt,
April 2002. August 2002.
[MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links
in RSVP-TE", Internet Draft,
draft-ietf-mpls-rsvp-unnum-07.txt, July 2002.
[RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol [RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol
-- Version 1 Functional Specification", RFC 2205, -- Version 1 Functional Specification", RFC 2205,
September 1997. September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services," RFC 2210, September 1997.
[RFC2961] Berger, L. et al, "RSVP Refresh Overhead Reduction [RFC2961] Berger, L. et al, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 2001 Extensions", RFC 2961, April 2001
[RFC3209] Awduche, et al, "RSVP-TE: Extensions to RSVP for [RFC3209] Awduche, et al, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001. LSP Tunnels", RFC 3209, December 2001.
14.2. Informative References 15.2. Informative References
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[MPLS-HIERARCHY] Kompella, K., and Rekhter, Y., "LSP Hierarchy with [MPLS-HIERARCHY] Kompella, K., and Rekhter, Y., "LSP Hierarchy with
MPLS TE", Internet Draft, MPLS TE", Internet Draft,
draft-ietf-mpls-lsp-hierarchy-02.txt, Feb., 2001. draft-ietf-mpls-lsp-hierarchy-02.txt, Feb., 2001.
[GMPLS-LDP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling -
CR-LDP Extensions", Internet Draft,
draft-ietf-mpls-generalized-cr-ldp-06.txt,
April 2002.
[PAN-RESTART] Pan, P, et al, "Graceful Restart Mechanism for RSVP-TE", [PAN-RESTART] Pan, P, et al, "Graceful Restart Mechanism for RSVP-TE",
Internet Draft, draft-pan-rsvp-te-restart-01.txt, Internet Draft, draft-pan-rsvp-te-restart-01.txt,
July 2001. July 2001.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3,"
RFC 2026.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119. Requirement Levels," RFC 2119.
15. Authors' Addresses 16. Contributors
Peter Ashwood-Smith Peter Ashwood-Smith
Nortel Networks Corp. Nortel Networks Corp.
P.O. Box 3511 Station C, P.O. Box 3511 Station C,
Ottawa, ON K1Y 4H7 Ottawa, ON K1Y 4H7
Canada Canada
Phone: +1 613 763 4534 Phone: +1 613 763 4534
Email: petera@nortelnetworks.com Email: petera@nortelnetworks.com
Ayan Banerjee Ayan Banerjee
Calient Networks Calient Networks
5853 Rue Ferrari 5853 Rue Ferrari
San Jose, CA 95138 San Jose, CA 95138
Phone: +1 408 972-3645 Phone: +1 408 972-3645
Email: abanerjee@calient.net Email: abanerjee@calient.net
Lou Berger
Lou Berger Editor & Primary Point of Contact
Movaz Networks, Inc. Movaz Networks, Inc.
7926 Jones Branch Drive 7926 Jones Branch Drive
Suite 615 Suite 615
McLean VA, 22102 McLean VA, 22102
Phone: +1 703 847-1801 Phone: +1 703 847-1801
Email: lberger@movaz.com Email: lberger@movaz.com
Greg Bernstein Greg Bernstein
Ciena Corporation Ciena Corporation
10480 Ridgeview Court 10480 Ridgeview Court
skipping to change at page 39, line 30 skipping to change at page 40, line 14
Eric Mannie Eric Mannie
KPNQwest KPNQwest
Terhulpsesteenweg 6A Terhulpsesteenweg 6A
1560 Hoeilaart - Belgium 1560 Hoeilaart - Belgium
Phone: +32 2 658 56 52 Phone: +32 2 658 56 52
Mobile: +32 496 58 56 52 Mobile: +32 496 58 56 52
Fax: +32 2 658 51 18 Fax: +32 2 658 51 18
Email: eric.mannie@kpnqwest.com Email: eric.mannie@kpnqwest.com
Ping Pan Ping Pan
Juniper Networks Ciena
1194 N.Mathilda Ave 10480 Ridgeview Court
Sunnyvale, CA 94089 Cupertino, CA 95014
Email: pingpan@juniper.net Phone: 408-366-4700
Email: ppan@ciena.com
Bala Rajagopalan Bala Rajagopalan
Tellium, Inc. Tellium, Inc.
2 Crescent Place 2 Crescent Place
P.O. Box 901 P.O. Box 901
Oceanport, NJ 07757-0901 Oceanport, NJ 07757-0901
Phone: +1 732 923 4237 Phone: +1 732 923 4237
Fax: +1 732 923 9804 Fax: +1 732 923 9804
Email: braja@tellium.com Email: braja@tellium.com
skipping to change at line 1748 skipping to change at page 41, line 20
Z. Bo Tang Z. Bo Tang
Tellium, Inc. Tellium, Inc.
2 Crescent Place 2 Crescent Place
P.O. Box 901 P.O. Box 901
Oceanport, NJ 07757-0901 Oceanport, NJ 07757-0901
Phone: +1 732 923 4231 Phone: +1 732 923 4231
Fax: +1 732 923 9804 Fax: +1 732 923 9804
Email: btang@tellium.com Email: btang@tellium.com
Generated on: Thu Apr 25 12:57:53 2002 17. Contact Address
Lou Berger
Movaz Networks, Inc.
7926 Jones Branch Drive
Suite 615
McLean VA, 22102
Phone: +1 703 847-1801
Email: lberger@movaz.com
Generated on: Wed Aug 28 10:40:33 2002
 End of changes. 

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