Network Working Group D

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Le protocole point à point (PPP) [RFC1661] fournit une méthode standard pour transporter des datagrammes multi protocoles sur des liaisons point à point. PPP définit aussi un protocole extensible de contrôle de liaison.

Le présent document définit une méthode pour négocier la compression de données sur des liaisons PPP.

Table des Matières

1. Introduction 1

2. Protocole de contrôle de compression (CCP) 1

2.1 Envoi de datagrammes compressés 2

3. Paquets supplémentaires 2

3.1 Demande de rétablissement et accusé de réception de rétablissement 3

4. Options de configuration CCP 4

4.1 OUI de compression propriétaire 4

4.2 Autres types de compression 5

Références 6

Remerciements 6

Adresse de l’auteur 6

Afin d’établir des communications sur une liaison PPP, chaque extrémité de la liaison doit d’abord envoyer des paquets de protocole de contrôle de liaison (LCP, Link Control Protocol) pour configurer et essayer la liaison de données durant la phase d’établissement de la liaison. Après l’établissement de la liaison, des facilités facultatives peuvent être négociées en tant que de besoin.

Une de ces facilités est la compression des données. Des méthodes de compression très diverses peuvent être négociées, bien que normalement une seule méthode soit utilisée dans chaque direction de la liaison.

Un algorithme de compression différent peut être négocié dans chaque direction, pour des considérations de vitesse, de coût, de mémoire ou autres, ou bien une seule direction peut être compressée.

Le protocole de contrôle de compression (CCP, Compression Control Protocol) est chargé de configurer, activer, et désactiver les algorithmes de compression des données sur les deux extrémités de la liaison point à point. Il est aussi utilisé pour signaler de façon fiable une défaillance du mécanisme de compression/décompression.

CCP utilise le même mécanisme d’échange de paquets que le protocole de contrôle de liaison (LCP, Link Control Protocol). Les paquets CCP ne peuvent pas être échangés jusqu’à ce que PPP ait atteint la phase de couche réseau du protocole. Les paquets CCP reçus avant que cette phase soit atteinte devraient être éliminés en silence.

Le protocole de contrôle de compression est exactement le même que le protocole de contrôle de liaison [RFC1661] avec les exceptions suivantes :

Modifications de trame : le paquet peut utiliser toute modification au format de trame de base qui a été négociée durant la phase d’établissement de liaison.

Champ Protocole de couche Liaison de données : exactement un paquet CCP est encapsulé dans la champ Informations PPP, où le champ Protocole PPP indique le type hexadécimal 80FD (protocole de contrôle de compression). Lorsque la compression de données de liaison individuelle est utilisée dans une connexion à liaisons multiples sur une seule destination, le champ Protocole PPP indique le type hexadécimal 80FB (protocole de contrôle de compression de liaison individuelle).

Champ Code : en plus des codes 1 à 7 (Demande de configuration, Accusé de réception de configuration, Non accusé de réception de configuration, Rejet de configuration, Demande de terminaison, Accusé de réception de terminaison et Rejet de code) deux codes supplémentaires, 14 et 15 (Demande de rétablissement et Accusé de réception de rétablissement) sont définis pour le présent protocole. Les autres codes devraient être traités comme non reconnus et devraient résulter en un rejet de code.

Fin de temporisation : les paquets CCP ne peuvent pas être échangés jusqu’à ce que PPP ait atteint la phase Protocole de couche réseau. Une mise en œuvre devrait être prête à attendre que l’authentification et la détermination de la qualité de la liaison soient terminées avant de mettre fin à l’attente d’un accusé de réception de configuration ou autre réponse. Il est suggéré qu’une mise en œuvre n’abandonne qu’après une intervention de l’usager ou une temporisation configurable.

Types d’option de configuration : CCP a un ensemble distinct d’options de configuration.

Avant qu’un paquet compressé puisse être communiqué, PPP doit atteindre la phase de protocole de couche réseau, et le protocole de contrôle de compression doit atteindre l’état Ouvert.

Un ou plusieurs paquets compressés sont encapsulés dans le champ Informations PPP, où le champ Protocole PPP indique le type hexadécimal 00FD (Datagramme compressé). Chacun des algorithmes de compression peut utiliser un mécanisme différent pour indiquer l’inclusion de plus d’un paquet non compressé dans une seule trame de couche de liaison des données.

