Tải bản đầy đủ - 0 (trang)
Chapter 5. Span-Restorable and Span-Protected Mesh Networks

Chapter 5. Span-Restorable and Span-Protected Mesh Networks

Tải bản đầy đủ - 0trang

This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks



[ Team LiB ]



5.1 Updating the View of Span Restoration

Distributed automatic ("Self-Healing") span restoration was first proposed in 1987 [Grov87] [Grov89]. Study of the corresponding spare

capacity design problems began about 1990 [SaNi90] [GrBi91]. As such, most prior work on span-restorable networks was conducted in

the context of SONET technology. But it has direct logical applicability to DWDM "optical networking." Differences in terminology are

superficial to what is a basic concept, applicable to any technology era. Some important paradigms have changed, notably the view of

static forecasts versus dynamic demand, the adoption of IP-centric control protocols, and the greater transparency of lightpaths relative

to SONET SPEs. Wavelength conversion is so-far also more technically difficult and costly than time slot interchange. But

span-restorable networking itself is a generic logical approach to the restoration problem and is not tied to any one technology. The

concept is just as relevant to DWDM-based networks as it was to SONET.

One of our aims in this chapter will thus be to update the thinking about span-restoration, lifting it from its apparent SONET-era stigma

and showing in many ways how remarkably well suited and advantageous it can be for dynamic optical networks as well. This entire

approach and each of the following concepts stands in sharp contrast to the much more software and database dependent IETF-driven

view of end-to-end disjoint path protection, which has been almost the sole approach considered for optical networking. Thus, in the spirit

of at least providing some fresh alternatives for the industry to consider, we will show in this chapter (and in part of Chapter 8):

1.



How span restoration can be almost ideally suited to dynamic demand environments with the Protected Working Capacity

Envelope concept.



2.



How all of the channel-associated signaling needed for statelet-driven self-organized distributed restoration algorithms

(DRAs), previously based on SONET overheads, are now also available in optical networking with advances such as Digital

Wrapper or Optical Service Channels and the Link Management Protocol.



3.



How the Distributed Preplanning (DPP) concept updates span restoration methods to provide preplanned protection, not just

on-demand restoration, options.



4.



How the first-failure protection, second-failure restoration concept makes possible priority services classes having "better than

1+1 availability" through dual-failure restorability using a DRA both for preplanning and adaptively on demand for dual

failures.



5.



How gracefully span-restoration lends itself to an operating of multiple Quality of Protection service classes.



[ Team LiB ]



.



This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks



[ Team LiB ]



5.2 Operational Concepts for Span Restoration

Before proceeding to the capacity design aspects of span-restorable networks, this section covers several of the important operational

concepts surrounding span-restoration. This is required to ensure a correct basic understanding of the functional model that underlies the

later capacity design methods. It also helps motivate why we should consider span restoration as an option, through the "updating" of

relevance to optical networks. These preliminaries will show that span restoration offers some rather overlooked but advantageous

properties and options for a network operator.



5.2.1 Details of the Span Restoration (SR) Concept

Let us start by simply looking at an example of span restoration as shown in Figure 5-1. In (a) and (b) the figure portrays two different span

failure scenarios and shows examples of the restoration routesets that might be deployed to recover from these failures. In Figure 5-1(c) a

check mark identifies each span on which spare capacity sharing occurred over the two failures in the example. With reference toFigure

5-1, the following points help further convey the key ideas of span restoration:

1.



For capacity-planning purposes the span cut is assumed to completely sever all the working and spare capacity on the failure

span. Operationally, however, if not all working channels fail, only the failed channels will be rerouted.



2.



In the special case of a single channel failure, the restoration process will act like a 1:1 APS, finding and immediately using a

surviving spare channel on the same span as the failed channel. The same applies for multiple independent channel failures

until there are no remaining spares on the direct span. Any further failed channels are rerouted through the network just as

they would be under restoration against an entire cable cut.



3.



The set of individual restoration paths shown in Figure 5-1(a), (b) are each collectively referred to as the restoration "path-set"

for the respective failure. The set of routes over which the path-set is implemented is called the restoration "route-set."



4.



The restoration path-set is formed entirely within the multigraph whose links represent the spare channels on surviving network

spans. The working capacity layer determines the number of paths needed for restoration (i.e., wi if span i fails) but the

restoration path-set is formed entirely within the spare capacity multigraph only. wi denotes the number of working channels to

be protected on span i of the network.



5.



The multigraph representing the number and topology of all spare channels in the networks is sometimes also called the

"reserve network."



6.



