NETEXT Working Group                                       CJ. Bernardos
Internet-Draft                                                      UC3M
Intended status: Informational                          October 16, 2009
Expires: April 19, 2010


             PMIPv6 and Network Mobility Problem Statement
                draft-bernardos-netext-pmipv6-nemo-ps-00

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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 19, 2010.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   The NETLMM WG standardized Proxy Mobile IPv6 (PMIPv6).  PMIPv6
   enables mobile devices to connect to a PMIPv6 domain and roam across
   gateways without changing the IP address.



Bernardos                Expires April 19, 2010                 [Page 1]


Internet-Draft              PMIPv6 & NEMO PS                October 2009


   Current PMIPv6 specification does only support the movement of hosts
   within the localized mobility domain.  A mobile network (commonly
   referred to as NEMO, NEtwork that MOves) can also benefit from the
   network-based localized mobility support provided by PMIPv6, but in a
   very limited way.  This I-D describes what can be done with current
   standardized protocols and describes the problem statement of fully
   supporting network mobility in Proxy Mobile IPv6.

   The goal of this document is to present the problem -- and the use
   cases where this problem is relevant to be solved -- to collect
   feedback from the community about the interest on working on this
   problem.


Table of Contents

   1.  Introduction and Motivation . . . . . . . . . . . . . . . . . . 3
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . . . 3
   3.  PMIPv6 and Network  Mobility Problem Statement  . . . . . . . . 4
     3.1.  Applicability of existing standards . . . . . . . . . . . . 5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
























Bernardos                Expires April 19, 2010                 [Page 2]


Internet-Draft              PMIPv6 & NEMO PS                October 2009


1.  Introduction and Motivation

   Proxy Mobile IPv6 (PMIPv6), specified in [RFC5213], provides network
   based mobility management to hosts connecting to a PMIPv6 domain.
   PMIPv6 introduces two new functional entities, the Local Mobility
   Anchor (LMA) and the Mobility Access Gateway (MAG).  The MAG is the
   first layer three hop detecting Mobile Node (MN) attachment and
   providing IP connectivity.  The LMA is the entity assigning one or
   more Home Network Prefixes (HNPs) to the MN and is the topological
   anchor for all traffic from/to the MN.

   The network-based localized mobility support provided by PMIPv6 was
   designed for hosts, so a mobile host can freely roam within the
   PMIPv6 domain, without changing its IP address.  An interesting
   scenario -- which is not supported by current standards (as we will
   explain later in this document) -- is the following: let consider a
   scenario in which users move around a large area (e.g., an airport,
   an exhibition site, a fairground or even a metropolitan area covered
   by different public transportation systems).  In these areas,
   attachment points to the Internet might be available both in fixed
   locations (such as coffee shops, airport terminals or train stations)
   or in mobile platforms, such as vehicles (e.g., buses that move
   between pavilions at a fair or a train that moves from one terminal
   to another at an airport).  Users demand the ability to keep their
   ongoing communications while changing their point of attachment to
   the network as they move around (e.g., when a user leaves a coffee
   shop and gets on a bus).

   While PMIPv6 [RFC5213] is the solution specified to provide network-
   based localized mobility support (which nicely fits the requirements
   related to providing Internet access in a large area), and the NEMO
   Basic Support Protocol [RFC3963] is the solution to provide
   transparent network mobility support to a set of nodes moving
   together, these two solutions cannot fully cope -- neither working
   standalone nor in a combined fashion -- with the kind of use case
   introduced above.  We need therefore a solution -- which may be for
   example based on extending NEMO mechanisms, extending PMIPv6 or both
   -- to address this scenario.  We next explain with a bit more of
   detail the problem statement of combining PMIPv6 with network
   mobility support and explain why current IETF standards are not able
   to tackle this problem.


2.  Conventions and Terminology

   Readers are expected to be familiar with all the terms defined in
   [RFC5213], [RFC3753] and [RFC4885].  In addition, the following terms
   are used in the context of this problem statement:



Bernardos                Expires April 19, 2010                 [Page 3]


Internet-Draft              PMIPv6 & NEMO PS                October 2009


   MR/MAG

      We use this term to refer to the router providing connectivity to
      a set of nodes moving together.  We do not use the term Mobile
      Router (MR) to avoid confusion with its well accepted meaning in
      the context of the NEMO Basic Support protocol (i.e. we do not
      assume nor prevent the MR/MAG to implement the MR functionality
      specified in [RFC3963]).  Analogously, since the nodes attached to
      the MR/MAG are expected to obtain network-based localized mobility
      support, it might be tempting to refer to this entity as a MAG,
      but a RFC 5213 MAG cannot move (i.e. change its point of
      attachment within the PMIPv6 domain).

   Network Mobility

      Within the scope of this document, we refer to network mobility as
      the capacity of a set of nodes -- attached to an MR/MAG -- to move
      together _within_ the PMIPv6 domain.  We do not consider the case
      of mobile networks that may roam across PMIPv6 domains (i.e.
      global mobility).  Although this scenario might be also
      interesting, current PMIPv6 does not support inter-domain
      mobility, thus we limit the scope of the problem statement to the
      same of PMIPv6.


3.  PMIPv6 and Network  Mobility Problem Statement

   Figure 1 shows an example of the use case scenario described in
   Section 1.  Let consider a very simple PMIPv6 domain composed of one
   LMA and two MAGs: MAG 1 and MAG 2.  There are three MNs: MN 1, MN 2
   and MN 3.  The goal is to enable any MN to freely roam within the
   PMIPv6 domain, without changing its IP address -- and without
   requiring any mobility support nor involvement from the MN -- even if
   the MN moves between the mobile network and the fixed access network
   (i.e. the MN changes its point of attachment from the MR/MAG 1 to the
   MAG 1 or MAG 2).















