idnits 2.17.1 draft-fredette-lmp-wdm-00.txt: 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: ---------------------------------------------------------------------------- == 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 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([LMD00]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (December 2000) is 8531 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) == Unused Reference: 'CBD00' is defined on line 546, but no explicit reference was found in the text == Unused Reference: 'DBC00' is defined on line 552, but no explicit reference was found in the text == Unused Reference: 'KRB00' is defined on line 558, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ceuppens-mpls-optical-00 -- Possible downref: Normative reference to a draft: ref. 'CBD00' -- Possible downref: Non-RFC (?) normative reference: ref. 'DBC00' == Outdated reference: A later version (-05) exists of draft-kompella-mpls-bundle-02 -- Possible downref: Normative reference to a draft: ref. 'KRB00' == Outdated reference: A later version (-02) exists of draft-ietf-mpls-lmp-00 -- Possible downref: Normative reference to a draft: ref. 'LMD00' -- Possible downref: Non-RFC (?) normative reference: ref. 'SDH' -- Possible downref: Non-RFC (?) normative reference: ref. 'SONET' Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Fredette, E. Snyder, J. Shantigram 2 Internet Draft (PhotonEx Corp) 3 Expiration Date: June 2001 4 J. Lang, J. Drake, G. Tumuluri 5 (Calient Networks) 7 R. Goyal, S. Brorson, R. Krishnan 8 (Axiowave Networks) 10 W. L. Edwards 11 (iLambda Networks) 13 Y. Xue 14 (UUNET/WorldCom) 16 J. Yu 17 (Zaffire, Inc) 19 December 2000 21 Link Management Protocol (LMP) for WDM Transmission Systems 22 draft-fredette-lmp-wdm-00.txt 24 STATUS OF THIS MEMO: 26 This document is an Internet-Draft and is in full conformance with 27 all provisions of Section 10 of RFC2026 [Bra96]. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as 32 Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 Abstract 47 A suite of protocols is being developed in the IETF to allow 48 networks consisting of photonic switches (PXCs), optical 49 crossconnects (OXCs), routers, switches, DWDM transmission systems, 50 and optical add-drop multiplexors (OADMs) to use an MPLS control 51 plane to dynamically provision resources and to provide network 52 survivability using protection and restoration techniques. As part 53 of this suite, the Link Management Protocol (LMP) [LMD00] is defined 54 to "maintain control channel connectivity, verify component link 55 connectivity, and isolate link, fiber, or channel failures within 56 the network." In it's present form, [LMD00] focuses on OXC-to-OXC 57 communications. In this document we propose extensions to LMP for 58 use with DWDM transmission systems. 60 1. Introduction 62 Future networks will consist of photonic switches (PXCs), optical 63 crossconnects (OXCs), routers, switches, DWDM transmission systems, 64 and optical add-drop multiplexors (OADMs) that use the MPLS control 65 plane to dynamically provision resources and to provide network 66 survivability using protection and restoration techniques. A pair 67 of nodes (e.g., a PXC and a DWDM system) may be connected by 68 thousands of fibers. Furthermore, multiple fibers and/or multiple 69 wavelengths may be combined into a single bundled link. [LMD00] 70 Defines the Link Management Protocol (LMP) to "maintain control 71 channel connectivity, verify component link connectivity, and 72 isolate link, fiber, or channel failures within the network." In 73 it's present form, [LMD00] focuses on OXC-to-OXC communications as 74 illustrated in Figure 1. In this document, extensions to LMP for 75 use with DWDM transmission systems are proposed. It is assumed that 76 the reader is familiar with LMP as defined in [LMD00]. 78 +------+ +------+ +------+ +------+ 79 | | ----- | | | | ----- | | 80 | OXC1 | ----- | WDM1 | ===== | WDM2 | ----- | OXC2 | 81 | | ----- | | | | ----- | | 82 +------+ +------+ +------+ +------+ 83 ^ ^ 84 | | 85 +----------------------LMP----------------------+ 87 Figure 1: Current LMP Model 89 A great deal of information about a link between two OXCs is known 90 by the DWDM transmission system. Exposing this information to the 91 control plane via LMP can improve network usability by further 92 reducing required manual configuration and also greatly enhance 93 fault detection and recovery. Fault detection is particularly an 94 issue when the network is using all-optical photonic switches or 95 photonic crossconnects (PXCs). Once a connection is established, 96 PXCs have only limited visibility into the health of the connection. 97 Even though the PXC is all-optical, long-haul DWDM transmission 98 systems typically terminate channels electrically, then regenerates 99 them optically which presents an opportunity to monitor the health 100 of a channel between PXCs. 102 The model for extending LMP to WDM transmission systems is shown in 103 Figure 2. 105 +------+ +------+ +------+ +------+ 106 | | ----- | | | | ----- | | 107 | OXC1 | ----- | WDM1 | ===== | WDM2 | ----- | OXC2 | 108 | | ----- | | | | ----- | | 109 +------+ +------+ +------+ +------+ 110 ^ ^ ^ ^ ^ ^ 111 | | | | | | 112 | +-----LMP-----+ +-----LMP----+ | 113 | | 114 +----------------------LMP----------------------+ 116 Figure 2: Extended LMP Model 118 In this model an OXC establishes LMP sessions with neighboring 119 transmission systems as well as with its neighboring OXCs. The 120 OXC-OXC LMP sessions are managed essentially the same as described 121 in [LMD00]. Although there are many similarities between OXC-OXC 122 LMP and OXC-WDM LMP, particularly for control management and link 123 verification, there are some significant differences as well. These 124 differences can primarily be attributed to the nature of an OXC-WDM 125 link, and the purpose of OXC-WDM LMP sessions. The OXC-OXC links 126 provide the basis for routing circuits at the optical layer. The 127 information exchanged over LMP sessions between an OXC and WDM 128 transmission system is used to augment knowledge about the links 129 between OXCs. 131 The organization of link bundles must be the same for the OXC-OXC 132 LMP session as well as for the OXC-WDM LMP sessions. Note that a 133 side-effect of this requirement is that a link bundle can span at 134 most one WDM system if LMP is being used. In order for the 135 information exchanged over the OXC-WDM LMP sessions to be used by 136 the OXC-OXC session and vice-versa, a relationship must be 137 maintained between the sessions. For a given OXC-OXC LMP session, 138 there are one or more related (child) OXC-WDM LMP sessions (at least 139 one per WDM transmission system connecting the OXCs). The LMP 140 session on the OXC is responsible for maintaining the relationship 141 between the parent session and its children. It may be possible for 142 the OXC to use the same CCid for OXC-OXC communications as well as 143 OXC-WDM communications, but this needs some further thought. The 144 OXC must also provide a session ID for the parent LMP session to the 145 WDM system so that it can be knowledgeable about this relationship. 147 The session ID can be created by concatenating the CCids from the 148 two OXCs. 150 It should be possible for the LMP sessions to come up in any order 151 and synchronize as new sessions come up. In particular, it should 152 be possible for the OXC-OXC session to come up without a WDM session 153 as LMP is defined today. In case of control channel failure, one or 154 both of the control channels may fail, and the failures may be 155 unrelated to each other. In case of component link failure, failure 156 of OXC-WDM link should imply failure of OXC-OXC link, and vice versa. 158 Additional details about the extensions required for LMP are 159 outlined in the next section. 161 2. LMP Extensions for WDM Transport Systems 163 As currently defined, LMP consists of four types of functions: 165 1. Control Channel Management 166 2. Link Verification 167 3. Link Summarization 168 4. Fault Localization 170 Extended LMP has these same basic functional categories with the 171 addition of performance summarization/notification as follows: 173 1. Control Channel Management 174 2. Link Verification 175 3. Link Summarization 176 4. Performance Summarization 177 5. Fault Localization 179 The first two functions, control channel management and link 180 verification, are concerned with OXC-WDM links, and are nearly the 181 same as those for OXC-OXC links. 183 It is very important to understand the subtle distinctions between 184 the different types of links being considered in the extended LMP. 185 For example, in Figure 2 when OXC1 and OXC2 complete the verify 186 process, the links being verified are the end-to-end links between 187 the OXC's. It is these "component links" (or a bundle thereof) that 188 are advertised in the routing protocols and used for the purposes of 189 connection setup. The verify between OXC1 and WDM1, on the other 190 hand verifies the shorter link between these two nodes. However, 191 each of these shorter links is a segment of one of the larger 192 end-to-end component links. The verify serves two functions. The 193 first is to verify connectivity. The second is to agree upon 194 handles by which to refer to each component link (the LinkID). So, 195 although the OXC-WDM verify only runs over the shorter link, the 196 LinkID is used to refer to the larger end-to-end component link. In 197 particular, the WDM system uses the LinkID to report on the 198 end-to-end component link in Link Summarization, Performance 199 Summarization, and Fault Localization. 201 Once a control channel has been established and its associated 202 WDM-OXC links are verified, the OXC and WDM transmission system may 203 exchange information regarding link configuration and/or performance 204 characteristics (link/performance summarization). An OXC may also 205 receive notifications from a WDM transmission system 206 (performance/fault notification). It is noted again that these 207 functions are concerned with the associated OXC-OXC links, not the 208 OXC-WDM links themselves. 210 In subsequent sections, specific changes are proposed to extend LMP 211 to work with WDM transmission systems. 213 2.1. Control Channel Management 215 The control channel management for OXC-WDM links is the same as for 216 OXC-OXC links, as described in [LMD00]. It may be useful to include 217 a "node type" or "protocol sub-type" identifier in the initial 218 HelloConfig messages so that an OXC may differentiate between 219 another OXC and a WDM transmission system. 221 2.2. Link Verification 223 The basic test procedure used with WDM transmission systems is the 224 same as described in [LMD00]. The VerifyTransportMechanism and 225 possibly the VerifyID parameters are added to the protocol as 226 described below. 228 [LMD00] requires that "a free (unallocated) component link must be 229 opaque (i.e., able to be terminated)". While this requirement may 230 be reasonable for cross-connects, it is not practical for most 231 transmission systems. When used with SONET or SDH access equipment, 232 the Section Trace (J0) overhead is used for the purpose of link 233 verification. For both SONET and SDH, the section trace message 234 consists of a string of 7-bit characters (i.e., ASCII) terminated by 235 a frame delimiter. SONET uses a 64 octet string (62 octets of data 236 with a CR-LF frame delimiter) [SONET], while SDH uses a 16 octet 237 string (15 octets of data with a CRC-7 frame delimiter) [SDH]. It 238 is proposed that 15 octets or fewer be used for the Test message so 239 that the same basic format is used for both SONET and SDH links. 241 A VerifyTransportMechanism is added to the BeginVerify and 242 BeginVerifyAck messages. The purpose for this new parameter is to 243 allow nodes to negotiate a link verification method. In particular, 244 it allows a transmission system to tell an OXC to use the section 245 trace overhead instead of a terminated link. Additional 246 VerifyTransportMechanism types may be added for new types of 247 connections in the future, if necessary. The verifying node 248 includes the VerifyTransportMechanism parameter in the BeginVerify 249 message to indicate all supported methods (e.g., link termination, 250 SONET Section Trace, or SDH Section Trace). 252 In the verify protocol of the current LMP, information including the 253 CCid is included in the the test message that allows the node being 254 verified to uniquely identify the source of each test message. It 255 needs to be determined whether this information can be encoded in 256 the limited payload space available in the SDH section trace message 257 (15 7-bit characters). 259 An alternate solution may be for the remote node provides a VerifyID 260 to the local node in the BeginVerifyAck Message. The Test message 261 can then be created by concatenating the VerifyID and the LinkID. 262 The VerifyID allows a node to differentiate test messages from 263 different LMP peers in the absence of the CCid. 265 2.3. Link Summarization 267 The LinkSummary message is extended to advertise link 268 characteristics. The specific link characteristics to be advertised 269 is still TBD; however, they should, in general, be those 270 characteristics needed by the control plane for constraint-based 271 routing and connection establishment. Additionally, the 272 characteristics advertised in the LinkSummary message are intended 273 to be more-or-less static characteristics as opposed to the more 274 dynamic ones advertised in the PerformanceSummary message described 275 below. 277 For the purpose of discussion, the following characteristics are 278 listed as potential candidates. In general these characteristics 279 are advertised on a per component link basis. However, it may also 280 be useful to advertise per fiber, per bundle, or per component link. 281 Also some make sense for the case of transparent all-optical 282 wavelength routing and some make sense for opaque channels that are 283 terminated electrically at the transmission system. 285 Potential Link Characteristics: 287 1. Wavelength Channel Count: 289 Number of independent wavelengths Carried 291 2. Total wavelengths carried (Information is carried on a 292 per-channel basis.): 294 Table of all wavelengths which can be supported. For each 295 wavelength, information should include: 297 - Allocated or Free 298 - Port 299 - Section trace or ID (J0) 300 - Timing source/quality (S1) 301 - Wavelength 302 - Wavelength Band (C- L- or S-Band) 303 - Bit rate. For multiple rate cards list all possible bit 304 rates. For transparent optical card, list "transparent" 305 - Protocol/framing (SONET, 10GigE, OCh) 306 - FEC if any 307 - BER estimate (quality of the link) 308 - Drop side interface type. 309 - Laser output power on drop side. 310 - Laser output power on line side. 311 - Receiver sensitivity (dynamic range) on drop side. 312 - Receiver sensitivity on line side. 313 - Availability of protection, i.e. Is SONET APS possible on 314 this wavelength? Protection type and QoS (e.g. None, SONET 315 1+1, SONET 1:1, Optical layer switching, pre-emptable 316 lightpath, etc.) 318 3. Transparent optical span length: 320 Distance of fiber between Tx and Rx. Used to make estimates of 321 attenuation and dispersion until next regen. Note that this 322 parameter applies to all wavelengths. 324 4. Span Loss: 326 Span loss between Tx and Rx in dB Tx power, span attenuation, 327 and Rx sensitivity is used in constraint-based routing on 328 physical layer. Note that this parameter applies to all 329 wavelengths. 331 5. Fiber Type: 333 Type of the fiber used in the span (DCF or not etc.) Fiber type 334 and span length is used to estimate dispersion penalty. Note 335 that this parameter applies to all wavelengths. 337 6. Fiber characteristics: 339 PMD, Dispersion, Loss etc. Theoretically used to estimate 340 penalty for constraint-based routing. It is possible that the 341 service providers have no accurate data for this field. 343 7. Optical amplifier data for link/span: 345 Type and number of amplifiers Used to estimate OSNR over link. 347 8. Performance Monitoring Capability: 349 Whether OPM is used and if so, what is monitored and can the 350 information be shared with other network elements. 352 9. OEO Regenerator Data for link/span 354 Number and type of regenerators present in the link/span Used to 355 estimate optical quality of link. 357 10. Regen and Amp Spacing/Locations 359 How far apart are the Regens and Amps 361 11. Signaling Format: 363 RZ, NRZ 365 12. Shared Risk Link Group Identifier: 367 What shared risk link groups exist (manually configured on the 368 DWDM systems by the service providers) Used for diverse path 369 computation. 371 13. Channel Spacing, 373 14. Spectral Bandwidth of Each Channel 375 2.4. Performance Summarization 377 A new type of message is added to LMP to advertise performance 378 monitoring (PM) information that is available within the WDM 379 transmission system. PM information is different from link 380 characteristics in that it is more dynamic in nature. 382 PM information should be advertised for one of several reasons: 383 - For use in ascertaining a QoS level of a link for routing purposes 384 - To predict likely or impending failure so that a connection can 385 be rerouted proactively. (E.g., exceeding an uncorrected BER 386 threshold even though the corrected BER is adequate.) 387 - To quickly detect a failed link. 389 This information can be used to allow the system to reroute 390 connections proactively to avert potential failures, and so that 391 problems can be diagnosed. 393 As in the case of link characteristics, specific items still require 394 further investigation. Some of the performance measures under 395 consideration for Optical Performance Monitoring are listed below: 397 1. Dispersion (chromatic and polarization mode): 399 The distortion or spreading of bits due to variations in 400 propagation velocity of different wavelengths and polarization 401 modes in the fiber and other network elements. 403 2. Optical signal-to-noise ratio (OSNR): 405 The ratio of optical power in a primary data channel to the 406 power in optical background noise accumulated during 407 transmission and switching. This ratio is usually specified 408 within some optical bandwidth of a receiver filter. The OSNR of 409 a channel at the destination receiver will set the limit of the 410 final detected SNR. 412 3. Bit-rate: 414 The data rate of the channel in a transparent system will be 415 necessary to make decisions on other performance metrics. 417 4. Q-Factor: 419 A measure of the signal-to-noise ratio (SNR) assuming Gaussian 420 noise statistics. 422 5. Wavelength registration: 424 The determination of which wavelengths are present on a given 425 fiber. 427 6. Wavelength selective component drift: 429 The drift of a laser, filter, mux or other wavelength selective 430 component relative to the ITU grid. 432 7. Optical cross talk: 434 Two types of cross talk are of interest, in-band and 435 out-of-band. In-band cross talk is seen as at the same 436 wavelength as the primary channel and appears as cross talk in 437 the electronic domain. Out-of-band cross talk appears as a 438 different wavelength in the presence of the primary wavelength 439 and appears as cross talk in the optical domain. 441 8. Optical power transients: 443 Changes in the optical powers that are not due to normal bit 444 transitions. May be due to optical amplifier gain transients or 445 other transient non-linearity in the system. 447 9. Bit-error-rate: 449 In a SONET environment BER can be directly measured on the 450 channel using means to look at bits within the data stream. 451 However, in a purely photonic network there will typically not 452 be access to the data streams carried over the channel. However, 453 by interpreting the other optical parameters, the system should 454 be able to estimate the BER with relatively good accuracy, as 455 well as guarantee bit error rate performance to the users of the 456 channel. 458 10. Jitter: 460 Random fluctuations in the location of rising and falling edges 461 of bits relative to a local or recovered clock reference. As 462 line speeds continue to increase, jitter will become a critical 463 performance parameter. 465 11. Insertion loss: 467 Indicates the input to output loss of a network element. When 468 examining excessive power loss along the path of a channel the 469 ability to measure insertion loss of individual network elements 470 is very useful, specifically when compared against an archival 471 database. 473 12. Optical power level 475 In addition to OPM measures, the transmission systems may exchange 476 SONET (OEO) monitoring information with the photonic switches, if 477 such information is available. Requirements for PM in SONET are 478 given in GR-253-CORE and some discussion of PM is also included in 479 G.874. PM parameters shall be gathered and reported over two time 480 intervals: 15-minute intervals and 24-hour intervals. The list given 481 below is a subset of the parameters listed in GR-253-CORE, and is 482 intended to be a minimal list required for making routing decisions. 483 Naturally, one also could implement the entire suite of SONET PM 484 parameters if one wanted to. 486 The following parameters should be reported on a per-component link 487 basis: 489 1. BER 491 Collected via B1 error count 493 2. SES 495 Severely errored seconds. Collected via B1 error count. Used to 496 collect statistics on burst errors. 498 3. Protection switch counts 500 Number of protection switch events during the count interval. 501 Provides an indication of possible link problems. If protection 502 switch chattering is occurring, the link is bad. 504 4. STS pointer justifications 506 Number of times the SONET SPE pointer needed to be justified. 507 Provides an indication of the clocking accuracy over the optical 508 link. 510 2.5. Fault Localization 512 Fault localization consists of three major functions: 514 1. Fault Detection 515 2. Fault Notification 516 3. Fault Localization 518 The actual Fault Detection mechanisms are the responsibility of the 519 individual nodes and are not specified as part of this protocol. 520 Fault detection mechanisms may include such things as bit error rate 521 (BER) exceeding a threshold, loss of signal (LOS) and certain 522 SONET-level errors. 524 The fault notification and localization procedure is essentially the 525 same as in the current version of LMP, however, it is executed at 526 two levels in the extended LMP. 528 OXCs continue to execute the OXC-to-OXC fault localization as 529 currently specified. The main difference is that the WDM system may 530 initiate the process (both downstream and upstream). The WDM system 531 will also execute its own fault localization process that may allow 532 it to determine the location of the fault much more specifically 533 than the OXCs can. For example, the WDM transmission system may be 534 able to pinpoint the fault to a particular amplifier along a set of 535 fibers that can span 1000's of kilometers. 537 3. Security Considerations 539 The security considerations will be the same as in [LMD00]. 541 4. References 543 [Bra96] Bradner, S., "The Internet Standards Process -- Revision 544 3," BCP 9, RFC 2026, October 1996. 546 [CBD00] Ceuppens, L., Blumenthal, D., Drake, J., Chrostowski, J., 547 Edwards, W. L., "Performance Monitoring in Photonic 548 Networks in Support of MPL(ambda)S", Internet Draft, 549 draft-ceuppens-mpls-optical-00.txt, (work in progress), 550 March 2000. 552 [DBC00] Drake, J., Blumenthal, D., Ceuppens, L., et al., 553 "Interworking between Photonic (Optical) Switches and 554 Transmission Systems over Optical Link Interface (OLI) 555 using Extensions to LMP", OIF Contribution oif2000.254, 556 (work in progress), November 2000. 558 [KRB00] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in 559 MPLS Traffic Engineering," Internet Draft, 560 draft-kompella-mpls-bundle-02.txt, (work in progress), 561 July 2000. 563 [LMD00] Lang, J., Mitra, K., Drake, J., Kompella, K., Rekhter, 564 Y., Berger, L., Saha, D., Basak, D., Sandick, H., "Link 565 Management Protocol (LMP)", Internet Draft, 566 draft-ietf-mpls-lmp-00.txt, (work in progress), September 567 2000. 569 [SDH] ITU-T G.707, "Network node interface for the synchronous 570 digital hierarchy (SDH)", 1996. 572 [SONET] GR-253-CORE, "Synchronous Optical Network (SONET) 573 Transport Systems: Common Generic Criteria", Telcordia 574 Technologies, Issue 3, September 2000 576 [T.50] ITU-T T.50, "International Reference Alphabet (IRA) 577 (formerly International Alphabet No. 5 or IA5) 578 Information technology 7-bit coded character set for 579 information interchange.", 1992. 581 5. Author's Addresses 583 Andre Fredette Ed Snyder 584 PhotonEx Corporation PhotonEx Corporation 585 8C Preston Court 8C Preston Court 586 Bedford, MA 01730 Bedford, MA 01730 587 email: fredette@photonex.com email: esnyder@photonex.com 589 Jagan Shantigram Jonathan P. Lang 590 PhotonEx Corporation Calient Networks 591 8C Preston Court25 Castilian Drive 592 Bedford, MA 01730 Goleta, CA 93117 593 email: jagan@photonex.com email: jplang@calient.net 595 John Drake Gopala Tumuluri 596 Calient Networks Calient Networks 597 5853 Rue Ferrari 5853 Rue Ferrari 598 San Jose, CA 95138 San Jose, CA 95138 599 email: jdrake@calient.net email: krishna@calient.net 601 Rohit Goyal Stuart Brorson 602 Axiowave Networks Axiowave Networks 603 100 Nickerson Road 100 Nickerson Road 604 Marlborough, MA 01752 Marlborough, MA 01752 605 email: rgoyal@axiowave.com email: sdb@axiowave.com 607 Ram Krishnan W. L. Edwards 608 Axiowave Networks iLambda Networks 609 100 Nickerson Road Aspen, CO 610 Marlborough, MA 01752 email: texas@ilambda.com 611 email: ram@axiowave.com 613 Yong Xue John Yu 614 UUNET/WorldCom Zaffire, Inc 615 22001 Loudoun County Parkway 2630 Orchard Parkway 616 Ashburn, VA 20148 San Jose, CA 95134 617 email: yxue@uu.net email: jzyu@zaffire.com