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

Qiao Fu <fuqiao1@outlook.com> Mon, 24 February 2014 06:16 UTC

Return-Path: <fuqiao1@outlook.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796441A031F for <opsawg@ietfa.amsl.com>; Sun, 23 Feb 2014 22:16:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.839
X-Spam-Level: ***
X-Spam-Status: No, score=3.839 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CN_BODY_35=0.339, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPdHiuHGOEd2 for <opsawg@ietfa.amsl.com>; Sun, 23 Feb 2014 22:16:18 -0800 (PST)
Received: from snt0-omc1-s12.snt0.hotmail.com (snt0-omc1-s12.snt0.hotmail.com [65.55.90.23]) by ietfa.amsl.com (Postfix) with ESMTP id A1A0D1A030B for <opsawg@ietf.org>; Sun, 23 Feb 2014 22:16:18 -0800 (PST)
Received: from SNT146-DS18 ([65.55.90.9]) by snt0-omc1-s12.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 23 Feb 2014 22:16:18 -0800
X-TMN: [tQYvq/pMZXdLUUWEgCz3MWXk5bZUTwzvO9qP3L6iR68=]
X-Originating-Email: [fuqiao1@outlook.com]
Message-ID: <SNT146-DS189EE010D40D00F9D2EA48E8860@phx.gbl>
From: Qiao Fu <fuqiao1@outlook.com>
To: opsawg@ietf.org
References: <mailman.4380.1392771610.2637.opsawg@ietf.org>
In-Reply-To: <mailman.4380.1392771610.2637.opsawg@ietf.org>
Date: Mon, 24 Feb 2014 14:18:35 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac8tDfEbaisiQv5bTmWcBnXDPj6OYABoW06A
Content-Language: zh-cn
X-OriginalArrivalTime: 24 Feb 2014 06:16:18.0224 (UTC) FILETIME=[EDECD300:01CF3127]
Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/rUBaK6yQVeZgFXae7jawjuKDal4
Subject: Re: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frame in CAPWAP
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Feb 2014 06:16:20 -0000

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:opsawg-bounces@ietf.org] 代表 opsawg-request@ietf.org
发送时间: 2014年2月19日 9:00
收件人: opsawg@ietf.org
主题: OPSAWG Digest, Vol 81, Issue 35

Send OPSAWG mailing list submissions to
	opsawg@ietf.org

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
	opsawg-request@ietf.org

You can reach the person managing the list at
	opsawg-owner@ietf.org

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 <melinda.shore@gmail.com>
To: "opsawg@ietf.org" <opsawg@ietf.org>
Subject: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frames
	in	CAPWAP
Message-ID: <53040210.4090709@gmail.com>
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) <rpazhyan@cisco.com>
To: 	opsawg@ietf.org <opsawg@ietf.org>



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
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


------------------------------

Subject: Digest Footer

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


------------------------------

End of OPSAWG Digest, Vol 81, Issue 35
**************************************