One document matched: draft-bernardos-netext-pmipv6-nemo-ps-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 06:47:58 |