Groupe de travail Réseau	T. Clausen, LIX, Ecole Polytechnique
Request for Comments: 5497	C. Dearlove, BAE Systems ATC
Catégorie : Sur la voie de la normalisation	mars 2009
Traduction Claude Brière de L'Isle

Représentation de valeurs de temps multiples dans les réseaux mobiles ad hoc (MANET)

Statut de ce mémoire
Le présent document spécifie un protocole sur la voie de la 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 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.

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.

Résumé
Le présent document décrit une structure générale et souple de TLV (Type-Longueur-Valeur) pour représenter les valeurs de temps, comme un intervalle ou une durée, en utilisant le format généralisé de paquet/message de réseau ad hoc mobile (MANET, Mobile Ad hoc NETwork). Il définit deux TLV Message et deux TLV Bloc d'adresse pour représenter les temps de validité et d'intervalles pour les protocoles d'acheminement de MANET.
Table des matières
1. Introduction	2
1.1 Motivation et raison	2
2. Terminologie	3
3. Déclaration d'applicabilité	3
4. Vue d'ensemble et fonctionnement du protocole	4
5. Représentation du temps	4
6. Structure générale de TLV de temps	4
6.1 TLV de temps d'une seule valeur	5
6.2 TLV de temps multi-valeurs	5
7. TLV Message	6
7.1 TLV INTERVAL_TIME	6
7.2 TLV VALIDITY_TIME	6
8. TLV Bloc d'addresses	6
8.1 TLV INTERVAL_TIME	6
8.2 TLV VALIDITY_TIME	7
9. Considérations relatives à l'IANA	7
9.1 Revue d'expert : lignes directrices d'évaluation	7
9.2 Types de TLV Message	7
9.3 Types de TLV Bloc d'addresses	7
10. Considérations sur la sécurité	8
11. Références	8
11.1 Références normatives	8
11.2 Références pour information	8
Appendice A. Remerciements	8
Adresse des auteurs	8

 	1.	Introduction

Le format de paquet/message généralisé [RFC5444] spécifie un format de signalisation que les protocoles d'acheminement de MANET peuvent employer pour échanger des informations de protocole. Ce format présente la capacité d'exprimer et associer des attributs aux paquets, messages, ou adresses, au moyen d'un mécanisme général de TLV (type-longueur-valeur).

Le présent document spécifie une structure générale de TLV de temps, qui peut être utilisée par tout protocole d'acheminement de MANET qui a besoin d'exprimer soit une seule valeur de temps, soit un ensemble de valeurs de temps avec chaque valeur de temps associée à une gamme de comptes de bonds, comme fourni par l'en-tête de message de la [RFC5444]. Cela permet au nœud receveur de déterminer une seule valeur de temps si il connaît son compte de bonds depuis le nœud d'origine ou si le TLV de temps spécifie une seule valeur de temps.

Une valeur de temps n'est pas, dans ce contexte, un "instant absolu", mais plutôt un intervalle ou une durée. Une instance de TLV de temps peut donc exprimer un intervalle ou une durée, comme "10 secondes".

Le présent document spécifie aussi deux types de TLV Message, qui utilisent la structure de TLV proposée. Ces types de TLV sont INTERVAL_TIME et VALIDITY_TIME, qui spécifient, respectivement, le temps maximum avant qu'un autre message du même type que ce message provenant de la même origine devrait être reçu, et la durée pendant laquelle les informations de ce message sont valides après réception. Noter que, si les deux sont présents, alors le dernier va normalement être supérieur au premier afin de permettre une éventuelle perte de message.

Le présent document spécifie aussi deux types de TLV Bloc d'adresses, qui utilisent la structure de TLV proposée. Ces types de TLV sont INTERVAL_TIME et VALIDITY_TIME, définis de façon équivalente aux deux TLV Message de même nom.

 	1.1	Motivation et raison
La structure de TLV Temps, spécifiée dans ce document, est destinée à être utilisée comme un composant dans un protocole d'acheminement de MANET, par exemple, pour indiquer l'espacement attendu entre des transmissions successives d'un type de message donné, en incluant un TLV Temps dans les messages transmis.

