Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 6252


A Framework of Media-Independent Pre-Authentication (MPA) for Inter-Domain Handover Optimization

Part 3 of 3, p. 40 to 57
Prev RFC Part


prevText      Top      Up      ToC       Page 40 
Appendix A.  Proactive Duplicate Address Detection

   When the DHCP server dispenses an IP address, it updates its lease
   table, so that this same address is not given to another client for
   that specific period of time.  At the same time, the client also
   keeps a lease table locally so that it can renew when needed.  In
   some cases where a network consists of both DHCP and non-DHCP-enabled
   clients, there is a probability that another client in the LAN may
   have been configured with an IP address from the DHCP address pool.
   In such a scenario, the server detects a duplicate address based on
   ARP (Address Resolution Protocol) or IPv6 Neighbor Discovery before
   assigning the IP address.  This detection procedure may take from 4
   sec to 15 sec [MAGUIRE] and will thus contribute to a larger handover
   delay.  In the case of a proactive IP address acquisition process,
   this detection is performed ahead of time and thus does not affect
   the handover delay at all.  By performing the Duplicate Address
   Detection (DAD) ahead of time, we reduce the IP address acquisition

   The proactive DAD over the candidate target network should be
   performed by the nAR on behalf of the mobile node at the time of
   proactive handover tunnel establishment, since DAD over a tunnel is
   not always performed.  For example, in the case of IPv6, DAD over an
   IP-IP tunnel interface is turned off in an existing implementation.
   In the case of IPv6 over PPP [RFC5172], the IP Control Protocol
   (IPCPv6) negotiates the link-local addresses, and hence DAD over the
   tunnel is not needed.  After the mobile node has moved to the target
   network, a DAD procedure may be started because of reassignment of
   the nCoA to the physical interface to the target network.  In that
   case, the mobile node should use optimistic DAD [RFC4429] over the
   physical interface so that the nCoA that was used inside the
   proactive handover tunnel before handover can be immediately used
   over that physical interface after handover.  The schemes used for
   the proactive DAD and optimistic DAD are applicable to both stateless
   and stateful address autoconfiguration schemes used for obtaining a

Top      Up      ToC       Page 41 
Appendix B.  Address Resolution

   Address resolution involves updating the next access router's
   neighbor cache.  We briefly describe these two operations below.

   During the process of pre-configuration, the MAC address resolution
   mappings needed by the mobile node to communicate with nodes in the
   target network after attaching to the target network can also be
   known, where the communicating nodes may be the access router,
   authentication agent, configuration agent, or Correspondent Node.
   There are several possible ways of performing such proactive MAC
   address resolution.

   o  One can use an information service mechanism [802.21] to resolve
      the MAC addresses of the nodes.  This might require each node in
      the target network to be involved in the information service so
      that the server of the information service can construct the
      database for proactive MAC address resolution.

   o  One can extend the authentication protocol used for pre-
      authentication or the configuration protocol used for
      pre-configuration to support proactive MAC address resolution.
      For example, if PANA is used as the authentication protocol for
      pre-authentication, PANA messages may carry attribute-value pairs
      (AVPs) used for proactive address resolution.  In this case, the
      PANA authentication agent in the target network may perform
      address resolution on behalf of the mobile node.

   o  One can also make use of DNS to map the MAC address of the
      specific interface associated with a specific IP address of the
      network element in the target network.  One may define a new DNS
      resource record (RR) to proactively resolve the MAC addresses of
      the nodes in the target network.  But this approach may have its
      own limitations, since a MAC address is a resource that is bound
      to an IP address, and not directly to a domain name.

   When the mobile node attaches to the target network, it installs the
   proactively obtained address resolution mappings without necessarily
   performing address resolution queries for the nodes in the target

   On the other hand, the nodes that reside in the target network and
   that are communicating with the mobile node should also update their
   address resolution mappings for the mobile node as soon as the mobile
   node attaches to the target network.  The above proactive address
   resolution methods could also be used for those nodes to proactively
   resolve the MAC address of the mobile node before the mobile node
   attaches to the target network.  However, this is not useful, since

