Techniques de résolutions d’adresses et d’encapsulations : ULE

La méthode MPE a différents défauts comme nous l’avons souligné dans la partie 3.2.3.1. Dans ce cadre un certain nombre de solutions propriétaires ont vu le jour utilisant comme base d’encapsulation la méthode du data-piping [41]. IP sur DVB, groupe de travail de l’IETF, œuvre pour la normalisation d’un nouveau protocole reposant sur le data-piping et adapté à la couche MPEG-2 TS / DVB : ULE (Ultra Lightweight Encapsulation) [38].

3.4.1.1.

Les principes de l’encapsulation ULE

Au niveau d’IP, ULE doit permettre d’assurer l’unicast, le broadcast comme le multicast IPv4, l’unicast et le multicast IPv6 ou encore la compression d’en-têtes [45] [46]. Le protocole ULE permet aussi de véhiculer directement d’autres PDUs (Protocol Data unit) comme les trames Ethernet, permettant ainsi la mise en place d’un pont Ethernet via le satellite.

La méthode ULE repose sur l’encapsulation des PDUs dans des SNDUs (SubNetwork Data Unit). Comme pour MPE, la SNDU est encapsulé dans le flux MPEG-2 TS. Ce mécanisme utilise alors l’indicateur PUSI pour renseigner sur la présence d’un début de SNDU dans le paquet. Lorsque le PUSI prend la valeur 1, un pointeur de 1 octet suit l’en-tête MPEG-2 TS, indiquant le début d’une nouvelle SNDU. Si plusieurs SNDU peuvent ainsi se retrouver dans un même paquet MPEG-2 TS, du bourrage peut aussi être utilisé quand il n’y a pas de SNDU

d’origine identique à transmettre c’est-à-dire utilisant le même PID. La figure suivante présente l’encapsulation d’un datagramme unicast IPv4 en utilisant le protocole ULE (Figure 3.14).

Figure 3.14 Encapsulation d’un datagramme unicast IPv4 via la méthode ULE

Cette encapsulation ne semble pas si différente que cela de la méthode MPE à première vue. Comme MPE on trouve un en-tête, un en-tête optionnel et un CRC. Comme MPE, une forme de section packing est utilisé. Toutefois l’en-tête d’une SNDU a un champ obligatoire de 4 octets comparé au pointer-field de 12 octets d’une section datagramme. La solution ULE propose un en-tête moins complexe que la solution MPE, avec une option pour l’adresse MAC destinataire, qui rend l’en-tête beaucoup plus court si celui-ci n’est pas nécessaire.

Figure 3.15 En-tête obligatoire et optionnel utilisé par la solution ULE

La figure ci-dessus (Figure 3.15) propose un aperçu de l’en-tête ULE, montrant ces trois champs obligatoires et quelques champs optionnels utilisables. Les champs obligatoires sont :

• D (Destination Address Present) : ce champ prend la valeur 0 pour indiquer qu’il y a un champ optionnel Receiver Destination Address.

• Length field : codé sur 15 bits, ce champ indique la longueur en octet de la SNDU, comptée à partir du premier bit suivant le champ type, jusqu’au CRC inclus.

• Type field : le champ de type est codé sur 2 octets. Il propose deux types possibles ; les valeurs de 0 à 1535 sont utilisées pour des types réservés du système ULE tandis que les valeurs au dessus de 1536 correspondent au type Ethernet IEEE.

Les champs optionnels sont plus spécifiques, on notera toutefois le champ Receiver Destination Address qui est présent dans le paquet quand D est fixé à 1. Cette adresse est un NPA (Network Point Attachment) qui identifie sur 6 octets le (ou les) récepteurs. Elle est similaire au standard IEEE LAN/MAN et peut être une adresse unicast, multicast ou même une adresse de broadcast (0xFF :FF :FF :FF :FF :FF). Les autres champs optionnels de la SNDU peuvent être utilisés pour faire notamment du pont Ethernet. L’en-tête présenté dans la figure ci-dessus est d’ailleurs un bon exemple d’encapsulation d’une trame Ethernet par la méthode ULE. Comme dans le cadre IP, le champ Receiver Destination Address peut être occulté dans certaines conditions.

