FR2857538A1 - Systeme et methode de compression d'en-tete de paquets bases sur la creation dynamique d'un gabarit - Google Patents

Abstract

Système de compression d'en-tête pour compresser l'en-tête des paquets de données d'une communication transmis entre un noeud d'entrée (10) et un noeud de sortie (12) à travers un réseau de transmission de données (14) comprenant des moyens de création de gabarit dans le noeud d'entrée et le noeud de sortie, adaptés pour créer le même gabarit de compression à partir d'un nombre prédéterminé de paquets de données non compressées au début de la communication respectivement transmis par le noeud d'entrée et reçus par le noeud de sortie, et des moyens de compression d'en-tête dans le noeud d'entrée, adaptés pour compresser l'en-tête de chaque paquet qui suit le nombre prédéterminé de paquets de données non compressés avant de le transmettre à travers le réseau de transmission de données, la compression étant réalisée en utilisant le gabarit de compression.

Description

1 2002-0151

Domaine technique La présente invention concerne de façon générale la compression des en-têtes des paquets de données transmis dans un réseau de transmission de données et concerne en particulier un système et une méthode de compression d'en-tête de paquets basés sur la création dynamique d'un gabarit.

Etat de la technique L'utilisation de la compression d'en-têtes des paquets de données transmis à travers un réseau de transmission de données utilisant le protocole IP ou d'autres protocoles s'appuie sur le fait que beaucoup de champs de l'en-tête sont constants ou changent rarement dans les paquets de données consécutifs appartenant à la même communication. La règle commune utilisée dans la technique de compression est basée sur le fait que les champs d'en-tête qui ne changent pas entre les paquets successifs n'ont pas besoin d'être transmis. Les champs qui changent souvent ou avec des valeurs faibles et/ou prévisibles (par exemple les numéros de séquence TCP) peuvent être codés par incréments de manière à ce que le nombre de bits nécessaire à ces champs décroisse de façon significative. Seuls les champs qui changent souvent ou de façon erratique, par exemple les sommes de contrôle ou les données d'authentification n'ont pas besoin d'être transmis dans chaque en-tête.

La technique de compression est basée sur des gabarits qui définissent quels bits de l'en-tête ont besoin d'être transmis. La plupart des mécanismes standards utilisent des gabarits fixes. Mais, dans l'environnement IP complexe (VoIP, IPv4, IPv6, tunnel), toutes les combinaisons de la pile IP n'ont pas de gabarits prédéfinis qui soient disponibles. En outre, la coexistence de plusieurs mécanismes différents est difficile voire impossible. Ainsi, de nos jours, la 2 2002-0151 compression d'en-tête n'est pas très souvent utilisée ou est limitée à quelques protocoles.

L'IETF (Internet Ingineering Task Force) comporte plusieurs mécanismes de compression d'en-tête qui sont basés sur les règles mentionnées ci-dessus. Le mécanisme de compression d'en-têtes d'origine, CTCP, compresse l'entête IP + TCP de 40 octets en 4 octets. Le compresseur CTCP détecte les retransmissions au niveau de la transmission et envoie un en-tête qui remet le contexte à jour lorsqu elles surviennent.

Ce mécanisme de réparation n'exige pas une signalisation explicite entre le compresseur et le décompresseur.

Un autre mécanisme CRTP, est une compression d'en-têtes qui compresse les 40 octets des en-têtes IPv4/UDP/RTP en un minimum de 2 octets lorsque la vérification par la somme de contrôle UDP n'est pas activée. Si la vérification par la somme de contrôle UDP est activée, l'en-tête CRTP Minimum est de 4 octets. CRTP ne peut pas utiliser le même mécanisme de réparation que CTCP puisque UDP/RTP ne retransmet pas. A la place, CRTP utilise des messages de signalisation explicites entre le décompresseur et le compresseur, appelés messages CONTEXT STATE pour indiquer que la transmission n'est pas synchronisée. Le temps de transmission total limite ainsi la vitesse de ce mécanisme de réparation. Sur les liaisons à taux d'erreur élevé avec des temps de transmission aller/retour importants telles que la plupart des liaisons cellulaires, CRTP ne fonctionne pas bien. Chaque paquet perdu sur la liaison provoque la perte de plusieurs paquets suivants puisque la transmission n'est pas synchronisée durant au moins un temps de transmission aller/retour.

La plupart des règles ci-dessus relatives à la compression d'en-tête sont basées sur des gabarits statiques définis pour un seul protocole ou un groupe de protocoles. Un gabarit spécifique est donc construit pour l'entête de chaque type de protocole dans lequel seuls les champs variables à 3 2002-0151 transmettre sont inclus. Les deux dispositifs d'extrémité qui utilisent ce mécanisme de compression sont configurés pour l'utiliser, soit de façon statique dans la configuration, soit de façon dynamique avec un protocole définissant quelle méthode doit être utilisée. Puis, lorsqu'une communication de données d'un n ud source à un n ud de destination est initialisée, la première trame est transmise avec un paquet complet, et, pour les trames suivantes, seulement des en-têtes compressés sont transmis en conformité avec un gabarit prédéfini ou déjà élaboré.

Avec les gabarits statiques, il existe plusieurs problèmes. Ainsi, tous les gabarits nécessaires doivent être prédéfinis, et il est également nécessaire de maintenir le gabarit adéquat pour une communication. Un autre problème est d'avoir un seul traitement qui n'affecte ni l'unité de traitement ni la mémoire et qui peut être appliqué indépendamment à plusieurs communications de données. Un autre problème est l'efficacité de la compression dans la mesure où certaines communications ne peuvent pas être compressées correctement sans des gabarits prédéfinis, ce qui est quasiment impossible vu le nombre de protocoles différents à supporter. Enfin, il y a aussi le problème de la négociation et du surplus de trafic qui y est associé.

Jusqu'à maintenant la plupart des efforts ont été réalisés pour réduire le surplus de trafic dû à l'en-tête pour des liaisons à vitesse faible ou moyenne dans lesquels l'impact du traitement de compression d'en-tête n'est pas trop important. Les méthodes de compression mentionnées cidessus nécessitent beaucoup de traitement dans la mesure ou elles sont orientées bit et basées sur des gabarits spécifiques utilisant chacun des règles différentes. Or, la compression d'en-tête devrait aussi concerner les liaisons à grande vitesse et pas seulement la compression d'en-tête IP mais un ensemble d'en-têtes relatifs à plusieurs couches de protocole 2857538 4 2002-0151 dès que plusieurs champs sont inchangés entre les paquets d'une même communication.

