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





   Requirements for Layer 2 Protocols to Support Optimized Handover for
                                IP Mobility


                            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 Mobile IP 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


        2        L2 Mobility Handover Optimization Requirements   July 2001

   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.


   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 L2 Handover Requirements for L2 Triggers ......................5
   5.0 L3 Handover Requirements for L2 Triggers ......................7
   6.0 Context Transfer Requirements for L2 Triggers .................8
      6.1. Types of Context Transfer .................................9
      6.2. Requirements for L2 Triggers for Context Transfer .........9
   7.0 Benefits of L2 Triggers for Other Systems ....................11
   8.0 Security Considerations ......................................11
   9.0 References ...................................................11
   10.0  Author's Addresses .........................................12


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 [10]. 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] [5]. 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 [6].
   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.


        3        L2 Mobility Handover Optimization Requirements   July 2001


   This document discusses requirements for an L2 handover protocol or
   API to support optimized L3 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 about L2
   events 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.

      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 abstracted from 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


        4        L2 Mobility Handover Optimization Requirements   July 2001

   has happened or is about to happen. The trigger may be implemented
   in a variety of ways. Some examples are:

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

      - The operating system may allow an application layer thread to
        call into a system call for the appropriate trigger or
        triggers. The system call returns when a particular trigger has
        fired, with parameter information as a return value of the
        system call.

      - 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 [7] is an example of such a protocol.

   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
                wireless link if one of its interfaces is on the


        5        L2 Mobility Handover Optimization Requirements   July 2001

                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  L2 Handover Requirements for L2 Triggers

   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 [7]. 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. Table
   1 contains a list of L2 handover requirements for L2 triggers.






















        6        L2 Mobility Handover Optimization Requirements   July 2001



      L2 Trigger          Event           Recipient        Parameters
      ----------          -----           ---------        ----------
       Intra-L2      Before handover     Current AR         MN's new
    Handover Start   between two APs                      downlink L2
                     supporting the          MN             address
                     same radio link
                       technology.                      New AP's uplink
                                                           L2 address

       Inter-L2      Before handover     Current AR         MN's new
    Handover Start   between two APs                      downlink L2
                       supporting            MN          address (radio
                     different radio   (optional, only  link technology
                          link         supplied if MN      specific)
                      technologies.    does not obtain
                                         otherwise)         MN's old
                                                          downlink L2
                                                         address (radio
                                                        link technology
                                                           specific)

                                                        New AP's uplink
                                                           L2 address
                                                             (radio
                                                           technology
                                                           specific)

     Inter-L2 Old    When the old L2     Current AR         MN's new
      Link Down          link is                          downlink L2
                    disappearing and         MN          address (radio
                    before disabling                    link technology
                    the old L2 link.                       specific)

                                                            MN's old
                                                          downlink L2
                                                         address (radio
                                                        link technology
                                                           specific)

                                                        New AP's uplink
                                                           L2 address
                                                             (radio
                                                           technology
                                                           specific)

                    Table 1 - L2 Handover Requirements






        7        L2 Mobility Handover Optimization Requirements   July 2001

5.0  L3 Handover Requirements for L2 Triggers

   The requirements discussed in this section have proven highly useful
   as a device in structuring low latency handover protocol designs for
   Mobile IPv4 and Mobile IPv6 [3] [4] [5]. An L2 that supports these
   requirements is a good candidate for a performance Mobile IP
   implementation. Table 2 contains the requirements for the L2
   triggers. 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.







































        8        L2 Mobility Handover Optimization Requirements   July 2001



      L2              Event          Recipient         Parameters
    Trigger
   --------          ------          ---------         ----------
   Link Up   When the L2 link comes    AP/AR      MN L2 address to AP/AP
             up.
                                         MN       AP/AR address to MN

   Link      When the L2 link goes     AP/AR     MN L2 address to AP/AR
   Down      down.
                                         MN       AP/AR address to MN

                                                     Boolean cause
                                                (inadvertent/deliberate)

   Source    Sufficiently before L2    MIPv6:    nAR or nFA IP address
   Trigger   handover start for         oAR      or L2 address that can
             pre-handover L3                     be mapped to an IP
             message exchange          MIPv4:    address
             across the wired           oFA
             and/or wireless link                    MN L2 address

   Target    Sufficiently before L2    MIPv6:    oAR or oFA IP address
   Trigger   handover finish for        nAR      or L2 address that can
             pre-handover L3                     be mapped to an IP
             message exchange          MIPv4:    address
             across the wired           nFA
             and/or wireless link.                   MN L2 address

   L2        When L2 handover          MIPv6:   MN L2 address to oAR/nAR
   Handover  begins                    oAR or
   Start                                nAR

                                       MIPv4:   MN L2 address to oFA/nFA
                                       oFA or
                                        nFA

                                         MN     MIPv6:oAR/nAR address or
                                                MIPv4 oFA/nFA address to
                                                           MN


                    Table 2 - L3 Handover Requirements


6.0  Context Transfer Requirements for L2 Triggers

   Context transfer (CT) is a relatively new issue for supporting
   seamless mobility between two nodes that provide access to a mobile
   node. Although lacking a "de facto" CT protocol specification at
   this time, plausible approaches toward CT framework are well


        9        L2 Mobility Handover Optimization Requirements   July 2001

   described in [8] [9]. Conceptually, the CT framework suggests two
   distinctive modes of operation, namely, reactive and proactive. In
   this section, specific modifications to L2 triggers that suffice
   both the reactive and the proactive context transfers are discussed.

