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

Versions: 00 01 02                                                      
   Informational                                        Alper E. Yegin,
                                                                 Editor
   Internet Draft                                         Daichi Funato
   Document: draft-manyfolks-l2-mobilereq-02.txt         Karim El Malki
   Expires: December 2002                                Youngjune Gwon
   June 2002                                                James Kempf
                                                     Mattias Pettersson
                                                           Phil Roberts
                                                         Hesham Soliman
                                                      Atsushi Takeshita


     Supporting Optimized Handover for IP Mobility - Requirements for
                            Underlying Systems


                            Status of this Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026. This is an individual
   draft for consideration by the PILC Working Group.

   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.

   Abstract

   A critical factor in achieving good performance for IP mobility
   protocols is the design of L2 handover. Handover occurs when a
   Mobile Node moves from one radio Access Point to another. If the new
   radio Access Point is associated with a new subnet, a change in
   routing reachability may occur and require L3 protocol action on the
   part of the Mobile Node or Access Routers. If no change in subnet
   occurs, the Access Point may still need to take some action to
   inform the Access Router about a change in on-link reachability. In
   either case, prompt and timely information from L2 to the parties
   involved about the sequencing of handover can help optimize handover
   at the IP level. This draft discusses requirements for an L2
   handover protocol or API to support optimized handover.


   Yegin (editor), et. al. Informational - Expires December 2002
   [Page 2]         Optimized IP Mobility Support           June 2002


   Table of Contents

   1.0  Introduction.................................................2
   2.0  Terminology..................................................3
   3.0  L2 Trigger Definition........................................3
      3.1. What is an L2 Trigger?....................................3
      3.2. Information in an L2 Trigger..............................4
   4.0  Requirements for L2 Triggers.................................5
      4.1. L2 Handovers..............................................5
      4.2. L3 Handovers..............................................5
      4.3. Context Transfers.........................................6
   5.0  L2 Triggers..................................................6
   6.0  Benefits of L2 Triggers for Other Systems....................7
   7.0  Example: 802.11..............................................8
   8.0  Security Considerations......................................9
   9.0  References...................................................9
   10.0 Author's Addresses..........................................10

1.0  Introduction

   An important consideration in the design of IP mobility protocols is
   handover. A moving Mobile Node (MN) may irregularly need to change
   the terrestrial radio Access Point (AP) with which it is
   communicating. The change in L2 connectivity to a new AP may cause a
   change in IP routing reachability, and thus require either the MN or
   the Access Routers (ARs) to perform actions that update routing
   information for the MN. Even if no change in subnet occurs, the APs
   may still need to communicate the change in on-link reachability to
   the local AR. In order for handover to occur, candidate APs must be
   identified and a target AP must be selected [9]. Once this process
   has been complete, the handover process can begin.

   Several protocol designs have been advanced for Mobile IP that seek
   to reduce the amount of handover latency at L3 [3] [4]. These
   protocols depend on obtaining timely information from the L2
   protocol about the progress of handover. An additional beneficiary
   of timely handover progress information is context transfer [5].
   Context transfer involves moving context information (QoS, header
   compression, authentication, etc.) from the old AR to the new. By
   moving such context information, the ARs can avoid requiring the MN
   to set up all the context information from scratch, considerably
   reducing the amount of time necessary to set up basic network
   service on the new subnet. If handover progress information is
   available from L2, context transfer can proceed more quickly.

   This document discusses requirements on underlying systems for
   supporting optimized IP mobility, in particular, handover. While the
   document has been written with existing Mobile IP work in mind, it
   should be applicable to any protocol that can benefit from knowledge

   Yegin (editor), et. al.  Informational - Expires December 2002
   [Page 3]         Optimized IP Mobility Support           June 2002

   about handover sequencing to facilitate mobility. Requirements for
   assisting in handover between two APs on the same subnet, between
   two ARs on different subnets, and for context transfer between ARs
   are discussed.

