IMPLEMENTAZIONE DEL SERVIZIO DI QoS Premium IP SULLA RETE GARR

Transcript

1 IMPLEMENTAZIONE DEL SERVIZIO DI QoS Premium IP SULLA RETE GARR Revisione: V1.9 Data: 08 Maggio 2007 Autori: Fabrizio Ferri, Alessandro Pancaldi Status: Final version

2 REVISIONI Revisione Data Modifiche V.01 Draft 8 Settembre 2006 Tutto il traffico IP con DSCP diverso da 46, 48 e 52 viene riscritto a 0. Review del documento effettuata da Mauro Campanella V.02 Draft 13 Settembre 2006 Cambiata la configurazione per consentire la trasparenze del DSCP: solo ai pacchetti IP con DSCP=46 provenienti da sorgenti IP non Premium subiscono il rewrite a 0 del DSCP. Inserita la descrizione dei meccanismi di CoS utilizzati con pseudo-codice. V.02.1-Draft 15 Settembre 2006 Correzioni varie e review di Mauro Campanella V.02.2-Draft 19 Settembre 2006 Modularizzato il filtro per il controllo del traffico in ingress nelle interfacce di accesso e di backbone; il filtro d ingresso è stato diviso in tre componenti Inserito il filtro per interfacce ATM su cui non è presente il servizio PIP Inserito capitolo limiti di erogazione del servizio PIP Inserite le correzioni di M. Campanella V.03.0-Draft 20 Settembre 2006 A causa dell impossibilità di ottenere la trasparenza del DSCP sugli M320 sono stati modificati i classifier, rewrite rule ed aggiunta l appendice A. V.03.1-Draft 27 Settembre 2006 Modificata la configurazione: utilizzati i gruppi di JUNOS, definita la configurazione per l erogazione di PIP sulle interfacce ATM Effettuati test in rete per la verifica dello scheduler delle interfacce ATM V.03.2-Draft 2 Ottobre 2006 Corretto filtro COMMON Aggiunta brevissima descrizione filtro DEFAULT_ACCEPT Aggiunta appendice sui gruppi JUNOS Correzione refusi e revisione generale V.03.3-Draft 18 Ottobre 2006 Corretto pseudo-codice e filtro COMMON Correzione refusi e revisione generale V Ottobre 2006 Prove di traffico Premium con utilizzatori connessi a GARR Preliminary attraverso un router M5 dotato di interfaccia ATM-1. version V1.1-V1.5 4 Dicembre 2006 Stesura capitoli V Dicembre 2006 Aggiunta del capitolo Scopo del documento V Febbraio 2007 Inserita descrizione del Premium IP su router Cisco di accesso V Febbraio 2007 Revisione di tutto il documento effettuata da Massimo Carboni V Febbraio 2007 Revisione di tutto il documento effettuata da Ugo Monaco V Maggio 2007 Revisione generale effettuata da Federica Tanlongo 2(88) 24/02/2005

3 INDICE 1 SCOPO DEL DOCUMENTO INTRODUZIONE ALLA QoS Ritardo (Delay) Jitter Perdite di pacchetti Architettura IntServ Architettura DiffServ SERVIZIO PREMIUM IP Erogazione del servizio Premium IP intradomain CoS sulle interfacce di accesso al dominio PIP CoS sulle interfacce di backbone del dominio PIP Dettagli di Configurazione del Servizio Premium IP INTERFACCE DI ACCESSO AL DOMINIO PIP Traffico di ingress nelle interfacce di accesso Traffico di ingress nelle interfacce di accesso connesse a sorgenti Premium Traffico di ingress nelle interfacce di accesso non connesse a sorgenti Premium Traffico di egress sulle interfacce di accesso del dominio PIP Scheduler sulle interfacce d accesso del dominio PIP Scheduler sulle interfacce d accesso ATM del dominio PIP DSCP rewrite sulle interfacce d accesso nel dominio PIP INTERFACCE DI BACKBONE NEL DOMINIO PIP Traffico di ingress sulle interfacce di backbone del dominio PIP Traffico di egress sulle interfacce di backbone nel dominio PIP Scheduler sulle interfacce di backbone nel dominio PIP DSCP rewrite sulle interfacce di backbone nel dominio PIP RILASCIO PREMIUM IP SULLA RETE GARR DESCRIZIONE DETTAGLIATA CONFIGURAZIONE GARR Configurazioni d accesso Configurazione Interfacce di Accesso ATM Configurazione di Backbone Estratto di configurazione PIP sul router RT1.BO Limiti della configurazione presenza di IPv6 su alcuni nodi della rete APPENDICE A Problemi di trasparenza del DSCP Rewrite Rules e PLP REWRITE sulle interfacce IQ PIC Limiti HW APPENDICE B: funzionamento della CoS sul JUNOS Scheduler sul JUNOS (88) 24/02/2005

4 10 APPENDICE C:Utilizzo dei Gruppi nel JUNOS APPENDICE D: test di traffico Premium con IRA-INAF APPENDICE E: Servizio Premium IP sui router di accesso Cisco Weighted Fair Queuing CLASS BASED WEIGHTED FAIR QUEUING CONFIGURAZIONE DEL CBWFQ BENEFICI DEL CBWFQ Restrizioni IMPLEMENTAZIONE PREMIUM IP SU CISCO RISULTATI DEI TEST CON LINK FAST ETHERNET Test in assenza del servizio Premium IP Test in presenza di Premium IP RISULTATI DEI TEST CON LINK ATM E3 (34Mbps) GLOSSARIO REFERENCE (88) 24/02/2005