Certain protocoles d'acheminement de MANET peuvent employer un très court espacement pour certains messages et de très longs espacements pour d'autres, ou peuvent changer le taux de transmission de message selon le comportement observé. Par exemple, si un réseau observé à un instant donné présente une topologie très dynamique, un espacement de messages très court (inférieur à la seconde) pourrait être approprié, tandis que si le réseau est observé plus tard comme stable, un espacement de messages de plusieurs heures peut devenir approprié. Différents protocoles d'acheminement de MANET et différents déploiements de protocoles d'acheminement de MANET peuvent avoir des exigences de granularité et de limites différentes sur les espacements plus courts et plus longs entre des transmissions de messages successives.

De plus, les déploiements de protocole d'acheminement de MANET utilisent normalement des interfaces de réseau sans fil à bande passante limitée, et préfèrent donc jouer sur la complexité de calcul pour économiser sur le nombre de bits transmis. C'est pratique dans ce cas, parce que les usages prévus des TLV Temps, y compris les exemples spécifiés de temps d'intervalle de message et de durée de validité d'informations, n'exigent pas des valeurs de temps d'une haute précision.

La structure de TLV Temps, spécifiée dans ce document, porte ces caractéristiques en :
o	codant les valeurs de temps, comme un intervalle ou une durée, dans un champ de 8 bits ;
o	permettant que ces valeurs de temps aillent de "très petit" (par exemple, 1/1024 seconde) à "très long" (par exemple, 45  jours) ;
o	permettant à un protocole d'acheminement de MANET, ou un déploiement, de paramétrer cela (par exemple, pour atteindre une plus fine granularité aux dépens d'une plus faible limite supérieure) par un seul paramètre, C.

Le paramètre C doit être le même pour tous les routeurs MANET dans le même déploiement.

Le mécanisme de TLV spécifié dans la [RFC5444] permet d'associer une "valeur" à un paquet, un message, ou des adresses. La structure de données pour ce faire -- le TLV -- est identique dans chacun des trois cas ; cependant, la position du TLV dans un paquet reçu permet de déterminer si ce TLV est un "TLV de paquet" (il apparaît dans l'en-tête de paquet, avant tout message) un "TLV de message" (il apparaît dans le TLV Bloc qui immédiatement un en-tête de message) ou un "TLV Bloc d'adresses" (il apparaît dans le TLV Bloc qui suit immédiatement un bloc d'adresses).

Bien que les TLV puissent être de structure identique, ce qu'ils expriment peut être différent. Ceci est déterminé à partir de la sorte (paquet, message, ou bloc d'adresses) et du type du TLV. Par exemple, un TLV pourrait associer une durée de vie à une adresse, un autre un numéro de séquence de contenu à un message, et un autre une signature cryptographique à un paquet. Pour cette raison, la [RFC5444] spécifie des registres séparés pour les types de TLV Paquet, Message, et Bloc d'adresses, et elle ne spécifie aucune structure dans le champ Valeur du TLV.

Les TLV définis dans le présent document expriment, essentiellement, que "ces informations vont être rafraîchies dans X secondes" et que "ces informations sont valides pour X secondes après réception", chacun permettant que les "X secondes" soient spécifiées comme une fonction du nombre de bonds à partir du générateur de l'information. Le présent document spécifie un format général qui permet d'exprimer et coder cela comme le champ Valeur d'un TLV. Cette représentation utilise une représentation compacte (8 bits) du temps, car la taille de message est un problème dans de nombreux MANET, et la précision et la gamme offertes sont appropriées pour les protocoles d'acheminement de MANET.

