Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5833

Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Base MIB

Pages: 73
Informational
Part 1 of 4 – Pages 1 to 14
None   None   Next

Top   ToC   RFC5833 - Page 1
Internet Engineering Task Force (IETF)                       Y. Shi, Ed.
Request for Comments: 5833                  Hangzhou H3C Tech. Co., Ltd.
Category: Informational                                  D. Perkins, Ed.
ISSN: 2070-1721                                          C. Elliott, Ed.

                                                           Y. Zhang, Ed.
                                                          Fortinet, Inc.
                                                                May 2010


  Control and Provisioning of Wireless Access Points (CAPWAP) Protocol
                                Base MIB

Abstract

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes the managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol. This MIB module is presented as a basis for future work on the SNMP management of the CAPWAP protocol. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5833.
Top   ToC   RFC5833 - Page 2
Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Internet-Standard Management Framework . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Requirements and Constraints . . . . . . . . . . . . . . . 5 5.2. Wireless Binding MIB Modules . . . . . . . . . . . . . . . 5 5.3. Design Objectives . . . . . . . . . . . . . . . . . . . . 5 5.4. Design Idea . . . . . . . . . . . . . . . . . . . . . . . 6 5.5. Mechanism of Reusing Wireless Binding MIB Modules . . . . 6 5.6. CAPWAP Protocol Wireless Binding MIB Module . . . . . . . 7 5.7. WTP Profile . . . . . . . . . . . . . . . . . . . . . . . 7 6. Structure of the MIB Module . . . . . . . . . . . . . . . . . 8 7. Relationship to Other MIB Modules . . . . . . . . . . . . . . 9 7.1. Relationship to SNMPv2-MIB Module . . . . . . . . . . . . 9 7.2. Relationship to IF-MIB Module . . . . . . . . . . . . . . 9 7.3. Relationship to ENTITY-MIB Module . . . . . . . . . . . . 10 7.4. Relationship to Wireless Binding MIB Modules . . . . . . . 10 7.5. MIB Modules Required for IMPORTS . . . . . . . . . . . . . 10 8. Example of CAPWAP-BASE-MIB Module Usage . . . . . . . . . . . 10 9. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 69 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70 11.1. IANA Considerations for CAPWAP-BASE-MIB Module . . . . . . 70 11.2. IANA Considerations for ifType . . . . . . . . . . . . . . 70 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 70 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 71 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 71 14.1. Normative References . . . . . . . . . . . . . . . . . . . 71 14.2. Informative References . . . . . . . . . . . . . . . . . . 72
Top   ToC   RFC5833 - Page 3

1. Introduction

The CAPWAP Protocol [RFC5415] defines a standard, interoperable protocol, which enables an Access Controller (AC) to manage a collection of Wireless Termination Points (WTPs). This document defines a MIB module that can be used to manage the CAPWAP implementations. This MIB module covers both configuration and WTP status-monitoring aspects of CAPWAP, and provides a way to reuse MIB modules for any wireless technology. It presented as a basis for future work on a SNMP management of the CAPWAP protocol.

2. The Internet-Standard Management Framework

For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579], and STD 58, RFC 2580 [RFC2580].

3. Terminology

