Subject: [Capwap] Data tunneling between WTP <->AC

From: "Puneet Agarwal" <[email-masked]>
Date: Wed, 22 Mar 2006 22:08:08 -0800

Hi All,
 
One of the recommendations of the evaluation team was to have a mode to
tunnel 802.3 frames between WTP and AC. It seems that that requirement
was interpreted as tunneling 802.3 frames for local MAC. However after
talking to various folks at IETF 65 (dallas), it seems the intent was to
tunnel 802.3 frames in the split MAC (and not local MAC).
 
Hence I would propose the following:
 
(a) Delete the tunneling of 802.3 frames between AC<->WTP for Local MAC
and replace it with (b).
(b) Add tunneling 802.3 frames between AC <-> WTP for Split MAC.
Following the notation in section 11.1.1, a new variant of Split MAC
should be defined (based on recommendation of the eval team) as follows.
I have marked the changes wrt the draft-00's section 11.1.1 with *
(note: section 11.1.1 remains unchanged - this proposal is an addition
to and not a replacement for section 11.1.1):
 
        Function                               Location
        -------------                               -------------
            Distribution Service                       AC
            Integration Service                       *WTP*
            Beacon Generation                       WTP
            Probe Response                           WTP
            Power Mgmt/Packet Buffering        WTP
            Fragmentation/Defragmentation      WTP
            Assoc/Disassoc/Reassoc              AC
 
       802.11e
            Classifying                               AC
            Scheduling                               *WTP* (I don't
understand why section 11.1.1 shows .11e scheduling at AC)
            Queuing                                   WTP
 
       802.11i
            802.1X/EAP                                AC
            Key Management                        AC
            802.11 Encryption/Decryption      *WTP*
 
Thanks.
 
-Puneet
 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 23 Mar 2006 10:20:51 -0800

Puneet,
 
Could you once more remind me why two different tunneling formats is
required in split-MAC mode?

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Puneet Agarwal [mailto:[email-masked]] 
	Sent: Wednesday, March 22, 2006 10:08 PM
	To: [email-masked]
	Subject: [Capwap] Data tunneling between WTP <->AC

	Hi All,
	 
	One of the recommendations of the evaluation team was to have a
mode to tunnel 802.3 frames between WTP and AC. It seems that that
requirement was interpreted as tunneling 802.3 frames for local MAC.
However after talking to various folks at IETF 65 (dallas), it seems the
intent was to tunnel 802.3 frames in the split MAC (and not local MAC).

	(a) Delete the tunneling of 802.3 frames between AC<->WTP for
Local MAC and replace it with (b).
	(b) Add tunneling 802.3 frames between AC <-> WTP for Split MAC.
Following the notation in section 11.1.1, a new variant of Split MAC
should be defined (based on recommendation of the eval team) as follows.
I have marked the changes wrt the draft-00's section 11.1.1 with *
(note: section 11.1.1 remains unchanged - this proposal is an addition
to and not a replacement for section 11.1.1):
	 
	        Function                               Location
	        -------------
-------------
	            Distribution Service                       AC
	 
	       802.11e
	            Classifying                               AC
	            Scheduling                               *WTP* (I
don't understand why section 11.1.1 shows .11e scheduling at AC)
	            Queuing                                   WTP
	 
	       802.11i
	            802.1X/EAP                                AC
	            Key Management                        AC
	 
	Thanks.
	 
	-Puneet

---

From: Michael Montemurro <[email-masked]>
Date: Mon, 27 Mar 2006 10:30:29 -0500

I've captured this item as number 90.

  _____  

From: Puneet Agarwal [mailto:[email-masked]] 
Sent: March 23, 2006 1:08 AM
To: [email-masked]
Subject: [Capwap] Data tunneling between WTP <->AC

Hi All,
 
One of the recommendations of the evaluation team was to have a mode to
tunnel 802.3 frames between WTP and AC. It seems that that requirement was
interpreted as tunneling 802.3 frames for local MAC. However after talking
to various folks at IETF 65 (dallas), it seems the intent was to tunnel
802.3 frames in the split MAC (and not local MAC).

(a) Delete the tunneling of 802.3 frames between AC<->WTP for Local MAC and
replace it with (b).
(b) Add tunneling 802.3 frames between AC <-> WTP for Split MAC. Following
the notation in section 11.1.1, a new variant of Split MAC should be defined
(based on recommendation of the eval team) as follows. I have marked the
changes wrt the draft-00's section 11.1.1 with * (note: section 11.1.1
remains unchanged - this proposal is an addition to and not a replacement
for section 11.1.1):
 
        Function                               Location
 
       802.11e
            Classifying                               AC
 
       802.11i
            802.1X/EAP                                AC
            Key Management                        AC
 
