One document matched: draft-ohba-mobopts-mpa-implementation-02.txt
Differences from draft-ohba-mobopts-mpa-implementation-01.txt
MOBOPTS Research Group V. Fajardo (Ed.)
Internet-Draft TARI
Expires: September 5, 2006 A. Dutta
Telcordia
Y. Ohba
K. Taniuchi
TARI
H. Schulzrinne
Columbia Univ.
March 4, 2006
Media-Independent Pre-Authentication (MPA) Implementation Results
draft-ohba-mobopts-mpa-implementation-02
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 September 5, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes an initial implementation of Media-
independent Pre-Authentication (MPA) optimization. MPA is a mobile-
Fajardo (Ed.), et al. Expires September 5, 2006 [Page 1]
Internet-Draft MPA Implementation March 2006
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
4.1. Intra-technology, Inter-domain . . . . . . . . . . . . . . 16
4.2. Inter-technology, Inter-domain . . . . . . . . . . . . . . 20
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 September 5, 2006 [Page 2]
Internet-Draft MPA Implementation March 2006
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 September 5, 2006 [Page 3]
Internet-Draft MPA Implementation March 2006
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 September 5, 2006 [Page 4]
Internet-Draft MPA Implementation March 2006
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 September 5, 2006 [Page 5]
Internet-Draft MPA Implementation March 2006
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 September 5, 2006 [Page 6]
Internet-Draft MPA Implementation March 2006
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 September 5, 2006 [Page 7]
Internet-Draft MPA Implementation March 2006
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 September 5, 2006 [Page 8]
Internet-Draft MPA Implementation March 2006
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 September 5, 2006 [Page 9]
Internet-Draft MPA Implementation March 2006
* 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 September 5, 2006 [Page 10]
Internet-Draft MPA Implementation March 2006
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 September 5, 2006 [Page 11]
Internet-Draft MPA Implementation March 2006
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 September 5, 2006 [Page 12]
Internet-Draft MPA Implementation March 2006
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 September 5, 2006 [Page 13]
Internet-Draft MPA Implementation March 2006
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 September 5, 2006 [Page 14]
Internet-Draft MPA Implementation March 2006
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 September 5, 2006 [Page 15]
Internet-Draft MPA Implementation March 2006
4. Evaluation and Performance Results
We have experimented MPA techniques for two types of heterogeneous
handovers as defined in [I-D.ohba-mobopts-heterogeneous-requirement].
We provide the details of two of these: I)Intra-technology, Inter-
domain, II) Inter-technology, Inter-domain. Section 4.1 discusses
the results of case I whereas Section 4.2 discusses the results of
case II.
4.1. Intra-technology, Inter-domain
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.
Fajardo (Ed.), et al. Expires September 5, 2006 [Page 16]
Internet-Draft MPA Implementation March 2006
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.
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 September 5, 2006 [Page 17]
Internet-Draft MPA Implementation March 2006
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 September 5, 2006 [Page 18]
Internet-Draft MPA Implementation March 2006
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 September 5, 2006 [Page 19]
Internet-Draft MPA Implementation March 2006
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.
4.2. Inter-technology, Inter-domain
Handoff involving heterogeneous access can take place in many
different ways. We limit the experiment to two interface 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 usually gives rise to undesirable packet
loss and handoff delay. In a second scenario, the second interface
is being prepared while the mobile still communicates using the old
interface (Sec 5.8.2 of accompanying document). Preparation of the
second interface should include setup of all the required state and
security associations (e.g., PPP state, LCP, CHAP). Such lengthly
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 can 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(2) flavors. The first is where both interfaces are up and
the second is when only the old interface is up the prepared
interface is brougth 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 may utilize
battery effectively. Information discovery and MPA remain the same
as in Section 5.1 with intra-technology handover. In this experiment
we add new optimization techniques such as faster link down detection
mechanism and a copy-forwarding technique at the access router to
help reduce transient packet loss during the handover. Detailed
discussion of faster link down detection and copy-forwarding
mechanisms are out of scope for the current document.
As compared to non-optimized handover that may result in delay up to
18 sec and 1000 packet loss during handover from WLAN to CDMA, we
were able to achieve 0 packet loss, and 50 ms handoff delay between
the last pre-handoff packet and 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 has moved. However we
observed about 10 duplicate packets because of the copy-forwarding
mechanism at the access routers. But these duplicate packets are
usually handled easily by the upper layer protocols.
Fajardo (Ed.), et al. Expires September 5, 2006 [Page 20]
Internet-Draft MPA Implementation March 2006
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 September 5, 2006 [Page 21]
Internet-Draft MPA Implementation March 2006
6. IANA Considerations
This document has no actions for IANA.
Fajardo (Ed.), et al. Expires September 5, 2006 [Page 22]
Internet-Draft MPA Implementation March 2006
7. Acknowledgments
We would like to thank Kensaku Fujimoto and Provin Gurung for MPA
prototype implementation support.
Fajardo (Ed.), et al. Expires September 5, 2006 [Page 23]
Internet-Draft MPA Implementation March 2006
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-10 (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-07 (work in progress),
January 2006.
[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-01
(work in progress), July 2005.
[I-D.ohba-mobopts-heterogeneous-requirement]
Dutta, A., "Problem Statement for Heterogeneous Handover",
draft-ohba-mobopts-heterogeneous-requirement-01 (work in
progress), March 2006.
[802.21] "IEEE 802.21", IEEE .
Fajardo (Ed.), et al. Expires September 5, 2006 [Page 24]
Internet-Draft MPA Implementation March 2006
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 September 5, 2006 [Page 25]
Internet-Draft MPA Implementation March 2006
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 September 5, 2006 [Page 26]
Internet-Draft MPA Implementation March 2006
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 (2006). 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 September 5, 2006 [Page 27]
| PAFTECH AB 2003-2026 | 2026-04-22 22:11:10 |