This document uses terminology from the CAPWAP Protocol specification [RFC5415] and the Architecture Taxonomy for CAPWAP [RFC4118]. Access Controller (AC): The network entity that provides WTP access to the network infrastructure in the data plane, control plane, management plane, or a combination therein. Wireless Termination Point (WTP): The physical or network entity that contains an radio frequency (RF) antenna and wireless physical layer (PHY) to transmit and receive station traffic for wireless access networks. Control And Provisioning of Wireless Access Points (CAPWAP): It is a generic protocol defining AC and WTP control and data plane communication via a CAPWAP protocol transport mechanism. CAPWAP control messages, and optionally CAPWAP data messages, are secured using Datagram Transport Layer Security (DTLS) [RFC4347].
Top   ToC   RFC5833 - Page 4
   CAPWAP Control Channel: A bi-directional flow defined by the AC IP
   Address, WTP IP Address, AC control port, WTP control port, and the
   transport-layer protocol (UDP or UDP-Lite) over which CAPWAP control
   packets are sent and received.

   CAPWAP Data Channel: A bi-directional flow defined by the AC IP
   Address, WTP IP Address, AC data port, WTP data port, and the
   transport-layer protocol (UDP or UDP-Lite) over which CAPWAP data
   packets are sent and received.

   Station (STA): A device that contains an interface to a wireless
   medium (WM).

   Split and Local MAC: The CAPWAP protocol supports two modes of
   operation: Split and Local MAC (medium access control).  In Split MAC
   mode, all Layer 2 wireless data and management frames are
   encapsulated via the CAPWAP protocol and exchanged between the AC and
   the WTPs.  The Local MAC mode allows the data frames to be either
   locally bridged or tunneled as 802.3 frames.

   Wireless Binding: The CAPWAP protocol is independent of a specific
   WTP radio technology, as well its associated wireless link-layer
   protocol.  Elements of the CAPWAP protocol are designed to
   accommodate the specific needs of each wireless technology in a
   standard way.  Implementation of the CAPWAP protocol for a particular
   wireless technology MUST define a binding protocol for it, e.g., the
   binding for IEEE 802.11, provided in [RFC5416].

   Autonomous Wireless Local Area Network (WLAN) Architecture: It is the
   traditional autonomous WLAN architecture, in which each WTP is a
   single physical device that implements all the wireless services.

   Centralized WLAN Architecture: It is an emerging hierarchical
   architecture utilizing one or more centralized controllers for
   managing a large number of WTP devices.  It can be said that the full
   wireless functions are implemented across multiple physical network
   devices, namely, the WTPs and ACs.

4. Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
Top   ToC   RFC5833 - Page 5

5. Overview

5.1. Requirements and Constraints

The CAPWAP Protocol MIB module (CAPWAP-BASE-MIB) is designed to: - Support centralized management and monitoring of WTPs from the AC in combination with the CAPWAP protocol; - Allow operators to make configurations for WTPs before and after they connect to the AC; - Support querying of CAPWAP protocol parameters; - Support displaying of WTPs' current states and configurations; - Provide basic property information about the AC, WTPs, radios, and stations, and their relationships; - Provide counters for events on WTPs and radios such as reboot and hardware failure; - Provide various notifications such as channel up and join failure.

5.2. Wireless Binding MIB Modules

Other Standards Development Organizations (SDOs), such as IEEE, have already defined MIB modules for a specific wireless technology, e.g., IEEE 802.11 MIB module [IEEE.802-11.2007]. Such MIB modules are called wireless binding MIB modules.

5.3. Design Objectives

This document introduces a mechanism to avoid redefining MIB objects in the existing MIB modules for a specific wireless technology, in other words, a mechanism to reuse wireless binding MIB modules defined by other SDOs. In summary, the CAPWAP-BASE-MIB module has the following design objectives: - To implement an architecture that uses SNMP for the management and control of wireless networks, and answering the operator's requirements for centralized management, whatever the wireless devices are configured and deployed (centralized, autonomous, or some mix); - To be consistent with the CAPWAP protocol;
Top   ToC   RFC5833 - Page 6
   -  To be independent of any wireless technologies and be able to
      reuse wireless binding MIB modules defined by other SDOs;

   -  To enable interoperability between vendors;

   -  To meet the management requirements for the centralized WLAN
      architecture.

5.4. Design Idea

The basic design idea of the CAPWAP-BASE-MIB module is: - The SNMP agent MUST be run on the AC devices and is not REQUIRED on the WTP devices. It follows the same model as the CAPWAP protocol: Centralized Control. - It is designed to accommodate the specific needs of each wireless technology in a standard way. It is independent of any wireless technologies. - The ifIndex [RFC2863] is used as a common index for corresponding interfaces in the CAPWAP-BASE-MIB and the MIB modules of specific wireless technologies. - The operator could manage and control the centralized WLAN architectures using multiple MIB modules defined by multiple SDOs, while keeping them loosely coupled.

5.5. Mechanism of Reusing Wireless Binding MIB Modules

