ad_hoc.txt

283个中文RFC文档

6.6.2. Route Reply Generation by an Intermediate Node

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.

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.

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.

6.6.3. Generating Gratuitous 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:

Hop Count The Hop Count as indicated in the
node's route table entry for the
originator

Destination IP Address The IP address of the node that
originated the RREQ

Destination Sequence Number The Originator Sequence Number from
the RREQ

Originator IP Address The IP address of the Destination
node in the RREQ

Lifetime The remaining lifetime of the route
towards the originator of the RREQ,
as known by the intermediate node.

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.

6.7. Receiving and Forwarding Route Replies

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:

(i) the sequence number in the routing table is marked as
invalid in route table entry.

(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

(iii) the sequence numbers are the same, but the route is is
marked as inactive, or

(iv) the sequence numbers are the same, and the New Hop Count is
smaller than the hop count in route table entry.

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,

- the hop count is set to the value of the New Hop Count,

- the expiry time is set to the current time plus the value of the
Lifetime in the RREP message,

- and the destination sequence number is the Destination Sequence
Number in the RREP message.

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).

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.

6.8. Operation over Unidirectional Links

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

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.

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.

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.

6.9. Hello Messages

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:

Destination IP Address The node's IP address.

Destination Sequence Number The node's latest sequence number.

Hop Count 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

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.

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.

6.10. Maintaining Local Connectivity

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.

- 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.

- 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:

* Receiving any packet (including a Hello message) from the next
hop.

* A RREQ unicast to the next hop, asking for a route to the next
hop.

* An ICMP Echo Request message unicast to the next hop.

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.

6.11. Route Error (RERR) Messages, Route Expiry and Route Deletion

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

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.

A node initiates processing for a RERR message in three situations:

(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

(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

(iii) if it receives a RERR from a neighbor for one or more
active routes.