One document matched: draft-seite-mif-connection-manager-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
<rfc category="info" ipr="trust200902" docName="draft-seite-mif-connection-manager-00.txt">
<?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 initials="P." surname="Seite" fullname="Pierrick 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 initials="G." surname="Feige" fullname="Gaetan 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>
<date month="July" year="2010"/>
<abstract>
<t>
It is a common practice for multiple interfaces terminals to leverage on
a connection manager to perform provisioning domain selection.
Problem statement document highlighted that lack of standardized behavior for connection managers can bring specific issues in a MIF context.
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"/>, it is a common practice for multiple interfaces terminals to leverage on
a connection manager to perform provisioning domain selection. The connection manager can make its decision on user preferences, applications inputs or many other criteria.
There are various ways to provide information to connection manager (static configuration, user provisionned, out-of-band mechanisms, etc) and a lot of
possible strategies that a connection manager can implement to make a selection.
This variety of situations may lead to specific issues, as specified in <xref target="I-D.ietf-mif-problem-statement"/>. For instance, issues may rise up because connection
managers does not behave in the same way depending on the operating systems and/or platforms.
High level API may also differ accross different operating systems and/or platforms. It is also stressed that, 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 manager behavior and API specifications would be a must for applications developpers, operators, users, etc...
So, this document aims to address this issue by proposing functional requirements for a generic connection manager expected to be used by a MIF node.
This document proposes a functional architecture for the connection manager, describes interfaces and required functions.
</t>
</section>
<section title="Use-cases" anchor ="USE_CASES">
<section title="Provisioning domain selection">
<t>
According to <xref target="I-D.ietf-mif-current-practices"/>; one of the basic operation 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. The selection could be based on various criteria,
among them are:
<vspace blankLines="1" />
<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 selects 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 selects 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 selects 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.
</t>
<t>
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 abovementioned 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, if possible, an alternative provisioning domain.
</t>
<t>
If IP communiation 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"/>) or associated configuration operations, e.g. configuration of a virtual interface for inter-access
handover support with PMIPv6 (as proposed in <xref target="I-D.melia-netext-logical-interface-support"/>).
</t>
<t>
Reselection may also happen foloowing an attachment failure (at Layer 2 or 3). For instance, the connection manager shouls 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"/>
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 title="Functional architecture " anchor = "ARCHI">
<t>
It can be deduced from the use-cases described in <xref target="USE_CASES"/> 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, …).
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"/>.
The Connection Manager supports the functions described above and it implements interfaces with all the involved actors (e.g., user, application,
operator,...) 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 will discuss needed SAPs in order
to allow other functional modules to interact with the Connection Manager.
<figure align="center" title = "A functional architecture for the connection manager" anchor="CM_ARCHI">
<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 one specific network interface.
Fon instanceThe Network SAP should provide the following capabilities:
<vspace blankLines="1" />
<list style = "symbols" >
<t>Switching ON/OFF a specific network interface.</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 alogrythm
as such a early link loss detection will vary according to other parameters such as the speed of the UE, 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. 3GPP ANDSF <xref target="TS23.402"/>, IEEE 802.21 <xref target="802.21"/>).</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, and so on…
These preferences are 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"/>) or 3GPP ANDSF (<xref target="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.
</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 priority.
</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 services).
Typically, these information are needed for the control of virtual 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"/>).</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>UE 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"/> 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 functions 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"/> or via 3GPP ANDSF
(<xref target="TS23.402"/>)). 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>
There are plenty of criteria which 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,…).</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 decision function triggers the execution, 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"/>),
if IP session continuity must be ensured.
<xref target="CM_SM"/> shows interaction between functions of the generic MIF connection manager.
<figure align="center" title = "State machine of connection manager" anchor="CM_SM">
<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 that the layer 2 is still connected.
</t>
<t>
Various situations may occur and various mechanisms are needed to ensure the IP connectivity can be used, 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 SSID does not mean they are part of the same network. Hence the
client must verify its IP address parameters. In order to avoid a complete reconfiguration when not needed; initial checks can be performed. Such
mechansisms 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 this avoids 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 connnectivity can be limited if there is a high level of layer 2 errors. When on the edge of a 802.11 cell, the radio paramters 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 title = "IP address and interface mapping" anchor = "MAPPING">
<t>
In a MIF context, the notion of path is indeed key as, even a single network 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).
Mechanism for selecting on or the other of these paths resides within source address selection rules associated with selection policies.
</t>
<t>
Selection of a source address should at least rely on default address selection as per <xref target="RFC3484"/> which defines algorithms for source and
destination IP address selections.
However, more sophisticated selection mechanism could also be provided by connection managers. Here, the connection manager will typically select the path
(i.e. source address) based on local information
(e.g. access monitoring) and policies/requirements issued from all actors coming to play (i.e., user, application, operator, etc.). Once the decision is made
(i.e. path selected), the execution function will configure, in a transparent manner for applications, the appropriate mapping of IP communication with selected local interface.
</t>
<t>
Information on IP address type (e.g. local, global, assigned to a virtual interface, etc…) must be known by the connection manager as an input for address selection.
This information may be provided by specific extensions to IP address allocation mechanisms (e.g. DHCP, IPCP, RA, or any other…).
</t>
</section>
<section title = "IP flow mobility">
<t>
Flow mobility realtes to the capability to move specific flows from one interface to another.
Specification of a network based solution is currently ongoing within NetExt working group. Basically, Network based IP flow mobility
is proposed to leverage on a virtual interface hiding the access change to application <xref target="I-D.melia-netext-logical-interface-support"/>. This approach results
in a mobile node getting the same IP address on multiple interfaces in the case of IPv4 and the same prefix in the case of IPv6. To handle these situations,
it is proposed that the mobile node should create a virtual interface to which an IP address would be allocated .
The connection manager can typically control the mapping of that virtual interface to the physical interface.
</t>
<t>
Mechanism for selecting on or the other of the paths for each IP flow resides within source address selection rules associated with Flow Mobility policies.
The flow mobility policies have direct impact on the source address selection rules. In the same manner than in the preceding section, the connection manager could handle
the mapping of the physical interface to the virtual interface (including the selection of the source address) depending on the decision made.
</t>
<t>
In this situation, the mapping control shall take into account the method used to learn the IP address, which can differ if:
<vspace blankLines="1" />
<list style = "symbols">
<t>this IP is learned directly from the network with PMIP 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.</t>
</list>
</t>
<t>
As in <xref target="MAPPING"/>, information on IP address type (e.g. local, anchored, assigned to a virtual interface, etc…) must be known by the connection manager as an input
for address selection.
</t>
<t>
The following picture illustrates the relationship between the connection manager and the virtual interface.
<figure align="center" title = "Connection Manager and Virtual Interface relationship" anchor="CM_VI">
<artwork align="center"><![CDATA[
+---------+ +---------+
| if_1 | | if_2 |
|(WLAN) | |(3GPP) |
+-.-------+-+-------.-+
_|_ | Virtual | _|_ IF/CM interface
| | Interface | |
+-'-----------------'-|
| Connection |
| Manager |
+---------------------+
| MN |
+---------------------+
]]>
</artwork>
</figure>
</t>
</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>
</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.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="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:56:32 |