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