idnits 2.17.1 draft-korhonen-netext-redirect-ps-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 9, 2009) is 5545 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-ietf-dime-pmip6-00 == Outdated reference: A later version (-01) exists of draft-korhonen-netlmm-lma-discovery-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Korhonen 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Informational February 9, 2009 5 Expires: August 13, 2009 7 Proxy Mobile IPv6 Mobility Session Redirection Problem Statement 8 draft-korhonen-netext-redirect-ps-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 13, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 47 This document discusses a Proxy Mobile IPv6 mobility session 48 redirection functionality at the Proxy Mobile IPv6 base protocol 49 level. The redirection functionality would allow a Local Mobility 50 Anchor to redirect the Mobile Access Gateway during the Proxy Binding 51 Update and Acknowledgement exchange to an alternative Local Mobility 52 Anchor. The benefit of redirection at the protocol level is that it 53 removes the dependence on having such functionality provided by the 54 Authentication, Authorization and, Accounting elements or the Domain 55 Name System in a Proxy Mobile IPv6 Domain. Furthermore, doing the 56 redirection at the base protocol level reduces the amount of 57 signaling, unnecessary costly setup of mobility sessions and 58 unnecessary costly interactions with backend systems. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Redirection Approaches . . . . . . . . . . . . . . . . . . . . 4 65 4. Redirection Scenarios . . . . . . . . . . . . . . . . . . . . . 4 66 4.1. Redirection During the Initial Attach . . . . . . . . . . . 4 67 4.2. Redirection of an Active IP Mobility Session . . . . . . . 5 68 5. Proxy Mobile IPv6 Domain Considerations . . . . . . . . . . . . 5 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 1. Introduction 78 This document discusses a mobility session redirection functionality 79 for the Proxy Mobile IPv6 (PMIPv6) protocol. The redirection 80 functionality would allow a Local Mobility Anchor (LMA) to redirect 81 the Mobile Access Gateway (MAG) during the Proxy Binding Update (PBU) 82 and the Proxy Binding Acknowledgement (PBA) exchange to an 83 alternative LMA. The benefit of redirection at the protocol level is 84 that it removes the dependence on having such functionality provided 85 by the Authentication, Authorization and, Accounting (AAA) elements 86 or the Domain Name System (DNS) in a PMIPv6 Domain. Furthermore, 87 doing the redirection at the base protocol level reduces the amount 88 of signaling, unnecessary costly setup of mobility sessions and 89 unnecessary costly interactions with backend systems. 91 The redirection during the initial attach and the exchange of PBU/PBA 92 messages seems to be the most natural place for redirection, because 93 the mobility session setup is still in progress. Therefore, the 94 redirection during the initial attach is also the main problem 95 interest area of this document. The redirection of an active 96 mobility session can be seen as a handover between LMAs. 97 Accomplishing a handover between LMAs and maintaining the active 98 mobility session, which may even include moving the Home Network 99 Prefix (HNP) to a new topological location in the network, can be 100 really challenging. Therefore, the redirection of an active mobility 101 session is the secondary problem interest area of this document. 103 The following sections evaluate existing solutions for redirection 104 that may be used with PMIPv6. This document also briefly describes 105 few use cases where redirection would be useful, and finally 106 describes deployment consideration within a PMIPv6 Domain when 107 redirection is used. 109 2. Terminology 111 In addition to the terminology defined in RFC 5213 [RFC5213], the 112 following terminology is also used: 114 rfLMA 116 The LMA which receives the PBU from a MAG and decides to redirect 117 the IP mobility session, and forwards the PBU to the target LMA 118 (r2LMA). 120 r2LMA 122 The LMA to which a MAG was redirected to. During the redirection, 123 the PBA is possibly sent to the MAG from this LMA. 125 3. Redirection Approaches 127 The dependency on DNS for redirection may not be deterministic enough 128 from the PMIPv6 Domain point of view, for example in cases where MAGs 129 cache DNS responses. DNS based approach is also applicable only 130 during the initial attach. Furthermore, globally deployed DNS has 131 unpredictable latencies on dynamic DNS updates that again make DNS 132 suboptimal tool for redirection. Using AAA for redirection is also 133 another possibility. However, relying on the AAA infrastructure 134 would mean, in most cases, unnecessary updates to a remote Policy 135 Store and subsequent Policy Profile downloads before and after 136 redirection. Compared to DNS based approach, the AAA infrastructure 137 would allow initiating the redirection of an active mobility session. 139 Another redirection approach would be utilizing Home Agent Switch 140 [RFC5142] type of solution, which appears to be suitable especially 141 initiating the redirection of an active mobility session. The 142 drawback of this approach during the initial attach is increased 143 signaling. One additional roundtrip is required to inform the MAG of 144 a LMA redirection, one roundtrip to remove the existing binding on 145 the old rfLMA, and one roundtrip to establish a new mobility session 146 at the target r2LMA. Also, there is no guarantee that the mobility 147 session continuity can be preserved. Furthermore, this approach 148 would mean unnecessary creation of a "temporary" state in the rfLMA 149 and unnecessary interactions with the backend systems. 151 Based on the above observations, a more efficient redirection 152 mechanism can be justified that would be part of the PMIPv6 base 153 protocol and independent of external supporting infrastructures. The 154 details of how a LMA determines the redirection and possibly the 155 communication between LMAs in a PMIP6 Domain to maintain a list of 156 available LMAs is outside the scope of this document. 158 4. Redirection Scenarios 160 4.1. Redirection During the Initial Attach 162 This is the basic use case for the redirection functionality. A MAG 163 sends an initial PBU for establishing a mobility session to a known 164 LMA address within the PMIPv6 Domain. The MAG may find out the "well 165 known" IP address or addresses of the LMA through various PMIPv6 166 bootstrapping mechanisms [I-D.ietf-dime-pmip6] 167 [I-D.korhonen-netlmm-lma-discovery]. The MAG receives the PBA from 168 the r2LMA and will send subsequent PBUs and user traffic to the 169 r2LMA. The MAG updates its Binding Cache and Policy Profile to 170 reflect the r2LMA to which PBUs associated with the MN need to be 171 sent. 173 4.2. Redirection of an Active IP Mobility Session 175 This use case would allow a redirection of an active mobility 176 session. The MAG would be redirected to a new r2LMA during a normal 177 Binding Lifetime Extension PBU/PBA exchange. Reasons for doing so 178 is, for example, moving Mobile Nodes (MS) anchored to a certain LMA 179 to another in order to allow graceful shutdown of the LMA for 180 maintenance purposes. Another reason could again be load balancing 181 in abrupt change of load condition on the LMA, and therefore redirect 182 some of the mobility sessions to another less loaded LMA. 184 If there is a need to maintain mobility session continuity during the 185 redirection, then additional functionality is required in LMAs and 186 possibly in the PMIPv6 Domain routing system. A context transfer 187 mechanism directly between LMAs, via a remote Policy Store or via 188 some other control function would be an obvious requirement. 189 However, context transfer specifics are outside the scope of this 190 document. 192 5. Proxy Mobile IPv6 Domain Considerations 194 The redirection problem discussed in this document is only possible 195 between MAGs and LMAs that have an existing SA set up. It is the 196 responsibility of the rfLMA that receives a PBU from a MAG to 197 redirect the MAG to a such r2LMA whom the MAG already has a SA set up 198 with. Furthermore, the rfLMA and the r2LMA must have a prior 199 agreement and an established trust relationship to perform 200 redirection. How a LMA learns and knows of other LMAs (where the 201 mobility session can be redirected), is not covered by this problem 202 statement. Dynamic establishment of a SA during redirection is not 203 covered in this problem statement. 205 6. Security Considerations 207 The security considerations of PMIPv6 signaling described in RFC 5213 208 [RFC5213] apply to this document. An incorrectly configured 209 redirection functionality may cause unwanted redirection attempts to 210 non-existing LMAs or to other LMAs that do not have and will not have 211 a SA with the redirected MAG. At the same time, a falsely redirected 212 MAG will experience failing binding updates and failing creation of 213 mobility sessions. An incorrectly configured redirection 214 functionality may also cause biased load distribution within a PMIPv6 215 Domain. This document also assumes that the LMAs participating to 216 the redirection have adequate prior agreement and trust relationship 217 between each other. 219 7. IANA Considerations 221 This document has no IANA actions. 223 8. References 225 8.1. Normative References 227 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 228 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 230 8.2. Informative References 232 [I-D.ietf-dime-pmip6] 233 Korhonen, J., Bournelle, J., Muhanna, A., Chowdhury, K., 234 and U. Meyer, "Diameter Proxy Mobile IPv6: Support For 235 Mobile Access Gateway and Local Mobility Anchor to 236 Diameter Server Interaction", draft-ietf-dime-pmip6-00 237 (work in progress), January 2009. 239 [I-D.korhonen-netlmm-lma-discovery] 240 Korhonen, J. and V. Devarapalli, "LMA Discovery for Proxy 241 Mobile IPv6", draft-korhonen-netlmm-lma-discovery-00 (work 242 in progress), October 2008. 244 [RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, 245 "Mobility Header Home Agent Switch Message", RFC 5142, 246 January 2008. 248 Author's Address 250 Jouni Korhonen 251 Nokia Siemens Networks 252 Linnoitustie 6 253 FIN-02600 Espoo 254 FINLAND 256 Email: jouni.nospam@gmail.com