6.1. Types of Context Transfer

   Reactive CT takes place subsequent to a MN establishing a new link
   with the new AR. Thus, the context information required should be
   transferred to the new access router after the MN completes the new
   link with the new access router. Although this timing requirement is
   loosely defined, it is desirable to initiate reactive CT sometime
   before (or about the same time as) the L2 handoff initiation. It is
   also noteworthy that the old access router is not always restricted
   to being the context source, i.e. where the context is transferred
   *from*.

   Proactive CT requires that the context is present at the new AR
   prior to the arrival of MN's packets at the new AR. The timing
   requirement for proactive CT is stricter because it may be possible
   that some of the context is still in transit when packets begin to
   arrive for the MN at the new access router.

6.2. Requirements for L2 Triggers for Context Transfer

   Similarly as FMIP L2 triggers (as defined in Section 4.0), L2
   triggers for context transfer operating on either reactive or
   proactive mode are defined in Table 3.


























        10       L2 Mobility Handover Optimization Requirements   July 2001



      L2 Trigger            Event         Recipient      Parameters
      ----------            -----         ---------      ----------
   Proactive CT L2  Sufficiently before      nAR     oAR or Context
   Target Trigger   L2 handover                      Transfer Source
                    initiation that CT               (CTS) L2/L3
                    can be completed                 address
                    before route/tunnel              identifiers.
                    for packets to MN
                    on new AR is set                 MN identifier
                    up.

   Proactive CT L2  Sufficiently before      oAR     nAR or Context
   Source Trigger   L2 handover                      Transfer Target
                    initiation that CT               (CTT) L2/L3
                    can be completed                 address
                    before route/tunnel              identifiers.
                    for packets to MN
                    on new AR is set                 MN identifier
                    up.

   Proactive CT L2  Sufficiently before       MN     nAR or Context
   Mobile Trigger   L2 handover                      Transfer Target
                    initiation that CT               (CTT) L2/L3
                    can be completed                 address
                    before route/tunnel              identifiers.
                    for packets to MN
                    on new AR is set
                    up.

   Reactive CT L2   Upon completion of       nAR     oAR or Context
   Target Trigger   the L2 handover.                 Transfer Source
                                                     (CTS) L2/L3
                                                     address
                                                     identifiers.

   Reactive CT L2   Upon initiation of       oAR     nAR or Context
   Source Trigger   L2 handover.                     Transfer Source
                                                     (CTS) L2/L3
                                                     address
                                                     identifiers.

   Reactive CT L2   Upon the initiation       MN     nAR or Context
   Mobile Trigger   of L2 handover.                  Transfer Target
                                                     (CTT) L2/L3
                                                     address
                                                     identifiers

                  Table 3 - Context Transfer Requirements




        11       L2 Mobility Handover Optimization Requirements   July 2001

7.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.
   For example, IP addresses may change due to stateless or stateful
   address configuration whenever hosts are unplugged from the network
   or replugged into a different subnet.

   Use of L2 triggers in such situations enables efficient state
   managment 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.

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-13.txt, a work in progress.



        12       L2 Mobility Handover Optimization Requirements   July 2001

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

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

   5  Kempf, et. al., "Bidirectional Edge Tunnel Handover for IPv6,"
      draft-kempf-beth-ipv6-00.txt, a work in progress.

   6  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-01.txt,
      a work in progress.

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


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

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


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






10.0 Author's Addresses

   James Kempf, Editor
   Sun Microsystems                     Phone: +1 650 336 1684
   901 San Antonio Rd, UMTV29-235         Fax: +1 650 691 0893
   Palo Alto, CA                        Email: james.kempf@sun.com
   94303
   USA

   Karim El Malki
   Ericsson Radio Systems AB
   LM Ericssons Vag. 8           Phone: +46 8 7195803


        13       L2 Mobility Handover Optimization Requirements   July 2001

   126 25 Stockholm                Fax: +46 8 7190170
   SWEDEN                        Email: Karim.El-Malki@era.ericsson.se

   Daichi Funato
   NTT DoCoMo, Inc.
   3-5, Hikarinooka, Yokosuka-shi     Phone: +81 468 40 3025
   Kanagawa, 239-8536                   Fax: +81 468 40 3726
   JAPAN                              Email: funato@nttdocomo.co.jp

   Youngjune Gwon
   Mobile Internet Laboratory
   DoCoMo Communications
     Laboratories USA, Inc.
   181 Metro Drive, Suite 300    Phone: +1 408 451 4734
   San Jose, CA 95110              Fax: +1 408 573 1090
   USA                           Email: gyj@dcl.docomo-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            Email: proberts@megisto.com
   Suite 120
   Germantown, MD 20874-1191

   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 Communications
     Laboratories USA, Inc.
   181 Metro Drive, Suite 300     Phone: +1 408 451 4705
   San Jose, CA 95110               Fax: +1 408 573 1090
   USA                            Email: takeshita@dcl.docomo-usa.com

   Alper Yegin
   Sun Microsystems                     Phone: +1 650 786 4013
   901 San Antonio Rd, UMPK17-202       Email: alper.yegin@sun.com
   Palo Alto, CA
   94303
   USA