Internet DRAFT - draft-antoine-mip4-lowlatency-handoff-triggers

draft-antoine-mip4-lowlatency-handoff-triggers





Network Working Group                                   Stephane Antoine
Internet-Draft                                            France Telecom
Intended status: Standards Track                       December 15, 2006
Expires: June 18, 2007


     Using Higher Layer Triggers for Low Latency Handoffs in MIPv4
           draft-antoine-mip4-lowlatency-handoff-triggers-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.
   This document may not be modified, and derivative works of it may not
   be created.

   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 June 18, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2006).

Abstract

   This document introduces the use of triggers coming from layers
   higher than the link layer to initiate the Low Latency Handoff in
   Mobile IPv4 (MIPv4) .  The Low Latency Handoff for MIPv4 assumes
   availability of Layer 2 (L2) triggers that contain Layer 3 (L3)
   information for the Mobile Node (MN) to handoff.  However, the low
   latency draft does not describe the method by which the L2 trigger is



Stephane Antoine          Expires June 18, 2007                 [Page 1]

Internet-Draft   Higher Layer Trigger Low Latency MIPv4    December 2006


   produced neither does it explicitly describe by what mechanism the L3
   information present in the L2 trigger is acquired.  The Low Latency
   Handoff for MIPv4 relies on availability of the L2 trigger.  However
   relying only on the link information to initiate a handoff does not
   generally gather enough information for the MN to handoff to the most
   suitable available access network.  Information from higher layers
   such as Higher Layer Triggers can be used to command a MN to quickly
   move from one access to another one.  Using Higher Layer Triggers to
   initiate the handoff enables the implementation of policy based
   handoff to garantee load balancing of the wireless networks and
   Quality of Services to the end users.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Inadequacies of relying on Layer 2 triggers alone for Low
       Latency Handoffs  . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     5.1.  Scenario 1  . . . . . . . . . . . . . . . . . . . . . . . . 5
     5.2.  Scenario 2  . . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Using Higher Layer Triggers to initiate the Low Latency
       Handoff in MIPv4  . . . . . . . . . . . . . . . . . . . . . . . 6
     6.1.  Pre-Registration handoff  . . . . . . . . . . . . . . . . . 6
       6.1.1.  Network initiated:  . . . . . . . . . . . . . . . . . . 6
       6.1.2.  Mobile initiated: . . . . . . . . . . . . . . . . . . . 7
     6.2.  Post-Registration Handoff . . . . . . . . . . . . . . . . . 7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   8.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   10. Normative References  . . . . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9
















Stephane Antoine          Expires June 18, 2007                 [Page 2]

Internet-Draft   Higher Layer Trigger Low Latency MIPv4    December 2006


1.  Introduction

   Low Latency Handoffs in MIPv4 [LOWLATMIP4] introduces a method that
   achieves low latency for Mobile IPv4 in support of real-time
   services.  The two methods presented in to achieve low latency are
   based on reception of various Layer 2 triggers on the MN and the
   Foreign Agent (FA).  The Layer 2 trigger introduced in [LOWLATMIP4]
   informs L3 of a particular event before L2 handoff actually takes
   place.  The Low Latency Handoff in MIPv4 is only initiated just
   before the L2 handoff takes place as indicated by the L2 triggers.
   L2 trigger usually occurs when the signal strength reaches a critical
   level that requires a handoff to take place.  However, handoff may be
   needed upon reception of parameters other than the ones related to
   the relative signal strength received.  L2 trigger indicating that
   the MN has just entered the coverage area of a WLAN network is not
   enough indication to handoff to the most suitable network at the most
   suitable time.  A Mobile Node which is simultaneously connected to
   several networks, does not necessarily have enough information to
   initiate the handoff from its default network to a most prefered
   access network.  Due to lack of additional information, the MN may
   stay connected to an acces network that may turn out to be more
   costly for the MN than another available one.  The lack of
   information, can cause the MN to stay connected to one access network
   that does not offer the MN the best quality of service.  This lack of
   informmation, prevents the management of load sharing mechanisms on
   different access networks to suit several subscribers having
   different profiles.  Higher Layer Triggers or Handoff Commands in
   response to a policy decision can trigger the MN handoff to the most
   preferable available network at the most suitable time.  The Higher
   Layer Trigger or Handoff Command comes from a Network Node or from
   the MN itself.  Higher Layer Trigger or a Handoff Command may trigger
   a MIPv4 handoff even without indication of a pending L2 handoff.
   Implementing the Higher Layer Handoff Trigger is compatible with
   [LOWLATMIP4].  One can design a system in which a Higher Layer
   Trigger or a Handoff Command is used to generate a L2 trigger that
   subsequently initiates the Low Latency Handoff in MIPv4.  In case
   urgent handoff is needed as indicated by a pending L2 handoff, the
   low latency takes place even if no Higher Layer Trigger has been
   received.


