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