For any wireless technology, the configuration and management of radios are very important. As usual, wireless binding MIB modules support radio management on their own. For example, the MIB tables such as the dot11OperationTable [IEEE.802-11.2007] are able to support WTP radio configuration. These tables use the ifIndex as the index, and work well under autonomous WLAN architecture. To reuse such wireless binding MIB modules is very important to centralized WLAN architectures. According to [RFC5415], a specific PHY radio could be identified by the combination of the identifiers of the WTP and radio (WTP ID + Radio ID), so the key point is to make use of the ifIndex idea and find a way to maintain the mappings between 'WTP ID + radio ID' and the ifIndex. As a generic mechanism, an ifIndex can identify an interface in an abstract way, and it does NOT care for the interface's PHY location (either on the WTP or AC). The AC can have WTP Virtual Radio Interfaces to logically represent PHY radios on the WTP. From the operator's perspective, it appears that PHY radios are located on the AC, and the PHY location of the
Top   ToC   RFC5833 - Page 7
   WTP (radio) is hidden.  The operator can operate radios through MIB
   tables with the ifIndex of a WTP Virtual Radio Interface.  As a type
   of abstract interface, the WTP Virtual Radio Interface could be used
   by any wireless technology such as IEEE 802.11 and 802.16.  The
   capwapBaseWirelessBindingTable in the CAPWAP-BASE-MIB module is used
   to store the mappings between the 'WTP ID + Radio ID' and the
   ifIndex.

5.6. CAPWAP Protocol Wireless Binding MIB Module

According to the CAPWAP Protocol specification [RFC5415], when defining a binding for wireless technologies, the authors MUST include any necessary definitions for technology-specific messages and all technology-specific message elements for those messages. A CAPWAP binding protocol is required for a specific wireless binding technology, e.g., the protocol of [RFC5416] for IEEE 802.11 binding. Sometimes, not all the technology-specific message elements in a CAPWAP binding protocol have MIB objects defined by other SDOs. For example, the protocol of [RFC5416] defines WLAN management. The WLAN refers to a logical component instantiated on a WTP device. A single physical WTP MAY operate a number of WLANs. Also, Local or Split MAC modes could be specified for a WLAN. The MAC mode for a WLAN is not in the scope of IEEE 802.11 [IEEE.802-11.2007]. In such cases, in addition to the existing wireless binding MIB modules defined by other SDOs, a CAPWAP protocol wireless binding MIB module is required to be defined for a wireless binding, e.g, the CAPWAP Protocol Binding MIB for IEEE 802.11 [RFC5834].

5.7. WTP Profile

In a centralized WLAN architecture, a WTP profile is used to make configurations such as a static IP address for a WTP before and after it connects to the AC. It MUST contain the Base MAC address [RFC5415] of the WTP because the CAPWAP message received from the WTP contains the Base MAC address and the AC uses this Base MAC address to find the corresponding WTP profile. Section 4.6.40 of [RFC5415] omits indicating that the WTP's Base MAC address MUST be included in the WTP Board Data message element. This is a known errata item [Err1832] and should be fixed in any future revision of RFC 5415. Another important function of WTP profile is to trigger the creation of WTP Virtual Radio Interfaces on the AC. To implement this function, a WTP profile MUST include the WTP's model number [RFC5415], which reflects the number of PHY radios on the WTP. In this way, the creation of a WTP profile triggers the AC to
Top   ToC   RFC5833 - Page 8
   automatically create the same number of WTP Virtual Radio Interfaces
   corresponding to the WTP's PHY radios without manual intervention.
   With the ifIndexes of WTP Virtual Radio Interfaces, the operator
   could configure and manage the WTP's PHY radios through the wireless
   binding MIB modules.

6. Structure of the MIB Module

