Revision as of 16:00, 31 January 2006

Réseaux NBMA

Table des matières

Tunnels

Les liaisons point à point relient de manière fixe deux machines. En général il n'existe donc pas de notion d'adresse MAC, un datagramme est systématiquement envoyé à l'extrémité distante du lien. Pour le cas où l'adresse destination est multicast, le datagramme IPv6 est dupliqué et transmis vers la machine locale aussi bien qu'à la machine distante. Il reste un problème propre à IPv6 à prendre en compte : comme il n'existe pas en général pas d'adresse MAC IEEE 802 ou EUI-64 sur des liens point à point, il n'y a pas de méthode standard pour définir l'adresse IPv6 lien-local d'un interface point à point.

Il existe plusieurs types de liens point à point :

• Le plus simple est un lien physique, par exemple une ligne série. En IPv4 il existe deux protocoles de transport standard sur ligne série, SLIP et PPP. En IPv6 seul PPP a été défini, SLIP étant considéré comme obsolète car ne permettant pas une authentification suffisante. PPP est aussi utilisable pour d'autres lien physiques comme les fibres optiques en utilisant PPP sur SONET/SDH (Synchronous Optic NEtwork et Synchronous Digital Hierarchy, (RFC 2615)).
• Le deuxième type est l'utilisation d'une connexion fixe dans un réseau multipoint, par exemple l'utilisation d'un VC ATM ou X25 pour créer une liaison point à point entre deux machines. Dans ce cas l'encapsulation utilisée pour transporter les datagrammes IPv6 est celle définie pour le réseau multipoint. Le protocole est simplifié car il n'y a pas besoin de déterminer dynamiquement l'adresse destination de la trame.
• Un troisième type est formé des différents tunnels de transport de IP au dessus de IP. Ils seront détaillés plus bas au paragraphe See Tunnels See Tunnels.
• Un dernier type apparaît avec l'utilisation de GPRS (2G ou 3G). Dans ce cas un ensemble de tunnels forme un lien logique entre l'équipement et le routeur de sortie du réseau GPRS.

PPP (RFC 2472)

L'encapsulation est faite dans une trame PPP Data Link Layer . Chaque datagramme IPv6 forme une trame séparée. Le champ protocole de la trame doit être 0x57.

Le protocole de contrôle de PPP pour IPv6 s'appelle IPV6CP. Il permet la configuration, la validation et l'invalidation des modules IPv6 de PPP. Chaque datagramme IPV6CP est transmis dans une trame PPP Data Link Layer de champ protocole 0x8057. Le protocole IPV6CP permet de négocier deux options, la valeur de l'identifiant d'interface et la compression.

Comme il n'existe pas d'adresse MAC IEEE 802 ou EUI-64 pour les interfaces PPP, il n'y a pas de valeur par défaut standard pour l'identifiant d'interface. Comme discuté See Identifiant d'interface, si la machine (ou une autre interface) possède un EUI-64 ou une adresse MAC IEEE 802, on utilise l'identifiant associé. Sinon il faut fournir une valeur unique (non universelle) à partir d'un numéro de série, ou par exemple d'un générateur aléatoire. Dans tous les cas, la négociation d'identifiant d'interface de IPV6CP doit être utilisée pour forcer l'unicité de l'identifiant.

Le MTU est variable car déterminé par la connexion PPP sous-jacente. Il doit être au moins égal à 1 280.

Il faut remarquer que PPP n'a pas de notion d'adresse physique, donc l'option Découverte des voisins du protocole de découverte de voisin n'est pas utilisée. De même, il n'est pas nécessaire de définir un traitement particulier pour les paquets multicast : comme sur tout lien point à point, le multicast IPv6 est supporté sans action particulière.

Une méthode de compression des en-têtes IPv6 du même type que celle utilisée par IPv4 a été proposée. Elle est optionnelle et son utilisation est négociée par IPV6CP.

Suivant le contexte d'utilisation deux mécanismes de compression peuvent être utilisés :

• Pour les réseaux où le taux d'erreur est relativement faible et pour lesquels la bi-directionnalité est garantie, le RFC 2507 définit une méthode de compression qui est une formalisation et une amélioration de la méthode définie par Van Jacobson pour PPP/IPv4/TCP.
• Pour les réseaux de troisième génération, le problème est plus complexe. D'abord le taux d'erreur est plus important, de plus certaines applications pour le multimédia peuvent être mono-directionnelles et utiliser l'encapsulation UDP/RTP. Le groupe de travail ROHC (RObust Header Compression) travaille à la définition d'un protocole pour cet environnement.

Compression Robuste des en-têtes

