idnits 2.17.1 draft-many-ccamp-gmpls-routing-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 18 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 192: '...e interface is unidirectional), A MUST...' RFC 2119 keyword, line 195: '...ed to L' by B, A MAY include the Incom...' RFC 2119 keyword, line 353: '...mpatibility, one MAY set the Maximum B...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 536 has weird spacing: '...terface on an...' == Line 538 has weird spacing: '...terface with ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '3' is mentioned on line 69, but not defined == Missing Reference: 'LSP-HIER' is mentioned on line 117, but not defined == Missing Reference: 'OSFP-TE' is mentioned on line 113, but not defined == Missing Reference: 'LINK-BUNLDE' is mentioned on line 119, but not defined == Missing Reference: 'GMPLS-SIG' is mentioned on line 379, but not defined == Missing Reference: 'Standard SONET' is mentioned on line 656, but not defined == Missing Reference: 'Arbitrary SONET' is mentioned on line 492, but not defined == Unused Reference: '1' is defined on line 707, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 712, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 720, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 724, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 727, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 731, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-awduche-mpls-te-optical-02 -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-02 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISIS-TE') -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-08) exists of draft-ietf-mpls-lsp-hierarchy-01 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-02 -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-05 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISIS-GMPLS' -- Possible downref: Non-RFC (?) normative reference: ref. 'OSPF-GMPLS' == Outdated reference: A later version (-02) exists of draft-ouldbrahim-bgpgmpls-ovpn-01 -- Possible downref: Normative reference to a draft: ref. 'OVPN' Summary: 11 errors (**), 0 flaws (~~), 23 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kompella (Juniper Networks) 3 Internet Draft Y. Rekhter (Juniper Networks) 4 Expiration Date: December 2001 A. Banerjee (Calient Networks) 5 J. Drake (Calient Networks) 6 G. Bernstein (Ciena) 7 D. Fedyk (Nortel Networks) 8 E. Mannie (GTS Network) 9 D. Saha (Tellium) 10 V. Sharma (Tellabs) 11 D. Basak (AcceLight Networks) 13 Routing Extensions in Support of Generalized MPLS 15 draft-many-ccamp-gmpls-routing-00.txt 17 1. Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as ``work in progress.'' 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 2. Abstract 40 This document specifies routing extensions in support of Generalized 41 Multi-Protocol Label Switching (GMPLS). 43 3. Summary for Sub-IP Area 45 3.1. Summary 47 This document specifies routing extensions in support of Generalized 48 Multi-Protocol Label Switching (GMPLS). 50 3.2. Where does it fit in the Picture of the Sub-IP Work 52 This work fits squarely in the CCAMP box. 54 3.3. Why is it Targeted at this WG 56 This draft is targeted at the CCAMP WG, because this draft specifies 57 the extensions to the link state routing protocols in support of 58 GMPLS, and because GMPLS is within the scope of CCAMP WG. 60 3.4. Justification 62 The WG should consider this document as it specifies the extensions 63 to the link state routing protocols in support of GMPLS. 65 4. Introduction 67 This document specifies routing extensions in support of carrying 68 link state information for Generalized Multi-Protocol Label Switching 69 (GMPLS). This document enhances the routing extensions [3] required 70 to support MPLS Traffic Engineering. 72 5. GMPLS TE Links 74 Traditionally, a TE link is advertised as an adjunct to a "regular" 75 link, i.e., a routing adjacency is brought up on the link, and when 76 the link is up, both the regular SPF properties of the link 77 (basically, the SPF metric) and the TE properties of the link are 78 then advertised. 80 GMPLS challenges this notion in three ways. First, links that are 81 not capable of sending and receiving on a packet-by-packet basis may 82 yet have TE properties; however, a routing adjacency cannot be 83 brought up on such links. Second, a Label Switched Path can be 84 advertised as a point-to-point TE link (see [LSP-HIER]); thus, an 85 advertised TE link may be between a pair of nodes that don't have a 86 routing adjacency with each other. Finally, a number of links may be 87 advertised as a single TE link (perhaps for improved scalability), so 88 again, there is no longer a one-to-one association of a regular 89 routing adjacency and a TE link. 91 Thus we have a more general notion of a TE link. A TE link is a 92 "logical" link that has TE properties. The link is logical in a sense 93 that it represents a way to map the information about certain 94 physical resources (and their properties) into the information that 95 is used by Constrained SPF for the purpose of path computation. Some 96 of the properties of a TE link may be configured on the advertising 97 Label Switching Router (LSR), others which may be obtained from other 98 LSRs by means of some protocol, and yet others which may be deduced 99 from the component(s) of the TE link. 101 A TE link between a pair of LSRs doesn't imply the existence of a 102 routing adjacency between these LSRs. 104 A TE link must have some means by which the advertising LSR can know 105 of its liveness (this means may be routing hellos, but is not limited 106 to routing hellos). When an LSR knows that a TE link is up, and can 107 determine the TE link's TE properties, the LSR may then advertise 108 that link to its (regular) neighbors. 110 In this document, we call the interfaces over which regular routing 111 adjacencies are established "control channels". 113 [ISIS-TE] and [OSFP-TE] defines the canonical TE properties, and says 114 how to associate TE properties to regular (packet-switched) links. 115 This document extends the set of TE properties, and also says how to 116 associate TE properties with non-packet-switched links such as links 117 between Optical Cross-Connects (OXCs). [LSP-HIER] says how to 118 associate TE properties with links formed by Label Switched Paths; 119 [LINK-BUNLDE] says how to associate TE properties with a "bundle" of 120 links. 122 5.1. Excluding data traffic from control channels 124 The control channels between nodes in a GMPLS network, such as OXCs, 125 SONET cross-connects and/or routers, are generally meant for control 126 and administrative traffic. These control channels are advertised 127 into routing as normal links as mentioned in the previous section; 128 this allows the routing of (for example) RSVP messages and telnet 129 sessions. However, if routers on the edge of the optical domain 130 attempt to forward data traffic over these channels, the channel 131 capacity will quickly be exhausted. 133 In order to keep these control channels from being advertised into 134 the user data plane a variety of techniques can be used. 136 If one assumes that data traffic is sent to BGP destinations, and 137 control traffic to IGP destinations, then one can exclude data 138 traffic from the control plane by restricting BGP nexthop resolution. 139 (It is assumed that OXCs are not BGP speakers.) Suppose that a 140 router R is attempting to install a route to a BGP destination D. R 141 looks up the BGP nexthop for D in its IGP's routing table. Say R 142 finds that the path to the nexthop is over interface I. R then 143 checks if it has an entry in its Link State database associated with 144 the interface I. If it does, and the link is not packet-switch 145 capable (see [LSP_HIER]), R installs a discard route for destination 146 D. Otherwise, R installs (as usual) a route for destination D with 147 nexthop I. Note that R need only do this check if it has packet- 148 switch incapable links; if all of its links are packet-switch 149 capable, then clearly this check is redundant. 151 In other instances it may be desirable to keep the whole address 152 space of a GMPLS routing plane disjoint from the endpoint addresses 153 in another portion of the GMPLS network. For example, the addresses 154 of a carrier network where the carrier uses GMPLS but does not wish 155 to expose the internals of the addressing or topology. In such a 156 network the control channels are never advertised into the end data 157 network. In this instance, independent mechanisms are used to 158 advertise the data addresses over the carrier network. The Optical 159 VPNs architecture [OVPN] discusses a mechanism for automating the 160 distribution of independent addresses. 162 Other techniques for excluding data traffic from control channels may 163 also be needed. 165 6. GMPLS Routing Enhancements 167 In this section we define the enhancements to the TE properties of 168 GMPLS TE links. Encoding of this information in IS-IS is specified in 169 [ISIS-GMPLS]. Encoding of this information in OSPF is specified in 170 [OSPF-GMPLS]. 172 6.1. Support for unnumbered interfaces 174 Supporting unnumbered interfaces includes carrying the information 175 about the identity of the interfaces. 177 6.1.1. Outgoing Interface Identifier 179 A link from LSR A to LSR B may be assigned an "outgoing interface 180 identifier". This identifier is a non-zero 32-bit number that is 181 assigned by LSR A. This identifier must be unique within the scope of 182 A. 184 6.1.2. Incoming Interface Identifier 186 Suppose there is a link L from A to B. Suppose further that the link 187 L' from B to A that corresponds to the same interface as L has been 188 assigned an outgoing interface identifier by B. The "incoming 189 interface identifier" for L (from A's point of view) is defined as 190 the outgoing interface identifier for L' (from B's point of view). 192 If no such L' exists (e.g., the interface is unidirectional), A MUST 193 NOT advertise an Incoming Interface Identifier. If A knows that such 194 an L' exists, but does not know the outgoing interface identifier 195 assigned to L' by B, A MAY include the Incoming Interface Identifier 196 with a value of 0. 198 6.2. Link Protection Type 200 The Link Protection Type represents the protection capability that 201 exists for a link. It is desirable to carry this information so that 202 it may be used by the path computation algorithm to set up LSPs with 203 appropriate protection characteristics. This information is organized 204 in a hierarchy where typically the minimum acceptable protection is 205 specified at path instantiation and a path selection technique is 206 used to find a path that satisfies at least the minimum acceptable 207 protection. Protection schemes are presented in order from lowest to 208 highest protection. 210 This document defines the following protection capabilities: 212 Extra Traffic 213 If the link is of type Extra Traffic, it means that the link is 214 protecting another link or links. The LSPs on a link of this type 215 will be lost if any of the links it is protecting fail. 217 Unprotected 218 If the link is of type Unprotected, it means that there is no 219 other link protecting this link. The LSPs on a link of this type 220 will be lost if the link fails. 222 Shared 223 If the link is of type Shared, it means that there are one or more 224 disjoint links of type Extra Traffic that are protecting this 225 link. These Extra Traffic links are shared between one or more 226 links of type Shared. 228 Dedicated 1:1 229 If the link is of type Dedicated 1:1, it means that there is one 230 dedicated disjoint link of type Extra Traffic that is protecting 231 this link. 233 Dedicated 1+1 234 If the link is of type Dedicated 1+1, it means that a dedicated 235 disjoint link is protecting this link. However, the protecting 236 link is not advertised in the link state database and is therefore 237 not available for the routing of LSPs. 239 Enhanced 240 If the link is of type Enhanced, it means that a protection scheme 241 that is more reliable than Dedicated 1+1, e.g., 4 fiber BLSR/MS- 242 SPRING, is being used to protect this link. 244 The Link Protection Type is optional, and if an LSA doesn't carry 245 this information, then the Link Protection Type is unknown. 247 6.3. Shared Risk Link Group Information 249 A set of links may constitute a 'shared risk link group' (SRLG) if 250 they share a resource whose failure may affect all links in the set. 251 For example, two fibers in the same conduit would be in the same 252 SRLG. A link may belong to multiple SRLGs. Thus the SRLG 253 Information describes a list of SRLGs that the link belongs to. An 254 SRLG is identified by a 32 bit number that is unique within an IGP 255 domain. The SRLG Information is an unordered list of SRLGs that the 256 link belongs to. 258 The SRLG of a LSP is the union of the SRLGs of the links in the LSP. 259 The SRLG of a bundled link is the union of the SRLGs of all the 260 component links. 262 If an LSR is required to have multiple diversely routed LSPs to 263 another LSR, the path computation should attempt to route the paths 264 so that they do not have any links in common, and such that the path 265 SRLGs are disjoint. 267 The SRLG Information starts with a configured value and does not 268 change over time, unless manually reconfigured. The SRLG Information 269 is optional and if an LSA doesn't carry the SRLG Information, then it 270 means that SRLG of that link is unknown. 272 6.4. Interface Switching Capability Descriptor 274 In the context of this document we say that a link is connected to a 275 node by an interface. In the context of GMPLS interfaces may have 276 different switching capabilities. For example an interface that 277 connects a given link to a node may not be able to switch individual 278 packets, but it may be able to switch channels within a SONET 279 payload. Interfaces at each end of a link need not have the same 280 switching capabilities. Interfaces on the same node need not have 281 the same switching capabilities. 283 The Interface Switching Capability Descriptor describes switching 284 capability of an interface. The switching capabilities of an 285 interface are defined to be the same in either direction. I.e., for 286 data entering the node through that interface and for data leaving 287 the node through that interface. 289 For a bidirectional link, each LSA carries just the Interface 290 Switching Capability Descriptor of the interface that connects the 291 link to the LSR that originates the LSA. For a unidirectional link 292 each LSA should carry the Interface Switching Capability Descriptor 293 for interfaces at both end of the link. 295 This document defines the following Interface Switching Capabilities: 297 Packet-Switch Capable-1 (PSC-1) 298 Packet-Switch Capable-2 (PSC-2) 299 Packet-Switch Capable-3 (PSC-3) 300 Packet-Switch Capable-4 (PSC-4) 301 Layer-2 Switch Capable (L2SC) 302 Time-Division-Multiplex Capable (TDM) 303 Lambda-Switch Capable (LSC) 304 Fiber-Switch Capable (FSC) 305 If there is no Interface Switching Capability Descriptor for an 306 interface, the interface is assumed to be packet-switch capable 307 (PSC-1). 309 Interface Switching Capability Descriptors present a new constraint 310 for LSP path computation. 312 Irrespective of a particular Interface Switching Capability, the 313 Interface Switching Capability Descriptor always includes information 314 about the encoding supported by an interface. The defined encodings 315 are the same as LSP Encoding as defined in [GMPLS-SIG]. 317 Depending on a particular Interface Switching Capability, the 318 Interface Switching Capability Descriptor may include additional 319 information, as specified below. 321 6.4.1. Layer-2 Switch Capable 323 If an interface is of type L2SC, it means that the node receiving 324 data over this interface can switch the received frames based on the 325 layer 2 address. For example, an interface associated with a link 326 terminating on an ATM switch would be considered L2SC. 328 6.4.2. Packet-Switch Capable 330 If an interface is of type PSC-1 through PSC-4, it means that the 331 node receiving data over this interface can switch the received data 332 on a packet-by-packet basis. The various levels of PSC establish a 333 hierarchy of LSPs tunneled within LSPs. 335 For Packet-Switch Capable interfaces the additional information 336 includes Maximum LSP Bandwidth. 338 For a simple (unbundled) link its Maximum LSP Bandwidth at priority p 339 is defined to be the smaller of its unreserved bandwidth at priority 340 p and its Maximum Reservable Bandwidth. 342 The Maximum LSP Bandwidth of a bundled link at priority p is defined 343 to be the maximum of the Maximum LSP Bandwidth at priority p of each 344 component link. 346 The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth 347 ([ISIS-TE], [OSPF-TE]). However, while Maximum Bandwidth is a single 348 fixed value (usually simply the link capacity), Maximum LSP Bandwidth 349 is carried per priority, and may vary as LSPs are set up and torn 350 down. 352 Although Maximum Bandwidth is to be deprecated, for backward 353 compatibility, one MAY set the Maximum Bandwidth to the Maximum LSP 354 Bandwidth at priority 7. 356 6.4.3. Time-Division Multiplex Capable 358 If an interface is of type TDM, it means that the node receiving data 359 over this interface can multiplex or demultiplex channels within a 360 SONET/SDH payload. 362 For Time-Division Multiplex Capable interfaces the additional 363 information includes Maximum LSP Bandwidth, the information on 364 whether the interface supports Standard or Arbitrary SONET/SDH, and 365 Minimum LSP Bandwidth. 367 For a simple (unbundled) link the Maximum LSP Bandwidth at priority p 368 is defined as the maximum bandwidth an LSP at priority p could 369 reserve. 371 The Maximum LSP Bandwidth of a bundled link at priority p is defined 372 to be the maximum of the Maximum LSP Bandwidth at priority p of each 373 component link. 375 The Minimum LSP Bandwidth specifies the minimum bandwith an LSP could 376 reserve. 378 Typical values for the Minimum LSP Bandwidth and for the Maximum LSP 379 Bandwidth are enumerated in [GMPLS-SIG]. 381 On an interface having Standard SONET (or Standard SDH) multiplexing, 382 an LSP at priority p could reserve any bandwidth allowed by the 383 branch of the SONET/SDH hierarchy, with the leaf and the root of the 384 branch being defined by the Minimum LSP Bandwidth and the Maximum LSP 385 Bandwidth at priority p. 387 On an interface having Arbitrary SONET (or Arbitrary SDH) 388 multiplexing, an LSP at priority p could reserve any bandwidth 389 between the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at 390 priority p, provided that the bandwidth reserved by the LSP is a 391 multiple of the Minimum LSP Bandwidth. 393 To handle the case where an interface supports multiple branches of 394 the SONET (or SDH) multiplexing hierarchy, multiple Interface 395 Switching Capability Descriptors would be advertised, one per branch. 396 For example, if an interface supports VT-1.5 and VT-2 (which are not 397 part of same branch of SONET multiplexing tree), then it could 398 advertise two descriptors, one for each one. 400 6.4.4. Lambda-Switch Capable 402 If an interface is of type LSC, it means that the node receiving data 403 over this interface can recognize and switch individual lambdas 404 within the interface. An interface that allows only one lambda per 405 interface, and switches just that lambda is of type LSC. 407 The additional information includes Reservable Bandwidth and 408 priority, which specifies the bandwidth of an LSP that could be 409 supported by the interface, and the (numerically) largest priority 410 number at which the bandwidth could be reserved. Note that the 411 priority needs to be present only when an interface has more than one 412 Interface Switching Capability Descriptor with LSC as the Interface 413 Switching Capability. 415 To handle the case of multiple data rates or multiple encodings 416 within a single TE Link, multiple Interface Switching Capability 417 Descriptors would be advertised, one per supported data rate and 418 encoding combination. For example, an LSC interface could support 419 the establishment of LSC LSPs at both OC-48c and OC-192c data rates. 421 6.4.5. Fiber-Switch Capable 423 If an interface is of type FSC, it means that the node receiving data 424 over this interface can switch the entire contents to another 425 interface (without distinguishing lambdas, channels or packets). 426 I.e., an interface of type FSC switches at the granularity of an 427 entire interface, and can not extract individual lambdas within the 428 interface. An interface of type FSC can not restrict itself to just 429 one lambda. 431 6.4.6. Multiple Switching Capabilities per interface 433 An interface that connects a link to an LSR may support not one, but 434 several Interface Switching Capabilities. For example, consider a 435 fiber link carrying a set of lambdas that terminates on an LSR 436 interface that could either cross-connect one of these lambdas to 437 some other outgoing optical channel, or could terminate the lamdba, 438 and extract (demultiplex) data from that lambda using TDM, and then 439 cross-connect these TDM channels to some outgoing TDM channels. To 440 support this an LSA may carry a list of Interface Switching 441 Capabilities Descriptors. 443 6.4.7. Examples of Interface Switching Capability Descriptor 445 6.4.7.1. STS-48 POS Interface on a LSR 447 Interface Switching Capability Descriptor: 448 Interface Switching Capability = PSC-1 449 Encoding = SONET ANSI T1.105-1995 450 Max LSP Bandwidth[p] = 2.5 Gbps, for all p 452 If multiple links with such interfaces were to be advertised as one 453 TE link, link bundling techniques should be used. 455 6.4.7.2. GigE Packet Interface on a LSR 457 Interface Switching Capability Descriptor: 458 Interface Switching Capability = PSC-1 459 Encoding = Ethernet 802.3 460 Max LSP Bandwidth[p] = 1.0 Gbps, for all p 462 If multiple links with such interfaces were to be advertised as one 463 TE link, link bundling techniques should be used. 465 6.4.7.3. OC-192 SONET Interface on a Digital Cross Connect with Standard 466 SONET 468 Consider a branch of SONET multiplexing tree : VT-1.5, STS-1, STS-3c, 469 STS-12c, STS-48c, STS-192c. If it is possible to establish all these 470 connections on a OC-192 interface, the Interface Multiplexing 471 Capability Descriptor of that interface can be advertised as follows: 473 Interface Switching Capability Descriptor: 474 Interface Switching Capability = TDM [Standard SONET] 475 Encoding = SONET ANSI T1.105-1995 476 Min LSP Bandwidth = VT1.5 477 Max LSP Bandwidth[p] = STS192, for all p 479 If multiple links with such interfaces were to be advertised as one 480 TE link, link bundling techniques should be used. 482 6.4.7.4. OC-192 SONET Interface on a Digital Cross Connect with two 483 types of SONET multiplexing hierarchy supported 485 Interface Switching Capability Descriptor 1: 486 Interface Switching Capability = TDM [Standard SONET] 487 Encoding = SONET ANSI T1.105-1995 488 Min LSP Bandwidth = VT1.5 489 Max LSP Bandwidth[p] = STS192, for all p 491 Interface Switching Capability Descriptor 2: 492 Interface Switching Capability = TDM [Arbitrary SONET] 493 Encoding = SONET ANSI T1.105-1995 494 Min LSP Bandwidth = VT2 495 Max LSP Bandwidth[p] = STS192, for all p 497 If multiple links with such interfaces were to be advertised as one 498 TE link, link bundling techniques should be used. 500 6.4.7.5. Interface on a transparent OXC (PXC) with external DWDM, that 501 understands SONET framing 503 From a GMPLS perspective a combination of PXC and external DWMD is 504 treated as a single unit. 506 _______ 507 | | 508 /|___| | 509 | |___| PXC | 510 =======X| |___| | 511 | |___| | 512 \| |_______| 513 DWDM 514 (SONET framed) 516 The interface at X is advertised as: 518 Interface Switching Capability Descriptor: 519 Interface Switching Capability = LSC 520 Encoding = SONET ANSI T1.105-1995 (comes from DWDM) 521 Reservable Bandwidth = Determined by DWDM (say OC192) 523 If multiple links with such interfaces were to be advertised as one 524 TE link, one way to do this is to use link bundling. Another way to 525 advertise multiple links with such interfaces as one TE link is just 526 to require that all ports on the PXCs have identifiers unique to the 527 PXC (as each interface identifier would act as a label). 529 6.4.7.6. Interface on an opaque OXC (SONET framed) 531 An "opaque OXC" is considered operationally an OXC, as the whole 532 lambda (carrying the SONET line) is switched transparently, that is 533 either none of the SONET overhead bytes are changed or at least the 534 important ones are not changed. 536 An interface on an opaque OXC handles a single wavelength on the 537 fiber. It fits the definition of LSC and not FSC as it cannot switch 538 an interface with multiple wavelengths as a whole. Thus, an 539 interface on an opaque OXC is always LSC, irrespective of whether 540 there is DWDM external to it. Note, if there is external DWDM then 541 the framing understood by the DWDM must be same as that understood by 542 the OXC. 544 The following is an example of a interface switching capability 545 decriptor on a SONET framed opaque OXC: 547 Interface Switching Capability Descriptor: 548 Interface Switching Capability = LSC 549 Encoding = SONET ANSI T1.105-1995 550 Reservable Bandwidth = Determined by SONET Framer (say OC192) 552 If multiple links with such interfaces were to be advertised as one 553 TE link, one way to do this is to use link bundling. Another way to 554 advertise multiple links with such interfaces as one TE link is just 555 to require that all interfaces on the OXCs have identifiers unique to 556 the OXC (as each interface identifier would act as a label). 558 6.4.7.7. Interface on a PXC with no external DWDM 560 The absence of DWDM in between two PXCs, implies that an interface is 561 not limited to one wavelength. Thus, the interface is advertised as 562 FSC. 564 Interface Switching Capability Descriptor 565 Interface Switching Capability = FSC 566 Encoding = Photonic 567 Reservable Bandwidth = Determined by optical technology limits 569 Note that this example assumes that the PXC does not restrict each 570 port to carry only one wavelength. 572 6.4.8. Example of interfaces that support multiple switching 573 capabilities 575 There can be many combinations possible, some are described below. 577 6.4.8.1. Interface on a PXC+TDM device with external DWDM 579 As discussed earlier, the presence of the external DWDM limits that 580 only one wavelength be on a port of the PXC. On such a port, the 581 attached PXC+TDM device can do one of the following. The wavelength 582 may be cross-connected by the PXC element to other out-bound optical 583 channel, or the wavelength may be terminated as a SONET interface and 584 SONET channels switched. 586 From a GMPLS perspective DWDM and the PXC+TDM functionality is 587 treated as a single unit. The interface is described using two 588 Interface descriptors, one for the LSC and another for the TDM, with 589 appropriate parameters. For example, 591 Interface Switching Capability Descriptor: 592 Interface Switching Capability = LSC 593 Encoding = SONET ANSI T1.105-1995 (comes from WDM) 594 Reservable Bandwidth = OC192 596 and 598 Interface Switching Capability Descriptor: 599 Interface Switching Capability = TDM [Standard SONET] 600 Encoding = SONET ANSI T1.105-1995 601 Min LSP Bandwidth = VT1.5 602 Max LSP Bandwidth[p] = STS192, for all p 604 6.4.8.2. Interface on an opaque OXC+LSR device with external DWDM 606 An interface on an "opaque OXC+TDM" device would also be advertised 607 as LSC+TDM much the same way as the previous case. 609 6.4.8.3. Interface on a PXC+LSR device with external DWDM 611 As discussed earlier, the presence of the external DWDM limits that 612 only one wavelength be on a port of the PXC. On such a port, the 613 attached PXC+LSR device can do one of the following. The wavelength 614 may be cross-connected by the PXC element to other out-bound optical 615 channel, or the wavelength may be terminated as a Packet interface 616 and packets switched. 618 From a GMPLS perspective DWDM and the PXC+LSR functionality is 619 treated as a single unit. The interface is described using two 620 Interface descriptors, one for the LSC and another for the PSC, with 621 appropriate parameters. For example, 623 Interface Switching Capability Descriptor: 624 Interface Switching Capability = LSC 625 Encoding = SONET ANSI T1.105-1995 (comes from WDM) 626 Reservable Bandwidth = OC192 628 and 630 Interface Switching Capability Descriptor: 631 Interface Switching Capability = PSC-1 632 Encoding = SONET ANSI T1.105-1995 633 Max LSP Bandwidth[p] = 10 Gbps, for all p 635 6.4.8.4. Interface on a TDM+LSR device 637 On a TDM+LSR device that offers a channelized SONET/SDH interface the 638 following may be possible: 640 - A subset of the SONET/SDH channels may be uncommitted. That is, 641 they are not currently in use and hence are available for 642 allocation. 644 - A second subset of channels may already be committed for transit 645 purposes. That is, they are already cross-connected by the 646 SONET/SDH cross connect function to other out-bound channels and 647 thus are not immediately available for allocation. 649 - Another subset of channels could be in use as terminal channels. 650 That is, they are already allocated by terminate on a packet 651 interface and packets switched. 653 The interface is advertised as TDM+PSC with example descriptors as: 655 Interface Switching Capability Descriptor: 656 Interface Switching Capability = TDM [Standard SONET] 657 Encoding = SONET ANSI T1.105-1995 658 Min LSP Bandwidth = VT1.5 659 Max LSP Bandwidth[p] = STS192, for all p 661 and 663 Interface Switching Capability Descriptor: 665 Interface Switching Capability = PSC-1 666 Encoding = SONET ANSI T1.105-1995 667 Max LSP Bandwidth[p] = 10 Gbps, for all p 669 6.4.9. Other issues 671 It is possible that Interface Switching Capability Descriptor will 672 change over time, reflecting the allocation/deallocation of LSPs. In 673 general, creation/deletion of an LSP on a link doesn't necessarily 674 result in changing the Interface Switching Capability Descriptor of 675 that interface. For example, assume that STS-1, STS-3c, STS-12c, 676 STS-48c and STS-192c LSPs can be established on a OC-192 interface 677 whose Encoding Type is SONET (or to be more precise, SONET ANSI 678 T1.105-1995). Thus, initially in the Interface Multiplexing 679 Capability Descriptor the Minimum LSP Bandwidth is set to STS-1, and 680 Maximum LSP Bandwidth is set to STS-192 for all priorities. As soon 681 as an LSP of STS-1 size at priority 1 is established on the 682 interface, it is no longer capable of STS-192c for all but LSPs at 683 priority 0. Therefore, the node advertises a modified Interface 684 Switching Capability Descriptor indicating that the Maximum LSP 685 Bandwidth is no longer STS-192, but STS-48 for all but priority 0 (at 686 priority 0 the Maximum LSP Bandwidth is still STS-192). If 687 subsequently there is another STS-1 LSP, there is no change in the 688 Interface Switching Capability Descriptor. The Descriptor remains 689 the same until the node can no longer establish a STS-48c LSP over 690 the interface (which means that at this point more than 144 time 691 slots are taken by LSPs on the interface). Once this happened, the 692 Descriptor is modified again, and the modified Descriptor is 693 advertised to other nodes. 695 7. Security Considerations 697 The routing extensions proposed in this document do not raise any new 698 security concerns. 700 8. Acknowledgements 702 The authors would like to thank Suresh Katukam, Jonathan Lang and 703 Quaizar Vohra for their comments on the draft. 705 9. References 707 [1] Awduche, D., Rekhter, Y., Drake, J., Coltun, R., "Multi- Protocol 708 Lambda Switching: Combining MPLS Traffic Engineering Control With 709 Optical Crossconnects", draft-awduche-mpls-te-optical-02.txt (work in 710 progress) 712 [2] Basak, D., Awduche, D., Drake, J., Rekhter, Y., "Multi- protocol 713 Lambda Switching: Issues in Combining MPLS Traffic Engineering 714 Control With Optical Crossconnects", draft-basak-mpls-oxc- 715 issues-01.txt (work in progress) 717 [ISIS-TE] Smit, H., Li, T., "IS-IS Extensions for Traffic 718 Engineering", draft-ietf-isis-traffic-02.txt (work in progress) 720 [4] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in MPLS 721 Traffic Engineering", draft-kompella-mpls-bundle-05.txt (work in 722 progress) 724 [5] Kompella, K., Rekhter, Y., "LSP Hierarchy with MPLS TE", draft- 725 ietf-mpls-lsp-hierarchy-01.txt (work in progress) 727 [6] Generalized MPLS Group, "Generalized MPLS - Signaling Functional 728 Description", draft-ietf-mpls-generalized-signaling-02.txt (work in 729 progress) 731 [7] Lang J., Mitra K., Drake J., Kompella K., Rekhter Y., Berger L., 732 Saha, D., Sandick, H., and Basak D., "Link Management Protocol", 733 draft-ietf-mpls-lmp-02.txt (work in progress) 735 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 736 Extensions to OSPF", draft-katz-yeung-ospf-traffic-05.txt 738 [ISIS-GMPLS] 740 [OSPF-GMPLS] 742 [OVPN] Ould-Brahim, H., Rekhter, Y., Fedyk, D., Ashwood-Smith, P., 743 Rosen, E., Mannie, E., Fang, L., Drake, J., "BGP/GMPLS Optical VPNs", 744 draft-ouldbrahim-bgpgmpls-ovpn-01.txt (work in progress) 745 10. Authors' Information 747 Kireeti Kompella 748 Juniper Networks, Inc. 749 1194 N. Mathilda Ave 750 Sunnyvale, CA 94089 751 Email: kireeti@juniper.net 753 Yakov Rekhter 754 Juniper Networks, Inc. 755 1194 N. Mathilda Ave 756 Sunnyvale, CA 94089 757 Email: yakov@juniper.net 759 Ayan Banerjee 760 Calient Networks 761 5853 Rue Ferrari 762 San Jose, CA 95138 763 Phone: +1.408.972.3645 764 Email: abanerjee@calient.net 766 John Drake 767 Calient Networks 768 5853 Rue Ferrari 769 San Jose, CA 95138 770 Phone: (408) 972-3720 771 Email: jdrake@calient.net 773 Greg Bernstein 774 Ciena Corporation 775 10480 Ridgeview Court 776 Cupertino, CA 94014 777 Phone: (408) 366-4713 778 Email: greg@ciena.com 779 Don Fedyk 780 Nortel Networks Corp. 781 600 Technology Park Drive 782 Billerica, MA 01821 783 Phone: +1-978-288-4506 784 Email: dwfedyk@nortelnetworks.com 786 Eric Mannie 787 GTS Network Services 788 RDI Department, Core Network Technology Group 789 Terhulpsesteenweg, 6A 790 1560 Hoeilaart, Belgium 791 Phone: +32-2-658.56.52 792 Email: eric.mannie@ebone.com 794 Debanjan Saha 795 Tellium Optical Systems 796 2 Crescent Place 797 P.O. Box 901 798 Ocean Port, NJ 07757 799 Phone: (732) 923-4264 800 Email: dsaha@tellium.com 802 Vishal Sharma 803 Jasmine Networks, Inc. 804 3061 Zanker Rd, Suite B 805 San Jose, CA 95134 806 Phone: (408) 895-5000 807 Email: vsharma@jasminenetworks.com 809 Debashis Basak 810 AcceLight Networks, 811 70 Abele Rd, Bldg 1200 812 Bridgeville PA 15017 813 Email: dbasak@accelight.com