2.0  Terminology

   The following terms are used in this document.

      Access Point (AP)

         A Layer 2 (L2) access entity, e.g. a radio transceiver
         station, that is connected to one or more Access Routers. Its
         primary function is to provide MNs an L2 wireless link via its
         specific air-interface technology.

      Access Router (AR)

         A Layer 3 (L3) IP router, residing in an access network and
         connected to one or more Access Points. An AR is the first hop
         router for a MN.

      L2 Handover

         Change of MN's link layer connection from one AP to another.
         No change in off-subnet routing reachability information is
         required if both APs are part of the same subnet.

      L3 Handover

         Change of MN's routable address from one AR to another. An L3
         handover results in a change in the MN's routing reachability,
         that will require action on the part of the IP mobility
         protocol running in the MN and/or ARs.

3.0  L2 Trigger Definition

   This section discusses defining L2 triggers that provide information
   on the sequencing of handover. An L2 trigger is not associated with
   any specific L2 but rather is based on the kind of L2 information
   that is or could be available from a wide variety of radio link
   protocols.

3.1. What is an L2 Trigger?

   An L2 trigger is an abstraction of a notification from L2
   (potentially including parameter information) that a certain event
   has happened or is about to happen. The trigger may be implemented
   in a variety of ways. Some examples are:


   Yegin (editor), et. al.  Informational - Expires December 2002
   [Page 4]         Optimized IP Mobility Support           June 2002

      - The L2 driver may allow the IP stack to register a callback
        function that is called when the trigger fires. The parameters
        associated with the trigger are delivered to the callback.

      - The operating system may allow a thread to call into a system
        call for the appropriate trigger or triggers. The system call
        blocks until a particular trigger has fired, then it returns
        with parameter information available in some way (return value
        of the system call, file descriptor, etc.).

      - The trigger may consist of a protocol for transferring the
        trigger notification and parameter information at either L2 or
        L3 between the new AP or AR and the old AP or AR. The parameter
        information is included as part of the protocol. This allows
        the IP stack on a separate machine to react to the trigger. The
        IAPP protocol [6] is an example of such a protocol.

      - The trigger information may be available within the operating
        system kernel to the IP stack from the driver as an out of band
        communication.

   In any case, the implementation details of how the information
   involved in an L2 trigger are transferred to the IP mobility
   protocol are likely to color how the mobility protocol is
   implemented on top of that L2, but they should not influence the
   specification of the abstract L2 triggers themselves.

3.2. Information in an L2 Trigger

   There are three types of information involved in defining an L2
   trigger:

      1. The event that causes the L2 trigger to fire,

      2. The IP entity that receives the trigger,

      3. The parameters delivered with the trigger.

   The IP entities that can receive the trigger depend on the
   particular IP mobility protocol in use. Here are some possible IP
   entities, based on work done with L2 triggers and Mobile IP:

      MN        The MN may receive an L2 trigger allowing it to start
                or conclude a mobile controlled handover.

      FA        In Mobile IPv4, the Foreign Agent (FA) is located on
                the last hop before the wireless link. The last hop
                can be either an AP or AR or even a separate host.
                An FA can make use of triggers to start or conclude
                network controlled handover.

      AR        The AR can obtain an L2 trigger directly from the

   Yegin (editor), et. al.  Informational - Expires December 2002
   [Page 5]         Optimized IP Mobility Support           June 2002

                wireless link if one of its interfaces is on the
                link (that is, the AR is also an AP), or it can obtain
                an L2 trigger indirectly by L2 or L3 protocol messages
                from the AP.

4.0  Requirements for L2 Triggers

   L2 handover, L3 handover, and context transfer events and related
   protocols would benefit from a collection of L2 triggers. Some of
   these protocols directly rely on the existence of certain triggers,
   and perform better when others are available. As such, L2 triggers
   should be designed to meet these protocolsÆ needs.

