idnits 2.17.1 draft-ietf-isis-gmpls-extensions-01.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 2 characters 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 230: '...-bearing channel MAY carry low-priorit...' RFC 2119 keyword, line 238: '...-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 452, 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') == Outdated reference: A later version (-05) exists of draft-kompella-mpls-bundle-04 -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-08) exists of draft-ietf-mpls-lsp-hierarchy-00 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-01 == Outdated reference: A later version (-02) exists of draft-ietf-mpls-lmp-01 -- Possible downref: Normative reference to a draft: ref. '7' Summary: 9 errors (**), 0 flaws (~~), 8 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 (Cisco Systems) 3 Expiration Date: May 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-01.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 can take one of the following values: 217 Value Link Protection Type 218 0 Unprotected 219 1 Shared 220 2 Dedicated 1:1 221 3 Dedicated 1+1 222 4 Enhanced 224 If the link is Unprotected, it means that there is no backup link for 225 traffic being carried on the link. 227 If the link has Shared protection, it means that for the N > 1 228 primary data-bearing channels, there are M disjoint backup data- 229 bearing channels reserved to carry the traffic. Additionally, the 230 protection data-bearing channel MAY carry low-priority preemptable 231 traffic. The bandwidth of backup data-bearing channels will be 232 announced in the unreserved bandwidth sub-TLV at the appropriate 233 priority. 235 If the link has Dedicated 1:1 protection, it means that for each 236 primary data-bearing channel, there is one disjoint backup data- 237 bearing channel reserved to carry the traffic. Additionally, the 238 protection data-bearing channel MAY carry low-priority preemptable 239 traffic. The bandwidth of backup data-bearing channels will be 240 announced in the unreserved bandwidth sub-TLV at the appropriate 241 priority. 243 If the link has Dedicated 1+1 protection, it means that a disjoint 244 backup data-bearing channel is reserved and dedicated for protecting 245 the primary data-bearing channel. This backup data-bearing channel 246 is not shared by any other connection, and traffic is duplicated and 247 carried simultaneously over both channels. 249 If the link has Enhanced protection, it indicates that the protection 250 scheme for the link is more reliable than the Dedicated 1+1, e.g., 4 251 fiber BLSR/MS-SPRING. 253 The second octet gives a priority value such that a new connection 254 with a higher priority (i.e., numerically lower than this value) is 255 guaranteed to be setup on a primary (or working) channel, and not on 256 a secondary (or protect) channel. 258 The Link Protection Type sub-TLV is optional and if an LSA does not 259 carry the TLV, then the Link Protection Type is unknown. The 260 protection capability of a link is typically pre-configured and does 261 not change dynamically over time. The working priority value is pre- 262 configured and does not depend on the traffic characteristics on the 263 primary data-bearing channel. 265 5.5. Link Descriptor TLV 267 The Link Descriptor TLV represents the characteristics of the link, 268 in particular the link type and the bit transmission rate. These 269 characteristics represent one of the constraints on the type of LSPs 270 that could be carried over a link. 272 These characteristics should not be confused with the physical link 273 encoding or multiplex structure (if any). For example there are 274 systems where four OC-48s are switched and transported over a single 275 fiber via wavelength division multiplexing (WDM) technology. There 276 are systems where four OC-48s are transported in a transparent OC-192 277 time division multiplex (TDM) structure, i.e., all the overheads of 278 the OC-48's are persevered. In both these cases the essential 279 information from a routing perspective is that both of the links can 280 transport media of type OC-48. 282 The proposed Link Descriptor TLV (of type 136 TBD) contains a new 283 data structure consisting of: 284 7 octets of System ID and Pseudonode Number 285 4 octets of IPv4 interface address 286 4 octets of IPv4 neighbor address 287 and a list of Link Descriptors, where each element in the list has 10 288 octets. The length of the TLV is thus 15+10*n octets, where n is the 289 number of elements in the list. 291 Each Link descriptor element consists of the following fields: the 292 first field is a one-octet value which defines the link encoding 293 type, the second field is a one-octet value which defines the lowest 294 priority at which that link encoding type is available, the third 295 field is four-octets and specifies the minimum reservable bandwidth 296 (in IEEE floating point format, the units being bytes per second) for 297 this link encoding type, and the last field is four-octets and 298 specifies the maximum reservable bandwidth (in IEEE floating point 299 format, the units being bytes per second) for this link encoding 300 type. Link encoding type values are taken from the following list: 302 Value Link Encoding Type 303 1 Standard SONET 304 2 Arbitrary SONET 305 3 Standard SDH 306 4 Arbitrary SDH 307 5 Clear 308 6 GigE 309 7 10GigE 311 A link having Standard SONET (or Standard SDH) link encoding type can 312 switch data at a minimum rate, which is given by the Minimum 313 Reservable Bandwidth on that link, and the maximum rate is given by 314 the Maximum Reservable Bandwidth on that link. Typical values of 315 these are enumerated in the GMPLS signaling draft [6]. In other 316 words, the Minimum and Maximum Reservable Bandwidth represents the 317 leaf and the root of one branch within the structure of the SONET (or 318 SDH) hierarchy. An LSP on that link may reserve any bit transmission 319 rate that is allowed by the SONET (or SDH) hierarchy between the 320 minimum and maximum reservable values (the spectrum is discrete). 321 For example, consider a branch of SONET multiplexing tree : VT-1.5, 322 STS-1, STS-3c, STS-12c, STS-48c, STS-192c. If it is possible to 323 establish all these connections on a OC-192 link, it can be 324 advertised as follows: Minimum Reservable Bandwidth VT-1.5 and 325 Maximum Reservable Bandwidth STS-192. 327 A link having Arbitrary SONET (or Arbitrary SDH) link encoding type 328 can switch data at a minimum rate, which is given by the Minimum 329 Reservable Bandwidth on that link, and the maximum rate is given by 330 the Maximum Reservable Bandwidth on that link. Typical values of 331 these are enumerated in the GMPLS signaling draft [6]. An LSP on 332 that link may reserve any bit transmission rate that is a multiple of 333 the Minimum Reservable Bandwidth between the minimum and maximum 334 reservable values (the spectrum is discrete). 336 To handle the case where a link could support multiple branches of 337 the SONET (or SDH) multiplexing hierarchy, one could use multiple LSP 338 descriptors. For example, if a link supports VT-1.5 and VT-2 (which 339 are not part of same branch of SONET multiplexing tree), then it 340 could advertise two LSP descriptors, one for each one. 342 For a link with Clear encoding, the minimum and maximum reservable 343 bandwidth will imply that the optical path is tuned to carry traffic 344 within those range of values. (Note that it should be possible to 345 carry OC-x as well as GigE or any other encoding format, as long as 346 the bit transmission rate of the data to be carried is within this 347 range.) 349 For other encoding types, the minimum and maximum reservable 350 bandwidth should be set to have the same values. 352 Link Descriptors present a new constraint for LSP path computation. 354 On a bundled link we assume that either the whole link is configured 355 with the Link Descriptor Types, or each of its component links are 356 configured with the Link Descriptor Types. In the latter case, the 357 Link Descriptor Type of the bundled link is set to the set union of 358 the Link Descriptor Types for all the component links. 360 It is possible that Link Descriptor TLV will change over time, 361 reflecting the allocation/deallocation of component links. In 362 general, creation/deletion of an LSP on a link doesn't necessarily 363 result in changing the Link Descriptor of that link. For example, 364 assume that STS-1, STS-3c, STS-12c, STS-48c and STS-192c LSPs can be 365 established on a OC-192 link whose Link Type is SONET. Thus, 366 initially in the Link Descriptor the minimum reservable bandwidth is 367 set to STS-1, and the maximum reservable bandwidth is set of STS-192. 368 As soon as an LSP of STS-1 size is established on the link, it is no 369 longer capable of STS-192c. Therefore, the node advertises a 370 modified Link Descriptor indicating that the maximum reservable 371 bandwidth is no longer STS-192, but STS-48. If subsequently there is 372 another STS-1 LSP, there is no change in the Link Descriptor. The 373 Link Descriptor remains the same until the node can no longer 374 establish a STS-48c LSP over the link (which means that at this point 375 more than 144 time slots are taken by LSPs on the link). Once this 376 happened, the Link Descriptor is modified again, and the modified 377 Link Descriptor is advertised to other nodes. 379 Note that changes to the Link Descriptor TLV will also affect the 380 Unreserved Bandwidth sub-TLV with respect to bandwidth available on 381 the link. 383 5.6. Shared Risk Link Group TLV 385 A set of links may constitute a 'shared risk link group' (SRLG) if 386 they share a resource whose failure may affect all links in the set. 387 For example, two fibers in the same conduit would be in the same 388 SRLG. A link may belong to multiple SRLGs. Thus the SRLG TLV 389 describes a list of SRLGs that the link belongs to. An SRLG is 390 identified by a 32 bit number that is unique within an IGP domain. 392 The SRLG of a LSP is the union of the SRLGs of the links in the LSP. 393 The SRLG of a bundled link is the union of the SRLGs of all the 394 component links. The SRLG values are an unordered list of 4 octet 395 numbers that the link belongs to. 397 If an LSR is required to have multiple diversely routed LSPs to 398 another LSR, the path computation should attempt to route the paths 399 so that they do not have any links in common, and such that the path 400 SRLGs are disjoint. 402 The proposed SRLG (of type 138 TBD) contains a new data structure 403 consisting of: 404 7 octets of System ID and Pseudonode Number 405 4 octets of IPv4 interface address 406 4 octets of IPv4 neighbor address 407 and a list of SRLG values, where each element in the list has 4 408 octets. The length of the TLV is thus 15+4*n octets, where n is the 409 number of elements in the list. 411 The SRLG TLV starts with a configured value and does not change over 412 time, unless manually reconfigured. The SRLG TLV is optional and if 413 an LSA doesn't carry the SRLG TLV, then it means that SRLG of that 414 link is unknown. 416 6. Security Considerations 418 The sub-TLVs proposed in this document does not raise any new 419 security concerns. 421 7. Acknowledgements 423 The authors would like to thank Suresh Katukam, Jonathan Lang and 424 Quaizar Vohra for their comments on the draft. 426 8. References 428 [1] Awduche, D., Rekhter, Y., Drake, J., Coltun, R., "Multi- 429 Protocol Lambda Switching: Combining MPLS Traffic Engineering 430 Control With Optical Crossconnects", 431 draft-awduche-mpls-te-optical-02.txt (work in progress) 433 [2] Basak, D., Awduche, D., Drake, J., Rekhter, Y., "Multi- 434 protocol Lambda Switching: Issues in Combining MPLS Traffic 435 Engineering Control With Optical Crossconnects", 436 draft-basak-mpls-oxc-issues-01.txt (work in progress) 438 [3] Smit, H., Li, T., "IS-IS Extensions for Traffic Engineering", 439 draft-ietf-isis-traffic-02.txt (work in progress) 441 [4] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in MPLS 442 Traffic Engineering", draft-kompella-mpls-bundle-04.txt (work 443 in progress) 445 [5] Kompella, K., Rekhter, Y., "LSP Hierarchy with MPLS TE", 446 draft-ietf-mpls-lsp-hierarchy-00.txt (work in progress) 448 [6] Generalized MPLS Group, "Generalized MPLS - Signaling Functional 449 Description", draft-ietf-mpls-generalized-signaling-01.txt (work 450 in progress) 452 [7] Lang J., Mitra K., Drake J., Kompella K., Rekhter Y., Berger L., 453 Saha, D., Sandick, H., and Basak D., "Link Management Protocol", 454 draft-ietf-mpls-lmp-01.txt (work in progress) 456 9. Authors' Information 458 Kireeti Kompella 459 Juniper Networks, Inc. 460 1194 N. Mathilda Ave 461 Sunnyvale, CA 94089 462 Email: kireeti@juniper.net 464 Yakov Rekhter 465 Cisco Systems, Inc. 466 170 West Tasman Drive 467 San Jose, CA 95134 468 Email: yakov@cisco.com 470 Ayan Banerjee 471 Calient Networks 472 5853 Rue Ferrari 473 San Jose, CA 95138 474 Phone: +1.408.972.3645 475 Email: abanerjee@calient.net 477 John Drake 478 Calient Networks 479 5853 Rue Ferrari 480 San Jose, CA 95138 481 Phone: (408) 972-3720 482 Email: jdrake@calient.net 483 Greg Bernstein 484 Ciena Corporation 485 10480 Ridgeview Court 486 Cupertino, CA 94014 487 Phone: (408) 366-4713 488 Email: greg@ciena.com 490 Don Fedyk 491 Nortel Networks Corp. 492 600 Technology Park Drive 493 Billerica, MA 01821 494 Phone: +1-978-288-4506 495 Email: dwfedyk@nortelnetworks.com 497 Eric Mannie 498 GTS Network Services 499 RDI Department, Core Network Technology Group 500 Terhulpsesteenweg, 6A 501 1560 Hoeilaart, Belgium 502 Phone: +32-2-658.56.52 503 E-mail: eric.mannie@gtsgroup.com 505 Debanjan Saha 506 Tellium Optical Systems 507 2 Crescent Place 508 P.O. Box 901 509 Ocean Port, NJ 07757 510 Phone: (732) 923-4264 511 Email: dsaha@tellium.com 513 Vishal Sharma 514 Tellabs Research Center 515 One Kendall Square 516 Bldg. 100, Ste. 121 517 Cambridge, MA 02139-1562 518 Phone: (617) 577-8760 519 Email: Vishal.Sharma@tellabs.com