idnits 2.17.1 draft-kompella-ospf-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 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 209: '...mpatibility, one MAY set the Maximum L...' RFC 2119 keyword, line 237: '...-bearing channel MAY carry low-priorit...' RFC 2119 keyword, line 246: '...-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 489, 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-04 -- 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: 8 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 OSPF Extensions in Support of Generalized MPLS 13 draft-kompella-ospf-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 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 extensions 168 5.1. Outgoing Interface Identifier 170 A link from LSR A to LSR B may be assigned an "outgoing interface 171 identifier". This identifier is a non-zero 32-but number that is 172 assigned by LSR A. This identifier must be unique within the scope 173 of A. If such an identifier has been assigned, A can advertise it as 174 a sub-TLV of the Link TLV with type 11, length 4 and value equal to 175 the assigned identifier. 177 5.2. Incoming Interface Identifier 179 Suppose there is a link L from A to B. Suppose further that the link 180 L' from B to A that corresponds to the same interface as L has been 181 assigned an outgoing interface identifier by B. The "incoming 182 interface identifier" for L (from A's point of view) is defined as 183 the outgoing interface identifier for L' (from B's point of view). 184 If A knows this value (by means beyond the scope of this document), A 185 can advertise it as a sub-TLV of the Link TLV with type 12, length 4 186 and value equal to L's incoming interface identifier. 188 5.3. Maximum LSP Bandwidth sub-TLV 190 The Maximum LSP Bandwidth takes the place of the Maximum Link 191 Bandwidth. However, while Maximum Link Bandwidth is a single fixed 192 value (usually simply the link capacity), Maximum LSP Bandwidth is 193 carried per priority, and may vary as LSPs are set up and torn down. 195 The Maximum LSP Bandwidth of a bundled link at priority p is defined 196 to be the maximum of the Maximum LSP Bandwidth at priority p of each 197 component link. 199 If a component link is a simple (unbundled) link, define its Maximum 200 LSP Bandwidth at priority p to be the smaller of its unreserved 201 bandwidth at priority p and its maximum link bandwidth. 203 The Maximum LSP Bandwidth TLV has type 13 and length 32 octets. The 204 value is a list of eight 4 octet fields in IEEE floating point format 205 of the Maximum LSP Bandwidth of the link, with priority 0 first and 206 priority 7 last. 208 Although Maximum Link Bandwidth is to be deprecated, for backward 209 compatibility, one MAY set the Maximum Link Bandwidth to the Maximum 210 LSP Bandwidth at priority 7 of the link. 212 5.4. Link Protection Type sub-TLV 214 The Link Protection Type sub-TLV represents the protection capability 215 that exists on a link. It is desirable to carry this information so 216 that it may be used by the path computation algorithm to set up LSPs 217 with appropriate protection characteristics. 219 In the Traffic Engineering LSA, the Link Protection Type sub-TLV is a 220 sub-TLV of the Link TLV, with type 14, and length of four octets, the 221 first of which is a bit vector describing the protection capabilities 222 of the link. They are: 224 0x01 Extra Traffic 225 If the link is Extra Traffic, it indicates that these links are 226 protecting other (primary) links. The LSPs on a link of this 227 type will be lost if the primary links being protected fail. 229 0x02 Unprotected 230 If the link is Unprotected, it means that there is no backup link 231 for traffic being carried on the link. 233 0x04 Shared 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 0x08 Dedicated 1:1 243 If the link has Dedicated 1:1 protection, it means that for each 244 primary data-bearing channel, there is one disjoint backup data- 245 bearing channel reserved to carry the traffic. Additionally, the 246 protection data-bearing channel MAY carry low-priority preemptable 247 traffic. The bandwidth of backup data-bearing channels will be 248 announced in the unreserved bandwidth sub-TLV at the appropriate 249 priority. 251 0x10 Dedicated 1+1 252 If the link has Dedicated 1+1 protection, it means that a disjoint 253 backup data-bearing channel is reserved and dedicated for 254 protecting the primary data-bearing channel. This backup data- 255 bearing channel is not shared by any other connection, and traffic 256 is duplicated and carried simultaneously over both channels. 258 0x20 Enhanced 259 If the link has Enhanced protection, it indicates that a protection 260 scheme that is more reliable than Dedicated 1+1 is being used, 261 e.g., 4 fiber BLSR/MS-SPRING to protect this link. 263 0x40 Reserved 264 0x80 Reserved 266 The second octet gives a priority value such that a new connection 267 with a higher priority (i.e., numerically lower than this value) is 268 guaranteed to be setup on a primary (or working) channel, and not on 269 a secondary (or protect) channel. 271 The format of the Link Protection Type sub-TLV is as shown below: 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | 14 | Length | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 |Link Prot. Type| Working Pri | Reserved | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 The Link Protection Type sub-TLV is optional and if an LSA does not 282 carry the TLV, then the Link Protection Type is unknown. The 283 protection capability of a link is typically pre-configured and does 284 not change dynamically over time. The working priority value is pre- 285 configured and does not depend on the traffic characteristics on the 286 primary data-bearing channel. 288 5.5. Link Descriptor sub-TLV 290 The Link Descriptor TLV represents the characteristics of the link, 291 in particular the link type and the bit transmission rate. These 292 characteristics represent one of the constraints on the type of LSPs 293 that could be carried over the link. 295 These characteristics should not be confused with the physical link 296 encoding or multiplex structure (if any). For example there are 297 systems where four OC-48s are switched and transported over a single 298 fiber via wavelength division multiplexing (WDM) technology. There 299 are systems where four OC-48s are transported in a transparent OC-192 300 time division multiplex (TDM) structure, i.e., all the overheads of 301 the OC-48's are persevered. In both these cases the essential 302 information from a routing perspective is that both of the links can 303 transport media of type OC-48. 305 In the Traffic Engineering LSA, the Link Descriptor sub-TLV is a sub- 306 TLV of the Link TLV, with type 15. The length is the length of the 307 list of Link Descriptors in octets. Each Link descriptor element 308 consists of the following fields: the first field is a one-octet 309 value which defines the link encoding type, the second field is a 310 one-octet value which defines the lowest priority at which that link 311 encoding type is available, the next two-octets are reserved, the 312 next field is four-octets and specifies the minimum reservable 313 bandwidth (in IEEE floating point format, the unit being bytes per 314 second) for this link encoding type, and the last four-octets 315 specifies the maximum reservable bandwidth (in IEEE floating point 316 format, the unit being bytes per second) for this link encoding type. 317 Link encoding type values are taken from the following list: 319 Value Link Encoding Type 320 1 Standard SONET 321 2 Arbitrary SONET 322 3 Standard SDH 323 4 Arbitrary SDH 324 5 Clear 325 6 GigE 326 7 10GigE 328 The format of the Link Descriptors is shown in the next figure. 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Link Type | Pri | Reserved | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Minimum Reservable Bandwidth | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Maximum Reservable Bandwidth | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 A link having Standard SONET (or Standard SDH) link encoding type can 341 switch data at a minimum rate, which is given by the Minimum 342 Reservable Bandwidth on that link, and the maximum rate is given by 343 the Maximum Reservable Bandwidth on that link. Typical values of 344 these are enumerated in the GMPLS signaling draft [6]. In other 345 words, the Minimum and Maximum Reservable Bandwidth represents the 346 leaf and the root of one branch within the structure of the SONET (or 347 SDH) hierarchy. An LSP on that link may reserve any bit transmission 348 rate that is allowed by the SONET (or SDH) hierarchy between the 349 minimum and maximum reservable values (the spectrum is discrete). 350 For example, consider a branch of SONET multiplexing tree : VT-1.5, 351 STS-1, STS-3c, STS-12c, STS-48c, STS-192c. If it is possible to 352 establish all these connections on a OC-192 link, it can be 353 advertised as follows: Minimum Reservable Bandwidth VT-1.5 and 354 Maximum Reservable Bandwidth STS-192. 356 A link having Arbitrary SONET (or Arbitrary SDH) link encoding type 357 can switch data at a minimum rate, which is given by the Minimum 358 Reservable Bandwidth on that link, and the maximum rate is given by 359 the Maximum Reservable Bandwidth on that link. Typical values of 360 these are enumerated in the GMPLS signaling draft [6]. An LSP on 361 that link may reserve any bit transmission rate that is a multiple of 362 the Minimum Reservable Bandwidth between the minimum and maximum 363 reservable values (the spectrum is discrete). 365 To handle the case where a link could support multiple branches of 366 the SONET (or SDH) multiplexing hierarchy, one could use multiple LSP 367 descriptors. For example, if a link supports VT-1.5 and VT-2 (which 368 are not part of same branch of SONET multiplexing tree), then it 369 could advertise two LSP descriptors, one for each one. 371 For a link with Clear encoding, the minimum and maximum reservable 372 bandwidth will imply that the optical path is tuned to carry traffic 373 within those range of values. (Note that it should be possible to 374 carry OC-x as well as GigE or any other encoding format, as long as 375 the bit transmission rate of the data to be carried is within this 376 range.) 378 For other encoding types, the minimum and maximum reservable 379 bandwidth should be set to have the same values. 381 Link Descriptors present a new constraint for LSP path computation. 383 On a bundled link we assume that either the whole link is configured 384 with the Link Descriptor Types, or each of its component links are 385 configured with the Link Descriptor Types. In the latter case, the 386 Link Descriptor Type of the bundled link is set to the set union of 387 the Link Descriptor Types for all the component links. 389 It is possible that Link Descriptor TLV will change over time, 390 reflecting the allocation/deallocation of component links. In 391 general, creation/deletion of an LSP on a link doesn't necessarily 392 result in changing the Link Descriptor of that link. For example, 393 assume that STS-1, STS-3c, STS-12c, STS-48c and STS-192c LSPs can be 394 established on a OC-192 link whose Link Type is SONET. Thus, 395 initially in the Link Descriptor the minimum reservable bandwidth is 396 set to STS-1, and the maximum reservable bandwidth is set of STS-192. 397 As soon as an LSP of STS-1 size is established on the link, it is no 398 longer capable of STS-192c. Therefore, the node advertises a 399 modified Link Descriptor indicating that the maximum reservable 400 bandwidth is no longer STS-192, but STS-48. If subsequently there is 401 another STS-1 LSP, there is no change in the Link Descriptor. The 402 Link Descriptor remains the same until the node can no longer 403 establish a STS-48c LSP over the link (which means that at this point 404 more than 144 time slots are taken by LSPs on the link). Once this 405 happened, the Link Descriptor is modified again, and the modified 406 Link Descriptor is advertised to other nodes. 408 Note that changes to the Link Descriptor TLV will also affect the 409 Unreserved Bandwidth sub-TLV with respect to bandwidth available on 410 the link. 412 5.6. Shared Risk Link Group TLV 414 A set of links may constitute a 'shared risk link group' (SRLG) if 415 they share a resource whose failure may affect all links in the set. 416 For example, two fibers in the same conduit would be in the same 417 SRLG. A link may belong to multiple SRLGs. Thus the SRLG TLV 418 describes a list of SRLGs that the link belongs to. An SRLG is 419 identified by a 32 bit number that is unique within an IGP domain. 421 The SRLG of a LSP is the union of the SRLGs of the links in the LSP. 422 The SRLG of a bundled link is the union of the SRLGs of all the 423 component links. The SRLG values are an unordered list of 4 octet 424 numbers that the link belongs to. 426 If an LSR is required to have multiple diversely routed LSPs to 427 another LSR, the path computation should attempt to route the paths 428 so that they do not have any links in common, and such that the path 429 SRLGs are disjoint. 431 The SRLG sub-TLV is a sub-TLV of the Link TLV with type 16. The 432 length is the length of the list in octets. The value is an 433 unordered list of 32 bit numbers that are the SRLGs that the link 434 belongs to. The format is as shown below: 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | 16 | 4 * No. of SRLGs in link | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Shared Risk Link Group Value | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | ............ | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Shared Risk Link Group Value | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 The SRLG TLV starts with a configured value and does not change over 449 time, unless manually reconfigured. The SRLG TLV is optional and if 450 an LSA doesn't carry the SRLG TLV, then it means that SRLG of that 451 link is unknown. 453 6. Security Considerations 455 The sub-TLVs proposed in this document does not raise any new 456 security concerns. 458 7. Acknowledgements 460 The authors would like to thank Suresh Katukam, Jonathan Lang and 461 Quaizar Vohra for their comments on the draft. 463 8. References 465 [1] Awduche, D., Rekhter, Y., Drake, J., Coltun, R., "Multi- 466 Protocol Lambda Switching: Combining MPLS Traffic Engineering 467 Control With Optical Crossconnects", 468 draft-awduche-mpls-te-optical-02.txt (work in progress) 470 [2] Basak, D., Awduche, D., Drake, J., Rekhter, Y., "Multi- 471 protocol Lambda Switching: Issues in Combining MPLS Traffic 472 Engineering Control With Optical Crossconnects", 473 draft-basak-mpls-oxc-issues-01.txt (work in progress) 475 [3] Katz, D., Yeung, D., "Traffic Engineering Extensions to OSPF", 476 draft-katz-yeung-ospf-traffic-04.txt (work in progress) 478 [4] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in MPLS 479 Traffic Engineering", draft-kompella-mpls-bundle-05.txt (work 480 in progress) 482 [5] Kompella, K., Rekhter, Y., "LSP Hierarchy with MPLS TE", 483 draft-ietf-mpls-lsp-hierarchy-01.txt (work in progress) 485 [6] Generalized MPLS Group, "Generalized MPLS - Signaling Functional 486 Description", draft-ietf-mpls-generalized-signaling-02.txt (work 487 in progress) 489 [7] Lang J., Mitra K., Drake J., Kompella K., Rekhter Y., Berger L., 490 Saha, D., Sandick, H., and Basak D., "Link Management Protocol", 491 draft-ietf-mpls-lmp-02.txt (work in progress) 493 9. Authors' Information 495 Kireeti Kompella 496 Juniper Networks, Inc. 497 1194 N. Mathilda Ave 498 Sunnyvale, CA 94089 499 Email: kireeti@juniper.net 501 Yakov Rekhter 502 Juniper Networks, Inc. 503 1194 N. Mathilda Ave 504 Sunnyvale, CA 94089 505 Email: yakov@juniper.net 507 Ayan Banerjee 508 Calient Networks 509 5853 Rue Ferrari 510 San Jose, CA 95138 511 Phone: +1.408.972.3645 512 Email: abanerjee@calient.net 514 John Drake 515 Calient Networks 516 5853 Rue Ferrari 517 San Jose, CA 95138 518 Phone: (408) 972-3720 519 Email: jdrake@calient.net 521 Greg Bernstein 522 Ciena Corporation 523 10480 Ridgeview Court 524 Cupertino, CA 94014 525 Phone: (408) 366-4713 526 Email: greg@ciena.com 527 Don Fedyk 528 Nortel Networks Corp. 529 600 Technology Park Drive 530 Billerica, MA 01821 531 Phone: +1-978-288-4506 532 Email: dwfedyk@nortelnetworks.com 534 Eric Mannie 535 GTS Network Services 536 RDI Department, Core Network Technology Group 537 Terhulpsesteenweg, 6A 538 1560 Hoeilaart, Belgium 539 Phone: +32-2-658.56.52 540 E-mail: eric.mannie@gtsgroup.com 542 Debanjan Saha 543 Tellium Optical Systems 544 2 Crescent Place 545 P.O. Box 901 546 Ocean Port, NJ 07757 547 Phone: (732) 923-4264 548 Email: dsaha@tellium.com 550 Vishal Sharma 551 Jasmine Networks, Inc. 552 3061 Zanker Rd, Suite B 553 San Jose, CA 95134 554 Phone: (408) 895-5000