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

Melinda Shore <melinda.shore@gmail.com> Wed, 19 February 2014 01:00 UTC

Return-Path: <melinda.shore@gmail.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 D51BE1A0216 for <opsawg@ietfa.amsl.com>; Tue, 18 Feb 2014 17:00:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 yB7uXuoXCMeO for <opsawg@ietfa.amsl.com>; Tue, 18 Feb 2014 17:00:07 -0800 (PST)
Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1B84B1A0426 for <opsawg@ietf.org>; Tue, 18 Feb 2014 17:00:07 -0800 (PST)
Received: by mail-pd0-f181.google.com with SMTP id y10so16935091pdj.12 for <opsawg@ietf.org>; Tue, 18 Feb 2014 17:00:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=KF2MSr8BL/OUQgUHFEQ8CVuuS2hRavbxpLJSZ6UPTaw=; b=lssBx7k1i5wqC4yUwMNXi9iSIAlH8ODnYsEX7PS0/BNq5EjPys8AstzB2YX9xHjfJ7 XZDvfPs7palVnMGld98UjeOTfuG+Y0Jx83+6BBJPoxKuyP6sdApdNO8Rz8IqCkRLunz0 XbSVEH5D89ir//uJNxMwfDCxmrIAZk/NroDLz+VIHAlLUa/uEo+6UJJTlwnirxQNlkuD 8oMAg63fjobsRmXjvlBkzYn2jyIn6E0B9ynEkDsmZqPhACW7N0uyun90gazFcLfrIFGW exi6G5Uy/ZtNCE6bZkm0mwUwv5taaBXGhRFKD1KPHXuO/Ns4xwNwz4fRX5d1ozRNltip Hvcw==
X-Received: by 10.68.133.193 with SMTP id pe1mr36551660pbb.56.1392771604139; Tue, 18 Feb 2014 17:00:04 -0800 (PST)
Received: from spandex.local (63-140-93-251.dynamic.dsl.acsalaska.net. [63.140.93.251]) by mx.google.com with ESMTPSA id yg4sm35044151pab.19.2014.02.18.17.00.02 for <opsawg@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Feb 2014 17:00:03 -0800 (PST)
Message-ID: <53040210.4090709@gmail.com>
Date: Tue, 18 Feb 2014 16:00:00 -0900
From: Melinda Shore <melinda.shore@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: "opsawg@ietf.org" <opsawg@ietf.org>
References: <4ED2E36A22261145861BAB2C24088B4320F5A67C@xmb-aln-x09.cisco.com>
In-Reply-To: <4ED2E36A22261145861BAB2C24088B4320F5A67C@xmb-aln-x09.cisco.com>
X-Forwarded-Message-Id: <4ED2E36A22261145861BAB2C24088B4320F5A67C@xmb-aln-x09.cisco.com>
Content-Type: multipart/mixed; boundary="------------080601040004090802000807"
Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/2KbGqn8_CthAv9j09KKdiJTgySQ
Subject: [OPSAWG] Fwd: Alternate Tunnel Encapsulation for Data Frames 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: Wed, 19 Feb 2014 01:00:09 -0000

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