Internet Engineering Task Force Y. Shi, Ed. Internet-Draft J. Wang, Ed. Intended status: Standards Track Hangzhou H3C Tech. Co., Ltd Expires: December 31, 2009 June 29, 2009 A Generic MIB for Centralized Network Architecture draft-richard-opsawg-cna-mib-00 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 December 31, 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 the managed objects for a generic model to manage the Shi & Wang Expires December 31, 2009 [Page 1] Internet-Draft Centralized Network Architecture MIB June 2009 centralized network architecture. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Internet-Standard Management Framework . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. The function of Tunnel Protocols . . . . . . . . . . . . . 4 5.2. Requirements and Constraints . . . . . . . . . . . . . . . 5 5.3. Network Access Technologies' MIB Modules . . . . . . . . . 5 5.4. Design Objectives . . . . . . . . . . . . . . . . . . . . 5 5.5. Design Idea . . . . . . . . . . . . . . . . . . . . . . . 6 5.6. Reusing the MIB Modules of Network Access Technologies . . 6 5.7. TP Profile . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Structure of the MIB Module . . . . . . . . . . . . . . . . . 7 7. Relationship to Other MIB Modules . . . . . . . . . . . . . . 8 7.1. Relationship to SNMPv2-MIB Module . . . . . . . . . . . . 8 7.2. Relationship to IF-MIB Module . . . . . . . . . . . . . . 8 7.3. Relationship to ENTITY-MIB Module . . . . . . . . . . . . 9 7.4. Relationship to Network Access Technologies' MIB Modules . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.5. MIB Modules Required for IMPORTS . . . . . . . . . . . . . 9 8. Example of CNA-MIB Module Usage . . . . . . . . . . . . . . . 10 9. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 34 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 11.1. IANA Considerations for CNA-MIB Module . . . . . . . . . . 35 11.2. IANA Considerations for ifType . . . . . . . . . . . . . . 35 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 13.1. Normative References . . . . . . . . . . . . . . . . . . . 36 13.2. Informative References . . . . . . . . . . . . . . . . . . 36 Shi & Wang Expires December 31, 2009 [Page 2] Internet-Draft Centralized Network Architecture MIB June 2009 1. Introduction The emergence of centralized IEEE 802.11 Wireless Local Area Network (WLAN) architectures, in which simple IEEE 802.11 Wireless Termination Points(WTPs) are managed by an Access Controller (AC), suggested that a standards-based, interoperable protocol could radically simplify the deployment and management of wireless networks. The IETF CAPWAP WG defines a such Protocol [RFC5415] which enables an Access Controller (AC) to manage a collection of WTPs. It is evident that the wired access network could use a similar architecture as centralized WLAN architectures. In this document, it calls both the centralized wireless and wired access network as the Centralized Network Architectures(CNA). This document defines a generic MIB module that can be used to manage the Centralized Network Architectures. This MIB module covers both configuration and network status-monitoring, and provides a way to reuse MIB modules defined by IETF or other Standards Developing Organizations (SDOs). 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 terminologies in the document are defined by referring to the CAPWAP Protocol specification [RFC5415] and the Architecture Taxonomy for CAPWAP [RFC4118]. Station (STA): A device that contains an interface to a wireless or wired medium (WM), and it access the network by certain access technologies. Termination Point (TP): The physical or network entity that contains wireless or wired PHY to transmit and receive station traffic. Shi & Wang Expires December 31, 2009 [Page 3] Internet-Draft Centralized Network Architecture MIB June 2009 Access Controller (AC): The network entity that provides TP access to the network infrastructure in the data plane, control plane, management plane, or a combination therein. There are several connectivity options to consider between the AC(s) and the TPs, including direct connection, L2 switched connection, and L3 routed connection. The communication PHY medium between TP and AC could be wired or wireless. Tunnel Protocol: It is a protocol defining AC and TP control and data plane communication. The protocol of CAPWAP[RFC5415] could be a candidate. Centralized Network Architecture: It is an emerging hierarchical architecture utilizing one or more centralized controllers for managing a large number of TP devices. It can be said that the full wireless or wired functions are implemented across multiple physical network devices, namely, the TPs and ACs. Autonomous Network Architecture: It is the traditional autonomous architecture, in which each TP is a single physical device that implements all the wireless or wired services. 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. The function of Tunnel Protocols The SNMP based management model of centralized network architectures is the SNMP agent run on the AC side, and AC could send configuration to TPs by the tunnel protocol. Although the MIB is independent of any tunnel protocols between AC and TPs, the following list outlines the basic operations that are typically performed between the TP and the AC in their typical order: 1. Discovery: The TPs discover the AC with which they will be bound to and controlled by. 2. Authentication: After discovery, the TP device authenticates itself with the AC. 3. TP Association: After successful authentication, a TP registers with the AC in order to start receiving management and configuration messages. Shi & Wang Expires December 31, 2009 [Page 4] Internet-Draft Centralized Network Architecture MIB June 2009 4. Firmware Download: After successful association, the TP may pull, or the AC may push, the TPs firmware. 5. Control Channel Establishment: The TP establishes either an IP- tunnel or performs Ethernet encapsulation with the AC in order to transfer data traffic and management frames. 6. Configuration Download: Following the control channel establishment process, the AC may push configuration parameters to the TPs. 5.2. Requirements and Constraints The Generic MIB for Centralized Network Architecture (CNA-MIB) is designed to: - Support centralized management and monitoring of TPs from the AC; - Allow operators to prepare configurations for TPs to be managed before they connect to the AC and to change TPs' configuration after they connect to the AC; - Support displaying of TPs' current state and configuration; - Provide basic property information about the AC, TP, interface and station; - Provide counters for events on TPs and interfaces such as reboot and hardware failure; - Provide various notifications such as channel up and interface failure. 5.3. Network Access Technologies' MIB Modules User could access the network by wireless or wired medium. For a specific network access technology, it usually defines the MIB modules on its own. For example, the ADSL MIB WG in the IETF defines several MIB modules for ADSL access technology, such as [RFC2662], [RFC4319]. IEEE 802.11 WG defines 802.11 MIB modules [IEEE.802-11.2007] for WLAN access technology. 5.4. Design Objectives This document brings forward a mechanism to avoid redefining MIB objects in the existing MIB modules, in other words, a mechanism to reuse MIB modules defined by IETF and other SDOs. Shi & Wang Expires December 31, 2009 [Page 5] Internet-Draft Centralized Network Architecture MIB June 2009 In summary, the CNA-MIB module has the following design objectives: - To implement an architecture that uses SNMP for the management and control of centralized network architecture, and answering the operator's requirements for centralized management; - To be independent of network access technologies(wireless or wired), and be able to reuse such technologies' MIB Modules; - To be independent of any tunnel protocols between AC and TPs; - To enable interoperability between vendors; - To meet requirements for the centralized network architecture. 5.5. Design Idea The basic design idea of the CNA-MIB module is: - The SNMP agent MUST be run on the AC devices, and it is NOT REQUIRED on the TP devices. It follows the same model as the centralized network architecture: Centralized Control; - It is designed to accommodate the specific needs of each network access technology in a standard way; - The ifIndex [RFC2863] is used as a common handler for corresponding interfaces in the CNA-MIB and the MIB modules of specific wireless or wired technologies; - The operator could manage and control the centralized network architectures using multiple MIB modules defined by multiple SDOs, while keeping them loosely coupled. 5.6. Reusing the MIB Modules of Network Access Technologies For any network access technology, the configuration and management of interface is very important, and a technology usually already defines the MIB modules on their own. For example, the MIB tables such as Dot11OperationTable [IEEE.802-11.2007] are able to support WLAN radio interface configuration, while the MIB tables such as adslLineTable [RFC2662] are able to support ADSL interface configuration. These tables use the ifIndex as index, and work well under autonomous network architecture. To reuse such MIB modules is very important to centralized network architectures. In the centralized network architectures, each TP could be identified by a TP Id which usually use the base MAC address Shi & Wang Expires December 31, 2009 [Page 6] Internet-Draft Centralized Network Architecture MIB June 2009 of the TP. For the interfaces in the TP, each interface could be identified by the interface Id. As a generic method, a specific PHY interface could be identified by the combination of the identifiers of the TP and interface Id (TP Id + Interface Id). so the key point is to make use of the ifIndex idea and requires a way to maintain the mappings between 'TP Id + interface Id' and the ifIndex. As the ifIndex can identify an interface in an abstract way, and it does NOT care for an interface's PHY location (either on the TP or AC). The AC can have TP Virtual Interfaces to logically represent PHY interfaces on the TP. It looks like that PHY interfaces are located on the AC, and PHY location of the TP (interface) is hidden to the operator. The operator can operate interfaces through MIB tables with the ifIndex of a TP Virtual Interface. As a type of abstract interface, the TP Virtual Interface could be used by any network access technology such as ADSL and IEEE 802.11. The table of cnaInterfaceMappingTable in the CNA-MIB module is used to store the mappings between the 'TP Id+ Interface Id' and the ifIndex. 5.7. TP Profile In the centralized network architecture, a TP profile is used to make configurations such as the name of a TP before and after it connects to the AC. It MUST contain an Id of a TP to manage and usually use the base MAC address of the TP, and the tunnel protocol message received from the TP MUST contains its base MAC address. The AC uses the base MAC address to find the corresponding TP profile. Another important function of TP profile is to trigger the creation of TP Virtual Interfaces on the AC. To implement this function, a TP profile MUST include the TP's model name [RFC4133], which reflects the number of PHY interfaces on the TP. In this way, the creation of a TP profile triggers the AC to automatically create the same number of TP Virtual Interfaces corresponding to the TP's PHY interfaces without manual intervention. With the ifIndexes of TP Virtual Interfaces, the operator could configure and manage the TP's PHY interfaces through the MIB modules of specific network access technologies. 6. Structure of the MIB Module 1) cnaTpProfileTable The TP profile table is used to configure the TP profiles for TPs to be managed before they connect to the AC. An operator could change a TP's current configuration by changing the values of parameters in the corresponding TP profile. 2) cnaTpTable Shi & Wang Expires December 31, 2009 [Page 7] Internet-Draft Centralized Network Architecture MIB June 2009 The TPs table is used display properties of TPs such as the base MAC address, work state and so on, and helps operator to query TPs' current configuration. 3) cnaInterfaceMappingTable The interface mapping table is used to display the mappings between TP Virtual Interfaces and PHY interfaces, and the ifType of the PHY interface. 4) cnaStationTable The station table is used for providing stations' basic property information. 5) cnaTpEventsStatsTable The TP events statistic table is used for collecting TP reboot count, link failure count, hardware failure count and so on. 6) cnaInterfaceEventsStatsTable The interface events statistic table is used for collecting interface reset count, hardware failure count and so on. 7. Relationship to Other MIB Modules 7.1. Relationship to SNMPv2-MIB Module The CNA-MIB module does not duplicate the objects of the 'system' group in the SNMPv2-MIB [RFC3418] that is defined as being mandatory for all systems, and the objects apply to the entity as a whole. The 'system' group provides identification of the management entity and certain other system-wide data. 7.2. Relationship to IF-MIB Module The Interfaces Group [RFC2863] defines generic managed objects for managing interfaces. This memo contains the media-specific extensions to the Interfaces Group for managing TP PHY interfaces that are modeled as interfaces. The IF-MIB module is required to be supported on the AC. Each PHY interface on the TP corresponds to a TP Virtual Interface on the AC. The TP Virtual Interface provides a way to configure the interface's parameters and query interface's traffic statistics, and reuse the MIB modules defined by specific network access technologies. The interface MUST be modeled as an ifEntry and provide appropriate Shi & Wang Expires December 31, 2009 [Page 8] Internet-Draft Centralized Network Architecture MIB June 2009 interface information. Also, as an ifIndex [RFC2863] is used as a common handler for a corresponding interfaces in the CNA-MIB and specific network access technologies' MIB modules, the AC MUST have a mechanism that preserves the values of the ifIndexes in the ifTable at AC reboot. 7.3. Relationship to ENTITY-MIB Module The ENTITY-MIB module [RFC4133] meets the need for a standardized way of representing a single agent, which supports multiple instances of one MIB. It could express a certain relationship between multiple entities, and provide entity properties for each entity. In the centralized network architecture, the SNMP agent runs on the AC, and is not required on the TP. With the ENTITY-MIB module on the AC, it could keep entity information such as firmware revision and software revision of the AC and TPs. From the ENTITY-MIB module's perspective, the overall physical entity (AC) is a 'compound' of multiple physical entities (that is, the TPs connected to AC), and all entities are each identified by a Physical index. The cnaTpTable of the CNA-MIB module uses the cnaTpPhyIndex object to store the mappings of TP object between CNA-MIB and ENTITY-MIB modules. By combining the MIB modules, operators could query the status and properties of the AC and TPs. For example, they could get a TP's current status through the CNA-MIB module, and a TP's software revision information through the ENTITY-MIB module. The CNA-MIB module does not duplicate those objects defined in the ENTITY-MIB module. 7.4. Relationship to Network Access Technologies' MIB Modules To manage the certain network access technologies, the MIB models for the technologies (such as [IEEE.802-11.2007]) is required to be supported on the AC. Through the ifIndexes of TP Virtual Interfaces, the CNA-MIB module provides a consistent and abstract way of reusing MIB objects in the access technologies' MIB modules. The CNA-MIB module does not duplicate those objects defined in the network access technologies' MIB modules. 7.5. MIB Modules Required for IMPORTS The following MIB module IMPORTS objects from SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], IF-MIB [RFC2863], SNMP- FRAMEWORK-MIB [RFC3411], INET-ADDRESS-MIB [RFC4001] and ENTITY-MIB [RFC4133]. Shi & Wang Expires December 31, 2009 [Page 9] Internet-Draft Centralized Network Architecture MIB June 2009 8. Example of CNA-MIB Module Usage Here takes the ADSL access technology as an example to show how the MIB modules operate. 1) Create a TP profile Suppose the TP's base MAC address is '00-0f-e2-0f-01-01'. Create the TP profiles as follows: In CnaTpProfileTable { cnaTpProfileId = 1, cnaTpProfileName = 'TP Profile 1', cnaTpProfileTPId = '00-0f-e2-0f-01-01', cnaTpProfileTPModelNumber = 'TP123', cnaTpProfileTpName = 'TP 1', cnaTpProfileTpLocation = 'office' } Suppose the TP with model name 'TP123' has one PHY interface and this PHY interface is identified by Id 1. The creation of this TP profile triggers the AC to automatically create a TP Virtual Interface and add a new row object to the CnaInterfaceMappingTable without manual intervention. Suppose the ifIndex of the TP Virtual Interface is 10. The following information is stored in the CnaInterfaceMappingTable. In CnaInterfaceMappingTable { cnaTpProfileId = 1, cnaInterfaceMappingIfId = 1, cnaInterfaceMappingVirtualIfIndex = 10, cnaInterfaceMappingPhyIfType = adsl(94) } The TP Virtual Interfaces on the AC correspond to the PHY interfaces on the TP. The TP Virtual Interface is modeled by ifTable [RFC2863]. Shi & Wang Expires December 31, 2009 [Page 10] Internet-Draft Centralized Network Architecture MIB June 2009 In ifTable { ifIndex = 10, ifDescr = 'TP Virtual Interface', ifType = xxx, RFC Editor - please replace xxx with the value allocated by IANA for IANAifType of TP Virtual Interface ifMtu = 0, ifSpeed = 0, ifPhysAddress = '000000', ifAdminStatus = true(1), ifOperStatus = false(0), ifLastChange = 0, ifInOctets = 0, ifInUcastPkts = 0, ifInDiscards = 0, ifInErrors = 0, ifInUnknownProtos = 0, ifOutOctets = 0, ifOutUcastPkts = 0, ifOutDiscards = 0, ifOutErrors = 0 } 2) Query the ifIndexes of TP Virtual Interfaces Before configuring PHY interfaces, the operator needs to get the ifIndexes of TP Virtual Interfaces corresponding to the PHY interfaces. As CnaInterfaceMappingTable already stores the mappings between PHY interfaces (Interface Id) and the ifIndexes of TP Virtual Interfaces, the operator can get the ifIndex information by querying this table. Such a query operation SHOULD run from interface Id 1 to the maximum value of interface Id, and stop when an invalid ifIndex value (0) is returned. This example uses cnaTpProfileId = 1 and cnaInterfaceMappingIfId = 1 as inputs to query the CnaInterfaceMappingTable, and gets cnaInterfaceMappingVirtualIfIndex = 10. Then it uses cnaTpProfileId = 1 and cnaInterfaceMappingIfId = 2, and gets a invalid ifIndex value (0), so the query operation ends. This method gets not only the ifIndexes of TP Virtual Interfaces, but also the numbers of PHY interfaces. Besides checking whether the ifIndex value is valid, the operator SHOULD check whether the cnaInterfaceMappingPhyIfType is the desired PHY interface type. 3) Configure parameters of a network access technology for a TP Shi & Wang Expires December 31, 2009 [Page 11] Internet-Draft Centralized Network Architecture MIB June 2009 Virtual Interface This configuration is made on the AC through the MIB modules of a specific network access technology, such as the ADSL MIB module [RFC2662]. for example, the operator could use the adslLineConfProfileTable [RFC2662] to create the configuration profile for the ADSL line. Also, operator could set the configuration profile used by the specific ADSL line through the adslLineTable [RFC2662]. In the adslLineTable, each ADSL line could be identified by the ifIndex value of a TP Virtual Interface. 4) Query TP and interface statistics data After TPs start to run, the operator could query TP and interface statistics data through CNA-MIB and a specific access technology's MIB modules on the AC. For example, through adslAtucPerfDataTable [RFC2662], the operator could query the number of loss of framing failures since agent reset using the ifIndex of the corresponding TP Virtual Interface. 5) Query other properties of a TP The Operator could query MIB objects in the ENTITY-MIB [RFC4133] module by using the cnaTpPhyIndex in the cnaTpTable of CNA-MIB module. The properties of a TP such as software version, hardware version are available in the ENTITY-MIB module. 9. Definitions CNA-MIB DEFINITIONS ::= BEGIN IMPORTS PhysAddress, TEXTUAL-CONVENTION, DateAndTime, RowStatus FROM SNMPv2-TC InterfaceIndex FROM IF-MIB PhysicalIndex FROM ENTITY-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB NOTIFICATION-GROUP, OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2, Unsigned32, Counter32 FROM SNMPv2-SMI InetAddressType, InetAddress Shi & Wang Expires December 31, 2009 [Page 12] Internet-Draft Centralized Network Architecture MIB June 2009 FROM INET-ADDRESS-MIB IANAifType FROM IANAifType-MIB; cnaMIB MODULE-IDENTITY LAST-UPDATED "200906290000Z" -- June 29th, 2009 ORGANIZATION "IETF Operations and Management Area Working Group (opsawg) http://www.ietf.org/html.charters/opsawg-charter.html" CONTACT-INFO "General Discussion: opsawg@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/opsawg Yang Shi Beijing R&D Center of H3C, Digital Technology Plaza, NO.9 Shangdi 9th Street,Haidian District,Beijing,China(100085) Email: young@h3c.com Ju Wang H3C Beijing R&D Center, Digital Technology Plaza, NO.9 Shangdi 9th Street,Haidian District,Beijing,China(100085) Email: wangju@h3c.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 the management model of the centralized network architecture." REVISION "2009006290000Z" DESCRIPTION "Initial version published as RFC xxx" ::= { mib-2 xxx } -- Textual Conventions CnaTpProfileIdTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Represents the unique identifier of a TP profile." SYNTAX Unsigned32 (0..4096) CnaTpIdTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "32a" STATUS current DESCRIPTION Shi & Wang Expires December 31, 2009 [Page 13] Internet-Draft Centralized Network Architecture MIB June 2009 "Represents the unique identifier of a TP instance. As usual, a base MAC address of TP is used, which MAY be assigned to the primary Ethernet interface." SYNTAX OCTET STRING (SIZE (0..32)) CnaStationIdTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x:" STATUS current DESCRIPTION "Represents the unique identifier of a station instance. As usual, the MAC address of the station is used." SYNTAX OCTET STRING (SIZE (6)) CnaInterfaceIdTC ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Represents the unique identifier of a PHY interface on a TP." SYNTAX Unsigned32 (0..1024) -- Top level components of this MIB module -- Notifications cnaNotifications OBJECT IDENTIFIER ::= { cnaMIB 0 } -- Tables, Scalars cnaObjects OBJECT IDENTIFIER ::= { cnaMIB 1 } -- Conformance cnaConformance OBJECT IDENTIFIER ::= { cnaMIB 2 } -- AC Objects Group cnaAc OBJECT IDENTIFIER ::= { cnaObjects 1 } cnaTpSessions OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the total number of TPs which are connecting to the AC." ::= { cnaAc 1 } Shi & Wang Expires December 31, 2009 [Page 14] Internet-Draft Centralized Network Architecture MIB June 2009 cnaStationSessions OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the total number of stations which are accessing the wired or wireless service provided by the AC." ::= { cnaAc 2 } -- End of AC Objects Group -- TP Objects Group cnaTps OBJECT IDENTIFIER ::= { cnaObjects 2 } -- cnaTpProfileTable Table cnaTpProfileTable OBJECT-TYPE SYNTAX SEQUENCE OF CnaTpProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that configure TP profiles for TPs to be managed before they connect to the AC. An operator could change a TP's configuration by changing the values of parameters in the corresponding TP profile. Values of all read-create objects in this table are persistent at restart/reboot." ::= { cnaTps 1 } cnaTpProfileEntry OBJECT-TYPE SYNTAX CnaTpProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that configure and display a TP profile." INDEX { cnaTpProfileId } ::= { cnaTpProfileTable 1 } CnaTpProfileEntry ::= SEQUENCE { cnaTpProfileId CnaTpProfileIdTC, cnaTpProfileName SnmpAdminString, cnaTpProfileTpId CnaTpIdTC, cnaTpProfileTpModelNumber SnmpAdminString, cnaTpProfileTpName OCTET STRING, cnaTpProfileTpLocation OCTET STRING, Shi & Wang Expires December 31, 2009 [Page 15] Internet-Draft Centralized Network Architecture MIB June 2009 cnaTpProfileRowStatus RowStatus } cnaTpProfileId OBJECT-TYPE SYNTAX CnaTpProfileIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "Represents the unique identifier of a TP profile." ::= { cnaTpProfileEntry 1 } cnaTpProfileName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "Represents the name of a TP profile." ::= { cnaTpProfileEntry 2 } cnaTpProfileTpId OBJECT-TYPE SYNTAX CnaTpIdTC MAX-ACCESS read-create STATUS current DESCRIPTION "Represents the base MAC address of a TP, which MAY be assigned to the primary Ethernet interface. A TP profile MUST contain the base MAC address of the TP and the tunnel protocol messages received from the TP should contain its base MAC address. The AC uses the base MAC address to find the corresponding TP profile." ::= { cnaTpProfileEntry 3 } cnaTpProfileTpModelNumber OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "Represents the model name of a TP. The preferred value is the customer-visible part number, which may be printed on the TP itself. A TP profile MUST include the TP's model name, which reflects the number of PHY interfaces on the TP. In this way, the creation of a TP profile triggers the AC to automatically create the same number of TP Virtual Interfaces corresponding to the TP's PHY interfaces without manual intervention. With the ifIndexes of TP Virtual Interfaces, the operator could configure and manage Shi & Wang Expires December 31, 2009 [Page 16] Internet-Draft Centralized Network Architecture MIB June 2009 the TP's PHY interfaces through the certain network access technologies' MIB Modules." REFERENCE "Section 3. of Entity MIB (Version 3), the MIB object entPhysicalModelName, RFC 4133." ::= { cnaTpProfileEntry 4 } cnaTpProfileTpName OBJECT-TYPE SYNTAX OCTET STRING(SIZE(512)) MAX-ACCESS read-create STATUS current DESCRIPTION "Represents the name of the TP." ::= { cnaTpProfileEntry 5 } cnaTpProfileTpLocation OBJECT-TYPE SYNTAX OCTET STRING(SIZE(1024)) MAX-ACCESS read-create STATUS current DESCRIPTION "Represents the location of the TP." ::= { cnaTpProfileEntry 6 } cnaTpProfileRowStatus 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. Deleting a TP profile in use will disconnect the TP to the AC. Therefore, the network management system SHOULD ask the operator to confirm such an operation. When a TP profile entry is removed from the table, the corresponding TP Virtual Interfaces are also removed from the CnaInterfaceMappingTable and ifTable [RFC2863]. Also, the related object instances SHOULD be removed from the MIB modules of the certain network access technologies ." ::= { cnaTpProfileEntry 7 } -- End of cnaTpProfileTable table -- cnaTpTable table cnaTpTable OBJECT-TYPE SYNTAX SEQUENCE OF CnaTpEntry Shi & Wang Expires December 31, 2009 [Page 17] Internet-Draft Centralized Network Architecture MIB June 2009 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that indicates each TP's current state, and helps operator to query the TPs' current configuration." ::= { cnaTps 2 } cnaTpEntry OBJECT-TYPE SYNTAX CnaTpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that display the TP's current state. Also, operator could query current configuration for a TP by identifier of a TP profile." INDEX { cnaTpId } ::= { cnaTpTable 1 } CnaTpEntry ::= SEQUENCE { cnaTpId CnaTpIdTC, cnaTpBaseMacAddress PhysAddress, cnaTpIpAddressType InetAddressType, cnaTpIpAddress InetAddress, cnaTpState INTEGER, cnaTpCurrTpProfileId CnaTpProfileIdTC, cnaTpPhyIndex PhysicalIndex } cnaTpId OBJECT-TYPE SYNTAX CnaTpIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "Represents the unique identifier of a TP." ::= { cnaTpEntry 1 } cnaTpBaseMacAddress OBJECT-TYPE SYNTAX PhysAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the TP's Base MAC Address, which MAY be assigned to the primary Ethernet interface." ::= { cnaTpEntry 2 } cnaTpIpAddressType OBJECT-TYPE SYNTAX InetAddressType Shi & Wang Expires December 31, 2009 [Page 18] Internet-Draft Centralized Network Architecture MIB June 2009 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the IP address type of a TP." ::= { cnaTpEntry 3 } cnaTpIpAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the IP address of a TP." ::= { cnaTpEntry 4 } cnaTpState OBJECT-TYPE SYNTAX INTEGER { associate(1), image(2), configure(3), run(4), unknown(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the various possible states of TP The following enumerated values are supported: associate(1) - The TP is associating with the AC image(2) - The TP is downloading software configure(3) - The TP is getting configuration from the AC run(4) - The TP comes to run state and could offer the access service to stations unknown(5) - Operator already prepare configuration for the TP, while the TP has not contact with the AC till now" ::= { cnaTpEntry 5 } cnaTpCurrTpProfileId OBJECT-TYPE SYNTAX CnaTpProfileIdTC MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the current identifier of a TP profile. Operator could query a TP' current configuration through it." ::= { cnaTpEntry 6 } cnaTpPhyIndex OBJECT-TYPE SYNTAX PhysicalIndex Shi & Wang Expires December 31, 2009 [Page 19] Internet-Draft Centralized Network Architecture MIB June 2009 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the unique physical index of a physical entity in the ENTITY-MIB module [RFC4133]. The information such as software version of a specific TP could be accessed through the index." ::= { cnaTpEntry 7 } -- End of cnaTpTable Table -- cnaInterfaceMappingTable Table cnaInterfaceMappingTable OBJECT-TYPE SYNTAX SEQUENCE OF CnaInterfaceMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that display the mappings between TP Virtual Interfaces and PHY interfaces, and the ifType of PHY interface. Values of all objects in this table are persistent at restart/reboot." ::= { cnaTps 4 } cnaInterfaceMappingEntry OBJECT-TYPE SYNTAX CnaInterfaceMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that display the mapping between a specific TP Virtual Interface and a PHY interface, and the ifType of PHY interface." INDEX { cnaTpProfileId, cnaInterfaceMappingIfId } ::= { cnaInterfaceMappingTable 1 } CnaInterfaceMappingEntry ::= SEQUENCE { cnaInterfaceMappingIfId CnaInterfaceIdTC, cnaInterfaceMappingVirtualIfIndex InterfaceIndex, cnaInterfaceMappingPhyIfType IANAifType } cnaInterfaceMappingIfId OBJECT-TYPE SYNTAX CnaInterfaceIdTC Shi & Wang Expires December 31, 2009 [Page 20] Internet-Draft Centralized Network Architecture MIB June 2009 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Represents the identifier of a PHY interface on a TP, and only requires unique on a TP. For example, TP A and TP B use a same value of cnaInterfaceMappingIfId for their first interface." ::= { cnaInterfaceMappingEntry 1 } cnaInterfaceMappingVirtualIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the index value that uniquely identifies a TP Virtual Interface. The interface identified by a particular value of this index is the same interface as identified by the same value of the ifIndex. The creation of a TP profile triggers system to automatically create specific number of TP Virtual Interfaces and add new row objects in the cnaInterfaceMappingTable without manual intervention. As most MIB modules such as the IEEE 802.11 MIB module [IEEE.802-11.2007] use an ifIndex to identify an interface for configuration and statistics, it will be easy to reuse such MIB modules through the TP Virtual Interface in the Centralized Network Architecture." ::= { cnaInterfaceMappingEntry 2 } cnaInterfaceMappingPhyIfType OBJECT-TYPE SYNTAX IANAifType MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the type of PHY interface which is corresponding to the ifIndex of the TP Virtual Interface." ::= { cnaInterfaceMappingEntry 3 } -- End of cnaInterfaceMappingTable Table -- cnaStationTable Table cnaStationTable OBJECT-TYPE SYNTAX SEQUENCE OF CnaStationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that display stations which are Shi & Wang Expires December 31, 2009 [Page 21] Internet-Draft Centralized Network Architecture MIB June 2009 associated with the specific interface on the TP. The TP is in running state." ::= { cnaTps 5 } cnaStationEntry OBJECT-TYPE SYNTAX CnaStationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that display a station which is associated with the specific interface on the TP. The TP is in running state." INDEX { cnaStationId } ::= { cnaStationTable 1 } CnaStationEntry ::= SEQUENCE { cnaStationId CnaStationIdTC, cnaStationAssociateTpId CnaTpIdTC, cnaStationAssociateMappingIfId CnaInterfaceIdTC, cnaStationAssociateTime DateAndTime } cnaStationId OBJECT-TYPE SYNTAX CnaStationIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "Represents the unique identifier of the station." ::= { cnaStationEntry 1 } cnaStationAssociateTpId OBJECT-TYPE SYNTAX CnaTpIdTC MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the TP that the station is associated with." ::= { cnaStationEntry 2 } cnaStationAssociateMappingIfId OBJECT-TYPE SYNTAX CnaInterfaceIdTC MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the interface that the station is associated with." ::= { cnaStationEntry 3 } Shi & Wang Expires December 31, 2009 [Page 22] Internet-Draft Centralized Network Architecture MIB June 2009 cnaStationAssociateTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the time when the station is associated with the network." ::= { cnaStationEntry 4 } -- End of cnaStationTable Table -- cnaTpEventsStatsTable cnaTpEventsStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF CnaTpEventsStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that display the TPs' events statistics." ::= { cnaTps 6 } cnaTpEventsStatsEntry OBJECT-TYPE SYNTAX CnaTpEventsStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that display the events statistic data of a TP." INDEX { cnaTpId } ::= { cnaTpEventsStatsTable 1 } CnaTpEventsStatsEntry ::= SEQUENCE { cnaTpEventsStatsRebootCount Counter32, cnaTpEventsStatsLinkFailureCount Counter32, cnaTpEventsStatsSwFailureCount Counter32, cnaTpEventsStatsHwFailureCount Counter32, cnaTpEventsStatsOtherFailureCount Counter32, cnaTpEventsStatsLastFailureType INTEGER, cnaTpEventsStatsLastFailureTime DateAndTime } cnaTpEventsStatsRebootCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of reboots that have occurred due to a Shi & Wang Expires December 31, 2009 [Page 23] Internet-Draft Centralized Network Architecture MIB June 2009 TP crash. A value of 65535 implies that this information is not available on the TP." ::= { cnaTpEventsStatsEntry 1 } cnaTpEventsStatsLinkFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that a tunnel protocol connection with an AC has failed due to link failure." ::= { cnaTpEventsStatsEntry 2 } cnaTpEventsStatsSwFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that a tunnel protocol connection with an AC has failed due to software related reasons." ::= { cnaTpEventsStatsEntry 3 } cnaTpEventsStatsHwFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that a tunnel protocol connection with an AC has failed due to hardware related reasons." ::= { cnaTpEventsStatsEntry 4 } cnaTpEventsStatsOtherFailureCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that a tunnel protocol connection with an AC has failed due to known reasons, other than the AC initiated, link, software or hardware failure." ::= { cnaTpEventsStatsEntry 5 } cnaTpEventsStatsLastFailureType OBJECT-TYPE SYNTAX INTEGER { acInit(1), linkFailure(2), swFailure(3), Shi & Wang Expires December 31, 2009 [Page 24] Internet-Draft Centralized Network Architecture MIB June 2009 hwFailure(4), otherFailure(5), unknown(255) } MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the failure type of the most recent TP failure. The following enumerated values are supported: acInit(1) - The AC initiated linkFailure(2) - Link failure swFailure(3) - Software failure hwFailure(4) - Hardware failure otherFailure(5) - Other failure unknown(255) - Unknown (e.g., TP doesn't keep track of info)" ::= { cnaTpEventsStatsEntry 6 } cnaTpEventsStatsLastFailureTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the time of the most recent TP failure." ::= { cnaTpEventsStatsEntry 7 } -- End of cnaTpEventsStatsTable table -- cnaInterfaceEventsStatsTable table cnaInterfaceEventsStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF CnaInterfaceEventsStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that display statistics on the interface behavior, and reasons why the TP interface has been reset." ::= { cnaTps 7 } cnaInterfaceEventsStatsEntry OBJECT-TYPE SYNTAX CnaInterfaceEventsStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that display the statistic data of events happened on a specific interface of a TP." INDEX { cnaTpId, cnaInterfaceMappingIfId } Shi & Wang Expires December 31, 2009 [Page 25] Internet-Draft Centralized Network Architecture MIB June 2009 ::= { cnaInterfaceEventsStatsTable 1 } CnaInterfaceEventsStatsEntry ::= SEQUENCE { cnaInterfaceEventsStatsResetCount Counter32, cnaInterfaceEventsStatsSwFailCount Counter32, cnaInterfaceEventsStatsHwFailCount Counter32, cnaInterfaceEventsStatsOtherFailCount Counter32, cnaInterfaceEventsStatsUnknownFailCount Counter32, cnaInterfaceEventsStatsConfigUpdateCount Counter32 } cnaInterfaceEventsStatsResetCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that that the interface has been reset." ::= { cnaInterfaceEventsStatsEntry 1 } cnaInterfaceEventsStatsSwFailCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that the interface has failed due to software related reasons." ::= { cnaInterfaceEventsStatsEntry 2 } cnaInterfaceEventsStatsHwFailCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that the interface has failed due to hardware related reasons." ::= { cnaInterfaceEventsStatsEntry 3 } cnaInterfaceEventsStatsOtherFailCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that the interface has failed due to known reasons, other than software or hardware failure." ::= { cnaInterfaceEventsStatsEntry 4 } cnaInterfaceEventsStatsUnknownFailCount OBJECT-TYPE Shi & Wang Expires December 31, 2009 [Page 26] Internet-Draft Centralized Network Architecture MIB June 2009 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that the interface has failed for unknown reasons." ::= { cnaInterfaceEventsStatsEntry 5 } cnaInterfaceEventsStatsConfigUpdateCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the number of times that the interface configuration has been updated." ::= { cnaInterfaceEventsStatsEntry 6 } -- End of cnaInterfaceEventsStatsTable table -- End of TP Objects Group -- Notifications cnaChannelUp NOTIFICATION-TYPE OBJECTS { cnaNtfTpId } STATUS current DESCRIPTION "This notification is sent by the AC when the channel of tunnel protocol is established." ::= { cnaNotifications 1 } cnaChannelDown NOTIFICATION-TYPE OBJECTS { cnaNtfTpId, cnaNtfChannelDownReason } STATUS current DESCRIPTION "This notification is sent by the AC when the channel of tunnel protocol becomes down." ::= { cnaNotifications 2 } cnaConfigMsgError NOTIFICATION-TYPE OBJECTS { Shi & Wang Expires December 31, 2009 [Page 27] Internet-Draft Centralized Network Architecture MIB June 2009 cnaNtfTpId, cnaNtfConfigMsgErrorType, cnaNtfMsgErrorElements } STATUS current DESCRIPTION "This notification is generated when a TP received message elements in the configuration management messages which it was unable to apply locally." ::= { cnaNotifications 3 } cnaInterfaceOperableStatus NOTIFICATION-TYPE OBJECTS { cnaNtfTpId, cnaNtfInterfaceId, cnaNtfInterfaceOperStatusFlag, cnaNtfInterfaceStatusCause } STATUS current DESCRIPTION "The notification is generated when an interface's operational state is changed." ::= { cnaNotifications 4 } -- Objects used only in notifications -- for notifications cnaNotifyVarObjects OBJECT IDENTIFIER ::= { cnaObjects 5 } cnaNtfTpId OBJECT-TYPE SYNTAX CnaTpIdTC MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the unique identifier of a TP." ::= { cnaNotifyVarObjects 1 } cnaNtfInterfaceId OBJECT-TYPE SYNTAX CnaInterfaceIdTC MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the identifier of a PHY interface on a TP, and only requires unique on a TP. For example, TP A and TP B use same value of cnaNtfInterfaceId for their first interface." Shi & Wang Expires December 31, 2009 [Page 28] Internet-Draft Centralized Network Architecture MIB June 2009 ::= { cnaNotifyVarObjects 2 } cnaNtfChannelDownReason OBJECT-TYPE SYNTAX INTEGER { timeout(1), acRebootTp(2), other(8) } MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the reason for Channel down. The following enumerated values are supported: timeout(1) - The keep alive message between the AC and TP is timeout acRebootTp(2) - The AC reboot TP other(8) - other reason" ::= { cnaNotifyVarObjects 3 } cnaNtfInterfaceOperStatusFlag OBJECT-TYPE SYNTAX INTEGER { operable(0), inoperable(1) } MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the operation status of a interface. The following enumerated values are supported: operable(0) - To indicate interface is operable inoperable(1) - To indicate interface is inoperable, and cnaNtfInterfaceStatusCause object will give reason in details" ::= { cnaNotifyVarObjects 4 } cnaNtfInterfaceStatusCause OBJECT-TYPE SYNTAX INTEGER { normal(0), hwError(1), swError(2), adminSet(3) } MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the reason the interface is out of service. The following enumerated values are supported: Shi & Wang Expires December 31, 2009 [Page 29] Internet-Draft Centralized Network Architecture MIB June 2009 normal(0) - Normal status hwError(1) - Hardware failure swError(2) - Software failure adminSet(3) - Administratively set" ::= { cnaNotifyVarObjects 5 } cnaNtfConfigMsgErrorType OBJECT-TYPE SYNTAX INTEGER { unknownElement(1), unsupportedElement(2), unknownValue(3), unsupportedValue(4) } MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the type of configuration message error. The following enumerated values are supported: unknownElement(1) - Unknown message element unsupportedElement(2) - Unsupported message element unknownValue(3) - Unknown message element value unsupportedValue(4) - Unsupported message element value" ::= { cnaNotifyVarObjects 6 } cnaNtfMsgErrorElements OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Represents the message elements sent by the AC in the Configuration Status Response message that caused the error." ::= { cnaNotifyVarObjects 7 } -- Module compliance cnaCompliances OBJECT IDENTIFIER ::= { cnaConformance 1 } cnaGroups OBJECT IDENTIFIER ::= { cnaConformance 2 } cnaCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the CNA-MIB module." MODULE -- this module Shi & Wang Expires December 31, 2009 [Page 30] Internet-Draft Centralized Network Architecture MIB June 2009 MANDATORY-GROUPS { cnaAcNodeGroup, cnaTpProfileGroup, cnaTpGroup, cnaInterfaceGroup, cnaStationGroup } GROUP cnaTpGroup2 DESCRIPTION "The cnaTpGroup2 group is optional." GROUP cnaTpEventsStatsGroup DESCRIPTION "The cnaTpEventsStatsGroup group is optional." GROUP cnaInterfaceEventsStatsGroup DESCRIPTION "The cnaInterfaceEventsStatsGroup group is optional." GROUP cnaNotificationsGroup DESCRIPTION "The cnaNotificationsGroup group is optional." GROUP cnaNotifyVarsGroup DESCRIPTION "The cnaNotifyVarsGroup group is optional. If cnaNotificationsGroup is supported, this group must be implemented." ::= { cnaCompliances 1 } cnaAcNodeGroup OBJECT-GROUP OBJECTS { cnaTpSessions, cnaStationSessions } STATUS current DESCRIPTION "The collection of objects which are used to represent the session information for the AC." ::= { cnaGroups 1 } cnaTpProfileGroup OBJECT-GROUP OBJECTS { cnaTpProfileName, cnaTpProfileTpId, cnaTpProfileTpModelNumber, cnaTpProfileTpName, Shi & Wang Expires December 31, 2009 [Page 31] Internet-Draft Centralized Network Architecture MIB June 2009 cnaTpProfileTpLocation, cnaTpProfileRowStatus } STATUS current DESCRIPTION "The collection of objects which are used to configure the TP profile." ::= { cnaGroups 2 } cnaTpGroup OBJECT-GROUP OBJECTS { cnaTpBaseMacAddress, cnaTpState, cnaTpCurrTpProfileId } STATUS current DESCRIPTION "The collection of objects which are used to represent the TP's Base MAC address, state information and so on." ::= { cnaGroups 3 } cnaTpGroup2 OBJECT-GROUP OBJECTS { cnaTpIpAddressType, cnaTpIpAddress, cnaTpPhyIndex } STATUS current DESCRIPTION "The collection of objects which are used to represent the TP's base MAC address, state information and so on." ::= { cnaGroups 4 } cnaInterfaceGroup OBJECT-GROUP OBJECTS { cnaInterfaceMappingVirtualIfIndex, cnaInterfaceMappingPhyIfType } STATUS current DESCRIPTION "The collection of objects which are used to represent the ifType of the PHY interface, the mappings between the ifIndexes of TP Virtual Interfaces and PHY interfaces." ::= { cnaGroups 5 } cnaStationGroup OBJECT-GROUP OBJECTS { cnaStationAssociateTpId, Shi & Wang Expires December 31, 2009 [Page 32] Internet-Draft Centralized Network Architecture MIB June 2009 cnaStationAssociateMappingIfId, cnaStationAssociateTime } STATUS current DESCRIPTION "A collection of objects which are used to represent the stations' basic properties." ::= { cnaGroups 6 } cnaTpEventsStatsGroup OBJECT-GROUP OBJECTS { cnaTpEventsStatsRebootCount, cnaTpEventsStatsLinkFailureCount, cnaTpEventsStatsSwFailureCount, cnaTpEventsStatsHwFailureCount, cnaTpEventsStatsOtherFailureCount, cnaTpEventsStatsLastFailureType, cnaTpEventsStatsLastFailureTime } STATUS current DESCRIPTION "The collection of objects which are used for collecting TP reboot count, link failure count, hardware failure count and so on." ::= { cnaGroups 7 } cnaInterfaceEventsStatsGroup OBJECT-GROUP OBJECTS { cnaInterfaceEventsStatsResetCount, cnaInterfaceEventsStatsSwFailCount, cnaInterfaceEventsStatsHwFailCount, cnaInterfaceEventsStatsOtherFailCount, cnaInterfaceEventsStatsUnknownFailCount, cnaInterfaceEventsStatsConfigUpdateCount } STATUS current DESCRIPTION "The collection of objects which are used for collecting interface reset count, channel change count, hardware failure count and so on" ::= { cnaGroups 8 } cnaNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { cnaChannelUp, cnaChannelDown, cnaConfigMsgError, cnaInterfaceOperableStatus Shi & Wang Expires December 31, 2009 [Page 33] Internet-Draft Centralized Network Architecture MIB June 2009 } STATUS current DESCRIPTION "The Collection of notifications in this MIB module." ::= { cnaGroups 9 } cnaNotifyVarsGroup OBJECT-GROUP OBJECTS { cnaNtfTpId, cnaNtfInterfaceId, cnaNtfChannelDownReason, cnaNtfInterfaceOperStatusFlag, cnaNtfInterfaceStatusCause, cnaNtfConfigMsgErrorType, cnaNtfMsgErrorElements } STATUS current DESCRIPTION "Objects used for notifications." ::= { cnaGroups 10 } 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: - Unauthorized changes to the cnaTpProfileTable MAY cause operators unable to correctly manage the TPs. For example, if the value of cnaTpProfileTpModelNumber object is incorrect, the TP could not work well. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) MAY be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. The followings are the tables and objects and their sensitivity/vulnerability: - The cnaTpEventsStatsTable exposes TP's failure information. Shi & Wang Expires December 31, 2009 [Page 34] Internet-Draft Centralized Network Architecture MIB June 2009 - The cnaInterfaceEventsStatsTable exposes interface's failure information. 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 CNA-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 ---------- ----------------------- cnaMIB { mib-2 XXX } 11.2. IANA Considerations for ifType Require IANA to assign a ifType for TP Virtual Interface. 12. Acknowledgements The authors wish to thank Fei Fang, Yujin Zhao, Haitao Zhang, Zhifei Zhang. 13. References Shi & Wang Expires December 31, 2009 [Page 35] Internet-Draft Centralized Network Architecture MIB June 2009 13.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. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005. [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, March 2009. 13.2. Informative References [IEEE.802-11.2007] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Shi & Wang Expires December 31, 2009 [Page 36] Internet-Draft Centralized Network Architecture MIB June 2009 requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications", IEEE Standard 802.11, 2007, . [RFC2662] Bathrick, G. and F. Ly, "Definitions of Managed Objects for the ADSL Lines", RFC 2662, August 1999. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4118, June 2005. [RFC4319] Sikes, C., Ray, B., and R. Abbi, "Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines", RFC 4319, December 2005. Authors' Addresses Yang Shi (editor) Hangzhou H3C Tech. Co., Ltd Beijing R&D Center of H3C, Digital Technology Plaza, NO.9 Shangdi 9th Street,Haidian District, Beijing China(100085) Phone: +86 010 82775276 EMail: young@h3c.com Ju Wang (editor) Hangzhou H3C Tech. Co., Ltd Beijing R&D Center of H3C, Digital Technology Plaza, NO.9 Shangdi 9th Street,Haidian District, Beijing China(100085) Phone: +86 010 82774283 EMail: wangju@h3c.com Shi & Wang Expires December 31, 2009 [Page 37]