Re: [netext] Update on flow mobility following discussion with ADs

["Stefano Faccin" <[e-mail]>]

Raj,

Thanks for the notes. There is one aspect that concerns me, and is
related to :

 

"2. There is no plan or expectation that there would be a way for the

   MN/host to do signaling related to flow mobility with a MAG at

   layer 3. Layer 2 is an option but obviously this requires such

   enhancements to be done in other SDOs. The preference is to develop

   a flow mobility solution that works with policies and signaling

   that is network centric (i.e MAG/LMA entities). 

"

 

Personally I am concerned about this. What is the usefulness in netext
providing an "alternative" IP flow mobility solution that provides only
a subset of the functionality of a host-based solution. Deployments of
such so called alternative would provide a limited services with respect
to deployments of the host-based solution. Why would anybody want to
step back in time? 

 

As for:

 

"The preference is to develop

   a flow mobility solution that works with policies and signaling

   that is network centric (i.e MAG/LMA entities). 

"

I can understand the point, but I have a question. As an example, 3GPP
(that can be one of the potential customers and that we can surely not
disregard) has been very keen in indicating that the user (whether it be
the actual human being using the MN or e.g. the enterprise owning the
MN) has priority wrt the policies defined by the operator. This is
because in several scenarios the user may have preference for certain
accesses (e.g. the enterprise WiFi) that are not provided by the
operator for certain services (e.g. access to the enterprise resources).
In such case, 3GPP has recognized the need to allow the user to have
precedence. If the solution designed by netext is based solely on
network policies and decisions, I am afraid we would have a solution
that does not allow valid scenarios that have been identified by one of
the potential customers for the solution.

 

Cheers,

Stefano Faccin

 

Standards Manager

Research In Motion Corporation 
5000 Riverside Drive 
Building 6, Brazos East, Ste. 100

Irving, Texas 75039 USA 
Office: [phone]  

Internal: 820.63451

 : [phone]

www.rim.com
<outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D41
49BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E000000
6F1BEA0000/www.rim.com> ; www.blackberry.com
<outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D41
49BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E000000
6F1BEA0000/www.blackberry.com>  

	

  <http://www.blackberry.com/> 

 

P Consider the environment before printing.

 

From: [e-mail] [mailto:[e-mail]] On Behalf
Of [e-mail]
Sent: Wednesday, March 02, 2011 9:04 AM
To: [e-mail]
Subject: [netext] Update on flow mobility following discussion with ADs

 

 

Just wanted to provide an update regarding the ongoing work on flow

mobility for PMIP6 and my discussion with our ADs (Jari and Ralph) on

March 1st:

 

I have apprised our ADs about the state of the ongoing discussion on

flow mobility. One of the concerns about the ongoing work on flow

mobility was related to the logical interface feature. Flow mobility

depends on the existence of a logical interface on the host. The WG

has not addressed the concerns related to the logical interface I-D,

that were raised at the previous WG meetings. Emphasised that we

should get the logical interface spec done soon since it is a

fundamental dependency for flow mobility. 

 

Regarding the current scope of the flow mobility work and the I-D

which is now in consensus call, there are a few issues that need to be

resolved. A few points below:

 

1. Flow mobility in the context of Proxy MIP6 is not analogous to the

   solution that has been developed for host based MIP6. The

   featureset and capabilities developed in Netext does not have to

   mirror, parallel or be equivalent to that of RFCs 6088/9. 

 

2. There is no plan or expectation that there would be a way for the

   MN/host to do signaling related to flow mobility with a MAG at

   layer 3. Layer 2 is an option but obviously this requires such

   enhancements to be done in other SDOs. The preference is to develop

   a flow mobility solution that works with policies and signaling

   that is network centric (i.e MAG/LMA entities). 

 

3. One of the major concerns raised on the mailing list is related to

   how flow mobility would work when an MN attaches to a wifi access

   and the LMA switches a flow(s) to the MAG serving the MN via that

   wifi. The MN has no way of indicating to the LMA if the wifi access

   is congested or for the MAG to indicate to the LMA about the state

   of the MNs attachment to the AP. Packets forwarded by the LMA to

   the MN via the wifi-MAG could be sent into a void. 

   Without a solution for the above scenario, flow mobility would not

   be robust. Some clear answers are needed here.

 

   One option is that flow mobility for PMIP6 is applicable only in

   those access networks wherein the access network elements are aware

   of the state of the MNs connection and congestion state. The MAG

   can use this information to signal to an LMA attachment state and

   potentially cause flows to be switched to an alternative MAG. It

   may be okay to have specific statements about the limitations of

   flow mobility for PMIP6 documented as a sort of disclaimer. 

   

   Other options?

 

4. The WG is free to extend the PMIP6 signaling between MAG/LMA to

   accomplish flow mobility. 

 

5. And lastly the question about who is the customer for this work at

   this time is irrelevant. We have had this discussion during the

   chartering phase and there is no reason to revisit it. 

 

If I have missed any other significant (show-stopper) concern

regarding the flow mobility feature, please do raise them.

 

-Raj


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.