Re: [OPSAWG] Alternate Tunnel Encapsulation for Data Frames in CAPWAP

Hello all

As some of you may know we (China Mobile) have been trying to progress a
CAPWAP related draft (this draft),  it advocates separating the control and
data plane of a CAPWAP AP.

In the past two IETF meetings, there have been questions about the need for
this. These question have been mainly centered around why the existing
CAPWAP capability is inadequate or other tunneling protocols cannot be
used. I am posting this email to reinforce our need for this work.

1)      As the attached link shows, the traffic to/from Wi-Fi in our
network is very large and growing rapidly. This is the driving factor to
consider separating the data traffic from the AC as we believe it leads to
scalable architecture than the current one.

2)      As an operator we need to tunnel the traffic from the AP to our NoC
for regulatory reasons.  So locally switching the traffic from the AP is
not an option.

3)      As an operator, we have chosen CAPWAP which is invented by IETF as
the protocol to create interoperable SP Wi-Fi systems.

I hope this will address some of the concerns raised.

Thanks

Regards

-Hui

2014-02-18 22:10 GMT+00:00 Rajesh Pazhyannur (rpazhyan) <rpazhyan@cisco.com>
:

>  Hello
>
> We have a submitted a new version of Alternate Tunnel Encapsulation for
> Data Frames in CAPWAP,
> *http://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds/*<http://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds/>.
>
>
> Abstract
>
>    In centralized IEEE 802.11 Wireless Local Area Network (WLAN)
>    architecture, the Access Controller (AC) isn't intelligent enough
>    actually to aggregate all the wireless frames, even the bandwidth
>    requirement in the access point is increasing.  Thus it is a general
>    case in the existing operator's network that WTPs forward the
>    wireless frames directly to Access Router (AR) to avoid overload on
>    the AC.  In this scenario, CAPWAP Control Channel and CAPWAP Data
>    Channel are separated from each other.  This document extends CAPWAP
>    for applicability of CAPWAP Control and Data Channel separation.
>
>
> We received some questions and suggestions from Dan Romascanu and John
> Kaippallimalil on the mailing list on the previous draft. We have attempted
> to address them in this draft. Specifically,
>
>    1. How does this draft address signaling, discovery mechanisms related
>    to setting up alternate tunnel. (ans. Tunneling protocols like L2TPv3,
>    IP/GRE (PMIPv6) already have a signaling mechanism. This draft focuses on
>    specifying the tunnel type and provides a container to hold message
>    elements)
>    2. Need for alternate tunnel encapsulation (given the existence of
>    defined mode with local bridging)
>
>
> We would like to get it adopted as a working group item and would like
> feedback on whether we are on track.
>
>
> thanks
>
> Regards
>
> Rajesh
>
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
>