Mobile IPv6 Extensions (mext)                                 C. Perkins
Internet-Draft                                                   Tellabs
Intended status: Informational                               Dapeng. Liu
Expires: January 13, 2013                                   China Mobile
                                                                  W. Luo
                                                                     ZTE
                                                           July 13, 2012


                         DMM Comparison Matrix
                      draft-perkins-dmm-matrix-04

Abstract

   Distributed Mobility Management (DMM) is proposed as a way to enable
   scalable growth of mobile core networks so that network service
   providers can meet new requirements for performance and reduced
   operational expenditures.  This requires reconsideration of existing
   approaches within the IETF and elsewhere in order to determine which
   if any such approaches may be used as part of a DMM solution.

Status of This Memo

   This Internet-Draft is submitted to IETF 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 January 2, 2013.

Copyright Notice

   Copyright (c) 2012 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
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Perkins, et al.          Expires January 2, 2013                [Page 1]


Internet-Draft            DMM Comparison Matrix                July 2012


   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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Current Practice of DMM  . . . . . . . . . . . . . . . . . . .  4
   3.  Matrix Comparing Existing Approaches for DMM . . . . . . . . .  5
   4.  Explanations for Matrix Entries  . . . . . . . . . . . . . . .  6
     4.1.  Route Optimization . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Source address selection refinements . . . . . . . . . . .  7
     4.3.  Dynamically allocated home agent . . . . . . . . . . . . .  8
     4.4.  Binding updates to CN even without HA  . . . . . . . . . .  9
     4.5.  Transport protocol Mobility  . . . . . . . . . . . . . . .  9
     4.6.  Local anchor . . . . . . . . . . . . . . . . . . . . . . . 10
     4.7.  HIP/LISP . . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.8.  Distributed anchor with direct tunnel  . . . . . . . . . . 11
     4.9.  Per-Host Locators Mechanism  . . . . . . . . . . . . . . . 12
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 14

























Perkins, et al.          Expires January 2, 2013                [Page 2]


Internet-Draft            DMM Comparison Matrix                July 2012


1.  Introduction

   The goal of this document is to identify and compare known existing
   approaches for Distributed Mobility Management (DMM).
   Characterizations of each of the various methods selected for
   comparison are provided in a matrix form according to whether or not
   they meet certain criteria.

   Efforts within the IETF have been launched to find improved mobility
   management by decentralizing some or all of the traditional functions
   associated with mobility, including handovers, location management,
   identification, and so on.

   The following abbreviations appear in this document:

      MN: mobile node

      HA: home agent

      CN: correspondent node

      FQDN: Fully Qualified Domain Name

   The following approaches to mobility management are characterized:

      Route optimization (RO): MN supplies Binding Updates directly to
      CN.[RFC3775]

      Source address selection refinements (SAddrSel): MN picks source
      address appropriate for current point of attachment when launching
      an application.

      Dynamically allocated home agent (DynHA): Mobility anchor for MN
      is allocated on demand.

      Binding updates to CN even without HA (CN-wo-HA): Similar to RO,
      but does not require protocol signaling with home agent.

      Transport protocol (Trans-Mob) : MN modifies transport (e.g., TCP,
      SCTP, DCCP, MPTCP) protocol parameters to change the IP address of
      transport connection endpoint

      Local anchor (Anchor-Mob): Local mobility anchor (e.g., MAP in
      HMIP [RFC5380]) available for use by MN at its current point of
      attachment.






Perkins, et al.          Expires January 2, 2013                [Page 3]


