---

Att förstå grunderna i QoS – som trafik klassificering, köhantering och olika QoS-modeller – är ett första steg. Nästa steg är att kunna tillämpa QoS i verkliga nätverksmiljöer. Det är här QoS-implementeringstekniker kommer in. Dessa tekniker omfattar allt från hur och var trafik klassificeras och markeras, till hur trafikflöden hanteras för att undvika överbelastning, minska fördröjningar och förhindra paketförlust.

I detta avsnitt går vi igenom konkreta metoder för att implementera QoS:

• Classifying och marking – identifiera och märka trafik tidigt i nätverket
• Trust boundaries – definiera var märkning sker och vilka enheter som är pålitliga
• Congestion avoidance och congestion management – förebygga och hantera trafikstockning
• Traffic shaping och policing – reglera trafikflöden ut och in ur nätverket

Undvika paketförluster

Paketförlust är vanligtvis resultatet av överbelastning (congestion) på ett interface. De flesta applikationer som använder TCP upplever försämrad prestanda vid förlust eftersom TCP automatiskt anpassar sig till nätverkets belastning. TCP-sessioner minskar sina fönsterstorlekar när segment tappas. Vissa applikationer använder dock inte TCP och klarar inte av paketförluster – dessa kallas för ”fragile flows”.

Följande metoder kan förhindra paketförluster i känsliga applikationer:

• Öka länkens överföringskapaciteten för att minska eller förhindra överbelastning.
• Garantera tillräcklig bandbredd och öka buffert storleken för att hantera trafiktoppar från ”fragile flows”. WFQ, CBWFQ och LLQ kan garantera bandbredd och ge prioriterad hantering till applikationer som är känsliga för förlust.
• Ta bort låg prioriterad trafik innan överbelastning uppstår. Cisco IOS QoS erbjuder kömekanismer, som Weighted Random Early Detection (WRED), som börjar droppa (ta bort) låg prioriterade paket innan köerna blir fulla.

QoS-verktyg

QoS-verktyg delas in i tre kategorier, enligt tabellen nedan:

QoS-sekvens

Som visas i figuren klassificeras inkommande paket (grå rutor) och får en markering i sina IP-header fält (färgade rutor). För att undvika överbelastning allokeras resurser enligt definierade policys. Paketen köas därefter och skickas ut via egress-interface enligt deras QoS-policy för shaping och policing.

Obs: Klassificering och markering kan utföras både vid ingress och egress, medan andra QoS-åtgärder som köhantering (queuing) och shaping normalt sker vid egress.

Klassifikation and Märkning

Innan ett paket kan få en QoS-policy tillämpad måste det klassificeras. Klassifikation and märkning gör det möjligt att identifiera eller ”markera” olika typer av paket. Klassificering avgör vilken trafikklass paketen eller ramarna tillhör. Först efter att trafik har markerats kan policies tillämpas.

Hur ett paket klassificeras beror på vilken QoS-implementering som används. Metoder för att klassificera trafik på lager 2 och 3 inkluderar användning av interface, ACL och class maps. Trafik kan även klassificeras på lager 4 till 7 med hjälp av Network-Based Application Recognition (NBAR).

Obs: NBAR är en funktion i Cisco IOS som möjliggör klassificering och protokollidentifikation i samverkan med QoS-funktioner. NBAR ingår inte i denna kurs.

Märkning innebär att ett värde läggs till i paketets header. Mottagande enheter läser det markerade fältet för att se om det matchar en definierad policy. Markering bör ske så nära source-enheten som möjligt – detta kallas trust boundary.

Hur trafiken markeras beror oftast på teknologin. Tabellen nedan beskriver några vanliga markerings fält för olika teknologier. Beslutet att markera trafik på lager 2 eller 3 (eller båda) bör fattas utifrån följande överväganden:

• Lager 2-markering kan utföras även för icke-IP-trafik.
• Lager 2-markering är det enda QoS-alternativet för switchar som inte är ”IP-aware”.
• Lager 3-markering bär med sig QoS-informationen hela vägen från källa till destination (end-to-end).

Trafik märkning för QoS:

Markering på lager 2

802.1Q är IEEE-standarden som stöder VLAN-taggning på lager 2 i Ethernet-nätverk. När 802.1Q implementeras läggs två fält (TPID och TCI)till i Ethernet-ramen. Som visas i figuren placeras dessa fält direkt efter källans MAC-adress.

