Mobile Ad hoc Networks Working Group C. Perkins
Internet-Draft Futurewei
Intended status: Standards Track March 9, 2015
Expires: September 10, 2015

AODVv2 Example RFC 5444 Packets
draft-perkins-manet-aodvv2pkts-00

Abstract

The revised Ad Hoc On-demand Distance Vector (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion, offering rapid convergence in dynamic topologies. This document provides some examples of AODVv2 messages encapsulated into simple packets according to the RFC 5444 specification.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 10, 2015.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Overview

The revised Ad Hoc On-demand Distance Vector (AODVv2) routing protocol [formerly named DYMO] enables on-demand, multihop unicast routing among AODVv2 routers in mobile ad hoc networks [MANETs][RFC2501]. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion, offering rapid convergence in dynamic topologies. This document provides some examples of AODVv2 messages encapsulated into simple packets according to the RFC 5444 specification [RFC5444]).

The basic operations of the AODVv2 protocol are route discovery and route maintenance. Route discovery is performed when an AODVv2 router must transmit a packet towards a destination for which it does not have a route. Route maintenance is performed to avoid prematurely expunging routes from the route table, and to avoid dropping packets when a route breaks. When a data packet is received to be forwarded but there is no valid route for the destination, then the AODVv2 router of the source of the packet is notified via a Route Error (RERR) message.

2. Terminology

This document uses terminology from [RFC5444] and [I-D.ietf-manet-aodvv2], reproduced here for convenience.

AckReq

Request for acknowledgement (of an RREP message).
AODVv2 Router

An IP addressable device in the ad-hoc network that performs the AODVv2 protocol operations specified in this document.
Current_Time

The current time as maintained by the AODVv2 router.
Data Element

A named object used within AODVv2 protocol messages
Disregard

Ignore for further processing.
Invalid route

A route that cannot be used for forwarding.
MANET

A Mobile Ad Hoc Network as defined in [RFC2501].
MetricList

The metrics associated with the addresses in an AddressList.
Node

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 perform any AODVv2 protocol operations.
OrigAddr

An IP address of the Originating Node used as a data element within AODVv2 messages.
OrigAddrMetric

The metric associated with the route to OrigAddr.
OrigSeqNum

The Sequence Number maintained by OrigNode for OrigAddr.
Originating Node (OrigNode)

The Originating Node is the node that launched the application requiring communication with the Target Address.
PktSource

The source address of a packet sent to an unreachable address.
PrefixLengthList

The prefix lengths associated with addresses in an AddressList.
Reactive

A protocol operation is called "reactive" if it is performed only in reaction to specific events. As used in this document, "reactive" is synonymous with "on-demand".
Routable Unicast IP Address

A routable unicast IP address is a unicast IP address that is scoped sufficiently to be forwarded by a router. Globally-scoped unicast IP addresses and Unique Local Addresses (ULAs).[RFC4193] are examples of routable unicast IP addresses.
Route Error (RERR)

A RERR message is used to indicate that an AODVv2 router does not have a route toward one or more particular destinations.
Route Reply (RREP)

A RREP message is used to establish a route between the Target Address and the Originating Address, at all the AODVv2 routers between them.
Route Request (RREQ)

An AODVv2 router uses a RREQ message to discover a valid route to a particular destination address, called the Target Address. An AODVv2 router processing a RREQ receives routing information for the Originating Address.
Router Interface

An interface supporting the transmission or reception of Router Messages.
Sequence Number (SeqNum)

A Sequence Number is an unsigned integer maintained by an AODVv2 router to avoid re-use of stale messages. The router associates SeqNum with an IP address of one or more of its network interfaces. The value zero (0) is reserved to indicate that the Sequence Number for an address is unknown.
SeqNumList

The list of Sequence Numbers associated with addresses in an AddressList, used in RERR messages.
TargAddr

An IP address of the Target Node used as a data element within AODVv2 messages.
TargAddrMetric

The metric associated with the route to TargAddr.
TargSeqNum

