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

Versions: 00 01 02 03

Network Working Group                                        K. Kim, Ed.
Internet-Draft                                  picosNet Corp/Ajou Univ.
Intended status: Standards Track                     S. Daniel Park, Ed.
Expires: December 21, 2007                           SAMSUNG Electronics
                                                           G. Montenegro
                                                   Microsoft Corporation
                                                                  S. Yoo
                                                         Ajou University
                                                          N. Kushalnagar
                                                              Intel Corp
                                                           June 19, 2007


         6LoWPAN Ad Hoc On-Demand Distance Vector Routing (LOAD)
             draft-daniel-6lowpan-load-adhoc-routing-03.txt

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

Abstract

   6LoWPAN Ad Hoc On-Demand Distance Vector Routing (LOAD) is intended
   for use by IEEE 802.15.4 devices in a 6LoWPAN.  It is a simplified
   on-demand routing protocol based on AODV.


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

Internet-Draft                    LOAD                         June 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Data Structures  . . . . . . . . . . . . . . . . . . . . . . .  6
     5.1   Routing Table Entry  . . . . . . . . . . . . . . . . . . .  6
     5.2   Route Request Table Entry  . . . . . . . . . . . . . . . .  6
     5.3   Message Format . . . . . . . . . . . . . . . . . . . . . .  7
       5.3.1   Route Request (RREQ) . . . . . . . . . . . . . . . . .  7
       5.3.2   Route Reply (RREP) . . . . . . . . . . . . . . . . . .  8
       5.3.3   Route Error (RERR) . . . . . . . . . . . . . . . . . . 10
   6.  Operation  . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.1   Generating Route Request . . . . . . . . . . . . . . . . . 11
     6.2   Processing and Forwarding Route Request  . . . . . . . . . 11
     6.3   Generating Route Reply . . . . . . . . . . . . . . . . . . 11
     6.4   Receiving and Forwarding Route Reply . . . . . . . . . . . 12
     6.5   Local Repair and RERR  . . . . . . . . . . . . . . . . . . 12
   7.  Configuration Parameters . . . . . . . . . . . . . . . . . . . 13
   8.  IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 13
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   10.  Acknowledgments  . . .. . . . . . . . . . . . . . . . . . . . 13
   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 14
     11.1  Normative Reference  . . . . . . . . . . . . . . . . . . . 14
     11.2  Informative Reference  . . . . . . . . . . . . . . . . . . 14
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
       Intellectual Property and Copyright Statements . . . . . . . . 17























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

Internet-Draft                    LOAD                         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.montenegro-lowpan-ipv6-over-802.15.4] defines basic
   functionality required to carry IPv6 packets over IEEE 802.15.4
   networks (including an adaptation layer, header compression, etc).
   Likewise, the functionality required for packet delivery in IEEE
   802.15.4 meshes is defined, as mesh topologies are expected to be
   common in LoWPAN networks.  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.

   The 6LoWPAN Ad hoc Routing Protocol (LOAD) is a simplified on-demand
   routing protocol based on AODV[RFC3561] for 6LoWPAN. Besides the main
   AODV specification [RFC3561], several efforts aim at simplifications
   of the protocol, as in the AODVjr proposal [AODVjr] or the TinyAODV
   implementation [TinyAODV].  Similarly, DyMO allows for minimalist
   implementation leaving non-essential functionality as optional
   [I-D.ietf-manet-dymo].  LOAD enables multihop routing between IEEE
   802.15.4 devices to establish and maintain routing routes in 6LoWPAN.

   This document defines the message formats, the data structures,
   and the operations of LOAD.

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

3.  Overview

   This section describes the distinctive features of LOAD compared to
   AODV.  LOAD is defined to be operating on top of the adaptation layer
   instead of the transport layer. That is, it creates a mesh network
   topology underneath and unbeknownst to IPv6 network layer.  IPv6
   sees a 6LoWPAN 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).
   LOAD control packets use the encapsulation defined in [I-D.montenegro
   -lowpan-ipv6-over-802.15.4].  All LOAD control packets shall use the
   prot_type value TBD (suggested value of 4).

   LOAD assumes the use of either one of the two different addresses for
   routing: the EUI-64 address and the 16 bit short address of the
   6LoWPAN device.



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

