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