tcom 541
Download
Skip this Video
Download Presentation
TCOM 541

Loading in 2 Seconds...

play fullscreen
1 / 49

TCOM 541 - PowerPoint PPT Presentation


  • 91 Views
  • Uploaded on

TCOM 541. Session 2. Mesh Network Design. Algorithms for access are not suitable for backbone design Access designs generally are trees – sites connect to center Diverse access (redundancy) is another question, and only needed for special situations

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'TCOM 541' - neo


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
tcom 541

TCOM 541

Session 2

mesh network design
Mesh Network Design
  • Algorithms for access are not suitable for backbone design
    • Access designs generally are trees – sites connect to center
      • Diverse access (redundancy) is another question, and only needed for special situations
    • Backbone designs require many-many connectivity
mentor algorithm
MENTOR Algorithm
  • “High quality, low complexity” algorithm
  • Originally developed for time division multiplexing
    • Works with other technologies
mentor algorithm 2
MENTOR Algorithm (2)
  • Assume initially only a single link type of capacity C
  • Divide sites into backbone sites and end sites
    • Backbone sites are aggregation points
    • Several algorithms to do this
      • Threshold clustering is used
threshold clustering
Threshold Clustering
  • Weight of a site is sum of all traffic into and out of the site
  • Normalized weight of site i is

NW(i) = W(i)/C

  • Sites with NW(i) > W are made into backbone sites
    • Where W is a parameter
threshold clustering 2
Threshold Clustering (2)
  • All sites that do not meet the weight criterion and are close to a backbone site are made into end sites
    • “Close” is defined as when the link cost from the end site e to the backbone site is less than a predefined fraction of the maximum link cost MAXCOST = maxi,jcost(Ni,Nj):

cost(e,Ni) < MAXCOST*RPARM

threshold clustering 3
Threshold Clustering (3)
  • If all sites that pass the weight limit as backbone sites have been chosen and there are still edge sites “too far” from any backbone site, we assign a “merit” to each site
    • Assign coordinates to each site (e.g., V&H)
    • Compute center of gravity of sites
center of gravity cg
Center of Gravity (CG)
  • Defined as (xctr, yctr) where

xctr = SnxnWn/SWn

yctr = SnynWn/SWn

Note: These coordinates need not correspond to any actual site

distances to cg
Distances to CG
  • Define

dcn = [(xn-xctr)2 + (yn-yctr)2]0.5

maxdc = max(dcn)

maxW = max(Wn)

  • Then

meritn= 0.5(maxdc–dcn)/maxdc + 0.5(Wn/maxW)

  • That is, “merit” gives equal value to a node’s proximity to the center and to its weight
mentor algorithm 3
MENTOR Algorithm (3)
  • From among remaining nodes, choose the one with the highest merit as a backbone node
  • Continue until all nodes are either backbone nodes or within RPARM*MAXCOST of a backbone node
  • Select backbone node with smallest moment to be center
    • Moment(n) = Sdist(n,n*)Wn*
  • Construct a Prim-Dijkstra tree, parameter a
mentor example
MENTOR Example

Radius = RPARM*MAXCOST

C*G

Edge node

Backbone node

mentor example 2
MENTOR Example (2)

Radius = RPARM*MAXCOST

C*G

Edge node

Backbone node

mentor example 3
MENTOR Example (3)

Radius = RPARM*MAXCOST

C*G

Edge node

Backbone node

mentor example 4
MENTOR Example (4)

Radius = RPARM*MAXCOST

C*G

Edge node

Backbone node

mentor example 5
MENTOR Example (5)

Radius = RPARM*MAXCOST

C*G

Edge node

Backbone node

need for improvement
Need for Improvement
  • As we know, tree designs have several drawbacks, especially for large networks
    • Lack of redundancy increases probability of failure
    • Chain-like network (low a)
      • Aggregation of traffic in “central” links raises costs
      • Large average hops in large networks
    • Star-like network network (high a)
      • May have low link utilization
refining the design in mentor
Refining the Design in MENTOR
  • We introduce the concepts of sequencing and homing to add links so as to make a better design by adding direct links where the traffic justifies it
  • Use the Prim-Dijkstra tree to define a sequencing of the sites
    • A sequencing is an outside-in ordering
    • Do not sequence the pair (N1,N2) until all pairs (N1*,N2*) have been sequenced where N1 and N2 lie on the path between N1* and N2*
    • Roughly, the longest paths get sequenced first
