Subject: [Capwap] Local-MAC & Split-MAC Negotiations

From: "Saravanan Govindan" <[email-masked]>
Date: Thu, 19 Jan 2006 11:05:54 +0800

Pat,

Issue:

The CAPWAP protocol is expected to support major WTP designs. It is
important for information on these design types to be exchanged during
configuration so that subsequent protocol operations are consistent and
accurate. 

My recommendation:

To specify WTP characteristics as part of Discovery state
(draft-ohara-capwap-lwapp-03.txt) Section 5. The following message
elements to be included to Discovery Request
(draft-ohara-capwap-lwapp-03.txt) Section 5.1;

MAC Type - Split-MAC, Local-MAC

MAC Frame Type - Native (IEEE 802.11), IEEE 802.3, No frames (local
bridging)

IEEE 802.11i Design - Encryption & Authenticator on same entity,
Encryption on WTP & Authenticator on AC

Saravanan 

_________________________________________________________________
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: Fri, 20 Jan 2006 11:28:41 -0800

This request is already encompased in tracker entries 3 and 4, which I
have already addressed and sent text earlier this week.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Saravanan Govindan
[mailto:[email-masked]] 
	Sent: Wednesday, January 18, 2006 7:06 PM
	To: Pat Calhoun (pacalhou); [email-masked]
	Subject: Local-MAC & Split-MAC Negotiations

	Pat,

	Issue:

	The CAPWAP protocol is expected to support major WTP designs. It
is important for information on these design types to be exchanged
during configuration so that subsequent protocol operations are
consistent and accurate. 

	My recommendation:

	MAC Frame Type - Native (IEEE 802.11), IEEE 802.3, No frames
(local bridging)

	 

	Saravanan

---

From: zhaoyujin 31390 <[email-masked]>
Date: Mon, 23 Jan 2006 16:10:51 +0500

Dear all

For this feature
Section 11.9.12  "IEEE 802.11 WTP Mode and Type"
Can LWAPP redefine the type: (Next LWAPP can extend to manage all types of AP)
      0 - Split MAC

      1 - Remote MAC

      2 - Local MAC

      3 - Fat AP

Next give comments: 
  The encapsulated data should be in the form of 802.3 for Fat AP and Local MAC.  And the encapsulated data should be in the form of 802.11 for Split AP and Remote MAC.

Best regards
Michael

This request is already encompased in tracker entries 3 and 4, which I have already addressed and sent text earlier this week.
 
Pat Calhoun

--------------------------------------------------------------------------------
From: Saravanan Govindan [mailto:[email-masked]] 
Sent: Wednesday, January 18, 2006 7:06 PM
To: Pat Calhoun (pacalhou); [email-masked]
Subject: Local-MAC & Split-MAC Negotiations

Pat,

Issue:

The CAPWAP protocol is expected to support major WTP designs. It is important for information on these design types to be exchanged during configuration so that subsequent protocol operations are consistent and accurate. 

My recommendation:

To specify WTP characteristics as part of Discovery state (draft-ohara-capwap-lwapp-03.txt) Section 5. The following message elements to be included to Discovery Request (draft-ohara-capwap-lwapp-03.txt) Section 5.1;

MAC Type – Split-MAC, Local-MAC

MAC Frame Type – Native (IEEE 802.11), IEEE 802.3, No frames (local bridging)

IEEE 802.11i Design – Encryption & Authenticator on same entity, Encryption on WTP & Authenticator on AC

Saravanan 

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

Pat Calhoun

	From: Saravanan Govindan

	Pat,

	Issue:

	My recommendation:

	 

	Saravanan

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 23 Jan 2006 07:09:38 -0800

Michael, I believe that I have responded to the original request, which
was to define two separate message elements, one for tunneling and one
for MAC mode. Could you apply your comments based on that proposed text?

Pat Calhoun

> -----Original Message-----
> From: zhaoyujin 31390 [mailto:[email-masked]] 
> Sent: Monday, January 23, 2006 3:11 AM
> To: Pat Calhoun (pacalhou)
> Cc: Saravanan Govindan; [email-masked]
> Subject: Re:[Capwap] RE: Local-MAC & Split-MAC Negotiations
> 
> Dear all
> 
> For this feature
>   The encapsulated data should be in the form of 802.3 for 
> Fat AP and Local MAC.  And the encapsulated data should be in 
> the form of 802.11 for Split AP and Remote MAC.
> 
> Best regards
> Michael
> 
> 
> 
> 
> 
> This request is already encompased in tracker entries 3 and 
> 4, which I have already addressed and sent text earlier this week.
>  
> Pat Calhoun
> The CAPWAP protocol is expected to support major WTP designs. 
> It is important for information on these design types to be 
> exchanged during configuration so that subsequent protocol 
> operations are consistent and accurate. 
> 
>  
> 
> My recommendation:
> 
> (draft-ohara-capwap-lwapp-03.txt) Section 5. The following 
> message elements to be included to Discovery Request 
> IEEE 802.11i Design - Encryption & Authenticator on same 
> entity, Encryption on WTP & Authenticator on AC
> 
>  
> 
>  
> 
>  
> 
> Saravanan 
> 
> 
>

---

From: "Saravanan Govindan" <[email-masked]>
Date: Tue, 24 Jan 2006 10:05:07 +0800

Hi Michael,

I was hoping you could help clarify the difference between 'Fat AP' and
Local MAC. 

I assume that 'Fat AP' refers to a standalone AP. If so, is your
suggestion to have standalone APs exchange data with an AC? 

Cheers,

Saravanan

-----Original Message-----
From: zhaoyujin 31390 [mailto:[email-masked]] 
Sent: Monday, January 23, 2006 7:11 PM
To: Pat Calhoun (pacalhou)
Cc: Saravanan Govindan; [email-masked]
Subject: Re:[Capwap] RE: Local-MAC & Split-MAC Negotiations

Dear all

For this feature
Section 11.9.12  "IEEE 802.11 WTP Mode and Type"
Can LWAPP redefine the type: (Next LWAPP can extend to manage all types
of AP)
      0 - Split MAC

      1 - Remote MAC

      2 - Local MAC

      3 - Fat AP

Next give comments: 
  The encapsulated data should be in the form of 802.3 for Fat AP and
Local MAC.  And the encapsulated data should be in the form of 802.11
for Split AP and Remote MAC.

Best regards
Michael

Pat Calhoun

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

Pat,

Issue:

My recommendation:

 

Saravanan 

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