One document matched: draft-seite-mif-connection-manager-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="bcp" docName="draft-seite-mif-connection-manager-02.txt"
ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<front>
<title>Connection Manager requirements</title>
<author fullname="Pierrick Seite" initials="P." surname="Seite">
<organization>France Telecom - Orange</organization>
<address>
<postal>
<street>4, rue du Clos Courtel, BP 91226</street>
<city>Cesson-Sevigne</city>
<code>35512</code>
<country>France</country>
</postal>
<email>pierrick.seite@orange-ftgroup.com</email>
</address>
</author>
<author fullname="Gaetan Feige" initials="G." surname="Feige">
<organization>Cisco</organization>
<address>
<postal>
<street>11 rue Camille Desmoulin</street>
<city>Issy les Moulineaux</city>
<code>92782</code>
<country>France</country>
</postal>
<email>gfeige@cisco.com</email>
</address>
</author>
<author fullname="Telemaco Melia" initials="T." surname="Melia">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street>Route de Villejust</street>
<city>Nozay</city>
<code>91620</code>
<country>France</country>
</postal>
<phone>+33672662903</phone>
<email>telemaco.melia@alcatel-lucent.com</email>
</address>
</author>
<author fullname="Juan-Carlos Zuniga" initials="JC." surname="Zuniga">
<organization>InterDigital</organization>
<address>
<postal>
<street>1000 Sherbrooke W</street>
<city>Montreal, QC</city>
<country>Canada</country>
</postal>
<email>juancarlos.zuniga.interdigital.com</email>
</address>
</author>
<date day="25" month="October" year="2010" />
<abstract>
<t>It is a common practice for multiple interface terminals to use a connection manager to perform provisioning domain selection and interface configuration. The concept of connection managers for personal computers is well known, and similar logic is now common in mobile phones that have multiple radio interfaces [3GPP TS 23.402]. The Problem Statement document highlights the lack of standardized behavior for terminals in regard to managing multiple interfaces and their respective properties. To address this issue, this document proposes a set of functional requirements for a generic MIF Connection Manager.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>As shown in <xref target="I-D.ietf-mif-current-practices"></xref>, it
is a common practice for multiple interfaces terminals to leverage on a
connection manager to perform provisioning domain selection and
interface configuration. The connection manager can make its decision
based on user preferences, applications inputs or many other criteria.
There are various ways to provide information to a connection manager
(static configuration, user provisioned, out-of- band mechanisms, etc)
and a large number of possible strategies that a connection manager can
implement to perform selection. This variety of situations may lead to
specific issues, as identified in <xref
target="I-D.ietf-mif-problem-statement"></xref>. For instance, issues
may rise up because connection managers do not behave in the same way
depending on the operating systems and/or platforms. High level API may
also differ across different operating systems and/or platforms. Also,
implementation of different connection manager on a same node may lead
to inconsistencies and unexpected behavior in interface selection. </t>
<t>Obviously, more consistency in connection managers behavior and API
specifications is needed for applications developers, operators, users,
etc. This document addresses this issue by specifying functional
requirements for a generic connection manager, and proposes a functional
architecture for the connection manager, describing the interfaces and
required functions. </t>
</section>
<section anchor="USE_CASES" title="Use-cases">
<section title="Provisioning domain selection">
<t>According to <xref target="I-D.ietf-mif-current-practices"></xref>
one of the basic operations of the connection manager is the selection
of the provisioning domain. This selection comes into play when the
MIF host bootstraps, or when it discovers a new provisioning domain.
Such provisioning domains can be:</t>
<t><list style="hanging">
<t hangText="o">Domain learned on a Ethernet or 802.11 interface
either from DHCP or IPV6 RA </t>
<t hangText="o">Domain associated with a 3GPP enabled interface
</t>
<t hangText="o">Domain associated with a WIMAX enabled interface
</t>
<t hangText="o">Domain associated with any otehr IP level
interface over other link layer technologies such as bluetooth,
802.15 </t>
</list>Domains are independent one from another and possibly IP
addresses / prefixes assigned by a domain to a host could overlap.
This is a valid configuration that the Connection Manager SHOULD
support. The selection could be based on various criteria, among them
are: <list style="symbols">
<t>preferences provided by the user,</t>
<t>policies provided by network operator,</t>
<t>quality of the radio link,</t>
<t>network resource considerations (i.e. available QoS, IP address
families, IP connectivity check,...),</t>
<t>Operating system hints (e.g. battery),</t>
<t>and so on...</t>
</list></t>
<t>In a MIF context, the Connection Manager must handle multiple
domains simultaneously in particular for host supporting multiple
access technologies. In this situation, when the user starts an
application, the Connection Manager SHOULD select the best domain
taking into account the application constraints besides aforementioned
selection criteria. Among these application constraints we can mention
for example the access restriction for a given application or minimum
required quality of service. By default, the Connection Manager MUST
select the provisioning domain provided by user and/or operator. If
the application is restricted to one provisioning domain, the
application MUST start on it. If the default provisioning domain is
not available, the application cannot start. If the application can
run over several provisioning domains, the Connection Manager SHOULD
select the provisioning domain which provides the best quality and/or
which satisfy the user preferences, operator policies, and service
provider preferences, e.g. selection of the access with lower cost. If
the user starts more than one application on a MIF host, the
connection manager SHOULD be able to select for each application the
most appropriate domain based on above mentioned criteria. </t>
</section>
<section title="Reselection">
<t>Once attached, if quality of the link degrades and/or the link
becomes unavailable and/or other domains with higher preferences
become available, the Connection Manager SHOULD re-select an
alternative provisioning domain.</t>
<t>If IP communication is ongoing and if IP session continuity must be
provided, the connection manager MAY trigger specific mobility
management mechanisms (e.g. trigger MIPv6 signalling <xref
target="RFC3775"></xref>) or associated configuration operations, e.g.
configuration of a logical interface for inter-access handover support
with PMIPv6 (as proposed in <xref
target="I-D.ietf-netext-logical-interface-support"></xref>). </t>
<t>Reselection may also happen following an attachment failure (at
Layer 2 or 3). For instance, the connection manager should select an
alternative provisioning domain if: <vspace blankLines="1" /> <list
style="symbols">
<t>the host fails to get L2 attachment;</t>
<t>the host has managed to get L2 attachment but fails to set up
the IP connectivity (e.g. cannot obtained a valid IP address);</t>
<t>the host has managed to get L2 attachment and IP connectivity,
but it has no access to the services (see <xref
target="I-D.ietf-mif-problem-statement"></xref> for details on MIF
issues).</t>
</list></t>
</section>
</section>
<section title="MIF Connection manager requirement">
<t>This section describes the generic framework of a MIF connection
connection manager.</t>
<section anchor="ARCHI" title="Functional architecture ">
<t>It can be deduced from the use-cases described in <xref
target="USE_CASES"></xref> that a connection manager SHOULD support at
least three main functions: <vspace blankLines="1" /> <list
style="numbers">
<t>initiation function: it monitors for events which possibly
required connection management operations. Events may be related
to access link characteristics, application hints, user triggers,
etc. When detecting an event which may require multiple interfaces
management operations (e.g. selection of a new provisioning
domain), the initiation function triggers the decision function
(see next item). </t>
<t>decision function: upon triggers and information fired by the
initiation Function, the decision function makes decision about
multiple interfaces management (e.g. select the best appropriate
provisioning domain to be used, source address selection, etc.).
The decision is also made using local information (e.g. policies,
user preferences) fetched from a local/remote repository. </t>
<t>execution function: once the decision made, the decision
function triggers the execution if required, e.g. attachment to
the targeted interface interface configuration, control of
associated mechanisms for communication continuity if needed (e.g.
configuration of a virtual interface, trigger mobile IP
procedures, and so on,….).</t>
</list></t>
<t>An example of a functional architecture of a Connection Manager is
given on <xref target="CM_ARCHI"></xref>. The Connection Manager
supports the functions described above and it implements interfaces
with all the involved actors (e.g., user, application, operator, etc.)
and with other functional modules on the terminal (i.e., access
monitoring, mobility management protocol, etc.). Interface endpoints
on the connection manager side are called Service Access Points
(SAPs). The following figure depicts the required SAPs in order to
allow other functional modules to interact with the Connection
Manager.
<figure align="center" anchor="CM_ARCHI"
title="A functional architecture for the connection manager">
<preamble></preamble>
<artwork align="left"><![CDATA[
+------------+ +--------+ +------------+ +------------+
|User Tools | | Appli. | | policies | |Authent. |
| | | | | server | | Framework |
+-----x------+ +---x----+ +------x-----+ +-----x------+
| | | |
_____x____ ____x_____ _____x______ ______x___
__ / user SAP \____ / Appli SAP\___ / Oper/cloud \__/ Auth. SAP\_
| \__________/ \__________/ \____________/ \__________/ |
| |
| Connection Manager |
| |
| +------------+ get info +------------+ |
| | Decision | ------------->| Repository | |
| | | <------------ | | |
| +------------+ send info +------------+ |
| __________ __________ __________ ________ |
|_ / 3GPP SAP \____ / Exec. SAP\_____ /WiFi SAP \____/OS SAP \___|
\__________/ \__________/ \__________/ \________/
x x x x
| +------------x-----------------+ | |
| | virtual Intf, | | +---- x------+
| | MIP stack, IP stack | | | OS |
| +------------------------------+ | +------------+
+--- x-------+ +-----x------+
|3GPP Intf. | |WiFi Intf. |
| | | |
+------------+ +------------+
]]></artwork>
</figure></t>
</section>
<section title="Interfaces">
<t>This section focuses on the interfaces endpoints on the connection
manager side. It is reminded that interface endpoints on the
connection manager side are called Service Access Points (SAPs). </t>
<section title="Network SAP">
<t>The Network SAP relates to features directly integrated with the
link layer access technologies and network interface. For instance,
the Network SAP should provide the following capabilities: <vspace
blankLines="1" /> <list style="symbols">
<t>Switching ON/OFF a specific network interface ( 3GPP APN PDP
context, 802.11 ESSID, …).</t>
<t>Provision the MN with the appropriate Access Point Name (APN)
to be used to access the 3GPP network (it should be noted that
in the 3GPP context different APNs can be used to access
different services and that according to EPC specifications
there is a one to one mapping between one APN and one IP
address).</t>
<t>Requesting an active network scan.</t>
<t>Switching on/off a passive network scan (e.g. a scan which
does not disturb current traffic flows).</t>
<t>An early link loss detection trigger ( e.g. link going down).
This should be based on local algorithms implemented within the
monitoring feature of the interfaces. The Network SAP should
have the capability to activate a specific supported algorithm
as such a early link loss detection will vary according to other
parameters such as the speed of the terminal, the neighboring
environment of the same technology.</t>
<t>A link lost trigger (e.g. link down).</t>
<t>A Link handover trigger (disconnect and reconnect to the same
network), this is used currently to verify the IP properties of
the newly attached base station.</t>
<t>List of neighboring base stations of the same technology and
if possible of any technology.</t>
<t>QOS: Interface queue packet loss.</t>
<t>Information brought by Layer 2 (e.g. IEEE 802.21 <xref
target="802.21"></xref>).</t>
<t>Access to information about the connected network provided y
mechanisms such as 802.11u.</t>
</list></t>
</section>
<section title="User SAP">
<t>The User SAP SHOULD allow the user to give his preferences
expected to influence the interface management, e.g. modification of
the application profiles, preferred provisioning domain per
application, etc. These preferences CAN be stored by the connection
manager in a local repository. </t>
</section>
<section title="Operator SAP">
<t>The Operator SAP provides services between the client and an
operator which could be either the network operator of any service
operator over the top. These services are not integrated within the
link layer protocols. If they were, these SAP primitives would then
be migrated to the Network SAP. The Operator SAP SHOULD provide the
following capabilities: <vspace blankLines="1" /> <list
style="symbols">
<t>Neighboring information on networks (e.g. 802.21 MIH server
(<xref target="802.21"></xref>) or 3GPP ANDSF (<xref
target="TS23.402"></xref>). Query of neighboring environment
(e.g. list of neighbor networks). This could be under a map
format. This can also be achieved depending on network
capabilities by the Network SAP.</t>
<t>Policy interface for allowing the network to push connection
policies and flow mobility policies. These policies COULD be one
time policies with immediate effect if the network operator
wants to change the behaviour of the client at once point in
time. These policies SHOULD only be accepted if the client has
agreed to such behaviour and not set an override policy with
higher </t>
</list></t>
</section>
<section title="Cloud SAP">
<t>The cloud SAP is the operator SAP dedicated to Over The Top
service provider. Obviously, this SAP is very similar to the
operator SAP, the interface between MIF host and server uses same
mechanisms than operator SAP. But, in this case, services MAY be
specific to OTT operator. More specifically: <vspace
blankLines="1" /> <list style="symbols">
<t>The Cloud SAP should allow cloud services to request sensor
information from the client device.</t>
<t>The Cloud SAP should allow a client to send sensor
information to a cloud server( e.g. location and speed,
temperature, humidity, available networks and their measured
quality, …).</t>
<t>The cloud SAP could exchange information with Over-the-top
services (e.g. geolocation).</t>
</list></t>
</section>
<section title="OS SAP">
<t>The OS SAP makes interface with terminal Operating system. This
SAP could provide the following capabilities: <vspace
blankLines="1" /> <list style="symbols">
<t>Notification of IP address network assignment and
notification of any extra information about this IP address such
as the scope of an address (locally serviced or anchor based in
case the network was performing PMIP/GTP services, <xref
target="RFC3484"></xref>, <xref target="RFC5014"></xref>).
Typically, these informations are needed for the control of
virtual( CMIP / DSMIP / VPN(Enterprise & I-WLAN )
)/physical(PMIP / GTP ) interfaces and source address selection
mechanisms. </t>
<t>Notification of DHCP events such as IP address assignment,
DHCP options such as ANDSF extensions (<xref
target="I-D.das-mipshop-andsf-dhcp-options"></xref>).</t>
<t>Power consumption triggers / queries.</t>
<t>Energy status triggers / queries.</t>
</list></t>
</section>
<section title="Execution SAP">
<t>The execution SAP allows to command actions on connectivity
layers (e.g., IP configuration, trigger IP session continuity
management protocols). The Execution SAP is tightly integrated with
OS features and capabilities. The Execution SAP SHOULD provide the
following capabilities: <vspace blankLines="1" /> <list
style="symbols">
<t>Provisioning of static IP addresses.</t>
<t>Generation of automatic WEB Auth methods and insertion into
the routing table of the default route once authentication
successful.</t>
<t>DHCP state machine control : <list style="symbols">
<t>let DHCP know it must wait for default route into routing
table insertion.</t>
<t>IP address request on demand, in particular for IPv4
addresses.</t>
</list></t>
<t>Control of OS virtual interfaces and binding (bridge or
routed mode ) to physical interface.</t>
</list></t>
</section>
<section title="Application SAP">
<t>The Application SAP allows to exchange application triggers (e.g.
application start/stop, notification for QoS requirements) and to
provide notification of selection decision from the connection
manager towards applications (i.e., to let the applications change
their behavior if it is appropriate). Typically, the Application SAP
SHOULD: <vspace blankLines="1" /> <list style="symbols">
<t>allow applications to register with the Connection Manager
for receiving notifications of other SAP interfaces. The
Connection Management behaves as a message routing entity in
this case with rules and filters. As an example in session
persistency an application may want to know of a “link
going down event” in order to anticipate any changes
required rather than reacting to a “link down”
event.</t>
<t>allow applications a feedback mechanism into the Connection
Manager for giving real time updates on the QOS observed.</t>
<t>Allow applications to query the identity store function
within the Connection manager and retrieve authentication
methods.</t>
<t>Allows some application to provide specific information to
feed the decision function(e.g. GPS positioning or
velocity).</t>
<t>terminal built in sensors listing and query/trigger of supported
options.</t>
</list></t>
<t>it is worth mentioning that the data traffic is exchanged
directly between the applications and the transport/IP layers,
through the standard socket, i.e. without traversing the Connection
Manager.</t>
</section>
<section title="Authentication SAP">
<t>The Authentication SAP provides access to all supported
authentication protocols in a shared fashion for all interfaces. For
instance, these protocols MAY include: <vspace blankLines="1" />
<list style="symbols">
<t>802.1x</t>
<t>EAP frameworks</t>
<t>WEB based mechanism such as WISPR 1.0 and WISPR 2.0, IPASS,
…</t>
</list></t>
<t>In addition to network authentication solutions, the
Authentication SAP can provide shared mechanisms for applications to
use Single-Sign-On solutions such as Open ID, HTTP digest or any
other proposal.</t>
</section>
</section>
<section title="Functions of the connection manager">
<section title="Initiation">
<t>According to <xref target="ARCHI"></xref> The decision is made on
triggers and the parameters provided by the initiation function.
This function SHOULD manage, at least, the following triggers:
<vspace blankLines="1" /> <list style="symbols">
<t>Access link triggers (via Network SAP): used to compute
network triggers like "access link is going down", "discover a
new access link", etc. This module is likely to implement a
technology dependant interface towards the network specific
layers in order to get e.g., radio/QoS measurements.</t>
<t>Application triggers (via Application SAP): application
starting or closing should trigger the decision process to
select the most appropriate provisioning domain.</t>
<t>User/Operator hints (via User/Cloud/Operator SAPs): these
hints may be modification of preferences, operator policies,
manual selection, etc.</t>
</list></t>
</section>
<section title="Decision">
<t>The decision function is the core of the connection manager, it
consists in two main functional blocks: <vspace blankLines="1" />
<list style="symbols">
<t>Decision Algorithm: when triggered by a given event (e.g..,
network, user/operator, or applicative), this module selects the
data path (e.g. provisioning domain, source address, ...). the
Decision Algorithm consults, if necessary the local policies
from the repository, and then it makes decision which is
transmitted to the execution function.</t>
<t>Repository: this function stores static inputs for the
decision-making process that will be used to feed the selection
algorithm . For instance, such information can be related to
user's preferences, operator's policies or application profiles
(storing application needs, in term of QoS, and per application
preferences for access). These information could be provisioned
to the terminal via out-of-band mechanisms ( e.g., download of
policies at bootstrapping via link layer mechanisms, during DHCP
process <xref target="I-D.sarikaya-mif-dhcpv6solution"></xref>
or via 3GPP ANDSF (<xref target="TS23.402"></xref>)).
Information could be also provisioned through dedicated
application, for instance allowing the user to indicate its
preferences (e.g. manage its list of preferred access
network).</t>
</list></t>
<t>Several criteria could be used to make a decision. For instance,
the following criteria COULD be considered: <vspace
blankLines="1" /> <list style="symbols">
<t>User Profile (user's rights in terms of QoS, roaming partners
allowed, etc.).</t>
<t>User/Operator ordered list of preferred Wi-Fi networks.</t>
<t>Access preference based on application type and destination,
e.g. IPTV is preferred on WLAN when available.</t>
<t>Link Quality: signal strength (assuming radio link), QoS
(throughput, packet loss, delay, etc.).</t>
<t>Application QoS requirements: throughput required per
application type/class, maximum accepted packet loss.</t>
<t>Source address selection policy, i.e. the connection manager
may want to use such interface if IPv6 is available then select
the source address (e.g. use Global address for Internet
destination and LLA for on-net services).</t>
</list></t>
</section>
<section title="Execution function">
<t>After making a decision, the execution function is triggered,
e.g. operation for attachment to a new interface, IP connectivity
check, source address selection, trigger other virtual interface
like tunnel interface (e.g. IPSEC) or steer the mobility protocol
e.g. MIPv6 <xref target="RFC3775"></xref>), if IP session continuity
must be ensured. <xref target="CM_SM"></xref> shows interaction
between functions of the generic MIF connection manager. </t>
<t><figure align="center" anchor="CM_SM"
title="State machine of connection manager">
<preamble></preamble>
<artwork align="left"><![CDATA[
+-----------------+ +-----------------+
|Event Monitoring | |policies, address|
|(e.g. monitoring | |selection policy,|
| access link) | |preferences,... |
+-----------------+ +-----------------+
|| || ,---------.
|| || ,-' `-.
\/ \/ | Execution |
,---------. ,---------. | (connectivity |
,-' `-. ,-' `-. | check, |
( Initiation |------>( Decision )--->| interface |
`-. ,-' `-. ,-' | control, |
`---------' `---------' | Handover |
^ ^ | ^ | management,.. ,
| | fail | | `---------------'
| +------(e.g. no access<---+ | | |
| available) | | |
| +-- reselection <---+ |
| due to execution |
| failure |
| |
+---------------- execution completed <-----------------+
]]></artwork>
</figure></t>
<section title="IP connectivity check">
<t>This sub-function of the execution deals with IP connectivity
verification (via OS SAP). This function triggers reselection in
case of layer 3 failure, during attachment or when a handover
happens and the layer 2 is still connected. </t>
<t>Various situations may occur and various mechanisms CAN be used
to ensure IP connectivity, for example: <vspace blankLines="1" />
<list style="symbols">
<t>While a client moves from one 802.11 access point to
another, both having the same (E)SSID does not mean they are
part of the same network. Hence the client SHOULD verify its
IP address parameters. In order to avoid a complete
reconfiguration when not needed; initial checks can be
performed. Such mechanisms are ARPing of the default gateway
or PING of that same default gateway. If provisioning domain
parameters, such as MAC address and IP, are similar then it
can be expected the client is on the same network and avoid
hence a full IP renewal process. </t>
<t>When a client associates to a network it MAY be required to
authenticate over HTTP and would have limited connectivity
initially. Mechanisms are needed to check access to the
authentication web portal.</t>
<t>The IP connectivity can be limited if there is a high level
of layer 2 errors. When on the edge of a 802.11 cell, the
radio parameters may be such that small IP packets would go
through but higher MTU packets would not get through. In this
case a client may get an IP address but not be capable of
further utilising it. </t>
<t>The end to end IP connectivity could be disturbed. A
mechanism is needed which would also differentiate between no
connectivity at all versus just some disturbed destinations
only. </t>
</list></t>
</section>
<section anchor="MAPPING" title="IP address and interface mapping">
<t>In a MIF context, the notion of path is indeed a key issue
since even a single interface could be providing multiple paths,
e.g. in IPv6 when delivering multiple prefixes. For example,
current IP mobility solutions use one IP address for local access
and another for anchored traffic through a mobility anchor (i.e.
HA or LMA). The mechanism for selecting anyof the available paths
SHOULD reside within the Connection Manager. </t>
<t>Selection of a source address MUST at least rely on default
address selection as per <xref target="RFC3484"></xref> which
defines algorithms for source and destination IP address
selections. However, more sophisticated selection mechanism COULD
also be provided. For instance, IP flows can be mapped
independently to different interfaces. Also, dynamic information
about the status of an interface CAN be used when deciding the
best available interface. </t>
<t>The Connection Manager SHOULD select the path (i.e. source
address) based on dynamic local information (e.g. access
monitoring)and current policies (i.e., operator, user,
application, etc.). Once the decision is made the execution
function MUST configure, in a transparent manner for applications,
the appropriate mapping of IP communication with the selected
local interface. </t>
<t>Information on IP address type (e.g. local, global, assigned to
a virtual interface, etc.) MUST be known and used by the
Connection Manager as an input for path selection. This
information MAY be provided by specific extensions to IP address
allocation mechanisms (e.g. DHCP, IPCP, RA, or any other). </t>
<t>A typical example of IP address and interface mapping is the
MultiPDN Access Connectivity (MAPCON) support currently being specified in 3GPP.
MAPCON is a 3GPP technology (see <xref target="mapcon"></xref> 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 <xref target="TS23.402"></xref>).
According to 3GPP, a one to one mapping exists between a PDN
connection and an APN. That is, every time that a terminal 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 terminal 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 of the available wireless
channels.</t>
<t>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 exist and IP address selection has been studied in <xref
target="RFC3484"></xref> and <xref target="RFC5014"></xref>. In
particular <xref target="RFC5014"></xref> provides socket API
extensions to influence the rules specified in <xref
target="RFC3484"></xref> (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.</t>
<t>The use of the CM 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 reveiced through the Operator SAP 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 MN configuration and
associated CM operations.</t>
<figure alt="" anchor="mapcon" title="Connection Manager for MAPCON-enabled terminal">
<artwork><![CDATA[
+----------------------------+
| TCP/UDP |
Session to IP -- | |
Address binding < +---(MN-IP1)---(MN-IP2)------+
-- | IP Layer |
IP Address(es) -- | |
binding < +----------------------------+
-- | L2 | L2 |
| (IF#1) | (IF#2) |
+--------------+-------------+
| L1 | L1 |
| | |
+--------------+-------------+
]]></artwork>
</figure>
</section>
<section title="Virtual Interface Configuration">
<t>Work has been carried out in the NetExt WG to define ways in
which a Logical Interface can help inter-access handover and
IP Flow Mobility (IFOM) for Proxy Mobile IPv6 <xref
target="I-D.ietf-netext-logical-interface-support"></xref>. The
NetExt Logical Interface terminology is equivalent to the MIF
Virtual Interface (VIF) terminology. This VIF allows a mobile
node sharing a set of IP addresses on multiple physical interfaces.
The same VIF can also help other mobility management solutions
like 3GPP GPRS Tunnelling Protocol (GTP) or DSMIPv6 and it can
add benefits to multi-access scenarios such as 3GPP Multi Access
PDN Connectivity (MAPCON) <xref target="S2-103593"></xref>. </t>
<t>For some implementations, the VIF is known as the master, and
the different sub-interfaces that are mapped below it are
referred-to as slaves. In most cases, the VIF will map several
physical network interfaces. Nevertheless, virtual interfaces
themseleves could be slaves of a higher level abstracted VIF.</t>
<t><xref target="CM_VF"></xref> illustrates the relationship
between the connection manager and the virtual interface. </t>
<figure align="center" anchor="CM_VF"
title="Connection Manager and Virtual Interface (VIF) relationship">
<artwork align="center"><![CDATA[
+---------------------+
| TCP/UDP |
+---------------------+
| IP |
+---------------------+ +------------+
| Virtual | | Connection |
| Interface |<---| Manager |
+---------------------+ +------------+
+---------+ +---------+ ^
| if_1 | | if_2 | |
| (WLAN) | | (3GPP) |<--------+
+---------+ +---------+ IF/CM interface
]]></artwork>
</figure>
<t>The connection manager SHOULD control the mapping between the
VIF and the sub-interfaces. The mapping control MUST take into
account class of the IP address, which can differ if:
<vspace blankLines="1" /> <list style="symbols">
<t>this IP is learned directly from the network with PMIP/GTP
service, in which case the IP is on the physical interface and
must be bridged onto the virtual interface.</t>
<t>this IP is assigned to a tunnel originating from the
virtual interface and bound to a physical interface getting an
IP address allocation from a non PMIP enabled network
(e.g; CMIP, DSMIP, VPN)</t>
</list>
</t>
<t>In order to support IP flow mobility and other mobility
features, the VIF MUST accept packets arriving on any of its
sub-interfaces, as long as the destination IP address is a valid
local address. Also, when the link layer technology of the
sub-interface encapsulates IP packets into frames, the link-layer
identifier of the VIF SHOULD be used in the link-layer header of
frames transmitted over this sub-interface. </t>
<t>Independent flows need to be monitored at the VIF. Flows can be
identified by a 5-tuple comprised of source address, destination
address, source port, destination port and protocol. Once a flow
is identified, it SHOULD be 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). </t>
<t>For IPv6, the VIF 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 then forwarded though this new sub-interface. </t>
<t><xref target="PMIP"></xref> depicts the use of the Virtual
Interface in a terminal supporting PMIPv6 / GTP advanced mobility
features in the network, and <xref target="DSMIP"></xref> shows
the use of the Virtual Interface in a terminal with a DSMIPv6 stack.</t>
<figure anchor="PMIP" title="VIF for terminal supporting network-based Proxy Mobile IPv6 / 3GPP GTP IFOM">
<artwork><![CDATA[
+----------------------------+
| TCP/UDP |
Session to IP --| |
Address binding < +----------------------------+
--| IP |
IP Address(es) ---| |
binding < +----------(MN-HoA)----------+
---| Logical Interface |
Logical to | |
Physical --> +----------------------------+
Interface | L2 | L2 | | L2 |
mapping |(IF#1)|(IF#2)| ..... |(IF#n)|
+------+------+ +------+
| L1 | L1 | | L1 |
| | | | |
+------+------+ +------+]]></artwork>
</figure>
<figure anchor="DSMIP" title="VIF in terminal with DSMIPv6 stack">
<artwork><![CDATA[
+----------------------------+
| TCP/UDP |
Session to IP --| |
Address binding < +----------(MN-HoA)----------+
--| IP in IP tunneling |
IP Address(es) ---| |
binding < +---(MN-CoA1)---(MN-CoA2)----+
---| IP Layer |
| |
+----------------------------+
| L2 | L2 |
| (IF#1) | (IF#2) |
+--------------+-------------+
| L1 | L1 |
| | |
+--------------+-------------+]]></artwork>
</figure>
</section>
</section>
</section>
</section>
<section title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Considerations">
<t>This document has no actions for IANA.</t>
</section>
<section title="Contributors">
<t>The following people contributed to this document:</t>
<t><list style="empty">
<t>Lucian Suciu</t>
<t>France telecom - Orange</t>
<t>lucian.suciu@orange-ftfroup.com</t>
</list></t>
<t><list style="empty">
<t>Patrice Nivagiolli</t>
<t>Cisco</t>
<t>pnivaggi@cisco.com</t>
</list></t>
</section>
<section title="Acknowledgements">
<t>The authors would like to acknowledge (in no specific order) Sri
Gundavelli, Hidetoshi Yokota, Hui Deng and Dapeng Liu
for all the fruitful discussions on this topic.</t>
</section>
</middle>
<back>
<references title="Informative References">
<?rfc include="reference.RFC.3484" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3775" ?>
<?rfc include="reference.RFC.5213" ?>
<?rfc include="reference.I-D.ietf-mif-problem-statement" ?>
<?rfc include="reference.I-D.ietf-mif-current-practices" ?>
<?rfc include="reference.I-D.cao-mif-analysis" ?>
<?rfc include="reference.I-D.melia-netext-logical-interface-support"
?>
<?rfc include="reference.I-D.ietf-netext-logical-interface-support"?>
<?rfc include="reference.RFC.5014"?>
<?rfc ?>
<?rfc include="reference.I-D.das-mipshop-andsf-dhcp-options" ?>
<?rfc include="reference.I-D.sarikaya-mif-dhcpv6solution"
?>
<reference anchor="TS23.402">
<front>
<title>3GPP TS 23.402; Architecture enhancements for non-3GPP
accesses</title>
<author>
<organization>3GPP</organization>
</author>
<date year="2010" />
</front>
</reference>
<reference anchor="S2-103593">
<front>
<title>
S2-103593 - Virtual Interface Support on UE
- Requirements and Properties</title>
<author>
<organization>3GPP</organization>
</author>
<date year="2010" />
</front>
</reference>
<reference anchor="802.21"
target=" http://www.ieee802.org/21/private/Published%20Spec/ 802.21-2008.pdf">
<front>
<title>IEEE Standard for Local and Metropolitan Area Networks - Part
21: Media Independent Handover Services", IEEE LAN/MAN Std
802.21-2008, January 2009.</title>
<author>
<organization>IEEE</organization>
</author>
<date year="2010" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:55:51 |