One document matched: draft-perkins-irrep-02.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"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict='yes'?>
<rfc category="std" docName="draft-perkins-irrep-02" ipr="trust200902">
<front>
<title abbrev="Intermediate RREP">
Intermediate RREP for dynamic MANET On-demand (AODVv2) Routing</title>
<author fullname="Charles E. Perkins" initials="C.E." surname="Perkins">
<organization abbrev="Futurewei">Futurewei Inc.</organization>
<address>
<postal>
<street>3300 Central Expressway</street>
<city>Santa Clara</city>
<code>95053</code>
<region>CA</region>
<country>USA</country>
</postal>
<phone>+1-408-330-5305</phone>
<email>charliep@computer.org</email>
</address>
</author>
<author fullname="Ian D Chakeres" initials="I.D." surname="Chakeres">
<organization>CenGen</organization>
<address>
<postal>
<street>9250 Bendix Road North</street>
<city>Columbia</city>
<region>Maryland</region>
<code>21045</code>
<country>USA</country>
</postal>
<email>ian.chakeres@gmail.com</email>
<uri>http://www.ianchak.com/</uri>
</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</keyword>
<keyword>RREP</keyword>
<abstract>
<t>The Dynamic MANET On-demand (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 on-demand
convergence in dynamic topologies. This document specifies
an extension to AODVv2 (and possibly other reactive routing
protocols) enabling intermediate nodes to shorten route
discovery times.</t>
</abstract>
</front>
<middle>
<section title="Overview">
<t>The Dynamic MANET On-demand (AODVv2) routing protocol enables
on-demand, multihop unicast routing among participating AODVv2
routers. The basic operations of the AODVv2 protocol are route
discovery and route maintenance. Route discovery is performed by
an AODVv2 router when one of its clients transmits a packet towards
a destination for which the router does not have a route.</t>
<t>During route discovery, the originator's AODVv2 router (i.e., OrigRtr)
initiates flooding of a Route Request (RREQ) throughout the
network to find a route to a particular destination, via the AODVv2
router (i.e., TargRtr) responsible for that destination. During this
hop-by-hop flooding process, each intermediate AODVv2 router
records a route to the originator (i.e., OrigNode). If an
intermediate router has a route to the destination requested
(i.e., TargNode) in the RREQ, it may
(by following the specification in this document) supply that
routing information to the originator of the RREQ. Such an
RREP message is termed an "Intermediate RREP" (iRREP).
The Intermediate router (i.e., InterRtr) also forwards another
RREP message, termed an "Unsolicited RREP" (uRREP),
to the requested destination. The Unsolicited RREP supplies
TargRtr and other intermediate routers with a route towards OrigNode.
When OrigRtr receives the iRREP, and TargRtr receives the uRREP,
a bi-directional route is established between OrigRtr and TargRtr.</t>
<t>In this document, RREQ always refers to the incoming RREQ
message received by InterRtr.
OrigRtr, OrigNode, TargRtr, and TargNode always refer to
the nodes as defined in <xref target="I-D.ietf-manet-dymo"/>;
they are named from the context of the AODVv2 router
originating the RREQ message (OrigRtr).
</t>
<t>Intermediate RREQ is particularly effective in conjunction with
the use of "expanding rings multicast", which is specified as
an optional feature in <xref target="I-D.ietf-manet-dymo" />.
Together, these two features enable a simple "route repair"
mechanism. When a route breaks somewhere near the packet source
(i.e., Originating Router), OrigRtr MAY limit the flooding of a
RREQ using expanding rings multicast. Then, nearby AODVv2
routers can in many situations use iRREP to supply a new
route to the desired destination. Nearness of the
broken link relative to OrigRtr can be measured by the
<msg-hop-count> field of the RERR message (if included)
indicating that a route has broken.
</t>
<t>When InterRtr receives an RREQ, it first uses the information
in the RREQ to update any relevant route table entries.
Then, if InterRtr is able to generate an iRREP to satisfy the
RREQ, it uses the up-to-date information in its route table to
assign proper values to the fields of the iRREP (and uRREP).
In this way, message processing for the outgoing RREP
messages may be viewed as isolated from the message processing
for the incoming RREQ message.
</t>
</section>
<section title="Terminology and Notation">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described
in <xref target="RFC2119" />.
Additionally, this document uses some terminology and notation from
<xref target="RFC5444" /> and <xref target="I-D.ietf-manet-dymo" />,
duplicated here for convenience.</t>
<t><list style="hanging">
<t hangText="AODVv2 Sequence Number (SeqNum)"><vspace />An AODVv2
Sequence Number is maintained by each AODVv2 router
process. This sequence number is used by other AODVv2 routers
to identify the temporal order of routing information
generated and ensure loop-free routes.</t>
<t hangText="Intermediate Route Reply (iRREP)"><vspace />
A RREP message that is originated by an AODVv2 router that
is not TargRtr.</t>
<t hangText="Intermediate Router (InterRtr)"><vspace />
An AODVv2 router along a route between OrigRtr and TargRtr
that itself is not OrigRtr or TargRtr.</t>
<t hangText="Originating Node (OrigNode)"><vspace /> The
Originating Node is the source of a data packet that
its AODVv2 router has to deliver. </t>
<t hangText="Originating Router (OrigRtr)"><vspace /> The
AODVv2 router that provides network connectivity to the
Originating Node (OrigNode). OrigRtr creates a
AODVv2 control message (namely, RREQ) on behalf of OrigNode
to discover a route to communications endpoints as required by
applications running on OrigNode. </t>
<t hangText="Route Reply (RREP)"><vspace />A RREP message is used to supply
routing information about the TargNode to OrigRtr and the
intermediate AODVv2 routers between them.</t>
<t hangText="Route Request (RREQ)"><vspace />A RREQ message is used to
discover a valid route to a particular destination address, called
the RREQ TargNode. When an AODVv2 router processes a RREQ, it
acquires routing information on how to reach the RREQ OrigNode.</t>
<t hangText="Router Client"><vspace />An AODVv2 router may
be configured with a list of other IP addresses and networks
which correspond to other non-router nodes which require
the services of the AODVv2 router for route discovery and
maintenance. An AODVv2 is always its own client, so that
the list of client IP addresses is never empty.
</t>
<t hangText="Target Node (TargNode)"><vspace />The
Target Node is the ultimate destination of a data packet,
and the node for which a route discovery may be attempted
by OrigRtr.</t>
<t hangText="Target Router (TargRtr)"><vspace />
TargRtr is the AODVv2 router providing connectivity for TargNode;
in other words, TargNode is a router client of TargRtr.</t>
<t hangText="Unsolicited Route Reply (uRREP)"><vspace />
An unsolicited RREP message is originated by an AODVv2 router, not
in response to an RREQ message by the uRREP destination.
uRREP is also sometimes called "Gratuitous RREP".</t>
</list></t>
<texttable anchor="notational-conventions">
<ttcol align="center">Notation</ttcol>
<ttcol align="center">Meaning</ttcol>
<c>Route[Dest]</c> <c>A route (or route table entry) to Dest</c>
<c>Route[Dest].{field}</c> <c>A field in the route table entry</c>
<c>RREP.{field}</c> <c>Field in RREP</c>
<c> -- </c> <!-- blank line --> <c> -- </c>
<c>MsgHdr</c> <c>the RFC5444 Message Header</c>
<c>MsgTLV</c> <c>an RFC5444 Message TLV</c>
<c>HopLimit</c> <c>MsgHdr.<msg-hop-limit></c>
<c> -- </c> <!-- RFC 5444 Address Block and TLV fields --> <c> -- </c>
<c>AddrBlk</c> <c>an RFC5444 address block</c>
<c>AddrBlk[1]</c> <c>The first address slot in AddrBlk</c>
<c>AddrBlk[N]</c> <c>The Nth address slot in AddrBlk</c>
<c>AddrBlk[i].{field}</c> <c>{field} value for AddrBlk[i]</c>
<c>AddrBlk[OrigNode]</c> <c>AddrBlk[1]</c>
<c>AddrBlk[TargNode]</c> <c>AddrBlk[2]</c>
<c>AddrBlk[uOrigNode]</c> <c>AddrBlk[1]</c>
<c>AddrBlk[uTargNode]</c> <c>AddrBlk[2]</c>
<c>RREP.PfxLen[i]</c> <c>same as RREP.AddrBlk[i].PfxLen</c>
<!--
<c>RREQ.{field}</c> <c>Field in RREQ</c>
<c>AddrTLV</c> <c>an RFC5444 address block TLV</c>
<c>AddrTLV[1]</c> <c>the first item in AddrTLV</c>
<c>AddrTLV[N]</c> <c>the Nth item in AddrTLV</c>
<c>AddrTLV[OrigNode]</c> <c>AddrTLV[1]</c>
<c>AddrTLV[TargNode]</c> <c>AddrTLV[2]</c>
-->
<c>HopCountTLV</c> <c>HopCount TLV for AddrBlk addresses</c>
<c>SeqNumTLV</c> <c>Sequence Number TLV for AddrBlk addresses</c>
<c> -- </c> <!-- Types of Nodes --> <c> -- </c>
<c>OrigRtr</c> <c>RREQ Originating Router</c>
<c>OrigNode</c> <c>Originating Node</c>
<c>InterRtr</c> <c>Intermediate AODVv2 Router</c>
<c>TargRtr</c> <c>Target Router</c>
<c>TargNode</c> <c>Target Node</c>
<c>uOrigNode</c> <c>IP address in the "OrigNode" uRREP slot</c>
<c>uTargNode</c> <c>IP address in the "TargNode" uRREP slot</c>
</texttable>
<t>
Note that <xref target="notational-conventions"/> treats
AddrBlk and TLV array values as if indexed starting with
1 instead of 0, in contrast to RFC 5444 <xref target="RFC5444"/>.
</t>
</section>
<section title="Unknown Prefix Convention">
<t>
In this specification, it is possible that one of the two
addresses in the specified RREP AddrBlks has a known
<prefix-length> value, but the other address does not.
In such cases, a <prefix-length> value block MUST be supplied
even though only one <prefix-length> is known. Since
RFC 5444 requires the <prefix-length>s to be supplied for
both addresses, in this document any unknown <prefix-length>
in an RFC 5444 AddrBlk MUST be assigned the value of 0. Such a
value for the prefix length is not meaningful, and MUST NOT be
stored as the prefix length in any route table entry.
</t>
</section>
<section anchor="Int_RREP_operation"
title="Intermediate and Unsolicited RREP">
<t>If an intermediate AODVv2 router (InterRtr) has a Route that can satisfy
an incoming RREQ, it MAY respond with an Intermediate RREP (iRREP).
As usual with any incoming RteMsg, InterRtr first updates its route
table using the information contained in the RREQ. For instance,
a route to OrigNode may be created. After the incoming route
update information is applied, InterRtr has valid routes to
both RREQ.OrigNode and RREQ.TargNode (namely, Route[OrigNode] and
Route[TargNode] respectively).
</t>
<t>InterRtr SHOULD also issue a RREP to
the RREQ TargNode, so that the RREQ TargNode receives
routing information on how to reach the RREQ OrigNode.
This RREP sent towards the RREQ TargNode is known as
an "Unsolicited RREP" (uRREP). Each AODVv2 router between
InterRtr and TargRtr that receives the uRREP,
uses the uRREP information to update their route table entry
for OrigNode. The uRREP is constructed as if it had been
transmitted in response to a route discovery initiated by TargRtr
to discover a route for OrigNode.
</t>
<t>The following conditions must be satisfied before the
intermediate router (InterRtr) can transmit iRREP and uRREP.
<list style="symbols">
<t>InterRtr is not TargRtr</t>
<t>RREQ does not contain the DestOnly message TLV</t>
<t>InterRtr has a valid route for TargNode, namely Route[TargNode]</t>
<t>Route[TargNode].SeqNum ≥ RREQ.SeqNumTLV[TargNode]
(using signed 16-bit arithmetic)</t>
</list>
</t>
<section anchor="Int_RREP"
title="Intermediate RREP Generation">
<t> The fields of the iRREP are assigned as follows.
<list style="symbols">
<!-- style="hanging" -->
<!-- hangText="whatever" -->
<t>IP.DestinationAddr := Route[OrigNode].NextHop</t>
<t>iRREP.HopLimit := Route[OrigNode].HopCount</t>
<t>iRREP.AddrBlk[OrigNode] := Route[OrigNode].Addr</t>
<t>iRREP.AddrBlk[TargNode] := Route[TargNode].Addr</t>
<t>iRREP.SeqNumTLV[OrigNode] := Route[OrigNode].SeqNum</t>
<t>iRREP.SeqNumTLV[TargNode] := Route[TargNode].Seqnum</t>
<t>iRREP.HopCountTLV[TargNode] := Route[TargNode].HopCount</t>
<t>If Route[TargNode].PfxLen is equal to 0, or the number of bits in
the addresses of the RREQ (32 for IPv4, 128 for IPv6),
then no <prefix-length> is included with the iRREP.
Otherwise,
<list>
<t>iRREP.PfxLen[TargNode] := Route[TargNode].PfxLen</t>
<t>iRREP.PfxLen[OrigNode] := 0</t>
</list></t>
<t>iRREP.VALIDITY_TIME[TargNode] := <vspace />
(ACTIVE_INTERVAL+MAX_IDLETIME) - (Current_Time-Route.LastUsed)</t>
</list></t>
<t>No prefix length is needed for OrigNode, but due to RFC 5444 format
requirements, RREP.PfxLen[OrigNode] must be included
if RREP.PfxLen[TargNode] is included. In that case,
RREP.PfxLen[OrigNode] = 0. Therefore either 0 or two
<prefix-length> values are included with iRREP.AddrBlk.
The VALIDITY_TIME TLV has exactly one (1) element, which
is the remaining time before the route to TargNode expires.
Since the route is a valid route, this is a positive number.</t>
</section>
<section anchor="Unsol_RREP"
title="Unsolicited RREP Generation">
<!--
<t> The uRREP message TLV (see <xref target="msgtlvtypes"/>)
MUST be included in the uRREP.</t>
-->
<t>Since the uRREP is intended to fulfill the function of an RREP response
to an fictional RREQ message for discovering a route to OrigNode,
the order of the addresses in the uRREP AddrBlk has to be reversed.
In other words, RREQ.OrigNode has to be the IP address in the
"TargNode" slot of the uRREP, and would have been the "TargNode"
in the fictional RREQ message to which the uRREP
is fictionally responding.
To reduce confusion, the IP address in the "OrigNode" AddrBlk
slot of the uRREP is denoted "uOrigNode", and it has the same
value as the IP address of the TargNode of the incoming RREQ.
Similarly, the IP address in the "TargNode" AddrBlk
slot of the uRREP is denoted "uTargNode", and it has the same
value as the IP address of the OrigNode of the incoming RREQ.
</t>
<t> The fields of the uRREP are assigned as follows.
<list style="symbols">
<t>IP.DestinationAddr := Route[TargNode].NextHop</t>
<t>uRREP.HopLimit := Route[TargNode].HopCount</t>
<t>uRREP.AddrBlk[uOrigNode] := Route[TargNode].Addr</t>
<t>uRREP.AddrBlk[uTargNode] := Route[OrigNode].Addr</t>
<t>uRREP.SeqNumTLV[uTargNode] := Route[OrigNode].SeqNum</t>
<t>uRREP.HopCountTLV[uTargNode] := Route[OrigNode].HopCount</t>
<t>If Route[OrigNode].PfxLen is equal to 0, or the number of bits in
the addresses of the RREQ (32 for IPv4, 128 for IPv6),
then no <prefix-length> is included with the uRREP
AddrBlk. Otherwise,
<list>
<t>uRREP.PfxLen[uTargNode] := Route[OrigNode].PfxLen.</t>
<t>uRREP.PfxLen[uOrigNode] := 0.</t>
</list></t>
</list></t>
<t>No prefix length is needed for uOrigNode == RREQ.TargNode, but due
to RFC 5444 format
requirements, uRREP.PfxLen[uOrigNode] must be included
if uRREP.PfxLen[uTargNode] is included. In that case,
uRREP.PfxLen[uOrigNode] = 0. Therefore either 0 or two
<prefix-length> values are included with uRREP.AddrBlk.
</t>
</section>
</section>
<!--DEREK comments
When InterRtr generates an iRREP it needs to authenticate that it has the
original route. Perhaps InterRtr could include the original RREP signed
by the Target Node in order to prove that InterRtr HAD (at one point in
the past) a valid route to the TargNode.
This is particularly an issue in creating the uRREP to the
TargNode from the OrigNode because there IS no RREP. In this case
InterRtr could include the original RREQ from the OrigRtr as the
authentication token.
-->
<!--
<section anchor="msgtlvtypes"
title="Message TLV Type Specification">
<texttable anchor="msgtlvtbl">
<preamble>Message TLV Types</preamble>
<ttcol align="center">Name</ttcol>
<ttcol align="center" width="14%">Type</ttcol>
<ttcol align="center">Length</ttcol>
<ttcol align="left">Meaning</ttcol>
<c>Unsolicited RREP (uRREP)</c>
<c>14 - TBD</c>
<c>O octets</c>
<c>The AddrTLV fields of a uRREP are to be interpreted
as indicated in <xref target="Unsol_RREP"/>.</c>
</texttable>
</section>
-->
<section title="Acknowledgments">
<t>TBD
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t> If AODVv2 RREP messages are not secured, then the threats are the same.
Otherwise, the ability of intermediate routers to issue RREP on
behalf of a destination node changes the security vulnerability
of the MANET. To improve security, then Intermediate Routers as well
as RREQ.OrigNode and RREQ.TargNode need to maintain security
associations with their neighbors in the MANET
in order to verify iRREP and uRREP. Doing this depends on the exact
nature of the method by which the control messages are
made secure, and is beyond the scope of this document.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.5444"?>
<?rfc include="reference.I-D.ietf-manet-dymo" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3561" ?>
</references>
<section anchor="changes"
title="Changes since the Previous Version">
<t><list style="symbols">
<t>Many changes for RFC 5444 compliance.</t>
<t>Added unsolicitied RREP (uRREP).
</t>
<t>Added notational conventions from <xref target="I-D.ietf-manet-dymo"/>.
</t>
<t>Rewrote many paragraphs to conform to above changes.
</t>
<t>Added section about "prefix-length"=0.
</t>
<t>Added this "Changes" section.
</t>
<t>More later...</t>
</list>
</t>
</section>
</back>
</rfc>
<!--
==================================== 80 ========================================
==================================== 72 ================================
-->
| PAFTECH AB 2003-2026 | 2026-04-24 01:19:15 |