idnits 2.17.1 draft-awduche-mpls-te-optical-02.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. == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 444 has weird spacing: '... of the netwo...' == Line 582 has weird spacing: '...tuation may b...' -- 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 (July 2000) is 8685 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 section? '1' on line 861 looks like a reference -- Missing reference section? '2' on line 865 looks like a reference -- Missing reference section? '3' on line 868 looks like a reference -- Missing reference section? '4' on line 872 looks like a reference -- Missing reference section? '8' on line 884 looks like a reference -- Missing reference section? '9' on line 887 looks like a reference -- Missing reference section? '10' on line 890 looks like a reference -- Missing reference section? '5' on line 875 looks like a reference -- Missing reference section? '12' on line 896 looks like a reference -- Missing reference section? '13' on line 899 looks like a reference -- Missing reference section? '6' on line 877 looks like a reference -- Missing reference section? '7' on line 881 looks like a reference -- Missing reference section? '11' on line 893 looks like a reference -- Missing reference section? 'RSVP' on line 615 looks like a reference -- Missing reference section? '14' on line 903 looks like a reference -- Missing reference section? '15' on line 906 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force 2 INTERNET-DRAFT 3 Daniel O. Awduche 4 Expiration Date: January 2001 UUNET (Worldcom) 6 Yakov Rekhter 7 Cisco Systems 9 John Drake 10 Calient Networks 12 Rob Coltun 13 Redback Networks 14 July 2000 16 Multi-Protocol Lambda Switching: 17 Combining MPLS Traffic Engineering Control With Optical Crossconnects 19 draft-awduche-mpls-te-optical-02.txt 21 Status of this Memo 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC2026 except that the right to 25 produce derivative works is not granted. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet- Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 Abstract 45 This document describes an approach to the design of control planes 46 for optical crossconnects (OXCs), which leverages existing control 47 plane techniques developed for MPLS Traffic Engineering. The 48 proposed approach combines recent advances in MPLS traffic 49 engineering control plane constructs with OXC technology to: (1) 50 provide a framework for real-time provisioning of optical channels in 51 automatically switched optical networks, (2) foster the expedited 52 development and deployment of a new class of versatile OXCs, and (3) 53 allow the use of uniform semantics for network management and 54 operations control in hybrid networks consisting of OXCs and label 55 switching routers (LSRs). The proposed approach is particularly 56 advantageous for OXCs intended for data-centric optical 57 internetworking systems. In such environments, it will help to 58 simplify network administration. This approach also paves the way 59 for the eventual incorporation of DWDM multiplexing capabilities in 60 IP routers. 62 1. Introduction 64 This document describes an approach to the design of control planes 65 for optical crossconnects (OXCs), which is based on the Multiprotocol 66 Label Switching (MPLS) traffic engineering control plane model. In 67 this approach, the main idea it to leverage recent advances in 68 control plane technology developed for MPLS traffic engineering (see 69 [1,2,3,4,8,9,10]). This approach is driven by pragmatic 70 considerations, as it exploits an existing technology base to foster 71 rapid development and deployment of a new class of versatile OXCs 72 that address the optical transport needs of the rapidly evolving 73 Internet. This approach will assist in optical channel layer 74 bandwidth management, dynamic provisioning of optical channels, and 75 network survivability through enhanced protection and restoration 76 capabilities in the optical domain. 78 As used in this document, an OXC is a path switching element in an 79 optical transport network that establishes routed paths for optical 80 channels by locally connecting an optical channel from an input port 81 (fiber) to an output port (fiber) on the switch element. Additional 82 characteristics of OXCs, as used in this document, are discussed in 83 Section 4.1. 85 The proposed OXC control plane uses the IGP extensions for MPLS 86 traffic engineering (with additional enhancements) to distribute 87 relevant optical transport network state information, including 88 topology state information. This state information is subsequently 89 used by a constraint-based routing system to compute paths for 90 point-to-point optical channels through the optical transport 91 network. The proposed OXC control plane also uses an MPLS signaling 92 protocol (see [3,4]) to instantiate point-to-point optical channels 93 between access points in the optical transport network. 95 This document does not specify the details of the extensions and 96 domain specific adaptations required to map the MPLS traffic 97 engineering control plane model onto the optical domain. These 98 aspects will be covered in a number of supplementary documents that 99 will follow. However, in Section 7 of this memo, we provide a high 100 level overview of the architectural issues involved in making such 101 adaptations. 103 2. Advantages 105 The advantages of the proposed approach are numerous. 107 - It offers a framework for optical bandwidth management 108 and the real-time provisioning of optical channels in 109 automatically switched optical networks. 111 - It exploits recent advances in MPLS control plane technology 112 and also leverages accumulated operational experience with IP 113 distributed routing control. 115 - It obviates the need to reinvent a new class of control 116 protocols for optical transport networks and allows reuse 117 of software artifacts originally developed for the MPLS 118 traffic engineering application. Consequently, it fosters 119 the rapid development and deployment of a new class of 120 versatile OXCs. 122 - It facilitates the introduction of control coordination concepts 123 between data network elements and optical network elements. 125 - It simplifies network administration in facilities based service 126 provider networks by providing uniform semantics for network 127 management and control in both the data and optical domains. 129 - It paves the way for the eventual introduction of DWDM 130 multiplexing capabilities on IP routers 132 - Lastly, it establishes a preliminary framework for the notion 133 of an optical Internet. 135 3. Background 137 The growth, performance, and survivability requirements of the 138 Internet (which is also becoming very mission critical) are mandating 139 IP-centric networks to be cost effective, survivable, scalable, and 140 to provide control capabilities that facilitate network performance 141 optimization. Some of these requirements are being addressed by the 142 Multiprotocol Label Switching (MPLS) traffic engineering capabilities 143 under development by the IETF [1,2,3,4]. 145 The underlying optical transport network also needs to be versatile, 146 reconfigurable, cost effective, and to support a variety of 147 protection and restoration capabilities due to the rapidly changing 148 requirements of the Internet. 150 A result of these trends, therefore, is the evolution of optical 151 transport networks from simple linear and ring topologies to mesh 152 topologies. By a mesh (not necessarily fully meshed) topology, we 153 mean a connected (not necessarily fully connected) network of 154 arbitrary topology in which the node degree is typically more than 155 two. In mesh optical networks, optical crossconnects engender 156 versatility and reconfigurability by performing switching and 157 rearrangement functions. 159 Underscoring the importance of versatile networking capabilities in 160 the optical domain, a number of standardization organizations and 161 interoperability forums have initiated work items to study the 162 requirements and architectures for reconfigurable optical networks. 163 Refer, for example, to ITU-T recommendation G.872 [5]. This document 164 defines a functional architecture for an optical transport network 165 (OTN) that supports the transport of digital client signals. ITU-T 166 G.872 speaks of an OTN as "a transport network bounded by optical 167 channel access points"[5]. The ITU-T G.872 OTN architecture is based 168 on a layered structure, which includes: 170 (a) an optical channel (OCh) layer network, 171 (b) an optical multiplex section (OMS) layer network, and 172 (c) an optical transmission section (OTS) layer network. 174 The optical channel layer is the most relevant to the discussions in 175 this document. The optical channel layer network supports end-to-end 176 networking of optical channel trails between access points. The OCh 177 layer network provides the following functions: routing, monitoring, 178 grooming, and protection and restoration of optical channels. In 179 this situation, programmable Optical crossconnects, with 180 rearrangeable switch fabrics and relatively smart control planes, 181 will be critical to the realization of the OCh layer functions, 182 especially in mesh optical networks. In the data network domain, 183 routing, monitoring, and survivability are crucial functions 184 performed by the MPLS traffic engineering control plane (see 185 [1,2,3,4,8,9,10]). 187 Note: Although we mention the ITU-T recommendation G.872, the OXC 188 control plane design approach described here is not restricted to 189 G.872 compliant networks. Instead, it can be applied to any mesh 190 optical network that uses programmable and reconfigurable OXCs. 192 Other standards organizations and interoperability forums that are 193 actively pursuing projects related to dynamically reconfigurable 194 optical networks include the ANSI T1X1.5 committee, the Optical 195 Internetworking Forum (OIF), and now by virtue of this memo the IETF. 197 Recent contributions to ANSI T1X1.5 emphasize the need for automation 198 of the OCh layer network by using appropriate signaling protocols to 199 establish optical channels in real time (see [12] and [13]). 201 The Optical Internetworking Forum (http://www.oiforum.com), an 202 international organization engaged in the development and promotion 203 of interoperability agreements for optical internetworking systems, 204 is also evaluating architectural and signaling options related to the 205 internetworking of data network elements with reconfigurable optical 206 networks -- to facilitate rapid provisioning, efficient 207 protection/restoration, and other services in optical internetworking 208 systems. 210 In all these cases, the successful realization of the vision of 211 versatile optical networking depends very much on the synthesis of 212 appropriate control plane technologies with programmable and 213 reconfigurable OXCs. 215 4. OXCs, LSRs, Optical Trails, and Explicit LSPs 217 Consider a hybrid, IP-centric optical internetworking environment 218 consisting of both label switching routers (LSRs) and OXCs, where the 219 OXCs are programmable and support wavelength conversion/translation. 221 At a level of abstraction, an LSR and an OXC exhibit a number of 222 isomorphic relations. It is important to enumerate these relations 223 because they help to expose the reusable software artifacts from the 224 MPLS traffic engineering control plane model. Architecturally, both 225 LSRs and OXCs emphasize problem decomposition by decoupling the 226 control plane from the data plane. 228 The data plane of an LSR uses the label swapping paradigm to transfer 229 a labeled packet from an input port to an output port (see e.g., 231 [6,7]). The data plane of an OXC uses a switching matrix to connect 232 an optical channel trail from an input port to an output port. 234 An LSR performs label switching by first establishing a relation 235 between an tuple and an tuple. Likewise, an OXC provisions optical channel 237 trails by first establishing a relation between an tuple and an 239 tuple. These relations are determined by the control plane of the 240 respective network elements, and are locally instantiated on the 241 device through a switch controller. In the LSR, the next hop label 242 forwarding entry (NHLFE) maintains the input-output relations. In the 243 OXC, the switch controller reconfigures the internal interconnection 244 fabric to establish the relations. These relations cannot be altered 245 by the payload of the data plane. 247 The functions of the control plane (for both LSRs and OXCs) include 248 resource discovery, distributed routing control, and connection 249 management. In particular, the control plane of the LSR is used to 250 discover, distribute, and maintain relevant state information 251 associated with the MPLS network, and to instantiate and maintain 252 label switched paths (LSPs) under various MPLS traffic engineering 253 rules and policies. An LSP is the path through one or more LSRs 254 followed by a specific forwarding equivalence class (FEC) (see [7]). 255 An explicit LSP is one whose route is defined at its origination 256 node. 258 The control plane of the OXC, on the other hand, is used to discover, 259 distribute, and maintain relevant state information associated with 260 the OTN, and to establish and maintain optical channel trails under 261 various optical internetworking traffic engineering rules and 262 policies. An optical channel trail provides a point-to-point optical 263 connection between two access points. An optical channel trail may 264 consist of just one wavelength or a concatenation of multiple 265 wavelengths. If an optical trail consists of just one wavelength, 266 then it is said to satisfy the "wavelength continuity property." At 267 each intermediate OXC along the route of an optical channel trail, 268 OXC switch fabric connects the trail from an input port to an output 269 port. 271 A distinction between the current generation of OXCs and LSRs is that 272 the former do not perform packet level processing in the data plane, 273 while the later are datagram devices which may perform certain packet 274 level operations in the data plane. A significant conceptual 275 difference is that with LSRs the forwarding information is carried 276 explicitly as part of the labels appended to data packets, while with 277 OXCs the switching information is implied from the wavelength or 278 optical channel. 280 4.1 Review of Relevant OXC Characteristics 282 The following section contains a brief overview of relevant OXC 283 characteristics, focusing on the switching functions and underlying 284 technologies. 286 As used in this document, the switching function of an OXC may be 287 electrical or optical. If the switching fabric is purely electrical, 288 then the crossconnect is typically referred to as a digital 289 crossconnect (DXC), or a broadband digital cross-connect (BBDXC) -- 290 if the capacity and port density are sufficiently high. Optical- 291 Electrical-Optical (OEO) conversion is required in BBDXCs. A BBDXC 292 may or may not have WDM multiplexing capabilities. If a BBDXC has WDM 293 multiplexing capabilities, then it may be connected directly to other 294 compatible WDM devices through optical fiber links that carry 295 multiple wavelengths per fiber. If a BBDXC does not have WDM 296 multiplexing capabilities, then it may be connected to an external 297 DWDM multiplexer through a set of discrete fibers, where each fiber 298 carries only one wavelength. A BBDXC may also perform regeneration, 299 reshaping, and re-timing functions. 301 If the switching fabric of an OXC is completely photonic, then we 302 refer to the cross-connect as a pure OXC. If the granularity of 303 channel switching is the wavelength, then the OXC is called a 304 wavelength routing switch (WRS), or simply a wavelength router. The 305 problem of establishing optical channel trails using WRS is called 306 the "Routing and Wavelength Assignment problem" (RWA) [11]. 308 An OXC may also be equipped with both electrical and optical 309 switching capabilities. In this situation, some channels may be 310 switched in the electrical domain and others in the optical domain. 312 Other terms commonly used within the context of optical transport 313 network switching elements include: wavelength selective 314 crossconnects (WSXC) and wavelength interchanging crossconnects 315 (WIXC). 317 In this document, we use the generic term OXC to refer to all 318 categories of programmable and reconfigurable crossconnects for 319 optical transport networks, irrespective of the technologies that 320 underlie them. 322 The OXC control plane design approach described in this document is 323 independent of the underlying OXC switch technologies. It is also 324 independent of specific OXC implementation details. Local adaptation 325 mechanisms can be used to tailor the control plane onto various OXC 326 implementations with different hardware capabilities. As an example, 327 a local adaption function can map a channel/port input/output 328 relation into specialized low level instructions to actuate a 329 rearrangement of the crossconnect switch fabric such that the 330 required input/output relation is realized. 332 A number of forthcoming supplementary documents will describe in some 333 detail the extensions needed to adapt the control plane approach 334 described in this memo to various OXC technologies and optical 335 transport network contexts. 337 4.2 Explicit LSPs and Optical Channel Trails 339 At a conceptual level, explicit LSPs and optical channel trails 340 exhibit certain commonalities. Essentially, they are both 341 fundamentally unidirectional, point-to-point virtual path connection 342 abstractions. An explicit LSP provides a parameterized packet 343 forwarding path (traffic-trunk) between an ingress LSR and an egress 344 LSR. Correspondingly, an optical channel trail provides a (possibly 345 parameterized) optical channel between two endpoints for the 346 transport of client digital signals. 348 The payload carried by both LSPs and optical trails are transparent 349 to intermediate nodes along their respective paths. Both LSPs and 350 optical trails can be parameterized to stipulate their performance, 351 behavioral, and survivability requirements from the network. A set of 352 LSPs induce a virtual graph on a data network topology, while a set 353 of optical trails induce a virtual graph on the topology of a fiber 354 plant. 356 A constraint-based routing scheme can be used to select appropriate 357 paths for both LSPs and optical trails. Generally such paths may 358 satisfy some demands and policy requirements subject to some 359 constraints imposed by the operational environment. 361 There are also commonalities in the allocation of labels to LSPs and 362 in the allocation of wavelengths to optical trails. Two different 363 LSPs that traverse through a given LSR port or interface cannot be 364 allocated the same label. The exception is for LSP aggregation using 365 label merge or label stacking. Similarly, two different optical 366 trails that traverse through a given OXC port cannot be allocated the 367 same wavelength. 369 5. Generic Requirements for the OXC Control Plane 371 The following section contains the requirements for the OXC control 372 plane, with emphasis on the routing components of these requirements. 373 There are three key aspects to these requirements: 375 (1) the capability to establish optical channel trails 376 expeditiously, (in seconds or even milliseconds rather 377 than days or months). 379 (2) the capability to support traffic engineering functions, 380 (see note below) 382 (3) the capability to support various protection and restoration 383 schemes. 385 Note: the introduction of DWDM and automatically switched optical 386 networks is unlikely to eliminate the need for traffic engineering. 387 Instead, it will simply mandate OXCs to also support some traffic 388 engineering capabilities. 390 Historically, the "control plane" of optical transport networks has 391 been implemented via network management. This approach has the 392 following drawbacks: 394 (1) It leads to relatively slow convergence following failure 395 events (typical restoration times are measured in minutes, 396 or even days and weeks especially in systems that require 397 explicit manual intervention). The only way to expedite 398 service recovery in such environments is to pre-provision 399 dedicated protection channels. 401 (2) It complicates the task of interworking equipment from 402 different manufacturers, especially at the management level 403 (generally, a custom "umbrella network management system 404 -NMS- or operations support system -OSS-" is required to 405 integrate otherwise incompatible Element Management Systems 406 from different vendors) 408 (3) It precludes the use of distributed dynamic routing control 409 capabilities in such environments. 411 (4) It complicates the task of inter-network provisioning (due 412 to the lack of EDI between operator NMSs). 414 Thus, another important motivation for the approach described in this 415 document is to improve the responsiveness of the optical transport 416 network, and to increase the level of interoperability within and 417 between service provider networks. 419 6. MPLS Traffic Engineering as a Generic Control Plane for OXCs 421 The requirements for the OXC control plane described in the previous 422 section have already been addressed by the MPLS Traffic Engineering 423 control plane, under development by the IETF (see e.g., 424 [1,2,3,4,8,9]). 426 6.1 Overview of the MPLS Traffic Engineering Control Plane 428 Let us now discuss the components of the MPLS traffic engineering 429 control plane model. The MPLS traffic engineering control plane is a 430 synthesis of new concepts in IP traffic engineering (enabled by MPLS) 431 and the conventional IP network layer control plane. The high level 432 requirements for traffic engineering over MPLS were articulated in 433 RFC-2702 [1]. It is the combination of the notions defined in RFC- 434 2702 (including relevant extensions) along with the conventional IP 435 control plane constructs that effectively establishes a framework for 436 the MPLS traffic engineering control plane model [1] (see also [2]). 438 The components of the MPLS traffic engineering control plane model 439 include the following modules: 441 - Resource discovery 443 - State information dissemination, which is used to distribute 444 relevant information concerning the state of the network, 445 including topology and resource availability information. 446 In the MPLS context, this is accomplished by extending 447 conventional IP link state interior gateway protocols to carry 448 additional information in their link state advertisements 449 (see [8,9]). 451 - Path selection, which is used to select an appropriate route 452 through the MPLS network for explicit routing. It is implemented 453 by introducing the concept of constraint-based routing which is 454 used to compute paths that satisfy certain specifications subject 455 to certain constraints, including constraints imposed by the 456 operational environment (see [1]). 458 - Path management, which includes label distribution, path 459 placement, path maintenance, and path revocation. These are 460 used to establish, maintain, and tear down LSPs in the MPLS 461 context. The label distribution, path placement, and path 462 revocation functions are implemented through a signaling 463 protocol, such as the RSVP extensions [3] or through CR-LDP [4]. 465 These components of the MPLS traffic engineering control plane are 466 separable, and independent of each other. This is a very attractive 467 feature because it allows an MPLS control plane to be implemented 468 using a composition or synthesis of best of breed modules. 470 In RFC-2702 [1], several new MPLS control plane capabilities were 471 proposed that allow various traffic engineering policies to be 472 actualized in MPLS networks. Many of these capabilities are also 473 relevant and applicable to automatically switched optical transport 474 networks with reconfigurable OXCs. 476 We summarize some of these capabilities below, focusing on the set of 477 attributes that can be associated with traffic-trunks. A traffic- 478 trunk is an aggregation of traffic belonging to the same class which 479 are forwarded through a common path. In general, the traffic-trunk 480 concept is a technology independent abstraction. In [1], it was used 481 within the context of MPLS and allowed certain attributes of the 482 traffic transported through LSPs to be parameterized. The traffic- 483 trunk concept can also be extended, in an obvious manner, to the 484 optical transport network. 486 As stipulated in RFC-2702 [1], the attributes that can can be 487 associated with traffic-trunks include: (1) traffic parameters which 488 indicate the bandwidth requirements of the traffic-trunk, (2) 489 adaptivity attributes which specify the sensitivity of the traffic- 490 trunk to changes in the state of the network and in particular 491 indicates whether the traffic-trunk can be re-routed when "better" 492 paths become available, (3) priority attributes which impose a 493 partial order on the set of traffic-trunks and allow path selection 494 and path placement operations to be prioritized, (4) preemption 495 attributes which indicate whether a traffic-trunk can preempt an 496 existing traffic-trunk from its path, (5) resilience attributes which 497 stipulate the survivability requirements of the traffic-trunk and in 498 particular the response of the system to faults that impact the path 499 of the traffic-trunk, and (6) resource class affinity attributes 500 which further restrict route selection to specific subsets of 501 resources and in particular allow generalized inclusion and exclusion 502 policies to be implemented. Other policy attributes and options are 503 also defined by Awduche et al in RFC-2702 [1] for traffic-trunks, 504 including policing attributes [1] (policing is irrelevant in the OXC 505 context). Concepts of subscription (booking) factors are also 506 supported to either bound the utilization of network resources 507 through under-subscription or to exploit statistical multiplexing 508 gain through over-subscription (this aspect is also not very relevant 509 in the OXC context). 511 It should be clear that a subset of these capabilities can be mapped 512 onto an optical transport network by substituting the term "traffic- 513 trunk" with the term "optical channel trail." 515 The MPLS control plane also supports the notion of abstract nodes. 516 An abstract node is essentially a set of nodes (e.g., a subnet, an 517 autonomous system, etc) whose internal topology is opaque to the 518 origination node of an explicit LSP. So, in the most general manner, 519 the route of an explicit LSP (or traffic-trunk) can be specified as a 520 sequence of single hops and/or as a sequence of abstract nodes. 522 The MPLS control plane is very general and is also oblivious of the 523 specifics of the data plane technology. In this regard, the MPLS 524 control plane can be used in conjunction with a data plane that (a) 525 does not necessarily process IP packet headers and (b) does not know 526 about IP packet boundaries. For an existence proof, note that the 527 MPLS control plane has been implemented on IP-LSRs, ATM-LSRs, and 528 Frame Relay-LSRs. 530 The MPLS control plane may also be implemented on OXCs as discussed 531 in this document. 533 6.2 Synthesizing the MPLS Traffic Engineering Control Plane with OXCs 535 Given that that both OXCs and LSRs require control planes, one option 536 would be to have two separate, independent, and incompatible control 537 planes - one for OXCs, and another for LSRs. To understand the 538 drawbacks of this approach, especially in IP-centric optical 539 internetworking systems, one need to look no further than the 540 experience with IP over ATM, where IP has its own control plane (BGP, 541 IS-IS, OSPF), and ATM its own control plane (PNNI) [12]. For some of 542 the drawbacks see [1,2]. 544 Given that the control planes for both OXCs and LSRs have relatively 545 similar requirements, an alternative approach is to develop a 546 coherent control plane technology that can be used for LSRs and for 547 OXCs. Such a uniform control plane will eliminate the administrative 548 complexity of managing hybrid optical internetworking systems with 549 separate, dissimilar control and operational semantics. 550 Specializations may be introduced in the control plane, as necessary, 551 to account for inherent peculiarities of the underlying technologies 552 and networking contexts. 554 All of the above observations suggest, therefore, that the MPLS 555 Traffic Engineering control plane (with some minor extensions) would 556 be very suitable as the control plane for OXCs. An OXC that uses the 557 MPLS traffic engineering control plane would effectively become an IP 558 addressable device. Thus, this proposition also solves the problem of 559 addressing for OXCs. The distribution of topology state information, 560 establishment of optical channel trails, OTN traffic engineering 561 functions, and protection and restoration capabilities would be 562 faciliated by the MPLS Traffic Engineering control plane. 564 An out-of-band IP communications system can be used to carry and 565 distribute control traffic between the control planes of OXCs, 566 perhaps through dedicated supervisory channels (using e.g., dedicated 567 wavelengths or channels, or an independent out-of-band IP network). 568 In this environment, SNMP, or some other network management 569 technology, could be used for element management. From the 570 perspective of control semantics, an OXC with an MPLS Traffic 571 Engineering control plane would resemble a Label Switching Router. 573 If the OXC is a wavelength routing switch, then the physical fiber 574 between a pair of OXCs would represent a single link in the OTN 575 network topology. Individual wavelengths or channels would be 576 analogous to labels. If there are multiple fibers between a pair of 577 OXCs, then as an option, these multiple fibers could be logically 578 grouped together through a process called bundling and represented as 579 a single link in the OTN network topology. 581 If a fiber terminates on a device that functions as both an OXC and 582 an IP router, then the following situation may be possible: 584 - A subset of optical channels within the fiber may be uncommitted. 585 That is, they are not currently in use and hence are available for 586 allocation. 588 - A second subset of channels may already be committed for transit 589 purposes. That is, they are already cross-connected by the OXC 590 element to other out-bound optical channels and thus are not 591 immediately available for allocation. 593 - Another subset of optical channels (within the same fiber) could 594 be 595 in use as terminal channels. That is, they are already allocated 596 but terminate on the local OXC/router device, for example, as 597 SONET 598 interfaces. 600 In the above scenario one way to represent the fiber in the OTN 601 network topology is to depict it is as several links, where one of 602 these links would represent the set of uncommitted channels which 603 constitute the residual capacity of the fiber; while each terminal 604 channel that terminates on the OXC/router could be represented as an 605 individual link. 607 In the control plane model described here, IS-IS or OSPF, with 608 extensions for traffic engineering ([8] or [9]) and possibly 609 additional optical network specific extensions would be used to 610 distribute information about the optical transport network topology 611 and information about available bandwidth and available channels per 612 fiber, as well as other OTN network topology state information. This 613 information will then be used to compute explicit routes for optical 614 channel trails. An MPLS signaling protocol, such as RSVP extensions 615 (see [RSVP]), will be used to instantiate the optical channel trails. 616 Using the RSVP extensions, for example, the wavelength information or 617 optical channel information (as the case may be) will be carried in 618 the LABEL object, which will be used to control and reconfigure the 619 OXCs. 621 The use of a uniform control plane technology for both LSRs and OXCs 622 introduces a number of interesting (and potentially advantageous) 623 architectural possibilities. One such possibility is that a single 624 control plane (MPLS Traffic Engineering) may be able to span both 625 routers and OXCs. In such an environment a Label Switched Path could 626 traverse an intermix of routers and OXCs, or could span just routers, 627 or just OXCs. This offers the potential for real bandwidth-on-demand 628 networking, in which an IP router may dynamically request bandwidth 629 services from the optical transport network. Another possibility is 630 that OXCs and LSRs may run different instances of the control plane 631 which are decoupled with little or no interaction between the control 632 plane instances. 634 To bootstrap the system, OXCs must be able to exchange control 635 information. One way to support this is to pre-configure a dedicated 636 control wavelength between each pair of adjacent OXCs, or between an 637 OXC and a router, and to use this wavelength as a supervisory channel 638 for exchange of control traffic. Another possibility, which has 639 already been mentioned, is to construct a dedicated out of band IP 640 network for the distribution of control traffic. 642 Even though an OXC equipped with an MPLS traffic engineering control 643 plane would (from a control perspective) resemble a Label Switching 644 Router, there are some important distinctions and limitations. One 645 distinction concerns the fact that there are no analogs of label 646 merging in the optical domain. This implies that an OXC cannot merge 647 several wavelengths into one wavelength. Another distinction is that 648 an OXC cannot perform the equivalent of label push and pop operations 649 in the optical domain. This is because the analog of a label in the 650 OXC is a wavelength or an optical channel, and the concept of pushing 651 and popping wavelengths is infeasible with contemporary commercial 652 optical technologies. 654 In the proposed control plane approach, an OXC will maintain a WFIB 655 (Wavelength Forwarding Information Base) per interface (or per 656 fiber). This is because lambdas and/or channels (labels) are specific 657 to a particular interface (fiber), and the same lambda and/or channel 658 (label) could be used concurrently on multiple interfaces (fibers). 660 The MPLS traffic engineering control plane is already being 661 implemented on data plane technologies that exhibit some of the 662 aforementioned distinctions. For example, an ATM-LSR supports only a 663 subset of the MPLS functionality. In particular, most ATM-LSRs are 664 incapable of merging Label Switching Paths, and may not be able to 665 perform label push/pop operations as well. Also, similar to the 666 approach proposed here for OXCs, ATM-LSRs have per interface LFIB 667 (Label Forwarding Information Base). 669 Yet another important distinction concerns the granularity of 670 resource allocation. An MPLS Label Switching Router which operates in 671 the electrical domain can potentially support an arbitrary number of 672 LSPs with arbitrary bandwidth reservation granularities (bounded by 673 the maximum reservable bandwidth per interface, the label space, and 674 the amount of required control overhead). In sharp contrast, an OXC 675 can only support a relatively small number of optical channel trails 676 (this may change as the technology evolves), each of which will have 677 coarse discrete bandwidth granularities (e.g.,OC-12, OC-48, OC-192, 678 and OC-768). A special degenerate case occurs when the control plane 679 is used to establish optical channel trails which all have a fixed 680 bandwidth (e.g., OC-48). 682 If the bandwidth associated with an LSP is small relative to the 683 capacity of an optical channel trail, then very inefficient 684 utilization of network resources could result if only one LSP is 685 mapped onto a given optical channel trail. To improve utilization of 686 resources, therefore, it is necessary to be able to map several low 687 bandwidth LSPs onto a relatively high capacity optical channel trail. 688 For this purpose, a generalized notion of "nested LSPs" may be used. 689 Note that since an OXC cannot perform label push/pop operations, the 690 start/end of a nested LSP has to be on a router (as nesting requires 691 label push/pop). Also note that in this nesting situation, it is the 692 wavelength of the "container" optical channel trail itself that 693 effectively constitutes the outermost label. 695 The transparency and multiprotocol properties of the MPLS Control 696 Plane approach would allow an OXC to route optical channel trails 697 carrying various types of digital payloads (including IP, ATM, Sonet, 698 etc) in a coherent and uniform way. 700 7. Control Adaptation 702 This section provides a high level overview of the architectural 703 considerations involved in tailoring the MPLS traffic engineering 704 control plane model to the optical domain. More detailed discussions 705 of these issues will be provided in a number of supplementary 706 documents to follow. 708 In adapting the MPLS traffic engineering control plane model to OXCs, 709 a number of critical issues should be considered. One critical issue 710 concerns the development of OTN specific domain models which 711 abstracts and captures relevant characteristics of the OTN. The 712 domain models help to delineate the design space for the control 713 plane problem in OXCs, and to construct domain specific software 714 reference architectures. 716 A domain model includes functional and structural aspects. For the 717 purpose of the present discussions, however, we have grouped the 718 considerations pertaining to OTN domain models into two broad 719 categories: (1) a horizontal dimension and (2) a vertical dimension. 720 The horizontal dimension pertains to the specialized networking 721 requirements of the OTN environment. It indicates the enhancements 722 needed to the MPLS TE control plane model to address the peculiar OTN 723 networking requirements. The vertical dimension pertains to 724 localized hardware and software characteristics of the OXCs, which 725 helps to determine the device specific adaptations and support 726 mechanisms needed to port and reuse the MPLS TE control plane 727 software artifacts on an OXC. 729 Horizontal dimension considerations include the following aspects: 731 - What type of OTN state information should be discovered and 732 disseminated to support path selection for optical channel 733 trails? Such state information may include domain specific 734 characteristics of the OTN (encoded as metrics), such as 735 attenuation, dispersion (chromatic, PMD), etc. This aspect will 736 determine the type of additional extensions that are required 737 to IGP link state advertisements to allow distribute such 738 information. 740 - What infrastructure will be used to propagate the control 741 information? 743 - How are constrained paths computed for optical channel trails 744 which fulfill a set of performance and policy requirements 745 subject to a set of system constraints? 747 - What are the domain specific requirements for setting up optical 748 channel trails and what are the enhancements needed to existing 749 MPLS signaling protocols to address these requirements? 751 Vertical dimension considerations include the aspects required to 752 practically port MPLS control plane software onto an OXC. In terms 753 of vertical dimensions, a candidate system architecture for an OXC 754 equipped with an MPLS control plane model is shown in Figure 1 below. 756 -------------------------------- 757 | OXC WITH MPLS CONTROL PLANE | 758 | | 759 | ------------------- | 760 | | | | 761 | | MPLS Control Plane| | 762 | | | | 763 | ------------------- | 764 | | | 765 | ------------------- | 766 | | | | 767 | |Control Adaptation | | 768 | ------------------- | 769 | | OXC Switch | | 770 | | Controller | | 771 | ------------------- | 772 | | | 773 | ------------------- | 774 | | | | 775 | | OXC Switch Fabric | | 776 | | OXC Data Plane | | 777 | ------------------- | 778 | | 779 -------------------------------- 781 Figure 1: Candidate OXC systems architecture 783 8. Architectural Considerations for Deployment in Operational Networks 785 This section provides a high level overview of the architectural 786 considerations for deployment of the proposed control plane in 787 operational networks consisting of LSRs and OXCs. These architectural 788 issues have implications on the degree of control isolation, control 789 coupling, and control cohesion between LSRs and OXCs. 791 Essentially, there are two extremal architectural options for 792 deployment of the proposed control plane in an operational context 793 consisting of LSRs and OXCs. 795 - Overlay Option: One option is to use different instances of the 796 control plane in the OTN (OXC) and IP (LSR) domains. In this 797 situation, each instance of the control plane will operate 798 independent of the other. Interworking (including control 799 coordination) between the two domains can be established through 800 static configuration or through some other procedures that are 801 outside the scope of this document. This partitioned and 802 explicitely decoupled deployment option allows maximal 803 control isolation between the OTN and IP domains. This scheme is 804 conceptually similar to the model in use today, whereby the OTN 805 simply provides point-to-point channels between IP network 806 elements with very minimal control interaction between the two 807 domains. 809 - Peer Option: Another option is to use a single instance of the 810 control plane that subsumes and spans LSRs and OXCs. 812 Other architectural options are also possible which allow various 813 degrees of control isolation and control integration between the OXCs 814 and LSRs. 816 To improve scalability the control plane may use routing hierarchy 817 (e.g., routing areas). Hierarchy may be applied in either of the 818 situations mentioned above. Furthermore, in the overlay option with 819 different control plane instances for OXCs and LSRs, hierarchy could 820 be enabled for each control plane instance independent of the other. 822 In the deployment option with a single instance of the control plane, 823 each routing area may maintain a link state database that contains: 824 (1) physical LSPs (fiber links), (2) optical LSPs (optical channel 825 trails), and (3) logical LSPs (conventional label switched paths). As 826 a general rule, all of these path-oriented connection entities could 827 simply be considered as LSPs with different characteristics. The 828 origination LSR (the head-end) of each LSP entity may locally decide 829 whether to advertise the LSP (with appropriate attributes), so that 830 other LSRs could use it as a link for subsequent path computations. 832 There are significant tradeoffs to the above deployment options, 833 including aspects related to scalability and fault isolation. 834 Additional documents to follow may elaborate on some of these 835 aspects. 837 One of the advantages of the control plane design approach described 838 in this memo is that it potentially allows network administrators the 839 leeway to make these deployment architectural decisions based on 840 their specific objectives, network contexts, and service models. 842 9. Summary 844 This document outlined how the MPLS Traffic Engineering control plane 845 could be adapted and reused as the control plane for optical 846 crossconnects. Such a control plane would be used to distribute 847 optical transport network topology state information and to setup 848 optical channel trails. Such a control plane would support various 849 traffic engineering functions in the optical domain, and enable a 850 variety of protection and restoration capabilities. Furthermore, 851 such a control plane technology would expedite the development and 852 deployment of a new class of versatile data-centric OXCs. 853 Additionally, the proposed control plane approach would simplify 854 integration of OXCs and label switching routers. Finally, the 855 proposed control plane approach would provide coherent semantics for 856 network management and operations control in hybrid optical 857 internetworking systems consisting of LSRs and OXCs. 859 References: 861 [1] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. 862 McManus,"Requirements for Traffic Engineering Over MPLS," RFC- 863 2702,September 1999. 865 [2] D. Awduche, "MPLS and Traffic Engineering in IP Networks," IEEE 866 Communications Magazine, December, 1999. 868 [3] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, and V. 869 Srinivasan, "Extensions to RSVP for LSP Tunnels," Internet Draft,Work 870 in Progress, 1999 872 [4] B. Jamoussi et al, "Constraint-Based LSP Setup using 873 LDP,"Internet Draft, Work in Progress, 1999 875 [5] ITU-T G.872, "Architecture for Optical Transport Networks," 1999. 877 [6] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow,A. 878 Viswanathan, "A Framework for Multiprotocol Label Switching,"Internet 879 Draft, Work in Progress, 1999 881 [7] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label 882 Switching Architecture," Internet Draft, Work in Progress, 1999 884 [8] H. Smit and T. Li, "IS-IS extensions for Traffic 885 Engineering,"Internet Draft, Work in Progress, 1999 887 [9] D. Katz, D. Yeung, "Traffic Engineering Extensions to 888 OSPF,"Internet Draft, Work in Progress, 1999 890 [10] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP- 891 4),"RFC-1171, March 1995 893 [11] B. Mukherjee, "Optical Communications Networks," McGraw-Hill, 894 1997.[14] 896 [12] G. Newsome and P. Bonenfant, "The Automatic Switched Optical 897 Network," Contribution to T1 STANDARDS PROJECT - T1X1.5, 1999. 899 [13] P. Bonenfant and and X. Liu, "A Proposal for Automatically 900 Switched Optical Channel Networks (ASON)," Contribution to T1 901 STANDARDS PROJECT - T1X1.5, 1999. 903 [14] "T. Worster, "General Switch Management Protocol," Internet 904 Draft, Work in Progress, 1999. 906 [15] E. Crawley, R. Nair, B. Rajagopalan, and H. Sandick, "A 907 Framework for QoS-Based Routing in the Internet," RFC-2386, August, 908 1998. 910 Security Considerations 912 It is imperative to guarantee the integrity and confidentiality of 913 control information used by the proposed OXC control plane. This can 914 be accomplished by using existing security mechanisms for the various 915 components of the MPLS traffic engineering control plane model. 917 Author's Addresses 919 Daniel O. Awduche 920 UUNET (Worldcom) 921 22001 Loudoun County Parkway 922 Ashburn, VA 20147 923 Phone: 703-886-5277 924 Email: awduche@uu.net 926 Yakov Rehkter 927 Cisco Systems 928 170 W. Tasman Dr. 929 San Jose, CA 95134 930 Email: yakov@cisco.com 932 John Drake 933 Calient Networks 934 5853 Rue Ferrari 935 San Jose, CA 95138 936 Phone: (408) 972-3720 937 Email: jdrake@calient.net 939 Rob Coltun 940 Redback Networks 941 300 Ferguson Drive 942 Mountain View, CA 94043 943 Phone: (650) 390-9030 944 Email: redback.com