Wide Area Ethernet Services Using GELS Architecture Zartash Afzal Uzmi Department of Computer Science School of Science and Engineering Lahore University

Wide Area Ethernet Services Using GELS Architecture

Zartash Afzal UzmiDepartment of Computer Science

School of Science and EngineeringLahore University of Management Sciences

(LUMS)Lahore, Pakistan

March 30, 2008 AICCSA 2008: Wide Area Ethernet Services Using GELS 2

What we are going to talk about?

Question– Is it feasible and/or better to use newly proposed GELS

architecture instead of traditional (STP) solution?

Given– A network of nodes and

communication links

Problem“Optimally” place traffic on the given network

Options(1) use 25+ years old STP in the network(2) use a newly proposedGELS architecture


What is GELS?

GMPLS control for Ethernet label switching

Ethernet uses IEEE 802.3 data plane Control plane

Current (old): STP and its variants Proposed: GMPLS (proposed by GELS!)

To evaluate GELS, we need to understand: STP and its variants such as Rapid STP (RSTP) GMPLS (generalized MPLS!)


Tutorial Agenda PART-I

Introduction to MPLS and MPLS Terminology Setting up a simulated MPLS network (Hands-on)

PART-II Introduction to STP for Bridges

PART-III GMPLS and the GELS Architecture Comparison of GELS with Rapid STP (Hands-on)

PART-IV Restoration and Protection Routing with MPLS

PART-V Comparison of GELS with RSTP (Hands-on)

PART-I

Introduction to MPLS and MPLS TerminologySetting up a simulated MPLS Network


Outline

Traditional IP Routing Forwarding and routing Problems with IP routing Motivations behind MPLS

MPLS Terminology and Operation MPLS Label, LSR and LSP, LFIB Vs FIB Transport of an IP packet over MPLS More MPLS terminology


Outline




Forwarding and routing

Forwarding: Passing a packet to the next hop router

Routing: Computing the “best” path to the destination

IP routing – includes routing and forwarding Each router makes the forwarding decision Each router makes the routing decision

MPLS routing Only one router (source) makes the routing decision Intermediate routers make the forwarding decision


IP versus MPLS routing

IP routing Each IP datagram is routed independently Routing and forwarding is destination-based

Routers look at the destination addresses May lead to congestion in parts of the network

MPLS routing A path is computed “in advance” and a

“virtual circuit” is established from ingress to egress

An MPLS path from ingress to egress node is called a label switched path (LSP)


How IP routing works

Searching Longest Prefix Match in FIB (Too Slow)


Problems with IP routing

Too slow IP lookup (longest prefix matching) “was” a

major bottleneck in high performance routers This was made worse by the fact that IP

forwarding requires complex lookup operation at every hop along the path

Too rigid – no flexibility Routing decisions are destination-based

Not scalable in some desirable applications When mapping IP traffic onto ATM


IP routing rigidity example

Packet 1: Destination A Packet 2: Destination B S computes shortest paths to A and B; finds D as next hop Both packets will follow the same path

Leads to IP hotspots! Solution?

Try to divert the traffic onto alternate paths

1 1

1 2

A B

C

A

B

S

D


IP routing rigidity example

Increase the cost of link DA from 1 to 4 Traffic is diverted away from node D A new IP hotspot is created! Solution(?): Network Engineering

Put more bandwidth where the traffic is! Leads to underutilized links; not suitable for large

networks

1 4

1 2

A B

C

SA

B

D


Motivations behind MPLS

Avoid [slow] IP lookup Led to the development of IP switching in 1996

Provide some scalability for IP over ATM Evolve routing functionality

Control was too closely tied to forwarding

Evolution of routing functionality led to some other benefits Explicit path routing Provision of service differentiation (QoS)


IP routing versus MPLS routing

Traditional IP RoutingMultiprotocol Label Switching (MPLS)

S D

543

21

MPLS allows overriding shortest paths!


Outline




MPLS label

To avoid IP lookup MPLS packets carry extra information called “Label”

Packet forwarding decision is made using label-based lookups

Labels have local significance only! How routing along explicit path works?

IP DatagramLabel


Routing along explicit paths

Idea: Let the source make the complete routing decision

How is this accomplished? Let the ingress attach a label to the IP packet and let

intermediate routers make forwarding decisions only On what basis should you choose different