Standarden IEEE 802.1Q inkluderar också ett QoS-prioriteringssystem kallat 802.1p. Denna använder de tre första bitarna i fältet Tag Control Information (TCI). Dessa tre bitar kallas Priority (PRI)-fältet och representerar Class of Service (CoS)-markeringar. Eftersom fältet är 3 bitar långt kan en Layer 2 Ethernet-ram märkas med någon av åtta prioriteringsnivåer (värden 0–7), enligt tabellen nedan:

Markering på lager 3

IPv4 och IPv6 har ett 8-bitars fält i sina paketheaders som används för markering. Som visas i figuren stöder både IPv4 och IPv6 detta fält: Type of Service (ToS) för IPv4 och Traffic Class för IPv6.

ToS-fältet (IPv4) och Traffic Class-fältet (IPv6) innehåller QoS-markeringen som tilldelats av klassificerings verktygen. Dessa fält läses sedan av mottagande enheter som vidarebefordrar paketen enligt tillämplig av QoS-policy.

I RFC 791, den ursprungliga IP-standarden, specificerades de tre första bitarna i fältet som IP Precedence (IPP) för QoS-markering. Men tre bitar gav inte tillräcklig precision. Därför RFC 2474 ersätter RFC 791 och omdefinierar ToS-fältet genom att utöka IPP till ett nytt fält kallat Differentiated Services Code Point (DSCP).

DSCP använder de 6 första bitarna för QoS-markering, vilket ger upp till 64 möjliga klasser. De återstående 2 bitarna kallas Explicit Congestion Notification (ECN), och används av ECN-medvetna routrar för att indikera överbelastning istället för att droppa paketen. Det hjälper routrar att bli medvetna om pågående trängsel i flödet.

DSCP-värden

De 64 möjliga DSCP-värdena delas in i tre huvudkategorier:

• Best-Effort (BE) – Standardvärde för alla IP-paket. DSCP = 0. Per-hop beteende är vanlig vidarebefordran. Paket släpps vid överbelastning. Ingen QoS tillämpas.
• Expedited Forwarding (EF) – RFC 3246 definierar EF som DSCP-värde 46 (binärt 101110). De tre första bitarna (101) matchar direkt CoS-värde 5 (används för rösttrafik). Cisco rekommenderar att EF enbart används för att markera röstpaket.
• Assured Forwarding (AF) – RFC 2597 definierar AF som ett schema där de 5 mest signifikanta bitarna visar klass och drop-preferens. Den 6:e biten är alltid 0.

Assured Forwarding värden:

AF-värden skrivs enligt formatet AFxy, där:

• x anger trafikklassen (1–4, låg till hög), där en högre klass innebär högre prioritet i köhanteringen.
• y anger drop-preferens (1 = låg, 2 = medel, 3 = hög), dvs. hur sannolikt det är att paketet tas bort vid överbelastning.

Exempel:

• AF41 tillhör klass 4 (den bästa klassen, hög prioritet) och har drop-preferens 1 (låg risk). Det innebär att trafiken prioriteras högt behandling i köhanteringen och har låg risk för att förloras vid överbelastning.
• AF43 tillhör klass 4 (den bästa klassen, hög prioritet), men har drop-preferens 3 (hög risk). Det innebär att trafiken placeras i samma kö som AF41 och AF42, men har större sannolikhet att förloras vid överbelastning.
• AF32 tillhör klass 3 (medel prioritet) och har drop-preferens 2 (medelhög risk). Det innebär att trafiken placeras i en medel prioriterad kö, med måttlig sannolikhet att förloras vid köbildning – mer skyddad än AF33, men mindre än AF31.

Class Selector-bitar

Eftersom de tre mest signifikanta bitarna i DSCP-fältet anger trafikklassen, kallas dessa ibland även för Class Selector (CS)-bitar. Dessa tre bitar motsvarar direkt de tre bitarna i CoS-fältet (802.1p) och IPP-fältet (IP Precedence enligt RFC 791), vilket säkerställer kompatibilitet mellan lager 2- och lager 3-markeringar, som visas i figuren.

• De tre bitarna i PRI-fältet (Priority) för CoS (Class of Service) motsvarar de binära vikterna 4, 2 och 1, vilket ger möjliga värden från 0 till 7 (2³ kombinationer).
• DSCP-fältet består av 6 bitar med vikterna 32, 16, 8, 4, 2 och 1. Tillsammans ger dessa värden från 0 till 63 (2⁶ kombinationer), vilket möjliggör upp till 64 olika DSCP-klasser. I praktiken är dock endast 56 av dessa värden definierade och används inom QoS. Övriga är reserverade eller ej tilldelade.

Trust Boundaries

