Hi all,
So.... here are the changes I made in response to today's teleconference.
Start of 4.3 - MUST
4.3. Neighbor Table
A neighbor table MUST be maintained with information about
neighboring AODVv2 routers, including an indication of the state of
the adjacency to the router. Section 6.2 discusses how to monitor
adjacency.
Start of 6.2: - MUST + extra description
6.2. Adjacency Monitoring
An adjacency is a bidirectional relationship between neighboring
AODVv2 routers for the purpose of exchanging routing information.
Not every pair of neighboring routers will necessarily form an
adjacency, but AODVv2 routers MUST monitor connectivity to
neighboring AODVv2 routers along potential routes and MUST NOT
establish routes over uni-directional links, since packet losses are
likely to occur and route establishment can fail.
Bidirectionality to the next hop toward TargAddr is confirmed by
receipt of the Route Reply message, since a Route Reply message is a
reply to a Route Request message which previously crossed the link in
the opposite direction.
The default approach for monitoring bidirectional connectivity to the
next hop toward OrigAddr is to request acknowledgement of Route Reply
messages. Receipt of an acknowledgement proves that bidirectional
connectivity exists. All AODVv2 routers MUST support this process,
which is explained in Section 7.2 and Section 7.3.
When routers perform other operations such as those from the list
below, these can be used as additional indications of connectivity:
o NHDP HELLO Messages [RFC6130]
o Route timeout
o Lower layer triggers, e.g. message reception or link status
notifications
o TCP timeouts
o Promiscuous listening
o Other monitoring mechanisms or heuristics
For example, receipt of a Neighborhood Discovery Protocol HELLO
message with the receiving router listed as a neighbor is a signal of
bidirectional connectivity. In this case, acknowledgement of a RREP
message sent to that neighbor is unnecessary. Similarly, if AODVv2
receives notification of a timeout, this may be due to a
disconnection. The AODVv2 router SHOULD attempt to verify
connectivity by requesting acknowledgement of the next RREP sent to
that neighbor.
The Neighbor Table (Section 4.3) gives the last known state of the
neighbor adjacency, either Confirmed, Unknown, or Blacklisted. Until
bidirectionality is confirmed, the state is Unknown, and
acknowledgement of RREP messages MUST be requested. If the state is
Confirmed, the acknowledgement request is unnecessary. If
bidirectionality
cannot be confirmed, the state is Blacklisted. RREQs received from a
blacklisted router, or any router over a link that is known to be
incoming-only, MUST be disregarded.
In 7.2.1 RREP Generation: - MUST + extra description
If the next hop neighbor on the route to OrigAddr is not yet
confirmed as adjacent (as described in Section 6.2), the RREP MUST
include an AckReq data element in order to perform adjacency
monitoring. If the adjacency is already confirmed, it can be
omitted. The AckReq data element indicates that an acknowledgement
to the RREP is requested in the form of a Route Reply Acknowledgement
(RREP_Ack).
Implementations may allow a number of retries of the RREP if an
acknowledgement is not received within RREP_Ack_SENT_TIMEOUT,
doubling the timeout with each retry, up to a maximum of
RREP_RETRIES, using the same exponential backoff described in
Section 6.4 for RREQ retries. Adjacency confirmation MUST be
considered to have failed after the wait time for a RREP_Ack response
to the final RREP. The next hop router MUST be marked as blacklisted
(Section 4.3), and any installed routes with next hop set to the
newly blacklisted router should be invalidated.
In 7.2.3 RREP Regeneration: - MUST + extra description
If the next hop neighbor on the route to OrigAddr is not yet
confirmed as adjacent (as described in Section 6.2), the RREP MUST
include an AckReq data element in order to perform adjacency
monitoring. If the adjacency is already confirmed, it can be
omitted. The AckReq data element indicates that an acknowledgement
to the RREP is requested in the form of a Route Reply Acknowledgement
(RREP_Ack).
7.3. Route Reply Acknowledgement (RREP_Ack) Message - MUST
The Route Reply Acknowledgement MUST be sent in response to a
received Route Reply which includes an AckReq data element. When the
RREP_Ack message is received, it confirms the adjacency between the
two routers. The RREP_Ack has no data elements.
7.3.1. RREP_Ack Generation - MUST
A RREP_Ack MUST be generated when the AckReq data element is included
in a received RREP.
I'll send out a version of the draft (10a) separately in a few minutes.
Feel free to comment and suggest changes though :)
Kind regards,
Vicky.