5 1 SCOPO DEL DOCUMENTO Il presente documento descrive i criteri utilizzati per l erogazione del servizio Premium IP (PIP) sulla rete GARR. Per la definizione del servizio di Premium IP si veda il progetto SEQUIN [1] mentre per le modalità di erogazione del servizio è utile consultare il deliverable di GEANT2 sulle Policy for allocation of Premium IP [2]. Il presente documento introduce in prima istanza alcuni concetti riguardanti la QoS, prosegue con il confronto tra due architetture proposte per l implementazione della QoS in reti IP (IntServ e DiffServ) e continua descrivendo il paradigma utilizzato per l erogazione del servizio Premium IP in modalità intradominio analizzandone anche le componenti. Viene descritto l uso e la funzione delle componenti di classificazione, policing e rewrite sia per le interfacce di accesso che di backbone. La restante parte del documento prende dettagliatamente in esame meccanismi e comandi utilizzati per l implementazione del servizio sui router Juniper della rete GARR. La QoS è un meccanismo hardware e software in grado di discriminare e privilegiare alcuni tipi di traffico all interno di una rete IP best effort. Il servizio di QoS può essere implementato mediante due tipi di architetture: Intserv e Diffserv. Il Premium IP è un servizio che si prefigge di realizzare il trasporto end-to-end di traffico bidirezionale privilegiato (Premium), con prestazioni paragonabili a quelle ottenibili su Circuito Diretto Numerico (CDN). Analogamente a quanto accade per un link CDN, al superamento della quantità di traffico Premium contrattualizzato, quello in eccesso viene comunque scartato. Una connessione Premium IP realizza quindi una virtual leased line tra due end-point della rete. Premium IP utilizza un architettura di tipo DiffServ (approccio Per Hop Behaviour). Ogni router della rete su cui è presente un servizio Premium IP decide per proprio conto, le politiche di trattamento dei flussi di traffico entranti ed uscenti (disciplina Per Hop Behaviour), pertanto le politiche per il trattamento dei traffici devono essere coerenti su tutti i router della rete. Va notato che i meccanismi di QoS intervengono SOLAMENTE IN CASO DI SATURAZIONE DEL LINK. Il traffico Premium IP in transito sulla rete viene identificato mediante l utilizzo di una porzione del campo TOS dell header IP, denominata DSCP e corrispondente al valore decimale 46. Il servizio Premium IP per le sue peculiarità ben si presta in applicazioni di tipo interattivo, per videoconferenza e VOIP. 2 INTRODUZIONE ALLA QOS La reti IP nascono originariamente per fornire un servizio di consegna dei pacchetti di tipo best effort: tutti i componenti di rete coinvolti nell'inoltro dei pacchetti, dalla sorgente verso la destinazione, operano in modo da fornire il miglior servizio di consegna ottenibile senza alcuna garanzia di inoltro. Nelle reti IP con consegna best effort tutti i pacchetti vengono trattati allo stesso modo e sono normalmente serviti da router con una disciplina FIFO (First In First Out) ed inoltrati senza controllo alcuno su throughput e latenza. 5(88) 24/02/2005

6 In una rete ipotetica a basso traffico le poche applicazioni presenti non competono per l allocazione della banda sperimentando una perdita di pacchetti nulla, ritardi contenuti e poco variabili. La realtà è più complessa in quanto più utenti che utilizzano simultaneamente la rete entrano in competizione per l allocazione di porzioni rilevanti della banda disponibile. La variabilità temporale dei dati applicativi, sia nella direzione che nelle quantità, introduce effetti indesiderati quali: una variabilità nel ritardo di trasferimento dei pacchetti (jitter); uno scarto dei pacchetti nel caso in cui il traffico transiti su un link saturo. Questi due effetti possono degradare il servizio offerto in applicazioni sensibili a questo tipo di parametri, come ad esempio quelle di videoconferenza e voce. 2.1 RITARDO (DELAY) Il ritardo (o latenza) di trasferimento è il tempo intercorso tra la trasmissione e la ricezione di un pacchetto tra due punti della rete. Esistono diversi fattori che contribuiscono al ritardo di trasferimento sperimentato da un pacchetto nell attraversamento di una rete IP: Ritardi di inoltro (forwarding delay). Il forwarding delay è il tempo che intercorre tra la ricezione di un pacchetto e il suo inoltro sulla coda dell interfaccia di uscita dell apparato, includendo anche il tempo necessario per risolvere l instradamento del pacchetto. Il ritardo di inoltro rappresenta quindi il tempo di attraversamento minimo dell apparato. Tale ritardo nei router è dell ordine dei 10µsec-100µsec, ed è dipendente dalla piattaforma hardware utilizzata; l amministratore di rete non ha nessuna possibilità di controllare il forwarding delay. Ritardi di accodamento. Il ritardo di accodamento è la quantità di tempo che un pacchetto deve attendere nelle code delle interfacce di uscita: è dipendente dal numero di pacchetti accodati da servire prima di esso e dalla loro dimensione. Durante i momenti di congestione, la gestione della profondità delle code (ovvero della memoria allocata nelle code) e la disciplina di scheduling adottata per svuotarle permettono di controllare il tempo di accodamento sperimentato dalle differenti classi di traffico poste nelle diverse code. Ritardi di trasmissione o di serializzazione. Il ritardo di serializzazione è il tempo impiegato dal router per inviare i bit del pacchetto sulla linea di trasmissione. I tempi necessari alla serializzazione dei pacchetti sul link sono dipendenti dalla lunghezza (L) del pacchetto e dalla velocità del link (B). Per esempio un pacchetto di 64Byte è serializzato su un link E1 in L/B=[64*8/2x10 6 )]sec 200µs. Ritardi di propagazione. Sono i tempi necessari ad un pacchetto per viaggiare su una certa distanza su uno specifico mezzo. La velocità della luce attraverso una fibra ottica è minore che nel vuoto e generalmente è pari a 0.6*c dove c è la velocità della luce nel vuoto ( 300x10 3 km/s). Per esempio, il ritardo di propagazione su una tratta Roma- Milano di circa 700km, è pari a [700/(0,6x300x10 3 )]s 3,8ms a cui corrisponde un ritardo di propagazione nel round-trip time di 7,6 ms. 6(88) 24/02/2005

7 D(forwarding) D(queuing) D(serializzazione) D(propagazione) D(R1) D(Link1) Ingress router Egress router Figura 1: ritardi di trasferimento Il ritardo end-to-end è determinato dalla somma dei ritardi di instradamento, di accodamento, di serializzazione e di propagazione che si verificano ad ogni nodo e link della rete. I pacchetti di un flusso non sperimentano tutti lo stesso ritardo di trasferimento attraverso la rete, in quanto il ritardo di ogni singolo pacchetto dipende dallo stato di congestione della rete ad uno specifico istante di tempo. In caso di link non congestionati, i pacchetti non presentano un ritardo di accodamento rilevante ed il ritardo complessivo del pacchetto sarà influenzato esclusivamente da quello di trasmissione e propagazione; tale ritardo costituisce il ritardo minimo comunque introdotto dalla rete. Sui link ad alta velocità, il ritardo di trasmissione è trascurabile rispetto al ritardo di propagazione. La sola componente controllabile del ritardo end-to-end è il ritardo nell accodamento: durante gli intervalli di tempo in cui si verifica la congestione di rete, è necessario utilizzare meccanismi in grado di differenziare il traffico in base alle sue diverse tipologie. 2.2 JITTER Il jitter (definito anche come one-way IP delay variation) è la variazione del ritardo sperimentato da pacchetti consecutivi che fanno parte dello stesso flusso. Indicato con: T k l istante di tempo in cui la sorgente invia in rete il pacchetto k; R k l istante di tempo in cui il ricevente ottiene il pacchetto k; T k+1 l istante di tempo in cui la sorgente inviato in rete il pacchetto k+1; R k+1 l istante di tempo in cui il ricevente ottiene il pacchetto k+1. il jitter tra i due pacchetti k e k+1 è: jitter (k)=(r k+1 -T k+1 )-(R k -T k ) 7(88) 24/02/2005

