tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5833

Informational
Pages: 73
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: CAPWAP

Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Base MIB

Part 1 of 4, p. 1 to 14
None       Next RFC Part

 


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

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


  Control and Provisioning of Wireless Access Points (CAPWAP) Protocol
                                Base MIB

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols.  In particular, it
   describes the managed objects for modeling the Control And
   Provisioning of Wireless Access Points (CAPWAP) Protocol.  This MIB
   module is presented as a basis for future work on the SNMP management
   of the CAPWAP protocol.

Status of This Memo

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

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

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

Page 2 
Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The Internet-Standard Management Framework . . . . . . . . . .  3
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   5.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     5.1.  Requirements and Constraints . . . . . . . . . . . . . . .  5
     5.2.  Wireless Binding MIB Modules . . . . . . . . . . . . . . .  5
     5.3.  Design Objectives  . . . . . . . . . . . . . . . . . . . .  5
     5.4.  Design Idea  . . . . . . . . . . . . . . . . . . . . . . .  6
     5.5.  Mechanism of Reusing Wireless Binding MIB Modules  . . . .  6
     5.6.  CAPWAP Protocol Wireless Binding MIB Module  . . . . . . .  7
     5.7.  WTP Profile  . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Structure of the MIB Module  . . . . . . . . . . . . . . . . .  8
   7.  Relationship to Other MIB Modules  . . . . . . . . . . . . . .  9
     7.1.  Relationship to SNMPv2-MIB Module  . . . . . . . . . . . .  9
     7.2.  Relationship to IF-MIB Module  . . . . . . . . . . . . . .  9
     7.3.  Relationship to ENTITY-MIB Module  . . . . . . . . . . . . 10
     7.4.  Relationship to Wireless Binding MIB Modules . . . . . . . 10
     7.5.  MIB Modules Required for IMPORTS . . . . . . . . . . . . . 10
   8.  Example of CAPWAP-BASE-MIB Module Usage  . . . . . . . . . . . 10
   9.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . . 14
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 69
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 70
     11.1. IANA Considerations for CAPWAP-BASE-MIB Module . . . . . . 70
     11.2. IANA Considerations for ifType . . . . . . . . . . . . . . 70
   12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 70
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 71
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 71
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 71
     14.2. Informative References . . . . . . . . . . . . . . . . . . 72

Top      ToC       Page 3 
1.  Introduction

   The CAPWAP Protocol [RFC5415] defines a standard, interoperable
   protocol, which enables an Access Controller (AC) to manage a
   collection of Wireless Termination Points (WTPs).

   This document defines a MIB module that can be used to manage the
   CAPWAP implementations.  This MIB module covers both configuration
   and WTP status-monitoring aspects of CAPWAP, and provides a way to
   reuse MIB modules for any wireless technology.  It presented as a
   basis for future work on a SNMP management of the CAPWAP protocol.

2.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579], and STD 58, RFC 2580
   [RFC2580].

3.  Terminology

   This document uses terminology from the CAPWAP Protocol specification
   [RFC5415] and the Architecture Taxonomy for CAPWAP [RFC4118].

   Access Controller (AC): The network entity that provides WTP access
   to the network infrastructure in the data plane, control plane,
   management plane, or a combination therein.

   Wireless Termination Point (WTP): The physical or network entity that
   contains an radio frequency (RF) antenna and wireless physical layer
   (PHY) to transmit and receive station traffic for wireless access
   networks.

   Control And Provisioning of Wireless Access Points (CAPWAP): It is a
   generic protocol defining AC and WTP control and data plane
   communication via a CAPWAP protocol transport mechanism.  CAPWAP
   control messages, and optionally CAPWAP data messages, are secured
   using Datagram Transport Layer Security (DTLS) [RFC4347].

Top      ToC       Page 4 
   CAPWAP Control Channel: A bi-directional flow defined by the AC IP
   Address, WTP IP Address, AC control port, WTP control port, and the
   transport-layer protocol (UDP or UDP-Lite) over which CAPWAP control
   packets are sent and received.

   CAPWAP Data Channel: A bi-directional flow defined by the AC IP
   Address, WTP IP Address, AC data port, WTP data port, and the
   transport-layer protocol (UDP or UDP-Lite) over which CAPWAP data
   packets are sent and received.

   Station (STA): A device that contains an interface to a wireless
   medium (WM).

   Split and Local MAC: The CAPWAP protocol supports two modes of
   operation: Split and Local MAC (medium access control).  In Split MAC
   mode, all Layer 2 wireless data and management frames are
   encapsulated via the CAPWAP protocol and exchanged between the AC and
   the WTPs.  The Local MAC mode allows the data frames to be either
   locally bridged or tunneled as 802.3 frames.

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

   Autonomous Wireless Local Area Network (WLAN) Architecture: It is the
   traditional autonomous WLAN architecture, in which each WTP is a
   single physical device that implements all the wireless services.

   Centralized WLAN Architecture: It is an emerging hierarchical
   architecture utilizing one or more centralized controllers for
   managing a large number of WTP devices.  It can be said that the full
   wireless functions are implemented across multiple physical network
   devices, namely, the WTPs and ACs.