Top      Up      ToC       Page 42 
   those nodes need to detect the attachment of the mobile node to the
   target network before adopting the proactively resolved address
   resolution mapping.  A better approach would be integration of
   attachment detection and address resolution mapping update.  This is
   based on gratuitously performing address resolution [RFC5944],
   [RFC3775] in which the mobile node sends an ARP Request or an ARP
   Reply in the case of IPv4, or a Neighbor Advertisement in the case of
   IPv6, immediately after the mobile node attaches to the new network,
   so that the nodes in the target network can quickly update the
   address resolution mapping for the mobile node.

Appendix C.  MPA Deployment Issues

   In this section, we describe some of the deployment issues related to

C.1.  Considerations for Failed Switching and Switch-Back

   The ping-pong effect is one of the common problems found during
   handover.  The ping-pong effect arises when a mobile node is located
   at the borderline of the cell or decision point and a handover
   procedure is frequently executed.  This results in higher call drop
   probability, lower connection quality, increased signaling traffic,
   and waste of resources.  All of these affect mobility optimization.
   Handoff algorithms are the deciding factors for performing the
   handoff between the networks.  Traditionally, these algorithms employ
   a threshold to compare the values of different metrics to decide on
   the handoff.  These metrics include signal strength, path loss,
   Carrier-to-Interference Ratio (CIR), Signal-to-Interference Ratio
   (SIR), Bit Error Rate (BER), and power budget.  In order to avoid the
   ping-pong effect, some additional parameters are employed by the
   decision algorithm, such as hysteresis margin, dwell timers, and
   averaging window.  For a vehicle moving at a high speed, other
   parameters, such as the distance between the mobile node and the
   point of attachment, velocity of the mobile node, location of the
   mobile node, traffic, and bandwidth characteristics are also taken
   into account to reduce the ping-pong effect.  More recently, there
   are other handoff algorithms available that help reduce the ping-pong
   effect in a heterogeneous network environment and that are based on
   techniques such as hypothesis testing, dynamic programming, and
   pattern recognition techniques.  While it is important to devise
   smart handoff algorithms to reduce the ping-pong effect, it is also
   important to devise methods to recover from this effect.

   In the case of the MPA framework, the ping-pong effect will result in
   the back-and-forth movement of the mobile node between the current
   network and target network, and between the candidate target
   networks.  MPA in its current form will be affected because of the

Top      Up      ToC       Page 43 
   number of tunnels set up between the mobile node and neighboring
   access routers, the number of binding updates, and associated handoff
   latency resulting from the ping-pong situation.  The mobile node's
   handoff rate may also contribute to delay and packet loss.  We
   propose a few techniques that will help reduce the probability of the
   ping-pong effect and propose several methods for the MPA framework so
   that it can recover from the packet loss resulting from the ping-pong

   The MPA framework can take advantage of the mobile node's geo-
   location with respect to APs in the neighboring networks using GPS.
   In order to avoid the oscillation between the networks, a location-
   aware algorithm can be derived by using a co-relation between the
   user's location and cached data from the previous handover attempts.
   In some cases, location may not be the only indicator for a handoff
   decision.  For example, in Manhattan-type grid networks, although a
   mobile node is close to an AP, it may not have enough SNR (Signal-to-
   Noise Ratio) to make a good connection.  Thus, knowledge of the
   mobility pattern, dwell time in a call, and path identification will
   help avoid the ping-pong problem to a great extent.

   In the absence of a good handoff algorithm that can avoid the ping-
   pong effect, it may be required to put in place a good recovery
   mechanism so as to mitigate the effect of ping-pong.  It may be
   necessary to keep the established context in the current network for
   a period of time, so that it can be quickly recovered when the mobile
   node comes back to the network where the context was last used.  This
   context may include security association, IP address used, and
   tunnels established.  Bicasting the data to both the previous network
   and the new network for a predefined period will also help the mobile
   node to take care of the lost packets in case the mobile node moves
   back and forth between the networks.  The mobile node can also take
   certain action, after it determines that it is in a stable state with
   respect to a ping-pong situation.

   When the MPA framework takes advantage of a combination of IKEv2 and
   MOBIKE, the ping-pong effect can be reduced further [MPA-MOBIKE].

C.2.  Authentication State Management

   In the case of pre-authentication with multiple target networks, it
   is useful to maintain the state in the authentication agent of each
   of the neighboring networks for a certain time period.  Thus, if the
   mobile node does move back and forth between neighboring networks,
   already-maintained authentication state can be helpful.  We provide
   some highlights on multiple security association state management