Dans les réseaux téléphoniques de troisième génération IPv6 a été retenu pour transporter la voix. Un mécanisme de compression robuste peut réduire le temps de transmission et augmenter l'utilisation d'une ressource très convoitée telle que le support de transmission Hertzien. Pour les services interactifs de voix sur IP et les liaisons cellulaires le protocole utilisé est le protocole RTP. La taille de l'en-tête d'un paquet IPv6/UDP/RTP varie de 60 octets à 120 octets, et de 40 octets à 100 octets pour un paquet IPv4/UDP/RTP. La charge utile, compte-tenu de l'algorithme de compression de la voix et des contraintes temps réel, varie entre 15 et 20 octets. La compression d'en-têtes est possible sur différentes couches du modèle ISO/OSI mais c'est au niveau de la couche réseau IP qu'elle est la plus efficace, puisque l'on a connaissance du format des paquets (et de celui des couches supérieures). Mais la compression signifie également réduction de la redondance dans l'information transmise, ce qui est antagoniste avec des transmissions bruitées. Les travaux présentés sont basés sur les résultats de standardisation de l'IETF du groupe ROHC (Robust Header Compression) et en particulier sur le RFC 3095.

Le principe à la base de la compression d'en-têtes est la réduction de la redondance de l'information contenue dans un en-tête, mais aussi de la redondance entre plusieurs en-têtes consécutifs. Ainsi, l'information qui ne change pas est envoyée au début de la session ou à un faible rythme et pour les autres champs, un mécanisme de prédiction ou de dépendance permet de réduire encore l'information transmise.

Le déroulement du protocole ROHC commence par une négociation, permettant au compresseur et au décompresseur de connaître les caractéristiques du lien et le profil à utiliser. Le mécanisme classifie les champs des en-têtes, l'analyse est basée sur le changement des valeurs de ces champs pendant la connexion, la classification se fait suivant cinq types de valeurs différents : INFERRED, STATIC-DEF, STATIC-KNOWN, CHANGING, et STATIC, qui forment les parties statique et dynamique de l'en-tête compressée ROHC.

ROHC maintient un contexte entre le compresseur et le décompresseur. Ce contexte contient une version non compressée du dernier en-tête envoyé et aussi l'information redondante dans le flot de données. Le contexte est gardé à la fois dans le décompresseur et dans le compresseur pour assurer la robustesse, et chaque fois que le compresseur doit envoyer des nouvelles valeurs, le contexte s'actualise. Si le contexte est perdu, il a désynchronisation, et le décompresseur peut éventuellement à travers des acquittements reprendre le contexte. Sinon, le décompresseur doit attendre qu'une temporisation expire au niveau du compresseur pour retrouver le contexte.

Le principe de ROHC est d'envoyer l'information minimale pour que le décompresseur puisse reformer l'en-tête. L'élément clé est le CRC, calculé avant la compression, qui donne au décompresseur une information sur la validité de l'information qu'il possède et qui est susceptible de dériver suite à des erreurs de transmission.

Le mécanisme ROHC utilise des profils, des niveaux de compression, des modes d'opération et des modes de transition. Chaque mode d'opération a trois niveaux de compression, et chaque mode de transition travaille dans le mode d'opération précédent en utilisant les deux premiers niveaux de compression jusqu'à la réception d'un acquittement pour changer de mode, comme le montre la figure Diagramme d'état de ROHC.

Les profils définissent les en-têtes protocolaires qui doivent être compressés dans l'en-tête. Ils permettent au décompresseur de connaître la version d'IP, si le flot utilise RTP ou ESP ou s'il s'agit d'un flot UDP seulement. Actuellement les profils définis sont les suivants, d'autres pourront être ajoutés dans le futur :

• Profil 0 sans compression. Si ce profil est choisi, seul l'identificateur de ROHC est ajouté pour que le décompresseur puisse reconnaître les paquets mais il n'y a pas de compression.
• Profil 1 compression des en-têtes IP/UDP/RTP. Ce profil est le plus générique, il compresse tout l'en-tête depuis IP jusqu'à l'en-tête RTP.
• Profil 2 compression des en-têtes IP/UDP. Ce profil est une variation du profil 1 sauf qu'ici la compression s'arrête au protocole UDP.
• Profil 3 compression des en-têtes IP/ESP. Ce profil compresse le protocole ESP, qui peut aussi être pris en compte comme une variation du profil 1.
• Profil 4 compression des en-têtes IP (RFC 3843). Ce profil ne compresse que les en-têtes du protocole IP (IPv4 et IPv6).
• Profil 7 pour la compression des en-têtes IP/UDP-lite/RTP (RFC 4019).
• Profil 8 pour la compression des en-têtes IP/UDP-lite (RFC 4019).

