Mon blog

Ce RFC décrit un langage formel pour spécifier les en-têtes d'un paquet et, surtout, pour indiquer le mécanisme de compression utilisé.

Tous les réseaux ne disposent pas d'un excès de bande passante. Même aujourd'hui, les vieux modems restent en service (y compris dans un pays riche, mais étendu, comme les États-Unis) et certaines technologies récentes offrent une bande passante limitée (par exemple sur les téléphones mobiles). Il est donc utile de pouvoir comprimer les données et aussi les en-têtes des paquets émis, qui sont souvent très redondants, ouvrant ainsi de bonnes perspectives pour la compression. Le premier grand travail dans ce domaine avait été la compression des en-têtes TCP par Van Jacobson en 1990 (RFC 1144). Par la suite, plusieurs mécanismes de compression ont été inventés et le projet ROHC (Robust Header Compression) a été créé pour mettre de l'ordre dans ces mécanismes, en développant un cadre commun, spécifié dans le RFC 3095 et dans plusieurs autres (ROHC est désormais normalisé dans le RFC 5795).

Il manquait à tous ces RFC un langage formel, toutes les descriptions étant en langue naturelle. C'est désormais fait avec notre RFC et ce langage, ROHC-FN, rejoint donc ABNF (RFC 5234) et MIB (RFC 2578) comme langage formel pour aider à la normalisation. La première utilisation de ROHC-FN a été dans le RFC 5225.

On notera que ROHC-FN permet également la description formelle des en-têtes des paquets, description qui était traditionnellement faite dans les RFC par des ASCII box. Voici un en-tête (imaginaire) en ASCII box :

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   |version| type  |    flow_id    |
   +---+---+---+---+---+---+---+---+
   |  sequence_no  |   flag_bits   |
   +---+---+---+---+---+---+---+---+

et le même décrit en ROHC-FN :

     eg_header
     {
       UNCOMPRESSED {
         version_no   [ 2 ];
         type         [ 2 ];
         flow_id      [ 4 ];
         sequence_no  [ 4 ];
         flag_bits    [ 4 ];
       }

Si on intègre la compression, ce qui est le but principal de ROHC-FN, on peut avoir :

       COMPRESSED obvious {
         version_no    =:= uncompressed_value(2, 1);
         type          =:= irregular(2);
         flow_id       =:= static;
         sequence_no   =:= lsb(0, -3);
         abc_flag_bits =:= irregular(3);
         reserved_flag =:= uncompressed_value(1, 0);
       }

ce qui exprime le fait que version_no a toujours la même valeur (1), que type n'est pas comprimable, ou que sequence_no ne l'est pas dans un paquet mais qu'une compression inter-paquets est possible (le numéro de séquence s'incrémentant légèrement à chaque paquet).

Ces différentes méthodes (uncompressed_value, lsb, etc) sont décrites dans la section 4.11 de notre RFC.

On notera qu'il existe d'autres langages pour la description de structures binaires comme les en-têtes mais qu'apparemment aucun ne convenait pour l'IETF.