Network Working Group T. Clausen
Request for Comments: 5497 LIX, Ecole Polytechnique
Category: Standards Track C. Dearlove
BAE Systems ATC
March 2009
Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Abstract
抽象
This document describes a general and flexible TLV (type-length-value structure) for representing time-values, such as an interval or a duration, using the generalized Mobile Ad hoc NETwork (MANET) packet/ message format. It defines two Message TLVs and two Address Block TLVs for representing validity and interval times for MANET routing protocols.
この文書では、そのような間隔または期間などの時間値を表す一般化されたモバイルアドホックネットワーク（MANET）は、パケット/メッセージ・フォーマットを使用するための一般的かつ柔軟なTLV（タイプ - 長さ - 値の構造）を記載しています。これは、MANETルーティングプロトコルのために有効とインターバル時間を表すための2つのメッセージのTLVと2つのアドレスブロックTLVを定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation and Rationale . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6
5. Representing Time . . . . . . . . . . . . . . . . . . . . . . 6
6. General Time TLV Structure . . . . . . . . . . . . . . . . . . 7
6.1. Single-Value Time TLVs . . . . . . . . . . . . . . . . . . 8
6.2. Multi-Value Time TLVs . . . . . . . . . . . . . . . . . . 9
7. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 10
7.2. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 10
8. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 10
8.1. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 10
8.2. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 11
9.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 12
9.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14
The generalized packet/message format [RFC5444] specifies a signaling format that MANET routing protocols can employ for exchanging protocol information. This format presents the ability to express and associate attributes to packets, messages, or addresses, by way of a general TLV (type-length-value) mechanism.
一般化されたパケット/メッセージフォーマット[RFC5444]はMANETルーティングプロトコルは、プロトコル情報を交換するために使用することができるシグナリング・フォーマットを指定します。このフォーマットは、発現する能力を提示し、会合は、一般的なTLV（タイプ - 長さ - 値）機構を介して、パケット、メッセージ、またはアドレスに属性。
This document specifies a general Time TLV structure, which can be used by any MANET routing protocol that needs to express either single time-values or a set of time-values with each time-value associated with a range of hop counts, as provided by the Message Header of [RFC5444]. This allows a receiving node to determine a single time-value if either it knows its hop count from the originator node or the Time TLV specifies a single time-value.
によって提供されるこのドキュメントは、単一の時間値またはホップカウントの範囲に関連付けられた各時間値と時間値のセットのいずれかを発現させるために必要なすべてのMANETルーティングプロトコルによって使用することができる一般的な時間TLV構造を、指定しますメッセージヘッダ[RFC5444]。これは、発信元ノードからそのホップカウントを知っているか、時間TLVは、単一の時間値を指定するいずれかの場合には単一の時間値を決定するために受信ノードを可能にします。
A time-value is, in this context, not an "absolute point in time", but rather an interval or a duration. An instance of a Time TLV can, therefore, express an interval or a duration such as "10 seconds".
時間値は、このコンテキストではなく、「時間における絶対的な点」で、むしろ間隔または期間。タイムTLVのインスタンスは、それ故、間隔または「10秒」などの持続時間を表現することができます。
This document also specifies two Message TLV Types, which use the TLV structure proposed. These TLV Types are INTERVAL_TIME and VALIDITY_TIME, specifying, respectively, the maximum time before another message of the same type as this message from the same originator should be received, and the duration for which the information in this message is valid after receipt. Note that, if both are present, then the latter will usually be greater than the former in order to allow for possible message loss.
この文書はまた、提案TLV構造を使用する2つのメッセージTLVタイプを、指定します。このTLVのタイプは、このメッセージ内の情報が受信した後有効であるため、同じ発信元からこのメッセージを受信しなければならないのと同じタイプの別のメッセージ、および持続時間前に、それぞれ、最大時間を指定し、INTERVAL_TIME及びVALIDITY_TIMEあります。両方が存在する場合、後者は、通常、可能なメッセージの損失を可能にするために、前者よりも大きくなることに留意されたいです。
This document also specifies two Address Block TLV Types, which use the TLV structure proposed. These TLV Types are INTERVAL_TIME and VALIDITY_TIME, defined equivalently to the two Message TLVs with the same names.
この文書はまた、提案TLV構造を使用する2つのアドレスブロックTLVタイプを、指定します。これらのTLVタイプは、同じ名前を持つ2つのメッセージのTLVと等価に定義され、INTERVAL_TIMEとVALIDITY_TIMEです。
The Time TLV structure, specified in this document, is intended to be used as a component in a MANET routing protocol, e.g., to indicate the expected spacing between successive transmissions of a given Message Type, by including a Time TLV in transmitted messages.
この文書で指定された時間TLV構造は、送信メッセージにタイムTLVを含むことによって、所与のメッセージ・タイプの連続する送信間の予想される間隔を示すために、例えば、MANETルーティングプロトコルの成分として使用されることを意図しています。
Some MANET routing protocols may employ very short spacing for some messages and very long spacing for others, or may change the message transmission rate according to observed behavior. For example, if a network is observed at some point in time to exhibit a highly dynamic topology, a very short (sub-second) message spacing could be appropriate, whereas if the network later is observed to stabilize, multi-hour message spacing may become appropriate. Different MANET routing protocols and different deployments of MANET routing protocols may have different granularity requirements and bounds on shortest and longest spacing between successive message transmissions.
いくつかのMANETルーティングプロトコルは、他人のためにいくつかのメッセージのための非常に短い間隔と非常に長い間隔を使用することができる、または観察された行動に応じてメッセージ送信レートを変更することができます。ネットワークは、非常に動的なトポロジを示すことがある時点で観察された場合、例えば、非常に短い（サブ秒）メッセージ間隔は、ネットワークが後で安定化することが観察された場合に対し、マルチ時間メッセージ間隔ができ、適切であり得ます適切になります。異なるMANETルーティングプロトコルとMANETルーティングプロトコルの異なる配備は、連続するメッセージ伝送間の最短及び最長の間隔に異なる粒度要件と境界を有していてもよいです。
In addition, MANET routing protocol deployments typically use bandwidth-limited wireless network interfaces, and therefore prefer to trade off computational complexity for a saving in the number of bits transmitted. This is practical in this case, because the intended usages of Time TLVs, including the specified examples of message interval time and information validity time, do not require high-precision values of time.
また、MANETルーティングプロトコルの導入は、典型的には、帯域幅制限された無線ネットワークインタフェースを使用し、したがって、送信されるビット数を節約するために計算の複雑さをトレードオフすることを好みます。メッセージインターバル時間と情報の有効時間の指定された例を含む時間のTLVの意図された用途は、時間の高精度な値を必要としないので、これは、この場合に実用的です。
The Time TLV structure, specified in this document, caters to these characteristics by:
この文書で指定された時間TLV構造は、することにより、これらの特性に食料調達します：
o encoding time-values, such as an interval or a duration, in an 8-bit field; while
O 8ビットのフィールドでは、そのような間隔または期間などの時間値を符号化します。同時に
o allowing these time-values to range from "very small" (e.g., 1/1024 second) to "very long" (e.g., 45 days); and
（例えば、1/1024秒）に「非常に長い」（例えば、45日）は、これらの時間値は、「非常に小さい」範囲を可能にOであり;そして
o allowing a MANET routing protocol, or a deployment, to parameterize this (e.g., to attain finer granularity at the expense of a lower upper bound) through a single parameter, C.
MANETルーティングプロトコル、または展開を可能にO、これは単一のパラメータ、C.介して（例えば、より低い上限を犠牲にしてより細かい粒度を達成するために）パラメータ化します
The parameter C must be the same for all MANET routers in the same deployment.
パラメータCは同じ展開内のすべてのMANETルータで同じでなければなりません。
The TLV mechanism as specified in [RFC5444] allows associating a "value" to either a packet, a message, or to addresses. The data structure for doing so -- the TLV -- is identical in each of the three cases; however, the TLV's position in a received packet allows determining if that TLV is a "Packet TLV" (it appears in the Packet Header, before any messages), a "Message TLV" (it appears in the TLV Block immediately following a Message Header), or an "Address Block TLV" (it appears in the TLV Block immediately following an Address Block).
[RFC5444]で指定されるようにTLV機構は、パケット、メッセージ、またはアドレスのいずれかに「値」を関連付けることができます。 TLV - - そうするためのデータ構造は、3例それぞれにおいて同一です。しかし、受信したパケット内TLVの位置は、そのTLVは「パケットTLV」で、「メッセージTLV」（それはすべてのメッセージの前に、パケットヘッダに表示されます）かどうかを判断することができます（それはすぐにメッセージヘッダ以下のTLVブロックに表示されます。 ）、または（それはすぐにアドレスブロック以下のTLVブロックに表示されます）「ブロックTLVアドレス」。
While TLVs may be structurally identical, that which they express may be different. This is determined from the kind (packet, message, or Address Block) and type of the TLV. For example, one TLV might associate a lifetime to an address, another a content sequence number to a message, and another a cryptographic signature to a packet. For this reason, [RFC5444] specifies separate registries for Packet TLV Types, Message TLV Types, and Address Block TLV Types, and it does not specify any structure in the TLV Value field.
TLVは、構造的に同一であってもよいが、それらが発現することが異なっていてもよいです。これは、種（パケット、メッセージ、またはアドレスブロック）及びTLVのタイプから決定されます。例えば、一つのTLVは、メッセージ、およびパケットの暗号署名別に他のコンテンツシーケンス番号、アドレスに寿命を関連付けるかもしれません。このため、[RFC5444]はパケットTLVタイプ、メッセージTLVタイプに個別のレジストリを指定し、ブロックTLVタイプのアドレス、そしてそれはTLVのValueフィールドに任意の構造を指定しません。
The TLVs defined in this document express, essentially, that "this information will be refreshed within X seconds" and that "this information is valid for X seconds after being received", each allowing the "X seconds" to be specified as a function of the number of hops from the originator of the information. This document specifies a general format allowing expressing and encoding this as the value field of a TLV. This representation uses a compact (8-bit) representation of time, as message size is an issue in many MANETs, and the offered precision and range is appropriate for MANET routing protocols.
TLV及び「この情報が受信された後のX秒間有効である」と「この情報はX秒以内に更新されます」と、本質的に、この文書の明示で定義され、「X秒」を可能にそれぞれがの関数として指定します情報の発信元からのホップ数。この文書では、発現及びTLVの値フィールドとしてこれをコードする可能一般的なフォーマットを指定します。メッセージサイズは、多くのアドホックネットワークにおけるにおける問題であり、提供される精度と範囲は、MANETルーティングプロトコルのために適切であるように、この表現は、時間のコンパクト（8ビット）表現を使用します。
A TLV of this format may be used for packets, messages, or addresses. For example, a proactive MANET routing protocol periodically reporting link-state information could include a TLV of this format as a Message TLV. This may indicate a different periodicity in different scopes (possibly frequently up to a few hops, less frequently beyond that) because some messages may be sent with limited scope, as specified in [RFC5444]. A reactive MANET routing protocol could include a TLV of this format as an Address Block TLV for reporting the lifetime of routes to individual addresses.
この形式のTLVは、パケット、メッセージ、又はアドレスのために使用することができます。例えば、定期的にリンクステート情報を報告するプロアクティブMANETルーティングプロトコルメッセージTLVにこの形式のTLVを含むことができます。 [RFC5444]で指定されるように、いくつかのメッセージは、限られた範囲で送信することができるので、これは（おそらく頻繁数ホップまで、より少ない頻度でそれを超える）異なるスコープに異なる周期性を示すことができます。反応MANETルーティングプロトコルは、個々のアドレスへのルートの寿命を報告するためのアドレスブロックTLVにこの形式のTLVを含むことができます。
In addition to defining the general format as outlined above, this document requests IANA assignments for INTERVAL_TIME and VALIDITY_TIME TLVs. These IANA assignments are requested in this document in order to avoid interdependencies between otherwise unrelated MANET protocols and in order to not exhaust the TLV Type spaces by having different protocols request types for essentially identical data structures. Only Message TLVs and Address Block TLVs are requested, as these are those for which a need has been demonstrated.
上記で概説した一般的なフォーマットを定義することに加えて、この文書はINTERVAL_TIMEとVALIDITY_TIMEのTLVのためのIANAの割り当てを要求します。これらIANAの割り当ては、そうでなければ無関係MANETプロトコル間と本質的に同一のデータ構造のための異なるプロトコル要求タイプを有することにより、TLVタイプスペースを排出しないためには相互依存性を回避するために、この文書で要求されています。これらは、必要性が実証されているものであり、として、メッセージのTLVとブロックのTLVアドレスのみが、要求されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "推奨NOT"、および「OPTIONAL 「本書では[RFC2119]で説明されるように解釈されるべきです。
Additionally, this document uses terminology from [RFC5444], and introduces the following terminology:
また、このドキュメントは[RFC5444]から用語を使用して、以下の用語が導入されています。
hop count - the number of hops from the message originator to the message recipient. This is defined to equal the <msg-hop-count> field in the <msg-header> element defined in [RFC5444], if present, after it is incremented on reception. If the <msg-hop-count> field is not present, or in a Packet TLV, then hop count is defined to equal 255.
ホップ数 - メッセージ受信者へのメッセージの発信元からのホップ数。これは、存在する場合、それは受信時にインクリメントされた後に、[RFC5444]で定義された<MSG-ヘッダ>要素内の<MSGホップカウント>フィールドと等しくなるように定義されています。 <MSGホップカウント>フィールドが存在する、またはパケットTLVに含まれていない場合、その後、カウントが255に等しくなるように定義されるホップ。
time-value - a time, measured in seconds.
時間値 - 時間、秒単位で測定。
time-code - an 8-bit field, representing a time-value.
タイムコード - 8ビットのフィールド、時間値を表します。
The TLV structure described in this document is applicable whenever a single time-value, or a time-value that varies with the number of hops from the originator of a message, is required in a protocol using the generalized MANET packet/message format [RFC5444].
単一の時間値、またはメッセージの発信元からのホップの数に応じて変化する時間値が、一般化されたMANETパケット/メッセージフォーマットを使用して、プロトコルに必要とされるときはいつでも、この文書に記載さTLV構造が適用可能である[RFC5444 ]。
Examples of time-values that may be included in a protocol message are:
プロトコルメッセージに含めることができる時間値の例は：
o The maximum time interval until the next message of the same type is to be generated by the message's originator node.
同じタイプの次のメッセージまでの最大時間間隔oをメッセージの発信ノードによって生成されます。
o The validity time of the information with which the time-value is associated.
時間値が関連付けられている情報の有効時間O。
Either of these may vary with the hop count between the originating and receiving nodes, e.g., if messages of the same type are sent with different hop limits as defined in [RFC5444].
[RFC5444]で定義されるものと同じタイプのメッセージは、異なるホップ制限に送信される場合、これらのいずれかは、例えば、発信と受信ノードの間のホップ数に応じて変化してもよいです。
Parts of this document have been generalized from material in the proactive MANET routing protocol OLSR (Optimized Link State Routing Protocol) [RFC3626].
この文書の部分は、プロアクティブMANETルーティングプロトコルOLSR（最適化リンク状態ルーティングプロトコル）[RFC3626]に材料から一般化されています。
This document does not specify a protocol nor does it mandate specific node or protocol behavior. Rather, it outlines mechanisms for encoding time-values using the TLV mechanism of [RFC5444].
この文書では、プロトコルを指定しておらず、特定のノードまたはプロトコルの動作を義務付けるん。むしろ、それは、[RFC5444]のTLVメカニズムを使用して時間値を符号化するためのメカニズムを概説します。
This document specifies a TLV structure in which time-values are each represented in an 8-bit time-code, one or more of which may be used in a TLV's <value> field. Of these 8 bits, the least significant 3 bits represent the mantissa (a), and the most significant 5 bits represent the exponent (b), so that:
この文書は、時間値は各8ビットのタイムコード、TLVの<値>フィールドに使用することができる1つ以上で表されたTLV構造を指定します。これらの8ビットのうち、最下位の3ビットは、仮数（A）を表し、最上位5ビットとなるよう、（b）は、指数を表します。
o time-value := (1 + a/8) * 2^b * C
O時間値=（1 + / 8）* 2 ^ B * C
o time-code := 8 * b + a
Oタイムコード：= 8 * B + A
All nodes in the MANET MUST use the same value of the constant C, which will be specified in seconds, hence so will be all time-values. C MUST be greater than 0 seconds. Note that ascending values of the time-code represent ascending time-values; time-values may thus be compared by comparison of time-codes.
MANET内のすべてのノードが秒単位で指定される定数C、の同じ値を使用する必要があり、従ってので、すべての時間値であろう。 Cは0秒より大きくなければなりません。タイムコードの上昇値が昇順時間値を表すことに留意されたいです。時間値は、このように時間コードを比較することにより比較することができます。
An algorithm for computing the time-code representing the smallest representable time-value not less than the time-value t is:
時間値tがより小さくない最小の表現の時間値を表すタイムコードを計算するためのアルゴリズム：
2. set a := 8 * (t / (C * 2^b) - 1), rounded up to the nearest integer;
2.設定：= 8×（T /（C * 2 ^ B）を - 1）、最も近い整数に切り上げ。
4. if 0 <= a <= 7, and 0 <= b <= 31, then the required time-value can be represented by the time-code 8 * b + a, otherwise it cannot.
0 <= A <= 7、及び0 <= B <= 31、次いで所要時間値をタイムコードで表すことができる場合4. 8 * B +、そうでなければできません。
The minimum time-value that can be represented in this manner is C. The maximum time-value that can be represented in this manner is 15 * 2^28 * C, or about 4.0 * 10^9 * C. If, for example, C = 1/1024 second, then this is about 45 days.
このようにして表すことができる最小時間値がこのように表現することができる最大時間値は約4.0 * 10 ^ 9 * C.場合、例えば15 * 2 ^ 28 *がCであるか、またはCです。 、C = 1/1024秒は、これは約45日です。
A protocol using this time representation MUST define the value of C. A protocol using this specification MAY specify that the all-bits zero time-value (0) represents a time-value of zero and/or that the all-bits one time-value (255) represents an indefinitely large time-value.
C.の値を定義しなければならないこの時間表現を使用して、プロトコルは、この仕様を使用してプロトコルは、すべてのビットがゼロ時間値が（0）ゼロおよび/またはそのすべてのビット1つのタイムの時間値を表すことを指定することができます値（255）は無期限に大きな時間値を表します。
The following data structure allows the representation of a single time-value, or of a default time-value plus pairs of (time-values, hop counts) for when hop-count-dependent time-values are required. The time-values are represented as time-codes as defined in Section 5. This <time-data> data structure is specified, using the regular expression syntax of [RFC5444], by:
次のデータ構造は、単一の時間値の表現を可能にする、またはホップ数に依存する時間値が必要な場合のために（時間値、ホップ数）のデフォルト時間値を加えたペア。セクション5で定義された時間値は、時間コードとして表され、この<時間データ>データ構造により、[RFC5444]の正規表現構文を使用して、指定されています。
<time-data> = (<time-code><hop-count>)*<time-code>
<時間データ> =（<タイムコード> <ホップ数>）* <タイムコード>
where:
どこ：
<time-code> is an 8-bit unsigned integer field containing a time-code as defined in Section 5.
<タイムコード>セクション5で定義されるようにタイムコードを含む8ビット符号なし整数フィールドです。
<hop-count> is an 8-bit unsigned integer field specifying a hop count from the message originator.
<ホップカウントが>メッセージ発信者からのホップカウントを指定する8ビット符号なし整数フィールドです。
A <time-data> structure thus consists of an odd number of octets; with a repetition factor of n for the (time, hop count) pairs in the regular expression syntax, it contains 2n+1 octets. On reception, n is determined from the length.
<時間データ>構造は、このようにオクテットの奇数から成ります。正規表現の構文で（時間、ホップ数）のペアのためのn個の繰り返し率で、それは2N + 1つのオクテットが含まれています。受信で、nは長さから決定されます。
A <time-data> field may be thus represented by:
<時間データ>フィールドは、このようにすることによって表すことができます。
<t_1><d_1><t_2><d_2> ... <t_i><d_i> ... <t_n><d_n><t_default>
<T_1> <D_1> <T_2> <D_2> ... <T_I> <D_I> ... <T_N> <d_n> <t_default>
<d_1>, ... <d_n>, if present, MUST be a strictly increasing sequence, with <d_n> < 255. Then, at the receiving node's hop count from the originator node, the time-value indicated is that represented by the time-code:
<D_1>、... <d_n>は、存在する場合、<d_n> <255で、厳密に増加するシーケンスでなければなりませんそして、発信ノードから受信ノードのホップカウントで、示された時間値は、によって表されることですタイムコード：
o <t_1>, if n > 0 and hop count <= <d_1>;
O <T_1>、N> 0とホップカウント場合<= <D_1>。
o <t_i+1>, if n > 1 and <d_i> < hop count <= <d_i+1> for some i such that 1 <= i < n;
O <T_I + 1> N> 1と<D_I> <ホップカウント<= <D_I + 1> 1 <= iがn <ように、いくつかの私用であれば、
o <t_default> otherwise, i.e. if n = 0 or hop count > <d_n>.
O <t_default>そうでない場合、すなわち、n = 0の場合、またはカウント> <d_n>ホップ。
If included in a message without a <msg-hop-count> field in its Message Header, or in a Packet TLV, then the form of this data structure with a single time-code in <time-data> (i.e., n = 0) SHOULD be used.
そのメッセージヘッダ内の<MSGホップカウント>フィールドせずにメッセージに含まれている場合、またはパケットTLVで、その後に単一のタイムコードと、このデータ構造の形態<時間データ>（すなわち、N = 0）使用されるべきです。
The purpose of a single value Time TLV is to allow a single time-value to be determined by a node receiving an entity containing the Time TLV, based on its hop count from the entity's originator. The Time TLV may contain information that allows that time-value to be a function of the hop count; thus, different receiving nodes may determine different time-values.
単一の値タイムTLVの目的は、単一の時間値は、エンティティの発信元からのホップカウントに基づいて時間TLVを含むエンティティを受信ノードによって決定されることを可能にすることです。タイムTLVは、その時間値は、ホップ数の関数であることを可能にする情報を含むことができます。従って、異なる受信ノードが異なる時間値を決定することができます。
A single-value Time TLV may be a Packet TLV, a Message TLV, or an Address Block TLV.
単一値タイムTLVは、TLVパケット、メッセージTLV、またはアドレスブロックTLVであってもよいです。
A Time TLV that has the tismultivalue flag cleared ('0') in its <tlv-flags> field, as defined in [RFC5444], contains a single <time-data>, as defined above, in its <value> field. For such a Time TLV:
tismultivalueフラグが<TLV-フラグ>フィールドに（「0」）をクリアされた時間TLVは、[RFC5444]で定義されるように、その<値>フィールドに、上記で定義され、単一の<時間データ>を含みます。そのような時間TLVの場合：
o The <length> field in the TLV MUST contain the value 2n+1, with n being the number of (time-value, hop count) pairs in the Time TLV.
<長さ> oをTLVフィールドは、nは、（時間値、ホップ数）タイムTLVにおけるペアの数であると、値2N + 1を含まなければなりません。
o The number of (time-value, hop count) pairs MUST be identified by inspecting the <length> field in the TLV. The number of such pairs, n, is:
O（時間値、ホップ数）対の数は、TLVの<長さ>フィールドを検査することによって同定されなければなりません。そのような対の数は、Nです。
* n := (<length> - 1) / 2
N *：=（<長さ> - 1）/ 2
This MUST be an integer value.
これは、整数値でなければなりません。
The purpose of a multi-value Time TLV is to associate a set of <time-data> structures to an identically sized set of addresses, as described in [RFC5444]. For each of these <time-data> structures, a single time-value can be determined by a node receiving an entity containing the Time TLV, based on its hop count from the entity's originator. The Time TLV may contain information that allows that time-value to be a function of the hop count, and thus different receiving nodes may determine different time-values.
多値タイムTLVの目的は、[RFC5444]に記載されているように、アドレスのセットサイズ同じに<時間データ>構造のセットを関連付けることです。これらの<時間データ>構造のそれぞれについて、単一の時間値は、エンティティの発信元からのホップカウントに基づいて、タイムTLVを含むエンティティを受信するノードによって決定することができます。タイムTLVは、その時間値は、ホップ数の関数であることを可能にする情報を含んでいてもよく、したがって異なる受信ノードは、異なる時間値を決定することができます。
Multi-value Time TLVs MUST be Address Block TLVs. A multi-value Time TLV MUST NOT be a Packet TLV or Message TLV.
マルチ値の時間のTLVは、アドレスブロックのTLVでなければなりません。マルチ値の時間TLVは、パケットTLVまたはメッセージTLVしているはずがありません。
A Time TLV that has the tismultivalue flag set ('1') in its <tlv-flags> field, as defined in [RFC5444], contains a sequence of <time-data> structures, as defined above, in its <value> field. For such a Time TLV:
その<値>に、上記で定義した通りでtismultivalueフラグが設定されているタイムTLV（「1」）は、その<TLV-フラグが>フィールドは、[RFC5444]で定義されるように、<時間データ>構造体の配列を含みますフィールド。そのような時間TLVの場合：
o The <length> field in the TLV MUST contain the value m * (2n+1), with n being the number of (time-value, hop count) pairs in the Time TLV, and m being number-values as defined in [RFC5444].
<長さ> TLVフィールドは、nは、（時間値、ホップ数）の数であると、タイムTLVでペアを値m×（2N + 1）を含まなければなりません、とで定義されるように、mは数値であるO [RFC5444]。
o The number of <time-data> structures included in the <value> field is equal to number-values as defined in [RFC5444].
[RFC5444]で定義されるように、O <値>に含まれる<時間データ>構造体の数は、フィールド番号値に等しいです。
o The number of (time-value, hop count) pairs in each <time-data> structure MUST be the same, and MUST be identified by inspecting the <length> field in the TLV and using number-values as defined in [RFC5444]. The number of such pairs in each <time-data> structure, n, is:
O（時間値、ホップ数）各<時間データ>におけるペアの数は、構造が同じである必要があり、そして、[RFC5444で定義されるように、数値をTLVにおける<長さ>フィールドを検査し、使用することによって同定されなければなりません]。各<時間データ>構造におけるそのような対の数、Nは、です。
* n := ((<length> / number-values) - 1) / 2
N *：=（（<長さ> /数値） - 1）/ 2
This MUST be an integer value. The lists of hop count values MAY be different.
これは、整数値でなければなりません。ホップカウント値のリストは異なる場合があります。
Two Message TLVs are defined, for signaling message interval (INTERVAL_TIME) and message validity time (VALIDITY_TIME).
2つのメッセージのTLVメッセージ間隔（INTERVAL_TIME）と、メッセージの有効時間（VALIDITY_TIME）をシグナリングするために、定義されています。
An INTERVAL_TIME TLV is a Message TLV that defines the maximum time before another message of the same type as this message from the same originator should be received. This interval time MAY be specified to depend on the hop count from the originator. (This is appropriate if messages are sent with different hop limits so that receiving nodes at greater hop counts have an increased interval time.)
INTERVAL_TIME TLVは、同じ発信元からこのメッセージを受信しなければならないのと同じタイプの他のメッセージの前に最大時間を定義するメッセージTLVです。このインターバル時間は、発信元からのホップ数に依存するように指定することができます。 （メッセージは大きいホップ数で受信ノードはインターバル時間を増加しているように、異なるホップ制限に送信された場合、これは適切です。）
A message MUST NOT include more than one INTERVAL_TIME TLV.
メッセージは、複数のINTERVAL_TIME TLVを含んではいけません。
An INTERVAL_TIME TLV is an example of a Time TLV specified as in Section 5.
INTERVAL_TIME TLVは、第5節のように指定された時間TLVの一例です。
A VALIDITY_TIME TLV is a Message TLV that defines the validity time of the information carried in the message in which the TLV is contained. After this time, the receiving node MUST consider the message content to no longer be valid (unless repeated in a later message). The validity time of a message MAY be specified to depend on the hop count from its originator. (This is appropriate if messages are sent with different hop limits so that receiving nodes at greater hop counts receive information less frequently and must treat is as valid for longer.)
VALIDITY_TIME TLVは、TLVが含まれているメッセージで運ばれた情報の有効時間を定義するメッセージTLVです。この時間の後、受信ノードは、（後でメッセージ内で繰り返されない限り）もはや有効でないために、メッセージの内容を考慮する必要があります。メッセージの有効期限は、その発信元からのホップ数に依存するように指定することができます。 （大きいホップカウントで受信ノードは、それほど頻繁に情報を受信し、長くとして有効で扱わなければならないように、メッセージが異なるホップ制限に送信された場合、これは適切です。）
A message MUST NOT include more than one VALIDITY_TIME TLV.
メッセージは、複数のVALIDITY_TIME TLVを含んではいけません。
A VALIDITY_TIME TLV is an example of a Time TLV specified as in Section 5.
VALIDITY_TIME TLVはセクション5のように指定された時間TLVの一例です。
Two Address Block TLVs are defined, for signaling address advertisement interval (INTERVAL_TIME) and address validity time (VALIDITY_TIME).
2つのアドレスブロックのTLVアドレス通知間隔（INTERVAL_TIME）とアドレス有効時間（VALIDITY_TIMEを）シグナリングのために、定義されています。
An INTERVAL_TIME TLV is an Address Block TLV that defines the maximum time before this address from the same originator should be received again. This interval time MAY be specified to depend on the hop count from the originator. (This is appropriate if addresses are contained in messages sent with different hop limits so that receiving nodes at greater hop counts have an increased interval time.)
INTERVAL_TIME TLVは再び受信されるべき同じ発信元からこのアドレスまでの最大時間を定義アドレスブロックTLVです。このインターバル時間は、発信元からのホップ数に依存するように指定することができます。 （大きいホップ数で受信ノードが大きく間隔を有するようにアドレスが異なるホップ制限に送信されたメッセージに含まれている場合、これは適切です。）
A protocol using this TLV and the same named Message TLV MUST specify how to interpret the case when both are present (typically, that the former overrides the latter for those addresses that are covered by the former).
このTLVと同じ名前のメッセージTLVを使用してプロトコルの両方が存在する場合（典型的には、前者で覆われているそれらのアドレスの元オーバーライド後者こと）ケースをどのように解釈するかを指定しなければなりません。
An INTERVAL_TIME TLV is an example of a Time TLV specified as in Section 5.
INTERVAL_TIME TLVは、第5節のように指定された時間TLVの一例です。
A VALIDITY_TIME TLV is an Address Block TLV that defines the validity time of the addresses to which the TLV is associated. After this time, the receiving node MUST consider the addresses to no longer be valid (unless these are repeated in a later message). The validity time of an address MAY be specified to depend on the hop count from its originator. (This is appropriate if addresses are contained in messages sent with different hop limits so that receiving nodes at greater hop counts receive information less frequently and must treat is as valid for longer.)
VALIDITY_TIME TLVは、TLVが関連付けられているアドレスの有効時間を規定するアドレスブロックTLVです。この時間の後、受信ノードは、（これらは、後のメッセージに繰り返されていない限り）もはや有効ではないにアドレスを考慮する必要があります。アドレスの有効期限は、その発信元からのホップ数に依存するように指定することができます。 （アドレスが大きいホップ数の受信ノードは、それほど頻繁に情報を受け取ることができるように、異なるホップ制限に送信されたメッセージに含まれていると長いためとして有効で扱わなければならない場合、これは適切です。）
A protocol using this TLV and the same named Message TLV MUST specify how to interpret the case when both are present (typically, that the former overrides the latter for those addresses that are covered by the former).
このTLVと同じ名前のメッセージTLVを使用してプロトコルの両方が存在する場合（典型的には、前者で覆われているそれらのアドレスの元オーバーライド後者こと）ケースをどのように解釈するかを指定しなければなりません。
A VALIDITY_TIME TLV is an example of a Time TLV specified as in Section 5.
VALIDITY_TIME TLVはセクション5のように指定された時間TLVの一例です。
This specification defines two Message TLV Types, which have been allocated from the "Assigned Message TLV Types" repository of [RFC5444] as specified in Table 1, and two Address Block TLV Types, which have been allocated from the "Assigned Address Block TLV Types" repository of [RFC5444] as specified in Table 2.
本明細書では、「割り当てられたアドレスブロックTLVタイプから割り当てられた、表1で指定されるように[RFC5444]の「割り当てられたメッセージTLVタイプ」リポジトリから割り当てられた2つのメッセージTLVタイプ、および2つのアドレスブロックTLVタイプを定義します表2で指定されるように[RFC5444]の「リポジトリ。
IANA has assigned the same numerical value to the Message TLV Type and Address Block TLV Type with the same name.
IANAは、メッセージTLVタイプに同じ数値が割り当てられ、同じ名前を持つブロックTLVタイプをアドレスしています。
For the registries for TLV Type Extensions where an Expert Review is required, the designated expert SHOULD take the same general recommendations into consideration as are specified by [RFC5444].
[RFC5444]で指定されているようエキスパートレビューが必要とされるTLVタイプの拡張機能のレジストリの場合は、指定された専門家は考慮に同じ一般的な推奨事項を取る必要があります。
+---------------+------+-----------+--------------------------------+
| Name | Type | Type | Description |
| | | Extension | |
+---------------+------+-----------+--------------------------------+
| INTERVAL_TIME | 0 | 0 | The maximum time before |
| | | | another message of the same |
| | | | type as this message from the |
| | | | same originator should be |
| | | | received |
| Unassigned | 0 | 1-223 | Expert Review |
| | | 224-255 | Experimental Use |
| VALIDITY_TIME | 1 | 0 | The time from receipt of the |
| | | | message during which the |
| | | | information contained in the |
| | | | message is to be considered |
| | | | valid |
| Unassigned | 1 | 1-223 | Expert Review |
| | | 224-255 | Experimental Use |
+---------------+------+-----------+--------------------------------+
Table 1
表1
+---------------+------+-----------+--------------------------------+
| Name | Type | Type | Description |
| | | extension | |
+---------------+------+-----------+--------------------------------+
| INTERVAL_TIME | 0 | 0 | The maximum time before |
| | | | another message of the same |
| | | | type as this message from the |
| | | | same originator and containing |
| | | | this address should be |
| | | | received |
| Unassigned | 0 | 1-223 | Expert Review |
| | | 224-255 | Experimental Use |
| VALIDITY_TIME | 1 | 0 | The time from receipt of the |
| | | | address during which the |
| | | | information regarding this |
| | | | address is to be considered |
| | | | valid |
| Unassigned | 0 | 1-223 | Expert Review |
| | | 224-255 | Experimental Use |
+---------------+------+-----------+--------------------------------+
Table 2
表2
This document specifies how to add data structures (TLVs) that provide timing information to packets and messages specified using [RFC5444]. In particular, information validity durations and reporting intervals may be added.
この文書では、[RFC5444]を使用して、指定されたパケットとメッセージにタイミング情報を提供するデータ構造（TLVを）追加する方法を指定します。具体的には、情報の有効期間および報告間隔を添加してもよいです。
The general security threats that apply are those general to [RFC5444] and described therein, problems of integrity and confidentiality. With regard to the former, modification of a Time TLV can cause information to have an invalid validity time, or expected interval time. This may cause incorrect protocol performance. Modification or addition of timed information can add to a protocol's workload (especially if a short validity time is specified) and storage requirements (especially if a long validity time is specified).
適用される一般的なセキュリティ上の脅威は[RFC5444]への一般的なものと、そこに記載されている、完全性と機密性の問題があります。前者に関しては、時間TLVの変更は、情報が無効有効期限を持たせる、または間隔時間を期待することができます。これは正しくないプロトコルのパフォーマンスを引き起こす可能性があります。変更またはタイミング情報の追加は、プロトコルの（短い有効期限が指定されている場合は特に）、ワークロードとストレージ要件（長い有効期限が指定されている場合は特に）に追加することができます。
To counter these threats, the security suggestions in [RFC5444], for the use of authentication and encryption, are appropriate.
これらの脅威に対抗するには、[RFC5444]のセキュリティ提案は、認証と暗号化を使用するため、適切です。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, February 2009.
[RFC5444] Clausenの、T.、Dearlove、C.、ディーン、J.、およびC. Adjih、 "一般モバイルアドホックネットワーク（MANET）パケット/メッセージフォーマット"、RFC 5444、2009年2月。
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State Routing Protocol", RFC 3626, October 2003.
[RFC3626]クラウゼン、T.およびP.ジャケ、 "最適化されたリンクステートルーティングプロトコル"、RFC 3626、2003年10月。
Appendix A. Acknowledgements
付録A.謝辞
The authors would like to thank Brian Adamson and Justin Dean (both NRL) and Ian Chakeres (Motorola) for their contributions, and Alan Cullen (BAE Systems) and Jari Arkko (Ericsson, Finland) for their careful reviews of this specification.
著者は、この仕様の彼らの慎重なレビューのためにブライアン・アダムソンとジャスティン・ディーン（両方NRL）と彼らの貢献のためのイアンChakeres（モトローラ）、そしてアラン・カレン（BAEシステムズ）とヤリArkko（エリクソン、フィンランド）を感謝したいと思います。
Authors' Addresses
著者のアドレス
Thomas Heide Clausen LIX, Ecole Polytechnique, France
トーマス・ハイデクラウゼンLIX、エコール・ポリテクニック、フランス
Phone: +33 6 6058 9349 EMail: T.Clausen@computer.org URI: http://www.ThomasClausen.org/
電話：+33 6 6058 9349 Eメール：T.Clausen@computer.org URI：http://www.ThomasClausen.org/
Christopher Dearlove BAE Systems Advanced Technology Centre
クリストファーDearlove BAEシステムズ先端技術センター
Phone: +44 1245 242194 EMail: chris.dearlove@baesystems.com URI: http://www.baesystems.com/
電話：+44 1245 242194 Eメール：chris.dearlove@baesystems.com URI：http://www.baesystems.com/