Multiple Home Network Prefixes Considerations in Handover involving Network and Client Based IP Mobility Protocols
draft-oulai-netlmm-mip-interaction-multiple-hnp-00

Versions: 00                                                            
Netlmm Working Group                                            D. Oulai
Internet-Draft                                               S. Krishnan
Intended status: Standards Track                                Ericsson
Expires: July 16, 2009                                  January 12, 2009


  Multiple Home Network Prefixes Considerations in Handover involving
             Network and Client Based IP Mobility Protocols
         draft-oulai-netlmm-mip-interaction-multiple-hnp-00.txt

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 July 16, 2009.

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
   (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
   to this document.







Oulai & Krishnan          Expires July 16, 2009                 [Page 1]


Internet-Draft  Multiple HNPs considerations in handover    January 2009


Abstract

   Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) are the base
   protocols defined by IETF for network based and client based
   mobility.  This document analyzes PMIPv6 and two MIPv6 extensions,
   DSMIP and NEMO, with regard to multiple Home Network Prefixes
   handling during handover.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Interaction between PMIP and client based protocols  . . . . .  6
     4.1.  Scenario A . . . . . . . . . . . . . . . . . . . . . . . .  6
       4.1.1.  PMIP-DSMIP . . . . . . . . . . . . . . . . . . . . . .  6
       4.1.2.  PMIP-NEMO  . . . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Scenario C . . . . . . . . . . . . . . . . . . . . . . . .  6
       4.2.1.  PMIP-DSMIP . . . . . . . . . . . . . . . . . . . . . .  6
       4.2.2.  PMIP-NEMO  . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Recommendations  . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13

























Oulai & Krishnan          Expires July 16, 2009                 [Page 2]


Internet-Draft  Multiple HNPs considerations in handover    January 2009


1.  Introduction

   MIPv6 is the IETF standard for client-based mobility [RFC3775] and
   PMIPv6 is an extension of MIPv6 developed to offer network-based
   mobility [RFC5213].  Those two protocols will be deployed on a wide
   scale.  On the other hand, DSMIP [I-D.ietf-mext-nemo-v4traversal] and
   NEMO [RFC3963] are two major variants of MIPv6 used to support IPv4
   mobility and mobile routers (MR).  Therefore, standardizing
   interactions between those protocols becomes mandatory.  Three
   scenarios have been presented in [I-D.ietf-netlmm-mip-interactions].

   * Scenario A: Two distinct PMIPv6 domains inside a single MIPv6
   domain.

   * Scenario B: A single domain where PMIPv6 and MIPv6 are supported.

   * Scenario C: A collocated LMA/HA serving distinct PMIPv6 and MIPv6
   domain.

   In this document, the ability to manage the mobility of a MN with
   more than one assigned HNPs for a mobility session is considered.
   This allows reducing the Binding Cache size, the signaling load and
   the security processing in some ways.  PMIP allows multiple HNPs for
   a single mobility session while MIPv6 does not.  MIPv6 [RFC3775]
   works with only one v6 HoA by MIPv6 session.  Therefore, we will not
   consider MIPv6 as managing multiples HNPs results on multiple MIPv6
   sessions.  DSMIP [I-D.ietf-mext-nemo-v4traversal] has the same
   limitations as MIPv6 except that a MN can have several v4 HoAs from
   different prefixes.  On the contrary, NEMO [RFC3963] supports
   multiple prefixes assignment.

   Having multiple HNPs is interesting for example in the case where,
   through a single LMA, a MN is connected to several service providers
   which assign prefixes to the MN.  In this situation, the mobility is
   managed through a single mobility session.  This features is also
   interesting for Mobile Routers (MR).  Here we consider DSMIP and NEMO
   as they are MIPv6 extensions that support multiple HNPs assignment in
   different ways.  Moreover, PMIP is the only network based IP mobility
   protocol.  Therefore, in this document we describe handover between
   PMIP and client based IP Mobility protocols (DSMIP and NEMO).











Oulai & Krishnan          Expires July 16, 2009                 [Page 3]


Internet-Draft  Multiple HNPs considerations in handover    January 2009


2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].














































Oulai & Krishnan          Expires July 16, 2009                 [Page 4]


