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

[Hui Deng <[e-mail]>]

Hi Julien

What I mean is I sent one email to clarify the AMSS/Brew several days ago
http://www.ietf.org/mail-archive/web/mif/current/msg00714.html
would like to clarify more detail before adding into the current practice draft,

thanks

-Hui

2009/8/16 George Tsirtsis <[e-mail]>:

2010/4/13 Laganier, Julien <[e-mail]>:
> Hi Hui,
>
> I do not understand what is meant here. Can you clarify?
>
> Thanks.
>
> --julien
>
> Hui Deng wrote:
>>
>> 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
>> >
>