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