DMM Working Group                                                 Z. Yan
Internet-Draft                                                   G. Geng
Intended status: Standards Track                                   CNNIC
Expires: March 22, 2020                                           J. Lee
                                                    Sangmyung University
                                                                 H. Chan
                                                     Huawei Technologies
                                                      September 19, 2019


         Mobility Capability Negotiation and Protocol Selection
                          draft-yan-dmm-man-05

Abstract

   Based on different requirements, multiple mobility management
   protocols have been developed.  Different protocols have different
   functional requirements on the network element or the host and then a
   scheme should be used in order to support the negotiation and
   selection of adopted mobility management protocol when a host
   accesses to a new network.  In this draft, this issue is analyzed.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on March 22, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Yan, et al.              Expires March 22, 2020                 [Page 1]


Internet-Draft                   MCN-PS                   September 2019


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Motivations . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Possible Cases  . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Principles and Possible Procedure . . . . . . . . . . . . . .   9
   5.  Extensions  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   In order to clearly analyze the possible cases, the following
   category labels of the mobility management protocols are defined:

   o  Mobile IPv6 (MIPv6) protocol: the mobility management scheme based
      on [RFC6275].
   o  Proxy Mobile IPv6 (PMIPv6) protocol: the mobility management
      scheme based on [RFC5213].
   o  MIPv6 suit protocols: based on MIPv6, there are multiple extension
      protocols have been standardized.  These protocols can be
      classified into two types: protocols for the function extension
      and protocols for the performance enhancement.  The protocols for
      the function extension are proposed to support some specific
      scenarios or functions, such as Dual-stack Mobile IPv6 (DSMIPv6)
      [RFC5555] for mobility of the dual-stack nodes, Multiple Care-of-
      address (MCoA) [RFC5648] for hosts with multiple access interfaces
      and Network Mobility (NEMO) [RFC3963] for mobility of sub-network.
      The other type is proposed to enhance the performance of the
      mobility management, such as Fast Mobile IPv6 (FMIP6) [RFC5268]
      for fast handover, Hierarchical Mobile IPv6 (HMIPv6) [RFC5380] for
      hierarchical mobility optimization.  In the MIPv6 suit protocols,
      location update is initiated by the host and the tunnel is also
      terminated at the host.
   o  PMIPv6 suit protocols: in order to reduce the protocol cost and
      enhance the handover performance further, the network-based
      mobility management protocols were proposed and PMIPv6 was
      standardized as a basis.  Based on PMIPv6, a series of its



Yan, et al.              Expires March 22, 2020                 [Page 2]


Internet-Draft                   MCN-PS                   September 2019


      extensions were proposed, such as Dual-stack Proxy Mobile IPv6
      (DS-PMIPv6) [RFC5844], and Distributed Mobility Management Proxy
      Mobile IPv6 (DMM-PMIPv6) [RFC7333].  Be different from the MIPv6
      suit protocols, the location update in PMIPv6 suit protocols is
      triggered by the network entity and the tunnel is established
      between network entities.  Then the host needs to do nothing about
      the signaling exchange during the movement, particularly, the
      mobility is transparent to the IP layer of the host.
   o  Network-based protocols: generally, it means the mobility
      management protocols which do not require the involvement of the
      mobile node in order to accomplish mobility.  It includes PMIPv6
      suit protocols and other network-based solutions, such as GPRS
      Tunnelling Protocol (GTP) [TS.29274][TS.29281].
   o  Host-based protocols: generally, the mobility management protocols
      which require the involvement of the mobile node in order to
      accomplish mobility.  It includes MIPv6 suit protocols and other
      host-based solutions, such as Host Identity Protocol (HIP)
      [RFC7401] and IKEv2 Mobility and Multihoming Protocol (MOBIKE)
      [RFC4555].

   Figure 1 illustrates the scopes of the above different category
   labels.

       +----------------+        +----------------+
       | Network-based  |        | Host-based     |
       |+--------------+|        |+--------------+|
       ||PMIPv6 suit   ||        ||MIPv6 suit    ||
       ||+------------+||        ||+------------+||
       |||PMIPv6      |||        |||MIPv6       |||
       ||+------------+||        ||+------------+||
       |+--------------+|        |+--------------+|
       +----------------+        +----------------+

          Figure 1: Scopes of different protocol category labels

   In reality, the host-based protocols and network-based protocols will
   be co-existing and multiple protocol deamons will be configured on
   the network entities or host.  That means a scheme is needed to
   support the negotiation and selection of mobility management protocol
   when the host accesses into a new access network initially or
   handover happens [Paper-CombiningMobilityStandards].

   This document tries to present the principles for the protocol
   selection and analyze the possible scenarios which should be
   supported by the further solution.






