The RFC Archive
 The RFC Archive   RFC 5834   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 5834

Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding MIB for IEEE 802.11

Last modified on Thursday, May 6th, 2010

Permanent link to RFC 5834
Search GitHub Wiki for RFC 5834
Show other RFCs mentioning RFC 5834







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

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


  Control and Provisioning of Wireless Access Points (CAPWAP) Protocol
                      Binding MIB for IEEE 802.11

 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 for IEEE 802.11 wireless
   binding.  This MIB module is presented as a basis for future work on
   the management of the CAPWAP protocol using the Simple Network
   Management Protocol (SNMP).

 Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/RFC 5834.













Shi, et al.                   Informational                  PAGE 1 top


RFC 5834 CAPWAP Protocol Binding MIB May 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Internet-Standard Management Framework . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. WLAN Profile . . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Requirements and Constraints . . . . . . . . . . . . . . . 5 5.3. Mechanism of Reusing Wireless Binding MIB Module . . . . . 6 6. Structure of MIB Module . . . . . . . . . . . . . . . . . . . 6 7. Relationship to Other MIB Modules . . . . . . . . . . . . . . 7 7.1. Relationship to SNMPv2-MIB Module . . . . . . . . . . . . 7 7.2. Relationship to IF-MIB Module . . . . . . . . . . . . . . 7 7.3. Relationship to CAPWAP-BASE-MIB Module . . . . . . . . . . 7 7.4. Relationship to MIB Module in the IEEE 802.11 Standard . . 8 7.5. MIB Modules Required for IMPORTS . . . . . . . . . . . . . 8 8. Example of CAPWAP-DOT11-MIB Module Usage . . . . . . . . . . . 8 9. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 11.1. IANA Considerations for CAPWAP-DOT11-MIB Module . . . . . 22 11.2. IANA Considerations for ifType . . . . . . . . . . . . . . 22 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 14.1. Normative References . . . . . . . . . . . . . . . . . . . 23 14.2. Informative References . . . . . . . . . . . . . . . . . . 24 Shi, et al. Informational PAGE 2 top

RFC 5834 CAPWAP Protocol Binding MIB May 2010 1. Introduction The CAPWAP protocol [RFC 5415] defines a standard, interoperable protocol, which enables an Access Controller (AC) to manage a collection of Wireless Termination Points (WTPs). CAPWAP supports the use of various wireless technologies by the WTPs, with one specified in the CAPWAP Protocol Binding for IEEE 802.11 [RFC 5416]. This document defines a MIB module that can be used to manage CAPWAP implementations for IEEE 802.11 wireless binding. This MIB module covers both configuration for Wireless Local Area Network (WLAN) and a way to reuse the IEEE 802.11 MIB module [IEEE.802-11.2007]. It is presented as a basis for future work on the SNMP management of the CAPWAP protocol. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC 3410]. 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 [RFC 2578], STD 58, RFC 2579 [RFC 2579], and STD 58, RFC 2580 [RFC 2580]. 3. Terminology This document uses terminology from the CAPWAP protocol specification [RFC 5415], the CAPWAP Protocol Binding for IEEE 802.11 [RFC 5416], and the CAPWAP Protocol Base MIB [RFC 5833]. 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 physical layer (PHY) to transmit and receive station traffic for wireless access networks. Shi, et al. Informational PAGE 3 top

RFC 5834 CAPWAP Protocol Binding MIB May 2010 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) [RFC 4347]. CAPWAP Control Channel: A bi-directional flow defined by the AC IP Address, WTP IP Address, AC control port, WTP control port, and the transport-layer protocol (UDP or UDP-Lite) over which CAPWAP control packets are sent and received. CAPWAP Data Channel: A bi-directional flow defined by the AC IP Address, WTP IP Address, AC data port, WTP data port, and the transport-layer protocol (UDP or UDP-Lite) over which CAPWAP data packets are sent and received. Station (STA): A device that contains an interface to a wireless medium (WM). Split and Local MAC: The CAPWAP protocol supports two modes of operation: Split and Local MAC (medium access control). In Split MAC mode, all Layer 2 wireless data and management frames are encapsulated via the CAPWAP protocol and exchanged between the AC and the WTPs. The Local MAC mode of operation allows the data frames to be either locally bridged or tunneled as 802.3 frames. Wireless Binding: The CAPWAP protocol is independent of a specific WTP radio technology, as well its associated wireless link layer protocol. Elements of the CAPWAP protocol are designed to accommodate the specific needs of each wireless technology in a standard way. Implementation of the CAPWAP protocol for a particular wireless technology MUST define a binding protocol for it, e.g., the binding for IEEE 802.11, provided in [RFC 5416]. Wireless Local Area Network (WLAN): A WLAN refers to a logical component instantiated on a WTP device. A single physical WTP MAY operate a number of WLANs. Each Basic Service Set Identifier (BSSID) and its constituent wireless terminal radios are denoted as a distinct WLAN on a physical WTP. To support a physical WTP with multiple WLANs is an important feature for CAPWAP protocol's 802.11 binding, and it is also for MIB module design. Wireless Binding MIB Module: Other Standards Development Organizations (SDOs), such as IEEE, already defined MIB modules for specific wireless technologies, e.g., the IEEE 802.11 MIB module [IEEE.802-11.2007]. Such MIB modules are called wireless binding MIB modules. Shi, et al. Informational PAGE 4 top

