[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 02 03

Internet Engineering Task Force                              K. Kim, Ed.
Internet-Draft                                  picosNet Corp/Ajou Univ.
Intended status: Standards Track                           G. Montenegro
Expires: December 21, 2007                         Microsoft Corporation
                                                            S. Park, Ed.
                                             Mobile Platform Laboratory,
                                                     SAMSUNG Electronics
                                                             I. Chakeres
                                        Boeing Phantom Works, The Boeing
                                                                 Company
                                                              C. Perkins
                                                   Nokia Research Center
                                                           June 19, 2007


         Dynamic MANET On-demand for 6LoWPAN (DYMO-low) Routing
              draft-montenegro-6lowpan-dymo-low-routing-03

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 December 21, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).





Kim, et al.             Expires December 21, 2007               [Page 1]

Internet-Draft                  DYMO-low                       June 2007


Abstract

   This document specifies how to use the Dynamic MANET On-demand
   Routing Protocol over IEEE802.15.4 networks.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements notation  . . . . . . . . . . . . . . . . . .  3
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Simplifications for DYMO over IEEE 802.15.4  . . . . . . .  4
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Data Structures  . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Route Table Entry  . . . . . . . . . . . . . . . . . . . .  5
     3.2.  DYMO-low Messages  . . . . . . . . . . . . . . . . . . . .  6
       3.2.1.  DYMO-low Routing Messages  . . . . . . . . . . . . . .  6
   4.  Detailed operation . . . . . . . . . . . . . . . . . . . . . .  9
     4.1.  DYMO-low Routing Table Operations  . . . . . . . . . . . .  9
       4.1.1.  Creating or Updating a Route Table Entry from New
               Routing Information  . . . . . . . . . . . . . . . . .  9
       4.1.2.  Route Table Entry Timeouts . . . . . . . . . . . . . . 10
     4.2.  Routing message  . . . . . . . . . . . . . . . . . . . . . 10
       4.2.1.  Routing message creation . . . . . . . . . . . . . . . 10
       4.2.2.  Routing message Processing . . . . . . . . . . . . . . 10
     4.3.  Energy-aware Route Discovery . . . . . . . . . . . . . . . 11
     4.4.  Route Maintenance  . . . . . . . . . . . . . . . . . . . . 12
       4.4.1.  Monitoring of Active Links . . . . . . . . . . . . . . 12
       4.4.2.  Updating Route Lifetimes . . . . . . . . . . . . . . . 12
       4.4.3.  Route Error Generation . . . . . . . . . . . . . . . . 12
     4.5.  General DYMO-low Processing  . . . . . . . . . . . . . . . 12
       4.5.1.  DYMO-low Processing  . . . . . . . . . . . . . . . . . 12
       4.5.2.  DYMO-low Control Packet Transmission . . . . . . . . . 13
     4.6.  Packet Generation Limits . . . . . . . . . . . . . . . . . 13
   5.  Configuration Parameters . . . . . . . . . . . . . . . . . . . 13
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 15











Kim, et al.             Expires December 21, 2007               [Page 2]

Internet-Draft                  DYMO-low                       June 2007


1.  Introduction

   The IEEE 802.15.4 standard [IEEE802.15.4] targets low power personal
   area networks.  The "IPv6 over IEEE 802.15.4" document [I-D.ietf-
   6lowpan-format] defines basic functionality required to carry IPv6
   packets over IEEE 802.15.4 networks (including an adaptation layer,
   header compression, etc).  Likewise, as mesh topologies are expected
   to be common in LoWPAN networks, the functionality required for
   packet delivery in IEEE 802.15.4 meshes is defined.  However, neither
   the IEEE 802.15.4 standard nor the "IPv6 over IEEE 802.15.4"
   specification provide any information as to how such a mesh topology
   could be obtained and maintained.

   This document specifies how to use the Dynamic MANET On-demand
   Routing Protocol (DYMO) [I-D.ietf-manet-dymo] over IEEE 802.15.4
   networks to provide mesh routing.  To distinguish this instantiation
   of the protocol from DYMO over IPv4 and DYMO over IPv6, the label
   "DYMO-low" is used in this document.  Given the very stringent
   limitations of the target devices, this document specifies
   simplifications that are recommended to the base DYMO specification.