The Sequence Number maintained by TargNode for TargAddr.
Target Node (TargNode)

The node hosting the IP address towards which a route is needed.
Type-Length-Value structure (TLV)

A generic way to represent information, for example as used in [RFC5444].
Unreachable Address

An address for which a valid route is not known.
upstream

In the direction from TargAddr to OrigAddr.
Valid route

A route that can be used for forwarding.
ValidityTime

The duration of time for which a route should be considered to be a valid route.





















3. Data Elements and Notational Conventions

This document uses the Data Elements and conventions found in Table 1.

Data Elements Meaning
msg_hop_limit Number of hops allowable for the message
msg_hop_count Number of hops traversed so far by the message
AckReq Acknowledgement Requested for RREP
MetricType The metric type for values in MetricList
PktSource Source address of a data packet
AddressList A list of IP addresses
OrigAddr IP address of the Originating Node
TargAddr IP address of the Target Node
UnreachableAddress An unreachable IP address
PrefixLengthList Routing prefixes associated with addresses in AddressList
SeqNum Sequence Number, used in RERR messages
SeqNumList A list of SeqNums
OrigSeqNum Originating Node Sequence Number
TargSeqNum Target Node Sequence Number
MetricList Metric values for routes to addresses in AddressList
OrigAddrMetric Metric value for route to OrigAddr
TargAddrMetric Metric value for route to TargAddr
ValidityTime Included in ValidityTimeList
ValidityTimeList ValidityTime values for routes to Addresses in AddressList

4. AODVv2 Message Transmission

In its default mode of operation, AODVv2 sends messages using the parameters for port number and IP protocol specified in [RFC5498]. Unless otherwise specified, the address for AODVv2 multicast messages (for example, RREQ or RERR) is the link-local multicast address LL-MANET-Routers [RFC5498]. All AODVv2 routers subscribe to LL-MANET-Routers [RFC5498] to receive AODVv2 messages. The IPv4 TTL (IPv6 Hop Limit) field for all packets containing AODVv2 messages is set to 255. This mechanism, known as "The Generalized TTL Security Mechanism" (GTSM) [RFC5082] helps to assure that packets have not traversed any intermediate routers. IP packets containing AODVv2 protocol messages are given priority queuing and channel access.

5. Example RFC 5444-compliant packet formats

The following subsections show example RFC 5444-compliant packets for AODVv2 message types RREQ, RREP, RERR, and RREP_Ack. These proposed message formats are designed based on expected savings from IPv6 addressable MANET nodes, and a layout for the Address TLVs that may be viewed as natural, even if perhaps not the absolute most compact possible encoding.

For RteMsgs (i.e., RREQ and RREP), the msg-hdr fields are followed by an Address Block, containing OrigAddr and TargAddr. There must be AddrTLVs of type Metric and either OrigSeqNum or TargSeqNum.

There is no MetricType Message TLV present, so the Metric AddrTLV measures HopCount. The Metric Address Block TLV also provides a way for the AODV router generating the RteMsg to supply an initial nonzero cost for the route to its client node (OrigAddr or TargAddr, for RREQ or RREP respectively).

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

     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
    +-+-+-+-+-+-+-+-+
    | PV=0 |  PF=0  |
    +-+-+-+-+-+-+-+-+

Figure 1: RFC 5444 Packet Header

The RFC 5444 header preceding AODVv2 messages in this document has the format illustrated in Figure 1.

The fields in Figure 1 are to be interpreted as follows:

  • PV=0 (Packet Header Version == 0)
  • PF=0 (Packet Flags == 0)

5.1. RREQ Message Format

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | msg-type=RREQ | MF=4  | MAL=3 |          msg-size=28          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | msg-hop-limit |      msg.tlvs-length=0        |   num-addr=2  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|0|0|0|0| Rsv | head-length=3 | Head (bytes for Orig & Target):
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :Head(Orig&Targ)|   Orig.Mid    |  Target.Mid   |addr.TLV.len=11:
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :addr.TLV.len=11|type=OrigSeqNum|0|1|0|1|0|0|Rsv| Index-start=0 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | tlv-length=2  |     Orig.Node Sequence #      |  type=Metric  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|1|0|1|0|0|Rsv| Index-start=0 | tlv-length=1  | OrigAddrHopCt |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Example IPv4 RREQ, with OrigSeqNum and Metric Address Block TLVs

