NETEXT WG T. Melia, Ed.
Internet-Draft Alcatel-Lucent
Intended status: Informational S. Gundavelli, Ed.
Expires: March 8, 2012 Cisco
September 5, 2011
Logical Interface Support for multi-mode IP Hosts
draft-ietf-netext-logical-interface-support-03.txt
Abstract
A Logical Interface is a software semantic internal to the host
operating system. This semantic is available in all popular
operating systems and is used in various protocol implementations.
The Logical Interface support is required on the mobile node
operating in a Proxy Mobile IPv6 domain, for leveraging various
network-based mobility management features such as inter-technology
handoffs, multihoming and flow mobility support. This document
explains the operational details of Logical Interface construct and
the specifics on how the link-layer implementations hide the physical
interfaces from the IP stack and from the network nodes on the
attached access networks. Furthermore, this document identifies the
applicability of this approach to various link-layer technologies and
analyzes the issues around it when used in context with various
mobility management features.
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 March 8, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Melia & Gundavelli Expires March 8, 2012 [Page 1]
Internet-Draft Logical Interface Support September 2011
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Hiding Link-layer Technologies - Approaches and
Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Link-layer Abstraction - Approaches . . . . . . . . . . . 7
4.2. Applicability Statement . . . . . . . . . . . . . . . . . 8
4.2.1. Link layer support . . . . . . . . . . . . . . . . . . 9
4.2.2. Logical Interface . . . . . . . . . . . . . . . . . . 9
5. Technology Use cases . . . . . . . . . . . . . . . . . . . . . 11
6. Logical Interface Functional Details . . . . . . . . . . . . . 12
6.1. Configuration of a Logical Interface . . . . . . . . . . . 13
6.2. MTU considerations . . . . . . . . . . . . . . . . . . . . 14
6.3. Supported Link models for a logical interface . . . . . . 14
6.4. Link-layer Identifier of a Logical Interface . . . . . . . 15
6.5. ND Considerations for Logical Interface . . . . . . . . . 15
6.6. Logical Interface Forwarding Conceptual Data Structures . 16
7. Logical Interface Use-cases in Proxy Mobile IPv6 . . . . . . . 18
7.1. Multihoming Support . . . . . . . . . . . . . . . . . . . 18
7.2. Inter-Technology Handoff Support . . . . . . . . . . . . . 19
7.3. Flow Mobility Support . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
Melia & Gundavelli Expires March 8, 2012 [Page 2]
Internet-Draft Logical Interface Support September 2011
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Melia & Gundavelli Expires March 8, 2012 [Page 3]
Internet-Draft Logical Interface Support September 2011
1. Introduction
Proxy Mobile IPv6 [RFC5213] is a network-based mobility protocol.
Some of the key goals of the protocol include support for
multihoming, inter-technology handoffs and flow mobility support.
The base protocol features specified in [RFC5213] allow the mobile
node to attach to the network using multiple interfaces
(simultaneously or sequentially), or to perform handoff between
different interfaces of the mobile node. However, for supporting
these features, the mobile node is required to be activated with
specific software configuration that allows the mobile node to either
perform inter-technology handoffs between different interfaces,
attach to the network using multiple interfaces, or perform flow
movement from one access technology to another. This document
analyzes from the mobile node's perspective a specific approach that
allows the mobile node to leverage these mobility features.
Specifically, it explores the use of the Logical Interface support, a
semantic available on most operating systems.
A Logical Interface is a construct internal to the operating system.
It is an approach where the link-layer implementations hide the
physical interfaces from the IP stack and from the network nodes on
the attached access networks. This semantic is widely available in
all popular operating systems. Many applications such as Mobile IP
client [RFC3775] and IPsec VPN client [RFC4301] rely on this semantic
for their protocol implementation and the same semantic can also be
useful in this context. Specifically, the mobile node can use the
logical interface configuration for leveraging various network-based
mobility management features provided by the Proxy Mobile IPv6 domain
[RFC5213].
The rest of the document provides the operational details of a
Logical Interface on the mobile node and the inter-working between a
mobile node using logical interface and network elements in the Proxy
Mobile IPv6 domain when supporting some of the mobility management
features. It also analyzes the issues involved with this approach
and characterizes the contexts in which such usage is appropriate.
Melia & Gundavelli Expires March 8, 2012 [Page 4]
Internet-Draft Logical Interface Support September 2011
2. Requirements Language
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [RFC2119].
Melia & Gundavelli Expires March 8, 2012 [Page 5]
Internet-Draft Logical Interface Support September 2011
3. Terminology
All the mobility related terms used in this document are to be
interpreted as defined in Proxy Mobile IPv6 specifications, [RFC5213]
and [RFC5844]. In addition, this document introduces the following
terms:
PIF (Physical Interface) - a network interface card attached to an
an host providing network connectivity (e.g. an Ethernet card, a
WLAN card, an LTE interface).
LIF (Logical Interface) - It is a virtual interface in the IP stack.
It appears just as any other physical interface, provides similar
semantics with respect to packet transmit and receieve functions
to the upper layers in the IP stack. However, it is only logical
construct and is not a representation of an instance of any
physical hardware.
VLL-ID (Virtual Link-layer ID) - a virtual link-layer address
configured on the logical interface. This identifier can be
randomly generated, or configured based on the link-layer address
of one of the physical interface.
Sub-If (Sub Interface) - a physical interface that is part of a
logical interface construct. For example, a logical interface may
have been created abstracting two physical interfaces, LTE and
WLAN. These physical interfaces, LTE and WLAN are referred to as
sub-interfaces of that logical interface. In some cases, a sub-
interface can also be another logical interface, such as an IPsec
tunnel interface.
Melia & Gundavelli Expires March 8, 2012 [Page 6]
Internet-Draft Logical Interface Support September 2011
4. Hiding Link-layer Technologies - Approaches and Applicability
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.
Later sections of this document analyze the applicability of these
solution approaches for supporting features such as, inter-technology
handovers and IP flow mobility support for a mobile node in a Proxy
Mobile IPv6 domain [RFC5213].
4.1. Link-layer Abstraction - Approaches
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.
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 EPC [TS23401]. 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
Melia & Gundavelli Expires March 8, 2012 [Page 7]
Internet-Draft Logical Interface Support September 2011
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 LTE/EPC 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
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 Logical interface, which is
defined in this document, or the bonding driver (a Linux
implementation).
4.2. Applicability Statement
We now focus on the applicability of the above solutions against the
following requirements:
o multi technology support
o sequential vs. simultaneous access
Melia & Gundavelli Expires March 8, 2012 [Page 8]
Internet-Draft Logical Interface Support September 2011
4.2.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
network domains. This solution does not impose any change at the IP
layer since changes in the access technology occur at layer two.
4.2.2. Logical Interface
The use of a logical interface allows the mobile node to provide a
single interface view to the layers above IP (thus not changing the
IP layer itself). 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 special mechanisms are required to enable
addressing a particular interface from the network (e.g. for flow
mobility). In particular extensions to PMIPv6 are required in order
to enable the network (i.e., the MAG and LMA) to deal with logicql
interfqce, 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.
It is therefore clear that the Logical Interface approach satisfies
Melia & Gundavelli Expires March 8, 2012 [Page 9]
Internet-Draft Logical Interface Support September 2011
the multi technology and the sequential vs: simultaneous access
support.
Melia & Gundavelli Expires March 8, 2012 [Page 10]
Internet-Draft Logical Interface Support September 2011
5. Technology Use cases
The 3GPP has defined the Evolved Packet Core (EPC) for heterogeneous
wireless access. A mobile device equipped with 3GPP and non-3GPP
wireless technologies can simultaneously or senquentialy connect any
of the available devices and receive IP services through any of them.
This document focuses on the simultaneous/sequential use of these
technologies and on the use cases that derive.
As mentioned in the previous sections the Logical Interface construct
is required to hide the specifities of each technology in the context
of network based mobility (e.g. in PMIPv6 deployments). The LIF
concept can be used with at least the following technologies: 3GPP
access technologies (3G, LTE), WIMAX access technology and IEEE
802.11 access technology.
3GPP In most OS implementations the connection setup establishes a
PPP interface through the IPCP and IPv6CP protocol [RFC5072]. In
this case the PPP interface does not have any L2 address assigned
and does not generate any ARP or ND message for layer two address
resolution. Conversely recent implementations configure an
ethernet alike interface at OS level hiding to the upper layers
the PPP nature of the connection. It has been verified (Android
platform) that in these cases the ethernet alike interface
configures a random L2 MAC address and uses this address as source
link layer address in ND messages. ARP is also run between the
mobile device and the remote peer (the network is a /30 address
space).
WIMAX In WiMAX system also, the connection between the mobile
station (MS) and the access router (AR) is a point-to-point link.
The MS autoconfigures an address based on the prefix advertised by
the AR or is assigned an address via DHCPv6. The stateless
address auto-configuration is performed as per [RFC4861] and the
IPv6 address is formed by adding an IID to the prefix learnt from
Router Advertisement. IPv6 packets sent or received by the MS are
identified by specific IDs, by which the AR can map them to the
corresponding tunnel in the network.
WIFI TBD
IPsec TBD
Melia & Gundavelli Expires March 8, 2012 [Page 11]
Internet-Draft Logical Interface Support September 2011
6. Logical Interface Functional Details
On most operating systems, a network interface is associated with a
physical device that offers the services for transmitting and
receiving IP packets to the applications on the host. In some
configurations, a network interface can also be implemented as a
logical interface which does not have the inherent capability to
transmit, or receive packets on a physical medium, but relies on
other physical interfaces for such services. Example of such
configuration is an IP tunnel interface. General overview of a
logical interface is shown in Figure 3. This section identifies the
functional details of a logical interface and provides some
implementation considerations.
The logical interface allows heterogeneous attachment while leaving
the change in the media transparent to the IP stack. Simultaneous
and sequential network attachment procedures are possible enabling
inter-technology and flow mobility scenarios.
+----------------------------+
| TCP/UDP |
Session to IP +---->| |
Address binding | +----------------------------+
+---->| IP |
IP Address +---->| |
binding | +----------------------------+
+---->| Logical Interface |
Logical to +---->| (MN-HoA) |
Physical | +----------------------------+
Interface +---->| L2 | L2 | | L2 |
binding |(IF#1)|(IF#2)| ..... |(IF#n)|
+------+------+ +------+
| L1 | L1 | | L1 |
| | | | |
+------+------+ +------+
Figure 3: General overview of logical interface
From the perspective of the IP stack and the applications, a Logical
interface is just another interface. In fact, the Logical interface
is the only one visible to the IP and upper layers when enabled. A
host does not see any operational difference between a Logical and a
physical interface. As with physical interfaces, a Logical interface
is represented as a software object to which IP address configuration
is bound. However, the Logical interface has some special properties
which are essential for enabling inter-technology handover and flow-
mobility features. Following are those properties:
Melia & Gundavelli Expires March 8, 2012 [Page 12]
Internet-Draft Logical Interface Support September 2011
o P1: The logical interface has a relation to a set of physical
interfaces (sub-interfaces) on the host that it is abstracting.
These sub-interfaces can be attached or detached from the Logical
Interface at any time. The sub-interfaces attached to a Logical
interface are not visible to the IP and upper layers.
o P2: The logical Interface may either use a virtual interface
identfier idependent of the interface identfiers of its sub-
interfaces, or it may use the link-layer identifier from one of
its sub-interfaces.
o P3: Logical Interface has the path awareness with respect to the
attached IP networks. For example, the logical interface may be
bound to two IP networks, CAFE::/64 and BABA::/64, each of these
prefixes may have been hosted on access networks attached through
different sub-interfaces, WLAN and LTE. The logical interface has
the path awareness with respect to IP network to sub-interface
mapping.
o P4: Logical Interface may be attached to multiple access
technologies with different link MTU values. The adopted MTU
value for the logical interface must be lowest MTU value across
those access technologies.
o P5: The Send/Receive functions of the Logical interface are mapped
to the services exposed by the sub-interfaces. This mapping is
dynamic and any change is not visible to the upper layers of the
IP stack.
o P6:Logical interface adapts to the link model underneath where the
packet is being transmitted. When transmitting a packet on a sub-
interface which is attached to a p2p link, the transmission
conforms to the p2p link model and when transmitting on a sub-
interface attached to a shared link, the transmission conforms to
the shared link model.
o P7: The Logical interface maintains IP flow information for each
of its sub-interfaces. A conceptual data structure can be
maintained for this purpose. The host may populate this
information based on tracking each of the sub-interface for the
active flows.
6.1. Configuration of a Logical Interface
A host may be statically configured with the logical interface
configuration, or an application such as a connection manager on the
host may dynamically create it. Furthermore, the set of sub-
interfaces that are part of a logical interface construct may be a
Melia & Gundavelli Expires March 8, 2012 [Page 13]
Internet-Draft Logical Interface Support September 2011
fixed set, or may be kept dynamic, with the sub-interfaces getting
added or deleted as needed. The specifics on how a host creates a
logical interface, or how it decides to add or delete a sub-interface
to a logical interface is out side the scope of this document.
6.2. MTU considerations
The link MTU (maximum transmission unit) value configured on a
logical interface should be the lowest of the MTU values supported
across any of the physical interfaces that are part of that logical
interface construct. The MTU value should be configured as part of
the logical interface creation on the host.
Furthermore, this value must be updated any time there is a change to
the logical interface construct, such as when interfaces are added or
deleted from the logical interface setup. Any time there is an
inter-technology handover between two access technologies, the
applications on the host bound to the IP address configuration on the
logical interface will not detect the change and will continue to use
the MTU value of the logical interface for the outbound packets,
which is never greater than the MTU value on that supported access
network. However, the access network may continue to deliver the
packets conforming to the MTU value supported on that access
technology and the logical interface should be able to receive those
packets from the physical interface attached to that network.
6.3. Supported Link models for a logical interface
The sub-interfaces of a logical interface can be bound to a point-to-
point or a shared link (Example: LTE and WLAN). The logical
interface appears as a shared-link to the applications, and adapts to
the link model of the sub-interface for packet communication. For
example, when transmitting a packet on a sub-interface which is
attached to a p2p link, the transmission conforms to the p2p link
model and when transmitting on a sub-interface attached to a shared
link, the transmission conforms to the shared link model.
Based on the link to which the sub-interface is attached to, the
layer-2 resolutions may or may not be needed. If the interface is
bound to a P2P link with PPP running, there will not be any link-
layer resolutions in the form of ARP/ND messages. However, if the
interface is bound to a shared link such as Ethernet, there will be
ND resolutions. The logical interface implementation has to maintain
the required link model and the associated state for each sub-
interface.
Melia & Gundavelli Expires March 8, 2012 [Page 14]
Internet-Draft Logical Interface Support September 2011
6.4. Link-layer Identifier of a Logical Interface
The logical Interface may or may not use the link-layer identifier
from one of its sub-interfaces. Following are the considerations.
o In access architectures where it is possible to adopt a virtual
link-layer identfier and use it for layer-2 communications in any
of the access networks, a virtual identifier (VLL-Id) may be used.
The specifics on how that identifier is chosen is out side the
scope of this document. This identifier may be used for all link-
layer communications. This identifier may also be used for
generating IPv6 global or link-local addresses on that interface.
o In access architectures, where the link-layer identifier is
associated with a specific access technology, it will not be
possible for the logical interface to adopt a virtual identifier
and it use it across different access networks. In such networks,
the logical interface must adopt the identifier of the respective
sub-interface through which a packet is being transmitted.
6.5. ND Considerations for Logical Interface
The following are the Neighbor Discovery related considerations for
the logical interface.
o Any Neighbor Discovery messages, such as Router Solicitation,
Neighbor Solicitation messages that the host sends to a multicast
destination address of link-local scope such as, all-nodes, all-
routers, solicited-node multicast group addresses, using either an
unspecified (::) source address, or a link-local address
configured on the logical interface will be replicated and
forwarded on each of the sub-interfaces under that logical
interface. However, if the destination address is a unicast
address and if that target is known to exist on a specific sub-
interface, the message will be forwarded only on that specific
sub-interface.
o Any Neighbor Discovery messages, such as Router Advertisement,
that the host receives from any of its sub-interfaces, will be
associated with the logical interface, i.e., in some
implementations the message will appear on the input interface of
the logical interface.
o When using Stateless Address Autoconfiguraion [RFC4862] for
generating IPv6 address configuration on the logical interface,
the host may use any of the IPv6 prefixes receieved from the
Router Advertisement messages that it received from any of its
sub-interfaces.
Melia & Gundavelli Expires March 8, 2012 [Page 15]
Internet-Draft Logical Interface Support September 2011
o The response to a Neighbor Discovery message received for a
unicast, link-specific multicast group address, will be sent on
the same sub-interface path where the packet was received.
o When using DHCPv4 for obtaining address configuration for the
logical interface, the value in the chaddr field in the DHCP
messages will be based on the link-layer identfier scheme chosen
by the logical interface.
.
6.6. Logical Interface Forwarding Conceptual Data Structures
The LIF should maintain the LIF and FLOW table data structures
depicted in Figure 4
LIF TABLE FLOW table
+===============================+ +===============================+
| PIF_ID | FLOW RoutingPolicies | | FLOW ID | PIF_ID |
| | Home Network Prefix | +-------------------------------+
| | Link Layer Address | | FLOW_ID | PIF_ID |
| | Status | +===============================+
+-------------------------------|
| PIF_ID | FLOW RoutingPolicies |
| | Home Network Prefix |
| | Link Layer Address |
| | Status |
+-------------------------------+
| .... | .... |
+===============================+
Figure 4
The LIF table maintains the mapping between the LIF and each PIF
associated to the LIF (see P3). For each PIF entry the table should
store the associated Routing Policies, the Home Network Prefix
received during the SLAAC procedure, the configured Link Layer
Address (as described above) and the Status of the PIF (e.g. active,
not active).
The method by which the Routing Policies are configured in the UE is
out of scope of this document. It is however assumed that this
method is in place and that these policies are configured in the LIF
TABLE.
The FLOW table allows a LIF to properly route each IP flow to the
right interface (see P6). The LIF can identify flows arriving on its
Melia & Gundavelli Expires March 8, 2012 [Page 16]
Internet-Draft Logical Interface Support September 2011
PIFs and can map them accordingly for transmitting the corresponding
packets. For locally generated traffic (e.g. unidirectional outgoing
flows, mobile initiated traffic, etc.), the LIF should perform
interface selection based on the Flow Routing Policies. In case
traffic of an existing flow is suddenly received from the network on
a different PIF than the one locally stored, the LIF should interpret
the event as an explicit flow mobility trigger from the network and
it should update the PIF_ID parameter in the FLOW table. Similarly,
locally generated events from the PIFs or configuration updates to
the local policy rules can cause updates to the table and hence
trigger flow mobility.
Melia & Gundavelli Expires March 8, 2012 [Page 17]
Internet-Draft Logical Interface Support September 2011
7. Logical Interface Use-cases in Proxy Mobile IPv6
This section explains how the Logical interface support on the mobile
node can be used for enabling some of the Proxy Mobile IPv6 protocol
features.
7.1. Multihoming Support
A mobile node with multiple interfaces can attach simultaneously to
the Proxy Mobile IPv6 domain. Each of the attachment links are
assigned a unique set of IPv6 prefixes. If the host is configured to
use Logical interface over the physical interface through which it is
attached, following are the related considerations.
LMA's Binding Table
+================================+
+----+ | HNP MN-ID CoA ATT LL-ID |
|LMA | +================================+
+----+ | HNP-1 MN-1 PCoA-1 5 ZZZ |
//\\ | HNP-2 MN-1 PCoA-2 4 ZZZ |
+---------//--\\-----------+
( // \\ )
( // \\ )
+------//--------\\--------+
// \\
PCoA-1 // \\ PCoA-2
+----+ +----+
(WLAN) |MAG1| |MAG2| (WiMAX)
+----+ +----+
\ /
\ /
HNP-1 \ / HNP-2
\ /
\ /
+-------+ +-------+
| if_1 | | if_2 |
|(WLAN) | |(WiMAX)|
+-------+-+-------+
| Logical |
(LL-ID: ZZZ) | Interface | HNP-1::zzz/128
+-----------------| HNP-2::zzz/128
| MN |
+-----------------+
Figure 5: Multihoming Support
Melia & Gundavelli Expires March 8, 2012 [Page 18]
Internet-Draft Logical Interface Support September 2011
o The mobile node detects the advertised prefixes from the MAG1 and
MAG2 as the on link prefixes on the link to which the Logical
interface is attached.
o The mobile node can generate address configuration using stateless
auto configuration mode from any of those prefixes.
o The applications can be bound to any of the addresses bound to the
Logical interface and that is determined based on the source
address selection rules.
o The host has path awareness for the hosted prefixes based on the
received Router Advertisement messages. Any packets with source
address generated using HNP_1 will be routed through the interface
if_1 and for packets using source address from HNP_2 will be
routed through the interface if_2.
7.2. Inter-Technology Handoff Support
The Proxy Mobile IPv6 protocol enables a mobile node with multiple
network interfaces to move between access technologies, but still
retaining the same address configuration on its attached interface.
The protocol enables a mobile node to achieve address continuity
during handoffs. If the host is configured to use Logical interface
over the physical interface through which it is attached, following
are the related considerations.
Melia & Gundavelli Expires March 8, 2012 [Page 19]
Internet-Draft Logical Interface Support September 2011
LMA's Binding Table
+================================+
+----+ | HNP MN-ID CoA ATT LL-ID |
|LMA | +================================+
+----+ | HNP-1 MN-1 PCoA-1 5 ZZZ |
//\\ (pCoA-2)(4) <-change
+---------//--\\-----------+
( // \\ )
( // \\ )
+------//--------\\--------+
// \\
PCoA-1 // \\ PCoA-2
+----+ +----+
(WLAN) |MAG1| |MAG2| (WiMAX)
+----+ +----+
\ /
\ Handoff /
\ ----> / HNP-1
\ /
\ /
+-------+ +-------+
| if_1 | | if_2 |
|(WLAN) | |(WiMAX)|
+-------+-+-------+
| Logical |
(LL-ID: ZZZ) | Interface | HNP-1::zzz/128
+-----------------|
| MN |
+-----------------+
Figure 6: Inter-Technology Handoff Support
o When the mobile node performs an handoff between if_1 and if_2,
the change will not be visible to the applications of the mobile
node. It will continue to receive Router Advertisements from the
network, but from a different sub-interface path.
o The protocol signaling between the network elements will ensure
the local mobility anchor will switch the forwarding for the
advertised prefix set from MAG1 to MAG2.
o The MAG2 will host the prefix on the attached link and will
include the home network prefixes in the Router Advertisements
that it sends on the link.
Melia & Gundavelli Expires March 8, 2012 [Page 20]
Internet-Draft Logical Interface Support September 2011
7.3. Flow Mobility Support
For supporting flow mobility support, there is a need to support
vertical handoff scenarios such as transferring a subset of
prefix(es) (hence the flows associated to it/them) from one interface
to another. The mobile node can support this scenario by using the
Logical interface support. This scenario is similar to the Inter-
technology handoff scenario defined in Section 7.2, only a subset of
the prefixes are moved between interfaces.
Additionally, IP flow mobility in general initiates when the LMA
decides to move a particular flow from its default path to a
different one. The LMA can decide on which is the best MAG that
should be used to forward a particular flow when the flow is
initiated e.g. based on application policy profiles) and/or during
the lifetime of the flow upon receiving a network-based or a mobile-
based trigger.
As an example of mobile-based triggers, the LMA could receive input
(e.g.by means of a layer 2.5 function via L3 signaling [RFC5677])
from the MN detecting changes in the mobile wireless environment
(e.g. weak radio signal, new network detected, etc.). Upon receiving
these triggers, the LMA can initiate the flow mobility procedures.
For instance, when the mobile node only supports single-radio
operation (i.e. one radio transmitting at a time), only sequential
(i.e. not simultaneous) attachment to different MAGs over different
media is possible. In this case layer 2.5 signaling can be used to
perform the inter-access technology handover and communicate to the
LMA the desired target access technology, MN-ID, Flow-ID and prefix.
Melia & Gundavelli Expires March 8, 2012 [Page 21]
Internet-Draft Logical Interface Support September 2011
8. IANA Considerations
This specification does not require any IANA Actions.
Melia & Gundavelli Expires March 8, 2012 [Page 22]
Internet-Draft Logical Interface Support September 2011
9. Security Considerations
This specification explains the operational details of Logical
interface on an IP host. The Logical Interface implementation on the
host is not visible to the network and does not require any special
security considerations.
Melia & Gundavelli Expires March 8, 2012 [Page 23]
Internet-Draft Logical Interface Support September 2011
10. Authors
This document reflects contributions from the following authors
(listed in alphabetical order):
Carlos Jesus Bernardos Cano
cjbc@it.uc3m.es
Antonio De la Oliva
aoliva@it.uc3m.es
Yong-Geun Hong
yonggeun.hong@gmail.com
Kent Leung
kleung@cisco.com
Tran Minh Trung
trungtm2909@gmail.com
Hidetoshi Yokota
yokota@kddilabs.jp
Juan Carlos Zuniga
JuanCarlos.Zuniga@InterDigital.com
11. Acknowledgements
The authors would like to acknowledge prior discussions on this topic
in NETLMM and NETEXT working groups. The authors would also like to
thank Joo-Sang Youn, Pierrick Seite, Rajeev Koodli, Basavaraj Patil,
Julien Laganier for all the discussions on this topic.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Melia & Gundavelli Expires March 8, 2012 [Page 24]
Internet-Draft Logical Interface Support September 2011
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", September 2007.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", RFC 5844, May 2010.
12.2. Informative References
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC5072] Varada, S., "IP Version 6 over PPP", September 2007.
[RFC5677] Melia, T., Bajko, G., Das, S., Golmie, N., and JC. Zuniga,
"IEEE 802.21 Mobility Services Framework Design (MSFD)",
RFC 5677, December 2009.
[RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec,
"Address Mapping of IPv6 Multicast Packets on Ethernet",
RFC 6085, January 2011.
[TS23401] "3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; General
Packet Radio Service (GPRS) enhancements for Evolved
Universal Terrestrial Radio Access Network (E-UTRAN)
access.", 2009.
Authors' Addresses
Telemaco Melia (editor)
Alcatel-Lucent
Route de Villejust
Nozay 91620
France
Email: telemaco.melia@alcatel-lucent.com
Melia & Gundavelli Expires March 8, 2012 [Page 25]
Internet-Draft Logical Interface Support September 2011
Sri Gundavelli (editor)
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Email: sgundave@cisco.com
Melia & Gundavelli Expires March 8, 2012 [Page 26]
