COMMUNICATION SPATIALE
3. LE SATELLITE COMME SUPPORT D’IP
3.2.1. Étude de l’encapsulation IP
Lorsqu’un datagramme IP doit être acheminé via un système satellite, une entité de niveau 3 doit être présente en bordure du système pour formater et multiplexer le datagramme dans le trafic satellite, le trafic MPEG-2 TS. Cette partie aborde donc les différentes méthodes envisagées par la norme DVB pour encapsuler et ensuite multiplexer des données dans un flux MPEG-2 TS.
Figure 3.1 Cinq méthodes de multiplexage de données dans la couche MPEG-2 TS
La norme DVB prévoit six méthodes d’encapsulation [32]. Parmi elles, la méthode privée laisse l’initiative totale sur le choix d’encapsulation et d’implantation à condition que les datagrammes soient au final encapsulés dans les paquets MPEG-2 TS. Toutefois, ce type de
méthode peut s’inscrire dans une démarche de normalisation seulement si elle est envisagée pour un système global comme par exemple dans le cadre des travaux du groupe IP sur DVB [33]. Une méthode spécifique à un système donné ne présente aucun intérêt si elle n’est pas réutilisable, et contraint le système à rester en marge des autres, sans la possibilité d’une interconnexion directe.
Les cinq autres méthodes proposées par la norme DVB sont illustrées dans la figure ci- dessus (Figure 3.1), et sont détaillées dans les parties suivantes, en insistant sur l’encapsulation recommandée par la norme, la méthode MPE (Multi Protocol Encapsulation).
3.2.1.1.
Le data-piping
Le data-piping est souvent proche de la méthode privée, puisque sa seule contrainte est l’encapsulation des données comme s’il s’agissait de PES. Le reste (découpage, réassemblage…) reste à la discrétion du développeur. Comme l’illustre la figure suivante (Figure 3.2), le data-piping reproduit l’encapsulation des PES dans le flux MPEG-2 TS, et utilise notamment le bourrage vu précédemment. Pour le reste, à savoir l’en-tête, un code correcteur ou encore le réassemblage, la méthode reste de type privé. Cette technique est souvent employée pour l’encapsulation d’IP (les propositions du groupe IP sur DVB sont de ce type [33]). On la considère le plus souvent comme la méthode privée (présentée précédemment), et donc son nom est généralisé à toutes les techniques privées, incluant alors une encapsulation possible sans bourrage.
Figure 3.2 Exemple d’encapsulation d’un datagramme par data-piping
3.2.1.2.
Le data-streaming
Le data-streaming considère les données comme un flux continu, comparable à un flux vidéo ou audio. Ainsi ce flux de données est segmenté en PES et ensuite encapsulé comme tout PES dans les paquets MPEG-2 TS. Cette encapsulation peut être faite de manière synchrone, synchronisée à d’autres PES (en utilisant le PCR) ou asynchrone (ce qui est le cas de données Internet). Ce mécanisme est illustré ci-dessous (Figure 3.3) mais est peu adapté au transport de flux IP, dans la mesure où les datagrammes forment rarement un flux continu de données.
3.2.1.3.
Le data-carousel et l’object-carousel
Le data-carousel et l’object-carousel sont des techniques d’encapsulation et de multiplexage très proches. La couche data-carousel utilise un buffer pour stocker les données à émettre. Ces données sont ensuite vidées cycliquement (peu importe leur type). Cette transmission périodique est utilisée notamment dans la transmission des tables de programmes, les EPG. Le data-carousel utilise les mêmes techniques que MPE pour l’encapsulation (le DSM-CC). Toutefois, les sections utilisées sont de taille fixe.
L’object-carousel est très semblable au data-carousel. Reposant sur le DSM-CC, il est utilisé pour envoyer de manière cyclique des données liées à des services. Ces données peuvent être liées au temps grâce au stream event.
3.2.1.4.
Le Multi Protocol Encapsulation (MPE)
Parmi les différentes méthodes d’encapsulation proposées par le DVB, MPE est celle que la norme retient et recommande pour les flux IP [11] [14]. MPE est la méthode utilisée par MPEG-2 et DVB pour encapsuler les tables de services. Ce protocole s’appuie sur le DSM-CC (Digital Storage Media Command and Control) pour opérer. Cette utilisation est définie dans la partie 6 de la norme MPEG-2 [4] et met en place une connexion client/serveur. MPE utilise cette extension de MPEG-2 pour encapsuler les datagrammes IP en émulant un LAN.
Le datagramme IP, une fois à la gateway, est traité par le niveau IP de celle-ci. Envoyé au niveau MPE, il est alors encapsulé dans une section privée appelée une section datagramme (ou section adressable dans la norme ATSC). La section a une taille variable avec une MTU de 4080 octets. Cette opération est illustrée dans la figure suivante (Figure 3.4). On peut noter que la couche MPE ne fait pas la fragmentation de la donnée, et c’est le niveau réseau qui doit fragmenter le datagramme IP si la taille de ce dernier est supérieure à la MTU d’une section. MPE ajoute un en-tête de 12 octets à chaque fragment de datagramme. Cet en-tête est appelé un pointer- field. Enfin un CRC de 4 octets est apposé à la fin de la section. Il faut toutefois remarquer que l’en-tête peut aussi contenir des champs optionnels et notamment le champ LLC-SNAP conforme à la norme ISO/IEEE pour les LAN/MAN. Cet ajout de 8 octets supplémentaires alourdit certes l’overhead du paquet, mais permet de faire directement du bridge Ethernet, en encapsulant des trames Ethernet. Dans un cadre IP classique, cette option n’est pas nécessaire.
Une fois sous forme de sections, les fragments sont encapsulés et multiplexés dans des paquets MPEG-2 TS. Cela peut être fait avec ou sans bourrage. Le mode sans bourrage est plus couramment nommé l’option section-packing.
L’introduction du pointeur de 1 octet pour renseigner sur le début de la prochaine section utilise le champ PUSI de l’en-tête obligatoire MPE (Figure 3.7). Ce flag, s’il est utilisé en accord avec la norme indique la présence d’un champ optionnel suivant l’en-tête. Nommé adaptation-field, ce champ est composé ici de 4 octets supplémentaires, dont 1 octet (le dernier) est le champ pointeur, indiquant le début de la nouvelle section (Figure 3.5). Toutefois parmi ces quatre octets optionnels, seul le champ pointeur est rigoureusement nécessaire. Ainsi, il est envisageable, en contournant légèrement la norme MPEG-2 TS, d’implanter uniquement l’ajout d’un unique octet, le champ pointeur, et ainsi de changer la signification du champ PUSI. Dans le cadre de cette modification, le flag PUSI indique la présence directe d’un unique pointeur juste après l’en-tête obligatoire MPEG-2 TS. Cette utilisation rend toutefois incompatible le champ PUSI avec un champ d’adaptation classique. Cette solution n’est donc pas totalement conforme à la norme, mais apporte un allégement à l’encapsulation.
Figure 3.5 Insertion du champ pointeur dans le champ d’adaptation MPEG-2 TS
L’encapsulation avec bourrage économise ce pointeur associé au début d’une nouvelle section (et les 3 autres octets de champ optionnel supplémentaire dans le cas d’une implantation rigoureuse). Cependant, le gain peut s’avérer faible s’il est comparé aux octets perdus par le bourrage. Le section-packing propose un rendement équivalent à une encapsulation classique IP sur Ethernet, comme le montre le graphique suivant (Figure 3.6).
En effet si l’on note s la taille du datagramme en octets et TE(s) la taille de la trame
Ethernet en octets encapsulant ce datagramme. Puisque la taille minimale d’une trame Ethernet est de 72 octets, on obtient la formule suivante (1), avec 22 octets d’en-tête et 4 octets de CRC (IEEE 802.3) :
(1) T sE( )=max(72,s+26)
De même lorsqu’il s’agit de la taille MPEG-2 TS générée par le même datagramme de taille s, l’on trouve trois valeurs possibles : TMB qui est la taille avec bourrage (2), TMP la taille avec
section-packing (3), et TMPA la taille avec section-packing réduite à un seul octet supplémentaire (4).
TMB est obtenu en calculant le nombre de paquets MPEG-2 TS requis pour contenir le
datagramme. Comme il y a du bourrage, c’est un nombre entier, donc une partie entière supérieure qui est obtenue. Pour le section-packing, il faut prendre en compte le pointeur, mais seulement une fraction du dernier paquet est utilisée pour la donnée. Il faut noter que ces calculs sont effectués dans un cadre où les données arrivent à un rythme suffisant pour permettre d’éviter le bourrage dans le cadre du section-packing.
(2) TMB( )s =⎡⎢(s+16) 184 .188⎤⎥
(3) TMP( )s =
(
(s+16 4) 184 .188+)
(4) TMPA( )s =
(
(s+16 1) 184 .188+)
On obtient en faisant les rapports TMB sur TE, TMP sur TE et TMPA sur TE la courbe ci-
dessous (Figure 3.6). Cette courbe montre alors les bonnes performances du section-packing avec MPE, permettant d’obtenir un rendement voisin d’une encapsulation Ethernet.
200 400 600 800 1000 1200 1400 0.5 1 1.5 2 2.5 3 avec bourrage section packing section packing amélioré
Taille du datagramme (Octets)
Rapport taille MPE sur taille Ethernet
Figure 3.6 Comparaison des tailles des données une fois encapsulées avec MPE et Ethernet Pour terminer l’étude de MPE, son en-tête, appelé le pointer-field, est décrit ici. Cet en-tête est composé des champs obligatoires suivants (Figure 3.7) [4] [6] :
• Table_Id : ce champ d’un octet prend la valeur 0x3F, désignant ainsi une section datagramme.
• Section_Syntax_Indicator : cet indicateur est fixé à zéro (selon l’annexe A de [11]) • Error_Detection_Type : ce drapeau d’un bit mis à la valeur ‘1’ indique l’utilisation du
checksum, la valeur ‘0’ indiquant l’utilisation d’un CRC_32.
• Reserved : ce champ de 2 bits est fixé à ‘11’ et est réservé à des utilisations futures. • Section_Length : il s’agit de la taille de la section codée sur 12 bits.
• Device_Id : ce champ est composé de 48 bits divisés en 6 parties de 1 octet chacune. Il s’agit de l’adresse du destinataire. C’est une adresse MAC conforme à la norme ISO/IEEE et celle-ci est réordonnée selon la figure (Figure 3.8).
• Payload_Scrambling_Control : ce champ de 2 bits définit le mode de cryptage de la charge utile de la section. La méthode de cryptage utilisée est de type privé.
• Address_Scrambling_Control :ce champ de 2 bits définit le mode de cryptage du device_Id de cette section. La méthode de cryptage utilisée est de type privé.
• LLCSNAP_Flag : cet indicateur de 1 bit, indique s’il est fixé à ‘1’, que la charge utile transporte un datagramme encapsulé avec LLC/SNAP. Cet en-tête optionnel est placé sur 8 octets supplémentaires juste après le deviced_Id [47..40].
• Current_Next_Indicator : ce bit est fixé à ‘1’ pour les sections adressables DSM-CC. • Section_Number : ce champ d’un octet correspond au numéro de la section,
incrémenté de un à chaque nouvelle section d’un même flux.
• Last_Section : ce champ d’un octet correspond au numéro de la dernière section, c’est- à-dire le numéro le plus grand pour une section de cette table.
Figure 3.8 Découpage de l’adresse MAC destination dans les champs Deviced_Id de la section Ces techniques décrites, leur utilisation va être observée, à travers un exemple.