RFC 6252
A Framework of Media-Independent Pre-Authentication (MPA) for Inter-Domain Handover Optimization
Pages: 57
Informational
Informational
Part 3 of 3 – Pages 40 to 57
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 time. 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 nCoA.
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 network. 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
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 MPA.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
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 effect. 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 below.
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
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 networks (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.
(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.
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 (ms) Avg. inter-packet n/a 45.33 n/a 66.60 arrival time during handover (ms) Avg. packet jitter n/a 29.33 n/a 50.60 (ms) Buffering Period n/a 50.00 n/a 50.00 (ms) Buffered Packets n/a 2.00 n/a 3.00 RO = Router Optimization Figure 6: Mobile IPv6 with MPA Results
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 (ms) Avg. inter-packet n/a 29.00 arrival time during handover (ms) Avg. packet jitter n/a 13.00 (ms) Buffering Period n/a 20.00 (ms) 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 analysis. 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
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 protocols.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
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)
+-----------------------------+ | +--------+ | | | | | | | 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)
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 pre-authentication. 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- authentication. 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
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 below. "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 post-authentication. "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 handoff.
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 Tassoc+4way. 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.
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
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.
Authors' Addresses
Ashutosh Dutta (editor) NIKSUN 100 Nassau Park Blvd. Princeton, NJ 08540 USA EMail: ashutosh.dutta@ieee.org Victor Fajardo NIKSUN 100 Nassau Park Blvd. Princeton, NJ 08540 USA EMail: vf0213@gmail.com Yoshihiro Ohba Corporate R&D Center, Toshiba Corporation 1 Komukai-Toshiba-cho, Saiwai-ku Kawasaki, Kanagawa 212-0001 Japan EMail: yoshihiro.ohba@toshiba.co.jp Kenichi Taniuchi Toshiba Corporation 2-9 Suehiro-cho Ome, Tokyo 198-8710 Japan EMail: kenichi.taniuchi@toshiba.co.jp Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 USA Phone: +1 212 939 7004 EMail: hgs@cs.columbia.edu