Figure 2 illustrates an example RREQ message format. Figure 2 are to be interpreted as follows:

  • msg-type=RREQ (first [and only] message is of type RREQ)
  • MF:=4 (Message Flags := 4 [only msg-hop-limit field is present])
  • MAL:=3 (Message Address Length indicator [3 for IPv4, 15 for IPv6])
  • msg-size=28 (octets, counting MsgHdr, MsgTLVs, and AddrBlks)
  • msg-hop-limit (initially MAX_HOPCOUNT by default)
  • msg.tlvs-length=0 (no Message TLVs)
  • num-addr=2 (OrigAddr and TargAddr in RteMsg AddrBlock)
  • 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
  • head-length=3 (length of head part of each address is 3 octets)
  • Head (3 initial bytes for both Originating & Target addresses)
  • Orig.Mid (4th byte of Originating Address)
  • Target.Mid (4th byte of Target Address)
  • addr.TLV.len := 11 (length in bytes for OrigSeqNum and Metric TLVs
  • type=OrigSeqNum (type of first AddrBlk TLV, value 2 octets)
  • AddrTLV flags for the OrigSeqNum TLV:
    • 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
  • Index-start=0 (OrigSeqNum TLV value applies at index 0)
  • tlv-length=2 (so there is only one TLV value, [1 = 2/2])
  • Orig.Node Sequence # (TLV value for the OrigSeqNum TLV
  • type=Metric (AddrTLV type of second AddrBlk TLV, values 1 octet)
  • AddrTLV flags for Metric TLV:
    • 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
  • Index-start=0 (Metric TLV values start at index 0)
  • tlv-length=1 (so there is only one TLV value, [1 = 1/1])
  • OrigAddrHopCt (first [and only] TLV value for the Metric TLV)

5.2. RREP Message Format

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | msg-type=RREP | MF=4  | MAL=3 |          msg-size=28          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | msg-hop-limit |      msg.tlvs-length=0        |   num-addr=2  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|0|0|0|0| Rsv | head-length=3 | Head (bytes for Orig & Target):
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :Head(Orig&Targ)|   Orig.Mid    |  Target.Mid   |addr.TLV.len=11:
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :addr.TLV.len=11|type=TargSeqNum|0|1|0|1|0|0|Rsv| Index-start=1 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | tlv-length=2  |     Targ.Node Sequence #      |  type=Metric  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|1|0|1|0|0|Rsv| Index-start=1 | tlv-length=1  | TargAddrHopCt |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Example IPv4 RREP, with TargSeqNum TLV and 1 Metric

Figure 3 illustrates a packet format for an example RREP message.




The fields in Figure 3 are to be interpreted as follows:























  • msg-type=RREP (first [and only] message is of type RREP)
  • MF:=4 (Message Flags = 4 [only msg-hop-limit field is present])
  • MAL:=3 (Message Address Length indicator [3 for IPv4, 15 for IPv6])
  • msg-size=28 (octets, counting MsgHdr, MsgTLVs, and AddrBlks)
  • msg-hop-limit (initially MAX_HOPCOUNT by default)
  • msg.tlvs-length=0 (no Message TLVs)
  • num-addr=2 (OrigAddr and TargAddr in RteMsg AddrBlock)
  • 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
  • head-length=3 (length of head part of each address is 3 octets)
  • Head (3 initial bytes for both Originating & Target addresses)
  • Orig.Mid (4th byte of Originating Address)
  • Target.Mid (4th byte of Target Address)
  • addr.TLV.len = 11 (length in bytes for TargSeqNum TLV and Metric TLV
  • type=TargSeqNum (type of first AddrBlk TLV, value 2 octets)
  • AddrTLV flags for the TargSeqNum TLV:
    • 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
  • Index-start=1 (TargSeqNum TLV value applies to address at index 1)
  • tlv-length=2 (there is one TLV value, 2 bytes in length)
  • Targ.Node Sequence # (value for the TargSeqNum TLV)
  • type=Metric (AddrTLV type of second AddrBlk TLV, value 1 octet)
  • AddrTLV flags for the Metric TLV [01010000, same as for TargSeqNum TLV]
  • Index-start=1 (Metric TLV values start at index 1)
  • tlv-length=1 (there is one TLV value, 1 byte in length)
  • TargAddrHopCt (first [and only] TLV value for Metric TLV)

5.3. RERR Message Format

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | msg-type=RERR | MF=4  | MAL=3 |          msg-size=24          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | msg-hop-limit |      msg.tlvs-length=0        |   num-addr=2  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|0|0|0|0| Rsv | head-length=3 | Head (for both destinations)  :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :Head (3rd byte)|  Mid (Dest_1) | Mid (Dest_2)  | addr.TLV.len=7:
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :addr.TLV.len=7 |  type=SeqNum  |0|0|1|1|0|1|Rsv| tlv-length=4  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Dest_1 Sequence #      |        Dest_2 Sequence #      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: Example IPv4 RERR with Two UnreachableAddresses

Figure 4 illustrates an example RERR message format. Figure 4 are to be interpreted as follows:

  • msg-type=RERR (first [and only] message is of type RERR)
  • MF:=4 (Message Flags = 4 [only msg-hop-limit field is present])
  • MAL:=3 (Message Address Length indicator [3 for IPv4, 15 for IPv6])
  • msg-size=24 (octets, counting MsgHdr, MsgTLVs, and AddrBlks)
  • msg-hop-limit (initially MAX_HOPCOUNT by default)
  • msg.tlvs-length=0 (no Message TLVs)
  • num-addr=2 (OrigAddr and TargAddr in RteMsg AddrBlock)
  • AddrBlk flags == 10000000 [same as RREQ and RREP AddrBlk examples]
  • head-length=3 (length of head part of each address is 3 octets)
  • Head (3 initial bytes for both UnreachableAddresses, Dest_1 and Dest_2)
  • Dest_1.Mid (4th byte of Dest_1 IP address)
  • Dest_2.Mid (4th byte of Dest_2 IP address)
  • addr.TLV.len = 7 (length in bytes for SeqNum TLV
  • type=SeqNum (AddrTLV type of AddrBlk TLV, values 2 octets each)
  • AddrTLV flags for SeqNum TLV:
    • 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
  • tlv-length=4 (so there are two TLV values, [2 = 4/2])
  • Dest_1 Sequence # (first of two TLV values for the SeqNum TLV)
  • Dest_2 Sequence # (second of two TLV values for the SeqNum TLV)

5.4. RREP_Ack Message Format

The figure below illustrates a packet format for an example RREP_Ack message. 

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |msgtype=RREPAck| MF=0  | MAL=3 |          msg-size=4           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: Example IPv4 RREP_Ack






The fields in Figure 3 are to be interpreted as follows:

  • msg-type=RREPAck (first [and only] message is of type RREP_Ack)
  • MF:=0 (Message Flags = 0 [no field is present])
  • MAL:=3 (Message Address Length indicator [3 for IPv4, 15 for IPv6])
  • msg-size=4

6. Informative References

[I-D.ietf-manet-aodvv2] Perkins, C., Ratliff, S., Dowdell, J., Steenbrink, L. and V. Mercieca, "Dynamic MANET On-demand (AODVv2) Routing", Internet-Draft draft-ietf-manet-aodvv2-07, March 2015.
[RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P. and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
[RFC5444] Clausen, T., Dearlove, C., Dean, J. and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, February 2009.
[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, March 2009.
[RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols", RFC 5498, March 2009.

Author's Address

Charles E. Perkins Futurewei Inc. 2330 Central Expressway Santa Clara, CA 95050 USA Phone: +1-408-330-4586 EMail: charliep@computer.org