2.  Terminology

   This section introduces the Handoff Command and the Higher Layer
   Handoff Trigger.

   Handoff Command - It is a message sent by an entity in the network to
   instruct the MN to initiate a handoff.



Stephane Antoine          Expires June 18, 2007                 [Page 3]

Internet-Draft   Higher Layer Trigger Low Latency MIPv4    December 2006


   Higher Layer Handoff Trigger - It is a trigger that comes from a
   layer higher than Layer 2.  The Higher Layer Handoff Trigger can come
   from Layer 3 or the application layer.  The Higher Layer Handoff
   Trigger may have been generated locally by the entity receiving the
   trigger.  It may also have been generated by a Network Node other
   than the node receiving the trigger.  The Higher Layer Handoff
   Trigger may be received as an IP message initiated from the network
   (Handoff Command).  The entity receiving the Higher Layer Handoff
   Trigger is either the MN or the FA or another entity in the network
   such as the Access Router (AR) that could subsequently interacts
   directly with the MN at layer 2.  The Higher Layer Handoff Trigger
   can generate the Layer 2 trigger.


3.  Motivation

   The Higher Layer Trigger or Handoff Command coming from the Network
   or the MN serves to implement policy based network controlled
   handoffs.  A network operator can command a set of users to handoff
   to different networks to provide load sharing on its different access
   networks.  The network operator can selectively command Mobile Nodes
   to handoff to different access networks to provide a level of Quality
   of Service to different users according to their user profiles.  The
   Higher Layer Trigger that comes from the MN application can initiate
   handoff when the quality of the application becomes poor.  For a
   Voice over IP application for example, the perceived quality of the
   voice can serve as a Trigger to the MN to initiate a handoff to a
   better network.  Figure 1 and 2 illustrate the initiation of the Low
   Latency Handoff by a Higher Layer Trigger from the network or the MN
   itself.

     MN            oFA/nFA                     Network Node/entity    HA/GFA
     |             |                               |                   |
     |             |Higher Layer Trigger/Command   |                   |
     |             |<------------------------------|                   |
   --|----------------------------------------------------------------------
   | |             |                                                   |   |
   | |             |Low Latency in  MIPv4                              |   |
   | |             |                                                   |   |
   -------------------------------------------------------------------------

   Figure 1: Network initiated, source/target triggered.









Stephane Antoine          Expires June 18, 2007                 [Page 4]

Internet-Draft   Higher Layer Trigger Low Latency MIPv4    December 2006


     MN            oFA           nFA          Network Node/entity    HA/GFA
     |             |              |                |                   |
     |             |Higher Layer Trigger/Command   |                   |
     |<--------------------------------------------|                   |
     |        or   |              |                |                   |
     |Higher Layer Trigger        |                |                   |
     |<~~~~~~      |              |                |                   |
   --|---------------------------------------------------------------------
   | |             |              |                |                   |  |
   | |             |Low Latency in| MIPv4          |                   |  |
   | |             |              |                |                   |  |
   ------------------------------------------------------------------------

   Figure 2: Mobile initiated.


