Groupe de travail Réseau	M. Watson, Digital Fountain
Request for Comments : 5445	
RFC rendues obsolètes : 3452, 3695	mars 2009
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle

Schémas de base de correction  d'erreur directe (FEC) 

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la normalisation 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 "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document.

Résumé
Le présent document donne les spécifications de schéma de correction d'erreur directe (FEC, Forward Error Correction) conformément au bloc de construction de FEC de transport fiable de diffusion groupée (RMT, Reliable Multicast Transport (RMT) pour le schéma de FEC compact No-Code, le schéma de FEC de petit bloc, grand bloc, et bloc expansible, le schéma de FEC de petit bloc systématique, et le schéma de FEC compact. Le présent document rend obsolète la RFC 3695 et assume la responsabilité des schémas de FEC définis dans la RFC 3452.
Table des matières
1. Introduction	2
2. Notation des exigences	2
3. Schéma compact de FEC No-Code	2
3.1 Introduction	2
3.2 Formats et codes	2
3.3 Procédures	4
3.4 Spécification du code de FEC	4
4. Schéma de FEC de petit bloc, grand bloc, et bloc expansible	5
4.1 Introduction	5
4.2 Formats et codes	5
4.3 Procédures	7
4.4 Spécification de code de FEC	7
5. Schéma de FEC de petit bloc systématique	7
5.1 Introduction	7
5.2 Formats et codes	7
5.3 Procédures	9
5.4 Spécification de code de FEC	9
6. Schéma compact de FEC	9
6.1 Introduction	9
6.2. Formats et codes	9
6.3 Procédures	10
6.4 Spécification de code de FEC	10
7. Considérations sur la sécurité	10
8. Remerciements	10
9. Considérations relatives à l’IANA	10
10. Changements par rapport aux schémas définis dans les RFC 3452 et RFC 3695	11
11. Références	12
11.1 Références normatives	12
11.2 Références pour information	12
Adresse de l'auteur	12

 	1.	Introduction

Le document spécifie les schémas de FEC suivants en accord avec les exigences de spécification de bloc de construction de FEC [RFC5052] :
o	Schéma de FEC compact No-Code
o	Schéma de FEC de petit bloc, grand bloc, et bloc expansible
o	Schéma de FEC de petit bloc systématique
o	Schéma de FEC compact

Le présent document hérite du contexte, langage, déclarations et restrictions de bloc de construction de FEC de la [RFC5052]. Il utilise aussi la terminologie de la [RFC3453], qui décrit l'utilisation des codes de FEC dans le contexte du transport fiable de diffusion groupée IP et fournit une introduction à certains codes de FEC d'utilisation courante.

Les blocs de construction sont définis dans la [RFC3048]. Le présent document suit les lignes directrices générales de la [RFC3269].

Les [RFC3452] et [RFC3695] contiennent les versions précédentes des schémas de FEC définis dans la présente spécification. Ces RFC ont été publiées dans la catégorie "Expérimentale". L'intention déclarée du groupe de travail RMT était de re soumettre ces spécifications comme propositions de normes de l'IETF en temps utile. Le présent document rend obsolète la [RFC3695]. La [RFC3452] avait déjà été rendue obsolète par la [RFC5052], et le présent document assume la responsabilité des aspects de la [RFC3452] qui n'étaient pas inclus dans la [RFC5052].

Cette spécification de proposition de norme est donc fondée sur la rétro compatibilité avec les schémas de FEC définis dans les [RFC3452] et [RFC3695], mis à jour en accord avec l'expérience accumulée et la maturité croissante des protocoles depuis leur publication originale. Cette expérience s'applique à la fois à la présente spécification et aux stratégies de contrôle de l'encombrement relatives à l'utilisation de cette spécification.

Les différences entre les spécifications de schéma de FEC des [RFC3452] et [RFC3695] et le présent document sont données à la Section 10.

Les champs d'entier spécifiés dans ce document sont tous codés dans l'ordre des octets du réseau (gros boutien).

 	2.	Notation des exigences

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].

 	3.	Schéma compact de FEC No-Code
 	3.1	Introduction
Le schéma de FEC compact No-code est un schéma de FEC pleinement spécifié. Le schéma n'exige pas de codage de FEC et est spécifié principalement pour permettre un simple essai d'interopérabilité entre les différentes mises en œuvre d'instances de protocole qui utilisent le bloc de construction de FEC.

 	3.2	Formats et codes
 	3.2.1	Identifiants de charge utile de FEC
