IP QoS Architecture Highlighting a Direction Rodrigo Linhares - rlinhare@cisco.com Consulting Systems Engineer 1
Agenda Objective IntServ Architecture DiffServ Architecture Some additional tools Conclusion 2
Objective 3
Objective To highlight the architectural foundation for SP IP/MPLS QoS architectures Not to detail low-level details Highlight the sibling link with ATM QoS 4
QoS building block 5
QoS Building Block - Concepts This is GENERAL to any management of a shared resource under congestion! Applies EQUALLY to ATM FR IP MPLS road-traffic on a highway 6
QoS Building Block Admission Control the ability to check if resources are available, allocate them for a specific request if available, issue a NO! if not available IP/MPLS: RSVP ATM: PNNI 7
QoS Building Block Policing/Shaping enforcing a certain temporal profile to a certain traffic stream Eg. IP: GTS, ATM shaping, FR shaping, lights at highway entrance 8
QoS Building Block Scheduling the ability to dequeue packets out of queue in an order that fits a certain objective eg: FIFO, PQ, FBWFQ, CBWFQ 9
QoS Building Block Drop Algorithm The ability to drop packets out of a queue according to a certain objective as a function of > queue population > importance/urgency of the packet > Eg. Tail-Drop, RED... 10
QoS building Block Packetization Delay Reduction ability to reduce the effect of the serialization of a large packet when urgent packets sit in the queue Eg. ATM: small cell size Eg. IP: LFI, FRF12 11
QoS Building Block ATM, IP, MPLS, FR, highway control ALL those cook have the same ingredients to prepare a QoS meal 12
Integrated Services 13
Integrated Services Aka IntServ or IS Per-Flow end-to-end Service Guaranteed (aka GS), RFC 2212 Controlled-Load (aka CL), RFC 2211 14
Integrated Services Need to program the appropriate QoS building blocks in the nodes along the flow path Admission Control Policing, Scheduling, Dropping Link-Layer QoS mapping Hop-by-hop Setup NMS, RSVP... 15
Guaranteed Service Guaranteed service provides assured level of bandwidth no queueing loss for conformant flow firm (mathematically provable) bounds on endto-end datagram queueing delays (called Qd) Application: interactive, real-time 16
Applications Cisco DLSW Cisco VoIP ports Cisco Multimedia Conference Manager (MCM) for H.323 video conferencing. Cisco IP phones Microsoft's Netmeeting uses RSVP to request quality of service for its audio and video flows 17
Deployment status Important in Enterprise arena for SNA (via RSVP/DLSW) VoIP Inexistant in SP arena 18
Why inexistant in SP arena? Because IntServ relies on per-flow Admission Control, policing and scheduling SP core millions of flows per seconds each flow lives on average 15 packets Unscalable 19
Would another shared resource better behave? What if we replace an IP micro-flow by an ATM vc, a FR dlci, an MPLS LSP Would this technology handle 10^6 vc/dlci/lsp per second with an average life time of 15 packets? NO! The problem is not inherent to the shared resource (IP, ATM, FR, MPLS ) It is inherent to the SP core context Millions of flows Average life of a flow: 15 packets 20
How to deal with that SP core context Aggregation lesser number of flows longer average life 21
The way towards Aggregation First and fundamental step Differentiated Services Architecture Second Complementary steps Aggregate Admission Control 22
Differentiated Services 23
Differentiated Services Motivation Scalability Aggregation High resource utilization Network-wide SLA monitoring as trigger for admission control capacity planning 24
Application Enterprise Arena In conjunction with Policy Networking SP Arena For MPLS-VPN s: several large networks already announced and deployed VoIP 25
Conclusion DiffServ is the fundamental architecture for an SP QoS design scalability, aggregation, resource utilization It relies on network-wide SLA monitoring Tactical & Strategical Capacity Planning 26
SLA Monitoring Service Assurance Agent MIB 27
Service Assurance Agent Agent in IOS (formerly known as RTR) Track One-Way Delay, Jitter, Loss Server reponse time: FTP/HTTP Service response time: DNS/DHCP 28
Management VPN Solution Center retrieves the information from the RTR MIBs and produce reports IPM: Internetwork Performance Mgr Third-Party: NetworkHealth from Concord Infovista... 29
Some other tools to use with DiffServ 30
Some further tools To increase the resource utilization MPLS Traffic Engineering To speed up convergence upon link or node failure MPLS TE and Link/Note protection To integrate IP and ATM QoS IP-ATM QoS mapping 31
Traffic Engineering: Motivations The efficacy with which one uses the available bandwidth in the transmission fabric directly drives the fundamental manufacturing efficiency of the business and its cost structure. Mike O Dell UUnet, November 17, 1996 32
Traffic Engineering: Motivations Reduce the overall cost of operations by more efficient use of bandwidth resources by preventing a situation where some parts of a service provider network are over-utilized (congested), while other parts under-utilized The ultimate goal is cost saving! 33
Traffic engineering R2 R3 R1 IP routing: destination-based least-cost routing Path for R2 to R3 traffic Path for R1 to R3 traffic under-utilized alternate path 34
Traffic engineering R2 R3 R1 IP routing: destination-based least-cost routing Path for R2 to R3 traffic Path for R1 to R3 traffic under-utilized alternate path 35
Routing solution to Traffic Engineering R2 R3 R1 Construct routes for traffic streams within a service provider in such a way, as to avoids causing some parts of the provider s network to be over-utilized, while others parts remain underutilized 36
Tool availability IP/MPLS: MPLS Traffic Engineering deployed since May99 ATM Traffic Engineering PNNI 37
Relationship with DiffServ This interworks with DiffServ This is useful when the network load does not match adequately the installed resources 38
Some further tools To increase the resource utilization MPLS Traffic Engineering To speed up convergence upon link or node failure MPLS TE and Link/Note protection To integrate IP and ATM QoS IP-ATM QoS mapping 39
Link/Node Protection MPLS Traffic Engineering allows to route an LSP around a failed link or node in less than 50ms Typical ISIS convergence: 1 minute Extremely important for VoIP commercial service! 40
Fast ReRoute (aka Link Protection) 41
Terminology Link Protection In the event of a link failure, an LSP is rerouted to the next-hop using a preconfigured backup tunnel 42
Static backup Tunnel R8 R9 R2 R4 R1 Pop R5 17 R6 R7 22 Setup: Path (R2->R6->R7->R4) Labels Established on Resv message 43
Routing prior R2-R4 link failure R8 R9 R4 R2 Pop R1 37 14 R5 R6 R7 Setup: Path (R1->R2->R4->R9) Labels Established on Resv message 44
Link Protection Active R8 R9 R2 R4 R1 R5 R6 R7 On failure of link from R2 -> R4, R2 simply changes outgoing Label Stack from 14 to <17, 14> 45
Fast ReRoute Node Protection 46
Overview R8 R9 R3 R4 R2 R1 R5 R6 R7 Backup Tunnel to the next-hop of the LSP s next-hop 47
How to detect R3 s failure? A node may fail while the link is still up A node s linecard processes might survive, a main process failure (freeze of the RP process) 48
Relationship with DiffServ InterWork with DiffServ This is useful when the services supported cannot cater a network convergence of a few seconds 49
Some further tools To increase the resource utilization MPLS Traffic Engineering To speed up convergence upon link or node failure MPLS TE and Link/Note protection To integrate IP and ATM QoS IP-ATM QoS mapping 50
IP+ATM QoS Alternatives MPLS CoS - two representative examples IP service classes implemented on each LSR >ABR (Available Bit Rate) model >Multiple LVC (Label Virtual Circuit) model 51
Utilizing ATM ABR in an IP Service CAR: Bandwidth Policy Edge CAR: Packet Classification WRED ABR LVC ATM I/F Gold Silver Bronze Operation ABR Feedback Loop One label per destination (in SP network) One ABR LVC for all service classes Core: ABR pushes congestion to the edge Edge: WRED creates distinct classes ABR provides congestion notification directly to IP queues without an end-to-end PVC Prefix Label 128.89 10 129.45 354 52
Multiple LVC Model Edge CAR: Bandwidth Policy CAR: Packet Classification WRED Gold Silver Bronze Operation Multiple labels per destination (one LVC for each class) Edge: CAR classifies packets WRED per interface Class-based Weighted Fair Queuing Core: Class-based WFQ No end-to-end VCs required Class Based Queuing Prefix Class Label 128.89 1 1217 128.89 2 1218 128.89 3 1219 53
Conclusion 54
SP QoS Architecture IP/MPLS as multiservice transport infrastructure DiffServ technology to support VoIP, Virtual LL Business, BE 55
SP QoS architecture DiffServ Technology enhanced with optional interworking tools MPLS TE: higher resource utilization MPLS TE Fast Reroute: link/node protection within 50ms IP-ATM QoS mapping 56
Presentation_ID 57