RFC 5834 CAPWAP Protocol Binding MIB May 2010 CAPWAP Protocol Wireless Binding MIB Module: It is a MIB module corresponding to the CAPWAP Protocol Binding for a wireless 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 [RFC 5416] defines WLAN conception. 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. 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 [RFC 2119]. 5. Overview 5.1. WLAN Profile A WLAN profile stores configuration parameters such as MAC type and tunnel mode for a WLAN. Each WLAN profile is identified by a profile identifier. The operator needs to create WLAN profiles before WTPs connect to the AC. To provide WLAN service, the operator SHOULD bind WLAN profiles to a WTP Virtual Radio Interface that corresponds to a PHY radio. During the binding operation, the AC MUST select an unused WLAN ID between 1 and 16 [RFC 5416]. For example, to bind one more WLAN profile to a radio that has been bound with a WLAN profile, the AC SHOULD allocate WLAN ID 2 to the radio. Although the maximum value of a WLAN ID is 16, the operator could configure more than 16 WLAN Profiles on the AC. 5.2. Requirements and Constraints The IEEE 802.11 MIB module [IEEE.802-11.2007] already defines MIB objects for most IEEE 802.11 Message Elements in the CAPWAP Protocol Binding for IEEE 802.11 [RFC 5416]. As a CAPWAP protocol 802.11 binding MIB module, the CAPWAP-DOT11-MIB module MUST be able to reuse such MIB objects in the IEEE 802.11 MIB module and support functions (such as MAC mode for WLAN in the [RFC 5416]) that are not in the scope of IEEE 802.11 standard. The CAPWAP-DOT11-MIB module MUST support such functions. In summary, the CAPWAP-DOT11-MIB module needs to support: - Reuse of wireless binding MIB modules in the IEEE 802.11 standard; Shi, et al. Informational PAGE 5 top

RFC 5834 CAPWAP Protocol Binding MIB May 2010 - Centralized management and configuration of WLAN profiles on the AC; - Configuration of a MAC type and tunnel mode for a specific WLAN profile. 5.3. Mechanism of Reusing Wireless Binding MIB Module In the IEEE 802.11 MIB module, the MIB tables such as dot11AuthenticationAlgorithmsTable are able to support WLAN configuration (such as authentication algorithm), and these tables use the ifIndex as the index which works well in the autonomous WLAN architecture. Reuse of such wireless binding MIB modules is very important to centralized WLAN architectures. The key point is to abstract a WLAN profile as a WLAN Profile Interface on the AC, which could be identified by an ifIndex. The MIB objects in the IEEE 802.11 MIB module which are associated with this interface can be used to configure WLAN parameters for the WLAN, such as authentication algorithm. With the ifIndex of a WLAN Profile Interface, the AC is able to reuse the IEEE 802.11 MIB module. In the CAPWAP-BASE-MIB module, each PHY radio is identified by a WTP ID and a radio ID, and has a corresponding WTP Virtual Radio Interface on the AC. The IEEE 802.11 MIB module associated with this interface can be used to configure IEEE 802.11 wireless binding parameters for the radio such as RTS Threshold. A WLAN Basic Service Set (BSS) Interface, created by binding a WLAN to a WTP Virtual Radio Interface, is used for data forwarding. 6. Structure of MIB Module The MIB objects are derived from the CAPWAP protocol binding for IEEE 802.11 document [RFC 5416]. capwapDot11WlanTable The table allows the operator to display and configure WLAN profiles, such as specifying the MAC type and tunnel mode for a WLAN. Also, it helps the AC to configure a WLAN through the IEEE 802.11 MIB module. Shi, et al. Informational PAGE 6 top

