Groupe de travail Réseau	G. Fairhurst, University of Aberdeen	
Request for Comments : 4326	B. Collini-Nocker, University of Salzburg	
Catégorie : Sur la voie de la normalisation		
Traduction Claude Brière de L'Isle	décembre 2005	

Encapsulation légère unidirectionnelle (ULE) pour la transmission de datagrammes IP sur un flux de transport MPEG-2

Statut de ce mémoire
Le présent document spécifie un protocole en cours de normalisation de l’Internet pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de copyright
Copyright (C) The Internet Society (2005).

Résumé
Le flux de transport (TS, Transport Stream) MPEG-2 a été largement accepté non seulement pour fournir des services de télévision numérique, mais aussi comme technologie de sous réseau pour construire des réseaux IP.

Le présent document décrit un mécanisme d'encapsulation légère unidirectionnelle (ULE, Unidirectional Lightweight Encapsulation) pour le transport de datagrammes IPv4 et IPv6 et autres paquets de protocole réseau directement sur le flux de transport ISO MPEG-2 comme données de TS privé. ULE spécifie un format de base d'encapsulation et prend en charge un format d'extension qui permet de porter des informations d'en-tête supplémentaires pour aider le traitement sur le réseau et chez le receveur.
Table des mati鑽es
1. Introduction	2
2. Conventions utilisées dans le document	2
3. Description de la méthode	5
4. Format de SNDU	6
4.1 Champ Adresse de destination absente (D)	6
4.2 Champ Longueur	6
4.3 Indicateur de fin	6
4.4 Champ Type	6
4.5 Champ Adresse de destination de SNDU	7
4.6 CRC d'en-queue de SNDU	8
4.7 Description des formats de SNDU	8
5. En-têtes d'extension	10
5.1 SNDU d'essai	11
5.2 Encapsulation de trame SNDU pontée	12
5.3 En-tête d'extension facultatif Extension-bourrage	14
6. Traitement à l'encapsuleur	14
6.1 Encapsulation de SNDU	14
6.2 Procédure de bourrage et d'empaquetage	15
7. Traitement chez le receveur	16
7.1 État Repos	17
7.2 Traitement d'une SNDU reçue	17
7.3 Autres conditions d'erreur	18
8. Résumé	18
9. Remerciements	18
10. Considérations sur la sécurité	18
11. Considérations relatives à l'IANA	19
11.1 Lignes directrices pour l'IANA	19
12. Références	20
12.1 Références normatives	20
12.2 Références pour information	20
Appendice A. Exemples d'empaquetage de SNDU	22
Appendice B. Encapsulation de SNDU	25
Adresse des auteurs	25
Déclaration de droits de reproduction	25

 	1.	Introduction

Le présent document décrit une encapsulation pour le transport de datagrammes IP, ou autres paquets de couche réseau, sur des flux de transport ISO MPEG-2 [ISO-MPEG2], [RFC4259]. L'encapsulation satisfait aux exigences d'une encapsulation légère définie à la Section 4 de la [RFC4259]. L'en-tête de base fournit l'ensemble requis de champs de protocole. Des en-têtes d'extension peuvent aussi être définis. Cette structure d'en-tête est significativement plus simple à analyser et à traiter [SOOR05] que les autres méthodes actuelles (par exemple, MPE [ETSI-DAT], qui est construite sur la syntaxe de section de tableau DSM-CC [ISO-DSMCC]).

