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

Versions: 00 01

Network Working Group                                          M-K. Shin
Internet-Draft                                                      ETRI
Expires: November 30, 2007                                     T. Camilo
                                                                J. Silva
                                                   University of Coimbra
                                                               D. Kaspar
                                                                    ETRI
                                                            May 29, 2007


                      Mobility Support in 6LoWPAN
                     draft-shin-6lowpan-mobility-00

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 November 30, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).










Shin, et al.            Expires November 30, 2007               [Page 1]


Internet-Draft         Mobility Support in 6LoWPAN              May 2007


Abstract

   This draft lists mobility scenarios and suggests solutions of how to
   provide mobility support in IPv6 low-power personal area networks
   (6LoWPANs).


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Notation  . . . . . . . . . . . . . . . . . .  3
     1.2.  Terms Used . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Scenario Considerations  . . . . . . . . . . . . . . . . . . .  6
     3.1.  Device Movement (e.g., FFD or RFD) within a Single
           WPAN Domain  . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Device Movement (e.g., FFD or RFD) between Multiple
           WPAN Domains . . . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Single WPAN Movement (e.g., NEMO)  . . . . . . . . . . . .  8
     3.4.  MANEMO - Nested NEMO . . . . . . . . . . . . . . . . . . .  9
   4.  Mobility Support in 6LoWPAN  . . . . . . . . . . . . . . . . . 11
     4.1.  Device Movement (e.g., FFD or RFD) within a Single
           WPAN Domain  . . . . . . . . . . . . . . . . . . . . . . . 11
     4.2.  Device Movement (e.g., FFD or RFD) between Multiple
           WPAN DomainsS  . . . . . . . . . . . . . . . . . . . . . . 11
     4.3.  Single WPAN movement (e.g., NEMO)  . . . . . . . . . . . . 13
     4.4.  MANEMO - Nested NEMO . . . . . . . . . . . . . . . . . . . 13
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 20
















Shin, et al.            Expires November 30, 2007               [Page 2]


Internet-Draft         Mobility Support in 6LoWPAN              May 2007


1.  Introduction

   A 6LoWPAN is a simple low cost communication network that allows
   wireless connectivity in applications with limited power and relaxed
   throughput requirements.  A 6LoWPAN typically includes devices that
   work together to connect the physical environment to real-world
   applications, e.g., wireless sensors [I-D.ietf-6lowpan-problem].

   6LoWPANs must support various topologies like mesh as well as star.
   Mesh topologies imply multi-hop routing, to a desired destination.
   Mesh networks are likely to consist of nodes with a certain degree of
   mobility.  Due to the low performance characteristics of LoWPAN
   devices, mobility support should be provided without high signaling
   involvement in end devices (e.g., RFD).

   Fast mobility detection will be a huge challenge and LoWPAN nodes
   might even change their location while being in state of hibernation.
   Also, as recently seen in discussions related to MANEMO (Network
   mobility for MANET), a similar point was stated regarding network
   mobility in LoWPAN environments.

   This document presents mobility scenarios and suggests solutions of
   how to provide mobility support in 6LoWPANs.

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

1.2.  Terms Used

   o  Reduced-Function Device (RFD): RFDs are intended for applications
      that are extremely simple, such as a light switch or a passive
      infrared sensor; they can be implemented using minimal resources
      and memory capacity.  RFDs are not able to transmit MAC layer
      beacons, and can only communicate with FFDs in a master/slave star
      topology.  RFDs may only associate with a single FFD at a time.

   o  Full-Function Device (FFD): A device implementing the complete
      protocol set.  FFDs have the possibility to send MAC layer beacon
      frames in order to indicate their presence to other FFDs or RFDs.
      FFDs can talk to RFDs or other FFDs, while an RFD can talk only to
      an FFD.

   o  Coordinator-Function Device (CFD): A full-function device (FFD)
      acting as the principal LoWPAN coordinator, configured to provide
      synchronization services through the transmission of beacons.  The



Shin, et al.            Expires November 30, 2007               [Page 3]


Internet-Draft         Mobility Support in 6LoWPAN              May 2007


      CFD is responsible for unique address allocation.  A LoWPAN has
      exactly one CFD.

















































Shin, et al.            Expires November 30, 2007               [Page 4]


Internet-Draft         Mobility Support in 6LoWPAN              May 2007


