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

From: Xueli <[email-masked]>
Date: Thu, 3 May 2012 09:16:36 +0000

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.
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?

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.

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.

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.

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?

BR
Li

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 3 May 2012 13:52:37 -0700

HI Li,

Thanks for the review. inline …

On May 3, 2012, at 2:16 AM, Xueli wrote:

> I agree 3GPP architecture supports unique-prefix model for the mobile node’s PDN connections. In the context of WiFi,

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
> 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)
> But you said, “Even in deployment models where such handovers are no envisioned,
> 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 ?

> 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.

> 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.

> 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.

> These are SDO areas, and we should concentrate on these requirements to identify what IETF can do and state requirements on IETF work.

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fmc

---

From: <[email-masked]>
Date: Fri, 4 May 2012 11:28:26 +0200

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: [email-masked] [mailto:[email-masked]] Im Auftrag von Sri Gundavelli
Gesendet: Donnerstag, 3. Mai 2012 22:53
An: Xueli
Cc: [email-masked]
Betreff: Re: [fmc] Some comments to the community wifi draft

HI Li,

Thanks for the review. inline ...

Hi, all,

4 Section 4.15

Regards
Sri

BR
Li
_______________________________________________
fmc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/fmc

---

From: Xueli <[email-masked]>
Date: Fri, 4 May 2012 09:58:32 +0000

Hi Sri,
Thanks for your response, please see the opinion inline.

BR
Li

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sri Gundavelli
Sent: Friday, May 04, 2012 4:53 AM
To: Xueli
Cc: [email-masked]
Subject: Re: [fmc] Some comments to the community wifi draft

HI Li,

Hi, all,

[Li XUE] I agree there will be some issues if the prefix assignment models are different between 3GPP and fixed network. As I mentioned, this depends on the service and scenario. In interworking and convergence, there is a  issue. But in the scenario I said, I think it is no issue. Even in the handover case, if the internet service is changed from macro access to WLAN access, because the IP address is assigned by different network, the unique-prefix model will not impact the handover at all.
[Li XUE] As far as I know, it seems difficult to achieve unique-prefix per UE in fixed network, because it need the extension work on RG/CPE.

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 ?
[Li XUE] I agree there is an issue for uniform accounting/AAA. Whether we can think about the IETF work on protocol layer to resolve it, other than to force the IPv6 prefix model?

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.
[Li XUE] As you said, the aspect of SSID is one approach. I suggest the IETF work for the service differentiation.

4 Section 4.15

[Li XUE] sure.

Yes. At the end we need to see how best the tools we have can be used for supporting these architectures.
[Li XUE] Agree. Thanks a lot.

Regards
Sri

BR
Li

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 6 May 2012 14:52:46 -0700

Hi Dirk,

> he aspect of SSID based separation is one approach.

- 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…

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

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 6 May 2012 14:55:49 -0700

Hi Li,

There is nothing like forcing a specific approach, but rather list out the issues and recommend a specific approach.

> [Li XUE] As far as I know, it seems difficult to achieve unique-prefix per UE in fixed network, because it need the extension work on RG/CPE.

I'm not sure, but we can discuss this in the solution context.

Regards
Sri