One document matched: draft-perkins-manet-aodvv2pkts-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!--
==================================== 80 ========================================
==================================== 72 ================================
-->
<!--
Check for lines containing the string "CEP".
Also for lines containing the string "JPD" (John Dowdell 20140827)
-->
<rfc category="std" docName="draft-perkins-manet-aodvv2pkts-00"
ipr="trust200902">
<front>
<title abbrev="AODVv2">AODVv2 Example RFC 5444 Packets</title>
<author fullname="Charles E. Perkins" initials="C.E." surname="Perkins">
<organization abbrev="Futurewei">Futurewei Inc. </organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<code>95050</code>
<region>CA</region>
<country>USA</country>
</postal>
<phone>+1-408-330-4586</phone>
<email>charliep@computer.org</email>
</address>
</author>
<date/>
<area>Routing</area>
<workgroup>Mobile Ad hoc Networks Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>reactive protocol</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Overview">
<t> 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]<xref target="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 <xref target="RFC5444"/>).</t>
<t> 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. </t>
</section>
<section title="Terminology">
<t>This document
uses terminology from <xref target="RFC5444"/> and
<xref target="I-D.ietf-manet-aodvv2"/>, reproduced here for
convenience.
<list style="hanging">
<t hangText="AckReq"><vspace/>
Request for acknowledgement (of an RREP message).</t>
<t hangText="AODVv2 Router"><vspace/>
An IP addressable device in the ad-hoc network that performs the AODVv2
protocol operations specified in this document.</t>
<t hangText="Current_Time"><vspace/>
The current time as maintained by the AODVv2 router.
<!-- [JPD] Need to have a discussion of time somewhere in the text.
If no security, only need locally scoped time. Add security, and you
need globally scoped time to support SSL etc -->
<!-- CEP: It would be wrong to require NTP for ad hoc networks -->
<!-- JPD: Completely agree, but to maintain security should we say that
some method of acquiring time either locally (eg from GPS) or remotely
(eg NTP or tlsdate) is necessary? I think it would be wrong to mandate
a particular method but I believe we need to say something --> </t>
<t hangText="Data Element"><vspace/>
A named object used within AODVv2 protocol messages</t>
<t hangText="Disregard"><vspace/>
Ignore for further processing.
<!-- CEP: Issue number goes here
, and discard unless it is
required to keep the message in the packet for purposes
of authentication. --> </t>
<!-- CEP: Look for the string "CEP" and insert Issue #s as needed... -->
<!-- downstream never appears in the text, and there was a complaint about it.
<t hangText="downstream"><vspace/>
In the direction from OrigAddr to TargAddr.</t>
-->
<t hangText="Invalid route"><vspace/>
A route that cannot be used for forwarding.</t>
<t hangText="MANET"><vspace/>
A Mobile Ad Hoc Network as defined in <xref target="RFC2501"/>.</t>
<t hangText="MetricList"><vspace/>
The metrics associated with the addresses in an AddressList.</t>
<t hangText="Node"><vspace/>
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. </t>
<t hangText="OrigAddr"><vspace/> An IP address of the Originating Node
used as a data element within AODVv2 messages.</t>
<t hangText="OrigAddrMetric"><vspace/>The metric associated with
the route to OrigAddr.</t>
<t hangText="OrigSeqNum"><vspace/>The Sequence Number maintained
by OrigNode for OrigAddr.</t>
<t hangText="Originating Node (OrigNode)"><vspace/>
The Originating Node is the node that launched the application
requiring communication with the Target Address.
</t>
<t hangText="PktSource"><vspace/>
The source address of a packet sent to an unreachable address.</t>
<t hangText="PrefixLengthList"><vspace/>
The prefix lengths associated with addresses in an AddressList.</t>
<t hangText="Reactive"><vspace/> 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". </t>
<!-- word "essentially" deleted, either synonymous or not -->
<!-- [CEP] Well, O.K., but no two words are absolutely synonymous. -->
<t hangText="Routable Unicast IP Address"><vspace/>
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).<xref target="RFC4193"/>
<!-- [JPD] ULAs are NOT globally routable -->
<!-- [CEP] That is true, but they *are* routable unicast addresses -->
are examples of routable unicast IP addresses.</t>
<!-- [CEP] Can a node determine whether an address is multihop-capable? -->
<t hangText="Route Error (RERR)"><vspace/>
A RERR message is used to indicate that an AODVv2 router does not
have a route toward one or more particular destinations.
</t>
<t hangText="Route Reply (RREP)"><vspace/>
A RREP message is used to establish a route between <!-- RREQ -->
the Target Address and the Originating Address, at all the AODVv2
routers between them.</t>
<t hangText="Route Request (RREQ)"><vspace/>
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.</t>
<t hangText="Router Interface"><vspace/>An interface supporting the
transmission or reception of Router Messages.</t>
<t hangText="Sequence Number (SeqNum)"><vspace/>
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.</t>
<t hangText="SeqNumList"><vspace/>
The list of Sequence Numbers associated with addresses in an AddressList,
used in RERR messages.
</t>
<t hangText="TargAddr"><vspace/> An IP address of the Target Node
used as a data element within AODVv2 messages.</t>
<t hangText="TargAddrMetric"><vspace/>The metric associated with
the route to TargAddr.</t>
<t hangText="TargSeqNum"><vspace/> The Sequence Number maintained
by TargNode for TargAddr.</t>
<t hangText="Target Node (TargNode)"><vspace/>
The node hosting the IP address towards which a route is needed.</t>
<t hangText="Type-Length-Value structure (TLV)"><vspace/>
A generic way to represent information, for example as used
in <xref target="RFC5444"/>.</t>
<t hangText="Unreachable Address"><vspace/>
An address for which a valid route is not known.</t>
<t hangText="upstream"><vspace/>
In the direction from TargAddr to OrigAddr.</t>
<t hangText="Valid route"><vspace/>
A route that can be used for forwarding.</t>
<t hangText="ValidityTime"><vspace/> The duration of time for which a
route should be considered to be a valid route.</t>
</list></t>
<t><vspace blankLines="19"/></t>
</section>
<section anchor="notation" title="Data Elements and Notational Conventions">
<t>This document uses the Data Elements and conventions found in
<xref target="data-elements"/>.</t>
<texttable anchor="data-elements">
<ttcol align="left" width="20%">Data Elements</ttcol>
<ttcol align="left">Meaning</ttcol>
<c>msg_hop_limit</c> <c>Number of hops allowable for the message</c>
<c>msg_hop_count</c> <c>Number of hops traversed so far by the message</c>
<c>AckReq</c> <c>Acknowledgement Requested for RREP</c>
<c>MetricType</c> <c>The metric type for values in MetricList</c>
<c>PktSource</c> <c>Source address of a data packet</c>
<c>AddressList</c> <c>A list of IP addresses</c>
<c>OrigAddr</c> <c>IP address of the Originating Node</c>
<c>TargAddr</c> <c>IP address of the Target Node</c>
<c>UnreachableAddress</c> <c>An unreachable IP address</c>
<c>PrefixLengthList</c>
<c>Routing prefixes associated with addresses in AddressList</c>
<c>SeqNum</c> <c>Sequence Number, used in RERR messages</c>
<c>SeqNumList</c> <c>A list of SeqNums</c>
<c>OrigSeqNum</c> <c>Originating Node Sequence Number</c>
<c>TargSeqNum</c> <c>Target Node Sequence Number</c>
<c>MetricList</c>
<c>Metric values for routes to addresses in AddressList</c>
<c>OrigAddrMetric</c> <c>Metric value for route to OrigAddr</c>
<c>TargAddrMetric</c> <c>Metric value for route to TargAddr</c>
<c>ValidityTime</c> <c>Included in ValidityTimeList</c>
<c>ValidityTimeList</c> <c>ValidityTime values for routes
to Addresses in AddressList</c>
</texttable>
</section>
<!-- ============================================================= -->
<section anchor="MsgXmit" title="AODVv2 Message Transmission">
<t> In its default mode of operation, AODVv2 sends messages using the
parameters for port number and IP protocol specified in
<xref target="RFC5498"/>. Unless otherwise specified, the address for
AODVv2 multicast messages (for example, RREQ or RERR) is the link-local
multicast address LL-MANET-Routers <xref target="RFC5498"/>.
All AODVv2 routers
subscribe to LL-MANET-Routers <xref target="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) <xref target="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.</t>
</section>
<section anchor="rfc5444-formats"
title="Example RFC 5444-compliant packet formats">
<t> 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.</t>
<t> 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.
</t>
<t>
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). </t>
<t> 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 <xref target="RFC5444"/>.</t>
<t> The RFC 5444 header preceding AODVv2 messages in this document
has the format illustrated in <xref target="fig5444_header"/>.
<figure anchor="fig5444_header" title="RFC 5444 Packet Header">
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+
]]></artwork>
<!-- <postamble></postamble> -->
</figure>
<vspace blankLines="1"/>
The fields in <xref target="fig5444_header"/> are to be interpreted
as follows:
<?rfc compact="yes" ?> <!-- conserve vertical whitespace -->
<?rfc subcompact="yes" ?> <!-- don't keep a blank line between list items -->
<list style="symbols">
<t>PV=0 (Packet Header Version == 0)</t>
<t>PF=0 (Packet Flags == 0)</t>
</list>
</t>
<section anchor="RREQ-format" title="RREQ Message Format">
<t><xref target="figRREQ"/> illustrates an example RREQ message format.
<figure anchor="figRREQ"
title="Example IPv4 RREQ, with OrigSeqNum and Metric Address Block TLVs">
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<!-- <postamble></postamble> -->
</figure>
<!-- <vspace blankLines="2" /> -->
The fields in <xref target="figRREQ"/> are to be interpreted as follows:
<?rfc compact="yes" ?> <!-- conserve vertical whitespace -->
<?rfc subcompact="yes" ?> <!-- don't keep a blank line between list items -->
<list style="symbols">
<t>msg-type=RREQ (first [and only] message is of type RREQ)</t>
<t>MF:=4 (Message Flags := 4 [only msg-hop-limit field is present])</t>
<t>MAL:=3 (Message Address Length indicator [3 for IPv4, 15 for IPv6])</t>
<t>msg-size=28 (octets, counting MsgHdr, MsgTLVs, and AddrBlks)</t>
<t>msg-hop-limit (initially MAX_HOPCOUNT by default)</t>
<t>msg.tlvs-length=0 (no Message TLVs)</t>
<t>num-addr=2 (OrigAddr and TargAddr in RteMsg AddrBlock)</t>
<t>AddrBlk flags:
<list style="symbols">
<t>bit 0 (ahashead): 1</t>
<t>bit 1 (ahasfulltail): 0</t>
<t>bit 2 (ahaszerotail): 0</t>
<t>bit 3 (ahassingleprelen): 0</t>
<t>bit 4 (ahasmultiprelen): 0</t>
<t>bits 5-7: RESERVED</t>
</list></t>
<t>head-length=3 (length of head part of each address is 3 octets)</t>
<t>Head
(3 initial bytes for both Originating & Target addresses)</t>
<t>Orig.Mid (4th byte of Originating Address)</t>
<t>Target.Mid (4th byte of Target Address)</t>
<t>addr.TLV.len := 11 (length in bytes for OrigSeqNum and Metric TLVs</t>
<t>type=OrigSeqNum (type of first AddrBlk TLV, value 2 octets)</t>
<t>AddrTLV flags for the OrigSeqNum TLV:
<list style="symbols">
<t>bit 0 (thastypeext): 0</t>
<t>bit 1 (thassingleindex): 1</t>
<t>bit 2 (thasmultiindex): 0</t>
<t>bit 3 (thasvalue): 1</t>
<t>bit 4 (thasextlen): 0</t>
<t>bit 5 (tismultivalue): 0</t>
<t>bits 6-7: RESERVED</t>
</list></t>
<t>Index-start=0 (OrigSeqNum TLV value applies at index 0)</t>
<t>tlv-length=2 (so there is only one TLV value, [1 = 2/2])</t>
<t>Orig.Node Sequence # (TLV value for the OrigSeqNum TLV</t>
<t>type=Metric (AddrTLV type of second AddrBlk TLV, values 1 octet)</t>
<t>AddrTLV flags for Metric TLV:
<list style="symbols">
<t>bit 0 (thastypeext): 0</t>
<t>bit 1 (thassingleindex): 1</t>
<t>bit 2 (thasmultiindex): 0</t>
<t>bit 3 (thasvalue): 1</t>
<t>bit 4 (thasextlen): 0</t>
<t>bit 5 (tismultivalue): 0</t>
<t>bits 6-7: RESERVED</t>
</list></t>
<t>Index-start=0 (Metric TLV values start at index 0)</t>
<t>tlv-length=1 (so there is only one TLV value, [1 = 1/1])</t>
<t>OrigAddrHopCt (first [and only] TLV value for the Metric TLV)</t>
</list>
</t>
</section>
<section anchor="RREP-format" title="RREP Message Format">
<t><xref target="RREPstruct"/> illustrates a packet format for
an example RREP message.
<figure anchor="RREPstruct"
title="Example IPv4 RREP, with TargSeqNum TLV and 1 Metric">
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<!-- <postamble></postamble> -->
</figure>
<vspace blankLines="4"/>
The fields in <xref target="RREPstruct"/> are to be interpreted as follows:
<list style="symbols">
<t>msg-type=RREP (first [and only] message is of type RREP)</t>
<t>MF:=4 (Message Flags = 4 [only msg-hop-limit field is present])</t>
<t>MAL:=3 (Message Address Length indicator [3 for IPv4, 15 for IPv6])</t>
<t>msg-size=28 (octets, counting MsgHdr, MsgTLVs, and AddrBlks)</t>
<t>msg-hop-limit (initially MAX_HOPCOUNT by default)</t>
<t>msg.tlvs-length=0 (no Message TLVs)</t>
<t>num-addr=2 (OrigAddr and TargAddr in RteMsg AddrBlock)</t>
<t>AddrBlk flags:
<list style="symbols">
<t>bit 0 (ahashead): 1</t>
<t>bit 1 (ahasfulltail): 0</t>
<t>bit 2 (ahaszerotail): 0</t>
<t>bit 3 (ahassingleprelen): 0</t>
<t>bit 4 (ahasmultiprelen): 0</t>
<t>bits 5-7: RESERVED</t>
</list></t>
<t>head-length=3 (length of head part of each address is 3 octets)</t>
<t>Head
(3 initial bytes for both Originating & Target addresses)</t>
<t>Orig.Mid (4th byte of Originating Address)</t>
<t>Target.Mid (4th byte of Target Address)</t>
<t>addr.TLV.len = 11
(length in bytes for TargSeqNum TLV and Metric TLV</t>
<t>type=TargSeqNum (type of first AddrBlk TLV, value 2 octets)</t>
<t>AddrTLV flags for the TargSeqNum TLV:
<list style="symbols">
<t>bit 0 (thastypeext): 0</t>
<t>bit 1 (thassingleindex): 1</t>
<t>bit 2 (thasmultiindex): 0</t>
<t>bit 3 (thasvalue): 1</t>
<t>bit 4 (thasextlen): 0</t>
<t>bit 5 (tismultivalue): 0</t>
<t>bits 6-7: RESERVED</t>
</list></t>
<t>Index-start=1
(TargSeqNum TLV value applies to address at index 1)</t>
<t>tlv-length=2 (there is one TLV value, 2 bytes in length)</t>
<t>Targ.Node Sequence # (value for the TargSeqNum TLV)</t>
<t>type=Metric (AddrTLV type of second AddrBlk TLV, value 1 octet)</t>
<t>AddrTLV flags for the Metric TLV
[01010000, same as for TargSeqNum TLV]</t>
<t>Index-start=1 (Metric TLV values start at index 1)</t>
<t>tlv-length=1 (there is one TLV value, 1 byte in length)</t>
<t>TargAddrHopCt (first [and only] TLV value for Metric TLV)</t>
</list>
<vspace blankLines="23"/>
</t>
</section>
<section anchor="RERR-format" title="RERR Message Format">
<t><xref target="figRERR"/> illustrates an example RERR
message format.
<figure anchor="figRERR"
title="Example IPv4 RERR with Two UnreachableAddresses">
<artwork><![CDATA[
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 # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<!-- <postamble>RERR </postamble> -->
</figure>
The fields in <xref target="figRERR"/> are to be interpreted as follows:
<list style="symbols">
<t>msg-type=RERR (first [and only] message is of type RERR)</t>
<t>MF:=4 (Message Flags = 4 [only msg-hop-limit field is present])</t>
<t>MAL:=3 (Message Address Length indicator [3 for IPv4, 15 for IPv6])</t>
<t>msg-size=24 (octets, counting MsgHdr, MsgTLVs, and AddrBlks)</t>
<t>msg-hop-limit (initially MAX_HOPCOUNT by default)</t>
<t>msg.tlvs-length=0 (no Message TLVs)</t>
<t>num-addr=2 (OrigAddr and TargAddr in RteMsg AddrBlock)</t>
<t>AddrBlk flags == 10000000
[same as RREQ and RREP AddrBlk examples]</t>
<t>head-length=3 (length of head part of each address is 3 octets)</t>
<t>Head
(3 initial bytes for both UnreachableAddresses, Dest_1 and Dest_2)</t>
<t>Dest_1.Mid (4th byte of Dest_1 IP address)</t>
<t>Dest_2.Mid (4th byte of Dest_2 IP address)</t>
<t>addr.TLV.len = 7 (length in bytes for SeqNum TLV</t>
<t>type=SeqNum (AddrTLV type of AddrBlk TLV, values 2 octets each)</t>
<t>AddrTLV flags for SeqNum TLV:
<list style="symbols">
<t>bit 0 (thastypeext): 0</t>
<t>bit 1 (thassingleindex): 0</t>
<t>bit 2 (thasmultiindex): 1</t>
<t>bit 3 (thasvalue): 1</t>
<t>bit 4 (thasextlen): 0</t>
<t>bit 5 (tismultivalue): 1</t>
<t>bits 6-7: RESERVED</t>
</list></t>
<t>tlv-length=4 (so there are two TLV values, [2 = 4/2])</t>
<t>Dest_1 Sequence # (first of two TLV values for the SeqNum TLV)</t>
<t>Dest_2 Sequence # (second of two TLV values for the SeqNum TLV)</t>
</list>
</t>
</section>
<!-- Removed: issue #40 -->
<section anchor="RREP_Ack-format" title="RREP_Ack Message Format">
<t>The figure below illustrates a packet format for an example
RREP_Ack message. </t>
<t><figure anchor="figRREPAk" title="Example IPv4 RREP_Ack">
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<!--| Targ.Node Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-->
<vspace blankLines="4"/>
The fields in <xref target="RREPstruct"/> are to be interpreted as follows:
<list style="symbols">
<t>msg-type=RREPAck (first [and only] message is of type RREP_Ack)</t>
<t>MF:=0 (Message Flags = 0 [no field is present])</t>
<t>MAL:=3 (Message Address Length indicator [3 for IPv4, 15 for IPv6])</t>
<t>msg-size=4</t>
<!-- <t>msg.tlvs-length=0 (no Message TLVs)</t> -->
</list>
</t>
</section>
<!-- End removed section: issue #40 -->
</section>
</middle>
<back>
<references title="Informative References">
<?rfc include="reference.RFC.4193" ?>
<?rfc include="reference.RFC.5082" ?>
<?rfc include="reference.RFC.5444" ?>
<?rfc include="reference.RFC.5497" ?>
<?rfc include="reference.RFC.5498" ?>
<?rfc include="reference.RFC.2501" ?>
<?rfc include="reference.I-D.ietf-manet-aodvv2" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:24:48 |