paths for different flows? Define some constraints and hope that the constraints

will take “some” traffic away from the hotspot! Use CSPF instead of SPF (shortest path first)


Label, LSP and LSR

Label

Router that supports MPLS is known as label switching router (LSR)

An “Edge” LSR is also known as LER (edge router)

Path which is followed using labels is called LSP

Label = 20 bits Exp = Experimental, 3 bits S = Bottom of stack, 1bitTTL = Time to live, 8 bits

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Label | Exp|S| TTL


LFIB versus FIB

Labels are searched in LFIB whereas normal IP Routing uses FIB to search longest prefix match for a destination IP address

Why switching based on labels is faster? LFIB has fewer entries Routing table FIB has larger number of entries???

In LFIB, label is an exact match In FIB, IP is longest prefix match


Mpls Flow Progress

LSR1

LSR2

LSR3

LSR5

LSR6

R1 R2LSR4D

1 - R1 receives a packet for destination D connected to R2

R1 and R2 areregular routers

D

destination


Mpls Flow Progress

LSR1

LSR2

LSR3

LSR5

LSR6

R1 R2LSR4D

2 - R1 determines the next hop as LSR1 and forwards the packet(Makes a routing as well as a forwarding decision)

D

destination


Mpls Flow Progress

LSR1

LSR2

LSR3

LSR5

LSR6

R1 R2LSR4

D

3 – LSR1 establishes a path to LSR6 and “PUSHES” a label(Makes a routing as well as a forwarding decision)

D

destination

31


Mpls Flow Progress

LSR1

LSR2

LSR3

LSR5

LSR6

R1 R2LSR4

D

4 – LSR3 just looks at the incoming labelLSR3 “SWAPS” with another label before forwarding

D

destination

17

Labels have localsignifacance!


MPLS Flow Progress

LSR1

LSR2

LSR3

LSR5

LSR6

R1 R2LSR4

D

5 – LSR6 looks at the incoming labelLSR6 “POPS” the label before forwarding to R2

D

destination

17

Path within MPLS cloudis pre-established:LSP (label-switched path)


MPLS and explicit routing recap

Who establishes the LSPs in advance? Ingress routers (usually!)

How do ingress routers decide not to always take the shortest path? Ingress routers use CSPF (constrained shortest path

first) instead of SPF Examples of constraints:

Do not use links left with less than 7Mb/s bandwidth Do not use blue-colored links for this request Use a path with delay less than 130ms


CSPF

What is the mechanism? (in typical cases!) First prune all links not fulfilling constrains Now find shortest path on the rest of the topology

Requires some reservation mechanism Changing state of the network must also be

recorded and propagated For example, ingress needs to know how much

bandwidth is left on links The information is propagated by means of routing

protocols and their extensions


More MPLS terminology

172.68.10/24

LSR1 LSR2

Upstream Downstream

Data


Label advertisement

Always downstream to upstream label advertisement and distribution

171.68.32/24

LSR1LSR2

Use label 5 for destination 171.68.32/24

MPLS Data Packet

with label 5 travels

Upstream Downstream


Label advertisement

Label advertisement can be downstream unsolicited or downstream on-demand

171.68.32/24

LSR1 LSR2

Sends label Without any Request

Upstream Downstream

171.68.32/24

LSR1 LSR2

Sends label ONLY after receiving request

Request For label

Upstream Downstream


Setting up a simulated MPLS Network

Need a simulator TOTEM with additional modules

Need a network Use famous European and NA networks

Need a traffic matrix Bandwidth for input-output pairs

Place traffic matrix on the network using TOTEM simulator!

PART-II

Introduction to STP for Bridges


Transparent Bridging

…

Bridge

For stations, the two topologies are the same transparent bridging

stations

Ethernet LAN Segment


Transparent Bridge Functions

Promiscuous Listening Every packet passed up to software

Store and Forward Based on a forwarding database

Filtering Also based on forwarding database


Example 1: Learning and Forwarding

Transmission order A D

Ports 2, 3 D A

Port 1 Q A

Filtered Z C

Ports 1, 3

BPort 1

Port 2

Port 3

A Q

Z C

D M


Example 2: Two Bridges

B1Port 1 Port 2

B2Port 1 Port 2

A Q D M K T

What are the Station Caches after “complete” learning?


