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

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