Outre ces mécanismes de compression d'en-tête utilisé avec IPv4, d'autres mécanismes ont été développés pour IPv6.

La mise en oeuvre de ces mécanismes différents est complexe dans la mesure où la compression basée sur un gabarit concerne généralement seulement un protocole parmi un ensemble de protocoles prédéfinis et n'est pas compatible et ne coexiste pas avec un autre mécanisme. Ainsi, le mécanisme CRTP est valable seulement pour les en-têtes VoIP et ne fonctionne pas avec d'autres types de communications.

Exposé de l'invention En conséquence, le but principale de l'invention est de fournir un système et de réaliser une méthode dans lesquels le gabarit à utiliser pour la compression ou décompression d'en-tête est créé dynamiquement pour chaque communication de données et de façon identique dans le noeud d'entrée et le noeud de sortie sans nécessiter la transmission du gabarit entre les deux n uds.

L'objet de l'invention est donc un système de compression d'en-tête pour compresser l'en-tête des paquets de données d'une communication transmis entre un n ud d'entrée et un noeud de sortie à travers un réseau de transmission de données, comprenant des moyens de création de gabarit dans le n ud d'entrée et le noeud de sortie adaptés pour créer le même gabarit de compression à partir d'un nombre prédéterminé de paquets de données non compressées au début de la communication respectivement transmis par le noeud d'entrée et reçus par le noeud de sortie, et des moyens de compression d'en-tête dans le noeud d'entrée adaptés pour compresser l'entête de chaque paquet qui suit le nombre prédéterminé de paquets de données non compressés avant de le transmettre à 2857538 5 2002-0151 travers le réseau de transmission de données, la compression étant réalisée en utilisant le gabarit de compression.

Description brève des dessins

Les buts, objets et caractéristiques de l'invention apparaîtront plus clairement à la lecture de la description qui suit faite en référence aux dessins dans lesquels: la figure 1 est un bloc-diagramme représentant schématiquement un système de mise en oeuvre de l'invention dans lequel un noeud d'entrée transmet des données à un noeud de sortie à travers un réseau de transmission de données; la Figure 2 représente un blocdiagramme du mécanisme dans le n ud d'entrée qui est utilisé pour créer le gabarit et compresser les en-têtes des paquets à transmettre; la figure 3 représente un bloc-diagramme du mécanisme dans le noeud de sortie utilisé pour créer le gabarit et décompresser les en-têtes des paquets reçus; les figure 4A, 4B, et 4C montrent respectivement la structure des paquets de données, sans l'utilisation de est un organigramme de la méthode selon est utilisée dans le noeud d'entrée et, est un organigramme de la méthode selon est utilisée dans le noeud de sortie.

Description détaillée de l'invention

En référence à la figure 1, un système dans lequel l'invention peut être mise en oeuvre comprend essentiellement un noeud d'entrée 10 en tant que source transmettant des paquets de données à un noeud de sortie 12 comme destination à travers un réseau de transmission de données 14. Dans le mode de réalisation préféré, le réseau 14 est un réseau à commutation d'étiquettes qui pourrait être n'importe quelle l'invention, en cas d'entête non compressé et en cas d'en-tête compressé; la figure 5 l'invention qui la figure 6 l'invention qui 2857538 6 2002-0151 sorte de réseau à zone étendue (WAN) dans lequel les données sont transmises par commutation de paquets.

Comme expliqué ci-dessous, le noeud d'entrée dispose d'un système dans lequel l'en-tête est compressé au moyen d'un gabarit de compression qui est construit de façon dynamique pour chaque communication. Par conséquent, le noeud d'entrée contient trois blocs de construction principaux qui sont un bloc de consultation de communications qui détermine si un gabarit existant peut être utilisé pour le paquet entrant, un bloc de création dynamique de gabarit utilisé pour construire un nouveau gabarit pour un paquet qui ne peut pas utiliser des gabarits existants et un bloc de compression d'en-têtes qui effectue la compression de l'en-tête du paquet lorsqu'un gabarit existe.

De façon similaire, le noeud de sortie dispose d'un système dans lequel l'en-tête est décompressé au moyen d'un gabarit de compression qui est construit de façon dynamique pour chaque communication en utilisant le même procédé que le noeud d'entrée. Le n ud de sortie contient trois blocs de construction principaux, à savoir un bloc de consultation d'étiquettes qui détermine si le paquet entrant contient un en-tête compressé ou non, et dans le premier cas à quel gabarit l'étiquette d'entrée est associée. Dans l'autre cas, un bloc de création dynamique de gabarit est utilisé pour construire un nouveau gabarit. Finalement, un bloc de décompression d'en-tête effectue la décompression de l'en-tête du paquet lorsqu'un gabarit existe et est fourni par la consultation d'étiquettes.

Une caractéristique essentielle consiste à utiliser une phase d'apprentissage pour construire les gabarits de façon dynamique. Durant cette phase d'apprentissage, les paquets de communication sont transmis de façon transparente c'est à dire sans compression d'en-tête. Dans le mode de réalisation préféré, une étiquette dédiée appelée LABX est utilisée pour 7 2002-0151 les paquets non compressés, tandis qu'une étiquette spécifique LABC est associée à chaque gabarit pour les paquets transmis ayant des en-têtes compressés en relation avec le gabarit correspondant.

La phase d'apprentissage est effectuée sur les paquets IP normaux qui débutent une communication. Un masque est construit en se basant sur l'analyse de plusieurs paquets consécutifs. Pour ceci, un OU exclusif est effectué sur tous les paquets et devient le gabarit de base (orienté bit) qui nécessite seulement d'être amélioré par l'identification de champs de numéros de séquence. Ce procédé sera décrit ci-après en détail.

