[OPSAWG] Alternate Tunnel Encapsulation for Data Frames in CAPWAP

["Rajesh Pazhyannur (rpazhyan)" <[e-mail]>]

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

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