summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5834.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5834.txt')
-rw-r--r--doc/rfc/rfc5834.txt1403
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc5834.txt b/doc/rfc/rfc5834.txt
new file mode 100644
index 0000000..a6daa08
--- /dev/null
+++ b/doc/rfc/rfc5834.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+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/rfc5834.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shi, et al. Informational [Page 1]
+
+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]
+
+RFC 5834 CAPWAP Protocol Binding MIB May 2010
+
+
+1. Introduction
+
+ The CAPWAP protocol [RFC5415] defines a standard, interoperable
+ protocol, which enables an Access Controller (AC) to manage a
+ collection of Wireless Termination Points (WTPs). CAPWAP supports
+ the use of various wireless technologies by the WTPs, with one
+ specified in the CAPWAP Protocol Binding for IEEE 802.11 [RFC5416].
+
+ 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 [RFC3410].
+
+ Managed objects are accessed via a virtual information store, termed
+ the Management Information Base or MIB. MIB objects are generally
+ accessed through the Simple Network Management Protocol (SNMP).
+ Objects in the MIB are defined using the mechanisms defined in the
+ Structure of Management Information (SMI). This memo specifies a MIB
+ module that is compliant to the SMIv2, which is described in STD 58,
+ RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579], and STD 58, RFC 2580
+ [RFC2580].
+
+3. Terminology
+
+ This document uses terminology from the CAPWAP protocol specification
+ [RFC5415], the CAPWAP Protocol Binding for IEEE 802.11 [RFC5416], and
+ the CAPWAP Protocol Base MIB [RFC5833].
+
+ 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]
+
+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) [RFC4347].
+
+ CAPWAP Control Channel: A bi-directional flow defined by the AC IP
+ Address, WTP IP Address, AC control port, WTP control port, and the
+ transport-layer protocol (UDP or UDP-Lite) over which CAPWAP control
+ packets are sent and received.
+
+ CAPWAP Data Channel: A bi-directional flow defined by the AC IP
+ Address, WTP IP Address, AC data port, WTP data port, and the
+ transport-layer protocol (UDP or UDP-Lite) over which CAPWAP data
+ packets are sent and received.
+
+ Station (STA): A device that contains an interface to a wireless
+ medium (WM).
+
+ Split and Local MAC: The CAPWAP protocol supports two modes of
+ operation: Split and Local MAC (medium access control). In Split MAC
+ mode, all Layer 2 wireless data and management frames are
+ encapsulated via the CAPWAP protocol and exchanged between the AC and
+ the WTPs. The Local MAC mode 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 [RFC5416].
+
+ 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]
+
+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 [RFC5416] 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 [RFC2119].
+
+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 [RFC5416]. 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 [RFC5416]. 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 [RFC5416]) 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]
+
+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 [RFC5416].
+
+ 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]
+
+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 [RFC3418] that is defined as being
+ mandatory for all systems, and the objects apply to the entity as a
+ whole. The 'system' group provides identification of the management
+ entity and certain other system-wide data.
+
+7.2. Relationship to IF-MIB Module
+
+ The Interfaces Group [RFC2863] defines generic managed objects for
+ managing interfaces. This memo contains the media-specific
+ extensions to the Interfaces Group for managing 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
+ [RFC2863]. 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 [RFC2863]. 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]
+
+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 [RFC5416] involves some
+ of the MIB objects defined in the IEEE 802.11 standard. Although
+ CAPWAP-DOT11-MIB module uses it [RFC5416] 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
+ [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], IF-MIB
+ [RFC2863], and CAPWAP-BASE-MIB [RFC5833].
+
+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
+ [RFC5833] 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]
+
+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 [RFC2863].
+
+ In ifTable
+ {
+ ifIndex = 10,
+ ifDescr = 'WTP Virtual Radio Interface',
+ ifType = 254,
+ ifMtu = 0,
+ ifSpeed = 0,
+ ifPhysAddress = '00:00:00:00:00:00',
+ ifAdminStatus = true(1),
+ ifOperStatus = false(0),
+ ifLastChange = 0,
+ ifInOctets = 0,
+ ifInUcastPkts = 0,
+ ifInDiscards = 0,
+ ifInErrors = 0,
+ ifInUnknownProtos = 0,
+ ifOutOctets = 0,
+ ifOutUcastPkts = 0,
+ ifOutDiscards = 0,
+ ifOutErrors = 0
+ }
+
+
+
+
+Shi, et al. Informational [Page 9]
+
+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 [RFC5415]), and stop when an
+ invalid ifIndex value (0) is returned.
+
+ This example uses capwapBaseWtpProfileId = 1 and
+ capwapBaseWirelessBindingRadioId = 1 as inputs to query the
+ capwapBaseWirelessBindingTable, and gets
+ capwapBaseWirelessBindingVirtualRadioIfIndex = 10. Then it uses
+ capwapBaseWtpProfileId = 1 and capwapBaseWirelessBindingRadioId =
+ 2, and gets an invalid ifIndex value (0), so the query operation
+ ends. This method gets not only the ifIndexes of WTP Virtual
+ Radio Interfaces, but also the numbers of PHY radios. Besides
+ checking whether the ifIndex value is valid, the operator SHOULD
+ check whether the capwapBaseWirelessBindingType is the desired
+ binding type.
+
+ 3) Configure 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]
+
+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]
+
+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]
+
+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
+ [RFC5415].
+
+ 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
+ [RFC2863].
+
+
+
+
+
+Shi, et al. Informational [Page 13]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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 [RFC5416]. 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]
+
+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]
+
+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]
+
+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 [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.
+
+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]
+
+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>.
+
+ [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., "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.
+
+ [RFC3418] 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]
+
+RFC 5834 CAPWAP Protocol Binding MIB May 2010
+
+
+ [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley,
+ "Control And Provisioning of Wireless Access
+ Points (CAPWAP) Protocol Specification",
+ RFC 5415, March 2009.
+
+ [RFC5416] 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.
+
+ [RFC5833] 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
+
+ [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
+ "Introduction and Applicability Statements for
+ Internet-Standard Management Framework",
+ RFC 3410, December 2002.
+
+ [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport
+ Layer Security", RFC 4347, April 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shi, et al. Informational [Page 24]
+
+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]
+