1.1.  Requirements notation

   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].

2.  Overview

   The addresses used in DYMO-low control messages are either 16 bit
   link layer short address or IEEE 64-bit extended addresses [EUI64].
   Additionally, it should be noted that as used in this specification,
   DYMO-low is not layered on top of IP, but underneath it.  It is an
   underlay.  As such, it creates a mesh network topology of IEEE
   802.15.4 devices that use single wireless interface each, underneath
   and unbeknownst to IP.  IP sees a PAN as a single link.  This is
   similar to how other technologies regularly create complex structures
   underneath IP (e.g., ethernet spanning tree bridges, token ring
   source routing, ATM, etc).  One can envision a sub-IP mesh creating
   the illusion that all the devices on that PAN are on the same IPv6
   link (sharing the same IPv6 prefix).  At the same time, normal usage
   of DYMO (above IP) could tie together several such "links"
   (potentially using different technologies for each) into a larger
   mesh.

   DYMO over IPv4 makes use of broadcast in its route discovery.  It
   does so in order to propagate the Route Request control packets
   (RREQs).  In this specification, such broadcast packets are obtained



Kim, et al.             Expires December 21, 2007               [Page 3]

Internet-Draft                  DYMO-low                       June 2007


   by setting the PAN id to the broadcast PAN (0xffff) and by setting
   the link layer destination address to the broadcast short address
   (0xffff) DYMO-low control packets use the encapsulation defined in
   [I-D.ietf-6lowpan-format].  All DYMO-low control packets shall use
   the prot_type value TBD (suggested value of 5).  This prot_type is
   used to send DYMO-low messages in a manner similar to how DYMO uses a
   properly assigned UDP port.

2.1.  Simplifications for DYMO over IEEE 802.15.4

   This section specifies simplifications and distinctive features of
   DYMO-low compared to the base DYMO.

   DYMO allows for minimalist implementations by specifying non-
   essential functionality as optional [I-D.ietf-manet-dymo].  In
   keeping with DYMO, DYMO-low implements the routing message(RM) which
   provides both the RREQ (route request) and the RREP (route reply).
   Furthermore, the RERR (route error) message is implemented while UERR
   (unsupported message error) message is obviated for simplicity.
   DYMO-low has the following characteristics:

   o  RREQ messages are transmitted as IEEE 802.15.4 broadcast messages
      to reach all the next hop neighbors.  DYMO packets SHOULD NOT be
      fragmented.

   o  Only the final destination SHOULD respond to a RREQ by replying
      with a RREP.

   o  Link quality (LQI) of IEEE 802.15.4 [IEEE802.15.4] in addition to
      the route cost is utilized for selecting best route to the
      destination.

   o  Hello messages are not used.  Instead, the IEEE 802.15.4
      acknowledgement mechanism is used to determine if a neighbor is no
      longer responsive.  This information is obtained when transmitting
      a packet with acknowledgement option turned on.

   o  Due to space limitations, nodes SHOULD append only one unreachable
      destination in RERR.

   o  Sequence numbers are used for loop freedom.  The size of the
      sequence number field is reduced from 32 bits to 16 bits for
      simplification.

   o  The transmission method for RREQ and RERR messages in DYMO is
      link-local multicast.However, considering the energy-constrained
      nature of 6lowpan, some efficient mechanisms other than broadcast
      are necessitated in DYMO-low (TBD).



Kim, et al.             Expires December 21, 2007               [Page 4]

Internet-Draft                  DYMO-low                       June 2007


2.2.  Terminology

   Link Layer Destination Address (LinkLayerDestinationAddress)

   The 16 bit short or EUI-64 link layer address of the destination in
   the MAC layer.  It is also called as the next-hop destination during
   hop-by-hop forwarding of packets.

   Link Layer Source Address (LinkLayerSourceAddress)

   The 16 bit short or EUI-64 link layer address of the source in the
   MAC layer.  It is also called as the previous-hop source address
   during hop-by-hop forwarding of packets.

   Broadcast

   A broadcast in 6lowpan implies link-local multicast in IEEE 802.15.4
   MAC layer.  This can be done by setting the link layer destination
   field to 0xffff.

   Valid Route

   A known route where the Route.ValidTimeout timer is not set to the
   current time.

