[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Help getting CAPWAP MIB doc plan started
I strongly believe that the working group should follow the concept of
reusing MIB modules and structures. In fact our implementation follow
suit to some extent.
Emek
-----Original Message-----
From: David T. Perkins [mailto:dperkins@dsperkins.com]
Sent: Thursday, February 02, 2006 7:19 PM
To: Sadot, Emek (Emek)
Cc: Romascanu, Dan (Dan); mreview@ops.ietf.org
Subject: RE: Help getting CAPWAP MIB doc plan started
HI,
Emek - thank you for the information.
MIB docs - the reason that I sent you the message was to get some
feedback on a somewhat unusual approach, and get your buyoff before
presenting this approach to the WG. The last thing that I wanted was
trashing or a battle of MIB docs on the CAPWAP WG mailing list, or late
review comments that the approach was flawed.
The primary goal of the approach is to reuse existing MIB modules, and
not to rewrite all applicable MIB modules to include an "extra" index
identifying an WTP (an access point).
I would appreciate getting any feedback about potential problems with
the approach that I have described in the message below. That is,
modelling the collection of an AC and connected WTPs as a single SNMP
managable system.
Please note that I just recently verified that at lease one current
CAPWAP vendor took standard MIB modules and created vendor MIB modules
that have the "extra"
index inserted. This seems like a big waste if we can use the existing
MIB modules unmodified.
Regards,
/david t. perkins
On Thu, 2 Feb 2006, Sadot, Emek (Emek) wrote:
> David Hi,
>
> Your proposed approach makes sense. In our implementation we anchored
> the WTP to the iFtable, thus derive other tables as of this index.
>
> I think that CAPWAP statistic thru the MIB based shall be in place.
> However on the battle between adding more components vs. protocol
> debug, I would argue in favor of pushing statistics to the next
> release as alleviating the magnitude at this point shall (in my
> opinion) take precedence.
>
> If you need a hand in pulling it out, please let me know.
>
> Regards,
> Emek
>
> -----Original Message-----
> From: Romascanu, Dan (Dan)
> Sent: Wednesday, February 01, 2006 11:14 AM
> To: David T. Perkins; mreview@ops.ietf.org
> Cc: Sadot, Emek (Emek)
> Subject: 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
>
>
>
>