Confronto tra Traffic Policing e Traffic Shaping per limitare la larghezza di banda

Introduzione

In questo documento vengono chiarite le differenze funzionali tra traffic shaping e traffic policing, due tecniche che limitano entrambe la velocità di trasmissione.

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

Questo documento chiarisce le differenze funzionali tra traffic shaping e policing. Entrambi limitano la velocità di output del traffico. Entrambi i meccanismi utilizzano un bucket di token come misuratore del traffico per misurare la velocità del pacchetto. Per ulteriori informazioni sui bucket di token, vedere Che cos'è un bucket di token

I concetti esposti in questo documento continuano a essere rilevanti per la comprensione dei progetti QoS di Cisco. Il Traffic Shaping e il monitoraggio del traffico continuano a essere usati per applicare le velocità massime del traffico e gestire la congestione. Per le nuove implementazioni, Cisco consiglia di utilizzare Modular QoS Command-Line (MQC) class-based shaping e class-based policing, quando supportato dalla piattaforma. I meccanismi legacy, quali GTS (Generic Traffic Shaping), FRTS (Frame Relay Traffic Shaping), CAR (Committed Access Rate) e il comando rate-limit, sono inclusi per il contesto storico o per supportare discussioni specifiche della piattaforma.

Differenze tra traffic policing e traffic shaping

Il traffic shaping propaga i burst. Quando la velocità del traffico raggiunge la velocità massima configurata, il traffico in eccesso viene eliminato (o contrassegnato diversamente). Il risultato è una velocità di trasmissione che appare come un'onda a dente di sega con picchi ad andamento positivo e negativo. A differenza del traffic policing, il traffic shaping mantiene in una coda i pacchetti in eccesso e poi pianifica una trasmissione successiva del traffico in eccesso nell'arco di incrementi temporali. Il risultato del traffic shaping è una velocità di trasmissione dei pacchetti fluida e uniforme.

Nel diagramma successivo vengono illustrate le principali differenze tra le due opzioni di traffico.

Policing VS Shaping

Il traffic shaping implica la presenza di una coda e di una memoria sufficiente per salvare nel buffer i pacchetti rimandati per una trasmissione successiva, a differenza del traffic policing. Le code sono un concetto in uscita; i pacchetti che lasciano un'interfaccia vengono messi in coda e possono essere modellati. Solo il traffic policing può essere applicato al traffico in entrata in un'interfaccia. Quando attivate il shaping, assicuratevi di disporre di memoria sufficiente. Inoltre, il shaping richiede una funzione che programma la trasmissione successiva di qualsiasi pacchetto ritardato. Questa funzionalità di pianificazione consente di organizzare la coda di shaping in code diverse. Esempi di questa funzionalità sono Class Based Weighted Fair Queuing (CBWFQ) e Low Latency Queuing (LLQ).

Criteri di selezione

La tabella seguente elenca le differenze tra il shaping e il policing per agevolare la scelta della soluzione di traffico appropriata.

	Traffic Shaping	Traffic Policing
Comportamento principale	Memorizzare nel buffer e mettere in coda i pacchetti in eccesso rispetto alle velocità di commit.	Elimina (o segnala) i pacchetti in eccesso rispetto alle velocità di commit. Non viene eseguito il salvataggio nel buffer.*
Frequenza di aggiornamento dei token	I token vengono riforniti periodicamente a ogni intervallo Tc. All'inizio di ogni intervallo, lo shaper aggiunge token Bc, fino al limite configurato del bucket. Il Tc è vincolato da limiti specifici della piattaforma.	I token vengono riforniti in base al tempo trascorso tra gli arrivi dei pacchetti. Il policer calcola il numero di token da aggiungere con: ((t - t1) * policer_rate_bps) / 8, dove t - t1 indica il tempo trascorso dal pacchetto precedente.
Valori dei token	Configurato in bit al secondo (bps).	Configurati in byte.
Opzioni di configurazione	Shape in MQC per implementare il shaping basato su classi. Comando Traffic-Shape Frame Relay per implementare FRTS. Traffic-shape per implementare GTS.	Comando police in MQC per implementare il Class-Based Policing. Rate-limit per implementare il comando CAR.
Direzione tipica	In uscita	In entrata o in uscita, dipendente dalla piattaforma
Burst	Controlla i picchi e smussa la velocità di output su almeno otto intervalli di tempo. Utilizza la misurazione del token bucket e accoda i pacchetti in eccesso. I pacchetti in coda vengono rilasciati nel tempo, creando un effetto di lisciatura simile a un bucket con perdita di dati.	Consente i burst entro i limiti di burst configurati. Non memorizza i pacchetti in un buffer per ridurre la velocità di trasmissione.
Vantaggi	Meno probabilità di eliminare i pacchetti in eccesso poiché vengono salvati nel buffer. (Salvataggio nel buffer di un numero di pacchetti pari al massimo alla lunghezza della coda. Le cadute possono verificarsi se il traffico in eccesso viene mantenuto a velocità elevate.) In genere, evita ritrasmissioni a causa di pacchetti eliminati.	Controlla la velocità di trasmissione tramite le perdite di pacchetti. Evita ritardi dovuti a queuingerrori.
Svantaggi	Può introdurre ritardi dovuti a queuingcode particolarmente profonde.	Elimina i pacchetti in eccesso (quando configurati), limita le dimensioni della finestra TCP e riduce la velocità di output complessiva dei flussi di traffico interessati. Dimensioni di burst eccessivamente aggressive possono portare a perdite di pacchetti in eccesso e limitare la velocità di output complessiva, in particolare con i flussi basati su TCP.
Pacchetti contrassegnati diversamente in via opzionale	No	Sì, può facoltativamente trasmettere, eliminare o contrassegnare i pacchetti, incluse le azioni DSCP o IP Precence, a seconda delle azioni del policer MQC configurate e del supporto della piattaforma.

