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