NETEXT Working Group CJ. Bernardos
Internet-Draft A. de la Oliva
Intended status: Informational UC3M
Expires: September 9, 2010 JC. Zuniga
InterDigital Communications, LLC
T. Melia
Alcatel-Lucent Bell Labs
March 8, 2010
Applicability Statement on Link Layer implementation/Logical Interface
over Multiple Physical Interfaces
draft-bernardos-netext-ll-statement-01
Abstract
The NETLMM WG standardized Proxy Mobile IPv6 (PMIPv6) as [RFC5213].
PMIPv6 enables mobile devices to connect to a PMIPv6 domain and roam
across gateways without changing the IP address. PMIPv6 also
provides limited multi-homing support to multi-mode mobile devices.
Proxy mobility is based on the assumption that changes in host IP
stacks are undesirable. Link layer implementations can hide the
actually used physical interfaces from the IP stack. These
techniques can be used to achieve inter-access technology handovers
or flow mobility, i.e., the movement of selected flows from one
access technology to another. It is assumed that an IP layer
interface can simultaneously and/or sequentially attach to multiple
MAGs (possibly over multiple media). This document provides an
informational applicability statement that analyzes the issues
involved with this approach (i.e. hiding access technology changes
from host IP layer) and characterizes the contexts in which such use
is or is not appropriate to achieve inter-access handovers or flow
mobility.
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
Bernardos, et al. Expires September 9, 2010 [Page 1]
Internet-Draft Link Layer Applicability Statement March 2010
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 September 9, 2010.
Copyright Notice
Copyright (c) 2010 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. 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 BSD License.
Bernardos, et al. Expires September 9, 2010 [Page 2]
Internet-Draft Link Layer Applicability Statement March 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Hiding access technology changes . . . . . . . . . . . . . . . 4
3. Applicability Statement . . . . . . . . . . . . . . . . . . . . 7
3.1. Link Layer Support . . . . . . . . . . . . . . . . . . . . 7
3.2. Logical Interface . . . . . . . . . . . . . . . . . . . . . 8
3.3. Layer 2.5 . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Bernardos, et al. Expires September 9, 2010 [Page 3]
Internet-Draft Link Layer Applicability Statement March 2010
1. Introduction
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 Mobile Access Gateway (MAG). The MAG is the
first layer three hop detecting Mobile Node's (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.
Proxy mobility is based on the assumption that changes in host IP
stacks are undesirable. Link layer implementations can hide the
actually used physical interfaces from the IP stack. These
techniques can be used to achieve inter-access technology handovers
or flow mobility, i.e., the movement of selected flows from one
access technology to another. It is assumed that an IP layer
interface can simultaneously and/or sequentially attach to multiple
MAGs (possibly over multiple media). This document provides an
informational applicability statement that analyzes the issues
involved with this approach and characterizes the contexts in which
such use is or is not appropriate.
2. Hiding access technology changes
There are several techniques/mechanisms that allow hiding access
technology changes or movement from host IP layer. This section
classifies these existing techniques into a set of generic
approaches, according to their most representative characteristics.
We then refer to these generic mechanisms later in the document, when
analyzing their applicability to inter-access technology and flow
mobility purposes in PMIPv6.
The following generic mechanisms can hide access technology changes
from host IP layer:
o Link layer support: certain link layer technologies are able to
hide physical media changes from the upper layers (see Figure 1).
For example, IEEE 802.11 is able to seamlessly change between IEEE
802.11a/b/g physical layers. Also, an 802.11 STA can move between
different Access Points (APs) within the same domain without the
IP stack being aware of the movement. In this case, the IEEE
802.11 MAC layer takes care of the mobility, making the media
change invisible to the upper layers. Another example is IEEE
802.3, that supports changing the rate from 10Mbps to 100Mbps and
to 1000Mbps.
Bernardos, et al. Expires September 9, 2010 [Page 4]
Internet-Draft Link Layer Applicability Statement March 2010
Mobile Node
+-----------------------+
| TCP/UDP | AR1 AR2
+-----------------------+ +-----+ +-----+
| IP | | IP | | IP |
+-----------------------+ +-----+ +-----+
| Link Layer (L2) | | L2 | | L2 |
+-----+-----+-----+-----+ +-----+ +-----+
| L1a | L1b | L1c | L1d |<---------->| L1d | | L1b |
+-----+-----+-----+-----+ +-----+ +-----+
^ ^
|_________________________________________|
Figure 1: Link layer support solution architecture
There are also other examples with more complicated architectures,
like for instance, 3GPP Rel-8. In this case, a UE can move
(inter-RA handover) between GERAN/UTRAN/E-UTRAN, being this
movement invisible to the IP layer at the UE, and also to the LMA
logical component at the PGW. The link layer stack at the UE
(i.e. PDCP and RLC layers), and the GTP between the RAN and the
SGW (which plays the role of inter-3GPP AN mobility anchor) hide
this kind of mobility, which is not visible to the IP layer of the
UE (see Figure 2).
---------
| Appl. |<----------------------------------------------------->
--------- ----------
| |<+ - - - - - - - - - - - - - - - - - - - - +>| |
| IP | . ----------------- . ------------------- . | IP |
| |<+>| relay |<+>| relay | . | |
--------- . ----------------- . ------------------- . ----------
| PDCP |<+>| PDCP | GTP-U |<+>| GTP-U | GTP-U |<+>| GTP-U |
--------- . ----------------- . ------------------- . ----------
| RLC |<+>| RLC | UDP/IP |<+>| UDP/IP | UDP/IP |<+>| UDP/IP |
--------- . ----------------- . ------------------- . ----------
| MAC |<+>| MAC | L2 |<+>| L2 | L2 |<+>| L2 |
--------- . ----------------- . ------------------- . ----------
| L1 |<+>| L1 | L1 |<+>| L1 | L1 |<+>| L1 |
--------- . ----------------- . ------------------- . ----------
UE Uu E-UTRAN S1-U SGW S5/S8a PGW
Figure 2: 3GPP Rel-8 data plane architecture (GTP option)
o Logical interface: this refers to solutions (see Figure 3) that
logically group/bond several physical interfaces so they appear to
the upper layers (i.e. IP) as one single interface (where
application sockets bind). Depending on the OS support, it might
Bernardos, et al. Expires September 9, 2010 [Page 5]
Internet-Draft Link Layer Applicability Statement March 2010
be possible to use more than one physical interface at a time --
so the node is simultaneously attached to different media -- or
just to provide a fail-over mode. Controlling the way the
different media is used (simultaneous, sequential attachment, etc)
is not trivial and requires additional intelligence and/or
configuration at the logical interface device driver. An example
of this type of solution is the virtual interface
[I-D.yokota-netlmm-pmipv6-mn-itho-support] or the bonding driver.
+----------------------------+
| TCP/UDP |
Session to IP +->| |
address binding | +----------------------------+
+->| IP |
IP to logical +->| |
interface binding | +----------------------------+
+->| Logical interface |
logical to physical +->| (MN-HoA) |
interface binding | +----------------------------+
+->| L2 | L2 | | L2 |
|(IF#1)|(IF#2)| ..... |(IF#n)|
+------+------+ +------+
| L1 | L1 | | L1 |
| | | | |
+------+------+ +------+
Figure 3: Logical interface architecture
o Layer 2.5: another potential solution is to add a layer 2.5 (e.g.,
shim-layer) on top of multiple L2 media. In this case, the so-
called layer 2.5 takes care of making inter-media support
transparent to upper layers (i.e. IP). The layer 2.5
functionality can reside only in the mobile node or it can also
have a layer 2.5 counterpart in the network (see Figure 4).
Communication between the layer 2.5 functionality in the mobile
node and in the network can either take place over L2 or L3
signaling, as described in RFC5164 [RFC5164] and RFC5677
[RFC5677].
Bernardos, et al. Expires September 9, 2010 [Page 6]
Internet-Draft Link Layer Applicability Statement March 2010
Mobile Node
+-----------------------+
| TCP/UDP | AR1 AR2
+-----------------------+ +------+ +------+
| IP | | IP | | IP |
+-----------------------+ +------+ +------+
| Layer 2.5 | | L2.5 | | L2.5 |
+-----------------------+ +------+ +------+
| L2a | L2b | L2c | L2d | | L2d | | L2b |
+-----+-----+-----+-----+ +------+ +------+
| L1a | L1b | L1c | L1d |<---------->| L1d | | L1b |
+-----+-----+-----+-----+ +------+ +------+
^ ^
|___________________________________________|
Figure 4: Layer 2.5 support solution architecture
3. Applicability Statement
This section analyzes the issues involved with the approaches
described in Section 2 and characterizes the contexts in which their
use is or is not appropriate.
3.1. Link Layer Support
Link layer mobility support applies to cases when the same link layer
technology is used and mobility can be fully handled at these layers.
One example is the case where several 802.11 APs are deployed in the
same subnet and all of them share higher layer resources such as DHCP
server, IP gateway, etc. In this case the APs can autonomously (or
with the help of a central box) communicate and control the STA
association changes from one AP to another, without the STA being
aware of the movement. This type of scenario is applicable to cases
when the different points of attachment (i.e. APs) belong to the
same network domain, e.g. enterprise, hotspots from same operator,
etc.
This type of solution does not typically allow for simultaneous
attachment to different access networks, and therefore can only be
considered for inter-access technology handovers, but not for flow
mobility. Existing RFC 5213 handover hint mechanisms could benefit
from link layer information (e.g. triggers) to detect and identify MN
handovers.
Link layer support is not applicable when two different access
technologies are involved (e.g. 802.11 WLAN and 802.16 WiMAX) and the
same is true when the same access technology expands over multiple
Bernardos, et al. Expires September 9, 2010 [Page 7]
Internet-Draft Link Layer Applicability Statement March 2010
network domains.
3.2. Logical Interface
The use of a logical interface allows the mobile node to provide a
single interface view to the layers above IP. Upper layers can bind
to this interface, which hides inner inter-access technology
handovers or data flow transfers among different physical interfaces.
This type of solution may support simultaneous attachment, in
addition to sequential attachment. It requires additional support at
the node and the network in order to benefit from simultaneous
attachment. For example, since the IP stack at the mobile does only
"see" one interface, special mechanisms are required to enable
addressing a particular interface from the network. Unmodified
standard Neighbor Discovery cannot be used to detect MN attachment,
since all physical interfaces are bound to the same logical IP
interface. Extensions to PMIPv6 would be required in order to enable
the network (i.e., the MAG and LMA) deal with physical interfaces,
instead to IP interfaces as current RFC5213 does. RFC5213 assumes
that each physical interface capable of attaching to a MAG is an IP
interface, while the logical interface solution groups several
physical interfaces under the same IP logical interface.
3.3. Layer 2.5
The layer 2.5 mobility support applies to cases similar to the ones
described in Section 3.1, although in this case heterogeneous
networks can be considered (i.e. 802.11 WLAN and 802.16 WiMAX
networks), as well as networks of the same access technology that
expand over multiple network domains.
Hints from the layer 2.5 can help both the network and the mobile
node perform inter-access technology handovers while ensuring the
mobile node keeps using the same IP address.
4. IANA Considerations
This document makes no request of IANA.
5. Security Considerations
TBD
Bernardos, et al. Expires September 9, 2010 [Page 8]
Internet-Draft Link Layer Applicability Statement March 2010
6. Acknowledgments
The research of Carlos J. Bernardos and Antonio de la Oliva 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). The work of Carlos J. Bernardos has also
received funding from the Ministry of Science and Innovation of
Spain, under the QUARTET project (TIN2009-13992-C02-01
7. References
7.1. Normative References
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
7.2. Informative References
[I-D.yokota-netlmm-pmipv6-mn-itho-support]
Yokota, H., Gundavelli, S., Trung, T., Hong, Y., and K.
Leung, "Virtual Interface Support for IP Hosts",
draft-yokota-netlmm-pmipv6-mn-itho-support-03 (work in
progress), March 2010.
[RFC5164] Melia, T., "Mobility Services Transport: Problem
Statement", RFC 5164, March 2008.
[RFC5677] Melia, T., Bajko, G., Das, S., Golmie, N., and JC. Zuniga,
"IEEE 802.21 Mobility Services Framework Design (MSFD)",
RFC 5677, December 2009.
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/
Bernardos, et al. Expires September 9, 2010 [Page 9]
Internet-Draft Link Layer Applicability Statement March 2010
Antonio de la Oliva
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 8803
Email: aoliva@it.uc3m.es
URI: http://www.it.uc3m.es/aoliva/
Juan Carlos Zuniga
InterDigital Communications, LLC
Email: JuanCarlos.Zuniga@InterDigital.com
Telemaco Melia
Alcatel-Lucent Bell Labs
Email: Telemaco.Melia@alcatel-lucent.com
Bernardos, et al. Expires September 9, 2010 [Page 10]