Hello all, The control/data channel separation of CAPWAP is a very useful deployment use case for operators. In that sense, I support the adoption of this draft and I do not see there is overlap/conflict with the already adopted CAPWAP extension drafts.
Cheers, Dapeng Liu 2014-02-19 9:00 GMT+08:00 Melinda Shore <[email protected]>: > Please note that Rajesh is planning to ask for working > group adoption of this document. Please give it a read > and provide feedback on this mailing list. Particularly > interested in the question of how well it meshes with > CAPWAP documents we've already adopted. > > Melinda > > > > -------- Original Message -------- > Subject: [OPSAWG] Alternate Tunnel Encapsulation for Data Frames in > CAPWAP > Date: Tue, 18 Feb 2014 22:10:10 +0000 > From: Rajesh Pazhyannur (rpazhyan) <[email protected]> > To: [email protected] <[email protected]> > > > > 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 > > > > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg > > -- ------ Best Regards, Dapeng Liu
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