The MIB objects are derived from the CAPWAP protocol document [RFC5415]. 1) capwapBaseAcNameListTable The AC name list table is used to configure the AC name list. 2) capwapBaseMacAclTable The ACL table is used to configure stations' Access Control Lists (ACLs). 3) capwapBaseWtpProfileTable The WTP profile table is used to configure WTP profiles for WTPs to be managed before they connect to the AC. An operator could change a WTP's current configuration by changing the values of parameters in the corresponding WTP profile, then the WTP could get the new configuration through the CAPWAP control channel. 4) capwapBaseWtpStateTable The state table of WTPs is used to indicate the AC's CAPWAP FSM state for each WTP, and helps the operator to query a WTP's current configuration. 5) capwapBaseWtpTable The WTP table is used to display properties of the WTPs in running state. 6) capwapBaseWirelessBindingTable The wireless binding table is used to display the mappings between WTP Virtual Radio Interfaces and PHY radios, and the wireless binding type for each PHY radio.
Top   ToC   RFC5833 - Page 9
   7) capwapBaseStationTable

      The station table is used for providing stations' basic property
      information.

   8) capwapBaseWtpEventsStatsTable

      The WTP events statistic table is used for collecting WTP reboot
      count, link failure count, hardware failure count and so on.

   9) capwapBaseRadioEventsStatsTable

      The radio events statistic table is used for collecting radio
      reset count, channel change count, hardware failure count, and so
      on.

7. Relationship to Other MIB Modules

7.1. Relationship to SNMPv2-MIB Module

The CAPWAP-BASE-MIB module does not duplicate the objects of the 'system' group in the SNMPv2-MIB [RFC3418] that is defined as being mandatory for all systems, and the objects apply to the entity as a whole. The 'system' group provides identification of the management entity and certain other system-wide data.

7.2. Relationship to IF-MIB Module

The Interfaces Group [RFC2863] defines generic managed objects for managing interfaces. This memo contains the media-specific extensions to the Interfaces Group for managing WTP PHY radios that are modeled as interfaces. The IF-MIB module is required to be supported on the AC. Each PHY radio on the WTP corresponds to a WTP Virtual Radio Interface on the AC. The WTP Virtual Radio Interface provides a way to configure the radio's parameters and query radio's traffic statistics, and reuse wireless binding modules defined by other SDOs. The interface MUST be modeled as an ifEntry, and ifEntry objects such as ifIndex, ifDescr, ifName, and ifAlias are to be used as per [RFC2863]. Also, as an ifIndex [RFC2863] is used as a common index for corresponding interfaces in the CAPWAP-BASE-MIB and specific wireless technologies MIB modules, the AC MUST have a mechanism that preserves the values of the ifIndexes in the ifTable at AC reboot.
Top   ToC   RFC5833 - Page 10

7.3. Relationship to ENTITY-MIB Module

The ENTITY-MIB module [RFC4133] meets the need for a standardized way of representing a single agent that supports multiple instances of one MIB. It could express a certain relationship between multiple entities and provide entity properties for each entity. In a centralized WLAN architecture, the SNMP agent runs on the AC and is not required on the WTP. With the ENTITY-MIB module on the AC, it could keep entity information such as firmware revision and software revision of the AC and WTPs. From the ENTITY-MIB module's perspective, the overall physical entity (AC) is a 'compound' of multiple physical entities (that is, the WTPs connected to AC), and all entities are each identified by a physical index. The capwapBaseWtpTable of the CAPWAP-BASE-MIB module uses the capwapBaseWtpPhyIndex object to store the mappings of WTP object between CAPWAP-BASE-MIB and ENTITY-MIB modules. By querying both the CAPWAP-BASE-MIB and ENTITY-MIB modules, operators could query the status and properties of the AC and WTPs. For example, they could get a WTP's current status through the CAPWAP-BASE-MIB module, and a WTP's software revision information through the ENTITY-MIB module. The CAPWAP-BASE-MIB module does not duplicate those objects defined in the ENTITY-MIB module.

7.4. Relationship to Wireless Binding MIB Modules

The wireless binding MIB module of a wireless technology (such as [IEEE.802-11.2007]) is required to be supported on the AC. The CAPWAP-BASE-MIB module is able to support any wireless binding. Through the ifIndexes of WTP Virtual Radio Interfaces, it provides a consistent and abstract way of reusing MIB objects in the wireless binding MIB modules. The CAPWAP-BASE-MIB module does not duplicate those objects defined in the wireless binding MIB modules.

7.5. MIB Modules Required for IMPORTS

The following MIB module IMPORTS objects from SYSAPPL-MIB [RFC2287], SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], IF-MIB [RFC2863], SNMP-FRAMEWORK-MIB [RFC3411], INET-ADDRESS-MIB [RFC4001], and ENTITY-MIB [RFC4133].

