idnits 2.17.1 draft-ietf-ccamp-gmpls-routing-05.txt: 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. 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. ** There are 5 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 621 has weird spacing: '...terface on an...' == Line 1049 has weird spacing: '...for the purpo...' -- 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.) -- The document date (August 2002) is 7919 days in the past. Is this intentional? 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 136, but not defined == Missing Reference: 'PSC' is mentioned on line 523, but not defined == Missing Reference: 'TDM' is mentioned on line 525, but not defined == Missing Reference: 'LSC' is mentioned on line 526, but not defined == Missing Reference: 'FSC' is mentioned on line 526, but not defined == Missing Reference: 'Standard SDH' is mentioned on line 879, but not defined == Missing Reference: 'Arbitrary SDH' is mentioned on line 605, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'GMPLS-OSPF' -- Possible downref: Non-RFC (?) normative reference: ref. 'GMPLS-SIG' -- Possible downref: Non-RFC (?) normative reference: ref. 'GMPLS-SONET-SDH' -- Possible downref: Non-RFC (?) normative reference: ref. 'LINK-BUNDLE' -- Possible downref: Non-RFC (?) normative reference: ref. 'LMP' -- Possible downref: Non-RFC (?) normative reference: ref. 'LSP-HIER' -- Possible downref: Non-RFC (?) normative reference: ref. 'OSPF-TE' Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kompella (Editor) 3 Internet Draft Y. Rekhter (Editor) 4 Category: Standards Track Juniper Networks 5 Expires: February 2003 August 2002 7 Routing Extensions in Support of Generalized MPLS 9 draft-ietf-ccamp-gmpls-routing-05.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 This document specifies routing extensions in support of Generalized 39 Multi-Protocol Label Switching (GMPLS). 41 Summary for Sub-IP Area 43 (This section to be removed before publication.) 45 0.1. Summary 47 This document specifies routing extensions in support of Generalized 48 Multi-Protocol Label Switching (GMPLS). 50 0.2. Where does it fit in the Picture of the Sub-IP Work 52 This work fits squarely in the CCAMP box. 54 0.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 0.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 1. Specification of Requirements 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in RFC 2119 [RFC2119]. 71 2. Introduction 73 This document specifies routing extensions in support of carrying 74 link state information for Generalized Multi-Protocol Label Switching 75 (GMPLS). This document enhances the routing extensions [ISIS-TE], 76 [OSPF-TE] required to support MPLS Traffic Engineering. 78 3. GMPLS TE Links 80 Traditionally, a TE link is advertised as an adjunct to a "regular" 81 link, i.e., a routing adjacency is brought up on the link, and when 82 the link is up, both the regular SPF properties of the link 83 (basically, the SPF metric) and the TE properties of the link are 84 then advertised. 86 GMPLS challenges this notion in three ways. First, links that are 87 not capable of sending and receiving on a packet-by-packet basis may 88 yet have TE properties; however, a routing adjacency cannot be 89 brought up on such links. Second, a Label Switched Path can be 90 advertised as a point-to-point TE link (see [LSP-HIER]); thus, an 91 advertised TE link may be between a pair of nodes that don't have a 92 routing adjacency with each other. Finally, a number of links may be 93 advertised as a single TE link (perhaps for improved scalability), so 94 again, there is no longer a one-to-one association of a regular 95 routing adjacency and a TE link. 97 Thus we have a more general notion of a TE link. A TE link is a 98 "logical" link that has TE properties. The link is logical in a sense 99 that it represents a way to group/map the information about certain 100 physical resources (and their properties) into the information that 101 is used by Constrained SPF for the purpose of path computation, and 102 by GMPLS signaling. This grouping/mapping must be done consistently 103 at both ends of the link. LMP [LMP] could be used to check/verify 104 this consistency. 106 Depending on the nature of resources that form a particular TE link, 107 for the purpose of GMPLS signaling in some cases the combination of 108 is sufficient to unambiguously identify 109 the appropriate resource used by an LSP. In other cases, the 110 combination of is not sufficient - such 111 cases are handled by using the link bundling construct [LINK-BUNDLE] 112 that allows to identify the resource by . 115 Some of the properties of a TE link may be configured on the 116 advertising Label Switching Router (LSR), others which may be 117 obtained from other LSRs by means of some protocol, and yet others 118 which may be deduced from the component(s) of the TE link. 120 A TE link between a pair of LSRs doesn't imply the existence of a 121 routing adjacency (e.g., an IGP adjacency) between these LSRs. As we 122 mentioned above, in certain cases a TE link between a pair of LSRs 123 could be advertised even if there is no routing adjacency at all 124 between the LSRs (e.g., when the TE link is a Forwarding Adjacency 125 (see [LSP-HIER])). 127 A TE link must have some means by which the advertising LSR can know 128 of its liveness (this means may be routing hellos, but is not limited 129 to routing hellos). When an LSR knows that a TE link is up, and can 130 determine the TE link's TE properties, the LSR may then advertise 131 that link to its (regular) neighbors. 133 In this document, we call the interfaces over which regular routing 134 adjacencies are established "control channels". 136 [ISIS-TE] and [OSFP-TE] define the canonical TE properties, and say 137 how to associate TE properties to regular (packet-switched) links. 138 This document extends the set of TE properties, and also says how to 139 associate TE properties with non-packet-switched links such as links 140 between Optical Cross-Connects (OXCs). [LSP-HIER] says how to 141 associate TE properties with links formed by Label Switched Paths. 143 3.1. Excluding data traffic from control channels 145 The control channels between nodes in a GMPLS network, such as OXCs, 146 SDH cross-connects and/or routers, are generally meant for control 147 and administrative traffic. These control channels are advertised 148 into routing as normal links as mentioned in the previous section; 149 this allows the routing of (for example) RSVP messages and telnet 150 sessions. However, if routers on the edge of the optical domain 151 attempt to forward data traffic over these channels, the channel 152 capacity will quickly be exhausted. 154 In order to keep these control channels from being advertised into 155 the user data plane a variety of techniques can be used. 157 If one assumes that data traffic is sent to BGP destinations, and 158 control traffic to IGP destinations, then one can exclude data 159 traffic from the control plane by restricting BGP nexthop resolution. 160 (It is assumed that OXCs are not BGP speakers.) Suppose that a 161 router R is attempting to install a route to a BGP destination D. R 162 looks up the BGP nexthop for D in its IGP's routing table. Say R 163 finds that the path to the nexthop is over interface I. R then 164 checks if it has an entry in its Link State database associated with 165 the interface I. If it does, and the link is not packet-switch 166 capable (see [LSP_HIER]), R installs a discard route for destination 167 D. Otherwise, R installs (as usual) a route for destination D with 168 nexthop I. Note that R need only do this check if it has packet- 169 switch incapable links; if all of its links are packet-switch 170 capable, then clearly this check is redundant. 172 In other instances it may be desirable to keep the whole address 173 space of a GMPLS routing plane disjoint from the endpoint addresses 174 in another portion of the GMPLS network. For example, the addresses 175 of a carrier network where the carrier uses GMPLS but does not wish 176 to expose the internals of the addressing or topology. In such a 177 network the control channels are never advertised into the end data 178 network. In this instance, independent mechanisms are used to 179 advertise the data addresses over the carrier network. 181 Other techniques for excluding data traffic from control channels may 182 also be needed. 184 4. GMPLS Routing Enhancements 186 In this section we define the enhancements to the TE properties of 187 GMPLS TE links. Encoding of this information in IS-IS is specified in 188 [GMPLS-ISIS]. Encoding of this information in OSPF is specified in 189 [GMPLS-OSPF]. 191 4.1. Support for unnumbered links 193 An unnumbered link has to be a point-to-point link. An LSR at each 194 end of an unnumbered link assigns an identifier to that link. This 195 identifier is a non-zero 32-bit number that is unique within the 196 scope of the LSR that assigns it. 198 Consider an (unnumbered) link between LSRs A and B. LSR A chooses an 199 idenfitier for that link. So is LSR B. From A's perspective we refer 200 to the identifier that A assigned to the link as the "link local 201 identifier" (or just "local identifier"), and to the identifier that 202 B assigned to the link as the "link remote identifier" (or just 203 "remote identifier"). Likewise, from B's perspective the identifier 204 that B assigned to the link is the local identifier, and the 205 identifier that A assigned to the link is the remote identifier. 207 Support for unnumbered links in routing includes carrying information 208 about the identifiers of that link. Specifically, when an LSR 209 advertises an unnumbered TE link, the advertisement carries both the 210 local and the remote identifiers of the link. If the LSR doesn't 211 know the remote identifier of that link, the LSR should use a value 212 of 0 as the remote identifier. 214 4.2. Link Protection Type 216 The Link Protection Type represents the protection capability that 217 exists for a link. It is desirable to carry this information so that 218 it may be used by the path computation algorithm to set up LSPs with 219 appropriate protection characteristics. This information is organized 220 in a hierarchy where typically the minimum acceptable protection is 221 specified at path instantiation and a path selection technique is 222 used to find a path that satisfies at least the minimum acceptable 223 protection. Protection schemes are presented in order from lowest to 224 highest protection. 226 This document defines the following protection capabilities: 228 Extra Traffic 229 If the link is of type Extra Traffic, it means that the link is 230 protecting another link or links. The LSPs on a link of this type 231 will be lost if any of the links it is protecting fail. 233 Unprotected 234 If the link is of type Unprotected, it means that there is no 235 other link protecting this link. The LSPs on a link of this type 236 will be lost if the link fails. 238 Shared 239 If the link is of type Shared, it means that there are one or more 240 disjoint links of type Extra Traffic that are protecting this 241 link. These Extra Traffic links are shared between one or more 242 links of type Shared. 244 Dedicated 1:1 245 If the link is of type Dedicated 1:1, it means that there is one 246 dedicated disjoint link of type Extra Traffic that is protecting 247 this link. 249 Dedicated 1+1 250 If the link is of type Dedicated 1+1, it means that a dedicated 251 disjoint link is protecting this link. However, the protecting 252 link is not advertised in the link state database and is therefore 253 not available for the routing of LSPs. 255 Enhanced 256 If the link is of type Enhanced, it means that a protection scheme 257 that is more reliable than Dedicated 1+1, e.g., 4 fiber BLSR/MS- 258 SPRING, is being used to protect this link. 260 The Link Protection Type is optional, and if a Link State 261 Advertisement doesn't carry this information, then the Link 262 Protection Type is unknown. 264 4.3. Shared Risk Link Group Information 266 A set of links may constitute a 'shared risk link group' (SRLG) if 267 they share a resource whose failure may affect all links in the set. 268 For example, two fibers in the same conduit would be in the same 269 SRLG. A link may belong to multiple SRLGs. Thus the SRLG 270 Information describes a list of SRLGs that the link belongs to. An 271 SRLG is identified by a 32 bit number that is unique within an IGP 272 domain. The SRLG Information is an unordered list of SRLGs that the 273 link belongs to. 275 The SRLG of a LSP is the union of the SRLGs of the links in the LSP. 276 The SRLG of a bundled link is the union of the SRLGs of all the 277 component links. 279 If an LSR is required to have multiple diversely routed LSPs to 280 another LSR, the path computation should attempt to route the paths 281 so that they do not have any links in common, and such that the path 282 SRLGs are disjoint. 284 The SRLG Information may start with a configured value, in which case 285 it does not change over time, unless reconfigured. 287 The SRLG Information is optional and if a Link State Advertisement 288 doesn't carry the SRLG Information, then it means that SRLG of that 289 link is unknown. 291 4.4. Interface Switching Capability Descriptor 293 In the context of this document we say that a link is connected to a 294 node by an interface. In the context of GMPLS interfaces may have 295 different switching capabilities. For example an interface that 296 connects a given link to a node may not be able to switch individual 297 packets, but it may be able to switch channels within an SDH payload. 298 Interfaces at each end of a link need not have the same switching 299 capabilities. Interfaces on the same node need not have the same 300 switching capabilities. 302 The Interface Switching Capability Descriptor describes switching 303 capability of an interface. For bi-directional links, the switching 304 capabilities of an interface are defined to be the same in either 305 direction. I.e., for data entering the node through that interface 306 and for data leaving the node through that interface. 308 A Link State Advertisement of a link carries the Interface Switching 309 Capability Descriptor(s) only of the near end (the end incumbent on 310 the LSR originating the advertisement). 312 An LSR performing path computation uses the Link State Database to 313 determine whether a link is unidirectional or bidirectional. 315 For a bidirectional link the LSR uses its Link State Database to 316 determine the Interface Switching Capability Descriptor(s) of the 317 far-end of the link, as bidirectional links with different Interface 318 Switching Capabilities at its two ends are allowed. 320 For an unidirectional link it is assumed that the Interface Switching 321 Capability Descriptor at the far-end of the link is the same as at 322 the near-end. Thus, an unidirectional link is required to have the 323 same interface switching capabilities at both ends. This seems a 324 reasonable assumption given that unidirectional links arise only with 325 packet forwarding adjacencies and for these both ends belong to the 326 same level of the PSC hierarchy. 328 This document defines the following Interface Switching Capabilities: 330 Packet-Switch Capable-1 (PSC-1) 331 Packet-Switch Capable-2 (PSC-2) 332 Packet-Switch Capable-3 (PSC-3) 333 Packet-Switch Capable-4 (PSC-4) 334 Layer-2 Switch Capable (L2SC) 335 Time-Division-Multiplex Capable (TDM) 336 Lambda-Switch Capable (LSC) 337 Fiber-Switch Capable (FSC) 339 If there is no Interface Switching Capability Descriptor for an 340 interface, the interface is assumed to be packet-switch capable 341 (PSC-1). 343 Interface Switching Capability Descriptors present a new constraint 344 for LSP path computation. 346 Irrespective of a particular Interface Switching Capability, the 347 Interface Switching Capability Descriptor always includes information 348 about the encoding supported by an interface. The defined encodings 349 are the same as LSP Encoding as defined in [GMPLS-SIG]. 351 An interface may have more than one Interface Switching Capability 352 Descriptor. This is used to handle interfaces that support multiple 353 switching capabilities, for interfaces that have Max LSP Bandwidth 354 values that differ by priority level, and for interfaces that support 355 discrete bandwidths. 357 Depending on a particular Interface Switching Capability, the 358 Interface Switching Capability Descriptor may include additional 359 information, as specified below. 361 4.4.1. Layer-2 Switch Capable 363 If an interface is of type L2SC, it means that the node receiving 364 data over this interface can switch the received frames based on the 365 layer 2 address. For example, an interface associated with a link 366 terminating on an ATM switch would be considered L2SC. 368 4.4.2. Packet-Switch Capable 370 If an interface is of type PSC-1 through PSC-4, it means that the 371 node receiving data over this interface can switch the received data 372 on a packet-by-packet basis, based on the label carried in the "shim" 373 header [RFC3032]. The various levels of PSC establish a hierarchy of 374 LSPs tunneled within LSPs. 376 For Packet-Switch Capable interfaces the additional information 377 includes Maximum LSP Bandwidth, Minimum LSP Bandwidth, and interface 378 MTU. 380 For a simple (unbundled) link its Maximum LSP Bandwidth at priority p 381 is defined to be the smaller of its unreserved bandwidth at priority 382 p and its Maximum Reservable Bandwidth. Maximum LSP Bandwidth for a 383 bundled link is defined in [LINK-BUNDLE]. 385 The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth 386 ([ISIS-TE], [OSPF-TE]). However, while Maximum Bandwidth is a single 387 fixed value (usually simply the link capacity), Maximum LSP Bandwidth 388 is carried per priority, and may vary as LSPs are set up and torn 389 down. 391 Although Maximum Bandwidth is to be deprecated, for backward 392 compatibility, one MAY set the Maximum Bandwidth to the Maximum LSP 393 Bandwidth at priority 7. 395 The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP 396 could reserve. 398 Typical values for the Minimum LSP Bandwidth and for the Maximum LSP 399 Bandwidth are enumerated in [GMPLS-SIG]. 401 On a PSC interface that supports Standard SDH encoding, an LSP at 402 priority p could reserve any bandwidth allowed by the branch of the 403 SDH hierarchy, with the leaf and the root of the branch being defined 404 by the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at 405 priority p. 407 On a PSC interface that supports Arbitrary SDH encoding, an LSP at 408 priority p could reserve any bandwidth between the Minimum LSP 409 Bandwidth and the Maximum LSP Bandwidth at priority p, provided that 410 the bandwidth reserved by the LSP is a multiple of the Minimum LSP 411 Bandwidth. 413 The Interface MTU is the maximum size of a packet that can be 414 transmitted on this interface without being fragmented. 416 4.4.3. Time-Division Multiplex Capable 418 If an interface is of type TDM, it means that the node receiving data 419 over this interface can multiplex or demultiplex channels within an 420 SDH payload. 422 For Time-Division Multiplex Capable interfaces the additional 423 information includes Maximum LSP Bandwidth, the information on 424 whether the interface supports Standard or Arbitrary SDH, and Minimum 425 LSP Bandwidth. 427 For a simple (unbundled) link the Maximum LSP Bandwidth at priority p 428 is defined as the maximum bandwidth an LSP at priority p could 429 reserve. Maximum LSP Bandwidth for a bundled link is defined in 430 [LINK-BUNDLE]. 432 The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP 433 could reserve. 435 Typical values for the Minimum LSP Bandwidth and for the Maximum LSP 436 Bandwidth are enumerated in [GMPLS-SIG]. 438 On an interface having Standard SDH multiplexing, an LSP at priority 439 p could reserve any bandwidth allowed by the branch of the SDH 440 hierarchy, with the leaf and the root of the branch being defined by 441 the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority 442 p. 444 On an interface having Arbitrary SDH multiplexing, an LSP at priority 445 p could reserve any bandwidth between the Minimum LSP Bandwidth and 446 the Maximum LSP Bandwidth at priority p, provided that the bandwidth 447 reserved by the LSP is a multiple of the Minimum LSP Bandwidth. 449 Interface Switching Capability Descriptor for the interfaces that 450 support sub VC-3 may include additional information. The nature and 451 the encoding of such information is outside the scope of this 452 document. 454 A way to handle the case where an interface supports multiple 455 branches of the SDH multiplexing hierarchy, multiple Interface 456 Switching Capability Descriptors would be advertised, one per branch. 457 For example, if an interface supports VC-11 and VC-12 (which are not 458 part of same branch of SDH multiplexing tree), then it could 459 advertise two descriptors, one for each one. 461 4.4.4. Lambda-Switch Capable 463 If an interface is of type LSC, it means that the node receiving data 464 over this interface can recognize and switch individual lambdas 465 within the interface. An interface that allows only one lambda per 466 interface, and switches just that lambda is of type LSC. 468 The additional information includes Reservable Bandwidth per 469 priority, which specifies the bandwidth of an LSP that could be 470 supported by the interface at a given priority number. 472 A way to handle the case of multiple data rates or multiple encodings 473 within a single TE Link, multiple Interface Switching Capability 474 Descriptors would be advertised, one per supported data rate and 475 encoding combination. For example, an LSC interface could support 476 the establishment of LSC LSPs at both STM-16 and STM-64 data rates. 478 4.4.5. Fiber-Switch Capable 480 If an interface is of type FSC, it means that the node receiving data 481 over this interface can switch the entire contents to another 482 interface (without distinguishing lambdas, channels or packets). 483 I.e., an interface of type FSC switches at the granularity of an 484 entire interface, and can not extract individual lambdas within the 485 interface. An interface of type FSC can not restrict itself to just 486 one lambda. 488 4.4.6. Multiple Switching Capabilities per interface 490 An interface that connects a link to an LSR may support not one, but 491 several Interface Switching Capabilities. For example, consider a 492 fiber link carrying a set of lambdas that terminates on an LSR 493 interface that could either cross-connect one of these lambdas to 494 some other outgoing optical channel, or could terminate the lamdba, 495 and extract (demultiplex) data from that lambda using TDM, and then 496 cross-connect these TDM channels to some outgoing TDM channels. To 497 support this a Link State Advertisement may carry a list of Interface 498 Switching Capabilities Descriptors. 500 4.4.7. Interface Switching Capabilities and Labels 502 Depicting a TE link as a tuple that contains Interface Switching 503 Capabilities at both ends of the link, some examples links may be: 505 [PSC, PSC] - a link between two packet LSRs 506 [TDM, TDM] - a link between two Digital Cross Connects 507 [LSC, LSC] - a link between two OXCs 508 [PSC, TDM] - a link between a packet LSR and a Digital Cross Connect 509 [PSC, LSC] - a link between a packet LSR and an OXC 510 [TDM, LSC] - a link between a Digital Cross Connect and an OXC 512 Both ends of a given TE link has to use the same way of carrying 513 label information over that link. Carrying label information on a 514 given TE link depends on the Interface Switching Capability at both 515 ends of the link, and is determined as follows: 517 [PSC, PSC] - label is carried in the "shim" header [RFC3032] 518 [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] 519 [LSC, LSC] - label represents a lambda 520 [FSC, FSC] - label represents a port on an OXC 521 [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] 522 [PSC, LSC] - label represents a lambda 523 [PSC, FSC] - label represents a port 524 [TDM, LSC] - label represents a lambda 525 [TDM, FSC] - label represents a port 526 [LSC, FSC] - label represents a port 528 4.4.8. Other issues 530 It is possible that Interface Switching Capability Descriptor will 531 change over time, reflecting the allocation/deallocation of LSPs. 532 For example, assume that VC-3, VC-4, VC-4-4c, VC-4-16c and VC-4-64c 533 LSPs can be established on a STM-64 interface whose Encoding Type is 534 SDH. Thus, initially in the Interface Switching Capability Descriptor 535 the Minimum LSP Bandwidth is set to VC-3, and Maximum LSP Bandwidth 536 is set to STM-64 for all priorities. As soon as an LSP of VC-3 size 537 at priority 1 is established on the interface, it is no longer 538 capable of VC-4-64c for all but LSPs at priority 0. Therefore, the 539 node advertises a modified Interface Switching Capability Descriptor 540 indicating that the Maximum LSP Bandwidth is no longer STM-64, but 541 STM-16 for all but priority 0 (at priority 0 the Maximum LSP 542 Bandwidth is still STM-64). If subsequently there is another VC-3 543 LSP, there is no change in the Interface Switching Capability 544 Descriptor. The Descriptor remains the same until the node can no 545 longer establish a VC-4-16c LSP over the interface (which means that 546 at this point more than 144 time slots are taken by LSPs on the 547 interface). Once this happened, the Descriptor is modified again, 548 and the modified Descriptor is advertised to other nodes. 550 4.5. Bandwidth Encoding 552 Encoding in IEEE floating point format of the discrete values that 553 could be used to identify Unreserved bandwidth, Maximum LSP bandwidth 554 and Minimum LSP bandwidth is described in Section 3.1.2 of [GMPLS- 555 SIG]. 557 5. Examples of Interface Switching Capability Descriptor 559 5.1. STM-16 POS Interface on a LSR 561 Interface Switching Capability Descriptor: 562 Interface Switching Capability = PSC-1 563 Encoding = SDH 564 Max LSP Bandwidth[p] = 2.5 Gbps, for all p 566 If multiple links with such interfaces at both ends were to be 567 advertised as one TE link, link bundling techniques should be used. 569 5.2. GigE Packet Interface on a LSR 571 Interface Switching Capability Descriptor: 572 Interface Switching Capability = PSC-1 573 Encoding = Ethernet 802.3 574 Max LSP Bandwidth[p] = 1.0 Gbps, for all p 576 If multiple links with such interfaces at both ends were to be 577 advertised as one TE link, link bundling techniques should be used. 579 5.3. STM-64 SDH Interface on a Digital Cross Connect with Standard SDH 581 Consider a branch of SDH multiplexing tree : VC-3, VC-4, VC-4-4c, 582 VC-4-16c, VC-4-64c. If it is possible to establish all these 583 connections on a STM-64 interface, the Interface Switching Capability 584 Descriptor of that interface can be advertised as follows: 586 Interface Switching Capability Descriptor: 587 Interface Switching Capability = TDM [Standard SDH] 588 Encoding = SDH 589 Min LSP Bandwidth = VC-3 590 Max LSP Bandwidth[p] = STM-64, for all p 592 If multiple links with such interfaces at both ends were to be 593 advertised as one TE link, link bundling techniques should be used. 595 5.4. STM-64 SDH Interface on a Digital Cross Connect with two types of 596 SDH multiplexing hierarchy supported 598 Interface Switching Capability Descriptor 1: 599 Interface Switching Capability = TDM [Standard SDH] 600 Encoding = SDH 601 Min LSP Bandwidth = VC-3 602 Max LSP Bandwidth[p] = STM-64, for all p 604 Interface Switching Capability Descriptor 2: 605 Interface Switching Capability = TDM [Arbitrary SDH] 606 Encoding = SDH 607 Min LSP Bandwidth = VC-4 608 Max LSP Bandwidth[p] = STM-64, for all p 610 If multiple links with such interfaces at both ends were to be 611 advertised as one TE link, link bundling techniques should be used. 613 5.5. Interface on an opaque OXC (SDH framed) with support for one lambda 614 per port/interface 616 An "opaque OXC" is considered operationally an OXC, as the whole 617 lambda (carrying the SDH line) is switched transparently without 618 further multiplexing/demultiplexing, and either none of the SDH 619 overhead bytes, or at least the important ones are not changed. 621 An interface on an opaque OXC handles a single wavelength, and 622 cannot switch multiple wavelengths as a whole. Thus, an interface on 623 an opaque OXC is always LSC, and not FSC, irrespective of whether 624 there is DWDM external to it. 626 Note that if there is external DWDM, then the framing understood by 627 the DWDM must be same as that understood by the OXC. 629 A TE link is a group of one or more interfaces on an OXC. All 630 interfaces on a given OXC are required to have identifiers unique to 631 that OXC, and these identifiers are used as labels (see 3.2.1.1 of 632 [GMPLS-SIG]). 634 The following is an example of an interface switching capability 635 descriptor on an SDH framed opaque OXC: 637 Interface Switching Capability Descriptor: 638 Interface Switching Capability = LSC 639 Encoding = SDH 640 Reservable Bandwidth = Determined by SDH Framer (say STM-64) 642 5.6. Interface on a transparent OXC (PXC) with external DWDM that 643 understands SDH framing 645 This example assumes that DWDM and PXC are connected in such a way 646 that each interface (port) on the PXC handles just a single 647 wavelength. Thus, even if in principle an interface on the PXC could 648 switch multiple wavelengths as a whole, in this particular case an 649 interface on the PXC is considered LSC, and not FSC. 651 _______ 652 | | 653 /|___| | 654 | |___| PXC | 655 ========| |___| | 656 | |___| | 657 \| |_______| 658 DWDM 659 (SDH framed) 661 A TE link is a group of one or more interfaces on the PXC. All 662 interfaces on a given PXC are required to have identifiers unique to 663 that PXC, and these identifiers are used as labels (see 3.2.1.1 of 664 [GMPLS-SIG]). 666 The following is an example of an interface switching capability 667 descriptor on a transparent OXC (PXC) with external DWDM that 668 understands SDH framing: 670 Interface Switching Capability Descriptor: 671 Interface Switching Capability = LSC 672 Encoding = SDH (comes from DWDM) 673 Reservable Bandwidth = Determined by DWDM (say STM-64) 675 5.7. Interface on a transparent OXC (PXC) with external DWDM that is 676 transparent to bit-rate and framing 678 This example assumes that DWDM and PXC are connected in such a way 679 that each interface (port) on the PXC handles just a single 680 wavelength. Thus, even if in principle an interface on the PXC could 681 switch multiple wavelengths as a whole, in this particular case an 682 interface on the PXC is considered LSC, and not FSC. 684 A TE link is a group of one or more interfaces on the PXC. All 685 interfaces on a given PXC are required to have identifiers unique to 686 _______ 687 | | 688 /|___| | 689 | |___| PXC | 690 ========| |___| | 691 | |___| | 692 \| |_______| 693 DWDM 694 (transparent to bit-rate and framing) 696 that PXC, and these identifiers are used as labels (see 3.2.1.1 of 697 [GMPLS-SIG]). 699 The following is an example of an interface switching capability 700 descriptor on a transparent OXC (PXC) with external DWDM that is 701 transparent to bit-rate and framing: 703 Interface Switching Capability Descriptor: 704 Interface Switching Capability = LSC 705 Encoding = Lambda (photonic) 706 Reservable Bandwidth = Determined by optical technology limits 708 5.8. Interface on a PXC with no external DWDM 710 The absence of DWDM in between two PXCs, implies that an interface is 711 not limited to one wavelength. Thus, the interface is advertised as 712 FSC. 714 A TE link is a group of one or more interfaces on the PXC. All 715 interfaces on a given PXC are required to have identifiers unique to 716 that PXC, and these identifiers are used as port labels (see 3.2.1.1 717 of [GMPLS-SIG]). 719 Interface Switching Capability Descriptor: 720 Interface Switching Capability = FSC 721 Encoding = Lambda (photonic) 722 Reservable Bandwidth = Determined by optical technology limits 724 Note that this example assumes that the PXC does not restrict each 725 port to carry only one wavelength. 727 5.9. Interface on a OXC with internal DWDM that understands SDH framing 729 This example assumes that DWDM and OXC are connected in such a way 730 that each interface on the OXC handles multiple wavelengths 731 individually. In this case an interface on the OXC is considered LSC, 732 and not FSC. 734 _______ 735 | | 736 /|| ||\ 737 | || OXC || | 738 ========| || || |==== 739 | || || | 740 \||_______||/ 741 DWDM 742 (SDH framed) 744 A TE link is a group of one or more of the interfaces on the OXC. 745 All lambdas associated with a particular interface are required to 746 have identifiers unique to that interface, and these identifiers are 747 used as labels (see 3.2.1.1 of [GMPLS-SIG]). 749 The following is an example of an interface switching capability 750 descriptor on an OXC with internal DWDM that understands SDH framing 751 and supports discrete bandwidths: 753 Interface Switching Capability Descriptor: 754 Interface Switching Capability = LSC 755 Encoding = SDH (comes from DWDM) 756 Max LSP Bandwidth = Determined by DWDM (say STM-16) 758 Interface Switching Capability = LSC 759 Encoding = SDH (comes from DWDM) 760 Max LSP Bandwidth = Determined by DWDM (say STM-64) 762 5.10. Interface on a OXC with internal DWDM that is transparent to bit- 763 rate and framing 765 This example assumes that DWDM and OXC are connected in such a way 766 that each interface on the OXC handles multiple wavelengths 767 individually. In this case an interface on the OXC is considered LSC, 768 and not FSC. 770 _______ 771 | | 772 /|| ||\ 773 | || OXC || | 774 ========| || || |==== 775 | || || | 776 \||_______||/ 777 DWDM 778 (transparent to bit-rate and framing) 780 A TE link is a group of one or more of the interfaces on the OXC. 781 All lambdas associated with a particular interface are required to 782 have identifiers unique to that interface, and these identifiers are 783 used as labels (see 3.2.1.1 of [GMPLS-SIG]). 785 The following is an example of an interface switching capability 786 descriptor on an OXC with internal DWDM that is transparent to bit- 787 rate and framing: 789 Interface Switching Capability Descriptor: 790 Interface Switching Capability = LSC 791 Encoding = Lambda (photonic) 792 Max LSP Bandwidth = Determined by optical technology limits 794 6. Example of interfaces that support multiple switching capabilities 796 There can be many combinations possible, some are described below. 798 6.1. Interface on a PXC+TDM device with external DWDM 800 As discussed earlier, the presence of the external DWDM limits that 801 only one wavelength be on a port of the PXC. On such a port, the 802 attached PXC+TDM device can do one of the following. The wavelength 803 may be cross-connected by the PXC element to other out-bound optical 804 channel, or the wavelength may be terminated as an SDH interface and 805 SDH channels switched. 807 From a GMPLS perspective the PXC+TDM functionality is treated as a 808 single interface. The interface is described using two Interface 809 descriptors, one for the LSC and another for the TDM, with 810 appropriate parameters. For example, 812 Interface Switching Capability Descriptor: 813 Interface Switching Capability = LSC 814 Encoding = SDH (comes from WDM) 815 Reservable Bandwidth = STM-64 817 and 819 Interface Switching Capability Descriptor: 820 Interface Switching Capability = TDM [Standard SDH] 821 Encoding = SDH 822 Min LSP Bandwidth = VC-3 823 Max LSP Bandwidth[p] = STM-64, for all p 825 6.2. Interface on an opaque OXC+TDM device with external DWDM 827 An interface on an "opaque OXC+TDM" device would also be advertised 828 as LSC+TDM much the same way as the previous case. 830 6.3. Interface on a PXC+LSR device with external DWDM 832 As discussed earlier, the presence of the external DWDM limits that 833 only one wavelength be on a port of the PXC. On such a port, the 834 attached PXC+LSR device can do one of the following. The wavelength 835 may be cross-connected by the PXC element to other out-bound optical 836 channel, or the wavelength may be terminated as a Packet interface 837 and packets switched. 839 From a GMPLS perspective the PXC+LSR functionality is treated as a 840 single interface. The interface is described using two Interface 841 descriptors, one for the LSC and another for the PSC, with 842 appropriate parameters. For example, 844 Interface Switching Capability Descriptor: 845 Interface Switching Capability = LSC 846 Encoding = SDH (comes from WDM) 847 Reservable Bandwidth = STM-64 849 and 851 Interface Switching Capability Descriptor: 852 Interface Switching Capability = PSC-1 853 Encoding = SDH 854 Max LSP Bandwidth[p] = 10 Gbps, for all p 856 6.4. Interface on a TDM+LSR device 858 On a TDM+LSR device that offers a channelized SDH interface the 859 following may be possible: 861 - A subset of the SDH channels may be uncommitted. That is, they 862 are not currently in use and hence are available for allocation. 864 - A second subset of channels may already be committed for transit 865 purposes. That is, they are already cross-connected by the SDH 866 cross connect function to other out-bound channels and thus are 867 not immediately available for allocation. 869 - Another subset of channels could be in use as terminal channels. 870 That is, they are already allocated by terminate on a packet 871 interface and packets switched. 873 From a GMPLS perspective the TDM+PSC functionality is treated as a 874 single interface. The interface is described using two Interface 875 descriptors, one for the TDM and another for the PSC, with 876 appropriate parameters. For example, 878 Interface Switching Capability Descriptor: 879 Interface Switching Capability = TDM [Standard SDH] 880 Encoding = SDH 881 Min LSP Bandwidth = VC-3 882 Max LSP Bandwidth[p] = STM-64, for all p 884 and 886 Interface Switching Capability Descriptor: 887 Interface Switching Capability = PSC-1 888 Encoding = SDH 889 Max LSP Bandwidth[p] = 10 Gbps, for all p 891 7. Normative References 893 [GMPLS-OSPF] Kompella, K., and Rekhter, Y. (Editors), "OSPF 894 Extensions in Support of Generalized MPLS", (work in progress) 896 [GMPLS-SIG] Berger, L., and Ashwood-Smith, P. (Editors), "Generalized 897 MPLS - Signaling Functional Description", (work in progress) 899 [GMPLS-SONET-SDH] Mannie, E., and Papadimitriou, D. (Editors), "GMPLS 900 Extensions for SONET and SDH Control", (work in progress) 902 [LINK-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link 903 Bundling in MPLS Traffic Engineering", (work in progress) 905 [LMP] Lang, J. (Editor), "Link Management Protocol (LMP)", (work in 906 progress) 908 [LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS 909 TE", (work in progress) 911 [OSPF-TE] Katz, D., Yeung, D., and Kompella, K., "Traffic Engineering 912 Extensions to OSPF", (work in progress) 914 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 915 Requirement Levels", BCP 14, RFC 2119, March 1997. 917 [RFC3032] Rosen, E., et al, "MPLS Label Stack Encoding", RFC 3032, 918 January 2001. 920 8. Informative References 922 [GMPLS-ISIS] Kompella, K., Rekhter, Y. (Editors), "IS-IS Extensions 923 in Support of Generalized MPLS", (work in progress) 925 [ISIS-TE] Smit, H., Li, T., "IS-IS Extensions for Traffic 926 Engineering", (work in progress) 928 9. Security Considerations 930 The routing extensions proposed in this document do not raise any new 931 security concerns. 933 10. Acknowledgements 935 The authors would like to thank Suresh Katukam, Jonathan Lang, Zhi- 936 Wei Lin, and Quaizar Vohra for their comments and contributions to 937 the draft. 939 11. Contributors 941 Ayan Banerjee 942 Calient Networks 943 5853 Rue Ferrari 944 San Jose, CA 95138 945 Phone: +1.408.972.3645 946 Email: abanerjee@calient.net 948 John Drake 949 Calient Networks 950 5853 Rue Ferrari 951 San Jose, CA 95138 952 Phone: (408) 972-3720 953 Email: jdrake@calient.net 955 Greg Bernstein 956 Ciena Corporation 957 10480 Ridgeview Court 958 Cupertino, CA 94014 959 Phone: (408) 366-4713 960 Email: greg@ciena.com 962 Don Fedyk 963 Nortel Networks Corp. 964 600 Technology Park Drive 965 Billerica, MA 01821 966 Phone: +1-978-288-4506 967 Email: dwfedyk@nortelnetworks.com 969 Eric Mannie 970 Libre Exaministe 971 Email: eric_mannie@hotmail.com 973 Debanjan Saha 974 Tellium Optical Systems 975 2 Crescent Place 976 P.O. Box 901 977 Ocean Port, NJ 07757 978 Phone: (732) 923-4264 979 Email: dsaha@tellium.com 981 Vishal Sharma 982 Metanoia, Inc. 983 335 Elan Village Lane, Unit 203 984 San Jose, CA 95134-2539 985 Phone: +1 408-943-1794 986 Email: v.sharma@ieee.org 988 Debashis Basak 989 AcceLight Networks, 990 70 Abele Rd, Bldg 1200 991 Bridgeville PA 15017 992 Email: dbasak@accelight.com 994 Lou Berger 995 Movaz Networks, Inc. 996 7926 Jones Branch Drive 997 Suite 615 998 McLean VA, 22102 999 Email: lberger@movaz.com 1001 12. Authors' Information 1003 Kireeti Kompella 1004 Juniper Networks, Inc. 1005 1194 N. Mathilda Ave 1006 Sunnyvale, CA 94089 1007 Email: kireeti@juniper.net 1009 Yakov Rekhter 1010 Juniper Networks, Inc. 1011 1194 N. Mathilda Ave 1012 Sunnyvale, CA 94089 1013 Email: yakov@juniper.net 1015 Intellectual Property Rights Notices 1017 The IETF takes no position regarding the validity or scope of any 1018 intellectual property or other rights that might be claimed to 1019 pertain to the implementation or use of the technology described in 1020 this document or the extent to which any license under such rights 1021 might or might not be available; neither does it represent that it 1022 has made any effort to identify any such rights. Information on the 1023 IETF's procedures with respect to rights in standards-track and 1024 standards-related documentation can be found in BCP-11. Copies of 1025 claims of rights made available for publication and any assurances of 1026 licenses to be made available, or the result of an attempt made to 1027 obtain a general license or permission for the use of such 1028 proprietary rights by implementors or users of this specification can 1029 be obtained from the IETF Secretariat. 1031 The IETF invites any interested party to bring to its attention any 1032 copyrights, patents or patent applications, or other proprietary 1033 rights which may cover technology that may be required to practice 1034 this standard. Please address the information to the IETF Executive 1035 Director. 1037 Full Copyright Statement 1039 Copyright (C) The Internet Society (2002). All Rights Reserved. 1041 This document and translations of it may be copied and furnished to 1042 others, and derivative works that comment on or otherwise explain it 1043 or assist in its implmentation may be prepared, copied, published and 1044 distributed, in whole or in part, without restriction of any kind, 1045 provided that the above copyright notice and this paragraph are 1046 included on all such copies and derivative works. However, this 1047 document itself may not be modified in any way, such as by removing 1048 the copyright notice or references to the Internet Society or other 1049 Internet organizations, except as needed for the purpose of 1050 developing Internet standards in which case the procedures for 1051 copyrights defined in the Internet Standards process must be 1052 followed, or as required to translate it into languages other than 1053 English. 1055 The limited permissions granted above are perpetual and will not be 1056 revoked by the Internet Society or its successors or assigns. 1058 This document and the information contained herein is provided on an 1059 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1060 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1061 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1062 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1063 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.