Le procédé est le même à la transmission et à la réception de sorte que le gabarit n'est pas transmis. Puis, les champs variables sont identifiés et agrégés pour construire l'en-tête compressé. Un mécanisme optimise la longueur du gabarit en se basant sur le taux de densité des bits compressibles. Pour éliminer le risque de désynchronisation entre les procédés utilisés à la source et à la destination pour la création du gabarit, l'étiquette utilisée pour la transmission en clair des paquets (en-tête non compressé) est suivie par un champ de numéros de séquence. En outre, l'intégrité du paquet est assurée par la somme de contrôle du paquet IP.

Un exemple pour la construction du gabarit dans lequel sont utilisés quelques octets (7) en notation binaire et quelques paquets est décrit cidessous: Paquet 1: 01011010 10010101 01100110 11010101 11011000 11100101 11010110 30 Paquet 2: 01011110 10000101 11111111 11010101 11011001 11100101 11010110 Paquet 3: 01011010 10011101 01100110 11010111 11011010 11111101 11010110 8 2002-0151 A noter qu'un plus grand nombre de paquets (par ex 8 paquets) doit être utilisé de manière à au moins identifier les champs de numéros de séquence.

Le gabarit est comme suit: Masque: 00000100 00011000 10011001 00000010 00000011 00011000 00000000 Référence: olollxlo looxxlol xllxxllx llololxl 11011oYY 111XX1ol 11010110 Comme illustré ci-dessus, le gabarit comprend le masque qui résulte du X-OR de tous les paquets et dans lequel les bits 0 correspondent aux bits constants et les bit 1 correspondent aux bits changeants et la référence dans laquelle les bits 0 et 1 correspondent aux bits réels et les X correspondent aux bits qui ont été changés durant la phase d'apprentissage des paquets.

On suppose que, après la phase d'apprentissage, le paquet N suivant est reçu: Paquet N: 01011010 10000101 01100110 11010111 11011011 11111101 11010110 Le paquet N étant conforme à la référence, le masque s'applique: tous les bits du paquet N définis à partir du masque sont agrégés pour la transmission. Ceci correspond à 000000011111.

En fait, dans l'exemple, deux bits ont été identifiés YY du fait qu'ils ressemblent à un champ d'agrémentation. Dans un tel cas, au moins un octet entier (le choix prédéfini est généralement d'un ou plusieurs octets) n'est pas compressé de sorte qu'un nouveau gabarit est créé : Gabarit Masque: 00000100 00011000 10011001 00000010 11111111 00011000 00000000 Référence: olollxlo looxxlol x11xx11x llololxl YYYYYYYY 111XX1ol 11010110 9 2002-0151 Ce qui a pour résultat un en-tête compressé du paquet N qui est le suivant: 000000011101101111 La récupération, le réalignement et l'ajustement du gabarit sont effectués lorsque des erreurs surviennent en redémarrant la phase d'apprentissage, soit à partir du début du procédé de création, soit en utilisant le gabarit actif précédent comme point de départ. Dans ce cas, une nouvelle étiquette basée sur la valeur LABC est utilisée pour modifier le gabarit correspondant en utilisant des nouveaux paquets transmis en clair avec cette étiquette. Par exemple, une communication gardera deux étiquettes ayant seulement un bit différent pour transporter les paquets ayant des en-têtes compressés ou les paquets en clair pour la mise à jour du gabarit. Comme mentionné ci-dessus, les étiquettes suivies de paquets en clair sont suivis de numéros de séquence. Par conséquent, un registre conserve le numéro de séquence courant pour chaque étiquette LABX de façon à vérifier qu'aucun paquet n'a été perdu ou trouvé erroné dans la transmission. Une autre amélioration de l'intégrité du paquet est d'ajouter CRC (de l'en-tête d'origine) pour la vérification de transmission d'erreurs de façon à identifier un besoin de récupération.