RFC 5834 CAPWAP Protocol Binding MIB May 2010 capwapDot11WlanBindTable The table provides a way to bind WLAN profiles to a WTP Virtual Radio Interface, which has a corresponding PHY radio. A binding operation dynamically creates a WLAN BSS Interface, which is used for data forwarding. 7. Relationship to Other MIB Modules 7.1. Relationship to SNMPv2-MIB Module The CAPWAP-DOT11-MIB module does not duplicate the objects of the 'system' group in the SNMPv2-MIB [RFC 3418] that is defined as being mandatory for all systems, and the objects apply to the entity as a whole. The 'system' group provides identification of the management entity and certain other system-wide data. 7.2. Relationship to IF-MIB Module The Interfaces Group [RFC 2863] defines generic managed objects for managing interfaces. This memo contains the media-specific extensions to the Interfaces Group for managing WLAN that are modeled as interfaces. Each WLAN profile corresponds to a WLAN Profile Interface on the AC. The interface MUST be modeled as an ifEntry, and ifEntry objects such as ifIndex, ifDescr, ifName, and ifAlias are to be used as per [RFC 2863]. The WLAN Profile Interface provides a way to configure IEEE 802.11 parameters for a specific WLAN and reuse the IEEE 802.11 MIB module. To provide data forwarding service, the AC dynamically creates WLAN BSS Interfaces. A WLAN BSS Interface MUST be modeled as an ifEntry, and ifEntry objects such as ifIndex, ifDescr, ifName, and ifAlias are to be used as per [RFC 2863]. The interface enables a single physical WTP to support multiple WLANs. Also, the AC MUST have a mechanism that preserves the value of the ifIndexes (of both the WLAN Profile Interfaces and the WLAN BSS Interfaces) in the ifTable at AC reboot. 7.3. Relationship to CAPWAP-BASE-MIB Module The CAPWAP-BASE-MIB module provides a way to manage and control WTP and radio objects. Especially, it provides the WTP Virtual Radio Interface mechanism to enable the AC to reuse the IEEE 802.11 MIB module. With this mechanism, an operator could configure an IEEE Shi, et al. Informational PAGE 7 top

RFC 5834 CAPWAP Protocol Binding MIB May 2010 802.11 radio's parameters and view the radio's traffic statistics on the AC. Based on the CAPWAP-BASE-MIB module, the CAPWAP-DOT11-MIB module provides more WLAN information. 7.4. Relationship to MIB Module in the IEEE 802.11 Standard With the ifIndex of WLAN Profile Interface and WLAN BSS Interface, the MIB module is able to reuse the IEEE 802.11 MIB module [IEEE.802-11.2007]. The CAPWAP-DOT11-MIB module does not duplicate those objects in the IEEE 802.11 MIB module. The CAPWAP Protocol Binding for IEEE 802.11 [RFC 5416] involves some of the MIB objects defined in the IEEE 802.11 standard. Although CAPWAP-DOT11-MIB module uses it [RFC 5416] as a reference, it could reuse all the MIB objects in the IEEE 802.11 standard , and is not limited by the scope of CAPWAP Protocol Binding for IEEE 802.11. 7.5. MIB Modules Required for IMPORTS The following MIB modules are required for IMPORTS: SNMPv2-SMI [RFC 2578], SNMPv2-TC [RFC 2579], SNMPv2-CONF [RFC 2580], IF-MIB [RFC 2863], and CAPWAP-BASE-MIB [RFC 5833]. 8. Example of CAPWAP-DOT11-MIB Module Usage 1) Create a WTP profile. Suppose the WTP's base MAC address is '00:01:01:01:01:00'. Creates a WTP profile for it through the capwapBaseWtpProfileTable [RFC 5833] as follows: In capwapBaseWtpProfileTable { capwapBaseWtpProfileId = 1, capwapBaseWtpProfileName = 'WTP Profile 123456', capwapBaseWtpProfileWtpMacAddress = '00:01:01:01:01:00', capwapBaseWtpProfileWTPModelNumber = 'WTP123', capwapBaseWtpProfileWtpName = 'WTP 123456', capwapBaseWtpProfileWtpLocation = 'office', capwapBaseWtpProfileWtpStaticIpEnable = true(1), capwapBaseWtpProfileWtpStaticIpType = ipv4(1), capwapBaseWtpProfileWtpStaticIpAddress = '192.0.2.10', capwapBaseWtpProfileWtpNetmask = '255.255.255.0', capwapBaseWtpProfileWtpGateway = '192.0.2.1', capwapBaseWtpProfileWtpFallbackEnable = true(1), capwapBaseWtpProfileWtpEchoInterval = 30, capwapBaseWtpProfileWtpIdleTimeout = 300, capwapBaseWtpProfileWtpMaxDiscoveryInterval = 20, Shi, et al. Informational PAGE 8 top

