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]