4.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Top      ToC       Page 5 
5.  Overview

5.1.  Requirements and Constraints

   The CAPWAP Protocol MIB module (CAPWAP-BASE-MIB) is designed to:

   -  Support centralized management and monitoring of WTPs from the AC
      in combination with the CAPWAP protocol;

   -  Allow operators to make configurations for WTPs before and after
      they connect to the AC;

   -  Support querying of CAPWAP protocol parameters;

   -  Support displaying of WTPs' current states and configurations;

   -  Provide basic property information about the AC, WTPs, radios, and
      stations, and their relationships;

   -  Provide counters for events on WTPs and radios such as reboot and
      hardware failure;

   -  Provide various notifications such as channel up and join failure.

5.2.  Wireless Binding MIB Modules

   Other Standards Development Organizations (SDOs), such as IEEE, have
   already defined MIB modules for a specific wireless technology, e.g.,
   IEEE 802.11 MIB module [IEEE.802-11.2007].  Such MIB modules are
   called wireless binding MIB modules.

5.3.  Design Objectives

   This document introduces a mechanism to avoid redefining MIB objects
   in the existing MIB modules for a specific wireless technology, in
   other words, a mechanism to reuse wireless binding MIB modules
   defined by other SDOs.

   In summary, the CAPWAP-BASE-MIB module has the following design
   objectives:

   -  To implement an architecture that uses SNMP for the management and
      control of wireless networks, and answering the operator's
      requirements for centralized management, whatever the wireless
      devices are configured and deployed (centralized, autonomous, or
      some mix);

   -  To be consistent with the CAPWAP protocol;

Top      ToC       Page 6 
   -  To be independent of any wireless technologies and be able to
      reuse wireless binding MIB modules defined by other SDOs;

   -  To enable interoperability between vendors;

   -  To meet the management requirements for the centralized WLAN
      architecture.

5.4.  Design Idea

   The basic design idea of the CAPWAP-BASE-MIB module is:

   -  The SNMP agent MUST be run on the AC devices and is not REQUIRED
      on the WTP devices.  It follows the same model as the CAPWAP
      protocol: Centralized Control.

   -  It is designed to accommodate the specific needs of each wireless
      technology in a standard way.  It is independent of any wireless
      technologies.

   -  The ifIndex [RFC2863] is used as a common index for corresponding
      interfaces in the CAPWAP-BASE-MIB and the MIB modules of specific
      wireless technologies.

   -  The operator could manage and control the centralized WLAN
      architectures using multiple MIB modules defined by multiple SDOs,
      while keeping them loosely coupled.

5.5.  Mechanism of Reusing Wireless Binding MIB Modules

   For any wireless technology, the configuration and management of
   radios are very important.  As usual, wireless binding MIB modules
   support radio management on their own.  For example, the MIB tables
   such as the dot11OperationTable [IEEE.802-11.2007] are able to
   support WTP radio configuration.  These tables use the ifIndex as the
   index, and work well under autonomous WLAN architecture.

   To reuse such wireless binding MIB modules is very important to
   centralized WLAN architectures.  According to [RFC5415], a specific
   PHY radio could be identified by the combination of the identifiers
   of the WTP and radio (WTP ID + Radio ID), so the key point is to make
   use of the ifIndex idea and find a way to maintain the mappings
   between 'WTP ID + radio ID' and the ifIndex.  As a generic mechanism,
   an ifIndex can identify an interface in an abstract way, and it does
   NOT care for the interface's PHY location (either on the WTP or AC).
   The AC can have WTP Virtual Radio Interfaces to logically represent
   PHY radios on the WTP.  From the operator's perspective, it appears
   that PHY radios are located on the AC, and the PHY location of the

