How To Design Mesh-Restorable Networks V1

.
.
.
.
.
.
.
.
.
.
On the design of span- and
path- restorable mesh
networks
TRLabs Technical Report TR 2001-01
Release 1, November 2001
It is intended that this document will be updated and grow in its coverage of additional
schemes. The next update will include the addition of design for shared backup path
protection schemes
Wayne D. Grover, John Doucette
TRLabs / University of Alberta
Design of mesh-based transport networks Version 1, November 2001
2
I. Introduction
Brief Historical Background:
Accumulating experience with the planning and operation of ring-based transport
networks, and the advent of a DWDM-based optical networking layer has set the stage
for revisiting the mesh-restorable transport alternative following a decade in which rings
were the dominant approach for transport survivability.
The principle theoretical advantages of a mesh over ring-based transport are its greater
capacity efficiency (lower ratio of required spare to working capacity) and relative
simplicity in provisioning to satisfy growth and changes in demand pattern. Mesh-based
networking is also far more amenable to ideas of automated self-provisioning of new
service paths. A mesh is inherently more flexible than a committed set of rings.
On the other hand, two factors have often worked against industry-wide adoption of
mesh-based solutions in recent generations of technology (primarily the Sonet era). These
have been:
(i) the relatively poor economics of the past cross-connect devices (on which mesh
provisioning and restoration is based), relative to add-drop multiplexors (ADMs) on
which rings are based, and
(ii) the typically slower restoration times which could be offered by mesh restoration
times (several hundred milliseconds opposed to the 50 msec benchmark of rings or
APS systems).
So what is different now? Why would a more capacity-efficient mesh imply
corresponding dollar-cost savings? One factor is optical networking technology based on
DWDM: The distance-dependent transmission costs for EDFAs, plus transmission-
related nodal termination and routing / switching equipment quantities, are high enough
to place a significant emphasis on capacity efficiency at the lightwave utilization level. In
the past nodal switching costs dominated and the truism was that transmission was nearly
free in comparison.
In addition, today, the optical transmission capacity (and associated line and nodal
transmission / cross-connecting gear) can sometimes barely even be provisioned quickly
enough to keep up with bandwidth needs. Regardless that the price per bit keeps going
down, the amount needed goes up as fast or more quickly so that the absolute yearly
capital expenditures on transmission equipment remain very significant: But even if the
cost-related argument for capacity efficiency was dismissed, it is still the case that more
revenue could be earned with an existing transmission base if less capacity has to be set
aside for restoration.
This is one of the main reasons that mesh restoration stands ultimately to become more
cost-effective than rings, especially in a long-haul environment with rapid demand
growth.
3) prepared by W. Grover TRLabs Copyright 2001 W. Grover grover@trlabs.ca
2 : Basics of mesh - restorable networks
This section is intended to touch on the key concepts and issues of span- and path-
restorable networks. Section 3 goes on to show the design methods in detail.
Terminology
A transport network must inherently be treated as a multi-graph or capacitated simple
graph. The widespread practice of referring to almost anything that connects two entities,
at any layer either physical or logical, simply a link is not precise enough in this
environment. For capacitated design of transport networks it is helpful to have ways of
distinguishing between references to physical entities, logical entities, signal paths,
simple routes, etc. A link in a logical layer may actually be a signal path over a route
comprised of several spans in the physical layer for example. We therefore define the
following generic terminology for work on transport network design.
Link:
A link is a logical pipe or connection between service layer devices such as a router or
telephone switch. In the transport layer each individual logical unit of transport capacity
between two adjacent nodes of the transport network is thus potentially part of a service-
layer link. For example, in a DWDM optically cross-connected transport network, a
single wavelength may be the unit capacity for forming service layer links. In a transport
network managed at the Sonet cross-connection layer the link unit may be the individual
STS1 or STS3c signal units managed. A link of capacity in the transport layers is often
also known as .a. capacity unit, bandwidth unit or a channel. These are discrete
(integer) entities in either WDM or Sonet.
Span:
A span is the set of all transmission links (both working and spare) between two nodes at
which transport-layer signal management is performed and which share the fate in the
event of a physical cut of a facilities structure such as a cable of duct system.. There may
be several transmission systems operating in parallel, but all following the same physical
right-of-way or facilities structure (pole line, ducts, trenches, etc). A group of such
transmission systems, possibly of various types and rates, a logically represented in the
planning problem as one edge in the network graph and an associated capacity which is
the total provisioned capacity of all systems in the span in terms of whatever capacity
units at which the transport network is being provisioned and managed. A span is the
independent entity that physically undergoes a cut (if one occurs), not a link. For
planning purposes we assume any span cut fails all working and spare capacity on the
span.
Route:
A route is any contiguous sequence of spans. i.e., simply a geographically connected
walk over physically existing spans between any two nodes in the network.
4
Path:
A path is a specific cross-connected concatenation of individual unit-capacity carrier
signals (links) following a route through the network. It is working paths that serve to
transport demand flows. Restoration path sets will be formed out of spare capacity units.
Reserve Network:
A term used to refer to the entire capacitated graph of spare capacity available for
restoration. A graph in which each edge has a limit to the flow that can cross the edge
(i.e., an edge capacity) is called a capacitated graph (as opposed to an uncapacitated
graph in which there are no such limits.)
"Span-restorable" mesh networks
The capacity-design of both span- and path- restorable networks is perhaps best
appreciated by starting with a look at the type of restoration re-routing mechanism that is
the basis for each class of network.
Span restoration re-routing In a network based on span restoration
1
, cable cuts (or
single unit-capacity link failures) are restored by re-routing between the end-nodes of the
break directly. Thus, span restoration is like a locally applied set of detours around a
break in the road. Note, in this analogy that if the road or highway that is disrupted has
several lanes, there may be an independent detour path deployed for each lane of the
highway. There is no stipulation that all affected demands must travel as a group via a
single replacement route. Rather, the total amount of work capacity disrupted is
efficiently re-routed at the individual link capacity unit level of the associated bandwidth-
management layer.
A common misunderstanding about span-restorable mesh networks is the notion that
restoration is via a single two-hop route around the break, such route having enough
spare capacity to handle the entire working capacity of the failed span. It is important to
correct this for a proper assessment and appreciation of the potential benefits. More
generally in span restoration, each individual failed working link unit may take a different
restoration route, up to some hop limit (H) that can be considerable more that two hops.
This makes for a much greater opportunity for network-wide sharing of spare capacity.
Figure 1 illustrates the issue. More technically, the two-hop single-route restoration
model is just the special case of "H=2, fully bundled".