Yan, et al.              Expires March 22, 2020                 [Page 3]


Internet-Draft                   MCN-PS                   September 2019


2.  Motivations

   As illustrated above, these protocols may co-exist in reality and
   simultaneously be used in an access network or even the same entity.
   Due to their different requirements on the network entity or host, a
   scheme is needed to support the negotiation and selection of adopted
   mobility management protocol when the host accesses to a new network.
   Generally, two problems should be solved:

   o  What principles should be followed for the protocol negotiation
      and selection?
   o  What procedure should be adopted for the protocol negotiation and
      selection?

   This scheme is needed because network entity and host may have
   different capabilities and preferences (may be decided by the
   capability and mobility pattern of the host).  This scheme aims to
   guarantee that the optimum and most suitable protocol will be used.

3.  Possible Cases

   From both host and network aspects, their capacities of mobility
   management may have multiple cases as shown in Figure 2.  We mainly
   analyze that host and network support single protocol, if multiple
   protocols are supported simultaneously by the host or network side,
   multiple cases exist at the same time but the logic is same as that
   in the case with single protocol supported.  Specifically, the
   following cases should be considered.

   1) Network supports network-based protocol, host supports network-
   based protocol

   In this case, there are the following sub-cases:

   a) Host supports PMIPv6 suit protocol, Network supports PMIPv6 suit
   protocol

   o  if host supports PMIPv6 and network supports PMIPv6, PMIPv6 is
      selected.
   o  if host supports PMIPv6 and network supports extended PMIPv6
      protocol, extended PMIPv6 protocol is selected if no host
      involvement is needed, otherwise the plain PMIPv6 is selected (we
      assume that the extension protocols are backward-compatible with
      the related plain protocol).
   o  if host supports extended PMIPv6 protocol and network supports
      PMIPv6, PMIPv6 is selected (we assume that the extension protocols
      are backward-compatible with the related plain protocol).




Yan, et al.              Expires March 22, 2020                 [Page 4]


Internet-Draft                   MCN-PS                   September 2019


   o  if host supports extended PMIPv6 protocol and network supports
      extended PMIPv6 protocol, the identical extension protocol is
      selected, otherwise, PMIPv6 is selected (we assume that the
      extension protocols are backward-compatible with the related plain
      protocol).

       +-------------+-----------+--------------------------- +
       |             |           |PMIPv6                      |
       |             |           |-----------------+----------+
       |Network-based|PMIPv6 suit|                 |DS-PMIPv6 |
       |             |           |                 +----------+
       |             |           |PMIPv6 extensions|FPMIPv6   |
       |             |           |                 +----------+
       |             |           |                 |DMM-PMIPv6|
       |             |           |                 +----------+
       |             |           |                 |...       |
       |             |-----------+-----------------+----------+
       |             | Others    |GTP                         |
       |             |           |----------------------------+
       |             |           |...                         |
       +-------------+-----------+----------------------------+
       |             |           |MIPv6                       |
       |             |           |-----------------+----------+
       |Host-based   |MIPv6 suit |                 |DS-MIPv6  |
       |             |           |                 +----------+
       |             |           |                 |FMIPv6    |
       |             |           |                 +----------+
       |             |           |MIPv6 extensions |HMIPv6    |
       |             |           |                 +----------+
       |             |           |                 |NEMO      |
       |             |           |                 +----------+
       |             |           |                 |DMM-MIPv6 |
       |             |           |                 +----------+
       |             |           |                 |...       |
       |             |-----------+-----------------+----------+
       |             | Others    |HIP                         |
       |             |           |----------------------------+
       |             |           |MOBIKE                      |
       |             |           |----------------------------+
       |             |           |...                         |
       +-------------+-----------+----------------------------+

             Figure 2: Possible capacities of host and network

   b) Host supports PMIPv6 suit protocol, Network supports other
   network-based protocol





