idnits 2.17.1 draft-kompella-ospf-gmpls-extensions-00.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. ** 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 210: '...mpatibility, one MAY set the Maximum L...' RFC 2119 keyword, line 237: '...-bearing channel MAY carry low-priorit...' RFC 2119 keyword, line 245: '...-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 71 == Unused Reference: '7' is defined on line 483, 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 (-10) exists of draft-katz-yeung-ospf-traffic-02 == 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: 7 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 OSPF Extensions in Support of Generalized MPLS 13 draft-kompella-ospf-gmpls-extensions-00.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 OSPF 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 OSPF 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 OSPF are outlined in [2]. This document enhances the 50 routing extensions [3] required to support MPLS Traffic Engineering. 51 Some of these enhancements also need to be carried in the signaling 52 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 OSPF TE LSAs. In Section 5, we define a new set of Type/Length/Value 57 (TLV) triplets, and describe their formats. 59 4. GMPLS TE Links 61 Traditionally, a TE link is advertised as an adjunct to a "regular" 62 OSPF link, i.e., an OSPF adjacency is brought up on the link, and 63 when the link is up, both the regular SPF properties of the link 64 (basically, the SPF metric) and the TE properties of the link are 65 then advertised. 67 However, GMPLS challenges this notion in three ways. First, links 68 that are not capable of sending and receiving on a packet-by-packet 69 basis may yet have TE properties; however, an OSPF adjacency cannot 70 be brought up on such links. Second, a Label Switched Path can be 71 advertised as a point-to-point TE link (see [LSP-HIER]); thus, an 72 advertised TE link need no longer be between two OSPF neighbors. 73 Finally, a number of links may be advertised as a single TE link 74 (perhaps for improved scalability), so again, there is no longer a 75 one-to-one association of a regular adjacency and a TE link. 77 Thus we have a more general notion of a TE link. A TE link is a 78 "logical" link that has TE properties, some of which may be 79 configured on the advertising Label Switching Router (LSR), others 80 which may be obtained from other LSRs by means of some protocol, and 81 yet others which may be deduced from the component(s) of the TE link. 83 A TE link between a pair of LSRs doesn't imply the existence of an 84 OSPF adjacency between these LSRs. A TE link must also have some 85 means by which the advertising LSR can know of its liveness (this 86 means may be OSPF hellos, but is not limited to OSPF hellos). When 87 an LSR knows that a TE link is up, and can determine the TE link's TE 88 properties, the LSR may then advertise that link to its (regular) 89 OSPF neighbors using the TE TLVs. In this document, we call the 90 interfaces over which regular OSPF adjacencies are established 91 "control channels". 93 [3] defines the canonical TE properties, and says how to associate TE 94 properties to regular (packet-switched) links. This document extends 95 the set of TE properties, and also says how to associate TE 96 properties with non-packet-switched links such as links between 97 Optical Cross-Connects (OXCs). [5] says how to associate TE 98 properties with Label Switched Paths; [4] says how to associate TE 99 properties with a "bundle" of links. 101 4.1. Excluding data traffic from control channels 103 The control channels between nodes in a GMPLS network, such as OXCs 104 (see [1], [2]), SONET cross-connects and/or routers, are generally 105 meant for control and administrative traffic. These control channels 106 are advertised into OSPF as normal IS links as mentioned in the 107 previous section; this allows the routing of (for example) RSVP 108 messages and telnet sessions. However, if routers on the edge of the 109 optical domain attempt to forward data traffic over these channels, 110 the channel capacity will quickly be exhausted. 112 If one assumes that data traffic is sent to BGP destinations, and 113 control traffic to IGP destinations, then one can exclude data 114 traffic from the control plane by restricting BGP nexthop resolution. 115 (It is assumed that OXCs are not BGP speakers.) Suppose that a 116 router R is attempting to install a route to a BGP destination D. R 117 looks up the BGP nexthop for D in its IGP's routing table. Say R 118 finds that the path to the nexthop is over interface I. R then 119 checks if it has an entry in its Link State database associated with 120 the interface I. If it does, and the link is not packet-switch 121 capable (see [5]), R installs a discard route for destination D. 122 Otherwise, R installs (as usual) a route for destination D with 123 nexthop I. Note that R need only do this check if it has packet- 124 switch incapable links; if all of its links are packet-switch 125 capable, then clearly this check is redundant. 127 Other techniques for excluding data traffic from control channels may 128 also be needed. 130 5. OSPF Routing Enhancements 132 In this section we define the enhancements to the TE properties of 133 GMPLS TE links that can be announced in OSPF TE LSAs. The Traffic 134 Engineering (TE) LSA, which is an opaque LSA with area flooding scope 135 [3], has only one top-level Type/Length/Value (TLV) triplet and has 136 one or more nested TLVs for extensibility. The top-level TLV can 137 take one of two values (1) Router Address or (2) Link. In this 138 document, we enhance the sub-TLVs for the Link TLV in support of 139 GMPLS. Specifically, we add the following sub-TLVs: 141 1. Outgoing Interface Identifier, 142 2. Incoming Interface Identifier, 143 3. Link Protection Type, 144 4. Link Descriptor, and 145 5. Shared Risk Link Group. 147 This brings the list of sub-TLVs of the TE Link TLV to: 149 Sub-TLV Type Length Name 150 1 1 Link type 151 2 4 Link ID 152 3 4 Local interface IP address 153 4 4 Remote interface IP address 154 5 4 Traffic engineering metric 155 6 4 Maximum bandwidth 156 7 4 Maximum reservable bandwidth 157 8 32 Unreserved bandwidth 158 9 4 Resource class/color 159 10 4 Link Mux Capability 160 11 4 Outgoing Interface Identifier 161 12 4 Incoming Interface Identifier 162 13 32 Maximum LSP Bandwidth 163 14 4 Link Protection Type 164 15 variable Link Descriptor 165 16 variable Shared Risk Link Group 166 32768-32772 - Reserved for Cisco-specific 167 extensions 169 5.1. Outgoing Interface Identifier 171 A link from LSR A to LSR B may be assigned an "outgoing interface 172 identifier". This identifier is a non-zero 32-but number that is 173 assigned by LSR A. This identifier must be unique within the scope 174 of A. If such an identifier has been assigned, A can advertise it as 175 a sub-TLV of the Link TLV with type 11, length 4 and value equal to 176 the assigned identifier. 178 5.2. Incoming Interface Identifier 180 Suppose there is a link L from A to B. Suppose further that the link 181 L' from B to A that corresponds to the same interface as L has been 182 assigned an outgoing interface identifier by B. The "incoming 183 interface identifier" for L (from A's point of view) is defined as 184 the outgoing interface identifier for L' (from B's point of view). 185 If A knows this value (by means beyond the scope of this document), A 186 can advertise it as a sub-TLV of the Link TLV with type 12, length 4 187 and value equal to L's incoming interface identifier. 189 5.3. Maximum LSP Bandwidth sub-TLV 191 The Maximum LSP Bandwidth takes the place of the Maximum Link 192 Bandwidth. However, while Maximum Link Bandwidth is a single fixed 193 value (usually simply the link capacity), Maximum LSP Bandwidth is 194 carried per priority, and may vary as LSPs are set up and torn down. 196 The Maximum LSP Bandwidth of a bundled link at priority p is defined 197 to be the maximum of the Maximum LSP Bandwidth at priority p of each 198 component link. 200 If a component link is a simple (unbundled) link, define its Maximum 201 LSP Bandwidth at priority p to be the smaller of its unreserved 202 bandwidth at priority p and its maximum link bandwidth. 204 The Maximum LSP Bandwidth TLV has type 13 and length 32 octets. The 205 value is a list of eight 4 octet fields in IEEE floating point format 206 of the Maximum LSP Bandwidth of the link, with priority 0 first and 207 priority 7 last. 209 Although Maximum Link Bandwidth is to be deprecated, for backward 210 compatibility, one MAY set the Maximum Link Bandwidth to the Maximum 211 LSP Bandwidth at priority 7 of the link. 213 5.4. Link Protection Type sub-TLV 215 The Link Protection Type sub-TLV represents the protection capability 216 that exists on a link. It is desirable to carry this information so 217 that it may be used by the path computation algorithm to set up LSPs 218 with appropriate protection characteristics. 220 In the Traffic Engineering LSA, the Link Protection Type sub-TLV is a 221 sub-TLV of the Link TLV, with type 14, and length of four octets, the 222 first of which can take one of the following values: 224 Value Link Protection Type 225 0 Unprotected 226 1 Shared 227 2 Dedicated 1:1 228 3 Dedicated 1+1 229 4 Enhanced 231 If the link is Unprotected, it means that there is no backup link for 232 traffic being carried on the link. 234 If the link has Shared protection, it means that for the N > 1 235 primary data-bearing channels, there are M disjoint backup data- 236 bearing channels reserved to carry the traffic. Additionally, the 237 protection data-bearing channel MAY carry low-priority preemptable 238 traffic. The bandwidth of backup data-bearing channels will be 239 announced in the unreserved bandwidth sub-TLV at the appropriate 240 priority. 242 If the link has Dedicated 1:1 protection, it means that for each 243 primary data-bearing channel, there is one disjoint backup data- 244 bearing channel reserved to carry the traffic. Additionally, the 245 protection data-bearing channel MAY carry low-priority preemptable 246 traffic. The bandwidth of backup data-bearing channels will be 247 announced in the unreserved bandwidth sub-TLV at the appropriate 248 priority. 250 If the link has Dedicated 1+1 protection, it means that a disjoint 251 backup data-bearing channel is reserved and dedicated for protecting 252 the primary data-bearing channel. This backup data-bearing channel 253 is not shared by any other connection, and traffic is duplicated and 254 carried simultaneously over both channels. 256 If the link has Enhanced protection, it indicates that the protection 257 scheme for the link is more reliable than the Dedicated 1+1, e.g., 4 258 fiber BLSR/MS-SPRING. 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 format of the Link Protection Type sub-TLV is as shown below: 267 The Link Protection Type sub-TLV is optional and if an LSA does not 268 carry the TLV, then the Link Protection Type is unknown. The 269 protection capability of a link is typically pre-configured and does 270 not change dynamically over time. The working priority value is pre- 271 0 1 2 3 272 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | 14 | Length | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 |Link Prot. Type| Working Pri | Reserved | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 configured and does not depend on the traffic characteristics on the 280 primary data-bearing channel. 282 5.5. Link Descriptor sub-TLV 284 The Link Descriptor TLV represents the characteristics of the link, 285 in particular the link type and the bit transmission rate. These 286 characteristics represent one of the constraints on the type of LSPs 287 that could be carried over the link. 289 These characteristics should not be confused with the physical link 290 encoding or multiplex structure (if any). For example there are 291 systems where four OC-48s are switched and transported over a single 292 fiber via wavelength division multiplexing (WDM) technology. There 293 are systems where four OC-48s are transported in a transparent OC-192 294 time division multiplex (TDM) structure, i.e., all the overheads of 295 the OC-48's are persevered. In both these cases the essential 296 information from a routing perspective is that both of the links can 297 transport media of type OC-48. 299 In the Traffic Engineering LSA, the Link Descriptor sub-TLV is a sub- 300 TLV of the Link TLV, with type 15. The length is the length of the 301 list of Link Descriptors in octets. Each Link descriptor element 302 consists of the following fields: the first field is a one-octet 303 value which defines the link encoding type, the second field is a 304 one-octet value which defines the lowest priority at which that link 305 encoding type is available, the next two-octets are reserved, the 306 next field is four-octets and specifies the minimum reservable 307 bandwidth (in IEEE floating point format, the unit being bytes per 308 second) for this link encoding type, and the last four-octets 309 specifies the maximum reservable bandwidth (in IEEE floating point 310 format, the unit being bytes per second) for this link encoding type. 311 Link encoding type values are taken from the following list: 313 Value Link Encoding Type 314 1 Standard SONET 315 2 Arbitrary SONET 316 3 Standard SDH 317 4 Arbitrary SDH 318 5 Clear 319 6 GigE 320 7 10GigE 322 The format of the Link Descriptors is shown in the next figure. 324 0 1 2 3 325 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Link Type | Pri | Reserved | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Minimum Reservable Bandwidth | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Maximum Reservable Bandwidth | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 A link having Standard SONET (or Standard SDH) link encoding type can 335 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]. In other 339 words, the Minimum and Maximum Reservable Bandwidth represents the 340 leaf and the root of one branch within the structure of the SONET (or 341 SDH) hierarchy. An LSP on that link may reserve any bit transmission 342 rate that is allowed by the SONET (or SDH) hierarchy between the 343 minimum and maximum reservable values (the spectrum is discrete). 344 For example, consider a branch of SONET multiplexing tree : VT-1.5, 345 STS-1, STS-3c, STS-12c, STS-48c, STS-192c. If it is possible to 346 establish all these connections on a OC-192 link, it can be 347 advertised as follows: Minimum Reservable Bandwidth VT-1.5 and 348 Maximum Reservable Bandwidth STS-192. 350 A link having Arbitrary SONET (or Arbitrary SDH) link encoding type 351 can switch data at a minimum rate, which is given by the Minimum 352 Reservable Bandwidth on that link, and the maximum rate is given by 353 the Maximum Reservable Bandwidth on that link. Typical values of 354 these are enumerated in the GMPLS signaling draft [6]. An LSP on 355 that link may reserve any bit transmission rate that is a multiple of 356 the Minimum Reservable Bandwidth between the minimum and maximum 357 reservable values (the spectrum is discrete). 359 To handle the case where a link could support multiple branches of 360 the SONET (or SDH) multiplexing hierarchy, one could use multiple LSP 361 descriptors. For example, if a link supports VT-1.5 and VT-2 (which 362 are not part of same branch of SONET multiplexing tree), then it 363 could advertise two LSP descriptors, one for each one. 365 For a link with Clear encoding, the minimum and maximum reservable 366 bandwidth will imply that the optical path is tuned to carry traffic 367 within those range of values. (Note that it should be possible to 368 carry OC-x as well as GigE or any other encoding format, as long as 369 the bit transmission rate of the data to be carried is within this 370 range.) 372 For other encoding types, the minimum and maximum reservable 373 bandwidth should be set to have the same values. 375 Link Descriptors present a new constraint for LSP path computation. 377 On a bundled link we assume that either the whole link is configured 378 with the Link Descriptor Types, or each of its component links are 379 configured with the Link Descriptor Types. In the latter case, the 380 Link Descriptor Type of the bundled link is set to the set union of 381 the Link Descriptor Types for all the component links. 383 It is possible that Link Descriptor TLV will change over time, 384 reflecting the allocation/deallocation of component links. In 385 general, creation/deletion of an LSP on a link doesn't necessarily 386 result in changing the Link Descriptor of that link. For example, 387 assume that STS-1, STS-3c, STS-12c, STS-48c and STS-192c LSPs can be 388 established on a OC-192 link whose Link Type is SONET. Thus, 389 initially in the Link Descriptor the minimum reservable bandwidth is 390 set to STS-1, and the maximum reservable bandwidth is set of STS-192. 391 As soon as an LSP of STS-1 size is established on the link, it is no 392 longer capable of STS-192c. Therefore, the node advertises a 393 modified Link Descriptor indicating that the maximum reservable 394 bandwidth is no longer STS-192, but STS-48. If subsequently there is 395 another STS-1 LSP, there is no change in the Link Descriptor. The 396 Link Descriptor remains the same until the node can no longer 397 establish a STS-48c LSP over the link (which means that at this point 398 more than 144 time slots are taken by LSPs on the link). Once this 399 happened, the Link Descriptor is modified again, and the modified 400 Link Descriptor is advertised to other nodes. 402 Note that changes to the Link Descriptor TLV will also affect the 403 Unreserved Bandwidth sub-TLV with respect to bandwidth available on 404 the link. 406 5.6. Shared Risk Link Group TLV 408 A set of links may constitute a 'shared risk link group' (SRLG) if 409 they share a resource whose failure may affect all links in the set. 410 For example, two fibers in the same conduit would be in the same 411 SRLG. A link may belong to multiple SRLGs. Thus the SRLG TLV 412 describes a list of SRLGs that the link belongs to. An SRLG is 413 identified by a 32 bit number that is unique within an IGP domain. 415 The SRLG of a LSP is the union of the SRLGs of the links in the LSP. 416 The SRLG of a bundled link is the union of the SRLGs of all the 417 component links. The SRLG values are an unordered list of 4 octet 418 numbers that the link belongs to. 420 If an LSR is required to have multiple diversely routed LSPs to 421 another LSR, the path computation should attempt to route the paths 422 so that they do not have any links in common, and such that the path 423 SRLGs are disjoint. 425 The SRLG sub-TLV is a sub-TLV of the Link TLV with type 16. The 426 length is the length of the list in octets. The value is an 427 unordered list of 32 bit numbers that are the SRLGs that the link 428 belongs to. The format is as shown below: 430 0 1 2 3 431 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | 16 | 4 * No. of SRLGs in link | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Shared Risk Link Group Value | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | ............ | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Shared Risk Link Group Value | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 The SRLG TLV starts with a configured value and does not change over 443 time, unless manually reconfigured. The SRLG TLV is optional and if 444 an LSA doesn't carry the SRLG TLV, then it means that SRLG of that 445 link is unknown. 447 6. Security Considerations 449 The sub-TLVs proposed in this document does not raise any new 450 security concerns. 452 7. Acknowledgements 454 The authors would like to thank Suresh Katukam, Jonathan Lang and 455 Quaizar Vohra for their comments on the draft. 457 8. References 459 [1] Awduche, D., Rekhter, Y., Drake, J., Coltun, R., "Multi- 460 Protocol Lambda Switching: Combining MPLS Traffic Engineering 461 Control With Optical Crossconnects", 462 draft-awduche-mpls-te-optical-02.txt (work in progress) 464 [2] Basak, D., Awduche, D., Drake, J., Rekhter, Y., "Multi- 465 protocol Lambda Switching: Issues in Combining MPLS Traffic 466 Engineering Control With Optical Crossconnects", 467 draft-basak-mpls-oxc-issues-01.txt (work in progress) 469 [3] Katz, D., Yeung, D., "Traffic Engineering Extensions to OSPF", 470 draft-katz-yeung-ospf-traffic-02.txt (work in progress) 472 [4] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in MPLS 473 Traffic Engineering", draft-kompella-mpls-bundle-04.txt (work 474 in progress) 476 [5] Kompella, K., Rekhter, Y., "LSP Hierarchy with MPLS TE", 477 draft-ietf-mpls-lsp-hierarchy-00.txt (work in progress) 479 [6] Generalized MPLS Group, "Generalized MPLS - Signaling Functional 480 Description", draft-ietf-mpls-generalized-signaling-01.txt (work 481 in progress) 483 [7] Lang J., Mitra K., Drake J., Kompella K., Rekhter Y., Berger L., 484 Saha, D., Sandick, H., and Basak D., "Link Management Protocol", 485 draft-ietf-mpls-lmp-01.txt (work in progress) 487 9. Authors' Information 489 Kireeti Kompella 490 Juniper Networks, Inc. 491 1194 N. Mathilda Ave 492 Sunnyvale, CA 94089 493 Email: kireeti@juniper.net 495 Yakov Rekhter 496 Cisco Systems, Inc. 497 170 West Tasman Drive 498 San Jose, CA 95134 499 Email: yakov@cisco.com 501 Ayan Banerjee 502 Calient Networks 503 5853 Rue Ferrari 504 San Jose, CA 95138 505 Phone: +1.408.972.3645 506 Email: abanerjee@calient.net 508 John Drake 509 Calient Networks 510 5853 Rue Ferrari 511 San Jose, CA 95138 512 Phone: (408) 972-3720 513 Email: jdrake@calient.net 515 Greg Bernstein 516 Ciena Corporation 517 10480 Ridgeview Court 518 Cupertino, CA 94014 519 Phone: (408) 366-4713 520 Email: greg@ciena.com 521 Don Fedyk 522 Nortel Networks Corp. 523 600 Technology Park Drive 524 Billerica, MA 01821 525 Phone: +1-978-288-4506 526 Email: dwfedyk@nortelnetworks.com 528 Eric Mannie 529 GTS Network Services 530 RDI Department, Core Network Technology Group 531 Terhulpsesteenweg, 6A 532 1560 Hoeilaart, Belgium 533 Phone: +32-2-658.56.52 534 E-mail: eric.mannie@gtsgroup.com 536 Debanjan Saha 537 Tellium Optical Systems 538 2 Crescent Place 539 P.O. Box 901 540 Ocean Port, NJ 07757 541 Phone: (732) 923-4264 542 Email: dsaha@tellium.com 544 Vishal Sharma 545 Tellabs Research Center 546 One Kendall Square 547 Bldg. 100, Ste. 121 548 Cambridge, MA 02139-1562 549 Phone: (617) 577-8760 550 Email: Vishal.Sharma@tellabs.com