idnits 2.17.1 draft-ietf-ccamp-gmpls-routing-07.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 709 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 7492 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 611, but not defined == Missing Reference: 'TDM' is mentioned on line 613, but not defined == Missing Reference: 'LSC' is mentioned on line 614, but not defined == Missing Reference: 'FSC' is mentioned on line 614, but not defined == Missing Reference: 'Standard SDH' is mentioned on line 967, but not defined == Missing Reference: 'Arbitrary SDH' is mentioned on line 693, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'GMPLS-OSPF' -- 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' Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 7 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-07.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 Generalized 40 Multi-Protocol Label Switching (GMPLS). 42 Summary for Sub-IP Area 44 (This section to be removed before publication.) 46 0.1. Summary 48 This document specifies routing extensions in support of Generalized 49 Multi-Protocol Label Switching (GMPLS). 51 0.2. Where does it fit in the Picture of the Sub-IP Work 53 This work fits squarely in the CCAMP box. 55 0.3. Why is it Targeted at this WG 57 This draft is targeted at the CCAMP WG, because this draft specifies 58 the extensions to the link state routing protocols in support of 59 GMPLS, and because GMPLS is within the scope of CCAMP WG. 61 0.4. Justification 63 The WG should consider this document as it specifies the extensions 64 to the link state routing protocols in support of GMPLS. 66 Changes since the last version 68 Added text that this document only covers single layer networks. 69 Updated references. 71 Specification of Requirements 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC 2119 [RFC2119]. 77 1. Introduction 79 This document specifies routing extensions in support of carrying 80 link state information for Generalized Multi-Protocol Label Switching 81 (GMPLS). This document enhances the routing extensions [ISIS-TE], 82 [OSPF-TE] required to support MPLS Traffic Engineering (TE). 84 2. GMPLS TE Links 86 Traditionally, a TE link is advertised as an adjunct to a "regular" 87 link, i.e., a routing adjacency is brought up on the link, and when 88 the link is up, both the regular SPF properties of the link 89 (basically, the SPF metric) and the TE properties of the link are 90 then advertised. 92 GMPLS challenges this notion in three ways. First, links that are 93 not capable of sending and receiving on a packet-by-packet basis may 94 yet have TE properties; however, a routing adjacency cannot be 95 brought up on such links. Second, a Label Switched Path can be 96 advertised as a point-to-point TE link (see [LSP-HIER]); thus, an 97 advertised TE link may be between a pair of nodes that don't have a 98 routing adjacency with each other. Finally, a number of links may be 99 advertised as a single TE link (perhaps for improved scalability), so 100 again, there is no longer a one-to-one association of a regular 101 routing adjacency and a TE link. 103 Thus we have a more general notion of a TE link. A TE link is a 104 "logical" link that has TE properties. The link is logical in a 105 sense that it represents a way to group/map the information about 106 certain physical resources (and their properties) into the 107 information that is used by Constrained SPF for the purpose of path 108 computation, and by GMPLS signaling. This grouping/mapping must be 109 done consistently at both ends of the link. LMP [LMP] could be used 110 to check/verify this consistency. 112 Depending on the nature of resources that form a particular TE link, 113 for the purpose of GMPLS signaling in some cases the combination of 114 is sufficient to unambiguously identify 115 the appropriate resource used by an LSP. In other cases, the 116 combination of is not sufficient - such 117 cases are handled by using the link bundling construct [LINK-BUNDLE] 118 that allows to identify the resource by . 121 Some of the properties of a TE link may be configured on the 122 advertising Label Switching Router (LSR), others which may be 123 obtained from other LSRs by means of some protocol, and yet others 124 which may be deduced from the component(s) of the TE link. 126 A TE link between a pair of LSRs doesn't imply the existence of a 127 routing adjacency (e.g., an IGP adjacency) between these LSRs. As we 128 mentioned above, in certain cases a TE link between a pair of LSRs 129 could be advertised even if there is no routing adjacency at all 130 between the LSRs (e.g., when the TE link is a Forwarding Adjacency 131 (see [LSP-HIER])). 133 A TE link must have some means by which the advertising LSR can know 134 of its liveness (this means may be routing hellos, but is not limited 135 to routing hellos). When an LSR knows that a TE link is up, and can 136 determine the TE link's TE properties, the LSR may then advertise 137 that link to its (regular) neighbors. 139 In this document, we call the interfaces over which regular routing 140 adjacencies are established "control channels". 142 [ISIS-TE] and [OSPF-TE] define the canonical TE properties, and say 143 how to associate TE properties to regular (packet-switched) links. 144 This document extends the set of TE properties, and also says how to 145 associate TE properties with non-packet-switched links such as links 146 between Optical Cross-Connects (OXCs). [LSP-HIER] says how to 147 associate TE properties with links formed by Label Switched Paths. 149 2.1. Requirements for Layer-specific TE Attributes 151 In generalizing TE links to include traditional transport facilities, 152 there are additional factors that influence what information is 153 needed about the TE link. These arise from existing transport layer 154 architecture (e.g., ITU-T Recommendations G.805 and G.806) and 155 associated layer services. Some of these factors are: 157 1. The need for LSPs at a specific adaptation, not just a particular 158 bandwidth. Clients of optical networks obtain connection services 159 for specific adaptations, for example, a VC-3 circuit. This not 160 only implies a particular bandwidth, but how the payload is 161 structured. Thus the VC-3 client would not be satisfied with any 162 LSP that offered other than 48.384 Mbit/s and with the expected 163 structure. The corollary is that path computation should be able 164 to find a route that would give a connection at a specific 165 adaptation. 167 2. Distinguishing variable adaptation. A resource between two OXCs 168 (specifically a G.805 trail) can sometimes support different 169 adaptations at the same time. An example of this is described in 170 section 3.4.8. In this situation, the fact that two adaptations 171 are supported on the same trail is important because the two 172 layers are dependent, and it is important to be able to reflect 173 this layer relationship in routing, especially in view of the 174 relative lack of flexibility of transport layers compared to 175 packet layers. 177 3. Inheritable attributes. When a whole multiplexing hierarchy is 178 supported by a TE link, a lower layer attribute may be applicable 179 to the upper layers. Protection attributes are a good example of 180 this. If an OC-192 link is 1+1 protected (a duplicate OC-192 181 exists for protection), then an OC-3c within that OC-192 (a higher 182 layer) would inherit the same protection property. 184 4. Extensibility of layers. In addition to the existing defined 185 transport layers, new layers and adaptation relationships could 186 come into existence in the future. 188 5. Heterogeneous networks whose OXCs do not all support the same set 189 of layers. In a GMPLS network, not all transport layer network 190 elements are expected to support the same layers. For example, 191 there may be switches capable of only VC-11, VC-12, and VC-3, 192 where as there may be others that can only support VC-3 and VC-4. 193 Even though a network element cannot support a specific layer, it 194 should be able to know if a network element elsewhere in the 195 network can support an adaptation that would enable that 196 unsupported layer to be used. For example, a VC-11 switch could 197 use a VC-3 capable switch if it knew that a VC-11 path could be 198 constructed over a VC-3 link connection. 200 From the factors presented above, development of layer specific GMPLS 201 routing documents should use the following principles for TE-link 202 attributes. 204 1. Separation of attributes. The attributes in a given layer are 205 separated from attributes in another layer. 207 2. Support of inter-layer attributes (e.g., adaptation 208 relationships). Between a client and server layer, a general 209 mechanism for describing the layer relationship exists. For 210 example "4 client links of type X can be supported by this server 211 layer link". Another example is being able to identify when two 212 layers share a common server layer. 214 3. Support for inheritable attributes. Attributes which can be 215 inherited should be identified. 217 4. Layer extensibilty. Attributes should be represented in routing 218 such that future layers can be accommodated. This is much like 219 the notion of the generalized label. 221 5. Explicit attribute scope. For example, it should be clear whether 222 a given attribute applies to a set of links at the same layer. 224 The present document captures general attributes that apply to a 225 single layer network, but doesn't capture inter-layer relationships 226 of attributes. This work is left to a future document. 228 2.2. Excluding data traffic from control channels 230 The control channels between nodes in a GMPLS network, such as OXCs, 231 SDH cross-connects and/or routers, are generally meant for control 232 and administrative traffic. These control channels are advertised 233 into routing as normal links as mentioned in the previous section; 234 this allows the routing of (for example) RSVP messages and telnet 235 sessions. However, if routers on the edge of the optical domain 236 attempt to forward data traffic over these channels, the channel 237 capacity will quickly be exhausted. 239 In order to keep these control channels from being advertised into 240 the user data plane a variety of techniques can be used. 242 If one assumes that data traffic is sent to BGP destinations, and 243 control traffic to IGP destinations, then one can exclude data 244 traffic from the control plane by restricting BGP nexthop resolution. 245 (It is assumed that OXCs are not BGP speakers.) Suppose that a 246 router R is attempting to install a route to a BGP destination D. R 247 looks up the BGP nexthop for D in its IGP's routing table. Say R 248 finds that the path to the nexthop is over interface I. R then 249 checks if it has an entry in its Link State database associated with 250 the interface I. If it does, and the link is not packet-switch 251 capable (see [LSP_HIER]), R installs a discard route for destination 252 D. Otherwise, R installs (as usual) a route for destination D with 253 nexthop I. Note that R need only do this check if it has 254 packet-switch incapable links; if all of its links are packet-switch 255 capable, then clearly this check is redundant. 257 In other instances it may be desirable to keep the whole address 258 space of a GMPLS routing plane disjoint from the endpoint addresses 259 in another portion of the GMPLS network. For example, the addresses 260 of a carrier network where the carrier uses GMPLS but does not wish 261 to expose the internals of the addressing or topology. In such a 262 network the control channels are never advertised into the end data 263 network. In this instance, independent mechanisms are used to 264 advertise the data addresses over the carrier network. 266 Other techniques for excluding data traffic from control channels may 267 also be needed. 269 3. GMPLS Routing Enhancements 271 In this section we define the enhancements to the TE properties of 272 GMPLS TE links. Encoding of this information in IS-IS is specified 273 in [GMPLS-ISIS]. Encoding of this information in OSPF is specified 274 in [GMPLS-OSPF]. 276 3.1. Support for unnumbered links 278 An unnumbered link has to be a point-to-point link. An LSR at each 279 end of an unnumbered link assigns an identifier to that link. This 280 identifier is a non-zero 32-bit number that is unique within the 281 scope of the LSR that assigns it. 283 Consider an (unnumbered) link between LSRs A and B. LSR A chooses an 284 idenfitier for that link. So is LSR B. From A's perspective we 285 refer to the identifier that A assigned to the link as the "link 286 local identifier" (or just "local identifier"), and to the identifier 287 that B assigned to the link as the "link remote identifier" (or just 288 "remote identifier"). Likewise, from B's perspective the identifier 289 that B assigned to the link is the local identifier, and the 290 identifier that A assigned to the link is the remote identifier. 292 Support for unnumbered links in routing includes carrying information 293 about the identifiers of that link. Specifically, when an LSR 294 advertises an unnumbered TE link, the advertisement carries both the 295 local and the remote identifiers of the link. If the LSR doesn't 296 know the remote identifier of that link, the LSR should use a value 297 of 0 as the remote identifier. 299 3.2. Link Protection Type 301 The Link Protection Type represents the protection capability that 302 exists for a link. It is desirable to carry this information so that 303 it may be used by the path computation algorithm to set up LSPs with 304 appropriate protection characteristics. This information is 305 organized in a hierarchy where typically the minimum acceptable 306 protection is specified at path instantiation and a path selection 307 technique is used to find a path that satisfies at least the minimum 308 acceptable protection. Protection schemes are presented in order 309 from lowest to highest protection. 311 This document defines the following protection capabilities: 313 Extra Traffic 314 If the link is of type Extra Traffic, it means that the link is 315 protecting another link or links. The LSPs on a link of this type 316 will be lost if any of the links it is protecting fail. 318 Unprotected 319 If the link is of type Unprotected, it means that there is no 320 other link protecting this link. The LSPs on a link of this type 321 will be lost if the link fails. 323 Shared 324 If the link is of type Shared, it means that there are one or more 325 disjoint links of type Extra Traffic that are protecting this 326 link. These Extra Traffic links are shared between one or more 327 links of type Shared. 329 Dedicated 1:1 330 If the link is of type Dedicated 1:1, it means that there is one 331 dedicated disjoint link of type Extra Traffic that is protecting 332 this link. 334 Dedicated 1+1 335 If the link is of type Dedicated 1+1, it means that a dedicated 336 disjoint link is protecting this link. However, the protecting 337 link is not advertised in the link state database and is therefore 338 not available for the routing of LSPs. 340 Enhanced 341 If the link is of type Enhanced, it means that a protection scheme 342 that is more reliable than Dedicated 1+1, e.g., 4 fiber 343 BLSR/MS-SPRING, is being used to protect this link. 345 The Link Protection Type is optional, and if a Link State 346 Advertisement doesn't carry this information, then the Link 347 Protection Type is unknown. 349 3.3. Shared Risk Link Group Information 351 A set of links may constitute a 'shared risk link group' (SRLG) if 352 they share a resource whose failure may affect all links in the set. 353 For example, two fibers in the same conduit would be in the same 354 SRLG. A link may belong to multiple SRLGs. Thus the SRLG 355 Information describes a list of SRLGs that the link belongs to. An 356 SRLG is identified by a 32 bit number that is unique within an IGP 357 domain. The SRLG Information is an unordered list of SRLGs that the 358 link belongs to. 360 The SRLG of a LSP is the union of the SRLGs of the links in the LSP. 361 The SRLG of a bundled link is the union of the SRLGs of all the 362 component links. 364 If an LSR is required to have multiple diversely routed LSPs to 365 another LSR, the path computation should attempt to route the paths 366 so that they do not have any links in common, and such that the path 367 SRLGs are disjoint. 369 The SRLG Information may start with a configured value, in which case 370 it does not change over time, unless reconfigured. 372 The SRLG Information is optional and if a Link State Advertisement 373 doesn't carry the SRLG Information, then it means that SRLG of that 374 link is unknown. 376 3.4. Interface Switching Capability Descriptor 378 In the context of this document we say that a link is connected to a 379 node by an interface. In the context of GMPLS interfaces may have 380 different switching capabilities. For example an interface that 381 connects a given link to a node may not be able to switch individual 382 packets, but it may be able to switch channels within an SDH payload. 383 Interfaces at each end of a link need not have the same switching 384 capabilities. Interfaces on the same node need not have the same 385 switching capabilities. 387 The Interface Switching Capability Descriptor describes switching 388 capability of an interface. For bi-directional links, the switching 389 capabilities of an interface are defined to be the same in either 390 direction. I.e., for data entering the node through that interface 391 and for data leaving the node through that interface. 393 A Link State Advertisement of a link carries the Interface Switching 394 Capability Descriptor(s) only of the near end (the end incumbent on 395 the LSR originating the advertisement). 397 An LSR performing path computation uses the Link State Database to 398 determine whether a link is unidirectional or bidirectional. 400 For a bidirectional link the LSR uses its Link State Database to 401 determine the Interface Switching Capability Descriptor(s) of the 402 far-end of the link, as bidirectional links with different Interface 403 Switching Capabilities at its two ends are allowed. 405 For an unidirectional link it is assumed that the Interface Switching 406 Capability Descriptor at the far-end of the link is the same as at 407 the near-end. Thus, an unidirectional link is required to have the 408 same interface switching capabilities at both ends. This seems a 409 reasonable assumption given that unidirectional links arise only with 410 packet forwarding adjacencies and for these both ends belong to the 411 same level of the PSC hierarchy. 413 This document defines the following Interface Switching Capabilities: 415 Packet-Switch Capable-1 (PSC-1) 416 Packet-Switch Capable-2 (PSC-2) 417 Packet-Switch Capable-3 (PSC-3) 418 Packet-Switch Capable-4 (PSC-4) 419 Layer-2 Switch Capable (L2SC) 420 Time-Division-Multiplex Capable (TDM) 421 Lambda-Switch Capable (LSC) 422 Fiber-Switch Capable (FSC) 424 If there is no Interface Switching Capability Descriptor for an 425 interface, the interface is assumed to be packet-switch capable 426 (PSC-1). 428 Interface Switching Capability Descriptors present a new constraint 429 for LSP path computation. 431 Irrespective of a particular Interface Switching Capability, the 432 Interface Switching Capability Descriptor always includes information 433 about the encoding supported by an interface. The defined encodings 434 are the same as LSP Encoding as defined in [GMPLS-SIG]. 436 An interface may have more than one Interface Switching Capability 437 Descriptor. This is used to handle interfaces that support multiple 438 switching capabilities, for interfaces that have Max LSP Bandwidth 439 values that differ by priority level, and for interfaces that support 440 discrete bandwidths. 442 Depending on a particular Interface Switching Capability, the 443 Interface Switching Capability Descriptor may include additional 444 information, as specified below. 446 3.4.1. Layer-2 Switch Capable 448 If an interface is of type L2SC, it means that the node receiving 449 data over this interface can switch the received frames based on the 450 layer 2 address. For example, an interface associated with a link 451 terminating on an ATM switch would be considered L2SC. 453 3.4.2. Packet-Switch Capable 455 If an interface is of type PSC-1 through PSC-4, it means that the 456 node receiving data over this interface can switch the received data 457 on a packet-by-packet basis, based on the label carried in the "shim" 458 header [RFC3032]. The various levels of PSC establish a hierarchy of 459 LSPs tunneled within LSPs. 461 For Packet-Switch Capable interfaces the additional information 462 includes Maximum LSP Bandwidth, Minimum LSP Bandwidth, and interface 463 MTU. 465 For a simple (unbundled) link, the Maximum LSP Bandwidth at priority 466 p is defined to be the smaller of the unreserved bandwidth at 467 priority p and a "Maximum LSP Size" parameter which is locally 468 configured on the link, and whose default value is equal to the Max 469 Link Bandwidth. Maximum LSP Bandwidth for a bundled link is defined 470 in [LINK-BUNDLE]. 472 The Maximum LSP Bandwidth takes the place of the Maximum Link 473 Bandwidth ([ISIS-TE], [OSPF-TE]). However, while Maximum Link 474 Bandwidth is a single fixed value (usually simply the link capacity), 475 Maximum LSP Bandwidth is carried per priority, and may vary as LSPs 476 are set up and torn down. 478 Although Maximum Link Bandwidth is to be deprecated, for backward 479 compatibility, one MAY set the Maximum Link Bandwidth to the Maximum 480 LSP Bandwidth at priority 7. 482 The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP 483 could reserve. 485 Typical values for the Minimum LSP Bandwidth and for the Maximum LSP 486 Bandwidth are enumerated in [GMPLS-SIG]. 488 On a PSC interface that supports Standard SDH encoding, an LSP at 489 priority p could reserve any bandwidth allowed by the branch of the 490 SDH hierarchy, with the leaf and the root of the branch being defined 491 by the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at 492 priority p. 494 On a PSC interface that supports Arbitrary SDH encoding, an LSP at 495 priority p could reserve any bandwidth between the Minimum LSP 496 Bandwidth and the Maximum LSP Bandwidth at priority p, provided that 497 the bandwidth reserved by the LSP is a multiple of the Minimum LSP 498 Bandwidth. 500 The Interface MTU is the maximum size of a packet that can be 501 transmitted on this interface without being fragmented. 503 3.4.3. Time-Division Multiplex Capable 505 If an interface is of type TDM, it means that the node receiving data 506 over this interface can multiplex or demultiplex channels within an 507 SDH payload. 509 For Time-Division Multiplex Capable interfaces the additional 510 information includes Maximum LSP Bandwidth, the information on 511 whether the interface supports Standard or Arbitrary SDH, and Minimum 512 LSP Bandwidth. 514 For a simple (unbundled) link the Maximum LSP Bandwidth at priority p 515 is defined as the maximum bandwidth an LSP at priority p could 516 reserve. Maximum LSP Bandwidth for a bundled link is defined in 517 [LINK-BUNDLE]. 519 The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP 520 could reserve. 522 Typical values for the Minimum LSP Bandwidth and for the Maximum LSP 523 Bandwidth are enumerated in [GMPLS-SIG]. 525 On an interface having Standard SDH multiplexing, an LSP at priority 526 p could reserve any bandwidth allowed by the branch of the SDH 527 hierarchy, with the leaf and the root of the branch being defined by 528 the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority 529 p. 531 On an interface having Arbitrary SDH multiplexing, an LSP at priority 532 p could reserve any bandwidth between the Minimum LSP Bandwidth and 533 the Maximum LSP Bandwidth at priority p, provided that the bandwidth 534 reserved by the LSP is a multiple of the Minimum LSP Bandwidth. 536 Interface Switching Capability Descriptor for the interfaces that 537 support sub VC-3 may include additional information. The nature and 538 the encoding of such information is outside the scope of this 539 document. 541 A way to handle the case where an interface supports multiple 542 branches of the SDH multiplexing hierarchy, multiple Interface 543 Switching Capability Descriptors would be advertised, one per branch. 544 For example, if an interface supports VC-11 and VC-12 (which are not 545 part of same branch of SDH multiplexing tree), then it could 546 advertise two descriptors, one for each one. 548 3.4.4. Lambda-Switch Capable 550 If an interface is of type LSC, it means that the node receiving data 551 over this interface can recognize and switch individual lambdas 552 within the interface. An interface that allows only one lambda per 553 interface, and switches just that lambda is of type LSC. 555 The additional information includes Reservable Bandwidth per 556 priority, which specifies the bandwidth of an LSP that could be 557 supported by the interface at a given priority number. 559 A way to handle the case of multiple data rates or multiple encodings 560 within a single TE Link, multiple Interface Switching Capability 561 Descriptors would be advertised, one per supported data rate and 562 encoding combination. For example, an LSC interface could support 563 the establishment of LSC LSPs at both STM-16 and STM-64 data rates. 565 3.4.5. Fiber-Switch Capable 567 If an interface is of type FSC, it means that the node receiving data 568 over this interface can switch the entire contents to another 569 interface (without distinguishing lambdas, channels or packets). 570 I.e., an interface of type FSC switches at the granularity of an 571 entire interface, and can not extract individual lambdas within the 572 interface. An interface of type FSC can not restrict itself to just 573 one lambda. 575 3.4.6. Multiple Switching Capabilities per interface 577 An interface that connects a link to an LSR may support not one, but 578 several Interface Switching Capabilities. For example, consider a 579 fiber link carrying a set of lambdas that terminates on an LSR 580 interface that could either cross-connect one of these lambdas to 581 some other outgoing optical channel, or could terminate the lamdba, 582 and extract (demultiplex) data from that lambda using TDM, and then 583 cross-connect these TDM channels to some outgoing TDM channels. To 584 support this a Link State Advertisement may carry a list of Interface 585 Switching Capabilities Descriptors. 587 3.4.7. Interface Switching Capabilities and Labels 589 Depicting a TE link as a tuple that contains Interface Switching 590 Capabilities at both ends of the link, some examples links may be: 592 [PSC, PSC] - a link between two packet LSRs 593 [TDM, TDM] - a link between two Digital Cross Connects 594 [LSC, LSC] - a link between two OXCs 595 [PSC, TDM] - a link between a packet LSR and a Digital Cross Connect 596 [PSC, LSC] - a link between a packet LSR and an OXC 597 [TDM, LSC] - a link between a Digital Cross Connect and an OXC 599 Both ends of a given TE link has to use the same way of carrying 600 label information over that link. Carrying label information on a 601 given TE link depends on the Interface Switching Capability at both 602 ends of the link, and is determined as follows: 604 [PSC, PSC] - label is carried in the "shim" header [RFC3032] 605 [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] 606 [LSC, LSC] - label represents a lambda 608 [FSC, FSC] - label represents a port on an OXC 609 [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] 610 [PSC, LSC] - label represents a lambda 611 [PSC, FSC] - label represents a port 612 [TDM, LSC] - label represents a lambda 613 [TDM, FSC] - label represents a port 614 [LSC, FSC] - label represents a port 616 3.4.8. Other issues 618 It is possible that Interface Switching Capability Descriptor will 619 change over time, reflecting the allocation/deallocation of LSPs. 620 For example, assume that VC-3, VC-4, VC-4-4c, VC-4-16c and VC-4-64c 621 LSPs can be established on a STM-64 interface whose Encoding Type is 622 SDH. Thus, initially in the Interface Switching Capability 623 Descriptor the Minimum LSP Bandwidth is set to VC-3, and Maximum LSP 624 Bandwidth is set to STM-64 for all priorities. As soon as an LSP of 625 VC-3 size at priority 1 is established on the interface, it is no 626 longer capable of VC-4-64c for all but LSPs at priority 0. 627 Therefore, the node advertises a modified Interface Switching 628 Capability Descriptor indicating that the Maximum LSP Bandwidth is no 629 longer STM-64, but STM-16 for all but priority 0 (at priority 0 the 630 Maximum LSP Bandwidth is still STM-64). If subsequently there is 631 another VC-3 LSP, there is no change in the Interface Switching 632 Capability Descriptor. The Descriptor remains the same until the 633 node can no longer establish a VC-4-16c LSP over the interface (which 634 means that at this point more than 144 time slots are taken by LSPs 635 on the interface). Once this happened, the Descriptor is modified 636 again, and the modified Descriptor is advertised to other nodes. 638 3.5. Bandwidth Encoding 640 Encoding in IEEE floating point format of the discrete values that 641 could be used to identify Unreserved bandwidth, Maximum LSP bandwidth 642 and Minimum LSP bandwidth is described in Section 3.1.2 of 643 [GMPLS-SIG]. 645 4. Examples of Interface Switching Capability Descriptor 647 4.1. STM-16 POS Interface on a LSR 649 Interface Switching Capability Descriptor: 650 Interface Switching Capability = PSC-1 651 Encoding = SDH 652 Max LSP Bandwidth[p] = 2.5 Gbps, 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 4.2. GigE Packet Interface on a LSR 659 Interface Switching Capability Descriptor: 660 Interface Switching Capability = PSC-1 661 Encoding = Ethernet 802.3 662 Max LSP Bandwidth[p] = 1.0 Gbps, for all p 664 If multiple links with such interfaces at both ends were to be 665 advertised as one TE link, link bundling techniques should be used. 667 4.3. STM-64 SDH Interface on a Digital Cross Connect with Standard SDH 669 Consider a branch of SDH multiplexing tree : VC-3, VC-4, VC-4-4c, 670 VC-4-16c, VC-4-64c. If it is possible to establish all these 671 connections on a STM-64 interface, the Interface Switching Capability 672 Descriptor of that interface can be advertised as follows: 674 Interface Switching Capability Descriptor: 675 Interface Switching Capability = TDM [Standard SDH] 676 Encoding = SDH 677 Min LSP Bandwidth = VC-3 678 Max LSP Bandwidth[p] = STM-64, for all p 680 If multiple links with such interfaces at both ends were to be 681 advertised as one TE link, link bundling techniques should be used. 683 4.4. STM-64 SDH Interface on a Digital Cross Connect with two types of 684 SDH multiplexing hierarchy supported 686 Interface Switching Capability Descriptor 1: 687 Interface Switching Capability = TDM [Standard SDH] 688 Encoding = SDH 689 Min LSP Bandwidth = VC-3 690 Max LSP Bandwidth[p] = STM-64, for all p 692 Interface Switching Capability Descriptor 2: 693 Interface Switching Capability = TDM [Arbitrary SDH] 694 Encoding = SDH 695 Min LSP Bandwidth = VC-4 696 Max LSP Bandwidth[p] = STM-64, for all p 698 If multiple links with such interfaces at both ends were to be 699 advertised as one TE link, link bundling techniques should be used. 701 4.5. Interface on an opaque OXC (SDH framed) with support for one lambda 702 per port/interface 704 An "opaque OXC" is considered operationally an OXC, as the whole 705 lambda (carrying the SDH line) is switched transparently without 706 further multiplexing/demultiplexing, and either none of the SDH 707 overhead bytes, or at least the important ones are not changed. 709 An interface on an opaque OXC handles a single wavelength, and 710 cannot switch multiple wavelengths as a whole. Thus, an interface on 711 an opaque OXC is always LSC, and not FSC, irrespective of whether 712 there is DWDM external to it. 714 Note that if there is external DWDM, then the framing understood by 715 the DWDM must be same as that understood by the OXC. 717 A TE link is a group of one or more interfaces on an OXC. All 718 interfaces on a given OXC are required to have identifiers unique to 719 that OXC, and these identifiers are used as labels (see 3.2.1.1 of 720 [GMPLS-SIG]). 722 The following is an example of an interface switching capability 723 descriptor on an SDH framed opaque OXC: 725 Interface Switching Capability Descriptor: 726 Interface Switching Capability = LSC 727 Encoding = SDH 728 Reservable Bandwidth = Determined by SDH Framer (say STM-64) 730 4.6. Interface on a transparent OXC (PXC) with external DWDM that 731 understands SDH framing 733 This example assumes that DWDM and PXC are connected in such a way 734 that each interface (port) on the PXC handles just a single 735 wavelength. Thus, even if in principle an interface on the PXC could 736 switch multiple wavelengths as a whole, in this particular case an 737 interface on the PXC is considered LSC, and not FSC. 739 _______ 740 | | 741 /|___| | 742 | |___| PXC | 743 ========| |___| | 744 | |___| | 745 \| |_______| 746 DWDM 747 (SDH framed) 749 A TE link is a group of one or more interfaces on the PXC. All 750 interfaces on a given PXC are required to have identifiers unique to 751 that PXC, and these identifiers are used as labels (see 3.2.1.1 of 752 [GMPLS-SIG]). 754 The following is an example of an interface switching capability 755 descriptor on a transparent OXC (PXC) with external DWDM that 756 understands SDH framing: 758 Interface Switching Capability Descriptor: 759 Interface Switching Capability = LSC 760 Encoding = SDH (comes from DWDM) 761 Reservable Bandwidth = Determined by DWDM (say STM-64) 763 4.7. Interface on a transparent OXC (PXC) with external DWDM that is 764 transparent to bit-rate and framing 766 This example assumes that DWDM and PXC are connected in such a way 767 that each interface (port) on the PXC handles just a single 768 wavelength. Thus, even if in principle an interface on the PXC could 769 switch multiple wavelengths as a whole, in this particular case an 770 interface on the PXC is considered LSC, and not FSC. 772 _______ 773 | | 774 /|___| | 775 | |___| PXC | 776 ========| |___| | 777 | |___| | 778 \| |_______| 779 DWDM 780 (transparent to bit-rate and framing) 782 A TE link is a group of one or more interfaces on the PXC. All 783 interfaces on a given PXC are required to have identifiers unique to 784 that PXC, and these identifiers are used as labels (see 3.2.1.1 of 785 [GMPLS-SIG]). 787 The following is an example of an interface switching capability 788 descriptor on a transparent OXC (PXC) with external DWDM that is 789 transparent to bit-rate and framing: 791 Interface Switching Capability Descriptor: 792 Interface Switching Capability = LSC 793 Encoding = Lambda (photonic) 794 Reservable Bandwidth = Determined by optical technology limits 796 4.8. Interface on a PXC with no external DWDM 798 The absence of DWDM in between two PXCs, implies that an interface is 799 not limited to one wavelength. Thus, the interface is advertised as 800 FSC. 802 A TE link is a group of one or more interfaces on the PXC. All 803 interfaces on a given PXC are required to have identifiers unique to 804 that PXC, and these identifiers are used as port labels (see 3.2.1.1 805 of [GMPLS-SIG]). 807 Interface Switching Capability Descriptor: 808 Interface Switching Capability = FSC 809 Encoding = Lambda (photonic) 810 Reservable Bandwidth = Determined by optical technology limits 812 Note that this example assumes that the PXC does not restrict each 813 port to carry only one wavelength. 815 4.9. Interface on a OXC with internal DWDM that understands SDH framing 817 This example assumes that DWDM and OXC are connected in such a way 818 that each interface on the OXC handles multiple wavelengths 819 individually. In this case an interface on the OXC is considered 820 LSC, and not FSC. 822 _______ 823 | | 824 /|| ||\ 825 | || OXC || | 826 ========| || || |==== 827 | || || | 828 \||_______||/ 829 DWDM 830 (SDH framed) 832 A TE link is a group of one or more of the interfaces on the OXC. 833 All lambdas associated with a particular interface are required to 834 have identifiers unique to that interface, and these identifiers are 835 used as labels (see 3.2.1.1 of [GMPLS-SIG]). 837 The following is an example of an interface switching capability 838 descriptor on an OXC with internal DWDM that understands SDH framing 839 and supports discrete bandwidths: 841 Interface Switching Capability Descriptor: 842 Interface Switching Capability = LSC 843 Encoding = SDH (comes from DWDM) 844 Max LSP Bandwidth = Determined by DWDM (say STM-16) 846 Interface Switching Capability = LSC 847 Encoding = SDH (comes from DWDM) 848 Max LSP Bandwidth = Determined by DWDM (say STM-64) 850 4.10. Interface on a OXC with internal DWDM that is transparent to 851 bit-rate and framing 853 This example assumes that DWDM and OXC are connected in such a way 854 that each interface on the OXC handles multiple wavelengths 855 individually. In this case an interface on the OXC is considered 856 LSC, and not FSC. 858 _______ 859 | | 860 /|| ||\ 861 | || OXC || | 862 ========| || || |==== 863 | || || | 864 \||_______||/ 865 DWDM 866 (transparent to bit-rate and framing) 868 A TE link is a group of one or more of the interfaces on the OXC. 869 All lambdas associated with a particular interface are required to 870 have identifiers unique to that interface, and these identifiers are 871 used as labels (see 3.2.1.1 of [GMPLS-SIG]). 873 The following is an example of an interface switching capability 874 descriptor on an OXC with internal DWDM that is transparent to 875 bit-rate and framing: 877 Interface Switching Capability Descriptor: 878 Interface Switching Capability = LSC 879 Encoding = Lambda (photonic) 880 Max LSP Bandwidth = Determined by optical technology limits 882 5. Example of interfaces that support multiple switching capabilities 884 There can be many combinations possible, some are described below. 886 5.1. Interface on a PXC+TDM device with external DWDM 888 As discussed earlier, the presence of the external DWDM limits that 889 only one wavelength be on a port of the PXC. On such a port, the 890 attached PXC+TDM device can do one of the following. The wavelength 891 may be cross-connected by the PXC element to other out-bound optical 892 channel, or the wavelength may be terminated as an SDH interface and 893 SDH channels switched. 895 From a GMPLS perspective the PXC+TDM functionality is treated as a 896 single interface. The interface is described using two Interface 897 descriptors, one for the LSC and another for the TDM, with 898 appropriate parameters. For example, 900 Interface Switching Capability Descriptor: 901 Interface Switching Capability = LSC 902 Encoding = SDH (comes from WDM) 903 Reservable Bandwidth = STM-64 905 and 907 Interface Switching Capability Descriptor: 908 Interface Switching Capability = TDM [Standard SDH] 909 Encoding = SDH 910 Min LSP Bandwidth = VC-3 911 Max LSP Bandwidth[p] = STM-64, for all p 913 5.2. Interface on an opaque OXC+TDM device with external DWDM 915 An interface on an "opaque OXC+TDM" device would also be advertised 916 as LSC+TDM much the same way as the previous case. 918 5.3. Interface on a PXC+LSR device with external DWDM 920 As discussed earlier, the presence of the external DWDM limits that 921 only one wavelength be on a port of the PXC. On such a port, the 922 attached PXC+LSR device can do one of the following. The wavelength 923 may be cross-connected by the PXC element to other out-bound optical 924 channel, or the wavelength may be terminated as a Packet interface 925 and packets switched. 927 From a GMPLS perspective the PXC+LSR functionality is treated as a 928 single interface. The interface is described using two Interface 929 descriptors, one for the LSC and another for the PSC, with 930 appropriate parameters. For example, 932 Interface Switching Capability Descriptor: 933 Interface Switching Capability = LSC 934 Encoding = SDH (comes from WDM) 935 Reservable Bandwidth = STM-64 937 and 939 Interface Switching Capability Descriptor: 940 Interface Switching Capability = PSC-1 941 Encoding = SDH 942 Max LSP Bandwidth[p] = 10 Gbps, for all p 944 5.4. Interface on a TDM+LSR device 946 On a TDM+LSR device that offers a channelized SDH interface the 947 following may be possible: 949 - A subset of the SDH channels may be uncommitted. That is, they 950 are not currently in use and hence are available for allocation. 952 - A second subset of channels may already be committed for transit 953 purposes. That is, they are already cross-connected by the SDH 954 cross connect function to other out-bound channels and thus are 955 not immediately available for allocation. 957 - Another subset of channels could be in use as terminal channels. 958 That is, they are already allocated by terminate on a packet 959 interface and packets switched. 961 From a GMPLS perspective the TDM+PSC functionality is treated as a 962 single interface. The interface is described using two Interface 963 descriptors, one for the TDM and another for the PSC, with 964 appropriate parameters. For example, 966 Interface Switching Capability Descriptor: 967 Interface Switching Capability = TDM [Standard SDH] 968 Encoding = SDH 969 Min LSP Bandwidth = VC-3 970 Max LSP Bandwidth[p] = STM-64, for all p 972 and 974 Interface Switching Capability Descriptor: 975 Interface Switching Capability = PSC-1 976 Encoding = SDH 977 Max LSP Bandwidth[p] = 10 Gbps, for all p 979 6. Normative References 981 [GMPLS-OSPF] Kompella, K., and Rekhter, Y. (Editors), "OSPF 982 Extensions in Support of Generalized MPLS", (work in progress) 984 [GMPLS-SIG] Berger, L. (Editor), "Generalized Multi-Protocol Label 985 Switching (GMPLS) Signaling Functional Description", RFC 3471, 986 January 2003 988 [GMPLS-SONET-SDH] Mannie, E., and Papadimitriou, D. (Editors), 989 "Generalized Multi-Protocol Label Switching Extensions for SONET 990 and SDH Control", [RFC Ed Queue] 992 [LINK-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link 993 Bundling in MPLS Traffic Engineering", [RFC Ed Queue] 995 [LMP] Lang, J. (Editor), "Link Management Protocol (LMP)", (work in 996 progress) 998 [LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with 999 Generalized MPLS TE", [RFC Ed Queue] 1001 [OSPF-TE] Katz, D., Kompella, K. and Yeung, D., "Traffic Engineering 1002 (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. 1004 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1005 Requirement Levels", BCP 14, RFC 2119, March 1997. 1007 [RFC3032] Rosen, E., et al, "MPLS Label Stack Encoding", RFC 3032, 1008 January 2001. 1010 7. Informative References 1012 [GMPLS-ISIS] Kompella, K., Rekhter, Y. (Editors), "IS-IS Extensions 1013 in Support of Generalized MPLS", (work in progress) 1015 [ISIS-TE] Smit, H., Li, T., "IS-IS Extensions for Traffic 1016 Engineering", (work in progress) 1018 8. Security Considerations 1020 The routing extensions proposed in this document do not raise any new 1021 security concerns. 1023 9. Acknowledgements 1025 The authors would like to thank Suresh Katukam, Jonathan Lang, 1026 Zhi-Wei Lin, and Quaizar Vohra for their comments and contributions 1027 to the document. Thanks too to Stephen Shew for the text regarding 1028 "Representing TE Link Capabilities". 1030 10. Contributors 1032 Ayan Banerjee 1033 Calient Networks 1034 5853 Rue Ferrari 1035 San Jose, CA 95138 1036 Phone: +1.408.972.3645 1037 Email: abanerjee@calient.net 1039 John Drake 1040 Calient Networks 1041 5853 Rue Ferrari 1042 San Jose, CA 95138 1043 Phone: (408) 972-3720 1044 Email: jdrake@calient.net 1046 Greg Bernstein 1047 Ciena Corporation 1048 10480 Ridgeview Court 1049 Cupertino, CA 94014 1050 Phone: (408) 366-4713 1051 Email: greg@ciena.com 1053 Don Fedyk 1054 Nortel Networks Corp. 1055 600 Technology Park Drive 1056 Billerica, MA 01821 1057 Phone: +1-978-288-4506 1058 Email: dwfedyk@nortelnetworks.com 1060 Eric Mannie 1061 Libre Exaministe 1062 Email: eric_mannie@hotmail.com 1063 Debanjan Saha 1064 Tellium Optical Systems 1065 2 Crescent Place 1066 P.O. Box 901 1067 Ocean Port, NJ 07757 1068 Phone: (732) 923-4264 1069 Email: dsaha@tellium.com 1071 Vishal Sharma 1072 Metanoia, Inc. 1073 335 Elan Village Lane, Unit 203 1074 San Jose, CA 95134-2539 1075 Phone: +1 408-943-1794 1076 Email: v.sharma@ieee.org 1078 Debashis Basak 1079 AcceLight Networks, 1080 70 Abele Rd, Bldg 1200 1081 Bridgeville PA 15017 1082 Email: dbasak@accelight.com 1084 Lou Berger 1085 Movaz Networks, Inc. 1086 7926 Jones Branch Drive 1087 Suite 615 1088 McLean VA, 22102 1089 Email: lberger@movaz.com 1091 11. Authors' Information 1093 Kireeti Kompella 1094 Juniper Networks, Inc. 1095 1194 N. Mathilda Ave 1096 Sunnyvale, CA 94089 1097 Email: kireeti@juniper.net 1099 Yakov Rekhter 1100 Juniper Networks, Inc. 1101 1194 N. Mathilda Ave 1102 Sunnyvale, CA 94089 1103 Email: yakov@juniper.net 1105 Intellectual Property Rights Notices 1107 The IETF takes no position regarding the validity or scope of any 1108 intellectual property or other rights that might be claimed to 1109 pertain to the implementation or use of the technology described in 1110 this document or the extent to which any license under such rights 1111 might or might not be available; neither does it represent that it 1112 has made any effort to identify any such rights. Information on the 1113 IETF's procedures with respect to rights in standards-track and 1114 standards-related documentation can be found in BCP-11. Copies of 1115 claims of rights made available for publication and any assurances of 1116 licenses to be made available, or the result of an attempt made to 1117 obtain a general license or permission for the use of such 1118 proprietary rights by implementors or users of this specification can 1119 be obtained from the IETF Secretariat. 1121 The IETF invites any interested party to bring to its attention any 1122 copyrights, patents or patent applications, or other proprietary 1123 rights which may cover technology that may be required to practice 1124 this standard. Please address the information to the IETF Executive 1125 Director. 1127 Full Copyright Statement 1129 Copyright (C) The Internet Society (2003). All Rights Reserved. 1131 This document and translations of it may be copied and furnished to 1132 others, and derivative works that comment on or otherwise explain it 1133 or assist in its implementation may be prepared, copied, published 1134 and distributed, in whole or in part, without restriction of any 1135 kind, provided that the above copyright notice and this paragraph are 1136 included on all such copies and derivative works. However, this 1137 document itself may not be modified in any way, such as by removing 1138 the copyright notice or references to the Internet Society or other 1139 Internet organizations, except as needed for the purpose of 1140 developing Internet standards in which case the procedures for 1141 copyrights defined in the Internet Standards process must be 1142 followed, or as required to translate it into languages other than 1143 English. 1145 The limited permissions granted above are perpetual and will not be 1146 revoked by the Internet Society or its successors or assigns. 1148 This document and the information contained herein is provided on an 1149 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1150 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1151 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1152 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1153 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.