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

[Hui Deng <[e-mail]>]

I have explained as well, hope it clarify the question.

-Hui

2010/4/14 Laganier, Julien <[e-mail]>:
> I have replied to your other email; it's not clear to me what needs to be clarified.
>
> --julien
>
> Hui Deng wrote:
>>
>> 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
>> >> >
>> >
>