Internet DRAFT - draft-perkins-irrep
draft-perkins-irrep
Mobile Ad hoc Networks Working Group C. Perkins
Internet-Draft Futurewei
Intended status: Standards Track May 30, 2015
Expires: December 1, 2015
Intermediate RREP for dynamic MANET On-demand (AODVv2) Routing
draft-perkins-irrep-03
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 1, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Perkins Expires December 1, 2015 [Page 1]
Internet-Draft Intermediate RREP May 2015
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3
3. Intermediate RREP Protocol Features . . . . . . . . . . . . . 5
4. Intermediate RREP Generation . . . . . . . . . . . . . . . . 6
5. Unsolicited RREP Generation . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Changes since version ...-02 . . . . . . . . . . . . 8
Appendix B. Previous Changes . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Overview
The Ad Hoc On-demand Distance Vector (AODVv2) routing protocol
[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.
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.
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
[I-D.ietf-manet-aodvv2]; they are named from the context of RREQ_Gen
(the AODVv2 router originating the RREQ message).
Perkins Expires December 1, 2015 [Page 2]
Internet-Draft Intermediate RREP May 2015
Intermediate RREP can be particularly effective in conjunction with
the use of "expanding rings multicast", which is specified as an
optional feature in [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.
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.
Other Intermediate routers receiving the iRREP and uRREP messages use
the same procedures to process those messages as specified in
[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.
2. Terminology and Notation
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
[RFC2119]. Additionally, this document uses some terminology and
notation from [RFC5444] and [I-D.ietf-manet-aodvv2], some of which is
duplicated here for convenience.
AODVv2 Sequence Number (SeqNum)
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.
Intermediate Route Reply (iRREP)
A RREP message that is originated by an Intermediate router.
Intermediate Router
An AODVv2 router along a route between RREQ_Gen and TargRtr that
itself is not RREQ_Gen or TargRtr.
iRREP_Gen
An Intermediate Router that generates an iRREP message and a uRREP
message.
Perkins Expires December 1, 2015 [Page 3]
Internet-Draft Intermediate RREP May 2015
OrigAddr
An IP address of the Originating Node used as a data element
within AODVv2 messages.
Originating Node (OrigNode)
The Originating Node is the node that launched the application
requiring communication with the Target Address.
RREQ Generating Router (RREQ_Gen)
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.
Router Client
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.
Target Address (TargAddr)
The Target Address is the address for which a route discovery is
initiated by RREQ_Gen.
Target Router (TargRtr)
TargRtr is the AODVv2 router providing connectivity for TargAddr.
Unsolicited Route Reply (uRREP)
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".
This document uses the Data Elements and conventions found in Table 1
and Table 2.
Perkins Expires December 1, 2015 [Page 4]
Internet-Draft Intermediate RREP May 2015
+------------------+------------------------------------------------+
| Data Elements | Meaning |
+------------------+------------------------------------------------+
| MetricType | The metric type for OrigMetric and TargMetric |
| AddressList | A list of IP addresses |
| OrigAddr | IP address of the Originating Node |
| TargAddr | IP address of the Target Node |
| PrefixLengthList | Routing prefixes associated with addresses in |
| | AddressList |
| OrigSeqNum | Originating Node Sequence Number |
| TargSeqNum | Target Node Sequence Number |
| OrigMetric | Metric value for route to OrigAddr |
| TargMetric | Metric value for route to TargAddr |
| ValidityTime | Validity Time values for routes |
+------------------+------------------------------------------------+
Table 1
+------------------------+------------------------------------------+
| Notation | Meaning |
+------------------------+------------------------------------------+
| Route[Address] | A route table entry towards Address |
| Route[Address].{field} | A field in such a route table entry |
| -- | -- |
| iRREP_Gen | AODVv2 Router generating Intermediate |
| | RREP |
| uOrigAddr | Used as OrigAddr in the uRREP message |
| uTargAddr | Used as TargAddr in the uRREP message |
+------------------------+------------------------------------------+
Table 2
3. Intermediate RREP Protocol Features
The protocol features specified in this document are as follows:
o DestOnly Message TLV
o iRREP
o uRREP
RREQ_Gen MAY specify that only the router serving TargAddr is allowed
to generate an RREP message, by including the DestOnly data element
(see Section 6) 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.
Perkins Expires December 1, 2015 [Page 5]
Internet-Draft Intermediate RREP May 2015
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).
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.
The following conditions must be satisfied before iRREP_Gen can
generate iRREP and uRREP.
o RREQ does not contain the DestOnly Message TLV.
o iRREP_Gen has a valid route with the same MatricType for TargAddr
(namely Route[TargAddr]).
o Route[TargAddr].SeqNum >= RREQ.TargSeqNum
4. Intermediate RREP Generation
The data elements for the iRREP are assigned as follows.
o IP.DestinationAddr := Route[OrigAddr].NextHop
o AddressList := {OrigAddr, TargAddr}
o TargSeqNum := Route[TargAddr].Seqnum
o Include the MetricType data element if offering a route for a non-
default metric type, and set the type accordingly.
o MetricList := {null, Route[TargAddr].Metric}
o 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.
o If Route[TargAddr].Timed is TRUE, include the ValidityTimeList and
set ValidityTimeList := {Route[TargAddr].ExpirationTime -
Current_Time, null}
Perkins Expires December 1, 2015 [Page 6]
Internet-Draft Intermediate RREP May 2015
If TargAddr has an associated subnet prefix in the route table,
insert its prefix in the PrefixLengthList; otherwise, omit the
PrefixLengthList.
5. Unsolicited RREP Generation
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. 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.
The data elements of the uRREP are assigned as follows.
o IP.DestinationAddr := Route[TargAddr].NextHop
o AddressList := {uOrigAddr, uTargAddr}
o TargSeqNum := Route[uTargAddr].Seqnum
o Include the MetricType data element if offering a route for a non-
default metric type, and set the type accordingly.
o MetricList := {null, Route[uTargAddr].Metric}
o 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.
o If Route[OrigAddr].Timed is TRUE, include the ValidityTimeList and
set ValidityTimeList := {Route[OrigAddr].ExpirationTime -
Current_Time, null}.
6. IANA Considerations
This section specifies one new RFC 5444 message-tlv type.
Perkins Expires December 1, 2015 [Page 7]
Internet-Draft Intermediate RREP May 2015
+------------------------------------+-------+----------+-----------+
| Name of RFC 5444 Message TLV | Type | Length | Cross |
| | | (octets) | Reference |
+------------------------------------+-------+----------+-----------+
| Destination RREP Only (DestOnly) | TBD | 0 | Section 3 |
+------------------------------------+-------+----------+-----------+
Table 3: RFC 5444 Message TLV Types
7. Acknowledgments
Victoria Mercieca
8. Security Considerations
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
[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 [I-D.ietf-manet-aodvv2].
9. Normative References
[I-D.ietf-manet-aodvv2]
Perkins, C., Ratliff, S., Dowdell, J., Steenbrink, L., and
V. Mercieca, "Ad Hoc On-demand Distance Vector (AODVv2)
Routing", draft-ietf-manet-aodvv2-09 (work in progress),
May 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized Mobile Ad Hoc Network (MANET) Packet/Message
Format", RFC 5444, February 2009.
Appendix A. Changes since version ...-02
o Text rewritten to conform to new terminology in
[I-D.ietf-manet-aodvv2].
o Updated to handle nondefault metrics.
o Replace SeqNum by OrigSeqNum and TargSeqNum as needed.
Perkins Expires December 1, 2015 [Page 8]
Internet-Draft Intermediate RREP May 2015
o Minor editorial improvements.
Appendix B. Previous Changes
o Many changes for RFC 5444 compliance.
o Added unsolicitied RREP (uRREP).
o Added notation from [I-D.ietf-manet-aodvv2].
o Rewrote many paragraphs to conform to above changes.
o Added section about "prefix-length"=0.
o Added this "Changes" section.
Author's Address
Charles E. Perkins
Futurewei Inc.
2300 Central Expressway
Santa Clara, CA 95053
USA
Phone: +1-408-330-4586
Email: charliep@computer.org
Perkins Expires December 1, 2015 [Page 9]