L'identifiant de charge utile de FEC pour le schéma compact No-Code de FEC est composé d'un numéro de bloc source et d'un identifiant de symbole de codage comme montré à la Figure 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Numéro de bloc source       | Identifiant symbole de codage |
+---------------+---------------+---------------+---------------+

Figure 1 : Format d'identifiant de charge utile de FEC pour le schéma Compact No-Code de FEC

Le numéro de bloc source (SBN, Source Block Number) est un entier non signé de 16 bits qui est utilisé pour identifier de quel bloc de source de l'objet est généré le symbole de codage dans la charge utile du paquet. Il y a deux modes possibles : dans le mode de SBN unique, chaque bloc de source au sein de l'objet a un unique numéro de bloc source associé, et dans le mode SBN non unique, les mêmes numéros de bloc source peuvent être utilisés pour plus d'un bloc source au sein de l'objet. Quel mode est utilisé pour un objet sort du domaine d'application du présent document et DOIT être communiqué, explicitement ou implicitement, hors bande aux receveurs.

Si le mode SBN unique est utilisé, alors les numéros de bloc source successifs sont associés à des blocs de source consécutifs de l'objet en commençant par le numéro de bloc de source 0 pour le premier bloc de source de l'objet. Dans ce cas, il y a au plus 2^^16 blocs de source dans l'objet.

Si le mode SBN non unique est utilisé, alors la transposition des blocs de source en numéros de bloc de source DOIT être communiquée hors bande aux receveurs, et comment cela est fait sort du domaine d'application du présent document. Cette transposition pourrait être implicite, par exemple, déterminée par l'ordre de transmission des blocs de source. Dans le mode SBN non unique, les paquets pour deux différents blocs de source transposés en les mêmes numéros de bloc source NE DEVRAIENT PAS être envoyés dans un intervalle de temps plus court que le temps de transport d'un bloc de source. Le temps de transport d'un bloc de source inclut le temps nécessaire pour traiter le bloc de source à la couche transport de l'envoyeur, le temps de transit du réseau pour les paquets, et le temps nécessaire pour traiter le bloc de source au transport du receveur. Cela permet au receveur de décider clairement quels paquets appartiennent à quel bloc de source.

L'identifiant de symbole de codage est un entier non signé de 16 bits qui identifie quel symbole de codage spécifique généré depuis le bloc de source est porté dans la charge utile du paquet. Les détails exacts de la correspondance entre identifiant de symbole de codage et symbole de codage dans la charge utile du paquet sont spécifiés au paragraphe  3.4.

 	3.2.2	Informations de transmission d'objet de FEC
 	3.2.2.1	Obligatoire
L'élément d'informations de transmission d'objet (OTI, Object Transmission Information) de FEC obligatoire pour le schéma de FEC compact No-Code est :

o	Identifiant de codage de FEC : zéro (0)

 	3.2.2.2	Commun
Les éléments communs d'informations de transmission d'objet de FEC et leurs gammes de valeurs pour le schéma de FEC compact No-Code sont :

Longueur de transfert : entier non négatif, inférieur à 2^^48, indiquant la longueur de l'objet en octets.

Longueur de symbole de codage : entier non négatif, inférieur à 2^^16, indiquant la longueur de chaque symbole de codage en octets.

Longueur maximum de bloc de source : entier non négatif, inférieur à 2^^32, indiquant le nombre maximum de symboles de source dans un bloc de source.

Le codage des informations communes de transmission d'objet de FEC est défini à la Figure 2.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Longueur de transfert                     |
+                               +---------------+---------------+
|                               |           Réservé             |
+---------------+---------------+---------------+---------------+
| Longueur de symbole de codage |Long. max. bloc de source (MSB)|
+---------------+---------------+---------------+---------------+
|Long. max. bloc de source (LSB)|
+---------------+---------------+

Figure 2 : Codage des informations communes de transmission d'objet de FEC pour schéma de FEC compact No-Code
Les champs Longueur de transfert, Longueur de symbole de codage, et Longueur maximum de bloc de source sont codés comme des entiers non signés, de longueur 48 bits, 16 bits, et 32 bits, respectivement.

Tous les symboles de codage d'un objet de transport DOIVENT avoir une longueur égale à la longueur spécifiée dans l'élément Longueur de symbole de codage, avec l'exception facultative du dernier symbole de source du dernier bloc de source (de sorte qu'un bourrage redondant n'est pas obligatoire dans ce dernier symbole). Ce dernier symbole de source DOIT être logiquement bourré de zéros quand un autre symbole de codage est calculé sur la base de ce symbole de source pour assurer la même interprétation de cette valeur de symbole de codage par l'envoyeur et le receveur. Cependant, ce bourrage n'a en fait pas besoin d'être envoyé avec les données du dernier symbole de source.

