Network Working Group                                         T. Clausen
Request for Comments: 5148              LIX, Ecole Polytechnique, France
Category: Informational                                      C. Dearlove
                                  BAE Systems Advanced Technology Centre
                                                              B. Adamson
                                          U.S. Naval Research Laboratory
                                                           February 2008
        
Network Working Group                                         T. Clausen
Request for Comments: 5148              LIX, Ecole Polytechnique, France
Category: Informational                                      C. Dearlove
                                  BAE Systems Advanced Technology Centre
                                                              B. Adamson
                                          U.S. Naval Research Laboratory
                                                           February 2008
        

Jitter Considerations in Mobile Ad Hoc Networks (MANETs)

移动自组网(MANET)中的抖动问题

Status of This Memo

关于下段备忘

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。

Abstract

摘要

This document provides recommendations for jittering (randomly modifying timing) of control traffic transmissions in Mobile Ad hoc NETwork (MANET) routing protocols to reduce the probability of transmission collisions.

本文档为移动自组织网络(MANET)路由协议中控制流量传输的抖动(随机修改定时)提供了建议,以降低传输冲突的概率。

Table of Contents

目录

   1. Introduction ....................................................2
   2. Terminology .....................................................3
   3. Applicability Statement .........................................4
   4. Protocol Overview and Functioning ...............................4
   5. Jitter ..........................................................5
      5.1. Periodic Message Generation ................................5
      5.2. Externally Triggered Message Generation ....................6
      5.3. Message Forwarding .........................................7
      5.4. Maximum Jitter Determination ...............................8
   6. Security Considerations .........................................9
   7. References .....................................................10
      7.1. Normative References ......................................10
      7.2. Informative References ....................................10
   Appendix A. Acknowledgements ......................................11
        
   1. Introduction ....................................................2
   2. Terminology .....................................................3
   3. Applicability Statement .........................................4
   4. Protocol Overview and Functioning ...............................4
   5. Jitter ..........................................................5
      5.1. Periodic Message Generation ................................5
      5.2. Externally Triggered Message Generation ....................6
      5.3. Message Forwarding .........................................7
      5.4. Maximum Jitter Determination ...............................8
   6. Security Considerations .........................................9
   7. References .....................................................10
      7.1. Normative References ......................................10
      7.2. Informative References ....................................10
   Appendix A. Acknowledgements ......................................11
        
1. Introduction
1. 介绍

In a wireless network, simultaneous packet transmission by nearby nodes is often undesirable. This is because any resulting collision between these packets may cause a receiving node to fail to receive some or all of these packets. This is a physical problem, which occurs before packets can be inserted into the receiver queue. Depending on the characteristics of the medium access control and other lower layer mechanisms, in particular whether retransmission of unacknowledged packets is supported, this may cause at best increased delay, and at worst complete packet loss. In some instances, these problems can be solved in these lower layers, but in other instances, some help at the network and higher layers is necessary.

在无线网络中,附近节点同时传输数据包通常是不可取的。这是因为这些数据包之间产生的任何冲突都可能导致接收节点无法接收部分或全部这些数据包。这是一个物理问题,发生在数据包可以插入接收方队列之前。取决于介质访问控制和其他低层机制的特性,尤其是是否支持未确认分组的重传,这最多可能导致延迟增加,最坏可能导致完全分组丢失。在某些情况下,这些问题可以在这些较低的层中解决,但在其他情况下,需要在网络和更高的层上提供一些帮助。

This document considers the case when that help is required, and provides recommendations for using jitter (randomly varying timing) to provide it. It is possible that the techniques described here could be implemented either by IP protocols designed for wireless networks or in conjunction with lower-layer mechanisms.

本文档考虑了需要帮助的情况,并提供了使用抖动(随机变化的定时)提供帮助的建议。这里描述的技术可以通过为无线网络设计的IP协议或结合较低层机制来实现。

The problems of simultaneous packet transmissions are amplified if any of the following features are present in a protocol:

如果协议中存在以下任何特征,则同时分组传输的问题将被放大:

