RD-QoS – The Integrated Provisioning of Resilience and QoS ......direct mapping of resilience attribute to MPLS recovery options •MPLS Traffic Engineering resource efficient resilience

Munich University of TechnologyInstitute of Communication NetworksProf.Dr.-Ing. Jörg Eberspächer

Achim [email protected]

L

1

RD-QoS – The Integrated Provisioning of Resilienceand QoS in MPLS-based Networks

Achim AutenriethMunich University of Technology

Institute of Communication Networks

Email: [email protected]

IEEE International Conference on Communications (ICC)New York, USA

May 1, 2002

Andreas KirstädterSiemens AG, Corporate Technology

Information and Communication

[email protected]



L

2

Outline

½ Introduction

½ Resilience Differentiated QoS (RD-QoS)

½ RSVP / DiffServ Resilience Signaling

½ Interworking with MPLS Recovery

½ Case Study and Results

½ Conclusion



L

3

Introduction

Resilience

Behavior under fault conditionsFault detection, failure notification,recovery and service restoration

MPLSsupports

QoSBehavior under normal conditions

Resource management, trafficmanagement (marking, shaping,queuing, metering)

MPLS offers various resilience optionsProtection Switching / Restoration, Local / Global Scope, …

Advantages of MPLS recovery are:Resource efficiency, recovery granularity, protection flexibility

QoSBehavior under normal conditions

Resource management, trafficmanagement (marking, shaping,queuing, metering)



L

4

Problem Definition

• MPLS recovery must be compared to optical network recovery

⇒ MPLS recovery should utilize its benefits to the most extent

• Moreover, service providers should be able to charge for higher

resilience as a value-added service

⇒ Services should be protected with the required level of resilience

But: How can this level be identified?

Resilience requirements (resilience attribute) should beincluded in the QoS signaling (like bandwidth and delay)



L

5

Resilience-Differentiated QoS

Extended quality-of-service definition: extend thestandard QoS-metrics (bandwidth, delay, delay jitter)

with resilience requirements of IP service classes

Extended quality-of-service definition: extend thestandard QoS-metrics (bandwidth, delay, delay jitter)

with resilience requirements of IP service classes

Resilience attribute• included in QoS signaling between application and network.

• depending on QoS architecture (IntServ, DiffServ) on a perflow or on a per packet basis.

• mapped to MPLS FECs with appropriate recovery options

4 Resilience Classes proposedmainly distinguished by recovery time requirements

RC1 - High RC2 - Medium RC3 - Low

10 - 100ms 100ms - 1s 1s - 10s pre-emption

RC4 - None



L

6

RD-QoS Network Model

FEC1

Core NetworkMPLS / DiffServ

Resilience mechanisms &Traffic Engineering

FEC2

Access networksDiffServ / RSVP

Resilience signaling &resource management

MPLS: MultiprotocolLabel SwitchingRSVP: ResourceReservation ProtocolDiffServ: DifferentiatedServicesFEC: ForwardEquivalence Class



L

7

RD-QoS Building Blocks

• Extended QoS architecture

resilience signaling between application and network

• QoS Resource Management and Traffic Conditioning

takes resilience attribute into account

• Recovery Mechanisms

provided by MPLS

• Interworking of RD-QoS with MPLS

direct mapping of resilience attribute to MPLS recovery options

• MPLS Traffic Engineering

resource efficient resilience provisioning



L

8

RD-QoS Signaling

DiffServ Network

Core routerTraffic SchedulingQueue Management

RM

Edge router (DS boundary)

Resource Management &Traffic ConditioningClassification, Policing,Marking, Shaping

with Resilience Attribute

In case of failure, non-resilient

packets can be treated

out-of-contract

DiffServ

QoS request with resilienceattribute is signaled throughnetwork-> Resource ManagementProtection: Signaling is doneon disjoint routes with explicitrouting

Network withRSVP-TE sign.

PathResv

RSVP-TE RMQoS request with resilienceattribute is signaled throughnetwork-> Resource ManagementProtection: Signaling is doneon disjoint routes with explicitrouting

Network withRSVP-TE sign.

PathResv

RSVP-TE RM



