Subject: RE: [Capwap] CAPWAP eval team - CTP evaluation

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 7 Sep 2005 09:29:32 -0700

> With my eval team member hat off,
> can I ask how appropriate/feasible/good SNMP would be for 
> Split MAC WTPs?
> CTP's use of SNMP stems originally from managing legacy Local 
> MAC WTPs. 
> Can one easily extend it to Split MAC WTPs?
> The use of SNMP versus CAPWAP had been discussed earlier in 
> this mailing list but I forgot what was the conclusion, if any?

As others have stated, SNMP requires ASN.1, and this therefore imposes
significant per packet overhead to each payload attached to a single
message. Putting aside CPU overhead this proposal alsowould create much
larger packets, and packet size efficiency is actually very important
once we start considering the use of CAPWAP over the air, for such
things as mesh networks (or 802.11s).

While the IEEE has defined a MIB, history has shown that the MIBs in
question have been largely incomplete. The fact that there is yet an AP
MIB means that there is no MIB one could actually use TODAY for CAPWAP.
So the end result is that every AP vendor out there has their own
enterprise specific MIB. Very few products actually make use of the
existing MIB, other than as there is work in progress in 802.11v, but
this is not expected to complete until Ocotber 2008 (see Group
Update/Timelines under http://ieee802.org/11/index.html). So going down
this path would require CAPWAP to define the MIBs anyways, eliminating
the benefits of reusing IEEE work.

So I would much prefer that we stick to the tried and true method of
AVPs, which has been very successful for such protocols as RADIUS, etc.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 7 Sep 2005 14:58:22 -0700

See my comments below.

Pat Calhoun

> There are a number of reasons why the CTP protocol relies 
> used SNMP payload (not SNMP) for WTP configuration:
> 
> 1) Protocol Administration: The IEEE defines MIB 
> configuration elements with every amendment to the standard. 
> If the CAPWAP working group adopts an approach of using the 
> SNMP mib definition for configuration of Access Points, it 
> means that the group does not have rev TLV's every time there 
> is a new amendment to the standard. If the MIB does not 
> compile, CAPWAP should go back to the IEEE to fix the MIB.

Or alternatively, it could do everything within the WG, which
would eliminate the cross-SDO communication, hence reduce time to RFC. 

> 
> Using existing MIB definitions for configuration also allows 
> the CAPWAP working group to apply the protocol to other 
> wireless technologies without having to derive new 
> configuration elements.
> 
> Contrary to Pat's statement, I would say that most vendors 
> that supply an SNMP mib with their Access Point use the 
> 802.11 MIB as a basis. Also, I very much doubt that the 
> CAPWAP working group would make use of 802.11 amendments 
> prior to them becoming a standard.

The current 802.11 MIB is designed for a STA, and does not even
allow for such things as multiple SSIDs. The lack of such a MIB was
instrumental to the creation of TGv, for which I am chair. Feel free
to look at the TG information on http://ieee802.org/11/index.html.

> 
> Also, if TLV's are adopted for configuration, the CAPWAP 
> working group is likely going to need to rely on the 802.11 
> MIB to derive new TLV's.

Ok, sure. However, mind you that it's not clear to me that the MIBs
created by the IEEE are really relevant for this working group. The
reason for this statement is that the IEEE considers everything to be
a STA. In fact, the IEEE still considers an AP to be a single autonomous
device, so the architectures being adopted by CAPWAP have additional
configuration elements that are never specified by the IEEE (because,
again, they consider this to be a closed system). So what they would
consider to be parameters in some API, we consider to be a protocol.

> 
> 2) Ease of Implementation: Most, if not all enterprise class 
> AP's have an SNMP agent. If CAPWAP relies on SNMP payload for 
> configuration, the existing SNMP agent on the WTP can be used 
> for CAPWAP implementation. 
> 
> We have had a lot of success in using this mechanism to port 
> our protocol across different AP hardware/software platforms. 
> We also have not seen any problems with regard to processor 
> overhead or network overhead. The size of a large 
> configuration packet is approximately around 7k, which would 
> not represent significant network overhead.

Versus less than an Ethernet MTU in LWAPP. Over the air, 7K requires 
5 individual transmissions, plus PIFS, so when running CAPWAP over the
air, it actually is significant.

> 
> This protocol is different from RADIUS and other IETF 
> protocols in that it is based on work done by another 
> standards body. However if the SNMP definition has already 
> been done by another standards body, why not use it?

If you can show me a MIB done by the IEEE (or IETF for that matter)
that is suitable for CAPWAP, then I will agree ;-)
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: Michael Montemurro <[email-masked]>
Date: Thu, 8 Sep 2005 09:04:11 -0400

Pat,

See my comments below: 

> -----Original Message-----
> From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
> Sent: September 7, 2005 5:58 PM
> To: Michael Montemurro; [email-masked]; [email-masked]
> Subject: RE: [Capwap] CAPWAP eval team - CTP evaluation
> 
> See my comments below.
> 
> Pat Calhoun
> > There are a number of reasons why the CTP protocol relies used SNMP 
> > payload (not SNMP) for WTP configuration:
> > 
> > 1) Protocol Administration: The IEEE defines MIB configuration 
> > elements with every amendment to the standard.
> SNMP mib 
> > definition for configuration of Access Points, it means 
> that the group 
> > does not have rev TLV's every time there is a new amendment to the 
> > standard. If the MIB does not compile, CAPWAP should go back to the 
> > IEEE to fix the MIB.
> 

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.

