Internet Engineering Task Force                              Y. Shi, Ed.
Internet-Draft                                        H3C Tech. Co., Ltd
Intended status: Standards Track                         D. Perkins, Ed.
Expires: April 30, September 4, 2009                                      SNMPinfo
                                                         C. Elliott, Ed.
                                                     Cisco Systems, Inc.
                                                           Y. Zhang, Ed.
                                                          Fortinet, Inc.
                                                        October 27, 2008
                                                           March 3, 2009

              CAPWAP Protocol Binding MIB for IEEE 802.11
                   draft-ietf-capwap-802dot11-mib-02
                   draft-ietf-capwap-802dot11-mib-03

Status of This Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she

   This Internet-Draft is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, submitted to IETF in accordance full conformance with Section 6 the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 30, September 4, 2009.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The Internet-Standard Management Framework . . . . . . . . . .  3
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  3  5
   5.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   6.  Structure of the MIB Module  . . . . . . . . . . . . . . . .  5
     5.1.  Requirements and Constraints .  4
     6.1.  The capwapDot11Objects Subtree . . . . . . . . . . . . . .  5
     6.2.  The capwapDot11Conformance Subtree . . .
     5.2.  Mechanism of Reusing Wireless Binding MIB Module . . . . .  5
   6.  Structure of the MIB Module  . . . .  5
     6.3.  Brief Description of MIB Objects . . . . . . . . . . . . .  5  6
   7.  Relationship to Other MIB Modules  . . . . . . . . . . . . . .  5  7
     7.1.  Relationship to the SNMPv2-MIB Module  . . . . . . . . . . . . . .  5  7
     7.2.  Relationship to the IF-MIB Module  . . . . . . . . . . . . . . . .  6  7
     7.3.  Relationship to CAPWAP-BASE-MIB Module . . . . . . . . . . . . .  8  7
     7.4.  Relationship to the MIBs defined MIB Module in IEEE 802.11
           standard and its amendments  . . . . . . . . . . . Standard . . . .  8
     7.5.  MIB modules required for IMPORTS . . . . . . . . . . . . .  8
   8.  Example of CAPWAP-DOT11-MIB Module Usage . . . . . . . . . . . . . .  8
   9.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . . 12 13
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 19 20
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
     11.1. IANA Considerations for CAPWAP-DOT11-MIB Module  . . . . . . . . . 20 21
     11.2. IANA Considerations for ifType . . . . . . . . . . . . . . 20 21
   12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 21
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 21
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 21
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 20 21
     14.2. Informative References . . . . . . . . . . . . . . . . . . 22 23
   Appendix A.  Appendix A. Changes between -03 and -02 . . . . . . . 23

1.  Introduction

   The CAPWAP Protocol [I-D.ietf-capwap-protocol-specification] defines
   a standard, interoperable protocol, which enables an Access
   Controller (AC) to manage a collection of Wireless Termination
   Points(WTPs).  CAPWAP supports the use of various wireless
   technologies by the WTPs, with one being specified in the CAPWAP
   Protocol Binding for IEEE 802.11
   binding document
   [I-D.ietf-capwap-protocol-binding-ieee80211].

   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 WLAN and a way to reuse the MIBs MIB module
   defined in IEEE 802.11 standard and its amendments. standard.

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 document describing the CAPWAP Protocol specification for 802.11 binding
   [I-D.ietf-capwap-protocol-binding-ieee80211].  Besides terminology
   defined in
   [I-D.ietf-capwap-protocol-specification], the CAPWAP Protocol Binding
   for IEEE 802.11 standard [I-D.ietf-capwap-protocol-binding-ieee80211] and
   CAPWAP specification, an
   important conception is WLAN service.  In Protocol Base MIB [I-D.ietf-capwap-base-mib].

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

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

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

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

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

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

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

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

   WLAN: The WLAN refers to a logical component instantiated on a WTP
   device.  A single physical WTP may operate a number of WLAN services, and the way is
   called as virtual AP. WLANs.  Each
   Basic Service Set Identifier (BSSID) and its constituent wireless
   terminal radios are is 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.

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

   Wireless Binding MIB Module: Other Standards Developing Organizations
   (SDOs), such as described in RFC 2119 [RFC2119].

5.  Overview

   The [I-D.ietf-capwap-base-mib] provides IEEE already defined MIB module for a way specific
   wireless technology, e.g., the MIB module in IEEE 802.11 standard
   [IEEE.802-11.2007].  Such MIB modules are called as wireless binding
   MIB module defined by other SDOs.

   CAPWAP Protocol Wireless Binding MIB Module: It is a MIB module
   corresponding to configure and manage
   WTP and radio CAPWAP Protocol Binding for a Wireless binding.

   Sometimes, not all the technology-specific message elements in a
   CAPWAP binding protocol have MIB objects through SNMP.  It's defined by other SDOs.  For
   example, the protocol of [I-D.ietf-capwap-protocol-binding-ieee80211]
   defines WLAN conception.  Also, Local or Split MAC modes could be
   specified for a basis WLAN.  The MAC mode for manage and
   control 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.  Requirements and Constraints

   The MIB module in IEEE 802.11 standard [IEEE.802-11.2007] already has
   MIB objects definition for most IEEE 802.11 Message Elements in the
   the CAPWAP Protocol's Protocol Binding for IEEE 802.11
   [I-D.ietf-capwap-protocol-binding-ieee80211].  As a CAPWAP Protocol
   802.11 binding MIB module, the CAPWAP-DOT11-MIB module (CAPWAP-DOT11-
   MIB) provides a way to configure WLAN service, and it also allows MUST be able
   to
   easily reuse current and future MIBs defined such MIB objects in the IEEE 802.11 standard
   and its amendments.

   It MIB module.  Also, the
   functions such as MAC mode for WLAN in the
   [I-D.ietf-capwap-protocol-binding-ieee80211] 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 is designed to satisfy the
   following requirements and constraints:

   - The MIB module could Could easily reuse current and future MIBs defined wireless binding MIB module in the IEEE 802.11 standard and its amendments, and not require to
   redefine them.
   standard;

   - From AC to centrally manage and configure WLAN service; WLAN;

   - Operators could configure MAC type and tunnel mode for a specific
   WLAN service by SNMP;

   - The
   WLAN.