Internet-Draft                    LOAD                         June 2007


   LOAD makes use of broadcast in its route discovery.  It does so in
   order to propagate the Route Request (RREQ) messages.  In this
   specification, such broadcast packets are obtained by setting the PAN
   id to the broadcast PAN (0xffff) and by setting the destination
   address to the broadcast short address (0xffff).

   LOAD doesn't use the destination sequence number in order to reduce
   the size of the control messages and simplify the route discovery
   process. For ensuring loop freedom, only the destination of a route
   SHOULD generate a RREP in reply. The intermediate nodes SHOULD not
   respond with a RREP. By the same reason, LOAD does not use the
   "Gratuitous RREP".

   LOAD MAY use the local repair for a link break during a data
   delivery. In a local repair, only the destination generates a RREP
   in reply because of no use of the destination sequence number.

   If a local repair fails, LOAD MAY generate a Route Error (RERR)
   message toward the originator of the data delivery to notify that the
   destination is no longer reachable by way of the broken link.  The
   format of RERR is simplified to include only one unreachable
   destination while the RERR of AODV MAY include multiple ones.

   LOAD does not use the "precursor list" of AODV to simplify the routing
   table structure. Notice that AODV uses the precursors for forwarding
   RERR messages in the event of detection of the loss of the next hop
   link. In LOAD, RERR is forwarded only to the originator of the failed
   data delivery, thus no requiring to use the precursor list.

   LOAD MAY use the route cost, which is the accumulated link cost from
   the originator to the destination, as a metric of routing.  For this,
   LOAD utilizes the Link Quality Indicator (LQI) of the 6LoWPAN PHY
   layer in the routing decision in addition to the hop distance. There
   are many ways to include LQI in the routing metric. The approach
   taken by LOAD avoids a route which contains weak links whose LQI is
   below certain threshold value (i.e. WEAK_LQI_VALUE).

   LOAD SHOULD utilize the acknowledged transmission option at the
   6LoWPAN MAC layer for keeping track of the connectivity of a route.
   LOAD uses neither the passive acknowledgements nor the HELLO messages
   of AODV.










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

Internet-Draft                    LOAD                         June 2007


   The basic operations of LOAD are route discovery, managing data
   structures and maintaining local connections.  For these operations,
   LOAD maintains the following two tables: the routing table and the
   route request table. The routing table stores route information such
   as destination, next hop node, and status. The route request table
   stores the temporary route information used in the route discovery
   process.

   There are two different types of 6LoWPAN devices: the reduced
   function device(RFD) and the full function device (FFD).  LOAD SHOULD
   utilize only FFD for mesh routing. Thus, A FFD SHOULD implement the
   operations of LOAD and maintain the data structures of LOAD.

4.  Terminology

   This section defines the terminology of LOAD that is not defined in
   [RFC3753] and [RFC3561].

      destination

         A node to which data packets are to be transmitted. Same as
         "destination node".

      forward route

         A route set up to send data packets from the originator to its
         destination.

      link cost

         The link Quality (LQ) between a node and its neighbor node.

      link quality indicator (LQI)

         A mechanism to measure the Link Quality (LQ) in IEEE 802.15.4
         PHY layer [ieee802.15.4].  It measures LQ by receiving the
         signal energy level.  A high LQ value implies the good quality
         of communication (i.e. low link cost).

      weak link

         A link of which the LQI falls below WEAK_LQI_VALUE.

      originator

         A node that initiates a route discovery process. Same as
         "originating node"




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

Internet-Draft                    LOAD                         June 2007


      route cost

         An accumulated link cost as a LOAD control message (RREQ or
         RREP) passes through the nodes on the route.

      reverse route

         A route set up to forward a RREP back to the originator
         from the destination.  Same as "reverse route" in [RFC3561].

5.  Data Structures

   A FFD in 6LoWPAN SHOULD maintain a routing table and a route request
   table. This section describes the tables and the message formats.

5.1  Routing Table Entry

   The routing table of LOAD includes the following fields:

      destination address

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

      next hop address

         The 16 bit short or EUI-64 link layer addresses of the next hop
         node to the destination.

      status

         The status of a route. It includes the following states: VALID,
         INVALID, ROUTE_DISCOVERY, etc.

      life time

         The valid time in milliseconds before the expiration or the
         deletion of a route.