Bernardos                Expires April 19, 2010                 [Page 4]


Internet-Draft              PMIPv6 & NEMO PS                October 2009


                       +-----+
                       | LMA |
                       +-----+
                        // \\
             +---------//---\\-------------+
            (         //     \\             ) PMIPv6 domain
            (        //       \\            )
             +------//---------\\----------+
                   //           \\
                  //             \\
             +-------+            +-------+
             | MAG 1 |            | MAG 2 |
             +-------+            +-------+
                 |                       |
              (( o ))                 (( o ))

   . .. . .. . .. . .. . .. . .. .
   :              mobile network :
   . ( o )                       .        ( o )
   :   |                         :          |
   .   | ----------              .   ------ |
   :   --|MR/MAG 1|--            :   |MN 1|--
   .     ---------- |            .   ------
   :                |            :
   .             << v >>         .
   :                             :
   .            Y     Y          .
   :     ------ |     | ------   :
   .     |MN 2|--     --|MN 3|   .
   :     ------         ------   :
   . .. . .. . .. . .. . .. . .. .

              Figure 1: PMIPv6 and network mobility scenario

3.1.  Applicability of existing standards

   This section briefly analyzes how the use of current standards fails
   in fully supporting the scenario described in this problem statement:

   1.  PMIPv6 only: by using PMIPv6 only, a single host would be able to
       freely roam between fixed points of attachment (MAG 1 and MAG 2
       in Figure 1).  By enabling bridging on the MN attaching to the
       MAG, some very limited kind of network mobility support could be
       achieved (if the Per-MN-Prefix model is used).  However, this
       approach does not support nodes leaving the mobile network and
       attaching to another MAG (or MR/MAG) without changing IP address,
       in addition to the undesired complexity brought by the use of
       bridging.



Bernardos                Expires April 19, 2010                 [Page 5]


Internet-Draft              PMIPv6 & NEMO PS                October 2009


   2.  NEMO Basic Support (NEMO B.S.) only: by enabling NEMO B.S. on the
       MR/MAG (and deploying a Home Agent in the network), a set of
       nodes would be able to freely roam within the domain (in the
       example of Figure 1, MAG 1 and MAG 2 would only play the role of
       plain IPv6 Access Routers).  However, an MN would not be able to
       move between the mobile network and the fixed access network
       (because the addresses that nodes may use while connected to the
       MR/MAG would belong to the Mobile Network Prefix -- MNP -- of the
       network, which is different from the prefixes provided by the LMA
       within the PMIPv6 domain).  Additionally, this scenario requires
       the deployment of a NEMO B.S. Home Agent (for example at the
       location where the LMA is placed in Figure 1) and involves
       additional NEMO B.S. signaling every time the MR/MAG moves.

   3.  NEMO B.S. + PMIPv6: by enabling NEMO B.S. on the MR/MAG and
       deploying PMIPv6 in the domain, we would achieve the same level
       of functionality of the previous case, but saving the signaling
       required every time the MR/MAG moves, since its Care-of Address
       (CoA) would not change while it is roaming within the domain (the
       address the MR/MAG uses as CoA is anchored at the LMA and does
       not change despite of the MR/MAG movements, thanks to the PMIPv6
       support).  In this scenario, NEMO B.S. HA and the PMIPv6 LMA
       could be collocated.

   The previous compilation of potential approaches does not consider
   the use of Mobile IPv6 [RFC3775] on the MNs, since this would not
   meet the fundamental feature of network-based localized mobility
   solutions (such as PMIPv6): not to involve MNs on the signaling nor
   management of their own mobility.

   As shown, with existing standards, there is no way of achieving the
   level of functionality required in our scenario.  It is therefore
   required to work on new solutions/extensions to existing protocols
   (either to the NEMO B.S., to PMIPv6 or to both when working in a
   combined way).


4.  IANA Considerations

   This document makes no request of IANA.


5.  Security Considerations

   Security considerations regarding the MR/MAG would be needed.  It
   might be safe to assume that the MR/MAG has the same level of trust/
   security that the MAGs of the network, but this may depend on the
   particular solution.



Bernardos                Expires April 19, 2010                 [Page 6]


Internet-Draft              PMIPv6 & NEMO PS                October 2009


6.  Acknowledgments

   The research of Carlos J. Bernardos leading to these results has
   received funding from the European Community's Seventh Framework
   Programme (FP7/2007-2013) under grant agreement n. 214994 (CARMEN
   project) and also from the Ministry of Science and Innovation of
   Spain, under the QUARTET project (TIN2009-13992-C02-01).


7.  References

7.1.  Normative References

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

   [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
              Thubert, "Network Mobility (NEMO) Basic Support Protocol",
              RFC 3963, January 2005.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

7.2.  Informative References

   [RFC3753]  Manner, J. and M. Kojo, "Mobility Related Terminology",
              RFC 3753, June 2004.

   [RFC4885]  Ernst, T. and H-Y. Lach, "Network Mobility Support
              Terminology", RFC 4885, July 2007.


Author's Address

   Carlos J. Bernardos
   Universidad Carlos III de Madrid
   Av. Universidad, 30
   Leganes, Madrid  28911
   Spain

   Phone: +34 91624 6236
   Email: cjbc@it.uc3m.es
   URI:   http://www.it.uc3m.es/cjbc/








Bernardos                Expires April 19, 2010                 [Page 7]