Lorsque on utilise plusieurs liaisons PPP pour une seule destination, il y a deux méthodes d’emploi de la compression de données. La première méthode est de compresser les données avant de les envoyer à travers les diverses liaisons. La seconde est de traiter chaque liaison comme une connexion distincte, qui peut avoir la compression activée ou non. Dans le second cas, le champ Protocole PPP DOIT être du type hexadécimal 00FB (datagramme compressé de liaison individuelle).

Seulement un algorithme principal dans chaque direction est utilisé à la fois, et il est négocié avant d’envoyer la première trame compressée. Le champ Protocole PPP du datagramme compressé indique que la trame est compressée, mais pas l’algorithme avec lequel elle a été compressée.

La longueur maximum d’un paquet compressé transmis sur une liaison PPP est la même que la longueur maximum du champ Information d’un paquet encapsulé dans PPP. Les plus grands datagrammes (résultant probablement de ce que dans certains cas l’algorithme de compression a augmenté la taille du message) peuvent être envoyés non compressés, en utilisant sa forme standard, ou peuvent être envoyés en plusieurs datagrammes, si l’algorithme de compression l’accepte.

Chacun des algorithmes de compression doit fournir un moyen de déterminer si il passe fiablement les données, ou il doit exiger l’utilisation d’un transport fiable tel que LAPB [RFC1663]. Les fabricants sont vivement encouragés à employer une méthode de validation des données compressées, ou de reconnaissance des paires désynchronisées de compresseur/ décompresseur.

Le format de paquet et les facilités de base sont déjà définies pour LCP dans la [RFC1661].

Les mises à jour des valeurs de code CCP sont spécifiées dans la plus récente version de la RFC "numéros alloués" [RFC1700]. La présente spécification concerne les valeurs suivantes :

CCP comporte les codes Demande de rétablissement et Accusé de réception de rétablissement afin de fournir un mécanisme pour indiquer un échec de décompression dans une direction d’une liaison compressée sans affecter le trafic dans l’autre direction. Un échec de décompression peut être déterminé en passant périodiquement une valeur de hachage, effectuant une vérification de CRC sur les données décompressées, ou un autre mécanisme. Il est fortement suggéré qu’un mécanisme soit disponible dans tout algorithme de compression pour valider les données décompressées avant de passer les données au reste du système.

Une mise en œuvre CCP qui souhaite indiquer un échec de décompression DEVRAIT transmettre un paquet CCP avec le champ Code réglé à 14 (Demande de rétablissement) et le champ Données rempli par des données de son choix. Une fois que la demande de rétablissement a été envoyée, tout paquet compressé reçu sera éliminé, et une autre demande de rétablissement sera envoyée avec le même identifiant, jusqu’à ce qu’un accusé de réception de rétablissement valide soit reçu.

À réception d’une demande de rétablissement, le compresseur émetteur est rétabli à son état initial. Cela peut inclure d’éliminer un dictionnaire, de rétablir des codes de hachage, ou d’autres mécanismes. Un paquet CCP DOIT être transmis avec le champ Code réglé à 15 (Accusé de réception de rétablissement) le champ Identifiant copié du paquet Demande de rétablissement, et le champ Données rempli avec les données désirées.

À réception d’un accusé de réception de rétablissement, le décompresseur receveur est remis à son état initial. Cela peut inclure de supprimer un dictionnaire, de rétablir des codes de hachage, ou d’autres mécanismes. Comme il peut y avoir plusieurs accusés de réception de rétablissement en cours, le décompresseur DOIT être rétabli pour chaque accusé de réception de rétablissement qui correspond à l’identifiant actuellement attendu.

Un résumé des formats de paquet Demande de rétablissement et Accusé de réception de rétablissement est présenté ci-dessous. Les champs sont transmis de gauche à droite.

À l’émission, le champ Identifiant DOIT être changé chaque fois que le contenu du champ Données change, et chaque fois qu’une réponse valide a été reçue pour une demande précédente. Pour les retransmissions, l’identifiant PEUT rester inchangé.

À réception, le champ Identifiant de la demande de rétablissement est copié dans le champ Identifiant du paquet Accusé de réception de rétablissement.

Le champ Données est de zéro, un ou plusieurs octets et contient des données non interprétées à utiliser par l’envoyeur. Les données peuvent consister en toute valeur binaire et peuvent être de toute longueur de zéro à la MRU établie par l’homologue moins quatre.