Figure 3.16 Deux encapsulations d’un datagramme IP via la méthode ULE

Pour l’encapsulation d’un datagramme IPv4 (Figure 3.16), les champs obligatoires et le champ optionnel Receiver Destination Address sont suffisants, donnant un overhead total de 12 octets contre 16 octets pour MPE. Cependant, si le système est capable de filtrer au niveau PID correctement et a une capacité de filtrage IP suffisante, ce champ optionnel n’est pas obligatoire, donnant un overhead de 8 contre 16 (Figure 3.16).

10 100 1 103 0.2 0.4 0.6 0.8 1

Rapport taille ULE sur taille MPE

3.4.1.2.

Les avantages de la méthode ULE

L’encapsulation ULE semble alors apporter une réduction de complexité et d’overhead comparé à la méthode MPE. Si l’on veut comparer l’encapsulation MPE et ULE, l’équation (4) donne TMPA(s), la taille de données de niveau 2 nécessaires à l’encapsulation d’un datagramme de

s octets. Soit TU(s) cette taille pour une encapsulation via ULE en version la plus légère (5).

(5) ( ) 8 1 .188 184 U s T s = ⎜⎛ + + ⎞_⎟ ⎝ ⎠

On représente le rapport entre TU(s) et TMPA(s) via la figure ci-dessus (Figure 3.17),

donnant un aperçu de l’efficacité de ULE comparée à MPE. On remarque que plus les datagrammes sont de petites tailles, plus le gain entre ULE et MPE est plus important.

Le protocole ULE a fait ainsi l’objet d’une étude approfondie dont le rapport final a été récemment rendu public [47]. Ce rapport conclut sur un gain d’efficacité d’ULE par rapport à MPE, de 10 à 15%, pour des trafics importants. De plus la grande flexibilité d’ULE lui permet d’être adapté à de nouveaux protocoles, sans avoir de modifications fondamentales à apporter, grâce notamment à son champ type et ses options sur mesure.

Aussi les premières implantations réelles de la solution ULE apparaissent (Thales, GCS GmbH, ECC, …) et l’on trouve même des IRDs intégrant cette solution [48].

3.4.1.3.

Les objectifs d’une résolution d’adresse standardisée

En ce qui concerne une méthode de résolution d’adresse complète et uniformisée, aucune solution n’a encore vraiment abouti. En effet pour pouvoir rendre la signalisation des flux privés et notamment IP uniforme, la résolution d’adresse doit proposer une solution capable d’encapsuler les PDUs de manière simple et efficace, de faire le lien entre le canal logique TS et une adresse IP, et de permettre la mise en place de QoS.

Avec ULE, un certain nombre d’objectifs sont atteints : d’une part l’overhead est réduit, et d’autre part la méthode permet d’éviter les champs inutiles via un système d’options facilitant le traitement par les stations et offrant une encapsulation à un grand nombre de protocoles.

Toutefois, l’encapsulation n’est pas suffisante lorsqu’il s’agit de compatibilité, de gestion des flux (gestion du délai, de la gigue…), d’interopérabilité, de facteur d’échelle, etc.… Pour cela, il faut une couche protocolaire complète proposant une interaction totale entre la couche MPEG-2 TS (et donc les canaux logiques) et la couche supérieure, ici IP [49]. Le protocole doit donc :

• être robuste face aux erreurs de liaison et de décodage,

• associer les adresses IP aux canaux logiques, en respectant la technique MPEG-2 (tables SI) ou en utilisant un canal pour des messages de type ARP (Address Resolution Protocol),

• supporter les protocoles IPv4 et IPv6,

• gérer la QoS, le multicast, le broadcast et la compression d’en-tête,

• supporter des protocoles de sécurité tels que IPsec (IP security protocol), • …

Il reste donc encore du travail d’uniformisation avant d’arriver à intégrer ces différents objectifs dans un seul et même niveau protocolaire, ULE n’étant qu’une étape vers une solution plus globale.