Internet-Draft            DMM Comparison Matrix                July 2012


      Dynamic DNS (DynDNS): When MN gets a new address, DNS is updated
      so that the MN's FQDN resolves to that new address.

      Distributed anchor with direct tunnel (Dis-Anc): MN's current
      anchor can be changed dynamically depends on current location of
      MN (e.g. methods introduced in [I-D.chan-netext-distributed-lma],
      [I-D.wakikawa-mext-global-haha-spec] and
      [I-D.liu-dmm-pmip-based-approach]).  Optimized routing is realized
      by a direct tunnel between anchors of MN and its CN.

      Per-Host Locators Mechanism (Host-Loc): By using identifier-
      locator split mechanism to solve the routing above anchor level
      and enable optimal routes to the mobile node's current mobility
      anchor ([I-D.liebsch-mext-dmm-nat-phl])

   The approaches listed above will be characterized according to the
   following criteria:

   1.  scalability: in # of nodes

   2.  specified?: whether there is a working group document specifying
       the approach

   3.  IPadd continuity: provides stable IP address

   4.  backhaul friendly: reduces burden on backhaul

   5.  app friendly: apps do not require new code

   6.  server-friendly: server state minimized, servers do not require
       new code

   7.  local routing: "local breakout" / "hairpinning" / local traffic
       routed locally

   8.  low signaling: not too much signaling required







2.  Current Practice of DMM

   Currently, IETF has specified mobile IP and its variants for mobility
   managment.  Current mobile IP protocol could be deployed in a
   distributed way to best meet the requirment of DMM.



Perkins, et al.          Expires January 2, 2013                [Page 4]


Internet-Draft            DMM Comparison Matrix                July 2012


   Dynamic Anchoring approach:

   Dynamic anchoring allows the application on the mobile node always
   choose the closest anchor.  The mobility anchors could be deployed in
   a distributed way: for example, deploy the mobility anchors in the
   access router level in an IP network or in the local gateway in 3GPP
   LIPA/SIPTO network.

   Both network based and client based mobile IP solution could use the
   dynamic anchoring concept.  There are common problems that need to be
   considered for both network/client based distributed mobile IP
   deployment.  The problems include active session managment, source
   address selection, CN initiate sessio etc.

   Hierarchical mobile IP

   Hierachical mobile IP was designed to reduce the signalling overhead
   of mobile IP protocol by introducing regional mobility anchor.  The
   regional mobility anchor could also be deployed in a distributed way.
   It shares the similar problems as mobile IP in terms of session
   management, source address selection etc.

3.  Matrix Comparing Existing Approaches for DMM

   The following matrix rates the approaches described in the previous
   section according to the characteristics listed.

























Perkins, et al.          Expires January 2, 2013                [Page 5]


Internet-Draft            DMM Comparison Matrix                July 2012


               RO  SAddr DynHA  CN   Trans  Anchor DynDNS HIP/ Dis- Host
                    Sel        wo-HA  Mob    Mob    Mob   LISP Anc  -LoC

   scalability  Y    Y     M     Y     Y      M      M     Y    Y    Y

   specified?   Y    N     N     N     Y      Y      Y     Y    N    N

   IPadd        Y    N     N     Y     Y      Y      N     Y    Y    Y
   continuity

   backhaul     Y    Y     Y     Y     Y      M      Y     M    Y    Y
   friendly

   app          Y    N     Y     Y     N      Y      M    N/Y   Y    Y
   friendly

   server       M    Y     Y     Y     N      Y      Y    N/Y   Y    Y
   friendly

   local        Y    Y     M     Y     Y      N      Y     M    M    M
   routing

   low          N    Y     M     N     N      N      N     N    M    M
   signaling

        Table 1: Comparison Matrix [Legend: Y=Yes, N=No, M=Maybe]

4.  Explanations for Matrix Entries

   Most of the matrix entries are relatively self-evident.  For
   instance, "Trans Mob" (Transport-based Mobility) approaches are rated
   as not "app friendly" because applications require changes in order
   to make use of the approach.

   For approaches that are identified generically, it may be ambiguous
   whether or not they are properly specified in any working group
   document.  Here, such approaches are characterized as specified if
   any particular approach in the generic family is specified.  More
   detail may be needed in the future, in which case more columns or a
   new table may be needed.