2.  Goals

   Given the unique low-performance properties of LoWPANs, new
   challenges arise of enabling mobility support to devices with highly
   reduced memory and power.  It is therefore crucial to reduce the
   additional mobility related signaling overhead or to possibly avoid
   it altogether.  Especially to optimize power consumption, battery-
   powered devices should be correctly discovered and handled by more
   capable (and possibly mains-powered) devices in the network, such as
   the CFD.  The fundamental goals for mobility support in 6LoWPANs can
   be listed as follows:

   o  Mobile 6LoWPAN devices must be addressable by any corresponding
      node, independent of the current whereabouts.

   o  RFDs are not to be involved in any mobility related signaling.

   o  Reduction of mobility signaling messages for FFDs.

   o  Reuse of existing mobility protocols.































Shin, et al.            Expires November 30, 2007               [Page 5]


Internet-Draft         Mobility Support in 6LoWPAN              May 2007


3.  Scenario Considerations

   Low-power WPAN technology is still in its early stage of development,
   but the range of conceivable usage scenarios is tremendous.  The
   numerous possible applications of sensor networks make it obvious
   that mesh topologies will be prevalent in LoWPAN environments and
   mobility support will be a necessity.

   Mobility based communication can also prolong the lifetime of devices
   and increase the connectivity between nodes and clusters.  Using
   distributed LoWPANs (i.e. sensor networks), it is possible to sculpt
   the devices density to cluster around areas of interest, cover large
   areas, and work more efficiently by filtering local data at the node
   level before it is transmitted or relayed peer-to-peer.  Furthermore,
   multiple controlled mobile elements can be used to provide load
   balancing for gathering data.  The required mobility is heavily
   dependent on the individual service scenario and the LoWPAN
   architecture.  This document covers the following scenarios for
   mobility support in 6LoWPAN.

   Here are some of the key elements of an IEEE 802.16 network.  Figure
   1 illustrates the key elements of typical mobile 802.16 deployments.

   o Device movement (e.g., FFD or RFD) within a single WPAN domain

   o Device movement (e.g., FFD or RFD) between multiple WPAN domains

   o Single WPAN movement (e.g., NEMO)

   o MANEMO (nested NEMO)

3.1.  Device Movement (e.g., FFD or RFD) within a Single WPAN Domain

   Device movement within a single WPAN domain comprehends the change of
   location of one LoWPAN device without losing connectivity between the
   CFD/sink-node.  Different behaviours can be expected depending on the
   type of topology used in the LoWPAN.  In star topologies, where there
   is a direct communication between the RFD/FFD and the CFD/sink-node
   (single-hop), the communication is not affected by the device
   mobility if the mobile device stays in the radio range of the CFD/
   sink-node.










Shin, et al.            Expires November 30, 2007               [Page 6]


Internet-Draft         Mobility Support in 6LoWPAN              May 2007


           +----------------------------+
           |               FFD          |
           +----+                       |
           |CFD |      RFD              |
           +----+                       |
           |                 FFD        |
           |      RFD                   |
           |                            |
           +----------------------------+

           Figure 1: Device mobility within a single WPAN domain

   In mesh topologies where the communication between the RFD/FFD and
   the CFD/sink-node is multi-hop the mobility needs to be supported by
   the routing protocol used within the LoWPAN.  In this scenario it is
   important to distinct the RFD/FFD mobility from the CFD/sink-node
   mobility.

3.2.  Device Movement (e.g., FFD or RFD) between Multiple WPAN Domains

   In this scenario the LoWPAN devices move between different WPAN
   domains as illustrated in the Fig. 2.  By changing from the WPAN1
   controlled by the CFD1 to the WPAN2 each device (e.g.  RFD and FFD)
   needs to advertise the CFD2 of its presence in order to receive new
   interface configurations.  Due to the LoWPAN devices characteristics
   it is necessary to adjust MIPv6 behavior to such networks.  Moreover
   it is important to understand that RFD represents several limitations
   regarding FFD, meaning that each one will have different roles
   regarding the handover process.

     +-----------------+      +------------------+
     |      FFD        |      |     FFD          |
     |            +----+      +----+             |
     |     FFD    |CFD1|      |CFD2|      RFD    |
     |            +----+      +----+             |
     |                 |      |                  |
     |            RFD  >------>  RFD             |
     |            FFD  >------>  FFD             |
     +-----------------+      +------------------+

        Figure 2: Device mobility between multiple WPAN domains(1)

   Another consideration should be made if the moving LoWPAN device is
   the CFD1.  In this case, such device will act as a CFD until he finds
   another CFD responsible for a new domain.  Fig. 3 illustrates the
   situation when the sink-node (CFD1) moves from his domain to another
   domain becoming a common FFD, after negotiating with CFD2.  The
   former domain of CFD1 will need to elect a new CFD, in the example