Frequenza di aggiornamento dei token

Una differenza chiave tra shaping e policing è la frequenza con cui i token vengono riforniti. Sia il shaping che il policing utilizzano la metafora del token bucket. Un token bucket non dispone di policy di eliminazione o priorità.

Con funzionalità token bucket: 

• I token vengono inseriti nel bucket a una determinata velocità.

• Ogni token consente all'origine di inviare un determinato numero di bit alla rete.

• Per inviare un pacchetto, il regolatore del traffico deve essere in grado di rimuovere dal bucket un certo numero di token uguale alla dimensione del pacchetto in termini di rappresentazione.

• Se nel bucket non sono presenti token sufficienti per inviare un pacchetto, il pacchetto attende finché il bucket non dispone di token sufficienti (nel caso di uno shaper), oppure il pacchetto viene scartato o contrassegnato (nel caso di un policer).

• Il bucket stesso ha una capacità specificata. Se il bucket riempie la capacità, i nuovi token in arrivo vengono eliminati e non sono disponibili per i pacchetti futuri. Pertanto, in qualsiasi momento, il burst di dimensioni maggiori che una sorgente può inviare alla rete è all'incirca proporzionale alla dimensione del bucket. Un token bucket consente l'esplosione ma la limita.

Il comando Shaping incrementa il bucket di token a intervalli di tempo che utilizzano un valore di bit al secondo (bps). Uno shaper utilizza la formula seguente:

Tc = Bc/CIR (in seconds)

In questa equazione:

• Bc: Burst confermato. La quantità di traffico che è possibile inviare durante un intervallo di tempo.

• CIR: percentuale di informazioni salvate. Frequenza media del traffico applicata dallo shaper o dal policer.

• Tc: Intervallo di tempo impegnato. Intervallo di tempo utilizzato da uno shaper per inviare la frammentazione di cui è stato eseguito il commit mantenendo il CIR configurato in secondi.

L'intervallo per Tc è compreso tra 10 ms e 125 ms. In alcune piattaforme legacy con DTS (Distributed Traffic Shaping), il valore Tc minimo è 4 ms. Il router calcola internamente questo valore in base ai valori di CIR e Bc. Se Bc / CIR è inferiore a 125 ms, utilizza il Tc calcolato da tale equazione. Se il valore Bc/CIR è superiore o uguale a 125 ms, viene utilizzato un valore Tc interno se Cisco IOS determina che il flusso del traffico può essere più stabile con un intervallo inferiore. Utilizzare il comando show traffic-shape per determinare se il router utilizza un valore interno per Tc o il valore configurato nella riga di comando.

mostra output traffico

Quando il burst in eccesso (Be) è configurato su un valore diverso da 0, il traffic shaping consente di memorizzare i token nel bucket, fino a Bc + Be. Il valore massimo che il token bucket possa mai raggiungere è Bc + Be e i token in overflow vengono eliminati. L'unico modo per avere un valore maggiore dei token Bc nel bucket è non utilizzare tutti i token Bc durante uno o più Tc. Poiché il token bucket viene ricaricato a ogni Tc con token Bc, è possibile accumulare token inutilizzati per un uso successivo per un valore massimo pari a Bc + Be.

Al contrario, la policy basata su classi e i token di rifornimento con limitazione della velocità si basano sul tempo trascorso tra gli arrivi dei pacchetti. Quando arriva un pacchetto, il policer calcola il numero di token da aggiungere dall'ora dal pacchetto precedente e dalla frequenza del policer configurata. In particolare, la velocità di arrivo dei token viene calcolata come segue:

Tokens added = ((t - t1) * policer_rate_bps) / 8 bytes

