idnits 2.17.1 draft-ietf-ipo-framework-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 3) being 59 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 56 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 202 has weird spacing: '...y carry more ...' == Line 204 has weird spacing: '...be used in th...' == Line 247 has weird spacing: '... trails provi...' == Line 256 has weird spacing: '... set of optic...' == Line 269 has weird spacing: '... A mesh optic...' == (51 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 1600 looks like a reference -- Missing reference section? '2' on line 1218 looks like a reference -- Missing reference section? '3' on line 816 looks like a reference -- Missing reference section? '4' on line 1624 looks like a reference -- Missing reference section? '5' on line 1796 looks like a reference -- Missing reference section? '6' on line 1796 looks like a reference -- Missing reference section? '7' on line 749 looks like a reference -- Missing reference section? '8' on line 863 looks like a reference -- Missing reference section? '9' on line 897 looks like a reference -- Missing reference section? '10' on line 1451 looks like a reference -- Missing reference section? '11' on line 1699 looks like a reference -- Missing reference section? '12' on line 1161 looks like a reference -- Missing reference section? '13' on line 1435 looks like a reference -- Missing reference section? '14' on line 1264 looks like a reference -- Missing reference section? '15' on line 1337 looks like a reference -- Missing reference section? '16' on line 1340 looks like a reference -- Missing reference section? '17' on line 1395 looks like a reference -- Missing reference section? '18' on line 1402 looks like a reference -- Missing reference section? '19' on line 1765 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Bala Rajagopalan 3 Internet Draft Tellium, Inc. 5 draft-ietf-ipo-framework-02.txt James Luciani 6 Expires on: 12/10/2002 Crescent Networks 7 Daniel Awduche 8 Movaz Networks 9 Brad Cain 10 Cereva Networks 11 Bilel Jamoussi 12 Nortel Networks 13 Debanjan Saha 14 Tellium, Inc. 16 IP over Optical Networks: A Framework 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. 23 Internet Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. Internet-Drafts are draft documents valid for a maximum of 27 six months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use Internet- Drafts 29 as reference material or to cite them other than as "work in 30 progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 1. Abstract 40 The Internet transport infrastructure is moving towards a model of 41 high-speed routers interconnected by optical core networks. The 42 architectural choices for the interaction between IP and optical 43 network layers, specifically, the routing and signaling aspects, are 44 maturing. At the same time, a consensus has emerged in the industry 45 on utilizing IP-based protocols for the optical control plane. This 46 document defines a framework for IP over Optical networks, 47 considering both the IP-based control plane for optical networks as 48 well as IP-optical network interactions (together referred to as "IP 49 over optical networks"). 51 Table of Contents 52 ----------------- 54 1. Abstract...........................................................1 55 2. Introduction.......................................................3 56 3. Terminology and Concepts...........................................4 57 4. The Network Model..................................................8 58 4.1 Network Interconnection........................................8 59 4.2 Control Structure.............................................10 60 5. IP over Optical Service Models and Requirements...................12 61 5.1 Domain Services Model.........................................12 62 5.2 Unified Service Model.........................................13 63 5.3 Which Service Model?..........................................14 64 5.4 What are the Possible Services?................................14 65 6. IP transport over Optical Networks................................15 66 6.1 Interconnection Models.........................................15 67 6.2 Routing Approaches.............................................16 68 6.3 Signaling-Related..............................................19 69 6.4 End-to-End Protection Models..................................20 70 7. IP-based Optical Control Plane Issues.............................22 71 7.1 Addressing....................................................23 72 7.2 Neighbor Discovery............................................24 73 7.3 Topology Discovery............................................25 74 7.4 Restoration Models............................................26 75 7.5 Route Computation.............................................27 76 7.6 Signaling Issues..............................................29 77 7.7 Optical Internetworking.......................................31 78 8. Other Issues......................................................32 79 8.1 WDM and TDM in the Same Network..............................32 80 8.2 Wavelength Conversion........................................32 81 8.3 Service Provider Peering Points..............................32 82 8.4 Rate of Lightpath Set-Up.....................................33 83 8.5 Distributed vs. Centralized Provisioning.....................34 84 8.6 Optical Networks with Additional Configurable Components.....34 85 8.7 Optical Networks with Limited Wavelength Conversion Capability35 86 9. Evolution Path for IP over Optical Architecture..................35 87 10. Security Considerations..........................................37 88 10.1 General security aspects......................................38 89 10.2 Protocol Mechanisms...........................................39 90 11. Summary and Conclusions..........................................39 91 12. References.......................................................39 92 13. Acknowledgments..................................................40 93 14. Author's Addresses...............................................41 94 2. Introduction 96 Optical network technologies are evolving rapidly in terms of 97 functions and capabilities. The increasing importance of optical 98 networks is evidenced by the copious amount of attention focused on 99 IP over optical networks and related photonic and electronic 100 interworking issues by all the major network service providers, 101 telecommunications equipment vendors, and standards organizations. 102 In this regard, the term "optical network" is used generically in 103 practice to refer to both SONET/SDH-based transport networks, as 104 well as transparent all-optical networks. 106 It has been realized that optical networks must be survivable, 107 flexible, and controllable. There is, therefore, an ongoing trend to 108 introduce intelligence in the control plane of optical networks to 109 make them more versatile [1]. An essential attribute of intelligent 110 optical networks is the capability to instantiate and route optical 111 layer connections in real-time or near real-time, and to provide 112 capabilities that enhance network survivability. Furthermore, there 113 is a need for multi-vendor optical network interoperability, when an 114 optical network may consist of interconnected vendor-specific 115 optical sub-networks. 117 The optical network must also be versatile because some service 118 providers may offer generic optical layer services that may not be 119 client-specific. It would therefore be necessary to have an optical 120 network control layer that can handle such generic optical services. 122 There is general consensus in the industry that the optical network 123 control plane should utilize IP-based protocols for dynamic 124 provisioning and restoration of lightpaths within and across optical 125 sub-networks. This is based on the practical view that signaling and 126 routing mechanisms developed for IP traffic engineering applications 127 could be re-used in optical networks. Nevertheless, the issues and 128 requirements that are specific to optical networking must be 129 understood to suitably adopt the IP-based protocols. This is 130 especially the case for restoration. Also, there are different 131 views on the model for interaction between the optical network and 132 client networks, such as IP networks. Reasonable architectural 133 alternatives in this regard must be supported, with an understanding 134 of their pros and cons. 136 Thus, there are two fundamental issues related to IP over optical 137 networks. The first is the adaptation and reuse of IP control plane 138 protocols within the optical network control plane, irrespective of 139 the types of digital clients that utilize the optical network. The 140 second is the transport of IP traffic through an optical network 141 together with the control and coordination issues that arise 142 therefrom. 144 This document defines a framework for IP over optical networks 145 covering the requirements and mechanisms for establishing an IP- 146 centric optical control plane, and the architectural aspects of IP 147 transport over optical networks. In this regard, it is recognized 148 that the specific capabilities required for IP over optical networks 149 would depend on the services expected at the IP-optical interface as 150 well as the optical sub-network interfaces. Depending on the 151 specific operational requirements, a progression of capabilities is 152 possible, reflecting increasingly sophisticated interactions at 153 these interfaces. This document therefore advocates the definition 154 of "capability sets" that define the evolution of functionality at 155 the interfaces as more sophisticated operational requirements arise. 157 This document is organized as follows. In the next section, 158 terminology covering certain concepts related to this framework are 159 described. In Section 4, the network model pertinent to this 160 framework is described. The service model and requirements for IP- 161 optical, and multi-vendor optical internetworking are described in 162 Section 5. This section presently considers certain general 163 requirements. Specific operational requirements may be accommodated 164 in this section as they arise. Section 6 considers the 165 architectural models for IP-optical interworking, describing the 166 pros and cons of each model. It should be noted that it is not the 167 intent of this document to promote any particular model over the 168 others. However, particular aspects of the models that may make one 169 approach more appropriate than another in certain circumstances are 170 described. Section 7 describes IP-centric control plane mechanisms 171 for optical networks, covering signaling and routing issues in 172 support of provisioning and restoration. Section 8 describes certain 173 specialized issues in relation to IP over optical networks. The 174 approaches described in Section 7 and 8 range from the relatively 175 simple to the sophisticated. Section 9 describes a possible 176 evolution path for IP over optical networking capabilities in terms 177 of increasingly sophisticated functionality supported. Section 10 178 considers security aspects. Finally, summary and conclusion are 179 presented in Section 11. 181 3. Terminology and Concepts 183 This section introduces the terminology pertinent to this framework 184 and some related concepts. 186 WDM 187 --- 189 Wavelength Division Multiplexing (WDM) is a technology that allows 190 multiple optical signals operating at different wavelengths to be 191 multiplexed onto a single fiber so that they can be transported in 192 parallel through the fiber. In general, each optical wavelength may 193 carry digital client payloads at a different data rate (e.g., OC-3c, 194 OC-12c, OC- 48c, OC-192c, etc.) and in a different format (SONET, 195 Ethernet, ATM, etc.) For example, there are many commercial WDM 196 networks in existence today that support a mix of SONET signals 197 operating at OC-48c (approximately 2.5 Gbps) and OC-192 198 (approximately 10 Gbps) over a single optical fiber. An optical 199 system with WDM capability can achieve parallel transmission of 200 multiple wavelengths gracefully while maintaining high system 201 performance and reliability. In the near future, commercial WDM 202 systems are expected to concurrently carry more than 160 203 wavelengths at data rates of OC-192c and above, for a total of 1.6 204 Tbps or more. The term WDM will be used in this document to refer 205 to both WDM and DWDM (Dense WDM). 207 In general, it is worth noting that WDM links are affected by the 208 following factors, which may introduce impairments into the optical 209 signal path: 211 1. The number of wavelengths on a single fiber. 212 2. The serial bit rate per wavelength. 213 3. The type of fiber. 214 4. The amplification mechanism. 215 5. The number of nodes through which the signal passes before 216 it reaches the egress node or before regeneration. 218 All these factors and others not mentioned here constitute domain 219 specific features of optical transport networks. As noted in [1], 220 these features should be taken into account in developing standards 221 based solutions for IP over optical networks. 223 Optical cross-connect (OXC) 224 --------------------------- 226 An OXC is a space-division switch that can switch an optical data 227 stream on an input port to a output port. Such a switch may have 228 optical-electrical conversion at the input port and electrical- 229 optical conversion at the output port, or it can be all-optical. An 230 OXC is assumed to have a control-plane processor that implements 231 signaling and routing protocols necessary for realizing an optical 232 network. 234 Optical channel trail or Lightpath 235 ---------------------------------- 237 An optical channel trail is a point-to-point optical layer 238 connection between two access points in an optical network. In this 239 document, the term "lightpath" is used interchangeably with optical 240 channel trail. 242 Optical mesh sub-network 243 ------------------------ 245 An optical sub-network, as discussed in this framework, is a network 246 of OXCs that supports end-to-end networking of optical channel 247 trails providing functionality like routing, monitoring, grooming, 248 and protection and restoration of optical channels. The 249 interconnection of OXCs in this network can be based on a general 250 topology (also called "mesh" topology) Underlying this network could 251 be the following: 253 (a) An optical multiplex section (OMS) layer network : The optical 254 multiplex section layer provides the transport of the optical 255 channels. The information contained in this layer is a data 256 stream comprising a set of optical channels, which have a 257 defined aggregate bandwidth. 259 (b) An optical transmission section (OTS) layer network : This 260 provides functionality for transmission of the optical signal on 261 optical media of different types. 263 This framework does not address the interaction between the optical 264 sub-network and the OMS, or between the OMS and OTS layer networks. 266 Mesh optical network (or simply, "optical network") 267 --------------------------------------------------- 269 A mesh optical network, as considered in document, is a mesh- 270 connected 271 collection of optical sub-networks. Such an optical network is 272 assumed to be under a single administration. It is also possible to 273 conceive of a large scale global mesh optical network consisting of 274 the voluntary interconnection of autonomous optical networks, each 275 of which is owned and administered by an independent entity. In this 276 circumstance, abstraction can be used to hide the internal details 277 of each autonomous optical cloud from the remainder of the network. 279 Optical internetwork 280 -------------------- 282 An optical internetwork is a mesh-connected collection of optical 283 networks. Each of these networks may be under different 284 administration. 286 Wavelength continuity property 287 ------------------------------ 289 A lightpath is said to satisfy the wavelength continuity property if 290 it is transported over the same wavelength end-to-end. Wavelength 291 continuity is required in optical networks with no wavelength 292 conversion feature. 293 Wavelength path 294 --------------- 296 A lightpath that satisfies the wavelength continuity property is 297 called a wavelength path. 299 Opaque vs. transparent optical networks 300 --------------------------------------- 302 A transparent optical network is an optical network in which each 303 transit node along a path passes optical transmission without using 304 transducers to convert the optical signal into an electrical signal 305 and back again to an optical signal. More generally, all 306 intermediate nodes in a transparent optical network will pass 307 optical signals without performing retiming and reshaping and thus 308 such nodes are unaware of many characteristics of the carried 309 signals. One could, for example, carry analog signals together with 310 digital signals (potentially of varying bit rate) on different 311 wavelengths over such a network. 313 Note that amplification of signals at transit nodes is 314 permitted in transparent optical networks. This is a result of the 315 availability of all optical amplification devices such as Erbium 316 Doped Fiber Amplifiers (EDFAs). 318 In opaque optical networks, by comparison, transit nodes will 319 manipulate the optical signals as the signals traverse through 320 them. An example of such manipulation would be 3R (reshaping, 321 retiming, regeneration/amplification). 323 Trust domain 324 ------------ 326 A trust domain is a network under a single technical administration 327 in which most nodes in the network are considered to be secure or 328 trusted in some fashion. An example of a trust domain is a campus 329 or corporate network in which all routing protocol packets are 330 considered to be authentic, without the need for additional security 331 schemes to prevent unauthorized access to the network 332 infrastructure. Generally, the "single" administrative control rule 333 may be relaxed in practice if a set of administrative entities agree 334 to trust one another to form an enlarged heterogeneous trust domain. 335 However, to simplify the discussions in this document, it will be 336 assumed, without loss of generality, that the term trust domain 337 applies to a single administrative entity. 339 Flow 340 ---- 342 For the purpose of this document, the term flow will be used to 343 represent the smallest non-separable stream of data, as seen by an 344 endpoint (source or destination node). It is to be noted that the 345 term flow is heavily overloaded in the networking literature. Within 346 the context of this document, it may be convenient to consider a 347 wavelength as a flow under certain circumstances. However, if there 348 is a method to partition the bandwidth of the wavelength, then each 349 partition may be considered a flow, for example by quantizing time 350 into some nicely manageable intervals, it may be feasible to 351 consider each quanta of time within a given wavelength as a flow. 353 Traffic Trunk 354 ------------- 356 A traffic trunk is an abstraction of traffic flow that follows the 357 same path between two access points which allows some 358 characteristics and attributes of the traffic to be parameterized. 360 4. The Network Model 362 4.1 Network Interconnection 364 The network model considered in this memo consists of IP routers 365 attached to an optical core internetwork, and connected to their 366 peers over dynamically established switched lightpaths. The optical 367 core itself is assumed to be incapable of processing individual IP 368 packets in the data plane. 370 The optical internetwork is assumed to consist of multiple optical 371 networks, each may possibly be administered by a different entity. 372 Each optical network consists of sub-networks interconnected by 373 optical links in a general topology (referred to as an optical mesh 374 network). This network may contain re-configurable optical equipment 375 from a single vendor or from multiple vendors. In the near term, it 376 may be expected that each sub-network will consist of a single 377 vendor switches. In the future, as standardization efforts mature, 378 each optical sub-network may in fact contain optical switches from 379 different vendors. In any case, each sub-network itself is assumed 380 to be mesh-connected internally. In general, it can be expected that 381 topologically adjacent OXCs in an optical mesh network will be 382 connected via multiple, parallel (bi-directional) optical links. 383 This network model is shown in Figure 1. 385 Here, an optical sub-network may consist entirely of all-optical 386 OXCs or OXCs with optical-electrical-optical (OEO) conversion. 387 Interconnection between sub-networks is assumed to be through 388 compatible physical interfaces, with suitable optical-electrical 389 conversions where necessary. The routers that have direct physical 390 connectivity with the optical network are referred to as "edge 391 routers". As shown in the figure, other client networks (e.g., ATM) 392 may connect to the optical network. 394 The switching function in an OXC is controlled by appropriately 395 configuring the cross-connect fabric. Conceptually, this may be 396 viewed as setting up a cross-connect table whose entries are of the 397 form , indicating that the data stream 398 entering input port i will be switched to output port j. In the 399 context of a wavelength selective cross-connect (generally referred 400 to as a WXC), the cross-connect tables may also indicate the input 401 and output wavelengths along with the input and output ports. A 402 lightpath from an ingress port in an OXC to an egress port in a 403 remote OXC is established by setting up suitable cross-connects in 404 the ingress, the egress and a set of intermediate OXCs such that a 405 continuous physical path exists from the ingress to the egress port. 406 Optical paths tend to be bi-directional, i.e., the return path from 407 the egress port to the ingress port is typically routed along the 408 same set of intermediate ports as the forward path, but this may not 409 be the case under all circumstances. 411 Optical Network 412 +----------------------------------------+ 413 | | 414 | Optical Subnetwork | 415 +--------------+ | +------------------------------------+ | 416 | | | | +-----+ +-----+ +-----+ | | 417 | IP | | | | | | | | | | | 418 | Network +--UNI--+--+ OXC +------+ OXC +------+ OXC + | | 419 | | | | | | | | | | | | 420 +--------------+ | | +--+--+ +--+--+ +--+--+ | | 421 | +-----|------------|------------|----+ | 422 | | | | | 423 | INNI INNI INNI | 424 +--------------+ | | | | | 425 | | | +-----+------+ | +-------+----+ | 426 | IP +--UNI--| +-----+ | | | 427 | Network | | | Optical | | Optical | | 428 | | | | Subnetwork +---INNI---+ Subnetwork | | 429 +--------------+ | | | | | | 430 | +------+-----+ +------+-----+ | 431 | | | | 432 +--------+-----------------------+-------+ 433 | | 434 ENNI ENNI 435 | | 436 +--------+-----------------------+-------+ 437 | | 438 | Optical Network | 439 | | 440 +--------+-----------------------+-------+ 441 | | 442 UNI UNI 443 | | 444 +------+-------+ +------+-----+ 445 | | | | 446 | Other Client | |Other Client| 447 | Network | | Network | 448 | (e.g., ATM) | | | 449 +--------------+ +------------+ 451 Figure 1: Optical Internetwork Model 453 Multiple data streams output from an OXC may be multiplexed onto an 454 optical link using WDM technology. The WDM functionality may exist 455 outside of the OXC, and be transparent to the OXC. Or, this function 456 may be built into the OXC. In the later case, the cross-connect 457 table (conceptually) consists of pairs of the form, <{input port 458 i, Lambda(j)}, {output port k, Lambda(l)}>. This indicates that the 459 data stream received on wavelength Lambda(j) over input port i is 460 switched to output port k on Lambda(l). Automated establishment of 461 lightpaths involves setting up the cross-connect table entries in 462 the appropriate OXCs in a coordinated manner such that the desired 463 physical path is realized. 465 Under this network model, a switched lightpath must be established 466 between a pair of IP routers before they can communicate. This 467 lightpath might traverse multiple optical networks and be subject to 468 different provisioning and restoration procedures in each 469 network. The IP-based control plane issue is that of designing 470 standard signaling and routing protocols for coherent end-to-end 471 provisioning and restoration of lightpaths across multiple optical 472 networks. Similarly, IP transport over such an optical network 473 involves determining IP reachability and seamless establishment of 474 paths from one IP endpoint to another over an optical core 475 internetwork. 477 4.2 Control Structure 479 There are three logical control interfaces identified in Figure 1. 480 These are the client-optical internetwork interface, the internal 481 node-to-node interface within a network (between OXCs in different 482 sub-networks), and the external node-to-node interface between nodes 483 in different networks. These interfaces are also referred to as the 484 User-Network Interface (UNI), the internal NNI (INNI), and the 485 external NNI, respectively. The distinction between these interfaces 486 arises out of the type and amount of control information flow across 487 them. The UNI represents a service boundary between the client and 488 optical networks. The client and server are essentially two 489 different roles: the client role requests a service connection from 490 a server; the server role establishes the connection to fulfill the 491 service request -- provided all relevant admission control 492 conditions are satisfied. Thus, the control flow across the UNI is 493 dependent on the set of services defined across it and the manner 494 in which the services may be accessed. The service models are 495 described in Section 7. The NNIs represent vendor-independent 496 standardized control flow between nodes. The distinction between the 497 INNI and the ENNI is that the former is an interface within a given 498 network under a single technical administration, while the later 499 indicates an interface at the administrative boundary between 500 networks. The INNI and ENNI may thus differ in the policies that 501 restrict control flow between nodes. Security, scalability, 502 stability, and information hiding are important considerations in 503 the specification of the ENNI. It is possible in principle to 504 harmonize the control flow across the UNI and the NNI and eliminate 505 the distinction between them. On the other hand, it may be required 506 to minimize control flow information, especially routing-related 507 information, over the UNI; and even over the ENNI. In this case, 508 UNI and NNIs may look different in some respects. In this document, 509 these interfaces are treated as distinct. 511 The UNI can be categorized as public or private depending upon 512 context and service models. Routing information (ie, topology state 513 information) can be exchanged across a private UNI. On the other 514 hand, such information is not exchanged across a public UNI, or such 515 information may be exchanged with very explicit restrictions 516 (including for example abstraction, filtration, etc). Thus, 517 different relationships (e.g., peer or over-lay, Section 7) may 518 occur across private and public logical interfaces. 520 The physical control structure used to realize these logical 521 interfaces may vary. For instance, for the UNI, some of the 522 possibilities are: 524 1. Direct interface: An in-band or out-of-band IP control channel 525 (IPCC) may be implemented between an edge router and each OXC 526 to which it is connected. This control channel is used for 527 exchanging signaling and routing messages between the router and 528 the OXC. With a direct interface, the edge router and the OXC it 529 connects to are peers in the control plane. This is shown in 530 Figure 2. The type of routing and signaling information exchanged 531 across the direct interface would vary depending on the service 532 definition. This issue is dealt with in the next section. Some 533 choices for the routing protocol are OSPF/ISIS (with traffic 534 engineering Extensions and additional extensions to deal with the 535 peculiar characteristics of optical networks) or BGP, or some 536 other protocol. Other directory-based routing information 537 exchanges are also possible. Some of the signaling protocol 538 choices are adaptations of RSVP-TE or CR-LDP. The details of how 539 the IP control channel is realized is outside the scope of this 540 document. 542 2. Indirect interface: An out-of-band IP control channel may be 543 implemented between the client and a device in the optical network 544 to signal service requests and responses. For instance, a 545 management system or a server in the optical network may receive 546 service requests from clients. Similarly, out-of-band signaling 547 may be used between management systems in client and optical 548 networks to signal service requests. In these cases, there is no 549 direct control interaction between clients and respective 550 OXCs. One reason to have an indirect interface would be that the 551 OXCs and/or clients do not support a direct signaling interface. 553 +-----------------------------+ +-----------------------------+ 554 | | | | 555 | +---------+ +---------+ | | +---------+ +---------+ | 556 | | | | | | | | | | | | 557 | | Routing | |Signaling| | | | Routing | |Signaling| | 558 | | Protocol| |Protocol | | | | Protocol| |Protocol | | 559 | | | | | | | | | | | | 560 | +-----+---+ +---+-----+ | | +-----+---+ +---+-----+ | 561 | | | | | | | | 562 | | | | | | | | 563 | +--+-----------+---+ | | +--+-----------+---+ | 564 | | | | | | | | 565 | | IP Layer +......IPCC.......+ IP Layer | | 566 | | | | | | | | 567 | +------------------+ | | +------------------+ | 568 | | | | 569 | Edge Router | | OXC | 570 +-----------------------------+ +-----------------------------+ 572 Figure 2: Direct Interface 574 3. Provisioned interface: In this case, the optical network services 575 are manually provisioned and there is no control interactions 576 between the client and the optical network. 578 Although different control structures are possible, further 579 descriptions in this framework assume direct interfaces for IP- 580 optical and optical sub-network control interactions. 582 5. IP over Optical Service Models and Requirements 584 In this section, the service models and requirements at the UNI and 585 the NNIs are considered. Two general models have emerged for the 586 services at the UNI (which can also be applied at the NNIs). These 587 models are as follows. 589 5.1 Domain Services Model 591 Under the domain services model, the optical network primarily 592 offers high bandwidth connectivity in the form of lightpaths. 593 Standardized signaling across the UNI (Figure 1) is used to invoke 594 the following 595 services: 597 1. Lightpath creation: This service allows a lightpath with the 598 specified attributes to be created between a pair of termination 599 points in the optical network. Lightpath creation may be subject 600 to network-defined policies (e.g., connectivity restrictions) and 601 security procedures. 603 2. Lightpath deletion: This service allows an existing lightpath to 604 be deleted. 606 3. Lightpath modification: This service allows certain parameters of 607 the lightpath to be modified. 609 4. Lightpath status enquiry: This service allows the status of 610 certain parameters of the lightpath (referenced by its ID) to be 611 queried by the router that created the lightpath. 613 An end-system discovery procedure may be used over the UNI to verify 614 local port connectivity between the optical and client devices, and 615 allows each device to bootstrap the UNI control channel. Finally, a 616 "service discovery" procedure may be employed as a precursor to 617 obtaining UNI services. Service discovery allows a client to 618 determine the static parameters of the interconnection with the 619 optical network, including the UNI signaling protocols supported. 620 The protocols for neighbor and service discovery are different from 621 the UNI signaling protocol itself (for example, see LMP [2]). 623 Because a small set of well-defined services is offered across the 624 UNI, the signaling protocol requirements are minimal. Specifically, 625 the signaling protocol is required to convey a few messages with 626 certain attributes in a point-to-point manner between the router and 627 the optical network. Such a protocol may be based on RSVP-TE or LDP, 628 for example. 630 The optical domain services model does not deal with the type and 631 nature of routing protocols within and across optical networks. 633 The optical domain services model would result in the establishment 634 of a lightpath topology between routers at the edge of the optical 635 network. The resulting overlay model for IP over optical networks 636 is discussed in Section 7. 638 5.2 Unified Service Model 640 Under this model, the IP and optical networks are treated together 641 as a single integrated network from a control plane point of view. 642 In this regard, the OXCs are treated just like any other router as 643 far as the control plane is considered. Thus, in principle, there is 644 no distinction between the UNI, NNIs and any other router-to-router 645 interface from a routing and signaling point of view. It is assumed 646 that this control plane is MPLS-based, as described in [1]. The 647 unified service model has so far been discussed only in the context 648 of a single administrative domain. A unified control plane is 649 possible even when there are administrative boundaries within an 650 optical internetwork, but some of the integrated routing 651 capabilities may not be practically attractive or even feasible in 652 this case (see Section 7). 654 Under the unified service model, optical network services are 655 obtained implicitly during end-to-end MPLS signaling. Specifically, 656 an edge router can create a lightpath with specified attributes, or 657 delete and modify lightpaths as it creates MPLS label-switched paths 658 (LSPs). In this regard, the services obtained from the optical 659 network are similar to the domain services model. These services, 660 however, may be invoked in a more seamless manner as compared to the 661 domain services model. For instance, when routers are attached to a 662 single optical network (i.e., there are no ENNIs), a remote router 663 could compute an end-to-end path across the optical internetwork. It 664 can then establish an LSP across the optical internetwork. But the 665 edge routers must still recognize that an LSP across the optical 666 internetwork is a lightpath, or a conduit for multiple LSPs. The 667 concept of "forwarding adjacency" can be used to specify virtual 668 links across optical internetworks in routing protocols such as OSPF 669 [3]. In essence, once a lightpath is established across an optical 670 internetwork between two edge routers, it can be advertised as a 671 forwarding adjacency (a virtual link) between these routers. Thus, 672 from a data plane point of view, the lightpaths result in a virtual 673 overlay between edge routers. The decisions as to when to create 674 such lightpaths, and the bandwidth management for these lightpaths 675 is identical in both the domain services model and the unified 676 service model. The routing and signaling models for unified services 677 is described in Section 7. 679 5.3 Which Service Model? 681 The pros and cons of the above service models can be debated at 682 length, but the approach recommended in this framework is to define 683 routing and signaling mechanisms in support of both. As pointed out 684 above, signaling for service request can be unified to cover both 685 models. The developments in GMPLS signaling [4] for the unified 686 service model and its adoption for UNI signaling [5, 6] under the 687 domain services model essentially supports this view. The 688 significant difference between the service models, however, is in 689 routing protocols, as described in Section 7. 691 5.4 What are the Possible Services? 693 Specialized services may be built atop the point-to-point 694 connectivity service offered by the optical network. For example, 696 5.4.1 Virtual Private Networks (VPNs) 698 Given that the data plane between IP routers over an optical network 699 amounts to a virtual topology which is an overlay over the optical 700 network, it is easy to imagine a virtual private network of 701 lightpaths that interconnect routers (or any other set of clients). 702 Indeed, in the case where the optical network provides connectivity 703 for multiple sets of external client networks, there has to be a 704 way to enforce routing policies that ensure routing separation 705 between different sets of clients (i.e., VPN service). 707 6. IP transport over Optical Networks 709 To examine the architectural alternatives for IP over optical 710 networks, it is important to distinguish between the data and 711 control planes over the UNI. As described in Section 6, the optical 712 network provides a service to external entities in the form of fixed 713 bandwidth transport pipes (optical paths). IP routers at the edge of 714 the optical networks must necessarily have such paths established 715 between them before communication at the IP layer can commence. 716 Thus, the IP data plane over optical networks is realized over a 717 virtual topology of optical paths. On the other hand, IP routers and 718 OXCs can have a peer relation on the control plane, especially for 719 the implementation of a routing protocol that allows dynamic 720 discovery of IP endpoints attached to the optical network. The IP 721 over optical network architecture is defined essentially by the 722 organization of the control plane. The assumption in this framework 723 is that an MPLS-based control plane [1] is used. Depending on the 724 service model(Section 6), however, the control planes in the IP and 725 optical networks can be loosely or tightly coupled. This coupling 726 determines 728 o the details of the topology and routing information advertised by 729 the optical network across UNI; 731 o Level of control that IP routers can exercise in selecting 732 specific paths for connections across the optical network; and 734 o Policies regarding the dynamic provisioning of optical paths 735 between routers. This includes access control, accounting and 736 security issues. 738 The following interconnection models are then possible: 740 6.1 Interconnection Models 742 6.1.1 The Peer Model 744 Under the peer model, the IP/MPLS layers act as peers of the optical 745 transport network, such that a single control plane runs 746 over both the IP/MPLS and optical domains. When there is a single 747 optical network involved, presumably a common IGP 748 such as OSPF or IS-IS, with appropriate extensions, can be used to 749 distribute topology information [7] over the integrated IP-optical 750 network. In the case of OSPF, opaque LSAs can be used to advertise 751 topology state information. In the case of IS-IS, extended TLVs will 752 have to be defined to propagate topology state information. When an 753 optical internetwork with multiple optical networks is involved 754 (that spans different administrative boundaries), a single instance 755 of an intra-domain routing protocol is not practically attractive or 756 even feasible. In this case, inter-domain routing and signaling are 757 needed. In either case, a tacit assumption is that a common 758 addressing scheme will be used for the optical and IP networks. A 759 common address space can be trivially realized by using IP addresses 760 in both IP and optical domains. Thus, the optical network elements 761 become IP addressable entities as noted in [1]. 763 6.1.2 The Overlay Model 765 Under the overlay model, the IP/MPLS routing, topology distribution, 766 and signaling protocols are independent of the routing, topology 767 distribution, and signaling protocols at the optical layer. This 768 model is conceptually similar to the classical IP over ATM or MPOA 769 models, but applied to an optical internetwork directly. In the 770 overlay model, topology distribution, path computation and signaling 771 protocols would have to be defined for the optical domain. In 772 certain circumstances, it may also be feasible to statically 773 configure the optical channels that provide connectivity in the 774 overlay model through network management. Static configuration is, 775 however, unlikely to scale in very large networks, nor support the 776 rapid connection provisioning required in today�s competitive 777 networking environment. 779 6.1.3 The Augmented Model 781 Under the augmented model, there are actually separate routing 782 instances in the IP and optical domains, but information from one 783 routing instance is passed through the other routing instance. For 784 example, external IP addresses could be carried within the optical 785 routing protocols to allow reachability information to be passed to 786 IP clients. 788 The routing approaches corresponding to these interconnection models 789 are described below. 791 6.2 Routing Approaches 793 6.2.1 Integrated Routing 795 This routing approach supports the peer model within an 796 administrative domain. Under this approach, the IP and optical 797 networks are assumed to run the same instance of an IP routing 798 protocol, e.g., OSPF with suitable "optical" extensions. These 799 extensions must capture optical link parameters, and any constraints 800 that are specific to optical networks. The topology and link state 801 information maintained by all nodes (OXCs and routers) is identical. 802 This permits a router to compute an end-to-end path to another 803 router across the optical network. Suppose the path computation is 804 triggered by the need to route a label switched path (LSP). Such an 805 LSP can be established using MPLS signaling, e.g., RSVP-TE or CR- 806 LDP. When the LSP is routed over the optical network, a lightpath 807 must be established between two edge routers. This lightpath is in 808 essence a tunnel across the optical network, and may have capacity 809 much larger than that required to route the first LSP. Thus, it is 810 essential that other routers in the network realize the availability 811 of resources in the lightpath for other LSPs to be routed over it. 813 The lightpath may therefore be advertised as a virtual link in the 814 topology. 816 The notion of "forwarding adjacency" (FA) described in [3] is 817 essential in propagating existing lightpath information to other 818 routers. An FA is essentially a virtual link advertised into a link 819 state routing protocol. Thus, an FA could be described by the same 820 parameters that define resources in any regular link. While it is 821 necessary to specify the mechanism for creating an FA, it is not 822 necessary to specify how an FA is used by the routing scheme. Once 823 an FA is advertised in a link state protocol, its usage for routing 824 LSPs is defined by the route computation and traffic engineering 825 algorithms implemented. 827 It should be noted that at the IP-optical interface, the physical 828 ports over which routers are connected to OXCs constrain the 829 connectivity and resource availability. Suppose a router R1 is 830 connected to OXC O1 over two ports, P1 and P2. Under integrated 831 routing, the connectivity between R1 and O1 over the two ports would 832 have been captured in the link state representation of the network. 833 Now, suppose an FA at full port bandwidth is created from R1 to 834 another router R2 over port P1. While this FA is advertised as a 835 virtual link between R1 and R2, it is also necessary to remove the 836 link R1-O1 (over P1) from the link state representation since that 837 port is no longer available for creating a lightpath. Thus, as FAs 838 are created, an overlaid set of virtual links is introduced into the 839 link state representation, replacing the links previously advertised 840 at the IP-Optical interface. Finally, the details of the optical 841 network captured in the link state representation is replaced by a 842 network of FAs. The above scheme is one way to tackle the problem. 843 Another approach is to associate appropriate dynamic attributes with 844 link state information, so that a link that cannot be used to 845 establish a particular type of connection will be appropriately 846 tagged. Generally, however, there is a great deal of similarity 847 between integrated routing and domain-specific routing (described 848 next). Both ultimately deal with the creation of a virtual 849 lightpath topology (which is overlaid over the optical network) to 850 meet certain traffic engineering objectives. 852 6.2.2 Domain-Specific Routing 854 The domain-specific routing approach supports the augmented 855 interconnection model. Under this approach, routing within the 856 optical and IP domains are separated, with a standard routing 857 protocol running between domains. This is similar to the IP inter- 858 domain routing model. A specific approach for this is considered 859 next. It is to be noted that other approaches are equally possible. 861 6.2.2.1 Domain-Specific Routing using BGP 863 The inter-domain IP routing protocol, BGP [8], may be adapted for 864 exchanging routing information between IP and optical domains. This 865 would allow the routers to advertise IP address prefixes within 866 their network to the optical internetwork and to receive external 867 IP address prefixes from the optical internetwork. The optical 868 internetwork transports the reachability information from one IP 869 network to others. For instance, edge routers and OXCs can run 870 exterior BGP (EBGP). Within the optical internetwork, interior BGP 871 (IBGP) is used between border OXCs within the same network, and EBGP 872 is used between networks (over ENNI, Figure 1). 874 Under this scheme, it is necessary to identify the egress points in 875 the optical internetwork corresponding to externally reachable IP 876 addresses. This is due to the following. Suppose an edge router 877 desires to establish an LSP to a destination reachable across the 878 optical internetwork. It could directly request a lightpath to that 879 destination, without explicitly specifying the egress optical port 880 for the lightpath as the optical internetwork has knowledge of 881 externally reachable IP addresses. However, if the same edge router 882 has to establish another LSP to a different external destination, it 883 must first determine whether there is a lightpath already available 884 (with sufficient residual capacity) that leads to that destination. 885 To identify this, it is necessary for edge routers to keep track of 886 which egress ports in the optical internetwork lead to which 887 external destinations. Thus, a border OXC receiving external IP 888 prefixes from an edge router through EBGP must include its own IP 889 address as the egress point before propagating these prefixes to 890 other border OXCs or edge routers. An edge router receiving this 891 information need not propagate the egress address further, but it 892 must keep the association between external IP addresses and egress 893 OXC addresses. Specific BGP mechanisms for propagating egress OXC 894 addresses are to be determined, considering prior examples 895 described in [9]. When VPNs are implemented, the address prefixes 896 advertised by the border OXCs may be accompanied by some VPN 897 identification (for example, VPN IPv4 addresses, as defined in [9], 898 may be used). 900 6.2.3 Overlay Routing 902 The overlay routing approach supports the overlay interconnection 903 model.Under this approach, an overlay mechanism that allows edge 904 routers toregister and query for external addresses is implemented. 905 This is conceptually similar to the address resolution mechanism 906 used for IP over ATM. Under this approach, the optical network could 907 implement a registry that allows edge routers to register IP 908 addresses and VPN identifiers. An edge router may be allowed to 909 query for external addresses belonging to the same set of VPNs it 910 belongs to. A successful query would return the address of the 911 egress optical port through which the external destination can be 912 reached. 914 Because IP-optical interface connectivity is limited, the 915 determination of how many lightpaths must be established and to what 916 endpoints are traffic engineering decisions. Furthermore, after an 917 initial set of such lightpaths are established, these may be used as 918 adjacencies within VPNs for a VPN-wide routing scheme, for example, 919 OSPF. With this approach, an edge router could first determine other 920 edge routers of interest by querying the registry. After it obtains 921 the appropriate addresses, an initial overlay lightpath topology may 922 be formed. Routing adjacencies may then be established across the 923 lightpaths and further routing information may be exchanged to 924 establish VPN-wide routing. 926 6.3 Signaling-Related 928 6.3.1 The Role of MPLS 930 It is possible to model wavelengths, and potentially TDM channels 931 within a wavelength as "labels". This concept was proposed in [1], 932 and "generalized" MPLS (GMPLS) mechanisms for realizing this are 933 described in [4]. MPLS signaling protocols with traffic engineering 934 extensions, such as RSVP-TE and CR-LDP can be used for signaling 935 lightpath requests. In the case of the domain services model, these 936 protocols can be adapted for UNI signaling as well [5, 6]. In the 937 case of the unified services model, lightpath establishment occurs 938 to support end-to-end LSP establishment using these protocols (with 939 suitable GMPLS enhancements [10, 11]). 941 6.3.2 Signaling Models 943 With the domain-services model, the signaling control plane in the 944 IP and optical network are completely separate as shown in Figure 3 945 below. This separation also implies the separation of IP and optical 946 address spaces (even though the optical network would be using 947 internal IP addressing). While RSVP-TE and LDP can be adapted for 948 UNI signaling, the full functionality of these protocols will not be 949 used. For example, UNI signaling does not require the specification 950 of explicit routes. On the other hand, based on the service 951 attributes, new objects need to be signaled using these protocols as 952 described in [5, 6]. 954 MPLS Signaling UNI Signaling MPLS or other signaling 955 | 956 +-----------------------------+ | +-----------------------------+ 957 | IP Network | | | Optical Internetwork | 958 | +---------+ +---------+ | | | +---------+ +---------+ | 959 | | | | | | | | | | | | | 960 | | Router +---+ Router +-----+------+ OXC +---+ OXC | | 961 | | | | | | | | | | | | | 962 | +-----+---+ +---+-----+ | | | +-----+---+ +---+-----+ | 963 +-----------------------------+ | +-----------------------------+ 964 | 965 | 966 Completely Separated Addressing and Control Planes 968 Figure 3: Domain Services Signaling Model 970 With the unified services model, the addressing is common in the IP 971 network and optical internetwork and the respective signaling 972 control are related, as shown in Figure 4. It is understood that 973 GMPLS signaling is implemented in the IP and optical domains, using 974 suitably enhanced RSVP-TE or CR-LDP protocols. But the semantics of 975 services within the optical internetwork may be different from that 976 in the IP network. As an example, the protection services offered in 977 the optical internetwork may be different from the end-to-end 978 protection services offered by the IP network. Another example is 979 with regard to bandwidth. While the IP network may offer a continuum 980 of bandwidths, the optical internetwork will offer only discrete 981 bandwidths. Thus, the signaling attributes and services are defined 982 independently for IP and optical domains. The routers at the edge of 983 the optical internetwork must therefore identify service boundaries 984 and perform suitable translations in the signaling messages crossing 985 the IP-optical boundary. This may still occur even though the 986 signaling control plane in both networks are GMPLS-based and there 987 is tighter coupling of the control plane as compared to the domain 988 services model. 990 Service Boundary Service Boundary 991 | | 992 IP Layer GMPLS Signaling | Optical Layer GMPLS | IP Layer GMPLS 993 | | 994 +--------+ +--------+ | +-------+ +-------+ | +--------+ 995 | | | | | | | | | | | | 996 | IP LSR +--+ IP LSR +--+--+Optical+--+Optical+-+--+ IP LSR +--- 997 | | | | | | LSR | | LSR | | | | 998 +-----+--+ +---+----+ | +-----+-+ +---+---+ | +--------+ 1000 Common Address Space, Service Translation 1002 Figure 4: Unified Services Signaling Model 1004 Thus, as illustrated in Figure 4, the signaling in the case of 1005 unified services is actually multi-layered. The layering is based on 1006 the technology and functionality. As an example, the specific 1007 adaptations of GMPLS signaling for SONET layer (whose functionality 1008 is transport) are described in [12]. 1010 6.4 End-to-End Protection Models 1012 Suppose an LSP is established from an ingress IP router to an egress 1013 router across an ingress IP network, a transit optical internetwork 1014 and an egress IP network. If this LSP is to be afforded protection 1015 in the IP layer, how is the service coordinated between the IP and 1016 optical layers? 1018 Under this scenario, there are two approaches to end-to-end 1019 protection: 1021 6.4.1 Segment-Wise Protection 1023 The protection services in the IP layer could utilize optical layer 1024 protection services for the LSP segment that traverses the optical 1025 internetwork. Thus, the end-to-end LSP would be treated as a 1026 concatenation of three LSP segments from the protection point of 1027 view: a segment in the ingress IP network, a segment in the optical 1028 internetwork and a segment in the egress IP network. The protection 1029 services at the IP layer for an end-to-end LSP must be mapped onto 1030 suitable protection services offered by the optical internetwork. 1031 Suppose that 1+1 protection is offered to LSPs at the IP layer, 1032 i.e., each protected LSP has a pre-established hot stand-by in a 1+1 1033 or 1:1 configuration. In case of a failure of the primary LSP, 1034 traffic can be immediately switched to the stand-by. This type of 1035 protection can be realized end-to-end as follows. With reference to 1036 Figure 5, let an LSP originate at (ingress) router interface A and 1037 terminate at (egress) router interface F. Under the first protection 1038 option, a primary path for the LSP must be established first. Let 1039 this path be as shown in Figure 5, traversing router interface B 1040 in the ingress network, optical ports C (ingress) and D (egress), 1041 and router interface E in the egress network. Next, 1+1 protection 1042 is realized separately in each network by establishing a protection 1043 path between points A and B, C and D and E and F. Furthermore, the 1044 segments B-C and D-E must themselves be 1+1 protected, using drop- 1045 side protection. For the segment between C and D, the optical 1046 internetwork must offer a 1+1 service similar to that offered in the 1047 IP networks. 1049 +----------------+ +------------------+ +---------------+ 1050 | | | | | | 1051 A Ingress IP Net B----C Optical Internet D----E Egress IP Net F 1052 | | | | | | 1053 +----------------+ +------------------+ +---------------+ 1055 Figure 5: End-to-End Protection Example 1057 6.4.2 Single-Layer Protection 1059 Under this model, the protection services in the IP layer do not 1060 rely on any protection services offered in the optical internetwork. 1061 Thus, with reference to Figure 5, two SRLG-disjoint LSPs are 1062 established between A and F. The corresponding segments in the 1063 optical internetwork are treated as independent lightpaths in the 1064 optical internetwork. These lightpaths may be unprotected in the 1065 optical internetwork. 1067 6.4.3 Differences 1069 A distinction between these two choices is as follows. Under the 1070 first choice, the optical internetwork is actively involved in end- 1071 to-end protection, whereas under the second choice, any protection 1072 service offered in the optical internetwork is not utilized directly 1073 by client IP network. Also, under the first choice, the protection 1074 in the optical internetwork may apply collectively to a number of IP 1075 LSPs. That is, with reference to Figure 5, many LSPs may be 1076 aggregated into a single lightpath between C and D. The optical 1077 internetwork protection may then be applied to all of them at once 1078 leading to some gain in scalability. Under the second choice, each 1079 IP LSP must be separately protected. Finally, the first choice 1080 allows different restoration signaling to be implemented in the IP 1081 and optical internetwork. These restoration protocols are "patched 1082 up" at the service boundaries to realize end-to-end protection. A 1083 further advantage of this is that restoration is entirely contained 1084 within the network where the failure occurs, thereby improving the 1085 restoration latency, and perhaps network stability as a fault within 1086 an optical domain is contained and corrected within the domain. For 1087 instance, if there is a failure in the optical internetwork, optical 1088 network protocols restore the affected internal segments. Under the 1089 second choice, restoration signaling is always end-to-end between IP 1090 routers, essentially by-passing the optical internetwork. A result 1091 of this is that restoration latency could be higher. In addition, 1092 restoration protocols in the IP layer must run transparently over 1093 the optical internetwork in the overlay mode. IP based recovery 1094 techniques may however be more resource efficient, as it may be 1095 possible to convey traffic through the redundant capacity under 1096 fault-free scenarios. In particular, it may be possible to utilize 1097 classification, scheduling, and concepts of forwarding equivalence 1098 class to route lower class traffic over protect facilities and then 1099 possibly preempt them to make way for high priority traffic when 1100 faults occur. 1102 7. IP-based Optical Control Plane Issues 1104 Provisioning and restoring lightpaths end-to-end between IP networks 1105 requires protocol and signaling support within optical sub-networks, 1106 and across the INNI and ENNI. In this regard, a distinction is made 1107 between control procedures within an optical sub-network (Figure 1), 1108 between sub-networks, and between networks. The general guideline 1109 followed in this framework is to separate these cases, and allow the 1110 possibility that different control procedures are followed inside 1111 different sub-networks, while a common set of procedures are 1112 followed across sub-networks and networks. 1114 The control plane procedures within a single vendor sub-network need 1115 not be defined since these can be proprietary. Clearly, it is 1116 possible to follow the same control procedures inside a sub-network 1117 as defined for control across sub-networks. But this is left as a 1118 recommendation � even choice � within this framework document, 1119 rather than as an imperative requirement. Thus, in the following, 1120 signaling and routing across sub-networks is considered first, 1121 followed by a discussion of similar issues across networks. 1123 7.1 Addressing 1125 For interoperability across optical sub-networks using an IP-centric 1126 control plane, the fundamental issue is that of addressing. What 1127 entities should be identifiable from a signaling and routing point 1128 of view? How should they be addressed? This section presents some 1129 guidelines on this issue. 1131 Identifiable entities in optical networks includes OXCs, optical 1132 links, optical channels and sub-channels, Shared Risk Link Groups 1133 (SRLGs), etc. An issue here is how granular the identification 1134 should be as far as the establishment of optical trails are 1135 concerned. The scheme for identification must accommodate the 1136 specification of the termination points in the optical network with 1137 adequate granularity when establishing optical trails. For instance, 1138 an OXC could have many ports, each of which may in turn terminate 1139 many optical channels, each of which contain many sub-channels etc. 1140 It is perhaps not reasonable to assume that every sub-channel or 1141 channel termination, or even OXC ports could be assigned a unique IP 1142 address. Also, the routing of an optical trail within the network 1143 does not depend on the precise termination point information, but 1144 rather only on the terminating OXC. Thus, finer granularity 1145 identification of termination points is of relevance only to the 1146 terminating OXC and not to intermediate OXCs (of course, resource 1147 allocation at each intermediate point would depend on the 1148 granularity of resources requested). This suggests an identification 1149 scheme whereby OXCs are identified by a unique IP address and a 1150 "selector" identifies further fine-grain information of relevance at 1151 an OXC. This, of course, does not preclude the identification of 1152 these termination points directly with IP addresses(with a null 1153 selector). The selector can be formatted to have adequate number of 1154 bits and a structure that expresses port, channel, sub-channel, etc, 1155 identification. 1157 Within the optical network, the establishment of trail segments 1158 between adjacent OXCs require the identification of specific port, 1159 channel, sub-channel, etc. With a GMPLS control plane, a label 1160 serves this function. The structure of the label must be such that 1161 it can encode the required information [12]. 1163 Another entity that must be identified is the SRLG [13]. An 1164 SRLG is an identifier assigned to a group of optical links that 1165 share a physical resource. For instance, all optical channels routed 1166 over the same fiber could belong to the same SRLG. Similarly, all 1167 fibers routed over a conduit could belong to the same SRLG. The 1168 notable characteristic of SRLGs is that a given link could belong to 1169 more than one SRLG, and two links belonging to a given SRLG may 1170 individually belong to two other SRLGs. This is illustrated in 1171 Figure 6. Here, the links 1,2,3 and 4 may belong to SRLG 1, links 1172 1,2 and 3 could belong to SRLG 2 and link 4 could belong to SRLG 3. 1173 Similarly, links 5 and 6 could belong to SRLG 1, and links 7 and 8 1174 could belong to SRLG 4. (In this example, the same SRLG, i.e., 1, 1175 contains links from two different adjacencies). 1177 While the classification of physical resources into SRLGs is a 1178 manual operation, the assignment of unique identifiers to these 1179 SRLGs within an optical network is essential to ensure correct 1180 SRLG-disjoint path computation for protection. SRLGs could be 1181 identified with a flat identifier (e.g., 32 bit integer). 1183 Finally, optical links between adjacent OXCs may be bundled for 1184 advertisement into a link state protocol [14]. A bundled interface 1185 may be numbered or unnumbered. In either case, the component links 1186 within the bundle must be identifiable. In concert with SRLG 1187 identification, this information is necessary for correct path 1188 computation. 1190 7.2 Neighbor Discovery 1192 Routing within the optical network relies on knowledge of network 1193 topology and resource availability. This information may be gathered 1194 and used by a centralized system, or by a distributed link state 1195 routing protocol. In either case, the first step towards network- 1196 wide link state determination is the discovery of the status of 1197 local links to all neighbors by each OXC. Specifically, each OXC 1198 must determine the up/down status of each optical link, the 1199 bandwidth and other parameters of the link, and the identity of the 1200 remote end of the link (e.g., remote port number). The last piece of 1201 information is used to specify an appropriate label when signaling 1202 for lightpath provisioning. The determination of these parameters 1203 could be based on a combination of manual configuration and an 1204 automated protocol running between adjacent OXCs. The 1205 characteristics of such a protocol would depend on the type of OXCs 1206 that are adjacent (e.g., transparent or opaque). 1208 Neighbor discovery would typically require in-band communication on 1209 the bearer channels to determine local connectivity and link status. 1210 In the case of opaque OXCs with SONET termination, one instance of a 1211 neighbor discovery protocol (e.g., LMP [2]) would run on each OXC 1212 port, communicating with the corresponding protocol instance at the 1213 neighboring OXC. The protocol would utilize the SONET overhead bytes 1214 to transmit the (configured) local attributes periodically to the 1215 neighbor. Thus, two neighboring switches can automatically determine 1216 the identities of each other and the local connectivity, and also 1217 keep track of the up/down status of local links. Neighbor discovery 1218 with transparent OXCs is described in [2]. 1220 +--------------+ +------------+ +------------+ 1221 | +-1:OC48---+ +-5:OC192-+ | 1222 | +-2:OC48---+ +-6:OC192-+ | 1223 | OXC1 +-3:OC48---+ OXC2 +-7:OC48--+ OXC3 | 1224 | +-4:OC192--+ +-8:OC48--+ | 1225 | | | | +------+ | 1226 +--------------+ +----+-+-----+ | +----+------+-----+ 1227 | | | | | 1228 | | | | | 1229 +--------------+ | | | | | 1230 | | +----+-+-----+ | | +------+-----+ 1231 | +----------+ +--+ | | | 1232 | OXC4 +----------+ +----+ | | 1233 | +----------+ OXC5 +--------+ OXC6 | 1234 | | | +--------+ | 1235 +--------------+ | | | | 1236 +------+-----+ +------+-----+ 1238 Figure 6: Mesh Optical Network with SRLGs 1240 7.3 Topology Discovery 1242 Topology discovery is the procedure by which the topology and 1243 resource state of all the links in a network are determined. This 1244 procedure may be done as part of a link state routing protocol 1245 (e.g., OSPF, ISIS), or it can be done via the management plane (in 1246 the case of centralized path computation). The implementation of a 1247 link state protocol within a network (i.e., across sub-network 1248 boundaries) means that the same protocol runs in OXCs in every sub- 1249 network. If this assumption does not hold then interworking of 1250 routing between sub-networks is required. This is similar to inter- 1251 network routing discussed in Section 8.7. The focus in the following 1252 is therefore on standardized link state routing. 1254 In general, most of the link state routing functionality is 1255 maintained when applied to optical networks. However, the 1256 representation of optical links, as well as some link parameters, 1257 are changed in this setting. Specifically, 1259 o The link state information may consist of link bundles [14]. 1260 Each link bundle is represented as an abstract link in the network 1261 topology. Different bundling representations are possible. For 1262 instance, the parameters of the abstract link may include the 1263 number, bandwidth and the type of optical links contained in the 1264 underlying link bundle [14]. Also, the SRLGs corresponding to each 1265 optical link in the bundle may be included as a parameter. 1267 o The link state information should capture restoration-related 1268 parameters for optical links. Specifically, with shared protection 1269 (Section 8.5), the link state updates must have information that 1270 allows the computation of shared protection paths. 1272 o A single routing adjacency could be maintained between neighbors 1273 which may have multiple optical links (or even multiple link 1274 bundles) between them. This reduces the protocol messaging 1275 overhead. 1277 o Since link availability information changes dynamically, a 1278 flexible policy for triggering link state updates based on 1279 availability thresholds may be implemented. For instance, changes 1280 in availability of links of a given bandwidth (e.g., OC-48) may 1281 trigger updates only after the availability figure changes by a 1282 certain percentage. 1284 These concepts are relatively well-understood. On the other hand, 1285 the resource representation models and the topology discovery 1286 process for hierarchical routing (e.g., OSPF with multiple areas) 1287 are areas that need further work. 1289 7.4 Restoration Models 1291 Automatic restoration of lightpaths is a service offered by optical 1292 networks. There could be local and end-to-end mechanisms for 1293 restoration of lightpaths within a network (across the INNI). Local 1294 mechanisms are used to select an alternate link between two adjacent 1295 OXCs across the INNI when a failure affects the primary link over 1296 which the (protected) lightpath is being routed. Local restoration 1297 does not affect the end-to-end route of the lightpath. When local 1298 restoration is not possible (e.g., no alternate link is available 1299 between the adjacent OXCs in question), end-to-end restoration may 1300 be performed. With this, the affected lightpath may be rerouted over 1301 an alternate path that completely avoids the OXCs or the link 1302 segment where the failure occurred. For end-to-end restoration, 1303 alternate paths are typically pre-computed. Such back-up paths may 1304 have to be physically diverse from the corresponding primary paths. 1306 End-to-end restoration may be based on two types of protection 1307 schemes; "1 + 1" protection or shared protection. Under 1 + 1 1308 protection, a back-up path is established for the protected primary 1309 path along a physically diverse route. Both paths are active and the 1310 failure along the primary path results in an immediate switch-over 1311 to the back-up path. Under shared protection, back-up paths 1312 corresponding to physically diverse primary paths may share the same 1313 network resources. When a failure affects a primary path, it is 1314 assumed that the same failure will not affect the other primary 1315 paths whose back-ups share resources. 1317 It is possible that different restoration schemes may be implemented 1318 within optical sub-networks. It is therefore necessary to consider a 1319 two-level restoration mechanism. Path failures within an optical 1320 sub-network could be handled using procedures specific to the 1321 sub-network. If this fails, end-to-end restoration across sub- 1322 networks could be invoked. The border OXC that is the ingress to a 1323 sub-network can act as the source for restoration procedures within 1324 a sub-network. The signaling for invoking end-to-end restoration 1325 across the INNI is described in Section 8.6.3. The computation of 1326 the back-up path for end-to-end restoration may be based on various 1327 criteria. It is assumed that the back-up path is computed by the 1328 source OXC, and signaled using standard methods. 1330 7.5 Route Computation 1332 The computation of a primary route for a lightpath within an optical 1333 network is essentially a constraint-based routing problem. The 1334 constraint is typically the bandwidth required for the lightpath, 1335 perhaps along with administrative and policy constraints. The 1336 objective of path computation could be to minimize the total 1337 capacity required for routing lightpaths [15]. 1339 Route computation with constraints may be accomplished using a 1340 number of algorithms [16]. When 1+1 protection is used, a back-up 1341 path that does not traverse on any link which is part of the same 1342 SRLG as links in the primary path must be computed. Thus, it is 1343 essential that the SRLGs in the primary path be known during 1344 alternate path computation, along with the availability of resources 1345 in links that belong to other SRLGs. This requirement has certain 1346 implications on optical link bundling. Specifically, a bundled LSA 1347 must include adequate information such that a remote OXC can 1348 determine the resource availability under each SRLG that the bundled 1349 link refers to, and the relationship between links belonging to 1350 different SRLGs in the bundle. For example, considering Figure 3, 1351 if links 1,2,3 and 4 are bundled together in an LSA, the bundled LSA 1352 must indicate that there are three SRLGs which are part of the 1353 bundle (i.e., 1, 2 and 3), and that links in SRLGs 2 and 3 are also 1354 part of SRLG 1. 1356 To encode the SRLG relationships in a link bundle LSA, only links 1357 which belong to exactly the same set of SRLGs must be bundled 1358 together. With reference to Figure 3, for example, two bundles can 1359 be advertised for links between OXC1 and OXC2, with the following 1360 information: 1362 Bundle No. SRLGs Link Type Number Other Info 1363 ---------- ----- --------- ------ ---------- 1364 1 1,2 OC-48 3 --- 1365 2 1,3 OC-192 1 --- 1367 Assuming that the above information is available for each bundle at 1368 every node, there are several approaches possible for path 1369 computation. For instance, 1371 1. The primary path can be computed first, and the (exclusive 1372 or shared) back-up is computed next based on the SRLGs chosen 1373 for the primary path. In this regard, 1375 o The primary path computation procedure can output a series of 1376 bundles the path is routed over. Since a bundle is uniquely 1377 identified with a set of SRLGs, the alternate path can be 1378 computed right away based on this knowledge. In this case, if 1379 the primary path set up does not succeed for lack of resources 1380 in a chosen bundle, the primary and backup paths must be 1381 recomputed. 1383 o It might be desirable to compute primary paths without choosing 1384 a specific bundle apriori. That is, resource availability over 1385 all bundles between a node pair is taken into account rather 1386 than specific bundle information. In this case, the primary 1387 path computation procedure would output a series of nodes the 1388 path traverses. Each OXC in the path would have the freedom to 1389 choose the particular bundle to route that segment of the 1390 primary path. This procedure would increase the chances of 1391 successfully setting up the primary path when link state 1392 information is not up to date everywhere. But the specific 1393 bundle chosen, and hence the SRLGs in the primary path, must be 1394 captured during primary path set-up, for example, using the 1395 RSVP-TE Route Record Object [17]. This SRLG information is 1396 then used for computing the back-up path. The back-up path may 1397 also be established specifying only which SRLGs to AVOID in a 1398 given segment, rather than which bundles to use. This would 1399 maximize the chances of establishing the back-up path. 1401 2. The primary path and the back-up path are comptuted together in 1402 one step, for example, using Suurbaale's algorithm [18]. In this 1403 case, the paths must be computed using specific bundle 1404 information. 1406 To summarize, it is essential to capture sufficient information in 1407 link bundle LSAs to accommodate different path computation 1408 procedures and to maximize the chances of successful path 1409 establishment. Depending on the path computation procedure used, 1410 the type of support needed during path establishment (e.g., the 1411 recording of link group or SRLG information during path 1412 establishment) may differ. 1414 When shared protection is used, the route computation algorithm must 1415 take into account the possibility of sharing links among multiple 1416 back-up paths. Under shared protection, the back-up paths 1417 corresponding to SRLG-disjoint primary paths can be assigned the 1418 same links. The assumption here is that since the primary paths are 1419 not routed over links that have the same SRLG, a given failure will 1420 affect only one of them. Furthermore, it is assumed that multiple 1421 failure events affecting links belonging to more than one SRLG will 1422 not occur concurrently. Unlike the case of 1+1 protection, the 1423 back-up paths are not established apriori. Rather, a failure event 1424 triggers the establishment of a single back-up path corresponding to 1425 the affected primary path. 1427 The distributed implementation of route computation for shared back- 1428 up paths require knowledge about the routing of all primary and 1429 back-up paths at every node. This raises scalability concerns. For 1430 this reason, it may be practical to consider the centralization of 1431 the route computation algorithm in a route server that has complete 1432 knowledge of the link state and path routes. Heuristics for fully 1433 distributed route computation without complete knowledge of path 1434 routes are to be determined. Path computation for restoration is 1435 further described in [13]. 1437 7.6 Signaling Issues 1439 Signaling within an optical network for lightpath provisioning 1440 is a relatively simple operation if a standard procedure is 1441 implemented within all sub-networks. Otherwise, proprietary 1442 signaling may be implemented within sub-networks, but converted back 1443 to standard signaling across the INNI. This is similar to signaling 1444 across the ENNI, as described in Section 8.7. In the former case, 1445 signaling messages could carry a strict explicit route in signaling 1446 messages, while in the latter case the route should be loose, at the 1447 level of sub-networks. Once a route is determined for a lightpath, 1448 each OXC in the path must establish appropriate cross-connects in a 1449 coordinated fashion. This coordination is akin to selecting incoming 1450 and outgoing labels in a label-switched environment. Thus, protocols 1451 like RSVP-TE [11] and CR-LDP [10] can be used across the INNI for 1452 this. A few new concerns, however, must be addressed. 1454 7.6.1 Bi-Directional Lightpath Establishment 1456 Lightpaths are typically bi-directional. That is, the output port 1457 selected at an OXC for the forward direction is also the input port 1458 for the reverse direction of the path. Since signaling for optical 1459 paths may be autonomously initiated by different nodes, it is 1460 possible that two path set-up attempts are in progress at the same 1461 time. Specifically, while setting up an optical path, an OXC A may 1462 select output port i which is connected to input port j of the 1463 "next" OXC B. Concurrently, OXC B may select output port j for 1464 setting up a different optical path, where the "next" OXC is A. This 1465 results in a "collision". Similarly, when WDM functionality is built 1466 into OXCs, a collision occurs when adjacent OXCs choose directly 1467 connected output ports and the same wavelength for two different 1468 optical paths. There are two ways to deal with such collisions. 1469 First, collisions may be detected and the involved paths may be torn 1470 down and re-established. Or, collisions may be avoided altogether. 1472 7.6.2 Failure Recovery 1474 The impact of transient partial failures must be minimized in an 1475 optical network. Specifically, optical paths that are not directly 1476 affected by a failure must not be torn down due to the failure. For 1477 example, the control processor in an OXC may fail, affecting 1478 signaling and other internodal control communication. Similarly, 1479 the control channel between OXCs may be affected temporarily by a 1480 failure. These failure may not affect already established optical 1481 paths passing through the OXC fabric. The detection of such failures 1482 by adjacent nodes, for example, through a keepalive mechanism 1483 between signaling peers, must not result in these optical paths 1484 being torn down. 1486 It is likely that when the above failures occur, a backup processor 1487 or a backup control channel will be activated. The signaling 1488 protocol must be designed such that it is resilient to transient 1489 failures. During failure recovery, it is desirable to recover local 1490 state at the concerned OXC with least disruption to existing optical 1491 paths. 1493 7.6.3 Restoration 1495 Signaling for restoration has two distict phases. There is a 1496 reservation phase in which capacity for the protection path is 1497 established. Then, there is an activation phase in which the 1498 back-up path is actually put in service. The former phase typically 1499 is not subject to strict time constraints, while the latter is. 1501 Signaling to establish a "1+1" back-up path is relatively straight- 1502 forward. This signaling is very similar to signaling used for 1503 establishing the primary path. Signaling to establish a shared back- 1504 up path is a little bit different. Here, each OXC must understand 1505 which back-up paths can share resources. The signaling message must 1506 itself indicate shared reservation. The sharing rule is as described 1507 in Section 8.4: back-up paths corresponding to physically diverse 1508 primary paths may share the same network resources. It is 1509 therefore necessary for the signaling message to carry adequate 1510 information that allows an OXC to verify that back-up paths that 1511 share a certain resources are allowed to do so. 1513 Under both 1+1 and shared protection, the activation phase has two 1514 parts: propagation of failure information to the source OXC from the 1515 point of failure, and activation of the back-up path. The signaling 1516 for these two phases must be very fast in order to realize response 1517 times in the order of tens of milliseconds. When optical links are 1518 SONET-based, in-band signals may be used, resulting in quick 1519 response. With out-of-band control, it is necessary to consider 1520 fast signaling over the control channel using very short IP packets 1521 and prioritized processing. While it is possible to use RSVP or CR- 1522 LDP for activating protection paths, these protocols do not provide 1523 any means to give priority to restoration signaling as opposed to 1524 signaling for provisioning. For instance, it is possible for a 1525 restoration-related RSVP message to be queued behind a number of 1526 provisioning messages thereby delaying restoration. It is therefore 1527 necessary to develop a definition of QoS for restoration signaling 1528 and incorporate mechanisms in existing signaling protocols to 1529 achieve this. Or, a new signaling protocol may be developed 1530 exclusively for activating protection paths during restoration. 1532 7.7 Optical Internetworking 1534 Within an optical internetwork, it must be possible to dynamically 1535 provision and restore lightpaths across optical networks. Therefore: 1537 o A standard scheme for uniquely identifying lightpath end-points in 1538 different networks is required. 1540 o A protocol is required for determining reachability of end-points 1541 across networks. 1543 o A standard signaling protocol is required for provisioning 1544 lightpaths across networks. 1546 o A standard procedure is required for the restoration of lightpaths 1547 across networks. 1549 o Support for policies that affect the flow of control information 1550 across networks will be required. 1552 The IP-centric control architecture for optical networks can be 1553 extended to satisfy the functional requirements of optical 1554 internetworking. Routing and signaling interaction between optical 1555 networks can be standardized across the ENNI (Figure 1). The 1556 functionality provided across ENNI is as follows. 1558 7.7.1 Neighbor Discovery 1560 Neighbor discovery procedure, as described in Section 8.2, can be 1561 used for this. Indeed, a single protocol should be standardized for 1562 neighbor discovery within and across networks. 1564 7.7.2 Addressing and Routing Model 1566 The addressing mechanisms described in Section 8.1 can be used to 1567 identify OXCs, ports, channels and sub-channels in each network. 1568 It is essential that the OXC IP addresses are unique within the 1569 internetwork. 1571 Provisioning an end-to-end lightpath across multiple networks 1572 involves the establishment of path segments in each network 1573 sequentially. Thus, a path segment is established from the source 1574 OXC to a border OXC in the source network. From this border OXC, 1575 signaling across NNI is used to establish a path segment to a border 1576 OXC in the next network. Provisioning then continues in the next 1577 network and so on until the destination OXC is reached. The usage of 1578 protocols like BGP for this purpose need to be explored. 1580 7.7.3 Restoration 1582 Local restoration across the ENNI is similar to that across INNI 1583 described in Section 8.6.3. End-to-end restoration across networks 1584 is likely to be either of the 1+1 type, or segmented within each 1585 network, as described in Section 8.4. 1587 8. Other Issues 1589 8.1 WDM and TDM in the Same Network 1591 A practical assumption would be that if SONET (or some other TDM 1592 mechanism that is capable partitioning the bandwidth of a 1593 wavelength) is used, then TDM is leveraged as an additional method 1594 to differentiate between "flows." In such cases, wavelengths and 1595 time intervals (sub-channels) within a wavelength become analogous 1596 to labels (as noted in [1]) which can be used to make switching 1597 decisions. This would be somewhat akin to using VPI (e.g., 1598 wavelength) and VCI (e.g., TDM sub-channel) in ATM networks. More 1599 generally, this will be akin to label stacking and to LSP nesting 1600 within the context of Multi-Protocol Lambda Switching [1]. GMPLS 1601 signaling [4] supports this type of multiplexing. 1603 8.2 Wavelength Conversion 1605 Some form of wavelength conversion may exist at some switching 1606 elements. This however may not be the case in some pure optical 1607 switching elements. A switching element is essentially anything 1608 more sophisticated than a simple repeater, that is capable of 1609 switching and converting a wavelength Lambda(k) from an input port 1610 to a wavelength Lambda(l) on an output port. In this display, it 1611 is not necessarily the case that Lambda(k) = Lambda(l), nor is it 1612 necessarily the case that the data carried on Lambda(k) is switched 1613 through the device without being examined or modified. 1615 It is not necessary to have a wavelength converter at every 1616 switching element. A number of studies have attempted to address 1617 the issue of the value of wavelength conversion in an optical 1618 network. Such studies typically use the blocking probability (the 1619 probability that a lightpath cannot be established because the 1620 requisite wavelengths are not available) as a metric to adjudicate 1621 the effectiveness of wavelength conversion. The IP over optical 1622 architecture must take into account hybrid networks with some OXCs 1623 capable of wavelength conversion and others incapable of this. The 1624 GMPLS "label set" mechanism [4] supports the selection of the same 1625 label (i.e., wavelength) across an NNI. 1627 8.3 Service Provider Peering Points 1629 There are proposed inter-network interconnect models which allow 1630 certain types of peering relationships to occur at the optical 1631 layer. This is consistent with the need to support optical layer 1632 services independent of higher layers payloads. In the context of IP 1633 over optical networks, peering relationships between different trust 1634 domains will eventually have to occur at the IP layer, on IP routing 1635 elements, even though non-IP paths may exist between the peering 1636 routers. 1638 8.4 Rate of Lightpath Set-Up 1640 Dynamic establishment of optical channel trails and lightpaths is 1641 quite desirable in IP over optical networks, especially when such 1642 instantiations are driven by a stable traffic engineering control 1643 system, or in response to authenticated and authorized requests from 1644 clients. 1646 However, there are many proposals suggesting the use of dynamic, 1647 data-driven shortcut-lightpath setups in IP over optical networks. 1648 The arguments put forth in such proposals are quite reminiscent of 1649 similar discussions regarding ATM deployment in the core of IP 1650 networks. Deployment of highly dynamic data driven shortcuts within 1651 core networks has not been widely adopted by carriers and ISPs for a 1652 number of reasons: possible CPU overhead in core network elements, 1653 complexity of proposed solutions, stability concerns, and lack of 1654 true economic drivers for this type of service. This document 1655 assumes that this paradigm will not change and that highly dynamic, 1656 data-driven shortcut lightpath setups are for future investigation. 1657 Instead, the optical channel trails and lightpaths that are expected 1658 to be widely used at the initial phases in the evolution of IP over 1659 optical networks will include the following: 1661 o Dynamic connections for control plane traffic and default path 1662 routed data traffic, 1664 o Establishment and re-arrangement of arbitrary virtual topologies 1665 over rings and other physical layer topologies. 1667 o Use of stable traffic engineering control systems to engineer 1668 lightpath connections to enhance network performance, either for 1669 explicit demand based QoS reasons or for load balancing). 1671 Other issues surrounding dynamic connection setup within the core 1672 center around resource usage at the edge of the optical domain. 1673 One potential issue pertains to the number of flows that can be 1674 processed by an ingress or egress network element either because of 1675 aggregate bandwidth limitations or because of a limitation on the 1676 number of flows (e.g., lightpaths) that can be processed 1677 concurrently. 1679 Another possible short term reason for dynamic shortcut lightpath 1680 setup would be to quickly pre-provisioned paths based on some 1681 criteria (TOD, CEO wants a high BW reliable connection, etc.). In 1682 this scenario, a set of paths is pre-provisioned, but not actually 1683 instantiated until the customer initiates an authenticated and 1684 authorized setup requests, which is consistent with existing 1685 agreements between the provider and the customer. In a sense, the 1686 provider may have already agreed to supply this service, but will 1687 only instantiate it by setting up a lightpath when the customer 1688 submits an explicit request. 1690 8.5 Distributed vs. Centralized Provisioning 1692 This document has mainly dealt with a distributed model for 1693 lightpath provisioning, in which all nodes maintain a synchronized 1694 topology database, and advertise topology state information to 1695 maintain and refresh the database. A constraint-based routing entity 1696 in each node then uses the information in the topology database and 1697 other relevant details to compute appropriate paths through the 1698 optical domain. Once a path is computed, a signaling protocol (e.g., 1699 [11]) is used to instantiate the lightpath. 1701 Another provisioning model is to have a centralized server which has 1702 complete knowledge of the physical topology, the available 1703 wavelengths, and where applicable, relevant time domain information. 1704 A corresponding client will reside on each network element that can 1705 source or sink a lightpath. The source client would query the 1706 server in order to set up a lightpath from the source to the 1707 destination. The server would then check to see if such a lightpath 1708 can be established based on prevailing conditions. Furthermore, 1709 depending on the specifics of the model, the server may either setup 1710 the lightpath on behalf of the client or provide the necessary 1711 information to the client or to some other entity to allow the 1712 lightpath to be instantiated. 1714 Centralization aids in implementing complex capacity optimization 1715 schemes, and may be the near-term provisioning solution in optical 1716 networks with interconnected multi-vendor optical sub-networks. In 1717 the long term, however, the distributed solution with centralization 1718 of some control procedures (e.g., traffic engineering) is likely to 1719 be the approach followed. 1721 8.6 Optical Networks with Additional Configurable Components 1723 Thus far, this memo has focused mainly on IP over optical networks 1724 where the cross-connect is the basic dynamically re-configurable 1725 device in the optical network. Recently, as a consequence of 1726 technology evolution, various types of re-configurable optical 1727 components are now available, including tunable lasers, tunable 1728 filters, etc. Under certain circumstances, it may be necessary to 1729 parameterize the characteristics of these components and advertise 1730 them within the control plane. This aspect is left for further 1731 study. 1733 8.7 Optical Networks with Limited Wavelength Conversion Capability 1735 At the time of the writing of this document, the majority of optical 1736 networks being deployed are "opaque". In this context the term 1737 opaque means that each link is optically isolated by transponders 1738 doing optical-electrical-optical conversions. Such conversions have 1739 the added benefit of permitting 3R regeneration. The 3Rs refer to 1740 re-power, signal retiming and reshaping. Unfortunately, this 1741 regeneration requires that the underlying optical equipment be aware 1742 of both the bit rate and frame format of the carried signal. These 1743 transponders are quite expensive and their lack of transparency 1744 constrains the rapid introduction of new services [19]. Thus there 1745 are strong motivators to introduce "domains of transparency" wherein 1746 all-optical networking equipment would transport data unfettered by 1747 these drawbacks. 1749 Thus, the issue of IP over optical networking in all optical sub- 1750 networks, and sub-networks with limited wavelength conversion 1751 capability merits special attention. In such networks, transmission 1752 impairments resulting from the peculiar characteristics of optical 1753 communications complicate the process of path selection. These 1754 transmission impairments include loss, noise (due primarily to 1755 amplifier spontaneous emission - ASE), dispersion (chromatic and 1756 PMD), cross-talk, and non-linear effects. In such networks, the 1757 feasibility of a path between two nodes is no longer simply a 1758 function of topology and resource availability but will also depend 1759 on the accumulation of impairments along the path. If the impairment 1760 accumulation is excessive, the optical signal to noise ratio (OSNR) 1761 and hence the electrical bit error rate (BER) at the destination 1762 node may exceed prescribed thresholds, making the resultant optical 1763 channel unusable for data communication. The challenge in the 1764 development of IP-based control plane for optical networks is to 1765 abstract these peculiar characteristics of the optical layer [19] in 1766 a generic fashion, so that they can be used for path computation. 1768 9. Evolution Path for IP over Optical Architecture 1770 The architectural models described in Section 7 imply a certain 1771 degree of implementation complexity. Specifically, the overlay 1772 model was described as the least complex for near term deployment 1773 and the peer model the most complex. Nevertheless, each model has 1774 certain advantages and this raises the question as to the evolution 1775 path for IP over optical network architectures. 1777 The evolution approach recommended in this framework is the 1778 definition of capability sets that start with simpler functionality 1779 in the beginning and include more complex functionality later. In 1780 this regard, it is realistic to expect that initial IP over optical 1781 deployments will be based on the domain services model (with overlay 1782 interconnection), with no routing exchange between the IP and 1783 optical domains. Under this model, direct signaling between IP 1784 routers and optical networks is likely to be triggered by offline 1785 traffic engineering decisions. The next step in the evolution of IP- 1786 optical interaction is the introduction of reachability information 1787 exchange between the two domains. This would potentially allow 1788 lightpaths to be established as part of end-to-end LSP set-up. The 1789 final phase is the support for the full peer model with more 1790 sophisticated routing interaction between IP and optical domains. 1792 Using a common signaling framework (based on GMPLS) from the 1793 beginning facilitates this type of evolution. For the domain 1794 services model, implementation agreement based on GMPLS UNI 1795 signaling is being developed in the Optical Interworking Forum (OIF) 1796 [5, 6]. This agreement is aimed at near term deployment and this 1797 could be the precursor to a future peer model architecture. In this 1798 evolution, the signaling capability and semantics at the IP-optical 1799 boundary would become more sophisticated, but the basic structure of 1800 signaling would remain. This would allow incremental developments as 1801 the interconnection model becomes more sophisticated, rather than 1802 complete re-development of signaling capabilities. 1804 From a routing point of view, the use of Network Management Systems 1805 (NMS) for static connection management is prevelant in legacy 1806 optical networks. Going forward, it can be expected that connection 1807 routing using the control plane will be gradually introduced and 1808 integrated into operational infrastructures. The introduction of 1809 routing capabilities can be expected to occur in a phased approach. 1810 It is likely that in the first phase, service providers will either 1811 upgrade existing local element management (EMS) software with 1812 additional control plane capabilities (and perhaps the hardware as 1813 well), or updrade the NMS software in order to introduce some degree 1814 of automation within each optical subnetwork. For this reason, it 1815 may be desirable to partition the network into subnetworks and 1816 introduce IGP interoperability within each subnetwork (i.e. at the 1817 I-NNI level), and employ either static or signaled interoperability 1818 between subnetworks. Consequently, it can be envisioned that the 1819 first phase in the evolution towards network level control plane 1820 interoperability in IP over Optical networks will be organized 1821 around a system of optical subnetworks which are interconnected 1822 statically (or dynamically in a signaled configuration). During this 1823 phase, an overlay interconnection model will be used between the 1824 optical network itself and external IP and MPLS routers (as 1825 described in Section 7.2.3). 1827 Progressing with this phased approach to IPO routing 1828 interoperabibility evolution, the next level of integration will be 1829 achieved when a single carrier provides dynamic optical routing 1830 interoperability between subnetworks and between domains. In order 1831 to become completely independent of the network switching capability 1832 within subnetworks and across domains, routing information exchange 1833 may need to be enabled at the UNI level. This would constitute a 1834 significant evolution: even if the routing instances are kept 1835 separate and independent, it would still be possible to dynamicallhy 1836 exchange reachability and other types of routing information. 1837 Another more sophisticated step during this phase is to introduce 1838 dynamic routing at the E-NNI level. This means that any neighboring 1839 networks (independent of internal switching capability) would be 1840 capable of exchanging routing information with peers across the E- 1841 NNI. 1843 Another alternative would be for private networks to bypass these 1844 intermediate steps and directly consider an integrated routing model 1845 from the onset. This direct evolution strategy is realistic, but is 1846 more likely to occur in operational contexts where both the IP (or 1847 MPLS) and optical networks are built simultaneously, using equipment 1848 from a single source or from multiple sources that are closely 1849 affiliated. In any case, due the current lack of operational 1850 experience in managing this degree of control plane interaction in a 1851 heterogenous network (these issues may exist even if the hardware 1852 and software originate from the same vendor), an augmented model is 1853 likely to be the most viable initial option. Alternatively, a very 1854 modular or hierarchical peer model may be contemplated. There may be 1855 other challenges (not just of a technical, but also administrative 1856 and even political issues) that may be need to be resolved in order 1857 to achieve full a peer model at the routing level in a multi- 1858 technology and multi-vendor environment. Ultimately, the main 1859 technical improvement would likely arise from efficiencies derived 1860 from the integration of traffic-engineering capabilities in the 1861 dynamic inter-domain routing environments. 1863 10. Security Considerations 1865 The architectural framework described in this document requires 1866 different protocol mechanisms for its realization. Specifically, the 1867 role of neighbor discovery, routing and signaling protocols were 1868 described in previous sections. The general security issues that 1869 arise with these protocols include: 1871 o The authentication of entities exchanging information 1872 (signaling, routing or link management) across a control 1873 interface; 1875 o Ensuring the integrity of the information exchanged across the 1876 interface, and 1878 o Protection of the control mechanisms from outside interference 1880 Because optical connections may carry high volumes of data and 1881 consume significant network resources, mechanisms are required to 1882 safeguard an optical network against unauthorized use of network 1883 resources. 1885 In addition to the security aspects related to the control plane, 1886 the data plane must also be protected from external interference. 1888 10.1 General security aspects 1890 Communication protocols usually require two main security 1891 mechanisms: authentication and confidentiality. Authentication 1892 mechanisms ensure data origin verification and message integrity so 1893 that unauthorized operations can be detectedd and discarded. For 1894 example, with reference to Figure 1, message authentication service 1895 can prevent a malicious IP client from mounting a denial of service 1896 attack against the optical network by inserting an excessive number 1897 of UNI connection creation requests. Additionally, authentication 1898 mechanisms can provide 1900 1. Replay protection, which detects and rejects attempts to 1901 reorder, duplicate, truncate, or otherwise tamper with the 1902 proper sequence of messages, and 1903 2. Non-repudiation, which may be desirable for accounting and 1904 billing purposes. 1906 Authentication and confidentiality can be achieved using either 1907 symmetric or public-key cryptographic algorithms. Simple message 1908 integrity and confidentiality are normally achieved using symmetric 1909 cryptographic algorithms. These algorithms typically require pair- 1910 wise shared secret keys and do not provide non-repudiation, but are 1911 typically less computationally intensive. Replay protection is 1912 normally achieved by adding sequence numbers to the messages or by 1913 relying on other protocol (e.g., TCP) to guarantee the proper 1914 sequencing of the message stream above the integrity service. 1915 Public-key or asymmetric cryptographic algorithms are typically 1916 used, initially, to provide two-way peer entity authentication and 1917 key agreement, which facilitate use of the integrity and 1918 confidentiality services described above. Asymmetric algorithms also 1919 provide digital signatures used to implement a non-repudiation 1920 service. The use of asymmetric algorithms may be supported by a 1921 public-key infrastructure (PKI) or some other, community-defined, 1922 key assignment scheme. Asymmetric algorithms are typically more 1923 computationally intensive than symmetric algorithms. 1925 Confidentiality of signaling messages is also likely to be 1926 desirable, especially in cases where message attributes include 1927 information private to the communicating parties (client and optical 1928 network operator). Examples of such attributes include account 1929 numbers, contract identification numbers, etc, exchanged over the 1930 UNI (Figure 1). 1932 The case of non-co-located equipment presents increased security 1933 requirements. In this scenario, the signaling (or routing) peers may 1934 be connected using an external network. Since such a network could 1935 be outside the control of the optical (or client) network operator, 1936 control communication between peers may be subject to increased 1937 security threats, such as address spoofing, eavesdropping and 1938 unauthorized intrusion attempts. To counter these threats , 1939 appropriate security mechanisms have to be employed to protect the 1940 signaling and control channel(s). 1942 10.2 Protocol Mechanisms 1944 The security-related mechanisms required in IP-centric control 1945 protocols would depend on the specific security requirements. Such 1946 details are beyond the scope of this document and hence are not 1947 considered further. 1949 11. Summary and Conclusions 1951 The objective of this document was to define a framework for IP over 1952 optical networks, considering the service models, routing and 1953 signaling issues. There are a diversity of choices, as described 1954 in this document, for IP-optical interconnection, service models 1955 and protocol mechanisms. The approach advocated in this document 1956 was to allow different service models and proprietary enhancements 1957 in optical networks, and define complementary signaling and 1958 routing mechanisms that would support these. An evolution scenario, 1959 based on a common GMPLS-based signaling framework with increasing 1960 interworking functionality was suggested. Under this scenario, the 1961 IP-optical interaction is first based on the domain services model 1962 with overlay interconnection that eventually evolves to support full 1963 peer interaction. 1965 12. References 1967 1. D. Awduche and Y. Rekhter, , "Multi-Protocol 1968 Lambda Switching: Combining MPLS Traffic Engineering Control With 1969 Optical Crossconnects," IEEE Communications Magazine, March 2001. 1971 2. J. P. Lang, et. al., "Link Management Protocol," Internet Draft, 1972 Work in progress. 1974 3. K. Kompella and Y. Rekhter, "LSP Hierarchy with MPLS TE," 1975 Internet Draft, Work in progress. 1977 4. P. Ashwood-Smith et. al, "Generalized MPLS - Signaling Functional 1978 Description", Internet Draft, Work in Progress. 1980 5. B. Rajagopalan, "LMP, LDP and RSVP Extensions for Optical UNI 1981 Signaling," Internet Draft, Work in Progress. 1983 6. The Optical Interworking Forum, "UNI 1.0 Signaling 1984 Specification," December, 2001. 1986 7. K. Kompella et al, "OSPF Extensions in Support of Generalized 1987 MPLS," Internet Draft, Work in Progress. 1989 8. Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP4)",RFC 1990 1771, March, 1995. 1992 9. E. Rosen and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March, 1999. 1994 10. P. Ashwood-Smith, et. al., "Generalized MPLS - CR-LDP Signaling 1995 Functional Description," Internet Draft, Work in Progress. 1997 11. P. Ashwood-Smith, et. al., "Generalized MPLS - RSVP-TE 1998 Signaling Functional Description", Internet Draft, Work in 1999 Progress. 2001 12. E. Mannie, et. al., "GMPLS Extensions for SONET/SDH Control," 2002 Internet Draft, Work in Progress. 2004 13. B. Doshi, S. Dravida, P. Harshavardhana, et. al, "Optical 2005 Network Design and Restoration," Bell Labs Technical Journal, 2006 Jan-March, 1999. 2008 14. K. Kompella, et al., "Link Bundling in MPLS Traffic 2009 Engineering," Internet Draft, Work in Progress. 2011 15. S. Ramamurthy, Z. Bogdanowicz, S. Samieian, et al., "Capacity 2012 Performance of Dynamic Provisioning in Optical Networks", J. of 2013 Lightwave Technology, January, 2001. 2015 16. E. Crawley, R. Nair, B. Rajagopalan and H. Sandick, "A 2016 Framework for QoS-based Routing in the Internet," RFC 2386, 2017 August, 1998. 2019 17. D. Awduche, L. Berger, Der-Hwa Gan, T. Li, G. Swallow, V. 2020 Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC 2021 3209. 2023 18. J. Suurballe, "Disjoint Paths in a Network," Networks, vol. 4, 2024 1974. 2026 19. A. Chie et al., "Impairments And Other Constraints On Optical 2027 Layer Routing", Internet Draft, Work in Progress. 2029 13. Acknowledgments 2031 We would like to thank Zouheir Mansourati (Movaz Networks), Ian 2032 Duncan (Nortel Networks), Dimitri Papadimitriou (Alcatel), and 2033 Dimitrios Pendarakis (Tellium) for their contributions to this 2034 document. 2036 14. Author's Addresses 2038 Bala Rajagopalan James V. Luciani 2039 Debanjan Saha Crescent Networks 2040 Tellium, Inc. 900 Chelmsford St. 2041 2 Crescent Place Lowell, MA 01851 2042 P.O. Box 901 Email: jluciani@CrescentNetworks.com 2043 Oceanport, NJ 07757-0901 2044 Email: {braja, dsaha}@tellium.com 2046 Daniel O. Awduche Bilel Jamoussi 2047 Movaz Networks Nortel Networks 2048 7926 Jones Branch Dr. 600 Tech Park 2049 McLean, VA 22102 Billerica, MA 01821 2050 Phone: 703-298-5291 Phone: 978-288-4734 2051 Email: awduche@movaz.com Email: jamoussi @nortelnetworks.com 2053 Brad Cain 2054 Cereva Networks 2055 3 Network Dr. 2056 Marlborough, MA 01752 2057 Email: bcain@cereva.com