5.2.  Mechanism of Reusing Wireless Binding MIB module supports virtual AP; Module

   Before coming to details of CAPWAP-DOT11-MIB module, it will
   introduce how it is able to reuse IEEE the MIB module in IEEE 802.11
   standard.  According to [I-D.ietf-capwap-protocol-binding-ieee80211],
   each WLAN service is identified by WLAN Id.  In the MIBs defined in MIB module of IEEE 802.11 standard
   and its amendments,
   standard, the MIB tables such as Dot11AuthenticationAlgorithmsTable
   are able to support wireless configuration (such as authentication
   algorithm), and these tables use ifIndex as index.  To support 802.11
   parameters for a specific
   WLAN service, WLAN, and consider that the operator has to
   prepare configurations for each WLAN service on the AC before WTPs connect to
   AC, a wireless service
   AC.  A WLAN could be abstracted as a 'WLAN Service Interface' on the
   AC, and which could be identified by ifIndex.  The MIB objects in the
   MIB module of IEEE 802.11 standard which are associated with this
   interface can be used to configure WLAN parameters for a WLAN, such
   as Authentication Algorithm.  On the AC, the MIB table CapwapDot11WlanConfigTable
   CapwapDot11WlanTable in the CAPWAP-DOT11-MIB module will indicate the
   mapping relation between a 'WLAN Id" and ifIndex of a 'WLAN Service
   Interface'.  With ifIndex of a 'WLAN Service Interface', system is
   able to reuse the MIBs defined MIB module in the IEEE 802.11 standard and its
   amendments.

6.  Structure of standard.

   In the MIB Module

6.1.  The capwapDot11Objects Subtree

   The subtree provides information for configuration parameters of WLAN
   service CAPWAP-BASE-MIB module, each PHY radio is identified by WTP Id
   and binding WLAN service to radio ID, and has a specific radio.

6.2.  The capwapDot11Conformance Subtree corresponding 'WTP Virtual Radio Interface'
   on the AC.  The subtree provides conformance information of IEEE 802.11 MIB objects.

6.3.  Brief Description module associated with this interface
   can be used to configure IEEE 802.11 wireless binding parameters for
   radio such as RTS Threshold.  The 'WLAN BSS Interface', created by
   binding 'WTP Virtual Radio Interface' and WLAN, is used for data
   forwarding.

6.  Structure of the MIB Objects Module

   The MIB objects were derived from the CAPWAP protocol binding for
   802.11 document [I-D.ietf-capwap-protocol-binding-ieee80211].

   1) capwapDot11WlanConfigTable capwapDot11WlanTable

   The table is used for providing configuration such as MAC type and so
   on for WLANs.  For a specific WLAN service which is identified by
   capwapDot11WlanId, an interface of 'WLAN Service Interface' ifType
   will be created.  By the ifIndex of interface, it provides a way to
   reuse the MIBs defined MIB module in IEEE 802.11 standard and its amendments. standard.  For example, according
   to [I-D.ietf-capwap-protocol-binding-ieee80211], Auth Type needs to
   be configured for a WLAN.  In the IEEE 802.11 MIB, MIB module, the MIB
   object dot11AuthenticationAlgorithm in the
   dot11AuthenticationAlgorithmsTable is corresponding to Auth Type.
   Considering both capwapDot11WlanConfigTable capwapDot11WlanTable and
   dot11AuthenticationAlgorithmsTable use ifIndex as index, CAPWAP-
   DOT11-MIB module are able to easily reuse
   dot11AuthenticationAlgorithm object in IEEE 802.11 MIB. MIB module.  It is
   same for other objects in the MIBs
   defined in MIB module of IEEE 802.11 standard and its amendments. standard.

   2) capwapDot11WlanBindTable

   The table provides a way to bind WLAN service to a radio, then supports virtual AP.
   multiple WLANs on a physical WTP.  The binding operation will
   dynamically create 'WLAN BSS Interface', and this logical interface
   is used for data forwarding function.

7.  Relationship to Other MIB Modules

7.1.  Relationship to the SNMPv2-MIB Module

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

7.2.  Relationship to the 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 service that are modeled
   as interfaces.

   For each WLAN, it will have a logical interface of 'WLAN Service
   Interface' responding to it on the AC.  The interface SHOULD MUST be modeled
   as an ifEntry and provide appropriate interface information.  'WLAN
   Service Interface' provides a way to configure IEEE 802.11 parameters
   for a specific WLAN service, WLAN, and reuse the MIBs defined MIB module in IEEE 802.11 standard and its amendments.

   To provide data forwarding service,
   standard.

   Also, the system will dynamically (AC) MUST have a mechanism that preserves the values
   of ifIndex of 'WLAN Service Interface' ifType in the ifTable at AC
   reboot.

   To provide data forwarding service, system will dynamically create
   logical interface of 'WLAN BSS Interface'.  The interface SHOULD MUST be
   modeled as an ifEntry and provide appropriate interface information.
   The interface enables a single physical WTP to support multiple
   WLANs.

   Also, the virtual AP function.

   Some specific interpretations of ifTable for CAPWAP-DOT11-MIB are as
   follow.

   1) WLAN Service Interface

      Object          Use for system (AC) MUST have a mechanism that preserves the CAPWAP-DOT11-MIB

   ifIndex         Each interface of 'WLAN Service Interface' type
                   maybe be represented by an ifEntry.

   ifDescr         Description values
   of the interface ifIndex of 'WLAN Service BSS Interface' type. ifType          IANAifType of 'WLAN Service Interface'.

   ifName          Textual name (unique on this system) of in the interface
                   or an octet string of zero length.

   ifAlias ifTable at AC
   reboot.

7.3.  Relationship to CAPWAP-BASE-MIB Module

   The nonvolatile 'alias' name for the interface, as
                   specified by CAPWAP-BASE-MIB module provides a network manager.

   ifPhysAddress   Unused.

   ifAdminStatus   This variable indicates the administrator's intent as way to whether PHY should be enabled, disabled. Could be
                   always enabled.

   ifOperStatus    This value reflects the actual or operational status
                   of interface. Could be always enabled.

                   Also see [RFC2863].

   ifLastChange    The value manage and control WTP
   and radio objects.  Especially, CAPWAP-BASE-MIB module has a
   mechanism of sysUpTime at the time 'WTP Virtual Radio Interface' which enable system to
   reuse the interface
                   entered its current operational state.
                   Also see [RFC2863].

   The other objects such as ifInOctets, ifOutOctets, ifInErrors,
   ifOutErrors are unused.

   2) MIB module in IEEE 802.11 standard.  With it, operator
   could configure an IEEE 802.11 AP radio's parameter and query radio's
   traffic statistics.  Based on CAPWAP-BASE-MIB module, CAPWAP-DOT11-
   MIB module provides more information from WLAN BSS Interface

      Object          Use for the CAPWAP-DOT11-MIB perspective.