8 Sorgente flusso costante di pacchetti I pacchetti arrivano spaziati in modo impredicibile Ricevitore Rete IP Figura 2: visualizzazione di effetti di jitter dovuti a transito sulla rete IP Analogamente al ritardo, anche il jitter aumenta con l incremento dell utilizzazione della banda. Le reti a multiplexing statistico (come le reti a commutazione di pacchetto) non presentano mai un jitter end-to-end nullo perchè il grado di occupazione della rete varia istante per istante. 2.3 PERDITE DI PACCHETTI In una rete IP esistono tre cause che determinano la possibile perdita di pacchetti: Rottura del link fisico. Anche in topologie di rete protette, a seguito di rottura di link fisici, possono verificarsi delle perdite di pacchetti per intervalli di tempo limitati. Questo fenomeno è dovuto al tempo necessario al router per effettuare il reinstradamento su link alternativi. Rumore presente sui link. I pacchetti in transito sui link rumorosi possono subire alterazioni rilevate e corrette dal router mediante checksum; nel caso in cui l algoritmo non sia in grado di effettuare la correzione d errore i pacchetti corrotti vengono scartati. Congestione di rete. In presenza di congestione di rete è possibile si verifichi lo scarto di pacchetti (drop packet). Se il numero di pacchetti concorrenti in attesa di essere inoltrati su una interfaccia di uscita è troppo elevato, il router non è in grado di procedere in modo sufficientemente veloce al loro smaltimento ed pertanto è costretto ad inserire i pacchetti su particolari buffer (denominati code) presenti sulla interfaccia di uscita. Se il rate di pacchetti diretti sull interfaccia di uscita rimane sostenuto per un significativo lasso di tempo, si può verificare il riempimento delle code delle interfacce di uscita che costringe il sistema allo scarto di pacchetti dal fondo della coda (tail-drop). I ritardi di accodamento influenzano il ritardo end-to-end e contribuiscono ad aumentare le variazioni di ritardo tra pacchetti consecutivi (jitter). La ragione principale di perdita di pacchetti è dovuta a condizioni di buffer overflow, causate da congestione. Riassumendo, le reti IP non trasportano un carico costante, poiché il traffico è inviato a raffiche e ciò determina una variabilità del carico di rete, è pertanto possibile che esistano intervalli di tempo durante i quali i volumi di traffico eccedono la capacità di alcuni link della rete. Quando si verifica tale situazione, il router della rete che entra in congestione tenta di ridurre il suo carico scartando i pacchetti. L obiettivo dei servizi di QoS consiste nel diversificare il traffico, mediante meccanismi hardware e software, garantendo il trasporto del traffico privileggiato anche nei momenti di congestione. 8(88) 24/02/2005

9 È opportuno evidenziare che la QoS non è un meccanismo con caratteristiche magiche, in grado di generare una quantità di banda maggiore di quella nominale disponibile sul link. La QoS può essere utilizzata, entro certi limiti, per far fronte a situazione temporanee di saturazione dei link. Un link che lavora per la totalità del tempo in prossimità della saturazione è un link poco utilizzabile ed in tal caso la soluzione è migliorabile solamente passando ad un link fisico a maggiore capacità. Esistono fondamentalmente due tipi di architetture per la QoS proposte nell ambito delle reti IP: Architettura Integrated Services (denominato anche come IntServ), definito nell'rfc1633 che lavora in congiunzione con il protocollo Resource reservation Protocol (RSVP). Architettura Differentiated Services (indicato nel seguito come DiffServ), definito dall RFC2475. Questo è il modello utilizzato nella realizzazione del servizio di rete Premium IP. 2.4 ARCHITETTURA INTSERV Integrated Services (IntServ) è stata la prima architettura progettata per offrire un servizio di trasporto del traffico IP migliore del best effort. Il modello IntServ è stato introdotto per soddisfare le esigenze del traffico real-time: garanzia e predicibilità del servizio. L architettura IntServ è basata sulla possibilità di riservare risorse di rete per ogni flusso e pertanto è in grado di garantire determinati parametri di QoS richiesti dai flussi di traffico. I componenti principali per la realizzazione del modello IntServ sono i seguenti: Packet Scheduler Lo scheduler si occupa della spedizione dei pacchetti dei diversi flussi usando un insieme di code ed altri meccanismi basati ad esempio su timer. Deve essere implementato dove i pacchetti sono accodati, cioè tipicamente nell'output del sistema. Lo scheduler decide inoltre quali pacchetti scartare in caso di sovraccarico del router ed implementa anche funzioni di stima del traffico, analizzandolo e traendone statistiche utilizzabili ad esempio per il policing. Classifier Per effettuare il controllo del traffico, ogni pacchetto entrante viene mappato in una specifica classe, associando flussi con caratteristiche comuni alla stessa classe. Tutti i pacchetti appartenenti ad una stessa classe riceveranno lo stesso trattamento dallo scheduler. La scelta della classe appropriata è effettuata localmente da ogni router e riflette l'importanza che il router dà al singolo flusso. È ad esempio possibile effettuare classificazione in base agli indirizzi sorgente e destinazione, al protocollo oppure in base al numero di porta. Admission Control 9(88) 24/02/2005