L'encapsulation convient aux services fondés sur MPEG-2 ; par exemple, l'architecture de diffusion vidéo numérique (DVB, Digital Video Broadcast), le système du comité des systèmes de télévision évolués (ATSC, Advanced Television Systems Committee) [ATSC], [ATSC-G], et autres systèmes similaire de transmission fondés sur MPEG-2. De tels systèmes fournissent des normes de couche physique et de liaison unidirectionnelle (simplex). La prise en charge a été définie pour une large gamme de supports physiques (par exemple, la télévision terrestre [ETSI-DVBT], [ATSC-PSIP-TC], la télévision par satellite [ETSI-DVBS], [ATSC-S], et la transmission par câble [ETSI-DVBC], [ATSC-PSIP-TC]). Les liaisons bidirectionnelles (duplex) peuvent aussi être établies en utilisant ces normes (par exemple, DVB définit une gamme de technologies de canaux de retour, incluant l'utilisation de liaisons satellite bidirectionnelles [ETSI-RCS]) et des liaisons à numérotation par modem [RFC3077].

Les unités de données de protocole (PDU, Protocol Data Units), comme les trames Ethernet, les datagrammes IP, ou autres paquets de couche réseau, utilisés pour la transmission sur un multiplex de transport MPEG-2 sont passés à un encapsuleur.  Cela formate chaque PDU en une unité de données de sous réseau (SNDU, SubNetwork Data Unit) en ajoutant un en-tête d'encapsulation et un en-queue de vérification d'intégrité. La SNDU est fragmentée en une série d'un ou plusieurs paquets de flux de transport (TS, Transport Stream) MPEG-2 qui sont envoyés sur un seul canal logique de TS.

La spécification MPEG-2 [ISO-MPEG2] exige que les multiplex TS conformes fournissent des informations spécifiques de programme (PSI, Program Specific Information) pour chaque flux dans le multiplex TS. D'autres normes de transmission fondées sur MPEG-2 peuvent aussi définir des informations de service (SI, Service Information).

Une valeur d'identifiant de format a été enregistrée pour ULE [ULE1]. Ce nombre de 32 bits a une valeur hexadécimale de 0x554C4531. Les flux de transport qui utilisent le tableau de transposition de programme (PMT, Programme Map Table) défini dans la norme ISO 13818-1 [ISO-MPEG2] et qui utilisent le format ULE défini dans le présent document, DEVRAIENT insérer un descripteur de cette valeur dans la boucle de descripteur de PMT ES_info. Les flux ULE peuvent aussi être identifiés par la valeur de type de flux (stream_type) de 0x91 [ATSC-REG] dans un tableau SI/PSI [ISO_MPEG2].

Ces informations peuvent permettre aux receveurs et aux remultiplexeurs [RFC4259] de localiser un flux ULE spécifique (c'est-à-dire, la valeur de PID du canal logique TS qui porte un flux ULE). Les conditions dans lesquelles ces informations sont exigées et le format dans lequel elles sont fournies sort du domaine d'application du présent document. Les questions d'adressage et de transposition pour ULE sur MPEG-2 sont aussi décrites dans la [RFC4947].

 	2.	Conventions utilisées dans le document

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

Les autres termes utilisés dans le présent document sont définis ci-dessous :

Champ d'adaptation : champ d'extension facultatif de longueur variable de la longueur fixée dans l'en-tête de paquet TS, destiné à porter les références d'horloge et des informations de synchronisation ainsi que de bourrage sur un multiplex MPEG-2 [ISO-MPEG2].

Contrôle de champ d'adaptation (AFC, Adaptation Field Control) [ISO-MPEG2] : paire de bits portés dans l'en-tête de paquet TS qui signale la présence du champ d'adaptation et/ou de la charge utile de paquet TS.

Comité des systèmes de télévision évolués (ATSC, Advanced Television Systems Committee) [ATSC] : cadre et ensemble des normes associé pour la transmission de vidéo, audio, et données utilisant la norme ISO MPEG-2.

b : bit. Par exemple, un octet consiste en 8b.

B (Byte) : les groupes d'octets sont représentés dans l'ordre d'octets de l'Internet (gros boutien).

Commande et contrôle de support de mémorisation numérique (DSM-CC, Digital Storage Media Command et Control) [ISO-DSMCC]. Format de transmission des données et informations de contrôle sur une section privée MPEG-2, défini par la norme ISO MPEG-2.

Diffusion vidéo numérique (DVB, Digital Video Broadcast) : cadre et ensemble de normes associé publié par l'Institut européen des normes de télécommunications (ETSI) (par exemple, [ETSI-DVBC], [ETSI-DVBS], [ETSI-DVBT]) pour la transmission de vidéo, audio, et données utilisant la norme [ISO-MPEG2].

Encapsuleur : appareil réseau qui reçoit des PDU et les formate en unités de charge utile (qu'on appelle ici des SNDU) pour les sortir comme un flux de paquets TS.

Indicateur de fin : valeur qui indique au receveur qu'il n'y a plus de SNDU présente dans le paquet TS actuel.

Commande de liaison logique (LLC, Logical Link Control) [ISO-8802-2], [IEEE-802.2]. Protocole de couche liaison défini par la norme IEEE 802, qui suit l'en-tête MAC Ethernet.

Contrôle d'accès au support (MAC, Medium Access Control) [IEEE-802.3]. Protocole de couche liaison défini par la norme IEEE 802.3 (ou par Ethernet v2 [DIX]).

En-tête MAC : en-tête de couche liaison de la norme IEEE 802.3 [IEEE-802.3] ou Ethernet v2 [DIX]. Il consiste en une adresse de destination de 6B, une adresse de source de 6B, et un champ de type de 2B (voir aussi NPA, LLC).

Encapsulation multi protocoles (MPE, Multiprotocol Encapsulation) [ETSI-DAT], [ATSC-DAT], [ATSC-DATG]. Schéma qui encapsule les PDU, formant une section de tableau DSM-CC. Chaque section est envoyée dans une série de paquets TS en utilisant un seul canal logique TS.

MPEG-2 : ensemble de normes spécifiées par le groupe d'experts en images animées (MPEG, Motion Picture Experts Group) et normalisé par l'Organisation Internationale de Normalisation (ISO/CEI 13818-1) [ISO-MPEG2], et l'UIT-T [ITU-H222].

Prochain en-tête (Next-Header) : valeur de type qui indique un en-tête d'extension.

Point de rattachement réseau (NPA, Network Point of Attachment) : dans le présent document, se réfère à une adresse de destination de 6 octets (qui ressemble à une adresse MAC IEEE) au sein du réseau de transmission MPEG-2 qui est utilisé pour identifier les receveurs individuels ou les groupes de receveurs.

Seuil d'empaquetage (Packing Threshold) : durée pendant laquelle un encapsuleur accepte de différer la transmission d'un paquet TS partiellement rempli pour accumuler plus de SNDU, plutôt que d'utiliser le bourrage. Après la période de seuil d'empaquetage, l'encapsuleur utilise le bourrage pour envoyer le paquet TS partiellement rempli.

Bourrage (padding) : méthode qui remplit les octets restants inutilisés dans une charge utile de paquet TS en utilisant le schéma spécifique de 0xFF.

Unité de charge utile (PU, Payload Unit) : séquence d'octets envoyée en utilisant un TS. Les exemples d'unités de charge utile incluent une section de tableau MPEG-2 ou une SNDU ULE.

Unité de données de protocole (PDU, Protocol Data Unit) : des exemples de PDU incluent des trames Ethernet, des datagrammes IPv4 ou IPv6, et d'autres paquets sur le réseau.

Flux élémentaire paqueté (PES, Packetized Elementary Stream) [ISO-MPEG2] : format de charge utile de paquet de TS MPEG-2 généralement utilisé pour des informations vidéo ou audio.

Identifiant de paquet (PID, Packet Identifier) [ISO-MPEG2] : champ de 13 bits porté dans l'en-tête des paquets TS. Il est utilisé pour identifier le canal logique TS auquel appartient un paquet TS [ISO-MPEG2]. Les paquets TS qui font les parties d'une section de tableau, d'un PES, ou autre unité de charge utile doivent tous porter la même valeur de PID. Le PID tout de zéros 0x0000 ainsi que les autres valeurs de PID sont réservés pour des tableaux spécifiques de PSI/SI [ISO-MPEG2]. Les valeurs de PID toutes de uns 0x1FFF indiquent un paquet TS Nul introduit pour conserver un débit binaire constant d'un multiplex TS. Il n'y a pas de relation obligatoire entre les valeurs de PID utilisées pour les canaux logiques TS transmis en utilisant des multiplex TS différents.

Pointeur de charge utile (PP, Payload Pointer) [ISO-MPEG2] : pointeur facultatif d'un octet qui suit directement l'en-tête de paquet TS de quatre octets. Il contient le nombre d'octets qui suivent le pointeur de charge utile, jusqu'au début de la première unité de charge utile (comptée depuis le premier octet du champ Charge utile de paquet TS, et en excluant le champ PP lui-même). La présence du pointeur de charge utile est indiquée par la valeur du bit PUSI dans l'en-tête de paquet TS. Le pointeur de charge utile est présent dans DSM-CC, les sections de tableau, et l'ULE. Il n'est pas présent dans les canaux logiques TS qui utilisent le format de PES.

Section privée : structure syntaxique construite conformément au Tableau 2-30 de [ISO-MPEG2]. La structure peut être utilisée pour identifier des informations privées (c'est-à-dire, non définies par [ISO-MPEG2]) relatives à un ou plusieurs flux élémentaires, ou à un programme MPEG-2 spécifique, ou au flux de transport entier. D'autres organisations de normalisation, par exemple, ETSI, ATSC, ont défini des ensembles de structures de tableau qui utilisent la structure "private_section". Une section privée est transmise comme une séquence de paquets TS utilisant un canal logique TS. Un canal logique TS peut porter des sections provenant de plus d'un ensemble de tableaux.

Informations spécifiques d'un programme (PSI, Program Specific Information) [ISO-MPEG2] : ce sont les tableaux utilisés pour convoyer les informations sur le service porté dans un multiplex TS. Les informations sont portées dans une des quatre sections de tableau spécifiquement identifiées définies par MPEG-2 [ISO-MPEG2]. Voir aussi Tableau de SI.

Indicateur de début d'unité de charge utile (PUSI, Payload_Unit_Start_Indicator) [ISO-MPEG2] : fanion d'un seul bit porté dans l'en-tête de paquet TS. Une valeur de PUSI de zéro indique que le paquet TS ne porte pas le début d'une nouvelle unité de charge utile. Une valeur de PUSI de un indique que le paquet TS porte bien le début d'une nouvelle unité de charge utile. Dans ULE, un bit PUSI réglé à 1 indique aussi la présence d'un pointeur de charge utile (PP, pointeur de charge utile) d'un octet.

Receveur : équipement qui traite le signal provenant d'un multiplex TS et effectue le filtrage et la transmission des PDU encapsulées au service de couche réseau (ou au module de pontage lors du fonctionnement à la couche de liaison).

Tableau d'informations de service [ISO-MPEG2] : dans le présent document, ce terme décrit un tableau défini par une autre organisation de normalisation pour convoyer des informations sur les services portés dans un multiplex TS. Un tableau peut consister en une ou plusieurs sections de tableau ; cependant, toutes les sections d'un tableau d'informations de service particulier doivent être portées sur un seul canal logique TS [ISO-MPEG2].

Unité de données de sous réseau (SNDU, SubNetwork Data Unit) : PDU encapsulée envoyée comme une unité de charge utile MPEG-2.

Section de tableau : unité de charge utile qui porte tout ou partie d'un tableau de SI ou PSI [ISO-MPEG2].

Flux de transport (TS, Transport Stream) [ISO-MPEG2] : méthode de transmission au niveau MPEG-2 en utilisant des paquets TS ; il représente la couche 2 du modèle de référence ISO/OSI. Voir aussi Canal logique TS et Multiplex TS.

En-tête TS : en-tête de 4 octets d'un paquet TS [ISO-MPEG2]. Chaque paquet TS de 188B incorpore un en-tête de 4B avec les champs suivants (ceux qui sont référencés dans le présent document sont marqués avec *) :

Longueur de champ (en bits)	Nom/objet
8b	Schéma de synchronisation égal à 0x47
*1b	Indicateur d'erreur de transport
*1b	Indicateur de début de charge utile (PUSI)
1b	Priorité de transport 
*13b	Identifiant de paquet (PID)
2b	Contrôle de croissance du transport
*2b	Contrôle de champ d'adaptation (AFC)
*4b	Compteur de continuité (CC)
Si le bit PUSI est réglé à 1, il y a un champ supplémentaire à la suite de l'en-tête de paquet TS :
*8b	Pointeur de charge utile (PP)

Canal logique de flux de transport : dans le présent document, ce terme identifie un canal au niveau MPEG-2 [ISO-MPEG2]. Il existe au niveau 2 du modèle de référence ISO/OSI. Tous les paquets envoyés sur un canal logique TS portent la même valeur de PID (cette valeur est unique au sein d'un multiplex TS spécifique). Le terme "flux" est défini dans MPEG-2 [ISO-MPEG2] pour décrire le contenu porté par un canal logique TS spécifique (voir Flux ULE). Certaines valeurs de PID sont réservées (par MPEG-2) pour une signalisation spécifique. D'autres normes (par exemple, ATSC, DVB) réservent aussi des valeurs spécifiques de PID.

Multiplex TS : dans le présent document, ce terme définit un ensemble de canaux logiques TS MPEG-2 envoyés sur une seule connexion de couche inférieure. Cela peut être une liaison physique courante (c'est-à-dire, une transmission à un taux de symboles spécifié, un réglage de FEC, et une fréquence de transmission) ou une encapsulation fournie par une autre couche de protocole (par exemple, Ethernet, ou RTP sur IP). Le même canal logique TS peut être répété sur plus d'un multiplex TS (éventuellement associé à une valeur de PID différente) [RFC4259] ; par exemple, pour redistribuer le même contenu de diffusion groupée à deux cellules de transmission de télévision terrestre.

Paquet TS : unité de longueur fixe de 188B de données envoyée sur un multiplex TS [ISO-MPEG2]. Chaque paquet TS porte un en-tête de 4B, plus une redondance facultative incluant un champ d'adaptation, les détails du chiffrement, et des informations d'horodatage pour synchroniser un ensemble de canaux logiques TS en rapport.

Flux ULE : canal logique TS MPEG-2 qui porte seulement des PDU ULE encapsulées. Les flux ULE peuvent être identifiés par la définition d'un type de flux dans les SI/PSI [ISO-MPEG2].

 	3.	Description de la méthode

Les PDU (paquets IP, trames Ethernet ou paquets provenant d'autres protocoles réseau) sont encapsulés pour former une unité de données de sous réseau (SNDU, SubNetwork Data Unit). La SNDU est transmise sur un réseau de transmission MPEG-2 soit en étant placée dans la charge utile d'un seul paquet TS, soit, si nécessaire, en étant fragmentée en une série de paquets TS. Lorsque il y a un espace suffisant, la méthode permet qu'un seul paquet TS porte plus d'une SNDU (ou d'une partie d'elle) une pratique parfois appelée l'empaquetage (packing). Tous les paquets TS comprenant une SNDU DOIVENT avoir alloué le même PID, et donc font partie du même canal logique TS.

L'encapsulation ULE se limite aux seuls flux privés TS. L'en-tête de chaque paquet TS porte un champ d'un bit Indicateur de début de charge utile (PUSI). Un champ PUSI d'une valeur de 1 indique le début d'au moins une unité de charge utile (SNDU) au sein de la charge utile du paquet. La sémantique du bit PUSI est définie pour les paquets PES et PSI [ISO-MPEG2] ; pour les données privées, son utilisation n'est pas définie dans la norme MPEG-2. Bien que ULE utilise des données privées, l'opération suit celle des paquets PSI. Donc, les valeurs de PUSI suivantes sont définies :
0 : le paquet TS NE contient PAS le début d'une SNDU, mais contient la continuation, ou la fin d'une SNDU ;
1 : le paquet TS contient le début d'une SNDU, et un pointeur de charge utile d'un octet suit le dernier octet de l'en-tête de paquet TS.

Si une unité de charge utile (SNDU) se termine avant la fin d'une charge utile de paquet TS, mais n'est pas destinée à commencer une autre unité de charge utile, une procédure de bourrage remplit le reste de la charge utile du paquet TS avec des octets de valeur 0xFF [ISO-MPEG2].

Un receveur traitant des sections de tableau MPEG-2 qui reçoit une valeur de 0xFF dans le premier octet d'une section de tableau (table_Id) interprète cela comme un bourrage et élimine en silence le reste de la charge utile du paquet TS. La charge utile du prochain paquet TS pour le même canal logique TS va commencer avec un pointeur de charge utile d'une valeur de 0x00, indiquant que la prochaine unité de charge utile suit immédiatement l'en-tête de paquet TS. Le protocole ULE ressemble à cela, mais diffère dans la procédure exacte (voir les sections suivantes).

L'en-tête de paquet TS porte aussi une valeur de deux bits de contrôle d'adaptation de champ (AFC, Adaptation Field Control). Ce champ d'adaptation peut étendre l'en-tête de paquet TS pour porter des informations d'heure et de synchronisation et peut aussi être utilisé pour inclure des octets de bourrage avant une charge utile de paquet TS. Le bourrage du champ d'adaptation N'EST PAS utilisé dans cette méthode d'encapsulation, et les paquets TS provenant d'un encapsuleur ULE DOIVENT être envoyés avec une valeur d'AFC de "01". Pour les canaux logiques TS qui prennent en charge ULE, les receveurs DOIVENT éliminer les paquets TS qui portent d'autres valeurs d'AFC.

 	4.	Format de SNDU

Les PDU sont encapsulées en utilisant ULE pour former une SNDU. (Chaque SNDU est une unité de charge utile MPEG-2.) Le format d'encapsulation à utiliser pour les PDU est illustré ci-dessous :

< ----------------------------- SNDU ----------------------------- >
+-+-------------------------------------------------------+--------+
|D|Longueur| Type | Adresse dest* |           PDU         | CRC-32 |
+-+-------------------------------------------------------+--------+

Figure 1 : Encapsulation de SNDU (*adresse de destination facultative)

Toutes les valeurs de plusieurs octets dans ULE (y compris l'indicateur de longueur/fin (4.2,4.3), de Type (4.4), d'adresse de destination (4.5), et les en-têtes d'extension (5)) sont transmises dans l'ordre des octets du réseau (octet de poids fort en premier). Le bit de plus fort poids de chaque octet est placé dans la position la plus à gauche du champ de 8 bits. L'Appendice A donne des exemples d'usage pour information.

 	4.1	Champ Adresse de destination absente (D)
Le bit de plus fort poids du champ Longueur porte la valeur du champ Adresse de destination absente, le bit D. Une valeur de 0 indique la présence du champ Adresse de destination (voir au paragraphe 4.5). Une valeur de 1 indique l'absence du champ Adresse de destination.

Un Indicateur de fin (4.3) DOIT être envoyé avec le bit D réglé à 1. D'autres SNDU PEUVENT être envoyés avec une valeur de bit D de 0 ou 1. La méthode par défaut DEVRAIT utiliser une valeur de bit D de 0 (voir le paragraphe 4.5).

 	4.2	Champ Longueur
Valeur de 15 bits qui indique la longueur en octets de la SNDU, comptée à partir de l'octet qui suit le champ Type de l'en-tête de SNDU de base (figure 9) jusqu'au CRD inclus. Cette longueur inclut la taille de tous en-têtes d'extension qui peuvent être présents (Section 5). Noter le cas particulier décrit au paragraphe 4.3.

 	4.3	Indicateur de fin
Quand les deux premiers octets qui suivent une SNDU ont la valeur de 0xFFFF, cela note un indicateur de fin (c'est-à-dire, une longueur toute de uns combinée avec une valeur du bit D de 1). Cela indique au receveur qu'aucune autre SNDU n'est présente au sein du paquet TS en cours (voir la Section 6) et qu'aucun champ d'adresse de destination n'est présent. La valeur de 0xFF a une sémantique spécifique dans le tramage MPEG-2, où elle est utilisée pour indiquer la présence d’un bourrage. Cette utilisation ressemble à [ISO-DSMCC].

 	4.4	Champ Type
Le champ Type de 16 bits indique le type de charge utile portée dans une SNDU, ou la présence d'un Prochain en-tête. L'ensemble des valeurs qui peuvent être allouées à ce champ est divisé en deux parties, similaires aux allocations pour Ethernet.

Les EtherTypes étaient à l'origine spécifiés par Xerox dans la spécification Ethernet v2 [DIX]. Après la spécification de IEEE 802.3 [IEEE-802.3], [ISO-8802-2], l'ensemble des EtherTypes inférieurs à 1536 (0x0600) a assumé le rôle d'un indicateur de longueur. Les receveurs Ethernet utilisent cette caractéristique pour discriminer les trames de format LLC. Donc, tout EtherType IEEE < 1536 indique une trame LLC, et la valeur réelle indique la longueur de la trame LLC.
Il y a un cas potentiellement ambigu quand un receveur reçoit une PDU avec deux champs Longueur: Le receveur va devoir valider la longueur réelle et le champ Longueur et s'assurer que des valeurs incohérentes ne sont pas propagées par le réseau. La spécification de deux champs Longueur indépendants n'est donc pas souhaitable. Dans l'en-tête ULE, ceci est évité dans l'en-tête de SNDU en incluant seulement une valeur de longueur, mais ponter les trames LLC réintroduit ce problème (paragraphe 5.2).

Le mode d'identification Ethernet LLC n'est pas exigé dans ULE, car le format de SNDU porte toujours un champ de longueur explicite, et donc la procédure dans ULE est modifiée, comme indiqué ci-dessous :
Le premier ensemble de valeurs du champ Type ULE comprend l'ensemble des valeurs inférieures à 1536 en décimal. Ces valeurs de champ de type sont allouées par l'IANA (voir le paragraphe 4.4.1) et indiquent le prochain en-tête.
Le second ensemble de valeurs de champ de type ULE comprend l'ensemble des valeurs supérieures ou égales à 1536 en décimal. Dans ULE, cette valeur est identique aux codes de type correspondants spécifiés par les allocations de type IEEE/DIX pour Ethernet et enregistrées dans le registre EtherType de l'IANA.

 	4.4.1	Type 1 : champs de type Prochain en-tête
La première partie de l'espace de type correspond aux valeurs de 0 à1535 en décimal. Ces valeurs peuvent être utilisées pour identifier des protocoles spécifiques de la liaison et/ou indiquer la présence d'en-têtes d'extension qui portent des champs de protocole facultatifs supplémentaires (par exemple, un pont d'encapsulation). L'utilisation de ces valeurs est coordonnée par un registre de l'IANA. Les types suivants sont définis dans le présent document :
0x0000 : SNDU d'essai (paragraphe 5.1)
0x0001 : trame pontée (paragraphe 5.2)
0x0100 : extension-bourrage (paragraphe 5.3)

Les valeurs restantes au sein de la première partie de l'espace de type sont réservées pour les valeurs de prochain en-tête allouées par l'IANA.

 	4.4.2	Type 2 : champs de type EtherType compatible
La seconde partie de l'espace de type correspond aux valeurs entre 0x600 (1536 en décimal) et 0xFFFF. Cet ensemble d'allocations de type suit les allocations DIX/IEEE (mais exclut l'utilisation de ce champ comme indicateur de longueur de trame). Toutes les allocations dans cet espace DOIVENT utiliser les valeurs définies pour l'EtherType de l'IANA. Les deux valeurs de type suivantes sont utilisées comme exemples (tirées du registre des EtherTypes de l'IANA) :
0x0800 : charge utile IPv4 (paragraphe 4.7.2)
0x86DD : charge utile IPv6 (paragraphe 4.7.3)

 	4.5	Champ Adresse de destination de SNDU
Le champ Adresse de destination de SNDU est facultatif (voir au paragraphe 4.1). Ce champ DOIT être porté (c'est-à-dire, D=0) par les paquets IP en envoi individuel destinés aux routeurs qui sont envoyés en utilisant des liaisons partagées (c'est-à-dire, où la même liaison connecte plusieurs receveurs). Un envoyeur PEUT omettre ce champ (D=1) pour un paquet IP en envoi individuel et/ou en diffusion groupée livré à des receveurs capables d'utiliser un champ discriminateur (par exemple, l'adresse IPv4/IPv6 de destination, ou une adresse MAC de destination pontée) qui, combiné avec la valeur de PID, pourrait être interprété comme une adresse de niveau liaison.

Quand l'en-tête de SNDU indique la présence d'un champ Adresse de destination de SNDU (c'est-à-dire, D=0) un champ Point de rattachement au réseau (NPA, Network Point of Attachment) suit directement le quatrième octet de l'en-tête de la SNDU. Les adresses de destination de NPA sont des nombres de six octets, normalement exprimés en hexadécimal, et sont utilisées pour identifier le ou les receveurs dans un réseau de transmission MPEG-2 qui devrait traiter une SNDU reçue. La valeur 0x00:00:00:00:00:00 NE DOIT PAS être utilisée comme adresse de destination dans une SNDU. Le bit de moindre poids du premier octet de l'adresse est réglé à 1 pour les trames de diffusion groupée, et les octets restants spécifient l'adresse de diffusion groupée de couche liaison. La valeur spécifique 0xFF:FF:FF:FF:FF:FF est l'adresse de diffusion de liaison, qui indique que cette SNDU est à livrer à tous les receveurs.
Les paquets IPv4 qui portent une adresse de diffusion de sous réseau IPv4 doivent être livrés à tous les systèmes avec le même préfixe réseau. Quand une adresse de destination de SNDU est présente (D=0) la valeur DOIT être réglée à l'adresse de diffusion de liaison du NPA (0xFF:FF:FF:FF:FF:FF).

Quand la PDU est un paquet IP en diffusion groupée et qu'une adresse de destination de SNDU est présente (D=0) l'adresse de destination de groupe IP du paquet en diffusion groupée DOIT être transposée en l'adresse de destination de diffusion groupée de la SNDU (suivant la méthode utilisée pour générer une adresse de destination MAC dans Ethernet). La méthode pour transposer les adresses de diffusion groupée IPv4 est spécifiée dans la [RFC1112]. La méthode pour transposer les adresses de diffusion groupée IPv6 est spécifiée dans la [RFC2464].

 	4.6	CRC d'en-queue de SNDU
Chaque SNDU DOIT porter un champ CRC de 32 bits dans les quatre derniers octets de la SNDU. Cette position facilite le calcul du CRC par le matériel. Le CRC-32 polynomial doit être utilisé. Des exemples où ce polynôme est aussi employé incluent Ethernet, la syntaxe de section DSM-CC [ISO-DSMCC], et AAL5 [ITU-3563]. C'est une valeur de 32 bits calculée conformément au polynôme générateur représenté par 0x104C11DB7 en hexadécimal :

x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+x^0.

L'encapsuleur initialise le registre accumulateur de CRC-32 à la valeur de 0xFFFF FFFF. Il accumule alors une valeur transmise pour le CRC32 qui inclut tous les octets depuis le début de l'en-tête de la SNDU jusqu'à la fin de la SNDU (excluant l'en-queue de 32 bits qui contient le CRC-32) et place cela dans le champ CRC. Dans ULE, les octets sont traités en ordre de position croissante au sein de la SNDU ; l'ordre de traitement des bits N'EST PAS inversé. Cet usage ressemble, avec des différences, à celui de SCTP [RFC3309].
Le receveur effectue une vérification d'intégrité en calculant de façon indépendante la même valeur de CRC et en la comparant à la valeur transmise dans l'en-queue SNDU. Les SNDU qui n'ont pas un CRC valide sont éliminées, causant l'entrée du receveur dans l'état Repos.

Cette description peut convenir pour des mises en œuvre de matériels, mais le présent document n'implique aucune mise en œuvre spécifique. Les mises en œuvre de recherche de tableau fondée sur le logiciel ou assistée par le matériel sont aussi possibles. L'Appendice B donne un exemple d'une PDU encapsulée qui inclut la valeur calculée de CRC-32.
Le principal objet de ce CRC est de protéger la SNDU (en-tête et charge utile) contre des erreurs non détectée de réassemblage et des erreurs introduites par des opérations inattendues de logiciel/matériel alors que la SNDU est en transit à travers le sous réseau MPEG-2 et durant le traitement chez l'encapsuleur et/ou le receveur. Il peut aussi détecter la présence d'erreurs non corrigées de la liaison physique (cependant, celles-ci peuvent aussi être détectées par d'autres moyens, par exemple, voir au paragraphe 7.3).

 	4.7	Description des formats de SNDU
Le format d'une SNDU est déterminé par la combinaison du bit Adresse de destination absente (D) et du champ Type de SNDU. La plus simple encapsulation place une PDU directement dans une charge utile de SNDU. Certaines encapsulations de type 1 peuvent exiger des champs d'en-tête supplémentaires. Ils sont insérés dans la SNDU à la suite de l'adresse de destination de NPA et directement avant la PDU.

Les formats de SNDU suivants sont définis ici :
Indicateur de fin : le receveur devrait passer à l'état Repos (4.7.1).
SNDU IPv4 : la charge utile est un datagramme IPv4 complet (4.7.2).
SNDU IPv6 : la charge utile est un datagramme IPv6 complet (4.7.3).
SNDU d'essai : la charge utile va être éliminée par le receveur (5.1).
SNDU pontée : la charge utile porte une trame MAC pontée (5.2).
D'autres formats pourront être définis par les allocations pertinentes dans les registres de l'IEEE et de l'IANA.

 	4.7.1	Indicateur de fin
Le format de l'indicateur de fin est montré à la Figure 2. Ce format DOIT porter une valeur de bit D de 1.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|            0x7FFF           |                               |
+-+-------------+---------------+                               +
|                                                               |
=   Séquence de zéro ou plus octets de valeur 0xFF remplissant  =
|           le reste de la charge utile du paquet TS            |
+---------------+---------------+---------------+---------------+

Figure 2 : Format d'un indicateur de fin d'ULE

 	4.7.2	Encapsulation de SNDU IPv4
Les datagrammes IPv4 sont directement transportés en utilisant une des deux structures standard de SNDU, dans laquelle la PDU est placée directement dans la charge utile de la SNDU. Les deux encapsulations sont montrées aux Figures 3 et 4. (Noter que dans cette figure, et les suivantes, la charge utile de datagramme IP est de taille variable et est directement suivie par le CRC-32).

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|       Longueur (15 bits)    |         Type = 0x0800         |
+-+-------------+---------------+---------------+---------------+
|    -       Adresse de destination NPA du receveur (6 octets)  |
+                               +---------------+---------------+
|                               |                               |
+---------------+---------------+                               +
|                                                               |
=                          Datagramme IPv4                      =
|                                                               |
+---------------+---------------+---------------+---------------+
|                             (CRC-32)                          |
+---------------+---------------+---------------+---------------+

Figure 3 : Format de SNDU pour un datagramme IPv4 avec filtrage de couche 2 (D=0)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|       Longueur (15 bits)    |         Type = 0x0800         |
+-+-------------+---------------+---------------+---------------+
|                                                               |
=                          Datagramme IPv4                      =
|                                                               |
+---------------+---------------+---------------+---------------+
|                             (CRC-32)                          |
+---------------+---------------+---------------+---------------+

Figure 4 : Format de SNDU pour un datagramme IPv4 avec filtrage de couche 3 (D=1)

 	4.7.3	Encapsulation de SNDU IPv6
Les datagrammes IPv6 sont transportés directement en utilisant une des deux structures standard de SNDU, où la PDU est placée directement dans la charge utile de la SNDU. Les deux encapsulations sont montrées dans les Figures 5 et 6.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|      Longueur (15 bits)     |         Type = 0x86DD         |
+-+-------------+---------------+---------------+---------------+
|            Adresse NPA de destination du receveur (6B)        |
+                               +---------------+---------------+
|                               |                               |
+---------------+---------------+                               +
|                                                               |
=                           Datagramme IPv6                     =
|                                                               |
+---------------+---------------+---------------+---------------+
|                             (CRC-32)                          |
+---------------+---------------+---------------+---------------+

Figure 5 : Format de SNDU pour un datagramme IPv6 avec filtrage de couche 2  (D=0)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|        Longueur (15b)       |         Type = 0x86DD         |
+-+-------------+---------------+---------------+---------------+
|                                                               |
=                           Datagramme IPv6                     =
|                                                               |
+---------------+---------------+---------------+---------------+
|                             (CRC-32)                          |
+---------------+---------------+---------------+---------------+

Figure 6 : Format de SNDU pour un datagramme IPv6 avec filtrage de couche 3 (D=1)

 	5.	En-têtes d'extension

Cette Section décrit un format d'extension pour l'encapsulation ULE. Dans ULE, une valeur du champ Type inférieure à 1536 en décimal indique un en-tête d'extension. Ces valeurs sont allouées à partir d'un registre séparé de l'IANA défini pour ULE.

L'utilisation d'un seul champ Type/Prochain en-tête simplifie le traitement et élimine le besoin de tenir plusieurs registres à l'IANA. Le coût est que chaque en-tête d'extension exige au moins deux octets. C'est justifié, sur la base d'un traitement simplifié et de la tenue d'un simple en-tête léger pour le cas courant où il n'y a pas d'extension.

Un en-tête d'extension ULE est identifié par une valeur de 16 bits dans le champ Type. Ce champ est organisé comme un préfixe de 5 bits zéro, un champ de 3 bits H-LEN, et un champ Type H de 8 bits , comme suit :

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0|H-LEN|    H-Type     |
+---------+-----+---------------+

Figure 7 : Structure du champ ULE Prochain en-tête

L'allocation des valeurs de H-LEN est la suivante :
0 : indique un en-tête d'extension obligatoire
1 :  indique un en-tête d'extension facultatif de longueur 2B (Type seulement)
2 :  indique un en-tête d'extension facultatif de longueur 4B (Type + 2B)
3 :  indique un en-tête d'extension facultatif de longueur 6B (Type + 4B)
4 :  indique un en-tête d'extension facultatif de longueur 8B (Type + 6B)
5 :  indique un en-tête d'extension facultatif de longueur 10B (Type + 8B)
≥ 6 : les valeurs combinées de H-LEN et H-TYPE indiquent l'EtherType d'une PDU qui suit directement ce champ Type.

La valeur H-LEN indique le nombre total d'octets dans un en-tête d'extension facultatif (incluant le champ Type de 2B).

Une valeur H-LEN de zéro indique un en-tête d'extension obligatoire. Chaque en-tête d'extension obligatoire a une longueur pré-définie qui n'est pas communiquée dans le champ H-LEN. Aucune limite supplémentaire n'est fixée à la longueur maximum d'un en-tête d'extension obligatoire. Un en-tête d'extension obligatoire PEUT modifier le format ou le codage de la PDU enclose (par exemple, pour effectuer le chiffrement et/ou la compression).

Le H-Type est un champ d'un octet qui est soit une des 256 extensions d'en-tête obligatoires, soit une des 256 extensions d'en-tête facultatives. L'ensemble des valeurs actuellement permises pour les deux types d'en-têtes d'extension est défini par un registre de l'IANA (Section 15). Les valeurs du registre pour les extensions facultatives sont spécifiées sous la forme H=1 (c'est-à-dire, un nombre décimal dans la gamme 256-511) mais peut être utilisé avec un valeur H-LEN dans la gamme de 1 à 5 (voir l'exemple au paragraphe 5.3).

Deux exemples d'en-têtes d'extension sont la SNDU d'essai et l'utilisation de l'extension bourrage. L'en-tête d'extension obligatoire SNDU d'essai résulte en l'élimination de la PDU entière. L'en-tête d'extension facultatif extension bourrage résulte en ce que l'en-tête d'option suivant (si il en est) sera ignoré (c'est-à-dire, un total de H-LEN mots de 16 bits).

Le format général d'une SNDU avec en-têtes d'extension est :

< --------------------------   SNDU   ------------------------- >
+---+--------------------------------------------------+--------+
|D=0|Longueur| T1 | Adresse NPA | H1 | T2 |    PDU     | CRC-32 |
+---+--------------------------------------------------+--------+
< e-t ULE de base >             <  ext 1  >

Figure 8 : Encapsulation SNDU avec un en-tête d'extension (pour D=0)

Où :
D est le bit ULE D (dans cet exemple D = 0 ; cependant, les adresses NPA peuvent aussi être omises quand on utilise des en-têtes d'extension).
T1 est le champ d'en-tête de base Type. Dans ce cas, il spécifie une valeur de Prochain en-tête.
H1 est un ensemble de champs définis pour le type d'en-tête T1. Il peut avoir zéro, un, ou plusieurs octets d'informations pour un en-tête d'extension ULE spécifique.
T2 est le champ Type du prochain en- tête, ou un EtherType > 1535 B indiquant le type de la PDU portée.

< --------------------------   SNDU   ------------------------- >
+---+---------------------------------------------------+--------+
|D=1|Longueur| T1 | H1 | T2 | H2 | T3 |       PDU       | CRC-32 |
+---+---------------------------------------------------+--------+
< e-t ULE de base >< ext 1  >< ext 2  >

Figure 9 : Encapsulation SNDU avec deux en-têtes d'extension (D=1)

Avec cette méthode, plusieurs en-têtes d'extension PEUVENT être enchaînés en série. La Figure 12 montre une SNDU incluant deux en-têtes d'extension. Dans l'exemple, les valeurs de T1 et T2 sont toutes deux inférieures au décimal 1536. Chacune indique la présence d'un en-tête d'extension, plutôt qu'une PDU suivant directement. T3 a une valeur supérieure à 1535 indiquant l'EtherType de la PDU portée. Bien qu'une SNDU puisse contenir un nombre arbitraire d'en-têtes d'extension consécutifs, il n'est généralement pas prévu que les SNDU portent un grand nombre d'extensions.

 	5.1	SNDU d'essai
Une SNDU d'essai (Figure 10) est un en-tête d'extension obligatoire de Type 1. Cet en-tête doit être l'en-tête d'extension final (ou le seul) spécifié dans la chaîne d'en-tête d'une SNDU. La structure de la portion Données de cette SNDU n'est pas définie par le présent document. Les receveurs PEUVENT enregistrer la réception dans un fichier journal, mais DOIVENT alors éliminer toutes les SNDU d'essai. Le bit D PEUT être établi à 1 dans une SNDU d'essai.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|     Longueur (15 bits)      |         Type = 0x0000         |
+-+-------------+---------------+---------------+---------------+
|                                                               |
=            Données (non transmises par un receveur)           =
|                                                               |
+---------------+---------------+---------------+---------------+
|                             (CRC-32)                          |
+---------------+---------------+---------------+---------------+

Figure 10 : Format de SNDU d'essai

 	5.2	Encapsulation de trame SNDU pontée
Une SNDU pontée est un en-tête d'extension obligatoire de type 1. Elle DOIT être l'en-tête d'extension final (ou le seul) spécifié dans la chaîne d'en-têtes d'une SNDU. La charge utile inclut l'adresse MAC et les champs EtherType [DIX] ou Longueur LLC [ISO-8802-2] ainsi que le contenu d'une trame MAC pontée. La SNDU a le format montré aux Figures 11 et 12.

Quand une adresse NPA est spécifiée (D=0), les receveurs DOIVENT éliminer toutes les SNDU qui portent une adresse de destination de NPA qui NE correspond PAS à leur propre adresse de NPA (ou à une adresse de diffusion/diffusion groupée) ; la charge utile des SNDU restantes est traitée par les règles de pontage qui suivent. Une SNDU sans adresse de NPA (D=1) a pour résultat qu'un receveur effectue le traitement du pontage sur la charge utile de toutes les SNDU reçues.

Un encapsuleur PEUT aussi utiliser ce format d'encapsulation pour communiquer directement les paquets de protocole réseau qui exigent l'encapsulation LLC [IEEE-802.2], [ISO-8802-2]. Pour ce faire, il construit une SNDU avec un en-tête d'extension Bridge contenant l'adresse de destination MAC prévue, l'adresse MAC de source de l'encapsuleur, et la longueur de LLC. La PDU comprend un en-tête LLC suivi par la charge utile requise. L'encapsuleur PEUT choisir de supprimer l'adresse de NPA (voir au paragraphe 4.5).

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|      Longueur (15 bits)     |         Type = 0x0001         |
+-+-------------+---------------+---------------+---------------+
|      Adresse de destination NPA du receveur (6 octets)        |
+                               +---------------+---------------+
|                               |                               |
+---------------+---------------+                               +
|            Adresse MAC de destination (6 octets)              |
+---------------+---------------+---------------+---------------+
|            Adresse MAC de source (6 octets)                   |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |   EtherType/Longueur LLC (2B) |
+---------------+---------------+---------------+---------------+
|                                                               |
=                 (Contenu de la trame MAC pontée)              =
|                                                               |
+---------------+---------------+---------------+---------------+
|                             (CRC-32)                          |
+---------------+---------------+---------------+---------------+

Figure 11 : Format de SNDU pour une charge utile pontée (D=0)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|      Longueur (15 bits)     |         Type = 0x0001         |
+-+-------------+---------------+---------------+---------------+
|             Adresse MAC de destination (6 octets)             |
+                               +---------------+---------------+
|                               |                               |
+---------------+---------------+                               +
|                    Adresse MAC de source (6 octets)           |
+---------------+---------------+---------------+---------------+
| EtherType/Longueur LLC (2B)   |                               |
+---------------+---------------+                               +
|                                                               |
=                 (Contenu de la trame MAC pontée)              =
|                                                               |
+---------------+---------------+---------------+---------------+
|                             (CRC-32)                          |
+---------------+---------------+---------------+---------------+

Figure 12 : Format de SNDU pour une charge utile pontée (D=1)

Le champ EtherType/Longueur LLC d'une trame est défini conformément à la norme IEEE 802.3 [IEEE-802.2] (voir la Section 5).

Dans ce cas particulier, le format d'en-tête d'extension obligatoire peut être interprété comme soit un EtherType [DIX], soit un champ Longueur LLC, spécifié par la norme IEEE 802 [IEEE-802.3] plutôt que comme une valeur allouée dans le registre Prochain en-tête ULE tenu par l'IANA.
Les adresses de MAC dans la trame pontée DEVRAIENT être allouées conformément aux règles spécifiées par l'IEEE et noter des adresses de liaison inconnues, d'envoi individuel, de diffusion, et de diffusion groupée. Ces adresses MAC notent le receveur prévu dans le LAN de destination, et ont donc une fonction différente de celle des adresses de NPA portées dans l'en-tête de SNDU.

Une trame de type supérieur à 1536 pour une trame pontée introduit un champ Longueur de LLC. Le receveur DOIT vérifier cette longueur et éliminer toute trame d'une longueur supérieure à celle permise par la taille de charge utile de la SNDU.
En fonctionnement normal, on s'attend à ce que tout bourrage ajouté à la trame Ethernet DEVRAIT être retiré avant la transmission. Cela exige que l'envoyeur soit informé d'un tel bourrage Ethernet (par exemple, [DIX], [IEEE-802.3]).

Les trames Ethernet reçues chez l'encapsuleur pour transmission ultérieure sur ULE portent un champ de séquence de vérification de trame de réseau de zone locale (LAN-FCS, Local Area Network Frame Check Sequence) (par exemple, CRC-32 pour Ethernet [DIX], [IEEE-802.3]). L'encapsuleur DOIT vérifier la valeur de LAN-FCS de toutes les trames reçues, avant tout traitement. Les trames reçues avec un LAN-FCS invalide DOIVENT être éliminées. Après la vérification, le champ LAN-FCS est ensuite supprimé (c'est-à-dire, il N'EST PAS transmis dans la SNDU pontée). Comme dans les autres trames ULE, l'encapsuleur ajoute un CRC-32 à la SNDU transmise. Chez le receveur, un champ LAN-FCS approprié sera ajouté à la trame pontée avant la transmission à venir sur l'interface Ethernet.
Ce schéma est directement mis en œuvre en utilisant les cartes d'interface réseau existantes et n'introduit pas de perte d'efficacité en calculant/vérifiant deux champs de vérification d'intégrité pour les trames pontées. Cependant, il introduit aussi la possibilité qu'une trame corrompue au sein du traitement effectué chez un encapsuleur et/ou receveur ne soit pas détectée par le ou les receveurs finaux (c'est-à-dire, qu'une telle corruption ne résulterait normalement pas en une LAN-FCS invalide).

 	5.3	En-tête d'extension facultatif Extension-bourrage
L'en-tête d'extension facultatif Extension-bourrage est spécifié par une valeur de type H allouée par l'IANA de 0x100. Comme dans les autres extensions facultatives, la longueur totale de l'extension est indiquée par le champ H-LEN (spécifié en mots de 16 bits). Le champ d'extension est formé d'un groupe de un à cinq champs de 16 bits.
Pour cette option spécifique, seul le dernier mot de 16 bits a une valeur allouée ; l'envoyeur DEVRAIT régler les valeurs restantes à 0x0000. Le dernier champ de 16 bits forme le type de champ Prochain en-tête. Un receveur DOIT interpréter le champ Type, mais DOIT ignorer tous les autres champs de cet en-tête d'extension.

 	6.	Traitement à l'encapsuleur

L'encapsuleur forme les PDU mises en file d'attente de transmission dans les SNDU en ajoutant un en-tête et un en-queue à chaque PDU (Section 4). Il segmente ensuite la SNDU en une série de charges utiles de paquet TS (Figure 13). Celles-ci sont transmises en utilisant un seul canal logique TS sur un multiplex TS. Le multiplex TS peut être traité par un certain nombre de (re)multiplexeurs MPEG-2 avant qu'il soit finalement livré à un receveur [RFC4259].

                +-------+--------------------------------+--------+
                |En-tête|  Unité de données de protocole | CRC-32 |
                |  ULE  |                                |   ULE  |
                +-------+--------------------------------+--------+
               /        /                                 \        \
              /        /                                   \        \
             /        /                                     \        \
  +---------+--------+   +---------+---------+     +---------+---------+
  | En-tête | Charge |...| En-tête |Ch. utile|.....| En-tête |Ch. utile|
  |TS MPEG-2|utile MP|   |TS MPEG-2|  MPEG-2 |     |TS MPEG-2|  MPEG-2 |
  +---------+--------+   +---------+---------+     +---------+---------+

Figure 13 : Encapsulation d'une SNDU dans une série de paquets TS

 	6.1	Encapsulation de SNDU
Quand un encapsuleur n'a pas envoyé précédemment un paquet TS pour un canal logique TS spécifique, ou après une période de repos, il commence à envoyer une SNDU dans le premier paquet TS disponible. Ce premier paquet TS généré DOIT porter une valeur PUSI de 1. Il DOIT aussi porter une valeur de Pointeur de charge utile de zéro, indiquant que la SNDU commence immédiatement après le pointeur de charge utile dans la charge utile du paquet TS.

L'encapsulation DOIT s'assurer que tous les paquets TS établissent le compteur de continuité MPEG-2 porté dans l'en-tête de paquet TS, conformément à [ISO-MPEG2]. Cette valeur DOIT être incrémentée de un (modulo 16) pour chaque paquet TS successif contenant un fragment ou une SNDU complète en utilisant le même canal logique TS.

Un encapsuleur PEUT décider de ne pas envoyer immédiatement une autre SNDU, même si de l'espace est disponible dans un paquet TS partiellement rempli. Cette procédure est appelée Bourrage (Figure 14). L'indicateur de fin informe le receveur qu'il n'y a plus de SNDU dans cette charge utile de paquet TS. L'indicateur de fin est suivi de zéro, un ou plusieurs octets non utilisés jusqu'à la fin de la charge utile du paquet TS. Tous les octets non utilisés DOIVENT être réglés à la valeur de 0xFF, suivant la pratique courante dans MPEG-2 [ISO-DSMCC]. La procédure de bourrage fait un compromis entre diminution de l'efficacité et amélioration de la latence.

                 +-/------------+
                 |  Sous réseau |
                 |     DU 1     |
                 +-/------------+
                        \        \
                         \        \
                          \        \
                +----------+--------+--------+------------+
                |  En-tête | Fin de | 0xFFFF |   Octets   |
                | TS MPEG-2| SNDU 1 |        |non utilisés|
                +----------+--------+--------+------------+
                   PUSI=0            Indicateur
                                     de fin d'ULE

Figure 14 : Paquet TS portant la fin de SNDU 1, suivi par un indicateur de fin

Autrement, quand plus de paquets attendent chez l'encapsuleur, et qu'un paquet TS a suffisamment d'espace restant dans la charge utile, l'encapsuleur peut faire suivre une SNDU précédemment encapsulée d'une autre SNDU en utilisant le prochain octet disponible de la charge utile du paquet TS (voir au paragraphe 6.2). C'est ce qu'on appelle "empaquetage" (Packing) (Figure 15).

              +-/----------------+       +----------------/-+
              |   Sous réseau    |       |   Sous réseau    |
              |      DU 2        |       |      DU 3        |
              +-/----------------+       +----------------/-+
                         \        \     /          /\
                          \        \   /          /  \
                           \        \ /          /    \. . .
        +----------+--------+--------+----------+
        |  En-tête |Pointeur| Fin de | Début de |
        | TS MPEG-2|de ch. u| SNDU 2 | SNDU 3   |
        +----------+--------+--------+----------+
            PUSI=1     |              ^
                       |              |
                       +--------------+

Figure 15 : Paquet TS avec la fin de SNDU 2, suivi par SNDU 3

 	6.2	Procédure de bourrage et d'empaquetage
Cinq actions possibles peuvent se produire quand un encapsuleur a achevé l'encapsulation d'une SNDU :

(i)	Si le paquet TS n'a pas d'espace restant, l'encapsuleur transmet ce paquet TS. Il commence la transmission de la prochaine SNDU dans un nouveau paquet TS. (Les règles standard [ISO-MPEG2] exigent que l'en-tête de ce nouveau paquet TS porte une valeur de PUSI de 1 suivie par une valeur de pointeur de charge utile de 0x00.)

(ii)	Si le paquet TS qui porte la partie finale d'une SNDU a un octet de charge utile non utilisé, l'encapsuleur DOIT placer la valeur 0xFF dans cet octet final et transmettre le paquet TS. Cette règle donne un mécanisme simple pour résoudre le comportement complexe qui peut survenir quand le paquet TS n'a pas de PUSI établi. Envoyer une autre SNDU dans le paquet TS en cours exigerait autrement l'ajout d'un pointeur de charge utile qui consommerait le dernier octet restant de la charge utile du paquet TS. Le comportement suit la pratique similaire des autres types de charge utile MPEG-2 [ISO-DSMCC]. L'encapsuleur DOIT commencer la transmission de la prochaine SNDU dans un nouveau paquet TS. (Les règles standard exigent que l'en-tête de ce nouveau paquet TS porte une valeur de PUSI de 1 suivie par une valeur de pointeur de charge utile de 0x00.)

(iii)	Si le paquet TS qui porte la partie finale d'une SNDU a exactement deux octets de charge utile non utilisés, et si le PUSI n'est pas déjà établi, l'encapsuleur DOIT placer la valeur 0xFFFF dans ces deux octets finaux, fournissant un indicateur de fin (paragraphe 4.3) et transmettre le paquet TS. Cette règle empêche la fragmentation du champ Longueur de la SNDU sur deux paquets TS. L'encapsuleur DOIT commencer la transmission de la prochaine SNDU dans un nouveau paquet TS. (Les règles standard exigent que l'en-tête de ce nouveau paquet TS porte une valeur de PUSI de 1 suivie par une valeur de pointeur de charge utile de 0x00.)

(iv)	Si le paquet TS a plus de deux octets de charge utile non utilisés, l'encapsuleur PEUT transmettre le paquet TS partiellement complet mais DOIT d'abord placer la valeur 0xFF dans tous les octets restants non utilisés (c'est-à-dire, établir un indicateur de fin suivi d'un bourrage). L'encapsuleur DOIT alors commencer la transmission de la prochaine SNDU dans un nouveau paquet TS. (Les règles standard [ISO-MPEG2] exigent que l'en-tête de ce nouveau paquet TS porte une valeur de PUSI de 1 et une valeur de pointeur de charge utile de 0x00.)

(v)	Si au moins deux octets sont disponibles pour des données de SNDU dans la charge utile du paquet TS (c'est-à-dire, trois octets si le PUSI N'ÉTAIT PAS établi précédemment, et deux octets si il était établi précédemment) l'encapsuleur PEUT encapsuler d'autres PDU de la file d'attente, en commençant par la prochaine SNDU dans le prochain octet disponible de la charge utile du paquet TS en cours. Quand l'encapsuleur empaquette d'autres SNDU dans un paquet TS où le PUSI N'A PAS été déjà  établi, le PUSI DOIT être mis à jour (mis à 1) et un pointeur de charge utile de 8 bits DOIT être inséré dans le premier octet qui suit directement l'en-tête de paquet TS. (Cela réduit d'un octet la taille du champ Charge utile du paquet TS qui est disponible pour les données.) La valeur du pointeur de charge utile DOIT être réglée à la position de l'octet qui suit la fin de la première SNDU dans la charge utile du paquet TS. Si aucune autre PDU n'est disponible, un encapsuleur PEUT attendre des PDU supplémentaires pour remplir le paquet TS incomplet. La durée maximum d'attente pour un encapsuleur, appelée le seuil d'empaquetage (Packing Threshold) DOIT être limitée et DEVRAIT être configurable dans l'encapsuleur. Si des PDU supplémentaires suffisantes NE sont PAS reçues pour compléter le paquet TS dans le seuil d'empaquetage, l'encapsuleur DOIT insérer un indicateur de fin (en utilisant la règle iv).

L'utilisation de la méthode de l'empaquetage (v) par un encapsuleur est facultative et peut être déterminée sur la base de la session, du paquet, ou de la SNDU.

Quand une SNDU fait moins que la taille d'une charge utile de paquet TS, un paquet TS peut être formé qui porte une valeur de PUSI de un et aussi un indicateur de fin (en utilisant la règle iv).

 	7.	Traitement chez le receveur

Un receveur se règle sur un multiplex TS spécifique portant un flux ULE et établit un filtre de réception pour accepter tous les paquets TS qui ont un PID spécifique. Ces paquets TS sont associés à un canal logique TS spécifique et sont rassemblés pour former un flux de SNDU. Un seul receveur peut être capable de recevoir plusieurs canaux logiques TS, éventuellement en utilisant une gamme de multiplex TS. Dans chaque cas, le réassemblage DOIT être effectué de façon indépendante pour chaque canal logique TS. Pour effectuer ce réassemblage, le receveur peut utiliser une mémoire tampon pour contenir la SNDU partiellement assemblée, qu'on appelle ici la mémoire tampon de SNDU en cours. D'autres mises en œuvre peuvent choisir d'utiliser d'autres structures de données, mais DOIVENT fournir des opérations équivalentes.

La réception d'un paquet TS avec une valeur de PUSI de 1 indique que le paquet TS contient le début d'une nouvelle SNDU. Elle indique aussi la présence du pointeur de charge utile (indiquant le nombre d'octets jusqu'au début de la première SNDU dans le paquet TS en cours de réassemblage). Il est illégal de recevoir une valeur de pointeur de charge utile supérieure à 181, et cela DOIT causer l'interruption du réassemblage de la SNDU et l'entrée du receveur dans l'état Repos. Cet événement DEVRAIT être enregistré comme erreur de pointeur de charge utile.

Un receveur DOIT prendre en charge l'utilisation des deux méthodes d'empaquetage et de bourrage pour toutes les SNDU reçues et DOIT prendre en charge la réception des SNDU avec ou sans champ Adresse de destination (c'est-à-dire, D=0 et D=1).

 	7.1	État Repos
Après une initialisation ou des erreurs, ou à réception d'un indicateur de fin, le receveur entre dans l'état Repos (Idle). Dans cet état, le receveur élimine tous les paquets TS jusqu'à ce qu'il découvre le début d'une nouvelle SNDU, et il entre alors dans l'état Réassemblage. La Figure 16 présente ces transitions d'état :

                                +-------+
                                | DÉBUT |
                                +---+---+
                                    |
                                    \/
                               +----------+
                               |  État    |
                      +------->|  Repos   |<-------+
      Espace inutilisé|        +----+-----+        |
      insuffisant     |             | PUSI établi  | Erreurs de TS MPEG-2
         ou           |             \/             | ou
     Indicateur de fin|        +------------+      | erreur de SNDU
                      |        |   État     |      |
                      +--------|Réassemblage|------+
                               +------------+

Figure 16 : Transitions d'état du receveur

 	7.1.1	Vérification du pointeur de charge utile en état repos
Un receveur dans l'état Repos DOIT vérifier la valeur de PUSI dans l'en-tête de tous les paquets TS reçus. Une valeur de PUSI de 1 indique la présence d'un pointeur de charge utile. À la suite d'une perte de synchronisation, les valeurs entre 0 et 181 sont permises, auquel cas le receveur DOIT éliminer le nombre d'octets indiqué par le pointeur de charge utile (compté à partir du premier octet du champ Charge utile du paquet TS, et en excluant le champ PP lui-même) avant de quitter l'état Repos. Il entre alors dans l'état Réassemblage, et commence le réassemblage d'une nouvelle SNDU à ce point.

 	7.2	Traitement d'une SNDU reçue
Quand il est dans l'état Réassemblage, le receveur lit un champ Longueur SNDU de deux octets dans la charge utile du paquet TS. Si sa valeur est inférieure ou égale à 4, ou égale à 0xFFFF, le receveur élimine la SNDU en cours et le reste de la charge utile du paquet TS et retourne à l'état Repos. La réception d'un champ Longueur invalide est un événement d'erreur qui DEVRAIT être enregistré comme erreur de longueur de SNDU.

Si la longueur de la SNDU en cours est supérieure à 4, le receveur accepte les octets provenant de la charge utile du paquet TS dans la mémoire tampon de la SNDU en cours jusqu'à ce que, soit le total des octets de Longueur soient reçus, soit que la fin du paquet TS soit atteinte (voir aussi au paragraphe 7.2.1). Quand la longueur de la SNDU en cours est égale à la valeur du champ Longueur, le receveur DOIT calculer et vérifier la valeur du CRC (voir le paragraphe 4.6). Les SNDU qui contiennent une valeur de CRC invalide DOIVENT être éliminées. La discordance du CRC est un événement d'erreur et DEVRAIT être enregistré comme erreur de CRC. Le traitement de la couche physique sous-jacente (par exemple, le codage de correction d'erreur de transmission) résulte souvent en des schémas d'erreurs, plutôt qu'en de simples erreurs de bits, de sorte que le receveur a besoin d'être robuste à des schémas arbitraires de corruption du paquet  et de la charge utile TS, incluant de potentielles corruptions des champs de PUSI, PP, et Longueur SNDU. Donc, un receveur DEVRAIT éliminer le reste de la charge utile du paquet TS (si il en est) qui suit une discordance de CRC et retourner à l'état Repos.

Quand l'adresse de destination est présente (D=0) le receveur accepte les SNDU qui correspondent à une d'un ensemble d'adresses spécifiées par le receveur (cela inclut les adresses de NPA du receveur, l'adresse de diffusion de NPA, et toutes les adresses de diffusion groupée de NPA requises). Le receveur DOIT éliminer en silence une SNDU avec une adresse qui ne correspond pas.

Après la réception d'une SNDU valide, le receveur DOIT vérifier le champ Type (et traiter tous les en-têtes d'extension de type 1). La charge utile de la SNDU est alors passée à la prochaine couche de protocole spécifiée. Une SNDU avec une valeur de type inconnue supérieure à 1536 DOIT être éliminée. Cet événement d'erreur DEVRAIT être enregistré comme erreur de type de SNDU.

Le receveur commence alors le réassemblage de la nouvelle SNDU. Elle PEUT suivre directement la SNDU précédemment réassemblée au sein de la charge utile du paquet TS.

(i)	Si la SNDU en cours se termine à la fin de la charge utile d’un paquet TS, le receveur DOIT passer à l'état Repos.

(ii)	Si il reste seulement un octet non traité dans la charge utile du paquet TS après l'achèvement de la SNDU en cours, le receveur DOIT éliminer cet octet final de la charge utile du paquet TS. Il entre ensuite dans l'état Repos. Il NE DOIT PAS enregistrer une erreur quand la valeur de l'octet restant est identique à 0xFF.

(iii)	Si deux octets ou plus de données de charge utile de paquet TS restent après l'achèvement de la SNDU en cours, le receveur accepte les deux prochains octets et examine si c'est un indicateur de fin. Quand un indicateur de fin est reçu, un receveur DOIT éliminer en silence le reste de la charge utile du paquet TS et passer à l'état Repos. Autrement, c'est le début de la prochaine SNDU empaquetée, et le receveur continue par le traitement de cette SNDU. (Ceci pourvu que le paquet TS ait une valeur de PUSI de 1, voir au paragraphe 7.2.1 ; autrement, le receveur a détecté une erreur de délimitation et DOIT éliminer tous les octets restants dans la charge utile du paquet TS et passer à l'état Repos.)

 	7.2.1	Vérification du pointeur de réassemblage de charge utile
Un receveur qui a partiellement reçu une SNDU (dans la mémoire tampon de SNDU en cours) DOIT vérifier la valeur du PUSI dans l'en-tête de tous les paquets TS suivants avec le même PID (c'est-à-dire, le même canal logique TS). Si il reçoit un paquet TS avec une valeur de PUSI de 1, il DOIT alors vérifier le pointeur de charge utile. Si le pointeur de charge utile N'EST PAS égal au nombre d'octets restants pour compléter la SNDU en cours (c'est-à-dire, la différence entre le champ Longueur de SNDU et le nombre d'octets réassemblés) le receveur a détecté une erreur de délimitation.

À la suite d'une erreur de délimitation, le receveur DOIT éliminer la SNDU partiellement assemblée (dans la mémoire tampon de SNDU en cours) et DEVRAIT enregistrer une erreur de réassemblage. Il DOIT alors retourner à l'état Repos.

 	7.3	Autres conditions d'erreur
Le receveur DEVRAIT vérifier l'indicateur d'erreur de transport MPEG-2 porté dans l'en-tête de paquet TS [ISO-MPEG2].  Ce fanion indique une erreur de transmission pour un canal logique TS. Si le fanion est réglé à un, un événement d'erreur de transmission DEVRAIT être enregistré. Toute SNDU reçue partiellement DOIT être éliminée. Le receveur passe alors à l'état Repos.

Le receveur DOIT vérifier le compteur de continuité MPEG-2 porté dans l'en-tête de paquet TS [ISO-MPEG2]. Si deux paquets successifs (ou plus) au sein du même canal logique TS portent la même valeur de compteur de continuité, les paquets dupliqués DOIVENT être éliminés en silence. Si la valeur reçue N'EST PAS identique à celle du paquet TS précédent, et si elle NE S'INCRÉMENTE PAS de un (modulo 16) pour les paquets TS successifs, le receveur a détecté une erreur de continuité. Toute SNDU partielle reçue DOIT être éliminée. Un événement d'erreur de compteur de continuité DEVRAIT être enregistrée. Le receveur passe alors à l'état Repos.

Noter qu'il est permis à un réseau de transmission MPEG2-2 de porter des paquets TS dupliqués [ISO-MPEG2], qui sont normalement détectés par le compteur de continuité MPEG-2. Un receveur qui n'effectue pas les vérifications de compteur de continuité ci-dessus va accepter des copies dupliquées de paquets TS à la procédure de réassemblage. Dans la plupart des cas, la vérification d'intégrité de SNDU par le CRC-32 va résulter en l'élimination de ces SNDU, conduisant à des pertes inattendues de PDU ; cependant, dans certains cas, des PDU dupliquées (tenant dans un paquet TS) pourraient passer indétectées à la prochaine couche de protocole.

 	8.	Résumé

Le présent document définit une encapsulation légère unidirectionnelle (ULE, Unidirectional Lightweight Encapsulation) qui effectue une prise en charge efficace et souple pour les services réseau IPv4 et IPv6 sur les réseaux construits sur le flux de transport (TS, Transport Stream) MPEG-2. L'encapsulation convient aussi pour le transport d'autres paquets de protocole et de trames Ethernet pontées.

ULE fournit aussi un format d'en-tête d'extension et définit un registre IANA associé pour une prise en charge efficace et souple des en-têtes SNDU obligatoires ainsi que facultatives. Cela permet une future extension du protocole, tout en assurant la rétro compatibilité avec les mises en œuvre existantes. En particulier, les en-têtes d'extension facultatifs peuvent être ignorés en toute sécurité par les receveurs qui ne les mettent pas en œuvre, ou choisissent de ne pas les traiter.

 	9.	Remerciements

Le présent document se fonde sur un document précédent dont les auteurs sont Horst D. Clausen, Bernhard Collini-Nocker, Hilmar Linder, et Gorry Fairhurst. Les auteurs souhaitent remercier les membres de la liste de diffusion ip-dvb de leurs contributions ; en particulier, des nombreux commentaires reçues de Art Allison, Carstsen Borman, Patrick Cipiere, Wolgang Fritsche, Hilmar Linder, Alain Ritoux, et William Stanislaus. Alain a aussi fourni les exemples originaux d'utilisation.

 	10.	Considérations sur la sécurité

Les considérations sur la sécurité pour ULE ressemblent à celles qui se produisent quand est utilisée l'encapsulation multi protocoles (MPE) existante. ULE n'ajoute pas de nouvelles menaces spécifiques qui impacteraient la sécurité de l'Internet.

Il y a un problème de sécurité connu avec les octets de bourrage non initialisés. Dans ULE, ces octets sont réglés à 0xFF (pratique normale dans MPEG-2).

Il y a des problèmes connus d'intégrité avec la suppression de la FCS de LAN dans un environnement de réseautage ponté. La suppression de trames pontées expose le trafic à une corruption potentiellement indétectée lorsque il est traité par l'encapsuleur et/ou le receveur.

Il y a un problème potentiel de sécurité quand un receveur reçoit une PDU avec deux champs de longueur : le receveur va devoir valider la longueur réelle et le champ Longueur et s'assurer que des valeurs incohérentes ne sont pas propagées par le réseau. Dans l'encapsulation directe de IPv4/IPv6 dans ULE, ceci est évité en incluant seulement un champ Longueur de SNDU. Cependant, ce problème se pose quand même dans les trames LLC pontées, et les trames avec une longueur LLC supérieure à la taille de charge utile de SNDU DOIVENT être éliminées, et une erreur de longueur de charge utile de SNDU DEVRAIT être enregistrée.

À l'avenir, un en-tête d'extension obligatoire ULE pourra être utilisé pour définir une méthode pour effectuer un chiffrement de liaison de la charge utile de SNDU. C'est un mécanisme de sécurité supplémentaire pour la sécurité de la couche IP, transport, ou application, et non un remplacement [RFC4259]. L'approche est générique et découple l'encapsulation de futures extensions de sécurité. L'opération fournit des fonctions qui ressemblent à celles actuellement utilisées avec l'encapsulation MPE.

Des champs de contrôle de sécurité supplémentaires pourront être fournis au titre de cet en-tête d'extension de chiffrement de liaison, par exemple, pour associer une SNDU avec un des paramètres d'un ensemble d'associations de sécurité. Comme partie du processus de chiffrement, il peut aussi être souhaitable d'authentifier certains en-têtes de SNDU, ou tous. La méthode de chiffrement et la façon dont les clés sont échangées sort du domaine d'application de la présente spécification, comme le sont la définition du format de l'association de sécurité et celui des clés de chiffrement qui s'y rapportent.

 	11.	Considérations relatives à l'IANA

L'IANA a créé le registre de type de champ de prochain en-tête ULE, comme défini dans le présent document.

Registre Prochain en-tête ULE 
Ce registre alloue les valeurs de Prochain en-tête dans la gamme de 0 à 511 (décimal). Pour chaque valeur allouée, il spécifie aussi l'ensemble des valeurs permises de H-LEN (voir la Section 5). Combinées, cela définit un ensemble de valeurs permises dans la gamme de 0 à 1535 pour la première partie de l'espace de type ULE (voir le paragraphe 4.4.1).

 	11.1	Lignes directrices pour l'IANA
Les lignes directrices suivantes sont fournies à l'IANA pour la gestion du registre Prochain en-tête ULE. Ce registre alloue les valeurs 0 à 511 en décimal (0x0000 à 0x01FF, en hexadécimal). Il NE DOIT PAS allouer des valeurs supérieures à 0x01FF (hexadécimal).

Le registre Prochain en-tête se divise comme suit :

1)	Les valeurs allouées par l'IANA de 0 à 255 (décimal) indiquant les en-têtes d'extension (ou les champs de type dépendants de la liaison) obligatoires pour ULE, exigent une revue par expert impliquant la production préalable d'une RFC de l'IETF. Cette spécification DOIT définir la valeur et le nom associé à l'en-tête d'extension, ainsi que la procédure pour traiter l'en-tête d'extension. Elle DOIT aussi définir le besoin de l'extension obligatoire et l'utilisation prévue. La taille de l'en-tête d'extension DOIT être spécifiée.

Des allocations ont été faites dans le présent document, et enregistrées par l'IANA :

Type	Nom	Référence
0	SNDU d'essai	paragraphe 5.1
1	SNDU  pontée	paragraphe 5.2

2)	Les valeurs allouées par l'IANA de 256 à 511 (décimal) indiquant des en-têtes d'extension facultatives pour ULE, exigent une revue d'expert impliquant la production préalable d'une RFC de l'IETF. Cette spécification DOIT définir la valeur et le nom associé à l'en-tête d'extension, ainsi que la procédure pour traiter l'en-tête d'extension. L'entrée DOIT spécifier la gamme des valeurs de H-LEN permises (dans la gamme 1 à 5). Elle DOIT aussi définir le besoin de l'extension facultative et l'utilisation prévue.

Des allocations ont été faites dans le présent document, et enregistrées par l'IANA :

Type	Nom	H-LEN	Référence
256	Extension-bourrage	1-5	paragraphe 5.3

 	12.	Références
 	12.1	Références normatives

[ISO-MPEG2]	International Standards Organisation (ISO), norme internationale 13818-1, "Technologie de l'information -- codage générique pour images animées et informations audio associées -- Partie 1: Systèmes", 2000.

[RFC1112]	S. Deering, "Extensions d'hôte pour diffusion groupée sur IP", STD 5, août 1989. (Mise à jour par la RFC2236)

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC2464]	M. Crawford, "Transmission de paquets IPv6 sur réseaux Ethernet", décembre 1998. (P.S. ; MàJ par RFC8064)

[ULE1]	SMPTE Registration Authority, LLC, "Registration for format_identifier ULE1", http://www.smpte-ra.org/ule1.html. 

 	12.2	Références pour information

[ATSC]	A/53, "ATSC Digital Television Standard", Advanced Television Systems Committee (ATSC), Doc. A/53 Rev.C, 2004

[ATSC-DAT]	A/90, "ATSC Data Broadcast Standard", Advanced Television Systems Committee (ATSC), Doc. A/090, 2000.

[ATSC-DATG]	A/91, "Recommended Practice: Implementation Guidelines for the ATSC Data Broadcast Standard", Advanced Television Systems Committee (ATSC), Doc. A/91, 2001.

[ATSC-G]	A/54, "Guide to the use of the ATSC Digital Television Standard", Advanced Television Systems Committee (ATSC), Doc. A/54, 1995.

[ATSC-PSIP-TC]	A/65B, "Program et System Information Protocol for Terrestrial Broadcast et Cable", Advanced Television Systems Committee (ATSC), Doc. A/65B, 2003.

[ATSC-REG]	ATSC "Code Point Registry" www.atsc.org/standards/Code_Point_Registry.pdf. 

[ATSC-S]	A/80, "Modulation et Coding Requirements for Digital TV (DTV) Applications over Satellite", Advanced Television Systems Committee (ATSC), Doc. A/80, 1999.

[DIX]	Digital Equipment Corp, Intel Corp, Xerox Corp, "Ethernet Local Area Network Specification" Version 2.0, November 1982.

[ETSI-DAT]	EN 301 192, "Specifications for Data Broadcasting", European Telecommunications Standards Institute (ETSI), 2004.

[ETSI-DVBC]	EN 300 800, "Digital Video Broadcasting (DVB); DVB interaction channel for Cable TV distribution systems (CATV)", European Telecommunications Standards Institute (ETSI), 1998.

[ETSI-DVBS]	EN 300 421, "Digital Video Broadcasting (DVB); Modulation et Coding for DBS satellite systems at 11/12 GHz", European Telecommunications Standards Institute (ETSI), 1997.

[ETSI-DVBT]	EN 300 744, "Digital Video Broadcasting (DVB); Framing structure, channel coding et modulation for digital terrestrial television (DVB-T)", European Telecommunications Standards Institute (ETSI), 2004.

[ETSI-RCS]	ETSI 301 790, "Digital Video Broadcasting (DVB); Interaction Channel for Satellite Distribution Systems", European Telecommunications Standards Institute (ETSI), 2005.

[IEEE-802.2]	IEEE 802.2, "Local et metropolitan area networks- Specific requirements Part 2: Logical Link Control", IEEE Computer Society, (aussi ISO/CEI 8802-2), 1998.

[IEEE-802.3]	IEEE 802.3, "Local et metropolitan area networks- Specific requirements Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method et physical layer specifications", IEEE Computer Society, (aussi ISO/CEI 8802-3), 2002.

[ISO-DSMCC]	International Standards Organisation (ISO), IS 13818-6, "Technologies de l'information - Codage générique des images animées et des informations audio associées -- Partie 6 : extensions pour DSM-CC", 1998.

[ITU-H222]	Recommandation UIT-T H.222.0, "Technologies de l'information - Codage générique des images animées et des informations audio associées : systèmes", 1995.

[ITU-3563]	Recommandation UIT-T I.363.5, "Spécification de la couche d'adaptation ATM en RNIS-LB : Type 5 AAL", 1996.

[ISO-8802-2]	International Standards Organisation (ISO), "Contrôle de liaison logique", ISO/CEI 8802.2, 1998.

[RFC3077]	E. Duros et autres, "Mécanisme de tunnelage de couche Liaison pour liaisons unidirectionnelles", mars 2001. (P.S.)

[RFC3309]	J. Stone, R. Stewart, D. Otis, "Changement de somme de contrôle du protocole de transmission de commandes de flux (SCTP)". septembre 2002. (Obsolète, voir RFC4960) (P.S.)

[RFC4259]	M.-J. Montpetit et autres, "Cadre pour la transmission de datagrammes IP sur les réseaux MPEG-2", novembre 2005. (Information)

[RFC4947]	G. Fairhurst, M. Montpetit, "Mécanismes de résolution d'adresse pour datagrammes IP sur réseaux MPEG-2", juillet  2007. (Information)

[SOOR05]	M. Sooriyabandara, G. Fairhurst, A. Ang, B. Collini-Nocker, H. Linder, W. Stering, "A Lightweight Encapsulation Protocol for IP over MPEG-2 Networks: Design, Implementation et Analysis", Computer Networks 48 p5-19, 2005.

 	Appendice A.	Exemples d'empaquetage de SNDU

Cet appendice fournit des exemples d'utilisation. Il est pour information. Il ne fournit pas de description du protocole. Les exemples fournissent la séquence complète de paquet TS pour un échantillon de paquets IP encapsulés.

La spécification du fonctionnement de l'en-tête de paquet TS et les valeurs des champs sont fournies dans [ISO-MPEG2]. La spécification de ULE est fournie dans le corps du présent document.

Les clés ci-dessous sont fournies pour les exemples qui suivent :
HDR	en-tête de paquet TS de quatre octets
PUSI	indicateur de début d'unité de charge utile
PP	pointeur de charge utile
***	pointeur de charge utile de paquet TS (PP)

Exemple A.1 : deux PDU de 186 octets

SNDU A fait 200 octets (incluant l'adresse NPA de destination ULE)
SNDU B fait 200 octets (incluant l'adresse NPA de destination ULE)

La séquence comporte 3 paquets TS :

           PP=0      Longueur SNDU
   +-----+------+------+------+-   -+------+
   | HDR | 0x00 | 0x00 | 0xC4 | ... | A182 |
   +-----+----*-+-*----+------+-   -+------+
   PUSI=1     *   *
              *****
           PP=17           CRC pour A     Longueur SNDU
   +-----+------+------+-   -+--- --+------+------+-   -+------+
   | HDR | 0x11 | A183 | ... | A199 | 0x00 | 0xC4 | ... | B165 |
   +-----+----*-+------+-   -+------+-*----+------+-   -+------+
   PUSI=1     *                       *
              *************************

                   CRC pour A Indicateur      Octet
                               de fin        de bourrage
   +-----+------+-   -+------+----+----+-   -+----+
   | HDR | B166 | ... | B199 |0xFF|0xFF| ... |0xFF|
   +-----+------+-   -+------+----+----+-   -+----+
   PUSI=0

Exemple A.2 : usage du dernier octet dans un paquet TS

SNDU A fait 183 octets
SNDU B fait 182 octets
SNDU C fait 181 octets
SNDU D fait 185 octets
La séquence comporte 4 paquets TS :

                      Longueur
            PP=0      SNDU       CRC pour A
    +-----+------+------+------+-   -+------+
    | HDR | 0x00 | 0x00 | 0xB3 | ... | A182 |
    +-----+----*-+-*----+------+-   -+------+
    PUSI=1     *   *
               *****
                      Longueur         CRC    Octet
            PP=0       SNDU          pour B  non utilisé
    +-----+------+------+------+-   -+------+------+
    | HDR | 0x00 | 0x00 | 0xB2 | ... | B181 | 0xFF |
    +-----+---*--+-*----+------+-   -+------+------+
    PUSI=1    *    *
              ******
                      Longueur                    Longueur
            PP=0       SNDU       CRC pour C       SNDU 
    +-----+------+------+------+-   -+------+------+------+
    | HDR | 0x00 | 0x00 | 0xB1 | ... | C180 | 0x00 | 0x65 |
    +-----+---*--+-*----+------+-   -+------+------+------+
    PUSI=1    *    *
              ******           Octet
                              non utilisé
    +-----+------+-   -+------+------+
    | HDR | D002 | ... | D184 | 0xFF |
    +-----+------+-   -+------+------+
     PUSI=0

Exemple A.3 : grandes SNDU

SNDU A fait 732 octets
SNDU B fait 284 octets
La séquence comporte 6 paquets TS :

                      Longueur
            PP=0       SNDU
    +-----+------+------+------+-   -+------+
    | HDR | 0x00 | 0x02 | 0xD8 | ... | A182 |
    +-----+---*--+-*----+------+-   -+------+
    PUSI=1    *    *
              ******

    +-----+------+-   -+------+
    | HDR | A183 | ... | A366 |
    +-----+------+-   -+------+
    PUSI=0

    +-----+------+-   -+------+
    | HDR | A367 | ... | A550 |
    +-----+------+-   -+------+
    PUSI=0

            PP=181         CRC pour A      Longueur SNDU
     +-----+------+------+-   -+------+------+------+
    | HDR | 0xB5 | A551 | ... | A731 | 0x01 | 0x18 |
    +-----+---*--+------+-   -+------+*-----+------+
    PUSI=1    *                       *
              *************************

    +-----+------+-   -+------+
    | HDR | B002 | ... | B185 |
    +-----+------+-   -+------+
    PUSI=0

                                Indicateur       Octets de
                                 de fin           bourrage
    +-----+------+-   -+------+------+------+-   -+------+
    | HDR | B186 | ... | B283 | 0xFF | 0xFF | ... | 0xFF |
    +-----+------+-   -+------+------+------+-   -+------+
    PUSI=0

Exemple A.4 : Illustration du champ Longueur SNDU

SNDU A fait 200 octets
SNDU B fait 60 octets
SNDU C fait 60 octets
La séquence comporte deux paquets TS:

                      Longueur
            PP=0       SNDU
    +-----+------+------+------+-   -+------+
    | HDR | 0x00 | 0x00 | 0xC4 | ... | A182 |
    +-----+----*-+-*----+------+-   -+------+
    PUSI=1     *   *  +      +
               *****  ++++++++
                       +
                       +++++++++++++++++
                                       +  Longueur
            PP=17           CRC for A  +   SNDU
    +-----+------+------+-   -+------+-+----+------+-
    | HDR | 0x11 | A183 | ... | A199 | 0x00 | 0x38 | ...
    +-----+----*-+------+-   -+------+*-----+------+-
    PUSI=1     *                      *  +       +
               ************************  +++++++++
                                          +
    +++++++++++++++++++++++++++++++++++++++
    +
    +                 Longueur                 Indicateur    Octets
    +                  SNDU                    de fin        de bourrage
    +    -+------+------+------+  -+------+------+------+- -+------+
    + ... | B59  | 0x00 | 0x38 |...| C59  | 0xFF | 0xFF |...| 0xFF |
    +    -+------+-+----+------+  -+------+-+----+------+- -+------+
    +              +  +      +              +
    +              +  ++++++++              +
    +              +   +                    +
    ++++++++++++++++   ++++++++++++++++++++++

*** pointeur de charge utile (PP) de paquet TS
+++ Indicateur de longueur ULE

Exemple A.5 : trois PDU de 44 octets

SNDU A fait 52 octets (pas d'adresse NPA de destination ULE)
SNDU B fait 52 octets (pas d'adresse NPA de destination ULE)
SNDU C fait 52 octets (pas d'adresse NPA de destination ULE)

La séquence comporte 1 paquet TS :

                     Longueur
           PP=0      SNDU
   +-----+------+------+------+-   -+-----+------+------+-   -+-----+-
   | HDR | 0x00 | 0x80 | 0x30 | ... | A51 | 0x80 | 0x30 | ... | B51 | ..
   +-----+----*-+-*----+------+-   -+-----+------+------+-   -+-----+-
   PUSI=1     *   *
              *****

                                         Indicateur    Octets
                                         de fin       de bourrage
                -----+------+-   -+-----+---------+- -+------+
            ... 0x80 | 0x30 | ... | C51 |0xFF|0xFF|   | 0xFF |
                -----+------+-   -+-----+---------+- -+------+

 	Appendice B.	Encapsulation de SNDU

Exemple d'encapsulation ULE portant un paquet ICMPv6 généré par ping6.

Longueur de SNDU ULE : 63 décimal
Valeur du bit D : 0 (adresse NPA de destination présente)
Type de protocole ULE : 0x86dd (IPv6)
Adresse NPA de destination ULE : 00:01:02:03:04:05
CRC32 ULE : 0x7c171763
Source IPv6 : 2001:DB8:3008:1965::1
Destination IPv6 : 2001:DB8:2509:1962::2
Contenu de la SNDU (incluant le CRC-32) :
0000 : 00 3f 86 dd 00 01 02 03 04 05 60 00 00 00 00 0d
0016 : 3a 40 20 01 0d b8 30 08 19 65 00 00 00 00 00 00
0032 : 00 01 20 01 0d b8 25 09 19 62 00 00 00 00 00 00
0048 : 00 02 80 00 9d 8c 06 38 00 04 00 00 00 00 00 7c
0064 : 17 17 63

 	Adresse des auteurs

Godred Fairhurst	Bernhard Collini-Nocker	
Department of Engineering	Department of Scientific Computing	
University of Aberdeen	University of Salzburg	
Aberdeen, AB24 3UE	Jakob Haringer Str. 2	
UK	5020 Salzburg	
mél : gorry@erg.abdn.ac.uk 	Austria	
Web : http://www.erg.abdn.ac.uk/users/Gorry 	mél : bnocker@cosy.sbg.ac.at 	
	Web : http://www.scicomp.sbg.ac.at/ 	

 	Déclaration de droits de reproduction

Copyright (C) The IETF Trust (2005).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci-encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Remerciement
Le financement de la fonction d’édition des RFC est actuellement fourni par la Internet Society.