Groupe de travail Réseau	E. Boschi, Hitachi Europe	
Request for Comments: 5610	B. Trammell, Hitachi Europe	
Catégorie : Sur la voie de la normalisation	L. Mark, Fraunhofer IFAM	
	T. Zseby, Fraunhofer FOKUS	
Traduction Claude Brière de L'Isle	juillet 2009	

Exportation des informations de type pour les éléments d'information d'exportation d'informations de flux IP (IPFIX)

Résumé
Le présent document décrit une extension au protocole d'exportation d'informations de flux IP (IPFIX, IP Flow Information Export) qui est utilisé pour représenter et transmettre des données provenant d'appareils de mesure de flux IP pour leur collecte, mémorisation, et analyse, pour permettre le codage des propriétés du modèle d'information IPFIX dans un flux de messages IPFIX. Cela permet l'exportation d'informations de type étendu pour des éléments d'information spécifiques d'entreprise et la mémorisation de ces informations dans des fichiers IPFIX, facilitant l'interopérabilité et la réutilisabilité parmi une large variété d'applications et d'outils.

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. 
Table des matières
1. Introduction	2
1.1 Vue d'ensemble des documents IPFIX	2
2. Terminologie	3
3. Exportation des informations de type	3
3.1 informationElementDataType	3
3.2 informationElementDescription	4
3.3 informationElementName	4
3.4 informationElementRangeBegin	4
3.5 informationElementRangeEnd	4
3.6 informationElementSemantics	4
3.7 informationElementUnits	5
3.8 privateEnterpriseNumber	5
3.9 Gabarit d'options de type d'élément d'information	6
3.10 Restrictions sur le type et la sémantique des données	7
4. Considérations sur la sécurité	7
5. Considérations relatives à l'IANA	8
6. Remerciements	8
7. Références	8
7.1 Références normatives	8
7.2 Références pour information	9
Appendice A. Exemples	9
Adresse des auteurs	11

 	1.	Introduction

L'exportation d'informations de flux IP (IPFIX, IP Flow Information Export) fournit un mécanisme de gabarit pour la description souple d'enregistrements de données, en définissant un enregistrement comme une collection d'éléments d'information définis dans un registre de l'IANA, Cependant, ces gabarits fournissent des informations limitées sur le type de données décrites ; bien sûr, ils codent seulement la taille des champs définis par ces éléments d'information. Il n'existe actuellement pas de mécanisme pour fournir des informations de type complètes pour ces éléments d'information, comme il en est défini pour les éléments d'information dans le modèle d'informations IPFIX [RFC5102].

Cela limite en particulier l'interopérabilité des éléments d'information spécifiques d'entreprise. Il n'est pas possible d'utiliser des outils d'analyse sur les enregistrements IPFIX qui contiennent ces éléments d'information partiellement définis qui n'ont pas été développés avec la connaissance a priori de leur type, car de tels outils ne vont pas être capables de les décoder ; ces outils peuvent seulement les traiter et les mémoriser comme des dispositifs d'octets opaques. Cependant, si de plus riches informations sont disponibles, des opérations supplémentaires comme une mémorisation efficace, l'affichage, et une analyse limitée des enregistrements contenant des éléments d'information spécifiques d'entreprise deviennent possibles, même pour des processus de collecte qui n'ont pas été spécifiquement développés pour les comprendre.

Le présent document définit un mécanisme général pour coder l'ensemble complet de propriétés disponibles pour la définition des éléments d'information dans le modèle d'informations IPFIX en ligne au sein d'un flux de messages IPFIX utilisant les options IPFIX. Ce mécanisme peut être utilisé pour définir pleinement les informations de type pour les éléments d'information utilisés au sein d'un flux de messages, sans recourir à une référence externe ou s'appuyer sur une configuration hors bande, améliorant par là l'interopérabilité des éléments d'information spécifiques d'entreprise.