RFC 5834 CAPWAP Protocol Binding MIB May 2010 capwapBaseWtpProfileWtpReportInterval = 120, capwapBaseWtpProfileWtpStatisticsTimer = 120, capwapBaseWtpProfileWtpEcnSupport = limited(0) } Suppose the WTP with model number 'WTP123' has one PHY radio and this PHY radio is identified by ID 1. The creation of this WTP profile triggers the AC to automatically create a WTP Virtual Radio Interface and add a new row object to the capwapBaseWirelessBindingTable without manual intervention. Suppose the ifIndex of the WTP Virtual Radio Interface is 10. The following information is stored in the capwapBaseWirelessBindingTable. In capwapBaseWirelessBindingTable { capwapBaseWtpProfileId = 1, capwapBaseWirelessBindingRadioId = 1, capwapBaseWirelessBindingVirtualRadioIfIndex = 10, capwapBaseWirelessBindingType = dot11(2) } The WTP Virtual Radio Interfaces on the AC correspond to the PHY radios on the WTP. The WTP Virtual Radio Interface is modeled by ifTable [RFC 2863]. In ifTable { ifIndex = 10, ifDescr = 'WTP Virtual Radio Interface', ifType = 254, ifMtu = 0, ifSpeed = 0, ifPhysAddress = '00:00:00:00:00:00', ifAdminStatus = true(1), ifOperStatus = false(0), ifLastChange = 0, ifInOctets = 0, ifInUcastPkts = 0, ifInDiscards = 0, ifInErrors = 0, ifInUnknownProtos = 0, ifOutOctets = 0, ifOutUcastPkts = 0, ifOutDiscards = 0, ifOutErrors = 0 } Shi, et al. Informational PAGE 9 top

RFC 5834 CAPWAP Protocol Binding MIB May 2010 2) Query the ifIndexes of WTP Virtual Radio Interfaces. Before configuring PHY radios, the operator needs to get the ifIndexes of WTP Virtual Radio Interfaces corresponding to the PHY radios. As the capwapBaseWirelessBindingTable already stores the mappings between PHY radios (Radio IDs) and the ifIndexes of WTP Virtual Radio Interfaces, the operator can get the ifIndex information by querying this table. Such a query operation SHOULD run from radio ID 1 to radio ID 31 (according to [RFC 5415]), and stop when an invalid ifIndex value (0) is returned. This example uses capwapBaseWtpProfileId = 1 and capwapBaseWirelessBindingRadioId = 1 as inputs to query the capwapBaseWirelessBindingTable, and gets capwapBaseWirelessBindingVirtualRadioIfIndex = 10. Then it uses capwapBaseWtpProfileId = 1 and capwapBaseWirelessBindingRadioId = 2, and gets an invalid ifIndex value (0), so the query operation ends. This method gets not only the ifIndexes of WTP Virtual Radio Interfaces, but also the numbers of PHY radios. Besides checking whether the ifIndex value is valid, the operator SHOULD check whether the capwapBaseWirelessBindingType is the desired binding type. 3) Configure IEEE 802.11 parameters for a WTP Virtual Radio Interface This configuration is made on the AC through the IEEE 802.11 MIB module. The following shows an example of configuring parameters for a WTP Virtual Radio Interface with ifIndex 10 through the dot11OperationTable [IEEE.802-11.2007]. In dot11OperationTable { ifIndex = 10, dot11MACAddress = '00:00:00:00:00:00', dot11RTSThreshold = 2347, dot11ShortRetryLimit = 7, dot11LongRetryLimit = 4, dot11FragmentationThreshold = 256, dot11MaxTransmitMSDULifetime = 512, dot11MaxReceiveLifetime = 512, dot11ManufacturerID = 'capwap', dot11ProductID = 'capwap', dot11CAPLimit = 2, dot11HCCWmin = 0, Shi, et al. Informational PAGE 10 top

RFC 5834 CAPWAP Protocol Binding MIB May 2010 dot11HCCWmax = 0, dot11HCCAIFSN = 1, dot11ADDBAResponseTimeout = 1, dot11ADDTSResponseTimeout = 1, dot11ChannelUtilizationBeaconInterval = 50, dot11ScheduleTimeout = 10, dot11DLSResponseTimeout = 10, dot11QAPMissingAckRetryLimit = 1, dot11EDCAAveragingPeriod = 5 } 4) Configure a WLAN Profile. WLAN configuration is made on the AC through the CAPWAP-DOT11-MIB module, and IEEE 802.11 MIB module. The first step is to create a WLAN Profile Interface through the CAPWAP-DOT11-MIB module on the AC. For example, when you configure a WLAN profile that is identified by capwapDot11WlanProfileId 1, the capwapDot11WlanTable creates the following row object for it. In capwapDot11WlanTable { capwapDot11WlanProfileId = 1, capwapDot11WlanProfileIfIndex = 20, capwapDot11WlanMacType = splitMAC(2), capwapDot11WlanTunnelMode = dot3Tunnel(2), capwapDot11WlanRowStatus = createAndGo(4) } The creation of a row object triggers the AC to automatically create a WLAN Profile Interface and it is identified by ifIndex 20 without manual intervention. A WLAN Profile Interface MUST be modeled as an ifEntry on the AC that provides appropriate interface information. The capwapDot11WlanTable stores the mappings between capwapDot11WlanProfileIds and the ifIndexes of WLAN Profile Interfaces. In ifTable { ifIndex = 20, ifDescr = 'WLAN Profile Interface', ifType = 252, ifMtu = 0, Shi, et al. Informational PAGE 11 top

RFC 5834 CAPWAP Protocol Binding MIB May 2010 ifSpeed = 0, ifPhysAddress = '00:00:00:00:00:00', ifAdminStatus = true(1), ifOperStatus = true(1), ifLastChange = 0, ifInOctets = 0, ifInUcastPkts = 0, ifInDiscards = 0, ifInErrors = 0, ifInUnknownProtos = 0, ifOutOctets = 0, ifOutUcastPkts = 0, ifOutDiscards = 0, ifOutErrors = 0 } The second step is to configure WLAN parameters for the WLAN Profile Interface through the IEEE 802.11 MIB module on the AC. The following example configures an authentication algorithm for a WLAN. In dot11AuthenticationAlgorithmsTable { ifIndex = 20, dot11AuthenticationAlgorithmsIndex = 1, dot11AuthenticationAlgorithm = Shared Key(2), dot11AuthenticationAlgorithmsEnable = true(1) } Here, ifIndex 20 identifies the WLAN Profile Interface, and the index of the configured authentication algorithm is 1. 5) Bind WLAN Profiles to a WTP radio. On the AC, the capwapDot11WlanBindTable in the CAPWAP-DOT11-MIB stores the bindings between WLAN profiles(identified by capwapDot11WlanProfileId) and WTP Virtual Radio Interfaces (identified by the ifIndex). For example, after the operator binds a WLAN profile with capwapDot11WlanProfileId 1 to WTP Virtual Radio Interface with ifIndex 10, the capwapDot11WlanBindTable creates the following row object. Shi, et al. Informational PAGE 12 top

