RFC 5834

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

๐Ÿ“… published May 2010, from ietf

RFC 5834: Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding MIB for IEEE 802.11 ๐ŸŽ€

okay so this is the RFC babe, and it's giving Informational ๐Ÿ’… It's from the IETF, dated May 2010, and its ISSN is 2070-1721. The authors are Y. Shi (Ed.) from Hangzhou H3C Tech. Co., Ltd., D. Perkins (Ed.) and C. Elliott (Ed.), and Y. Zhang (Ed.) from Fortinet, Inc. The header doesn't have any "Obsoletes" or "Updates" line, so it isn't replacing or changing anything else ๐Ÿซถ

Abstract โœจ

okay so the main point: this memo defines a chunk of a Management Information Base (MIB) for network management protocols ๐Ÿงš It's all about modeling the Control And Provisioning of Wireless Access Points (CAPWAP) protocol for the IEEE 802.11 wireless binding. It's presented as a starting point for future work on managing CAPWAP with the Simple Network Management Protocol (SNMP) ๐Ÿ’œ

Status of This Memo ๐ŸŒธ

this one is literally not an Internet Standards Track spec, it's just published for info ๐Ÿ™ˆ It's still a product of the IETF and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the deets ๐Ÿ”ฅ

info about the current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc5834 ๐Ÿฆ‹

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

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Read them carefully, because they explain your rights and restrictions ๐Ÿ’… Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're 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

1. Introduction ๐ŸŒˆ

okay so the CAPWAP protocol [RFC5415] is a standard, interoperable protocol that lets an Access Controller (AC) manage a bunch of Wireless Termination Points (WTPs) ๐Ÿ’… CAPWAP works with different wireless techs on the WTPs, and the one specified in the CAPWAP Protocol Binding for IEEE 802.11 [RFC5416] is the one we care about here โœจ

this doc defines a MIB module you can use to manage CAPWAP implementations for the IEEE 802.11 wireless binding ๐Ÿฆ‹ It covers configuration for Wireless Local Area Networks (WLANs) and also a way to reuse the IEEE 802.11 MIB module [IEEE.802-11.2007]. Again, it's presented as a basis for future SNMP management of CAPWAP ๐Ÿซถ

2. The Internet-Standard Management Framework ๐Ÿงš

if you want the full tour of the current Internet-Standard Management Framework, go check section 7 of RFC 3410 [RFC3410] ๐Ÿ’œ

managed objects get accessed through a virtual information store called the Management Information Base, or MIB ๐Ÿ“ MIB objects are usually reached through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms in the Structure of Management Information (SMI). This memo specifies a MIB module that's compliant with SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579], and STD 58, RFC 2580 [RFC2580] ๐Ÿ”ฅ

3. Terminology ๐Ÿ’…

