A simulation study of GELS (GMPLS-controlled Ethernet Label Switching) for

Ethernet over WANMuhammad Saqib Ilyas (msaqib@ieee.org)School of Science and EngineeringLUMS, Lahore, Pakistan

IEEE Globecom 2007Washington, D.C.Wednesday, Nov 28, 2007

Work sponsored by:Siemens Corporate Technology DivisionMunich, Germany

Co-authors:Atif Nazir, Fawaz Saleem Bokhari, Zartash Afzal Uzmi (LUMS)Fahad Dogar (CMU, Pittsburgh)Adrian Farrel (Old Dog Consulting)

AgendaGMPLS – BackgroundEthernet – BackgroundGELS Architecture

◦GMPLS as the control plane for Ethernet

Simulation Modeling and SetupSimulation ResultsSummary and Conclusions

IP Routing

Dest: 150.10.10.1

Dest IP Next hop

I’face

………….. ….. …

150.0.0.0 ….. …

150.10.0.0

.…. …

150.10.10.0

….. …

………….. ….. …

………….. ….. …

Longest prefixmatch

Forwarding in MPLS

Label lookup

Labeli

n

Labelou

t

I’face

… ….. …

8 8 …

9 15 …

10 13 …

… ….. …

… ….. …

Label: 10

Label: 13

MPLS challengesNewer devices are capable of switching on

the basis of:◦ Interface (FSC)◦ Wavelength (LSC)◦ TDM timeslot

MPLS works with packet switch devices only◦ Looks at the label and forwards an incoming packet

Solution:◦ Generalize MPLS to GMPLS (RFC 3945)

Incompatibility of MPLS with newer devices

GMPLS offers a control plane for devices with ANY data

plane

EthernetDominant LAN transport

technologySpeed and reach grew

substantially in the last 25 yearsVery flexible and cost-effective

transport

Ethernet is seeing increasing deployment in service provider networks

Ethernet in the core - challengesExisting control plane (STP)

◦Network link utilization – Low◦Resilience mechanism – Slow◦Rudimentary support for QoS and TE

Spanning tree computed

Link failure

Spanning tree recomputed

GELS is in draft stages in IETFNo quantitative performance

comparison available so far

Proposes to use GMPLS control plane for the Ethernet data plane!

GELS

Ethernet Bridge

GMPLS control plane

Ethernet control plane

Ethernet data plane

Our workSimulation based evaluation of

GELSRapid STP (RSTP) versus GMPLS

◦How does old control plane compare with new control plane?

Considered:1. Normal network operation2. Single element failures

GELS Recovery Schemes

Evaluation CriteriaEvaluation criteria

Normal network condition

Average link utilization

Number of LSPs placed

Total bandwidth placed

Failed network condition

Single link failure

Single node failure

RSTP convergence time

GELS recovery

Restoration

Protection

How efficiently can we use the

network?

How quickly can we recover from

failure?

GMPLS with Compromised CSPF

Evaluation challengesHow to compare contention-

based Ethernet with reservation based GMPLS?◦Allow partial placement of LSPs in

GMPLS instead of YES/NO placement

Request: 25Placed: 0

GMPLS with CSPF

Placed: 15

LSP placedBandwidth placed: 60%LSP not placedBandwidth placed: 0%

Capacity: 100

Available: 15

Available: 0

Switch traffic onto new LSP

tsw: Switching delay

GELS: Convergence time

Link failure

Failure notification

sent to ingresstsig: Signaling

delay

Compute new LSP

tproc: Processing delay

Potential new path

Reserve new LSPtres: Reservation

delay

Ingress Egres

s

LSP

Restoration: trest = tsig + tproc + tres + tsw

Protection: tprot = tsig + tsw

Nearest upstream

node to the failure

Timing parameter valuestsig(Signaling delay):

◦ Based on 1ms/200 km link propagation delay

tproc(Processing delay):◦ 5ms

tres(Reservation delay): ◦ Based on 1ms/200 km link propagation delay

tsw(Switching delay): ◦ 1ms