Regularly scheduled messages - If two nodes generate packets containing regularly scheduled messages of the same type at the same time, and if, as is typical, they are using the same message interval, all further transmissions of these messages will thus also be at the same time. Note that the following mechanisms may make this a likely occurrence.

定期调度消息-如果两个节点同时生成包含相同类型的定期调度消息的数据包,并且通常情况下,如果它们使用相同的消息间隔,则这些消息的所有进一步传输也将同时进行。请注意,以下机制可能导致这种情况。

Event-triggered messages - If nodes respond to changes in their circumstances, in particular changes in their neighborhood, with an immediate message generation and transmission, then two nearby nodes that respond to the same change will transmit messages simultaneously.

事件触发消息-如果节点响应其环境的变化,特别是其邻居的变化,并立即生成和传输消息,则响应相同变化的两个相邻节点将同时传输消息。

Schedule reset - When a node sends an event-triggered message of a type that is usually regularly scheduled, then there is no apparent reason why it should not restart its corresponding message schedule. This may result in nodes responding to the same change also sending future messages simultaneously.

计划重置-当节点发送通常定期计划的类型的事件触发消息时,没有明显的理由不应重新启动其相应的消息计划。这可能会导致响应相同更改的节点同时发送将来的消息。

Forwarding - If nodes forward messages they receive from other nodes, then nearby nodes will commonly receive and forward the same message. If forwarding is performed immediately, then the resulting packet transmissions may interfere with each other.

转发-如果节点转发从其他节点接收的消息,则附近的节点通常会接收并转发相同的消息。如果立即执行转发,则产生的分组传输可能相互干扰。

A possible solution to these problems is to employ jitter, a deliberate random variation in timing. Such jitter is employed in e.g., [2], [3], and [4], in which transmission intervals for regularly scheduled messages are reduced by a small, bounded and random amount in order to desynchronize transmitters and thereby avoid overloading the transmission medium as well as receivers. This document discusses and provides recommendations for applying jitter to control packet transmissions in Mobile Ad hoc NETworks (MANETs), with the purpose of avoiding collisions, with particular reference to the features listed above.

解决这些问题的一个可能方法是使用抖动,这是一种故意的随机定时变化。例如,在[2]、[3]和[4]中使用了这种抖动,其中定期调度的消息的传输间隔被减少了一个小的、有界的和随机的量,以便使发射机去同步,从而避免传输介质以及接收机过载。本文档讨论并提供了在移动自组织网络(MANET)中应用抖动控制数据包传输的建议,目的是避免冲突,特别是参考上面列出的特性。

2. Terminology
2. 术语

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [1].

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC2119[1]中所述进行解释。

Additionally, this document uses the following terminology:

此外,本文件使用以下术语:

Node - A MANET router that implements a message sending protocol.

节点-实现消息发送协议的MANET路由器。

MANET interface - A network device participating in a MANET. A node may have one or more MANET interfaces.

MANET接口-参与MANET的网络设备。一个节点可以有一个或多个MANET接口。

Message - An entity carrying protocol information intended for exchange between nodes. Messages are transmitted over MANET interfaces embedded in packets.

消息-承载协议信息的实体,用于节点之间的交换。消息通过包中嵌入的MANET接口传输。

Packet - An entity embedding zero or more messages for transmission over a MANET interface of the node.

数据包-嵌入零条或多条消息的实体,用于在节点的MANET接口上传输。

Transmission - A packet being sent over a MANET interface of the node. A transmission can be due to either a message being generated or a message being forwarded.

传输-通过节点的MANET接口发送的数据包。传输可能是由于生成消息或转发消息造成的。

Generation - Creation of a new message (rather than a received and forwarded message) for transmission over one or more MANET interfaces of the node. Typically, a node will generate messages based on a message schedule (periodic or otherwise) or as a response to changes in circumstances.

生成-创建新消息(而不是接收和转发的消息),以便通过节点的一个或多个MANET接口进行传输。通常,节点将根据消息调度(定期或其他)或作为对环境变化的响应来生成消息。