Top      Up      ToC       Page 44 
   A mobile node that has pre-authenticated with an authentication agent
   in a candidate target network and has an MPA-SA may need to continue
   to keep the MPA-SA while it continues to stay in the current network
   or even after it makes a handover to a network that is different from
   the candidate target network.

   When an MN that has been authenticated and authorized by an
   authentication agent in the current network makes a handover to a
   target network, it may want to hold the SA that has been established
   between the MN and the authentication agent for a certain time period
   so that it does not have to go through the entire authentication
   signaling to create an SA from scratch, in case it returns to the
   previous network.  Such an SA being held at the authentication agent
   after the MN's handover to another network is considered as an
   MPA-SA.  In this case, the authentication agent should change the
   fully authorized state for the MN to an unauthorized state.  The
   unauthorized state can be changed to the fully authorized state only
   when the MN comes back to the network and provides proof of
   possession of a key associated with the MPA-SA.

   While an MPA-SA is being held at an authentication agent, the MN will
   need to keep updating the authentication agent when an IP address of
   the MN changes due to a handover, to re-establish the new SA.

C.3.  Pre-Allocation of QoS Resources

   In the pre-configuration phase, it is also possible to pre-allocate
   QoS resources that may be used by the mobile node not only after
   handover but also before handover.  When pre-allocated QoS resources
   are used before handover, they are used for application traffic
   carried over a proactive handover tunnel.

   It is possible that QoS resources are pre-allocated in an end-to-end
   fashion.  One method to achieve this proactive end-to-end QoS
   reservation is to execute the NSIS Signaling Layer Protocol (NSLP)
   [RFC5974] or the Resource Reservation Protocol (RSVP) [RFC2205] over
   a proactive handover tunnel where pre-authentication can be used for
   bootstrapping a security association for the proactive handover
   tunnel to protect the QoS signaling.  In this case, QoS resources are
   pre-allocated on the path between the Correspondent Node and a target
   access router and can be used continuously before and after handover.
   On the other hand, duplicate pre-allocation of QoS resources between
   the target access router and the mobile node is necessary when using
   pre-allocated QoS resources before handover, due to differences in

Top      Up      ToC       Page 45 
   paths between the target access router and the mobile node before and
   after handover.  QoS resources to be used for the path between the
   target access router and the mobile node after handover may be
   pre-allocated by extending NSLP to work for off-path signaling (Note:
   this path can be viewed as off-path before handover) or by
   media-specific QoS signaling at layer 2.

C.4.  Resource Allocation Issue during Pre-Authentication

   In the case of multiple CTNs, establishing multiple tunnels with the
   neighboring target networks provides some additional benefits.  But
   it contributes to some resource utilization issues as well.  A
   pre-authentication process with multiple candidate target networks
   can happen in several ways.

   The very basic scheme involves authenticating the mobile node with
   the multiple authentication agents in the neighboring networks, but
   actual pre-configuration and binding update take place only after
   layer 2 movement to a specific network is complete.

   Similarly, in addition to pre-authentication, the mobile node can
   also complete the pre-configuration while in the previous network,
   but can postpone the binding update until after the mobile node has
   moved.  Like the previous case, in this case the mobile node also
   does not need to set up the pre-configured tunnels.  While the pre-
   authentication process and part of the pre-configuration process are
   taken care of before the mobile node has moved to the new network,
   the binding update is actually done after the mobile node has moved.

   The third type of multiple pre-authentication involves all the three
   steps while the mobile node is in the previous networks, such as
   authentication, configuration, and binding update.  But, this
   specific process utilizes the highest amount of resources.  Some of
   the resources that get used during this process are as follows:

   (1)  Additional signaling for pre-authentication in the neighboring

   (2)  Holding the IP address of the neighboring networks in the mobile
        node's cache for a certain amount of time.  Additional
        processing in the mobile node is needed for storing these IP
        addresses.  In addition, this caching of addresses also uses up
        the temporary IP addresses from the neighboring routers.

   (3)  There is an additional cost associated with setting up
        additional transient tunnels with the target routers in the
        neighboring networks and the mobile node.