Internet-Draft  Multiple HNPs considerations in handover    January 2009


3.  Terminology

   All the general mobility-related terms used in this document are to
   be interpreted as defined in the Mobile IPv6 [RFC3775], Proxy Mobile
   IPv6 [RFC5213], NEMO [RFC3963] and DSMIP
   [I-D.ietf-mext-nemo-v4traversal] base specifications.













































Oulai & Krishnan          Expires July 16, 2009                 [Page 5]


Internet-Draft  Multiple HNPs considerations in handover    January 2009


4.  Interaction between PMIP and client based protocols

   We now describe the interaction between PMIP, DSMIP and NEMO
   protocols.  First, note that we will not address scenario B mentioned
   in [I-D.ietf-netlmm-mip-interactions] as it does not involve any
   handover.  Home Addresses in a PMIP domain are referred as P-HoA and
   Home Addresses in the other protocol are simply labeled HoA.

4.1.  Scenario A

   In this scenario, PMIP is used for local mobility and the other
   protocols for global mobility.  We consider the case where Multiple
   HNPs are assigned in the PMIP domain.

4.1.1.  PMIP-DSMIP

   Here, the MN can locally obtain several HNPs and forms P-HoAs based
   on these HNPs.  To register more than one P-HoA as CoAs with the
   DSMIP HA, the MN must use Multiple CoA [I-D.ietf-monami6-multiplecoa]
   specification (MCoA).  After a handover in a new PMIP domain, the MN
   can configure different P-HoAs and register them with the DSMIPv6 HA.
   Note that some extensions to MCoA protocol are required to register
   v4 P-HoA as CoA.

4.1.2.  PMIP-NEMO

   The same operations described in Section 4.1.1 apply here and the
   MCoA specification can be modify to handle the assignment of a Mobile
   Network Prefix (MNP) toward a specific CoA.

4.2.  Scenario C

   In this scenario, the LMA and the HA are collocated.  Let's also
   mentioned that there is no prefix sharing between MNs as stated in
   [I-D.ietf-netlmm-mip-interactions].  Moreover, when in the PMIP
   domain, it is recommended to create the SA for the DSMIP or NEMO
   session in order to reduce the handover delay.

4.2.1.  PMIP-DSMIP

4.2.1.1.  Handover PMIP-DSMIP

   We consider that the MN is assigned several HNPs in the PMIP domain.
   Based on [I-D.ietf-mext-nemo-v4traversal] and [RFC5213]
   specifications, the MN MUST choose one HNP and register it in the
   DSMIPv6 domain, loosing connectivity through the other HNPs.  We
   suggest to label one HNP as the primary one in the PMIP domain.  This
   primary HNP will likely be chosen in for registration in the DSMIP



Oulai & Krishnan          Expires July 16, 2009                 [Page 6]


Internet-Draft  Multiple HNPs considerations in handover    January 2009


   domain.  The MN can also create one DSMIPv6 session for each assigned
   HNP, which is not optimal.

   As the whole prefix is reserved for a MN, a simple extension to
   DSMIPv6 could be to allow several v6HoAs in the BCE but perform all
   the signaling and security operations based on a single HoA labeled
   as the primary HoA.  Therefore, allowing multiple HoAs is equivalent
   to allowing multiple HNPs.  The MN is then able to send a single BU
   and binds all the HNPs to a single CoAs.  Modifying DSMIP in this way
   should be straightforward as DSMIP already allows v6 and v4 HoAs in a
   single binding and all the signaling and security operations are
   based on the v6HoA.

4.2.1.2.  Handover DSMIP-PMIP

   Two sub-cases may happen here:

   1.  The MN runs one or more DSMIPv6 session with one HNP for each
       session
       After the handover, the PMIP domain assigns the HNPs used in the
       DSMIPv6 domain and additional ones if required for a single PMIP
       session.  The HNP used in the MIPv6 domains are labeled as the
       primary HNPs.  The MN MUST maintain the MIPv6 SAs.

   2.  The MN uses one DSMIPv6 session with several HNPs
       In this case, the prefix list used in the DSMIPv6 BCE is copied
       to the PMIP BCE and all the HNPs are assigned to the MNs.  The
       primary HNP in the PMIP domain is also the primary one in the
       DSMIPv6 domain.  The MN MUST maintain the DSMIPv6 SA using the
       primary v6HoA.