The two nodes adjacent to the failed span are together referred to as the "custodial nodes" with respect to the particular span

failure.



7.



Restoration paths are formed from individual cross-connections between discrete spare channels on each span.



8.



The restoration path-set is not limited to employing a single replacement route for all failed capacity. It may, as needed,

comprise paths on all distinct routes (up to a prescribed hop or distance limit).



9.



The theoretically ideal performance model for a span restoration mechanism is that (in the absence of a limit on the wi

requirement) it should be capable of deploying a path-set that is equivalent in total flow to the max-flow capacity of the reserve

network between the custodial nodes without using any capacity on the direct span. i.e., restoration flow(span x-y) = min(wx-y ,

max-flowx-y (G)) where x,y are the custodial nodes in reserve networkG.



Figure 5-1. A visual appreciation of span restoration, and how spare capacity is shared.



This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks



Point 8 touches on an apparently common misunderstanding about span restoration—that restoration is via a single simple deflection of

the total flow from the failed span. Diagrams similar to Figure 5-2(a) all too often seem to portray span restoration this way, but are

fundamentally misleading as they fail to convey the far greater generality of rerouting that is part of the concept. As Figure 5-1 or Figure

5-2(b) illustrates, the general concept is to allow the most diverse path-set formation that may be needed to efficiently use the spare

capacities available on other spans. This means rerouting at the granularity level of capacity management at the associated cross-connect

nodes. The failure may sever multiple fibers, but the restoration path-set can be constructed at the fiber, waveband, wavelength channel,

or even OC-n level, depending on implementation. The general concept also allows that restoration paths may be of any length required

up to some logical or physical length limit, H. The case shown in Figure 5-2(a) is in fact only the limiting case of H=2 with "full bundling."

The H=2 fully bundled model is the least efficient for sharing of spare capacity over different failure scenarios—often only two or three

span failures will be able to share the spare capacity on a span. (For example, reconsider the failures of Figure 5-1(a) and (b) if only a

single two-hop reroute is allowed). Spare capacity levels are also higher with full bundling because a single restoration route must have all

of the spare capacity to handle the failure rather than allowing the spare capacity of many routes to be employed. Having stressed these

basic points, practical implementations can involve limitations on hop-limits so that realistic restoration path-sets would typically not be as

complex as the "concept" example in Figure 5-2(b). Similarly, partial bundling can enhance speed by reducing signaling volumes with little

or no loss in overall capacity efficiency. The main point is, however, is to completely dispel the commonly encountered view of span

restoration implying what Figure 5-2(a) portrays as the restoration principle.



Figure 5-2. A common but misleading portrayal of the span restoration concept is the special

case of H=2 with full bundling in (a). Unbundled multi-hop restoration in (b) is more efficient.



This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register

. it. Thanks



5.2.2 Concept of Distributed Self-Healing Mesh Restoration and DRAs

Span-restorable networks lend themselves well to the application of a distributed restoration algorithm (DRA) that operates with

state-driven signaling interaction on the overhead bytes of each lightwave channel, or through signaling on the OSC for all channels in the

associated fiber. DRAs differ remarkably in implementation and performance from explicit message-passing distributed protocols in the IP

control plane, such as OSPF-TE or CR-LDP. None of the current IP-centric control applications are really "distributed" protocols because

they rely on having a current and complete global database view of the network state in every node. Each node is really solving an

instance of the centralized computational version of the respective routing problem at hand. In contrast DRAs have no database and form

restoration path-sets through a truly distributed self-organizing event-driven interaction of state-based signaling bytes on spare channels.

The physical state of the network is the database within which they execute.

The differences are essentially the same as comparing OSPF-TE/CR-LDP which is a software and database intensive high-level protocol

suite to the SONET K1-K2 state-driven byte-signaling protocol for automatic protection switching (Section 3.4.2). It may be difficult to think

of these as being comparable but they are in the sense that they both solve a restoration rerouting problem. OSPF-TE coupled with

CR-LDP is representative of IP-centric control protocols which have tens of thousands of lines of source code and rely on accurate global

state databases. In contrast the K1-K2 byte protocol can be implemented in a few hundred logic gates, including the trivial finite-state

machine (FSM) "program" that controls APS switching. How does this relate to DRAs? DRAs are the mesh rerouting equivalent of the

simple K1-K2 byte-driven APS protocol. They effect span-restorable path-set formation with FSM-driven node protocols that can be

implemented in firmware, not greatly more complex than the K1-K2 state-driven APS protocol. First developed in the 1990s for SONET,

this approach has been largely overlooked for optical networking applications, which have been rather captive to the software and