1
Other writers alternatively refer to this as "link restoration."
a common, but misleading,
portrayal of span restoration
the more general concept of span
restoration permiting much greater
sharing of network spare capacity
Figure 1: Different understandings of span restoration.
From Figure 1 it can be seen that there is a great deal more opportunity to share network
protection capacity on the right than on the left. In fact, through design controls on the
"hop (or distance) limit" parameter, a network operator can mediate a trade-off between
the maximum length of the restoration path-sets that would be acceptable against the total
investment in spare capacity required for restoration. Thus the fully bundled H=2 case on
the left above, gives the simplest re-routing characteristics, but uses the most spare
capacity. At higher hop-limits more complex patterns of re-routing arise, so as to
maximize spare capacity sharing. At a "threshold" hop-limit the theoretical minimum of
spare capacity is reached. Restoration path-sets even at this highest hop limit, however,
are typically not as complex as the example on the right, which is intended mainly as an
example of the generality of the re-routing that is possible.
Although the example may look complex, the path-sets in span restoration are always
algorithmically specified. Theoretically the ideal restoration path-set is equivalent to a
solution of the (single-commodity) max-flow problem between the immediate end nodes
of the failed span (the custodial nodes). In practice this is very closely approximated by
a type of k-shortest paths (ksp) re-routing [2]. The literature in graph and routing theory
contains many variants of "k-shortest paths", many of which are for scheduling and
project management applications on uncapacitated graphs, and may include looping -to
enumerate successive route-lengths. The model to approximate max-flow for span
restoration is, however, specifically the set of k non-looping link-disjoint paths of
successive length up to the maximum number of paths feasible or required for restoration.
Note that link-disjointness refers here specifically to disjointness at the unit-capacity of
transport management. This means that no unit-capacity link can be used in more than
one path, but any number of restoration paths can share the same span, up to the spare
capacity limit of the span. In other words the paths are not span-disjoint, but as a set have
to respect the capacitation of all spans. The ksp path-set can thus be thought of as the
6
process of finding "all the paths feasible on the shortest route, followed by all the paths
feasible on the second shortest route not using any spare links from the first set, followed
by the set of feasible paths on the third-shortest replacement route not using and spare
links of the first or second set of paths, etc." (up to the maximum allowed hop- or
distance-limit). The paths are link-disjoint (i.e., they are discrete and feasible under the
capacities present) but are not limited to being span-disjoint.
For many planning and study purposes dealing with span-restorable networks, the "k-
shortest paths" (ksp) path-sets for span restoration can be found by an O(nlogn) algorithm
[11] that generates restoration paths, up to the number feasible or needed in each case.
2
A
related point for clarification is that while the ksp reference model for span restoration
finds its paths in a sequentially increasing iterative manner, we do not mean to suggest or
imply that the actual real-time restoration protocols work the same way. For instance a
distributed span-restoration protocol may actually find all paths at once without iteration
and be equivalent in terms of path number and path length total to algorithmic ksp,
without being based on a direct iterative ksp approach [12].
Capacity design for span restoration: A "span-restorable mesh network" is one in which
the spare capacity allocation across the network is sufficient to allow this type of re-
routing behavior to provide 100% restoration of any single span cut. An input parameter
when we design the spare capacity of a mesh network is the maximum hop or distance
limit that one considers acceptable for restoration in the network. Hop counts, H, are
typically in the range of 5 to 10 for many networks at the level at which the network can
be viewed as a mesh - more will be said about this later. This is the concept of a meta-
mesh abstraction for the case of networks with extensive chain segments.
H
min
H*
Full
restoration
infeasible
Total
spare
capacity
Design Hop Limit, H
Figure 2: How mesh network spare capacity depends on hop limit.