ROHC a trois niveaux de compression :

• Initialisation et Régénération (IR),
• Premier Niveau (FO),
• Deuxième Niveau (SO).

Chaque niveau de compression dans chaque mode d'opération utilise différents types de paquets (cf. See Différents en-têtes ROHC).

Chaque paquet est envoyé avec une fréquence déterminée par différents facteurs : soit la réception d'un acquittement négatif ou positif, soit un délai dépassé, soit une mise à jour ou soit périodiquement en fonction de la confiance que le compresseur a de la qualité du lien. La taille de chaque paquet varie en fonction du type d'en-tête qui va être compressé, les limites des valeurs sont données dans le See Différents en-têtes ROHC.

Les niveaux de compression permettent de diminuer la taille de l'en-tête basée sur l'information que le compresseur a déjà envoyé. Dans le premier niveau de compression qui s'appelle initialisation et régénération, la taille des en-têtes envoyés varie entre 48 à 130 octets, et pour le deuxième niveau les en-têtes ont une taille comprise entre 3 à 84 octets.

Les modes d'opération permettent d'augmenter la performance du mécanisme car le mécanisme peut aller d'un mode d'opération à l'autre en fonction des caractéristiques de la liaison. Chaque mode d'opération a ses caractéristiques propres, le mode d'opération unidirectionnel et bidirectionnel optimiste sont plus complexes que le mode d'opération bidirectionnel fiable, parce qu'au début ni le compresseur ni le décompresseur n'ont d'information pertinente ni tous les paramètres pour effectuer la compression. Le compresseur change de niveau de compression en réduisant la taille de l'en-tête qu'il envoie, les changements sont faits chaque fois que le décompresseur assure au compresseur qu'il a l'information nécessaire pour reconstruire l'en-tête ou si le niveau de confiance en la liaison est suffisant dans le compresseur.

Le mode d'opération unidirectionnel possède différents algorithmes de contrôle de régénération. Il utilise deux temporisateurs pour effectuer la régénération de l'en-tête complète et un système de confiance (L) qui est basé sur le BER et le comportement des erreurs dans les liaisons. Dans ce mode d'opération, le compresseur contrôle la taille de l'en-tête utilisée, et s'il y a un changement dans l'en-tête il peut revenir à un niveau de compression inférieur pour donner toute l'information nécessaire au décompresseur. Le décompresseur ne peut pas communiquer avec le compresseur, les acquittements ne sont pas envoyés et tout est basé sur les mécanismes de contrôle. C'est le mode d'opération le moins performant mais le protocole assure que les en-têtes sont bien arrivés.

Le mode d'opération bidirectionnel optimiste est très similaire au mode d'opération unidirectionnel mais ici le décompresseur peut envoyer des acquittements pour confirmer les envois. Le mode optimiste n'utilise pas les deux temporisateurs mais il garde le système de confiance (L), les changements de niveaux de compression se font grâce à trois différents acquittements : les acquittements positifs/négatifs font une transition positive/négative d'un seul niveau de compression. Les acquittements statiques font une transition négative au niveau de compression plus bas. Si le compresseur reçoit un paquet qui va actualiser le contexte, le compresseur changera de niveau de compression en envoyant un en-tête plus grand.

Le mode d'opération bidirectionnel fiable travaille uniquement avec les acquittements reçus du décompresseur, chaque fois qu'il reçoit un acquittement positif/négatif le compresseur change de niveau de compression et revient à l'état d'initialisation avec un acquittement statique.

Les modes de transition sont déclenchés par le décompresseur, chaque fois qu'il est capable de travailler avec un nouveau mode d'opération il lance un acquittement avec le nouveau mode d'opération dans lequel il veut travailler. En général tous les modes de transition travaillent avec les deux premiers niveaux de compression du mode d'opération précédent qui peuvent actualiser le contexte. Tous les paquets envoyés pendant la transition contiennent le CRC pour vérifier l'information. Pendant les transitions le compresseur et le décompresseur gardent chacun deux variables de contrôle : Transition et Mode, si la variable transition a la valeur d'attente, la transition ne peut pas être déclenchée. Pour finir la transition, un acquittement avec le numéro de séquence et le mode d'opération doit être reçu par le compresseur, sinon la variable transition reste en attente et le mode d'opération conserve l'ancienne valeur. La seule transition différente est la transition d'Unidirectionnel à Optimiste qui est automatique. Pour faire les transitions au mode d'opération fiable (R), le contexte doit être mis en place. Pour les autres, la transition peut commencer à n'importe quel niveau de compression dans le mode d'opération actuel.

Réseaux NBMA

Table des matières

Tunnels