CANNOT be performed when the initial ERO subobject is not the
incoming interface.
8.2. Errored Interface Identification
There are cases where it is useful to indicate a specific interface
associated with an error. To support these cases the IF_ID
ERROR_SPEC Objects are defined.
8.2.1. IF_ID ERROR_SPEC Objects
The format of the IPv4 IF_ID ERROR_SPEC Object is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (6) | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Error Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the IPv6 IF_ID ERROR_SPEC Object is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (6) | C-Type (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Error Node Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC2205] for a description of address, flags, error code and
error value fields. See [RFC3471] for a description of parameters
and encoding of TLVs.
8.2.2. Procedures
Nodes wishing to indicate that an error is related to a specific
interface SHOULD use the appropriate IF_ID ERROR_SPEC Object in the
corresponding PathErr or ResvErr message. IF_ID ERROR_SPEC Objects
SHOULD be generated and processed as any other ERROR_SPEC Object, see
[RFC2205].
9. Fault Handling
The handling of two types of control communication faults is
described in this section. The first, referred to as nodal faults,
relates to the case where a node losses its control state (e.g.,
after a restart) but does not loose its data forwarding state. In
the second, referred to as control channel faults, relates to the
case where control communication is lost between two nodes. The
handling of both faults is supported by the Restart_Cap object
defined below and require the use of Hello messages.
Note, the Restart_Cap object MUST NOT be sent when there is no
mechanism to detect data channel failures independent of control
channel failures.
Please note this section is derived from [PAN-RESTART].
9.1. Restart_Cap Object
The Restart_Cap Object is carried in Hello messages.
The format of the Restart_Cap Object is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(131)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Restart Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recovery Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Restart Time: 32 bits
Restart Time is measured in milliseconds. Restart Time SHOULD 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 exchange
RSVP Hello with its neighbors) and the 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
The period of time, in milliseconds, that the sender desires for
the recipient to re-synchronize RSVP and MPLS forwarding state
with the sender after the re-establishment of Hello
synchronization. A value of zero (0) indicates that MPLS
forwarding state was not preserved across a particular reboot.
9.2. Processing of Restart_Cap Object
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 all Hello messages. (Note that this
includes Hello messages containing ACK objects.) Usage of the
special case Recovery Time values is described in greater detail
below.
When a node receives a Hello message with the Restart_Cap object, it
SHOULD record the values of the parameters received.
9.3. Modification to Hello Processing to Support State Recovery
When a node determines that RSVP communication with a neighbor has
been lost, and the node previously learned that the neighbor supports
state recovery, the node SHOULD wait at least the amount of time
indicated by the Restart Time indicated by the neighbor before
invoking procedures related to communication loss. A node MAY wait a
different amount of time based on local policy or configuration
information.
During this waiting period, all Hello messages MUST be sent with a
Dst_Instance value set to zero (0), and Src_Instance should be
unchanged. While waiting, the node SHOULD also preserve the RSVP and
MPLS forwarding state for (already) established LSPs that traverse
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
receive periodic RSVP refresh messages from the neighbor. The node
MAY clear RSVP and forwarding state for the LSPs that are in the
process of being established when their refresh timers expire.
Refreshing of Resv and Path state SHOULD be suppressed during this
waiting period.
During this waiting period, the node MAY inform upstream nodes of the
communication loss via a PathErr and/or upstream Notify message with
"Control Channel Degraded State" indication. If such notification
has been sent, then upon restoration of the control channel the node
MUST inform other nodes of the restoration via a PathErr and/or
upstream Notify message with "Control Channel Active State"
indication. (Specific error codes have been assigned by IANA.)
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
nodal fault. This determination is based on the Src_Instance
received from the neighbor. If the value is different than the value
that was received from the neighbor prior to the fault, then the
neighbor should be treated as if it has restarted. Otherwise, the
the fault was limited control channel. Procedures for handling each
case are described below.
9.4. Control Channel Faults
In the case of control channel faults, the node SHOULD refresh all
state shared with the neighbor. Summary Refreshes [RFC2961] with the
ACK_Desired flag set SHOULD be used, if supported. Note that if a
large number of messages are need, some pacing should be applied.
All state SHOULD be refreshed within the Recovery time advertised by
the neighbor.
9.5. Nodal Faults
Recovering from nodal faults uses one new object and other existing
protocol messages and objects.
9.5.1. Recovery Label
The Recovery_Label object is used during the nodal fault recovery
process. The format of a Recovery_Label object is identical to a
generalized label. A Recovery_Label object uses Class-Number 34 (of
form 0bbbbbbb) and the C-Type of the label being suggested.
9.5.2. Procedures for the Restarting node
After a node restarts its control plane, a node that supports state
recovery SHOULD check whether it was able to preserve its MPLS
forwarding state. If no forwarding state from prior to the restart
was preserved, then the node MUST set the Recovery Time to 0 in the
Hello message the node sends to its neighbors.
If the forwarding state was preserved, then the node initiates the
state recovery process. The period during which a node is prepared
to support the recovery process is referred to as the Recovery
Period. The total duration of the Recovery Period is advertised by
the recovering node in the Recovery Time parameter of the Restart_Cap
object. The Recovery Time MUST be set to the duration of the
Recovery Period in all Hello messages sent during the Recovery
Period. State that is not resynchronized during the Recovery Period
SHOULD be removed at the end of the Period.
Note that if during Hello synchronization the restarting node
determines that a neighbor does not support state recovery, and the
restarting node maintains its MPLS forwarding state on a per neighbor
basis, the restarting node should immediately consider the Recovery
Period with that neighbor completed. Forwarding state may be
considered to be maintained on a per neighbor basis when per
interface labels are used on point-to-point interfaces.
When a node receives a Path message during the Recovery Period, 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
according to previously defined procedures.
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,
and handles it according to previously defined procedures.
If the RSVP state is not found, and the message carries a
Recovery_Label object, the node searches its MPLS forwarding table
(the one that was preserved across the restart) for an entry whose
incoming interface matches the Path message and whose incoming label
is equal to the label carried in the Recovery_Label object.
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
defined procedures.
If the MPLS forwarding table entry is found, the appropriate RSVP
state is created, the entry is bound to the LSP associated with the
message, and related forwarding state should be considered as valid
and refreshed. Normal Path message processing should also be
conducted. When sending the corresponding outgoing Path message the
node SHOULD include a Suggested_Label object with a label value
matching the outgoing label from the now restored forwarding entry.
The outgoing interface SHOULD also be selected based on the
forwarding entry. In the special case where a restarting node also
has a restating downstream neighbor, a Recovery_Label object should
be used instead of a Suggested_Label object.
Additionally, for bidirectional LSPs, the node extracts the label
from the UPSTREAM_LABEL object carried in the received Path message,
and searches its MPLS forwarding table for an entry whose outgoing
label is equal to the label carried in the object (in the case of
link bundling, this may also involved first identifying the
appropriate incoming component link).
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
defined procedures.
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
considered to be re-synchronized. In addition, if the node is not
the tail-end of the LSP, the corresponding outgoing Path messages is
sent with the incoming label from that entry carried in the
UPSTREAM_LABEL object.
During the Recovery Period, Resv messages are processed normally with
two exceptions. In the case that a forwarding entry is recovered, no
new label or resource allocation is required while processing the
Resv message. The second exception is that ResvErr messages SHOULD
NOT be generated when a Resv message with no matching Path state is
received. In this case the Resv message SHOULD just be silently
discarded.
9.5.3. Procedures for the Neighbor of a Restarting node
The following specifies the procedures that apply when the node
reestablishes communication with the neighbor's control plane within
the Restart Time, the node determines (using the procedures defined
in Section 5 of [RFC3209]) that the neighbor's control plane has
restarted, and the neighbor was able to preserve its forwarding state
across the restart (as was indicated by a non-zero Recovery Time
carried in the Restart_Cap object of the RSVP Hello messages received
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
recovery, a node SHOULD refresh all Path state shared with that
neighbor. The outgoing Path messages MUST include a Recovery_Label
object containing a label value corresponding to the label value
received in the most recently received corresponding Resv message.
All Path state SHOULD be refreshed within approximately 1/2 of the
Recovery time advertised by the restarted neighbor. If there are
many LSP's going through the restarting node, the neighbor node
should avoid sending Path messages in a short time interval, as to
avoid unnecessary stressing the restarting node's CPU. Instead, it
should spread the messages across 1/2 the Recovery Time interval.
After detecting a restart of a neighbor that supports state recovery,
all Resv state shared with the restarting node MUST NOT be refreshed
until a corresponding Path message is received. This requires
suppression of normal Resv and Summary Refresh processing to the
neighbor during the Recovery Time advertised by the restarted
neighbor. As soon as a corresponding Path message is received a Resv
message SHOULD be generated and normal state processing SHOULD be
re-enabled.
10. RSVP Message Formats and Handling
This message summarizes RSVP message formats and handling as modified
by GMPLS.
10.1. RSVP Message Formats
This section presents the RSVP message related formats as modified by
this document. Where they differ, formats for unidirectional LSPs
are presented separately from bidirectional LSPs. Unmodified formats
are not listed. Again, MESSAGE_ID and related objects are defined in
[RFC2961].
The format of a Path message is as follows:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
The format of the sender description for unidirectional LSPs is:
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]
The format of the sender description for bidirectional LSPs is:
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_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:
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> is not modified by this document.
The format of a ResvErr 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>
The modified Hello message format is:
<Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO>
[ <RESTART_CAP> ]
10.2. Addressing Path, PathTear and ResvConf Messages
RSVP was designed to handle dynamic (non-explicit) path changes and
non RSVP hops along the path. To this end, the Path, PathTear and
ResvConf messages carry the destination address of the session in the
IP header. In generalized signaling, routes are usually explicitly
signaled. Further, hops that cannot allocate labels cannot exist in
the path of an LSP. A further difference with traditional RSVP is
that at times, an RSVP message may travel out of band with respect to
an LSP's data channel.
When a node is sending a Path, PathTear or ResvConf message to a node
that it knows to be adjacent at the data plane (i.e., along the path
of the LSP), it SHOULD address the message directly to an address
associated with the adjacent node's control plane. In this case the
router-alert option SHOULD not be included.
11. Acknowledgments
This document is the work of numerous authors and consists of a
composition of a number of previous documents in this area.
Valuable comments and input were received from a number of people,
including Igor Bryskin, Adrian Farrel and Dimitrios Pendarakis.
Portions of Section 4 are based on suggestions and text proposed by
Adrian Farrel.
The security considerations section is based on text provided by
Steven Bellovin.
12. Security Considerations
RSVP message security is described in [RFC2747] and provides message
integrity and node authentication. For hop-by-hop messages, this
document introduces no other new security considerations.
This document introduces the ability to send a Notify message in a
non-hop-by-hop fashion. This precludes RSVP's hop-by-hop integrity
and authentication model. In the case where RSVP is generating end-
to-end messages and the same level of security provided by [RFC2747]
is desired, the standard IPSEC based integrity and authentication can
be used. Alternatively, the sending of no-hop-by-hop Notify messages
can be disabled.
When using IPSEC to provide message authentication, the following
apply:
Selectors
The selector is identified by RSVP messages exchanged between a
pair of non-adjacent nodes. The nodes are identified by the
source and destination IP address of the inner IP header used
on Notify messages.
Mode
In this application, transport mode is the proper choice. The
information being communicated is generally not confidential,
so encryption need not be used. Either AH [RFC2402] or ESP
[RFC2406] MAY be used; if ESP is used, the sender's IP address
MUST be checked against the IP address asserted in the key
management exchange.
Key Management
To permit replay detection, an automated key management system
SHOULD be used, most likely IKE [RFC2409]. Configured keys MAY
be used.
Security Policy
Messages MUST NOT be accepted except from nodes that are not
known to the recipient to be authorized to make such requests.
Identification
Shared keys mechanisms should be adequate for initial
deployments and smaller networks. For larger-scale
deployments, certificate-based IKE should be supported.
Whatever scheme is used, it must tie back to a source IP
address in some fashion.
Availability
Many routers and switches already support IPSEC. For cases
where IPSEC is unavailable and security is required, Notify
messages MUST be sent hop-by-hop.
13. IANA Considerations
IANA assigns values to RSVP protocol parameters. Within the current
document multiple objects are defined. Each of these objects contain
C-Types. This section defines the rules for the assignment of the
related C-Type values. This section uses the terminology of BCP 26
"Guidelines for Writing an IANA Considerations Section in RFCs"
[BCP26].
As per [RFC2205], C-Type is an 8-bit number that identifies the
function of an object. All possible values except zero are available
for assignment.
The assignment of C-Type values of the objects defined in this
document fall into three categories. The first category inherit C-
Types from the Label object, i.e., object class number 16 [RFC3209].
IANA is requested to institute a policy whereby all C-Type values
assign for the Label object are also assigned for the following
objects:
o Suggested_Label (Class-Num 129)
o Upstream_Label (Class-Num 35)
o Recovery_Label (Class-Num 34)
The second category of objects follow independent policies.
Specifically, following the policies outlined in [BCP26], C-Type
values in the range 0x00 - 0x3F are allocated through an IETF
Consensus action, values in the range 00x40 - 0x5F are allocated as
First Come First Served, and values in the range 0x60 - 0x7F are
reserved for Private Use. This policy applies to the following
objects.
o Label_Set (Class-Num 36)
o Notify_Request (Class-Num 195)
o Protection (Class-Num 37)
o Admin Status (Class-Num 196)
o Restart_Cap (Class-Num 131)
The assignment of C-Type values for the remaining object, the
Acceptable_Label_Set object, follows the assignment of C-Type values
of the Label_Set object. IANA will institute a policy whereby all
C-Type values assigned for the Label_Set object are also assigned for
the Acceptable_Label_Set object.
13.1. IANA Assignments
This section summarizes values used in this document that have been
assigned by IANA.
---------------------------------------------------------------------
Message Types
o Notify message (Message type = 21)
---------------------------------------------------------------------
Class Types
o RSVP_HOP (C-Num 3)
- IPv4 IF_ID RSVP_HOP (C-type = 3)
- IPv6 IF_ID RSVP_HOP (C-type = 4)
o ERROR_SPEC (C-Num 6)
- IPv4 IF_ID ERROR_SPEC (C-type = 3)
- IPv6 IF_ID ERROR_SPEC (C-type = 4)
o LABEL_REQUEST (Class-Num 19)
- Generalized_Label_Request (C-Type = 4)
o RSVP_LABEL (Class-Num = 16)
- Generalized_Label (C-Type = 2)
- Waveband_Switching_Label C-Type (C-Type = 3)
---------------------------------------------------------------------
New Class-Nums, C-Types inherited from Label object (same as CNum16)
o RECOVERY_LABEL Class-Num of form 0bbbbbbb (= 34)
o SUGGESTED_LABEL Class-Num of form 10bbbbbb (= 129)
o UPSTREAM_LABEL Class-Num of form 0bbbbbbb (= 35)
---------------------------------------------------------------------
New Class-Nums
o LABEL_SET Class-Num of form 0bbbbbbb (= 36)
- Type 1 (C-Type = 1)
o ACCEPTABLE_LABEL_SET Class-Num of form 10bbbbbb (= 130)
- Type 1 Acceptable_Label_Set (C-type from label_set cnum)
o NOTIFY_REQUEST Class-Num of form 11bbbbbb (= 195)
- IPv4 Notify Request (C-Type = 1)
- IPv6 Notify Request (C-Type = 2)
o PROTECTION Class-Num of form 0bbbbbbb (= 37)
- Type 1 (C-Type = 1)
o ADMIN STATUS Class-Num of form 11bbbbbb (= 196)
- Type 1 (C-Type = 1)
o RESTART_CAP Class-Num of form 10bbbbbb (= 131)
- Type 1 (C-Type = 1)
---------------------------------------------------------------------
ERO/RRO subobject types
o Label ERO subobject
Type 3 - Label
o Label RRO subobject
Type 3 - Label
---------------------------------------------------------------------
Error codes
o "Routing problem/Label Set" (value = 11)
o "Routing problem/Switching Type" (value = 12)
(duplicate code 13 dropped)
o "Routing problem/Unsupported Encoding" (value = 14)
o "Routing problem/Unsupported Link Protection" (value = 15)
o "Notify Error/Control Channel Active State" (value = 4)
o "Notify Error/Control Channel Degraded State" (value = 5)
---------------------------------------------------------------------
14. Intellectual Property Considerations
This section is taken from Section 10.4 of [RFC2026].
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
15. References
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S.
and S. Jamin, "Resource ReserVation Protocol --
Version 1 Functional Specification", RFC2205,
September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF
Integrated Services", RFC2210, September 1997.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication
Header", RFC2401, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC2401, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key
Exchange (IKE)", RFC2409, November 1998.
[RFC2747] Baker, F., Lindell, B. and M. Talwar, "RSVP
Cryptographic Authentication", RFC2747, January
2000.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi,
F. and S. Molendini, "RSVP Refresh Overhead
Reduction Extensions", RFC2961, April 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions
to RSVP for LSP Tunnels", RFC3209, December 2001.
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol
Label Switching (GMPLS) Signaling Functional
Description", RFC3471, January 2003.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered
Links in Resource Reservation Protocol - Traffic
Engineering (RSVP-TE)", RFC3477, January 2003.
15.2. Informative References
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP
26, RFC2434, October 1998.
[MPLS-HIERARCHY] Kompella, K. and Y. Rekhter, "LSP Hierarchy with
MPLS TE", Work in Progress.
[PAN-RESTART] Pan, P., et. al., "Graceful Restart Mechanism for
RSVP-TE", Work in Progress.
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC2026, October 1996.
16. Contributors
Peter Ashwood-Smith
Nortel Networks Corp.
P.O. Box 3511 Station C,
Ottawa, ON K1Y 4H7
Canada
Phone: +1 613 763 4534
EMail: petera@nortelnetworks.com
Ayan Banerjee
Calient Networks
5853 Rue Ferrari
San Jose, CA 95138
Phone: +1 408 972-3645
EMail: abanerjee@calient.net
Lou Berger
Movaz Networks, Inc.
7926 Jones Branch Drive
Suite 615
McLean VA, 22102
Phone: +1 703 847-1801
EMail: lberger@movaz.com
Greg Bernstein
EMail: gregb@grotto-networking.com
John Drake
Calient Networks
5853 Rue Ferrari
San Jose, CA 95138
Phone: +1 408 972 3720
EMail: jdrake@calient.net
Yanhe Fan
Axiowave Networks, Inc.
200 Nickerson Road
Marlborough, MA 01752
Phone: + 1 774 348 4627
EMail: yfan@axiowave.com
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
EMail: kireeti@juniper.net
Jonathan P. Lang
EMail: jplang@ieee.org
Fong Liaw
Solas Research, LLC
EMail: fongliaw@yahoo.com
Eric Mannie
Independent Consultant
2 Avenue de la Folle Chanson
1050 Brussels
Belgium
EMail: eric_mannie@hotmail.com
Ping Pan
Ciena
10480 Ridgeview Court
Cupertino, CA 95014
Phone: 408-366-4700
EMail: ppan@ciena.com
Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Phone: +1 732 923 4237
Fax: +1 732 923 9804
EMail: braja@tellium.com
Yakov Rekhter
Juniper Networks, Inc.
EMail: yakov@juniper.net
Debanjan Saha
EMail: debanjan@acm.org
Vishal Sharma
Metanoia, Inc.
1600 Villa Street, Unit 352
Mountain View, CA 94041-1174
Phone: +1 650-386-6723
EMail: v.sharma@ieee.org
George Swallow
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Phone: +1 978 244 8143
EMail: swallow@cisco.com
Z. Bo Tang
EMail: botang01@yahoo.com
17. Editor's Address
Lou Berger
Movaz Networks, Inc.
7926 Jones Branch Drive
Suite 615
McLean VA, 22102
Phone: +1 703 847-1801
EMail: lberger@movaz.com
18. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.