Yan, et al.              Expires March 22, 2020                 [Page 5]


Internet-Draft                   MCN-PS                   September 2019


   o  if host supports PMIPv6 and network supports other network-based
      protocol, other network-based protocol is selected if no host
      involvement is needed, otherwise failure.
   o  if host supports extended PMIPv6 protocol and network supports
      other network-based protocol, other network-based protocol is
      selected if no host involvement is needed, otherwise failure.

   c) Host supports other network-based protocol, Network supports
   PMIPv6 suit protocol

   o  if host supports other network-based protocol and network supports
      PMIPv6, PMIPv6 is selected.
   o  if host supports other network-based protocol and network supports
      extended PMIPv6 protocol, extended PMIPv6 protocol is selected if
      no host involvement is needed, otherwise failure.

   d) Host supports other network-based protocol, Network supports other
   network-based protocol

   o  the identical protocol is selected, otherwise follow network
      capability if the protocols are different.

   2) Network supports network-based protocol, host supports host-based
   protocol

   In this case, there are the following sub-cases:

   a) Host supports PMIPv6 suit protocol, Network supports MIPv6 suit
   protocol

   o  if host supports PMIPv6 and network supports MIPv6, failure.
   o  if host supports PMIPv6 and network supports extended MIPv6
      protocol, failure.
   o  if host supports extended PMIPv6 protocol and network supports
      MIPv6, failure.
   o  if host supports extended PMIPv6 protocol and network supports
      extended MIPv6 protocol, failure.

   b) Host supports PMIPv6 suit protocol, Network supports other host-
   based protocol

   o  if host supports PMIPv6 and network supports other host-based
      protocol, failure.
   o  if host supports extended PMIPv6 protocol and network supports
      other host-based protocol, failure.

   c) Host supports other network-based protocol, Network supports MIPv6
   suit protocol



Yan, et al.              Expires March 22, 2020                 [Page 6]


Internet-Draft                   MCN-PS                   September 2019


   o  if host supports other network-based protocol and network supports
      MIPv6, failure.
   o  if host supports other network-based protocol and network supports
      extended MIPv6 protocol, failure.

   d) Host supports other network-based protocol, Network supports other
   host-based protocol

   o  failure.

   3) Network supports host-based protocol, host supports network-based
   protocol

   In this case, there are the following sub-cases:

   a) Host supports MIPv6 suit protocol, Network supports PMIPv6 suit
   protocol

   o  if host supports MIPv6 and network supports PMIPv6, PMIPv6 is
      selected in default and MIPv6 is selected if host prefers it.
   o  if host supports MIPv6 and network supports extended PMIPv6
      protocol, extended PMIPv6 is selected in default, then PMIPv6 is
      selected with the lower priority and MIPv6 is selected if host
      prefers it.
   o  if host supports extended MIPv6 protocol and network supports
      PMIPv6, PMIPv6 is selected in default, then extended MIPv6
      protocol is selected if host prefers it and network also supports,
      otherwise MIPv6 is selected with the lowest priority.
   o  if host supports extended MIPv6 protocol and network supports
      extended PMIPv6 protocol, extended PMIPv6 protocol is selected in
      default, then PMIPv6 is selected, then extended MIPv6 protocol is
      selected if host prefers and network also supports, otherwise
      MIPv6 is selected with the lowest priority.

   b) Host supports MIPv6 suit protocol, Network supports other network-
   based protocol

   o  if host supports MIPv6 and network supports other network-based
      protocol, other network-based protocol is selected if no host
      involvement is needed, otherwise failure.
   o  if host supports extended MIPv6 protocol and network supports
      other network-based protocol, other network-based protocol is
      selected if no host involvement is needed, otherwise failure.

   c) Host supports other host-based protocol, Network supports PMIPv6
   suit protocol