this doc uses terminology from the CAPWAP protocol spec [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 โœจ

Control And Provisioning of Wireless Access Points (CAPWAP): It's 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: CAPWAP 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 CAPWAP and exchanged between the AC and the WTPs. Local MAC mode lets data frames be either locally bridged or tunneled as 802.3 frames ๐Ÿ’œ

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

Wireless Binding is the big one: every CAPWAP implementation for a wireless tech MUST come with its own binding protocol, no skipping ๐Ÿ’€

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. Supporting a physical WTP with multiple WLANs is an important feature for the CAPWAP 802.11 binding, and it's also important 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]. Those MIB modules are called wireless binding MIB modules ๐Ÿงš

CAPWAP Protocol Wireless Binding MIB Module: This 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 out of scope for IEEE 802.11 [IEEE.802-11.2007]. In those cases, on top of 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 config parameters like 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's already 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 those MIB objects in the IEEE 802.11 MIB module, and MUST support functions (like MAC mode for WLAN in [RFC5416]) that aren't in the scope of the IEEE 802.11 standard. So the CAPWAP-DOT11-MIB module MUST support those functions too ๐Ÿ‘‘

in summary, the CAPWAP-DOT11-MIB module needs to support:

  • Reuse of wireless binding MIB modules in the IEEE 802.11 standard;
  • 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 โœจ

okay so, in the IEEE 802.11 MIB module, tables like dot11AuthenticationAlgorithmsTable can totally handle WLAN config (like which authentication algorithm you're using) ๐Ÿ”, and they use ifIndex as the index. That works super well in the autonomous WLAN architecture ๐Ÿ’…

Reusing these wireless binding MIB modules is very important for centralized WLAN architectures ๐Ÿ‘‘. The key move is to treat a WLAN profile as a WLAN Profile Interface on the AC, and that interface gets its own ifIndex. The MIB objects in the IEEE 802.11 MIB module that are associated with this interface can then be used to configure WLAN parameters for the WLAN, like the authentication algorithm. So 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 ๐Ÿ“ก. Each radio also has a matching WTP Virtual Radio Interface on the AC. The IEEE 802.11 MIB module associated with that interface can configure IEEE 802.11 wireless binding parameters for the radio, like the RTS Threshold. Then there's the WLAN Basic Service Set (BSS) Interface, which gets created when you bind a WLAN to a WTP Virtual Radio Interface, and it's what handles the data forwarding ๐ŸŒˆ


6. Structure of MIB Module ๐Ÿงš

The MIB objects are derived from the CAPWAP protocol binding for IEEE 802.11 document [RFC5416]. Here's the vibe of the two main tables ๐Ÿ’–

capwapDot11WlanTable

This table lets the operator display and configure WLAN profiles, like specifying the MAC type and tunnel mode for a WLAN. It also helps the AC configure a WLAN through the IEEE 802.11 MIB module ๐ŸŽ€

capwapDot11WlanBindTable

This table gives you 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, and that interface 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 are defined as mandatory for all systems. Those objects apply to the entity as a whole ๐Ÿซถ The 'system' group handles identification of the management entity and certain other system-wide data, so this module doesn't need to repeat it ๐Ÿ™ˆ

7.2. Relationship to IF-MIB Module

The Interfaces Group [RFC2863] defines generic managed objects for managing interfaces ๐Ÿ”Œ This memo adds the media-specific extensions to the Interfaces Group for managing WLANs that are modeled as interfaces. It's giving modular โœจ

Each WLAN profile corresponds to a WLAN Profile Interface on the AC. The interface MUST be modeled as an ifEntry, and ifEntry objects like ifIndex, ifDescr, ifName, and ifAlias are to be used as per [RFC2863]. The WLAN Profile Interface gives you a way to configure IEEE 802.11 parameters for a specific WLAN and reuse the IEEE 802.11 MIB module ๐Ÿง 

To provide the data forwarding service, the AC dynamically creates WLAN BSS Interfaces ๐Ÿš€ A WLAN BSS Interface MUST be modeled as an ifEntry, and the same ifEntry objects (ifIndex, ifDescr, ifName, and ifAlias) are to be used as per [RFC2863]. This is the part that lets a single physical WTP support multiple WLANs, which is lowkey iconic ๐Ÿ‘‘

Also, the AC MUST have a mechanism that preserves the values of the ifIndexes (of both the WLAN Profile Interfaces and the WLAN BSS Interfaces) in the ifTable at AC reboot. Non-negotiable, bestie ๐Ÿ˜ญ๐Ÿ’…

7.3. Relationship to CAPWAP-BASE-MIB Module

The CAPWAP-BASE-MIB module gives you a way to manage and control WTP and radio objects ๐Ÿ› ๏ธ Especially, it provides the WTP Virtual Radio Interface mechanism, which lets the AC reuse the IEEE 802.11 MIB module. Thanks to this, an operator can configure an IEEE 802.11 radio's parameters and view the radio's traffic statistics on the AC ๐Ÿ“Š Building on the CAPWAP-BASE-MIB module, the CAPWAP-DOT11-MIB module provides even more WLAN information ๐ŸŒธ

7.4. Relationship to MIB Module in the IEEE 802.11 Standard

With the ifIndex of a WLAN Profile Interface and a 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. Even though the CAPWAP-DOT11-MIB module uses [RFC5416] as a reference, it could reuse all the MIB objects in the IEEE 802.11 standard, and it isn't limited to the scope of the 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 โœจ

okay so this section is a full walkthrough of how an operator sets everything up, start to finish ๐ŸŽ€ it's giving tutorial energy and honestly it's so satisfying to watch it all click together ๐Ÿซถ

1) Create a WTP profile. ๐Ÿ’–

So the WTP's base MAC address is '00:01:01:01:01:00'. You make a WTP profile for it in the capwapBaseWtpProfileTable [RFC5833] like this:

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

Suppose the WTP with model number 'WTP123' has one PHY radio, and that radio is identified by ID 1. Creating this WTP profile triggers the AC to automatically create a WTP Virtual Radio Interface and add a new row object to the capwapBaseWirelessBindingTable, all without manual intervention ๐Ÿค–โœจ Suppose the ifIndex of the WTP Virtual Radio Interface is 10. The following information then gets stored in the capwapBaseWirelessBindingTable:

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

The WTP Virtual Radio Interfaces on the AC line up with the PHY radios on the WTP. The WTP Virtual Radio Interface is modeled by ifTable [RFC2863], so it shows up there too:

In ifTable
{
  ifIndex              = 10,
  ifDescr              = 'WTP Virtual Radio Interface',
  ifType               = 254,
  ifMtu                = 0,
  ifSpeed              = 0,
  ifPhysAddress        = '00:00:00:00:00:00',
  ifAdminStatus        = true(1),
  ifOperStatus         = false(0),
  ifLastChange         = 0,
  ifInOctets           = 0,
  ifInUcastPkts        = 0,
  ifInDiscards         = 0,
  ifInErrors           = 0,
  ifInUnknownProtos    = 0,
  ifOutOctets          = 0,
  ifOutUcastPkts       = 0,
  ifOutDiscards        = 0,
  ifOutErrors          = 0
}

2) Query the ifIndexes of WTP Virtual Radio Interfaces. ๐Ÿ”

