One document matched: draft-ohba-mobopts-mpa-implementation-00.txt
MOBOPTS Research Group A. Dutta
Internet-Draft Telcordia
Expires: January 2, 2006 Y. Ohba
K. Taniuchi
V. Fajardo (Ed.)
TARI
H. Schulzrinne
Columbia Univ.
July 2005
Media-Independent Pre-Authentication (MPA) Implementation Results
draft-ohba-mobopts-mpa-implementation-00
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 2, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes an initial implementation of Media-
independent Pre-Authentication (MPA) optmization. MPA is a mobile-
assisted, secure handover optimization scheme that works over any
Dutta, et al. Expires January 2, 2006 [Page 1]
Internet-Draft MPA Implementation July 2005
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 simulation network where the implementation resides.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Network Topology of MPA Testbed . . . . . . . . . . . . . . . 4
3. MPA Assisted Handover Scenario . . . . . . . . . . . . . . . . 6
4. Non-MPA Assisted Handover Scenario . . . . . . . . . . . . . . 9
5. Evaluation and Performace Results . . . . . . . . . . . . . . 11
6. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1 Normative References . . . . . . . . . . . . . . . . . . . 13
7.2 Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 16
Dutta, et al. Expires January 2, 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 one method of implementating
MPA. It also describes performace results gathered from the
implementation experience and can clearly show how one can use
exsiting protocols to provide MPA functionality. The succeeding
sections also describes specific scenarios where both MPA and non-MPA
approaches are evaluated and results of thier comparison is
described.
Dutta, et al. Expires January 2, 2006 [Page 3]
Internet-Draft MPA Implementation July 2005
2. Network Topology of MPA Testbed
The experimental MPA network topology is shown in Figure 1.
Network 1 Network 2 Network 3
(oPoA) (nPoA)
+--------+ +------------+
|Router 1|---------|Router 2(RA)|---------+
+---+----+ |PAA(AA) | |
| |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 1: Network Topology
There are three networks defined in the implementation environment.
Network 1 is old point of attachment (oPoA), Network 2 is new point
of attachment (nPoA), and network 3 is where the correspondent node
(CN) resides. The mobile node (MN) is initially in Network 1 and
starts communicating with the CN. Network 1, network 2, and network
3 do not need to be adjacent. However, in the test scenario, network
1, network 2 and network 3 are one IP hop away. During handoff, a
specific Mobility Management Protocol (MMP) can take care of the IP
continuity of the streaming traffic.
Network 1 consists of DHCP Server 1, access point (AP) 1 and Access
Router 1. Network 2 consists a DHCP Server 2, AP 2 and Access Router
2. AP 1 and AP 2 are 802.11 wireless LAN access points. Router 2
also works as a PANA Authentication Agent (PAA) [I-D.ietf-pana-pana]
and a DHCP Relay Agent [RFC3046] for Network 2, though they do not
have to be co-located. DHCP relay-agent also acts like a
Configuration Agent (CA) that helps obtaining the IP address
assignments for the mobile during pre-authentication. Network 3
Dutta, et al. Expires January 2, 2006 [Page 4]
Internet-Draft MPA Implementation July 2005
consists of the CN that communicates with the MN in Network 1. Both
the CN and MN are equipped with mobility enabled SIP client. Mobile
SIP client is also equipped with PANA Client (PaC). To simplify the
scenario, SIP proxies are not involved to set up the initial
communication between the CN and MN. The MN uses 802.11 wireless LAN
interfaces and associates with AP 1 prior to handoff. During the
handoff process, the MN moves to Network 2 by associating with AP 2.
The Mobility Management Protocol (MMP) is SIP Mobility (SIP-M). The
configuration protocol is DHCP and the authentication agent (AA) is a
PANA PAA. The configuration agent (CA) is DHCP Relay Agent. The
Access Router (AR) Router 2 provides IP-in-IP tunneling [RFC1853] to
facilitate routing via the MN's pre-provisioned IP address on Network
2. In turn, the MN also has a corresponding IP-in-IP tunneling
management function to match Router 2. Although, the current testbed
uses IPv4 but it is not limited to it. MIPv6 or SIP mobility over
IPv6 can also be used to provide the same functionality.
Dutta, et al. Expires January 2, 2006 [Page 5]
Internet-Draft MPA Implementation July 2005
3. MPA Assisted Handover Scenario
The communication flow for MPA test environment is described below
and is represented in Figure 2
Step 0: As the MN bootstraps, it associates itself with AP 1 and
obtains the IP address from DHCP Server 1 in Network 1. This IP
address is the old Care of Address (oCoA). Then the MN's SIP user
agent attempts to connect with the CN's SIP user agent. After a
successful SIP connection, voice traffic is initiated and it flows
between from CN to MN. The voice traffic is carried over RTP/UDP
using the RAT (Robust Audio Tool) media agent.
Step 1: 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 level going down"
event [802.21]. In anycase, pre- authentication prepares the MN to
start 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
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 with the PAA
and derives proper security keys which defines the security
association (SA) between the MN and Network 2.
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. Note that the DHCP Proxy gets the IP address from DHCP
Server 2. The new IP address is relayed back to the MN as part of
the pre-authentication process. This IP address is the new Care of
Address (nCoA) and is usable in Network 2. Once the MN gets the
nCoA, it configures this address on a virtual interface and sets up
an IP-in-IP tunnel to Router 2.
The IP-in-IP tunneling between MN and Router 2 can be best be
described in [RFC1853] where the signaling can be cryptographically
protected by using the MN-CA key.
Step 3: The MN performs proactive secure handover of application
traffic. Since the MN is configured with the nCoA and an IP-in-IP
tunnel has been created, the MN can send a SIP Re-invite to CN with
nCoA as its new contact address. In the testbed, all traffic between
Dutta, et al. Expires January 2, 2006 [Page 6]
Internet-Draft MPA Implementation July 2005
CN and MN will be carried over the tunnel once SIP Re-invite
finishes. This includes the RTP/UDP traffic that was initiated in
Step 0.
Steps 4, 5 and 6: The MN performs secure proactive handover pre-
switching, switching and post-switching phase. 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 assigning the nCoA to its physical interface
and updates its local default route information with the default
route information for Network 2 obtained in step 2. The MN then
sends a PANA- Update-Request message to the access router R2. The
purpose of this message is to tear down the IP-in-IP tunnel between
MN and R2. The MN will delete the tunnel end-point local to itself
prior to sending PANA-Update-Request and R2 will delete its tunnel
end-point once it receives the PANA-Update-Request. 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 used in a network.
Dutta, et al. Expires January 2, 2006 [Page 7]
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 Router 2 | |
|<-------------------------------------->| | |
| Step 3 SIP Re-invite | | | |
|<======================================>|<------------------>|
|Voice traffic goes through IP in IP tunnel | |
|<======================================>|<------------------>|
| Step 4 Deletion of the tunnel | | |
|<-------------------------------------->| | |
X Step 5 Association with AP 2| | | |
X<- - - - - - - - - - - - - - >| | | |
X Voice traffic goes to nCoA | | | |
|<----------------------------------------------------------->|
<- - - - ->802.11 frame
<--------->IP packet
<=========>IP in IP tunneling packet
X Voice Packet loss is happened.
Figure 2: MPA Communication Flow in the Test Environment
Dutta, et al. Expires January 2, 2006 [Page 8]
Internet-Draft MPA Implementation July 2005
4. Non-MPA Assisted Handover Scenario
For the comparison purposes, non-MPA assisted handover is also
described in this section. The non-MPA scheme does not provide any
proactive handover mechanism as such but follows standard handover
procedure.
The following are the steps involved in the non-MPA scheme. The
steps involved as part of bootstrap process remains the same as in
step 0 of the MPA assisted case. This scenario also uses the same
localized policy as with the MPA assisted handover to decide when
handover should begin, i.e. signal strength.
Step 1: The MN disassociates with AP 1 and associates with AP 2. On
successful association, it obtains an IP address from DHCP Server 2,
then assigns that address to its network interface. At this point,
no data can flow through R2 for the MN since MN is not yet
authenticated in Network 2.
Step 2: The MN authenticates with the PAA. Since the authentication
period happens as part of the handover, it adds delays in the overall
handover process. Once authentication is successful, forwarding of
packets for the MN will be allowed in Network 2.
Step 3: The MN sends SIP Re-invite with the new IP address obtained
from the DHCP server in the Network 2 which causes the voice traffic
to be forwarded to the MN which is now in Network 2. This binding
update could have potentially taken potentially a longer amount of
time if the MB's target network and the CN are far apart.
Dutta, et al. Expires January 2, 2006 [Page 9]
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 Voice Packet loss is happened.
Figure 3: Communication Flow for Non-MPA Assisted Handover in the
Test Environment
Dutta, et al. Expires January 2, 2006 [Page 10]
Internet-Draft MPA Implementation July 2005
5. Evaluation and Performace Results
In case of MPA assisted handover, there is no packet loss during pre-
authentication before link-layer handover takes place. Delay and
packet loss is observed during the actual link-layer handover. Delay
is also introduced in the network layer during tunnel deletion and IP
address re-assignments. The total observed handover delay is limited
to 170 ms. The traffic rate is approximately one pacekt every 20
msec (though the RTP source does not equally space them). This
amounts to an observable packet loss of 6 RTP packets during the
entire handover period. Optimizing the link-layer delay using a
scheme such as [MACD] will further reduce the packet loss. It is
important to note that the scheme described in [MACD] uses HOSTAP
driver only. It is also noted that the end-host processing
contributes to the handoff delay such as tunnel deletion and signal
processing. Thus further system optimizations can still help reduce
the handoff delay.
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
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.
Dutta, et al. Expires January 2, 2006 [Page 11]
Internet-Draft MPA Implementation July 2005
6. Notes
In the testbed, a 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.
Protocols used in the testbed can always be replaced by the other
existing protocols. For example, Mobility management protocol can be
replaced by Mobile IPv4 or Mobile IPv6. In such case, the Home Agent
(HA) could be in Network 3, similarly the tunnel management protocol
can always be replaced by IKEv2 and IPsec tunnel mode. It is normal
to assume that the performance results will be differ based on the
type of protocols used. The test results also show that link-layer
delay can vary based on the drivers and operating system used. Some
examples of link-layer are Cisco Aironet 350 which takes almost 200-
300 ms under Linux 2.4.x operating system. Orinoco and Dlink using
Hostap drivers takes around 100-160 ms and 400-600 ms respectively
under Linux 2.4.x operating system. Though the Orinoco card takes
about 250 ms under Windows XP using pre-packaged drivers. Hostap
driver with managed mode takes about 30 ms and is comparable to that
obtained by [MACD].
Dutta, et al. Expires January 2, 2006 [Page 12]
Internet-Draft MPA Implementation July 2005
7. References
7.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-08 (work in
progress), May 2005.
7.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 .
[MACD] Shin, S., "Reducing MAC Layer Handoff Latency in IEEE
802.11 Wireless LANs", MOBIWAC Workshop .
Dutta, et al. Expires January 2, 2006 [Page 13]
Internet-Draft MPA Implementation July 2005
Authors' Addresses
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
Victor Fajardo
Toshiba America Research, Inc.
1 Telcordia Drive
Piscataway, NJ 08854
USA
Phone: +1 732 699 5308
Email: ktaniuchi@tari.toshiba.com
Dutta, et al. Expires January 2, 2006 [Page 14]
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
Dutta, et al. Expires January 2, 2006 [Page 15]
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.
Dutta, et al. Expires January 2, 2006 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-22 21:41:28 |