4.2.2.  PMIP-NEMO

   As the LMA and NEMO HA are collocated, the same sets of prefixes
   advertised as HNPs in the PMIP domain can be used as MNPs in the NEMO
   domain as those prefixes are reserved.  When the MN is in the PMIP
   domain, the SA with the NEMO HA should be created.

4.2.2.1.  Handover PMIP-NEMO

   As the MN (which became a MR in the NEMO domain) knows which prefixes
   are advertised in the PMIP domain, after the handover, it inserts all
   the PMIP HNPs as MNPs in the BU sent to the NEMO HA.  A binding is
   created towards the CoA for all those MNPs.  The MR can also follow
   the implicit mode where the HA will be responsible of retrieving all
   the HNPs used int he PMIP domain and assigning them to the MN as
   MNPs. if other means are used to assign the MNPs in the NEMO domain,
   the MN or the HA should send the HNPs as hints during the signaling.



Oulai & Krishnan          Expires July 16, 2009                 [Page 7]


Internet-Draft  Multiple HNPs considerations in handover    January 2009


4.2.2.2.  Handover NEMO-PMIP

   When the LMA/HA receives the PBU for the MN, it checks the NEMO BCE
   and assigns all the MNPs as HNPs to the MN.  Therefore, the MR can
   continue serving its MNPs, believing it is on the home network.














































Oulai & Krishnan          Expires July 16, 2009                 [Page 8]


Internet-Draft  Multiple HNPs considerations in handover    January 2009


5.  Recommendations

   For scenario A, the best approach is to register all the P-HoAs
   formed in the PMIP domain as CoAs at the HA.  This is performed using
   MCoA [I-D.ietf-monami6-multiplecoa] specification.  For scenario C,
   the interaction between PMIP and NEMO is the most elegant way of
   providing multiple HNPs support.  However, as NEMO is not expected to
   be supported by most of the HAs, a slight modification of DSMIPv6
   where multiple HNPs (or at least multiple v6HoAs) are supported
   represents the best alternative.









































Oulai & Krishnan          Expires July 16, 2009                 [Page 9]


Internet-Draft  Multiple HNPs considerations in handover    January 2009


6.  Security Considerations

   The issue brought here resides in the SA for the signaling message as
   there are several HNPs and it is not scalable to have one SA for each
   HoA or HNP.  The MN in scenario C MUST be able to create the SA based
   on one primary HoA.  When receiving a signaling packet, the LMA/HA
   MUST be able to identify the primary HoA or HNP in order to locate
   the right SA for the host.











































Oulai & Krishnan          Expires July 16, 2009                [Page 10]


Internet-Draft  Multiple HNPs considerations in handover    January 2009


7.  IANA Considerations

   TBD
















































Oulai & Krishnan          Expires July 16, 2009                [Page 11]


Internet-Draft  Multiple HNPs considerations in handover    January 2009


8.  Normative References

   [I-D.ietf-mext-nemo-v4traversal]
              Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
              Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-07
              (work in progress), December 2008.

   [I-D.ietf-monami6-multiplecoa]
              Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami,
              "Multiple Care-of Addresses Registration",
              draft-ietf-monami6-multiplecoa-10 (work in progress),
              November 2008.

   [I-D.ietf-netlmm-mip-interactions]
              Giaretta, G., "Interactions between PMIPv6 and MIPv6:
              scenarios and related issues",
              draft-ietf-netlmm-mip-interactions-01 (work in progress),
              November 2008.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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




















Oulai & Krishnan          Expires July 16, 2009                [Page 12]


Internet-Draft  Multiple HNPs considerations in handover    January 2009


Authors' Addresses

   Desire Oulai
   Ericsson
   8400 Blvd Decarie
   Town of Mount Royal, Quebec
   Canada

   Email: desire.oulai@ericsson.com


   Suresh Krishnan
   Ericsson
   8400 Blvd Decarie
   Town of Mount Royal, Quebec
   Canada

   Email: Suresh.Krishnan@ericsson.com

































Oulai & Krishnan          Expires July 16, 2009                [Page 13]