4.1. L2 Handovers

   On the face of it, specifying requirements for pure L2 handover
   (i.e. no change in IP routing reachability) might seem out of scope
   for IETF. Existing wireless networks typically have special L2 AP-AR
   interfaces with L2 address update built in. For these systems, L2
   triggers are unnecessary.

   However, current trends in wireless networking suggest that future
   wireless networks will consist of a variety of heterogeneous
   wireless APs bridged into the wired network, potentially on the same
   subnet. A change in wireless AP, either between an AP supporting one
   wireless link technology and an AP supporting another, or between
   two APs supporting the same wireless technology, necessarily results
   in a change in the on-subnet reachability. Packet delivery within
   the subnet can be optimized if this information can be propagated to
   the AR, so it can update its on-subnet L2 address to IP address
   mapping.

   In addition, the old AP may benefit from a notification that the MN
   has moved in the event it is not involved in the handover (as is the
   case with some WLAN radio protocols), by allowing the old AP to more
   quickly de-allocate resources dedicated to the moved MN. Some radio
   link protocols already define IP-based L2 trigger protocols for this
   purpose [6]. When APs supporting multiple radio technologies on a
   single subnet are involved, however, interoperability suffers if
   there is no L2-independent way of reporting on-link movement.

4.2. L3 Handovers

   Low latency handover protocol designs for Mobile IPv4 and Mobile
   IPv6 [3] [4] rely on the existence of certain L2 triggers.
   Either the MN or the AP/AR needs to receive an indication that the
   handoff is imminent for these L3 mobility protocols to work. This
   trigger must be received by the MN for mobile-controlled handovers,
   and received by the AP/AR for network-controlled handovers. Timely
   receipt of this trigger is needed as protocol signaling needs to
   take place in parallel with the handoff. Protocol signaling over the
   current link should be completed prior to loss of connectivity.

   Yegin (editor), et. al.  Informational - Expires December 2002
   [Page 6]         Optimized IP Mobility Support           June 2002


   Additional triggers that indicate the link tear down and
   establishment can be used to indicate departure and arrival of a MN
   at AP/ARs. Such indications can replace L3 signal exchange and
   therefore expedite the process. An L2 that supports a collection of
   such triggers is a good candidate for a high performance Mobile IP
   implementation.

4.3. Context Transfers

   Context transfer (CT) is a relatively new issue for supporting
   seamless mobility between two ARs or FAs that provide access to a
   mobile node. Although lacking a "de facto" CT protocol specification
   at this time, plausible approaches toward a CT framework are well
   described in [7] [8]. Conceptually, CT can take place before,
   during, or after handover. Exactly when and how CT takes place is
   highly dependent on the type of context being transferred.

   L2 triggers are used to initiate the context transfer operation.
   Early notification of handovers is essential to having sufficient
   time to complete the required protocol signaling. Also link
   establishment trigger can be used for activating the state related
   to a context.