5.2  Route Request Table Entry

   Route request table is used for discovering routes.  It stores the
   following route request information until a route is discovered.

      route request ID

         a sequence number uniquely identifying the particular RREQ when
         taken in conjunction with the originator



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

Internet-Draft                    LOAD                         June 2007


      originator address

         The 16 bit short or EUI-64 link layer address of the node which
         originates a RREQ.

      reverse route address

         The 16 bit short or EUI-64 link layer address of the next hop
         node on the reverse route to the originator.

      forward route cost

         The accumulated link cost along the forward route from the
         originator to the current node through which a RREQ is
         forwarded.

      reverse route cost

         The accumulated link cost along the reverse route from the
         final destination to the current node through which a RREP is
         forwarded.

      valid time

         The time of the expiration or deletion of a route in
         milliseconds.

5.3  Message Format

5.3.1  Route Request (RREQ)

       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       |R|D|O|Reserved | CT    | WL    |   RREQ ID     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       RC      | Link Layer Destination Address                /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Link Layer Originator Address                 /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 <Fig. 1. RREQ message format>

   The RREQ message format is shown in Fig. 1 and contains the following
   fields:

      Type         1 for indicating a RREQ message.





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

Internet-Draft                    LOAD                         June 2007


      CT           Type of route cost. The followings are the current
                   route cost types known:
                   0    :      Hop count while avoiding weak links
                   1-0xf:      TBD

      WL           The total number of weak links on the routing path
                   from the originator to the sender of the RREQ.

      R            1 Local Repair.

      D            1 for the 16 bit address of the destination,
                   0 for the EUI-64 address of the destination.

      O            1 for the 16 bit address of the originator,
                   0 for the EUI-64 address of the originator.

      RC(Route cost)
                   The accumulated link cost of the reverse route from
                   the originator to the sender of the RREQ. The type of
                   link cost is specified by CT.

      RREQ ID      A sequence number uniquely identifying the particular
                   RREQ when taken in conjunction with the originator.

      Reserved     0; ignored on reception.

      Link layer Destination Address
                   The 16 bit short or EUI-64 link layer address of the
                   destination for which a route is supplied.

      Link layer Originator Address
                   The 16 bit short or EUI-64 link layer address of the
                   node which originated the Route Request.


5.3.2  Route Reply (RREP)

       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       |R|D|O|Reserved | CT    | WL    |   RREQ ID     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       RC      |Link layer Destination Address                 /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Link layer Originator Address                  /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    <Fig. 2. RREP message format>




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

Internet-Draft                    LOAD                         June 2007


   The RREP message format is shown in Fig. 2 and contains the following
   fields:

      Type         2 for indicating a RREP message.

      CT           Type of route cost. The followings are the current
                   route cost types known:
                   0    :      Hop count while avoiding weak links
                   1-0xf:      TBD

      WL           The total number of weak links on the routing path
                   from the originator of the RREP to the sender of
                   the RREP.

      R            1 Local Repair.

      D            1 for the 16 bit address of the destination,
                   0 for the EUI-64 address of the destination.

      O            1 for the 16 bit address of the originator,
                   0 for the EUI-64 address of the originator.

      Reserved      0; ignored on reception.

      RC(Route cost)
                   The accumulated link cost of the route from the
                   originator of the RREP to the sender of the RREP.
                   The type of link cost is specified by CT.

      RREQ ID      A sequence number uniquely identifying the particular
                   RREQ when taken in conjunction with the originator.

      Link layer Destination Address
                   The 16 bit short or EUI-64 link layer address of the
                   destination for which a route is supplied.

      Link layer Originator Address
                   The 16 bit short or EUI-64 link layer address of the
                   node which originated the Route Request.












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

Internet-Draft                    LOAD                         June 2007


