[mif] AMSS/Brew Multi-interface handling

[George Tsirtsis <[e-mail]>]

Hi all,

I sent this to Margaret during the IETF meeting but I did not hear
back from her. Maybe it got lost in the IETF noise so I thought I
might as well forward this to the list.

I hope it helps.

George

---------- Forwarded message ----------
From: George Tsirtsis <[e-mail]>
Date: Wed, Jul 29, 2009 at 9:58 AM
Subject: AMSS/Brew Multi-interface handling
To: [e-mail]


Hi Margaret,

Here is a description of how multi-interface support is handled by
Advanced Mobile Station Software (AMSS) that comes with Brew OS for
all Qualcomm chipsets (e.g., MSM, Snapdragon etc). I hope this is
helpful information for draft-mrw-mif-current-practices.

Let me know if you have any questions.

Regards
George Tsirtsis (wearing a Qualcomm hat)

-----------------------------------------------------------------------------------------------------


Multiple Interface Handling - Qualcomm AMSS/Brew Mobile Platform

AMSS supports a concept of “netpolicy” which allows each application
to specify the type of network connectivity desired.  The netpolicy
contains parameters such as access technology, IP version type and
network profile.  Access technology could be a specific technology
type such as CDMA or WiFi or could be a group of technologies, such as
ANY_Cellular or ANY_Wireless.  IP version could be one of Ipv4, Ipv6
or Default.  The network profile identifies a type of network domain
or service within a certain network technology, such as 3GPP APN or
Mobile IP Home Agent.  It also specifies all the mandatory parameters
required to connect to the domain such authentication credentials and
other optional parameters such as QoS attributes.  Network Profile is
technology specific and set of parameters contained in the profile
could vary for different technologies.

Two models of network usage are supported.

Applications requiring network connectivity specify an appropriate
netpolicy in order to select the desired network.  The netpolicy may
match one or more network interfaces.  AMSS system selection module
selects the best interface out of the ones that match the netpolicy
based on various criteria such as cost, speed or other provisioned
rules.  Application explicitly starts the selected network interface
and, as a result, the application also gets bound to the corresponding
network interface.  All outbound packets from this application are
always routed over this bound interface using the source address of
the interface.
Alternately, applications may rely on a separate connection manager to
control (start/stop) the network interface.    In this method,
applications are not necessarily bound to any one interface.  All
outbound packets from such applications are routed on one of the
interfaces that match its netpolicy.  The routing decision is made
individually for each packet and  selects the best interface based on
the criteria described above and the destination address.   Source
address is always that assigned to the interface used to transmit the
packet.

Note that all of the routing/interface selection decisions are based
on the netpolicy and not just destination address to avoid overlapping
private Ipv4 address issue.  This also allows multiple (logical)
interfaces to be configured with the same IP address, for example, to
handle certain tunnelling scenarios.   Applications that do not
specify a netpolicy are routed by AMSS to the best possible interface
using the default netpolicy.  Default netpolicy could be pre-defined
or provisioned by the administrator or operator.  Hence default
interface could vary from device to device and also depends upon the
available networks at any given time.
AMSS allows each interface to be configured with its own set of DNS
configuration parameters – a list of DNS servers, domain names etc.
Interface selected to make a DNS resolution is the one to which
application making the DNS query is bound.  Applications can also
specify a different netpolicy as part of DNS request to select another
interface for DNS resolution.  Regardless, all the DNS queries are
sent only over this selected interface using the DNS configuration
from the interface.   DNS resolution is first attempted with the
primary server configured in the interface.  If a response is not
received, the queries are sent to all the other servers configured in
the interface in a sequential manner using a backoff mechanism.