5.0  L2 Triggers

   Based on the L2 handover, L3 handover, and context transfer
   protocolsÆ needs, underlying systems are required to implement basic
   L2 triggers as outlined in Table 1.

   The description for a trigger contains the trigger name, the L2
   handover event causing the trigger to fire, what entities receive
   the trigger, and parameters, if any. The recipient is qualified by
   the IP mobility protocol in which the recipient plays a role. If the
   recipient does not have AP functionality (i.e., the recipient does
   not have an interface directly on the wireless link), the trigger
   information must be conveyed from the AP where it occurs to the
   recipient by an L2 or L3 protocol [10].















   Yegin (editor), et. al.  Informational - Expires December 2002
   [Page 7]         Optimized IP Mobility Support           June 2002

      L2            Event            Recipient         Parameters
    Trigger
  +---------+---------------------+--------------+------------------+
  |Link Up  |   When the L2 link  |   AP/AR/FA   |  MN L2 address   |
  |         |   comes up.         |              |  to AP/AR/FA     |
  |         |                     |              |                  |
  |         |                     |      MN      |  AP/AR/FA L2     |
  |         |                     |              |  address to MN   |
  +---------+---------------------+--------------+------------------+
  |  Link   |   When the L2 link  |   AP/AR/FA   |  MN L2 address   |
  |  Down   |   goes down.        |              |  to AP/AR/FA     |
  |         |                     |              |                  |
  |         |                     |      MN      |  AP/AR/FA L2     |
  |         |                     |              |  address to MN   |
  |         |                     |              |                  |
  |         |                     |              |  Boolean cause   |
  |         |                     |              |  (inadvertent/   |
  |         |                     |              |  deliberate)     |
  +---------+---------------------+--------------+------------------+
  |Source   | Sufficiently before |  oAP/oAR/oFA | nAP/nAR/nFA L2   |
  |Trigger  | L2 handover start   |              | address that can |
  |         | for pre-handover L3 |              | be mapped to an  |
  |         | message exchange    |              | IP address       |
  |         | across the wired    |              |                  |
  |         | and/or wireless link|              | MN L2 address    |
  +---------+---------------------+--------------+------------------+
  |Target   | Sufficiently before |  nAP/nAR/nFA | oAP/oAR/oFA L2   |
  |Trigger  | L2 handover finish  |              | address that can |
  |         | for pre-handover L3 |              | be mapped to an  |
  |         | message exchange    |              | IP address       |
  |         | across the wired    |              |                  |
  |         | and/or wireless     |              | MN L2 address    |
  |         | link.               |              |                  |
  +---------+---------------------+--------------+------------------+
  |Mobile   | Sufficiently before |      MN      | nAP/nAR/nFA L2   |
  |Trigger  | L2 handover start   |              | address that can |
  |         | for pre-handover L3 |              | be mapped to an  |
  |         | message exchange    |              | IP address       |
  |         | across the wired    |              |                  |
  |         | and/or wireless link|              |                  |
  +---------+---------------------+--------------+------------------+
                     Table 1. L2 trigger requirements

   When a source trigger or target trigger is not followed by a link up
   or down trigger, this sequence of events can be interpreted as an
   indication of a failed handover.

6.0  Benefits of L2 Triggers for Other Systems

   While the primary purpose of L2 triggers described in this draft is
   to aid L2 mobility optimization, L2 triggers can also benefit
   networks without Mobile IP or other IP mobility protocol support.

   Yegin (editor), et. al.  Informational - Expires December 2002
   [Page 8]         Optimized IP Mobility Support           June 2002

   For example, IP addresses may change due to stateless or stateful
   address configuration whenever hosts are unplugged from the network
   or re-plugged into a different subnet.

   Use of L2 triggers in such situations enables efficient state
   management in the AR. The AR can clean up the associated state as
   soon as it detects that a host has been disconnected through the L2
   Link Down trigger, for example. State clean up includes removal of
   ARP or Neighbor Cache entries, and can save bandwidth by inhibiting
   incoming data on the link where the host was once connected.

   Additionally, faster and more efficient router discovery is possible
   if the AR receives a L2 Link Up trigger for a host. When the AR
   receives the trigger, it can send an unsolicited unicast router
   advertisement to the host. The host can begin the process of
   establishing IP connectivity more quickly.

