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

["Laganier, Julien" <[e-mail]>]

Hui Deng wrote:
> 
> Hi, George,
> 
> just two clarifications AMSS/Brew DNS configuration is
> interface based other than host based?

Quoting the text George sent:

   AMSS allows each interface to be configured with its own set of DNS 
   configuration parameters - a list of DNS servers, domain names etc.
 
> secondly, network profile could identify only APN other than PDP
> context?

Quoting the text George sent: 

   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.

--julien

> 2009/8/16 George Tsirtsis <[e-mail]>:
> > 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