Re: [mif] AMSS/Brew Multi-interface handling

[Margaret Wasserman <[e-mail]>]

Hi George,

Thanks for sending this!

I'll add it to the next version of the draft.

Margaret

On Aug 16, 2009, at 5:41 AM, George Tsirtsis wrote:

> 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.
> _______________________________________________
> mif mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mif
>