5.3.3  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     |D| Reserved    |   Error Code  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Unreachable Link Layer Destination Address             /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  <Fig. 3. RERR message format>

   The RERR message format is shown in Fig. 3 and contains the following
   fields:

      Type         3 for indicating a RERR message.

      D            1 for the 16 bit address of the destination,
                   0 for the EUI-64 address of the destination.

      Reserved     0; ignored on reception.

      Error Code   Numeric value for describing error.
                   0x00 = No available route
                   0x01 = Low battery
                   0x02 = routing cost not supported
                   0x03 - 0xff = reserved (TBD)

      Unreachable Link Layer Destination Address
                   The 16 bit short or EUI-64 link layer address of the
                   final destination that has become unreachable due to
                   a link break.




















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

Internet-Draft                    LOAD                         June 2007


6.  Operation

6.1  Generating Route Request

   The basic operations of LOAD include route discovery, managing data
   structures and maintaining local connections.  A node maintains
   the following two tables for routing: the routing table and the
   routing request table.

   During the discovery period, an originator, a node that requests a
   route discovery, generates a Route Request (RREQ) message with the
   RREQ ID which was incremented by one from the previous RREQ ID value.

   A node SHOULD NOT originate more than RREQ_RATELIMIT RREQs per
   second. After brocasting a RREQ, a node waits for a RREP. If a route
   is not discovered within NET_TRAVERSAL_TIME milliseconds, the node
   MAY try again the discovery process a maximum of RREQ_RETRIES times.

6.2  Processing and Forwarding Route Request

   Upon receiving a RREQ, an intermediate FFD node tries to find the
   entry of the same originator address and RREQ ID pair in the route
   request table.  If the entry is found, the node just discards the
   RREQ. Otherwise, the node creates a reverse route to the originator
   in the routing table and a RREQ entry in the route request table. It
   then checks whether the link through which the RREQ is received is a
   weak link or not. If the link is a weak link, the node adds 1 to the
   WL field of the RREQ.  Then, the node forwards the RREQ.

6.3  Generating Route Reply

   When the destination receives a RREQ, it tries to find the entry of
   the same originator address and RREQ ID pair in the route request
   table. If the entry is found, the destination compares the route cost
   of the RREQ with the forward route cost of the entry. If the cost of
   the RREQ is better than(i.e. less than) that of the entry, the desti-
   nation updates the reverse route to the originator in the routing
   table and generates a RREP in reply. If the cost of the RREQ is not
   less than that of the entry, the destination just discards the RREQ.

   If the CT field of the RREQ is 0 (i.e. hop count while avoiding weak
   links), the route cost becomes a tuple of (WL, RC) and is ordered
   lexicographically. That is, the route cost (WL,RC) is said to be
   better (or smaller) than or equal to (WL',RC') if the following
   condition holds.

   (WL,RC) <= (WL',RC') if and only if WL < WL', or WL == WL'
   and RC <= RC'



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

Internet-Draft                    LOAD                         June 2007


6.4  Receiving and Forwarding Route Reply
   Upon receiving a RREP, an intermediate node checks whether the link
   through which the RREP is received is a weak link or not. If the link
   is a weak link, the node add 1 to the WL field of the RREP.

   The node then checks whether it has a route entry for the destination
   of the RREP (i.e. the originator of the corresponding RREQ). If it
   does not have the route entry, it just discards the RREP.  Otherwise,
   it also checks for the existence of the corresponding RREQ entry
   (which has the same RREQ ID and originator address pair as that of
   the RREP) in the route request table. If there is no such entry, then
   it just discards the RREP.

   If there is such an entry and the entry has worse reverse route cost
   (i.e. higher value) than the route cost of the RREP, the node updates
   the entry with the information of the RREP and forwards it to the
   previous hop node toward the destination of the RREP.  If the entry
   has better reverse route cost (i.e. lower value) than that of the
   RREP, the node just discards the RREP.

   If the CT field of the RREP is 0 (i.e. hop count while avoiding weak
   links), the route cost becomes a tuple of (WL,RC) and is ordered
   lexicographically.

   During the delivery of the RREP to the originator, the route cost
   value of the RREP is accumulated on the reverse route from the
   destination to the originator.