RFC 5834 CAPWAP Protocol Binding MIB May 2010 In capwapDot11WlanBindTable { ifIndex = 10, capwapDot11WlanProfileId = 1, capwapDot11WlanBindBssIfIndex = 30, capwapDot11WlanBindRowStatus = createAndGo(4) } If the capwapDot11WlanMacType of the WLAN is splitMAC(2), the creation of the row object in the capwapDot11WlanBindTable triggers the AC to automatically create a WLAN BSS Interface identified by ifIndex 30 without manual intervention. The WLAN BSS Interface MUST be modeled as an ifEntry on the AC, which provides appropriate interface information. The capwapDot11WlanBindTable stores the mappings among the ifIndex of a WTP Virtual Radio Interface, WLAN profile ID, WLAN ID, and the ifIndex of a WLAN BSS Interface. 6) Get the current configuration status report from the WTP to the AC. Before a WTP that has joined the AC gets configuration from the AC, it needs to report its current configuration status by sending a configuration status request message to the AC, which uses the message to update corresponding MIB objects on the AC. For example, for ifIndex 10 (which identifies a WLAN Virtual Radio Interface), its ifOperStatus in the ifTable is updated according to the current radio operational status in the CAPWAP message [RFC 5415]. 7) Query WTP and radio statistical data. After WTPs start to run, the operator could query WTP and radio statistics data through the CAPWAP-BASE-MIB and CAPWAP-DOT11-MIB modules. For example, through the dot11CountersTable [IEEE.802-11.2007], the operator could query counter data of a radio that is identified by the ifIndex of the corresponding WLAN Virtual Radio Interface. 8) Query other statistical data. The operator could query the configuration of a WLAN through the dot11AuthenticationAlgorithmsTable [IEEE.802-11.2007] and the statistical data of a WLAN BSS Interface through the ifTable [RFC 2863]. Shi, et al. Informational PAGE 13 top

RFC 5834 CAPWAP Protocol Binding MIB May 2010 9. Definitions CAPWAP-DOT11-MIB DEFINITIONS ::= BEGIN IMPORTS RowStatus, TEXTUAL-CONVENTION FROM SNMPv2-TC OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF MODULE-IDENTITY, OBJECT-TYPE, mib-2, Unsigned32 FROM SNMPv2-SMI ifIndex, InterfaceIndex FROM IF-MIB CapwapBaseMacTypeTC, CapwapBaseTunnelModeTC FROM CAPWAP-BASE-MIB; capwapDot11MIB MODULE-IDENTITY LAST-UPDATED "201004300000Z" -- 30 April 2010 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 (editor) Hangzhou H3C Tech. Co., Ltd. Beijing R&D Center of H3C, Digital Technology Plaza NO. 9 Shangdi 9th Street, Haidian District Beijing 100085 China Phone: +86 010 82775276 Email: rishyang@gmail.com David T. Perkins (editor) 228 Bayview Dr. San Carlos, CA 94070 USA Phone: +1 408 394-8702 Email: dperkins@dsperkins.com Chris Elliott (editor) 1516 Kent St. Durham, NC 27707 USA Phone: +1 919-308-1216 Email: chelliot@pobox.com Shi, et al. Informational PAGE 14 top