GELS restoration recovery timeLSP 1LSP 2

Ingress has lost multiple LSPs

Nearest upstream

node for LSP 2

Nearest upstream

node for LSP 1

Failure signaled to

ingress

Link failure

1. Compute

2. Reserve3. Switch

SequentiallyOr

In parallel

Sequentially

Sequentially

Convergence time is

tmin

Convergence time is

tmax

Simulation setup - networks

Milan (11)

Copenhagen (1)

London (2) Amsterdam (3) Berlin (4)

Brussels (5) Luxembourg (6) Prague (7)

Paris (8) Zurich (9) Vienna (10)

Oslo (2) Helsinki (1)

Stockholm (3)

Glasgow (4)

Copenhagen (6)

Dublin (7)

Birmingham (9)

London (10)Amsterdam (11)Hamburg (12)Berlin (13) Warsaw (14)

Brussels (15)Dusseldorf (16)

Frankfurt (17)

Paris (19)Strasbourg (20)Munich (21)

Prague (22)Krakow (23)

Zurich (26) Vienna (24)Budapest (28)

Bordeaux (30) Lyon (31)Milan (32) Zagreb (33)

Belgrade (37)Marseille (42)

Barcelona (41)Sofia (46)

Lisbon (43) Madrid (44) Rome (45)

Seville (47)Palermo (49) Athens (50)

Turin (35)Porto (39)Bukarest (38)

Neapel (48)

Belfast (5)

Graz (29)Basel (25)

Toulouse (34)

Salzburg (27)

Liverpool (8)

Zaragoza (40) Bologna (36)

Leipzig (18)

COST 239: 11 nodes

COST 266: 50 nodes

Traffic matricesLSP requests arrive one-by-oneRandomly chosen ingress and

egress nodesBandwidth request 1, 2 or 3 Gb/s

chosen with equal probability

Simulation environmentBased on:

◦Bridgesim1 for native Ethernet◦TOTEM2 for GMPLS-controlled

EthernetEnhancements to simulators:

◦Implementation of C-CSPF◦Computation of recovery time

1: http://www.cs.cmu.edu/~acm/bridgesim/index.html2: http://totem.info.ucl.ac.be/

Results: LSP placement percentage

GELS with restoration places more LSPs than RSTP

GELS with protection places fewer LSPs than RSTP

Results: Bandwidth placement

GELS with protection places less (primary) bandwidth than RSTP

GELS with restoration places more bandwidth than RSTP

Results: Average link utilization

RSTP has lowest average link utilization

GELS with protection quickly approaches almost full link utilization GELS approaches 92% average link

utilization

Results: RSTP convergence time vs cost to root

RSTP convergence time is highest if the root bridge fails

Convergence time decreases as cost to root increases

Single link failure average convergence timeTopology RSTP

(ms)Restoration (ms) Protecti

on (ms)tmin tmax

11 nodes

0.7 32.67 41.61 3.89

50 nodes

102.4 38.13 39.61 6.18

Results: Single link failure convergence time

More links closer to root bridge in COST 266More LSPs were restored in COST 239

Single link failure average convergence timeTopology RSTP

(ms)Restoration (ms) Protecti

on (ms)tmin tmax

11 nodes

4850 30.07 39.34 2.56

50 nodes

3365 42.25 44.24 6.1

Results: Node failure convergence time

t1 - t10 are in milliseconds

10

1iit

t1 – t49 are in milliseconds

50+11

Small value

10

1iit50+

50

Small value

SummaryAbout 45% improvement with

GELS over native Ethernet in: ◦LSP acceptance◦Bandwidth placement

Failure recovery time orders of magnitude less for GELS than for native Ethernet

ConclusionEthernet is a flexible, cost

effective and efficient transport mechanism for metro/core networks

GMPLS promises to be a useful control plane for Ethernet in metro/core

Tremendous administrative benefits of using a single control plane

Vendors actively working on standardization of GELS

Questions?Contact:

msaqib@gmail.com

Simulator: http://suraj.lums.edu.pk/gels/