idnits 2.17.1 draft-ietf-ccamp-oli-reqts-00.txt: -(183): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(489): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(500): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(513): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 22 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2002) is 8106 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'GMPLS-RSVP' is mentioned on line 253, but not defined == Unused Reference: 'LMP-WDM' is defined on line 508, but no explicit reference was found in the text == Unused Reference: 'NTIP' is defined on line 513, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'GMPLS-ARCH' == Outdated reference: A later version (-19) exists of draft-ietf-isis-gmpls-extensions-02 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-gmpls-extensions (ref. 'GMPLS-ISIS') == Outdated reference: A later version (-07) exists of draft-ietf-mpls-generalized-cr-ldp-01 == Outdated reference: A later version (-02) exists of draft-kompella-ospf-gmpls-extensions-01 -- Possible downref: Normative reference to a draft: ref. 'GMPLS-OSPF' == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-02 -- Possible downref: Normative reference to a draft: ref. 'LMP' == Outdated reference: A later version (-03) exists of draft-fredette-lmp-wdm-01 -- Possible downref: Normative reference to a draft: ref. 'LMP-WDM' == Outdated reference: A later version (-01) exists of draft-sahay-ccamp-ntip-00 -- Possible downref: Normative reference to a draft: ref. 'NTIP' Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Andre Fredette (Editor) 3 Internet Draft 4 Expiration Date: August 2002 Osama Aboul-Magd (Nortel Networks) 5 Curtis Brownmiller (WorldCom) 6 Sudheer Dharanikota (Nayna Networks) 7 Naganand Doraswamy (PhotonEx Corp.) 8 John Drake (Calient Networks) 9 Georgios Ellinas (Tellium) 10 Rohit Goyal (Axiowave Networks) 11 Riad Hartani (Caspian Networks) 12 Bilel Jamoussi (Nortel Networks) 13 John Labourdette (Tellium) 14 Jonathan Lang (Calient Networks) 15 Eric Mannie (Ebone (GTS)) 16 Babu Narayanan (Nortel Networks) 17 Dimitri Papadimitriou (Alcatel IPO-NSG) 18 Bala Rajagopalan (Tellium) 19 Rajiv Ramaswami (Nortel Networks) 20 Vasant Sahay (Nortel Networks) 21 Ed Snyder (PhotonEx Corp.) 22 Yong Xue (UUNET/WorldCom) 24 February 2002 26 TITLE: Optical Link Interface Requirements 28 draft-ietf-ccamp-oli-reqts-00.txt 30 Status of this Memo 32 This document is an Internet-Draft and is in full conformance with 33 all provisions of Section 10 of RFC2026 [RFC2026]. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six 41 months and may be updated, replaced, or obsoleted by other documents 42 at any time. It is inappropriate to use Internet- Drafts as 43 reference material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/ietf/1id-abstracts.txt 48 The list of Internet-Draft Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html. 51 ABSTRACT 52 The emergence of transparent optical switches, together with a 53 movement towards more dynamic, multi-vendor networks, has introduced 54 a need for information sharing between optical line systems and 55 client devices. The information that needs to be shared includes 56 link status and link properties. We call this interface the Optical 57 Link Interface (OLI). In this document, we provide high-level 58 requirements for the OLI. 60 CONTENTS 61 ABSTRACT...........................................................2 62 CONTENTS...........................................................2 63 1. Introduction and Overview.......................................3 64 2. Fault Detection and Notification for PXCs.......................5 65 3. Discovery of Link Properties....................................5 66 4. Requirements for the Optical Link Interface.....................6 67 4.1. OLI General Principles........................................6 68 4.2. General OLI Characteristics...................................7 69 4.3. OLI Functionality.............................................7 70 4.3.1. Neighbor Discovery..........................................7 71 4.3.2. Control Channel Maintenance.................................8 72 4.3.3. OLI Synchronization.........................................8 73 4.3.4. Connectivity Discovery......................................8 74 4.3.5. Fault Management............................................8 75 4.3.5.1. Fault Notification........................................9 76 4.3.5.2. Trace Monitoring..........................................9 77 4.3.5.3. Alarm Suppression........................................10 78 4.3.6. Link Property Information..................................10 79 5. References.....................................................12 80 6. Author Contact Information.....................................13 82 1. Introduction and Overview 84 Optical networks being deployed today consist of the following three 85 basic types of devices: service delivery platforms (e.g., routers, 86 ATM switches, and SONET/SDH devices), optical switches (OXCs), and 87 Optical Line Systems (OLSs), as shown in Figure 1. 89 +-OLI-+ +-OLI-+ 90 | | | | 91 | +-------------------------+ | 92 +----+ |+----+ OLS +----+| +----+ 93 SONET--| |--|| | +---+ +---+ | ||--| |--SONET 94 ATM--|OXC1|--||DWDM|=|Amp|=|Amp|=|DWDM||--|OXC2|--ATM 95 Router��| |--|| 1 | +---+ +---+ | 2 ||--| |--Router 96 | +----+ |+----+ +----+| +----+ | 97 | | | +-------------------------+ | | | 98 | | | | | | 99 +-LMP-+ +---------------LMP---------------+ +-LMP-+ 101 Figure 1: Optical Network 103 Before continuing, a few definitions are provided to describe 104 salient information about the above network. 106 . Opaque Device: 107 A device that terminates a connection electrically. An opaque 108 device is sometimes called an O-E-O device because it receives 109 an optical signal, converts it to an electrical signal, then 110 regenerates a new optical signal. It is also usually must be 111 aware of the type of traffic and bandwidth being carried and 112 has a specific physical interface for that type of traffic and 113 bandwidth. An example is a SONET or SDH device. 115 . Transparent Optical Device: 116 A device that transmits/propagates an optical signal without 117 terminating it. These devices are sometimes referred to as O- 118 O-O devices, because they receive an optical signal, switch it 119 optically, then transmit the same optical signal without ever 120 converting it to an electrical signal. An example is a MEMS- 121 based photonic switch in which both the interfaces and 122 switching fabric are transparent. Transparent devices, in 123 theory, can operate independent of traffic type and bandwidth. 125 . Optical Cross Connect (OXC): 126 A cross connect that switches optical connections. The term 127 OXC is used as a generic term that may apply to both opaque and 128 transparent devices. Whenever the material applies to both 129 opaque and transparent devices, we use the term OXC, as opposed 130 to the more specific PXC term defined below. 132 . Photonic Cross Connect (PXC): 133 A transparent OXC. An example is a MEMS-based photonic switch 134 in which both the interfaces and switching fabric are 135 transparent. Whenever the material in this document applies 136 specifically to transparent devices, we used the term PXC, as 137 opposed to the more generic term OXC defined above. 139 . Optical Line System (OLS): 140 An optical line system is used to transmit data over long 141 distances. There are various classes including long-haul, 142 ultra-long haul, metro, however, we do not differentiate 143 between the classes in this document. Most OLSs being deployed 144 today use wave division multiplexing (WDM), or dense division 145 multiplexing (DWDM) techniques to multiplex many channels over 146 a single pair of fibers. Therefore, the OLS is also commonly 147 referred to as a DWDM transmission system. An OLS typically 148 contains multiple types of nodes including DWDM and Optical 149 Amplifier (OA) nodes. Although an OLS contains multiple nodes, 150 they work as a single system, and for the purposes of this 151 document, we treat the OLS as a single system. Note that an 152 OLS may be either opaque or transparent, however, in this 153 document we only address opaque OLSs. 155 . OLS Client: 156 Any device that attaches to an OLS for the purpose of using its 157 data transmission services. An OLS client may be either opaque 158 or transparent. In Figure 1, the OXC is shown as an OLS client 159 with the service delivery platforms connected to the OXC; 160 however, the service delivery platforms may also be direct OLS 161 clients. Whenever the material in this document applies to any 162 OLS client, we use this most general term. 164 . Link: 165 The term link refers to a circuit or logical connection between 166 two peer OLS clients. The OLS transmits the data on a link 167 between the two peer OLS clients. A link may be uni- 168 directional or bi-directional. 170 . Port: 171 Place where an OLS client attaches to an OLS. A link requires 172 that both OLS clients are attached to corresponding ports on 173 the OLS. 175 This work is motivated by two main issues. The first is the need to 176 enhance the fault detection and recovery support for PXCs, and the 177 second is to enhance the discovery of link characteristics for 178 optical networks in general. These issues are discussed separately 179 below. We then provide more specific requirements for an interface 180 between the OLS and OLS client proposed to solve these issues called 181 the Optical Link Interface (OLI). 183 DISCLAIMER: The name �OLI�, introduced in [OIF2000.254], has been 184 chosen due to the lack of a better name at this time. Not all of 185 the co-authors agree on the name OLI. 187 2. Fault Detection and Notification for PXCs 189 Standard SONET/SDH equipment provides extensive fault detection, 190 reporting and handling capabilities. These SONET/SDH standards can 191 be employed by opaque devices using SONET/SDH overhead messaging; 192 however, as networks transition to the use of more transparent 193 optical networking devices, such as PXCs, access to the SONET/SDH 194 overhead may not exist in every node. Once a connection is 195 established, PXCs have only limited visibility into the health of 196 the connection. Even though the PXC is all-optical, an opaque OLS 197 terminates channels electrically and regenerate them optically, 198 which presents an opportunity to monitor the health of a channel 199 between PXCs. The elements of an OLS also typically communicate 200 over an internal control channel. This can provide a system wide 201 view of OLS client-to-client link health. In a sense, the OLI 202 allows the OLSs to become the �eyes and the ears� of the PXC. 204 The typical OLS located between a pair of PXCs monitors for 205 degradation and faults along the entire fiber path. Expensive 206 electronic circuitry monitors such degradations at the SONET/SDH and 207 wavelength level at various points along the fiber path. Repeaters 208 and Amplifiers detect fiber cuts and pass along the information to 209 other equipment along the path. SONET/SDH-level failures can be 210 detected as well. To use the SONET/SDH-level fault reporting 211 methods, all devices require the expensive electronic circuitry. A 212 PXC can avoid the use of SONET/SDH circuitry to provide a more cost 213 effective solution. In this perspective, an OLI between the OLS and 214 PXC can provide the same fault information to a non-SONET/SDH 215 client, while reducing the cost of that client, and, therefore 216 overall network cost. 218 3. Discovery of Link Properties 220 The establishment of connections in an optical network may be 221 accomplished either through a centralized management system or a 222 distributed control system, such as GMPLS. 224 A great deal of information about a link between two clients is 225 known by the OLS. Exposing this information to the control plane 226 can improve network usability by further reducing required manual 227 configuration and also greatly enhancing fault detection and 228 recovery. 230 The configuration and management of today�s transport networks are 231 largely driven by significant human intervention, which increases 232 the time to turn up revenue generating services and is prone to 233 errors and inefficiencies. Even where management systems provide 234 automation for some provisioning and management tasks, the 235 management systems are still largely proprietary and cumbersome. 236 Furthermore, optical networks are more commonly being deployed with 237 equipment from multiple vendors which further burdens the user with 238 multiple management systems. A standard interface between the OLS 239 and its clients can simplify the users job by allowing some 240 provisioning functions to be accomplished by just the client 241 management application. 243 The Generalized Multi-protocol Label Switching (GMPLS) body of work 244 [GMPLS-ARCH] is being specified in the IETF to provide a standard 245 automated and distributed IP control plane for optical networks. 246 The use of GMPLS will enable the dynamic provisioning of resources 247 and provide network survivability using protection and restoration 248 techniques. The main intent of GMPLS is to make optical networks 249 more manageable, scalable and efficient, while maintaining or 250 improving on their current high availability characteristics. GMPLS 251 protocols define standard control interfaces between service 252 delivery platforms and OXCs to exchange routing [GMPLS-OSPF, GMPLS- 253 ISIS] and signaling [GMPLS-SIG, GMPLS-RSVP, GMPLS-LDP] information, 254 and perform link management functions [LMP]. An interface with the 255 OLS can allow GMPLS devices to automatically learn information about 256 the links, and therefore, will reduce required manual configuration. 258 4. Requirements for the Optical Link Interface 260 In this section we define more specific requirements for an Optical 261 Link Interface (OLI) between the OLS and its clients. As described 262 above, the OLI is required to provide fast failure detection and 263 notification for PXCs, as well as to provide much-needed information 264 for the operation of both centralized and GMPLS-controlled optical 265 networks. 267 4.1. OLI General Principles 269 . In optical networks there will be a management plane and a 270 control plane. The fundamental purpose of the control plane is 271 to accurately and rapidly create, maintain, and delete 272 connections within the optical network; while the purpose of 273 the management plane is to provide operators with capabilities 274 such as root cause analysis, service definition, and SLA 275 verification. The OLI is targeted at the information that is 276 required for the control plane to accomplish its task. 278 . The OLI should be a simple protocol mechanism for reporting the 279 health and properties of OLSs based on a well-defined set of 280 parameters. 282 . The OLI-defined parameters should be accessible via query by 283 both the control and the management plane of the network 284 regardless of the architecture used (i.e., distributed or 285 centralized). 287 . The OLI should be extensible so that we can start with a set of 288 most-needed parameters initially, and be able to extend later 289 by adding new parameter types and new parameters within a type. 290 In particular, the initial focus is on opaque OLSs. However, 291 the OLS should be extensible for use with all optical networks 292 containing PXCs and transparent OLSs. 294 . The initial focus of the OLI is on SONET and SDH equipment. 295 However, the OLI must be extensible to support other types of 296 equipment such as Ethernet and G.709. 298 . All the intelligence such as data collection, analysis, 299 triggering, routing decisions, etc. should reside in the 300 network control and management plane functions. What and how 301 the OLI-parameters are used is totally up to the control and 302 management plane design. In effect, this will allow OLI to be 303 decoupled from any particular control plane protocol such as 304 GMPLS. 306 . In general, care must be taken to make the OLI implementable on 307 existing OLS hardware, while still being flexible enough to 308 allow enhanced operations with future generations of OLS 309 hardware. This desire may make it necessary to specify some 310 optional OLI features. 312 4.2. General OLI Characteristics 314 . The OLI must be reliable. 316 . The OLI must provide security measures. 318 . The OLI must not assume a one-to-one relationship between OLS 319 and client. I.e., an OLS client will most likely be attached 320 to multiple different OLSs, and a single OLS may have multiple 321 different clients at a single location. 323 4.3. OLI Functionality 325 4.3.1. Neighbor Discovery 326 . It should be possible for adjacent nodes to use the OLI with as 327 little configuration as possible. 329 . The OLI should support discovery and negotiation of optional 330 features. 332 4.3.2. Control Channel Maintenance 334 . The OLI must support the use of out-of-band communications for 335 all messages (except for the specific in-band signals for 336 connectivity discovery described in Section 4.3.4). 337 . The OLI must provide a mechanism to maintain the OLI 338 session/control channel between neighboring nodes. For 339 example, a simple hello or keep-alive protocol could be used. 340 If a session fails it should be reestablished and the 341 information should be resynchronized as described in Section 342 4.3.3. 344 4.3.3. OLI Synchronization 346 . The OLI must specify a process for the OLS and OLS client to 347 resynchronize if the session is disrupted for any reason (such 348 as a reboot or temporary loss of control channel connectivity). 350 . The resynchronization process should be defined such that the 351 OLS does not need to remember the instructions issued by the 352 OLS client. The client should re-issue the 353 instructions/commands to OLS during the resynchronization. 355 4.3.4. Connectivity Discovery 357 . The OLI must provide a protocol including in-band signals for 358 auto discovery of optical connectivity. 360 . The OLI must support control over link transparency. 362 Link transparency control is used by OLS clients to control whether 363 the OLS terminates the in-band messages, or allows them to pass 364 through so that the OLS client can discover its peer at a higher 365 layer. 367 4.3.5. Fault Management 369 . Fault reporting must be both event-driven and available on 370 request (e.g., polling). 372 . The defect notification must be fast enough to support switch 373 times in the range of a few 10�s of milliseconds. 375 Note: The OLS does not participate in end-to-end fault isolation. 377 It is the role of the control plane to determine whether switching 378 is done on the section or path level and to make the protection 379 switching decisions. 381 . The OLI should support the aggregation of fault reporting. For 382 example, the failure of a single fiber could cause the failure 383 of 100�s to 1000�s of ports simultaneously. If possible, it 384 would be better to send a single message to report all 385 failures. 387 4.3.5.1. Fault Notification 389 At a minimum, the following fault granularity must be provided: 391 . Signal Okay (OK): Port is operational. 393 . Signal Fail (SF): A hard signal failure including (but not 394 limited to) loss of signal (LOS), loss of frame (LOF), Line 395 AIS, or a BER (BIP-8 measure through B1/B2) exceeding a 396 specified value. 398 . Signal Degrade (SD): A soft failure caused by a BER exceeding a 399 preselected threshold. The specific BER used to define the 400 threshold is may be configured, but is typically in the range 401 of 10-5 to 10-9. 403 . It should be possible to negotiate a line behavior for the 404 above failures. For example, it may be more advantageous to a 405 PXC for the OLS to turn off its laser than to insert AIS-L when 406 a failure is detected. 408 . It is expected that the thresholds necessary (e.g., BER) for 409 detecting the above failures are provisioned at the OLS. It 410 may also be useful to support the negotiation of some of these 411 thresholds. 413 4.3.5.2. Trace Monitoring 415 Trace monitoring is an important feature, especially for PXCs. The 416 trace monitoring features described in this section, allow the PXC 417 to do basic trace monitoring on circuits by using the capabilities 418 on the attached OLSs 420 . It must be possible for an OLS Client to request the OLS to 421 monitor a link for a specific pattern in the overhead. An 422 example of this overhead is the SONET Section Trace message 423 transmitted in the J0 byte. If the actual trace message does 424 not match the expected trace message, the OLS must report the 425 mismatch condition. 427 . It must be possible for an OLS client to request the value of 428 the current trace message on a given port. 430 . It should be possible for an OLS client to request the OLS to 431 insert a trace message. It is optional for an OLS to provide 432 this service. 434 4.3.5.3. Alarm Suppression 436 . It must be possible to enable a port in an unequipped state on 437 an OLS, but suppress alarms. This allows the OXC to have a 438 port/wavelength ready, but not necessarily operational. 440 4.3.6. Link Property Information 442 The link property advertisement provides information known to 443 transport systems that would otherwise need to be configured at the 444 OLS client. Link properties, in general, constitute the information 445 needed by the control plane for constraint-based routing and 446 connection establishment. Additionally, the information advertised 447 in the Link Property advertisement is intended to be more-or-less 448 static, as opposed to the more dynamic information available in the 449 Performance Information Advertisement described in the next section. 451 The OLI should provide a mechanism for advertising the following 452 information: 454 . Link Descriptor 456 . Signal Type: The overhead termination type (e.g., STM-16 or 457 OC-48). 459 . Bandwidth Encoding: Bandwidth supported on the link. 461 . Shared Risk Link Group Identifier (SRLG): SRLGs to which the 462 link is a member. This information may be manually configured 463 on the OLS by the service providers. It may also be derived 464 based on information known to the OLS (e.g., all circuits 465 sharing a single fiber). The SRLG can be used for diverse path 466 computation. See [GMPLS-OSPF] or [GMPLS-ISIS] for more details 467 on SRLGs. 469 . Span Length: Distance of fiber in the OLS. May be used as a 470 routing metric or to estimate delay. This value may either be 471 estimated by the OLS, or provisioned at the OLS. 473 . Administrative Group (Color). 475 5. References 477 [GMPLS-ARCH] E. Mannie, Editor, �Generalized Multi-Protocol Label 478 Switching (GMPLS) Architecture�, Internet Draft, 479 draft-many-gmpls-architecture-00.txt, (work in 480 progress), February 2001. 482 [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A., Drake, J., 483 Bernstein, G., Fedyk, D., Mannie, E., Saha, D., and 484 Sharma, V., �IS-IS Extensions in Support of 485 Generalized MPLS�, Internet Draft, draft-ietf-isis- 486 gmpls-extensions-02.txt, (work in progress), February 487 2001. 489 [GMPLS-LDP] Ashwood-Smith, P. et al, �Generalized MPLS Signaling - 490 CR-LDP Extensions�, Internet Draft, draft-ietf-mpls- 491 generalized-cr-ldp-01.txt, (work in progress), 492 February 2001. 494 [GMPLS-OSPF] Kompella, K., et. al, �OSPF Extensions in Support of 495 Generalized MPLS�, Internet Draft, draft-kompella- 496 ospf-gmpls-extensions-01.txt, (work in progress), 497 February 2001. 499 [GMPLS-SIG] Berger, L., Ashwood-Smith, Peter, editors, 500 �Generalized MPLS - Signaling Functional Description�, 501 Internet Draft, draft-ietf-mpls-generalized-signaling- 502 02.txt, (work in progress), March 2001. 504 [LMP] Lang, J., et. al, �Link Management Protocol (LMP)�, 505 Internet Draft, draft-ietf-mpls-lmp-02.txt, (work in 506 progress), March 2001. 508 [LMP-WDM] A. Fredette, et al., �Link Management Protocol (LMP) 509 for WDM Transmission Systems,� Internet Draft, draft- 510 fredette-lmp-wdm-01.txt, (work in progress), March 511 2001. 513 [NTIP] V. Sahay et al., �Network Transport Interface Protocol 514 (NTIP) for Photonic Cross Connects (PXC),� Internet 515 Draft, draft-sahay-ccamp-ntip-00.txt, (work in 516 progress), February 2001. 518 [OIF2000.254] Drake, J., Blumenthal, D., Ceuppens, L., et al., 519 �Interworking between Photonic (Optical) Switches and 520 Transmission Systems over Optical Link Interface (OLI) 521 using Extensions to LMP�, OIF Contribution 522 oif2000.254, (work in progress), November 2000. 524 [RFC2026] Bradner, S., "The Internet Standards Process -- 525 Revision 3," BCP 9, RFC 2026, October 1996. 527 6. Author Contact Information 529 Osama Aboul-Magd John Labourdette 530 Nortel Networks Tellium 531 osama@nortelnetworks.com jlabourdette@tellium.com 533 Curtis Brownmiller Jonathan Lang 534 WorldCom Calient Networks 535 Curtis.Brownmiller@wcom.com jplang@calient.net 537 Sudheer Dharanikota Eric Mannie 538 Nayna Networks Ebone (GTS) 539 sudheer@nayna.com Eric.Mannie@ebone.com 541 John Drake Babu Narayanan 542 Calient Networks Nortel Networks 543 jdrake@calient.net bon@nortelnetworks.com 545 Naganand Doraswamy Dimitri Papadimitriou 546 PhotonEx Corp. Alcatel IPO-NSG 547 naganand@photonex.com dimitri.papadimitriou@alcatel.be 549 Georgios Ellinas Bala Rajagopalan 550 Tellium Tellium 551 gellinas@tellium.com BRaja@tellium.com 553 Andre Fredette Rajiv Ramaswami 554 PhotonEx Corp. Nortel Networks 555 fredette@photonex.com rajiv@nortelnetworks.com 557 Rohit Goyal Vasant Sahay 558 Axiowave Networks Nortel Networks 559 rgoyal@axiowave.com vasants@nortelnetworks.com 561 Riad Hartani Ed Snyder 562 Caspian Networks PhotonEx Corp. 563 rhartani@caspiannetworks.com esnyder@photonex.com 565 Bilel Jamoussi Yong Xue 566 Nortel Networks UUNET/WorldCom 567 jamoussi@nortelnetworks.com yxue@UU.NET