Internet DRAFT - draft-ghani-optical-rings
draft-ghani-optical-rings
Internet Draft Nasir Ghani
Expiration: September 2001 James Fu
Dan Guo
Xinyi Liu
Zhensheng Zhang
Sorrento Networks Inc
Paul Bonenfant
Leah Zhang
Antonio Rodriguez Moral
Murali Krishnaswamy
Photuris Inc
Dimitri Papadimitriou
Alcatel
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
Ghani et. al. [Page 1]
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 MPL(ambda)S/GMPLS 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
optical rings and ensure its proper integration within the emerging
MPL(ambda)S/GMPLS architecture. Along these lines, the various optical
ring schemes are summarized and their associated dynamic provisioning
concerns detailed.
Table of Contents
1 Introduction ............................................... 4
2 Framework for Optical Rings ................................ 5
2.1 Dedicated Path Protection Rings (DPRING) .............. 7
2.2 Shared Protection Rings (SPRING) ..................... 9
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 ........................ 17
3 Dynamic Provisioning Issues ............................... 19
3.1 Channel Setup Requirements ........................... 19
3.1.1 Signaling Extensions ............................. 20
3.1.2 Resource and State Dissemination ................. 21
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 ................................... 28
3.2.3 Multi-Layer Escalation Strategies ................ 30
3.3 Additional Considerations ............................ 32
3.3.1 Multi-Ring Provisioning .......................... 32
3.3.2 Hybrid Mesh-Ring Interworking .................... 33
3.3.3 Resilient Packet Ring (RPR) Synergies ............ 34
4 Appendix A: Review of SONET Ring Architectures ............ 35
4.1 Uni-directional Path-Switched Rings (UPSR) ........... 35
4.2 Bi-directional Line-Switched Rings (BLSR) ............ 36
5 Security Considerations ................................... 37
6 References ................................................ 37
7 Authors Information ....................................... 41
8 Full Copyright Notice ..................................... 41
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
Ghani et. al. [Page 2]
DPRING: Dedicated protection ring
DRI: Dual ring interconnection
DWDM: Dense wavelength division multiplexing
DXC: Digital cross-connect
EXC: Electronic cross-connect (electronic cross-point switch)
FIS: Failure indication signal
FRS: Failure recovery signal
GFP: Generic framing protocol (for data over SONET/SDH)
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
LOL: Loss of light
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
OC-n: Optical carrier
OCh: Optical channel
OMS: Optical multiplex section
OPU: Optical payload unit
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
PXC: Photonic cross-connect switch
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
SNCP: Sub-network connection protection
SPRING: Shared protection ring
SONET: Synchronous optical network
SRLG: Shared risk link group
STM: Synchronous transfer module
TCP: Transport control protocol
Ghani et. al. [Page 3]
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 SONET/SDH rings all the way from
the long-haul backbone to the metropolitan and regional areas. Most
larger backbone rings represent significant investments on the
part of service providers, and expectedly will have longer lifetimes.
Additionally, in the regional metro space, hierarchical SONET/SDH
ring architectures are also very commonplace. For example, at the
access-side, smaller (optical carrier/synchronous transfer module)
OC-3/STM-1 (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/STM-4 (622 Mb/s) and possibly OC-48/STM-16
(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/STM-64 (10 Gb/s). As a result, ring architectures will clearly
play a major role in the evolution of optical networks.
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/
regional and even long-haul networks, helping operators ease their
transition to future optical (mesh or hybrid ring-mesh) networks.
Since many operators have significant experience in deploying and
maintaining SONET/SDH rings, future optical analogs of such 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 ring network elements [MARCENAC].
Optical 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, ADM-based ring
architectures are well-known for their operational simplicity and
inherently fast protection switching capabilities, and perhaps, this
is the main reason for the widescale acceptance of SONET/SDH technology.
Network operators have become well-accustomed to the fast, timely
recovery capabilities provided by SONET/SDH automatic protection
switching (APS) schemes, such as uni-directional path switched rings
(UPSR)/1+1 sub-network connection protection (SNCP) and bi-directional
line switched rings (BLSR)/multiplex section shared protection rings
(MS/SPRINGs) [GR1230],[T1.105.01],[G.841]. These architectures can
achieve service recovery within 50 ms after a fault event, via
Ghani et. al. [Page 4]
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) [ASHWOOD1],[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 optical 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/GMPLS 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/GMPLS
framework. As most long-haul optical networks continue to migrate
towards mesh-based GMPLS/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 architecture.
Such a uniform provisioning framework will permit true optical services
provisioning across all network/geographic domains.
In particular, the MPL(ambda)S/GMPLS 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 optical
rings, representing a logical, structured evolution (expansion) from
existing SONET/SDH (TDM) ring paradigms. Optical ring equivalents of
SONET/SDH 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 upon existing TDM SONET/SDH 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., SONET/SDH, ATM, IP, GFP, ESCON, SDL, Gigabit Ethernet, etc.
Note that there are also standardization efforts to define generic
mappings/encapsulations for data protocols, such as the generic framing
procedure (GFP) [GFP] for the optical payload unit (OPUk), as defined
Ghani et. al. [Page 5]
in ITU-T G.709 [G709]. 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/
GMPLS 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) nodes.
With regards to the latter, purely optical nodes can also be further
classified as photonic cross-connect (PXC) nodes. The latter types
(OXC, PXC) are well-suited to larger inter-ring connection (i.e.,
switching) applications, which require added (mesh) spatial switching
capabilities. Note that the terms O-ADM, OXC, and PXC in the context
herein are used to refer to complete ring node systems (and not just
node sub-systems as may be done in a more detailed context).
_ +------------+ _
Demux / |---<o>-->| |---<o>-->| \ Mux
W-E in >----+ |---<o>-->| Lambda |---<o>-->| +----> W-E out
\_|---<o>-->| pass-thru/ |---<o>-->|_/
_ | protection | _
Mux / |<--<o>---| |<--<o>---| \ Demux
E-W out <----+ |<--<o>---| |<--<o>---| +----< E-W in
\_|<--<o>---| |<--<o>---|_/
+------------+
| | | ^ ^ ^ -<o>- 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 ring node (2-fibers shown)
A generic overview of a two-fiber optical ring 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),
digital/electronic cross-point switches (DXC/EXC), or simpler 2x1
switching devices. The add/drop channels help to form the access stage
of a ring node and this is where signals are mapped/de-mapped onto/from
wavelength transmitters/receivers. Optionally, O-E designs can perform
edge SONET/SDH (or digital wrappers [G.709]) payload mapping at the
access stage.
Overall, optical ring nodes can exhibit many different levels of
functionality. For example, purely optical add-drop/switching fabrics
are incapable of performing wavelength conversion but offer true signal
format transparency. Conversely, EXC-based designs using opto-
Ghani et. al. [Page 6]
electronic (O-E) conversion techniques will not have wavelength
interchange restrictions, but will reduce signal format transparency.
Therefore, as a tradeoff, "hybrid" designs are also possible, using EXC
switches or tunable lasers to offer partial wavelength conversion
capabilities for selected wavelengths and/or links. Moreover, numerous
studies have shown that partial wavelength conversion capabilities yield
network blocking probabilities close to those achieved with full
wavelength conversion switches (i.e., O-E based). Hence, for the
foreseeable future, optical networks will comprise of non-conversion and
conversion-capable devices. Note that all-optical wavelength conversion
techniques are also being actively researched, but commercial components
are not yet available. Given all these variations of optical ring
nodes, is important to define an optical ring framework that, to the
extent possible, is independent of implementation and encompasses all
(or as many of) these possibilities.
Uni-Directional Rings
=====================
TDM Models WDM Models
========== ==========
2-fiber SONET/SDH UPSR <-----> 2-fiber O-UPSR w. 1+1 OCh-DPRING
Note: WDM 2-fiber O-UPSR (1:1 OCh-DPRING) also conceivable
Bi-Directional Rings
====================
TDM Models WDM Models
========== ==========
2-fiber SONET/SDH BLSR <-----> 2-fiber O-BLSR (OMS-SPRING)
4-fiber SONET/SDH BLSR <-----> 4-fiber O-BLSR (OMS-SPRING)
Note: WDM 2/4-fiber O-BPSR (OCh-SPRING) also possible (path-level)
Figure 2: Mapping between SONET (SDH) and optical ring architectures
To date, the ANSI T1X1 and ITU-T SG15 have been most active with regards
To work/proposals for optical ring architectures, e.g., see [CHEN],
[CVIJETIC1-2],[SOULLIERE]. Although this work 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. The general relationship between SONET/SDH and
proposed/emerging WDM (optical) shared/dedicated ring architectures is
shown in Figure 2, and details are discussed subsequently. More specific
provisioning (signaling) requirements are treated in Section 3. Note
that the terms optical channel and lightpath are used in an
interchangeable manner to represent wavelength circuits. Furthermore,
the prefix "O" is used to identify "optical" ring concepts, in order to
clearly discern them from existing TDM ring (SONET/SDH) 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
Ghani et. al. [Page 7]
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 is 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, with bi-directional connections consuming wavelength
resources on all fibers, i.e., permanent head-end bridging. This OCh-
DPRING scheme is shown in Figure 3 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 transmitters). Since
receiver-based switchovers are performed, no complex signaling protocols
are required for 1+1 optical protection unless 1+1 bi-directional
switching is employed (see [MANCHESTER1]). However, there is normally
an added power penalty when performing optical head-end bridging, e.g.,
if a single laser's output signal is head-end bridged [SOULLIERE].
Node A Node B
+--------+ +--------+
******************************************* |
| # | | * |
| # |------------------| * |
+------#-+ +------*-+
| # ** Working | *
| # ## Protection | *
| # (permanently | X<--Fiber
| # bridged) | * cut
| # | *
+------#-+ +------*-+
| ############################*****> A-D
| | | |
| |------------------| |
+--------+ +--------+
Node C Node D
Figure 3: 1+1 wavelength path protection (2-fiber OCh-DPRING)
Additionally, signaled 1:1 protection is also conceivable for 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 that has yet to be specified, a
major task. However, note that overhead bytes have been proposed in the
ITU for the OMS level, as per G.709 [G.709], and these can be used for
conveying APS signaling. Although 1:1 channel protection improves upon
idle resource utilization here, 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 4, where the lower-priority lightpath C-D
occupies a protection wavelength/span for lightpath A-D. Overall,
however, signaled protection is mostly proposed for more advanced shared
Ghani et. al. [Page 8]
(line, path) ring architectures, Section 2.2. Note that the co-
existence of both 1+1 and 1:1 OCh protection mechanisms in the same two-
fiber DPRING may also be possible (i.e., since the underlying fiber/
wavelength plan is the same). However this issue requires further,
more careful investigation of non-homogeneous ring behaviors.
Node A Node B
+--------+ +--------+
******************************************* |
| # | | * |
| # | | * |
| # |------------------| * |
+------#-+ +------*-+
| # ** Working | *
| # ## Path | *
| # @@ Low Priority | X<--Fiber
| # (pre-emptable) | * cut
| # | *
+------#-+ +------*-+
| ############################*****> A-D
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@> C-D
| | | |
| |------------------| |
+--------+ +--------+
Node C Node D
Figure 4: 1:1 wavelength path protection (2-fiber OCh-DPRING)
Note that depending upon the ring node's fault detection mechanism,
switchover signaling can be actuated using a variety of methods (see
Section 2.4, Section 3.2). For example, translucent designs using
"inband overhead" monitoring (as defined by SONET B1-bytes [GR1230]
or digital wrappers defect indicator bytes [G.709]) can detect
progressive signal degradation and estimate bit-error rate (BER)
values, etc. Inband overhead byte monitoring can also be used to
detect progressive signal degradation. Alternatively, for transparent
optical rings, optical monitoring techniques, such as power or
signal-to-noise ratios (SNR) can be used to detect fiber (or
wavelength) faults, Section 2.4.
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
traffic demand 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
the optical channel (OCh) level, respectively. In all such schemes, bi-
Ghani et. al. [Page 9]
directional connections between two endpoint nodes must traverse the
same set of intermediate nodes. Details are now presented (see also
[ARIJIS]).
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
adjacent 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 that opposing directions will be routed on the same
side (i.e., through common nodes) but use different fibers. Note that
the intra-fiber wavelength plan requirement of O-BLSR/2 rings complicates
ring node design (e.g., if O-E based or all-optical based). Also, for
all-optical rings, added wavelength numbering qualifications are required
to enforce the wavelength-continuity constraint. In particular, the
actual wavelength values within each group (working, protection) 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-E) node designs, where wavelength values can also be
interchanged upon protection switching.
Node A Node B
@
+---------+ +-------@-+
| | | @ |
*********************************************@ |
| | | *@ |
| oooooooooooooooooooooooooooooo*@ |
| o#############################*@ |
Ghani et. al. [Page 10]
+------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 5: Loop-back span protection (O-BLSR/2)
Two-fiber OMS-SPRING (O-BLSR/2) protection is possible using "loop-
back" protection (i.e., conceptually similar 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 5.
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 and other parameters will likely further
hinder applicability, especially 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
| |<--------------------| |
| | | |
| |-------------------->| |
Ghani et. al. [Page 11]
| | | |
| |<--------------------| |
+-----------+ +-----------+
Node C Node D
Figure 6: 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 6 (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 6, 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
individual channel (time-slot) failures within the ring were considered
relatively rare. However, when considering the types of failures that
optical rings may be required to protect against, yet another type of
SPRING design may emerge as a more viable alternative to a simpler
optical analog of two- and four-fiber multiplex-section SPRING's, namely
the optical channel-level SPRING (OCh-SPRING). Specifically, for the
case of both all-optical and transponder-based (i.e., translucent)
optical rings, the need arises to protect against isolated opto-
electronic (source or intermediate wavelength transmitter/receiver)
failures that will affect only a single optical channel entity at a time.
This implies the need for a protection architecture that performs OCh-
level switching, based upon OCh-level indications, independently for
Ghani et. al. [Page 12]
each optical channel on the ring. As the OMS-SPRING switches based upon
OMS-level failure indications, and switches all optical channel entities
as a group within the OMS, it is incapable of protecting lightpath
connections independently of one another based upon OCh-level failure
indications. A protection architecture that can protect optical channels
individually based upon per-channel failure indications is the OCh-SPRING
[MANCHESTER1], as facilitated by per-wavelength routing/processing/
monitoring capabilities. In other words, this is essentially the optical
bi-directional path switched ring (O-BPSR) concept for shared protection
rings. 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 7: Bi-directional path protection schemes (O-BPSR/2)
The O-BPSR/2 proposal is based upon 1:1 wavelength protection (i.e.,
signaled switchover) and utilizes the same wavelength plan as its line-
switching counterpart, O-BLSR/2. The scheme implements 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 7. 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 (see Section 2.4), 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.
Ghani et. al. [Page 13]
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. Additionally, customers transporting relatively low-
priority (cost) traffic may be satisfied with pre-emptable lightpath
connections, namely ones that can be dropped (squelched) in the favor
of allocating resources to higher-priority connections (e.g., at
call setup request or protection switching times). These multiple
levels of protection/sharing (e.g., 1:1 dedicated, 1:1 shared,
1:N shared, pre-emptable) will allow operators to define several
differing classes (or 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 ring nodes. O-BPSR/4 protection schemes are largely
variations of 1:1 protection switching scheme, as illustrated for a
single direction in Figure 8. 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 ^ *
Ghani et. al. [Page 14]
| | | # ## 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 8: 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 8. Meanwhile, to minimize the drop-rate of possible low-
priority connections using the protection wavelengths (and to an extent,
to also reduce signaling overheads), intermediate near-side path
switching can be considered. This form of protection switching only
performs partial working path re-routing, as illustrated for lightpath
A-D in Figure 8, 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 adjacent ring 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 optical ring 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/OCh-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, although implementation concerns can
be more challenging. Here, "batch" control commands (to switch
multiple wavelengths) can be developed, since all wavelengths on a
failed span are re-routed along a common route. Furthermore, 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
ring schemes.
Ghani et. al. [Page 15]
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.
Various such mechanisms are conceivable, either signaling or non-
signaling based (for possible further study). 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. As an example, co-existence between channel (O-BPSR)
and line (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 OCh (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 that 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
is concerned, there is no interaction and hence this approach is termed
as out-band. Note that the OSC channel will require appropriate
hardware support (filters, receivers, laser transmitters, etc).
Recently efforts are beginning to emerge for defining a broad range
of OSC standards, see [FREDETTE],[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
Ghani et. al. [Page 16]
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, typically for SONET/
SDH in-band signaling transport. 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 are also being 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/SDH 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 [CEUPPENS],[GHANI2],
[MANCHESTER1].
Many first-generation and even current-generation WDM systems simply
re-use existing SONET/SDH 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/SDH framing, also essentially embodies
a similar O-E based solution, e.g., forward/reverse defect indicator
(FDI/RDI) bytes, etc [G.709]. Since most operators are quite familiar
with SONET/SDH 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-defined
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
Ghani et. al. [Page 17]
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/SDH payload types, and analyze such parameters as fiber/
wavelength (optical signal) power levels, optical signal-to-noise ratios
(O-SNR), 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)/loss of light (LOL) fault, and
can trigger various protection actions, such as 1+1 receiver switchovers
or fault/alarm messaging. 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) is hindering its
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 approach is not cost-effective at all for large channel
counts (i.e., hundreds of wavelengths, as per DWDM). Nevertheless,
such per-wavelength monitoring capabilities inside the network core
will be needed in order 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. Further adding in transient
switching times (milliseconds range), achieving the "50 ms" SONET/SDH
recovery time ceiling may prove difficult. 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 network designers
may actually want to use optical monitoring techniques to complement
capabilities in opaque networks, e.g., observe 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 inside the network (between
the edge points), thereby precluding excessive (expensive) O-E
conversions or OCh-level optical monitoring. Instead, fault isolation is
only done at the channel edge points. This can be achieved using a
variety of techniques, implemented in the appropriate receiver/interface
cards (either optical power monitoring or electronic frame monitoring
after O-E conversion). All that is required is that the channel
protection sub-path be "dis-joint" (Section 3.1.2) from the working
paths. This approach is very attractive in all-optical networks (both
ring and mesh), where operators request service transparency with
"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. Note here
that the "edge" regions can either comprise single rings (i.e., SNC
portion) or a series of rings (or hybrid ring-meshes), forming a larger
(optical) sub-domain (also see discussions in Section 3.3.1).
Ghani et. al. [Page 18]
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) use IP addressing schemes and run extended MPLS
routing and generalized signaling protocols, i.e., lambda switch routers.
More importantly, recent proposals for a generalized MPLS (GMPLS)
[ASHWOOD1] framework are furthering this trend, extending basic MPLS
concepts to provision more generalized label switched path (G-LSP)
entities, e.g., TDM circuits via SONET ADM's, lightpaths via wavelength
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]. Possibly, these schemes
can also be investigated for their potential applicability to "optical
LSP" (i.e., lightpath) protection. However, in general, due to the
IP-centric origins of the MPLS framework, the above work is generally
tailored for mesh (optical) 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/GMPLS architecture. In particular, two
signaling mechanisms are required for optical rings:
- First, signaling is required for dynamic ring configuration and
lightpath provisioning operations, such as setup/takedown. These
mechanisms must specify both the working and protection entities of the
lightpaths and incorporate all of the intricacies of (ring) protection
switching mechanisms. Ring resource management will also be a critical
part of the provisioning stage.
- Second, a signaling mechanism is required to perform the automatic
protection switching (APS) actions, as determined by related ring
protection schemes, Section 2.
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
>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/GMPLS type protocols for optical mesh provisioning, it is
prudent to choose likewise for ring networks, thereby enabling an even
closer interworking. For optical ring channel setup/takedown, the
overall provisioning capabilities developed under the ubiquitous
MPL(ambda)S/GMPLS frameworks are quite applicable. Namely extensions to
MPLS signaling protocols are already being proposed to handle the
specifics of optical lightpath routing [ASHWOOD2-3],[KOMPELLA1-3],[YU].
However, provisioning ring lightpaths (working, protection) will require
Ghani et. al. [Page 19]
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 various new "signaled"
interfaces [ARVIND],[ABOULMAGD],[MCADAMS],[XUE] along with expanded
features in the 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, digital
wrappers, IEEE Ethernet, etc), bit-rate (2.5 Gb/s OC-48/STM-16, 10 Gb/s
OC-192/STM-64, 1.0 Gb/s 10 Gb/s Ethernet, etc), protection type (shared,
dedicated, enhanced, unprotected), and priority (non-pre-emptable,
pre-emptable), etc, see [ABOULMAGD],[ASHWOOD1]. Provisions have also
been suggested for indicating lightpath diversity levels (e.g., node,
link, etc), see [XUE],[ABOULMAGD]. By and large, these generic
attributes also apply to ring networks, although their detailed usages
and applications require further considerations.
The above-mentioned service definition "attributes" need to be "mapped"
into appropriate signaling messages in order to setup the lightpath
channels (e.g., as per RSVP-TE, CR-LDP signaling [ASHWOOD2-3],
[KOMPELLA3]). Here, a key step in this mapping will be to first
translate the desired (requested) user lighpath attributes into
appropriate ring channel request types, i.e., as per the various types
of optical rings (Section 2). 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 very implementation-
specific and hence should not be the subject of standardization (i.e.,
vendor-value add feature).
Once the user request is properly mapped (on to the ring) and its
lightpath route computed (Section 3.1.3), various MPLS LSP signaling
capabilities can be exploited for the actual setup [ASHWOOD2-3].
Clearly, one such feature is explicit route (ER) signaling, which can
explicitly indicate the required path and reserve resources.
Ghani et. al. [Page 20]
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_REQUEST messages). Additionally, bi-directional channel
setup provisions have also been considered [ASHWOOD2-3],[GUO1], helping
ensure that both uni-directional lightpaths of a bi-directional LSP/G-LSP
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 ring nodes).
Sample proposals for lightpath setup signaling using appropriately
defined TLV objects are presented in [KOMPELLA3],[YU] and the additional
related references therein. Any extensions to the setup signaling
message (object) types for ring channel provisioning need 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 [CHIU],
[BERNSTEIN]) in order to compute ring routes. Consider the first
requirement. Examples of basic static topological information are the
number of fibers, ring 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 ring 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., 1R, 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 within the context of
mesh-routing MPL(ambda)S/GMPLS 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
Ghani et. al. [Page 21]
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 (i.e., LSP/G-LSP) setup phase, lightpath route
computation is performed by utilizing the available network
information (e.g., topology, ring-type, resource levels, 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). As an
aside, generic policy control (management issue) 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] problem. 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,
Ghani et. al. [Page 22]
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 specific objectives, subject to various broad
constraints such as hop counts, wavelength re-use (in given network
segments), propagation delays, protection/priority levels, residual
resources, revenues, risk probabilities, etc. The objectives could either
be resource oriented, namely high resource efficiency, or performance
oriented, such as low blocking probability, etc. Moreover, many ring-
specific lightpath routing algorithms have also been researched, see
[MARCENAC] and related references. Clearly, any ring lightpath RWA
algorithms will be very tightly coupled with the actual ring types (uni-
directional, bi-directional), 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 (e.g., specific renditions of Dijkstra
algorithms) or via centralized route/policy control servers.
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/SDH-type recovery
Ghani et. al. [Page 23]
timescales for protected optical ring services (i.e., 50 ms ceiling), and
meeting this stringent requirement is perhaps the foremost concern when
trying to apply the MPL(ambda)S/GMPLS framework to optical ring control
[GHANI2]. Now for most optical ring types (excluding 1+1 uni-directional
O-UPSR/2 designs), millisecond recovery requires fast "APS-like"
signaling capabilities, akin to the SONET/SDH 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 adjacent optical ring nodes. By developing appropriate switchover
signaling capabilities to implement this generic model, conceivably most
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 an optical APS (O-APS) protocol, to complement the overall
MPL(ambda)S/GMPLS framework. This new protocol would only perform
protection switchover signaling for fault events but not any setup
provisioning (relegated to existing setup signaling mechanisms,
as detailed previously in Section 3.1). These two cases are presented
in a broader context in Figure 9, which shows an example of multi-level
recovery protocols. On the packet routing level, service recovery
actions can be performed by existing IGP path re-computation/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 9. 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 9: Service recovery protocols (packet, flow, circuit levels)
3.2.1 Direct Interworking
It is instructive to first briefly review MPLS LSP protection concepts.
Clearly, simple non-signaled protection is possible by establishing
Ghani et. al. [Page 24]
multiple (LSP) paths between source and destination LSR nodes and
streaming data across these paths, essentially like 1+1 ("make-before-
break") 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 10. 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) / #
# \ / #
# \ +---+ +---+ / #
Ghani et. al. [Page 25]
# +------| F |--------| G |------+ #
# +---+ +---+ #
################################
Figure 10: 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 protection switching in 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 ring 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. Note, further, that the PMTG
concept can be used to group "lambdas" and define appropriate class of
service (CoS) for the optical domain (i.e., from the service protection
perspective).
Ghani et. al. [Page 26]
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. This
implies an "inband" signaling setup. 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 out-band 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 ring node's
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/SDH APS. Here, the RNT
architecture is of particular importance (as detailed above). It is
Ghani et. al. [Page 27]
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/SDH recovery times can be
effectively matched. Otherwise, the advantage of fast protection
switching yielded by ring networks cannot be realized.
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/GMPLS-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 message type, etc. 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 ring 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 an orthogonal addition to the
MPL(ambda)S/GMPLS protocols suite to achieve fast protection signaling,
see Figure 9. 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] the O-APS protocol
should be defined as "fast" packet-based protocol, in order to keep it
in-line with the packet-oriented control philosophy of MPLS networks.
Ghani et. al. [Page 28]
How the O-APS protocol's packet messages are actually transported on
control channels, however, can be left open to vendor implementation,
but likely, bandwidth guarantees will be necessary in order to meet
recovery timing requirements (similar to discussions for FIS message
transport, Section 3.2.1). For example, some vendors may choose to
explicitly map the message bytes into appropriate inband overhead
bytes (e.g., SONET/SDH or digital wrappers bytes). Note that this
case is somewhat different from that of standardizing explicit
signaling bytes, i.e., "non-packetized" O-APS protocol. However,
since protection timing is such a critical issue, some guidelines
will likely be required to ensure satisfactory performance across
larger networks (consisting of multi-vendor equipment). Such
guidelines are for further study and can include guard-band times for
message processing, etc.
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 with likely
longer inter-message periods, 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 (and fast detection 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
Ghani et. al. [Page 29]
important for many vendors who need to provide optical ring solutions,
but at the same time, want to gradually transition into a full-blown
"MPLS-based" control frameworks. In such cases, the orthogonal nature
of the O-APS protocol will allow vendors to either couple its
protection switching features with their own (proprietary) NMS-based
provisioning solutions, or with their MPL(ambda)S/GMPLS-based control
framework. In the former case, an 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, etc. 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.
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 ring 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) can also arise 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
Ghani et. al. [Page 30]
Assuming that fast optical (ring) lightpath protection schemes will
emerge, inter-layer protection "collisions" will be of concern. Since
multiple protocols can provide recovery mechanisms operating across
multiple domains, the simultaneous interference of such functionalities
(e.g., optical lightpath protection, SONET/SDH APS, MPLS LSP protection
switching, IP flow re-routing) can lead to serious shortcomings, such as
reduced resource utilization and data routing instabilities [DEMEESTER],
[MANCHESTER2]. For example, optical lightpath recovery times can overlap
with (client) SONET/SDH circuit 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],[DEMEESTER],[MANCHESTER2].
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, MPLS/ATM LSP protection switching, or SONET/SDH APS).
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. Note that a broader delineation of escalation
strategies is also presented in [MANCHESTER2], i.e., serial and parallel
approaches.
As far as the proposed optical (ring) protection framework is concerned,
escalation strategies can be implemented using either MPLS/GMPLS or
non-MPLS (non-GMPLS) type control-planes. Carefully note that this
pertains to how protection capabilities are initiated and not the
subsequent switching signaling actions. Consider the former case, in
which the "higher layers" (e.g., 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
Ghani et. al. [Page 31]
packet LSP notification durations, thereby permitting more selective "per-
CoS" or "per-LSP/G-LSP" re-routing (based upon priorities, policies, etc).
However, given the increased complexity and signaling requirements of
top-down approaches, many operators may not find them very attractive in
practical network settings.
Meanwhile, for the 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/SDH 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, since inter-layer
synchronization needs to be addressed/defined. For example, optical
(WDM)-SONET/SDH protection interworkings may possibly need SONET/SDH
hold-off timers, requiring changes to existing standards and deployed
equipment [MANCHESTER2], raising even further challenges and complexities.
In such cases, simpler "all-or-nothing" interworkings may be more
feasible. For example, for the case of traditional "SONET-over-WDM",
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 is a complex issue and needs significant investigation.
3.3 Additional Considerations
Albeit detailed, the above discussions have only focused on basic
optical ring definitions and provisioning issues. Clearly, many 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 so-called dual ring interworking
(DRI) interconnection between multiple SONET/SDH rings [GR1230],[G.842].
Likewise, as optical rings emerge (most likely re-using much of the
existing SONET/SDH ring fiber infrastructures), there will be a strong
requirement for similar optical ring interworkings, namely to route
lightpaths in between multiple rings. In addition to applying the
conventional DRI concepts, 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
Ghani et. al. [Page 32]
larger rings) it may be advantageous to move to a hierarchical routing
setup. Specifically, individual rings would be grouped into separate
domains, e.g., autonomous systems (AS), and multi-ring provisioning
would be performed under the broader context of inter-domain
provisioning [GHANI1],[GUO2],[PAPADIMITRIOU2],[RAJAGOPALAN]. Here,
added enhancements to emerging (optical) network interface definitions
(O-NNI) [PAPADIMITRIOU2] may be required, e.g., for setup signaling,
protection switching between multiple rings, etc (further study needed).
Alternatively, a more immediate alternative is that of intra-domain
provisioning between rings, especially where multiple smaller rings
constitute a domain, i.e., single ring represents an area instead.
Here, since opaque LSA's only have area scope, further work is required
in order to define summary LSA's to provide enough information for
inter-ring (i.e., intra-domain) provisioning, yet without flooding the
network with message updates.
3.3.2 Hybrid Mesh-Ring Interworking
Similar to the case of multi-ring provisioning (above), the broader
evolution towards mesh/mesh-ring network topologies is also an important
concern. From an operator migration point of view, both ring and mesh
topologies have their respective advantages/disadvantages. Ring
topologies allow for fast, well-defined protection switching concepts but
have reduced connectivity (degree two). Meanwhile, mesh networks offer
better connectivity and improved resource efficiencies but lack well-
defined protection switching features. Hence, a likely, cost-effective
migration path will be for operators to first migrate their existing
SONET/SDH (TDM-based) rings to counterpart optical rings and then move
towards mesh or "hybrid" mesh-ring topologies, inline with growth in
traffic demand and operational experience. These evolutions can be done
either via phased expansions to existing ring topologies (i.e., adding
fibers between non-adjacent ring nodes to "break" the ring) or altogether
new (i.e., "greenfield-type") deployments. Such cases present two
foreseeable interworking requirements, namely for ring emulation and
ring-mesh interconnection purposes (and others may also emerge) [GUO2].
Either way, it is clear that provisioning features for hybrid topologies
will be a crucial requirement for operators as they move to deploy or
expand their optical network offerings.
On a high level, ring emulation basically entails provisioning/operating
"virtual" rings on top of mesh (network) topologies, e.g., via the
concept of ring covers [PAPADIMITRIOU3]. For operators accustomed to
operating ring networks, this capability will still allow them to expand
to mesh topologies, and is particularly germane to the case of phased-in
ring-to-mesh expansions. For example, different ring types (O-UPSR,
O-BLSR, O-BPSR) can be deployed in selective parts of a mesh network
topology, thereby exploiting the advantages of fast ring-based
protection switching. Additionally, for richly-connected mesh networks,
operators can offer virtual private optical ring (VPOR) services to large
clients, an attractive proposition. Note that ring emulation will
require that specific network nodes (i.e., those sitting on multiple
rings) have more advanced spatial switching characteristics, as yielded
by OXC/PXC designs and not basic O-ADM designs. Moreover, these nodes
must be "ring-enabled", and most notably, be capable of meeting fast
protection switching requirements.
Ghani et. al. [Page 33]
Meanwhile, the issue of ring-mesh interconnection arises when
provisioning lighpath channels across multiple, separate ring and mesh
topologies (e.g., metro-regional rings to long-haul meshes). Here,
the mesh network segments themselves may or may not perform ring
emulation, and therefore this becomes a generalization of the multi-ring
interconnection case (Section 3.3.1). However, many of the concepts
discussed for the multi-ring case, such as intra- and inter-domain
partitioning, are also applicable here. Of particular concern will be
achieving commensurate protection switching timescales in the mesh-
network segments. However, here it is expected that as standards
evolve, many of the optical ring protection switching concepts/protocols
will likely also be leveraged for mesh architectures. For example, mesh
span protection or mesh end-to-end channel protection (via diverse
routing) can re-use or extend the working/protection channel setup and
protection signaling mechanisms developed for optical rings.
Overall, hybrid topology provisioning, for both ring emulation and ring-
mesh interconnection, will require additional specifications.
Considering the more likely case of intra-domain provisioning, topology/
resource discovery methods will need to perform summarization/aggregation
of ring information. Some early work along these lines is emerging,
proposing "ring ID" and "ring type" sub-TLV definitions for opaque LSA's,
see [GUO2],[PAPADIMITRIOU3]. Provisioning lightpaths across ring-mesh
topologies or "virtual ring" mesh networks will require new resource/
constrained-routing algorithms also. A related, key issue here will
be implementing protection switching signaling (as per the user SLA
requirements), e.g., protecting a fiber cut between multiple "virtual"
rings or an optical channel failure across multiple network ring/mesh
network segments. Cleary, there is a strong need for more detailed work
in the area of hybrid topology provisioning.
3.3.3 Resilient Packet Ring (RPR) Synergies
So far, only "full-granularity" lightpaths have been considered, i.e.,
ring channels utilizing full wavelength capacity, such as OC-48/STM-16
and OC-192/STM-64. However, new generations of advanced integrated edge
devices (IED's) are beginning to appear, integrating (sub-rate) packet,
circuit, and wavelength/fiber switching capabilities onto a common
platform. In a timely manner, the broader GMPLS framework is also being
extended to provision related sub-rate tributary channels [ASHWOOD1],
[XU] (both packet and circuit). Therefore, for improved generality,
GMPLS ring provisioning mechanisms/concepts can also be considered for
various "sub-rate ring" architectures. Sub-rate rings can improve
wavelength utilization and provide finer-granularity connections between
smaller users. A very good example of a sub-rate (packet) ring
technology is the emerging resilient packet ring (RPR) architecture
(IEEE 802.17). Recently there has been significant interest and
development in this space, as noted by work on IP over RPR (IPoRPR)
architectures, see [HERRERA].
Since packet rings operate on an "electronic" level and require
visibility into the packet stream, from a technology point of view,
they are quite different from the optical rings proposed herein.
Nevertheless, there are many generic architectural aspects of optical
Ghani et. al. [Page 34]
rings which can also apply to packet rings, and these can be further
investigated. Examples include setup signaling procedures, protection
signaling, constrained routing, etc. Furthermore, RPR's can be mapped
onto optical ring wavelength channels, thereby permitting potential
traffic/resource engineering synergies, i.e., advanced "multi-ring"
architectures with "embedded" sub-rate packet ring channels being
carried in larger granularity optical ring channels. Additionally,
given the fast fault detection/recovery mechanisms being proposed for
RPR designs (in comparison with mesh IP packet re-routing), the
likelihood of protection "collisions" between optical ring and RPR
recovery mechanisms increases. Hence protection escalation strategies
(Section 3.2.3) are of importance in such interworkings and should be
designed to properly arbitrate between the respective protection
protocol(s) or different levels thereof (packet, circuit). All of
these topics need further, more detailed 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/SDH 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.
Ghani et. al. [Page 35]
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 the switching nodes (i.e.,
adjacent to the fault), 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/SDH frame overhead, also commonly
termed as the SONET APS or BLSR K1/K2 byte protocol [GR1230],
[T1.105.01],[G.841]. This protocol uses a 4-bit node identifier (in
the K1 byte) and hence only allows up to 16 nodes per ring. Additional
Ghani et. al. [Page 36]
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 the associated references.
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.
[ASHWOOD1] P. Ashwood-Smith, et al, "Generalized MPLS-Signaling
Functional Description," Internet Draft, draft-ietf-mpls-generalized-
signaling-01.txt, November 2000.
[ASHWOOD2] P. Ashwood-Smith, et al, "Generalized MPLS Signaling-
RSVP-TE Extensions," Internet Draft, draft-ietf-mpls-generalized-rsvp-
te-00.txt, December 2000.
[ASHWOOD3] P. Ashwood-Smith, et al, "Generalized MPLS Signaling-
CR-LDP Extensions," Internet Draft, draft-ietf-mpls-generalized-cr-
ldp-00.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.
Ghani et. al. [Page 37]
[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.
[CHIU] A. Chiu, J. Strand, R. Tkach, "Unique Features and Requirements
for the Optical Layer Control Plane," Internet Draft, draft-chiu-strand-
unique-olcp-01.txt, December 2000.
[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.
[G.709] D. Brungard, "TD Draft ITU-T G.709 for February 2001 SG15
Meeting," T1X1 Forum, T1X1.5/2001-043, March 2001.
[G.841] "Types and Characteristics of SDH Network Protection
Architectures," ITU-T Recommendation G.841, 2000.
Ghani et. al. [Page 38]
[GFP] E. Hernandez-Valencia, "GFP Draft Specification-Revision 2
(Synchronous Optical Network (SONET)-Generic Framing Protocol,"
January 2001.
[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
GMPLS," Internet Draft, draft-kompella-ospf-gmpls-extensions-00.txt,
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.
Ghani et. al. [Page 39]
[MANCHESTER1] J. Manchester, P. Bonenfant, C. Newton, "The Evolution
of Transport Network Survivability," IEEE Communications, August 1999.
[MANCHESTER2] J. Manchester, P. Bonenfant, "Fiber Optic Network
Survivability: SONET/Optical Protection Layer Interworkign,"
Proceedings of the National Fiber Optics Engineering Conference 1996
(NFOEC'96), Denver, CO, 1996.
[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.
[PAPADIMITRIOU3] D. Papadimitriou, "Optical Rings and Hybrid Mesh-
Ring Optical Networks," Internet Draft, draft-papadimitriou-optical-
Rings-00.txt, February 2001.
[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.
[T1.105.01] S. Gorshe, "Synchronous Optical Network (SONET) Automatic
Protection Switching, ANSI T105.01 (T1X1.5/99-065R3), November 1999.
[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.
Ghani et. al. [Page 40]
[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.
9990 Mesa Rim Blvd, 9990 Mesa Rim Blvd,
San Diego, CA 92121, USA San Diego, CA 92121, USA
nghani@sorrentonet.com jfu@sorrentonet.com
Dan Guo Xinyi Liu
Sorrento Networks Inc. Sorrento Networks Inc.
San Diego, CA 92121, USA San Diego, CA 92121, USA
dguo@sorrentonet.com xliu@sorrentonet.com
Zhensheng Zhang Paul Bonenfant
Sorrento Networks Inc. Photuris
9990 Mesa Rim Blvd 20 Corporate Place South
San Diego, CA 92121, USA Piscataway, NJ 08854, USA
zzhang@sorrentonet.com pbonenfant@photuris.com
Leah Zhang Antonio Rodriguez Moral
Photuris Inc. Photuris Inc.
20 Corporate Place South 20 Corporate Place South
Piscataway, NJ 08854, USA Piscataway, NJ 08854, USA
lzhang@photuris.com arodmor@photuris.com
Murali Krishnaswamy Dimitri Papadimitriou
Photuris Inc. Alcatel IPO-NSG
20 Corporate Place South B-2018 Antwerpen, Belgium
Piscataway, NJ 08854, USA Phone: +32 3 240-8491
murali@photuris.com dimitri.papadimitriou@alcatel.be
Sudheer Dharanikota Raj Jain
Nayna Networks Inc. Nayna Networks Inc.
157 Topaz Street 157 Topaz Street
Milpitas, CA 95035, USA Milpitas, CA 95035, USA
sudheer@nayna.com 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
Ghani et. al. [Page 41]
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.
