idnits 2.17.1 draft-chaudhuri-ip-olxc-control-00.txt: -(951): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1126): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1146): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 is more than 15 pages and seems to lack a Table of Contents. == There are 5 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 21) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 117 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 20 has weird spacing: '... at any ti...' == Line 23 has weird spacing: '... The list ...' == Line 31 has weird spacing: '... This docum...' == Line 35 has weird spacing: '... paving the ...' == Line 36 has weird spacing: '...fically inten...' == (112 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Sid Chaudhuri 2 Expires: August 2000 Gisli Hjalmtysson 3 Jennifer Yates 4 AT&T Labs - Research 6 Control of Lightpaths in an Optical Network 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document details requirements and mechanisms for optical 32 bandwidth management and restoration in a dynamically reconfigurable 33 optical network. A management approach is described where IP 34 algorithms and mechanisms are used to control optical resources, 35 paving the way for the optical Internet. The proposal is 36 specifically intended for optical internetworking in which IP 37 routers are connected by the reconfigurable optical layer using 38 lightpaths. However, it is assumed that the same methodology will 39 be used for non-IP traffic as well. 41 1. Introduction 43 This document describes an approach for optical bandwidth management 44 in a dynamically reconfigurarable optical network. The optical 45 network consists of optical layer cross-connects (OLXCs) that switch 46 high-speed optical signals (e.g. OC-48, OC-192) from input ports to 47 output ports. These OLXCs are interconnected via WDM links. The 48 OLXCs may be purely optical or electrical or a combination. The 50 Internet draft draft-chaudhuri-ip-olxc-control-00.txt Feb. 2000 52 network is assumed to be within a single domain of authority (or 53 trust), with the inter-domain capability to be addressed in a future 54 document. 56 Every node in the network consists of an IP router and an OLXC. 57 This document is only concerned with the functions of the router as 58 they relate to the control of the optical layer. In general, the 59 router may be traffic bearing as proposed in [1], or it may function 60 purely as a controller for the optical layer and carry no IP data 61 traffic. The node may be implemented using a stand-alone router 62 interfacing with the OLXC through a defined interface, or may be an 63 integrated system, in which the router is part of the OLXC system. 64 The policies and mechanisms proposed within this document for 65 optical bandwidth management and restoration are applicable whether 66 the router carries data or not. 68 In the networks considered, it is assumed that the physical hardware 69 is deployed, but that network connectivity is not defined until 70 lightpaths are established within the network. A lightpath is a 71 constant bit-rate data stream connected between two network elements 72 such as IP routers. An example is one direction of an OC-48/STM-16 73 (2.5 Gbit/s) or an OC-192/STM-64 (10 Gbit/s) established between two 74 client routers through the OLXCs with or without Multiplex / 75 regenerator Section Overhead termination. 77 Lightpaths may be requested by client IP aware network elements, or 78 by external operations systems used for IP-ignorant network 79 elements. Such requests may be for uni-directional or bi- 80 directional lightpaths of a given bandwidth and with specified 81 restoration requirements. The lightpaths are provisioned by 82 choosing a route through the network with sufficient available 83 capacity. The lightpath is established by allocating capacity on 84 each link along the chosen route, and appropriately configuring the 85 OLXCs. Restoration is provided by reserving capacity on routes that 86 are physically diverse to the primary lightpath. 88 This document is a contribution to the on-going discussion on the 89 provisioning and management of optical networks. Specifically, we 90 propose a framework for the management of optical layer resources 91 and restoration. We identify a set of services that we foresee 92 offered by an optical network, and derive the requirements on 93 functionality offered by the network. We define an addressing and 94 naming scheme, which is required to facilitate distributed 95 information maintenance, and separate the connectivity management 96 from higher levels concerns, such as global network and customer 97 management. The main part of the document specifies in detail the 98 mechanisms and information requirements for fast provisioning, 99 diverse routing and restoration. In this part, we discuss the state 100 required and the mechanisms for the maintenance of this state, and 101 propose a new model for restoration. 103 The approach proposed in this document complements that proposed by 104 Awduche et al. on Multi-Protocol Lambda Switching [2], which is 106 Internet draft draft-chaudhuri-ip-olxc-control-00.txt Feb. 2000 108 based on Multi-Protocol Label Switching (MPLS). While our proposal 109 does not require MPLS, it is consistent with the use of MPLS and 110 specifically of the signaling protocols proposed for MPLS [3,4]. As 111 such, this document is a contribution into the work on Multi- 112 Protocol Lambda Switching. The objective of our contribution is to 113 incorporate the optical layer requirements in the selection and 114 extension of the proposals under discussion. In this document we 115 illustrate how IP algorithms and mechanisms can be used to implement 116 these requirements. While our architectural assumptions are 117 congruent with those in [2], we analyze optical services and 118 networks in greater detail, thereby addressing some of the issues 119 raised in [2]. 121 Neither this document nor the proposal in [2] analyzes the 122 efficiency of network utilization with respect to a specific 123 protocol choice for provisioning and restoration. In addition to the 124 functional requirements advanced in this document we believe that 125 the capacity efficiency is an important issue to be considered in 126 developing the algorithms and protocols for lightpath provisioning 127 and restoration in the optical network. 129 The rest of the document is organized as follows. In Section 2 we 130 provide background and definitions needed for the rest of the 131 document. Section 3 provides a brief discussion of the network 132 architecture. In Section 4 we analyze network services and outline 133 how they translate into requirements for the optical layer 134 functionality. Naming and addressing are discussed in Section 5. 135 Sections 6 and 7 contain the embodiment of the implementation of the 136 requirements for provisioning and restoration at the optical layer. 137 Section 8 discusses periodic resource reconfiguration policies. 138 Sections 9, 10 and 11 specify in detail the information requirements 139 and interface primitives. 141 2. Background 143 In order to facilitate the discussion we define the following 144 network objects: 146 - Wavelength Division Multiplexer (WDM). A system which takes 147 multiple optical inputs, converts them into narrowly spaced 148 wavelength optical signals within an optical amplification band 149 and couples them onto a single fiber. The amplified signal is 150 received at the receive end, demultiplexed and converted to 151 multiple channels of standard wavelength to interface with other 152 equipment. It is, however, possible to take the wavelength 153 specific signals directly as the inputs. In that case no 154 wavelength conversion is necessary at the WDM system. The WDM 155 system may or may not be integrated with an OLXC. 157 - Channel. A channel is a uni-directional optical tributary 158 connecting two OLXCs. Multiple channels are multiplexed optically 159 at the WDM system. One direction of an OC-48/192 connecting two 160 immediately neighboring OLXCs is an example of a channel. A 162 Internet draft draft-chaudhuri-ip-olxc-control-00.txt Feb. 2000 164 single direction of an Optical channel (Och) as defined in ITU-T 165 G.872 [5] between two OLXCs over a WDM system is another example 166 of a channel. A channel can generally be associated with a 167 specific wavelength in the WDM system. However, with a WDM system 168 with transponders the interfaces to the OLXC would be a standard 169 single color (1310 or 1550 nm). In addition, a single wavelength 170 may transport multiple channels multiplexed in the time domain. 171 For example, an OC-192 signal on a fiber may carry four STS-48 172 channels. For these reasons we define a channel which is different 173 from wavelength although in many applications there is a one-to- 174 one correspondence. 176 - Optical layer cross-connect (OLXC). A switching element which 177 connects an optical channel from an input port to an output port. 178 These devices are also often referred to as optical cross-connects 179 (OXC). Note that an optical add-drop multiplexor (OADM) is viewed 180 here as a simple OLXC. The switching fabric in an OLXC may be 181 either electronic or optical. If the switching fabric is 182 electronic, then switching would occur at a given channel rate, 183 but the interface ports may in fact be at higher rates (i.e. 184 multiplex multiple channels onto a single wavelength). It is 185 important to note that because of the multiplexing function 186 assumed in the OLXC, we do not restrict the lightpaths to be 187 identical to the Och defined in ITU-T G.872 [2]. If the WDM 188 systems contain transponders or if electronic OLXCs are used, then 189 it is implied that a channel associated with a specific wavelength 190 in the WDM input can be converted to an output channel associated 191 with a different wavelength in the WDM output (i.e. wavelength 192 conversion is inherent). However, if the switching fabric is 193 optical and there is no transponder function in the WDM system, 194 then wavelength conversion is only implemented if optical to 195 electronic conversion is performed at the input or output ports, 196 or if optical wavelength converters are introduced to the OLXC. 197 Also, we assume that the rates in the input and output channels in 198 an all-optical OLXC are identical, implying that Time Division 199 Multiplexing (TDM) is not offered within the OLXC. 201 - Link. A link is a set of channels in a given direction connecting 202 a particular pair of OLXCs and routed along the same physical 203 route. Multiple links may exist between the same OLXCs, for 204 example if route diversity is implemented between two OLXCs. Note 205 that links defined this way are uni-directional. There can be 206 multiple WDMs within a link. A single WDM can be divided into 207 multiple links (i.e. between different OLXCs). The link is thus 208 not necessarily a union of WDMs, and there is not necessarily a 209 one-to-one correspondence between WDM systems and links. 211 - Fiber Span. A fiber span consists of a collection of fiber cables 212 that are located in the same conduit or right of way. If there is 213 a cut in the fiber span, then failures would potentially be 214 experienced on all fibers within the fiber span. 216 Internet draft draft-chaudhuri-ip-olxc-control-00.txt Feb. 2000 218 - Shared Risk Link Group (SRLG). For restoration and diverse routing 219 purposes it may be necessary to associate links within a fiber 220 span in a Shared Risk Link Group (SRLG). A SRLG is a union of all 221 links that ride on a fiber span. Links may traverse multiple 222 fiber spans, and thus be in multiple SRLGs. 224 - Drop Port. An OLXC port that connects to the end client network 225 element (NE). The drop interface connects the client port to the 226 OLXC drop port. This is essentially a User Network Interface (UNI) 227 connecting the end devices to the optical layer. The drop port 228 terminates the user network interface between the client NE and 229 the optical network. It is necessary to distinguish this type of 230 interface from others to identify network requests originating 231 from a client NE. 233 - Network Port. An OLXC port not directly interfacing with an end 234 client NE. A Network Port in an OLXC would always interface with 235 another Network Port via a WDM system or directly via optical 236 fibers. 238 - Lightpath. The elementary abstraction of optical layer 239 connectivity between two end points is a uni-directional 240 lightpath. A lightpath is a fixed bandwidth connection (e.g. one 241 direction of a STM-N/OC-M payload or an Och payload) between two 242 network elements established via the OLXCs. A bi-directional 243 lightpath consists of two associated lightpaths in opposite 244 directions routed over the same set of nodes. Note that if the 245 OLXC is an electronic SONET/SDH line terminating equipment, the 246 entire path need not be OC-48 for an OC-48 path. Note also that 247 an OC-N and Och are by definition bi-directional, whilst 248 lightpaths are by default uni-directional (anticipating asymmetric 249 loads). Therefore it is assumed that independent lightpaths in 250 opposite directions may use a bi-directional OC-48 or Och span. 252 - Source and Source Address. A source can be a client router 253 physically connected to an OLXC by one or more OC-48/192 254 interfaces. A source can also be a non-IP NE connected to the 255 OLXC via an OC-48/192 interface. In the case of an IP router 256 source, the router will have an IP address and the physical 257 interfaces to the OLXC are identified with some set of addresses 258 (potentially a single IP address, or a unique address per port). 259 In the case of a non-IP NE, either the NE will be assigned an IP 260 address, or the OLXC port connecting the NE will have an IP 261 address. For non-IP aware equipment interfacing the OLXC, any 262 connection request must be originated externally via craft or 263 external OS interfaces. 265 - Destination and Destination Address. The destination is 266 essentially the same as the source from the physical interface 267 perspective. When a request is generated from one end, the other 268 end client or end OLXC interface becomes the destination. 270 Internet draft draft-chaudhuri-ip-olxc-control-00.txt Feb. 2000 272 - First-hop router. The first router within the domain of concern 273 along the lightpath route. If the source is a router in the 274 network, it is also its own first-hop router. 276 - Last-hop router. The last router within the domain of concern 277 along the lightpath route. If the destination is a router in the 278 network, it is also its own last-hop router. 280 - Mediation device (MD). A vendor specific controller used to 281 control the OLXC. The mediation device provides the interface 282 between external sources and the OLXC, translating logical 283 primitives to and from the proprietary controls of the OLXC. If 284 the router is integrated with the OLXC, then the mediation device 285 is merely a function within the integrated entity, and not an 286 explicit device. 288 3. Network architecture 290 The salient feature of the network architecture is that every node 291 in the network consists of an IP router and a reconfigurable OLXC. 292 The IP router is responsible for all non-local management functions, 293 including the management of optical resources, configuration and 294 capacity management, addressing, routing, traffic engineering, 295 topology discovery, exception handling and restoration. In general, 296 the router may be traffic bearing as proposed in [1], or it may 297 function purely as a controller for the optical network and carry no 298 IP data traffic. The mechanisms and requirements discussed within 299 this document are applicable regardless of whether data traffic 300 traverses through the routers or not. Although the IP router 301 performs all management and control functions, lightpaths may carry 302 arbitrary types of traffic. 304 The IP router implements the necessary IP protocols and uses IP for 305 signaling to establish lightpaths. Specifically, optical resource 306 management requires resource availability per link to be propagated, 307 implying link state protocols such as OSPF. In subsequent 308 discussions we assume OSPF. However, other link state algorithms, 309 for example that used in PNNI [6], may be equally applicable. 311 On each link within the network, one channel is assigned as the 312 default routed (one hop) lightpath. The routed lightpath provides 313 router to router connectivity over this link. These routed 314 lightpaths reflect (and are thus identical to) the physical 315 topology. The assignment of this default lightpath is by 316 convention, e.g. the 'first' channel. All traffic using this 317 lightpath is IP traffic and is forwarded by the router. All control 318 messages are sent in-band on a routed lightpath as regular IP 319 datagrams, potentially mixed with other data but with the highest 320 forwarding priority. We assume multiple channels on each link, a 321 fraction of which is reserved at any given time for restoration. 322 The default routed lightpath is restored on one of these channels. 323 Therefore we can assume that as long as the link is functional, 324 there is a default routed lightpath on that link. 326 Internet draft draft-chaudhuri-ip-olxc-control-00.txt Feb. 2000 328 In resource constrained parts of the network, such as the link 329 connecting the customer premise to the network, it may not be 330 economically feasible to reserve a channel and the associated IP 331 interface for the default routed lightpath. Within the network, 332 where each link has multiple channels carrying traffic from many 333 customers, the overhead of the routed wavelength is amortized over 334 the channels on that link. In contrast, the link connecting the 335 customer premise to the network may typically have only a single 336 traffic bearing channel. In this case, unless the routed lightpath 337 is also used for IP data traffic, the overhead of an optical channel 338 dedicated for control may be excessive. If electronic line 339 terminating OLXCs are used, an alternative to dedicating an optical 340 channel as the routed lightpath is to transport the IP datagrams 341 within the framing overheads of the signals (e.g. SONET Multiplex 342 and/or Regenerator Section Overhead). 344 The IP router communicates with the OLXC mediation device (MD) 345 through a logical interface. The interface defines a set of basic 346 primitives to configure the OLXC, and to enable the OLXC to convey 347 information to the router. The mediation device translates the 348 logical primitives to and from the proprietary controls of the OLXC. 349 Ideally, this interface is both explicit and open. We recognize 350 that a particular realization may integrate the router and the OLXC 351 into a single box and use a proprietary interface implementation. 352 The crucial point is that this proprietary interface must still 353 provide equivalent functionality to the interface described herein. 355 Another interface of importance is the service interface between the 356 customers and the network. This interface determines the set of 357 services that the optical network provides. In Section 11 we 358 discuss this interface. 360 4. Optical Network Requirements 362 It is important to identify the services that an optical network 363 should offer, and the functionality that must be implemented by the 364 optical infrastructure to support these services. Within the same 365 domain of trust, servers and other network management systems may 366 have access to the network information available to routers, and may 367 actively interact with the network by requesting lightpaths. These 368 servers may for example provide authentication, risk analysis and 369 management, and more. While this document defines mechanisms that 370 would be used by these higher layer systems, the specifics of these 371 advanced services are not discussed herein. The following outlines 372 the optical network services and functionality. 374 4.1. Optical network services 376 Lightpath services. Lightpath requests between a source and 377 destination with the following attributes: 378 - Lightpath identifier. A globally unique identifier. 380 Internet draft draft-chaudhuri-ip-olxc-control-00.txt Feb. 2000 382 - Bandwidth: A limited set of bandwidth allocations are available 383 (e.g. OC-48, OC-192). 384 - Uni-directional or bi-directional lightpath. 385 - Diversely routed lightpath group identifier(s). A globally unique 386 group identifier defined for diversely routed lightpath groups 387 (see below). A convenient way to create one is by concatenating 388 the IP address of the first-hop router, and a sequence number 389 unique at the router. If the diversely routed lightpath group is 390 not coordinated by the first-hop router (see Section 6.3) but 391 instead by an external operations system, the address of the 392 coordinating entity would be used instead. 393 - Restoration class: one of (i) restored lightpath, (ii) restored IP 394 connectivity, (iii) not restored, (iv) not restored and 395 preemptable. For Class (i) the lightpath must be restored using 396 another lightpath, whose route is different from the primary. IP 397 restored (Class (ii)) assumes that the traffic transported on the 398 lightpath is IP, and may be restored by routing through the 399 network routers if needed and given that routing capacity is 400 available [1]. Clearly, the network will attempt to restore all 401 lost connectivity if and when possible. This is however done on a 402 best effort basis. 404 Diversely routed lightpath groups. A set of diversely routed non- 405 restored lightpaths so that for any single failure, at most a given 406 number of lightpaths out of the group fail. A lightpath belongs to 407 one or more diversely routed lightpath group(s). 409 The simplest form of diversely routed lightpaths is a group 410 originating at the same first hop router. This case is handled by 411 the first hop router. More generally, the lightpaths of a group may 412 potentially have different sources and destinations, and may be 413 required to satisfy other more stringent requirements, such as 414 ensuring that particular end-points are always connected. The 415 implementation of these more elaborate risk management services is 416 outside the scope of this document and would typically be provided 417 by higher level management system(s) external to the network nodes. 419 4.2. Requirements on optical network functionality 421 To cope with decreasing provisioning time scales, and to enhance 422 scalability, it is necessary to maintain the network state in a 423 distributed manner. This need drives most other system requirements 424 and implementation choices, and the service requirements above imply 425 the need for the following information and algorithms: 426 1) Information on topology and inventory of physical resources 427 (e.g. channels). 428 2) Information about shared risk link groups (SRLGs). This is 429 necessary for routing of restoration lightpaths, and for diverse 430 routing of primary lightpaths. 431 3) Information regarding the current resource allocations must be 432 propagated throughout the network. For scalability, details of 433 individual wavelength allocations are not distributed. 434 4) An addressing and naming scheme. 436 Internet draft draft-chaudhuri-ip-olxc-control-00.txt Feb. 2000 438 5) Algorithms for distributed state maintenance of the above. 439 6) Algorithms and mechanisms for the allocation of bandwidth 440 resources to new lightpaths, and for the reservation of 441 restoration capacity. These algorithms and mechanisms must be 442 able to support diversely routed lightpaths as described above. 443 7) Algorithms for the management and optimizations of resource 444 allocation; and the minimization of resources reserved for 445 restoration. Established lightpaths may occasionally be 446 reconfigured to optimize resource allocations. 447 8) Algorithms and mechanisms to ensure diversity in routes among a 448 set of lightpaths. 449 9) Algorithms and mechanisms for fault detection and recovery 450 (i.e., notification and exception handling). 451 10) Specification of interfaces between the external systems 452 (including client) and the network. 453 11) Specification of interfaces between the router and the OLXC 454 mediation device. 456 5. Naming and Addressing 458 Every network addressable element must have an IP address. 459 Typically these elements include each node and every optical link 460 and IP router port. When it is desirable to have the ability to 461 address individual optical channels those are assigned IP addresses 462 as well. The IP addresses must be globally unique if the element is 463 globally addressable. Otherwise domain unique addresses suffice. 465 Local naming schemes can be used to identify channels within fibers, 466 or to identify fibers within links. However, globally unique names 467 will be required to specify routes through the network. A possible 468 naming convention for uniquely identifying the channels used along a 469 route through a network is proposed. This convention identifies a 470 channel according to the OLXC from which it is sourced, the link 471 within the OLXC and the channel within the link. How these values 472 are used depends on what elements are assigned IP addresses. If 473 only the OLXC has a unique IP address, then the naming scheme uses a 474 pre-defined convention to identify links and channels within the 475 OLXC (i.e. OLXC IP address : link number : channel number). 476 Alternatively, if the link is also assigned an IP address, then the 477 channel is uniquely defined by the link IP address, and the channel 478 identifications within that link (i.e. link IP address : NULL 479 identifier : channel number). The NULL identifier is used to 480 indicate that a given field is invalid. For example, in the 481 identifier associated with the link IP address, the second field 482 contains a NULL identifier, which is used to indicate that a link 483 number is not required, because the IP address corresponds to a 484 unique link. Thus, the first non-NULL identifier can be used to 485 denote what the IP address corresponds to (i.e. OLXC or link). The 486 same applies for addresses assigned at finer granularities, e.g., 487 for each channel. Clearly, other variants on the above naming 488 scheme are possible. 490 Internet draft draft-chaudhuri-ip-olxc-control-00.txt Feb. 2000 492 A client must also have an IP address by which it is identified. 493 However, optical lightpaths could potentially be established between 494 devices that do not support IP (i.e. are not IP aware), and 495 consequently do not have IP addresses. This could be handled by 496 either assigning an IP address to the device, or alternatively 497 assigning an address to the OLXC port to which the device is 498 attached. Whether or not a client is IP aware can be discovered by 499 the network using traditional IP mechanisms. 501 6. Provisioning at the Optical Layer 503 6.1. Provisioning lightpaths in a network with wavelength converters 505 In an optical network with wavelength conversion, channel allocation 506 can be performed independently on different links along a route. 507 However, if wavelength converters are not available, then a common 508 wavelength must be located on each link along the entire route, 509 which requires some degree of coordination between different nodes 510 in choosing an appropriate wavelength. We commence this section by 511 outlining how lightpath provisioning may be performed in a network 512 with wavelength converters. Networks and sub-networks without 513 wavelength converters are considered in Section 6.5. 515 A lightpath request from a source is received by the first-hop 516 router. The first-hop router creates a lightpath setup message and 517 sends it towards the destination of the lightpath where it is 518 received by the last-hop router. If the originator of the request is 519 not the source, the originator tunnels the request to the first- hop 520 router. The lightpath setup is sent from the first-hop router on the 521 default routed lightpath as the payload of a normal IP packet with 522 router alert. A router alert ensures that the packet is processed 523 by every router in the path. A channel is allocated for the 524 lightpath on the downstream link at every node traversed by the 525 setup. The identifier of the allocated channel is written to the 526 setup message. If no channel is available on some link, the setup 527 fails, and a message is returned to the first-hop router informing 528 it that the lightpath cannot be established. We propose to use the 529 'destination not reachable' ICMP (Internet Control Messaging 530 Protocol) message for this, but any comparable mechanism would 531 suffice. For example, if all routers are MPLS capable one could use 532 the appropriate CR-LDP (Constraint-based Routing - Label 533 Distribution Protocol) message. If the setup fails, the first-hop 534 router issues a release message to release resources allocated for 535 the partially constructed lightpath. Upon failure, the first-hop 536 router may attempt to establish the lightpath over an alternate 537 route, before giving up on satisfying the original user request. 538 Note that the lightpath is established over the links traversed by 539 the lightpath setup packet. Moreover, when electronic line 540 terminating OLXCs are used it is possible to alternatively use the 541 channel overheads of the chosen lightpath channels to carry the 542 lightpath setup. After a channel has been allocated at a node, the 543 router communicates with the OLXC to reconfigure the OLXC to provide 544 the desired connectivity. 546 Internet draft draft-chaudhuri-ip-olxc-control-00.txt Feb. 2000 548 After processing the setup, the destination (or the last-hop router) 549 returns an acknowledgement to the source. The acknowledgment 550 indicates that a channel has been allocated on each hop of the 551 lightpath. It does not, however, confirm that the lightpath has been 552 successfully implemented (i.e. the OLXCs have been reconfigured). It 553 may be desirable to have the acknowledgement confirm that every hop 554 has completed the OLXC configuration. However, to verify that end- 555 to-end connectivity has been established requires that additional 556 mechanisms be implemented. These could for example be tandem 557 connection identification verification, as defined in ITU-T 558 SONET/SDH and OTN. Either way, the channel becomes available 559 immediately after the request is sent, at the discretion of the 560 user. Once established, the lightpath may carry arbitrary traffic, 561 such as ATM, Frame Relay or TDM circuit. 563 If the user requests a restored lightpath, then capacity must be 564 reserved within the network. This reserved capacity is shared over 565 multiple failures and only allocated (i.e., configured in the OLXC) 566 upon failure. The capacity reservation is performed independently of 567 the setup of the primary lightpath albeit perhaps simultaneously. 568 It may take a significantly longer time than the lightpath setup. 569 The first-hop router is responsible for ensuring that restoration 570 capacity is reserved for all restorable failures. The first-hop 571 router informs the source once this is completed. The establishment 572 of a restored lightpath is completed when the primary capacity is 573 allocated and the restoration capacity is reserved. 575 6.2. Softness of State 577 To simplify exception handling, all network state is assumed to be 578 soft unless otherwise stated. This applies in particular to 579 lightpath and restoration state. Soft state has an associated time- 580 to-live, and expires and may be discarded once that time is passed. 581 To avoid expiration the state must be periodically refreshed. To 582 reduce the overhead of the state maintenance, the expiration period 583 may be increased exponentially over time to a predefined maximum. 584 This way the longer a state has survived the fewer the number of 585 refresh messages that are required. 587 For lightpaths this implies that the source must periodically resend 588 the lightpath request. Similarly, the first-hop router must resend 589 the lightpath setup. If the state of a lightpath expires at a 590 particular node, the state is locally removed and all resources 591 allocated to the lightpath are reclaimed. 593 6.3. Lightpath Routing 595 To satisfy the requirements of diverse routing and restoration we 596 assert that it is necessary to use explicit routing for constructing 597 lightpaths. In addition, explicit routes may be valuable for traffic 598 engineering and load optimizations in the network. The route on 599 which a new lightpath is to be established is specified in the 601 Internet draft draft-chaudhuri-ip-olxc-control-00.txt Feb. 2000 603 lightpath setup message. This route would typically be chosen by 604 the first-hop router, but could be determined by a pre-authenticated 605 higher level network management system. Through routing protocols 606 the first-hop router has a representation of the full physical 607 network topology and the available resources on each link. These 608 are obtained and updated via OSPF link state advertisements. The 609 explicit route might be carried directly in the IP datagram using 610 the IP source route option, or might be carried in the packet 611 payload as would be the case if RSVP were used for signaling 612 lightpath requests. The route may be specified either as a series 613 of nodes (routers / OLXCs), or in terms of the specific links used 614 (as long as IP addresses are associated with these links). 616 Numerous policies can be used to route lightpaths through the 617 network, such as constraint-based routing algorithms. It is 618 expected that using a good routing algorithm will produce better 619 route selection and improve network resource utilization. 621 To ensure diversity in routes, each diversely routed lightpath group 622 is coordinated by a single network entity. To create a diversely 623 routed lightpath group, a user registers with a coordinator, and 624 receives the group identifier. For groups originating through the 625 same first-hop router, this router would typically act as the 626 coordinator. To ensure diversity in routes, K SRLG and node 627 disjoint routes through the network are selected, where K represents 628 the number of diverse routes required. The corresponding lightpaths 629 are then established independently. When a router receives a 630 diversely routed lightpath request coordinated by another network 631 entity, the router uses the address in the diversely routed 632 lightpath group identifier to retrieve the explicit route for the 633 new path from the coordinator. 635 6.4. Provisioning bi-directional lightpaths 637 The construction of a bi-directional lightpath differs from the 638 construction of a uni-directional lightpath above only in that upon 639 receiving the setup request, the last-hop router returns the setup 640 message using the reverse of the explicit route of the forward path. 641 Both directions of a bi-directional lightpath share the same 642 characteristics, i.e., set of nodes, bandwidth and restoration 643 requirements. For more general bi-directional connectivity, a user 644 simply requests multiple individual lightpaths. 646 6.5. Provisioning lightpaths in a (sub-)network without wavelength 647 converters 649 The provisioning techniques proposed earlier in this section apply 650 to optical networks with wavelength conversion. However, future 651 all-optical OLXCs may not have the ability to convert an incoming 652 wavelength to a different outgoing wavelength (i.e. do not implement 653 wavelength conversion). Such OLXCs may be used throughout an 654 optical network, or may be used in only some nodes, creating all- 655 optical sub-networks. Sections of a network that do not have 657 Internet draft draft-chaudhuri-ip-olxc-control-00.txt Feb. 2000 659 wavelength converters are thus referred to as being wavelength 660 continuous. A common wavelength must be chosen on each link along a 661 wavelength continuous section of a lightpath. Whatever wavelength is 662 chosen on the first link defines the wavelength allocation along the 663 rest of the section. A wavelength assignment algorithm must thus be 664 used to choose this wavelength. It is plausible, although unlikely, 665 that wavelength conversion could also be eliminated between the 666 client and the network. Wavelength selection within the network must 667 be performed within this subset of client wavelengths. 669 Optical non-linearities, chromatic dispersion, amplifier spontaneous 670 emission and other factors [7] together limit the scalability of an 671 all-optical network. Routing in such networks will then have to 672 take into account noise accumulation and dispersion to ensure that 673 lightpaths are established with adequate signal qualities. In the 674 following discussion we assume that the all-optical (sub-)network 675 considered is geographically constrained so that all routes will 676 have adequate signal quality, and physical layer attributes can be 677 ignored during routing and wavelength assignment. However, the 678 policies and mechanisms proposed here can be extended to account for 679 physical layer characteristics. 681 One approach to provisioning in a sub-network without wavelength 682 converters would be to propagate information throughout the network 683 about the state of every wavelength on every link in the network. 684 However, the state required and the overhead involved in maintaining 685 this information would be excessive. By not propagating 686 individual wavelength availability information around the network, 687 we must select a route and wavelength upon which to establish a new 688 lightpath, without detailed knowledge of wavelength availability. 690 We propose in this case to probe the network to determine an 691 appropriate wavelength choice. We use a probe message to determine 692 available wavelengths along wavelength continuous routes. A vector 693 of the same size as the number of wavelengths on the first link is 694 sent out to each node in turn along the desired route. This vector 695 represents wavelength availability, and is set at the first node to 696 the wavelength availability on the first link along the wavelength 697 continuous section. If a wavelength on a link is not available or 698 does not exist, then this is noted in the wavelength availability 699 vector (i.e. the wavelength is set to being unavailable). Once the 700 entire route has been traversed, the wavelength availability vector 701 will denote the wavelengths that are available on every link along 702 the route. The vector is returned to the source OLXC, and a 703 wavelength is chosen from amongst the available wavelengths using an 704 arbitrary wavelength assignment scheme, such as first-fit [8]. Note 705 that wavelength assignment is performed here using wavelength usage 706 information from only the links along the chosen route. Also, 707 multiple lightpaths can be simultaneously established using the same 708 wavelength availability information. 710 Alternative techniques can be used for selecting a wavelength, such 711 as attempting to establish a lightpath on successive wavelengths in 713 Internet draft draft-chaudhuri-ip-olxc-control-00.txt Feb. 2000 715 turn, or simultaneously attempting to allocate the lightpath on all 716 wavelengths that are available at the source. 718 The key point is that extensions of the provisioning techniques 719 proposed in this document for optical networks with wavelength 720 converters can be used to implement fast provisioning in networks 721 without wavelength converters, and that the two techniques can 722 interwork in a network with OLXCs with and without wavelength 723 conversion. 725 6.6. Lightpath removal 727 A lightpath must be removed when it is no longer required. To 728 achieve this, an explicit release request is sent by the first-hop 729 router along the lightpath route. Each router in the path processes 730 the release message by releasing the resources allocated to the 731 lightpath, and removing the associated state. It is worth noting 732 that the release message is an optimization and need not be sent 733 reliably, as if it is lost or never issued (e.g., due to customer 734 premise equipment failure) the softness of the lightpath state 735 ensures that it will eventually expire and be released. 737 7. Restoration plan 739 7.1. Restoration in a network with wavelength conversion 741 When a restored lightpath is requested, the primary lightpath is 742 established as described above, and the restoration capacity must be 743 reserved. The extent to which a network provider chooses to protect 744 the network depends on which failures can be recovered from. In 745 this discussion we assume that recovery is guaranteed for all 746 individual channel, link and single fiber span failures (i.e., links 747 in a common SRLG). Recovery from node or multiple fiber span 748 failures is not guaranteed. 750 There are three aspects to restoration: reservation of restoration 751 capacity, failure detection and exception handling. We treat each 752 of these separately, as discussed in the following. We propose a 753 distributed approach to the restoration management. 755 7.1.1. Failure detection and exception handling 757 We treat the handling of failures in an optical network as 758 equivalent to exception handling in advanced programming languages. 759 We equate failures to exceptions. When a component receives an 760 exception (at the lowest level detects a failure), it either handles 761 the exception or throws it up the chain of control. Locally, the 762 chain of control goes from the router to the OLXC. For a lightpath 763 the chain of control goes downstream through the routers. This 764 means that exceptions get thrown from the OLXC to the local router, 765 from there to the upstream router, and then recursively to the 766 router further upstream until the exception is handled. 768 Internet draft draft-chaudhuri-ip-olxc-control-00.txt Feb. 2000 770 This approach separates the mechanisms of exception propagation from 771 the policy of deciding who and how the exception is handled, 772 yielding great flexibility in the management of restoration 773 capacity. In general, each lightpath is recovered independently. 774 However, in some situations it may be desirable to handle multiple 775 exceptions as a single unit. For example, if a fiber is cut, all 776 channels may be restored in a single action. 778 It is worth stressing that restoration capacity is reserved, and not 779 allocated. The capacity reserved for restoration is therefore 780 shared and not dedicated to any particular lightpath. The 781 restoration capacity is either idle or is used for preemptable 782 lightpaths. The use of preemptable lightpaths enables the use of a 783 larger percentage of the total capacity albeit for secondary 784 services. This is particularly attractive for adaptable services, as 785 are common in the Internet, which would benefit from exploiting the 786 restoration capacity under normal operating conditions, but would 787 gracefully adapt to the reduction in capacity during failure. 789 Since restoration capacity is only reserved, handling the exception 790 translates into allocating the restoration lightpath on failure. 791 This requires efficient setup mechanisms for the construction and 792 allocation of the restoration lightpath to meet the tight 793 restoration timing constraints. Ideally the basic lightpath setup 794 would be suitable for this purpose. Otherwise a separate mechanism 795 must be devised for this purpose. In either case, we believe that 796 it is essential to pre-compute and store the restoration routes. 797 The advantage of using a fast lightpath setup is that a normal setup 798 would be issued from the exception handler, allowing all lightpath 799 specific state, specifically the restoration state, to be stored 800 only at the nodes traversed by the primary lightpath. This 801 significantly reduces the maintenance of the soft restoration state. 802 However, other considerations may dictate which mechanisms are used 803 for setting up the primary lightpath even if those mechanisms are 804 poorly suited for restoration. For example, the processing of 805 explicitly routed RSVP messages may be acceptable to setup primary 806 lightpaths, but appears too costly for meeting restoration timing 807 guarantees. To cope with this, the state for the restoration path 808 may be pre-established along the restoration route, leaving out only 809 the OLXC configuration. This way a simple allocation notification 810 (a touch message) along the restoration path is sufficient to 811 trigger the OLXC configuration. The notification can be forwarded 812 by the router before it is processed, thus avoiding accumulating the 813 processing overhead of each node, allowing for very rapid 814 restoration setup. Data can then be transmitted on the restoration 815 path immediately, with insignificant data loss. Such a router 816 notification is described in [9]. 818 Note that the lightpath establishment message must distinguish 819 between a restoration lightpath and a new lightpath request, so that 820 restoration lightpaths allocate resources out of the preemptable 821 capacity reserved for restoration. 823 Internet draft draft-chaudhuri-ip-olxc-control-00.txt Feb. 2000 825 7.1.2. Management and reservation of restoration capacity 827 The first-hop router selects the restoration route(s), and is 828 responsible for reserving restoration capacity. Numerous policies 829 may be used for determining the lightpath restoration routes. The 830 choice of a good restoration policy is a tradeoff between 831 simplicity, utilization and restoration speed. The simplest 832 approach is to restore only at the first-hop router using a single 833 end-to-end route completely SRLG and node disjoint from the primary 834 lightpath. Such a disjoint route is sufficient for all failures 835 along the primary route. Even if restoring only from the first-hop 836 router, it may be preferable to use different restoration routes 837 depending on which hop of the primary lightpath failed. However for 838 longer lightpaths the delay in exception propagation from the point 839 of failure to the first-hop router may be too excessive, and thus it 840 may be desirable to perform the restoration (handle the exception) 841 at intermediate nodes along the path. The mechanisms above support 842 all of these options. 844 The first-hop router stores all of the restoration routes for which 845 it is responsible (i.e. for which it is the first hop of the primary 846 lightpath) and calculates the total restoration resources required 847 for these routes on each link in the network and for each different 848 link failure, taking into account risk groups and available 849 resources. This calculation can be performed on-line using a greedy 850 algorithm, thus optimizing the choice of restoration routes 851 conditional on the existing lightpath allocations and reserved 852 restoration capacity. Restoration capacity is reserved on a link 853 for the failure of each single SRLG within the network. Thus, the 854 number of lightpaths that use a given link for restoration will 855 differ depending on which SRLG failure is considered. Restoration 856 resources on a given link must thus be independently reserved for 857 each different link failure within the network. The resources 858 required by a first-hop router, s, on a given link, l, for 859 restoration of a failed link i is denoted here by r[s][i](l). The 860 r[s][i](l) values are transmitted to the links (l) at regular 861 intervals and when restoration resource requirements are altered 862 (i.e. for each arriving and departing restored lightpath). In a 863 network with L links, this requires that O(L) values be transmitted 864 to link l from first-hop router s. The resources reserved on a link 865 for restoration are stored locally at that link. This implies the 866 equivalent of storing a two dimensional array of information for 867 each link l which documents the number of channels reserved at link 868 l for each first-hop router and every possible link failure (i.e. 869 requires that O(NL) values be stored, where N is the number of nodes 870 / sources, and L is the number of links in the network). The total 871 number of resources reserved on link l for restoration is the 872 maximum over all possible fiber span failures (risk groups) of the 873 sum over all first-hop nodes of restoration resources required on 874 each link within the risk group. 876 Once restoration routes have been determined, a restoration 877 reservation message (in IP packets) is sent to reserve the 879 Internet draft draft-chaudhuri-ip-olxc-control-00.txt Feb. 2000 881 restoration capacity on the links along the chosen routes. This is 882 performed in a manner similar to lightpath allocations using 883 explicit routing, with the difference that while capacity is 884 reserved, the OLXCs are not reconfigured. Instead, counts of 885 reserved restoration capacity are updated at each of the links along 886 the route. 888 As long as provisioning time-scales remain long, it is alternatively 889 viable to do restoration management in a centralized fashion, where 890 a centralized Risk Management Center assumes the responsibility for 891 selecting and maintaining restoration routes. This center would 892 subscribe to routing updates but would in addition need to be 893 informed about the routes used for every lightpath established 894 within the network. This last part becomes infeasible as time- 895 scales shrink. 897 7.1.3. Repair and return to primary lightpaths 899 Once a failed link or resource has been repaired, the restoration 900 lightpath is released and the lightpath is restored on the original 901 route. This responsibility is also delegated to the first-hop 902 router, which periodically repeats the original lightpath request 903 until it succeeds. For extended outages, the first-hop router may 904 eventually give up on the primary path, and compute and allocate a 905 new restorable primary route. Reverting back to the primary 906 lightpath route after a failure requires that this capacity remain 907 allocated during the time that the lightpath uses the restoration 908 capacity. The proposal here assumes soft connection states, so that 909 if a lightpath refresh is not periodically received for an 910 established lightpath, then its capacity will be de-allocated. This 911 causes a problem in that these refresh messages will not be received 912 along a primary route downstream of the failure. An explicit 913 notification to the closest node downstream of the failure is needed 914 to temporarily reduce the available capacity to ensure that this 915 capacity is not allocated to new lightpaths during the failure. 917 7.2. Restoration in a network without wavelength converters 919 End-to-end restoration is proposed for all-optical networks or sub- 920 networks. If no wavelength conversion is used in the network and on 921 the client / network interface, then the same wavelength will be 922 required for the primary and restoration lightpaths if the client 923 cannot retune its wavelength on failure. Whether or not the client 924 can provide this retuning can be passed as a parameter in the 925 lightpath request. 927 Wavelength selection on the primary and restoration lightpaths 928 should be simultaneously performed if the same wavelength is 929 required on both of these lightpaths. This requires that the 930 wavelengths available on both of the lightpaths be returned to the 931 first-hop router, and a decision made before either lightpath is 932 established. It also requires that specific wavelengths be reserved 933 for restoration at each node, significantly increasing the state 935 Internet draft draft-chaudhuri-ip-olxc-control-00.txt Feb. 2000 937 information required. The issue becomes even more complex in a 938 hybrid transparent and opaque OLXC environment. However, we believe 939 that we should focus on opaque OLXC environment on the first phase 940 while keeping in mind that in the future it may be required to 941 incorporate transparent and mixed optical networks. 943 8. Network reconfiguration 945 The above proposal performs the calculation of primary and 946 restoration lightpath routes on-line as the individual requests 947 arrive. The lightpath routes are thus chosen conditional on the 948 existing lightpath allocations. A more optimal set of lightpath 949 routes could be calculated off-line, with all of the requests known 950 and their routes simultaneously calculated. However, as the 951 lightpaths vary over time, the implementation of the �optimal� route 952 choices would likely result in the reconfiguration of lightpath 953 routes being required. Although a large number of lightpath 954 reconfigurations may not be acceptable, it is possible that a 955 limited number of lightpath reconfigurations could dramatically 956 improve the network state, freeing up resources for future lightpath 957 allocations. 959 For restored lightpaths, rerouting would generally have to be 960 performed within the time limits set for restoration. The lightpath 961 allocation schemes would either be fast enough to make this 962 achievable, or additional mechanisms would be employed to hide the 963 delay in lightpath construction. The number of reconfigurations 964 that a given lightpath experiences should be limited, to ensure that 965 lightpaths don�t suffer a constant route fluttering. Lightpath 966 reconfigurations should also be confined only to those lightpaths 967 that are rearrangeable (as identified in the lightpath requests). 969 9. Resource discovery and maintenance 971 Topology information is distributed and maintained using standard 972 routing algorithms. On boot, each network node goes through 973 neighbor discovery. By combining neighbor discovery with local 974 configuration, each node creates an inventory of local resources and 975 resource hierarchies, namely: channels, channel capacity, 976 wavelengths, links and SRLGs. 978 We expect that most of these parameters would be automatically 979 discovered. However, some parameters, such as the SRLG information, 980 may need to be inserted by external means. Once the local inventory 981 is constructed, the node engages in the routing protocol. 983 9.1. Information requirements 985 The following information should be stored at each node and must be 986 propagated throughout the network as OSPF link-state information: 987 - Representation of the current network topology and the link states 988 (which will reflect the wavelength availability). This can be 990 Internet draft draft-chaudhuri-ip-olxc-control-00.txt Feb. 2000 992 achieved by associating the following information with the link 993 state: 994 - total number of active channels (note that if a laser fails, for 995 example, then the channels using this laser become inactive, and 996 are not counted in the total number of active channels) 997 - number of allocated channels (non-preemptable) 998 - number of allocated preemptable channels 999 - number of reserved restoration channels (maximum allocated over 1000 all potential SRLG failures within the network) 1001 - Risk groups throughout the network (i.e. which links share risk 1002 groups) 1003 - Optional physical layer parameters for each link. These 1004 parameters are not expected to be required in a network with 3R 1005 signal regeneration, but may be used in all-optical networks. 1007 All of the above information is obtained via OSPF updates, and is 1008 propagated throughout the network. Note that we do not inform nodes 1009 of which channels are available on a link. Thus, in networks with 1010 OLXCs without wavelength converters, decisions at the first-hop 1011 router are made without knowledge of wavelength availability. This 1012 is done to reduce the state information that needs to be propagated 1013 within the network. 1015 In addition to this, extra information would be stored locally 1016 (i.e., in the router), including the following list (note that this 1017 is not exhaustive): 1018 - IP routing tables 1019 - Additional routing table information containing currently active 1020 lightpaths passing through, sourced or destined to this node and 1021 the channels that they are allocated 1022 - For each link exiting the OLXC: 1023 - total capacity (number of channels and their bandwidth) 1024 - available capacity 1025 - preemptable capacity 1026 - number of channels reserved for restoration on this link for 1027 each potential link failure within the network and for each 1028 first-hop router (if distributed restoration capacity 1029 calculations are being done). Thus, if there are L links within 1030 the network and N nodes, then there are must be L.N unique 1031 values stored here. 1032 - association between channels and fibers / wavelengths. This is 1033 particularly important for OLXCs without wavelength converters 1034 and for OLXCs in which lower rate channels are multiplexed onto 1035 a common higher rate channel on a common fiber (e.g. four OC-48s 1036 multiplexed onto a single OC-192 for transmission). 1037 - The first-hop router maintains for each client: 1038 - client identification 1039 - associated lightpath IDs for every established lightpath for 1040 this client 1041 - set of primary and restoration routes associated with each 1042 lightpath ID 1044 Internet draft draft-chaudhuri-ip-olxc-control-00.txt Feb. 2000 1046 10. Attributes for a lightpath request 1048 The information conveyed in a client request for lightpath 1049 connectivity should include the following parameters: 1050 - globally unique lightpath identifier 1051 - diversely routed lightpath group identifier(s) 1052 - destination address 1053 - source address 1054 - bandwidth requirements (e.g. OC48 or OC192) 1055 - uni-directional / bi-directional 1056 - security object � for authentication 1057 - restoration class: one of (i) restored lightpath, (ii) restored IP 1058 connectivity, (iii) not restored, (iv) not restored and 1059 preemptable. For Class (i) the lightpath must be restored using 1060 another lightpath. IP restored (Class (ii)) assumes that the 1061 traffic transported on the lightpath is IP, and may be restored by 1062 routing through the network routers if needed and given that 1063 routing capacity is available [1]. 1064 - wavelength rearrangeability (optional parameter required only for 1065 client / network interfaces without wavelength conversion). 1067 Note that the unique lightpath identifier can be assigned by the 1068 customer when the lightpath is requested, or can be assigned by the 1069 network once the lightpath has been established. 1071 11. Interface primitives for IP router and OLXC 1073 We propose the following interface primitives for communication 1074 between the router and the OLXC within a node. 1075 - connect(input link, input channel, output link, output channel): 1076 commands sent from the router to the OLXC requesting that the OLXC 1077 cross-connect input channel on the input link to the output 1078 channel on the output link. Note that one end of the connection 1079 can also be a drop port. This is true for the following connection 1080 primitives as well. 1081 - disconnect(input link, input channel, output link, output 1082 channel): command sent from the router to the OLXC requesting that 1083 it disconnect the output channel on the output link from the 1084 connected input channel on the input link. 1085 - bridge(input link, input channel, output link, output channel): 1086 command sent from the router controller to the OLXC requesting the 1087 bridging of a connected input channel on input link to another 1088 output channel on output link. 1089 - switch(old input link, old input channel, new input link, new 1090 input channel, output link, output channel): switch output port 1091 from the currently connected input channel on the input link to 1092 the new input channel on the new input link. The switch primitive 1093 is equivalent to atomically implementing a disconnect(old input 1094 channel, old input link, output channel, output link) followed by 1095 a connect(new input link, new input channel, output link, output 1096 channel). 1098 Internet draft draft-chaudhuri-ip-olxc-control-00.txt Feb. 2000 1100 - alarm(exception, object): command sent from the OLXC to the router 1101 informing it of a failure detected by the OLXC. The object 1102 represents the element for which the failure has been detected. 1104 Note that IP packets are also passed by the OLXC to the router in 1105 the network when the control packets from clients are transmitted 1106 within the framing overheads. 1108 12. Summary 1110 This document outlined how IP algorithms and mechanisms can be used 1111 as the basis for a control plane for an optical network. This 1112 contribution provides the optical layer requirements that can be the 1113 basis for the selection and extension of the proposals on algorithms 1114 and protocols. The document illustrated how optical lightpath 1115 management, and particularly rapid lightpath provisioning and 1116 restoration can be implemented using IP control. 1118 13. Acknowledgments 1120 The authors wish to thank John Strand, Albert Greenberg, Bob Tkach, 1121 Bob Doverspike, Evan Goldstein and Jerry Ash for their contributions 1122 to this proposal. 1124 14. References 1126 [1] A. Greenberg, G. Hj�lmt�sson and J. Yates, "Smart Routers � Simple 1127 Optics: A Network Architecture for IP over WDM," accepted for 1128 publication at OFC 2000. 1129 [2] D. Awduche, Y. Rekhter, J. Drake, R. Coltun, "Multi-Protocol 1130 Lambda Switching: Combining MPLS Traffic Engineering Control with 1131 Optical Crossconnects," IETF Internet draft. 1132 [3] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, and V. 1133 Srinivasan, "Extensions to RSVP for LSP Tunnels," IETF Internet Draft, 1134 Work in Progress, 1999. 1135 [4] B. Jamoussi et al, "Constraint-Based LSP Setup using LDP," IETF 1136 Internet Draft, Work in Progress, 1999. 1137 [5] ITU-T G.872, "Architecture for Optical Transport Networks," 1999. 1138 [6] ATM Forum, "Private Network-Network Interface Specification: 1139 Version 1.0," March 1996. 1140 [7] R. Tkach, E. Goldstein, J. Nagel and J. Strand, "Fundamental 1141 Limits of Optical Transparency," Optical Fiber Communication Conf., pp. 1142 161-162, Feb. 1998. 1143 [8] I. Chlamtac, A. Ganz and G. Karmi, "Lightpath Communications: An 1144 Approach to High Bandwidth Optical WANs," IEEE Trans. On Comms., vol. 1145 40, pp. 1171-1182, July 1992. 1146 [9] G. Hj�lmt�sson, "IPv6 Courtesy-Copy Extension Headers," IETF 1147 Internet Draft.