Shin, et al.            Expires November 30, 2007               [Page 7]


Internet-Draft         Mobility Support in 6LoWPAN              May 2007


   the CFD3.

     +-----------------+      +------------------+
     |      FFD        |      |     FFD          |
     |    +----+       |      +----+             |
     |    |CFD3|       |      |CFD2|      RFD    |
     |    +----+       |      +----+             |
     |            +----+      |                  |
     |   RFD      |CFD1|------>  FFD             |
     |            +----+      |                  |
     +-----------------+      +------------------+

        Figure 3: Device mobility between multiple WPAN domains(2)

3.3.  Single WPAN Movement (e.g., NEMO)

   In this scenario we consider the aggregation of nodes (FFDs and RFDs)
   in clusters, with the introduction of an elected node that will work
   as a Coordinator Function Device (CFD).  This node will be
   responsible for the management of the cluster communication with the
   external networks.

                    +----------------------------+
                    |               FFD          |
    +----------+    +----+                       |
    | External |--- |CFD |      RFD              |
    | Network  |    +----+                       |
    +----------+    |                 FFD        |
                    |      FFD                   |
                    |                            |
                    +----------------------------+

                          Figure 4: WPAN mobility

   In this section the WPAN is considered indivisible and presents
   mobility as an entity.  Moreover, we consider a mobile WPAN as a leaf
   network, as it does not carry transit traffic.

   The CFD must be a FFD, as it requires supplementary functionalities
   when compared with RFDs, as extra processing and energy power.  None
   of the FFDs and RFDs behind the CFD need to be aware of the WPAN
   mobility, being its movement completely transparent to those devices
   inside the mobile WPAN.  The protocols that support the WPAN movement
   are very dependent of the following issues:

   - Application requirements

   - Level of mobility of WPAN



Shin, et al.            Expires November 30, 2007               [Page 8]


Internet-Draft         Mobility Support in 6LoWPAN              May 2007


   The level of mobility of the WPAN requires different routing updates.
   It is crucial that the routing protocol optimize the traffic routes
   as the energy consumption is critical in node forwarding.  Using the
   CFD concept is possible to create an architecture that reduces the
   energy consumed in WPAN movement, and thus increasing performance in
   these networks.

   The IPv6 [RFC2460] supports natively the mobility.  Moreover, in
   contrast with IPv4, IPv6 offers extra functionalities for router
   optimization.  However, it presents overheads and the routing is not
   optimal in the case of network mobility.  The Nemo working group
   [RFC3963] that studies these scenarios, has already proposed a simple
   solution to transparently solve, part of the present needs.  However
   the applicability to LowPAN networks is not trivial and requires
   extra adaptability to its limited characteristics.  The new
   challenges in providing mobility for WPANs include resource
   management, network coverage, network lifetime, topology change,
   routing protocols, security, data reliability, QoS and timely
   dissemination.  These challenges affect the performance of the mobile
   WPANs.

3.4.  MANEMO - Nested NEMO

   In these scenarios, terminal devices or WPANs inside a WPAN could
   present mobility support, travelling to other fixed or mobile WPANs.
   These entities can move inside or outside high-level WPANs, forming
   nested entities.  Sink node mobility, as a unique entity, was
   presented as a special case in sections 3.1 and 3.2.

                     +----------------------------+
                     |               FFD          |
     +----------+    +----+                       |
     | Exterior |--- |CFD |      RFD              |
     +----------+    +----+                       |
                     |                 FFD        |
                     |      FFD      +--------+   |
                     |               |  WPAN  |   |
    +------+         |               +--------+   |
    | WPAN |         |   RFD                      |
    +------+         +----------------------------+


                         Figure 5: MANEMO mobility

   In these scenarios, due to its properties, several issues need to be
   covered (i.e. route optimization, bandwidth and encapsulation
   overhead).




Shin, et al.            Expires November 30, 2007               [Page 9]


Internet-Draft         Mobility Support in 6LoWPAN              May 2007


   In nested networks - in more complex scenarios, the problems are more
   accentuated and need several improvements and adaptations.  Even if
   we use the redirect IPv6 properties [RFC3775], there stills to exist
   indirection and overhead, which is more critical when there are
   several hierarchical levels.

   Among the open research problems, real time solutions that result in
   low mobile device speeds and cooperation between multiple mobile
   devices stand out as challenges that have significant impact.










































Shin, et al.            Expires November 30, 2007              [Page 10]