Forwarding - Retransmission of a received message (whether modified or unchanged) over one or more MANET interfaces of the node.

转发-通过节点的一个或多个MANET接口重新传输接收到的消息(无论是修改的还是未修改的)。

Collision - A specific instance of interference, where two or more nodes transmit a packet at the same time and within the same signal space (at the same frequency and/or encoding) such that

冲突-一种特定的干扰实例,其中两个或多个节点同时在同一信号空间内(以相同的频率和/或编码)传输数据包,从而

another, closely located, node that should receive and decode these packets instead fails to do so, and loses one or more of the packets.

另一个位置很近的节点应该接收和解码这些数据包,但却没有这样做,并且丢失了一个或多个数据包。

3. Applicability Statement
3. 适用性声明

The mechanisms described in this document are applicable to the control messages of any MANET protocol in which simultaneous transmissions by different nodes are undesirable, and that contains mechanisms, such as periodic control message transmission, triggered control message transmission, or control message forwarding, which either make a simultaneous transmission more likely, or cause one to be repeated when it occurs. This particularly applies to protocols using broadcast transmissions in wireless networks, where proactive MANET routing protocols such as [5] employ scheduled messages, where reactive MANET routing protocols such as [6] employ event-triggered messages, and where both employ message forwarding.

本文档中描述的机制适用于任何MANET协议的控制消息,其中不同节点的同时传输是不可取的,并且包含诸如周期性控制消息传输、触发控制消息传输或控制消息转发等机制,这要么使同步传输更有可能,要么在发生时导致重复传输。这尤其适用于在无线网络中使用广播传输的协议,其中诸如[5]之类的主动MANET路由协议采用调度消息,诸如[6]之类的被动MANET路由协议采用事件触发消息,并且两者都采用消息转发。

These mechanisms are intended for application where the underlying medium access control and lower layers do not provide effective mechanisms to avoid such collisions. Where these layers do provide effective mechanisms, the recommendations of this document are not needed.

这些机制适用于底层介质访问控制和较低层不能提供有效机制来避免此类冲突的应用。如果这些层确实提供了有效的机制,则不需要本文件的建议。

The approach described in this document uses random variations in timing to achieve a reduction in collisions. Alternatives using, for example, pseudo-random variation based on node identity, may be considered, but are not discussed by this document.

本文档中描述的方法使用定时的随机变化来减少碰撞。可以考虑使用例如基于节点身份的伪随机变化的备选方案,但本文件不讨论。

Any protocol based on [7] and using the message forwarding mechanism facilitated by that structure is a particular candidate for application of at least some of these mechanisms.

基于[7]并使用由该结构促进的消息转发机制的任何协议都是应用这些机制中至少一些机制的特定候选者。

The document has been generalized from the jitter mechanism used in the proactive MANET routing protocol OLSR (the Optimized Link State Routing Protocol) [5].

本文档是从主动式MANET路由协议OLSR(优化链路状态路由协议)[5]中使用的抖动机制推广而来的。

4. Protocol Overview and Functioning
4. 议定书概述和运作

This document provides recommendations for message transmission (and retransmission) that may be used by MANET routing protocols. It may also be used by other protocols that employ a periodic or triggered message schedule running over wireless interfaces. Using such simultaneous message transmissions from two (or more) adjacent nodes may cause delays, packet losses, and other problems. Any protocol using jitter as outlined here must specify its precise usage insofar as is necessary for interoperability.

本文档为MANET路由协议可能使用的消息传输(和重传)提供了建议。它也可由采用在无线接口上运行的周期性或触发消息调度的其他协议使用。使用来自两个(或更多)相邻节点的此类同时消息传输可能会导致延迟、数据包丢失和其他问题。此处概述的任何使用抖动的协议必须在互操作性所需的范围内指定其精确用法。

5. Jitter
5. 抖动