Topologies with Loops

Problems Frames proliferate Learning process unstable Multicast traffic loops forever

B1 B2 B3

LAN 1

LAN 2

A


Spanning Tree Algorithm

A distributed Algorithm Elects a single bridge to be the root bridge Calculates the distance of the shortest path from

each bridge to the root bridge (cost) For each LAN segment , elects a “designated”

bridge from among the bridges residing on that segment The designated bridge for a LAN segment is the one

closest to the root bridge And…


Spanning Tree Algorithm

For each bridge Selects ports to be included in spanning tree The ports selected are:

The root port --- the port that gives the best path from this bridge to the root

The designated ports --- ports connected to a segment on which this bridge is designated

Ports included in the spanning tree are placed in the forwarding state

All other ports are placed in the blocked state


Forwarding frames along the spanning tree

Forward and Blocked States of Ports

Data traffic (from various stations) is forwarded to and from the ports selected in the spanning tree

Incoming data traffic is always discarded (this is different from filtering frames. Why?) and is never forwarded on the blocked ports


Root Selection: Bridge ID

Each port on the Bridge has a unique LAN address just like any other LAN interface card

Bridge ID is a single bridge-wide identifier that could be: A unique 48-bit address Perhaps the LAN address of one of its ports

Root Bridge is the one with lowest Bridge ID

BPort Address


Path Length (Cost)

Path length is the number of hops from a bridge to the root

While forming a spanning tree, we are interested in the least cost path to the root

Cost can also be specified based on the speed of the link Not fair to treat a 10Mb/s link the same as a 1Gb/s

link A guideline for cost selection is in Table 8.5 of the

latest IEEE 802.1D standard


Example Topology

1

4 5 7

1068

11 2

0


After algorithm execution

1

4 5 7

1068

11 2

0

DP

RP

BP BP

RPRP

DP

RP

DP

RP

DP

DP

RP

BP

RP

DP

DP

RP

RP

DP

RP: Root PortDP: Designated PortBP: Blocked Port


The Spanning Tree

1

4 5 7

1068

11 2

0

DP

RP

BP BP

RPRP

DP

RP

DP

RP

DP

DP

RP

BP

RP

DP

DP

RP

RP

DP

RP: Root PortDP: Designated PortBP: Blocked Port


Setting up a simulated STP Network

Need a simulator TOTEM with additional modules

Need a network Use famous European networks

Need a traffic matrix Bandwidth for input-output pairs

Compromised CSPF algorithm Paths over a shared medium network


STP and wide area networks

Traditionally, STP is used in Bridged Ethernet local area networks (LANs)

Ethernet means two things: Physical and MAC layer standard (CSMA/CD) A frame format

Use of Ethernet [from format] is becoming popular in wide area networks STP can be used in wide area networks to

come up with a loop free network topology


Applying STP on a wide area network


Applying STP on a wide area network

Things will work okay but we would like to do better!


EthernetEthernet

Dominant 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 - Ethernet in the core - challengeschallenges

Existing control plane (STP)Network link utilization – LowResilience mechanism – SlowRudimentary support for QoS and TE

Spanning tree computed

Spanning tree recomputed

Link failure


Ethernet in the Core

Ethernet LANs use STP (or RSTP/MSTP)

Use of STP in Core Network leads to challenges

Can we use an alternate control plane?

GELS Architecture For Core Networks, use GMPLS as the

Ethernet control plane

PART-III

GMPLS and the GELS ArchitectureComparison of GELS with Rapid STP (Hands-

on)


MPLS challengesMPLS challenges

Newer 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


GMPLS: Introduction

Extends MPLS to support non-packet based interfaces (like TDM, OTN, Ethernet etc.)

Concept of LSP and label is generalized Such as timeslots as labels or layer 2 LSP

Provides a unified control plane for various data planes


GMPLS: Supported Interfaces

Packet Switch Capable Interfaces (PSC) Interfaces that recognize packet boundaries

and forward data based on packet headers Example: IP GMPLS labels are based on packet header

values



Layer-2 Switch Capable (L2SC) Interfaces Interfaces that recognize frame/cell

boundaries and forward data based on frame/cell headers

Examples: Ethernet, ATM GMPLS labels are based on frame/cell

header values



Time Division Multiplex Capable (TDM) Interfaces Interfaces that switch data based on the