6.5  Local Repair and Route Error (RERR) Messages

   If a link break occurs or a device fails during the delivery of data
   packets,  the upstream node of the link break MAY repair the route
   locally.  To repair a route, the node disseminates a RREQ with the
   originator address set to its own address and the destination address
   set to the data packet's destination address.  In this case, the 'R
   flag' of the RREQ is set to 1.  The data packet is buffered during
   the route discovery period.  If the destination node receives the
   RREQ for a route repair, it responds with a RREP of which the
   'R flag' is also set to 1.

   If the repairing node cannot receive a RREP from the final
   destination until the end of the route discovery period, it unicasts
   a RERR with an error code that indicates the reason of the repair
   failure to the originator.  A repairing node SHOULD NOT generate more
   than RERR_RATELIMIT RERRs per second. Then, the buffered data packet
   is discarded. If the originator that sends a data packet receives the
   RERR, it MAY try to reinitiate route discovery.




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

Internet-Draft                    LOAD                         June 2007


   When the repairing node receives a RREP from the destination during
   the route discovery period, it updates the routing table entry
   information from the RREP.  Then the node transmits the buffered data
   packet to the destination through the new route.


7. Configuration Parameters

   This section describes the default values for some important
   parameters associated with LOAD operations.

   Parameter Name               Value
   ---------------------        -------------
   NET_TRAVERSAL_TIME           TBD
   RREQ_RETRIES                 3
   RREQ_RATELIMIT               2
   RERR_RATELIMIT               2
   WEAK_LQI_VALUE               8


8.  IANA Consideration

   This document needs an additional IANA registry for the prot_type
   value that indicates the LOAD format.

9.  Security Considerations

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

10.  Acknowledgments

   Thanks to the authors of RFC 3753 and RFC 3561, as parts of this
   document are patterned after theirs.  Thanks to Nandakishore
   Kushalnagar, Byeong-Hee Roh, Myung-ho Jung, Dae-hong Son, and Minho
   Lee for their useful discussions and supports for writing this
   document.











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

Internet-Draft                    LOAD                         June 2007


11.  References

11.1  Normative Reference

   [EUI64]    "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64)
              REGISTRATION AUTHORITY", IEEE http://standards.ieee.org/
              regauth/oui/tutorials/EUI64.html.

   [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", draft-ietf-6lowpan-format (work in progress),
              April 2007.

   [I-D.ietf-ipv6-rfc2462bis]
              Thomson, S., "IPv6 Stateless Address Autoconfiguration",
              draft-ietf-ipv6-rfc2462bis-08 (work in progress),
              May 2005.

   [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, RFC 2434,
              October 1998.

   [ieee802.15.4]
              IEEE Compure Society, "IEEE Std. 802.15.4-2003", IEEE Std.
              802.15.4-2003, October 2003.

11.2  Informative Reference

   [RFC1884]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 1884, December 1995.

   [I-D.ietf-6lowpan-problem]
              N., Kushalnagar., Montenegro, G., and C. Schumacher,
              "6LoWPAN: Overview, Assumptions, Problem Statement and
              Goals", draft-ietf-6lowpan-problem (work in progress),
              February 2007.

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

   [RFC3753]  Manner, J. and M. Kojo, "Mobility Related Terminology",
              RFC 3753, June 2004.




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

Internet-Draft                    LOAD                         June 2007


   [AODVjr]   Chakeres, Ian and Klein-Berndt, Luke, "AODVjr, AODV
              Simplified", ACM SIGMOBILE Mobile Computing and
              Communications Review pp. 100-101, July 2002.

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

   [TinyAODV]
              "TinyAODV Implementation", TinyOS Source Code Repository h
              ttp://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-1.x/
              contrib/hsn/.







































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

Internet-Draft                    LOAD                         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


   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


   Gabriel Montenegro
   Microsoft Corporation
   US

   Email: gabriel_montenegro_2000@yahoo.com


   Seung Wha Yoo
   Ajou University
   San 5 Wonchun-dong, Yeongtong-gu
   Suwon-si, Gyeonggi-do  442-749
   KOREA

   Phone: +82 31 219 1603
   Email: swyoo@ajou.ac.kr


   Nandakishore Kushalnagar
   Intel Corp
   US

   Email: nandakishore.kushalnagar@intel.com







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

Internet-Draft                    LOAD                         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.109, available from https://tools.ietf.org/tools/rfcmarkup/