--- 1/draft-ietf-mpls-generalized-cr-ldp-03.txt 2006-02-05 00:38:58.000000000 +0100 +++ 2/draft-ietf-mpls-generalized-cr-ldp-04.txt 2006-02-05 00:38:58.000000000 +0100 @@ -1,94 +1,107 @@ Network Working Group Peter Ashwood-Smith (Nortel Networks Corp.) Internet Draft Ayan Banerjee (Calient Networks) -Expiration Date: November 2001 Lou Berger (Movaz Networks) +Expiration Date: January 2002 Lou Berger (Movaz Networks) Greg Bernstein (Ciena Corporation) John Drake (Calient Networks) Yanhe Fan (Axiowave Networks) + Don Fedyk (Nortel Networks Corp.) Kireeti Kompella (Juniper Networks, Inc.) Eric Mannie (EBONE) Jonathan P. Lang (Calient Networks) Bala Rajagopalan (Tellium, Inc.) Yakov Rekhter (Juniper Networks, Inc.) Debanjan Saha (Tellium, Inc.) Vishal Sharma (Jasmine Networks) George Swallow (Cisco Systems) Z. Bo Tang (Tellium, Inc.) - May 2001 + July 2001 Generalized MPLS Signaling - CR-LDP Extensions - draft-ietf-mpls-generalized-cr-ldp-03.txt + draft-ietf-mpls-generalized-cr-ldp-04.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - To view the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow Directory, see http://www.ietf.org/shadow.html. Abstract This document describes extensions to CR-LDP signaling required to support Generalized MPLS. Generalized MPLS extends MPLS to encompass time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). This document presents a CR-LDP specific description of the extensions. An RSVP-TE specific description can be found in [GMPLS- RSVP]. A generic functional description is presented in [GMPLS-SIG]. Contents 1 Introduction .............................................. 3 2 Label Related Formats .................................... 3 - 2.1 Generalized Label Request ................................. 3 + 2.1 Generalized Label Request ................................. 4 2.1.1 Procedures ................................................ 4 2.1.2 Bandwidth Encoding ........................................ 5 2.2 Generalized Label ......................................... 5 2.2.1 Procedures ................................................ 5 2.3 Waveband Switching ........................................ 6 2.3.1 Procedures ................................................ 6 2.4 Suggested Label ........................................... 7 2.5 Label Set ................................................. 7 - 2.5.1 Procedures ................................................ 7 - 3 Bidirectional LSPs ........................................ 8 + 2.5.1 Procedures ................................................ 8 + 3 Bidirectional LSPs ........................................ 9 3.1 Procedures ................................................ 9 - 4 Notification on Label Error ............................... 9 + 4 Notification on Label Error ............................... 10 5 Explicit Label Control .................................... 10 - 5.1 Procedures ................................................ 10 - 6 Protection TLV ............................................ 11 + 5.1 Procedures ................................................ 11 + 6 Protection TLV ............................................ 12 6.1 Procedures ................................................ 12 - 7 Acknowledgments ........................................... 12 - 8 Security Considerations ................................... 12 - 9 References ................................................ 12 -10 Authors' Addresses ........................................ 13 + 7 Administrative Status Information ......................... 12 + 7.1 Admin Status Object ....................................... 12 + 7.2 REQUEST and MAPPING Message Procedures .................... 13 + 7.3 Modification Message Procedures ........................... 13 + 7.3.1 Deletion procedure ........................................ 14 + 7.3.2 Compatibility ............................................. 14 + 7.3.3 Notify Message Procedures ................................. 14 + 8 Control Channel Separation ................................ 15 + 8.1 Interface Identification .................................. 15 + 8.2 Procedures ................................................ 16 + 9 Fault Handling ......................................... 16 +10 Acknowledgments ........................................... 16 +11 Security Considerations ................................... 17 +12 References ................................................ 17 +13 Authors' Addresses ........................................ 17 Changes from previous version: -o Fixed Label Set format +o Fixed Label Set format (for LDP) +o Removed unassigned values +o Added Switching type of LSP being requested +o Added Administrative Status Information (based on last call comments) +o Added section on Control Channel Separation + (based on last call comments) + Covers: + - Separation of control and data channels 1. Introduction Generalized MPLS extends MPLS from supporting packet (PSC) interfaces and switching to include support of three new classes of interfaces and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and Fiber-Switch (FSC). A functional description of the extensions to MPLS signaling needed to support the new classes of interfaces and switching is provided in [GMPLS-SIG]. This document presents CR-LDP specific formats and mechanisms needed to support all four classes of @@ -120,23 +133,23 @@ A REQUEST message SHOULD contain as specific an LSP Encoding Type as possible to allow the maximum flexibility in switching by transit LSRs. A Generalized Label Request TLV is set by the ingress node, transparently passed by transit nodes, and used by the egress node. The format of a Generalized Label Request 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| 0x0901 | Length | + |U|F| Type (TBA by IANA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LSP Enc. Type | Reserved | G-PID | + | LSP Enc. Type |Switching Type | G-PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See [GMPLS-SIG] for a description of parameters. 2.1.1. Procedures A node processing a REQUEST message containing a Generalized Label Request must verify that the requested parameters can be satisfied by 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), @@ -179,21 +192,21 @@ Rate fields of the Traffic Parameters TLV. Other bandwidth/service related parameters in the TLV are ignored and carried transparently. 2.2. Generalized Label The format of a Generalized Label 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| 0x0902 | Length | + |U|F| Type (TBA by IANA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See [GMPLS-SIG] for a description of parameters and encoding of labels. 2.2.1. Procedures @@ -215,21 +228,21 @@ Waveband switching uses the same format as the generalized label, see section 2.2. The type (0x0903) is assigned for the Waveband Label. In the context of waveband switching, the generalized label has the following format: 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| 0x0903 | Length | + |U|F| Type (TBA by IANA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Waveband Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See [GMPLS-SIG] for a description of parameters. @@ -238,22 +251,22 @@ The procedures defined in Section 2.2.1 apply to waveband switching. This includes generating a NOTIFICATION message with a "Routing problem/MPLS label allocation failure" indication if any of the label fields are unrecognized or unacceptable. Additionally, when a waveband is switched to another waveband, it is possible that the wavelengths within the waveband will be mirrored about a center frequency. When this type of switching is employed, the start and end label in the waveband label TLV MUST be flipped before forwarding the label TLV with the new waveband Id. In this - manner an egress/ingress LSR which receives a waveband label which - has these values inverted, knows that it must also invert its egress + manner an egress/ingress LSR that receives a waveband label which has + these values inverted, knows that it must also invert its egress association to pick up the proper wavelengths. Without this mechanism and with an odd number of mirrored switching operations, the egress LSRs will not know that an input wavelength of say L1 will emerge from the waveband tunnel as L100. This operation MUST be performed in both directions when a bidirectional waveband tunnel is being established. 2.4. Suggested Label @@ -299,24 +312,24 @@ labels/subchannels can be added to or excluded from a Label Set via Action two (2) and three (3) TLVs respectively. When the Label_Set TLVs only list labels/subchannels to exclude, this implies that all other labels are acceptable. The absence of any Label_Set TLVs implies that all labels are acceptable. A Label Set is included when a node wishes to restrict the label(s) that may be used downstream. On reception of a REQUEST message, the receiving node will restrict - its choice of labels to one which is in the Label Set. Nodes capable - of performing label conversion may also remove the Label Set prior to - forwarding the REQUEST message. If the node is unable to pick a - label from the Label Set or if there is a problem parsing the + its choice of labels to one, which is in the Label Set. Nodes + capable of performing label conversion may also remove the Label Set + prior to forwarding the REQUEST message. If the node is unable to + pick a label from the Label Set or if there is a problem parsing the Label_Set TLVs, then the request is terminated and a NOTIFICATION message with a "Routing problem/Label Set" indication MUST be generated. It is a local matter if the Label Set is stored for later selection on the MAPPING or if the selection is made immediately for propagation in the MAPPING. On reception of a REQUEST message, the Label Set represented in the message is compared against the set of available labels at the downstream interface and the resulting intersecting Label Set is forwarded in a REQUEST message. When the resulting Label Set is @@ -400,21 +413,21 @@ problem/Unacceptable label value" indication. The absence of Acceptable_Label_Set TLVs does not have any specific meaning. 5. Explicit Label Control The Label ER-Hop is defined as follows: 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|0| 0x0806 | Length | + |0|0| Type (TBA by IANA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L|U| Reserved | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label (continued) | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See [GMPLS-SIG] for a description of L, U and Label parameters. 5.1. Procedures @@ -428,90 +441,256 @@ - If the first label ER-Hop is not preceded by a ER-Hop containing an IP address, or a interface identifier [MPLS-UNNUM], associated with an output link. - For a label ER-Hop to follow a ER-Hop that has the L-bit set - On unidirectional LSP setup, for there to be a label ER-Hop with the U-bit set - For there to be two label ER-Hops with the same U-bit values To support the label ER-Hop, a node must check to see if the ER-Hop - following it's associate address/interface is a label ER-Hop. If it + following its associate address/interface is a label ER-Hop. If it is, one ER-Hop is examined for unidirectional LSPs and two ER-Hops for bidirectional LSPs. If the U-bit of the ER-Hop being examined is clear (0), then value of the label is copied into a new Label_Set TLV. This Label_Set TLV MUST be included on the corresponding outgoing MAPPING message. If the U-bit of the ER-Hop being examined is set (1), then value of the label is label to be used for upstream traffic associated with the bidirectional LSP. If this label is not acceptable, a "Bad EXPLICIT_ROUTE" error SHOULD be generated. If the label is acceptable, the label is copied into a new Upstream Label TLV. This Upstream Label TLV MUST be included on the corresponding outgoing MAPPING message. After processing, the label ER-Hops are removed from the ER. 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 - label ER-Hop is the the first ER-Hop an a received ER, then it SHOULD - be treated as a "Bad strict node" error. + label ER-Hop is the first ER-Hop an a received ER, 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 information needed to construct the Label ER-Hop are outside the scope of this document. 6. Protection TLV The use of the Protection TLV is optional. The TLV is included to indicate specific protection attributes of an LSP. The format of Protection Information TLV 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| 0x0908 | Length | + |U|F| Type (TBA by IANA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved | Link Flags| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See [GMPLS-SIG] for a description of parameters. 6.1. Procedures Transit nodes processing a REQUEST message containing a Protection TLV 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. -7. Acknowledgments +7. Administrative Status Information + + Administrative Status Information is carried in the Admin Status TLV. + The TLV provides information related to the administrative state of a + particular LSP. The information is used in two ways. In the first, + the object is carried in REQUEST and MAPPING messages to indicate the + administrative state of an LSP. In the second, the TLV is carried in + a REQUEST and MAPPING message with the modification bit set to + request a change to the administrative state of an LSP. + +7.1. Admin Status Object + + The use of the Admin Status TLV is optional. + + The format of the TLV is: + + The format of Admin Status TLV in REQUEST, MAPPING Messages 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| Type (TBA by IANA) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved |T|D| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The U Bit Should be set to 1. The F bit should be set to 1. + + See [GMPLS-SIG] for a description of parameters. + +7.2. REQUEST and MAPPING Message Procedures + + The Admin Status TLV is used to notify each node along the path of + the status of the LSP. Status information is processed by each node + based on local policy and then propagated in the corresponding + outgoing messages. The TLV is inserted in REQUEST messages at the + discretion of the ingress node. + + Transit nodes receiving a REQUEST message containing an Admin Status + TLV, update their local state, take any appropriate local action + based on the indicated status and then propagate the received Admin + Status TLV in the outgoing REQUEST message. + + Egress nodes receiving a REQUEST message containing an Admin Status + TLV, also update their local state and take any appropriate local + action based on the indicated status. + + The subsequent MAPPING message MUST carry back the Admin Status TLV + if the corresponding request message had the Admin Status TLV. + +7.3. Modification Message Procedures + + Subsequent messaging Admin Status messaging is all performed by + REQUEST and MAPPING Messages using the modification action indicator + flag. The ingress may begin the propagation of a Message with an + Admin Status TLV. Each subsequent node propagates the REQUEST with + the Admin Status TLV from the ingress to the egress and then the + egress node returns the MAPPING messages back Upstream carrying the + Admin Status TLV. A modification message of this type would + typically only carry the mandatory CR-LDP TLVs and the Admin Status + TLV. + +7.3.1. Deletion procedure + + In some circumstances, particularly optical networks, it is useful to + set the administrative status of an LSP before tearing it down. In + such circumstances the procedure SHOULD be followed when deleting an + LSP: + + The ingress node precedes an LSP deletion by inserting an Admin + Status TLV in a REQUEST Message with the modification action + indicator set to modify message and setting the Down (D) bit. + + Transit and egress nodes process the Admin Status TLV as described + above. + + Upon receiving the Admin Status TLV with the Down (D) bit set in the + MAPPING message with the modification action indicator set to modify + the ingress node sends a RELEASE message downstream to remove the LSP + and normal CR-LDP processing takes place. + +7.3.2. Compatibility + + It is possible that some nodes along an LSP will not support the + Admin Status TLV. In the case of a non-supporting transit node, the + TLV will pass through the node unmodified and normal processing can + continue. In the case of a non-supporting egress node, the Admin + Status TLV may not be reflected back in the MAPPING Message. In this + case, the ingress SHOULD continue to set the contents of the object + normally but, when processing an LSP deletion, it MUST NOT wait for + an updated Admin Status TLV in a MAPPING message before issuing a + RELEASE/WITHDRAW message. + +7.3.3. Notify Message Procedures + + Intermediate and egress nodes may trigger the setting of + administrative status before a deletion via the use of REQUEST + messages. To accomplish this, an intermediate or egress node + generates a REQUEST message with the modification action indicator + set to modify and with the corresponding upstream. The Admin Status + TLV MUST be included in the message, with the Down (D) bit set. + + An ingress node receiving a MAPPING message containing an Admin + Status TLV with the Down (D) bit set, SHOULD initiate the deletion + procedure described in the previous section. + +8. Control Channel Separation + + This section provides the protocol specific formats and procedures to + required support a control channel not being in-band with a data + channel. + +8.1. Interface Identification + + The choice of the data interface to use is always made by the sender + of the REQUEST message. The choice of the data interface is indicated + by the sender of the REQUEST message by including the data channel's + interface identifier in the message using a new Interface TLV. type. + For bidirectional LSPs, the sender chooses the data interface in each + direction. In all cases but bundling [MPLS-BUNDLE] the upstream + interface is implied by the downstream interface. For bundling, the + path sender explicitly identifies the component interface used in + each direction. + The format of Interface ID in REQUEST, MAPPING Messages 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| Type (TBA by IANA) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Interface ID TLVS see [GMLPS-SIG] | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The U Bit Should be set to 0. The F bit should be set to 0. + + See [GMPLS-SIG] for a description of parameters. + + See [CR-LDP] for a description of signaling address. See [GMPLS-SIG] + for a description of parameters and encoding of TLVs. + +8.2. Procedures + + An IF_ID TLV is used on links where there is not a one-to- one + association of a control channel to a data channel, see [GMPLS- SIG]. + + The LDP session uses the IF_ID TLV to identify the data channel(s) + associated with the LSP. For a unidirectional LSP, a forward channel + MUST be indicated. For a bidirectional LSP that use bundled links, a + reverse channel MUST be indicated. Data channels are specified from + the viewpoint of the sender of the REQUEST message. + +9. Fault Handling + + In optical transport networks, failures in the out-of-fiber signaling + communication or optical control plane should not have service impact + on the existing optical connections. Under such circumstances, a + mechanism MUST exist to detect a signaling communication failure and + a recovery procedure SHALL guarantee connection integrity at both + ends of the signaling channel. + + The LDP Fault tolerant draft [LDP-FT] specifies the procedures for + recovering LDP and CR-LDP sessions under failure. Please refer to + this draft for procedures on recovering optical connections. + Currently the Fault tolerant draft covers many of the common failure + modes for a separated control and data plane. + +10. Acknowledgments 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 the drafts from which material and ideas were incorporated follows: draft-saha-rsvp-optical-signaling-00.txt draft-lang-mpls-rsvp-oxc-00.txt draft-kompella-mpls-optical-00.txt draft-fan-mpls-lambda-signaling-00.txt Valuable comments and input were received from a number of people, notably Adrian Farrel. -8. Security Considerations +11. Security Considerations This draft introduce no new security considerations to [CR-LDP]. -9. References +12. References [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", draft-ietf-mpls-cr-ldp-05.txt, Feb., 2001. [MPLS-HIERARCHY] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS TE", Internet Draft, draft-ietf-mpls-lsp-hierarchy-02.txt, Feb., 2001. [MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links in CR-LDP", Internet Draft, draft-ietf-mpls-crldp-unnum-01.txt, February 2001 @@ -519,33 +698,37 @@ [GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - RSVP-TE Extensions", Internet Draft, draft-ietf-mpls-generalized-rsvp-te-01.txt, February 2001. [GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS - Signaling Functional Description", Internet Draft, draft-ietf-mpls-generalized-signaling-02.txt, February 2001. +[LDP-FT] Farrel, A. et al, "Fault Tolerance for LDP + and CR-LDP", Internet Draft, + draft-ietf-mpls-ldp-ft-02.txt, + February 2001. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119. -10. Authors' Addresses +13. Authors' Addresses 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 @@ -560,27 +743,35 @@ Cupertino, CA 94014 Phone: +1 408 366 4713 Email: greg@ciena.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. 100 Nickerson Road Marlborough, MA 01752 Phone: +1 508 460 6969 Ext. 627 Email: yfan@axiowave.com + Don Fedyk + Nortel Networks Corp. + 600 Technology Park + Billerica MA 01821 + Phone: +1 978 288 3041 + Fax: +1 978 288 0620 + Email: dwfedyk@nortelnetworks.com Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089 Email: kireeti@juniper.net Jonathan P. Lang Calient Networks 25 Castilian Goleta, CA 93117 @@ -632,11 +823,11 @@ Z. Bo Tang Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Phone: +1 732 923 4231 Fax: +1 732 923 9804 Email: btang@tellium.com -Generated on: Tue May 1 16:25:40 EDT 2001 +Generated on: Fri Jul 20 16:49:49 EDT 2001