IP/MPLS QoS over ATM TO DO:

IP/MPLS QoS over ATM TO DO:
tests 11.1(14.5)CA has ACL features CSCdjCSCdj42989 test an SSE to see if different behavior test aggressive to see if the random drop is there even on a not SSE platform example section 1

Clarence Filsfils Tech. Consulting - EMEA 2

Agenda IP COS over ATM IP COS over MPLS MPLS CoS over ATM
IP QoS for Tag VPNs Conclusion

IP COS over ATM: Overlay Model
How do I map the two worlds ??? ATM Backbone: ATMF/ITU-T Qos mechanisms Per Connection Qos Very strict Qos Traffic classes: CBR, VBR, VBR-RT, UBR, ABR Traffic Parameters: PCR, MCR, SCR,.. IP Layer: Diff-Serv Mechanisms Connectionless Per packet precedence (DS-byte) indicating “priority” for each packet limited number of COSs

IOS “IP ATM COS”: Principles
Router’s traffic must be compliant with respect to ATM service contracted The ATM service contracted must be provided! (at least, loss less!)

IOS “IP ATM COS”: Principles
Congestion pushed back at the edge per-VC IP Queue develops IP-intelligent QoS Mechanisms in the router Because: ATM switch does not understand 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

Distributed VIP2 Architecture
Distributed Switching Distributed Services Distributed WRED/WFQ Route Switch Processors i Packet Memory Port Adapter P C I C y B u s P C I Port Adapter xIP VIP2 xIP VIP2 VIP2 Switch Processor Cisco 7500

ATM PA-A3 Architecture DS E OC3c/STM1 MM OC3c/STM1 SM-IR OC3c/STM1 SM-LR Single-wide port adapter for Cisco 7200/7500 SAR PCI Per-VC Queues/ Traffic Shaping ATM Shaping: CBR, VBR, ABR (all 3 modes) and UBR High-performance SAR

Per-VC WRED : Intelligent IP Packet Discard
Traffic Shaping Threshold Exceeded VIP2-50 PA-A3-XX VC1 VC2 VC3 No discard on PA Per-VC WRED: Intelligent Discard Per-VC Queues

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: To activate a WRED profile on a PVC:
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 CLI nf-7505-1# show run
interface ATM1/1/0.47 point-to-point atm pvc aal5snap random-detect wredgroup1 nf #show queueing red VC 0/47 - random-detect group default: exponential weight 9 precedence min-threshold max-threshold mark-probablity 0: /10 1: /10 2: /10 3: /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 , drops WRED: queue average 82 weight 1/512, max available buffers 1021 Precedence 0: 40 min threshold, 81 max threshold, 1/10 mark weight packets output, drops: random, 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 Precedence 3: 55 min threshold, 81 max threshold, 1/10 mark weight

IP ATM COS-Ph2: Bundle 1! IGP neighborship Prec: 5 - 7 VC1: VBR-nrt
VC2: ABR Prec: 0 - 4 A single Bundle routing neighborship! Flexible IP CoS mapping to VCs RED (WRED) runs on each VC queue 942 NW’98 © 1998, Cisco Systems, Inc. 17

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 VC1: VBR-nrt VC2: ABR

VC Provisioning VC1: VBR-nrt ??? SCR, PCR, MBS VC2: ABR ??? PCR, MCR 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

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-nrt Protected VC
TOS 4-5 <-> VC 2 - ATM VBR-nrt Protected Group- bump explicit 7 TOS 2-3 <-> VC 3 - ATM VBR-nrt Protected Group - bump implicit TOS 0-1 <-> VC 4 - ATM UBR Protected Group

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 Still OVERLAY!
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!

IP QoS for Tag VPNs

network is running MPLS
What is Tag/MPLS COS ? Support of Consistent IP Diff-Serv Classes of Service end-to-end when part of the network is running MPLS Conventional Router Tag Edge Routers ATM-TSR Frame-TSR Tag Non-Tag IP Diff-Serv COS end-to-end

MPLS CoS: 3 steps Step1: NON-MPLS CAR/QPPB/CiscoAssure WFQ/WRED MPLS
IPv4 STEP2 STEP1 STEP3 Step1: NON-MPLS CAR/QPPB/CiscoAssure WFQ/WRED

