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

[Hui Deng <[e-mail]>]

Hi Julien

As I asked the question yesterday,
it is expected that Qualcomm has more detail clarification about the text,

Regards,

-Hui


2010/4/10 Laganier, Julien <[e-mail]>:
> Hi Margaret -
>
> I notice this text is not included in the current rev. of the current practice draft. Are you going to include it?
>
> Thanks.
>
> --julien
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Margaret Wasserman
>> Sent: Sunday, August 16, 2009 7:04 AM
>> To: George Tsirtsis
>> Cc: mif
>> Subject: Re: [mif] AMSS/Brew Multi-interface handling
>>
>>
>> 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
>> >
>>
>> _______________________________________________
>> mif mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mif
> _______________________________________________
> mif mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mif
>