Internet DRAFT - draft-bernardos-netext-pmipv6-nemo-ps
draft-bernardos-netext-pmipv6-nemo-ps
NETEXT Working Group CJ. Bernardos
Internet-Draft M. Calderon
Intended status: Informational UC3M
Expires: September 13, 2012 I. Soto
UPM
March 12, 2012
PMIPv6 and Network Mobility Problem Statement
draft-bernardos-netext-pmipv6-nemo-ps-02
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.
Current PMIPv6 specification does only support the movement of hosts
within the localized mobility domain. A mobile network (commonly
referred to as a NEMO, NEtwork that MOves) can also benefit from the
network-based localized mobility support provided by PMIPv6
[I-D.ietf-netext-pd-pmip], but with some limitations. 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.
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 September 13, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Bernardos, et al. Expires September 13, 2012 [Page 1]
Internet-Draft PMIPv6 & NEMO PS March 2012
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. 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 and Motivation . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . . 4
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
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Bernardos, et al. Expires September 13, 2012 [Page 2]
Internet-Draft PMIPv6 & NEMO PS March 2012
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's 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, such as in the
use cases described above), and the NEMO Basic Support Protocol
[RFC3963] is the solution to provide transparent network mobility
support to a set of nodes moving together (which nicely fits the
requirements related to providing Internet access to users in mobile
platforms, such in the use cases described above), 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 detail the problem
statement of combining PMIPv6 with network mobility support and
explain why current IETF standards are not able to fully tackle this
problem.
Bernardos, et al. Expires September 13, 2012 [Page 3]
Internet-Draft PMIPv6 & NEMO PS March 2012
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:
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 an RFC 5213-compliant 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 (similarly as done in
[I-D.ietf-netext-pd-pmip]). 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's 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. Additionally, there is also an MR/MAG: MER/MAG 1. 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, et al. Expires September 13, 2012 [Page 4]
Internet-Draft PMIPv6 & NEMO PS March 2012
+-----+
| 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
to fully support the scenario described in this problem statement:
1. PMIPv6 only. By using PMIPv6 only, a single host (i.e. an MN)
would be able to freely roam between fixed points of attachment
(MAG 1 and MAG 2 in Figure 1). By enabling bridging on an MR/MAG
attaching to a fixed MAG, some very limited kind of network
mobility support could be achieved (if the Per-MN-Prefix model
[RFC5213] is used). [I-D.ietf-netext-pd-pmip] specifies
extensions to Proxy Mobile IPv6 to support network mobility.
However, none of these approaches do support a mobile node
leaving the mobile network and attaching to another MAG (or MR/
Bernardos, et al. Expires September 13, 2012 [Page 5]
Internet-Draft PMIPv6 & NEMO PS March 2012
MAG) without changing IP address of the mobile node.
2. NEMO Basic Support (NEMO B.S.) only. In this case, MAG 1 and MAG
2 in the example of Figure 1 would only play the role of plain
IPv6 Access Routers. If NEMO B.S is enabled on the MR/MAG (and a
Home Agent is deployed in the network), a set of nodes would be
able to freely roam within the domain . 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
the 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 as the previous case, but saving the NEMO
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 [RFC6275] on the MNs, since this would not
meet the fundamental feature of network-based localized mobility
solutions (such as PMIPv6): not to involve the MN on the signaling
nor on the management of its 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/
Bernardos, et al. Expires September 13, 2012 [Page 6]
Internet-Draft PMIPv6 & NEMO PS March 2012
security that the MAGs of the network, but this may depend on the
particular solution.
6. Acknowledgments
The work of Carlos J. Bernardos has also been partially supported by
the European Community's Seventh Framework Programme (FP7-ICT-2009-5)
under grant agreement n. 258053 (MEDIEVAL project). The research of
Carlos J. Bernardos and Maria Calderon has also been partially
supported by the Ministry of Science and Innovation of Spain under
the QUARTET project (TIN2009-13992-C02-01).
7. References
7.1. Normative References
[I-D.ietf-netext-pd-pmip]
Zhou, X., Korhonen, J., Williams, C., Gundavelli, S., and
C. Bernardos, "Prefix Delegation for Proxy Mobile IPv6",
draft-ietf-netext-pd-pmip-02 (work in progress),
March 2012.
[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.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
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.
Bernardos, et al. Expires September 13, 2012 [Page 7]
Internet-Draft PMIPv6 & NEMO PS March 2012
Authors' Addresses
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/
Maria Calderon
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 8780
Email: maria@it.uc3m.es
Ignacio Soto
Universidad Politecnica de Madrid
Email: isoto@dit.upm.es
Bernardos, et al. Expires September 13, 2012 [Page 8]
