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