Top      Up      ToC       Page 46 
   (4)  In the case of a binding update with multiple IP addresses
        obtained from the neighboring networks, multiple transient
        streams flow between the CN and mobile node using these
        transient tunnels.

   However, there are pros and cons related to sending the binding
   update after the handover.  If the binding update is sent after the
   mobile node has moved to the new network, this will contribute to the
   delay if the CH or HA is far from the MN.  Multiple binding updates
   can be taken care of in many different ways.  We describe a few of
   these update mechanisms below.

   When only pre-authentication and pre-configuration are done ahead of
   time with multiple networks, the mobile node sends one binding update
   to the CN.  In this case, it is important to find out when to send
   the binding update after the layer 2 handoff.

   In case a binding update with multiple contact addresses is sent,
   multiple media streams stem out of the CN, using the transient
   tunnels.  But in that case, one needs to send another binding update
   after the handover, with the contact address set to the new address
   (only one address) where the mobile node has moved.  This way, the
   mobile node stops sending media to other neighboring networks where
   the mobile node did not move.

   The following is an illustration of this specific case that takes
   care of multiple binding streams, when the mobile node moves only to
   a specific network, but sends multiple binding updates in the
   previous network.  The MN sends a binding update to the CH with
   multiple contact addresses, such as c1, c2, and c3, that were
   obtained from three neighboring networks.  This allows the CN to send
   transient multiple streams to the mobile node over the pre-
   established tunnels.  After the mobile node moves to the actual
   network, it sends another binding update to the CN with the care-of
   address of the mobile node in the network where the mobile node has
   moved.  One issue with multiple streams is consumption of extra
   bandwidth for a small period of time.

   Alternatively, one can apply the buffering technique at the target
   access router or at the Home Agent.  Transient data can be forwarded
   to the mobile node after it has moved.  Forwarding of data can be
   triggered by the mobile node either as part of Mobile IP registration
   or as a separate buffering protocol.

Top      Up      ToC       Page 47 
C.5.  Systems Evaluation and Performance Results

   In this section, we present some of the results from MPA
   implementation when applied to different handover scenarios.  We
   present the summary of results from our experiments using MPA
   techniques for two types of handovers: i) intra-technology and
   intra-domain, and ii) inter-technology and inter-domain.  We also
   present the results of how the MPA can bootstrap layer 2 security for
   both roaming and non-roaming cases.  Detailed procedures and results
   are explained in [MOBIQUIT07] and [SPRINGER07].

C.5.1.  Intra-Technology, Intra-Domain

   The results for MIPv6 and SIP mobility involving intra-domain
   mobility are shown in Figures 6 and 7, respectively.

                         Buffering    Buffering   Buffering   Buffering
                         (disabled)   (enabled)   (disabled)  (enabled)
                          & RO         & RO        & RO        & RO
                         (disabled)   (disabled)  (enabled)   (enabled)
    L2 handoff (ms)         4.00        4.33        4.00        4.00

    L3 handoff (ms)         1.00        1.00        1.00        1.00

    Avg. packet loss        1.33           0        0.66           0

    Avg. inter-packet      16.00       16.00       16.00       16.00
    arrival interval

    Avg. inter-packet       n/a        45.33        n/a        66.60
    arrival time during

    Avg. packet jitter      n/a        29.33        n/a        50.60

    Buffering Period        n/a        50.00        n/a        50.00

    Buffered Packets        n/a         2.00        n/a         3.00

   RO = Router Optimization

                  Figure 6: Mobile IPv6 with MPA Results

Top      Up      ToC       Page 48 
                                      Buffering      Buffering
                                      disabled       enabled
               L2 handoff (ms)           4.00          5.00

               L3 handoff (ms)           1.00          1.00

               Avg. packet loss          1.50             0

               Avg. inter-packet        16.00         16.00
               arrival interval

               Avg. inter-packet         n/a          29.00
               arrival time during

               Avg. packet jitter        n/a          13.00

               Buffering Period          n/a          20.00

               Buffered Packets          n/a           3.00

                  Figure 7: SIP Mobility with MPA Results

   For all measurements, we did not experience any performance
   degradation during handover in terms of the audio quality of the
   voice traffic.

   With the use of buffering during handover, packet loss during the
   actual L2 and L3 handover is eliminated with appropriate and
   reasonable settings of the buffering period for both MIP6 and SIP
   mobility.  In the case of MIP6, there is not a significant difference
   in results with and without route optimization.  It should be noted
   that results with more samples would be necessary for a more detailed

   In the case of non-MPA-assisted handover, handover delay and
   associated packet loss occur from the moment the link-layer handover
   procedure begins, up to successful processing of the binding update.
   During this process, IP address acquisitions via DHCP incur the
   longest delay.  This is due to the detection of duplicate IP
   addresses in the network before the DHCP request completes.  The
   binding update exchange also experiences a long delay if the CN is
   too far from the MN.  As a result, the non-MPA-assisted handover took