8. Example of CAPWAP-BASE-MIB Module Usage

Below, the IEEE 802.11 binding is used as an example of how the MIB modules operate. 1) Create a WTP profile.
Top   ToC   RFC5833 - Page 11
      Suppose the WTP's Base MAC address is '00:01:01:01:01:00'.  Create
      the WTP profile as follows:

     In capwapBaseWtpProfileTable
     {
       capwapBaseWtpProfileId                  = 1,
       capwapBaseWtpProfileName                = 'WTP Profile 123456',
       capwapBaseWtpProfileWtpMacAddress       = '00:01:01:01:01:00',
       capwapBaseWtpProfileWtpModelNumber             = 'WTP123',
       capwapBaseWtpProfileWtpName                    = 'WTP 123456',
       capwapBaseWtpProfileWtpLocation                = 'office',
       capwapBaseWtpProfileWtpStaticIpEnable          = true(1),
       capwapBaseWtpProfileWtpStaticIpType            = ipv4(1),
       capwapBaseWtpProfileWtpStaticIpAddress         = '192.0.2.10',
       capwapBaseWtpProfileWtpNetmask                 = '255.255.255.0',
       capwapBaseWtpProfileWtpGateway                 = '192.0.2.1',
       capwapBaseWtpProfileWtpFallbackEnable          = true(1),
       capwapBaseWtpProfileWtpEchoInterval            = 30,
       capwapBaseWtpProfileWtpIdleTimeout             = 300,
       capwapBaseWtpProfileWtpMaxDiscoveryInterval    = 20,
       capwapBaseWtpProfileWtpReportInterval          = 120,
       capwapBaseWtpProfileWtpStatisticsTimer         = 120,
       capwapBaseWtpProfileWtpEcnSupport              = limited(0)
     }

      Suppose the WTP with model number 'WTP123' has one PHY radio,
      which is identified by ID 1.  The creation of this WTP profile
      triggers the AC to automatically create a WTP Virtual Radio
      Interface and add a new row object to the
      capwapBaseWirelessBindingTable without manual intervention.
      Suppose the ifIndex of the WTP Virtual Radio Interface is 10.  The
      following information is stored in the
      capwapBaseWirelessBindingTable.

      In capwapBaseWirelessBindingTable
      {
        capwapBaseWtpProfileId                          = 1,
        capwapBaseWirelessBindingRadioId                = 1,
        capwapBaseWirelessBindingVirtualRadioIfIndex    = 10,
        capwapBaseWirelessBindingType                   = dot11(2)
      }

      The WTP Virtual Radio Interfaces on the AC correspond to the PHY
      radios on the WTP.  The WTP Virtual Radio Interface is modeled by
      ifTable [RFC2863].
Top   ToC   RFC5833 - Page 12
      In ifTable
      {
        ifIndex              = 10,
        ifDescr              = 'WTP Virtual Radio Interface',
        ifType               = 254,
        ifMtu                = 0,
        ifSpeed              = 0,
        ifPhysAddress        = '00:00:00:00:00:00',
        ifAdminStatus        = true(1),
        ifOperStatus         = false(0),
        ifLastChange         = 0,
        ifInOctets           = 0,
        ifInUcastPkts        = 0,
        ifInDiscards         = 0,
        ifInErrors           = 0,
        ifInUnknownProtos    = 0,
        ifOutOctets          = 0,
        ifOutUcastPkts       = 0,
        ifOutDiscards        = 0,
        ifOutErrors          = 0
       }

   2) Query the ifIndexes of WTP Virtual Radio Interfaces.

      Before configuring PHY radios, the operator needs to get the
      ifIndexes of WTP Virtual Radio Interfaces corresponding to the PHY
      radios.

      As capwapBaseWirelessBindingTable already stores the mappings
      between PHY radios (Radio IDs) and the ifIndexes of WTP Virtual
      Radio Interfaces, the operator can get the ifIndex information by
      querying this table.  Such a query operation SHOULD run from radio
      ID 1 to radio ID 31 according to [RFC5415]), and stop when an
      invalid ifIndex value (0) is returned.

      This example uses capwapBaseWtpProfileId = 1 and
      capwapBaseWirelessBindingRadioId = 1 as inputs to query the
      capwapBaseWirelessBindingTable, and gets
      capwapBaseWirelessBindingVirtualRadioIfIndex = 10.  Then it uses
      capwapBaseWtpProfileId = 1 and capwapBaseWirelessBindingRadioId =
      2, and gets an invalid ifIndex value (0), so the query operation
      ends.  This method gets not only the ifIndexes of WTP Virtual
      Radio Interfaces, but also the numbers of PHY radios.  Besides
      checking whether the ifIndex value is valid, the operator SHOULD
      check whether the capwapBaseWirelessBindingType is the desired
      binding type.