Le champ "Réservé" dans les informations codées de transmission d'objet de FEC DOIT être réglé à zéro par les envoyeurs et sa valeur DOIT être ignorée par les receveurs.

Note : ce schéma de FEC a été défini d'abord dans la [RFC3695], qui n'exigeait pas que la longueur de symbole de codage devrait être la même pour chaque bloc de source. Le présent document introduit une exigence générale que la longueur de symbole de codage soit la même sur les blocs de source. Comme aucun protocole n'était défini pour prendre en charge la variation de la longueur de symbole de codage entre les blocs de source, ceci peut être fait sans introduire de problème de rétro compatibilité.

 	3.2.2.3	Spécifique du schéma
Aucun élément d'informations de transmission d'objet de FEC spécifique du schéma n'est défini par le présent schéma de FEC.

 	3.3	Procédures
L'algorithme défini au paragraphe 9.1 de la [RFC5052] DOIT être utilisé pour partager le fichier en blocs de source.

 	3.4	Spécification du code de FEC
Le schéma de FEC compact No-Code n'exige pas de codage ou décodage de FEC. Chaque symbole de codage consiste plutôt en octets consécutifs d'un bloc de source de l'objet.

Les deux paragraphes suivants décrivent les détails de la façon dont le schéma de FEC compact No-Code fonctionne pour chaque bloc de source d'un objet.

 	3.4.1	Logistique de bloc de source
Soit X > 0 la longueur d'un bloc de source en octets. Soit L > 0 la longueur du symbole de codage contenu dans la charge utile de chaque paquet. La valeur de X et de L fait partie des informations de transmission d'objet de FEC, et comment ces informations sont communiquées à un receveur sort du domaine d'application du présent document.

Pour un bloc de source donné de X octets avec le numéro de bloc source I, soit N = X/L arrondi au plus proche entier supérieur. Le symbole de codage porté dans la charge utile d'un paquet consiste en une portion consécutive de blocs de source. Le bloc de source est logiquement partagé en N symboles de codage, chacun de L octets de long, et les identifiants de symbole de codage correspondants vont de 0 à N-1 en commençant par le début du bloc de source et en poursuivant jusqu'à la fin. Donc, le symbole de codage avec l'identifiant de symbole de codage Y consiste en les octets L*Y jusqu'à L*(Y+1)-1 du bloc de source, où les octets du bloc de source sont numérotés de 0 à X-1. Si X/L n'est pas entier, alors le dernier symbole de codage avec l'identifiant de symbole de codage N-1 consiste en les octets L*(N-1) jusqu'au dernier octet X-1 du bloc de source, et les L*N - X octets restants du symbole de codage peuvent être bourrés de zéros.

Par exemple, supposons la longueur de bloc de source X = 20  400 et la longueur de symbole de codage L = 1000. Le symbole de codage avec l'identifiant de symbole de codage 10 contient les octets 10  000 à 10  999 du bloc de source, et le symbole de codage avec l'identifiant de symbole de codage 20 contient les octets 20  000 jusqu'au dernier octet 20  399 du bloc de source et les 600 octets restants du symbole de codage peuvent être bourrés de zéros.

Il n'y a pas de restriction au delà des règles déclarées ci-dessus sur la façon dont un envoyeur génère des symboles de codage à envoyer d'un bloc de source. Cependant, il est recommandé qu'une mise en œuvre se réfère au document d'accompagnement [RFC3452] pour des conseils généraux.

Dans le paragraphe suivant, une procédure est recommandée pour l'envoi et la réception des blocs de source.

 	3.4.2	Envoi et réception d'un bloc de source
La procédure de carrousel suivante est RECOMMANDÉE pour un envoyeur qui génère des paquets contenant des identifiants de charge utile de FEC et les symboles de codage correspondants pour un bloc de source avec le numéro de bloc de source I. Régler la longueur en octets d'un symbole de codage à une valeur fixe L, qui est raisonnable pour une charge utile de paquet (par exemple, assurant que la taille totale de paquet n'excède pas la MTU) et qui est plus petite que la longueur de bloc de source X, par exemple, L = 1 000 pour X ≤ 1 000. Initialiser Y à une valeur aléatoire choisie dans l'intervalle [0 à N-1]. Répéter ce qui suit pour chaque paquet du bloc de source à envoyer.