Top      Up      ToC       Page 49 
   an average of 4 seconds to complete, with an approximate packet loss
   of about 200 packets.  The measurement is based on the same traffic
   rate and traffic source as the MPA-assisted handover.

C.5.2.  Inter-Technology, Inter-Domain

   Handoff involving heterogeneous access can take place in many
   different ways.  We limit the experiment to two interfaces, and
   therefore results in several possible setup scenarios, depending upon
   the activity of the second interface.  In one scenario, the second
   interface comes up when the link to the first interface goes down.
   This is a reactive scenario and usually gives rise to undesirable
   packet loss and handoff delay.  In a second scenario, the second
   interface is being prepared while the mobile node still communicates
   using the old interface.  Preparation of the second interface should
   include setup of all the required state and security associations
   (e.g., PPP state, the Link Control Protocol (LCP), the Challenge
   Handshake Authentication Protocol (CHAP)).  If such a lengthy process
   is established ahead of time, it reduces the time taken for the
   secondary interface to be attached to the network.  After
   preparation, the mobile node decides to use the second interface as
   the active interface.  This results in less packet loss, as it uses
   make-before-break techniques.  This is a proactive scenario and can
   have two "flavors".  The first is where both interfaces are up; the
   second is when only the old interface is up and the prepared
   interface is brought up only when handoff is about to occur.  This
   scenario may be beneficial from a battery management standpoint.
   Devices that operate two interfaces simultaneously can rapidly
   deplete their batteries.  However, by activating the second interface
   only after an appropriate network has been selected, the client may
   utilize battery power effectively.

   As compared to non-optimized handover that may result in a delay of
   up to 18 sec and loss of 1000 or more packets during the handover
   from the wireless LAN (WLAN) to CDMA, we observed 0 packet loss and a
   50-ms handoff delay between the last pre-handoff packet and the first
   in-handoff packet.  This handoff delay includes the time due to link
   down detection and time needed to delete the tunnel after the mobile
   node has moved.  However, we observed about 10 duplicate packets
   because of the copy-and-forward mechanism at the access routers.  But
   these duplicate packets are usually handled easily by the upper-layer

C.5.3.  MPA-Assisted Layer 2 Pre-Authentication

   In this section, we discuss the results obtained from MPA-assisted
   layer 2 pre-authentication and compare these with EAP authentication
   and IEEE 802.11i's pre-authentication techniques.  Figure 8 shows the

Top      Up      ToC       Page 50 
   experimental testbed where we have conducted the MPA-assisted
   pre-authentication experiment for bootstrapping layer 2 security as
   explained in Section 7.  By pre-authenticating and pre-configuring
   the link, the security association procedure during handoff reduces
   to a 4-way handshake only.  Then the MN moves to the AP and, after
   association, runs a 4-way handshake by using the PSKap (Pre-shared
   Key at AP) generated during PANA pre-authentication.  At this point,
   the handoff is complete.  Details of this experimental testbed can be
   found in [MOBIQUIT07].

   +----------------------------+-----------+ +-------------+----------+
   |                                        | |                        |
   |  Home Domain       +-------++          | |                        |
   |                    |        |          | |                        |
   |                    |AAAHome |          | |                        |
   |                    +        |          | |                        |
   |                    +-----+--+          | |                        |
   |                          |             | |  Network B             |
   |   Network A              |             | |                        |
   |                        /----\          | |            /---\       |
   |                       /nAR   \         | |           /     \      |
   |                      | PAA    |--------+-+----------+ pAR   |     |
   |                       \      /         | |           \     /      |
   |                        \----/          | |            \-+-/       |
   |                           |            | |              |         |
   |             +-------------------|      | |              |         |
   |             |       IEEE 802.11i|      | |              |         |
   |           +------+          +------+   | |          +---+--+      |
   |           |      |          |      |   | |          |      |      |
   |           |AP2   |          |AP1   |   | |          |AP0   |      |
   |           +------+          +------+   | |          +------+      |
   |           +------+            +-----+  | |           +-----+      |
   |           |      |            |     |  | |           |     |      |
   |           |MN    +----------->|MN   |<+------------- |MN   |      |
   |           +------+            +-----+  | |           ++----+      |
   |----------------------------------------+ +------------+-----------+

              Figure 8: Experimental Testbed for MPA-Assisted
                    L2 Pre-Authentication (Non-Roaming)

