One document matched: draft-perkins-manet-precursor-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-manet-precursor-00"
ipr="trust200902">
<front>
<title abbrev="Precursor notification">
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>2330 Central Expressway</street>
<city>Santa Clara</city>
<code>95050</code>
<region>CA</region>
<country>USA</country>
</postal>
<phone>+1-408-421-1172</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>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
a simple modification to AODVv2 (and possibly other reactive routing
protocols) enabling faster notifications to known sources of traffic
upon determination that a route for such traffic's destination has
become invalid.</t>
</abstract>
</front>
<middle>
<section title="Overview">
<t>If an AODVv2 router, while attempting to forward a packet to
a particular destination, determines that the next hop (one of
its neighbors) is no longer reachable, AODVv2 specifies that
the router notify the source of that packet that the route to
the destination has become invalid. In the existing specification,
the notification to the source is a unicast RERR message.</t>
<t>However, in many cases there will be several sources of
of traffic for that particular destination. In fact, the
broken link for the next hop in question may be a path component
of numerous other routes for other destinations, and in that case
the node detecting the broken link must invalidate multiple
routes, one for each of the newly unreachable destinations.
Each route that uses the newly broken link is no longer valid.
For each such route, every node along the way from the source
using that route, to the node detecting the broken link, is
known as a "precursor" for the broken next hop.
All the precursors for a particular next hop
should be notified about the change in status of their route
to a destination downstream from the broken next hop.
This can be done in several ways.</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="Precursor-Notification"
title="Precursor Notification">
<t>During normal operation, each node wishing to enable the
improved notification for precursors of any links to its
next hop neighbors has to keep track of the precursors.
This is done by maintaining a precursor table and updating
the table whenever the node initiates or relays a RREP
message back to a node originating a RREQ message. When the
node transmits the RREP message, it is implicitly agreeing
to forward traffic from the RREQ originator towards the
RREP originator (i.e., along the next hop link to the
neighbor from which the RREP was received). The "other"
next hop, which is the neighbor along the way towards the
originator of the RREQ message, is then the next precursor
for the route towards the destination requested by the RREQ.</t>
<t>Each such precursor should then be recorded as a precursor for
a route along the next hop. The same next hop may be in service
for routes to multiple destinations, but for precursor list
management it is only important to keep track of precursors
for a particular next hop; the exact destination does not
matter, only the particular next hop towards the destination(s).
</t>
<t>When a node observes that one of its neighbors is no longer
reachable, the node first checks to see whether the link to
that neighbor is a next hop for any more distant destination
in its route table. If not, then the node simply updates any
relevant neighorhood information and takes no further action.</t>
<t>Otherwise, for all destinations no longer reachable because of
the changed status of the next hop, the
reachable, the node first checks to see whether the link to
that neighbor is a next hop for any more distant destination
in its route table. If not, then the node simply updates any
relevant neighorhood information and takes no further action.</t>
<t>For each precursor of the next hop, the node MAY notify the
the changed status of the next hop, the
reachable, the node first checks to see whether the link to
that neighbor is a next hop for any more distant destination
in its route table. If not, then the node simply updates any
relevant neighorhood information and takes no further action.</t>
<t>Otherwise, for all destinations no longer reachable because of
the changed status of the next hop, the
reachable, the node first checks to see whether the link to
that neighbor is a next hop for any more distant destination
in its route table. If not, then the node simply updates any
relevant neighorhood information and takes no further action.</t>
<t>For each precursor of the next hop, the node MAY notify the
precursor in one of three ways:</t>
<t><list style="symbols">
<t>unicast RERR</t>
<t>broadcast RERR</t>
<t>multicast RERR to multicast group PRECURSOR_RERR_RECEIVERS</t>
</list>
</t>
<t>Each precursor then MAY execute the same procedure until all
affected traffic sources have received the RERR route
maintenance information.</t>
<t>When a precursor receives a unicast RERR, the precursor
MUST further unicast the RERR message
towards the affected traffic source.
If a precursor receives a broadcast or multicast RERR,
the precursor MAY further retransmit the RERR towards
the traffic source.
</t>
</section>
<section title="Acknowledgments">
<t>TBD
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The ability of to use broadcast instead of unicast can in
some cases cause additional network traffic.
This would happen when many traffic sources were
never going to re-use a particular route, and yet were receiving
essentially useless notifications about that route.
It remains to be determined whether such scenarios, where
route tables have significant numbers of useless routes,
would be encountered in practice.
</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" ?>
</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:04 |