7.0  Example: 802.11

   In this section, we give an example of how a subset of the L2
   triggers could be implemented for the 802.11 wireless LAN protocol
   [11] and used by Mobile IPv6 [2].

   The 802.11 protocol supports a MAC layer management frame called
   Reassociation.request. The Reassociation.request frame is sent by a
   MN to a peer acting as an AP when the MN is in infrastructure mode
   and the MN wishes to change its association from its current AP to a
   new AP. The MN determines that a new AP is available because it
   detects a beacon from the new AP. The MN sends the
   Reassociation.request because the bit error rate on the link with
   the old AP has become too high (the standard does not specify
   exactly how high is too high, however).

   The 802.11 Reassociation.request message contains the MAC address of
   the MN's current AP, and it is sent to the MAC address of the MN's
   desired new AP. The MAC layer frame in addition contains the MN's
   MAC address. Upon receipt of the Reassociation.request, the AP
   determines if the MN may reassociate and replies with a
   Reassociation.reply message either allowing or denying the request.

   The Reassociation.request and Reassociation.reply contain the
   material for the following L2 triggers:

   - When the MN's 802.11 driver receives a Reassociation.reply from
     the new AP confirming reassociation, it can deliver a Link Up
     trigger to the Mobile IP stack (or a daemon that communicates
     with the Mobile IP stack and is monitoring the driver) containing
     the MAC address of the new AP.

   - When the AP determines that it can send a positive
     Reassociation.reply to the MN, it can generate a Link Up trigger
     with the MN's MAC address and the MAC address of the MN's old AP.


   Yegin (editor), et. al.  Informational - Expires December 2002
   [Page 9]         Optimized IP Mobility Support           June 2002

   On the MN, the Link Up trigger delivered to the Mobile IP stack
   triggers the stack to send a Solicitation for Router Advertisement
   [2] to the new AR. This causes the AR to reply with a Router
   Advertisement. The MN compares the subnet prefix advertised by
   the router with its current subnet prefix, and if it determines that
   it has moved into a new subnet, it begins the process of
   establishing a new Care of Address. In this case, the MN is running
   standard Mobile IP without any fast handover enhancements; but
   because of the L2 trigger, it is able to eliminate the latency
   involved in waiting for a Router Advertisement beacon from the AR,
   thus increasing handover performance.

   On the AP, the disposition of the Link Up trigger depends on the
   relationship between the AP and the AR. If the AP is acting as a
   transparent Layer 2 bridge, then some type of protocol is needed to
   transfer the trigger from the AP to the AR. This could be an
   addition to the 802 protocol, or it could be an enhancement to IAPP,
   the 802.11 InterAccess Point Protocol [6], or it could be an IPv6
   protocol enhancement [10]. Upon receipt of the trigger protocol, the
   AR's driver or Mobile IP stack disposes of it exactly as in the case
   of a trigger on the MN. If the AP is integrated with the AR, then
   the trigger is delivered programmatically to the Mobile IP stack.

8.0  Security Considerations

   The L2 triggers convey information about the link state of the MN
   and this information can trigger IP layer changes in routing
   reachability. As such, the information in an L2 trigger, if misused
   by an adversary or fraudulently propagated, could result in denial
   of IP service to the MN or hijacking of the MN's packets to a
   hostile third party.

   If the L2 trigger is implemented as an API on an AR or AP, then the
   operating system and API implementation are required to assure that
   only qualified users can call into the API. Normally this involves
   denying access through the API unless the process running the API
   client has the proper security credentials on the host. If the L2
   trigger is implemented as an L2 or L3 protocol, the protocol is
   required to protect the trigger messages with the proper
   authentication. In particular, if the protocol is an IP-based
   protocol, it must include authenticators so the parties that use the
   protocol can authenticate each other. If the protocol is intended to
   be used on public data networks, the option of encrypting the
   traffic must be available, to grant some privacy over the MN
   movement information propagated by the protocol messages.