10 È l algoritmo di decisione che il router utilizza per stabilire se può garantire o meno la qualità del servizio richiesta da un nuovo flusso senza influenzare le richieste precedentemente accettate. Nel modello IntServ ogni flusso può ricevere una prefissata qualità del servizio, negoziata all'inizio tra l'applicazione e la rete tramite il protocollo RSVP. Prima di iniziare la trasmissione, utilizzando l'rsvp, l applicazione deve costruire i percorsi e riservare le risorse, la rete viene quindi configurata in modo da garantire che tutti i pacchetti di quel prestabilito flusso possano beneficiare della stessa qualità del servizio. Il protocollo RSVP è usato dagli host per richiedere una specifica qualità del servizio alla rete, ma è anche usato dai router per spedire informazioni sulla qualità del servizio lungo il percorso seguito dal flusso, al fine di stabilire e mantenere la classe di servizio richiesta. Il modello IntServ richiede che gli host sorgente e destinazione scambino una segnalazione RSVP in modo da configurare, su ogni router attraversato, i meccanismi di classificazione e accodamento in grado di garantire i parametri richiesti. Routing Message Routing RSVP Admission Control RSVP Message Control Plane Data in Forwarding Table Per flow QoS base Data out Route Lookup Classifier Scheduler Figura 3: architettura di un router che lavora in modalità IntSrv Data Plane L architettura IntServ ha il vantaggio di garantire i parametri di QoS richiesti dai flussi di traffico, ma presenta alcune notevoli debolezze brevemente elencate di seguito: non è scalabile su grandi reti poiché richiede la memorizzazione dello stato dei flussi e l elaborazione dei pacchetti su tutti i router lungo il percorso end-to-end. richiede che le applicazioni presenti sugli host siano in grado di gestire il protocollo RSVP. Subentra quindi anche un problema di disponibilità sul sistema operativo di API RSVP utilizzabili per la scrittura di applicazioni in grado di richiedere la riservazione di flussi. tutti i router della rete lungo il percorso tra gli host sorgente e destinazione dei flussi devono supportare il modello IntServ. 10(88) 24/02/2005

11 2.5 ARCHITETTURA DIFFSERV A differenza del precedente, il modello DiffServ non memorizza le informazioni di stato per ogni singolo flusso che richiede qualità del servizio. Per questo motivo è un paradigma scalabile, ma non è in grado da solo di garantire in senso assoluto dei parametri di QoS dichiarati dai flussi di traffico. Questa architettura prevede che il traffico in ingresso alla rete subisca un effetto di condizionamento in cui i flussi vengono identificati e classificati sulla base di un campo dell header IP denominato Differenziated Service (DS) field. Ad ogni DS è associata una diversa strategia di inoltro che determina il modo in cui i pacchetti vengono gestiti in ogni router della rete (Per-Hop Behaviour, PHB). In tal caso non è necessario impiegare alcun protocollo di segnalazione nè immagazzinare informazioni sullo stato della rete: ogni router, per la gestione dei flussi, mantiene ed utilizza esclusivamente le proprie informazioni. Nel caso di pacchetti IPv4, la funzione di DS field è assolta da una porzione del campo TOS (Type of Service) ed i valori che può assumere sono denominati Differenziated Service CodePoint (DSCP). Solo i sei bit più significativi del campo TOS sono utilizzati per codificare i valori del DS field, mentre i rimanenti due bit meno significativi sono inutilizzati e riservati per usi futuri DSCP ECN TOS Figura 4: formato del campo TOS dell header del pacchetto IP L IETF working group ha definito i seguenti valori di DSCP: Default DSCP. È un valore di DSCP con i 6 bit tutti a zero. È il valore raccomandato per il traffico Best Effort. Class Selector DSCP 1. Sono DSCP definiti per avere una compatibilità con l IP Precedence. La seguente tabella descrive i valori assegnabili alle classi di precedenza. Nome Class Selector DSCP Mnemonico cs1 Precedence cs2 Precedence cs3 Precedence Specificato nell RFC (88) 24/02/2005

12 cs4 Precedence cs5 Precedence cs6 Precedence cs7 Precedence Expedite Forwarding (EF) PHB 2. L Expedited Forwarding è utilizzato in un dominio Diffserv per fornire un servizio end-to-end a banda garantita con basso numero di pacchetti persi, bassa latenza, basso jitter. Questo tipo di assegnazione è raccomandata per applicazioni come il VoIP ed il video. L EF può essere realizzato, ad esempio, mediante priority queuing associato ad un rate limit sulla classe. Il valore raccomandato del DSCP per l EF è pari al valore binario '101110' (corrispondente ad un valore decimale di 46). Assured Forwarding (AF) PHB 3. L AF definisce un metodo per fornire diverse garanzie d inoltro. L AFxy PHB definisce quattro classi AFx: AF1, AF2, AF3, e AF4. Ad ogni classe è assegnata una certa quantità di buffer e una percentuale dell ampiezza di banda dell interfaccia, dipendente dalla banda contrattualizzata (SLA). All interno di ogni classe AFx è possibile specificare 3 valori di precedenza nell operazione di scarto dei pacchetti. Se si verifica una congestione in un router appartenente al dominio DS, ed i pacchetti di una specifica classe AFx (per esempio AF1) necessitano di essere scartati, i pacchetti in AFxy saranno scartati in modo che P(AFx1) P(AFx2) P(AFx3), dove P(AFxy) è la probabilità che i pacchetti della classe AFxy siano scartati. L indice "y" in AFxy indica la precedenza di scarto (drop precedence) all interno di una classe AFx. Per esempio, i pacchetti in AF13 verranno scartati prima dei pacchetti in AF12, che a loro volta vengono scartati prima dei pacchetti in AF11. Questo concetto di precedenza nello scarto è utile, per esempio, per penalizzare i flussi che eccedono un ampiezza di banda assegnata a priori. Di seguito è riportata la tabella che definisce le 4 classi di servizio, ciascuna dei quali possiede tre livelli di drop (per un totale di 12 diversi valori del Code Point): Drop Precedence Class1 Class2 Class3 Class4 Low drop precedence (AF11) (AF21) (AF31) (AF41) Medium drop precedence High drop precedence (AF12) (AF13) (AF22) (AF23) (AF32) (AF33) (AF42) (AF43) Specificato nell RFC Specificato nell RFC2597. Si noti che le variabili xy di AFxy, definiscono rispettivamente le classi e sottoclassi del servizio Assured Forwarding (AF). 12(88) 24/02/2005