RFC 5834 CAPWAP Protocol Binding MIB May 2010 Yong Zhang (editor) Fortinet, Inc. 1090 Kifer Road Sunnyvale, CA 94086 USA Email: yzhang@fortinet.com" DESCRIPTION "Copyright (c) 2010 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this MIB module is part of RFC 5834; see the RFC itself for full legal notices. This MIB module contains managed object definitions for CAPWAP Protocol binding for IEEE 802.11." REVISION "201004300000Z" DESCRIPTION "Initial version, published as RFC 5834" ::= { mib-2 195 } -- Textual conventions CapwapDot11WlanIdTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Represents the unique identifier of a Wireless Local Area Network (WLAN)." SYNTAX Unsigned32 (1..16) CapwapDot11WlanIdProfileTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Represents the unique identifier of a WLAN profile." SYNTAX Unsigned32 (1..512) -- Top level components of this MIB module -- Tables, Scalars Shi, et al. Informational PAGE 15 top

RFC 5834 CAPWAP Protocol Binding MIB May 2010 capwapDot11Objects OBJECT IDENTIFIER ::= { capwapDot11MIB 1 } -- Conformance capwapDot11Conformance OBJECT IDENTIFIER ::= { capwapDot11MIB 2 } -- capwapDot11WlanTable Table capwapDot11WlanTable OBJECT-TYPE SYNTAX SEQUENCE OF CapwapDot11WlanEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that allows the operator to display and configure WLAN profiles, such as specifying the MAC type and tunnel mode for a WLAN. Also, it helps the AC to configure a WLAN through the IEEE 802.11 MIB module. Values of all objects in this table are persistent at restart/reboot." ::= { capwapDot11Objects 1 } capwapDot11WlanEntry OBJECT-TYPE SYNTAX CapwapDot11WlanEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that stores the settings of a WLAN profile." INDEX { capwapDot11WlanProfileId } ::= { capwapDot11WlanTable 1 } CapwapDot11WlanEntry ::= SEQUENCE { capwapDot11WlanProfileId CapwapDot11WlanIdProfileTC, capwapDot11WlanProfileIfIndex InterfaceIndex, capwapDot11WlanMacType CapwapBaseMacTypeTC, capwapDot11WlanTunnelMode CapwapBaseTunnelModeTC, capwapDot11WlanRowStatus RowStatus } capwapDot11WlanProfileId OBJECT-TYPE SYNTAX CapwapDot11WlanIdProfileTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "Represents the identifier of a WLAN profile that has a corresponding capwapDot11WlanProfileIfIndex." ::= { capwapDot11WlanEntry 1 } Shi, et al. Informational PAGE 16 top

RFC 5834 CAPWAP Protocol Binding MIB May 2010 capwapDot11WlanProfileIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the index value that uniquely identifies a WLAN Profile Interface. The interface identified by a particular value of this index is the same interface as identified by the same value of the ifIndex. The creation of a row object in the capwapDot11WlanTable triggers the AC to automatically create an WLAN Profile Interface identified by an ifIndex without manual intervention. Most MIB tables in the IEEE 802.11 MIB module [IEEE.802-11.2007] use an ifIndex to identify an interface to facilitate the configuration and maintenance, for example, dot11AuthenticationAlgorithmsTable. Using the ifIndex of a WLAN Profile Interface, the Operator could configure a WLAN through the IEEE 802.11 MIB module." ::= { capwapDot11WlanEntry 2 } capwapDot11WlanMacType OBJECT-TYPE SYNTAX CapwapBaseMacTypeTC MAX-ACCESS read-create STATUS current DESCRIPTION "Represents whether the WTP SHOULD support the WLAN in Local or Split MAC modes." REFERENCE "Section 6.1 of CAPWAP Protocol Binding for IEEE 802.11, RFC 5416." ::= { capwapDot11WlanEntry 3 } capwapDot11WlanTunnelMode OBJECT-TYPE SYNTAX CapwapBaseTunnelModeTC MAX-ACCESS read-create STATUS current DESCRIPTION "Represents the frame tunneling mode to be used for IEEE 802.11 data frames from all stations associated with the WLAN. Bits are exclusive with each other for a specific WLAN profile, and only one tunnel mode could be configured. If the operator set more than one bit, the value of the Response-PDU's error-status field is set to 'wrongValue', and the value of its error-index field is set to the index of the failed variable binding." REFERENCE "Section 6.1 of CAPWAP Protocol Binding for IEEE 802.11, Shi, et al. Informational PAGE 17 top

