RE: Help getting CAPWAP MIB doc plan started

["David B Harrington" <dbharrington@comcast.net>]

Hi,

I'll try (but fail) to be terse ;-)

Without delving into the details of CAPWAP, a few things come to mind.

1) I feel it would be useful to keep statistics on the CAPWAP
messages, but cannot provide a justification.

2) with wireless devices, it can be important to understand the
overlap of coverage, so WTPs can adjust their power output to minimize
interference with other WTPs. Will the MIB modules reflect the STAs
associated with each WTP (so duplicates can be detected), and the
power levels of each WTP, and include SNMP knobs to adjust the power
levels (and possibly other characteristics) of the WTPs to minimize
duplicated associations between WTPs? 

3) rogue access points are a notable problem in wireless networks. To
detect them, one would need to have some understanding of the WTPs
visible to the STAs. Will your modeling include any gathering of WTP
visibility from the STAs, presumably passed via the associated WTP(s)
to the AC?

An alternative to gathering WTP visibility to the STAs is to have the
WTPs switch to STA mode to detect other WTPs within its range. Will
your modeling include the possibility of gathering WTP visibility from
a dual-mode WTP/STA?

4) I am of the impression, but I'd really need to check, that WTPs can
be used as relays to other WTPs. With the CAPWAP approach, can an AC
ever support nested/relayed WTPs? If so, how will you model that?

-
Given the need to gather stats from multiple levels of the wireless
hierarchy, I can see a real problem of large tables emerging trying to
do all the SNMP MIBs for three (or more) levels at the AC level. This
could lead to a situation where it is decided to not bother developing
manageability for WTPs and STAs because the only-at-the-AC design is
flawed, or to develop a new management protocol as part of CAPWAP that
basically duplicates the functionality that would be provided by
having SNMP in the WTPs and STAs if a more "normal" approach to SNMP
modeling was used.

Won't you have somewhat similar problems of scalability using a CLI or
web-based mgmt if the tables can grow as large as you expect?

Will the AC use Netconf (the expected IETF standard for configuration
maagement) to configure the WTPs? If not, why not? ;-)

David Harrington
dbharrington@comcast.net

 

> -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com] 
> Sent: Tuesday, January 31, 2006 4:24 PM
> To: dbharrington@comcast.net
> Subject: fwd: Help getting CAPWAP MIB doc plan started
> 
> HI,
> 
> Here it is. I didn't see it either. Maybe there is
> a limit on the size of email messages, and it is
> waiting for approval.
> 
> Regards,
> /david t. perkins
> 
> ---------- Forwarded message ----------
> Date: Tue, 31 Jan 2006 12:48:45 -0800 (PST)
> From: David T. Perkins <dperkins@dsperkins.com>
> 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
> 
> 
>