o	Si Y ≤ N-1, générer alors le symbole de codage Y.

o	Dans l'identifiant de charge utile de FEC, régler la longueur de bloc de source à X, régler le numéro de bloc source à I, régler l'identifiant de symbole de codage à Y, placer l'identifiant de charge utile de FEC et le symbole de codage dans le paquet à envoyer.

o	En préparation de la génération du prochain paquet : si Y < N-1, alors incrémenter Y de un, autrement  si Y = N-1 alors remettre Y à zéro.

La procédure suivante est RECOMMANDÉE à un receveur pour récupérer le bloc de source sur la base des paquets reçus pour le bloc de source provenant d'un envoyeur qui utilise la procédure de carrousel décrite ci-dessus. Le receveur peut déterminer à partir de quel bloc de source un paquet reçu a été généré par le numéro de bloc source porté dans l'identifiant de charge utile de FEC. À réception du premier identifiant de charge utile de FEC pour un bloc de source, le receveur utilise la longueur de bloc de source et la longueur de symbole de codage reçues hors bande au titre des informations de transmission d'objet de FEC pour déterminer la longueur X en octets du bloc de source et la longueur L en octets de chaque symbole de codage. Le receveur alloue de l'espace pour les X octets que le bloc de source exige. Le receveur calcule aussi la longueur de symbole de codage dans la charge utile du paquet en soustrayant la longueur d'en-tête de paquet de la longueur totale du paquet reçu. Le receveur vérifie que cette longueur de symbole est égale à L, sauf dans le cas où c'est le dernier symbole du bloc de source, et dans ce cas la longueur de symbole dans le paquet peut être inférieure à L. Après le calcul de N = X/L arrondi au plus proche entier, le receveur alloue un dispositif booléen RECEIVED[0..N-1] avec toutes les N entrées initialisées à faux pour retracer les symboles de codage reçus. Le receveur continue de recevoir les paquets pour le bloc de source tant qu'il y a au moins une entrée dans RECEIVED encore réglée à faux ou jusqu'à ce que l'application décide d'arrêter sur ce bloc de source et de passer à d'autres blocs de source. Pour chaque paquet reçu pour le bloc de source (y compris le premier paquet) les étapes à suivre pour aider à récupérer le bloc de source sont les suivantes. Soit Y la valeur de l'identifiant de symbole de codage dans l'identifiant de charge utile de FEC du paquet. Si Y ≤ N-1, alors le receveur copie le symbole de codage à l'endroit approprié dans l'espace réservé pour le bloc de source et règle RECEIVED[Y] = vrai. Si toutes les N entrées de RECEIVED sont vraies, alors le receveur a récupéré le bloc de source entier.

 	4.	Schéma de FEC de petit bloc, grand bloc, et bloc expansible
 	4.1	Introduction
Cette section définit un schéma de FEC sous spécifié pour les codes de FEC de petit bloc, les codes de FEC de grand bloc, et les codes de FEC expansibles comme décrit dans la [RFC3453].

 	4.2	Formats et codes
 	4.2.1	Identifiants de charge utile de FEC
L'identifiant de charge utile de FEC est composé d'un numéro de bloc source et d'un identifiant de symbole de codage structuré comme le montre la Figure 3.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Numéro de bloc source                     |
+---------------+---------------+---------------+---------------+
|                     Identifiant de symbole de codage          |
+---------------+---------------+---------------+---------------+

Figure 3 : Format d'identifiant de charge utile de FEC pour codes de FEC de petit bloc, grand bloc, et expansible

Le numéro de bloc source est un entier non signé de 32 bits qui identifie à partir de quel bloc de source de l'objet sont générés le ou les symboles de codage dans la charge utile. Ces blocs sont numérotés consécutivement de 0 à N-1, où N est le nombre de blocs de source dans l'objet.

L'identifiant de symbole de codage est un entier non signé de 32 bits qui identifie quels symboles de codage spécifiques générés à partir du bloc de source sont portés dans la charge utile du paquet. Les détails exacts de la correspondance entre les identifiants de symbole de codage et les symboles de codage dans la charge utile de paquet dépendent de l'instance particulière du schéma de FEC utilisé telle qu'identifiée par l'identifiant de codage de FEC et par l'identifiant d'instance de FEC, et ces détails peuvent être non normalisés.

 	4.2.2	Informations de transmission d'objet de FEC
 	4.2.2.1	Obligatoire
L'élément d'informations de transmission d'objet de FEC obligatoire pour le schéma de FEC petit bloc, grand bloc, et expansible est :