Yan, et al.              Expires March 22, 2020                 [Page 7]


Internet-Draft                   MCN-PS                   September 2019


   o  if host supports other host-based protocol and network supports
      PMIPv6, PMIPv6 is selected in default, otherwise failure.
   o  if host supports other host-based protocol and network supports
      extended PMIPv6 protocol, extended PMIPv6 protocol is selected if
      no host involvement is needed, otherwise failure.

   d) Host supports other host-based protocol, Network supports other
   network-based protocol

   o  other network-based protocol is selected if no host involvement is
      needed, otherwise failure.

   4) Network supports host-based protocol, host supports host-based
   protocol

   In this case, there are the following sub-cases:

   a) Host supports MIPv6 suit protocol, Network supports MIPv6 suit
   protocol

   o  if host supports MIPv6 and network supports MIPv6, MIPv6 is
      selected.
   o  if host supports MIPv6 and network supports extended MIPv6
      protocol, MIPv6 is selected.
   o  if host supports extended MIPv6 protocol and network supports
      MIPv6, MIPv6 is selected.
   o  if host supports extended MIPv6 protocol and network supports
      extended MIPv6 protocol, the identical protocol is selected,
      otherwise MIPv6 is selected.

   b) Host supports MIPv6 suit protocol, Network supports other host-
   based protocol

   o  if host supports MIPv6 and network supports other host-based
      protocol, failure.
   o  if host supports extended MIPv6 protocol and network supports
      other host-based protocol, failure.

   c) Host supports other host-based protocol, Network supports MIPv6
   suit protocol

   o  if host supports other host-based protocol and network supports
      MIPv6, failure.
   o  if host supports other host-based protocol and network supports
      extended MIPv6 protocol, failure.

   d) Host supports other host-based protocol, Network supports other
   host-based protocol



Yan, et al.              Expires March 22, 2020                 [Page 8]


Internet-Draft                   MCN-PS                   September 2019


   o  the identical other host-based protocol is selected, otherwise
      failure.

   5) Network supports host-based protocol and network-based protocol,
   host supports host-based protocol and network-based protocol

   o  follow the network based protocol in default if the host can
      support, otherwise select the protocol both network and host can
      support if host prefers.

4.  Principles and Possible Procedure

   Two different schemes may be used for the protocol negotiation and
   selection: host-initiated and network-initiated.  Within the MIPv6/
   PMIPv6 protocols, the priority of the function-extension protocols
   should be higher than the performance-enhancement protocols.
   Generally, the following principles should be followed:

   o  In default: Network based scheme if it can be supported
   o  Priority 1: Follow network capability
   o  Priority 2: Follow host preference
   o  Priority 3: Support the functional extensions
   o  Priority 4: Support the performance enhancements

   And the general procedure for the protocol selection should be:

   o  During initiation, network-based protocol may be used as a default
      mobility management protocol once the network supports it.
   o  If the host prefers host-based protocols, a negotiation is
      executed to handover from network-based protocol to host-based
      protocol.
   o  After initial attachment, a profile will be generated in the
      management store to record the selected or preferred protocol of
      this host.
   o  When the handover happens, the network will check the selected or
      preferred protocol during the authentication process.  But the
      network also needs to notify the host if the selected protocol
      cannot be supported herein.

5.  Extensions

   In order to fulfill the above principles, some extensions should be
   supported, for example:

   1) Extended negotiation messages

   The protocol negotiation may be included in the MN_ATTACH Function
   [MN-AR.IF] and the implementation may be based on a new signaling



Yan, et al.              Expires March 22, 2020                 [Page 9]