Top      Up      ToC       Page 51 
                        |      +--------+             |
                        |      |        |             |
                        |      | AAAH   +             |
                        |      |        |             |
                        |      ++-------+             |
                        |       |                     |
                        |       |  Home AAA Domain    |
                        |       |                     |
                       RADIUS/  |
                       Diameter |
   +----------------------------+-----------+ +-------------+----------+
   |                            |           | |                        |
   | Roaming            +-------++          | |                        |
   | AAA Domain A       |        |          | |                        |
   |                    | AAAV   |          | |                        |
   |                    +        |          | |                        |
   | Network A          +-----+--+          | |  Network B             |
   |                          |             | |                        |
   |                          |             | |                        |
   |                        /----\          | |            /---\       |
   |                       /nAR   \         | |           /     \      |
   |                      | PAA    |--------+-+----------+ pAR   |     |
   |                       \      /         | |           \     /      |
   |                        \----/          | |            \-+-/       |
   |                           |            | |              |         |
   |             +-------------------|      | |              |         |
   |             |       IEEE 802.11i|      | |              |         |
   |           +------+          +------+   | |          +---+--+      |
   |           |      |          |      |   | |          |      |      |
   |           |AP2   |          |AP1   |   | |          |AP0   |      |
   |           +------+          +------+   | |          +------+      |
   |           +------+            +-----+  | |           +-----+      |
   |           |      |            |     |  | |           |     |      |
   |           |MN    +----------->|MN   |<---------------| MN  |      |
   |           +------+            +-----+  | |           ++----+      |
   -----------------------------------------+ +------------+-----------+

              Figure 9: Experimental Testbed for MPA-Assisted
                      L2 Pre-Authentication (Roaming)