data’s time slot Examples: SONET/SDH GMPLS labels are actual time slots



Lambda Switch Capable (LSC) Interfaces Interfaces that switch data based on the

wavelength or waveband on which data is received Examples: Photonic Cross-Connect (PXC), Optical

Cross-Connect (OXC) GMPLS labels are either

wavelength (value of lambda), or (waveband id + lambda range)



Fiber Switch Capable (FSC) Interfaces Interfaces that switch data based on the

physical media Examples: PXC and OXC that can operate at

the level of single or multiple fibers GMPLS labels are actual fibers


GMPLS: Enhancements to MPLS

GMPLS incorporates enhancements to MPLS including: Constraining Label Choices Out of Band Signaling Reducing Signaling Latency Link Management Protocol


Constraining Label Choices

What is meant by constraining label choices? In MPLS, the upstream node requests a label and the

downstream node assigns one from the available set of labels

In GMPLS, the downstream node can be constrained to select a specific label or a label from a given label set

Why constrain label choices? Some optical switches may not have the capability to

switch wavelengths or may not prefer too much switching (wavelength conversion introduces distortion)

Nodes may need to assign a specific label which is chosen by a centralized server


Constraining Label Choices

Two ways of constraining label choices Label Set: Upstream node specifies a label set to

the downstream node which selects a label from this set

Explicit Label Set: A central node, having complete information about label assignments in network, can select labels on each link for each LSP; all nodes along the LSP have to assign the pre-selected labels


Out of Band Signaling

Protocol Layers for data and control plane: In MPLS, IP is used for communicating data as well as

control messages. Thus, data and control channels are at the same protocol layer

In GMPLS, control messages are still communicated at IP layer, while the GMPLS supported forwarding (data) planes can be at lower layers

Granularity of Layers Lower layers have coarse granularity e.g., thousands of

MPLS LSPs traverse a single wavelength Assigning a separate wavelength or fiber for a single

control channel may not be efficient



In GMPLS out of band signaling is preferred due to: difference in control and data protocol layers possible wastage of resources if control channel uses

the data plane at relatively lower layers Control channels use IP which may run over any

transport such as ethernet etc. Process of identifying data and control paths for an LSP:

First, we calculate the data path for an LSP request Then, we calculate the control path that traverses all

nodes in the data path Since control channel topology may be different from

the data topology, the data and control paths MAY be different



Control path

Data path

Forward

Reserve

Reserve


Out of Band Signaling: Issues

In in-band signaling, all nodes that receive the control message for resource reservation have to reserve resources on the same interface on which the control message is received

However, in out of band signaling: If the node that receives the control message is not in

the data path it should simply forward the message to the next control node.

If the node is in the data path, it has to identify the data interface on which the reservation is required

GMPLS handles the above issues through extensions in resource reservation protocols


Signaling Latency: Problem

In MPLS/GMPLS, actual switching/label assignment decision is made during the return path of signaling request

Configuring a IP/MPLS router for switching is not too time consuming

However, configuring an OXC for switching requires extra time micro mirrors have to be adjusted subsequent wait time for the resulting movement

vibrations to damp away


Reducing Signaling Latency

Suggested Label Upstream node suggests a label to the downstream

node It configures its switching based on this label Downstream node is not constrained to select this

label but should prefer this assignment If another label is assigned by the downstream

node, the configuration is done for the actual label Reduces signaling latency in general


Suggested label: Example

Used labels101520

Used labels111621

Use label 11 Use label 12

12 12


GMPLS/MPLS with Ethernet

GMPLS support for Ethernet Ethernet control plane is replaced by GMPLS control

plane Ethernet over MPLS

Ethernet frames are carried over an MPLS cloud, giving a virtual LAN type environment

MPLS over Ethernet MPLS packets are carried over an Ethernet transport


GELS is in draft stages in IETF

No quantitative performance comparison available so far

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

GELSGELS

Ethernet Bridge


GMPLS Support for Ethernet

GMPLS control plane dictates the forwarding of ethernet frames

Provides a connection oriented ethernet service

Spanning tree protocols are replaced by GMPLS constraint based routing

Allows traffic engineering and rerouting of ethernet connections.


GMPLS controlled Ethernet Label Switching (GELS)

Architecture GMPLS enabled bridges in the core that switch the

