idnits 2.17.1 draft-yan-dmm-man-05.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 (September 19, 2019) is 1652 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5268 (Obsoleted by RFC 5568) ** Downref: Normative reference to an Informational RFC: RFC 7333 Summary: 2 errors (**), 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 G. Geng 4 Intended status: Standards Track CNNIC 5 Expires: March 22, 2020 J. Lee 6 Sangmyung University 7 H. Chan 8 Huawei Technologies 9 September 19, 2019 11 Mobility Capability Negotiation and Protocol Selection 12 draft-yan-dmm-man-05 14 Abstract 16 Based on different requirements, multiple mobility management 17 protocols have been developed. Different protocols have different 18 functional requirements on the network element or the host and then a 19 scheme should be used in order to support the negotiation and 20 selection of adopted mobility management protocol when a host 21 accesses to a new network. In this draft, this issue is analyzed. 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 https://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 March 22, 2020. 40 Copyright Notice 42 Copyright (c) 2019 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 (https://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. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Possible Cases . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Principles and Possible Procedure . . . . . . . . . . . . . . 9 61 5. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 66 8.2. Informative References . . . . . . . . . . . . . . . . . 13 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 69 1. Introduction 71 In order to clearly analyze the possible cases, the following 72 category labels of the mobility management protocols are defined: 74 o Mobile IPv6 (MIPv6) protocol: the mobility management scheme based 75 on [RFC6275]. 76 o Proxy Mobile IPv6 (PMIPv6) protocol: the mobility management 77 scheme based on [RFC5213]. 78 o MIPv6 suit protocols: based on MIPv6, there are multiple extension 79 protocols have been standardized. These protocols can be 80 classified into two types: protocols for the function extension 81 and protocols for the performance enhancement. The protocols for 82 the function extension are proposed to support some specific 83 scenarios or functions, such as Dual-stack Mobile IPv6 (DSMIPv6) 84 [RFC5555] for mobility of the dual-stack nodes, Multiple Care-of- 85 address (MCoA) [RFC5648] for hosts with multiple access interfaces 86 and Network Mobility (NEMO) [RFC3963] for mobility of sub-network. 87 The other type is proposed to enhance the performance of the 88 mobility management, such as Fast Mobile IPv6 (FMIP6) [RFC5268] 89 for fast handover, Hierarchical Mobile IPv6 (HMIPv6) [RFC5380] for 90 hierarchical mobility optimization. In the MIPv6 suit protocols, 91 location update is initiated by the host and the tunnel is also 92 terminated at the host. 93 o PMIPv6 suit protocols: in order to reduce the protocol cost and 94 enhance the handover performance further, the network-based 95 mobility management protocols were proposed and PMIPv6 was 96 standardized as a basis. Based on PMIPv6, a series of its 97 extensions were proposed, such as Dual-stack Proxy Mobile IPv6 98 (DS-PMIPv6) [RFC5844], and Distributed Mobility Management Proxy 99 Mobile IPv6 (DMM-PMIPv6) [RFC7333]. Be different from the MIPv6 100 suit protocols, the location update in PMIPv6 suit protocols is 101 triggered by the network entity and the tunnel is established 102 between network entities. Then the host needs to do nothing about 103 the signaling exchange during the movement, particularly, the 104 mobility is transparent to the IP layer of the host. 105 o Network-based protocols: generally, it means the mobility 106 management protocols which do not require the involvement of the 107 mobile node in order to accomplish mobility. It includes PMIPv6 108 suit protocols and other network-based solutions, such as GPRS 109 Tunnelling Protocol (GTP) [TS.29274][TS.29281]. 110 o Host-based protocols: generally, the mobility management protocols 111 which require the involvement of the mobile node in order to 112 accomplish mobility. It includes MIPv6 suit protocols and other 113 host-based solutions, such as Host Identity Protocol (HIP) 114 [RFC7401] and IKEv2 Mobility and Multihoming Protocol (MOBIKE) 115 [RFC4555]. 117 Figure 1 illustrates the scopes of the above different category 118 labels. 120 +----------------+ +----------------+ 121 | Network-based | | Host-based | 122 |+--------------+| |+--------------+| 123 ||PMIPv6 suit || ||MIPv6 suit || 124 ||+------------+|| ||+------------+|| 125 |||PMIPv6 ||| |||MIPv6 ||| 126 ||+------------+|| ||+------------+|| 127 |+--------------+| |+--------------+| 128 +----------------+ +----------------+ 130 Figure 1: Scopes of different protocol category labels 132 In reality, the host-based protocols and network-based protocols will 133 be co-existing and multiple protocol deamons will be configured on 134 the network entities or host. That means a scheme is needed to 135 support the negotiation and selection of mobility management protocol 136 when the host accesses into a new access network initially or 137 handover happens [Paper-CombiningMobilityStandards]. 139 This document tries to present the principles for the protocol 140 selection and analyze the possible scenarios which should be 141 supported by the further solution. 143 2. Motivations 145 As illustrated above, these protocols may co-exist in reality and 146 simultaneously be used in an access network or even the same entity. 147 Due to their different requirements on the network entity or host, a 148 scheme is needed to support the negotiation and selection of adopted 149 mobility management protocol when the host accesses to a new network. 150 Generally, two problems should be solved: 152 o What principles should be followed for the protocol negotiation 153 and selection? 154 o What procedure should be adopted for the protocol negotiation and 155 selection? 157 This scheme is needed because network entity and host may have 158 different capabilities and preferences (may be decided by the 159 capability and mobility pattern of the host). This scheme aims to 160 guarantee that the optimum and most suitable protocol will be used. 162 3. Possible Cases 164 From both host and network aspects, their capacities of mobility 165 management may have multiple cases as shown in Figure 2. We mainly 166 analyze that host and network support single protocol, if multiple 167 protocols are supported simultaneously by the host or network side, 168 multiple cases exist at the same time but the logic is same as that 169 in the case with single protocol supported. Specifically, the 170 following cases should be considered. 172 1) Network supports network-based protocol, host supports network- 173 based protocol 175 In this case, there are the following sub-cases: 177 a) Host supports PMIPv6 suit protocol, Network supports PMIPv6 suit 178 protocol 180 o if host supports PMIPv6 and network supports PMIPv6, PMIPv6 is 181 selected. 182 o if host supports PMIPv6 and network supports extended PMIPv6 183 protocol, extended PMIPv6 protocol is selected if no host 184 involvement is needed, otherwise the plain PMIPv6 is selected (we 185 assume that the extension protocols are backward-compatible with 186 the related plain protocol). 187 o if host supports extended PMIPv6 protocol and network supports 188 PMIPv6, PMIPv6 is selected (we assume that the extension protocols 189 are backward-compatible with the related plain protocol). 191 o if host supports extended PMIPv6 protocol and network supports 192 extended PMIPv6 protocol, the identical extension protocol is 193 selected, otherwise, PMIPv6 is selected (we assume that the 194 extension protocols are backward-compatible with the related plain 195 protocol). 197 +-------------+-----------+--------------------------- + 198 | | |PMIPv6 | 199 | | |-----------------+----------+ 200 |Network-based|PMIPv6 suit| |DS-PMIPv6 | 201 | | | +----------+ 202 | | |PMIPv6 extensions|FPMIPv6 | 203 | | | +----------+ 204 | | | |DMM-PMIPv6| 205 | | | +----------+ 206 | | | |... | 207 | |-----------+-----------------+----------+ 208 | | Others |GTP | 209 | | |----------------------------+ 210 | | |... | 211 +-------------+-----------+----------------------------+ 212 | | |MIPv6 | 213 | | |-----------------+----------+ 214 |Host-based |MIPv6 suit | |DS-MIPv6 | 215 | | | +----------+ 216 | | | |FMIPv6 | 217 | | | +----------+ 218 | | |MIPv6 extensions |HMIPv6 | 219 | | | +----------+ 220 | | | |NEMO | 221 | | | +----------+ 222 | | | |DMM-MIPv6 | 223 | | | +----------+ 224 | | | |... | 225 | |-----------+-----------------+----------+ 226 | | Others |HIP | 227 | | |----------------------------+ 228 | | |MOBIKE | 229 | | |----------------------------+ 230 | | |... | 231 +-------------+-----------+----------------------------+ 233 Figure 2: Possible capacities of host and network 235 b) Host supports PMIPv6 suit protocol, Network supports other 236 network-based protocol 237 o if host supports PMIPv6 and network supports other network-based 238 protocol, other network-based protocol is selected if no host 239 involvement is needed, otherwise failure. 240 o if host supports extended PMIPv6 protocol and network supports 241 other network-based protocol, other network-based protocol is 242 selected if no host involvement is needed, otherwise failure. 244 c) Host supports other network-based protocol, Network supports 245 PMIPv6 suit protocol 247 o if host supports other network-based protocol and network supports 248 PMIPv6, PMIPv6 is selected. 249 o if host supports other network-based protocol and network supports 250 extended PMIPv6 protocol, extended PMIPv6 protocol is selected if 251 no host involvement is needed, otherwise failure. 253 d) Host supports other network-based protocol, Network supports other 254 network-based protocol 256 o the identical protocol is selected, otherwise follow network 257 capability if the protocols are different. 259 2) Network supports network-based protocol, host supports host-based 260 protocol 262 In this case, there are the following sub-cases: 264 a) Host supports PMIPv6 suit protocol, Network supports MIPv6 suit 265 protocol 267 o if host supports PMIPv6 and network supports MIPv6, failure. 268 o if host supports PMIPv6 and network supports extended MIPv6 269 protocol, failure. 270 o if host supports extended PMIPv6 protocol and network supports 271 MIPv6, failure. 272 o if host supports extended PMIPv6 protocol and network supports 273 extended MIPv6 protocol, failure. 275 b) Host supports PMIPv6 suit protocol, Network supports other host- 276 based protocol 278 o if host supports PMIPv6 and network supports other host-based 279 protocol, failure. 280 o if host supports extended PMIPv6 protocol and network supports 281 other host-based protocol, failure. 283 c) Host supports other network-based protocol, Network supports MIPv6 284 suit protocol 285 o if host supports other network-based protocol and network supports 286 MIPv6, failure. 287 o if host supports other network-based protocol and network supports 288 extended MIPv6 protocol, failure. 290 d) Host supports other network-based protocol, Network supports other 291 host-based protocol 293 o failure. 295 3) Network supports host-based protocol, host supports network-based 296 protocol 298 In this case, there are the following sub-cases: 300 a) Host supports MIPv6 suit protocol, Network supports PMIPv6 suit 301 protocol 303 o if host supports MIPv6 and network supports PMIPv6, PMIPv6 is 304 selected in default and MIPv6 is selected if host prefers it. 305 o if host supports MIPv6 and network supports extended PMIPv6 306 protocol, extended PMIPv6 is selected in default, then PMIPv6 is 307 selected with the lower priority and MIPv6 is selected if host 308 prefers it. 309 o if host supports extended MIPv6 protocol and network supports 310 PMIPv6, PMIPv6 is selected in default, then extended MIPv6 311 protocol is selected if host prefers it and network also supports, 312 otherwise MIPv6 is selected with the lowest priority. 313 o if host supports extended MIPv6 protocol and network supports 314 extended PMIPv6 protocol, extended PMIPv6 protocol is selected in 315 default, then PMIPv6 is selected, then extended MIPv6 protocol is 316 selected if host prefers and network also supports, otherwise 317 MIPv6 is selected with the lowest priority. 319 b) Host supports MIPv6 suit protocol, Network supports other network- 320 based protocol 322 o if host supports MIPv6 and network supports other network-based 323 protocol, other network-based protocol is selected if no host 324 involvement is needed, otherwise failure. 325 o if host supports extended MIPv6 protocol and network supports 326 other network-based protocol, other network-based protocol is 327 selected if no host involvement is needed, otherwise failure. 329 c) Host supports other host-based protocol, Network supports PMIPv6 330 suit protocol 331 o if host supports other host-based protocol and network supports 332 PMIPv6, PMIPv6 is selected in default, otherwise failure. 333 o if host supports other host-based protocol and network supports 334 extended PMIPv6 protocol, extended PMIPv6 protocol is selected if 335 no host involvement is needed, otherwise failure. 337 d) Host supports other host-based protocol, Network supports other 338 network-based protocol 340 o other network-based protocol is selected if no host involvement is 341 needed, otherwise failure. 343 4) Network supports host-based protocol, host supports host-based 344 protocol 346 In this case, there are the following sub-cases: 348 a) Host supports MIPv6 suit protocol, Network supports MIPv6 suit 349 protocol 351 o if host supports MIPv6 and network supports MIPv6, MIPv6 is 352 selected. 353 o if host supports MIPv6 and network supports extended MIPv6 354 protocol, MIPv6 is selected. 355 o if host supports extended MIPv6 protocol and network supports 356 MIPv6, MIPv6 is selected. 357 o if host supports extended MIPv6 protocol and network supports 358 extended MIPv6 protocol, the identical protocol is selected, 359 otherwise MIPv6 is selected. 361 b) Host supports MIPv6 suit protocol, Network supports other host- 362 based protocol 364 o if host supports MIPv6 and network supports other host-based 365 protocol, failure. 366 o if host supports extended MIPv6 protocol and network supports 367 other host-based protocol, failure. 369 c) Host supports other host-based protocol, Network supports MIPv6 370 suit protocol 372 o if host supports other host-based protocol and network supports 373 MIPv6, failure. 374 o if host supports other host-based protocol and network supports 375 extended MIPv6 protocol, failure. 377 d) Host supports other host-based protocol, Network supports other 378 host-based protocol 379 o the identical other host-based protocol is selected, otherwise 380 failure. 382 5) Network supports host-based protocol and network-based protocol, 383 host supports host-based protocol and network-based protocol 385 o follow the network based protocol in default if the host can 386 support, otherwise select the protocol both network and host can 387 support if host prefers. 389 4. Principles and Possible Procedure 391 Two different schemes may be used for the protocol negotiation and 392 selection: host-initiated and network-initiated. Within the MIPv6/ 393 PMIPv6 protocols, the priority of the function-extension protocols 394 should be higher than the performance-enhancement protocols. 395 Generally, the following principles should be followed: 397 o In default: Network based scheme if it can be supported 398 o Priority 1: Follow network capability 399 o Priority 2: Follow host preference 400 o Priority 3: Support the functional extensions 401 o Priority 4: Support the performance enhancements 403 And the general procedure for the protocol selection should be: 405 o During initiation, network-based protocol may be used as a default 406 mobility management protocol once the network supports it. 407 o If the host prefers host-based protocols, a negotiation is 408 executed to handover from network-based protocol to host-based 409 protocol. 410 o After initial attachment, a profile will be generated in the 411 management store to record the selected or preferred protocol of 412 this host. 413 o When the handover happens, the network will check the selected or 414 preferred protocol during the authentication process. But the 415 network also needs to notify the host if the selected protocol 416 cannot be supported herein. 418 5. Extensions 420 In order to fulfill the above principles, some extensions should be 421 supported, for example: 423 1) Extended negotiation messages 425 The protocol negotiation may be included in the MN_ATTACH Function 426 [MN-AR.IF] and the implementation may be based on a new signaling 427 message or extended messages (e.g., ICMPv6, Diameter, and RADIUS). 428 Besides these, some other protocols may also be used in some 429 specified scenarios, such as extended IEEE 802.21 primitives. 431 As a possible solution, a new option under ICMPv6 is proposed in this 432 draft in order to support the protocol negotiation when the mobile 433 terminal initially accesses the network or hands over to a different 434 network. In the RA and Router Solicitation (RS) message headers, a 435 one-bit flag (C) is used to illustrate that mobility capability 436 negotiation is needed and a Mobility Capability (MC) option is 437 included in the message body. The format of MC option is shown in 438 Figure 3. 440 0 78 1516 2324 31 441 +---------+---------+---------+---------+ 442 | Type | Length | p |Reserved | 443 +---------------------------------------+ 444 | Protocol 1 | ...... | 445 +---------------------------------------+ 446 | Protocol p | Protocol p+1 | 447 +---------------------------------------+ 448 | ...... | Protocol s | 449 +---------------------------------------+ 451 Figure 3: The format of Mobility Capability option 453 "Type" indicates that this option is of the type Mobility Capability. 454 "p" is the number of preferred protocols. "Protocol 1" to "Protocol 455 s" is a list of s supported protocols, which can be selected. Out of 456 the s supported protocols, the first p protocols are ones preferred 457 by the network and the terminal, listed in the order of preference, 458 whereas no preference is indicated in the remaining protocols from 459 p+1 to s. How to code the protocol types with the 16-bit space is 460 implementation-depended. 462 "Length" is the number of octets in this option excluding option type 463 and option length, and it can be seen that Length = 2x(s+1). 465 "Reserved" is for future use. 467 It is noted that when p = 0, preference is not indicated in the 468 entire list of supported protocols, and when p = s, preference is 469 indicated in all the supported protocols. 471 Based on this extension, when the mobile terminal receives the RA 472 message with the "C" flag set to 1 and "p" in MC option is at least 473 one, it means that the access network has selected the first 474 supported protocol (protocol 1) as the default protocol for the 475 terminal. Based on the previous principles, the terminal should 476 follow this selected protocol if it is able to. If the terminal is 477 not capable to use the first supported protocol, it will use the 478 second supported protocol (protocol 2) if it is able to. If it is 479 still not capable of using the second supported protocol, it will try 480 the third one and so on. 482 If the terminal is not capable of using any of the p supported 483 protocols, it will try to use any of the remaining protocols. When 484 the mobile terminal receives the RA message with the "C" flag set to 485 1 and "Preferred protocol" in MC option is null, it means that the 486 access network has not selected the default protocol for the terminal 487 but illustratesed to the terminal about the supported protocols from 488 the network side. Then based on the previous principles, the 489 terminal should select one protocol and notify it to the network with 490 the MC option in RS message. The network should acknowledge it with 491 a new re-formatted RA message. In this new RA message, the protocol 492 selected by terminal is included in the "Preferred protocol" of MC 493 option. After the choice has been made, the terminal may inform the 494 network of the choice by sending a message with MC option in which p 495 = s = 1, and the protocol field is the selected protocol. 497 When the network receives the RS message with the "C" flag set to 1 498 and "p" in MC option is zero, it means that the terminal only lists 499 its supported mobility management protocols but does not have any 500 preference. The network will then select one based on the principles 501 and notify the selected protocol to the terminal with a RA message 502 containing the MC option in which p=1 and "protocol 1" is the 503 selected protocol. 505 When the network receives the RS message with the "C" flag set to 1 506 and "p" in MC option is at least one, it means that the terminal 507 tries to negotiate the mobility management protocol and has included 508 the preferred protocols listed in the order of preference. The 509 network will try one by one to select from protocol 1 to protocol p 510 until it has find one it supports. If the network is not capable of 511 supporting all the p protocols, it will try the remaining s-p 512 protocols. 514 2) Extended management store 516 When the host accesses to the network, an authentication should be 517 executed before the mobility management service is provided. In 518 order to support the mobility management protocol selection, a new 519 information should be recorded by the network after the successful 520 authentication during the initial attachment. The newly introduced 521 information shows the selected mobility management protocol and 522 should be updated when the used protocol changes. 524 6. Security Considerations 526 Generally, this function will not incur additional security issues. 527 The detailed influence should be analyzed in the future. 529 7. IANA Considerations 531 A new ICMP option or authentication option or other signaling message 532 may be used with a new code number. 534 8. References 536 8.1. Normative References 538 [MN-AR.IF] 539 Laganier, J., Narayanan, S., and P. McCann, "Interface 540 between a Proxy MIPv6 Mobility Access Gateway and a Mobile 541 Node", draft-ietf-netlmm-mn-ar-if-03, February 2008. 543 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 544 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 545 RFC 3963, DOI 10.17487/RFC3963, January 2005, 546 . 548 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 549 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 550 . 552 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 553 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 554 RFC 5213, DOI 10.17487/RFC5213, August 2008, 555 . 557 [RFC5268] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268, 558 DOI 10.17487/RFC5268, June 2008, 559 . 561 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 562 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 563 Management", RFC 5380, DOI 10.17487/RFC5380, October 2008, 564 . 566 [RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack 567 Hosts and Routers", RFC 5555, DOI 10.17487/RFC5555, June 568 2009, . 570 [RFC5648] Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G., Ernst, 571 T., and K. Nagami, "Multiple Care-of Addresses 572 Registration", RFC 5648, DOI 10.17487/RFC5648, October 573 2009, . 575 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 576 Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010, 577 . 579 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 580 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 581 2011, . 583 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 584 Korhonen, "Requirements for Distributed Mobility 585 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 586 . 588 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 589 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 590 RFC 7401, DOI 10.17487/RFC7401, April 2015, 591 . 593 [TS.29274] 594 "3GPP Evolved Packet System (EPS); Evolved General Packet 595 Radio Service (GPRS) Tunnelling Protocol for Control plane 596 (GTPv2-C); Stage 3", 3GPP TS 29.274 8.10.0, June 2011. 598 [TS.29281] 599 "General Packet Radio System (GPRS) Tunnelling Protocol 600 User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, September 601 2011. 603 8.2. Informative References 605 [Paper-CombiningMobilityStandards] 606 Oliva, A., Soto, I., Calderon, M., Bernardos, C., and M. 607 Sanchez, "The costs and benefits of combining different IP 608 mobility standards", Computer Standards and Interfaces, 609 February 2013. 611 Authors' Addresses 612 Zhiwei Yan 613 CNNIC 614 No.4 South 4th Street, Zhongguancun 615 Beijing 100190 616 China 618 Email: yan@cnnic.cn 620 Guanggang Geng 621 CNNIC 622 No.4 South 4th Street, Zhongguancun 623 Beijing 100190 624 China 626 Email: ggg@cnnic.cn 628 Jong-Hyouk Lee 629 Sangmyung University 630 31, Sangmyeongdae-gil, Dongnam-gu 631 Cheonan 632 Republic of Korea 634 Email: jonghyouk@smu.ac.kr 636 H. Anthony Chan 637 Huawei Technologies 638 5340 Legacy Dr. Building 3 639 Plano, TX 75024 640 USA 642 Email: h.a.chan@ieee.org