Internet DRAFT - draft-chakeres-manet-dymo-default
draft-chakeres-manet-dymo-default
Mobile Ad hoc Networks Working I. Chakeres
Group Motorola
Internet-Draft April 11, 2008
Intended status: Standards Track
Expires: October 13, 2008
A Default Route for DYMO
draft-chakeres-manet-dymo-default-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 13, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document describes how to distribute, create, and update a
default route in DYMO.
Chakeres Expires October 13, 2008 [Page 1]
Internet-Draft DYMO April 2008
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability Statement . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Distributing and Installing a Default Route . . . . . . . . . . 4
5. Performing Route Discovery in the Presence of a Default
Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Forwarding Data Packets . . . . . . . . . . . . . . . . . . . . 4
7. Learning about Locally Reachable Destinations . . . . . . . . 4
8. Informing DYMO Routers about Locally Reachable
Destinations . . . . . . . . . . . . . . . . . . . . . . . . . 5
9. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 5
10. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 5
11. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
13.1. Normative References . . . . . . . . . . . . . . . . . . . 6
13.2. Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 7
Chakeres Expires October 13, 2008 [Page 2]
Internet-Draft DYMO April 2008
1. Overview
This document describes how to distribute, create, and update a
default route in DYMO [I-D.ietf-manet-dymo].
A default route can be very effective in reducing the number of route
discoveries, particularly for destinations not reachable inside a
MANET.
The mechanisms proposed in this document reuse DYMO's existing RM
processing and forwarding logic. Similarly, this specification
ensures that DYMO remains reactive for known locally reachable
destinations.
2. Applicability Statement
This specification allows one DYMO router within a MANET, called a
DYMO Default Router (DDR), to advertise a default route (DROUTE).
In the simplest operational mode, we assume that all DYMO routers in
the MANET know the locally reachable destination addresses.
Reversing this logic, we assume that all DYMO routers know which
destination addresses are not locally reachable, and that should be
forwarded via the DDR. Correspondingly, the set of reachable/
unreachable destinations is known by all DYMO routers in the MANET.
In a more complex mode of operation, we describe how the DDR can
inform other DYMO routers that a particular address or set of
addresses is directly reachable in the MANET (Section 8). Note that,
the DDR may or may not know all the reachable destination addresses.
3. 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].
Default Route (DROUTE)
A default route is represented by 0.0.0.0 or ::/0 [RFC5156].
REACHABLE_ADDRESSES
The list of addresses known/assumed to be reachable with the
MANET. Route discoveries are performed for these destinations.
Chakeres Expires October 13, 2008 [Page 3]
Internet-Draft DYMO April 2008
REACHABLE_ADDRESS_TIMEOUT
The amount of time to wait before removing a dynamically added
REACHABLE_ADDRESS entry.
4. Distributing and Installing a Default Route
The DDR MAY reactively or proactively distribute DROUTE information.
The DDR may advertise a default route by attaching the DROUTE address
to a RM (RREQ or RREP) as described in DYMO Section 5.3.5 "Adding
Additional Routing Information to a RM". The prefix length is set to
zero (0).
Alternatively, the DDR may advertise a default route by inserting the
DROUTE address as the OrigNode and TargetNode in a RREQ. The prefix
length is set to zero (0).
DYMO routers conforming to this specification process the DDR routing
information as if it were a unicast address.
5. Performing Route Discovery in the Presence of a Default Route
If a default route exists, DYMO routers MUST still perform route
discovery for those destination addresses reachable within the MANET.
Each DYMO router SHOULD maintain this list of addresses, and their
prefixes. We will refer to this list as REACHABLE_ADDRESSES.
6. Forwarding Data Packets
When a DYMO router receives a data packet for forwarding with a
destination addresses not reachable within the MANET, the default
route SHOULD be used for forwarding.
7. Learning about Locally Reachable Destinations
When a DYMO router processes a RM, it SHOULD add the OrigNode.Address
and prefix to its REACHABLE_ADDRESSES. These entries SHOULD be
removed after REACHABLE_ADDRESS_TIMEOUT seconds.
The DDR MAY also learn about locally reachable destinations, by
examining the source address in data packets it receives from the
MANET for forwarding. These sources SHOULD be added to the DDR's
REACHABLE_ADDRESSES. These entries SHOULD be removed after
REACHABLE_ADDRESS_TIMEOUT seconds.
Chakeres Expires October 13, 2008 [Page 4]
Internet-Draft DYMO April 2008
8. Informing DYMO Routers about Locally Reachable Destinations
When the DDR receives a data packet for a locally reachable
destination, it SHOULD inform the source's DYMO router that this
particular destination exists in the local MANET by issuing a
Destination Reachable DYMO control message.
The Destination Reachable (DR) DYMO control message is unicast hop-
by-hop to the DYMO router responsible for the source of the data
packet. Note: the exact format of this message will be flushed out
in later drafts.
DYMO routers processing this DR message SHOULD add the reachable
destination(s) to their REACHABLE_DESTINATIONS list. These entries
SHOULD be removed after REACHABLE_ADDRESS_TIMEOUT seconds.
9. Backward Compatibility
The DYMO specification [I-D.ietf-manet-dymo] defines unicast routing
for valid unicast IP destination addresses. Therefore, if a DYMO
router does not follow the directions describe in this document, it
will not process or forward DROUTE routing information.
10. Parameters
REACHABLE_ADDRESS_TIMEOUT should be larger than ROUTE_DELETE_TIMEOUT.
Logically, it would also be correct for REACHABLE_ADDRESS_TIMEOUT to
be less than ROUTE_AGE_MAX_TIMEOUT.
11. Security Considerations
TBD
12. Acknowledgments
DYMO is a descendant of the design of previous MANET reactive
protocols, especially AODV [RFC3561]. Some of the concepts contained
in the document come from AODV, AODV-bis, and early DYMO I-Ds.
13. References
Chakeres Expires October 13, 2008 [Page 5]
Internet-Draft DYMO April 2008
13.1. Normative References
[I-D.ietf-manet-dymo]
Chakeres, I. and C. Perkins, "Dynamic MANET On-demand
(DYMO) Routing", draft-ietf-manet-dymo-12 (work in
progress), February 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
13.2. Informative References
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
Demand Distance Vector (AODV) Routing", RFC 3561,
July 2003.
[RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156,
April 2008.
Author's Address
Ian D Chakeres
Motorola
Bangalore
India
Email: ian.chakeres@gmail.com
URI: http://www.ianchak.com/
Chakeres Expires October 13, 2008 [Page 6]
Internet-Draft DYMO April 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Chakeres Expires October 13, 2008 [Page 7]
