draft-ietf-mpls-generalized-rsvp-te-06.txt   draft-ietf-mpls-generalized-rsvp-te-07.txt 
Network Working Group Peter Ashwood-Smith (Nortel Networks Corp.) Network Working Group Lou Berger - Editor (Movaz Networks)
Internet Draft Ayan Banerjee (Calient Networks) Internet Draft Peter Ashwood-Smith (Nortel Networks)
Expiration Date: May 2002 Lou Berger (Movaz Networks) Expiration Date: October 2002 Ayan Banerjee (Calient 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)
Jonathan P. Lang (Calient Networks) Jonathan P. Lang (Calient Networks)
Fong Liaw (Zaffire Inc.) Fong Liaw (Solas Research)
Eric Mannie (EBONE) Eric Mannie (KPNQwest)
Ping Pan (Juniper Networks, Inc.) Ping Pan (Juniper Networks, Inc.)
Bala Rajagopalan (Tellium, Inc.) Bala Rajagopalan (Tellium)
Yakov Rekhter (Juniper Networks, Inc.) Yakov Rekhter (Juniper Networks)
Debanjan Saha (Tellium, Inc.) Debanjan Saha (Tellium)
Vishal Sharma (Metanoia, Inc.) Vishal Sharma (Metanoia)
George Swallow (Cisco Systems) George Swallow (Cisco Systems)
Z. Bo Tang (Tellium, Inc.) Z. Bo Tang (Tellium)
November 2001 April 2002
Generalized MPLS Signaling - RSVP-TE Extensions Generalized MPLS Signaling - RSVP-TE Extensions
draft-ietf-mpls-generalized-rsvp-te-06.txt draft-ietf-mpls-generalized-rsvp-te-07.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 1, line 47 skipping to change at page 1, line 47
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To view the current status of any Internet-Draft, please check the To view the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
Directory, see http://www.ietf.org/shadow.html. Directory, see http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes extensions to RSVP-TE signaling required to This document describes extensions to 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/SDH 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 generic functional description and a CR-LDP
[GMPLS-LDP]. A generic functional description is presented in specific description can be found in separate documents.
[GMPLS-SIG].
Contents Contents
1 Introduction ................................................ 4 1 Introduction ................................................ 3
2 Label Related Formats ...................................... 4 2 Label Related Formats ...................................... 3
2.1 Generalized Label Request Object ............................ 4 2.1 Generalized Label Request Object ............................ 3
2.2 Generalized Label Object .................................... 6 2.2 Generalized Label Object .................................... 5
2.3 Waveband Switching .......................................... 7 2.3 Waveband Switching .......................................... 6
2.4 Suggested Label ............................................. 8 2.4 Suggested Label ............................................. 7
2.5 Label Set ................................................... 8 2.5 Label Set ................................................... 7
3 Bidirectional LSPs .......................................... 10 3 Bidirectional LSPs .......................................... 9
3.1 Procedures .................................................. 10 3.1 Procedures .................................................. 9
3.2 Contention Resolution ....................................... 11 3.2 Contention Resolution ....................................... 10
4 Notification ................................................ 11 4 Notification ................................................ 10
4.1 Acceptable Label Set Object ................................. 11 4.1 Acceptable Label Set Object ................................. 10
4.2 Notify Request Objects ...................................... 12 4.2 Notify Request Objects ...................................... 11
4.3 Notify Message .............................................. 13 4.3 Notify Message .............................................. 12
4.4 Removing State with a PathErr message ....................... 15 4.4 Removing State with a PathErr message ....................... 14
5 Explicit Label Control ...................................... 16 5 Explicit Label Control ...................................... 15
5.1 Label ERO subobject ......................................... 16 5.1 Label ERO subobject ......................................... 15
5.2 Label RRO subobject ......................................... 18 5.2 Label RRO subobject ......................................... 17
6 Protection Object ........................................... 19 6 Protection Object ........................................... 18
6.1 Procedures .................................................. 19 6.1 Procedures .................................................. 18
7 Administrative Status Information ........................... 19 7 Administrative Status Information ........................... 18
7.1 Admin Status Object ......................................... 19 7.1 Admin Status Object ......................................... 18
7.2 Path and Resv Message Procedures ............................ 20 7.2 Path and Resv Message Procedures ............................ 19
7.3 Notify Message Procedures ................................... 22 7.3 Notify Message Procedures ................................... 21
8 Control Channel Separation .................................. 23 8 Control Channel Separation .................................. 22
8.1 Interface Identification .................................... 23 8.1 Interface Identification .................................... 22
8.2 Errored Interface Identification ............................ 25 8.2 Errored Interface Identification ............................ 24
9 Fault Handling .............................................. 26 9 Fault Handling .............................................. 25
9.1 Restart_Cap Object .......................................... 27 9.1 Restart_Cap Object .......................................... 26
9.2 Processing of Restart_Cap Object ............................ 27 9.2 Processing of Restart_Cap Object ............................ 27
9.3 Modification to Hello Processing to Support State Recovery .. 28 9.3 Modification to Hello Processing to Support State Recovery .. 27
9.4 Control Channel Faults ...................................... 29 9.4 Control Channel Faults ...................................... 28
9.5 Nodal Faults ................................................ 29 9.5 Nodal Faults ................................................ 28
10 RSVP Message Formats and Handling ........................... 32 10 RSVP Message Formats and Handling ........................... 31
10.1 RSVP Message Formats ........................................ 32 10.1 RSVP Message Formats ........................................ 31
10.2 Addressing Path and PathTear Messages ...................... 33
10.2 Addressing Path and PathTear Messages ...................... 34 11 Acknowledgments ............................................. 33
11 Acknowledgments ............................................. 34 12 Security Considerations ..................................... 33
12 Security Considerations ..................................... 34 13 IANA Considerations ......................................... 34
13 IANA Considerations ......................................... 35 13.1 IANA [Suggestions /] Assignments ............................ 35
14 References .................................................. 36 14 References .................................................. 36
15 Authors' Addresses .......................................... 37 14.1 Normative References ........................................ 37
14.2 Informative References ...................................... 37
15 Authors' Addresses .......................................... 38
[Editor's note: changes to be removed prior to publication as an RFC.] [Editor's note: changes to be removed prior to publication as an RFC.]
Changes from previous version: Changes from previous version:
o Reorder author's list to indicate primary contact
o Fixed indication of infinite restart time
o Added IANA [Suggestions /] Assignments Section
o Split references section
o Minor editorial changes and clarifications 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
skipping to change at page 5, line 4 skipping to change at page 3, line 47
This section defines formats for a generalized label request, a This section defines formats for a generalized label request, a
generalized label, support for waveband switching, suggested label generalized label, support for waveband switching, suggested label
and label sets. and label sets.
2.1. Generalized Label Request Object 2.1. Generalized Label Request Object
A Path message SHOULD contain as specific an LSP Encoding Type as A Path message SHOULD contain as specific an LSP Encoding Type as
possible to allow the maximum flexibility in switching by transit possible to allow the maximum flexibility in switching by transit
LSRs. A Generalized Label Request object is set by the ingress node, LSRs. A Generalized Label Request object is set by the ingress node,
transparently passed by transit nodes, and used by the egress node. transparently passed by transit nodes, and used by the egress node.
The Switching Type field may also be updated hop-by-hop.
The format of a Generalized Label Request object is: The format of a Generalized Label Request object is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (19)|C-Type (4)[TBA]| | Length | Class-Num (19)|C-Type (4)[TBA]|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | G-PID | | LSP Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 10 skipping to change at page 6, line 10
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. Waveband Label uses C-Type (3),
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Waveband Id | | Waveband Id |
skipping to change at page 10, line 40 skipping to change at page 9, line 40
If 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/MPLS 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
skipping to change at page 13, line 43 skipping to change at page 12, line 43
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. [RFC2961] is used to acknowledge the receipt of a Notify Message.
See [RSVP-RR] for details on reliable RSVP message delivery. See [RFC2961] for details on reliable RSVP message delivery.
4.3.1. Required Information 4.3.1. Required Information
The Notify message is a generalized notification message. The IP The Notify message is a generalized notification message. The IP
destination address is set to the IP address of the intended destination address is set to the IP address of the intended
receiver. The Notify message is sent without the router alert receiver. The Notify message is sent without the router alert
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.
skipping to change at page 14, line 31 skipping to change at page 13, line 31
<notify session list> ::= [ <notify session list> ] <notify session list> ::= [ <notify session list> ]
<upstream notify session> | <upstream notify session> |
<downstream notify session> <downstream notify session>
<upstream notify session> ::= <SESSION> [ <ADMIN_STATUS> ] <upstream notify session> ::= <SESSION> [ <ADMIN_STATUS> ]
[<POLICY_DATA>...] [<POLICY_DATA>...]
<sender descriptor> <sender descriptor>
<downstream notify session> ::= <SESSION> [<POLICY_DATA>...] <downstream notify session> ::= <SESSION> [<POLICY_DATA>...]
<flow descriptor list descriptor> <flow descriptor list>
The ERROR_SPEC object specifies the error and includes the IP address The ERROR_SPEC object specifies the error and includes the IP address
of either the node that detected the error or the link that has of either the node that detected the error or the link that has
failed. See ERROR_SPEC definition in [RFC2205]. The MESSAGE_ID and failed. See ERROR_SPEC definition in [RFC2205]. The MESSAGE_ID and
related objects are defined in [RSVP-RR] and are used when refresh related objects are defined in [RFC2961] and are used when refresh
reductions is supported. reductions is supported.
4.3.2. Procedures 4.3.2. Procedures
Notify messages are most commonly generated at nodes that detect an Notify messages are most commonly generated at nodes that detect an
error that will trigger the generation of a PathErr or ResvErr error that will trigger the generation of a PathErr or ResvErr
message. If a PathErr message is to be generated and a Notify message. If a PathErr message is to be generated and a Notify
Request object has been received in the corresponding Path message, Request object has been received in the corresponding Path message,
then a Notify message destined to the recorded node SHOULD be then a Notify message destined to the recorded node SHOULD be
generated. If a ResvErr message is to be generated and a Notify generated. If a ResvErr message is to be generated and a Notify
skipping to change at page 15, line 16 skipping to change at page 14, line 16
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 [RFC2961].
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.4. 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
skipping to change at page 16, line 23 skipping to change at page 15, line 23
an error with the Path_State_Removed flag set to zero MUST NOT set an error with the Path_State_Removed flag set to zero MUST NOT set
this flag unless it also generates a corresponding PathTear message. this flag unless it also generates a corresponding PathTear message.
Note that the use of this flag does not result in any Note that the use of this flag does not result in any
interoperability incompatibilities. interoperability incompatibilities.
5. Explicit Label Control 5. Explicit Label Control
The Label ERO and RRO subobjects are defined to support Explicit The Label ERO and RRO subobjects are defined to support Explicit
Label Control. Note that the Label RRO subobject was defined in Label Control. Note that the Label RRO subobject was defined in
[RSVP-TE] and is being revised to support bidirectional LSPs. [RFC3209] and is being revised to support bidirectional LSPs.
5.1. Label ERO subobject 5.1. Label ERO subobject
The Label ERO subobject is defined as follows: The Label ERO subobject is defined as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length |U| Reserved | C-Type | |L| Type | Length |U| Reserved | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 18, line 32 skipping to change at page 17, line 32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of U and Label parameters. See [GMPLS-SIG] for a description of U and Label parameters.
Type Type
3 Label 3 Label
Length Length
See [RSVP-TE]. See [RFC3209].
Flags Flags
See [RSVP-TE]. See [RFC3209].
C-Type C-Type
The C-Type of the included Label Object. Copied from the Label The C-Type of the included Label Object. Copied from the Label
Object. Object.
5.2.1. Procedures 5.2.1. Procedures
Label RRO subobjects are included in RROs as described in [RSVP-TE]. Label RRO subobjects are included in RROs as described in [RFC3209].
The only modification to usage and processing from [RSVP-TE] is that The only modification to usage and processing from [RFC3209] is that
when labels are recorded for bidirectional LSPs, label ERO subobjects when labels are recorded for bidirectional LSPs, label ERO subobjects
for both downstream and upstream labels MUST be included. for both downstream and upstream labels MUST be included.
6. Protection Object 6. Protection Object
The use of the Protection Object is optional. The object is included The use of the Protection Object is optional. The object is included
to indicate specific protection attributes of an LSP. The Protection to indicate specific protection attributes of an LSP. The Protection
Object uses Class-Number TBA (of form 0bbbbbbb). Object uses Class-Number TBA (of form 0bbbbbbb).
The format of the Protection Object is: The format of the Protection Object is:
skipping to change at page 23, line 18 skipping to change at page 22, line 18
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, see [MPLS-BUNDLE], the in each direction. In all cases but bundling, the upstream interface
upstream interface is implied by the downstream interface. For is implied by the downstream interface. For bundling, the path
bundling, the path sender explicitly identifies the component sender explicitly identifies the component interface used in each
interface used in each direction. The new RSVP_HOP object is used in direction. The new RSVP_HOP object is used in Resv message to
Resv message to indicate the downstream node's usage of the indicated 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:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (3) | C-Type (3)TBA | | Length | Class-Num (3) | C-Type (3)TBA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 27, line 29 skipping to change at page 26, line 29
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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. A value of
0xffffffff indicates that the restart of the sender's control
plane may occur over an indeterminate interval and that the
operation of its data plane is unaffected by control plane
failures. The method used to ensure continued data plane
operation is outside the scope of this document.
Recovery Time: 32 bits Recovery Time: 32 bits
The period of time, in milliseconds, that the sender desires The period of time, in milliseconds, that the sender desires
for the recipient to resyncronize RSVP and MPLS forwarding for the recipient to re-synchronize 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
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 advertise this capability by carrying Nodes supporting state recovery advertise this capability by carrying
the Restart_Cap object in Hello messages. Such nodes MUST include the Restart_Cap object in Hello messages. Such nodes MUST include
the Restart_Cap object in all Hello messages. (Note that this the Restart_Cap object in all Hello messages. (Note that this
includes Hello messages containing ACK objects.) Usage of the includes Hello messages containing ACK objects.) Usage of the
special case Recovery Time values is described in greater detail special case Recovery Time values is described in greater detail
below. below.
skipping to change at page 28, line 27 skipping to change at page 27, line 38
unchanged. While waiting, the node SHOULD also preserve the RSVP and unchanged. While waiting, the node SHOULD also preserve the RSVP and
MPLS forwarding state for (already) established LSPs that traverse MPLS forwarding state for (already) established LSPs that traverse
the link(s) between the node and the neighbor. In a sense with the link(s) between the node and the neighbor. In a sense with
respect to established LSPs the node behaves as if it continues to respect to established LSPs the node behaves as if it continues to
receive periodic RSVP refresh messages from the neighbor. The node receive periodic RSVP refresh messages from the neighbor. The node
MAY clear RSVP and forwarding state for the LSPs that are in the MAY clear RSVP and forwarding state for the LSPs that are in the
process of being established when their refresh timers expire. process of being established when their refresh timers expire.
Refreshing of Resv and Path state SHOULD be suppressed during this Refreshing of Resv and Path state SHOULD be suppressed during this
waiting period. waiting period.
During this waiting period, the node MAY inform other nodes of the During this waiting period, the node MAY inform upstream nodes of the
communication loss via a PathErr and/or upstream Notify message with communication loss via a PathErr and/or upstream Notify message with
"Control Channel Degraded State" indication. If such notification "Control Channel Degraded State" indication. If such notification
has been sent, then upon restoration of the control channel the node has been sent, then upon restoration of the control channel the node
MUST inform other nodes of the restoration via a PathErr and/or MUST inform other nodes of the restoration via a PathErr and/or
upstream Notify message with "Control Channel Active State" upstream Notify message with "Control Channel Active State"
indication. (Specific error codes are to be assigned IANA.) indication. (Specific error codes are to be assigned IANA.)
When a new Hello message is received from the neighbor, the node must When a new Hello message is received from the neighbor, the node must
determine if the fault was limited to the control channel or was a determine if the fault was limited to the control channel or was a
nodal fault. This determination is based on the Src_Instance nodal fault. This determination is based on the Src_Instance
received from the neighbor. If the value is different than the value received from the neighbor. If the value is different than the value
that was received from the neighbor prior to the fault, then the that was received from the neighbor prior to the fault, then the
neighbor should be treated as if it has restarted. Otherwise, the neighbor should be treated as if it has restarted. Otherwise, the
the fault was limited control channel. Procedures for handling each the fault was limited control channel. Procedures for handling each
case are described below. case are described below.
9.4. Control Channel Faults 9.4. Control Channel Faults
In the case of control channel faults, the node 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 [RFC2961] 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 uses one new object and other existing Recovering from nodal faults uses one new object and other existing
protocol messages and objects. protocol messages and objects.
skipping to change at page 29, line 41 skipping to change at page 28, line 43
was preserved, then the node MUST set the Recovery Time to 0 in the was preserved, then the node MUST set the Recovery Time to 0 in the
Hello message the node sends to its neighbors. Hello message the node sends to its neighbors.
If the forwarding state was preserved, then the node initiates the If the forwarding state was preserved, then the node initiates the
state recovery process. The period during which a node is prepared state recovery process. The period during which a node is prepared
to support the recovery process is referred to as the Recovery to support the recovery process is referred to as the Recovery
Period. The total duration of the Recovery Period is advertised by Period. The total duration of the Recovery Period is advertised by
the recovering node in the Recovery Time parameter of the Restart_Cap the recovering node in the Recovery Time parameter of the Restart_Cap
object. The Recovery Time MUST be set to the duration of the object. The Recovery Time MUST be set to the duration of the
Recovery Period in all Hello messages sent during the Recovery Recovery Period in all Hello messages sent during the Recovery
Period. A Recovery Time value of 0xffffffff indicates that the Period. State that is not resynchronized during the Recovery Period
Recovery Period is effectively infinite. State that is not SHOULD be removed at the end of the Period.
resynchronized during the Recovery Period SHOULD be removed at the
end of the Period.
Note that if during Hello synchronization the restarting node Note that if during Hello synchronization the restarting node
determines that a neighbor does not support state recovery, and the determines that a neighbor does not support state recovery, and the
restarting node maintains its MPLS forwarding state on a per neighbor restarting node maintains its MPLS forwarding state on a per neighbor
basis, the restarting node should immediately consider the Recovery basis, the restarting node should immediately consider the Recovery
Period with that neighbor completed. Note forwarding state can be Period with that neighbor completed. Forwarding state may be
considered to be maintained on a per neighbor basis when per 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 a node receives a Path message during the Recovery Period, the When a node receives a Path message during the Recovery Period, the
node first checks if it has an RSVP state associated with the node first checks if it has an RSVP state associated with the
message. If the state is found, then the node handles this message message. If the state is found, then the node handles this message
according to 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
Recovery_Label object, the node treats this as a setup for a new LSP, Recovery_Label object, the node treats this as a setup for a new LSP,
skipping to change at page 31, line 5 skipping to change at page 30, line 7
label is equal to the label carried in the object (in the case of label is equal to the label carried in the object (in the case of
link bundling, this may also involved first identifying the link bundling, this may also involved first identifying the
appropriate incoming component link). appropriate incoming component link).
If the MPLS forwarding table entry is not found, the node 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 should be the LSP associated with the Path message, and the entry should be
considered to be resyncronized. In addition, if the node is not the considered to be re-synchronized. In addition, if the node is not
tail-end of the LSP, the corresponding outgoing Path messages is sent the tail-end of the LSP, the corresponding outgoing Path messages is
with the incoming label from that entry carried in the UPSTREAM_LABEL sent with the incoming label from that entry carried in the
object. 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 is that ResvErr messages SHOULD
is not 0xffffffff. In this case, ResvErr messages SHOULD NOT be 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 silently received. In this case the Resv message SHOULD just be silently
discarded. discarded.
9.5.3. Procedures for the Neighbor of a Restarting node 9.5.3. Procedures for the Neighbor of a Restarting node
The following specifies the procedures that apply when the node 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 node determines (using the procedures defined the Restart Time, the node determines (using the procedures defined
in Section 5 of [RSVP-TE]) that the neighbor's control plane has in Section 5 of [RFC3209]) that the neighbor's control plane has
restarted, and the neighbor was able to preserve its forwarding state restarted, and the neighbor was able to preserve its forwarding state
across the restart (as was indicated by a non-zero Recovery Time across the restart (as was indicated by a non-zero Recovery Time
carried in the Restart_Cap object of the RSVP Hello messages received carried in the Restart_Cap object of the RSVP Hello messages received
from the neighbor). from the neighbor). Note, a Restart Time value of 0xffffffff
indicates an infinite Restart Time interval.
Upon detecting a restart with a neighbor that supports state Upon detecting a restart with a neighbor that supports state
recovery, a node SHOULD refresh all Path state shared with that recovery, a node SHOULD refresh all Path state shared with that
neighbor. The outgoing Path messages MUST include the Recovery_Label neighbor. The outgoing Path messages MUST include the Recovery_Label
object containing the label value received in the most recently object containing the label value received in the most recently
received corresponding Resv message. All Path state SHOULD be received corresponding Resv message. All Path state SHOULD be
refreshed within approximately 1/2 of the Recovery time advertised by refreshed within approximately 1/2 of the Recovery time advertised by
the restarted neighbor. If there are many LSP's going through the the restarted neighbor. If there are many LSP's going through the
restarting node, the neighbor node should avoid sending Path messages restarting node, the neighbor node should avoid sending Path messages
in a short time interval, as to avoid unnecessary stressing the in a short time interval, as to avoid unnecessary stressing the
skipping to change at page 32, line 16 skipping to change at page 31, line 16
This message summarizes RSVP message formats and handling as modified This message summarizes RSVP message formats and handling as modified
by GMPLS. by GMPLS.
10.1. RSVP Message Formats 10.1. RSVP Message Formats
This section presents the RSVP message related formats as modified by This section presents the RSVP message related formats as modified by
this document. Where they differ, formats for unidirectional LSPs this document. Where they differ, formats for unidirectional LSPs
are presented separately from bidirectional LSPs. Unmodified formats are presented separately from bidirectional LSPs. Unmodified formats
are not listed. Again, MESSAGE_ID and related objects are defined in are not listed. Again, MESSAGE_ID and related objects are defined in
[RSVP-RR]. [RFC2961].
The format of a Path message is as follows: The format of a Path message is as follows:
<Path Message> ::= <Common Header> [ <INTEGRITY> ] <Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ] [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ] [ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<TIME_VALUES> <TIME_VALUES>
[ <EXPLICIT_ROUTE> ] [ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST> <LABEL_REQUEST>
skipping to change at page 34, line 46 skipping to change at page 33, line 46
Portions of Section 4 are based on suggestions and text proposed by Portions of Section 4 are based on suggestions and text proposed by
Adrian Farrel. Adrian Farrel.
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 MUST be used.
This draft introduces no other new security considerations to [RSVP- This draft introduces no other new security considerations to
TE]. [RFC3209].
13. IANA Considerations 13. IANA Considerations
IANA assigns values to RSVP protocol parameters. Within the current IANA assigns values to RSVP protocol parameters. Within the current
document multiple objects are defined. Each of these objects contain document multiple objects are defined. Each of these objects contain
C-Types. This section defines the rules for the assignment of the C-Types. This section defines the rules for the assignment of the
related C-Type values. This section uses the terminology of BCP 26 related C-Type values. This section uses the terminology of BCP 26
"Guidelines for Writing an IANA Considerations Section in RFCs" "Guidelines for Writing an IANA Considerations Section in RFCs"
[BCP26]. [BCP26].
As per [RFC2205], C-Type is an 8-bit number that identifies the As per [RFC2205], C-Type is an 8-bit number that identifies the
function of an object. There are no range restrictions. All function of an object. There are no range restrictions. All
possible values except zero are available for assignment. possible values except zero are available for assignment.
The assignment of C-Type values of the objects defined in this The assignment of C-Type values of the objects defined in this
document fall into three categories. The first category inherit C- document fall into three categories. The first category inherit C-
Types from the Label object, i.e., object class number 16 [RSVP-TE]. Types from the Label object, i.e., object class number 16 [RFC3209].
IANA is requested to institute a policy whereby all C-Type values IANA is requested to institute a policy whereby all C-Type values
assign for the Label object are also assigned for the following assign for the Label object are also assigned for the following
objects: objects:
o Suggested_Label (Class-Num TBA) o Suggested_Label (Class-Num TBA)
o Upstream_Label (Class-Num TBA) o Upstream_Label (Class-Num TBA)
o Recovery_Label (Class-Num TBA) o Recovery_Label (Class-Num TBA)
The second category of objects follow independent policies. The second category of objects follow independent policies.
Specifically, following the policies outlined in [BCP26], C-Type Specifically, following the policies outlined in [BCP26], C-Type
values in the range 0x00 - 0x3F are allocated through an IETF values in the range 0x00 - 0x3F are allocated through an IETF
skipping to change at page 36, line 5 skipping to change at page 35, line 5
o Protection (Class-Num TBA) o Protection (Class-Num TBA)
o Admin Status (Class-Num TBA) o Admin Status (Class-Num TBA)
o Restart_Cap (Class-Num TBA) o Restart_Cap (Class-Num TBA)
The assignment of C-Type values for the remaining object, the The assignment of C-Type values for the remaining object, the
Acceptable_Label_Set object, follows the assignment of C-Type values Acceptable_Label_Set object, follows the assignment of C-Type values
of the Label_Set object. IANA is requested to institute a policy of the Label_Set object. IANA is requested to institute a policy
whereby all C-Type values assigned for the Label_Set object are also whereby all C-Type values assigned for the Label_Set object are also
assigned for the Acceptable_Label_Set object. assigned for the Acceptable_Label_Set object.
13.1. IANA [Suggestions /] Assignments
[Note to RFC Editor:
Please drop all text enclosed in brackets in this section once
IANA assignments are made.
Editor's Note:
The values in this section were suggested to IANA for assignment
on March 11, 2002. No acknowledgment of the request has been
received. The values are included for reference purposes only
and should considered as unassigned.]
This section summarizes values used in this document that [will be /
] have been assigned by IANA.
---------------------------------------------------------------------
Message Types
o Notify message (suggested Message type =21)
---------------------------------------------------------------------
Class Types
o RSVP_HOP (Existing C-Num 3)
- IPv4 IF_ID RSVP_HOP (Suggested C-type =3)
- IPv6 IF_ID RSVP_HOP (Suggested C-type =4)
o ERROR_SPEC (Existing C-Num 6)
- IPv4 IF_ID ERROR_SPEC (Suggested C-type =3)
- IPv6 IF_ID ERROR_SPEC (Suggested C-type =4)
o LABEL_REQUEST (Existing Class-Num 19)
- Generalized_Label_Request (Suggested C-Type =4)
o RSVP_LABEL (Existing Class-Num 16)
- Generalized_Label (Suggested C-Type =2)
- Waveband_Switching_Label C-Type (Suggested C-Type =3)
---------------------------------------------------------------------
New Class-Nums, C-Types inherited from Label object (same as CNum16)
o RECOVERY_LABEL Class-Num of form 0bbbbbbb (suggested =34)
o SUGGESTED_LABEL Class-Num of form 10bbbbbb (suggested =129)
o UPSTREAM_LABEL Class-Num of form 0bbbbbbb (suggested =35)
---------------------------------------------------------------------
New Class-Nums
o LABEL_SET Class-Num of form 0bbbbbbb (suggested =36)
- Type 1 (C-Type =1)
o ACCEPTABLE_LABEL_SET Class-Num of form 10bbbbbb (suggested =130)
- Type 1 Acceptable_Label_Set (C-type from label_set cnum)
o NOTIFY_REQUEST Class-Num of form 11bbbbbb (suggested =195)
- IPv4 Notify Request (C-Type =1)
- IPv6 Notify Request (C-Type =2)
o PROTECTION Class-Num of form 0bbbbbbb (suggested =37)
- Type 1 (C-Type =1)
o ADMIN STATUS Class-Num of form 11bbbbbb (suggested =196)
- Type 1 (C-Type =1)
o RESTART_CAP Class-Num of form 10bbbbbb (suggested =131)
- Type 1 (C-Type =1)
---------------------------------------------------------------------
ERO/RRO subobject types
o Label ERO subobject
Type 3 - Label
o Label RRO subobject
Type 3 - Label
---------------------------------------------------------------------
Error codes
o "Routing problem/Label Set" (Suggested value =11)
o "Routing problem/Switching Type" (Suggested value =12)
(duplicate code 13 dropped)
o "Routing problem/Unsupported Encoding" (Suggested value =14)
o "Routing problem/Unsupported Link Protection" (Suggested value =15)
o "Notify Error/Control Channel Active State" (Suggested value =4)
o "Notify Error/Control Channel Degraded State" (Suggested value =5)
---------------------------------------------------------------------
14. References 14. References
14.1. Normative References
[MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links
in RSVP-TE", Internet Draft,
draft-ietf-mpls-rsvp-unnum-02.txt, August 2001
[GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS -
Signaling Functional Description", Internet Draft,
draft-ietf-mpls-generalized-signaling-08.txt,
April 2002.
[RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol
-- Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC2961] Berger, L. et al, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 2001
[RFC3209] Awduche, et al, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
14.2. Informative References
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[MPLS-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
in RSVP-TE", Internet Draft,
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-05.txt, draft-ietf-mpls-generalized-cr-ldp-06.txt,
November 2001. April 2002.
[GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS -
Signaling Functional Description", Internet Draft,
draft-ietf-mpls-generalized-signaling-07.txt,
November 2001.
[PAN-RESTART] Pan, P, et al, "Graceful Restart Mechanism for RSVP-TE", [PAN-RESTART] Pan, P, et al, "Graceful Restart Mechanism for RSVP-TE",
Internet Draft, draft-pan-rsvp-te-restart-01.txt, Internet Draft, draft-pan-rsvp-te-restart-01.txt,
July 2001. July 2001.
[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
-- Version 1 Functional Specification", RFC 2205,
September 1997.
[RSVP-TE] Awduche, D.O. et al, "RSVP-TE: Extensions to RSVP for LSP
Tunnels," Internet Draft,
draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, February 2001.
[RSVP-RR] Berger, L. et al, "RFC 2961: RSVP Refresh Overhead
Reduction Extensions", RFC2961.
15. 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
Calient Networks Calient Networks
5853 Rue Ferrari 5853 Rue Ferrari
San Jose, CA 95138 San Jose, CA 95138
Phone: +1 408 972-3645 Phone: +1 408 972-3645
Email: abanerjee@calient.net Email: abanerjee@calient.net
Lou Berger Lou Berger Editor & Primary Point of Contact
Movaz Networks, Inc. Movaz Networks, Inc.
7926 Jones Branch Drive 7926 Jones Branch Drive
Suite 615 Suite 615
McLean VA, 22102 McLean VA, 22102
Phone: +1 703 847-1801 Phone: +1 703 847-1801
Email: lberger@movaz.com Email: lberger@movaz.com
Greg Bernstein Greg Bernstein
Ciena Corporation Ciena Corporation
10480 Ridgeview Court 10480 Ridgeview Court
skipping to change at page 38, line 17 skipping to change at page 39, line 17
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
Email: jplang@calient.net Email: jplang@calient.net
Fong Liaw Fong Liaw
Zaffire Inc. Solas Research, LLC
2630 Orchard Parkway, Email: fongliaw@yahoo.com
San Jose, CA 95134
Email: fliaw@zaffire.com
Eric Mannie Eric Mannie
EBONE KPNQwest
Terhulpsesteenweg 6A Terhulpsesteenweg 6A
1560 Hoeilaart - Belgium 1560 Hoeilaart - Belgium
Phone: +32 2 658 56 52 Phone: +32 2 658 56 52
Mobile: +32 496 58 56 52 Mobile: +32 496 58 56 52
Fax: +32 2 658 51 18 Fax: +32 2 658 51 18
Email: eric.mannie@ebone.com Email: eric.mannie@kpnqwest.com
Ping Pan Ping Pan
Juniper Networks Juniper Networks
1194 N.Mathilda Ave 1194 N.Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: pingpan@juniper.net Email: pingpan@juniper.net
Bala Rajagopalan Bala Rajagopalan
Tellium, Inc. Tellium, Inc.
2 Crescent Place 2 Crescent Place
skipping to change at line 1664 skipping to change at line 1748
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: Wed Nov 21 15:26:44 EST 2001 Generated on: Thu Apr 25 12:57:53 2002
 End of changes. 

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