RFC 5834 CAPWAP Protocol Binding MIB May 2010 RFC 5416." ::= { capwapDot11WlanEntry 4 } capwapDot11WlanRowStatus 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. All the objects in a row can be modified only when the value of this object in the corresponding conceptual row is not 'active'. Thus, to modify one or more of the objects in this conceptual row: a. change the row status to 'notInService', b. change the values of the row c. change the row status to 'active' The capwapDot11WlanRowStatus may be changed to 'active' if all the managed objects in the conceptual row with MAX-ACCESS read-create have been assigned valid values. When the operator deletes a WLAN profile, the AC SHOULD check whether the WLAN profile is bound with a radio. If yes, the value of the Response-PDU's error-status field is set to 'inconsistentValue', and the value of its error-index field is set to the index of the failed variable binding. If not, the row object could be deleted." ::= { capwapDot11WlanEntry 5 } -- End of capwapDot11WlanTable Table -- capwapDot11WlanBindTable Table capwapDot11WlanBindTable OBJECT-TYPE SYNTAX SEQUENCE OF CapwapDot11WlanBindEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table that stores bindings between WLAN profiles (identified by capwapDot11WlanProfileId) and WTP Virtual Radio Interfaces. The WTP Virtual Radio Interfaces on the AC correspond to physical layer (PHY) radios on the WTPs. It also stores the mappings between WLAN IDs and WLAN Basic Service Set (BSS) Interfaces. Values of all objects in this table are persistent at restart/reboot." REFERENCE Shi, et al. Informational PAGE 18 top

RFC 5834 CAPWAP Protocol Binding MIB May 2010 "Section 6.1 of CAPWAP Protocol Binding for IEEE 802.11, RFC 5416." ::= { capwapDot11Objects 2 } capwapDot11WlanBindEntry OBJECT-TYPE SYNTAX CapwapDot11WlanBindEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that stores the binding of a WLAN profile to a WTP Virtual Radio Interface. It also stores the mapping between WLAN ID and WLAN BSS Interface. The INDEX object ifIndex is the ifIndex of a WTP Virtual Radio Interface." INDEX { ifIndex, capwapDot11WlanProfileId } ::= { capwapDot11WlanBindTable 1 } CapwapDot11WlanBindEntry ::= SEQUENCE { capwapDot11WlanBindWlanId CapwapDot11WlanIdTC, capwapDot11WlanBindBssIfIndex InterfaceIndex, capwapDot11WlanBindRowStatus RowStatus } capwapDot11WlanBindWlanId OBJECT-TYPE SYNTAX CapwapDot11WlanIdTC MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the WLAN ID of a WLAN. During a binding operation, the AC MUST select an unused WLAN ID from between 1 and 16 [RFC 5416]. For example, to bind another WLAN profile to a radio that has been bound with a WLAN profile, WLAN ID 2 should be assigned." REFERENCE "Section 6.1 of CAPWAP Protocol Binding for IEEE 802.11, RFC 5416." ::= { capwapDot11WlanBindEntry 1 } capwapDot11WlanBindBssIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the index value that uniquely identifies a WLAN BSS Interface. The interface identified by a particular value of this index is the same interface as identified by the same value of the ifIndex. Shi, et al. Informational PAGE 19 top

RFC 5834 CAPWAP Protocol Binding MIB May 2010 The ifIndex here is for a WLAN BSS Interface. The creation of a row object in the capwapDot11WlanBindTable triggers the AC to automatically create a WLAN BSS Interface identified by an ifIndex without manual intervention. The PHY address of the capwapDot11WlanBindBssIfIndex is the BSSID. While manufacturers are free to assign BSSIDs by using any arbitrary mechanism, it is advised that where possible the BSSIDs are assigned as a contiguous block. When assigned as a block, implementations can still assign any of the available BSSIDs to any WLAN. One possible method is for the WTP to assign the address using the following algorithm: base BSSID address + WLAN ID." REFERENCE "Section 2.4 of CAPWAP Protocol Binding for IEEE 802.11, RFC 5416." ::= { capwapDot11WlanBindEntry 2 } capwapDot11WlanBindRowStatus 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. All the objects in a row can be modified only when the value of this object in the corresponding conceptual row is not 'active'. Thus, to modify one or more of the objects in this conceptual row: a. change the row status to 'notInService', b. change the values of the row c. change the row status to 'active'" ::= { capwapDot11WlanBindEntry 3 } -- End of capwapDot11WlanBindTable Table -- Module compliance capwapDot11Groups OBJECT IDENTIFIER ::= { capwapDot11Conformance 1 } capwapDot11Compliances OBJECT IDENTIFIER ::= { capwapDot11Conformance 2 } capwapDot11Compliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the Shi, et al. Informational PAGE 20 top

