CoS

CoS terms and Concepts

Network QoS parameters

Nel linguaggio comune, i termini QoS e CoS sono scambiati. Per essere chiari utilizzeremo il
termine QoS per indicare i parametri della rete come delay o loss probability, me
utilizzeremo il termine CoS per indicare l’effetto dell’applicazione dei parametri QoS.
I parametri QoS sono:
●​ Bandwidth: è la capacità di trasporto di ogni link
●​ Delay: é la misura di tempo che server a muovere un pacchetto da un punto ad un
altro
●​ Delay variation (Jitter):è la misurazione della variazione dei ritardi
●​ Loss: è la percentuale dei pacchetti persi
●​ Loss Pattern: definisce la natura della perdità che può essere bursty (breve
durata) o cronica (detto dribble error)

Classification
La classificazione è l’azione che associa un pacchetto ricevuto con una forwarding class
definita, che a sua volta si associa ad una coda.

I nuovi routers ip supportano due tipi di classificazioni:

●​ Multifield classification: I classificatori multicampo sono i più flessibili e quindi i più
pesanti a livello computazionale. Si basa sulle corrispondenze con più campi con il
pacchetto IP, incluse origine e destinazione indirizzi, tipo di protocollo, porte e così
via. Normalmente si utilizza Multifield classification nei router edge
●​ Behavior aggregate (BA): Utilizza campi fissi negli header dei pacchetti per
prendere decisioni di classificazione.

Forwarding classes, queues, and schedulers

Tipicamente, c’è una mappatura one-to-one tra forwarding class e queue number, ma è
possibile anche settare una mappatura many-to-one
Vediamo la classica dei forwarding class, dal meno pregiato al più pregiato
●​ Best effort (BE)
●​ Assured forwarding (AF)
●​ Expedited forwardinf (EF)
●​ Network Control (NC) traffico con la più alta priorità perchè è il traffico dei protocolli
Nella terminologia IP DiffServ, una forwarding class viene mappata ad una DS behavior
aggregate (o ordered aggregate).
I pacchetti inseriti in una egress queue sono serviti da uno scheduler. L’algoritmo di
scheduler determina quanto spesso la coda è servita, e in quale ordine basandosi sulla
priorità e il transmit rate. Lo scheduling dei pacchetti combinato con il rate limiting e le policy
sono un importante aspetto dell IP CoS.

L’algoritmo di base serve prima le code che hanno priorità alta e stato positivo, poi quelle
con priorità bassa e stato positivo, ed infine serve tutte le altre (tipicamente utilizzando un
round-robin algorithm).
Nell’esempio precedente FC3 ha priorità alta, ma stato negativo, ciò significa che ha
superato la percentuale di trasmissione configurata ed adesso deve aspettare di accumulare
crediti per diventare nuovamente positivo.
Per vedere lo scheduler applicato ad un’interfaccia si utilizza il comando
Che oltre a far vedere il classificatore applicato, mostra anche lo scheduler map
(nell’esempio default)1.
Per vedere in dettaglio lo scheduler map si utilizza il comando:

Per creare uno scheduler si utilizzano i comandi

Una volta creati gli schedulers bisogna creare uno scheduler-maps contenente i vari
scheduler

1
Il traffico che matcha con il nostro classificatore viene scartato, perchè lo scheduler map default
prevedere solo traffico Best-efferdor (BE) e Network control (NC) tutto il resto viene scartato
ed infine applicare lo scheduler-map all’interfaccia con il comando set class-of-service
interfaces interface-name unit unit-number scheduler-map scheduler-name

Congestion management
Statisticamente le reti multiplexed sono soggette a congestione. Poichè le datagram network
non supportano il flow control, discard è l’unico meccanismo che un router ha per prevenire
la congestione. i router moderni implementano alcune forme di Active Queue Management
(AQM)2.
Un router può semplicemente droppare quando la coda è piena (questo processo è detto
tail dropping), oppure droppare il traffico in maniera randomica prima di riempire la coda
random early detection (RED), questo processo ha più vantaggi rispetto la semplice tail
dropping.
Il RED applica una politica di drop più soft quando la coda è vuota più aggressiva quando si
va riempendo.

Nell’immagine sopra viene creato un profilo personalizzato dal nome knoxs.-drop, poi deve
essere applicato allo scheduler, con il comando drop-profile-map.

2
Per lettura AOQ è definita nella RFC2309
Il Weighted RED applica politiche di drop diverse anche in base al tipo di traffico.

