draft-ietf-mpls-generalized-rsvp-te-04.txt   draft-ietf-mpls-generalized-rsvp-te-05.txt 
Network Working Group Peter Ashwood-Smith (Nortel Networks Corp.) Network Working Group Peter Ashwood-Smith (Nortel Networks Corp.)
Internet Draft Ayan Banerjee (Calient Networks) Internet Draft Ayan Banerjee (Calient Networks)
Expiration Date: January 2002 Lou Berger (Movaz Networks) Expiration Date: April 2002 Lou Berger (Movaz Networks)
Greg Bernstein (Ciena Corporation) Greg Bernstein (Ciena Corporation)
John Drake (Calient Networks) John Drake (Calient Networks)
Yanhe Fan (Axiowave Networks) Yanhe Fan (Axiowave Networks)
Kireeti Kompella (Juniper Networks, Inc.) Kireeti Kompella (Juniper Networks, Inc.)
Jonathan P. Lang (Calient Networks) Jonathan P. Lang (Calient Networks)
Fong Liaw (Zaffire Inc.) Fong Liaw (Zaffire Inc.)
Eric Mannie (EBONE) Eric Mannie (EBONE)
Ping Pan (Juniper Networks, Inc.) Ping Pan (Juniper Networks, Inc.)
Bala Rajagopalan (Tellium, Inc.) Bala Rajagopalan (Tellium, Inc.)
Yakov Rekhter (Juniper Networks, Inc.) Yakov Rekhter (Juniper Networks, Inc.)
Debanjan Saha (Tellium, Inc.) Debanjan Saha (Tellium, Inc.)
Vishal Sharma (Jasmine Networks) Vishal Sharma (Metanoia, Inc.)
George Swallow (Cisco Systems) George Swallow (Cisco Systems)
Z. Bo Tang (Tellium, Inc.) Z. Bo Tang (Tellium, Inc.)
July 2001 October 2001
Generalized MPLS Signaling - RSVP-TE Extensions Generalized MPLS Signaling - RSVP-TE Extensions
draft-ietf-mpls-generalized-rsvp-te-04.txt draft-ietf-mpls-generalized-rsvp-te-05.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 2, line 7 skipping to change at page 2, line 7
support Generalized MPLS. Generalized MPLS extends MPLS to encompass support Generalized MPLS. Generalized MPLS extends MPLS to encompass
time-division (e.g. SONET ADMs), wavelength (optical lambdas) and time-division (e.g. SONET ADMs), wavelength (optical lambdas) and
spatial switching (e.g. incoming port or fiber to outgoing port or spatial switching (e.g. incoming port or fiber to outgoing port or
fiber). This document presents an RSVP-TE specific description of fiber). This document presents an RSVP-TE specific description of
the extensions. A CR-LDP specific description can be found in the extensions. A CR-LDP specific description can be found in
[GMPLS-LDP]. A generic functional description is presented in [GMPLS-LDP]. A generic functional description is presented in
[GMPLS-SIG]. [GMPLS-SIG].
Contents Contents
1 Introduction ................................................ 3 1 Introduction ................................................ 4
2 Label Related Formats ...................................... 3 2 Label Related Formats ...................................... 5
2.1 Generalized Label Request Object ............................ 4 2.1 Generalized Label Request Object ............................ 5
2.2 Generalized Label Object .................................... 5 2.2 Generalized Label Object .................................... 6
2.3 Waveband Switching .......................................... 6 2.3 Waveband Switching .......................................... 7
2.4 Suggested Label ............................................. 7 2.4 Suggested Label ............................................. 8
2.5 Label Set ................................................... 7 2.5 Label Set ................................................... 8
3 Bidirectional LSPs .......................................... 9 3 Bidirectional LSPs .......................................... 10
3.1 Procedures .................................................. 9 3.1 Procedures .................................................. 10
3.2 Contention Resolution ....................................... 9 3.2 Contention Resolution ....................................... 11
4 Notification ................................................ 10 4 Notification ................................................ 11
4.1 Acceptable Label Set Object ................................. 10 4.1 Acceptable Label Set Object ................................. 12
4.2 Notify Request Objects ...................................... 11 4.2 Notify Request Objects ...................................... 12
4.3 Notify Message .............................................. 12 4.3 Notify Message .............................................. 14
4.4 Removing State with a PathErr message ....................... 14 4.4 Removing State with a PathErr message ....................... 15
5 Explicit Label Control ...................................... 15 5 Explicit Label Control ...................................... 16
5.1 Procedures .................................................. 16 5.1 Label ERO subobject ......................................... 17
6 Protection Object ........................................... 17 5.2 Label RRO subobject ......................................... 18
6.1 Procedures .................................................. 17 6 Protection Object ........................................... 19
7 Administrative Status Information ........................... 17 6.1 Procedures .................................................. 20
7.1 Admin Status Object ......................................... 17 7 Administrative Status Information ........................... 20
7.2 Path and Resv Message Procedures ............................ 18 7.1 Admin Status Object ......................................... 20
7.3 Notify Message Procedures ................................... 19 7.2 Path and Resv Message Procedures ............................ 20
8 Control Channel Separation .................................. 20 7.3 Notify Message Procedures ................................... 22
8.1 Interface Identification .................................... 20 8 Control Channel Separation .................................. 23
9 Fault Handling .............................................. 22 8.1 Interface Identification .................................... 23
9.1 RESTART_CAP Object .......................................... 22 8.2 Errored Interface Identification ............................ 25
9.2 Processing of RESTART_CAP Object ............................ 23 9 Fault Handling .............................................. 27
9.3 Modification to Hello Processing to Support State Recovery .. 23 9.1 Restart_Cap Object .......................................... 27
9.4 Control Channel Faults ...................................... 24 9.2 Processing of Restart_Cap Object ............................ 28
9.5 Nodal Faults ................................................ 24 9.3 Modification to Hello Processing to Support State Recovery .. 28
10 RSVP Message Formats and Handling ........................... 27 9.4 Control Channel Faults ...................................... 29
10.1 RSVP Message Formats ........................................ 27 9.5 Nodal Faults ................................................ 29
10.2 Addressing Path and PathTear Messages ...................... 29 10 RSVP Message Formats and Handling ........................... 32
11 Acknowledgments ............................................. 29 10.1 RSVP Message Formats ........................................ 32
12 Security Considerations ..................................... 29
13 References .................................................. 30 10.2 Addressing Path and PathTear Messages ...................... 34
14 Authors' Addresses .......................................... 31 11 Acknowledgments ............................................. 35
12 Security Considerations ..................................... 35
13 IANA Considerations ......................................... 35
14 References .................................................. 36
15 Authors' Addresses .......................................... 37
[Editor's note: changes to be removed prior to publication as an RFC.]
Changes from previous version: Changes from previous version:
o Fixed Label Set format (for LDP) o Revised Admin Status Usage
o Added Switching type of LSP being requested (per comments and also removed potential race condition)
o Added Administrative Status Information (based on last call comments) o Clarified text related to interface bundling
o Added section on Control Channel Separation (To be consistent with updated bundling draft.)
(based on last call comments) o Added IF_ID ERROR_SPEC Object
Covers: (Per comments, supports Control Channel Separation by allowing
- Separation of control and data channels identification of errored interface.)
- Restoration of state post control channel failures o Added U bit to Label RRO subobject
(Per comment, to match defined ERO.)
o Clarified usage of Restart_Cap
o Replaced use of Suggested_Label during recovery with new Recovery_Label
(Per last WG session)
o Added IANA Considerations
o Minor editorial changes and clarifications
1. Introduction 1. Introduction
Generalized MPLS extends MPLS from supporting packet (PSC) interfaces Generalized MPLS extends MPLS from supporting packet (PSC) interfaces
and switching to include support of three new classes of interfaces and switching to include support of three new classes of interfaces
and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and
Fiber-Switch (FSC). A functional description of the extensions to Fiber-Switch (FSC). A functional description of the extensions to
MPLS signaling needed to support the new classes of interfaces and MPLS signaling needed to support the new classes of interfaces and
switching is provided in [GMPLS-SIG]. This document presents RSVP-TE switching is provided in [GMPLS-SIG]. This document presents RSVP-TE
specific formats and mechanisms needed to support all four classes of specific formats and mechanisms needed to support all four classes of
skipping to change at page 6, line 13 skipping to change at page 7, line 22
by the recipient. by the recipient.
The recipient of a Resv message containing a Generalized Label The recipient of a Resv message containing a Generalized Label
verifies that the values passed are acceptable. If the label is verifies that the values passed are acceptable. If the label is
unacceptable then the recipient MUST generate a ResvErr message with unacceptable then the recipient MUST generate a ResvErr message with
a "Routing problem/MPLS label allocation failure" indication. a "Routing problem/MPLS label allocation failure" indication.
2.3. Waveband Switching 2.3. Waveband Switching
Waveband switching uses the same format as the generalized label, see Waveband switching uses the same format as the generalized label, see
section 2.2. For compatibility reasons, a new RSVP c-type (3) is section 2.2. For compatibility reasons, a new RSVP C-Type (3) is
assigned for the Waveband Label. assigned for the Waveband Label.
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 7 skipping to change at page 8, line 17
before forwarding the label object with the new waveband Id. In this before forwarding the label object with the new waveband Id. In this
manner an egress/ingress LSR which receives a waveband label which manner an egress/ingress LSR which receives a waveband label which
has these values inverted, knows that it must also invert its egress has these values inverted, knows that it must also invert its egress
association to pick up the proper wavelengths. association to pick up the proper wavelengths.
This operation MUST be performed in both directions when a This operation MUST be performed in both directions when a
bidirectional waveband tunnel is being established. bidirectional waveband tunnel is being established.
2.4. Suggested Label 2.4. Suggested Label
The format of a suggested label is identical to a generalized label. The format of a Suggested_Label object is identical to a generalized
It is used in Path messages. Suggested Label uses Class-Number TBA label. It is used in Path messages. A Suggested_Label object uses
(of form 10bbbbbb) and the C-type of the label being suggested. Class-Number TBA (of form 10bbbbbb) and the C-Type of the label being
suggested.
Errors in received Suggested Labels MUST be ignored. This includes Errors in received Suggested_Label objects MUST be ignored. This
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
differs from the suggested label upstream, the upstream LSR MUST
either reconfigure itself so that it uses the label specified by the
downstream node or generate a ResvErr message with a "Routing
problem/Unacceptable label value" indication. Furthermore, an
ingress node SHOULD NOT transmit data traffic using a suggested label
until the downstream node passes a corresponding label upstream.
2.5. Label Set 2.5. Label Set
The Label_Set object uses Class-Number TBA (of form 0bbbbbbb) and the The Label_Set object uses Class-Number TBA (of form 0bbbbbbb) and the
C-type of 1. C-Type of 1. It is used in Path messages.
The format of a Label_Set is: The format of a Label_Set is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(TBA)| C-Type (1) | | Length | Class-Num(TBA)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved | Label Type | | Action | Reserved | Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 8 skipping to change at page 10, line 34
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 has the same format as Label in the Path message. An Upstream_Label object has the same
the generalized label, see Section 2.2. The Upstream Label uses format as the generalized label, see Section 2.2. The Upstream_Label
Class-Number TBA (of form 0bbbbbbb) and the C-type of the label being object uses Class-Number TBA (of form 0bbbbbbb) and the C-Type of the
suggested. 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 is added to the Path support bidirectional LSPs an Upstream_Label object is added to the
message. The Upstream Label MUST indicate a label that is valid for Path message. The Upstream_Label object MUST indicate a label that
forwarding at the time the Path message is sent. is valid for forwarding at the time the Path message is sent.
When a Path message containing an Upstream Label is received, the When a Path message containing an Upstream_Label object is received,
receiver first verifies that the upstream label is acceptable. If the receiver first verifies that the upstream label is acceptable.
the label is not acceptable, the receiver MUST issue a PathErr If the label is not acceptable, the receiver MUST issue a PathErr
message with a "Routing problem/Unacceptable label value" indication. message with a "Routing problem/Unacceptable label value" indication.
The generated PathErr message MAY include an Acceptable Label Set, The generated PathErr message MAY include an Acceptable Label Set,
see Section 4.1. see Section 4.1.
An intermediate node must also allocate a label on the outgoing An intermediate node must also allocate a label on the outgoing
interface and establish internal data paths before filling in an interface and establish internal data paths before filling in an
outgoing Upstream Label and propagating the Path message. If an outgoing upstream label and propagating the Path message. If an
intermediate node is unable to allocate a label or internal intermediate node is unable to allocate a label or internal
resources, then it MUST issue a PathErr message with a "Routing resources, then it MUST issue a PathErr message with a "Routing
problem/Label allocation failure" indication. problem/Label allocation failure" indication.
Terminator nodes process Path messages as usual, with the exception Terminator nodes process Path messages as usual, with the exception
that the upstream label can immediately be used to transport data that the upstream label can immediately be used to transport data
traffic associated with the LSP upstream towards the initiator. traffic associated with the LSP upstream towards the initiator.
When a bidirectional LSP is removed, both upstream and downstream When a bidirectional LSP is removed, both upstream and downstream
labels are invalidated and it is no longer valid to send data using labels are invalidated and it is no longer valid to send data using
skipping to change at page 10, line 22 skipping to change at page 12, line 8
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 TBA (of form
10bbbbbb). The remaining contents of the object, including C-type, 10bbbbbb). The remaining contents of the object, including C-Type,
have the identical format as the Label_Set object, see Section 2.5. have the identical format as the Label_Set object, see Section 2.5.
Acceptable_Label_Set objects may be carried in PathErr and ResvErr Acceptable_Label_Set objects may be carried in PathErr and ResvErr
messages. The procedures for defining an Acceptable Label Set follow messages. The procedures for defining an Acceptable Label Set follow
the procedures for defining a Label Set, see Section 2.5.1. the procedures for defining a Label Set, see Section 2.5.1.
Specifically, an Acceptable Label Set is defined via one or more Specifically, an Acceptable Label Set is defined via one or more
Acceptable_Label_Set objects. Specific labels/subchannels can be Acceptable_Label_Set objects. Specific labels/subchannels can be
added to or excluded from an Acceptable Label Set via Action zero added to or excluded from an Acceptable Label Set via Action zero
(0) and one (1) objects respectively. Ranges of labels/subchannels (0) and one (1) objects respectively. Ranges of labels/subchannels
can be added to or excluded from an Acceptable Label Set via Action can be added to or excluded from an Acceptable Label Set via Action
skipping to change at page 11, line 15 skipping to change at page 12, line 38
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 TBA (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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(TBA)| C-Type (1) | | Length | Class-Num(TBA)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Notify Node Address | | IPv4 Notify Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 49 skipping to change at page 13, line 26
| IPv6 Notify Node Address | | IPv6 Notify Node Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Notify Node Address: 16 bytes IPv6 Notify Node Address: 16 bytes
The IP address of the node that should be notified when The IP address of the node that should be notified when
generating an error message. 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 is
indicated via the inclusion of a Notify Request Object in the 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
skipping to change at page 12, line 28 skipping to change at page 14, line 8
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.
Note that the inclusion of a Notify Request object does not guarantee Note that the inclusion of a Notify Request object does not guarantee
that a Notify message will be generated. that a Notify message will be generated.
4.3. Notify Message 4.3. Notify Message
The Notify message provides a mechanism to inform non-adjacent nodes The Notify message provides a mechanism to inform non-adjacent nodes
of LSP related events. Notify messages are only generated after a of LSP related events. Notify messages are normally generated only
Notify Request object has been received. The Notify message differs after a Notify Request object has been received. The Notify message
from the currently defined error messages (i.e., PathErr and ResvErr differs from the currently defined error messages (i.e., PathErr and
messages) in that it can be "targeted" to a node other than the ResvErr messages) in that it can be "targeted" to a node other than
immediate upstream or downstream neighbor and that it is a the immediate upstream or downstream neighbor and that it is a
generalized notification mechanism. The Notify message does not generalized notification mechanism. The Notify message does not
replace existing error messages. The Notify message may be sent replace existing error messages. The Notify message may be sent
either (a) normally, where non-target nodes just forward the Notify either (a) normally, where non-target nodes just forward the Notify
message to the target node, similar to ResvConf processing in [RSVP]; message to the target node, similar to ResvConf processing in [RSVP];
or (b) encapsulated in a new IP header whose destination is equal to or (b) encapsulated in a new IP header whose destination is equal to
the target IP address. Regardless of the transmission mechanism, the target IP address. Regardless of the transmission mechanism,
nodes receiving a Notify message not destined to the node forward the nodes receiving a Notify message not destined to the node forward the
message, unmodified, towards the target. message, unmodified, towards the target.
To support reliable delivery of the Notify message, an Ack Message To support reliable delivery of the Notify message, an Ack Message
skipping to change at page 13, line 14 skipping to change at page 14, line 35
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 Msg Type of TBA (by IANA). The Notify The Notify message has a Message Type of TBA (by IANA). The Notify
message format is as follows: message 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>
skipping to change at page 13, line 41 skipping to change at page 15, line 14
<flow descriptor list descriptor> <flow descriptor list descriptor>
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 [RSVP-RR] and are used when refresh related objects are defined in [RSVP-RR] and are used when refresh
reductions is supported. reductions is supported.
4.3.2. Procedures 4.3.2. Procedures
Notify messages are generated at nodes that detect an error that will Notify messages are most commonly generated at nodes that detect an
trigger the generation of a PathErr or ResvErr message. If a PathErr error that will trigger the generation of a PathErr or ResvErr
message is to be generated and a Notify Request object has been message. If a PathErr message is to be generated and a Notify
received in the corresponding Path message, then a Notify message Request object has been received in the corresponding Path message,
destined to the recorded node SHOULD be generated. If a ResvErr then a Notify message destined to the recorded node SHOULD be
message is to be generated and a Notify Request object has been generated. If a ResvErr message is to be generated and a Notify
received in the corresponding Resv message, then a Notify message Request object has been received in the corresponding Resv message,
destined to the recorded node SHOULD be generated. As previously then a Notify message destined to the recorded node SHOULD be
mentioned, a single error may generate a Notify message in both the generated. As previously mentioned, a single error may generate a
upstream and downstream directions. Note that a Notify message MUST Notify message in both the upstream and downstream directions. Note
NOT be generated unless an appropriate Notify Request object has been that a Notify message MUST NOT be generated unless an appropriate
received. Notify Request object has been received.
When generating Notify messages, a node SHOULD attempt to combine When generating Notify messages, a node SHOULD attempt to combine
notifications being sent to the same Notify Node and that share the notifications being sent to the same Notify Node and that share the
same ERROR_SPEC into a single Notify message. The means by which a same ERROR_SPEC into a single Notify message. The means by which a
node determines which information may be combined is implementation node determines which information may be combined is implementation
dependent. Implementations may use event, timer based or other dependent. Implementations may use event, timer based or other
approaches. If using a timer based approach, the implementation approaches. If using a timer based approach, the implementation
SHOULD allow the user to configure the interval over which SHOULD allow the user to configure the interval over which
notifications are combined. When using a timer based approach, a notifications are combined. When using a timer based approach, a
default "notification interval" of 1 ms SHOULD be used. Notify default "notification interval" of 1 ms SHOULD be used. Notify
skipping to change at page 15, line 21 skipping to change at page 16, line 44
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
Label Control. Note that the Label RRO subobject was defined in
[RSVP-TE] and is being revised to support bidirectional LSPs.
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 |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 5 skipping to change at page 17, line 35
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. Procedures 5.1.1. Procedures
The Label subobject follows a subobject containing the IP address, or The Label subobject follows a subobject containing the IP address, or
the interface identifier [MPLS-UNNUM], associated with the link on the interface identifier [MPLS-UNNUM], associated with the link on
which it is to be used. The preceding subobject must be a strict which it is to be used. The preceding subobject must be a strict
object. Up to two label subobjects may be present, one for the object. Up to two label subobjects may be present, one for the
downstream label and one for the upstream label. The following downstream label and one for the upstream label. The 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 - If the first label subobject is not preceded by a subobject
containing an IP address, or a interface identifier containing an IP address, or a interface identifier
[MPLS-UNNUM], associated with an output link. [MPLS-UNNUM], associated with an output link.
skipping to change at page 16, line 34 skipping to change at page 18, line 16
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
of the label is label to be used for upstream traffic associated with of the label is label to be used for upstream traffic associated with
the bidirectional LSP. If this label is not acceptable, a "Bad the bidirectional LSP. If this label is not acceptable, a "Bad
EXPLICIT_ROUTE object" error SHOULD be generated. If the label is EXPLICIT_ROUTE object" error SHOULD be generated. If the label is
acceptable, the label is copied into a new Upstream Label object. acceptable, the label is copied into a new Upstream_Label object.
This Upstream Label object MUST be included on the corresponding This Upstream_Label object MUST be included on the corresponding
outgoing Path message. outgoing Path message.
After processing, the label subobjects are removed from the ERO. After processing, the label subobjects are removed from the ERO.
Note an implication of the above procedures is that the label Note an implication of the above procedures is that the label
subobject should never be the first subobject in a newly received subobject should never be the first subobject in a newly received
message. If the label subobject is the the first subobject an a message. If the label subobject is the the first subobject an a
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
The Label RRO subobject is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |U| Flags | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of U and Label parameters.
Type
3 Label
Length
See [RSVP-TE].
Flags
See [RSVP-TE].
C-Type
The C-Type of the included Label Object. Copied from the Label
Object.
5.2.1. Procedures
Label RRO subobjects are included in RROs as described in [RSVP-TE].
The only modification to usage and processing from [RSVP-TE] is that
when labels are recorded for bidirectional LSPs, label ERO subobjects
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 TBA (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
skipping to change at page 17, line 33 skipping to change at page 20, line 15
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
Administrative Status Information is carried in the Admin Status Administrative Status Information is carried in the Admin_Status
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). TBA (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(TBA)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |T|D| |R| Reserved |T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of parameters. See [GMPLS-SIG] 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 is inserted in Path messages at the outgoing messages. The object may be inserted in either Path or Resv
discretion of the ingress node. messages at the discretion of the ingress (for Path messages) or
egress (for Resv messages) nodes. The absence of the object is
Transit nodes receiving a non-refresh Path message containing an equivalent to receiving an object containing values all set to zero
Admin Status Object, update their local state, take any appropriate (0).
local action based on the indicated status and then propagate the
received Admin Status Object in the outgoing Path message.
Egress nodes receiving a non-refresh Path message containing an Admin Transit nodes receiving a non-refresh Path or Resv message containing
Status Object, also update their local state and take any appropriate an Admin_Status object, update their local state, take any
local action based on the indicated status. If an egress node has appropriate local action based on the indicated status and then
issued a Resv message corresponding to the Path message it MUST send propagate the received Admin_Status object in the corresponding
an updated Resv message containing an Admin Status Object with the outgoing Path or Resv message. If the values of an Admin_Status
same values set as received in the corresponding Path message. The object received in a Resv message differs from the values received in
egress node MUST also ensure that all subsequent Resv messages sent a Path message then, with one exception, no local action should be
by the node contain the same Admin Status Objects matching the taken but the values should still be propagated. The one case where
corresponding Path message. values received in the Resv message should result in local action is
when both the received R and D bits are set, i.e., are one (1).
Transit nodes receiving a non-refresh Resv message containing an Edge nodes receiving a non-refresh Path or Resv message containing an
Admin Status Object, update their local state, take any appropriate Admin_Status object, also update their local state and take any
local action based on the indicated status and then propagate the appropriate local action based on the indicated status. When an
received Admin Status Object in the outgoing Resv message. Admin Status object is received with the R bit set, the receiving
edge node should reflect the received values in a corresponding
outgoing message. Specifically, if an egress node receives a Path
message with the R bit of the Admin_Status object set and the node
has previously issued a Resv message corresponding to the Path
message, the node SHOULD send an updated Resv message containing an
Admin_Status object with the same values set, with the exception of
the R bit, as received in the corresponding Path message.
Furthermore, the egress node SHOULD also ensure that subsequent Resv
messages sent by the node contain the same Admin Status Object.
Additionally, if an ingress node receives a Resv message with the R
bit of the Admin_Status object set, the node SHOULD send an updated
Path message containing an Admin_Status object with the same values
set, with the exception of the R bit, as received in the
corresponding Resv message. Furthermore, the ingress node SHOULD
also ensure that subsequent Path messages sent by the node contain
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: 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 Path message and setting the Down (D) bit. Status Object in a Path message and setting the Reflect (R) and
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. described above. (Alternatively, the egress MAY respond with
a PathErr message with the Path_State_Removed flag set, see
section 4.4.)
3. Upon receiving the Admin Status Object with the Delete (D) bit set
in the Resv message, the ingress node sends a PathTear message
downstream to remove the LSP and normal RSVP processing takes place.
3. Upon receiving the Admin Status Object with the Down (D) bit set in In such circumstances the procedure SHOULD be followed when deleting
the Resv message, the ingress node sends a PathTear message an LSP from the egress:
1. The egress node indicates its desire for deletion by inserting
an Admin Status Object in a Resv message and setting the Reflect (R)
and Delete (D) bits.
2. Transit nodes process the Admin Status Object as described above.
3. Upon receiving the Admin Status Object with the Delete (D) bit set
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 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. In this case, the ingress SHOULD continue to set the Message. To support the case of a non-supporting egress node, the
contents of the object normally but, when processing an LSP deletion, ingress SHOULD only wait a configurable period of time for the
it MUST NOT wait for an updated Admin Status Object in a Resv message updated Admin Status Object in a Resv message. Once the period of
before issuing a PathTear message. time has elapsed, the ingress node sends a PathTear message. By
default this period of time SHOULD be 30 seconds.
7.3. Notify Message Procedures 7.3. Notify Message Procedures
Intermediate and egress nodes may trigger the setting of Intermediate and egress nodes may trigger the setting of
administrative status before a deletion via the use of Notify administrative status via the use of Notify messages. To accomplish
messages. To accomplish this, an intermediate or egress node this, an intermediate or egress node generates a Notify message with
generates a Notify message with the corresponding upstream notify the corresponding upstream notify session information. The Admin
session information. The Admin Status Object MUST be included in the Status Object MUST be included in the session information, with the
session information, with the Down (D) bit set. The Notify message appropriate bit or bits set. The Reflect (R) bit MUST NOT be set.
may, but is not required to be, encapsulated, see Section 4.3. The Notify message may be, but is not required to be, encapsulated,
see Section 4.3.
An ingress node receiving a Notify message containing an Admin Status An ingress node receiving a Notify message containing an Admin Status
Object with the Down (D) bit set, SHOULD initiate the deletion Object with the Delete (D) bit set, SHOULD initiate the deletion
procedure described in the previous section. procedure described in the previous section. Other bits SHOULD be
propagated in an outgoing Path message as normal.
7.3.1. Compatibility and Error Procedures 7.3.1. Compatibility and Error Procedures
Some special processing is required in order to cover the case of Some special processing is required in order to cover the case of
nodes that do not support the Admin Status Object and other error nodes that do not support the Admin Status Object and other error
conditions. Specifically, a node that sends a Notify message conditions. Specifically, a node that sends a Notify message
containing an Admin Status Object with the Down (D) bit set MUST containing an Admin Status Object with the Down (D) bit set MUST
verify that it receives a corresponding Path message with the Down verify that it receives a corresponding Path message with the Down
(D) bit set within a configurable period of time. By default this (D) bit set within a configurable period of time. By default this
period of time SHOULD be 30 seconds. If the node does not receive period of time SHOULD be 30 seconds. If the node does not receive
such a Path message, it SHOULD send a ResvTear message upstream and a such a Path message, it SHOULD send a PathTear message downstream and
PathTear message downstream. either a ResvTear message or a PathErr message with the
Path_State_Removed flag set upstream.
8. Control Channel Separation 8. Control Channel Separation
This section provides the protocol specific formats and procedures to This section provides the protocol specific formats and procedures to
required support a control channel not being in-band with a data required support a control channel not being in-band with a data
channel. channel.
8.1. Interface Identification 8.1. Interface Identification
The choice of the data interface to use is always made by the sender The choice of the data interface to use is always made by the sender
of the Path message. The choice of the data interface is indicated by of the Path message. The choice of the data interface is indicated by
the sender of the Path message by including the data channel's the sender of the Path message by including the data channel's
interface identifier in the message using a new RSVP_HOP object sub- interface identifier in the message using a new RSVP_HOP object sub-
type. For bidirectional LSPs, the sender chooses the data interface type. For bidirectional LSPs, the sender chooses the data interface
in each direction. In all cases but bundling [MPLS-BUNDLE] the in each direction. In all cases but bundling, see [MPLS-BUNDLE], the
upstream interface is implied by the downstream interface. For upstream interface is implied by the downstream interface. For
bundling, the path sender explicitly identifies the component bundling, the path sender explicitly identifies the component
interface used in each direction. The new RSVP_HOP object is used in interface used in each direction. The new RSVP_HOP object is used in
Resv message to indicate the downstream node's usage of the indicated Resv message to indicate the downstream node's usage of the indicated
interface(s). 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:
skipping to change at page 21, line 4 skipping to change at page 24, line 22
| Length | Class-Num (3) | C-Type (3)TBA | | Length | Class-Num (3) | C-Type (3)TBA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 (3)TBA | | Length | Class-Num (3) | C-Type (4)TBA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IPv6 Next/Previous Hop Address | | IPv6 Next/Previous Hop Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface Handle | | Logical Interface Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ TLVs ~ ~ TLVs ~
skipping to change at page 22, line 5 skipping to change at page 25, line 24
LSP. For a unidirectional LSP, a forward channel MUST be indicated. LSP. For a unidirectional LSP, a forward channel MUST be indicated.
For a bidirectional LSP that uses bundled links, a reverse channel For a bidirectional LSP that uses bundled links, a reverse channel
MUST be indicated. Data channels are specified from the view point MUST be indicated. Data channels are specified from the view point
of the sender of the Path message. The IF_ID RSVP_HOP object SHOULD of the sender of the Path message. The IF_ID RSVP_HOP object SHOULD
NOT be used when no TLVs are needed. NOT be used when no TLVs are needed.
A node receiving one or more TLVs in a Path message saves their A node receiving one or more TLVs in a Path message saves their
values and returns them in the HOP objects of subsequent Resv values and returns them in the HOP objects of subsequent Resv
messages sent to the node that originated the TLVs. messages sent to the node that originated the TLVs.
As with [MPLS-TE], the node originating an IF_ID object must ensure
that the selected outgoing interface is consistent with the outgoing
ERO. A node that receives an IF_ID object SHOULD check whether the
information carried in this object is consistent with the information
carried in a received ERO, and if not it MUST send a PathErr with the
error code "Routing Error" and error value of "Bad Explicit Route
Object" toward the sender.
8.2. Errored Interface Identification
There are cases where it is useful to indicate a specific interface
associated with an error. To support these cases the IF_ID
ERROR_SPEC Objects are defined.
8.2.1. IF_ID ERROR_SPEC Objects
The format of the IPv4 IF_ID ERROR_SPEC Object is:
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 (6) | C-Type (3)TBA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Error Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the IPv6 IF_ID ERROR_SPEC Object is:
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 (6) | C-Type (4)TBA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Error Node Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC2205] for a description of address, flags, error code and
error value fields. See [GMPLS-SIG] for a description of
parameters and encoding of TLVs.n
8.2.2. Procedures
Nodes wishing to indicate that an error is related to a specific
interface SHOULD use the appropriate IF_ID ERROR_SPEC Object in the
corresponding PathErr or ResvErr message. IF_ID ERROR_SPEC Objects
SHOULD be generated and processed as any other ERROR_SPEC Object, see
[RFC2205].
9. Fault Handling 9. Fault Handling
The handling of two types of control communication faults are The handling of two types of control communication faults is
described in this section. The first, referred to as nodal faults, described in this section. The first, referred to as nodal faults,
relates to the case where a node losses its control state (e.g., relates to the case where a node losses its control state (e.g.,
after a restart) but does not loose its data forwarding state. In after a restart) but does not loose its data forwarding state. In
the second, referred to as control channel faults, relates to the the second, referred to as control channel faults, relates to the
case where control communication is lost between two nodes. The case where control communication is lost between two nodes. The
handling of both faults are supported by a the RESTART_CAP object handling of both faults is supported by the Restart_Cap object
defined below and require the use of Hello messages. defined below and require the use of Hello messages.
Please note this section is derived from [PAN-RESTART]. Note, the Restart_Cap object MUST NOT be sent when there is no
mechanism to detect data channel failures independent of control
channel failures.
9.1. RESTART_CAP Object Please note this section is derived from [PAN-RESTART].
The RESTART_CAP Object is carried in Hello messages. The modified 9.1. Restart_Cap Object
Hello message format is:
<Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO> The Restart_Cap Object is carried in Hello messages.
[ <RESTART_CAP> ]
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(TBD)| C-Type (1) | | Length | Class-Num(TBA)| 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 set to the sum of the time it takes the sender of the object be set to the sum of the time it takes the sender of the object
to restart its RSVP-TE component (to the point where it can to restart its RSVP-TE component (to the point where it can
exchange RSVP Hello with its neighbors) and the communication exchange RSVP Hello with its neighbors) and the communication
channel that is used for RSVP communication. channel that is used for RSVP communication.
Recovery Time: 32 bits Recovery Time: 32 bits
skipping to change at page 23, line 15 skipping to change at page 28, line 22
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 the recipient to resyncronize RSVP and MPLS forwarding for the recipient to resyncronize RSVP and MPLS forwarding
state with the sender after the re-establishment of Hello state 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.
A value of 0xffffffff indicates that resynchronization may A value of 0xffffffff indicates that resynchronization may
occur at a rate selected by the receiver. occur at a rate selected by the receiver.
9.2. Processing of RESTART_CAP Object 9.2. Processing of Restart_Cap Object
Nodes supporting state recovery MUST advertise this capability by Nodes supporting state recovery advertise this capability by carrying
carrying the RESTART_CAP object in the Hello messages it sends to the the Restart_Cap object in Hello messages. Such nodes MUST include
neighbors. Usage of the special case Recovery Time values is the Restart_Cap object in all Hello messages. (Note that this
described in greater detail below. includes Hello messages containing ACK objects.) Usage of the
special case Recovery Time values is described in greater detail
below.
When a node receives a Hello message with the RESTART_CAP object, it When a node receives a Hello message with the Restart_Cap object, it
SHOULD record the values of the parameters received. Note that the SHOULD record the values of the parameters received.
RESTART_CAP Object will only be present when the Dst_Instance value
is set to zero (0).
9.3. Modification to Hello Processing to Support State Recovery 9.3. Modification to Hello Processing to Support State Recovery
Nodes supporting state recovery MUST include the RESTART_CAP object When a node determines that RSVP communication with a neighbor has
in all Hello messages which are sent with Dst_Instance value set to been lost, and the node previously learned that the neighbor supports
zero (0). state recovery, the node SHOULD wait at least the amount of time
When an LSR determines that RSVP communication with a neighbor has
been lost, and the LSR previously learned that the neighbor supports
state recovery, the LSR SHOULD wait at least the amount of time
indicated by the Restart Time indicated by the neighbor before indicated by the Restart Time indicated by the neighbor before
invoking procedures related to communication loss. An LSR MAY wait invoking procedures related to communication loss. A node MAY wait
longer based on local policy or configuration information. longer based on local policy or configuration information.
During this waiting period, all Hello messages MUST be sent with a During this waiting period, all Hello messages MUST be sent with a
Dst_Instance value set to zero (0), and Src_Instance should be Dst_Instance value set to zero (0), and Src_Instance should be
unchanged. While waiting, the LSR SHOULD also preserve the RSVP and unchanged. While waiting, the node SHOULD also preserve the RSVP and
MPLS forwarding state for (already) established LSPs that traverse MPLS forwarding state for (already) established LSPs that traverse
the link(s) between the LSR and the neighbor. In a sense with the link(s) between the node and the neighbor. In a sense with
respect to established LSPs the LSR behaves as if it continues to respect to established LSPs the node behaves as if it continues to
receive periodic RSVP refresh messages from the neighbor. The LSR receive periodic RSVP refresh messages from the neighbor. The node
MAY clear RSVP and forwarding state for the LSPs that are in the MAY clear RSVP and forwarding state for the LSPs that are in the
process of being established when their refresh timers expire. process of being established when their refresh timers expire.
Refreshing of Resv state SHOULD be suppressed during this waiting Refreshing of Resv and Path state SHOULD be suppressed during this
period. waiting period.
During this waiting period, the LSR MAY inform other nodes of the During this waiting period, the node MAY inform other nodes of the
communication loss via send a PathErr and/or upstream Notify message communication loss via a PathErr and/or upstream Notify message with
with "Control Channel Degraded State" indication. If such "Control Channel Degraded State" indication. If such notification
notification has been sent, then upon restoration of the control has been sent, then upon restoration of the control channel the node
channel the LSR MUST inform other nodes of the restoration via a MUST inform other nodes of the restoration via a PathErr and/or
PathErr and/or upstream Notify message with "Control Channel Active upstream Notify message with "Control Channel Active State"
State" indication. (Specific error codes are to be assigned IANA.) indication. (Specific error codes are to be assigned IANA.)
When a new Hello message is received from the neighbor, the LSR 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.
9.4. Control Channel Faults 9.4. Control Channel Faults
In the case of control channel faults, the LSR SHOULD refresh all In the case of control channel faults, the node SHOULD refresh all
state shared with the neighbor. Summary Refreshes [RSVP-RR] with the state shared with the neighbor. Summary Refreshes [RSVP-RR] with the
ACK_Desired flag set SHOULD be used, if supported. Note that if a ACK_Desired flag set SHOULD be used, if supported. Note that if a
large number of messages are need, some pacing should be applied. large number of messages are need, some pacing should be applied.
All state SHOULD be refreshed within the Recovery time advertised by All state SHOULD be refreshed within the Recovery time advertised by
the neighbor. the neighbor.
9.5. Nodal Faults 9.5. Nodal Faults
Recovering from nodal faults primarily relies on existing protocol Recovering from nodal faults uses one new object and other existing
messages and objects. protocol messages and objects.
9.5.1. Procedures for the Restarting LSR 9.5.1. Recovery Label
After an LSR restarts its control plane, an LSR that supports state The Recovery_Label object is used during the nodal fault recovery
process. The format of a Recovery_Label object is identical to a
generalized label. A Recovery_Label object uses Class-Number TBA (of
form 0bbbbbbb) and the C-Type of the label being suggested.
9.5.2. Procedures for the Restarting node
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 LSR 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 LSR sends to its neighbors. Hello message the node sends to its neighbors.
If the forwarding state was preserved, then the LSR initiates the If the forwarding state was preserved, then the node initiates the
state recovery process. The LSR MUST be prepared to support the state recovery process. The period during which a node is prepared
recovery process for at least the time it advertised in the Recovery to support the recovery process is referred to as the Recovery
Time in the Hello messages used during initial Hello message Period. The total duration of the Recovery Period is advertised by
exchange, i.e., when the Dst_Instance that the LSR advertises to the the recovering node in the Recovery Time parameter of the Restart_Cap
neighbor was 0. The period during which a node is prepared to object. The Recovery Time MUST be set to the duration of the
support the recovery process is referred to as the Recovery Period. Recovery Period in all Hello messages sent during the Recovery
Note, a Recovery Time value of 0xffffffff indicates that the Recovery Period. A Recovery Time value of 0xffffffff indicates that the
Period is effectively infinite. State that is not resynchronized Recovery Period is effectively infinite. State that is not
during the Recovery Period SHOULD be removed at the end of the resynchronized during the Recovery Period SHOULD be removed at the
Period. Note that if during Hello synchronization the restarting end of the Period.
LSR determines that a neighbor does not support state recovery, and
the restarting LSR maintains its MPLS forwarding state on a per Note that if during Hello synchronization the restarting node
neighbor basis, the restarting LSR should immediately consider the determines that a neighbor does not support state recovery, and the
Recovery Period with that neighbor completed. Note forwarding state restarting node maintains its MPLS forwarding state on a per neighbor
can be considered to be maintained on a per neighbor basis when per basis, the restarting node should immediately consider the Recovery
Period with that neighbor completed. Note forwarding state can be
considered to be maintained on a per neighbor basis when per
interface labels are used on point-to-point interfaces. interface labels are used on point-to-point interfaces.
When an LSR receives a Path message during the Recovery Period, the When a node receives a Path message during the Recovery Period, the
LSR first checks if it has an RSVP state associated with the message. node first checks if it has an RSVP state associated with the
If the state is found, then the LSR handles this message according to message. If the state is found, then the node handles this message
previously defined procedures. according to previously defined procedures.
If the RSVP state is not found, and the message does not carry a If the RSVP state is not found, and the message does not carry a
SUGGESTED_LABEL object, the LSR treats this as a setup for a new LSP, Recovery_Label object, the node treats this as a setup for a new LSP,
and handles it according to previously defined procedures. and handles it according to previously defined procedures.
If the RSVP state is not found, and the message carries the If the RSVP state is not found, and the message carries a
SUGGESTED_LABEL object, the LSR searches its MPLS forwarding table Recovery_Label object, the node searches its MPLS forwarding table
(the one that was preserved across the restart) for an entry whose (the one that was preserved across the restart) for an entry whose
incoming interface matches the Path message and whose incoming label incoming interface matches the Path message and whose incoming label
is equal to the label carried in the SUGGESTED_LABEL object. is equal to the label carried in the Recovery_Label object.
If the MPLS forwarding table entry is not found, the LSR treats this If the MPLS forwarding table entry is not found, the node treats this
as a setup for a new LSP, and handles it according to previously as a setup for a new LSP, and handles it according to previously
defined procedures. defined procedures.
If the MPLS forwarding table entry is found, the appropriate RSVP If the MPLS forwarding table entry is found, the appropriate RSVP
state is created, the entry is bound to the LSP associated with the state is created, the entry is bound to the LSP associated with the
message, and related forwarding state should be considered as valid message, and related forwarding state should be considered as valid
and refreshed. Normal Path message processing should also be and refreshed. Normal Path message processing should also be
conducted. When sending the corresponding outgoing Path message the conducted. When sending the corresponding outgoing Path message the
node SHOULD include a SUGGESTED_LABEL object with a label value node SHOULD include a Suggested_Label object with a label value
matching the outgoing label from the now restored forwarding entry. matching the outgoing label from the now restored forwarding entry.
The outgoing interface SHOULD also be selected based on the The outgoing interface SHOULD also be selected based on the
forwarding entry. forwarding entry.
Additionally, for bidirectional LSPs, the LSR extracts the label from Additionally, for bidirectional LSPs, the node extracts the label
the UPSTREAM_LABEL object carried in the received Path message, and from the UPSTREAM_LABEL object carried in the received Path message,
searches its MPLS forwarding table for an entry whose outgoing label and searches its MPLS forwarding table for an entry whose outgoing
is equal to the label carried in the object (in the case of link label is equal to the label carried in the object (in the case of
bundling, this may also involved first identifying the appropriate link bundling, this may also involved first identifying the
incoming component link). appropriate incoming component link).
If the MPLS forwarding table entry is not found, the LSR treats this If the MPLS forwarding table entry is not found, the node treats this
as a setup for a new LSP, and handles it according to previously as a setup for a new LSP, and handles it according to previously
defined procedures. defined procedures.
If the MPLS forwarding table entry is found, the entry is bound to If the MPLS forwarding table entry is found, the entry is bound to
the LSP associated with the Path message, and the entry is no longer the LSP associated with the Path message, and the entry should be
considered as stale. In addition, if the LSR is not the tail-end of considered to be resyncronized. In addition, if the node is not the
the LSP, the corresponding outgoing Path messages is sent with the tail-end of the LSP, the corresponding outgoing Path messages is sent
incoming label from that entry carried in the UPSTREAM_LABEL object. with the incoming label from that entry carried in the UPSTREAM_LABEL
object.
During the Recovery Period, Resv messages are processed normally with During the Recovery Period, Resv messages are processed normally with
two exceptions. In the case that a forwarding entry is recovered, no two exceptions. In the case that a forwarding entry is recovered, no
new label or resource allocation is required while processing the new label or resource allocation is required while processing the
Resv message. The second exception applies only if the Recovery Time Resv message. The second exception applies only if the Recovery Time
is not 0xffffffff. In this case, ResvErr messages SHOULD NOT be is not 0xffffffff. In this case, ResvErr messages SHOULD NOT be
generated when a Resv message with no matching Path state is generated when a Resv message with no matching Path state is
received. In this case the Resv message SHOULD just be sighlently received. In this case the Resv message SHOULD just be silently
discarded. discarded.
9.5.2. Procedures for the Neighbor of a Restarting LSR 9.5.3. Procedures for the Neighbor of a Restarting node
The following specifies the procedures that apply when the LSR The following specifies the procedures that apply when the node
reestablishes communication with the neighbor's control plane within reestablishes communication with the neighbor's control plane within
the Restart Time, the LSR determines (using the procedures defined in the Restart Time, the node determines (using the procedures defined
Section 5 of [RSVP-TE]) that the neighbor's control plane has in Section 5 of [RSVP-TE]) 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). from the neighbor).
Upon detecting a restart with a neighbor that supports state Upon detecting a restart with a neighbor that supports state
recovery, an LSR 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 neighbor. The outgoing Path messages MUST include the Recovery_Label
SUGGESTED_LABEL object containing the label value received in the object containing the label value received in the most recently
most recently received corresponding Resv message. All Path state received corresponding Resv message. All Path state SHOULD be
SHOULD be refreshed within approximately 1/2 of the Recovery time refreshed within approximately 1/2 of the Recovery time advertised by
advertised by the restarted neighbor. If there are many LSP's going the restarted neighbor. If there are many LSP's going through the
through the restarting LSR, the neighbor LSR should avoid sending restarting node, the neighbor node should avoid sending Path messages
Path messages in a short time interval, as to avoid unnecessary in a short time interval, as to avoid unnecessary stressing the
stressing the restarting LSR's CPU. Instead, it should spread the restarting node's CPU. Instead, it should spread the messages across
messages across 1/2 the Recovery Time interval. 1/2 the Recovery Time interval.
During the recovery period, new Path state being advertised to the
restarted neighbor SHOULD not include the SUGGESTED_LABEL object in
the corresponding outgoing Path message. This will prevent the
restarting node from erroneously reusing a saved forwarding entry.
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 may be re- message SHOULD be generated and normal state processing SHOULD be re-
enabled. 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
skipping to change at page 28, line 4 skipping to change at page 33, line 28
[ <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> ]
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> ]
<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> ... ]
skipping to change at page 29, line 5 skipping to change at page 34, line 30
<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:
<Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO>
[ <RESTART_CAP> ]
10.2. Addressing Path and PathTear Messages 10.2. Addressing Path and PathTear 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 and PathTear
messages carry the destination address of the session in the IP messages carry the destination address of the session in the IP
header. In generalized signaling, routes are usually explicitly 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 or PathTear message to a node that it
knows to be adjacent at the data plane (i.e. along the path of the knows to be adjacent at the data plane (i.e. along the path of the
LSP) it SHOULD address the message directly to that node. In this LSP) it SHOULD address the message directly to an address associated
case the router-alert option SHOULD not be included. with the adjacent node's control plane. In this case the router-
alert option SHOULD not be included.
11. Acknowledgments 11. Acknowledgments
This draft is the work of numerous authors and consists of a This draft 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 drafts in this area. A list of
the drafts from which material and ideas were incorporated follows: the drafts from which material and ideas were incorporated follows:
draft-saha-rsvp-optical-signaling-00.txt draft-saha-rsvp-optical-signaling-00.txt
draft-lang-mpls-rsvp-oxc-00.txt draft-lang-mpls-rsvp-oxc-00.txt
draft-kompella-mpls-optical-00.txt draft-kompella-mpls-optical-00.txt
draft-fan-mpls-lambda-signaling-00.txt draft-fan-mpls-lambda-signaling-00.txt
draft-pan-rsvp-te-restart-01.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, and Adrian Farrel. Portions of Section 4 are including Igor Bryskin, Adrian Farrel and Dimitrios Pendarakis.
based on suggestions and text proposed by Adrian Farrel. Portions of Section 4 are based on suggestions and text proposed by
Adrian Farrel.
12. Security Considerations 12. Security Considerations
The transmission of notify messages using IP in IP, breaks RSVP's The transmission of notify messages using IP in IP, breaks RSVP's
hop-by-hop integrity and authentication model. Fortunately, such hop-by-hop integrity and authentication model. Fortunately, such
usage mirrors the IP end-to-end model. In the case where RSVP is usage mirrors the IP end-to-end model. In the case where RSVP is
generating end-to-end messages and integrity and/or authentication generating end-to-end messages and integrity and/or authentication
are desired, the standard IPSEC based integrity and authentication are desired, the standard IPSEC based integrity and authentication
methods SHOULD be used. methods SHOULD be used.
This draft introduces no other new security considerations to [RSVP- This draft introduces no other new security considerations to [RSVP-
TE]. TE].
13. References 13. IANA Considerations
IANA assigns values to RSVP protocol parameters. Within the current
document multiple objects are defined. Each of these objects contain
C-Types. This section defines the rules for the assignment of the
related C-Type values. This section uses the terminology of BCP 26
"Guidelines for Writing an IANA Considerations Section in RFCs"
[BCP26].
As per [RFC2205], C-Type is an 8-bit number that identifies the
function of an object. There are no range restrictions. All
possible values except zero are available for assignment.
The assignment of C-Type values of the objects defined in this
document fall into three categories. The first category inherit C-
Types from the Label object, i.e., object class number 16 [RSVP-TE].
IANA is requested to institute a policy whereby all C-Type values
assign for the Label object are also assigned for the following
objects:
o Suggested_Label (Class-Num TBA)
o Upstream_Label (Class-Num TBA)
o Recovery_Label (Class-Num TBA)
The second category of objects follow independent policies.
Specifically, following the policies outlined in [BCP26], C-Type
values in the range 0x00 - 0x3F are allocated through an IETF
Consensus action, values in the range 00x40 - 0x5F are allocated as
First Come First Served, and values in the range 0x60 - 0x7F are
reserved for Private Use. This policy applies to the following
objects.
o Label_Set (Class-Num TBA)
o Notify_Request (Class-Num TBA)
o Protection (Class-Num TBA)
o Admin Status (Class-Num TBA)
o Restart_Cap (Class-Num TBA)
The assignment of C-Type values for the remaining object, the
Acceptable_Label_Set object, follows the assignment of C-Type values
of the Label_Set object. IANA is requested to institute a policy
whereby all C-Type values assigned for the Label_Set object are also
assigned for the Acceptable_Label_Set object.
14. References
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[MPLS-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link Bundling
in MPLS Traffic Engineering", Internet Draft,
draft-kompella-mpls-bundle-05.txt, Feb., 2001.
[MPLS-HIERARCHY] Kompella, K., and Rekhter, Y., "LSP Hierarchy with [MPLS-HIERARCHY] Kompella, K., and Rekhter, Y., "LSP Hierarchy with
MPLS TE", Internet Draft, MPLS TE", Internet Draft,
draft-ietf-mpls-lsp-hierarchy-02.txt, Feb., 2001. draft-ietf-mpls-lsp-hierarchy-02.txt, Feb., 2001.
[MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links [MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links
in RSVP-TE", Internet Draft, in RSVP-TE", Internet Draft,
draft-ietf-mpls-rsvp-unnum-01.txt, February 2001 draft-ietf-mpls-rsvp-unnum-02.txt, August 2001
[GMPLS-LDP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - [GMPLS-LDP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling -
CR-LDP Extensions", Internet Draft, CR-LDP Extensions", Internet Draft,
draft-ietf-mpls-generalized-cr-ldp-01.txt, draft-ietf-mpls-generalized-cr-ldp-01.txt,
February 2001. February 2001.
[GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS - [GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS -
Signaling Functional Description", Internet Draft, Signaling Functional Description", Internet Draft,
draft-ietf-mpls-generalized-signaling-02.txt, draft-ietf-mpls-generalized-signaling-02.txt,
February 2001. February 2001.
[PAN-RESTART] Pan, et al, "Graceful Restart Mechanism for RSVP-TE", [PAN-RESTART] Pan, P, et al, "Graceful Restart Mechanism for RSVP-TE",
Internet Draft, draft-pan-rsvp-te-restart-01.txt, Internet Draft, draft-pan-rsvp-te-restart-01.txt,
July 2001. July 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119. Requirement Levels," RFC 2119.
[RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol [RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol
-- Version 1 Functional Specification", RFC 2205, -- Version 1 Functional Specification", RFC 2205,
September 1997. September 1997.
[RSVP-TE] Awduche, D.O., Berger, L., Gan, D.-H., Li, T., Swallow, G., [RSVP-TE] Awduche, D.O. et al, "RSVP-TE: Extensions to RSVP for LSP
and Srinivasan, V., "RSVP-TE: Extensions to RSVP for LSP
Tunnels," Internet Draft, Tunnels," Internet Draft,
draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, February 2001. draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, February 2001.
[RSVP-RR] Berger, L. et al, "RFC 2961: RSVP Refresh Overhead [RSVP-RR] Berger, L. et al, "RFC 2961: RSVP Refresh Overhead
Reduction Extensions", RFC2961. Reduction Extensions", RFC2961.
14. Authors' Addresses 15. Authors' Addresses
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
skipping to change at page 31, line 46 skipping to change at page 38, line 28
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.
100 Nickerson Road 200 Nickerson Road
Marlborough, MA 01752 Marlborough, MA 01752
Phone: +1 508 460 6969 Ext. 627 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 Calient Networks
25 Castilian 25 Castilian
Goleta, CA 93117 Goleta, CA 93117
skipping to change at page 33, line 4 skipping to change at page 39, line 31
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 Email: yakov@juniper.net
Debanjan Saha Debanjan Saha
Tellium Optical Systems Tellium Optical Systems
2 Crescent Place 2 Crescent Place
Oceanport, NJ 07757-0901 Oceanport, NJ 07757-0901
Phone: +1 732 923 4264 Phone: +1 732 923 4264
Fax: +1 732 923 9804 Fax: +1 732 923 9804
Email: dsaha@tellium.com Email: dsaha@tellium.com
Vishal Sharma Vishal Sharma
Jasmine Networks, Inc. Metanoia, Inc.
3061 Zanker Road, Suite B 335 Elan Village Lane, Unit 203
San Jose, CA 95134 San Jose, CA 95134-2539
Phone: +1 408 895 5030 Phone: +1 408-943-1794
Fax: +1 408 895 5050 Email: v.sharma@ieee.org
Email: vsharma@jasminenetworks.com
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 Voice: +1 978 244 8143
Email: swallow@cisco.com Email: swallow@cisco.com
Z. Bo Tang Z. Bo Tang
Tellium, Inc. Tellium, Inc.
2 Crescent Place 2 Crescent Place
P.O. Box 901 P.O. Box 901
Oceanport, NJ 07757-0901 Oceanport, NJ 07757-0901
Phone: +1 732 923 4231 Phone: +1 732 923 4231
Fax: +1 732 923 9804 Fax: +1 732 923 9804
Email: btang@tellium.com Email: btang@tellium.com
Generated on: Fri Jul 20 16:38:09 EDT 2001 Generated on: Mon Oct 1 01:20:20 EDT 2001
 End of changes. 

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