RFC3561 日本語訳
3561 Ad hoc On-Demand Distance Vector (AODV) Routing. C. Perkins, E.Belding-Royer, S. Das. July 2003. (Format: TXT=90356 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Perkins
Request for Comments: 3561 Nokia Research Center
Category: Experimental E. Belding-Royer
University of California, Santa Barbara
S. Das
University of Cincinnati
July 2003
コメントを求めるワーキンググループC.パーキンス要求をネットワークでつないでください: 3561年のノキアリサーチセンターカテゴリ: 実験的なE.ベルディング-ロワイエーカリフォルニア大学、サンタバーバラS.ダスシンシナティ大学2003年7月
Ad hoc On-Demand Distance Vector (AODV) Routing
臨時のOn-要求Distance Vector(AODV)ルート設定
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and determines unicast routes to destinations within the ad hoc network. It uses destination sequence numbers to ensure loop freedom at all times (even in the face of anomalous delivery of routing control messages), avoiding problems (such as "counting to infinity") associated with classical distance vector protocols.
Ad hoc On-要求Distance Vector(AODV)ルーティング・プロトコルは使用のために可動のノードで臨時のネットワークで意図します。 それは、ダイナミックなリンク状態、低い処理、およびメモリの頭上の、そして、低いネットワーク利用への迅速な適合を提供して、臨時のネットワークの中でユニキャストルートを目的地に決定します。 それはいつも(ルーティングコントロールメッセージの変則的な配送に直面してさえ)輪の自由を確実にするのに目的地一連番号を使用します、古典的な距離ベクトルプロトコルに関連している問題(「無限勘定」などであることなどの)を避けて。
Table of Contents
目次
1. Introduction ............................................... 2
2. Overview .................................................. 3
3. AODV Terminology ........................................... 4
4. Applicability Statement .................................... 6
5. Message Formats ............................................ 7
5.1. Route Request (RREQ) Message Format ................... 7
5.2. Route Reply (RREP) Message Format ..................... 8
5.3. Route Error (RERR) Message Format ..................... 10
5.4. Route Reply Acknowledgment (RREP-ACK) Message Format .. 11
6. AODV Operation ............................................. 11
6.1. Maintaining Sequence Numbers .......................... 11
6.2. Route Table Entries and Precursor Lists ............... 13
1. 序論… 2 2. 概観… 3 3. AODV用語… 4 4. 適用性声明… 6 5. メッセージ形式… 7 5.1. 要求(RREQ)メッセージ・フォーマットを発送してください… 7 5.2. 回答(RREP)メッセージ・フォーマットを発送してください… 8 5.3. 誤り(RERR)メッセージ・フォーマットを発送してください… 10 5.4. 回答承認(RREP-ACK)メッセージ・フォーマットを発送してください。 11 6. AODV操作… 11 6.1. 一連番号を維持します… 11 6.2. テーブル項目と先駆リストを発送してください… 13
Perkins, et. al. Experimental [Page 1] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[1ページ]RFC3561AODV
6.3. Generating Route Requests ............................. 14
6.4. Controlling Dissemination of Route Request Messages ... 15
6.5. Processing and Forwarding Route Requests .............. 16
6.6. Generating Route Replies .............................. 18
6.6.1. Route Reply Generation by the Destination ...... 18
6.6.2. Route Reply Generation by an Intermediate
Node ........................................... 19
6.6.3. Generating Gratuitous RREPs .................... 19
6.7. Receiving and Forwarding Route Replies ................ 20
6.8. Operation over Unidirectional Links ................... 21
6.9. Hello Messages ........................................ 22
6.10 Maintaining Local Connectivity ........................ 23
6.11 Route Error (RERR) Messages, Route Expiry and Route
Deletion .............................................. 24
6.12 Local Repair .......................................... 26
6.13 Actions After Reboot ................................. 27
6.14 Interfaces ............................................ 28
7. AODV and Aggregated Networks ............................... 28
8. Using AODV with Other Networks ............................. 29
9. Extensions ................................................. 30
9.1. Hello Interval Extension Format ....................... 30
10. Configuration Parameters ................................... 31
11. Security Considerations .................................... 33
12. IANA Considerations ........................................ 34
13. IPv6 Considerations ........................................ 34
14. Acknowledgments ............................................ 34
15. Normative References ....................................... 35
16. Informative References ..................................... 35
17. Authors' Addresses ......................................... 36
18. Full Copyright Statement ................................... 37
6.3. ルート要求を発生させます… 14 6.4. ルートの普及を制御して、メッセージを要求してください… 15 6.5. 処理と推進は要求を発送します… 16 6.6. ルートを発生させるのは返答します… 18 6.6.1. 目的地のそばで回答世代を発送してください… 18 6.6.2. 中間的ノードは回答世代を発送してください… 19 6.6.3. 無料のRREPsを発生させます… 19 6.7. 受信と推進は回答を発送します… 20 6.8. 単方向の間の操作はリンクされます… 21 6.9. こんにちは、メッセージ… 22 6.10 ローカルの接続性を維持します… 23 6.11 誤り(RERR)メッセージ、ルート満期、およびルート削除を発送してください… 24 6.12 地方の修理… リブートの後の26 6.13の動作… 27 6.14 連結します… 28 7. AODVと集められたネットワーク… 28 8. 他のネットワークがあるAODVを使用します… 29 9. 拡大… 30 9.1. こんにちは、間隔拡大形式… 30 10. 構成パラメタ… 31 11. セキュリティ問題… 33 12. IANA問題… 34 13. IPv6問題… 34 14. 承認… 34 15. 標準の参照… 35 16. 有益な参照… 35 17. 作者のアドレス… 36 18. 完全な著作権宣言文… 37
1. Introduction
1. 序論
The Ad hoc On-Demand Distance Vector (AODV) algorithm enables dynamic, self-starting, multihop routing between participating mobile nodes wishing to establish and maintain an ad hoc network. AODV allows mobile nodes to obtain routes quickly for new destinations, and does not require nodes to maintain routes to destinations that are not in active communication. AODV allows mobile nodes to respond to link breakages and changes in network topology in a timely manner. The operation of AODV is loop-free, and by avoiding the Bellman-Ford "counting to infinity" problem offers quick convergence when the ad hoc network topology changes (typically, when a node moves in the network). When links break, AODV causes the affected set of nodes to be notified so that they are able to invalidate the routes using the lost link.
臨時のネットワークを設立して、維持することを願いながら、Ad hoc On-要求Distance Vector(AODV)アルゴリズムは参加の可動のノードの間でダイナミックで、自己を始めるマルチホップルーティングを可能にします。 AODVは、可動のノードがすぐに新しい目的地にルートを入手するのを許容して、アクティブコミュニケーションにない目的地にルートを維持するためにノードを必要としません。 AODVは、直ちにネットワーク形態における折損と変化をリンクするために可動のノードを応じさせます。 AODVの操作は輪なしです、そして、臨時のネットワーク形態が変化するとき(ノードが通常ネットワークに入って来るとき)、「無限で数え」ながらBellman-フォードを避けることによって、問題は迅速な集合を提供します。 リンクが壊れると、AODVが影響を受けるセットのノードを通知させるので、それらは無くなっているリンクを使用することでルートを無効にすることができます。
Perkins, et. al. Experimental [Page 2] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[2ページ]RFC3561AODV
One distinguishing feature of AODV is its use of a destination sequence number for each route entry. The destination sequence number is created by the destination to be included along with any route information it sends to requesting nodes. Using destination sequence numbers ensures loop freedom and is simple to program. Given the choice between two routes to a destination, a requesting node is required to select the one with the greatest sequence number.
AODVの1つの区別の特徴は目的地一連番号のそのそれぞれのルートエントリーの使用です。 目的地一連番号は目的地によって作成されて、それがノードを要求するのに送るどんな経由地案内と共にも含まれています。 目的地一連番号を使用するのは、輪の自由を確実にして、プログラムするのは簡単です。 目的地への2つのルートの選択を考えて、要求ノードが、最大級の一連番号に従ったものを選択するのに必要です。
2. Overview
2. 概観
Route Requests (RREQs), Route Replies (RREPs), and Route Errors (RERRs) are the message types defined by AODV. These message types are received via UDP, and normal IP header processing applies. So, for instance, the requesting node is expected to use its IP address as the Originator IP address for the messages. For broadcast messages, the IP limited broadcast address (255.255.255.255) is used. This means that such messages are not blindly forwarded. However, AODV operation does require certain messages (e.g., RREQ) to be disseminated widely, perhaps throughout the ad hoc network. The range of dissemination of such RREQs is indicated by the TTL in the IP header. Fragmentation is typically not required.
ルートRequests(RREQs)、Route Replies(RREPs)、およびRoute Errors(RERRs)はAODVによって定義されたメッセージタイプです。 UDPを通してこれらのメッセージタイプを受け取ります、そして、通常のIPヘッダー処理は適用されます。 そのように、そして、例えば、要求ノードがメッセージにOriginator IPアドレスとしてIPアドレスを使用すると予想されます。 同報メッセージに関して、IPが放送演説を制限した、(255.255 .255 .255は)使用されています。 これは、そのようなメッセージが盲目的に転送されないことを意味します。 しかしながら、AODV操作は、あるメッセージ(例えば、RREQ)が恐らく臨時のネットワーク中で広く広められるのを必要とします。 そのようなRREQsの普及の範囲はIPヘッダーでTTLによって示されます。 断片化は通常必要ではありません。
As long as the endpoints of a communication connection have valid routes to each other, AODV does not play any role. When a route to a new destination is needed, the node broadcasts a RREQ to find a route to the destination. A route can be determined when the RREQ reaches either the destination itself, or an intermediate node with a 'fresh enough' route to the destination. A 'fresh enough' route is a valid route entry for the destination whose associated sequence number is at least as great as that contained in the RREQ. The route is made available by unicasting a RREP back to the origination of the RREQ. Each node receiving the request caches a route back to the originator of the request, so that the RREP can be unicast from the destination along a path to that originator, or likewise from any intermediate node that is able to satisfy the request.
コミュニケーション接続の終点が有効なルートを互いに持っている限り、AODVはどんな役割も果たしません。 新しい目的地へのルートが必要であるときに、ノードは、目的地にルートを見つけるためにRREQを放送します。 '十分新鮮な'ルートでRREQが目的地自体か中間的ノードのどちらかに目的地に達するとき、ルートは決定している場合があります。 '十分新鮮な'ルートは関連一連番号がRREQに含まれたそれと少なくとも同じくらい大きい目的地のための有効なルートエントリーです。 RREQの創作にRREPをunicastingして戻すことによって、ルートを利用可能にします。 要求を受け取る各ノードが要求の創始者にルートをキャッシュして戻します、RREPが経路に沿った目的地からその創始者まで同様な要望に応じることができるどんな中間的ノードからもユニキャストになるように。
Nodes monitor the link status of next hops in active routes. When a link break in an active route is detected, a RERR message is used to notify other nodes that the loss of that link has occurred. The RERR message indicates those destinations (possibly subnets) which are no longer reachable by way of the broken link. In order to enable this reporting mechanism, each node keeps a "precursor list", containing the IP address for each its neighbors that are likely to use it as a next hop towards each destination. The information in the precursor lists is most easily acquired during the processing for generation of a RREP message, which by definition has to be sent to a node in a precursor list (see section 6.6). If the RREP has a nonzero prefix
ノードはアクティブなルートで次のホップのリンク状態をモニターします。 アクティブなルートによるリンク中断が検出されるとき、RERRメッセージは、そのリンクの損失が発生したことを他のノードに通知するのに使用されます。 RERRメッセージはそれらのもうリンク切れを通して届いていない目的地(ことによるとサブネット)を示します。 メカニズム、各ノードが「先駆リスト」を保つと報告しながらこれを可能にして、IPを含んで、それぞれのために次のホップとして各目的地に向かってそれを使用しそうな隣人に演説してください。 RREPメッセージの世代のために処理の間、最も容易に先駆リストの情報を取得します(セクション6.6を見てください)。(メッセージは定義上先駆リストのノードに送られなければなりません)。 RREPに非零接頭語があるなら
Perkins, et. al. Experimental [Page 3] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[3ページ]RFC3561AODV
length, then the originator of the RREQ which solicited the RREP information is included among the precursors for the subnet route (not specifically for the particular destination).
長さ、そして、RREP情報に請求したRREQの創始者はサブネットルート(特に特定の目的地でないことへの)への先駆の中に含まれています。
A RREQ may also be received for a multicast IP address. In this document, full processing for such messages is not specified. For example, the originator of such a RREQ for a multicast IP address may have to follow special rules. However, it is important to enable correct multicast operation by intermediate nodes that are not enabled as originating or destination nodes for IP multicast addresses, and likewise are not equipped for any special multicast protocol processing. For such multicast-unaware nodes, processing for a multicast IP address as a destination IP address MUST be carried out in the same way as for any other destination IP address.
また、マルチキャストIPアドレスのためにRREQを受け取るかもしれません。 本書では、そのようなメッセージのための完全な処理は指定されません。 例えば、マルチキャストIPアドレスのためのそのようなRREQの創始者は特別な規則に従わなければならないかもしれません。 しかしながら、それをIPマルチキャストアドレスのための由来するとして可能にされない中間的ノードか目的地ノードで正しいマルチキャスト操作を可能にするために重要であり、どんな特別なマルチキャストプロトコル処理のためにも同様に備えていません。 同様に、そのようなマルチキャスト気づかないノードに関しては、いかなる他の送付先IPアドレスのようにも送付先IPアドレスとしてのマルチキャストIPアドレスのための処理を行わなければなりません。
AODV is a routing protocol, and it deals with route table management. Route table information must be kept even for short-lived routes, such as are created to temporarily store reverse paths towards nodes originating RREQs. AODV uses the following fields with each route table entry:
AODVはルーティング・プロトコルです、そして、それはルートテーブル管理と取り引きします。 一時ノードの由来しているRREQsに向かって逆の経路を格納するために作成されるような短命なルートに同等にルートテーブル情報を保たなければなりません。 AODVはそれぞれのルートテーブルエントリーがある以下の分野を使用します:
- Destination IP Address
- Destination Sequence Number
- Valid Destination Sequence Number flag
- Other state and routing flags (e.g., valid, invalid, repairable,
being repaired)
- Network Interface
- Hop Count (number of hops needed to reach destination)
- Next Hop
- List of Precursors (described in Section 6.2)
- Lifetime (expiration or deletion time of the route)
- IP Address--目的地Sequence Number--有効なDestination Sequence Numberが旗を揚げさせる目的地--他の状態とルーティング旗(例えば修理された有効で、無効の、そして、修繕可能な存在)--ネットワークInterface--ホップCount(ホップの数は、目的地に達する必要があった)--次のHop--Precursors(セクション6.2では、説明される)のリスト--生涯(ルートの満了か削除時間)
Managing the sequence number is crucial to avoiding routing loops, even when links break and a node is no longer reachable to supply its own information about its sequence number. A destination becomes unreachable when a link breaks or is deactivated. When these conditions occur, the route is invalidated by operations involving the sequence number and marking the route table entry state as invalid. See section 6.1 for details.
輪を発送するのを避けるのに一連番号を管理するのは重要です、リンクが壊れて、ノードが一連番号のそれ自身の情報を提供するためにもう届かないときさえ。 リンクが壊れるか、または非活性化されるとき、目的地は手が届かなくなります。 これらの状態が現れるとき、ルートは一連番号を伴って、ルートテーブル項目州が無効であるとマークする操作で無効にされます。 詳細に関してセクション6.1を見てください。
3. AODV Terminology
3. AODV用語
This protocol specification uses conventional meanings [1] for capitalized words such as MUST, SHOULD, etc., to indicate requirement levels for various protocol features. This section defines other terminology used with AODV that is not already defined in [3].
仕様が大文字で書かれた単語のための従来の意味[1]を使用するこのプロトコルはそうしなければなりません、SHOULD、など、要件を示すのが様々なプロトコルのために特徴を平らにします。 このセクションは[3]で既に定義されないAODVと共に使用される他の用語を定義します。
Perkins, et. al. Experimental [Page 4] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[4ページ]RFC3561AODV
active route
アクティブなルート
A route towards a destination that has a routing table entry
that is marked as valid. Only active routes can be used to
forward data packets.
有効であるとして示される経路指定テーブルエントリーを持っている目的地に向かったルート。 データ・パケットを進めるのにアクティブなルートしか使用できません。
broadcast
放送
Broadcasting means transmitting to the IP Limited Broadcast
address, 255.255.255.255. A broadcast packet may not be
blindly forwarded, but broadcasting is useful to enable
dissemination of AODV messages throughout the ad hoc network.
放送は、.255にIP株式会社Broadcastアドレス、255.255に.255を伝えることを意味します。 放送パケットは盲目的に進められないかもしれませんが、放送は、臨時のネットワーク中でAODVメッセージの普及を可能にするために役に立ちます。
destination
目的地
An IP address to which data packets are to be transmitted.
Same as "destination node". A node knows it is the destination
node for a typical data packet when its address appears in the
appropriate field of the IP header. Routes for destination
nodes are supplied by action of the AODV protocol, which
carries the IP address of the desired destination node in route
discovery messages.
データ・パケットが伝えられることになっているIPアドレス。 「目的地ノード」と同じです。 ノードは、アドレスがIPヘッダーの適切な分野に現れるとき、それが典型的なデータ・パケットのための目的地ノードであることを知っています。 AODVプロトコルの動作で目的地ノードのためのルートを供給します。(プロトコルはルート発見メッセージの必要な目的地ノードのIPアドレスを運びます)。
forwarding node
推進ノード
A node that agrees to forward packets destined for another
node, by retransmitting them to a next hop that is closer to
the unicast destination along a path that has been set up using
routing control messages.
パケットを進めるのに同意するノードは別のノードのために運命づけました、セットアップされた経路に沿ったユニキャストの目的地の、より近くにルーティングコントロールメッセージを使用することである次のホップにそれらを再送することによって。
forward route
前進のルート
A route set up to send data packets from a node originating a
Route Discovery operation towards its desired destination.
ルートは必要な目的地に向かってRouteディスカバリー操作を溯源するノードから送信データパケットまでセットしました。
invalid route
無効のルート
A route that has expired, denoted by a state of invalid in the
routing table entry. An invalid route is used to store
previously valid route information for an extended period of
time. An invalid route cannot be used to forward data packets,
but it can provide information useful for route repairs, and
also for future RREQ messages.
それが経路指定テーブルエントリーで病人の州によって満期で、指示されるようにするルート。 無効のルートは、延ばされた期間の間、以前に有効な経由地案内を格納するのに使用されます。 データ・パケットを進めるのに無効のルートを使用できませんが、それはルート修理、および将来のRREQメッセージのも役に立つ情報を提供できます。
Perkins, et. al. Experimental [Page 5] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[5ページ]RFC3561AODV
originating node
由来しているノード
A node that initiates an AODV route discovery message to be
processed and possibly retransmitted by other nodes in the ad
hoc network. For instance, the node initiating a Route
Discovery process and broadcasting the RREQ message is called
the originating node of the RREQ message.
臨時のネットワークで処理されてことによると他のノードによって再送されるべきAODVルート発見メッセージを開始するノード。 例えば、Routeディスカバリーの過程に着手して、RREQメッセージを放送するノードはRREQメッセージの由来しているノードと呼ばれます。
reverse route
ルートを逆にしてください。
A route set up to forward a reply (RREP) packet back to the
originator from the destination or from an intermediate node
having a route to the destination.
目的地、または、ルートを持っている中間的ノードから目的地まで回答(RREP)パケットを創始者に送って戻すためにセットアップされたルート。
sequence number
一連番号
A monotonically increasing number maintained by each
originating node. In AODV routing protocol messages, it is
used by other nodes to determine the freshness of the
information contained from the originating node.
それぞれの由来しているノードによって維持された単調に増加する数。 AODVルーティング・プロトコルメッセージでは、それは他のノードによって使用されて、由来しているノードから含まれた情報の新しさを決定します。
valid route
有効なルート
See active route.
アクティブなルートを見てください。
4. Applicability Statement
4. 適用性証明
The AODV routing protocol is designed for mobile ad hoc networks with populations of tens to thousands of mobile nodes. AODV can handle low, moderate, and relatively high mobility rates, as well as a variety of data traffic levels. AODV is designed for use in networks where the nodes can all trust each other, either by use of preconfigured keys, or because it is known that there are no malicious intruder nodes. AODV has been designed to reduce the dissemination of control traffic and eliminate overhead on data traffic, in order to improve scalability and performance.
AODVルーティング・プロトコルは可動の臨時のネットワークのために10の人口で何千もの可動のノードに設計されています。 AODVは低、そして、適度の、そして、比較的高い移動性レート、およびさまざまなデータ通信量レベルを扱うことができます。 AODVはあらかじめ設定されたキーか、どんな悪意がある侵入者ノードもないのが知られているのでノードがすべて、使用のどちらかで互いを信じることができるネットワークにおける使用のために設計されています。 AODVはコントロール交通の普及を減少させて、データ通信量でのオーバーヘッドを取り除くように設計されています、スケーラビリティと性能を向上させるために。
Perkins, et. al. Experimental [Page 6] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[6ページ]RFC3561AODV
5. Message Formats
5. メッセージ・フォーマット
5.1. Route Request (RREQ) Message Format
5.1. ルート要求(RREQ)メッセージ・フォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |J|R|G|D|U| Reserved | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RREQ ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ|J|R|G|D|U| 予約されます。| ホップカウント| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RREQ ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付先IPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目的地一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 創始者IPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 創始者一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Route Request message is illustrated above, and contains the following fields:
Route Requestメッセージの形式は、以下の分野を上で例証されて、含んでいます:
Type 1
1をタイプしてください。
J Join flag; reserved for multicast.
Jは旗を接合します。 マルチキャストのために、予約されます。
R Repair flag; reserved for multicast.
R修理旗。 マルチキャストのために、予約されます。
G Gratuitous RREP flag; indicates whether a
gratuitous RREP should be unicast to the node
specified in the Destination IP Address field (see
sections 6.3, 6.6.3).
G無料のRREPは弛みます。 無料のRREPがDestination IP Address分野で指定されたノードへのユニキャストであるべきである(セクション6.3、6.6.3を見る)か否かに関係なく、示します。
D Destination only flag; indicates only the
destination may respond to this RREQ (see
section 6.5).
Dの目的地は弛むだけです。 目的地だけがこのRREQに応じるかもしれないのを(セクション6.5を見てください)示します。
U Unknown sequence number; indicates the destination
sequence number is unknown (see section 6.3).
U未知の一連番号。 目的地一連番号が未知であることを(セクション6.3を見てください)示します。
Reserved Sent as 0; ignored on reception.
0として送った状態で、予約されます。 レセプションでは、無視されます。
Hop Count The number of hops from the Originator IP Address
to the node handling the request.
Countを飛び越してください。Originator IP Addressからノードまでのホップが要求を扱う数。
Perkins, et. al. Experimental [Page 7] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[7ページ]RFC3561AODV
RREQ ID A sequence number uniquely identifying the
particular RREQ when taken in conjunction with the
originating node's IP address.
由来しているノードのIPアドレスに関連して取ると唯一特定のRREQを特定するRREQ ID A一連番号。
Destination IP Address
The IP address of the destination for which a route
is desired.
IPが記述するルートが望まれている目的地の目的地IP Address。
Destination Sequence Number
The latest sequence number received in the past
by the originator for any route towards the
destination.
最新の一連番号の目的地Sequence Numberは過去に創始者のそばで目的地に向かったどんなルートにも受信しました。
Originator IP Address
The IP address of the node which originated the
Route Request.
IPが記述するRoute Requestを溯源したノードの創始者IP Address。
Originator Sequence Number
The current sequence number to be used in the route
entry pointing towards the originator of the route
request.
ルート要求の創始者を示すルートエントリーで使用されるべき現在の一連番号の創始者Sequence Number。
5.2. Route Reply (RREP) Message Format
5.2. ルート回答(RREP)メッセージ・フォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |R|A| Reserved |Prefix Sz| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ|R|A| 予約されます。|接頭語Sz| ホップカウント| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付先IPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目的地一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 創始者IPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Route Reply message is illustrated above, and contains the following fields:
Route Replyメッセージの形式は、以下の分野を上で例証されて、含んでいます:
Type 2
2をタイプしてください。
R Repair flag; used for multicast.
R修理旗。 マルチキャストにおいて、使用されています。
A Acknowledgment required; see sections 5.4 and 6.7.
Acknowledgmentが必要です。 セクション5.4と6.7を見てください。
Reserved Sent as 0; ignored on reception.
0として送った状態で、予約されます。 レセプションでは、無視されます。
Perkins, et. al. Experimental [Page 8] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[8ページ]RFC3561AODV
Prefix Size If nonzero, the 5-bit Prefix Size specifies that the
indicated next hop may be used for any nodes with
the same routing prefix (as defined by the Prefix
Size) as the requested destination.
Size If非零を前に置いてください、要求された目的地として同じルーティング接頭語でどんなノードにおいてPrefix Sizeが指定する次のホップがそうする表示がある中古さ5ビットです(Prefix Sizeによって定義されるように)。
Hop Count The number of hops from the Originator IP Address
to the Destination IP Address. For multicast route
requests this indicates the number of hops to the
multicast tree member sending the RREP.
Countを飛び越してください。Originator IP AddressからDestination IP Addressまでのホップの数。 マルチキャストルート要求のために、これはRREPを送るマルチキャスト木のメンバーにホップの数を示します。
Destination IP Address
The IP address of the destination for which a route
is supplied.
IPが記述するルートが供給される目的地の目的地IP Address。
Destination Sequence Number
The destination sequence number associated to the
route.
ルートに関連している目的地一連番号の目的地Sequence Number。
Originator IP Address
The IP address of the node which originated the RREQ
for which the route is supplied.
IPが記述するルートが供給されるRREQを溯源したノードの創始者IP Address。
Lifetime The time in milliseconds for which nodes receiving
the RREP consider the route to be valid.
生涯、受信して、RREPがそれのノードに関してルートが有効であると考えるミリセカンドで表現される時間。
Note that the Prefix Size allows a subnet router to supply a route for every host in the subnet defined by the routing prefix, which is determined by the IP address of the subnet router and the Prefix Size. In order to make use of this feature, the subnet router has to guarantee reachability to all the hosts sharing the indicated subnet prefix. See section 7 for details. When the prefix size is nonzero, any routing information (and precursor data) MUST be kept with respect to the subnet route, not the individual destination IP address on that subnet.
Prefix SizeがサブネットルータにサブネットルータとPrefix SizeのIPアドレスで決定するルーティング接頭語によって定義されたサブネットですべてのホストにルートを提供させることに注意してください。 この特徴を利用するために、サブネットルータは示されたサブネット接頭語を共有しているすべてのホストに可到達性を保証しなければなりません。 詳細に関してセクション7を見てください。 接頭語サイズが非零であるときに、そのサブネットに関する個々の送付先IPアドレスではなく、サブネットルートに関してどんなルーティング情報(そして、先駆データ)も保たなければなりません。
The 'A' bit is used when the link over which the RREP message is sent may be unreliable or unidirectional. When the RREP message contains the 'A' bit set, the receiver of the RREP is expected to return a RREP-ACK message. See section 6.8.
RREPメッセージが送って、頼り無いかもしれないということであるリンクか単方向ときに、'A'ビットは使用されています。 RREPメッセージが'A'噛み付いているセットを含むとき、RREPの受信機がRREP-ACKメッセージを返すと予想されます。 セクション6.8を見てください。
Perkins, et. al. Experimental [Page 9] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[9ページ]RFC3561AODV
5.3. Route Error (RERR) Message Format
5.3. ルート誤り(RERR)メッセージ・フォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |N| Reserved | DestCount |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreachable Destination IP Address (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreachable Destination Sequence Number (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Additional Unreachable Destination IP Addresses (if needed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Additional Unreachable Destination Sequence Numbers (if needed)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ|N| 予約されます。| DestCount| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 手の届かない送付先IPアドレス(1)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 手の届かない目的地一連番号(1)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | 追加Unreachable Destination IP Addresses(必要であるなら)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |追加Unreachable Destination Sequence民数記(必要であるなら)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Route Error message is illustrated above, and contains the following fields:
Route Errorメッセージの形式は、以下の分野を上で例証されて、含んでいます:
Type 3
3をタイプしてください。
N No delete flag; set when a node has performed a local
repair of a link, and upstream nodes should not delete
the route.
Nノー、は旗を削除します。 ノードがリンクの局部的修繕を実行したときにはセットしてください。そうすれば、上流のノードはルートを削除するはずがありません。
Reserved Sent as 0; ignored on reception.
0として送った状態で、予約されます。 レセプションでは、無視されます。
DestCount The number of unreachable destinations included in the
message; MUST be at least 1.
メッセージに手の届かない目的地の数を含んでいるDestCount。 少なくとも1はそうであるに違いありませんか?
Unreachable Destination IP Address
The IP address of the destination that has become
unreachable due to a link break.
IPが記述する手が届かなくなった目的地の手の届かないDestination IP Addressはリンクのため壊れます。
Unreachable Destination Sequence Number
The sequence number in the route table entry for
the destination listed in the previous Unreachable
Destination IP Address field.
目的地のためのルートテーブルエントリーにおける一連番号が前のUnreachable Destination IP Address分野に記載した手の届かないDestination Sequence Number。
The RERR message is sent whenever a link break causes one or more destinations to become unreachable from some of the node's neighbors. See section 6.2 for information about how to maintain the appropriate records for this determination, and section 6.11 for specification about how to create the list of destinations.
1つ以上の目的地がリンク中断によってノードの何人かの隣人から手が届かなくなるときはいつも、RERRメッセージを送ります。 この決断のために適切な記録を保守して、仕様のためにどうセクション6.11を保守するかの情報に関してどう目的地のリストを作成するかに関してセクション6.2を見てください。
Perkins, et. al. Experimental [Page 10] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[10ページ]RFC3561AODV
5.4. Route Reply Acknowledgment (RREP-ACK) Message Format
5.4. ルート回答承認(RREP-ACK)メッセージ・フォーマット
The Route Reply Acknowledgment (RREP-ACK) message MUST be sent in response to a RREP message with the 'A' bit set (see section 5.2). This is typically done when there is danger of unidirectional links preventing the completion of a Route Discovery cycle (see section 6.8).
'A'ビットがセットしたことでのRREPメッセージに対応してRoute Reply Acknowledgment(RREP-ACK)メッセージを送らなければなりません(セクション5.2を見てください)。 Routeディスカバリーサイクルの完成を防ぐ単方向のリンクの危険があるとき(セクション6.8を見てください)、通常これをします。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 4
4をタイプしてください。
Reserved Sent as 0; ignored on reception.
0として送った状態で、予約されます。 レセプションでは、無視されます。
6. AODV Operation
6. AODV操作
This section describes the scenarios under which nodes generate Route Request (RREQ), Route Reply (RREP) and Route Error (RERR) messages for unicast communication towards a destination, and how the message data are handled. In order to process the messages correctly, certain state information has to be maintained in the route table entries for the destinations of interest.
このセクションはどのノードがユニキャストコミュニケーションのためにRoute Request(RREQ)、Route Reply(RREP)、およびRoute Error(RERR)メッセージを目的地に向かって発生させるか、そして、メッセージデータがどのように扱われるかの下のシナリオについて説明します。 正しくメッセージを処理するために、ある州の情報は興味がある目的地のためのルートテーブルエントリーで保守されなければなりません。
All AODV messages are sent to port 654 using UDP.
UDPを使用することで654を移植するためにすべてのAODVメッセージを送ります。
6.1. Maintaining Sequence Numbers
6.1. 一連番号を維持します。
Every route table entry at every node MUST include the latest information available about the sequence number for the IP address of the destination node for which the route table entry is maintained. This sequence number is called the "destination sequence number". It is updated whenever a node receives new (i.e., not stale) information about the sequence number from RREQ, RREP, or RERR messages that may be received related to that destination. AODV depends on each node in the network to own and maintain its destination sequence number to guarantee the loop-freedom of all routes towards that node. A destination node increments its own sequence number in two circumstances:
あらゆるノードのあらゆるルートテーブルエントリーが一連番号に関してルートテーブルエントリーが維持される目的地ノードのIPアドレスに利用可能な最新情報を含まなければなりません。 この一連番号は「目的地一連番号」と呼ばれます。 ノードがRREQから一連番号の新しい(すなわち、聞き古したでない)情報を受け取るときはいつも、それをアップデートします、RREP、または、受け取られるかもしれないRERRメッセージはその目的地に関係しました。 AODVは、すべてのルートの輪自由をそのノードに向かって保証するために目的地一連番号を所有して、維持するためにネットワークにおける各ノードによります。 目的地ノードは2つの事情のそれ自身の一連番号を増加します:
- Immediately before a node originates a route discovery, it MUST
increment its own sequence number. This prevents conflicts with
previously established reverse routes towards the originator of a
RREQ.
- ノードがルート発見を溯源する直前、それはそれ自身の一連番号を増加しなければなりません。 これは以前に確立した逆のルートとの闘争をRREQの創始者に向かって防ぎます。
Perkins, et. al. Experimental [Page 11] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[11ページ]RFC3561AODV
- Immediately before a destination node originates a RREP in
response to a RREQ, it MUST update its own sequence number to the
maximum of its current sequence number and the destination
sequence number in the RREQ packet.
- 目的地ノードがRREQに対応してRREPを溯源する直前、それはRREQパケットで現在の一連番号と目的地一連番号の最大にそれ自身の一連番号をアップデートしなければなりません。
When the destination increments its sequence number, it MUST do so by treating the sequence number value as if it were an unsigned number. To accomplish sequence number rollover, if the sequence number has already been assigned to be the largest possible number representable as a 32-bit unsigned integer (i.e., 4294967295), then when it is incremented it will then have a value of zero (0). On the other hand, if the sequence number currently has the value 2147483647, which is the largest possible positive integer if 2's complement arithmetic is in use with 32-bit integers, the next value will be 2147483648, which is the most negative possible integer in the same numbering system. The representation of negative numbers is not relevant to the increment of AODV sequence numbers. This is in contrast to the manner in which the result of comparing two AODV sequence numbers is to be treated (see below).
目的地が一連番号を増加すると、それは、まるでそれが符号のない数であるかのように一連番号値を扱うことによって、そうしなければなりません。 そして、一連番号ロールオーバーを達成するために、増加されているとき、32ビットの符号のない整数(すなわち、4294967295)としての可能な限り大きい数の「表-可能」になるように既に一連番号を割り当ててあると、それには(0)がない値があるでしょう。 他方では、一連番号に値2147483647(2の補数演算が32ビットの整数で使用中であるなら、可能な限り大きい正の整数です)が現在あると、次の値はなるでしょう。(2147483648、その2147483648は同じ付番システムで可能な限り負の整数です)。 負数の表現はAODV一連番号の増分に関連していません。 これは扱われる2つのAODV一連番号を比較するという結果がことである方法と対照的になっています(以下を見てください)。
In order to ascertain that information about a destination is not stale, the node compares its current numerical value for the sequence number with that obtained from the incoming AODV message. This comparison MUST be done using signed 32-bit arithmetic, this is necessary to accomplish sequence number rollover. If the result of subtracting the currently stored sequence number from the value of the incoming sequence number is less than zero, then the information related to that destination in the AODV message MUST be discarded, since that information is stale compared to the node's currently stored information.
目的地の情報が聞き古したでない確かめて、ノードは一連番号のために入って来るAODVメッセージから得るそれと現在の数値を比較します。 サインされた32ビットの演算を使用しこの比較を終わらなければならなくて、これが、一連番号ロールオーバーを達成するのに必要です。入って来る一連番号の値から現在格納された一連番号を引き算するという結果がゼロ未満であるならAODVメッセージのその目的地に関連する情報を捨てなければなりません、ノードの現在格納された情報と比べて、その情報が聞き古したである。
The only other circumstance in which a node may change the destination sequence number in one of its route table entries is in response to a lost or expired link to the next hop towards that destination. The node determines which destinations use a particular next hop by consulting its routing table. In this case, for each destination that uses the next hop, the node increments the sequence number and marks the route as invalid (see also sections 6.11, 6.12). Whenever any fresh enough (i.e., containing a sequence number at least equal to the recorded sequence number) routing information for an affected destination is received by a node that has marked that route table entry as invalid, the node SHOULD update its route table information according to the information contained in the update.
ノードがルートテーブルエントリーの1つで目的地一連番号を変えるかもしれない他の唯一の状況が次のホップへの無くなっているか満期のリンクに対応してその目的地に向かっています。 ノードは、どの目的地が経路指定テーブルに相談することによって次の特定のホップを使用するかを決定します。 この場合、次のホップを使用する各目的地に関して、ノードは、一連番号を増加して、ルートが無効であるとマークします(また、セクション6.11、6.12を見てください)。 そのルートテーブルエントリーが無効であるとマークしたノードでどんな影響を受ける目的地のために十分新鮮な(すなわち、記録された一連番号と少なくとも等しい一連番号を含んでいる)ルーティング情報も受け取るときはいつも、アップデートに含まれた情報によると、ノードSHOULDはルートテーブル情報をアップデートします。
Perkins, et. al. Experimental [Page 12] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[12ページ]RFC3561AODV
A node may change the sequence number in the routing table entry of a destination only if:
ノードが目的地の経路指定テーブルエントリーだけで一連番号を変えるかもしれない、:
- it is itself the destination node, and offers a new route to
itself, or
- またはそれがそれ自体で目的地ノードであり、新しいルートをそれ自体に提供する。
- it receives an AODV message with new information about the
sequence number for a destination node, or
- またはそれが目的地ノードのために一連番号に関する新情報でAODVメッセージを受け取る。
- the path towards the destination node expires or breaks.
- 目的地ノードに向かった経路は、期限が切れるか、または壊れます。
6.2. Route Table Entries and Precursor Lists
6.2. ルートテーブルエントリーと先駆リスト
When a node receives an AODV control packet from a neighbor, or creates or updates a route for a particular destination or subnet, it checks its route table for an entry for the destination. In the event that there is no corresponding entry for that destination, an entry is created. The sequence number is either determined from the information contained in the control packet, or else the valid sequence number field is set to false. The route is only updated if the new sequence number is either
ノードが特定の目的地かサブネットのためにルートを隣人からAODVコントロールパケットを受けるか、作成するか、またはアップデートすると、それは目的地のためのエントリーがないかどうかルートテーブルをチェックします。 その目的地のためのどんな対応するエントリーもない場合、エントリーは作成されます。 一連番号がコントロールパケットに含まれた情報から測定されるか、または有効な一連番号分野は誤っているのに設定されます。 新しい一連番号がどちらか場合にだけルートをアップデートします。
(i) higher than the destination sequence number in the route
table, or
または(i) ルートテーブルの目的地一連番号より高さ。
(ii) the sequence numbers are equal, but the hop count (of the
new information) plus one, is smaller than the existing hop
count in the routing table, or
または(ii) 一連番号が等しいのですが、経路指定テーブルでは、ホップカウント(新情報の)と1つが既存のホップカウントより小さい。
(iii) the sequence number is unknown.
(iii) 一連番号は未知です。
The Lifetime field of the routing table entry is either determined from the control packet, or it is initialized to ACTIVE_ROUTE_TIMEOUT. This route may now be used to send any queued data packets and fulfills any outstanding route requests.
経路指定テーブルエントリーのLifetime分野がコントロールパケットから決定するか、またはそれはACTIVE_ROUTE_TIMEOUTに初期化されます。 このルートは、現在、どんな列に並ばせられたデータ・パケットも送るのに使用されるかもしれなくて、どんな傑出しているルート要求も実現させます。
Each time a route is used to forward a data packet, its Active Route Lifetime field of the source, destination and the next hop on the path to the destination is updated to be no less than the current time plus ACTIVE_ROUTE_TIMEOUT. Since the route between each originator and destination pair is expected to be symmetric, the Active Route Lifetime for the previous hop, along the reverse path back to the IP source, is also updated to be no less than the current time plus ACTIVE_ROUTE_TIMEOUT. The lifetime for an Active Route is updated each time the route is used regardless of whether the destination is a single node or a subnet.
少なくとも現在の時間プラスACTIVE_ROUTE_TIMEOUTになるようにルートがデータ・パケット、ソースのActive Route Lifetime分野、目的地、および経路の次のホップを目的地に送るのに使用される各回をアップデートします。 それぞれの創始者と目的地組の間のルートが左右対称であると予想されて、また、少なくとも現在の時間プラスACTIVE_ROUTE_TIMEOUTになるようにIPソースへの逆の経路に沿って前のホップのためのActive Route Lifetimeをアップデートします。 ルートが目的地がただ一つのノードかサブネットであることにかかわらず使用されるたびにActive Routeのための生涯をアップデートします。
Perkins, et. al. Experimental [Page 13] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[13ページ]RFC3561AODV
For each valid route maintained by a node as a routing table entry, the node also maintains a list of precursors that may be forwarding packets on this route. These precursors will receive notifications from the node in the event of detection of the loss of the next hop link. The list of precursors in a routing table entry contains those neighboring nodes to which a route reply was generated or forwarded.
また、経路指定テーブルエントリーとしてノードによって維持されたそれぞれの有効なルートに、ノードはこのルートでパケットを進めているかもしれない先駆のリストを維持します。 これらの先駆は次のホップリンクの損失の検出の場合ノードから通知を受け取るでしょう。 経路指定テーブルエントリーにおける先駆のリストはルート回答が発生したか、または送られたそれらの隣接しているノードを含んでいます。
6.3. Generating Route Requests
6.3. ルート要求を発生させます。
A node disseminates a RREQ when it determines that it needs a route to a destination and does not have one available. This can happen if the destination is previously unknown to the node, or if a previously valid route to the destination expires or is marked as invalid. The Destination Sequence Number field in the RREQ message is the last known destination sequence number for this destination and is copied from the Destination Sequence Number field in the routing table. If no sequence number is known, the unknown sequence number flag MUST be set. The Originator Sequence Number in the RREQ message is the node's own sequence number, which is incremented prior to insertion in a RREQ. The RREQ ID field is incremented by one from the last RREQ ID used by the current node. Each node maintains only one RREQ ID. The Hop Count field is set to zero.
目的地にルートを必要として、1つを利用可能にしないことを決定すると、ノードはRREQを広めます。 目的地への以前に有効なルートがノードにおいて、目的地が以前に、未知である、期限が切れるか、または無効であるとマークされるなら、これは起こることができます。 RREQメッセージのDestination Sequence Number分野は、この目的地への最後に知られている目的地一連番号であり、経路指定テーブルのDestination Sequence Number分野からコピーされます。 一連番号が全く知られていないなら、未知の一連番号旗を設定しなければなりません。 RREQメッセージのOriginator Sequence Numberはノードの自己の一連番号です。(その一連番号はRREQへの挿入の前に増加されます)。 RREQ ID分野は現在のノードによって使用される最後のRREQ IDからの1つ増加されます。 各ノードは1RREQ IDだけを維持します。 Hop Count分野はゼロに設定されます。
Before broadcasting the RREQ, the originating node buffers the RREQ ID and the Originator IP address (its own address) of the RREQ for PATH_DISCOVERY_TIME. In this way, when the node receives the packet again from its neighbors, it will not reprocess and re-forward the packet.
RREQを放送する前に、由来しているノードは_PATH_ディスカバリータイム誌のためのRREQのRREQ IDとOriginator IPアドレス(それ自身のアドレス)をバッファリングします。 これほどずっとノードが再び隣人からパケットを受けて、それが意志の「再-過程」でなく、再フォワードがパケットであることのコネ。
An originating node often expects to have bidirectional communications with a destination node. In such cases, it is not sufficient for the originating node to have a route to the destination node; the destination must also have a route back to the originating node. In order for this to happen as efficiently as possible, any generation of a RREP by an intermediate node (as in section 6.6) for delivery to the originating node SHOULD be accompanied by some action that notifies the destination about a route back to the originating node. The originating node selects this mode of operation in the intermediate nodes by setting the 'G' flag. See section 6.6.3 for details about actions taken by the intermediate node in response to a RREQ with the 'G' flag set.
由来しているノードは、しばしば目的地ノードとの双方向のコミュニケーションを持っていると予想します。 そのような場合、由来しているノードが目的地ノードにルートを持っているのは、十分ではありません。 また、目的地は由来しているノードにルートを返してもらわなければなりません。 これが配送のための中間的ノード(セクション6.6のように)によるRREPの由来しているノードSHOULDへのどんな世代の間にもできるだけ効率的に起こる命令では、ルートに関して由来しているノードに目的地に通知して戻す何らかの動作で伴われてください。 由来しているノードは、'G'旗を設定することによって、中間的ノードのこの運転モードを選択します。 動作に関する詳細のためのセクション6.6.3が中間的ノードによって'G'旗のセットがあるRREQに対応して取られるのを見てください。
A node SHOULD NOT originate more than RREQ_RATELIMIT RREQ messages per second. After broadcasting a RREQ, a node waits for a RREP (or other control message with current information regarding a route to the appropriate destination). If a route is not received within NET_TRAVERSAL_TIME milliseconds, the node MAY try again to discover a route by broadcasting another RREQ, up to a maximum of RREQ_RETRIES
SHOULD NOTが1秒あたりのRREQ_RATELIMIT RREQメッセージより溯源するノード。 RREQを放送した後に、ノードはRREP(または、適切な目的地へのルートに関する現行情報がある他のコントロールメッセージ)を待ちます。 ルートがネット_TRAVERSAL_タイム誌のミリセカンドの中に受け取られないなら、ノードは再び別のRREQを放送することによって、ルートを発見しようとするかもしれません、最大RREQ_RETRIESまで
Perkins, et. al. Experimental [Page 14] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[14ページ]RFC3561AODV
times at the maximum TTL value. Each new attempt MUST increment and update the RREQ ID. For each attempt, the TTL field of the IP header is set according to the mechanism specified in section 6.4, in order to enable control over how far the RREQ is disseminated for the each retry.
最大のTTL値における回。 それぞれの新しい試みは、RREQ IDを増加して、アップデートしなければなりません。 セクション6.4で指定されたメカニズムによると、各試みにおいて、IPヘッダーのTTL分野は設定されます、どれくらい遠いことのRREQが広められるコントロールを可能にするかために各再試行
Data packets waiting for a route (i.e., waiting for a RREP after a RREQ has been sent) SHOULD be buffered. The buffering SHOULD be "first-in, first-out" (FIFO). If a route discovery has been attempted RREQ_RETRIES times at the maximum TTL without receiving any RREP, all data packets destined for the corresponding destination SHOULD be dropped from the buffer and a Destination Unreachable message SHOULD be delivered to the application.
aを待つデータ・パケットがSHOULDを発送します(すなわち、RREQを送った後にRREPを待っています)。バッファリングされます。 「中と最初に、最初に外」(先入れ先出し法)ということになってくださいSHOULDをバッファリングして。 どんなRREPも受けることのない最大のTTL、対応する目的地SHOULDに運命づけられたすべてのデータ・パケットではルート発見が試みられたRREQ_RETRIES回であるならバッファとDestination UnreachableメッセージSHOULDから低下してください。アプリケーションに渡します。
To reduce congestion in a network, repeated attempts by a source node at route discovery for a single destination MUST utilize a binary exponential backoff. The first time a source node broadcasts a RREQ, it waits NET_TRAVERSAL_TIME milliseconds for the reception of a RREP. If a RREP is not received within that time, the source node sends a new RREQ. When calculating the time to wait for the RREP after sending the second RREQ, the source node MUST use a binary exponential backoff. Hence, the waiting time for the RREP corresponding to the second RREQ is 2 * NET_TRAVERSAL_TIME milliseconds. If a RREP is not received within this time period, another RREQ may be sent, up to RREQ_RETRIES additional attempts after the first RREQ. For each additional attempt, the waiting time for the RREP is multiplied by 2, so that the time conforms to a binary exponential backoff.
ネットワークで混雑を抑えるために、単一の目的地のためのルート発見におけるソースノードによる繰り返された試みは2進の指数のbackoffを利用しなければなりません。 初めてソースノードがRREQを放送するとき、それはRREPのレセプションのためにネット_TRAVERSAL_タイム誌のミリセカンドを待ちます。RREPがその時中に受け取られないなら、ソースノードは新しいRREQを送ります。 第2RREQを送った後にRREPを待つ時間について計算するとき、ソースノードは2進の指数のbackoffを使用しなければなりません。 したがって、第2RREQに対応するRREPのための待ち時間は2*ネット_TRAVERSAL_タイム誌のミリセカンドです。 この期間中にRREPを受け取らないなら、別のRREQを送るかもしれません、最初のRREQの後のRREQ_RETRIESの追加試みまで。 それぞれの追加試みにおいて、2はRREPのための待ち時間に掛けられます、時間が2進の指数のbackoffに従うように。
6.4. Controlling Dissemination of Route Request Messages
6.4. ルート要求メッセージの普及を制御します。
To prevent unnecessary network-wide dissemination of RREQs, the originating node SHOULD use an expanding ring search technique. In an expanding ring search, the originating node initially uses a TTL = TTL_START in the RREQ packet IP header and sets the timeout for receiving a RREP to RING_TRAVERSAL_TIME milliseconds. RING_TRAVERSAL_TIME is calculated as described in section 10. The TTL_VALUE used in calculating RING_TRAVERSAL_TIME is set equal to the value of the TTL field in the IP header. If the RREQ times out without a corresponding RREP, the originator broadcasts the RREQ again with the TTL incremented by TTL_INCREMENT. This continues until the TTL set in the RREQ reaches TTL_THRESHOLD, beyond which a TTL = NET_DIAMETER is used for each attempt. Each time, the timeout for receiving a RREP is RING_TRAVERSAL_TIME. When it is desired to have all retries traverse the entire ad hoc network, this can be achieved by configuring TTL_START and TTL_INCREMENT both to be the same value as NET_DIAMETER.
RREQsの不要なネットワーク全体の普及を防ぐために、由来しているノードSHOULDは拡張リング検索技術を使用します。 拡張リング検索では、由来しているノードは、初めは、RREQパケットIPヘッダーでTTL=TTL_STARTを使用して、RING_TRAVERSAL_タイム誌のミリセカンドにRREPを受けるのにタイムアウトを設定します。 RING_TRAVERSAL_タイム誌はセクション10で説明されるように計算されます。 VALUEが計算の_RING_TRAVERSALタイム誌に使用したTTL_はIPヘッダーのTTL分野の値と等しいセットです。 対応するRREPのないRREQ回であるなら、TTLがTTL_INCREMENTによって増加されている状態で、創始者は再びRREQを放送します。 RREQで用意ができているTTLがTTL_THRESHOLD(TTL=ネット_DIAMETERは各試みに使用される)に達するまで、これは続きます。 その都度、RREPを受けるためのタイムアウトはRING_TRAVERSAL_タイム誌です。 すべての再試行に全体の臨時のネットワークを横断させるのが、必要であるときに、TTL_STARTとTTL_INCREMENTがネット_DIAMETERと同じ値であることを両方の、構成することによって、これを達成できます。
Perkins, et. al. Experimental [Page 15] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[15ページ]RFC3561AODV
The Hop Count stored in an invalid routing table entry indicates the last known hop count to that destination in the routing table. When a new route to the same destination is required at a later time (e.g., upon route loss), the TTL in the RREQ IP header is initially set to the Hop Count plus TTL_INCREMENT. Thereafter, following each timeout the TTL is incremented by TTL_INCREMENT until TTL = TTL_THRESHOLD is reached. Beyond this TTL = NET_DIAMETER is used. Once TTL = NET_DIAMETER, the timeout for waiting for the RREP is set to NET_TRAVERSAL_TIME, as specified in section 6.3.
無効の経路指定テーブルエントリーに格納されたHop Countは最後に知られているホップカウントを経路指定テーブルのその目的地に示します。 同じ目的地への新しいルートが初めは後で(例えば、ルートの損失に関して)必要であるときに、RREQ IPヘッダーのTTLはHop CountとTTL_INCREMENTに用意ができています。 その後、各タイムアウトに続いて、TTL=TTL_THRESHOLDに達するまで、TTLはTTL_INCREMENTによって増加されます。 向こうでは、このTTL=ネット_DIAMETERは使用されています。 TTLがいったんネット_DIAMETERと等しいと、RREPを待つためのタイムアウトはセクション6.3で指定されるようにネット_TRAVERSAL_タイム誌に設定されます。
An expired routing table entry SHOULD NOT be expunged before (current_time + DELETE_PERIOD) (see section 6.11). Otherwise, the soft state corresponding to the route (e.g., last known hop count) will be lost. Furthermore, a longer routing table entry expunge time MAY be configured. Any routing table entry waiting for a RREP SHOULD NOT be expunged before (current_time + 2 * NET_TRAVERSAL_TIME).
満期のルーティングはエントリーSHOULD NOTをテーブルの上に置きます。以前(現在の_時間+DELETE_PERIOD)、梢消されてください(セクション6.11を見てください)。 さもなければ、ルート(例えば、最後に知られているホップカウント)に対応する軟性国家は失われるでしょう。 その上、より長い経路指定テーブルエントリーは構成されるかもしれない時を梢消します。 どんなルーティングもRREP SHOULD NOTを待つエントリーをテーブルの上に置きます。以前(現在の_時間+2*ネット_TRAVERSAL_タイム誌)、梢消されてください。
6.5. Processing and Forwarding Route Requests
6.5. 処理とルート要求を転送すること。
When a node receives a RREQ, it first creates or updates a route to the previous hop without a valid sequence number (see section 6.2) then checks to determine whether it has received a RREQ with the same Originator IP Address and RREQ ID within at least the last PATH_DISCOVERY_TIME. If such a RREQ has been received, the node silently discards the newly received RREQ. The rest of this subsection describes actions taken for RREQs that are not discarded.
ノードがRREQを受けるとき、それは、最初に、(セクション6.2を見ます)その時がそれが_少なくとも最後のPATH_ディスカバリータイム誌の中の同じOriginator IPのAddressとRREQ IDと共にRREQを受けたかどうか決定するためにチェックする有効な一連番号なしで前のホップにルートを作成するか、またはアップデートします。 そのようなRREQを受け取ったなら、ノードは静かに新たに受け取られたRREQを捨てます。 この小区分の残りは捨てられなかったRREQsに取られた行動について説明します。
First, it first increments the hop count value in the RREQ by one, to account for the new hop through the intermediate node. Then the node searches for a reverse route to the Originator IP Address (see section 6.2), using longest-prefix matching. If need be, the route is created, or updated using the Originator Sequence Number from the RREQ in its routing table. This reverse route will be needed if the node receives a RREP back to the node that originated the RREQ (identified by the Originator IP Address). When the reverse route is created or updated, the following actions on the route are also carried out:
まず最初に、それは、最初に、中間的ノードを通して新しいホップの原因になるようにRREQでホップカウント価値を1つ増加します。 そして、最も長い接頭語マッチングを使用して、ノードはOriginator IP Address(セクション6.2を見る)に逆のルートを捜し求めます。 必要なら作成されるか、または経路指定テーブルでRREQからOriginator Sequence Numberを使用することでアップデートされたルート。 ノードがRREQ(Originator IP Addressによって特定される)を溯源したノードにRREPを受けて戻すと、この逆のルートが必要でしょう。 また、逆のルートを作成するか、またはアップデートするとき、ルートへの以下の動作を行います:
1. the Originator Sequence Number from the RREQ is compared to the
corresponding destination sequence number in the route table entry
and copied if greater than the existing value there
1. そこの既存の値より大きいなら、RREQからのOriginator Sequence Numberはルートテーブルエントリーで対応する目的地一連番号と比較されて、コピーされます。
2. the valid sequence number field is set to true;
2. 有効な一連番号分野は本当に設定されます。
3. the next hop in the routing table becomes the node from which the
RREQ was received (it is obtained from the source IP address in
the IP header and is often not equal to the Originator IP Address
field in the RREQ message);
3. 経路指定テーブルの次のホップはRREQが受け取られたノードになります(それは、IPヘッダーでソースIPアドレスから得られて、RREQメッセージにおいてしばしばOriginator IP Address分野と等しいというわけではありません)。
Perkins, et. al. Experimental [Page 16] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[16ページ]RFC3561AODV
4. the hop count is copied from the Hop Count in the RREQ message;
4. ホップカウントはRREQメッセージのHop Countからコピーされます。
Whenever a RREQ message is received, the Lifetime of the reverse route entry for the Originator IP address is set to be the maximum of (ExistingLifetime, MinimalLifetime), where
RREQメッセージが受信されているときはいつも、Originator IPアドレスのための逆のルートエントリーのLifetimeは(ExistingLifetime、MinimalLifetime)の最大であるように用意ができています、どこ
MinimalLifetime = (current time + 2*NET_TRAVERSAL_TIME -
2*HopCount*NODE_TRAVERSAL_TIME).
MinimalLifetime=(現在の時間+2*ネット_TRAVERSAL_タイム誌--2*HopCount*NODE_TRAVERSAL_タイム誌)。
The current node can use the reverse route to forward data packets in the same way as for any other route in the routing table.
現在のノードは、同様に、経路指定テーブルのいかなる他のルートのようにもデータ・パケットを進めるのに逆のルートを使用できます。
If a node does not generate a RREP (following the processing rules in section 6.6), and if the incoming IP header has TTL larger than 1, the node updates and broadcasts the RREQ to address 255.255.255.255 on each of its configured interfaces (see section 6.14). To update the RREQ, the TTL or hop limit field in the outgoing IP header is decreased by one, and the Hop Count field in the RREQ message is incremented by one, to account for the new hop through the intermediate node. Lastly, the Destination Sequence number for the requested destination is set to the maximum of the corresponding value received in the RREQ message, and the destination sequence value currently maintained by the node for the requested destination. However, the forwarding node MUST NOT modify its maintained value for the destination sequence number, even if the value received in the incoming RREQ is larger than the value currently maintained by the forwarding node.
ノードがRREPを発生させないで(セクション6.6で処理規則に従って)、入って来るIPヘッダーがTTLを1より大きくするなら、ノードがRREQをアドレスにアップデートして、放送する、255.255、.255、.255、それぞれの構成されたインタフェース(セクション6.14を見る)で。 外向的なIPヘッダーのRREQ、TTLまたはホップ限界分野をアップデートするのは1つ減少します、そして、RREQメッセージのHop Count分野は、中間的ノードを通して新しいホップの原因になるように1つ増加されます。 最後に、要求された目的地のDestination Sequence番号はRREQメッセージに受け取られた換算値の最大、および現在要求された目的地のためのノードによって維持されている目的地系列価値へのセットです。 しかしながら、推進ノードは目的地一連番号のために維持された値を変更してはいけません、入って来るRREQの対価領収が現在推進ノードによって維持されている値よりさらに大きいなら。
Otherwise, if a node does generate a RREP, then the node discards the
RREQ. Notice that, if intermediate nodes reply to every transmission
of RREQs for a particular destination, it might turn out that the
destination does not receive any of the discovery messages. In this
situation, the destination does not learn of a route to the
originating node from the RREQ messages. This could cause the
destination to initiate a route discovery (for example, if the
originator is attempting to establish a TCP session). In order that
the destination learn of routes to the originating node, the
originating node SHOULD set the "gratuitous RREP" ('G') flag in the
RREQ if for any reason the destination is likely to need a route to
the originating node. If, in response to a RREQ with the 'G' flag
set, an intermediate node returns a RREP, it MUST also unicast a
gratuitous RREP to the destination node (see section 6.6.3).
さもなければ、ノードがRREPを発生させるなら、ノードはRREQを捨てます。 中間的ノードが特定の目的地のためにRREQsのあらゆるトランスミッションに答えるなら目的地が発見メッセージのいずれも受け取らないと判明するかもしれないのに注意してください。 この状況で、目的地はRREQメッセージからの由来しているノードにルートを知りません。 これで、目的地はルート発見を開始するかもしれません(創始者が、例えばTCPセッションを確立するのを試みているなら)。 目的地が由来しているノードにルートを知るように、由来しているノードSHOULDはRREQの「無料のRREP」('G')旗を設定します目的地がどんな理由でも由来しているノードにルートが必要でありそうであるなら。 中間的ノードが'G'旗のセットがあるRREQに対応してRREPを返すなら、それは目的地ノード(セクション6.6.3を見る)へのユニキャストのもa無料のRREPを返さなければなりません。
Perkins, et. al. Experimental [Page 17] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[17ページ]RFC3561AODV
6.6. Generating Route Replies
6.6. ルート回答を発生させます。
A node generates a RREP if either:
ノードはどちらかならRREPを発生させます:
(i) it is itself the destination, or
または(i) それがそれ自体で目的地である。
(ii) it has an active route to the destination, the destination
sequence number in the node's existing route table entry
for the destination is valid and greater than or equal to
the Destination Sequence Number of the RREQ (comparison
using signed 32-bit arithmetic), and the "destination only"
('D') flag is NOT set.
アクティブなルートを目的地に持っています、そして、目的地のためのノードの既存のルートテーブルエントリーにおける目的地一連番号は有効です、そして、RREQのDestination Sequence Number(サインされた32ビットの演算を使用する比較)、および「目的地専用」('D')旗は、より有効です。セットしませんでした。
When generating a RREP message, a node copies the Destination IP Address and the Originator Sequence Number from the RREQ message into the corresponding fields in the RREP message. Processing is slightly different, depending on whether the node is itself the requested destination (see section 6.6.1), or instead if it is an intermediate node with an fresh enough route to the destination (see section 6.6.2).
RREPメッセージを発生させるとき、ノードはDestination IP AddressとOriginator Sequence NumberをRREPメッセージの対応する分野にRREQメッセージを回避します。 処理はわずかに異なっています、ノードがそれ自体で要求された目的地(セクション6.6.1を見る)であるかどうかかそれとも代わりに、十分新鮮なルートでそれが目的地への中間的ノードであるかどうかによって(セクション6.6.2を見てください)。
Once created, the RREP is unicast to the next hop toward the originator of the RREQ, as indicated by the route table entry for that originator. As the RREP is forwarded back towards the node which originated the RREQ message, the Hop Count field is incremented by one at each hop. Thus, when the RREP reaches the originator, the Hop Count represents the distance, in hops, of the destination from the originator.
一度作成されています、RREPはRREQの創始者に向かった次のホップへのユニキャストです、その創始者のためのルートテーブルエントリーで示されるように。 RREQメッセージを溯源したノードに向かってRREPを送って戻すのに従って、Hop Count分野は各ホップの1つ増加されます。 したがって、RREPが創始者に届くと、Hop Countは距離を表します、創始者からの目的地のホップで。
6.6.1. Route Reply Generation by the Destination
6.6.1. 目的地のそばのルート回答世代
If the generating node is the destination itself, it MUST increment its own sequence number by one if the sequence number in the RREQ packet is equal to that incremented value. Otherwise, the destination does not change its sequence number before generating the RREP message. The destination node places its (perhaps newly incremented) sequence number into the Destination Sequence Number field of the RREP, and enters the value zero in the Hop Count field of the RREP.
発生ノードが目的地自体であるなら、RREQパケットの一連番号がその増加している値と等しいなら、それはそれ自身の一連番号を1つ増加しなければなりません。 さもなければ、RREPメッセージを発生させる前に、目的地は一連番号を変えません。 目的地ノードは、(恐らく新たに増加されています)の一連番号をRREPのDestination Sequence Number分野に置いて、RREPのHop Countフィールドに値ゼロを入れます。
The destination node copies the value MY_ROUTE_TIMEOUT (see section 10) into the Lifetime field of the RREP. Each node MAY reconfigure its value for MY_ROUTE_TIMEOUT, within mild constraints (see section 10).
目的地ノードは値のMY_ROUTE_TIMEOUT(セクション10を見る)をRREPのLifetime分野にコピーします。各ノードはMY_ROUTE_TIMEOUTのために値を再構成するかもしれません、軽い規制の中で(セクション10を見てください)。
Perkins, et. al. Experimental [Page 18] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[18ページ]RFC3561AODV
6.6.2. Route Reply Generation by an Intermediate Node
6.6.2. 中間的ノードによるルート回答世代
If the node generating the RREP is not the destination node, but instead is an intermediate hop along the path from the originator to the destination, it copies its known sequence number for the destination into the Destination Sequence Number field in the RREP message.
RREPを発生させるノードが目的地ノードではありませんが、代わりに創始者から目的地までの経路に沿った中間的ホップであるなら、それはRREPメッセージのDestination Sequence Number分野への目的地に知られている一連番号をコピーします。
The intermediate node updates the forward route entry by placing the last hop node (from which it received the RREQ, as indicated by the source IP address field in the IP header) into the precursor list for the forward route entry -- i.e., the entry for the Destination IP Address. The intermediate node also updates its route table entry for the node originating the RREQ by placing the next hop towards the destination in the precursor list for the reverse route entry -- i.e., the entry for the Originator IP Address field of the RREQ message data.
中間的ノードは最後のホップノード(それが示されるようにIPヘッダーのソースIPアドレス・フィールドでRREQを受けた)を前進のルートエントリーのための先駆リストの中に置くことによって、前進のルートエントリーをアップデートします--すなわち、Destination IP Addressのためのエントリー。 また、中間的ノードは逆のルートエントリーのための先駆リストに次のホップを目的地に向かって置くことによってRREQを溯源するノードのためのルートテーブルエントリーをアップデートします--すなわち、RREQメッセージデータのOriginator IP Address分野のためのエントリー。
The intermediate node places its distance in hops from the destination (indicated by the hop count in the routing table) Count field in the RREP. The Lifetime field of the RREP is calculated by subtracting the current time from the expiration time in its route table entry.
中間的ノードは距離をRREPの目的地(ホップカウントで、経路指定テーブルで示される)カウント分野からホップに置きます。RREPのLifetime分野は、ルートテーブルエントリーで満了時間から現在の時間を引き算することによって、計算されます。
6.6.3. Generating Gratuitous RREPs
6.6.3. 無料のRREPsを発生させます。
After a node receives a RREQ and responds with a RREP, it discards the RREQ. If the RREQ has the 'G' flag set, and the intermediate node returns a RREP to the originating node, it MUST also unicast a gratuitous RREP to the destination node. The gratuitous RREP that is to be sent to the desired destination contains the following values in the RREP message fields:
ノードがRREQを受けて、RREPと共に応じた後に、それはRREQを捨てます。 RREQが'G'旗を設定させて、中間的ノードが由来しているノードにRREPを返すなら、それは目的地ノードへのユニキャストのもa無料のRREPを返さなければなりません。 必要な目的地に送られることになっている無料のRREPはRREPメッセージ分野に以下の値を保管しています:
Hop Count The Hop Count as indicated in the
node's route table entry for the
originator
創始者のためのノードのルートテーブルエントリーにみられるようにCount Hop Countを飛び越してください。
Destination IP Address The IP address of the node that
originated the RREQ
IPが記述するRREQを溯源したノードの目的地IP Address
Destination Sequence Number The Originator Sequence Number from
the RREQ
目的地一連番号はRREQからの創始者一連番号です。
Originator IP Address The IP address of the Destination
node in the RREQ
IPが記述するRREQのDestinationノードの創始者IP Address
Perkins, et. al. Experimental [Page 19] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[19ページ]RFC3561AODV
Lifetime The remaining lifetime of the route
towards the originator of the RREQ,
as known by the intermediate node.
中間的ノードによる知られるとしてのRREQの創始者に向かったルートの残り生涯生涯。
The gratuitous RREP is then sent to the next hop along the path to the destination node, just as if the destination node had already issued a RREQ for the originating node and this RREP was produced in response to that (fictitious) RREQ. The RREP that is sent to the originator of the RREQ is the same whether or not the 'G' bit is set.
次に、目的地ノードへの経路に沿った次のホップに無料のRREPを送ります、まるでまさしく、目的地ノードが由来しているノードのために既にRREQを発行して、このRREPがその(架空)のRREQに対応して生産されるかのように。 'G'ビットが設定されるか否かに関係なく、RREQの創始者に送られるRREPは同じです。
6.7. Receiving and Forwarding Route Replies
6.7. ルート回答を受け取って、進めます。
When a node receives a RREP message, it searches (using longest- prefix matching) for a route to the previous hop. If needed, a route is created for the previous hop, but without a valid sequence number (see section 6.2). Next, the node then increments the hop count value in the RREP by one, to account for the new hop through the intermediate node. Call this incremented value the "New Hop Count". Then the forward route for this destination is created if it does not already exist. Otherwise, the node compares the Destination Sequence Number in the message with its own stored destination sequence number for the Destination IP Address in the RREP message. Upon comparison, the existing entry is updated only in the following circumstances:
ノードがRREPメッセージを受け取るとき、それは前のホップとしてルートを探します(最も長い接頭語マッチングを使用します)。 必要であるなら、ルートは前のホップのために作成されますが、有効な一連番号なしで作成されます(セクション6.2を見てください)。 そして、次に、ノードは、中間的ノードを通して新しいホップの原因になるようにRREPでホップカウント価値を1つ増加します。 「新しいホップカウント」にこの増加している値に電話をしてください。 そして、既に存在していないなら、この目的地への前進のルートは作成されます。 さもなければ、ノードはRREPメッセージのDestination IP Addressのためにそれ自身の格納された目的地一連番号とメッセージのDestination Sequence Numberを比べます。 比較のときに、以下の事情だけで既存のエントリーをアップデートします:
(i) the sequence number in the routing table is marked as
invalid in route table entry.
(i) 経路指定テーブルの一連番号はルートテーブルエントリーで無効であるとマークされます。
(ii) the Destination Sequence Number in the RREP is greater than
the node's copy of the destination sequence number and the
known value is valid, or
または(ii) RREPのDestination Sequence Numberがノードの目的地一連番号と知られている価値のコピーが有効であるというよりもすばらしい。
(iii) the sequence numbers are the same, but the route is is
marked as inactive, or
または(iii)一連番号が同じですが、ルートが同じである、不活発であるとしてマークされる。
(iv) the sequence numbers are the same, and the New Hop Count is
smaller than the hop count in route table entry.
(iv) 一連番号が同じであり、New Hop Countはルートテーブルエントリーにおけるホップカウントより小さいです。
If the route table entry to the destination is created or updated, then the following actions occur:
目的地へのルートテーブルエントリーを作成するか、またはアップデートするなら、以下の動作は起こります:
- the route is marked as active,
- ルートはアクティブであるとしてマークされます。
- the destination sequence number is marked as valid,
- 目的地一連番号は有効であるとしてマークされます。
- the next hop in the route entry is assigned to be the node from
which the RREP is received, which is indicated by the source IP
address field in the IP header,
- ルートエントリーにおける次のホップは、RREPがどれであるかから受け取られたノードになるように割り当てられます。(それは、IPヘッダーのソースIPアドレス・フィールドによって示されます)。
Perkins, et. al. Experimental [Page 20] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[20ページ]RFC3561AODV
- the hop count is set to the value of the New Hop Count,
- ホップカウントはNew Hop Countの値に設定されます。
- the expiry time is set to the current time plus the value of the
Lifetime in the RREP message,
- 満期時間はRREPメッセージの現在の時間とLifetimeの値に決められます。
- and the destination sequence number is the Destination Sequence
Number in the RREP message.
- そして、目的地一連番号はRREPメッセージのDestination Sequence Numberです。
The current node can subsequently use this route to forward data packets to the destination.
現在のノードは、次に、データ・パケットを目的地に送るのにこのルートを使用できます。
If the current node is not the node indicated by the Originator IP Address in the RREP message AND a forward route has been created or updated as described above, the node consults its route table entry for the originating node to determine the next hop for the RREP packet, and then forwards the RREP towards the originator using the information in that route table entry. If a node forwards a RREP over a link that is likely to have errors or be unidirectional, the node SHOULD set the 'A' flag to require that the recipient of the RREP acknowledge receipt of the RREP by sending a RREP-ACK message back (see section 6.8).
現在のノードがRREPメッセージでOriginator IP Addressによって示されたノードでなく、上で説明されるように前進のルートを作成するか、またはアップデートしたなら、ノードは、由来しているノードがRREPパケットのために次のホップを決定するようにルートテーブルエントリーに相談して、そのルートテーブルエントリーで情報を使用することで創始者に向かってRREPを送ります。 ノードが誤りを持っているか、単方向である傾向があるリンクの上にRREPを送るなら、ノードSHOULDは、'A'旗にRREPの受取人がRREP-ACKメッセージを返送することによってRREPの領収書を受け取ったことを知らせるのを必要であるように設定します(セクション6.8を見てください)。
When any node transmits a RREP, the precursor list for the corresponding destination node is updated by adding to it the next hop node to which the RREP is forwarded. Also, at each node the (reverse) route used to forward a RREP has its lifetime changed to be the maximum of (existing-lifetime, (current time + ACTIVE_ROUTE_TIMEOUT). Finally, the precursor list for the next hop towards the destination is updated to contain the next hop towards the source.
どんなノードもRREPを伝えるとき、RREPが送られる次のホップノードをそれに加えることによって、対応する目的地ノードのための先駆リストをアップデートします。 また、各ノードのa RREPを進めるのにおいて中古の(逆)のルートには最大になるように変えられた寿命がある、(ソースに向かって次のホップを含むように. 既存の生涯、目的地に向かった次のホップのための最終的に(現在の時間+ACTIVE_ROUTE_TIMEOUT)先駆リストをアップデートします。
6.8. Operation over Unidirectional Links
6.8. 単方向のリンクの上の操作
It is possible that a RREP transmission may fail, especially if the RREQ transmission triggering the RREP occurs over a unidirectional link. If no other RREP generated from the same route discovery attempt reaches the node which originated the RREQ message, the originator will reattempt route discovery after a timeout (see section 6.3). However, the same scenario might well be repeated without any improvement, and no route would be discovered even after repeated retries. Unless corrective action is taken, this can happen even when bidirectional routes between originator and destination do exist. Link layers using broadcast transmissions for the RREQ will not be able to detect the presence of such unidirectional links. In AODV, any node acts on only the first RREQ with the same RREQ ID and ignores any subsequent RREQs. Suppose, for example, that the first
RREPトランスミッションが失敗するのは、可能です、特にRREPの引き金となるRREQトランスミッションが単方向のリンクの上に起こるなら。 他のどんなRREPも同じルート発見試み範囲からRREQメッセージを溯源したノードを作らなかったなら、創始者はタイムアウト(セクション6.3を見る)の後の「再-試み」ルート発見を作ったつもりでした。 しかしながら、同じシナリオはたぶん少しも改良なしで繰り返されるでしょう、そして、ルートは全く繰り返された再試行の後にさえ発見されないでしょう。 修正措置が取られない場合、創始者と目的地の間の双方向のルートが存在していると、これは起こることができます。 RREQに放送送信を使用するリンクレイヤはそのような単方向のリンクの存在を検出できないでしょう。 AODVでは、どんなノードも、同じRREQ IDと共に最初のRREQだけに影響して、どんなその後のRREQsも無視します。 例えば、それが1番目であると仮定してください。
Perkins, et. al. Experimental [Page 21] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[21ページ]RFC3561AODV
RREQ arrives along a path that has one or more unidirectional link(s). A subsequent RREQ may arrive via a bidirectional path (assuming such paths exist), but it will be ignored.
RREQは1個以上の単方向のリンクを持っている経路に沿って到着します。 その後のRREQは双方向の経路を通して到着するかもしれませんが(そのような経路が存在すると仮定して)、それは無視されるでしょう。
To prevent this problem, when a node detects that its transmission of a RREP message has failed, it remembers the next-hop of the failed RREP in a "blacklist" set. Such failures can be detected via the absence of a link-layer or network-layer acknowledgment (e.g., RREP- ACK). A node ignores all RREQs received from any node in its blacklist set. Nodes are removed from the blacklist set after a BLACKLIST_TIMEOUT period (see section 10). This period should be set to the upper bound of the time it takes to perform the allowed number of route request retry attempts as described in section 6.3.
ノードがそれを検出するとき、この問題を防ぐために、RREPメッセージの伝達は失敗して、それは、「ブラックリスト」の失敗したRREPの次のホップがセットしたのを覚えています。 リンクレイヤかネットワーク層承認(例えば、RREP- ACK)の欠如でそのような失敗を検出できます。 ノードはどんなノードからもブラックリストセットで受け取られたすべてのRREQsを無視します。 ノードはBLACKLIST_TIMEOUTの期間の後にブラックリストセットから取り除かれます(セクション10を見てください)。 この期間はセクション6.3で説明されるようにわざわざそれがルート要求再試行試みの許容数を実行する上限に決められるべきです。
Note that the RREP-ACK packet does not contain any information about which RREP it is acknowledging. The time at which the RREP-ACK is received will likely come just after the time when the RREP was sent with the 'A' bit. This information is expected to be sufficient to provide assurance to the sender of the RREP that the link is currently bidirectional, without any real dependence on the particular RREP message being acknowledged. However, that assurance typically cannot be expected to remain in force permanently.
RREP-ACKパケットがどのRREPで承認しているかという少しの情報も含まないことに注意してください。 RREP-ACKが受け取られている時はRREPが'A'ビットで送られた時代のすぐ後におそらく来るでしょう。 この情報がリンクが現在双方向であるというRREPの送付者への保証を提供するために十分であると予想されます、承認される特定のRREPメッセージへの少しも本当の依存なしで。 しかしながら、その保証が永久に有効なままで残っていることを通常期待できません。
6.9. Hello Messages
6.9. こんにちは、メッセージ
A node MAY offer connectivity information by broadcasting local Hello messages. A node SHOULD only use hello messages if it is part of an active route. Every HELLO_INTERVAL milliseconds, the node checks whether it has sent a broadcast (e.g., a RREQ or an appropriate layer 2 message) within the last HELLO_INTERVAL. If it has not, it MAY broadcast a RREP with TTL = 1, called a Hello message, with the RREP message fields set as follows:
ノードは、ローカルのHelloメッセージを放送することによって、接続性情報を提供するかもしれません。 SHOULDが使用するだけであるノード、こんにちは、それがアクティブなルートの一部であるなら、通信します。 あらゆる、HELLO_INTERVALミリセカンド、ノードはそれが最後のHELLO_INTERVALの中で放送(例えば、RREQか適切な層の2メッセージ)を送ったかどうかチェックします。 そうしていないなら、分野が以下の通り設定するRREPメッセージでHelloメッセージと呼ばれるTTL=1があるRREPを放送するかもしれません:
Destination IP Address The node's IP address.
ノードのIPが記述する目的地IP Address。
Destination Sequence Number The node's latest sequence number.
ノードの最新の一連番号の目的地Sequence Number。
Hop Count 0
ホップカウント0
Lifetime ALLOWED_HELLO_LOSS * HELLO_INTERVAL
寿命が_を許容した、こんにちは、_損失*、こんにちは、_間隔
A node MAY determine connectivity by listening for packets from its set of neighbors. If, within the past DELETE_PERIOD, it has received a Hello message from a neighbor, and then for that neighbor does not receive any packets (Hello messages or otherwise) for more than
ノードは、隣人のセットからパケットの聞こうとすることによって、接続性を決定するかもしれません。 過去のDELETE_PERIODの中で隣人からHelloメッセージを受け取って、そして、その隣人のためにどんなパケットも受けない、(こんにちは、メッセージかそうでない、)、十二分
Perkins, et. al. Experimental [Page 22] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[22ページ]RFC3561AODV
ALLOWED_HELLO_LOSS * HELLO_INTERVAL milliseconds, the node SHOULD assume that the link to this neighbor is currently lost. When this happens, the node SHOULD proceed as in Section 6.11.
ALLOWED_HELLO_LOSS*HELLO_INTERVALミリセカンドであり、ノードSHOULDは、この隣人へのリンクが現在なくされていると仮定します。 これが起こると、ノードSHOULDはセクション6.11のように続きます。
Whenever a node receives a Hello message from a neighbor, the node SHOULD make sure that it has an active route to the neighbor, and create one if necessary. If a route already exists, then the Lifetime for the route should be increased, if necessary, to be at least ALLOWED_HELLO_LOSS * HELLO_INTERVAL. The route to the neighbor, if it exists, MUST subsequently contain the latest Destination Sequence Number from the Hello message. The current node can now begin using this route to forward data packets. Routes that are created by hello messages and not used by any other active routes will have empty precursor lists and would not trigger a RERR message if the neighbor moves away and a neighbor timeout occurs.
ノードが隣人からHelloメッセージを受け取るときはいつも、ノードSHOULDはアクティブなルートを隣人に持っているのを確実にして、必要なら、1つを作成します。 ルートが既に存在しているなら、必要なら、ルートへのLifetimeは、少なくともALLOWED_HELLO_LOSS*HELLO_INTERVALになるように増加するべきです。 存在しているなら、隣人へのルートは次に、Helloメッセージからの最新のDestination Sequence Numberを含まなければなりません。 現在のノードは、現在、データ・パケットを進めるのにこのルートを使用し始めることができます。 作成されるルート、こんにちは、通信して、アクティブなルートで先駆リストを空にするいかなる他のも使用しないで、また隣人が遠くに移って、隣人タイムアウトが起こるなら、RERRメッセージの引き金とならないでしょう。
6.10. Maintaining Local Connectivity
6.10. ローカルの接続性を維持します。
Each forwarding node SHOULD keep track of its continued connectivity to its active next hops (i.e., which next hops or precursors have forwarded packets to or from the forwarding node during the last ACTIVE_ROUTE_TIMEOUT), as well as neighbors that have transmitted Hello messages during the last (ALLOWED_HELLO_LOSS * HELLO_INTERVAL). A node can maintain accurate information about its continued connectivity to these active next hops, using one or more of the available link or network layer mechanisms, as described below.
それぞれの推進ノードSHOULDは次のアクティブなホップに継続的な接続性の動向をおさえます(すなわち、どの次のホップか先駆が最後のACTIVE_ROUTE_TIMEOUTの間、ノードか推進ノードからパケットを進めていますか)、最終(ALLOWED_HELLO_LOSS*HELLO_INTERVAL)の間にHelloメッセージを送っている隣人と同様に。 ノードはこれらの次のアクティブなホップに継続的な接続性に関する的確な情報を維持できます、利用可能なリンクかネットワーク層メカニズムの1つ以上を使用して、以下で説明されるように。
- Any suitable link layer notification, such as those provided by
IEEE 802.11, can be used to determine connectivity, each time a
packet is transmitted to an active next hop. For example, absence
of a link layer ACK or failure to get a CTS after sending RTS,
even after the maximum number of retransmission attempts,
indicates loss of the link to this active next hop.
- IEEE802.11によって提供されたものなどのように、接続性を決定するのにどんな適当なリンクレイヤ通知も使用できます、パケットが次のアクティブなホップに伝えられる各回。 例えば、ACKリンクレイヤかRTSを送った後にCTSを手に入れないことの欠如は「再-トランスミッション」試みの最大数の後にさえこの次のアクティブなホップへのリンクの損失を示します。
- If layer-2 notification is not available, passive acknowledgment
SHOULD be used when the next hop is expected to forward the
packet, by listening to the channel for a transmission attempt
made by the next hop. If transmission is not detected within
NEXT_HOP_WAIT milliseconds or the next hop is the destination (and
thus is not supposed to forward the packet) one of the following
methods SHOULD be used to determine connectivity:
- 層-2通知が利用可能で、受け身の承認SHOULDでないなら、次のホップがパケットを進めると予想されるときには使用されてください、次のホップによってされたトランスミッション試みに関してチャンネルの言うことを聞くことによって。 トランスミッションがネクスト_HOP_WAITミリセカンドの中に検出されないか、次のホップが以下の方法SHOULDの目的地(そして、その結果、パケットを進めるのは思われない)1つであるなら使用されて、接続性を決定してください:
* Receiving any packet (including a Hello message) from the next
hop.
* 次のホップからどんなパケット(Helloメッセージを含んでいる)も受けます。
* A RREQ unicast to the next hop, asking for a route to the next
hop.
* 次のホップにルートを求める次のホップへのRREQユニキャスト。
Perkins, et. al. Experimental [Page 23] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[23ページ]RFC3561AODV
* An ICMP Echo Request message unicast to the next hop.
* 次のホップへのICMP Echo Requestメッセージユニキャスト。
If a link to the next hop cannot be detected by any of these methods, the forwarding node SHOULD assume that the link is lost, and take corrective action by following the methods specified in Section 6.11.
これらの方法のどれかで次のホップへのリンクを検出できないなら、推進ノードSHOULDは、リンクが無くなると仮定して、セクション6.11で指定された方法に従うことで修正措置を取ります。
6.11. Route Error (RERR) Messages, Route Expiry and Route Deletion
6.11. ルート誤り(RERR)メッセージ、ルート満期、およびルート削除
Generally, route error and link breakage processing requires the following steps:
一般に、ルート誤りとリンク折損処理は以下のステップを必要とします:
- Invalidating existing routes
- 既存のルートを無効にします。
- Listing affected destinations
- 影響を受ける目的地を記載します。
- Determining which, if any, neighbors may be affected
- 隣人がいくらか影響を受けるかもしれないなら、どれを決定するか。
- Delivering an appropriate RERR to such neighbors
- 適切なRERRをそのような隣人に届けます。
A Route Error (RERR) message MAY be either broadcast (if there are many precursors), unicast (if there is only 1 precursor), or iteratively unicast to all precursors (if broadcast is inappropriate). Even when the RERR message is iteratively unicast to several precursors, it is considered to be a single control message for the purposes of the description in the text that follows. With that understanding, a node SHOULD NOT generate more than RERR_RATELIMIT RERR messages per second.
Route Error(RERR)メッセージは、放送(多くの先駆がいれば)、ユニキャスト(1つの先駆しかいなければ)かすべての先駆への繰り返しユニキャストのどちらかであるかもしれません(放送が不適当であるなら)。 RERRメッセージが数人の先駆への繰り返しユニキャストでさえあるときに、従うテキストにおける記述の目的への単一管理メッセージであることは考えられます。 その理解、SHOULD NOTが1秒あたりのRERR_RATELIMIT RERRメッセージより作るノードで。
A node initiates processing for a RERR message in three situations:
ノードは3つの状況におけるRERRメッセージのための処理を開始します:
(i) if it detects a link break for the next hop of an active
route in its routing table while transmitting data (and
route repair, if attempted, was unsuccessful), or
または(i) データを送っている間、経路指定テーブルのアクティブなルートの次のホップのためのリンク中断を検出するなら(試みられるなら、ルート修理は失敗していました)。
(ii) if it gets a data packet destined to a node for which it
does not have an active route and is not repairing (if
using local repair), or
またはデータ・パケットを得るなら(ii)がそれがアクティブなルートを持たないで、また修理されていないノードに運命づけられた、(局部的修繕を使用するなら)。
(iii) if it receives a RERR from a neighbor for one or more
active routes.
(iii) 隣人からRERRを1つ以上のアクティブなルートに受けるなら。
For case (i), the node first makes a list of unreachable destinations consisting of the unreachable neighbor and any additional destinations (or subnets, see section 7) in the local routing table that use the unreachable neighbor as the next hop. In this case, if a subnet route is found to be newly unreachable, an IP destination address for the subnet is constructed by appending zeroes to the
ケース(i)のために、ノードが最初に手の届かない隣人とどんな追加目的地からも成る手の届かない目的地のリストを作る、(または、サブネット、地方の経路指定テーブルの次のホップとして手の届かない隣人を使用するセクション7)を見てください。 この場合、サブネットルートが新たに手が届かないのがわかっているなら、サブネットのための受信者IPアドレスは、ゼロを追加することによって、構成されます。
Perkins, et. al. Experimental [Page 24] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[24ページ]RFC3561AODV
subnet prefix as shown in the route table entry. This is unambiguous, since the precursor is known to have route table information with a compatible prefix length for that subnet.
ルートテーブルエントリーに示されるサブネット接頭語。 これは明白です、先駆にはそのサブネットのためのコンパチブル接頭語の長さがあるルートテーブル情報があるのが知られているので。
For case (ii), there is only one unreachable destination, which is the destination of the data packet that cannot be delivered. For case (iii), the list should consist of those destinations in the RERR for which there exists a corresponding entry in the local routing table that has the transmitter of the received RERR as the next hop.
ケース(ii)のために、1つの手の届かない目的地しかありません。(それは、届けることができないデータ・パケットの目的地です)。 ケース(iii)のために、リストは次のホップとして容認されたRERRの送信機を持っている地方の経路指定テーブルの対応するエントリーが存在するRERRでそれらの目的地から成るはずです。
Some of the unreachable destinations in the list could be used by neighboring nodes, and it may therefore be necessary to send a (new) RERR. The RERR should contain those destinations that are part of the created list of unreachable destinations and have a non-empty precursor list.
隣接しているノードでリストの手の届かない目的地のいくつかを使用できました、そして、したがって、(新しい)のRERRを送るのが必要であるかもしれません。 RERRは手の届かない目的地の作成されたリストの一部であるそれらの目的地を含んでいて、非空の先駆リストを持っているはずです。
The neighboring node(s) that should receive the RERR are all those that belong to a precursor list of at least one of the unreachable destination(s) in the newly created RERR. In case there is only one unique neighbor that needs to receive the RERR, the RERR SHOULD be unicast toward that neighbor. Otherwise the RERR is typically sent to the local broadcast address (Destination IP == 255.255.255.255, TTL == 1) with the unreachable destinations, and their corresponding destination sequence numbers, included in the packet. The DestCount field of the RERR packet indicates the number of unreachable destinations included in the packet.
RERRを受けるはずである隣接しているノードはすべて、新たに作成されたRERRで少なくとも手の届かない目的地の1つの先駆リストに属すものです。 RERR、RERR SHOULDを受け取るためには、必要とする1人のユニークな隣人しかいないといけないのでその隣人に向かったユニキャストになってください。 さもなければ、手の届かない目的地、およびそれらの対応する目的地一連番号があるパケットに含まれていたローカル放送アドレス(目的地IP=255.255.255.255、TTL=1)にRERRを通常送ります。 RERRパケットのDestCount分野はパケットに手の届かない目的地を含む数を示します。
Just before transmitting the RERR, certain updates are made on the routing table that may affect the destination sequence numbers for the unreachable destinations. For each one of these destinations, the corresponding routing table entry is updated as follows:
RERRを伝えるすぐ前に、手の届かない目的地への目的地一連番号に影響するかもしれない経路指定テーブルで、あるアップデートをします。 これらの目的地のそれぞれに関しては、以下の通り対応する経路指定テーブルエントリーをアップデートします:
1. The destination sequence number of this routing entry, if it
exists and is valid, is incremented for cases (i) and (ii) above,
and copied from the incoming RERR in case (iii) above.
1. それが存在していて、有効であるなら、このルーティングエントリーの目的地一連番号は、ケース(i)と(ii)のために上で増加されて、場合(iii)における上の入って来るRERRからコピーされます。
2. The entry is invalidated by marking the route entry as invalid
2. ルートエントリーが無効であるとマークすることによって、エントリーは無効にされます。
3. The Lifetime field is updated to current time plus DELETE_PERIOD.
Before this time, the entry SHOULD NOT be deleted.
3. 現在の時間とDELETE_PERIODにLifetime分野をアップデートします。 以前これは調節されて、エントリーはSHOULD NOTです。削除されます。
Note that the Lifetime field in the routing table plays dual role -- for an active route it is the expiry time, and for an invalid route it is the deletion time. If a data packet is received for an invalid route, the Lifetime field is updated to current time plus DELETE_PERIOD. The determination of DELETE_PERIOD is discussed in Section 10.
経路指定テーブルのLifetime分野がニ重の役割をプレーすることに注意してください--アクティブなルートに、満期時間です、そして、無効のルートに削除時間です。 無効のルートにデータ・パケットを受け取るなら、現在の時間とDELETE_PERIODにLifetime分野をアップデートします。 セクション10でDELETE_PERIODの決断について議論します。
Perkins, et. al. Experimental [Page 25] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[25ページ]RFC3561AODV
6.12. Local Repair
6.12. 局部的修繕
When a link break in an active route occurs, the node upstream of that break MAY choose to repair the link locally if the destination was no farther than MAX_REPAIR_TTL hops away. To repair the link break, the node increments the sequence number for the destination and then broadcasts a RREQ for that destination. The TTL of the RREQ should initially be set to the following value:
アクティブなルートによるリンク中断が起こるとき、目的地がマックス_REPAIR_TTLが遠くを跳ぶよりこれ以上選んだなら、その中断のノード上流は、局所的にリンクを修理するのを選ぶかもしれません。 ノードは、リンク中断を修理するために、目的地に一連番号を増加して、次に、その目的地にRREQを放送します。 RREQのTTLは初めは、以下の値に用意ができるべきです:
max(MIN_REPAIR_TTL, 0.5 * #hops) + LOCAL_ADD_TTL,
最大(_分_修理TTL、0.5*#、は跳ぶ)+地方の_は_TTLを加えます。
where #hops is the number of hops to the sender (originator) of the currently undeliverable packet. Thus, local repair attempts will often be invisible to the originating node, and will always have TTL >= MIN_REPAIR_TTL + LOCAL_ADD_TTL. The node initiating the repair then waits the discovery period to receive RREPs in response to the RREQ. During local repair data packets SHOULD be buffered. If, at the end of the discovery period, the repairing node has not received a RREP (or other control message creating or updating the route) for that destination, it proceeds as described in Section 6.11 by transmitting a RERR message for that destination.
#、がどこを跳ぶかは、現在「非-提出物」なパケットの送付者(創始者)へのホップの数です。 したがって、局部的修繕試みは、しばしば由来しているノードに目に見えなく、いつもTTL>がMIN_REPAIR_TTL+LOCAL_ADD_TTLとの等しさにするでしょう。 その時修理を開始するノードは、RREQに対応してRREPsを受け取るために発見の期間を待ちます。 局部的修繕データ・パケットSHOULDの間、バッファリングされてください。 修理ノードが発見の期間の終わりにRREP(または、ルートを作成するか、またはアップデートする他のコントロールメッセージ)をその目的地に受けていないなら、それはセクション6.11でその目的地へのRERRメッセージを送ることによって説明されるように続きます。
On the other hand, if the node receives one or more RREPs (or other control message creating or updating the route to the desired destination) during the discovery period, it first compares the hop count of the new route with the value in the hop count field of the invalid route table entry for that destination. If the hop count of the newly determined route to the destination is greater than the hop count of the previously known route the node SHOULD issue a RERR message for the destination, with the 'N' bit set. Then it proceeds as described in Section 6.7, updating its route table entry for that destination.
他方では、ノードが1RREPs(または、必要な目的地にルートを作成するか、またはアップデートする他のコントロールメッセージ)を受けるなら、以上、それが最初に比較する発見の間、値が無効のルートのホップカウント分野にある新しいルートのホップカウントはその目的地のためのエントリーをテーブルの上に置きます。 '目的地への新たに決定しているルートのホップカウントが以前に知られているルートのホップカウントより大きいならノードSHOULDが目的地へのRERRメッセージを発行する、'ビット設定しています。 そして、その目的地のためのルートテーブルエントリーをアップデートして、それはセクション6.7で説明されるように続きます。
A node that receives a RERR message with the 'N' flag set MUST NOT delete the route to that destination. The only action taken should be the retransmission of the message, if the RERR arrived from the next hop along that route, and if there are one or more precursor nodes for that route to the destination. When the originating node receives a RERR message with the 'N' flag set, if this message came from its next hop along its route to the destination then the originating node MAY choose to reinitiate route discovery, as described in Section 6.3.
'それがRERRメッセージを受け取るノード、'旗のセットはその目的地にルートを削除してはいけません。 取られた唯一の行動がメッセージの「再-トランスミッション」であるべきです、RERRがそのルートに沿った次のホップから到着して、目的地へのそのルートに1つ以上の先駆ノードがあれば。 '由来しているノードがいつでRERRメッセージを受け取るか、'旗のセット、このメッセージがルートに沿った次のホップから目的地に来たなら、由来しているノードは再開始ルート発見に選ぶかもしれません、セクション6.3で説明されるように。
Local repair of link breaks in routes sometimes results in increased path lengths to those destinations. Repairing the link locally is likely to increase the number of data packets that are able to be delivered to the destinations, since data packets will not be dropped as the RERR travels to the originating node. Sending a RERR to the
ルートによるリンク中断の局部的修繕は時々それらの目的地への増加する経路の長さをもたらします。 局所的にリンクを修理するのは送付先に届けることができるデータ・パケットの数を増加させそうです、RERRが由来しているノードに旅行するのに応じてデータ・パケットが落とされないので。 RERRを送ります。
Perkins, et. al. Experimental [Page 26] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[26ページ]RFC3561AODV
originating node after locally repairing the link break may allow the originator to find a fresh route to the destination that is better, based on current node positions. However, it does not require the originating node to rebuild the route, as the originator may be done, or nearly done, with the data session.
創始者は局所的にリンク中断を修理した後の由来しているノードで、より良い目的地に新鮮なルートを見つけることができるかもしれません、現在のノード位置に基づいて。 しかしながら、ルートを再建するのが由来しているノードを必要としません、創始者をするか、またはほとんどするかもしれないように、データセッションで。
When a link breaks along an active route, there are often multiple destinations that become unreachable. The node that is upstream of the lost link tries an immediate local repair for only the one destination towards which the data packet was traveling. Other routes using the same link MUST be marked as invalid, but the node handling the local repair MAY flag each such newly lost route as locally repairable; this local repair flag in the route table MUST be reset when the route times out (e.g., after the route has been not been active for ACTIVE_ROUTE_TIMEOUT). Before the timeout occurs, these other routes will be repaired as needed when packets arrive for the other destinations. Hence, these routes are repaired as needed; if a data packet does not arrive for the route, then that route will not be repaired. Alternatively, depending upon local congestion, the node MAY begin the process of establishing local repairs for the other routes, without waiting for new packets to arrive. By proactively repairing the routes that have broken due to the loss of the link, incoming data packets for those routes will not be subject to the delay of repairing the route and can be immediately forwarded. However, repairing the route before a data packet is received for it runs the risk of repairing routes that are no longer in use. Therefore, depending upon the local traffic in the network and whether congestion is being experienced, the node MAY elect to proactively repair the routes before a data packet is received; otherwise, it can wait until a data is received, and then commence the repair of the route.
リンクがアクティブなルートに沿って壊れるとき、手が届かなくなる複数の目的地がしばしばあります。 無くなっているリンクの上流であるノードはデータ・パケットが移動していた1つの目的地だけのために即座の局部的修繕を試みます。 同じリンクを使用する他のルートを無効であるとマークしなければなりませんが、局部的修繕を扱うノードは局所的に修繕可能であるようなそれぞれの新たに失われたルートに旗を揚げさせるかもしれません。 例えば、ルート回であるときにリセットが出ていたならルートテーブルのこの局部的修繕旗がそうしなければならない、(ルートがあった後、ACTIVE_ROUTE_TIMEOUTにはアクティブでない、) タイムアウトが起こる前に、パケットが他の目的地に到着するとき、これらの他のルートは必要に応じて修理されるでしょう。 したがって、これらのルートは必要に応じて修理されます。 データ・パケットがルートに到着しないと、そのルートは修理されないでしょう。 あるいはまた、地方の混雑によって、ノードは他のルートのための局部的修繕を確立するプロセスを開始するかもしれません、新しいパケットが到着するのを待たない。 リンクの損失のため壊れたルートを予測して修理することによって、それらのルートへの受信データパケットをルートを修理する遅れを受けることがなくて、すぐに、送ることができます。 しかしながら、それのためにデータ・パケットを受け取る前にルートを修理すると、もう使用中でないルートを修理するという危険は冒されます。 したがって、ネットワークのローカルの交通によって、混雑が経験されているか否かに関係なく、ノードは、データ・パケットが受け取られている前にルートを予測して修理するのを選ぶかもしれません。 さもなければ、それは、データが受信されるまで待っていて、次に、ルートの修理を始めることができます。
6.13. Actions After Reboot
6.13. リブートの後の動作
A node participating in the ad hoc network must take certain actions after reboot as it might lose all sequence number records for all destinations, including its own sequence number. However, there may be neighboring nodes that are using this node as an active next hop. This can potentially create routing loops. To prevent this possibility, each node on reboot waits for DELETE_PERIOD before transmitting any route discovery messages. If the node receives a RREQ, RREP, or RERR control packet, it SHOULD create route entries as appropriate given the sequence number information in the control packets, but MUST not forward any control packets. If the node receives a data packet for some other destination, it SHOULD broadcast a RERR as described in subsection 6.11 and MUST reset the waiting timer to expire after current time plus DELETE_PERIOD.
すべての目的地のためのすべての一連番号記録を失うかもしれないとき、臨時のネットワークに参加するノードはリブートの後に、ある行動を取らなければなりません、それ自身の一連番号を含んでいて。 しかしながら、次のアクティブなホップとしてこのノードを使用している隣接しているノードがあるかもしれません。 これは潜在的にルーティング輪を作成できます。 この可能性を防ぐために、どんなルート発見メッセージも送る前に、リブートでの各ノードはDELETE_PERIODを待ちます。 ノードがRREQ、RREPを受けるか、そして、RERRがパケットを制御します、それ。コントロールパケットの一連番号情報を適宜考えて、どんなコントロールパケットも進めてはいけないのを除いて、SHOULDはルートエントリーを作成します。 ノードはある他の目的地にデータ・パケットを受けます、それ。SHOULDは、小区分6.11で説明されるようにRERRを放送して、現在の時間とDELETE_PERIODの後に期限が切れるために待ちタイマをリセットしなければなりません。
Perkins, et. al. Experimental [Page 27] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[27ページ]RFC3561AODV
It can be shown [4] that by the time the rebooted node comes out of the waiting phase and becomes an active router again, none of its neighbors will be using it as an active next hop any more. Its own sequence number gets updated once it receives a RREQ from any other node, as the RREQ always carries the maximum destination sequence number seen en route. If no such RREQ arrives, the node MUST initialize its own sequence number to zero.
[4] リブートされたノードが待ちフェーズから出て来て、再びアクティブなルータになる時までに隣人のだれももう次のアクティブなホップとしてそれを使用しないのを示すことができます。 いかなる他のノードからもRREQをいったん受けると、それ自身の一連番号をアップデートします、RREQがいつも途中で見られた最大の目的地一連番号を運ぶとき。 どれかそのようなRREQが到着しないなら、ノードはそれ自身の一連番号をゼロに初期化しなければなりません。
6.14. Interfaces
6.14. インタフェース
Because AODV should operate smoothly over wired, as well as wireless, networks, and because it is likely that AODV will also be used with multiple wireless devices, the particular interface over which packets arrive must be known to AODV whenever a packet is received. This includes the reception of RREQ, RREP, and RERR messages. Whenever a packet is received from a new neighbor, the interface on which that packet was received is recorded into the route table entry for that neighbor, along with all the other appropriate routing information. Similarly, whenever a route to a new destination is learned, the interface through which the destination can be reached is also recorded into the destination's route table entry.
AODVがワイヤードで、無線のネットワークの上でスムーズに作動するはずであり、また、AODVが複数のワイヤレス機器と共に使用されそうであるので、パケットが受け取られているときはいつも、AODVにおいてパケットが到着する特定のインタフェースを知っていなければなりません。 これはRREQ、RREP、およびRERRメッセージのレセプションを含んでいます。 新しい隣人からパケットを受け取るときはいつも、そのパケットが受け取られたインタフェースはその隣人のためにルートテーブルエントリーに記録されます、もう片方のすべての適切なルーティング情報と共に。 また、同様に、新しい目的地へのルートが学習されるときはいつも、目的地に達することができるインタフェースは目的地のルートテーブルエントリーに記録されます。
When multiple interfaces are available, a node retransmitting a RREQ message rebroadcasts that message on all interfaces that have been configured for operation in the ad-hoc network, except those on which it is known that all of the nodes neighbors have already received the RREQ For instance, for some broadcast media (e.g., Ethernet) it may be presumed that all nodes on the same link receive a broadcast message at the same time. When a node needs to transmit a RERR, it SHOULD only transmit it on those interfaces that have neighboring precursor nodes for that route.
複数のインタフェースが利用可能であるときに、RREQメッセージを再送するノードは臨時のネットワークで操作のために構成されたすべてのインタフェースに関するそのメッセージを再放送します、ノード隣人が皆、既にRREQ For例を受けて、いくつかの電波媒体(例えば、イーサネット)において、同じリンクの上のすべてのノードが同時に同報メッセージを受け取ると推定されるかもしれないのが知られているそれらを除いて。 ノードが、必要があるときにはRERRを伝えてください、それ。SHOULDはそのルートのための隣接している先駆ノードを持っているそれらのインタフェースでそれを伝えるだけです。
7. AODV and Aggregated Networks
7. AODVと集められたネットワーク
AODV has been designed for use by mobile nodes with IP addresses that are not necessarily related to each other, to create an ad hoc network. However, in some cases a collection of mobile nodes MAY operate in a fixed relationship to each other and share a common subnet prefix, moving together within an area where an ad hoc network has formed. Call such a collection of nodes a "subnet". In this case, it is possible for a single node within the subnet to advertise reachability for all other nodes on the subnet, by responding with a RREP message to any RREQ message requesting a route to any node with the subnet routing prefix. Call the single node the "subnet router". In order for a subnet router to operate the AODV protocol for the whole subnet, it has to maintain a destination sequence number for the entire subnet. In any such RREP message sent by the subnet router, the Prefix Size field of the RREP message MUST be set to the
AODVは使用のために臨時のネットワークを創設するために必ず互いに関連するというわけではないIPアドレスがある可動のノードによって設計されます。 しかしながら、いくつかの場合、可動のノードの収集は、互いとの固定関係で作動して、一般的なサブネット接頭語を共有するかもしれません、臨時のネットワークを形成してある領域の中を一緒に動いて。 「サブネット」にノードのそのような収集に電話をしてください。 この場合、サブネットの中のただ一つのノードがサブネットの他のすべてのノードのために可到達性の広告を出すのは、可能です、どんなRREQメッセージへのRREPメッセージもサブネットルーティング接頭語でどんなノードにもルートを要求していて応じることによって。 ただ一つのノードを「サブネットルータ」と呼んでください。 サブネットルータが全体のサブネットのためにAODVプロトコルを操作して、それは全体のサブネットのために目的地一連番号を維持しなければなりません。 サブネットルータによって送られたどんなそのようなRREPメッセージにも、RREPメッセージのPrefix Size分野を設定しなければなりません。
Perkins, et. al. Experimental [Page 28] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[28ページ]RFC3561AODV
length of the subnet prefix. Other nodes sharing the subnet prefix SHOULD NOT issue RREP messages, and SHOULD forward RREQ messages to the subnet router.
サブネット接頭語の長さ。 サブネットを共有する他のノードがSHOULD NOT問題RREPメッセージ、およびSHOULDの前進のRREQメッセージをサブネットルータへ前に置きます。
The processing for RREPs that give routes to subnets (i.e., have nonzero prefix length) is the same as processing for host-specific RREP messages. Every node that receives the RREP with prefix size information SHOULD create or update the route table entry for the subnet, including the sequence number supplied by the subnet router, and including the appropriate precursor information. Then, in the future the node can use the information to avoid sending future RREQs for other nodes on the same subnet.
サブネット(すなわち、非零接頭語の長さを持っている)にルートを与えるRREPsのための処理はホスト特有のRREPメッセージのために処理するのと同じです。 SHOULDがサブネットルータによって供給された一連番号を含むサブネットのためのルートテーブルエントリーを作成するか、またはアップデートするという接頭語サイズ情報と適切な先駆情報を含んでいるのにRREPを受けるあらゆるノード。 そして将来、ノードは、他のノードのために将来のRREQsを同じサブネットに送るのを避けるのに情報を使用できます。
When a node uses a subnet route it may be that a packet is routed to an IP address on the subnet that is not assigned to any existing node in the ad hoc network. When that happens, the subnet router MUST return ICMP Host Unreachable message to the sending node. Upstream nodes receiving such an ICMP message SHOULD record the information that the particular IP address is unreachable, but MUST NOT invalidate the route entry for any matching subnet prefix.
ノードが多分サブネットルートを使用すると、パケットは臨時のネットワークにおけるどんな既存のノードにも割り当てられないサブネットに関するIPアドレスに発送されます。 それが起こると、サブネットルータはICMP Host Unreachableメッセージを送付ノードに返さなければなりません。 SHOULDが情報を記録するという特定のIPアドレスが手が届かなく、しかし、どんな合っているサブネット接頭語のためのルートエントリーも無効にしてはいけないくらいのICMPメッセージを受け取る上流のノード。
If several nodes in the subnet advertise reachability to the subnet defined by the subnet prefix, the node with the lowest IP address is elected to be the subnet router, and all other nodes MUST stop advertising reachability.
サブネットにおけるいくつかのノードがサブネット接頭語によって定義されたサブネットに可到達性の広告を出すなら、最も低いIPアドレスがあるノードはサブネットルータになるように選ばれます、そして、他のすべてのノードが可到達性の広告を出すのを止めなければなりません。
The behavior of default routes (i.e., routes with routing prefix length 0) is not defined in this specification. Selection of routes sharing prefix bits should be according to longest match first.
デフォルトルート(すなわち、ルーティング接頭語長さ0があるルート)の動きはこの仕様に基づき定義されません。 最初に、最も長いマッチに従って、接頭語ビットを共有するルートの品揃えがあるべきです。
8. Using AODV with Other Networks
8. 他のネットワークがあるAODVを使用します。
In some configurations, an ad hoc network may be able to provide connectivity between external routing domains that do not use AODV. If the points of contact to the other networks can act as subnet routers (see Section 7) for any relevant networks within the external routing domains, then the ad hoc network can maintain connectivity to the external routing domains. Indeed, the external routing networks can use the ad hoc network defined by AODV as a transit network.
いくつかの構成では、臨時のネットワークはAODVを使用しない外部の経路ドメインの間に接続性を提供できるかもしれません。 他のネットワークへの連絡先が外部の経路ドメインの中のどんな関連ネットワークのためにもサブネットルータとして機能できるなら(セクション7を見ます)、臨時のネットワークは外部の経路ドメインに接続性を維持できます。 本当に、外部のルーティングネットワークはAODVによってトランジットネットワークと定義された臨時のネットワークを使用できます。
In order to provide this feature, a point of contact to an external network (call it an Infrastructure Router) has to act as the subnet router for every subnet of interest within the external network for which the Infrastructure Router can provide reachability. This includes the need for maintaining a destination sequence number for that external subnet.
この特徴を提供するために、外部のネットワーク(それをInfrastructure Routerと呼ぶ)への連絡先は興味があるあらゆるサブネットのためのサブネットルータとしてInfrastructure Routerが可到達性を提供できる外部のネットワークの中で機能しなければなりません。 これはその外部のサブネットのために目的地一連番号を維持する必要性を含んでいます。
Perkins, et. al. Experimental [Page 29] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[29ページ]RFC3561AODV
If multiple Infrastructure Routers offer reachability to the same external subnet, those Infrastructure Routers have to cooperate (by means outside the scope of this specification) to provide consistent AODV semantics for ad hoc access to those subnets.
複数のInfrastructure Routersが同じ外部のサブネットに可到達性を提供するなら、それらのInfrastructure Routersは協力して(この仕様の範囲の外の手段で)、それらのサブネットへの臨時のアクセスに一貫したAODV意味論を提供しなければなりません。
9. Extensions
9. 拡大
In this section, the format of extensions to the RREQ and RREP messages is specified. All such extensions appear after the message data, and have the following format:
このセクションでは、RREQとRREPメッセージへの拡大の形式は指定されます。 そのようなすべての拡大が、メッセージデータの後に現れて、以下の形式を持っています:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | type-specific data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| タイプ特有のデータ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
どこ:
Type 1-255
1-255にタイプしてください。
Length The length of the type-specific data, not including the Type
and Length fields of the extension in bytes.
長さはバイトで拡大のTypeとLength分野を含まないタイプ特有のデータの長さです。
Extensions with types between 128 and 255 may NOT be skipped. The rules for extensions will be spelled out more fully, and conform to the rules for handling IPv6 options.
タイプが128と255の間ある拡大はサボられないかもしれません。 拡大のための規則は、より完全に詳しく説明されて、取り扱いIPv6オプションのために規則に従うでしょう。
9.1. Hello Interval Extension Format
9.1. こんにちは、間隔拡大形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Hello Interval ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Hello Interval, continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| こんにちは、間隔… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... こんにちは、Intervalであって、続けられています。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 1
1をタイプしてください。
Length 4
長さ4
Hello Interval
The number of milliseconds between successive transmissions
of a Hello message.
こんにちは、Helloの連続したトランスミッションの間のミリセカンドの数が通信させるInterval。
Perkins, et. al. Experimental [Page 30] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[30ページ]RFC3561AODV
The Hello Interval extension MAY be appended to a RREP message with TTL == 1, to be used by a neighboring receiver in determine how long to wait for subsequent such RREP messages (i.e., Hello messages; see section 6.9).
TTL=1があるRREPメッセージに拡大がそうするHello Intervalを追加して、中で隣接している受信機によって使用されるために、長くその後のそのようなRREPメッセージを待つ方法を決定してください(すなわち、Helloは通信します; セクション6.9を見てください)。
10. Configuration Parameters
10. 設定パラメータ
This section gives default values for some important parameters associated with AODV protocol operations. A particular mobile node may wish to change certain of the parameters, in particular the NET_DIAMETER, MY_ROUTE_TIMEOUT, ALLOWED_HELLO_LOSS, RREQ_RETRIES, and possibly the HELLO_INTERVAL. In the latter case, the node should advertise the HELLO_INTERVAL in its Hello messages, by appending a Hello Interval Extension to the RREP message. Choice of these parameters may affect the performance of the protocol. Changing NODE_TRAVERSAL_TIME also changes the node's estimate of the NET_TRAVERSAL_TIME, and so can only be done with suitable knowledge about the behavior of other nodes in the ad hoc network. The configured value for MY_ROUTE_TIMEOUT MUST be at least 2 * PATH_DISCOVERY_TIME.
このセクションはAODVプロトコル操作に関連しているいくつかの重要なパラメタのためにデフォルト値を与えます。 特定の可動のノードは_パラメタが確かな変化、特にネットへのMY_ROUTEのALLOWEDの_DIAMETER、_TIMEOUT、HELLO_LOSS、RREQ_RETRIES、およびことによるとHELLO_INTERVALを願うかもしれません。 後者の場合では、ノードはHelloメッセージにHELLO_INTERVALの広告を出すはずです、RREPメッセージにHello Interval Extensionを追加することによって。 これらのパラメタの選択はプロトコルの性能に影響するかもしれません。 _NODEを変えて、ノードのネット_TRAVERSAL_タイム誌の見積りを変えるので、TRAVERSAL_タイム誌も処理できるだけです。臨時のネットワークにおける、他のノードの動きに関する適当な知識。 構成は_少なくとも2が*PATH_ディスカバリータイム誌であったならMYのために_ROUTE_TIMEOUT MUSTを評価します。
Parameter Name Value
---------------------- -----
ACTIVE_ROUTE_TIMEOUT 3,000 Milliseconds
ALLOWED_HELLO_LOSS 2
BLACKLIST_TIMEOUT RREQ_RETRIES * NET_TRAVERSAL_TIME
DELETE_PERIOD see note below
HELLO_INTERVAL 1,000 Milliseconds
LOCAL_ADD_TTL 2
MAX_REPAIR_TTL 0.3 * NET_DIAMETER
MIN_REPAIR_TTL see note below
MY_ROUTE_TIMEOUT 2 * ACTIVE_ROUTE_TIMEOUT
NET_DIAMETER 35
NET_TRAVERSAL_TIME 2 * NODE_TRAVERSAL_TIME * NET_DIAMETER
NEXT_HOP_WAIT NODE_TRAVERSAL_TIME + 10
NODE_TRAVERSAL_TIME 40 milliseconds
PATH_DISCOVERY_TIME 2 * NET_TRAVERSAL_TIME
RERR_RATELIMIT 10
RING_TRAVERSAL_TIME 2 * NODE_TRAVERSAL_TIME *
(TTL_VALUE + TIMEOUT_BUFFER)
RREQ_RETRIES 2
RREQ_RATELIMIT 10
TIMEOUT_BUFFER 2
TTL_START 1
TTL_INCREMENT 2
TTL_THRESHOLD 7
TTL_VALUE see note below
パラメタ名前価値---------------------- ----- ACTIVE_ROUTE_TIMEOUT3,000Milliseconds ALLOWED_HELLO_LOSS2BLACKLIST_TIMEOUT RREQ_RETRIES*ネット_TRAVERSAL_TIME DELETE_PERIODは注意以下のHELLO_INTERVAL1,000Milliseconds LOCAL_ADD_TTL2マックス_REPAIR_TTL0を見ます; ネット..見る..注意..ネット..タイム誌..タイム誌..ネット..タイム誌..タイム誌..ミリセカンド..ディスカバリー..タイム誌..ネット..タイム誌..タイム誌..見る..注意..以下に
Perkins, et. al. Experimental [Page 31] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[31ページ]RFC3561AODV
The MIN_REPAIR_TTL should be the last known hop count to the destination. If Hello messages are used, then the ACTIVE_ROUTE_TIMEOUT parameter value MUST be more than the value (ALLOWED_HELLO_LOSS * HELLO_INTERVAL). For a given ACTIVE_ROUTE_TIMEOUT value, this may require some adjustment to the value of the HELLO_INTERVAL, and consequently use of the Hello Interval Extension in the Hello messages.
MIN_REPAIR_TTLは目的地への最後に知られているホップカウントであるべきです。 Helloメッセージが使用されているなら、ACTIVE_ROUTE_TIMEOUTパラメタ価値は値以上であるに違いありません(ALLOWED_HELLO_LOSS*HELLO_INTERVAL)。 与えられたACTIVE_ROUTE_TIMEOUT価値のために、これはHELLO_INTERVALの値、およびその結果HelloメッセージにおけるHello Interval Extensionの使用に何らかの調整を必要とするかもしれません。
TTL_VALUE is the value of the TTL field in the IP header while the expanding ring search is being performed. This is described further in section 6.4. The TIMEOUT_BUFFER is configurable. Its purpose is to provide a buffer for the timeout so that if the RREP is delayed due to congestion, a timeout is less likely to occur while the RREP is still en route back to the source. To omit this buffer, set TIMEOUT_BUFFER = 0.
拡張リング検索が実行されている間、TTL_VALUEはIPヘッダーのTTL分野の値です。 これはセクション6.4で、より詳しく説明されます。 TIMEOUT_BUFFERは構成可能です。 目的がタイムアウトのためのバッファを提供することであるので、RREPが混雑のため遅らせられるなら、途中でまだソースにはRREPがある間、タイムアウトが、より起こりそうにはありません。 このバッファを省略するには、TIMEOUT_BUFFER=0を設定してください。
DELETE_PERIOD is intended to provide an upper bound on the time for which an upstream node A can have a neighbor B as an active next hop for destination D, while B has invalidated the route to D. Beyond this time B can delete the (already invalidated) route to D. The determination of the upper bound depends somewhat on the characteristics of the underlying link layer. If Hello messages are used to determine the continued availability of links to next hop nodes, DELETE_PERIOD must be at least ALLOWED_HELLO_LOSS * HELLO_INTERVAL. If the link layer feedback is used to detect loss of link, DELETE_PERIOD must be at least ACTIVE_ROUTE_TIMEOUT. If hello messages are received from a neighbor but data packets to that neighbor are lost (e.g., due to temporary link asymmetry), we have to make more concrete assumptions about the underlying link layer. We assume that such asymmetry cannot persist beyond a certain time, say, a multiple K of HELLO_INTERVAL. In other words, a node will invariably receive at least one out of K subsequent Hello messages from a neighbor if the link is working and the neighbor is sending no other traffic. Covering all possibilities,
DELETE_PERIODが上流のノードAが目的地Dへの次のアクティブなホップとして隣人Bを持つことができる時に上限を提供することを意図して、BはBが(既に無効にされます)のルートをD.に削除できるこの時代にD.Beyondにルートを無効にしましたが、上限の決断はいくらか基本的なリンクレイヤの特性に依存します。 Helloメッセージがノードが次に跳ぶようにリンクの継続的な有用性を決定するのに使用されるなら、DELETE_PERIODは少なくともALLOWED_HELLO_LOSS*HELLO_INTERVALであるに違いありません。 リンクレイヤフィードバックがリンクの損失を検出するのに使用されるなら、DELETE_PERIODは少なくともACTIVE_ROUTE_TIMEOUTであるに違いありません。 こんにちは、その隣人へのデータ・パケットが無くなる(例えば、一時的なリンク非対称による)、隣人からメッセージを受け取りますが、私たちは基本的なリンクレイヤに関する、より具体的な仮定をしなければなりません。 私たちは、そのような非対称がたとえば、ある時間、HELLO_INTERVALの倍数Kを超えて持続できないと思います。 言い換えれば、リンクが働いていて、隣人が他の交通を全く送らないと、ノードはKその後のHelloメッセージから隣人から少なくとも1を不変的に受け取るでしょう。 すべての可能性をカバーしています。
DELETE_PERIOD = K * max (ACTIVE_ROUTE_TIMEOUT, HELLO_INTERVAL)
(K = 5 is recommended).
DELETE_PERIODはK*最大(ACTIVE_ROUTE_TIMEOUT、HELLO_INTERVAL)と等しいです(K=5はお勧めです)。
NET_DIAMETER measures the maximum possible number of hops between two nodes in the network. NODE_TRAVERSAL_TIME is a conservative estimate of the average one hop traversal time for packets and should include queuing delays, interrupt processing times and transfer times. ACTIVE_ROUTE_TIMEOUT SHOULD be set to a longer value (at least 10,000 milliseconds) if link-layer indications are used to detect link breakages such as in IEEE 802.11 [5] standard. TTL_START should be set to at least 2 if Hello messages are used for local connectivity information. Performance of the AODV protocol is sensitive to the chosen values of these constants, which often depend on the
ネット_DIAMETERはネットワークにおける2つのノードの間のホップの最大の可能な数を測定します。 NODE_TRAVERSAL_タイム誌は、パケットのための平均したワンバウンドの縦断時間の内輪な見積りであり、遅れ、割込み処理時間、および転送時間を列に並ばせるのを含めるべきです。 ACTIVE_ROUTE_TIMEOUT SHOULD、リンクレイヤ指摘がIEEE802.11[5]規格などのリンク折損を検出するのに使用されるなら、より長い値(少なくとも1万ミリセカンド)に設定されてください。 Helloメッセージがローカルの接続性情報に使用されるなら、TTL_STARTは少なくとも2に用意ができるべきです。 AODVプロトコルのパフォーマンスがしばしばよるこれらの定数の選ばれた値に敏感である、オン
Perkins, et. al. Experimental [Page 32] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[32ページ]RFC3561AODV
characteristics of the underlying link layer protocol, radio
technologies etc. BLACKLIST_TIMEOUT should be suitably increased if
an expanding ring search is used. In such cases, it should be
{[(TTL_THRESHOLD - TTL_START)/TTL_INCREMENT] + 1 + RREQ_RETRIES} *
NET_TRAVERSAL_TIME. This is to account for possible additional route
discovery attempts.
基本的なラジオリンクレイヤ技術プロトコルなどの特性 拡張リング検索が使用されているなら、BLACKLIST_TIMEOUTは適当に増加するべきです。 そのような場合、それは+ 1+RREQ[(TTL_THRESHOLD--TTL_START)/TTL_INCREMENT]_RETRIESが*ネット_TRAVERSAL_タイム誌であるならそうするでしょうに。 これは、可能な追加ルート発見試みを説明するためのものです。
11. Security Considerations
11. セキュリティ問題
Currently, AODV does not specify any special security measures. Route protocols, however, are prime targets for impersonation attacks. In networks where the node membership is not known, it is difficult to determine the occurrence of impersonation attacks, and security prevention techniques are difficult at best. However, when the network membership is known and there is a danger of such attacks, AODV control messages must be protected by use of authentication techniques, such as those involving generation of unforgeable and cryptographically strong message digests or digital signatures. While AODV does not place restrictions on the authentication mechanism used for this purpose, IPsec AH is an appropriate choice for cases where the nodes share an appropriate security association that enables the use of AH.
現在、AODVはどんな特別担保測定も指定しません。 しかしながら、ルートプロトコルはものまね攻撃のための主要な目標です。 ノード会員資格が知られていないネットワークでは、ものまね攻撃の発生を決定するのが難しく、セキュリティ防止のテクニックはせいぜい難しいです。 しかしながら、ネットワーク会員資格がそこで知られているとき、そのような攻撃では、暗号で非鍛造可能の世代にかかわるものなどの認証のテクニックの使用でAODVコントロールメッセージを保護しなければならないことにおける危険は、強いメッセージダイジェストかそれともデジタル署名ですか? AODVはこのために使用される認証機構に関して制限を課しませんが、IPsec AHはノードがAHの使用を可能にする適切なセキュリティ協会を共有するケースのための適当な選択です。
In particular, RREP messages SHOULD be authenticated to avoid creation of spurious routes to a desired destination. Otherwise, an attacker could masquerade as the desired destination, and maliciously deny service to the destination and/or maliciously inspect and consume traffic intended for delivery to the destination. RERR messages, while less dangerous, SHOULD be authenticated in order to prevent malicious nodes from disrupting valid routes between nodes that are communication partners.
特定のRREPメッセージSHOULDでは、認証されて、偽物のルートの創造を必要な目的地として避けてください。 さもなければ、攻撃者は、陰湿に配送のために目的地に意図する交通の、必要な目的地のふりをして、陰湿に目的地に対するサービスを否定する、点検して、そして/または、消費できました。 RERRは通信します、それほど危険ではありませんが、SHOULD。悪意があるノードがコミュニケーションパートナーであるノードの間の有効なルートを混乱させるのを防ぐには、認証されてください。
AODV does not make any assumption about the method by which addresses are assigned to the mobile nodes, except that they are presumed to have unique IP addresses. Therefore, no special consideration, other than what is natural because of the general protocol specifications, can be made about the applicability of IPsec authentication headers or key exchange mechanisms. However, if the mobile nodes in the ad hoc network have pre-established security associations, it is presumed that the purposes for which the security associations are created include that of authorizing the processing of AODV control messages. Given this understanding, the mobile nodes should be able to use the same authentication mechanisms based on their IP addresses as they would have used otherwise.
AODVはアドレスが可動のノードに割り当てられる方法に関する少しの仮定もしません、固有のIPアドレスがあえてそれらが持たれているのを除いて。 したがって、一般的なプロトコル仕様のために当然のこと以外に、IPsec認証ヘッダーか主要な交換メカニズムの適用性に関して特別の配慮を全くすることができません。しかしながら、臨時のネットワークにおける可動のノードがセキュリティ協会をあらかじめ設立したなら、セキュリティ協会が創設される目的がAODVコントロールメッセージの処理を認可するものを含んでいると推定します。 この理解を考えて、そうでなければ、可動のノードは使用されていた状態で基づくようにそれらのIPアドレスに基づく同じ認証機構を使用するはずであることができます。
Perkins, et. al. Experimental [Page 33] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[33ページ]RFC3561AODV
12. IANA Considerations
12. IANA問題
AODV defines a "Type" field for messages sent to port 654. A new registry has been created for the values for this Type field, and the following values have been assigned:
AODVは654を移植するために送られたメッセージのために「タイプ」分野を定義します。 値のためにこのType分野に新しい登録を作成してあります、そして、以下の値を割り当ててあります:
Message Type Value
--------------------------- -----
Route Request (RREQ) 1
Route Reply (RREP) 2
Route Error (RERR) 3
Route-Reply Ack (RREP-ACK) 4
メッセージタイプ価値--------------------------- ----- ルート要求(RREQ)1ルート回答(RREP)2ルート誤り(RERR)3ルート回答Ack(RREP-ACK)4
AODV control messages can have extensions. Currently, only one extension is defined. A new registry has been created for the Type field of the extensions:
AODVコントロールメッセージは拡張子を持つことができます。 現在、1つの拡大だけが定義されます。 拡大のType分野に新しい登録を作成してあります:
Extension Type Value
--------------------------- -----
Hello Interval 1
拡大タイプ価値--------------------------- ----- こんにちは、間隔1
Future values of the Message Type or Extension Type can be allocated using standards action [2].
規格動作[2]を使用することでMessage TypeかExtension Typeの将来価値を割り当てることができます。
13. IPv6 Considerations
13. IPv6問題
See [6] for detailed operation for IPv6. The only changes to the protocol are that the address fields are enlarged.
IPv6に関して詳細な操作のための[6]を見てください。 プロトコルへの唯一の変化はアドレス・フィールドが拡大しているということです。
14. Acknowledgments
14. 承認
Special thanks to Ian Chakeres, UCSB, for his extensive suggestions and contributions to recent revisions.
イアンChakeres、彼の大規模な提案のためのUCSB、および最近の改正への貢献のおかげで、特別です。
We acknowledge with gratitude the work done at University of Pennsylvania within Carl Gunter's group, as well as at Stanford and CMU, to determine some conditions (especially involving reboots and lost RERRs) under which previous versions of AODV could suffer from routing loops. Contributors to those efforts include Karthikeyan Bhargavan, Joshua Broch, Dave Maltz, Madanlal Musuvathi, and Davor Obradovic. The idea of a DELETE_PERIOD, for which expired routes (and, in particular, the sequence numbers) to a particular destination must be maintained, was also suggested by them.
私たちは謝意をもってAODVの旧バージョンがルーティング輪を欠点であることができたいくつかの条件(リブートと無くなっているRERRsに特にかかわる)を決定するためにカールGunterのグループの中のペンシルバニア大学においてスタンフォードと米カーネギーメロン大学で行われた仕事を承諾します。 それらの努力への貢献者はKarthikeyan Bhargavan、ジャシュア・ブロッホ、デーヴ・マルツ、Madanlal Musuvathi、およびデブール・オブラードビチを入れます。 また、DELETE_PERIODの考えは彼らによって示されました。(PERIODに関して特定の目的地への満期のルート(特に一連番号)を維持しなければなりません)。
We also acknowledge the comments and improvements suggested by Sung- Ju Lee (especially regarding local repair), Mahesh Marina, Erik Nordstrom (who provided text for section 6.11), Yves Prelot, Marc Mosko, Manel Guerrero Zapata, Philippe Jacquet, and Fred Baker.
また、私たちはマークMosko、ManelゲレロのSung- Juリー(特に局部的修繕に関する)、マヘシュ・マリナ、エリック・ノードストロム(セクション6.11にテキストを供給した)、イヴPrelot、サパタ、フィリップ・ジャケ、およびフレッド・ベイカーによって提案されたコメントと改良を承諾します。
Perkins, et. al. Experimental [Page 34] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[34ページ]RFC3561AODV
15. Normative References
15. 引用規格
[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月。
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[2]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
16. Informative References
16. 有益な参照
[3] Manner, J., et al., "Mobility Related Terminology", Work in
Progress, July 2001.
[3] 方法、J.、他、「移動性関連用語」、Progress、2001年7月のWork。
[4] Karthikeyan Bhargavan, Carl A. Gunter, and Davor Obradovic.
Fault Origin Adjudication. In Proceedings of the Workshop on
Formal Methods in Software Practice, Portland, OR, August 2000.
[4]Karthikeyan Bhargavan、カールA.ガンター氏比例尺、およびデブール・オブラードビチ。 欠点起源判決。 中では、正式な方法におけるソフトウェアにおける、ワークショップの議事はポートランド(OR)2000年8月に練習されます。
[5] IEEE 802.11 Committee, AlphaGraphics #35, 10201 N.35th Avenue,
Phoenix AZ 85051. Wireless LAN Medium Access Control MAC and
Physical Layer PHY Specifications, June 1997. IEEE Standard
802.11-97.
[5] IEEE802.11委員会、AlphaGraphics#35、10201のN.第35アベニュー、フェニックスアリゾナ 85051。 無線のLAN媒体アクセス制御MACと物理的な層のPHY仕様、1997年6月。 IEEE規格802.11-97。
[6] Perkins, C., Royer, E. and S. Das, "Ad hoc on demand distance
vector (AODV) routing for ip version 6", Work in Progress.
[6] パーキンスとC.とロワイエーとE.とS.ダス、「ipバージョン6インチ臨時のオンデマンドの距離ベクトル(AODV)ルーティング、ProgressのWork。」
Perkins, et. al. Experimental [Page 35] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[35ページ]RFC3561AODV
17. Authors' Addresses
17. 作者のアドレス
Charles E. Perkins Communications Systems Laboratory Nokia Research Center 313 Fairchild Drive Mountain View, CA 94303 USA
チャールズE.パーキンス通信網研究所ノキアリサーチセンター313フェアチャイルド・Driveカリフォルニア94303マウンテンビュー(米国)
Phone: +1 650 625 2986 Fax: +1 650 691 2170 (fax) EMail: Charles.Perkins@nokia.com
以下に電話をしてください。 +1 650 625、2986Fax: +1 650 691 2170(ファックス)メール: Charles.Perkins@nokia.com
Elizabeth M. Belding-Royer Department of Computer Science University of California, Santa Barbara Santa Barbara, CA 93106
エリザベスM.ベルディング-ロワイエーコンピュータサイエンス学部カリフォルニア大学、サンタバーバラ・サンタバーバラ、カリフォルニア 93106
Phone: +1 805 893 3411 Fax: +1 805 893 8553 EMail: ebelding@cs.ucsb.edu
以下に電話をしてください。 +1 805 893、3411Fax: +1 8553年の805 893メール: ebelding@cs.ucsb.edu
Samir R. Das Department of Electrical and Computer Engineering & Computer Science University of Cincinnati Cincinnati, OH 45221-0030
電気とコンピュータ工学のSamir R.ダス部とシンシナティ、コンピュータサイエンスシンシナティ大学OH45221-0030
Phone: +1 513 556 2594 Fax: +1 513 556 7326 EMail: sdas@ececs.uc.edu
以下に電話をしてください。 +1 513 556、2594Fax: +1 7326年の513 556メール: sdas@ececs.uc.edu
Perkins, et. al. Experimental [Page 36] RFC 3561 AODV Routing July 2003
etパーキンス、アル。 2003年7月に掘る実験的な[36ページ]RFC3561AODV
18. Full Copyright Statement
18. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Perkins, et. al. Experimental [Page 37]
etパーキンス、アル。 実験的[37ページ]
一覧
スポンサーリンク