database intensive IP-centric approach.

Distributed restoration effects a much more primitive, lower-level, autonomous and collective response to a failure. This gives it speed and

database independence well beyond that achievable through high-level packet messaging protocols. The network state as it exists at the

moment of failure is the database, not a centralized software abstraction of the global network. This lets us realize the rerouting

computation for restoration without any database requirements. Every node will perform in an apparently isolated manner, but the

independently deduced cross-connection decisions of each node collectively constitute efficient multipath rerouting plans.

A DRA does not replace centralized supervisory control over the network. Rather, the DRA is an embedded real-time assistant to

centralized administrative systems. Network elements will react autonomously to the emergency, coordinating themselves under the DRA,

but they then use normal IP messaging to a network operation center (NOC) for ratification of restoration actions, and for all other normal

provisioning and maintenance purposes. All DRAs use some version of forward flooding (or selective forward flooding) and reverse linking

as introduced in [Grov87] [Grov89] (for span restoration DRAs), and employed again for a path-restoration DRA inIrGr00]

[

. The flooding is

not, however, a simple repeat broadcast as in LSA dissemination. It is also state-based not message-based. The flooding in a DRA which

obtains all paths of the restoration path-set in parallel, such as the Self-Healing Network (SHN) protocol, is controlled by a compact set of

[1]

nodal rules which determine which incoming restoration state bytes (or "statelets") are relayed.

[1]



The SHN protocol was first proposed in G

[ rov87] but an improved description, in [Grov97], is recommended for

readers interested in seeing how it works. Many still tend to think that what the SHN achieves is impossible without

preplanned databases or global topology-discovery techniques. The SHN spontaneously assembles restoration

path-sets as a low-level self-organizing interaction amongst nodes with no global database or topology knowledge.

[Grov97] gives a better explanation of how this works than the earlierGrov87].

[



5.2.3 Self-Organizing Nodal Interaction via Statelets

In the SHN Protocol [Grov89] and related protocols employing this form of simple state-driven signalingIrGr00]

