RFC 5833
Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Base MIB
Pages: 73
Informational
Informational
Part 1 of 4 – Pages 1 to 14
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 MIBAbstract
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.
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
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].
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].
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;
- 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
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
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.
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.
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.
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].
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.
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.
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)