In order to prevent nodes in a MANET from simultaneous transmission, whilst retaining the MANET characteristic of maximum node autonomy, a randomization of the transmission time of packets by nodes, known as jitter, SHOULD be employed. Three jitter mechanisms, which target different aspects of this problem, SHOULD be employed, with the aim of reducing the likelihood of simultaneous transmission, and, if it occurs, preventing it from continuing.

为了防止MANET中的节点同时传输,同时保持最大节点自主性的MANET特性,应采用节点对分组传输时间的随机化,称为抖动。应采用三种针对该问题不同方面的抖动机制,以降低同时传输的可能性,并在发生时防止其继续。

Three cases exist:

存在三种情况:

o Periodic message generation;

o 定期消息生成;

o Externally triggered message generation;

o 外部触发消息生成;

o Message forwarding.

o 消息转发。

For the first of these cases, jitter is used to reduce the interval between successive message transmission by a random amount; for the latter two cases, jitter is used to delay a message being generated or forwarded by a random amount.

对于第一种情况,抖动用于将连续消息传输之间的间隔减少随机量;对于后两种情况,抖动用于以随机量延迟生成或转发的消息。

Each of these cases uses a parameter, denoted MAXJITTER, for the maximum timing variation that it introduces. If more than one of these cases is used by a protocol, it MAY use the same or a different value of MAXJITTER for each case. It also MAY use the same or different values of MAXJITTER according to message type, and under different circumstances -- in particular if other parameters (such as message interval) vary.

每种情况都使用一个参数MAXJITTER来表示它引入的最大定时变化。如果协议使用了这些情况中的一种以上,则对于每种情况,它可能使用相同或不同的MAXJITTER值。它还可以根据消息类型使用相同或不同的MAXJITTER值,并且在不同的情况下——特别是在其他参数(如消息间隔)不同的情况下。

Issues relating to the value of MAXJITTER are considered in Section 5.4.

第5.4节考虑了与MAXJITTER值相关的问题。

5.1. Periodic Message Generation
5.1. 定期消息生成

When a node generates a message periodically, two successive messages will be separated by a well-defined interval, denoted MESSAGE_INTERVAL. A node MAY maintain more than one such interval, e.g., for different message types or in different circumstances (such as backing off transmissions to avoid congestion). Jitter SHOULD be applied by reducing this delay by a random amount, so that the delay between consecutive transmissions of messages of the same type is equal to (MESSAGE_INTERVAL - jitter), where jitter is the random value.

当一个节点周期性地生成一条消息时,两条连续的消息将被一个定义良好的间隔隔开,表示为message_interval。节点可以维持一个以上的这样的间隔,例如,对于不同的消息类型或在不同的情况下(例如退避传输以避免拥塞)。应通过将该延迟减少随机量来应用抖动,以便相同类型的消息的连续传输之间的延迟等于(消息间隔-抖动),其中抖动是随机值。

Subtraction of the random value from the message interval ensures that the message interval never exceeds MESSAGE_INTERVAL, and does

从消息间隔中减去随机值可确保消息间隔不会超过消息间隔,并且

not adversely affect timeouts or other mechanisms that may be based on message late arrival or failure to arrive. By basing the message transmission time on the previous transmission time, rather than by jittering a fixed clock, nodes can become completely desynchronized, which minimizes their probability of repeated collisions. This is particularly useful when combined with externally triggered message generation and rescheduling.

不会对超时或基于消息延迟到达或未能到达的其他机制产生不利影响。通过将消息传输时间建立在前一个传输时间的基础上,而不是抖动固定的时钟,节点可以变得完全不同步,从而将重复冲突的概率降至最低。这在与外部触发的消息生成和重新调度相结合时特别有用。

The jitter value SHOULD be generated uniformly in an interval between zero and MAXJITTER.

抖动值应在零和最大抖动之间的间隔内均匀生成。

Note that a node will know its own MESSAGE_INTERVAL value and can readily ensure that any MAXJITTER value used satisfies the conditions in Section 5.4.

请注意,节点将知道自己的消息_间隔值,并且可以轻松确保使用的任何MAXJITTER值满足第5.4节中的条件。