Thanks.
 
-Puneet

---

From: "Puneet Agarwal" <[email-masked]>
Date: Mon, 27 Mar 2006 11:34:04 -0800

Hi Pat,
 
Sorry for the delayed response.
 
The main reason for doing .11 Integration service (convert 802.11 <-->
802.3 frame) in the WTP is that it insulates the AC data plane from any
changes in the 802.11 (and other wireless bindings) frame format. For
many reasons, including fast roaming now (and in future inter AC
roaming), one still wants to do the .11 Distribution service at the AC
(for a single point of presence in the L2 wired network of a wireless
node) - hence the split MAC model. The proposed split insulates the
"data plane" at the AC from the vagaries of the underlying wireless
binding formats (802.11, 802.16, 802.xx) and any changes to those
formats.
 
Wrt Mike M's comment about "802.11 management frame" - 802.11 non-data
frames (like management frames etc) are not handled by the data plane
(as they are not switched into the L2 network). Hence the CAPWAP
protocol should really provide a separate mechanism in the control
channel to carry such non-data frames unmodified to the AC if so desired
(could be a separate opcode in the control channel that is specific to
the 802.11 binding). This will go a long way in decoupling the data and
control plane in the CAPWAP protocol and provide for the architectural
longevity of the CAPWAP protocol. Moreover, it is highly likely that
other wireless MACs have their own management frames which need to be
sent to the AC control channel that do not need to be processed by the
data channel.
 
It is my humble opinion that the CAPWAP base protocol should be designed
such that it is independent of the underlying wireless technology. When
one introduces a new wireless binding (like 802.16), we will have to
write a new control plane (and do a software upgrade) but the intent
should be able to reuse the same dataplane hardware/firmware as was
deployed for 802.11. Control plane changes are primarily a new software
load on the AC - a data plane change is much more expensive to customers
as it typically involves hardware.
 
Thanks.
 
-Puneet

From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Thursday, March 23, 2006 10:21 AM
To: Puneet Agarwal; [email-masked]
Subject: RE: [Capwap] Data tunneling between WTP <->AC

Puneet,

Pat Calhoun

	Hi All,

	 
	 
	        Function                               Location
	        -------------
