Mobility for IPv6 Working Group J.T.Park Internet Draft S.M.Chun Intended status: Standards Track Expires: May 08, 2011 Kyungpook National University November 23, 2010 Extension of Hierarchical Mobile IPv6 (E-HMIPv6) for Multiple Tunnel Support draft-park-mext-multipletunnel-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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. Park, et al Expires May 23,2011 [Page 1] Internet-Draft Extension of Hierarchical Mobile (E-HMIPv6) for Multiple Tunnel Support November 2010 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 23, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document describes an extension to the Hierarchical Mobile IPv6 for multiple tunnel support by adopting an IP mobility management scheme in which multiple wireless network interfaces are assigned active IPv6 care-of addresses and are used simultaneously to enable fast handover. The mechanism of this document not only enhances the handover latency, but also drastically reduces the packet loss and improves throughput. Park, et al Expires May 23,2011 [Page 2] Internet-Draft Extension of Hierarchical Mobile (E-HMIPv6) for Multiple Tunnel Support November 2010 Table of Contents 1. Introduction ................................................ 4 2. Conventions & Terminology ................................... 4 2.1. Conventions ............................................ 4 2.2. Terminology ............................................ 4 3. Overview and Limitations of HMIPv6 .......................... 6 4. E-HMIPv6 overview & operation ............................... 7 4.1. Structure of E-MAP ..................................... 9 4.2. Extension of Binding Update Message .................... 11 4.3. Signal Flow Diagram for E-HMIPv6 Operation ............. 12 5. Security Considerations ..................................... 14 6. IANA Considerations ......................................... 14 7. Conclusions ................................................. 14 8. References .................................................. 14 8.1. Normative References ................................... 14 8.2. Informative References ................................. 15 9. Acknowledgements ............................................ 15 Park, et al Expires May 23,2011 [Page 3] Internet-Draft Extension of Hierarchical Mobile (E-HMIPv6) for Multiple Tunnel Support November 2010 1. Introduction Hierarchical Mobile IPv6 (HMIPv6) allows the mobile nodes (MNs) to move within the local Internet topology while maintaining fast connections between MNs and correspondent nodes. This document introduces an extension to HMIPv6 for multiple tunnel support between an MN and the mobility anchor point (MAP) of HMIPv6. The aim of introducing the multiple tunnel support in HMIPv6 is to enhance the performance of the handover, and to help MNs achieve fast seamless mobility. The objective of this document is to develop an IP mobility management scheme in which either negligible or no performance degradation in both handover latency and packet loss occurs when the MN moves between different wireless cells. We have extended the Hierarchical Mobile IPv6 (HMIPv6), named E-HMIPv6, such that while the MN is moving, parallel distribution packet tunnels between an access router and the MN are dynamically constructed using multiple wireless network interfaces. More specifically, the HMIPv6 MAP has been extended to instrument parallelism in the packet transmission through multiple tunnels with a modification in binding and address management. 2. Conventions & Terminology 2.1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC-2119]. 2.2. Terminology All the mobility related terms used in this document are to be interpreted as described in the specifications [RFC-3775], [RFC 5380].In addition this document introduces the following terms. Mobile node (MN) MN is that they are equipped with multiple wireless network interfaces which MAY include mobile network interfaces such as Wi-Fi, 3G etc. Extended Mobility Anchor Point (E-MAP) Park, et al Expires May 23,2011 [Page 4] Internet-Draft Extension of Hierarchical Mobile (E-HMIPv6) for Multiple Tunnel Support November 2010 An E-MAP is a router located in a network visited by the MN. The E-MAP is used by the MN as a local home agent (HA). One or more MAPs can exist within a visited network. the E-MAP manages the traffic and routing table for the MN to support the multiple tunnels. The structure and function of E-HMIPv6 MAP is described in Section 4.1. Previous Access Router (PAR) The PAR is the MN's default router. The PAR aggregates the outbound traffic of MNs. It is the MN's default router prior to its handover. Next Access Router (NAR) The NAR is the MN's default router. The NAR aggregates the outbound traffic of MNs. It is the MN's default router subsequent to its handover. Regional Care-of Address (RCoA) An RCoA is an address allocated by the MAP to the MN. On-link Care-of Address (LCoA) The LCoA is the on-link CoA configured on An MN's interface based on the prefix advertised by its default router. Local Binding Update The MN sends a local binding update to the E-MAP in order to establish a binding between the RCoA and LCoA. On-link Care-of Address interface number (LCoA i) The LCoA is the on-link CoA configured on An MN's interface based on the prefix advertised by its default router. In [RFC 3775], this is simply referred to as the care-of address. The letter 'i' is depicted as an integer number of network interface. Local Unbinding Update (LUU) LUU message is used by the MN to unbind the LCoA {number} of the MN when An MN needs to delete a binding RCoA and LCoA {number} in binding cache table entry at the E-MAP. Park, et al Expires May 23,2011 [Page 5] Internet-Draft Extension of Hierarchical Mobile (E-HMIPv6) for Multiple Tunnel Support November 2010 3. Overview and Limitations of HMIPv6 Hierarchical Mobile IPv6 [RFC 5380] is a localized mobility management protocol to reduce the signaling load between the MN and its correspondent node or its home agent due to user mobility. The mobility management inside the local domain is handled by a mobility anchor point. The mobility anchor point basically acts as a local home agent for the local mobility domain. As the MN enters into a new local mobility domain, called mobility anchor point domain, it registers two IP addresses in the binding cache entry: on-link care- of address and regional care-of address. An on-link care-of address is a temporary IP address obtained from the next access router in the new mobility anchor point domain. It is same as that of care-of address for MIPv6. A regional care-of address is another temporary IP address scheme provided by the new mobility anchor point. A regional care-of address is used by the mobility anchor point to inform a home agent and correspondent node of the MN's current location. For the MN in its domain, the mobility anchor point maintains a mapping table called the binding cache entry to bind a regional care-of address with an on-link care-of address. As the MN performs a handover between two access routers within the same mobility anchor point domain, only the mobility anchor point needs to be informed. An on-link care-of address can change but a regional care-of address does not change. The packets sent from the home agent or correspondent node are intercepted by the mobility anchor point and routed to the new on-link care-of address of the MN. Therefore, the MN does not have to inform either home agent or correspondent node of its new location, i.e., new on-link care-of address. These operations of the mobility anchor point reduce direct binding update signaling traffic between the MN and home agent/correspondent node. This results in a reduction of handover latency and packet loss. However, there could be significant handover latency and packet loss as the MN moves quickly between different access points. This is because it MAY still have large delay and packet loss in getting new on-link care-of address during handover. These large delay and packet loss MAY not be allowable to delay-sensitive real-time IP services, such as mobile VoIP and mobile IPTV. The design of the Hierarchical Mobile IPv6 does not take the "ping-pong" effect into consideration, which further degrades the performance while an MN moves back and forth around the handover boundary. Park, et al Expires May 23,2011 [Page 6] Internet-Draft Extension of Hierarchical Mobile (E-HMIPv6) for Multiple Tunnel Support November 2010 4. E-HMIPv6 overview & operation Extended Hierarchical Mobile IPv6 (E-HMIPv6) scheme introduces a new function; the extended MAP and minor extensions to the MN operation. The correspondent node and home agent operations will not be affected. Just like Mobile IPv6, this solution is independent of the underlying access technology, allowing mobility within or between different types of access networks. The hierarchical Mobile IPv6 has been extended to support multiple tunnels. Figure 1 illustrates the architecture of E-HMIPv6. The extension of HMIPv6 mainly comes with three parts: Simultaneous binding, Extension of MAP, i.e., E-MAP and Binding Update Protocol Extension. The details of the simultaneous binding and structure of E-MAP are described in Section 4.1. Binding Update protocol extension is described in subsection 4.2. The MN is assumed to be equipped with multiple wireless network interfaces, i.e., 3G, Wi-Fi, WiBro network interface, etc. An MN entering an E-MAP domain will receive Router Advertisement (RA) message containing information about an E-MAP. The MN can bind its current address (LCoA) with an address on the E-MAP's subnet (RCoA). Acting as a local HA, the E-MAP will receive all packets on behalf of the MN it is serving, and will encapsulate and forward them directly to the MN's current address. Each network interface of an MN is assigned address by access router. If a network interface of an MN changes its current address within an E-MAP domain (LCoA Number), it only needs to register the new address to the E-MAP. The structure of the E-MAP is described in subsection 4.2. In Figure 1, an MN is connected through LCoA1 to a previous access router (PAR) through interface 1 (IF1). The MN constructs IP tunnel with end-points of LCoA1 and RCoA to the E-MAP to exchange packets with HA/CN. Interface 1 and interface 2 (IF2) represent two wireless network interfaces which are chosen to be activated for data transmission from multiple wireless network interfaces. It is assumed that the MN selects two wireless network interfaces from multiple wireless network interfaces which have the best radio signal strengths. As the MN moves away from PAR and enters into the overlapping area between domains of the PAR and new access router (NAR), the radio signal strength from the PAR decreases and it starts to get LCoA2 and connects to NAR by activating the network interface 2 (IF2). As the MN successfully connects to NAR, it requests to the E-MAP for binding the LCoA2 with RCoA. In this case, the E-MAP simultaneously binds both LCoA1 and LCoA2 with RCoA. In simultaneous binding, the Park, et al Expires May 23,2011 [Page 7] Internet-Draft Extension of Hierarchical Mobile (E-HMIPv6) for Multiple Tunnel Support November 2010 packets from HA/CN can be transmitted through bi-directional tunnels. In packet transmission, the packets can be transmitted in either duplicate or alternate mode. By extending MAP of HMIPv6 and utilizing simultaneous binding, the packets from the MN can be sent to both PAR and NAR simultaneously and received in a similar way for a certain period of time. These can drastically and/or completely eliminate the handover delay and packet loss due to link-layer delay effect, duplicate address detection (DAD) for getting new LCoA, and others such as ping-pong effect. When the MN moves away from the PAR coverage, the MN sends the unbinding update message to E-MAP. Unbinding update message is described in more detail in Subsection 4.2. In the MN, the packets from multiple simultaneous tunnels can be directed to the home IP address (HoA) using IPv6 home address option. In this way, the fast IP handover in E-HMIPv6 can be achieved without performance degradation in the handover delay, packet loss and throughput. It SHOULD be noted that during handover operation, there is no service disruption since the MN is always connected to at least one access router during handover operation. Park, et al Expires May 23,2011 [Page 8] Internet-Draft Extension of Hierarchical Mobile (E-HMIPv6) for Multiple Tunnel Support November 2010 +----+ Home Agent (HA) | HA | Binding Cache Entry (HoA, RCoA) +----+ +----+ | | CN | Correspondent Node (CN) | +----+ (HoA, RCoA) | | +-------+-----+ | | +-------+ Extended Binding Cache Table Entry | E-MAP | (HoA, RCoA, LCoA1, LCoA2) +-------+ || || Bidirectional || || Tunnel || || || || +-----+ +-----+ Binding Cache Entry Binding Cache | PAR | | NAR | (HoA, LCoA2) Entry (HoA, LCoA1) +-----+ +-----+ || || || || || || +-+-+-+-+-+-+-+-+-+-+ | +---+ +---+ | Mobile Node (MN) | |IF1| |IF2| | (HoA, LCoA1, LCoA2) | +---+ +---+ | +-+-+-+-+-+-+-+-+-+-+ Figure 1 : Handover Scenario for E-HMIPv6 4.1. Structure of E-MAP In this subsection, the structure of the E-MAP, i.e., the extension of the mobility anchor point in HMIPv6, is described. The MAP in [RFC 5280] of HMIPv6 acts as an HA; it intercepts all packets addressed to registered MNs and tunnels them to the corresponding LCoA, which is stored in its binding cache entry. Figure 2 shows the extended binding cache table entry of the E-MAP. Entry components in binding cache table are created by local binding update message sent by an MN. The binding cache table entry components are composed of the MN's home address, the MN's regional care-of address, the MN's on-link care-of address and lifetime. Park, et al Expires May 23,2011 [Page 9] Internet-Draft Extension of Hierarchical Mobile (E-HMIPv6) for Multiple Tunnel Support November 2010 An E-MAP has no knowledge of the MN's home address (HoA). The MN will send a local binding update to the E-MAP. The aim of this binding update is to bind the RCoA (contained in the binding update as a home address (HoA)) to the MN's LCoA. If successful, the E-MAP returns a binding acknowledgement to the MN, indicating a successful registration. The E-MAP SHOULD be able to accept packets tunneled from the MN with the MN being the tunnel entry point and the E-MAP being the tunnel exit point. In order to support multiple tunnels, the binding cache table entry of HMIPv6 is extended. More specifically, the LCoA {number} in extended binding cache table entry has been newly defined to support registration of multiple care-of addresses. LCoA1 is an on-link address configured by one interface of multiple interfaces on the MN. The MN can acquire its care-of address through conventional IPv6 mechanisms, such as stateless or stateful auto-configuration [RFC 3775]. The LCoA {number} field can be renewed through local binding update message or local unbinding update message. If there exist an on-link care-of address1 and on-link care-of address2 on the extended binding cache table entry, the E-MAP encapsulates the packets from home agent/correspondent node with the on-link care-of address1 or on-link care-of address2 and transmits them using two bi-directional tunnels. The lifetime defines the entry duration. Once the binding lifetime expires, the binding entry is deleted. Park, et al Expires May 23,2011 [Page 10] Internet-Draft Extension of Hierarchical Mobile (E-HMIPv6) for Multiple Tunnel Support November 2010 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |MN's Home Address|MN's Regional CoA|on-link CoA| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HoA | RCoA | LCoA1 | TTL1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HoA | RCoA | LCoA2 | TTL2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 : Extended binding cache table entry 4.2. Extension of Binding Update Message In order to register and de-register multiple wireless network interfaces of an MN to the E-MAP, the local binding update message of HMIPv6 is extended by defining new flags. Figure 3 shows the extended local binding update message format of HMIPv6, the format of which is specified in [RFC 5380]. The local binding update message is used by an MN to notify other node (HA/CN/MAP) of a new care-of address for itself within a MAP domain. In [RFC 5380] [RFC 3775], the single flag bits in local binding update message format are defined as A, H, L, K and M. The registration location is different from a single flag bit set. The extension is comprised of two messages: Local Binding Update and Local Unbinding Update. The "U" flag is used to distinguish the Local Binding Update from the Local Unbinding Update. The "O" flag is used to distinguish the two wireless interfaces: interface1 and interface2. The functions of all the other flags are the same as described in [RFC 5380]. The "O" flag and "U" flag set indicate the E-MAP registration for interface2's on-link care-of address2 and de-registration for interface1's on-line care-of address1, respectively. The MN will send a local binding update message to the E-MAP with setting of the M and A flags. If the flags M and A are set, it indicates that the binding update request has been sent to network interface1. If the flags M, A and O are set, it indicates that the binding update request has been sent to interface2. Park, et al Expires May 23,2011 [Page 11] Internet-Draft Extension of Hierarchical Mobile (E-HMIPv6) for Multiple Tunnel Support November 2010 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|O|U| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobility Option | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 : Extension of local BU message 4.3. Signal Flow Diagram for E-HMIPv6 Operation Figure 5 shows the exchanges of signaling for the local mobility management of E-HMIPv6. The detailed description of the signaling operation is below. It is assumed that the MN have equipped with extensions of Hierarchical Mobile IPv6 protocol [RFC 5380]. Assume that MN had already acquired an RCoA and LCoA1 by the E-MAP and PAR, and an MN is receiving the packet through the PAR. Each wireless interface can be assigned with LCoA which is given by an access router. Here, the LCoA1 is the care-of address assigned by PAR in the IF1, and the LCoA2 is the on-link CoA assigned by NAR in the IF2. The detailed signaling operation is as follows: - A MN is exchanging packets with HA/CN using the interface one through tunnels which are constructed between the MN and the E-MAP with assigned end-points addresses of RCoA and LCoA1. - If the MN moves to an overlapping of PAR and NAR domains, the IF2 will be activated. The IF2 receives and identifies the RA message from NAR. If the prefix information is different from the prefix information having the wireless network interface 1, the wireless network interface 2 configures the LCoA2. - In order to perform neighbor unreachability detection (NUD) for the newly generated LCoA2, the MN sends the neighbor solicitation message (NS) to the NAR. In response to this message, the NAR performs DAD process for LCoA2, and sends the DAD result message to the MN using neighbor acknowledgement message (NA). Afterwards, the MN sends the LBU message by setting A, M, O flag to the E-MAP. The E-MAP updates the extended binding cache Table entry. The MN receives the LBAck from the E-MAP through the NAR. In this case, the MN does not need to send BU message to its HA and CN. Park, et al Expires May 23,2011 [Page 12] Internet-Draft Extension of Hierarchical Mobile (E-HMIPv6) for Multiple Tunnel Support November 2010 - There are two tunnels created: one between E-MAP and PAR, and the other between E-MAP and NAR. The E-MAP sends the packet simultaneously through the two tunnels using either bi-casting or alternate packet distribution mode. - As the MN moves far away from the PAR, it sends Local Unbinding Update (LUU) to the E-MAP to remove the tunnel between the E-MAP and PAR. As soon as the E-MAP receives the LUU message, it deletes the LCoA1 from the extended binding cache Table entry, and sends back the local unbinding acknowledge to the MN. MN NAR PAR E-MAP CN/HA Interface1 (IF1) Interface 2 (IF2) | | | | | | Data Exchange | | | | |<-------------------------------------------------- | | | | | Router Solicitation (RS) | | | | | |--------------------------------------->| | | | | | Router Advertisement (RA) | | | | | |<---------------------------------------| | | | | | Neighbor Solicitation (NS) | | | | | |--------------------------------------->| | | | | | Neighbor Acknowledgement (NA) | | | | | |<---------------------------------------| | | | | | Local Binding Update (LBU) | | | | | |---------------------------------------------------------->| | | | Local Binding Acknowledgement (LBack) | | | | | |<----------------------------------------------------------| | | | Data Exchange | | | | |<------------------------------------------| | | | | | Data Exchange | | | | | |<------------------------------------------------| | | | | Local Unbinding Update (LUU) | | | | |--------------------------------------------------->| | | | | Local Unbinding Acknowledgement (LUAck)| | | | |<---------------------------------------------------| | | | | Data Exchange | | | | | |<--------------------------------------------------------->|<----->| | | | | | | Figure 4 : Signaling Flow Diagram Park, et al Expires May 23,2011 [Page 13] Internet-Draft Extension of Hierarchical Mobile (E-HMIPv6) for Multiple Tunnel Support November 2010 5. Security Considerations This specification allows An MN to establish multiple tunnels with the home agent by assigning active care-of addresses with multiple wireless network interfaces. This essentially allows the MNs home address to be reachable through its active interfaces. This new capability has no impact on protocol security; however, it certainly improves the MN reachability. 6. IANA Considerations Section 4.3 introduces two flags "U" and "O" to the binding update specified in [RFC 5380]. 7. Conclusions This document proposes a new fast IP mobility management scheme in which bi-casting multiple tunnels between mobile node and E-MAP of HMIPv6 using multiple wireless network interfaces are dynamically constructed during handover operation. The proposed scheme can reduce handover latency and packet loss. 8. References 8.1. Normative References [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC 5380] Soliman, H., Castelluccia. C., El Malki, K., and Bellier, L. "Hierarchical Mobile IPv6 Mobility Management", RFC 5380, October 2008. [RFC 4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861 September 2007. Park, et al Expires May 23,2011 [Page 14] Internet-Draft Extension of Hierarchical Mobile (E-HMIPv6) for Multiple Tunnel Support November 2010 8.2. Informative References [RFC 4068] R. Koodli, "Fast Handovers for Mobile IPv6," RFC 4068, July 2005. [1] Lee, J. Y., Kim, B. C., Park, H. S., and Shin, K. C. Internet Draft-Fast Handovers for Multiple Interfaces Mobile IPv6 (MFMIPv6). IETF MONAMI6 WG, July 2007. [2] Jung. Y., Soliman, H., Koh, S. J., and Lee, J. Y. 2005. "Fast Handover for Hierarchical MIPv6", IETF Internet Draft, April 2005. 9. Acknowledgements This document was prepared using 2-Word-v2.0.template.dot. Park, et al Expires May 23,2011 [Page 15] Internet-Draft Extension of Hierarchical Mobile (E-HMIPv6) for Multiple Tunnel Support November 2010 Authors' Addresses Jong-Tae Park Kyungpook National University School of Electrical Engineering and Computer Science Daegu, 702-701, Korea EMail: jtpark@ee.knu.ac.kr Seung-Man Chun Kyungpook National University School of Electrical Engineering and Computer Science Daegu, 702-701, Korea EMail: smchun@ee.knu.ac.kr Park, et al Expires May 23,2011 [Page 16]