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

DMM Working Group                                                 Z. Yan
Internet-Draft                                                     CNNIC
Intended status: Standards Track                                  J. Lee
Expires: December 22, 2017                          Sangmyung University
                                                                 H. Chan
                                                     Huawei Technologies
                                                           June 20, 2017

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

Abstract

   Based on IPv6, multiple mobility management protocols have been
   developed and generally they can be classified into two types:
   network-based and host-based.  Different protocols have different
   functional requirements on the network element or the terminal and
   then a scheme should be used in order to support the negotiation and
   selection of adopted mobility management protocol when a terminal
   accesses to a new network.  In this draft, this issue is considered
   and 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 http://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 December 22, 2017.

Copyright Notice

   Copyright (c) 2017 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
   (http://trustee.ietf.org/license-info) in effect on the date of

Yan, et al.             Expires December 22, 2017               [Page 1]
Internet-Draft                   MCN-PS                        June 2017

   publication of this document.  Please review these documents
   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 . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Principles and possible solution  . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Based on Mobile IPv6 (MIPv6) [RFC6275], there are multiple extension
   protocols have been standardized.  These protocols can be classified
   into two categories: 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 mobile nodes with multiple access interfaces and
   Network Mobility (NEMO) [RFC3963] for mobility of sub-network.  The
   other category 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.  MIPv6 and these extensions are
   classified in the host-based mobility management protocol suite
   because the location update is initiated by the terminal and the
   tunnel is also terminated at the terminal.

   In order to reduce the protocol cost and enhance the handover
   performance further, the network-based mobility management protocols
   were proposed and Proxy Mobile IPv6 (PMIPv6) [RFC5213] was
   standardized as a basis.  Based on PMIPv6, a series of its extensions
   were proposed, such as Dual-stack Proxy Mobile IPv6 (DS-PMIPv6)
   [RFC5844], Distributed Mobility Management Proxy Mobile IPv6 (DMM-
   PMIPv6) [RFC7333] as the network-based mobility management protocol
   suite.  Be different from the host-based suite, the location update
   in network-based suite is triggered by the network entity and the

Yan, et al.             Expires December 22, 2017               [Page 2]
Internet-Draft                   MCN-PS                        June 2017

   tunnel is established between network entities.  Then the terminal
   needs to do nothing about the signaling exchange during the movement,
   particularly, the mobility is transparent to the IP layer of the
   terminal.

   In reality, these protocols will be co-existing and multiple protocol
   daemons will be configured on the network entities or terminal.  That
   means a scheme is needed to support the negotiation and selection of
   mobility management protocol when the terminal 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.

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
   terminal, a scheme is needed to support the negotiation and selection
   of adopted mobility management protocol when the terminal 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 shoud be adopted for the protocol negotiation and
      selection?

   This scheme is needed because different entity and terminal will have
   different capabilities and preferences (may be decided by the
   capability and mobility pattern of the mobile node).  This scheme can
   guarantee that the optimum and most suitable protocol will be used.

3.  Scenarios

   In order to illustrate the necessity of the mobility capability
   negotiation and protocol selection, the following scenarios are taken
   as typical examples:

   1) Network supports MIPv6, host supports only PMIPv6

   In this case, the network supports only host-based protocol, while
   the host does not have any mobility management function.  Then only
   the PMIPv6 can be used to support the mobility management of the

Yan, et al.             Expires December 22, 2017               [Page 3]
Internet-Draft                   MCN-PS                        June 2017

   host, but the network does not deploy the PMIPv6 protocol and this
   will cause the mobility failure because no available protocol can be
   used.

   2) Network supports both MIPv6 and PMIPv6, host supports only PMIPv6

   In this case, the network deploys both host-based and network-based
   protocols, while the host supports only PMIPv6.  When the host
   accesses to the network, PMIPv6 will be used.  Actually, PMIPv6
   should be adopted as a default mobility management scheme considering
   its optimized performance.  Once the PMIPv6 can be supported by the
   network, it will be adopted as the default one.

   3) Network supports both MIPv6 and PMIPv6, host supports MIPv6

   In this case, the network deploys both host-based and network-based
   protocols, and the host also supports MIPv6.  Because PMIPv6 has no
   requirement on the host, both PMIPv6 and MIPv6 can be used in this
   case.  Then the host can use PMIPv6 as default, and use MIPv6 for the
   global mobility.

   4) Network and host support multiple extension protocols

   In this case, the network has deployed multiple extensions to support
   more complex requirements, so does the host.  And then the host and
   network can negotiate a protocol for the optimized performance or
   other special requirement, for example, FMIPv6 may be selected in
   order to support fast handover, HMIPv6 may be selected in order to
   reduce the signaling cost, NEMO may be selected in order to support
   the subnet mobility.

   However, there are more complex scenarios considering the different
   abilities of network entities and terminal.

4.  Principles and possible solution

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

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

Yan, et al.             Expires December 22, 2017               [Page 4]
Internet-Draft                   MCN-PS                        June 2017

   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.

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

   2) Extended management store

   When the terminal 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.

5.  Security Considerations

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

6.  IANA Considerations

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

Yan, et al.             Expires December 22, 2017               [Page 5]
Internet-Draft                   MCN-PS                        June 2017

7.  References

7.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,
              <http://www.rfc-editor.org/info/rfc3963>.

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

   [RFC5268]  Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268,
              DOI 10.17487/RFC5268, June 2008,
              <http://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,
              <http://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, <http://www.rfc-editor.org/info/rfc5555>.

   [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, <http://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,
              <http://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, <http://www.rfc-editor.org/info/rfc6275>.

Yan, et al.             Expires December 22, 2017               [Page 6]
Internet-Draft                   MCN-PS                        June 2017

   [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,
              <http://www.rfc-editor.org/info/rfc7333>.

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

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

   Email: yan@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 December 22, 2017               [Page 7]