Perché la QoS è una scelta di design, non un ritocco a fine progetto
In ENSLD la QoS non è “abilitare una feature”, ma decidere quale modello di servizio adottare in funzione dei requisiti applicativi (voce, video, dati transazionali) e dove collocare i confini di fiducia. Il progettista sceglie il modello, la strategia di classificazione/marking e la posizione del trust boundary prima di scrivere qualsiasi policy.
I tre modelli di servizio
| Modello | Meccanismo | Stato | Scalabilità | Uso tipico |
|---|---|---|---|---|
| Best Effort | FIFO, nessuna differenziazione | Nessuno | Massima | Traffico non critico, default |
| IntServ | Prenotazione per-flusso via RSVP | Per-flow (stateful) | Scarsa | Flussi singoli con garanzie hard |
| DiffServ | Classi aggregate via PHB su DSCP | Per-hop, stateless | Alta | Reti enterprise moderne |
Best Effort non offre garanzie: tutto compete nella stessa coda. Serve come baseline e come classe per il traffico “scavenger”.
IntServ usa RSVP per segnalare e riservare risorse lungo l’intero path, offrendo garanzie di banda e ritardo per singolo flusso (guaranteed e controlled-load). Il costo è la stateful reservation su ogni hop: non scala su reti grandi, quindi in design enterprise si usa solo in nicchie (es. RSVP per CAC voce, spesso in forma “IntServ over DiffServ”).
DiffServ è il modello di riferimento: il traffico viene marcato ai bordi e ogni router applica un Per-Hop Behavior (PHB) in base al valore DSCP, senza mantenere stato per flusso. È la scelta di default in un progetto ENSLD perché combina differenziazione e scalabilità.
Classification e marking: DSCP vs CoS
La classificazione identifica il traffico (ACL, NBAR, porta, protocollo); il marking scrive un valore che gli hop successivi useranno per fidarsi senza riclassificare.
- DSCP — 6 bit nel campo ToS/Traffic Class dell’header IP (Layer 3). Sopravvive a tutta la rete instradata. Valori chiave: EF (46) per la voce, CS6 per il routing, la famiglia AF (es. AF41 per video interattivo), CS/Default 0 per best effort.
- CoS — 3 bit (PCP) nel tag 802.1Q (Layer 2). Esiste solo su link trunk; si perde appena il frame attraversa un segmento non taggato o esce dalla VLAN.
Principio di design cardine: marcare il più vicino possibile alla sorgente e con DSCP, così il marking persiste end-to-end anche quando il CoS scompare.
Il trust boundary
Il trust boundary è il punto oltre il quale i valori QoS in ingresso vengono accettati come attendibili. La regola di progetto è spingerlo il più vicino possibile a una sorgente affidabile:
- Endpoint gestito e fidato (es. IP phone Cisco): il boundary può stare sull’endpoint stesso.
- Access switch: quando l’endpoint non è fidato, il boundary è la porta di accesso, che rimarca il traffico secondo la policy.
- Distribution: posizione di ripiego, meno ideale perché il traffico non marcato ha già attraversato la rete.
Con un IP phone si usa la conditional trust: lo switch, riconoscendo il telefono via CDP/LLDP, si fida del marking del telefono ma non di quello del PC collegato dietro, che viene forzato a un valore basso.
Mappatura tra domini QoS
Ai confini fra domini (L2↔L3, enterprise↔service provider) i valori vanno rimappati esplicitamente. Uscendo da un dominio Layer 2 il CoS si perde, quindi il DSCP deve portare l’informazione. Verso un SP il proprio modello a molte classi va compresso nelle classi contrattuali del provider (SLA), spesso riducendo DSCP a un numero minore di PHB. Non progettare questa traduzione significa perdere la priorità al primo salto fuori dominio.
Trappole tipiche d’esame
- Scenario: PC utente non gestito marca il proprio traffico come EF per “rubare” priorità alla voce → Risposta giusta: non fidarsi del marking in ingresso; impostare il trust boundary all’access edge e rimarcare (o azzerare a DSCP 0) il traffico dell’endpoint non fidato.
- Scenario: serve QoS scalabile end-to-end su un campus enterprise → Risposta giusta: DiffServ con marking DSCP ai bordi; non IntServ/RSVP, che è stateful e non scala.
- Scenario: la priorità voce si perde dopo il primo router → Risposta giusta: si stava marcando in CoS (Layer 2), che non sopravvive all’instradamento; marcare in DSCP vicino alla sorgente.
- Scenario: IP phone Cisco con PC collegato in daisy-chain → Risposta giusta: conditional trust — fidarsi del marking del telefono via CDP, rimarcare quello del PC.
- Scenario: interconnessione col service provider con poche classi contrattuali → Risposta giusta: definire una QoS domain mapping che comprime i DSCP interni nelle classi SLA del provider al boundary.