Network Working Group P. Kim Internet-Draft Korea Polytechnic University Intended status: Informational S. Kim Expires: May 7, 2008 J. Jin KT Infra R&D Center November 8, 2007 Proactive Correspondent Registration for Proxy Mobile IPv6 for Route Optimization draft-pskim-proactive-cnregistration-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 May 7, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Kim et al. Expires May 7, 2008 [Page 1] Internet-Draft Proactive Correspondent Registration November 2007 Abstract In this document, a proactive correspondent registration mechanism is proposed for the Proxy Mobile IPv6 (PMIPv6) route optimization between the correspondent node (CN) and the mobile access gateway (MAG) on behalf of the mobile node (MN). Two scenarios are considered according to the type of CN. For the proposed mechanism, the proxy home test and the concurrent care-of test are defined newly with parameters specified by information on candidate MAGs. The proposed correspondent registration mechanism is performed before actual handover for candidate MAGs where the MN can attach newly. Therefore, the proposed mechanism can reduce correspondent registration latency, which can reduce handover latency and thus enhance throughput degradation caused by the bidirectional tunneling via the local mobility anchor (LMA). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Network Configuration . . . . . . . . . . . . . . . . . . . . 4 4. New Authorizing Binding Mechanism . . . . . . . . . . . . . . 6 4.1 Tradeoff between Security and QoS in Mobile IPv6 Handover Procedure . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2 New Return Routability Procedure . . . . . . . . . . . . . . 6 4.3 New Binding Update and Acknowledgement Procedure . . . . . . 9 5. Operation Procedure of Proposed Mechanism . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 11 Kim et al. Expires May 7, 2008 [Page 2] Internet-Draft Proactive Correspondent Registration November 2007 1. Introduction In recent, to support IP mobility for all hosts irrespective of the presence or absence of Mobile IPv6 (MIPv6) functionality in [1], the Proxy Mobile IPv6 (PMIPv6) is being standardized in Internet Engineer Task Force (IETF) [2]-[4]. This protocol to supporting mobility does not require the mobile node (MN) to be involved in the signaling required for mobility management. The mobility access gateway (MAG) in the network performs the signaling and does the mobility management on behalf of the MN. The PMIPv6 can be the L3 handover solution for wireless access networks from now on. For the successful deployment of PMIPv6, the need to communicate efficiently on the move and to minimize the packet loss caused by a handover is becoming increasingly important because handover latency is unacceptable for real-time IP services. The L3 handover latency in PMIPv6 can be caused mainly by the network access authentication latency and the correspondent registration latency for the route optimization, etc. These latencies are inevitable in PMIPv6 because of its basic operations. These latencies could be appreciable for real-time applications and throughput sensitive applications. Among them, in this paper, the correspondent registration latency for the route optimization will be considered and reduced by the proposed mechanism. The PMIPv6 protocol specification [2] doesn't provide any route optimization. Therefore, when the MN moves and attaches to a new link connected to the new MAG in the PMIPv6 domain, the bidirectional tunneling between the CN and the MAG on behalf of the MN via the local mobility agent (LMA) cannot be avoided before the correspondent registration procedure is completed between two entities. This bidirectional tunneling via the LMA may not allow the shortest communication path to be used. That is, data packets between two entities are often routed along paths that are significantly longer than optimal, which can cause end-to-end delay between two entities. In addition, this can also cause congestion at the LMA and its link. Moreover, the impact of any possible failure of the LMA or networks on the path to or from it can increase. Therefore, two entities suffer from significant throughput degradation caused by the bidirectional tunneling for interactive and real-time applications. As shown in [5], TCP bulk-data transfers are likewise affected since long handoff latencies may lead to successive retransmission timeouts and degraded throughput. That is, the correspondent registration procedure using cryptographic functions can help secure the PMIPv6 communication between two entities, but it also introduces significant quality of service (QoS) issues such as delay, congestion, etc. This means there is a tradeoff between security and QoS. Kim et al. Expires May 7, 2008 [Page 3] Internet-Draft Proactive Correspondent Registration November 2007 In order to solve the mentioned problem in the route optimization procedure, the correspondent registration between the CN and the MAG on behalf of the MN should be completed within short time as possible to reduce the correspondent registration latency. However, as shown in [3], the proxy home test and the concurrent proxy care-of test including the proxy binding update (PBU) and the proxy binding acknowledgement (PBA) for the correspondent registration are somewhat time-consuming and computationally burdensome since cryptographic functions for authentication and encryption require considerable computation and CPU processing time, which might introduces the binding latency. In this document, therefore, a proactive correspondent registration mechanism between the CN and the MAG on behalf of the MN is proposed in order to reduce correspondent registration latency for the PMIPv6 route optimization. As shown in [3], two scenarios are considered according to the type of CN. The first scenario is that the CN has the MIPv6 function and recognize PMIPv6 messages. The second scenario is that the CN doesn't have MIPv6 function and are provided mobility support by PMIPv6. The proxy home test and the concurrent care-of test including the PBU and the PBA are defined newly with parameters specified by information on candidate MAGs. The correspondent registration through above messages is performed before actual handover for candidate MAGs where the MN can attach newly. Therefore, the proposed mechanism can reduce correspondent registration latency, which can reduce handover latency and thus enhance throughput degradation caused by the bidirectional tunneling via the LMA. 2. Requirements 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 [RFC2119]. 3. Network Scenarios This document considers the Proxy Mobile IPv6 (PMIPv6) based IEEE 802.16 wireless network which consists of only several mobile access gateways (MAGs) that typically run on corresponding access routers, as shown in Figure 1 and Figure 2. This network configuration might be feasible because there are often access networks that several access routers can cover quite a wide area. For example, in broadband wireless access (BWA) networks such as IEEE 802.16e wireless network [6], several access routers can cover quite a wide area where the MN can move. In this document, it is assumed that all MAGs can share information on other MAGs which exist in same PMIPv6 domain. As shown in Kim et al. Expires May 7, 2008 [Page 4] Internet-Draft Proactive Correspondent Registration November 2007 Table 1, for all MAGs, the information consists of the MAG identifier (MID), the network prefix for proxy care-of address (Proxy-CoA) configuration, the list of candidate MAGs where the MN can attach newly. The MAG can acquire this information from the policy store. As shown in [3], there are two scenarios according to the type of CN. The first scenario is that CNs have MIPv6 function and recognize PMIPv6 messages as shown in Figure 1. The second scenario is that CNs don't have MIPv6 function and are provided mobility support by PMIPv6 as shown in Figure 2. Note that this document borrows all of the terminology from the IETF specification [1]-[4] and the IEEE 802.16e specification [6]. ______ / \ CN (with MIPv6 function) | LMA | \______/ ------- ------- | MAG_B | | MAG_D | ------- ------- / \ / \ / \ / \ / \ / \ ------- ------- ------- | MAG_A |-------| MAG_C | --------- | MAG_E | ------- ------- ------- | MN (which can move to either MAG_B or MAG_C) Figure 1. PMIPv6 Network Scenario (1st Scenario) _______ / \ ------- _______ | LMA_CN |------|MAG_CN | / \ \_______/ ------- | LMA_MN | | \_______/ | CN ------- ------- | MAG_B | | MAG_D | ------- ------- / \ / \ / \ / \ / \ / \ ------- ------- ------- | MAG_A |-------| MAG_C | --------- | MAG_E | ------- ------- ------- | MN (which can move to either MAG_B or MAG_C) Figure 2. PMIPv6 Network Scenario (2nd Scenario) Kim et al. Expires May 7, 2008 [Page 5] Internet-Draft Proactive Correspondent Registration November 2007 Table 1. Information on Access Subnets -------------------------------------------------------------- Subnet NID Network Prefix Candidate Networks -------------------------------------------------------------- MAG_A 0x01 3ffe:2e01:2a:101 MAG_B, MAG_C -------------------------------------------------------------- MAG_B 0x02 3ffe:2e01:2a:102 MAG_A, MAG_C -------------------------------------------------------------- MAG_C 0x03 3ffe:2e01:2a:103 MAG_A, MAG_B, MAG_D -------------------------------------------------------------- MAG_D 0x04 3ffe:2e01:2a:104 MAG_C, MAG_E -------------------------------------------------------------- MAG_E 0x05 3ffe:2e01:2a:105 MAG_E -------------------------------------------------------------- 4. Proactive Correspondent Registration Mechanism 4.1 Tradeoff between Security and QoS in PMIPv6 Handover Procedure The PMIPv6 protocol specification [2] doesn't provide any route optimization. Therefore, when the MN moves and attaches to a new link connected to the new MAG in the PMIPv6 domain, the bidirectional tunneling between the CN and the MAG on behalf of the MN via the LMA cannot be avoided before the correspondent registration procedure is completed between two entities. This bidirectional tunneling via the LMA may not allow the shortest communication path to be used. That is, data packets between two entities are often routed along paths that are significantly longer than optimal, which can cause end-to-end delay between two entities. For example, a VoIP application is much more sensitive to delays than its traditional data counterparts. A few seconds' slowdown is negligible for downloading a file. However, a mere 150 millisecond delay can turn a crisp VoIP call into a garbled, unintelligent mess. In addition, this can also cause congestion at the LMA and its link. Moreover, the impact of any possible failure of the LMA or networks on the path to or from it can increase. Therefore, two entities suffer from significant throughput degradation caused by the bidirectional tunneling for interactive and real-time applications. As shown in [5], TCP bulk-data transfers are likewise affected since long handoff latencies may lead to successive retransmission timeouts and degraded throughput. That is, the binding procedure using cryptographic functions can help secure the PMIPv6 communication between two entities, but it also introduces significant QoS issues such as delay, congestion, etc. This means there is a tradeoff between security and QoS. In order to solve the mentioned problem in the route optimization procedure, the correspondent registration between the CN and the MAG Kim et al. Expires May 7, 2008 [Page 6] Internet-Draft Proactive Correspondent Registration November 2007 on behalf of the MN should be also completed within short time as possible to reduce the correspondent registration latency. However, as shown in [3], the proxy home test and the concurrent proxy care-of test including the early PBU and the PBA for the correspondent registration are somewhat time-consuming and computationally burdensome since cryptographic functions for authentication and encryption require considerable computation and CPU processing time, which might introduces the binding latency. 4.2 New Proxy Home Test and Concurrent Care-of Test Procedures In this section, the proxy home test and the concurrent proxy care-of test for the correspondent registration are newly defined with parameters specified by information on candidate MAGs. For simplicity, hereafter, the MAG on behalf of the MN and the MAG on behalf of the CN are called the MAG_MN and the MAG_CN, respectively. The LMA for the MN and the LMA for the CN are called the LMA_MN and the LMA_CN. 4.3 Processing Cryptographic Functions for New Return Routability Procedure (1) New Proxy Home Test Procedure As soon as the MAG_MN makes decision on which the CN or the MAG_CN needs the route optimization, the MAG_MN initiates the proxy home test procedure. The CN or the MAG_CN verifies the reachability of MN's home address (MN-HoA) via this procedure. For the new proxy home test, two messages are defined with parameters specified by information on candidate MAGs where the MN can attach newly. - Proxy Home Test Init (PHoTI) The MAG_MN sends the PHoTI message to acquire home keygen tokens for candidate MAGs. In this message, the field of parameters can be defined by MIDs, proxy care-of addresses (Proxy-CoAs), home init cookies, which are generated by the MAG_MN for candidate MAGs. In case of the 1st scenario of Figure 1, the PHoTI message is sent to the CN via the shared tunnel between the MAG_MN and the LMA_MN. On the other hand, in case of the 2nd scenario of Figure 2, the PHoTI message is sent to the MAG_CN via the shared tunnel between the MAG_MN and the LMA_MN. Then, this PHoTI message is forwarded to proxy home address of the CN by the LMA_MN. At the LMA_CN, this message is tunnelled into the shared tunnel between the LMA_CN and the MAG_CN. Then, the MAG_CN intercepts the PHoTI message and extracts MN-HoA and Proxy-CoAs for candidate MAGs from it. - Proxy Home Test (PHoT) Kim et al. Expires May 7, 2008 [Page 7] Internet-Draft Proactive Correspondent Registration November 2007 The PHoT message is sent in response to a PHoTI message. In this message, the field of parameters can be defined by MIDs, home keygen tokens, home init cookies, home nonce indices, which are generated by the CN or the MAG_CN for candidate MAGs. Home init cookies from the MAG_MN are returned in the PHoT message, to ensure that the message comes from a node on the route between the LMA_MN and the CN or between the LMA_MN and the MAG_CN. Home nonce indices are delivered to the MAG_MN to later allow the CN or the MAG_CN to efficiently find the nonce value that it used in creating home keygen tokens. Home keygen tokens for corresponding candidate MAGs are computed by processing cryptographic functions in [6]. In case of the 1st scenario of Figure 1, the CN sends the PHoT message back to the MAG_MN via the shared tunnel between the MAG_MN and the LMA_MN. On the other hand, in case of the 2nd scenario of Figure 2, the MAG_CN sends the PHoT message back to the MAG_MN and adds Proxy-CoA of the CN into PHoT message. The MAG_CN creates a binding cache entry for this MN. This PHoT is sent via the shared tunnel between MAG_CN and the LMA_CN. Then, the LMA_CN forwards this message to the MN-CoA which tunnels it to the MAG_MN. The MAG_MN receives PHoT message, it extracts the Proxy-CoA of CN and adds this information to the binding cache entry for CN. (2) New Concurrent Proxy Care-of Test Procedure The CN or the MAG_CN also needs to prove the reachability of the Proxy-CoA, which is called the proxy care-of test. This proxy care-of test is piggybacked on a Proxy Binding Update (PBU) which is sent by the MAG_MN to register with the CN or the MAG_CN. That is, the proxy care-of test is done concurrently with the early PBU exchange, so it is called the concurrent proxy care-of test. - Proxy Care-of Test Init (PCoTI) The MAG_MN sends the early PBU which contains the PCoTI option to acquire the care-of keygen token for candidate MAGs. In the PCoTI option, the field of parameters can be defined by MIDs, Proxy-CoAs, care-of init cookies, which are generated by the MAG_MN for candidate MAGs. In case of the 1st scenario of Figure 1, it is sent directly to the CN. On the other hand, in case of the 2nd scenario in Figure 2, it is sent directly to the Proxy-CoA of CN, i.e. to the MAG_CN. The field of parameters in the early PBU can be defined as [1] for candidate MAGs. - Proxy Care-of Test (PCoT) The Proxy Binding Acknowledgement (PBA) message with PCoT option is Kim et al. Expires May 7, 2008 [Page 8] Internet-Draft Proactive Correspondent Registration November 2007 sent in response to the early PBU message with PCoTI option. In the PCoT option, the field of parameters can be defined by MIDs, care-of init cookies, care-of keygen tokens, care-of nonce indices for candidate MAGs, which are generated by the CN or the MAG_CN. Care-of nonce indices are provided to identify the nonce used for care-of keygen tokens. Home and care-of nonce indices may be the same, or different, in PHoT message and PCoT option. Care-of keygen tokens for corresponding candidate MAGs are computed by processing cryptographic functions in [6]. This message is sent directly to the MAG_MN for both scenarios. In the PBA message, the field of parameters can be defined as [1] for candidate MAGs. 5. Operation Procedure and Advantages over Existing Mechanism To describe the operation procedure of the proposed proactive correspondent registration mechanism, it will be assumed that the MN moves and attaches to the 'MAG_C' from the 'MAG_A' and then moves and attaches to the 'MAG_E'. The existing mechanism was explained in [2][3]. For the proposed proactive correspondent registration mechanism, when the MN moves and attaches to 'MAG_A', the 'MAG_A' on behalf of the MN performs the newly defined correspondent registration for candidate MAGs 'MAG_C' and 'MAG_E' at appropriate time using MAG information cached beforehand, such as the MID, the network prefix for Proxy-CoA configuration, the list of candidate MAGs where the MN can attach newly as shown in Table 1. In real-time communication, when the MAG_A performs actual PMIPv6 handover to 'MAG_C', the 'trigger' may arrive from specific L2 events that might determine the need for handover. In this document, this trigger itself is not specified in detail. After the network access authentication, the direct communication between CN and 'MAG_C' or between MAG_CN and 'MAG_C' can be started without the correspondent registration on 'MAG_C'. Therefore, the correspondent registration latency between two entities can be reduced because somewhat time-consuming and computationally burdensome tasks are performed beforehand. That is, the proposed proactive correspondent registration mechanism can reduce handover latency and thus enhance throughput degradation caused by the bidirectional tunneling. On the other hand, in the existing mechanism [2][3], these time-consuming and computationally burdensome tasks for correspondent registration are performed during the PMIPv6 handover procedure. In addition, the proposed mechanism can also avoid congestion at the LMA and its link during PMIPv6 handover. Moreover, the impact of any possible failure of the LMA or networks on the path to or from it can decrease. Kim et al. Expires May 7, 2008 [Page 9] Internet-Draft Proactive Correspondent Registration November 2007 6. Security Considerations This document has no direct impact on the security of the Internet. 7. IANA Considerations This document requests no action by the IANA. 8. References 8.1 Normative [1] Johnson, D.B., Perkins, C.E., Arkko, J., "Mobility Support in IPv6," IETF RFC 3775, June 2004. [2] Gundavelli, S., "Proxy Mobile IPv6", (work in progress) , June 2007. [3] Qin, A., "PMIPv6 Route Optimization Protocol", , February 2007. [4] Jeong, S. et al, "Route Optimization Support for Proxy Mobile IPv6 (PMIPv6)", , July 2007. [5] Vogt, C. and M. Doll, "Efficient End-to-End Mobility Support in IPv6", In Proc. of the IEEE Wireless Communications and Networking Conference, April 2006. [6] IEEE802.16e, "Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands,", ANSI/IEEE Std 802.16e/D12, 2005. 8.2 Informative None Authors' Addresses Pyungsoo Kim Department of Electronics Engineering, Korea Polytechnic University, 2121 Jungwang-Dong, Shiheung City, Gyeonggi-Do 429-793 KOREA Phone: +82 31 8041 0489 EMail: pskim@kpu.ac.kr Sang-Eon Kim Infra Lab., KT 17 Woomyeon-dong, Seocho-gu Kim et al. Expires May 7, 2008 [Page 10] Internet-Draft Proactive Correspondent Registration November 2007 Seoul, 137-792 KOREA Phone: +82 2 526 6117 Email: sekim@kt.co.kr Jong-Sam Jin Infra Lab., KT 17 Woomyeon-dong, Seocho-gu Seoul, 137-792 KOREA Phone: +82 2 526 6117 Email: jongsam@kt.co.kr Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Kim et al. Expires May 7, 2008 [Page 11] Internet-Draft Proactive Correspondent Registration November 2007 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Kim et al. Expires May 7, 2008 [Page 12]