13 L amministratore di rete può utilizzare i valori di DSCP raccomandati dall IETF per la discriminazione dei traffici in transito sulla rete oppure sceglierne di propri. Il modello DiffServ si compone di tre funzioni principali: Classifier. Il classifier seleziona i pacchetti dello stream in ingresso sulla base del contenuto di una porzione dell header del pacchetto IP. Esistono due tipi di classifier: il BA (Behaviour Aggregate), basato solo sul valore del DSCP, e l MF (Multi-Field) classifier basato sui valori di una combinazione di più campi dell header come ad esempio: Source Address, Destination Address, Protocol ID, Source Port, Destination Port ed è inoltre in grado di utilizzare altre informazioni quali l interfaccia d ingresso. Traffic conditioner. È la parte centrale dell architettura DiffServ, il cui obiettivo è l applicazione di azioni prefissate sui pacchetti preventivamente classificati. Vengono definiti dei traffic profile che specificano le proprietà temporali di un flusso. Il traffic profile fornisce le regole per determinare se un particolare pacchetto IP è in-profile o out-profile. Un traffic conditioner può essere costituito da uno più di questi elementi: Meter: misura il traffico dei pacchetti selezionati dal classifier confrontandoli con il traffic profile e suddividendoli in in-profile e out-profile Marker: riscrive il DSCP dei pacchetti impostando valori prestabiliti per i pacchetti in-profile e per i pacchetti out-profile. I valori dei pacchetti fuori profilo generalmente differiscono da quelli in-profile. Shaper: si occupa dei pacchetti out-profile scegliendo di ritardarne la trasmissione per farli rientrare in-profile. Dropper/Policer: effettua il policing dei flussi e, in caso di congestione, si occupa di scartare i pacchetti fuori profilo. Traffic conditioner Meter Classifier Marker Shaper/ Dropper Figura 5: diagramma a blocchi del modello DiffServ Il modello DiffServ introduce inoltre il concetto di DS domain. Un DS domain è un insieme di router che operano con comportamenti PHB congruenti ed è solitamente gestito da una sola autorità amministrativa, responsabile di erogare sui router delle specifiche di gestione del traffico congruenti. 13(88) 24/02/2005

14 DS ingress boundary router DS interior router DS interior router DS interior router DS egress boundary router DS DOMAIN Figura 6: PHB su tutti i router del DS domain Un DS domain è costituito da DS boundary router e da DS interior router. I DS boundary router sono quelli all edge del DS domain. Un DS boundary router agisce sui flussi entranti ed uscenti dal DS domain. Quando il DS boundary router agisce sui flussi entranti è responsabile della loro classificazione e marking oltre che del controllo della banda ammessa; sui flussi uscenti può essere opzionalmente effettuato un controllo della banda ammessa. Un DS interior router seleziona una specifica modalità di trattamento del pacchetto (in termini di accodamento e scheduling) sulla base di uno specifico valore del DSCP. L obiettivo del servizio di rete Premium IP è formare una confederazione di DS domain con un comune comportamento PHB. 3 SERVIZIO PREMIUM IP Il servizio Premium IP (PIP) ha origine nel progetto europeo SEQUIN e si propone come obiettivo la definizione e realizzazione di un servizio di trasporto end-to-end del traffico con QoS attraverso i domini delle reti nazionali della ricerca europea. Il servizio è stato concepito in modo che ciascuna rete nazionale della ricerca (NREN) ne mantenga un controllo indipendente al proprio interno. Il lavoro è stato successivamente rielaborato ed esteso nella Service Activity 3 di GEANT2 (GN2-SA3). La disponibilità del servizio Premium IP è limitata al mondo accademico e della ricerca italiano ed europeo (la rete GARR e tutte le NREN ad essa interconnesse dalla rete Europea della ricerca GEANT). Lo scopo del servizio Premium IP è quello di realizzare il trasporto bidirezionale del traffico privilegiato tra due end-point con prestazioni confrontabili a quelle di un Circuito Diretto Numerico (CDN): una connessione Premium IP realizza quindi una virtual leased line tra due end-point della rete. Un flusso Premium IP è caratterizzato dalle seguenti caratteristiche: prefisso IP di sorgente noto; 14(88) 24/02/2005

15 prefisso IP di destinazione noto; DSCP uguale a 46 4 ; traffico con perdita di pacchetti nulla all interno della banda contrattualizzata anche in condizioni di saturazione della rete; IPDV (IP packet Delay Variation o jitter) minimo, il più possibile vicino al valore ottenibile in assenza di flussi concorrenti; è soggetto alle medesime politiche di instradamento di tutto il resto del traffico. Si noti che di per sé l architettura DiffServ non offre meccanismi per garantire parametri di QoS ai flussi di traffico in rete. Nel Premium IP, questo è realizzato facendo in modo che tutto il traffico PIP instradato in rete possa essere servito con specifici parametri di QoS, anche in presenza di eventuali reinstrdamenti dei flussi di traffico a causa di guasti. In altre parole, il volume del traffico PIP su qualsiasi link della rete risulta, anche nel caso peggiore, trasportabile con i parametri di qualità attesi. Premium IP è un servizio end-to-end realizzato mediante i meccanismi di CoS (Class Of Service) e si basa sull architettura DiffServ. I router della rete sui quali è presente il servizio Premium IP costituiscono un Premium IP domain 5. Questi router possono appartenere anche a domini amministrativi diversi (ad esempio, altre NREN). Il dominio Premium IP non è tuttavia limitato alla rete GARR, ma si estende sulla rete GEANT grazie ad una interoperabilità del servizio di tipo federativo. L utilizzo del medesimo PHB in ciascuna delle reti nazionali della ricerca rende possibile la cooperazione inter-dominio. NREN3 NREN4 GEANT NREN1 NREN5 NREN2 Dominio Premium IP dominio amministrativo Estensione federativa interdominio del servizio Premium IP Figura 7: estensione federativa interdominio del servizio Premium IP sulle reti della ricerca europee Uno dei requisiti che caratterizzano il servizio Premium IP è la quantità di banda end-to-end ammessa, al superamento della quale i router della rete effettueranno il drop dei pacchetti eccedenti il valore massimo di throughput ammesso. A differenza di quanto avviene per il traffico best effort, lo scarto dei pacchetti IP Premium eccedenti il valore di banda contrattualizzato avverrà anche in assenza di congestione dei link attraversati. 4 Il valore del DSCP 46 del traffico Premium si intende in numerazione decimale, ovvero (46) 10 =(2E) 16 5 Analogamente al DS domain, l insieme di router su cui è presente un servizio Premium IP aventi la stessa politica di trattamento del traffico costituiscono un Premium IP domain. 15(88) 24/02/2005