7.4.  Relationship to MIB Module in IEEE 802.11 Standard

   Through ifIndex         Each interface of 'WLAN BSS Service Interface' type maybe
                   be represented by an ifEntry.

   ifDescr         Description of the interface of and 'WLAN BSS Interface'
                   type.

   ifType          IANAifType of 'WLAN BSS Interface'.

   ifName          Textual name (unique on this system) of
   ifType, the interface
                   or an octet string of zero length.

   ifAlias         The nonvolatile 'alias' name for the interface, as
                   specified by a network manager.

   ifPhysAddress   The physical address of interface, i.e. WTP assigned
                   BSSID.

   ifAdminStatus   This variable indicates the administrator's intent as
                   to whether PHY should be enabled, disabled, or
                   running in some diagnostic testing mode on this
                   interface.
                   Also see [RFC2863].

   ifOperStatus    This value reflects the actual or operational status
                   of interface.
                   Also see [RFC2863].

   ifLastChange    The value of sysUpTime at the time the interface
                   entered its current operational state.
                   Also see [RFC2863].

   ifInOctets      The number of octets received as IEEE 802.11 frames.

   ifOutOctets     The number of octets transmitted as IEEE 802.11
                   frames.

   ifInErrors      The number of inbound IEEE 802.11 frames dropped due
                   to uncorrectable errors.

   ifInUnknownProtos
                   The number of received IEEE 802.11 frame discarded
                   during frame header validation, including frames with
                   unrecognized label values.

   ifOutErrors     The number of outbound IEEE 802.11 frames dropped due
                   to uncorrectable errors.

7.3.  Relationship to CAPWAP-BASE-MIB

   The CAPWAP-BASE-MIB provides a way to manage and control WTP and
   radio objects.  Especially, CAPWAP-BASE-MIB has a mechanism of 'WTP
   Virtual Radio Interface' which enable system MIB module is able to reuse the MIBs
   defined MIB module in IEEE 802.11 standard and its amendments.  With it,
   administrator could configure an IEEE 802.11 AP radio's parameter and
   query radio's traffic statistics.  Based on CAPWAP-BASE-MIB, CAPWAP-
   DOT11-MIB provides more information from WLAN service perspective.

7.4.  Relationship to the MIBs defined in IEEE 802.11
   standard and its
      amendments

   Through ifIndex of 'WLAN Service Interface' and 'WLAN BSS Interface'
   ifType, the MIB [IEEE.802-11.2007].  The CAPWAP-DOT11-MIB module is able to reuse MIB does not
   duplicate those objects in the MIBs
   defined in MIB module of IEEE 802.11 standard and its amendments. standard.

   In the CAPWAP Protocol Binding for IEEE 802.11 binding document [I-D.ietf-capwap-protocol-binding-
   ieee80211],
   [I-D.ietf-capwap-protocol-binding-ieee80211], it involves a part of
   MIB objects defined by IEEE 802.11
   standard and its amendments. standard.  Although CAPWAP-DOT11-MIB CAPWAP-DOT11-
   MIB module uses the
   802.11 binding document it [I-D.ietf-capwap-protocol-binding-ieee80211] as a
   reference, it could reuse all the MIB objects defined by in the IEEE 802.11
   standard and its amendments , and not limited by the scope of the 802.11 binding document. 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 [I-D.ietf-capwap-base-mib].