Ethernet frame based on a ‘label’ Bridges could be part of a multi-layer network ---

nodes are called Ethernet Label Edge Routers (E-LER) and Ethernet Label Switched Routers (E-LSR) regardless of the type/number of layers Typical GELS layers: IP, Ethernet, and Lambda i.e. IP

over Ethernet over Lambda E-LERs and E-LSRs need not have IP layer i.e. only

have functionality of layer 2 and below


GELS- Architecture

Ethernet Label Edge Router (E-LER) ingress or egress points of a GMPLS Ethernet

network at the ingress: takes an incoming native frame,

adds an Ethernet label, and forwards it to the appropriate label controlled interface

at the egress: removes the label and forwards it to a non-label controlled interface

Ethernet Label Switched Router (E-LSR) takes an incoming labeled ethernet frame and

forwards the frame to the appropriate label controlled interface


E-LER and E-LSR functionality

Ethernet Ethernet Ethernet Ethernet

E-LER E-LERE-LSR


Services offered by GELS

Metro Ethernet Forum has defined two service types: Ethernet Line Service (ELS) and Ethernet LAN Service (E-LAN)

ELS Point to Point Ethernet Service Similar to Frame Relay or ATM Virtual Circuit

E-LAN Multipoint to Multipoint Ethernet Service (like a normal

Ethernet LAN) A new site automatically gains access to all previously

existing sites


ELS and E-LAN

Initial scope of GELS is limited to Point to Point Ethernet LSPs


GELS --- Choice of Label

The selection of label has been the most controversial issue in GELS --- still no consensus

What are the considerations? Label should not require changes in data plane

IETF’s role is restricted to GMPLS which mandates changes in control plane ONLY

Any change in data plane is unlikely to be supported by IEEE.

The label should allow large number of nodes to be addressed i.e., label space should be sufficient

It should allow co-working of 802.1 bridges having VLAN capability with GMPLS enabled Ethernet Routers

Should be scalable --- the forwarding table entries and changes to OSPF-TE and RSVP-TE should be manageable


Label Options: VLAN ID

VLAN ID can be used as a label with MAC learning switched off This ensures that switching is done on the basis of

VLAN id Pros

Doesn’t require changes in Data Plane Cons

VLAN id cannot be used within LANs --- their functionality would be lost

Limited label space --- 12 bits


Label Options: VLAN ID (Q in Q)

Stack VLAN ids: use separate VLAN ids for metro/core while preserving the ids used in individual LANs

Example: Cisco’s Q in Q (used for metro Ethernet but doesn’t use GMPLS control plane)

Pros VLAN functionality is not lost

Cons Requires modification in data plane since stacking

of VLAN ids is not supported


Label Options: MPLS shim label

Already defined in MPLS to be used with Ethernet as layer 2 technology

Pros Doesn’t require changes in data plane

Cons Doesn’t work at the Ethernet level (layer 2) ---

works at MPLS layer which means that MPLS/IP layer functionality has to be added to ethernet switches. Then why not use ethernet over MPLS?


Label Options: Use of proprietary MAC addresses

Use different/proprietary MAC addresses for forwarding in the GMPLS core

First three bytes of MAC address are the Organizational Unit Identifier (OUI)

Reserve OUI for use in GELS Pros

Large label space No changes required in E-LSR

Cons MAC address has to be overwritten at the E-LER, thereby

requiring change in the data plane


Label Options: Use of new tag protocol identifier (tpid)

First two bytes of Q-tag are tpid e.g, value of 0x8100 in the first two bytes indicate

a (C-)VLAN in the next two bytes idea is to use a different tpid for the GMPLS label

Acreo have built a tpid based solution for GELS

Pros Large label space (2 bytes)

Cons Require changes in data plane


Label Options: Use of MAC address + VLAN id

Use a combination of Destination MAC address + VLAN id as the label

Pros Large label space

Cons Require changes in data plane Labels cannot be link local


GELS: Future Work

Need a consensus on the choice of label Evaluate the several proposals that have been

made already and possibly some new ones as well Based on the choice of label and other GELS

requirement, design appropriate extensions to OSPF-TE and RSVP-TE

Design a mechanism to interoperate traditional MAC learning/flooding with GMPLS based control plane


GELS EvaluationGELS Evaluation

Simulation 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