Internet-Draft         Mobility Support in 6LoWPAN              May 2007


4.  Mobility Support in 6LoWPAN

   In this section, some solutions and optimization techniques for each
   scenario described in section 3 will be described.

4.1.  Device Movement (e.g., FFD or RFD) within a Single WPAN Domain

   In this scenario, there is no need to define mobility protocols
   additionally.  The mobility can be supported by the routing protocol
   used within the 6LoWPAN.  The first way to achieve this goal is to
   re-use existing MANET protocols without making any modifications.
   (e.g., AODV, OLSR, DYMO, Etc.)

   However, the modification or simplification of existing MANET routing
   protocols may be required for dynamic routing to be feasible in a
   LoWPAN domain, because other requirements apply to LoWPAN devices.
   Unlike MANET devices, LoWPAN nodes are characterized by much lower
   power supplies, smaller memory sizes, and lower processing power,
   which create new challenges on obtaining robust and reliable dynamic
   routing within LoWPANs.

   There exists a trade-off relationship between routing effectiveness
   and the requirements posed upon the devices participating in a
   dynamic network.  The challenge is to create a balance between
   protocol simplicity and routing performance.  But stripping down
   existing protocols to power-aware, low-overhead protocols decreases
   the efficacy and functionality of their sophisticated routing
   techniques, or possibly even endangers the goals they were designed
   for.  The issues is being discussed now in [I-D.dokaspar-6lowpan-
   routreq].

   The other way is to develop a new routing protocol for 6LoWPAN.  The
   work is also being discussed in [I-D.culler-rsn-routing-reqs] and is
   especially focused on sensor networks.  Considering the variety of
   sensor based applications, there may not be a single routing protocol
   satisfying the entire list of requirements, in which case it may be
   decided to define a limited set of routing protocols that could be
   combined to satisfy the overall objective.

4.2.  Device Movement (e.g., FFD or RFD) between Multiple WPAN DomainsS

   In this scenario, MIPv6 [RFC3775] could be considered for mobility
   solutions.  However, as listed in goals, RFDs should not to be
   involved in any MIPv6 mobility related signaling and mobility
   signaling messages in FFD should be reduced if possible.

   To support efficiently this scenario, network-based mobility
   management approach (e.g., Proxy MIPv6 [I-D.ietf-netlmm-proxymip6])



Shin, et al.            Expires November 30, 2007              [Page 11]


Internet-Draft         Mobility Support in 6LoWPAN              May 2007


   would be preferred.

   The goals of network-based mobility management approach [RFC 4831]
   are:

   o  Handover Performance Improvement

   o  Reduction in Handover-Related Signaling Volume

   o  Location Privacy

   o  Limit Overhead in the Network

   o  Simplify Mobile Node Mobility Management Security by Deriving from
      IP Network Access and/or IP Movement Detection Security

   o  Link Technology Agnostic

   o  Support for Unmodified Mobile Nodes

   o  Reuse of Existing Protocols Where Sensible

   o  Localized Mobility Management Independent of Global Mobility
      Management

   o  Configurable Data Plane Forwarding between Local Mobility Anchor
      and Mobile Access Gateway

   Almost of the goal above fits to our goals for mobility support in
   6LoWPAN described in section 2.

   Host-based mobility protocols (e.g., MIPv6) require a number of
   periodic signaling messages (e.g, Binding Update in MIPv6) at end
   devices.  It can increase power consumption.  In network-based
   mobility protocols does not require any mobility protocols in end
   devices.  Instead, gateway (CFD) performs mobility functions (e.g.,
   Proxy BU).

   At this phase, current PIMv6 defines the device-to-gateway interface
   applied in a single-hop.  However, in this scenario, multi-hop and
   mesh topologies should be considered.  So, to use PMIPv6 in 6LoWPAN,
   the interface for multi-hop and mesh topologies between devices and
   gateway (CFD) should be extended and defined (e.g., ad-hoc manner
   support).







Shin, et al.            Expires November 30, 2007              [Page 12]


Internet-Draft         Mobility Support in 6LoWPAN              May 2007


4.3.  Single WPAN movement (e.g., NEMO)

   This scenario is exactly the same as that of NEMO.  NEMO support
   [I-D.ietf-nemo-requirements] is concerned with managing the mobility
   of an entire network, viewed as a single unit, which changes its
   point of attachment to the Internet and thus its reachability in the
   Internet topology.  Such a network is referred to as a mobile network
   and includes one or more mobile routers (MRs) which connect it to the
   global Internet.  So, in this scenario a mobility network and MRs are
   mapped into WPAN and CFDs, respectively.

   To support this scenario, basic NEMO support protocol [RFC3963]
   should be supported in 6LoWPAN.

