[要約] RFC 5497は、MANETsで複数の値を持つ時間を表現するための方法を提案しています。その目的は、MANETs内での時間情報の正確な表現と共有を可能にすることです。
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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.
このドキュメントは、一般的な時間TLV構造を指定します。これは、単一の時間値または一連の時間価値を表す必要があるMANETルーティングプロトコルで使用できます。[RFC5444]のメッセージヘッダー。これにより、受信ノードは、Originatorノードからのホップカウントを知っているか、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とQualitididiaty_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タイプは、interval_timeとquality_timeであり、同じ名前の2つのメッセージTLVに等しい定義されています。
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
o これらの時間値は、「非常に小」（例：1/1024秒）から「非常に長い」（45日間）までの範囲になります。と
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.
o MANETルーティングプロトコル、または展開を許可して、単一のパラメーター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の種類から決定されます。たとえば、1つのTLVは、寿命をアドレスに、もう1つはコンテンツシーケンス番号をメッセージに関連付け、別のTLVはパケットに暗号化署名を関連付ける場合があります。このため、[RFC5444]は、パケットTLVタイプ、メッセージTLVタイプ、およびアドレスブロックTLVタイプの個別のレジストリを指定しますが、TLV値フィールドの構造を指定しません。
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の値フィールドとして表現およびエンコードできる一般的な形式を指定します。この表現は、多くのマネの問題であり、提供された精度と範囲がマネルーティングプロトコルに適しているため、時間のコンパクトな（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は、パケット、メッセージ、またはアドレスに使用できます。たとえば、リンク状態情報を定期的に報告するプロアクティブなマネルーティングプロトコルには、メッセージ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およびvuricidity_time TLVのIANA割り当てを要求します。これらのIANAの割り当ては、関係のないマネのプロトコル間の相互依存性を回避し、本質的に同一のデータ構造の異なるプロトコルをリクエストすることにより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].
キーワード「必須」、「しない」、「必須」、「shall」、「shall」、「obs "of"、 "not"、 "becommended"、 "becommented"、 "may"、 "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-HOP-HEADER>要素の<MSG-Hop-Count>フィールドに等しいと定義されます。<sg-hop-count>フィールドが存在しない場合、またはパケット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].
このドキュメントで説明されているTLV構造は、単一の時間価値、またはメッセージの発信者からのホップ数によって変化する時間価値がいつでも適用されますが、一般化されたManetパケット/メッセージ形式[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].
このドキュメントの一部は、プロアクティブマネールーティングプロトコル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の<value>フィールドで使用できます。これらの8ビットのうち、最も重要な3ビットはマンティッサ（a）を表し、最も重要な5ビットは指数（b）を表します。
o time-value := (1 + a/8) * 2^b * C
o 時間価値：=（1 a/8） * 2^b * c
o time-code := 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.
o タイムコード：= 8 * bマネのすべてのノードは、数秒で指定される定数Cの同じ値を使用する必要があります。Cは0秒を超える必要があります。タイムコードの上昇値は、昇順の時間値を表していることに注意してください。したがって、時間値は、時間コードの比較によって比較される場合があります。
An algorithm for computing the time-code representing the smallest representable time-value not less than the time-value t is:
最小の表現可能な時間価値を表すタイムコードを計算するためのアルゴリズムは、次のとおりです。
1. find the largest integer b such that t/C >= 2^b;
1. t/c> = 2^bになる最大の整数Bを見つけます。
2. set a := 8 * (t / (C * 2^b) - 1), rounded up to the nearest integer;
2. a：= 8 *（t /（c * 2^b）-1）を設定し、最寄りの整数まで丸めます。
3. if a = 8, then set b := b + 1 and set a := 0;
3. a = 8の場合、b：= b 1を設定し、a：= 0を設定します。
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.
4. 0 <= a <= 7、および0 <= b <= 31の場合、必要な時間値はタイムコード8 * b aで表すことができます。
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.
この方法で表現できる最小時間値はCです。この方法で表現できる最大時間値は、15 * 2^28 * c、または約4.0 * 10^9 * 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）がゼロの時間値を表すことを指定する場合があります。値（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.
<time-code>は、セクション5で定義されているタイムコードを含む8ビットの符号なし整数フィールドです。
<hop-count> is an 8-bit unsigned integer field specifying a hop count from the message originator.
<Hop-Count>は、メッセージオリジネーターからのホップカウントを指定する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.
したがって、<time-data>構造は、奇数のオクテットで構成されています。正規表現構文の（時間、ホップカウント）のペアに対してnの繰り返し係数があるため、2N 1オクテットが含まれています。レセプションでは、Nは長さから決定されます。
A <time-data> field may be thus represented by:
したがって、<time-data>フィールドは、次のように表される場合があります。
<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で厳密に増加するシーケンスでなければなりません。その後、Originatorノードからの受信ノードのホップ数で、示される時間価値はタイムコード：
o <t_1>, if n > 0 and hop count <= <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_default> otherwise, i.e. if n = 0 or hop count > <d_n>.
o <t_default>それ以外の場合は、n = 0またはホップcount> <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-Hop-Count>フィールドのないメッセージまたはパケットTLVに含まれる場合、<Time-Data>に単一のタイムコードを持つこのデータ構造の形式（つまり、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:
[rfc5444]で定義されているように、<tlv-flags>フィールドでtismultivalueフラグがクリアされた（ '0'）時間tlvには、上記のように<値>フィールドに単一の<時間帯>が含まれています。そのような時間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の<length>フィールドには値2n 1を含める必要があり、nは時間TLVの（時間価値、ホップカウント）ペアの数です。
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の<length>フィールドを検査することにより、（時間価値、ホップカウント）ペアの数を特定する必要があります。そのようなペアの数、nは次のとおりです。
* n := (<length> - 1) / 2
* n：=（<length> -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]で説明されているように、<タイムダタ>構造のセットを同一のサイズのアドレスのセットに関連付けることです。これらの<Time-Data>構造のそれぞれについて、単一の時間値は、エンティティの発信者からのホップ数に基づいて、時間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:
[rfc5444]で定義されているように、<tlv-flags>フィールドにtismultivalueフラグセット（ '1'）を持つ時間tlvには、上記のように<値>の構造のシーケンスが含まれています。分野。そのような時間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].
o TLVの<length>フィールドには値m *（2n 1）が含まれている必要があり、nは時間TLVの（時間値、ホップカウント）ペアの数、mは[rfc5444で定義されている数値値です。]。
o The number of <time-data> structures included in the <value> field is equal to number-values as defined in [RFC5444].
o <value>フィールドに含まれる<time-data>構造の数は、[rfc5444]で定義されている数値値に等しくなります。
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 各<タイムダタ>構造の（時間価値、ホップカウント）ペアの数は同じでなければならず、TLVの<length>フィールドを検査し、[RFC5444]で定義されている数値値を使用することで識別する必要があります。。各<Time-Data>構造nのそのようなペアの数は次のとおりです。
* n := ((<length> / number-values) - 1) / 2
* n：=（（<length> / number -values）-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).
メッセージメッセージ間隔（Interval_Time）とメッセージの妥当性時間（妥当性_Time）の2つのメッセージTLVが定義されています。
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.)
有効性_TIME TLVは、TLVが含まれるメッセージに掲載された情報の有効性時間を定義するメッセージTLVです。この時間の後、受信ノードはメッセージコンテンツを有効にしないと考える必要があります（後のメッセージで繰り返されない限り）。メッセージの妥当性時間を指定すると、そのオリジネーターからのホップカウントに依存するように指定できます。（これは、メッセージが異なるホップ制限で送信される場合に適切です。これにより、より大きなホップカウントでノードを受信する頻度が低く、扱わなければならないことがより長く扱わなければなりません。）
A message MUST NOT include more than one VALIDITY_TIME TLV.
メッセージには、複数の有効性_TIME TLVを含めてはなりません。
A VALIDITY_TIME TLV is an example of a Time TLV specified as in Section 5.
有効性_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）とアドレスの有効性時間（妥当性_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.)
有効性_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.
有効性_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.
この仕様では、表1で指定されている[RFC5444]の「割り当てられたメッセージTLVタイプ」リポジトリから割り当てられた2つのメッセージTLVタイプと、「割り当てられたアドレスブロックTLVタイプから割り当てられた2つのアドレスブロックTLVタイプから定義されています。「[RFC5444]のリポジトリは、表2に指定されています。
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].
専門家のレビューが必要なTLVタイプの拡張機能のレジストリの場合、指定された専門家は[RFC5444]で指定されているのと同じ一般的な推奨事項を考慮する必要があります。
+---------------+------+-----------+--------------------------------+
| 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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Dean、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] Clausen、T。およびP. Jacquet、「最適化されたリンク状態ルーティングプロトコル」、RFC 3626、2003年10月。
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の両方）とイアン・チェーカーズ（モトローラ）の貢献に感謝し、アラン・カレン（BAEシステム）とジャリ・アークコ（フィンランド、エリクソン）がこの仕様の慎重なレビューをしてくれたことに感謝したいと思います。
Authors' Addresses
著者のアドレス
Thomas Heide Clausen LIX, Ecole Polytechnique, France
トーマス・ハイデ・クラウセン・リックス、エコール・ポリテクニック、フランス
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/
Christopher Dearlove BAE Systems Advanced Technology Centre
クリストファー・ディアローブ・ベイ・システムズアドバンステクノロジーセンター
Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/