In altre parole, se l'arrivo precedente del pacchetto era a t1 e il momento corrente è t, il bucket viene aggiornato con byte di valore t-t1 in base alla velocità di arrivo del token. 

Questo è un esempio in cui si usa un CIR (o frequenza policer) di 8000 bps e un normale burst di 1000 byte:

Router(config)#policy-map police-setting 
Router(config-pmap)#class access-match 
Router(config-pmap-c)#police 8000 1000 conform-action transmit exceed-action drop 

I bucket di token iniziano completi a 1000 byte. Un pacchetto da 450 byte in arrivo è conforme perché nel token bucket sono disponibili abbastanza byte. L'azione di conformità (trasmissione) viene effettuata dal pacchetto e 450 byte vengono rimossi dal bucket di token (e rimangono 550 byte). Se il pacchetto successivo arriva 0,25 secondi dopo, vengono aggiunti 250 byte al bucket del token, come indicato nella formula seguente:

(0.25 * 8000)/8

1. Inizio periodo fisso completo:

   • Normal burst = 1000 byte
   • Token iniziali =1000 byte

2. Arrivo primo pacchetto:

   • Dimensioni pacchetto = 450 byte
   • Il pacchetto è conforme perché il bucket dispone di un numero sufficiente di token.
   • Il policer rimuove 450 byte di token dal bucket.

   Calcolo: 1000 - 450 = 550 byte rimanenti

3. Il pacchetto successivo arriva 0,25 secondi dopo:

   • Velocità Policer = 8000 bps
   • Token aggiunti durante 0,25 secondi:

   (0,25 × 8000) / 8 = 250 byte

4. Periodo fisso dopo l'aggiornamento:

   • Token esistenti rimanenti = 550 byte
   • Nuovi token aggiunti = 250 byte

   Calcolo: 550 + 250 = 800 byte

Il calcolo lascia 800 byte nel bucket di token (token rimanenti nel bucket di policer). Se il pacchetto successivo è di 900 byte, questo risulta in eccesso e viene eseguita l'azione exceed action (drop). Nessun byte viene preso dal token bucket.

Traffic Shaping

Cisco IOS® supporta i seguenti metodi di traffic shaping:

• GTS (Generic Traffic Shaping)

• FRTS (Frame Relay Traffic Shaping)

• Class-Based Shaping e Distributed Class-Based Shaping

Tutti i metodi di traffic shaping presentano un'implementazione simile, anche se le interfacce a riga di comando (CLI) sono in qualche modo diverse, e utilizzano diversi tipi di code per contenere e controllare il traffico che viene rinviato. Cisco consiglia il class-based shaping e il distributed shaping, configurati con la CLI QoS modulare.

Nel diagramma successivo viene illustrato come un criterio QoS dispone il traffico in classi e accoda i pacchetti che superano le velocità di shaping configurate.

Traffic Policing

Cisco IOS supporta i seguenti metodi di monitoraggio del traffico:

• CAR (Committed Access Rate)

• Class-Based Policing

I due meccanismi presentano importanti differenze funzionali, come spiegato in Come configurare il policing basato su classi. Cisco consiglia il policing basato su classi e altre funzionalità della CLI QoS modulare quando vengono applicati i criteri QoS.

Usare il comando Police per specificare che a una classe di traffico deve essere imposta una velocità massima e, se questa velocità viene superata, è necessario eseguire un'azione immediata. In altre parole, con il comando police, non è possibile salvare il pacchetto nel buffer e inviarlo in un secondo momento, come nel caso del comando shape.

Inoltre, con il traffic policing, il token bucket determina se un pacchetto è in eccesso o è conforme alla velocità applicata. In entrambi i casi, il policing implementa un'azione configurabile, che include la precedenza IP o il DSCP (Differentiated Services Code Point).

Il diagramma successivo mostra un'applicazione comune del traffic policing in un punto di congestione, dove normalmente si applicano le funzionalità QoS.

Controlli per la larghezza di banda minima e massima

I comandi shape e Police limitano il traffico a una velocità massima configurata. In MQC, la velocità configurata per la media delle forme e la polizia è specificata in bps, a meno che la sintassi specifica della piattaforma non indichi diversamente. È importante sottolineare che nessuno dei due meccanismi fornisce una garanzia di larghezza di banda minima durante i periodi di congestione. Utilizzare il comando bandwidth o priority per fornire tali garanzie.

Un criterio gerarchico utilizza due criteri di servizio: un criterio padre per applicare un meccanismo QoS a un'aggregazione di traffico e un criterio figlio per applicare un meccanismo QoS a un flusso o a un subset dell'aggregazione. Le interfacce logiche, ad esempio le sottointerfacce e le interfacce tunnel, richiedono un criterio gerarchico con la funzionalità trafficolimiting al livello padre e con l'accodamento ai livelli inferiori. La funzione traffic-limiting riduce la velocità di uscita e (presumibilmente) crea una congestione, come dimostrano i pacchetti in queuing eccesso.