Une amélioration du gabarit peut aussi être réalisée en transmettant un ou plusieurs paquets entiers lorsque l'en-tête du paquet entrant ne correspond pas à la référence de l'en- tête courant (définie comme étant l'ensemble des bits inchangés du gabarit). Ceci active un procédé de modification du gabarit. Le gabarit converge ainsi vers un état stable. La procédure de compression doit quelquefois être réactualisée pour être mieux optimisée. Ceci peut être réalisé par un seuil dans le taux de compression, un nombre de paquets transmis ou un compteur de temps.

L'en-tête compressé comprend un champ qui indique que c'est un en-tête compressé : 2002-0151 Ce champ appartient généralement à une couche inférieure (étiquette, Vc, champ dans le PPP) et a déjà été considéré dans des mécanismes de compression d'en-têtes existants. Dans le mode de réalisation préféré, une valeur LABC est utilisée pour un en-tête compressé et une valeur LABX pour un en-tête non compressé avec une valeur LABX dédiée pour les communications basées sur la valeur LABC correspondante (un bit inversé) ce qui perfectionne le procédé d'amélioration du gabarit.

La figure 2 décrit les blocs fonctionnels implémentés dans le noeud d'entrée. Un paquet d'origine arrivant sur l'entrée est analysé dans le bloc 20 qui effectue une consultation de communication. Dans IP, une communication est définie par des paquets ayant au moins la même adresse source, la même adresse destination et qui utilisent généralement le même protocole. Ainsi, l'étape de consultation compare les valeurs d'en-tête du paquet avec les gabarits disponibles dans la table 22. On notera que des actions ou analyses de protocole additionnelles sont effectuées à ce stade si elles n'ont pas été effectuées plus tôt dans le processus. Elles comprennent le routage, le filtrage si besoin et la décrémentation TTL. Par exemple, la table de gabarit peut contenir des instructions de routages associées à une communication ou la consultation peut être mise en oeuvre séparément du procédé de compression d'en-tête. Un tel traitement de paquet IP ne sera pas détaillé ici dans la mesure où il ne fait pas partie de l'invention. La sélection des communications pour lesquelles la compression d'en-tête est activée peut aussi être effectuée à ce stade ou plus tôt dans le traitement dans la mesure où toutes les communications ne nécessitent pas la compression d'en-tête. Une ou plusieurs étiquettes peuvent être réservées pour transporter des paquets qui ne sont pas impliqués dans le mécanisme de compression d'en-tête. De tels paquets ne doivent pas utiliser les 11 2002-0151 étiquettes employées pour le transport des paquets non compressés pour lesquels la compression est définie dans la mesure où ils auront un impact dans le procédé de compression. Ceci peut aussi être une façon de résoudre la limitation du calcul de performance. Lorsqu'un niveau de traitement défini est atteint, les communications entrantes supplémentaires ne sont pas compressées pour éviter un surplus de traitement le temps d'atteindre un niveau souhaitable.

La table de gabarit 22 dans laquelle la consultation est effectuée peut contenir une ou plusieurs communications correspondant à la consultation ou aucune. Dans ce dernier cas, le procédé du bloc 25 est activé de façon à créer un nouveau gabarit pour cette communication. Dans le premier cas, et si plus d'un gabarit est disponible, une seconde consultation sélectionne le gabarit qui a le moins de champs indéfinis correspondant par exemple au nombre de bits 1 dans le masque correspondant, ce qui est un calcul facile. Une fois que le gabarit à utiliser est défini, le procédé de compression d'en-tête du bloc 24 est activé en utilisant le mécanisme décrit à la figure 1. Le procédé de création du nouveau gabarit représenté par le bloc 25 peut fonctionner, soit en mode de création pour une nouvelle communication, soit en mode d'amélioration. Ce mode est fourni par l'analyse effectuée par le bloc d'analyse de paquet et consultation 20 qui détermine si l'adresse source et/ou l'adresse de destination de la communication sont présentes dans le gabarit. Si soit l'adresse source, soit l'adresse de destination n'est pas définie dans la table de gabarit pour une communication, alors une création d'un nouveau gabarit est nécessaire. Si les champs d'adresse source et de destination existent dans un gabarit mémorisé dans la table 22, alors un mode d'amélioration doit être utilisé. La différence essentielle entre les deux modes est qu'ils utilisent des étiquettes différentes pour transmettre les paquets non 12 2002-0151 compressés ce qui aide des deux côté à construire le nouveau gabarit. En rappel, un gabarit est construit en parallèle dans les noeuds d'entrée et de sortie grâce à l'ensemble de paquets non compressés transmis avant la compression. Pour cela, on utilise une étiquette dédiée dont la valeur est dérivée de l'étiquette utilisée pour transmettre des paquets ayant des en-têtes compressés associés au gabarit de la communication. Des étiquettes pour des en-têtes compressés sont appelées LABC tandis que les étiquettes pour les en-têtes non compressés associés sont appelées LABX. Elles diffèrent seulement par un bit inversé de sorte que c'est un moyen facile de les différencier.

Un gabarit est créé en utilisant la méthode de la figure 1 en utilisant plusieurs paquets non compressés consécutifs. Une fois défini, un nouveau gabarit doit être associé à une nouvelle étiquette (une LABC et LABX correspondante pour des modifications ultérieures). Lorsque le premier paquet est reçu pour construire le gabarit, le bloc 25 demande au bloc de gestion d'étiquettes 26 de fournir une nouvelle étiquette pour ce gabarit et la mémorise dans la table 22 dans la rangée où le nouveau gabarit à été mis. Lorsque le procédé est terminé, le bloc 25 mémorise ce nouveau gabarit dans la table de gabarit 22 avec son étiquette associée.

La méthode d'affectation et de gestion d'étiquette ne fait pas partie de l'invention et peut être mise en oeuvre au moyen de méthodes différentes. Une méthode est l'utilisation d'un protocole de distribution d'étiquette qui affecte une nouvelle étiquette pour le noeud d'entrée et le noeud de sortie pour chaque nouvelle communication. Un tel protocole de distribution d'étiquettes dépend en principe de l'infrastructure réseau utilisée telle que MPLS. Une autre méthode est d'affecter des étiquettes LABC/LABX seulement dans le noeud d'entrée en utilisant une procédure d'auto- 13 2002-0151 affectation. L'autre côté (noeud de sortie) comprendra que pour chaque nouvelle étiquette LABX pas encore définie, une nouvelle communication a commencé et mettra à jour sa base de données avec les étiquettes LABC et LABX correspondantes. Dans cette dernière implémentation, seules les étiquettes pour les communications non compressées définies LABU doivent être prédéfinies de façon à éviter une incompréhension due aux affectations d'étiquettes entre le noeud d'entrée et le noeud de sortie. Un procédé additionnel est nécessaire pour effacer les étiquettes avant de les réaffecter quand il n'y plus d'étiquettes disponibles. Le champ de contrôle d'option des étiquettes est utilisé pour un tel but pour les étiquettes existantes.

Le procédé de création d'une nouvelle communication transmet chaque paquet avec un en-tête non compressé et l'étiquette LABX associée au constructeur de paquet 28 qui dans ce cas transmet juste le paquet à l'interface de sortie après l'ajout d'un numéro de séquence entre l'étiquette et le paquet. Le numéro de séquence est nécessaire pour éviter de construire des gabarits différents des deux côtés si un paquet est perdu. Si un paquet est modifié, le CRC du paquet doit permettre d'identifier l'erreur. En cas d'erreur, soit un mécanisme de récupération est utilisé pour retransmette le paquet manquant, soit la création de gabarit est réinitialisée pour cette communication. La réinitialisation est effectuée grâce à un champ de contrôle d'option qui suit l'étiquette tel que décrit avec plus de détail dans la figure 4.

Comme mentionné ci-dessus, lorsqu'un gabarit est trouvé pour un paquet entrant dans le bloc 20 le procédé continue au bloc 24. Le bloc 20 procure au bloc 24 le paquet lui-même ou au moins la partie (nombre d'octets) qui est incluse dans le gabarit, le gabarit lui-même et l'étiquette associée (LABC) à utiliser. Le mécanisme de compression d'en- tête est très simple puisqu'il extrait simplement les bits qui sont définis 14 2002-0151 comme pouvant être modifiés dans l'en-tête du paquet et les agrège dans le même ordre que dans l'en-tête d'origine. En d'autres termes, tous les bits constants de l'en-tête sont retirés ce qui donne l'en-tête compressé. En option, un CRC de l'en-tête d'origine est calculé.