Before configuring PHY radios, the operator needs the ifIndexes of the WTP Virtual Radio Interfaces that match those radios.

Good news: the capwapBaseWirelessBindingTable already stores the mappings between PHY radios (Radio IDs) and the ifIndexes of the WTP Virtual Radio Interfaces, so the operator just queries that table. The query SHOULD run from radio ID 1 to radio ID 31 (according to [RFC5415]), and it stops when an invalid ifIndex value (0) comes back ๐Ÿ›‘

In this example, capwapBaseWtpProfileId = 1 and capwapBaseWirelessBindingRadioId = 1 go in as inputs, and the table gives back capwapBaseWirelessBindingVirtualRadioIfIndex = 10. Next, capwapBaseWtpProfileId = 1 with capwapBaseWirelessBindingRadioId = 2 returns an invalid ifIndex value (0), so the query ends there. This method gets you the ifIndexes of the WTP Virtual Radio Interfaces and the number of PHY radios, which is a double win ๐Ÿ™Œ 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 part happens on the AC, through the IEEE 802.11 MIB module. Here's an example of setting parameters for the 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,
  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 happens on the AC through the CAPWAP-DOT11-MIB module and the IEEE 802.11 MIB module, so it's a two-part glow-up ๐Ÿ’…

Step one is making a WLAN Profile Interface through the CAPWAP-DOT11-MIB module on the AC. Say you configure a WLAN profile identified by capwapDot11WlanProfileId 1. The capwapDot11WlanTable then creates this row object for it:

In capwapDot11WlanTable
{
  capwapDot11WlanProfileId          = 1,
  capwapDot11WlanProfileIfIndex     = 20,
  capwapDot11WlanMacType            = splitMAC(2),
  capwapDot11WlanTunnelMode         = dot3Tunnel(2),
  capwapDot11WlanRowStatus          = createAndGo(4)
}

Creating that row triggers the AC to automatically create a WLAN Profile Interface, 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 keeps track of the mappings between capwapDot11WlanProfileIds and the ifIndexes of WLAN Profile Interfaces.

The ifEntry is the bit that makes the interface real in the ifTable, so don't skip it ๐Ÿ‘€
In ifTable
{
  ifIndex              = 20,
  ifDescr              = 'WLAN Profile Interface',
  ifType               = 252,
  ifMtu                = 0,
  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
}

Step two is setting WLAN parameters for that WLAN Profile Interface through the IEEE 802.11 MIB module on the AC. This example sets an authentication algorithm for the WLAN:

In dot11AuthenticationAlgorithmsTable
{
  ifIndex                                = 20,
  dot11AuthenticationAlgorithmsIndex     = 1,
  dot11AuthenticationAlgorithm           = Shared Key(2),
  dot11AuthenticationAlgorithmsEnable    = true(1)
}

Here, ifIndex 20 points at 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 ifIndex).

Say the operator binds the WLAN profile with capwapDot11WlanProfileId 1 to the WTP Virtual Radio Interface with ifIndex 10. The capwapDot11WlanBindTable then creates this row object:

In capwapDot11WlanBindTable
{
  ifIndex                          = 10,
  capwapDot11WlanProfileId         = 1,
  capwapDot11WlanBindBssIfIndex    = 30,
  capwapDot11WlanBindRowStatus     = createAndGo(4)
}