3.  Data Structures

3.1.  Route Table Entry

   The route table entry is a conceptual data structure.
   Implementations may use any internal representation that conforms to
   the semantics of a route as specified in this document.

   Route Destination Address (Route.DestAddress)

   The 16 bit short or EUI-64 link layer address of the final
   destination of a route.

   Route Delete Timeout (Route.DeleteTimeout)

   If the current time is after Route.DeleteTimeout the corresponding
   routing table entry MUST be deleted and the timer associated with
   this entry are reset.

   Route Cost (Route.RouteCost)

   Cumulative cost metric used for allowing a node to select an optimum
   route to the final destination.



Kim, et al.             Expires December 21, 2007               [Page 5]

Internet-Draft                  DYMO-low                       June 2007


   Route Next Hop Address (Route.NextHopAddress)

   The 16 bit short or EUI-64 link layer address of the next-hop node on
   the path toward the final destination.

   Route.ValidTimeout

   The time at which a route table entry is scheduled to be invalidated.
   The routing table entry is no longer considered valid when the timer
   is set after Route.ValidTimeout, and Route.DeleteTimeOut is set.

3.2.  DYMO-low Messages

   DYMO-low messages are categorized either as a Routing Message (RM) or
   a Route Error (RERR) message.

3.2.1.  DYMO-low Routing Messages

   A RM can be either a Route Request (RREQ) message or a Route Reply
   (RREP) message.  These messages are very similar in information but
   vary in the way of their processing.

3.2.1.1.  DYMO-low Route Request (RREQ) and Route Reply (RREP) messages


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |      TTL      |T|O|S|C|A| CT  |   RREQ  ID    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |TRouteCost(opt)|         TargetAddress (optional)              /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            OriginatorAddress                  /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 1

   Message Type (Type) The following is the list of the currently
   available message types.


             Type                                     Value
             --------------------------------         -----
             Routing Message (RM)                       1
             Route Error (RERR)                         2


   Time To Live (TTL)



Kim, et al.             Expires December 21, 2007               [Page 6]

Internet-Draft                  DYMO-low                       June 2007


   8-bit field that identifies the maximum number of times the message
   is to be retransmitted.

   Target (T-bit)

   1 for the 16-bit address of the target.

   0 for the EUI-64 address of the target.

   Originator (O-bit)

   1 for the 16-bit address of the Source.

   0 for the EUI-64 address of the Source.

   Solicited/Unsolicited (S-bit)

   Route discovery is desired (solicited) if S is set.  The
   TargetAddress is only present if S is set.  If S is unset (ie, zero),
   it allows nodes to disseminate unsolicited & undirected routing
   information.

   Coordinator (C-bit)

   1 if the node generating DYMO message is a PAN Coordinator (PC).
   Allows priority routing (TBD) to node if it is a PC 0 if the node
   generating this message is a not PC (TBD)

   A-bit (A)

   1-bit selector indicating whether this RM requires a RREP by the
   TargetAddress.  If A=1 the RM is a RREQ and needs a RREP.

   Cost Type (CT)

   3-bits of CT are currently defined as:

   0: Hop count

   1-0xf: TBD

   RREQ ID

   An identifier that uniquely identifies the particular RREQ when taken
   in conjunction with the originator.  It serves two purposes, i) It
   allows intermediate nodes to process the RREQ message once and ii) It
   matches a unique RREP message against unique RREQ in the wake of
   multiple RREQ generation.



Kim, et al.             Expires December 21, 2007               [Page 7]

Internet-Draft                  DYMO-low                       June 2007


   Target Address (TargetAddress) - (Optional)

   The node that is the ultimate destination of the message.  This field
   is only required if the LinkLayerDestinationAddress is not the
   BroadcastAddress.  TargetAddress is present if the S-bit is set.  For
   RREQ the TargetAddress is the desired destination, the destination
   for which a valid route does not exist.  For RREP the TargetAddress
   is the RREQ originator.  During hop-by-hop transmission of a DYMO-low
   packet the LinkLayerDestinationAddress is filled with the
   Route.NextHopAddress of the route table entry associated with the
   TargetAddress.  In case S-bit is unset,the message is neither a RREQ
   nor a RREP.  It can be used an unsolicited routing informational
   message.

   Target Route Cost (TRouteCost) - (Optional)

   8-bit field that identifies the routing cost across the number of
   intermediate nodes through which a packet traversed on the route to
   this particular TargetAddress.

   Originator Address (OriginatorAddress)

   The node that is the originator of routing message.  In RREQ message,
   the OriginatorAddress is the node that generates RREQ message.  In
   RREP, the OriginatorAddress is the node that replies to RREQ.