L'en-tête compressé, les données restantes (directement à partir du bloc 24 ou d'une autre mémoire intermédiaire dépendant de l'implémentation matérielle), l'étiquette LABC et de façon optionnelle le CRC de l'en-tête sont fournis par le bloc 24 au bloc de construction de paquet 28 qui juxtapose tous ces champs pour obtenir la trame compressée qui est transmise à l'interface de sortie. Le constructeur de paquet peut ajouter, si nécessaire, des champs optionnels (CRC, longueur, contrôle) pour une gestion améliorée du mécanisme de compression entre l'étiquette et l'entête compressé tel que défini à la figure 4.

La figure 3 décrit les blocs fonctionnels implémentés dans les n uds de sortie. Un paquet venant de l'entrée est analysé dans le bloc 30 qui effectue une consultation d'étiquettes. Ainsi, la consultation indique d'abord si le paquet utilise un en-tête compressé ou est un paquet non compressé. Si l'étiquette est une étiquette LABC, le paquet est compressé et un gabarit est associé. Si l'étiquette est une étiquette LABX, le paquet n'est pas compressé. Dans ce dernier cas, soit l'étiquette LABX est une nouvelle valeur LABX auquel cas un procédé de création de gabarit doit débuter, soit LABX est une étiquette existante associée à un gabarit (différent d'un bit de la valeur LABC existante) et une modification de gabarit (ou un effacement d'étiquette) débute. La table d'étiquettes et gabarits 32 dans laquelle la consultation est effectuée contient ou non une concordance pour cette étiquette.

Si une valeur LABC est utilisée, le paquet (au moins les champs comprenant l'en-tête compressé) est fourni au bloc 2857538 15 2002-0151 de décompression d'en-tête 34 qui reconstruit l'en- tête d'origine. Si une valeur LABX est détectée, le paquet est transmis au bloc de création et de mise à jour de gabarit 35 qui crée un nouveau gabarit pour la communication correspondant au paquet entrant. Le bloc 35 valide le numéro de séquence entrant pour continuer à créer le gabarit. En cas d'erreur, le procédé est arrêté et une alerte est fournie au constructeur de paquets du noeud d'entrée 28 de façon à commencer la procédure de récupération.

Un procédé de création de nouveau gabarit représenté sur le bloc 35 est identique au procédé du bloc 25 et aboutit à la même définition de gabarit qu'il travaille en mode de création pour une nouvelle communication ou en mode d'amélioration. Comme mentionné sur la figure 2, le même gabarit dynamique est construit en parallèle dans les noeuds d'entrée et de sortie grâce à des paquets non compressés transmis avant la compression et traités respectivement par les bloc 25 et 35.

Un gabarit est par conséquent créé dans le noeud de sortie en utilisant la méthode décrite dans la figure 1 grâce à plusieurs paquets non compressés consécutifs. Une fois défini, un nouveau gabarit a besoin d'être associé à une nouvelle étiquette (une LABC et la LABX correspondante pour des modifications ultérieures). Lorsque le premier paquet est reçu pour construire le gabarit, le bloc 35 ajoute une rangée LABX et LABC associéedans la table 32 qui définit les champs où le nouveau gabarit pour la communication correspondante est ajouté. Lorsque le processus est terminé, le bloc 35 mémorise ce nouveau gabarit et son étiquette associée dans la table des gabarits 32.

L'objectif de l'affectation d'étiquette et d'avoir finalement la même étiquette pour le même gabarit. L'affectation automatique de l'invention dans le noeud d'entrée 16 2002-0151 avec reconnaissance dans le n ud de sortie satisfait une telle exigence.

Le procédé de création de communication transmet chaque paquet avec un entête non compressé et l'étiquette LABX associé au constructeur de paquet 38 qui, dans ce cas, envoie le paquet à l'interface de sortie après retrait de l'étiquette et des champs optionnels pour conserver seulement le paquet d'origine reçu à l'entrée de la figure 2.

Comme mentionné ci-dessus, lorsqu'un paquet du type LABC est reçu et qu'un gabarit est trouvé pour le paquet entrant au bloc 30, le procédé continue au bloc 34. Le bloc 30 fournit au bloc 34 le paquet lui-même ou au moins les champs comprenant l'en-tête compressé et le gabarit lui-même de façon à reconstruire l'en-tête d'origine et à effectuer la vérification si un CRC est ajouté. Le mécanisme de compression d'en-tête est très simple puisqu'il remplace seulement les bits manquants, qui sont définis comme étant susceptibles de changer dans le gabarit, par les bits reçus de l'en-tête compressé ce qui restaure l'en-tête d'origine.

L'en-tête reconstruit et les données restantes (directement du bloc 34 ou d'une autre mémoire intermédiaire dépendant de l'implémentation) sont fournis par le bloc 34 au bloc constructeur de paquets 38 qui transmet ensuite le paquet reconstruit à l'interface de sortie.

En référence à la figure 4A, le paquet d'origine 40 comprend 2 champs, les données et l'en-tête. Le point de démarcation entre les deux champs n'est pas nécessairement en relation avec l'en-tête réel et la définition du bloc de données mais simplement avec la longueur maximum du gabarit.

Par exemple, la taille maximale du gabarit peut être arbitrairement établie à 128 octets à cause de l'implémentation matérielle, ce qui ne correspond pas nécessairement aux tailles d'en-têtes définies par les protocoles.

17 2002-0151 Dans le mode de réalisation préféré, les types de paquets sont identifiés par des étiquettes. Les paquets d'origine 42 illustrés sur la figure 4B utilisent une étiquette du type LABX. Une telle étiquette est simplement ajoutée à l'en-tête du paquet d'origine transmis sur le réseau. Les paquets 44 avec des en-têtes compressés, illustrés sur la figure 4C, utilisent une structure différente avec un format d'étiquette spécifique. Les étiquettes LABC et LABX sont décrites en détail ci-dessous.

Le format d'étiquette comprend un champ "option" (OP) qui indique si des champs additionnels sont ajoutés entre la valeur de l'étiquette de commutation (valeur SW + 1 bit de compression) et l'en-tête (compressé ou non). Ce bit de compression est ensuite suivi de plusieurs champs dont la présence est établie en utilisant le champ "option" mentionné ci-dessus. Ils comprennent un premier champ optionnel qui est la somme de contrôle de l'en-tête d'origine (CRC) pour vérifier l'en-tête reconstruit) en cas de LABC ou un champ de numéros de séquence (SEQ) en cas de LABX, un second champ de contrôle CTL pour la gestion bout à bout utilisé pour l'amélioration de l'en-tête, effacement d'étiquettes ou restauration de gabarits, et finalement le champ requis des bits delta (000000011101101111 dans l'exemple) aussi appelé données d'en-tête compressé dans le cas de LABC. Pour LABX, l'en-tête normal suit le dernier champ additionnel alors que c'est l'en-tête compressé en cas de LABC. On notera que, en cas d'erreur, de façon à accélérer le processus de récupération, un paquet vide LABX avec seulement un champ de contrôle peut être renvoyé s'en y inclure de données en réponse à un problème découvert dans la direction de trafic opposée.

