Qualità di servizio in reti IP Tecnologie e Protocolli per Internet II rev 0.8 Andrea Detti Electronic Engineering dept. E-mail: andrea.detti@uniroma2.it Ringraziamenti: devo un ringraziamento al Prof. Nicola Blefari- Roberto Mameli, autori di presentazioni da cui sono state tratte parte delle seguenti slides. Slide 1
Introduzione + Una rete supporta Qualità del Servizio (QoS) se fornisce un trasferimento di informazioni garantendo specifiche prestazioni + I parametri prestazionali di interesse sono: Ritardo medio, massimo, percentile non superato Jitter (RFC 3550) Jitter tra pacchetto i e j, D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si) Con Ri (Si) instante di tempo di ricezione (invio) pacchetto x Stima Jitter --> J(i) = J(i-1) + ( D(i-1,i) - J(i-1))/16 Throughput : banda (bps) end-to-end garantita Packet Loss Rate: probabilità di perdita di pacchetto=rapporto pachetti persi su pacchetti trasmessi + La necessità di avere una garanzia prestazionale su un parametro ed il suo relativo valore garantito dipendono dal tipo di applicazione. Slide 2
Introduzione + La fornitura di QoS su Internet è problematica poiché IP offre un servizio best effort, senza connessione e senza garanzie di affidabilità di consegna del pacchetto (reliability) Non controllo, ovvero il modo di trasferimento è a domanda Internet è caratterizzata da una interconnessione di reti (INTER- NETwork) fortemente eterogenee in termini di prestazioni (e.s. Gigabit Ethernet vs collegamenti diretti a 10 Mbps) La reliability è assicurata per il trasferimento dati dal TCP, ma il TCP non è in grado di assicurare nulla in termini di ritardo, jitter e throughput. Slide 3
Elementi chiave di un framework di QoS + Disciplina di coda (scheduling): Algoritmi e insieme di code (buffer) attraverso i quali un nodo differenzia tra i pacchetti delle sessioni comunicative Linux : qdisc (queue discipline) + Classificatore (Classifier) : Permette ad un nodo di classificare i pacchetti (diretti verso una specifica interfaccia di uscita) in classi di servizio Ogni classe di servizio è servita da una specifica coda Una classe di servizio può essere associata ad una singola sessione comunicativa o a più sessioni comunicative caratterizzate da uno stesso parametro comune (es. Transport Layer == UDP) Linux : filter Slide 4
Elementi chiave di un framework di QoS IP layer + Policer / Shaper Policer: rende il traffico in ingresso conforme agli accordi di QoS stabiliti, eliminando (o riclassificando come best effort) i pacchetti non conformi Shaper: come il policer ma invece di eliminare/riclassificare i pacchetti non conformi, li ritarda in un buffer (finchè può) Linux : ingress qdisc (policer), qdisc (shaper) + Architettura di QoS Definisce e dove gli elementi di cui sopra sono posizionati nella rete e come questi funzionano source shaper policer classifier Sorgente (solo sul primo Forwarding Queue #1 Queue # 2 Queue #3 Nodo di rete (QoS enabled) Scheduler algorithm Slide 5
Scheduling + Il traffico offerto puntuale può temporaneamente superare la capacità + Senza coda questo traffico sarebbe perso + La coda permette di memorizzare di traffico e quindi rilanciarlo successivamente + Lo scheduling definisce quante code per interfaccia e da quale coda prelevare il prossimo pacchetto che deve essere trasmesso + Esempi di scheduler FIFO Priority Queue (PQ) Weighted Round Robin (WRR) Deficit Round Robin (DRR) Generalized Process Sharing (GPS) Weighted Fair Queueing (WFQ) Hierarchy Token Bucket (HTB) Slide 6
FIFO + Strategia di coda più semplice (basso processing) ed utilizzata di default + Si trasmettono i pacchetti seguendo di arrivo (a meno di perdite) + Un elevato carico può aumentare molto il ritardo di coda compromettendo comunicazioni interattive + Molto spesso le implementazioni gestiscono lo spazio di memoria dedicato ad una FIFO su base pacchetto invece che su base byte, poichè vi è una forte semplificazione sul processing (es. circular buffer) Nel caso di packet-based la memoria è suddivisa in blocchi pari al Maximum Packet Size ed uno ed un solo pacchetto è memorizzato in un blocco con un possibile spreco di memoria Slide 7
Prestazioni di una coda FIFO + Le prestazioni di una coda FIFO peggiorano drasticamente quando il carico (bitrate offerto/bitrate linea) supera una certa soglia + Questa soglia dipende dalla burstiness del traffico in ingresso La burstiness misura insieme i pacchetti arrivano Burstiness = 0 significa pacchetti equispaziati, cioè traffico CBR Burstiness grande significa che i pacchetti spesso arrivano insieme e poi silenzio Un burstiness elevata si ha quando il traffico in ingresso è molto correlato temporalmente (long range dependence --> la funzione di autocorrelazione non è sommabile) Il traffico Internet segue un comportamento di tipo self-similar e long range dependent Avg. Queue length burstiness Interface load 10 % 50 % 100 % + Maggiore è la burstiness del traffico, più bassa è la soglia, ovvero peggiori le prestazioni + OVERPROVISIONING Per assicurare basso ritardo, il carico deve essere fortemente limitato (es. 50 %) Slide 8
Self-Similar Le caratteristiche statistiche sono invariati (a meno di un fattore moltiplicativo) alla scala di osservazione Frattale Traffico Slide 9
Self-Similar vs Poisson Slide 10
Ottimizzazione FIFO per traffici TCP: Random Early Detection (RED) + Scarto randomico di alcuni pacchetti con probabilita di scarto proporzionale allo stato attuale della coda + Elimina la sincronizzazione delle connessioni TCP grazie alla randomicità delle perdite di pacchetto RED Enabled 1.0 P(drop) maxp MAX-thr MIN-thr MIN-thr MAX-thr qlen-avg Slide 11
Priority Queuing (PQ) Traffic Destined for Interface Classify High Medium Normal Low Interface Hardware Ethernet Frame Relay ATM Serial Link Etc. Transmit Queue Output Line Q Length Defined by Q Limit Interface Buffer Resources Absolute Priority Scheduling High Empty? Y Y Y Y Medium Empty? Normal Empty? Low Empty? N N N N Send packet from High Send Packet from Medium Send Packet from Normal Send Packet from Low Slide 12
Priority Queuing (PQ) - Esempio Due code: una per traffico UDP Traffic (high) e una per traffico TCP (low) Delay FIFO TCP Maximum delay for real-time UDP t Delay PQ TCP UDP t Slide 13
Priority Queuing (PQ) : Problemi + Non un limite superiore alla banda utilizzata dalla classe ad alta priorità + Elevato rischio di per le classi a bassa priorità Slide 14
Weighted Round Robin (WRR) Traffic Destined for Interface Classify 1/10 2/10 3/10 2/10 Interface Hardware Ethernet Frame Relay ATM Serial Link Etc. Transmit Queue Output Line 3/10 Up to 16 Q Length Deferred by Queue Limit Link Utilization Ratio Weighted Round Robin Scheduling Interface Buffer Resources Allocate Proportion of Link Bandwidth Slide 15
Weighted Round Robin (WRR) + Weighted round-robin Differenti pesi w i per coda Coda j può trasmettere w j pacchetti in un ciclo. Ciclo di durata massima pari alla trasmissione di pacchetti w j + Problemi Pacchetti di dimensioni variabili Impredicibilità sull uso della banda Impredicibilita sulla durata dei ritardi Slide 16
Deficit Round Robin (DRR) + Ogni coda ha un deficit counter che memorizza il numero di crediti in bytes ed ha un valore iniziale pari a zero + Si definisce un quantum di bytes da scaricare da una coda prima di passare alla prossima + Ogni volta che si seleziona una coda, provenendo dalla precedente del giro, si incrementa il deficit counter di quantum + Per ogni pacchetto in testa alla coda selezinata, Se la dimensione L è <= deficit counter si trasmette il pacchetto, si decrementa il deficit counter di L Si passa al prossimo pacchetto della stessa coda Altrimenti si passa alla coda successiva. + Se non c nessun pacchetto da trasmettere si azzera il deficit counter (per ottenere fairness) + Facile implementazione + Differenziazione delle classi di servizio attraverso quantum differenti per coda (WDRR) Più grande il quantum, maggiore la percentuale di banda dedicata Slide 17
Deficit Round Robin (DRR) Quantum size : 1000 byte Second Round 2000 1000 First Round 500 1500 300 1200 0 A B C Head of Queue + 1st Round A s count : 1000 B s count : 200 (served twice) C s count : 1000 + 2nd Round A s count : 500 (served) B s count : 0 C s count : 800 (served) Slide 18
Generalized Process Sharing (GPS) + Metodologia ideale: Ipotizzare che si possa inviare una parte infinitesimale di pacchetto (i.e., un singolo bit o un insieme di bit) Round robin fra le code a livello di bit (i.e., ogni bit si passa alla coda successiva). + Politica ideale per la suddivisione equa della banda anche nel breve periodo + GPS non è implementabile è utilizzato principalmente come benchmark + Il numero di bit inviabili per round definisce i rapporti di capacità di trasferimento fra le varie classi di servizio Capacità j t Capacita _ linea * k w j ACTIVE ( t) w k Slide 19
queue size Generalized Process Sharing (GPS) GPS examlpe 1 40 30 20 10 0 A B C time Pacchetti di tre classi di dimensioni 10, 20 & 30 arrivano al tempo 0 e tutte le code hanno un peso pari ad 1 bit Slide 20
Weighted Fair Queueing + Non possiamo implementare il GPS + Pertanto, cerchiamo di emularlo + Si ordinano i pacchetti in base al loro expected virtual departure time del loro ultimo bit, calcolato applicando le regole del GPS + Elevato processing di ordinamento rispetto agli altri approcci, ogni nuovo pacchetto entrante bisogna ordinare di nuovo Slide 21
Scheduling gerarchico + Gli scheduler possono essere organizzati in modo gerarchico. + Gli scheduler foglia prelevano i pacchetti dalle code quando lo scheduler di ordine superiore, a sua volta, preleva un pacchetto da loro S1 WFQ S1.1 S1.2 S1.3 DRR FIFO PQ Slide 22
Flow fair queuing + Garanzie equità (fairness) di servizio ai vari flussi (i.e. sessioni UDP,TCP) + Linux SFQ, Cisco fair-queue Packet in HASH function on socket parameters Queue 1 Queue 2 Fair scheduling (DRR, WFQ, etc) Packet output Queue N Slide 23
Cisco - Low Latency Queuing (LLQ) + Scheduler implementato in molti router Cisco + Utilizzato per fornire basso ritardo ai pacchetti real time e differenziare la capacità rimanente in classi di servizio PQ Costrittore di capacità (Token Bucket) utilizzato per evitare la starvation (interviene solo nei casi in cui la WFQ vuole bandaworkconserving) High priority FIFO Traffico voce WFQ Low priority aka CB-WFQ Traffico dati a diversa priorità Slide 24
Cisco Routers- Scheduling + Strumenti: Policy-map Specifica politiche di trattamento dei pacchetti appartenenti ad una certa classe Scheduling Class (Classifier) CQ-WFQ (class-based WFQ) Si configura la banda di ogni classe LLQ Una classe priority + altre classi in CW-WFQ Marking Shaping Policing Specifica i criteri di matching che definiscono ad una classe Access-List (Classifier e policer) Specifica dei criteri flessibili basati su L3/L4 che definiscono di un pacchetto ad un access group Specifica se accettare o meno questi pacchetti di un pacchetto Slide 25
Cisco Routers- Scheduling gerarchico Policy-map parent class-default Shape 2Mbit/s Service-policy children output fastethernet 1/0 Policy-map children (CBWFQ) VoIP bandwidth 1500 kbit/s Class-default Bandwidth 500 kbit/s Slide 26
Classifier + Classificazione: Esamina il pacchetto e determina in base a delle specifiche regole quale è la coda dello scheduler su cui accodare La classificazione è fatta in base ai campi dei packet headers: Multi Field (MF) Classification: Matching basuato su una tupla del packet header Processing intensivo Granularità fina Behavior Aggregate (BA) Classification Matching basato su un solo campo di un header (e.s., IP protocol type o IP TOS) più semplice e più veloce della MF granularità grossa Interface based Classification Matching basato Slide 27
Policer and Shaper + Sono meccanismi utilizzati per il Traffic control. Limitano dei dati iniettato da una sorgente in accordo ad uno specifico profilo di traffico, concordato durante la richiesta di QoS + I profili di traffico sono spesso definiti in termini di un meccanismo di rate-limiting denominato Token Bucket, che può essere utilizzato sia come policer che come shaper + Shaper: + Policer: Ritarda i pacchetti fuori profilo in modo da rendere il flusso compatibile con il profilo di traffico Uno shaper ideale è un Token Bucket con coda infinita Scarta o declassa i pacchetti fuori profilo Può essere implementato con un Token Bucket con coda nulla Slide 28
Token Bucket Tokens Overflow Tokens r b b r Burst Size (byte) Token Arrival Rate (bit/sec) Packets Arriving Conform Exceed Slide 29
Traffic mask post Token Bucket Amount of transfered bits at time t A(t) r b t Slide 30
Dual Token Bucket + First Token bucket control the average + Second Token bucket control the maximum duration of transmission at peak rate r bit/s p bit/s Policer x b y M Shaper L bytes L x? yes L y? YES: Transfer buffer size NO: Police Action NO: Delay A(T)=min[pt+M, rt+b] Slide 31
Traffic mask post Dual Token Bucket Amount of transfered bits at time t A(t) p r b M (often equal to the maximum packet size) t Slide 32
+ Linux: + Cisco References per laboratorio QoS http://linux-ip.net/articles/traffic-control-howto/classlessqdiscs.html http://linux-ip.net/articles/traffic-control-howto/classfulqdiscs.html http://lartc.org/howto/ http://startccna.blogspot.it/ http://www.cisco.com/en/us/docs/ios/12_2/qos/configuration/guide/ qcfintro.html http://www.cisco.com/en/us/docs/ios/12_2/qos/configuration/guide/ qcfcbshp.html Slide 33
Resource Reservation Framework + Is the set of protocols, mechanisms and devices used to reserve and use bandwidth along a network path + We discuss: Integrated Services Architecture (IntServ) Differentiated Services Architecture (DiffServ) Multi Protocol Label Switching + All of them are based on the concept of Collective pre-assignment (connection oriented) of resources + The first two are integrated in the IP layer; instead MPLS is another layer below IP Slide 34
IntServ Architecture Integrated Service (IntServ) architecture provides: QoS support Multicast support Controlled link sharing Slide 35
Intserv approach An Integrated Services Architecture requires: Traffic Control Mechanisms (Admission Control, Classifier, Scheduler) Reservation Setup Protocol The Intserv is based on the - handling of IP packets (both on User plane and on Control Plane) Direction of data flow Slide 36
IntServ Key Concepts Flow A distinguishable stream of related datagrams that results from a single user activity and requires the same QoS (e.g., a TCP connection or a UDP session) Service Class Specifies the type of service experienced by a flow Currently IntServ Architecture provides 3 Service Classes Best Effort delivery Guaranteed Service Controlled Load Service Slide 37
Traffic Control Mechanisms Admission Control Decides whether accepting a QoS request based on available resources Requires the knowledge of QoS parameters Current state of the network Slide 38
Traffic Control Mechanisms Packet Classifier recognizes the flow to which incoming datagrams belong to the class (i.e. flow or a set of flows) is defined locally and can differ in different network nodes Packet Scheduler schedules incoming datagrams for transmission based on their service class uses queue management and other mechanisms (e.g. timers) may also apply traffic policing and/or shaping Slide 39
IntServ Router Model Routing Protocol Admission Control Background functions Routing DB Reservation Protocol Tr. Ctrl. DB Management Agent Packet Scheduler Inbound link Outbound link Packet Classifier Forwarding Path Slide 40
IntServ Guaranteed Service Guaranteed Service is thought for real time applications with tight delay requirements Guaranteed Service QoS implies assured level of bandwidth mathematically bounded end-to-end delay no queuing losses for conforming packets The applications involved specify both traffic characteristics (Tspec) and reservation characteristics (Rspec) Slide 41
IntServ Guaranteed Service Guaranteed Service traffic is subject to Traffic policing Traffic shaping Traffic policing incoming traffic must conform to Tspec non conforming traffic is discarded or treated as best effort policing is executed at network borders Traffic shaping bursty traffic is shaped in order to fit it into Tspec shaping may be executed inside the network Slide 42
IntServ Controlled Load Service Controlled Load Service is thought for adaptive tolerant real time traffic Controlled Load Service guarantees a QoS similar to those achievable by a best effort traffic in an unloaded network Applications involved specify only Tspec (no Rspec required) Traffic policing and shaping are required. Non conforming traffic is treated as best effort Slide 43
IntServ Tspec Applications must always specify traffic characteristics (Tspec) in order to let the network reserve a proper amount of resources The profile is expressed in terms of the Dual Token Bucket Tspec parameters: r = average rate (bytes/s) b = bucket size (bytes) p = peak rate (bytes/s) M = max. datagram length m = min. datagram length Slide 44
IntServ Guaranteed Delay Theorem if flows are characterized and are enforced by a token bucket Tspec WFQ queuing discipline used in all the routers of the network a reserved rate R not less than average token bucket rate r (R r) it can be proved that the maximum end-to-end queuing delay D MAXQ is mathematically upper bounded (Parekh and Gallager, 1993) Slide 45
IntServ Guaranteed Delay Maximum end-to-end delay is given by: D MAX = D FIX + D MAXQ D FIX is related to fixed delays (transmission, propagation) D MAXQ is the maximum end-to-end queuing delay In a perfect fluid model the flow sees a dedicated wire of bandwidth R between source and destination In this case the maximum end-to-end queuing delay should be: D MAXQ = b R b: bucket depth R: reserved rate (R r) Slide 46
IntServ Guaranteed Delay To allow for deviations from the perfect fluid model two error terms are introduced: C: rate dependent error term (e.g. datagram assembling from ATM b C cells) D MAXQ = R + R + D D: rate independent error term (e.g. processing routing updates) Considering peak rate limitation p and maximum packet size M, the maximum end-to-end delay becomes: D MAXQ = (b-m)(p-r) R(p-r) M+C TOT R + + D TOT M+C TOT R + D TOT p > R r R p r Ctot, Dtot: sum of C and D parameters of the nodes of the path Lossless buffer size at node i = b+csum(i)+dsum(i)*r Csum(i)=sums of C until node i Slide 47
IntServ Traffic Classes Template Components End-to-End behavior Typical Applications Network Elements involved Parameters requested Exported Information Policing Guaranteed Service Guaranteed max. delay Guaranteed throughput No queuing losses Real time applications Fluid model using R (requested bandwidth) and B (buffer size) Tspec: r, b, p, M, m Rspec: R, S (C,D), i.e. values which measure deviation from the ideal fluid model M + min [p T, r T + b-m] Min. datagram length: m Controlled Load Service Approximates Best Effort over unloaded network Applications sensitive to network congestion Admission Control Tspec: r, b, M, m (p is not required) No exported information r T + b Slide 48
RSVP Design Goals RSVP has been designed according to several goals: Unicast and Multicast capabilities Heterogeneous receivers support Source and sub-stream filtering capabilities Dynamic multicast group changes capability Efficient use of resources Protocol overhead limitation Connectionless and dynamic routing environment adaptability Modularity Slide 49
RSVP Design Principles The following design principles have been adopted: Receiver initiated reservation Soft-state Reservation styles and merging Opaque information transport Independence from underlying routing protocol Slide 50
RSVP Key concepts Flow Descriptor obtained joining Filter Spec and Flow Spec Flow Descriptor Filter Spec Flow Spec identifies packets of a flow updates classifier Service class Tspec (r,b,p,m,m) Rspec (R,S) updates scheduler Slide 51
RSVP Messages RSVP messages are carried inside IP datagrams (protocol ID 46) Seven message types: Path (downstream) Resv (upstream) PathErr (upstream) ResvErr (downstream) PathTear (downstream) ResvTear (upstream) ResvConf (downstream) Slide 52
Unicast Reservation 1st step: PATH messages are sent downstream PATH RSVP Enabled Host (SND) RSVP Router RSVP Router RSVP Enabled Host (RCV) At the reception of a PATH message RSVP router creates a path state associated to the corresponding session RSVP router refeshes the timer associated to this path state RSVP router updates Phop and Adspec objects and then forwards Path message towards next Slide 53
Unicast Reservation 2nd step: RESV messages are sent back upstream RESV RSVP Enabled Host (SND) RSVP Router RSVP Router RSVP Enabled Host (RCV) At the reception of a RESV message an RSVP router analyzes FlowSpec for Admission Control; if accepted a resv state is created restarts the timer associated to the resv state forwards Resv message to the previous node of the path (Phop) Slide 54
RSVP Messages Path message sent downstream from sender towards receiver(s) provides information about sender(s) Tspec and end-to-end path characteristics creates path states in each router along the path contains the following objects: Session: destination IP address, port and protocol ID Phop: address of previous RSVP node Sender_Template: IP address and port of the sender Sender_Tspec: sender traffic characteristics (including dual token bucket parameters) Adspec (optional): One Pass With Advertisement (OPWA) information updated by routers along the path Update MAX MTU if smaller Parameters C and D of delay formula summed to the one just contained in the packet (Csum, Dsum) Slide 55
RSVP Messages Resv message: sent upstream from receiver(s) towards sender(s) carries reservation requests to the routers along the distribution tree Resv messages originating from receivers of the same multicast group are merged together before being forwarded upstream contains the following objects: Session: destination IP address, port and protocol ID Reservation style: it can be FF, SE or WF Flow descriptor: Filter spec and Flow spec (including rate R) ResvConf (optional): IP address of the receiver, used to allow the sender to acknowledge reservation Slide 56
Intserv Scalability Problem RSVP per-flow reservation model and soft-state philosophy are particularly suitable for multicast broadband applications (e.g. videoconference and video broadcasting) When used for point-to-point narrowband purposes (e.g. IP telephony) these choices implies large processing overhead in routers and great amount of traffic generation for periodic refreshes Example: ADPCM coding requires 32 kb/s for a voice channel. Neglecting packet overhead a single OC-12 interface of a backbone router (622 Mb/s) should support up to 20000 flows, implying that: packet scheduler has to manage 20000 queues up to 20000 states must be periodically refreshed Slide 57
Intserv Scalability Problem Solutions Flows aggregation (SRP - Scalable Reservation Protocol, currently under study) Use of RSVP limited to the Access Network (IP based), with interconnection among IP domains relying on other QoS capable technologies (e.g. ATM) Differentiated Services Approach Combination of RSVP/IntServ in the Access Section and DiffServ in the backbone Internet Slide 58
DiffServ approach + Scalability A differentiated services mechanism must work at the scale of the Internet (e.g. millions of networks) and at the full range of speeds of the Internet (e.g., Gb/s links) push all the state to the edges force all per-flow work to the edges Edge-only state suggests that service indication must be carried in the packet: Diff Serv Code Point (DSCP) in the IP header DSCP marked at edge? Service Level Agreement (SLA) defines capacity at each service level (DSCP) Direction of data flow Slide 59
Overall scenario for Diffserv QoS Client SLA = Service Level Agreement client SLA SLA Domain SLA Domain Client SLA Domain = Region of shared trust, administration, provisioning, etc. SLA client + Domains provide their customers with the service specified in Service Level Agreement + Individual domains are free to manage the internal resources, to fulfill both internal and external obligations Slide 60
Overall scenario for Diffserv QoS Service Level Agreement ISP SLA ISP SLA ISP SLA Traffic Conditioner meter, mark, shape, drop Per-Hop Behavior active queue management, scheduler End-to-end congestion control Slide 61
DiffServ approach What problem are we solving? Give service to some traffic (at the expense of giving worse service to the rest) What is the service? Better best effort ISPs want finer control of relative bandwidth allocation, particularly under heavy load Virtual leased line Users want an end-to-end absolute bandwidth allocation, independent of other traffic Slide 62
DiffServ approach + Standardizing or Packet Forwarding? If the answer is everyone has to agree on what constitutes a useful service and every router has to implement the machinery for it (i. e., to deploy a new service, you have to upgrade the world) Since a router actually do that many different things to a packet, it makes more sense to standardize forwarding behavior (e. g., this packet or this packet Behaviors + Rules = Services Slide 63
Architectural Model + Diff-serv architecture implements scalable service differentiation in the Internet + A defines some significant characteristics of packet transmission across a set of one or more path within a network + Service differentiation is desired to accommodate heterogeneous application requirements and user expectations, and to permit differentiated pricing. Slide 64
DiffServ Architecture Components + Functional elements in the network nodes a small set of -hop forwarding packet classification functions traffic conditioning functions (metering, marking, shaping and policing) + To achieve scalability complex classification and conditioning functions are implemented only at network boundary nodes per-hop behavior are applied to aggregate of traffic marked using the DS in the IP header Slide 65
DiffServ Field in the IP header + IP datagram header 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version IHL Type of Service Total Length +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Identification Flags Fragment Offset +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Time to Live Protocol Header Checksum +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Options Padding +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Slide 66
DiffServ Field in the IP header + Historical TOS field Precedence 111 - Network Control 110 - Internetwork Control 101 - CRITIC/ECP 100 - Flash Override 011 - Flash 010 - Immediate 001 - Priority 000 - Routine Bits 0-2: Precedence. Bit 3: 0 = Normal Delay, 1 = Low Delay. Bits 4: 0 = Normal Throughput, 1 = High Throughput. Bits 5: 0 = Normal Reliability,1 = High Reliability. Bit 6-7: Reserved for Future Use. 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ PRECEDENCE D T R 0 0 +-----+-----+-----+-----+-----+-----+-----+-----+ Slide 67
DiffServ Field in the IP header + The DS field replaces the IPv4 TOS octet (and the corresponding IPv6 Traffic Class octet) The DS field structure is the following 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ DSCP CU +---+---+---+---+---+---+---+---+ DSCP: differentiated services codepoint CU: currently unused The DS code point MUST be used as an index to a table Slide 68
DiffServ Field in the IP header + Codepoint for the PHB (i.e. Best effort) is: 000000 + IP Precedence/Class selector code points (for backward compatibility) 0 1 2 3 4 5 6 7 X X X 0 0 0 CU + NO backward compatibility for the DTR bits Slide 69
Services vs. PHBs vs. DS code points + Services are the composition of PHBs + DS code points are mapped into PHBs available in a given node + A PHB is realized by an implementation mechanism internal to the node Slide 70
Differentiated Service Domain DS interior node DS boundary DS boundary node + A DS domain is a contiguous set of DS nodes which operate with a common service provisioning policy and a set of PHB groups implemented in each node Slide 71
Service Level Agreements (SLAs) + A Service Level Agreement (SLA) is a service contract between a customer and a service provider that specifies the forwarding service a customer should receive + A customer may be a user organization (source domain) or another DS domain (upstream domain) + A SLA may include traffic conditioning rules which constitute a Traffic Conditioning Agreement (TCA) + The SLA typically specifies the TCA, plus: availability/reliability encryption services routing constraint authentication mechanisms service monitoring mechanisms pricing and billing Slide 72
Traffic classification and conditioning Meter Classifier Marker Shaper/ Dropper Slide 73
Traffic classification and conditioning + Classifiers can be Behavior Aggregate (BA) based on the DS codepoint only Multi-Field (MF) based on the combination of one or more header field such as source address, destination address, DS field, protocol IP, source and destination port number and on other information such as incoming interface Slide 74
Traffic classification and conditioning + Traffic profiles specify the temporal properties of a traffic stream selected by a classifier + A Traffic Conditioner can be composed by the following elements meter marker shaper and dropper + The meter measure the traffic pattern against the traffic profile and can interact with marker and shaper/dropper Slide 75
Service taxonomy: quantitative vs. qualitative + Clearly qualitative (IntServ-controlled load, DiffServ EF) Level A traffic will be delivered with low latency Level B traffic will be delivered with low loss + Clearly quantitative (IntServ - guaranteed service) 90% of in profile traffic will experience no more than 50msec latency 95% of in profile traffic will be delivered + Not readily categorized (relative) (DiffServ - AF) Traffic offered at service level E will be allotted twice the bandwidth of service level F traffic Traffic with drop precedence AF12 has a lower probability of delivery than traffic with drop precedence AF13 Slide 76
Dynamic vs. Static SLAs + Static SLAs are considered at present time + They are agreed after negotiation between human agents + They can be periodically renegotiated (days weeks ) + The SLA can specify a time varying services (times of day) + Dynamic SLAs may change frequently, as a result from variations in offered traffic load or from changes in pricing offered by the provider + Dynamic SLAs change without human intervention and require an automated agent and protocol Bandwidth Broker Slide 77
Bandwidth Broker (BB) + A BB is responsible within a DiffServ domain for the handling of the network resources + The BB guarantees the SLAs negotiated with users BB Access network ER CR CR CR ER BB Dominio DiffServ Access network ER Dominio DiffServ ER Access network Slide 78
Bandwidth Broker (BB) + The BB is a logical entity residing in each administrative domain Diffserv treatment BB manages internal demands & resources according to the policy database sets up & maintains bilateral agreement with neighbor domains controls the traffic entering & going out on border routers BB BB BB BB + Three components: Intra-domain protocols Inter-domain protocols End-to-End Services Slide 79
Bandwidth Broker (BB) + Tasks of a BB Interaction with ER e CR for QoS signalling handling Interaction with other BBs for QoS signalling handling Handling of the information database concerning SLAs negotiated with users congestion status of network resources Flow admission control Router configuration Slide 80
Per-hop forwarding behaviors + Class selector compliant PHBs + Expedited Forwarding (EF) PHB + Assured Forwarding (AF) PHB group Slide 81
Class selector compliant PHBs + 8 code points 000 + At least two different PHBs + Any PHB selected by a higher code-point should give higher probability of timely forwarding than a PHB selected by a lower code-point + Code-points 11x000 must be mapped in a PHB than 000000 Slide 82
Expedited Forwarding PHB + The EF PHB can be used to build an end-to-end service through DS domains characterized by low-loss low-latency, low-jitter assured bandwidth Queuing must be avoided aggregate maximum arrival rate is less than that aggregate minimum departure rate Slide 83
Expedited Forwarding PHB + To create the low-loss, low delay service + Nodes must be configured so that the aggregate has a - (i.e. independent of other traffic on the node) minimum departure rate (EF PHB) + The aggregate must be configured (via policing and shaping) so that its arrival at any node is always less than the configured minimum departure rate Slide 84
Expedited Forwarding PHB + Description of the EF PHB + The departure rate of aggregate must equal or exceed a configurable rate + The EF traffic should receive this rate independent of other traffic + The rate should average at least the configured rate when measured over any time interval equal to or longer than a packet time at the configured rate Slide 85
Expedited Forwarding PHB + Mechanisms to implement EF PHB Simple priority queue A queue from a pool served by weighted round robin Class Base Queuing (CBQ) + Recommended code-point 101110 Slide 86
Assured forwarding PHB group + The AF PHB group provides delivery of IP packets in four independently forwarded AF classes AFxy x=1,2,3,4 + Within each AF class, an IP packet can be assigned one of three different levels of drop precedence AFxy y=1,2,3 + A DS node does not reorder IP packets of the same microflow if they belong to the same AF class + Packets of AF class x do not have higher probability of timely forwarding than class y packets, if x < y + Within an AF class, a packet with drop precedence p must not be forwarded with smaller probability than a packet with drop precedence q, if p < q Slide 87
Assured forwarding PHB group better service AF4x AF3x AF2x Priority queueing AF1x AF11,12,13 Drop thresholds (Weighted RED) Slide 88
Multiple class over-provisioning 1/2 + Different classes with different bandwidth and delay requirements + Link BW distributed through over-provisioned bandwidth constraint realised through advanced scheduling (e.g., WDRR, WFQ, etc.) + Lower delay, more over-provisioning Free BW for best-effort Delay class x < Delay class y Class x class y Class x Class y Maximum reservabe capacity on output interface Offered traffic Planned reservation Slide 89
Multiple class over-provisioning 2/2 + Ingress shaping and Link BW distributed through priority queing Condition: Sum of shaped offered traffic enougth lower than output capacity + Russian Dolls Model Priority queueing leads class x to see all capacity, class y to see the maximum capacity less the one takens by x class + Problem: limit ingress traffic (e.g., shaping) to avoid starvation This may involve resource usage inefficiency, since a class can not exploits temporary remaining capacity due to the shaping Class x Class y Class x Class x + Class y Maximum reservabe bandwidth Offered traffic Planned reservation Slide 90
Multi Protocol Label Switching Slide 91
MPLS: architettura + alla base di tale architettura è quella di associare a tutti i pacchetti un breve identificativo di lunghezza fissa, detto Label, con cui gli apparati di internetworking possono effettuare un instradamento veloce basato sulla commutazione di etichetta (label swapping) + MPLS è indipendente sia dalla sottorete di trasporto (Frame Relay, ATM, etc.) sia dai protocolli di rete adottati 20 bit Label Label Label 20 bit Label Label Label 3 bit 3 bit 1 bit Exp Exp S Exp Exp S Exp Exp S Pacchetto Pacchetto IP IP 1 bit 8 bit 8 bit S TTL TTL S TTL TTL S TTL TTL Slide 92
Nodo MPLS Il nodo di rete MPLS Label Switch = + Control component (router + LDP) Forwarding component (L2 switch) + Control Component Insieme di moduli demandati nodi adiacenti + Forwarding Component di livello 3 (IP addressing, IP routing) Inoltro secondo il paradigma label swapping delle Label ed al binding delle Label tra + Le due componenti devono essere indipendenti: posso sviluppare differenti protocolli su qualsiasi mezzo + La Control Component viene talvolta realizzata come parte integrata (SW o HW) del nodo di rete, talvolta come controllore esterno Slide 93
Label encoding + Se il livello data-link supporta nativamente un campo per la label (ATM con VPI/VCI, Frame Relay con DLCI) in questo campo viene inserita la label MPLS + Se i livello data-link non supporta un tale campo, la label MPLS viene incapsulata in un MPLS header che viene inserito tra header di livello 2 e quello di livello 3 Header cella ATM GFC VPI VCI PTI CLP HEC DATA MPLS Header Packet Over SONET/SDH PPP Header MPLS Header Layer 3 Header Label CoS S TTL 20 bit 3 bit 1 bit 8 bit Slide 94
Terminologia + Label Edge Router (LER): router di frontiera per una rete MPLS; svolgono funzionalità di instradamento da e verso applicando e rimuovendo le label ai pacchetti in ingresso ed uscita dalla rete + Label Switching Router (LSR): switch che operano la commutazione di etichetta (label) della rete e prevedono il supporto di funzionalità di instradamento + Label Distribution Protocol (LDP): in congiunzione con i protocolli di routing tradizionali, LDP è utilizzato per distribuire le label tra i dispositivi della rete + Forwarding Equivalence Class (FEC): un insieme di pacchetti IP che vengono instradati allo stesso modo (ad es., lungo lo stesso percorso, con lo stesso trattamento) + Label Switched Path (LSP): Il percorso attraverso uno o più LSRs segutio da un pacchetto appartenente ad un certa FEC Slide 95
Funzionamento + Il LER di ingresso al backbone MPLS analizza IP del pacchetto, classifica il pacchetto, aggiunge la label e lo trasmette al next hop LSR + Nella nuvola di LSRs il pacchetto viene instradato lungo il LSP in accordo alla label + Il LER di uscita rimuove la label ed il pacchetto viene instradato in base IP di destinazione Slide 96
Label Switching Operation: Control + LDP è utilizzato per distribuire le associazioni <label, prefisso> LDP stabilisce le associazioni tra le route e le label, che vengono memorizzate in una tabella denominata LIB (Label Information Base) LSR LER LSR LER LSR LSR LER LSR LSR LER LER Slide 97
LDP: Downstream on Demand local label remote label addr. prefix i/f local label x x remote label addr. prefix i/f 128.89.10.0 1 171.69.0.0 1 local label remote label addr. prefix 128.89.10.0 0 171.69.0.0 1 LSR i/f 0 i/f x LER 128.89.10.0 0 i/f 0 128.89.10.0 LER i/f 1 Label Request <128.89.10.0> <171.69.0.0> i/f 1 LER 171.69.0.0 i/f 0 Data Flow local label remote label addr. prefix i/f x 171.69.0.0 0 Slide 98
LDP: Downstream on Demand local label remote label addr. prefix i/f local label x x remote label addr. prefix i/f 3 128.89.10.0 1 4 171.69.0.0 1 local label 3 4 remote label addr. prefix i/f 128.89.10.0 0 171.69.0.0 1 LER x 128.89.10.0 0 i/f 0 128.89.10.0 LSR i/f 0 LER i/f 1 Label Mapping <3,128.89.10.0> <4,171.69.0.0> i/f 1 LER 171.69.0.0 i/f 0 Data Flow local label remote label addr. prefix i/f x 171.69.0.0 0 Slide 99
LDP: Downstream on Demand local label remote label addr. prefix i/f local label x x remote label addr. prefix i/f 3 128.89.10.0 1 4 171.69.0.0 1 local label 3 4 remote label 5 7 addr. prefix i/f 128.89.10.0 0 171.69.0.0 1 LER 5 x 128.89.10.0 0 i/f 0 128.89.10.0 LSR i/f 0 LER i/f 1 i/f 1 LER i/f 0 171.69.0.0 Data Flow local label remote label addr. prefix i/f 7 x 171.69.0.0 0 Slide 100
Label Switching Operation: Forwarding local label x remote label addr. prefix 3 x 4 LER i/f 128.89.10.0 1 171.69.0.0 1 i/f 1 local label 3 4 remote label 171.69.12.1 dati 4 171.69.12.1 dati 5 7 addr. prefix 128.89.10.0 0 171.69.0.0 1 LSR i/f 0 i/f 1 7 i/f LER 171.69.12.1 dati rimuove la label Il primo LER aggiunge la label Il LSR instrada il pacchetto in base alla label LER 171.69.12.1 dati local label 7 remote label x addr. prefix i/f 171.69.0.0 0 Slide 101
Label Stacking + Le label MPLS possono essere messe in stack per aggregare, su un tratto di rete, due o piu LSP in un unico LSP di ordine gerarchico superiore + di una label prende il nome di label push + La rimozione di una label prende il nome di label pop + è fatto sempre in base alla label di ordine superiore; se la label non si instrada a livello IP L=x IP LSR L=z L=x IP L=x IP L=y IP PUSH label z L=z L=y IP POP label L=y IP Slide 102
MPLS: realtà + Perchè un ISP dovrebbe impiegare MPLS? Il vantaggio principale di MPLS è che consente ad un ISP di offrire nuovi servizi che non possono essere supportati semplicemente attraverso le tecniche di routing convenzionale + Attualmente possono essere individuate tre applicazioni di MPLS nel core degli ISP: Traffic Engineering (MPLS-TE) Traffic Engineering with QoS (MPLS DS-TE) Virtual Private Networks (VPN) Slide 103
MPLS-TE + Traffic Engineering consente ad un ISP di instradare un certo flusso di traffico lungo un percorso differente da quello calcolato dal protocollo di routing in modo da utilizzare (qualora sia necessario) un percorso fisico meno congestionato + Ciò consente agli ISP per bilanciare il carico sui vari link e nodi della rete in modo che nessuno di questi componenti sia sovrautilizzato o sottoutilizzato + MPLS-TE estende il funzionamento di base di MPLS introducendo: dei meccanismi per il recupero delle informazioni di occupazione dei link Dei meccanismi di segnalazione RSVP-TE, CR-LSP per il setup di LSP con un routing forzato Slide 104
Traffic Engineering: come? + Normalmente un LSP viene instaurato in base al calcolo del percorso a costo minore effettuato dal protocollo di routing utilizzato sul backbone + Questa modalità non offre nessun valore aggiunto in termini di traffic engineering + Possono essere utilizzati diversi meccanismi per instaurare un LSP differente da quello determinato attraverso il protocollo di routing: configurazione statica di tutti i LSR nel LSP (in modo analogo a come viene configurato un backbone IP/ATM tradizionale) configurazione del LER con il percorso completo. Il LER poi utilizza una versione modificata del protocollo RSVP per installare le LIB in ciascuno dei LSR lungo il percorso (LSP) Slide 105
Routing di un LSP + Il percorso che un LSP deve seguire affinché attraversi link con {opportuna capacità riservabile, scarichi} è solitamente precalcolato da un tool off-line + necessaria la conoscenza dello stato di occupazione delle varie interfacce di uscita dei LER A) Soluzioni proprietarie che sfruttano query dello LSR MIB B) Estensione dei protocolli di routing link-state (flooding delle informazioi delle interfacce), IGP di tipo OSPF o IS-IS, in modo che trasportino anche lo stato di occupazione delle risorse. Conseguentemente i LER (o una entità centralizzata di management) conoscono topologia e occupazione della rete + Calcolo del percorso attraverso constraint-based, shortest path first (CSPF) Algoritmo shortest-path calcolato sulla topologia di rete con esclusione dei link che non possono supportare la banda B dello LSP di cui si sta facendo il setup + Setup manuale o attraverso RSVP-TE / CR-LDP Slide 106
LSP: configurazione statica R1 R2 Configurazione statica: R2 R4 ha bisogno di 1 Mbps R1 R3 ha bisogno di 2 Mbps R1 R4 ha bisogno di 2 Mbps LSR1 LSR3 45 Mbps 1.5 Mbps 45 Mbps LSR2 R3 R4 Slide 107
LSP: configurazione con RSVP-TE R8 R2 R3 R4 Pop R9 R1 49 17 R6 R7 32 R5 22 Setup: Path (R1->R2->R6->R7->R4->R9) Reply: RESV (Comunica le label) Slide 108
RSVP-TE Slide 109
LSP: configurazione con CR-LDP R8 R2 R3 R4 R9 R1 49 17 R6 R7 32 R5 22 Setup: Label Request (R1->R2->R6->R7->R4->R9) Reply: Label mapping Slide 110
MPLS & QoS + del traffico implica una pianificazione delle risorse al fine di permettere un efficace trasferimento dei dati appartenenti agli LSP + Pertanto il traffic engineering tenta di rendere i link scarichi + Come ci si comporta in caso di classi di servizio diverse? + Regola Empirica: Nel caso in cui la somma delle capacità richieste da tutti gli LSP su una interfaccia di uscita di un LSR sia inferiore o uguale alla metà della capacità della linea, tutti i LSP subiranno un ritardo molto basso e non necessità di impiego di meccanismi di scheduling (e.g., WDRR) + Quando però, post traffic engineering, le capacità delle interfacce in gioco cominciano a lavorare con carichi >>0.5, allora è necessario differenziare il trattamento del traffico + MPLS si integra con DiffServ Slide 111
MPLS e DiffServ + Quale è il criterio di classificazione che un LSR adotta per determinare la coda dello scheduler (ovvero il forwarding-behaviour DiffServ)? + Due soluzioni: Exp inferred LSP (E-LSP) La classificazione per lo scheduler avviene attraverso il campo Exp (3 bit) MPLS Forwarding behaviour e drop precedence dedotto dalla codifica del campo Exp Pachetti di LSP diversi con lo stesso campo Exp sono trattati ugualmente Richiede al massimo 8 code dello scheduler, tante quanto le possibili combinazioni dl campo EXP Label inferred LSP (L-LSP) Forwarding behaviour dedotto dalla label, drop precedence dedotto dal campo Exp Ogni LSP può essere gestito con un differente forwarding behaviour indipendentemente dal campo EXP Richiede un numero variabile di code dello scheduler Più complesso, ma più versatile < Forwarding behaviour, label > deve essere segnalata esplicitamente durante la fase di setup dello LSP Slide 112
MPLS & BGP + BGP è il protocollo di routing utilizzato tra AS + BGP è eseguito dai nodi di bordo di un AS + Le tabelle BGP contengono le rotte verso tutte le net 2011 circa 400k rotte (http://bgp.potaroo.net/) Slide 113
MPLS & BGP + Problema: come fanno i router interni (e.s. R2) a instradare i pacchetti in transito, i.e. diretti ad una delle 400k reti esterne? Replico le tabelle BGP anche nei router interni (router interni costosi) Faccio dei Label Switched Path MPLS tra router di bordo (full mesh) su cui instrado solo il traffico di transito I router interni hanno solo tabelle di routing che riguardano gli instradamenti interni Large BGP Table (1) Net a.a.a.a (400 k) Net z.z.z.z BGP R1 MPLS LSP BGP R3 Large BGP Table (1) Net a.a.a.a (400 k) Net z.z.z.z IGP Autonomous system R2 Small IGP Table (1) Net 1.1.1.1 Slide 114