16 Il PIP utilizza il trattamento Expedited Forwarding (EF) PHB. A tutt oggi, il servizio PIP è definito ed in produzione per il protocollo IPv4, ed è estendibile senza variazioni anche al protocollo IPv6. È estremamente importante sottolineare come i meccanismi di CoS intervengano SOLAMENTE IN CASO DI SATURAZIONE DEL LINK. Per spiegare questo tipo di comportamento, ci serviremo di un esempio. Si prenda in considerazione un autostrada composta da 3 corsie di marcia normale e di una corsia di emergenza (considerabile anche come una corsia per traffico a più alta priorità). In condizioni di traffico normale, due veicoli che procedano uno sulle corsie di marcia normale ed uno sulla corsia di emergenza per compiere un identico tragitto impiegheranno lo stesso tempo. In caso di traffico congestionato, il veicolo abilitato a transitare sulla corsia di emergenza riuscirà a coprire il tragitto in un tempo sicuramente inferiore, paragonabile a quello ottenibile in assenza di traffico. Differentemente, il veicolo in transito sulle normali corsie di marcia sperimenterà un marcato innalzamento dei propri tempi di percorrenza. È quasi superfluo notare come, in assenza di traffico congestionato, transitare sulla corsia di emergenza non apporti beneficio alcuno. 3.1 EROGAZIONE DEL SERVIZIO PREMIUM IP INTRADOMAIN Nell erogazione di Premium IP all interno della comunità GARR si individuano diversi domini amministrativi di competenza: dominio della rete GARR e domini degli utilizzatori. Estensione intradominio del servizio Premium IP Dominio Utilizzatore 1 Dominio Utilizzatore 2 DOMINIO rete GARR Figura 8: presenza di più domini nell erogazione del servizio Premium IP È importante notare che la natura end-to-end del servizio ne comporta la configurazione anche sugli apparati di rete dell utilizzatore. In conformità con il modello DiffServ, l erogazione del servizio Premium IP sulla rete prevede l impostazione di una serie di meccanismi necessari al trattamento del traffico: Classification e Policing: I flussi di traffico vengono classificati e ne viene controllata la conformità rispetto al valore contrattuale. Scheduling: In condizioni di saturazione, lo scheduling garantisce l inoltro prioritario del traffico Premium rispetto al best effort. 16(88) 24/02/2005

17 Rewrite: La rewrite impone al valore 0 il DSCP per il traffico best effort ed impone al valore 46 il DSCP per il traffico Premium. Estensione intradominio del servizio Premium IP QoS Host Premium SCHEDULING REWRITE CLASSIFICATION POLICING SCHEDULING REWRITE CLASSIFICATION POLICING SCHEDULING REWRITE QoS Host Best Effort Host Best Effort Dominio Utilizzatore 1 DOMINIO rete GARR Host Premium Dominio Utilizzatore 2 CLASSIFICATION POLICING Figura 9: impostazione delle operazioni di classificatione/policing/scheduling nel dominio GARR I componenti software principali disponibili nel JUNOS per l utilizzo della Class of Service (CoS) sono rappresentati schematicamente nella figura che segue: flussi entranti flusso 1. flusso N Interfaccia d ingresso Componenti base della CoS Componenti JUNOS Componenti JUNOS disponibili in INGRESS disponibili in EGRESS Classifier BA MF POL POL Sch R Interfaccia d uscita flussi uscenti flusso 1 flusso N Legenda Internal forwarding Non utilizzato in Premium IP BA MF Beaviour POL Policer Aggregate MultiField Sch Scheduler R Rewrite Figura 10: componenti CoS nel JUNOS utilizzate per l erogazione del servizio di Premium IP Per l elaborazione del traffico è possibile utilizzare/abilitare selettivamente solo una parte dei componenti del CoS. Ad esempio, il servizio Premium IP non utilizza il componente Policer che agisce dopo l internal forwarding. 17(88) 24/02/2005

18 Esistono due componenti software della CoS che agiscono sui pacchetti in ingress sulle interfacce del router: il Behavior Aggregate (BA) e il Multi Field (MF). Qualora queste componenti vengano utilizzate congiuntamente, la sequenza con cui vengono prese in esame è: BA e MF. Se entrambe presenti l MF sovrascrive le impostazioni del BA. Il servizio Premium IP individua complessivamente tre tipologie di traffico in transito nella rete: Traffico IP Premium. È il traffico con DSCP pari al valore decimale 46. Traffico di Network Control. È il traffico di segnalazione dei protocolli di routing (OSPF, BGP, multicast, ecc.) che ha DSCP pari ai valore decimali 48 e 56. Traffico Best Effort. È il traffico con valori di DSCP diversi da 46, 48 e 56. Per gestire queste tre tipologie di traffico sono necessarie sulle interfacce d uscita tre code hardware complessive. Tutti i router Juniper hanno per default quattro code hardware 6 anche se nel caso del servizio Premium IP ne vengono adoperate solo tre. I flussi di traffico in ingresso vengono riconosciuti dal classifier ed inseriti all interno di differenti code hardware. In un router appartenente al dominio Premium IP si individuano due tipi diversi di interfacce: interfaccia di accesso al dominio Premium IP interfaccia di backbone del dominio Premium IP Il traffico in transito attraverso queste due tipologie di interfacce è trattato in modo differente. In Figura 11 vengono mostrate le componenti della CoS utilizzate per la realizzazione del servizio Premium IP, sia per le interfacce di accesso che per le interfacce di backbone. Interfaccia d ACCESSO flussi entranti flusso 1. flusso N MF Componenti base della CoS POL Sch Interfaccia di uscita (accesso o backbone) R flussi uscenti flusso 1 flusso N flussi entranti flusso 1. flusso N Componenti JUNOS disponibili in INGRESS Internal forwarding Componenti JUNOS disponibili in EGRESS BA POL Sch R flussi uscenti flusso 1 flusso N Interfaccia di BACKBONE Legenda BA MF Beaviour Aggregate MultiField POL Sch Policer Scheduler Interfaccia di uscita (accesso o backbone) R Rewrite Figura 11: componenti sw del JUNOS necessarie all erogazione del Premium IP 6 Su alcuni modelli di router Juniper è possibile all occorrenza abilitare il funzionamento di otto code hardware. 18(88) 24/02/2005