Noter que la solution décrite dans le présent document n'est pas destinée à remplacer l'enregistrement auprès de l'IANA des éléments d'information d'utilité générale. Elle introduit des frais généraux et ne conduit pas à une réelle interopérabilité comme celle fournie par la normalisation. Donc, on recommande fortement de normaliser tous les nouveaux éléments d'information d'utilité générale en les enregistrant auprès de l'IANA. La normalisation est directe, et les informations de type qui ont besoin d'être spécifiées afin de prendre en charge la solution proposée fournissent une base parfaite pour la description exigée pour normaliser l'élément d'information.

Il pourrait arriver qu'un élément d'information précédemment décrit par le mécanisme du présent document devienne ultérieurement un élément d'information standard enregistré par l'IANA. Dans un tel environnement, l'ancienne et la nouvelle version de l'élément d'information peuvent coexister. Une traduction entre éléments d'information exprimée par la solution décrite et les éléments d'information normalisés n'est donc pas nécessaire et est sans objet pour le présent document.

 	1.1	Vue d'ensemble des documents IPFIX
La [RFC5101] "Spécification du protocole d'exportation d'informations de flux IP (IPFIX) pour l'échange d'informations de flux de trafic IP" (informellement, le document de protocole IPFIX) et ses documents associés définissent le protocole IPFIX, qui fournit aux ingénieurs et administrateurs de réseau l'accès aux informations de flux de trafic IP.

