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

["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
> >> >
> >