Internet Engineering Task Force Y. Shi, Ed. Internet-Draft H3C Tech. Co., Ltd Intended status: Standards Track D. Perkins, Ed. Expires: September 1, 2009 SNMPinfo C. Elliott, Ed. Cisco Systems, Inc. Y. Zhang, Ed. Fortinet, Inc. February 28, 2009 CAPWAP Protocol Base MIB draft-ietf-capwap-base-mib-04 Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 1, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Shi, et al. Expires September 1, 2009 [Page 1] Internet-Draft CAPWAP Protocol Base MIB February 2009 Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Internet-Standard Management Framework . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 6. Structure of the MIB Module . . . . . . . . . . . . . . . . . 7 7. Relationship to Other MIB Modules . . . . . . . . . . . . . . 8 7.1. Relationship to SNMPv2-MIB Module . . . . . . . . . . . . 8 7.2. Relationship to IF-MIB Module . . . . . . . . . . . . . . 8 7.3. Relationship to ENTITY-MIB Module . . . . . . . . . . . . 9 7.4. Relationship to Wireless Binding MIB Modules . . . . . . . 9 7.5. MIB Modules Required for IMPORTS . . . . . . . . . . . . . 10 8. Example of CAPWAP-BASE-MIB Module Usage . . . . . . . . . . . 10 9. CAPWAP Message Element Extension . . . . . . . . . . . . . . . 12 9.1. CAPWAP Protocol Timers . . . . . . . . . . . . . . . . . . 13 9.2. CAPWAP Protocol Variables . . . . . . . . . . . . . . . . 16 9.3. CAPWAP Messages for CAPWAP Control Message Extension . . . 16 9.3.1. Configuration Status Response Message . . . . . . . . 16 9.3.2. Configuration Update Response Message . . . . . . . . 17 10. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 65 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 12.1. IANA Considerations for CAPWAP-BASE-MIB module . . . . . . 67 12.2. IANA Considerations for ifType . . . . . . . . . . . . . . 67 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 67 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 67 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 67 15.1. Normative References . . . . . . . . . . . . . . . . . . . 67 15.2. Informative References . . . . . . . . . . . . . . . . . . 69 Appendix A. Appendix A. Changes between -04 and -03 . . . . . . . 71 Shi, et al. Expires September 1, 2009 [Page 2] Internet-Draft CAPWAP Protocol Base MIB February 2009 1. Introduction The CAPWAP Protocol [I-D.ietf-capwap-protocol-specification] 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 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. 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 [I-D.ietf-capwap-protocol-specification] 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 RF antenna and wireless 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 Shi, et al. Expires September 1, 2009 [Page 3] Internet-Draft CAPWAP Protocol Base MIB February 2009 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. In Split MAC mode all L2 wireless data and management frames are encapsulated via the CAPWAP protocol and exchanged between the AC and the WTPs. The Local MAC mode of operation allows for 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 defining a binding protocol for it, e.g., the binding for IEEE 802.11, provided in [I-D.ietf-capwap-protocol-binding-ieee80211]. Autonomous 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 Shi, et al. Expires September 1, 2009 [Page 4] Internet-Draft CAPWAP Protocol Base MIB February 2009 5.1. Requirements and Constraints The CAPWAP Protocol MIB module (CAPWAP-BASE-MIB) is designed to satisfy the following requirements and constraints: - From AC to centrally manage and monitor WTPs; - Supports CAPWAP protocol parameters queries; - Supports showing WTPs current state; - Provides the information of AC, WTP, radio and station objects' basic property and their relationship; - Supports indicating the 'WTP Virtual Radio Interface' and PHY radio's mapping relationship; - Provides counters for WTP, radio's reboot event, hardware event failure and so on; - Provides the various notifications like channel up, join failure and so on. 5.2. Wireless Binding MIB Modules Other Standards Developing Organizations (SDOs), such as IEEE, have already defined MIB modules for a specific wireless technology, e.g., the MIB module in IEEE 802.11 standard [IEEE.802-11.2007]. Such MIB modules are called as wireless binding MIB module. 5.3. Design Objectives This document brings forward a mechanism to avoid redefining MIB objects in the existing MIB modules for a specific wireless technology, in another words, a mechanism to reuse wireless binding MIB modules defined by other SDOs. In summary, the CAPWAP-BASE-MIB module have the following design objectives: - To implement an architecture that uses SNMP for the management and control of wireless networks, answering the operators requirements for centralized management, whatever the deployment or configuration of the network devices (centralized, distributed, or some mix); - To be consistent with CAPWAP protocol; - To be independent of any wireless technologies and have ability to Shi, et al. Expires September 1, 2009 [Page 5] Internet-Draft CAPWAP Protocol Base MIB February 2009 reuse wireless binding MIB modules defined by other SDOs; - To enable interoperability between vendors; - To meet operator requirements for centralized wireless architectures. 5.4. Design Idea The basic design idea of CAPWAP-BASE-MIB module is: - The CAPWAP-BASE-MIB module MUST be run on the AC devices and is NOT REQUIRED on the WTP devices. It follows same idea as 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; - ifIndex [RFC2863] will be used as common handler for corresponding interfaces in the CAPWAP-BASE-MIB and specific wireless technologies MIB modules; - The operator could manage and control the centralized wireless architectures using multiple MIB modules defined by multiple SDOs, while keeping them loosely coupled. 5.5. Mechanism of Reusing Wireless Binding MIB Modules Before coming to details of CAPWAP-BASE-MIB module, it will introduce how CAPWAP-BASE-MIB module is able to be independent of any wireless technologies and reuse wireless binding MIB modules defined by other SDOs. As centralized Wireless architecture, the operator has to prepare configuration on the AC before WTPs connects to AC. For any wireless technology, the configuration and management of radio is very important. Under centralized WLAN architecture, according to [I-D.ietf-capwap-protocol-specification], a specific PHY radio could be identified by identifier of a WTP and radio (WTP id + radio id). As usual, wireless binding MIB modules support radio management on its own. For example, the MIB tables such as Dot11OperationTable [IEEE.802-11.2007] are able to support WTP radio configuration. These tables use ifIndex as the index, and work well under autonomous WLAN architecture. To reuse such wireless binding MIB modules is very important, and the key point is to reuse the idea of ifIndex. So it is required a way to maintain the mapping relationship between 'WTP id + radio id' and 'ifIndex'. As a generic mechanism, ifIndex can identify an interface Shi, et al. Expires September 1, 2009 [Page 6] Internet-Draft CAPWAP Protocol Base MIB February 2009 in abstract way, and it does NOT care for an interface's PHY location (either on the WTP or AC). AC can have interfaces of 'WTP Virtual Radio Interface' ifType, which will logically represent PHY radios on the WTP. It looks like that PHY radios are located on the AC, and PHY location of WTP (radio) is hidden to the operator. Operator can operate radios by MIB tables with ifIndex of 'WTP Virtual Radio Interface'. As an abstract interface, 'WTP Virtual Radio Interface' could be used by any wireless technology such as IEEE 802.11 and 802.16. The table of capwapBaseWirelessBindingTable in the CAPWAP- BASE-MIB module is used to indicate the such mapping relationship between 'WTP id + Radio id' and IfIndex. 5.6. CAPWAP Protocol Wireless Binding MIB Module According to the CAPWAP Protocol specification [I-D.ietf-capwap-protocol-specification], 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 [I-D.ietf-capwap-protocol-binding-ieee80211] 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 [I-D.ietf-capwap-protocol-binding-ieee80211] defines WLAN conception. 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 [I-D.ietf-capwap-802dot11-mib]. 6. Structure of the MIB Module The MIB objects were derived from the CAPWAP protocol document [I-D.ietf-capwap-protocol-specification]. 1) capwapBaseAcNameListTable The AC name list table is used to configure AC name list. 2) capwapBaseMacAclTable The ACL table is used to configure stations' Access Control Shi, et al. Expires September 1, 2009 [Page 7] Internet-Draft CAPWAP Protocol Base MIB February 2009 List(ACL). 3) capwapBaseWtpStateTable The WTPs status table is used to indicate each WTP's CAPWAP FSM state. 4) capwapBaseWtpTable The WTPs table is used for providing property and configuration information in details for WTPs in running state. 5) capwapBaseWirelessBindingTable The wireless binding table is used to indicate the mapping relationship between logical interface of 'WTP Virtual Radio Interface' ifType and PHY radio. 6) capwapBaseStationTable The station table is used for providing stations' basic property information. 7) capwapBaseWtpEventsStatsTable The WTP events statistic table is used for collecting WTP reboot count, link failure count, hardware failure count and so on. 8) 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 'system' group in the SNMPv2-MIB [RFC3418] 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. The CAPWAP-BASE-MIB module does not duplicate those objects. 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 radio object that Shi, et al. Expires September 1, 2009 [Page 8] Internet-Draft CAPWAP Protocol Base MIB February 2009 are modeled as interfaces. IF-MIB module is required to support on the AC. For each PHY radio on the WTP, it will have a logical interface of 'WTP Virtual Radio Interface' ifType on the AC. 'WTP Virtual Radio Interface' provides a way to configure 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 provide appropriate interface information. Also, as ifIndex [RFC2863] will be used as common handler for corresponding interfaces in the CAPWAP-BASE-MIB and specific wireless technologies MIB modules, the system (AC) MUST have a mechanism that preserves the values of ifIndex in the ifTable at AC reboot. 7.3. Relationship to ENTITY-MIB Module The ENTITY-MIB module [RFC4133] meets need for a standardized way of representing a single agent, which supports multiple instances of one MIB. It could express a certain relationship between multiple entities, and provide entity properties for each entity. Under the wireless centralized architectures, the SNMP agent will run on the AC, and not required on the WTP. By the ENTITY-MIB module on the AC, it could keep entity information such as firmware revision and software revision of AC and WTPs. From the ENTITY-MIB module perspective, the overall physical entity (AC) is a 'compound' of multiple physical entities (WTPs which connects to AC), all entities are identified by Physical index. In the capwapBaseWtpTable of CAPWAP-BASE-MIB module, it uses capwapBaseWtpPhyIndex object to keep the mapping relationship of WTP object between CAPWAP-BASE-MIB and ENTITY-MIB module. By combining the MIB modules, operators could query AC and WTP's status and properties. For example, they could get WTP's current status through CAPWAP-BASE-MIB module, and WTP's software revision information through 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 support on the AC. The CAPWAP- BASE-MIB module is able to support any wireless binding. Through ifIndex of 'WTP Virtual Radio Interface' ifType, it provides 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. Shi, et al. Expires September 1, 2009 [Page 9] Internet-Draft CAPWAP Protocol Base MIB February 2009 7.5. MIB Modules Required for IMPORTS The following MIB module IMPORTS objects from 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 With the idea of 'WTP Virtual Radio Interface' in the mind, the usage of the MIB modules will be easily understood. Here takes IEEE 802.11 binding as an example. 1) Identify the PHY radio by 'WTP Virtual Radio Interface' According to [I-D.ietf-capwap-protocol-specification], each radio on a WTP will be identified by a radio Id. Each WTP could be identified by its serial number. Suppose a WTP's serial number is '12345678', and first radio id is 1. On the AC, the ifIndex of interface in 'WTP Virtual Radio Interface' ifType is 10 which represents the PHY radio 1. The following information is obtained in the CapwapBaseWirelessBindingTable. In CapwapBaseWirelessBindingTable { capwapBaseWtpStateWtpId = '12345678', capwapBaseWirelessBindingRadioId = 1, capwapBaseWirelessBindingVirtualRadioIfIndex = 10, capwapBaseWirelessBindingType = dot11(2) } By the mechanism of 'WTP Virtual Radio Interface', it seems WTP PHY radios are located on the AC. The interface of 'WTP Virtual Radio Interface' ifType is modeled by ifTable [RFC2863]. Shi, et al. Expires September 1, 2009 [Page 10] Internet-Draft CAPWAP Protocol Base MIB February 2009 In ifTable { ifIndex = 10, ifDescr = 'WTP Virtual Radio Interface', ifType = xxx, RFC Editor - please replace xxx with the value allocated by IANA for IANAifType of 'WTP Virtual Radio Interface' ifMtu = 0, ifSpeed = 0, ifPhysAddress = '000000', ifAdminStatus = true, ifOperStatus = false, ifLastChange = 0, ifInOctets = 0, ifInUcastPkts = 0, ifInDiscards = 0, ifInErrors = 0, ifInUnknownProtos = 0, ifOutOctets = 0, ifOutUcastPkts = 0, ifOutDiscards = 0, ifOutErrors = 0 } 2) Configure specific wireless binding parameters for 'WTP Virtual Radio Interface' It will be done on the AC through specific wireless binding MIB module such as IEEE 802.11 MIB module. For example, to configure parameter for 'WTP Virtual Radio Interface' by IEEE 802.11 Dot11OperationTable [IEEE.802-11.2007]. In Dot11OperationTable { ifIndex = 10, dot11MACAddress = '000000', dot11RTSThreshold = 2347, dot11ShortRetryLimit = 7, dot11LongRetryLimit = 4, dot11FragmentationThreshold = 256, dot11MaxTransmitMSDULifetime = 512, dot11MaxReceiveLifetime = 512, dot11ManufacturerID = 'capwap', dot11ProductID = 'capwap' } In the example, it suppose ifIndex of an interface in 'WTP Virtual Shi, et al. Expires September 1, 2009 [Page 11] Internet-Draft CAPWAP Protocol Base MIB February 2009 Radio Interface' ifType is 10. 3) WTP reports its current configuration status According to [I-D.ietf-capwap-protocol-specification], after join phase and before WTP get configuration from AC, it will report its current configuration status to AC through configuration status request message. The data of MIB objects will be updated on the AC. For example, for IEEE 802.11 binding, WTP will update data in the ifTable and IEEE 802.11 MIB module so on according to message content. As an example for ifIndex 10, its ifOperStatus in ifTable will be updated according to current radio operational status in the CAPWAP message. 4) Query WTP and radio statistics data After WTPs come to run status, operator could query WTP and radio statistics data through CAPWAP-BASE-MIB and specific binding MIB module. For example, through dot11CountersTable in the IEEE 802.11 MIB module, operator could query counter data for radio which is identified by ifIndex of a virtual radio interface. With capwapBaseWtpTable table in the CAPWAP-BASE-MIB module, operator could query configuration and properties of WTPs which are in run status. 5) MIB operations through a CAPWAP protocol wireless binding MIB module For example, for CAPWAP IEEE 802.11 binding protocol [I-D.ietf-capwap-protocol-binding-ieee80211], Some MIB operations such as MAC mode configuration for a WLAN depend on the CAPWAP Protocol Binding MIB for IEEE 802.11 [I-D.ietf-capwap-802dot11-mib]. In the [I-D.ietf-capwap-802dot11-mib], it will give more explain. 6) Query other properties of WTP Operator could query MIB objects in the ENTITY-MIB module by capwapBaseWtpPhyIndex in the capwapBaseWtpTable of CAPWAP-BASE-MIB module. The properties of WTP such as software version, hardware version and so on are available in the ENTITY-MIB module. 9. CAPWAP Message Element Extension This section describes the CAPWAP control message extension for CAPWAP protocol to support CAPWAP-BASE-MIB module. To enable CAPWAP protocol timers and variables [I-D.ietf-capwap-protocol-specification] manageable through CAPWAP Shi, et al. Expires September 1, 2009 [Page 12] Internet-Draft CAPWAP Protocol Base MIB February 2009 protocol, the following capwap message element extensions are defined using Vendor Specific Payload message element in this section. These message elements are used by WTP to report extra configuration information to AC. CAPWAP Message Element Vendor Identifier Element ID CAPWAP Protocol Timers Id assigned by IANA 1 CAPWAP Protocol Variables Id assigned by IANA 2 9.1. CAPWAP Protocol Timers 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Element ID | DataChannelKeepAlive | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DataChannelDeadInterval | DiscoveryInterval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DTLSSessionDelete | EchoInterval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IdleTimeout | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ImageDataStartTimer | MaxDiscoveryInterval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ReportInterval | RetransmitInterval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SilentInterval | StatisticsTimer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WaitDTLS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: 37 for Vendor Specific Payload Length: 34 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI Network Management Private Enterprise Codes". Element ID: The Element ID field is set to 1 for CAPWAP Protocol Timers. DataChannelKeepAlive: A 16-bit value representing the time, in seconds, that is used by the WTP to determine the next must transmit the Data Channel Keep Alive. (see section 4.7.2 of [I-D.ietf-capwap-protocol-specification]). Shi, et al. Expires September 1, 2009 [Page 13] Internet-Draft CAPWAP Protocol Base MIB February 2009 DataChannelDeadInterval: A 16-bit value representing the minimum time, in seconds, a WTP MUST wait without having received a Data Channel Alive packets may be considered dead. The value of this timer MUST be no less than 2*DataChannelKeepAlive seconds and no greater that 240 seconds (see section 4.7.3 of [I-D.ietf- capwap-protocol-specification]). DiscoveryInterval: A 16-bit value representing the minimum time, in seconds, that a WTP MUST wait after receiving a Discovery Response message, before initiating a DTLS handshake (see section 4.7.5 of [I-D.ietf-capwap-protocol-specification]). DTLSSessionDelete: A 16-bit value representing the minimum time, in seconds, a WTP MUST wait for DTLS session deletion (see section 4.7.6 of [I-D.ietf-capwap-protocol-specification]). EchoInterval: A 16-bit value representing the minimum time, in seconds, between sending Echo Request messages to the AC with which the WTP has joined (see section 4.7.7 of [I-D.ietf-capwap- protocol-specification]). IdleTimeout: A 32-bit value representing the idle timeout value that the WTP SHOULD enforce for its active station. The default Idle Timeout is 300 seconds (see section 4.7.8 of [I-D.ietf-capwap- protocol-specification]). ImageDataStartTimer: A 16-bit value representing the number of seconds the WTP will wait for its peer to transmit the Image Data Request (see section 4.7.9 of [I-D.ietf-capwap-protocol- specification]). MaxDiscoveryInterval: A 16-bit value representing the maximum time allowed between sending Discovery Request messages, in seconds. This value MUST be no less than 2 seconds and no greater than 180 seconds (see section 4.7.10 of [I-D.ietf-capwap-protocol- specification]). ReportInterval: A 16-bit value representing the time, in seconds, that is used by the WTP to determine the interval the WTP uses between sending the Decryption Error message elements to inform the AC of decryption errors (see section 4.7.11 of [I-D.ietf- capwap-protocol-specification]). RetransmitInterval: A 16-bit value representing the minimum time, in seconds, in which a non-acknowledged CAPWAP packet will be retransmitted (see section 4.7.12 of [I-D.ietf-capwap-protocol- specification]). Shi, et al. Expires September 1, 2009 [Page 14] Internet-Draft CAPWAP Protocol Base MIB February 2009 SilentInterval: The minimum time, in seconds, a WTP MUST wait before it MAY again send Discovery Request messages or attempt to establish DTLS session (see section 4.7.13 of [I-D.ietf-capwap- protocol-specification]). StatisticsTimer: A 16-bit value representing the time, in seconds, that is used by the WTP to determine the interval the WTP uses between the WTP Events Requests it transmits to the AC to communicate its statistics (see section 4.7.14 of [I-D.ietf- capwap-protocol-specification]). WaitDTLS: A 16-bit value representing the maximum time, in seconds, a WTP MUST wait without having received a DTLS Handshake message from an AC. This timer MUST be greater than 30 seconds (see section 4.7.15 of [I-D.ietf-capwap-protocol- specification]). Shi, et al. Expires September 1, 2009 [Page 15] Internet-Draft CAPWAP Protocol Base MIB February 2009 9.2. CAPWAP Protocol Variables 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Element ID | MaxDiscoveries | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MaxFailedDTLSSessionRetry | MaxRetransmit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 37 for Vendor Specific Payload Length: 12 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI Network Management Private Enterprise Codes". Element ID: The Element ID field is set to 2 for CAPWAP Protocol Variables. MaxDiscoveries: A 16-bit value representing the maximum number of Discovery Request messages that will be sent after a WTP boots (see section 4.8.5 of [-D.ietf-capwap-protocol-specification]). MaxFailedDTLSSessionRetry: A 16-bit value representing the maximum number of failed DTLS session establishment attempts before the CAPWAP device enters a silent period (see section 4.8.6 of [I-D.ietf-capwap-protocol-specification]). MaxRetransmit: A 16-bit value representing the maximum number of retransmissions for a given CAPWAP packet before the link layer considers the peer dead (see section 4.8.7 of [I-D.ietf-capwap- protocol-specification]). 9.3. CAPWAP Messages for CAPWAP Control Message Extension For CAPWAP Control Message Extension, the following CAPWAP messages will be used. 9.3.1. Configuration Status Response Message The following message elements MAY be included in the CAPWAP Configuration Status Response Message. - CAPWAP Protocol Timers, see Section Section 9.1 Shi, et al. Expires September 1, 2009 [Page 16] Internet-Draft CAPWAP Protocol Base MIB February 2009 - CAPWAP Protocol Variables, see Section Section 9.2 9.3.2. Configuration Update Response Message The following message elements MAY be included in the CAPWAP Configuration Update Response Message. - CAPWAP Protocol Timers, see Section Section 9.1 - CAPWAP Protocol Variables, see Section Section 9.2 10. Definitions CAPWAP-BASE-MIB DEFINITIONS ::= BEGIN IMPORTS PhysAddress, TEXTUAL-CONVENTION, TruthValue, DateAndTime, RowStatus FROM SNMPv2-TC InterfaceIndex FROM IF-MIB PhysicalIndex FROM ENTITY-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB NOTIFICATION-GROUP, OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2, Integer32, Unsigned32, Counter32 FROM SNMPv2-SMI InetAddressType, InetAddress FROM INET-ADDRESS-MIB; capwapBaseMIB MODULE-IDENTITY LAST-UPDATED "200902280000Z" -- Feb 28th, 2009 ORGANIZATION "IETF Control And Provisioning of Wireless Access Points (CAPWAP) Working Group http://www.ietf.org/html.charters/capwap-charter.html" CONTACT-INFO "General Discussion: capwap@frascone.com To Subscribe: http://lists.frascone.com/mailman/listinfo/capwap Yang Shi H3C, Digital Technology Plaza, NO.9 Shangdi 9th Street,Haidian District,Beijing,China(100085) Email: young@h3c.com Shi, et al. Expires September 1, 2009 [Page 17] Internet-Draft CAPWAP Protocol Base MIB February 2009 David T. Perkins 228 Bayview Dr San Carlos, CA 94070 USA Phone: +1 408 394-8702 Email: dperkins@snmpinfo.com Chris Elliott Cisco Systems, Inc. 7025 Kit Creek Rd., P.O. Box 14987 Research Triangle Park 27709 USA Phone: +1 919-392-2146 Email: chelliot@cisco.com Yong Zhang Fortinet, Inc. 1090 Kifer Road Sunnyvale, CA 94086 USA Email: yzhang@fortinet.com" DESCRIPTION "Copyright (C) 2009 The Internet Society. This version of the MIB module is part of RFC xxx; see the RFC itself for full legal notices. This MIB module contains managed object definitions for the CAPWAP Protocol." REVISION "200902280000Z" DESCRIPTION "Initial version published as RFC xxx" ::= { mib-2 xxx } -- Textual Conventions CapwapBaseWtpIdTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "32a" STATUS current DESCRIPTION "Represents an unique identifier of a WTP instance. As usual, a serial number of WTP will be used." SYNTAX OCTET STRING (SIZE (0..32)) CapwapBaseStationIdTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x:" STATUS current DESCRIPTION Shi, et al. Expires September 1, 2009 [Page 18] Internet-Draft CAPWAP Protocol Base MIB February 2009 "Represents an unique identifier of a station instance. As usual, the MAC address of station will be used." SYNTAX OCTET STRING (SIZE (6)) CapwapBaseRadioIdTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Represents an unique identifier of a radio on a WTP." SYNTAX Unsigned32 (1..31) CapwapBaseTunnelModeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the tunneling modes of operation that are supported by the WTP. The WTP MAY support more than one option, represented by the bit field below: localBridging(0) - Local Bridging Mode dot3Tunnel(1) - 802.3 Frame Tunnel Mode nativeTunnel(2) - Native Frame Tunnel Mode" REFERENCE "Section 4.6.43. of CAPWAP Protocol Specification, RFC xxx." SYNTAX BITS { localBridging(0), dot3Tunnel(1), nativeTunnel(2) } CapwapBaseMacTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the MAC mode of operation supported by the WTP. The following enumerated values are supported: localMAC(0) - Local-MAC Mode splitMAC(1) - Split-MAC Mode both(2) - Both Local-MAC and Split-MAC" REFERENCE "Section 4.6.44. of CAPWAP Protocol Specification, RFC xxx." SYNTAX INTEGER { localMAC(0), splitMAC(1), both(2) } CapwapBaseChannelTypeTC::= TEXTUAL-CONVENTION STATUS current DESCRIPTION Shi, et al. Expires September 1, 2009 [Page 19] Internet-Draft CAPWAP Protocol Base MIB February 2009 "Represents the channel type for CAPWAP protocol. The following enumerated values are supported: data(1) - data Channel control(2) - control Channel" SYNTAX INTEGER { data(1), control(2) } CapwapBaseAuthenMethodTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the authentication credential type for WTP. The following enumerated values are supported: other(1) - Other method, for example, vendor specific clear(2) - Clear text and no authentication x509(3) - X.509 Certificate authentication psk(4) - Pre-Shared Secret authentication As mandatory requirement, CAPWAP control channel authentication should use DTLS, and either by certificate or PSK. For data channel, DTLS is optional." SYNTAX INTEGER { other(1), clear(2), x509(3), psk(4) } -- Top level components of this MIB module -- Notifications capwapBaseNotifications OBJECT IDENTIFIER ::= { capwapBaseMIB 0 } -- Tables, Scalars capwapBaseObjects OBJECT IDENTIFIER ::= { capwapBaseMIB 1 } -- Conformance capwapBaseConformance OBJECT IDENTIFIER ::= { capwapBaseMIB 2 } -- AC Objects Group capwapBaseAc OBJECT IDENTIFIER ::= { capwapBaseObjects 1 } capwapBaseWtpSessions OBJECT-TYPE Shi, et al. Expires September 1, 2009 [Page 20] Internet-Draft CAPWAP Protocol Base MIB February 2009 SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the total number of WTPs which are connecting to AC." REFERENCE "Section 4.6.1. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseAc 1 } capwapBaseWtpSessionsLimit OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the maximum number of WTP sessions configured for the AC." REFERENCE "Section 4.6.1. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseAc 2 } capwapBaseStationSessions OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the total number of stations which are accessing the wireless service provided by the AC." REFERENCE "Section 4.6.1. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseAc 3 } capwapBaseStationSessionsLimit OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the maximum number of station sessions configured on the AC. The value of the object is persistent at restart/reboot." REFERENCE "Section 4.6.1. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseAc 4 } capwapBaseDataChannelDTLSPolicyOptions OBJECT-TYPE SYNTAX BITS { other(0), clear(1), Shi, et al. Expires September 1, 2009 [Page 21] Internet-Draft CAPWAP Protocol Base MIB February 2009 dtls(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The AC communicates its policy on the use of DTLS for the CAPWAP data channel. The AC MAY support more than one option, represented by the bit field below: other(0) - Other method, for example, vendor specific clear(1) - Clear Text dtls(2) - DTLS" REFERENCE "Section 4.6.1. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseAc 5 } capwapBaseDataChannelDTLSPolicyConfig OBJECT-TYPE SYNTAX INTEGER { other(0), clear(1), dtls(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the security policy configured on the AC for CAPWAP data channel. The following enumerated values are supported: other(0) - Other method, for example, vendor specific clear(1) - Clear Text dtls(2) - DTLS" REFERENCE "Section 4.6.1. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseAc 6 } capwapBaseControlChannelAuthenOptions OBJECT-TYPE SYNTAX BITS { x509(0), psk(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the authentication credential type supported by the AC for control channel. The AC MAY support more than one option, represented by the bit field below: x509(0) - X.509 Certificate Based Shi, et al. Expires September 1, 2009 [Page 22] Internet-Draft CAPWAP Protocol Base MIB February 2009 psk(1) - Pre-Shared Secret" REFERENCE "Section 4.6.1. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseAc 7 } capwapBaseControlChannelAuthenConfig OBJECT-TYPE SYNTAX INTEGER { x509(1), psk(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the authentication credential type configured for the AC for control channel. The following enumerated values are supported: x509(1) - X.509 Certificate Based psk(2) - Pre-Shared Secret" REFERENCE "Section 4.6.1. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseAc 8 } -- capwapBaseAcNameListTable table capwapBaseAcNameListTable OBJECT-TYPE SYNTAX SEQUENCE OF CapwapBaseAcNameListEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that display AC name list." REFERENCE "Section 4.6.5. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseAc 9 } capwapBaseAcNameListEntry OBJECT-TYPE SYNTAX CapwapBaseAcNameListEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that configure AC name list. Values of all read-create objects in this table are persistent at restart/reboot." INDEX { capwapBaseAcNameListId } ::= { capwapBaseAcNameListTable 1 } CapwapBaseAcNameListEntry ::= SEQUENCE { capwapBaseAcNameListId Unsigned32, capwapBaseAcNameListName OCTET STRING, Shi, et al. Expires September 1, 2009 [Page 23] Internet-Draft CAPWAP Protocol Base MIB February 2009 capwapBaseAcNameListPriority Unsigned32, capwapBaseAcNameListRowStatus RowStatus } capwapBaseAcNameListId OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Represents a unique id for a AC Name list." ::= { capwapBaseAcNameListEntry 1 } capwapBaseAcNameListName OBJECT-TYPE SYNTAX OCTET STRING(SIZE(512)) MAX-ACCESS read-create STATUS current DESCRIPTION "Represents the name of an AC, and it is expected to be an UTF-8 encoded string." REFERENCE "Section 4.6.5. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseAcNameListEntry 2 } capwapBaseAcNameListPriority OBJECT-TYPE SYNTAX Unsigned32 (1..255) MAX-ACCESS read-create STATUS current DESCRIPTION "Represents the priority order of the preferred AC. For instance, the value of one (1) is used to set the primary AC, the value of two (2) is used to set the secondary, etc." REFERENCE "Section 4.6.5. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseAcNameListEntry 3 } capwapBaseAcNameListRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table." ::= { capwapBaseAcNameListEntry 4 } -- End of capwapBaseAcNameListTable table -- capwapBaseMacAclTable table Shi, et al. Expires September 1, 2009 [Page 24] Internet-Draft CAPWAP Protocol Base MIB February 2009 capwapBaseMacAclTable OBJECT-TYPE SYNTAX SEQUENCE OF CapwapBaseMacAclEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that configure station Access Control List (ACL). WTP will not provide service to the MAC addresses configured in this table." REFERENCE "Section 4.6.7. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseAc 10 } capwapBaseMacAclEntry OBJECT-TYPE SYNTAX CapwapBaseMacAclEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that configure station Access Control List (ACL). Values of all read-create objects in this table are persisten at AC restart/reboot." INDEX { capwapBaseMacAclId } ::= { capwapBaseMacAclTable 1 } CapwapBaseMacAclEntry ::= SEQUENCE { capwapBaseMacAclId Unsigned32, capwapBaseMacAclStationId CapwapBaseStationIdTC, capwapBaseMacAclRowStatus RowStatus } capwapBaseMacAclId OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Represents a unique id for a ACL." ::= { capwapBaseMacAclEntry 1 } capwapBaseMacAclStationId OBJECT-TYPE SYNTAX CapwapBaseStationIdTC MAX-ACCESS read-create STATUS current DESCRIPTION "Represents a station's MAC address which WTPs will no longer provides service to it." REFERENCE "Section 4.6.7. of CAPWAP Protocol Specification, RFC xxx." Shi, et al. Expires September 1, 2009 [Page 25] Internet-Draft CAPWAP Protocol Base MIB February 2009 ::= { capwapBaseMacAclEntry 2 } capwapBaseMacAclRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table." ::= { capwapBaseMacAclEntry 3 } -- End of capwapBaseMacAclTable table -- End of AC Objects Group -- WTP Objects Group capwapBaseWtps OBJECT IDENTIFIER ::= { capwapBaseObjects 2 } -- capwapBaseWtpStateTable table capwapBaseWtpStateTable OBJECT-TYPE SYNTAX SEQUENCE OF CapwapBaseWtpStateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that display WTP CAPWAP FSM state." ::= { capwapBaseWtps 1 } capwapBaseWtpStateEntry OBJECT-TYPE SYNTAX CapwapBaseWtpStateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that display WTP CAPWAP FSM state." INDEX { capwapBaseWtpStateWtpId } ::= { capwapBaseWtpStateTable 1 } CapwapBaseWtpStateEntry ::= SEQUENCE { capwapBaseWtpStateWtpId CapwapBaseWtpIdTC, capwapBaseWtpStateWtpIpAddressType InetAddressType, capwapBaseWtpStateWtpIpAddress InetAddress, capwapBaseWtpStateWtpPhyAddress PhysAddress, capwapBaseWtpState INTEGER } Shi, et al. Expires September 1, 2009 [Page 26] Internet-Draft CAPWAP Protocol Base MIB February 2009 capwapBaseWtpStateWtpId OBJECT-TYPE SYNTAX CapwapBaseWtpIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "Represents the unique identifier of a WTP." ::= { capwapBaseWtpStateEntry 1 } capwapBaseWtpStateWtpIpAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the type of IP address of a WTP." ::= { capwapBaseWtpStateEntry 2 } capwapBaseWtpStateWtpIpAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the IP address of a WTP." ::= { capwapBaseWtpStateEntry 3 } capwapBaseWtpStateWtpPhyAddress OBJECT-TYPE SYNTAX PhysAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the PHY address of a WTP." ::= { capwapBaseWtpStateEntry 4 } capwapBaseWtpState OBJECT-TYPE SYNTAX INTEGER { dtls(1), join(2), image(3), configure(4), dataCheck(5), run(6), clear(7), unknown(8) } MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the various possible CAPWAP FSM states of WTP The following enumerated values are supported: Shi, et al. Expires September 1, 2009 [Page 27] Internet-Draft CAPWAP Protocol Base MIB February 2009 dtls(1) - DTLS negotiation states, which include DTLS Setup, Authorize, DTLS Connect join(2) - WTP is joining with AC image(3) - WTP is downloading software configure(4) - WTP is getting configuration from AC dataCheck(5) - AC is waiting for the Data Channel Keep Alive Packet run(6) - WTP comes to run state clear(7) - WTP recoveries default configuration unknown(8) - Operator already prepare configuration for WTP, while WTP has not contact with AC till now" REFERENCE "Section 2.3.1. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWtpStateEntry 5 } -- End of capwapBaseWtpStateTable Table -- capwapBaseWtpTable Table capwapBaseWtpTable OBJECT-TYPE SYNTAX SEQUENCE OF CapwapBaseWtpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that display and control WTPs in running state. Values of all read-write objects in this table are persistent at restart/reboot." ::= { capwapBaseWtps 2 } capwapBaseWtpEntry OBJECT-TYPE SYNTAX CapwapBaseWtpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that display and control a WTP in running state." INDEX { capwapBaseWtpCurrId } ::= { capwapBaseWtpTable 1 } CapwapBaseWtpEntry ::= SEQUENCE { capwapBaseWtpCurrId CapwapBaseWtpIdTC, capwapBaseWtpPhyIndex PhysicalIndex, capwapBaseWtpName OCTET STRING, capwapBaseWtpLocation OCTET STRING, capwapBaseWtpBaseMacAddress PhysAddress, capwapBaseWtpTunnelModeOptions CapwapBaseTunnelModeTC, Shi, et al. Expires September 1, 2009 [Page 28] Internet-Draft CAPWAP Protocol Base MIB February 2009 capwapBaseWtpMacTypeOptions CapwapBaseMacTypeTC, capwapBaseWtpDiscoveryType INTEGER, capwapBaseWtpRadiosInUseNum Unsigned32, capwapBaseWtpRadioNumLimit Unsigned32, capwapBaseWtpStaticIpEnable TruthValue, capwapBaseWtpStaticIpType InetAddressType, capwapBaseWtpStaticIp InetAddress, capwapBaseWtpNetmask InetAddress, capwapBaseWtpGateway InetAddress, capwapBaseWtpFallbackEnable INTEGER, capwapBaseWtpRetransmitCount Counter32, capwapBaseWtpMaxDiscoveries Unsigned32, capwapBaseWtpMaxFailedDTLSSessionRetry Unsigned32, capwapBaseWtpMaxRetransmit Unsigned32, capwapBaseWtpDataChannelKeepAliveTimer Unsigned32, capwapBaseWtpDataChannelDeadInterval Unsigned32, capwapBaseWtpDiscoveryInterval Unsigned32, capwapBaseWtpDTLSSessionDeleteTimer Unsigned32, capwapBaseWtpEchoInterval Unsigned32, capwapBaseWtpIdleTimeout Unsigned32, capwapBaseWtpImageDataStartTimer Unsigned32, capwapBaseWtpMaxDiscoveryInterval Unsigned32, capwapBaseWtpReportInterval Unsigned32, capwapBaseWtpRetransmitInterval Unsigned32, capwapBaseWtpSilentInterval Unsigned32, capwapBaseWtpStatisticsTimer Unsigned32, capwapBaseWtpWaitDTLSTimer Unsigned32, capwapBaseWtpEcnSupport INTEGER } capwapBaseWtpCurrId OBJECT-TYPE SYNTAX CapwapBaseWtpIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "Represents the unique identifier of a WTP which is in running state." ::= { capwapBaseWtpEntry 1 } capwapBaseWtpPhyIndex OBJECT-TYPE SYNTAX PhysicalIndex MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the unique physical index of a physical entity in the ENTITY-MIB module. The information such as software version of specific WTP could be accessed through the index." ::= { capwapBaseWtpEntry 2 } Shi, et al. Expires September 1, 2009 [Page 29] Internet-Draft CAPWAP Protocol Base MIB February 2009 capwapBaseWtpName OBJECT-TYPE SYNTAX OCTET STRING(SIZE(512)) MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the name of a WTP." REFERENCE "Section 4.6.45. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWtpEntry 3 } capwapBaseWtpLocation OBJECT-TYPE SYNTAX OCTET STRING(SIZE(1024)) MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the location of a WTP." REFERENCE "Section 4.6.30. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWtpEntry 4 } capwapBaseWtpBaseMacAddress OBJECT-TYPE SYNTAX PhysAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the WTP's Base MAC Address, which MAY be assigned to the primary Ethernet interface." REFERENCE "Section 4.6.40. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWtpEntry 5 } capwapBaseWtpTunnelModeOptions OBJECT-TYPE SYNTAX CapwapBaseTunnelModeTC MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the tunneling modes of operation supported by the WTP." REFERENCE "Section 4.6.43. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWtpEntry 6 } capwapBaseWtpMacTypeOptions OBJECT-TYPE SYNTAX CapwapBaseMacTypeTC MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the MAC mode of operation supported by the WTP." Shi, et al. Expires September 1, 2009 [Page 30] Internet-Draft CAPWAP Protocol Base MIB February 2009 REFERENCE "Section 4.6.44. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWtpEntry 7 } capwapBaseWtpDiscoveryType OBJECT-TYPE SYNTAX INTEGER { unknown(0), staticConfig(1), dhcp(2), dns(3), acRef(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Represents how WTP discovers the AC. The following enumerated values are supported: unknown(0) - Unknown staticConfig(1) - Static Configuration dhcp(2) - DHCP dns(3) - DNS acRef(4) - AC Referral" REFERENCE "Section 4.6.21. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWtpEntry 8 } capwapBaseWtpRadiosInUseNum OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of radios in use on the WTP." REFERENCE "Section 4.6.41. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWtpEntry 9 } capwapBaseWtpRadioNumLimit OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the maximum radio number supported by the WTP." REFERENCE "Section 4.6.41. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWtpEntry 10 } capwapBaseWtpStaticIpEnable OBJECT-TYPE SYNTAX TruthValue Shi, et al. Expires September 1, 2009 [Page 31] Internet-Draft CAPWAP Protocol Base MIB February 2009 MAX-ACCESS read-write STATUS current DESCRIPTION "Represents whether the WTP should use a static IP address or not. A value of false disables the static IP address, while a value of true enables it." REFERENCE "Section 4.6.48. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWtpEntry 11 } capwapBaseWtpStaticIpType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-write STATUS current DESCRIPTION "Represents whether WTP uses IPv4 or IPv6 static IP address." ::= { capwapBaseWtpEntry 12 } capwapBaseWtpStaticIp OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION "When capwapBaseWtpStaticIpEnable is true, it represents the static IP address to assign to the WTP." REFERENCE "Section 4.6.48. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWtpEntry 13 } capwapBaseWtpNetmask OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION "When capwapBaseWtpStaticIpEnable is true, it represents the netmask to assign to the WTP." REFERENCE "Section 4.6.48. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWtpEntry 14 } capwapBaseWtpGateway OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION "When capwapBaseWtpStaticIpEnable is true, it represents the gateway to assign to the WTP." REFERENCE Shi, et al. Expires September 1, 2009 [Page 32] Internet-Draft CAPWAP Protocol Base MIB February 2009 "Section 4.6.48. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWtpEntry 15 } capwapBaseWtpFallbackEnable OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Represents whether to enable or disable automatic CAPWAP fallback in the event that a WTP detects its preferred AC, and is not currently connected to it. The following enumerated values are supported: enabled(1) - The fallback mode is enabled disabled(2) - The fallback mode is disabled" REFERENCE "Section 4.6.42. of CAPWAP Protocol Specification, RFC xxx." DEFVAL { enabled } ::= { capwapBaseWtpEntry 16 } capwapBaseWtpRetransmitCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of retransmissions for a given CAPWAP packet." REFERENCE "Section 4.8.8. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWtpEntry 17 } capwapBaseWtpMaxDiscoveries OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represent the maximum number of Discovery Request messages that will be sent after a WTP boots." REFERENCE "Section 4.8.5. of CAPWAP Protocol Specification, RFC xxx." DEFVAL { 10 } ::= { capwapBaseWtpEntry 18 } capwapBaseWtpMaxFailedDTLSSessionRetry OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only Shi, et al. Expires September 1, 2009 [Page 33] Internet-Draft CAPWAP Protocol Base MIB February 2009 STATUS current DESCRIPTION "Represent the maximum number of failed DTLS session establishment attempts before the CAPWAP device enters a silent period." REFERENCE "Section 4.8.6. of CAPWAP Protocol Specification, RFC xxx." DEFVAL { 3 } ::= { capwapBaseWtpEntry 19 } capwapBaseWtpMaxRetransmit OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represent the maximum number of retransmission for a given CAPWAP packet before the link layer considers the peer dead." REFERENCE "Section 4.8.7. of CAPWAP Protocol Specification, RFC xxx." DEFVAL { 5 } ::= { capwapBaseWtpEntry 20 } capwapBaseWtpDataChannelKeepAliveTimer OBJECT-TYPE SYNTAX Unsigned32 UNITS "second" MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the next opportunity, in seconds, the WTP must transmit the Data Channel Keep Alive message." REFERENCE "Section 4.7.2. of CAPWAP Protocol Specification, RFC xxx." DEFVAL { 30 } ::= { capwapBaseWtpEntry 21 } capwapBaseWtpDataChannelDeadInterval OBJECT-TYPE SYNTAX Unsigned32 (0..240) UNITS "second" MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the minimum time, in seconds, a WTP MUST wait without having received a Data Channel Keep Alive packet before the destination for the Data Channel Keep Alive packets may be considered dead." REFERENCE "Section 4.7.3. of CAPWAP Protocol Specification, RFC xxx." DEFVAL { 60 } Shi, et al. Expires September 1, 2009 [Page 34] Internet-Draft CAPWAP Protocol Base MIB February 2009 ::= { capwapBaseWtpEntry 22 } capwapBaseWtpDiscoveryInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "second" MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the minimum time, in seconds, that a WTP MUST wait after receiving a Discovery Response message, before initiating a DTLS handshake." REFERENCE "Section 4.7.5. of CAPWAP Protocol Specification, RFC xxx." DEFVAL { 5 } ::= { capwapBaseWtpEntry 23 } capwapBaseWtpDTLSSessionDeleteTimer OBJECT-TYPE SYNTAX Unsigned32 UNITS "second" MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the minimum time, in seconds, a WTP MUST wait for DTLS session deletion." REFERENCE "Section 4.7.6. of CAPWAP Protocol Specification, RFC xxx." DEFVAL { 5 } ::= { capwapBaseWtpEntry 24 } capwapBaseWtpEchoInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "second" MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the minimum time, in seconds, between sending Echo Request messages to the AC with which the WTP has joined." REFERENCE "Section 4.7.7. of CAPWAP Protocol Specification, RFC xxx." DEFVAL { 30 } ::= { capwapBaseWtpEntry 25 } capwapBaseWtpIdleTimeout OBJECT-TYPE SYNTAX Unsigned32 UNITS "second" MAX-ACCESS read-write STATUS current DESCRIPTION Shi, et al. Expires September 1, 2009 [Page 35] Internet-Draft CAPWAP Protocol Base MIB February 2009 "Represents the idle timeout value that the WTP SHOULD enforce for its active stations." REFERENCE "Section 4.7.8. of CAPWAP Protocol Specification, RFC xxx." DEFVAL { 300 } ::= { capwapBaseWtpEntry 26 } capwapBaseWtpImageDataStartTimer OBJECT-TYPE SYNTAX Unsigned32 UNITS "second" MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of seconds the WTP will wait for its peer to transmit the Image Data Request." REFERENCE "Section 4.7.9. of CAPWAP Protocol Specification, RFC xxx." DEFVAL { 30 } ::= { capwapBaseWtpEntry 27 } capwapBaseWtpMaxDiscoveryInterval OBJECT-TYPE SYNTAX Unsigned32 (2..180) UNITS "second" MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the maximum time allowed between sending Discovery Request messages, in seconds. This value MUST be no less than 2 seconds and no greater than 180 seconds." REFERENCE "Section 4.7.10. of CAPWAP Protocol Specification, RFC xxx." DEFVAL { 20 } ::= { capwapBaseWtpEntry 28 } capwapBaseWtpReportInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "second" MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the interval for WTP to send Decryption Error report." REFERENCE "Section 4.7.11. of CAPWAP Protocol Specification, RFC xxx." DEFVAL { 120 } ::= { capwapBaseWtpEntry 29 } capwapBaseWtpRetransmitInterval OBJECT-TYPE Shi, et al. Expires September 1, 2009 [Page 36] Internet-Draft CAPWAP Protocol Base MIB February 2009 SYNTAX Unsigned32 UNITS "second" MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the minimum time, in seconds, in which a non-acknowledged CAPWAP packet will be retransmitted." REFERENCE "Section 4.7.12. of CAPWAP Protocol Specification, RFC xxx." DEFVAL { 3 } ::= { capwapBaseWtpEntry 30 } capwapBaseWtpSilentInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "second" MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the minimum time, in seconds, a WTP MUST wait before it MAY again send Discovery Request messages or attempt to a establish DTLS session." REFERENCE "Section 4.7.13. of CAPWAP Protocol Specification, RFC xxx." DEFVAL { 30 } ::= { capwapBaseWtpEntry 31 } capwapBaseWtpStatisticsTimer OBJECT-TYPE SYNTAX Unsigned32 UNITS "second" MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the interval the WTP uses between the WTP Events Requests it transmits to the AC to communicate its statistics, in seconds." REFERENCE "Section 4.7.14. of CAPWAP Protocol Specification, RFC xxx." DEFVAL { 120 } ::= { capwapBaseWtpEntry 32 } capwapBaseWtpWaitDTLSTimer OBJECT-TYPE SYNTAX Unsigned32 (30..4294967295) UNITS "second" MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the maximum time, in seconds, an AC MUST wait without having received a DTLS Handshake message from an AC. Shi, et al. Expires September 1, 2009 [Page 37] Internet-Draft CAPWAP Protocol Base MIB February 2009 This timer MUST be greater than 30 seconds." REFERENCE "Section 4.7.15. of CAPWAP Protocol Specification, RFC xxx." DEFVAL { 60 } ::= { capwapBaseWtpEntry 33 } capwapBaseWtpEcnSupport OBJECT-TYPE SYNTAX INTEGER { limited(0), fullAndLimited(1) } MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the support for the Explicit Congestion Notification (ECN) bits, as defined in [RFC3168]." REFERENCE "Section 4.7.25. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWtpEntry 34 } -- End of capwapBaseWtpTable table -- capwapBaseWirelessBindingTable Table capwapBaseWirelessBindingTable OBJECT-TYPE SYNTAX SEQUENCE OF CapwapBaseWirelessBindingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that display the mapping relationship between specific interface of 'WTP Virtual Radio Interface' ifType and PHY radio, and wireless binding type for a specific radio. The mapping relationship in this table is persistent at restart/reboot." ::= { capwapBaseWtps 3 } capwapBaseWirelessBindingEntry OBJECT-TYPE SYNTAX CapwapBaseWirelessBindingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that display the mapping relationship between 'WTP Virtual Radio Interface' and PHY radio, and wireless binding type for a specific radio." INDEX { capwapBaseWtpStateWtpId, capwapBaseWirelessBindingRadioId Shi, et al. Expires September 1, 2009 [Page 38] Internet-Draft CAPWAP Protocol Base MIB February 2009 } ::= { capwapBaseWirelessBindingTable 1 } CapwapBaseWirelessBindingEntry ::= SEQUENCE { capwapBaseWirelessBindingRadioId CapwapBaseRadioIdTC, capwapBaseWirelessBindingVirtualRadioIfIndex InterfaceIndex, capwapBaseWirelessBindingType INTEGER } capwapBaseWirelessBindingRadioId OBJECT-TYPE SYNTAX CapwapBaseRadioIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "Represents the identifier of a PHY radio on a WTP, and only requires unique on a WTP. For example, WTP A and WTP B will use same value of capwapBaseWirelessBindingRadioId for their first radio." REFERENCE "Section 4.3. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWirelessBindingEntry 1 } capwapBaseWirelessBindingVirtualRadioIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the index value that uniquely identifies a 'WLAN Virtual Radio Interface'. The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex. Before WTPs connect to AC and get configuration, operator will prepare configuration for them. On the AC, there are interfaces of 'WTP Virtual Radio Interface' ifType which represent PHY radio interfaces on the WTP. As most MIB modules use ifIndex to identify an interface for configuration and statistic data, for example, IEEE 802.11 MIB module. It will be very easy to reuse other wireless binding MIB modules through 'WTP Virtual Radio Interface'." ::= { capwapBaseWirelessBindingEntry 2 } capwapBaseWirelessBindingType OBJECT-TYPE SYNTAX INTEGER { dot11(1), epc(3) } MAX-ACCESS read-only STATUS current Shi, et al. Expires September 1, 2009 [Page 39] Internet-Draft CAPWAP Protocol Base MIB February 2009 DESCRIPTION "Represents the wireless binding type for radio. The following enumerated values are supported: dot11(1) - IEEE 802.11 epc(3) - EPCGlobal" REFERENCE "Section 4.3. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWirelessBindingEntry 3 } -- End of capwapBaseWirelessBindingTable Table -- capwapBaseStationTable Table capwapBaseStationTable OBJECT-TYPE SYNTAX SEQUENCE OF CapwapBaseStationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that display stations which are accessing the wireless service provided by the AC." REFERENCE "Section 4.6.8. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWtps 4 } capwapBaseStationEntry OBJECT-TYPE SYNTAX CapwapBaseStationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that display a station which is associated with the specific radio on the WTP." INDEX { capwapBaseWtpCurrId, capwapBaseWirelessBindingRadioId, capwapBaseStationId } ::= { capwapBaseStationTable 1 } CapwapBaseStationEntry ::= SEQUENCE { capwapBaseStationId CapwapBaseStationIdTC, capwapBaseStationAddedTime DateAndTime, capwapBaseStationVlanName SnmpAdminString } capwapBaseStationId OBJECT-TYPE SYNTAX CapwapBaseStationIdTC MAX-ACCESS not-accessible Shi, et al. Expires September 1, 2009 [Page 40] Internet-Draft CAPWAP Protocol Base MIB February 2009 STATUS current DESCRIPTION "Represents the unique identifier of the station." REFERENCE "Section 4.6.8. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseStationEntry 1 } capwapBaseStationAddedTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the time when the station is added." REFERENCE "Section 4.6.8. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseStationEntry 2 } capwapBaseStationVlanName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "Represents VLAN name to which the station is associated." REFERENCE "Section 4.6.8. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseStationEntry 3 } -- End of capwapBaseStationTable Table -- capwapBaseWtpEventsStatsTable capwapBaseWtpEventsStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF CapwapBaseWtpEventsStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that display WTPs' events statistics." REFERENCE "Section 4.6.47. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWtps 5 } capwapBaseWtpEventsStatsEntry OBJECT-TYPE SYNTAX CapwapBaseWtpEventsStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that display the events statistic data Shi, et al. Expires September 1, 2009 [Page 41] Internet-Draft CAPWAP Protocol Base MIB February 2009 of a WTP." REFERENCE "Section 4.6.47. of CAPWAP Protocol Specification, RFC xxx." INDEX { capwapBaseWtpCurrId } ::= { capwapBaseWtpEventsStatsTable 1 } CapwapBaseWtpEventsStatsEntry ::= SEQUENCE { capwapBaseWtpEventsStatsRebootCount Counter32, capwapBaseWtpEventsStatsInitCount Counter32, capwapBaseWtpEventsStatsLinkFailureCount Counter32, capwapBaseWtpEventsStatsSwFailureCount Counter32, capwapBaseWtpEventsStatsHwFailureCount Counter32, capwapBaseWtpEventsStatsOtherFailureCount Counter32, capwapBaseWtpEventsStatsUnknownFailureCount Counter32, capwapBaseWtpEventsStatsLastFailureType INTEGER } capwapBaseWtpEventsStatsRebootCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of reboots that have occurred due to a WTP crash. A value of 65535 implies that this information is not available on the WTP." REFERENCE "Section 4.6.47. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWtpEventsStatsEntry 1 } capwapBaseWtpEventsStatsInitCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of reboots that have occurred at the request of a CAPWAP protocol message, such as a change in configuration that required a reboot or an explicit CAPWAP protocol reset request. A value of 65535 implies that this information is not available on the WTP." REFERENCE "Section 4.6.47. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWtpEventsStatsEntry 2 } capwapBaseWtpEventsStatsLinkFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Shi, et al. Expires September 1, 2009 [Page 42] Internet-Draft CAPWAP Protocol Base MIB February 2009 "Represents the number of times that a CAPWAP protocol connection with an AC has failed due to link failure." REFERENCE "Section 4.6.47. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWtpEventsStatsEntry 3 } capwapBaseWtpEventsStatsSwFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that a CAPWAP protocol connection with an AC has failed due to software related reasons." REFERENCE "Section 4.6.47. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWtpEventsStatsEntry 4 } capwapBaseWtpEventsStatsHwFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that a CAPWAP protocol connection with an AC has failed due to hardware related reasons." REFERENCE "Section 4.6.47. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWtpEventsStatsEntry 5 } capwapBaseWtpEventsStatsOtherFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that a CAPWAP protocol connection with an AC has failed due to known reasons, other than AC initiated, link, software or hardware failure." REFERENCE "Section 4.6.47. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWtpEventsStatsEntry 6 } capwapBaseWtpEventsStatsUnknownFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that a CAPWAP protocol Shi, et al. Expires September 1, 2009 [Page 43] Internet-Draft CAPWAP Protocol Base MIB February 2009 connection with an AC has failed for unknown reasons." REFERENCE "Section 4.6.47. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWtpEventsStatsEntry 7 } capwapBaseWtpEventsStatsLastFailureType OBJECT-TYPE SYNTAX INTEGER { notSupport(0), acInit(1), linkFailure(2), swFailure(3), hwFailure(4), otherFailure(5), unknown(255) } MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the failure type of the most recent WTP failure. The following enumerated values are supported: notSupport(0) - Not Supported acInit(1) - AC Initiated linkFailure(2) - Link Failure swFailure(3) - Software Failure hwFailure(4) - Hardware Failure otherFailure(5) - Other Failure unknown(255) - Unknown (e.g., WTP doesn't keep track of info)" REFERENCE "Section 4.6.47. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWtpEventsStatsEntry 8 } -- End of capwapBaseWtpEventsStatsTable table -- capwapBaseRadioEventsStatsTable table capwapBaseRadioEventsStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF CapwapBaseRadioEventsStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that display statistics on radios behavior, and reasons why the WTP radio has been reset." REFERENCE "Section 4.6.46. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseWtps 6 } Shi, et al. Expires September 1, 2009 [Page 44] Internet-Draft CAPWAP Protocol Base MIB February 2009 capwapBaseRadioEventsStatsEntry OBJECT-TYPE SYNTAX CapwapBaseRadioEventsStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that display the statistic data of events happened on a specific radio of a WTP." INDEX { capwapBaseWtpCurrId, capwapBaseWirelessBindingRadioId } ::= { capwapBaseRadioEventsStatsTable 1 } CapwapBaseRadioEventsStatsEntry ::= SEQUENCE { capwapBaseRadioEventsStatsResetCount Counter32, capwapBaseRadioEventsStatsSwFailCount Counter32, capwapBaseRadioEventsStatsHwFailCount Counter32, capwapBaseRadioEventsStatsOtherFailCount Counter32, capwapBaseRadioEventsStatsUnknownFailCount Counter32, capwapBaseRadioEventsStatsConfigUpdateCount Counter32, capwapBaseRadioEventsStatsChannelChangeCount Counter32, capwapBaseRadioEventsStatsBandChangeCount Counter32, capwapBaseRadioEventsStatsCurrentNoiseFloor Integer32, capwapBaseRadioEventsStatsDecryptErrorCount Counter32, capwapBaseRadioEventsStatsLastFailType INTEGER } capwapBaseRadioEventsStatsResetCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that that the radio has been reset." REFERENCE "Section 4.6.46. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseRadioEventsStatsEntry 1 } capwapBaseRadioEventsStatsSwFailCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that the radio has failed due to software related reasons." REFERENCE "Section 4.6.46. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseRadioEventsStatsEntry 2 } capwapBaseRadioEventsStatsHwFailCount OBJECT-TYPE SYNTAX Counter32 Shi, et al. Expires September 1, 2009 [Page 45] Internet-Draft CAPWAP Protocol Base MIB February 2009 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that the radio has failed due to hardware related reasons." REFERENCE "Section 4.6.46. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseRadioEventsStatsEntry 3 } capwapBaseRadioEventsStatsOtherFailCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that the radio has failed due to known reasons, other than software or hardware failure." REFERENCE "Section 4.6.46. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseRadioEventsStatsEntry 4 } capwapBaseRadioEventsStatsUnknownFailCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that the radio has failed for unknown reasons." REFERENCE "Section 4.6.46. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseRadioEventsStatsEntry 5 } capwapBaseRadioEventsStatsConfigUpdateCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that the radio configuration has been updated." REFERENCE "Section 4.6.46. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseRadioEventsStatsEntry 6 } capwapBaseRadioEventsStatsChannelChangeCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that the radio channel has Shi, et al. Expires September 1, 2009 [Page 46] Internet-Draft CAPWAP Protocol Base MIB February 2009 been changed." REFERENCE "Section 4.6.46. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseRadioEventsStatsEntry 7 } capwapBaseRadioEventsStatsBandChangeCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that the radio has changed frequency bands." REFERENCE "Section 4.6.46. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseRadioEventsStatsEntry 8 } capwapBaseRadioEventsStatsCurrentNoiseFloor OBJECT-TYPE SYNTAX Integer32 UNITS "dBm" MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the noise floor of the radio receiver in units of dBm." REFERENCE "Section 4.6.46. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseRadioEventsStatsEntry 9 } capwapBaseRadioEventsStatsDecryptErrorCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of decryption errors that occurred on the WTP. Note that this field is only valid in cases where the WTP provides encryption/decryption services." REFERENCE "Section 4.6.46. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseRadioEventsStatsEntry 10 } capwapBaseRadioEventsStatsLastFailType OBJECT-TYPE SYNTAX INTEGER { notSupport(0), swFailure(1), hwFailure(2), otherFailure(3), unknown(255) } Shi, et al. Expires September 1, 2009 [Page 47] Internet-Draft CAPWAP Protocol Base MIB February 2009 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the failure type of the most recent radio failure. The following enumerated values are supported: notSupport(0) - Not Supported swFailure(1) - Software Failure hwFailure(2) - Hardware Failure otherFailure(3) - Other Failure unknown(255) - Unknown" REFERENCE "Section 4.6.46. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseRadioEventsStatsEntry 11 } -- End of capwapBaseRadioEventsStatsTable table -- End of WTP Objects Group -- CAPWAP Base Parameters Group capwapBaseParameters OBJECT IDENTIFIER ::= { capwapBaseObjects 3 } capwapBaseAcMaxRetransmit OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "Represent the maximum number of retransmission for a given CAPWAP packet before the link layer considers the peer dead. The value of the object is persistent at restart/reboot." REFERENCE "Section 4.8.7. of CAPWAP Protocol Specification, RFC xxx." DEFVAL { 5 } ::= { capwapBaseParameters 1 } capwapBaseAcChangeStatePendingTimer OBJECT-TYPE SYNTAX Unsigned32 UNITS "second" MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the maximum time, in seconds, the AC will wait for the Change State Event Request from the WTP after having transmitted a successful Configuration Status Response message. The value of the object is persistent at restart/reboot." REFERENCE Shi, et al. Expires September 1, 2009 [Page 48] Internet-Draft CAPWAP Protocol Base MIB February 2009 "Section 4.7.1. of CAPWAP Protocol Specification, RFC xxx." DEFVAL { 25 } ::= { capwapBaseParameters 2 } capwapBaseAcDataCheckTimer OBJECT-TYPE SYNTAX Unsigned32 UNITS "second" MAX-ACCESS read-write STATUS current DESCRIPTION "Represents The number of seconds the AC will wait for the Data Channel Keep Alive, which is required by the CAPWAP state machine's Data Check state. The AC resets the state machine if this timer expires prior to transitioning to the next state. The value of the object is persistent at restart/reboot." REFERENCE "Section 4.7.4. of CAPWAP Protocol Specification, RFC xxx." DEFVAL { 30 } ::= { capwapBaseParameters 3 } capwapBaseAcDTLSSessionDeleteTimer OBJECT-TYPE SYNTAX Unsigned32 UNITS "second" MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the minimum time, in seconds, an AC MUST wait for DTLS session deletion. The value of the object is persistent at restart/reboot." REFERENCE "Section 4.7.6. of CAPWAP Protocol Specification, RFC xxx." DEFVAL { 5 } ::= { capwapBaseParameters 4 } capwapBaseAcEchoInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "second" MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the minimum time, in seconds, between sending Echo Request messages to the AC with which the WTP has joined. The value of the object is persistent at restart/reboot." REFERENCE "Section 4.7.7. of CAPWAP Protocol Specification, RFC xxx." DEFVAL { 30 } ::= { capwapBaseParameters 5 } Shi, et al. Expires September 1, 2009 [Page 49] Internet-Draft CAPWAP Protocol Base MIB February 2009 capwapBaseAcRetransmitInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "second" MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the minimum time, in seconds, in which a non-acknowledged CAPWAP packet will be retransmitted. The value of the object is persistent at restart/reboot." REFERENCE "Section 4.7.12. of CAPWAP Protocol Specification, RFC xxx." DEFVAL { 3 } ::= { capwapBaseParameters 6 } capwapBaseAcSilentInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "second" MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the minimum time, in seconds, during which the AC SHOULD ignore all CAPWAP and DTLS packets received from the WTP that is in the Sulking state. The value of the object is persistent at restart/reboot." REFERENCE "Section 4.7.13. of CAPWAP Protocol Specification, RFC xxx." DEFVAL { 30 } ::= { capwapBaseParameters 7 } capwapBaseAcWaitDTLSTimer OBJECT-TYPE SYNTAX Unsigned32 (30..4294967295) UNITS "second" MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the maximum time, in seconds, an AC MUST wait without having received a DTLS Handshake message from an AC. This timer MUST be greater than 30 seconds. The value of the object is persistent at restart/reboot." REFERENCE "Section 4.7.15. of CAPWAP Protocol Specification, RFC xxx." DEFVAL { 60 } ::= { capwapBaseParameters 8 } capwapBaseAcWaitJoinTimer OBJECT-TYPE SYNTAX Unsigned32 (20..4294967295) UNITS "second" MAX-ACCESS read-write Shi, et al. Expires September 1, 2009 [Page 50] Internet-Draft CAPWAP Protocol Base MIB February 2009 STATUS current DESCRIPTION "Represents the maximum time, in seconds, an AC will wait after the DTLS session has been established until it receives the Join Request from the WTP. This timer MUST be greater than 20 seconds. The value of the object is persistent at restart/reboot." REFERENCE "Section 4.7.16. of CAPWAP Protocol Specification, RFC xxx." DEFVAL { 60 } ::= { capwapBaseParameters 9 } capwapBaseAcEcnSupport OBJECT-TYPE SYNTAX INTEGER { limited(0), fullAndLimited(1) } MAX-ACCESS read-write STATUS current DESCRIPTION "Represents the support for the Explicit Congestion Notification (ECN) bits, as defined in [RFC3168]. The value of the object is persistent at restart/reboot." REFERENCE "Section 4.7.25. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseParameters 10 } -- End of CAPWAP Base Parameters Group -- CAPWAP Statistics Group capwapBaseStats OBJECT IDENTIFIER ::= { capwapBaseObjects 4 } capwapBaseFailedDTLSAuthFailCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of failed DTLS session establishment attempts due to authentication failures." REFERENCE "Section 4.8.3. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseStats 1 } capwapBaseFailedDTLSSessionCount OBJECT-TYPE SYNTAX Counter32 Shi, et al. Expires September 1, 2009 [Page 51] Internet-Draft CAPWAP Protocol Base MIB February 2009 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of failed DTLS session establishment attempts." REFERENCE "Section 4.8.4. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseStats 2 } -- Notifications capwapBaseChannelUp NOTIFICATION-TYPE OBJECTS { capwapBaseNtfWtpId, capwapBaseNtfChannelType, capwapBaseNtfAuthenMethod } STATUS current DESCRIPTION "This notification is sent by AC when a CAPWAP channel established. The notification is separated for data or control channel." ::= { capwapBaseNotifications 1 } capwapBaseChannelDown NOTIFICATION-TYPE OBJECTS { capwapBaseNtfWtpId, capwapBaseNtfChannelType, capwapBaseNtfChannelDownReason } STATUS current DESCRIPTION "This notification is sent by AC when CAPWAP channel becomes down. The notification is separated for data or control channel." ::= { capwapBaseNotifications 2 } capwapBaseDecryptErrorReport NOTIFICATION-TYPE OBJECTS { capwapBaseNtfWtpId, capwapBaseNtfRadioId, capwapBaseNtfStationIdList } STATUS current DESCRIPTION "This notification is generated when a WTP that has occurred decryption error since the last report." REFERENCE Shi, et al. Expires September 1, 2009 [Page 52] Internet-Draft CAPWAP Protocol Base MIB February 2009 "Section 4.6.17. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseNotifications 3 } capwapBaseJoinFailure NOTIFICATION-TYPE OBJECTS { capwapBaseNtfWtpId, capwapBaseNtfJoinFailureReason } STATUS current DESCRIPTION "This notification is generated when a WTP fails to join." REFERENCE "Section 4.6.35. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseNotifications 4 } capwapBaseImageUpgradeFailure NOTIFICATION-TYPE OBJECTS { capwapBaseNtfWtpId, capwapBaseNtfImageFailureReason } STATUS current DESCRIPTION "This notification is generated when a WTP fails to update firmware image." REFERENCE "Section 4.6.35. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseNotifications 5 } capwapBaseConfigMsgError NOTIFICATION-TYPE OBJECTS { capwapBaseNtfWtpId, capwapBaseNtfConfigMsgErrorType, capwapBaseNtfMsgErrorElements } STATUS current DESCRIPTION "This notification is generated when a WTP received message elements in the configuration management messages which it was unable to apply locally." REFERENCE "Section 4.6.35. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseNotifications 6 } capwapBaseRadioOperableStatus NOTIFICATION-TYPE OBJECTS { capwapBaseNtfWtpId, capwapBaseNtfRadioId, capwapBaseNtfRadioOperStatusFlag, Shi, et al. Expires September 1, 2009 [Page 53] Internet-Draft CAPWAP Protocol Base MIB February 2009 capwapBaseNtfRadioStatusCause } STATUS current DESCRIPTION "The notification is generated when a radio's operational state is changed." REFERENCE "Section 4.6.34. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseNotifications 7 } capwapBaseAuthenticationFailure NOTIFICATION-TYPE OBJECTS { capwapBaseNtfWtpId, capwapBaseNtfChannelType, capwapBaseNtfAuthenMethod, capwapBaseNtfAuthenFailureReason } STATUS current DESCRIPTION "The notification will notify the authentication failure event, and provides the reason for it." ::= { capwapBaseNotifications 8 } -- Objects used only in notifications -- for notifications capwapBaseNotifyVarObjects OBJECT IDENTIFIER ::= { capwapBaseObjects 5 } capwapBaseNtfWtpId OBJECT-TYPE SYNTAX CapwapBaseWtpIdTC MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the unique identifier of a WTP." ::= { capwapBaseNotifyVarObjects 1 } capwapBaseNtfRadioId OBJECT-TYPE SYNTAX CapwapBaseRadioIdTC MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the identifier of a PHY radio on a WTP, and only requires unique on a WTP. For example, WTP A and WTP B will use same value of capwapBaseNtfRadioId for their first radio." REFERENCE Shi, et al. Expires September 1, 2009 [Page 54] Internet-Draft CAPWAP Protocol Base MIB February 2009 "Section 4.3. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseNotifyVarObjects 2 } capwapBaseNtfChannelType OBJECT-TYPE SYNTAX CapwapBaseChannelTypeTC MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the channel type for CAPWAP protocol." ::= { capwapBaseNotifyVarObjects 3 } capwapBaseNtfAuthenMethod OBJECT-TYPE SYNTAX CapwapBaseAuthenMethodTC MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents authentication method for Channel." ::= { capwapBaseNotifyVarObjects 4 } capwapBaseNtfChannelDownReason OBJECT-TYPE SYNTAX INTEGER { timeout(1), rekeyfailure(2), acRebootWtp(3), dtlsError(4), maxRetransmit(5) } MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the reason for Channel down. The following enumerated values are supported: timeout(1) - The keep alive is timeout rekeyfailure(2) - Rekey process is failed, channel will be broken acRebootWtp(3) - AC reboot WTP dtlsError(4) - DTLS notifications: DTLSAborted, DTLSReassemblyFailure, DTLSPeerDisconnect, or frequent DTLSDecapFailure maxRetransmit(5) - The underlying reliable transport's RetransmitCount counter has reached the MaxRetransmit variable" ::= { capwapBaseNotifyVarObjects 5 } capwapBaseNtfStationIdList OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS accessible-for-notify STATUS current Shi, et al. Expires September 1, 2009 [Page 55] Internet-Draft CAPWAP Protocol Base MIB February 2009 DESCRIPTION "Represents the list of station id which use semicolons to separate each station id." REFERENCE "Section 4.6.8. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseNotifyVarObjects 6 } capwapBaseNtfAuthenFailureReason OBJECT-TYPE SYNTAX INTEGER { keyMismatch(1), invalidCA(2), micError(3), timeout(4), unknown(8) } MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents reason for WTP authorization failure. The following enumerated values are supported: keyMismatch(1) - WTP's and AC's key is not matched invalidCA(2) - ca is not valid micError(3) - detect MIC error timeout(4) - WaitDTLS Timer is timeout unknown(8) - Unknown reason" REFERENCE "Section 2.3.1. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseNotifyVarObjects 7 } capwapBaseNtfRadioOperStatusFlag OBJECT-TYPE SYNTAX INTEGER { operable(0), inoperable(1) } MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the operation status of a radio. The following enumerated values are supported: operable(0) - To indicate radio is operable inoperable(1) - To indicate radio is inoperable, and capwapBaseNtfRadioStatusCause object will give reason in details" REFERENCE "Section 4.6.34. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseNotifyVarObjects 8 } capwapBaseNtfRadioStatusCause OBJECT-TYPE Shi, et al. Expires September 1, 2009 [Page 56] Internet-Draft CAPWAP Protocol Base MIB February 2009 SYNTAX INTEGER { normal(0), hwError(1), swError(2), adminSet(3) } MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the reason the radio is out of service. The following enumerated values are supported: normal(0) - Normal Status hwError(1) - Radio Failure swError(2) - Software Failure adminSet(3) - Administratively Set" REFERENCE "Section 4.6.34. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseNotifyVarObjects 9 } capwapBaseNtfJoinFailureReason OBJECT-TYPE SYNTAX INTEGER { unspecified(1), resDepletion(2), unknownSource(3), incorrectData(4), sessionIdInUse(5), notSupportHw(6), notSupportBinding(7) } MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the reason of join failure. The following enumerated values are supported: unspecified(1) - unspecified failure reason resDepletion(2) - Resource Depletion unknownSource(3) - Unknown Source incorrectData(4) - Incorrect Data sessionIdInUse(5) - Session ID already in use notSupportHw(6) - WTP Hardware not supported notSupportBinding(7) - Binding Not Supported" REFERENCE "Section 4.6.35. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseNotifyVarObjects 10 } capwapBaseNtfImageFailureReason OBJECT-TYPE SYNTAX INTEGER { invalidChecksum(1), Shi, et al. Expires September 1, 2009 [Page 57] Internet-Draft CAPWAP Protocol Base MIB February 2009 invalidLength(2), other(3), inStorage(4) } MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the reason of image failure. The following enumerated values are supported: invalidChecksum(1) - Invalid Checksum invalidLength(2) - Invalid Data Length other(3) - Other Error inStorage(4) - Image Already Present" REFERENCE "Section 4.6.35. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseNotifyVarObjects 11 } capwapBaseNtfConfigMsgErrorType OBJECT-TYPE SYNTAX INTEGER { unknownElement(1), unsupportedElement(2), unknownValue(3), unsupportedValue(4) } MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the type of configuration message error. The following enumerated values are supported: unknownElement(1) - Unknown Message Element unsupportedElement(2) - Unsupported Message Element unknownValue(3) - Unknown Message Element Value unsupportedValue(4) - Unsupported Message Element Value" REFERENCE "Section 4.6.36. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseNotifyVarObjects 12 } capwapBaseNtfMsgErrorElements OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the message elements sent by the AC in the Configuration Status Response message that caused the error." REFERENCE "Section 4.6.36. of CAPWAP Protocol Specification, RFC xxx." ::= { capwapBaseNotifyVarObjects 13 } Shi, et al. Expires September 1, 2009 [Page 58] Internet-Draft CAPWAP Protocol Base MIB February 2009 -- Module compliance capwapBaseCompliances OBJECT IDENTIFIER ::= { capwapBaseConformance 1 } capwapBaseGroups OBJECT IDENTIFIER ::= { capwapBaseConformance 2 } capwapBaseCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the CAPWAP-BASE-MIB module." MODULE -- this module MANDATORY-GROUPS { capwapBaseAcNodeGroup, capwapBaseWtpStateGroup, capwapBaseWtpsGroup, capwapBaseRadiosGroup, capwapBaseStationsGroup } GROUP capwapBaseAcNodeGroup2 DESCRIPTION "The capwapBaseAcNodeGroup2 group is optional." GROUP capwapBaseAcNameListGroup DESCRIPTION "The capwapBaseAcNameListGroup group is optional." GROUP capwapBaseMacAclsGroup DESCRIPTION "The capwapBaseMacAclsGroup group is optional." GROUP capwapBaseWtpsGroup2 DESCRIPTION "The capwapBaseWtpsGroup2 group is optional." GROUP capwapBaseWtpEventsStatsGroup DESCRIPTION "The capwapBaseWtpEventsStatsGroup group is optional." GROUP capwapBaseRadioEventsStatsGroup DESCRIPTION "The capwapBaseRadioEventsStatsGroup group is optional." GROUP capwapBaseParametersGroup Shi, et al. Expires September 1, 2009 [Page 59] Internet-Draft CAPWAP Protocol Base MIB February 2009 DESCRIPTION "The capwapBaseParametersGroup group is optional." GROUP capwapBaseStatsGroup DESCRIPTION "The capwapBaseStatsGroup group is optional." GROUP capwapBaseNotificationGroup DESCRIPTION "The group capwapBaseNotificationGroup is optional." GROUP capwapBaseNotifyVarGroup DESCRIPTION "The capwapBaseNotifyVarGroup group is optional. If capwapBaseNotificationGroup is supported, this group must be implemented." ::= { capwapBaseCompliances 1 } capwapBaseAcNodeGroup OBJECT-GROUP OBJECTS { capwapBaseWtpSessions, capwapBaseWtpSessionsLimit, capwapBaseStationSessions, capwapBaseStationSessionsLimit } STATUS current DESCRIPTION "The collection of objects which are used to represent basic properties for AC from CAPWAP protocol perspective." ::= { capwapBaseGroups 1 } capwapBaseAcNodeGroup2 OBJECT-GROUP OBJECTS { capwapBaseDataChannelDTLSPolicyOptions, capwapBaseDataChannelDTLSPolicyConfig, capwapBaseControlChannelAuthenOptions, capwapBaseControlChannelAuthenConfig } STATUS current DESCRIPTION "The collection of objects which are used to represent other properties such as security for AC from CAPWAP protocol perspective." ::= { capwapBaseGroups 2 } capwapBaseAcNameListGroup OBJECT-GROUP OBJECTS { capwapBaseAcNameListName, Shi, et al. Expires September 1, 2009 [Page 60] Internet-Draft CAPWAP Protocol Base MIB February 2009 capwapBaseAcNameListPriority, capwapBaseAcNameListRowStatus } STATUS current DESCRIPTION "The collection of objects which are used to configure AC name list." ::= { capwapBaseGroups 3 } capwapBaseMacAclsGroup OBJECT-GROUP OBJECTS { capwapBaseMacAclStationId, capwapBaseMacAclRowStatus } STATUS current DESCRIPTION "The collection of objects which are used to configure stations ACL." ::= { capwapBaseGroups 4 } capwapBaseWtpStateGroup OBJECT-GROUP OBJECTS { capwapBaseWtpStateWtpIpAddressType, capwapBaseWtpStateWtpIpAddress, capwapBaseWtpStateWtpPhyAddress, capwapBaseWtpState } STATUS current DESCRIPTION "The collection of objects which are used to represent WTP state information." ::= { capwapBaseGroups 5 } capwapBaseWtpsGroup OBJECT-GROUP OBJECTS { capwapBaseWtpName, capwapBaseWtpLocation, capwapBaseWtpBaseMacAddress, capwapBaseWtpTunnelModeOptions, capwapBaseWtpMacTypeOptions, capwapBaseWtpRadiosInUseNum, capwapBaseWtpRadioNumLimit, capwapBaseWtpEcnSupport } STATUS current DESCRIPTION "The collection of objects which are used to represent configuration and properties information for WTP Shi, et al. Expires September 1, 2009 [Page 61] Internet-Draft CAPWAP Protocol Base MIB February 2009 in running state." ::= { capwapBaseGroups 6 } capwapBaseWtpsGroup2 OBJECT-GROUP OBJECTS { capwapBaseWtpPhyIndex, capwapBaseWtpDiscoveryType, capwapBaseWtpStaticIpEnable, capwapBaseWtpStaticIpType, capwapBaseWtpStaticIp, capwapBaseWtpNetmask, capwapBaseWtpGateway, capwapBaseWtpFallbackEnable, capwapBaseWtpRetransmitCount, capwapBaseWtpMaxDiscoveries, capwapBaseWtpMaxFailedDTLSSessionRetry, capwapBaseWtpMaxRetransmit, capwapBaseWtpDataChannelKeepAliveTimer, capwapBaseWtpDataChannelDeadInterval, capwapBaseWtpDiscoveryInterval, capwapBaseWtpDTLSSessionDeleteTimer, capwapBaseWtpEchoInterval, capwapBaseWtpIdleTimeout, capwapBaseWtpImageDataStartTimer, capwapBaseWtpMaxDiscoveryInterval, capwapBaseWtpReportInterval, capwapBaseWtpRetransmitInterval, capwapBaseWtpSilentInterval, capwapBaseWtpStatisticsTimer, capwapBaseWtpWaitDTLSTimer } STATUS current DESCRIPTION "The collection of objects which are used to represent configuration and properties information for WTP in running state." ::= { capwapBaseGroups 7 } capwapBaseRadiosGroup OBJECT-GROUP OBJECTS { capwapBaseWirelessBindingVirtualRadioIfIndex, capwapBaseWirelessBindingType } STATUS current DESCRIPTION "The collection of objects which are used to represent wireless binding type, the mapping relationship between 'WLAN Virtual Radio Interface' and PHY radio." Shi, et al. Expires September 1, 2009 [Page 62] Internet-Draft CAPWAP Protocol Base MIB February 2009 ::= { capwapBaseGroups 8 } capwapBaseStationsGroup OBJECT-GROUP OBJECTS { capwapBaseStationAddedTime, capwapBaseStationVlanName } STATUS current DESCRIPTION "The collection of objects which are used to represent stations' basic property." ::= { capwapBaseGroups 9 } capwapBaseWtpEventsStatsGroup OBJECT-GROUP OBJECTS { capwapBaseWtpEventsStatsRebootCount, capwapBaseWtpEventsStatsInitCount, capwapBaseWtpEventsStatsLinkFailureCount, capwapBaseWtpEventsStatsSwFailureCount, capwapBaseWtpEventsStatsHwFailureCount, capwapBaseWtpEventsStatsOtherFailureCount, capwapBaseWtpEventsStatsUnknownFailureCount, capwapBaseWtpEventsStatsLastFailureType } STATUS current DESCRIPTION "The collection of objects which are used for collecting WTP reboot count, link failure count, hardware failure count and so on." ::= { capwapBaseGroups 10 } capwapBaseRadioEventsStatsGroup OBJECT-GROUP OBJECTS { capwapBaseRadioEventsStatsResetCount, capwapBaseRadioEventsStatsSwFailCount, capwapBaseRadioEventsStatsHwFailCount, capwapBaseRadioEventsStatsOtherFailCount, capwapBaseRadioEventsStatsUnknownFailCount, capwapBaseRadioEventsStatsConfigUpdateCount, capwapBaseRadioEventsStatsChannelChangeCount, capwapBaseRadioEventsStatsBandChangeCount, capwapBaseRadioEventsStatsCurrentNoiseFloor, capwapBaseRadioEventsStatsDecryptErrorCount, capwapBaseRadioEventsStatsLastFailType } STATUS current DESCRIPTION "The collection of objects which are used for collecting Shi, et al. Expires September 1, 2009 [Page 63] Internet-Draft CAPWAP Protocol Base MIB February 2009 radio reset count, channel change count, hardware failure count and so on" ::= { capwapBaseGroups 11 } capwapBaseParametersGroup OBJECT-GROUP OBJECTS { capwapBaseAcMaxRetransmit, capwapBaseAcChangeStatePendingTimer, capwapBaseAcDataCheckTimer, capwapBaseAcDTLSSessionDeleteTimer, capwapBaseAcEchoInterval, capwapBaseAcRetransmitInterval, capwapBaseAcSilentInterval, capwapBaseAcWaitDTLSTimer, capwapBaseAcWaitJoinTimer, capwapBaseAcEcnSupport } STATUS current DESCRIPTION "Objects used for CAPWAP protocol." ::= { capwapBaseGroups 12 } capwapBaseStatsGroup OBJECT-GROUP OBJECTS { capwapBaseFailedDTLSAuthFailCount, capwapBaseFailedDTLSSessionCount } STATUS current DESCRIPTION "Objects used for CAPWAP protocol." ::= { capwapBaseGroups 13 } capwapBaseNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { capwapBaseChannelUp, capwapBaseChannelDown, capwapBaseDecryptErrorReport, capwapBaseJoinFailure, capwapBaseImageUpgradeFailure, capwapBaseConfigMsgError, capwapBaseRadioOperableStatus, capwapBaseAuthenticationFailure } STATUS current DESCRIPTION "The Collection of notifications in this MIB module." ::= { capwapBaseGroups 14 } Shi, et al. Expires September 1, 2009 [Page 64] Internet-Draft CAPWAP Protocol Base MIB February 2009 capwapBaseNotifyVarGroup OBJECT-GROUP OBJECTS { capwapBaseNtfWtpId, capwapBaseNtfRadioId, capwapBaseNtfChannelType, capwapBaseNtfAuthenMethod, capwapBaseNtfChannelDownReason, capwapBaseNtfStationIdList, capwapBaseNtfAuthenFailureReason, capwapBaseNtfRadioOperStatusFlag, capwapBaseNtfRadioStatusCause, capwapBaseNtfJoinFailureReason, capwapBaseNtfImageFailureReason, capwapBaseNtfConfigMsgErrorType, capwapBaseNtfMsgErrorElements } STATUS current DESCRIPTION "Objects used for notification." ::= { capwapBaseGroups 15 } END 11. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The followings are the tables and objects and their sensitivity/vulnerability: - Unauthorized changes to the capwapBaseWtpTable, writable objects under capwapBaseAcs group may disrupt allocation of resources in the network. For example, a WTP's static IP address could be changed by set capwapBaseWtpStaticIp object. - Unauthorized changes to writable objects under the capwapBaseAc group, it may disrupt allocation of resources in the network. For example, a invalid value for capwapBaseWtpSessionsLimit object will increase AC's traffic burden. Also, some objects such as capwapBaseDataChannelDTLSPolicyConfig may cause network unsafe. - Unauthorized changes to the capwapBaseMacAclTable, it may cause legal stations could not access network any more while illegal stations have chance to access network. Shi, et al. Expires September 1, 2009 [Page 65] Internet-Draft CAPWAP Protocol Base MIB February 2009 - Unauthorized changes to writable objects under the capwapBaseParameters group, it may influence CAPWAP protocol behaviour and status. For example, the invalid value for capwapBaseAcDataCheckTimer may influence CAPWAP state machine. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. The followings are the tables and objects and their sensitivity/vulnerability: - The capwapBaseDataChannelDTLSPolicyOptions and capwapBaseControlChannelAuthenOptions under the capwapBaseAc group exposes the current security option for CAPWAP data and control channel. - The capwapBaseWtpTable exposes WTP's important information like IP address, MAC type and so on. - The capwapBaseWtpEventsStatsTable exposes WTP's failure information. - The capwapBaseRadioEventsStatsTable exposes radio's failure information. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Shi, et al. Expires September 1, 2009 [Page 66] Internet-Draft CAPWAP Protocol Base MIB February 2009 12. IANA Considerations 12.1. IANA Considerations for CAPWAP-BASE-MIB module The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- capwapBaseMIB { mib-2 XXX } 12.2. IANA Considerations for ifType Require IANA to assign a ifType for 'WTP Virtual Radio Interface' type. 13. Contributors This MIB module is based on contributions from Long Gao. 14. Acknowledgements The authors wish to thank David Harrington, Fei Fang, Yu Liu, Sachin Dutta, Ju Wang, Yujin Zhao, Haitao Zhang. 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., Shi, et al. Expires September 1, 2009 [Page 67] Internet-Draft CAPWAP Protocol Base MIB February 2009 "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005. Shi, et al. Expires September 1, 2009 [Page 68] Internet-Draft CAPWAP Protocol Base MIB February 2009 [I-D.ietf-capwap-protocol-specification] Montemurro, M., Stanley, D., and P. Calhoun, "CAPWAP Protocol Specification", draft- ietf-capwap-protocol- specification-15 (work in progress), November 2008. 15.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4118, June 2005. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [IEEE.802-11.2007] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer Shi, et al. Expires September 1, 2009 [Page 69] Internet-Draft CAPWAP Protocol Base MIB February 2009 (PHY) specifications", IEEE Standard 802.11, 2007, . [I-D.ietf-capwap-protocol-binding-ieee80211] Montemurro, M., Stanley, D., and P. Calhoun, "CAPWAP Protocol Binding for IEEE 802.11", draft- ietf-capwap-protocol- binding-ieee80211-12 (work in progress), November 2008. [I-D.ietf-capwap-802dot11-mib] Shi, Y., Perkins, D., Elliott, C., and Y. Zhang, "CAPWAP Protocol Binding MIB for IEEE 802.11", draft-ietf- capwap-802dot11-mib-02 (work in progress), October 2008. Shi, et al. Expires September 1, 2009 [Page 70] Internet-Draft CAPWAP Protocol Base MIB February 2009 Appendix A. Appendix A. Changes between -04 and -03 T1. Running smilint results in the following errors: mibs/CAPWAP-BASE-MIB:480: [5] {index-exceeds-too-large} warning: index of row `capwapBaseWtpStateEntry' can exceed OID size limit by 6 subidentifier(s) mibs/CAPWAP-BASE-MIB:582: [5] {index-exceeds-too-large} warning: index of row `capwapBaseWtpEntry' can exceed OID size limit by 6 subidentifier(s) mibs/CAPWAP-BASE-MIB:1090: [5] {index-exceeds-too-large} warning: index of row `capwapBaseRadioBindEntry' can exceed OID size limit by 7 subidentifier(s) mibs/CAPWAP-BASE-MIB:1181: [5] {index-exceeds-too-large} warning: index of row `capwapBaseStationEntry' can exceed OID size limit by 13 subidentifier(s) mibs/CAPWAP-BASE-MIB:1249: [5] {index-exceeds-too-large} warning: index of row `capwapBaseWtpRebootStatsEntry' can exceed OID size limit by 6 subidentifier(s) mibs/CAPWAP-BASE-MIB:1408: [5] {index-exceeds-too-large} warning: index of row `capwapBaseRadioStatsEntry' can exceed OID size limit by 7 subidentifier(s) The reason is that these tables are indexed with objects of SYNTAX of CapwapBaseWtpIdTC which has a maximal size of 128, equal to the maximal size allowed for the whole OID. Reducing the maximal size of the TC to anything less or equal than 115 solves the problem. -------------------------------------------------------------- Refer to entPhysicalSerialNum in RFC4133 and Dan's comment, define CapwapBaseWtpIdTC with OCTET STRING (SIZE (0..32)) IF we use SnmpAdminString (SIZE (0..32)), libsmi would generate error: textual convention `CapwapBaseWtpIdTC' can not be derived from the textual convention `SnmpAdminString' T2. Section 5 - ' To reuse current MIB standards and future extensions for a wireless binding technology' - it is not clear what 'future extensions' may be and I would not commit to using them in advance, so I would suggest to drop this ------------------------------------------------------------- Change it into " To be independent of any wireless technologies and have ability to reuse wireless binding MIB modules defined by other SDOs;" T3 What are the 'MIB standards of other SDOs' that need to be reused? Shi, et al. Expires September 1, 2009 [Page 71] Internet-Draft CAPWAP Protocol Base MIB February 2009 Please refer to them specifically at least by providing one example - for instance where does Dot11OperationTable come from? -------------------------------------------------------------- It is changed into: The text give a definition of " 5.2. Wireless Binding MIB Modules" For Dot11OperationTable, the chang is: For example, the MIB tables such as Dot11OperationTable [IEEE.802- 11.2007] are able to support WTP radio configuration. T4. In order for ifIndex to be used as a common handler for the CAPWAP MIB and for the interface specific MIB modules like a dot11 MIB from IEEE one needs to ensure that the same numbering scheme and mapping is used by all MIB modules, and that it behaves identically for events like interface card swapping, reset or power loss. I do not see how this can happen, I am not sure that this is possible at all, and in any case there is no text in the CAPWAP MIB that explains this mechanism. -------------------------------------------------------------- in the Capwap Digest, Vol 39, Issue 4, we gave the text to explain a mechanism that preserves the values of ifIndex, Request mailing list to confirm it. In the section of "Relationship to the IF-MIB", add text "Also, as ifIndex[RFC2863] will be used as common handler for corresponding interfaces in the CAPWAP-BASE-MIB and specific wireless technologies MIB modules, the system (AC) MUST have a mechanisms that preserves the values of ifIndex in the ifTable at AC reboot." T5. Section 7.2 - 'The interface SHOULD be modeled as an ifEntry' - Is a SHOULD enough or rather a MUST is required here taking into account the requirements in Section 5. ----------------------------------------------------------------- It is changed into:MUST be T6. The documents that define the MIB modules required for IMPORTs must be listed in the Normative References section. ----------------------------------------------------------------- Shi, et al. Expires September 1, 2009 [Page 72] Internet-Draft CAPWAP Protocol Base MIB February 2009 add reference to RFC3411 in the section of "MIB modules required for IMPORTS", add "SNMP-FRAMEWORK-MIB [RFC3411]," T7. In the example in Section 8 capwapBaseWtpId equals the representation of the OCTET STRING '12345678' and not the number 12345678 ---------------------------------------------------------------- Yes, it is change into '12345678' T8. In the example in Section 8 ifPhysicalAddress should have six zeros. ----------------------------------------------------------------- Yes, it is change into '000000' T9. What is the Vendor Identifier mentioned in Section 9 as being assigned by IANA? Is this something specific for this MIB document - in this case it needs to be mentioned in the IANA considerations section? ----------------------------------------------------------------- The description of Vendor Identifie is changed into: Vendor Identifier: A 32-bit value containing the IANA assigned "SMI Network Management Private Enterprise Codes" T10. Why does one need a special TC for CapwapBaseWtpIdTC? If this is typically a serial number, then SnmpAdminString SIZE (1..128) should do. ----------------------------------------------------------------- Station, radio, WTP are main objects to management by MIB drafts. They would appear in the serval table and notification. Suggest to have a TC for them. T11. In any case why is the SIZE in this TC fixed at 128? ----------------------------------------------------------------- Refer to entPhysicalSerialNum in RFC4133 and Dan's comment, define CapwapBaseWtpIdTC with OCTET STRING (SIZE (0..32)) T12. A number of read-write objects do not have the persistency behavior defined in case of agent reboot - capwapBaseStationSessionsLimit, capwapBaseDataChannelSecConfig, Shi, et al. Expires September 1, 2009 [Page 73] Internet-Draft CAPWAP Protocol Base MIB February 2009 capwapBaseControlChannelAuthenConfig ----------------------------------------------------------------- Add the "The value of the object is persistent at restart/reboot." in the description of capwapBaseAcMaxRetransmit,capwapBaseAcChangeStatePendingTimer, capwap BaseAcDataCheckTimer,capwapBaseAcDTLSSessionDeleteTimer,capwapBaseAcE choInterval, capwapBaseAcWaitJoinTimer, capwapBaseAcWaitDTLSTimer,capwapBaseAcSilentInterval, capwapBaseAcRetransmitInterval T13 - Is more than one security policy possible to be configured on a given AC? If not, then why is capwapBaseDataChannelSecConfig a BIT? ----------------------------------------------------------------- Yes, the data type of capwapBaseDataChannelSecConfig should be INTEGER T14 - the name of capwapBaseDataChannelSecOptions should better be something that includes DTLSPolicy to make clear to what fields in the AC Descriptor it corresponds. The DESCRIPTION should also be consistent with the text in the protocol document ----------------------------------------------------------------- To make it consistent with protocol, change capwapBaseDataChannelSecOptions with capwapBaseDataChannelDTLSPolicyOptions. Change capwapBaseDataChannelSecConfig with capwapBaseDataChannelDTLSPolicyConfig Also, the DESCRIPTION should also be consistent with the text in the protocol document T15 - is more than one credential type possible to be configured on a given AC? If not then why is capwapBaseControlChannelAuthenConfig a BIT? ----------------------------------------------------------------- Yes, the data type of capwapBaseControlChannelSecConfig should be INTEGER T16 - it would be good for management applications writers to mention in the DESCRIPTION clause thatcapwapBaseAcnameListName is expected to be a UTF-8 encoded string ----------------------------------------------------------------- Shi, et al. Expires September 1, 2009 [Page 74] Internet-Draft CAPWAP Protocol Base MIB February 2009 Yes, it is added T17 - Object names in capwapBaseWtpStateTable do not respect the naming conditions relative to capwapBaseWtpStateEntry --------------------------------------------------------------- Add one more WtpState in the object name. For example, capwapBaseWtpId is to changed into capwapBaseWtpStateWtpId, other objects are similiar. all objects with new name: CapwapBaseWtpStateEntry ::= SEQUENCE { capwapBaseWtpStateWtpId CapwapBaseWtpIdTC, capwapBaseWtpStateWtpIpAddressType InetAddressType, capwapBaseWtpStateWtpIpAddress InetAddress, capwapBaseWtpStateWtpPhyAddress PhysAddress, capwapBaseWtpState INTEGER } T18 - same for capwapBaseWtpStateTable ----------------------------------------------------------------- Same as above T19 - capwapBaseWtpName is of SYNTAX AsnmpAdminString which is limited to SIZE 255, while the WTP name can be up to 512 characters -------------------------------------------------------------- change with OCTET STRING(SIZE(512)) T20 - same about capwapbaseWtpLocation which can be up to 1024 characters in length ----------------------------------------------------------------- change with OCTET STRING(SIZE(1024)) T21 - Section 4.8 defines default value for a number of variables. However, these are not reflected in the MIB - for example why is there not a DEFAULT clause that will set capwapBaseWtpFallbackEnable to enabled(1) as per 4.8.9? Or capwapBaseWtpMaxDiscoveries which has a default of 10 defined in 4.8.5 ------------------------------------------------------------------- Shi, et al. Expires September 1, 2009 [Page 75] Internet-Draft CAPWAP Protocol Base MIB February 2009 Added DEFVAL { enabled } for capwapBaseWtpFallbackEnable. capwapBaseWtpMaxDiscoveries already has DEFVAL { 10 }. T22 - why does the MIB support reserved(0) for capwapBaseWtpFallbackEnable. Does setting to reserved(0) by the management application have any significance? ----------------------------------------------------------------- The reserved(0) is removed for capwapBaseWtpFallbackEnable T23 - According to 4.8.8 capwapBaseWtpRetransmitCount is a monotonous increasing counter. The appropriate SYNTAX for such an object is Counter32 and not Unsigned32 ----------------------------------------------------------------- Yes, capwapBaseWtpRetransmitCount should use Counter32 T24 - it would be useful to define UNITS clauses for objects like capwapBaseWtpRetransmitCount ----------------------------------------------------------------- It seemed capwapBaseWtpRetransmitCount does not require a UNIT. T25 - define a range (2..180) for capwapBaseWtpMaxDiscoveryInterval ---------------------------------------------------------------- add value scope of (0..24) to capwapBaseWtpDataChannelDeadInterval add value scope of (2..180) to capwapBaseWtpMaxDiscoveryInterval add value scope of (30..4294967295) to capwapBaseWtpWaitDTLSTimer add value scope of (30..4294967295) to capwapBaseAcWaitDTLSTimer add value scope of (20..4294967295) to capwapBaseAcWaitJoinTimer T27 - Object names in capwapBaseRadioBindTable do not respect the naming conditions relative to capwapBaseRadioBindEntry -------------------------------------------------------------------- Change all objects (entry, table)'s prefix from capwapBaseRadioBind to capwapBaseWirelessBinding. change CapwapBaseRadioBindTable to CapwapBaseWirelessBindingTable The Objects with new name: Shi, et al. Expires September 1, 2009 [Page 76] Internet-Draft CAPWAP Protocol Base MIB February 2009 CapwapBaseWirelessBindingEntry ::= SEQUENCE { capwapBaseWirelessBindingRadioId CapwapBaseRadioIdTC, capwapBaseWirelessBindingVirtualRadioIfIndex InterfaceIndex, capwapBaseWirelessBindingType INTEGER } T28 - What do the values reserved(0) and reserved(2) in capwapBaseRadioWirelessBinding mean? Are they ever returned by an agent? ----------------------------------------------------------------- removed the reserved(0) and reserved(2) from the object definition. T29 - in other IETF documents (like RFC 4363) VLAN names are defined as SnmpAdminString (SIZE (0..32)). I suggest the same for capwapBaseStationVlanName. I am aware that section 4.6.8 allows for names up to 512, but I do not find this justified. In any case, if the full size defined in 4.6.8 is to be accommodated, then SnmpAdminString would not be sufficient as its size is limited to 256. ----------------------------------------------------------------- capwapBaseStationVlanName use SnmpAdminString (SIZE (0..32)) T30 - Object names in capwapBaseWtpRebootStatsTable do not respect the naming conditions relative to capwapBaseWtpRebootStatsEntry ------------------------------------------------------------------ Change table name from capwapBaseWtpRebootStatTable to capwapBaseWtpEventsStatsTable. The objects also do similar changes, for example, change capwapBaseWtpRebootCount to capwapBaseWtpEventsStatsRebootCount The objects with new name: CapwapBaseWtpEventsStatsEntry ::= SEQUENCE { capwapBaseWtpEventsStatsRebootCount Counter32, capwapBaseWtpEventsStatsInitCount Counter32, capwapBaseWtpEventsStatsLinkFailureCount Counter32, capwapBaseWtpEventsStatsSwFailureCount Counter32, capwapBaseWtpEventsStatsHwFailureCount Counter32, capwapBaseWtpEventsStatsOtherFailureCount Counter32, capwapBaseWtpEventsStatsUnknownFailureCount Counter32, capwapBaseWtpEventsStatsLastFailureType INTEGER Shi, et al. Expires September 1, 2009 [Page 77] Internet-Draft CAPWAP Protocol Base MIB February 2009 } T31 - Object names in capwapBaseWtpRadioStatsTable do not respect the naming conditions relative to capwapBaseWtpRadioStatsEntry ---------------------------------------------------------------- Change table name from capwapBaseWtpRadioStatsTable to capwapBaseRadioEventsStatsTable. The objects also do similar changes, for example, change capwapBaseRadioSwFailCount to capwapBaseRadioEventsStatsSwFailCount. The objects with new name: CapwapBaseRadioEventsStatsEntry ::= SEQUENCE { capwapBaseRadioEventsStatsResetCount Counter32, capwapBaseRadioEventsStatsSwFailCount Counter32, capwapBaseRadioEventsStatsHwFailCount Counter32, capwapBaseRadioEventsStatsOtherFailCount Counter32, capwapBaseRadioEventsStatsUnknownFailCount Counter32, capwapBaseRadioEventsStatsConfigUpdateCount Counter32, capwapBaseRadioEventsStatsChannelChangeCount Counter32, capwapBaseRadioEventsStatsBandChangeCount Counter32, capwapBaseRadioEventsStatsCurrentNoiseFloor Integer32, capwapBaseRadioEventsStatsDecryptErrorCount Counter32, capwapBaseRadioEventsStatsLastFailType INTEGER } E1. Even if this document uses terminology borrowed from other CAPWAP documents, acronyms like WTP, AC, etc. should be expanded at the first occurrence. ----------------------------------------------------------------- The Terminology section is updated with more Terminology such as Autonomous WLAN Architecture, Centralized WLAN Architecture, Wireless Binding,Split and Local MAC and so on. E2. It would be good for the document to be grammar and spelling checked by a native English speaker. E3. No need for sections 6.1, 6.2, 6.3 - these are standard in any MIB module and their content is well known ----------------------------------------------------------------- Ok, there are removed Shi, et al. Expires September 1, 2009 [Page 78] Internet-Draft CAPWAP Protocol Base MIB February 2009 E4. In Section 7.2 there is no need to mention information that is not specific to the CAPWAP MIB -------------------------------------------------------------------- Removed the "Some specific interpretations of ifTable for CAPWAP- BASE-MIB are as follow." and the interpretations followed it. E5. In the example in Section 8 ifType should be equal with the value assigned by IANA for the ifType - you may mark it xxx and enter an editor note saying 'RFC Editor - please replace xxx with the value allocated by IANA for IANAifType of 'WTP Virtual Radio Interface') ----------------------------------------------------------------- It is done according to the comment E6. Please indicate specifically for each field for the protocols timers message the exact reference in than CAPWAP protocol document. ----------------------------------------------------------------- The section was updated according to protocol E7. The numbering of referred paragraphs in the REFERENCE clauses are not synchronized with the latest version of the CAPWAP protocol document as per http://www.rfc-editor.org/rfc/rfc3411.txt ------------------------------------------------------------------- The REFERENCE clauses for the following TCs or objects are changed with new id: CapwapBaseTunnelModeTC Section 4.6.42 to Section 4.6.43 CapwapBaseMacTypeTC Section 4.6.43 to Section 4.6.44 capwapBaseWtpName Section 4.6.44 to Section 4.6.45 capwapBaseWtpLocation Section 4.6.29 to Section 4.6.30 capwapBaseWtpBaseMacAddress Section 4.6.39 to Section 4.6.40 Shi, et al. Expires September 1, 2009 [Page 79] Internet-Draft CAPWAP Protocol Base MIB February 2009 capwapBaseTunnelModeOptions Section 4.6.42 to Section 4.6.43 capwapBaseMacTypeOptions Section 4.6.43 to Section 4.6.44 capwapBaseWtpRadiosInUseNum and capwapBaseWtpRadioNumLimit Section 4.6.40 to Section 4.6.41 capwapBaseWtpStaticIpEnable, capwapBaseWtpStaticIp, capwapBaseWtpNetmask,capwapBaseWtpGateway Section 4.6.47 to Section 4.6.48 capwapBaseWtpFallbackEnable Section 4.6.41 to Section 4.6.42 all the objects in the capwapBaseWtpRebootStatsTable Section 4.6.46 to Section 4.6.47 all the objects in the capwapBaseRadioStatsTable Section 4.6.45 to Section 4.6.46 capwapBaseJoinFailure,capwapBaseImageUpgradeFailure, capwapBaseConfigMsgError Section 4.6.34 to Section 4.6.35 capwapBaseRadioOperableStatus,capwapBaseNtfRadioOperStatusFlag, capwapBaseNtfRadioStatusCause Section 4.6.33 to Section 4.6.34 capwapBaseNtfJoinFailureReason,capwapBaseNtfImageFailureReason Section 4.6.34 to Section 4.6.35 capwapBaseNtfConfigMsgErrorType,capwapBaseNtfMsgErrorElements Section 4.6.35 to Section 4.6.36 E8. No need to repeat the text in the DESCRIPTION clause if a TC is used (e.g. capwapBaseTunnelModeOption, capwapBaseMacTypeOptions) ---------------------------------------------------------------- Change the description of them, and only talk about the function of objects. E9 - capwapBaseWtpMaxRetransmitCnt is not a counter so the suffix Cnt should be dropped from the name. ------------------------------------------------------------------- Shi, et al. Expires September 1, 2009 [Page 80] Internet-Draft CAPWAP Protocol Base MIB February 2009 Change capwapBaseWtpMaxRetransmitCnt into capwapBaseWtpMaxRetransmit E10 - capwapBaseAcMaxRetransmitCnt is not a counter so the suffix Cnt should be dropped from the name. ------------------------------------------------------------------- Change capwapBaseAcMaxRetransmitCnt into capwapBaseAcMaxRetransmit Other changes made by authors: 1) To keep Terminology consistent change "MIBs" with "MIB modules", change "MIB standards" with "MIB modules". 2) Replace "As a generic mechanism, it is independent of any wireless technologies and defined by an independent MIB file" with "It is designed to accommodate the specific needs of each wireless technology in a standard way. It is independent of any wireless technologies;" 3) add reference to [IEEE.802-11.2007],[I-D.ietf-capwap-protocol-binding -ieee80211] and [I-D.ietf-capwap-802dot11-mib] 4) Respect the naming conditions to capwapBaseWtpTable, change capwapBaseMacTypeOptions to capwapBaseWtpMacTypeOptions change capwapBaseTunnelModeOptions to capwapBaseWtpTunnelModeOptions 5) Change IPV6 to IPv6, IPV4 to IPv4 6) remove redundant "the" in the R"Represents the the next" 7) reorganized the section of overview, and divided it into the following sub sections: 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 Especially, add the Terminology of "CAPWAP Protocol Wireless Binding MIB Module" and "Wireless Binding MIB Module". 8) Remove unused(0) from CapwapBaseTunnelModeTC, capwapBaseControlChannelAuthenOptions and capwapBaseControlChannelAuthenConfig 9) Update some words in the section of" Example of CAPWAP-BASE-MIB Module Usage" 10) Added capwapBaseAcEcnSupport, capwapBaseWtpEcnSupport Shi, et al. Expires September 1, 2009 [Page 81] Internet-Draft CAPWAP Protocol Base MIB February 2009 Authors' Addresses Yang Shi (editor) H3C Tech. Co., Ltd Digital Technology Plaza, NO.9 Shangdi 9th Street,Haidian District, Beijing China(100085) Phone: +86 010 82775276 EMail: young@h3c.com David Perkins (editor) SNMPinfo 288 Quailbrook Ct San Carlos, CA 94070 USA Phone: +1 408 394-8702 EMail: dperkins@snmpinfo.com Chris Elliott (editor) Cisco Systems, Inc. 7025 Kit Creek Rd., P.O. Box 14987 Research Triangle Park 27709 USA Phone: +1 919-392-2146 EMail: chelliot@cisco.com Yong Zhang (editor) Fortinet, Inc. 1090 Kifer Road Sunnyvale, CA 94086 USA EMail: yzhang@fortinet.com Shi, et al. Expires September 1, 2009 [Page 82]