o	Identifiant de codage de FEC : 128

 	4.2.2.2	Commun
Les éléments communs d'informations de transmission d'objet de FEC et leurs gammes de valeur pour le schéma de FEC petit bloc, grand bloc, et expansible sont :

Identifiant d'instance de FEC : un entier non négatif inférieur à 2^^16.

Longueur de transfert : un entier non négatif inférieur à 2^^48, indiquant la longueur de l'objet en octets.

Longueur de symbole de codage : un entier non négatif inférieur à 2^^16, indiquant la longueur de chaque symbole de codage en octets.

Longueur maximum de bloc source : un entier non négatif inférieur à 2^^32, indiquant le nombre maximum de symboles de source dans un bloc de source.

Les informations de transmission d'objet (OTI) codées communes de FEC sont définies à la Figure 4.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Longueur de transfert                    |
+                               +---------------+---------------+
|                               | Identifiant d'instance de FEC |
+---------------+---------------+---------------+---------------+
| Longueur de symbole de codage |Long. max. bloc de source (MSB)|
+---------------+---------------+---------------+---------------+
|Long. max. bloc de source (LSB)|
+---------------+---------------+

Figure 4 : OTI codées communes de FEC pour schéma de FEC de petit bloc, grand bloc, et expansible

La longueur de transfert (48 bits), l'identifiant d'instance de FEC (16 bits), la longueur de symbole de codage (16 bits), et la longueur maximum de bloc de source (32 bits) sont codés comme des entiers non signés.

 	4.2.2.3	Spécifiques de schéma
Le champ Informations de transmission d'objet de FEC spécifiques de schéma pour les schémas de FEC de petit bloc, grand bloc, et expansible donne la possibilité d'informations de transmission d'objet de FEC spécifiques d'instance. Le format des informations de transmission d'objet de FEC spécifiques de schéma pour ce schéma de FEC est défini à la Figure 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Longueur    |     OTI de FEC spécifiques d'instance         |
+---------------+---------------+---------------+---------------+
|                                                               |
|              OTI de FEC spécifiques d'instance (suite)        |
|                                                               |
+---------------+---------------+---------------+---------------+

Figure 5 : Codage d'OTI de FEC spécifiques de schéma pour les schémas de FEC de petit bloc, grand bloc, et expansible

Le champ Informations de transmission d'objet de FEC spécifiques de schéma contient les sous champs suivants :

Longueur (1 octet) : entier non signé qui spécifie la longueur des OTI de FEC spécifiques de schéma dans des mots de quatre octets (incluant ce champ Longueur) sauf que la valeur zéro indique qu'aucune OTI de FEC spécifiques d'instance ne sont fournies. Quand la longueur est zéro, trois octets de bourrage contenant la valeur zéro DEVRONT suivre le champ Longueur pour garder l'alignement sur 4 octets.

OTI de FEC spécifiques d'instance : le contenu de ce champ est spécifique de l'instance de schéma de FEC.

Noter que dans le cas d'un protocole de livraison de contenu qui prend en charge la signalisation externe de la longueur totale des informations de transmission d'objet de FEC, le champ OTI de FEC spécifiques de schéma défini ici est  facultatif. Autrement, ce champ DOIT être inclus.

 	4.3	Procédures
L'algorithme défini au paragraphe 9.1 de la [RFC5052] DOIT être utilisé pour partager le fichier en blocs de source.

 	4.4	Spécification de code de FEC
La spécification de code de FEC et la correspondance des identifiants de symboles de codage en symboles de codage sont définies par des instances spécifiques de ce schéma et sortent donc du domaine de ce document.

 	5.	Schéma de FEC de petit bloc systématique
 	5.1	Introduction
Cette section définit un schéma de FEC sous spécifié pour les codes de FEC de petit bloc systématique, comme décrit dans la [RFC3453]. Pour les codes de FEC de petit bloc systématique, chaque bloc de source est d'une longueur d'au plus 65535 symboles de source.

Bien que ces codes puissent généralement être traités par l'identifiant de codage de FEC décrit à la Section 4, un identifiant spécifique de codage de FEC est défini pour les codes de FEC de petit bloc systématique pour permettre plus de souplesse et pour garder les en-têtes compacts. La longueur de petit bloc de source et du facteur de petite expansion qui caractérisent souvent les codes systématiques peuvent exiger que la source des données change fréquemment la longueur du bloc de source. Pour permettre la variation dynamique de la longueur du bloc de source et pour la communiquer aux receveurs avec de faibles frais généraux, la longueur de bloc est incluse dans l'identifiant de charge utile de FEC.

 	5.2	Formats et codes
 	5.2.1	Identifiants de charge utile de FEC