L

9

MPLS Recovery MechanismP

rote

ctio

nR

esto

rati

on

A

B C

DE F

GH I

Segment Prot. (Haskin)

A

B C

DE F

GH I

Fast Reroute

A

B C

DE F

G H I

Global Restoration

A

B C

DE F

GH I

Local Restoration

A

B C

DE F

G H I

Local to Egress Rest.

A

B C

DE F

GH I

Path Protection

Global Segment Local

Recovery Scope

Rec

ove

ry m

od

el

P1 P2 P3

R1 R2 R3



L

10

Resilience Class

RC1 RC2 RC3 RC4

Resilience requirements

High Medium Low None

Recovery time

10-100 ms 100ms - 1s 1s - 10s n.a.

Resilience scheme

Protection Restoration Rerouting Pre-emption

Recovery path setup

pre-establishedon-demand immediate

on-demand delayed

none

Resource allocation

pre-reserved on-demand (assured)

on-demand (if available)

none

QoS after recovery

equivalentmay be tempo-rarily reduced

may have reduced QoS

none

Interworking of RD-QoS with MPLS

Resilience classes are mapped to MPLS recovery optionsResilience classes are mapped to MPLS recovery options



L

11

RD-QoS Traffic Engineering

link

ban

dw

idth

RC1a

RC2a

RC3

RC4RC2b

RC1b

RC1: Protectiona: activeb: backup

RC2: Restorationa: activeb: backup

RC3: ReroutingRC4: Pre-emption

where:

• Offline MPLS Traffic Engineering with resiliencedifferentiation

• Used resources (guaranteed bandwidth)calculated on each link for the 4 resilience classes



L

12

RD-QoS Case Study

Network Scenario• Northern Italian research network• 16 nodes, 36 links • Demands between a pair of nodes

between 1 Gb/s and 16 Gb/s

4 Service Ratio Scenarios• 100% Best-effort traffic (RC3)• RD-QoS traffic with 10% RC1,

20% RC2, 40% RC3 and 30% RC4• 100% RC2 traffic (restoration)• 100% RC1 traffic (protection)

3 Protection and 3 Restoration mechanisms• P1: Path protection P2: Segment prot. P3: Link protection • R1: Global rest. R2: Local to egress rest. R3: Local rest.

GEN

SAV

ALETOR MIL

MIL2BRE VIC

VEN

BOL

FIRPIS

ROM

ANC

PIA VER

GEN

SAV

ALETOR MIL

MIL2BRE VIC

VEN

BOL

FIRPIS

ROM

ANC

PIA VER



L

13

0

200

400

600

800

1000

1200

1400

1600

1800

2000

RC1a RC2a RC3 RC4 RC1b RC2b

Case Study Results

A

Case Study Scenarios

Tot

al u

sed

reso

urce

s (

Gb/

s)

P1: Path protection R1: Global rest. P2: Segment prot. R2: Local to egress rest.P3: Link protection R3: Local rest.

B C D

P1

R1 R2 R3

E F G

P2

R1 R2 R3

H I J

P3

R1 R2 R3

K L M

R1

R2

R3

N O P

P1

P2

P3

Global recoverymechanisms have

better resourceefficiency than

local mechanisms

Global recoverymechanisms have

better resourceefficiency than

local mechanisms

RD-QoS has significantlybetter resource efficiency:

11%-33% recovery resourceratio compared to 115%-207% with full recovery

RD-QoS has significantlybetter resource efficiency:

11%-33% recovery resourceratio compared to 115%-207% with full recovery



L

14

Conclusionsu RD-QoS architecture extends QoS signaling with resilience

requirements of IP services to achieve flexible resilienceprovisioning

u 4 Resilience Classes proposed, primarily distinguished byrecovery time requirements

u RD-QoS achieves high resource efficiency for the cost ofincreased complexity (additional resilience attribute)

The current trend is clearly towards a service-driventransport architecture. The resilience requirements

should therefore be included in the QoS signaling likebandwidth and delay



L

15

Thank you for your attention.



L

16

Resilience Requirements of IP Services

