4. Grouping packets into packet streams (Raggruppamento dei pacchetti in flussi)
4. Grouping packets into packet streams (Raggruppamento dei pacchetti in flussi)
Questa sezione spiega come raggruppare i pacchetti in flussi di pacchetti ai fini della compressione. Per ottenere il miglior rapporto di compressione, i pacchetti dovrebbero essere raggruppati in modo che i pacchetti nello stesso flusso abbiano intestazioni simili. Se questo raggruppamento fallisce, le prestazioni della compressione delle intestazioni saranno scarse, perché l'algoritmo di compressione potrà sfruttare raramente il contesto esistente del flusso e dovrà inviare frequentemente intestazioni complete.
Il raggruppamento viene eseguito dal compressore. Il compressore può usare qualsiasi criterio che ritenga appropriato per assegnare i pacchetti ai flussi. Per determinare a quale flusso appartenga un pacchetto, il compressore può:
a) esaminare la catena di sottointestazioni comprimibili (vedere la Sezione 7),
b) esaminare il contenuto dell'intestazione del protocollo superiore che segue la catena di sottointestazioni comprimibili, ad esempio un'intestazione ICMP, un'intestazione DVMRP o un'intestazione IPX incapsulata,
c) usare informazioni ottenute da un gestore di risorse, ad esempio se il gestore di risorse richiede la compressione di uno specifico flusso e fornisce il modo di identificare i pacchetti appartenenti a quel flusso,
d) usare qualsiasi altra informazione rilevante, ad esempio se il routing oscilla e il campo Hop Limit (TTL) in un flusso varia frequentemente tra n e n+k, il compressore può scegliere di raggruppare i pacchetti in due flussi diversi.
Il compressore può anche scegliere di non raggruppare alcuni pacchetti in flussi per la compressione, lasciando che mantengano le intestazioni regolari e inoltrandoli senza modificarli.
Finché vengono seguite le regole per l'invio delle intestazioni complete nei flussi non TCP e le sottointestazioni sono compresse come specificato in questo documento, il decompressore sarà in grado di ricostruire correttamente le intestazioni compresse indipendentemente dal modo in cui i pacchetti sono raggruppati nei flussi.
4.1 Guidelines for grouping packets (Linee guida per il raggruppamento dei pacchetti)
In questa sezione forniamo linee guida opzionali su come il compressore può raggruppare i pacchetti in flussi per la compressione.
Defining fields (campi di definizione)
I campi di definizione dell'intestazione dovrebbero essere presenti e identici in tutti i pacchetti appartenenti allo stesso flusso. Questi campi sono marcati come DEF nella Sezione 7. I campi di definizione includono Flow Label, gli indirizzi sorgente e destinazione dell'intestazione IP, l'indirizzo di destinazione finale in una Routing header, il campo Next Header (per IPv6), il campo Protocol (IPv4), i numeri di porta (UDP e TCP) e lo SPI nelle intestazioni di autenticazione e cifratura.
Fragmented packets (pacchetti frammentati)
I pacchetti frammentati e non frammentati non dovrebbero mai essere raggruppati nello stesso flusso. L'intestazione di frammentazione o il campo Identification dell'intestazione IPv4 non dovrebbero essere usati per identificare un flusso di pacchetti. Se lo fossero, il primo frammento di un nuovo pacchetto causerebbe il compression slow-start.
Nessun campo dopo l'intestazione di frammentazione, o dopo l'intestazione IPv4 usata per la frammentazione, dovrebbe essere usato ai fini del raggruppamento.
Upper protocol identification (identificazione del protocollo superiore)
Il primo campo Next Header che identifica un'intestazione non descritta nella Sezione 7 dovrebbe essere usato per identificare il flusso di pacchetti; cioè, tutti i pacchetti con gli stessi campi DEF e lo stesso protocollo di livello superiore dovrebbero essere raggruppati insieme.
TTL field (Hop Limit field) (campo TTL, campo Hop Limit)
Implementazioni sofisticate possono monitorare il campo TTL (Hop Limit) e usarlo come campo DEF se cambia frequentemente. Questo può accadere in presenza di frequenti oscillazioni di routing, quando i pacchetti attraversano percorsi diversi in Internet.
Traffic Class field (IPv6), Type of Service field (IPv4) (campo Traffic Class, campo Type of Service)
Il campo Traffic Class dell'intestazione IPv6 e il Type of Service dell'intestazione IPv4 possono cambiare frequentemente tra pacchetti con gli stessi campi DEF. Implementazioni sofisticate dovrebbero tenerne conto ed essere pronte a usare questi campi come campi di definizione.
Quando i pacchetti IP vengono incapsulati in un tunnel, al punto di ingresso del tunnel vengono racchiusi in un'intestazione IP aggiuntiva e poi inviati all'endpoint del tunnel. Per raggruppare questi pacchetti in flussi, dovrebbero essere esaminate anche le intestazioni interne per determinare il flusso. In caso contrario, ogni modifica dell'intestazione del pacchetto IP interno causerebbe l'invio di un'intestazione completa. Pertanto, quando i pacchetti sono incapsulati in tunnel, oltre ai campi di identificazione dell'intestazione IP iniziale dovrebbero essere considerati anche i campi di identificazione delle sottointestazioni interne.
Le implementazioni possono usare per l'identificazione campi diversi da quelli descritti qui. Se vengono usati troppi campi per identificare i flussi, le prestazioni possono risentirne perché verranno usati più CID e, quando un nuovo flusso richiede un CID, potrebbe essere riutilizzato il CID sbagliato. Se vengono usati troppo pochi campi, le prestazioni possono risentirne perché le modifiche del contesto saranno troppo frequenti.
Sottolineiamo che queste linee guida sono ipotesi motivate. Quando IPv6 sarà ampiamente distribuito e il traffico IPv6 potrà essere analizzato, potremmo scoprire che altri algoritmi di raggruppamento funzionano meglio. Sottolineiamo inoltre che, se il raggruppamento fallisce, il risultato sarà una scarsa prestazione, non una decompressione errata. Il decompressore può svolgere il proprio compito indipendentemente da come funzioni l'algoritmo di raggruppamento.