Network Working Group
Jin Ho Hahm
Document: draft-many-optical-restoration-00.txt
ETRI
Category: Internet Draft
Expires: August 2001
Kwang-il Lee
David Griffith
NIST
Riad Hartani
Caspian Networks
D.Papadimitriou
Fabrice Poppe
Alcatel
Restoration Mechanisms and Signaling in Optical Networks
<draft-many-optical-restoration-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may 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.
Conventions used in this document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
Internet Draft û Expires August 2001 1
Draft-many-optical-restoration-00.txt February 2001
Abstract
With the advent of tunable lasers and optical switches, dynamic
configuration of optical mesh networks has become possible. This
Internet-Draft presents a signaling mechanism for provisioning
schemes and dynamic lightpath restoration. The mechanisms proposed
covers shared restoration (i.e. 1:1, 1:N and M:N) as well as
provisioned and non-provisioned scheme. Provisioned restoration
(equivalent to lightpath protection) implies the provisioning of
backup lightpaths in advance before failures occur.
1. Introduction
In general, Internet backbone networks are overbuilt in comparison
to average traffic volumes, in order to support fluctuations in
traffic levels and to stay ahead of traffic growth rates. Therefore,
any given time there are typically under utilized capacity in
deployed optical network facilities. Overbuilding of the backbone to
support traffic fluctuations is part of the optical network design
to meet the expected performance and the QoS provided.
One of the most important concepts in network management is
maintaining the survivability of networks and in particular the
survivability of optical networks. When there are link failures or
the like, any affected routes should be repaired as soon as
possible. This mechanism is also referred to as fast restoration. In
today's SONET/SDH networks, one can achieve recovery times of 50 ms
or even lower, but this mechanism depends on the 1+1 backup optical
network link resources to achieve this performance. To avoid this
resources waste in optical networks, an adaptive 1:N or M:N shared
restoration mechanism can be applied that still provides enhanced
network survivability while minimizing the waste in network
resources. When using these shared mechanisms, the protection paths
can be used to transport best-effort traffic throughout the optical
network.
This Internet Draft proposes a mechanism for route computation and
restoration processes that meet these goals in optical meshed
networks, as well as the associated signaling extensions and
notification message definitions.
Note: in order to avoid the use of RSVP-TE and CR-LDP message in the
first four sections of this memo, a generic terminology described in
Appendix 1.
2. Basic concepts for bandwidth provisioning and restoration
This section describes the basic concept of bandwidth provisioning
and restoration mechanisms in optical networks.
2.1 OXC system architecture
Internet Draft û Expires August 2001 2
Draft-many-optical-restoration-00.txt February 2001
The Optical Cross-Connect (OXC) system architecture for lambda
switching has been introduced in the [IPO-FRAME] and [IPO-MPLS]. The
OXC interfaces considered hereafter includes, as described in
[GMPLS-SIG], Lambda Switch Capable (LSC) interfaces that switches
the lightpath segment based on the incoming wavelength and Fiber-
Switch Capable (FSC) interfaces that switches the lightpath based on
the spatial position of the incoming data stream in the real world
physical spaces. Our proposed bandwidth provisioning and restoration
mechanisms are based on this architecture.
The internal processing in OXC system for lambda switching (i.e.
wavelength switching) is briefly outlined hereafter. This
description is presented only as an aid to understanding the content
of the next sections.
An OXC has several incoming and outgoing LSC interfaces or ports,
connected to adjacent OXCs, and several incoming and outgoing LSC
interfaces or ports attached to an edge device that can be a router
(or any other termination capable device supporting LSC interface
connectivity see [IPO-MPLS]). An OXC includes mainly two functional
parts: an OXC Switch Controller (OSCtrl) and OXC optical matrix.
The OSCtrl communicates through Optical Signalling Channels (OSC)
i.e. out-of-band signaling transport mechanism or through dedicated
and physically diverse control network i.e. out-of-network signaling
transport mechanism as indicated in Figure 1. OSCtrls and OSCs
together define the signalling plane of the optical network.
+----------+ OSC +----------+ OSC +----------+
+++|+ OSCtrl +|+++++++|+ OSCtrl +|+++++++|+ OSCtrl +|+++
+ |==========| |=+========| |==========| +
+ | |-------| + |-------| | +
+ | OXC |-------| + OXC |-------| OXC | +
+ | |-------| + |-------| | +
+ +----------+ +-+--------+ +----------+ +
+ | | | + | | | | | + OSC
+ | | | + | | | | | +
+ | | | + | | | | | +
+ +----------+ OSC +-+--------+ OSC +----------+ +
+++|+ OSCtrl +|+++++++|+ OSCtrl +|+++++++|+ OSCtrl +|+++
|==========| |==========| |==========|
| |-------| |-------| |
| OXC |-------| OXC |-------| OXC |
| |-------| |-------| |
+----------+ +----------+ +----------+
(Fig.1) OSC Channel, OSC Controller and OXC
The OSCtrl converts the received messages (mentioned in section 5)
to the proper control command, and sends this command to the OXC
optical matrix. The commands to control the OXC optical matrix are
Internet Draft û Expires August 2001 3
Draft-many-optical-restoration-00.txt February 2001
as follows: connect (and disconnect) between an incoming LSC
interface and an outgoing LSC interface. The OSCtrl is also capable
to process status requests, lightpath modification requests as well
as notification messages. The same commands apply when the OXC is
connected to an LSC capable edge device. However, within the optical
transport plane, lightpaths are strictly defined between the ingress
and the egress OXC LSC interfaces.
Based on these commands, a chain of connections through OXCs can
form an end-to-end lightpath. The OXC initiating the lightpath
creation process is called the ingress OXC, and the OXC ending a
lightpath is called the egress OXC. The OXCs inside the lightpath
are called the intermediate OXCs.
An OXC optical matrix receives commands from the OSCtrl, and replies
whether the command was successful or not. The OSCtrl then converts
the result into a message (described in section 5) that it sends via
the OSC channel throughout the optical network.
+----------+ +-----------------------+
|IP Control| | |
| | | Router |
| Network | | |
+----------+ +--+--+--+-----+--+--+--+
A A A A | | |
| | | | | | |
| | | | | | |
+----|----------|--|--|-----|--|--|---------+
| V | | | | | | |
| +------+ | | | | | | |
| |OSCtrl|<--+ | | | | | | OXC |
| +------+ | | | | | | | |
| +--V--|--|--|-----|--|--|-----+ |
| | | | | V V V | |
egress LSC ports O O O O O O ingress LSC ports
| | | | | | |
-->>-----------------O-----+ | +--O--------------->>--
-->>-----------------O-------------\ +-----O--------------->>--
-->>-----------------O \--------O--------------->>--
-->>-----------------O-----------------------O--------------->>--
incoming lambda | port OXC Matrix port | outgoing lambda
| +-----------------------------+ |
| |
+-------------------------------------------+
(Fig.2) OXC system architecture
To cover any kind of optical network, we consider as specified in
[IPO-FRAME] the following distinction between Optical Cross-Connect
(OXC) in Transparent optical networks and Photonic Cross-Connect
(PXC) in All-optical networks. Basically, OXC devices included
within Transparent optical networks performs
optical/electrical/optical (O/E/O) conversion at each of their
Internet Draft û Expires August 2001 4
Draft-many-optical-restoration-00.txt February 2001
interfaces. Conversely, PXC devices included within All-optical
networks do not perform O/E/O conversion at all so they are defined
as pure O-O devices (including for most of them tunable lasers). As
described in [GMPLS-SIG], we consider here that all the interfaces
of a PXC are Lambda-Switch Capable (LSC) as well as all the
interfaces of an OXC are Lambda Switch Capable.
2.2 Control channel between OXC switching controllers
The OSCtrl communicates through Optical Signalling (i.e. control)
Channels (OSC) i.e. in-fiber/out-of-band signaling transport
mechanism or dedicated physically diverse control network or through
out-of-network signaling transport mechanism. OSC signalling
transport mechanism is described in [IPO-ONNI].
We assume here that control channels between OSCtrl's must be
continuously available in order to enable the exchange of signaling
information. The details of the signalling fault tolerance
mechanisms required are detailed in sub-section 4.3.2 (but limited
here to the scope of notification mechanisms).
2.3 Gathering of link state information for lightpath computation
Lightpath route computation (and selection) can be computed based
on dynamic flooding of information related to optical network link
resources, by using link state IGP protocol advertisements. Many
mechanisms for exchanging the link state information have been
introduced by extending existing IGP routing protocol such as OSPF
[GMPLS-OSPF] or IS-IS [GMPLS-ISIS] for traffic-engineering purposes
in optical network environment. This memo assumes that the link
state information exchange mechanisms and eventually the bundling
(or link bundling) mechanisms enabling the grouping of several links
between adjacent OXCs is as described in [GMPLS-BUNDLE]. So, when a
link state routing protocol is used, these links can be bundled
together and be advertised in a single LSA.
The minimum link state information required to select lightpaths can
be described as follows:
- the link identifier, status and the corresponding signal encoding
- the link bandwidth (minimum/maximum reservable bandwidth and
available bandwidth)
- optionally the link protection type (unprotected 0:1, dedicated
1:1, shared protection M:N and dedicated 1+1)
Any ingress OXC has to know the SRLG (Shared Risk Link Group) list
of every link to compute lightpath routes that do not share the same
risk of potential damages. In the steady state, these SRLG values do
not change, so this information is exchanged only once (at the
initial optical network setup time). As described in [IPO-SRLG], the
routing diversity constraint implies specific considerations with
respect to the optical network topology.
Internet Draft û Expires August 2001 5
Draft-many-optical-restoration-00.txt February 2001
In order to know whether it is possible to switch an incoming
wavelength to a different outgoing wavelength, the ingress OXC could
also need to know the availability of lambda converters (i.e.
tunable lasers) in all OXCs.
Currently, we assume here that all OXCs have enough lambda
converters for that purpose. If this assumption is not verified,
then the switching process depends on the availability of the
wavelength requested for a given lightpath. In this case, the
wavelength blocking probability must be taken into account during
the setup and the restoration process. This may lead to specific
considerations like crank-back mechanism during lightpath setup
process.
2.4 Lightpath Creation Process
It is assumed that ingress OXC (or boundary intermediate OXC see
[IPO-ONNI] and [IPO_FRAME]) functions will perform lightpath route
computation and selection. However, in this Draft, we only consider
the signaling procedures after the route (or the partial) of the
lightpath (of the lightpath segment, respectively) is computed by a
distributed CSPF algorithm. Since the signaling mechanisms are
independent on the route computation and selection, the restoration
procedures described here are quite general and apply to distributed
optical network environments.
In general, the establishment of an LSP by using GMPLS signaling
[GMPLS-SIG] can be divided into two cases:
- signalling-driven approach: pre-establishment before data traffic
arrives at the ingress router in response to an explicit signalling
request
- data-driven approach: and post-establishment after data traffic
arrives at the ingress router
In the latter case, LSPs must be created quickly enough to handle
the data traffic waiting at the ingress Label Switch Router (LSR)
for transmission. However, the signalling-driven approach is the one
considered here and we only refer to the data-driven approach for
completeness.
Nevertheless, even with data-driven approach, one might expect that
the lightpath creation process will not in general be so intensive,
as lightpath will only be created in response to long-term changes
in traffic volume (note: long-term comparing to the time scale of
the optical restoration one). Since several LSPs are generally
multiplexed within the same lightpath, the granularity of the
lightpath is coarser than the one of the LSPs it carriers.
Moreover, since we assume that the permanent state [IPO-FRAME] is
supported for the lightpath, the Bandwidth-on-Demand (BoD) model
support will require high availability of the signaling plane (i.e.
of the control channels). Consequently, some specific features such
Internet Draft û Expires August 2001 6
Draft-many-optical-restoration-00.txt February 2001
as signaling fault-tolerance and signaling performance (i.e.
signaling delay) are required when considering the lightpath create
procedures.
3. Optical Restoration Mechanisms
The ingress OXC (or intermediate OXC) is in charge of the creation,
modification, deletion, and subsequently the restoration (or partial
restoration) of lightpaths. This means that the ingress OXC will
also assign the restoration-related parameters during the lightpath
creation phase.
First we compare the link protection to the link restoration
mechanisms and analyze in detail the lightpath restoration
procedures and the corresponding signalling enhancements in the
remaining part of this document.
3.1 Link Protection and Restoration vs. Lightpath Restoration
If we compare the optical restoration to the link (1+1) protection
mechanism between OXC, then the following protection mechanism can
be considered. For each of the link included in the primary
lightpath route that needs to be protected, a dedicated link-
disjoint backup route is setup in advance during the lightpath
creation process. Switching from the primary to the backup route is
executed when a link failure is detected.
The link restoration mechanism is based on distributed recovery
process. When a link failure is detected by the node(s) adjacent to
the failure, the adjacent upstream node dynamically computes a route
(for instance, from the adjacent upstream node to the adjacent
downstream node) for each damaged lightpath traversing that failed
link. Upon backup lightpaths establishment the upstream adjacent
node and downstream adjacent nodes to the failure switch the failed
primary lightpath to the corresponding backup lightpath.
The lightpath restoration mechanism is based on the following edge-
to-edge principle. When a link failure is detected by the node(s)
adjacent to the link failure (or the node failure), they notify the
ingress and egress nodes of each of the lightpaths traversing that
failed link (or failed node). Then depending on the restoration
scheme, the ingress and egress nodes compute the route of an end-to-
end backup lightpath or use the provisioned end-to-end backup
lightpath. When the backup lightpath is established the ingress and
egress nodes switch from the failed primary lightpath to the backup
lightpath.
However, as described in the section 4 (see below), with non-
revertive strategy, the provisioned restoration (which is equivalent
to lightpath protection) operation is a particular case of the
lightpath destructive modification procedure. On the other hand, the
non-provisioned restoration is basically a triggered lightpath
creation procedure.
Internet Draft û Expires August 2001 7
Draft-many-optical-restoration-00.txt February 2001
3.2 Lightpath Failure Detection
If an optical link is damaged physically, all the lightpaths passing
through this link will be affected. Generally, in case of an all-
optical network (i.e. transparent optical network) where all devices
do not use Optical/Electrical/Optical (O/E/O) conversion, damage to
a lightpath or drop of light signal level depends on the Loss of
Light (LoL) detection capacity of the PXC. For that purpose the AND
function of the LoLs on all terminated wavelengths channels can be
used to detect the loss of the physical section (more precisely, the
wavelengths changing device which can be based on an adaptation of
the laser/detector). In practice, a LoL detector will be essential
to provide at the end of the physical optical section in order to
provide fault detection and localization.
If the PXC supports this feature, a bi-directional LoL detection
will be propagated from the source of the failure to the ingress and
egress PXC by a Notification Message. Otherwise, if the PXC doesn't
support LoL detection, this lost of signal will be triggered by the
ingress OXC or the egress OXC depending on the transmission
direction since the devices support O/E/O conversion at their LSC
interfaces. The unidirectional LoL detection mechanism is detailed
in section 4.3.
Link failure detection used in all-optical networks can be compared
with the current mechanisms used in SDH/Sonet networks:
- LoF (Lost of Frame) is detected by monitoring A1 and A2 RS/Section
overhead bytes. LoF is declared when valid values for these bytes
are not received for a 3-ms time period. LoF is cleared when two
consecutive valid A1 and A2 bytes are received.
- LoS (Lost of Signal) occurs when an all zeroes pattern is received
for 10 ´s or longer (indicating an upstream transmit failure).
- AIS (Alarm Indication Signal) occurs as a result of a failure
condition such as LoF or LoS and is used to notify downstream nodes
that a failure has occurred. Line AIS is detected by 1's in bits 6 -
8 of the K2 byte in five consecutive frames. AIS performs two
functions: inform the intermediate nodes that a failure has been
detected and notify that the connection end-point that the service
is no longer available. Note that some proprietary implementations
also provides to localization (i.e. the originating point) of the
failure.
- BER (Bit error rate): BER monitoring is handled by counting parity
violations detected via the B2 MS/Line overhead byte or B1
RS/Section overhead byte and converting the number of violations
over a time period into the corresponding bit error rate. The
configured BER threshold is used to determine if the observed BER
results in a signal failure (SF) or signal degradation (SD)
condition.
Note here that LoF, LoS and AIS refer to Inherent path state
monitoring and BER refers to Inherent and Non-intrusive path state
monitoring.
Internet Draft û Expires August 2001 8
Draft-many-optical-restoration-00.txt February 2001
In all-optical networks, LoS (or LoL) is directly applicable to
optical link failure detection. BER is more complicated to achieve
in all-optical networks since they include only PXCÆs. Since the BER
real-time measurement in all-optical networks is currently under
definition, these considerations are left for further study.
Note also that the failure detection mechanisms considered in this
memo are bit rate independent and transparent (to the client
signal).
3.3 Strict vs. Loose explicit routing
In CR-LDP [MPLS-CRLDP], both strict explicit routing and loose
explicit routing mechanisms may be used. However, in this scheme for
lambda switching within a given IGP area, we only consider strict
explicit routing to designate the route of the lightpath. By using
strict explicit routing, optical network resources can be managed
more precisely, and the rate of success for lightpath creation can
be enhanced. Consequently, we only consider strict explicit routing
for intra-area routing.
For inter-area routing, the knowledge of the topology of the
neighboring areas depends on the information advertised through the
IGP protocol (we consider here inter-area summary advertisements as
described in [MPLS-TE]). So, we assume that the explicit route
computation and selection is performed at the ingress OXC (default
behavior) and explicitly at each border OXC. This means that at each
border OXC (i.e. at the ingress of each sub-network or area), the
explicit route for the lightpath segment within this area needs to
be computed (or selected).
3.4 Decision of backup lightpath
The difference between a primary lightpath and backup lightpath is
that at the edge of the optical network, the backup lightpath has no
connections within the optical matrix between the input and the
output LSC interface of the ingress OXC and egress OXC, whereas the
primary lightpath has connection in both OXCs. The connections
between these LSC interfaces are performed during the restoration
process.
However, the backup lightpath resources used within the optical
network could be used to transport best-effort traffic. In this
case, the edge (ingress and egress) port connections for the backup
lightpath are assigned to interfaces excluded from those allocated
to the corresponding restoration group. The corresponding bandwidth
resource is then considered as available but advertised with a lower
priority. This is the more efficient way to use the optical network
resources.
3.4.1 Restoration schemes
Internet Draft û Expires August 2001 9
Draft-many-optical-restoration-00.txt February 2001
In our approach of the lightpath restoration, we consider two kinds
of lightpath restoration schemes: provisioned or non-provisioned.
Provisioned restoration of lightpaths is also referred to as
lightpath protection.
- Either provisioned: meaning that backup lightpaths are established
in advance of a link failure. The method of pre-establishment of
backup lightpaths in advance of link failure minimizes the
restoration time, especially when the restoration process must be
carried out simultaneously for a large number of damaged lightpaths
sharing the same damaged link. In order to maximize the use of the
optical network resources, the wavelengths allocated to the backup
lightpaths could be used for carrying preemptable best-effort, low-
priority traffic and this only during failure-free optical network
operating conditions.
- Or non-provisioned with a maximum restoration time value: meaning
that backup lightpaths are dynamically created when a link failure
is detected or advertised. The maximum restoration time is related
to the signaling delay needed to create the backup lightpath through
the optical network. This implies the need to define an ultra fast
restoration mechanism (we assume here a low latency signalling
network).
This non-provisioned approach does not preclude the background pre-
computing of the backup route for these paths (also referred to as
non-static routing). However, in this case, some refreshment
mechanism of the pre-calculated backup routes is needed in order to
ensure that these routes are still æusableÆ regarding the
topological and resource information advertised by the IGP protocol.
The (non-)static vs dynamic route computation is described in
section 3.4.
3.4.2 Dedicated vs. Shared Restoration
The following dedicated and shared restoration mechanisms for meshed
optical networks are considered:
- Dedicated 1:1 where one primary lightpath shares one backup
lightpath
- Group Shared 1:N where N primary lightpaths share one backup
lightpath (still dedicated to the designated to a unique restoration
group-N)
- Group Shared M:N (with N > M and M >= 2) where N primary
lightpaths share M backup lightpaths (still dedicated to the
designated to a unique restoration group-N)
- Multi-group Group Shared 1:N where N primary lightpaths share one
backup lightpath (here the protection lightpath is shared between P
restoration group-N)
- Multi-group Shared M:N (with N > M and M >= 2) where N primary
lightpaths share M backup lightpaths (here the protection lightpaths
are shared between P restoration group-N)
Internet Draft û Expires August 2001 10
Draft-many-optical-restoration-00.txt February 2001
Since 1:1 and 1:N are particular case of the M:N restoration scheme
we only consider this last case for the seek of generality of this
draft. The size of N will depend on the topological characteristics
of the network and the size of M depends on the restoration level
supported by the optical network. We say that the N primary
lightpath and M backup lightpath share the same restoration group. A
given restoration group is identified by a restoration identifier
defined by the ingress OXC.
Note that the weakness of the 1:N restoration mechanism is that,
after an initial failure and before re-provisioning, it cannot
support restoration for additional failures to other lightpaths in
the same restoration group. This defect is remedied through the
general M:N restoration mechanism (M >= 2) which the simultaneous
restoration of maximum M primary lightpaths.
To decide on the grouping of primary lightpaths and backup
lightpaths, the SRLG values of links are considered. Because a
lightpath travels through several links, it will have corresponding
to it the set of SRLG values of its member links.
The lightpaths within a 1:N restoration group cannot share the same
SRLG value (and subsequently set of SRLG value, since SRLG sets must
be disjoint), as then a single failure could affect several
lightpaths simultaneously. Therefore, when a new lightpath is
created, if it cannot be placed within any existing restoration
group, a new restoration group is created, along with a backup
lightpath for the newly created primary lightpath.
Moreover, since SRLG sets must be completely disjoint more than M
lightpaths within a M:N restoration group cannot share the same set
of SRLG values since a single failure could affect more than M
primary lightpath simultaneously.
3.4 Static vs. Dynamic Routing
The Optical Restoration Diameter (ORD) defines the Optical
Restoration Scope (ORS) or domain. Optical Restoration Diameter is
defined as the number of nodes (i.e. number OXCÆs and PXCÆs) in the
routing path (i.e. node sequence) for which a given restoration
mechanism and policy is applied providing the static or dynamic
routing.
Regarding the lightpath restoration policy (provisioned or non-
provisioned) and depending on the restoration diameter, two route
computation schemes can be considered: static and dynamic routing.
- Static routing: for every end-to-end lightpath between border OXC,
the routing path are predetermined through the application of
Constraint-based SPF (CSPF) algorithm and does not change depending
on the connection in progress in the network. Different routing
constraints can be used to compute the routing path for every
lightpath. Some of these constraints are:
Internet Draft û Expires August 2001 11
Draft-many-optical-restoration-00.txt February 2001
. to minimize the transport-plane delay
. to minimize the signalling delay
. to minimize the link and wavelength usage
. to maximize the bandwidth usage
. to optimize other network performance characteristics
. to optimize the routing diversity between lightpath belonging to
the same restoration group
- Dynamic routing: for any given end-to-end lightpath, the routing
path to be used is determined when a connection between boundary
OXCs is requested. Using a dynamic routing scheme, a lightpath is
not predetermined and depends on the routing path for other
connection in progress in the network. A dynamic scheme needs a
setup time (i.e. a maximum restoration time) to determine the
routing path such that the lightpath satisfies the routing
constraints (delay, bandwidth and performance). From the link and
wavelength usage at any instant, the lightpath is constructed
dynamically. Consequently, the OXCs are not programmed initially and
set to establish the lightpaths when such requests occurs.
When using static routing scheme, if faults occur to the nodes,
links or channels, one or more predetermined lightpaths will become
unusable. Consequently, since fault occurrence is inherently a
dynamic network characteristic, achieving fault-tolerance in a
network using static routing is more difficult than in a network
using dynamic routing. The failure avoidance mechanism needed with
static routing as well as specific dynamic routing mechanisms are
detailed in the remaining document.
3.5 Partial Restoration
When the ORD does not include any node traversed by a lightpath
(from the ingress to the egress OXC) but only some partial segment
of the routing path, then the restoration mechanism applied for this
lightpath is only partial.
Consequently, a restoration path has to be provided for each link or
sequence of links covered by the lightpath and not only from the
ingress to the egress OXC, source and destination of this lightpath.
Depending on the routing plan (i.e. static or dynamic), partial
restoration can be applied for instance per IGP area. In this case,
the lightpath restoration procedure only applies between ABR
belonging to the area experiencing the lightpath failure.
If the lightpath traverse multiple areas, partial restoration can
independently handle simultaneous recovery of single failure per
area. At the ABR, in case of simultaneous recovery, the
synchronization between the ingress and the egress port switching
connection is guaranteed by the bi-directionality of the lightpath
restoration process.
Partial restoration offers the advantage of lightpath failure
isolation per area (or any other logical structure) as well as a
Internet Draft û Expires August 2001 12
Draft-many-optical-restoration-00.txt February 2001
greater flexibility in the backup routing path selection. However,
the main advantage of partial restoration is that this technique
enables the partitioning of the restoration domains; this in turn
limits the probability of simultaneous failures within the mean
restoration time.
Partial restoration can also be applied for link failure restoration
and more generally to node failure. In this case, one could expect
that each node is capable to compute the lightpath segment of detour
[IPO-FT] between the upstream and the downstream node adjacent the
link failure detection. This restoration mechanism is sometimes
referred to as ôlocal re-routingö.
3.6 Release of damaged lightpath and Restoration Strategies
Depending on the lightpath restoration strategy, a damaged lightpath
could be released (non-revertive restoration strategy) or repaired
(revertive restoration strategy):
- If we consider a non-revertive strategy, then the damaged
lightpath must be released in order to make the resources of its
undamaged segments available for future demands. Since a link
failure generates a Notification Message in both ingress and egress
OXC direction, the release of the corresponding lightpath resources
is by default the ingress OXC's responsibility. However, as
explained in section 4.3, in order to decrease the restoration time
from the primary to the backup path, the switching is performed
'simultaneously' at both ends. The released resources can be reused
after announcement of the corresponding released status through IGP
link-state advertisements.
- If we consider a revertive strategy, then the resources used by
the damaged lightpaths must not be released in order to be re-used
when the failed æresourceÆ will be available again. By receiving the
Notification Message, any OXC included within the route of the
failed lightpath reserves the corresponding resources. Note that a
specific time-out could be locally defined to release the resources
if the failed resource status does not change within a certain
period of time.
Note that by referring to MPLS specification [MPLS-ARCH] (and to the
GMPLS signalling specification [GMPLS-SIG]), a non-revertive
restoration strategy refers to a liberal (generalized) label
retention mode and a revertive restoration to a conservative
(generalized) label retention mode.
3.7 Failure of lightpath creation
The creation of lightpaths can fail for the following three reasons.
First, failure can occur due to an inconsistency between the
gathered link state information at the ingress OXC and the actual
link status of optical network. Because link state information can
Internet Draft û Expires August 2001 13
Draft-many-optical-restoration-00.txt February 2001
be transmitted with some delay from every OXC, delayed updates can
make for this inconsistency.
Secondly, failure can occur even if link state information is
consistent with the actual link status. If two ingress OXCs decide
simultaneously to use the same network resources, one of the
lightpath setup attempts will fail because its resources have
already been claimed by the other lightpath. However, contention
resolution procedures are described in [GMPLS-SIG] and are not
further considered within this document.
Finally, even if lightpath establishment completes, the lightpath
may fail to carry data because the quality of transmission does not
reach a minimal threshold level. The deterioration of transmission
quality can occur due to several reasons as described in [IPO-CTRL]
and [IPO-LMP].
The first two cases of failure during lightpath creation are
reported to the ingress OXC by a Notification Message from the
intermediate OXCs where the error is detected. Failure can be
detected by measuring the Optical Signal to Noise Ration (OSNR) of
the received optical signal or the Bit Error Rate (BER) of Optical-
to-Electric transformed data. In the all-optical domain, a new BER
measurement has been proposed in [IPO-OPM], this technique performs
sequential scanning of the input power of the optical signal after
splitting (more accurately by using taps). If the quality of the
optical signal does not reach the threshold level, then the
lightpath is released, and a new lightpath is created.
4. Restoration Procedures
In this section, we detail the optical restoration procedures and
mechanisms. More precisely, we analyze the setup procedures for
primary and backup lightpaths, the reporting procedure for handling
damaged lightpaths, the restoration procedure for replacing a
damaged lightpath with one of the backup lightpaths included within
the backup group, and the release procedure for unused lightpaths.
4.2 Decision of lightpath route based on link state information
If a primary lightpath cannot be created within an already existing
restoration group, then a new restoration group needs to be defined.
So, the primary lightpath and the corresponding backup lightpath are
created within the new restoration group defined by a new
restoration identifier.
If the primary lightpath can be created within an existing
restoration group, then if the number of backup lightpath already
created for this restoration group is less than M then a new backup
lightpath is created. Otherwise, if the number of backup lightpath
is greater than M, no new backup lightpath is created. However, if
the number of established primary lightpath does not exceed the
Internet Draft û Expires August 2001 14
Draft-many-optical-restoration-00.txt February 2001
number of existing backup lightpath, no new backup lightpath is
created.
4.2.1 Lightpath setup procedure for primary lightpath
Once the route of a lightpath is decided, the ingress OXC sends the
Lightpath Create Request Message to the next intermediate OXC
through the control channel. The sequence of intermediate OXCs to be
followed by the lightpath is included within the explicit route
field of the Lightpath Create Request Message; and at each OXC the
wavelength to be allocated for the lightpath is deduced from the
channel identifier corresponding to this wavelength.
An intermediate OXC receives the Lightpath Create Request Message
from its adjacent upstream OXC. The OSCtrl of the intermediate OXC
then attempts to configure the OXC switch fabric according to the
Lightpath Create Request Message, and receives the result from the
OXC switch fabric. If a successful result is returned, the OSCtrl of
the intermediate OXC sends the Lightpath Create Request Message to
its downstream intermediate OXC for that route. During this
procedure, intermediate OXCs consume the optical network resources
and therefore update the link state database by indicating the
corresponding resources as reserved meaning that these resources
won't be allocated to another restoration group. This link state
information will then be flooded to other OXC by using IGP link-
state advertisement.
If a Lightpath Create Request Message successfully reaches the
egress OXC, the egress OXC then returns the Lightpath Create
Response Message noting the successful lightpath creation through
the reverse direction of the Lightpath Create Request Message
direction to the ingress OXC. Upon receiving this response message,
each of the OXC updates the link state database by indicating the
corresponding resources as used. This link state information will
then be flooded to other OXC through IGP link-state advertisements.
When the Lightpath Create Response Message reaches the ingress OXC,
it advertises this increment in available bandwidth capacity by
flooding link-state IGP routing protocol advertisement at the client
IP network control-plane level. Routers receiving this link status
information apply the increased bandwidth to the generation of LSPs
meeting traffic-engineering requirements [MPLS-LSPH].
If an intermediate OXC receiving the Lightpath Create Request
Message cannot successfully configure the OXC switch fabric, the
intermediate OXC replies with a Notification Message indicating the
failure to the ingress OXC. At each of the OXC where the Lightpath
Create Request Message has been successfully proceeded and the
allocated resources marked as reserved, the corresponding resources
previously marked as reserved are released and marked as unused in
the link state database. An ingress OXC receiving this reply then
sends a Lightpath Create Response Message (to the requesting client)
Internet Draft û Expires August 2001 15
Draft-many-optical-restoration-00.txt February 2001
to release any tentatively claimed resources. The detailed procedure
is explained in section 4.3.
4.2.2 Lightpath setup procedure for backup lightpath
Backup lightpaths are created through the same procedure as primary
lightpaths. Depending on the restoration policy defined regarding
the backup lightpath provisioning, backup lightpath creation is
triggered either during the primary lightpath setup (provisioned) or
during the lightpath recovery (non-provisioned).
The backup lightpaths established by this procedure belong to the
same restoration group than the primary group of lightpaths to which
they refers. Each of these lightpaths is also identified by the
restoration Path_Status field that indicates the status of the
lightpath within the range [0, M] and the Restoration Path_Type bit
(= 1) defining it as a backup lightpath.
4.3 Procedure for reporting a damaged lightpath
Damaged lightpaths can be triggered by detecting a LoL or a LoS
Alarm on the upstream and/or on the downstream OXC depending on
failure experienced by the fiber link, the fiber sub-segment and the
fiber segment connecting the optical device interfaces [IPO-SRLG].
4.3.1 Link Failure Detection
However, the resulting link failure detection will be one of the
following:
- Uni-directional link detection: the failure affects only one fiber
of the fiber pair; meaning that the LoS is detected by the
downstream OXC or by the upstream OXC.
- Bi-directional link detection: the failure affects both fibers of
a fiber pair; meaning that the LoS is detected by the downstream and
by the upstream OXC.
In a end-to-end (or partial) restoration, by receiving the alarm
signal, the OXC issues a Notification Message translating this
physical network failure. The Notification Message comprises the
Lightpath ID, the Restoration Group ID and the Restoration
Path_Status of the damaged primary or backup lightpath. The
Notification Message may optionally include the detailed the reason
why the impairment occurred.
Ingress Egress
+-------+ OSC +-------+ OSC +-------+ OSC +-------+
| |++++ à ++++| |+++++++++| |++++ à ++++| |
| | | |Tx Rx| | | |
| OXC A |---- à ----| OXC B |---------| OXC C |---- à ----| OXC D |
| |---- à ----| |---------| |---- à ----| |
Internet Draft û Expires August 2001 16
Draft-many-optical-restoration-00.txt February 2001
| | | |Rx Tx| | | |
+-------+ +-------+ +-------+ +-------+
OSC
+++++++++++++++
Ingress + + Egress
+-------+ +-------+ +-------+ +-------+
| | OSC | | Failure | | OSC | |
| |++++ à ++++| |Tx Rx| |++++ à ++++| |
| OXC A |---- à ----| OXC B |xxxxxxxxx| OXC C |---- à ----| OXC D |
| |---- ----| |---------| |---- à ----| |
| | | |Rx Tx| | | |
+-------+ +-------+ +-------+ +-------+
T0 >>>>>>> LoL
T1 X <---------------+ +------- à --------->
Up Notification Down Notification
T2 <------- à -------+
Up Notification
Fig 3. Unidirectional Link Failure Detection
OSC
+++++++++++++++
Ingress + + Egress
+-------+ +-------+ +-------+ +-------+
| | OSC | | Failure | | OSC | |
| |++++ à ++++| |Tx Rx| |++++ à ++++| |
| OXC A |---- à ----| OXC B |xxxxxxxxx| OXC C |---- à ----| OXC D |
| |---- ----| |xxxxxxxxx| |---- à ----| |
| | | |Rx Tx| | | |
+-------+ +-------+ +-------+ +-------+
T0 LoL <<<<<< >>>>>> LoL
T1 <------- à ------+ X <-------------> X +------ à -------->
Up Notification Notification Down Notification
Fig 4. Bi-directional Link Failure Detection
To detect a unidirectional link failure the following mechanism is
proposed: by detecting a LoS Alarm, the OXC generates a Notification
in both the downstream and upstream direction of the damaged
lightpath. If the upstream (or the downstream) OXC has also detected
the LoS Alarm (i.e. bi-directional link failure detection), then it
sends back a Notification Message to the downstream (or upstream)
OXC. Otherwise (i.e. unidirectional link failure detection) the
upstream (or the downstream) OXC forward the Notification toward the
ingress (or the egress) OXC.
Internet Draft û Expires August 2001 17
Draft-many-optical-restoration-00.txt February 2001
Depending on restoration mechanism supported within a given ORD:
- Either the OXCs detecting the failure restore the corresponding
damaged lightpaths; in that case the restoration procedure is
referred to as link restoration (as described in section 3.1). If
the link restoration mechanism does not recover the lightpath after
the expiration restoration time-out then the notification message is
forwarded until reaching the ingress (or the egress) OXC.
- Or if these OXCs does not support (or are not allowed by their
restoration policy restriction) to perform link restoration; in that
case the notification message is directly sent to the ingress (or
egress) OXC who will apply the restoration procedure(s) described in
section 4.4.
4.3.2 Notification Mechanism
The need for an upstream and downstream Notification depends on:
- the restoration policy (end-to-end or partial including link
restoration) applied within a given ORD
- the local re-routing of all the damaged lightpaths is unsuccessful
- the node B and/or C which might not be capable to detect a LoL
Specific timers and thresholds are introduced in order to ensure the
proper operation of the restoration mechanism. The following timers
and thresholds are defined for that purpose:
- Notification Timer (NTR): when an OXC detects a failure, this
timer defines the waiting period before sending a notification
message. For instance, in the previous example (see Figure 3), if
NRT = 0 then T1 û T0 = 0.
- Forwarding Timer (FTR): when an OXC receive a notification
message, this timer defines the waiting period before forwarding the
notification message to the upstream or the downstream OXC. A
notification timer of 0 means that the notification messages must be
directly sent to the upstream or downstream next OXC. For instance,
in the previous example (see Figure 3), if FTR = 0 then T1 û T2 = 0.
- Restoration Timer (RTR): when an OXC detects a failure, this timer
(also referred to as restoration time-out) defines the period during
which the OXC can execute the local restoration procedure (as
specified in the next section). A restoration timer value equal to 0
means that the OXC does not have the capability to perform the local
path re-routing so that the corresponding forwarding timer equals to
0. For instance, in the previous example (see Figure 3), if RTR = 0
then T1 - T2 = 0 since it implies that FTR must be equal to 0.
4.3.3 Reliable Notification Mechanism
In order to provide a reliable notification mechanism, a
Notification Counter (RCR) can be additionally defined. This counter
provides the required retransmission capabilities in case of
Notification Message loss and the continuous notification of the
failure until this failure has been repaired (see section 4.4.1).
Internet Draft û Expires August 2001 18
Draft-many-optical-restoration-00.txt February 2001
The continuous notification mechanism is regulated by a exponential
back-off algorithm: T[n] = 2 x k x T[n-1] =< RTR with T[0] = 1 and k
=< 1.
However, reliability of the notification mechanism can be also
achieved by extending the (CR-)LDP fault tolerant (FT) enhancements
[MPLS-LDPFT]. This mechanism allows nodes to negotiate how long they
will retain FT states such as learned (generalized) label bindings
after the lightpath failure occurs as well as the corresponding
damaged links but also after the potential failure of the (CR-)LDP
session occurs (for signalling plane fault-tolerance purpose).
Consequently, when sending the notification message, the OXC (i.e.
the one who has detected the failure) is waiting for the
acknowledgement of this notification message by the receiver. The
receiver is defined as the OXC that takes the failure recovery
procedure into consideration and applies the lightpath restoration
procedure as described in section 4.4.
The definition of a reliable notification mechanism allows the OXC
to negotiate how long they will remember pre-failure switching state
after experiencing a link failure.
4.4 Lightpath Restoration procedure
Restoration procedure can be applied to a damaged primary lightpath
or backup lightpath.
4.4.1 Restoration procedure for single damaged primary lightpath
In case of failure of a primary lightpath, the (ingress) OXC is made
aware of which lightpath is damaged by the Lightpath ID, the
Restoration Group ID and the Restoration Path_Status field included
within the Notification Message. The localization of the failure is
inferred from the link ID (or the bundle ID) included in the
notification message.
- If the provisioned restoration policy has been previously
configured for this restoration group, the ingress OXC then replaces
the damaged primary lightpath with of the backup lightpath shared by
the same restoration group. With M:N restoration, the backup
lightpath Path_Status corresponds to the value of N (if this value
of M exist).
- If the provisioned restoration policy has not been previously
configured for this restoration group, then the ingress OXC
initiates a lightpath create procedure for the backup lightpath, as
described in section 4.2.2. Note that since the route computation
for backup lightpath has been determined prior to the primary
lightpath failure, the maximum restoration time depends here only on
the signaling delay.
When provisioned restoration policy is defined, if the physical
resource failure affect also the one computed for the backup
Internet Draft û Expires August 2001 19
Draft-many-optical-restoration-00.txt February 2001
lightpath, the restoration policy is automatically switched to the
one executed for the non-provisioned case.
When receiving the failure Notification Message, the ingress OSCtrl
reconfigure the connection within the OXC switch by switching the
connection between the incoming and the outgoing lambda port of the
damaged lightpath with that of the backup lightpath. This process is
executed internally without exchanging messages but not activated.
Then, the ingress OSCtrl reflects the result in the Notification
Message it sends to the egress OSCtrl.
Since the failure Notification Message is sent simultaneously from
the OXC detecting the failure to the ingress and the egress OXC,
this Notification Message is also received by the egress OXCs. This
in order to enable the egress OSCtrl to find the outgoing LSC
interface for the damaged lightpath. The OSCtrl converts this
message into an internal control command it sends to the OXC switch
to enable the connection between the incoming and outgoing lambda
port in the OXC switch fabric. The OXC switch returns a result
status to the OSCtrl. Then, the egress OSCtrl reflects the result in
the Notification Message it sends to the ingress OSCtrl.
When the ingress (egress) OSCtrl receives the Notification message
sent by the egress (ingress) OSCtrl, corresponding to the lightpath
failure, both OXC activate the backup connection.
Since one of the backup lightpath is consumed (or created depending
on the restoration policy) by this restoration procedure, a new
alternative backup lightpath must be created. This procedure is
carried out according to the procedure of section 4.2.2. As we
consider the Restoration Path_Status of each of the backup
lightpath, this procedure must take into account the Path_Status
value of the consumed lightpath.
4.4.2 Restoration procedure for multiple damaged lightpaths
The previous section describes the basic restoration procedure for
multiple damaged lightpath. Depending on the restoration policy, the
following alternative is considered:
- Provisioned restoration: in order to decrease the number of
notification messages sent by the OXC detecting the failure, we
consider a unique Notification Message including the Lightpath ID
and Path_Status value of each of the damaged lightpath belonging to
the same Restoration Group ID. At the ingress OXC, if the number of
provisioned backup is not sufficient, then additional backup
lightpath can be created as described in section 4.2.2. However, the
egress OXC never initiates a backup Lightpath Create Request Message
even if the number of backup lightpath is not sufficient to restore
a sufficient number of damaged primary lightpaths.
- Non-provisioned restoration: the same notification mechanism as
the one described for provisioned restoration is used. However, only
Internet Draft û Expires August 2001 20
Draft-many-optical-restoration-00.txt February 2001
the ingress OXC initiates a backup Lightpath Create Request Message
in order to restore the damaged primary lightpaths.
4.4.3 Restoration procedure for damaged backup lightpath
In case of failure of a backup lightpath, the ingress OXC must be
aware which lightpath is damaged by referring to the Lightpath ID,
the Restoration Group ID and Restoration Path_Status of the backup
lightpath.
The damage of a backup lightpath must not affect to the ongoing data
transfer. However, since the primary lightpaths belonging to the
same restoration group lose the restoration capability, an
alternative backup lightpath must be created when a backup lightpath
failure is detected. The procedure for creating alternative backup
lightpath is executed according to the procedure of section 4.2.2.
4.4.4 Restoration procedure for damage primary and backup lightpaths
It is possible that a combination of failures will affect primary
and backup lightpaths in a restoration group. In general, in an M:N
restoration group, a set of failures can occur so that N' primary
lightpaths and M' backup lightpaths are disabled. If the number of
remaining backup lightpaths M - M' is less than the number of
affected primary lightpaths N', then it will not be possible for the
network to restore service to all the affected primary lightpaths by
using the standard restoration procedure described in the preceding
sections.
In such a situation, the network should attempt to provide automatic
restoration services to as many affected primary lightpaths as
possible. If different priority (i.e. precedence) levels are
assigned to the various primary lightpaths in the restoration group,
those affected lightpaths with the highest priority will have their
traffic routed onto the remaining backup lightpaths. Once all the
highest-priority affected lightpaths have been served, the network
will then attempt to provide backup lightpaths for the set of
affected lightpaths that have the next highest precedence level.
This process will continue until the supply of unaffected backup
lightpaths has been exhausted. If all the affected lightpaths have
the same priority level or if priority levels are not being used,
backup paths will be activated for them on a first come, first
served basis (FIFO-like service).
For the remaining N' - M + M' lightpaths that do not have backup
lightpaths available, the network will attempt to create backup
lightpaths on the fly using the procedure in Section 4.2.2. It will
do this by precedence level or on a first come, first served basis
until all N' affect primary lightpaths have been served or until M
backup lightpaths have been used. After the restoration procedures
have been completed, the network will create N new backup
lightpaths, as described in Section 4.4.1, for the restoration
group.
Internet Draft û Expires August 2001 21
Draft-many-optical-restoration-00.txt February 2001
4.5 Lightpath release procedure
4.5.1 Release procedure with non-revertive restoration policy
The release of a lightpath can take place for several reasons:
(1) the primary or backup lightpath becoming impaired by the damage
(2) the backup lightpath becoming unneeded due to the release of a
sufficient number of primary lightpaths belonging to the same
restoration group
(3) the primary or backup lightpath not further processed due to the
occurrence of an non-recoverable error during the lightpath creation
procedure
(4) the preemption by a lightpath with a higher precedence when the
preempting lightpath is unable to obtain free network resources to
be created (this case include the blocking probability recovery)
(5) the primary lightpath becoming under-utilized due to a decreased
volume of the data traffic (in a data-driven approach only and not
considered in this memo since the procedure associated to such an
event is a lightpath modification procedure)
A Lightpath Delete Request Message is sent from the ingress OXC to
the egress OXC or to an intermediate OXC by passing through the
intermediate OXCs comprising the target lightpath that experience a
failure. For this process, the Lightpath Delete Request Message
includes the identifier of the damaged lightpath (which stands for
the explicit route) in order to determine at each the sequence of
intermediate OXCs that this message need to follow.
When an intermediate OXC receives the Lightpath Delete Request
Message from its upstream OXC, its OSCtrl attempts to configure the
OXC switch fabric according to the Lightpath Delete Request Message
content, and wait to receive the result from the OXC switch. If a
successful result is returned, the OSCtrl of the intermediate OXC
transmits the Lightpath Delete Request Message to the next
downstream intermediate OXC. During this procedure, intermediate
OXCs release the optical network resources and then update their
link state database by marking the corresponding resources as
reserved.
If the Lightpath Delete Request Message successfully proceeds all
the way to the egress OXC, the latter notifies the result of the
delete request by generating a Lightpath Delete Response Message
back to the ingress OXC. By receiving this message, intermediate
OXCs update their link state database by marking the optical network
resources as unused. This link state information will be then
flooded through usual OSPF/IS-IS link-state advertisement.
If the intermediate OXC receiving the Lightpath Delete Request (or
Response) Message fails to commit the release in the OXC switch
fabric, an error message is returned to the OSCtrl and subsequently
propagated back using a Notification Message.
Internet Draft û Expires August 2001 22
Draft-many-optical-restoration-00.txt February 2001
4.5.2 Maintenance procedure with revertive restoration policy
If we consider a revertive approach, then the resource used by the
damaged lightpath must not be released in order to be re-used when
the failed æresourceÆ will be available again. More precisely, the
non-release procedure is a standby maintenance procedure since the
resources can not be used either by the damaged primary lightpath or
by any another lightpath. Note here that we assume that the
notification message generated during the failure detection has
already trigger usage of a backup lightpath between the ingress and
the egress OXC.
By receiving the Notification Message sent by any OXC included
within the route of the failed lightpath indicates the corresponding
resources as reserved (i.e. locked) within the local link state
database. The sub-sequent unlock process of the resources reserved
for this lightpath depends on following alternative:
- if the failure is not recovered at expiration of the restoration
time-out, then the OXC(s) still experiencing the damage sends a last
Notification Message; and as described for the non-revertive
approach, the ingress OXC initiates a primary lightpath deletion
procedure;
- if the failure is recovered prior to the expiration of the
restoration time-out, then by reaching the ingress OXC, the last
Notification Message initiates a Lightpath Create Request Message
whose effect is to unlock the resources reserved for the ærestoredÆ
lightpath. When both end of the restored lightpath are synchronized
(i.e. the ingress OXC received the Lightpath Create Response Message
back from the egress OXC) the switching from the backup to the
primary lightpath can occur.
5. Signaling Extensions
In this section, we define the message types that are used for the
bandwidth provisioning and restoration procedures. These message
types and their corresponding can be further defined and included
within optical CR-LDP (and within optical RSVP extensions) signaling
extensions.
5.1 Lightpath Create Request Message
A Lightpath Create Request Message is issued to create a primary
lightpath or backup lightpath by an ingress OXC. As defined in
[MPLS-CRLDP] and generalized in [GMPLS-CRLDP], the explicit route
field of the Label Request Message (i.e. the Lightpath Create
Request Message) specifies the path to be taken by the lightpath
being established.
Internet Draft û Expires August 2001 23
Draft-many-optical-restoration-00.txt February 2001
The Label Request Message must include additionally to the
parameters already defined, the following specific information
defined within. The Restoration TLV format is defined as:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type (TBD) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Restoration Group ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Type & Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preemption TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Restoration Policy TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Restoration TLV (optional) which could include the following
information:
- Restoration Group ID: 48-bit field identifying the restoration
group to which the lightpath belongs. The Restoration Group ID is
defined is a unique identifier of a Restoration Group defined within
a GMPLS network. The Restoration Group ID is defined as been
composed by the following fields:
- the ingress LSR Router ID (i.e ingress OXC ID) or any of its own
IPv4 addresses
- a locally unique Group ID (16-bit) to that LSR
- a locally unique P integer (8-bit) specifying the number
restoration Group IDs sharing the backup LSPs, to that LSR
The Restoration Group ID TLV format is defined as:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type (TBD) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P Group | Res |ActFlg | Local Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress LSR Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ActFlg is a 4-bit field that indicates explicitly the action
that should be taken if the Restoration Group already exists on the
LSR receiving the message. The ActFlg value must be set to 0001
(modify LSP indication) except when a new Restoration Group has to
be created.
- Restoration Path_Type: 1-bit field (T bit) enabling the
distinction between a primary and backup lightpath is defined
through the use of the Restoration Path_Type bit. When the
Internet Draft û Expires August 2001 24
Draft-many-optical-restoration-00.txt February 2001
Restoration Path_Type bit equals to 0 the lightpath is defined as a
primary path and when it equals to 1 the lightpath is defined as a
backup path.
- Restoration Path_Status: for primary path this 15-bit integer
assigned by the ingress OXC takes a value within the range [0, N]
with N < 32767 and for backup path this integer takes a value within
the range [0, M] with M < N.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type (TBD) | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Path Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Restoration Priority: this optional parameter defines the setup
priority (8-bit field) and holding priority (8-bit field) of the
restoration group to which it refers. In [MPLS-CRLDP], the
corresponding Preemption TLV is format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0820 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SetPriority | HoldPriority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that the default value of the setup and holding priorities
should be in the middle of the range (e.g., 4).
- Restoration Policy: this optional parameter (8-bit field) includes
. the restoration strategy bit: revertive (R bit = 0) or non-
revertive (R bit = 1)
. the restoration scheme bit: provisioned (P bit = 0) or non-
provisioned (P bit = 1)
. the restoration diameter bit: partial restoration (D bit = 0) or
end-to-end restoration (D bit = 1)
. the setup (S bit) and recovery (R bit) preemption behavior of
the lightpath included within the corresponding restoration group:
the setup and the recovery preemption bit values are defined by
the ingress OXC;
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type (TBD) | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|P|D|S|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Internet Draft û Expires August 2001 25
Draft-many-optical-restoration-00.txt February 2001
When the non-provisioned policy is selected, an additional parameter
referred to as the maximum restoration time can be considered. This
parameter enable to determine a æpre-selectedÆ route for the backup
lightpaths whose signaling delay is less than the maximum
restoration time.
The restoration policy parameter values should be the same for all
the lightpath belonging to the same restoration group.
5.2 Lightpath Create Response message
This message is used as the response message for the Lightpath
Create Request Message. As described in [MPLS-CRLDP] and generalized
in [GMPLS-CRLDP], an ingress OXC identifies a Label Mapping Message
(i.e. Lightpath Create Response Message) respectively by comparing
the Message ID conveyed by a Label Request Message (i.e. Lightpath
Create Request Message) with the Message ID that was issued by
itself.
The Label Mapping Message must include additionally to the
parameters already defined, the specific information defined within
the Restoration TLV (optional); which could include the specific
information within the Result Code TLV.
5.3 Notification Message
The lightpath restoration procedures imply the definition of an
additional Notification Message type. This Notification Message must
include the Lightpath ID (i.e. LSPID TLV - see section 5.3.2) as
well as the Status of the corresponding lightpath (or the list of
lightpaths).
The Status of the lightpath must include the current status of the
lightpath (active, inactive, reserved, failed) as well as optionally
the alarm detection such as a LoL, LoS, BER, OSNR, etc. resulting
from the physical network damage or failure.
5.3.1 Notification Message format
As defined in [MPLS-LDP], an OXC sends a Notification Message to
inform an OXC peer of significant event. A Notification Message
signals a fatal error or provides advisory information such as the
outcome of processing a CR-LDP message or the state of the LDP
session.
Here, to distinguish between Notification Message sent in response
to a Label Request Message and Unsolicited Notification Message, we
define an Unsolicited Notification Message type. Consequently, to
inform an OXC peer of significant event within the transport plane,
an OXC sends an Unsolicited Notification Message.
The encoding for the Unsolicited Notification Message is:
Internet Draft û Expires August 2001 26
Draft-many-optical-restoration-00.txt February 2001
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0002) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type û Unsolicited Notification (0x0002)
Message ID
32-bit value used to identify this message.
Status TLV
Indicates the event being signaled. The encoding for the
Status TLV is specified in Section "Status TLV" of [MPLS-LDP].
The Status Code included in the Status TLV must have the fatal
error E bit = 0 (advisory notification) except if a fatal error
is notified E bit = 1 (fatal error). If the Notification
Message need to be forwarded the forward F bit = 1, otherwise F
bit = 0. The latter case applies only for unidirectional link
failure restoration procedure.
Optional Parameters
This variable length field contains 0 or more parameters, each
encoded as a TLV. For the purpose of this memo, only the
Extended Status TLV (type 0x0301 û length 32-bit) will appear
in Notification Messages.
5.3.2 Notification Message Parameters
For the notification messages, the additional parameters defined for
lightpath restoration purposes are:
- Lightpath ID: which corresponds to the LSPID TLV defined in [MPLS-
CR-LDP]
This identifier is mandatory and corresponds to the 48-bit value of
the optical network identifier defining the lightpath. The Lightpath
ID corresponds to the LSPID defined in [MPLS-CRLDP] which is a
unique identifier of a Constraint-based LSP defined within a GMPLS
network. The LSPID is defined as been composed by the ingress LSR
Router ID (or any of its own IPv4 addresses) and a locally unique
LSPID (16-bit) to that LSR. So, we define the Lightpath ID as been
composed by the node ID of the source OXC and a locally unique
identifier to that OXC.
0 1 2 3
Internet Draft û Expires August 2001 27
Draft-many-optical-restoration-00.txt February 2001
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0821 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |ActFlg | Local LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress LSR Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ActFlg is a 4-bit field that indicates explicitly the action
that should be taken if the LSP already exists on the LSR receiving
the message. The ActFlg value must be set to 0001 (modify LSP
indication).
- Link ID (or Bundle ID): 32-bit integer identifying the link (or
the bundle) that experiences a failure. The Link (or the bundle) can
be numbered or unnumbered. A list of Link IDs is needed in order to
notify multiple simultaneous failures. Consequently, the format of
the Link TLV includes at least one Link ID:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type (TBD) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Status: The additional status (values) included in the Status TLV
are defined with respect to the restoration procedure they refer:
. Active Connection Status defines an Active Notification Message
. Inactive Connection Status defines an Inactive Notification
Message
. Reserved Connection Status defines a Reservation Notification
Message
. Suspend Connection Status defines a Suspend Notification Message
. Failed Connection Status defines a Failure Notification Message
The optional Extended Status only refers to the Failed Connection
Status Code. The Extended Status are defined as follows:
- LoL: Loss of Light detected
- LoS: Loss of Signal detected
- BER: BER Threshold exceeded
- OSNR: OSNR Threshold exceeded
- Jitter: Jitter Threshold exceeded
Consequently, the encoding of the Unsolicited Notification Message
is defined as:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0002) | Message Length |
Internet Draft û Expires August 2001 28
Draft-many-optical-restoration-00.txt February 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSPID (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.3.3 Fault Tolerant Notification Message
As described in section 4.3.3, a Fault Tolerant (FT) Notification
mechanism can be extended to implement a reliable notification
procedure after the lightpath failure has been detected.
As described in [MPLS-LDPFT], the corresponding FT Protection TLV is
optional and is included only if Reliable Notification as defined in
Section 4.3.3 is being negotiated during the FT CR-LDP session
establishment. If reliable transportûplane notification is desired,
FT status must be negotiated by the participants in the CR-LDP
session during the exchange of LDP Initialization Messages.
These messages must contain the FT Session TLV as defined in [MPLS-
LDPFT], which is also used to negotiate the amount of time that a
node will maintain state for FT resources and labels in the event of
LDP session failure. The new FT Path Protection TLV message format
is defined as:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| FT Path Protection (TBD) | Length (= 4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FT Sequence Number:
32 bit unsigned integer that uniquely identifies each message
in a CR-LDP session between two nodes. The sequence number is
initialized to 0x00000001 when the CR-LDP session is created
at FT status is negotiated. It increments by 1 when a new
notification message is transmitted, and wraps from 0xFFFFFFF
to 0x00000000.
If an LSR transmits a Fault Notification message using a FT CR-LDP
session and does not receive an acknowledgment from the target node
within the time allocated by the NCR, it will retransmit the
message, without incrementing the FT Sequence Number, using the
continuous notification mechanism defined in Section 4.3.2.
Internet Draft û Expires August 2001 29
Draft-many-optical-restoration-00.txt February 2001
While [MPS-LDPFT] does not require FT ACKs to be sent immediately,
they should be sent as soon as possible in response to Failure
Notification Messages by the LSR recovering the LSP failure. The
corresponding FT ACK TLV message format is defined as:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| FT ACK (TBD) | Length (= 4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT ACK Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ACK Sequence Number:
32 bit unsigned integer that identifies the most recent FT
Protection Sequence Number that was received by the sending
node in the LDP session, as defined in [MPLS-LDPFT]. The ACK
Sequence Number is cumulative, e.g. a value of 0x0000000F
indicates that the first 15 messages in the session have been
successfully received.
Consequently, the updated Unsolicited Notification Message with
Reliable Notification encoding is defined as:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0002) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSPID (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT Path Protection (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6. Security Considerations
It is essential to maintain secure communication between the OXCs.
However, this document does not address the detailed security
consideration. These considerations are reserved for future study.
7. References
1. [GMPLS-CRLDP] P. Ashwood-Smith et al., æGeneralized MPLS
Signaling - CR-LDP Extensions,Æ Internet Draft, draft-ietf-mpls-
generalized-cr-ldp-00.txt, November 2000.
Internet Draft û Expires August 2001 30
Draft-many-optical-restoration-00.txt February 2001
2. [GMPLS-ISIS] K. Kompella et al., æIS-IS Extensions in Support of
MPL(ambda)S,Æ Internet Draft, draft-kompella-isis-gmpls-extensions-
00.txt, November 2000.
3. [GMPLS-OSPF] K. Kompella et al., æOSPF Extensions in Support of
MPL(ambda)S,Æ Internet Draft, draft-kompella-ospf-gmpls-extensions-
00.txt, November 2000.
4. [GMPLS-SIG] P. Ashwood-Smith et al., æGeneralized MPLS Signaling
û Signaling Functional Requirements,Æ Internet Draft, draft-ietf-
mpls-generalized-signaling-01.txt, November 2000.
5. [GMPLS-BUNDLE] Bala Rajagopalan et al., æLink Bundling in Optical
Networks,Æ Internet Draft, draft-rs-optical-bundling-01.txt,
November 2000.
6. [IPO-CTRL] A. Chiu et al., æUnique Features and Requirements
for the Optical Layer Control Plane,Æ Internet Draft, draft-chiu-
strand-unique-olcp-01.txt, November 2000.
7. [IPO-FRAME] B. Rajagopalan et al., æIP over Optical Networks: A
Framework,Æ Internet Draft, draft-many-ip-optical-framework-02.txt,
November 2000.
8. [IPO-LMP] A. Fredette et al., æLink Management Protocol (LMP) for
WDM Transmission Systems,Æ Internet Draft, draft-fredette-lmp-wdm-
00.txt, December 2000.
9. [IPO-MPLS] D. Awduche et al., æMulti-Protocol Lambda Switching:
Combining MPLS Traffic Engineering Control With Optical
Crossconnects,Æ Internet Draft, draft-awduche-mpls-te-optical-
02.txt, July 2000.
10. [IPO-ONNI] D. Papadimitriou et al., æOptical Network-to-Network
Interface û Architecture, Routing and SignallingÆ, Internet Draft,
draft-papadimitriou-onni-frame-02.txt, February 2001.
11. [IPO-OPM] D. Papadimitriou et al., æOptical Signal Performance
Measurement,Æ Work in progress, draft-papadimitriou-optical-opm-
00.txt, February 2001.
12. [IPO-SRLG] D. Papadimitriou et al., æInference of Shared Risk
Link Groups,Æ Internet Draft, draft-many-inference-srlg-00.txt,
February 2001.
13. [MPLS-CRLDP] B. Jamoussi et al., æConstraint-Based LDP Setup
using LDP,Æ Internet Draft, draft-ietf-mpls-cr-ldp-04.txt, July
2000.
14. [MPLS-LDPFT] Brittain et al., æFault Tolerance for LDP and CR-
LDP,Æ Internet Draft, draft-ietf-mpls-ldp-ft-00.txt, October 2000.
Internet Draft û Expires August 2001 31
Draft-many-optical-restoration-00.txt February 2001
15. [NEXT-OSPFv3] S. Giacalone, æNetwork Engineering Extensions
(NEXT) for OSPFv3,Æ Internet Draft, Work in Progress, August 2000.
16. [IEEE-IC99] S. Ramamurthy and B. Mukherjee, æSurvivable WDM mesh
networks - ProtectionÆ, Proceedings Infocom 99, March 1999.
17. [IEEE-ICC99] S. Ramamurthy and B. Mukherjee, æSurvivable WDM
mesh networks - RestorationÆ, Proceedings Int. Conference
Communication 99, June 1999.
7. Acknowledgments
This work has been produced from the joint project between ETRI
(Electronics and Telecommunications Research Institute in Korea)
NIST (National Institute Standards and Technology).
From this collaboration, the following draft was published: draft-
hahm-optical-restoration-01.txt and used as guideline for the
publication of the current document.
The authors would like also to thank Doug Montgomery and Mark Carson
(NIST) and Bernard Sales, Emmanuel Desmet, Hans De Neve, Stefan
Ansorge, Gert Grammel, Mike Sexton and Jim Jones (Alcatel) for their
valuable comments, suggestions and inputs.
8. Author's Addresses
Jin Ho Hahm
ETRI
820 West Diamond Avenue
Gaithersburg, MD 20899, USA
Phone: +1 301-975-8400
Email: hahm@antd.nist.gov & jhhahm@etri.re.kr
Kwang-il Lee
Advanced Network Technologies Division
National Institute of Standards and Technology (NIST)
820 West Diamond Avenue
Gaithersburg, MD 20899, USA
Phone: +1 301 975-8428
Email: kilee@antd.nist.gov
David W. Griffith
Advanced Network Technologies Division
National Institute of Standards and Technology (NIST)
100 Bureau Drive, Stop 8920
Gaithersburg, MD 20899-8920, USA
Phone: +1 301 975-3512
Email: david.griffith@nist.gov
Riad Hartani
Caspian Networks
170 Baytech Drive,
Internet Draft û Expires August 2001 32
Draft-many-optical-restoration-00.txt February 2001
San Jose, CA 95134, USA
Phone: +1 408 382-5216
Email: riad@caspiannetworks.com
Dimitri Papadimitriou (Editor)
Optical Networking Research
Alcatel IPO-NSG
Francis Wellesplein, 1
B-2018 Antwerpen, BELGIUM
Phone: +32 3 240-8491
Email: dimitri.papadimitriou@alcatel.be
Fabrice Poppe
Optical Networking Research
Alcatel IPO-NSG
Francis Wellesplein, 1
B-2018 Antwerpen, BELGIUM
Phone: +32 3 240-8006
Email: fabrice.poppe@alcatel.be
Internet Draft û Expires August 2001 33
Draft-many-optical-restoration-00.txt February 2001
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into
Internet Draft û Expires August 2001 34