• Resilience requirements of IP services are orthogonal totheir ”classical” quality-of-service requirements(bandwidth, delay, delay jitter)

highlow

highmission-critical VoIP and

multimedia servicesstandard VoIP and

multimedia services

low

database transactions, mission-critical control terminals, e-commerce

applications

e-mail, FTP, standard WWW

Resilience requirements

QoSRequire-ments



L

17

Resilience Classes

Proposed Resilience Classes RC1 - RC4:

RC1: High Resilience Requirements: 10 – 100ms recovery timeUse of MPLS protection switching or Fast Reroute

RC2: Medium Resilience Requirements: 100ms – 1s recovery timeMPLS Restoration with on-demand backup path establishment

RC3: Low Resilience Requirements: 1s – 10 s recovery timeNo resources are reserved / allocated in advance. Traffic recoveryrequires rerouting and resource reservation.

RC4: No Resilience Requirements: pre-emptionCorresponding to low-priority, pre-emptible traffic. Packets may bediscarded in case of failures.



L

18

Multiprotocol Label Switching (MPLS)

u MPLS integrates Layer 3 Routing with Layer 2 Switching

u Connection-oriented characteristic: hop-by-hop IP routingreplaced by label switching

u Packets are assigned to Forward Equivalence Classes (FEC) onlyonce at the network ingress

u Packets follow a pre-definedLabel Switched Path (LSP)

u Signaling protocols forpath setup:CR-LDP & RSVP-TE LSR LSR

LSRLSR

LSR

LER

LSR

LSRLER

FEC1

MPLS domain

FEC2

Assignment of different pathsfor flows with same source

and destination address

Assignment of different pathsfor flows with same source

and destination address



L

19

MPLS Recoveryu MPLS Recovery is currently a key research issue in the IETFu Several drafts are published which present recovery

mechanismsu “ Framework for MPLS-based Recovery ” defined in

[draft-ietf-mpls-recovery-frmwrk-03.txt]u Well known resilience concepts from SDH and ATM Recovery

are mapped to MPLS

Benefits from MPLS Recovery• Finer recovery granularity (compared to Layer 1 recovery)• Protection Selectivity based on Service Requirements

possible• Efficient and flexible resource usage (e.g., recovery path

may have reduced performance requirements)• Allows end-to-end protection of IP services



L

20

MPLS Recovery OptionsRecovery models

Resource Allocation

Resource Use

Path Setup

Recovery Scope

Recovery Trigger

Protection Switching Restoration (MPLS Rerouting)

Reserved-on-demandPre-reserved

Dedicated resources Shared resources Extra-traffic allowed

Pre-established Pre-Qualified Established-on-demand

Local RepairGlobal Repair Segment Repair

Automatic Input(internal signals)

External commands(OAM signaling)

Recovery models

Resource Allocation

Resource Use

Path Setup

Recovery Scope

Recovery Trigger

Protection Switching Restoration (MPLS Rerouting)

Reserved-on-demandPre-reserved

Dedicated resources Shared resources Extra-traffic allowed

Pre-established Pre-Qualified Established-on-demand

Local RepairGlobal Repair Segment Repair

Automatic Input(internal signals)

External commands(OAM signaling)



L

21

Path ProtectionProtection switching, pre-established, global scope, pre-reservedProtection switching, pre-established, global scope, pre-reserved

A E

GH

F

G

D

CB

p-LSP

w-LSP

+ Single backup LSP per working LSP– Failure signaling required+ Node failures covered



L

22

Fast Reroute [Haskin]

u Alternative recovery LSP set up from the last-hop LSR in reverse direction to the ingress

LSP and along a node-disjoint pathto the egress LSP

Source: [draft-haskin-mpls-fast-reroute-01.txt]

Protection switching, pre-established, pre-reserved,local switching, global recovery

Protection switching, pre-established, pre-reserved,local switching, global recovery

A E

GH

F

G

D

CB w-LSP

p-LSP

+ Single backup LSP per working LSP– No failure signaling required

+ Node failures covered– High spare capacity requirement



L

23

Link Protection

Protection switching, pre-established, local scope, pre-reservedProtection switching, pre-established, local scope, pre-reserved

