[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03                                                   
MIP6 Working Group                                   Soohong Daniel Park
Internet-Draft                                                    M. Lee
Intended status: Best Current                        Samsung Electronics
Practice                                                     J. Korhonen
Expires: August 1, 2007                                      TeliaSonera
                                                                J. Zhang
                                                 Cambridge Silicon Radio
                                                        January 28, 2007


             Link Characteristics Information for Mobile IP
              draft-daniel-mip-link-characteristic-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 August 1, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document introduces a model for link characteristic information
   delivery from the mobile node to the home agent and correspondent
   node(s).  This model allows the home agent and correspondent node(s)
   to know the characteristics of the link the mobile node is currently



Park, et al.             Expires August 1, 2007                 [Page 1]


Internet-Draft      Link Characteristics Information        January 2007


   attached to.  Based on this information, the home agent and
   correspondent node(s) may shape ongoing traffic according to the
   current available link capacity (e.g. bandwidth) to the mobile node.
   This model can be applicable for Mobile IPv4 as well as Mobile IPv6.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Link Characteristic Information Option for Mobile IPv6 . . . .  4
   4.  Operational Considerations . . . . . . . . . . . . . . . . . .  6
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   8.  Appendix A (Informative) - Option Usage Examples . . . . . . .  8
     8.1.  Vertical Handover from a GPRS Link to an 802.11b Link  . .  8
     8.2.  Vertical Handover from an 802.11b Link to a GPRS Link  . .  9
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
   Intellectual Property and Copyright Statements . . . . . . . . . . 12




























Park, et al.             Expires August 1, 2007                 [Page 2]


Internet-Draft      Link Characteristics Information        January 2007


1.  Introduction

   Mobile IP [2], [3] allows a mobile node to maintain its existing
   connections while changing its access link.  This is achieved through
   the mechnism of mobility binding management at the home agent and
   optionally correspondent node(s) with the assistance of the mobile
   node's notifications of its current location.

   Recently more and more mobile nodes are equipped with multiple
   interfaces for different L2 technologies.  These mobile nodes may be
   reachable through different links at the same time or use each
   interface alternately depending on the network environment.  In the
   latter case, transitions between heterogeneous links (vertical
   handovers) occur.  Mobile IP, however, does not provide a mechanism
   to indicate which type of link the mobile node is attached to.
   Therefore, sudden changes of access link characteristics caused by
   vertical handovers are usually not quickly observed by higher layer
   applications until a certain mechanism (e.g. congestion control or
   error recovery mechanism) is invoked some time later when it senses a
   misuse of the network capacity.  This can cause undesirable
   disruptions or performance degradation to the ongoing connections.
   For example, when the mobile node performs a handover from an IEEE
   802.11b WLAN link (high bandwidth link) to a CDMA cellular link (low
   bandwidth link), the home agent and correspondent nodes may still
   send their traffic to the mobile node as if the 802.11b bandwidth is
   still available.  Thus, the ratio of packet loss will eventually
   increase.

   In some cases, the mobile node's available bandwidth may also vary
   considerably on handovers between the same type of links (horizontal
   handovers) due to the different traffic loads on the old and the new
   link.  Moreover, even the mobile node stays on the same link, the
   available bandwidth may change significantly due to the variations of
   the traffic load on current link.  Both of these situations may lead
   to similar adverse effects as vertical handovers.

   This document introduces a new model for link characteristic
   information delivery from the mobile node to the home agent and
   correspondent node(s).  The purpose of this model is to let the home
   agent and correspondent node(s) properly shape their traffic to the
   mobile node according to the mobile node's current access link
   characteristics.  This model can be applicable for both Mobile IPv6
   [3] and Mobile IPv4 [2].  However, to illustrate this model
   concisely, only Mobile IPv6 is considered in this document.  A new
   mobility option called Link Characteristic Information Option is
   defined to carry link characteristics (e.g., current link bandwidth,
   link type, and other relevant information to be extended) to the home
   agent and correspondent node(s).  This option SHOULD be included in



Park, et al.             Expires August 1, 2007                 [Page 3]


Internet-Draft      Link Characteristics Information        January 2007


   the Binding Update message on vertical handovers or when the mobile
   node senses a significant link characteristic change.  The method
   used by the mobile node to obtain the current link characteristic
   information is implementation dependent (e.g. enhancing the wireless
   access device driver functions or using the 802.21 utility), and is
   therefore out of the scope of this document.  For Mobile IPv4, the
   option can be defined following the Type-Length-Value extension
   format, and can be carried by the Registration Request message.


2.  Requirements

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


3.  Link Characteristic Information Option for Mobile IPv6

   The Link Characteristic Information Option is a new mobility option
   that MAY be carried in the Mobile IPv6 Binding Update message.
   Various link types and characteristic information (e.g. bandwidth)
   can be delivered to the home agent and correspondent node(s) from the
   mobile node.  The subtype field in the option defines the specific
   link type.  Other link information such as the current estimated
   available bandwidth is encoded in the Link Characteristic Information
   field.

   This option SHOULD be carried in the Binding Update message on
   vertical handovers or when the mobile node senses a significant link
   characteristic change by some means out of the scope of this
   document.  The trigger of sending the option by the mobile node is an
   implementation issue.  For example, a bandwidth change threshold
   could be defined.  Only when the available bandwidth change exceeds
   the threshold, should the mobile node initiate a Link Characteristic
   Information option to be delivered.  Further study is required to
   determine the optimal threshold for different link types and ongoing
   applications.



    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Option Type  | Option Length |    Subtype    |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Link Characteristic Information...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Park, et al.             Expires August 1, 2007                 [Page 4]


Internet-Draft      Link Characteristics Information        January 2007


          Link Characteristic Information Option for Mobile IPv6

   o  Option Type: 8-bit identifier of the type of the mobility option.
      To be defined by IANA.

   o  Option Length: 8-bit unsigned integer, representing the length of
      the Link Characteristic Information Option in octets, excluding
      the Option Type and Option Length fields.

   o  Subtype: 8-bit identifier (as shown in the following table),
      indicating the type of the link the mobile node currently
      accesses.

      Subtype        Link Type
      ----------------------------------------------
      0              LAN  (802.3)
      1              WLAN (802.11b)
      2              WLAN (802.11a)
      3              WLAN (802.11g)
      4              WLAN (802.11n)
      5-15           Reserved for (W)LAN Extensions
      16             CDMA
      17             GPRS
      18             UMTS
      19-31          Reserved for Cellular Networks
      32-47          802.15 Family Networks
      48-63          802.16 Family Networks
      64             Bluetooth
      65             Virtual (the physical link type is irrelevant)
      66-255         Reserved
      ----------------------------------------------

   o  Reserved: MUST be set to zero when sending this option and ignored
      when receiving this option.

   o  Link Characteristic Information: A variable length field that
      contains the current available bandwidth information and possibly
      other to-be-defined link information for a specific link type as
      specified in the subtype field.  The ABNF below describes how the
      Link Characteristic Information field MUST be constructed:

      link-info = link-info-data
      link-info =/ link-info-data "," 1*info-label
      link-info =/ 1*info-label "," link-info-data
      link-info-data = "bw=" 1*DIGIT
      bandwidth = "kbps" / "Mbps" / "kB" / "Gbps"





Park, et al.             Expires August 1, 2007                 [Page 5]


Internet-Draft      Link Characteristics Information        January 2007


      info-label = ALPHA / DIGIT

      The "ALPHA" and "DIGIT" rules are defined in [4].

      This option does not have any alignment requirements.


4.  Operational Considerations

   The binding cache is a table maintained by the home agent and each
   correspondent node that contains the current mobility bindings for
   mobile nodes.  To store link characteristic information at the home
   agent and correspondent node(s), one entry MUST be contained in the
   binding cache for each mobility binding.  Similarly the mobile node
   MUST have one entry in every item in its binding update list to store
   the link characteristic information the mobile node has sent to other
   network nodes (i.e. home again, correspondent nodes).

   The home agent and correspondent node(s) MUST recognize the Link
   Characteristic Information Option in the Binding Update message in
   order for them to properly shape their traffic to the mobile node or
   dynamically adjust their services.  Otherwise, this option is
   silently discarded by the home agent and correspondent node(s).
   Moreover, this option MUST be silently discarded if the Binding
   Update message fails to be authenticated.

   On receipt of a Binding Update message with the Link Characteristic
   Information Option, correspondent node(s) SHOULD control their
   traffic amount or pattern sent to the mobile node according to the
   link characteristics (i.e. available bandwidth as currently defined)
   specified in the option.  To perform traffic controls, correspondent
   node(s) SHOULD implement an interface for communications between IP
   layer and upper layer mechanisms (e.g.  TCP, media application codec,
   etc.).  However, the specific control method is out of the scope of
   this document.

   On receipt of a Binding Update message with the Link Characteristic
   Information Option, the home agent SHOULD control its traffic amount
   or pattern sent to the mobile node according to the link
   characteristics.  This is helpful when the mobile node is
   communicating with any of its correspondent node(s) in non-route-
   optimization mode (i.e. the bi-directional tunneling mode, in which
   case the correspondent node does not receive Binding Update messages
   and traffic go through the home agent).  However, the specific
   control method is out of the scope of this document.

   For example, an ongoing connection is using a bandwidth of 10Mbps,
   while the available bandwidth specified in the Link Characteristic



Park, et al.             Expires August 1, 2007                 [Page 6]


Internet-Draft      Link Characteristics Information        January 2007


   Information Option is 1Mbps.  The home agent or correspondent node
   receiving this option SHOULD reduce its traffic forwarding rate.

   Link characteristic information SHOULD be provided by the mobile node
   in the Binding Update message on vertical handovers or when the
   mobile node senses a significant link characteristic change by some
   means out of the scope of this document, in order to guide the home
   agent and correspondent node(s) to shape their traffic.  The trigger
   of sending the option by the mobile node is an implementation issue.

   In the case that the mobile node has multiple correspondent nodes, in
   order for the model defined in this document to work well, the mobile
   node SHOULD have a certain capacity (i.e. bandwidth as currently
   defined) assignment algorithm to determine the share for each of
   them, and specify it (the share) in the Link Characteristic
   Information Option in the corresponding Binding Update message.  The
   total capacity (i.e. bandwidth as currently defined) specified in all
   concurrent Link Characteristic Information Options SHOULD not exceed
   the maximum capacity available to the mobile node on the current
   access link.  The capacity assignment algorithm is out of the scope
   of this document.

   This document only defines the available bandwidth as link
   characteristic information.  However, there is no restriction to add
   other available link information in the Link Characteristic
   Information Option if required.  Furthermore, the Link Characteristic
   Information Option as such is also applicable when Mobile IPv6 is
   used in proxy mode [5].  In this particular case the source of the
   information is the local proxy node representing the mobile node.
   The use case could be the access network signaling the allowed
   capacity to the mobile node to the correspondent nodes along with the
   Mobile IP signaling.


5.  Security Considerations

   Potentially, the model proposed in this document may be misused by an
   attacker to indicate fabricated available bandwidth information to
   the home agent or correspondent node(s).  However, the Link
   Characteristic Information Option is carried by the Binding Update
   message, which are always supposed to be protected by IPsec [6] or
   the binding management key (Kbm) [3] established beforehand.
   Attackers who have the capability of fabricating a valid Binding
   Update message are able to launch more serious attacks than those
   potentially caused by this model.  Therefore, it is believed that the
   use of the Link Characteristic Information Option does not bring new
   security vulnerabilities to Mobile IP.




Park, et al.             Expires August 1, 2007                 [Page 7]


Internet-Draft      Link Characteristics Information        January 2007


6.  IANA Considerations

   A new Mobile IPv6 Mobility Option type is required for the following
   new mobility option described in section Section 3:

       Link Characteristic Information Option       is set to TBD

   Also, IANA needs to allocate a new Link Characteristic Information
   Option (TBD) namespace for the subtype field described in section
   Section 3:

       Subtype        Link Type
       ----------------------------------------------
       0              LAN  (802.3)
       1              WLAN (802.11b)
       2              WLAN (802.11a)
       3              WLAN (802.11g)
       4              WLAN (802.11n)
       5-15           Reserved for (W)LAN Extensions
       16             CDMA
       17             GPRS
       18             UMTS
       19-31          Reserved for Cellular Networks
       32-47          802.15 Family Networks
       48-63          802.16 Family Networks
       64             Bluetooth
       65             Virtual
       66-255         Reserved


7.  Acknowledgements

   The authors would like to acknowledge Rajeev Koodli, Bongkyo Moon,
   Pyungsoo Kim and Junghoon Jee for their useful comments.


8.  Appendix A (Informative) - Option Usage Examples

8.1.  Vertical Handover from a GPRS Link to an 802.11b Link

   The example below shows the link characteristic information
   notification when the mobile node performs a vertical handover from a
   46kbps GPRS link to an 11Mbps 802.11b link.  During the Binding
   Update procedure the mobile node deliveries its new access link
   bandwidth to the home agent (in bi-directional tunneling mode) or the
   correspondent node (in route optimization mode).  After receiving the
   Binding Update message, the home agent or the correspondent node
   adjusts its traffic sending rate towards the mobile node to take



Park, et al.             Expires August 1, 2007                 [Page 8]


Internet-Draft      Link Characteristics Information        January 2007


   advantage of the reported increased bandwidth.


      mobile node                       home agent / correspondent node
           |                                               |
   attach to GPRS link                                     |
           |           data (with GPRS bandwidth)          |
           |<----------------------------------------------|
   handover to 802.11b link                                |
           |               Binding Update                  |
           |---------------------------------------------->|
           |  (subtype: 802.11b; info: bandwidth=11Mbps)   |
           |                                               |
           |       Binding Acknowledgement (if sent)       |
           |<----------------------------------------------|
           |                               adjust traffic sending rate
           |         data (with 802.11b bandwidth)         |
           |<----------------------------------------------|
           |                                               |

                                 Example 1

8.2.  Vertical Handover from an 802.11b Link to a GPRS Link

   The following example shows the link characteristic information
   notification when the mobile node performs a vertical handover from
   an 11Mbps 802.11b link to a 46kbps GPRS link.  During the Binding
   Update procedure the mobile node delieveries its new access link
   bandwidth to the home agent (in bi-directional tunneling mode) or the
   correspondent node (in route optimization mode).  After receiving the
   Binding Update message the home agent or the correspondent node
   reduces its traffic sending rate towards the mobile node to match the
   reported decreased bandwidth.


















Park, et al.             Expires August 1, 2007                 [Page 9]


Internet-Draft      Link Characteristics Information        January 2007


      mobile node                        home agent / correspondent node
           |                                               |
   attach to 802.11b link                                  |
           |         data (with 802.11b bandwidth)         |
           |<----------------------------------------------|
   handover to GPRS link                                   |
           |               Binding Update                  |
           |---------------------------------------------->|
           |    (subtype: GPRS; info: bandwidth=46kbps)    |
           |                                               |
           |       Binding Acknowledgement (if sent)       |
           |<----------------------------------------------|
           |                                 adjust traffic sending rate
           |          data (with GPRS bandwidth)           |
           |<----------------------------------------------|
           |                                               |

                                 Example 2


9.  References

9.1.  Normative References

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

9.2.  Informative References

   [2]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
        August 2002.

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

   [4]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

   [5]  Gundavelli, S., "Proxy Mobile IPv6",
        draft-sgundave-mip6-proxymip6-01 (work in progress),
        January 2007.

   [6]  Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
        Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
        Agents", RFC 3776, June 2004.

   [7]  Haley, B., "Mobility Header Home Agent Switch Message",
        draft-ietf-mip6-ha-switch-02 (work in progress), December 2006.



Park, et al.             Expires August 1, 2007                [Page 10]


Internet-Draft      Link Characteristics Information        January 2007


Authors' Addresses

   Soohong Daniel Park
   Mobile Platform Laboratory, SAMSUNG Electronics.
   416 Maetan-3dong, Yeongtong-gu
   Suwon, Gyeonggi-do  443-742
   KOREA

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


   Minho Lee
   Mobile Platform Laboratory, SAMSUNG Electronics.
   416 Maetan-3dong, Yeongtong-gu
   Suwon, Gyeonggi-do  443-742
   KOREA

   Phone: +82 31 200 3697
   Email: minho03.lee@samsung.com


   Jouni Korhonen
   TeliaSonera Corporation.
   P.O.Box 970
   FIN-00051 Sonera
   FINLAND

   Phone: +358 40 534 4455
   Email: jouni.korhonen@teliasonera.com


   Ji Zhang
   Fix Mobile Convergence Solutions, Cambridge Silicon Radio Ltd.
   Cambridge Business Park, Cowley Road
   Cambridge  CB4 0WZ
   United Kingdom

   Phone: +44 1223 692906
   Email: ji.zhang@csr.com











Park, et al.             Expires August 1, 2007                [Page 11]


Internet-Draft      Link Characteristics Information        January 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).





Park, et al.             Expires August 1, 2007                [Page 12]