Top   ToC   RFC5833 - Page 13
   3) Configure specific wireless binding parameters for a WTP Virtual
   Radio Interface.

      This configuration is made on the AC through a specific wireless
      binding MIB module such as the IEEE 802.11 MIB module.

      The following shows an example of configuring parameters for a WTP
      Virtual Radio Interface with ifIndex 10 through the IEEE 802.11
      dot11OperationTable [IEEE.802-11.2007].

      In dot11OperationTable
      {
        ifIndex                                  = 10,
        dot11MACAddress                          = '00:00:00:00:00:00',
        dot11RTSThreshold                        = 2347,
        dot11ShortRetryLimit                     = 7,
        dot11LongRetryLimit                      = 4,
        dot11FragmentationThreshold              = 256,
        dot11MaxTransmitMSDULifetime             = 512,
        dot11MaxReceiveLifetime                  = 512,
        dot11ManufacturerID                      = 'capwap',
        dot11ProductID                           = 'capwap',
        dot11CAPLimit                            = 2,
        dot11HCCWmin                             = 0,
        dot11HCCWmax                             = 0,
        dot11HCCAIFSN                            = 1,
        dot11ADDBAResponseTimeout                = 1,
        dot11ADDTSResponseTimeout                = 1,
        dot11ChannelUtilizationBeaconInterval    = 50,
        dot11ScheduleTimeout                     = 10,
        dot11DLSResponseTimeout                  = 10,
        dot11QAPMissingAckRetryLimit             = 1,
        dot11EDCAAveragingPeriod                 = 5
      }

   4) Get the current configuration status report from the WTP to the
   AC.

      According to [RFC5415], before a WTP that has joined the AC gets
      configuration from the AC, it needs to report its current
      configuration status by sending a configuration status request
      message to the AC, which uses the message to update MIB objects on
      the AC.  For example, for IEEE 802.11 binding, the AC updates data
      in the ifTable [RFC2863] and IEEE 802.11 MIB module, and so on,
      according to the message.  For ifIndex 10, its ifOperStatus in
      ifTable is updated according to the current radio operational
      status in the CAPWAP message.
Top   ToC   RFC5833 - Page 14
   5) Query WTP and radio statistical data.

      After WTPs start to run, the operator could query WTP and radio
      statistical data through CAPWAP-BASE-MIB and the specific binding
      MIB module on the AC.  For example, through dot11CountersTable in
      the IEEE 802.11 MIB module, the operator could query the counter
      data of a radio using the ifIndex of the corresponding WTP Virtual
      Radio Interface.  With the capwapBaseWtpTable table in the CAPWAP-
      BASE-MIB module, the operator could query the properties of
      running WTPs.

   6) Run MIB operations through a CAPWAP protocol wireless binding MIB
   module.

      For example, for the CAPWAP IEEE 802.11 binding protocol
      [RFC5416], some MIB operations such as MAC mode configuration for
      a WLAN depend on the CAPWAP Protocol Binding MIB for IEEE 802.11
      [RFC5834].  For more information, refer to [RFC5834].

   7) Query other properties of a WTP.

      The Operator could query MIB objects in the ENTITY-MIB [RFC4133]
      module by using the capwapBaseWtpPhyIndex in the
      capwapBaseWtpTable of CAPWAP-BASE-MIB module.  The properties of a
      WTP such as software version, hardware version are available in
      the ENTITY-MIB module.



(page 14 continued on part 2)

Next Section