Hi, all. I have read through the draft and here are some comment. This draft addresses on two shortcomings of the current CAPWAP. 1) the current one does not allow the WTP to tunnel data frames to an endpoint other than AC; 2) it does not allow the WTP to tunnel data frames using any encapsulation other than CAPWAP. This draft presents a case in which the WTP may have the requirement to tunnel a frame to an AR but not an AC. Moreover, when tunneling to an AR, the choice of tunnel encapsulation may be extended to other types, such as L2TP, L2TPv3, IP-in-IP, IP/GRE and etc.. The authors further describe how the WTP can be configured with this alternate tunnel. The suggested procedure to establish the alternate tunnel encapsulation is also presented.
The case presented in the draft is quite clear, and the solution of alternate tunnel encapsulation in the draft is quite straightforward. Therefore, I support for working group adoption. Best regards! Qiao Fu -----邮件原件----- 发件人: OPSAWG [mailto:[email protected]] 代表 [email protected] 发送时间: 2014年2月19日 9:00 收件人: [email protected] 主题: OPSAWG Digest, Vol 81, Issue 35 Send OPSAWG mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/opsawg or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of OPSAWG digest..." Today's Topics: 1. Fwd: Alternate Tunnel Encapsulation for Data Frames in CAPWAP (Melinda Shore) ---------------------------------------------------------------------- Message: 1 Date: Tue, 18 Feb 2014 16:00:00 -0900 From: Melinda Shore <[email protected]> To: "[email protected]" <[email protected]> Subject: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frames in CAPWAP Message-ID: <[email protected]> Content-Type: text/plain; charset="iso-8859-1" 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 -------------- next part -------------- _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg ------------------------------ Subject: Digest Footer _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg ------------------------------ End of OPSAWG Digest, Vol 81, Issue 35 ************************************** _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
