draft-ietf-mpls-generalized-rsvp-te-01.txt   draft-ietf-mpls-generalized-rsvp-te-02.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: September 2001 Lou Berger (Movaz Networks) Expiration Date: October 2001 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.)
Eric Mannie (EBONE) Eric Mannie (EBONE)
Jonathan P. Lang (Calient Networks) Jonathan P. Lang (Calient Networks)
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 (Jasmine Networks)
George Swallow (Cisco Systems) George Swallow (Cisco Systems)
Z. Bo Tang (Tellium, Inc.) Z. Bo Tang (Tellium, Inc.)
March 2001 April 2001
Generalized MPLS Signaling - RSVP-TE Extensions Generalized MPLS Signaling - RSVP-TE Extensions
draft-ietf-mpls-generalized-rsvp-te-01.txt draft-ietf-mpls-generalized-rsvp-te-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
To view the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
Directory, see http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes extensions to RSVP-TE signaling required to This document describes extensions to RSVP-TE signaling required to
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 .............................................. 3
2 Label Related Formats .................................... 3 2 Label Related Formats .................................... 3
2.1 Generalized Label Request ................................ 3 2.1 Generalized Label Request ................................ 3
2.1.1 Generalized Label Request with SONET/SDH Label Range ...... 4 2.1.1 Procedures ................................................ 4
2.1.2 Procedures ................................................ 4 2.1.2 Bandwidth Encoding ........................................ 5
2.1.3 Bandwidth Encoding ........................................ 5
2.2 Generalized Label ......................................... 5 2.2 Generalized Label ......................................... 5
2.2.1 Procedures ................................................ 6 2.2.1 Procedures ................................................ 5
2.3 Waveband Switching ........................................ 6 2.3 Waveband Switching ........................................ 6
2.3.1 Procedures ................................................ 6 2.3.1 Procedures ................................................ 6
2.4 Suggested Label ........................................... 7 2.4 Suggested Label ........................................... 7
2.5 Label Set ................................................. 7 2.5 Label Set ................................................. 7
2.5.1 Procedures ................................................ 8 2.5.1 Procedures ................................................ 8
3 Bidirectional LSPs ........................................ 9 3 Bidirectional LSPs ........................................ 9
3.1 Procedures ................................................ 9 3.1 Procedures ................................................ 9
3.2 Contention Resolution ..................................... 10 3.2 Contention Resolution ..................................... 9
4 Notification .............................................. 10 4 Notification .............................................. 10
4.1 Notify Request Objects .................................... 10 4.1 Acceptable Label Set Object ............................... 10
4.1.1 Required Information ...................................... 11 4.2 Notify Request Objects .................................... 11
4.1.2 Procedures ................................................ 11 4.2.1 Required Information ...................................... 11
4.2 Notify Message ............................................ 12 4.2.2 Procedures ................................................ 12
4.2.1 Required Information ...................................... 12 4.3 Notify Message ............................................ 12
4.2.2 Procedures ................................................ 13 4.3.1 Required Information ...................................... 13
4.3 Removing State with a PathErr message ..................... 14 4.3.2 Procedures ................................................ 13
4.4 Removing State with a PathErr message ..................... 14
5 Explicit Label Control .................................... 15 5 Explicit Label Control .................................... 15
5.1 Procedures ................................................ 15 5.1 Procedures ................................................ 16
6 Protection Object ......................................... 16 6 Protection Object ......................................... 17
6.1 Procedures ................................................ 17 6.1 Procedures ................................................ 17
7 RSVP Message Formats ...................................... 17 7 RSVP Message Formats ...................................... 17
8 Acknowledgments ........................................... 18 8 Acknowledgments ........................................... 19
9 Security Considerations ................................... 18 9 Security Considerations ................................... 20
10 References ................................................ 19 10 References ................................................ 20
11 Authors' Addresses ........................................ 19 11 Authors' Addresses ........................................ 21
Changes from previous version: Changes from previous version:
o Revised label request o Fixed format of notification message. Had <upstream notify session>
o Moved protection flags to separate object and <downstream notify session> reversed.
o Added IPv6 support to Notify message o Added Acceptable Label Set
o Minor text cleanup o Removed SONET/SDH specifics.
1. Introduction 1. Introduction
Generalized MPLS extends MPLS from supporting packet (PSC) interfaces Generalized MPLS extends MPLS from supporting packet (PSC) interfaces
and switching to include support of three new classes of interfaces and switching to include support of three new classes of interfaces
and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and
Fiber-Switch (FSC). A functional description of the extensions to Fiber-Switch (FSC). A functional description of the extensions to
MPLS signaling needed to support the new classes of interfaces and MPLS signaling needed to support the new classes of interfaces and
switching is provided in [GMPLS-SIG]. This document presents RSVP-TE switching is provided in [GMPLS-SIG]. This document presents RSVP-TE
specific formats and mechanisms needed to support all four classes of specific formats and mechanisms needed to support all four classes of
interfaces. CR-LDP extensions can be found in [GMPLS-LDP]. interfaces. CR-LDP extensions can be found in [GMPLS-LDP].
[GMPLS-SIG] should be viewed as a companion document to this [GMPLS-SIG] should be viewed as a companion document to this
document. The format of this document parallels [GMPLS-SIG]. In document. The format of this document parallels [GMPLS-SIG]. In
addition to the other features of Generalized MPLS, this document addition to the other features of Generalized MPLS, this document
also defines RSVP-TE specific features to support rapid failure also defines RSVP-TE specific features to support rapid failure
notification, see Section 4. notification, see Sections 4.2 and 4.3.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Label Related Formats 2. Label Related Formats
This section defines formats for a generalized label request, a This section defines formats for a generalized label request, a
generalized label, support for waveband switching, suggested label generalized label, support for waveband switching, suggested label
and label sets. and label sets.
skipping to change at page 4, line 17 skipping to change at page 4, line 17
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (19)|C-Type (4)[TBA]| | Length | Class-Num (19)|C-Type (4)[TBA]|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type | Reserved | G-PID | | LSP Enc. Type | Reserved | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of parameters. See [GMPLS-SIG] for a description of parameters.
2.1.1. Generalized Label Request with SONET/SDH Label Range 2.1.1. Procedures
The format of a Generalized Label Request with SONET/SDH Label Range
(in RSVP) 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 (19)|C-Type (5)[TBA]|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type | Reserved | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RNC | Signal Type |Rsrved.| RGT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of parameters.
2.1.2. Procedures
A node processing a Path message containing a Generalized Label A node processing a Path message containing a Generalized Label
Request must verify that the requested parameters can be satisfied by Request must verify that the requested parameters can be satisfied by
the incoming interface, the node and by the outgoing interface. The the interface on which the incoming label is to be allocated, the
node may either directly support the LSP or it may use a tunnel (FA), node itself, and by the interface on which the traffic will be
i.e., another class of switching. In either case, each parameter transmitted. The node may either directly support the LSP or it may
must be checked. use a tunnel (FA), i.e., another class of switching. In either case,
each parameter must be checked.
Note that local node policy dictates when tunnels may be used and Note that local node policy dictates when tunnels may be used and
when they may be created. Local policy may allow for tunnels to be when they may be created. Local policy may allow for tunnels to be
dynamically established or may be solely administratively controlled. dynamically established or may be solely administratively controlled.
For more information on tunnels and processing of ER hops when using For more information on tunnels and processing of ER hops when using
tunnels see [MPLS-HIERARCHY]. tunnels see [MPLS-HIERARCHY].
Transit and egress nodes MUST verify that the node itself and, where Transit and egress nodes MUST verify that the node itself and, where
appropriate, that the outgoing interface or tunnel can support the appropriate, that the interface or tunnel on which the traffic will
requested LSP Encoding Type. If encoding cannot be supported, the be transmitted can support the requested LSP Encoding Type. If
node MUST generate a PathErr message, with a "Routing encoding cannot be supported, the node MUST generate a PathErr
problem/Unsupported Encoding" indication. message, with a "Routing problem/Unsupported Encoding" indication.
The G-PID parameter is normally only examined at the egress. If the The G-PID parameter is normally only examined at the egress. If the
indicated G-PID cannot be supported then the egress MUST generate a indicated G-PID cannot be supported then the egress MUST generate a
PathErr message, with a "Routing problem/Unsupported GPID" PathErr message, with a "Routing problem/Unsupported L3PID"
indication. In the case of PSC and when penultimate hop popping indication. In the case of PSC and when penultimate hop popping
(PHP) is requested, the penultimate hop also examines the (stored) G- (PHP) is requested, the penultimate hop also examines the (stored) G-
PID during the processing of the Resv message. In this case if the PID during the processing of the Resv message. In this case if the
G-PID is not supported, then the penultimate hop MUST generate a G-PID is not supported, then the penultimate hop MUST generate a
ResvErr message with a "Routing problem/Unacceptable label value" ResvErr message with a "Routing problem/Unacceptable label value"
indication. indication. The generated ResvErr message MAY include an Acceptable
Label Set, see Section 4.1.
When an error message is not generated, normal processing occurs. In When an error message is not generated, normal processing occurs. In
the transit case this will typically result in a Path message being the transit case this will typically result in a Path message being
propagated. In the egress case and PHP special case this will propagated. In the egress case and PHP special case this will
typically result in a Resv message being generated. typically result in a Resv message being generated.
2.1.3. Bandwidth Encoding 2.1.2. Bandwidth Encoding
Bandwidth encodings are carried in the SENDER_TSPEC and FLOWSPEC Bandwidth encodings are carried in the SENDER_TSPEC and FLOWSPEC
objects. See [GMPLS-SIG] for a definition of values to be used for objects. See [GMPLS-SIG] for a definition of values to be used for
specific signal types. These values are set in the Peak Data Rate specific signal types. These values are set in the Peak Data Rate
field of Int-Serv objects. Other bandwidth/service related field of Int-Serv objects. Other bandwidth/service related
parameters in the object are ignored and carried transparently. parameters in the object are ignored and carried transparently.
2.2. Generalized Label 2.2. Generalized Label
The format of a Generalized Label is: The format of a Generalized Label is:
skipping to change at page 5, line 45 skipping to change at page 5, line 29
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (16)| C-Type (2) | | Length | Class-Num (16)| C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | | Label |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of parameters and encoding of See [GMPLS-SIG] for a description of parameters and encoding of
SDH, SONET, port, wavelength and other labels. labels.
2.2.1. Procedures 2.2.1. Procedures
The Generalized Label travels in the upstream direction in Resv The Generalized Label travels in the upstream direction in Resv
messages. messages.
The presence of both a generalized and normal label object in a Resv The presence of both a generalized and normal label object in a Resv
message is a protocol error and should treated as a malformed message message is a protocol error and should treated as a malformed message
by the recipient. by the recipient.
skipping to change at page 7, line 22 skipping to change at page 7, line 9
the egress LSRs will not know that an input wavelength of say L1 will the egress LSRs will not know that an input wavelength of say L1 will
emerge from the waveband tunnel as L100. emerge from the waveband tunnel as L100.
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 is identical to a generalized label.
It is used in Path messages. Suggested Label uses a new Class-Number It is used in Path messages. Suggested Label uses a new Class-Number
(TBD of form 10bbbbbb) and the C-type of the label being suggested. (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 Labels MUST be ignored. This includes
any received inconsistent or unacceptable values. any received inconsistent or unacceptable values.
2.5. Label Set 2.5. Label Set
The Label_Set object uses a Class-Number TBA (of form 0bbbbbbb) and The Label_Set object uses a Class-Number TBA (of form 0bbbbbbb) and
the C-type of the label type being described. the C-type of 1.
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Label Type | Action | | Reserved | Label Type | Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 46 skipping to change at page 8, line 19
Action zero (0) and one (1) objects respectively. Ranges of Action zero (0) and one (1) objects respectively. Ranges of
labels/subchannels can be added to or excluded from a Label Set via labels/subchannels can be added to or excluded from a Label Set via
Action two (2) and three (3) objects respectively. When the Action two (2) and three (3) objects respectively. When the
Label_Set objects only list labels/subchannels to exclude, this Label_Set objects only list labels/subchannels to exclude, this
implies that all other labels are acceptable. implies that all other labels are acceptable.
The absence of any Label_Set objects implies that all labels are The absence of any Label_Set objects implies that all labels are
acceptable. A Label Set is included when a node wishes to restrict acceptable. A Label Set is included when a node wishes to restrict
the label(s) that may be used downstream. the label(s) that may be used downstream.
On reception of a Path message a CI-capable interface will restrict On reception of a Path message, the receiving node will restrict its
its choice of labels to one which is in the Label Set. The CI- choice of labels to one which is in the Label Set. Nodes capable of
capable receiver may also remove the Label Set prior to forwarding performing label conversion may also remove the Label Set prior to
the Path message. If the node is unable to pick a label from the forwarding the Path message. If the node is unable to pick a label
Label Set or if there is a problem parsing the Label_Set objects, from the Label Set or if there is a problem parsing the Label_Set
then the request is terminated and a PathErr message with a "Routing objects, then the request is terminated and a PathErr message with a
problem/Label Set" indication MUST be generated. It is a local matter "Routing problem/Label Set" indication MUST be generated. It is a
if the Label Set is stored for later selection on the Resv or if the local matter if the Label Set is stored for later selection on the
selection is made immediately for propagation in the Resv. Resv or if the selection is made immediately for propagation in the
Resv.
On reception of a Path message for a CI-incapable interface, the On reception of a Path message, the Label Set represented in the
Label Set represented in the message is compared against the set of message is compared against the set of available labels at the
available labels at the downstream interface and the resulting downstream interface and the resulting intersecting Label Set is
intersecting Label Set is forwarded in a Path message. When the forwarded in a Path message. When the resulting Label Set is empty,
resulting Label Set is empty, the Path must be terminated, and a the Path must be terminated, and a PathErr message, and a "Routing
PathErr message, and a "Routing problem/Label Set" indication MUST be problem/Label Set" indication MUST be generated. Note that
generated. Note that intersection is based on the physical labels intersection is based on the physical labels (actual wavelength/band
(actual wavelength/band values) which may have different logical values) which may have different logical values on different links,
values on different links, as a result it is the responsibility of as a result it is the responsibility of the node to map these values
the node to map these values so that they have a consistent physical so that they have a consistent physical meaning, or to drop the
meaning, or to drop the particular values from the set if no suitable particular values from the set if no suitable logical label value
logical label value exists. exists.
When processing a Resv message at an intermediate node, the label When processing a Resv message at an intermediate node, the label
propagated upstream MUST fall within the Label Set. propagated upstream MUST fall within the Label Set.
Note, on reception of a Resv message for an interface which is CI- Note, on reception of a Resv message a node that is incapable of
incapable it has no other choice than to use the same physical label performing label conversion has no other choice than to use the same
(wavelength/band) as received in the Resv. In this case, the use and physical label (wavelength/band) as received in the Resv message. In
propagation of a Label Set will significantly reduce the chances that this case, the use and propagation of a Label Set will significantly
this allocation will fail when CI-incapable nodes are traversed. 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 has the same format as
the generalized label, see Section 2.2. The Upstream Label uses the generalized label, see Section 2.2. The Upstream Label uses
Class-Number TBD (of form 0bbbbbbb) and the C-type of the label being Class-Number TBA (of form 0bbbbbbb) and the C-type of the label being
suggested. suggested.
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 is added to the Path
message. The Upstream Label MUST indicate a label that is valid for message. The Upstream Label MUST indicate a label that is valid for
forwarding at the time the Path message is sent. 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 is received, the
receiver first verifies that the upstream label is acceptable. If receiver first verifies that the upstream label is acceptable. If
the label is not acceptable, the receiver MUST issue a PathErr 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,
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
the associated labels. the associated labels.
3.2. Contention Resolution 3.2. Contention Resolution
There are two additional contention resolution related considerations There are two additional contention resolution related considerations
when controlling bidirectional LSPs setup via RSVP-TE. The first is when controlling bidirectional LSP setup via RSVP-TE. The first is
that for the purposes of RSVP contention resolution, the node ID is that for the purposes of RSVP contention resolution, the node ID is
the IP address used in the RSVP_HOP object. The second is that a the IP address used in the RSVP_HOP object. The second is that a
neighbor's node ID might not be known when sending an initial Path neighbor's node ID might not be known when sending an initial Path
message. When this case occurs, a node should suggest a label chosen message. When this case occurs, a node should suggest a label chosen
at random from the available label space. at random from the available label space.
4. Notification 4. Notification
This section defines three signaling extensions that modify error This section covers several notification related extensions. The
handling, enable expedited notification of failures and other events first extension defines the Acceptable Label Set object to support
to nodes responsible for restoring failed LSPs. The first extension, Notification on Label Error, per [GMPLS-SIG]. The second and third
the Notify Request object, identifies where event notifications are extensions enable expedited notification of failures and other events
to be sent. The second, the Notify message, provides for general to nodes responsible for restoring failed LSPs. (The second
event notification. The final extension allows for the removal of extension, the Notify Request object, identifies where event
Path state on handling of PathErr messages. notifications are to be sent. The third extension, the Notify
message, provides for general event notification.) The final
extension allows for the removal of Path state on handling of PathErr
messages.
4.1. Notify Request Objects 4.1. Acceptable Label Set Object
Acceptable_Label_Set objects use a Class-Number TBA (of form
11bbbbbb). The remaining contents of the object, including C-type,
have the identical format as the Label_Set object, see Section 2.5.
Acceptable_Label_Set objects may be carried in PathErr and ResvErr
messages. The procedures for defining an Acceptable Label Set follow
the procedures for defining a Label Set, see Section 2.5.1.
Specifically, an Acceptable Label Set is defined via one or more
Acceptable_Label_Set objects. Specific labels/subchannels can be
added to or excluded from an Acceptable Label Set via Action zero
(0) and one (1) objects respectively. Ranges of labels/subchannels
can be added to or excluded from an Acceptable Label Set via Action
two (2) and three (3) objects respectively. When the
Acceptable_Label_Set objects only list labels/subchannels to exclude,
this implies that all other labels are acceptable.
The inclusion of Acceptable_Label_Set objects is optional. If
included, the PathErr or ResvErr message SHOULD contain a "Routing
problem/Unacceptable label value" indication. The absence of
Acceptable_Label_Set objects does not have any specific meaning.
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.1.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 6. 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(TBD)| C-Type (1) | | Length | Class-Num(TBA)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Notify Node Address | | IPv4 Notify Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Notify Node Address: 32 bits IPv4 Notify Node Address: 32 bits
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.
o IPv6 Notify Request Object o IPv6 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(TBD)| C-Type (2) | | Length | Class-Num(TBA)| C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| 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.1.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
the inclusion of a Notify Request Object in the corresponding Resv the inclusion of a Notify Request Object in the corresponding Resv
message. message.
A node receiving a message containing a Notify Request object SHOULD A node receiving a message containing a Notify Request object SHOULD
store the Notify Node Address in the corresponding state block. If store the Notify Node Address in the corresponding state block. If
the node is a transit node, it SHOULD also included a Notify Request the node is a transit node, it SHOULD also included a Notify Request
object in the outgoing Path or Resv message. The outgoing Notify object in the outgoing Path or Resv message. The outgoing Notify
Node Address MAY be updated based on local policy. Node Address MAY be updated based on local policy.
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.2. 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 only generated after a
Notify Request object has been received. The Notify message differs Notify Request object has been received. The Notify message differs
from the currently defined error messages (i.e., PathErr and ResvErr from the currently defined error messages (i.e., PathErr and ResvErr
messages of RSVP) in that it can be "targeted" to a node other than messages) in that it can be "targeted" to a node other than the
the immediate upstream or downstream neighbor and that it is a 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
[RSVP-RR] is used to acknowledge the receipt of a Notify Message. [RSVP-RR] is used to acknowledge the receipt of a Notify Message.
See [RSVP-RR] for details on reliable RSVP message delivery. See [RSVP-RR] for details on reliable RSVP message delivery.
4.2.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.
<Notify message> ::= <Common Header> [<INTEGRITY>] <MESSAGE_ID> The Notify message has a Msg Type of TBA (by IANA). The Notify
message format is as follows:
<Notify message> ::= <Common Header> [<INTEGRITY>]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <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>
<downstream notify session> ::= <SESSION> [<POLICY_DATA>...] <upstream notify session> ::= <SESSION> [<POLICY_DATA>...]
<sender descriptor> <sender descriptor>
<upstream notify session> ::= <SESSION> [<POLICY_DATA>...] <downstream notify session> ::= <SESSION> [<POLICY_DATA>...]
<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 failed. See ERROR_SPEC definition in [RFC2205]. The MESSAGE_ID and
object is defined in [RSVP-RR]. related objects are defined in [RSVP-RR] and are used when refresh
reductions is supported.
4.2.2. Procedures 4.3.2. Procedures
Notify messages are generated at nodes that detect an error that will Notify messages are generated at nodes that detect an error that will
trigger the generation of a PathErr or ResvErr message. If a PathErr trigger the generation of a PathErr or ResvErr message. If a PathErr
message is to be generated and a Notify Request object has been message is to be generated and a Notify Request object has been
received in the corresponding Path message, then a Notify message received in the corresponding Path message, then a Notify message
destined to the recorded node SHOULD be generated. If a ResvErr destined to the recorded node SHOULD be generated. If a ResvErr
message is to be generated and a Notify Request object has been message is to be generated and a Notify Request object has been
received in the corresponding Resv message, then a Notify message received in the corresponding Resv message, then a Notify message
destined to the recorded node SHOULD be generated. As previously destined to the recorded node SHOULD be generated. As previously
mentioned, a single error may generate a Notify message in both the mentioned, a single error may generate a Notify message in both the
upstream and downstream directions. Note a Notify message MUST NOT upstream and downstream directions. Note that a Notify message MUST
be generated unless an appropriate Notify Request object has been NOT be generated unless an appropriate Notify Request object has been
received. 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
messages SHOULD be delivered using the reliable message delivery messages SHOULD be delivered using the reliable message delivery
mechanisms defined in [RSVP-RR]. mechanisms defined in [RSVP-RR].
Upon receiving a Notify message, the Notify Node SHOULD send a Upon receiving a Notify message, the Notify Node SHOULD send a
corresponding Ack message. corresponding Ack message.
4.3. Removing State with a PathErr message 4.4. Removing State with a PathErr message
The PathErr message as defined in [RFC2205] is sent hop-by-hop to the The PathErr message as defined in [RFC2205] is sent hop-by-hop to the
source of the associated Path message. Intermediate nodes may source of the associated Path message. Intermediate nodes may
inspect this message, but take no action upon it. In an environment inspect this message, but take no action upon it. In an environment
where Path messages are routed according to an IGP and that route may where Path messages are routed according to an IGP and that route may
change dynamically, this behavior is a fine design choice. change dynamically, this behavior is a fine design choice.
However, when RSVP is used with explicit routes, it is often the case However, when RSVP is used with explicit routes, it is often the case
that errors can only be corrected at the source node or some other that errors can only be corrected at the source node or some other
node further upstream. In order to clean up resources, the source node further upstream. In order to clean up resources, the source
must receive the PathErr and then either send a PathTear (or wait for must receive the PathErr and then either send a PathTear (or wait for
the messages to timeout). This causes idle resources to be held the messages to timeout). This causes idle resources to be held
longer than necessary increases control message load. In a situation longer than necessary and increases control message load. In a
where the control plane is attempting to recover from a serious situation where the control plane is attempting to recover from a
outage, both the message load and the delay in freeing resources serious outage, both the message load and the delay in freeing
hamper the ability to rapidly reconverge. resources hamper the ability to rapidly reconverge.
The situation can be greatly improved by allowing state to be removed The situation can be greatly improved by allowing state to be removed
by intermediate nodes on certain error conditions. To facilitate by intermediate nodes on certain error conditions. To facilitate
this a new flag is defined in the ERROR_SPEC object. The two this a new flag is defined in the ERROR_SPEC object. The two
currently defined ERROR_SPEC objects (IPv4 and IPv6 error spec currently defined ERROR_SPEC objects (IPv4 and IPv6 error spec
objects) each contain a one byte flag field. Within that field two objects) each contain a one byte flag field. Within that field two
flags are defined. This specification defines a third flag, 0x04, flags are defined. This specification defines a third flag, 0x04,
Path_State_Removed. Path_State_Removed.
The semantics of the Path_State_Removed flag are simply that the node The semantics of the Path_State_Removed flag are simply that the node
skipping to change at page 16, line 37 skipping to change at page 17, line 11
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.
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 a Class-Number TBA (of form 0bbbbbbb). Object uses a Class-Number TBA (of form 0bbbbbbb).
The format of Protection Flags Object is: The format of Protection Information 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Link Flags| |S| Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of parameters. See [GMPLS-SIG] for a description of parameters.
skipping to change at page 17, line 18 skipping to change at page 17, line 36
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. RSVP Message Formats 7. RSVP Message Formats
This section presents the RSVP message related formats as modified by This section presents the RSVP message related formats as modified by
this document. Where they differ, formats for unidirectional LSPs this document. Where they differ, formats for unidirectional LSPs
are presented separately from bidirectional LSPs. Unmodified formats are presented separately from bidirectional LSPs. Unmodified formats
are not listed. are not listed. Again, MESSAGE_ID and related objects are defined in
[RSVP-RR].
The format of a Path message is as follows: The format of a Path message is as follows:
<Path Message> ::= <Common Header> [ <INTEGRITY> ] <Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<TIME_VALUES> <TIME_VALUES>
[ <EXPLICIT_ROUTE> ] [ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST> <LABEL_REQUEST>
[ <PROTECTION> ] [ <PROTECTION> ]
[ <LABEL_SET> ... ] [ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ] [ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ] [ <NOTIFY_REQUEST> ]
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
<sender descriptor> <sender descriptor>
skipping to change at page 18, line 4 skipping to change at page 18, line 35
[ <RECORD_ROUTE> ] [ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ] [ <SUGGESTED_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> ]
<UPSTREAM_LABEL> <UPSTREAM_LABEL>
The format of a PathErr message is as follows:
<PathErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <ERROR_SPEC>
[ <ACCEPTABLE_LABEL_SET> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>
The format of a Resv message is as follows: The format of a Resv message is as follows:
<Resv Message> ::= <Common Header> [ <INTEGRITY> ] <Resv Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<TIME_VALUES> <TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ] [ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <NOTIFY_REQUEST> ] [ <NOTIFY_REQUEST> ]
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list> <STYLE> <flow descriptor list>
<flow descriptor list> is not modified by this document. <flow descriptor list> is not modified by this document.
The format of a Resv message is as follows:
<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<ERROR_SPEC> [ <SCOPE> ]
[ <ACCEPTABLE_LABEL_SET> ... ]
[ <POLICY_DATA> ... ]
<STYLE> <error flow descriptor>
8. Acknowledgments 8. 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
skipping to change at page 18, line 40 skipping to change at page 20, line 14
9. Security Considerations 9. Security Considerations
The transmission of notify messages using IP in IP, break RSVP's hop- The transmission of notify messages using IP in IP, break RSVP's hop-
by-hop integrity and authentication model. Fortunately, such usage by-hop integrity and authentication model. Fortunately, such usage
mirrors the IP end-to-end model. In the case where RSVP is 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 introduce no other new security considerations to [RSVP- This draft introduces no other new security considerations to [RSVP-
TE]. TE].
10. References 10. References
[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-00.txt, July 2000. draft-ietf-mpls-lsp-hierarchy-02.txt, Feb., 2001.
[MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links
in RSVP-TE", Internet Draft,
draft-ietf-mpls-rsvp-unnum-01.txt, February 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.
skipping to change at page 22, line 4 skipping to change at page 23, line 26
Phone: +1 408 895 5030 Phone: +1 408 895 5030
Fax: +1 408 895 5050 Fax: +1 408 895 5050
Email: vsharma@jasminenetworks.com 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 Mar 2 14:07:37 EST 2001 Generated on: Mon Apr 16 19:44:44 EDT 2001
 End of changes. 

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