Top      ToC       Page 7 
   WTP (radio) is hidden.  The operator can operate radios through MIB
   tables with the ifIndex of a WTP Virtual Radio Interface.  As a type
   of abstract interface, the WTP Virtual Radio Interface could be used
   by any wireless technology such as IEEE 802.11 and 802.16.  The
   capwapBaseWirelessBindingTable in the CAPWAP-BASE-MIB module is used
   to store the mappings between the 'WTP ID + Radio ID' and the
   ifIndex.

5.6.  CAPWAP Protocol Wireless Binding MIB Module

   According to the CAPWAP Protocol specification [RFC5415], when
   defining a binding for wireless technologies, the authors MUST
   include any necessary definitions for technology-specific messages
   and all technology-specific message elements for those messages.  A
   CAPWAP binding protocol is required for a specific wireless binding
   technology, e.g., the protocol of [RFC5416] for IEEE 802.11 binding.

   Sometimes, not all the technology-specific message elements in a
   CAPWAP binding protocol have MIB objects defined by other SDOs.  For
   example, the protocol of [RFC5416] defines WLAN management.  The WLAN
   refers to a logical component instantiated on a WTP device.  A single
   physical WTP MAY operate a number of WLANs.  Also, Local or Split MAC
   modes could be specified for a WLAN.  The MAC mode for a WLAN is not
   in the scope of IEEE 802.11 [IEEE.802-11.2007].  In such cases, in
   addition to the existing wireless binding MIB modules defined by
   other SDOs, a CAPWAP protocol wireless binding MIB module is required
   to be defined for a wireless binding, e.g, the CAPWAP Protocol
   Binding MIB for IEEE 802.11 [RFC5834].

5.7.  WTP Profile

   In a centralized WLAN architecture, a WTP profile is used to make
   configurations such as a static IP address for a WTP before and after
   it connects to the AC.  It MUST contain the Base MAC address
   [RFC5415] of the WTP because the CAPWAP message received from the WTP
   contains the Base MAC address and the AC uses this Base MAC address
   to find the corresponding WTP profile.

   Section 4.6.40 of [RFC5415] omits indicating that the WTP's Base MAC
   address MUST be included in the WTP Board Data message element.  This
   is a known errata item [Err1832] and should be fixed in any future
   revision of RFC 5415.

   Another important function of WTP profile is to trigger the creation
   of WTP Virtual Radio Interfaces on the AC.  To implement this
   function, a WTP profile MUST include the WTP's model number
   [RFC5415], which reflects the number of PHY radios on the WTP.  In
   this way, the creation of a WTP profile triggers the AC to

Top      ToC       Page 8 
   automatically create the same number of WTP Virtual Radio Interfaces
   corresponding to the WTP's PHY radios without manual intervention.
   With the ifIndexes of WTP Virtual Radio Interfaces, the operator
   could configure and manage the WTP's PHY radios through the wireless
   binding MIB modules.

6.  Structure of the MIB Module

   The MIB objects are derived from the CAPWAP protocol document
   [RFC5415].

   1) capwapBaseAcNameListTable

      The AC name list table is used to configure the AC name list.

   2) capwapBaseMacAclTable

      The ACL table is used to configure stations' Access Control Lists
      (ACLs).

   3) capwapBaseWtpProfileTable

      The WTP profile table is used to configure WTP profiles for WTPs
      to be managed before they connect to the AC.  An operator could
      change a WTP's current configuration by changing the values of
      parameters in the corresponding WTP profile, then the WTP could
      get the new configuration through the CAPWAP control channel.

   4) capwapBaseWtpStateTable

      The state table of WTPs is used to indicate the AC's CAPWAP FSM
      state for each WTP, and helps the operator to query a WTP's
      current configuration.

   5) capwapBaseWtpTable

      The WTP table is used to display properties of the WTPs in running
      state.

   6) capwapBaseWirelessBindingTable

      The wireless binding table is used to display the mappings between
      WTP Virtual Radio Interfaces and PHY radios, and the wireless
      binding type for each PHY radio.

Top      ToC       Page 9 
   7) capwapBaseStationTable

      The station table is used for providing stations' basic property
      information.

   8) capwapBaseWtpEventsStatsTable

      The WTP events statistic table is used for collecting WTP reboot
      count, link failure count, hardware failure count and so on.

   9) capwapBaseRadioEventsStatsTable

      The radio events statistic table is used for collecting radio
      reset count, channel change count, hardware failure count, and so
      on.

7.  Relationship to Other MIB Modules

7.1.  Relationship to SNMPv2-MIB Module

   The CAPWAP-BASE-MIB module does not duplicate the objects of the
   'system' group in the SNMPv2-MIB [RFC3418] that is defined as being
   mandatory for all systems, and the objects apply to the entity as a
   whole.  The 'system' group provides identification of the management
   entity and certain other system-wide data.