Top      Up      ToC       Page 52 
   We have experimented with three types of movement scenarios involving
   both non-roaming and roaming cases, using the testbeds shown in
   Figures 8 and 9, respectively.  In the roaming case, the MN is
   visiting in a domain different than its home domain.  Consequently,
   the MN needs to contact the AAA server in the home domain (AAAH) from
   its new domain.  For the non-roaming case, we assume the MN is moving
   within its home domain, and only the local AAA server (AAAHome),
   which is the home AAA server for the mobile node, is contacted.

   The first scenario does not involve any pre-authentication.  The MN
   is initially connected to AP0 and moves to AP1.  Because neither
   network-layer authentication nor IEEE 802.11i pre-authentication is
   used, the MN needs to engage in a full EAP authentication with AP1 to
   gain access to the network after the move (post-authentication).
   This experiment shows the effect of the absence of any kind of

   The second scenario involves 802.11i pre-authentication and involves
   movement between AP1 and AP2.  In this scenario, the MN is initially
   connected to AP2, and starts IEEE 802.11i pre-authentication with
   AP1.  This is an ideal scenario to compare the values obtained from
   802.11i pre-authentication with that of network-layer assisted
   pre-authentication.  Both scenarios use RADIUS as the AAA protocol
   (APs implement a RADIUS client).  The third scenario takes advantage
   of network-layer assisted link-layer pre-authentication.  It involves
   movement between two APs (e.g., between AP0 and AP1) that belong to
   two different subnets where 802.11i pre-authentication is not
   possible.  Here, Diameter is used as the AAA protocol (PAA implements
   a Diameter client).

   In the third movement scenario, the MN is initially connected to AP0.
   The MN starts PANA pre-authentication with the PAA, which is
   co-located on the AR in the new candidate target network (nAR in
   network A) from the current associated network (network B).  After
   authentication, the PAA proactively installs two keys, PSKap1 and
   PSKap2, in AP1 and AP2, respectively.  By doing the key installations
   proactively, the PAA preempts the process of communicating with the
   AAA server for the keys after the mobile node moves to the new
   network.  Finally, because PSKap1 is already installed, AP1
   immediately starts the 4-way handshake.  We have used measurement
   tools such as ethereal and kismet to analyze the measurements for the
   4-way handshake and PANA authentication.  These measurements reflect
   different operations involved during network-layer pre-

   In our experiment, as part of the discovery phase, we assume that the
   MN is able to retrieve the PAA's IP address and all required
   information about AP1 and AP2 (e.g., channel, security-related

Top      Up      ToC       Page 53 
   parameters, etc.) at some point before the handover.  This avoids the
   scanning during link-layer handoff.  We have applied this assumption
   to all three scenarios.  Because our focus is on reducing the time
   spent on the authentication phase during handoff, we do not discuss
   the details of how we avoid the scanning.

   Types    |802.11i            | 802.11i           | MPA-assisted
            |Post-              | Pre-              | Layer 2
            |authentication     | authentication    | Pre-authentication
   Operation| Non-    | Roaming | Non-    | Roaming |Non-   | Roaming|
            | Roaming |         | Roaming |         |Roaming|        |
   Tauth    | 61 ms   |  599 ms | 99 ms   | 638 ms  | 177 ms| 831 ms |
   Tconf    | --      |  --     | --      | --      | 16 ms | 17ms   |
   Tassoc+  |         |         |         |         |       |        |
   4way     | 18 ms   |  17 ms  | 16 ms   | 17 ms   | 16 ms | 17 ms  |
   Total    | 79 ms   |  616 ms | 115 ms  | 655 ms  | 208 ms| 865 ms |
   Time     |         |         |         |         |       |        |
   affecting| 79 ms   |  616 ms | 16 ms   | 17 ms   | 15 ms | 17 ms  |
   handover |         |         |         |         |       |        |

                Figure 10: Results of MPA-Assisted Layer 2
                       Pre- and Post-Authentication

   Figure 10 shows the timing (rounded off to the most significant
   number) associated with some of the handoff operations we have
   measured in the testbed.  We describe each of the timing parameters

   "Tauth" refers to the execution of EAP-Transport Layer Security (TLS)
   authentication.  This time does not distinguish whether this
   authentication was performed during pre-authentication or a typical

   "Tconf" refers to the time spent during PSK generation and
   installation after EAP authentication is complete.  When network-
   layer pre-authentication is not used, this time is not considered.

   "Tassoc+4way" refers to the time dedicated to the completion of the
   association and the 4-way handshake with the target AP after the

Top      Up      ToC       Page 54 
   The first two columns in the figure show the results for non-roaming
   and roaming cases, respectively, when no pre-authentication is used
   at all.  The second two columns depict the same cases when IEEE
   802.11i pre-authentication is used.  The last two columns show when
   we used network-layer-assisted layer 2 pre-authentication.  When pre-
   authentication is used, only the factor Tassoc+4way affects the
   handoff time.  When no pre-authentication is used, the time affecting
   the handoff includes Tauth (the complete EAP-TLS authentication) plus

   That is precisely the time affecting the handoff in the case where
   the MN moves from AP0 to AP1 in the absence of pre-authentication.
   As it is seen, these delays are not suitable for real-time
   applications.  Indeed, for the non-roaming case, we obtained a ~80-ms
   delay for re-establishing the connection with target AP1.  It takes
   about 600 ms to complete the handoff when the MN moves to a visited
   domain and the home AAA server is located far away.  However,
   network-layer pre-authentication is only affected by Tassoc+4way
   (~17 ms) involving any kind of handoff authentication.  As is
   evident, IEEE 802.11i pre-authentication provides a comparable
   benefit (~16 ms) in terms of handoff but is limited to cases when APs
   are in the same Distribution System (DS).  Additionally, network-
   layer pre-authentication leverages a single EAP authentication to
   bootstrap security in several target APs by allowing the MN to move
   among APs under the same PAA without running EAP and consequently
   without contacting the AAA server.  In this sense, it extends IEEE
   802.11r advantages over IEEE 802.11i by allowing inter-subnet and
   inter-domain and even inter-technology handoffs.