-------------
	            Distribution Service                       AC
	 
	       802.11e
	            Classifying                               AC
	            Scheduling                               *WTP* (I
	 
	       802.11i
	            802.1X/EAP                                AC
	            Key Management                        AC
	 
	Thanks.
	 
	-Puneet

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 27 Mar 2006 14:25:24 -0800

Puneet,
 
You are making assumptions about 802.16 that converting the frames to
802.3 will allow the AC to provide the normal function of an 802.16 base
station - ditto for all wireless technologies. Is this realistic?
 
As an aside, the hardware needs to be modified to support CAPWAP frames
too...

Pat Calhoun

	From: Puneet Agarwal [mailto:[email-masked]] 
	Sent: Monday, March 27, 2006 11:34 AM
	To: Pat Calhoun (pacalhou); [email-masked]
	Subject: RE: [Capwap] Data tunneling between WTP <->AC

	Hi Pat,

	The main reason for doing .11 Integration service (convert
802.11 <--> 802.3 frame) in the WTP is that it insulates the AC data
plane from any changes in the 802.11 (and other wireless bindings) frame
format. For many reasons, including fast roaming now (and in future
inter AC roaming), one still wants to do the .11 Distribution service at
the AC (for a single point of presence in the L2 wired network of a
wireless node) - hence the split MAC model. The proposed split insulates
the "data plane" at the AC from the vagaries of the underlying wireless
binding formats (802.11, 802.16, 802.xx) and any changes to those
formats.
	 
	Wrt Mike M's comment about "802.11 management frame" - 802.11
non-data frames (like management frames etc) are not handled by the data
plane (as they are not switched into the L2 network). Hence the CAPWAP
protocol should really provide a separate mechanism in the control
channel to carry such non-data frames unmodified to the AC if so desired
(could be a separate opcode in the control channel that is specific to
the 802.11 binding). This will go a long way in decoupling the data and
control plane in the CAPWAP protocol and provide for the architectural
longevity of the CAPWAP protocol. Moreover, it is highly likely that
other wireless MACs have their own management frames which need to be
sent to the AC control channel that do not need to be processed by the
data channel.
	 
	It is my humble opinion that the CAPWAP base protocol should be
designed such that it is independent of the underlying wireless
technology. When one introduces a new wireless binding (like 802.16), we
will have to write a new control plane (and do a software upgrade) but
the intent should be able to reuse the same dataplane hardware/firmware
as was deployed for 802.11. Control plane changes are primarily a new
software load on the AC - a data plane change is much more expensive to
customers as it typically involves hardware.
	 
	Thanks.
	 
	-Puneet

	Puneet,
	 
	Could you once more remind me why two different tunneling
formats is required in split-MAC mode?

	Pat Calhoun

		Hi All,
		 
		One of the recommendations of the evaluation team was to
have a mode to tunnel 802.3 frames between WTP and AC. It seems that
that requirement was interpreted as tunneling 802.3 frames for local
MAC. However after talking to various folks at IETF 65 (dallas), it
seems the intent was to tunnel 802.3 frames in the split MAC (and not
local MAC).

		(a) Delete the tunneling of 802.3 frames between
AC<->WTP for Local MAC and replace it with (b).
		(b) Add tunneling 802.3 frames between AC <-> WTP for
Split MAC. Following the notation in section 11.1.1, a new variant of
Split MAC should be defined (based on recommendation of the eval team)
as follows. I have marked the changes wrt the draft-00's section 11.1.1
with * (note: section 11.1.1 remains unchanged - this proposal is an
addition to and not a replacement for section 11.1.1):
		 
		        Function                               Location
		        -------------
-------------
		            Distribution Service
AC
		            Integration Service
*WTP*
		            Beacon Generation                       WTP
		            Probe Response                           WTP
		 
		       802.11e
		            Classifying                               AC
		            Scheduling
*WTP* (I don't understand why section 11.1.1 shows .11e scheduling at
AC)
		            Queuing
WTP
		 
		       802.11i
		            802.1X/EAP                                AC
		            Key Management                        AC
		 
		Thanks.
		 
		-Puneet

---

From: "Saravanan Govindan" <[email-masked]>
Date: Tue, 28 Mar 2006 08:49:36 +0800

Puneet,

Since the evaluation teams recommended in introducing a 802.3-tunnel
mode option, would it be better to have integration services performed
at AC "or" WTP?

In general, I think this is a configuration feature to be determined
during initial WTP configuration. So we can introduce the tunnel mode
option here and include text in Section 5.1.5 (WTP Frame Type) to the
effect of 

"2 - 802.3 Bridging:  802.3 Bridging requires the WTP and AC to 

     encapsulate all user payload as native IEEE 802.3 frames (see

     Section 4.2).  This value DELETE: (MUST NOT be) REPLACE WITH: (is)
used when the MAC Type is

     set to Split-MAC."

Cheers,

Saravanan

 

From: Puneet Agarwal [mailto:[email-masked]] 
Sent: Thursday, March 23, 2006 2:08 PM
To: [email-masked]
Subject: [Capwap] Data tunneling between WTP <->AC

Hi All,

        Function                               Location

       802.11e
            Classifying                               AC

       802.11i
            802.1X/EAP                                AC
            Key Management                        AC

Thanks.

-Puneet

---

From: "Puneet Agarwal" <[email-masked]>
Date: Mon, 27 Mar 2006 17:11:20 -0800

Hi Pat,
 
It is hard for me to conjecture how realistic this goal is as it is
difficult for me to speculate how the various protocols (.11, .16 etc)
are going to evolve. All I can do is point to past architectural
frameworks within IETF that were application neutral and led to and
explosion (in a manner of speaking) of applications after the base
protocol data path was defined - the most recent one that comes to mind
is MPLS. The base architecture of MPLS was application neutral and this
led to many variants like RSVP-TE LSPs, L2 VPNs, L3VPN etc. Each of
these applications had a different control plane protocol variant (RSVP,
LDP, BGP) but the same/similar data plane processing for most part. This
is not an apples to apples comparison with wireless but just an
illustration to substantiate my point.
 
I believe that the CAPWAP working group is in a unique position to
influence the wired/wireless network evolution. I think that it is up to
us to take the long term architectural view of the problem and then
propose solutions within the constraints of those architectural
framework. To that extent, I believe we (CAPWAP) need to document our
architectural constraints that we want to use as guideposts as we are
developing our protocol(s). [Aside: If the groups feels that this is a
useful exercise then I am willing to contribute to that effort as
required.]
 
With regard to the hardware - yes, the hardware will need to be modified
for the initial implementation of CAPWAP frames but the intent is that
we should not have to rev the hardware when we extend CAPWAP control
plane for 802.16, 802.xx or new variants in 802.11. Software revs are
much cheaper (and faster) than hardware revs.
 
Thanks.
 
-Puneet

From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Monday, March 27, 2006 2:25 PM
To: Puneet Agarwal; [email-masked]
Subject: RE: [Capwap] Data tunneling between WTP <->AC

Puneet,

Pat Calhoun

	Hi Pat,

	 

	Thanks.
	 
	-Puneet

	Puneet,

	Pat Calhoun

		Hi All,

		 
		 
		        Function                               Location
		        -------------
-------------
		            Distribution Service
AC
		            Integration Service
*WTP*
		            Beacon Generation                       WTP
		            Probe Response                           WTP
		 
		       802.11e
		            Classifying                               AC
		            Scheduling
		 
		       802.11i
		            802.1X/EAP                                AC
		            Key Management                        AC
		 
		Thanks.
		 
		-Puneet

---

From: "Puneet Agarwal" <[email-masked]>
Date: Tue, 28 Mar 2006 10:10:36 -0800

Hi Saravan,
 
802.3 tunnel mode option only applies when WTP is performing the
Integration service.
 
Part of the challenge is that Split MAC is a very overloaded term. We
really need to specify clearly which capabilities reside where (even in
modified Split MAC) for the proposed 802.3 tunneling mode. This is what
I attempted to do in specifying the new variant of Split MAC (where
integration in done on the WTP but Distribution is still done at the
AC). For clarity in specification, I would err on the side of being a
little verbose, and add the necessary text that I outlined in my earlier
email (or some variant of it) to the spec for the 802.3 tunneling mode
as a separate subsection of 11.1.1.
 
Thanks.
 
-Puneet

From: Saravanan Govindan [mailto:[email-masked]] 
Sent: Monday, March 27, 2006 4:50 PM
To: Puneet Agarwal; [email-masked]
Subject: RE: [Capwap] Data tunneling between WTP <->AC

Puneet,

     set to Split-MAC."

Cheers,

Saravanan

 

Hi All,

        Function                               Location

       802.11e
            Classifying                               AC

       802.11i
            802.1X/EAP                                AC
            Key Management                        AC

Thanks.

-Puneet