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

Versions: 00 01 02 03

Network Working Group                                        K. Kim, Ed.
Internet-Draft                                           Ajou University
Expires: January 18, 2006                            S. Daniel Park, Ed.
                                                     SAMSUNG Electronics
                                                           G. Montenegro
                                                   Microsoft Corporation
                                                                  S. Yoo
                                                         Ajou University
                                                           July 15, 2005



         6LoWPAN Ad Hoc On-Demand Distance Vector Routing (LOAD)
             draft-daniel-6lowpan-load-adhoc-routing-01.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 January 18, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

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 January 18, 2006                [Page 1]


Internet-Draft                    LOAD                         July 2005


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) . . . . . . . . . . . . . . . . . .  9
   6.  Operation  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.1   Generating Route Request . . . . . . . . . . . . . . . . . 10
     6.2   Processing and Forwarding Route Request  . . . . . . . . . 10
     6.3   Generating Route Reply . . . . . . . . . . . . . . . . . . 10
     6.4   Receiving and Forwarding Route Reply . . . . . . . . . . . 10
     6.5   Local Repair and RERR  . . . . . . . . . . . . . . . . . . 11
   7.  Configuration Parameters . . . . . . . . . . . . . . . . . . . 12
   8.  IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 12
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   10.  Acknowledgments  . . .. . . . . . . . . . . . . . . . . . . . 12
   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 12
     11.1  Normative Reference  . . . . . . . . . . . . . . . . . . . 12
     11.2  Informative Reference  . . . . . . . . . . . . . . . . . . 13
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
       Intellectual Property and Copyright Statements . . . . . . . . 15






















Kim, et al.             Expires January 18, 2006                [Page 2]


Internet-Draft                    LOAD                         July 2005


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 January 18, 2006                [Page 3]


Internet-Draft                    LOAD                         July 2005


   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 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 responds
   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 requring 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. This
   implies that LOAD MAY prefer a route of better link quality to a route
   of shorter hop distance.

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

   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.


Kim, et al.             Expires January 18, 2006                [Page 4]


Internet-Draft                    LOAD                         July 2005


   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

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

      originator

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

      route cost

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

      reverse route

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



Kim, et al.             Expires January 18, 2006                [Page 5]


Internet-Draft                    LOAD                         July 2005


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

      originator address

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

      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.


Kim, et al.             Expires January 18, 2006                [Page 6]


Internet-Draft                    LOAD                         July 2005


      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 |   RREQ ID     |   Route cost  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 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.

      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.

      Route cost   The accumulated link cost of the reverse route from
                   the originator to the sender of the RREQ.



Kim, et al.             Expires January 18, 2006                [Page 7]


Internet-Draft                    LOAD                         July 2005


      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 |   RREQ ID     |   Route cost  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Link layer Destination Address                 /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Link layer Originator Address                  /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    <Fig. 2. RREP message format>

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

      Type         2 for indicating a RREP message.

      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.

      Route cost   The accumulated link cost of the route from
                   the destination to the sender of the RREP.

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



Kim, et al.             Expires January 18, 2006                [Page 8]


Internet-Draft                    LOAD                         July 2005


      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.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 - 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 January 18, 2006                [Page 9]


Internet-Draft                    LOAD                         July 2005


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

6.4  Receiving and Forwarding Route Reply

   Upen receiving a RREP, an intermediate node 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



Kim, et al.             Expires January 18, 2006               [Page 10]


Internet-Draft                    LOAD                         July 2005


   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.

   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.  The accumulation mechanism is TBD (if
   necessary in this document).

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.

   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.














Kim, et al.             Expires January 18, 2006               [Page 11]


Internet-Draft                    LOAD                         July 2005


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


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.

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.montenegro-lowpan-ipv6-over-802.15.4]
              Montenegro, G., "Transmission of IPv6 Packets over IEEE
              802.15.4 Networks",
              draft-montenegro-lowpan-ipv6-over-802.15.4-02 (work in
              progress), February 2005.



Kim, et al.             Expires January 18, 2006               [Page 12]


Internet-Draft                    LOAD                         July 2005


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

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

   [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.kushalnagar-lowpan-goals-assumptions]
              Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview,
              Assumptions, Problem Statement and Goals",
              draft-kushalnagar-lowpan-goals-assumptions-00 (work in
              progress), February 2005.

   [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-02 (work in progress), June 2005.

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




Kim, et al.             Expires January 18, 2006               [Page 13]


Internet-Draft                    LOAD                         July 2005


Authors' Addresses

   Ki-Hyung Kim, Editor
   Ajou University
   San 5 Wonchun-dong, Yeongtong-gu
   Suwon-si, Gyeonggi-do  442-749
   KOREA

   Phone: +82 31 219 2433
   Email: kkim86@ajou.ac.kr


   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













Kim, et al.             Expires January 18, 2006               [Page 14]


Internet-Draft                    LOAD                         July 2005


Intellectual Property Statement

   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.


Disclaimer of Validity

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


Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



Kim, et al.             Expires January 18, 2006               [Page 15]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/