MIF Working Group JC.Zuniga
Internet Draft InterDigital Communications, LLC
Intended status: Best Current Practice T.Melia
Expires: April 18, 2011 Alcatel-Lucent
October 18, 2010
Logical Interface (LIF) Implementation Guidelines
draft-zuniga-mif-lif-implementation-guidelines-00.txt
Abstract
A Logical Interface is a software module internal to the host that is
available in all popular operating systems. The use of this Logical
Interface allows supporting different network-based mobility
management solutions. In the NETEXT WG, work has been carried out to
define ways in which a Logical Interface can help IP flow mobility
(IFOM) for Proxy Mobile IPv6 [I-D.draft-ietf-netext-logical-
interface-support]. The same Logical Interface construct can help
other mobility management solutions like 3GPP GPRS Tunnelling
Protocol (GTP), and it can add benefits to multi-access scenarios
such as 3GPP Multi Access PDN Connectivity (MAPCON). This document
provides guidelines for the implementation and configuration of a
generic Logical Interface.
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 18, 2011.
Zuniga, et al. Expires April 18, 2011 [Page 1]
Internet-Draft LIF Implementation Guidelines October 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.
Table of Contents
1. Introduction...................................................2
2. Conventions and Terminology....................................3
3. Logical Interface (LIF)........................................3
3.1. Description...............................................3
3.1.1. Usage in PMIPv6......................................4
3.1.2. Usage in GTP.........................................4
3.1.3. Usage in MAPCON......................................5
3.2. Implementation Guidelines.................................6
3.2.1. Policy management....................................6
3.2.2. Interface configuration..............................6
3.2.3. Flow mapping.........................................6
4. Security Considerations........................................7
5. IANA Considerations............................................7
6. References.....................................................7
6.1. Normative References......................................7
6.2. Informative References....................................7
7. Acknowledgments................................................8
Authors' Addresses................................................8
1. Introduction
A Logical Interface (LIF) is a construct internal to the operating
system. It is an approach where the link-layer implementation hides
the physical interfaces from the IP stack in the host. The IP stack
can bind one or many IPv4 and/or IPv6 addresses onto this interface.
Zuniga, et al. Expires April 18, 2011 [Page 2]
Internet-Draft LIF Implementation Guidelines October 2010
The basic LIF function is widely available in all popular operating
systems. Many applications such as Mobile IP client [RFC3775], IPsec
VPN client [RFC4301] and L2TP client [RFC3931] rely on this semantic
for their protocol implementation.
This basic LIF functionality can be expanded for achieving more
advanced mobility features. For instance, in the NETEXT WG work has
been carried out to define requirements on this Logical Interface to
support IP flow mobility (IFOM) for Proxy Mobile IPv6 [I-D.draft-
ietf-netext-logical-interface-support]. Beyond Proxy Mobile IPv6, the
use of a LIF can also help supporting IP flow mobility for 3GPP GPRS
Tunnelling Protocol (GTP), and similarly it can add benefits to other
multi-access scenarios such as 3GPP Multi Access PDN Connectivity
(MAPCON) [TD S2-103593].
This document describes the guidelines to implement and configure a
generic LIF module to enable the aforementioned mobility and multi-
access features.
2. Conventions and Terminology
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].
This document uses the terminology defined in [RFC5213], [RFC3775],
and [RFC3810].
3. Logical Interface (LIF)
3.1. Description
The LIF is a software construct that presents itself to higher layers
(i.e. IP) as a normal single interface. However, instead of providing
access to a single physical or network interface (i.e. NIC), it can
bond one or several network interfaces. As a result, an IP layer that
binds to a single LIF will potentially encompass access to several
physical interfaces. The actual specific data packet delivery to the
different network interfaces is fully controlled by the LIF and it is
also hidden to the IP layer.
For some implementations, the LIF is known as the master, and the
different sub-interfaces that are bonded below it are referred to as
slaves. In most cases, the LIF will bond several physical network
interfaces. Nevertheless, virtual interfaces (e.g. VPN) can also be
treated as slaves and be bonded by the LIF.
Zuniga, et al. Expires April 18, 2011 [Page 3]
Internet-Draft LIF Implementation Guidelines October 2010
Although the main purpose of the available LIF modules is to provide
for link aggregation and redundancy, it has been shown that some of
the LIF functionalities can be expanded to support more advanced
features, like multi-access handovers and IP flow mobility.
3.1.1. Usage in PMIPv6
Proxy Mobile IPv6 [RFC5213] is a network-based approach to solving
the IP mobility problem. In a Proxy Mobile IPv6 (PMIPv6) domain, the
Mobile Access Gateway (MAG) behaves as a proxy mobility agent in the
network and performs the mobility management on behalf of the Mobile
Node (MN) or IP host. The Local Mobility Anchor (LMA) is the home
agent for the MN and the topological anchor point.
At present, there is work going on in the NETEXT working group to
extend the basic PMIPv6 functionality to support inter-access
handovers and IP flow mobility [I-D.draft-bernardos-netext-pmipv6-
flowmob-00]. As part of this work, the LIF has been identified as a
critical element in the MN required to support these IP flow mobility
and inter-access handover features. A basic set of LIF
functionalities has been identified in the group to support multi-
homing, inter-technology handovers and IP flow mobility in a Proxy
Mobile IPv6 network [I-D.draft-ietf-netext-logical-interface-
support].
3.1.2. Usage in GTP
Another network-based mobility approach proposed in 3GPP is based on
the GPRS Tunnelling protocol (GTP) [TS 23.402]. Similarly to the
PMIPv6 architecture, the PDN-GW behaves as a single anchor point and
the Serving Gateway and ePDG perform the attachment functions on
behalf of the MN.
Since GTP tunnels between the gateways and the anchor are transparent
to the mobile, the LIF at the MN can perform the exact same actions
on traffic flows regardless of the network-based mobility solution.
This means that a LIF configured to support the PMIPv6 case can also
support the GTP scenario without any modifications.
Zuniga, et al. Expires April 18, 2011 [Page 4]
Internet-Draft LIF Implementation Guidelines October 2010
+----------------------------+
| TCP/UDP |
Session to IP --| |
Address binding < +----------------------------+
--| IP |
IP Address(es) ---| |
binding < +----------(MN-HoA)----------+
---| Logical Interface |
Logical to | |
Physical --> +----------------------------+
Interface | L2 | L2 | | L2 |
bonding |(IF#1)|(IF#2)| ..... |(IF#n)|
+------+------+ +------+
| L1 | L1 | | L1 |
| | | | |
+------+------+ +------+
Figure 3: LIF for Proxy Mobile IPv6 / 3GPP GTP
3.1.3. Usage in MAPCON
MAPCON is a 3GPP technology and refers to the capability of the
Evolved Packet Core (EPC)network to configure and maintain two or
more PDN connections for a given mobile device across heterogeneous
wireless access networks. According to 3GPP, a one to one mapping
exists between a PDN connection and an APN. That is, every time that
a UE requests to activate a specific APN (either resolved to the same
P-GW or to different P-GWs) the network assigns a new IP address (v4,
v6 or v4v6). This APN (or IP address) can be configured on a 3GPP
network at time T0 and moved at time T1 to the WLAN network. It
derives that all the sessions associated to this IP address (alias
Home Network Prefix) are handed over from the 3GPP to the non 3GPP
access network. If the UE has configured two different APNs on the
3GPP access network, after the handover procedure takes place it will
continue to use one APN for each wireless channel.
In a 3GPP context and from an application perspective, the selection
of an IP address corresponds to map a specific application to a given
APN. In the IETF world the APN concept does not exists and IP address
selection has been studied in [RFC3484] and [RFC5014]. In particular
[RFC5014] provides socket API extensions to influence the rules
specified in [RFC3484] (e.g. prefer a public IPv4 address over a
private one, prefer a HoA over a CoA). However, such extensions do
not consider the particular requirements imposed by 3GPP.
Zuniga, et al. Expires April 18, 2011 [Page 5]
Internet-Draft LIF Implementation Guidelines October 2010
The use of the LIF in the context of the MAPCON scenario simplifies
the operations executed at the mobile device. The routing of flows to
interfaces is achieved by means of the policies in the LIF layer and
not according to the IP address destination. In this sense the
routing operations at the MN are extremely simplified with respect to
the extensive use of multiple interfaces and advance routing
capabilities. The granularity for routing can for instance be based
on prefixes or flows, providing great flexibility to the LIF
implementation and associated CM operations.
3.2. Implementation Guidelines
3.2.1. Policy management
LIF policies can be either pre-configured or dynamically configured
on a host through some external protocol or function (e.g. OMA DM,
IEEE 802.21 IS, etc). Normally, these policies MAY be configured and
enforced onto the LIF by a Connection Manager (CM) [I-D.draft-seite-
mif-connection-manager]. The CM SHOULD be in charge of managing the
different sets of policies and enforcing them in a coherent manner.
The mapping between physical and virtual network interfaces and the
LIF SHOULD first follow the appropriate network-based policies and
then the user-based policies. In this manner, network-based features
such as IFOM can be supported.
3.2.2. Interface configuration
A LIF MUST accept packets arriving on any of its sub-interfaces, as
long as the destination IP address is a valid local address.
The LIF CAN by default bond all available sub-interfaces. However, if
a policy is defined where only some interfaces are considered, for
instance for IFOM purposes, the LIF SHOULD only bond the sub-
interfaces defined in the policy.
When the link layer technology of the sub-interface encapsulates IP
packets into frames, the link-layer identifier of the LIF SHOULD be
used in the link-layer header of frames transmitted over this sub-
interface.
3.2.3. Flow mapping
In order for the LIF to support IFOM, independent flows need to be
monitored at the LIF. Flows can be identified by a 5-tuple comprised
of source address, destination address, source port, destination port
Zuniga, et al. Expires April 18, 2011 [Page 6]
Internet-Draft LIF Implementation Guidelines October 2010
and protocol. Once a flow is identified, it is mapped to the sub-
interface that has first been used to perform the packet transmission
and reception functions for this specific flow. This mapping SHOULD
be kept for the lifespan of the flow (e.g. TCP session).
For IPv6, the LIF MUST be aware of the hosted prefixes based on the
received Router Advertisement (RA) messages. For instance, provided
that RAs HNP1 are received on interface if1, any packet with source
address generated using HNP1 SHOULD be forwarded through interface
if1.
In case packets from a certain flow are suddenly received on a
different sub-interface, an update to the flow mapping table COULD be
done so that the corresponding packets are now forwarded though this
new sub-interface. This case is especially needed to support the IFOM
as described in [I-D.draft-ietf-netext-logical-interface-support].
4. Security Considerations
This draft discusses the operations of existing protocols without
modifications. It does not introduce new security threats beyond the
current security considerations of PMIPv6 [RFC5213].
5. IANA Considerations
This document makes no request of IANA.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
Zuniga, et al. Expires April 18, 2011 [Page 7]
Internet-Draft LIF Implementation Guidelines October 2010
[RFC5014] Nordmark, E., Chakrabarti, S., and Laganier, J. "IPv6
Socket API for Source Address Selection", RFC 5014,
September 2007.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[I-D.draft-ietf-netext-logical-interface-support]
Melia, T. Ed., Gundavelli, S. Ed., "Logical Interface
Support for multi-mode IP Hosts", draft-netext-logical-
interface-support-00 (work in progress), August 2010.
[I-D.draft-seite-mif-connection-manager]
Seite, P., Feige, G. "Connection Manager Requirements",
draft-seite-mif-connection-manager-01 (work in progress),
July 2010.
[TD S2-103593]
3GPP TD S2-103593, Cisco, "Virtual Interface Support on UE
- Requirements & Properties", 2010.
[TS 23.402]
3GPP, "3GPP TS 23.402; Architecture enhancements for non-
3GPP accesses", 2010.
7. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Juan Carlos Zuniga
InterDigital Communications, LLC
Email: JuanCarlos.Zuniga@InterDigital.com
Telemaco Melia
Alcatel-Lucent
Email: telemaco.melia@alcatel-lucent.com
Zuniga, et al. Expires April 18, 2011 [Page 8]