C.6.  Guidelines for Handover Preparation

   In this section, we provide some guidelines for the roaming clients
   that use pre-authentication mechanisms to reduce the handoff delay.
   These guidelines can help determine the extent of the
   pre-authentication operation that is needed based on a specific type
   of movement of the client.  IEEE 802.11i and 802.11r take advantage
   of the pre-authentication mechanism at layer 2.  Thus, many of the
   guidelines observed for 802.11i-based pre-authentication and 802.11r-
   based fast roaming could also be applicable to the clients that use
   MPA-based pre-authentication techniques.  However, since MPA
   operations are not limited to a specific subnet and involve inter-
   subnet and inter-domain handover, the guidelines need to take into
   account other factors, such as movement pattern of the mobile node,
   cell size, etc.

Top      Up      ToC       Page 55 
   The time needed to complete the pre-authentication mechanism is an
   important parameter, since the mobile node needs to determine how
   much ahead of time the mobile node needs to start the
   pre-authentication process so that it can finish the desired
   operations before the handover to the target network starts.  The
   pre-authentication time will vary, depending upon the speed of the
   mobile node (e.g., pedestrian vs. vehicular) and cell sizes (e.g.,
   WiFi, Cellular).  Cell residence time is defined as the average time
   the mobile node stays in the cell before the next handoff takes
   place.  Cell residence time is dependent upon the coverage area and
   velocity of the mobile node.  Thus, cell residence time is an
   important factor in determining the desirable pre-authentication time
   that a mobile node should consider.

   Since the pre-authentication operation involves six steps as
   described in Section 6.3 and each step takes some discrete amount of
   time, only part of these sub-operations may be completed before
   handoff, depending upon the available delay budget.

   For example, a mobile node could complete only network discovery and
   the network-layer authentication process before the handoff and
   postpone the rest of the operations until after the handover is
   complete.  On the other hand, if it is a slow-moving vehicle and the
   adjacent cells are sparsely spaced, a mobile node could complete all
   the desired MPA-related operations.  Finishing all the MPA-related
   operations ahead of time reduces the handoff delay but adds other
   constraints, such as cell residence time.

   We give a numerical example here, similar to [MISHRA04].

      D = Coverage diameter

      v = Mobile node's velocity

      RTT = round trip time from AP to AAA server, including processing
      time for authentication (Tauth)

      Tpsk = Time spent to install keys proactively on the target APs

   If for a given value of D = 100 ft, Tpsk = 10 ms, and RTT = 100 ms, a
   mobile node needs to execute only the pre-authentication procedure
   associated with MPA, then the following can be calculated for a
   successful MPA procedure before the handoff is complete.

      2RTT + Tpsk < D/v

      v = 100 ft/(200 ms + 10 ms) = ~500 ft/sec

Top      Up      ToC       Page 56 
   Similarly, for a similar cell size, if the mobile node is involved in
   both pre-authentication and pre-configuration operations as part of
   the MPA procedure, and it takes an amount of time Tconf = 190 ms to
   complete the layer 3 configuration including IP address
   configuration, then for a successful MPA operation,

      2RTT + Tpsk + Tconf < D/v

      v = 100 ft/(200 ms + 10 ms + 190 ms) = ~250 ft/sec

   Thus, compared to only the pre-authentication part of the MPA
   operation, in order to be able to complete both pre-authentication
   and pre-configuration operations successfully, either the mobile node
   needs to move at a slower pace or it needs to expedite these
   operations for this given cell size.  Thus, types of MPA operations
   will be constrained by the velocity of the mobile node.

   As an alternative, if a mobile node does complete all of the
   pre-authentication procedure well ahead of time, it uses up the
   resources accordingly by way of an extra IP address, tunnel, and
   extra bandwidth.  Thus, there is always a tradeoff between the
   performance benefit obtained from the pre-authentication mechanism
   and network characteristics, such as movement speed, cell size, and
   resources utilized.

Top      Up      ToC       Page 57 
Authors' Addresses

   Ashutosh Dutta (editor)
   100 Nassau Park Blvd.
   Princeton, NJ  08540


   Victor Fajardo
   100 Nassau Park Blvd.
   Princeton, NJ  08540


   Yoshihiro Ohba
   Corporate R&D Center, Toshiba Corporation
   1 Komukai-Toshiba-cho, Saiwai-ku
   Kawasaki, Kanagawa  212-0001


   Kenichi Taniuchi
   Toshiba Corporation
   2-9 Suehiro-cho
   Ome, Tokyo  198-8710


   Henning Schulzrinne
   Columbia University
   Department of Computer Science
   450 Computer Science Building
   New York, NY  10027

   Phone: +1 212 939 7004