idnits 2.17.1 draft-ietf-ccamp-gmpls-routing-09.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. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 25 pages 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 abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 683 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.) -- The document date (October 2003) is 7497 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: 'PSC' is mentioned on line 585, but not defined == Missing Reference: 'TDM' is mentioned on line 587, but not defined == Missing Reference: 'LSC' is mentioned on line 588, but not defined == Missing Reference: 'FSC' is mentioned on line 588, but not defined == Missing Reference: 'Standard SDH' is mentioned on line 941, but not defined == Missing Reference: 'Arbitrary SDH' is mentioned on line 667, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-ospf-gmpls-extensions-11 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE' == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-04 == Outdated reference: A later version (-10) exists of draft-ietf-ccamp-lmp-09 == Outdated reference: A later version (-19) exists of draft-ietf-isis-gmpls-extensions-16 Summary: 6 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, Editor 3 Internet Draft Y. Rekhter, Editor 4 Category: Standards Track Juniper Networks 5 Expires: April 2004 October 2003 7 Routing Extensions in Support of Generalized 8 Multi-Protocol Label Switching 10 draft-ietf-ccamp-gmpls-routing-09.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document specifies routing extensions in support of carrying 40 link state information for Generalized Multi-Protocol Label Switching 41 (GMPLS). This document enhances the routing extensions required to 42 support MPLS Traffic Engineering (TE). 44 Changes since the last version 46 Incorporated comments from IESG review and Thaler's comments. 48 Specification of Requirements 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC 2119 [RFC2119]. 54 1. Introduction 56 This document specifies routing extensions in support of carrying 57 link state information for Generalized Multi-Protocol Label Switching 58 (GMPLS). This document enhances the routing extensions [ISIS-TE], 59 [OSPF-TE] required to support MPLS Traffic Engineering (TE). 61 Traditionally, a TE link is advertised as an adjunct to a "regular" 62 link, i.e., a routing adjacency is brought up on the link, and when 63 the link is up, both the properties of the link used for Shortest 64 Path First (SPF) computations (basically, the SPF metric) and the TE 65 properties of the link are then advertised. 67 GMPLS challenges this notion in three ways. First, links that are 68 not capable of sending and receiving on a packet-by-packet basis may 69 yet have TE properties; however, a routing adjacency cannot be 70 brought up on such links. Second, a Label Switched Path can be 71 advertised as a point-to-point TE link (see [LSP-HIER]); thus, an 72 advertised TE link may be between a pair of nodes that don't have a 73 routing adjacency with each other. Finally, a number of links may be 74 advertised as a single TE link (perhaps for improved scalability), so 75 again, there is no longer a one-to-one association of a regular 76 routing adjacency and a TE link. 78 Thus we have a more general notion of a TE link. A TE link is a 79 "logical" link that has TE properties. The link is logical in a 80 sense that it represents a way to group/map the information about 81 certain physical resources (and their properties) into the 82 information that is used by Constrained SPF for the purpose of path 83 computation, and by GMPLS signaling. This grouping/mapping must be 84 done consistently at both ends of the link. LMP [LMP] could be used 85 to check/verify this consistency. 87 Depending on the nature of resources that form a particular TE link, 88 for the purpose of GMPLS signaling in some cases the combination of 89 is sufficient to unambiguously identify 90 the appropriate resource used by an LSP. In other cases, the 91 combination of is not sufficient - such 92 cases are handled by using the link bundling construct [LINK-BUNDLE] 93 that allows to identify the resource by . 96 Some of the properties of a TE link may be configured on the 97 advertising Label Switching Router (LSR), others which may be 98 obtained from other LSRs by means of some protocol, and yet others 99 which may be deduced 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 (e.g., an IGP adjacency) between these LSRs. As we 103 mentioned above, in certain cases a TE link between a pair of LSRs 104 could be advertised even if there is no routing adjacency at all 105 between the LSRs (e.g., when the TE link is a Forwarding Adjacency 106 (see [LSP-HIER])). 108 A TE link must have some means by which the advertising LSR can know 109 of its liveness (this means may be routing hellos, but is not limited 110 to routing hellos). When an LSR knows that a TE link is up, and can 111 determine the TE link's TE properties, the LSR may then advertise 112 that link to its (regular) neighbors. 114 In this document, we call the interfaces over which regular routing 115 adjacencies are established "control channels". 117 [ISIS-TE] and [OSPF-TE] define the canonical TE properties, and say 118 how to associate TE properties to regular (packet-switched) links. 119 This document extends the set of TE properties, and also says how to 120 associate TE properties with non-packet-switched links such as links 121 between Optical Cross-Connects (OXCs). [LSP-HIER] says how to 122 associate TE properties with links formed by Label Switched Paths. 124 1.1. Requirements for Layer-specific TE Attributes 126 In generalizing TE links to include traditional transport facilities, 127 there are additional factors that influence what information is 128 needed about the TE link. These arise from existing transport layer 129 architecture (e.g., ITU-T Recommendations G.805 and G.806) and 130 associated layer services. Some of these factors are: 132 1. The need for LSPs at a specific adaptation, not just a particular 133 bandwidth. Clients of optical networks obtain connection services 134 for specific adaptations, for example, a VC-3 circuit. This not 135 only implies a particular bandwidth, but how the payload is 136 structured. Thus the VC-3 client would not be satisfied with any 137 LSP that offered other than 48.384 Mbit/s and with the expected 138 structure. The corollary is that path computation should be able 139 to find a route that would give a connection at a specific 140 adaptation. 142 2. Distinguishing variable adaptation. A resource between two OXCs 143 (specifically a G.805 trail) can sometimes support different 144 adaptations at the same time. An example of this is described in 145 section 2.4.8. In this situation, the fact that two adaptations 146 are supported on the same trail is important because the two 147 layers are dependent, and it is important to be able to reflect 148 this layer relationship in routing, especially in view of the 149 relative lack of flexibility of transport layers compared to 150 packet layers. 152 3. Inheritable attributes. When a whole multiplexing hierarchy is 153 supported by a TE link, a lower layer attribute may be applicable 154 to the upper layers. Protection attributes are a good example of 155 this. If an OC-192 link is 1+1 protected (a duplicate OC-192 156 exists for protection), then an OC-3c within that OC-192 (a higher 157 layer) would inherit the same protection property. 159 4. Extensibility of layers. In addition to the existing defined 160 transport layers, new layers and adaptation relationships could 161 come into existence in the future. 163 5. Heterogeneous networks whose OXCs do not all support the same set 164 of layers. In a GMPLS network, not all transport layer network 165 elements are expected to support the same layers. For example, 166 there may be switches capable of only VC-11, VC-12, and VC-3, 167 where as there may be others that can only support VC-3 and VC-4. 168 Even though a network element cannot support a specific layer, it 169 should be able to know if a network element elsewhere in the 170 network can support an adaptation that would enable that 171 unsupported layer to be used. For example, a VC-11 switch could 172 use a VC-3 capable switch if it knew that a VC-11 path could be 173 constructed over a VC-3 link connection. 175 From the factors presented above, development of layer specific GMPLS 176 routing documents should use the following principles for TE-link 177 attributes. 179 1. Separation of attributes. The attributes in a given layer are 180 separated from attributes in another layer. 182 2. Support of inter-layer attributes (e.g., adaptation 183 relationships). Between a client and server layer, a general 184 mechanism for describing the layer relationship exists. For 185 example "4 client links of type X can be supported by this server 186 layer link". Another example is being able to identify when two 187 layers share a common server layer. 189 3. Support for inheritable attributes. Attributes which can be 190 inherited should be identified. 192 4. Layer extensibilty. Attributes should be represented in routing 193 such that future layers can be accommodated. This is much like 194 the notion of the generalized label. 196 5. Explicit attribute scope. For example, it should be clear whether 197 a given attribute applies to a set of links at the same layer. 199 The present document captures general attributes that apply to a 200 single layer network, but doesn't capture inter-layer relationships 201 of attributes. This work is left to a future document. 203 1.2. Excluding data traffic from control channels 205 The control channels between nodes in a GMPLS network, such as OXCs, 206 SDH cross-connects and/or routers, are generally meant for control 207 and administrative traffic. These control channels are advertised 208 into routing as normal links as mentioned in the previous section; 209 this allows the routing of (for example) RSVP messages and telnet 210 sessions. However, if routers on the edge of the optical domain 211 attempt to forward data traffic over these channels, the channel 212 capacity will quickly be exhausted. 214 In order to keep these control channels from being advertised into 215 the user data plane a variety of techniques can be used. 217 If one assumes that data traffic is sent to BGP destinations, and 218 control traffic to IGP destinations, then one can exclude data 219 traffic from the control plane by restricting BGP nexthop resolution. 220 (It is assumed that OXCs are not BGP speakers.) Suppose that a 221 router R is attempting to install a route to a BGP destination D. R 222 looks up the BGP nexthop for D in its IGP's routing table. Say R 223 finds that the path to the nexthop is over interface I. R then 224 checks if it has an entry in its Link State database associated with 225 the interface I. If it does, and the link is not packet-switch 226 capable (see [LSP_HIER]), R installs a discard route for destination 227 D. Otherwise, R installs (as usual) a route for destination D with 228 nexthop I. Note that R need only do this check if it has 229 packet-switch incapable links; if all of its links are packet-switch 230 capable, then clearly this check is redundant. 232 In other instances it may be desirable to keep the whole address 233 space of a GMPLS routing plane disjoint from the endpoint addresses 234 in another portion of the GMPLS network. For example, the addresses 235 of a carrier network where the carrier uses GMPLS but does not wish 236 to expose the internals of the addressing or topology. In such a 237 network the control channels are never advertised into the end data 238 network. In this instance, independent mechanisms are used to 239 advertise the data addresses over the carrier network. 241 Other techniques for excluding data traffic from control channels may 242 also be needed. 244 2. GMPLS Routing Enhancements 246 In this section we define the enhancements to the TE properties of 247 GMPLS TE links. Encoding of this information in IS-IS is specified 248 in [GMPLS-ISIS]. Encoding of this information in OSPF is specified 249 in [GMPLS-OSPF]. 251 2.1. Support for unnumbered links 253 An unnumbered link has to be a point-to-point link. An LSR at each 254 end of an unnumbered link assigns an identifier to that link. This 255 identifier is a non-zero 32-bit number that is unique within the 256 scope of the LSR that assigns it. 258 Consider an (unnumbered) link between LSRs A and B. LSR A chooses an 259 idenfitier for that link. So does LSR B. From A's perspective we 260 refer to the identifier that A assigned to the link as the "link 261 local identifier" (or just "local identifier"), and to the identifier 262 that B assigned to the link as the "link remote identifier" (or just 263 "remote identifier"). Likewise, from B's perspective the identifier 264 that B assigned to the link is the local identifier, and the 265 identifier that A assigned to the link is the remote identifier. 267 Support for unnumbered links in routing includes carrying information 268 about the identifiers of that link. Specifically, when an LSR 269 advertises an unnumbered TE link, the advertisement carries both the 270 local and the remote identifiers of the link. If the LSR doesn't 271 know the remote identifier of that link, the LSR should use a value 272 of 0 as the remote identifier. 274 2.2. Link Protection Type 276 The Link Protection Type represents the protection capability that 277 exists for a link. It is desirable to carry this information so that 278 it may be used by the path computation algorithm to set up LSPs with 279 appropriate protection characteristics. This information is 280 organized in a hierarchy where typically the minimum acceptable 281 protection is specified at path instantiation and a path selection 282 technique is used to find a path that satisfies at least the minimum 283 acceptable protection. Protection schemes are presented in order 284 from lowest to highest protection. 286 This document defines the following protection capabilities: 288 Extra Traffic 289 If the link is of type Extra Traffic, it means that the link is 290 protecting another link or links. The LSPs on a link of this type 291 will be lost if any of the links it is protecting fail. 293 Unprotected 294 If the link is of type Unprotected, it means that there is no 295 other link protecting this link. The LSPs on a link of this type 296 will be lost if the link fails. 298 Shared 299 If the link is of type Shared, it means that there are one or more 300 disjoint links of type Extra Traffic that are protecting this 301 link. These Extra Traffic links are shared between one or more 302 links of type Shared. 304 Dedicated 1:1 305 If the link is of type Dedicated 1:1, it means that there is one 306 dedicated disjoint link of type Extra Traffic that is protecting 307 this link. 309 Dedicated 1+1 310 If the link is of type Dedicated 1+1, it means that a dedicated 311 disjoint link is protecting this link. However, the protecting 312 link is not advertised in the link state database and is therefore 313 not available for the routing of LSPs. 315 Enhanced 316 If the link is of type Enhanced, it means that a protection scheme 317 that is more reliable than Dedicated 1+1, e.g., 4 fiber 318 BLSR/MS-SPRING, is being used to protect this link. 320 The Link Protection Type is optional, and if a Link State 321 Advertisement doesn't carry this information, then the Link 322 Protection Type is unknown. 324 2.3. Shared Risk Link Group Information 326 A set of links may constitute a 'shared risk link group' (SRLG) if 327 they share a resource whose failure may affect all links in the set. 328 For example, two fibers in the same conduit would be in the same 329 SRLG. A link may belong to multiple SRLGs. Thus the SRLG 330 Information describes a list of SRLGs that the link belongs to. An 331 SRLG is identified by a 32 bit number that is unique within an IGP 332 domain. The SRLG Information is an unordered list of SRLGs that the 333 link belongs to. 335 The SRLG of a LSP is the union of the SRLGs of the links in the LSP. 336 The SRLG of a bundled link is the union of the SRLGs of all the 337 component links. 339 If an LSR is required to have multiple diversely routed LSPs to 340 another LSR, the path computation should attempt to route the paths 341 so that they do not have any links in common, and such that the path 342 SRLGs are disjoint. 344 The SRLG Information may start with a configured value, in which case 345 it does not change over time, unless reconfigured. 347 The SRLG Information is optional and if a Link State Advertisement 348 doesn't carry the SRLG Information, then it means that SRLG of that 349 link is unknown. 351 2.4. Interface Switching Capability Descriptor 353 In the context of this document we say that a link is connected to a 354 node by an interface. In the context of GMPLS interfaces may have 355 different switching capabilities. For example an interface that 356 connects a given link to a node may not be able to switch individual 357 packets, but it may be able to switch channels within an SDH payload. 358 Interfaces at each end of a link need not have the same switching 359 capabilities. Interfaces on the same node need not have the same 360 switching capabilities. 362 The Interface Switching Capability Descriptor describes switching 363 capability of an interface. For bi-directional links, the switching 364 capabilities of an interface are defined to be the same in either 365 direction. I.e., for data entering the node through that interface 366 and for data leaving the node through that interface. 368 A Link State Advertisement of a link carries the Interface Switching 369 Capability Descriptor(s) only of the near end (the end incumbent on 370 the LSR originating the advertisement). 372 An LSR performing path computation uses the Link State Database to 373 determine whether a link is unidirectional or bidirectional. 375 For a bidirectional link the LSR uses its Link State Database to 376 determine the Interface Switching Capability Descriptor(s) of the 377 far-end of the link, as bidirectional links with different Interface 378 Switching Capabilities at its two ends are allowed. 380 For a unidirectional link it is assumed that the Interface Switching 381 Capability Descriptor at the far-end of the link is the same as at 382 the near-end. Thus, an unidirectional link is required to have the 383 same interface switching capabilities at both ends. This seems a 384 reasonable assumption given that unidirectional links arise only with 385 packet forwarding adjacencies and for these both ends belong to the 386 same level of the PSC hierarchy. 388 This document defines the following Interface Switching Capabilities: 390 Packet-Switch Capable-1 (PSC-1) 391 Packet-Switch Capable-2 (PSC-2) 392 Packet-Switch Capable-3 (PSC-3) 393 Packet-Switch Capable-4 (PSC-4) 394 Layer-2 Switch Capable (L2SC) 395 Time-Division-Multiplex Capable (TDM) 396 Lambda-Switch Capable (LSC) 397 Fiber-Switch Capable (FSC) 399 If there is no Interface Switching Capability Descriptor for an 400 interface, the interface is assumed to be packet-switch capable 401 (PSC-1). 403 Interface Switching Capability Descriptors present a new constraint 404 for LSP path computation. 406 Irrespective of a particular Interface Switching Capability, the 407 Interface Switching Capability Descriptor always includes information 408 about the encoding supported by an interface. The defined encodings 409 are the same as LSP Encoding as defined in [GMPLS-SIG]. 411 An interface may have more than one Interface Switching Capability 412 Descriptor. This is used to handle interfaces that support multiple 413 switching capabilities, for interfaces that have Max LSP Bandwidth 414 values that differ by priority level, and for interfaces that support 415 discrete bandwidths. 417 Depending on a particular Interface Switching Capability, the 418 Interface Switching Capability Descriptor may include additional 419 information, as specified below. 421 2.4.1. Layer-2 Switch Capable 423 If an interface is of type L2SC, it means that the node receiving 424 data over this interface can switch the received frames based on the 425 layer 2 address. For example, an interface associated with a link 426 terminating on an ATM switch would be considered L2SC. 428 2.4.2. Packet-Switch Capable 430 If an interface is of type PSC-1 through PSC-4, it means that the 431 node receiving data over this interface can switch the received data 432 on a packet-by-packet basis, based on the label carried in the "shim" 433 header [RFC3032]. The various levels of PSC establish a hierarchy of 434 LSPs tunneled within LSPs. 436 For Packet-Switch Capable interfaces the additional information 437 includes Maximum LSP Bandwidth, Minimum LSP Bandwidth, and interface 438 MTU. 440 For a simple (unbundled) link, the Maximum LSP Bandwidth at priority 441 p is defined to be the smaller of the unreserved bandwidth at 442 priority p and a "Maximum LSP Size" parameter which is locally 443 configured on the link, and whose default value is equal to the Max 444 Link Bandwidth. Maximum LSP Bandwidth for a bundled link is defined 445 in [LINK-BUNDLE]. 447 The Maximum LSP Bandwidth takes the place of the Maximum Link 448 Bandwidth ([ISIS-TE], [OSPF-TE]). However, while Maximum Link 449 Bandwidth is a single fixed value (usually simply the link capacity), 450 Maximum LSP Bandwidth is carried per priority, and may vary as LSPs 451 are set up and torn down. 453 Although Maximum Link Bandwidth is to be deprecated, for backward 454 compatibility, one MAY set the Maximum Link Bandwidth to the Maximum 455 LSP Bandwidth at priority 7. 457 The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP 458 could reserve. 460 Typical values for the Minimum LSP Bandwidth and for the Maximum LSP 461 Bandwidth are enumerated in [GMPLS-SIG]. 463 On a PSC interface that supports Standard SDH encoding, an LSP at 464 priority p could reserve any bandwidth allowed by the branch of the 465 SDH hierarchy, with the leaf and the root of the branch being defined 466 by the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at 467 priority p. 469 On a PSC interface that supports Arbitrary SDH encoding, an LSP at 470 priority p could reserve any bandwidth between the Minimum LSP 471 Bandwidth and the Maximum LSP Bandwidth at priority p, provided that 472 the bandwidth reserved by the LSP is a multiple of the Minimum LSP 473 Bandwidth. 475 The Interface MTU is the maximum size of a packet that can be 476 transmitted on this interface without being fragmented. 478 2.4.3. Time-Division Multiplex Capable 480 If an interface is of type TDM, it means that the node receiving data 481 over this interface can multiplex or demultiplex channels within an 482 SDH payload. 484 For Time-Division Multiplex Capable interfaces the additional 485 information includes Maximum LSP Bandwidth, the information on 486 whether the interface supports Standard or Arbitrary SDH, and Minimum 487 LSP Bandwidth. 489 For a simple (unbundled) link the Maximum LSP Bandwidth at priority p 490 is defined as the maximum bandwidth an LSP at priority p could 491 reserve. Maximum LSP Bandwidth for a bundled link is defined in 492 [LINK-BUNDLE]. 494 The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP 495 could reserve. 497 Typical values for the Minimum LSP Bandwidth and for the Maximum LSP 498 Bandwidth are enumerated in [GMPLS-SIG]. 500 On an interface having Standard SDH multiplexing, an LSP at priority 501 p could reserve any bandwidth allowed by the branch of the SDH 502 hierarchy, with the leaf and the root of the branch being defined by 503 the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority 504 p. 506 On an interface having Arbitrary SDH multiplexing, an LSP at priority 507 p could reserve any bandwidth between the Minimum LSP Bandwidth and 508 the Maximum LSP Bandwidth at priority p, provided that the bandwidth 509 reserved by the LSP is a multiple of the Minimum LSP Bandwidth. 511 Interface Switching Capability Descriptor for the interfaces that 512 support sub VC-3 may include additional information. The nature and 513 the encoding of such information is outside the scope of this 514 document. 516 A way to handle the case where an interface supports multiple 517 branches of the SDH multiplexing hierarchy, multiple Interface 518 Switching Capability Descriptors would be advertised, one per branch. 519 For example, if an interface supports VC-11 and VC-12 (which are not 520 part of same branch of SDH multiplexing tree), then it could 521 advertise two descriptors, one for each one. 523 2.4.4. Lambda-Switch Capable 525 If an interface is of type LSC, it means that the node receiving data 526 over this interface can recognize and switch individual lambdas 527 within the interface. An interface that allows only one lambda per 528 interface, and switches just that lambda is of type LSC. 530 The additional information includes Reservable Bandwidth per 531 priority, which specifies the bandwidth of an LSP that could be 532 supported by the interface at a given priority number. 534 A way to handle the case of multiple data rates or multiple encodings 535 within a single TE Link, multiple Interface Switching Capability 536 Descriptors would be advertised, one per supported data rate and 537 encoding combination. For example, an LSC interface could support 538 the establishment of LSC LSPs at both STM-16 and STM-64 data rates. 540 2.4.5. Fiber-Switch Capable 542 If an interface is of type FSC, it means that the node receiving data 543 over this interface can switch the entire contents to another 544 interface (without distinguishing lambdas, channels or packets). 545 I.e., an interface of type FSC switches at the granularity of an 546 entire interface, and can not extract individual lambdas within the 547 interface. An interface of type FSC can not restrict itself to just 548 one lambda. 550 2.4.6. Multiple Switching Capabilities per interface 552 An interface that connects a link to an LSR may support not one, but 553 several Interface Switching Capabilities. For example, consider a 554 fiber link carrying a set of lambdas that terminates on an LSR 555 interface that could either cross-connect one of these lambdas to 556 some other outgoing optical channel, or could terminate the lamdba, 557 and extract (demultiplex) data from that lambda using TDM, and then 558 cross-connect these TDM channels to some outgoing TDM channels. To 559 support this a Link State Advertisement may carry a list of Interface 560 Switching Capabilities Descriptors. 562 2.4.7. Interface Switching Capabilities and Labels 564 Depicting a TE link as a tuple that contains Interface Switching 565 Capabilities at both ends of the link, some examples links may be: 567 [PSC, PSC] - a link between two packet LSRs 568 [TDM, TDM] - a link between two Digital Cross Connects 569 [LSC, LSC] - a link between two OXCs 570 [PSC, TDM] - a link between a packet LSR and Digital Cross Connect 571 [PSC, LSC] - a link between a packet LSR and an OXC 572 [TDM, LSC] - a link between a Digital Cross Connect and an OXC 574 Both ends of a given TE link has to use the same way of carrying 575 label information over that link. Carrying label information on a 576 given TE link depends on the Interface Switching Capability at both 577 ends of the link, and is determined as follows: 579 [PSC, PSC] - label is carried in the "shim" header [RFC3032] 580 [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] 581 [LSC, LSC] - label represents a lambda 582 [FSC, FSC] - label represents a port on an OXC 583 [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] 584 [PSC, LSC] - label represents a lambda 585 [PSC, FSC] - label represents a port 586 [TDM, LSC] - label represents a lambda 587 [TDM, FSC] - label represents a port 588 [LSC, FSC] - label represents a port 590 2.4.8. Other issues 592 It is possible that Interface Switching Capability Descriptor will 593 change over time, reflecting the allocation/deallocation of LSPs. 594 For example, assume that VC-3, VC-4, VC-4-4c, VC-4-16c and VC-4-64c 595 LSPs can be established on a STM-64 interface whose Encoding Type is 596 SDH. Thus, initially in the Interface Switching Capability 597 Descriptor the Minimum LSP Bandwidth is set to VC-3, and Maximum LSP 598 Bandwidth is set to STM-64 for all priorities. As soon as an LSP of 599 VC-3 size at priority 1 is established on the interface, it is no 600 longer capable of VC-4-64c for all but LSPs at priority 0. 601 Therefore, the node advertises a modified Interface Switching 602 Capability Descriptor indicating that the Maximum LSP Bandwidth is no 603 longer STM-64, but STM-16 for all but priority 0 (at priority 0 the 604 Maximum LSP Bandwidth is still STM-64). If subsequently there is 605 another VC-3 LSP, there is no change in the Interface Switching 606 Capability Descriptor. The Descriptor remains the same until the 607 node can no longer establish a VC-4-16c LSP over the interface (which 608 means that at this point more than 144 time slots are taken by LSPs 609 on the interface). Once this happened, the Descriptor is modified 610 again, and the modified Descriptor is advertised to other nodes. 612 2.5. Bandwidth Encoding 614 Encoding in IEEE floating point format [IEEE] of the discrete values 615 that could be used to identify Unreserved bandwidth, Maximum LSP 616 bandwidth and Minimum LSP bandwidth is described in Section 3.1.2 of 617 [GMPLS-SIG]. 619 3. Examples of Interface Switching Capability Descriptor 621 3.1. STM-16 POS Interface on a LSR 623 Interface Switching Capability Descriptor: 624 Interface Switching Capability = PSC-1 625 Encoding = SDH 626 Max LSP Bandwidth[p] = 2.5 Gbps, for all p 628 If multiple links with such interfaces at both ends were to be 629 advertised as one TE link, link bundling techniques should be used. 631 3.2. GigE Packet Interface on a LSR 633 Interface Switching Capability Descriptor: 634 Interface Switching Capability = PSC-1 635 Encoding = Ethernet 802.3 636 Max LSP Bandwidth[p] = 1.0 Gbps, for all p 638 If multiple links with such interfaces at both ends were to be 639 advertised as one TE link, link bundling techniques should be used. 641 3.3. STM-64 SDH Interface on a Digital Cross Connect with Standard SDH 643 Consider a branch of SDH multiplexing tree : VC-3, VC-4, VC-4-4c, 644 VC-4-16c, VC-4-64c. If it is possible to establish all these 645 connections on a STM-64 interface, the Interface Switching Capability 646 Descriptor of that interface can be advertised as follows: 648 Interface Switching Capability Descriptor: 649 Interface Switching Capability = TDM [Standard SDH] 650 Encoding = SDH 651 Min LSP Bandwidth = VC-3 652 Max LSP Bandwidth[p] = STM-64, for all p 654 If multiple links with such interfaces at both ends were to be 655 advertised as one TE link, link bundling techniques should be used. 657 3.4. STM-64 SDH Interface on a Digital Cross Connect with two types of 658 SDH multiplexing hierarchy supported 660 Interface Switching Capability Descriptor 1: 661 Interface Switching Capability = TDM [Standard SDH] 662 Encoding = SDH 663 Min LSP Bandwidth = VC-3 664 Max LSP Bandwidth[p] = STM-64, for all p 666 Interface Switching Capability Descriptor 2: 667 Interface Switching Capability = TDM [Arbitrary SDH] 668 Encoding = SDH 669 Min LSP Bandwidth = VC-4 670 Max LSP Bandwidth[p] = STM-64, for all p 672 If multiple links with such interfaces at both ends were to be 673 advertised as one TE link, link bundling techniques should be used. 675 3.5. Interface on an opaque OXC (SDH framed) with support for one lambda 676 per port/interface 678 An "opaque OXC" is considered operationally an OXC, as the whole 679 lambda (carrying the SDH line) is switched transparently without 680 further multiplexing/demultiplexing, and either none of the SDH 681 overhead bytes, or at least the important ones are not changed. 683 An interface on an opaque OXC handles a single wavelength, and 684 cannot switch multiple wavelengths as a whole. Thus, an interface on 685 an opaque OXC is always LSC, and not FSC, irrespective of whether 686 there is DWDM external to it. 688 Note that if there is external DWDM, then the framing understood by 689 the DWDM must be same as that understood by the OXC. 691 A TE link is a group of one or more interfaces on an OXC. All 692 interfaces on a given OXC are required to have identifiers unique to 693 that OXC, and these identifiers are used as labels (see 3.2.1.1 of 694 [GMPLS-SIG]). 696 The following is an example of an interface switching capability 697 descriptor on an SDH framed opaque OXC: 699 Interface Switching Capability Descriptor: 700 Interface Switching Capability = LSC 701 Encoding = SDH 702 Reservable Bandwidth = Determined by SDH Framer (say STM-64) 704 3.6. Interface on a transparent OXC (PXC) with external DWDM that 705 understands SDH framing 707 This example assumes that DWDM and PXC are connected in such a way 708 that each interface (port) on the PXC handles just a single 709 wavelength. Thus, even if in principle an interface on the PXC could 710 switch multiple wavelengths as a whole, in this particular case an 711 interface on the PXC is considered LSC, and not FSC. 713 _______ 714 | | 715 /|___| | 716 | |___| PXC | 717 ========| |___| | 718 | |___| | 719 \| |_______| 720 DWDM 721 (SDH framed) 723 A TE link is a group of one or more interfaces on the PXC. All 724 interfaces on a given PXC are required to have identifiers unique to 725 that PXC, and these identifiers are used as labels (see 3.2.1.1 of 726 [GMPLS-SIG]). 728 The following is an example of an interface switching capability 729 descriptor on a transparent OXC (PXC) with external DWDM that 730 understands SDH framing: 732 Interface Switching Capability Descriptor: 733 Interface Switching Capability = LSC 734 Encoding = SDH (comes from DWDM) 735 Reservable Bandwidth = Determined by DWDM (say STM-64) 737 3.7. Interface on a transparent OXC (PXC) with external DWDM that is 738 transparent to bit-rate and framing 740 This example assumes that DWDM and PXC are connected in such a way 741 that each interface (port) on the PXC handles just a single 742 wavelength. Thus, even if in principle an interface on the PXC could 743 switch multiple wavelengths as a whole, in this particular case an 744 interface on the PXC is considered LSC, and not FSC. 746 A TE link is a group of one or more interfaces on the PXC. All 747 interfaces on a given PXC are required to have identifiers unique to 748 _______ 749 | | 750 /|___| | 751 | |___| PXC | 752 ========| |___| | 753 | |___| | 754 \| |_______| 755 DWDM 756 (transparent to bit-rate and framing) 758 that PXC, and these identifiers are used as labels (see 3.2.1.1 of 759 [GMPLS-SIG]). 761 The following is an example of an interface switching capability 762 descriptor on a transparent OXC (PXC) with external DWDM that is 763 transparent to bit-rate and framing: 765 Interface Switching Capability Descriptor: 766 Interface Switching Capability = LSC 767 Encoding = Lambda (photonic) 768 Reservable Bandwidth = Determined by optical technology limits 770 3.8. Interface on a PXC with no external DWDM 772 The absence of DWDM in between two PXCs, implies that an interface is 773 not limited to one wavelength. Thus, the interface is advertised as 774 FSC. 776 A TE link is a group of one or more interfaces on the PXC. All 777 interfaces on a given PXC are required to have identifiers unique to 778 that PXC, and these identifiers are used as port labels (see 3.2.1.1 779 of [GMPLS-SIG]). 781 Interface Switching Capability Descriptor: 782 Interface Switching Capability = FSC 783 Encoding = Lambda (photonic) 784 Reservable Bandwidth = Determined by optical technology limits 786 Note that this example assumes that the PXC does not restrict each 787 port to carry only one wavelength. 789 3.9. Interface on a OXC with internal DWDM that understands SDH framing 791 This example assumes that DWDM and OXC are connected in such a way 792 that each interface on the OXC handles multiple wavelengths 793 individually. In this case an interface on the OXC is considered 794 LSC, and not FSC. 796 _______ 797 | | 798 /|| ||\ 799 | || OXC || | 800 ========| || || |==== 801 | || || | 802 \||_______||/ 803 DWDM 804 (SDH framed) 806 A TE link is a group of one or more of the interfaces on the OXC. 807 All lambdas associated with a particular interface are required to 808 have identifiers unique to that interface, and these identifiers are 809 used as labels (see 3.2.1.1 of [GMPLS-SIG]). 811 The following is an example of an interface switching capability 812 descriptor on an OXC with internal DWDM that understands SDH framing 813 and supports discrete bandwidths: 815 Interface Switching Capability Descriptor: 816 Interface Switching Capability = LSC 817 Encoding = SDH (comes from DWDM) 818 Max LSP Bandwidth = Determined by DWDM (say STM-16) 820 Interface Switching Capability = LSC 821 Encoding = SDH (comes from DWDM) 822 Max LSP Bandwidth = Determined by DWDM (say STM-64) 824 3.10. Interface on a OXC with internal DWDM that is transparent to 825 bit-rate and framing 827 This example assumes that DWDM and OXC are connected in such a way 828 that each interface on the OXC handles multiple wavelengths 829 individually. In this case an interface on the OXC is considered 830 LSC, and not FSC. 832 _______ 833 | | 834 /|| ||\ 835 | || OXC || | 836 ========| || || |==== 837 | || || | 838 \||_______||/ 839 DWDM 840 (transparent to bit-rate and framing) 842 A TE link is a group of one or more of the interfaces on the OXC. 843 All lambdas associated with a particular interface are required to 844 have identifiers unique to that interface, and these identifiers are 845 used as labels (see 3.2.1.1 of [GMPLS-SIG]). 847 The following is an example of an interface switching capability 848 descriptor on an OXC with internal DWDM that is transparent to 849 bit-rate and framing: 851 Interface Switching Capability Descriptor: 852 Interface Switching Capability = LSC 853 Encoding = Lambda (photonic) 854 Max LSP Bandwidth = Determined by optical technology limits 856 4. Example of interfaces that support multiple switching capabilities 858 There can be many combinations possible, some are described below. 860 4.1. Interface on a PXC+TDM device with external DWDM 862 As discussed earlier, the presence of the external DWDM limits that 863 only one wavelength be on a port of the PXC. On such a port, the 864 attached PXC+TDM device can do one of the following. The wavelength 865 may be cross-connected by the PXC element to other out-bound optical 866 channel, or the wavelength may be terminated as an SDH interface and 867 SDH channels switched. 869 From a GMPLS perspective the PXC+TDM functionality is treated as a 870 single interface. The interface is described using two Interface 871 descriptors, one for the LSC and another for the TDM, with 872 appropriate parameters. For example, 874 Interface Switching Capability Descriptor: 875 Interface Switching Capability = LSC 876 Encoding = SDH (comes from WDM) 877 Reservable Bandwidth = STM-64 879 and 881 Interface Switching Capability Descriptor: 882 Interface Switching Capability = TDM [Standard SDH] 883 Encoding = SDH 884 Min LSP Bandwidth = VC-3 885 Max LSP Bandwidth[p] = STM-64, for all p 887 4.2. Interface on an opaque OXC+TDM device with external DWDM 889 An interface on an "opaque OXC+TDM" device would also be advertised 890 as LSC+TDM much the same way as the previous case. 892 4.3. Interface on a PXC+LSR device with external DWDM 894 As discussed earlier, the presence of the external DWDM limits that 895 only one wavelength be on a port of the PXC. On such a port, the 896 attached PXC+LSR device can do one of the following. The wavelength 897 may be cross-connected by the PXC element to other out-bound optical 898 channel, or the wavelength may be terminated as a Packet interface 899 and packets switched. 901 From a GMPLS perspective the PXC+LSR functionality is treated as a 902 single interface. The interface is described using two Interface 903 descriptors, one for the LSC and another for the PSC, with 904 appropriate parameters. For example, 906 Interface Switching Capability Descriptor: 907 Interface Switching Capability = LSC 908 Encoding = SDH (comes from WDM) 909 Reservable Bandwidth = STM-64 911 and 913 Interface Switching Capability Descriptor: 914 Interface Switching Capability = PSC-1 915 Encoding = SDH 916 Max LSP Bandwidth[p] = 10 Gbps, for all p 918 4.4. Interface on a TDM+LSR device 920 On a TDM+LSR device that offers a channelized SDH interface the 921 following may be possible: 923 - A subset of the SDH channels may be uncommitted. That is, they 924 are not currently in use and hence are available for allocation. 926 - A second subset of channels may already be committed for transit 927 purposes. That is, they are already cross-connected by the SDH 928 cross connect function to other out-bound channels and thus are 929 not immediately available for allocation. 931 - Another subset of channels could be in use as terminal channels. 932 That is, they are already allocated by terminate on a packet 933 interface and packets switched. 935 From a GMPLS perspective the TDM+PSC functionality is treated as a 936 single interface. The interface is described using two Interface 937 descriptors, one for the TDM and another for the PSC, with 938 appropriate parameters. For example, 940 Interface Switching Capability Descriptor: 941 Interface Switching Capability = TDM [Standard SDH] 942 Encoding = SDH 943 Min LSP Bandwidth = VC-3 944 Max LSP Bandwidth[p] = STM-64, for all p 946 and 948 Interface Switching Capability Descriptor: 949 Interface Switching Capability = PSC-1 950 Encoding = SDH 951 Max LSP Bandwidth[p] = 10 Gbps, for all p 953 Contributors 955 Ayan Banerjee 956 Calient Networks 957 5853 Rue Ferrari 958 San Jose, CA 95138 959 Phone: +1.408.972.3645 960 Email: abanerjee@calient.net 962 John Drake 963 Calient Networks 964 5853 Rue Ferrari 965 San Jose, CA 95138 966 Phone: (408) 972-3720 967 Email: jdrake@calient.net 969 Greg Bernstein 970 Ciena Corporation 971 10480 Ridgeview Court 972 Cupertino, CA 94014 973 Phone: (408) 366-4713 974 Email: greg@ciena.com 976 Don Fedyk 977 Nortel Networks Corp. 978 600 Technology Park Drive 979 Billerica, MA 01821 980 Phone: +1-978-288-4506 981 Email: dwfedyk@nortelnetworks.com 982 Eric Mannie 983 Libre Exaministe 984 Email: eric_mannie@hotmail.com 986 Debanjan Saha 987 Tellium Optical Systems 988 2 Crescent Place 989 P.O. Box 901 990 Ocean Port, NJ 07757 991 Phone: (732) 923-4264 992 Email: dsaha@tellium.com 994 Vishal Sharma 995 Metanoia, Inc. 996 335 Elan Village Lane, Unit 203 997 San Jose, CA 95134-2539 998 Phone: +1 408-943-1794 999 Email: v.sharma@ieee.org 1001 Debashis Basak 1002 AcceLight Networks, 1003 70 Abele Rd, Bldg 1200 1004 Bridgeville PA 15017 1005 Email: dbasak@accelight.com 1007 Lou Berger 1008 Movaz Networks, Inc. 1009 7926 Jones Branch Drive 1010 Suite 615 1011 McLean VA, 22102 1012 Email: lberger@movaz.com 1014 5. Acknowledgements 1016 The authors would like to thank Suresh Katukam, Jonathan Lang, 1017 Zhi-Wei Lin, and Quaizar Vohra for their comments and contributions 1018 to the document. Thanks too to Stephen Shew for the text regarding 1019 "Representing TE Link Capabilities". 1021 6. Security Considerations 1023 There are a number of security concerns in implementing the 1024 extensions proposed here, particularly since these extensions will 1025 potentially be used to control the underlying transport 1026 infrastructure. It is vital that there be secure and/or 1027 authenticated means of transfering this information among the 1028 entities that require its use. 1030 While this document proposes extensions, it does not state how these 1031 extensions are implemented in routing protocols such as OSPF or 1032 IS-IS. The documents that do state how routing protocols implement 1033 these extensions [GMPLS-OSPF, GMPLS-ISIS] must also state how the 1034 information is to be secured. 1036 Normative References 1038 [GMPLS-OSPF] Kompella, K., and Rekhter, Y. (Editors), "OSPF 1039 Extensions in Support of Generalized MPLS", (work in progress) 1040 [draft-ietf-ccamp-ospf-gmpls-extensions-11.txt] 1042 [GMPLS-SIG] Berger, L. (Editor), "Generalized Multi-Protocol Label 1043 Switching (GMPLS) Signaling Functional Description", RFC 3471, 1044 January 2003 1046 [GMPLS-SONET-SDH] Mannie, E., and Papadimitriou, D. (Editors), 1047 "Generalized Multi-Protocol Label Switching Extensions for SONET 1048 and SDH Control", [RFC Ed Queue] [draft-ietf-ccamp-gmpls-sonet- 1049 sdh-08.txt] 1051 [IEEE] IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", 1052 Standard 754-1985, 1985 (ISBN 1-5593-7653-8). 1054 [LINK-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link 1055 Bundling in MPLS Traffic Engineering", [RFC Ed Queue] [draft- 1056 ietf-mpls-bundle-04.txt] 1058 [LMP] Lang, J. (Editor), "Link Management Protocol (LMP)", (work in 1059 progress) [draft-ietf-ccamp-lmp-09.txt] 1061 [LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with 1062 Generalized MPLS TE", [RFC Ed Queue] [draft-ietf-mpls-lsp- 1063 hierarchy-08.txt] 1065 [OSPF-TE] Katz, D., Kompella, K. and Yeung, D., "Traffic Engineering 1066 (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. 1068 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1069 Requirement Levels", BCP 14, RFC 2119, March 1997. 1071 [RFC3032] Rosen, E., et al, "MPLS Label Stack Encoding", RFC 3032, 1072 January 2001. 1074 Informative References 1076 [GMPLS-ISIS] Kompella, K., Rekhter, Y. (Editors), "IS-IS Extensions 1077 in Support of Generalized MPLS", (work in progress) [draft-ietf- 1078 isis-gmpls-extensions-16.txt] 1080 [ISIS-TE] Smit, H., Li, T., "IS-IS Extensions for Traffic 1081 Engineering", (work in progress) [draft-ietf-isis-traffic-05.txt] 1083 Authors' Information 1085 Kireeti Kompella 1086 Juniper Networks, Inc. 1087 1194 N. Mathilda Ave 1088 Sunnyvale, CA 94089 1089 Email: kireeti@juniper.net 1091 Yakov Rekhter 1092 Juniper Networks, Inc. 1093 1194 N. Mathilda Ave 1094 Sunnyvale, CA 94089 1095 Email: yakov@juniper.net 1097 Intellectual Property Rights Notices 1099 The IETF takes no position regarding the validity or scope of any 1100 intellectual property or other rights that might be claimed to 1101 pertain to the implementation or use of the technology described in 1102 this document or the extent to which any license under such rights 1103 might or might not be available; neither does it represent that it 1104 has made any effort to identify any such rights. Information on the 1105 IETF's procedures with respect to rights in standards-track and 1106 standards-related documentation can be found in BCP-11. Copies of 1107 claims of rights made available for publication and any assurances of 1108 licenses to be made available, or the result of an attempt made to 1109 obtain a general license or permission for the use of such 1110 proprietary rights by implementors or users of this specification can 1111 be obtained from the IETF Secretariat. 1113 The IETF invites any interested party to bring to its attention any 1114 copyrights, patents or patent applications, or other proprietary 1115 rights which may cover technology that may be required to practice 1116 this standard. Please address the information to the IETF Executive 1117 Director. 1119 Full Copyright Statement 1121 Copyright (C) The Internet Society (2003). All Rights Reserved. 1123 This document and translations of it may be copied and furnished to 1124 others, and derivative works that comment on or otherwise explain it 1125 or assist in its implementation may be prepared, copied, published 1126 and distributed, in whole or in part, without restriction of any 1127 kind, provided that the above copyright notice and this paragraph are 1128 included on all such copies and derivative works. However, this 1129 document itself may not be modified in any way, such as by removing 1130 the copyright notice or references to the Internet Society or other 1131 Internet organizations, except as needed for the purpose of 1132 developing Internet standards in which case the procedures for 1133 copyrights defined in the Internet Standards process must be 1134 followed, or as required to translate it into languages other than 1135 English. 1137 The limited permissions granted above are perpetual and will not be 1138 revoked by the Internet Society or its successors or assignees. 1140 This document and the information contained herein is provided on an 1141 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1142 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1143 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1144 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1145 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.