Internet DRAFT - draft-perkins-manet-precursor
draft-perkins-manet-precursor
Mobile Ad hoc Networks Working Group C. Perkins
Internet-Draft Futurewei
Intended status: Standards Track July 14, 2012
Expires: January 15, 2013
Precursor Notification for dynamic MANET On-demand (AODVv2) Routing
draft-perkins-manet-precursor-01
Abstract
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.
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 January 15, 2013.
Copyright Notice
Copyright (c) 2012 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
Perkins Expires January 15, 2013 [Page 1]
Internet-Draft Precursor Notification July 2012
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Precursor Notification . . . . . . . . . . . . . . . . . . . . 4
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Perkins Expires January 15, 2013 [Page 2]
Internet-Draft Precursor Notification July 2012
1. Overview
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.
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.
2. Terminology
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 [RFC2119].
Additionally, this document uses some terminology from [RFC5444] and
[I-D.ietf-manet-dymo], 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.
Originating Node (OrigNode)
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.
Route Reply (RREP)
A RREP message is used to disseminate routing information about
the RREP TargetNode to the RREP OrigNode and the AODVv2 routers
between them.
Perkins Expires January 15, 2013 [Page 3]
Internet-Draft Precursor Notification July 2012
Route Request (RREQ)
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.
Target Node (TargetNode)
The TargetNode is the ultimate destination of a message.
This Node (ThisNode)
ThisNode corresponds to the AODVv2 router process currently
performing a calculation or attending to a message.
3. Precursor Notification
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.
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).
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.
Otherwise, for all destinations no longer reachable because of the
changed status of the next hop, 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.
Perkins Expires January 15, 2013 [Page 4]
Internet-Draft Precursor Notification July 2012
For each precursor of the next hop, the node MAY notify the precursor
in one of three ways:
o unicast RERR
o broadcast RERR
o multicast RERR to multicast group PRECURSOR_RERR_RECEIVERS
Each precursor then MAY execute the same procedure until all affected
traffic sources have received the RERR route maintenance information.
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.
4. Acknowledgments
TBD
5. Security Considerations
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.
6. References
6.1. Normative References
[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.
Perkins Expires January 15, 2013 [Page 5]
Internet-Draft Precursor Notification July 2012
6.2. Informative References
[I-D.ietf-manet-dymo]
Perkins, C. and I. Chakeres, "Dynamic MANET On-demand
(AODVv2) Routing", draft-ietf-manet-dymo-22 (work in
progress), March 2012.
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
Demand Distance Vector (AODV) Routing", RFC 3561,
July 2003.
Author's Address
Charles E. Perkins
Futurewei Inc.
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone: +1-408-421-1172
Email: charliep@computer.org
Perkins Expires January 15, 2013 [Page 6]