3.2.1.2.  Route Error (RERR)


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |      TTL      |T|O|U|C|A|    TargetAddress    /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         OriginatorAddress                     /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         UnreachableNodeAddress                /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                  Figure 2

   U-bit (T)

   1 for the 16-bit address of UnreachableNodeAddress.

   0 for the EUI-64 address of UnreachableNodeAddress.

   UnreachableNodeAddress




Kim, et al.             Expires December 21, 2007               [Page 8]

Internet-Draft                  DYMO-low                       June 2007


   The 16-bit short or EUI-64 link layer address of the node that has
   become unreachable.

   OriginatorAddress

   The 16-bit short or EUI-64 link layer address of the node that
   generates the RERR message.

   Target Node Address (TargetAddress)

   The 16-bit short or EUI-64 link layer address of the node that is the
   destination of the RERR message.

4.  Detailed operation

4.1.  DYMO-low Routing Table Operations

4.1.1.  Creating or Updating a Route Table Entry from New Routing
        Information

   While processing a RM, as described in Section 4.2.2, a node checks
   its routing table for an entry to the OriginatorAddress in the RREQ.
   If a valid route exists to TargetAddress, the route can be used to
   send any queued data packets and to fulfill any outstanding route
   requests.

   In the event that no matching entry is found, an entry is created.

   If a matching entry is found, the routing information about
   OriginatorAddress contained in this RM is considered stale if the
   TRouteCost is greater than Route.RouteCost.

   If there exists a route AND the TRouteCost is equal to the
   Route.RouteCost in this RM, the information is not stale, but the
   routing information SHOULD be disregarded and no routing update
   should occur.

   If the information in this RM is stale or disregarded this DYMO-low
   packet MUST be dropped.  If the route information for Originator is
   not stale or disregarded, then the following actions occur to the
   route table entry for OriginatorAddress:

   1. the Route.RouteCost is set to the TRouteCost,

   2. the Route.NextHopAddress is set to the node that transmitted this
   DYMO-low packet (LinkLayerSourceAddress),

   3. and the Route.ValidTimeout is set to the current time +



Kim, et al.             Expires December 21, 2007               [Page 9]

Internet-Draft                  DYMO-low                       June 2007


   ROUTE_TIMEOUT.  If a valid route exists to TargetAddress, the route
   can be used to send any queued data packets and to fulfill any
   outstanding route requests.

4.1.2.  Route Table Entry Timeouts

   If the current time is later than a routing entry's
   Route.ValidTimeout, the route is stale and it is not to be used to
   route packets.  The information in invalid entries is still used for
   generating RREQ messages.  If the current time is after
   Route.DeleteTimeout the corresponding routing table entry MUST be
   deleted.

4.2.  Routing message

4.2.1.  Routing message creation

   When a node creates a RREQ or RREP, it MUST create the RM.  It sets
   the OriginatorAddress to its own address.