Internet-Draft                   MCN-PS                   September 2019


   message or extended messages (e.g., ICMPv6, Diameter, and RADIUS).
   Besides these, some other protocols may also be used in some
   specified scenarios, such as extended IEEE 802.21 primitives.

   As a possible solution, a new option under ICMPv6 is proposed in this
   draft in order to support the protocol negotiation when the mobile
   terminal initially accesses the network or hands over to a different
   network.  In the RA and Router Solicitation (RS) message headers, a
   one-bit flag (C) is used to illustrate that mobility capability
   negotiation is needed and a Mobility Capability (MC) option is
   included in the message body.  The format of MC option is shown in
   Figure 3.

       0         78       1516      2324       31
       +---------+---------+---------+---------+
       | Type    | Length  |   p     |Reserved |
       +---------------------------------------+
       | Protocol 1        |   ......          |
       +---------------------------------------+
       | Protocol p        |   Protocol p+1    |
       +---------------------------------------+
       | ......            |   Protocol s      |
       +---------------------------------------+

            Figure 3: The format of Mobility Capability option

   "Type" indicates that this option is of the type Mobility Capability.
   "p" is the number of preferred protocols.  "Protocol 1" to "Protocol
   s" is a list of s supported protocols, which can be selected.  Out of
   the s supported protocols, the first p protocols are ones preferred
   by the network and the terminal, listed in the order of preference,
   whereas no preference is indicated in the remaining protocols from
   p+1 to s.  How to code the protocol types with the 16-bit space is
   implementation-depended.

   "Length" is the number of octets in this option excluding option type
   and option length, and it can be seen that Length = 2x(s+1).

   "Reserved" is for future use.

   It is noted that when p = 0, preference is not indicated in the
   entire list of supported protocols, and when p = s, preference is
   indicated in all the supported protocols.

   Based on this extension, when the mobile terminal receives the RA
   message with the "C" flag set to 1 and "p" in MC option is at least
   one, it means that the access network has selected the first
   supported protocol (protocol 1) as the default protocol for the



Yan, et al.              Expires March 22, 2020                [Page 10]


Internet-Draft                   MCN-PS                   September 2019


   terminal.  Based on the previous principles, the terminal should
   follow this selected protocol if it is able to.  If the terminal is
   not capable to use the first supported protocol, it will use the
   second supported protocol (protocol 2) if it is able to.  If it is
   still not capable of using the second supported protocol, it will try
   the third one and so on.

   If the terminal is not capable of using any of the p supported
   protocols, it will try to use any of the remaining protocols.  When
   the mobile terminal receives the RA message with the "C" flag set to
   1 and "Preferred protocol" in MC option is null, it means that the
   access network has not selected the default protocol for the terminal
   but illustratesed to the terminal about the supported protocols from
   the network side.  Then based on the previous principles, the
   terminal should select one protocol and notify it to the network with
   the MC option in RS message.  The network should acknowledge it with
   a new re-formatted RA message.  In this new RA message, the protocol
   selected by terminal is included in the "Preferred protocol" of MC
   option.  After the choice has been made, the terminal may inform the
   network of the choice by sending a message with MC option in which p
   = s = 1, and the protocol field is the selected protocol.

   When the network receives the RS message with the "C" flag set to 1
   and "p" in MC option is zero, it means that the terminal only lists
   its supported mobility management protocols but does not have any
   preference.  The network will then select one based on the principles
   and notify the selected protocol to the terminal with a RA message
   containing the MC option in which p=1 and "protocol 1" is the
   selected protocol.

   When the network receives the RS message with the "C" flag set to 1
   and "p" in MC option is at least one, it means that the terminal
   tries to negotiate the mobility management protocol and has included
   the preferred protocols listed in the order of preference.  The
   network will try one by one to select from protocol 1 to protocol p
   until it has find one it supports.  If the network is not capable of
   supporting all the p protocols, it will try the remaining s-p
   protocols.

   2) Extended management store

   When the host accesses to the network, an authentication should be
   executed before the mobility management service is provided.  In
   order to support the mobility management protocol selection, a new
   information should be recorded by the network after the successful
   authentication during the initial attachment.  The newly introduced
   information shows the selected mobility management protocol and
   should be updated when the used protocol changes.



Yan, et al.              Expires March 22, 2020                [Page 11]


Internet-Draft                   MCN-PS                   September 2019


6.  Security Considerations

   Generally, this function will not incur additional security issues.
   The detailed influence should be analyzed in the future.

7.  IANA Considerations

   A new ICMP option or authentication option or other signaling message
   may be used with a new code number.

