draft-ietf-mpls-generalized-rsvp-te-00.txt   draft-ietf-mpls-generalized-rsvp-te-01.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: May 2001 Lou Berger (Movaz Networks) Expiration Date: September 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 (GTS) Eric Mannie (EBONE)
Jonathan P. Lang (Calient Networks) Jonathan P. Lang (Calient Networks)
Bala Rajagopalan (Tellium, Inc.) Bala Rajagopalan (Tellium, Inc.)
Yakov Rekhter (Cisco Systems) Yakov Rekhter (Juniper Networks, Inc.)
Debanjan Saha (Tellium, Inc.) Debanjan Saha (Tellium, Inc.)
Vishal Sharma (Tellabs) Vishal Sharma (Jasmine Networks)
George Swallow (Cisco Systems) George Swallow (Cisco Systems)
Z. Bo Tang (Tellium, Inc.) Z. Bo Tang (Tellium, Inc.)
November 2000 March 2001
Generalized MPLS Signaling - RSVP-TE Extensions Generalized MPLS Signaling - RSVP-TE Extensions
draft-ietf-mpls-generalized-rsvp-te-00.txt draft-ietf-mpls-generalized-rsvp-te-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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 Generalized Label Request with SONET/SDH Label Range ...... 4
2.1.2 Procedures ................................................ 4 2.1.2 Procedures ................................................ 4
2.1.3 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 ................................................ 6
2.3 Waveband Switching ........................................ 6 2.3 Waveband Switching ........................................ 6
2.3.1 Procedures ................................................ 7 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 ..................................... 10
4 Notification .............................................. 10 4 Notification .............................................. 10
4.1 Notify Request Object ..................................... 10 4.1 Notify Request Objects .................................... 10
4.1.1 Required Information ...................................... 11 4.1.1 Required Information ...................................... 11
4.1.2 Procedures ................................................ 11 4.1.2 Procedures ................................................ 11
4.2 Notify Message ............................................ 12 4.2 Notify Message ............................................ 12
4.2.1 Required Information ...................................... 12 4.2.1 Required Information ...................................... 12
4.2.2 Procedures ................................................ 13 4.2.2 Procedures ................................................ 13
4.3 Removing State with a PathErr message ..................... 13 4.3 Removing State with a PathErr message ..................... 14
5 Explicit Label Control .................................... 14 5 Explicit Label Control .................................... 15
5.1 Procedures ................................................ 15 5.1 Procedures ................................................ 15
6 RSVP Message Formats ...................................... 16 6 Protection Object ......................................... 16
7 Acknowledgments ........................................... 17 6.1 Procedures ................................................ 17
8 Security Considerations ................................... 17 7 RSVP Message Formats ...................................... 17
9 References ................................................ 18 8 Acknowledgments ........................................... 18
10 Authors' Addresses ........................................ 18 9 Security Considerations ................................... 18
10 References ................................................ 19
11 Authors' Addresses ........................................ 19
Changes from previous version: Changes from previous version:
o Moved protocol specific details into two documents, one for RSVP-TE o Revised label request
and one for CR-LDP. o Moved protection flags to separate object
o Fixed bandwidth encodings o Added IPv6 support to Notify message
o Revised Notify message format to disambiguate upstream and
downstream notifications.
o Minor text cleanup o Minor text cleanup
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 4, line 12 skipping to change at page 4, line 12
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 format of a Generalized Label Request is: The format of a Generalized Label Request 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 |Link Prot.Flags| 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. Generalized Label Request with SONET/SDH Label Range
The format of a Generalized Label Request with SONET/SDH Label Range The format of a Generalized Label Request with SONET/SDH Label Range
(in RSVP) is: (in RSVP) 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 (5)[TBA]| | Length | Class-Num (19)|C-Type (5)[TBA]|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Link Prot.Flags| G-PID | | LSP Enc. Type | Reserved | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RGT | RT | Reserved | RNC | | RNC | Signal Type |Rsrved.| RGT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of parameters. See [GMPLS-SIG] for a description of parameters.
2.1.2. Procedures 2.1.2. Procedures
A node processing the Path message containing the 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 incoming interface, the node and by the outgoing interface. The
node may either directly support the LSP or it may use a tunnel (FA), node may either directly support the LSP or it may use a tunnel (FA),
i.e., another class of switching. In either case, each parameter i.e., another class of switching. In either case, each parameter
must be checked. 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 outgoing interface or tunnel can support the
requested LSP Encoding Type. If encoding cannot be supported, the requested LSP Encoding Type. If encoding cannot be supported, the
node MUST generate a PathErr message, with a "Routing node MUST generate a PathErr message, with a "Routing
problem/Unsupported Encoding" indication. problem/Unsupported Encoding" indication.
Transit nodes MUST verify that the outgoing interface or tunnel can
support the requested Link Protection Flags. If it cannot, the node
MUST generate a PathErr message, with a "Routing problem/Unsupported
Link Protection" 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 GPID"
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.
skipping to change at page 10, line 40 skipping to change at page 10, line 40
4. Notification 4. Notification
This section defines three signaling extensions that modify error This section defines three signaling extensions that modify error
handling, enable expedited notification of failures and other events handling, enable expedited notification of failures and other events
to nodes responsible for restoring failed LSPs. The first extension, to nodes responsible for restoring failed LSPs. The first extension,
the Notify Request object, identifies where event notifications are the Notify Request object, identifies where event notifications are
to be sent. The second, the Notify message, provides for general to be sent. The second, the Notify message, provides for general
event notification. The final extension allows for the removal of event notification. The final extension allows for the removal of
Path state on handling of PathErr messages. Path state on handling of PathErr messages.
4.1. Notify Request Object 4.1. 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.1.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 6. 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
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(TBD)| 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
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(TBD)| C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Notify Node Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Notify Node Address: 16 bytes
The IP address of the node that should be notified when
generating an error message.
If a message contains multiple NOTIFY_REQUEST objects, only the first If a message contains multiple NOTIFY_REQUEST objects, only the first
object is meaningful. Subsequent NOTIFY_REQUEST objects MAY be object is meaningful. Subsequent NOTIFY_REQUEST objects MAY be
ignored and SHOULD NOT be propagated. ignored and SHOULD NOT be propagated.
4.1.2. Procedures 4.1.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
skipping to change at page 16, line 12 skipping to change at page 16, line 31
Note an implication of the above procedures is that the label Note an implication of the above procedures is that the label
subobject should never be the first subobject in a newly received subobject should never be the first subobject in a newly received
message. If the label subobject is the the first subobject an a message. If the label subobject is the the first subobject an a
received ERO, then it SHOULD be treated as a "Bad strict node" error. received ERO, then it SHOULD be treated as a "Bad strict node" error.
Procedures by which an LSR at the head-end of an LSP obtains the Procedures by which an LSR at the head-end of an LSP obtains the
information needed to construct the Label subobject are outside the information needed to construct the Label subobject are outside the
scope of this document. scope of this document.
6. RSVP Message Formats 6. Protection Object
The use of the Protection Object is optional. The object is included
to indicate specific protection attributes of an LSP. The Protection
Object uses a Class-Number TBA (of form 0bbbbbbb).
The format of Protection Flags 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(TBA)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of parameters.
6.1. Procedures
Transit nodes processing a Path message containing a Protection
Object MUST verify that the requested protection can be satisfied by
the outgoing interface or tunnel (FA). If it cannot, the node MUST
generate a PathErr message, with a "Routing problem/Unsupported Link
Protection" indication.
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.
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> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<TIME_VALUES> <TIME_VALUES>
[ <EXPLICIT_ROUTE> ] [ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST> <LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ] [ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ] [ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ] [ <NOTIFY_REQUEST> ]
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
<sender descriptor> <sender descriptor>
The format of the sender description for unidirectional LSPs is: The format of the sender description for unidirectional LSPs is:
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC> <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ] [ <ADSPEC> ]
skipping to change at page 17, line 16 skipping to change at page 18, line 16
<Resv Message> ::= <Common Header> [ <INTEGRITY> ] <Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<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.
7. 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
Valuable comments and input were received from a number of people, Valuable comments and input were received from a number of people,
including Igor Bryskin and Adrian Farrel. Portions of Section 4 are including Igor Bryskin and Adrian Farrel. Portions of Section 4 are
based on suggestions and text proposed by Adrian Farrel. based on suggestions and text proposed by Adrian Farrel.
8. 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 introduce no other new security considerations to [RSVP-
TE]. TE].
9. 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-00.txt, July 2000.
[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-00.txt, draft-ietf-mpls-generalized-cr-ldp-01.txt,
November 2000. 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-01.txt, draft-ietf-mpls-generalized-signaling-02.txt,
November 2000. February 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119. Requirement Levels," RFC 2119.
[RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol [RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol
-- Version 1 Functional Specification", RFC 2205, -- Version 1 Functional Specification", RFC 2205,
September 1997. September 1997.
[RSVP-TE] Awduche, D.O., Berger, L., Gan, D.-H., Li, T., Swallow, G., [RSVP-TE] Awduche, D.O., Berger, L., Gan, D.-H., Li, T., Swallow, G.,
and Srinivasan, V., "RSVP-TE: Extensions to RSVP for LSP and Srinivasan, V., "RSVP-TE: Extensions to RSVP for LSP
Tunnels," Internet Draft, Tunnels," Internet Draft,
draft-ietf-mpls-rsvp-lsp-tunnel-06.txt, July 2000. draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, February 2001.
[RSVP-RR] Berger L., Gan D., Swallow G., Pan P., Tommasi F., [RSVP-RR] Berger L., Gan D., Swallow G., Pan P., Tommasi F.,
Molendini S., "RSVP Refresh Overhead Reduction Extensions", Molendini S., "RSVP Refresh Overhead Reduction Extensions",
draft-ietf-rsvp-refresh-reduct-05.txt, June 2000. draft-ietf-rsvp-refresh-reduct-05.txt, June 2000.
10. Authors' Addresses 11. 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
Movaz Networks Movaz Networks, Inc.
Phone: +1 301 468 9228 7926 Jones Branch Drive
Suite 615
McLean VA, 22102
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
Cupertino, CA 94014 Cupertino, CA 94014
Phone: +1 408 366 4713 Phone: +1 408 366 4713
Email: greg@ciena.com Email: greg@ciena.com
John Drake John Drake
skipping to change at page 20, line 5 skipping to change at page 21, line 5
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: kireeti@juniper.net Email: kireeti@juniper.net
Jonathan P. Lang Jonathan P. Lang
Calient Networks Calient Networks
25 Castilian 25 Castilian
Goleta, CA 93117 Goleta, CA 93117
Email: jplang@calient.net Email: jplang@calient.net
Eric Mannie Eric Mannie
GTS EBONE
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@gts.com Email: eric.mannie@ebone.com
Bala Rajagopalan Bala Rajagopalan
Tellium, Inc. Tellium, Inc.
2 Crescent Place 2 Crescent Place
P.O. Box 901 P.O. Box 901
Oceanport, NJ 07757-0901 Oceanport, NJ 07757-0901
Phone: +1 732 923 4237 Phone: +1 732 923 4237
Fax: +1 732 923 9804 Fax: +1 732 923 9804
Email: braja@tellium.com Email: braja@tellium.com
Yakov Rekhter Yakov Rekhter
cisco Systems Juniper Networks, Inc.
Email: yakov@cisco.com Email: yakov@juniper.net
Debanjan Saha Debanjan Saha
Tellium Optical Systems Tellium Optical Systems
2 Crescent Place 2 Crescent Place
Oceanport, NJ 07757-0901 Oceanport, NJ 07757-0901
Phone: +1 732 923 4264 Phone: +1 732 923 4264
Fax: +1 732 923 9804 Fax: +1 732 923 9804
Email: dsaha@tellium.com Email: dsaha@tellium.com
Vishal Sharma Vishal Sharma
Tellabs Research Center Jasmine Networks, Inc.
One Kendall Square 3061 Zanker Road, Suite B
Bldg. 100, Ste. 121 San Jose, CA 95134
Cambridge, MA 02139-1562 Phone: +1 408 895 5030
Phone: +1 617 577 8760 Fax: +1 408 895 5050
Email: Vishal.Sharma@tellabs.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
 End of changes. 

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