If the capwapDot11WlanMacType of the WLAN is splitMAC(2), creating that row triggers the AC to automatically create a WLAN BSS Interface identified by ifIndex 30, again with no 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, the WLAN profile ID, the WLAN ID, and the ifIndex of a WLAN BSS Interface. Iconic table, honestly ๐ŸŒธ

6) Get the current configuration status report from the WTP to the AC. ๐Ÿ“

Before a WTP that has joined the AC gets any configuration from it, the WTP reports its current configuration status by sending a configuration status request message to the AC. The AC uses that message to update the matching MIB objects. For example, for ifIndex 10 (which identifies a WLAN Virtual Radio Interface), its ifOperStatus in the ifTable gets updated based on the current radio operational status in the CAPWAP message [RFC5415]. Keeping things in sync, bestie ๐Ÿซถ

7) Query WTP and radio statistical data. ๐Ÿ“Š

Once WTPs start running, the operator can query WTP and radio statistics through the CAPWAP-BASE-MIB and CAPWAP-DOT11-MIB modules. For example, through the dot11CountersTable [IEEE.802-11.2007], the operator can pull counter data for a radio identified by the ifIndex of the matching WLAN Virtual Radio Interface.

8) Query other statistical data. ๐Ÿง

The operator can check a WLAN's configuration through the dot11AuthenticationAlgorithmsTable [IEEE.802-11.2007], and check the statistical data of a WLAN BSS Interface through the ifTable [RFC2863]. Full data collection era ๐Ÿ’œ


9. Definitions ๐ŸŒˆ

Here's the MIB module itself, the official source of truth for all the objects we just walked through ๐Ÿ’–

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;

More of the MIB module is coming in the next part, so stay tuned ๐Ÿฆ‹

Okay bestie, the MIB module itself is where it gets really good ๐ŸŽ€ Here's the module identity, with the authors, copyright, and revision info:

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
         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 }

Next up are the textual conventions, which are basically the custom data types the module reuses. These are the WLAN ID and the WLAN profile ID ๐Ÿ’…

-- 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
capwapDot11Objects OBJECT IDENTIFIER
    ::= { capwapDot11MIB 1 }
-- Conformance
capwapDot11Conformance OBJECT IDENTIFIER
    ::= { capwapDot11MIB 2 }

Now the capwapDot11WlanTable, which is where you set up WLAN profiles. It's giving "profile glow-up" ๐ŸŒธ The row structure and each column come next:

-- 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 }

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,

         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

Last bit for this part: the capwapDot11WlanBindTable, which is the binding table linking WLAN profiles to the WTP Virtual Radio Interfaces. It's the relationship goals ๐Ÿฆ‹ The sections follow in the next part:

-- 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

        "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.

         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

         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

Okay bestie, that's the whole MIB module wrapped up ๐Ÿ’– Those groups are how the compliance statement lines everything up, so it's giving tidy and organised ๐ŸŽ€


10. Security Considerations ๐Ÿ”

Okay so this part is seriously important, bestie ๐Ÿฅบ There are a bunch of management objects in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Those objects MAY be considered sensitive or vulnerable in some network environments ๐Ÿ™ˆ Letting people SET things without proper protection can seriously mess with network operations ๐Ÿ’€ Here's the tea on which tables and objects are sensitive:

  • 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 before SNMPv3 didn't have adequate security, no cap ๐Ÿ™…โ€โ™€๏ธ Even if the network itself is secure (like by using IPSec), there's still no control over who on that secure network gets to GET/SET (read/change/create/delete) the objects in this MIB module ๐Ÿ’…

Implementers, it is RECOMMENDED that you look at the security features the SNMPv3 framework provides (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy) ๐Ÿ”’โœจ

Further, deploying SNMP versions before SNMPv3 is NOT RECOMMENDED ๐Ÿšซ Instead, it is RECOMMENDED to deploy SNMPv3 and turn on cryptographic security ๐Ÿงš It's then a customer/operator responsibility to make sure the SNMP entity giving access to an instance of this MIB module is set up so only principals (users) with legitimate rights can GET or SET (change/create/delete) those objects. Main character energy for security, periodt ๐Ÿ‘‘


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 ๐Ÿซถ

13. Acknowledgements ๐Ÿฅน

Thanks to David Harrington, Dan Romascanu, Abhijit Choudhury, and Elwyn Davies for helpful comments on this document and for 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, http://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.
  • [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.

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
๐Ÿ“ฆ where this page comes from