8.  Example of CAPWAP-DOT11-MIB Module Usage

   In the CAPWAP-BASE-MIB, each PHY radio is identified by WTP Id and
   radio ID, and which has a corresponding 'WTP Virtual Radio Interface'
   on the AC. The IEEE 802.11 MIB associated with this interface
   can be used to configure IEEE 802.11 wireless binding parameters for
   radio such as RTS Threshold.

   In the CAPWAP 802.11 Binding MIB, each WLAN service is identified
   by WLAN Id, and which has a corresponding 'WLAN Service Interface'
   on the AC. The MIBs defined in IEEE 802.11 standard and its
   amendments associated with this interface can be used to configure
   WLAN parameters for a WLAN service, such as Authentication Algorithm.

   The 'WLAN BSS Interface', created by binding 'WTP Virtual Radio
   Interface' and 'WLAN Service Interface', is used for data forwarding.
   Combining the example provided in the [I-D.ietf-capwap-base-mib],
   the following is a whole example for configuration and management of
   WTP, radio and WLAN service for IEEE 802.11 binding.

   1) Identify each the PHY radio by 'WTP Virtual Radio Interface'

   According to [I-D.ietf-capwap-protocol-specification], each radio on
   a WTP will be identified by a radio Id.  Each WTP could be identified
   by its serial number.
   When configuration for a WTP is prepared before a WTP connects to AC,
   the following information is available in the
   CapwapBaseRadioBindTable.

   In CapwapBaseRadioBindTable
   {
     capwapBaseWTPId                     = 12345678,
     capwapBaseRadioId                   = 1,
     capwapBaseWtpVirtualRadioifIndex    = 10,
     capwapBaseWirelessBinding           = dot11(2)
   }

   Suppose a WTP's serial number is 12345678, '12345678', and first PHY radio's radio id is 1.
   On the AC, the ifIndex of interface in 'WTP Virtual Radio Interface'
   ifType is 10 which represents the PHY radio 1.  The following
   information is obtained in the CapwapBaseWirelessBindingTable.

      In CapwapBaseWirelessBindingTable
      {
        capwapBaseWtpStateWtpId                         = '12345678',
        capwapBaseWirelessBindingRadioId                = 1,
        capwapBaseWirelessBindingVirtualRadioIfIndex    = 10,
        capwapBaseWirelessBindingType                   = dot11(2)
      }
   By the mechanism of 'WTP Virtual Radio Interface', it seemed that seems WTP PHY
   radios are located on the AC.  The interface of 'WTP Virtual Radio
   Interface' ifType is modeled by ifTable. ifTable [RFC2863].

      In ifTable
      {
        ifIndex              = 10,
        ifDescr              = 'WTP Virtual Radio Interface',
        ifType               = xxx,
   RFC Editor - please replace xxx with the value
   allocated by IANA for IANAifType of 'WTP Virtual Radio
                            Interface', Interface'
        ifMtu                = 0,
        ifSpeed              = 0,
        ifPhysAddress        = 0.0.0.0.0.0, '000000',
        ifAdminStatus        = true,
        ifOperStatus         = false,
        ifLastChange         = 0,
        ifInOctets           = 0,
        ifInUcastPkts        = 0,
        ifInDiscards         = 0,
        ifInErrors           = 0,
        ifInUnknownProtos    = 0,
        ifOutOctets          = 0,
        ifOutUcastPkts       = 0,
        ifOutDiscards        = 0,
        ifOutErrors          = 0
       }

   2) Configure IEEE 802.11 specific wireless binding parameters for 'WTP Virtual
   Radio Interface'

   It will be done on the AC through the MIBs MIB module defined in IEEE
   802.11
   standard and its amendments. standard.

   For example, to configure parameter for 'WTP Virtual Radio Interface'
   by IEEE 802.11 Dot11OperationTable. Dot11OperationTable [IEEE.802-11.2007].

      In Dot11OperationTable
      {
        ifIndex                         = 10,
        dot11MACAddress                 = 0.0.0.0.0.0,
        dot11RTSThreshold               = 2347,
        dot11ShortRetryLimit            = 7,
        dot11LongRetryLimit             = 4,
        dot11FragmentationThreshold     = 256,
        dot11MaxTransmitMSDULifetime    = 512,
        dot11MaxReceiveLifetime         = 512,
        dot11ManufacturerID             = 'capwap',
        dot11ProductID                  = 'capwap'
      }

   In the example, it supposes ifIndex of a 'WTP Virtual Radio
   Interface' is 10.

   3) Configure WLAN service

   WLAN service configuration will be done through CAPWAP-DOT11-MIB, CAPWAP-DOT11-MIB Module, and
   the MIBs MIB module defined in IEEE 802.11 standard and its amendments.

   First step is to create a 'WLAN Service Interface' through
   CAPWAP-DOT11-MIB CAPWAP-
   DOT11-MIB Module on the AC.

   Here supposes to configure a WLAN which is identified by
   capwapDot11WlanId 1, and CapwapDot11WlanTable would create a row
   object for it.

      In CapwapDot11WlanConfigTable CapwapDot11WlanTable
      {
        capwapDot11WlanId                 = 1,
        capwapDot11WlanServiceIfIndex     = 20,
        capwapDot11WlanMacType            = splitMAC(2),
        capwapDot11WlanTunnelMode         = dot3Tunnel(2),
     capwapDot11WlanConfigRowStatus
        capwapDot11WlanRowStatus          = create
      }

   Here supposes

   The creation operation of a row object would trigger AC system to configure
   automatically create a WLAN service which is identified by
   capwapDot11WlanId 1. A 'WLAN Service Interface' is created
   for it and it is identified
   by ifIndex 20.  It does not require operator to manually create a
   'WLAN Service Interface'.

   Corresponding to 'WLAN Service Interface', it SHOULD MUST be modeled as an
   ifEntry on the AC and provide appropriate interface information.
   CapwapDot11WlanTable would keep the mapping relationship between
   capwapDot11WlanId and ifIndex of a 'WLAN Service Interface'.

      In ifTable
      {
        ifIndex              = 20,
        ifDescr              = 'WLAN Service Interface',
        ifType               = xxx,
   RFC Editor - please replace xxx with the value
   allocated by IANA for IANAifType of 'WLAN Service Interface', Interface'
        ifMtu                = 0,
        ifSpeed              = 0,
        ifPhysAddress        = 0.0.0.0.0.0,
        ifAdminStatus        = true,
        ifOperStatus         = true,
        ifLastChange         = 0,
        ifInOctets           = 0,
        ifInUcastPkts        = 0,
        ifInDiscards         = 0,
        ifInErrors           = 0,
        ifInUnknownProtos    = 0,
        ifOutOctets          = 0,
        ifOutUcastPkts       = 0,
        ifOutDiscards        = 0,
        ifOutErrors          = 0
      }

   Second step is to configure WLAN parameters of 'WLAN Service
   Interface' through the MIBs MIB module defined in IEEE 802.11 standard and
   its amendments on
   the AC.

   Suppose operator to configure authentication algorithm for a WLAN.

      In Dot11AuthenticationAlgorithmsTable
      {
        ifIndex                                = 20,
        dot11AuthenticationAlgorithmsIndex     = 1,
        dot11AuthenticationAlgorithm           = Shared Key,
        dot11AuthenticationAlgorithmsEnable    = true
      }

   Here ifIndex 20 is for interface of 'WLAN Service Interface' ifType.
   Suppose the index of authentication algorithm is 1.

   4) Bind WLAN service to WTP radio

   On the AC, through CapwapDot11WlanBindTable, CapwapDot11WlanBindTable in the CAPWAP-DOT11-MIB,
   it configures which WLAN service (identified by capwapDot11WlanId) will be
   provided on which radio 'WTP Virtual Radio Interface' (identified by
   ifIndex).
   Suppose capwapDot11WlanMacType of

   Here supposes to bind a WLAN service (capwapDot11WlanId is splitMAC(2),
   the 1) with a
   interface of 'WLAN BSS Interface' will be created on the AC. 'WTP Virtual Radio Interface'(ifIndex is 10).  The AC will use it
   CapwapDot11WlanBindTable would create a row object for split data forwarding. Here supposes ifIndex
   of interface in 'WLAN BSS Interface' ifType is 30. it.

      In CapwapDot11WlanBindTable
      {
        ifIndex                            = 10,
        capwapDot11WlanId                  = 1,
     capwapDot11WlanBssIfIndex
        capwapDot11WlanBindBssIfIndex      = 30,
     capwapDot11WlanBssRowStatus
        capwapDot11WlanBindBssRowStatus    = create
      }

   Suppose capwapDot11WlanMacType of WLAN is splitMAC(2), the creation
   operation of a row object on the CapwapDot11WlanBindTable would
   trigger AC system to automatically create a 'WLAN BSS Interface' and
   it is identified by ifIndex 30.  It does not require operator to
   manually create a 'WLAN BSS Interface'.

   Corresponding to 'WLAN BSS Interface', it MUST be modeled as an
   ifEntry on the AC and provide appropriate interface information.
   CapwapDot11WlanBindTable would keep the mapping relationship among
   ifIndex of a 'WTP Virtual Radio Interface', WLAN and ifIndex of a
   'WLAN BSS Interface'.

   5) WTP reports its current configuration status

   After join phase and before WTP get configuration from AC, it will
   report its current configuration status to AC through configuration
   status request message.  The MIB data will be updated on the AC.  As
   an example, for ifIndex 10 (which identifies an interface of 'WLAN
   Virtual Radio Interface' ifType), its ifOperStatus in ifTable will be
   updated with current radio operational status.

   6) Query WTP and radio statistics data

   After WTPs come to run status, administrator operator could query WTP and radio
   statistics data through CAPWAP-BASE-MIB and CAPWAP-DOT11-MIB. CAPWAP-DOT11-MIB module.
   For example, through dot11CountersTable in the IEEE 802.11 MIB,
   administrator [IEEE.802-11.2007], operator
   could query counter data for radio which is identified by ifIndex of
   a 'WLAN Virtual Radio Interface'.

   7) Query other statistics data

   For example, administrator operator could query the configuration of WLAN service through
   Dot11AuthenticationAlgorithmsTable [IEEE.802-11.2007] and statistic
   data of 'WLAN BSS Interface' through ifTable;

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 "200810270000Z" "200903030000Z"        -- Oct 27th, 2008 March 3th, 2009
    ORGANIZATION "IETF Control And Provisioning of Wireless Access
                  Points (CAPWAP) Working Group
                  http://www.ietf.org/html.charters/capwap-charter.html"
    CONTACT-INFO
        "General Discussion: capwap@frascone.com
         To Subscribe: http://lists.frascone.com/mailman/listinfo/capwap

         Yang Shi
         H3C, Digital Technology Plaza, NO.9 Shangdi 9th Street,Haidian
         District,Beijing,China(100085)
         Email:  young@h3c.com

         David T. Perkins
         228 Bayview Dr
         San Carlos, CA 94070
         USA
         Phone: +1 408 394-8702
         Email:  dperkins@snmpinfo.com

         Chris Elliott
         Cisco Systems, Inc.
         7025 Kit Creek Rd., P.O. Box 14987
         Research Triangle Park  27709
         USA
         Phone: +1 919-392-2146
         Email: chelliot@cisco.com

         Yong Zhang
         Fortinet, Inc.
         1090 Kifer Road
         Sunnyvale, CA 94086
         USA
         Email: yzhang@fortinet.com"

   DESCRIPTION
       "Copyright (C) 2008 2009 The Internet Society.  This version of
        the MIB module is part of RFC xxx; see the RFC itself
        for full legal notices.

        This MIB module contains managed object definitions for
        the IEEE 802.11 bindings for the
        CAPWAP Protocol." Protocol binding for IEEE 802.11."
   REVISION    "200810270000Z"    "200903030000Z"
   DESCRIPTION
       "Initial version, published as RFC xxx"
        ::= { mib-2 xxx }

