idnits 2.17.1 draft-sijeon-dmm-use-cases-api-source-02.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 (October 19, 2015) is 3112 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-dmm-ondemand-mobility-00 ** Downref: Normative reference to an Informational draft: draft-ietf-dmm-ondemand-mobility (ref. 'I-D.ietf-dmm-ondemand-mobility') ** Downref: Normative reference to an Informational RFC: RFC 5014 == Outdated reference: A later version (-03) exists of draft-mccann-dmm-prefixcost-02 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM S. Jeon 3 Internet-Draft Instituto de Telecomunicacoes 4 Intended status: Standards Track S. Figueiredo 5 Expires: April 21, 2016 Altran Research 6 Y. Kim 7 Soongsil University 8 J. Kaippallimalil 9 Huawei 10 October 19, 2015 12 Use Cases and API Extension for Source IP Address Selection 13 draft-sijeon-dmm-use-cases-api-source-02.txt 15 Abstract 17 This draft specifies and analyzes the expected cases regarding the 18 selection of a proper source IP address and address type based on the 19 application features over a distributed mobility management (DMM) 20 network. It also provides available selection methods to better 21 achieve DMM goals in the specified scenarios. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 21, 2016. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. When an application does not have specific IP address 60 type requirement and address preferences . . . . . . . . 3 61 2.2. When an application has specific IP address type 62 requirement and address preference . . . . . . . . . . . 3 63 2.2.1. Case 1: there is no available IP address based on a 64 requested type in the IP stack . . . . . . . . . . . 3 65 2.2.2. Case 2: there are one or more IP addresses based on a 66 requested type in the IP stack, and no selection 67 preference by the application . . . . . . . . . . . . 4 68 2.2.3. Case 3: there are one or more IP addresses based on a 69 requested type in the IP stack, but there is a 70 further selection preference by the application . . . 4 71 3. Indications for expressing address preference requirement . . 5 72 3.1. When an application does not have specific IP address 73 type requirement and address preferences . . . . . . . . 5 74 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 79 7.2. Informative References . . . . . . . . . . . . . . . . . 7 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 82 1. Introduction 84 In [I-D.ietf-dmm-ondemand-mobility], it suggests picking up a proper 85 source IP address type for an initiated application in a mobile node 86 (MN), taking into consideration the need of IP session continuity 87 and/or IP address reachability by the application. Therefore, source 88 IP addresses were defined in three types with regard to providing the 89 required mobility management capabilities: fixed IP address, 90 sustained IP address, and nomadic IP address. Following the on- 91 demand mobility approach, the MN obtains a proper IP address 92 corresponding to a specific address type requirement when an 93 application tries to get an IP address, whereas the former approaches 94 [RFC5014][RFC6724] operate on the available set of IP addresses, 95 based on a preference. But even in the specific type of IP address 96 request, there may be a need to indicate further requirements such as 97 which IP address is preferred among the available IP addresses 98 belonging to the same type requested by the application. Such a 99 situation may easily be met over a DMM network environment for some 100 reasons such as QoS or Policy, as an MN is supposed to obtain new IP 101 prefixes from the different serving networks to which it attaches. 102 To check and reflect further requirements based on the IP address 103 types defined in the on-demand mobility management, this draft 104 specifies and describes expected use cases where an MN is likely to 105 be encountered and proposes required extensions to fill the gaps 106 found from the use cases study. 108 2. Use Cases 110 We specify and analyze expected use cases where the MN tries to 111 initiate an application. 113 2.1. When an application does not have specific IP address type 114 requirement and address preferences 116 Applications such as a text-based web browsing or information-centric 117 service, e.g. weather and stock information, as well as legacy 118 applications may belong to this category. As many applications 119 require simple Internet connectivity without session continuity and 120 IP address reachability, assigning a nomadic IP address can be highly 121 considered by default for MNs. But it is subject to address 122 assignment policy by network operators. The suggested flag, 123 IPV6_REQ_NOMADIC_IP, defined in [I-D.ietf-dmm-ondemand-mobility] is 124 used for expressing its preference to the IP stack. 126 2.2. When an application has specific IP address type requirement and 127 address preference 129 This category is for an application requiring IP session continuity 130 with different granularity of IP address reachability. This case may 131 be further divided in three sub-cases with regard to IP address type 132 availability and/or address selection. 134 2.2.1. Case 1: there is no available IP address based on a requested 135 type in the IP stack 137 For mobility support in terms of IP session continuity and IP address 138 reachability, sustained IP address and fixed IP address are used. 139 When one IP address of one of the two types is requested using flag 140 IPV6_REQ_FIXED_IP or IPV6 REQ SUSTAINED IP, accordingly, a proper 141 address assignment procedure based on DHCP or IP mobility management 142 protocol is expected. 144 2.2.2. Case 2: there are one or more IP addresses based on a requested 145 type in the IP stack, and no selection preference by the 146 application 148 In this case, the situation the MN meets is the same as Case 1 149 described above, except the availability of IP addresses belonging to 150 the requested IP address type in the IP stack, e.g. due to different 151 address assignment policy by an operator. Expected operation can be 152 described as follows: 154 1. The MN is configured with one or more sustained IP addresses. 156 2. Once an application requests "sustained IP address" to the IP 157 stack, it will use the existing sustained IP address when there is 158 one sustained IP address available in the IP stack. If there are 159 multiple available sustained IP addresses, the default address 160 selection rules will be applied [RFC6724], e.g. with scope 161 preference, longest prefix matching, and/or so on. The best-matched 162 IP address among them will be selected and assigned to the 163 application. 165 3. The MN moves to another serving network, while the previous 166 (mobile) sessions are still working. A new application requests a 167 sustained IP address with the address flag to the IP stack. The 168 selection of the sustained IP address follows the same procedure as 169 described in Step 2. 171 2.2.3. Case 3: there are one or more IP addresses based on a requested 172 type in the IP stack, but there is a further selection 173 preference by the application 175 In case of sustained IP address, the procedure to assign and 176 configure sustained IP addresses is the same as the procedure 177 described in Case 2 when following the three types of IP addresses in 178 [I-D.ietf-dmm-ondemand-mobility]. 180 On one hand, the on-demand mobility is meant to enable application to 181 have the desired mobility capability, i.e. IP address session 182 continuity and/or IP address reachability, by proper selection of a 183 source IP address. On the other hand, it needs to be extended to 184 have dynamic mobility management capability, which should be 185 considered when sustained IP address is used. The specified 186 operation based on the definition of address flags in 187 [I-D.ietf-dmm-ondemand-mobility] does not ensure the observation of 188 dynamic mobility principle, where IP mobility is provided only upon 189 an MN's movement. This is because an initiated application may be 190 served with IP mobility even though the MN has not moved from the 191 current serving network where the IP prefix/address was assigned for 192 the Application. As a result, IP mobility may be activated before 193 needed, so the new session is served by a remote IP mobility anchor 194 with necessary mobility management functions, though the MN has not 195 moved yet. 197 To make a proper way of delivering further preference of an 198 application, additional definition for address selection preference 199 in address flag level will help fill the requirement. See Section 3 200 for the proposed flag. 202 3. Indications for expressing address preference requirement 204 When an application prefers a new IP address of the requested IP 205 address type, additional indication flags should be delivered through 206 the socket API interface. 208 3.1. When an application does not have specific IP address type 209 requirement and address preferences 211 To support dynamic mobility of an initiated application using 212 sustained IP address, a new address preference flag needs to be 213 defined. Definition of additional flag should be simple and useful 214 while going along with the three types of IP addresses. But careful 215 consideration may be needed in defining the level of address 216 preference flag among "requirement" or "preference". The objective 217 of the hereby presented address preference flag is letting the IP 218 stack check whether it has an available IP address assigned from the 219 current serving network when the flag is received by an initiated 220 application. If not, it will trigger the IP stack to get a new IP 221 address from the current serving network. We call it "ON_NET" 222 property. 224 If it is defined in the requirement level, the IP address confirmed 225 to the address preference requirement should be used, though other 226 sustained IP addresses, not assigned from the current serving 227 network, are available. If there are multiple sustained IP addresses 228 matched with ON_NET property, the default source address selection 229 rules will be applied. 231 If it is defined in the preference level, priority value for ON_NET 232 flag should be determined among the other address preference flags 233 defined in [RFC5014]. 235 IPV6_XX_SRC_ON_NET 237 /* Require (or Prefer) an IP address based on a requested IP address 238 type as source, assigned from the current serving network, whatever 239 it has been assigned or should be assigned */ 240 This flag aims to express the preference to check an IP address, 241 being used by an application, previously assigned from the current 242 serving network and to use it or to get an IP address from the 243 current serving network, as well as enabling differentiated per-flow 244 anchoring where an obtained sustained IP address might be used for 245 all initiated sustained IP applications. The use of the flag can be 246 combined together with the three types of IP address defined in 247 [I-D.ietf-dmm-ondemand-mobility]. 249 In [I-D.mccann-dmm-prefixcost], it proposes that the Router 250 Advertisement signaling messages communicate the cost of maintaining 251 a given prefix at the MN's current point of attachment. The 252 objective of the idea is to make a dynamic and optimal decision of 253 address assignment and release, i.e. when to release old addresses 254 and assign new ones. The proposed ON_NET property presents a way to 255 deliver a prefix decision of an application, specifically from a 256 routing distance point of view, to the IP stack. 258 4. IANA Considerations 260 This document makes no request of IANA. 262 5. Security Considerations 264 T.B.D. 266 6. Acknowledgements 268 7. References 270 7.1. Normative References 272 [I-D.ietf-dmm-ondemand-mobility] 273 Yegin, A., Kweon, K., Lee, J., Park, J., and D. Moses, "On 274 Demand Mobility Management", draft-ietf-dmm-ondemand- 275 mobility-00 (work in progress), May 2015. 277 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 278 Socket API for Source Address Selection", RFC 5014, 279 DOI 10.17487/RFC5014, September 2007, 280 . 282 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 283 "Default Address Selection for Internet Protocol Version 6 284 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 285 . 287 7.2. Informative References 289 [I-D.mccann-dmm-prefixcost] 290 McCann, P. and J. Kaippallimalil, "Communicating Prefix 291 Cost to Mobile Nodes", draft-mccann-dmm-prefixcost-02 292 (work in progress), October 2015. 294 Authors' Addresses 296 Seil Jeon 297 Instituto de Telecomunicacoes 298 Campus Universitario de Santiago 299 Aveiro 3810-193 300 Portugal 302 Email: seiljeon@av.it.pt 304 Sergio Figueiredo 305 Altran Research 306 2, Rue Paul Dautier 307 Velizy-Villacoublay 78140 308 France 310 Email: sergio.figueiredo@altran.com 312 Younghan Kim 313 Soongsil University 314 369, Sangdo-ro, Dongjak-gu 315 Seoul 156-743 316 Korea 318 Email: younghak@ssu.ac.kr 320 John Kaippallimalil 321 Huawei 322 5340 Legacy Dr., Suite 175 323 Plano, TX 75024 324 USA 326 Email: john.kaippallimalil@huawei.com