9.0  References

   1  Perkins, C., ed., "IP Mobility Support," RFC 2002, October, 1996.

   2  Johnson, D., and Perkins, C., "Mobility Support in IPv6,"
      draft-ietf-mobileip-ipv6-17.txt, a work in progress.


   Yegin (editor), et. al.  Informational - Expires December 2002
   [Page 10]        Optimized IP Mobility Support           June 2002

   3  El-Malki, K., et. al., "Low Latency Handoff in Mobile IPv4,"
      draft-ietf-mobileip-lowlatencyhandoffs-v4-02.txt, a work in
      progress.

   4  Dommety, G., et. al. "Fast Handovers for Mobile IPv6,"
      draft-ietf-mobileip-fast-mipv6-04.txt, a work in progress.

   5  Levkowetz, O.H., et. al., "Problem Description: Reasons for
      Performing Context Transfers Between Nodes in an IP Access
      Network,"
      draft-ietf-seamoby-context-transfer-problem-stat-04.txt,
      a work in progress.

   6  "Recommended Practice for Multi-Vendor Access Point
      Interoperability via an Inter-Access Point Protocol Across
      Distribution Systems Supporting IEEE 802.11 Operation," IEEE Std
      802.11f/D1, DRAFT.

   7  Sayed, H., et. al., "Context Transfer Framework,"
      draft-hamid-seamoby-ct-fwk-01.txt, a work in progress

   8  Sayed, H., et. al., "General Requirements for a Context Transfer
      Framework," draft-hamid-seamoby-ct-reqs-02.txt, a work in
      progress

   9  Trossen, D., et. al., "Issues in Candidate Access Router
      Discovery for Seamless IP Handoffs,"
      draft-ietf-seamoby-CARdiscovery-issues-03.txt, a work in
      progress.

   10 Yegin, A., "Link-layer Triggers Protocol",
      draft-yegin-l2-triggers-00.txt, a work in progress.

   11 IEEE, "Wireless LAN Medium Access Control (MAC) and Physical
      Layer (PHY) Specifications,"  IEEE Std. 802.11, 1999.

   12 Krishnamurthi, et. al., "Requirements for CAR Discovery
      Protocols," draft-ietf-seamoby-card-requirements-00.txt, a work
      in progress.

10.0  Author's Addresses

   Karim El Malki
   Ericsson Radio Systems AB
   LM Ericssons Vag. 8            Phone: +46 8 7195803
   126 25 Stockholm                 Fax: +46 8 7190170
   SWEDEN                         Email: Karim.El-Malki@era.ericsson.se

   Daichi Funato
   DoCoMo USA Labs
   181 Metro Drive, Suite 300     Phone: +1 408 451 4736
   San Jose, CA 95110               Fax: +1 408 573 1090
   USA                            Email: funato@docomolabs-usa.com

   Yegin (editor), et. al.  Informational - Expires December 2002
   [Page 11]        Optimized IP Mobility Support           June 2002

   Youngjune Gwon
   DoCoMo USA Labs
   181 Metro Drive, Suite 300     Phone: +1 408 451 4734
   San Jose, CA 95110               Fax: +1 408 573 1090
   USA                            Email: gyj@docomolabs-usa.com

   James Kempf
   DoCoMo USA Labs
   181 Metro Drive, Suite 300     Phone: +1 408 451 4711
   San Jose, CA 95110               Fax: +1 408 573 1090
   USA                            Email: james@docomolabs-usa.com

   Mattias Pettersson
   Ericsson Radio Systems AB      Phone: +46 8 585 32 562
   Torshamnsgatan 23                Fax: +46 8 404 70 20
   SE-164 80 Stockholm       E-mail: Mattias.Pettersson@era.ericsson.se
   SWEDEN

   Phil Roberts
   Megisto Systems
   20251 Century Blvd, Suite 120  Email: proberts@megisto.com
   Germantown, MD 20874-1191
   USA

   Hesham Soliman
   Ericsson Radio Systems
   Torshamnsgatan 29, Kista       Phone: +46 8 7578162
   Stockholm                        Fax: +46 8 4043630
   SWEDEN                         Email: Hesham.Soliman@era.ericsson.se

   Atsushi Takeshita
   DoCoMo USA Labs
   181 Metro Drive, Suite 300     Phone: +1 408 451 4705
   San Jose, CA 95110               Fax: +1 408 573 1090
   USA                            Email: takeshita@docomolabs-usa.com

   Alper E. Yegin, Editor
   DoCoMo USA Labs
   181 Metro Drive, Suite 300     Phone: +1 408 451 4743
   San Jose, CA 95110               Fax: +1 408 573 1090
   USA                            Email: alper@docomolabs-usa.com














   Yegin (editor), et. al.  Informational - Expires December 2002