L'identifiant de charge utile de FEC est composé du numéro de bloc de source, de la longueur de bloc de source, et de l'identifiant de symbole de codage, structurés comme montré à la Figure 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Numéro de bloc de source                  |
+---------------+---------------+---------------+---------------+
| Longueur de bloc de source    | Identifiant symbole de codage |
+---------------+---------------+---------------+---------------+

Figure 6 : Format d'identifiant de charge utile de FEC pour schéma de FEC de petit bloc systématique

Le numéro de bloc de source est un entier non signé de 32 bits qui identifie de quel bloc de source de l'objet le ou les symboles de codage dans la charge utile sont générés. Ces blocs sont numérotés consécutivement de 0 à N-1, où N est le nombre de blocs de source dans l'objet.

La longueur de bloc de source est un entier non signé de 16 bits qui spécifie la longueur en unités de symboles de source du bloc de source identifié par le numéro de bloc source.

L'identifiant de symbole de codage est un entier non signé de 16 bits qui identifie quels symboles de codage spécifiques générés depuis le bloc de source sont portés dans la charge utile de paquet. Chaque symbole de codage est soit un symbole de source original, soit un symbole redondant généré par le codeur. Les détails exacts de la correspondance entre les identifiants de symbole de codage et les symboles de codage dans la charge utile du paquet dépendent de l'instance particulière de schéma de FEC utilisée, comme identifiée par l'identifiant d'instance de FEC, et ces détails peuvent être non normalisés.

 	5.2.2	Informations de transmission d'objet de FEC
 	5.2.2.1	Obligatoire
L'élément d'informations de transmission d'objet de FEC obligatoire pour le schéma de FEC de petit bloc systématique est :

o	Identifiant de codage de FEC : 129

 	5.2.2.2	Commun
Les éléments communs d'informations de transmission d'objet de FEC et leurs gammes de valeur pour le schéma de FEC de petit bloc systématique sont :

Identifiant d'instance de FEC : un entier non négatif inférieur à 2^^16.

Longueur de transfert : un entier non négatif inférieur à 2^^48, indiquant la longueur de l'objet en octets.

Longueur de symbole de codage : un entier non négatif inférieur à 2^^16, indiquant la longueur de chaque symbole de codage in octets.

Longueur maximum de bloc de source : un entier non négatif inférieur à 2^^16, indiquant le nombre maximum de symboles de source dans un bloc de source.

Nombre maximum de symboles de codage : un entier non négatif inférieur à 2^^16, indiquant le nombre maximum de symboles de codage par bloc (c'est-à-dire, les symboles de source plus de réparation dans le cas d'un code systématique).

Le codage des informations communes de transmission d'objet de FEC est défini à la Figure 7.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Longueur de transfert                    |
+                               +---------------+---------------+
|                               | Identifiant d'instance de FEC |
+---------------+---------------+---------------+---------------+
| Longueur de symbole de codage | Longueur maximum bloc source  |
+---------------+---------------+---------------+---------------+
| Nb. max. symboles de codage   |
+---------------+---------------+

Figure 7 : Format des OTI de FEC pour schéma de FEC de petit bloc systématique

Les champs Longueur de transfert (48 bits), Identifiant d'instance de FEC (16 bits), Longueur de symbole de codage (16  bits), Longueur maximum de bloc de source (16 bits), et Nombre maximum de symboles de codage (16 bits) sont codés comme des entiers non signés.

Tous les symboles de codage d'un objet de transport DOIVENT avoir une longueur égale à la longueur spécifiée dans le champ Longueur de symbole de codage, avec l'exception facultative du dernier symbole de source du dernier bloc de source (afin que le bourrage redondant ne soit pas obligatoire dans ce dernier symbole). Ce dernier symbole de source DOIT être logiquement bourré de zéros quand un autre symbole de codage est calculé sur la base de ce symbole de source pour assurer la même interprétation de cette valeur de symbole de codage par l'envoyeur et le receveur. Cependant, ce bourrage n'a pas besoin d'être réellement envoyé avec les données du dernier symbole de source.

Note : ce schéma de FEC a d'abord été défini dans la [RFC3452], qui n'exigeait pas que la longueur de symbole de codage devrait être la même pour chaque bloc de source. Cependant, aucun protocole n'a été défini qui prenne en charge de variation de la longueur de symbole de codage entre les blocs de source, et donc l'introduction d'une exigence générale que la longueur de symbole de codage soit la même sur les blocs de source (comme définis ici) ne devrait pas causer de problème de rétro compatibilité et va aider à l'interopérabilité.

 	5.2.2.3	Spécifique de schéma