5.2. Externally Triggered Message Generation
5.2. 外部触发消息生成

An internal or external condition or event may trigger message generation by a node. Depending upon the protocol, this condition may trigger generation of a single message (including, but not limited to, an acknowledgement message), initiation of a new periodic message schedule, or rescheduling of existing periodic messaging. Collision between externally triggered messages is made more likely if more than one node is likely to respond to the same event. To reduce this likelihood, an externally triggered message SHOULD be jittered by delaying it by a random duration; an internally triggered message MAY also be so jittered if appropriate. This delay SHOULD be generated uniformly in an interval between zero and MAXJITTER. If periodically transmitted messages are rescheduled, then this SHOULD be based on this delayed time, with subsequent messages treated as described in Section 5.1.

内部或外部条件或事件可能触发节点生成消息。根据协议,该条件可能触发单个消息(包括但不限于确认消息)的生成、新周期消息调度的启动或现有周期消息的重新调度。如果有多个节点可能响应同一事件,则外部触发的消息之间发生冲突的可能性更大。为了降低这种可能性,外部触发的消息应该通过随机延迟时间来抖动;如果合适,内部触发的消息也可能会如此抖动。该延迟应在零和最大抖动之间的间隔内均匀产生。如果周期性传输的消息被重新调度,则应基于该延迟时间,后续消息按第5.1节所述处理。

When messages are triggered, whether or not they are also periodically transmitted, a protocol MAY impose a minimum interval between messages of the same type, denoted MESSAGE_MIN_INTERVAL. In the case that such an interval is not required, MESSAGE_MIN_INTERVAL is considered to be zero. When MESSAGE_MIN_INTERVAL is non-zero, it is however appropriate to also allow this interval to be reduced by jitter. Thus, when a message is transmitted, the next message is allowed after a time (MESSAGE_MIN_INTERVAL - jitter). This jitter SHOULD be generated uniformly in an interval between zero and MAXJITTER (using a value of MAXJITTER appropriate to periodic message transmission).

当消息被触发时,无论它们是否也被周期性地传输,协议可以在相同类型的消息之间施加最小间隔,表示为消息最小间隔。在不需要这样的间隔的情况下,消息_MIN _interval被认为是零。然而,当消息_MIN_INTERVAL为非零时,允许通过抖动减小该间隔也是合适的。因此,当一条消息被传输时,下一条消息在一段时间后被允许(消息最小间隔-抖动)。该抖动应在零和MAXJITTER之间的间隔内均匀生成(使用适合于定期消息传输的MAXJITTER值)。

It might appear counterintuitive to have a defined MESSAGE_MIN_INTERVAL, yet allow this to be reduced by jittering. For periodic messages, setting MESSAGE_INTERVAL, MAXJITTER and MESSAGE_MIN_INTERVAL such that (MESSAGE_INTERVAL-MAXJITTER) >

定义一个消息的最小间隔似乎有悖常理,但允许通过抖动来减少这一点。对于周期性消息,设置消息间隔、最大抖动和消息最小间隔,以便(消息间隔-最大抖动)>

MESSAGE_MIN_INTERVAL would ensure at least MESSAGE_MIN_INTERVAL would elapse between two subsequent message transmissions. In a highly dynamic network with triggered messages, however, external circumstances might be such that external triggers are more frequent than MESSAGE_MIN_INTERVAL, effectively making MESSAGE_MIN_INTERVAL take the role of MESSAGE_INTERVAL as the "default" interval at which messages are transmitted. Thus, in order to avoid synchronization in this highly dynamic case, jittering SHOULD be applied to MESSAGE_MIN_INTERVAL. This also permits MESSAGE_MIN_INTERVAL to equal MESSAGE_INTERVAL, even when jitter is used.

