draft-ietf-mpls-generalized-rsvp-te-09.txt   rfc3473.txt 
Network Working Group Lou Berger - Editor (Movaz Networks)
Internet Draft
Expiration Date: March 2003
September 2002
Generalized MPLS Signaling - RSVP-TE Extensions Network Working Group L. Berger, Editor
Request for Comments: 3473 Movaz Networks
Category: Standards Track January 2003
draft-ietf-mpls-generalized-rsvp-te-09.txt Generalized Multi-Protocol Label Switching (GMPLS) Signaling
Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026. Internet-Drafts are working Internet community, and requests discussion and suggestions for
documents of the Internet Engineering Task Force (IETF), its areas, improvements. Please refer to the current edition of the "Internet
and its working groups. Note that other groups may also distribute Official Protocol Standards" (STD 1) for the standardization state
working documents as Internet-Drafts. and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six months Copyright Notice
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To view the current status of any Internet-Draft, please check the Copyright (C) The Internet Society (2003). All Rights Reserved.
"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
Directory, see http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes extensions to MPLS (Multi-Protocol Label This document describes extensions to Multi-Protocol Label Switching
Switching) RSVP-TE (Resource ReserVation Protocol - Traffic (MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE)
Engineering) signaling required to support Generalized MPLS. signaling required to support Generalized MPLS. Generalized MPLS
Generalized MPLS extends the MPLS control plane to encompass time- extends the MPLS control plane to encompass time-division (e.g.,
division (e.g., Synchronous Optical Network and Synchronous Digital Synchronous Optical Network and Synchronous Digital Hierarchy,
Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g.,
switching (e.g. incoming port or fiber to outgoing port or fiber). incoming port or fiber to outgoing port or fiber). This document
This document presents a RSVP-TE specific description of the presents a RSVP-TE specific description of the extensions. A generic
extensions. A generic functional description can be found in functional description can be found in separate documents.
separate documents.
Contents Table of Contents
1. Introduction .............................................. 2
2. Label Related Formats .................................... 3
2.1 Generalized Label Request Object ........................ 3
2.2 Bandwidth Encoding ...................................... 4
2.3 Generalized Label Object ................................ 5
2.4 Waveband Switching ...................................... 5
2.5 Suggested Label ......................................... 6
2.6 Label Set ............................................... 7
3. Bidirectional LSPs ........................................ 8
3.1 Procedures .............................................. 9
3.2 Contention Resolution ................................... 9
4. Notification .............................................. 9
4.1 Acceptable Label Set Object ............................. 10
4.2 Notify Request Objects .................................. 10
4.3 Notify Message .......................................... 12
4.4 Removing State with a PathErr message ................... 14
5. Explicit Label Control .................................... 15
5.1 Label ERO subobject ..................................... 15
5.2 Label RRO subobject ..................................... 16
6. Protection Object ......................................... 17
6.1 Procedures .............................................. 18
7. Administrative Status Information ......................... 18
7.1 Admin Status Object ..................................... 18
7.2 Path and Resv Message Procedures ........................ 18
7.3 Notify Message Procedures ............................... 20
8. Control Channel Separation ................................ 21
8.1 Interface Identification ................................ 21
8.2 Errored Interface Identification ........................ 23
9. Fault Handling ............................................ 25
9.1 Restart_Cap Object ...................................... 25
9.2 Processing of Restart_Cap Object ........................ 26
9.3 Modification to Hello Processing to Support
State Recovery .......................................... 26
9.4 Control Channel Faults .................................. 27
9.5 Nodal Faults ............................................ 27
10. RSVP Message Formats and Handling ......................... 30
10.1 RSVP Message Formats ................................... 30
10.2 Addressing Path and PathTear Messages ................. 32
11. Acknowledgments ........................................... 32
12. Security Considerations ................................... 33
13. IANA Considerations ....................................... 34
13.1 IANA Assignments ....................................... 35
14. Intellectual Property Considerations ...................... 36
15. References ................................................ 37
15.1 Normative References ................................... 37
15.2 Informative References ................................. 38
16. Contributors .............................................. 38
17. Editor's Address .......................................... 41
18. Full Copyright Statement .................................. 42
1 Introduction ................................................ 3
2 Label Related Formats ...................................... 3
2.1 Generalized Label Request Object ............................ 3
2.2 Bandwidth Encoding .......................................... 5
2.3 Generalized Label Object .................................... 5
2.4 Waveband Switching .......................................... 6
2.5 Suggested Label ............................................. 7
2.6 Label Set ................................................... 7
3 Bidirectional LSPs .......................................... 9
3.1 Procedures .................................................. 9
3.2 Contention Resolution ....................................... 10
4 Notification ................................................ 10
4.1 Acceptable Label Set Object ................................. 10
4.2 Notify Request Objects ...................................... 11
4.3 Notify Message .............................................. 12
4.4 Removing State with a PathErr message ....................... 14
5 Explicit Label Control ...................................... 15
5.1 Label ERO subobject ......................................... 15
5.2 Label RRO subobject ......................................... 17
6 Protection Object ........................................... 18
6.1 Procedures .................................................. 18
7 Administrative Status Information ........................... 18
7.1 Admin Status Object ......................................... 18
7.2 Path and Resv Message Procedures ............................ 19
7.3 Notify Message Procedures ................................... 21
8 Control Channel Separation .................................. 22
8.1 Interface Identification .................................... 22
8.2 Errored Interface Identification ............................ 24
9 Fault Handling .............................................. 25
9.1 Restart_Cap Object .......................................... 26
9.2 Processing of Restart_Cap Object ............................ 27
9.3 Modification to Hello Processing to Support State Recovery .. 27
9.4 Control Channel Faults ...................................... 28
9.5 Nodal Faults ................................................ 28
10 RSVP Message Formats and Handling ........................... 31
10.1 RSVP Message Formats ........................................ 31
10.2 Addressing Path and PathTear Messages ...................... 33
11 Acknowledgments ............................................. 33
12 Security Considerations ..................................... 34
13 IANA Considerations ......................................... 35
13.1 IANA [Suggestions /] Assignments ............................ 36
14 Intellectual Property Considerations ........................ 37
15 References .................................................. 38
15.1 Normative References ........................................ 38
15.2 Informative References ...................................... 39
16 Contributors ................................................ 39
17 Contact Address ............................................. 42
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 [RFC3471]. 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. interfaces.
[GMPLS-SIG] should be viewed as a companion document to this [RFC3471] should be viewed as a companion document to this document.
document. The format of this document parallels [GMPLS-SIG]. In The format of this document parallels [RFC3471]. In addition to the
addition to the other features of Generalized MPLS, this document other features of Generalized MPLS, this document also defines RSVP-
also defines RSVP-TE specific features to support rapid failure TE specific features to support rapid failure notification, see
notification, see Sections 4.2 and 4.3. 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.
skipping to change at page 3, line 42 skipping to change at page 3, line 32
A Path message SHOULD contain as specific an LSP (Label Switched A Path message SHOULD contain as specific an LSP (Label Switched
Path) Encoding Type as possible to allow the maximum flexibility in Path) Encoding Type as possible to allow the maximum flexibility in
switching by transit LSRs. A Generalized Label Request object is set switching by transit LSRs. A Generalized Label Request object is set
by the ingress node, transparently passed by transit nodes, and used by the ingress node, transparently passed by transit nodes, and used
by the egress node. The Switching Type field may also be updated by the egress node. The Switching Type field may also be updated
hop-by-hop. 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | G-PID | | LSP Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of parameters.
See [RFC3471] for a description of parameters.
2.1.1. Procedures 2.1.1. Procedures
A node processing a Path message containing a Generalized Label A node processing a Path message containing a Generalized Label
Request must verify that the requested parameters can be satisfied by Request must verify that the requested parameters can be satisfied by
the interface on which the incoming label is to be allocated, the the interface on which the incoming label is to be allocated, the
node itself, and by the interface on which the traffic will be node itself, and by the interface on which the traffic will be
transmitted. The node may either directly support the LSP or it may transmitted. The node may either directly support the LSP or it may
use a tunnel (FA), i.e., another class of switching. In either case, use a tunnel (FA), i.e., another class of switching. In either case,
each parameter must be checked. each parameter must be checked.
skipping to change at page 4, line 37 skipping to change at page 4, line 26
Nodes MUST verify that the type indicated in the Switching Type Nodes MUST verify that the type indicated in the Switching Type
parameter is supported on the corresponding incoming interface. If parameter is supported on the corresponding incoming interface. If
the type cannot be supported, the node MUST generate a PathErr the type cannot be supported, the node MUST generate a PathErr
message with a "Routing problem/Switching Type" indication. message with a "Routing problem/Switching Type" indication.
The G-PID parameter is normally only examined at the egress. If the The G-PID parameter is normally only examined at the egress. If the
indicated G-PID cannot be supported then the egress MUST generate a indicated G-PID cannot be supported then the egress MUST generate a
PathErr message, with a "Routing problem/Unsupported L3PID" PathErr message, with a "Routing problem/Unsupported L3PID"
indication. In the case of PSC and when penultimate hop popping indication. In the case of PSC and when penultimate hop popping
(PHP) is requested, the penultimate hop also examines the (stored) G- (PHP) is requested, the penultimate hop also examines the (stored)
PID during the processing of the Resv message. In this case if the G-PID during the processing of the Resv message. In this case if the
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.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 [RFC3471] 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, see [RFC2210]. Other bandwidth/service field of Int-Serv objects, see [RFC2210]. Other bandwidth/service
related parameters in the object are ignored and carried related parameters in the object are ignored and carried
transparently. transparently.
2.3. 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 [RFC3471] for a description of parameters and encoding of labels.
labels.
2.3.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.4. Waveband Switching 2.4. Waveband Switching Object
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (16)| C-Type (3) | | Length | Class-Num (16)| C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Waveband Id | | Waveband Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Label | | Start Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Label | | End Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of parameters. See [RFC3471] for a description of parameters.
2.4.1. Procedures 2.4.1. Procedures
The procedures defined in Section 2.2.1 apply to waveband switching. The procedures defined in Section 2.3.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.5. Suggested Label 2.5. Suggested Label Object
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 129 (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 [RFC3471], if a downstream node passes a label value that differs
differs from the suggested label upstream, the upstream LSR MUST from the suggested label upstream, the upstream LSR MUST either
either reconfigure itself so that it uses the label specified by the 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.6. Label Set 2.6. Label Set Object
The Label_Set object uses Class-Number TBA (of form 0bbbbbbb) and the The Label_Set object uses Class-Number 36 (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 (36)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved | Label Type | | Action | Reserved | Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 | | Subchannel 1 |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : : : :
: : : : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel N | | Subchannel N |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label Type: 14 bits
Indicates the type and format of the labels carried in the Label Type: 14 bits
object. Values match the C-Type of the appropriate Label
object. Only the low order 8 bits are used in this field.
See [GMPLS-SIG] for a description of other parameters. Indicates the type and format of the labels carried in the object.
Values match the C-Type of the appropriate RSVP_LABEL object.
Only the low order 8 bits are used in this field.
See [RFC3471] for a description of other parameters.
2.6.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.
skipping to change at page 8, line 42 skipping to change at page 8, line 25
"Routing problem/Label Set" indication MUST be generated. It is a "Routing problem/Label Set" indication MUST be generated. It is a
local matter if the Label Set is stored for later selection on the local matter if the Label Set is stored for later selection on the
Resv or if the selection is made immediately for propagation in the Resv or if the selection is made immediately for propagation in the
Resv. Resv.
On reception of a Path message, the Label Set represented in the On reception of a Path message, the Label Set represented in the
message is compared against the set of available labels at the message is compared against the set of available labels at the
downstream interface and the resulting intersecting Label Set is downstream interface and the resulting intersecting Label Set is
forwarded in a Path message. When the resulting Label Set is empty, forwarded in a Path message. When the resulting Label Set is empty,
the Path must be terminated, and a PathErr message, and a "Routing the Path must be terminated, and a PathErr message, and a "Routing
problem/Label Set" indication MUST be generated. Note that problem/Label Set" indication MUST be generated. Note that
intersection is based on the physical labels (actual wavelength/band intersection is based on the physical labels (actual wavelength/band
values) which may have different logical values on different links, values) which may have different logical values on different links,
as a result it is the responsibility of the node to map these values as a result it is the responsibility of the node to map these values
so that they have a consistent physical meaning, or to drop the so that they have a consistent physical meaning, or to drop the
particular values from the set if no suitable logical label value particular values from the set if no suitable logical label value
exists. exists.
When processing a Resv message at an intermediate node, the label When processing a Resv message at an intermediate node, the label
propagated upstream MUST fall within the Label Set. propagated upstream MUST fall within the Label Set.
Note, on reception of a Resv message a node that is incapable of Note, on reception of a Resv message a node that is incapable of
performing label conversion has no other choice than to use the same performing label conversion has no other choice than to use the same
physical label (wavelength/band) as received in the Resv message. In physical label (wavelength/band) as received in the Resv message. In
this case, the use and propagation of a Label Set will significantly this case, the use and propagation of a Label Set will significantly
reduce the chances that this allocation will fail. reduce the chances that this allocation will fail.
3. Bidirectional LSPs 3. Bidirectional LSPs
Bidirectional LSP setup is indicated by the presence of an Upstream Bidirectional LSP setup is indicated by the presence of an Upstream
Label in the Path message. An Upstream_Label object has the same Label in the Path message. An Upstream_Label object has the same
format as the generalized label, see Section 2.2. The Upstream_Label format as the generalized label, see Section 2.3. The Upstream_Label
object uses Class-Number TBA (of form 0bbbbbbb) and the C-Type of the object uses Class-Number 35 (of form 0bbbbbbb) and the C-Type of the
label being used. label being used.
3.1. Procedures 3.1. Procedures
The process of establishing a bidirectional LSP follows the The process of establishing a bidirectional LSP follows the
establishment of a unidirectional LSP with some additions. To establishment of a unidirectional LSP with some additions. To
support bidirectional LSPs an Upstream_Label object is added to the support bidirectional LSPs an Upstream_Label object is added to the
Path message. The Upstream_Label object MUST indicate a label that Path message. The Upstream_Label object MUST indicate a label that
is valid for forwarding at the time the Path message is sent. is valid for forwarding at the time the Path message is sent.
skipping to change at page 10, line 19 skipping to change at page 9, line 49
that for the purposes of RSVP contention resolution, the node ID is that for the purposes of RSVP contention resolution, the node ID is
the IP address used in the RSVP_HOP object. The second is that a the IP address used in the RSVP_HOP object. The second is that a
neighbor's node ID might not be known when sending an initial Path neighbor's node ID might not be known when sending an initial Path
message. When this case occurs, a node should suggest a label chosen message. When this case occurs, a node should suggest a label chosen
at random from the available label space. at random from the available label space.
4. Notification 4. Notification
This section covers several notification related extensions. The This section covers several notification related extensions. The
first extension defines the Acceptable Label Set object to support first extension defines the Acceptable Label Set object to support
Notification on Label Error, per [GMPLS-SIG]. The second and third Notification on Label Error, per [RFC3471]. The second and third
extensions enable expedited notification of failures and other events extensions enable expedited notification of failures and other events
to nodes responsible for restoring failed LSPs. (The second to nodes responsible for restoring failed LSPs. (The second
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 130 (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.6. 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.6.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
skipping to change at page 11, line 15 skipping to change at page 10, line 42
4.2. Notify Request Objects 4.2. Notify Request Objects
Notifications may be sent via the Notify message defined below. The Notifications may be sent via the Notify message defined below. The
Notify Request object is used to request the generation of Notify Request object is used to request the generation of
notifications. Notifications, i.e., the sending of a Notify message, notifications. Notifications, i.e., the sending of a Notify message,
may be requested in both the upstream and downstream directions. may be requested in both the upstream and downstream directions.
4.2.1. Required Information 4.2.1. Required Information
The Notify Request Object may be carried in Path or Resv Messages, The Notify Request Object may be carried in Path or Resv Messages,
see Section 7. The Notify_Request Class-Number is TBA (of form see Section 7. The Notify_Request Class-Number is 195 (of form
11bbbbbb). The format of a Notify Request is: 11bbbbbb). The format of a Notify Request is:
o IPv4 Notify Request Object o IPv4 Notify Request Object
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(TBA)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Notify Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Notify Node Address: 32 bits 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (1) | C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Notify Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IP address of the node that should be notified when IPv4 Notify Node Address: 32 bits
generating an error message.
o IPv6 Notify Request Object The IP address of the node that should be notified when generating
0 1 2 3 an error message.
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 (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Notify Node Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Notify Node Address: 16 bytes o IPv6 Notify Request Object
The IP address of the node that should be notified when 0 1 2 3
generating an error message. 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 (2) | C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Notify Node Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Notify Node Address: 16 bytes
The IP address of the node that should be notified when generating
an error message.
If a message contains multiple Notify_Request objects, only the first If a message contains multiple Notify_Request objects, only the first
object is meaningful. Subsequent Notify_Request objects MAY be object is meaningful. Subsequent Notify_Request objects MAY be
ignored and SHOULD NOT be propagated. ignored and SHOULD NOT be propagated.
4.2.2. Procedures 4.2.2. Procedures
A Notify Request object may be inserted in Path or Resv messages to A Notify Request object may be inserted in Path or Resv messages to
indicate the address of a node that should be notified of an LSP indicate the address of a node that should be notified of an LSP
failure. As previously mentioned, notifications may be requested in failure. As previously mentioned, notifications may be requested in
both the upstream and downstream directions. Upstream notification is both the upstream and downstream directions. Upstream notification
indicated via the inclusion of a Notify Request Object in the is indicated via the inclusion of a Notify Request Object in the
corresponding Path message. Downstream notification is indicated via corresponding Path message. Downstream notification is indicated via
the inclusion of a Notify Request Object in the corresponding Resv the inclusion of a Notify Request Object in the corresponding Resv
message. message.
A node receiving a message containing a Notify Request object SHOULD A node receiving a message containing a Notify Request object SHOULD
store the Notify Node Address in the corresponding state block. If store the Notify Node Address in the corresponding state block. If
the node is a transit node, it SHOULD also included a Notify Request the node is a transit node, it SHOULD also included a Notify Request
object in the outgoing Path or Resv message. The outgoing Notify object in the outgoing Path or Resv message. The outgoing Notify
Node Address MAY be updated based on local policy. Node Address MAY be updated based on local policy.
skipping to change at page 13, line 14 skipping to change at page 12, line 44
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
option. A single Notify message may contain notifications being option. A single Notify message may contain notifications being
sent, with respect to each listed session, both upstream and sent, with respect to each listed session, both upstream and
downstream. downstream.
The Notify message has a Message Type of TBA (by IANA). The Notify The Notify message has a Message Type of 21. The Notify message
message format is as follows: format is as follows:
<Notify message> ::= <Common Header> [<INTEGRITY>] <Notify message> ::= <Common Header> [<INTEGRITY>]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ] [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ] [ <MESSAGE_ID> ]
<ERROR_SPEC> <notify session list> <ERROR_SPEC> <notify session list>
<notify session list> ::= [ <notify session list> ] <notify session list> ::= [ <notify session list> ]
<upstream notify session> | <upstream notify session> |
<downstream notify session> <downstream notify session>
<upstream notify session> ::= <SESSION> [ <ADMIN_STATUS> ] <upstream notify session> ::= <SESSION> [ <ADMIN_STATUS> ]
[<POLICY_DATA>...] [<POLICY_DATA>...]
<sender descriptor> <sender descriptor>
<downstream notify session> ::= <SESSION> [<POLICY_DATA>...] <downstream notify session> ::= <SESSION> [<POLICY_DATA>...]
<flow descriptor list> <flow descriptor list>
The ERROR_SPEC object specifies the error and includes the IP address The ERROR_SPEC object specifies the error and includes the IP address
of either the node that detected the error or the link that has of either the node that detected the error or the link that has
failed. See ERROR_SPEC definition in [RFC2205]. The MESSAGE_ID and failed. See ERROR_SPEC definition in [RFC2205]. The MESSAGE_ID and
related objects are defined in [RFC2961] and are used when refresh related objects are defined in [RFC2961] and are used when [RFC2961]
reductions is supported. is supported.
4.3.2. Procedures 4.3.2. Procedures
Notify messages are most commonly generated at nodes that detect an Notify messages are most commonly generated at nodes that detect an
error that will trigger the generation of a PathErr or ResvErr error that will trigger the generation of a PathErr or ResvErr
message. If a PathErr message is to be generated and a Notify message. If a PathErr message is to be generated and a Notify
Request object has been received in the corresponding Path message, Request object has been received in the corresponding Path message,
then a Notify message destined to the recorded node SHOULD be then a Notify message destined to the recorded node SHOULD be
generated. If a ResvErr message is to be generated and a Notify generated. If a ResvErr message is to be generated and a Notify
Request object has been received in the corresponding Resv message, Request object has been received in the corresponding Resv message,
skipping to change at page 15, line 21 skipping to change at page 15, line 7
PathErr message. A node which does not remove the associated Path PathErr message. A node which does not remove the associated Path
state MUST NOT set the Path_State_Removed flag. A node that receives state MUST NOT set the Path_State_Removed flag. A node that receives
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 (Explicit Route Object) and RRO (Record Route Object)
Label Control. Note that the Label RRO subobject was defined in subobjects are defined to support Explicit Label Control. Note that
[RFC3209] and is being extended to support bidirectional LSPs. the Label RRO subobject was defined in [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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | | Label |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of L, U and Label parameters. See [RFC3471] for a description of L, U and Label parameters.
Type Type
3 Label 3 Label
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. The Length is always including the Type and Length fields. The Length is always
divisible by 4. divisible by 4.
C-Type C-Type
The C-Type of the included Label Object. Copied from the Label The C-Type of the included Label Object. Copied from the Label
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 [RFC3477], associated with the link on which
which it is to be used. Up to two label subobjects may be present, it is to be used. Up to two label subobjects may be present, one for
one for the downstream label and one for the upstream label. The the downstream label and one for the upstream label. The following
following SHOULD result in "Bad EXPLICIT_ROUTE object" errors: SHOULD result in "Bad EXPLICIT_ROUTE object" errors:
- If the first label subobject is not preceded by a subobject
containing an IP address, or an interface identifier o If the first label subobject is not preceded by a subobject
[MPLS-UNNUM], associated with an output link. containing an IP address, or an interface identifier [RFC3477],
- For a label subobject to follow a subobject that has the L-bit associated with an output link.
set
- On unidirectional LSP setup, for there to be a label subobject o For a label subobject to follow a subobject that has the L-bit set
with the U-bit set
- For there to be two label subobjects with the same U-bit values o On unidirectional LSP setup, for there to be a label subobject with
the U-bit set
o 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
LSPs and two subobjects for bidirectional LSPs. If the U-bit of the LSPs and two subobjects for bidirectional LSPs. If the U-bit of the
subobject being examined is clear (0), then value of the label is subobject being examined is clear (0), then value of the label is
copied into a new Label_Set object. This Label_Set object MUST be copied into a new Label_Set object. This Label_Set object MUST be
included on the corresponding outgoing Path message. included on the corresponding outgoing Path message.
If the U-bit of the subobject being examined is set (1), then value If the U-bit of the subobject being examined is set (1), then value
skipping to change at page 17, line 15 skipping to change at page 16, line 43
received ERO, then it SHOULD be treated as a "Bad strict node" error. received ERO, then it SHOULD be treated as a "Bad strict node" error.
Procedures by which an LSR at the head-end of an LSP obtains the Procedures by which an LSR at the head-end of an LSP obtains the
information needed to construct the Label subobject are outside the information needed to construct the Label subobject are outside the
scope of this document. scope of this document.
5.2. Label RRO subobject 5.2. Label RRO subobject
The Label RRO subobject is defined as follows: The Label RRO 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |U| Flags | C-Type | | Type | Length |U| Flags | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | | Label |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of U and Label parameters. See [RFC3471] for a description of U and Label parameters.
Type Type
3 Label 3 Label
Length Length
See [RFC3209]. See [RFC3209].
Flags Flags
See [RFC3209]. See [RFC3209].
C-Type C-Type
The C-Type of the included Label Object. Copied from the Label The C-Type of the included Label Object. Copied from the Label
Object. Object.
5.2.1. Procedures 5.2.1. Procedures
Label RRO subobjects are included in RROs as described in [RFC3209]. Label RRO subobjects are included in RROs as described in [RFC3209].
The only modification to usage and processing from [RFC3209] is that The only modification to usage and processing from [RFC3209] is that
when labels are recorded for bidirectional LSPs, label ERO subobjects when labels are recorded for bidirectional LSPs, label ERO subobjects
for both downstream and upstream labels MUST be included. for both downstream and upstream labels MUST be included.
6. Protection Object 6. Protection Object
The use of the Protection Object is optional. The object is included The use of the Protection Object is optional. The object is included
to indicate specific protection attributes of an LSP. The Protection to indicate specific protection attributes of an LSP. The Protection
Object uses Class-Number TBA (of form 0bbbbbbb). Object uses Class-Number 37 (of form 0bbbbbbb).
The format of the Protection Object is: The format of the Protection 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(TBA)| C-Type (1) | | Length | Class-Num (37)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Link Flags| |S| Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of parameters. See [RFC3471] for a description of parameters.
6.1. Procedures 6.1. Procedures
Transit nodes processing a Path message containing a Protection Transit nodes processing a Path message containing a Protection
Object MUST verify that the requested protection can be satisfied by Object MUST verify that the requested protection can be satisfied by
the outgoing interface or tunnel (FA). If it cannot, the node MUST the outgoing interface or tunnel (FA). If it cannot, the node MUST
generate a PathErr message, with a "Routing problem/Unsupported Link generate a PathErr message, with a "Routing problem/Unsupported Link
Protection" indication. Protection" indication.
7. Administrative Status Information 7. Administrative Status Information
skipping to change at page 18, line 44 skipping to change at page 18, line 26
object. The object provides information related to the object. The object provides information related to the
administrative state of a particular LSP. The information is used in administrative state of a particular LSP. The information is used in
two ways. In the first, the object is carried in Path and Resv two ways. In the first, the object is carried in Path and Resv
messages to indicate the administrative state of an LSP. In the messages to indicate the administrative state of an LSP. In the
second, the object is carried in a Notification message to request second, the object is carried in a Notification message to request
that the ingress node change the administrative state of an LSP. that the ingress node change the administrative state of an LSP.
7.1. Admin Status Object 7.1. Admin Status Object
The use of the Admin_Status Object is optional. It uses Class-Number The use of the Admin_Status Object is optional. It uses Class-Number
TBA (of form 11bbbbbb). 196 (of form 11bbbbbb).
The format of the Admin_Status Object is: The format of the Admin_Status 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(TBA)| C-Type (1) | | Length | Class-Num(196)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |T|A|D| |R| Reserved |T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of parameters. See [RFC3471] for a description of parameters.
7.2. Path and Resv Message Procedures 7.2. Path and Resv Message Procedures
The Admin_Status object is used to notify each node along the path of The Admin_Status object is used to notify each node along the path of
the status of the LSP. Status information is processed by each node the status of the LSP. Status information is processed by each node
based on local policy and then propagated in the corresponding based on local policy and then propagated in the corresponding
outgoing messages. The object may be inserted in either Path or Resv outgoing messages. The object may be inserted in either Path or Resv
messages at the discretion of the ingress (for Path messages) or messages at the discretion of the ingress (for Path messages) or
egress (for Resv messages) nodes. The absence of the object is egress (for Resv messages) nodes. The absence of the object is
equivalent to receiving an object containing values all set to zero equivalent to receiving an object containing values all set to zero
skipping to change at page 20, line 20 skipping to change at page 19, line 45
also ensure that subsequent Path messages sent by the node contain also ensure that subsequent Path messages sent by the node contain
the same Admin Status Object. the same Admin Status Object.
7.2.1. Deletion procedure 7.2.1. Deletion procedure
In some circumstances, particularly optical networks, it is useful to In some circumstances, particularly optical networks, it is useful to
set the administrative status of an LSP before tearing it down. In set the administrative status of an LSP before tearing it down. In
such circumstances the procedure SHOULD be followed when deleting an such circumstances the procedure SHOULD be followed when deleting an
LSP from the ingress: LSP from the ingress:
1. The ingress node precedes an LSP deletion by inserting an Admin 1. The ingress node precedes an LSP deletion by inserting an Admin
Status Object in a Path message and setting the Reflect (R) and Status Object in a Path message and setting the Reflect (R) and
Delete (D) bits. Delete (D) bits.
2. Transit and egress nodes process the Admin Status Object as 2. Transit and egress nodes process the Admin Status Object as
described above. (Alternatively, the egress MAY respond with described above. (Alternatively, the egress MAY respond with a
a PathErr message with the Path_State_Removed flag set, see PathErr message with the Path_State_Removed flag set, see section
section 4.4.) 4.4.)
3. Upon receiving the Admin Status Object with the Delete (D) bit set 3. Upon receiving the Admin Status Object with the Delete (D) bit set
in the Resv message, the ingress node sends a PathTear message in the Resv message, the ingress node sends a PathTear message
downstream to remove the LSP and normal RSVP processing takes place. downstream to remove the LSP and normal RSVP processing takes
place.
In such circumstances the procedure SHOULD be followed when deleting In such circumstances the procedure SHOULD be followed when deleting
an LSP from the egress: an LSP from the egress:
1. The egress node indicates its desire for deletion by inserting 1. The egress node indicates its desire for deletion by inserting an
an Admin Status Object in a Resv message and setting the Reflect (R) Admin Status Object in a Resv message and setting the Reflect (R)
and Delete (D) bits. and Delete (D) bits.
2. Transit nodes process the Admin Status Object as described above. 2. Transit nodes process the Admin Status Object as described above.
3. Upon receiving the Admin Status Object with the Delete (D) bit set 3. Upon receiving the Admin Status Object with the Delete (D) bit set
in the Resv message, the ingress node sends a PathTear message in the Resv message, the ingress node sends a PathTear message
downstream to remove the LSP and normal RSVP processing takes place. downstream to remove the LSP and normal RSVP processing takes
place.
7.2.2. Compatibility and Error Procedures 7.2.2. Compatibility and Error Procedures
It is possible that some nodes along an LSP will not support the It is possible that some nodes along an LSP will not support the
Admin Status Object. In the case of a non-supporting transit node, Admin Status Object. In the case of a non-supporting transit node,
the object will pass through the node unmodified and normal the object will pass through the node unmodified and normal
processing can continue. In the case of a non-supporting egress processing can continue. In the case of a non-supporting egress
node, the Admin Status Object will not be reflected back in the Resv node, the Admin Status Object will not be reflected back in the Resv
Message. To support the case of a non-supporting egress node, the Message. To support the case of a non-supporting egress node, the
ingress SHOULD only wait a configurable period of time for the ingress SHOULD only wait a configurable period of time for the
skipping to change at page 22, line 28 skipping to change at page 22, line 9
in each direction. In all cases but bundling, the upstream interface in each direction. In all cases but bundling, the upstream interface
is implied by the downstream interface. For bundling, the path is implied by the downstream interface. For bundling, the path
sender explicitly identifies the component interface used in each sender explicitly identifies the component interface used in each
direction. The new RSVP_HOP object is used in Resv message to direction. The new RSVP_HOP object is used in Resv message to
indicate the downstream node's usage of the indicated interface(s). indicate the downstream node's usage of the indicated interface(s).
8.1.1. IF_ID RSVP_HOP Objects 8.1.1. IF_ID RSVP_HOP Objects
The format of the IPv4 IF_ID RSVP_HOP Object is: The format of the IPv4 IF_ID RSVP_HOP 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 (3) | C-Type (3)TBA | | Length | Class-Num (3) | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Next/Previous Hop Address | | IPv4 Next/Previous Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface Handle | | Logical Interface Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ TLVs ~ ~ TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the IPv6 IF_ID RSVP_HOP Object is: The format of the IPv6 IF_ID RSVP_HOP 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 (3) | C-Type (4)TBA | | Length | Class-Num (3) | C-Type (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IPv6 Next/Previous Hop Address | | IPv6 Next/Previous Hop Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface Handle | | Logical Interface Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ TLVs ~ ~ TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC2205] for a description of hop address and handle fields. See [RFC2205] for a description of hop address and handle fields.
See [GMPLS-SIG] for a description of parameters and encoding of See [RFC3471] for a description of parameters and encoding of
TLVs. TLVs.
8.1.2. Procedures 8.1.2. Procedures
An IF_ID RSVP_HOP object is used in place of previously defined An IF_ID RSVP_HOP object is used in place of previously defined
RSVP_HOP objects. It is used on links where there is not a one-to- RSVP_HOP objects. It is used on links where there is not a one-to-
one association of a control channel to a data channel, see [GMPLS- one association of a control channel to a data channel, see
SIG]. The Hop Address and Logical Interface Handle fields are used [RFC3471]. The Hop Address and Logical Interface Handle fields are
per standard RSVP [RFC2205]. used per standard RSVP [RFC2205].
TLVs are used to identify the data channel(s) associated with an LSP. TLVs are used to identify the data channel(s) associated with an LSP.
For a unidirectional LSP, a downstream data channel MUST be For a unidirectional LSP, a downstream data channel MUST be
indicated. For bidirectional LSPs, a common downstream and upstream indicated. For bidirectional LSPs, a common downstream and upstream
data channel is normally indicated. In the special case where a data channel is normally indicated. In the special case where a
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 viewpoint of the channel. Data channels are specified from the viewpoint 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.
skipping to change at page 24, line 22 skipping to change at page 24, line 9
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:
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 (6) | C-Type (3)TBA | | Length | Class-Num (6) | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Error Node Address | | IPv4 Error Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value | | Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ TLVs ~ ~ TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the IPv6 IF_ID ERROR_SPEC Object is: The format of the IPv6 IF_ID ERROR_SPEC 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 (6) | C-Type (4)TBA | | Length | Class-Num (6) | C-Type (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IPv6 Error Node Address | | IPv6 Error Node Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 [RFC3471] for a description of parameters
parameters and encoding of TLVs. 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 26, line 13 skipping to change at page 25, line 28
channel failures. channel failures.
Please note this section is derived from [PAN-RESTART]. Please note this section is derived from [PAN-RESTART].
9.1. Restart_Cap Object 9.1. Restart_Cap Object
The Restart_Cap Object is carried in Hello messages. The Restart_Cap Object is carried in Hello messages.
The format of the Restart_Cap Object is: The format of the Restart_Cap 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(TBA)| C-Type (1) | | Length | Class-Num(131)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Restart Time | | Restart Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recovery Time | | Recovery Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Restart Time: 32 bits Restart Time: 32 bits
Restart Time is measured in milliseconds. Restart Time SHOULD Restart Time is measured in milliseconds. Restart Time SHOULD be
be set to the sum of the time it takes the sender of the object set to the sum of the time it takes the sender of the object to
to restart its RSVP-TE component (to the point where it can restart its RSVP-TE component (to the point where it can exchange
exchange RSVP Hello with its neighbors) and the communication RSVP Hello with its neighbors) and the communication channel that
channel that is used for RSVP communication. A value of is used for RSVP communication. A value of 0xffffffff indicates
0xffffffff indicates that the restart of the sender's control that the restart of the sender's control plane may occur over an
plane may occur over an indeterminate interval and that the indeterminate interval and that the operation of its data plane is
operation of its data plane is unaffected by control plane unaffected by control plane failures. The method used to ensure
failures. The method used to ensure continued data plane continued data plane operation is outside the scope of this
operation is outside the scope of this document. document.
Recovery Time: 32 bits Recovery Time: 32 bits
The period of time, in milliseconds, that the sender desires The period of time, in milliseconds, that the sender desires for
for the recipient to re-synchronize RSVP and MPLS forwarding the recipient to re-synchronize RSVP and MPLS forwarding state
state with the sender after the re-establishment of Hello with the sender after the re-establishment of Hello
synchronization. A value of zero (0) indicates that MPLS synchronization. A value of zero (0) indicates that MPLS
forwarding state was not preserved across a particular reboot. forwarding state was not preserved across a particular reboot.
9.2. Processing of Restart_Cap Object 9.2. Processing of Restart_Cap Object
Nodes supporting state recovery advertise this capability by carrying Nodes supporting state recovery advertise this capability by carrying
the Restart_Cap object in Hello messages. Such nodes MUST include the Restart_Cap object in Hello messages. Such nodes MUST include
the Restart_Cap object in all Hello messages. (Note that this the Restart_Cap object in all Hello messages. (Note that this
includes Hello messages containing ACK objects.) Usage of the includes Hello messages containing ACK objects.) Usage of the
special case Recovery Time values is described in greater detail special case Recovery Time values is described in greater detail
below. below.
skipping to change at page 27, line 45 skipping to change at page 27, line 6
process of being established when their refresh timers expire. process of being established when their refresh timers expire.
Refreshing of Resv and Path state SHOULD be suppressed during this Refreshing of Resv and Path state SHOULD be suppressed during this
waiting period. waiting period.
During this waiting period, the node MAY inform upstream nodes of the During this waiting period, the node MAY inform upstream nodes of the
communication loss via a PathErr and/or upstream Notify message with communication loss via a PathErr and/or upstream Notify message with
"Control Channel Degraded State" indication. If such notification "Control Channel Degraded State" indication. If such notification
has been sent, then upon restoration of the control channel the node has been sent, then upon restoration of the control channel the node
MUST inform other nodes of the restoration via a PathErr and/or MUST inform other nodes of the restoration via a PathErr and/or
upstream Notify message with "Control Channel Active State" upstream Notify message with "Control Channel Active State"
indication. (Specific error codes are to be assigned IANA.) indication. (Specific error codes have been assigned by IANA.)
When a new Hello message is received from the neighbor, the node must When a new Hello message is received from the neighbor, the node must
determine if the fault was limited to the control channel or was a determine if the fault was limited to the control channel or was a
nodal fault. This determination is based on the Src_Instance nodal fault. This determination is based on the Src_Instance
received from the neighbor. If the value is different than the value received from the neighbor. If the value is different than the value
that was received from the neighbor prior to the fault, then the that was received from the neighbor prior to the fault, then the
neighbor should be treated as if it has restarted. Otherwise, the neighbor should be treated as if it has restarted. Otherwise, the
the fault was limited control channel. Procedures for handling each the fault was limited control channel. Procedures for handling each
case are described below. case are described below.
skipping to change at page 28, line 26 skipping to change at page 27, line 35
9.5. Nodal Faults 9.5. Nodal Faults
Recovering from nodal faults uses one new object and other existing Recovering from nodal faults uses one new object and other existing
protocol messages and objects. protocol messages and objects.
9.5.1. Recovery Label 9.5.1. Recovery Label
The Recovery_Label object is used during the nodal fault recovery The Recovery_Label object is used during the nodal fault recovery
process. The format of a Recovery_Label object is identical to a process. The format of a Recovery_Label object is identical to a
generalized label. A Recovery_Label object uses Class-Number TBA (of generalized label. A Recovery_Label object uses Class-Number 34 (of
form 0bbbbbbb) and the C-Type of the label being suggested. form 0bbbbbbb) and the C-Type of the label being suggested.
9.5.2. Procedures for the Restarting node 9.5.2. Procedures for the Restarting node
After a node restarts its control plane, a node that supports state After a node restarts its control plane, a node that supports state
recovery SHOULD check whether it was able to preserve its MPLS recovery SHOULD check whether it was able to preserve its MPLS
forwarding state. If no forwarding state from prior to the restart forwarding state. If no forwarding state from prior to the restart
was preserved, then the node MUST set the Recovery Time to 0 in the was preserved, then the node MUST set the Recovery Time to 0 in the
Hello message the node sends to its neighbors. Hello message the node sends to its neighbors.
skipping to change at page 30, line 35 skipping to change at page 29, line 41
the Restart Time, the node determines (using the procedures defined the Restart Time, the node determines (using the procedures defined
in Section 5 of [RFC3209]) that the neighbor's control plane has in Section 5 of [RFC3209]) that the neighbor's control plane has
restarted, and the neighbor was able to preserve its forwarding state restarted, and the neighbor was able to preserve its forwarding state
across the restart (as was indicated by a non-zero Recovery Time across the restart (as was indicated by a non-zero Recovery Time
carried in the Restart_Cap object of the RSVP Hello messages received carried in the Restart_Cap object of the RSVP Hello messages received
from the neighbor). Note, a Restart Time value of 0xffffffff from the neighbor). Note, a Restart Time value of 0xffffffff
indicates an infinite Restart Time interval. indicates an infinite Restart Time interval.
Upon detecting a restart with a neighbor that supports state Upon detecting a restart with a neighbor that supports state
recovery, a node SHOULD refresh all Path state shared with that recovery, a node SHOULD refresh all Path state shared with that
neighbor. The outgoing Path messages MUST include the Recovery_Label neighbor. The outgoing Path messages MUST include a Recovery_Label
object containing the label value received in the most recently object containing a label value corresponding to the label value
received corresponding Resv message. All Path state SHOULD be received in the most recently received corresponding Resv message.
refreshed within approximately 1/2 of the Recovery time advertised by All Path state SHOULD be refreshed within approximately 1/2 of the
the restarted neighbor. If there are many LSP's going through the Recovery time advertised by the restarted neighbor. If there are
restarting node, the neighbor node should avoid sending Path messages many LSP's going through the restarting node, the neighbor node
in a short time interval, as to avoid unnecessary stressing the should avoid sending Path messages in a short time interval, as to
restarting node's CPU. Instead, it should spread the messages across avoid unnecessary stressing the restarting node's CPU. Instead, it
1/2 the Recovery Time interval. should spread the messages across 1/2 the Recovery Time interval.
After detecting a restart of a neighbor that supports state recovery, After detecting a restart of a neighbor that supports state recovery,
all Resv state shared with the restarting node MUST NOT be refreshed all Resv state shared with the restarting node MUST NOT be refreshed
until a corresponding Path message is received. This requires until a corresponding Path message is received. This requires
suppression of normal Resv and Summary Refresh processing to the suppression of normal Resv and Summary Refresh processing to the
neighbor during the Recovery Time advertised by the restarted neighbor during the Recovery Time advertised by the restarted
neighbor. As soon as a corresponding Path message is received a Resv neighbor. As soon as a corresponding Path message is received a Resv
message SHOULD be generated and normal state processing SHOULD be re- message SHOULD be generated and normal state processing SHOULD be
enabled. re-enabled.
10. RSVP Message Formats and Handling 10. RSVP Message Formats and Handling
This message summarizes RSVP message formats and handling as modified This message summarizes RSVP message formats and handling as modified
by GMPLS. by GMPLS.
10.1. RSVP Message Formats 10.1. RSVP Message Formats
This section presents the RSVP message related formats as modified by This section presents the RSVP message related formats as modified by
this document. Where they differ, formats for unidirectional LSPs this document. Where they differ, formats for unidirectional LSPs
are presented separately from bidirectional LSPs. Unmodified formats are presented separately from bidirectional LSPs. Unmodified formats
are not listed. Again, MESSAGE_ID and related objects are defined in are not listed. Again, MESSAGE_ID and related objects are defined in
[RFC2961]. [RFC2961].
The format of a Path message is as follows: The format of a Path message is as follows:
<Path Message> ::= <Common Header> [ <INTEGRITY> ] <Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ] [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ] [ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<TIME_VALUES> <TIME_VALUES>
[ <EXPLICIT_ROUTE> ] [ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST> <LABEL_REQUEST>
[ <PROTECTION> ] [ <PROTECTION> ]
[ <LABEL_SET> ... ] [ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ] [ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ] [ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ] [ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
<sender descriptor> <sender descriptor>
The format of the sender description for unidirectional LSPs is: The format of the sender description for unidirectional LSPs is:
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC> <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ] [ <ADSPEC> ]
[ <RECORD_ROUTE> ] [ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ] [ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ] [ <RECOVERY_LABEL> ]
The format of the sender description for bidirectional LSPs is: The format of the sender description for bidirectional LSPs is:
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC> <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ] [ <ADSPEC> ]
[ <RECORD_ROUTE> ] [ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ] [ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ] [ <RECOVERY_LABEL> ]
<UPSTREAM_LABEL> <UPSTREAM_LABEL>
The format of a PathErr message is as follows: The format of a PathErr message is as follows:
<PathErr Message> ::= <Common Header> [ <INTEGRITY> ] <PathErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ] [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ] [ <MESSAGE_ID> ]
<SESSION> <ERROR_SPEC> <SESSION> <ERROR_SPEC>
[ <ACCEPTABLE_LABEL_SET> ... ] [ <ACCEPTABLE_LABEL_SET> ... ]
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
<sender descriptor> <sender descriptor>
The format of a Resv message is as follows: The format of a Resv message is as follows:
<Resv Message> ::= <Common Header> [ <INTEGRITY> ] <Resv Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ] [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ] [ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<TIME_VALUES> <TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ] [ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <NOTIFY_REQUEST> ] [ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ] [ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list> <STYLE> <flow descriptor list>
<flow descriptor list> is not modified by this document. <flow descriptor list> is not modified by this document.
The format of a ResvErr message is as follows: The format of a ResvErr message is as follows:
<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ] <ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ] [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ] [ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<ERROR_SPEC> [ <SCOPE> ] <ERROR_SPEC> [ <SCOPE> ]
[ <ACCEPTABLE_LABEL_SET> ... ] [ <ACCEPTABLE_LABEL_SET> ... ]
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
<STYLE> <error flow descriptor> <STYLE> <error flow descriptor>
The modified Hello message format is: The modified Hello message format is:
<Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO> <Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO>
[ <RESTART_CAP> ] [ <RESTART_CAP> ]
10.2. Addressing Path and PathTear Messages 10.2. Addressing Path, PathTear and ResvConf Messages
RSVP was designed to handle dynamic (non-explicit) path changes and RSVP was designed to handle dynamic (non-explicit) path changes and
non RSVP hops along the path. To this end, the Path and PathTear non RSVP hops along the path. To this end, the Path, PathTear and
messages carry the destination address of the session in the IP ResvConf messages carry the destination address of the session in the
header. In generalized signaling, routes are usually explicitly IP header. In generalized signaling, routes are usually explicitly
signaled. Further, hops that cannot allocate labels cannot exist in signaled. Further, hops that cannot allocate labels cannot exist in
the path of an LSP. A further difference with traditional RSVP is the path of an LSP. A further difference with traditional RSVP is
that at times, an RSVP message may travel out of band with respect to that at times, an RSVP message may travel out of band with respect to
an LSP's data channel. an LSP's data channel.
When a node is sending a Path or PathTear message to a node that it When a node is sending a Path, PathTear or ResvConf message to a node
knows to be adjacent at the data plane (i.e. along the path of the that it knows to be adjacent at the data plane (i.e., along the path
LSP) it SHOULD address the message directly to an address associated of the LSP), it SHOULD address the message directly to an address
with the adjacent node's control plane. In this case the router- associated with the adjacent node's control plane. In this case the
alert option SHOULD not be included. router-alert option SHOULD not be included.
11. Acknowledgments 11. Acknowledgments
This draft is the work of numerous authors and consists of a This document is the work of numerous authors and consists of a
composition of a number of previous drafts in this area. A list of composition of a number of previous documents in this area.
the drafts from which material and ideas were incorporated follows:
draft-saha-rsvp-optical-signaling-00.txt
draft-lang-mpls-rsvp-oxc-00.txt
draft-kompella-mpls-optical-00.txt
draft-fan-mpls-lambda-signaling-00.txt
draft-pan-rsvp-te-restart-01.txt
Valuable comments and input were received from a number of people, Valuable comments and input were received from a number of people,
including Igor Bryskin, Adrian Farrel and Dimitrios Pendarakis. including Igor Bryskin, Adrian Farrel and Dimitrios Pendarakis.
Portions of Section 4 are based on suggestions and text proposed by Portions of Section 4 are based on suggestions and text proposed by
Adrian Farrel. Adrian Farrel.
The security considerations section is based on text provided by The security considerations section is based on text provided by
Steven Bellovin. Steven Bellovin.
12. Security Considerations 12. Security Considerations
RSVP message security is described in [RFC2747] and provides message RSVP message security is described in [RFC2747] and provides message
integrity and node authentication. For hop-by-hop messages, this integrity and node authentication. For hop-by-hop messages, this
draft introduces no other new security considerations. document introduces no other new security considerations.
This document introduces the ability to send a Notify message in a This document introduces the ability to send a Notify message in a
non-hop-by-hop fashion. This precludes RSVP's hop-by-hop integrity non-hop-by-hop fashion. This precludes RSVP's hop-by-hop integrity
and authentication model. In the case where RSVP is generating end- and authentication model. In the case where RSVP is generating end-
to-end messages and the same level of security provided by [RFC2747] to-end messages and the same level of security provided by [RFC2747]
is desired, the standard IPSEC based integrity and authentication can is desired, the standard IPSEC based integrity and authentication can
be used. Alternatively, the sending of no-hop-by-hop Notify messages be used. Alternatively, the sending of no-hop-by-hop Notify messages
can be disabled. can be disabled.
When using IPSEC to provide message authentication, the following When using IPSEC to provide message authentication, the following
skipping to change at page 35, line 18 skipping to change at page 34, line 20
13. IANA Considerations 13. IANA Considerations
IANA assigns values to RSVP protocol parameters. Within the current IANA assigns values to RSVP protocol parameters. Within the current
document multiple objects are defined. Each of these objects contain document multiple objects are defined. Each of these objects contain
C-Types. This section defines the rules for the assignment of the C-Types. This section defines the rules for the assignment of the
related C-Type values. This section uses the terminology of BCP 26 related C-Type values. This section uses the terminology of BCP 26
"Guidelines for Writing an IANA Considerations Section in RFCs" "Guidelines for Writing an IANA Considerations Section in RFCs"
[BCP26]. [BCP26].
As per [RFC2205], C-Type is an 8-bit number that identifies the As per [RFC2205], C-Type is an 8-bit number that identifies the
function of an object. There are no range restrictions. All function of an object. All possible values except zero are available
possible values except zero are available for assignment. for assignment.
The assignment of C-Type values of the objects defined in this The assignment of C-Type values of the objects defined in this
document fall into three categories. The first category inherit C- document fall into three categories. The first category inherit C-
Types from the Label object, i.e., object class number 16 [RFC3209]. Types from the Label object, i.e., object class number 16 [RFC3209].
IANA is requested to institute a policy whereby all C-Type values IANA is requested to institute a policy whereby all C-Type values
assign for the Label object are also assigned for the following assign for the Label object are also assigned for the following
objects: objects:
o Suggested_Label (Class-Num TBA)
o Upstream_Label (Class-Num TBA) o Suggested_Label (Class-Num 129)
o Recovery_Label (Class-Num TBA) o Upstream_Label (Class-Num 35)
o Recovery_Label (Class-Num 34)
The second category of objects follow independent policies. The second category of objects follow independent policies.
Specifically, following the policies outlined in [BCP26], C-Type Specifically, following the policies outlined in [BCP26], C-Type
values in the range 0x00 - 0x3F are allocated through an IETF values in the range 0x00 - 0x3F are allocated through an IETF
Consensus action, values in the range 00x40 - 0x5F are allocated as Consensus action, values in the range 00x40 - 0x5F are allocated as
First Come First Served, and values in the range 0x60 - 0x7F are First Come First Served, and values in the range 0x60 - 0x7F are
reserved for Private Use. This policy applies to the following reserved for Private Use. This policy applies to the following
objects. objects.
o Label_Set (Class-Num TBA)
o Notify_Request (Class-Num TBA) o Label_Set (Class-Num 36)
o Protection (Class-Num TBA) o Notify_Request (Class-Num 195)
o Admin Status (Class-Num TBA) o Protection (Class-Num 37)
o Restart_Cap (Class-Num TBA) o Admin Status (Class-Num 196)
o Restart_Cap (Class-Num 131)
The assignment of C-Type values for the remaining object, the The assignment of C-Type values for the remaining object, the
Acceptable_Label_Set object, follows the assignment of C-Type values Acceptable_Label_Set object, follows the assignment of C-Type values
of the Label_Set object. IANA is requested to institute a policy of the Label_Set object. IANA will institute a policy whereby all
whereby all C-Type values assigned for the Label_Set object are also C-Type values assigned for the Label_Set object are also assigned for
assigned for the Acceptable_Label_Set object. the Acceptable_Label_Set object.
13.1. IANA [Suggestions /] Assignments
[Note to RFC Editor:
Please drop all text enclosed in brackets in this section once
IANA assignments are made.
Editor's Note: 13.1. IANA Assignments
The values in this section were suggested to IANA for assignment
on March 11, 2002. No acknowledgment of the request has been
received. The values are included for reference purposes only
and should considered as unassigned.]
This section summarizes values used in this document that [will be / This section summarizes values used in this document that have been
] have been assigned by IANA. assigned by IANA.
--------------------------------------------------------------------- ---------------------------------------------------------------------
Message Types Message Types
o Notify message (suggested Message type =21) o Notify message (Message type = 21)
--------------------------------------------------------------------- ---------------------------------------------------------------------
Class Types Class Types
o RSVP_HOP (Existing C-Num 3) o RSVP_HOP (C-Num 3)
- IPv4 IF_ID RSVP_HOP (Suggested C-type =3) - IPv4 IF_ID RSVP_HOP (C-type = 3)
- IPv6 IF_ID RSVP_HOP (Suggested C-type =4) - IPv6 IF_ID RSVP_HOP (C-type = 4)
o ERROR_SPEC (Existing C-Num 6) o ERROR_SPEC (C-Num 6)
- IPv4 IF_ID ERROR_SPEC (Suggested C-type =3) - IPv4 IF_ID ERROR_SPEC (C-type = 3)
- IPv6 IF_ID ERROR_SPEC (Suggested C-type =4) - IPv6 IF_ID ERROR_SPEC (C-type = 4)
o LABEL_REQUEST (Existing Class-Num 19) o LABEL_REQUEST (Class-Num 19)
- Generalized_Label_Request (Suggested C-Type =4) - Generalized_Label_Request (C-Type = 4)
o RSVP_LABEL (Existing Class-Num 16) o RSVP_LABEL (Class-Num = 16)
- Generalized_Label (Suggested C-Type =2) - Generalized_Label (C-Type = 2)
- Waveband_Switching_Label C-Type (Suggested C-Type =3) - Waveband_Switching_Label C-Type (C-Type = 3)
--------------------------------------------------------------------- ---------------------------------------------------------------------
New Class-Nums, C-Types inherited from Label object (same as CNum16) New Class-Nums, C-Types inherited from Label object (same as CNum16)
o RECOVERY_LABEL Class-Num of form 0bbbbbbb (suggested =34) o RECOVERY_LABEL Class-Num of form 0bbbbbbb (= 34)
o SUGGESTED_LABEL Class-Num of form 10bbbbbb (suggested =129) o SUGGESTED_LABEL Class-Num of form 10bbbbbb (= 129)
o UPSTREAM_LABEL Class-Num of form 0bbbbbbb (suggested =35) o UPSTREAM_LABEL Class-Num of form 0bbbbbbb (= 35)
--------------------------------------------------------------------- ---------------------------------------------------------------------
New Class-Nums New Class-Nums
o LABEL_SET Class-Num of form 0bbbbbbb (suggested =36) o LABEL_SET Class-Num of form 0bbbbbbb (= 36)
- Type 1 (C-Type =1) - Type 1 (C-Type = 1)
o ACCEPTABLE_LABEL_SET Class-Num of form 10bbbbbb (suggested =130) o ACCEPTABLE_LABEL_SET Class-Num of form 10bbbbbb (= 130)
- Type 1 Acceptable_Label_Set (C-type from label_set cnum) - Type 1 Acceptable_Label_Set (C-type from label_set cnum)
o NOTIFY_REQUEST Class-Num of form 11bbbbbb (suggested =195) o NOTIFY_REQUEST Class-Num of form 11bbbbbb (= 195)
- IPv4 Notify Request (C-Type =1) - IPv4 Notify Request (C-Type = 1)
- IPv6 Notify Request (C-Type =2) - IPv6 Notify Request (C-Type = 2)
o PROTECTION Class-Num of form 0bbbbbbb (suggested =37) o PROTECTION Class-Num of form 0bbbbbbb (= 37)
- Type 1 (C-Type =1) - Type 1 (C-Type = 1)
o ADMIN STATUS Class-Num of form 11bbbbbb (suggested =196)
- Type 1 (C-Type =1)
o RESTART_CAP Class-Num of form 10bbbbbb (suggested =131)
- Type 1 (C-Type =1)
o ADMIN STATUS Class-Num of form 11bbbbbb (= 196)
- Type 1 (C-Type = 1)
o RESTART_CAP Class-Num of form 10bbbbbb (= 131)
- Type 1 (C-Type = 1)
--------------------------------------------------------------------- ---------------------------------------------------------------------
ERO/RRO subobject types ERO/RRO subobject types
o Label ERO subobject o Label ERO subobject
Type 3 - Label Type 3 - Label
o Label RRO subobject o Label RRO subobject
Type 3 - Label Type 3 - Label
--------------------------------------------------------------------- ---------------------------------------------------------------------
Error codes Error codes
o "Routing problem/Label Set" (Suggested value =11) o "Routing problem/Label Set" (value = 11)
o "Routing problem/Switching Type" (Suggested value =12) o "Routing problem/Switching Type" (value = 12)
(duplicate code 13 dropped) (duplicate code 13 dropped)
o "Routing problem/Unsupported Encoding" (Suggested value =14) o "Routing problem/Unsupported Encoding" (value = 14)
o "Routing problem/Unsupported Link Protection" (Suggested value =15) o "Routing problem/Unsupported Link Protection" (value = 15)
o "Notify Error/Control Channel Active State" (Suggested value =4) o "Notify Error/Control Channel Active State" (value = 4)
o "Notify Error/Control Channel Degraded State" (Suggested value =5) o "Notify Error/Control Channel Degraded State" (value = 5)
--------------------------------------------------------------------- ---------------------------------------------------------------------
14. Intellectual Property Considerations 14. Intellectual Property Considerations
This section is taken from Section 10.4 of [RFC2026]. This section is taken from Section 10.4 of [RFC2026].
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 or other rights that might be claimed to intellectual property 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
skipping to change at page 38, line 23 skipping to change at page 37, line 9
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 which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
15. References 15. References
15.1. Normative References 15.1. Normative References
[GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Signaling Functional Description", Internet Draft, Requirement Levels", BCP 14, RFC 2119, March 1997.
draft-ietf-mpls-generalized-signaling-09.txt,
August 2002.
[MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S.
in RSVP-TE", Internet Draft, and S. Jamin, "Resource ReserVation Protocol --
draft-ietf-mpls-rsvp-unnum-07.txt, July 2002. Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol [RFC2210] Wroclawski, J., "The Use of RSVP with IETF
-- Version 1 Functional Specification", RFC 2205, Integrated Services", RFC 2210, September 1997.
September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated [RFC2402] Kent, S. and R. Atkinson, "IP Authentication
Services," RFC 2210, September 1997. Header", RFC 2401, November 1998.
[RFC2402] "IP Authentication Header", S. Kent and R. Atkinson, [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
RFC 2401, November 1998. Payload (ESP)", RFC 2401, November 1998.
[RFC2406] "IP Encapsulating Security Payload (ESP)", S. Kent and R. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key
Atkinson, RFC 2401, November 1998. Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] "The Internet Key Exchange (IKE)", D. Harkins and D. [RFC2747] Baker, F., Lindell, B. and M. Talwar, "RSVP
Carrel. RFC 2409, November 1998. Cryptographic Authentication", RFC 2747, January
2000.
[RFC2747] Baker, et al, "RSVP Cryptographic Authentication", RFC [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi,
2747, January 2000. F. and S. Molendini, "RSVP Refresh Overhead
Reduction Extensions", RFC 2961, April 2001.
[RFC2961] Berger, L. et al, "RSVP Refresh Overhead Reduction [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
Extensions", RFC 2961, April 2001 Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions
to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche, et al, "RSVP-TE: Extensions to RSVP for [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol
LSP Tunnels", RFC 3209, December 2001. Label Switching (GMPLS) Signaling Functional
Description", RFC 3471, January 2003.
15.2. Informative References [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered
Links in Resource Reservation Protocol - Traffic
Engineering (RSVP-TE)", RFC 3477, January 2003.
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 15.2. Informative References
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[MPLS-HIERARCHY] Kompella, K., and Rekhter, Y., "LSP Hierarchy with [BCP26] Narten, T. and H. Alvestrand, "Guidelines for
MPLS TE", Internet Draft, Writing an IANA Considerations Section in RFCs", BCP
draft-ietf-mpls-lsp-hierarchy-02.txt, Feb., 2001. 26, RFC 2434, October 1998.
[PAN-RESTART] Pan, P, et al, "Graceful Restart Mechanism for RSVP-TE", [MPLS-HIERARCHY] Kompella, K. and Y. Rekhter, "LSP Hierarchy with
Internet Draft, draft-pan-rsvp-te-restart-01.txt, MPLS TE", Work in Progress.
July 2001.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3," [PAN-RESTART] Pan, P., et. al., "Graceful Restart Mechanism for
RFC 2026. RSVP-TE", Work in Progress.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2026] Bradner, S., "The Internet Standards Process --
Requirement Levels," RFC 2119. Revision 3", BCP 9, RFC 2026, October 1996.
16. Contributors 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
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
Email: lberger@movaz.com
Phone: +1 703 847-1801
EMail: lberger@movaz.com
Greg Bernstein Greg Bernstein
Ciena Corporation EMail: gregb@grotto-networking.com
10480 Ridgeview Court
Cupertino, CA 94014
Phone: +1 408 366 4713
Email: greg@ciena.com
John Drake John Drake
Calient Networks Calient Networks
5853 Rue Ferrari 5853 Rue Ferrari
San Jose, CA 95138 San Jose, CA 95138
Phone: +1 408 972 3720 Phone: +1 408 972 3720
Email: jdrake@calient.net EMail: jdrake@calient.net
Yanhe Fan Yanhe Fan
Axiowave Networks, Inc. Axiowave Networks, Inc.
200 Nickerson Road 200 Nickerson Road
Marlborough, MA 01752 Marlborough, MA 01752
Phone: + 1 774 348 4627 Phone: + 1 774 348 4627
Email: yfan@axiowave.com EMail: yfan@axiowave.com
Kireeti Kompella Kireeti Kompella
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: kireeti@juniper.net
EMail: kireeti@juniper.net
Jonathan P. Lang Jonathan P. Lang
Calient Networks EMail: jplang@ieee.org
25 Castilian
Goleta, CA 93117
Email: jplang@calient.net
Fong Liaw Fong Liaw
Solas Research, LLC Solas Research, LLC
Email: fongliaw@yahoo.com
EMail: fongliaw@yahoo.com
Eric Mannie Eric Mannie
KPNQwest Independent Consultant
Terhulpsesteenweg 6A 2 Avenue de la Folle Chanson
1560 Hoeilaart - Belgium 1050 Brussels
Phone: +32 2 658 56 52 Belgium
Mobile: +32 496 58 56 52
Fax: +32 2 658 51 18 EMail: eric_mannie@hotmail.com
Email: eric.mannie@kpnqwest.com
Ping Pan Ping Pan
Ciena Ciena
10480 Ridgeview Court 10480 Ridgeview Court
Cupertino, CA 95014 Cupertino, CA 95014
Phone: 408-366-4700 Phone: 408-366-4700
Email: ppan@ciena.com 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
Yakov Rekhter Yakov Rekhter
Juniper Networks, Inc. Juniper Networks, Inc.
Email: yakov@juniper.net
Debanjan Saha EMail: yakov@juniper.net
Tellium Optical Systems
2 Crescent Place
Oceanport, NJ 07757-0901
Phone: +1 732 923 4264
Fax: +1 732 923 9804
Email: dsaha@tellium.com
Debanjan Saha
EMail: debanjan@acm.org
Vishal Sharma Vishal Sharma
Metanoia, Inc. Metanoia, Inc.
335 Elan Village Lane, Unit 203 1600 Villa Street, Unit 352
San Jose, CA 95134-2539 Mountain View, CA 94041-1174
Phone: +1 408-943-1794
Email: v.sharma@ieee.org Phone: +1 650-386-6723
EMail: v.sharma@ieee.org
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
250 Apollo Drive 250 Apollo Drive
Chelmsford, MA 01824 Chelmsford, MA 01824
Voice: +1 978 244 8143
Email: swallow@cisco.com Phone: +1 978 244 8143
EMail: swallow@cisco.com
Z. Bo Tang Z. Bo Tang
Tellium, Inc. EMail: botang01@yahoo.com
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Phone: +1 732 923 4231
Fax: +1 732 923 9804
Email: btang@tellium.com
17. Contact Address 17. Editor's Address
Lou Berger Lou Berger
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
Generated on: Fri Oct 4 15:47:43 2002 18. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 169 change blocks. 
606 lines changed or deleted 591 lines changed or added

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