Le format des informations de transmission d'objet de FEC spécifiques de schéma défini au paragraphe 4.2.2.3 DEVRA être utilisé.

 	5.3	Procédures
L'algorithme défini au paragraphe 9.1 de la [RFC5052] PEUT être utilisé pour partager le fichier en blocs de source.  Autrement, l'instance de schéma de FEC DOIT spécifier l'algorithme utilisé.

 	5.4	Spécification de code de FEC
La spécification de code de FEC et la correspondance des identifiants de symboles de codage en symboles de codage sont définies par les instances spécifiques de ce schéma et sortent donc du domaine de ce document.

 	6.	Schéma compact de FEC
 	6.1	Introduction
Le schéma de FEC compact est un schéma de FEC sous spécifié. Ce schéma de FEC est similaire dans son esprit au schéma de FEC compact No-Code, sauf qu'un codage non trivial de FEC (qui est sous spécifié) peut être utilisé pour générer un ou des symboles de codage placés dans la charge utile de chaque paquet et un décodeur de FEC correspondant peut être utilisé pour produire le bloc de source provenant des paquets reçus.

 	6.2.	Formats et codes
 	6.2.1	Identifiants de charge utile de FEC
Le format d'identifiant de charge utile de FEC défini au paragraphe 3.2.1 DEVRA être utilisé.

 	6.2.2	Informations de transmission d'objet de FEC
 	6.2.2.1	Obligatoire
L'élément d'informations de transmission d'objet de FEC obligatoire pour le schéma de FEC compact No-Code est :

o	Identifiant de codage de FEC : 130

 	6.2.2.2	Commun
Les éléments communs d'informations de transmission d'objet de FEC et leur codage sont les mêmes que définis pour le schéma de FEC de petit bloc, grand bloc, et expansible de la Figure 4.

 	6.2.2.3	Spécifque de schéma
Le format des informations de transmission d'objet de FEC spécifques de schéma défini au paragraphe 4.2.2.3 DEVRA être utilisé.

 	6.3	Procédures
L'algorithme défini au paragraphe 9.1. de la [RFC5052] DOIT être utilisé pour partager le fichier en blocs de source.

 	6.4	Spécification de code de FEC
La spécification de code de FEC et la correspondance des identifiants de symboles de codage en symboles de codage sont définies par les instances spécifiques de ce schéma et sortent donc du domaine de ce document.

 	7.	Considérations sur la sécurité

Cette spécification n'introduit pas de considérations de sécurité au delà de celles décrites dans la [RFC5052].

 	8.	Remerciements

Ce document se fonde substantiellement sur la [RFC3695] de Michael Luby et Lorenzo Vicisano et la [RFC3452] de Michael Luby, Lorenzo Vicisano, Jim Gemmell, Luigi Rizzo, Mark Handley, et Jon Crowcroft.

 	9.	Considérations relatives à l’IANA

Les identifiants de codage de FEC 0 et 130 ont d'abord été définis et enregistrés dans l'espace de noms ietf:rmt:fec:encoding par la [RFC3695]. Le présent document met à jour et rend obsolètes les définitions provenant de cette spécification. Les références à cette spécification devraient être remplacées par des références au présent document.

Les identifiants de codage de FEC 128 et 129 ont d'abord été définis et enregistrés dans l'espace de noms ietf:rmt:fec:encoding par la [RFC3452]. Le présent document met à jour et rend obsolètes les définitions provenant de cette spécification. Les références à cette spécification devraient être remplacées par des références au présent document.

Les valeurs des identifiants de codage de FEC et les identifiants d'instance de FEC sont soumis à enregistrement par l'IANA. Pour des lignes directrices générales sur les considérations relatives à l'IANA qui s'appliquent au présent document, voir la [RFC5052].

Le présent document alloue l'identifiant de codage de FEC pleinement spécifié de 0 sous l'espace de noms  ietf:rmt:fec:encoding (qui était précédemment alloué par la [RFC3695], qui est rendue obsolète par le présent document) de "Compact No-Code" comme spécifié à la Section 3.

