Capwap Mailing List: RE: CAPWAP eval team - CTP evaluation

[Bob O'Hara (boohara) (boohara]

Mike,

I agree that other opinions would be interesting to hear.
Unfortunately, it has been quite some time since anyone outside a very
small group of posters, including the authors of the various proposals,
has felt the need to offer an opinion or an insight into what they want
out of CAPWAP.  

Perhaps all that the vast majority that attend the WG meetings want to
see is a little entertainment.  I hope that is not the case.

In any case, a few comments, below.


 -Bob
 
-----Original Message-----
From: capwap-admin [at] frascone.com [mailto:capwap-admin [at] frascone.com] On
Behalf Of Michael Montemurro
Sent: Thursday, September 08, 2005 7:26 AM
To: Pat Calhoun (pacalhou); sarikaya [at] ieee.org; capwap [at] frascone.com
Subject: RE: [Capwap] CAPWAP eval team - CTP evaluation

Pat,

I've inserted my comments below. Although I enjoy debating this topic
with
you, it would be nice to hear other opinions from the WG on this topic. 

However I think there is a misunderstanding on how we could make use of
SNMP. SNMP is only used for two functions: passing "configuration
information" from the AC down to the WTP; and passing statistics from
the
WTP to the AC. The purpose is to make use of the OID's defined by the
IEEE,
and the SNMP agent that exists on most, if not all, enterprise class
AP's.
The protocol still needs to define control messages that allow the AC
and
the WTP to exchange state information on connections.

Bob>> There is not necessarily an SNMP agent in all of the WTP
configurations under discussion.  Certainly there might be an agent in a
local MAC (local AP) WTP.  However, it is highly speculative to say
there is also an agent present in a split MAC (split AP) or a remote MAC
(remote AP).  These also represent "enterprise class" APs.  I know of at
least two implementations of the Split MAC (split AP) that do not have
an agent present.

More, below.

Cheers,

        Mike

> 
> > CAPWAP is inherently based on other wireless standards. 
> > Unless this WG is planning on defining their own wireless 
> MAC/PHY, it 
> > will depend on other SDO's for standards. You still have to look at 
> > configuration elements that happen to be defined in the MIB 
> to derive 
> > your TLV's.
> 
> Agreed. However, I believe that the assumption is that CAPWAP 
> picks up a completed MAC/PHY and then adapts the CAPWAP 
> protocol to it. If CAPWAP then required that they send a 
> liason to the appropriate SDO to further expand their MIBs 
> for our use, then I would argue that this would significantly 
> increase our time to delivery. We cannot assume that other 
> SDOs understand our problem space, and certainly are not 
> designing their protocols to satisfy our needs.
>

The SDO provides enough information so that you could configure the
MAC/PHY
through SNMP OIDs. In CTP, we use the SNMP mib to push configuration
information down to the WTP. It makes it easy to format the
configuration
message.

Bob>> I don't think this information from the SDO is sufficient.  An
equivalent statement might be that one could configure a 48-port
Ethernet switch using only the information provided in the Ethernet MIB
for the MAC and PHY.  Since the IETF put a lot of work into the Bridge
MIB, I think the existence proof says the MAC/PHY MIB is insufficient.

Bob>> If all you need is a message formatter, SNMP and ASN.1 are a
little on the heavy side.  Don't you agree?  If SNMP and ASN.1 are so
useful for the purpose of formatting packets, why has the IETF continued
to develop protocols that do not use them?  I think the answer has to
do, at least in part, with the fact that ASN.1 creates bloated packets
to carry small amounts of information.

> > There is no standard for multiple SSID's. There has been discussion 
> > around defining a "multi-BSS" standard in 802.11 for about 
> the last 2 
> > years. I'm glad that finally the IEEE has decided to take 
> that task. 
> > However, I thought it was Tgu that was defining "multi-BSS".
> 
> TGv is creating the MIB. TGu is looking at what multiple-BSS 
> means. The actual MIB is what we care about here because we 
> are talking about WTP configuration, not what the user sees 
> over the air.
> 

In your LWAPP model, I assume we would need the WTP configuration to
create
configuration TLV's. In the CTP model, we would use the OID's that TGv
defines to specify the configuration of the WTP. In the CTP case, you
don't
need to rev the specification for configuration in the AC-WTP protocol.

> > You keep stating that the IEEE considers everything a STA 
> and yet, the 
> > only example for a feature that is missing is multi-SSID, 
> which isn't 
> > a standard.
> > I don't know of an enterprise class AP that doesn't have a 
> MIB based 
> > on the
> > 802.11 MIB. Also, I would like to understand what is 
> missing from the 
> > 802.11 MIB that would prevent it from being used by the CAPWAP WG.
> Show me the MIB that allows one to retrieve the list of STAs 
> and association state from an AP? Given that CAPWAP supports 
> encryption in the WTP, show me the MIB that allows us to push 
> the PTK/GTK from the AC to the WTP. etc, etc.
>

The two examples you give relate to state information on the WTP, not
configuration. I believe that the CAPWAP protocol needs to define
messages
that allow the WTP and the AP to share connection state information. 

The CAPWAP protocol needs to define messages that allow the WTP and the
AC
to ensure state information. There needs to be a message that lets the
AC
know that a STA has associated. There also needs to be a messages for
keying
information to be passed from the AC to the WTP.

> > The amount of time you are talking about a time, which over 
> the aire, 
> > is actually less than 9 ms. When you start taking a look at 
> discovery 
> > and authentication, this timing is insignificant.
> I think we will have to agree to disagree. When you take 
> those 9ms, and then you run it on a mesh that consists of 4 
> hops - things add up. Keep in mind these types of messages 
> are generated when users come and go, etc. So it's more than 
> just configuring the WTP, so efficiency is required here.
> 

No. That is not how we proposed using SNMP. CTP only uses SNMP for
configuration elements that are passed from the WTP to the AC.
> 
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
> 
_______________________________________________
Capwap mailing list
Capwap [at] frascone.com
http://mail.frascone.com/mailman/listinfo/capwap