MethodologyDevelop software tools for:(1) simulating GELS architecture(2) simulating traditional solution

Consider a well known network (e.g., European COST266)

Compare old and new solutions (STP vs. GELS)

Network behaves normally Portion of Network fails

Which solution places more traffic on the network?

Which solution recovers faster from the failure?

Compare resultsSTP vs. GELS

Approach for Evaluation of GELS

Approach for Evaluation of Approach for Evaluation of GELSGELS

PART-IV

Restoration and Protection with MPLS


IP versus MPLS (recall)

In IP Routing, each router makes its own routing and forwarding decisions

In MPLS: source router makes the routing decision Intermediate routers make forwarding decisions A path is computed and a “virtual circuit” is

established from ingress router to egress router

An MPLS path or virtual circuit from source to destination is called an LSP (label switched path)


Protection and Restoration

Restoration On-demand recovery – no preset backup paths Example: existing recovery in IP networks

Protection Pre-determined recovery – backup paths “in advance” Primary and backup are provisioned at the same time

IP supports restoration Because it is datagram service

MPLS supports restoration as well as protection Because it is virtual-circuit service


Restoration in IP network

In traditional IP, what happens when a link or node fails? Failure information needs to be disseminated

in the network During this time, packets may go in loops Restoration latency is in the order of seconds

We look for protection possibilities in an MPLS network, but… First we need to look at the QoS

requirements


QoS Requirements

Bandwidth Guaranteed Primary Paths

Bandwidth Guaranteed Backup Paths BW remains provisioned in case of network failure

Minimal “Protection or Restoration Latency” Protection/Restoration latency is the time that

elapses between: “the occurrence of a failure”, and “the diversion of network traffic on a new path”

Restoration is generally SLOWER than protection


Protection in MPLS

First we define Protection level

Path protection Also called end-to-end protection For each primary LSP, a node-disjoint backup LSP is set up Upon failure, ingress node diverts traffic on the backup path

Local Protection Upon failure, node immediately upstream the failed element

diverts the traffic on a “local” backup path

Path Protection More LatencyLocal Protection Less Latency


Protection in MPLS

S 1 2 3 D

Primary PathBackup Path

Path Protection

This type of “path Protection” still takes 100s of ms.We may explore “Local Protection” to quickly switch onto backup paths!


Local Protection: Fault Models

A B C DLink Protection

A B C D

A B C D

Node Protection

Element Protection


Reliability in Core Networks

In Core Networks, we can use GELS with:

Protection, or Restoration

With this background on network recovery, we are now ready to compare STP with the GMPLS control plane

PART-V

Comparison of GELS with RSTP(Hands-on)


GELS EvaluationGELS Evaluation

Simulation 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


Evaluation CriteriaEvaluation Criteria

Evaluation criteria

Normal network condition

Failed network condition

Total bandwidth

placed

Number of LSPs

placed

Average link

utilization

Single link failure

Single node

failure

RSTP convergenc

e time

GELS recovery

Restoration

Protection

GELS recovery schemes

How efficiently can we use the

network?

How quickly can we recover from

failure?


GMPLS with Compromised CSPF

Evaluation challengesEvaluation challenges

How 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 timeGELS: 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 valuesTiming parameter values

tsig(Signaling delay):

Based on 1ms/200 km link propagation delay

tproc(Processing delay):

5ms

tres(Reservation delay):


tsw(Switching delay):

1ms


GELS restoration recovery timeGELS restoration recovery time

LSP 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


GELS Centralized restorationGELS Centralized restoration

Some deployments may use centralized instead of distributed failure recovery

A central server handles restoration of LSPs affected by a failure

Two options:Path Computation Element (PCE)Network Management System (NMS)


Path Computation Element (PCE)Path Computation Element (PCE)

PCE is an entity responsible for path computation on request from a Path Computation Client (PCC)

It could be a node or a processPCE may or may not reside on the

same node as the PCC

PCE

PCC

Node A

PCC

Node B

PCE

Node C


Path Computation Element (PCE)Path Computation Element (PCE)

PCC sends a targeted request to a PCEPCC may not broadcast a requestThe PCE may compute the end-to-end

path itselfA PCE may cooperate with other PCEs

to determine intermediate loose hops

PCC PCE PCE PCE


Our PCE scenarioOur PCE scenario