Policy and shaping

Le reti Packet-based sono in grado di interconnettere dispositivi e collegamenti che operano
su velocità variabili. I buffer dei pacchetti sono fondamentali quando supportano velocità di
collegamento misto perché forniscono un accoppiamento elastico tra i collegamenti ad alta e
bassa velocità. Questa condizione può portare ad un uso indiscriminato di tail-drop o WRED.
Per limitare questo problema si utilizzano policy o rate-limit che limitano la quantità di traffico
che un apparato può inviare. ponendo dei limiti sulla velocità massima di trasmissione.
Isolation is needed to preserve CoS. Isolamento tra le classi viene fornito dallo scheduler,
ma l’isolamento tra le classi non basta, perchè un utente potrebbe occupare tutte le risorse
della coda, quindi di solito l’isolamento tra le classi viene fatto tra i flussi.
Policing versus shaping Gli utenti tendono a scambiare policy e shaping, ma hanno
funzionalità diverse, anche se nel tempo a parità di parametri la quantità di traffico inviata
non cambia. Lo shaping tende a bafferizzare il traffico, la policy invece tende a tagliare il
traffico in eccesso anche se utilizza il burst per evitare di perdere tanto traffico

Finché i dispositivi a valle non operano vicino alla capacità del buffer, il policing è
generalmente preferito allo shaping, dato che è meno complesso e meno costoso (i buffer
non sono gratuiti) e non induce ulteriori ritardi nel buffering.
Summary of CoS processing steps

Ecco la lista dei processi CoS che un processo segue da quando entra a quando esce:
●​ INGRESS CoS processing
○​ BA classification: Il pacchetto quando arriva al router subisce una BA
Classification.
○​ Multifield classification: Il firewall match diversi header fields, interfacce
d’ingresso ecc per definire la forwarding class, o fare l’override dei valori
settati dalla BA classification
○​ Ingress Policy qui il firewall o interface-level policy vengono applicate per
fare il discard del traffico o marcare il traffico in eccesso
○​ Forwarding policy Questa policy può alterare la forwarding class, e può
essere utilizzata per scegliere il forwarding next-hop basandosi su una
forwarding class, questa feature è detta Class-Based Forwarding (CBF)
●​ Egress CoS processing
○​ Egress policing Il primo processo CoS in uscita è la policy che droppa o
marca a bassa priorità il traffico in eccesso
○​ Rewrite Marker questo è il processo che permette di modificare uno o più
campi del pacchetto da trasmettere al downstream
○​ Queuing and scheduling è il processo che inserisce il pacchetto nella coda
corretta in base alla forwarding class
○​ RED/congestion controll è il processo che droppa i pacchetti in eccesso in
base al protocollo, loss priority ed il riempimento delle code

IP Differentiated Service
Durante gli anni sono state ideate diversi standard di IP CoS solution. L’attuale soluzione è
IP differentiated Service (DiffServ). Vediamo un pò la storia di come si è arrivato

IP ToS
Con la definizione del protocollo IP è stato inserito un campo di 1Byte che identifica il Type
of Service (ToS)
Ip Differentiated Service (DiffeServ) ridefinisce il vecchio campo IP ToS in un campo a 6 bit
chiamato DiffServ Code Point (DSCP). Questo supporta fino a 64 livelli di classificazione
BA.

Alcuni termini da conoscere

 ●​ BA: classificazione basata sul DSCP, i pacchetti che hanno lo stesso DSCP
appartengono alla stessa BA
●​ DiffServ field: è l’originale IPv4 ToS field, il DSCP utilizza i 6 bit più significativi
●​ PHB: è il tipo di forwarding associato ad un BA
●​ PHB group Questo è l’insieme di uno o più PHB che possono implementati
simultaneamente
●​ DiffServ domain: è l’insieme di nodi sotto un comune set di php:
○​ Edge: classificazione, shape, police, mark e queue traffic
○​ Core: Classificazione e queue traffic
●​ DiffServ region: è un insieme di Diffeserv domain contigui

Per creare una class DSCP si utilizzano questi comandi

Una volta creato il classificatore (nell’esempio DEMO-DSCP) si indica l’interfaccia dove

applicarlo
Possiamo anche modificare le regole di DSCP con il comando