19 3.1.1 CoS sulle interfacce di accesso al dominio PIP I traffici in ingress sulle interfacce di accesso sono considerati come untrusted e richiedono pertanto per la loro classificazione l utilizzo del Multi Field (MF), in grado di discriminare il traffico sulla base dei valori dei campi IP sorgente, IP Destinazione, DSCP. In presenza di saturazione del link di accesso, per evitare che il traffico best effort subisca effetti di starving, la quantità massima di traffico Premium IP contrattualizzabile lungo un path fisico tra due sedi è uguale al 10% del throughput massimo del link a più bassa velocità. La quantità di traffico Premium in ingress è determinata dal policer applicato all interfaccia d ingresso. PIP2 R Sch Scheduler PIP1 sui flussi in egress dalle interfacce d accesso Incoming flow Flusso Premium Link backbone R Sch MF POL MF BE2 BE1 Link backbone MF MF interfacce d accesso Legenda MF MultiField POL Policer Flusso Premium R Rewrite Sch Scheduler Figura 12: ingress/egress sulle interfacce di accesso In base ad un proprio algoritmo e tenendo conto sia della priorità di scheduling, che della quantità di banda associate a ciascuna coda lo scheduler decide l ordine di trasmissione dei pacchetti sull interfaccia di uscita. In condizioni di saturazione, i pacchetti inseriti all interno delle due code Premium IP e Network Control (priorità di scheduling high) saranno trasmessi prima di quelli contenuti nella coda besteffort (priorità di scheduling low). L algoritmo con cui lo scheduler estrae i pacchetti dalle code hardware è denominato Modified Deficit Round Robin (MDRR- descritto in dettaglio nell appendice di questo documento). 19(88) 24/02/2005

20 Flussi in ingress Interfaccia d accesso Priority scheduling: low Transmission scheduling: 75%BW Interfaccia di backbone Flow 1 (DSCP=48 o DSCP=56) queue 0: Flow 2 (DSCP=46) (flusso non premium) Flow 3 (DSCP=21) Flow 4 (DSCP 0) Flow 5 (DSCP 63) Flow 6 (DSCP 0) (flusso premium) MF POL Priority scheduling: high Transmission scheduling: 20%BW queue 1: queue 3: Priority scheduling: high Transmission scheduling: 5%BW Sch MDRR Figura 13: classificazione e scheduling nel dominio Premium IP-traffico in ingress nelle interfacce di accesso Lo scheduler applicato all interfaccia di accesso si diversifica dallo scheduler dell interfaccia di backbone esclusivamente per il valore delle percentuali assegnate al transmission scheduling. Flussi in ingress Interfaccia di backbone Priority scheduling: low Transmission scheduling: 85%BW Interfaccia di accesso Flow 1 (DSCP=48 o DSCP=56) queue 0: Flow 2 (DSCP=0) (flusso non premium) Flow 3 (DSCP=0) Flow 4 (DSCP 0) Flow 5 (DSCP 0) Flow 6 (DSCP 46) (flusso premium) BA POL Priority scheduling: high Transmission scheduling: 10%BW queue 1: queue 3: Priority scheduling: high Transmission scheduling: 5%BW Sch MDRR Figura 14: classificazione e scheduling nel dominio Premium IP-traffico in egress dalle interfacce di accesso Il trasmission scheduling è il valore percentuale di banda riservata per ciascuna cosa in condizioni di saturazione. Per le interfacce di accesso il transmission scheduling (Transmission SCHED ) è impostato con le seguenti percentuali: Coda per traffico Premium IP: Transmission SCHED =max (10% BW InterfacciaUscita ) Code per traffico di Network Control: Transmission SCHED = (5% BW InterfacciaUscita ) Coda per traffico di Best Effort: Transmission SCHED = 100% BW [ Transmission ( IPPr emium) Transmission ( IPNetwkControl)] Interfacci auscita SCHED + SCHED È opportuno notare che, in assenza di congestione dell interfaccia di uscita, le code per il traffico best effort e per il network control possono arrivare ad occupare il 100% della banda disponibile. Al contrario, la coda per il traffico Premium IP può arrivare ad occupare al massimo il 10% della banda disponibile anche in assenza di congestione. 20(88) 24/02/2005

21 L operazione di rewrite viene effettuata per garantire un trattamento del traffico congruente su tutto il dominuo amministrativo mediante un marking dei pacchetti in transito sui router di accesso. Le operazioni di rewrite effettuate sono le seguenti: Traffico Best Effort. Il traffico proveniente dalla coda Best Effort viene riscritto al valore di DSCP uguale al valore decimale 0. In questo modo il traffico non conforme (ovvero con DSCP 0) generato da utenti non trusted, inserito quindi in coda 0, viene inoltrato in rete con DSCP= 0. Traffico Premium. Il traffico proveniente dalla coda Premium viene riscritto al valore di DSCP uguale al valore decimale 46. In questo modo, il traffico non conforme (ovvero con DSCP 46) generato da utenti trusted, inserito quindi in coda 1, viene inoltrato con DSCP = 46. Traffico di network Control. Il traffico di network control (ad esempio generato dai OSPF, BGP e multicast) può essere marcato con valori di DSCP pari a 48 e 56 e necessita di una trattazione specifica. Per ottenere una trasparenza del DSCP di network control, viene sfruttato un parametro interno del JUNOS denominato Packet Loss Priority (PLP). Si tratta di un attributo che viene associato ai pacchetti entranti nelle interfacce del router. Generalmente il PLP viene utilizzato insieme con i drop-profile del RED. Nel caso del Servizio Premium IP, il PLP viene utilizzato nel seguente modo: Se il pacchetto entrante nell interfaccia è marcato con valore di DSCP=48 gli viene attribuito un PLP=0; Se il pacchetto entrante nell interfaccia è marcato con valore di DSCP=56 gli viene attribuito PLP=1. La Figura 15 mostra come il valore del PLP attribuito ai pacchetti inserti nella coda di network control venga utilizzato per effettuare una rewrite condizionale sul traffico uscente dalle interfacce del router. Inspection DSCP DSCP=48? Set PLP=low Queue Network Control Sch PLP=low? SI REWRITE DSCP= 48 Output interface DSCP=56? Set PLP=high NO PLP=high REWRITE DSCP= 56 R2 BGP Output interface R1 Figura 15: rewrite condizionale per il traffico di network control 21(88) 24/02/2005