[

, [StGr98] ,[GrSt98], nodes

interact solely through statelets on the channels (or channel bundles) between them. A statelet is not an inter-processor data message in

the usual sense—rather it is a channel-associated overhead state byte much more like the K1-K2 bytes in SONET than, say, like an OSPF

data packet. In fact, one can say that the K1-K2 bytes in SONET are the statelets for the SONET APS protocol. One study by Bellcore

[Bell93] tested a variety of DRA proposals for SONET and concluded that signaling of this type, rather than DCC-channel based

messaging, was probably essential to meet the 2-second speed of restoration target at the time. Related work and conclusions are also

reported in [WuKo93]. DRAs based on statelet-type signaling are just extensions of the SONET APS protocol to distributed mesh

restoration. Statelets are invisible to traffic on the link but are physically inseparable from the transmission signal itself. Statelets are



This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks

comprised of fixed information fields, some of which are specific to the application that the basic protocol is used for. A statelet is not

addressed as a message is; it arrives at whatever node and in whichever port the transport signal is connected. Similarly a node

originating a statelet on a link does not explicitly know who will be influenced by its direct or indirect effects.

SHN nodes do not rely on a data communication link between node processors to coordinate their restoration efforts. Rather, the SHN

task sees the outside world only through the statelets appearing locally on the links incident to it. Nodes are effectively isolated and act

solely as a specialized processor of statelets. The self-healing effect occurs as the network-level side effect of the apparently isolated

actions of each node following a set of rules for reaction to and creation of statelets. The action of nodes, particularly of the nodes not

directly adjacent to the failure but involved with cross-connecting spare channels to form restoration paths (called Tandem nodes), appear

more like the conduct of a card game than any explicit algorithmic attack on the rerouting problem at hand. This game is defined by rules

for operation on statelets and by a goal of seeking certain combinations of statelets among several families of statelets that will be present.

A condition of matched statelets authorizes a node (a player)—in total unawareness of the actions at any other node—to make a

cross-connection. The independently derived cross-connection decisions at each node will collectively form coherent restoration path-sets.

This clearly different approach to restoration addresses the demanding requirements of restoration in terms of speed and accuracy (in the

sense of never acting with out-of-date information on network configuration). Speed arises from the properties of event-driven processing

of statelets rather than software handling of queued messages. Statelets are semi-static information fields repeatedly impressed on the

bearing signal in hardware. As a result the entire network state information needed for restoration is stored on the links of the network

itself. Nodes sit within this database viewing only the part of it that is adjacent to them. Changes in statelets are detected in hardware in the

port cards of the OXC nodes, allowing parallel evolution of the collective state of all network links to proceed with little more than the

statelet repetition and propagation delays. No inter-processor communication stacks are involved. A change in a statelet is trapped in

hardware and raises a flag for service. To the Operating System (OS) of host OXC the SHN task looks simply like a specialized interrupt

handler for handling statelet change events.

The SHN protocol thus executes within a memory space which is comprised of the array of incoming and outgoing port card statelet

registers and neighbor nodes are directly coupled in a shared-memory sense. When a node creates or changes a statelet, the memory

state within the adjacent node is directly updated. The effects of protocol execution at one node are automatically reflected in the memory

state within which adjacent nodes are concurrently executing. This couples all nodes as a system but eliminates the real-time burden and

delays of serial inter-processor messaging and protocol stacks with error recovery, message ordering, and queuing if conventional packet

messaging was used between nodes. Figure 5-3 illustrates this logical model of nodes coupled through the shared memory which are the

links of the network itself with state information in their statelets. The spatial position of links on which various statelets exist also encodes

information relevant to the process.



Figure 5-3. Shared memory execution paradigm of the SHN protocol for adaptive real-time

restoration or prefailure distributed preplanning.



In addition, the protocol action is always defined by the current state of links surrounding the node, not by previous messaging histories, so

statelet change events in a port need not be queued. It is only the current state of the link when the SHN task considers it that matters to

the network wide evolution of the result. There is no receive message buffering: a new statelet overwrites, rather than follows, any



.



This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register

.

it. Thanks

previous statelet. It is important to see that each change in a statelet is not a packet data message to be processed in the usual sense.

Statelet-driven interaction can also be made almost arbitrarily robust to errors without retransmission needed in ordinary packet

messaging protocols. Simple triplication testing is a highly effective form of error correction in an environment of fiber transmission where

-6

10 BER is already considered an alarm condition. But a checksum can also be embedded in the statelet to absolutely validate it. A 64-bit

statelet including a checksum can be subjected to three-times persistence validation in the receiving port to virtually eliminating a false

statelet event and requiring only 3 ms to propagate an event over a single 64 kb/s statelet overhead channel.



Other DRAs and Common Misunderstandings

Local interaction via statelets leading to emergent parallel formation of complete and efficient sets of restoration paths is a unique feature

of the SHN protocol above. Other DRAs have been developed and characterized that use more conventional inter-processor messaging

and explicit route-seeking algorithmic approaches. Examples include FITNESS [YaHa88], NETRATS [SaNi90] and Komine's DRA

[KoCh90]. An in depth discussion of DRAs is found in G

[ rov94]. Studies reporting validation and performance assessment of DRAs include

[SaAl98], [Grov89], [KoCh90] , [ChKo91], [GrVe91], [IrGr00] . Much of the work on DRAs occurred during the SONET era and seems to

have been overlooked for optical mesh networks, although it is logically just as applicable to DWDM-based optical networking— especially

with "digital wrapper" or other forms of optical service channels to convey the physical layer channel-associated signaling that makes these

schemes so fast compared to Internet-style messaging. An important point established by the literature just cited is that distributed

restoration can be assured with 100% restorability of predefined levels of working capacity. This is relevant to the following discussion of

the "working capacity envelope concept" for dynamic demand provisioning because a DRA can be the basis of an adaptive restoration

response that, operating within a pre-designed environment of spare capacity, is assured to fully restore working capacity up to a known

maximum level on each span. These maximum working levels associated with a given spare capacity distribution define an operational

envelope for dynamic demand provisioning. But the adaptive nature of a DRA give extra advantages over protection schemes. These

points need to be stressed in light of two misunderstandings sometimes expressed in papers on optical mesh networking. These are:



Misconception 1: that only protection schemes (not restoration) can give an advance assurance of 100% recovery. While this

is true of GMPLS auto reprovisioning (as we explain in Chapters 3 and 6), DRAs for span restoration (and one for path

restoration [IrGr00]) have been well validated to reliably achieve 100% of the predefined working capacity restoration goals.

Although dynamic and adaptive, these remain assured, not best-efforts, schemes when operating within well-know limits on

working capacity.

Misconception 2: that distributed span restoration schemes don't support dynamic demand. This is also not true, but

presumably arises because many past studies employed a static demand forecast matrix for design studies. The logical

extension to apply to dynamic demand environments is, however, direct: the static demand quantities need only be

reinterpreted as traffic-based estimates of maximum requirements. The "static" capacity design then produces a pool of

protected working channels on each span, available for dynamic demand provisioning. We develop this point further as the

"working capacity envelope concept" below.



5.2.4 Distributed Protection Preplanning with a DRA

The concept of Distributed Preplanning with a DRA was mentioned in Chapter 3 where we pointed out why it is too simplified to classify all

mesh schemes as either protection or restoration. Let us now describe the concept of DPP more fully. DPP works as follows:

1.



A DRA (such as the SHN protocol) is executed sequentially in a background mode for each possible span failure or SRLG in

the network. This is a dress rehearsal in which no cross-connections are actually made. The failure scenario to simulate may

be downloaded from central control or enumerated by the network nodes in round-robin by themselves.



2.



Each node records the cross-connections that it would have made between spare channels for each trial run in which the DRA

recruited it into making one or more restoration cross-connections. The node records the custodial node name pair that

identifies the failure and the local spare capacity cross-connection map that corresponds. This results in a "DPP table" of

instructions at each node for that node's portion only of the DRA response to each respective span cut of the network.



3.

When a real span failure occurs, the custodial nodes observing the failure emit a single alerting statelet containing the span



This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks

identity and an indication equivalent to saying "span (x,y) fail: this is not a drill!" Alerting can be accomplished over an activation

loop pre-established through all nodes or by disseminating a simple flooding alert which requires one statelet event in each

node.

4.



Any alerted node that has non-null actions for a listed failure in its DPP table immediately makes the internal cross-connections

between spare ports that are listed in its table, and changes the local status of the links used from spare to "in use." With

MEMS or other optical array switch core technologies it may be possible for the whole spare capacity cross-connection map

that corresponds to the given failure to be asserted in parallel.



Figure 5-4 illustrates this relationship between a span-restorable mesh network that contains an embedded DRA for real-time restoration

and a corresponding preplanned span protection scheme supported in the same spare capacity environment. This works through

distributed preplanning of protection reactions with the same DRA that would be called upon for real-time restoration if needed. We refer to

this overall scheme, in which preplans are developed (and adapted) through a continual series of mock restoration trials, as

span-restorable distributed preplanning or SR-DPP.



Figure 5-4. Concept of Distributed Preplanning: A DRA continually runs mock failure trials and

nodes store only their actions for use as fast protection plans.



When a real failure occurs it is only necessary to disseminate the names of the end-nodes adjacent to the failure (which serves as a fault

ID). All nodes then immediately deploy their corresponding preplanned cross-connection actions in parallel. Thus, in the same sense that

an APS system is like a pre-stressed trap, ready to be sprung by a failure, the mesh network is also completely pre-wired with a collective

restoration path-set for each failure that can be triggered into existence in parallel at all nodes just by dissemination of the fault notification.

One possibility to very rapidly alert all nodes is with an activation loop, created by concatenation of some existing spare links in an

arrangement that visits all nodes. A loop ensures that the span-cut cannot itself isolate any nodes from the alerting path. In the case of two

cuts on the activation loop, or in any case where the pre-placed instructions do not yield 100% restoration, the DRA can then be triggered

in real-time as a follow up. But simple flooding is also a fast form of activation. Even with simple flooding, instead of an activation loop, all

nodes can be alerted into action to deploy the last stored self-planning result faster than they could have been by collectively executing the

DRA itself.

DPP has considerable advantages over centralized preplanning since the database remains the network itself and there are no

centralized computational or downloading of preplan files. The network operations center (NOC) has only to command (or pre-schedule)

the cycle of background trial runs that continually update the distributed preplan. The NOC may alternately command updates selectively

when network changes occur. If the DPP only protects the working paths as they are provisioned then there may be a finite "window of

vulnerability" in the preplans between the time when provisioning occurs and when the relevant updates to the DPP are effected. If one

assumes a rotation schedule which provides regular 10 second slots (which is generous) for each span to run a DRA dress rehearsal then

a 100-span network would have its DPP regenerated entirely every 17 minutes. Any new service path would be automatically integrated

into the fast protection preplans with at most this much delay.

In a more dynamic demand provisioning environment where full pre-provisioning of channel capacity is assumed (that is, all per-channel

equipment is in place on all channels of the transmission system prior to use), new service paths can be established over an already

protected "envelope" of working capacity on each span. There is literally no delay in establishing protection in this case, as the DPP



.



This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks

process is continually preplanning protection for the entire working envelope, not for individual working channels as they are provisioned.



5.2.5 The Working Capacity Envelope Concept for Dynamic Demands

Another attractive aspect of span-restorable networks is the operational simplicity of the protected working capacity envelope (WCE)

paradigm to support dynamic service provisioning. In contrast to MPLS or optical layer shared backup path provisioning, where working

and backup paths must both be determined in the provisioning process, and shared backup capacity must be coordinated with all other

paths, span-restorable networks protect the bearer capacity of the network directly. This creates an inherently-protected amount of

working capacity on every span that is a resource pool for provisioning. The set of all such protected capacities on network spans creates

an "operating envelope" within which a vast number of simultaneously provisioned path states are feasible and inherently protected without

any further consideration or even checking. Service provisioning is simplified to the equivalent of routing a new path in a previously

non-protected network of point-to-point transmission systems. "Point and click" or fully automated dynamic service path provisioning are

both greatly simplified because provisioning need focus only on the working path. As long as the path fits in the envelope, it is protected.

And fitting in the envelope only requires that at least one unit of unused working capacity is available on each span of its route. Thus, with

one envelope of working span capacities, a vast number of dynamically changing network connection states are feasible and inherently

protected against span failures. The service layer merely routes the path over a shortest route on which working capacity is available. If

multiple protection classes are desired (as follows in Section 5.9), a status indicator borne by the signal will indicate if it is in the protected

envelope on each span or uses unprotected (or best-efforts) working capacity.

Figure 5-5 illustrates the point. In (a) is a simple example of a mesh network design (obtained using the methods that follow) that is 100%

restorable to any single-span failure at 70% redundancy. The working and spare capacities on spans are indicated as (wi, si) values,

respectively, in Figure 5-5(a). Figure 5-5(b), (c) and (d) just illustrate three of the vast number of different point-to-point demand

combinations that are supported and inherently protected by routing within the protected working capacity envelope of Figure 5-5(a). Unlike

path protection there is no determination of backup routes or coordination of spare capacity on backups required to provision each

changing demand as it arrives. If it can be routed under the wi of (a), it is protected, end-to-end, by virtue of embedded span replacement

rerouting through the si quantities in (a), should a failure occur.



Figure 5-5. (a) A span-restorable mesh network and examples (b), (c), (d) of different (dynamic)

demand patterns feasible under the protected working capacity quantities of (a).



This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks



In fact, the extent of the working capacity envelope is not fully portrayed by Figure 5-5 because within the physical totals (wi + si) of

capacities present on the spans, there is yet further latitude if needed to revise the boundaries on spans between working and spare

capacity to accommodate even more deviation in a dynamic demand pattern from the pattern for which the capacities were initially

designed. Such "stretching of the envelope" is approached with the theory to follow.

In an optical network with OXC-based SR-DPP protection at the lightwave channel, waveband, or whole-fiber level, this means that

rerouting for survivability is completely transparent to the payload types on each wavelength and there are no explicit provisioning

operations required in the service layer to provide for survivability. The service layer merely routes over a shortest path through the

available working capacity quantities, designates the protection priority or class, and receives a confirmation that the path is protected

when routed within the current envelope of protected working span capacities. In contrast to SBPP, where explicit arrangements for

protection are referred into the service provisioning problem for every path and a large amount of global network state is needed to

coordinate sharing on backup paths, span restoration offers a simpler operational service provisioning paradigm: that of provisioning over

protected capacity versus explicitly provisioning for protection.

Another important aspect of the working capacity envelope (WCE) concept is that it relates the mathematical models for capacity planning

(i.e., most of what follows in this chapter) for "static demand" matrices to the emerging view of highly dynamic demand arrival and

departure processes under fully pre-provisioned inventories of channel capacity. Under the WCE view of dynamic operations, the static

"demand matrix" which we specify for a capacity design problem is simply reinterpreted as the generating exemplar that dimensions the

working capacity envelope within which we want to serve dynamic demand. In this role a demand matrix no longer expresses the planner's

forecast of exactly which future demands he/she expects to support, but rather his/her view of either:

1.



The most demand expected to have to be supported on each O-D pair simultaneously, or,



2.



In an analogy to traffic engineering, the number of lightpath "trunks" needed to serve the average instantaneous demand on

each O-D pair at a target blocking level.



Regarding the second scenario, it is relevant to note that while blocking probability P(B) is quite nonlinear as a function of offered traffic(A)

for a fixed number of servers (N), it is easily shown that under Erlang B the number of "servers" required (here lightpath requirements) to

retain a low constant blocking probability is essentially linear above a few Erlangs. For example: N = 5.5 +1.17 A is accurate within +/- 1

server for P(B)<0.01 from 5 < A < 50 Erlangs. Similarly N = 7.8 +1.28 A approximates P(B)=0.001 engineering within +/- 1 server over the

same range. The relevance is that design methods developed to solve apparently "static demand" problems also apply directly to the

dynamic demand environment, through traffic theory. Simulation studies are not needed to generate the capacity requirements. If one

knows the mean traffic intensities (A) that the simulation would have used, these values can be used directly in the equations given to

generate the lightpath number requirements for the target blocking levels. Moreover, because N for a constant P(B) is nearly linear with A,

the individual O-D pair path requirements can be added on spans that are common to the routes taken for various O-D pairs, thus

generating the wi quantities used for the subsequent span-restorable envelope protection design.

In either case above, a process of shortest path mapping of these requirements onto the network graph generates a family of working

capacity requirements on each span. This is in effect sizing the envelope: it fleshes out the number of wavelength channels to

pre-provision for working services on each span. A separately solved spare capacity allocation problem (to follow) can then stipulate the

additional required number of spare channels to pre-provision so that the entire network envelope of working capacities is protected,

regardless of the actual pattern of dynamic demand connections being supported at any time.

Figure 5-6 illustrates the overall relationships. The main horizontal lines divide the space into planning, protection, and real-time service

provisioning activities or operations. In planning there are four possible avenues or planning paths that lead to generation of the working

capacity requirements on each span:

1.



A forecast is made of the average lightpath demand (simultaneously required lightpath connections) on each O-D pair in

Erlangs. Actual traffic is understood to be random in time, but characterized by these mean traffic intensities.



2.



A specification of the simultaneous peak connection numbers required between all O-D pairs is given. Again traffic is

understood to be random in time, but this characterizes the worst-case simultaneous peak connection loads that it is desired to

support.



3.



A forecast of exact static demand requirements expected between each O-D pair.



4.



No forecast of demand is given or used. The amount of provisioned working capacity on each span is specified directly, based

on availability or investment considerations and simply represents an inventory of installed capacity with which to provide

services.



Figure 5-6. How static planning models support dynamic provisioning: dimensioning the



This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register

. it. Thanks



protected working capacity envelope that supports simplified dynamic path provisioning.



Point 3 is what is referred to as the traditional "static" planning model, which is useful for many study contexts, but does not directly

consider the dynamic nature of demand patterns expected in future. Points 1 and 2 are both better descriptions of a dynamic demand

environment. And yet in a sense, they are just as static as 1, when the random models used are characterized by their mean or peak

intensities, which are assumed to be known. In fact, many studies using simulation methods to model various aspects of network

performance under dynamic demand are logically no more models of an uncertain future demand than the completely static forecasts

because the assumption of known mean traffic intensities per node pair is as predictive as a static demand model. Capacity planning

methods used in conjunction with static demand matrices can be just as applicable to dynamic demand contexts if we simply assign new

meaning to the demand specifications and understand that the capacity designs that result are dimensioned to provide suitably sized

envelopes for dynamic operation, rather than capacity allocations to serve only one exact demand pattern. A related point is that true

uncertainty about future demand patterns is not addressed by simulation of dynamic random demands to assumed mean traffic measures.

In the telephone network every call is a random arrival, but the forecast would be considered perfect if the mean traffic intensities on each

node pair were exactly known as in so many recent simulations of dynamic lightpath arrivals. Thus, when some researchers model

lightpath demand as Poisson processes of known mean values (or any other random models of known parameters), they are no more

addressing uncertainty about the pattern of demand when using simulations to generate required capacity than when a static demand

model is assumed for a capacity design problem. True planning uncertainty and simple randomness of arrivals are not the same thing.

In the overall concept portrayed in Figure 5-6, each of the different planning approaches leads to a specification of required working

channel quantities, wi, on each span. Whether the interpretation is a forecast of static demands, or a forecast of mean dynamic traffic

intensities, both lead ultimately to an as-built requirement that is static once placed on the ground. Once the planning of working quantities

is complete, through whatever path is taken above, we enter the protection planning domain. If the wi quantities are given, then an

optimization problem called Spare Capacity Allocation (SCA) dimensions the minimal total spare capacity that will protect all wi capacity on

each span. Usually a side-effect of this process is to also produce all the restoration rerouting plans that define the use of the spare

capacity for each planned failure scenario. This information can be downloaded to each node in a centrally controlled scheme but is not

required in a network that employs distributed preplanning.

Below the second line in Figure 5-6, the network is viewed in its operational service provisioning phase. Thewi quantities define the

resource pool or envelope that is used for dynamic service provisioning. The si quantities, protection preplans and protection mechanism

are unseen by the provisioning process, but ready if needed. The service provisioning process need not directly address protection

concerns at all within its routine of establishing and removing dynamic connection requests. The service provisioning process is using

inherently protected capacity, instead of having to explicitly provision protection for each service path it establishes.

The overall process thus dimensions and protects a working envelope of capacity within which dynamic path provisioning operates without

any further immediate concerns about survivability. The envelope itself is structurally protected by design. Regardless of the

minute-by-minute changes in the actual mix of services and composition of the bandwidth allocation in links of each span, every service

provisioned through the envelope of protected capacity is inherently also protected. With the protected working envelope concept,

protection preplans are far less dynamic than the traffic itself. Only when the envelope requirements change do the protection plans



This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register

. it. Thanks

possibly need changing. But evolution in the envelope requirements occurs only in response to evolution of the total demand pattern itself,

not "call-by-call" events. It takes a shift in the statistics of the demand pattern to require a logical change in the working envelope. And it

takes a large shift in total demand or its pattern to ultimately require additional spare capacity. But envelope changes occur on a very

different time scale than the underlying call-by-call events themselves and, importantly, exhibit correlated observable trends that can drive

appropriate ongoing planning processes.

Thus, the envelope and its protection plans are only slowly changing—or even static—over long periods of time, even in the most

frenetically dynamic network. No matter how rapidly individual lightpath demands come and go at random, the envelope requirement will

not change at all if the system is at statistical equilibrium. The envelope is only sensitive to non-stationary drift in the underlying pattern of

random arrival/departure processes. Which, thus, is truly a more "scalable" architecture for handling a dynamic demand environment? A

span-protected working capacity envelope or a scheme where every arrival requires its own individual protected arrangements,

coordinated in real-time with every other (equally dynamic) path in the network? The envelope needs to track only non-stationary drift in

the statistics, not each arrival and departure event individually. This is highly advantageous compared to the incrementally provisioned

path model under which protection preplans have to be updated following each new service path establishment. It makes a span-protected

WCE network considerably more scalable than a corresponding SBPP network in terms of growth in both network size and service

provisioning volumes handled per unit time. Under SBPP every connection establishment requires explicit consideration of a working path

and a disjoint shared-backup path arrangement based on global network topology and shareability data. Under a span-protected WCE

every connection set-up is simply a single shortest-path routing problem within available wi capacities of the protected envelope. We think

this is one of the most important advantages of span-oriented protection, but to our knowledge, the case for WCE-based dynamic

provisioning has never been argued before.

More formally, we can define the state-space of all demand patterns (instantaneous combinations of connection states) that are inherently

protected by a given working capacity envelope as follows.



G(N,S) is the network graph comprised sets of nodes N and spans S.

wi is the number of working channels on spani



S which are protected under the current distribution of spare channels on



other spans j



S|i

x' j . It is a separate problem to determinewi by any number of means depending on the protection

mechanism, the network graph, and the spare capacity distribution. Suffice it here to say that the maximum number of working

channels that can be protected by any given reserve network is computable yielding W = {wi|



i



S} which is the network's



protected working capacity envelope.

Dk is the matrix of point-to-point demand requirements in demand scenario k. There is an essentially infinite number of possible

demand scenarios.

M(G,Dk) is a process or algorithm for working path routing. It takes the graphG and maps the demand matrixDk onto routes

through graph. The output is wi,k —the number of working channels on spani employed by M() to map demands of demand

scenario k. M(G, Dk) can be invoked as a function to form the setAk = {wi,k|



i



S,



k



K}. These represent the actual



usage of working channels on span i when demand pattern k is routed over the graph by processM().



It is feasible to entirely serve demand matrix k through the current envelope W if wi,k



wi|



i



S. If this condition is true, we can say



that Dk is "inside" envelope W under routing process M()—a relationship we can denote asM(G,Dk) = Ak

W or just M (G,Dk)

W.

Then the state-space for automated provisioning is definable as the set of all demand matrices Dk that are served and protected "inside"

the working capacity envelope. That is:



Equation 5.1



By this we mean that

is the set of all possible demand matrices where every demand is served and protected within the working

capacity envelope W using a given process M() to route demands. Spare capacity does not come directly into these considerations even

though all services are protected. This is the simple beauty of the WCE concept: dynamic service provisioning has to consider only

working path routing. There are no explicit considerations about spare capacity allocation or protection path arrangements because the



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Chapter 5. Span-Restorable and Span-Protected Mesh Networks

Tải bản đầy đủ ngay(0 tr)

×