Nota bene è buona norma importare il default per non dover specificare tutte le classi.
Una volta definita la regola di rewrite bisogna applicarla all’interfaccia con i comandi set
class-of-service interfaces interface-name unit unit-number rewrite-rules dscp
nome-regola-rewrite
DiffServ PHBs
Ci sono 4 PHBs standardizzati:
1.​ Default PHB: Questo deve essere presente in tutti i nodi DiffServ compliant, ogni
pacchetto non classificato appartiene al gruppo di default
2.​ CS PHB
3.​ EF PHB è associato a servizi con low-latency, low-jitter, low-loss come ad esempio la
voce
4.​ AF PHB è una famiglia di PHBs, chiamati PHB group, utilizzata per classificare i
pacchetti in vari livelli di drop

Input processing
Gli input processing includono BA Classification, multifiedld classification, policing, e
forwarding policy, vediamoli separatamente

BA Classification
La BA CLassification supporta classificazioni su campi L2 o L3
●​ DSCP è una classificazione L3 che supporta fino a 64 livelli nel TOS Byte
●​ IP precedence è una classificazione L3 che supporta 8 livelli nel TOS Byte
●​ MPLS EXP classificazione L2
●​ IEEE 802.1p classificazione L2
Per configurare una BA CLassification si utilizza il livello class-of-service classifier

Se vogliamo definire una classe denominata test, con loss-priority low ed un definito code
point utilizziamo i seguenti comandi

Volendo si può popolare la classe con i valori di default con il comando set import default

[edit class-of-service classifiers inet-precedence test]

root@PE1# show
import default;
forwarding-class best-effort {
loss-priority low code-points 000;
}
Una volta definita la classe allora si applica all’interfaccia:

Multifield classification
Su junos il multifield classification si applica a livello di firewall, vediamo un esempio
[edit firewall filter mf_class]
lab@Bock#show
term udp_port_5555 {
from {
protocol udp;
port 5555;
}
then {
loss-priority high;
forwarding-class best-effort;
accept;
}
}
term default {
then {
loss-priority low;
forwarding-class best-effort;
accept;
}
}

Il comando fa ricordare è forwarding-class sulla parte then del term, una volta definita la
regola di firewall bisogna applicarla all’interfaccia

Policing
Anche le policy vengono configurate a livello di firewall, il traffico in eccesso può essere
scartato, ridotto di priorità oppure marcato.
[edit firewall]
lab@Bock#show
policer EF_policer {
if-exceeding {
bandwidth-limit 128k;
burst-size-limit 2k;
}
then discard;
}
filter mf_class_and_police {
interface-specific3;
3
Questo comando fa in modo che il traffico sia calcolato sul traffico effettivo dell’interfaccia e no sul
traffico complessivo della macchina
 term EF_classify {
from {
protocol udp;
port 6000-6100;
}
then {
policer EF_policer;
forwarding-class expedited-forwarding;
}
}
term other {
then forwarding-class best-effort;
}
}
In questo esempio al traffico che matcha nella mf_class_and_police quindi
nel range di porte UDP dalla 6000 alla 6100 viene applicata la policy
EF_policer, se supera la soglia allora la policy scarta il traffico.

COS policy
COS policy può essere utilizzato in due modi CBF (COS Based Forwarding) e classification
override.
IL CBF viene così configurato
[edit class-of-service forwarding-policy]
next-hop-map map1 {
forwarding-class expedited-forwarding {
next-hop next-hop1;
next-hop next-hop2;
}
forwarding-class best-effort {
next-hop next-hop3;
lsp-next-hop lsp-next-hop4;
}
forwarding-class-default {
lsp-next-hop lsp-next-hop5;
}
}
Il next-hop può essere o un ip o un’interfaccia, mentre lsp-next-hop è un’espressione
regolare.
Nel caso nello stesso term ci sia un next-hop ed un lsp-next-hop, se entrambi sono validi
allora LSP ha priorità.
La modalità classification override invece cambia la classe, per prima cosa bisogna creare
una policy che matcha il traffico
lab@Bock#show policy-options
policy-statement AF_override {
term 1 {
from interface ge-0/0/0.0;
then class reset_to_be;
}
 term 2 {
then accept;
}
}
Poi bisogna creare il class override reset_to_be
[edit]
lab@Bock#show class-of-service
forwarding-policy {
class reset_to_be {
classification-override {
forwarding-class best-effort;
}
}
Ed applicare la policy
[edit]
lab@Bock# show routing-options forwarding-table
export AF_override;