Re: [fmc] Some comments to the community wifi draft

[Sri Gundavelli <[e-mail]>]

Hi Dirk,

Thanks for your comments.

> he aspect of SSID based separation is one approach.
> doesn't this imply that the requirement is to enable service differentiation, and multiple SSIDs per AP is one potential solution?

- Multiple SSID's per Access Point is the trend in many deployments. Surely, service differentiation based on the SSID is surely one consideration. But, one may also bring the Hotspot/.11u efforts and may attempt to provide the same service differentiation using other means. The approaches of service differentiation may be relevant

> But as mentioned the draft is a collection of identified issues and provides a good basis for FMC work together with others such as http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-01,  http://tools.ietf.org/html/draft-liebsch-netext-pmip6-qos-01, and http://tools.ietf.org/id/draft-xue-intarea-fmc-ps-02.txt.

The focus of the draft was to really identify the SP WIFI market and the solution requirements, so we can see how best we can address these requirements using existing protocols developed by IETF. This is by no means a complete spec; the spec will not focus on any specific tool/protocol extensions.  The other drafts such as listed above can complement the work and be the tools in the over all solution design. Taking the  http://tools.ietf.org/html/draft-liebsch-netext-pmip6-qos-01 d- it explains how we can support QoS within a localized domain and map it to the 802.11 access. 

> Another minor remark: I may have misunderstood the introductory remarks saying that a mobile operator will see WiFi as "the basis for offering new wireless broadband services"  ... I'd rather think it is seen as an add-on/completion of the cellular coverage for dedicated services.


It depends. If this access is enabled by an operator who is also a mobile service operator, then its essentially about expanding the network coverage and increasing the service availability; its also about offload.  However,  for a cable operator with no mobile subscribers, the primary business incentive is enabling the new service for their own subscribers and also support a retail model with roaming agreements with other operators. Both the scenarios are valid IMO.

> Beside that only regarding smartphones and tablets almost every new mobile device is now equipped with IEEE 802.11-based wireless interface - there are still many new (low-cost) devices without. And I think, at least in Europe for the time being most of the devices are pre-configured with a policy to prefer cellular packet data access to WiFi.

:) Back in 2006, there was one of the top mobile handset vendor who used to disable WLAN interface on their mobile terminals :);  then there was this 2007 and some operators have decided to enable WLAN and also set the default policy to pick WLAN to cellular; So, operators are learning. Today, some applications such as FaceTime application is not enabled on cellular access and there are also new models with respect to moving away from unlimited service models for cellular, so I assume things will change in Europe too. 


Regards 
Sri




On May 4, 2012, at 2:28 AM, <[e-mail]> <[e-mail]> wrote:

> Dear Sri, all,
> in general I think that the updated draft http://tools.ietf.org/rfcdiff?url2=draft-gundavelli-v6ops-community-wifi-svcs-04.txt addresses several FMC issues which might be included in the planned FMC problem statement or requirements draft. I agree with Li that requirements in different sections on authentication might be grouped together.
> BTW strictly speaking when you  say below
> The aspect of SSID based separation is one approach.
> doesn't this imply that the requirement is to enable service differentiation, and multiple SSIDs per AP is one potential solution?
> But as mentioned the draft is a collection of identified issues and provides a good basis for FMC work together with others such as http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-01,  http://tools.ietf.org/html/draft-liebsch-netext-pmip6-qos-01, and http://tools.ietf.org/id/draft-xue-intarea-fmc-ps-02.txt.
>  
> What do you think of an attempt to merge aspects addressed within them?
>  
> Another minor remark: I may have misunderstood the introductory remarks saying that a mobile operator will see WiFi as "the basis for offering new wireless broadband services"  ... I'd rather think it is seen as an add-on/completion of the cellular coverage for dedicated services. Beside that only regarding smartphones and tablets almost every new mobile device is now equipped with IEEE 802.11-based wireless interface - there are still many new (low-cost) devices without. And I think, at least in Europe for the time being most of the devices are pre-configured with a policy to prefer cellular packet data access to WiFi.
>  
> Best regards 
> Dirk
>  
> Von: [e-mail] [mailto:[e-mail]] Im Auftrag von Sri Gundavelli
> Gesendet: Donnerstag, 3. Mai 2012 22:53
> An: Xueli
> Cc: [e-mail]
> Betreff: Re: [fmc] Some comments to the community wifi draft
> 
> HI Li,
> 
> Thanks for the review. inline …
> 
> 
> 
> 
> On May 3, 2012, at 2:16 AM, Xueli wrote:
> 
>> Hi, all,
>> I have went through the new draft( http://tools.ietf.org/rfcdiff?url2=draft-gundavelli-v6ops-community-wifi-svcs-04.txt).
>> I have several comments on this draft.
>> Please see as follows.
>> 1 Section 4.1 IPv6 addressing Model for SP WiFi architecture.
>> I agree 3GPP architecture supports unique-prefix model for the mobile node’s PDN connections. In the context of WiFi,
>> I am not sure this same requirement must be satisfied.
> 
> 
> It depends. There are very good reasons why IETF made a recommendation to 3GPP to support Per-MN prefix model. Clearly there are advantages that stand out. For SP WIFI architectures, the considerations are no different. We also need to think from the perspective of the handover from macros access to trusted WLAN access, the choice of different addressing will make handovers difficult.
> 
> 
> 
>> First, when a UE is connecting to the Wifi, there are two kinds service from UE, internet (local breakout) or operators’ service
>> / internet service (need go through the EPC core network).
>> For the EPC point of view, the UE obtains an IP address from the EPC network for the operator’s service, which is unique-prefix model.
>> For the wifi point of view, the UE obtains a local IP address for operator’s or internet service (need go through the EPC core network)
>> So we can see two kinds IP addresses will be assigned to UE.
>> When a UE is connecting to the LTE, unique-prefix model is used.
>> If the mobile node performs handover from macro network to the WLAN network for internet service,
>> I am not sure the unique prefix model should be adopted, except special scenarios, such as integration or interworking.
>> But you said, “Even in deployment models where such handovers are no envisioned,
>> such as an WLAN access aggregation architecture with no mobile packet core integration,
>> there are sufficient reasons for adopting the Unique Prefix model.”. Could you clarify this?
> 
> 
> That is one approach, but lets look at some other considerations. The mobile node is using Stateless Autoconf for address configuration and now the operator asks the vendor to do per-user accounting. How does that work ? The gateway will start tracking all the IPv6 address that the mobile node generates ? If it generates like a dozen IPv6 addresses for ephemeral lifetime, will the gateway track all these addresses ? Will it report all these addresses in Accounting-Start/AAA ? How about LI ? How about we assign a single prefix and track that one prefix ? What is a better approach and what is our recommendation ?
> 
> 
> 
> 
>> 2 Section 4.6 Multiple WLAN SSID support
>> I am wondering whether it is the requirement section of Community WiFi. IMHO, community wifi is kind of service or service requirements.
>> Multiple WLAN SSID supported in residential wifi hotspots seems like a solution instead of the requirements.
>> Even more, this section is the implementation issue.
>> Do you mind to clarify the real requirements of community wifi?
>> Then we can think about the IETF solutions, that would be better.
> 
> 
> This is a requirement. All most all WLAN networks have this concept of guest user/guest user service differentiation. The aspect of SSID based separation is one approach. Sure, this can be generalized with the use of HotSpot2.0. But, the key point is service differentiation.
> 
> 
> 
>> 3 Section 4.9 CPE identity and authorization
>> What about to merge the authorization elements to section 4.1, which is authentication and authorization related.
> 
> There is this aspect of CPE identity, authorization and then there is the aspict of service authorization to users. There are good reasons to separate them. As we bring some more analysis, this part will be clear. If there is need, it can be collapsed.
> 
> 
> 
>> 4 Section 4.15
>> This section seems like the issues introduced by multiple SSID deployment. My confusion is mentioned in the second comment.
>> I suggest the real requirements of community wifi should be clarified at first.
> 
> These are practical issues related to WiFi deployments in SP context. This translates into some specific requirements on the protocol layers. Lets discuss further.
> 
> 
> 
>> 5 some suggestion on these requirements , such as section 4.5, 4.9, etc, mentioned in the draft.
>> These are SDO areas, and we should concentrate on these requirements to identify what IETF can do and state requirements on IETF work.
>> What about your opinion?
> 
> Yes. At the end we need to see how best the tools we have can be used for supporting these architectures.
> 
> Thanks for your comments.
> 
> Regards
> Sri
> 
> 
> 
> 
>> BR
>> Li
>> _______________________________________________
>> fmc mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/fmc
>