A E

GH

F

G

D

CB

w-LSP

p-LSP3

p-LSP2

p-LSP1

– Multiple backup LSPs per working LSP+ No failure signaling required– Node failures not covered



L

24

Path Restoration

Restoration, established on-demand, reserved on-demand, global scopeRestoration, established on-demand, reserved on-demand, global scope

A E

GH

F

G

D

CB

w-LSP

– Failure signaling required+ Node failures covered

+ Alternative LSPs distributed over network => high spare capacity efficiency



L

25

Failure to Egress RestorationRestoration, pre-established, pre-reserved,

local switching, global recoveryRestoration, pre-established, pre-reserved,

local switching, global recovery

A E

GH

F

G

D

CB

w-LSP

+ No failure signaling required+ Node failures covered

o Between local and global routing => average spare capacity efficiency



L

26

Link Restoration

Restoration, established on-demand, reserved on-demand, local scopeRestoration, established on-demand, reserved on-demand, local scope

A E

GH

F

G

D

CB

w-LSP

+ No failure signaling required– Node failures difficult to cope with

– Alternative LSPs locally routed => lower spare capacity efficiency



L

27

RSVP-TE RC1 Protection Signaling5'�4R6

u Application signals resilience requirements to the network in addition to classical QoS requirementsu Network (additionally) reserves an alternative and disjoint route for the flow (e.g., with explicit routing)u Link or node failure: Traffic is sent over alternative route

MPLS domain

RSVP-TE signals LSP setup for RC1 through network1+1, 1:1 protection: Signaling is done on disjoint routes

PathResv



L

28

0,0

200,0

400,0

600,0

800,0

1000,0

1200,0

1400,0

1600,0

1800,0

2000,0

A B C D E F G H I J K L M N O P


PANEL Case Study Results

100%

RC

3P1

/ R

1P1

/ R

2P1

/ R

3

P2 /

R1

P2 /

R2

P2 /

R3

P3 /

R1

P3 /

R2

P3 /

R3

R1

R2

R3

P1P2

P3

Simulation Scenarios

Tot

al u

sed

reso

urce

s (

Gb/

s)

P1: Path protection

P2: Haskin

P3: Link protection

R1: Global rest.

R2: Local to egress rest.

R3: Local rest.



L

29

COST Case Study Results

0

2000

4000

6000

8000

10000

12000

14000

16000

A B C D E F G H I J K L M N O P Q R S T U V


100%

RC

3P1

/ R

1P1

/ R

2P1

/ R

3P2

/ R

1P2

/ R

2P2

/ R

3P3

/ R

1P3

/ R

2P3

/ R

3R

1R

2R

3P1 P2 P3

R1

R2

R3

P1P2

P3

Simulation Scenarios

Tot

al R

eser

ved

Net

wor

k C

apac

ity (

Gb/

s) P1: Path protection P2: Haskin P3: Link protection

R1: Global rest. R2: Local to egress rest. R3: Local rest.



L

30

Benefits

Interworking of RD-QoS with MPLS allows a direct mapping of RD-QoSclasses to MPLS LSPs with different protection levels according to the

negotiated resilience requirements

Interworking of RD-QoS with MPLS allows a direct mapping of RD-QoSclasses to MPLS LSPs with different protection levels according to the

negotiated resilience requirements

• RD-QoS as an integrated approach for the provisioning ofend-to-end QoS and Resilience

• Direct mapping of Resilience Classes to MPLS recovery optionspossible

• Applications define their resilience requirements⇒ protection flexibility⇒ efficient resource usage

• QoS requirements of high resilience traffic can be met in case ofnetwork failures

• RD-QoS as an integrated approach for the provisioning ofend-to-end QoS and Resilience

• Direct mapping of Resilience Classes to MPLS recovery optionspossible

• Applications define their resilience requirements⇒ protection flexibility⇒ efficient resource usage

• QoS requirements of high resilience traffic can be met in case ofnetwork failures

Documents

RD-QoS – The Integrated Provisioning of Resilience and QoS ......direct mapping of resilience attribute to MPLS recovery options •MPLS Traffic Engineering resource efficient resilience