idnits 2.17.1 draft-yan-dmm-man-09.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 (January 27, 2022) is 819 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5268 (Obsoleted by RFC 5568) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM Working Group Z. Yan 3 Internet-Draft CNNIC 4 Intended status: Informational J. Guan 5 Expires: July 31, 2022 BUPT 6 J. Lee 7 Sejong University 8 T. Huang 9 BUPT 10 January 27, 2022 12 Mobility Capability Negotiation as a 5G Mobility Pattern 13 draft-yan-dmm-man-09 15 Abstract 17 Mobility support is an important network capability for mobile node, 18 and 5G introduces the Mobility Pattern used by the Access and 19 Mobility Management Function (AMF) to optimize mobility support 20 provided to the UE. More specific, The AMF determines and updates 21 Mobility Pattern of the UE according to the subscription of the UE, 22 statistics of the UE mobility, network local policy, and the UE 23 assisted information, or any combination of them with the help of 24 NWDAF. Based on different requirements, multiple mobility management 25 protocols have been developed under IPv6. However, different 26 protocols have different functional requirements on the network 27 element or the host and then a scheme should be used in order to 28 support the negotiation and selection of adopted mobility management 29 protocol when a host (or UE) accesses to a new network. In this 30 draft, this issue is analyzed. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on July 31, 2022. 49 Copyright Notice 51 Copyright (c) 2022 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Possible Cases . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Protocol Selection Principles . . . . . . . . . . . . . . . . 10 70 5. General Procedure . . . . . . . . . . . . . . . . . . . . . . 10 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 75 8.2. Informative References . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 In order to clearly analyze the possible cases and actual 81 requirements, the following category labels of the mobility 82 management protocols are defined: 84 o Mobile IPv6 (MIPv6) protocol: the mobility management scheme based 85 on [RFC6275]. 86 o Proxy Mobile IPv6 (PMIPv6) protocol: the mobility management 87 scheme based on [RFC5213]. 88 o MIPv6 suit protocols: based on MIPv6, there are multiple extension 89 protocols have been standardized. These protocols can be 90 classified into two types: protocols for the function extension 91 and protocols for the performance enhancement. The protocols for 92 the function extension are proposed to support some specific 93 scenarios or functions, such as Dual-stack Mobile IPv6 (DSMIPv6) 94 [RFC5555] for mobility of the dual-stack nodes, Multiple Care-of- 95 address (MCoA) [RFC5648] for hosts with multiple access interfaces 96 and Network Mobility (NEMO) [RFC3963] for mobility of sub-network. 98 The other type is proposed to enhance the performance of the 99 mobility management, such as Fast Mobile IPv6 (FMIP6) [RFC5268] 100 for fast handover, Hierarchical Mobile IPv6 (HMIPv6) [RFC5380] for 101 hierarchical mobility optimization. In the MIPv6 suit protocols, 102 location update is initiated by the host and the tunnel is also 103 terminated at the host. 104 o PMIPv6 suit protocols: in order to reduce the protocol cost and 105 enhance the handover performance further, the network-based 106 mobility management protocols were proposed and PMIPv6 was 107 standardized as a basis. Based on PMIPv6, a series of its 108 extensions were proposed, such as Dual-stack Proxy Mobile IPv6 109 (DS-PMIPv6) [RFC5844], and Distributed Mobility Management Proxy 110 Mobile IPv6 (DMM-PMIPv6) [RFC7333]. Be different from the MIPv6 111 suit protocols, the location update in PMIPv6 suit protocols is 112 triggered by the network entity and the tunnel is established 113 between network entities. Then the host needs to do nothing about 114 the signaling exchange during the movement, particularly, the 115 mobility is transparent to the IP layer of the host. 116 o Network-based protocols: generally, it means the mobility 117 management protocols which do not require the involvement of the 118 mobile node in order to accomplish mobility. It includes PMIPv6 119 suit protocols and other network-based solutions, such as GPRS 120 Tunnelling Protocol (GTP) [TS.29274][TS.29281]. 121 o Host-based protocols: generally, the mobility management protocols 122 which require the involvement of the mobile node in order to 123 accomplish mobility. It includes MIPv6 suit protocols and other 124 host-based solutions, such as Host Identity Protocol (HIP) 125 [RFC7401] and IKEv2 Mobility and Multihoming Protocol (MOBIKE) 126 [RFC4555]. 127 o AMF: Access and Mobility Management Function, is responsible for 128 processing the control signaling between the User Equipment (UE) 129 and the core network. It inherits the mobility management 130 function and access control function. It is the most important 131 control module in the 5G core network. It has the ability to 132 process user registration requests, authenticate user identity, 133 and when the UE sends the location movement, it handles the UE's 134 location update and other functions. 135 o Mobility Pattern: The Mobility Pattern is a concept that may be 136 used by the AMF to characterise and optimise the UE mobility. Due 137 to the uneven space-time distribution of mobile data traffic and 138 frequent user switching in the 5G system, the 5G core network 139 function still has the problem of unbalanced load. Especially, 140 when the UE accesses the 5G communication system or the UE moves 141 between 5G base stations, the access network needs to allocate the 142 access and handover requests of the UE to the AMF to carry and 143 process them. Allocating UEs to those with relatively large 144 remaining resources can achieve load balancing of different AMFs, 145 thereby effectively accelerating service response speed and 146 improving the stability of the communication system. 148 Figure 1 illustrates the scopes of the above different category 149 labels. 151 +----------------+ +----------------+ 152 | Network-based | | Host-based | 153 |+--------------+| |+--------------+| 154 ||PMIPv6 suit || ||MIPv6 suit || 155 ||+------------+|| ||+------------+|| 156 |||PMIPv6 ||| |||MIPv6 ||| 157 ||+------------+|| ||+------------+|| 158 |+--------------+| |+--------------+| 159 +----------------+ +----------------+ 161 Figure 1: Scopes of different protocol category labels 163 In reality, the host-based protocols and network-based protocols will 164 be co-existing and multiple protocol deamons will be configured on 165 the network entities and host. That means a scheme is needed to 166 support the negotiation and selection of mobility management protocol 167 when the host accesses into a new access network initially or 168 handover happens [Paper-CombiningMobilityStandards]. 170 This document tries to present the principles for the protocol 171 selection and analyze the possible scenarios which should be 172 supported by the further solution. 174 2. Motivations 176 As illustrated above, these protocols may co-exist in reality and 177 simultaneously be used in an access network or even the same entity 178 to support ubiquitous connection and mobility support in 5G. Due to 179 their different requirements on the network entity or host, a scheme 180 is needed to support the negotiation and selection of adopted 181 mobility management protocol when the host accesses to a new network, 182 as a implementation of Mobility Pattern. Generally, two problems 183 should be solved: 185 o What principles should be followed for the protocol negotiation 186 and selection? 187 o What procedure should be adopted for the protocol negotiation and 188 selection? 190 This scheme is needed because network entity and host may have 191 different capabilities and preferences (may be decided by the 192 capability and mobility pattern of the host). This scheme aims to 193 guarantee that the optimum and most suitable protocol will be used, 194 although the selection procedure and notification scheme can be 195 implementation-dependent. 197 3. Possible Cases 199 From both host and network aspects, their capabilities of mobility 200 management may have multiple cases as shown in Figure 2. We mainly 201 analyze that host and network support single protocol for clear 202 description, if multiple protocols are supported simultaneously by 203 the host or network side, multiple cases exist at the same time but 204 the logic is same as that in the case with single protocol supported. 205 Specifically, the following cases should be considered. 207 1) Network supports network-based protocol, host supports network- 208 based protocol 210 In this case, there are the following sub-cases: 212 a) Host supports PMIPv6 suit protocol, Network supports PMIPv6 suit 213 protocol 215 o if host supports PMIPv6 and network supports PMIPv6, PMIPv6 is 216 selected. 217 o if host supports PMIPv6 and network supports extended PMIPv6 218 protocol, extended PMIPv6 protocol is selected if no host 219 involvement is needed, otherwise the plain PMIPv6 is selected (we 220 assume that the extension protocols are backward-compatible with 221 the related plain protocol). 222 o if host supports extended PMIPv6 protocol and network supports 223 PMIPv6, PMIPv6 is selected (we assume that the extension protocols 224 are backward-compatible with the related plain protocol). 225 o if host supports extended PMIPv6 protocol and network supports 226 extended PMIPv6 protocol, the identical extension protocol is 227 selected, otherwise, PMIPv6 is selected (we assume that the 228 extension protocols are backward-compatible with the related plain 229 protocol). 231 +-------------+-----------+--------------------------- + 232 | | |PMIPv6 | 233 | | |-----------------+----------+ 234 |Network-based|PMIPv6 suit| |DS-PMIPv6 | 235 | | | +----------+ 236 | | |PMIPv6 extensions|FPMIPv6 | 237 | | | +----------+ 238 | | | |DMM-PMIPv6| 239 | | | +----------+ 240 | | | |... | 241 | |-----------+-----------------+----------+ 242 | | Others |GTP | 243 | | |----------------------------+ 244 | | |... | 245 +-------------+-----------+----------------------------+ 246 | | |MIPv6 | 247 | | |-----------------+----------+ 248 |Host-based |MIPv6 suit | |DS-MIPv6 | 249 | | | +----------+ 250 | | | |FMIPv6 | 251 | | | +----------+ 252 | | |MIPv6 extensions |HMIPv6 | 253 | | | +----------+ 254 | | | |NEMO | 255 | | | +----------+ 256 | | | |DMM-MIPv6 | 257 | | | +----------+ 258 | | | |... | 259 | |-----------+-----------------+----------+ 260 | | Others |HIP | 261 | | |----------------------------+ 262 | | |MOBIKE | 263 | | |----------------------------+ 264 | | |... | 265 +-------------+-----------+----------------------------+ 267 Figure 2: Possible capacities of host and network 269 b) Host supports PMIPv6 suit protocol, Network supports other 270 network-based protocol 272 o if host supports PMIPv6 and network supports other network-based 273 protocol, other network-based protocol is selected if no host 274 involvement is needed, otherwise failure. 275 o if host supports extended PMIPv6 protocol and network supports 276 other network-based protocol, other network-based protocol is 277 selected if no host involvement is needed, otherwise failure. 279 c) Host supports other network-based protocol, Network supports 280 PMIPv6 suit protocol 282 o if host supports other network-based protocol and network supports 283 PMIPv6, PMIPv6 is selected. 284 o if host supports other network-based protocol and network supports 285 extended PMIPv6 protocol, extended PMIPv6 protocol is selected if 286 no host involvement is needed, otherwise failure. 288 d) Host supports other network-based protocol, Network supports other 289 network-based protocol 291 o the identical protocol is selected, otherwise follow network 292 capability if the protocols are different. 294 2) Network supports network-based protocol, host supports host-based 295 protocol 297 In this case, there are the following sub-cases: 299 a) Host supports PMIPv6 suit protocol, Network supports MIPv6 suit 300 protocol 302 o if host supports PMIPv6 and network supports MIPv6, failure. 303 o if host supports PMIPv6 and network supports extended MIPv6 304 protocol, failure. 305 o if host supports extended PMIPv6 protocol and network supports 306 MIPv6, failure. 307 o if host supports extended PMIPv6 protocol and network supports 308 extended MIPv6 protocol, failure. 310 b) Host supports PMIPv6 suit protocol, Network supports other host- 311 based protocol 313 o if host supports PMIPv6 and network supports other host-based 314 protocol, failure. 315 o if host supports extended PMIPv6 protocol and network supports 316 other host-based protocol, failure. 318 c) Host supports other network-based protocol, Network supports MIPv6 319 suit protocol 321 o if host supports other network-based protocol and network supports 322 MIPv6, failure. 323 o if host supports other network-based protocol and network supports 324 extended MIPv6 protocol, failure. 326 d) Host supports other network-based protocol, Network supports other 327 host-based protocol 329 o failure. 331 3) Network supports host-based protocol, host supports network-based 332 protocol 334 In this case, there are the following sub-cases: 336 a) Host supports MIPv6 suit protocol, Network supports PMIPv6 suit 337 protocol 339 o if host supports MIPv6 and network supports PMIPv6, PMIPv6 is 340 selected in default and MIPv6 is selected if host prefers it. 341 o if host supports MIPv6 and network supports extended PMIPv6 342 protocol, extended PMIPv6 is selected in default, then PMIPv6 is 343 selected with the lower priority and MIPv6 is selected if host 344 prefers it. 345 o if host supports extended MIPv6 protocol and network supports 346 PMIPv6, PMIPv6 is selected in default, then extended MIPv6 347 protocol is selected if host prefers it and network also supports, 348 otherwise MIPv6 is selected with the lowest priority. 349 o if host supports extended MIPv6 protocol and network supports 350 extended PMIPv6 protocol, extended PMIPv6 protocol is selected in 351 default, then PMIPv6 is selected, then extended MIPv6 protocol is 352 selected if host prefers and network also supports, otherwise 353 MIPv6 is selected with the lowest priority. 355 b) Host supports MIPv6 suit protocol, Network supports other network- 356 based protocol 358 o if host supports MIPv6 and network supports other network-based 359 protocol, other network-based protocol is selected if no host 360 involvement is needed, otherwise failure. 361 o if host supports extended MIPv6 protocol and network supports 362 other network-based protocol, other network-based protocol is 363 selected if no host involvement is needed, otherwise failure. 365 c) Host supports other host-based protocol, Network supports PMIPv6 366 suit protocol 368 o if host supports other host-based protocol and network supports 369 PMIPv6, PMIPv6 is selected in default, otherwise failure. 370 o if host supports other host-based protocol and network supports 371 extended PMIPv6 protocol, extended PMIPv6 protocol is selected if 372 no host involvement is needed, otherwise failure. 374 d) Host supports other host-based protocol, Network supports other 375 network-based protocol 377 o other network-based protocol is selected if no host involvement is 378 needed, otherwise failure. 380 4) Network supports host-based protocol, host supports host-based 381 protocol 383 In this case, there are the following sub-cases: 385 a) Host supports MIPv6 suit protocol, Network supports MIPv6 suit 386 protocol 388 o if host supports MIPv6 and network supports MIPv6, MIPv6 is 389 selected. 390 o if host supports MIPv6 and network supports extended MIPv6 391 protocol, MIPv6 is selected. 392 o if host supports extended MIPv6 protocol and network supports 393 MIPv6, MIPv6 is selected. 394 o if host supports extended MIPv6 protocol and network supports 395 extended MIPv6 protocol, the identical protocol is selected, 396 otherwise MIPv6 is selected. 398 b) Host supports MIPv6 suit protocol, Network supports other host- 399 based protocol 401 o if host supports MIPv6 and network supports other host-based 402 protocol, failure. 403 o if host supports extended MIPv6 protocol and network supports 404 other host-based protocol, failure. 406 c) Host supports other host-based protocol, Network supports MIPv6 407 suit protocol 409 o if host supports other host-based protocol and network supports 410 MIPv6, failure. 411 o if host supports other host-based protocol and network supports 412 extended MIPv6 protocol, failure. 414 d) Host supports other host-based protocol, Network supports other 415 host-based protocol 417 o the identical other host-based protocol is selected, otherwise 418 failure. 420 5) Network supports host-based protocol and network-based protocol, 421 host supports host-based protocol and network-based protocol 422 o follow the network based protocol in default if the host can 423 support, otherwise select the protocol both network and host can 424 support if host prefers. 426 4. Protocol Selection Principles 428 Two different schemes may be used for the protocol negotiation and 429 selection: host-initiated and network-initiated. Within the MIPv6/ 430 PMIPv6 protocols, the priority of the function-extension protocols 431 should be higher than the performance-enhancement protocols. 432 Generally, the following principles should be followed: 434 o In default: Network based scheme if it can be supported 435 o Priority 1: Follow network capability 436 o Priority 2: Follow host preference 437 o Priority 3: Support the functional extensions 438 o Priority 4: Support the performance enhancements 440 5. General Procedure 442 The protocol negotiation may be included in the MN_ATTACH Function 443 [MN-AR.IF] and the implementation may be based on a new signaling 444 message or extended messages (e.g., ICMPv6, Diameter, and RADIUS). 445 Besides these, some other protocols may also be used in some 446 specified scenarios, such as extended IEEE 802.21 primitives. Then 447 the selected protocol will be included as a parameter in AMF during 448 the node handover. 450 The general procedure for the protocol selection should be: 452 o During initiation, network-based protocol may be used as a default 453 mobility management protocol once the network supports it. 454 o If the host prefers host-based protocols, a negotiation is 455 executed to handover from network-based protocol to host-based 456 protocol. 457 o After initial attachment, a profile will be generated in the 458 management store to record the selected or preferred protocol of 459 this host. 460 o When the handover happens, the network will check the selected or 461 preferred protocol during the authentication process. But the 462 network also needs to notify the host if the selected protocol 463 cannot be supported herein. 465 When the host accesses to the network, an authentication should be 466 executed before the mobility management service is provided. In 467 order to support the mobility management protocol selection, a new 468 information should be recorded by the network after the successful 469 authentication during the initial attachment. The newly introduced 470 information in AMF shows the selected mobility management protocol 471 and should be updated when the used protocol changes. 473 6. Security Considerations 475 Generally, this function will not incur additional security issues. 476 The detailed influence should be analyzed in the future. 478 7. IANA Considerations 480 A new authentication option or other signaling message option may be 481 used based on the specific implementation. 483 8. References 485 8.1. Normative References 487 [MN-AR.IF] 488 Laganier, J., Narayanan, S., and P. McCann, "Interface 489 between a Proxy MIPv6 Mobility Access Gateway and a Mobile 490 Node", draft-ietf-netlmm-mn-ar-if-03, February 2008. 492 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 493 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 494 RFC 3963, DOI 10.17487/RFC3963, January 2005, 495 . 497 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 498 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 499 . 501 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 502 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 503 RFC 5213, DOI 10.17487/RFC5213, August 2008, 504 . 506 [RFC5268] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268, 507 DOI 10.17487/RFC5268, June 2008, 508 . 510 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 511 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 512 Management", RFC 5380, DOI 10.17487/RFC5380, October 2008, 513 . 515 [RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack 516 Hosts and Routers", RFC 5555, DOI 10.17487/RFC5555, June 517 2009, . 519 [RFC5648] Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G., Ernst, 520 T., and K. Nagami, "Multiple Care-of Addresses 521 Registration", RFC 5648, DOI 10.17487/RFC5648, October 522 2009, . 524 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 525 Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010, 526 . 528 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 529 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 530 2011, . 532 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 533 Korhonen, "Requirements for Distributed Mobility 534 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 535 . 537 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 538 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 539 RFC 7401, DOI 10.17487/RFC7401, April 2015, 540 . 542 [TS.23.288] 543 "3GPP TS 23.288 (V17.3.0): Architecture enhancements for 544 5G System (5GS) to support network data analytics 545 services", 3GPP TS 23.288, December 2021. 547 [TS.23.501] 548 "3GPP TS 23.501 (V17.0.0): System Architecture for 5G 549 System; Stage 2", 3GPP TS 23.501, March 2021. 551 [TS.29274] 552 "3GPP Evolved Packet System (EPS); Evolved General Packet 553 Radio Service (GPRS) Tunnelling Protocol for Control plane 554 (GTPv2-C); Stage 3", 3GPP TS 29.274 8.10.0, June 2011. 556 [TS.29281] 557 "General Packet Radio System (GPRS) Tunnelling Protocol 558 User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, September 559 2011. 561 8.2. Informative References 563 [Paper-CombiningMobilityStandards] 564 Oliva, A., Soto, I., Calderon, M., Bernardos, C., and M. 565 Sanchez, "The costs and benefits of combining different IP 566 mobility standards", Computer Standards and Interfaces, 567 February 2013. 569 Authors' Addresses 571 Zhiwei Yan 572 CNNIC 573 No.4 South 4th Street, Zhongguancun 574 Beijing 100190 575 China 577 Email: yan@cnnic.cn 579 Jianfeng Guan 580 BUPT 581 No.10 Xitucheng Road, Haidian District 582 Beijing 100876 583 China 585 Email: jfguan@bupt.edu.cn 587 Jong-Hyouk Lee 588 Sejong University 589 209, Neungdong-ro, Gwangjin-gu 590 Seoul 05006 591 Republic of Korea 593 Email: jonghyouk@sejong.ac.kr 595 Tao Huang 596 BUPT 597 No.10 Xitucheng Road, Haidian District 598 Beijing 100876 599 China 601 Email: htao@bupt.edu.cn