RFC 5834 CAPWAP Protocol Binding MIB May 2010 CAPWAP-DOT11-MIB module." MODULE -- this module MANDATORY-GROUPS { capwapDot11WlanGroup, capwapDot11WlanBindGroup } ::= { capwapDot11Compliances 1 } capwapDot11WlanGroup OBJECT-GROUP OBJECTS { capwapDot11WlanProfileIfIndex, capwapDot11WlanMacType, capwapDot11WlanTunnelMode, capwapDot11WlanRowStatus } STATUS current DESCRIPTION "A collection of objects that is used to configure the properties of a WLAN profile." ::= { capwapDot11Groups 1 } capwapDot11WlanBindGroup OBJECT-GROUP OBJECTS { capwapDot11WlanBindWlanId, capwapDot11WlanBindBssIfIndex, capwapDot11WlanBindRowStatus } STATUS current DESCRIPTION "A collection of objects that is used to bind the WLAN profiles with a radio." ::= { capwapDot11Groups 2 } END 10. 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 following are the tables and objects and their sensitivity/vulnerability: Shi, et al. Informational PAGE 21 top

RFC 5834 CAPWAP Protocol Binding MIB May 2010 o Unauthorized changes to the capwapDot11WlanTable and capwapDot11WlanBindTable MAY disrupt allocation of resources in the network, and also change the behavior of the WLAN system such as MAC type. 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 [RFC 3410], 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. 11. IANA Considerations 11.1. IANA Considerations for CAPWAP-DOT11-MIB Module The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER value recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- capwapDot11MIB { mib-2 195 } 11.2. IANA Considerations for ifType IANA has assigned the following ifTypes: Decimal Name Description ------- ------------ ------------------------------- 252 capwapDot11Profile WLAN Profile Interface 253 capwapDot11Bss WLAN BSS Interface 12. Contributors This MIB module is based on contributions from Long Gao. Shi, et al. Informational PAGE 22 top

RFC 5834 CAPWAP Protocol Binding MIB May 2010 13. Acknowledgements Thanks to David Harrington, Dan Romascanu, Abhijit Choudhury, and Elwyn Davies for helpful comments on this document and guiding some technical solutions. The authors also thank their friends and coworkers Fei Fang, Xuebin Zhu, Hao Song, Yu Liu, Sachin Dutta, Ju Wang, Yujin Zhao, Haitao Zhang, Xiansen Cai, and Xiaolan Wan. 14. References 14.1. Normative References [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 (PHY) specifications", IEEE Standard 802.11, 2007, <htt p://standards.ieee.org/getieee802/download/ 802.11-2007.pdf>. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC 2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC 2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC 2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC 3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. Shi, et al. Informational PAGE 23 top

RFC 5834 CAPWAP Protocol Binding MIB May 2010 [RFC 5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, March 2009. [RFC 5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11", RFC 5416, March 2009. [RFC 5833] Shi, Y., Ed., Perkins, D., Ed., Elliott, C., Ed., and Y. Zhang, Ed., "Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Base MIB", RFC 5833, May 2010. 14.2. Informative References [RFC 3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC 4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. Shi, et al. Informational PAGE 24 top

RFC 5834 CAPWAP Protocol Binding MIB May 2010 Authors' Addresses Yang Shi (editor) Hangzhou H3C Tech. Co., Ltd. Beijing R&D Center of H3C, Digital Technology Plaza NO. 9 Shangdi 9th Street, Haidian District Beijing 100085 China Phone: +86 010 82775276 EMail: rishyang@gmail.com David T. Perkins (editor) 228 Bayview Dr. San Carlos, CA 94070 USA Phone: +1 408 394-8702 EMail: dperkins@dsperkins.com Chris Elliott (editor) 1516 Kent St. Durham, NC 27707 USA Phone: +1 919-308-1216 EMail: chelliot@pobox.com Yong Zhang (editor) Fortinet, Inc. 1090 Kifer Road Sunnyvale, CA 94086 USA EMail: yzhang@fortinet.com Shi, et al. Informational PAGE 25 top

Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding MIB for IEEE 802.11 RFC TOTAL SIZE: 51144 bytes PUBLICATION DATE: Thursday, May 6th, 2010 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 5834: The IETF Trust, Thursday, May 6th, 2010
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement