Request for Comments : 1979 |
J. Woods, Proteon, Inc. |
Groupe de travail Réseau |
août 1996 |
Catégorie : Information |
Traduction Claude Brière de L'Isle |
Protocole PPP Deflate
Statut de ce mémoire
Le présent mémoire apporte des informations pour la communauté de l'Internet. Le présent mémoire ne spécifie aucune sorte de norme de l'Internet. La distribution du présent mémoire n'est soumise à aucune restriction.
Résumé
Le protocole point à point (PPP) [1] donne une méthode standard pour transporter des datagrammes multi protocole sur des liaisons point à point.
Le protocole de contrôle de compression PPP [2] fournit une méthode pour négocier et utiliser les protocoles de compression sur des liaisons encapsulées en PPP.
Le présent document décrit l'utilisation du protocole de compression PPP Deflate pour compresser les paquets encapsulés dans PPP.
Table des Matières
3. Format de l'option de configuration
Le format de compression 'deflate' [3], tel qu'utilisé par les compresseurs PKZIP et gzip et tel qu'il figure dans la librairie de code source librement et largement distribuée zlib[4], a les caractéristiques suivantes :
- un algorithme de codage et de compression apparemment non encombré, avec une spécification ouverte et publiquement disponible.
- un mécanisme d'échappement à faible redondance pour les données incompressibles. La spécification de PPP Deflate offre des options pour réduire encore cette redondance.
- largement utilisé depuis de nombreuses années dans les réseaux, sur les modems et autres liaisons point à point pour transférer les fichiers des ordinateurs individuels et stations de travail.
- réalise facilement une compression de 2 à 1 sur le corpus de Calgary [5] en utilisant moins de 64 koctets de mémoire à la fois chez l'envoyeur et le receveur.
La source zlib est largement et librement disponible, soumise au copyright suivant :
(C) 1995 Jean-Loup Gailly and Mark Adler
Ce logiciel est fourni 'en l'état', sans aucune garantie expresse ou implicite. En aucun cas les auteurs ne peuvent être tenus pour responsables d'aucun dommage survenant du fait de l'utilisation de ce logiciel.
La permission d'utiliser ce logiciel est accordée à tous pour tout objet, y compris des applications commerciales, ainsi que de l'altérer et de le redistribuer librement, sous réserve des restrictions suivantes :
1. L'origine de ce logiciel ne doit pas être dissimulée ; vous ne devez pas revendiquer la rédaction du logiciel original. Si vous utilisez ce logiciel dans un produit, un remerciement dans la documentation du produit serait appréciée, mais n'est pas exigé.
2. Les versions altérées de la source doivent être clairement marquées comme telles, et ne doivent pas se présenter comme étant le logiciel d'origine.
3. Cet avis ne doit pas être retiré ni altéré des distributions de la source.
Jean-Loup Gailly Mark Adler
gzip@prep.ai.mit.edu madler@alumni.caltech.edu
Si vous utilisez la librairie zlib dans un produit, il serait apprécié de *ne pas* recevoir des quantités de documents légaux à signer. Les sources sont fournies gracieusement mais sans garantie d'aucune sorte. La librairie a été entièrement écrite par Jean-Loup Gailly et Mark Adler ; elle ne comporte aucun code de tiers.
Le format et l'algorithme de compression deflate sont fondés sur la compression Lempel-Ziv LZ77 ; des recherches extensives ont été menées par le projet GNU et le groupe de travail Portable Network Graphics à l'appui de son statut libre de brevet.
Avant qu'aucun paquet PPP Deflate puisse être communiqué, PPP doit atteindre la phase de protocole de couche réseau, et le protocole de contrôle de CCP doit atteindre l'état Ouvert.
Exactement un datagramme PPP est encapsulé dans le champ d'information de PPP, et le champ de protocole PPP contient 0xFD ou 0xFB. 0xFD est utilisé quand le protocole multiliaison PPP n'est pas utilisé ou "au-dessus de" multiliaison. 0xFB est utilisé "en dessous de" multiliaison, pour compresser indépendamment sur les liaisons individuelles d'un faisceau multiliaison.
La longueur maximum du datagramme PPP Deflate transmis sur une liaison PPP est la même que la longueur maximale du champ Information d'un paquet encapsulé en PPP.
Seuls les paquets avec des numéros de protocole PPP dans la gamme 0x0000 à 0x3FFF et ni 0xFD ni 0xFB sont compressés. Les autres paquets PPP sont toujours envoyés non compressés. Les paquets de contrôle sont peu fréquents et ne devraient pas être compressés pour ménager la robustesse de l'application.
Bourrage
Les paquets PPP Deflate exigent la négociation préalable de l'option de configuration Self-Describing-Padding [6] si le bourrage est ajouté aux paquets. Si aucun bourrage n'est ajouté, alors Self-Describing-Padding n'est pas exigé.
Fiabilité et séquençage
PPP Deflate exige que les paquets soient livrés en séquence. Il s'appuie sur les paquets LCP Reset-Request et Reset-Ack ou sur la renégociation du protocole de contrôle de compression [2] pour indiquer la perte de synchronisation entre l'émetteur et le receveur. La séquence de contrôle de trame (FCS, Frame Check Sequence) de LCP détecte les paquets lésés et les mécanismes normaux les éliminent. Les paquets manquants ou décalés sont détectés par le numéro de séquence inclus dans chaque paquet. Le numéro de séquence du paquet devrait être vérifié avant de décoder le paquet.
Au lieu de transmettre un paquet de Reset-Request lors de la détection d'une erreur de séquence, le receveur PEUT momentanément forcer CCP à abandonner un état Ouvert en transmettant une nouvelle demande Configure-Request de CCP. Cette méthode est plus coûteuse que d'utiliser les Reset-Request.
Lorsque le receveur rencontre d'abord un numéro de séquence inattendu, il DEVRAIT envoyer un paquet LCP Reset-Request comme défini dans le protocole de contrôle de compression. Lorsque l'émetteur envoie un Reset-Ack ou lorsque le receveur reçoit un Reset-ACK, ils doivent remettre le numéro de séquence à zéro, purger le dictionnaire de compression, et reprendre l'envoi et la réception des paquets compressés. Le receveur DOIT éliminer tous les paquets compressés après la détection d'une erreur et jusqu'à ce qu'il reçoive un Reset-Ack. Cette stratégie peut être vue comme l'abandon de la transmission d'un "fichier" et le début de la transmission d'un nouveau "fichier."
L'émetteur doit purger son historique de compression et répondre par un Reset-Ack chaque fois qu'il reçoit une Reset-Request, parce qu'il ne peut pas savoir si les précédents Reset-Acks ont atteint le receveur. Le receveur n'a pas besoin de faire quoi que ce soit à son historique quand il reçoit un Reset-Ack, parce que l'émetteur ne va simplement pas se référer à un historique antérieur ('deflate' est compresseur à fenêtre glissante).
Lorsque la liaison est occupée, une erreur de décompression est normalement suivie par plusieurs autres avant que le Reset-Ack puisse être reçu. Il n'est pas souhaitable d'émettre des Reset-Request plus fréquemment que le délais d'aller-retour de la liaison, parce que des Reset-Request redondants causent une purge inutile du dictionnaire de compression. Le receveur PEUT transmettre une Reset-Request supplémentaire chaque fois qu'il reçoit un paquet compressé ou non compressé jusqu'à ce qu'il reçoive enfin un Reset-Ack, mais le receveur ne devrait pas transmettre d'autre Reset-Request jusqu'à ce que le délai Reset-Ack pour le précédant ne soit écoulé. Le receveur DOIT transmettre suffisamment de paquets Reset-Request pour s'assurer que l'émetteur en reçoit au moins un. Par exemple, le receveur peut choisir de ne pas transmettre un autre Reset-Request avant un délai d'une seconde (ou, bien sûr, la réception d'un Reset-Ack et la reprise de la décompression).
Expansion des données
'Deflate', tel qu'utilisé dans la présente norme, étend les données incompressibles d'approximativement 14 à 18 octets (8 octets dans le plus mauvais cas au niveau 'deflate', deux autres octets pour la fin de bloc 'deflate' et l'en-tête de bloc de synchronisation de longueur zéro, deux octets de numéro de séquence, et deux octets pour l'ajout du champ de protocole PPP à l'unité de données transmise).
Le projet de proposition de compression BSD [7] décrit un mécanisme d'échappement pour les données incompressibles qui constitue un compromis à une violation de mise en couche pour les complications irritantes de longueurs effective de MRU variables et potentiellement imprévisibles. Ce mécanisme d'échappement direct (et beaucoup du texte de sa description) est aussi utilisé ici.
Si un paquet de données incompressible ne tient pas dans la MRU de la liaison, le paquet DOIT être envoyé dans sa forme originale sans encapsulation CCP ; les paquets PPP avec une expansion de données significative qui n'excèdent pas la MRU de la liaison DEVRAIENT être envoyés dans leur forme originale sans encapsulation CCP. Dans ces deux cas, l'émetteur doit incrémenter le numéro de séquence, car les futurs paquets encapsulés dépendent de la réception correcte d'un certain nombre des paquets non encapsulés.
Lorsque un paquet PPP est reçu avec des numéros de protocole PPP dans la gamme de 0x0000 à 0x3FFF, (excepté, bien sûr, 0xFD et 0xFB) on suppose que le paquet aura causé de l'expansion. Le paquet est localement ajouté à l'historique de compression. (Étant donnée la définition du format 'deflate', une méthode convenable pour le faire est de "décompresser" localement un en-tête mémorisé en bloc de la longueur appropriée, suivi par le bloc de données réel ; ou les données peuvent simplement être ajoutées à l'historique du receveur, selon les modalités propres de la mise en œuvre.)
L'envoi de paquets incompressibles dans leur encapsulation d'origine évite un maximum de complications d'unité de transmission. Si les paquets non compressés pouvaient être plus grands que dans leur forme d'origine, il serait alors nécessaire que les couches supérieures d'une mise en œuvre traitent la liaison PPP comme si elle avait une MTU plus petite, afin de s'assurer que les paquets incompressibles compressés ne sont jamais supérieurs à la MTU PPP négociée.
Utiliser l'encapsulation d'origine pour les paquets incompressibles complique la mise en œuvre. L'émetteur et le receveur doivent commencer à mettre des information dans le dictionnaire de compression en commençant par les mêmes paquets, sans compter sur le fait qu'ils vont voir un paquet compressé pour la synchronisation. Les quelques premiers paquets après la purge du dictionnaire sont habituellement incompressibles, et donc ils vont vraisemblablement être envoyés dans leur encapsulation d'origine, juste comme commencent à arriver les paquets avant compression. Si les paquets CCP ou LCP sont traités séparément des paquets de la couche réseau (par exemple, un "démon" pour les paquets de contrôle et un "code noyau" pour les paquets de données) il faut veiller à s'assurer que l'émetteur synchronise la purge du dictionnaire avec la transmission du configure-ACK ou Reset-Ack qui débuté la compression, et le receveur doit de même s'assurer que son dictionnaire est purgé avant qu'il ne traite le paquet suivant.
Un résumé du format de paquet PPP Deflate est donné ci-dessous.
Les champs sont transmis de gauche à droite.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocole PPP | Séquence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Données...
+-+-+-+-+-+-+-+-+
Protocole PPP
Le champ Protocole PPP est décrit dans l'encapsulation du protocole point à point [1].
Lorsque le protocole de compression PPP Deflate est négocié avec succès par le protocole de contrôle de compression PPP [2], la valeur du champ de protocole est 0xFD ou 0xFB. Cette valeur PEUT être compressée lorsque Protocol-Field-Compression est négociée.
Séquence
Le numéro de séquence est envoyé avec l'octet de plus fort poids en premier. Il commence à 0 quand le dictionnaire est purgé, et il est incrémenté de 1 pour chaque paquet, y compris les paquets non compressés. Le numéro de séquence après 65 535 est zéro. En d'autres termes, le numéro de séquence "déborde" de la façon habituelle.
Le numéro de séquence assure que les paquets perdus ou décalés ne causent pas la désynchronisation des bases de données de compression des homologues. Lorsque un numéro de séquence inattendu est rencontré, les dictionnaires doivent être resynchronisés avec un Reset-Request ou Configure-Request CCP. Le numéro de séquence de paquet peut être vérifié avant qu'un paquet compressé ne soit décodé.
Données
Le paquet encapsulé PPP compressé, comportant les champs Protocole et Données de l'original, le paquet non compressé suit.
La compression du champ Protocole DOIT être appliquée au champ de protocole dans le paquet original avant le calcul du numéro de séquence ou que le paquet entier ne soit compressé, sans considération de la négociation de la compression du champ protocole PPP. Et donc, si le numéro de séquence d'origine était inférieur à 0x100, il doit être compressé sur un seul octet.
Le format de base des données compressées est décrit avec précision par la spécification du format de données compressées 'Deflate' [3]. Chaque paquet transmis doit commencer à une limite de bloc 'deflate', pour assurer la synchronisation lorsque des données incompressibles remettent à zéro l'état de l'émetteur ; pour le garantie, chaque paquet émis doit être terminé par un bloc 'deflate' non compressé de longueur zéro (BTYPE de 00). Cela signifie que les quatre derniers octets du format compressé doivent être 0x00 0x00 0xFF 0xFF. Ces octets DOIVENT être retirés avant la transmission ; le receveur peut les réinsérer si c'est exigé par la mise en œuvre.
3. Format de l'option de configuration
Description
L'option de configuration Deflate de CCP PPP négocie l'utilisation de PPP Deflate sur la liaison. Par défaut ou en cas de désaccord de dernière minute, aucune compression n'est utilisée.
Un résumé du format de l'option de configuration PPP Deflate est donné ci-dessous. Les champs sont transmis de gauche à droite.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Longueur |Fenêtre|Méthode| MBZ |Chk|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
26 pour PPP Deflate.
Longueur
3
Fenêtre
Représente la taille maximum de fenêtre que le décompresseur veut allouer ; exprimée comme le logarithme en base 2 de la taille de la fenêtre LZ77, moins 8. Les décompresseurs conformes à 'deflate' doivent accepter la taille maximum de fenêtre de 32 kbit, représentée par une valeur de 7. Un compresseur conforme à 'deflate' a la liberté d'utiliser une taille de fenêtre réduite, et donc un compresseur PPP Deflate DOIT soit honorer la restriction demandée soit rejeter l'option.
Méthode
Doit être le nombre binaire 1000. Représente l'identifiant de méthode de compression 'zlib' de '8' pour la compression 'deflate' avec une taille de fenêtre jusqu'à 32 k.
MBZ
Doit être tout de bits 0.
Chk
Doit être 00 pour spécifier la méthode de vérification de numéro de séquence.
Considérations pour la sécurité
Les questions de sécurité ne sont pas abordées dans le présent mémoire.
[1] W. Simpson, éditeur, "Protocole point à point (PPP)", STD 51, RFC 1661, Daydreamer, juillet 1994.
[2] D. Rand, "Protocole de contrôle de compression en PPP (CCP)", RFC 1962, juin 1996.
[3] L. P. Deutsch, "Spécification du format 'Deflate' de compression de données", projet disponible à ftp.uu.net:/pub/archiving/zip/doc/deflate-1.1.doc.
[4] J.-L. Gailly, "Zlib 0.95 beta".
[5] Bell, T.C., Cleary, G. G. and Witten, I.H., "Text Compression", Prentice_Hall, Englewood Cliffs NJ, 1990. Le texte lui-même se trouve à ftp.uu.net:/pub/archiving/zip/.
[6] W. Simpson, "Extensions LCP pour PPP", RFC 1570, janvier 1994.
[7] V. Schryver, "Protocole de compression BSD en PPP", RFC 1977, août 1996.
William Simpson a fourni l'excellente idée de ne pas utiliser d'octets d'en-tête additionnel pour les paquets incompressibles.
Adresse du président
Le groupe de travail peut être contacté via le président actuel :
Karl Fox
Ascend Communications
3518 Riverside Drive, Suite 101
Columbus, Ohio 43221
mél : karl@ascend.com
Adresse de l'auteur
Les questions sur le présent mémoire peuvent aussi être adressées à :
John Woods
Proteon, Inc.
9 Technology Drive
Westborough MA 01581-1799
(508) 898-2800 ext. 2651
mél : jfw@funhouse.com