ad_hoc.txt

283个中文RFC文档

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

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.

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.

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.

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:

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.

2. The entry is invalidated by marking the route entry as invalid

3. The Lifetime field is updated to current time plus DELETE_PERIOD.
Before this time, the entry SHOULD NOT be deleted.

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.

6.12. Local Repair

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:

max(MIN_REPAIR_TTL, 0.5 * #hops) + LOCAL_ADD_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.

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.

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.

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

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.

6.13. Actions After Reboot

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.

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.

6.14. Interfaces

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.

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.

7. AODV and Aggregated Networks

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

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.

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.

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.

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.

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.

8. Using AODV with Other Networks

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.

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.

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.

9. Extensions

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:

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

where:

Type 1-255

Length The length of the type-specific data, not includi