Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC

From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
Date: Fri, 13 Aug 2004 11:27:36 -0600

Behcet,

The case you're alluding to is interesting. If I understand correctly
where a 'non-AP' function is involved by way of user authentication that
is not a standard recognizable as a MAC/link-layer function/interface;
it is a higher layer function served by a higher layer service (at AC
presumably) - past the 802.1X authentication. It looks clearly out of
scope. I may have understood the issue wrongly - I could not spot the
related text in the referred CTP draft.

[I suppose you are not referring to the 'inner' authentication phase of
tunneled EAP methods? It is still EAP and the uncontrolled port does not
enable controlled port (I guess I switched the terms in an earlier
email) until the entire sequence completes.]

Can you expand on this further?

-mani

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Behcet Sarikaya
Sent: Thursday, August 12, 2004 2:52 PM
To: Wijnen, Bert (Bert)
Cc: [email-masked]
Subject: Re: [Capwap] Re: Data plane and control plane separation in
Split MAC

Wijnen, Bert (Bert) wrote:

	-----Original Message-----
	From: Shankar Narayanaswamy [mailto:[email-masked]]
	Sent: donderdag 12 augustus 2004 05:13
	To: [email-masked]
	Cc: [email-masked]
	Subject: [Capwap] Re: Data plane and control plane separation in
Split
	MAC

	The parameters by which the data plane communicates such as 
	authentication/security info, destination switch (if any) for
data 
	frames, etc, are communicated by the control plane. Hence the
need for 
	some architectural assumptions regarding the data plane even if
the 
	focus is on the control plane.
	 
	Or at least a decision on the data plane architectures to be 
	supported.

So... to me that sounds that we may potentially do an IMPLIED agreement 
on the architecture for data plane, based on the capabilities we define
in the standards track control and provisioning protocol.
 
That would be fine with me. But we should NOT get bogged down in that
data plane stuff, or at least that to me seems to be the wrong focus.

Agreed.
However, there might be interest in data packets for user-based security
management. As in CTP,
tunneling data frames to AC so that user-based authentication, etc. can
be achieved.
Is this within the scope?
Otherwise control frames are probably sufficient for a control and
provisioning protocol to deal with.
--behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 13 Aug 2004 15:35:13 -0700

Mani, both cases look similar to me from control and provisioning point 
of view, AP needs to be
provisioned, why not include one and exclude the other?

Mani, Mahalingam (Mahalingam) wrote:

> where a 'non-AP' function is involved by way of user authentication 
> that is not a standard recognizable as a MAC/link-layer 
> function/interface; it is a higher layer function served by a higher 
> layer service (at AC presumably) - past the 802.1X authentication. It 
> looks clearly out of scope. I may have understood the issue wrongly - 
> I could not spot the related text in the referred CTP draft.
>
>  
>
> [I suppose you are not referring to the 'inner' authentication phase 
> of tunneled EAP methods? It is still EAP and the uncontrolled port 
> does not enable controlled port (I guess I switched the terms in an 
> earlier email) until the entire sequence completes.]
>
>  
>
> ------------------------------------------------------------------------
>
>>To: [email-masked] <mailto:[email-masked]>
>>
>>Cc: [email-masked] <mailto:[email-masked]>
>>
>>Subject: [Capwap] Re: Data plane and control plane separation in Split
>>
>>MAC
>>
>> 
>>
>> 
>>
>>authentication/security info, destination switch (if any) for data 
>>
>>frames, etc, are communicated by the control plane. Hence the need for 
>>
>>some architectural assumptions regarding the data plane even if the 
>>
> However, there might be interest in data packets for user-based 
> security management. As in CTP,
> tunneling data frames to AC so that user-based authentication, etc. 
> can be achieved.