MESSAGE_MIN_INTERVAL将确保在两次后续消息传输之间至少经过MESSAGE_MIN_INTERVAL。然而,在具有触发消息的高度动态网络中,外部环境可能导致外部触发比消息\u MIN\u INTERVAL更频繁,从而有效地使消息\u MIN\u INTERVAL充当消息\u INTERVAL的角色,作为消息传输的“默认”间隔。因此,为了避免在这种高度动态的情况下进行同步,应该对消息\u MIN\u间隔应用抖动。这也允许消息最小间隔等于消息间隔,即使在使用抖动时也是如此。

When a triggered message is delayed by jitter, the node MAY also postpone generation of the triggered message. If a node is then triggered to generate a message of the same type while waiting, it can generate a single message. If however the node generates a message when it is triggered, and then receives a another trigger while waiting to send that message, then the appropriate action to take is protocol specific (typically to discard the earlier message or to transmit both, possibly modifying timing to maintain message order).

当触发消息因抖动而延迟时,节点还可以延迟触发消息的生成。如果在等待时触发节点生成相同类型的消息,则它可以生成单个消息。然而,如果节点在被触发时生成消息,然后在等待发送该消息时接收到另一个触发器,则要采取的适当操作是特定于协议的(通常是丢弃先前的消息或传输两者,可能修改定时以维持消息顺序)。

5.3. Message Forwarding
5.3. 消息转发

When a node forwards a message, it SHOULD be jittered by delaying it by a random duration. This delay SHOULD be generated uniformly in an interval between zero and MAXJITTER.

当一个节点转发一条消息时,它应该通过延迟一个随机的持续时间来抖动。该延迟应在零和最大抖动之间的间隔内均匀产生。

Unlike the cases of periodically generated and externally triggered messages, a node is not automatically aware of the message originator's value of MESSAGE_INTERVAL, which is required to select a value of MAXJITTER that is known to be valid. This may require prior agreement as to the value (or minimum value) of MESSAGE_INTERVAL, may be by inclusion in the message of MESSAGE_INTERVAL (the time until the next relevant message, rather than the time since the last message) or be by any other protocol specific mechanism, which may include estimation of the value of MESSAGE_INTERVAL based on received message times.

与周期性生成和外部触发消息的情况不同,节点不会自动知道消息发起人的message_INTERVAL值,这是选择已知有效的MAXJITTER值所必需的。这可能需要事先就消息_间隔的值(或最小值)达成一致,可以包括在消息_间隔的消息中(直到下一条相关消息的时间,而不是自上一条消息以来的时间),或者通过任何其他协议特定机制,这可以包括基于接收到的消息时间估计消息间隔的值。

For several possible reasons (differing parameters, message rescheduling, extreme random values), a node may receive a message while still waiting to forward an earlier message of the same type originating from the same node. This is possible without jitter, but may occur more often with it. The appropriate action to take is protocol-specific (typically, to discard the earlier message or to forward both, possibly modifying timing to maintain message order).

由于几个可能的原因(不同的参数、消息重新调度、极端随机值),节点可能会在等待转发来自同一节点的相同类型的较早消息的同时接收消息。这在没有抖动的情况下是可能的,但在抖动的情况下可能会更频繁地发生。要采取的适当操作是特定于协议的(通常是丢弃较早的消息或转发两者,可能会修改定时以保持消息顺序)。

In many cases, including [5] and protocols using the full functionality of [7], messages are transmitted hop-by-hop in

在许多情况下,包括[5]和使用[7]全部功能的协议,消息都是逐跳传输的

potentially multi-message packets, and some or all of those messages may need to be forwarded. For efficiency, this SHOULD be in a single packet, and hence the forwarding jitter of all messages received in a single packet SHOULD be the same. (This also requires that a single value of MAXJITTER is used in this case.) For this to have the intended uniform distribution, it is necessary to choose a single random jitter for all messages. It is not appropriate to give each message a random jitter and then to use the smallest of these jitter values, as that produces a jitter with a non-uniform distribution and a reduced mean value.

可能是多个消息包,并且可能需要转发部分或所有这些消息。为了提高效率,这应该在单个数据包中,因此在单个数据包中接收的所有消息的转发抖动应该相同。(这也要求在这种情况下使用单个MAXJITTER值。)为了达到预期的均匀分布,必须为所有消息选择单个随机抖动。不适合给每条消息一个随机抖动,然后使用这些抖动值中的最小值,因为这样会产生分布不均匀且平均值减小的抖动。

