MOBOPTS Research Group V. Fajardo (Ed.) Internet-Draft TARI Expires: January 18, 2006 A. Dutta Telcordia Y. Ohba K. Taniuchi TARI H. Schulzrinne Columbia Univ. July 17, 2005 Media-Independent Pre-Authentication (MPA) Implementation Results draft-ohba-mobopts-mpa-implementation-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 18, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes an initial implementation of Media- independent Pre-Authentication (MPA) optimization. MPA is a mobile- Fajardo (Ed.), et al. Expires January 18, 2006 [Page 1] Internet-Draft MPA Implementation July 2005 assisted, secure handover optimization scheme that works over any link-layer and with any mobility management protocol. The implementation described in this document shows how existing protocols could be leveraged to realize the functionalities of MPA. It also includes empirical result gathered from experiments performed on a simulated network where the implementation resides. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Network Topology of MPA Testbed . . . . . . . . . . . . . . . 4 2.1 MPA Testbed using Mobile IPv6 . . . . . . . . . . . . . . 4 2.2 MPA Testbed using SIP Mobility . . . . . . . . . . . . . . 9 3. Non-MPA Assisted Handover Scenario . . . . . . . . . . . . . . 14 4. Evaluation and Performance Results . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8.1 Normative References . . . . . . . . . . . . . . . . . . . 24 8.2 Informative References . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . 27 Fajardo (Ed.), et al. Expires January 18, 2006 [Page 2] Internet-Draft MPA Implementation July 2005 1. Introduction Media-independent Pre-Authentication (MPA), is a new handover optimization mechanism that provides mobility optimization that is decoupled from existing mobility management schemes. It is designed to support a mobile terminal with one or more interfaces and is capable of securely crossing administrative domains. It also easily integrates with existing mobility management protocols. The MPA architecture is described in [I-D.ohba-mobopts-mpa-framework]. This document accompanies MPA architectural document [I-D.ohba- mobopts-mpa-framework] and it provides practical methods of implementing MPA. It also describes performace results gathered from these implementations and can clearly show how one can use existing protocols to provide MPA functionality. The succeeding sections also describe specific scenarios where both MPA and non-MPA approaches are evaluated and results of their comparison is described. Fajardo (Ed.), et al. Expires January 18, 2006 [Page 3] Internet-Draft MPA Implementation July 2005 2. Network Topology of MPA Testbed For the MPA evaluation, two(2) testbeds where developed each using a different mobility management protocol (MMP). The first implementation uses Mobile IPv6 (MIPv6) and the second uses SIP Mobility (SIP-M). The results of the test from both testbeds are described in the succeeding chapters. These results are also compared against a non-MPA scenario and describes the advantages of using MPA. 2.1 MPA Testbed using Mobile IPv6 The initial MPA testbed uses Mobile IPv6 (MIPv6) to facilitate mobility management functions between Mobile Node (MN) and the Correspondent Node (CN). Figure 1 describes the basic topology for the MPA testbed using MIPv6. Network 1 Network 2 Network 3 Network 4 (oPoA) (nPoA) +-------------+ | Mobile IPv6 | ------------------------------------------| Home Agent | | | (HA) | | +-------------+ +--------+ +------------+ |Router 1|---------|Router 2(RA)|---------+ +---+----+ |PAA(AA) | | | |Packet Buf | | | +------------+ | +------------+ | | |-| MIPv6 CN | | | | +------------+ | +-----+ | +-----+ | |-|AP 1 | |-|AP 2 | | +-----+ +-----+ : : : : +------------+ +------------+ |MN |---->|MN | |MIPv6 Client| |MIPv6 Client| |PaC | |PaC | +------------+ +------------+ Figure 1: MPA Test Network using Mobile IPv6 There are four networks. Network 1 is the old point of attachment (oPoA) where the mobile node (MN) intially resides prior to handover, Network 2 is new point of attachment (nPoA) where the MN is moving towards, Network 3 is where the correspondent node (CN) resides and Fajardo (Ed.), et al. Expires January 18, 2006 [Page 4] Internet-Draft MPA Implementation July 2005 finally Network 4 is where the Home Agent (HA) resides. All networks need not be adjacent. However, in the testbed each network is one IP hope away from each other. IPv6 addressing schemes are used in all networks and prefixes are statically configured to reduce complexity. As an initial state, the CN starts communicating with the MN while the MN is in Network 1 by sending streaming (RTP) traffic towrds the MN via HA within the MIPv6 tunnel. During handoff, the MIPv6 takes care of the IP continuity of the RTP traffic. Details of the topology of is as follows. 1. Network 1 * Router 1 (R1) - IPv6 Gateway to Network 1 and reachable via Network 2 and Network 4. * Access Point 1 (AP1) - 802.11 WLAN Access Point acting as oPoA of the MN 2. Network 2 * Router 2 (R2) - IPv6 Gateway to Network 2 and reachable via Network 1 and Network 3. It has a co-located Authentication Agent (AA) using PANA PAA (PAA), [I-D.ietf-pana-pana]. Packet buffering is also available in R2 to assist during handover. When packet buffering is used during handover, packet loss is averted. * Access Point 2 (AP2) - 802.11 WLAN Access Point acting as nPoA for the MN 3. Network 3 * Correspondent Node (CN) - IPv6 source of voice/ streaming traffic via RTP/UDP using the RAT (Robust Audio Tool) media agent. 4. Network 4 * Mobile IPv6 Home Agent (HA) - MIPv6 Home Agent (HA) responsible for IPv6 source of voice/ streaming traffic via RTP/UDP using the RAT (Robust Audio Tool) media agent. 5. MN * MIPv6 mobile node (MN) - MN that binds with the HA in Network 3.It uses an 802.11 WLAN optimized interface driver for handover. There is also an optinal kernel based network buffer for packet loss protection. Fajardo (Ed.), et al. Expires January 18, 2006 [Page 5] Internet-Draft MPA Implementation July 2005 In MIPv6, the MN creates an IPv6-IPv6 tunnel with the HA as part of the mobility management. With the addition of MPA, a proactive handover tunnel is additionally created between the MN and R2 in Network 2. In the testbed, this tunnel is based on IPsec tunnel mode ESP and PANA is used for dynamically establishing and terminating the IPsec tunnel. Note that for simplicity, the required cipher keys for IPsec tunnel mode ESP are pre-configured on the MN and R2. Though IKE was not used for establishing the IPsec tunnel mode ESP in the test scenario, use of IKE before the handover will not impact on the overall scheme. As part of the MPA scheme, the MIPv6 tunnel traffic between the MN and HA goes through the IPsec tunnel created by MPA with appropriate IPsec policy settings. In the testbed, the required IPsec policy parameters including nCoA are also carried in PANA messages. Details of the MPA message flows is shown in Figure 2. Fajardo (Ed.), et al. Expires January 18, 2006 [Page 6] Internet-Draft MPA Implementation July 2005 Router 2 (RA) MN AP1 AP2 PAA (AA) HA CN |L2 Association| | | | | | and oCoA assignment | | | | |<------------>| | | | | | MIPv6 and voice communication start | | | |<------------------------------------------------->|<------>| | Step 1 Pre-authentication with PAA | | | |<-------------------------------------->| | | | Step 2 Pre-configuration with R2 | | | | and nCoA assignment preparations | | | |<-------------------------------------->| | | | | | | | | |IPsec tunnel is established with R2 | | |<-------------------------------------->| | | | Step 3 MIPv6 Binding Update | | | | |<------------------------------------------------->| | |MIPv6 voice traffic goes through IPsec tunnel | | |<======================================>|<----------------->| | Step 4 Deletion of the IPsec tunnel | | | | Start of buffering (optional) | | | |<-------------------------------------->| | | X Step 5 Association with AP 2| | | | X<- - - - - - - - - - - - - - >| | | | X MIPv6 voice traffic goes to nCoA | | | | End of buffering (optional) | | | | |<---------------------------------------------------------->| <- - - - ->802.11 frame <--------->IP packet <=========>IPsec tunneling packet X Potential Packet loss Figure 2: MPA Communication Flow in the Test Environment with MIPv6 As an initial state the MN associates itself with AP 1. It configures based on a statically configure prefix. This IP address is the old Care of Address (oCoA) that is sent to the HA via the initial Binding Update (BU). Voice traffic then initiated from CN to MN via the HA (inside the MIPv6 tunnel). The voice traffic is carried over RTP/UDP using the RAT (Robust Audio Tool) media agent. MPA process starts when the MN pre-authenticates with Network 2. This step is similar to SIP-Mobility Section 2.2 and shows the generic application of pre-authentication with any mobility management scheme. Pre-authentication can be triggered by some localized policy that includes monitoring the MN's signal strength or Fajardo (Ed.), et al. Expires January 18, 2006 [Page 7] Internet-Draft MPA Implementation July 2005 maybe an indication of "link going down" event [802.21]. In the pre- authentication procedure (Step 1 of Figure 2, the MN prepares for link-layer handover and obtains all relevant information about the target network. After successful completion of the pre- authentication procedure, an MPA SA is established between the MN and AA in Network 2. In the MIPv6 tested, information about the target network is also obtained in Step 1. Note that in the testbed these information are locally stored on the MN before starting the pre- authentication procedure. In step 2, the pre-configuration procedure is executed to configure parameters required for communicating via Network 2. Such parameters include nCoA and are communicated back via PANA messaging. As part of the MIPv6 functions, the MN sends a BU to HA to update the mobility binding. Once HA is updated, MIPv6 will use nCoA and traffic will flow via Network 2. Since the MN and R2 are aware of nCoA, it is also used during the establishment of the IPsec tunnel. The IPsec policies established between the MN and R2 will allow MIPv6 traffic to be forwared through the IPsec tunnel. This process is step 3 of Figure 2. When MPA setup is completed, the MN can perform proactive secure handover. The MN and R2 tear down the IPsec tunnel as part of this process and MN associates with AP 2. Since the HA is already configured with the nCoA, the MN does not need to send a BU to the HA after handover. R2 should naturally forwards traffic for the MN as it is managed by the HA. The signalling of the movement between MN and R2 are also similar to the SIP-mobility scenario in that it uses PANA-Update-Request messages. As shown in Figure 2, there is potential packet loss during 'X'. In the testbed, an optional packet buffering mechanism has been implemented to assist during handover. Prior to handover, setp 4 in Figure 2, the MN signals R2 so that buffering of packets that is destined for the MN can begin. So during the handover, R2 buffers all packets that is already in transit and has a destination of oCoA of the MN. Once handover has successfully completed, the MN again signals R2 that it can end buffering of packets and forward any buffered packets to the MN at nCoA. This mechanism guarantees no packet loss for incoming packet to the MN during the handover. The results of MPA with and without buffering is shown in Section 4. As shown in the results, adding buffering has a side effect of increasing overall delay because of additional signaling as well as delay caused by the act of buffering itself. A source of delay can also be attributed to the fact that the packet sequence has to be maintained during forwarding of buffered packets so newly arrived packets has to wait until all buffered packets has been forwarded. Fajardo (Ed.), et al. Expires January 18, 2006 [Page 8] Internet-Draft MPA Implementation July 2005 2.2 MPA Testbed using SIP Mobility The second MPA testbed uses SIP Mobility (SIP-M) to facilitate mobility management functions between Mobile Node (MN) and the Correspondent Node (CN). Figure 3 describes the basic topology for the MPA testbed using SIP-M. Network 1 Network 2 Network 3 (oPoA) (nPoA) +--------+ +------------+ |Router 1|---------|Router 2(RA)|---------+ +---+----+ |PAA(AA) | | | |Packet Buf | | | |DHCP Relay | | | +--------+ |Agent (CA) | | +------------+ |-|DHCP | +------------+ | |CN | | |Server 1| | +------------+ |-|SIP-M Client| | +--------+ |-|DHCP | | +------------+ | | |Server 2 | | | | +------------+ | | | | | +-----+ | +-----+ | |-|AP 1 | |-|AP 2 | | +-----+ +-----+ : : : : +------------+ +------------+ |MN |---->|MN | |SIP-M Client| |SIP-M Client| |PaC | |PaC | +------------+ +------------+ Figure 3: MPA Test Network using SIP Mobility The topology for the SIP Mobility (SIP-M) testbed is very similar to Figure 1. The first three (3) networks have the same configuration except that IPv4 addressing is used and mobility management is done via SIP. Also, IP addressing is based on DHCP Server assignments instead of static configurations. In addition, Network 4 is not required since Home Agent (HA) is not present in the SIP-M tests. 1. Network 1 * Router 1 (R1) - IPv4 Gateway to Network 1 and reachable via Network 2 * DHCP Server 1 (DHCPs1) - IP addressing needs for Network 1 Fajardo (Ed.), et al. Expires January 18, 2006 [Page 9] Internet-Draft MPA Implementation July 2005 * Access Point 1 (AP1) - 802.11 WLAN Access Point acting as oPoA of the MN 2. Network 2 * Router 2 (R2) - IPv4 Gateway to Network 2 and reachable via Network 1 and Network 3. It has a co-located Authentication Agent (AA) using PANA PAA (PAA), [I-D.ietf-pana-pana] and a co-located DHCP relay-agent acting as Configuration Agent (CA), [RFC3046]. Packet buffering is also available in R2 to assist during handover. When packet buffering is used during handover, packet loss is averted. * DHCP Server 2 (DHCPs2) - IP addressing needs for Network 2. It's reachability is extended by the DHCP relay-agent in R2 * Access Point 2 (AP2) - 802.11 WLAN Access Point acting as nPoA for the MN 3. Network 3 * Correspondent Node (CN) - Co-located SIP Mobility Client and source of voice/streaming traffic via RTP/UDP using the RAT (Robust Audio Tool) media agent. 4. MN * Co-located SIP Mobility Client that binds with the CN. It uses an 802.11 WLAN optimized interface driver for handover. There is also an optinal kernel based network buffer for packet loss protection. To simplify the scenario, SIP proxies are not involved to set up the initial communication between the CN and MN. Router 2 provides IP- in-IP tunneling [RFC1853] to facilitate routing to the MN while the MN is still in Network 1. This is part of the MPA handover procedure. The IP-in-IP tunnel will make it appear as though the MN is already in Network 2 and the streaming traffic will be forwarded via the tunnel. Details of the MPA message flows is shown in Figure 4. Fajardo (Ed.), et al. Expires January 18, 2006 [Page 10] Internet-Draft MPA Implementation July 2005 Router 2 (RA) PAA (AA) DHCP DHCP Relay DHCP MN AP1 Server 1 AP2 Agent Server 2 CN |L2 Association| | | | | | |<- - - - - - >| | | | | | | oCoA assignment | | | | | |<------------------->| | | | | | SIP and voice communication start | | | |<----------------------------------------------------------->| | Step 1 Pre-authentication with PAA | | | |<-------------------------------------->| | | | Step 2 Pre-configuration with DHCP RA | | | |<-------------------------------------->| | | | | | | |DHCP Relay | | | | | | |<--------->| | | nCoA assignment | | | | | |<-------------------------------------->| | | |IP in IP tunnel is established with R2 | | |<-------------------------------------->| | | |Step 3 SIP Re-invite goes through IP-in-IP tunnel | | |<======================================>|<------------------>| |Voice traffic goes through IP in IP tunnel | | |<======================================>|<------------------>| | Step 4 Deletion of the tunnel | | | | Start of buffering (optional) | | | |<-------------------------------------->| | | X Step 5 Association with AP 2| | | | X<- - - - - - - - - - - - - - >| | | | X Voice traffic goes to nCoA | | | | | End of buffering (optional) | | | | |<----------------------------------------------------------->| <- - - - ->802.11 frame <--------->IP packet <=========>IP in IP tunneling packet X Potential Packet loss Figure 4: MPA Communication Flow in the Test Environment with SIP-M As an initial state the MN associates itself with AP1 and obtains the IP address from DHCP Server 1 in Network 1. The IP address obtained in Network 1 is the old Care of Address (oCoA). To setup streaming traffic, the CN's SIP user agent attempts to connect with the MN's SIP user agent. After a successful SIP connection, voice traffic is initiated from CN to MN. The voice traffic is carried over RTP/UDP using the RAT (Robust Audio Tool) media agent. Fajardo (Ed.), et al. Expires January 18, 2006 [Page 11] Internet-Draft MPA Implementation July 2005 MPA test starts when the MN pre-authenticates with Network 2. This step can be triggered by some localized policy that includes monitoring the MN's signal strength or maybe an indication of "link going down" event [802.21]. In anycase, pre-authentication prepares the MN for the handover process by obtaining information about the target network. Obtaining this information can be done via information servers that maybe present in a reachable network [802.21]. In the case of the testbed, information servers are not present to simplify the network topology. Target network information are pre-defined within the MN to simulate a successful information server query. Since the relevant information is available, the MN authenticates to the PAA and derives proper security keys and establishes a security association (SA) with the MN. The pre- authentication process is step 1 of Figure 4. In step 2, the MN pre-configures with Network 2. The MN performs pre-configuration by communicating with DHCP Proxy to obtain an IP address for Network 2. Other implementation may require more than just the IP address. In such a case, more information can pre- provisioned and can be communicated to the MN during this phase. In the testbed, the DHCP proxy and Authentication Agent (AA) are co- located and the DHCP proxy provides IP assignment services to pre- authenticated MN's via DHCP Server 2. The new IP address is relayed back to the MN as part of the PANA exchanges. The newly obtained IP address is the new Care of Address (nCoA) and is usable in Network 2. Once the MN gets the nCoA, it can create an IP-in-IP tunnel with Router 2 of Network 2 and assign the nCoA as a virtual interface address of this tunnel. Once a tunnel is created, the MN performs proactive secure handover. Since the MN is configured with the nCoA, the MN can send a SIP Re- invite to CN with nCoA as its new contact address via the tunnel. In the testbed, all traffic between CN and MN will be carried within the tunnel once SIP Re-invite completes. This traffic includes the voice traffic initiated in the initial step. The remaining steps allow the MN to perform the actual secure proactive handover. As the mobile detects the nPoA and makes a decision to switch over to Network 2 it starts association with AP 2. Once association completes successfully, the MN configures itself by tearing down the local tunnel end-point and re-assign the nCoA to the physical interface associated with AP 2. In addition, it also updates its local default route information with that of Network 2. The MN then sends a PANA-Update-Request message to the access router R2. The purpose of this message is to notify Router 2 to tear down its tunnel end-point. The MN's ARP entry for nCoA is also be updated in R2 upon receipt of this message. This reduces the delay due to ARP exchanges that usually happens when a new IP address is first Fajardo (Ed.), et al. Expires January 18, 2006 [Page 12] Internet-Draft MPA Implementation July 2005 used in a network. Similar to MIPv6 with MPA, a optional packet buffering exists in R2 to assist with packet loss during handover. The mechanism for buffering remains the same as with MIPv6 with MPA as described in Section 2.1. The results of MIPv6 MPA with buffering is also shown in Section 4 and is consistent with MIPv6 results with buffering. Fajardo (Ed.), et al. Expires January 18, 2006 [Page 13] Internet-Draft MPA Implementation July 2005 3. Non-MPA Assisted Handover Scenario For the comparison purposes, non-MPA assisted handover is also described in this section. The non-MPA scheme were tested using Figure 3. Note that the expected behavior described in this section would be similar if the testbed used was Figure 1. The non-MPA scheme does not provide any proactive handover mechanism and therefore follow a typical procedure for handover. To make a good comparison with the MPA scenario, the MN boostraps itself in Network 1 and obtains an oCoA from DHCP Server 1 in the non-MPA scenario. In addition, it uses the same handover policy to decide when actual handover process should begin, i.e. signal strength or link layer down event. Once the policy indicates that handover should begin, the MN disassociates with AP 1 and associates with AP 2. On successful association, it obtains an IP address (nCoA) from DHCP Server 2, then assigns that address to its physical interface. During this period, no data can reach the MN. Even after associating with AP 2, traffic towards the MN through Router 2 may not be allowed since the MN is not yet authenticated in Network 2. So the authentication process becomes part of the overall handover and hence the additional delay. Only when the authentication is successful can packets be forwarded to the MN via Network 2. An additional requirement before packet forwarding can happen is to send binding updates to inform the CN of the MN's nCoA. In the testbed, the MN sends SIP Re-invite with the nCoA and causes voice traffic to be forwarded via Network 2. This process also adds delay and could have potentially taken an even longer amount of time if the MB's target network and the CN are far apart. Fajardo (Ed.), et al. Expires January 18, 2006 [Page 14] Internet-Draft MPA Implementation July 2005 Router 2(RA) PAA(AA) DHCP DHCP Relay DHCP MN AP1 Server 1 AP2 Agent Server 2 CN |L2 Association| | | | | | |<- - - - - - >| | | | | | | IP address assignment | | | | |<------------------->| | | | | | SIP and voice communication start | | | |<----------------------------------------------------------->| | Association with AP 2 | | | | X<- - - - - - - - - - - - - - >| | | | X new IP address assignment | | | | X<-------------------------------------------------->| | X Authentication with PAA | | | | X<-------------------------------------->| | | X SIP Re-invite | | | | X<----------------------------------------------------------->| X Voice traffic goes to new IP address | | | |<----------------------------------------------------------->| <- - - - ->802.11 frame <--------->IP packet X Potential Packet loss Figure 5: Communication Flow for Non-MPA Assisted Handover in the Test Environment using SIP-M Fajardo (Ed.), et al. Expires January 18, 2006 [Page 15] Internet-Draft MPA Implementation July 2005 4. Evaluation and Performance Results Measurements taken from testbed Figure 1 are shown in Figure 6 and testbed Figure 3 are shown in Figure 7. Measurements are based on the following common scenarios for both testbed and the values are mean values taken from three (3) test samples. o AP 1 and AP 2 are 802.11b access points operating on separate channels. o L2 handoff measurements are based on complete open mode association sequence. Measurement is a mean value in millisecond. o L3 handoff measurements are based on linux network layer configuration including routing table updates, neighbhor cache or ARP table updates and interface address assignment. Measurement is a mean value in millisecond. o Avg. packet loss is number of packets that failed to reach the MN during L2 and L3 handoff periods. Measurement is a mean value. o Avg. inter-packet arrival interval is the average time interval between each RTP packets as they arrive in the MN. The measurement is taken from the MN. This value mostly reflects the RTP packet generation rate in the CN where RTP traffic comes from. However, it should also include the propagation time from CN to MN including tunneling (MIPv6 and IPsec) but this propagation time is orders of magnitude smaller than the packet generation rate. The measured value of this is 16 msec. o Avg. inter-packet arrival time during handover is the amount of time in msec between the last RTP packet received by the MN before handover and the first RTP packet received by the MN after handover. This will include the binding update signaling (SIP and MIPv6) as well as any buffer signaling. Measurement is a mean value in millisecond. o Avg. packet jitter is the avg. inter-packet arrival time during handover minus the expected avg. inter-packet arrival interval. This provides a measurement of the avg. additional delay incurred because of the handover process. o R2 Buffering is an optional mechanism in the router to perform IP packet buffering on behalf of the MN during handoff period. It is a measure of the length of the buffering period. Measurement is a mean value in millisecond. Fajardo (Ed.), et al. Expires January 18, 2006 [Page 16] Internet-Draft MPA Implementation July 2005 o Buffered packets is the number of packets buffered and eventually forwarded to the MN after handoff. This is available only if buffering is enabled. o Non-critical portions of the process is omitted such as pre- authorization. Such process can be implemented in any network infrastructure though it is not critical for the purpose of handover measurements. o Pre-athentication protocol used is PANA to establish SA between MN and Network 2. Also, handover signaling information is carried by PANA messages after successful pre-authentication. o RO is MIPv6 route optimiziation where the CN sends RTP packets directly to the MN's nCoA bypassing the HA. o All IP nodes in both testbed uses linux 2.6.x with Helsinkin University of Technology (HUT) implementation of Mobile IPv6. The results for MIPv6 and SIP mobility are shown in Figure 6 and Figure 7, respectively. Fajardo (Ed.), et al. Expires January 18, 2006 [Page 17] Internet-Draft MPA Implementation July 2005 Buffering Buffering Buffering Buffering (disabled) (enabled) (disabled) (enabled) RO RO RO RO (disabled) (disabled) (enabled) (enabled) ------------------------------------------------------------------- L2 handoff (msec) 4.00 4.33 4.00 4.00 L3 handoff (msec) 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 (msec) Avg. inter-packet n/a 45.33 n/a 66.60 arrival time during handover (msec) Avg. packet jitter n/a 29.33 n/a 50.60 (msec) Buffering Period n/a 50.00 n/a 50.00 (msec) Buffered Packets n/a 2.00 n/a 3.00 Figure 6: Mobile IPv6 with MPA Results Fajardo (Ed.), et al. Expires January 18, 2006 [Page 18] Internet-Draft MPA Implementation July 2005 Buffering Buffering disabled enabled ----------------------------------------------- L2 handoff (msec) 4.00 5.00 L3 handoff (msec) 1.00 1.00 Avg. packet loss 1.50 0 Avg. inter-packet 16.00 16.00 arrival interval (msec) Avg. inter-packet n/a 29.00 arrival time during handover (msec) Avg. packet jitter n/a 13.00 (msec) Buffering Period n/a 20.00 (msec) Buffered Packets n/a 3.00 Figure 7: SIP Mobility with MPA Results For all measurement, 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 an appropriate and reasonable settings of 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 to do more detailed analysis. In case of non-MPA assisted handover, handover delay and associated packet loss occurs 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 incurs the longest delay. This is due to the detection of duplicate of IP address in the network before DHCP request completes. Binding update exchange also experiences 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 Fajardo (Ed.), et al. Expires January 18, 2006 [Page 19] Internet-Draft MPA Implementation July 2005 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. Fajardo (Ed.), et al. Expires January 18, 2006 [Page 20] Internet-Draft MPA Implementation July 2005 5. Security Considerations This document's intent is to describe different implementations of the MPA framework defined in [I-D.ohba-mobopts-mpa-framework]. To this end, any security concerns with this document are likely a reflection of security concerns with the MPA framework itself. Fajardo (Ed.), et al. Expires January 18, 2006 [Page 21] Internet-Draft MPA Implementation July 2005 6. IANA Considerations This document has no actions for IANA. Fajardo (Ed.), et al. Expires January 18, 2006 [Page 22] Internet-Draft MPA Implementation July 2005 7. Acknowledgments We would like to thank Kensaku Fujimoto and Provin Gurung for MPA prototype implementation support. Fajardo (Ed.), et al. Expires January 18, 2006 [Page 23] Internet-Draft MPA Implementation July 2005 8. References 8.1 Normative References [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [I-D.ietf-pana-pana] Forsberg, D., "Protocol for Carrying Authentication for Network Access (PANA)", draft-ietf-pana-pana-09 (work in progress), July 2005. 8.2 Informative References [I-D.ietf-mobike-design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE protocol", draft-ietf-mobike-design-02 (work in progress), February 2005. [RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995. [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001. [I-D.ohba-mobopts-mpa-framework] Ohba, Y., "A Framework of Media-Independent Pre- Authentication (MPA)", draft-ohba-mobopts-mpa-framework-00 (work in progress), February 2005. [802.21] "IEEE 802.21", IEEE . Fajardo (Ed.), et al. Expires January 18, 2006 [Page 24] Internet-Draft MPA Implementation July 2005 Authors' Addresses Victor Fajardo Toshiba America Research, Inc. 1 Telcordia Drive Piscataway, NJ 08854 USA Phone: +1 732 699 5368 Email: vfajardo@tari.toshiba.com Ashutosh Dutta Telcordia Technologies 1 Telcordia Drive Piscataway, NJ 08854 USA Phone: +1 732 699 3130 Email: adutta@research.telcordia.com Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscataway, NJ 08854 USA Phone: +1 732 699 5305 Email: yohba@tari.toshiba.com Kenichi Taniuchi Toshiba America Research, Inc. 1 Telcordia Drive Piscataway, NJ 08854 USA Phone: +1 732 699 5308 Email: ktaniuchi@tari.toshiba.com Fajardo (Ed.), et al. Expires January 18, 2006 [Page 25] Internet-Draft MPA Implementation July 2005 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 Fajardo (Ed.), et al. Expires January 18, 2006 [Page 26] Internet-Draft MPA Implementation July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Fajardo (Ed.), et al. Expires January 18, 2006 [Page 27]