4.1.  Route Optimization

   Mobile IPv6 supports route optimization and bi-directional tunneling.
   Using route optimization, the mobile node can send mobility
   signalling, and subsequently data packets, directly to the
   correspondent node.  The following aspects of route optimization are
   characterized in the comparison matrix.



Perkins, et al.          Expires January 2, 2013                [Page 6]


Internet-Draft            DMM Comparison Matrix                July 2012


   1.  Scalability: Using route optimization, the signalling and data do
       not have to be sent through the centralized mobility anchor.
       Since the effect of route optimization is to reduce traffic
       through the home network, scalability is improved.  Moreover,
       route optimization can reduce the effect of the home agent as a
       single point of failure.

   2.  Specified: RFC 3775 specifies the route optimization mode of
       MIPv6.

   3.  IP address continuity: In MIPv6 route optimization mode, the
       mobile node still uses the same home address as the bi-
       directional tunnel mode.  RO mode supports IP address continuity.

   4.  backhaul friendly: In RO mode, the data can send directly to the
       CN.  Data do not need to send through centralized moblity anchor,
       thence RO is backhaul friendly.

   5.  app friendly: RO mode does not require application changing, so
       it is application friendly.

   6.  server-friendly: RO mode requires the server (i.e., CN) to also
       support Mobile IP RO mode.  In this sense, RO is not server
       friendly.

   7.  local routing: In RO mode, the data is forwarded directly between
       MN and CN, it thence can support local routing.

   8.  low signaling: MIPv6 RO mode use the return routability
       procedure. which requires more signalling than MIPv6 bi-
       directional tunnel mode.

4.2.  Source address selection refinements

   Source address selection refinements (SAddrSel): MN picks source
   address appropriate for current point of attachment when launching an
   application.

   1.  Scalability: Since the MN can pick a local source address,
       packets to/from the MN do not have to traverse the home network,
       improving scalability and reducing delay.

   2.  Specified: see [RFC3484]

   3.  IP address continuity: If the MN uses a local source address, IP
       address continuity is likely to be violated when MN moves to a
       new network where that address is no longer addressable.




Perkins, et al.          Expires January 2, 2013                [Page 7]


Internet-Draft            DMM Comparison Matrix                July 2012


   4.  backhaul friendly: Since packets do not have to traverse the home
       network, this solution is more backhaul friendly.

   5.  app friendly: since applications are likely to require changes in
       order to make the address selection, this solution is less app-
       friendly.  If source addresses are selected without involvement
       of the application, this effect would be eliminated.

   6.  server-friendly: The source address selection by the application
       does not involve the server.

   7.  local routing: Using a local source address enables local routing
       for local services and communication partners.

   8.  low signaling: This solution does not impose any signaling
       signaling requirement, unless the address selection algorithm
       requires policy management by the operator.

4.3.  Dynamically allocated home agent

   Dynamically allocated home agent (DynHA): Mobility anchor for MN is
   allocated on demand.

   Scalability: If the network supports dynamically allocated home
   agents, the mobile node can choose the nearest home agent.  Other
   mobile nodes can use different home agents.  But when changing
   location, home agent may not be able to change accordingly.  The
   mechanism for associating home agents to mobile nodes can vary, and
   different algorithms have different scalability characteristics; some
   may be more scalable than others.  Method relying on anycast
   addresses for home agents are among the more scalable approaches.

   Specified: RFC 3775 specifies dynamic home agent address discovery
   and dynamic home prefix discovery.  But it does not support changing
   home agent afterwards.  If the MN selected a new home agent, it is
   likely that existing communications through the previous home agent
   would be disrupted.

   IP address continuity: When mobile node changes location, it may
   choose a new home agent, but home address would also need to change
   accordingly, making IP address continuity unlikely.

   backhaul friendly: The mobile node can choose the nearest home agent,
   in this sense, it is backhaul friendly.

   app friendly: application does not need to change to support
   dynamically allocated home agent.  So it is app friendly.




