idnits 2.17.1 draft-ietf-ccamp-gmpls-routing-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? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 are 3 instances of too long lines in the document, the longest one being 3 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 192: '...e interface is unidirectional), A MUST...' RFC 2119 keyword, line 195: '...ed to L' by B, A MAY include the Incom...' RFC 2119 keyword, line 371: '...mpatibility, one MAY set the Maximum B...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 544 has weird spacing: '...terface on an...' -- 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) == Missing Reference: 'OSFP-TE' is mentioned on line 113, but not defined == Missing Reference: 'Standard SONET' is mentioned on line 735, but not defined == Missing Reference: 'Arbitrary SONET' is mentioned on line 529, but not defined == 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. 'ISIS-TE') == 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-05 == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-05 == Outdated reference: A later version (-19) exists of draft-ietf-isis-gmpls-extensions-02 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-gmpls-extensions (ref. 'GMPLS-ISIS') == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-ospf-gmpls-extensions-00 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-00 == Outdated reference: A later version (-02) exists of draft-ouldbrahim-bgpgmpls-ovpn-01 -- Possible downref: Normative reference to a draft: ref. 'OVPN' Summary: 12 errors (**), 0 flaws (~~), 14 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kompella (Juniper Networks) 3 Internet Draft Y. Rekhter (Juniper Networks) 4 Expiration Date: March 2002 A. Banerjee (Calient Networks) 5 J. Drake (Calient Networks) 6 G. Bernstein (Ciena) 7 D. Fedyk (Nortel Networks) 8 E. Mannie (GTS Network) 9 D. Saha (Tellium) 10 V. Sharma (Metanoia, Inc.) 11 D. Basak (AcceLight Networks) 13 Routing Extensions in Support of Generalized MPLS 15 draft-ietf-ccamp-gmpls-routing-00.txt 17 1. Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as ``work in progress.'' 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 2. Abstract 40 This document specifies routing extensions in support of Generalized 41 Multi-Protocol Label Switching (GMPLS). 43 3. Summary for Sub-IP Area 45 3.1. Summary 47 This document specifies routing extensions in support of Generalized 48 Multi-Protocol Label Switching (GMPLS). 50 3.2. Where does it fit in the Picture of the Sub-IP Work 52 This work fits squarely in the CCAMP box. 54 3.3. Why is it Targeted at this WG 56 This draft is targeted at the CCAMP WG, because this draft specifies 57 the extensions to the link state routing protocols in support of 58 GMPLS, and because GMPLS is within the scope of CCAMP WG. 60 3.4. Justification 62 The WG should consider this document as it specifies the extensions 63 to the link state routing protocols in support of GMPLS. 65 4. Introduction 67 This document specifies routing extensions in support of carrying 68 link state information for Generalized Multi-Protocol Label Switching 69 (GMPLS). This document enhances the routing extensions [ISIS-TE], 70 [OSPF-TE] required to support MPLS Traffic Engineering. 72 5. GMPLS TE Links 74 Traditionally, a TE link is advertised as an adjunct to a "regular" 75 link, i.e., a routing adjacency is brought up on the link, and when 76 the link is up, both the regular SPF properties of the link 77 (basically, the SPF metric) and the TE properties of the link are 78 then advertised. 80 GMPLS challenges this notion in three ways. First, links that are 81 not capable of sending and receiving on a packet-by-packet basis may 82 yet have TE properties; however, a routing adjacency cannot be 83 brought up on such links. Second, a Label Switched Path can be 84 advertised as a point-to-point TE link (see [LSP-HIER]); thus, an 85 advertised TE link may be between a pair of nodes that don't have a 86 routing adjacency with each other. Finally, a number of links may be 87 advertised as a single TE link (perhaps for improved scalability), so 88 again, there is no longer a one-to-one association of a regular 89 routing adjacency and a TE link. 91 Thus we have a more general notion of a TE link. A TE link is a 92 "logical" link that has TE properties. The link is logical in a sense 93 that it represents a way to map the information about certain 94 physical resources (and their properties) into the information that 95 is used by Constrained SPF for the purpose of path computation. Some 96 of the properties of a TE link may be configured on the advertising 97 Label Switching Router (LSR), others which may be obtained from other 98 LSRs by means of some protocol, and yet others which may be deduced 99 from the component(s) of the TE link. 101 A TE link between a pair of LSRs doesn't imply the existence of a 102 routing adjacency between these LSRs. 104 A TE link must have some means by which the advertising LSR can know 105 of its liveness (this means may be routing hellos, but is not limited 106 to routing hellos). When an LSR knows that a TE link is up, and can 107 determine the TE link's TE properties, the LSR may then advertise 108 that link to its (regular) neighbors. 110 In this document, we call the interfaces over which regular routing 111 adjacencies are established "control channels". 113 [ISIS-TE] and [OSFP-TE] define the canonical TE properties, and say 114 how to associate TE properties to regular (packet-switched) links. 115 This document extends the set of TE properties, and also says how to 116 associate TE properties with non-packet-switched links such as links 117 between Optical Cross-Connects (OXCs). [LSP-HIER] says how to 118 associate TE properties with links formed by Label Switched Paths; 119 [LINK-BUNDLE] says how to associate TE properties with a "bundle" of 120 links. 122 5.1. Excluding data traffic from control channels 124 The control channels between nodes in a GMPLS network, such as OXCs, 125 SONET cross-connects and/or routers, are generally meant for control 126 and administrative traffic. These control channels are advertised 127 into routing as normal links as mentioned in the previous section; 128 this allows the routing of (for example) RSVP messages and telnet 129 sessions. However, if routers on the edge of the optical domain 130 attempt to forward data traffic over these channels, the channel 131 capacity will quickly be exhausted. 133 In order to keep these control channels from being advertised into 134 the user data plane a variety of techniques can be used. 136 If one assumes that data traffic is sent to BGP destinations, and 137 control traffic to IGP destinations, then one can exclude data 138 traffic from the control plane by restricting BGP nexthop resolution. 139 (It is assumed that OXCs are not BGP speakers.) Suppose that a 140 router R is attempting to install a route to a BGP destination D. R 141 looks up the BGP nexthop for D in its IGP's routing table. Say R 142 finds that the path to the nexthop is over interface I. R then 143 checks if it has an entry in its Link State database associated with 144 the interface I. If it does, and the link is not packet-switch 145 capable (see [LSP_HIER]), R installs a discard route for destination 146 D. Otherwise, R installs (as usual) a route for destination D with 147 nexthop I. Note that R need only do this check if it has packet- 148 switch incapable links; if all of its links are packet-switch 149 capable, then clearly this check is redundant. 151 In other instances it may be desirable to keep the whole address 152 space of a GMPLS routing plane disjoint from the endpoint addresses 153 in another portion of the GMPLS network. For example, the addresses 154 of a carrier network where the carrier uses GMPLS but does not wish 155 to expose the internals of the addressing or topology. In such a 156 network the control channels are never advertised into the end data 157 network. In this instance, independent mechanisms are used to 158 advertise the data addresses over the carrier network. The Optical 159 VPNs architecture [OVPN] discusses a mechanism for automating the 160 distribution of independent addresses. 162 Other techniques for excluding data traffic from control channels may 163 also be needed. 165 6. GMPLS Routing Enhancements 167 In this section we define the enhancements to the TE properties of 168 GMPLS TE links. Encoding of this information in IS-IS is specified in 169 [GMPLS-ISIS]. Encoding of this information in OSPF is specified in 170 [GMPLS-OSPF]. 172 6.1. Support for unnumbered interfaces 174 Supporting unnumbered interfaces includes carrying the information 175 about the identity of the interfaces. 177 6.1.1. Outgoing Interface Identifier 179 A link from LSR A to LSR B may be assigned an "outgoing interface 180 identifier". This identifier is a non-zero 32-bit number that is 181 assigned by LSR A. This identifier must be unique within the scope of 182 A. 184 6.1.2. Incoming Interface Identifier 186 Suppose there is a link L from A to B. Suppose further that the link 187 L' from B to A that corresponds to the same interface as L has been 188 assigned an outgoing interface identifier by B. The "incoming 189 interface identifier" for L (from A's point of view) is defined as 190 the outgoing interface identifier for L' (from B's point of view). 192 If no such L' exists (e.g., the interface is unidirectional), A MUST 193 NOT advertise an Incoming Interface Identifier. If A knows that such 194 an L' exists, but does not know the outgoing interface identifier 195 assigned to L' by B, A MAY include the Incoming Interface Identifier 196 with a value of 0. 198 6.2. Link Protection Type 200 The Link Protection Type represents the protection capability that 201 exists for a link. It is desirable to carry this information so that 202 it may be used by the path computation algorithm to set up LSPs with 203 appropriate protection characteristics. This information is organized 204 in a hierarchy where typically the minimum acceptable protection is 205 specified at path instantiation and a path selection technique is 206 used to find a path that satisfies at least the minimum acceptable 207 protection. Protection schemes are presented in order from lowest to 208 highest protection. 210 This document defines the following protection capabilities: 212 Extra Traffic 213 If the link is of type Extra Traffic, it means that the link is 214 protecting another link or links. The LSPs on a link of this type 215 will be lost if any of the links it is protecting fail. 217 Unprotected 218 If the link is of type Unprotected, it means that there is no 219 other link protecting this link. The LSPs on a link of this type 220 will be lost if the link fails. 222 Shared 223 If the link is of type Shared, it means that there are one or more 224 disjoint links of type Extra Traffic that are protecting this 225 link. These Extra Traffic links are shared between one or more 226 links of type Shared. 228 Dedicated 1:1 229 If the link is of type Dedicated 1:1, it means that there is one 230 dedicated disjoint link of type Extra Traffic that is protecting 231 this link. 233 Dedicated 1+1 234 If the link is of type Dedicated 1+1, it means that a dedicated 235 disjoint link is protecting this link. However, the protecting 236 link is not advertised in the link state database and is therefore 237 not available for the routing of LSPs. 239 Enhanced 240 If the link is of type Enhanced, it means that a protection scheme 241 that is more reliable than Dedicated 1+1, e.g., 4 fiber BLSR/MS- 242 SPRING, is being used to protect this link. 244 The Link Protection Type is optional, and if a Link State 245 Advertisement doesn't carry this information, then the Link 246 Protection Type is unknown. 248 6.3. Shared Risk Link Group Information 250 A set of links may constitute a 'shared risk link group' (SRLG) if 251 they share a resource whose failure may affect all links in the set. 252 For example, two fibers in the same conduit would be in the same 253 SRLG. A link may belong to multiple SRLGs. Thus the SRLG 254 Information describes a list of SRLGs that the link belongs to. An 255 SRLG is identified by a 32 bit number that is unique within an IGP 256 domain. The SRLG Information is an unordered list of SRLGs that the 257 link belongs to. 259 The SRLG of a LSP is the union of the SRLGs of the links in the LSP. 260 The SRLG of a bundled link is the union of the SRLGs of all the 261 component links. 263 If an LSR is required to have multiple diversely routed LSPs to 264 another LSR, the path computation should attempt to route the paths 265 so that they do not have any links in common, and such that the path 266 SRLGs are disjoint. 268 The SRLG Information may start with a configured value, in which case 269 it does not change over time, unless reconfigured. 271 The SRLG Information is optional and if a Link State Advertisement 272 doesn't carry the SRLG Information, then it means that SRLG of that 273 link is unknown. 275 6.4. Interface Switching Capability Descriptor 277 In the context of this document we say that a link is connected to a 278 node by an interface. In the context of GMPLS interfaces may have 279 different switching capabilities. For example an interface that 280 connects a given link to a node may not be able to switch individual 281 packets, but it may be able to switch channels within a SONET 282 payload. Interfaces at each end of a link need not have the same 283 switching capabilities. Interfaces on the same node need not have 284 the same switching capabilities. 286 The Interface Switching Capability Descriptor describes switching 287 capability of an interface. For bi-directional links, the switching 288 capabilities of an interface are defined to be the same in either 289 direction. I.e., for data entering the node through that interface 290 and for data leaving the node through that interface. 292 A Link State Advertisement of a link carries the Interface Switching 293 Capability Descriptor(s) only of the near end (the end incumbent on 294 the LSR originating the advertisement). 296 An LSR performing path computation uses the Link State Database to 297 determine whether a link is unidirectional or bidirectional. 299 For a bidirectional link the LSR uses its Link State Database to 300 determine the Interface Switching Capability Descriptor(s) of the 301 far-end of the link, as bidirectional links with different Interface 302 Switching Capabilities at its two ends are allowed. 304 For an unidirectional link it is assumed that the Interface Switching 305 Capability Descriptor at the far-end of the link is the same as at 306 the near-end. Thus, an unidirectional link is required to have the 307 same interface switching capabilities at both ends. This seems a 308 reasonable assumption given that unidirectional links arise only with 309 packet forwarding adjacencies and for these both ends belong to the 310 same level of the PSC hierarchy. 312 This document defines the following Interface Switching Capabilities: 314 Packet-Switch Capable-1 (PSC-1) 315 Packet-Switch Capable-2 (PSC-2) 316 Packet-Switch Capable-3 (PSC-3) 317 Packet-Switch Capable-4 (PSC-4) 318 Layer-2 Switch Capable (L2SC) 319 Time-Division-Multiplex Capable (TDM) 320 Lambda-Switch Capable (LSC) 321 Fiber-Switch Capable (FSC) 323 If there is no Interface Switching Capability Descriptor for an 324 interface, the interface is assumed to be packet-switch capable 325 (PSC-1). 327 Interface Switching Capability Descriptors present a new constraint 328 for LSP path computation. 330 Irrespective of a particular Interface Switching Capability, the 331 Interface Switching Capability Descriptor always includes information 332 about the encoding supported by an interface. The defined encodings 333 are the same as LSP Encoding as defined in [GMPLS-SIG]. 335 Depending on a particular Interface Switching Capability, the 336 Interface Switching Capability Descriptor may include additional 337 information, as specified below. 339 6.4.1. Layer-2 Switch Capable 341 If an interface is of type L2SC, it means that the node receiving 342 data over this interface can switch the received frames based on the 343 layer 2 address. For example, an interface associated with a link 344 terminating on an ATM switch would be considered L2SC. 346 6.4.2. Packet-Switch Capable 348 If an interface is of type PSC-1 through PSC-4, it means that the 349 node receiving data over this interface can switch the received data 350 on a packet-by-packet basis. The various levels of PSC establish a 351 hierarchy of LSPs tunneled within LSPs. 353 For Packet-Switch Capable interfaces the additional information 354 includes Maximum LSP Bandwidth. 356 For a simple (unbundled) link its Maximum LSP Bandwidth at priority p 357 is defined to be the smaller of its unreserved bandwidth at priority 358 p and its Maximum Reservable Bandwidth. 360 The Maximum LSP Bandwidth of a bundled link at priority p is defined 361 to be the maximum of the Maximum LSP Bandwidth at priority p of each 362 component link. 364 The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth 365 ([ISIS-TE], [OSPF-TE]). However, while Maximum Bandwidth is a single 366 fixed value (usually simply the link capacity), Maximum LSP Bandwidth 367 is carried per priority, and may vary as LSPs are set up and torn 368 down. 370 Although Maximum Bandwidth is to be deprecated, for backward 371 compatibility, one MAY set the Maximum Bandwidth to the Maximum LSP 372 Bandwidth at priority 7. 374 6.4.3. Time-Division Multiplex Capable 376 If an interface is of type TDM, it means that the node receiving data 377 over this interface can multiplex or demultiplex channels within a 378 SONET/SDH payload. 380 For Time-Division Multiplex Capable interfaces the additional 381 information includes Maximum LSP Bandwidth, the information on 382 whether the interface supports Standard or Arbitrary SONET/SDH, and 383 Minimum LSP Bandwidth. 385 For a simple (unbundled) link the Maximum LSP Bandwidth at priority p 386 is defined as the maximum bandwidth an LSP at priority p could 387 reserve. 389 The Maximum LSP Bandwidth of a bundled link at priority p is defined 390 to be the maximum of the Maximum LSP Bandwidth at priority p of each 391 component link. 393 The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP 394 could reserve. 396 Typical values for the Minimum LSP Bandwidth and for the Maximum LSP 397 Bandwidth are enumerated in [GMPLS-SIG]. 399 On an interface having Standard SONET (or Standard SDH) multiplexing, 400 an LSP at priority p could reserve any bandwidth allowed by the 401 branch of the SONET/SDH hierarchy, with the leaf and the root of the 402 branch being defined by the Minimum LSP Bandwidth and the Maximum LSP 403 Bandwidth at priority p. 405 On an interface having Arbitrary SONET (or Arbitrary SDH) 406 multiplexing, an LSP at priority p could reserve any bandwidth 407 between the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at 408 priority p, provided that the bandwidth reserved by the LSP is a 409 multiple of the Minimum LSP Bandwidth. 411 A way to handle the case where an interface supports multiple 412 branches of the SONET (or SDH) multiplexing hierarchy, multiple 413 Interface Switching Capability Descriptors would be advertised, one 414 per branch. For example, if an interface supports VT-1.5 and VT-2 415 (which are not part of same branch of SONET multiplexing tree), Then 416 it could advertise two descriptors, one for each one. 418 6.4.4. Lambda-Switch Capable 420 If an interface is of type LSC, it means that the node receiving data 421 over this interface can recognize and switch individual lambdas 422 within the interface. An interface that allows only one lambda per 423 interface, and switches just that lambda is of type LSC. 425 The additional information includes Reservable Bandwidth per 426 priority, which specifies the bandwidth of an LSP that could be 427 supported by the interface at a given priority number. 429 A way to handle the case of multiple data rates or multiple encodings 430 within a single TE Link, multiple Interface Switching Capability 431 Descriptors would be advertised, one per supported data rate and 432 encoding combination. For example, an LSC interface could support 433 the establishment of LSC LSPs at both OC-48c and OC-192c data rates. 435 6.4.5. Fiber-Switch Capable 437 If an interface is of type FSC, it means that the node receiving data 438 over this interface can switch the entire contents to another 439 interface (without distinguishing lambdas, channels or packets). 440 I.e., an interface of type FSC switches at the granularity of an 441 entire interface, and can not extract individual lambdas within the 442 interface. An interface of type FSC can not restrict itself to just 443 one lambda. 445 6.4.6. Multiple Switching Capabilities per interface 447 An interface that connects a link to an LSR may support not one, but 448 several Interface Switching Capabilities. For example, consider a 449 fiber link carrying a set of lambdas that terminates on an LSR 450 interface that could either cross-connect one of these lambdas to 451 some other outgoing optical channel, or could terminate the lamdba, 452 and extract (demultiplex) data from that lambda using TDM, and then 453 cross-connect these TDM channels to some outgoing TDM channels. To 454 support this a Link State Advertisement may carry a list of Interface 455 Switching Capabilities Descriptors. 457 6.4.7. Other issues 459 It is possible that Interface Switching Capability Descriptor will 460 change over time, reflecting the allocation/deallocation of LSPs. 461 For example, assume that STS-1, STS-3c, STS-12c, STS-48c and STS-192c 462 LSPs can be established on a OC-192 interface whose Encoding Type is 463 SONET (or to be more precise, SONET ANSI T1.105-1995). Thus, 464 initially in the Interface Switching Capability Descriptor the 465 Minimum LSP Bandwidth is set to STS-1, and Maximum LSP Bandwidth is 466 set to STS-192 for all priorities. As soon as an LSP of STS-1 size 467 at priority 1 is established on the interface, it is no longer 468 capable of STS-192c for all but LSPs at priority 0. Therefore, the 469 node advertises a modified Interface Switching Capability Descriptor 470 indicating that the Maximum LSP Bandwidth is no longer STS-192, but 471 STS-48 for all but priority 0 (at priority 0 the Maximum LSP 472 Bandwidth is still STS-192). If subsequently there is another STS-1 473 LSP, there is no change in the Interface Switching Capability 474 Descriptor. The Descriptor remains the same until the node can no 475 longer establish a STS-48c LSP over the interface (which means that 476 at this point more than 144 time slots are taken by LSPs on the 477 interface). Once this happened, the Descriptor is modified again, 478 and the modified Descriptor is advertised to other nodes. 480 6.4.8. Examples of Interface Switching Capability Descriptor 482 6.4.8.1. STS-48 POS Interface on a LSR 484 Interface Switching Capability Descriptor: 485 Interface Switching Capability = PSC-1 486 Encoding = SONET ANSI T1.105-1995 487 Max LSP Bandwidth[p] = 2.5 Gbps, for all p 489 If multiple links with such interfaces were to be advertised as one 490 TE link, link bundling techniques should be used. 492 6.4.8.2. GigE Packet Interface on a LSR 494 Interface Switching Capability Descriptor: 495 Interface Switching Capability = PSC-1 496 Encoding = Ethernet 802.3 497 Max LSP Bandwidth[p] = 1.0 Gbps, for all p 499 If multiple links with such interfaces were to be advertised as one 500 TE link, link bundling techniques should be used. 502 6.4.8.3. OC-192 SONET Interface on a Digital Cross Connect with Standard 503 SONET 505 Consider a branch of SONET multiplexing tree : VT-1.5, STS-1, STS-3c, 506 STS-12c, STS-48c, STS-192c. If it is possible to establish all these 507 connections on a OC-192 interface, the Interface Switching Capability 508 Descriptor of that interface can be advertised as follows: 510 Interface Switching Capability Descriptor: 511 Interface Switching Capability = TDM [Standard SONET] 512 Encoding = SONET ANSI T1.105-1995 513 Min LSP Bandwidth = VT1.5 514 Max LSP Bandwidth[p] = STS192, for all p 516 If multiple links with such interfaces were to be advertised as one 517 TE link, link bundling techniques should be used. 519 6.4.8.4. OC-192 SONET Interface on a Digital Cross Connect with two 520 types of SONET multiplexing hierarchy supported 522 Interface Switching Capability Descriptor 1: 523 Interface Switching Capability = TDM [Standard SONET] 524 Encoding = SONET ANSI T1.105-1995 525 Min LSP Bandwidth = VT1.5 526 Max LSP Bandwidth[p] = STS192, for all p 528 Interface Switching Capability Descriptor 2: 529 Interface Switching Capability = TDM [Arbitrary SONET] 530 Encoding = SONET ANSI T1.105-1995 531 Min LSP Bandwidth = VT2 532 Max LSP Bandwidth[p] = STS192, for all p 534 If multiple links with such interfaces were to be advertised as one 535 TE link, link bundling techniques should be used. 537 6.4.8.5. Interface on an opaque OXC (SONET framed) 539 An "opaque OXC" is considered operationally an OXC, as the whole 540 lambda (carrying the SONET line) is switched transparently without 541 further multiplexing/demultiplexing, and either none of the SONET 542 overhead bytes, or at least the important ones are not changed. 544 An interface on an opaque OXC handles a single wavelength, and 545 cannot switch multiple wavelengths as a whole. Thus, an interface on 546 an opaque OXC is always LSC, and not FSC, irrespective of whether 547 there is DWDM external to it. 549 Note that if there is external DWDM, then the framing understood by 550 the DWDM must be same as that understood by the OXC. 552 A TE link is a group of interfaces on an OXC. All interfaces on a 553 given OXC are required to have identifiers unique to that OXC, and 554 these identifiers are used as port labels (see 3.2.1.1 of [GMPLS- 555 SIG]). 557 The following is an example of an interface switching capability 558 descriptor on a SONET framed opaque OXC: 560 Interface Switching Capability Descriptor: 561 Interface Switching Capability = LSC 562 Encoding = SONET ANSI T1.105-1995 563 Reservable Bandwidth = Determined by SONET Framer (say OC192) 564 6.4.8.6. Interface on a transparent OXC (PXC) with external DWDM that 565 understands SONET framing 567 This example assumes that DWDM and PXC are connected in such a way 568 that each interface (port) on the PXC handles just a single 569 wavelength. Thus, even if in principle an interface on the PXC could 570 switch multiple wavelengths as a whole, in this particular case an 571 interface on the PXC is considered LSC, and not FSC. 573 _______ 574 | | 575 /|___| | 576 | |___| PXC | 577 ========| |___| | 578 | |___| | 579 \| |_______| 580 DWDM 581 (SONET framed) 583 A TE link is a group of interfaces on the PXC. All interfaces on a 584 given PXC are required to have identifiers unique to that PXC, and 585 these identifiers are used as port labels (see 3.2.1.1 of [GMPLS- 586 SIG]). 588 The following is an example of an interface switching capability 589 descriptor on a transparent OXC (PXC) with external DWDM that 590 understands SONET framing: 592 Interface Switching Capability Descriptor: 593 Interface Switching Capability = LSC 594 Encoding = SONET ANSI T1.105-1995 (comes from DWDM) 595 Reservable Bandwidth = Determined by DWDM (say OC192) 597 6.4.8.7. Interface on a transparent OXC (PXC) with external DWDM that is 598 transparent to bit-rate and framing 600 This example assumes that DWDM and PXC are connected in such a way 601 that each interface (port) on the PXC handles just a single 602 wavelength. Thus, even if in principle an interface on the PXC could 603 switch multiple wavelengths as a whole, in this particular case an 604 interface on the PXC is considered LSC, and not FSC. 606 _______ 607 | | 608 /|___| | 609 | |___| PXC | 610 ========| |___| | 611 | |___| | 612 \| |_______| 613 DWDM 614 (transparent to bit-rate and framing) 616 A TE link is a group of interfaces on the PXC. All interfaces on a 617 given PXC are required to have identifiers unique to that PXC, and 618 these identifiers are used as port labels (see 3.2.1.1 of [GMPLS- 619 SIG]). 621 The following is an example of an interface switching capability 622 descriptor on a transparent OXC (PXC) with external DWDM that is 623 transparent to bit-rate and framing: 625 Interface Switching Capability Descriptor: 626 Interface Switching Capability = LSC 627 Encoding = Photonic 628 Reservable Bandwidth = Determined by optical technology limits 630 6.4.8.8. Interface on a PXC with no external DWDM 632 The absence of DWDM in between two PXCs, implies that an interface is 633 not limited to one wavelength. Thus, the interface is advertised as 634 FSC. 636 A TE link is a group of interfaces on the PXC. All interfaces on a 637 given PXC are required to have identifiers unique to that PXC, and 638 these identifiers are used as port labels (see 3.2.1.1 of [GMPLS- 639 SIG]). 641 Interface Switching Capability Descriptor: 642 Interface Switching Capability = FSC 643 Encoding = Photonic 644 Reservable Bandwidth = Determined by optical technology limits 646 Note that this example assumes that the PXC does not restrict each 647 port to carry only one wavelength. 649 6.4.9. Example of interfaces that support multiple switching 650 capabilities 652 There can be many combinations possible, some are described below. 654 6.4.9.1. Interface on a PXC+TDM device with external DWDM 656 As discussed earlier, the presence of the external DWDM limits that 657 only one wavelength be on a port of the PXC. On such a port, the 658 attached PXC+TDM device can do one of the following. The wavelength 659 may be cross-connected by the PXC element to other out-bound optical 660 channel, or the wavelength may be terminated as a SONET interface and 661 SONET channels switched. 663 From a GMPLS perspective the PXC+TDM functionality is treated as a 664 single interface. The interface is described using two Interface 665 descriptors, one for the LSC and another for the TDM, with 666 appropriate parameters. For example, 668 Interface Switching Capability Descriptor: 669 Interface Switching Capability = LSC 670 Encoding = SONET ANSI T1.105-1995 (comes from WDM) 671 Reservable Bandwidth = OC192 673 and 675 Interface Switching Capability Descriptor: 676 Interface Switching Capability = TDM [Standard SONET] 677 Encoding = SONET ANSI T1.105-1995 678 Min LSP Bandwidth = VT1.5 679 Max LSP Bandwidth[p] = STS192, for all p 681 6.4.9.2. Interface on an opaque OXC+TDM device with external DWDM 683 An interface on an "opaque OXC+TDM" device would also be advertised 684 as LSC+TDM much the same way as the previous case. 686 6.4.9.3. Interface on a PXC+LSR device with external DWDM 688 As discussed earlier, the presence of the external DWDM limits that 689 only one wavelength be on a port of the PXC. On such a port, the 690 attached PXC+LSR device can do one of the following. The wavelength 691 may be cross-connected by the PXC element to other out-bound optical 692 channel, or the wavelength may be terminated as a Packet interface 693 and packets switched. 695 From a GMPLS perspective the PXC+LSR functionality is treated as a 696 single interface. The interface is described using two Interface 697 descriptors, one for the LSC and another for the PSC, with 698 appropriate parameters. For example, 699 Interface Switching Capability Descriptor: 700 Interface Switching Capability = LSC 701 Encoding = SONET ANSI T1.105-1995 (comes from WDM) 702 Reservable Bandwidth = OC192 704 and 706 Interface Switching Capability Descriptor: 707 Interface Switching Capability = PSC-1 708 Encoding = SONET ANSI T1.105-1995 709 Max LSP Bandwidth[p] = 10 Gbps, for all p 711 6.4.9.4. Interface on a TDM+LSR device 713 On a TDM+LSR device that offers a channelized SONET/SDH interface the 714 following may be possible: 716 - A subset of the SONET/SDH channels may be uncommitted. That is, 717 they are not currently in use and hence are available for 718 allocation. 720 - A second subset of channels may already be committed for transit 721 purposes. That is, they are already cross-connected by the 722 SONET/SDH cross connect function to other out-bound channels and 723 thus are not immediately available for allocation. 725 - Another subset of channels could be in use as terminal channels. 726 That is, they are already allocated by terminate on a packet 727 interface and packets switched. 729 From a GMPLS perspective the TDM+PSC functionality is treated as a 730 single interface. The interface is described using two Interface 731 descriptors, one for the TDM and another for the PSC, with 732 appropriate parameters. For example, 734 Interface Switching Capability Descriptor: 735 Interface Switching Capability = TDM [Standard SONET] 736 Encoding = SONET ANSI T1.105-1995 737 Min LSP Bandwidth = VT1.5 738 Max LSP Bandwidth[p] = STS192, for all p 740 and 742 Interface Switching Capability Descriptor: 743 Interface Switching Capability = PSC-1 744 Encoding = SONET ANSI T1.105-1995 745 Max LSP Bandwidth[p] = 10 Gbps, for all p 746 7. Security Considerations 748 The routing extensions proposed in this document do not raise any new 749 security concerns. 751 8. Acknowledgements 753 The authors would like to thank Suresh Katukam, Jonathan Lang and 754 Quaizar Vohra for their comments on the draft. 756 9. References 758 [ISIS-TE] Smit, H., Li, T., "IS-IS Extensions for Traffic 759 Engineering", draft-ietf-isis-traffic-02.txt (work in progress) 761 [LSP-HIER] Kompella, K., Rekhter, Y., "LSP Hierarchy with MPLS TE", 762 draft-ietf-mpls-lsp-hierarchy-01.txt (work in progress) 764 [GMPLS-SIG] Generalized MPLS Group, "Generalized MPLS - Signaling 765 Functional Description", draft-ietf-mpls-generalized-signaling-05.txt 766 (work in progress) 768 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 769 Extensions to OSPF", draft-katz-yeung-ospf-traffic-05.txt 771 [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS 772 Extensions in Support of Generalized MPLS", draft-ietf-isis-gmpls- 773 extensions-02.txt (work in progress) 775 [GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF 776 Extensions in Support of Generalized MPLS", draft-ietf-ccamp-ospf- 777 gmpls-extensions-00.txt (work in progress) 779 [LINK-BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling 780 in MPLS Traffic Engineering", draft-ietf-mpls-bundle-00.txt (work in 781 progress) 783 [OVPN] Ould-Brahim, H., Rekhter, Y., Fedyk, D., Ashwood-Smith, P., 784 Rosen, E., Mannie, E., Fang, L., Drake, J., "BGP/GMPLS Optical VPNs", 785 draft-ouldbrahim-bgpgmpls-ovpn-01.txt (work in progress) 786 10. Authors' Information 788 Kireeti Kompella 789 Juniper Networks, Inc. 790 1194 N. Mathilda Ave 791 Sunnyvale, CA 94089 792 Email: kireeti@juniper.net 794 Yakov Rekhter 795 Juniper Networks, Inc. 796 1194 N. Mathilda Ave 797 Sunnyvale, CA 94089 798 Email: yakov@juniper.net 800 Ayan Banerjee 801 Calient Networks 802 5853 Rue Ferrari 803 San Jose, CA 95138 804 Phone: +1.408.972.3645 805 Email: abanerjee@calient.net 807 John Drake 808 Calient Networks 809 5853 Rue Ferrari 810 San Jose, CA 95138 811 Phone: (408) 972-3720 812 Email: jdrake@calient.net 814 Greg Bernstein 815 Ciena Corporation 816 10480 Ridgeview Court 817 Cupertino, CA 94014 818 Phone: (408) 366-4713 819 Email: greg@ciena.com 820 Don Fedyk 821 Nortel Networks Corp. 822 600 Technology Park Drive 823 Billerica, MA 01821 824 Phone: +1-978-288-4506 825 Email: dwfedyk@nortelnetworks.com 827 Eric Mannie 828 GTS Network Services 829 RDI Department, Core Network Technology Group 830 Terhulpsesteenweg, 6A 831 1560 Hoeilaart, Belgium 832 Phone: +32-2-658.56.52 833 Email: eric.mannie@ebone.com 835 Debanjan Saha 836 Tellium Optical Systems 837 2 Crescent Place 838 P.O. Box 901 839 Ocean Port, NJ 07757 840 Phone: (732) 923-4264 841 Email: dsaha@tellium.com 843 Vishal Sharma 844 Metanoia, Inc. 845 335 Elan Village Lane, Unit 203 846 San Jose, CA 95134-2539 847 Phone: +1 408-943-1794 848 Email: v.sharma@ieee.org 850 Debashis Basak 851 AcceLight Networks, 852 70 Abele Rd, Bldg 1200 853 Bridgeville PA 15017 854 Email: dbasak@accelight.com