Les options de configuration CCP permettent la négociation d’algorithmes de compression et de leurs paramètres. CCP utilise le même format d’option de configuration que celui défini pour LCP [RFC1661], avec un ensemble d’options distinct.

Dans ce protocole, les options de configuration indiquent les algorithmes que le receveur accepte ou est capable d’utiliser pour décompresser les données envoyées par l’émetteur. Il en résulte qu’on s’attend à ce que les systèmes offrent d’accepter plusieurs algorithmes, et en négocient un seul qui sera utilisé.

Il y a une possibilité qu’on ne soit pas capable de se mettre d’accord sur un algorithme de compression . Dans ce cas, aucune compression ne sera utilisée, et la liaison va continuer de fonctionner sans compression. Si la fiabilité de la liaison a été négociée séparément, elle va continuer d’être utilisée, jusqu’à ce que le LCP soit renégocié.

On s’attend à ce que de nombreux fabricants veuillent utiliser des algorithmes de compression propriétaires, et on a rendu un mécanisme disponible pour les négocier sans encombrer l’autorité d’allocation des numéros de l’Internet avec des demandes de numéros propriétaires.

On utilise les techniques de négociation d’option LCP. Si une option n’est pas reconnue, un Rejet de configuration DOIT être envoyé. Si tous les protocoles que met en œuvre l’envoyeur subissent un rejet de configuration par le receveur, aucune compression n’est alors activée dans cette direction de la liaison.

Si une option est reconnue, mais n’est pas acceptable à cause des valeurs dans la demande (ou de paramètres facultatifs qui se sont pas dans la demande) un Non accusé de réception de configuration DOIT être envoyé avec l’option modifiée de façon appropriée. Le Non accusé de réception de configuration DOIT ne contenir que les options qui seront acceptables. Une nouvelle demande de configuration DEVFRAIT être envoyée avec seulement la seule option préférée, ajustée comme spécifié dans le Non accusé de réception de configuration.

Des valeurs mises à jour du champ Type de l’option CCP sont spécifiées dans la plus récente RFC "Numéros alloués" [RFC1700]. Les valeurs actuelles sont allouées comme suit :

Les valeurs non alloués de 4 à 15 sont destinées à être allouées à d’autres algorithmes de compression en accès libre qui n’ont pas redevances de licence.

Cette option de configuration donne un moyen pour négocier l’utilisation d’un protocole de compression propriétaire.

Comme la première compression qui correspond va être utilisée, il est recommandé que tous les OUI d’options de compression connus soient transmis d’abord, avant d’utiliser les options communes.

Avant d’accepter cette option, la mise en œuvre doit vérifier que l’identifiant unique d’organisation (OUI) identifie un algorithme propriétaire que la mise en œuvre peut décompresser, et que toutes les valeurs de négociation spécifiques du fabricant sont pleinement comprises.

Un résumé du format de l’option de configuration d’OUI de compression propriétaire est présenté ci-dessous. Les champs sont transmis de gauche à droite.

Identifiant unique d’organisation IEEE du fabricant , qui sont les trois octets de poids fort d’une adresse physique Ethernet, allouée au fabricant par la norme IEEE 802. Cela identifie l’option comme étant la propriété du fabricant indiqué. Les bits dans l’octet sont en ordre canonique, et l’octet de plus fort poids est transmis en premier.

Ce champ est spécifique de chaque OUI, et indique un type de compression pour cet OUI. Ce champ n’est pas normalisé. Chaque OUI met en œuvre ses propres valeurs.

Ce champ fait zéro, un ou plusieurs octets, et contient des données supplémentaires comme déterminé par le protocole de compression du fabricant.

Ces options de configuration donnent un moyen pour négocier l’utilisation d’un algorithme de compression défini publiquement. De nombreux algorithmes de compression sont spécifiés. Aucune technique de compression particulière ne s’est imposée comme norme de l’Internet.

Ces protocoles seront rendus disponibles à toutes les parties intéressées, mais peuvent être associées à certaines restrictions liées à des brevets. Pour plus d’informations, se référer aux documents du protocole de compression qui définissent chaque type de compression.

Un résumé du format d’option de configuration du type de compression est présenté ci-dessous. Les champs sont transmis de gauche à droite.

Ce champ fait zéro, un ou plusieurs octets, et contient des données supplémentaires comme déterminé par le protocole de compression.

Groupe de travail Réseau	D. Rand, Novell
Request for Comments : 1962	juin 1996
Catégorie : En cours de normalisation	Traduction Claude Brière de L’Isle