1 IP/MPLS QoS over ATM. 2 Clarence Filsfils [email protected] Tech. Consulting - EMEA

1

IP/MPLS QoS over ATM

2

Clarence Filsfils

[email protected]

Tech. Consulting - EMEA

3Cisco Systems ConfidentialClarence Filsfils - atm-mpls-cos

Agenda

• IP COS over ATMIP COS over ATM

• IP COS over MPLS

• MPLS CoS over ATM

• IP QoS for Tag VPNs

• Conclusion


IP COS over ATM: Overlay Model

IP Layer: Diff-Serv IP Layer: Diff-Serv MechanismsMechanisms• Connectionless Per packet

precedence (DS-byte) indicating “priority” for each packet

• limited number of COSs

ATM Backbone: ATM Backbone:

ATMF/ITU-T Qos mechanismsATMF/ITU-T Qos mechanisms• Per Connection Qos

• Very strict Qos

• Traffic classes:CBR, VBR, VBR-RT, UBR, ABR

• Traffic Parameters:PCR, MCR, SCR,..

How do I mapHow do I mapthe two worlds ???the two worlds ???

How do I mapHow do I mapthe two worlds ???the two worlds ???


IOS “IP ATM COS”: Principles

• The ATM service The ATM service contracted must be contracted must be provided! (at least, loss provided! (at least, loss less!)less!)

• Router’s traffic Router’s traffic must be compliant must be compliant with respect to with respect to ATM service ATM service contractedcontracted


IOS “IP ATM COS”: Principles

• Congestion pushed back at the edgeCongestion pushed back at the edge

• per-VC IP Queue developsper-VC IP Queue develops

• IP-intelligent QoS Mechanisms in the IP-intelligent QoS Mechanisms in the routerrouter

• Because: ATM switch does not Because: ATM switch does not understand IPunderstand IP


IP ATM COS-Ph1: Per-VC WRED

• Single VC per Pair of Routing Peers • Multiple Service Classes on same VC• WRED runs on each VC queue

VC1

VC2


Distributed VIP2 Architecture

Route Switch Processors

VIP2 VIP2 VIP2xIPxIP

i

SwitchProcessor

PortAdapter

PortAdapter

PortAdapter

PortAdapter

PacketMemory

PPCCII

PPCCII

CCyyBBuuss

Cisco 7500

• Distributed Switching• Distributed Services• Distributed WRED/WFQ


ATM PA-A3 Architecture

SARSAR

PC

I

High-performance SAR

Per-VC Queues/ Traffic Shaping

ATM Shaping: CBR, VBR, ABR (all 3

modes) and UBR

Single-wide port adapter for Cisco

7200/7500

DS3 E3

OC3c/STM1 MM OC3c/STM1 SM-IR OC3c/STM1 SM-LR


Per-VC WRED : Intelligent IP Packet Discard

VIP2-50 PA-A3-XX

Per-VCPer-VCWRED:WRED:

Intelligent DiscardIntelligent Discard

Threshold Exceeded

VC1

VC2

VC3

No discardNo discardon PAon PA

Traffic Traffic ShapingShaping

Per-VCPer-VCQueuesQueues


Per-VC WRED (cont.)

• ATM router interface “shapes” according to VBR, CBR or ABR* requirements

• Very low loss on ATM network is essential–Easy with CBR, VBR

–Good match to ABR allowing elastic use of all available bandwidth (assuming low loss implementation, e.g. BPX)

–Not effective with UBR VCs

• VCs not backlogged are unaffected!

• VC dimensioned so that all COSs get their appropriate quality

* ABR : Future


Per-VC WRED CLI

WRED profile:random-detect group <group-name>

exponential weighting constant <1.16>

precedence <0..7, rsvp> <min-th> <max-th> <mark-p>

