Annexe A. Sémantique et utilisation du champ Flow Label (Appendix A. Semantics and Usage of the Flow Label Field)
Un flux (flow) est une séquence de paquets envoyés d'une source particulière à une destination particulière (unicast ou multicast) pour laquelle la source souhaite un traitement spécial par les routeurs intermédiaires. La nature de ce traitement spécial PEUT être communiquée aux routeurs par un protocole de contrôle (tel qu'un protocole de réservation de ressources) ou par des informations contenues dans les paquets du flux eux-mêmes (par exemple, dans une option saut par saut). Les détails de tels protocoles de contrôle ou options dépassent le cadre de ce document.
Il PEUT y avoir plusieurs flux actifs d'une source vers une destination, ainsi que du trafic non associé à un flux. Un flux est identifié de manière unique par la combinaison d'une adresse source et d'une étiquette de flux non nulle. Les paquets n'appartenant pas à un flux portent une étiquette de flux de zéro.
Les étiquettes de flux sont assignées aux flux par les nœuds sources. Les nouvelles étiquettes de flux DOIVENT être choisies de manière (pseudo-)aléatoire et uniforme dans la plage de 1 à FFFFF hexadécimal. L'objectif de l'attribution aléatoire est de faire en sorte que tout ensemble de bits dans le champ Flow Label soit utilisable comme clé de hachage par les routeurs pour rechercher l'état associé au flux.
Tous les paquets appartenant au même flux DOIVENT être envoyés avec la même adresse source, la même adresse destination et la même étiquette de flux. Si l'un de ces paquets contient un Hop-by-Hop Options header, ils DOIVENT tous être émis avec le même contenu de Hop-by-Hop Options header (à l'exclusion du champ Next Header du Hop-by-Hop Options header). Si l'un de ces paquets contient un Routing header, ils DOIVENT tous être émis avec le même contenu dans tous les en-têtes d'extension jusqu'au Routing header inclus (à l'exclusion du champ Next Header du Routing header). Les routeurs ou la destination PEUVENT, mais ne sont pas tenus de, vérifier que ces conditions sont satisfaites. Si une violation est détectée, elle DEVRAIT être signalée à la source via un message ICMP Parameter Problem (Code 0, pointant vers l'octet de poids fort du champ Flow Label (c'est-à-dire le décalage 1 dans le paquet IPv6)).
La durée de vie maximale de tout état de traitement de flux établi le long du chemin du flux DOIT être spécifiée dans le cadre du mécanisme d'établissement de l'état (par exemple, le protocole de réservation de ressources ou l'option saut par saut d'établissement de flux). Une source NE DOIT PAS réutiliser une étiquette de flux pour un nouveau flux dans la durée de vie maximale de tout état de traitement de flux qui aurait pu être établi pour une utilisation précédente de cette étiquette de flux.
Lorsqu'un nœud s'arrête et redémarre (par exemple, à la suite d'un « crash (plantage) »), il DOIT veiller à ne pas utiliser d'étiquettes de flux qui auraient pu être utilisées pour des flux antérieurs dont la durée de vie n'a peut-être pas encore expiré. Cela PEUT être accompli en enregistrant l'utilisation des étiquettes de flux dans un stockage stable, afin de pouvoir s'en souvenir après un plantage, ou en évitant d'utiliser toute étiquette de flux jusqu'à l'expiration de la durée de vie maximale de tout flux précédemment établi. Si la durée minimale de redémarrage du nœud est connue, cette durée PEUT être soustraite de la période d'attente nécessaire avant de commencer à allouer des étiquettes de flux.
Il n'est pas exigé que tous ou même la plupart des paquets appartiennent à des flux, c'est-à-dire portent des étiquettes de flux non nulles. Cette observation est faite ici pour rappeler aux concepteurs et implémenteurs de protocoles de ne pas faire d'hypothèses contraires. Par exemple, il serait imprudent de concevoir un routeur dont les performances ne seraient adéquates que si la plupart des paquets appartiennent à des flux, ou de concevoir un schéma de compression d'en-tête qui ne s'applique qu'aux paquets appartenant à des flux.