-- Textual conventions

CapwapDot11WlanIdTC ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "d"
    STATUS      current
    DESCRIPTION
        "Represents an unique identifier of a WLAN." WLAN.
         According to REFERENCE, the value of WLAN ID MUST be between
         one (1) and 16, and it is specified for a radio of WTP.
         The SYNTAX      Unsigned32 (1..16)

-- Top level components of this MIB

-- Tables, Scalars
capwapDot11Objects OBJECT IDENTIFIER capwapDot11WlanId is defined as
         CapwapDot11WlanIdTC, and capwapDot11WlanId is WLAN configured
         on the AC (NOT on the WTP).
         As AC could have more WLANs configured than WTP, the value of
         capwapDot11WlanId could be more than 16.
    SYNTAX      CapwapDot11WlanIdTC "
    REFERENCE
        "Section 6.1. of CAPWAP Protocol Binding for IEEE 802.11,
         RFC xxx."
    SYNTAX      Unsigned32 (1..512)

-- Top level components of this MIB module

-- Tables, Scalars
capwapDot11Objects OBJECT IDENTIFIER
    ::= { capwapDot11MIB 1 }
-- Conformance
capwapDot11Conformance OBJECT IDENTIFIER
    ::= { capwapDot11MIB 2 }

-- capwapDot11WlanConfigTable capwapDot11WlanTable Table

capwapDot11WlanConfigTable

capwapDot11WlanTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF CapwapDot11WlanConfigEntry CapwapDot11WlanEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "A table of objects that display and control the WLAN
         service. WLANs.
         Values of all read-create objects in this table are persistent at
         restart/reboot."
    ::= { capwapDot11Objects 1 }

capwapDot11WlanConfigEntry

capwapDot11WlanEntry  OBJECT-TYPE
    SYNTAX      CapwapDot11WlanConfigEntry      CapwapDot11WlanEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "A set of objects that display and control the WLAN
         service." WLANs."
    INDEX { capwapDot11WlanId }
    ::= { capwapDot11WlanConfigTable capwapDot11WlanTable 1 }

CapwapDot11WlanConfigEntry

CapwapDot11WlanEntry ::=
    SEQUENCE {
      capwapDot11WlanId                 CapwapDot11WlanIdTC,
      capwapDot11WlanServiceIfIndex     InterfaceIndex,
      capwapDot11WlanMacType            CapwapBaseMacTypeTC,
      capwapDot11WlanTunnelMode         CapwapBaseTunnelModeTC,
      capwapDot11WlanConfigRowStatus
      capwapDot11WlanRowStatus          RowStatus
    }

capwapDot11WlanId OBJECT-TYPE
    SYNTAX      CapwapDot11WlanIdTC
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Represents the WLAN Id for a WLAN which has a
         capwapDot11WlanServiceIfIndex interface corresponding to it."
    REFERENCE
        "Section 6.1. of CAPWAP Protocol Binding for IEEE 802.11,
         RFC xxx."
    ::= { capwapDot11WlanConfigEntry capwapDot11WlanEntry 1 }