8.  References

8.1.  Normative References

   [MN-AR.IF]
              Laganier, J., Narayanan, S., and P. McCann, "Interface
              between a Proxy MIPv6 Mobility Access Gateway and a Mobile
              Node",  draft-ietf-netlmm-mn-ar-if-03, February 2008.

   [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
              Thubert, "Network Mobility (NEMO) Basic Support Protocol",
              RFC 3963, DOI 10.17487/RFC3963, January 2005,
              <https://www.rfc-editor.org/info/rfc3963>.

   [RFC4555]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol
              (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,
              <https://www.rfc-editor.org/info/rfc4555>.

   [RFC5213]  Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
              Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
              RFC 5213, DOI 10.17487/RFC5213, August 2008,
              <https://www.rfc-editor.org/info/rfc5213>.

   [RFC5268]  Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268,
              DOI 10.17487/RFC5268, June 2008,
              <https://www.rfc-editor.org/info/rfc5268>.

   [RFC5380]  Soliman, H., Castelluccia, C., ElMalki, K., and L.
              Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
              Management", RFC 5380, DOI 10.17487/RFC5380, October 2008,
              <https://www.rfc-editor.org/info/rfc5380>.

   [RFC5555]  Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack
              Hosts and Routers", RFC 5555, DOI 10.17487/RFC5555, June
              2009, <https://www.rfc-editor.org/info/rfc5555>.






Yan, et al.              Expires March 22, 2020                [Page 12]


Internet-Draft                   MCN-PS                   September 2019


   [RFC5648]  Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G., Ernst,
              T., and K. Nagami, "Multiple Care-of Addresses
              Registration", RFC 5648, DOI 10.17487/RFC5648, October
              2009, <https://www.rfc-editor.org/info/rfc5648>.

   [RFC5844]  Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010,
              <https://www.rfc-editor.org/info/rfc5844>.

   [RFC6275]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
              Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
              2011, <https://www.rfc-editor.org/info/rfc6275>.

   [RFC7333]  Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J.
              Korhonen, "Requirements for Distributed Mobility
              Management", RFC 7333, DOI 10.17487/RFC7333, August 2014,
              <https://www.rfc-editor.org/info/rfc7333>.

   [RFC7401]  Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
              Henderson, "Host Identity Protocol Version 2 (HIPv2)",
              RFC 7401, DOI 10.17487/RFC7401, April 2015,
              <https://www.rfc-editor.org/info/rfc7401>.

   [TS.29274]
              "3GPP Evolved Packet System (EPS); Evolved General Packet
              Radio Service (GPRS) Tunnelling Protocol for Control plane
              (GTPv2-C); Stage 3",  3GPP TS 29.274 8.10.0, June 2011.

   [TS.29281]
              "General Packet Radio System (GPRS) Tunnelling Protocol
              User Plane (GTPv1-U)",  3GPP TS 29.281 10.3.0, September
              2011.

8.2.  Informative References

   [Paper-CombiningMobilityStandards]
              Oliva, A., Soto, I., Calderon, M., Bernardos, C., and M.
              Sanchez, "The costs and benefits of combining different IP
              mobility standards",  Computer Standards and Interfaces,
              February 2013.

Authors' Addresses









Yan, et al.              Expires March 22, 2020                [Page 13]


Internet-Draft                   MCN-PS                   September 2019


   Zhiwei Yan
   CNNIC
   No.4 South 4th Street, Zhongguancun
   Beijing  100190
   China

   Email: yan@cnnic.cn


   Guanggang Geng
   CNNIC
   No.4 South 4th Street, Zhongguancun
   Beijing  100190
   China

   Email: ggg@cnnic.cn


   Jong-Hyouk Lee
   Sangmyung University
   31, Sangmyeongdae-gil, Dongnam-gu
   Cheonan
   Republic of Korea

   Email: jonghyouk@smu.ac.kr


   H. Anthony Chan
   Huawei Technologies
   5340 Legacy Dr. Building 3
   Plano, TX 75024
   USA

   Email: h.a.chan@ieee.org

















Yan, et al.              Expires March 22, 2020                [Page 14]