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