capwapDot11WlanServiceIfIndex OBJECT-TYPE
    SYNTAX      InterfaceIndex
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Represents the index value that uniquely identifies a
         'WLAN Service Interface'. The interface identified by a
         particular value of this index is the same interface as
         identified by the same value of ifIndex.
         The creation operation of a row object on the
         capwapDot11WlanTable would trigger AC system to automatically
         create a 'WLAN Service Interface' and it is identified by
         ifIndex. It does not require operator to manually create a
         'WLAN Service Interface'.
         Before WTPs connect to AC and get configuration, administrator operator
         will prepare configuration for them. For a specific WLAN
         service, WLAN,
         a logical interface of 'WLAN Service Interface'
         ifType will be created, created by system, and administrator operator could
         configure WLAN parameter through it.
         For example, according to IEEE 802.11 '6.1. IEEE 802.11
         Add WLAN' in the [I-D.ietf-capwap-protocol-binding-ieee80211], administrator
         operator could configure Auth Type for a WLAN. The 'WLAN
         Service Interface' provides a way to uniquely identify each
         WLAN by logical on the AC. As most MIBs MIB modules use ifIndex to
         identify an interface for configuration and statistic data,
         for example, dot11AuthenticationAlgorithmsTable in IEEE 802.11
         MIB module use ifIndex as index, and
         dot11AuthenticationAlgorithm object is for Auth Type mentioned
         in the CAPWAP '6.1. IEEE 802.11 Add WLAN', WLAN'
         [I-D.ietf-capwap-protocol-binding-ieee80211], With the way of
         'WLAN Service Interface', it will easily reuse MIB table like
         dot11AuthenticationAlgorithmsTable,
         dot11AuthenticationAlgorithmsTable in the IEEE 802.11 standard,
         while only care for other configurations like
         capwapDot11WlanTunnelMode."
    ::= { capwapDot11WlanConfigEntry 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 xxx."
    ::= { capwapDot11WlanConfigEntry capwapDot11WlanEntry 3 }

capwapDot11WlanTunnelMode OBJECT-TYPE
    SYNTAX      CapwapBaseTunnelModeTC
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "Represents the frame tunneling type to be used for 802.11 data
         frames from all stations associated with the WLAN.
         Bits are exclusive with each other for a specific WLAN Id." Id, and
         only one tunnel mode could be configured.
         If 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 xxx."
    ::= { capwapDot11WlanConfigEntry capwapDot11WlanEntry 4 }

capwapDot11WlanConfigRowStatus

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."
    ::= { capwapDot11WlanConfigEntry capwapDot11WlanEntry 5 }

-- End of capwapDot11WlanConfigTable capwapDot11WlanTable Table

-- capwapDot11WlanBindTable Table

capwapDot11WlanBindTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF CapwapDot11WlanBindEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "A table of objects that configure which WLAN
         (identified by capwapDot11WlanId) will be provided on
         which 'WTP Virtual Radio Interface' (identified by ifIndex)
         Also, display and control the mapping
         relationship between interface of 'WTP Virtual Radio Interface'
         interface and interface of 'WLAN BSS Interface'.
         The PHY address for interface of  'WTP Virtual Radio
         Interface' ifType will be base BSSID address for PHY
         radio."
    REFERENCE
        "Section 6.1. of CAPWAP Protocol Binding for IEEE 802.11,
         RFC xxx."
    ::= { capwapDot11Objects 2 }

capwapDot11WlanBindEntry OBJECT-TYPE
    SYNTAX      CapwapDot11WlanBindEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "A set of objects that display the mapping relationship
         between interface of 'WTP Virtual Radio Interface' and
         interface of 'WLAN BSS Interface'.
         The INDEX object ifIndex is the ifIndex of an interface
         'WTP Virtual Radio Interface'."
    INDEX { ifIndex, capwapDot11WlanId }
    ::= { capwapDot11WlanBindTable 1 }

CapwapDot11WlanBindEntry ::=
    SEQUENCE {
      capwapDot11WlanBssIfIndex
      capwapDot11WlanBindBssIfIndex      InterfaceIndex,
      capwapDot11WlanBssRowStatus
      capwapDot11WlanBindBssRowStatus    RowStatus
    }

capwapDot11WlanBssIfIndex

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 ifIndex.
         Each capwapDot11WlanBssIfIndex The ifIndex here
         is for an interface of 'WLAN BSS Interface'.
         For a WLAN configuration on a radio, an interface of 'WLAN
         BSS Interface' will corresponding correspond to it.
         The creation operation of a
         WLAN service row object on the PHY radio which
         capwapDot11WlanBindTable would trigger AC system to
         automatically create a 'WLAN BSS Interface' and it is
         identified by ifIndex. It does not require operator to manually
         create a 'WLAN BSS Interface'.
         The PHY address for capwapDot11WlanBssIfIndex capwapDot11WlanBindBssIfIndex is BSSID.
         While manufacturers are free to assign BSSIDs 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 xxx."
    ::= { capwapDot11WlanBindEntry 1 }

capwapDot11WlanBssRowStatus

capwapDot11WlanBindBssRowStatus 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."
    ::= { capwapDot11WlanBindEntry 2 }

-- 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."
         CAPWAP-DOT11-MIB module."

    MODULE -- this module
      MANDATORY-GROUPS {
        capwapDot11WlanConfigGroup,
        capwapDot11WlanGroup,
        capwapDot11WlanBindGroup
      }
    ::= { capwapDot11Compliances 1 }

capwapDot11WlanConfigGroup

capwapDot11WlanGroup    OBJECT-GROUP
    OBJECTS {
      capwapDot11WlanServiceIfIndex,
      capwapDot11WlanMacType,
      capwapDot11WlanTunnelMode,
      capwapDot11WlanConfigRowStatus
      capwapDot11WlanRowStatus
    }
    STATUS  current
    DESCRIPTION
        "The collection of objects which are used to configure
         property of WLAN."
    ::= { capwapDot11Groups 1 }

capwapDot11WlanBindGroup    OBJECT-GROUP
    OBJECTS {
      capwapDot11WlanBssIfIndex,
      capwapDot11WlanBssRowStatus
      capwapDot11WlanBindBssIfIndex,
      capwapDot11WlanBindBssRowStatus
    }
    STATUS  current
    DESCRIPTION
        "The collection of objects which are used to configure
         WLAN BSS."
    ::= { 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 followings are the tables and objects and
   their sensitivity/vulnerability:

   o  - Unauthorized changes to the capwapDot11WlanConfigTable capwapDot11WlanTable and
      capwapDot11WlanBindTable may disrupt allocation of resources in
      the network, also change the behavior of 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 values recorded in the SMI Numbers registry:

        Descriptor        OBJECT IDENTIFIER value
        ----------        -----------------------

        capwapDot11MIB  { mib-2 XXX }

11.2.  IANA Considerations for ifType

   Require IANA to assign a ifType for 'WLAN Service Interface' type.

   Require IANA to assign a ifType for 'WLAN BSS Interface' type.

12.  Contributors

   This MIB module is based on contributions from Long Gao.

13.  Acknowledgements

   The authors wish to thank David Harrington, Fei Fang, Yu Liu, Xi Yao, Sachin
   Dutta, Yujin Zhao, Haitao Zhang. Zhang, Hao Song.

14.  References

14.1.  Normative References

   [RFC2119]                                     Bradner, S., "Key words
                                                 for use in RFCs to
                                                 Indicate Requirement
                                                 Levels", BCP 14,
                                                 RFC 2119, March 1997.

   [RFC2578]                                     McCloghrie, K., Ed.,
                                                 Perkins, D., Ed., and
                                                 J. Schoenwaelder, Ed.,
                                                 "Structure of
                                                 Management Information
                                                 Version 2 (SMIv2)",
                                                 STD 58, RFC 2578,
                                                 April 1999.

   [RFC2579]                                     McCloghrie, K., Ed.,
                                                 Perkins, D., Ed., and
                                                 J. Schoenwaelder, Ed.,
                                                 "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.

   [I-D.ietf-capwap-base-mib]                    Shi, Y., Perkins, D.,
                                                 Elliott, C., and Y.
                                                 Zhang, "CAPWAP Protocol
                                                 Base MIB", draft-ietf-
                                                 capwap-base-mib-01
                                                 capwap-base-mib-03
                                                 (work in progress),
                                                 October
                                                 November 2008.

   [I-D.ietf-capwap-protocol-specification]      Montemurro, M.,
                                                 Stanley, D., and P.
                                                 Calhoun, "CAPWAP
                                                 Protocol
                                                 Specification", draft-
                                                 ietf-capwap-protocol-
                                                 specification-14
                                                 specification-15 (work
                                                 in progress),
                                                 October
                                                 November 2008.

   [I-D.ietf-capwap-protocol-binding-ieee80211]  Montemurro, M.,
                                                 Stanley, D., and P.
                                                 Calhoun, "CAPWAP
                                                 Protocol Binding for
                                                 IEEE 802.11", draft-
                                                 ietf-capwap-protocol-
                                                 binding-ieee80211-11
                                                 (work for
                                                 IEEE 802.11", draft-
                                                 ietf-capwap-protocol-
                                                 binding-ieee80211-12
                                                 (work in progress),
                                                 November 2008.

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

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.

Appendix A.  Appendix A. Changes between -03 and -02

   T1.  T4.  In order for ifIndex to be used as a common handler for the
   CAPWAP MIB and for the interface specific MIB modules like a dot11
   MIB from IEEE one needs to ensure that the same numbering scheme and
   mapping is used by all MIB modules, and that it behaves identically
   for events like interface card swapping, reset or power loss.  I do
   not see how this can happen, I am not sure that this is possible at
   all, and in any case there is no text in the document that explains
   this mechanism.

   --------------------------------------------------------------

   In the Capwap Digest, Vol 39, Issue 4, we gave the text to explain a
   mechanism that preserves the values of ifIndex, Request mailing list
   to confirm it.

   In the section of "Relationship to the IF-MIB", add text:

   Also, the system (AC) MUST have a mechanism that preserves the values
   of ifIndex of 'WLAN Service Interface' ifType in the ifTable at AC
   reboot.

   Also, the system (AC) MUST have a mechanism that preserves the values
   of ifIndex of 'WLAN BSS Interface' ifType in the ifTable at AC
   reboot.

   T2.  Is the WLAN Service interface described in Section 7.2 modeled
   by capwapDot11WlanConfigTable?  If so please say it and make this
   clear by using a more explicit naming convention.  The model here is
   not clear to me.  On one hand you say 'the interface SHOULD be
   modeled as an ifEntry ...'  Why only a SHOULD and not a MUST?  What
   is the procedure for the manager?  Is he looking for all 802.11
   interfaces on the AC and then creates manually a WLAN Service entry
   in the table for each?  What if the ifNumber does not correspond to a
   802.11 interface?  What if the 802.11 interface disappears?

   -----------------------------------------------------------------

   1) The "WLAN Service interface" is modeled by
   capwapDot11WlanConfigTable, and capwapDot11WlanConfigTable is rename
   as capwapDot11WlanTable.

   2) Yes, the the interface MUST be modeled as an ifEntry, not SHOULD
   be

   3) What is the procedure for the manager?  Is he looking for all
   802.11 interfaces on the AC and then creates manually a WLAN Service
   entry in the table for each?

   Please refer to the section of Example of CAPWAP-DOT11-MIB Module
   Usage (the section is updated in the new version).

   The creation operation of a row object on capwapDot11WlanTable would
   trigger system to create "WLAN service Interface", and it does not
   require operator to manually create a "WLAN service Interface".

   In the section of "Relationship to the IF-MIB", add text:

   Also, the system (AC) MUST have a mechanism that preserves the values
   of ifIndex of 'WLAN Service Interface' ifType in the ifTable at AC
   reboot.

   T3.  What 'could be always enabled' means for ifAdminStatus and
   ifOperStatus in the WLAN Service Interface table?  Either change this
   to MUST or explain in what cases these should be other than enabled.

   --------------------------------------------------------------

   The section for interpration of specific MIB objects in the iftable
   was removed in the new version.  Reader could refer to RFC2863

   T4.  What does the statement that 'the other objects such as
   ifInOctets ... are unused' relative to the VLAN Service interface
   mean?  Counters are always zero?

   --------------------------------------------------------------

   The section for interpration of specific MIB objects in the iftable
   was removed in the new version.  Reader could refer to RFC2863

   T5.  In 7.4 - does the text mean that the manager can reuse objects
   from the IEEE 802.11 MIB modules, or that values of these objects are
   being duplicates in this MIB module? (why?  Which ones?)  In any case
   the IEEE 802.11 standard that defines these objects must be a
   Normative Reference for this document.

   -----------------------------------------------------------------

   Yes

   1)the text mean that the manager can reuse objects from the IEEE
   802.11 MIB modules, and the section of "Mechanism of Reusing Wireless
   Binding MIB Module" give explain to it.

   2) also, add one text of "The CAPWAP-DOT11-MIB module does not
   duplicate those objects in the MIB module of IEEE 802.11 standard."
   in the section of "7.4.  Relationship to MIB Module in IEEE 802.11
   Standard"

   3) yes, IEEE 802.11 standard was added as a Normative Reference.

   T6.  The RFCs that define all MIB modules required for IMPORTSs must
   be Normative References to this document.

   -----------------------------------------------------------------

   add reference to RFC3411 in the section of "MIB modules required for
   IMPORTS", add "SNMP-FRAMEWORK-MIB [RFC3411],"

   T7.  The value of the object capwapBaseWTPId in the example is the
   string '12345678' not the integer 12345678

   -----------------------------------------------------------------

   Yes, it is change into '12345678'

   T8.  The names of the objects in the capwapDot11WlanConfigTable are
   not consistent (similar prefix) to capwapDot11WlanConfigEntry.

   ---------------------------------------------------------

   Yes, they are changed with:

   CapwapDot11WlanEntry ::=
       SEQUENCE {
         capwapDot11WlanId                 CapwapDot11WlanIdTC,
         capwapDot11WlanServiceIfIndex     InterfaceIndex,
         capwapDot11WlanMacType            CapwapBaseMacTypeTC,
         capwapDot11WlanTunnelMode         CapwapBaseTunnelModeTC,
         capwapDot11WlanRowStatus          RowStatus
       }

   T9.  The names of the objects in the capwapDot11WlanBindTable are not
   consistent (similar prefix) to capwapDot11WlanBindEntry.

   ---------------------------------------------------------

   Yes, they are changed with:

   CapwapDot11WlanBindEntry ::=
       SEQUENCE {
         capwapDot11WlanBindBssIfIndex      InterfaceIndex,
         capwapDot11WlanBindBssRowStatus    RowStatus
       }

   T10.  What does 'Bits are exclusive for each other for a specific
   WLAN Id' mean for capwapDot11WlanTunnelMode?  That only one tunnel
   mode can be configured (one bit set)?  I assume this does not include
   the bit unused(0).  What happens if the manager sets more than one
   bit, ore no bit, or unused(0) - how does the agent behave in this
   case?
   -----------------------------------------------------------------

   1) Yes, unused(0) is removed.

   2) The description is updated with:

   Bits are exclusive with each other for a specific WLAN Id, and only
   one tunnel mode could be configured.  If 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."

   T11.  What is the persistency of the capwapDot11WlanTunnelMode at
   agent reboot?  Is the whole table persistent at agent reboot?

   -----------------------------------------------------------------

   Yes, it should be whole table persistent instead of previous
   statement "Values of all read-create objects in this table are
   persistent at restart/reboot."

   T12.  I do not understand how does row creation in the
   capwapDot11WlanBindTable work.  It is indexed by ifIndex and
   capwapDot11WlanId.  The only visible object in this table except
   RowStatus is capwapDot11WlanBssIfIndex which is read-only and the
   description says that 'it is the same interface as identified by the
   same value of ifIndex.  But the manager cannot read its value until
   the row exists.  How does the manager know its value in order to
   create the row in the table?

   ----------------------------------------------------------------

   The old description would lead to misunderstanding when it says "The
   interface identified by a particular value of this index is the same
   interface as identified by the same value of ifIndex".  In fact, the
   ifIndex here is not a ifIndex in the INDEX { ifIndex (it is a
   "Wireless virtual radio interface), capwapDot11WlanId }, while it is
   a "WLAN "WLAN BSS Interface".

   To clarify it, the following text is added to the description of
   capwapDot11WlanBindBssIfIndex:

   The ifIndex here is for an interface of 'WLAN BSS Interface'.  For a
   WLAN configuration on a radio, an interface of 'WLAN BSS Interface'
   will correspond to it.  The creation operation of a row object on the
   capwapDot11WlanBindTable would trigger AC system to automatically
   create a 'WLAN BSS Interface' and it is identified by ifIndex.  It
   does not require operator to manually create a 'WLAN BSS Interface'.

   For the table of capwapDot11WlanBindTable, the description is updated
   with the following text:

   A table of objects that configure which WLAN (identified by
   capwapDot11WlanId) will be provided on which 'WTP Virtual Radio
   Interface' (identified by ifIndex) Also, display and control the
   mapping relationship between interface of 'WTP Virtual Radio
   Interface' interface and interface of 'WLAN BSS Interface'.  The PHY
   address for interface of 'WTP Virtual Radio Interface' ifType will be
   base BSSID address for PHY radio.

   Values of all bjects in this table are persistent at restart/reboot.

   For the table of capwapDot11WlanBindEntry, the description is updated
   with the following text:

   A set of objects that display the mapping relationship between
   interface of 'WTP Virtual Radio Interface' and interface of 'WLAN BSS
   Interface'.  The Index object ifIndex is a ifIndex of a 'WTP Virtual
   Radio Interface'.

   T13.  Is the capwapDot11WlanBindTable persistent at agent reboot?

   -----------------------------------------------------------------

   Yes, The whole table is persistent at restart/reboot.

   E1.  Not all acronyms are expanded at first occurrence - e.g.  WTP

   -----------------------------------------------------------------

   The Terminology section is updated with more Terminology such as
   CAPWAP,WTP,AC, Wireless Binding,Split and Local MAC and so on.

   E2.  Please avoid using the construct 'the MIBs' (e.g. in Section 5).
   s/the MIBs/the MIB modules/

   -----------------------------------------------------------------

   use either "MIB module" or "MIB modules" in the document

   E3.  There is no need to include sections 6.1 and 6.2, they provide
   no new or specific information for this MIB module.

   ----------------------------------------------------------------

   Yes, they were removed
   E4.  I suggest for this document to be verified by a native English
   speaker for English spelling and grammar.

   E5. ifIndex, ifDescr, ifName, ifAlias in the WLAN Service Interface
   and WLAN BSS Interface table contain no specific information, I
   suggest to just mention that they are used as per RFC 2863

   --------------------------------------------------------------

   The section for interpration of specific MIB objects in the iftable
   was removed in the new version.  Reader could refer to RFC2863

Other changes made by authors:
1) reorganized the section of overview, and divided it into the
following sub sections:
   5.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     5.1.  Requirements and Constraints . . . . . . . . . . . . . . .  5
     5.2.  Mechanism of Reusing Wireless Binding MIB Module . . . . .  5

2) Update some words in progress),
                                                 October 2008.