In addition, the protocol MAY permit control messages received in different packets to be combined, possibly also with locally generated control messages (periodically generated or triggered), as supported by [7]. However, in this case, the purpose of the jitter will be accomplished by choosing any of the independently scheduled times for these events as the single forwarding time; this may have to be the earliest time to achieve all constraints. This is because without combining messages, a transmission would be due at this time anyway.

此外,如[7]所支持的,该协议可允许在不同分组中接收的控制消息被组合,也可能与本地生成的控制消息(周期性生成或触发)组合。然而,在这种情况下,抖动的目的将通过选择这些事件的任何独立调度时间作为单个转发时间来实现;这可能是实现所有约束的最早时间。这是因为在不合并消息的情况下,传输将在此时到期。

5.4. Maximum Jitter Determination
5.4. 最大抖动测定

In considering how the maximum jitter (one or more instances of parameter MAXJITTER) may be determined, the following points may be noted:

在考虑如何确定最大抖动(参数MAXJITTER的一个或多个实例)时,可注意以下几点:

o While jitter may resolve the problem of simultaneous transmissions, the timing changes (in particular the delays) it introduces will otherwise typically have a negative impact on a well-designed protocol. Thus, MAXJITTER SHOULD always be minimized, subject to acceptably achieving its intent.

o 虽然抖动可以解决同时传输的问题,但它引入的定时变化(特别是延迟)通常会对设计良好的协议产生负面影响。因此,MAXJITTER应始终最小化,以达到可接受的目的。

o When messages are periodically generated, all of the following that are relevant apply to each instance of MAXJITTER:

o 当定期生成消息时,以下所有相关信息均适用于MAXJITTER的每个实例:

* it MUST NOT be negative;

* 它不能是消极的;

* it MUST NOT be greater than MESSAGE_INTERVAL/2;

* 不得大于消息间隔/2;

* it SHOULD NOT be greater than MESSAGE_INTERVAL/4.

* 它不应大于消息间隔/4。

o If MESSAGE_MIN_INTERVAL > 0, then:

o 如果消息\u MIN\u INTERVAL>0,则:

* MAXJITTER MUST NOT be greater than MESSAGE_MIN_INTERVAL;

* 最大抖动不得大于消息最小间隔;

* MAXJITTER SHOULD NOT be greater than MESSAGE_MIN_INTERVAL/2.

* MAXJITTER不应大于消息最小间隔/2。

o As well as the decision as to whether to use jitter being dependent on the medium access control and lower layers, the selection of the MAXJITTER parameter SHOULD be appropriate to those mechanisms. For example, MAXJITTER should be significantly greater than (e.g., an order of magnitude greater than) any medium access control frame period.

o 至于是否使用抖动的决定取决于介质访问控制和较低层,MAXJITTER参数的选择应该适合这些机制。例如,MAXJITTER应显著大于(例如,一个数量级大于)任何媒体访问控制帧周期。

o As jitter is intended to reduce collisions, greater jitter, i.e., an increased value of MAXJITTER, is appropriate when the chance of collisions is greater. This is particularly the case with increased node density, which is significant relative to (the square of) the interference range rather than useful signal range.

o 由于抖动旨在减少碰撞,因此当碰撞的可能性更大时,更大的抖动(即MAXJITTER的增加值)是合适的。这在节点密度增加的情况下尤其如此,其相对于干扰范围(而非有用信号范围的平方)显著。

o The choice of MAXJITTER used when forwarding messages MAY also take into account the expected number of times that the message may be sequentially forwarded, up to the network diameter in hops, so that the maximum accumulated delay is bounded.

o 转发消息时使用的MAXJITTER的选择还可以考虑消息可能被顺序转发的预期次数,以跳数为单位的网络直径,以便最大累积延迟是有界的。

6. Security Considerations
6. 安全考虑