7.2.  Relationship to IF-MIB Module

   The Interfaces Group [RFC2863] defines generic managed objects for
   managing interfaces.  This memo contains the media-specific
   extensions to the Interfaces Group for managing WTP PHY radios that
   are modeled as interfaces.

   The IF-MIB module is required to be supported on the AC.  Each PHY
   radio on the WTP corresponds to a WTP Virtual Radio Interface on the
   AC.  The WTP Virtual Radio Interface provides a way to configure the
   radio's parameters and query radio's traffic statistics, and reuse
   wireless binding modules defined by other SDOs.  The interface MUST
   be modeled as an ifEntry, and ifEntry objects such as ifIndex,
   ifDescr, ifName, and ifAlias are to be used as per [RFC2863].

   Also, as an ifIndex [RFC2863] is used as a common index for
   corresponding interfaces in the CAPWAP-BASE-MIB and specific wireless
   technologies MIB modules, the AC MUST have a mechanism that preserves
   the values of the ifIndexes in the ifTable at AC reboot.

Top      ToC       Page 10 
7.3.  Relationship to ENTITY-MIB Module

   The ENTITY-MIB module [RFC4133] meets the need for a standardized way
   of representing a single agent that supports multiple instances of
   one MIB.  It could express a certain relationship between multiple
   entities and provide entity properties for each entity.

   In a centralized WLAN architecture, the SNMP agent runs on the AC and
   is not required on the WTP.  With the ENTITY-MIB module on the AC, it
   could keep entity information such as firmware revision and software
   revision of the AC and WTPs.  From the ENTITY-MIB module's
   perspective, the overall physical entity (AC) is a 'compound' of
   multiple physical entities (that is, the WTPs connected to AC), and
   all entities are each identified by a physical index.  The
   capwapBaseWtpTable of the CAPWAP-BASE-MIB module uses the
   capwapBaseWtpPhyIndex object to store the mappings of WTP object
   between CAPWAP-BASE-MIB and ENTITY-MIB modules.

   By querying both the CAPWAP-BASE-MIB and ENTITY-MIB modules,
   operators could query the status and properties of the AC and WTPs.
   For example, they could get a WTP's current status through the
   CAPWAP-BASE-MIB module, and a WTP's software revision information
   through the ENTITY-MIB module.  The CAPWAP-BASE-MIB module does not
   duplicate those objects defined in the ENTITY-MIB module.

7.4.  Relationship to Wireless Binding MIB Modules

   The wireless binding MIB module of a wireless technology (such as
   [IEEE.802-11.2007]) is required to be supported on the AC.  The
   CAPWAP-BASE-MIB module is able to support any wireless binding.
   Through the ifIndexes of WTP Virtual Radio Interfaces, it provides a
   consistent and abstract way of reusing MIB objects in the wireless
   binding MIB modules.  The CAPWAP-BASE-MIB module does not duplicate
   those objects defined in the wireless binding MIB modules.

7.5.  MIB Modules Required for IMPORTS

   The following MIB module IMPORTS objects from SYSAPPL-MIB [RFC2287],
   SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580],
   IF-MIB [RFC2863], SNMP-FRAMEWORK-MIB [RFC3411], INET-ADDRESS-MIB
   [RFC4001], and ENTITY-MIB [RFC4133].

8.  Example of CAPWAP-BASE-MIB Module Usage

   Below, the IEEE 802.11 binding is used as an example of how the MIB
   modules operate.

   1) Create a WTP profile.

