Internet Engineering Task Force Y. Shi, Ed. Internet-Draft H3C Tech. Co., Ltd Intended status: Standards Track D. Perkins, Ed. Expires: September 4, 2009 SNMPinfo C. Elliott, Ed. Cisco Systems, Inc. Y. Zhang, Ed. Fortinet, Inc. March 3, 2009 CAPWAP Protocol Binding MIB for IEEE 802.11 draft-ietf-capwap-802dot11-mib-03 Status of This Memo This Internet-Draft is submitted to IETF in full conformance with 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 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. Shi, et al. Expires September 4, 2009 [Page 1] Internet-Draft CAPWAP Protocol Binding MIB March 2009 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Requirements and Constraints . . . . . . . . . . . . . . . 5 5.2. Mechanism of Reusing Wireless Binding MIB Module . . . . . 5 6. Structure of the MIB Module . . . . . . . . . . . . . . . . . 6 7. Relationship to Other MIB Modules . . . . . . . . . . . . . . 7 7.1. Relationship to SNMPv2-MIB Module . . . . . . . . . . . . 7 7.2. Relationship to IF-MIB Module . . . . . . . . . . . . . . 7 7.3. Relationship to CAPWAP-BASE-MIB Module . . . . . . . . . . 7 7.4. Relationship to MIB Module in IEEE 802.11 Standard . . . . 8 7.5. MIB modules required for IMPORTS . . . . . . . . . . . . . 8 8. Example of CAPWAP-DOT11-MIB Module Usage . . . . . . . . . . . 8 9. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 11.1. IANA Considerations for CAPWAP-DOT11-MIB Module . . . . . 21 11.2. IANA Considerations for ifType . . . . . . . . . . . . . . 21 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 14.1. Normative References . . . . . . . . . . . . . . . . . . . 21 14.2. Informative References . . . . . . . . . . . . . . . . . . 23 Appendix A. Appendix A. Changes between -03 and -02 . . . . . . . 23 Shi, et al. Expires September 4, 2009 [Page 2] Internet-Draft CAPWAP Protocol Binding MIB March 2009 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 [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 MIB module defined in IEEE 802.11 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 CAPWAP Protocol specification [I-D.ietf-capwap-protocol-specification], the CAPWAP Protocol Binding for IEEE 802.11 [I-D.ietf-capwap-protocol-binding-ieee80211] and CAPWAP Protocol Base MIB [I-D.ietf-capwap-base-mib]. Access Controller (AC): The network entity that provides WTP access to the network infrastructure in the data plane, control plane, management plane, or a combination therein. Wireless Termination Point (WTP): The physical or network entity that contains an RF antenna and wireless 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 Shi, et al. Expires September 4, 2009 [Page 3] Internet-Draft CAPWAP Protocol Binding MIB March 2009 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 WLANs. Each Basic Service Set Identifier (BSSID) and its constituent wireless terminal radios 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. Wireless Binding MIB Module: Other Standards Developing Organizations (SDOs), such as IEEE already defined MIB module for a 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 CAPWAP Protocol Binding for a Wireless binding. Shi, et al. Expires September 4, 2009 [Page 4] Internet-Draft CAPWAP Protocol Binding MIB March 2009 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 [I-D.ietf-capwap-protocol-binding-ieee80211] defines WLAN conception. Also, Local or Split MAC modes could be specified for a WLAN. The MAC mode for a WLAN is not in the scope of IEEE 802.11 [IEEE.802-11.2007]. In such cases, in addition to the existing wireless binding MIB modules defined by other SDOs, a CAPWAP protocol wireless binding MIB module is required to be defined for a wireless binding. 4. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 5. Overview 5.1. 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 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 MUST be able to reuse such MIB objects in the IEEE 802.11 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: - Could easily reuse wireless binding MIB module in the IEEE 802.11 standard; - From AC to centrally manage and configure WLAN; - Operators could configure MAC type and tunnel mode for a specific WLAN. 5.2. Mechanism of Reusing Wireless Binding MIB Module Before coming to details of CAPWAP-DOT11-MIB module, it will introduce how it is able to reuse the MIB module in IEEE 802.11 standard. According to [I-D.ietf-capwap-protocol-binding-ieee80211], each WLAN is identified by WLAN Id. In the MIB module of IEEE 802.11 Shi, et al. Expires September 4, 2009 [Page 5] Internet-Draft CAPWAP Protocol Binding MIB March 2009 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, and consider that the operator has to prepare configurations for each WLAN on the AC before WTPs connect to 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 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 MIB module in the IEEE 802.11 standard. In the CAPWAP-BASE-MIB module, each PHY radio is identified by WTP Id and radio ID, and has a corresponding 'WTP Virtual Radio Interface' on the AC. The IEEE 802.11 MIB module associated with this interface can be used to configure IEEE 802.11 wireless binding parameters for 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 Module The MIB objects were derived from the CAPWAP protocol binding for 802.11 document [I-D.ietf-capwap-protocol-binding-ieee80211]. 1) capwapDot11WlanTable The table is used for providing configuration such as MAC type and so on for WLANs. For a specific WLAN 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 MIB module in IEEE 802.11 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 module, the MIB object dot11AuthenticationAlgorithm in the dot11AuthenticationAlgorithmsTable is corresponding to Auth Type. Considering both capwapDot11WlanTable and dot11AuthenticationAlgorithmsTable use ifIndex as index, CAPWAP- DOT11-MIB module are able to easily reuse dot11AuthenticationAlgorithm object in IEEE 802.11 MIB module. It is same for other objects in the MIB module of IEEE 802.11 standard. 2) capwapDot11WlanBindTable The table provides a way to bind WLAN to a radio, then supports Shi, et al. Expires September 4, 2009 [Page 6] Internet-Draft CAPWAP Protocol Binding MIB March 2009 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 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 IF-MIB Module The Interfaces Group [RFC2863] defines generic managed objects for managing interfaces. This memo contains the media-specific extensions to the Interfaces Group for managing WLAN that are modeled as interfaces. For each WLAN, it will have a logical interface of 'WLAN Service Interface' responding to it on the AC. The interface 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, and reuse the MIB module in IEEE 802.11 standard. 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. To provide data forwarding service, system will dynamically create logical interface of 'WLAN BSS Interface'. The interface MUST be modeled as an ifEntry and provide appropriate interface information. The interface enables a single physical WTP to support multiple WLANs. 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. 7.3. Relationship to CAPWAP-BASE-MIB Module The CAPWAP-BASE-MIB module provides a way to manage and control WTP and radio objects. Especially, CAPWAP-BASE-MIB module has a mechanism of 'WTP Virtual Radio Interface' which enable system to reuse the MIB module in IEEE 802.11 standard. With it, operator Shi, et al. Expires September 4, 2009 [Page 7] Internet-Draft CAPWAP Protocol Binding MIB March 2009 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 perspective. 7.4. Relationship to MIB Module in IEEE 802.11 Standard Through ifIndex of 'WLAN Service Interface' and 'WLAN BSS Interface' ifType, the MIB module is able to reuse MIB module in the IEEE 802.11 standard [IEEE.802-11.2007]. The CAPWAP-DOT11-MIB module does not duplicate those objects in the MIB module of IEEE 802.11 standard. In the CAPWAP Protocol Binding for IEEE 802.11 [I-D.ietf-capwap-protocol-binding-ieee80211], it involves a part of MIB objects defined by IEEE 802.11 standard. Although CAPWAP-DOT11- MIB module uses it [I-D.ietf-capwap-protocol-binding-ieee80211] as a reference, it could reuse all the MIB objects in the IEEE 802.11 standard , and not limited by the scope of CAPWAP Protocol Binding for IEEE 802.11. 7.5. MIB modules required for IMPORTS The following MIB modules are required for IMPORTS: SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], IF-MIB [RFC2863] and CAPWAP-BASE-MIB [I-D.ietf-capwap-base-mib]. 8. Example of CAPWAP-DOT11-MIB Module Usage The following is a whole example for configuration and management of WTP, radio and WLAN for IEEE 802.11 binding. 1) Identify 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. Suppose a WTP's serial number is '12345678', and first 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) } Shi, et al. Expires September 4, 2009 [Page 8] Internet-Draft CAPWAP Protocol Binding MIB March 2009 By the mechanism of 'WTP Virtual Radio Interface', it seems WTP PHY radios are located on the AC. The interface of 'WTP Virtual Radio Interface' ifType is modeled by 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' ifMtu = 0, ifSpeed = 0, ifPhysAddress = '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 specific wireless binding parameters for 'WTP Virtual Radio Interface' It will be done on the AC through the MIB module defined in IEEE 802.11 standard. For example, to configure parameter for 'WTP Virtual Radio Interface' by Dot11OperationTable [IEEE.802-11.2007]. Shi, et al. Expires September 4, 2009 [Page 9] Internet-Draft CAPWAP Protocol Binding MIB March 2009 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 WLAN configuration will be done through CAPWAP-DOT11-MIB Module, and the MIB module defined in IEEE 802.11 standard First step is to create a 'WLAN Service Interface' through 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 CapwapDot11WlanTable { capwapDot11WlanId = 1, capwapDot11WlanServiceIfIndex = 20, capwapDot11WlanMacType = splitMAC(2), capwapDot11WlanTunnelMode = dot3Tunnel(2), capwapDot11WlanRowStatus = create } The creation operation of a row object would trigger AC system to automatically create a 'WLAN Service Interface' 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 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'. Shi, et al. Expires September 4, 2009 [Page 10] Internet-Draft CAPWAP Protocol Binding MIB March 2009 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' 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 MIB module defined in IEEE 802.11 standard 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 to WTP radio On the AC, through CapwapDot11WlanBindTable in the CAPWAP-DOT11-MIB, it configures which WLAN (identified by capwapDot11WlanId) will be provided on which 'WTP Virtual Radio Interface' (identified by ifIndex). Shi, et al. Expires September 4, 2009 [Page 11] Internet-Draft CAPWAP Protocol Binding MIB March 2009 Here supposes to bind a WLAN (capwapDot11WlanId is 1) with a interface of 'WTP Virtual Radio Interface'(ifIndex is 10). The CapwapDot11WlanBindTable would create a row object for it. In CapwapDot11WlanBindTable { ifIndex = 10, capwapDot11WlanId = 1, capwapDot11WlanBindBssIfIndex = 30, 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, operator could query WTP and radio statistics data through CAPWAP-BASE-MIB and CAPWAP-DOT11-MIB module. For example, through dot11CountersTable [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, operator could query the configuration of WLAN through Dot11AuthenticationAlgorithmsTable [IEEE.802-11.2007] and statistic data of 'WLAN BSS Interface' through ifTable; 9. Definitions Shi, et al. Expires September 4, 2009 [Page 12] Internet-Draft CAPWAP Protocol Binding MIB March 2009 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 "200903030000Z" -- 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 Shi, et al. Expires September 4, 2009 [Page 13] Internet-Draft CAPWAP Protocol Binding MIB March 2009 Email: yzhang@fortinet.com" DESCRIPTION "Copyright (C) 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 CAPWAP Protocol binding for IEEE 802.11." REVISION "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. 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 of 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 } -- capwapDot11WlanTable Table capwapDot11WlanTable OBJECT-TYPE SYNTAX SEQUENCE OF CapwapDot11WlanEntry Shi, et al. Expires September 4, 2009 [Page 14] Internet-Draft CAPWAP Protocol Binding MIB March 2009 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that display and control WLANs. Values of all objects in this table are persistent at restart/reboot." ::= { capwapDot11Objects 1 } capwapDot11WlanEntry OBJECT-TYPE SYNTAX CapwapDot11WlanEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that display and control WLANs." INDEX { capwapDot11WlanId } ::= { capwapDot11WlanTable 1 } CapwapDot11WlanEntry ::= SEQUENCE { capwapDot11WlanId CapwapDot11WlanIdTC, capwapDot11WlanServiceIfIndex InterfaceIndex, capwapDot11WlanMacType CapwapBaseMacTypeTC, capwapDot11WlanTunnelMode CapwapBaseTunnelModeTC, 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." ::= { 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 Shi, et al. Expires September 4, 2009 [Page 15] Internet-Draft CAPWAP Protocol Binding MIB March 2009 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, operator will prepare configuration for them. For a specific WLAN, a logical interface of 'WLAN Service Interface' ifType will be created by system, and 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], 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 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' [I-D.ietf-capwap-protocol-binding-ieee80211], With the way of 'WLAN Service Interface', it will easily reuse MIB table like dot11AuthenticationAlgorithmsTable in the IEEE 802.11 standard, while only care for other configurations like capwapDot11WlanTunnelMode." ::= { 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." ::= { 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, and only one tunnel mode could be configured. If operator set more than one bit, the value of the Shi, et al. Expires September 4, 2009 [Page 16] Internet-Draft CAPWAP Protocol Binding MIB March 2009 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." ::= { capwapDot11WlanEntry 4 } capwapDot11WlanRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table." ::= { capwapDot11WlanEntry 5 } -- End of 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 Shi, et al. Expires September 4, 2009 [Page 17] Internet-Draft CAPWAP Protocol Binding MIB March 2009 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 { capwapDot11WlanBindBssIfIndex InterfaceIndex, capwapDot11WlanBindBssRowStatus RowStatus } 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. 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'. The PHY address for 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 } capwapDot11WlanBindBssRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row Shi, et al. Expires September 4, 2009 [Page 18] Internet-Draft CAPWAP Protocol Binding MIB March 2009 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 module." MODULE -- this module MANDATORY-GROUPS { capwapDot11WlanGroup, capwapDot11WlanBindGroup } ::= { capwapDot11Compliances 1 } capwapDot11WlanGroup OBJECT-GROUP OBJECTS { capwapDot11WlanServiceIfIndex, capwapDot11WlanMacType, capwapDot11WlanTunnelMode, capwapDot11WlanRowStatus } STATUS current DESCRIPTION "The collection of objects which are used to configure property of WLAN." ::= { capwapDot11Groups 1 } capwapDot11WlanBindGroup OBJECT-GROUP OBJECTS { capwapDot11WlanBindBssIfIndex, capwapDot11WlanBindBssRowStatus } STATUS current DESCRIPTION "The collection of objects which are used to configure Shi, et al. Expires September 4, 2009 [Page 19] Internet-Draft CAPWAP Protocol Binding MIB March 2009 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 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 Shi, et al. Expires September 4, 2009 [Page 20] Internet-Draft CAPWAP Protocol Binding MIB March 2009 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, Sachin Dutta, Yujin Zhao, Haitao 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 Shi, et al. Expires September 4, 2009 [Page 21] Internet-Draft CAPWAP Protocol Binding MIB March 2009 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-03 (work in progress), November 2008. [I-D.ietf-capwap-protocol-specification] Montemurro, M., Stanley, D., and P. Calhoun, "CAPWAP Protocol Specification", draft- ietf-capwap-protocol- specification-15 (work in progress), 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- Shi, et al. Expires September 4, 2009 [Page 22] Internet-Draft CAPWAP Protocol Binding MIB March 2009 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, . 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 Shi, et al. Expires September 4, 2009 [Page 23] Internet-Draft CAPWAP Protocol Binding MIB March 2009 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". Shi, et al. Expires September 4, 2009 [Page 24] Internet-Draft CAPWAP Protocol Binding MIB March 2009 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. Shi, et al. Expires September 4, 2009 [Page 25] Internet-Draft CAPWAP Protocol Binding MIB March 2009 ----------------------------------------------------------------- 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? Shi, et al. Expires September 4, 2009 [Page 26] Internet-Draft CAPWAP Protocol Binding MIB March 2009 ----------------------------------------------------------------- 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'. Shi, et al. Expires September 4, 2009 [Page 27] Internet-Draft CAPWAP Protocol Binding MIB March 2009 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 Shi, et al. Expires September 4, 2009 [Page 28] Internet-Draft CAPWAP Protocol Binding MIB March 2009 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 the section of" Example of CAPWAP-DOT11-MIB Module Usage, especially explain how interfaces of "WLAN service Interface" and "WLAN BSS Interface" are created. 3) Modify the value scope of CapwapDot11WlanIdTC from (1, 16) to (1, 512), and 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 Shi, et al. Expires September 4, 2009 [Page 29] Internet-Draft CAPWAP Protocol Binding MIB March 2009 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 Shi, et al. Expires September 4, 2009 [Page 30]