[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Help getting CAPWAP MIB doc plan started
HI,
I've been asked by the CAPWAP WG chairs to edit the
MIB docs for CAPWAP. I'd like to request your help
on a modelling question and the plan for the contents.
Below describes very briefly the CAPWAP architecture,
followed by the modelling question, and then the doc
content plan.
Note that I've CC'ed Pat Calhoun the editor of the
CAPWAP protocol specification, so please include
him in your comments.
After getting your comments, I plan on sending
the proposal for the MIB docs to the CAPWAP WG.
----------------------------------------------------------
31-jan-2006:dtp
Dear MIB doctors,
The CAPWAP WG is working on standardizing a protocol
that is used to configure, monitor, control, and
potentially pass user traffic between a wireless
termination point (WTP) (which usually called an
access point (AP)) and an access controller (AC).
Typically, two or more WTPs are connected to a single AC,
which coordinates their operation so that a user with
a 802.11 device (such as a PC with an 802.11 interface,
or a WiFi phone) can seamlessly travel within a geographic
coverage area. The CAPWAP protocol allows an operator
to manage the coverage area supported by the WTPs as
if it were a single system.
Note that a device with an 802.11 network interface is
called a wireless client station (STA).
Figure 1: End to End view
-------
| | STA (a wireless client)
| |
--|||--
|||
| \- 802.11 interface
|
|--802.11 wireless protocol
|
| /- 802.11 interface
|||
--|||--
| | WTP
| |
--:::--
:::<->--------------------
| \-Ethernet interface |
| |
----- |
/ \ |>CAPWAP protocol between WTP and AC
| | L3 cloud |
\ / |
----- |
| |
| /-Ethernet interface |
:::<->--------------------
--:::--
| | AC
| |
-@-@-@-
@ @ @
| | |\- potential Ethernet interfaces to L2 or L3 clouds
There are many different designs for placing and interconnecting
the functionality shown in the above figure. These different
designs are described in RFC 4118. The CAPWAP WG decided to
standardize a protocol that supported three variations,
which are:
1) Local MAC with STA data terminated at the WTP
2) Local MAC with STA data terminated at the AC
3) Split MAC with STAT data terminated at the AC
Local MAC means the entire set of 802.11 MAC functions is
implemented on the WTP.
Split MAC means that the 802.11 MAC functions are split
between the WTP and AC, with generally the time critical
functions performed on the WTP and the STA authentication
and authorization functions performed on the AC.
STA data terminated on the WTP means that L2 user frames
are output on the WTA's Ethernet interface and may have
802.1Q tags added.
STA data terminated on the AC means that L2 user frames
are tunnelled to the AC and are output on one of the AC's
Ethernet interfaces and may have 802.1Q tags added.
The number of WTPs that can be associated with an AC could be
2 or 3 in an small environment, up to several hundred. A typical
maximum would be around 50. The number of concurrent STAs could
be up to around 1000, with a more typical max being around
being 300 to 500. Once installed and put into service, it
is expected that WTPs (and the AC) would be in continuous
operation. It would be a fault condition for the association
between an AC and WTP to be lost. (Yes, an AC is a single
point of failure in this architecture, because WTPs are
not expected to operate without an AC.) An AC may be configured
so that it uses a RADIUS server for authentication
of STAs that authenticate with 802.1X/EAP. An AC may
also use a RADIUS server for authorization and assignment
of STA session attributes (such as QoS or L2 VLAN and 802.1Q tag).
In most designs, a WTP contains no system software and
a minimal amount of configuration information. When a WTP
starts, it first discovers the address of its controlling
AC. Next, a WTP authenticates itself with the AC (and possibly
the AC authenticates itself with the WTP) after which an
association (a secure control channel) is set up. The
system software for the WTP is transferred to the WTP,
followed by the AC configuring the WTP.
Current Documents
-----------------
1) Base protocol specification used to specify the CAPWAP protocol:
http://www.ietf.org/internet-drafts/draft-ohara-capwap-lwapp-03.txt
2) Description of problems to be solved by CAPWAP protocol:
http://www.ietf.org/rfc/rfc3990.txt
3) A description of the architectures of existing (or planned)
"pre-CAPWAP" implementations:
http://www.ietf.org/rfc/rfc4118.txt
4) A list of desired features to be in the CAPWAP protocol:
http://www.ietf.org/internet-drafts/draft-ietf-capwap-objectives-04.txt
5) An evaluation of candidates to be used for the base protocol
specification document:
http://www.ietf.org/internet-drafts/draft-ietf-capwap-eval-00.txt
Modeling Question
-----------------
Ideally, the system of an AC and its associated WTPs
would be managed as a single entity. That is, there would
be a single SNMP agent residing on the AC that would
provide information about the system as a whole, and not
as an agent for the AC and a proxy agent for each WTP.
In many ways, an AC and its associated WTPs can be modeled
as a chassis that contains a management/control card (the AC),
and multiple line cards (the WTPs).
The benefits of this approach are the following:
1) This simplifies the work of writing management applications
because there is a single system to track instead
of potentially 100's of systems.
2) This makes SNMP administration easier, since there is only
a single system where SNMP admin tables need to be
configured.
3) Potentially, the existing MIB definitions can be reused
without modification.
4) The AC can consolidate WTP management information, and provide
management apps that information from a single source.
The issue is that the instrumentation for some management
info is on the WTPs and some is on the AC. However, the
CAPWAP protocol allows a range of WTPs where in some cases
the instrumentation is on the WTP and in other cases the
instrumentation in on the AC. (The three major classes are
the listed above). The other management interfaces (such as
the CLI or WEB interface) on an AC must already do the
consolidation (which means managing the cached data from
the WTPs), and it makes sense to have the SNMP model
consistent with the model used by the other management
interfaces.
The potential problems with this approach are:
1) The SNMP protocol has performance problems
with supporting tables with a large number of rows,
and the number of rows in the interface table
(from the IF MIB module) and rows in the physical
entity table (from the ENTITY MIB module) would
be increased by a factor of the number of WTPs.
2) The mapping of existing management models is not
straightforward, and interpretations are needed
such as to how to apply the "interface model" and
the "Entity MIB" to such a system.
So, the bottom line question here is the following:
Is modelling the collection of an AC and its associated WTPs
as a single SNMP entity the best approach to be taken?
And the follow-ups are:
1) have I listed all of the key benefits and costs?
2) are there any potential problems that I need to
look at in more detail?
3) I'm planning on creating two documents, which are:
a) Application of Standard MIB Objects for CAPWAP Systems, and
b) Definition of Management Objects for CAPWAP Systems.
Is this the most appropriate approach to take?
Plan for CAPWAP Object and Notification Definitions
---------------------------------------------------
For the actual objects for CAPWAP, I'm planning to
try to go minimal. That is, in the first version of
the MIB module, include only those objects and notifications
that are (or can be) supported by all current vendors
and provide clear need in writing mgmt apps that provide
high value. The current candidate tables include:
1) configured WTPs (with minimal config info, which
is not enough to be used to configure WTPs).
2) WTPs that have been connected to the AC, with status
and statistics info for each connection
3) status and statistics of currently associated STAs
4) configuration of "wireless LANs"
5) configuration of "radios" on the WTPs
6) status and statistics of the radios on the WTPs
What I don't plan to include is statistics on message
types of the CAPWAP protocol.
Regards,
/david t. perkins