14.2.  Informative References

   [RFC3410]                                     Case, J., Mundy, R.,
                                                 Partain, D., the section of" Example of CAPWAP-DOT11-MIB
Module Usage, especially explain how interfaces of
"WLAN service Interface" and B.
                                                 Stewart, "Introduction "WLAN BSS Interface" are created.

3) Modify the value scope of CapwapDot11WlanIdTC from (1, 16) to
(1, 512), and Applicability
                                                 Statements for
                                                 Internet-Standard
                                                 Management Framework",
                                                 RFC 3410,
                                                 December 2002. description of it.

Authors' Addresses

   Yang Shi (editor)
   H3C Tech. Co., Ltd
   Digital Technology Plaza, NO.9 Shangdi 9th Street,Haidian District,
   Beijing
   China(100085)

   Phone: +86 010 82775276
   EMail: young@h3c.com

   David Perkins (editor)
   SNMPinfo
   288 Quailbrook Ct San Carlos,
   CA 94070
   USA

   Phone: +1 408 394-8702
   EMail: dperkins@snmpinfo.com
   Chris Elliott (editor)
   Cisco Systems, Inc.
   7025 Kit Creek Rd., P.O. Box 14987 Research Triangle Park
   27709
   USA

   Phone: +1 919-392-2146
   EMail: chelliot@cisco.com

   Yong Zhang (editor)
   Fortinet, Inc.
   1090 Kifer Road
   Sunnyvale, CA 94086
   USA

   EMail: yzhang@fortinet.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.