Internet Draft Nasir Ghani Expiration: September 2001 James Fu Dan Guo Xinyi Liu Zhensheng Zhang Sorrento Networks Paul Bonenfant Leah Zhang Antonio Rodriguez Moral Murali Krishnaswamy Xiaowen Mang Photuris Sudheer Dharanikota Raj Jain Nayna Networks Architectural Framework for Automatic Protection Provisioning In Dynamic Optical Rings draft-ghani-optical-rings-01.txt Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups ay also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract Given the large installed base of ring fiber-plants and the extensive experience operators have gained in operating SONET (SDH) ring networks, optical rings are becoming increasingly important. As such, optical rings will play a crucial role in the migration from existing TDM-based SONET (SDH) architectures to more dynamic lightpath provisioning paradigms. To date, various optical ring concepts have been tabled, proposing multi-services support and mirroring the fast protection switching capabilities of existing SONET (SDH) rings. Nevertheless, the emerging IP-based MPL(ambda)S framework for optical networks is largely based upon (optical) mesh routing concepts. Clearly, there is a strong need to formalize a more comprehensive architectural framework for dynamic optical rings and ensure their integration within the emerging MPL(ambda)S architecture. Along these lines, the various optical ring schemes are summarized and associated MPL(ambda)S interworking concerns detailed. Table of Contents 1 Introduction ................................................ 3 2 Framework for Optical Rings ................................. 6 2.1 Dedicated Path Protection Rings (DPRING) ............... 8 2.2 Shared Protection Rings (SPRING) ...................... 10 2.2.1 OMS-Shared Protection Ring (OMS-SPRING)............ 10 2.2.2 OCh-Shared Protection Ring (OCh-SPRING)............ 12 2.3 Signaling Channel Considerations ...................... 16 2.4 Fault Detection and Isolation ......................... 16 3 Dynamic Provisioning Issues ................................ 18 3.1 Channel Setup Requirements ............................ 19 3.1.1 Signaling Extensions .............................. 19 3.1.2 Resource and State Dissemination .................. 22 3.1.3 Constraint-Based Routing/Path Computation ......... 22 3.2 Protection Signaling .................................. 23 3.2.1 Direct Interworking ............................... 24 3.2.2 O-APS Protocol .................................... 27 3.2.3 Multi-Layer Escalation Strategies ................. 28 3.3 Additional Considerations ............................. 30 3.3.1 Multi-Ring Provisioning ........................... 30 3.3.2 Mesh-Ring Interworking ............................ 30 3.3.3 Sub-Rate Tributary Rings .......................... 30 3.3.4 Resilient Packet Ring Synergies ................... 30 4 Appendix A: Review of SONET Ring Architectures ............. 31 4.1 Uni-directional Path-Switched Rings (UPSR) ............ 31 4.2 Bi-directional Line-Switched Rings (BLSR) ............. 31 5 Security Considerations .................................... 31 6 References ................................................. 31 7 Authors Information ........................................ 34 8 Full Copyright Notice ...................................... 35 List of Acronyms ADM: Add-drop multiplexer APS: Automatic protection switching AS: Autonomous system (routing domain) BER: Bit error rate BLSR: Bi-directional line-switched ring BPSR: Bi-directional path-switched ring COPS: Common open policy service CR-LDP: Constraint-routing label distribution protocol DPRING: Dedicated protection ring DWDM: Dense wavelength division multiplexing EXC: Electronic cross-connect (electronic cross-point switch) FIS: Failure indication signal FRS: Failure recovery signal GMPLS: Generalized multi-protocol label switching IED: Integrated edge device IGP: Interior gateway protocol ILM: Incoming label map IPoRPR: IP over resilient packet ring LMP: Link management protocol LOF: Loss of framing LOS: Loss of signal LSA: Link state attribute LSP: Label switched path LSR: Label switch router (also lambda switch router) MEMS: Micro-electro-mechanical systems MPLS: Multi-protocol label switching NHLFE: Next-hop label forwarding entry NMS: Network management system NNI: Network-to-network interface O-ADM: Optical add-drop multiplexer O-BLSR: Optical bi-directional line-switched rings O-BPSR: Optical bi-directional path-switched rings OCh: Optical channel OMS: Optical multiplex section OSC: Optical supervisory channel OSPF: Open shortest path first protocol OXC: Optical cross-connect switch PDH: Plesiochronous digital hierarchy PML: Protection merge LSR PMTG: Protected MPLS traffic group PSL: Protection switch LSR RNT: Reverse notification tree RPR: Resilient packet ring RSVP: Resource reservation protocol RWA: Routing and wavelength assignment SDH: Synchronous digital hierarchy SHR: Self-healing ring SNC: Sub-network connection SPRING: Shared protection ring SONET: Synchronous optical network SRLG: Shared risk link group TCP: Transport control protocol TDM: Time division multiplexing TLV: Type length value (field) UNI: User network interface VPOR: Virtual private optical ring UPSR: Uni-directional path-switched ring WDM: Wavelength division multiplexing WRS: Wavelength-routing switch 1. Introduction Many networks today are based upon fiber-ring architectures, as evidenced by the proliferation of multi-level SONET (SDH) rings, especially in metropolitan and regional areas. For example, at the access-side, smaller OC-3 (155 Mb/s) tributary rings are used to aggregate and groom traffic from enterprise customers. These rings are then connected to larger granularity OC-12 (622 Mb/s) and possibly OC-48 (2.5 Gb/s) rings spanning larger metropolitan distances. Metropolitan rings are then used to feed into even larger regional (and possibly long-haul) fiber-ring topologies with increased bit rates, such as OC-192 (10 Gb/s). As a result, ring architectures will clearly play a major role in the evolution of optical network architectures. Given this large, entrenched base of ring topologies, currently many operators are planning for a migration to equivalent dynamic optical ring architectures. Dynamic optical rings can be defined as fiber rings with dynamic lightpath provisioning capabilities (such as routing, add/drop, and protection). These optical wavelength routing rings, commonly also referred to as optical add-drop ring multiplexer (O-ADM) rings, will form the mainstay architecture for most metro and regional networks and will help operators ease their transition to future optical (mesh) networks. Since many operators have significant experience in deploying and maintaining TDM rings (i.e., SONET/SDH), such optical analogs of time-division multiplexing (TDM) ring switching are of great transitional value. Here, wavelength channels (as opposed to TDM circuits) undergo bypass, add, or drop operations at O-ADM network elements [MARCENAC]. O-ADM rings will allow operators to immediately leverage their current fiber topologies and avoid lengthy fiber-expansion costs (i.e., associated with deploying mesh networks). Furthermore, ring architectures are well-known for their inherently fast protection switching capabilities, and perhaps, this is the main reason for the widescale acceptance of SONET technology (i.e., TDM rings). Network operators have become well- accustomed to the fast, timely recovery capabilities provided by SONET automatic protection switching (APS) schemes, such as uni-directional path switched rings (UPSR) and bi-directional line switched rings (BLSR) [GR1230]. These architectures can achieve service recovery within 50 ms after a fault event, via detailed electronic frame monitoring and fast (protection) switchover signaling provisions. Meanwhile, recently there have also been significant developments in extending the ubiquitous multi-protocol label switching (MPLS) framework to the optical networking domain, namely "IP over optical" via MPL(ambda)S [AWDUCHE],[GHANI1],[RAJAGOPALAN] and more recently, generalized MPLS (GMPLS) [ASHWOOD],[XU]. Nevertheless, given its origins from (mesh) IP packet routing networks, this framework as it stands today, is largely geared to support dynamic optical mesh networks. Conversely, no standards exist for O-ADM rings and most offerings do not provide dynamic channel routing (add-drop) capabilities, relying instead upon proprietary, static solutions. Now given the abundance and strategic importance of ring fiber-plants (as detailed above), it is crucial to extend the existing MPL(ambda)S framework to provision dynamic optical ring networks. Although some may state that rings are special cases of meshes (technically speaking), the various intricacies of ring networks require special attention in the MPL(ambda)S framework. As most long- haul optical networks continue to migrate towards mesh-based MPL(ambda)S setups, along with increasingly MPLS-based "client" router networks, intermediate metro/regional networks (largely ring-based) must also evolve to a similar "IP-based" architecture. Such a uniform provisioning framework will permit true optical services provisioning across all network/geographic domains. In particular, the MPL(ambda)S framework must address ring channel provisioning and protection switching functions. Undoubtedly, optical (ring) solutions must provide equivalent, or improved, capabilities in order to replace TDM rings in a timely manner. Since each fiber (or wavelength) in an optical network can now carry a much higher degree of multiplexed traffic, APS capabilities are even more crucial. This report details an architectural framework for O-ADM rings, representing a logical, structured evolution (expansion) from existing SONET (TDM) ring paradigms. Optical ring equivalents of SONET protection schemes are presented and detailed provisioning issues outlined within the context of the broader MPL(ambda)S/GMPLS framework. 2. Framework for Optical Rings Many of the proposed concepts in optical ring networks derive their origins from those in SONET/SDH ring networks. Here it is assumed that readers are familiar with basic SONET/SDH constructs, albeit a brief introduction is presented in the Appendix (Section 4). Due to the inherent transparency of optical switching technologies, optical rings can develop significantly on existing TDM SONET rings. Namely, the concept of "transparent" optical rings is envisioned, permitting a full range of protocols/bit-streams being carried in their native format, e.g., ATM, IP, ESCON, Gigabit Ethernet, etc. Fundamentally optical ring network elements must perform the optical "equivalents" of TDM ADM channel operations: pass-through, add, drop, and fast APS functions [ARIJIS],[MARCENAC]. Expectedly, "active" operations are implied here, otherwise the principles of dynamic wavelength provisioning, and hence MPL(ambda)S, are largely inapplicable. Specifically, TDM circuit/ timeslots are now replaced by wavelength-based lightpath entities. These requirements can be met by either using optical add-drop multiplexer (O-ADM) or optical cross-connect (OXC)/wavelength routing switch (WRS) devices. The latter types are well-suited to larger inter-ring connection applications, which require added (mesh) spatial switching capabilities. _ +------------+ _ Demux / |----->| |----->| \ Mux W-E in >----+ |----->| |----->| +----> W-E out \_|----->| Lambda |----->|_/ _ | pass-thru/ | _ Mux / |<-----| protection |<-----| \ Demux E-W out <----+ |<-----| |<-----| +----< E-W in \_|<-----| |<-----|_/ +------------+ | | | ^ ^ ^ -- Optional O-E conv. | | | | | | (wavelength transponders, v v v | | | possible SONET/digital +------------+ wrappers monitoring) ---->| Wavelength |----> From client nodes ---->| channel |----> To client nodes ---->| add/drop |----> +------------+ Figure 1: Sample optical add-drop multiplexer (O-ADM) node (2-fiber) A generic overview of a two-fiber O-ADM device is shown in Figure 1 and can easily be extended for four-fiber rings. Optical demux (mux) devices split (combine) wavelength channels (wavelength bands) from incoming (outgoing) fibers and connect to a wavelength channel (band) add/drop/protection unit. This stage can be implemented using a variety of techniques, such as optical switches (e.g., micro-electro- mechanical systems (MEMS), bubble, thermo-optic, etc), electronic cross-point switches (EXC), or simpler 2x1 switching devices. The add/ drop channels help to form the access stage of an O-ADM and this is where signals are mapped/de-mapped onto/from wavelength transmitters/ receivers. Optionally, O-E designs can perform edge SONET (or digital wrappers) payload mapping at the access stage. Overall, O-ADM devices can exhibit different levels of functionality. For example, purely optical add-drop/switching fabrics are incapable of wavelength conversion unlike designs based upon opto-electronic (O-E) conversion techniques. Also, hybrid designs can offer partial wavelength conversion for selected wavelengths and/or links (as illustrated in Figure 1). It is important to define an O-APS framework that encompasses all (or as many of) these possibilities. To date, the T1X1 forum has been most active with regards to proposals for optical ring architectures, see [CHEN],[CVIJETIC1-2],[SOULLIERE]. Although this work is currently on the T1X1 living list and represents a good starting point, detailed standards (comparable to SONET UPSR, BLSR) are yet to emerge. Overall, optical ring proposals are classified into two major types, namely dedicated protection rings (DPRING) and shared protection rings (SPRING), and this delineation is re-used here to define the conceptual framework. More specific provisioning (signaling) requirements are treated in the subsequent sections. Note that the terms channel and lightpath are used interchangeably to represent wavelength circuits. Others have proposed further classifications for lightpaths with or without wavelength conversion, namely virtual wavelength path (VWP) and wavelength path (WP) concepts, respectively. However, herein the term lightpath (channel) is used to generically refer to both entities. Furthermore, the prefix "O" is used to identify all optical ring concepts, in order to clearly discern from existing TDM ring (SONET) schemes. 2.1 Dedicated Path Protection Rings (DPRING) Dedicated protection rings are relatively simple in design and usually associated with two-fiber uni-directional (path-switched) O-ADM rings, O-UPSR/2. These rings can implement "edge-to-edge" wavelength channel protection, and are therefore more commonly termed as optical channel DPRING (OCh-DPRING) [ARIJIS]. Note that the term "edge-to-edge" is chosen here, referring to a "sub-network" connection (SNC) entity, since it most germane to a single ring (domain) and not necessarily a complete "end-to-end" client connection, see [XUE]. Both the 1+1 (non-signaled) and 1:1 (signaled) protection switching paradigms can be used herein. Each fiber in a OCh-DPRING carries wavelength channels in counter-propagating directions, with one fiber each for working and protection channels. The 1+1 OCh-DPRING solution is similar to SONET UPSR rings, where bi-directional connections consume wavelength resources on all fibers, i.e., head-end bridging. This OCh-DPRING scheme is shown in Figure 2 for a uni-directional channel. Note that an all-optical OCh-DPRING will likely require the same wavelength value on the working and protection path (i.e., unless ingress traffic bridging is done onto two separate wavelength transponders). Since receiver-based switchovers can be done, no complex signaling protocols are required for 1+1 optical protection. However, there is normally an added power penalty, about 3 dB, when performing head-end bridging [SOULLIERE]. Node A Node B +--------+ +--------+ ******************************************* | | # | | * | | # |------------------| * | +------#-+ +------*-+ | # ** Working | * | # ## Protection | * | # (permanently | X<--Fiber | # bridged) | * cut | # | * +------#-+ +------*-+ | ############################*****> A-D | | | | | |------------------| | +--------+ +--------+ Node C Node D Figure 2: 1+1 wavelength path protection (2-fiber OCh-DPRING) Additionally, signaled 1:1 protection can also be implemented in the OCh-DPRING, essentially re-using protection wavelengths for lower- priority traffic, i.e., head-end switching [SOULLIERE]. This requires an optical APS signaling protocol (yet to be specified). Although 1:1 channel protection improves upon idle resource utilization, it still has limited spatial wavelength re-use and is rather disruptive (i.e., full ring/path switch can affect many users, albeit lower pre-emptable priority). The 1:1 OCh-DPRING structure is shown in Figure 3, where the lower-priority lightpath C-D occupies a protection wavelength/span for lightpath A-D. Conceivably, both 1+1 and 1:1 OCh-DPRING mechanisms can coexist simultaneously on the same two-fiber ring, since they utilize the same underlying fiber/wavelength plan. Overall, however, signaled protection is mostly proposed for more advanced bi-directional (line, path) ring architectures, Section 2.2. Node A Node B +--------+ +--------+ ******************************************* | | # | | * | | # | | * | | # |------------------| * | +------#-+ +------*-+ | # ** Working | * | # ## Path | * | # @@ Low Priority | X<--Fiber | # (pre-emptable) | * cut | # | * +------#-+ +------*-+ | ############################*****> A-D @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@> C-D | | | | | |------------------| | +--------+ +--------+ Node C Node D Figure 3: 1:1 wavelength path protection (2-fiber OCh-DPRING) Note that depending upon the O-ADM node's fault detection mechanism, switchover signaling can be actuated using a variety of methods (see Section 2.4, Section 3.2). For example, for translucent designs using SONET framing, B1-byte (inband overhead) monitoring can be done to detect progressive signal degradation. Alternatively, for transparent optical rings, optical monitoring techniques (such as power or signal-to-noise ratios) can be used to detect fiber (or wavelength) faults. In summary, the OCh-DPRING scheme requires full (100%) protection resource overhead and cannot achieve spatial re-use, somewhat akin to SONET UPSR rings. Hence, the OCh-DPRING scheme is best suited for hubbed traffic demands, where wavelength counts (and not spatial distributions) are the dominant factors. 2.2 Shared Protection Rings (SPRING) Shared protection ring (SPRING) architectures are designed to improve upon spatial resource utilization over UPSR designs. These rings are derived from SONET BLSR rings, and are usually more complex, requiring active signaling for fast recovery. Overall, two shared ring schemes have been proposed, namely at the optical multiplex section (OMS) and optical channel (OCh) levels, respectively. In all such schemes, bi- directional connections between two endpoint nodes must traverse the same set of intermediate nodes. Details are now presented (see also [ARIJIS] for details). 2.2.1 Optical Multiplex Section-Shared Protection Rings (OMS-SPRING) Fiber cuts are one of the most common faults in ring networks, and given the increased multiplexing of DWDM systems, it is very desirable to also protect at the fiber span (i.e., OMS) level. Since per-channel protection switching can involve excessive signaling for large channel counts, fiber (i.e., optical line) protection can be much more scalable. Fiber protection basically provides an alternate fiber path between two nodes experiencing a fiber cut, and usually also requires signaling between the two end-points of fiber cut. Fiber protection is best applied to "fiber-rich" four-fiber rings, although two-fiber schemes are also possible. However, carefully note that line protection requires fiber fault detection and isolation capabilities, unlike end- to-end channel protection. A variety of OMS shared protection rings are possible, termed OMS-SPRING, and details are presented. Two-fiber OMS-SPRING line (fiber) protection schemes, termed herein as O-BLSR/2, are very similar conceptually to SONET BLSR/2 designs. For example, to permit resource sharing and (intra-fiber) coordination between working/protection channels, these rings require a wavelength numbering/assignment scheme to effect a grouping between working and protection channels. This essentially creates two "virtual fibers" from each physical fiber, albeit each with only half the number of wavelengths. The rules for such a partitioning are somewhat similar to those for timeslot partitioning in SONET BLSR/2 rings. Specifically, each fiber has an equal number of working and protection wavelengths traveling in the same direction, and the working wavelength group in a given fiber corresponds to the protection wavelength group in the other fiber. This implies opposing directions will be routed on the same side (i.e., through common nodes) but use different fibers. For all- optical rings, however, added wavelength numbering qualifications are required to enforce the wavelength-continuity constraint. In particular, the actual wavelength values within each group have to match each other, thereby precluding the need for wavelength conversion upon switchover events. For example, the first (W/2) fiber wavelengths can be assigned for working channels, whereas the last (W/2) wavelengths can be assigned for protection channels. This condition can be relaxed for translucent O-ADM designs, where wavelength values can also be interchanged upon protection switching. Node A Node B @ +---------+ +-------@-+ | | | @ | *********************************************@ | | | | *@ | | oooooooooooooooooooooooooooooo*@ | | o#############################*@ | +------o#-+ +------*@-+ ^ o# **,@@ Working ^ *@ | o# ##,oo Far-side | *@ | o# loop-back | XX<--Fiber | o# protection | *@ cut | o# | *@ +------o#-+ +------*@-+ | o#############################*@@@@@> B-D | oooooooooooooooooooooooooooooooooooo> A-D | | | | | | | | | |<------------------| | +---------+ +---------+ Node C Node D Figure 4: Loop-back span protection (O-BLSR/2) Two-fiber OMS-SPRING (O-BLSR/2) protection is possible using "loop- back" protection (akin to SONET BLSR/2 rings), namely, all failed fiber wavelengths are re-routed on to the protection fiber route on the counter-propagating side of the ring, see Figure 4. Again, wavelength continuity concerns may arise for all-optical rings. As expected, protection signaling is done on the far-side. Albeit an alternative, optical loop-back protection, however, is not very attractive since it increases the distance and transmission delay of the restored channels (nearly doubling path lengths, as per SONET BLSR/2). Related analog degradations will likely further hinder applicability in all-optical rings. Furthermore, loop-back protection fully consumes protection fiber resources and limits recovery to single fiber-cut faults at any given time. As a result, it is unlikely that two-fiber OMS loop-back schemes (O-BLSR/2) will see much favor in practical settings. Node A Node B @ +-----------+ +----------@+ ************************************************@| | | | *@| | |<--------------------| *@| | | | *@| | |-------------------->| *@| | oooooooooooooooooooooooooooooooooo*@| | o###########################o#####*@| +---------o#+ +---o#----*@+ ^ | ^ o# ** Working 1 ^ o# ^ *@ | | | o# @@ Working 2 | o# | *@ | | | o# oo Protection 1 | o# | XX <--Fiber | | | o# ## Protection 2 | o# | *@ cut | v | o# | o# | *@ +---------o#+ +---o#----*@+ | o###########################o#####*@@@@> B-D | oooooooooooooooooooooooooooooooooo*****> A-D | |<--------------------| | | | | | | |-------------------->| | | | | | | |<--------------------| | +-----------+ +-----------+ Node C Node D Figure 5: Span protection, loop-back and near-side (O-BLSR/4) Span switching is much more attractive for four-fiber rings since protection fibers have the same wavelength directionality as working fibers. By logically extending SONET BLSR/4 architectures, four-fiber OMS-SPRING schemes can also be defined to protect against fiber cuts, termed O-BLSR/4. Clearly, these rings can implement loop-back (i.e., far-side) span protection by simply re-routing all failed working wavelengths on a fiber onto their associated, counter-propagating protection fiber (like O-BLSR/2). This will extend the channel routes as shown in Figure 5 (e.g., lightpath A-D protection via A-B-A-C-D, lightpath B-D protection via B-A-C-D). Far-side loop-back switching is especially attractive if all working-side fibers are cut (e.g., conduit fault), but again suffers from increased analog degradations. Unlike two-fiber rings, four-fiber OMS-SPRING designs also enable more interesting and less-disruptive "near-side" protection switching. This form of protection switching is largely designed to protect against fiber (and channel) failures, and not node failures. One of its main purposes is to relegate protection signaling actions to the failed side of the ring (i.e., working, near-side). In other words, the "dual- directional" nature of fiber diversity of the four-fiber ring is exploited to maintain the same edge-to-edge node route between working and protection paths. Near-side protection switching is a generic concept that can be applied on both the line and path levels. The line- level case is illustrated for the O-BLSR/4 scheme in Figure 5, where the failed wavelengths are routed to the same-direction protection fiber on the near-side (only single direction shown for two working lightpaths A-D, B-D, traversing the outer working fiber). Overall, near-side line switching improves resource efficiencies since it does not disrupt traffic along the whole (long-side) protection route, as per loop-back techniques. However, near-side switching is less robust since it can only protect against working fiber faults, and not those that may also affect near-side protection fibers. 2.2.2 Optical Channel-Shared Protection Ring (OCh-SPRING) Bi-directional SONET rings have only considered line protection since channel protection will entail much more complicated tributary extraction. However, for optical (ring) networks, per-wavelength routing/processing capabilities are becoming commonplace. This enables the bi-directional ring concept to be extended at the optical path level, termed OCh-SPRING, and consequently, optical bi-directional path switched rings (BPSR) have also been proposed under the shared protection ring framework. Again, two variants of the OCh-SPRING are possible, namely for two- (O-BPSR/2) and four-fiber (O-BPSR/4) rings. Node A Node B +--------+ +--------+ ******************************************* | | # | | * | D-A <@@@@@@@+@@@@+@@@@@@@@@@@@@@@@@@@@@@@@@@@ * | +-o----#-+ +-@----*-+ o # @ * o # **,@@ Working @ * o # ##,oo Far-side @ * o # protection @ X <--Fiber o # @ * cut o # @ * o # @ * +-o----#-+ +-@----*-+ | o ###########################+####*******> A-D | o | | @ | | oooooooooooooooooooooooooooooooo+ | +--------+ +-@------+ @ Node C Node D Figure 6: Bi-directional path protection schemes (O-BPSR/2) The O-BPSR/2 proposal is based upon 1:1 protection (i.e., signaled switchover) and utilizes the same wavelength plan as its line-switching counterpart, O-BLSR/2. These schemes implement full bi-directional edge-to-edge switching on the "far-side" of the ring, i.e., on the side away from the fault. For example, lightpath A-D (D-A) re-routed from A-B-D (D-B-A) to A-C-D (D-C-A), Figure 6. Again, depending upon the translucency level,wavelength continuity may be required along all edge- to-edge routes. Channel switchovers are performed for channels in both directions, regardless of which one actually failed. This is more beneficial in case of both working and protection fiber cuts on the working side, e.g., conduit cuts. Lightpath faults are detected by downstream nodes, which then effect switchover actions via expedited upstream signaling along the far-side (albeit no standards are defined yet). Clearly, far-side edge-to-edge path switching will be the most disruptive, since (lower-priority) traffic and fast signaling are required on the opposite side of the ring. However, far-side switching can protect against intermediate node failures. It should, however, be noted that signaling latencies will dictate maximum ring sizes (node count limits) for all edge-to-edge ring switching schemes. By utilizing the SPRING wavelength plan, O-BPSR/2 solutions also significantly improve spatial resource sharing over their UPSR counterparts, especially for "non-hubbed" traffic demands [ARIJIS]. Furthermore, differing levels of protection resource sharing can also be allowed. For example, obviously, idle protection wavelengths can be used to carry lower-priority pre-emptable traffic (termed 1:1 shared). Furthermore, protection wavelengths (on the far-side) themselves can be shared between multiple working channels. This achieves a "1:N" protection resource multiplexing effect for each wavelength (hop), and not just the complete protection path. This feature improves resource efficiency significantly, especially for all-optical rings without wavelength conversion, and will yield reduced call setup blocking probabilities. These multiple levels of protection/sharing (e.g., 1:1 dedicated, 1:1 shared, 1:N shared, pre-emptable) will allow operators to define more differing grades of service. Further variations to the O-BPSR/2 framework are for future study. Four-fiber optical path-switched rings (O-BPSR/4) have also been defined and can provide more advanced capabilities. These rings also require a wavelength numbering plan, and it is best to choose one that mirrors the counterpart four-fiber OMS-SPRING scheme (and therefore, conceptually parallel to four-fiber SONET ring time-slot assignments). Specifically, due to increased fiber resources, there is no need for intra-fiber wavelength partitioning, and therefore, two counter- rotating fibers (i.e., all wavelengths) can be reserved for working and protection traffic, respectively. Differing directions of a bi- directional connection are therefore routed on different working fibers between the same O-ADM nodes. O-BPSR/4 protection schemes are largely variations of 1:1 protection switching scheme, as illustrated for a single direction in Figure 7. Furthermore, strong conceptual parallels exist with O-BLSR/4 line-switching concepts with regards to protection routing. In the most straightforward case, ubiquitous far-side path switching can be implemented, with both paths (of a bi-directional circuit) being switched over on to their corresponding protection fiber routes on the opposite side of the ring (as per OCh-SPRING O-BPSR/2). Far-side path switching can protect against failure of all standby resources on the working side (i.e., complete multi-fiber ring conduit cut). Node A Node B +----------+ +----------+ *********************************************** | | @ #|<---------------------| * | | @@@+@@@@@@@@@@@@@@@@@@@@@@@@@@@ooooo* | | #|<---------------------| @o * | +---------#+ +--@o----*-+ ^ | ^ # ** Working ^ @o ^ * | | | # ## Far-side | @o | * | | | # @@ Near-side path | @o | X <--Fiber | | | # 00 Near-side sub-path | @o | * cut | v | # | @o | * +---------#+ +--@o----*-+ | ###########################@oooooo | | |<---------------------| @@@@@@@*****> A-D | |--------------------->| | | |<---------------------| | +----------+ +----------+ Node C Node D Figure 7: Path protection schemes (O-BPSR/4), one-direction shown Furthermore, four-fiber ring near-side protection switching concepts (Section 2.2.2) can also be applied on a path-level. In fact, more variations are possible, namely edge-to-edge and intermediate near-side path switching. The first, O-BPSR/4 edge-to-edge near-side path switching, routes both the working and protection lightpaths from the working fiber on to the protection fiber in the same direction, see Figure 7. Meanwhile, to reduce service disruptions and signaling overheads further, intermediate near-side path switching only performs partial working path re-routing. This is shown for lightpath A-D in Figure 7, where the failed segment B-D is switched to the associated wavelength on the protection set of the second fiber. This largely limits protection signaling to the two end-point O-ADM nodes, but cannot overcome node failures. Due to the bi-directionality requirement, both channel directions are switched regardless of if one or both failed. For both forms of (O-BPSR/4) near-side switching, all-optical nodes will have to ensure that wavelength continuity considerations are met. Note that O-BPSR/2/4/ concepts can also be applied at the wavelength band level and this can be studied further. Depending upon the O-ADM node designs, protection resource sharing can also be achieved for four-fiber rings (and hence multi-level service definitions). For example, some have proposed a straightforward fiber protection implementation using 2x1 fiber switches before any mux/de-mux stages (Figure 1). This implementation precludes complimentary wavelength-level processing capabilities (such as pass-through, add, drop), and hence will hinder wavelength sharing on protection fibers (more restrictive). Clearly, in order to share wavelengths on the protection spans and improve resource utilization (i.e., for OMS-SPRING O-BLSR/4), per-wavelength processing is required for both working and protection fiber channels. This essentially means that a fiber cut can also be handled by multiple channel-level re-routing actions. However, since all wavelengths on a failed span are re-routed along a common route, "batch" control command implementations can be used. Nevertheless, sharing protection resources will require larger add/drop or switching fabrics (Figure 1). Clearly, "full-blown" four-fiber rings can support many more users of any given service category, as compared to two- fiber rings. In general, operators may also want to provision multiple (ring) protection schemes off of the same fiber infrastructure. In this regard, a generic limitation of fiber protection is that it treats all wavelengths (channels) in a fiber equally, and therefore alone it cannot achieve (channel-specific) service differentiation. However, span protection can co-exist with channel protection if a priority mechanism is used to arbitrate between the two recovery mechanisms For two-fiber UPSR schemes (O-UPSR/2), span protection is not applicable for 1+1 channel protection. However, (signaled) bi- directional OMS/OCh-SPRING schemes (i.e., those using the O-BLSR/2 or O-BLSR/4 wavelength plans) can support both mechanisms, with idle protection spans carrying lower-priority traffic. In such cases, co- existence between channeel (O-BPSR) and span (O-BLSR) protection mechanisms can be achieved in the protection signaling specification via an appropriate "priority" mechanism. Typically,span protection should be done first since it represents "lower-level" (or more coarse) recovery. This can be achieved by inhibiting all channel failure message responses and only responding to fiber/span failure messages. Further details and intricacies are outside the current scope and require careful future considerations. 2.3 Signaling Channel Architectures Optical rings allow for significant latitude in signaling channel architectures, and two overall categories are possible, namely in-band and out-band signaling. In-band signaling requires the use of overhead framing bytes (as reserved in a SONET/SDH or digital wrapper frame header) that are reserved on data channels. Such mechanisms are best suited for O-E based optical node designs, where edge client signals are mapped into synchronized electronic frames (which already contain the required signaling bytes). Alternatively, out-band signaling can be used to more clearly decouple the data and control planes. Out-band signaling can be done using a dedicated control wavelength, commonly termed as the optical supervisory channel (OSC), or even via a physically separate, out-of-band network (such as an Ethernet LAN). Note that some have termed the OSC approach as in-band also, since the control wavelength (typically 1510 nm) "physically" resides in the fiber itself. However, as far as data-control channel interaction goes, there is no interaction and hence this approach is termed as out-band. Recently efforts on defining a broad range of OSC standards are also emerging, see [SZERENYI]. In general, an out-band OSC-based approach is more attractive to some since it allows for genuine service-transparent optical ring paradigms, also stated in [SOULLIERE]. Specifically, this approach utilizes the same fiber plant, precluding limitations with a completely external out-of-band signaling network, yet still permitting true client wavelength (payload) transparency. However, out-band signaling systems need to ensure adequate bandwidth levels for increasingly large data wavelengths counts (in the hundreds). As a result, further considerations are needed for the out-band OSC channel approach (see T1X1 generic proposal [SZERENYI]). For example, some have proposed using sub-rate (synchronous) TDM circuit streams to partition and guarantee OSC bandwidth to all data wavelengths. Others have proposed (asynchronous) packet signaling on the OSC channels. In either case, whenever fast recovery guarantees are required, some form of bandwidth scheduling, be it TDM or packet scheduling (possibly with priority drop mechanisms), will likely be required on the OSC channels. This introduces added, but necessary, complexity concerns. Additionally, signaling channel robustness is also of concern and here, backup control channel provisions can be considered (see [LANG],[FREDETTE]). 2.4 Fault Detection and Isolation The ability to quickly detect, and preferably localize, fault events is crucial to achieving fast service recovery. So far, the above discussions have focused more upon switchover actions, and assume that fault detection (possibly localization) is already done. Now a key differentiating aspect of optical networks, unlike SONET networks, is that more variations of fault detection and localization mechanisms can be utilized (as will be detailed subsequently). In order to allow for full flexibility, it is therefore preferable that network-level optical (ring) fault recovery, notification, and detection/isolation mechanisms be clearly separable and independent of each other (more detailed discussion in Section 3.2.2). A review of the various monitoring solutions is now presented, see also [MANCHESTER]. Many first-generation and even current-generation WDM systems simply re-use existing SONET schemes to detect and isolate channel faults inside the core optical (ring) network. These solutions include re- using B1 byte monitoring, and loss of framing (LOF)/loss of signal (LOS) alarm information. Such solutions have been commonly referred to as opto-electronic (O-E) and/or frame-monitoring schemes [GHANI2], [CUEPPENS], since they require that all monitored data wavelengths be "opaque" or "translucent". The digital wrappers approach, which represents a counterpart to SONET framing, also essentially embodies a similar O-E based solution, e.g., forward/reverse defect indicator (FDI/RDI) bytes, etc. Since most operators are quite familiar with SONET overhead monitoring, O-E type schemes have one definite advantage, namely, well-defined standards. This permits faster vendor interoperability (albeit not considering proprietary usages of various unused overhead bytes). However, opaque monitoring represents some serious limitations. First of all, per-channel electronic overheads usually pose increased systems costs and power requirements. More importantly, such designs are largely unscalable to very large, ultra- dense WDM systems, and generally inhibit evolutions to truly transparent networks [BHANDARI]. Furthermore, O-E monitoring requires mappings for all client payload types. Now although well-known (SONET) encapsulations exist for IP, ATM, and frame relay protocols, further extensions may be necessary, e.g., for new gigabit Ethernet standards, ESCON, cable video signals, etc. Note however, that O-E monitoring may be suitable for monitoring out-band control channels, since these are electrically terminated at each node. To get around the limitations of opaque monitoring, various vendors have proposed optical monitoring schemes using non-intrusive signal tapping setups. These solutions are particularly germane to monitoring non-SONET payload types, and include such as fiber/wavelength power levels, optical signal-to-noise ratio (O-SNR) measurements, Q-factors, etc (see [GHANI2],[CUEPPENS]). For example, power monitoring can detect fiber cuts in under 10 ms, and this is capable of meeting the most stringent of recovery requirements. Power monitoring is also termed as loss of signal (LOS) fault, and can trigger various protection actions, such as 1+1 receiver switchovers or MPLS FIS [GHANI2] alarm messaging (see Section 3.2.1). However, although optical monitoring is of high interest to vendors and service providers alike, the current lack of standards (and to an extent, advanced features) are hindering widescale adoption. Most current all-optical solutions simply perform line power-level monitoring, and are therefore best-suited for O-BLSR support. Although per- wavelength power-level monitoring can also be done, this poses significant equipment costs. Nevertheless, per-wavelength monitoring inside the network core will be necessary to support transparent O-BPSR schemes, in the absence of any O-E (SONET) frame monitoring. Although optical monitoring resources (such as spectrum scanners) can be shared between multiple fibers/wavelengths to control costs, the resulting fault detection times will be much longer (beyond the "50 ms" SONET reference). Regardless, since optical component technologies are continually undergoing rapid improvements and miniaturization, it remains to be seen if these concerns, indeed, may be mitigated in the foreseeable future. Moreover, some designers may actually want to use optical monitoring techniques to complement capabilities in opaque networks, e.g., transponder performance/ behaviors to predict failure conditions. A more timely and cost-effective alternative may be to perform "edge" channel (OCh) fault isolation, as suggested in [BHANDARI]. Specifically, no channel-level monitoring is performed in the network core, thereby precluding excessive (expensive) O-E conversions or OCh-level optical monitoring. Instead, fault isolation is only done at the channel termination points. This can be achieved using a variety of techniques, implemented in the receiver line cards (either optical power monitoring or electronic frame monitoring after O-E conversion). All that is required is that the channel protection path be "dis-joint" (Section 3.1.2) from the working paths. This approach is very attractive in all-optical (ring) networks, where operators need service transparency and "SONET-like" recovery times. Also, this solution is well-suited for "edge-to-edge" channel protection schemes, such as those detailed for O-UPSR/2 or O-BPSR (far-side, edge-to-edge near-side) setups. 3. Dynamic Provisioning Issues Recent developments have extended the MPLS protocol framework from the packet/flow switching domain to the optical lightpath switching domain. Termed multi-protocol lambda switching, MPL(ambda)S [AWDUCHE],[GHANI1], [RAJAGOPALAN], this work draws analogies between labels and wavelengths and intends to re-use/extend signaling and resource discovery protocols for the optical domain. Optical nodes (such as cross-connects or add-drop multiplexers) are assigned IP addresses and run modified MPLS routing and signaling protocols, i.e., lambda switch routers. More importantly, recent proposals for a generalized MPLS (GMPLS) [ASHWOOD], [XU] framework are furthering this trend, extending basic MPLS concepts to provision other entities, e.g., TDM circuits via SONET ADM's, fiber routes via fiber cross-connects, etc. In parallel, there has been a lot of focus on defining LSP recovery schemes for MPLS networks, albeit, mostly at the packet flow level [DOVOLSKY],[OWENS1],[KINI2]. Conceivably, these schemes can also be extended to apply to "optical LSP" (i.e., lightpath) protection under the MPL(abmda)S framework. In fact, this application has already been proposed in [GHANI2]. However, owing to the IP-centric origins of the MPLS framework, the above work is generally tailored for mesh routing networks, even though its generic nature does not preclude specialized, topology- specific applications or extensions. Given all the variations of optical rings (Section 2), it is very advantageous to develop a comprehensive provisioning framework and align it with the larger MPL(ambda)S architecture. In particular, two signaling mechanisms are required for optical rings. First of all, signaling is required for lightpath provisioning operations, such as setup/takedown. This mechanism (protocol) must specify both the working and protection switched O-ADM paths along with all the intricacies of ring protection switching requirements. Ring resource management will also be a critical part of the provisioning stage. Secondly, a signaling mechanism is required to implement fast optical APS actions for O-ADM (light)path protection schemes, as detailed previously. An initial look at these two crucial topics is now presented and is intended to serve as basis for further, more defining work. 3.1 Channel Setup Requirements For optical ring channel setup/takedown, the overall provisioning capabilities developed under the ubiquitous MPL(ambda)S framework are quite applicable. Namely extensions to MPLS signaling protocols are already being proposed to handle the specifics of optical lightpath routing [KOMPELLA3],[YU]. From an operator's point of view, ring networks will likely interface to (or even migrate into) mesh networks in the near future (e.g., metro rings to regional/long-haul mesh). Given the likely adoption of MPL(ambda)S type protocols for optical mesh provisioning, it is prudent to choose likewise for ring networks, thereby enabling an even closer interworking. However, provisioning ring paths (working, protection) will require added considerations, and some of these are now considered more closely. 3.1.1 Signaling Extensions At the core of ring channel provisioning is the concept of a service definition, as commonly extended through various means, e.g., either from a element/network management system (EMS/NMS) or via an "optical user network interface" (O-UNI). Since the latter approach has been the focus of many standardization efforts, discussions herein will give it closer consideration. Recently, many "O-UNI" definitions have been tabled for optical networks, proposing some new signaled interfaces [ARVIND],[ABOULMAGD],[MCADAMS],[XUE] along with more auggmentations to MPLS LSP setup messaging [YU],[KOMPELLA3]. In short, service definitions supply the signaled information "attributes" for subsequent channel setups. Channel setup, in turn, implies the more general category of routing and wavelength assignment (RWA) and policy control (Section 3.1.3). Setup information usually includes many details, such as the channel framing type (e.g., SONET, SDH, PDH, digital wrappers, IEEE Ethernet, none, etc), bit-rate (2.5 Gb/s OC-48, 10 Gb/s OC-192, 1.0 Gb/s 10 Gb/s Ethernet, etc), protection type (shared, non-shared), and priority (non-pre-emptable, pre-emptable), etc, see [ABOULMAGD]. Provisions have also been suggested for indicating lightpath diversity levels (e.g., node, link, etc), see [XUE]. By and large, these generic attributes also apply to ring networks, although their detailed usages and applications require further considerations. Typically, these service definition "attributes" will be mapped to appropriate signaling parameters for lightpath setup signaling. A sample implementation may be onto RSVP-TE or CR-LDP LABEL_REQ messages, via appropriately defined TLV objects, see examples in [KOMPELLA3],[YU] and related references therein for details. Given the many possible variants of optical rings (as per Section 2), appropriate "mappings" will have to be generated to translate the desired user lightpath attributes, especially for the case of open (signaled) optical network interfaces. Specifically, users may request various channel priority or protection types (amongst other attributes), and these must be translated to the appropriate channel types given the underlying ring specifics. For example, a user request for a non-pre- emptable, non-shared protected channel in a O-UPSR/2 (two-fiber) setup may be translated into a simple 1+1 working/protection channel request. Alternatively, the same request in a O-BPSR/4 (four-fiber) setup may be resolved as a 1:1 working/protection channel request. Such mappings are required before any ligthpath routing can be performed (Section 3.1.3). Overall, the mapping of (signaled) channel attributes from user requests to the exact ring lightpath types is highly implementation-specific and hence should not be the subject of standardization (i.e., vendor-value add feature). Once the user request is properly mapped (to the ring) and its lightpath route computed (Section 3.1.3), various MPLS LSP signaling capabilities can be exploited for the actual setup. Clearly, one such feature is explicit route (ER) signaling, which can explicitly indicate the required path and reserve resources. Specifically, ER inserts the complete route specification in appropriate route specification objects (i.e., explicit route fields in RSVP-TE PATH or CR-LDP LABEL_REQ messages). Additionally, MPLS bi-directional LSP setup proposals [GUO1] can ensure that both uni-directional channels of a bi-directional connection traverse the same set of nodes. In conjunction with shared risk link group (SRLG) "disjointness" information (Section 3.1.2), this signaling feature is directly applicable to O-BLSR/2/4 and O-BPSR/2/4 setups (i.e., where bi-directional channels must traverse the same set of O-ADM nodes). Possible extensions to the setup signaling message (object) types for ring channel provisioning are for further study. 3.1.2 Resource and State Dissemination In addition to the above setup information requirements, provisioning algorithms (Section 3.1.3) need to know the existing static topological details and available dynamic resource levels (as detailed in [BERNSTEIN]) in order to compute ring routes. Consider the first requirement. Examples of basic static topological information are the number of fibers, O-ADM nodes, and their connectivity. For fiber elements, information is required to indicate the link type (transparent, service-aware), the number and location of supported wavelength channels (e.g., ITU-T grid spacing, offsets, guard bands), related analog metrics (loss, dispersion figures), etc. Meanwhile, for O-ADM node elements, many (static) details are pertinent. Examples include the ring configuration type (O-UPSR, O-BLSR, O-BPSR, or multiple), number of fiber ports (e.g., incoming, outgoing, add, drops), fiber port protection type (1+1 protected or unprotected), type of ports supported (e.g., transparent, opaque), performance monitoring capabilities (e.g., optical, electrical, per-channel, per-span), signal regeneration (e.g., 2R, 3R), wavelength conversion capabilities (e.g., none, partial/selected, full), protection switching capabilities (e.g., per-channel, per-fiber, per-conduit), etc. Since ring schemes are intricately associated with the directionality and protection association (working, protection) of fibers or wavelength groups inside fibers, this information must also be incorporated. In traditional data networks, interior gateway protocols (IGP) are used to disseminate static topology and dynamic resource information. Recent additions for supporting opaque link state attribute (LSA) definitions (RFC 2370) will help further facilitate extensions to "non-data" routing applications. More recently, many proposals have tabled extensions thereof for optical networks, and in fact, many of the above-discussed requirements (for static topology and dynamic resource information) have already been proposed with in the context mesh-routing MPL(ambda)S networks [KOMPELLA1-3]. For example, IGP provisions have been considered to indicate wavelength conversion capabilities and dynamic link-level resource (wavelength) utilizations/ levels. Such active resource updates are vital for dynamic ring RWA algorithms. Delineations between different link-level resource classes have also been proposed (i.e., active, free, reserved, pre- emptable wavelength sets), see [KINI1-2]. The actual control/ specification of wavelength plans can be done either statically (via the NMS) or dynamically (e.g., based upon changing network topologies). As an application here, such resource class delineations can be leveraged to control intra-fiber wavelength plans (e.g., per O-BLSR/2, O-BPSR/2 schemes). In addition, recently the concept of a shared risk link group (SRLG) definition has also been proposed to help identify risk associations between various entities, see [RAJAGOPALAN],[PAPADIMITRIOU1]. By using this information, adequate resource "disjointness" can be introduced into the constraint-based path computation (routing, Section 3.1.3) phase, thereby reducing simultaneous lightpath failures (e.g., between working and protection paths). Recently, a detailed, comprehensive treatment of the SRLG concept has been presented in [PAPADIMITRIOU1], in order to formalize the link between risk groups and route computation. Here, two different hierarchical resource inference/diversity models are defined, namely physical (e.g., wavelength, fiber, conduit, etc) and logical (or geographical, i.e., node, zone, region). An encoding scheme is also presented for encoding/summarizing SRLG identifiers (e.g., between logical boundaries) along with possible mechanisms for risk assignment. Collectively, SRLG information and the associated lightpath risk derivation mechanisms are crucial for service provisioning in optical networks, given the high levels of traffic multiplexing and also resource co-location (e.g., wavelengths in fibers, fibers in conduits, etc), see also Section 3.1.3. Overall, many of the above-described informational (IGP) extensions are also very applicable to optical ring networks. As these concepts mature, along with their usage definitions, their application herein will indeed be highly practical. Additional specifications or applications of such augmented LSA's are for future study. 3.1.3 Constraint-Based Routing/Path Computation During the channel setup phase, lightpath route computation is performed by utilizing the available network information (e.g., topology, ring-type, resource leveks, risk groups, etc). Specifically constrained routing/ path computation is required, and this can be deemed as a subset of the more generic constraint-based routing paradigm [GHANI1]. Here, the constraints are now more specific to optical parameters (e.g., topologies, wavelengths, converters, amplifiers, etc) and policies (e.g., as per SLA requirements). Additionally, generic policy control can also be implemented (in addition to the compute-centric RWA processes) in order to enforce user SLA guidelines. A sample application using the well- defined, generic common open policy service protocol (COPS RFC 2748) is presented in [GHANI3]. To date, much detailed research has been done on the subject of constraint-based lightpath routing, technically termed as the routing and wavelength assignment (RWA) [ZANG] and/or virtual topology design [DUTTA] problems. In performing lightpath channel routing, typically, there are two sub-problems which have to be resolved, namely lightpath route computation and subsequent wavelength selection [DUTTA]. Overall, many types of RWA algorithms have been proposed in the literature, ranging from complex optimization-type formulations, to constrained shortest-path methods, to various simplified heuristics. Usually, RWA algorithms aim to optimize various broad constraints such as hop counts, wavelength re-use (in a given network segments), propagation delays, protection/priority levels, residual resources, revenues, risk probabilities, etc. Moreover, many ring-specific lightpath routing algorithms have also been researched, see [MARCENAC] and related references. Clearly, the any ring lightpath RWA algorithms will be very tightly coupled with the actual ring types, wavelength plans, wavelength conversion capabilities, and various other specific considerations. For example, in O-UPSR/2 rings for a 1+1 protected channel request, two "disjoint" paths must be found between the source and destination nodes, along with necessary permanent bridging/ receiving resources at the endpoints. Alternatively, in O-BLSR/4 rings for a 1:1 shared long-side protected channel request, the RWA schemes will only need to search the long-side of the ring for protection channel routes, and this can include any assigned protection wavelengths. Note that the actual computation phase can be implemented in a variety of ways, such as distributed shortest-path/heuristic computations across network nodes or via a a centralized route/policy control server. Note that for (ring) protection schemes, further RWA considerations are required. Specifically, at setup time "joint" RWA algorithms are necessary for resolving the routes and associated wavelengths for both the working and protection (sub)paths, see [DOSHI] for sample proposal. These computations can (should) further utilize SRLG-based information to ensure adequate resource/risk diversity between working and protection channels, see [PAPDIMITRIOU1] Appendix. For example, (ring) protection paths require shared-resource (i.e., risk) separation from working entities, i.e., "disjoint". In this context, an entity can be a full edge-to-edge lightpath (as per O-BPSR/2/4 near/far-side and O-UPSR/2), a portion of a lightpath (i.e., sub-path as per O-BPSR/4 intermediate near-side), or a complete fiber span (as per O-BLSR/2/4). Moreover, SRLG definitions can be used to effect inter-fiber delineation between working and protection fibers (for the case of O-UPSR/2 and O-BLSR/4 rings), i.e., working and protection SRLG identifiers. Generic discussion of routing diversity (dis-jointness) is also presented in [DOVOLSKY],[OWENS2],[XUE]. Overall, it is highly likely that the lightpath routing algorithms themselves will not be the subject of standardization. Conversely, this is certainly an area of vendor-value add, and many suppliers will prefer implementing their own proprietary algorithms/policy control as best suited to their individual customer needs. Therefore, what needs to be standardized is more the actual informational framework required to perform proper lightpath RWA computation. 3.2 Protection Signaling It is safe to assume that operators will demand SONET SHR (50 ms ceiling) recovery timescales for protected O-ADM ring services, and meeting this stringent requirement is perhaps the foremost concern when trying to leverage MPL(ambda)S signaling for optical ring control schemes [GHANI2]. Now for most optical ring types (excluding 1+1 O-UPSR/2 designs), millisecond recovery requires fast "APS-like" signaling capabilities, akin to the SONET K1/K2-byte APS protocol. Generally speaking, all such schemes can be subsumed under a more encompassing model, namely that of two (or more) switching end-point nodes and intermediate, physically disjoint protection resource(s). (This excludes loop-back switching techniques, which are largely deemed unfavorable for optical networks, Section 2.2.2). For example, for channel protection, the end-point nodes are either the source and destination nodes (O-BPSR/2, edge-to-edge near-side and far-side O-BPSR/4), or the appropriate intermediate nodes (intermediate near-side O-BPSR/4). Likewise, for span protection, the end-point nodes are simply the adjoining O-ADM nodes. By developing appropriate switchover signaling extensions to implement this generic model, conceivably all relevant ring protection schemes can be covered. For the special case of optical ring networks, two possible options exist for implementing such fast protection switching. One is to develop enhancements to the existing RSVP-TE/CR-LDP LSP protection (survivability) signaling proposals and tailor them for "optical lightpath LSP" protection, termed herein as the direct interworking approach (originally proposed in [GHANI2]). The other would be to develop an altogether new, dedicated protection-switching protocol, namely optical APS (O-APS) protocol, to complement the overall MPL(ambda)S framework. This new protocol would only perform protection switchover signaling for fault events but not any setup provisioning (relegated to existing MPL(ambda)S signaling mechanisms, as detailed previously in Section 3.1). These two cases are presented in a broader context in Figure 8, which shows an example of multi-level recovery protocols. On the packet routing level, service recovery actions can be performed by existing IGP path recomputation/re-routing schemes (longer convergence times). On the virtual circuit (i.e., packet LSP) level, emerging enhancements to RSVP-TE/CR-LDP signaling can effect improved recovery timescales (sub-second or lower). Finally, on the lightpath circuit level, recovery actions can be implemented either via further RSVP-TE/CR-LDP enhancements or an (above-mentioned) O-APS protocol, Figure 8. Further details are now discussed. +-------------------------+ | IGP re-routing | Packet routing level +-------------------------+ | RSVP-TE/CR-LDP | "Virtual circuit" (packet LSP) level +-------------------------+ | RSVP-TE/CR-LDP or O-APS | Lightpath circuit level +-------------------------+ Figure 8: Service recovery protocols (packet, flow, circuit levels) 4.2.1 Direct Interworking It is instructive to first briefly review MPLS LSP protection concepts. Clearly, simple non-signaled protection is possible by establishing multiple (LSP) paths between source and destination LSR nodes and Streaming data across these paths, essentially like 1+1 protection. However, more advanced protection signaling proposals are also beginning to emerge within the extended RSVP-TE and CR-LDP protocols framework [BHANDARI],[HUANG],[KINI1-2],[OWENS1-3]. The basic idea with MPLS LSP protection is to provision back LSP (sub)-paths, and in case of fault discovery, perform a signaled switchover. Generic protection switch LSR (PSL) and protection merge LSR (PML) nodes are defined and these entities define the edges of the protected LSP segments. Specifically, a desired LSP segment, termed working (or active) path [OWENS1], is setup for protection by having the PML/PSL nodes source and sink two distinct (sub)-paths, working and protection, as shown in Figure 9. As a generalization, PSL/PML node pairs can protect multiple LSP segments, termed protected MPLS traffic group (PMTG) [OWENS1], reducing signaling overheads for improved scalability. Downstream nodes detecting a fault event propagate a failure indication signal (FIS) in the upstream direction, containing a list of protected LSP's on the failed PMTG entity. Various timer mechanisms are used to control the inter-FIS packet timing, duration of FIS transmissions, and hold-off time for initial FIS indication, see [OWENS1] for discussions on timer settings. Upon receiving the FIS message, the PML node performs a switchover from the working to protection sub-paths for all affected LSP's specified in the PMTG. Additionally, a failure recovery signal (FRS) is also propagated after the fault has been repaired (along the same route as the FIS message). Similar timer mechanisms as with the FIS message also exist for the FRS message, and neither message type requires reliable transport, e.g., no TCP connection. Note that both the FIS and FRS message types are "protection-related" additions to the MPLS signaling framework (CR-LDP, RSVP). Owing to the generic nature of this specification, the PML and PSL nodes need not be the "end-point" source and destination nodes, respectively, and hence technically speaking, judicious placement thereof allows this framework to incorporate path, sub-path, and hop protection schemes. Although this overall framework seems most applicable to 1:1 or 1:N protection schemes (downstream nodes signal fault switchover requests to upstream nodes), a 1+1 protection type is also mentioned in [OWENS3]. Finally, proposals for sharing protection resources between multiple protection paths (and lower- priority traffic) are also beginning to emerge [BHANDARI], [GHANI1],[KINI2]. ******************************** * +---+ * * +-------------| C |------------+ * * / +---+ \ * * / \ * *********** / \ ************> +---+ +---+ ** Working +---+ +---+ | A |------| B | PSL (A-B-C-D-E) PML | D |-----| E | +---+ +---+ ## Protection (PMTG) +---+ +---+ # \ (A-B-F-G-D-E) / # # \ / # # \ +---+ +---+ / # # +------| F |--------| G |------+ # # +---+ +---+ # ################################ Figure 9: MPLS LSP protection concept (PSL/PML LSR nodes) A paramount concern for network operators is fast recovery times. The MPLS LSP protection proposals are increasingly aware of this need, especially in comparison with the relatively longer timescales of IP re-routing schemes. Along these lines, the MPLS LSP protection framework includes the concept of a reverse notification tree (RNT) [OWENS1-2] entity that traverses from the PSL to the PML node. This provides an "express" signaling path for protection and recovery messages, significantly more efficient that "flooding-type" recovery schemes. The RNT is basically an "inverse" label-lookup (cross-connect) table that is constructed at the time of working/protection LSP setup and allows for resolving the incoming links on which to forward the backwards-propagating FIS message. As such, this construct implements "near-side" protection signaling. By using the RNT, hop-by-hop routing of FIS messages can be avoided, helping to expedite switchover times. In the latest specification, hop-by-hop routing (layer 3), packet LSP (MPLS), or SONET K1/K2 bytes (layer 2) mechanisms can be used to implement the RNT (see [OWENS1]). Also note that the RNT concept extends to multicast LSP's and is implemented for both working and protected paths. The latter allows it to be used to indicate failures on the protection path (requiring subsequent manual operator intervention, however). The actual setup of protection segment is implemented via extensions to the ER field of CR-LDP and RSVP-TE setup messages, e.g., LABEL_REQ, PATH [HUANG],[OWENS3]. Specifically, attributes are added for identifying the PSL/PML pair, protection type (1:1, 1+1) RNT implementation, timer values, etc. Note that there have also been related proposals for augmenting IGP protocols to support LSP protection (e.g., delineate active/back bandwidths), see [KINI1]. These can be extended to the optical case to specify active/ backup wavelength sets, etc. Now consider the application of the above MPLS "packet LSP" protection framework within the context of MPL(ambda)S optical (ring) networks. For the case of channel (OCh) protection, the optical (O-ADM, OXC) LSR devices can now serve as PML and PSL nodes and "disjoint" protection lightpaths (or hops) can be specified between the two nodes, as per [GHANI2]. The PMTG entity at this level is the lightpath channel. For example, for edge-to-edge channel protection (e.g., O-BPSR/2, O-BPSR/4), the PSL/PML nodes can be the (sub)connection end-points themselves. Alternatively, for intermediate near-side channel protection (O-BLSR/4 case only), the PSL/PML pair can be the appropriate intermediate O-ADM nodes. Given the appropriate information (via requirements specified in Section 3.1.2), RWA algorithms can appropriately setup the ring working/protection routes and switching points by using the ER signaling function. The case of line protection, as proposed in O-BLSR/2/4 schemes, is somewhat different, since spans are more static (physical) entities and not dynamically created ones, as are lightpaths. However, using the protection group concept, all wavelengths on a given fiber span can be grouped into a common "span" PMTG and the diverse PMTG "span" route established. This route can either be a single span (O-BLSR/4) or a series of spans (O-BLSR/2 with loop-back), with the two adjacent nodes serving as the PML/PSL pair. Note that depending upon the span- switching implementation, wavelength switching may not be required. More clearly, O-BLSR/4 schemes using simple 2x1 switches for fiber protection do not permit wavelength re-use on protection fibers. In this case, a FIS message (pertaining to a fiber cut) will simply trigger a 2x1 span switch. However, simpler O-BLSR/2 schemes and more elaborate O-BLSR/4 schemes (e.g., without 2x1 span switches) can carry lower-priority traffic on protection wavelengths. In these cases, all individual channels of a PMTG have to be switched. Although the above high-level interworking seems amenable, there are some concerns regarding recovery timing, particularly with regards to RNT setups and fault signaling. Consider the RNT issue first. During MPLS LSP setup, LSR nodes must keep track of the upstream node, incoming link and interface, and list of LSP(s) (unicast case) in order to construct the RNT. The procedure assumes bi-directional links between intermediate LSR nodes, since FIS messages are subsequently transmitted on the "reverse-table" incoming link interface. However, in optical rings (even meshes), especially transparent rings (meshes), there is likely a much higher degree of orthogonality between control and data flows. For example, if control signaling is done on OSC channels and not embedded in data wavelengths, even though RNT setups can extract the above-detailed state at channel setup time, the actual FIS (and FRS) messages are not sent on the "reverse-lookup" incoming interface links. Additionally, the current MPLS RNT setup performs near-side protection signaling, since fault messaging traverses the same set of nodes but in the opposite direction. For long-side protection signaling (as required per some O-BLSR/O-BPSR designs, Section 2.2), however, protection signaling is required on the RNT of the protection path. This is slightly different from the existing possibility of MPLS protection-path RNT signaling [OWENS1], since it implies failure of the working and not protection side. All of these intricacies will require further setup signaling considerations. Now consider the MPLS fault signaling message types, namely FIS and FRS and their usage for optical channel protection. Initially, the various fault detection (isolation) schemes, Section 2.4, are expected to trigger FIS message transmissions within a few milliseconds of an occurring fault (note that associated FIS hold-off timers must set appropriately). Once the FIS messages are generated, the remaining recovery latency is largely controlled by MPLS-layer signaling protocols and ensuing optical switchover times. The latter issue depends upon the actual switching technology used in the O-ADM protection stage, Figure 1, and realistically, millisecond timeframes can be expected via solutions such as MEMS or (O-E based) EXC designs. Meanwhile, this stresses the need for expedient FIS processing in order to match stringent benchmarks set by SONET APS. Here, the RNT architecture is of particular importance (as detailed above). It is expected that high-priority MPLS packet LSP's (routed on the OSC) will be required to expedite fault message transmissions along the reverse path. Specifically, improvements can be achieved using a variety of solutions. One is to use priority queuing for (reverse) FIS messages, and dedicate a fixed minimum amount of bandwidth via some scheduler mechanisms. A further extension would be to perform FIS message processing (e.g., RNT label lookups and fast switchover) via dedicated hardware, such as FPGA devices. Clearly, both of these schemes entail added system complexity, and demonstrable evidence is required to determine if SONET recovery times can be matched. Another important issue arises with regards to "operational modes." Specifically, the emerging MPLS protection signaling framework still lacks some of the vital, "externally-initiated" [GR1230] features which SONET operators are well-accustomed to. Namely, the SONET K1/K2 byte protocol enables multiple operating "modes" via a well-defined message priority structure. For example, messages are defined (in decreasing order of priority) for lockout, forced switching, fault events (signal fail, signal degrade), and manual switching, see [GR1230]. Such procedures are vital to operations-related tasks and are used during various phases (i.e., maintenance, diagnostics, and upgrades). Controlling the "operating mode" is instrumental in avoiding excessive service disruptions to live customer traffic. Undoubtedly, similar functions must eventually be provided by MPL(ambda)S-based optical signaling protocols, in both ring and mesh networks, if optical channel services are to be deployed in carrier-class networks. This area has not received much attention to date and significant further work will be required. Provisioning such operating modes will require additional message types to be added to RSVP-TE and CR-LDP messaging, e.g., a forced or manual switching on to protection paths. In summary, there are clearly a number of issues that need to be resolved before MPLS LSP protection schemes can be confidently applied to optical networks. 3.2.2 O-APS Protocol As an alternative to generalizing MPLS LSP protection capabilities, a specialized, fast optical APS (O-APS) protocol is possible for optical rings. This entity can be considered as a "lower-layer" (i.e., layer two) type of protocol, as illustrated in Figure 8, somewhat akin to the LMP [LANG],[FREDETTE]. For some, there are various compelling reasons to develop such an alternative. First of all, given the relatively stringent recovery requirements, many may argue that modifying or specializing MPLS signaling protocols (e.g., added failure-recovery messages, prioritized processing/implementations) may become too complicated and lengthy a process. Instead, a lightweight O-APS protocol can be designed, and this would be functionally equivalent to an "optical" version of the ubiquitous SONET K1/K2 byte protocol. Nevertheless, unlike the SONET K1/K2 byte APS protocol [GR1230], for IP integration purposes, this protocol must be packet-based. In other words, the implementation should not be restricted to a fixed number of signaling bytes in a synchronous (e.g., SONET) framing standard. Such a setup would be totally counter to packet-oriented control done in IP networks. Instead, a "fast" packet-based protection protocol must be developed. How these packets are actually carried in the control channel, however, can be left open to vendor implementation, but bandwidth guarantees are necessary in order to meet recovery timing requirements (similar to discussions for FIS message transport, Section 3.2.1). It is here that some vendors may choose to embed these O-APS control packets into SONET overhead framing bytes on the (out-band) OSC, but note that this is distinctly different from the case of standardizing explicit signaling bytes, i.e., "non-packetized" O-APS implementation. Some of the key components of an O-APS protocol are briefly highlighted here, although a more detailed specification is clearly beyond the scope of this discussion and intended for further study. Among other things, message fields must identify the switching nodes, lightpath channels/spans, fault type (channel, span, node), and requested protection actions (channel or span switching, near-side, far-side), etc. Additional parameters must also be specified for alarm messaging, such as durations, spacings, even priorities (e.g., span, channel). A complete state machine definition and related rules are also required, and examples include triggering recovery actions, starting/stopping alarm messaging, alarm squelching for multiple types of alarms (e.g., channel versus span, etc). Another issue is inter-node keepalive messaging. Such "hello" message formats are common in IGP protocols and are directly embedded into the SONET APS protocol, i.e., non-alarm K1/K2 byte fields serve as constant "hello" updates. O-APS peer nodes must also have this capability, and one alternative is to add explicit hello messaging for non-failure time periods. Note that the LMP protocol also has some provisions for "liveness" message updates, but this protocol is currently more geared towards mesh network support, i.e., OXC-to-OXC or router-to-OXC connectivity maintenance, see [LANG], [FREDETTE]. (Nevertheless, new WDM-related provisions are being considered for LMP, and their applicability within the O-APS context is discussed later). Hence a fast, dedicated liveness/hello mechanism is desirable for optical rings. Finally, since the O-APS protocol will be "new" protocol, it presents a good opportunity to properly define crucial "operator-initiated" functionalities, Section 3.2.1. For example, explicit message types (or fields, as appropriate) and appropriate priorities can be assigned for features such as resource lockout, forced and/or manual protection switching, etc. In fact, this option is one clear advantage of defining an altogether new protection O-APS switching protocol. However, significant further work is required to specify a truly generalized O-APS framework to implement the previously-defined transparent optical ring architectures, Section 2. Overall, an O-APS function will be an orthogonal, complimentary addition to the MPL(ambda)S/GMPLS suite. Note that from a broader perspective, a dedicated O-APS protocol can also be deployed in a "standalone" manner, an added benefit. This is important for many vendors need to provide O-ADM ring solutions, but at the same time, want to gradually transition into a full-blown "IP-based" MPL(ambda)S-based control framework. In such cases, the orthogonal nature of the O-APS protocol will allow vendors to couple its protection switching features with their own (proprietary) NMS-based provisioning solutions. Specifically, the NMS controller(s) will explicitly setup and takedown ring channel lightpaths and "fill in" the required information for the O-APS protocols to operate from, e.g., such as ring maps. However, future migrations towards truly open, distributed provisioning paradigms (i.e., in lieu of proprietary NMS-based provisioning setups) will clearly necessitate added interworkings between the O-APS protocol and the other (orthogonal) MPL(ambda)S/GMPLS components. In particular, proper interfaces have to be identified (and developed) to enable any information exchange. Although the details of such interworkings are for further study, some preliminary possibilities can be highlighted here (further study required). At channel setup time, the O-APS protocol may require various pieces of information from the related setup signaling entities (CR-LDP or RSVP-TE, Section 3.1) in order to perform its functions, i.e., since the O-APS protocol itself does not implement any channel provisioning functionalities. As a particular example, "connection ring map" information must be supplied after the appropriate signaling procedures have setup the associated lightpath channels, identifying the source and destination endpoints of the lighpath connection. Additional information will likely be required from the lighpath routing engine which computes details of the working/protection routes, e.g., protection types (e.g., channel, span), switching endpoints (source/destination or intermediate node pairs), etc. For example, the source/destination O-ADM nodes are the switching end-points for edge-to-edge long/near-side channel protection (as per O-UPSR and O-BPSR designs), whereas the selected intermediate nodes are the end-points for near-side intermediate channel switching (as per some O-BPSR/4 designs). Alternatively, for span protection, the end-points are the two nodes adjacent to the failure. Another requirement for information exchange (with the O-APS protocol) also arises during fault event occurrences. Specifically, it was stated earlier that optical rings provide the added benefit of decoupling fault detection mechanisms from the subsequent recovery procedures, Section 2.4. Now in order to develop a more structured, formal mapping between the actual fault detection, notification, and recovery mechanisms, interworking with the emerging LMP protocol [LANG] can be considered. Specifically, LMP provides generic fault correlation/ notification functionalities which are independent of the actual fault detection schemes, a very germane feature. Moreover, recent proposals for new WDM-transport related considerations within the LMP framework [FREDETTE] will undoubtedly help improve its scalability and fault notification timings in optical (ring) networks. As this work matures, mapping LMP notifications to O-APS recovery mechanisms (e.g., via defining switching triggers) can improve overall architectural modularities/ orthogonalities and this requires further investigation. 3.2.3 Multi-Layer Escalation Strategies Assuming that fast optical (ring) lightpath protection schemes will emerge, inter-layer protection "collisions" will be of concern. Since multiple protocols provide recovery mechanisms, duplicated functionalities (e.g., optical lightpath protection, SONET APS, MPLS LSP protection switching, IP flow re-routing) can lead to reduced resource utilization and data routing instabilities [DEMEESTER]. For example, optical lightpath recovery times can overlap with (client) SONET or MPLS LSP protection timescales. Clearly, a mechanism is required to coordinate recovery actions between the various layers (packet, circuit, wavelength, fiber). This issue is commonly termed as escalation strategy design and has been treated in the broader research literature [GHANI1]. Specifically, two types of escalation strategies have been proposed, namely bottom-up and top-down approaches, see [DEMEESTER] for full details. The former scheme assumes that "lower-level" recovery schemes (e.g., optical ring protection) are more efficient and expedient, and therefore inhibits higher-layer protection switching (such as IP re-routing or MPLS/ATM LSP protection switching). Alternatively, the top-down approach attempts service recovery at the higher layers first before invoking "lower layer" (e.g., optical) recovery. The reasoning here is that higher-layer protection can be more service selective, and therefore efficient. Clearly, these are both advanced mechanisms and require complex signaling and hold-off timer mechanisms [GHANI2] to coordinate the different layer recovery procedures. Overall, the SLA's between the network operators and their clients will determine the necessary timescales for protection recovery (e.g., 50 ms, 200 ms, 5 minutes, etc) and will also impact escalation strategy design. As far as the proposed optical ring protection framework is concerned, there are two cases of escalation strategies that can be derived, namely MPLS (GMPLS) control-specific, and non-MPLS (non-GMPLS) control-specific. Consider the former case, in which the "higher layers" (e.g., TDM circuit, packet LSP) are also controlled (provisioned and protected) by the MPLS (GMPLS) framework. Assuming a generalized MPLS LSP restoration framework [XU] at all layers, escalation strategy timing is facilitated by this common control framework. The appropriate LSP protection timer mechanisms can specify hold-off times, alarm message (FIS) spacings, and alarm message durations. Clearly, judicious choices of these parameters at different LSP levels (packet, circuit, wavelength lightpath, fiberpath) can be used to design advanced "inter-layer" escalation strategies. For example, at the wavelength LSP level, small hold-off times and FIS spacings can be used to enact fast (sub-50 ms) recovery. Additionally, the duration of lightpath-level FIS messaging can be restricted to a timescale window, beyond which lightpath FIS notification is terminated. This duration (plus an acceptable guard-time) can be the hold-off time for "higher-layer" packet LSP FIS message generation. Note that this example details a "bottom-up" recovery case, and a complimentary "top-down" case can also be detailed. Specifically, lightpath recovery hold-off times can be set larger than packet LSP notification durations, thereby permitting more selective "per-LSP" re-routing (based upon priorities, policies, etc). However, given the increased signaling requirements of such an approach, many operators may not find it very attractive in practical network settings. Meanwhile, for non-MPLS (non-GMPLS) control specific case, escalation strategy design can be more complicated since generalized timing control and signaling mechanisms may not exist at all protocol layers. In particular, this situation will arise if MPLS (GMPLS) protection is not used at the various networking "levels", e.g., O-APS at optical lightpath level, SONET APS at the circuit tributary level, MPLS LSP protection at flow level, etc. In general, this makes it more difficult to control inter-layer protection recovery timings. In such cases, simpler "all-or-nothing" interworkings are more feasible. For example, for the case of traditional SONET over WDM rings, either optical ring or SONET APS recovery can be disabled. Nevertheless, for higher-layer IP packet traffic, "bottom-up" escalation strategies can usually be implemented safely by simply ensuring small enough FIS message windows, i.e., versus IGP re-routing timescales. In general, escalation strategy design (both MPLS, non-MPLS based) needs significant further attention. 3.3 Additional Considerations Albeit detailed, the above discussions have only focused on basic optical ring definitions and provisioning issues. Clearly, much more advanced concerns relating to optical rings can be tabled, but their detailed treatment is beyond the scope of this document. Nevertheless, a brief synopsis is presented in order to stimulate further work. 3.3.1 Multi-Ring Provisioning In most current SONET networks, multi-ring architectures are very common. Specifically, smaller rings are used to aggregate traffic from local domains onto larger rings spanning increased distances (metro, regional), and standards exist for interconnection between multiple SONET rings [GR1230]. Likewise, as optical rings emerge (most likely re-using much of the existing SONET ring fiber infrastructures), there will be a strong requirement for similar O-ADM ring interworkings, namely to route lightpaths spanning multiple rings. Inter-connection can be achieved by simpler, static "back-to-back" O-ADM co-location or via more advanced, dynamic OXC switching devices [ARIJIS]. Now conceivably, different optical ring types (e.g., O-BLSR, O-BLSR, O-UPSR) can be used for an end-to-end circuit connection, along with their respective "localized" protection mechanisms (i.e., protection zones). Clearly, this may also permit greater latitudes in user SLA definitions. >From a routing/provisioning point of view, there are various ways to handle such "multi-ring" architectures. In the longer run (and for larger rings) it may be desirable to group individual rings into separate domains, e.g., autonomous systems (AS), and therefore perform multi-ring provisioning under the broader context of inter-domain provisioning [GHANI1],[GUO2],[PAPADIMITRIOU2],[RAJAGOPALAN]. Most likely, this will require enhancements to emerging (optical) network interface (O-NNI) definitions [PAPADIMITRIOU2], e.g., signaling requirements for channel provisioning (i.e., setup) and protection switching between multiple rings. Alternatively, a more immediate case is that of intra-domain provisioning between rings, especially where multiple smaller rings constitute a domain, i.e., single ring represents an area instead. Now since opaque LSAs only have area scope, further work is required in order to define summary LSAs to provide enough information for inter-ring (i.e., intra-domain) provisioning, yet without flooding the network. 3.3.2 Mesh-Ring Interworking A further evolution of multi-ring provisioning can be considered as more generic mesh-ring provisioning. As optical mesh optical networks evolve, mesh channel protection schemes can also leverage off of ring protection schemes. Specifically, mesh span protection or mesh end-to-end channel protection (via diverse routing) can re-use (extend) the (working, protection) channel setup and protection signaling mechanisms developed for optical rings. In fact, this analogy can be taken one step further in the form of "virtual rings." Here, different ring types (O-UPSR, O-BLSR, O-BPSR) can be overlaid on top of generic mesh networks, thereby exploiting the advantages of fast ring-based protection switching. Such overlay applications are a very powerful feature, especially for operators familiar with operating ring networks, and will allow them to provision virtual private optical rings (VPOR). Although various extensions are required, early work along these lines is emerging [GUO2], e.g., "ring ID" and "ring type" sub-TLV's for opaque LSA. 3.3.3 Sub-Wavelength Tributary Rings So far, only "full-granularity" lightpaths have been considered, i.e., ring channels utilizing full wavelength capacity, such as OC-48, OC-192. However, new generations of advanced integrated edge devices (IED's) are beginning to appear, integrating packet, circuit (i.e., sub-rate lambda), and wavelength switching capabilities into a single box. In a timely manner, the broader MPLS framework is also being extended to provision related sub-rate tributary channels (e.g., OC-12, OC-3, even DS3) [ASHWOOD],[XU]. Therefore, for true generality, future ring provisioning mechanisms must also apply to sub-rate tributary channels. Sub-rate rings can improve wavelength utilization and provide more granular connectivity between smaller users. As a result, advanced "multi-ring" architectures can be envisioned, with "embedded" sub-rate ring channels (LSP's) being carried in larger granularity wavelength ring channels. Here, a given sub-rate channel can traverse multiple wavelength channels (depending upon location of the IED nodes). Again, escalation strategies will be required here to arbitrate between multiple different ring protection mechanisms, akin to O-BPSR/O-BLSR interworking, e.g., Section 2.2.1. However, for this particular case, the escalation strategies can be built into a single protocol, such as the O-APS protocol, simplifying the architecture. 3.3.4 Resilient Packet Ring (RPR) Synergies Similarly, there has recently also been significant interest and development in resilient packet ring (RPR) architectures and IP over resilient packet rings (IPoRPR)[HERRERA]. Since these rings operate on a "higher" level and require visibility into the data stream, they are markedly different from the optical rings proposed herein. However, RPR's can be embedded onto optical wavelength ring channels, and given the increased detection/recovery speeds being proposed (in comparison to IP re-routing or LSP recovery), there can be a much higher likelihood of protection "collisions" between optical ring and RPR recovery mechanisms. Hence protection escalation strategies will be needed for arbitration between the respective ring protocols (packet, circuit). Additionally, traffic/resource engineering synergies are also possible, and all of these topics need further investigation. 4. APPENDIX A: Review of SONET Ring Architectures SONET (SDH) ring architectures have emerged to dominate the transport landscape. Termed also as self-healing rings (SHR), perhaps their defining characteristic is stringent recovery timescales. Namely, SONET (and SDH) standards stipulate a service recovery time of 50 ms after the fault condition (i.e., including detection, guard time, switching time, ring propagation delays, and re-synchronization). These values are derived from frame synchronization at the lowest frame speed, namely DS1 (1.5 Mb/s). A very brief outline of the SONET ring framework is given here. However, this summary is only intended to serve as a background reference, and interested readers are referred to the specifications for complete details [ANSI],[ITU], [GR1230]. As will be seen, these existing architectures will form the basis for much of the counterpart optical ring frameworks. 4.1 Uni-directional Path-Switched Ring (UPSR) The UPSR concept is designed for channel level protection in two-fiber rings. Although two-fiber BLSR architectures also exist, termed BLSR/2, the UPSR architecture is significantly less complex. UPSR rings dedicate one fiber for working TDM channels (timeslots) and the other for corresponding protection channels (counter-propagating directions). Traffic is permanently bridged at the head-end and sent along both fibers, namely 1+1 protection. UPSR working traffic travels in the clockwise direction and protection traffic travels in the counter- clockwise direction. This implies that bi-directional connections will consume resources on all working and protection fibers, restricting ring throughput to that of a single fiber. Clearly, UPSR rings represent simpler designs and do not require any notification or switchover signaling mechanisms between ring nodes, i.e., receiver nodes perform channel switchovers. As such, they are resource inefficient since they do not re-use fiber capacity (both spatially and between working/protection paths). Moreover, span (i.e., fiber) protection is undefined for UPSR rings, and such rings are typically most efficient in access rings where traffic patterns are concentrated around collector hubs. 4.2 Bi-Directional Line Switched Ring (BLSR) BLSR rings are designed to protect at the line (i.e., fiber) level, and there are two possible variants, namely two-fiber (BLSR/2) and four- fiber (BLSR/4) rings. The BLSR/2 concept is designed to overcome the spatial reuse limitations associated with two-fiber UPSR rings and only provides path (i.e., line) protection. Specifically, the BLSR/2 scheme divides the capacity timeslots within each fiber evenly between same-direction working and protection channels (with working channels on a given fiber being protected by protection channels on the other fiber). Therefore bi-directional connections between nodes will now traverse the same intermediate nodes but on differing fibers. This allows for sharing loads away from saturated spans and increases the level of spatial re-use (sharing), a major advantage over two-fiber UPSR rings. Protection slots for working channels are pre-assigned based upon a fixed odd/even numbering scheme, and in case of a fiber cut, all affected timeslots are looped back in the opposite direction of the ring. This is commonly termed "loop-back" line/span protection and avoids any per-channel processing. However, loop-back protection increases the distance and transmission delay of the restored channels (nearly doubling path lengths in the worst case). More importantly, since BLSR rings perform line switching at intermediate nodes, more complex active signaling functionality is required. Further bandwidth utilization improvements can also be made here by allowing lower- priority traffic to traverse on idle protection spans. Four-fiber BLSR rings extend upon the BLSR/2 concepts by providing added span switching capabilities. In BLSR/4 rings, two fibers are used for working traffic and two for protection traffic (counter- propagating pairs, one in each direction). Again, working traffic can be carried in both directions (clockwise, counter-clockwise), and this minimizes spatial resource utilization for bi-directional connection setups. Line protection is used when both working and protection fibers are cut, looping traffic around the long-side path. If, however, only the working fiber is cut, less disruptive switching can be performed at the fiber level. Here, all failed channels are switched to the corresponding protection fiber going in the same direction (and lower-priority channels pre-empted). Overall, the BLSR/4 ring capacity is twice that of the BLSR/2 ring, and the four- fiber variant can handle more failures. Also, it should be noted that both two- and four-fiber rings provide node failure recovery for pass-through traffic. Essentially, all channels on all fibers traversing the failed node are line switched away from the node. As mentioned above, BLSR rings (unlike UPSR rings) require a protection signaling mechanism. Since protection channels can be shared, each node must have global state, and this requires state signaling over both spans (directions) of the ring. This is achieved via an automatic protection switching (APS) protocol running on the "embedded" K1/K2 bytes in the SONET frame overhead (commonly also termed as the K1/K2 byte protocol) [GR1230]. This protocol uses a 4-bit node identifier (in the K1 byte) and hence only allows up to 16 nodes per ring. Additional bits are designated to identify the type of function requested (e.g., bi-directional or unidirectional switching) and the fault condition (i.e., channel state). Control nodes performing the switchover functions utilize frame-persistency checks to avoid premature actions and discard any invalid message codes. Further details can be found in [GR1230]. 5. Security Considerations Security considerations are for future study, in particular with regards to signaling extensions and a possibly new O-APS protocol. The overall optical ring provisioning framework, however, poses the same security requirements as those present in existing MPL(ambda)S or GMPLS provisioning architectures. 6. References [ABOULMAGD] O. Aboul-Magd, et al, "Signaling Requirements of the Optical UNI," Internet Draft, draft-bala-mpls-optical-uni-signaling- 01.txt, November 2000. [ANSI] "Synchronous Optical Network (SONET): Basic Description Including Multiplex Structure, Rates, and Formats," ANSI T1.105-1995, 1995. [ARIJS] P. Arijs, et al, "Design of Ring and Mesh Based WDM Transport Networks," Optical Networks, July 2000. [ARVIND] K. Arvind, et al, "Optical Domain Service Interconnect (ODSI) Signaling Control Specification," Version 1.4.5, ODSI Coalition, November 2000. [ASHWOOD] P. Ashwood-Smith, et al, "Generalized MPLS-Signaling Functional Description," Internet Draft, draft-ietf-mpls-generalized- signaling-01.txt, November 2000. [AWDUCHE] D. Awduche, Y. Rekhter, J. Drake, R. Coltun, "Multi-Protocol Lambda Switching: Combining MPLS Traffic Engineering Control with Optical Crossconnects," Internet Draft, draft-awduche-mpls-te- optical-00.trt, October 1999. [BERNSTEIN] G. Bernstein, V. Sharma, "Some Comments on GMPLS and Optical Technologies," Internet Draft, draft-bernstein-gmpls-optical-00.txt, November 2000. [BHANDARI] R. Bhandari, S. Sankaranarayanan, E. Varma, "High-Level Requirements for Optical Shared Mesh Restoration," Internet Draft, draft-bhandari-optical-restoration-00.txt, May 2001. [CEUPPENS] L. Ceuppens, et al, "Performance Monitoring in Photonic Networks in Support of MPL(ambda)S," Internet Draft, draft-ceuppens- mpls-optical-00.txt, March 2000. [CHEN] J. Chen, T. Shiragaki, "Routing of OCh Shared Protection Ring," T1X1 Forum, T1X1.5/99-256R1, October 1999. [CVIJETIC1] M. Cvijetic, T. Shiragaki, "Standardization of OCh Shared Protection Ring and Its Open Issue List," T1X1 Forum, T1X1.5/99-255R1, October 1999. [CVIJETIC2] M. Cvijetic, T. Shiragaki, A. Weissberger, "OCh Shared Protection Ring," T1X1 Forum, T1X1.5/99-178, July 1999. [DEMMESTER] P. Demmester, et al, "Resiliency in Multilayer Networks," IEEE Communications Magazine, March 2000. [DOSHI] B. Doshi, et al, "Optical Network Design and Restoration," Bell Labs Technical Journal, January-March 1999. [DOVOLSKY] D. Dovolsky, I. Bryskin, "Calculation of Protection Paths and Proxy Interfaces in Optical Networks Using OSPF," Internet Draft, draft-dovolsky-bryskin-ospf-pathprotect-proxy-00.txt, June 2000. [DUTTA] R. Dutta, G. Rouskas, "A Survey of Virtual Topology Design Algorithms for Wavelength Routed Optical Networks," Optical Networks, January 2000. [FREDETTE] A. Fredette, et al, "Link Management Protocol (LMP) for WDM Transmission Systems," Internet Draft, draft-fredette-lmp- wdm-00.txt, December 2000. [GHANI1] N. Ghani, "Lambda-Labeling: A Framework for IP over WDM Using MPLS," Optical Networks, April 2000. [GHANI2] N. Ghani, "Survivability Provisioning in Optical MPLS Networks," 5th European Conference on Networks and Optical Communications, June 2000. [GHANI3] N. Ghani, et al, "COPS Usage for ODSI," Version 2, ODSI Coalition, August 2000. [GR1230] GR-1230-CORE, SONET Bi-directional Line-Switched Ring Equipment Generic Criteria, Issue 4, December 1998. [GR3009] GR-3009-CORE, Optical Cross-Connect Generic Requirements, Issue 1, January 1999. [GUO1] D. Guo, et al, "Extensions to RSVP-TE for Bi-directional Optical Path Setup," Internet Draft, draft-sorrento-rsvp-bi- osp-00.txt, July 2000. [GUO2] D. Guo, et al, "Hybrid Mesh-Ring Optical Networks and Their Routing Information Distribution Using Opaque LSA," Internet Draft, draft-guo-optical-mesh-ring-00.txt, December 2000. [HERRERA] A. Herrera, et al, "A Framework for IP Over Resilient Packet Rings," work in progress, January 2001. [HUANG] C. Huang, V. Sharma, S. Makam, K. Owens, "Extensions to RSVP- TE for MPLS Path Protection", Internet Draft, draft-chang-rsvpte-path- protection-ext-00.txt, June 2000. [ITU] "Network Node Interface for the Synchronous Digital Hierarchy (SDH)," International Telecommunication Union, G.707, March 1996. [KINI1] S. Kini, M. Kodialam, T. V. Lakshman, "Open Shortest Path First (OSPF) Protocol Extensions for Label Switched Path Restoration," Internet Draft, draft-kini-ospf-lsp-restoration-00.txt, October 2000. [KINI2] S. Kini, M. Kodialam, T. V. Lakshman, "Shared Backup Label Switched Path Restoration," Internet Draft, draft-kini-restoration- shared-backup-00.txt, October 2000. [KOMPELLA1] K. Kompella, et al, "OSPF Extensions in Support of MPL(ambda)S," Internet Draft, draft-kompella-ospf-ompls- extensions-00.txt, July 2000. [KOMPELLA2] K. Kompella, et al, "IS-IS Extensions in Support of MPL(ambda)S," Internet Draft, draft-kompella-isis-ompls- extensions-00.txt, July 2000. [KOMPELLA3] K. Kompella, et al, "Extensions to IS-IS/OSPF and RSVP in Support of MPL(ambda)S," Internet Draft, draft-kompella-mpls- optical-00.txt, March 2000. [LANG] J. Lang, et al, "Link Management Protocol (LMP)," Internet Draft, draft-lang-mpls-lmp-01.txt, July 2000. [MARCENAC] D. Marcenac, "Benefits of Wavelength Conversion in Optical Ring-Based Networks," Optical Networks, April 2000. [MANCHESTER] J. Manchester, P. Bonenfant, C. Newton, "The Evolution of Transport Network Survivability," IEEE Communications, August 1999. [MCADAMS] L. McAdams, J. Yates, K. Bala, "User to Network Interface (UNI) Service Definition and Lightpath Attributes," OIF Forum, OIF2000.061, September 2000. [OWENS1] K. Owens, et al, "A Path Protection/Restoration Mechanism for MPLS Networks", Internet Draft, draft-chang-mpls-path- protection-02.txt, November 2000. [OWENS2] K. Owens, V. Sharma, M. Oommen, "Network Survivability Considerations for Traffic Engineered IP Networks", Internet Draft, draft-owens-te-network-survivability-00.txt, March 2000. [OWENS3] K. Owens, et al, "Extensions to CR-LDP for MPLS Path Protection," Internet Draft, draft-owens-crldp-path-protection- ext-00.txt, December 2001. [PAPADIMITRIOU1] D. Papadimitriou, et al, "Inference of Shared Risk Link Groups," Optical Internetworking Forum, OIF2001.066, January 2001. [PAPADIMITRIOU2] D. Papadimitriou, et al, "Optical Network-to-Network Interface Framework and Signaling Requirements," Internet Draft, draft-papadimitriou-onni-frame-01.txt, November 2000. [RAJAGOPALAN] B. Rajagopalan, et al, "IP Over Optical Networks- A Framework," Internet draft, draft-many-optical-framework-02.txt, November 2000. [SOULLIERE] M. Soulliere, "Proposed ITU-T Contribution on Transparent OCh SPRings," T1X1 Forum, T1X1.5/2001-027, January 2001. [SZERENYI] L. Szerenyi, "Approach to OSC Standardization," T1X1 Forum, T1X1.5/2001-002, January 2001. [XU] Y. Xu, et al, "Generalized MPLS Control Plane Architecture for Automatic Switched Transport Network," Internet Draft, draft-xu-mpls- ipo-gmpls-arch-00.txt, November 2000. [XUE] Y. Xue, et al, "Carrier Optical Services Framework and Associated UNI Requirements," Internet Draft, draft-many-carrier-framework- uni-00.txt, November 2000. [YU] J. Yu, et al, "RSVP Extensions in Support for OIF Optical UNI Signaling," Internet Draft, draft-yu-mpls-rsvp-oif-uni-00.txt, July 2000. [ZANG] H. Zang, J. Jue, B. Mukherjee, "A Review of Routing and Wavelength Assignment Approaches for Wavelength-Routed Optical WDM Networks," Optical Networks, January 2000. 7. Authors Information Nasir Ghani James Fu Sorrento Networks Inc. Sorrento Networks Inc. Email: nghani@sorrentonet.com Email: jfu@sorrentonet.com Dan Guo Xinyi Liu Sorrento Networks Inc. Sorrento Networks Inc. Email: dguo@sorrentonet.com Email: xliu@sorrentonet.com Zhensheng Zhang Paul Bonenfant Sorrento Networks Inc. Photuris Inc. Email: zzhang@sorrentonet.com Email: pbonenfant@photuris.com Leah Zhang Antonio Rodriguez Moral Photuris Inc. Photuris Inc. Email: lzhang@photuris.com Email: arodmor@photuris.com Murali Krishnaswamy Xiaowen Mang Photuris Inc. Photuris Inc. Email: murali@photuris.com Email: xmang@photuris.com Sudheer Dharanikota Raj Jain Nayna Networks Inc. Nayna Networks Inc. Email: sudheer@nayna.com Email: raj@nayna.com 8. Full Copyright Notice Copyright (C) The Internet Society (1997). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.