4.2.2.  Routing message Processing

   After the general DYMO-low message pre-processing (Section 4.5.2),
   the Routing message is processed to yield the route cost TRouteCost.
   That is, the route cost TRouteCost is said to be better (or
   equivalently smaller) than or equal to (Route.RouteCost') if the
   following condition holds (Note that the apostrophe refers to
   Route.RouteCost i.e., an already existing route entry in the routing
   table)

   TRouteCost < = Route.RouteCost'

   If a matching entry to the OriginatorAddress in the routing message
   is found in the routing table, the routing information about
   OriginatorAddress contained in this routing message is considered
   stale if TRouteCost is greater than the Route.RouteCost'.  If the
   information in this routing message is stale or disregarded this
   DYMO-low packet MUST be dropped.

   If there exists a route AND equal the information is not stale, then
   the routing information SHOULD be disregarded and no routing update
   should occur.  If the route information for OriginatorAddress is not
   stale or disregarded,then the following actions occur to the route
   table entry for OriginatorAddress:

   1. the Route.RouteCost is set to the TRouteCost,

   2. the Route.NextHopAddress is set to the node that transmitted this



Kim, et al.             Expires December 21, 2007              [Page 10]

Internet-Draft                  DYMO-low                       June 2007


   DYMO-low packet (LinkLayerSourceAddress),

   3. and the Route.ValidTimeout is set to the current time +
   ROUTE_TIMEOUT.

   If this node is the TargetAddress AND the A-bit is set (A=1), this
   node MUST respond with a RREP.  The target node creates a new RM as
   described in Section 4.2.1.  The TargetAddress in the new RM is set
   to the OriginatorAddress from the RM currently being processed.  The
   A-bit is set to (A=0).  The LinkLayerDestinationAddress is set to the
   Route.NextHopAddress for the TargetAddress.  Then the new RM
   undergoes post-processing, according to Section 4.5.3.  If this node
   is not the TargetAddress, the current RE SHOULD be handled according
   to Section 4.5.4.

   If this node is the TargetAddress, the current packet and any
   additional elements are processed, but this packet is not
   retransmitted.

4.3.  Energy-aware Route Discovery

   A node generates a Route Request (RREQ) to discover a valid route to
   a particular destination (TargetAddress).  A RREQ is a RM with the
   A-bit is set to one (A=1) to indicate that the TargetAddress must
   respond with a RREP.  The LinkLayerDestinationAddress is set to the
   BroadcastAddress.  The RM is then transmitted according to the
   procedure defined in Section 4.5.4.  After issuing a RREQ, the
   originating node waits for a route to be created to the
   TargetAddress.  If a RREP is not received within RREQ_WAIT_TIME
   milliseconds, this node MAY again try to discover a route by issuing
   another RREQ.  An intermediate node that receives RREQ message may
   agree broadcast it right away only if its energy level permits so.
   Otherwise, such an energy starved node (shown in Fig. 3) may delay
   the broadcast of RREQ message by the time factor 'INDELAY' (where the
   notation is intended to represent induced delay) so that other nodes
   with relatively more energy form the routing path for the
   TargetAddress.  The methods to adjust the value of INDELAY is TBD.
   To reduce congestion in a network, repeated attempts at route
   discovery for a particular TargetAddress SHOULD utilize a binary
   exponential backoff.  The first time a node issues a RREQ, it waits
   RREQ_WAIT_TIME milliseconds for a route to the TargetAddress.  If a
   route is not found within that time, the node MAY send another RREQ.
   If a route is not found within two (2) times the current waiting
   time, another RREQ may be sent, up to a total of RREQ_TRIES.  For
   each additional attempt, the waiting time for the previous RREQ is
   multiplied by two (2) so that the waiting time conforms to a binary
   exponential backoff.  Data packets awaiting for a route MAY be
   buffered.  If a route discovery has been attempted RREQ_TRIES times



Kim, et al.             Expires December 21, 2007              [Page 11]

Internet-Draft                  DYMO-low                       June 2007


   without receiving a route to the TargetAddress, all data packets
   destined to the corresponding TargetAddress SHOULD be dropped from
   the buffer.

4.4.  Route Maintenance

4.4.1.  Monitoring of Active Links

   Before a route can be used for forwarding a packet, it MUST be
   checked to make sure that the route is still valid.  If the
   Route.ValidTimeout is earlier than the current time, the packet
   cannot be forwarded, and a RERR message MUST be generated (seesection
   4.4.3).  In this case, the Route.DeleteTimeout is set to
   Route.ValidTimeout + ROUTE_DELETE_TIMEOUT.  If the current time is
   after Route.DeleteTimeout, then the route SHOULD be deleted, though a
   route MAY be deleted at any time.  Upon detecting a link break the
   detecting node MUST set the Route.ValidTimeout to the current time
   for all active routes utilizing the broken link.  A RERR MUST be
   issued if a data packet is received and it cannot be delivered to the
   next hop.  RERR generation is described in Section 4.4.3.  A RERR
   SHOULD be issued after detecting a broken link of an active route to
   quickly notify nodes that a link break occurred and a route or routes
   are no longer available.

4.4.2.  Updating Route Lifetimes

   To avoid route timeouts for active routes, a node SHOULD update the
   Route.ValidTimeout to the final destination address[I-D.ietf-6lowpan-
   format] to be the current time + ROUTE_TIMEOUT upon successfully
   transmitting a packet to the next hop.

4.4.3.  Route Error Generation

   When a data packet is received for a destination without a valid
   routing table entry, a Route Error (RERR) MUST be generated by this
   node.  A RERR informs the source that the current route is no longer
   available.  In the RERR, the TargetAddress field is the address of
   the unreachable node (final destination address) from the data
   packet.  The setting of theL inkLayerDestinationAddress of the RERR
   and the RERR processing at the receiving node are TBD.

4.5.  General DYMO-low Processing

4.5.1.  DYMO-low Processing

   The Routing Message (RM) MUST be processed completely prior to any
   transmissions.  Unless specific message processing requires dropping
   the DYMO-low packet, it is retransmitted after processing, according



Kim, et al.             Expires December 21, 2007              [Page 12]

Internet-Draft                  DYMO-low                       June 2007


   to the method described in Section 4.5.4.

4.5.1.1.  Routing Message Pre-processing

   The RM in a DYMO-low packet undergoes pre-processing before the
   message specific processing occurs.  During pre-processing, the TTL
   is decremented by one (1).

4.5.1.2.  Routing Message Post-processing

   If the TTL is zero (0) the DYMO-low packet is dropped.  If the TTL is
   greater than zero the DYMO-low packet is re-transmitted after
   processing of all messages.  If the TTL of Routing Message (RM) is
   zero (0) after processing, it MUST be removed from the DYMO-low
   packet prior to transmission.

4.5.2.  DYMO-low Control Packet Transmission

   DYMO-low packet transmission and re-transmission is controlled by the
   LinkLayerDestinationAddress.  If the LinkLayerDestinationAddress is a
   unicast address, the packet LinkLayerDestinationAddress is replaced
   by the Route.NextHopAddress from a route table lookup for the
   TargetAddress.  If a route for the TargetAddress is unknown or
   invalid the packet is dropped and a RERR SHOULD be generated.

4.6.  Packet Generation Limits

   To avoid congestion, a node SHOULD NOT transmit more than RATE_LIMIT
   control messages per second.  RREQ packets SHOULD be discarded before
   RREP or RERR packets.

5.  Configuration Parameters

   Here are some default parameter values for DYMO-low:

         Parameter Name                  Suggested Value
         ---------------------------     ---------------
         NET_DIAMETER                    256
         RATE_LIMIT                      2
         ROUTE_TIMEOUT                   10 minutes
         ROUTE_DELETE_TIMEOUT            2*ROUTE_TIMEOUT
         RREQ_WAIT_TIME                  1000 milliseconds
         RREQ_TRIES                      2








Kim, et al.             Expires December 21, 2007              [Page 13]

Internet-Draft                  DYMO-low                       June 2007


6.  IANA Considerations

   This document needs an additional IANA registry for the prot_type
   value that indicates the DYMO-low format.

7.  Security Considerations

   The security considerations of the [RFC3561] are applicable to this
   document.  As described in the charter of the 6lowpan w.g., DYMO-low
   will also try to reuse existing security considerations related to Ad
   hoc routing protocols.  Further considerations will be studied in the
   next version.

8.  Acknowledgements

   Thanks to Ali Hammad Akbar, Seung-Wha Yoo, Byeong-Hee Roh, Shafique
   Ahmad Chaudhry, Hee-Jung Kim and Hamid Mukhtar for their useful
   discussions and supports for writing this document.

9.  References

9.1.  Normative References

   [EUI64]                      802.15.4-2003, IEEE Standard.,
                                "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER
                                (EUI-64) REGISTRATION AUTHORITY".

   [I-D.ietf-ipv6-2461bis]      T., Narten., "Neighbor Discovery for IP
                                version 6 (IPv6)", May 2005.

   [I-D.ietf-ipv6-rfc2462bis]   S., Thomson., "IPv6 Stateless Address
                                Autoconfiguration", May 2005.

   [I-D.ietf-manet-dymo]        I., Chakeres., "Dynamic MANET On-demand
                                (DYMO) Routing", May 2007.

   [I-D.ietf-6lowpan-format]    N., Kushalnagar., Montenegro, G., Hui,
                                J., and D. Culler, "6LoWPAN:
                                Transmission of IPv6 Packets over IEEE
                                802.15.4 Networks", February 2007.

   [RFC2119]                    Bradner, S., "Key words for use in RFCs
                                to Indicate Requirement Levels", BCP 14,
                                RFC 2119, March 1997.

   [RFC2434]                    Narten, T. and H. Alvestrand,
                                "Guidelines for Writing an IANA
                                Considerations Section in RFCs", BCP 26,



Kim, et al.             Expires December 21, 2007              [Page 14]

Internet-Draft                  DYMO-low                       June 2007


                                RFC 2434, October 1998.

   [RFC2460]                    Deering, S. and R. Hinden, "Internet
                                Protocol, Version 6 (IPv6)
                                Specification", RFC 2460, December 1998.

   [RFC4291]                    Hinden, R. and S. Deering, "IP Version 6
                                Addressing Architecture", RFC 4291,
                                February 2006.

   [IEEE802.15.4]               802.15.4-2003, IEEE Standard., "Wireless
                                medium access control and physical layer
                                specifications for low-rate wireless
                                personal area networks.", May 2003.

9.2.  Informative References

   [AODVjr]                     I., Chakeres. and Klein-Berndt. Luke,
                                "AODVjr, AODV Simplified", July 2002.

   [I-D.ietf-ipngwg-icmp-v3]    A., Conta., "nternet Control Message
                                Protocol (ICMPv6) for the Internet
                                Protocol Version  6 (IPv6)
                                Specification", July 2005.

   [I-D.perkins-manet-aodvbis]  C., Perkins., "Ad hoc On-Demand Distance
                                Vector (AODV) Routing", February 2004.

   [KW03]                       C., Karlof. and Wagner. D., "Secure
                                Routing in Sensor Networks: Attacks and
                                Countermeasures", September 2003.

   [RFC3439]                    Bush, R. and D. Meyer, "Some Internet
                                Architectural Guidelines and
                                Philosophy", RFC 3439, December 2002.

   [RFC3756]                    Nikander, P., Kempf, J., and E.
                                Nordmark, "IPv6 Neighbor Discovery (ND)
                                Trust Models and Threats", RFC 3756,
                                May 2004.

   [TinyAODV]                   ., TinyOS Source Code Repository.,
                                "TinyAODV Implementation".

   [RFC3561]                    Perkins, C., Belding-Royer, E., and S.
                                Das, "Ad hoc On-Demand Distance Vector
                                (AODV) Routing", RFC 3561, July 2003.




Kim, et al.             Expires December 21, 2007              [Page 15]

Internet-Draft                  DYMO-low                       June 2007


Authors' Addresses

   Kim, Ki Hyung (editor)
   picosNet Corp/Ajou Univ.
   San 5 Wonchun-dong, Yeongtong-gu
   Suwon-si, Gyeonggi-do  442-749
   KOREA

   Phone: +82 31 219 2433
   EMail: kkim86@picosnet.com


   Gabriel Montenegro
   Microsoft Corporation


   Soohong Daniel Park (editor)
   Mobile Platform Laboratory, SAMSUNG Electronics
   416 Maetan-3dong, Yeongtong-gu
   Suwon-si, Gyeonggi-do  442-742
   KOREA

   Phone: +82 31 200 4508
   EMail: soohong.park@samsung.com


   Ian Chakeres
   Boeing Phantom Works, The Boeing Company
   P.O. Box 3707 Mailcode 7L-49
   Seattle, WA  98124-2207
   USA

   EMail: ian.chakeres@gmail.com


   Charlie Perkins
   Nokia Research Center
   313 Fairchild Drive
   Mountain View, CA  94043
   USA

   Phone: +1-650-625-2986
   EMail: charles.perkins@nokia.com








Kim, et al.             Expires December 21, 2007              [Page 16]

Internet-Draft                  DYMO-low                       June 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).







Kim, et al.             Expires December 21, 2007              [Page 17]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/