Liaisons point à point - Revision history

Laurent Toutain: /* Compression Robuste des en-têtes */

2006-09-05T20:55:19Z

‎Compression Robuste des en-têtes

Laurent Toutain: /* Compression Robuste des en-têtes */

2006-09-05T20:54:55Z

‎Compression Robuste des en-têtes

Laurent Toutain: /* Compression Robuste des en-têtes */

2006-09-05T20:53:58Z

‎Compression Robuste des en-têtes

Bruno Deniaud: ;)

2006-02-09T17:43:21Z

;)

Bruno Deniaud: /* Compression Robuste des en-têtes */

2006-02-09T09:25:50Z

‎Compression Robuste des en-têtes

Bruno Deniaud: /* PPP (RFC 2472) */

2006-02-09T09:18:54Z

‎PPP (RFC 2472)

Bruno Stévant at 22:56, 7 February 2006

2006-02-07T22:56:24Z

Bruno Stévant at 23:36, 31 January 2006

2006-01-31T23:36:25Z

Bruno Stévant at 14:00, 31 January 2006

2006-01-31T14:00:33Z

Laurent Toutain: /* Compression Robuste des en-têtes */

2005-11-22T06:58:33Z

‎Compression Robuste des en-têtes

@@ Line 43: / Line 43: @@
 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.
-[[image:Fig7-6.png|thumb|right|500px|Figure 7-6 ''Diagramme d'état de ROHC'']]
+[[image:Fig7-6.png|thumb|right|600px|Figure 7-6 ''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 :

@@ Line 43: / Line 43: @@
 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.
-[[image:Fig7-6.png|thumb|right|400px|Figure 7-6 ''Diagramme d'état de ROHC'']]
+[[image:Fig7-6.png|thumb|right|500px|Figure 7-6 ''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 :

@@ Line 43: / Line 43: @@
 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.
-[[image:CS71.gif]]
+[[image:Fig7-6.png|thumb|right|400px|Figure 7-6 ''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 :

@@ Line 31: / Line 31: @@
 === 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.
+Dans les réseaux téléphoniques de troisième génération IPv6 avait é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.

@@ Line 37: / Line 37: @@
 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.
+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 y 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.

@@ Line 16: / Line 16: @@
 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 <tt>0x8057</tt>. 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 [[Identifiant d'interface|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.
+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é dans le paragraphe [[Identifiant d'interface]], si la machine (ou une autre interface) possède un [[Identifiant d'interface|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.

← Older revision		Revision as of 22:56, 7 February 2006
Line 1:		Line 1:
	{{suivi\|Réseaux NBMA\|Réseaux NBMA\|Tunnels\|Tunnels}}		{{suivi\|Réseaux NBMA\|Réseaux NBMA\|Tunnels\|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.		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.

@@ Line 4: / Line 4: @@
 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 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 liens 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 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 [[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 [[IPv6 dans la téléphonie mobile (UMTS)|GPRS]].

@@ Line 1: / Line 1: @@
 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.
@@ Line 6: / Line 7: @@
 * 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]].
+* 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 [[IPv6 dans la téléphonie mobile (UMTS)|GPRS]].
 == PPP (RFC 2472) ==
@@ Line 14: / Line 15: @@
 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 <tt>0x8057</tt>. 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.
+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 [[Identifiant d'interface|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.
@@ Line 82: / Line 83: @@
 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.