Dans le mode de réalisation préféré, la valeur SW a une longueur prédéfinie telle que 16 bits par défaut. Cette taille peut changer selon la vitesse du lien et le nombre maximum des 18 2002-0151 différentes communications à supporter. Si la commutation d'étiquettes est utilisée, cette valeur (et longueur) peut changer à chaque n ud (remplacement d'étiquette) mais la distribution d'étiquettes prend en compte ce remplacement. Le bit de compression suit ce champ de valeur SW. Une valeur 0 indique que l'étiquette est une étiquette LABX alors qu'une valeur 1 indique une étiquette LABC. Le champ "option" (OP) est établi à 2 bits dont la valeur indique la présence ou non des champs optionnels.

É00 signifie aucun champ optionnel additionnel ^ 01 signifie première option seulement: numéro de séquence (SEQ) si LABX ou somme de contrôle d'en-tête (CRC) si LABC É 10 signifie seconde option seulement: champ de contrôle 15 dans les deux cas É 11 signifie les deux options Le numéro de séquence est un champ de 2 octets, le CRC est un champ de 2 ou 4 octets, le champ de contrôle est un octet dans le mode de réalisation proposé avec possibilité d'extension défini dans le champ de contrôle. Le champ de contrôle permet d'échanger des informations ou des commandes entre le n ud d'entrée et le n ud de sortie telles que le mode commande, le mode configuration, le mode d'échange d'étiquettes, le mode d'échange de gabarits, le mode sécurité et le mode récupération. Le mode est défini avec les trois premiers bits. Les trois bits suivants définissent l'action et les deux derniers bits l'extension du champ de contrôle pour échanger plus de données et dépend du type d'action.

Des exemples d'utilisation du champ de contrôle sont de: restaurer une création de gabarit, renvoyer un paquet perdu ou erroné, modifier les paramètres de configuration tels que la longueur du gabarit, le nombre de paquets à analyser pour créer un gabarit, la longueur d'étiquette ou la longueur du champ d'incrémentation des gabarits. La vérification 19 2002-0151 d'intégrité des gabarits/tables d'étiquettes est aussi réalisée en utilisant ce champ avec une possibilité de restauration de tables.

Le procédé selon l'invention qui est implémenté dans le noeud d'entrée, illustré sur la figure 5, commence lorsqu'un paquet d'origine est reçu à l'étape 50 et doit être transmis sur le réseau WAN pour lequel la compression de l'en-tête est validée. Les en-têtes du paquet définis par le protocole sont analysés à l'étape 51 (au moins le premier en-tête de protocole qui est IP). En se basant sur le filtrage prédéfini, le paquet correspond à un type pour lequel la compression d'en-tête doit être appliquée ou non. Cette sélection à l'étape 52 peut être simplement faite sur les champs d'adresse et de protocole de l'en-tête. Si aucune compression d'en-tête est nécessaire, le paquet est alors traité à l'étape 58 en y ajoutant une étiquette prédéfinie appelée LABU utilisant la structure LABX pour laquelle on n'utilise pas de champ additionnel mais seulement la valeur SW suivie par un 0 parce que le procédé est très similaire au transport de paquets non compressés, mais cette valeur ne doit pas être utilisée pour la création de gabarits.

Si le paquet appartient à une communication pour laquelle la compression d'en-têtes est admise, une consultation est effectuée pour vérifier si ce paquet appartient à une communication existante pour laquelle un gabarit existe déjà. A l'étape 53, si au moins un gabarit existe, le meilleur est sélectionné et le procédé continue à l'étape 55 où les bits qui diffèrent entre le gabarit et l'en-tête du paquet entrant sont extraits et groupés pour construire l'en-tête différentiel. Puis, à l'étape 57 une étiquette est utilisée, fournie par d'autres moyens qui utilisent la structure des étiquettes LABC. Le champ CRC, si il existe, est élaboré avec des valeurs correspondant à l'en-tête. Le champ de contrôle est ajouté si des données de 2002-0151 contrôle doivent être transmises à l'étape finale 59 et tous les champs sont agrégés selon la structure 44 définie à la figure 4 suivi par la transmission du paquet et son étiquette sur le réseau WAN.

Si la consultation de l'étape 53 se termine sans trouver de gabarit pour le paquet, un nouveau gabarit doit être construit. Un numéro de sequence est affecté temporairement de sorte que les autres paquets de la même communication auront le même traitement et participeront à la création du gabarit. Cette fonction de l'étape 54 peut fonctionner en deux modes. Soit la création d'un nouveau gabarit est effectuée, soit une mise à jour du gabarit est activée. Cette dernière est seulement possible si on a pu, à l'étape 53, trouver un gabarit proche du gabarit à utiliser mais avec quelques différences mineures empêchant de l'utiliser directement. Dans ce cas, ce gabarit est fourni pour la création de gabarits en tant que référence mais non comme gabarit réel de sorte que le gabarit créé sera plus restrictif avec plus de bits delta à transmettre. Ce peut être le cas dans une communication où les paquets ont des champs d'adresse et de protocole communs et dans lesquels d'autres champs ne changent pas au début de la transmission mais seulement après un nombre significatif de paquets. Pour une telle communication, l'apprentissage avec les premiers paquets ne fournit pas un gabarit valide pour tous les paquets de cette communication.

