idnits 2.17.1 draft-ietf-ccamp-gmpls-routing-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 20 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 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 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 382: '...mpatibility, one MAY set the Maximum B...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 597 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 130, but not defined == Missing Reference: 'RFC3032' is mentioned on line 503, but not defined == Missing Reference: 'PSC' is mentioned on line 507, but not defined == Missing Reference: 'TDM' is mentioned on line 508, but not defined == Missing Reference: 'LSC' is mentioned on line 508, but not defined == Missing Reference: 'GMPLS-SONET-SDH' is mentioned on line 506, but not defined == Missing Reference: 'Standard SONET' is mentioned on line 788, but not defined == Missing Reference: 'Arbitrary SONET' is mentioned on line 582, 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 -- Possible downref: Non-RFC (?) normative reference: ref. 'LMP' == Outdated reference: A later version (-02) exists of draft-ouldbrahim-bgpgmpls-ovpn-01 -- Possible downref: Normative reference to a draft: ref. 'OVPN' Summary: 11 errors (**), 0 flaws (~~), 20 warnings (==), 4 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: August 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-02.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 group/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, and 96 by GMPLS signaling. This grouping/mapping must be done consistently 97 at both ends of the link. LMP [LMP] could be used to check/verify 98 this consistency. 100 Depending on the nature of resources that form a particular TE link, 101 for the purpose of GMPLS signaling in some cases the combination of 102 is sufficient to unambiguously identify 103 the appropriate resource used by an LSP. In other cases, the 104 combination of is not sufficient - such 105 cases are handled by using the link bundling construct [LINK-BUNDLE] 106 that allows to identify the resource by . 109 Some of the properties of a TE link may be configured on the 110 advertising Label Switching Router (LSR), others which may be 111 obtained from other LSRs by means of some protocol, and yet others 112 which may be deduced from the component(s) of the TE link. 114 A TE link between a pair of LSRs doesn't imply the existence of a 115 routing adjacency (e.g., an IGP adjacency) between these LSRs. As we 116 mentioned above, in certain cases a TE link between a pair of LSRs 117 could be advertised even if there is no routing adjacency at all 118 between the LSRs (e.g., when the TE link is a Forwarding Adjacency 119 (see [LSP-HIER])). 121 A TE link must have some means by which the advertising LSR can know 122 of its liveness (this means may be routing hellos, but is not limited 123 to routing hellos). When an LSR knows that a TE link is up, and can 124 determine the TE link's TE properties, the LSR may then advertise 125 that link to its (regular) neighbors. 127 In this document, we call the interfaces over which regular routing 128 adjacencies are established "control channels". 130 [ISIS-TE] and [OSFP-TE] define the canonical TE properties, and say 131 how to associate TE properties to regular (packet-switched) links. 132 This document extends the set of TE properties, and also says how to 133 associate TE properties with non-packet-switched links such as links 134 between Optical Cross-Connects (OXCs). [LSP-HIER] says how to 135 associate TE properties with links formed by Label Switched Paths. 137 5.1. Excluding data traffic from control channels 139 The control channels between nodes in a GMPLS network, such as OXCs, 140 SONET cross-connects and/or routers, are generally meant for control 141 and administrative traffic. These control channels are advertised 142 into routing as normal links as mentioned in the previous section; 143 this allows the routing of (for example) RSVP messages and telnet 144 sessions. However, if routers on the edge of the optical domain 145 attempt to forward data traffic over these channels, the channel 146 capacity will quickly be exhausted. 148 In order to keep these control channels from being advertised into 149 the user data plane a variety of techniques can be used. 151 If one assumes that data traffic is sent to BGP destinations, and 152 control traffic to IGP destinations, then one can exclude data 153 traffic from the control plane by restricting BGP nexthop resolution. 154 (It is assumed that OXCs are not BGP speakers.) Suppose that a 155 router R is attempting to install a route to a BGP destination D. R 156 looks up the BGP nexthop for D in its IGP's routing table. Say R 157 finds that the path to the nexthop is over interface I. R then 158 checks if it has an entry in its Link State database associated with 159 the interface I. If it does, and the link is not packet-switch 160 capable (see [LSP_HIER]), R installs a discard route for destination 161 D. Otherwise, R installs (as usual) a route for destination D with 162 nexthop I. Note that R need only do this check if it has packet- 163 switch incapable links; if all of its links are packet-switch 164 capable, then clearly this check is redundant. 166 In other instances it may be desirable to keep the whole address 167 space of a GMPLS routing plane disjoint from the endpoint addresses 168 in another portion of the GMPLS network. For example, the addresses 169 of a carrier network where the carrier uses GMPLS but does not wish 170 to expose the internals of the addressing or topology. In such a 171 network the control channels are never advertised into the end data 172 network. In this instance, independent mechanisms are used to 173 advertise the data addresses over the carrier network. The Optical 174 VPNs architecture [OVPN] discusses a mechanism for automating the 175 distribution of independent addresses. 177 Other techniques for excluding data traffic from control channels may 178 also be needed. 180 6. GMPLS Routing Enhancements 182 In this section we define the enhancements to the TE properties of 183 GMPLS TE links. Encoding of this information in IS-IS is specified in 184 [GMPLS-ISIS]. Encoding of this information in OSPF is specified in 185 [GMPLS-OSPF]. 187 6.1. Support for unnumbered links 189 An unnumbered link has to be a point-to-point link. An LSR at each 190 end of an unnumbered link assigns an identifier to that link. This 191 identifier is a non-zero 32-bit number that is unique within the 192 scope of the LSR that assigns it. 194 Consider an (unnumbered) link between LSRs A and B. LSR A chooses an 195 idenfitier for that link. So is LSR B. From A's perspective we refer 196 to the identifier that A assigned to the link as the "link local 197 identifier" (or just "local identifier"), and to the identifier that 198 B assigned to the link as the "link remote identifier" (or just 199 "remote identifier"). Likewise, from B's perspective the identifier 200 that B assigned to the link is the local identifier, and the 201 identifier that A assigned to the link is the remote identifier. 203 Support for unnumbered links in routing includes carrying information 204 about the identifiers of that link. Specifically, when an LSR 205 advertises an unnumbered TE link, the advertisement carries both the 206 local and the remote identifiers of the link. If the LSR doesn't 207 know the remote identifier of that link, the LSR should use a value 208 of 0 as the remote identifier. 210 6.2. Link Protection Type 212 The Link Protection Type represents the protection capability that 213 exists for a link. It is desirable to carry this information so that 214 it may be used by the path computation algorithm to set up LSPs with 215 appropriate protection characteristics. This information is organized 216 in a hierarchy where typically the minimum acceptable protection is 217 specified at path instantiation and a path selection technique is 218 used to find a path that satisfies at least the minimum acceptable 219 protection. Protection schemes are presented in order from lowest to 220 highest protection. 222 This document defines the following protection capabilities: 224 Extra Traffic 225 If the link is of type Extra Traffic, it means that the link is 226 protecting another link or links. The LSPs on a link of this type 227 will be lost if any of the links it is protecting fail. 229 Unprotected 230 If the link is of type Unprotected, it means that there is no 231 other link protecting this link. The LSPs on a link of this type 232 will be lost if the link fails. 234 Shared 235 If the link is of type Shared, it means that there are one or more 236 disjoint links of type Extra Traffic that are protecting this 237 link. These Extra Traffic links are shared between one or more 238 links of type Shared. 240 Dedicated 1:1 241 If the link is of type Dedicated 1:1, it means that there is one 242 dedicated disjoint link of type Extra Traffic that is protecting 243 this link. 245 Dedicated 1+1 246 If the link is of type Dedicated 1+1, it means that a dedicated 247 disjoint link is protecting this link. However, the protecting 248 link is not advertised in the link state database and is therefore 249 not available for the routing of LSPs. 251 Enhanced 252 If the link is of type Enhanced, it means that a protection scheme 253 that is more reliable than Dedicated 1+1, e.g., 4 fiber BLSR/MS- 254 SPRING, is being used to protect this link. 256 The Link Protection Type is optional, and if a Link State 257 Advertisement doesn't carry this information, then the Link 258 Protection Type is unknown. 260 6.3. Shared Risk Link Group Information 262 A set of links may constitute a 'shared risk link group' (SRLG) if 263 they share a resource whose failure may affect all links in the set. 264 For example, two fibers in the same conduit would be in the same 265 SRLG. A link may belong to multiple SRLGs. Thus the SRLG 266 Information describes a list of SRLGs that the link belongs to. An 267 SRLG is identified by a 32 bit number that is unique within an IGP 268 domain. The SRLG Information is an unordered list of SRLGs that the 269 link belongs to. 271 The SRLG of a LSP is the union of the SRLGs of the links in the LSP. 272 The SRLG of a bundled link is the union of the SRLGs of all the 273 component links. 275 If an LSR is required to have multiple diversely routed LSPs to 276 another LSR, the path computation should attempt to route the paths 277 so that they do not have any links in common, and such that the path 278 SRLGs are disjoint. 280 The SRLG Information may start with a configured value, in which case 281 it does not change over time, unless reconfigured. 283 The SRLG Information is optional and if a Link State Advertisement 284 doesn't carry the SRLG Information, then it means that SRLG of that 285 link is unknown. 287 6.4. Interface Switching Capability Descriptor 289 In the context of this document we say that a link is connected to a 290 node by an interface. In the context of GMPLS interfaces may have 291 different switching capabilities. For example an interface that 292 connects a given link to a node may not be able to switch individual 293 packets, but it may be able to switch channels within a SONET 294 payload. Interfaces at each end of a link need not have the same 295 switching capabilities. Interfaces on the same node need not have 296 the same switching capabilities. 298 The Interface Switching Capability Descriptor describes switching 299 capability of an interface. For bi-directional links, the switching 300 capabilities of an interface are defined to be the same in either 301 direction. I.e., for data entering the node through that interface 302 and for data leaving the node through that interface. 304 A Link State Advertisement of a link carries the Interface Switching 305 Capability Descriptor(s) only of the near end (the end incumbent on 306 the LSR originating the advertisement). 308 An LSR performing path computation uses the Link State Database to 309 determine whether a link is unidirectional or bidirectional. 311 For a bidirectional link the LSR uses its Link State Database to 312 determine the Interface Switching Capability Descriptor(s) of the 313 far-end of the link, as bidirectional links with different Interface 314 Switching Capabilities at its two ends are allowed. 316 For an unidirectional link it is assumed that the Interface Switching 317 Capability Descriptor at the far-end of the link is the same as at 318 the near-end. Thus, an unidirectional link is required to have the 319 same interface switching capabilities at both ends. This seems a 320 reasonable assumption given that unidirectional links arise only with 321 packet forwarding adjacencies and for these both ends belong to the 322 same level of the PSC hierarchy. 324 This document defines the following Interface Switching Capabilities: 326 Packet-Switch Capable-1 (PSC-1) 327 Packet-Switch Capable-2 (PSC-2) 328 Packet-Switch Capable-3 (PSC-3) 329 Packet-Switch Capable-4 (PSC-4) 330 Layer-2 Switch Capable (L2SC) 331 Time-Division-Multiplex Capable (TDM) 332 Lambda-Switch Capable (LSC) 333 Fiber-Switch Capable (FSC) 335 If there is no Interface Switching Capability Descriptor for an 336 interface, the interface is assumed to be packet-switch capable 337 (PSC-1). 339 Interface Switching Capability Descriptors present a new constraint 340 for LSP path computation. 342 Irrespective of a particular Interface Switching Capability, the 343 Interface Switching Capability Descriptor always includes information 344 about the encoding supported by an interface. The defined encodings 345 are the same as LSP Encoding as defined in [GMPLS-SIG]. 347 Depending on a particular Interface Switching Capability, the 348 Interface Switching Capability Descriptor may include additional 349 information, as specified below. 351 6.4.1. Layer-2 Switch Capable 353 If an interface is of type L2SC, it means that the node receiving 354 data over this interface can switch the received frames based on the 355 layer 2 address. For example, an interface associated with a link 356 terminating on an ATM switch would be considered L2SC. 358 6.4.2. Packet-Switch Capable 360 If an interface is of type PSC-1 through PSC-4, it means that the 361 node receiving data over this interface can switch the received data 362 on a packet-by-packet basis, based on the label carried in the "shim" 363 header [RFC3032]. The various levels of PSC establish a hierarchy of 364 LSPs tunneled within LSPs. 366 For Packet-Switch Capable interfaces the additional information 367 includes Maximum LSP Bandwidth, Minimum LSP Bandwidth, and interface 368 MTU. 370 For a simple (unbundled) link its Maximum LSP Bandwidth at priority p 371 is defined to be the smaller of its unreserved bandwidth at priority 372 p and its Maximum Reservable Bandwidth. Maximum LSP Bandwidth for a 373 bundled link is defined in [LINK-BUNDLE]. 375 The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth 376 ([ISIS-TE], [OSPF-TE]). However, while Maximum Bandwidth is a single 377 fixed value (usually simply the link capacity), Maximum LSP Bandwidth 378 is carried per priority, and may vary as LSPs are set up and torn 379 down. 381 Although Maximum Bandwidth is to be deprecated, for backward 382 compatibility, one MAY set the Maximum Bandwidth to the Maximum LSP 383 Bandwidth at priority 7. 385 The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP 386 could reserve. 388 Typical values for the Minimum LSP Bandwidth and for the Maximum LSP 389 Bandwidth are enumerated in [GMPLS-SIG]. 391 On a PSC interface that supports Standard SONET (or Standard SDH) 392 encoding, an LSP at priority p could reserve any bandwidth allowed by 393 the branch of the SONET/SDH hierarchy, with the leaf and the root of 394 the branch being defined by the Minimum LSP Bandwidth and the Maximum 395 LSP Bandwidth at priority p. 397 On a PSC interface that supports Arbitrary SONET (or Arbitrary SDH) 398 encoding, an LSP at priority p could reserve any bandwidth between 399 the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority 400 p, provided that the bandwidth reserved by the LSP is a multiple of 401 the Minimum LSP Bandwidth. 403 The Interface MTU is the maximum size of a packet that can be 404 transmitted on this interface without being fragmented. 406 6.4.3. Time-Division Multiplex Capable 408 If an interface is of type TDM, it means that the node receiving data 409 over this interface can multiplex or demultiplex channels within a 410 SONET/SDH payload. 412 For Time-Division Multiplex Capable interfaces the additional 413 information includes Maximum LSP Bandwidth, the information on 414 whether the interface supports Standard or Arbitrary SONET/SDH, and 415 Minimum LSP Bandwidth. 417 For a simple (unbundled) link the Maximum LSP Bandwidth at priority p 418 is defined as the maximum bandwidth an LSP at priority p could 419 reserve. Maximum LSP Bandwidth for a bundled link is defined in 420 [LINK-BUNDLE]. 422 The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP 423 could reserve. 425 Typical values for the Minimum LSP Bandwidth and for the Maximum LSP 426 Bandwidth are enumerated in [GMPLS-SIG]. 428 On an interface having Standard SONET (or Standard SDH) multiplexing, 429 an LSP at priority p could reserve any bandwidth allowed by the 430 branch of the SONET/SDH hierarchy, with the leaf and the root of the 431 branch being defined by the Minimum LSP Bandwidth and the Maximum LSP 432 Bandwidth at priority p. 434 On an interface having Arbitrary SONET (or Arbitrary SDH) 435 multiplexing, an LSP at priority p could reserve any bandwidth 436 between the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at 437 priority p, provided that the bandwidth reserved by the LSP is a 438 multiple of the Minimum LSP Bandwidth. 440 A way to handle the case where an interface supports multiple 441 branches of the SONET (or SDH) multiplexing hierarchy, multiple 442 Interface Switching Capability Descriptors would be advertised, one 443 per branch. For example, if an interface supports VT-1.5 and VT-2 444 (which are not part of same branch of SONET multiplexing tree), Then 445 it could advertise two descriptors, one for each one. 447 6.4.4. Lambda-Switch Capable 449 If an interface is of type LSC, it means that the node receiving data 450 over this interface can recognize and switch individual lambdas 451 within the interface. An interface that allows only one lambda per 452 interface, and switches just that lambda is of type LSC. 454 The additional information includes Reservable Bandwidth per 455 priority, which specifies the bandwidth of an LSP that could be 456 supported by the interface at a given priority number. 458 A way to handle the case of multiple data rates or multiple encodings 459 within a single TE Link, multiple Interface Switching Capability 460 Descriptors would be advertised, one per supported data rate and 461 encoding combination. For example, an LSC interface could support 462 the establishment of LSC LSPs at both OC-48c and OC-192c data rates. 464 6.4.5. Fiber-Switch Capable 466 If an interface is of type FSC, it means that the node receiving data 467 over this interface can switch the entire contents to another 468 interface (without distinguishing lambdas, channels or packets). 469 I.e., an interface of type FSC switches at the granularity of an 470 entire interface, and can not extract individual lambdas within the 471 interface. An interface of type FSC can not restrict itself to just 472 one lambda. 474 6.4.6. Multiple Switching Capabilities per interface 476 An interface that connects a link to an LSR may support not one, but 477 several Interface Switching Capabilities. For example, consider a 478 fiber link carrying a set of lambdas that terminates on an LSR 479 interface that could either cross-connect one of these lambdas to 480 some other outgoing optical channel, or could terminate the lamdba, 481 and extract (demultiplex) data from that lambda using TDM, and then 482 cross-connect these TDM channels to some outgoing TDM channels. To 483 support this a Link State Advertisement may carry a list of Interface 484 Switching Capabilities Descriptors. 486 6.4.7. Interface Switching Capabilities and Labels 488 Depicting a TE link as a tuple that contains Interface Switching 489 Capabilities at both ends of the link, some examples links may be: 491 [PSC, PSC] - a link between two packet LSRs 492 [TDM, TDM] - a link between two Digital Cross Connects 493 [LSC, LSC] - a link between two OXCs 494 [PSC, TDM] - a link between a packet LSR and a Digital Cross Connect 495 [PSC, LSC] - a link between a packet LSR and an OXC 496 [TDM, LSC] - a link between a Digital Cross Connect and an OXC 498 Both ends of a given TE link has to use the same way of carrying 499 label information over that link. Carrying label information on a 500 given TE link depends on the Interface Switching Capability at both 501 ends of the link, and is determined as follows: 503 [PSC, PSC] - label is carried in the "shim" header [RFC3032] 504 [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] 505 [LSC, LSC] - label represents a port on an OXC 506 [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] 507 [PSC, LSC] - label represents a port 508 [TDM, LSC] - label represents a port 510 6.4.8. Other issues 512 It is possible that Interface Switching Capability Descriptor will 513 change over time, reflecting the allocation/deallocation of LSPs. 514 For example, assume that STS-1, STS-3c, STS-12c, STS-48c and STS-192c 515 LSPs can be established on a OC-192 interface whose Encoding Type is 516 SONET (or to be more precise, SONET ANSI T1.105). Thus, initially in 517 the Interface Switching Capability Descriptor the Minimum LSP 518 Bandwidth is set to STS-1, and Maximum LSP Bandwidth is set to 519 STS-192 for all priorities. As soon as an LSP of STS-1 size at 520 priority 1 is established on the interface, it is no longer capable 521 of STS-192c for all but LSPs at priority 0. Therefore, the node 522 advertises a modified Interface Switching Capability Descriptor 523 indicating that the Maximum LSP Bandwidth is no longer STS-192, but 524 STS-48 for all but priority 0 (at priority 0 the Maximum LSP 525 Bandwidth is still STS-192). If subsequently there is another STS-1 526 LSP, there is no change in the Interface Switching Capability 527 Descriptor. The Descriptor remains the same until the node can no 528 longer establish a STS-48c LSP over the interface (which means that 529 at this point more than 144 time slots are taken by LSPs on the 530 interface). Once this happened, the Descriptor is modified again, 531 and the modified Descriptor is advertised to other nodes. 533 6.4.9. Examples of Interface Switching Capability Descriptor 535 6.4.9.1. STS-48 POS Interface on a LSR 537 Interface Switching Capability Descriptor: 538 Interface Switching Capability = PSC-1 539 Encoding = SONET ANSI T1.105 540 Max LSP Bandwidth[p] = 2.5 Gbps, for all p 542 If multiple links with such interfaces at both ends were to be 543 advertised as one TE link, link bundling techniques should be used. 545 6.4.9.2. GigE Packet Interface on a LSR 547 Interface Switching Capability Descriptor: 548 Interface Switching Capability = PSC-1 549 Encoding = Ethernet 802.3 550 Max LSP Bandwidth[p] = 1.0 Gbps, for all p 552 If multiple links with such interfaces at both ends were to be 553 advertised as one TE link, link bundling techniques should be used. 555 6.4.9.3. OC-192 SONET Interface on a Digital Cross Connect with Standard 556 SONET 558 Consider a branch of SONET multiplexing tree : VT-1.5, STS-1, STS-3c, 559 STS-12c, STS-48c, STS-192c. If it is possible to establish all these 560 connections on a OC-192 interface, the Interface Switching Capability 561 Descriptor of that interface can be advertised as follows: 563 Interface Switching Capability Descriptor: 564 Interface Switching Capability = TDM [Standard SONET] 565 Encoding = SONET ANSI T1.105 566 Min LSP Bandwidth = VT1.5 567 Max LSP Bandwidth[p] = STS192, for all p 569 If multiple links with such interfaces at both ends were to be 570 advertised as one TE link, link bundling techniques should be used. 572 6.4.9.4. OC-192 SONET Interface on a Digital Cross Connect with two 573 types of SONET multiplexing hierarchy supported 575 Interface Switching Capability Descriptor 1: 576 Interface Switching Capability = TDM [Standard SONET] 577 Encoding = SONET ANSI T1.105 578 Min LSP Bandwidth = VT1.5 579 Max LSP Bandwidth[p] = STS192, for all p 581 Interface Switching Capability Descriptor 2: 582 Interface Switching Capability = TDM [Arbitrary SONET] 583 Encoding = SONET ANSI T1.105 584 Min LSP Bandwidth = VT2 585 Max LSP Bandwidth[p] = STS192, for all p 587 If multiple links with such interfaces at both ends were to be 588 advertised as one TE link, link bundling techniques should be used. 590 6.4.9.5. Interface on an opaque OXC (SONET framed) 592 An "opaque OXC" is considered operationally an OXC, as the whole 593 lambda (carrying the SONET line) is switched transparently without 594 further multiplexing/demultiplexing, and either none of the SONET 595 overhead bytes, or at least the important ones are not changed. 597 An interface on an opaque OXC handles a single wavelength, and 598 cannot switch multiple wavelengths as a whole. Thus, an interface on 599 an opaque OXC is always LSC, and not FSC, irrespective of whether 600 there is DWDM external to it. 602 Note that if there is external DWDM, then the framing understood by 603 the DWDM must be same as that understood by the OXC. 605 A TE link is a group of interfaces on an OXC. All interfaces on a 606 given OXC are required to have identifiers unique to that OXC, and 607 these identifiers are used as port labels (see 3.2.1.1 of [GMPLS- 608 SIG]). 610 The following is an example of an interface switching capability 611 descriptor on a SONET framed opaque OXC: 613 Interface Switching Capability Descriptor: 614 Interface Switching Capability = LSC 615 Encoding = SONET ANSI T1.105 616 Reservable Bandwidth = Determined by SONET Framer (say OC192) 617 6.4.9.6. Interface on a transparent OXC (PXC) with external DWDM that 618 understands SONET framing 620 This example assumes that DWDM and PXC are connected in such a way 621 that each interface (port) on the PXC handles just a single 622 wavelength. Thus, even if in principle an interface on the PXC could 623 switch multiple wavelengths as a whole, in this particular case an 624 interface on the PXC is considered LSC, and not FSC. 626 _______ 627 | | 628 /|___| | 629 | |___| PXC | 630 ========| |___| | 631 | |___| | 632 \| |_______| 633 DWDM 634 (SONET framed) 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 The following is an example of an interface switching capability 642 descriptor on a transparent OXC (PXC) with external DWDM that 643 understands SONET framing: 645 Interface Switching Capability Descriptor: 646 Interface Switching Capability = LSC 647 Encoding = SONET ANSI T1.105 (comes from DWDM) 648 Reservable Bandwidth = Determined by DWDM (say OC192) 650 6.4.9.7. Interface on a transparent OXC (PXC) with external DWDM that is 651 transparent to bit-rate and framing 653 This example assumes that DWDM and PXC are connected in such a way 654 that each interface (port) on the PXC handles just a single 655 wavelength. Thus, even if in principle an interface on the PXC could 656 switch multiple wavelengths as a whole, in this particular case an 657 interface on the PXC is considered LSC, and not FSC. 659 _______ 660 | | 661 /|___| | 662 | |___| PXC | 663 ========| |___| | 664 | |___| | 665 \| |_______| 666 DWDM 667 (transparent to bit-rate and framing) 669 A TE link is a group of interfaces on the PXC. All interfaces on a 670 given PXC are required to have identifiers unique to that PXC, and 671 these identifiers are used as port labels (see 3.2.1.1 of [GMPLS- 672 SIG]). 674 The following is an example of an interface switching capability 675 descriptor on a transparent OXC (PXC) with external DWDM that is 676 transparent to bit-rate and framing: 678 Interface Switching Capability Descriptor: 679 Interface Switching Capability = LSC 680 Encoding = Lambda (photonic) 681 Reservable Bandwidth = Determined by optical technology limits 683 6.4.9.8. Interface on a PXC with no external DWDM 685 The absence of DWDM in between two PXCs, implies that an interface is 686 not limited to one wavelength. Thus, the interface is advertised as 687 FSC. 689 A TE link is a group of interfaces on the PXC. All interfaces on a 690 given PXC are required to have identifiers unique to that PXC, and 691 these identifiers are used as port labels (see 3.2.1.1 of [GMPLS- 692 SIG]). 694 Interface Switching Capability Descriptor: 695 Interface Switching Capability = FSC 696 Encoding = Lambda (photonic) 697 Reservable Bandwidth = Determined by optical technology limits 699 Note that this example assumes that the PXC does not restrict each 700 port to carry only one wavelength. 702 6.4.10. Example of interfaces that support multiple switching 703 capabilities 705 There can be many combinations possible, some are described below. 707 6.4.10.1. Interface on a PXC+TDM device with external DWDM 709 As discussed earlier, the presence of the external DWDM limits that 710 only one wavelength be on a port of the PXC. On such a port, the 711 attached PXC+TDM device can do one of the following. The wavelength 712 may be cross-connected by the PXC element to other out-bound optical 713 channel, or the wavelength may be terminated as a SONET interface and 714 SONET channels switched. 716 From a GMPLS perspective the PXC+TDM functionality is treated as a 717 single interface. The interface is described using two Interface 718 descriptors, one for the LSC and another for the TDM, with 719 appropriate parameters. For example, 721 Interface Switching Capability Descriptor: 722 Interface Switching Capability = LSC 723 Encoding = SONET ANSI T1.105 (comes from WDM) 724 Reservable Bandwidth = OC192 726 and 728 Interface Switching Capability Descriptor: 729 Interface Switching Capability = TDM [Standard SONET] 730 Encoding = SONET ANSI T1.105 731 Min LSP Bandwidth = VT1.5 732 Max LSP Bandwidth[p] = STS192, for all p 734 6.4.10.2. Interface on an opaque OXC+TDM device with external DWDM 736 An interface on an "opaque OXC+TDM" device would also be advertised 737 as LSC+TDM much the same way as the previous case. 739 6.4.10.3. Interface on a PXC+LSR device with external DWDM 741 As discussed earlier, the presence of the external DWDM limits that 742 only one wavelength be on a port of the PXC. On such a port, the 743 attached PXC+LSR device can do one of the following. The wavelength 744 may be cross-connected by the PXC element to other out-bound optical 745 channel, or the wavelength may be terminated as a Packet interface 746 and packets switched. 748 From a GMPLS perspective the PXC+LSR functionality is treated as a 749 single interface. The interface is described using two Interface 750 descriptors, one for the LSC and another for the PSC, with 751 appropriate parameters. For example, 752 Interface Switching Capability Descriptor: 753 Interface Switching Capability = LSC 754 Encoding = SONET ANSI T1.105 (comes from WDM) 755 Reservable Bandwidth = OC192 757 and 759 Interface Switching Capability Descriptor: 760 Interface Switching Capability = PSC-1 761 Encoding = SONET ANSI T1.105 762 Max LSP Bandwidth[p] = 10 Gbps, for all p 764 6.4.10.4. Interface on a TDM+LSR device 766 On a TDM+LSR device that offers a channelized SONET/SDH interface the 767 following may be possible: 769 - A subset of the SONET/SDH channels may be uncommitted. That is, 770 they are not currently in use and hence are available for 771 allocation. 773 - A second subset of channels may already be committed for transit 774 purposes. That is, they are already cross-connected by the 775 SONET/SDH cross connect function to other out-bound channels and 776 thus are not immediately available for allocation. 778 - Another subset of channels could be in use as terminal channels. 779 That is, they are already allocated by terminate on a packet 780 interface and packets switched. 782 From a GMPLS perspective the TDM+PSC functionality is treated as a 783 single interface. The interface is described using two Interface 784 descriptors, one for the TDM and another for the PSC, with 785 appropriate parameters. For example, 787 Interface Switching Capability Descriptor: 788 Interface Switching Capability = TDM [Standard SONET] 789 Encoding = SONET ANSI T1.105 790 Min LSP Bandwidth = VT1.5 791 Max LSP Bandwidth[p] = STS192, for all p 793 and 795 Interface Switching Capability Descriptor: 796 Interface Switching Capability = PSC-1 797 Encoding = SONET ANSI T1.105 798 Max LSP Bandwidth[p] = 10 Gbps, for all p 799 7. Security Considerations 801 The routing extensions proposed in this document do not raise any new 802 security concerns. 804 8. Acknowledgements 806 The authors would like to thank Suresh Katukam, Jonathan Lang and 807 Quaizar Vohra for their comments on the draft. 809 9. References 811 [ISIS-TE] Smit, H., Li, T., "IS-IS Extensions for Traffic 812 Engineering", draft-ietf-isis-traffic-02.txt (work in progress) 814 [LSP-HIER] Kompella, K., Rekhter, Y., "LSP Hierarchy with MPLS TE", 815 draft-ietf-mpls-lsp-hierarchy-01.txt (work in progress) 817 [GMPLS-SIG] Generalized MPLS Group, "Generalized MPLS - Signaling 818 Functional Description", draft-ietf-mpls-generalized-signaling-05.txt 819 (work in progress) 821 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 822 Extensions to OSPF", draft-katz-yeung-ospf-traffic-05.txt 824 [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS 825 Extensions in Support of Generalized MPLS", draft-ietf-isis-gmpls- 826 extensions-02.txt (work in progress) 828 [GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF 829 Extensions in Support of Generalized MPLS", draft-ietf-ccamp-ospf- 830 gmpls-extensions-00.txt (work in progress) 832 [LINK-BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling 833 in MPLS Traffic Engineering", draft-ietf-mpls-bundle-00.txt (work in 834 progress) 836 [LMP] 838 [OVPN] Ould-Brahim, H., Rekhter, Y., Fedyk, D., Ashwood-Smith, P., 839 Rosen, E., Mannie, E., Fang, L., Drake, J., "BGP/GMPLS Optical VPNs", 840 draft-ouldbrahim-bgpgmpls-ovpn-01.txt (work in progress) 841 10. Authors' Information 843 Kireeti Kompella 844 Juniper Networks, Inc. 845 1194 N. Mathilda Ave 846 Sunnyvale, CA 94089 847 Email: kireeti@juniper.net 849 Yakov Rekhter 850 Juniper Networks, Inc. 851 1194 N. Mathilda Ave 852 Sunnyvale, CA 94089 853 Email: yakov@juniper.net 855 Ayan Banerjee 856 Calient Networks 857 5853 Rue Ferrari 858 San Jose, CA 95138 859 Phone: +1.408.972.3645 860 Email: abanerjee@calient.net 862 John Drake 863 Calient Networks 864 5853 Rue Ferrari 865 San Jose, CA 95138 866 Phone: (408) 972-3720 867 Email: jdrake@calient.net 869 Greg Bernstein 870 Ciena Corporation 871 10480 Ridgeview Court 872 Cupertino, CA 94014 873 Phone: (408) 366-4713 874 Email: greg@ciena.com 875 Don Fedyk 876 Nortel Networks Corp. 877 600 Technology Park Drive 878 Billerica, MA 01821 879 Phone: +1-978-288-4506 880 Email: dwfedyk@nortelnetworks.com 882 Eric Mannie 883 GTS Network Services 884 RDI Department, Core Network Technology Group 885 Terhulpsesteenweg, 6A 886 1560 Hoeilaart, Belgium 887 Phone: +32-2-658.56.52 888 Email: eric.mannie@ebone.com 890 Debanjan Saha 891 Tellium Optical Systems 892 2 Crescent Place 893 P.O. Box 901 894 Ocean Port, NJ 07757 895 Phone: (732) 923-4264 896 Email: dsaha@tellium.com 898 Vishal Sharma 899 Metanoia, Inc. 900 335 Elan Village Lane, Unit 203 901 San Jose, CA 95134-2539 902 Phone: +1 408-943-1794 903 Email: v.sharma@ieee.org 905 Debashis Basak 906 AcceLight Networks, 907 70 Abele Rd, Bldg 1200 908 Bridgeville PA 15017 909 Email: dbasak@accelight.com