22 3.1.2 CoS sulle interfacce di backbone del dominio PIP Le interfacce di backbone possono essere trattate in modo diverso dalle interfacce di accesso. In assenza di errate configurazioni, sui flussi entranti sulle interfacce di backbone, non è in linea di principio necessario applicare alcun policer per limitare il traffico Premium IP in quanto la sua presenza sul link di backbone non eccederà mai il limite massimo. Nonostante ciò, è utile impostare un policer in grado di stabilire una quantità di banda massima ammessa, proteggendo in questo modo il traffico best effort da errate configurazioni. Il policer sul traffico entrante nelle interfacce di backbone svolge quindi un ruolo di safe guard. La percentuale massima di traffico Premium IP ammessa su un link di backbone è impostata al 20% della banda disponibile; se in linea di principio un valore del 10% è da considerarsi come sufficiente, potrebbero verificarsi aumenti del traffico Premium dovuti a down di link di backbone che portano ad un naturale innalzamento sul link attivo del traffico Premium. Il 20% sembra quindi un valore di soglia massimo ragionevole, in grado di garantire il corretto funzionamento del traffico Premium anche in presenza di eventuali rerouting dei traffici. 4 DETTAGLI DI CONFIGURAZIONE DEL SERVIZIO PREMIUM IP Di seguito vengono descritte in dettaglio le configurazioni JUNOS necessarie alla realizzazione del servizio Premium IP. Vengono descritte prima le configurazioni delle interfacce di accesso del dominio Premium IP e poi quelle delle interfacce di backbone. 4.1 INTERFACCE DI ACCESSO AL DOMINIO PIP Il traffico entrante nelle interfacce di accesso va controllato in modo da garantire che solamente le sorgenti PIP autorizzate possano utilizzare la coda ad alta priorità Traffico di ingress nelle interfacce di accesso Nella Figura 16 sono riportati i componenti del JUNOS utilizzati per trattare il traffico entrante nelle interfacce d accesso. realizzato mediante firewall filter Internal forwarding Multifield Policer Classifier Figura 16: componenti del JUNOS utilizzati per l ingress traffic sulle interfacce d accesso In ingress nelle interfacce d accesso viene applicato: un MF, che dopo aver verificato l IP della sorgente e della destinazione, imposta la forwarding-class e il Packet Loss Priority (PLP) del pacchetto IP; 22(88) 24/02/2005

23 un Policer che regola la quantità di traffico entrante nell interfaccia. È possibile distinguere due differenti casi: traffico di ingress nelle interfacce di accesso attraverso le quali sono raggiungibili sorgenti Premium; traffico di ingress nelle interfacce di accesso attraverso le quali non sono raggiungibili sorgenti Premium Traffico di ingress nelle interfacce di accesso connesse a sorgenti Premium Il comportamento del policer può essere descritto sotto forma di pseudo-codice 7 : Policer policer per Expedite-Forwarding if [(Used_Bandwidth > 12% Total_If_Bandwidth) && (Burst_Size > 150K)] then{ discard; policer per Network-Control if [(Used_Bandwith > 5% Total_If_Bandwith) && (Burst_Size > 150K)] then{ discard; dove Used_Bandwidth: è la quantità di traffico ad un certo istante di tempo; Total_If_Bandwidth: è il throughput nominale dell interfaccia di accesso; Burst_Size: è il valore massimo di picco espresso in byte; Osservazioni sul policer applicato sul traffico entrante nelle interfacce di accesso: Il policer per Expedite-Forwarding garantisce che il traffico massimo generato da una sorgente premium non superi il 12% 8 della velocità dell interfaccia di accesso. Il policer per il traffico di Network Control garantisce che il traffico massimo generato da una sorgente premium non superi il 5% della velocità dell interfaccia di accesso. Non viene definito nessun policer per il traffico best-effort. Per razionalizzare l impatto sulle configurazioni da erogare in rete è utile suddividere l impostazione dell MF in due macro-blocchi, da aggiungere ad un eventuale filtro preesistente. 7 Nello pseudo codice vengono utilizzati i seguenti operatori logici:!= diverso == uguale or logico && and logico 8 Il valore del 12% utilizzato nel presente documento presuppone un valore contrattualizzato del traffico PIP pari al 10% della velocità nominale dell interfaccia di accesso. In generale la quantità di traffico IP Premium contrattualizzabile con l utenza risulta compresa tra [0%, 10%] della velocità nominale dell interfaccia di accesso. 23(88) 24/02/2005

24 L MF risulta così strutturato: realizzato mediante firewall filter Multifield Classifier Policer PIP_<NOME_ENTE> COMMON <NOME_ENTE>_IN firewall filter dove: Figura 17: macroblocchi del filtro in ingresso PIP_<NOME_ENTE> = filtro utilizzato per individuare la coppia (IP Source, IP Dest) del traffico PIP; COMMON = filtro utilizzato per discriminare tutto il traffico differente da quello PIP; <NOME_ENTE>_IN= eventuale filtro preesistente per controllare il traffico diretto verso particolari host/porte. Il filtro <NOME_ENTE>_IN dovrà contenere il seguente comando JUNOS: term default { then accept; Nei casi in cui non esista alcun filtro preesistente, è possibile utilizzare il filtro DEFAULT_ACCEPT, contenente solamente l istruzione pocanzi elencata. Il funzionamento del firewall filter può essere espresso sotto forma di pseudo-codice: Firewall filter PIP_<NOME_ENTE> if [(IP_Source ingress traffic == IP_Premium_Source) && (IP_Destination ingress traffic == IP_Premium_Destination)] then { applica il policer per Expedite-Forwarding; inserisci il traffico nella Premium-queue; accept; Firewall filter COMMON if [(DSCP ingress traffic ) == 48] then { applica il policer per Network-Control; inserisci il traffico nella Network-Control-queue; 24(88) 24/02/2005

25 imposta PLP= low; next; if [(DSCP ingress traffic ) == 56] then { applica il policer per Network-Control; inserisci il traffico nella Network-Control-queue; imposta PLP= high; next; if [(DSCP ingress traffic )!= 48 && (DSCP ingress traffic )!= 56 ] then { imposta PLP =low; inserisci il traffico nella Best-Effort-queue; accept; exit; Firewall filter <NOME_ENTE>_IN { custom-filter-statements default then { accept; exit; default then { accept; exit; Firewall filter DEFAULT_ACCEPT i pacchetti IP provenienti da una sorgente non Premium vengono inseriti nella coda best effort e gli viene attribuito un PLP=low. Nella configurazione non viene impiegato nessun tipo di drop profile; il PLP 9 viene utilizzato esclusivamente dalla rewrite-rule per i pacchetti in egress. A causa della presenza di istruzioni next term all interno del filtro denominato come COMMON, in uno dei filtri applicati di seguito, deve essere OBBLIGATORIAMENTE presente un term di default contenente l istruzione accept ; il JUNOS non permette la creazione di un filtro che non presenti almeno un term contenente una action (accept/reject/discard). Il funzionamento del firewall filter può essere anche espresso in forma tabulare: ingress flow DSCP value Forwarding-class PLP PIP qualsiasi ef low (default) (trusted IP Source & & IP Destination) 9 vedi appendice A. 25(88) 24/02/2005