One document matched: draft-perkins-irrep-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"?>
<?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-00" 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-421-1172</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>Extensible Markup Language</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
when an AODVv2 router receives a packet from a node under its
responsibility to a destination for which it 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 dissemination 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 dissemination 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", "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">
<!-- Move to AODV2 Extensions document
TODO
<t hangText="AODVv2 Identifier (DID)"><vspace />A DID is
maintained for each AODVv2 routing process (ThisNode.DID), and
the default value is zero (0). Each routing message is
tagged with its associated DID (MsgTLV.DID), unless zero
(0). Upon receipt of AODVv2 protocol message an AODVv2 routing
protocol process SHOULD only attend to messages with a
matching DID value.</t>
-->
<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="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
disseminate 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 disseminate 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 message.</t>
<t hangText="This Node (ThisNode)"><vspace />ThisNode
corresponds to the AODVv2 router process currently performing
a calculation or attending to 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>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>When an intermediate AODVv2 router originates a RREP in
response to a RREQ on behalf of the TargetNode's AODVv2
router, it sends the RREP to the RREQ OrigNode with
additional routing information (Address, Prefix, SeqNum,
Dist, etc.) about the RREQ 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>
<t>When an intermediate AODVv2 router creates this RREP, it
sends a RREP to the RREQ TargetNode with additional routing
information (Address, Prefix, SeqNum, Dist, etc.) about 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>The ability of intermediate nodes to issue RREP on behalf of
a destination node does not significantly add to the
security vulnerability of an ad hoc network. If the routing
control messages are not secured, then the threats are exactly
the same. If the routing control messages are secured, then
the originator of the RREP may need to maintain security
associations with additional nodes in the ad hoc network
in order to verify iRREP, but this depends on the exact
nature of the method by which the control messages are
made secure. That 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"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3561" ?>
<?rfc include="reference.I-D.ietf-manet-dymo" ?>
<?rfc include="reference.I-D.clausen-lln-loadng" ?>
</references>
<!--
<section anchor="changes"
title="Changes since the Previous Version">
<t><list style="symbols">
<t>Intermediate RREPs (iRREPs) are to be put into new document. Without
iRREP, only the destination can respond to a RREQ. </t>
<t>Precursor lists not supported, based on reported performance loss.</t>
</list>
</t>
</section>
-->
</back>
</rfc>
<!--
==================================== 80 ========================================
==================================== 72 ================================
-->
| PAFTECH AB 2003-2026 | 2026-04-24 01:19:43 |