One document matched: draft-perkins-irrep-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- "setl noai nocin nosi inde=" turns off vim autoindentation -->
<?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 ================================
-->
<rfc category="std" docName="draft-perkins-irrep-03" 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>2300 Central Expressway</street>
<city>Santa Clara</city>
<code>95053</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</keyword>
<keyword>RREP</keyword>
<abstract>
<t> The 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 on-demand convergence in
dynamic topologies. This document specifies an extension to AODVv2
(possibly useful with other reactive routing protocols) enabling
intermediate nodes to shorten route discovery times.</t>
</abstract>
</front>
<middle>
<section title="Overview">
<t> The Ad Hoc On-demand Distance Vector (AODVv2) routing protocol
<xref target="I-D.ietf-manet-aodvv2"/>
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 (called OrigNode) attempts to transmit a packet
towards a destination for which the router does not have a route.</t>
<t> OrigNode's AODVv2 router (denoted RREQ_Gen) initiates route discovery
by multicasting a Route Request (RREQ). During the hop-by-hop multicast
operation, each intermediate AODVv2 router records a route to the IP
address of OrigNode (i.e., OrigAddr). If an intermediate router has a
route to the destination requested (denoted TargAddr) in the RREQ, it
could transmit an RREP with that routing information to RREQ_Gen. Such
an RREP message is called an "Intermediate RREP" (or, "iRREP").
The intermediate router (denoted iRREP_Gen) also generates another
RREP message, which is called an "Unsolicited RREP" (or, "uRREP"),
to TargRtr, the router TargAddr. The uRREP supplies
TargRtr and other intermediate routers with a route towards OrigAddr.
When RREQ_Gen receives the iRREP, and TargRtr receives the uRREP,
a bi-directional route is established between RREQ_Gen and TargRtr.</t>
<t> In this document, RREQ always refers to the incoming RREQ message
received by iRREP_Gen. RREQ_Gen, OrigAddr, TargRtr, and TargAddr always
refer to the addresses and routers as defined in
<xref target="I-D.ietf-manet-aodvv2"/>; they are named from the context
of RREQ_Gen (the AODVv2 router originating the RREQ message).
</t>
<t> Intermediate RREP can be 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-aodvv2" />.
Together, these two features enable a simple "route repair"
mechanism. When a route breaks close to the origin, RREQ_Gen MAY
limit the flooding of a RREQ using expanding rings multicast.
Then, nearby AODVv2 routers could in many situations generate iRREP
to supply a new route to the desired destination.
<!-- TODO: Check use of msg-hop-count -->
<!--
Nearness of the broken link relative to RREQ_Gen can be measured
by the <msg-hop-count> field of the RERR message (if included)
indicating that a route has broken.
-->
</t>
<t> When an AODVv2 router receives an RREQ, it first uses the information
in the RREQ to update any relevant route table entries. Then, if the
router 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 data elements of the iRREP and uRREP.
</t>
<t> Other Intermediate routers receiving the iRREP and uRREP messages use
the same procedures to process those messages as specified in
<xref target="I-D.ietf-manet-aodvv2"/>. In other words, when iRREP_Gen
sends iRREP and uRREP messages, other AODVv2 routers along the route
receive and regenerate those messages using the same rules as for any
other RREP 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-aodvv2"/>,
some of which is 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 Intermediate router.</t>
<t hangText="Intermediate Router"><vspace />
An AODVv2 router along a route between RREQ_Gen and TargRtr
that itself is not RREQ_Gen or TargRtr.</t>
<t hangText="iRREP_Gen"><vspace />
An Intermediate Router that generates an iRREP message and a
uRREP message.</t>
<t hangText="OrigAddr"><vspace/> An IP address of the Originating Node
used as a data element within AODVv2 messages.</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="RREQ Generating Router (RREQ_Gen)"><vspace /> The
AODVv2 router that provides network connectivity to the
Originating Node (OrigNode). RREQ_Gen creates a
AODVv2 control message (namely, RREQ) on behalf of OrigNode
to discover a route to TargAddr. </t>
<t hangText="Router Client"><vspace />A node that requires
the services of an AODVv2 router for route discovery and
maintenance. An AODVv2 router is always its own client,
so that its list of client IP addresses is never empty. </t>
<t hangText="Target Address (TargAddr)"><vspace />
The Target Address is the address for which a route discovery
is initiated by RREQ_Gen.</t>
<t hangText="Target Router (TargRtr)"><vspace />
TargRtr is the AODVv2 router providing connectivity for TargAddr.
</t>
<t hangText="Unsolicited Route Reply (uRREP)"><vspace />
An unsolicited RREP message is a RREP originated by an AODVv2 router
to a router which did not send a RREQ. In previous documents,
uRREP was also sometimes called "Gratuitous RREP".</t>
</list></t>
<t>This document uses the Data Elements and conventions found in
<xref target="data-elements"/> and <xref target="conventions"/>.</t>
<texttable anchor="data-elements">
<ttcol align="left" width="20%">Data Elements</ttcol>
<ttcol align="left">Meaning</ttcol>
<c>MetricType</c> <c>The metric type for OrigMetric and TargMetric</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>PrefixLengthList</c>
<c>Routing prefixes associated with addresses in AddressList</c>
<c>OrigSeqNum</c> <c>Originating Node Sequence Number</c>
<c>TargSeqNum</c> <c>Target Node Sequence Number</c>
<c>OrigMetric</c> <c>Metric value for route to OrigAddr</c>
<c>TargMetric</c> <c>Metric value for route to TargAddr</c>
<c>ValidityTime</c> <c>Validity Time values for routes</c>
</texttable>
<texttable anchor="conventions">
<ttcol align="left" width="25%">Notation</ttcol>
<ttcol align="left">Meaning</ttcol>
<c>Route[Address]</c> <c>A route table entry towards Address</c>
<c>Route[Address].{field}</c> <c>A field in such a route table entry</c>
<c> -- </c> <!-- Types of Nodes --> <c> -- </c>
<c>iRREP_Gen</c> <c>AODVv2 Router generating Intermediate RREP</c>
<c>uOrigAddr</c> <c>Used as OrigAddr in the uRREP message</c>
<c>uTargAddr</c> <c>Used as TargAddr in the uRREP message</c>
</texttable>
</section>
<section anchor="Features" title="Intermediate RREP Protocol Features">
<t> The protocol features specified in this document are as follows:
<list style="symbols">
<!-- style="hanging" -->
<!-- hangText="whatever" -->
<t> DestOnly Message TLV </t>
<t> iRREP </t>
<t> uRREP </t>
</list></t>
<t>
RREQ_Gen MAY specify that only the router serving TargAddr is allowed
to generate an RREP message, by including the DestOnly data element
(see <xref target="iana" />) as part of the message. This also
assures that RREP_Gen increments its sequence number. Otherwise
Intermediate AODVv2 routers MAY respond to the RREQ if they have a
valid route to TargAddr, as detailed in this document.
</t>
<t> If an intermediate AODVv2 router (iRREP_Gen) has a Route that can satisfy
an incoming RREQ, it MAY respond with an Intermediate RREP (iRREP).
As usual with any incoming RREQ, iRREP_Gen first updates its route
table using the information contained in the RREQ. For example,
a route to OrigAddr may be created or updated. After the incoming route
update information is applied, iRREP_Gen has valid routes to
both OrigAddr and TargAddr (Route[OrigAddr] and
Route[TargAddr] respectively).
</t>
<t> iRREP_Gen SHOULD also send a RREP to TargRtr, so that TargRtr can obtain
a route towards
OrigAddr. This RREP sent towards the TargAddr is known as an
"Unsolicited RREP" (uRREP). Each AODVv2 router between iRREP_Gen
and TargRtr that receives the uRREP, uses the uRREP information to
update their route table entry for OrigAddr.
</t>
<t> The following conditions must be satisfied before iRREP_Gen
can generate iRREP and uRREP.
<list style="symbols">
<t>RREQ does not contain the DestOnly Message TLV.</t>
<t>iRREP_Gen has a valid route with the same MatricType for TargAddr
(namely Route[TargAddr]).</t>
<t>Route[TargAddr].SeqNum ≥ RREQ.TargSeqNum
</t>
</list>
</t>
</section>
<section anchor="Int_RREP" title="Intermediate RREP Generation">
<t> The data elements for the iRREP are assigned as follows.
<list style="symbols">
<!-- style="hanging" -->
<!-- hangText="whatever" -->
<t> IP.DestinationAddr := Route[OrigAddr].NextHop</t>
<t> AddressList := {OrigAddr, TargAddr} </t>
<t> TargSeqNum := Route[TargAddr].Seqnum</t>
<t> Include the MetricType data element if offering a route for a
non-default metric type, and set the type accordingly.</t>
<t> MetricList := {null, Route[TargAddr].Metric}</t>
<t> PrefixLengthList contains the length of the prefix for TargAddr,
if TargAddr resides on a Client Network with a prefix length shorter
than the number of bits of the address family for TargAddr.</t>
<t>If Route[TargAddr].Timed is TRUE, include the ValidityTimeList and set
ValidityTimeList :=
{Route[TargAddr].ExpirationTime - Current_Time, null}</t>
</list></t>
<t>If TargAddr has
an associated subnet prefix in the route table, insert its prefix
in the PrefixLengthList; otherwise, omit the PrefixLengthList.</t>
</section>
<section anchor="Unsol_RREP" title="Unsolicited RREP Generation">
<!--
<t> The uRREP message TLV (see <xref target="iana"/>)
MUST be included in the uRREP.</t>
-->
<t> The uRREP is intended to fulfill the function of an RREP as if in
response to a (fictional) RREQ message sent by TargRtr for discovering
a route to OrigAddr. The sense of the addresses in the uRREP
has to be reversed.
<!-- RREQ.OrigAddr fulfills the role of the TargAddr in the uRREP. -->
To reduce confusion which might result from this reversal, the OrigAddr
data element of the uRREP is denoted "uOrigAddr"; uOrigAddr has
the same value as the TargAddr of the incoming RREQ. Similarly, the
TargAddr data element is denoted "uTargAddr", and
it has the same value as the OrigAddr of the incoming RREQ.
</t>
<t> The data elements of the uRREP are assigned as follows.
<list style="symbols">
<t> IP.DestinationAddr := Route[TargAddr].NextHop</t>
<t> AddressList := {uOrigAddr, uTargAddr} </t>
<t> TargSeqNum := Route[uTargAddr].Seqnum</t>
<t> Include the MetricType data element if offering a route for a
non-default metric type, and set the type accordingly.</t>
<t> MetricList := {null, Route[uTargAddr].Metric}</t>
<t> PrefixLengthList contains the length of the prefix for uTargAddr,
if uTargAddr resides on a Client Network with a prefix length shorter
than the number of bits of the address family for uTargAddr.</t>
<t>If Route[OrigAddr].Timed is TRUE, include the ValidityTimeList and set
ValidityTimeList :=
{Route[OrigAddr].ExpirationTime - Current_Time, null}.</t>
</list></t>
<!--
<t>If OrigAddr has
an associated subnet prefix in the route table, insert its prefix
in the PrefixLengthList; otherwise, omit the PrefixLengthList.</t>
-->
</section>
<section anchor="iana" title="IANA Considerations">
<t>This section specifies one new RFC 5444 message-tlv type.</t>
<texttable anchor="msgtlvtbl" title="RFC 5444 Message TLV Types">
<ttcol align="left" width="60%">Name of RFC 5444 Message TLV</ttcol>
<ttcol align="center" width="8%">Type</ttcol>
<ttcol align="center" width="8%">Length (octets)</ttcol>
<ttcol align="center">Cross Reference</ttcol>
<c>Destination RREP Only (DestOnly)</c> <c>TBD</c> <c>0</c>
<c><xref target="Features"/></c>
</texttable>
</section>
<!--DEREK comments
When iRREP_Gen generates an iRREP it needs to authenticate that it has the
original route. Perhaps iRREP_Gen could include the original RREP signed
by the Target Node in order to prove that iRREP_Gen HAD (at one point in
the past) a valid route to the TargAddr.
This is particularly an issue in creating the uRREP to the
TargAddr from the OrigAddr because there IS no RREP. In this case
iRREP_Gen could include the original RREQ from the RREQ_Gen as the
authentication token.
-->
<section title="Acknowledgments">
<t>Victoria Mercieca
</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_Gen
and RREP_Gen need to maintain security associations with their
neighbors in the MANET in order to verify iRREP and uRREP.
-->
Since the RREP message is used in the same way as in AODVv2, no
new security vulnerabilities are introduced. The effect of an
intermediate node erroneously inserting a DestOnly TLV is minimal,
and would simply prevent other routers from offering the benefit
of generating Intermediate RREP.
Security associations SHOULD be maintained in the same way
as specified in AODVv2 <xref target="I-D.ietf-manet-aodvv2"/>.
Likewise, RREP messages generated according to the specification
in this document SHOULD be protected in the same way
as specified in AODVv2 <xref target="I-D.ietf-manet-aodvv2"/>.
</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-aodvv2" ?>
</references>
<!--
<references title="Informative References">
<?rfc include="reference.RFC.3561" ?>
</references>
-->
<section anchor="changes" title="Changes since version ...-02">
<t><list style="symbols">
<t> Text rewritten to conform to new terminology
in <xref target="I-D.ietf-manet-aodvv2"/>.</t>
<t> Updated to handle nondefault metrics.</t>
<t> Replace SeqNum by OrigSeqNum and TargSeqNum as needed.</t>
<t> Minor editorial improvements.</t>
</list>
</t>
</section>
<section anchor="prev-changes" title="Previous Changes">
<t><list style="symbols">
<t> Many changes for RFC 5444 compliance.</t>
<t> Added unsolicitied RREP (uRREP).</t>
<t> Added notation from <xref target="I-D.ietf-manet-aodvv2"/>.</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>
</list>
</t>
</section>
</back>
</rfc>
<!--
==================================== 80 ========================================
==================================== 72 ================================
-->
| PAFTECH AB 2003-2026 | 2026-04-23 03:33:32 |