4.   Inadequacies of relying on Layer 2 triggers alone for Low Latency
    Handoffs

   The Low Latency Handoff in MIPv4 relies on L2 triggers as an
   indication of a pending L2 handoff to initiate the early MIPv4
   registration before the L2 handoff actually takes place.  L2 triggers
   although not exactly define in [LOWLATMIP4] correspondent to events
   such as perception of signal noise ratio at the MN or Link Up, Link
   Down, reception of an agent solicitation...  Reception of L2 triggers
   alone is not always sufficient information to rely upon for the
   initiation of the Layer 3 handoff.  Handoff Commands can be used to
   force a handoff even if the signal quality is very good on all of the
   MN's interfaces.  In such scenarios, the handoff triggers coming from
   a higher layer protocol can be used to initiate the L3 handoff
   presented in [LOWLATMIP4].


5.   Scenarios

   A few scenarios can illustrate the application of handoff triggers
   from higher layers to initiate the Low Latency Handoff in MIPv4.

5.1.  Scenario 1

   The handoff trigger comes locally from a Layer 3 or above of the MN
   due to variations or degradation in the application for example.
   Application degradation may be due to increased load in the MN's
   serving network.  The MN can interpret such degradation as a hint for
   an eventual need to handoff to a different access network.  The MN
   may generate a scan to obtain the identifier of other networks
   available (BSSID identifier for example of the Access Point that is a
   potential handoff target).  The MN resumes the actions with a Proxy



Stephane Antoine          Expires June 18, 2007                 [Page 5]

Internet-Draft   Higher Layer Trigger Low Latency MIPv4    December 2006


   Router Solicitation (PrRtSol) as in the Pre-Registration Low Latency
   Handoff in MIPv4 case.  Note that scanning of potential new access
   networks may not result in finding a target access network to handoff
   to as the MN may not be in an overlapping networks coverage area.  In
   that case, the hint received (from L3 or the application) would have
   not triggered the handoff.

5.2.  Scenario 2

   A Mobile Node is using a WLAN connection and is simultaneously in the
   coverage area of WLAN and 3G with a good signal reception in WLAN.
   The Link Up on the 3G interface is not necessarily a trigger
   providing sufficient information to initiate the Pre-registration
   with L3 handoff towards 3G. However a network policy may require the
   MN to execute a handoff due to various network conditions and
   policies pre-established.  To achieve policy based network control
   handoff, several techniques can be designed: The MN can collect
   information and send it to the network which ultimately takes the
   decision to instruct the MN or the FA (by a Handoff Command) to
   handoff to a preferred type of available network.  The criterion
   initiating the handoff is not restricted to the signal noise ratio
   perceived at lower layers.  Instead the set of criteria can include
   other parameters such as the link characteristics of available
   networks, the load on the MN serving network and neighbouring access
   networks, the level of quality of service perceived...(Such a
   scenario is the most appealing for network operators as it enables
   the network to initiate and assist the handoff).  One may design a
   system in which Higher Layer Triggers are used to initiate the Low
   Latency Handoff in MIP.


6.   Using Higher Layer Triggers to initiate the Low Latency Handoff in
    MIPv4

6.1.  Pre-Registration handoff

   The MN MAY perform regular scans to obtain information about its
   available networks.  The MN MAY report regularly to a network entity
   such information.  The network entity might then take the decision to
   instruct the MN to handoff.  The handoff trigger from higher layer
   protocol could be received at the FA (Network initiated) or at the MN
   (Mobile initiated).

6.1.1.  Network initiated:

   The MN reports to a central entity (Policy Decision Point) the IP
   addresses of its available FAs obtained through scanning.  Upon
   decision to instruct the MN to handoff to a particular access



Stephane Antoine          Expires June 18, 2007                 [Page 6]