Perkins, et al.          Expires January 2, 2013                [Page 8]


Internet-Draft            DMM Comparison Matrix                July 2012


   server-friendly: server does not need to change to support
   dynamically allocated home agent, so it is server friendly.

   Local routing: When mobile node selects the nearest home agent, it
   can support local routing through that home agent.

   Low signaling: Dynamic discovery and assignment of a home agent may
   need additional signaling.

4.4.  Binding updates to CN even without HA

   Binding updates to CN even without HA (CN-wo-HA): Similar to route
   optimization, but does not require protocol signaling with home
   agent.

   1.  Scalability: yes, same as for route optimization.

   2.  Specified: Internet drafts exist, but no working group document.

   3.  IP address continuity: yes, same as for route optimization.

   4.  backhaul friendly: yes, same as for route optimization.

   5.  app friendly: yes, same as for route optimization.

   6.  server-friendly: no, same as for route optimization.

   7.  local routing: yes, same as for route optimization.

   8.  low signaling: no, same as for route optimization.

4.5.  Transport protocol Mobility

   Transport protocol (Trans-Mob): MN modifies transport (e.g., TCP,
   SCTP, DCCP, MPTCP) protocol parameters to change the IP address of
   transport connection endpoint.  In many ways, such approaches
   resemble CN-wo-HA except that the signaling occurs at a different
   layer of the protocol stack (namely, at the transport layer instead
   of the network layer).

   1.  Scalability: yes, same as for CN-wo-HA.

   2.  Specified: no, same as for CN-wo-HA.

   3.  IP address continuity: The point of such approaches is,
       basically, to eliminate the need for IP address continuity.  So,
       while IP address continuity is not provided, this should not be
       considered a demerit of transport mobility approaches.  It would



Perkins, et al.          Expires January 2, 2013                [Page 9]


Internet-Draft            DMM Comparison Matrix                July 2012


       be better to compare approaches based on "session continuity"
       instead of "IP address continuity".

   4.  backhaul friendly: yes, same as for CN-wo-HA.

   5.  app friendly: yes (typically), same as for CN-wo-HA.

   6.  server-friendly: no, same as for CN-wo-HA.

   7.  local routing: yes, same as for CN-wo-HA.

   8.  low signaling: MIPv6 RO mode use the return routability
       procedure. which requires more signalling than MIPv6 bi-
       directional tunnel mode.

4.6.  Local anchor

   Local anchor (Anchor-Mob): Local mobility anchor (e.g., MAP in HMIP
   [RFC5380]) available for use by MN at its current point of
   attachment.

   1.  Scalability: The mobile node signals the nearest anchor.  MNs in
       other networks can use different anchors.  Scalability is
       improved because the signaling path between the mobile node and
       its local anchor is shorter.  Moreover, local mobility anchors
       offload work from any remote mobility anchor such as the home
       agent.

   2.  Specified: HMIP[RFC5380]

   3.  IP address continuity: In conjunction with Mobile IPv6 as a macro
       mobility protocol, IP address continuity is enabled.

   4.  backhaul friendly: The mobile node can choose the nearest local
       anchor; in this sense, it is backhaul friendly.

   5.  app friendly: application does not need to change to support
       dynamically allocated home agent.  So it is app friendly.

   6.  server-friendly: server does not need to change to support local
       mobility anchor, so it is server friendly.

   7.  Local routing: Generally, the use of a local anchor does not
       necessarily improve local routing; additional functionality would
       need to be designed or included with the local anchor.

   8.  Low signaling: Additional signaling is required for the mobile
       node to insert new bindings at the local anchor.



Perkins, et al.          Expires January 2, 2013               [Page 10]


Internet-Draft            DMM Comparison Matrix                July 2012


