Network Working Group T. Clausen
Request for Comments: 5497 LIX, Ecole Polytechnique
Category: Standards Track C. Dearlove
BAE Systems ATC
March 2009
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)
移动自组网（MANET）中多值时间的表示
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和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
Abstracttranslate error, please retry
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.
本文档描述了一种通用且灵活的TLV（类型-长度-值结构），用于使用通用移动自组织网络（MANET）数据包/消息格式表示时间值，例如间隔或持续时间。它定义了两个消息TLV和两个地址块TLV，用于表示MANET路由协议的有效性和间隔时间。
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
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]的消息头所提供。如果接收节点从发端节点知道其跳数，或者时间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类型，它们使用建议的TLV结构。这些TLV类型为间隔时间和有效期时间，分别指定从同一发起者处接收与此消息相同类型的另一消息之前的最长时间，以及接收后此消息中的信息有效的持续时间。请注意，如果两者都存在，则后者通常会大于前者，以允许可能的消息丢失。
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类型，它们使用建议的TLV结构。这些TLV类型是INTERVAL_TIME和VALIDITY_TIME，与两个同名的消息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结构旨在用作MANET路由协议中的组件，例如，通过在传输的消息中包括时间TLV来指示给定消息类型的连续传输之间的预期间隔。
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
一些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路由协议的不同部署可能对连续消息传输之间的最短和最长间隔有不同的粒度要求和界限。
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.
同一部署中的所有MANET路由器的参数C必须相同。
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——在三种情况下都是相同的；然而，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可能将生存期与地址相关联，另一个TLV可能将内容序列号与消息相关联，另一个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秒内有效”，每个TLV都允许将“X秒”指定为信息发起者跳数的函数。本文档指定了一种通用格式，允许将其表示和编码为TLV的值字段。由于消息大小在许多MANET中是一个问题，并且提供的精度和范围适用于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.
除了如上所述定义通用格式外，本文件还要求IANA分配间隔时间和有效时间TLV。本文件中要求这些IANA分配，以避免其他不相关的MANET协议之间的相互依赖性，并避免通过对基本相同的数据结构使用不同的协议请求类型而耗尽TLV类型空间。仅请求消息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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[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 header>元素中的<msg hop count>字段，如果存在，则在接收时递增。如果<msg hop count>字段不存在，或在数据包TLV中不存在，则hop count定义为等于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].
本文档的部分内容已根据主动式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:
本文件规定了一种TLV结构，其中时间值以8位时间码表示，其中一个或多个时间码可用于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
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的最小可表示时间值的时间码的算法为：
1. find the largest integer b such that t/C >= 2^b;
1. 求最大整数b，使t/C>=2^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-data> = (<time-code><hop-count>)*<time-code>
<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>是一个8位无符号整数字段，包含第5节中定义的时间代码。
<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.
因此，<时间数据>结构由奇数个八位组组成；正则表达式语法中的（时间、跳数）对的重复因子为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>, 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_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\u default>否则，即如果n=0或跃点计数><d\u 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。时间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>字段中清除了TISMultipalue flag（“0”）的时间TLV在其<value>字段中包含一个如上定义的<Time data>。在这种情况下，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>字段中设置了TISMultipalue flag（'1'）的时间TLV在其<value>字段中包含如上定义的<Time data>结构序列。在这种情况下，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 每个<time data>结构中的（时间值、跃点计数）对数必须相同，并且必须通过检查TLV中的<length>字段并使用[RFC5444]中定义的数值来识别。每个<时间数据>结构中此类对的数量n为：
* n := ((<length> / number-values) - 1) / 2
* n:=（（<length>/数值）-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).
定义了两个消息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.)
间隔时间TLV是一种消息TLV，它定义了从同一发起者处接收与此消息类型相同的另一消息之前的最长时间。此间隔时间可指定为取决于发起者的跃点计数。（如果发送的消息具有不同的跃点限制，因此接收节点的跃点计数越大，间隔时间就越长，则这是合适的。）
A message MUST NOT include more than one INTERVAL_TIME TLV.
消息不得包含多个间隔时间TLV。
An INTERVAL_TIME TLV is an example of a Time TLV specified as in Section 5.
间隔时间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.)
有效性时间TLV是定义包含TLV的消息中所携带信息的有效性时间的消息TLV。在此之后，接收节点必须考虑消息内容不再有效（除非在稍后的消息中重复）。消息的有效时间可以指定为取决于其发起者的跃点计数。（如果发送的消息具有不同的跃点限制，则这是适当的，以便跃点计数越大的接收节点接收信息的频率越低，并且必须将其视为有效时间越长。）
A message MUST NOT include more than one VALIDITY_TIME TLV.
消息不能包含多个有效时间TLV。
A VALIDITY_TIME TLV is an example of a Time TLV specified as in Section 5.
有效性时间TLV是第5节中规定的时间TLV的一个示例。
Two Address Block TLVs are defined, for signaling address advertisement interval (INTERVAL_TIME) and address validity time (VALIDITY_TIME).
定义了两个地址块TLV，用于信令地址公布间隔（间隔时间）和地址有效时间（有效时间）。
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
间隔时间TLV是一个地址块TLV，它定义了再次接收来自同一发起者的此地址之前的最长时间。此间隔时间可指定为取决于发起者的跃点计数。（如果地址为
contained in messages sent with different hop limits so that receiving nodes at greater hop counts have an increased interval time.)
包含在以不同跳数限制发送的消息中，因此跳数越大的接收节点的间隔时间越长。）
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.
间隔时间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.)
有效性时间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.
有效性时间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类型”存储库中分配的，以及两种地址块TLV类型，它们是从表2中指定的[RFC5444]的“已分配地址块TLV类型”存储库中分配的。
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 |
+---------------+------+-----------+--------------------------------+
+---------------+------+-----------+--------------------------------+
| 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 |
+---------------+------+-----------+--------------------------------+
+---------------+------+-----------+--------------------------------+
| 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.
本文档规定了如何添加数据结构（TLV），这些数据结构向使用[RFC5444]指定的数据包和消息提供定时信息。特别是，可以添加信息有效期和报告间隔。
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 54442009年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.
作者要感谢Brian Adamson和Justin Dean（均为NRL）和Ian Chakeres（摩托罗拉）的贡献，以及Alan Cullen（BAE Systems）和Jari Arkko（爱立信，芬兰）对本规范的仔细审查。
Authors' Addresses
作者地址
Thomas Heide Clausen LIX, Ecole Polytechnique, France
托马斯·海德·克劳森·利克斯，法国理工学院
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/
Christopher Dearlove BAE Systems Advanced Technology Centre
克里斯托弗·迪尔洛夫BAE系统高级技术中心
Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/
Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/