idnits 2.17.1 draft-ietf-isis-gmpls-extensions-02.txt: ** The Abstract section seems to be numbered 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? == 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 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. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 205: '...mpatibility, one MAY set the Maximum L...' RFC 2119 keyword, line 231: '...-bearing channel MAY carry low-priorit...' RFC 2119 keyword, line 240: '...-bearing channel MAY carry low-priorit...' 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'LSP-HIER' on line 73 == Unused Reference: '7' is defined on line 459, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-awduche-mpls-te-optical-02 -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-02 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. '3') -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-08) exists of draft-ietf-mpls-lsp-hierarchy-01 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-02 -- Possible downref: Normative reference to a draft: ref. '7' Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Kompella (Juniper Networks) 2 Internet Draft Y. Rekhter (Juniper Networks) 3 Expiration Date: August 2001 A. Banerjee (Calient Networks) 4 J. Drake (Calient Networks) 5 G. Bernstein (Ciena) 6 D. Fedyk (Nortel Networks) 7 E. Mannie (GTS Network) 8 D. Saha (Tellium) 9 V. Sharma (Tellabs) 11 IS-IS Extensions in Support of Generalized MPLS 13 draft-ietf-isis-gmpls-extensions-02.txt 15 1. Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as ``work in progress.'' 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 2. Abstract 38 This document specifies extensions to the IS-IS routing protocol in 39 support of Generalized Multi-Protocol Label Switching (previously 40 known as Multi-Protocol Lambda Switching). 42 3. Introduction 44 This document specifies extensions to the IS-IS routing protocol in 45 support of carrying link state information for Generalized Multi- 46 Protocol Label Switching (GMPLS, previously known as Multi-Protocol 47 Lambda Switching, MPL(ambda)S). For motivations and overall 48 architecture of MPL(ambda)S see [1]. The set of required 49 enhancements to IS-IS are outlined in [2]. This document enhances 50 the routing extensions [3] required to support MPLS Traffic 51 Engineering. Some of these enhancements also need to be carried in 52 the signaling protocols [6]. 54 The organization of the remainder of the document is as follows. In 55 Section 4, we describe the types of links that may be advertised in 56 IS-IS TE LSAs (we call Link State PDUs LSAs to avoid confusion with 57 Label Switched Paths). In Section 5, we define a new set of 58 Type/Length/Value (TLV) triplets, as well as extend a proposed TLV, 59 and describe their formats. 61 4. GMPLS TE Links 63 Traditionally, a TE link is advertised as an adjunct to a "regular" 64 IS-IS link, i.e., an IS-IS adjacency is brought up on the link, and 65 when the link is up, both the regular SPF properties of the link 66 (basically, the SPF metric) and the TE properties of the link are 67 then advertised. 69 However, GMPLS challenges this notion in three ways. First, links 70 that are not capable of sending and receiving on a packet-by-packet 71 basis may yet have TE properties; however, an IS-IS adjacency cannot 72 be brought up on such links. Second, a Label Switched Path can be 73 advertised as a point-to-point TE link (see [LSP-HIER]); thus, an 74 advertised TE link need no longer be between two IS-IS neighbors. 75 Finally, a number of links may be advertised as a single TE link 76 (perhaps for improved scalability), so again, there is no longer a 77 one-to-one association of a regular adjacency and a TE link. 79 Thus we have a more general notion of a TE link. A TE link is a 80 "logical" link that has TE properties, some of which may be 81 configured on the advertising Label Switching Router (LSR), others 82 which may be obtained from other LSRs by means of some protocol, and 83 yet others which may be deduced from the component(s) of the TE link. 84 A TE link between a pair of LSRs doesn't imply the existence of an 85 IS-IS adjacency between these LSRs. A TE link must also have some 86 means by which the advertising LSR can know of its liveness (this 87 means may be IS-IS hellos, but is not limited to IS-IS hellos). When 88 an LSR knows that a TE link is up, and can determine the TE link's TE 89 properties, the LSR may then advertise that link to its (regular) IS- 90 IS neighbors using the TE TLVs. In this document, we call the 91 interfaces over which regular IS-IS adjacencies are established 92 "control channels". 94 [3] defines the canonical TE properties, and says how to associate TE 95 properties to regular (packet-switched) links. This document extends 96 the set of TE properties, and also says how to associate TE 97 properties with non-packet-switched links such as links between 98 Optical Cross-Connects (OXCs). [5] says how to associate TE 99 properties with Label Switched Paths; [4] says how to associate TE 100 properties with a "bundle" of links. 102 4.1. Excluding data traffic from control channels 104 The control channels between nodes in a GMPLS network, such as OXCs 105 (see [1], [2]), SONET cross-connects and/or routers, are generally 106 meant for control and administrative traffic. These control channels 107 are advertised into IS-IS as normal IS links as mentioned in the 108 previous section; this allows the routing of (for example) RSVP 109 messages and telnet sessions. However, if routers on the edge of the 110 optical domain attempt to forward data traffic over these channels, 111 the channel capacity will quickly be exhausted. 113 If one assumes that data traffic is sent to BGP destinations, and 114 control traffic to IGP destinations, then one can exclude data 115 traffic from the control plane by restricting BGP nexthop resolution. 116 (It is assumed that OXCs are not BGP speakers.) Suppose that a 117 router R is attempting to install a route to a BGP destination D. R 118 looks up the BGP nexthop for D in its IGP's routing table. Say R 119 finds that the path to the nexthop is over interface I. R then 120 checks if it has an entry in its Link State database associated with 121 the interface I. If it does, and the link is not packet-switch 122 capable (see [5]), R installs a discard route for destination D. 123 Otherwise, R installs (as usual) a route for destination D with 124 nexthop I. Note that R need only do this check if it has packet- 125 switch incapable links; if all of its links are packet-switch 126 capable, then clearly this check is redundant. 128 Other techniques for excluding data traffic from control channels may 129 also be needed. 131 5. IS-IS Routing Enhancements 133 In this section we define the enhancements to the TE properties of 134 GMPLS TE links that can be announced in IS-IS TE LSAs. In this 135 document, we enhance the sub-TLVs for the extended IS reachability 136 TLV (see [3]) in support of GMPLS. Specifically, we add sub-TLVs 137 for: Outgoing/Incoming Interface Identifier, Maximum LSP Bandwidth 138 and Link Protection Type. This brings the list of sub-TLVs of the 139 extended IS reachability TLV to: 141 Sub-TLV Type Length Name 142 3 4 Administrative group (color) 143 4 4 Outgoing Interface Identifier 144 5 4 Incoming Interface Identifier 145 6 4 IPv4 interface address 146 8 4 IPv4 neighbor address 147 9 4 Maximum link bandwidth 148 10 4 Reservable link bandwidth 149 11 32 Unreserved bandwidth 150 12 32 Maximum LSP Bandwidth 151 18 3 TE Default metric 152 19 1 Link Mux Capability 153 20 2 Link Protection Type 154 250-254 - Reserved for cisco specific extensions 155 255 - Reserved for future expansion 157 We further add two new TLVs. 159 TLV Type Length Name 160 136 (TBD) variable Link Descriptor 161 138 (TBD) variable Shared Risk Link Group 163 5.1. Outgoing Interface Identifier 165 A link from LSR A to LSR B may be assigned an "outgoing interface 166 identifier". This identifier is a non-zero 32-but number that is 167 assigned by LSR A. This identifier must be unique within the scope 168 of A. If such an identifier has been assigned, A can advertise it as 169 a sub-TLV of the extended IS reachability TLV with type 4, length 4 170 and value equal to the assigned identifier. 172 5.2. Incoming Interface Identifier 174 Suppose there is a link L from A to B. Suppose further that the link 175 L' from B to A that corresponds to the same interface as L has been 176 assigned an outgoing interface identifier by B. The "incoming 177 interface identifier" for L (from A's point of view) is defined as 178 the outgoing interface identifier for L' (from B's point of view). 179 If A knows this value (by means beyond the scope of this document), A 180 can advertise it as a sub-TLV of the extended IS reachability TLV 181 with type 5, length 4 and value equal to L's incoming interface 182 identifier. 184 5.3. Maximum LSP Bandwidth sub-TLV 186 The Maximum LSP Bandwidth takes the place of the Maximum Link 187 Bandwidth. However, while Maximum Link Bandwidth is a single fixed 188 value (usually simply the link capacity), Maximum LSP Bandwidth is 189 carried per priority, and may vary as LSPs are set up and torn down. 191 The Maximum LSP Bandwidth of a bundled link at priority p is defined 192 to be the maximum of the Maximum LSP Bandwidth at priority p of each 193 component link. 195 If a component link is a simple (unbundled) link, define its Maximum 196 LSP Bandwidth at priority p to be the smaller of its unreserved 197 bandwidth at priority p and its maximum link bandwidth. 199 The Maximum LSP Bandwidth TLV has type 12 and length 32 octets. The 200 value is a list of eight 4 octet fields in IEEE floating point format 201 of the Maximum LSP Bandwidth of the link, with priority 0 first and 202 priority 7 last. 204 Although Maximum Link Bandwidth is to be deprecated, for backward 205 compatibility, one MAY set the Maximum Link Bandwidth to the Maximum 206 LSP Bandwidth at priority 7 of the link. 208 5.4. Link Protection Type sub-TLV 210 The Link Protection Type sub-TLV represents the protection capability 211 that exists on a link. It is desirable to carry this information so 212 that it may be used by the path computation algorithm to set up LSPs 213 with appropriate protection characteristics. This is a sub-TLV (of 214 type 20) of the extended IS reachability TLV, with length two octets, 215 the first of which is a bit vector describing the protection 216 capabilities of the link. They are: 218 0x01 Extra Traffic 219 If the link is Extra Traffic, it indicates that these links are 220 protecting other (primary) links. The LSPs on a link of this 221 type will be lost if the primary links being protected fail. 223 0x02 Unprotected 224 If the link is Unprotected, it means that there is no backup link 225 for traffic being carried on the link. 227 0x04 Shared 228 If the link has Shared protection, it means that for the N > 1 229 primary data-bearing channels, there are M disjoint backup data- 230 bearing channels reserved to carry the traffic. Additionally, the 231 protection data-bearing channel MAY carry low-priority preemptable 232 traffic. The bandwidth of backup data-bearing channels will be 233 announced in the unreserved bandwidth sub-TLV at the appropriate 234 priority. 236 0x08 Dedicated 1:1 237 If the link has Dedicated 1:1 protection, it means that for each 238 primary data-bearing channel, there is one disjoint backup data- 239 bearing channel reserved to carry the traffic. Additionally, the 240 protection data-bearing channel MAY carry low-priority preemptable 241 traffic. The bandwidth of backup data-bearing channels will be 242 announced in the unreserved bandwidth sub-TLV at the appropriate 243 priority. 245 0x10 Dedicated 1+1 246 If the link has Dedicated 1+1 protection, it means that a disjoint 247 backup data-bearing channel is reserved and dedicated for 248 protecting the primary data-bearing channel. This backup data- 249 bearing channel is not shared by any other connection, and traffic 250 is duplicated and carried simultaneously over both channels. 252 0x20 Enhanced 253 If the link has Enhanced protection, it indicates that a protection 254 scheme that is more reliable than Dedicated 1+1 is being used, 255 e.g., 4 fiber BLSR/MS-SPRING to protect this link. 257 0x40 Reserved 258 0x80 Reserved 260 The second octet gives a priority value such that a new connection 261 with a higher priority (i.e., numerically lower than this value) is 262 guaranteed to be setup on a primary (or working) channel, and not on 263 a secondary (or protect) channel. 265 The Link Protection Type sub-TLV is optional and if an LSA does not 266 carry the TLV, then the Link Protection Type is unknown. The 267 protection capability of a link is typically pre-configured and does 268 not change dynamically over time. The working priority value is pre- 269 configured and does not depend on the traffic characteristics on the 270 primary data-bearing channel. 272 5.5. Link Descriptor TLV 274 The Link Descriptor TLV represents the characteristics of the link, 275 in particular the link type and the bit transmission rate. These 276 characteristics represent one of the constraints on the type of LSPs 277 that could be carried over a link. 279 These characteristics should not be confused with the physical link 280 encoding or multiplex structure (if any). For example there are 281 systems where four OC-48s are switched and transported over a single 282 fiber via wavelength division multiplexing (WDM) technology. There 283 are systems where four OC-48s are transported in a transparent OC-192 284 time division multiplex (TDM) structure, i.e., all the overheads of 285 the OC-48's are persevered. In both these cases the essential 286 information from a routing perspective is that both of the links can 287 transport media of type OC-48. 289 The proposed Link Descriptor TLV (of type 136 TBD) contains a new 290 data structure consisting of: 291 7 octets of System ID and Pseudonode Number 292 4 octets of IPv4 interface address 293 4 octets of IPv4 neighbor address 294 and a list of Link Descriptors, where each element in the list has 10 295 octets. The length of the TLV is thus 15+10*n octets, where n is the 296 number of elements in the list. 298 Each Link descriptor element consists of the following fields: the 299 first field is a one-octet value which defines the link encoding 300 type, the second field is a one-octet value which defines the lowest 301 priority at which that link encoding type is available, the third 302 field is four-octets and specifies the minimum reservable bandwidth 303 (in IEEE floating point format, the units being bytes per second) for 304 this link encoding type, and the last field is four-octets and 305 specifies the maximum reservable bandwidth (in IEEE floating point 306 format, the units being bytes per second) for this link encoding 307 type. Link encoding type values are taken from the following list: 309 Value Link Encoding Type 310 1 Standard SONET 311 2 Arbitrary SONET 312 3 Standard SDH 313 4 Arbitrary SDH 314 5 Clear 315 6 GigE 316 7 10GigE 318 A link having Standard SONET (or Standard SDH) link encoding type can 319 switch data at a minimum rate, which is given by the Minimum 320 Reservable Bandwidth on that link, and the maximum rate is given by 321 the Maximum Reservable Bandwidth on that link. Typical values of 322 these are enumerated in the GMPLS signaling draft [6]. In other 323 words, the Minimum and Maximum Reservable Bandwidth represents the 324 leaf and the root of one branch within the structure of the SONET (or 325 SDH) hierarchy. An LSP on that link may reserve any bit transmission 326 rate that is allowed by the SONET (or SDH) hierarchy between the 327 minimum and maximum reservable values (the spectrum is discrete). 328 For example, consider a branch of SONET multiplexing tree : VT-1.5, 329 STS-1, STS-3c, STS-12c, STS-48c, STS-192c. If it is possible to 330 establish all these connections on a OC-192 link, it can be 331 advertised as follows: Minimum Reservable Bandwidth VT-1.5 and 332 Maximum Reservable Bandwidth STS-192. 334 A link having Arbitrary SONET (or Arbitrary SDH) link encoding type 335 can switch data at a minimum rate, which is given by the Minimum 336 Reservable Bandwidth on that link, and the maximum rate is given by 337 the Maximum Reservable Bandwidth on that link. Typical values of 338 these are enumerated in the GMPLS signaling draft [6]. An LSP on 339 that link may reserve any bit transmission rate that is a multiple of 340 the Minimum Reservable Bandwidth between the minimum and maximum 341 reservable values (the spectrum is discrete). 343 To handle the case where a link could support multiple branches of 344 the SONET (or SDH) multiplexing hierarchy, one could use multiple LSP 345 descriptors. For example, if a link supports VT-1.5 and VT-2 (which 346 are not part of same branch of SONET multiplexing tree), then it 347 could advertise two LSP descriptors, one for each one. 349 For a link with Clear encoding, the minimum and maximum reservable 350 bandwidth will imply that the optical path is tuned to carry traffic 351 within those range of values. (Note that it should be possible to 352 carry OC-x as well as GigE or any other encoding format, as long as 353 the bit transmission rate of the data to be carried is within this 354 range.) 356 For other encoding types, the minimum and maximum reservable 357 bandwidth should be set to have the same values. 359 Link Descriptors present a new constraint for LSP path computation. 361 On a bundled link we assume that either the whole link is configured 362 with the Link Descriptor Types, or each of its component links are 363 configured with the Link Descriptor Types. In the latter case, the 364 Link Descriptor Type of the bundled link is set to the set union of 365 the Link Descriptor Types for all the component links. 367 It is possible that Link Descriptor TLV will change over time, 368 reflecting the allocation/deallocation of component links. In 369 general, creation/deletion of an LSP on a link doesn't necessarily 370 result in changing the Link Descriptor of that link. For example, 371 assume that STS-1, STS-3c, STS-12c, STS-48c and STS-192c LSPs can be 372 established on a OC-192 link whose Link Type is SONET. Thus, 373 initially in the Link Descriptor the minimum reservable bandwidth is 374 set to STS-1, and the maximum reservable bandwidth is set of STS-192. 375 As soon as an LSP of STS-1 size is established on the link, it is no 376 longer capable of STS-192c. Therefore, the node advertises a 377 modified Link Descriptor indicating that the maximum reservable 378 bandwidth is no longer STS-192, but STS-48. If subsequently there is 379 another STS-1 LSP, there is no change in the Link Descriptor. The 380 Link Descriptor remains the same until the node can no longer 381 establish a STS-48c LSP over the link (which means that at this point 382 more than 144 time slots are taken by LSPs on the link). Once this 383 happened, the Link Descriptor is modified again, and the modified 384 Link Descriptor is advertised to other nodes. 386 Note that changes to the Link Descriptor TLV will also affect the 387 Unreserved Bandwidth sub-TLV with respect to bandwidth available on 388 the link. 390 5.6. Shared Risk Link Group TLV 392 A set of links may constitute a 'shared risk link group' (SRLG) if 393 they share a resource whose failure may affect all links in the set. 394 For example, two fibers in the same conduit would be in the same 395 SRLG. A link may belong to multiple SRLGs. Thus the SRLG TLV 396 describes a list of SRLGs that the link belongs to. An SRLG is 397 identified by a 32 bit number that is unique within an IGP domain. 399 The SRLG of a LSP is the union of the SRLGs of the links in the LSP. 400 The SRLG of a bundled link is the union of the SRLGs of all the 401 component links. The SRLG values are an unordered list of 4 octet 402 numbers that the link belongs to. 404 If an LSR is required to have multiple diversely routed LSPs to 405 another LSR, the path computation should attempt to route the paths 406 so that they do not have any links in common, and such that the path 407 SRLGs are disjoint. 409 The proposed SRLG (of type 138 TBD) contains a new data structure 410 consisting of: 411 7 octets of System ID and Pseudonode Number 412 4 octets of IPv4 interface address 413 4 octets of IPv4 neighbor address 414 and a list of SRLG values, where each element in the list has 4 415 octets. The length of the TLV is thus 15+4*n octets, where n is the 416 number of elements in the list. 418 The SRLG TLV starts with a configured value and does not change over 419 time, unless manually reconfigured. The SRLG TLV is optional and if 420 an LSA doesn't carry the SRLG TLV, then it means that SRLG of that 421 link is unknown. 423 6. Security Considerations 425 The sub-TLVs proposed in this document does not raise any new 426 security concerns. 428 7. Acknowledgements 430 The authors would like to thank Suresh Katukam, Jonathan Lang and 431 Quaizar Vohra for their comments on the draft. 433 8. References 435 [1] Awduche, D., Rekhter, Y., Drake, J., Coltun, R., "Multi- 436 Protocol Lambda Switching: Combining MPLS Traffic Engineering 437 Control With Optical Crossconnects", 438 draft-awduche-mpls-te-optical-02.txt (work in progress) 440 [2] Basak, D., Awduche, D., Drake, J., Rekhter, Y., "Multi- 441 protocol Lambda Switching: Issues in Combining MPLS Traffic 442 Engineering Control With Optical Crossconnects", 443 draft-basak-mpls-oxc-issues-01.txt (work in progress) 445 [3] Smit, H., Li, T., "IS-IS Extensions for Traffic Engineering", 446 draft-ietf-isis-traffic-02.txt (work in progress) 448 [4] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in MPLS 449 Traffic Engineering", draft-kompella-mpls-bundle-05.txt (work 450 in progress) 452 [5] Kompella, K., Rekhter, Y., "LSP Hierarchy with MPLS TE", 453 draft-ietf-mpls-lsp-hierarchy-01.txt (work in progress) 455 [6] Generalized MPLS Group, "Generalized MPLS - Signaling Functional 456 Description", draft-ietf-mpls-generalized-signaling-02.txt (work 457 in progress) 459 [7] Lang J., Mitra K., Drake J., Kompella K., Rekhter Y., Berger L., 460 Saha, D., Sandick, H., and Basak D., "Link Management Protocol", 461 draft-ietf-mpls-lmp-02.txt (work in progress) 463 9. Authors' Information 465 Kireeti Kompella 466 Juniper Networks, Inc. 467 1194 N. Mathilda Ave 468 Sunnyvale, CA 94089 469 Email: kireeti@juniper.net 471 Yakov Rekhter 472 Juniper Networks, Inc. 473 1194 N. Mathilda Ave 474 Sunnyvale, CA 94089 475 Email: yakov@juniper.net 477 Ayan Banerjee 478 Calient Networks 479 5853 Rue Ferrari 480 San Jose, CA 95138 481 Phone: +1.408.972.3645 482 Email: abanerjee@calient.net 484 John Drake 485 Calient Networks 486 5853 Rue Ferrari 487 San Jose, CA 95138 488 Phone: (408) 972-3720 489 Email: jdrake@calient.net 490 Greg Bernstein 491 Ciena Corporation 492 10480 Ridgeview Court 493 Cupertino, CA 94014 494 Phone: (408) 366-4713 495 Email: greg@ciena.com 497 Don Fedyk 498 Nortel Networks Corp. 499 600 Technology Park Drive 500 Billerica, MA 01821 501 Phone: +1-978-288-4506 502 Email: dwfedyk@nortelnetworks.com 504 Eric Mannie 505 GTS Network Services 506 RDI Department, Core Network Technology Group 507 Terhulpsesteenweg, 6A 508 1560 Hoeilaart, Belgium 509 Phone: +32-2-658.56.52 510 E-mail: eric.mannie@gtsgroup.com 512 Debanjan Saha 513 Tellium Optical Systems 514 2 Crescent Place 515 P.O. Box 901 516 Ocean Port, NJ 07757 517 Phone: (732) 923-4264 518 Email: dsaha@tellium.com 520 Vishal Sharma 521 Jasmine Networks, Inc. 522 3061 Zanker Rd, Suite B 523 San Jose, CA 95134 524 Phone: (408) 895-5000