Le gabarit est construit dans les deux cas en utilisant les paquets consécutifs de la même communication qui sont identifiés comme aboutissant au même résultat après consultation des gabarits résultant en une même affectation du numéro de communication. L'étiquette LABC est requise à l'étape 56 lorsqu'un paquet commence une création de gabarit.

Les paquets suivants de la même communication évitent l'étape 56. Le procédé à l'étape 58' finit par la transmission sur le 21 2002-0151 réseau WAN du paquet d'origine non compressé ayant une étiquette LABX utilisant le format 44 défini à la figure 4. A ce stade, le numéro de séquence est incrémenté et si nécessaire un champ de contrôle est ajouté dans LABX.

La figure 6 décrit le procédé de réception dans le noeud de sortie qui débute avec un paquet et son étiquette reçus à partir du réseau WAN à l'étape 60. Le choix du procédé est effectué à l'étape 61 avec trois voies possibles. Si l'étiquette du paquet entrant est du type LABX, le procédé va à l'étape 63 correspondant au paquet non compressé reçu pour la création de gabarit. Si l'étiquette entrante est du type LABU, le procédé va à l'étape 68 correspondant à des paquets non compressés qui ne nécessitent pas la création de gabarits dans la mesure où ils sont transmis de façon transparente. Si l'étiquette est une étiquette LABC connue, le procédé va à l'étape 65 correspondant aux paquets ayant des en-têtes compressés pour lesquels l'en-tête devrait être recréé. Les étiquettes LABC inconnues sont traitées par un procédé d'erreur non montré.

Le procédé détaillé pour les paquets transmis avec des étiquettes LABX débute à l'étape 63 où un nouveau gabarit est créé en utilisant exactement le même procédé défini à la figure 5 dans la mesure où les noeuds d'entrée et de sortie suivent le même procédé qui aboutit au même gabarit. Si une LABX est utilisée pour laquelle une LABC est déjà affectée, la création de gabarit utilise le mode mise à jour tandis que si aucune étiquette LABC n'est associée, ce qui correspond à une LABX inconnue, une nouvelle création est effectuée. Pour chaque paquet reçu le numéro de séquence est vérifié aussi bien que l'intégrité du paquet (vérification de la somme de contrôle). Au cas d'erreur de paquet découverte à l'étape 64, la création de gabarit est arrêtée puisqu'elle aurait pour conséquence de créer un gabarit différent des deux côtés. Par conséquent, le procédé de récupération de l'étape 70 est 22 2002-0151 appelé par l'étape 64 de façon, soit à restaurer la création de gabarit, soit à demander la retransmission du paquet erroné si possible, ce qui est fait en utilisant les champs de contrôle du côté transmission du noeud correspondant à la liaison entre les blocs 35 et 28 des figures 3 et 2 respectivement. Puis le procédé continue à l'étape 68. Lorsque aucune erreur n'est trouvée à l'étape 64, une nouvelle rangée LABC et gabarit correspondant à l'étiquette LABX reçue est mémorisée à l'étape 66 lorsque le premier paquet est traité en cas de nouvelle étiquette LABX inconnue. Etape 66, la création de rangée dans la base de donnés est évitée pour les paquets suivants de la même communication utilisée pour la même création de gabarit et en cas de LABX existante correspondant à une mise à jour du gabarit. Finalement, à l'étape 68, l'étiquette LABX ou LABU d'un paquet transparent est retirée et ces paquets sont transmis à l'interface de destination de sortie. Les paquets erronés de l'étape 62 sont transmis comme s'ils devaient être éliminés, ceci n'étant pas une fonction incluse dans la présente invention.

Le procédé LABC détaillé commence à l'étape 65 lorsque l'étiquette LABC est retirée et une consultation fournit le gabarit correspondant qui permet de reconstruire l'en-tête d'origine à l'étape suivante 67. A cette étape une vérification d'intégrité peut être effectuée si l'option de CRC d'en-tête est activée. Autrement, le paquet entier CRC, si il est présent et inchangé depuis le noeud d'entrée, peut être utilisé pour valider la reconstitution de l'en-tête. Finalement à l'étape 69 le paquet reconstruit est transmis à l'interface de destination du noeud de sortie.

Claims (1)