example of sequencing
Example of Sequencing

Sequence

AE

AF

BE

BF

CE

CF

DA

DB

AC

BC

DF

F

A

C

3 hops

D

E

B

2 hops

1 hop

comments on sequences
Comments on Sequences
  • Sequences are not unique
  • Different (valid) sequences do not influence the design greatly
homing
Homing
  • For each pair of nodes (N1, N2) that are not adjacent we select a home
    • If 2 hops separate N1 and N2, the home is the node between them
    • If they are more than 2 hops apart there are multiple candidates for their home
homing 2
Homing (2)

N4

N1

N3

N2

Candidate for home (N1,N2)

Candidate for home (N1,N2)

Choose N3 as home(N1,N2) if:

Cost(N1,N3) + Cost(N3,N2) < Cost(N1,N4) + Cost(N4,N2)

Otherwise choose N4

last step
Last Step
  • Consider each node pair only once, add a link if it will carry enough traffic to justify itself
  • Consider the traffic matrix T(Ni,Nj)
    • Assume it is symmetric
    • Recall that MENTOR was developed to design TDM networks, and muxes are bi-directional (usually)
last step 2
Last Step (2)
  • For each pair (N1,N2), execute the following algorithm:
  • If capacity of a link is C, compute
  • n = ceil[T(N1,N2)/C]
  • Compute utilization
  • u = T(N1,N2)/(n*C)
  • Add link if u > umin, otherwise move traffic 1 hop through the network
  • I.e., add T(N1,N2) to both T(N1,H) and T(H,N2)
  • And do same for T(N2,N1)
  • Note – there is a special case when (N1,N2) belongs to the original tree
  • In this case just add the link (N1,N2) to the design
comments
Comments
  • The link-adding algorithm aggregates traffic to justify links between nodes that are multiple hops apart
  • If traffic between N1 and N2 cannot justify a direct link, it is routed through their home node H
  • Eventually, in large networks, enough traffic is aggregated to justify a direct link
comments 2
Comments (2)
  • Performance of MENTOR is governed by utilization parameter umin and the Prim-Dijkstra tree-building parameter a
  • How easy it is to add new links is controlled by umin
  • The shape of the initial tree is controlled by a
    • High a will build a star-like tree – then links will be added only between site pairs that have enough traffic without help from other nodes
    • Low a will build a more chain-like tree, so there will be more aggregation of traffic and likely addition of links
performance of mentor
Performance of MENTOR
  • Low-cost algorithm
    • Three main steps
      • Backbone selection
      • Tree building
      • Link addition
    • All of O(n2)
    • Possible to re-run many times, varying parameters
mentor example1
MENTOR Example

Based on mux1.inp on Cahn’s FTP site

15 sites, 60 256 kbps circuits

13

6

2

7

15

14

10

9

1

5

12

4

8

11

3

initial choice of backbone nodes 5
Initial Choice of Backbone Nodes (5)

13

6

2

7

15

Backbone node

Backbone node

14

10

9

1

Backbone node

5

12

Backbone node

4

8

Backbone node

11

3

initial design
Initial Design

a = 0

Cost = $269,785/month

13

6

2

7

15

5 x T1

2 x T1

14

10

9

1

5

5 x T1

12

5 x T1

4

8

11

3

review of initial design
Review of Initial Design
  • Backbone links have multiple (5) T1 links
  • Probably not a good thing
  • Design Principle:
    • If a design has multiple parallel high-speed links there is usually a better, meshier design
      • Lower cost, greater diversity (= reliability)
  • Note this is not mathematically provable
revised design
Revised Design

umin = 0.7

Cost = $221,590

13

6

2

7

15

3

1

2

14

10

9

1

1

2

5

12

1

4

8

1

11

3

best 5 node backbone design
“Best” 5-Node Backbone Design

a = 0.1

umin = 0.9

Cost = 209,220

13

6

2

7

15

2

2

14

10

9

1

2

5

2

12

1

4

1

8

11

3

comments1
Comments
  • Note that we produced multiple designs by varying some parameters and picking the best
  • Of course, there is no guarantee that this design really is “best”
  • In fact, changing number of backbone nodes yields much better designs
    • 13-node backbone yields design costing only $191,395
    • 12-node backbone costs $198,975