> > 
> > Using existing MIB definitions for configuration also allows the 
> > CAPWAP working group to apply the protocol to other wireless 
> > technologies without having to derive new configuration elements.
> > 
> that supply 
> > an SNMP mib with their Access Point use the
> CAPWAP working 
> > group would make use of 802.11 amendments prior to them becoming a 
> > standard.
> 
> The current 802.11 MIB is designed for a STA, and does not 
> even allow for such things as multiple SSIDs. The lack of 
> such a MIB was instrumental to the creation of TGv, for which 
> I am chair. Feel free to look at the TG information on 
> http://ieee802.org/11/index.html.
>

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".
  
> working group 
> > is likely going to need to rely on the 802.11 MIB to derive 
> new TLV's.
> 
> Ok, sure. However, mind you that it's not clear to me that 
> the MIBs created by the IEEE are really relevant for this 
> working group. The reason for this statement is that the IEEE 
> considers everything to be a STA. In fact, the IEEE still 
> considers an AP to be a single autonomous device, so the 
> architectures being adopted by CAPWAP have additional 
> configuration elements that are never specified by the IEEE 
> (because, again, they consider this to be a closed system). 
> So what they would consider to be parameters in some API, we 
> consider to be a 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.

> > 
> > 2) Ease of Implementation: Most, if not all enterprise 
> class AP's have 
> > an SNMP agent. If CAPWAP relies on SNMP payload for 
> configuration, the 
> > existing SNMP agent on the WTP can be used for CAPWAP 
> implementation.
> > 
> > We have had a lot of success in using this mechanism to port our 
> > protocol across different AP hardware/software platforms.
> overhead 
> > or network overhead. The size of a large configuration packet is 
> > approximately around 7k, which would not represent 
> significant network 
> > overhead.
> 
> 5 individual transmissions, plus PIFS, so when running CAPWAP 
> over the air, it actually is significant.
>

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.
 
> > 
> > This protocol is different from RADIUS and other IETF protocols in 
> > that it is based on work done by another standards body. However if 
> > the SNMP definition has already been done by another 
> standards body, 
> > why not use it?
> 
> If you can show me a MIB done by the IEEE (or IETF for that 
> matter) that is suitable for CAPWAP, then I will agree ;-)
> 

It depends how you define suitable? ;-)

Cheers,

	Mike

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 8 Sep 2005 06:55:18 -0700

> 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.

> 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.

> 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.
> 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 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.

Pat Calhoun

---

From: Michael Montemurro <[email-masked]>
Date: Thu, 8 Sep 2005 10:25:31 -0400

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.

Cheers,

	Mike

> 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.

> > 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 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.

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Thu, 8 Sep 2005 08:05:53 -0700

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Michael Montemurro
Sent: Thursday, September 08, 2005 7:26 AM
To: Pat Calhoun (pacalhou); [email-masked]; [email-masked]
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

> 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.

> are talking about WTP configuration, not what the user sees 

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.

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.

---

From: <[email-masked]>
Date: Fri, 9 Sep 2005 11:22:11 -0700

[My apologies if you get this twice--I sent the first version from the wrong
email address.]

Regarding the use of SNMP in CAPWAP, I would like to offer a few
observations and opinions:

Among the enterprise access points on the market today that have SNMP
support for configuration, nearly all of the interesting configuration and
monitoring items are in the vendor-specific enterprise MIB. The 802.11 MIB
is certainly supported on most enterprise APs, but it is hardly sufficient
for full management or monitoring of a device. The MIB work in progress in
the IEEE may look promising, but it will take a while for that to make it
into the marketplace. 

The actual SNMP agent implementations on enterprise access points on the
market today vary greatly in their capabilities. Most of the implementations
have quirks: only a single OID can be set per packet, types for values don't
match what's advertised in the MIB definition, some groups of settings have
to be changed in the same packet (with no documentation in the MIB
definition), etc. In some cases, it's impossible to fully configure a device
using SNMP. I would not necessarily look at the state of things as an
endorsement for SNMP. 

I'm a fan of SNMP for monitoring (from an NMS perspective), but it's really
less than ideal for configuration in my opinion. I much prefer a clear
command line language or configuration file when a human is interacting with
a set of devices. For device-to-device communication, especially where there
are time-critical operations, I am not sure that SNMP offers much over a
protocol designed for this specific purpose. My only concern is that the
protocol is open, which is the point of CAPWAP. 

As I see it, the primary advantage to using SNMP is that there are existing
NMS tools that can take advantage of it. But if the only devices using this
protocol are a controller and a WTP, what value does SNMP add over a
new/different protocol? 

In a network where all of the wireless devices are addressable only through
a controller element, I certainly want that controller to support SNMP for
monitoring and have a well-documented open interface for configuration. If
that's an SNMP agent with a standard MIB, that's okay, but I am still hoping
that the entire networking industry moves to something standardized that's
better than SNMP for device configuration. 

Cheers,
Jason

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bob O'Hara (boohara)
Sent: Thursday, September 08, 2005 8:06 AM
To: Michael Montemurro; Pat Calhoun (pacalhou); [email-masked];
[email-masked]
Subject: RE: [Capwap] CAPWAP eval team - CTP evaluation

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.

 -Bob

[...]