draft-ietf-mpls-generalized-cr-ldp-00.txt   draft-ietf-mpls-generalized-cr-ldp-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 - CR-LDP Extensions Generalized MPLS Signaling - CR-LDP Extensions
draft-ietf-mpls-generalized-cr-ldp-00.txt draft-ietf-mpls-generalized-cr-ldp-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
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at To view the current status of any Internet-Draft, please check the
http://www.ietf.org/ietf/1id-abstracts.txt "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
Directory, see http://www.ietf.org/shadow.html.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes extensions to CR-LDP signaling required to This document describes extensions to CR-LDP signaling required to
support Generalized MPLS. Generalized MPLS extends MPLS to encompass support Generalized MPLS. Generalized MPLS extends MPLS to encompass
time-division (e.g. SONET ADMs), wavelength (optical lambdas) and time-division (e.g. SONET ADMs), wavelength (optical lambdas) and
spatial switching (e.g. incoming port or fiber to outgoing port or spatial switching (e.g. incoming port or fiber to outgoing port or
fiber). This document presents a CR-LDP specific description of the fiber). This document presents a CR-LDP specific description of the
extensions. An RSVP-TE specific description can be found in [GMPLS- extensions. An RSVP-TE specific description can be found in [GMPLS-
RSVP]. A generic functional description is presented in [GMPLS-SIG]. RSVP]. A generic functional description is presented in [GMPLS-SIG].
skipping to change at page 2, line 24 skipping to change at page 2, line 24
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 ................................................ 7
2.4 Suggested Label ........................................... 8 2.4 Suggested Label ........................................... 8
2.5 Label Set ................................................. 8 2.5 Label Set ................................................. 8
2.5.1 Procedures ................................................ 8 2.5.1 Procedures ................................................ 8
3 Bidirectional LSPs ........................................ 9 3 Bidirectional LSPs ........................................ 9
3.1 Procedures ................................................ 10 3.1 Procedures ................................................ 10
4 Explicit Label Control .................................... 10 4 Explicit Label Control .................................... 10
4.1 Procedures ................................................ 11 4.1 Procedures ................................................ 11
5 Acknowledgments ........................................... 12 5 Protection TLV ............................................ 12
6 Security Considerations ................................... 12 5.1 Procedures ................................................ 12
7 References ................................................ 12 6 Acknowledgments ........................................... 12
8 Authors' Addresses ........................................ 13 7 Security Considerations ................................... 13
8 References ................................................ 13
9 Authors' Addresses ........................................ 13
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 Clarified Label Set
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 CR-LDP switching is provided in [GMPLS-SIG]. This document presents CR-LDP
skipping to change at page 4, line 19 skipping to change at page 4, line 19
LSRs. A Generalized Label Request TLV is set by the ingress node, LSRs. A Generalized Label Request TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| 0x0901 | Length | |U|F| 0x0901 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 CR-LDP) is: (in CR-LDP) 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| 0x0902 | Length | |U|F| 0x0902 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 REQUEST message containing the Generalized A node processing a REQUEST message containing a Generalized Label
Label Request must verify that the requested parameters can be Request must verify that the requested parameters can be satisfied by
satisfied by the incoming interface, the node and by the outgoing the incoming interface, the node and by the outgoing interface. The
interface. The node may either directly support the LSP or it may node may either directly support the LSP or it may use a tunnel (FA),
use a tunnel (FA), i.e., another class of switching. In either case, i.e., another class of switching. In either case, each parameter
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 NOTIFICATION message, with a "Routing node MUST generate a NOTIFICATION 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 NOTIFICATION 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
NOTIFICATION message, with a "Routing problem/Unsupported GPID" NOTIFICATION 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 MAPPING message. In this case if PID during the processing of the MAPPING message. In this case if
the G-PID is not supported, then the penultimate hop MUST generate a the G-PID is not supported, then the penultimate hop MUST generate a
NOTIFICATION message with a "Routing problem/Unacceptable label NOTIFICATION message with a "Routing problem/Unacceptable label
value" indication. value" indication.
skipping to change at page 11, line 5 skipping to change at page 11, line 5
|0|0| 0x901 | Length | |0|0| 0x901 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|U| Reserved | Label | |L|U| Reserved | Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label (continued) | | Label (continued) |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of L, U and Label parameters. See [GMPLS-SIG] for a description of L, U and Label parameters.
Length
Specifies the length of the value field in bytes.
4.1. Procedures 4.1. Procedures
The Label ER-Hop follows a ER-Hop containing the IP address, or the The Label ER-Hop follows a ER-Hop containing the IP address, or the
interface identifier [MPLS-UNNUM], associated with the link on which interface identifier [MPLS-UNNUM], associated with the link on which
it is to be used. The preceding ER-Hop must be strict. Up to two it is to be used. The preceding ER-Hop must be strict. Up to two
label ER-Hops may be present, one for the downstream label and one label ER-Hops may be present, one for the downstream label and one
for the upstream label. The following SHOULD result in "Bad for the upstream label. The following SHOULD result in "Bad
EXPLICIT_ROUTE" errors: EXPLICIT_ROUTE" errors:
- If the first label ER-Hop is not preceded by a ER-Hop - If the first label ER-Hop is not preceded by a ER-Hop
containing an IP address, or a interface identifier containing an IP address, or a interface identifier
skipping to change at page 12, line 5 skipping to change at page 12, line 5
Note an implication of the above procedures is that the label ER-Hop Note an implication of the above procedures is that the label ER-Hop
should never be the first ER-Hop in a newly received message. If the should never be the first ER-Hop in a newly received message. If the
label ER-Hop is the the first ER-Hop an a received ER, then it SHOULD label ER-Hop is the the first ER-Hop an a received ER, then it SHOULD
be treated as a "Bad strict node" error. 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 ER-Hop are outside the information needed to construct the Label ER-Hop are outside the
scope of this document. scope of this document.
5. Acknowledgments 5. Protection TLV
The use of the Protection Object is optional. The object is included
to indicate specific protection attributes of an LSP.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| TBA | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [GMPLS-SIG] for a description of parameters.
5.1. Procedures
Transit nodes processing a REQUEST 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 NOTIFICATION message, with a "Routing problem/Unsupported
Link Protection" indication.
6. 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,
notably Adrian Farrel. notably Adrian Farrel.
6. Security Considerations 7. Security Considerations
This draft introduce no new security considerations to [CR-LDP]. This draft introduce no new security considerations to [CR-LDP].
7. References 8. References
[CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP",
draft-ietf-mpls-cr-ldp-04.txt, July, 2000. draft-ietf-mpls-cr-ldp-04.txt, July, 2000.
[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-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - [GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling -
RSVP-TE Extensions", Internet Draft, RSVP-TE Extensions", Internet Draft,
draft-ietf-mpls-generalized-rsvp-te-00.txt, draft-ietf-mpls-generalized-rsvp-te-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.
[FEEDBACK] P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki, [FEEDBACK] P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki,
"Improving Topology Data Base Accuracy With LSP Feedback "Improving Topology Data Base Accuracy With LSP Feedback
via CR-LDP", Internet Draft, draft-ietf-mpls-te-feed-00.txt. via CR-LDP", Internet Draft, draft-ietf-mpls-te-feed-00.txt.
8. Authors' Addresses 9. Authors' Addresses
Peter Ashwood-Smith Peter Ashwood-Smith
Nortel Networks Corp. Nortel Networks Corp.
P.O. Box 3511 Station C, P.O. Box 3511 Station C,
Ottawa, ON K1Y 4H7 Ottawa, ON K1Y 4H7
Canada Canada
Phone: +1 613 763 4534 Phone: +1 613 763 4534
Email: petera@nortelnetworks.com Email: petera@nortelnetworks.com
Ayan Banerjee Ayan Banerjee
skipping to change at page 13, line 21 skipping to change at page 14, line 4
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 14, line 15 skipping to change at page 15, line 4
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: kireeti@juniper.net Email: kireeti@juniper.net
Jonathan P. Lang Jonathan P. Lang
Calient Networks Calient Networks
25 Castilian 25 Castilian
Goleta, CA 93117 Goleta, CA 93117
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:09:47 EST 2001
 End of changes. 

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