Hi Melinda, This document and the other capwap drafts in opsawg serve different purposes: new Model, new air-interface support and new control function support. After reading it I believe this document has evolved into a stable version with a straightforward solution, and is ready for adoption.
Regards, Peng > -----Original Message----- > From: OPSAWG [mailto:[email protected]] On Behalf Of Melinda Shore > Sent: Wednesday, February 19, 2014 9:00 AM > To: [email protected] > Subject: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frames in > CAPWAP > > 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
