One document matched: draft-perkins-irrep-01.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-01" 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. Route maintenance is performed to help ensure that the
route being used to forward packets from the source to the
destination remains operational.</t>
<t>During route discovery, the originator's AODVv2 router
initiates flooding of a Route Request (RREQ) throughout the
network to find a route to a particular destination, via the
AODVv2 router responsible for this destination. During this
hop-by-hop flooding process, each intermediate AODVv2 router
records a route to the originator. If the intermediate router
has a route to the destination requested 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 also forwards another RREP message
to the requested destination, supplying the destination and
other intermediate routers with a route towards the originator
of the RREQ.
When the originator's AODVv2 router receives the iRREP,
and the destination receives iRREP for the originator,
routes have then been established between the originating AODVv2
router and the target AODVv2 router in both directions.</t>
</section>
<section title="Terminology">
<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 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="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.
corresponds to the AODVv2 router process currently performing
a calculation or processing a message.</t>
<t hangText="Originating Node (OrigNode)"><vspace /> The
originating node is the source, its AODVv2 router creates a
AODVv2 control message on its behalf in an effort to
flood some routing information. The originating node
is also referred to as a particular message's
originator.</t>
<t hangText="Route Reply (RREP)"><vspace />A RREP message is
used to flood routing information about the RREP
TargetNode to the RREP OrigNode and the 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 TargetNode. When an AODVv2
router processes a RREQ, it learns routing information on
how to reach the RREQ OrigNode.</t>
<t hangText="Target Node (TargetNode)"><vspace />The
TargetNode is the ultimate destination of a data packet.</t>
<t hangText="This Node (ThisNode)"><vspace />ThisNode
corresponds to the AODVv2 router process currently performing
a calculation or processing a message.</t>
</list></t>
</section>
<section anchor="Int_RREP_create"
title="Intermediate AODVv2 Router RREP Creation">
<t>Sometimes an AODVv2 router other than the TargetNode's AODVv2
router (call it an "intermediate AODVv2 router") has routing
information that can satisfy an incoming RREQ. An
intermediate AODVv2 router can issue a intermediate AODVv2
router RREP on behalf of the TargetNode's AODVv2 router.</t>
<t>If ThisNode is not the TargetNode, and the
RREQ contains the TargetNode.AddTLV.SeqNum, and ThisNode has
a forwarding route to the TargetNode with a SeqNum satisfying
Route.TargetNode.SeqNum > RREQ.TargetNode.AddTLV.SeqNum
(using signed 16-bit arithmetic); then ThisNode MAY
respond with an intermediate AODVv2 router RREP (iRREP).
When an intermediate AODVv2 router creates a iRREP in
response to a RREQ on behalf of the TargetNode's AODVv2
router, it transmits the iRREP to the RREQ OrigNode with
additional routing information (Address, Prefix, SeqNum,
Dist, etc.) about the RREQ TargetNode.
After an AODVv2 router sends iRREP, it need not perform any more
operations for the RREQ being processed.</t>
<!--
<t>Before creating a intermediate AODVv2 router RREP,
OwnSeqNum SHOULD be incremented by one (1) according to the rules
specified in <xref target="I-D.ietf-manet-dymo" />.</t>
<t>If OwnSeqNum is not incremented the routing information
about ThisNode might be considered stale by a handling
AODVv2 router. In this case, the RREP would not reach the RREP
TargetNode.</t>
-->
<t>The Intermediate AODVv2 router SHOULD also issue a RREP to
the RREQ TargetNode, so that the RREQ TargetNode receives
routing information on how to reach the RREQ OrigNode.</t>
</section>
<!--DEREK comments
When an intermediate router creates an RREP it needs to authenticate
that it has the original route. Perhaps what needs to happen is that
it includes the original RREP signed by the TargetNode in order to
prove
that it HAD (at one point in the past) a valid route to the
TargetNode.
This is particularly an issue in creating the RREP on the fly to the
TargetNode from the OrigNode because there IS no RREP. In this case
it might want to include the original RREQ from the OrigNode as the
authentication token.
-->
<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 nodes to issue RREP on
behalf of a destination node changes the security vulnerability
of an ad hoc network. In that case, then the originator and
TargetNode of the RREQ may need to maintain security
associations with additional nodes in the ad hoc network
in order to verify iRREP. 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" ?>
<?rfc include="reference.I-D.clausen-lln-loadng" ?>
</references>
</back>
</rfc>
<!--
==================================== 80 ========================================
==================================== 72 ================================
-->
| PAFTECH AB 2003-2026 | 2026-04-24 01:18:38 |