To activate a WRED profile on a PVC:atm pvc <vcd> <vpi> <vci> <aal-encap> [[<mid_low> <mid_high>]

[<peak> <average> <burst>]] [oam <seconds>] [inarp [<minutes>] [random-detect [<group_name>]


Per-VC WRED CLI

WRED parameters bound to a VC:

show queueing red int <atm_subinterface> [vc [[<vpi>/]<vci>]]

Queuing statistics of an ATM PVC:

show queueing int <atm_subintf> [vc [[<vpi>/]<vci>]]


IPATMCOS-Ph1 CLI

• Cf “IPATMCoS-Ph1” Design Guide


Per-VC WRED CLInf-7505-1# show runinterface ATM1/1/0.47 point-to-point atm pvc 47 0 47 aal5snap 10 10 1 random-detect wredgroup1

nf-7505-1#show queueing redVC 0/47 -random-detect group default:exponential weight 9precedence min-threshold max-threshold mark-probablity---------------------------------------------------------------0: 20 40 1/101: 22 40 1/102: 24 40 1/103: 26 40 1/10


Per-VC WRED CLI

7513-1-31#sh queueing int atm 11/0/0.103 VC 5/103

ATM11/0/0.103 queue size 83 packets output 1345843, drops 1590472 WRED: queue average 82 weight 1/512, max available buffers 1021 Precedence 0: 40 min threshold, 81 max threshold, 1/10 mark weight 1344366 packets output, drops: 134304 random, 1456168 threshold Precedence 1: 45 min threshold, 81 max threshold, 1/10 mark weight (no traffic) Precedence 2: 50 min threshold, 81 max threshold, 1/10 mark weight (no traffic) Precedence 3: 55 min threshold, 81 max threshold, 1/10 mark weight (no traffic)

IP ATM COS-Ph2: Bundle

• A single Bundle routing neighborship!

• Flexible IP CoS mapping to VCs

• RED (WRED) runs on each VC [email protected]’98 17© 1998, Cisco Systems, Inc.

VC2: ABR

VC1: VBR-nrtPrec: 5 - 7

Prec: 0 - 4

1! IGP neighborship


Precedence to VC Mapping

• Mapping of precedence to VCs – 1 Precedence to 1 VC

– Several Precedences to 1 VC

Prec: 5 - 7

Prec: 0 - 4 VC2: ABR

VC1: VBR-nrt


VC Provisioning

• VCs are dimensioned based on expected load for the precedence(s) level transported on that VC

• More isolation between classes

• At the expense of – less statistical multiplexing,

– more complex provisioning/engineering

VC2: ABR ??? PCR, MCR

VC1: VBR-nrt ??? SCR, PCR, MBS


VC Bundle Mgnt

• Two Modes:

– Protected VC rule : when a protected VC goes down, the bundle goes down

– Protected group rule : when all members in the protected group fail, the bundle is delared DOWN

–When a bundle is declared down, no traffic is forwarded out of the bundle (EVEN some VCs are still up).


Bumping

• VC bumping: possibility for a traffic mapped to a VC X to be forwarded onto another VC Y, in case of failure of X.

–Implicit bumping rule : Y is the next lower precedence level VC is selected,

–Explicit bumping rule : Y is explicitely specified.


Bumping (Cont.)

• Traffic is restored to the original VC when it comes back.

• « Reject Bumping »: It is possible for a VC to be configured not to accept the bumped traffic

• When no alternate VC for some bumped traffic, the bundle will be declared down.


Bumping (Cont.)

• To prevent from declaring a bundle DOWN due to the failure of the lowest precedence VC, explicit bumping should be configured on the lowest precedence.

• Should be used in conjunction with the protected group rule

• If the VC which carries the bumped traffic fails also, the traffic will follow the bumping rules specified for that VC.


Bundle example

TOS 6-7 <-> VC 1 - ATM VBR-nrtProtected VC

TOS 4-5 <-> VC 2 - ATM VBR-nrtProtected Group- bump explicit 7

TOS 0-1 <-> VC 4 - ATM UBR Protected Group

TOS 2-3 <-> VC 3 - ATM VBR-nrtProtected Group - bump implicit


VC1 Failure

Protected VC


VC2 Failure

Explicit bumping


VC3 Failure

Implicit bumping


VC2 & 3 & 4 Failures

Protected group


CLI details

• Cf “atmvcbundle.doc” or Manuals


IP ATM COS Roadmap

• Phase 1 - Per-VC WRED (single VC)–Cisco 7500 (VIP2-50/PA-A3)

–FCS since 11.1(22)CC

• Phase 2 - Precedence Mapping (multiple VC)– Cisco 7200 (NPE-200/PA-A3)

– Bundle Management

– 12.0(3)T FCS 1Q99 (planned)*

• Phase 3 - Per-VC WFQ– Per-VC WFQ


IP ATM COS Summary • IP gateway uses/conforms to ATM

service contract (ATM QoS)

• Queues are developed in router where intelligent decisions can be made (IP QoS)

• Does not requires any proprietary features onto ATM switches

Still OVERLAY!


Agenda

• IP COS over ATM

• IP COS over MPLSIP COS over MPLS



• Conclusion


Agenda

• IP COS over ATMIP COS over ATM





What is Tag/MPLS COS ?

ConventionalRouter

Tag EdgeRouters

ATM-TSR

Frame-TSR

Tag

Non-Tag

Non-Tag

IP Diff-Serv COSend-to-end

Support of Consistent IP Diff-Serv Classes Support of Consistent IP Diff-Serv Classes of Service end-to-end when part of theof Service end-to-end when part of the

network is running MPLSnetwork is running MPLS


MPLS CoS: 3 steps

• Step1: NON-MPLS

– CAR/QPPB/CiscoAssure

– WFQ/WRED

MPLSIPv4 IPv4STEP1

STEP2

STEP3


MPLS CoS: 3 steps

• Step2: Label Imposition

– LER sets MPLS CoS bits = IPv4 Prec; or

– CoS is associated with label via LDP

IPv4 Packet MPLS Hdr

Prec: xyz Prec: xyzMPLS CoS: xyz

Non-MPLS Domain

MPLS Domain

0 1 2 30 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 | CoS |S| TTL |


MPLS CoS: 3 steps

• Step2: Label Imposition

– LER sets MPLS CoS bits = IPv4 Prec; or

– CoS is associated with label via LDP

IPv4 Packet

Prec: xyz

P/p CoS1 17

P/p CoS2 22

P/p CoS3 25

P/p CoS4 12

Dest-CoS Label

0 1 2 30 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 | UUU |S| TTL |


MPLS CoS: 3 steps

• Step 3: DiffServ inside MPLS domain based on MPLS-CoS field or CoS associated with Label

– 3a: Frame MPLS CoS

– 3b: ATM MPLS CoS


Frame MPLS CoS

• Straightforward!!!

• Same Mechanisms as IP CoS

• Class Marker

– MPLS CoS instead of Precedence; or

– MPLS Label instead of Precedence

• Undistinguishable from IPv4 DiffServ


ATM MPLS CoS

• Great Opportunity!

• Peer Model instead of Overlay

– IP intelligence at every hop

– IP-friendly mech. on ATM switches!

• Diffserv instead of per-VC ATM QoS

– Superior Resource Utilisation

– Simpler Resource Allocation


Peer vs Overlay

Overlay Model:IP Intelligence

Around

Peer Model:IP Intelligence

at every hop


Agenda

• IP COS over ATM


• MPLS CoS over ATMMPLS CoS over ATM


• Conclusion


Challenges

• No CoS field in ATM cells

• No WRED in switches

– WFQ is often available in atm switches under the form of a WRR implementation


Two Modes

• Single LSP in ABR mode

• Multi-LSP in TBR mode

– Each has advantage and drawbacks

TBR: Tag Bit Rate: ATM service category designed for Differv/MPLSTBR: Tag Bit Rate: ATM service category designed for Differv/MPLS


Single `VC’ ABR mode

• Extention of “IPATMCoS” feature

• ABR control algorithms are enabled on LSPs

• ATM-LSRs push congestion towards edge LSRs

• Edge-LSRs: WRED/WFQ per-LSP queues

ABR TSP

ATM TSR


Single VC ABR mode

• ATM-LSR Scheduling = per-VC ABR

• ABR parameters:

– MCR is effectively zero (to avoid loss/blocking)

– “Relative bandwidthRelative bandwidth” parameter carried by TDP and used by ABR algorithm


Single VC ABR: Example

A

B

London Paris

KleinStadt

Tarifa

• Equal sharing of link A-B is not always desirable:– Configure relative bandwidth on router-pair basis,

e.g. Tarifa-KleinStadt = 1; London-Paris = 100

• Resource Allocation :– Sharing of Bandwidth across Edge Pairs via “Relative BW” on a per

TSP basis

– Sharing of Bandwidth across COS performed through WRED on Edge

Per VCABR


Multi-VC TBR mode

• Up to 4 parallel TSPs for the same prefix

• CoS <--> TSPs mapping

• Optional setting of CLP for some CoS

Parallel TBR TSPs

ATM TSR

Control Plane


Multi-VC TBR mode

• Edge ATM-LSR: per CoS WFQ + per CoS WRED

• ATM-LSR: per CoS WFQ + per CoS WEPD

Parallel TBR TSPs

ATM TSR

CoS Mechanism in cell Data path


Multi-VC TBR mode: Example

• Queuing on all links is per-class WFQ (not per TSP)

• Resource allocation – Assign weight to each class on per-link basis

(e.g. Premium gets 80% of link, Standard gets 20%)– Choice of weights based on expected load & desired

performance PER CLASS– No per-router-pair configuration (config independent of

topology & geography)

Per COSWFQ


Multi-VC TBR Mode: Example

• EPD is not RED, but...

• EPD thresholds can be set to different levels for different classes ---> WEPD

• Threshold scaling ensures that buffers are not wasted

–allocation to each class decreases as total free buffer space decreases


Single-ABR vs Multi-TBR

• Multi-VC TBR Mode:– Congestion managed directly at every hop (IP and ATM hops)

– Possible Discard at every hop

– Resource Allocation per COS per link; does not have to concern itself with topology and geography

• Single-VC ABR:– No Loss in the ATM fabric

– Discard possible only on the Edge performed by Routers

– Resource Allocation optionally per Pair of Edge Routers. Sharing of bandwidth across COS indirect via WRED profiles


ATM MPLS CoS: other cases

• MPLS CoS over ATM-Forum PVC’s

• MPLS CoS over MPLS VP


Tag over ATMF/ITU-T ATM PVC

• Generic Frame MPLS CoS Case!– A Frame TSR use “normal” ATM PVC with chosen ATM QoS– Perform all Service Differentiation on Frame TSRs at edge of ATM

ATMATM PVCPVC

Tag ATMTag ATM

TDPTDP

ATM Forum ATMATM Forum ATM

TDPTDPTDPTDP

TDPTDP

TSPs


Tag COS over Tag VP Tunnels

• ATM-LSR runs MPLS CoS inside an ATM VPs

• ATM VP is a virtual trunk between L1 and L2

TDPTDP

ATM Forum ATMATM Forum ATM

TDPTDP

ATM VP

Tag Switching

TDPTDP

L1L1 L2L2


Agenda

• IP COS over ATM



• IP QoS for Tag VPNsIP QoS for Tag VPNs

• Conclusion


Tag VPN QoS

• 2 very distinct point of views:

– How the SP will market the service (SLA)

– What are the mechanisms for SP to meet the commitments/SLA

• FR analogy:

– sell 64 kb/s CIR for 99.5% of the time

– reserve 64/overbooking kb/s + admission control + selective discard + …


How to market MPLS VPN CoS?

VPN SP

ECR 128kVPN_A

site 2 ICR 256k

VPN_A site 3

ECR 128k

ICR 256k

ICR 256k

ECR 128k

VPN_A site 4


Proposed SLA for CoS C1

• As long as for each site S of VPN X:

– S sends less than ICR

– S receives less than ECR

• Then:

– loss property is 10^(-n1)

– RTT is < m1 ms


Should offer different CoS!

CoS X: [nx, mx], price Px

Gold: [-10, 100ms], $$$

Silver: [-8, 200ms], $$

BE: [be, be], $


• Should not be marketed as Frame Relay QoS:

– N1 kb/s guaranteed from Site 1 to Site 2



– …

• Layer 2 based VPNs (ie FR or ATM) address that need

How it should not be marketed


How to meet SLA

• Enforcement of ICR:– CAR: policing in/out of profile

• MPLS CoS in the SP’s backbone– single-ABR, multi-TBR mode

– DiffServ engineering

– Per-Class LSP Traffic Engineering in the backbone

• Enforcement of ECR


DiffServ Engineering

• Scalability: no per-VPN QoS in BB

• Per-Class Scheduling/Discarding at every hop

• Resource Allocation based on ICR/ECR sold– share each trunk between different Classes – start conservative– then monitor traffic per class and fine tune– Optimise with per-class Traffic Engineering– Cisco Service Management tool for Tag VPN QoS provisioning


Per-VPN WFQ

• For ATM-ABR model or ATMF PVC

• Scalability: only at edge!

VPN_1VPN_1 Per VC Q on Tag ABR-VC to Remote PE Per VC Q on Tag ABR-VC to Remote PE

Per VPN WFQ

Per COSWRED

PEPEATM Tag BackboneSingle-VC ABR Mode

VPN_2VPN_2

VPN_3VPN_3


MPLS VPN CoS: Sum up

• Frame, single LSP

• ATM, single-ABR mode

• ATM, multi-TBR mode

• ATM, ATM-Forum/ITU pvc


Frame, single LSP

VPN_A VPN_A

VPN_A

VPN_BVPN_B

10.2

10.1

11.5

11.6PE

PE

P P

PPPE 3

PE 4

CE

CE

CE

CE

-2 PE: Single TSPper COS Scheduling& Discard

-4- non Tag COSon output:WRED, TS

-3-P: Single TSPper COS

Scheduling/Discard

COS_0

COS_1

COS_7

Per COS WFQ

Per COSWRED

-1-CAR:Mark in-profile (eg

Silver VPN)Mark out-profile

(Optionally Mark per application, per user…)

Per COS WFQ

Per COSWRED


ATM, single-ABR mode

VPN_A VPN_A

VPN_A

VPN_BVPN_B10.210.2

10.1

11.5

11.6

PE

PE

P P

PPPE 3

PE 4

CE

CE

CE

CE




-2- PE Scheduling& Discard


VPN_1

VPN_2

VPN_N

Per VC Q(to PE 3)

Per VPN WFQ

Per COSWRED

VPN_1

VPN_2

VPN_N

Per VC Q(to PE 4)

Per VPN WFQ

Per COSWRED

-3- ABR TSP

Per VC Queuing,“Relative Relative BandwidthBandwidth” usedto apportion bandwidthacross competing ABR VCs


ATM, multi-TBR

VPN_A VPN_A

VPN_A

VPN_BVPN_B10.210.2

10.1

11.5

11.6PE

PE

P P

PP PE 3

PE 4

CE

CE

CE

CE

-2 PE Scheduling& Discard


-3- TBR Multi-VC

Per Class WFQ

COS_0

COS_1

COS_7

Per COS WFQ

Per COSWRED




Per COSDynamicWEPD


ATM, ATM-forum/ITU PVC

VPN_A VPN_A

VPN_A

VPN_BVPN_B10.210.2

10.1

11.5

11.6PE

PE PE 3

PE 4

CE

CE

CE

CE




-2- PE Scheduling& Discard


VPN_1

VPN_2

VPN_N

Per VC Q(to PE 3)

Per VPN WFQ

Per COSWRED

VPN_1

VPN_2

VPN_N

Per VC Q(to PE 4)

Per VPN WFQ

Per COSWRED

-3- ATM Forum/ITU-T ATM PVC (CBR, VBR,

ABR)

“Normal”ATM Forum/ITU-T scheduling/discarding (CBR, VBR, ABR)

Non-Tag CapableATM Switches


Agenda

• IP COS over ATM




• ConclusionConclusion


IP COS over ATM: Conclusions

• IP is the end2end QoS enabler

–Applications are running on IP, and Networks are constituted of diverse media's. Therefore QoS end-to-end has to be provided by IP

• DiffServ model for IP CoS

–IETF’s Differentiated Services is an extremely scalablescalable COS model and is likely to become widespread



• IP Diff-Serv’s CoS over ATM:

– Overlay: IOS “IP ATM COS “

– Peer: MPLS COS ATM-LSR’s: IP controlled and IP QoS aware

tighter IP/ATM integration



• Perfect illustration: MPLS VPN’s

– Scalability of Diff-Serv COS

– Several SLA’s (Gold, Silver, BE)

– integration IP & ATM

Documents

1 IP/MPLS QoS over ATM. 2 Clarence Filsfils [email protected] Tech. Consulting - EMEA