One document matched: draft-seite-mif-connection-manager-02.txt
Differences from draft-seite-mif-connection-manager-01.txt
Network Working Group P. Seite
Internet-Draft France Telecom - Orange
Intended status: BCP G. Feige
Expires: April 28, 2011 Cisco
T. Melia
Alcatel-Lucent
JC. Zuniga
InterDigital
October 25, 2010
Connection Manager requirements
draft-seite-mif-connection-manager-02.txt
Abstract
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.
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 April 28, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Seite, et al. Expires April 28, 2011 [Page 1]
Internet-Draft Connection Manager requirements October 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Provisioning domain selection . . . . . . . . . . . . . . 3
2.2. Reselection . . . . . . . . . . . . . . . . . . . . . . . 4
3. MIF Connection manager requirement . . . . . . . . . . . . . . 5
3.1. Functional architecture . . . . . . . . . . . . . . . . . 5
3.2. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Network SAP . . . . . . . . . . . . . . . . . . . . . 6
3.2.2. User SAP . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.3. Operator SAP . . . . . . . . . . . . . . . . . . . . . 7
3.2.4. Cloud SAP . . . . . . . . . . . . . . . . . . . . . . 8
3.2.5. OS SAP . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.6. Execution SAP . . . . . . . . . . . . . . . . . . . . 8
3.2.7. Application SAP . . . . . . . . . . . . . . . . . . . 9
3.2.8. Authentication SAP . . . . . . . . . . . . . . . . . . 9
3.3. Functions of the connection manager . . . . . . . . . . . 10
3.3.1. Initiation . . . . . . . . . . . . . . . . . . . . . . 10
3.3.2. Decision . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.3. Execution function . . . . . . . . . . . . . . . . . . 11
3.3.3.1. IP connectivity check . . . . . . . . . . . . . . 12
3.3.3.2. IP address and interface mapping . . . . . . . . . 13
3.3.3.3. Virtual Interface Configuration . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Informative References . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Seite, et al. Expires April 28, 2011 [Page 2]
Internet-Draft Connection Manager requirements October 2010
1. Introduction
As shown in [I-D.ietf-mif-current-practices], 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
[I-D.ietf-mif-problem-statement]. 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.
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.
2. Use-cases
2.1. Provisioning domain selection
According to [I-D.ietf-mif-current-practices] 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:
o Domain learned on a Ethernet or 802.11 interface either from DHCP
or IPV6 RA
o Domain associated with a 3GPP enabled interface
o Domain associated with a WIMAX enabled interface
o Domain associated with any otehr IP level interface over other
link layer technologies such as bluetooth, 802.15
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:
Seite, et al. Expires April 28, 2011 [Page 3]
Internet-Draft Connection Manager requirements October 2010
o preferences provided by the user,
o policies provided by network operator,
o quality of the radio link,
o network resource considerations (i.e. available QoS, IP address
families, IP connectivity check,...),
o Operating system hints (e.g. battery),
o and so on...
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.
2.2. Reselection
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.
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 [RFC3775]) or
associated configuration operations, e.g. configuration of a logical
interface for inter-access handover support with PMIPv6 (as proposed
in [I-D.ietf-netext-logical-interface-support]).
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:
Seite, et al. Expires April 28, 2011 [Page 4]
Internet-Draft Connection Manager requirements October 2010
o the host fails to get L2 attachment;
o the host has managed to get L2 attachment but fails to set up the
IP connectivity (e.g. cannot obtained a valid IP address);
o the host has managed to get L2 attachment and IP connectivity, but
it has no access to the services (see
[I-D.ietf-mif-problem-statement] for details on MIF issues).
3. MIF Connection manager requirement
This section describes the generic framework of a MIF connection
connection manager.
3.1. Functional architecture
It can be deduced from the use-cases described in Section 2 that a
connection manager SHOULD support at least three main functions:
1. 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).
2. 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.
3. 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,....).
An example of a functional architecture of a Connection Manager is
given on Figure 1. 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.
Seite, et al. Expires April 28, 2011 [Page 5]
Internet-Draft Connection Manager requirements October 2010
+------------+ +--------+ +------------+ +------------+
|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. |
| | | |
+------------+ +------------+
Figure 1: A functional architecture for the connection manager
3.2. Interfaces
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).
3.2.1. Network SAP
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:
o Switching ON/OFF a specific network interface ( 3GPP APN PDP
context, 802.11 ESSID, ...).
Seite, et al. Expires April 28, 2011 [Page 6]
Internet-Draft Connection Manager requirements October 2010
o 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).
o Requesting an active network scan.
o Switching on/off a passive network scan (e.g. a scan which does
not disturb current traffic flows).
o 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.
o A link lost trigger (e.g. link down).
o 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.
o List of neighboring base stations of the same technology and if
possible of any technology.
o QOS: Interface queue packet loss.
o Information brought by Layer 2 (e.g. IEEE 802.21 [802.21]).
o Access to information about the connected network provided y
mechanisms such as 802.11u.
3.2.2. User SAP
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.
3.2.3. Operator SAP
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:
o Neighboring information on networks (e.g. 802.21 MIH server
([802.21]) or 3GPP ANDSF ([TS23.402]). 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.
Seite, et al. Expires April 28, 2011 [Page 7]
Internet-Draft Connection Manager requirements October 2010
o 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
3.2.4. Cloud SAP
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:
o The Cloud SAP should allow cloud services to request sensor
information from the client device.
o 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, ...).
o The cloud SAP could exchange information with Over-the-top
services (e.g. geolocation).
3.2.5. OS SAP
The OS SAP makes interface with terminal Operating system. This SAP
could provide the following capabilities:
o 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, [RFC3484], [RFC5014]).
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.
o Notification of DHCP events such as IP address assignment, DHCP
options such as ANDSF extensions
([I-D.das-mipshop-andsf-dhcp-options]).
o Power consumption triggers / queries.
o Energy status triggers / queries.
3.2.6. Execution SAP
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:
Seite, et al. Expires April 28, 2011 [Page 8]
Internet-Draft Connection Manager requirements October 2010
o Provisioning of static IP addresses.
o Generation of automatic WEB Auth methods and insertion into the
routing table of the default route once authentication successful.
o DHCP state machine control :
* let DHCP know it must wait for default route into routing table
insertion.
* IP address request on demand, in particular for IPv4 addresses.
o Control of OS virtual interfaces and binding (bridge or routed
mode ) to physical interface.
3.2.7. Application SAP
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:
o 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.
o allow applications a feedback mechanism into the Connection
Manager for giving real time updates on the QOS observed.
o Allow applications to query the identity store function within the
Connection manager and retrieve authentication methods.
o Allows some application to provide specific information to feed
the decision function(e.g. GPS positioning or velocity).
o terminal built in sensors listing and query/trigger of supported
options.
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.
3.2.8. Authentication SAP
The Authentication SAP provides access to all supported
authentication protocols in a shared fashion for all interfaces. For
instance, these protocols MAY include:
o 802.1x
Seite, et al. Expires April 28, 2011 [Page 9]
Internet-Draft Connection Manager requirements October 2010
o EAP frameworks
o WEB based mechanism such as WISPR 1.0 and WISPR 2.0, IPASS, ...
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.
3.3. Functions of the connection manager
3.3.1. Initiation
According to Section 3.1 The decision is made on triggers and the
parameters provided by the initiation function. This function SHOULD
manage, at least, the following triggers:
o 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.
o Application triggers (via Application SAP): application starting
or closing should trigger the decision process to select the most
appropriate provisioning domain.
o User/Operator hints (via User/Cloud/Operator SAPs): these hints
may be modification of preferences, operator policies, manual
selection, etc.
3.3.2. Decision
The decision function is the core of the connection manager, it
consists in two main functional blocks:
o 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.
o 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
[I-D.sarikaya-mif-dhcpv6solution] or via 3GPP ANDSF ([TS23.402])).
Information could be also provisioned through dedicated
Seite, et al. Expires April 28, 2011 [Page 10]
Internet-Draft Connection Manager requirements October 2010
application, for instance allowing the user to indicate its
preferences (e.g. manage its list of preferred access network).
Several criteria could be used to make a decision. For instance, the
following criteria COULD be considered:
o User Profile (user's rights in terms of QoS, roaming partners
allowed, etc.).
o User/Operator ordered list of preferred Wi-Fi networks.
o Access preference based on application type and destination, e.g.
IPTV is preferred on WLAN when available.
o Link Quality: signal strength (assuming radio link), QoS
(throughput, packet loss, delay, etc.).
o Application QoS requirements: throughput required per application
type/class, maximum accepted packet loss.
o 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).
3.3.3. Execution function
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
[RFC3775]), if IP session continuity must be ensured. Figure 2 shows
interaction between functions of the generic MIF connection manager.
Seite, et al. Expires April 28, 2011 [Page 11]
Internet-Draft Connection Manager requirements October 2010
+-----------------+ +-----------------+
|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 <-----------------+
Figure 2: State machine of connection manager
3.3.3.1. IP connectivity check
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.
Various situations may occur and various mechanisms CAN be used to
ensure IP connectivity, for example:
o 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.
o 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
Seite, et al. Expires April 28, 2011 [Page 12]
Internet-Draft Connection Manager requirements October 2010
authentication web portal.
o 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.
o 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.
3.3.3.2. IP address and interface mapping
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.
Selection of a source address MUST at least rely on default address
selection as per [RFC3484] 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.
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.
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).
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 Figure 3 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 [TS23.402]). According to
3GPP, a one to one mapping exists between a PDN connection and an
Seite, et al. Expires April 28, 2011 [Page 13]
Internet-Draft Connection Manager requirements October 2010
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.
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 [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.
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.
+----------------------------+
| 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 |
| | |
+--------------+-------------+
Figure 3: Connection Manager for MAPCON-enabled terminal
Seite, et al. Expires April 28, 2011 [Page 14]
Internet-Draft Connection Manager requirements October 2010
3.3.3.3. Virtual Interface Configuration
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
[I-D.ietf-netext-logical-interface-support]. 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)
[S2-103593].
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.
Figure 4 illustrates the relationship between the connection manager
and the virtual interface.
+---------------------+
| TCP/UDP |
+---------------------+
| IP |
+---------------------+ +------------+
| Virtual | | Connection |
| Interface |<---| Manager |
+---------------------+ +------------+
+---------+ +---------+ ^
| if_1 | | if_2 | |
| (WLAN) | | (3GPP) |<--------+
+---------+ +---------+ IF/CM interface
Figure 4: Connection Manager and Virtual Interface (VIF) relationship
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:
o 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.
Seite, et al. Expires April 28, 2011 [Page 15]
Internet-Draft Connection Manager requirements October 2010
o 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)
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.
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).
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.
Figure 5 depicts the use of the Virtual Interface in a terminal
supporting PMIPv6 / GTP advanced mobility features in the network,
and Figure 6 shows the use of the Virtual Interface in a terminal
with a DSMIPv6 stack.
Seite, et al. Expires April 28, 2011 [Page 16]
Internet-Draft Connection Manager requirements 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 |
mapping |(IF#1)|(IF#2)| ..... |(IF#n)|
+------+------+ +------+
| L1 | L1 | | L1 |
| | | | |
+------+------+ +------+
Figure 5: VIF for terminal supporting network-based Proxy Mobile IPv6
/ 3GPP GTP IFOM
+----------------------------+
| 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 |
| | |
+--------------+-------------+
Figure 6: VIF in terminal with DSMIPv6 stack
4. Security Considerations
TBD
Seite, et al. Expires April 28, 2011 [Page 17]
Internet-Draft Connection Manager requirements October 2010
5. IANA Considerations
This document has no actions for IANA.
6. Contributors
The following people contributed to this document:
Lucian Suciu
France telecom - Orange
lucian.suciu@orange-ftfroup.com
Patrice Nivagiolli
Cisco
pnivaggi@cisco.com
7. Acknowledgements
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.
8. References
8.1. Informative References
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
8.2. Informative References
[802.21] IEEE, "IEEE Standard for Local and Metropolitan Area
Networks - Part 21: Media Independent Handover Services",
IEEE LAN/MAN Std 802.21-2008, January 2009.", 2010, <
http://www.ieee802.org/21/private/Published%20Spec/
802.21-2008.pdf>.
[I-D.cao-mif-analysis]
Laganier, J., Montenegro, G., Korhonen, J., Savolainen,
T., and Z. Cao, "MIF Current Practice Analysis",
draft-cao-mif-analysis-01 (work in progress), July 2010.
[I-D.das-mipshop-andsf-dhcp-options]
Das, S. and G. Bajko, "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Options for Access Network Discovery
Seite, et al. Expires April 28, 2011 [Page 18]
Internet-Draft Connection Manager requirements October 2010
and Selection Function(ANDSF) Discovery",
draft-das-mipshop-andsf-dhcp-options-07 (work in
progress), October 2010.
[I-D.ietf-mif-current-practices]
Wasserman, M. and P. Seite, "Current Practices for
Multiple Interface Hosts",
draft-ietf-mif-current-practices-05 (work in progress),
October 2010.
[I-D.ietf-mif-problem-statement]
Blanchet, M. and P. Seite, "Multiple Interfaces and
Provisioning Domains Problem Statement",
draft-ietf-mif-problem-statement-08 (work in progress),
October 2010.
[I-D.ietf-netext-logical-interface-support]
Melia, T. and S. Gundavelli, "Logical Interface Support
for multi-mode IP Hosts",
draft-ietf-netext-logical-interface-support-01 (work in
progress), October 2010.
[I-D.melia-netext-logical-interface-support]
Melia, T., Gundavelli, S., Yokota, H., and C. Bernardos,
"Logical Interface Support for multi-mode IP Hosts",
draft-melia-netext-logical-interface-support-01 (work in
progress), July 2010.
[I-D.sarikaya-mif-dhcpv6solution]
Sarikaya, B., Xia, F., and P. Seite, "DHCPv6 Extension for
Configuring Hosts with Multiple Interfaces",
draft-sarikaya-mif-dhcpv6solution-04 (work in progress),
July 2010.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "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.
[S2-103593]
3GPP, "S2-103593 - Virtual Interface Support on UE -
Requirements and Properties", 2010.
Seite, et al. Expires April 28, 2011 [Page 19]
Internet-Draft Connection Manager requirements October 2010
[TS23.402]
3GPP, "3GPP TS 23.402; Architecture enhancements for non-
3GPP accesses", 2010.
Authors' Addresses
Pierrick Seite
France Telecom - Orange
4, rue du Clos Courtel, BP 91226
Cesson-Sevigne 35512
France
Email: pierrick.seite@orange-ftgroup.com
Gaetan Feige
Cisco
11 rue Camille Desmoulin
Issy les Moulineaux 92782
France
Email: gfeige@cisco.com
Telemaco Melia
Alcatel-Lucent
Route de Villejust
Nozay 91620
France
Phone: +33672662903
Email: telemaco.melia@alcatel-lucent.com
Juan-Carlos Zuniga
InterDigital
1000 Sherbrooke W
Montreal, QC
Canada
Email: juancarlos.zuniga.interdigital.com
Seite, et al. Expires April 28, 2011 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-24 07:35:52 |