4.7.  HIP/LISP

   HIP: Host Identity Protocol(RFC 4423); LISP: Locator/ID Separation
   Protocol.

   1.  Scalability: HIP/LISP are both location/indentification
       separation protocol.  Both HIP/LISP can support large scale
       deployment in HIP/LISP domain.  But when a node running HIP/LISP
       needs to communicate with other hosts that are not located in the
       HIP/LISP domain, another mechanism is needed.

   2.  HIP is specified in RFC 4423[RFC5380].  LISP is specified in
       [I-D.ietf-lisp].

   3.  IP address continuity: HIP/LISP both use host indentification for
       addressing.  The host can use a stable IP address for
       identification and addressing, thence HIP/LISP can support IP
       address continuity.

   4.  backhaul friendly: HIP/LISP both use routing address for packet
       routing; there is no centralized anchor point in the data plane.
       But for communication to other hosts which are not located in the
       HIP/LISP domain, a gateway function is needed and the data
       traffic is constrained to travel through the gateway.

   5.  app friendly: LISP does not require application modification.
       HIP may require application modification [RFC 6317].

   6.  server-friendly: For mobile nodes, HIP may require server
       modifications; LISP does not require server modification.

   7.  Local routing: For communication within the HIP/LISP domain, HIP/
       LISP can support local routing since the routing is based on
       routing prefix instead of host indentification and there is no
       cent

   8.  ralized anchor point.

   9.  Low signaling: HIP/LISP need new signaling in the host/network to
       support its function.

4.8.  Distributed anchor with direct tunnel

   1.  Scalability: Mobile node's home network contains its first anchor
       when MN is initialized.  When MN moves to a visit network, it can
       change its mobility anchor to a new anchor point which is located
       in this visit network.  The traffic will not go through mobile
       node's home network when it is in visit network.  No centralized



Perkins, et al.          Expires January 2, 2013               [Page 11]


Internet-Draft            DMM Comparison Matrix                July 2012


       mobility anchor is needed and scalability is improved.  Besides,
       dynamically allocated mobility anchor mechanism can also be
       applied when mobile node is initialized in its home network.

   2.  Specified: Internet drafts exist, but no working group document.

   3.  IP address continuity: All mechanisms introduced in
       [I-D.chan-netext-distributed-lma],
       [I-D.wakikawa-mext-global-haha-spec] and
       [I-D.liu-dmm-pmip-based-approach] are claimed to support IP
       address continuity.  I.e. additional mechanisms are used to
       guarantee that mobile node can keeps its HoA unchanged even its
       mobility anchor is changed.

   4.  Backhaul friendly: Mobile node can change it mobility anchor to a
       best anchor point (e.g. a nearest anchor point) and packets do
       not have to traverse the home network, this solution is more
       backhaul friendly.

   5.  App friendly: Does not require application changing.  Socket of
       application is always binded to mobile node's HoA, so it is
       application friendly.

   6.  Server-friendly: Does not require server changing, so it is
       server friendly.

   7.  Local routing: Packets from mobile node to its correspondent node
       shall go though mobile node's current mobility anchor.  If the
       mobility anchor is mobile node's first router, then local routing
       is supported.

   8.  Low signaling: Additional signaling is needed for supporting
       location management approaches and handoff approaches.  It can be
       excepted that number of signaling may increase with growth of
       mobile node's number.  It depends on the specific design.

4.9.  Per-Host Locators Mechanism

   1.  Scalability: As claimed in [I-D.liebsch-mext-dmm-nat-phl], mobile
       node are supported to change its current mobility anchor, i.e.
       when mobile node is not at home, packet will not go through its
       home network which is similar with Dis-Anc.  So it is Yes.

   2.  Specified: Internet drafts exist, but no working group document.

   3.  IP address continuity: Mobile node can keep its HoA unchanged, so
       IP address continuity is guaranteed.  How to guarantee limited
       packet loss rate when mobile node changes its current anchor



Perkins, et al.          Expires January 2, 2013               [Page 12]