MPLS CoS: 3 steps Step2: Label Imposition
| Label | CoS |S| TTL | Step2: Label Imposition LER sets MPLS CoS bits = IPv4 Prec; or CoS is associated with label via LDP IPv4 Packet MPLS Hdr Prec: xyz MPLS CoS: xyz Non-MPLS Domain MPLS Domain

MPLS CoS: 3 steps Step2: Label Imposition
| Label | UUU |S| TTL | Step2: Label Imposition LER sets MPLS CoS bits = IPv4 Prec; or CoS is associated with label via LDP IPv4 Packet Prec: xyz P/p CoS P/p CoS P/p CoS P/p CoS Dest-CoS Label

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

IP Intelligence Around IP Intelligence at every hop
Peer vs Overlay Overlay Model: IP Intelligence Around Peer Model: IP Intelligence at every hop

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/MPLS

Single `VC’ ABR mode Extention of “IPATMCoS” feature
ABR TSP ATM TSR 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

Single VC ABR mode ATM-LSR Scheduling = per-VC ABR ABR parameters:
MCR is effectively zero (to avoid loss/blocking) “Relative bandwidth” parameter carried by TDP and used by ABR algorithm

Single VC ABR: Example KleinStadt B London Paris A Per VC ABR 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

Multi-VC TBR mode Up to 4 parallel TSPs for the same prefix
Control Plane Parallel TBR TSPs ATM TSR Up to 4 parallel TSPs for the same prefix CoS <--> TSPs mapping Optional setting of CLP for some CoS

CoS Mechanism in cell Data path
Multi-VC TBR mode CoS Mechanism in cell Data path Parallel TBR TSPs ATM TSR Edge ATM-LSR: per CoS WFQ + per CoS WRED ATM-LSR: per CoS WFQ + per CoS WEPD

Multi-VC TBR mode: Example
Per COS WFQ 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)

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
Tag ATM TDP ATM Forum ATM TSPs 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 Does not yield the Tag benefits inside the ATM fabric but useful for migration scenario and to leverage legacy-ATM The Frame TSR sees the pipe as a “Frame Interface” (as opposed to a a Tag ATM interface): Many TSPs can be multiplexed over the ATM PVC TDP runs between the Frame TSRs at both ends of ATM PVC; TDP is not seen by ATM switches; Tags are allocated between Frame TSRs Router complies to ATM traffic contract eg CBR,VBR, ABR shaping Key idea: A Frame TSR use “normal” ATM PVC as a lossless Pipe Perform all Service Differentiation on Frame TSRs at edge of ATM Router complies to ATM traffic contract ie CBR, VBR, ABR shaping Packets wait in per-VC queue when arrival rate > VC rate WRED per Tag COS inside per-VC queue offers drop prioritisation If TER is Tag VPN PE, then Optional WFQ per VPN inside per-VC queue

Tag COS over Tag VP Tunnels
TDP ATM Forum ATM ATM VP Tag Switching L2 L1 ATM-LSR runs MPLS CoS inside an ATM VPs ATM VP is a virtual trunk between L1 and L2

Tag VPN QoS 2 very distinct point of views: FR analogy:
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 128k VPN_A site 2 ICR 256k VPN_A site 3 VPN_A site 4 Each VPN site has an Ingress Committed Rate (ICR) to VPN and an Egress Committed Rate (ECR) from VPN As long as for each Site S: traffic sent by Site S to VPN is below its ICR Aggregate traffic received by Site S from all the other sites together is below S’s ECR then, traffic will be “committed” with loss probability <10-n, delay<M ms

Proposed SLA for CoS C1 As long as for each site S of VPN X: Then:
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], $

How it should not be marketed
Should not be marketed as Frame Relay QoS: N1 kb/s guaranteed from Site 1 to Site 2 N2 kb/s guaranteed from Site 1 to Site 3 N3 kb/s guaranteed from Site 2 to Site 3 … Layer 2 based VPNs (ie FR or ATM) address that need

How to meet SLA Enforcement of ICR: MPLS CoS in the SP’s backbone
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 Commitment to VPN is made based on: Tag COS Network-Engineering/Provisioning based on Diff-Serv Network Engineering (ie ensure that each COS will offer its corresponding Qos commitments) Resource Allocation based on ICR/ECR sold Statistical information about traffic, load, loss/delay commitments by precedence (measurement, history,..) Routing information and/or Tag Traffic Engineering and RRR Cisco Service Management tool for Tag VPN (Qos) Provisioning optionally per VPN WFQ (in ABR Tag COS model and in Tag COS over ATM PVC model) Tag VPN QoS Model does not require per-VPN QoS scheduling in core (Scalability) Tag VPN QoS Model relies on Diff-Serv mechanisms: VPN traffic is marked into one of the VPN Classes Admission Control is performed in ingress for every VPN class at every VPN site Differentiated Scheduling/Discarding performed at every hop and Resource Allocation based on “contracted bandwidths” to satisfy QoS parameters of each Class (loss probability, delay, jitter,…) Any VPN traffic inside contract will experience the committed QoS for corresponding Class Assumes correct Resource Allocation start conservative frequent measurements easier with Egress Committed Rate (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 PE For ATM-ABR model or ATMF PVC
Per VC Q on Tag ABR-VC to Remote PE Per VPN WFQ Per COS WRED PE ATM Tag Backbone Single-VC ABR Mode VPN_2 VPN_3 For ATM-ABR model or ATMF PVC Scalability: only at edge! In case of ATM-ABR model or ATM-PVC, optional per-VPN WFQ scheduling per-VPN WFQ inside (shared) ABR-VC per-VPN WFQ Weight configurable or defaulted to Sum of VPN-site bandwidth only requires per-VPN WFQ scheduling on edge (scalable)

MPLS VPN CoS: Sum up Frame, single LSP ATM, single-ABR mode
ATM, multi-TBR mode ATM, ATM-Forum/ITU pvc

Frame, single LSP -4- non Tag COS on output: WRED, TS -1-CAR:
VPN_A VPN_B 10.2 10.1 11.5 11.6 PE P PE 3 PE 4 CE -2 PE: Single TSP per COS Scheduling & Discard -4- non Tag COS on output: WRED, TS -3-P: Single TSP per COS Scheduling/Discard COS_0 COS_1 COS_7 Per COS WFQ Per COS WRED -1-CAR: Mark in-profile (eg Silver VPN) Mark out-profile (Optionally Mark per application, per user…) Per COS WRED

ATM, single-ABR mode Per VC Queuing, “Relative Bandwidth” used
VPN_A CE 11.5 VPN_B 10.2 -4- non Tag COS on output: WRED, TS CE P P PE PE 3 VPN_A CE P P VPN_A 11.6 10.1 PE 4 CE PE -1-CAR: Mark in-profile (eg Silver VPN) Mark out-profile (Optionally Mark per application, per user…) -2- PE Scheduling & Discard -3- ABR TSP Per VC Queuing, “Relative Bandwidth” used to apportion bandwidth across competing ABR VCs Per VPN WFQ VPN_1 Per VC Q (to PE 3) Per COS WRED VPN_2 VPN_N Per VPN WFQ VPN_1 Per COS WRED Per VC Q (to PE 4) VPN_2 VPN_N

ATM, multi-TBR -4- non Tag COS on output: WRED, TS -1-CAR:
VPN_A VPN_B 10.2 10.1 11.5 11.6 PE P PE 3 PE 4 CE -2 PE Scheduling & Discard -4- non Tag COS on output: WRED, TS -3- TBR Multi-VC Per Class WFQ COS_0 COS_1 COS_7 Per COS WFQ Per COS WRED -1-CAR: Mark in-profile (eg Silver VPN) Mark out-profile (Optionally Mark per application, per user…) Dynamic WEPD

ATM, ATM-forum/ITU PVC Per VC Q (to PE 3) Per VC Q (to PE 4)
VPN_A VPN_B 10.2 10.1 11.5 11.6 PE PE 3 PE 4 CE -1-CAR: Mark in-profile (eg Silver VPN) Mark out-profile (Optionally Mark per application, per user…) -2- PE Scheduling & Discard -4- non Tag COS on output: WRED, TS VPN_1 VPN_2 VPN_N Per VC Q (to PE 3) Per VPN WFQ Per COS WRED Per VC Q (to PE 4) -3- ATM Forum/ITU-T ATM PVC (CBR, VBR, ABR) “Normal”ATM Forum/ITU-T scheduling/discarding (CBR, VBR, ABR) Non-Tag Capable ATM Switches

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 scalable 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

IP/MPLS QoS over ATM TO DO:

Similar presentations

Presentation on theme: "IP/MPLS QoS over ATM TO DO:"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

IP/MPLS QoS over ATM TO DO:

Similar presentations

Presentation on theme: "IP/MPLS QoS over ATM TO DO:"— Presentation transcript:

Similar presentations

About project

Feedback