draft-ietf-manet-dymo-24.txt   draft-ietf-manet-dymo-25.txt 
Mobile Ad hoc Networks Working Group C. Perkins Mobile Ad hoc Networks Working Group C. Perkins
Internet-Draft Futurewei Internet-Draft Futurewei
Intended status: Standards Track I. Chakeres Intended status: Standards Track I. Chakeres
Expires: June 4, 2013 CenGen Expires: July 8, 2013 CenGen
December 1, 2012 January 4, 2013
Dynamic MANET On-demand (AODVv2) Routing Dynamic MANET On-demand (AODVv2) Routing
draft-ietf-manet-dymo-24 draft-ietf-manet-dymo-25
Abstract Abstract
The Dynamic MANET On-demand (AODVv2) routing protocol is intended for The Dynamic MANET On-demand (AODVv2) routing protocol is intended for
use by mobile routers in wireless, multihop networks. AODVv2 use by mobile routers in wireless, multihop networks. AODVv2
determines unicast routes among AODVv2 routers within the network in determines unicast routes among AODVv2 routers within the network in
an on-demand fashion, offering on-demand convergence in dynamic an on-demand fashion, offering on-demand convergence in dynamic
topologies. topologies.
Status of this Memo Status of this Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 4, 2013. This Internet-Draft will expire on July 8, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Notational Conventions . . . . . . . . . . . . . . . . . . . . 7 3. Notational Conventions . . . . . . . . . . . . . . . . . . . . 8
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 9 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 8
5. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 10 5. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Route Table Entry . . . . . . . . . . . . . . . . . . . . 10 5.1. Route Table Entry . . . . . . . . . . . . . . . . . . . . 10
5.2. Bidirectional Connectivity During Route Discovery and 5.2. Bidirectional Connectivity and Blacklists . . . . . . . . 12
Blacklists . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Router Clients and Client Networks . . . . . . . . . . . . 13 5.3. Router Clients and Client Networks . . . . . . . . . . . . 13
5.4. AODVv2 Packet Header Fields and Information Elements . . . 13 5.4. AODVv2 Packet Header Fields and Information Elements . . . 13
5.5. AODVv2 Sequence Numbers . . . . . . . . . . . . . . . . . 14 5.5. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . 14
5.6. Enabling Alternate Metrics . . . . . . . . . . . . . . . . 15 5.6. Enabling Alternate Metrics . . . . . . . . . . . . . . . . 15
6. AODVv2 Operations on Route Table Entries . . . . . . . . . . . 17 5.7. RREQ Table: Received RREQ . . . . . . . . . . . . . . . . 17
6.1. Evaluating Incoming Routing Information . . . . . . . . . 17 6. AODVv2 Operations on Route Table Entries . . . . . . . . . . . 18
6.2. Applying Route Updates To Route Table Entries . . . . . . 19 6.1. Evaluating Incoming Routing Information . . . . . . . . . 18
6.3. Route Table Entry Timeouts . . . . . . . . . . . . . . . . 19 6.2. Applying Route Updates To Route Table Entries . . . . . . 20
7. Routing Messages RREQ and RREP (RteMsgs) . . . . . . . . . . . 20 6.3. Route Table Entry Timeouts . . . . . . . . . . . . . . . . 21
7.1. Route Discovery Retries and Buffering . . . . . . . . . . 20 7. Routing Messages RREQ and RREP (RteMsgs) . . . . . . . . . . . 21
7.2. RteMsg Structure . . . . . . . . . . . . . . . . . . . . . 21 7.1. Route Discovery Retries and Buffering . . . . . . . . . . 22
7.3. RREQ Generation . . . . . . . . . . . . . . . . . . . . . 23 7.2. RteMsg Structure . . . . . . . . . . . . . . . . . . . . . 22
7.4. RREP Generation . . . . . . . . . . . . . . . . . . . . . 24 7.3. RREQ Generation . . . . . . . . . . . . . . . . . . . . . 24
7.5. Handling a Received RteMsg . . . . . . . . . . . . . . . . 25 7.4. RREP Generation . . . . . . . . . . . . . . . . . . . . . 25
7.5.1. Additional Handling for Outgoing RREQ . . . . . . . . 26 7.5. Handling a Received RteMsg . . . . . . . . . . . . . . . . 26
7.5.2. Additional Handling for Outgoing RREP . . . . . . . . 27 7.5.1. Additional Handling for Incoming RREQ . . . . . . . . 28
8. Route Maintenance . . . . . . . . . . . . . . . . . . . . . . 27 7.5.2. Additional Handling for Incoming RREP . . . . . . . . 28
8.1. Handling Route Lifetimes During Packet Forwarding . . . . 27 7.6. Suppressing Useless RteMsgs . . . . . . . . . . . . . . . 29
8.2. Active Next-hop Router Adjacency Monitoring . . . . . . . 28 8. Route Maintenance . . . . . . . . . . . . . . . . . . . . . . 29
8.3. RERR Generation . . . . . . . . . . . . . . . . . . . . . 28 8.1. Maintaining Route Lifetimes During Packet Forwarding . . . 29
8.3.1. Case 1: Undeliverable Packet . . . . . . . . . . . . . 29 8.2. Active Next-hop Router Adjacency Monitoring . . . . . . . 30
8.3.2. Case 2: Broken Link . . . . . . . . . . . . . . . . . 30 8.3. RERR Generation . . . . . . . . . . . . . . . . . . . . . 30
8.4. Receiving and Handling RERR Messages . . . . . . . . . . . 30 8.3.1. Case 1: Undeliverable Packet . . . . . . . . . . . . . 32
9. Unknown Message and TLV Types . . . . . . . . . . . . . . . . 31 8.3.2. Case 2: Broken Link . . . . . . . . . . . . . . . . . 32
10. Simple Internet Attachment . . . . . . . . . . . . . . . . . . 32 8.4. Receiving and Handling RERR Messages . . . . . . . . . . . 33
11. Multiple Interfaces . . . . . . . . . . . . . . . . . . . . . 33 9. Unknown Message and TLV Types . . . . . . . . . . . . . . . . 34
12. AODVv2 Control Packet/Message Generation Limits . . . . . . . 33 10. Simple Internet Attachment . . . . . . . . . . . . . . . . . . 34
13. Optional Features . . . . . . . . . . . . . . . . . . . . . . 33 11. Multiple Interfaces . . . . . . . . . . . . . . . . . . . . . 35
13.1. Expanding Rings Multicast . . . . . . . . . . . . . . . . 34 12. AODVv2 Control Packet/Message Generation Limits . . . . . . . 36
13.2. Intermediate RREP . . . . . . . . . . . . . . . . . . . . 34 13. Optional Features . . . . . . . . . . . . . . . . . . . . . . 36
13.3. Precursor Lists and Notifications . . . . . . . . . . . . 34 13.1. Expanding Rings Multicast . . . . . . . . . . . . . . . . 36
13.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 34 13.2. Intermediate RREP . . . . . . . . . . . . . . . . . . . . 36
13.3.2. Precursor Notification Details . . . . . . . . . . . . 35 13.3. Precursor Lists and Notifications . . . . . . . . . . . . 37
13.4. Multicast RREP Response to RREQ . . . . . . . . . . . . . 35 13.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 37
13.5. RREP_ACK . . . . . . . . . . . . . . . . . . . . . . . . . 36 13.3.2. Precursor Notification Details . . . . . . . . . . . . 37
13.6. Message Aggregation . . . . . . . . . . . . . . . . . . . 36 13.4. Multicast RREP Response to RREQ . . . . . . . . . . . . . 38
13.7. Added Routing Information in RteMsgs . . . . . . . . . . . 36 13.5. RREP_ACK . . . . . . . . . . . . . . . . . . . . . . . . . 38
13.7.1. Including Added Node Information . . . . . . . . . . . 36 13.6. Message Aggregation . . . . . . . . . . . . . . . . . . . 39
13.7.2. Handling Added Node Information . . . . . . . . . . . 37 13.7. Added Routing Information in RteMsgs . . . . . . . . . . . 39
14. Administratively Configured Parameters and Timer Values . . . 38 13.7.1. Including Added Node Information . . . . . . . . . . . 39
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 13.7.2. Handling Added Node Information . . . . . . . . . . . 40
15.1. AODVv2 Message Types Specification . . . . . . . . . . . . 41 14. Administratively Configurable Parameters and Timer Values . . 41
15.2. Message and Address Block TLV Type Specification . . . . . 41 14.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 42
15.3. Address Block TLV Specification . . . . . . . . . . . . . 42 14.2. Protocol constants . . . . . . . . . . . . . . . . . . . . 42
15.4. Metric Type Number Allocation . . . . . . . . . . . . . . 42 14.3. Administrative (functional) controls . . . . . . . . . . . 43
16. Security Considerations . . . . . . . . . . . . . . . . . . . 43 14.4. Other administrative parameters and lists . . . . . . . . 43
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 15.1. AODVv2 Message Types Specification . . . . . . . . . . . . 44
18.1. Normative References . . . . . . . . . . . . . . . . . . . 45 15.2. Message TLV Type Specification . . . . . . . . . . . . . . 44
18.2. Informative References . . . . . . . . . . . . . . . . . . 46 15.3. Address Block TLV Specification . . . . . . . . . . . . . 44
Appendix A. Example RFC 5444-compliant packet formats . . . . . . 47 15.4. Metric Type Number Allocation . . . . . . . . . . . . . . 44
A.1. RREQ Message Format . . . . . . . . . . . . . . . . . . . 48 16. Security Considerations . . . . . . . . . . . . . . . . . . . 45
A.2. RREP Message Format . . . . . . . . . . . . . . . . . . . 48 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47
A.3. RERR Message Format . . . . . . . . . . . . . . . . . . . 49 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
A.4. RREP_ACK Message Format . . . . . . . . . . . . . . . . . 50 18.1. Normative References . . . . . . . . . . . . . . . . . . . 47
Appendix B. Changes since revision ...-21.txt . . . . . . . . . . 50 18.2. Informative References . . . . . . . . . . . . . . . . . . 48
Appendix C. Shifting Network Prefix Advertisement Between Appendix A. Example RFC 5444-compliant packet formats . . . . . . 49
AODVv2 Routers . . . . . . . . . . . . . . . . . . . 53 A.1. RREQ Message Format . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 A.2. RREP Message Format . . . . . . . . . . . . . . . . . . . 52
A.3. RERR Message Format . . . . . . . . . . . . . . . . . . . 54
A.4. RREP_ACK Message Format . . . . . . . . . . . . . . . . . 55
Appendix B. Changes since revision ...-24.txt . . . . . . . . . . 55
Appendix C. Changes between revisions ...-21.txt and
...-24.txt . . . . . . . . . . . . . . . . . . . . . 56
Appendix D. Shifting Network Prefix Advertisement Between
AODVv2 Routers . . . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58
1. Overview 1. Overview
The Dynamic MANET On-demand (AODVv2) routing protocol [formerly named The Dynamic MANET On-demand (AODVv2) routing protocol [formerly named
DYMO] enables on-demand, multihop unicast routing among AODVv2 DYMO] enables on-demand, multihop unicast routing among AODVv2
routers in mobile ad hod networks [MANETs][RFC2501]. The basic routers in mobile ad hod networks [MANETs][RFC2501]. The basic
operations of the AODVv2 protocol are route discovery and route operations of the AODVv2 protocol are route discovery and route
maintenance. Route discovery is performed when an AODVv2 router must maintenance. Route discovery is performed when an AODVv2 router must
transmit a packet towards a destination for which it does not have a transmit a packet towards a destination for which it does not have a
route. Route maintenance is performed to avoid prematurely expunging route. Route maintenance is performed to avoid prematurely expunging
routes from the route table, and to avoid dropping packets when a routes from the route table, and to avoid dropping packets when an
route being used to forward packets from the source to a destination active route breaks.
breaks.
During route discovery, an AODVv2 router multicasts a Route Request During route discovery, an AODVv2 router (RREQ_Gen) multicasts a
message (RREQ) to find a route toward a particular destination, via Route Request message (RREQ) to find a route toward some target
the AODVv2 router responsible for this destination. Using a hop-by- destination. Using a hop-by-hop retransmission algorithm, each
hop retransmission algorithm, each intermediate AODVv2 router AODVv2 router receiving the RREQ message records a route toward the
receiving the RREQ message records a route toward the originator. originator. When the target's AODVv2 router (RREP_Gen) receives the
When the target's AODVv2 router (TargRtr) receives the RREQ, it RREQ, it records a route toward RREQ_Gen and generates a Route Reply
records a route toward the originator and responds with a Route Reply (RREP) unicast toward RREQ_Gen. Each AODVv2 router that receives the
(RREP) unicast hop-by-hop toward the originating AODVv2 router. Each RREP stores a route toward the target, and again unicasts the RREP
intermediate AODVv2 router that receives the RREP creates a route toward the originator. When RREQ_Gen receives the RREP, routes have
toward the target, and unicasts the RREP hop-by-hop toward the then been established between RREQ_Gen (the originating AODVv2
originator. When the originator's AODVv2 router receives the RREP, router) and RREP_Gen (the target's AODVv2 router) in both directions.
routes have then been established between the originating AODVv2
router and the target AODVv2 router in both directions.
Route maintenance consists of two operations. In order to preserve Route maintenance consists of two operations. In order to maintain
active routes, AODVv2 routers extend route lifetimes upon active routes, AODVv2 routers extend route lifetimes upon
successfully forwarding a packet. When a data packet is received for successfully forwarding a packet. When a data packet is received
forwarding and there is no valid route for the destination, then the downstream for forwarding but there is no valid route for the
AODVv2 router of the source of the packet is notified via a Route destination, then the AODVv2 router of the source of the packet is
Error (RERR) message. Each upstream router that receives the RERR notified via a Route Error (RERR) message. Each upstream router that
marks the route as broken. Before such an upstream AODVv2 router receives the RERR marks the route as broken. Before such an upstream
could forward a packet to the same destination, it would have to AODVv2 router could forward a packet to the same destination, it
perform route discovery again for that destination. would have to perform route discovery again for that destination.
AODVv2 uses sequence numbers to assure loop freedom [Perkins99], AODVv2 uses sequence numbers to assure loop freedom [Perkins99],
similarly to AODV. Sequence numbers enable AODVv2 routers to similarly to AODV. Sequence numbers enable AODVv2 routers to
determine the temporal order of AODVv2 route discovery messages, determine the temporal order of AODVv2 route discovery messages,
thereby avoiding use of stale routing information. Unlike AODV, thereby avoiding use of stale routing information. Unlike AODV,
AODVv2 uses RFC 5444 message and TLV formats. AODVv2 uses RFC 5444 message and TLV formats.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
This document also uses some terminology from [RFC5444]. This document also uses some terminology from [RFC5444].
This document defines the following terminology: This document defines the following terminology:
Adjacency Adjacency
A bi-directional relationship between neighboring routers for the A bi-directional relationship between neighboring AODVv2 routers
purpose of exchanging routing information. Not every pair of for the purpose of exchanging routing information. Not every pair
neighboring routers will necessarily form an adjacency. of neighboring routers will necessarily form an adjacency.
Neighboring routers may form an adjacency based on various Neighboring routers may form an adjacency based on various
information or other protocols; for example, exchange of AODVv2 information or other protocols; for example, exchange of AODVv2
routing messages, other protocols (e.g. NDP [RFC4861] or NHDP routing messages, other protocols (e.g. NDP [RFC4861] or NHDP
[RFC6130]), or manual configuration. Loss of a routing adjacency [RFC6130]), or manual configuration. Loss of a routing adjacency
may also be based upon similar information; monitoring of may also be based upon similar information; monitoring of
adjacencies where packets are being forwarded is required (see adjacencies where packets are being forwarded is required (see
Section 8.2). Section 8.2).
AODVv2 Router AODVv2 Router
An IP addressable device in the ad-hoc network that performs the An IP addressable device in the ad-hoc network that performs the
AODVv2 protocol operations specified in this document. AODVv2 protocol operations specified in this document.
AODVv2 Sequence Number (SeqNum) AODVv2 Sequence Number (SeqNum)
An AODVv2 Sequence Number is an unsigned integer maintained by Same as Sequence Number.
each AODVv2 router. This sequence number guarantees the temporal
order of routing information to maintain loop-free routes. The
value zero (0) is reserved to indicate that the SeqNum for a
destination address is unknown.
Current_Time Current_Time
The current time as maintained by the AODVv2 router. The current time as maintained by the AODVv2 router.
disregard disregard
Ignore for further processing (see Section 5.4), and delete unless Ignore for further processing (see Section 5.4), and delete unless
it is required to keep the message in the packet for purposes of it is required to keep the message in the packet for purposes of
authentication. authentication.
Handling Router (HandlingRtr) Handling Router (HandlingRtr)
HandlingRtr denotes the AODVv2 router handling an AODVv2 message. HandlingRtr denotes the AODVv2 router receiving and handling an
AODVv2 message.
Incoming Link Incoming Link
A link over which an AODVv2 has received a message from one of its A link over which an AODVv2 router has received a message from an
adjacent routers. adjacent router.
MANET MANET
A Mobile Ad Hoc Network as defined in [RFC2501]. A Mobile Ad Hoc Network as defined in [RFC2501].
node node
An IP addressable device in the ad-hoc network. A node may be an An IP addressable device in the ad-hoc network. A node may be an
AODVv2 router, or it may be a device in the network that does not AODVv2 router, or it may be a device in the network that does not
perform any AODVv2 protocol operations. All nodes in this perform any AODVv2 protocol operations. All nodes in this
document are either AODVv2 Routers or else Router Clients. document are either AODVv2 Routers or else Router Clients.
Originating Node (OrigNode) Originating Node (OrigNode)
The Originating Node is the node that launched the application The Originating Node is the node that launched the application
requiring communication with the Target Node. If OrigNode is not requiring communication with the Target Node. If OrigNode is not
itself an AODVv2 router, its AODVv2 router (OrigRtr) has the itself an AODVv2 router, its AODVv2 router (RREQ_Gen) has the
responsibility to generate a AODVv2 RREQ message on behalf of responsibility to generate a AODVv2 RREQ message on behalf of
OrigNode when necessary to multicast a route discovery message. OrigNode when necessary to discover a route.
Originating Router (OrigRtr)
The Originating Router is the AODVv2 router that serves OrigNode.
OrigRtr generates the RREQ message to discover a route for
TargNode.
reactive reactive
A protocol operation is said to be "reactive" if it is performed A protocol operation is said to be "reactive" if it is performed
only in reaction to specific events. As used in this document, only in reaction to specific events. As used in this document,
"reactive" is essentially synonymous with "on-demand". "reactive" is essentially synonymous with "on-demand".
Routable Unicast IP Address Routable Unicast IP Address
A routable unicast IP address is a unicast IP address that when A routable unicast IP address is a unicast IP address that when
put into the IP.DestinationAddress field is scoped sufficiently to put into the IP.DestinationAddress field is scoped sufficiently to
be forwarded by a router. Globally-scoped unicast IP addresses be forwarded by a router. Globally-scoped unicast IP addresses
skipping to change at page 7, line 12 skipping to change at page 6, line 45
AODVv2 router processing a RREQ receives routing information for AODVv2 router processing a RREQ receives routing information for
the RREQ OrigNode. the RREQ OrigNode.
Router Client Router Client
An AODVv2 router may be configured with a list of other IP An AODVv2 router may be configured with a list of other IP
addresses and networks which correspond to other non-router nodes addresses and networks which correspond to other non-router nodes
which require the services of the AODVv2 router for route which require the services of the AODVv2 router for route
discovery and maintenance. An AODVv2 is always its own client, so discovery and maintenance. An AODVv2 is always its own client, so
that the list of client IP addresses is never empty. that the list of client IP addresses is never empty.
RREP Generating Router (RREP_Gen)
The RREP Generating Router is the AODVv2 router that serves
TargNode. RREP_Gen generates the RREP message to advertise a
route for TargNode.
RREQ Generating Router (RREQ_Gen)
The RREQ Generating Router is the AODVv2 router that serves
OrigNode. RREQ_Gen generates the RREQ message to discover a route
for TargNode.
Sequence Number (SeqNum) Sequence Number (SeqNum)
Same as AODVv2 Sequence Number. AODVv2 mandates that each AODVv2 router maintain an unsigned
integer known as the router's "Sequence Number". This Sequence
Number guarantees the temporal order of routing information to
maintain loop-free routes. This Sequence Number fulfills the same
role as the "Destination Sequence Number" of DSDV, and of AODV
Sequence Number in RFC 3561[RFC3561]. The value zero (0) is
reserved to indicate that the Sequence Number for an address is
unknown.
Target Node (TargNode) Target Node (TargNode)
The Target Node denotes the node for which a route is needed. The Target Node denotes the node for which a route is needed.
Target Router (TargRtr)
The TargetRtr denotes the AODVv2 router which serves TargNode.
Type-Length-Value structure (TLV) Type-Length-Value structure (TLV)
A generic way to represent information as specified in [RFC5444]. A generic way to represent information as specified in [RFC5444].
Unreachable Node (UnreachableNode) Unreachable Node (UnreachableNode)
An UnreachableNode is a node for which a forwarding route is An UnreachableNode is a node for which a forwarding route is
unknown. unknown.
valid route valid route
A route that can be used for forwarding; in other words a route A route that can be used for forwarding; in other words a route
that is not Broken or Expired. that is not Broken or Expired.
3. Notational Conventions 3. Notational Conventions
This document uses the conventions found in Table 1 to describe This document uses the conventions found in Table 1 to describe
information in the fields from [RFC5444]. information in the fields from [RFC5444].
+--------------------+-------------------------------------------+ +---------------------+-----------------------------------------+
| Notation | Information Location and/or Meaning | | Notation | Information Location and/or Meaning |
+--------------------+-------------------------------------------+ +---------------------+-----------------------------------------+
| Route[DestAddr] | A route table entry towards DestAddr | | Route[DestAddr] | A route table entry towards DestAddr |
| Route[Addr]{field} | A field in a route table entry | | Route[Addr].{field} | A field in a route table entry |
| -- | -- | | -- | -- |
| RREQ.{field} | Field in RREQ | | <msg-hop-count> | RFC 5444 Message Header <msg-hop-count> |
| RREP.{field} | Field in RREP | | <msg-hop-limit> | RFC 5444 Message Header <msg-hop-limit> |
| RERR.{field} | Field in RERR | | AddrBlk | an RFC 5444 Address TLV Block |
| -- | -- | | AddrBlk[1] | The first address slot in AddrBlk |
| MsgHdr | the RFC5444 Message Header | | AddrBlk[N] | The Nth address slot in AddrBlk |
| MsgTLV | an RFC5444 Message TLV | | AddrBlk[OrigNode] | AddrBlk[1] |
| MetricTypeTLV | MetricType MsgTLV for Metric AddrTLV | | AddrBlk[TargNode] | AddrBlk[2] |
| MAL | MsgHdr.<msg-addr-length> | | AddrTLV | an RFC 5444 Address Block TLV |
| -- | -- | | AddrTLV[1] | the first item in AddrTLV |
| AddrBlk | an RFC5444 address block | | AddrTLV[N] | the Nth item in AddrTLV |
| AddrBlk[1] | The first address slot in AddrBlk | | AddrTLV[OrigNode] | AddrTLV[1] |
| AddrBlk[N] | The Nth address slot in AddrBlk | | AddrTLV[TargNode] | AddrTLV[2] |
| AddrBlk[OrigNode] | AddrBlk[1] | | MetricTLV | Metric AddrTLV for AddrBlk |
| AddrBlk[TargNode] | AddrBlk[2] | | SeqNumTLV | Sequence Number AddrTLV for AddrBlk |
| AddrTLV | an RFC5444 address block TLV | | -- | -- |
| AddrTLV[1] | the first item in AddrTLV | | OrigNode | Originating Node |
| AddrTLV[N] | the Nth item in AddrTLV | | RREQ_Gen | AODVv2 router originating an RREQ |
| AddrTLV[OrigNode] | AddrTLV[1] | | RREP_Gen | AODVv2 router responding to an RREQ |
| AddrTLV[TargNode] | AddrTLV[2] | | RteMsg | Either RREQ or RREP |
| HopCountTLV | Metric8 AddrTLV when MetricTypeTLV=3 | | RteMsg.{field} | Field in RREQ or RREP |
| Metric8TLV | Metric8 AddrTLV | | HandlingRtr | Handling Router |
| SeqNumTLV | Sequence Number TLV for AddrBlk addresses | | TargNode | Target Node |
| RteAddrBlk | the main address block in a RteMsg | | UnreachableNode | Unreachable Node |
| RteSeqNumTLV | Sequence Numbers for RteAddrBlk addresses | +---------------------+-----------------------------------------+
| UnreachAddrBlk | Unreachable Node AddrBlk in RERR |
| -- | -- |
| OrigRtr | RREQ Originating Router |
| OrigNode | Originating Node |
| RREQ_Gen | AODVv2 router originating an RREQ |
| RREP_Gen | AODVv2 router responding to an RREQ |
| RteMsg | either RREQ or RREP |
| RteMsg_Orig | Originator of a RteMsg |
| HandlingRtr | Handling Router |
| TargRtr | Target Router |
| TargNode | Target Node |
| UnreachableNode | Unreachable Node |
+--------------------+-------------------------------------------+
Table 1 Table 1
4. Applicability Statement 4. Applicability Statement
The AODVv2 routing protocol is designed for stub (i.e., non-transit) The AODVv2 routing protocol is designed for stub (i.e., non-transit)
or disconnected (i.e., from the Internet) mobile ad hoc networks or disconnected (i.e., from the Internet) mobile ad hoc networks
(MANETs). AODVv2 handles a wide variety of mobility patterns by (MANETs). AODVv2 handles a wide variety of mobility patterns by
determining routes on-demand. AODVv2 also handles a wide variety of determining routes on-demand. AODVv2 also handles a wide variety of
traffic patterns. In networks with a large number of routers, AODVv2 traffic patterns. In networks with a large number of routers, AODVv2
is best suited for relatively sparse traffic scenarios where any is best suited for relatively sparse traffic scenarios where any
particular router forwards packets to only a small percentage of the particular router forwards packets to only a small percentage of the
AODVv2 routers in the network, due to the on-demand nature of route AODVv2 routers in the network, due to the on-demand nature of route
discovery and route maintenance. discovery and route maintenance. AODVv2 supports routers with
multiple interfaces, as long as each interface has its own (unicast
routeable) IP address; the set of all network interfaces supporting
AODVv2 is administratively configured in a list (namely,
AODVv2_INTERFACES).
Although AODVv2 is closely related to AODV [RFC3561], and has some of Although AODVv2 is closely related to AODV [RFC3561], and has some of
the features of DSR [RFC4728], AODVv2 is not interoperable with the features of DSR [RFC4728], AODVv2 is not interoperable with
either of those other two protocols. either of those other two protocols.
AODVv2 is applicable to memory constrained devices, since little AODVv2 is applicable to memory constrained devices, since little
routing state is maintained in each AODVv2 router. Only routing routing state is maintained in each AODVv2 router. Only routing
information related to routes between active sources and destinations information related to routes between active sources and destinations
is maintained, in contrast to proactive routing protocols that is maintained, in contrast to proactive routing protocols that
require routing information to all routers within the MANET be require routing information to all routers within the MANET be
maintained. maintained.
AODVv2 supports routers with multiple interfaces, as long as each In addition to routing for their local applications, AODVv2 routers
interface has its own IP address. In addition to routing for their can also route on behalf of other non-routing nodes (i.e., "hosts",
local processes, AODVv2 routers can also route on behalf of other or, in this document, "clients"), reachable via those interfaces.
non-routing nodes (i.e., "hosts", or, in this document, "clients"), Each AODVv2 router, if serving router clients other than itself, is
reachable via those interfaces. Any such node which is not itself an configured with information about the IP addresses of its clients.
AODVv2 router SHOULD NOT be served by more than one AODVv2 router. No AODVv2 router is required to have information about the
relationship between any other AODVv2 router and its router clients.
The coordination among multiple AODVv2 routers to distribute routing
information correctly for a shared address (i.e. an address that is
advertised and can be reached via multiple AODVv2 routers) is not
described in this document. The AODVv2 router operation of shifting
responsibility for a routing client from one AODVv2 router to another
is mentioned in Appendix D. Address assignment procedures are
entirely out of scope for AODVv2. Any such node which is not itself
an AODVv2 router SHOULD NOT be served by more than one AODVv2 router.
Multi-homing is difficult unless the sequence number is expanded to Multi-homing is difficult unless the sequence number is expanded to
include the IP address as well as OwnSeqNum. Otherwise, comparing include the AODVv2 router's IP address as well as SeqNum. Otherwise,
sequence numbers would not work to evaluate freshness. Even when the comparing sequence numbers would not work to evaluate freshness.
IP address is included, there isn't a good way to compare sequence Even when the IP address is included, there isn't a good way to
numbers from different IP addresses, but at least a handling node can compare sequence numbers from different IP addresses, but at least a
determine whether the two given sequence numbers are comparable. If handling node can determine whether the two given sequence numbers
the route table can store multiple routes for the same destination, are comparable. If the route table can store multiple routes for the
then multi-homing can work with sequence numbers augmented by IP same destination, then multi-homing can work with sequence numbers
addresses. augmented by IP addresses.
AODVv2 routers perform route discovery to find a route toward a AODVv2 routers perform route discovery to find a route toward a
particular destination. Therefore, AODVv2 routers MUST must be particular destination. Therefore, AODVv2 routers MUST must be
configured to respond to RREQs for a certain set of addresses. When configured to respond to RREQs for a certain set of addresses. When
AODVv2 is the only protocol interacting with the forwarding table, AODVv2 is the only protocol interacting with the forwarding table,
AODVv2 MAY be configured to perform route discovery for all unknown AODVv2 MAY be configured to perform route discovery for all unknown
unicast destinations. unicast destinations.
At all times within an AODVv2 MANET, only one AODVv2 router SHOULD be
serve any particular routing client. The coordination among multiple
AODVv2 routers to distribute routing information correctly for a
shared address (i.e. an address that is advertised and can be reached
via multiple AODVv2 routers) is not described in this document. The
AODVv2 router operation of shifting responsibility for a routing
client from one AODVv2 router to another is mentioned in Appendix C.
Each AODVv2 router, if serving router clients other than itself, is
configured with information about the IP addresses of its clients.
No AODVv2 router is required to have information about the
relationship between any other AODVv2 router and its router clients.
Address assignment procedures are entirely out of scope for AODVv2.
AODVv2 only utilizes bidirectional links. In the case of possible AODVv2 only utilizes bidirectional links. In the case of possible
unidirectional links, either blacklists (see Section 5.2) or other unidirectional links, either blacklists (see Section 5.2) or other
means (e.g. adjacency establishment with only neighboring routers means (e.g. adjacency establishment with only neighboring routers
that have bidirectional communication as indicated by NHDP [RFC6130]) that have bidirectional communication as indicated by NHDP [RFC6130])
of assuring and monitoring bi-directionality is recommended. of assuring and monitoring bi-directionality is recommended.
Otherwise, persistent packet loss or persistent protocol failures Otherwise, persistent packet loss or persistent protocol failures
could occur. The Cost(L) of bidirectional link L may depend upon the could occur. The Cost(L) of bidirectional link L may depend upon the
direction across the link for which the cost is measured. direction across the link for which the cost is measured.
The routing algorithm in AODVv2 may be operated at layers other than The routing algorithm in AODVv2 may be operated at layers other than
the network layer, using layer-appropriate addresses. The routing the network layer, using layer-appropriate addresses. The routing
algorithm makes of some persistent state; if there is no persistent algorithm makes of some persistent state; if there is no persistent
storage available for this state, recovery can impose a performance storage available for this state, recovery can impose a performance
penalty in case of AODVv2 router reboots. penalty (e.g., in case of AODVv2 router reboots).
5. Data Structures 5. Data Structures
5.1. Route Table Entry 5.1. Route Table Entry
The route table entry is a conceptual data structure. The route table entry is a conceptual data structure.
Implementations may use any internal representation so long as it Implementations may use any internal representation so long as it
provides access to the same information as specified below. provides access to the information specified below.
Conceptually, a route table entry has the following fields: Conceptually, a route table entry has the following fields:
Route.Address Route.Address
The (host or network) destination address of the node(s) The (host or network) destination address of the node(s)
associated with the routing table entry associated with the routing table entry
Route.PfxLen Route.PrefixLength
The value is the length of the netmask/prefix. If the value of The length of the netmask/prefix. If the value of the
the Route.PfxLen is nonzero and different than the length of Route.PrefixLength is not INVALID_PREFIX_LENGTH and is different
addresses in the address family used by the AODVv2 routers, the than the length of addresses in the address family used by the
associated address is a routing prefix, rather than a host AODVv2 routers, the associated address is a routing prefix, rather
address. than a host address.
Route.SeqNum Route.SeqNum
The AODVv2 SeqNum associated with a route table entry The Sequence Number associated with a route table entry
Route.NextHopAddress Route.NextHopAddress
An IP address of the adjacent AODVv2 router on the path toward the An IP address of the adjacent AODVv2 router on the path toward the
Route.Address Route.Address
Route.NextHopInterface Route.NextHopInterface
The interface used to send packets toward the Route.Address The interface used to send packets toward the Route.Address
Route.LastUsed Route.LastUsed
The time that this route was last used The time that this route was last used
skipping to change at page 12, line 17 skipping to change at page 12, line 6
Route.ExpirationTime time of the route table entry, not Route.ExpirationTime time of the route table entry, not
MAX_IDLETIME. Until that time, a Timed route can be used for MAX_IDLETIME. Until that time, a Timed route can be used for
forwarding packets. Afterwards, the route must be Expired (or forwarding packets. Afterwards, the route must be Expired (or
expunged). expunged).
The route's state determines the operations that can be performed on The route's state determines the operations that can be performed on
the route table entry. During use, an Active route is maintained the route table entry. During use, an Active route is maintained
continuously by AODVv2 and is considered to remain active as long as continuously by AODVv2 and is considered to remain active as long as
it is used at least once during every ACTIVE_INTERVAL. When a route it is used at least once during every ACTIVE_INTERVAL. When a route
is no longer Active, it becomes an Idle route. After a route remains is no longer Active, it becomes an Idle route. After a route remains
Idle for MAX_IDLETIME, it becomes an Expired route; after that, the Idle for MAX_IDLETIME, it becomes an Expired route; an Expired route
route is not used for forwarding, but the sequence number information is not used for forwarding, but the sequence number information can
can be maintained until the destination sequence number has had no be maintained until the destination sequence number has had no
updates for MAX_SEQNUM_LIFETIME. After MAX_SEQNUM_LIFETIME, old updates for MAX_SEQNUM_LIFETIME. After MAX_SEQNUM_LIFETIME, old
sequence number information is considered no longer valuable and the sequence number information is considered no longer valuable and the
route is expunged. route is expunged.
MAX_SEQNUM_LIFETIME is the time after a reboot during which an AODVv2 MAX_SEQNUM_LIFETIME is the time after a reboot during which an AODVv2
router MUST NOT transmit any routing messages. Thus, if all other router MUST NOT transmit any routing messages. Thus, if all other
AODVv2 routers expunge routes to the rebooted router after that time AODVv2 routers expunge routes to the rebooted router after that time
interval, the rebooted AODVv2 router's sequence number will not be interval, the rebooted AODVv2 router's sequence number will not be
considered stale by any other AODVv2 router in the MANET. considered stale by any other AODVv2 router in the MANET.
When the link to a route's next hop is broken, the route is marked as When the link to a route's next hop is broken, the route is marked as
being Broken, and the route may no longer be used. being Broken, and the route may no longer be used.
5.2. Bidirectional Connectivity During Route Discovery and Blacklists 5.2. Bidirectional Connectivity and Blacklists
To avoid repeated failure of Route Discovery, an AODVv2 router To avoid repeated failure of Route Discovery, an AODVv2 router
(HandlingRtr) handling a RREP message MAY attempt to verify (HandlingRtr) handling a RREP message MAY attempt to verify
connectivity to the next upstream router towards AODVv2 router connectivity to the next upstream router towards AODVv2 router
originating an RREQ message, by including the Unicast Response originating an RREQ message, by including the Acknowledgement Request
Request message TLV (see Section 15.2) in the RREP. Any unicast (AckReq) message TLV (see Section 15.2) in the RREP. Any unicast
packet will satisfy the Response Request, for example an ICMP REPLY packet will satisfy the Acknowledgement Request, for example an ICMP
message. If the verification fails, HandlingRtr SHOULD put the REPLY message. If the verification is not received within
upstream neighbor in a blacklist. RREQs received from a blacklisted UNICAST_MESSAGE_SENT_TIMEOUT, HandlingRtr SHOULD put the upstream
node SHOULD NOT be retransmitted by HandlingRtr. However, the neighbor in the blacklist. RREQs received from a blacklisted node
upstream neighbor should not be permanently blacklisted; after a SHOULD NOT be retransmitted by HandlingRtr. However, the upstream
certain time (MAX_BLACKLIST_TIME), it should once again be considered neighbor should not be permanently blacklisted; after a certain time
as a viable upstream neighbor for route discovery operations. (MAX_BLACKLIST_TIME), it should once again be considered as a viable
upstream neighbor for route discovery operations.
For this purpose, a list of blacklisted nodes along with their time For this purpose, a list of blacklisted nodes along with their time
of removal should be maintained: of removal should be maintained:
BlacklistNode Blacklist.Node
The IP address of the node that did not verify bidirectional The IP address of the node that did not verify bidirectional
connectivity. connectivity.
BlacklistRmTime Blacklist.RemoveTime
The time at which BlacklistNode will be removed from the The time at which Blacklist.Node will be removed from the
blacklist. blacklist.
5.3. Router Clients and Client Networks 5.3. Router Clients and Client Networks
An AODVv2 router may offer routing services to other nodes that are An AODVv2 router may offer routing services to other nodes that are
not AODVv2 routers. The AODVv2 Sequence Number is (by definition) not AODVv2 routers. AODVv2 defines the Sequence Number to be the
the same for the AODVv2 router and each of its clients. same for the AODVv2 router and each of its clients.
For this purpose, a list of IP addresses nodes along with relevant For this purpose, CLIENT_ADDRESSES must be configured on each AODVv2
prefixes must be configured on each AODVv2: router with the following information:
Client IP address Client IP address
The IP address of the node that requires routing service from the The IP address of the node that requires routing service from the
AODVv2 router. AODVv2 router.
Client Prefix Length Client Prefix Length
The length of the routing prefix associated with the client IP The length of the routing prefix associated with the client IP
address. address.
If the Client Prefix Length is not the full length of the Client IP If the Client Prefix Length is not the full length of the Client IP
skipping to change at page 13, line 43 skipping to change at page 13, line 35
router MUST serve every node that has an address within the range router MUST serve every node that has an address within the range
defined by the routing prefix of the Client Network. The list of defined by the routing prefix of the Client Network. The list of
Routing Clients for an AODVv2 router is never empty, since an AODVv2 Routing Clients for an AODVv2 router is never empty, since an AODVv2
router is always its own client as well. router is always its own client as well.
5.4. AODVv2 Packet Header Fields and Information Elements 5.4. AODVv2 Packet Header Fields and Information Elements
In its default mode of operation, AODVv2 uses the UDP port 269 In its default mode of operation, AODVv2 uses the UDP port 269
[RFC5498] to carry protocol packets. In addition, IP Protocol Number [RFC5498] to carry protocol packets. In addition, IP Protocol Number
138 has been reserved for MANET protocols [RFC5498]. Most AODVv2 138 has been reserved for MANET protocols [RFC5498]. Most AODVv2
messages are sent with the IP destination address set to the link- packets are sent with the IP destination address set to the link-
local multicast address LL-MANET-Routers [RFC5498] unless otherwise local multicast address LL-MANET-Routers [RFC5498] unless otherwise
specified. Therefore, all AODVv2 routers MUST subscribe to LL-MANET- specified. Therefore, all AODVv2 routers MUST subscribe to LL-MANET-
Routers [RFC5498] to receiving AODVv2 messages. In order to reduce Routers [RFC5498] to receiving AODVv2 messages. In order to reduce
multicast overhead, retransmitting multicast packets in MANETs SHOULD multicast overhead, retransmitting multicast packets in MANETs SHOULD
be done according to methods specified in [RFC6621]. AODVv2 does not be done according to methods specified in [RFC6621]. AODVv2 does not
specify which method should be used to restrict the set of AODVv2 specify which method should be used to restrict the set of AODVv2
routers that have the responsibility to retransmit multicast packets. routers that have the responsibility to retransmit multicast packets.
Note that multicast packets MAY be sent via unicast. For example, Note that multicast packets MAY be sent via unicast. For example,
this may occur for certain link-types (non-broadcast media), for this may occur for certain link-types (non-broadcast media), for
manually configured router adjacencies, or in order to improve manually configured router adjacencies, or in order to improve
skipping to change at page 14, line 18 skipping to change at page 14, line 10
messages is set to 255. If a packet is received with a value other messages is set to 255. If a packet is received with a value other
than 255, any AODVv2 message contained in the packet MUST be than 255, any AODVv2 message contained in the packet MUST be
disregarded by AODVv2. This mechanism, known as "The Generalized TTL disregarded by AODVv2. This mechanism, known as "The Generalized TTL
Security Mechanism" (GTSM) [RFC5082] helps to assure that packets Security Mechanism" (GTSM) [RFC5082] helps to assure that packets
have not traversed any intermediate routers. have not traversed any intermediate routers.
IP packets containing AODVv2 protocol messages SHOULD be given IP packets containing AODVv2 protocol messages SHOULD be given
priority queuing and channel access. priority queuing and channel access.
AODVv2 messages are transmitted in packets that conform to the packet AODVv2 messages are transmitted in packets that conform to the packet
and message format described in [RFC5444]. Here is a brief and message format specified in [RFC5444]. Here is a brief summary
description of the format. of the format.
A packet formatted according to RFC5444 contains zero or more A packet formatted according to RFC 5444 contains zero or more
messages. messages.
A message contains a message header, message TLV block, and zero A message contains a message header, message TLV block, and zero
or more address blocks. or more address blocks.
Each address block may also have associated TLV blocks. Each address block may also have an associated TLV block; this TLV
block may encode multiple TLVs. According to RFC 5444, each such
TLV may itself include an array of values.
If a packet contains only a single AODVv2 message and no packet TLVs, If a packet contains only a single AODVv2 message and no packet TLVs,
it need not include a packet-header [RFC5444]. The length of an it need only include a minimal Packet-Header [RFC5444]. The length
address (32 bits for IPv4 and 128 bits for IPv6) inside an AODVv2 of an address (32 bits for IPv4 and 128 bits for IPv6) inside an
message is indicated by the msg-addr-length (MAL) in the msg-header, AODVv2 message is indicated by the msg-addr-length (MAL) in the msg-
as specified in [RFC5444]. header, as specified in [RFC5444].
When multiple messages are aggregated into a single packet according When multiple messages are aggregated into a single packet according
to RFC 5444 formatting, and the aggregation of messages is also to RFC 5444 formatting, and the aggregation of messages is also
authenticated (e.g., with IPsec), it becomes unfeasible to delete authenticated (e.g., with IPsec), and the IP destination is multiple
individual messages. In such cases, instead of deleting individual hops away, it becomes infeasible to delete individual messages. In
messages, they are maintained in the aggregation of messages, but such cases, instead of deleting individual messages, they are
simply ignored for further processing. In such cases where maintained in the aggregation of messages, but simply ignored for
individual messages cannot be deleted, in this document "disregarded" further processing. In such cases where individual messages cannot
means "ignored". Otherwise, any such "disregarded" AODVv2 messages be deleted, in this document "disregarded" means "ignored".
SHOULD be deleted from the aggregated messages in the RFC 5444 Otherwise, any such "disregarded" AODVv2 messages SHOULD be deleted
packet. from the aggregated messages in the RFC 5444 packet.
5.5. AODVv2 Sequence Numbers 5.5. Sequence Numbers
AODVv2 sequence numbers allow AODVv2 routers to evaluate the Sequence Numbers allow AODVv2 routers to evaluate the freshness of
freshness of routing information. Proper maintenance of sequence routing information. Proper maintenance of sequence numbers assures
numbers assures that the destination sequence number value stored by that the destination sequence number value stored by intermediate
intermediate AODVv2 routers is monotonically increasing along any AODVv2 routers is monotonically increasing along any path from any
path from any source to the destination. As a consequence, loop source to the destination. As a consequence, loop freedom is
freedom is assured. assured.
Each AODVv2 router in the network MUST maintain its own sequence Each AODVv2 router in the network MUST maintain its own sequence
number (OwnSeqNum, a 16-bit unsigned integer). An AODVv2 router number An AODVv2 router increments its SeqNum as follows. Most of
increments its OwnSeqNum as follows. Most of the time, OwnSeqNum is the time, SeqNum is incremented by simply adding one (1). But to
incremented by simply adding one (1). But to increment OwnSeqNum increment SeqNum when it has the value of the largest largest
when it has the value of the largest largest possible number possible number representable as a 16-bit unsigned integer (i.e.,
representable as a 16-bit unsigned integer (i.e., 65,535), it MUST be 65,535), it MUST be set to one (1). In other words, the sequence
set to one (1). In other words, the sequence number after 65,535 is number after 65,535 is 1.
1.
An AODVv2 router SHOULD maintain OwnSeqNum in persistent storage. If An AODVv2 router SHOULD maintain its SeqNum in persistent storage.
an AODVv2 router's OwnSeqNum is lost, it MUST take the following If an AODVv2 router's SeqNum is lost, it MUST take the following
actions to avoid the danger of routing loops. First, the AODVv2 actions to avoid the danger of routing loops. First, the AODVv2
router MUST invalidate all route table entries, by setting router MUST invalidate all route table entries, by setting
Route.Broken for each entry. Furthermore the AODVv2 router MUST wait Route.Broken for each entry. Furthermore the AODVv2 router MUST wait
for at least MAX_SEQNUM_LIFETIME before transmitting or for at least MAX_SEQNUM_LIFETIME before transmitting or
retransmitting any AODVv2 RREQ or RREP messages. If an AODVv2 retransmitting any AODVv2 RREQ or RREP messages. If an AODVv2
protocol message is received during this waiting period, the AODVv2 protocol message is received during this waiting period, the AODVv2
router SHOULD perform normal route table entry updates. If a data router SHOULD perform normal route table entry updates. If a data
packet is received for forwarding to another destination during this packet is received for forwarding to another destination during this
waiting period, the AODVv2 router MUST transmit a RERR message waiting period, the AODVv2 router MUST transmit a RERR message
indicating that no route is available. At the end of the waiting indicating that no route is available. At the end of the waiting
period the AODVv2 router sets its OwnSeqNum to one (1) and begins period the AODVv2 router sets its SeqNum to one (1) and begins
performing AODVv2 protocol functions again. performing AODVv2 protocol functions again.
5.6. Enabling Alternate Metrics 5.6. Enabling Alternate Metrics
Route selection in AODVv2 MANETs depends upon associating metric AODVv2 route selection in MANETs depends upon associating metric
information with each route table entry. When presented with information with each route table entry. When presented with
candidate route update information, deciding whether to use the candidate route update information, deciding whether to use the
update involves evaluating the metric. Some applications may require update involves evaluating the metric. Some applications may require
the consideration of metric information other than Hop Count, which metric information other than Hop Count, which has traditionally been
has traditionally been the default metric associated with routes in the default metric associated with routes in MANET. Unfortunately,
MANET. In fact, it is well known that reliance on Hop Count can it is well known that reliance on Hop Count can cause selection of
cause selection of the worst possible route in many situations. the worst possible route in many situations.
It is beyond the scope of this document to describe how applications It is beyond the scope of this document to describe how applications
specify route selection at the time they launch processing. One specify route selection at the time they launch processing. One
possibility would be to provide a route metric preference as part of possibility would be to provide a route metric preference as part of
the library routines for opening sockets. In view of the above the library routines for opening sockets. In view of the above
considerations, it is important to enable route selection based on considerations, it is important to enable route selection based on
metric information other than Hop Count -- in other words, based on metric information other than Hop Count -- in other words, based on
"alternate metrics". Each such alternate metric identifies a "cost" "alternate metrics". Each such alternate metric measures a "cost" of
of using the associated route, and there are many different kinds of using the associated route, and there are many different kinds of
cost (latency, delay, financial, energy, etc.). cost (latency, delay, monetary, energy, etc.).
The most significant change when enabling use of alternate metrics is The most significant change when enabling use of alternate metrics is
to require the possibility of multiple routes to the same to require the possibility of multiple routes to the same
destination, where the "cost" of each of the multiple routes is destination, where the "cost" of each of the multiple routes is
measured by a different alternate metric. The other change relevant measured by a different metric. Moreover, the method by which route
to AODVv2 is that the method by which route updates are tested for updates are tested for usefulness has to be slightly generalized to
usefulness has to be slightly generalized to depend upon a more depend upon a more abstract method of evaluation which, in this
abstract method of evaluation which, in this document, is named document, is named "Cost(R)", where 'R' is the route for which the
"Cost(R)", where 'R' is the route information to be evaluated. From Cost to be evaluated. From the above, the route table information
the above, the route table information for 'R' must always include for 'R' must always include the type of metric by which Cost(R) is
the type of metric by which Cost(R) is evaluated, so the metric type evaluated, so the metric type does not have to be shown as a distinct
does not have to be shown as a distinct parameter for Cost(R). Since parameter for Cost(R). Since determining loop freedom is known to
determining loop freedom is known to depend on comparing the Cost(R) depend on comparing the Cost(R) of route update information to the
of route update information to the Cost(R) of an existing stored Cost(R) of an existing stored route using the same metric, AODVv2
route using the same metric, AODVv2 must also be able to invoke an must also be able to invoke an abstract routine which in this
abstract routine which in this document is called "LoopFree(R1, R2)". document is called "LoopFree(R1, R2)". LoopFree(R1, R2) returns TRUE
LoopFree(R1, R2) returns TRUE when, given that R2 is loop-free and when, (under the assumption of nondecreasing SeqNum during Route
Cost(R2) is the cost of route R2, Cost(R1) is known to guarantee loop Discovery) given that R2 is loop-free and Cost(R2) is the cost of
freedom of the route R1. In this document, LoopFree(R1,R2) will only route R2, Cost(R1) is known to guarantee loop freedom of the route
be invoked for routes R1 and R2 which use the same metric. R1. In this document, LoopFree(R1,R2) will only be invoked for
routes R1 and R2 which use the same metric.
Generally, HopCount may still be considered the default metric for Generally, HopCount may still be considered the default metric for
use in MANETs, notwithstanding the above objections. Each metric has use in MANETs, notwithstanding the above objections. Each metric has
to have a Metric Type, and the Metric Type is allocated by IANA as to have a Metric Type, and the Metric Type is allocated by IANA as
specified in [RFC6551]. Each Route has to include the Metric Type as specified in [RFC6551]. Each Route has to include the Metric Type as
part of the route table entry for that route. Hop Count has Metric part of the route table entry for that route. Hop Count has Metric
Type assignment 3. The Cost of a route using Metric Type 3 is Type assignment 3. The Cost of a route using Metric Type 3 is simply
naturally the Hop Count between the router and the destination. For the hop count between the router and the destination. For routes R1
routes R1 and R2 using Metric Type 3, LoopFree (R1, R2) is TRUE when and R2 using Metric Type 3, LoopFree (R1, R2) is TRUE when Cost(R2)
Cost(R2) <= (Cost(R1) + 1). The specification of Cost(R) and <= (Cost(R1) + 1). The specification of Cost(R) and LoopFree(R1,R2)
LoopFree(R1,R2) for metric types other than 3 is beyond the scope of for metric types other than 3 is beyond the scope of this document.
this document.
Whenever an AODV router receives metric information in an incoming Whenever an AODV router receives metric information in an incoming
message, the value of the metric is as measured by the transmitting message, the value of the metric is as measured by the transmitting
router, and does not reflect the cost of traversing the incoming router, and does not reflect the cost of traversing the incoming
link. In order to simplify the description of storing accrued route link. In order to simplify the description of storing accrued route
costs in the route table, the Cost() function is also defined to costs in the route table, the Cost() function is also defined to
return the value of traversing a link 'L'. In other words, the return the value of traversing a link 'L'. In other words, the
domain of the Cost() function is enlarged to include links as well as domain of the Cost() function is enlarged to include links as well as
routes. For Metric Type 3, (i.e., the HopCount metric) Cost(L) = 1 routes. For Metric Type 3, (i.e., the HopCount metric) Cost(L) = 1
for all links. The specification of Cost(L) for metric types other for all links. The specification of Cost(L) for metric types other
skipping to change at page 17, line 9 skipping to change at page 16, line 49
the Cost() function is a link or a route will, in this document, the Cost() function is a link or a route will, in this document,
always be clear. As a natural result of the way routes are looked up always be clear. As a natural result of the way routes are looked up
according to conformant metric type, all intermediate routers according to conformant metric type, all intermediate routers
handling a RteMsg will assign the same metric type to all metric handling a RteMsg will assign the same metric type to all metric
information in the RteMsg. information in the RteMsg.
For some metrics, a maximum value is defined, namely MAX_METRIC[i] For some metrics, a maximum value is defined, namely MAX_METRIC[i]
where 'i' is the Metric Type. AODVv2 does not store routes that cost where 'i' is the Metric Type. AODVv2 does not store routes that cost
more than MAX_METRIC[i]. MAX_METRIC[3] is defined to be more than MAX_METRIC[i]. MAX_METRIC[3] is defined to be
MAX_HOPCOUNT, where as before 3 is the Metric Type of the HopCount MAX_HOPCOUNT, where as before 3 is the Metric Type of the HopCount
metric. metric. MAX_HOPCOUNT MUST be larger than the AODVv2 network
diameter. Otherwise, AODVv2 protocol messages may not reach their
intended destinations.
5.7. RREQ Table: Received RREQ
Two incoming RREQ messages are considered to be "comparable" if they
were generated by the same AODVv2 router in order to discover a route
for the same destination with the same metric type. Using that
notion of comparability, when RREQ messages are flooded in a MANET,
an AODVv2 router may well receive comparable RREQ messages from more
than one of its neighbors. A router, after receiving an RREQ
message, MUST check against previous RREQs to assure that its
response message would contain useful information. Otherwise,
multicast RREQs are likely to be retransmitted over and over again
with zero additional benefit but generating a great deal of
unnecessary signaling traffic and interference.
When optional multicast RREP (see Section 13.4) is used to enable
selection from among multiple possible return routes, an AODVv2
router can eliminate useless RREP messages using the analogous
mechanism along with a RREP Table. Nevertheless, the description in
this section only refers to RREQ multicast messages.
To avoid transmission of useless RREQ messages, while still enabling
the proper handling of earlier RREQ messages that may have somehow
been delayed in the network, it is needed for each AODVv2 router to
keep a list of the certain information about RREQ messages which it
has recently received.
This list is called the AODVv2 Received RREQ Table -- or, more
briefly, the RREQ Table. Two AODVv2 RREQ messages are comparable if:
o they have the same metric type
o they have the same OrigNode and TargNode addresses
The RREQ Table is maintained so that no two entries in the RREQ Table
are comparable -- that is, all RREQs represented in the RREQ Table
either have different OrigNode addresses, different TargNode
addresses, different metric types, or different message types. If
two RREQs have the same metric type and OrigNode and Targnode
addresses, the information from the one with the older Sequence
Number is not needed in the table; in case they have the same
Sequence Number, the one with the greater Metric value is not needed;
in case they have the same Metric as well, it does not matter which
table entry is maintained. Whenever a RREQ Table entry is updated,
its Timestamp field should also be updated to reflect the
Current_Time.
Each entry in the RREQ Table has the following fields:
o Metric Type
o OrigNode address
o TargNode address
o Sequence Number
o Metric
o Timestamp
Protocol handling of RERR messages eliminates the need for tracking
RERR messages, since the rules for RERR regeneration prevent the
phenomenon of useless retansmission that affects RREQ and RREP
multicast.
6. AODVv2 Operations on Route Table Entries 6. AODVv2 Operations on Route Table Entries
In this section, operations are specified for updating the route In this section, operations are specified for updating the route
table due to timeouts and route updates within AODVv2 messages. The table due to timeouts and route updates within AODVv2 messages.
route update information in AODVv2 messages includes the destination Route update information in AODVv2 messages includes a destination IP
IP address (DestIP), SeqNum and prefix length associated with DestIP, address (DestIP), SeqNum and prefix length associated with DestIP,
and the Metric from DestIP to the node transmitting the AODVv2 and the Metric from the node transmitting the AODVv2 message to
message. DestIP information and prefix length are encoded within an DestIP. DestIP and prefix length are encoded within an RFC 5444
RFC 5444 Address Block, and the SeqNum and Metric associated with Address Block, and the SeqNum and Metric associated with each DestIP
each DestIP are encoded in RFC 5444 AddrTLVs. Optionally, there may are encoded in RFC 5444 AddrTLVs. Optionally, there may be AddedNode
be AddedNode route updates included in AODVv2 messages, as specified route updates included in AODVv2 messages, as specified in
in Section 13.7. In this section, RteMsg is either RREQ or RREP, Section 13.7. In this section, RteMsg is either RREQ or RREP,
RteMsg.Addr denotes the [i]th address in an RFC 5444 AddrBlk of the RteMsg.Addr denotes the [i]th address in an RFC 5444 AddrBlk of the
RteMsg, RteMsg.PfxLen denotes the associated prefix length for RteMsg, RteMsg.PrefixLength denotes the associated prefix length for
RteMsg.Addr, and RteMsg.{field} denotes the corresponding value in RteMsg.Addr, and RteMsg.{field} denotes the corresponding value in
the named AddrTLV block associated with RteMsg.Addr. All SeqNum the named AddrTLV block associated with RteMsg.Addr. All SeqNum
comparisons use signed 16-bit arithmetic. comparisons use signed 16-bit arithmetic.
6.1. Evaluating Incoming Routing Information 6.1. Evaluating Incoming Routing Information
If the incoming RteMsg does not have a MetricTypeTLV, then the metric If the incoming RteMsg does not have a MetricType Message TLV, then
information contained by RteMsg is considered to be of type the metric information contained by RteMsg is considered to be of
DEFAULT_METRIC_TYPE. Whenever an AODVv2 router (HandRtr) handles an type DEFAULT_METRIC_TYPE -- by default, 3 (for HopCount). Whenever
incoming RteMsg (i.e., RREQ or RREP), for every relevant address an AODVv2 router (HandlingRtr) handles an incoming RteMsg (i.e., RREQ
(RteMsg.Addr) in the RteMsg, HandRtr searches its route table to see or RREP), for every relevant address (RteMsg.Addr) in the RteMsg,
if there is a route table entry with the same MetricType of the HandlingRtr searches its route table to see if there is a route table
RteMsg, matching RteMsg.Addr. If not, HandRtr creates a route table entry with the same MetricType of the RteMsg, matching RteMsg.Addr.
entry for RteMsg.Addr as described in Section 6.2. Otherwise, If not, HandlingRtr creates a route table entry for RteMsg.Addr as
HandRtr compares the incoming routing information in RteMsg against described in Section 6.2. Otherwise, HandlingRtr compares the
the already stored routing information in the route table entry incoming routing information in RteMsg against the already stored
(Route) for RteMsg.Addr, as described below. routing information in the route table entry (Route) for RteMsg.Addr,
as described below.
Suppose a route table entry (Route[RteMsg.Addr]) uses the same metric Suppose Route[RteMsg.Addr] uses the same metric type as the incoming
type as the incoming routing information, and contains Route.SeqNum, routing information, and contains Route.SeqNum, Route.Metric, and
Route.Metric, and Route.Broken. Suppose the incoming routing Route.Broken. Suppose the incoming routing information for
information for Route.Addr is RteMsg.SeqNum and RteMsg.Metric. The Route.Addr is RteMsg.SeqNum and RteMsg.Metric. Define RteMsg.Cost to
be (RteMsg.Metric + Cost(L)), where L is the incoming link. The
incoming routing information is compared as follows: incoming routing information is compared as follows:
1. Stale:: RteMsg.SeqNum < Route.SeqNum : 1. Stale:: RteMsg.SeqNum < Route.SeqNum :
If RteMsg.SeqNum < Route.SeqNum the incoming information is stale. If RteMsg.SeqNum < Route.SeqNum the incoming information is stale.
Using stale routing information is not allowed, since that might Using stale routing information is not allowed, since that might
result in routing loops. HandRtr MUST disregard the routing result in routing loops. HandlingRtr MUST NOT update the route
information for RteMsg.Addr. table entry using the routing information for RteMsg.Addr.
2. Unsafe against loops:: (TRUE != LoopFree (RteMsg, Route)) : 2. Unsafe against loops:: (TRUE != LoopFree (RteMsg, Route)) :
If RteMsg is not Stale (as in (1)), RteMsg.Metric is next If RteMsg is not Stale (as in (1) above), RteMsg.Cost is next
considered to insure loop freedom. If (TRUE != LoopFree (RteMsg, considered to insure loop freedom. If (TRUE != LoopFree (RteMsg,
Route)) (see Section 5.6), then the incoming RteMsg information is Route)) (see Section 5.6), then the incoming RteMsg information is
not guaranteed to prevent routing loops, and it MUST NOT be used. not guaranteed to prevent routing loops, and it MUST NOT be used
to update any route table entry.
3. Longer:: 3. Longer::
(RteMsg.Metric >= Route.Metric) && (Route.Broken==FALSE) (RteMsg.Cost >= Route.Metric) && (Route.Broken==FALSE)
When RteMsg.SeqNum is the same as in a valid route table entry, When RteMsg.SeqNum is the same as in a valid route table entry,
and LoopFree (RteMsg, Route) assures loop freedom, incoming and LoopFree (RteMsg, Route) assures loop freedom, incoming
information still does not offer any improvement over the existing information still does not offer any improvement over the existing
route table information if RteMsg.Metric >= Route.Metric. Using route table information if RteMsg.Cost >= Route.Metric. Using
such incoming routing information to update a route table entry is such incoming routing information to update a route table entry is
not recommended. not recommended.
4. Offers improvement:: 4. Offers improvement::
Incoming routing information that does not match any of the above Incoming routing information that does not match any of the above
criteria is better than existing routing table information and criteria is better than existing routing table information and
SHOULD be used to improve the route table. The following pseudo- SHOULD be used to improve the route table. The following pseudo-
code illustrates whether incoming routing information should be code illustrates whether incoming routing information should be
used to update an existing route table entry as described in used to update an existing route table entry as described in
Section 6.2. Section 6.2.
(RteMsg.SeqNum > Route.SeqNum) OR (RteMsg.SeqNum > Route.SeqNum) OR
{(RteMsg.SeqNum == Route.SeqNum) AND {(RteMsg.SeqNum == Route.SeqNum) AND
[(RteMsg.Metric < Route.Metric) OR [(RteMsg.Cost < Route.Metric) OR
((Route.Broken == TRUE) && LoopFree (RteMsg, Route))]} ((Route.Broken == TRUE) && LoopFree (RteMsg, Route))]}
The above logic corresponds to placing the following conditions on The above logic corresponds to placing the following conditions on
the incoming route update (compared to the existing route table the incoming route update (compared to the existing route table
entry) before it can be used: entry) before it can be used:
* it is more recent, or * it is more recent, or
* it is not stale and is shorter, or * it is not stale and is shorter, or
* it can safely repair a broken route. * it can safely repair a broken route.
6.2. Applying Route Updates To Route Table Entries 6.2. Applying Route Updates To Route Table Entries
To apply the route update, the route table entry is populated with To apply the route update, the route table entry is populated with
the following information: the following information:
o Route.Address := RteMsg.Addr o Route.Address := RteMsg.Addr
o If (RteMsg.PfxLen != 0), then Route.PfxLen := RteMsg.PfxLen o If RteMsg.PrefixLength exists and is not INVALID_PREFIX_LENGTH,
then Route.PrefixLength := RteMsg.PrefixLength
o Route.SeqNum := RteMsg.SeqNum o Route.SeqNum := RteMsg.SeqNum
o Route.NextHopAddress := IP.SourceAddress (i.e., an address of the o Route.NextHopAddress := IP.SourceAddress (i.e., an address of the
node from which the RteMsg was received) node from which the RteMsg was received)
o Route.NextHopInterface is set to the interface on which RteMsg was o Route.NextHopInterface is set to the interface on which RteMsg was
received received
o Route.Broken flag := FALSE o Route.Broken flag := FALSE
o If RteMsg.MetricType is included, then o If RteMsg.MetricType is included, then
Route.MetricType := RteMsg.MetricType. Otherwise, Route.MetricType := RteMsg.MetricType. Otherwise,
Route.MetricType := DEFAULT_METRIC_TYPE. Route.MetricType := DEFAULT_METRIC_TYPE.
o Route.MetricType := RteMsg.MetricType o Route.Metric := (RteMsg.Metric + Cost(L)), where L is the incoming
link.
o Route.Metric := RteMsg.Metric
o Route.LastUsed := Current_Time o Route.LastUsed := Current_Time
o If RteMsg.VALIDITY_TIME is not included, then o If RteMsg.VALIDITY_TIME is included, then
Route.ExpirationTime := MAXTIME, otherwise Route.ExpirationTime := Route.ExpirationTime := Current_Time + RteMsg.VALIDITY_TIME,
Current_Time + RteMsg.VALIDITY_TIME otherwise, Route.ExpirationTime := Current_Time + (ACTIVE_INTERVAL
+ MAX_IDLETIME).
With these assignments to the route table entry, a route has been With these assignments to the route table entry, a route has been
made available, and the route can be used to send any buffered data made available, and the route can be used to send any buffered data
packets and subsequently to forward any incoming data packets for packets and subsequently to forward any incoming data packets for
Route.Addr. An updated route entry also fulfills any outstanding Route.Addr. An updated route entry also fulfills any outstanding
route discovery (RREQ) attempts for Route.Addr. route discovery (RREQ) attempts for Route.Addr.
6.3. Route Table Entry Timeouts 6.3. Route Table Entry Timeouts
During normal operation, AODVv2 does not require any explicit During normal operation, AODVv2 does not require any explicit
skipping to change at page 20, line 39 skipping to change at page 21, line 48
The constructed route is bidirectional, enabling packets to flow The constructed route is bidirectional, enabling packets to flow
between OrigNode and TargNode. RREQ and RREP have similar between OrigNode and TargNode. RREQ and RREP have similar
information and function, but have some differences in their rules information and function, but have some differences in their rules
for handling. The main difference between the two messages is that for handling. The main difference between the two messages is that
RREQ messages are typically multicast to solicit a RREP, whereas RREP RREQ messages are typically multicast to solicit a RREP, whereas RREP
is typically unicast as a response to RREQ. is typically unicast as a response to RREQ.
When an AODVv2 router needs to forward a data packet from a node When an AODVv2 router needs to forward a data packet from a node
(OrigNode) in its set of router clients, and it does not have a (OrigNode) in its set of router clients, and it does not have a
forwarding route toward the packet's IP destination address forwarding route toward the packet's IP destination address
(TargNode), the AODVv2 router (in this section, called RREQ_Gen) (TargNode), the AODVv2 router (RREQ_Gen) generates a RREQ (as
generates a RREQ (as described in Section 7.3) to discover a route described in Section 7.3) to discover a route toward TargNode.
toward TargNode. Subsequently RREQ_Gen awaits reception of an RREP Subsequently RREQ_Gen awaits reception of an RREP message (see
message (see Section 7.4) or other route table update (see Section 7.4) or other route table update (see Section 6.2) to
Section 6.2) to establish a route toward TargNode. The RREQ message establish a route toward TargNode. The RREQ message contains routing
contains routing information to enable RREQ recipients to route information to enable RREQ recipients to route packets back to
packets back to OrigNode, and the RREP message contains routing OrigNode, and the RREP message contains routing information enabling
information enabling RREP recipients to route packets to TargNode. RREP recipients to route packets to TargNode.
7.1. Route Discovery Retries and Buffering 7.1. Route Discovery Retries and Buffering
After issuing a RREQ, as described above RREQ_Gen awaits a RREP After issuing a RREQ, as described above RREQ_Gen awaits a RREP
providing a bidirectional route toward Target Node. If the RREP is providing a bidirectional route toward Target Node. If the RREP is
not received within RREQ_WAIT_TIME, RREQ_Gen may retry the Route not received within RREQ_WAIT_TIME, RREQ_Gen may retry the Route
Discovery by generating another RREQ. Route Discovery SHOULD be Discovery by generating another RREQ. Route Discovery SHOULD be
considered to have failed after DISCOVERY_ATTEMPTS_MAX and the considered to have failed after DISCOVERY_ATTEMPTS_MAX and the
corresponding wait time for a RREP response to the final RREQ. After corresponding wait time for a RREP response to the final RREQ. After
the attempted Route Discovery has failed, RREQ_Gen MUST wait at least the attempted Route Discovery has failed, RREQ_Gen MUST wait at least
skipping to change at page 22, line 6 skipping to change at page 23, line 6
of the data packet. The code for the ICMP message is 1 (Host of the data packet. The code for the ICMP message is 1 (Host
unreachable error). If RREQ_Gen is not the source (OrigNode), then unreachable error). If RREQ_Gen is not the source (OrigNode), then
the ICMP is sent over the interface from which OrigNode sent the the ICMP is sent over the interface from which OrigNode sent the
packet to the AODVv2 router. packet to the AODVv2 router.
7.2. RteMsg Structure 7.2. RteMsg Structure
RteMsgs have the following general format: RteMsgs have the following general format:
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| RFC 5444 Packet Header | | RFC 5444 Message Header (optionally, with MsgTLVs) |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| RFC 5444 Message Header <msg-hopcount> | | AddrBlk[1,2]:= [OrigNode,TargNode] |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| RFC 5444 MsgHdr, opt. DestOnly TLV, opt. MetricTypeTLV | | AddrBlk.PrefixLength[OrigNode OR TargNode] (Optional) |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| RteAddrBlk {[1]:=RREQ.OrigNode,[2]:=RREQ.TargNode)} | | SeqNumTLV [OrigNode AND/OR TargNode] |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| RteSeqNumTLV (OrigRtr.Seqnum, TargNode.Seqnum) | | MetricTLV [OrigNode, TargNode] (Optional) |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Added Node Address Block (Optional) | | Added Node Address Block (Optional) |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Added Node Address TLV (SeqNum) | | Added Node Address SeqNumTLV |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Added Node Address TLV (Metric[MetricType]) | | Added Node Address MetricTLV[MetricType] |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 1: RREQ and RREP (RteMsg) message structure Figure 1: RREQ and RREP (RteMsg) message structure
Message Header Required Message Header Fields
This is typically mostly boilerplate but can contain MsgTLVs as The RteMsg MUST contain the following:
below.
DestOnly TLV * <msg-hop-limit>
RREQ only: no Intermediate RREP.
MetricType TLV * Metric Type Message TLV, if MetricType != 3
Metric Type for Metric AddrTLV
RteAddrBlk Optional Message Header Fields
The RteMsg may contain the following:
* <msg-hop-count>
* DestOnly TLV (RREQ only: no Intermediate RREP)
* MetricType TLV (Metric Type for Metric AddrTLV)
* AckReq TLV (Acknowledgement Requested)
AddrBlk
This Address Block contains the IP addresses for RREQ Originating This Address Block contains the IP addresses for RREQ Originating
and Target Node (OrigNode and TargNode). Note that for both RREP and Target Node (OrigNode and TargNode). For both RREP and RREQ,
and RREQ, the OrigNode and TargNode are as identified in the OrigNode and TargNode are as identified in the context of the RREQ
context of the RREQ message originator. message originator.
RteSeqNumTLV (Sequence Number AddrTLV) SeqNumTLV (Sequence Number AddrTLV)
This Address Block TLV is REQUIRED and carries the destination This Address Block TLV is REQUIRED and carries the destination
sequence numbers associated with either OrigNode or TargNode or sequence numbers associated with either OrigNode or TargNode or
both. both.
(Optional) Added Node AddrBlk (Optional) Added Node AddrBlk
AODVv2 allows the inclusion of routing information for other nodes AODVv2 allows the inclusion of routing information for other nodes
in addition to OrigNode and TargNode. in addition to OrigNode and TargNode.
(Optional) SeqNum AddrTLV If the Added Node AddrBlk is present, the (Optional) SeqNum AddrTLV If the Added Node AddrBlk is present, the
SeqNum AddrTLV is REQUIRED, to carry the destination sequence SeqNum AddrTLV is REQUIRED, to carry the destination sequence
numbers associated with the Added Nodes. numbers associated with the Added Nodes.
(Optional) Metric AddrTLV If the Added Node AddrBlk is present, this (Optional) Metric AddrTLV If the Added Node AddrBlk is present, this
AddrTLV is REQUIRED, to carry the metric information associated AddrTLV is REQUIRED, to carry the metric information associated
with the Added Nodes. See Below. with the Added Nodes. See Below.
The metric AddrTLV may be either a Metric8 AddrTLV or an Metric16
AddrTLV.
7.3. RREQ Generation 7.3. RREQ Generation
RREQ_Gen generates the RREQ according to the following steps, with The AODVv2 router generating the RREQ (RREQ_Gen) on behalf of its
order of protocol elements illustrated schematically in Figure 1. client OrigNode follows the steps in this section. OrigNode MUST be
a unicast address. The order of protocol elements is illustrated
schematically in Figure 1.
1. RREQ_Gen MUST increment its OwnSeqNum by one (1) according to the 1. RREQ_Gen MUST increment its SeqNum by one (1) according to the
rules specified in Section 5.5. This assures that all nodes with rules specified in Section 5.5. This assures that each node
existing routing information will use RREQ_Gen's new information receiving the RREQ will update its route table using the
to update existing routing table information. information in the RREQ.
2. OrigNode MUST be a unicast address. If RREQ_Gen is not OrigNode, 2. If RREQ_Gen requires that only the router providing connectivity
then OwnSeqNum will be used as the value of OrigNode.SeqNum. will to TargNode is allowed to generate a RREP, then RREQ_Gen
be used by AODVv2 routers to create a route toward the OrigNode, includes the "Destination RREP Only" (DestOnly) TLV as part of
enabling a RREP from TargRtr, and eventually used for proper the RFC 5444 message header. This also assures that RREP_Gen
forwarding of data packets. increments its sequence number. Otherwise, (if the optional
behavior is enabled) other AODVv2 routers MAY respond to the
RREQ if they have an valid route to TargNode (see Section 13.2).
3. If RREQ_Gen requires that only TargRtr is allowed to generate a 3. <msg-hop-limit> SHOULD be set to MAX_HOPCOUNT.
RREP, then RREQ_Gen includes the "Destination RREP Only" TLV as
part of the RFC 5444 message header. This also assures that
TargRtr increments its sequence number. Otherwise, intermediate
AODVv2 routers MAY respond to the RREQ_Gen's RREQ if they have an
valid route to TargNode (see Section 13.2).
4. msg-hopcount MUST be set to 0. 4. <msg-hop-count>, if included, MUST be set to 0.
* This RFC 5444 constraint causes the typical RteMsg payload * This RFC 5444 constraint causes the typical RREQ payload to
incur additional enlargement. incur additional enlargement (otherwise, <msg-hop-count>
could often be used as the metric).
5. RREQ_Gen adds the TargNode.Addr to the RREQ. 5. RREQ.AddrBlk[1] := OrigNode.Addr
6. If a previous value of the TargNode's SeqNum is known (e.g., from 6. RREQ.AddrBlk[2] := TargNode.Addr
an invalid routing table entry using longest-prefix matching),
RREQ_Gen SHOULD include TargNode.SeqNum in all but the last RREQ
attempt. If TargNode.SeqNum is not included, it is assumed to be
unknown by AODVv2 routers handling the RREQ; if the optional
feature Intermediate RREP is enabled, then any route to TargNode
will satisfy the RREQ [I-D.perkins-irrep].
7. RREQ_Gen adds OrigNode.Addr, its prefix, and the RREQ_Gen.SeqNum 7. If Route[OrigNode].PrefixLength/8 is equal to the number of
(OwnSeqNum) to the RREQ. bytes in the addresses of the RREQ (4 for IPv4, 16 for IPv6),
then no <prefix-length> is included with the RREQ.AddrBlk.
Otherwise, RREQ.PrefixLength[OrigNode] :=
Route[OrigNode].PrefixLength according to the rules of RFC 5444
AddrBlk encoding.
8. If OrigNode.Metric is included it is set to the cost of the route 8. RREQ.AddrTLV.SeqNum[1] := RREQ_Gen SeqNum
between OrigNode and RREQ_Gen.
9. RREQ.AddrTLV.SeqNum[2] := TargNode SeqNum (only if known)
If a previous value of the TargNode's SeqNum is known (e.g.,
from an invalid routing table entry using longest-prefix
matching), RREQ_Gen SHOULD include TargNode's SeqNum. If
TargNode's SeqNum is not included, AODVv2 routers handling the
RREQ assumed that RREQ_Gen does not have that information. If
ENABLE_IRREP is enabled, then any route to TargNode will satisfy
the RREQ [I-D.perkins-irrep].
10. RREQ.MetricTLV[1] := Route[OrigNode].Metric
An example RREQ message format is illustrated in Appendix A.1. An example RREQ message format is illustrated in Appendix A.1.
7.4. RREP Generation 7.4. RREP Generation
An AODVv2 router (TargRtr, called in this section RREP_Gen) generates This section specifies the generation of an RREP by an AODVv2 router
a RREP in order to provide a route to the Target Node (TargNode) of a (RREP_Gen) that provides connectivity for the Target Node (TargNode)
RREQ, thus satisfying the routing requirement for packets to flow of a RREQ, thus satisfying the routing requirement for packets to
between OrigNode and TargNode. This section specifies the generation flow between OrigNode and TargNode. If TargNode is not a unicast IP
of an RREP by the RREP_Gen. The basic format of an RREP conforms to address the RREP MUST NOT be generated, and processing for the RREQ
the structure for RteMsgs as illustrated in Figure 1. Optionally, is complete. Before transmitting a RREP, the routing information of
RREP messages may be generated by AODVv2 routers other than TargRtr; the RREQ is processed as specified in Section 6.2. The basic format
this optional message generation is known as "Intermediate RREP" of an RREP conforms to the structure for RteMsgs as shown in
generation, and is specified in Internet Draft [I-D.perkins-irrep]. Figure 1.
If TargNode is not a unicast IP address the RREP MUST NOT be
generated, and processing for the RREQ is complete.
Otherwise RREP_Gen generates the RREP as follows: RREP_Gen generates the RREP as follows:
1. RREP_Gen first uses the routing information to update its route 1. RREP_Gen checks the RREQ against recently received RREQ
table entry for OrigNode if necessary as specified in information as specified in Section 7.6. If a previously
Section 6.2. received RREQ has made the information in the incoming RREQ to
be useless, no RREP is generated and processing is complete.
2. RREP_Gen MUST increment its OwnSeqNum by one (1) according to 2. RREP_Gen MUST increment its SeqNum by one (1) according to the
the rules specified in Section 5.5. rules specified in Section 5.5.
3. RREP.AddrBlk[OrigNode] := RREQ.AddrBlk[OrigNode] 3. RREP.AddrBlk[OrigNode] := RREQ.AddrBlk[OrigNode]
4. RREP.AddrBlk[TargNode] := RREQ.AddrBlk[TargNode] 4. RREP.AddrBlk[TargNode] := RREQ.AddrBlk[TargNode]
5. RREP.SeqNumTLV[OrigNode] := RREQ.SeqNumTLV[OrigNode] 5. RREP.SeqNumTLV[OrigNode] := RREQ.SeqNumTLV[OrigNode]
6. RREP.SeqNumTLV[TargNode] := RREP_Gen's SeqNum
6. RREP.SeqNumTLV[TargNode] := OwnSeqNum 7. If Route[TargNode].PrefixLength/8 is equal to the number of
bytes in the addresses of the RREQ (4 for IPv4, 16 for IPv6),
7. If Route[TargNode].PfxLen/8 is equal to the number of bytes in then no <prefix-length> is included with the RREP.AddrBlk.
the addresses of the RREQ (4 for IPv4, 16 for IPv6), then no Otherwise, RREP.PrefixLength[TargNode] :=
<prefix-length> is included with the iRREP. Otherwise, Route[TargNode].PrefixLength according to the rules of RFC 5444
RREP.PfxLen[TargNode] := RREQ.PfxLen[TargNode] according to the AddrBlk encoding.
rules of RFC 5444 AddrBlk encoding.
8. RREP.MetricType[TargNode] := Route[TargNode].MetricType 8. RREP.MetricType[TargNode] := Route[TargNode].MetricType
9. RREP.Metric[TargNode] := Route[TargNode].Metric 9. RREP.Metric[TargNode] := Route[TargNode].Metric
10. <msg-hop-limit> SHOULD be set to RteMsg.<msg-hop-count>. 10. <msg-hop-count>, if included, MUST be set to 0.
11. IP.DestinationAddr := Route[OrigNode].NextHop 11. <msg-hop-limit> SHOULD be set to RREQ.<msg-hop-count>.
The message format for RREP is illustrated in Appendix A.2. 12. IP.DestinationAddr := Route[OrigNode].NextHop
7.5. Handling a Received RteMsg An example message format for RREP is illustrated in Appendix A.2.
Before an AODVv2 router (HandlingRtr) can process a received RteMsg 7.5. Handling a Received RteMsg
(i.e., RREQ or RREP), it first must verify that the RteMsg is
permissible according to the following steps. For RREQ, RteMsg_Gen
is OrigRtr, also called RREQ_Gen. For RREP, RteMsg_Gen is TargRtr,
also called RREP_Gen.
1. HandlingRtr MUST handle AODVv2 messages only from adjacent Before an AODVv2 router (HandlingRtr) can make use of a received
routers as specified in Section 5.4. AODVv2 messages from other RteMsg (i.e., RREQ or RREP), it first must verify that the RteMsg is
sources MUST be disregarded. permissible according to the following steps. For RREQ,
RteMsg.Metric is MetricTLV[OrigNode]. For RREP, RteMsg.Metric is
MetricTLV[TargNode].
2. If the RteMsg.<msg-hop-limit> is equal to 0, then the message is 1. HandlingRtr MUST handle RteMsgs only from adjacent routers as
specified in Section 5.4. RteMsgs from other sources MUST be
disregarded. disregarded.
3. If the RteMsg.<msg-hop-count> is present, and RteMsg.<msg-hop- 2. HandlingRtr examines the RteMsg to ascertain that it contains the
count> >= MAX_HOPCOUNT, then the message is disregarded.
4. HandlingRtr examines the RteMsg to ascertain that it contains the
required information: TargNode.Addr, OrigNode.Addr, required information: TargNode.Addr, OrigNode.Addr,
RteMsg_Gen.Metric and RteMsg_Gen.SeqNum. If the required RteMsg.Metric, RteMsg.SeqNum and <msg-hop-limit>. If the
information does not exist, the message is disregarded. required information does not exist, the message is disregarded.
5. HandlingRtr checks that OrigNode.Addr and TargNode.Addr are valid 3. HandlingRtr checks that OrigNode.Addr and TargNode.Addr are valid
routable unicast addresses. If not, the message is disregarded. routable unicast addresses. If not, the message is disregarded.
6. HandlingRtr checks that the Metric Type associated with 4. HandlingRtr checks the Metric Type MsgTLV (if present) to assure
OrigNode.Metric and TargNode.Metric is known, and that Cost(L) that the Metric Type associated with the Metric AddrTLV
can be computed. If not, the message is disregarded. information in the RREQ or RREP is known, and that Cost(L) can be
computed, where 'L' is the incoming link. If not, the message is
disregarded.
* DISCUSSION: alternatively, can change the AddrBlk metric to * DISCUSSION: or, can change the AddrBlk metric to use HopCount,
use HopCount, measured from<msg-hop-limit>. e.g., measured from <msg-hop-count>.
7. If MAX_METRIC[RteMsg.MetricType] <= (RteMsg_Gen.Metric + 5. If (MAX_METRIC[RteMsg.MetricType] - Cost(L)) <= RteMsg.Metric,
Cost(L)), where 'L' is the incoming link, the RteMsg is the RteMsg is disregarded, where Cost(L) denotes the cost of
disregarded. traversing the incoming link (i.e., as measured by the network
interface receiving the incoming RteMsg).
An AODVv2 router (HandlingRtr) handles a permissible RteMsg according An AODVv2 router (HandlingRtr) handles a permissible RteMsg according
to the following steps. to the following steps.
1. HandlingRtr MUST process the routing information contained in the 1. HandlingRtr MUST process the routing information for OrigNode and
RteMsg as speciied in Section 6.1. TargNode contained in the RteMsg as specified in Section 6.1.
2. HandlingRtr MAY process AddedNode routing information (if 2. HandlingRtr MAY process AddedNode routing information (if
present) as specified in Section 13.7.1 Otherwise, if AddedNode present) as specified in Section 13.7.1. Otherwise, if AddedNode
information is not processed, it MUST be deleted. information is not processed, it MUST be deleted.
3. By sending the updated RteMsg, HandlingRtr advertises that it 3. If RteMsg.<msg-hop-limit> is zero (0), no further action is
will route for addresses contained in the outgoing RteMsg based taken. Otherwise, HandlingRtr MUST decrement RteMsg.<msg-hop-
on the information enclosed. HandlingRtr MAY choose not to send limit>.
the RteMsg, though not resending this RteMsg could decrease
connectivity in the network or result in a nonoptimal path. The 4. If the RteMsg.<msg-hop-count> is present, and <msg-hop-count> ==
circumstances under which HandlingRtr might choose to not re- MAX_HOPCOUNT, then no further action is taken. Otherwise,
transmit a RteMsg are not specified in this document. Some HandlingRtr MUST increment RteMsg.<msg-hop-count>
examples might include the following:
5. By sending a RteMsg, HandlingRtr advertises that it will route
for addresses contained in the RteMsg based on the information
enclosed. HandlingRtr MAY choose not to send the RteMsg, though
not resending the RteMsg could decrease connectivity in the
network or result in nonoptimal paths. The circumstances under
which HandlingRtr might choose not to re-transmit a RteMsg are
not specified in this document. Some examples might include the
following:
* HandlingRtr is already heavily loaded and does not want to * HandlingRtr is already heavily loaded and does not want to
advertise routing for the contained addresses advertise routing for more traffic
* HandlingRtr recently transmitted identical routing information * HandlingRtr recently transmitted identical routing information
(e.g. in a RteMsg advertising the same metric) (e.g. in a RteMsg advertising the same metric) Section 7.6
* HandlingRtr is low on energy and has to reduce energy expended * HandlingRtr is low on energy and has to reduce energy expended
for sending protocol messages or packet forwarding for sending protocol messages or packet forwarding
Unless HandlingRtr is prepared to send an updated RteMsg, it Unless HandlingRtr is prepared to send a RteMsg, it halts
halts processing. Otherwise, processing continues as follows. processing. Otherwise, further actions to transmit an updated
RteMsg depend upon whether the incoming RteMsg is an RREP or an
RREQ.
4. HandlingRtr MUST decrement RteMsg.<msg-hop-limit>. If 7.5.1. Additional Handling for Incoming RREQ
RteMsg.<msg-hop-limit> is then zero (0), no further action is
taken.
5. HandlingRtr MUST increment RteMsg.<msg-hop-count>. o If the upstream router is in the Blacklist, and Current_Time <
Blacklist.RemoveTime, then HandlingRtr MUST NOT transmit any
outgoing RteMsg, and processing is complete.
Further actions to send an updated RteMsg depend upon whether the o Otherwise, if the upstream router is in the Blacklist, and
RteMsg is an RREP or an RREQ Current_Time >= Blacklist.RemoveTime, then the upstream router
SHOULD be removed from the Blacklist, and message processing
continued.
7.5.1. Additional Handling for Outgoing RREQ o The incoming RREQ MUST be checked against previously received
information from the RREQ Table Section 7.6. If the information
in the incoming RteMsg is useless, then then no further action is
taken.
o If the upstream router is in the Blacklist, and Current_Time < o If TargNode is a client of HandlingRtr, then HandlingRtr generates
BlacklistRmTime, then HandlingRtr MUST NOT transmit any outgoing a RREP message as specified in Section 7.4, and subsequently
RREQ, and processing is complete. processing for the RREQ is complete. Otherwise, processing
continues as follows.
o Otherwise, if the upstream router is in the Blacklist, and o RREQ.MetricType := Route[OrigNode].MetricType
Current_Time >= BlacklistRmTime, then the upstream router SHOULD
be removed from the Blacklist, and message processing continued.
o If TargNode is a client of HandlingRtr, then a RREP is generated o RREQ.MetricTLV[OrigNode] := Route[OrigNode].Metric
by the HandlingRtr (i.e., TargRtr) and unicast to the upstream
router towards the RREQ OrigNode, as specified in Section 7.4.
Afterwards, TargRtr processing for the RREQ is complete.
o If HandlingRtr is not the TargetNode, then the outgoing RREQ (as o The RREQ (with updated fields as specified above>) SHOULD be sent
altered by the procedure defined above) SHOULD be sent to the IP to the IP multicast address LL-MANET-Routers [RFC5498]. If the
multicast address LL-MANET-Routers [RFC5498]. If the RREQ is RREQ is unicast, the IP.DestinationAddress is set to
unicast, the IP.DestinationAddress is set to the NextHopAddress. Route[RREQ.TargNode].NextHopAddress.
7.5.2. Additional Handling for Outgoing RREP 7.5.2. Additional Handling for Incoming RREP
o If HandlingRtr is not OrigRtr then the outgoing RREP is sent to As before, OrigNode and TargNode are named in the context of the
the Route.NextHopAddress for the RREP.AddrBlk[OrigNode]. If no router (i.e., RREQ_Gen) originating the RREQ for which the RREP was
forwarding route exists to OrigNode, then a RERR SHOULD be generated (see Table 1).
transmitted to RREP.AddrBlk[TargNode]. See Table 1 for notational
conventions; OrigRtr, OrigNode, and TargNode are routers named in o If no forwarding route exists to OrigNode, then a RERR SHOULD be
the context of OrigRtr, that is, the router originating the RREQ transmitted to RREP.AddrBlk[TargNode]. Otherwise, if HandlingRtr
to which the RREP is responding. is not RREQ_Gen then the outgoing RREP is sent to the
Route.NextHopAddress for the RREP.AddrBlk[OrigNode].
o If HandlingRtr is RREQ_Gen then the RREP satisfies RREQ_Gen's
earlier RREQ, and RREP processing is completed. Any packets
buffered for OrigNode should be transmitted.
7.6. Suppressing Useless RteMsgs
Since RREQ messages are multicast, there are common circumstances in
which an AODVv2 router might respond by sending out a RteMsgs (RREQ
or RREQ) that is useless, given the information transmitted after
receiving in some other recent RteMsg (see Section 5.7). Before
transmitting a RteMsg, AODVv2 routers MUST suppress such useless
RteMsgs; this is done by checking the list of recently received
RteMsgs to determine whether the incoming RteMsg contains useful new
information, as follows:
o The AODVv2 router searches the RteMsg Table for recent entries
with the same OrigNode, TargNode, and Metric Type. If there is no
such entry, the incoming RteMsg message is not suppressed. A new
entry for the incoming RteMsg information is created in the RteMsg
Table.
o If there is such an entry, and the incoming RteMsg has a newer
sequence number, the incoming RteMsg is not suppressed, and the
existing table entry MUST be updated to reflect the new Sequence
Number and Metric.
o Similarly, if the Sequence Numbers are the same, and the incoming
RteMsg offers a better Metric, the incoming RteMsg not suppressed,
and the RteMsg Table entry MUST be updated to reflect the new
Metric.
o Otherwise, the incoming RteMsg is suppressed.
8. Route Maintenance 8. Route Maintenance
AODVv2 routers attempt to maintain active routes. When a routing AODVv2 routers attempt to maintain active routes. When a routing
problem is encountered, an AODVv2 router (namely, RERR_Gen) attempts problem is encountered, an AODVv2 router (denoted RERR_Gen) attempts
to quickly notify upstream routers. Two kinds of routing problems to quickly notify upstream routers. Two kinds of routing problems
may trigger generation of a RERR message. The first case happens may trigger generation of a RERR message. The first case happens
when the router receives a packet but does not have a route for the when the router receives a packet but does not have a route for the
destination of the packet. The second case happens immediately upon destination of the packet. The second case happens immediately upon
detection of a broken link (see Section 8.2) of an Active route, to detection of a broken link (see Section 8.2) of an Active route, to
quickly notify AODVv2 routers that that route is no longer available. quickly notify upstream AODVv2 routers that that route is no longer
When the RERR message is generated, it MUST be the only message in available. When the RERR message is generated, it MUST be the only
the RFC 5444 packet. message in the RFC 5444 packet.
8.1. Handling Route Lifetimes During Packet Forwarding 8.1. Maintaining Route Lifetimes During Packet Forwarding
Before using a route to forward a packet, an AODVv2 router MUST check Before using a route to forward a packet, an AODVv2 router MUST check
the status of the route as follows. the status of the route as follows.
If the route is marked has been marked as Broken, it cannot be If the route is marked has been marked as Broken, it cannot be
used for forwarding. used for forwarding.
If Current_Time > Route.ExpirationTime, the route table entry has If Current_Time > Route.ExpirationTime, the route table entry has
expired, and a RERR SHOULD be generated. expired.
Similarly, if (Route.ExpirationTime == MAXTIME), and if Similarly, if (Route.ExpirationTime == MAXTIME), and if
Current_Time - Route.LastUsed > (ACTIVE_INTERVAL+MAX_IDLETIME), (Current_Time - Route.LastUsed) > (ACTIVE_INTERVAL +
the route has expired, and a RERR SHOULD be generated. MAX_IDLETIME), the route has expired.
Furthermore, if Current_Time - Route.LastUsed > Furthermore, if Current_Time - Route.LastUsed >
(MAX_SEQNUM_LIFETIME), the route table entry MUST be expunged. (MAX_SEQNUM_LIFETIME), the route table entry MUST be expunged.
Otherwise, if none of the above route error conditions are indicated, If any of the above route error conditions hold true, the route
Route.LastUsed := Current_Time, and the packet is forwarded to the cannot be used to forward the packet, and an RERR message MUST be
route's next hop. generated (see Section 8.3).
Otherwise, Route.LastUsed := Current_Time, and the packet is
forwarded to the route's next hop.
Optionally, if a precursor list is maintained for the route, see Optionally, if a precursor list is maintained for the route, see
Section 13.3 for precursor lifetime operations. Section 13.3 for precursor lifetime operations.
8.2. Active Next-hop Router Adjacency Monitoring 8.2. Active Next-hop Router Adjacency Monitoring
Nodes SHOULD monitor connectivity to adjacent next-hop AODVv2 routers AODVv2 routers SHOULD monitor connectivity to adjacent routers along
on forwarding routes. This monitoring can be accomplished by one or active routes. This monitoring can be accomplished by one or several
several mechanisms, including: mechanisms, including:
o Neighborhood discovery [RFC6130] o Neighborhood discovery [RFC6130]
o Route timeout o Route timeout
o Lower layer trigger that a neighboring router is no longer o Lower layer trigger that a link is broken
reachable
o TCP timeouts
o Other monitoring mechanisms or heuristics o Other monitoring mechanisms or heuristics
Upon determining that a next-hop AODVv2 router has become If a next-hop AODVv2 router has become unreachable, RERR_Gen follows
unreachable, RERR_Gen follows the procedures specified in the procedures specified in Section 8.3.2.
Section 8.3.2.
8.3. RERR Generation 8.3. RERR Generation
An RERR message is generated by a AODVv2 router (in this section, An RERR message is generated by a AODVv2 router (in this section,
called RERR_Gen) in order to to notify upstream routers that packets called RERR_Gen) in order to notify upstream routers that packets
cannot be delivered to certain destinations. An RERR message has the cannot be delivered to certain destinations. An RERR message has the
following general structure: following general structure:
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| RFC 5444 Packet Header |
+---------------------------------------------------------------+
| RFC 5444 Message Header <msg-hoplimit> <msg-hopcount> | | RFC 5444 Message Header <msg-hoplimit> <msg-hopcount> |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| UnreachableNode AddrBlk (Unreachable Node addresses) | | UnreachableNode AddrBlk (Unreachable Node addresses) |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| UnreachableNode SeqNum AddrBlk TLV | | UnreachableNode SeqNum AddrBlk TLV |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 2: RERR message structure Figure 2: RERR message structure
Message Header Required Message Header Fields
RFC 5444 MsgHdr may contain the following options: The RERR MUST contain the following:
* <msg-hop-limit> * <msg-hop-limit>
* <msg-hop-count> * PktSource Message TLV, if the RERR is unicast
* PktSource MsgTLV * Metric Type Message TLV, if MetricType != 3
Optional Message Header Fields
The RERR may contain the following:
* <msg-hop-count>
UnreachableNode AddrBlk UnreachableNode AddrBlk
This Address Block contains the IP addresses unreachable by AODVv2 This Address Block contains the IP addresses unreachable by AODVv2
router transmitting the RERR. router transmitting the RERR.
Sequence Number AddrBlk TLV Sequence Number AddrBlk TLV
This Address Block TLV carries the destination sequence number This Address Block TLV carries the destination sequence number
associated with the UnreachableNodes when that information is associated with each UnreachableNode when that information is
available. available.
UnreachableNode.PfxLen UnreachableNode.PrefixLength
The prefix length associated with an UnreachableNode. The prefix length associated with an UnreachableNode.
There are two kinds of events indicating that packets cannot be There are two kinds of events indicating that packets cannot be
delivered to certain destinations. The two cases differ in the way delivered to certain destinations. The two cases differ in the way
that the neighboring IP destination address for the RERR (i.e., that the neighboring IP destination address for the RERR is chosen,
RERR_dest) is chosen, and in the way that the set of UnreachableNodes and in the way that the set of UnreachableNodes is identified.
is identified.
In both cases, the MsgHdr.<msg-hop-limit> MUST be set to In both cases, the <msg-hop-limit> MUST be included and SHOULD be set
MAX_HOPCOUNT. MsgHdr.<msg-hop-count> SHOULD be be included and set to MAX_HOPCOUNT. <msg-hop-count> SHOULD be be included and set to 0,
to 0, to facilitate use of various route repair strategies including to facilitate use of various route repair strategies including
Intermediate RREP [I-D.perkins-irrep]. expanding rings multicast and Intermediate RREP [I-D.perkins-irrep].
8.3.1. Case 1: Undeliverable Packet 8.3.1. Case 1: Undeliverable Packet
The first case happens when the router receives a packet but does not The first case happens when the router receives a packet but does not
have a valid route for the destination of the packet. In this case, have a valid route for the destination of the packet. In this case,
there is exactly one UnreachableNode to be included in the RERR's there is exactly one UnreachableNode to be included in the RERR's
AddrBlk. RERR_dest SHOULD be the multicast address LL-MANET-Routers, AddrBlk (either IP.DestinationAddress from a data packet or
but RERR_Gen MAY instead set RERR_dest to be the next hop towards the RREP.AddrBlk[TargNode]). The RERR SHOULD be sent to the multicast
source IP address of the packet which was undeliverable. In the address LL-MANET-Routers, but RERR_Gen MAY instead send the RERR to
latter case, the PktSource MsgTLV MUST be included, containing the the next hop towards the source IP address of the packet which was
the source IP address of the undeliverable packet. If a value for undeliverable. In the latter case, the PktSource Message TLV MUST be
the UnreachableNode's SeqNum (UnreachableNode.SeqNum) is known, it included, containing the the source IP address of the undeliverable
MUST be placed in the RERR. Otherwise, if no Seqnum AddrTLV is packet. If SeqNum UnreachableNode is known, it SHOULD be placed in
included, all nodes handling the RERR will assume their route through the RERR. Otherwise, if no Seqnum AddrTLV is included, all nodes
RERR_Gen towards the UnreachableNode is no longer valid and flag handling the RERR will assume their route through RERR_Gen towards
those routes as broken. RERR_Gen MUST discard the packet or message the UnreachableNode is no longer valid and flag those routes as
that triggered generation of the RERR. broken. RERR_Gen MUST discard the packet or message that triggered
generation of the RERR.
If an AODVv2 router receives an ICMP packet from the address of one
of its client nodes, it simply relays the packet to the ICMP packet's
destination address, and does not generate any RERR message.
8.3.2. Case 2: Broken Link 8.3.2. Case 2: Broken Link
The second case happens when the link breaks to an active downstream The second case happens when the link breaks to an active adjacent
neighbor (i.e., the next hop of an active route). In this case, AODVv2 router (i.e., the next hop of an active route). In this case,
RERR_dest MUST be the multicast address LL-MANET-Routers, except when the RERR MUST be sent to the multicast address LL-MANET-Routers,
the optional feature of maintaining precursor lists is used as except when the optional feature of maintaining precursor lists is
specified in Section 13.3. All Active, Idle and Expired routes that used as specified in Section 13.3. All routes (Active, Idle and
use the broken link MUST be marked as Broken. The set of Expired) that use the broken link MUST be marked as Broken. The set
UnreachableNodes is initialized by identifying those Active routes of UnreachableNodes is initialized by identifying those Active routes
which use the broken link. For each such Active Route, Route.Dest is which use the broken link. For each such Active Route, Route.Dest is
added to the set of Unreachable Nodes. After the Active Routes using added to the set of Unreachable Nodes. After the Active Routes using
the broken link have all been included as UnreachableNodes, idle the broken link have all been included as UnreachableNodes, idle
routes MAY also be included, as long as the packet size of the RERR routes MAY also be included, if allowed by the setting of
does not exceed the MTU of the physical medium. ENABLE_IDLE_UNREACHABLE, as long as the packet size of the RERR does
not exceed the MTU (interface "Maximum Transfer Unit") of the
physical medium.
If the set of UnreachableNodes is empty, no RERR is generated. If the set of UnreachableNodes is empty, no RERR is generated.
Otherwise, RERR_Gen generates a new RERR, and the address of each Otherwise, RERR_Gen generates a new RERR, and the address of each
UnreachableNode (IP.DestinationAddress from a data packet or UnreachableNode is inserted into an AddrBlock. If a prefix is known
RREP.TargNode.Address) is inserted into an AddrBlock. If a prefix is for the UnreachableNode.Address, it SHOULD be included. Otherwise,
known for the UnreachableNode.Address, it SHOULD be included. the UnreachableNode.Address is assumed to be a host address with a
Otherwise, the UnreachableNode.Address is assumed to be a host full length prefix. The value for each UnreachableNode's SeqNum
address with a full length prefix. The value for each (UnreachableNode.SeqNum) MUST be placed in a SeqNum AddrTLV. If none
UnreachableNode's SeqNum (UnreachableNode.SeqNum) MUST be placed in a of UnreachableNode.Addr entries are associated with known prefix
SeqNum AddrTLV. If none of UnreachableNode.Addr entries are lengths, then the AddrBlk SHOULD NOT include any prefix-length
associated with known prefix lengths, then the AddrBLK SHOULD NOT information. Otherwise, for each UnreachableNode.Addr that does not
include any prefix-length information. Otherwise, for each have any associated prefix-length information, the prefix-length for
UnreachableNode.Addr that does not have any associated prefix-length that address MUST be assigned to INVALID_PREFIX_LENGTH, which is a
information, the prefix-length for that address MUST be assigned to length strictly greater than the length of any valid address.
zero.
Every broken route reported in the RERR MUST have the same Metric
Type. If the Metric Type is not 3, then the RERR message MUST
contain a MetricType MsgTLV indicating the Metric Type of the broken
route(s).
8.4. Receiving and Handling RERR Messages 8.4. Receiving and Handling RERR Messages
When an AODVv2 router (HandlingRtr) receives a RERR message, it uses When an AODVv2 router (HandlingRtr) receives a RERR message, it uses
the information provided to invalidate affected routes. If the the information provided to invalidate affected routes. If the
information in the RERR may be useful to upstream neighbors using information in the RERR may be useful to upstream neighbors using
those routes, HandlingRtr subsequently sends another RERR to those those routes, HandlingRtr subsequently sends another RERR to those
neighbors. This operation has the effect of retransmitting the RERR neighbors. This operation has the effect of retransmitting the RERR
information and is counted as another "hop" for purposes of properly information and is counted as another "hop" for purposes of properly
modifying Msg.<msg-hop-limit> and Msg.<msg-hop-count>. modifying Msg.<msg-hop-limit> and Msg.<msg-hop-count>.
skipping to change at page 31, line 18 skipping to change at page 33, line 46
3. Route.NextHopInterface is the same as the interface on which the 3. Route.NextHopInterface is the same as the interface on which the
RERR was received. RERR was received.
4. The UnreachableNode.SeqNum is unknown, OR Route.SeqNum <= 4. The UnreachableNode.SeqNum is unknown, OR Route.SeqNum <=
UnreachableNode.SeqNum (using signed 16-bit arithmetic). UnreachableNode.SeqNum (using signed 16-bit arithmetic).
If the route satisfies all of the above conditions, HandlingRtr sets If the route satisfies all of the above conditions, HandlingRtr sets
the Route.Broken flag for that route. Furthermore, if Msg.<msg-hop- the Route.Broken flag for that route. Furthermore, if Msg.<msg-hop-
limit> is greater than 0, then HandlingRtr adds the UnreachableNode limit> is greater than 0, then HandlingRtr adds the UnreachableNode
address and TLV information to an AddrBlk for for delivery in the address and TLV information to an AddrBlk for delivery in the
outgoing RERR message to one or more of HandlingRtr's upstream outgoing RERR message.
neighbors.
If there are no UnreachableNode addresses to be transmitted in an If there are no UnreachableNode addresses to be transmitted in an
RERR to upstream routers, HandlingRtr MUST discard the RERR, and no RERR to upstream routers, HandlingRtr MUST discard the RERR, and no
further action is taken. further action is taken.
Otherwise, Msg.<msg-hop-limit> is decremented by one (1) and Otherwise, Msg.<msg-hop-limit> is decremented by one (1) and
processing continues as follows: processing continues as follows:
o If precursor lists are (optionally) maintained, the outgoing RERR o (Optional) If precursor lists are maintained, the outgoing RERR
SHOULD be sent to the active precursors of the broken route as SHOULD be sent to the active precursors of the broken route as
specified in Section 13.3. specified in Section 13.3.
o Otherwise, if the incoming RERR message was received at the LL- o Otherwise, if the incoming RERR message was received at the LL-
MANET-Routers [RFC5498] multicast address, the outgoing RERR MANET-Routers [RFC5498] multicast address, the outgoing RERR
SHOULD also be sent to LL-MANET-Routers. SHOULD also be sent to LL-MANET-Routers.
o Otherwise, if the PktSource MsgTLV is present, and HandlingRtr has o Otherwise, if the PktSource Message TLV is present, and
a Route to PktSource.Addr, then HandlingRtr MUST send the outgoing HandlingRtr has a Route to PktSource.Addr, then HandlingRtr MUST
RERR to Route[PktSource.Addr].NextHop. send the outgoing RERR to Route[PktSource.Addr].NextHop.
o Otherwise, the outgoing RERR MUST be sent to LL-MANET-Routers. o Otherwise, the outgoing RERR MUST be sent to LL-MANET-Routers.
9. Unknown Message and TLV Types 9. Unknown Message and TLV Types
If a message with an unknown type is received, the message is If a message with an unknown type is received, the message is
disregarded. disregarded.
For handling of messages that contain unknown TLV types, ignore the For handling of messages that contain unknown TLV types, ignore the
information for processing, preserve it unmodified for forwarding. information for processing, but preserve it unmodified for
forwarding.
10. Simple Internet Attachment 10. Simple Internet Attachment
Simple Internet attachment means attachment of a stub (i.e., non- Simple Internet attachment means attachment of a stub (i.e., non-
transit) network of AODVv2 routers to the Internet via a single transit) network of AODVv2 routers to the Internet via a single
Internet AODVv2 router (called IAR). Internet AODVv2 router (called IAR).
As in any Internet-attached network, AODVv2 routers, and their As in any Internet-attached network, AODVv2 routers, and their
clients, wishing to be reachable from hosts on the Internet MUST have clients, wishing to be reachable from hosts on the Internet MUST have
IP addresses within the IAR's routable and topologically correct IP addresses within the IAR's routable and topologically correct
prefix (e.g. 191.0.2.0/24). prefix (e.g. 191.0.2.0/24).
The IAR is responsible for generating RREQ messages to find nodes
within the MANET on behalf of nodes on the Internet, as well as
responding to route requests from the AODVv2 MANET on behalf of the
nodes on the Internet.
/-------------------------\ /-------------------------\
/ +----------------+ \ / +----------------+ \
/ | AODVv2 Router | \ / | AODVv2 Router | \
| | 191.0.2.2/32 | | | | 191.0.2.2/32 | |
| +----------------+ | Routable | +----------------+ | Routable
| +-----+--------+ Prefix | +-----+--------+ Prefix
| | Internet | /191.0.2/24 | | Internet | /191.0.2/24
| | AODVv2 Router| / | | AODVv2 Router| /
| | 191.0.2.1 |/ /----------------\ | | 191.0.2.1 |/ /----------------\
| | serving net +-------+ Internet \ | | serving net +-------+ Internet \
skipping to change at page 34, line 33 skipping to change at page 37, line 15
13.3. Precursor Lists and Notifications 13.3. Precursor Lists and Notifications
This section specifies an interoperable enhancement to AODVv2 (and This section specifies an interoperable enhancement to AODVv2 (and
possibly other reactive routing protocols) enabling more economical possibly other reactive routing protocols) enabling more economical
notifications to active sources of traffic upon determination that a notifications to active sources of traffic upon determination that a
route needed to forward such traffic to its destination has become route needed to forward such traffic to its destination has become
Broken. Broken.
13.3.1. Overview 13.3.1. Overview
In many circumstances, there might be several sources of traffic for In many circumstances, there can be several sources of traffic for a
any particular destination. Each such source of traffic is known as certain destination. Each such source of traffic is known as a
a "precursor" for the destination, as well as all upstream routers "precursor" for the destination, as well as all upstream routers
between the forwarding AODVv2 router and the traffic source. For between the forwarding AODVv2 router and the traffic source. For
each active destination, an AODVv2 router MAY choose to keep track of each active destination, an AODVv2 router MAY choose to keep track of
the upstream neighbors that have provided traffic for that the upstream neighbors that have provided traffic for that
destination; there is no need to keep track of upstream routers any destination; there is no need to keep track of upstream routers any
farther away than the next hop. farther away than the next hop.
Moreover, any particular link to an adjacent AODVv2 router may be a Moreover, any particular link to an adjacent AODVv2 router may be a
path component of multiple routes towards various destinations. The path component of multiple routes towards various destinations. The
precursors for all destinations using the next hop across any link precursors for all destinations using the next hop across any link
are collectively known as the precursors for that next hop. are collectively known as the precursors for that next hop.
skipping to change at page 35, line 29 skipping to change at page 38, line 11
When an AODVv2 router detects that a link is broken, then for each When an AODVv2 router detects that a link is broken, then for each
precursor using that next hop, the node MAY notify the precursor precursor using that next hop, the node MAY notify the precursor
using either unicast or multicast RERR: using either unicast or multicast RERR:
unicast RERR to each Active precursor unicast RERR to each Active precursor
This option is useful when there are few Active precursors This option is useful when there are few Active precursors
compared to the number of neighboring AODVv2 routers. compared to the number of neighboring AODVv2 routers.
multicast RERR to RERR_PRECURSORS multicast RERR to RERR_PRECURSORS
RERR_PRECURSORS is, by default, LL-MANET-Routers [RFC5498]. This RERR_PRECURSORS is, by default, LL-MANET-Routers [RFC5498]. This
option is typically preferable since fewer packet transmissions option is typically preferable when there are many precursors,
are required. since fewer packet transmissions are required.
Each active upstream neighbor (i.e., precursor) MAY then execute the Each active upstream neighbor (i.e., precursor) MAY then execute the
same procedure until all active upstream routers have received the same procedure until all active upstream routers have received the
RERR notification. RERR notification.
13.4. Multicast RREP Response to RREQ 13.4. Multicast RREP Response to RREQ
The RREQ Target Router (RREP_Gen) MAY, as an alternative to The RREQ Target Router (RREP_Gen) MAY, as an alternative to
unicasting a RREP, be configured to distribute routing information unicasting a RREP, be configured to distribute routing information
about the route toward the RREQ TargNode (TargRtr's client) more about the route toward the RREQ TargNode (RREP_Gen's client) more
widely. That is, RREP_Gen MAY be configured respond to a route widely. That is, RREP_Gen MAY be configured respond to a route
discovery by generating a RREP, using the procedure in Section 7.4, discovery by generating a RREP, using the procedure in Section 7.4,
but multicasting the RREP to LL-MANET-Routers [RFC5498]. Afterwards, but multicasting the RREP to LL-MANET-Routers [RFC5498] (subject to
similar suppression algorithm for useless RREP multicasts as
described in Section 7.6). The useless message suppression must
occur at every router handling the multicast RREP. Afterwards,
RREP_Gen processing for the incoming RREQ is complete. RREP_Gen processing for the incoming RREQ is complete.
Broadcast response to incoming RREQ was originally specified to Broadcast RREP response to incoming RREQ was originally specified to
handle unidirectional links, but it is expensive. Due to the handle unidirectional links, but it is expensive. Due to the
significant overhead, AODVv2 routers MUST NOT use multicast RREP significant overhead, AODVv2 routers MUST NOT use multicast RREP
unless configured to do so by setting the administrative parameter unless configured to do so by setting the administrative parameter
USE_MULTICAST_RREP. USE_MULTICAST_RREP.
13.5. RREP_ACK 13.5. RREP_ACK
Instead of relying on existing mechanisms for requesting verification Instead of relying on existing mechanisms for requesting verification
of link bidirectionality during Route Discovery, RREP_Ack is provided of link bidirectionality during Route Discovery, RREP_Ack is provided
as an optional feature and modeled on the RREP_Ack message type from as an optional feature and modeled on the RREP_Ack message type from
AODV [RFC3561]. AODV [RFC3561].
Since the RREP_ACK is simply echoed back to the node from which the Since the RREP_ACK is simply echoed back to the node from which the
RREP was received, there is no need for any additional RFC 5444 RREP was received, there is no need for any additional RFC 5444
address information (or TLVs). Considerations of packet TTL are as address information (or TLVs). Considerations of packet TTL are as
specified in Section 5.4. The message format is illustrated in specified in Section 5.4. An example message format is illustrated
section Appendix A.4. in section Appendix A.4.
13.6. Message Aggregation 13.6. Message Aggregation
The aggregation of multiple messages into a packet is specified in The aggregation of multiple messages into a packet is specified in
RFC 5444 [RFC5444]. RFC 5444 [RFC5444].
Implementations MAY choose to briefly delay transmission of messages Implementations MAY choose to briefly delay transmission of messages
for the purpose of aggregation (into a single packet) or to improve for the purpose of aggregation (into a single packet) or to improve
performance by using jitter [RFC5148]. performance by using jitter [RFC5148].
13.7. Added Routing Information in RteMsgs 13.7. Added Routing Information in RteMsgs
DSR [RFC4728] includes source routes as part of the data of its RREPs DSR [RFC4728] includes source routes as part of the data of its RREPs
and RREQs. Doign so allows additional topology information to be and RREQs. Doing so allows additional topology information to be
multicast along with the RteMsg, and potentially allows updating for multicast along with the RteMsg, and potentially allows updating for
stale routing information at MANET routers along new paths between stale routing information at MANET routers along new paths between
source and destination. To maintain this functionality, AODVv2 has source and destination. To maintain this functionality, AODVv2 has
defined a somewhat more general method that enables inclusion of defined a somewhat more general method that enables inclusion of
source routes in RteMsgs. source routes in RteMsgs.
Appending routing information can eliminate some route discovery Including additional routing information in outgoing RREQ or RREP
attempts to the nodes whose information is included, if handling messages can eliminate some route discovery attempts to the nodes
AODVv2 routers use this information to update their routing tables. whose information is included, if AODVv2 routers receiving the
information use it to update their routing tables.
Note that, since the initial merger of DSR with AODV to create this Note that, since the initial merger of DSR with AODV to create this
protocol, further experimentation has shown that including the protocol, further experimentation has shown that including the
additional routing information is not always helpful. Sometimes it additional routing information is not always helpful. Sometimes it
seems to help, and other times it seems to reduce overall seems to help, and other times it seems to reduce overall
performance. The results depend upon packet size and traffic performance. The results depend upon packet size and traffic
patterns. patterns.
13.7.1. Including Added Node Information 13.7.1. Including Added Node Information
skipping to change at page 37, line 16 skipping to change at page 40, line 6
The following notation is used to specify the methods for inclusion The following notation is used to specify the methods for inclusion
of routing information for addtional nodes. of routing information for addtional nodes.
AddedNode AddedNode
The IP address of an additional node that can be reached via the The IP address of an additional node that can be reached via the
AODVv2 router adding this information. Each AddedNode.Address AODVv2 router adding this information. Each AddedNode.Address
MUST include its prefix. Each AddedNode.Address MUST also have an MUST include its prefix. Each AddedNode.Address MUST also have an
associated Node.SeqNum in the address TLV block. associated Node.SeqNum in the address TLV block.
AddedNode.SeqNum AddedNode.SeqNum
The AODVv2 sequence number associated with this routing The Sequence Number associated with the AddedNode's routing
information. information.
AddedNode.Metric AddedNode.Metric
The cost of the route needed to reach the associated The cost of the route needed to reach the associated
AddedNode.Address. This field is increased by Cost(L) at each AddedNode.Address. This field is increased by Cost(L) at each
intermediate AODVv2 router, where 'L' is the incoming link. If, intermediate AODVv2 router, where 'L' is the incoming link. If,
for the Metric Type of the AddrBlk, it is not known how to compute for the Metric Type of the AddrBlk, it is not known how to compute
Cost(L), the AddedNode.Addr information MUST be deleted from the Cost(L), the AddedNode.Addr information MUST be deleted from the
AddedNode AddrBlk. AddedNode AddrBlk.
skipping to change at page 37, line 42 skipping to change at page 40, line 32
defined in [RFC5497]. defined in [RFC5497].
SeqNum and Metric AddrTLVs about any appended address(es) MUST be SeqNum and Metric AddrTLVs about any appended address(es) MUST be
included. included.
Routing information about the TargNode MUST NOT be added to the Routing information about the TargNode MUST NOT be added to the
AddedAddrBlk. Also, duplicate address entries SHOULD NOT be added. AddedAddrBlk. Also, duplicate address entries SHOULD NOT be added.
Only the best routing information (Section 6.1) for a particular Only the best routing information (Section 6.1) for a particular
address SHOULD be included; if route information is included for a address SHOULD be included; if route information is included for a
destination address already in the AddedAddrBlk, the previous destination address already in the AddedAddrBlk, the previous
information SHOULD NOT be included in the outgoing RteMsg. information SHOULD NOT be included in the RteMsg.
13.7.2. Handling Added Node Information 13.7.2. Handling Added Node Information
An intermediate node (i.e., HandlingRtr) obeys the following An intermediate node (i.e., HandlingRtr) obeys the following
procedures when processing AddedNode.Address information and other procedures when processing AddedNode.Address information and other
associated TLVs that are included with a RteMsg. For each AddedNode associated TLVs that are included with a RteMsg. For each AddedNode
(except the TargetNode) in the RteMsg, the AddedNode.Metric (except the TargetNode) in the RteMsg, the AddedNode.Metric
information MUST be increased by Cost(L), where 'L' is the incoming information MUST be increased by Cost(L), where 'L' is the incoming
link. If, for the Metric Type of the AddrBlk, it is not known how to link. If, for the Metric Type of the AddrBlk, it is not known how to
compute Cost(L), the AddedNode.Addr information MUST be deleted from compute Cost(L), the AddedNode.Addr information MUST be deleted from
skipping to change at page 38, line 37 skipping to change at page 41, line 26
Route.SeqNum, the incoming routing information is compared with the Route.SeqNum, the incoming routing information is compared with the
route table entry following the procedure described in Section 6.1. route table entry following the procedure described in Section 6.1.
If the incoming routing information is used, the route table entry If the incoming routing information is used, the route table entry
SHOULD be updated as described in Section 6.2. SHOULD be updated as described in Section 6.2.
If the routing information for an AddedNode.Address is not used, then If the routing information for an AddedNode.Address is not used, then
it is removed from the RteMsg. it is removed from the RteMsg.
If route information is included for a destination address already in If route information is included for a destination address already in
the AddedAddrBlk, the previous information SHOULD NOT be included in the AddedAddrBlk, the previous information SHOULD NOT be included in
the outgoing RteMsg. the RteMsg.
14. Administratively Configured Parameters and Timer Values 14. Administratively Configurable Parameters and Timer Values
AODVv2 contains several parameters which MUST be administratively AODVv2 uses various configurable parameters of various types:
configured. The list of these follows:
+------------------------+------------------------------------------+ o Timers
| Name | Description |
+------------------------+------------------------------------------+
| CLIENT_ADDRESSES | List of addresses and routing prefixes, |
| | for which this AODVv2 router is |
| | responsible. If the list is empty, this |
| | AODVv2 router is only responsible for |
| | its own addresses. |
| USE_MULTICAST_RREP | Whether or not to use multicast RREP |
| | (see Section 13.4). |
| DEFAULT_METRIC_TYPE | 3 (Hop Count {see [RFC6551]} |
| AODVv2_INTERFACES | List of the interfaces participating in |
| | AODVv2 routing protocol. |
+------------------------+------------------------------------------+
Table 2: Required Administratively Configured Parameters o Protocol constants
o Administrative (functional) controls
o Other administrative parameters and lists
The tables in the following sections show the parameters along their
definitions and default values (if any).
Note: several fields have limited size (bits or bytes). These sizes
and their encoding may place specific limitations on the values that
can be set. For example, <msg-hop-count> is a 8-bit field and
therefore MAX_HOPCOUNT cannot be larger than 255.
14.1. Timers
AODVv2 requires certain timing information to be associated with AODVv2 requires certain timing information to be associated with
route table entries. The default values are as follows: route table entries. The default values are as follows, subject to
future experience:
+------------------------------+-------------+ +------------------------------+---------------+
| Name | Value | | Name | Default Value |
+------------------------------+-------------+ +------------------------------+---------------+
| ACTIVE_INTERVAL | 5 second | | ACTIVE_INTERVAL | 5 second |
| MAX_IDLETIME | 200 seconds | | MAX_IDLETIME | 200 seconds |
| MAX_SEQNUM_LIFETIME | 300 seconds | | MAX_BLACKLIST_TIME | 200 seconds |
| ROUTE_RREQ_WAIT_TIME | 2 seconds | | MAX_SEQNUM_LIFETIME | 300 seconds |
| UNICAST_MESSAGE_SENT_TIMEOUT | 1 second | | ROUTE_RREQ_WAIT_TIME | 2 seconds |
| RREQ_HOLDDOWN_TIME | 10 seconds | | UNICAST_MESSAGE_SENT_TIMEOUT | 1 second |
+------------------------------+-------------+ | RREQ_HOLDDOWN_TIME | 10 seconds |
+------------------------------+---------------+
Table 3: Default Timing Parameter Values Table 2: Timing Parameter Values
The above timing parameter values have worked well for small and The above timing parameter values have worked well for small and
medium well-connected networks with moderate topology changes. medium well-connected networks with moderate topology changes.
The timing parameters SHOULD be administratively configurable for the The timing parameters SHOULD be administratively configurable for the
network where AODVv2 is used. Ideally, for networks with frequent network where AODVv2 is used. Ideally, for networks with frequent
topology changes the AODVv2 parameters should be adjusted using topology changes the AODVv2 parameters should be adjusted using
either experimentally determined values or dynamic adaptation. For either experimentally determined values or dynamic adaptation. For
example, in networks with infrequent topology changes MAX_IDLETIME example, in networks with infrequent topology changes MAX_IDLETIME
may be set to a much larger value. may be set to a much larger value.
+------------------------+-----------+------------------------------+ 14.2. Protocol constants
| Name | Value | Description |
+------------------------+-----------+------------------------------+
| MAX_HOPCOUNT | 20 hops | This value MUST be larger |
| | | than the AODVv2 network |
| | | diameter. Otherwise, |
| | | routing messages may not |
| | | reach their intended |
| | | destinations. |
| MAX_METRIC[i] | Not | If defined, this is the |
| | Specified | maximum permissible value |
| | in This | for Metric Type 'i' (see |
| | Document | [RFC6551]). |
| MAXTIME | TBD | The maximum expressible |
| | | value for clock time. |
| DISCOVERY_ATTEMPTS_MAX | 3 | The number of route |
| | | discovery attempts to make |
| | | before indicating that a |
| | | particular address is not |
| | | reachable. |
| MTU | TBD -- | Determines the maximum |
| | depends | number of RFC 5444 AddrBlk |
| | on | entries |
| | address | |
| | family | |
+------------------------+-----------+------------------------------+
Table 4: Default Parameter Values AODVv2 protocol constants typically do not require changes. The
following table lists these constants, along with their values and a
reference to the specification describing their use.
In addition to the above parameters and timing values, several +------------------------+-------------------+----------------------+
administrative options exist. These options have no influence on | Name | Default Value | Description |
correct routing behavior, although they may potentially reduce AODVv2 +------------------------+-------------------+----------------------+
protocol messaging in certain situations. The default behavior is to | DISCOVERY_ATTEMPTS_MAX | 3 | Section 7.1 |
NOT enable any of these options; and although many of these options | INVALID_PREFIX_LENGTH | 255 | Section 8.3.2 |
can be administratively controlled, they may be better served by | MAX_HOPCOUNT | 20 hops | Section 5.6 |
intelligent control. The following table enumerates several of the | MAX_METRIC[i] | Specified only | Section 5.6 |
options. | | for HopCount | |
| MAXTIME | [TBD] | Maximum expressible |
| | | clock time |
+------------------------+-------------------+----------------------+
Table 3: Parameter Values
+-------------------------+-----------------------------------------+ 14.3. Administrative (functional) controls
| Name | Description |
+-------------------------+-----------------------------------------+
| APPEND_INFORMATION | Whether or not appending routing |
| | information for AddedNodes to a RteMsg |
| | is enabled. |
| BUFFER_SIZE_PACKETS | 2 |
| BUFFER_SIZE_BYTES | MAX_PACKET_SIZE [TBD] |
| APPEND_IDLE_UNREACHABLE | Whether to append Unreachable |
| | information about idle routes to RERR. |
| CONTROL_TRAFFIC_LIMIT | TBD [50 msgs/sec?] |
+-------------------------+-----------------------------------------+
Table 5: Administratively Controlled Options The following administrative controls may be used to change the
operation of the network, by enabling optional behaviors. These
options are not required for correct routing behavior, although they
may potentially reduce AODVv2 protocol messaging in certain
situations. The default behavior is to NOT enable most such options,
options. Packet buffering is enabled by default.
Note: several fields have limited size (bits or bytes). These sizes +-------------------------+-------------------------------+
and their encoding may place specific limitations on the values that | Name | Description |
can be set. For example, MsgHdr.<msg-hop-count> is a 8-bit field and +-------------------------+-------------------------------+
therefore MAX_HOPCOUNT cannot be larger than 255. | APPEND_INFORMATION | Section 13.7.1 |
| DEFAULT_METRIC_TYPE | 3 {Hop Count (see [RFC6551])} |
| ENABLE_IDLE_UNREACHABLE | Section 8.3.2 |
| ENABLE_IRREP | Section 7.3 |
| USE_MULTICAST_RREP | Section 13.4 |
+-------------------------+-------------------------------+
Table 4: Administratively Configured Controls
14.4. Other administrative parameters and lists
The following table lists contains AODVv2 parameters which should be
administratively configured for each specific network.
+-----------------------+-----------------------+-----------------+
| Name | Default Value | Cross Reference |
+-----------------------+-----------------------+-----------------+
| AODVv2_INTERFACES | | Section 4 |
| BUFFER_SIZE_PACKETS | 2 | Section 7.1 |
| BUFFER_SIZE_BYTES | MAX_PACKET_SIZE [TBD] | Section 7.1 |
| CLIENT_ADDRESSES | AODVv2_INTERFACES | Section 5.3 |
| CONTROL_TRAFFIC_LIMIT | TBD [50 packets/sec?] | Section 12 |
+-----------------------+-----------------------+-----------------+
Table 5: Other Administrative Parameters
15. IANA Considerations 15. IANA Considerations
This section specifies several message types, message tlv-types, and This section specifies several message types, message tlv-types, and
address tlv-types. Also, a new registry of 16-bit alternate metric address tlv-types. Also, a new registry of 16-bit alternate metric
types is specified. types is specified.
15.1. AODVv2 Message Types Specification 15.1. AODVv2 Message Types Specification
+----------------------------------------+----------+ +----------------------------------------+------------+
| Name | Type | | Name | Type (TBD) |
+----------------------------------------+----------+ +----------------------------------------+------------+
| Route Request (RREQ) | 10 - TBD | | Route Request (RREQ) | 10 |
| Route Reply (RREP) | 11 - TBD | | Route Reply (RREP) | 11 |
| Route Error (RERR) | 12 - TBD | | Route Error (RERR) | 12 |
| Route Reply Acknowledgement (RREP_ACK) | 13 - TBD | | Route Reply Acknowledgement (RREP_ACK) | 13 |
+----------------------------------------+----------+ +----------------------------------------+------------+
Table 6: AODVv2 Message Types Table 6: AODVv2 Message Types
15.2. Message and Address Block TLV Type Specification 15.2. Message TLV Type Specification
+-------------------+------+--------+-------------------------------+ +-----------------------------------+-------+---------+-------------+
| Name | Type | Length | Value | | Name | Type | Length | Cross |
+-------------------+------+--------+-------------------------------+ | | (TBD) | in | Reference |
| Unicast Response | 10 - | 0 | Indicates to the handling | | | | octets | |
| Request (RespReq) | TBD | octets | (receiving) AODVv2 router | +-----------------------------------+-------+---------+-------------+
| | | | that the previous hop | | Acknowledgment Request (AckReq) | 10 | 0 | Section 5.2 |
| | | | (IP.SourceAddress) expects a | | Destination RREP Only (DestOnly) | 11 | 0 | Section 7.3 |
| | | | unicast reply message within | | Packet Source (PktSource) | 12 | 4 or 16 | Section 8.3 |
| | | | UNICAST_MESSAGE_SENT_TIMEOUT. | | Metric Type | 13 | 1 | Section 7.2 |
| | | | -- | +-----------------------------------+-------+---------+-------------+
| Destination RREP | 11 - | 0 | Indicates that intermediate |
| Only (DestOnly) | TBD | octets | RREPs are prohibited. |
| | | | -- |
| Packet source IP | 12 - | 4 or | Provides the IP address for |
| address | TBD | 16 | RERR messages generated due |
| (PktSource) | | octets | to inability to deliver a |
| | | | packet. |
| | | | -- |
| Metric Type | 13 - | 1 | Type of metric in the Metric8 |
| | TBD | octet | or Metric16 AddrTLV. |
+-------------------+------+--------+-------------------------------+
Table 7: Message TLV Types Table 7: Message TLV Types
15.3. Address Block TLV Specification 15.3. Address Block TLV Specification
+---------------+------------+----------+---------------------------+ +----------------------------+--------+---------------+-------------+
| Name | Type | Length | Value | | Name | Type | Length | Value |
+---------------+------------+----------+---------------------------+ | | (TBD) | | |
| VALIDITY_TIME | 1[RFC5497] | 1 octet | The maximum amount of | +----------------------------+--------+---------------+-------------+
| | | | time that information can | | Metric | 10 | depends on | Section 7.2 |
| | | | be maintained before | | | | Metric Type | |
| | | | being deleted. The | | Sequence Number (SeqNum) | 11 | 2 octets | Section 7.2 |
| | | | VALIDITY_TIME TLV is | | VALIDITY_TIME | 1 | 1 octet | [RFC5497] |
| | | | defined in [RFC5497]. | +----------------------------+--------+---------------+-------------+
| | | | -- |
| Sequence | 10 - TBD | 2 octets | The latest AODVv2 |
| Number | | | sequence number |
| (SeqNum) | | | associated with the |
| | | | address. |
| Metric8 | 11 - TBD | 1 octet | 8-bit Cost of the route |
| | | | to reach the destination |
| | | | address. |
| Metric16 | 12 - TBD | 2 octets | 16-bit Cost of the route |
| | | | to reach the destination |
| | | | address. |
+---------------+------------+----------+---------------------------+
Table 8: Address Block TLV (AddrTLV) Types Table 8: Address Block TLV (AddrTLV) Types
The same number space should be used for both Metric8 and Metric16
metric types.
15.4. Metric Type Number Allocation 15.4. Metric Type Number Allocation
Metric types are identified according to the assignments as specified Metric types are identified according to the assignments as specified
in [RFC6551]. The metric type of the Hop Count metric is assigned to in [RFC6551]. The metric type of the Hop Count metric is assigned to
be 3, in order to maintain compatibility with that existing table of be 3, in order to maintain compatibility with that existing table of
values from RFC 6551. If non-additive metrics are to be used, the values from RFC 6551. Non-addititve metrics are not supported in
specification for assessing the usability of route updates (see this draft.
Section 6.1 ) may require changes.
+-----------------------+----------+-----------+ +-----------------------+----------+-------------+
| Name | Type | Size | | Name | Type | Metric Size |
+-----------------------+----------+-----------+ +-----------------------+----------+-------------+
| Reserved | 0 | Undefined | | Unallocated | 0 -- 2 | TBD |
| Unallocated | 1 -- 2 | TBD | | Hop Count | 3 - TBD | 1 octet |
| Hop Count | 3 - TBD | 1 octet | | Unallocated | 4 -- 254 | TBD |
| Unallocated | 4 -- 254 | TBD | | Reserved | 255 | Undefined |
| Reserved | 255 | Undefined | +-----------------------+----------+-------------+
+-----------------------+----------+-----------+
Table 9: Metric Types Table 9: Metric Types
16. Security Considerations 16. Security Considerations
The objective of the AODVv2 protocol is for each router to The objective of the AODVv2 protocol is for each router to
communicate reachability information about addresses for which it is communicate reachability information about addresses for which it is
responsible. Positive routing information (i.e. a route exists) is responsible. Positive routing information (i.e. a route exists) is
distributed via RteMsgs and negative routing information (i.e. a distributed via RteMsgs and negative routing information (i.e. a
route does not exist) via RERRs. AODVv2 routers that handle these route does not exist) via RERRs. AODVv2 routers that handle these
skipping to change at page 47, line 37 skipping to change at page 49, line 39
IPv6 addressable MANET nodes, and a layout for the Address TLVs that IPv6 addressable MANET nodes, and a layout for the Address TLVs that
may be viewed as natural, even if perhaps not the absolute most may be viewed as natural, even if perhaps not the absolute most
compact possible encoding. compact possible encoding.
For RteMsgs, the msg-hdr fields are followed by at least one and For RteMsgs, the msg-hdr fields are followed by at least one and
optionally two Address Blocks. The first AddrBlk contains OrigNode optionally two Address Blocks. The first AddrBlk contains OrigNode
and TargNode. For each AddrBlk, there must be AddrTLVs of type and TargNode. For each AddrBlk, there must be AddrTLVs of type
Seqnum and of type Metric. Seqnum and of type Metric.
In addition to the Seqnum TLV, there MUST be an AddrTLV of type In addition to the Seqnum TLV, there MUST be an AddrTLV of type
Metric. The msg-hop-count is counts the number of hops followed by Metric. The msg-hop-count counts the number of hops followed by the
the RteMsg from RteMsg_Orig to the current intermediate AODVv2 router RteMsg from point of generation to the current intermediate AODVv2
handling the RteMsg. Alternate metrics are enabled by the inclusion router handling the RteMsg. Alternate metrics are enabled by the
of the MetricType MsgTLV. When there is no such MetricType MsgTLV inclusion of the MetricType Message TLV. When there is no such
present, then the Metric AddrTLV measures HopCount. The Metric MetricType Message TLV present, then the Metric AddrTLV measures
AddrTLV also provides a way for the RteMsg_Orig to supply an initial HopCount. The Metric AddrTLV also provides a way for the AODV router
nonzero cost for the route between the RteMsg_Orig and its client generating the RREQ or RREP to supply an initial nonzero cost for the
node, i.e., either OrigNode or TargNode. route to its client node (OrigNode or TargNode, for RREQ or RREP
respectively).
AddedNode information MAY be included in a RteMsg by adding a second AddedNode information MAY be included in a RteMsg by adding a second
AddrBlk. Both Metric AddrTLVs use the same Metric Type. AddrBlk. Both Metric AddrTLVs use the same Metric Type.
In all cases, the length of an address (32 bits for IPv4 and 128 bits
for IPv6) inside an AODVv2 message is indicated by the msg-addr-
length (MAL) in the msg-header, as specified in [RFC5444].
A.1. RREQ Message Format A.1. RREQ Message Format
The figure below illustrates a packet format for an example RREQ Figure 4 illustrates a packet format for an example RREQ message.
message.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PV=0 | PF=0 | msg-type=RREQ | MF=4 | MAL=3 | msg-size=24 | | PV=0 | PF=0 | msg-type=RREQ | MF=4 | MAL=3 | msg-size=28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-size=24 | msg-hop-limit | msg.tlvs-length=0 | | msg-size=28 | msg-hop-limit | msg.tlvs-length=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| num-addr=2 |1|0|0|0|0| Rsv | head-length=3 |Head(Orig&Targ)| | num-addr=2 |1|0|0|0|0| Rsv | head-length=3 |Head(Orig&Targ)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (bytes for Orig & Target)| Orig.Tail | Target.Tail | | Head (bytes for Orig & Target)| Orig.Tail | Target.Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| addr.tlvs-length=11 | type=SeqNum |0|1|0|1|0|0|Rsv| | addr.tlvs-length=11 | type=SeqNum |0|1|0|1|0|0|Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index-start=0 | tlv-length=2 | Orig.Node Sequence # | | Index-start=0 | tlv-length=2 | Orig.Node Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type=SeqNum |0|1|0|1|0|0|Rsv| Index-start=0 | tlv-length=1 | | type=Metric |0|1|0|1|0|0|Rsv| Index-start=0 | tlv-length=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OrigNodeHopCt | | OrigNodeHopCt |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
RREQ with SeqNum and Metric AddrTLVs added, and: - two addresses in Figure 4: Example IPv4 RREQ, with SeqNum and Metric AddrTLVs
Address Block - address length = 4 [IPv4], shared initial bytes = 3 -
Sequence Number available only for Orig.Node in addr.tlv - Hop Count
available only for Orig.Node in Metric8 AddrTLV - Addresses stored in
the order OrigNode, TargNode
Figure 4: Example IPv4 RREQ The fields in Figure 4 are to be interpreted as follows:
o PV=0 (Packet Header Version = 0)
o PF=0 (Packet Flags = 0)
o msg-type=RREQ (first [and only] message is of type RREQ)
o MF=4 (Message Flags = 4 [only msg-hop-limit field is present])
o MAL=3 (Message Address Length indicator [3 for IPv4, 15 for IPv6])
o msg-size=28 (octets -- counting MsgHdr, MsgTLVs, and AddrBlks)
o msg-hop-limit (initially MAX_HOPCOUNT by default)
o msg.tlvs-length=0 (no Message TLVs)
o num-addr=2 (OrigNode and TargNode addresses in RteMsg AddrBlock)
o AddrBlk flags:
* bit 0 (ahashead): 1
* bit 1 (ahasfulltail): 0
* bit 2 (ahaszerotail): 0
* bit 3 (ahassingleprelen): 0
* bit 4 (ahasmultiprelen): 0
* bits 5-7: RESERVED
o head-length=3 (length of head part of each address is 3 octets)
o Head (3 initial bytes for both Originating & Target addresses)
o Orig.Tail (4th byte of Originating Node IP address)
o Target.Tail (4th byte of Target Node IP address)
o addr.tlvs-length=11 (length in bytes for SeqNum and Metric TLVs
o type=SeqNum (AddrTLV type of first AddrBlk TLV, values 2 octets)
o AddrTLV flags for SeqNumTLV:
* bit 0 (thastypeext): 0
* bit 1 (thassingleindex): 1
* bit 2 (thasmultiindex): 0
* bit 3 (thasvalue): 1
* bit 4 (thasextlen): 0
* bit 5 (tismultivalue): 0
* bits 6-7: RESERVED
o Index-start=0 (SeqNum TLV values start at index 0)
o tlv-length=2 (so there is only one TLV value, [1 = 2/2])
o Orig.Node Sequence # (first [and only] TLV value for SeqNum TLVs
o type=Metric (AddrTLV type of second AddrBlk TLV, values 1 octet)
o AddrTLV flags for MetricTLV:
* bit 0 (thastypeext): 0
* bit 1 (thassingleindex): 1
* bit 2 (thasmultiindex): 0
* bit 3 (thasvalue): 1
* bit 4 (thasextlen): 0
* bit 5 (tismultivalue): 0
* bits 6-7: RESERVED
o Index-start=0 (Metric TLV values start at index 0)
o tlv-length=1 (so there is only one TLV value, [1 = 1/1])
o OrigNodeHopCt (first [and only] TLV value for Metric TLVs)
A.2. RREP Message Format A.2. RREP Message Format
The figure below illustrates a packet format for an example RREP Figure 5 illustrates a packet format for an example RREP message.
message.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PV=0 | PF=0 | msg-type=RREP | MF=4 | MAL=3 | msg-size=30 | | PV=0 | PF=0 | msg-type=RREP | MF=4 | MAL=3 | msg-size=30 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-size=30 | msg-hop-limit | msg.tlvs-length=0 | | msg-size=30 | msg-hop-limit | msg.tlvs-length=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| num-addr=2 |1|0|0|0|0| Rsv | head-length=3 |Head(Orig&Targ)| | num-addr=2 |1|0|0|0|0| Rsv | head-length=3 |Head(Orig&Targ)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (bytes for Orig & Target)| Orig.Tail | Target.Tail | | Head (bytes for Orig & Target)| Orig.Tail | Target.Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| addr.tlvs-length=13 | type=SeqNum |0|1|0|1|0|0|Rsv| | addr.tlvs-length=13 | type=SeqNum |0|1|0|1|0|0|Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index-start=0 | tlv-length=2 | Orig.Node Sequence # | | Index-start=0 | tlv-length=2 | Orig.Node Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target.Node Sequence # | type=Metric8 |0|1|0|1|0|0|Rsv| | Target.Node Sequence # | type=Metric |0|1|0|1|0|0|Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index-start=1 | tlv-length=1 | TargNodeHopCt | | Index-start=1 | tlv-length=1 | TargNodeHopCt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RREP with SeqNum and Metric AddrTLVs added, and: - two addresses in Figure 5: Example IPv4 RREP, with 2 SeqNums and 1 Metric
AddrBlk - address length = 4 [IPv4], shared initial bytes = 3 - One
Sequence Number (for TargNode) in SeqNum AddrTLV - Hop Count
available only for Targ.Node in Metric8 AddrTLV - Addresses stored in
the order OrigNode, TargNode
Figure 5: Example IPv4 RREP The fields in Figure 5 are to be interpreted as follows:
o PV=0 (Packet Header Version = 0)
o PF=0 (Packet Flags = 0)
o msg-type=RREP (first [and only] message is of type RREP)
o MF=4 (Message Flags = 4 [only msg-hop-limit field is present])
o MAL=3 (Message Address Length indicator [3 for IPv4, 15 for IPv6])
o msg-size=28 (octets -- counting MsgHdr, MsgTLVs, and AddrBlks)
o msg-hop-limit (initially MAX_HOPCOUNT by default)
o msg.tlvs-length=0 (no Message TLVs)
o num-addr=2 (OrigNode and TargNode addresses in RteMsg AddrBlock)
o AddrBlk flags:
* bit 0 (ahashead): 1
* bit 1 (ahasfulltail): 0
* bit 2 (ahaszerotail): 0
* bit 3 (ahassingleprelen): 0
* bit 4 (ahasmultiprelen): 0
* bits 5-7: RESERVED
o head-length=3 (length of head part of each address is 3 octets)
o Head (3 initial bytes for both Originating & Target addresses)
o Orig.Tail (4th byte of Originating Node IP address)
o Target.Tail (4th byte of Target Node IP address)
o addr.tlvs-length=13 (length in bytes for SeqNum and Metric TLVs
o type=SeqNum (AddrTLV type of first AddrBlk TLV, values 2 octets)
o AddrTLV flags for SeqNumTLV:
* bit 0 (thastypeext): 0
* bit 1 (thassingleindex): 1
* bit 2 (thasmultiindex): 0
* bit 3 (thasvalue): 1
* bit 4 (thasextlen): 0
* bit 5 (tismultivalue): 0
* bits 6-7: RESERVED
o Index-start=0 (SeqNum TLV values start at index 0)
o tlv-length=4 (so there is are two TLV values, [2 = 4/2])
o Orig.Node Sequence # (first of two TLV values for SeqNum TLVs
o Targ.Node Sequence # (second of two TLV values for SeqNum TLVs
o type=Metric (AddrTLV type of second AddrBlk TLV, values 1 octet)
o AddrTLV flags for MetricTLV [01010000, same as for SeqNumTLV]
o Index-start=1 (Metric TLV values start at index 1)
o tlv-length=1 (so there is only one TLV value, [1 = 1/1])
o TargNodeHopCt (first [and only] TLV value for Metric TLVs)
A.3. RERR Message Format A.3. RERR Message Format
The figure below illustrates a packet format for an example RERR Figure 6 illustrates a packet format for an example RERR message.
message.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PV=0 | PF=0 | msg-type=RERR | MF=4 | MAL=3 | msg-size=25 | | PV=0 | PF=0 | msg-type=RERR | MF=4 | MAL=3 | msg-size=24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-size=25 | msg-hop-limit | msg.tlvs-length=0 | | msg-size=24 | msg-hop-limit | msg.tlvs-length=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| num-addr=2 |1|0|0|0|0| Rsv | head-length=3 |Head(Two Dests)| | num-addr=2 |1|0|0|0|0| Rsv | head-length=3 | Head (3 bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (for both destinations) | Tail(Dest_1) | Tail(Dest_2) | | Head (for both destinations) | Tail(Dest_1) | Tail(Dest_2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| addr.tlvs-length=8 | type=SeqNum |0|1|0|1|0|0|Rsv| | addr.tlvs-length=7 | type=SeqNum |0|0|1|1|0|1|Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index-start=0 | tlv-length=2 | Dest_1 Sequence # | | tlv-length=4 | Dest_1 Sequence # | Dest_2 Seq# |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest_2 Sequence # | | Dest_2 Seq# |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
RERR with - Two Unreachable Node address in Address Block - address Figure 6: Example IPv4 RERR with Two Unreachable Nodes
length = 4 [IPv4], shared initial bytes = 3 - Two Sequence Numbers
available in addr.tlv - Addresses stored from Originator to Target
Figure 6: Example IPv4 RERR The fields in Figure 6 are to be interpreted as follows:
o PV=0 (Packet Header Version = 0)
o PF=0 (Packet Flags = 0)
o msg-type=RERR (first [and only] message is of type RERR)
o MF=4 (Message Flags = 4 [only msg-hop-limit field is present])
o MAL=3 (Message Address Length indicator [3 for IPv4, 15 for IPv6])
o msg-size=24 (octets -- counting MsgHdr, MsgTLVs, and AddrBlks)
o msg-hop-limit (initially MAX_HOPCOUNT by default)
o msg.tlvs-length=0 (no Message TLVs)
o num-addr=2 (OrigNode and TargNode addresses in RteMsg AddrBlock)
o AddrBlk flags == 10000000 [same as RREQ and RREP AddrBlk examples]
o head-length=3 (length of head part of each address is 3 octets)
o Head (3 initial bytes for both Unreachable Nodes, Dest_1 and
Dest_2)
o Dest_1.Tail (4th byte of Dest_1 IP address)
o Dest_2.Tail (4th byte of Dest_2 IP address)
o addr.tlvs-length=7 (length in bytes for SeqNum TLV
o type=SeqNum (AddrTLV type of AddrBlk TLV, values 2 octets each)
o AddrTLV flags for SeqNumTLV:
* bit 0 (thastypeext): 0
* bit 1 (thassingleindex): 0
* bit 2 (thasmultiindex): 1
* bit 3 (thasvalue): 1
* bit 4 (thasextlen): 0
* bit 5 (tismultivalue): 1
* bits 6-7: RESERVED
o Index-start=0 (SeqNum TLV values start at index 0)
o tlv-length=4 (so there is are two TLV values, [2 = 4/2])
o Dest_1 Sequence # (first of two TLV values for SeqNum TLVs)
o Dest_2 Sequence # (second of two TLV values for SeqNum TLVs)
A.4. RREP_ACK Message Format A.4. RREP_ACK Message Format
The figure below illustrates a packet format for an example RREP_ACK The figure below illustrates a packet format for an example RREP_ACK
message. message.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PV=0 | PF=0 |msg-type=RREPAk| MF=0 | MAL=3 | msg-size=3 | | PV=0 | PF=0 |msgtype=RREPAck| MF=0 | MAL=3 | msg-size=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-size=3 | | msg-size=4 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
RREP_ACK - address length = 4 [IPv4]
Figure 7: Example IPv4 RREP_ACK Figure 7: Example IPv4 RREP_ACK
Appendix B. Changes since revision ...-21.txt Appendix B. Changes since revision ...-24.txt
The main goals of this revision are to improve readability and to
introduce a protocol update to handle suppression of unnecessary
multicast RREQs and certain other messages.
o Specified operations for maintenance and use of RREQ Table (see
Section 5.7, Section 7.6).
o Inserted explanations for example packet formats in appendix (see
Appendix A).
o Eliminated OwnSeqNum, RERR_dest, and various other abbreviations,
reworded relevant text.
o Reorganized Section 14 into four sections so that the various
parameters are grouped more naturally into tables of similar
types.
o Replaced parameter descriptions in the tables in Section 14, with
cross references to the parameter descriptions in the body of the
specification.
o Created parameters and administrative controls ENABLE_IRREP and
MAX_BLACKLIST_TIME which had been alluded to in the body of the
specification.
o Corrected metric comparison formulae to include cost of incoming
link.
o Renamed Unicast Response Request MsgTLV to be Acknowledgment
Request.
o Clarified <msg-hop-limit> and <msg-hop-count> mandates and
initialization.
o Reformatted various tables to improve readability.
o Changed some descriptions to apply to "Incoming" messages instead
of "Outgoing" messages, enabling simpler specification.
o Many other minor editorial improvements to improve readability and
eliminate possibly ambiguities.
Appendix C. Changes between revisions ...-21.txt and ...-24.txt
The revisions of this document that were numbered 22 and 23 were The revisions of this document that were numbered 22 and 23 were
produced without sufficient time for preparation, and suffered from produced without sufficient time for preparation, and suffered from
numerous editorial errors. Therefore, this list of changes is numerous editorial errors. Therefore, this list of changes is
enumerated based on differences between this revision (24) and enumerated based on differences between this revision (24) and
revision 21. revision 21.
o Alternate metrics enabled: o Alternate metrics enabled:
* New section added to describe general design approach. * New section added to describe general design approach.
* Abstract functions "Cost()" and "LoopFree()" defined. * Abstract functions "Cost()" and "LoopFree()" defined.
* MAX_HOPCOUNT typically replaced by MAX_METRIC. * MAX_HOPCOUNT typically replaced by MAX_METRIC.
* DEFAULT_METRIC_TYPE parameter defined, defaulting to HopCount. * DEFAULT_METRIC_TYPE parameter defined, defaulting to HopCount.
* MetricType Message TLV defined.
* MetricType MsgTLV defined. * Metric Address TLV defined.
* Metric8 and Metric16 AddrTLVs defined.
o Many changes for RFC 5444 compliance o Many changes for RFC 5444 compliance
o New section added for "Notational Conventions" (see Table 1). o New section added for "Notational Conventions" (see Table 1).
Many changes to improve readability and accuracy (e.g., eliminate Many changes to improve readability and accuracy (e.g., eliminate
use of "Flooding", "ThisNode", ...). use of "Flooding", "ThisNode", ...).
o Reorganized and simplified route lifetime management (see o Reorganized and simplified route lifetime management (see
Section 5.1). Section 5.1).
o Reorganized document structure, combining closely related small o Reorganized document structure, combining closely related small
sections and eliminating top-level "Detailed ..." section. sections and eliminating top-level "Detailed ..." section.
* RREQ and RREP specification sections coalesced. * RREQ and RREP specification sections coalesced.
* RERR specification sections coalesced. * RERR specification sections coalesced.
* Eliminated resulting duplicated specification. * Eliminated resulting duplicated specification.
* New section added for "Notational Conventions". * New section added for "Notational Conventions".
o Internet-Facing AODVv2 router renamed to be IAR o Internet-Facing AODVv2 router renamed to be IAR
o "Optional Features" section (see Section 13) created to contain o "Optional Features" section (see Section 13) created to contain
features not required within base specification, including: features not required within base specification, including:
* Adding RREP-ACK message type instead of relying on reception of * Adding RREP-ACK message type instead of relying on reception of
arbitrary packets as sufficient response to establish arbitrary packets as sufficient response to establish
bidirectionality. bidirectionality.
* Expanding Rings Multicast * Expanding Rings Multicast
* Intermediate RREPs (iRREPs): Without iRREP, only the * Intermediate RREPs (iRREPs): Without iRREP, only the
destination can respond to a RREQ. destination can respond to a RREQ.
* Precursor lists. * Precursor lists.
* Reporting Multiple Unreachable Nodes. An RERR message can * Reporting Multiple Unreachable Nodes. An RERR message can
carry more than one Unreachable Destination node for cases when carry more than one Unreachable Destination node for cases when
a single link breakage causes multiple destinations to become a single link breakage causes multiple destinations to become
unreachable from an intermediate router. unreachable from an intermediate router.
* Message Aggregation. * Message Aggregation.
* Inclusion of Added Routing Information. * Inclusion of Added Routing Information.
o Sequence number MUST be incremented after generating any RteMsg. o Sequence number MUST be incremented after generating any RteMsg.
o Resulting simplifications for accepting route updates in RteMsgs. o Resulting simplifications for accepting route updates in RteMsgs.
o Sequence number MUST (instead of SHOULD) be set to 1 after o Sequence number MUST (instead of SHOULD) be set to 1 after
rollover. rollover.
o AODVv2 routers MUST (instead of SHOULD) only handle AODVv2 o AODVv2 routers MUST (instead of SHOULD) only handle AODVv2
messages from adjacent routers. messages from adjacent routers.
o Clarification that Added Routing information in RteMsgs is o Clarification that Added Routing information in RteMsgs is
optional (MAY) to use. optional (MAY) to use.
o Clarification that if Added Routing information in RteMsgs is o Clarification that if Added Routing information in RteMsgs is
used, then the Route Table Entry SHOULD be updated using normal used, then the Route Table Entry SHOULD be updated using normal
procedures as described in Section 6.2. procedures as described in Section 6.2.
o Clarification in Section 7.1 that nodes may be configured to o Clarification in Section 7.1 that nodes may be configured to
buffer zero packets. buffer zero packets.
o Clarification in Section 7.1 that buffered packets MUST be dropped o Clarification in Section 7.1 that buffered packets MUST be dropped
if route discovery fails. if route discovery fails.
o In Section 8.2, relax mandate for monitoring connectivity to next- o In Section 8.2, relax mandate for monitoring connectivity to next-
hop AODVv2 neighbors (from MUST to SHOULD), in order to allow for hop AODVv2 neighbors (from MUST to SHOULD), in order to allow for
minimal implementations minimal implementations
o Remove Route.Forwarding flag; identical to "NOT" Route.Broken. o Remove Route.Forwarding flag; identical to "NOT" Route.Broken.
o Routing Messages MUST be originated with the <msg-hop-limit> set
o Routing Messages MUST be originated with the MsgHdr.<msg-hop- to MAX_HOPCOUNT.
limit> set to MAX_HOPCOUNT.
o Maximum hop count set to MAX_HOPCOUNT, and 255 is reserved for o Maximum hop count set to MAX_HOPCOUNT, and 255 is reserved for
"unknown". Since the current draft only uses hop-count as "unknown". Since the current draft only uses hop-count as
distance, this is also the current maximum distance. distance, this is also the current maximum distance.
Appendix C. Shifting Network Prefix Advertisement Between AODVv2 Appendix D. Shifting Network Prefix Advertisement Between AODVv2
Routers Routers
Only one AODVv2 router within a MANET SHOULD be responsible for a Only one AODVv2 router within a MANET SHOULD be responsible for a
particular address at any time. If two AODVv2 routers dynamically particular address at any time. If two AODVv2 routers dynamically
shift the advertisement of a network prefix, correct AODVv2 routing shift the advertisement of a network prefix, correct AODVv2 routing
behavior must be observed. The AODVv2 router adding the new network behavior must be observed. The AODVv2 router adding the new network
prefix must wait for any existing routing information about this prefix must wait for any existing routing information about this
network prefix to be purged from the network. Therefore, it must network prefix to be purged from the network. Therefore, it must
wait at least ROUTER_SEQNUM_AGE_MAX_TIMEOUT after the previous AODVv2 wait at least ROUTER_SEQNUM_AGE_MAX_TIMEOUT after the previous AODVv2
router for this address stopped advertising routing information on router for this address stopped advertising routing information on
 End of changes. 244 change blocks. 
804 lines changed or deleted 1022 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/