Un TLV de ce format peut être utilisé pour des paquets, des messages, ou des adresses. Par exemple, un protocole d'acheminement de MANET proactif qui rapporte périodiquement des informations d'état de liaison pourrait inclure un TLV de ce format comme un TLV Message. Cela peut indiquer une périodicité différente dans des portées différentes (assez fréquemment jusqu'à quelques bonds, moins fréquemment au delà) parce que certains messages peuvent être envoyés avec une portée limitée, comme spécifié dans la [RFC5444]. Un protocole d'acheminement de MANET réactif pourrait inclure un TLV de ce format comme TLV Bloc d'adresses pour rapporter la durée de vie des chemins vers des adresses individuelles.

En plus de définir le format général comme mentionné ci-dessus, le présent document demande à l'IANA des allocations pour les TLV INTERVAL_TIME et VALIDITY_TIME. Ces allocations de l'IANA sont demandées dans le présent document afin d'éviter des inter dépendances entre des protocole de MANET par ailleurs sans relations et afin de ne pas épuiser les espaces de types de TLV en ayant les différents protocoles qui demandent des types pour des structures de données essentiellement identiques. Seuls les TLV Message et les TLV Bloc d'adresses sont demandés, car ce sont ceux pour lesquels un besoin a été démontré.

 	2.	Terminologie

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

De plus, le présent document utilise la terminologie de la [RFC5444], et introduit les termes suivants :

compte de bonds : nombre de bonds depuis l'origine du message jusqu'au receveur du message. Ceci est défini comme égal au champ <msg-bond-compte> dans l'élément <msg-en-tête> défini dans la [RFC5444], si il est présent, après avoir été incrémenté à réception. Si le champ <msg-bond-compte> n'est pas présent, ou dans un TLV Paquet, le compte de bonds est alors défini comme égal à 255.

valeur de temps : un temps, mesuré en secondes.

code de temps : champ de 8 bits, représentant une valeur de temps.

 	3.	Déclaration d'applicabilité

La structure de TLV décrite dans ce document est applicable chaque fois qu'une seule valeur de temps, ou qu'une valeur de temps qui varie avec le nombre de bonds à partir de l'origine d'un message, est exigée dans un protocole qui utilise le format généralisé de paquet/message de MANET [RFC5444].

Des exemples de valeurs de temps qui peuvent être incluses dans un message de protocole sont :

o	L'intervalle de temps maximum jusqu'à ce que le prochain message de même type soit généré par le nœud générateur du message.

o	La durée de validité des informations auxquelles la valeur de temps est associée.

L'une et l'autre peuvent varier avec le compte de bonds entre les et nœuds d'origine et de réception, par exemple, si des messages de même type sont envoyés avec des limites de bonds différentes comme défini dans la [RFC5444].

Des parties du présent document ont été généralisées à partir de matériaux du protocole d'acheminement de MANET proactif OLSR (Optimized Link State Routing Protocol, protocole d'acheminement d'état de liaison optimisé) [RFC3626].

 	4.	Vue d'ensemble et fonctionnement du protocole

Le présent document ne spécifie pas un protocole ni ne rend obligatoire de comportement spécifique de nœud ou de protocole. Il mentionne plutôt les mécanismes pour coder les valeurs de temps en utilisant le mécanisme de TLV de la [RFC5444].

 	5.	Représentation du temps

Le présent document spécifie une structure de TLV dans laquelle les valeurs de temps sont chacune représentées dans un code de temps de 8 bits, dont un ou plusieurs peuvent être utilisés dans un champ <valeur> de TLV. De ces 8 bits, les trois bits de moindre poids représentent la mantisse (a), et les 5 bits de poids fort représentent l'exposant (b), de sorte que :
o	valeur de temps = (1 + a/8) * 2^b * C
o	code de temps = 8 * b + a

Tous les nœuds dans le MANET DOIVENT utiliser la même valeur de la constante C, qui va être spécifiée en secondes, comme vont l'être toutes les valeurs de temps. C DOIT être supérieur à 0 seconde. Noter que les valeurs de temps ascendantes du code de temps représentent des valeurs de temps ascendantes ; les valeurs de temps peuvent donc être comparées par la comparaison des codes de temps.

Un algorithme pour calculer le code de temps représentant la plus petite valeur de temps représentable non inférieure à la valeur de temps t est :
1.	trouver le plus grand entier b tel que t/C ≥ 2^b ;
2.	régler a = 8 * (t / (C * 2^b) - 1), arrondi à l'entier supérieur ;
3.	si a = 8, alors régler b = b + 1 et régler a = 0 ;
4.	 si 0 ≤ a ≤ 7, et 0 ≤ b ≤ 31, alors la valeur de temps exigée peut être représentée par le code de temps 8 * b + a, autrement, elle ne le peut pas.

La valeur de temps minimum qui peut être représentée de cette manière est C. La valeur de temps maximum qui peut être représentée de cette manière est 15 * 2^28 * C, ou environ 4,0 * 10^9 * C. Si, par exemple, C = 1/1024 seconde, c'est alors environ 45 jours.

Un protocole qui utilise cette représentation du temps DOIT définir la valeur de C. Un protocole qui utilise la présente spécification PEUT spécifier que la valeur de temps avec tous les bits à zéro (0) représente une valeur de temps de zéro et/ou que la valeur de temps avec tous les bits à un (255) représente une valeur de temps de durée infinie.

 	6.	Structure générale de TLV de temps

La structure de données suivante permet la représentation d'une seule valeur de temps, ou d'une valeur de temps par défaut plus des paires de (valeurs de temps, comptes de bonds) pour quand des valeurs de temps dépendantes du compte de bonds sont exigées. Les valeurs de temps sont représentées comme des codes de temps, comme défini dans la Section 5. Cette structure de données <données de temps> est spécifiée en utilisant la syntaxe régulière d'expression de la [RFC5444], par :

<données de temps> = (<code de temps><compte de bonds>)*<code de temps>

où :

<code de temps> est un champ d'entier non signé de 8 bits contenant un code de temps comme défini dans la Section 5.

<compte de bonds> est un champ d'entier non signé de 8 bits qui spécifie un compte de bonds à partir de l'origine du message.

Une structure <données de temps> consiste donc en un nombre impair d'octets; avec un facteur de répétition de n pour les paires (temps, compte de bonds) dans la syntaxe régulière d'expression, elle contient 2n+1 octets. À réception, n est déterminé à partir de la longueur.

Un champ <données de temps> peut donc être représenté par :

<t_1><d_1><t_2><d_2> ... <t_i><d_i> ...  <t_n><d_n><t_default>

<d_1>, ... <d_n>, si elle est présente, DOIT être une séquence strictement croissante, avec <d_n> < 255. Alors, au compte de bonds depuis le nœud receveur jusqu'au nœud d'origine, la valeur de temps indiquée est celle représentée par le code de temps :
o  <t_1>, si n > 0 et compte de bonds ≤ <d_1>;
o  <t_i+1>, si n > 1 et <d_i> < compte de bonds ≤ <d_i+1> pour tout i tel que 1 ≤ i < n;
o  <t_default> autrement, c'est-à-dire, si n = 0 ou compte de bonds > <d_n>.

Si elle est incluse dans un message sans un champ <msg-hop-count> dans son en-tête de message, ou dans un TLV Paquet, alors la forme de cette structure de données avec un seul code de temps dans les <données de temps> (c'est-à-dire, n = 0) DEVRAIT être utilisée.

 	6.1	TLV de temps d'une seule valeur
L'objet d'un TLV Temps d'une seule valeur est de permettre qu'une seule valeur de temps soit déterminée par un nœud recevant une entité contenant le TLV Temps, sur la base de son compte de bonds depuis l'entité d'origine. Le TLV Temps peut contenir des informations qui permettent que cette valeur de temps soit une fonction du compte de bonds ; donc, différents nœuds receveurs peuvent déterminer des valeurs de temps différentes.

Un TLV Temps d'une seule valeur peut être un TLV Paquet, Message, ou Bloc d'adresses.

Un TLV Temps qui a le fanion "tismultivalue" à zéro (0) dans son champ <tlv-fanions>, comme défini dans la [RFC5444], contient une seule <données de temps>, comme défini ci-dessus, dans son champ <valeur>. Pour un tel TLV Temps :
o	Le champ <longueur> dans le TLV DOIT contenir la valeur 2n+1, n étant le nombre de paires (valeur de temps, compte de bonds) dans le TLV Temps.
o	Le nombre de paires (valeur de temps, compte de bonds) DOIT être identifié par l'inspection du champ <longueur> du TLV. Le nombre de ces paires, n, est : n = (<longueur> - 1) / 2. Ce DOIT être une valeur d'entier.

 	6.2	TLV de temps multi-valeurs
L'objet d'un TLV Temps multi-valeurs est d'associer un ensemble de structures <données de temps> à un ensemble d'adresses de taille identique, comme décrit dans la [RFC5444]. Pour chacune de ces structures <données de temps>, une seule valeur de temps peut être déterminée par un nœud recevant une entité contenant le TLV Temps, sur la base de son compte de bonds depuis l'entité d'origine. Le TLV Temps peut contenir des informations qui permettent que la valeur de temps soit une fonction du compte de bonds, et donc que différents nœuds receveurs puissent déterminer des valeurs de temps différentes.

Les TLV Temps multi-valeurs DOIVENT être des TLV Bloc d'adresses. Un TLV Temps multi-valeurs NE DOIT PAS être un TLV Paquet ou Message.

Un TLV de temps qui a le fanion "tismultivalue" établi (1) dans son champ <tlv-fanions>, comme défini dans la [RFC5444], contient une séquence de structures <données de temps>, comme défini ci-dessus, dans son champ <valeur>. Pour un tel TLV Temps :

o	Le champ <longueur> dans le TLV DOIT contenir la valeur m * (2n+1), n étant le nombre de paires (valeur de temps, compte de bonds) dans le TLV Temps, et m étant nombre-valeurs comme défini dans la [RFC5444].

o	Le nombre de structures <données de temps> incluses dans le champ <valeur> est égal aux nombre-valeurs comme défini dans la [RFC5444].

o	Le nombre de paires (valeur de temps, compte de bonds) dans chaque structure <données de temps> DOIT être le même, et DOIT être identifié en inspectant le champ <longueur> dans le TLV et en utilisant nombre-valeurs comme défini dans la [RFC5444]. Le nombre de ces paires dans chaque structure <données de temps>, n, est :

*  n := ((<longueur> / nombre-valeurs) - 1) / 2

Ce DOIT être une valeur d'entier. La liste des valeurs de compte de bonds PEUT être différente.

 	7.	TLV Message

Deux TLV Message sont définis, pour signaler l'intervalle de message (INTERVAL_TIME) et la durée de validité de message (VALIDITY_TIME).

 	7.1	TLV INTERVAL_TIME
Un TLV INTERVAL_TIME est un TLV Message qui définit le temps maximum avant qu'un autre message de même type que ce message provenant du même générateur devrait être reçu. Cet intervalle de temps PEUT être spécifié comme dépendant du compte de bonds depuis l'origine. (Ceci est approprié si les messages sont envoyés avec des limites de bonds différentes afin que les nœuds receveurs de plus grands comptes de bonds aient un intervalle de temps accru.)

Un message NE DOIT PAS inclure plus d'un TLV INTERVAL_TIME.

Un TLV INTERVAL_TIME est un exemple de TLV Temps spécifié dans la Section 5.

 	7.2	TLV VALIDITY_TIME
Un TLV VALIDITY_TIME est un TLV Message qui définit la durée de validité des informations portées dans le message dans lequel le TLV est contenu. Après ce temps, le nœud receveur DOIT considérer que le contenu du message n'est plus valide (sauf si il est répété dans un message ultérieur). La durée de validité d'un message PEUT être spécifiée comme dépendant du compte de bonds depuis l'origine. (Ceci est approprié si les messages sont envoyés avec des limites de bonds différentes afin que les nœuds receveurs à de plus grands comptes de bonds reçoivent moins fréquemment les informations et doivent les traiter comme valides pendant plus longtemps.)

Un message NE DOIT PAS inclure plus d'un TLV VALIDITY_TIME.
Un TLV VALIDITY_TIME est un exemple de TLV Temps spécifié à la Section 5.

 	8.	TLV Bloc d'adresses

Deux TLV Bloc d'adresses sont définis, pour signaler l'intervalle d'annonce d'adresses (INTERVAL_TIME) et la durée de validité d'adresse (VALIDITY_TIME).

 	8.1	TLV INTERVAL_TIME
Un TLV INTERVAL_TIME est un TLV Bloc d'adresses qui définit le temps maximum avant que cette adresse provenant de la même origine devrait être reçue à nouveau. Cet intervalle de temps PEUT être spécifié comme dépendant du compte de bonds depuis l'origine. (Ceci est approprié si les adresses sont contenues dans des messages envoyés avec des limites de bonds différentes afin que les nœuds receveurs à de plus grands comptes de bonds aient un intervalle de temps accru.)

Un protocole qui utilise ce TLV et le même TLV Message désigné DOIT spécifier comment interpréter le cas où tous les deux sont présents (normalement, que le premier outrepasse le dernier pour les adresses qui sont couvertes par le premier).
Un TLV INTERVAL_TIME est un exemple de TLV Temps spécifié à la Section 5.

 	8.2	TLV VALIDITY_TIME
Un TLV VALIDITY_TIME est un TLV Bloc d'adresses qui définit la durée de validité des adresses auxquelles le TLV est associé. Après ce délai, le nœud receveur DOIT considérer que les adresses ne sont plus valides (sauf si elles sont répétées dans un message ultérieur). La durée de validité d'une adresse PEUT être spécifiée comme dépendant du compte de bonds depuis l'origine. (Ceci est approprié si les adresses sont contenues dans des messages envoyés avec des limites de bonds différentes afin que les nœuds receveurs à de plus grands comptes de bonds reçoivent les informations moins fréquemment et doivent les traiter comme valides plus longtemps.)

Un protocole qui utilise ce TLV et le même TLV Message désigné DOIT spécifier comment interpréter le cas où les deux  sont présents (normalement, que le premier outrepasse le dernier pour les adresses qui sont couvertes par le premier).
Un TLV VALIDITY_TIME est un exemple de TLV Temps spécifié à la Section 5.

 	9.	Considérations relatives à l'IANA

La présente spécification définit deux types de TLV Message, qui ont été alloués dans le registre des "Types de TLV Message alloués" de la [RFC5444] comme spécifié dans le Tableau 1, et deux types de TLV Bloc d'adresses, qui ont été alloués du registre des "Types de TLV Bloc d'adresses" de la [RFC5444] comme spécifié dans le Tableau 2.
L'IANA a alloué la même valeur numérique au type de TLV Message et au type de TLV Bloc d'adresses avec le même nom.

 	9.1	Revue d'expert : lignes directrices d'évaluation
Pour les registres d'extensions de type de TLV où une revue par expert est exigée, l'expert désigné DEVRAIT prendre en considération les mêmes recommandations générales que celles spécifiées dans la [RFC5444].

 	9.2	Types de TLV Message
Nom	Type	Extension de type	Description	
INTERVAL_TIME	0	0	Durée maximum avant qu'un autre message de même type que ce  message provenant de la même origine devrait être reçu	
Non alloué	0	1-223	Revue par expert	
		224-255	Utilisation expérimentale	
VALIDITY_TIME	1	0	Temps depuis la réception du message durant lequel les informations contenues dans le message sont considérées comme valides	
Non alloué	1	1-223	Revue par expert	
		224-255	Utilisation expérimentale	

Tableau 1

 	9.3	Types de TLV Bloc d'addresses
Nom	Type	Extension de type	Description	
INTERVAL_TIME	0	0	Durée maximum avant qu'un autre message de même type que ce  message provenant de la même origine et contenant cette adresse devrait être reçu	
Non alloué	0	1-223	Revue par expert	
		224-255	Utilisation expérimentale	
VALIDITY_TIME	1	0	Temps depuis la réception de l'adresse durant lequel les informations concernant cette adresse sont considérées comme valides	
Non alloué	0	1-223	Revue par expert	
		224-255	Utilisation expérimentale	

Tableau 2

 	10.	Considérations sur la sécurité

Le présent document spécifie comment ajouter des structures de données (des TLV) qui fournissent des informations de temps aux paquets et messages spécifiés en utilisant la [RFC5444]. En particulier, des durées de validité des informations et des intervalles de rapports peuvent être ajoutés.

Les menaces générales sur la sécurité qui s'appliquent sont celles de la [RFC5444] et elles y sont décrites, avec les problèmes d'intégrité et de confidentialité. À l'égard de ceux-là, la modification d'un TLV Temps peut causer l'invalidation des informations de durée de validité, ou de l'intervalle de temps attendu. Cela peut causer des performances de protocole incorrectes. La modification ou l'ajout d'informations de temps peut ajouter à la charge de travail d'un protocole (en particulier si une courte durée de validité est spécifiée) et les exigences de mémorisation (en particulier si une longue durée de validité est spécifiée).

Pour contrer ces menaces, les suggestions de sécurité de la [RFC5444], d'utiliser l'authentification et le chiffrement, sont appropriées.

 	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)

[RFC5444]	T. Clausen et autres, "Format de paquet/message de réseau ad hoc mobile (MANET)", février 2009. (P.S.)

 	11.2	Références pour information

[RFC3626]	T. Clausen et P. Jacquet, éd., "Protocole d'acheminement d'état de liaison optimisé (OLSR)", octobre 2003. (Exp.)

 	Appendice A.	Remerciements
Les auteurs tiennent à remercier Brian Adamson et Justin Dean (tous deux de NRL) et Ian Chakeres (Motorola) de leurs contributions, et Alan Cullen (BAE Systems) et Jari Arkko (Ericsson, Finland) de leurs relectures attentives de la présente spécification.

 	Adresse des auteurs
Thomas Heide Clausen
LIX, Ecole Polytechnique, France
téléphone : +33 6 6058 9349
mél : T.Clausen@computer.org
URI : http://www.ThomasClausen.org/

Christopher Dearlove
BAE Systems Advanced Technology Centre
téléphone : +44 1245 242194
mél : chris.dearlove@baesystems.com
URI : http://www.baesystems.com/