routing
Routing
  • Now we have designed a good network, we consider how the traffic will actually flow across it
  • This introduces a whole new class of problems that center on the performance of the routing algorithms
feasibility considerations
Feasibility Considerations
  • For any pair of nodes N0 and N1, define a route by

(N0, N1, h,n)

Where n = 0 if h is adjacent to N0 and n = 1 if h is adjacent to N1

  • If N0 and N1 are adjacent, we have a direct route
    • Else the route is the link (Nn,h) and the route (N1-n,h,h*,n*)
  • Continue until the full route is established
feasibility considerations1
Feasibility Considerations
  • This process establishes a feasible routing pattern for the network
  • However, the muxes may not be smart enough to find this pattern
  • As an example, consider single-route, minimum-hop (SRMH) routing
an srmh disaster
An SRMH Disaster

A

H

  • Assume MENTOR adds link BF to carry traffic from B to F, G, H, I – but not traffic from F to ABC
  • SRMH insists on carrying all traffic from A, B, C to F, G, H, I – result is overload on BF

B

G

F

C

E

I

D

feasibility and routing
Feasibility and Routing
  • In reality, few network-loading algorithms are as bad as SRMH
  • However, network-loading algorithms do add to the design constraints
    • In particular, minimum-hop routing algorithms are fragile with respect to network capacity changes
    • Effective algorithms for redesign are not available
a more realistic loading algorithm
A More Realistic Loading Algorithm
  • Flow-Sensitive, Minimum-Hop (FSMH) loader loads traffic onto a minimum-hop path, subject to using only links with enough free capacity to carry it
    • Allows overflow onto longer paths
    • If no path exists, traffic is blocked
  • However, there is no guarantee that FSMH will do better than SRMH!
fsmh failure example
FSMH Failure Example

A

B

Each link has capacity 1

C

D

Traffic:

SRMH will block the second AB traffic

and load 4 out of 5 requirements

FSMH will load load both AB requirements,

but block all the rest

Note: order of loading traffic is significant!

comments on fsmh
Comments on FSMH
  • In the earlier example (15 sites), FSMH fails on the best designs
    • 13-node, $191k design blocks 3.3% of traffic
    • 12-node, $199k design blocks 6.7% of traffic
  • Best design where FSMH does not block is 11-node, $201k
approaches
Approaches
  • We cannot guarantee that a highly-optimized network design will work with a given routing algorithm
  • Approaches
    • Test the loading algorithm against best designs
      • Routing takes more computation than design Raises complexity to between O(n3) and O(n4)
    • Limit maximum link utilization to <100%
      • Also increases reliability, allows for growth
router network design
Router Network Design
  • Common routing algorithm for IP is OSPF (Open Shortest Path First)
  • Implicit problem is design for minimum distance
    • Single-route, minimum distance loader (SRMD)
      • Computes single shortest path between site pairs
      • If traffic saturates the route, it’s discarded
      • Designer chooses link lengths appropriately
srmd characteristics
SRMD Characteristics
  • Traffic not forced onto illogical paths if link lengths are chosen properly
  • Problems can still arise
    • Not dynamic
    • Cannot split traffic between different routes
ospf example
OSPF Example

This link intended to carry traffic between A and H, and B to H

but not traffic between A and G

A

395

H

90

100

B

100

G

100

F

100

C

E

I

100

D

A-H traffic will take 1-hop path length 395

B-H traffic will take 2-hop path length 485

A-G traffic will take 5-hop path length 490

important difference
Important Difference
  • Mux networks are designed for high utilization
  • Router networks are not designed for high utilization
    • Allows some margin for error by the routing algorithm
comments2
Comments
  • Can encourage the traffic to use the MENTOR routing as we add edges by setting the length of each tree edge to 100, and the length of a direct edge between N1 and N2 to:

100 + 90*(hops(N1,N2)-1)

comments 21
Comments (2)
  • Any routing algorithm should work for a tree
  • Problems arise when design becomes more highly meshed
  • Can manipulate solution by
    • Increasing length of overloaded links
    • Shortening under-utilized links
    • Adding or deleting capacity
homework assignment
Homework Assignment
  • Cahn Exercises 8.2, 8.6
  • Read Cahn Chapter 9
ad