Appendix A. Semantics and Usage of the Flow Label Field (Semantica e uso del campo Flow Label)

Un flusso (flow) è una sequenza di pacchetti inviati da una sorgente specifica a una destinazione specifica, unicast o multicast, per la quale la sorgente desidera un trattamento speciale da parte dei router intermedi. La natura di tale trattamento speciale può essere comunicata ai router tramite un protocollo di controllo, come un protocollo di prenotazione delle risorse, oppure tramite informazioni contenute nei pacchetti del flusso stesso, ad esempio in un'opzione hop-by-hop. I dettagli di tali protocolli di controllo o opzioni sono fuori dall'ambito di questo documento.

Da una sorgente a una destinazione possono esistere più flussi attivi, oltre a traffico non associato ad alcun flusso. Un flusso è identificato in modo univoco dalla combinazione di indirizzo sorgente e flow label non nullo. I pacchetti che non appartengono a un flusso portano un flow label pari a zero.

I flow label vengono assegnati ai flussi dai nodi sorgente dei flussi. I nuovi flow label DEVONO essere scelti in modo (pseudo-)casuale e uniforme nell'intervallo da 1 a FFFFF esadecimale. Lo scopo dell'assegnazione casuale è rendere qualsiasi insieme di bit nel campo Flow Label adatto come chiave hash per i router, per cercare lo stato associato al flusso.

Tutti i pacchetti appartenenti allo stesso flusso DEVONO essere inviati con lo stesso indirizzo sorgente, lo stesso indirizzo di destinazione e lo stesso flow label. Se uno qualsiasi di questi pacchetti contiene una Hop-by-Hop Options header, tutti DEVONO essere originati con lo stesso contenuto della Hop-by-Hop Options header, escludendo il campo Next Header della Hop-by-Hop Options header. Se uno qualsiasi di questi pacchetti contiene una Routing header, tutti DEVONO essere originati con lo stesso contenuto in tutte le intestazioni di estensione fino alla Routing header inclusa, escludendo il campo Next Header nella Routing header. I router o la destinazione POSSONO, ma non sono tenuti a, verificare che queste condizioni siano soddisfatte. Se viene rilevata una violazione, essa DOVREBBE essere segnalata alla sorgente con un messaggio ICMP Parameter Problem, Code 0, che punta all'ottetto più significativo del campo Flow Label, cioè all'offset 1 nel pacchetto IPv6.

La durata massima di qualsiasi stato di elaborazione del flusso stabilito lungo il percorso del flusso DEVE essere specificata come parte della descrizione del meccanismo di stabilimento dello stato, ad esempio un protocollo di prenotazione delle risorse o un'opzione hop-by-hop di stabilimento del flusso. Una sorgente NON DEVE riutilizzare un flow label per un nuovo flusso entro la durata massima di qualsiasi stato di elaborazione del flusso che possa essere stato stabilito per un uso precedente di quel flow label.

Quando un nodo si arresta e si riavvia, ad esempio a causa di un "crash (arresto anomalo)", DEVE fare attenzione a non usare flow label che potrebbero essere stati usati per flussi precedenti la cui durata potrebbe non essere ancora scaduta. Ciò può essere ottenuto registrando l'uso dei flow label in memoria stabile, in modo che possa essere ricordato dopo un arresto anomalo, oppure evitando l'uso di qualsiasi flow label fino alla scadenza della durata massima di tutti i flussi eventualmente stabiliti in precedenza. Se è noto il tempo minimo di riavvio del nodo, tale tempo può essere sottratto dal periodo di attesa necessario prima di iniziare ad assegnare flow label.

Non è richiesto che tutti, o anche la maggior parte, dei pacchetti appartengano a flussi, cioè portino flow label non nulli. Questa osservazione è inclusa qui per ricordare ai progettisti e agli implementatori di protocolli di non fare assunzioni diverse. Per esempio, sarebbe imprudente progettare un router le cui prestazioni siano adeguate solo se la maggior parte dei pacchetti appartiene a flussi, oppure progettare uno schema di compressione delle intestazioni applicabile solo ai pacchetti appartenenti a flussi.