La [RFC5470] "Architecture pour l'exportation d'informations de flux IP" (le document d'architecture IPFIX) définit l'architecture pour l'exportation des informations de flux IP mesuré d'un processus d'exportation IPFIX à un processus de collecte IPFIX, et la terminologie de base utilisée pour décrire les éléments de cette architecture, selon les exigences définies dans "Exigences pour l'exportation d'informations de flux IP" [RFC3917]. Le document de protocole IPFIX [RFC5101] couvre les détails de la méthode de transport des enregistrements et gabarits de données IPFIX via un protocole de transport qui tient compte de l'encombrement d'un processus d'exportation IPFIX à un processus de collecte IPFIX.

La [RFC5102] "Modèle d'information pour l'exportation des informations de flux IP" (informellement, le document de modèle d'informations IPFIX) décrit les éléments d'information utilisés par IPFIX, incluant des détails sur la dénomination des éléments d'information, leur numérotation, et le codage de type des données.

Le présent document fait référence aux documents de protocole et d'architecture pour la terminologie et étend le modèle d'informations IPFIX pour fournir de nouveaux éléments d'information pour la représentation des propriétés des éléments d'information. Il tire les définitions de type de données et de sémantique des types de données du modèle d'information ; les codages de ces types de données sont définis dans la [RFC5101].

 	2.	Terminologie

Les termes utilisé dans le présent document qui sont définis dans la section Terminologie de la [RFC5101] sont à interpréter comme ils y sont définis.

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.	Exportation des informations de type

Cette section décrit le mécanisme utilisé pour coder les informations de type d'élément d'information au sein d'un flux de messages IPFIX. Ce mécanisme consiste en un enregistrement de gabarit d'options utilisé pour définir les enregistrements de type d'élément d'information, et en un ensemble d'éléments d'information exigés par ces enregistrements de type. On spécifie d'abord les éléments d'information nécessaires, suivis par la structure du gabarit d'options qui décrit les enregistrements de type.

Noter que les enregistrements de type d'élément d'information exigent un élément d'information, informationElementId, qui est défini dans le modèle d'information d'échantillonnage de paquet (PSAMP, Packet Sampling) [RFC5477]. Cet élément d'information ne supporte de références que d'éléments d'information définis par l'IANA ; l'élément d'information privateEnterpriseNumber est exigé avec informationElementId pour décrire les éléments d'information.

 	3.1	informationElementDataType
Description : description du type de données abstrait d'un élément d'information IPFIX. Ils sont pris des types de données abstraits définis au paragraphe 3.1 du modèle d'informations IPFIX [RFC5102] ; voir dans ce paragraphe plus d'informations sur les types décrits ci-dessous. Ce champ peut prendre les valeurs définies dans le Tableau 1.

Valeur	Description
0	octetArray
1	unsigned8
2	unsigned16
3	unsigned32
4	unsigned64
5	signed8
6	signed16
7	signed32
8	signed64
9	float32
10	float64
11	boolean
12	macAddress
13	string
14	dateTimeSeconds
15	dateTimeMilliseconds
16	dateTimeMicroseconds
17	dateTimeNanoseconds
18	ipv4Address
19	ipv6Address

Tableau 1 : Valeurs de type de données d'IE

Ces types sont enregistrés dans le sous registre de l'IANA "Type de données d'élément d'information IPFIX". Ce sous registre est destiné à allouer des numéros aux noms de type, et non à fournir un mécanisme pour ajouter des types de données au protocole IPFIX, et à ce titre exige une action de normalisation [RFC5226] pour le modifier.

Type de données abstrait : unsigned8
ElementId : 339
Statut : courant
Référence : paragraphe 3.1 du modèle d'informations IPFIX [RFC5102]

 	3.2	informationElementDescription
Description : chaîne Unicode codée en UTF-8 [RFC3629] contenant une description lisible par l'homme d'un élément d'information. Le contenu de informationElementDescription PEUT être annoté avec une ou plusieurs étiquettes de langage [RFC4646], codée en ligne [RFC2482] au sein de la chaîne UTF-8, afin de spécifier le langage dans lequel la description est écrite. Un texte de description en plusieurs langues PEUT étiqueter chaque section avec sa propre étiquette de langue ; dans ce cas, les informations de description dans chaque langue DEVRAIENT avoir une signification équivalente. En l'absence de toute étiquette de langue, le langage "i-default" [RFC2277] DEVRAIT être supposé. Voir dans les considérations sur la sécurité (Section 4) les notes sur le traitement des chaînes pour les enregistrements de type d'élément d'information.

Type de données abstrait : string
ElementId : 340
Statut : courant

 	3.3	informationElementName
Description : chaîne Unicode codée en UTF-8 [RFC3629] contenant le nom d'un élément d'information, entendu comme un simple identifiant. Voir dans les considérations sur la sécurité (Section 4) les notes sur le traitement des chaînes pour les enregistrements de type d'élément d'information.

Type de données abstrait : string
ElementId : 341
Statut : courant

 	3.4	informationElementRangeBegin
Description : contient l'extrémité inférieure incluse de la gamme des valeurs acceptables pour un élément d'information.

Type de données abstrait : unsigned64
Sémantique du type de données : quantité
ElementId : 342
Statut : courant

 	3.5	informationElementRangeEnd
Description : contient l'extrémité supérieure incluse de la gamme des valeurs acceptables pour un élément d'information.

Type de données abstrait : unsigned64
Sémantique du type de données : quantité
ElementId : 343
Statut : courant

 	3.6	informationElementSemantics
Description : description de la signification d'un élément d'information IPFIX. Elle est tirée de la signification du type de données définie au paragraphe 3.2 du modèle d'informations IPFIX [RFC5102] ; voir dans ce paragraphe plus d'informations sur les types décrits ci-dessous. Ce champ peut prendre les valeurs du Tableau 2 ci-dessous. La valeur spéciale 0x00 (par défaut) est utilisée pour noter qu'aucune sémantique ne s'applique au champ ; il ne peut pas être manipulé par un processus de collecte ou un lecteur de fichier qui ne le comprend pas à priori.

Valeur	Description
0	par défaut
1	quantité
2	compteur total
3	compteur de différence
4	identifiant
5	fanions

Tableau 2 : Valeurs de sémantique d'IE

Ces significations sont enregistrées dans le sous registre IANA "Sémantique d'élément d'information IPFIX". Ce sous registre est destiné à allouer des numéros aux noms de sémantique, et non à fournir un mécanisme pour ajouter des significations au protocole IPFIX, et à ce titre exige une action de normalisation [RFC5226] pour le modifier.

Type de données abstrait : unsigned8
ElementId : 344
Statut : courant
Référence : paragraphe 3.2 du modèle d'informations IPFIX [RFC5102]

 	3.7	informationElementUnits
Description : description des unités d'un élément d'information IPFIX. Elles correspondent aux unités implicitement définies dans les définitions d'élément d'information de la Section 5 du modèle d'informations IPFIX [RFC5102] ; voir dans ce paragraphe plus d'informations sur les types décrits ci-dessous. Ce champ peut prendre les valeurs du Tableau  3 ci-dessous ; la valeur spéciale 0x00 (aucun) est utilisée pour noter que le champ n'a pas d'unité.

Valeur	Nom	Notes
0	aucun
1	bits
2	octets
3	paquets
4	flux
5	secondes
6	millisecondes
7	microsecondes
8	nanosecondes
9	mots de 4 octets	pour la longueur d'en-tête IPv4
10	messages	pour le rapport de fiabilité
11	bonds	pour le TTL
12	entrées	pour la pile d'étiquettes MPLS

Tableau 3 : Valeurs des unités d'IE

Ces types sont enregistrés dans le sous registre "Unités d'élément d'information IPFIX" de l'IANA ; de nouveaux types peuvent être ajoutés sur la base du "premier arrivé, premier servi" [RFC5226].

Type de données abstrait : unsigned16
ElementId : 345
Statut : courant
Référence : Section 5 du modèle d'informations IPFIX [RFC5102]

 	3.8	privateEnterpriseNumber
Description : numéro d'entreprise privée, alloué par l'IANA. Dans le contexte d'un enregistrement de type d'élément d'information, cet élément peut être utilisé avec l'élément informationElementId pour limiter la portée des propriétés à un élément d'information spécifique. Pour exporter les informations de type sur un élément d'information alloué par l'IANA, on règle le privateEnterpriseNumber à 0, ou on n'exporte pas le privateEnterpriseNumber dans l'enregistrement de type. Pour exporter les informations de type sur un élément d'information spécifique d'entreprise, on exporte le numéro d'entreprise dans le privateEnterpriseNumber, et on exporte le numéro d'élément d'information avec le bit "Enterprise" à zéro dans le informationElementId. Le bit "Enterprise" dans l'élément d'information informationElementId associé DOIT être ignoré par le processus de collecte.

Type de données abstrait : unsigned32
Sémantique du type de données : identifiant
ElementId : 346
Statut : courant
Référence: paragraphes 3.2 et 3.4.1 du protocole IPFIX [RFC5101] ; paragraphe 8.2.3 du modèle d'information PSAMP [RFC5477].

 	3.9	Gabarit d'options de type d'élément d'information
L'élément d'information Gabarit d'options de type rattache les informations de type aux éléments d'information utilisés dans les enregistrements de gabarit, dont la portée est un domaine d'observation au sein d'une session de transport. Cela fournit un mécanisme pour représenter un modèle d'informations IPFIX en ligne avec un flux de messages IPFIX. Les enregistrements de données décrits par ce gabarit sont appelés des enregistrements de type d'élément d'information.

Dans les déploiements dans lesquels l'interopérabilité entre mises en œuvre de fabricants IPFIX est importante, un processus d'exportation qui exporte des données utilisant des gabarits contenant des éléments d'information spécifiques d'entreprise DEVRAIT exporter un enregistrement de type d'élément d'information pour chaque élément d'information spécifique d'entreprise qu'il exporte. Les processus de collecte PEUVENT utiliser ces enregistrements de type pour améliorer le traitement des éléments d'information spécifiques d'entreprise inconnus. Les processus d'exportation qui utilisent des éléments d'information spécifiques d'entreprise pour mettre en œuvre des caractéristiques propriétaires PEUVENT omettre les enregistrements de type pour ces éléments d'information.

Les enregistrements de type d'élément d'information DOIVENT être traités par les processus de collecte comme ayant la portée de la session de transport dans laquelle ils sont envoyés ; cette facilité n'est pas destinée à fournir une méthode pour la définition permanente des éléments d'information.

De même, pour des raisons de sécurité, les informations de type pour un élément d'information donné NE DOIVENT PAS être redéfinies par les enregistrements de type d'élément d'information, et un processus de collecte NE DOIT PAS permettre qu'un enregistrement de type d'élément d'information remplace sa propre définition interne d'un élément d'information. Les enregistrements de type d'élément d'information NE DEVRAIENT PAS être dupliqués dans un domaine d'observation donné au sein d'une session de transport. Une fois qu'un enregistrement de type d'élément d'information a été exporté pour un élément d'information donné au sein d'une session de transport donnée, tous les enregistrements de type suivants pour cet élément d'information DOIVENT être identiques. Les éléments d'information pour lesquels un processus de collecte reçoit des significations ou informations de type différentes DOIVENT être ignorés.

Noter que alors que ce gabarit PEUT être utilisé pour exporter des informations sur tout élément d'information, y compris ceux enregistrés par l'IANA, les processus d'exportation NE DEVRAIENT PAS exporter des enregistrements de type qui pourraient être raisonnablement supposés dupliquer des informations de type disponibles au processus de collecte. Ce mécanisme n'est pas destiné à remplacer les processus d'exportation et de collecte qui mettent à jour des changements du registre de l'IANA ; un tel mécanisme de mise à jour sort du domaine d'application du présent document.

Le gabarit DEVRAIT contenir les éléments d'information du Tableau 4, ci-dessous, comme défini dans le modèle d'information PSAMP [RFC5477] et dans le présent document.

IE	Description
informationElementId [portée]	Identifiant d'élément d'information de l'élément d'information décrit par cet enregistrement de type. Cet élément d'information DOIT être défini comme un champ Scope. Voir dans le modèle d'information PSAMP [RFC5477] la définition du champ.
privateEnterpriseNumber [portée]	Numéro d'entreprise privée de l'élément d'information décrit par cet enregistrement de type. Cet élément d'information DOIT être défini comme un champ Scope.
informationElementDataType	Type de mémorisation de l'élément d'information spécifié.
informationElementSemantics	Type de sémantique de l'élément d'information spécifié.
informationElementUnits	Unités de l'élément d'information spécifié. Cet élément DEVRAIT être omis si l'élément d'information est une quantité sans unités, ou pas une quantité ni un compteur.
informationElementRangeBegin	Extrémité inférieure de la gamme des valeurs acceptables pour l'élément d'information spécifié. Cet élément DEVRAIT être omis si le début de la gamme acceptable d'éléments d'information est définie par son type de données.
informationElementRangeEnd	Extrémité supérieure de la gamme des valeurs acceptables pour l'élément d'information spécifié. Cet élément DEVRAIT être omis si la fin de la gamme acceptable d'éléments d'information est définie par son type de données.
informationElementName	Nom de l'élément d'information spécifié.
informationElementDescription	Description lisible par l'homme de l'élément d'information spécifié. Cet élément PEUT être omis dans l'intérêt de l'efficacité de l'exportation.

Tableau 4 : Options de type d'IE

 	3.10	Restrictions sur le type et la sémantique des données
Noter que les valeurs de informationElementSemantics définies au paragraphe 3.2 de la [RFC5102] sont principalement destinées à différencier l'interprétation du sens des valeurs numériques, et que toutes les combinaisons des éléments d'information informationElementDataType et informationElementSemantics ne sont pas valides ; par exemple, un compteur ne peut pas être codé comme une adresse IPv4. Les valeurs suivantes sont acceptables pour informationElementSemantics :

o	Toute valeur est valide pour les informationElementDataType non signées ("unsigned8", "unsigned16", "unsigned32", ou "unsigned64").

o	Toute valeur sauf "flags" est valide pour les informationElementDataType signées ("signed8", "signed16", "signed32", ou "signed64").

o	Toute valeur sauf "identifier" ou "flags" est valide pour les informationElementDataType en virgule flottante ("float32" ou "float64").

o	Seul "default" est valide pour toutes les autres valeurs de informationElementDataType ("octetArray", "boolean", "macAddress", "string", "dateTimeSeconds", "dateTimeMilliseconds", "dateTimeMicroseconds", "dateTimeNanoseconds", "ipv4Address", ou "ipv6Address").

Les enregistrements de type d'élément d'information contenant des combinaisons invalides de informationElementSemantics et informationElementDataType NE DOIVENT PAS être envoyés par les processus d'exportation, et DOIVENT être ignorés par les processus de collecte.

Les futures actions de normalisation qui modifient le sous registre des types de données d'élément d'information ou le sous registre de sémantique d'élément d'information devraient contenir une section de restrictions sur les types et la sémantique des données comme celle-ci pour définir les combinaisons admissibles d'informations de type et de sémantique.

 	4.	Considérations sur la sécurité

Les mêmes considérations sur la sécurité que pour le protocole IPFIX [RFC5101] s'appliquent.

De plus, il faut faire attention au traitement des enregistrements de type d'élément d'information au processus de collecte. Les règles de préséance des informations de type définies ci-dessus (la connaissance actuelle du processus de collecte outrepasse les enregistrements de type ; les types ne sont pas redéfinissables durant une session) sont destinées à minimiser l'opportunité pour un attaquant de redéfinir dans une intention malveillante le modèle de données.

Noter que les enregistrements de type d'élément d'information peuvent contenir deux chaînes décrivant les éléments d'information : informationElementName et informationElementDescription. Les chaînes IPFIX sur le réseau sont de longueur fixée à l'avance et codées en UTF-8 [RFC3629], le plus souvent au sein d'un élément d'information IPFIX de longueur variable, qui atténue le risque d'attaques de chaînes non terminées contre des processus de collecte IPFIX. Cependant, on devrait quand même faire attention quand on traite des chaînes au sein du système de types du processus de collecte.

D'abord, les processus de collecte devraient porter une attention particulière aux tailles de mémoire tampon qui convertissent des chaînes de longueur fixe en chaînes terminée par un caractère nul. Les processus d'exportation NE DOIVENT PAS exporter, et les processus de collecte DOIVENT ignorer, tout contenu de informationElementName ou informationElementDescription qui contient des caractères nuls (U+0000) afin de s'assurer de la cohérence des longueurs de mémoire tampon et des chaînes.

Aussi, noter qu'il n'y a pas de limite à la longueur de chaîne IPFIX au delà de celle inhérente au protocole. La longueur maximum de chaîne IPFIX est de 65512 octets (longueur maximum de message (65535) moins l'en-tête de message (16) moins l'en-tête Set (4) moins le champ Longueur variable (3)).

Précisément, bien que le informationElementName de tous les éléments d'information de l'IANA au moment de la rédaction soit de moins d'environ 40 octets, et que la informationElementDescription soit de moins de 4096 octets, un de ces éléments d'information peut contenir des chaînes de jusqu'à 65512 octets de long.

 	5.	Considérations relatives à l'IANA

Le présent document spécifie plusieurs nouveaux éléments d'information IPFIX dans le registre des éléments d'information IPFIX défini à la Section3. L'IANA a alloué les numéros d'élément d'information suivants pour les éléments d'information respectifs comme spécifié ci-dessous :

o	Numéro 339 pour l'élément d'information informationElementDataType

o	Numéro 340 pour l'élément d'information informationElementDescription

o	Numéro 341 pour l'élément d'information informationElementName

o	Numéro 342 pour l'élément d'information informationElementRangeBegin

o	Numéro 343 pour l'élément d'information informationElementRangeEnd

o	Numéro 344 pour l'élément d'information informationElementSemantics

o	Numéro 345 pour l'élément d'information informationElementUnits

o	Numéro 346 pour l'élément d'information privateEnterpriseNumber

L'IANA a créé un sous registre Type de données d'élément d'information pour les valeurs définies pour l'élément d'information informationElementDataType. Des entrées peuvent être ajoutées à ce sous registre sous la politique d'action de normalisation [RFC5226].

L'IANA a créé un sous registre Sémantique d'élément d'information pour les valeurs définies pour l'élément d'information informationElementSemantics. Des entrées peuvent être ajoutées à ce sous registre sous la politique d'action de normalisation [RFC5226].

L'IANA a créé un sous registre Unités d'élément d'information pour les valeurs définies pour l'élément d'information informationElementUnits. Des entrées peuvent être ajoutées à ce sous registre sur la base d'une revue d'expert [RFC5226].

 	6.	Remerciements

Merci à Paul Aitken et Gerhard Muenz pour leurs relectures détaillées, et à David Moore pour avoir le premier soulevé ce problème sur la liste de diffusion IPFIX. Merci au projet PRISM pour son soutien au présent travail.

 	7.	Références
 	7.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. DOI 10.17487/RFC2119, (MàJ par RFC8174)

[RFC2277]	H. Alvestrand, "Politique de l'IETF en matière de jeux de caractères et de langages", BCP 18, janvier 1998.

[RFC2482]	K. Whistler, G. Adams, "Étiquettes de langues dans un libellé Unicode", janvier 1999. (Info. Historique)

[RFC3629]	F. Yergeau, "UTF-8, un format de transformation de la norme ISO 10646", STD 63, novembre 2003, DOI 10.17487/RFC3629.

[RFC4646]	A. Phillips, M. Davis, "Étiquettes d'identification des langues", BCP0047 septembre 2006. (Remplacée par RFC5646)

[RFC5101]	B. Claise, éd., "Spécification du protocole d'exportation d'informations de flux IP (IPFIX) pour l'échange d'informations de flux de trafic IP", janvier 2008. (P.S.) (Obsolète, voir RFC7011, STD77) 

[RFC5102]	J. Quittek et autres, "Modèle d'informations pour l'exportation d'informations de flux IP", janvier 2008. (P.S.) (Remplacée par RFC7012)

[RFC5226]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, mai 2008. (Remplace RFC2434 ; remplacée par RFC8126) 

[RFC5477]	T. Dietz et autres, "Modèle d'information pour l'exportation d'échantillonnage de paquet", mars 2009. (P.S.)

 	7.2	Références pour information

[RFC3917]	J. Quittek, T. Zseby, B. Claise, S. Zander, "Exigences pour l'exportation d'informations de flux IP (IPFIX)", octobre  2004. (Information)

[RFC5470]	G. Sadasivan et autres, "Architecture pour l'exportation d'informations de flux IP", mars 2009. (Information)

 	Appendice A.	Exemples

L'exemple suivant illustre comment le mécanisme d'extension d'informations de type défini dans le présent document peut être utilisé pour décrire la sémantique des éléments d'information spécifiques d'entreprise. Les éléments d'information utilisés dans cet exemple sont comme suit :

o	initialTCPFlags, un exemple d'IE privé 14, 1 octet, les fanions TCP sur le premier paquet TCP dans le flux.

o	unionTCPFlags, un exemple d'IE privé 15, 1 octet, l'union des fanions TCP sur tous les paquets après le premier paquet TCP dans le flux.

Un processus d'exportation qui exporte des flux contenant ces éléments d'information pourrait utiliser un gabarit comme le suivant :

                     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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Set ID = 2           |        Longueur =  52         |
+---------------+---------------+---------------+---------------+
|      ID de gabarit = 256      |      Compte de champs = 9     |
+---------------+---------------+---------------+---------------+
|0| flowStartSeconds        150 |     Longueur de champ =  4    |
+-+-------------+---------------+---------------+---------------+
|0| sourceIPv4Address         8 |     Longueur de champ =  4    |
+-+-------------+---------------+---------------+---------------+
|0| destinationIPv4Address   12 |     Longueur de champ =  4    |
+-+-------------+---------------+---------------+---------------+
|0| sourceTransportPort       7 |     Longueur de champ =  2    |
+-+-------------+---------------+---------------+---------------+
|0| destinationTransportPort 11 |     Longueur de champ =  2    |
+-+-------------+---------------+---------------+---------------+
|0| octetTotalCount          85 |     Longueur de champ =  4    |
+-+-------------+---------------+---------------+---------------+
|1| (initialTCPFlags)        14 |     Longueur de champ =  1    |
+-+-------------+---------------+---------------+---------------+
|                  Numéro d'entreprise privée                   |
+---------------+---------------+---------------+---------------+
|1| (unionTCPFlags)          15 |     Longueur de champ =  1    |
+-+-------------+---------------+---------------+---------------+
|                  Numéro d'entreprise privée                   |
+---------------+---------------+---------------+---------------+
|0| protocolIdentifier        4 |     Longueur de champ =  1    |
+-+-------------+---------------+---------------+---------------+

Figure 1 : Gabarit avec IE spécifiques d'entreprise

Cependant, un processus de collecte recevant des ensembles de données décrits par ce gabarit peut seulement traiter les éléments d'information spécifiques d'entreprise comme des octets opaques ; spécifiquement, il n'y a pas de conseil au collecteur qu'ils contiennent des informations de fanion. Afin d'utiliser le mécanisme d'extension d'informations de type pour traiter ce problème, le processus d'exportation va d'abord exporter le gabarit d'options de type d'élément d'information décrit au paragraphe 3.9 ci-dessus :

                     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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Set ID = 3           |        Longueur =  26         |
+---------------+---------------+---------------+---------------+
|      ID de gabarit = 256      |      Compte de champs = 4     |
+---------------+---------------+---------------+---------------+
|  Compte de champ Scope = 2    |0| priv.EnterpriseNumber   346 |
+---------------+---------------+-+-------------+---------------+
|     Longueur de champ = 4     |0| informationElementId    303 |
+---------------+---------------+-+-------------+---------------+
|     Longueur de champ = 2     |0| inf.El.DataType         339 |
+---------------+---------------+-+-------------+---------------+
|     Longueur de champ = 1     |0| inf.El.Semantics        344 |
+---------------+---------------+-+-------------+---------------+
|     Longueur de champ = 1     |0| inf.El.Name             341 |
+---------------+---------------+-+-------------+---------------+
|   Longueur de champ = 65536   |
+---------------+---------------+

Figure 2 : Exemple de gabarit d'options de type d'élément d'information

Ensuite, le processus d'exportation va exporter deux enregistrements décrits par l'exemple de gabarit d'options de type d'élément d'information pour décrire les éléments d'information spécifiques d'entreprise :

                     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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Set ID = 257         |        Longueur =  50         |
+---------------+---------------+---------------+---------------+
|                  Numéro d'entreprise privée                   |
+---------------+---------------+---------------+---------------+
|X|         IE 14               |0x01 unsigned8 |0x05 fanions   |
+-+-------------+---------------+---------------+---------------+
|  15 longueur  |                                               |
+---------------+                                               |
|                      "initialTCPFlags"                        |
|                                                               |
+---------------+---------------+---------------+---------------+
|                  Numéro d'entreprise privée                   |
+---------------+---------------+---------------+---------------+
|X|         IE 15               |0x01 unsigned8 |0x05 flags     |
+---------------+---------------+---------------+---------------+
| 13 longueur   |                                               |
+---------------+        "unionTCPFlags"                        |
|                               +---------------+---------------+
|                               |
+---------------+---------------+

Figure 3 : Exemple d'enregistrement de type

 	Adresse des auteurs

Elisa Boschi	Brian Trammell	
Hitachi Europe	Hitachi Europe	
c/o ETH Zurich	c/o ETH Zurich	
Gloriastrasse 35	Gloriastrasse 35	
8092 Zurich	8092 Zurich	
Switzerland	Switzerland	
mél : elisa.boschi@hitachi-eu.com	mél : brian.trammell@hitachi-eu.com	

Lutz Mark	Tanja Zseby	
Fraunhofer Institute for Manufacturing Technology	Fraunhofer Institute for Open Communication Systems	
and Applied Materials Research	Kaiserin-Augusta-Allee 31	
Wiener Str. 12	10589 Berlin	
28359 Bremen	Germany	
Germany	mél : tanja.zseby@fokus.fraunhofer.de	
mél : lutz.mark@ifam.fraunhofer.de