Internet-Draft            DMM Comparison Matrix                July 2012


       point is not very clear now.

   4.  Backhaul friendly: Yes. The reason is same as Dis-Anc.

   5.  App friendly: Yes. The reason is same as Dis-Anc.

   6.  Server-friendly: Yes. The reason is same as Dis-Anc.

   7.  Local routing: Maybe.  The reason is same as Dis-Anc.

   8.  Low signaling: The mechanism is based on NAT to guarantee per-
       host locators.  How to guarantee the synchronization of NAT
       status is un-clear now.  But it can be excepted that additional
       signaling is necessary.

5.  Security Considerations

   This document does not have any security considerations.

6.  IANA Considerations

   This document does not have any IANA actions.







7.  References

7.1.  Normative References

   [I-D.ietf-lisp]                       Farinacci, D., Fuller, V.,
                                         Meyer, D., and D. Lewis,
                                         "Locator/ID Separation Protocol
                                         (LISP)", draft-ietf-lisp-23
                                         (work in progress), May 2012.

   [RFC3484]                             Draves, R., "Default Address
                                         Selection for Internet Protocol
                                         version 6 (IPv6)", RFC 3484,
                                         February 2003.

   [RFC3775]                             Johnson, D., Perkins, C., and
                                         J. Arkko, "Mobility Support in
                                         IPv6", RFC 3775, June 2004.




Perkins, et al.          Expires January 2, 2013               [Page 13]


Internet-Draft            DMM Comparison Matrix                July 2012


   [RFC4423]                             Moskowitz, R. and P. Nikander,
                                         "Host Identity Protocol (HIP)
                                         Architecture", RFC 4423,
                                         May 2006.

   [RFC5380]                             Soliman, H., Castelluccia, C.,
                                         ElMalki, K., and L. Bellier,
                                         "Hierarchical Mobile IPv6
                                         (HMIPv6) Mobility Management",
                                         RFC 5380, October 2008.

7.2.  Informative References

   [I-D.chan-netext-distributed-lma]     Chan, H., Xia, F., Xiang, J.,
                                         and H. Ahmed, "Distributed
                                         Local Mobility Anchors",  draft
                                         -chan-netext-distributed-lma-
                                         03, March 2010.

   [I-D.wakikawa-mext-global-haha-spec]  Wakikawa , R., Kuntz, R., Zhu,
                                         Z., and L. Zhang, "Global HA to
                                         HA Protocol Specification",  dr
                                         aft-wakikawa-mext-global-haha-
                                         spec-02, September 2011.

   [I-D.liu-dmm-pmip-based-approach]     Liu, D., Song, J., and W. Luo,
                                         "PMIP Based Distributed
                                         Mobility Management Approach",
                                          draft-liu-dmm-pmip-based-
                                         approach-01, December 2011.

   [I-D.liebsch-mext-dmm-nat-phl]        Liebsch , M., "Per-Host
                                         Locators for Distributed
                                         Mobility Management",  draft-
                                         liebsch-mext-dmm-nat-phl-00,
                                         October 2011.

Appendix A.  Acknowledgements

   This document has benefitted from discussions with the following
   people, in no particular order: Seok Joo Koh, Jouni Korhonen, Julien
   Laganier, Dapeng Liu, Telemaco Melia, Pierrick Seite









Perkins, et al.          Expires January 2, 2013               [Page 14]


Internet-Draft            DMM Comparison Matrix                July 2012


Authors' Addresses

   Charles E. Perkins
   Tellabs

   Phone: +1-408-421-1172
   EMail: charliep@computer.org


   Dapeng Liu
   China Mobile

   Phone: +86-139-117-88933
   EMail: liudapeng@chinamobile.com


   Wen Luo
   ZTE

   Phone:
   EMail: luo.wen@zte.com.cn






























Perkins, et al.          Expires January 2, 2013               [Page 15]