Var ska markering ske? Trafik bör klassificeras och markeras så nära sin källa som tekniskt och administrativt möjligt. Detta definierar trust boundary, vilket illustreras i figuren.

Exempel på hantering inom en trust boundary:

1. Trusted endpoints har förmågan och intelligensen att själva markera applikationstrafik med lämpliga Lager 2 CoS- och/eller Lager 3 DSCP-värden.
   Exempel: IP-telefoner, trådlösa accesspunkter, videokonferenssystem, IP-konferens stationer med mera.
2. Secure endpoints kan få sin trafik markerad av närmaste Lager 2-switch.
3. Trafik kan även markeras i Lager 3-switchar eller routrar.

Markering av trafik, exempelvis från CoS till DSCP eller IP Precedence, är ofta nödvändig för att upprätthålla enhetlig QoS genom hela nätet.

Congestion Avoidance

Trängselhantering omfattar kö- och schemaläggnings metoder där överskotts trafik buffras eller köas (och ibland kasseras) medan den väntar på att skickas ut via ett egress-interface.
Congestion Avoidance handlar om att övervaka nätverkstrafikens belastning i syfte att förutse och undvika trängsel vid vanliga flaskhalsar i nätverk innan trängsel uppstår. Dessa verktyg kan till exempel övervaka det genomsnittliga ködjupet (belastning i kön), vilket illustreras i figuren.

När kön ligger under den lägsta tröskeln kasseras inga paket. När kön närmar sig den högsta tröskeln kasseras en liten andel av paketen. När den högsta tröskeln överskrids kasseras samtliga paket.

Vissa tekniker ger företräde till vilka paket som ska kasseras först för att effektivt motverka trängsel. Ett exempel är funktionen Weighted Random Early Detection (WRED) i Cisco IOS QoS, som erbjuder en metod för trängsel undvikande. WRED-algoritmen möjliggör buffertstyrning vid nätverksportar och tillåter TCP-trafik att minska eller ”backa av” innan buffertarna är helt fyllda.

Genom att använda WRED undviker man så kallade tail drops och maximerar både nätverks utnyttjande och prestanda för TCP-baserade applikationer.
För trafik som baseras på User Datagram Protocol (UDP), till exempel röstsamtal, finns däremot inget inbyggt trängsel undvikande. I sådana fall används istället metoder som köhantering och komprimering för att minska – eller i bästa fall förhindra – förlust av UDP-paket.

Shaping och Policing

Traffic shaping och traffic policing är två metoder i Cisco IOS QoS för att kontrollera trafikflöden och förebygga överbelastning. Traffic shaping behåller överskottspaket i en kö och schemalägger dem för senare överföring i successiva tidsintervall. Resultatet av traffic shaping är en jämnare och mer utjämnad utgående pakethastighet, vilket illustreras i figuren.

Shaping förutsätter att det finns en kö och tillräckligt med minne för att buffra fördröjda paket, vilket policing inte gör. Vid aktivering av shaping bör finnas tillräckligt med minne. Dessutom kräver shaping en schemaläggnings funktion för att senare kunna skicka de fördröjda paketen. Denna schemaläggning gör det möjligt att organisera shaping-kön i olika delköer.

Exempel på sådana schemaläggnings funktioner är CBWFQ (Class-Based Weighted Fair Queuing) och LLQ (Low Latency Queuing).

Shaping tillämpas på utgående trafik – det vill säga, paket som skickas ut från ett interface köas och kan vidarebefordras.
Policing, däremot, tillämpas på ingående trafik. När trafikmängden når den konfigurerade maxgränsen, kasseras överskotts trafiken (eller märks om).

Policing används ofta av tjänsteleverantörer för att upprätthålla en avtalad CIR (Committed Information Rate). Tjänsteleverantören kan dock tillåta tillfälliga toppar över CIR om nätverket för tillfället inte är överbelastat.

Policing trafik exempel:

QoS Policy riktlinjer

En QoS-policy måste ta hänsyn till hela vägen från source till destination. Om en enhet längs vägen använder en annan policy än den avsedda, påverkas hela QoS-policyn negativt.
Till exempel kan hackig videouppspelning bero på att en switch i vägen inte har rätt inställning för CoS-värdet (Class of Service).

Här är några riktlinjer som hjälper till att säkerställa bästa möjliga upplevelse för slutanvändarna:

• Aktivera köhantering på varje enhet i vägen mellan source och destination.
• Klassificera och märk trafik så nära source som möjligt.
• Forma (shaping) och begränsa (policing) trafikflöden så nära deras source som möjligt.

---