2
Here, n is the number of nodes in the network.
Figure 2 illustrates how the optimum spare capacity decreases with increasing hop count
for eligible restoration routes, up to a threshold limit. In specifying a hop count for the
design there are two main considerations: H should be sufficiently high so as to enable
achievement of the theoretical minimum of spare capacity. As the hop count is
conceptually increased from the minimum starting value (of two), a network first reaches
a state where 100% restorability becomes feasible. (Not all networks will even be
restorable, regardless of capacity, under the pure H=2 deflection re-route model discussed
above.) Further increases in H allow full restorability to be satisfied with decreased total
spare capacity, because the sharing of spare capacity on each span over separate failure
scenarios is increasing, until the threshold hop limit, H* , is reached. Thereafter increases
in H provide no further reduction in total spare capacity.
As a matter of study design, some preliminary tests can determine H* and the detailed
capacity designs conducted using that value, as long as it is not excessive from a practical
restoration distance standpoint or from the standpoint of computational complexity of the
design formulations that follow.
"Path-restorable" mesh networks
If we return to the analogy of re-routing around a multi-lane highway section that is
under repair, path restoration is more like planning a completely different route before
setting out on the journey, as opposed to following the regular route up to the break then
taking a local detour. In the transport network context it is thus equivalent to rapid tear-
down and re-provisioning of new end-to-end paths (which avoid the break) for every
affected O-D pair simultaneously. Path restoration thus distributes the impact of failures
and the recovery effort more widely over the network as a whole and therefore generally
permits greater efficiency in spare capacity design. Theoretically this offers even lower
network spare capacity requirements for 100% restorability, but it comes at the price of a
quite significant escalation in both design and real-time reconfiguration complexity. A
simple illustration of the concept, in contrast to span restoration, is shown in Figure 3.
8
Figure 3: Example of path restoration
The solid lines in Figure 3 show the pre-failure working path routings. The dashed lines
show what is called "stub-release" - the surviving portions of the pre-fail path up to and
following the break are released back into a pool of effectively spare capacity for
restoration. (Otherwise these stub-segments of the pre-failure paths are like unusable
deadwood that in fact get in the way and can even block restoration sometimes. In the
example the top path retraces its path up to the break (using a left to right orientation)
then takes a completely different path the rest of the way to its destination. The next
lower path takes a completely disjoint route end-to-end.
With path restoration the key technical issue is that to have an assurance of 100%
restoration within the relatively even lesser amount of spare capacity in a path-restorable
network, one must globally solve for the correct co-ordination amongst restoration path-
sets for individual origin -destination (O-D) pairs. The issue is sometimes referred to as
the "mutual capacity" problem : in the worst case up to N (N-1)/2 O-D pairs may
simultaneously want to make use of the limited spare capacity available on one span out
in the body of the network. A small example can be based on the figure above. This is
Figure 4 below.

Figure 4: Illustrating the importance of stub release in path restoration.
Say the top path in Figure 4 took the alternate route shown (relative to Figure 3.) This
route may be equally good (short) from the point of view of this O-D pair alone, but as
can be seen below, would block out the second path (assuming the available spare
capacity can just support the initial path-set above.)
Therefore the allocation of spare links on every span must be made so that all required
restoration paths are feasible at once. If a spare link on one span is allocated to one O-D
pair, which may have several diverse options for re-routing, another O-D with fewer
routing options may be frozen out and fail to obtain full restoration. A set of
independently determined shortest replacement paths for each O-D in isolation does not
provide this property at all.
The problem is still solvable of course. Formally, the solution to the multiple O-D pair
simultaneous re-routing problem is a multi-commodity maximum flow (MCMF) problem
with constraints on amounts of each commodity [3]. Optimal solution to this problem is
NP-hard (compute time rises exponentially with problem size) whereas for span
restoration the re-routing problem is practically and indeed optimally solvable in low-
order "polynomial time" (O(n
2
) for ksp or O(n
3
) for strict max-flow).
3 : Design Theory and AMPL / CPLEX Details
Span restorable networks
In this section we look at the design of span-restorable mesh networks using a basic "arc-
path" type of optimization formulation first promoted by Meir Herzberg, then of Telestra
(Australia), in 1994 [4]. We present an extension of Herzberg's work that includes joint
optimization of the working path routing along with spare capacity placement. This is

10
logically the version of the span-restorable mesh design problem that most directly
corresponds to the ring-based status-quo in the sense that BLSR / OPSR ring
functionality is a form of span restoration (not path restoration or 1+1 APS) and, in ring-
based networking, we always have to plan the routing of working paths in concert with
the protection structures being employed (as opposed to pure shortest path routing of the
workers independent of the protection capacity).
This basic formulation is later referred to as the "joint", span-restorable, design case and
it may be solved with or without optimized chain sub-networks through changes in the
basic model that will be described. The basic model to follow does not treat chain sub-
networks in the "optimized" manner described above. That follows as an enhancement to
the basic model.
Basic Model for Optimal Capacity Design: Joint, Span-restorable, no chain bypass.
Parameters:
C
j
Cost of each unit of capacity on span j
L
i
Target Restoration level for span i (L
i
= 1 assumed henceforth)
S Number of spans in the network
P
i
Number of eligible routes for restoration of span i (discussed below)
w
j
Number of working links (capacity units) on span j
i,j
p
Equal to 1 if p
th
eligible route for span i uses span j
D Total number of O-D pairs with non-zero demand
d
r
Number of demand units for O-D pair r
Q
r
Number of eligible working routes available for demand pair r
j
r,q
Equal to 1 if q
th
eligible route for demands between O-D pair r uses span j
Variables:
f
i
p
Restoration flow assigned to p
th
eligible restoration route for span i
s
j
Number of spare capacity units placed on span j
g
r,q
Working capacity assigned to the q
th
eligible working route for demand pair r
w
j
Number of working capacity units on span j
1
( )
s
j j j
j
Minimize C w s
(1)
Subject to:
1 i i
P
p
p
i
L w f
i

1
. ,..., 2 , 1 S i (2)
,
1
i
P
p p
j i j i
p
s f
j i S j i . ,..., 2 , 1 ) , ( (3)
r
Q
q
r q r
d g
1
,
. ,..., 2 , 1 D r (6)
, ,
1 1
r
Q D
r q r q
j j
r q
g w

. ,..., 2 , 1 S j (7)
Constraint set (2) ensures that restoration for span failure i meets the target level.
Constraints (3) force sufficient spare capacity on each span j such that the sum of the
restoration paths routed over that span is met for every failure span i. The largest
simultaneously imposed set of restoration paths imposed in a span effectively sets the
minimum s
i
value on each span in the solution.
The constraint set (6) ensures that all working demands are routed. The constraints in (7)
generate the logically required working capacity required on each span j to satisfy the
sum of all pre-failure demands routed over it.
AMPL Model for Modular Joint Span restorable design
An AMPL model that implements the above formulation is shown below. The AMPL
model shown is actually suitable for the general case of modular min-cost design. In the
more general, modular, design case the family of available transmission module sizes and
corresponding per-span costs for each module can be entered in the parameters
ZmodCap[m] and Cost[m , j] where {1... } m M is the m
th
module size and j is the span
index.
12
# Joint Modular Span-Restorable Design Model
# This model is designed to jointly optimize the routing of working
# paths and spare capacity placement Modularity is included in the basic
# model. If a family of modular capacity sizes does not pertain
# simply provide the data file with a single module of size 1 which will be
# equivalent to the non-modular design.
# SETS
set SPANS; # (set of all spans)
set REST_ROUTES{i in SPANS};
# (set of all restoration paths for each span failure i)
set MODULES; # (set of all types of capacity modules)
set DEMANDS; # (set of all demand pairs or node pairs)
set WORK_ROUTES{r in DEMANDS};
# (set of all working routes for each demand pair r)
# PARAMETERS
param bypass{i in SPANS} symbolic;
param Cost{m in MODULES, j in SPANS};
# (cost (or distance as a surrogate)of module types on span j)
param DemUnits{r in DEMANDS};
# (number of demand units between node pair r)
param Level{i in SPANS};
# (the minimum required restoration level on span i)
param ZModCap{m in MODULES}; # (capacity of module type m)
param Delta{i in SPANS, j in SPANS, p in REST_ROUTES[i]};
# (equal to 1 if pth restoration route for failure of span
# i uses span j and 0 otherwise)
param Zeta{j in SPANS, r in DEMANDS, q in WORK_ROUTES[r]};
# (equal to 1 if qth working route for demand between node pair r
# uses span j and 0 otherwise)
# VARIABLES
var flowrest{i in SPANS, p in REST_ROUTES[i]} >=0, <=10000 integer;
# (restoration flow through pth restoration route for failure of
# span i)
var gwrkflow{r in DEMANDS, q in WORK_ROUTES[r]} >=0, <=10000;
# (working capacity required by qth working route for demand between
# node pair r)
var nmodules{j in SPANS, m in MODULES} >=0, <=100000 integer;
# (number of modules of type m placed on span j)
var spare{j in SPANS} >=0, <=100000 integer;
# (number of spare links place on span j)
var work{j in SPANS} >=0, <=100000 integer;
# (number of working links placed on span j)
# OBJECTIVE FUNCTION
minimize totcost: sum{m in MODULES, j in SPANS} Cost[m,j] * nmodules[j,m];
# CONSTRAINTS
subject to restorability{i in SPANS}:
sum{p in REST_ROUTES[i]} flowrest[i,p] = work[i];
subject to spare_capacity{i in SPANS, j in SPANS: i <> j}:
spare[j] >= sum{p in REST_ROUTES[i]} Delta[i,j,p] * flowrest[i,p];
subject to modularity{j in SPANS}:
spare[j] + work[j] = sum{m in MODULES} nmodules[j,m] * ZModCap[m];
subject to demands_routed{r in DEMANDS}:
sum{q in WORK_ROUTES[r]} gwrkflow[r,q] = DemUnits[r];
subject to working_capacity{j in SPANS}:
work[j] = sum{r in DEMANDS, q in WORK_ROUTES[r]} Zeta[j,r,q] *
gwrkflow[r,q];
# END
Concept of Eligible routes and their generation:
To implement the above formulation, one needs a pre-processing step, usually with
custom programs, to enumerate the sets of "eligible" working and restoration routes. The
ideal is to represent all distinct routes for restoration up to the threshold hop (or distance)
limit between adjacent node pairs on the network graph for span restoration, and the set
of all distinct routes up to a corresponding allowance in excess of the shortest path for
each O-D pair, for routing of working paths.
The complete sets of all such paths are, however, strictly O(S 2
dH
) where S is the number
of spans, H is the hop limit, and d is the average node degree. So in practice, unless the
hop limits are low, one typically has to limit the number of eligible restoration routes to a
target number for each relation, say to 10 or 20, or adopt a technique of artificially
reducing the hop limit and supplementing the resulting route-set with an explicit set of k-
successively shortest distinct routes without any hop limit [6].
In our recent studies, a further improved strategy for populating the route-sets has been
used. In this approach, the hop limit is adaptively determined for each span failure
scenario, or each working path to be routed, so that a minimum target number of distinct
eligible routes are found. For example, it might be desired to solve a joint span-restorable
design formulation where there are at least 10 distinct working path choices for each O-D
pair and 20 eligible restoration routes for every span failure scenario. The program that
identifies such routes takes each failure case individually and first conducts a complete
depth-first search for all distinct routes between the relevant end nodes, with an
arbitrarily high initial hop limit, for instance 3/4 of all the nodes in the network. This is
typically a large file, written to disk as a temporary working file
3
. The routes in this
complete list are then sorted by increasing mileage. The required number of routes for the
formulation are then taken from the top of the sorted list, and the highest hop limit
amongst these routes is recorded. The temporary file for that O-D pair or span failure
scenario is then deleted and the process repeated for the next failure or working O-D pair.
In the case of joint span-restorable designs, the eligible route policy for the result is then
denoted by the minimum numbers of eligible routes found this way. N1, is the number of
distinct eligible working routes consider for each O-D pair, and N2 is the number of
distinct eligible restoration routes considered for each failure scenario.
The above is a practical and effective procedure for formulating the optimization problem
with minimum time spent in source-code development, but it is acknowledged that the
formulations are solved to optimality with respect to the set of generated routes. Only by
implicitly or explicitly considering all possible routes can we strictly claim absolute
optimality of the solution. Advanced optimization techniques such as column generation
embedded within branch-and-bound could be developed in future to solve the
formulation exactly without the need to generate all of the candidate paths. This is an area
of suggested further research.

3
Writing the routes to a temporary file before sorting and selecting is a practical albeit brute-force way of achieving the
desired end with relatively little time spent programming (i.e., elapsed project time as opposed to computing
efficiency). A more elegant approach for production use would be to keep a distance-sorted linked list during the depth
first search
14
Path-restorable Design
The path restorable design formulation described here is one in which working paths are
first shortest-path routed (independent of the spare capacity design problem i.e., it is a
non-joint design), and stub-release is assumed.
m
C
j
Parameters and variables path-restorable capacity design
(in the master formulation)*
r
x
i
, r q
g
D
, r q
j
S
m
n
j
r
d
j
w
0
,
s
i j
, p r
f
i
,
,
r p
i
j
j
s
r
i
P
r
Q
* some variables become pre-computable parameters in the variations that follow
Input data
Intermediate (internal)
variables
Design output variables
Cost of m
th
module
size on span j.
Set of all point to point
demand quantities, indexed
by r
amount of demand on
relation r
Set of all spans between
mesh cross-connection points
Set of eligible working
routes for relation r
Encodes routes in
= 1 if span j is in q
th
route
for relation r
r
Q
Set of eligible restoration
routes for relation r
upon failure i.
= 1 if span j is in p
th
route
for relation r upon failure i
Stub release
quantity on span j
from failure i
Amount of demand lost
on relation r for
failure i
No. of operating
working and spare
links (channels)
on span j
No. of modules of
type m to install
on span j for min cost
m
Z
Capacity of m
th

module size
Working and
restoration
routing
solutions
m m
j j
m j
Minimize C n

M S
Cost of modules of all sizes placed on all spans
Master formulation for path-restorable capacity design
S. t.
; i r S D
, , r q r q
i
q
r
g x
i
r
Q
Defines the amount of damaged working flow
for each relation under each failure scenario
,
r
r q r
q
g d
Q
r D
, , r q r q
j j
r q
g w

r
D Q
j S
All demands must be routed
Working capacity on spans must be adequate
(1)
(2)
(3)
Master formulation for path-restorable capacity design (2)
, , ,
0
,
0
r q r q r q
j
i
r q
g
s
i j

' ;

r
D Q
With stub release
Without stub release
2
( , ) i j
i j

S
r
P
,
p
i
p r r
f x
i i
; i r S D
0
r
P
, ,
, ,
p r
i
r p r p
f s s
j i i i j
j

D
Restorability of working flows for each relation
Spare capacity on spans must be adequate
(see note on stub release)
+
M
m
m m
j j j
Z n w s
1
j S Modularity of installed capacity
(4)
(5)
(6)
(7)
As presented, this is a universal or master formulation that allows for (i) modularity, (ii)
joint optimization of working path routing, (iii) stub release or non-stub release.
The master formulation requires as inputs:
16
(a) point-to-point demand matrix (or list)
(b) set of eligible distinct working routes for every (O-D) pair, r
(c) set of eligible distinct restoration routes for every (O-D) pair, r
for each failure scenario i .
It solves for:
(a) the amount of working flow on each working route for each O-D pair
(working flows may be split over several routes)
(b) the working, spare, (and module) capacity totals on each span
(c) the composite restoration path-set for all affected demands in each
failure scenario
One may represent specific problems variants as follows:
(a) If an integer but non-modular capacity design is desired, change the
objective function to cost-weighted sum of spares (and / or working, if
joint) and drop the set M, and the related module number variables and
Constraint (7).
(b) If a non-joint design is desired, drop (1), (2), (3), (6) and pre-compute
all of the x
i
r
damage coefficients (from the known routings) as
constants. Also pre-compute all the stub-release spare capacity
quantities according to (6).
(c) If stub-release is not desired: drop (6) and set all stub release spare
capacity return values to zero.
A note on Joint path-restorable networks: In a prior study of six different test
networks it was found that while the aspect of joint design was in all cases quite
significant ( 15 to 28%) in reducing total capacity for the span-restorable designs, it was
very much more marginal in the difference it made in the path-restorable designs (only a
few percent improvement relative to the corresponding non-joint cases).
# AMPL Model for non-joint path-restorable design with stub release
set SPANS;
set DEMAND_PAIRS;
# Set of all non-zero demand pairs as read in from dat file
param span{SPANS} symbolic;
# whereas the SET SPANS is an indexing of spans that exist, span[j]
# is the actual NAME of the jth span in the set.
param Cost{j in SPANS};
# DESCRIPTION OF WORKING DEMANDS AND THEIR NORMAL ROUTING
param DemUnits{r in DEMAND_PAIRS} default 0;
# Number of demand units between node pair r.
set WORK_ROUTES{r in DEMAND_PAIRS};
set WORK_ROUTE_VECTORS{r in DEMAND_PAIRS, p in WORK_ROUTES[r]} within {j in
SPANS};
param Work_Route_Vectors{r in DEMAND_PAIRS, p in WORK_ROUTES[r], j in
WORK_ROUTE_VECTORS[r,p]} symbolic;
# N.B. Everywhere in this model a route is specified as a sequence
# of the names of spans that comprise the route. This is a more
# compact form that replaces the prior encoding of routes by 1 / 0
# representation of span membership in a routes for every span of
# the network
18
set DEMANDS_AFFECTED{i in SPANS}
:= {r in DEMAND_PAIRS : exists {p in WORK_ROUTES[r], j in WORK_ROUTE_VECTORS[r,p]}
Work_Route_Vectors[r,p,j] = span[i] };
# This builds a set of the demand pairs that are damaged by each possible span
failure i
param Stub_release {i in SPANS, j in SPANS: span[i] <> span[j]}
:= sum {r in DEMANDS_AFFECTED[i]: exists {p in WORK_ROUTES[r], k in
WORK_ROUTE_VECTORS[r,p]} Work_Route_Vectors[r,p,k] = span[j] } DemUnits[r] ;
# Stub_release[i,j] is the amount of surviving working capacity on
# span[j] that is in a stub of a working route severed
# by failure of span [i]
# ELIGIBLE ROUTES FOR PATH-LEVEL RESTORATION OF O-D PAIRS
set REST_ROUTES{r in DEMAND_PAIRS};
set REST_ROUTE_VECTORS{r in DEMAND_PAIRS, p in REST_ROUTES[r]} within {j in SPANS};
param Rest_Route_Vectors{r in DEMAND_PAIRS, p in REST_ROUTES[r], j in
REST_ROUTE_VECTORS[r,p]} symbolic;
# There is one set of restoration routes, indexed within each set
# by dummy variable p, for each r. (r,p) is subsequently
# used directly as a tuple so that AMPL will index over only the
# (r, p) combinations actually presented in the data file.
# The DAT file will present params Rest_routes[r,p,j] which will be
# for each relation r, a set of horizontal lists
# numbered locally by p, each list being a vector of span names
# that are included in the pth eligible route for relation r.
# VARIABLES
var rest_flow {i in SPANS, r in DEMAND_PAIRS, p in REST_ROUTES[r]} >=0, <=10000;
# There is one restoration flow assignment variable for each REST_ROUTES
# with regard to each possible failure scenario (i in SPANS)
var spare{j in SPANS} >=0, <=10000 integer;
# Total number of spare links placed on span j.
# OBJECTIVE FUNCTION
minimize cost_of_mesh_sparing: sum{j in SPANS} spare[j]* Cost[j];
# for each span failure i, all demand pairs affected by the cut must be restorable
# through restoration flow assignments to eligible routes for those relations,
# such routes not containing the failure span i themselves ...
subject to path_restorability {i in SPANS, r in DEMANDS_AFFECTED[i]}:
sum{p in REST_ROUTES[r]: forall {j in REST_ROUTE_VECTORS[r,p]}
Rest_Route_Vectors[r,p,j] <> span[i]} rest_flow[i,r,p] = DemUnits[r];
# and all flow patterns must be feasible under the spare capacity assignment .
subject to spare_capacity {i in SPANS, j in SPANS: span[i] <> span[j]}:
spare[j] >= sum {r in DEMANDS_AFFECTED[i], p in REST_ROUTES[r]: exists {k in
REST_ROUTE_VECTORS[r,p]} Rest_Route_Vectors[r,p,k] = span[j]} rest_flow[i,r,p] -
Stub_release[i,j];
# END
Note that in both of the AMPL models presented above, an essentially arbitrary upper
bound of 10000 (links) is used on the spare capacity variables to ensure the bounds were
not active in the solution. In future one might be able to improve the solution times with
tactics to tighten these initial bounds. One suggestion would be to start with a set of
bounds that are generated by application of a simple "max-latching" heuristic such as
described in [13] (for the case of span restorable design). Max-latching always produces a
feasible but over-capacitated reserve network, which may be suitable for use as a set of
upper bounds span spare capacities in the AMPL models.
Stub release: Figure 10 illustrates how the surviving stub segments of the failed paths
are detected for generation of the
0
s
ij
stub release quantities in the above formulation. In
the non-joint case these can be handled as a set of computed parameters, as shown in the
AMPL model above. In the jointly optimized case the stub release quantities and all the
associated working path routing indicators become additional variables in the problem.
How the stub-release quantities are detected / generated
O
D
Relation r
Route q
Failure span i
Other span j
Working flow g
r,q
,
1
r q
j

,
1
r q
i

Span j enjoys a stub release credit
of spare capacity = g
r,q
for any failure
on span i such that:
, ,
( 1) ( 1)
r q r q
j i
true
I
Figure 10: How stub release following failure generates free spare capacity to include in
the restoration problem.
20
References
[1] Telecommunication Network Planning, B.Sanso, P. Soriano (editors), Kluwer
Academic Publishers, 1999, pp. 169-200.
[2] D.A. Dunn, W.D. Grover, M.H. MacGregor, A comparison of k-shortest paths and
maximum flow methods for network facility restoration, IEEE Journal on Selected
Areas in Communications, Jan. 1994, vol. 12, no. 1, pp. 88-99.
[3] R.R. Iraschko, W.D. Grover, A Highly Efficient Path-Restoration Protocol for
Management of Optical Network Transport Integrity, IEEE Journal on Selected Areas in
Communications, vol.18, no.5, May 2000, pp. 779-794.
[4] M. Herzberg and S. J. Bye, "An Optimal Spare-Capacity Assignment Model for
Survivable Networks with Hop Limits", IEEE GLOBECOM '94, 1994.
[6] R. R. Iraschko, M. H. MacGregor, W. D. Grover, "Optimal Capacity Placement for
Path Restoration in STM or ATM Mesh-Survivable Networks", IEEE/ACM Transactions
on Networking, Vol. 6, No. 3, pp. 325-336, June 1998.
[11] M.H. MacGregor, W.D. Grover, Optimized k-shortest paths algorithm for facility
restoration, Software - Practice & Experience, Vol. 24(9), Wiley & Sons, Sept. 1994,
pp.823-834.
[12] W.D. Grover, Self-organizing Broad-band Transport Networks, Proceedings of
the IEEE: Special Issue on Communications in the 21st Century, vol. 85, no.10, October
1997, pp. 1582-1611.
[13] W.D. Grover, V. Rawat, M. MacGregor, A Fast Heuristic Principle for Spare
Capacity Placement in Mesh-Restorable SONET / SDH Transport Networks,
Electronics Letters, vol.33, no.3, Jan. 30, 1997, pp.195-196.
Appendix A:
The joint span-restorable mesh design
process
22
Overview of the files and programs involved
Netname.snf
Netname.ptp
Netname.cst
JointSpanDATprep
Netname.dat
Netname.
hpd
.hpd
d
Netname.hpr
AMPL
Netname.MPS
CPLEX
Figure A1: Relationships of files and programs for a jointly optimized mesh capacity
design
Format and Function of SNF, PTP, and CST input files
Format of Standard Network Interface File (SNF)
Example:
Date: 1 July 2001
File Name: TopoTrial2.snf
Network: Netname
Program: This SNF file was created by hand as an input file for
JointSpanDATprep
Node Xcoord Ycoord
1 42.6525 73.76
2 33.7489 84.38
3 30.2669 97.742
4 39.2903 76.61
5 42.3583 71.06
6 42.8864 78.87
7 35.2269 80.84
.... (etc)
50 40.7608 111.9
51 38.6272 90.2
52 41.0533 73.54
53 36.3361 102.07
54 27.9472 82.46
55 42.45 80.02
56 39.7458 75.54
Span NodeA NodeB Distance Working Spare
1 21 44 490 0 0
2 44 31 112 0 0
3 31 47 11 0 0
4 47 48 54 0 0
5 48 21 481 0 0
6 49 50 1205 0 0
7 49 39 200 0 0
8 39 44 667 0 0
9 21 22 406 0 0
10 22 50 500 0 0
11 13 50 653 0 0
..... (etc)
53 26 1 225 0 0
54 1 5 206 0 0
55 5 41 47 0 0
56 41 16 72 0 0
57 16 52 79 0 0
58 52 30 48 0 0
59 30 29 11 0 0
60 29 40 40 0 0
61 40 36 50 0 0
62 36 56 28 0 0
63 56 4 74 0 0
64 4 12 39 0 0
66 30 12 322 0 0
Format of Point-to-Point Demand File (PTP)
171
0 1 2 2
1 1 3 2
2 1 4 1
3 1 5 3
4 1 6 2
5 1 7 1
6 1 8 1
7 1 9 1
8 1 10 2
9 1 11 2
10 1 12 3
.... etc
164 15 19 1
165 16 17 12
166 16 18 15
167 16 19 7
24
168 17 18 11
169 17 19 12
170 18 19 9
Format of Span Cost File (CST)
span unitcost fixedcost
1 490 0
2 112 0
3 11 0
4 54 0
5 481 0
6 1205 0
7 200 0
8 667 0
9 406 0
10 500 0
11 653 0
12 33 0
13 93 0
14 360 0
15 942 0
16 364 0
17 573 0
18 207 0
19 291 0
20 256 0
....
55 47 0
56 72 0
57 79 0
58 48 0
59 11 0
60 40 0
61 50 0
62 28 0
63 74 0
64 39 0
Generating the AMPL DAT file for the problem
The usage of program JointSpanDATprep is:
JointSpanDATprep <path>NetName MinWRoute MinRRoute
where : "NetName" is the project name of the network for which the span-restorable
design is being generated. MinWRoute is the minimum number of eligible working
routes to be generated for each demand pair . MinRRoute is the minimum number of
eligible restoration routes to be generated for each span failure. Default values are 10 and
20, respectively.
Program JointSpanDATprep automatically uses NetName to identify and open its
corresponding input files: NetName.snf, NetName.ptp, and NetName.cst which should be
prepared the respective file formats documented elsewhere in this Appendix. The
NetName.* files may be placed in the same directory as the instance of program
JointSpanDATprep.exe that is being run, in which case no <path> specification has to be
given. More generally the NetName.* files can be in any directory as long as the path is
given in the command line, as in the example below.
Program JointSpanDATprep also uses the keyword NetName to create output files
NetName.dat, NetName.hpr, and NetName.hpd. NetName.dat is the main output- the AMPL
DAT file to go with AMPL model file JointSpanMesh.mod. Ancillary output files
NetName.hpr and NetName.hpd document the restoration route hop-limits used for each span
failure and the working route hop-limits used for each demand pair, as required to
satisfy the MinRRoute and MinWRoute specifications when calling JointSpanDATprep.
Example:
If compiled as an executable for Windows or NT you could use the following command
line:
JointSpanDATprep.exe C:\directory\subdirectory\Netname 5 15
where files Netname.snf, Netname.ptp, and Netname.cst are present in
C:\directory\subdirectory\). The program will then create the appropriate output
files in the same directory. If you don't enter any path then it will perform all of its
operations in whatever directory JointSpanDATprep.exe resides.

How To Design Mesh-Restorable Networks V1

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

How To Design Mesh-Restorable Networks V1

Enviado por

Direitos autorais:

Formatos disponíveis

.

Você também pode gostar