This document provides recommendations for mechanisms to be used in protocols; full security considerations are to be provided by those protocols, rather than in this document.

本文件为协议中使用的机制提供了建议;完整的安全注意事项将由这些协议提供,而不是在本文件中。

It may however be noted that introduction of random timing by these recommendations may provide some security advantage to such a protocol in that it makes the prediction of transmission times, and thereby intentional interference with a protocol functioning through selectively scheduling jamming transmissions to coincide with protocol message transmissions, more difficult.

然而,可以注意到,通过这些建议引入随机定时可以为这样的协议提供一些安全优势,因为它可以预测传输时间,因此,通过有选择地调度干扰传输以与协议消息传输一致来对协议进行有意干扰更为困难。

7. References
7. 工具书类
7.1. Normative References
7.1. 规范性引用文件

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[1] Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

7.2. Informative References
7.2. 资料性引用

[2] Moy, J., "OSPF Database Overflow", RFC 1765, March 1995.

[2] Moy,J.,“OSPF数据库溢出”,RFC17651995年3月。

[3] Marlow, D., "Host Group Extensions for CLNP Multicasting", RFC 1768, March 1995.

[3] Marlow,D.,“CLNP多播的主机组扩展”,RFC17681995年3月。

[4] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.

[4] Rekhter,Y.,Ed.,Li,T.,Ed.,和S.Hares,Ed.,“边境网关协议4(BGP-4)”,RFC 42712006年1月。

[5] Clausen, T., Ed., and P. Jacquet, Ed., "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003.

[5] Clausen,T.,Ed.,和P.Jacquet,Ed.,“优化链路状态路由协议(OLSR)”,RFC3626,2003年10月。

[6] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing", RFC 3561, July 2003.

[6] Perkins,C.,Belding Royer,E.和S.Das,“特殊按需距离向量(AODV)路由”,RFC 3561,2003年7月。

[7] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized MANET Packet/Message Format", Work in Progress.

[7] Clausen,T.,Dearlove,C.,Dean,J.,和C.Adjih,“广义MANET数据包/消息格式”,正在进行的工作。

Appendix A. Acknowledgements
附录A.确认书

The authors would like to acknowledge the MANET working group and the OLSRv2 Design team, in particular Joe Macker and Justin Dean (both NRL), for their contributions and discussions in developing and testing the concepts retained in this document, and Alan Cullen (BAE Systems) for his careful review of this specification. OLSRv1, as specified in [5], introduced the concept of jitter on control traffic, which was tested thoroughly by Gitte Hansen and Lars Christensen (then, both Aalborg University).

作者要感谢MANET工作组和OLSRv2设计团队,特别是Joe Macker和Justin Dean(均为NRL),感谢他们在开发和测试本文件中保留的概念方面的贡献和讨论,感谢Alan Cullen(BAE Systems)对本规范的仔细审查。如[5]所述,OLSRv1引入了控制流量抖动的概念,Gitte Hansen和Lars Christensen(当时都是奥尔堡大学)对此进行了全面测试。

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/
        

Brian Adamson U.S. Naval Research Laboratory

布莱恩·亚当森美国海军研究实验室

   Phone: +1 202 404 1194
   EMail: adamson@itd.nrl.navy.mil
   URI:   http://www.nrl.navy.mil/
        
   Phone: +1 202 404 1194
   EMail: adamson@itd.nrl.navy.mil
   URI:   http://www.nrl.navy.mil/
        

Full Copyright Statement

完整版权声明

Copyright (C) The IETF Trust (2008).

版权所有(C)IETF信托基金(2008年)。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

本文件受BCP 78中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

本文件及其包含的信息以“原样”为基础提供,贡献者、他/她所代表或赞助的组织(如有)、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Intellectual Property

知识产权

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和BCP 79。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

向IETF秘书处披露的知识产权副本和任何许可证保证,或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果,可从IETF在线知识产权存储库获取,网址为http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETF邀请任何相关方提请其注意任何版权、专利或专利申请,或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.