1. 23 2002-0151 REVENDICATIONS

   1. Système de compression d'en-tête pour compresser l'en-tête des paquets de données d'une communication transmis entre un n ud d'entrée (10) et un n ud de sortie (12) à travers un réseau de transmission de données (14); caractérisé en ce qu'il comprend: - des moyens de création de gabarit (20, 22, 25 ou 30, 32, 35), dans le n ud d'entrée et le n ud de sortie, adaptés pour créer le même gabarit de compression à partir d'un nombre prédéterminé de paquets de données non compressées au début de ladite communication respectivement transmis par ledit n ud d'entrée et reçus par ledit n ud de sortie, et - des moyens de compression d'en-tête (24) dans ledit n ud d'entrée, adaptés pour compresser l'en-tête de chaque paquet qui suit ledit nombre prédéterminé de paquets de données non compressés avant de le transmettre à travers ledit réseau de transmission de données, la compression étant réalisée en utilisant ledit gabarit de compression.

   2. Système de compression de données selon la revendication 1, dans lequel ledit n ud de sortie (12) comprend des moyens de décompression (34) pour décompresser l'en-tête de chaque paquet reçu après ledit nombre prédéterminé de paquets de données, la décompression étant réalisée en utilisant ledit gabarit de compression.

   3. Système de compression de données selon la revendication 2, dans lequel ledit n ud d'entrée (10) comprend en outre un bloc de gestion d'étiquettes (26) adapté pour fournir une première étiquette ajoutée à l'en-tête de chaque paquet de données parmi le nombre prédéterminé de paquets de données 24 2002-0151 non compressés et une seconde étiquette à ajouter à l'en- tête de chaque paquet de données compressés transmis après ledit nombre prédéterminé de paquets de données non compressés.

   4. Système de compression de données selon la revendication 3, dans lequel ladite première étiquette et ladite seconde étiquette comprennent chacune un bit de compression qui a une valeur prédéterminée (0) dans ladite première étiquette et dans lequel ladite seconde étiquette correspond à ladite première étiquette dans laquelle ledit bit de compression est établi à la valeur complémentaire (1).

   Système de compression de données selon la revendication 4, dans lequel lesdits moyens de création de gabarit comprennent une table de gabarits et d'étiquettes (22 ou 32) contenant les gabarits qui ont été créés, un bloc d'analyse de paquets et de consultation (20 ou 30) pour comparer respectivement l'en-tête de chaque paquet à transmettre par ledit n ud d'entrée (10) ou reçu par ledit n ud de sortie (12) avec les gabarits contenus dans ladite table de gabarits et d'étiquettes et un bloc de création de gabarit (25 ou 35) pour créer un nouveau gabarit lorsqu'il n'y a pas de gabarit pour la communication associée auxdits paquets de données, ledit nouveau gabarit étant mémorisé dans ladite table avec l'étiquette ajoutée auxdits paquets de données.

   6. Système de compression de données selon l'une quelconque des revendications 1 à 5, dans lequel ledit gabarit de compression comprend un masque composé d'autant d'octets que l'en-tête à compresser et dans lequel les bits changeants dudit en-tête sont des bits 1 tandis que les bits constants dudit en-tête sont des bits 0, ledit masque 2002-0151 résultant d'un OU exclusif logique entre les bits correspondants des en- têtes de paquets appartenant audit nombre prédéterminé de paquets.

   7. Procédé de compression pour compresser l'en-tête des paquets de données d'une communication transmise entre un noeud d'entrée (10) et un noeud de sortie (12) à travers un réseau de transmission de données (14), ledit procédé étant caractérisé en ce qu'il 10 consiste à : - créer un même gabarit de compression dans le n ud d'entrée et le noeud de sortie en utilisant un nombre prédéterminé de paquets de données non compressés au début de ladite communication respectivement transmis par ledit noeud d'entrée et reçus par ledit noeud de sortie; et - compresser l'en-tête de chaque paquet qui suit ledit nombre prédéterminé de paquets de données non compressés avant de le transmettre à travers ledit réseau de transmission de données, la compression étant réalisée en utilisant ledit gabarit de compression.

   8. Procédé de compression selon la revendication 7, dans lequel dans ledit noeud d'entrée (10), une étiquette d'un premier type (LABX) est ajoutée à l'en-tête de chaque paquet de données parmi le nombre prédéterminé de paquets de données non compressés et une étiquette d'un second type (LABC) est ajoutée à l'en-tête de chaque paquet de données compressés transmis après ledit nombre prédéterminé de paquets de données.

   9. Procédé de compression selon la revendication 8, dans lequel ladite étiquette d'une premier type (LABX) comprend un bit de compression qui a une valeur prédéterminée (0) et dans lequel ladite étiquette d'un second type (LABC) 26 2002-0151 correspond à ladite première étiquette dans laquelle ledit bit de compression a une valeur complémentaire (1).

   10. Procédé de compression selon la revendication 9, dans lequel une étiquette d'un troisième type (LABU) est ajouté à l'en-tête de chaque paquet de données d'une communication pour laquelle une compression d'entête n'est pas requise.

   11. Procédé de compression selon la revendication 10, comprenant en outre, une étape initiale avant ladite étape de création de gabarit dans ledit noeud d'entrée (10) consistant à déterminer si il y a déjà un gabarit pour la communication à laquelle le paquet de données appartient et à réaliser ladite étape de création de gabarit seulement si il n'y a pas de gabarit existant.

   12. Procédé de compression selon la revendication 11, dans lequel l'étape initiale a déterminé plusieurs gabarits existants pour ladite communication et dans lequel le gabarit ayant le moins de champs indéfinis est choisi parmi lesdits gabarits existants.

   13. Procédé de compression selon la revendication 11, dans lequel ladite étape consistant à créer un gabarit dans ledit noeud d'entrée (10) est utilisée en mode de mise à jour lorsqu'il est déterminé qu'il n'y a pas de gabarit existant pour la communication à laquelle appartient ledit paquet de données mais qu'il y a une communication antérieure ayant les mêmes adresses source et de destination.

   14. Procédé de compression selon la revendication 13, dans lequel ladite étiquette d'un premier type (LABX) à ajouter à l'en-tête de chaque paquet non compressé parmi le nombre 27 2002-0151 prédéterminé de paquets de données est l'étiquette d'un second type (LABC) associée à ladite communication antérieure dans laquelle ledit bit de compression a été mis à ladite valeur prédéterminée (0).

   15. Procédé de compression selon la revendication 14, dans lequel ladite étape de création d'un gabarit de compression est réalisée seulement si l'en-tête du paquet de données reçu comporte une étiquette du premier type (LABX).

   16. Procédé de compression selon la revendication 15, dans lequel une étiquette du second type (LABC) correspondant à ladite étiquette du premier type (LABX) comprise dans l'en-tête dudit paquet de données reçu dans lequel le bit de compression a été mis à ladite valeur complémentaire (1) est mémorisée de façon à être utilisée pour les paquets de données compressées de la même communication reçus plus tard.

   17. Procédé de compression selon la revendication 16, comprenant en outre l'étape de décompression de chaque paquet reçu par ledit noeud de sortie (12) comprenant ladite étiquette d'un second type (LABC).

   18. Procédé de compression selon la revendication 17, dans lequel l'entête de chaque paquet de données comprenant ladite étiquette d'un second type (LABC) est décompressé dans ledit noeud de sortie (12) en utilisant ledit gabarit de compression créé par l'utilisation dudit nombre prédéterminé de paquets de données non compressés.

   19. Procédé de compression selon la revendication 18, dans lequel l'étiquette dudit premier type (LABX) ajoutée à l'en-tête de chaque paquet de données appartenant audit 28 2002-0151 nombre prédéterminé de paquet de données non compressés comprend un numéro de séquence de façon à vérifier dans lesdits n uds de sortie (12) qu'aucun paquet de données n'a été perdu.

   20. Procédé de compression selon l'une des revendications 7 à 19, dans lequel ledit gabarit de compression comprend un masque composé d'autant d'octets que l'en-tête à compresser dans lequel les bits changeants dudit en-tête sont des bits 1 tandis que les bits constants dudit en-tête sont des bits 0, ledit masque résultant d'un OU exclusif logique entre les bits correspondants des en-têtes de paquets appartenant auxdits nombres prédéterminés de paquets.