Internet-Draft   Higher Layer Trigger Low Latency MIPv4    December 2006


   network, the network entity will send a Handoff Command to a FA to
   initiate handoff to the target access network.  The termination of
   the Handoff Command can be the oFA (for the source trigger handoff)
   or the nFA (for the target trigger handoff).  The Handoff Command
   could contain the IP address of the nFA it is instructed the MN to
   move to.  The Handoff Command in turn generates the Layer 2 source or
   target trigger in use in the Low Latency Handoff in MIPv4.  The
   Handoff Command when implemented provides a means to pass the IP
   address of the new FA (nFA) or the old FA (oFA) for use in the L2
   trigger.  A method by which the Handoff Command from layer 3
   generates a Layer 2 trigger at the FA is not described in this
   document.

6.1.2.  Mobile initiated:

   The Mobile Initiated Pre-registration handoff can result from a
   Higher Layer Handoff Trigger that originated locally on the MN or
   from a Handoff Command sent from another node in the network.  The
   Handoff Command may contain limited information such as the type of
   the preferred network to move to (i.e 3G or WLAN or WiMAX, the load
   on each network, the QoS ...).  When the MN receives an instruction
   to handoff it can then issue a new scan to obtain the BSSID
   identifier of the Access Point that is a potential handoff target.
   The reception of the BSSID of the target AP can be the layer 2
   trigger that then initiates the Mobile Initiated Pre-registration
   Handoff as in [LOWLATMIP4].

6.2.   Post-Registration Handoff

   The application of Handoff Command towards the Post registration
   handoff is restricted.  As the Post Registration Handoff effectively
   starts with the loss of L2 connectivity with the oFA L2-Link Down
   (L2-LD) it makes it more difficult to initiate it with Higher Layer
   Triggers.


7.  Security Considerations

   This document introduces a framework describing the use of triggers
   coming from layers higher than the link layer to initiate the Low
   Latency Handoff in Mobile IPv4.  The Handoff Layer Triggers MUST be
   secured to provide reliable information to the Low Latency for MIPv4.
   The mechanism causing the delivery of the Triggers MUST also be
   secured and MUST not introduce any vulnerability to the low Latency
   handoff for MIPv4.  Securing the delivery of Higher Layer Triggers
   prevents an attacker in the network to send bogus messages causing
   the MN undesired handoffs.  A Security Association SHOULD exist
   between the Network Node sending the Command and the recipient (the



Stephane Antoine          Expires June 18, 2007                 [Page 7]

Internet-Draft   Higher Layer Trigger Low Latency MIPv4    December 2006


   FA or the MN) of the Higher Layer Trigger.  The establishment of
   these Security Associations are out of the scope of this document.


8.  Conclusion

   This document introduces the use of triggers from layers higher than
   layer 2 to initiate the Low Latency Handoff in MIPv4.  The trigger
   issued from the application or the network layer may in turn generate
   the Layer 2 trigger.  Layer 2 trigger is not necessarily received as
   an indication of a stronger or lower signal received at the MN from
   the access network.  The Higher Layer Trigger coming from the network
   is a Handoff Command which makes it possible to implement policy
   decision based handoff.  According to a policy decision the system
   may command the MN to handoff to the most preferable Access Network.
   The policy based handoff decision may be taken locally on the MN or
   may be implemented on a different node in the network.


9.  Acknowledgements

   The author wish to thank Karim El Malki for reviewing this document
   and for providing useful comments.


10.  Normative References

   [LOWLATMIP4]
              K. El Malki, Editor., "Low Latency Handoffs in Mobile
              IPv4", October  2005.


Author's Address

   Stephane Antoine
   France Telecom
   Chiswick Park
   London, Chiswick  W4 5XS
   United Kingdom

   Phone: + 44 (0)208 849 5821
   Fax:   +44 (0)208 849 0991
   Email: stephane.antoine@orange-ft.com








Stephane Antoine          Expires June 18, 2007                 [Page 8]

Internet-Draft   Higher Layer Trigger Low Latency MIPv4    December 2006


Full Copyright Statement

   Copyright (C) The IETF Trust (2006).

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





Stephane Antoine          Expires June 18, 2007                 [Page 9]