[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Help getting CAPWAP MIB doc plan started
David,
I suggest that you post your proposal also on the CAPWAP list. I believe
that something similar was developped in my company, but I was not
directly involved in the project. I copy my colleague Emek Sadot who may
know more.
In principle, it looks like the Entity MIB can help in modeling the
WTPs. To a certain extent the use of Interface MIB, Bridge MIB and the
802.11 MIB can apply for these. That's what your suggested document a)
is about I guess.
It sounds odd to me your suggestion not to do CAPWAP protocol statistics
however. How do you debug the protocol itself, at first deployment
phases especially?
Regards,
Dan
> -----Original Message-----
> From: owner-mreview@ops.ietf.org
> [mailto:owner-mreview@ops.ietf.org] On Behalf Of David T. Perkins
> Sent: Tuesday, January 31, 2006 10:49 PM
> To: mreview@ops.ietf.org
> Subject: 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-objectiv
es-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