Top      ToC       Page 11 
      Suppose the WTP's Base MAC address is '00:01:01:01:01:00'.  Create
      the WTP profile as follows:

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

      Suppose the WTP with model number 'WTP123' has one PHY radio,
      which is identified by ID 1.  The creation of this WTP profile
      triggers the AC to automatically create a WTP Virtual Radio
      Interface and add a new row object to the
      capwapBaseWirelessBindingTable without manual intervention.
      Suppose the ifIndex of the WTP Virtual Radio Interface is 10.  The
      following information is stored in the
      capwapBaseWirelessBindingTable.

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

      The WTP Virtual Radio Interfaces on the AC correspond to the PHY
      radios on the WTP.  The WTP Virtual Radio Interface is modeled by
      ifTable [RFC2863].

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

   2) Query the ifIndexes of WTP Virtual Radio Interfaces.

      Before configuring PHY radios, the operator needs to get the
      ifIndexes of WTP Virtual Radio Interfaces corresponding to the PHY
      radios.

      As capwapBaseWirelessBindingTable already stores the mappings
      between PHY radios (Radio IDs) and the ifIndexes of WTP Virtual
      Radio Interfaces, the operator can get the ifIndex information by
      querying this table.  Such a query operation SHOULD run from radio
      ID 1 to radio ID 31 according to [RFC5415]), and stop when an
      invalid ifIndex value (0) is returned.

      This example uses capwapBaseWtpProfileId = 1 and
      capwapBaseWirelessBindingRadioId = 1 as inputs to query the
      capwapBaseWirelessBindingTable, and gets
      capwapBaseWirelessBindingVirtualRadioIfIndex = 10.  Then it uses
      capwapBaseWtpProfileId = 1 and capwapBaseWirelessBindingRadioId =
      2, and gets an invalid ifIndex value (0), so the query operation
      ends.  This method gets not only the ifIndexes of WTP Virtual
      Radio Interfaces, but also the numbers of PHY radios.  Besides
      checking whether the ifIndex value is valid, the operator SHOULD
      check whether the capwapBaseWirelessBindingType is the desired
      binding type.

Top      ToC       Page 13 
   3) Configure specific wireless binding parameters for a WTP Virtual
   Radio Interface.

      This configuration is made on the AC through a specific wireless
      binding MIB module such as the IEEE 802.11 MIB module.

      The following shows an example of configuring parameters for a WTP
      Virtual Radio Interface with ifIndex 10 through the IEEE 802.11
      dot11OperationTable [IEEE.802-11.2007].

      In dot11OperationTable
      {
        ifIndex                                  = 10,
        dot11MACAddress                          = '00:00:00:00:00:00',
        dot11RTSThreshold                        = 2347,
        dot11ShortRetryLimit                     = 7,
        dot11LongRetryLimit                      = 4,
        dot11FragmentationThreshold              = 256,
        dot11MaxTransmitMSDULifetime             = 512,
        dot11MaxReceiveLifetime                  = 512,
        dot11ManufacturerID                      = 'capwap',
        dot11ProductID                           = 'capwap',
        dot11CAPLimit                            = 2,
        dot11HCCWmin                             = 0,
        dot11HCCWmax                             = 0,
        dot11HCCAIFSN                            = 1,
        dot11ADDBAResponseTimeout                = 1,
        dot11ADDTSResponseTimeout                = 1,
        dot11ChannelUtilizationBeaconInterval    = 50,
        dot11ScheduleTimeout                     = 10,
        dot11DLSResponseTimeout                  = 10,
        dot11QAPMissingAckRetryLimit             = 1,
        dot11EDCAAveragingPeriod                 = 5
      }

   4) Get the current configuration status report from the WTP to the
   AC.

      According to [RFC5415], before a WTP that has joined the AC gets
      configuration from the AC, it needs to report its current
      configuration status by sending a configuration status request
      message to the AC, which uses the message to update MIB objects on
      the AC.  For example, for IEEE 802.11 binding, the AC updates data
      in the ifTable [RFC2863] and IEEE 802.11 MIB module, and so on,
      according to the message.  For ifIndex 10, its ifOperStatus in
      ifTable is updated according to the current radio operational
      status in the CAPWAP message.

Top      ToC       Page 14 
   5) Query WTP and radio statistical data.

      After WTPs start to run, the operator could query WTP and radio
      statistical data through CAPWAP-BASE-MIB and the specific binding
      MIB module on the AC.  For example, through dot11CountersTable in
      the IEEE 802.11 MIB module, the operator could query the counter
      data of a radio using the ifIndex of the corresponding WTP Virtual
      Radio Interface.  With the capwapBaseWtpTable table in the CAPWAP-
      BASE-MIB module, the operator could query the properties of
      running WTPs.

   6) Run MIB operations through a CAPWAP protocol wireless binding MIB
   module.

      For example, for the CAPWAP IEEE 802.11 binding protocol
      [RFC5416], some MIB operations such as MAC mode configuration for
      a WLAN depend on the CAPWAP Protocol Binding MIB for IEEE 802.11
      [RFC5834].  For more information, refer to [RFC5834].

   7) Query other properties of a WTP.

      The Operator could query MIB objects in the ENTITY-MIB [RFC4133]
      module by using the capwapBaseWtpPhyIndex in the
      capwapBaseWtpTable of CAPWAP-BASE-MIB module.  The properties of a
      WTP such as software version, hardware version are available in
      the ENTITY-MIB module.



(page 14 continued on part 2)

Next RFC Part