Le présent document alloue l'identifiant de codage de FEC sous spécifié de 128 sous l'espace de noms ietf:rmt:fec:encoding  (qui était précédemment alloué par la [RFC3452]) à "Petit bloc, grand bloc, expansible", et noter qu'on a ajouté une virgule entre grand bloc et expansible tout au long du présent document (le style de l'éditeur des RFC est d'inclure une virgule avant le dernier élément d'une série). Si il n'y a pas d'objection, on demandera à l'IANA d'inclure cette virgule dans son registre pour qu'il soit cohérent. --> Code de FEC expansible" comme spécifié à la Section 4.

Le présent document alloue l'identifiant de codage de FEC sous spécifié de 129 sous l'espace de noms ietf:rmt:fec:encoding (qui était précédemment alloué par la [RFC3452]) aux "codes de FEC de petit bloc systématique" comme spécifié à la Section 5.

Le présent document alloue l'identifiant de codage de FEC sous spécifié de 130 sous l'espace de noms ietf:rmt:fec:encoding (qui était précédemment alloué par la [RFC3695], qui est rendue obsolète par le présent document) à "FEC compacte" comme spécifié à la Section 6.

Comme les identifiants de codage de FEC 128, 129, et 130 sont sous spécifiés, des sous espaces de noms "Identifiant d'instance de FEC" doivent être établis, conformément à la [RFC5052]. Donc, le présent document assume aussi la responsabilité des registres "Identifiant d'instance de FEC" désignés.

ietf:rmt:fec:encoding:instance :128, de portée ietf:rmt:fec :  codage = 128

ietf:rmt:fec:encoding:instance :129, de portée ietf:rmt:fec : codagz = 129

ietf:rmt:fec:encoding:instance :130, de portée ietf:rmt:fec : codage = 130

Les valeurs qui peuvent être allouées dans ces espaces de noms sont des indices numériques non négatifs. Les demandes d'allocation sont accordées sur la base du "premier arrivé, premier servi". La [RFC5052] spécifie des critères supplémentaires qui doivent être satisfaits pour une allocation dans l'espace de noms générique ietf:rmt:fec:encoding:instance. Ces critères s'appliquent aussi à ietf:rmt:fec:encoding:instance : 128, ietf:rmt:fec:encoding:instance : 129, et ietf:rmt:fec:encoding:instance : 130.

 	10.	Changements par rapport aux schémas définis dans les RFC 3452 et RFC 3695

Cette section décrit les changements entre les versions expérimentales de ces spécifications de schéma de FEC contenues dans les [RFC3452] et [RFC3695] et celles définies dans la présente spécification:

o	Les définitions de schéma ont été mises à jour pour satisfaire les exigences de la [RFC5052].

o	Les formats complets de codage des informations de transmission d'objet de FEC pour chaque schéma sont définis ici, au lieu des spécifications de protocole de livraison de contenu, car le format exact dépend du schéma de FEC.

o	Les précédentes spécifications pour les schémas de FEC compact No-Code et petit bloc systématique n'exigeaient pas que tous les symboles de codage de l'objet aient la même longueur. Cette exigence est introduite dans la présente spécification. Comme aucun protocole n'a été défini pour prendre en charge la variation de la longueur du symbole de codage dans un objet, cela ne devrait pas causer de problème de rétro compatibilité.

 	11.	Références
 	11.1	Références normatives

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

[RFC5052]	M. Watson et autres, "Bloc de construction de la correction d'erreur directe (FEC)", août 2007. (Remplace RFC3452) (P.S.)

 	11.2	Références pour information

[RFC3048]	B. Whetten, L. Vicisano, R. Kermode, M. Handley, S. Floyd et M. Luby, "Blocs de construction de transport fiable en diffusion groupée pour transfert de données en vrac en point à multipoint", janvier 2001. (Info.)

[RFC3269]	R. Kermode et L. Vicisano, "Lignes directrices pour les auteurs de documents de mise en œuvre de protocole et de blocs de construction de transport fiable en diffusion groupée (RMT)", avril 2002.

[RFC3452]	M. Luby, L. Vicisano, J. Gemmell, L. Rizzo, M. Handley et J. Crowcroft, "Bloc de construction de correction d'erreur directe (FEC)", décembre 2002. (Exp., rendue obsolète par la RFC5052)

[RFC3453]	M. Luby et autres, "Utilisation de la correction d'erreur directe (FEC) en diffusion groupée fiable", décembre 2002. (Info.)

[RFC3695]	M. Luby, L. Vicisano, "Schémas compacts de correction d'erreur directe (FEC)", février 2004. (Expérimentale)

 	Adresse de l'auteur

Mark Watson
Digital Fountain
39141 Civic Center Drive
Suite 300
Fremont, CA 94538
USA

mél : mark@digitalfountain.com