RFC5148 日本語訳
5148 Jitter Considerations in Mobile Ad Hoc Networks (MANETs). T.Clausen, C. Dearlove, B. Adamson. February 2008. (Format: TXT=26379 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループT.クローゼン要求をネットワークでつないでください: 5148LIX、Ecole Polytechnique、フランスカテゴリ: 情報のC.Dearlove BAEシステム先進技術は2008年2月にB.アダムソン米国海軍研究試験所を集中させます。
Jitter Considerations in Mobile Ad Hoc Networks (MANETs)
モバイル臨時のネットワークにおけるジター問題(MANETs)
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.
このドキュメントはモバイルAd hoc NETwork(マネ)ルーティング・プロトコルにおけるコントロール交通送信のジッタリング(手当たりしだいに、タイミングを変更する)がトランスミッション衝突の確率を減少させるという推薦を提供します。
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. 序論…2 2. 用語…3 3. 適用性声明…4 4. 概観と機能について議定書の中で述べてください…4 5. ジター…5 5.1. 周期的なメッセージ世代…5 5.2. 外部的に、メッセージ世代の引き金となります…6 5.3. メッセージ推進…7 5.4. 最大のジター決断…8 6. セキュリティ問題…9 7. 参照…10 7.1. 標準の参照…10 7.2. 有益な参照…10 付録A.承認…11
Clausen, et al. Informational [Page 1] RFC 5148 Jitter February 2008
クローゼン、他 [1ページ]情報のRFC5148ジター2008年2月
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.
定期的に予定されているメッセージ--その結果、また、同時に同じタイプの定期的に予定されているメッセージを含んで、典型的であることで、そのままで同じメッセージ間隔を費やしているなら2つのノードがパケットを発生させると、同時に、これらのメッセージのさらなるすべての送信があるでしょう。 以下のメカニズムがこれをありそうな発生にするかもしれないことに注意してください。
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.
出来事で引き起こされたメッセージ--ノードがそれらの近所でそれらの事情、特定の変化で変化に応じると、即座のメッセージ世代とトランスミッションで、同じ変化に応じる2つの近いノードが同時に、メッセージを送るでしょう。
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.
推進--ノードが彼らが他のノードから受け取るメッセージを転送すると、近いノードは、一般的に同じメッセージを受け取って、転送するでしょう。 推進がすぐに実行されるなら、結果として起こるパケット伝送は互いを妨げるかもしれません。
Clausen, et al. Informational [Page 2] RFC 5148 Jitter February 2008
クローゼン、他 [2ページ]情報のRFC5148ジター2008年2月
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]で使われます。そこでは定期的に予定されているメッセージのためのトランスミッション間隔が小さくて、境界があって無作為の量で短縮されます、そして、送信機を反連動させて、その結果、受信機と同様にトランスミッション媒体を積みすぎるのを避けます。 このドキュメントは、モバイルAd hoc NETworks(MANETs)のパケット伝送を制御するためにジターを適用するための推薦について議論して、提供します、衝突を避ける目的で、上にリストアップされた特徴に特に関連して。
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?
Additionally, this document uses the following terminology:
さらに、このドキュメントは以下の用語を使用します:
Node - A MANET router that implements a message sending protocol.
ノード--メッセージ送信プロトコルを実行するマネルータ。
MANET interface - A network device participating in a MANET. A node may have one or more MANET interfaces.
マネインタフェース--マネに参加するネットワーク装置。 ノードには、1つ以上のマネインタフェースがあるかもしれません。
Message - An entity carrying protocol information intended for exchange between nodes. Messages are transmitted over MANET interfaces embedded in packets.
メッセージ--ノードの間の交換のために意図するプロトコル情報を運ぶ実体。 メッセージはパケットに埋め込まれたマネインタフェースの上に送られます。
Packet - An entity embedding zero or more messages for transmission over a MANET interface of the node.
パケット--ノードのマネインタフェースの上のトランスミッションへのゼロを埋め込む実体か、より多くのメッセージ。
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.
トランスミッション--ノードのマネインタフェースの上に送られるパケット。 トランスミッションは発生するメッセージか転送されるメッセージのどちらかのためであることができます。
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.
世代--ノードの1つ以上のマネインタフェースの上のトランスミッションへの新しいメッセージ(受け取られていていて転送されたメッセージよりむしろ)の創造。 通常、ノードはメッセージスケジュール(周期的であるかそうでない)に基づいた変化への応答として事情でメッセージを発生させるでしょう。
Forwarding - Retransmission of a received message (whether modified or unchanged) over one or more MANET interfaces of the node.
推進--ノードの1つ以上の容認されたメッセージ(変更されているか、または変わりがないことにかかわらず)マネインタフェースのRetransmission。
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
衝突、--、2つ以上のノードが干渉同時間と同じ信号の中でパケットを伝えるところで特定の例がそのようなものを区切る(同じ頻度、そして/または、コード化で)それ
Clausen, et al. Informational [Page 3] RFC 5148 Jitter February 2008
クローゼン、他 [3ページ]情報のRFC5148ジター2008年2月
another, closely located, node that should receive and decode these packets instead fails to do so, and loses one or more of the packets.
密接に見つけられています、別のもの、これらのパケットを受けて、解読するはずであるノードが代わりにそうしないで、パケットの1つ以上を失います。
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.
本書では説明されたメカニズムはメカニズムを含む異なったノードによる両方向同時伝送が望ましくないどんなマネプロトコルのコントロールメッセージにも適切です、起こるとき、繰り返されるためにおそらく、両方向同時伝送、または原因を1つにする周期的なコントロールメッセージ送信、引き起こされたコントロールメッセージ送信、またはコントロールメッセージ推進などのように。 これは、ワイヤレス・ネットワーク([5] 雇用などの先を見越すマネルーティング・プロトコルは[6] 雇用などの反応マネルーティング・プロトコルが出来事でメッセージの引き金となったメッセージの計画をしました、そして、両方がメッセージ推進を使う)に放送送信を使用することでプロトコルに特に適用されます。
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].
ドキュメントは先を見越すマネルーティング・プロトコルOLSR(Optimized Link州ルート設定プロトコル)[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.
このドキュメントはマネルーティング・プロトコルによって使用されるかもしれないメッセージ送信(そして、「再-トランスミッション」)のための推薦を提供します。 また、それはワイヤレスインターフェースをひく周期的であるか引き起こされたメッセージスケジュールを使う他のプロトコルによって使用されるかもしれません。 2つ(さらに)の隣接しているノードからそのような同時のメッセージ送信を使用すると、遅れ、パケット損失、および他の問題は引き起こされるかもしれません。ここに概説されているようにジターを使用するどんなプロトコルもそのままで相互運用性に必要な状態で正確な用法をその程度において指定しなければなりません。
Clausen, et al. Informational [Page 4] RFC 5148 Jitter February 2008
クローゼン、他 [4ページ]情報のRFC5148ジター2008年2月
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.
マネでノードを防ぐには、ノードで最大のノード自治のマネの特性、パケットのトランスミッション時間の無作為化を保有している間にジター、SHOULDとして知られている両方向同時伝送から、使われてください。 3つのジターメカニズム、この問題、SHOULDのどの目標の続行と異なった局面が両方向同時伝送の見込みを減少させる目的と、起こるときそれを防ぐと共に使われますか?
Three cases exist:
3つのケースが存在しています:
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.
これらのケースの1番目において、ジターは連続したメッセージ送信の間隔を無作為の量で短縮するのに使用されます。 後者の2つのケースにおいて、ジターは、無作為の量によって発生するか、または転送されるメッセージを遅らせるのに使用されます。
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は、それが導入する最大のタイミング変化のためにそれぞれに関するこれらのケースがパラメタを使用するのを指示しました。 これらのケースの1つ以上がプロトコルによって使用されるなら、それは各ケースに同じくらいかMAXJITTERの異価を使用するかもしれません。 また、それは、メッセージタイプに従ってMAXJITTERの同じであるか異なった値を使用して、特定の、しかし、他のパラメタの異なった状況(メッセージ間隔などの)で異なるかもしれません。
Issues relating to the value of MAXJITTER are considered in Section 5.4.
MAXJITTERの値に関連する問題がセクション5.4で考えられます。
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は、ノードがメッセージを定期的に発生させるとき、2つの連続したメッセージが明確な間隔のそばで切り離されるのを指示しました。 ノードは例えば、異なったメッセージタイプか異なった事情(混雑を避けるためにトランスミッションを戻すことなどの)でそのような間隔の1つ以上を維持するかもしれません。 ジターSHOULD、この遅れを無作為の量で減少させることによって、適用されてください、同じタイプに関するメッセージの連続した送信の間の遅れが等しいそう(MESSAGE_INTERVAL--ジター)、ジターが無作為の値であるところで。
Subtraction of the random value from the message interval ensures that the message interval never exceeds MESSAGE_INTERVAL, and does
メッセージ間隔からの無作為の価値の引き算は、メッセージ間隔がMESSAGE_INTERVALを決して超えないで、するのを確実にします。
Clausen, et al. Informational [Page 5] RFC 5148 Jitter February 2008
クローゼン、他 [5ページ]情報のRFC5148ジター2008年2月
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.
ジターはSHOULDを評価します。ゼロと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.
ノードがINTERVALが評価して、容易に確実にすることができるそれ自身のMESSAGE_を知るというどんな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.
内部の、または、外部の状態か出来事がノードでメッセージ世代の引き金となるかもしれません。 プロトコルによって、この状態はただ一つのメッセージ(包含、他、確認メッセージ)の世代、新しい周期的なメッセージスケジュールの開始、または既存の周期的なメッセージングの時期変更の引き金となるかもしれません。 1つ以上のノードが同じ出来事に応じそうであるならおそらく外部的に引き起こされたメッセージの間の衝突をします。 この見込み、外部的に引き起こされたメッセージSHOULDを減少させるために、いてください、無作為の持続時間でそれを遅らせることによって、jitteredしました。 そのようにjitteredされていますが、また、内部的に引き起こされたメッセージも適切であるかもしれません。 これはSHOULDを遅らせます。ゼロとMAXJITTERの間で一様に合間に発生してください。 定期的に伝えられたメッセージが時期変更されるなら、このSHOULDがこのディレイド・タイムに基づいて、その後のメッセージで、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).
それらが定期的に伝えられるか否かに関係なくも、メッセージが引き起こされるとき、プロトコルは同じタイプに関するメッセージの最小間隔を課すかもしれません、とMESSAGE_MIN_INTERVALが指示しました。 そのような間隔は必要でないことで、MESSAGE_MIN_INTERVALはゼロであると考えられます。 MESSAGE_MIN_INTERVALが非ゼロであるときに、どんなにまた、この間隔にジターによって減少されるのを許容する適切であってもそれはゼロです。 メッセージが送られるとき、したがって、次のメッセージはしばらくして(MESSAGE_MIN_INTERVAL--ジター)許容されています。 このジターSHOULD、合間にゼロと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を持っていますが、これはジッタリングによって減少させられるのを許容するように直観に反するように見えるかもしれません。 周期的なメッセージのMESSAGE_INTERVALを設定することでのMAXJITTERとMESSAGE_MIN_INTERVAL(メッセージ_間隔-MAXJITTER) >。
Clausen, et al. Informational [Page 6] RFC 5148 Jitter February 2008
クローゼン、他 [6ページ]情報のRFC5148ジター2008年2月
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が2つのその後のメッセージ送信の間で経過するのを確実にするでしょう。 外部トリガーはしかしながら、引き起こされたメッセージがある非常にダイナミックなネットワークでは、外部の事情がそのようなものであるかもしれないので、MESSAGE_MIN_INTERVALより頻繁です、事実上、MESSAGE_MIN_INTERVALにメッセージが送られる「デフォルト」間隔としてMESSAGE_INTERVALの役割をみなさせて。 この非常にダイナミックなケース、ジッタリングSHOULDにおける同期を避けてください。このようにして、MESSAGE_MIN_INTERVALに適用されます。 また、ジターが使用されてさえいるとき、これは、MESSAGE_MIN_INTERVALがMESSAGE_INTERVALと等しいことを許可します。
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).
また、引き起こされたメッセージがジターで遅れるとき、ノードは引き起こされたメッセージの世代を延期するかもしれません。 次に、ノードが待っている間、同じタイプに関するメッセージを発生させるように引き起こされるなら、それはただ一つのメッセージを発生させることができます。 引き起こされて、次に、aを受けるとき、ノードがメッセージをどのように発生させてもそれを送るのを待っている間、別の引き金が通信するなら、取る適切な行動はプロトコル詳細(通常、以前のメッセージを捨てるか、またはメッセージオーダーを維持するようにことによるとタイミングを変更して、両方を伝える)です。
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.
ノードはメッセージを転送して、それはSHOULDです。いつ、無作為の持続時間でそれを遅らせながら、jitteredされるか。 これはSHOULDを遅らせます。ゼロと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の価値を意識していません。(INTERVALは有効であることが知られているMAXJITTERの値を選択しなければなりません)。 これがMESSAGE_INTERVALの値(または、最小値)に関して事前同意を必要とするかもしれなくて、MESSAGE_INTERVAL(最後のメッセージ以来の時間よりむしろ次の関連メッセージまでの時間)に関するメッセージでの包含であるか、またはいかなる他のプロトコルの特定のメカニズムでもあるかもしれません。(それは、容認されたメッセージ時間に基づくMESSAGE_INTERVALの価値に関する見積りを含むかもしれません)。
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
多くの場合、[7]の完全な機能性を使用することで[5]とプロトコルを含んでいて、メッセージはホップごとに中に送られます。
Clausen, et al. Informational [Page 7] RFC 5148 Jitter February 2008
クローゼン、他 [7ページ]情報のRFC5148ジター2008年2月
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.
潜在的にそれらのメッセージのパケットと、いくつかかすべてが転送される必要があるかもしれないマルチメッセージ。 単一のパケットでこのSHOULDは効率のための、そうです、そして、したがって、すべてのメッセージの推進ジターは単一のパケットでSHOULDを受けました。同じであってください。 (また、これは、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の1つ以上の例)がどのように断固とするかもしれないかを考える際に、以下のポイントに注意するかもしれません:
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 SHOULDがいつも最小にされて、許容できて達成を条件としてそれは熱心です。
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;
* それはMESSAGE_INTERVAL/2よりすばらしいはずがありません。
* it SHOULD NOT be greater than MESSAGE_INTERVAL/4.
* それ、SHOULD NOT、MESSAGE_INTERVAL/4よりすばらしくいてください。
o If MESSAGE_MIN_INTERVAL > 0, then:
o MESSAGE_MIN_INTERVAL>0、その時なら:
* MAXJITTER MUST NOT be greater than MESSAGE_MIN_INTERVAL;
* MAXJITTER MUST NOT、MESSAGE_MIN_INTERVALよりすばらしくいてください。
* MAXJITTER SHOULD NOT be greater than MESSAGE_MIN_INTERVAL/2.
* MAXJITTER SHOULD NOT、MESSAGE_MIN_INTERVAL/2よりすばらしくいてください。
Clausen, et al. Informational [Page 8] RFC 5148 Jitter February 2008
クローゼン、他 [8ページ]情報のRFC5148ジター2008年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パラメタSHOULDの媒体アクセス制御と下層、選択に依存するジターを使用するかどうかに関する決定と同様に、それらのメカニズムに適切にしてください。例えば、MAXJITTERがかなり優れるべきである、(例えば、1桁よりすばらしい、)、どんな媒体アクセス制御フレームの期間。
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.
しかしながら、トランスミッション時間の予測をして、その結果、選択的にジャムトランスミッションがプロトコルメッセージ送信と同時に起こる計画をすることでプロトコルが機能する状態で故意の妨害をするのでこれらの推薦による無作為のタイミングの導入が何らかのセキュリティ上の利点をそのようなプロトコルに提供するかもしれないことに注意されるかもしれません、より難しいです。
Clausen, et al. Informational [Page 9] RFC 5148 Jitter February 2008
クローゼン、他 [9ページ]情報のRFC5148ジター2008年2月
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] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
7.2. Informative References
7.2. 有益な参照
[2] Moy, J., "OSPF Database Overflow", RFC 1765, March 1995.
[2]Moy、J.、「OSPFデータベースオーバーフロー」、RFC1765、1995年3月。
[3] Marlow, D., "Host Group Extensions for CLNP Multicasting", RFC 1768, March 1995.
[3] マーロウ、D.、「CLNPマルチキャスティングのためのホスト群拡大」、RFC1768、1995年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.(エド)、李、T.(エド)、およびS.野兎(エド)、「境界ゲートウェイは4(BGP-4)について議定書の中で述べます」、RFC4271、2006年1月。
[5] Clausen, T., Ed., and P. Jacquet, Ed., "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003.
[5] クローゼン、T.、エド、エドP.ジャケ、RFC3626、「最適化されたリンク州はプロトコル(OLSR)を発送すること」での10月2003日
[6] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing", RFC 3561, July 2003.
[6] パーキンス、C.、ベルディング-ロワイエー、E.、およびS.ダス、「臨時のOn-要求Distance Vector(AODV)ルート設定」、RFC3561、2003年7月。
[7] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized MANET Packet/Message Format", Work in Progress.
クローゼンとT.とDearloveとC.とディーン、J.とC.Adjih、「一般化されたマネパケット/メッセージ・フォーマット」が進行中で扱う[7]。
Clausen, et al. Informational [Page 10] RFC 5148 Jitter February 2008
クローゼン、他 [10ページ]情報のRFC5148ジター2008年2月
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).
作者はマネワーキンググループとOLSRv2 Designチームを承認したがっています、特定のジョーMackerとジャスティン・ディーンで(両方、NRL)、開発とテストにおける彼らの貢献と議論のために、概念はこのドキュメント、およびアランで彼のこの仕様の慎重なレビューのためのカレン(BAE Systems)を保有しました。 [5]で指定されるOLSRv1がコントロール交通でジターの概念を紹介した、(そして両方、オールボア大学)。交通はGitteハンセンとラースクリステンセンによって徹底的にテストされました。
Authors' Addresses
作者のアドレス
Thomas Heide Clausen LIX, Ecole Polytechnique, France
トーマスハイデクローゼンLIX、Ecole Polytechnique、フランス
Phone: +33 6 6058 9349 EMail: T.Clausen@computer.org URI: http://www.ThomasClausen.org/
以下に電話をしてください。 +33 6 6058 9349はメールされます: T.Clausen@computer.org ユリ: http://www.ThomasClausen.org/
Christopher Dearlove BAE Systems Advanced Technology Centre
クリストファーDearlove BAEシステム先進技術センター
Phone: +44 1245 242194 EMail: chris.dearlove@baesystems.com URI: http://www.baesystems.com/
以下に電話をしてください。 +44 1245 242194はメールされます: chris.dearlove@baesystems.com ユリ: 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/
以下に電話をしてください。 +1 1194年の202 404メール: adamson@itd.nrl.navy.mil ユリ: http://www.nrl.navy.mil/
Clausen, et al. Informational [Page 11] RFC 5148 Jitter February 2008
クローゼン、他 [11ページ]情報のRFC5148ジター2008年2月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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-ipr@ietf.org のIETFに情報を記述してください。
Clausen, et al. Informational [Page 12]
クローゼン、他 情報[12ページ]
一覧
スポンサーリンク