A single central PCE server for the routing domain

Nearest upstream node to the point of failure sends restoration request to PCE upon a failure event

PCE computes the new path and sends this path to the ingress

Ingress reserves the new LSPIngress switches traffic onto new LSP




GELS centralized restoration: PCEGELS centralized restoration: PCE

Link failure

Failure notification sent to PCE

tsig1: Signaling

delay

Potential new path

Reserve new LSPtres: Reservation

delay

Ingress Egres

s

LSP

Restoration: trest = tsig1 + tproc + tsig2 +

tres + tsw

Nearest upstream

node to the failure

PCE

Compute new LSP


Notify the ingress of the new path

tsig2: signaling delay


GELS restoration: PCEGELS restoration: PCE

Central PCEs are typically high end multiprocessor platforms

Router platforms are not as fast as central PCEs

Centralized PCEs should be able to compute paths more quickly than routers

Centralized PCEs should also be able to perform multiple path computations simultaneously


GELS restoration: NMSGELS restoration: NMS

NMS is also a centralized restoration scenario

Here, the central server performs path computation as well as reservation

It may use SNMP for path reservationOnce path has been reserved, the

ingress is notifiedIngress switches traffic onto new LSP




GELS centralized restoration: NMSGELS centralized restoration: NMS

Link failure

Failure notification sent to NMS

tsig1: Signaling

delay

Potential new path

Ingress Egres

s

LSP

Restoration: trest = tsig1 + tproc + tsig2 +

tres + tsw

Nearest upstream

node to the failure

NMS

Compute new LSP


Reserve resources along the new pathtsig2:

signaling delayNotify the ingress of the new LSP


Timing parameter valuesTiming parameter values

tsig(Signaling delay):


tproc(Processing delay):

1ms

tres(Reservation delay):


tsw(Switching delay):

1ms


Simulation setup - networksSimulation 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 nodesCOST 266: 50

nodes


Traffic matricesTraffic matrices

LSP requests arrive one-by-oneRandomly chosen ingress and egress

nodesBandwidth request 1, 2 or 3 Gb/s

chosen with equal probability


Simulation environmentSimulation environment

Based on:Bridgesim1 for native EthernetTOTEM2 for GMPLS-controlled Ethernet

Enhancements to simulators:Implementation of C-CSPFComputation of recovery time

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


A famous European network (COST266)

How much traffic can be placed?


Black links indicate no traffic!

Results: Using old solution (STP)


There are no black links!

Results: Using new solution (GELS)


Comparison Graph: Taken from IEEE Globecom 2007 paper

Comparative Performance


Results: LSP placement percentageResults: LSP placement percentage

GELS with restoration places more LSPs than RSTP

GELS with protection places fewer LSPs than RSTP


Results: Bandwidth placementResults: Bandwidth placement

GELS with protection places less (primary) bandwidth than RSTP

GELS with restoration places more bandwidth than RSTP


Results: Average link utilizationResults: 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 rootResults: 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 time

Topology

RSTP (ms)

Restoration (ms)

PCE(ms)

NMS(ms)

Protection (ms)

tmin tmax tmin tmax tmin tmax

11 nodes

0.7 32.67

41.61

23.53 81.75 29.36 99.68 3.89

50 nodes

102.4 38.13

39.61

39.14 64.65 52.4 98.31 6.18

Results: Single link failure Results: Single link failure convergence timeconvergence time

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

239


Single link failure average convergence time

Topology

RSTP (ms)

Restoration (ms)

PCE(ms)

NMS(ms)

Protection (ms)

tmin tmax tmin tmax Tmin tmax

11 nodes

4850 30.07 39.34 22.21

62.34 29.81 95.25 2.56

50 nodes

3365 42.25 44.24 37.41

76.13 52.73 111.83

6.1

Results: Node failure convergence Results: Node failure convergence timetime

t1 - t10 are in milliseconds

10

1iit

t1 – t49 are in milliseconds

50+

11

Small value

49

1iit50+

50

Small value


SummarySummary

About 45% improvement with GELS over native Ethernet in: LSP acceptanceBandwidth placement

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


ConclusionConclusion

Ethernet 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

Documents

Wide Area Ethernet Services Using GELS Architecture Zartash Afzal Uzmi Department of Computer Science School of Science and Engineering Lahore University