4.4.  MANEMO - Nested NEMO

   MANEMO is a special case for Nested NEMO.  When mobile routers (CFDs)
   and mobile nodes (RFDs/FFDs) converge at the edge of the Internet
   using wireless interfaces, they can form a 6LoWPAN network in an ad-
   hoc fashion and are able to provide Internet connectivity to one
   another.  Several issues exist in this network configuration such as
   network loop, un-optimized path and multiple exit routers to the
   Internet.  They are well-known MANEMO' issues.  While fixed routers
   provide constantly connectivity, mobile routers (CFDs) can experience
   intermittent connectivity to the Internet due to their movement.
   When NEMO Basic Support [RFC3963] is used in this context, network
   loops naturally occur.  So, a new MANEMO solution is required in
   6LoWPAN.

   MANEMO solution is not finalized yet and it is at initial stage.  If
   it is done, to support this scenario, it should be also supported in
   6LoWPAN.



















Shin, et al.            Expires November 30, 2007              [Page 13]


Internet-Draft         Mobility Support in 6LoWPAN              May 2007


5.  IANA Considerations

   This document requests no action by IANA.
















































Shin, et al.            Expires November 30, 2007              [Page 14]


Internet-Draft         Mobility Support in 6LoWPAN              May 2007


6.  Security Considerations

   RFD nodes must have a means of identifying friendly nodes and
   distinguishing them from not trusted nodes.  Especially if the RFDs'
   mobility support is handled by an FFD or CFD, there must be some way
   for the RFD to tell whether that more capable device can be trusted
   or not.

   More to be defined.










































Shin, et al.            Expires November 30, 2007              [Page 15]


Internet-Draft         Mobility Support in 6LoWPAN              May 2007


7.   Acknowledgements

   TBD
















































Shin, et al.            Expires November 30, 2007              [Page 16]


Internet-Draft         Mobility Support in 6LoWPAN              May 2007


8.  References

8.1.  Normative References

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

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

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

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
              Thubert, "Network Mobility (NEMO) Basic Support Protocol",
              RFC 3963, January 2005.

8.2.  Informative References

   [RFC4831]  Kempf, J., "Goals for Network-Based Localized Mobility
              Management (NETLMM)", RFC 4831, April 2007.

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

   [I-D.dokaspar-6lowpan-routreq]
              Kaspar, D., "Design Goals and Requirements for 6LoWPAN
              Mesh Routing", draft-dokaspar-6lowpan-routreq-01 (work in
              progress), March 2007.

   [I-D.ietf-netlmm-proxymip6]
              Gundavelli, S., "Proxy Mobile IPv6",
              draft-ietf-netlmm-proxymip6-00 (work in progress),
              April 2007.

   [I-D.ietf-nemo-requirements]
              Ernst, T., "Network Mobility Support Goals and
              Requirements", draft-ietf-nemo-requirements-06 (work in
              progress), November 2006.

   [I-D.chakrabarti-mobopts-lowpan-req]
              Park, S. and S. Chakrabarti, "LowPan Mobility Requirements



Shin, et al.            Expires November 30, 2007              [Page 17]


Internet-Draft         Mobility Support in 6LoWPAN              May 2007


              and Goals", draft-chakrabarti-mobopts-lowpan-req-01 (work
              in progress), March 2007.

















































Shin, et al.            Expires November 30, 2007              [Page 18]


Internet-Draft         Mobility Support in 6LoWPAN              May 2007


Authors' Addresses

   Myung-Ki Shin
   ETRI
   161 Gajeong-dong Yuseng-gu
   Daejeon, 305-350
   Korea

   Phone: +82 42 860 4847
   Email: myungki.shin@gmail.com


   Tiago Camilo
   University of Coimbra

   Email: tandre@dei.uc.pt


   Jorge Sa Silva
   University of Coimbra

   Email: sasilva@dei.uc.pt


   Dominik Kaspar
   ETRI
   161 Gajeong-dong Yuseng-gu
   Daejeon, 305-350
   Korea

   Phone: +82 42 860 1702
   Email: dominik@etri.re.kr



















Shin, et al.            Expires November 30, 2007              [Page 19]


Internet-Draft         Mobility Support in 6LoWPAN              May 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.


Acknowledgment

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





Shin, et al.            Expires November 30, 2007              [Page 20]


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