La configurazione successiva non è ottimale ed è mostrata per illustrare la differenza tra il comando Police e il comando Shape quando limiting il traffico viene aggregato, in questo caso per impostazione predefinita in base alla classe, a una velocità massima. In questa configurazione, il comando Police invia i pacchetti dalle classi figlie in base alle dimensioni del pacchetto e al numero di byte che rimangono nei bucket di conformità e che superano i bucket dei token. (Consultare Traffic Policing.) Di conseguenza, le tariffe fornite alle classi VoIP (Voice over IP) e IP (Internet Protocol) non possono essere garantite, poiché la funzionalità di polizia ignora le garanzie fornite dalla funzionalità di priorità.

Tuttavia, se si utilizza il comando shape, il risultato è un sistema di accodamento gerarchico e tutte le garanzie vengono fornite. In altre parole, quando il carico offerto supera la velocità di shaping, la velocità delle classi VoIP e IP è garantita e il traffico di classe predefinita (al livello secondario) subisce eventuali perdite.

Attenzione: Questa configurazione non è consigliata e viene mostrata per illustrare la differenza tra il comando Police rispetto a Shape quando limita un'aggregazione di traffico.

class-map match-all IP 
   match ip precedence 3 
class-map match-all VoIP 
   match ip precedence 5 
!  
policy-map child 
  class VoIP 
     priority 128 
   class IP 
     priority 1000 
! 
 policy-map parent 
   class class-default 
     police 3300000 103000 103000 conform-action transmit exceed-action drop 
     service-policy child

Affinché la configurazione precedente abbia senso, è necessario sostituire la policy con la shaping. Ad esempio:

policy-map parent
    class class-default
     shape average 3300000 103000 0
     service-policy child

Utilizzare show policy-map interface <interface> per verificare che i criteri configurati, i contatori di classe, la velocità offerta, i contatori di rilascio, la velocità di shaping, la profondità della coda e i contatori di conformazione, superamento o violazione del policer siano conformi.

Router#show policy-map interface gigabitEthernet 0/0/2
 GigabitEthernet0/0/2 

 Service-policy output: parent 
    Class-map: class-default (match-any)  
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: any 
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 0/0
 shape (average) cir 3300000, bc 103000, be 0 target shape rate 3300000 
 Service-policy : child 
        queue stats for all priority classes:
          Queueing
          queue limit 512 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0

        Class-map: VoIP (match-all)  
          0 packets, 0 bytes
          5 minute offered rate 0000 bps, drop rate 0000 bps
          Match: ip precedence 5 
 Priority: 128 kbps, burst bytes 3200, b/w exceed drops: 0           

        Class-map: IP (match-all)  
          0 packets, 0 bytes
          5 minute offered rate 0000 bps, drop rate 0000 bps
          Match: ip precedence 3 
 Priority: 1000 kbps, burst bytes 25000, b/w exceed drops: 0           

        Class-map: class-default (match-any)  
          0 packets, 0 bytes
          5 minute offered rate 0000 bps, drop rate 0000 bps
          Match: any 
          
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0

Nota: Per ulteriori informazioni sui criteri padre e figlio, fare riferimento a QoS: Criteri di servizio figlio per classe di priorità.

L'esempio precedente è intenzionalmente subottimale ed è fornito solo per illustrare la differenza tra policing e shaping in un criterio QoS gerarchico. In una progettazione QoS consigliata, il comando priority è in genere riservato al traffico in tempo reale, sensibile alla latenza, come il traffico vocale. Le classi non in tempo reale che richiedono una larghezza di banda minima garantiscono in genere l'utilizzo del comando bandwidth con CBWFQ.

Questo approccio è in linea con le linee guida di progettazione QoS di Cisco per LLQ e CBWFQ. LLQ fornisce un rigoroso trattamento di priorità per il traffico sensibile al ritardo, mentre CBWFQ fornisce garanzie di larghezza di banda per altre classi di traffico durante la congestione. Pertanto, la classe IP nell'esempio riportato è rappresentata in modo migliore con la larghezza di banda anziché con la priorità, a meno che la classe non trasporti un traffico che richiede esplicitamente un trattamento di priorità rigorosa.

policy-map child
 class VoIP
  priority 128
 class IP
  bandwidth 1000

Informazioni correlate

• Supporto tecnologico per Qualità del servizio (QoS)
• Documentazione e supporto tecnico – Cisco Systems

Cronologia delle revisioni

Revisione	Data di pubblicazione	Commenti
6.0	21-Jul-2026	Certificazione.
4.0	07-Sep-2023	Aggiornamento dei requisiti di personalizzazione, SEO, grammatica e formattazione.
3.0	26-Sep-2022	Certificazione
1.0	15-Feb-2002	Versione iniziale