WO2001024445A9 - SYSTEM AND METHOD FOR SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) v3 MODEMS TO INTEROPERATE WITH SNMPv1/v2c MODEMS - Google Patents

Abstract

A method for initializing an SNMPv3 cable modem to operate concurrently with other SNMPv1/v2c cable modems on an SNMPv1/v2c managed network. During initialization (100), the SNMPv3 cable modem will obtain information of location and name of a configuration file that the modem downloads (101). The SNMPv3 modem generates an access control object (102) that allows the SNMPv3 modem to operate in SNMPv1/v2c mode (104). The configuration file comprises an element that initializes the SNMPv3 modem in SNMPv3 mode (105) and causes the modem to translate the content of the access control object into corresponding SNMPv3 MIB elements (106). This translation process allows the SNMPv3 modem to process and receive SNMPv1/v2c commands (107).

Description

SYSTEM AND METHOD FOR SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) v3 MODEMS TO INTEROPERATE WITH SNMPvl/v2c MODEMS

BACKGROUND 1. Technical Field:

The present application relates generally to a system and method for providing coexistence between SNMP (Simple Network Management Protocol) vl/v2c and v3 agents and, in particular, to a system and method that allows a SNMPv3 DOCSIS (Data Over Cable Systems Interface Specifϊcations)-enabled modem to operate concurrently on a network with SNMPvl/v2c DOCSIS-enabled modems. 2. Description of Related Art:

In general, the SNMP is a standard, application-layer protocol that is employed in a network to facilitate the exchange of management information between networked devices. Although the SNMP standard is continuously emerging, the most recent version of SNMP is version 3, SNMPv3, which is derived from and builds upon both the first and second versions of the SNMP, SNMPvl and SNMPv2c. The SNMPv3 framework defines standard security and access control protocols known, respectively, as the User-Based Security Model (USM) and View-Based Access Control Model (NACM). The SMMPv3 standard (as well as SΝMPvl and v2c) is an extensible "bare-bones" protocol that allows vendors to incorporate proprietary MIB (management information base) elements and applications to execute on top of the S MP standard. SΝMPv3 can be implemented in conjunction with SNMPvl and/or SNMPv2c (i.e., multi-lingual application) with use of appropriate MIB (management information base) elements (as described below).

An SNMP network generally comprises a plurality of distributed SNMP entities each comprising one or more SNMP agents and one or more SNMP managers (although an entity may comprise and agent and manager) that communicate using SNMP messages. An SNMP manager (or NMS (network management station)) is responsible for managing one or more SNMP agents within the domain of the SNMP manager. An SNMP agent is included on each node (or host) of the network (e.g, computer, server, etc) that is managed by an SNMP manager. Each agent is responsible for collecting and maintaining information about its environment and providing such information to a respective SNMP manager and responding to manager commands to alter the local configuration or operating parameters of the managed node.

Fig. 1 illustrates components that are typically included in a SNMPv3 agent as is known by those skilled in the art. This architecture is described in detail, for example, in RFC 2571 /Harrington, et al., "An Architecture for Describing SNMP Management Frameworks," RFC 2571, April 1999. A SNMPv3 agent module 10 comprises an SNMP engine 11, a plurality of agent SNMP applications 12 and a MLB 13. As is known in the art, the agent applications 12 comprise a plurality of applications such as command responder applications, which provide access to management data in the MIB 13, and notification originator applications, which generate asynchronous messages (e.g., traps) . The command responder applications respond to incoming management requests (such as Get and Set PDUs) by first determining if access to the requested management operation is allowed (via the appropriate Access Control Model 17 in the engine 11), retrieving and or setting managed objects (in the MOB 13) based on the request if access is allowed, and then possibly issuing a Response PDU. The specific details of the agent SNMP applications 12 (as well as manager applications) are well-known in the art and a description can be found, for example, in RFC 2573, Levi, et al., "SNMP Applications," RFC 2573, April 1999.

The MIB 13 maintained by the agent is a virtual information store that comprises management information, i.e., current and historical information about the local configuration and traffic of the managed device (node). More specifically, the agent MIB 13 comprises a collection of managed objects within the device to be managed, wherein collections of related objects are defined in MIB modules. The standardized MIB modules include, for example, an SNMP-TARGET-MIB module, which comprises MIB objects that allow remote configuration of the parameters used for generating SNMP messages, a SNMP-NOTIFICATION-MIB module, which comprises MIB elements that allow configuration of the parameters used for generating notifications, a SNMP-USER-BASED-SM-MIB module, which defines the MIB objects for managing the configuration parameters for the USM, a SNMP-NIE -BASED ACM, which defines the MIB elements for managing the configuration parameters for the View-Based Access Control Model, and a SΝMP-COMMUΝITY-MIB module, which defines objects for, mter αliα, mapping between community strings and SΝMPv3 parameters (i.e., it helps support coexistence between SNMPvl, v2c and v3). The agent SNMP engine 11 comprise a dispatcher module 14, a message processing module 15, a security module 16 and an access control module 17. The dispatcher module 14 is responsible for managing traffic, i.e., PDU and message traffic. The message processor module 15 is responsible for encapsulating outgoing PDUs generated by the SNMP applications 12 into SNMP messages(with appropriate header information) for transmission, as well as extracting PDUs from incoming SNMP messages. The specific details of the operation of the dispatcher module and message processing module are described, for example, in RFC 2572, Case, et al., "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC, 2572, April 1999. The security module 16, which implements one or more security models, is responsible for privacy and authentication. In an SNMPv3 mode, the agent 10 implements the standard USM (user-based security model), wherein the configuration parameters for the USM are managed via MIB elements defined by the SNMP-USER-BASED-SM-MIB module (which is described in detail, for example, in RFC 2574, "User-Based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", by Blumenthal et al, April 1999.)

The access control module 17, which implements one or more access control models, is responsible for determining (in response to a call by an SNMP application) whether a specific type of access (read, write) is authorized for a manager requesting to retrieve or modify local MIB managed data, or whether the manager is authorized to receive notifications (traps) from the agent. In an SNMPv3 mode, the agent 10 utilizes the View-based Access Control Model (VACM) to determine whether such access is allowed (the configuration parameters for the VACM are managed via MIB elements defined by the SNMP-VIEW- BASED-ACM-MIB as described in detail, for example, in RFC 2575, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)," by Wijnen, et al, April, 1999).

There are methods for providing coexistence between entities in an SNMP network that support various versions of SNMP in a multi-lingual network, which are well-known by those skilled in the art. These methods are described, for example, in RFC 2576, "Coexistence between Version 1 , Version 2 and Version 3 of the Internet-standard Network Management Framework," by Frye, et al, March 2000. For example, the message processor module 15 of the SNMPv3 agent 10 can support multiple message formats by implementing a

SNMPvl message processing model, a SNMPv2c message processing model, and SNMPv3 message processing model. In addition, the security module 16 can support various security models including the USM, the SNMPvl Community-Based security model and the SNMPv2c community based security modes. RFC 2576 addresses, for example, the processing of protocol operations in multi-lingual implementations, and describes the

SNMPvl/v2c Message Processing Model and the SNMPvl/v2c Community-Based Security

Model. In a multi-lingual application, the local MIB 13 in comprises the SNMP-

COMMUNITY-MIB module which provides mechanisms for adapting SNMPvl (v2c) into the VACM of SNMPv3. The multi -lingual implementations allow SNMP entities in a network to communicate with each other using an SNMP version which both entities support. Various applications and network architectures implement the SNMP framework. For instance, the SNMP p'rotocol has been selected as the communications protocol for management of DOCSIS (Data Over Cable Service Interface Specifications)-based cable modem systems. The DOCSIS cable modems are configured with SNMP agents, which allows a manager (operator of the DOCSIS cable modem system) to remotely manage and configure the cable modems of the end users. In the current DOCSIS framework, the access of an SNMP manager to the local MIB objects residing in a given cable modem (via an SNMP agent) is controlled, inter alia, via an access control table referred to as docsDevNmAccessTable. The docsDevNmAccessTable, which is defined in a DOCS- CAB LE-DEVICE-MIB module, provides means for restricting access to particular network management stations over particular interfaces using specific community strings. The docsDevNmAccessTable and associated parameters are well known in the art (a detailed description can be found in the proposed standard RFC 2669, M. St Johns, "DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems", RFC2669, August, 1999).

The current DOCSIS standard and associated DOCSIS cable modem system infrastructure, however, only supports SNMPv/v2c and does not provide a standard protocol for initializing a cable modem in SNMPv3 mode. Indeed, because a SNMPv3-enabled cable modem must implement the VACM protocol for access control, and since the docsDevNmAccessTable can only be implemented in conjunction with SNMPvl/v2c cable modems (i.e., docsDevNmAccessTable is not compatible with SNMPv3 modems), SNMPv3 cable modems cannot be readily implemented in SNMPvl/v2c-enabled cable modem networks. Accordingly, a system and method that would allow SNMPv3 cable modems to operate concurrently with SNMPvl/v2 cable modems in a DOCSIS-based cable modem system is highly desirable.

SUMMARY OF THE INVENTION The present invention is generally directed to a system and method for initializing an SNMPv3 device to operate concurrently with other SNMPvl/v2c devices on a SNMPvl/v2c managed network. In one aspect of the present invention, a method for initializing a SNMP (simple network management protocol) v3 device to operate on a SNMPvl/v2c network comprises the steps of: generating an SNMPvl/v2c access control object in the SNMPv3 device; translating parameters of the SNMPvl/v2c access control object to corresponding parameters of an SNMPv3 access control object; and utilizing the SNMPv3 access control object to process SNMPvl/v2c commands. The present invention is preferably implemented in a DOCSIS-based cable modem system wherein SNMPv3 cable modems are automatically configured to operate concurrently with SNMPvl/v2c cable modems and communicate with SNMPvl/v2c managers. During initialization/registration in the DOCSIS system, a SNMPv3 cable modem will download a configuration file comprising elements that allows the SNMPv3 modem to generate the appropriate entries in the docsDevNmAccessTable and set the SNMPv3 modem in a SNMPvl/v2c mode of operation. Preferably, the configuration file comprises a proprietary element which, when read by the SNMPv3 modem, causes the modem to translate the content of the docsDevNmAccessTable into appropriate SNMPv3 MIB elements that would allow the SNMPv3 modem to operate in v3 mode, while at the same time, allow the SNMPv3 cable modem to process and receive SNMPvl/v2c commands using, e.g., VACM, and enforcing the same access rules as specified by the docsDevNmAccessTable (notwithstanding that the docsDevNmAccessTable is not utilized for checking access rights of managers during a SNMPv3 mode of operation). BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 is a block diagram of an architecture of a conventional SNMPv3 agent;

Fig. 2 is a block diagram of a system that allows a SNMPv3 modem to operate concurrently with SNMPvl/v2c modems on a SNMPvl/v2c network according to a preferred embodiment of the present invention;

Fig. 3 is a high-level flow diagram of a method for initializing a SNMPv3 modem to operate concurrently with SNMPvl/v2c modems on a SNMPvl/v2c network according to one aspect of the present invention; and

Figs. 4a and 4b comprise a flow diagram of a method for translating a SNMPvl/v2c access control MIB element of a modem to SNMPv3 MIB elements according to one aspect of the present invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The present invention may be implemented in various forms of hardware, software, firmware, special purpose processors, or a combination thereof. Preferably, the present invention is implemented in software as an application comprising program instructions that are tangibly embodied on one or more program storage devices (e.g., magnetic floppy disk, RAM, CD ROM, ROM, Flash memory, etc.) and executable by any device, machine or platform comprising suitable architecture. It is to be further understood that because some of the system components and method steps depicted are preferably implemented in software, the actual connections between the system components (or the process steps) may differ depending upon the manner in which the present invention is programmed.

Referring to Fig. 2, system 20 comprises a DOCSIS cable modem system that provides transparent bi-directional transfer of Internet Protocol (IP) packets (received transmitted over a backbone network 24, e.g., the Internet) between a CMTS (cable modem termination system) 25 and a plurality of cable modems 27, 29 over an all coaxial or hybrid-fiber/coaxial (HFC) cable network 26. As is known in the art, the CMTS 25 performs functions such as providing an interface between IP traffic and RF (radio frequency) modulation/transmission of the IP packets and assigning IP addresses to the cable modems 27, 29. It is to be understood that two cable modems 27, 29 are shown for illustrative purposes, but the system 20 may comprise hundreds of cable modems. The system 20 comprises a NMS (network management station) 21 located on the backbone network 24 for managing the CMTS 25 and DOCSIS cable modems 27 and 29.

The NMS 21 comprises a user interface 22 (e.g., a GUI (graphic user interface)) and a

SNMPvl /v2c manager 23 of conventional architecture for communicating with the SNMP agents 28, 30 of cable modems 27, 29 via SNMP messages. It is to be understood that the

SNMP agents 28, 30 comprise the agent architecture illustrated in Fig. 1, except that the

SNMPvl/v2c agent 30 does not implement the SNMPv3 message processing model, USM and VACM. The system 20 further comprises a remote server facility 31 that is accessible by the cable modems 27, 29 for, e.g., downloading a configuration file comprising parameters that are used for configuring the cable modems 27, 29. For instance, the configuration file comprises objects that are used by the SNMPvl/v2c agent 30 in modem 29 to build the docsDevNmAccessTable and allow the SNMPvl/v2c agent to readily process and receive SNMPvl/v2c messages from the SNMPvl/v2c manager 23 using methods known in the art. In accordance with the present invention, the same objects in the configuration file are used by the SNMPv3 agent to place the cable modem 27 in SNMPvl/v2 mode for communication with the SNMPvl/v2c manager 23. Furthermore, in accordance with the present invention, a proprietary mechanism (i.e., not a DOCSIS standard) is provided that allows cable modem 27 to enter a SNMPv3 mode, wherein the SNMPv3 agent is configured for receiving and processing SNMPvl/v2c messages from, and otherwise communicating with, the SNMPvl /v2c manager 23. In a preferred embodiment, this mechanism is provided via "translation software" that is provided within the cable modem 27, which when executed, translates the parameters of the docsDevNmAccessTable at runtime into the appropriate SNMPv3 parameters (i.e., MIB elements) that allow the cable modem 27 to enter in SNMPv3 mode and process and receive SNMPvl/v2c commands from the SNMPvl/v2c manager 23. Preferably, the "translation" process is triggered by the presence of a proprietary element in the configuration file, referred to herein as tceKickStartMgrPublic2 (configuration file element 181). Advantageously, this translation process allows SNMPv3 cable modems to operate concurrently in the SNMPvl/v2c DOCSIS framework. A preferred translation process will be described in further detail below with reference to the flow diagrams of Figs. 3, 4a and 4b. Referring now to Fig. 3, a high-level flow diagram illustrates a method for initializing a SNMPv3 modem to operate concurrently with SNMPvl/v2c modems on a SNMPvl/v2c network according to one aspect of the present invention. A preferred process begins with cable modem initialization (e.g., reboot, power up) (step 100). In the DOCSIS framework, the initialization process comprises establishing network connectivity, wherein the cable modem transmits a DHCP (dynamic host configuration protocol) request to the CMTS to obtain an IP address and other parameters that are needed to establish IP connectivity. The CMTS will transmit a DHCP response comprising, e.g., the name and location, e.g., the IP address of a TFTP (trivial file transfer protocol) server (such as the remote server 31 in Fig. 2) of a configuration file that is accessible by the cable modem.

Using the information in the DHCP response, the SNMPv3 cable modem will download the appropriate configuration file via TFTP (step 101). The configuration file comprises standard configuration settings and vendor-specific configuration settings. Using the appropriate configuration settings, the SNMPv3 cable modem will generate the docsDevNmAccessTable (step 102). At this point, the SNMPv3 cable modem will be in a SNMPvl/v2c mode. If the configuration file does not contain proprietary configuration elements to initialize the cable modem into SNMPv3 mode (negative result in step 103), the cable modem will remain in SNMPvl/v2c mode (step 104). In SNMPvl/v2c mode, the docsDevNmAccessTable controls SNMP access by the SNMPvl/v2c manager and determines where traps are sent. In addition, the SNMPv3 modem will only accept and process SNMPvl/v2c packets. Any received SNMPv3 packets will be discarded.

On the other hand, the SNMPv3 cable modem will be configured in SNMPv3 mode if the configuration file comprises proprietary elements for initializing the cable modem in SNMPv3 mode (affirmative result in step 103). One step for initializing the cable modem into SNMPv3 mode comprises entering the initial SNMPv3 privacy/authentication keys into the modem (step 105). This step is beyond the scope of the present application and will not be discussed in detail herein. At the present, there is no final approved DOCSIS standard for initializing a cable modem in SNMPv3 mode and any suitable method may be used. A preferred initialization process using a Diffie-Hellman key exchange process between the agent and manager is discussed in detail in a PCT patent application entitled "System and Method For Initializing A Simple Network Management Protocol (SNMP) Agent," Attorney

Docket No. RCA 89826, filed concurrently herewith.

Briefly, with this process, the cable modem comprises a TCE-DCM105-MIB module that defines MIB elements referred to as tceDCMlOSKickstartMyPublic and tceDCM105KickstartMgrPublic . The manager will generate a Diffie-Hellman public value and pass its public value to the cable modem (agent) via the configuration file. The modem generates its random number and public value via Diffie-Hellman. The cable modem publishes its public value in the MIB object tceDCM105KickstartMyPublic and the public value of the CMTS in the MIB object tceDCM105KickstartMgrPublic. An initial SNMPv3 user named "docsislnit" of security level noAuthNoPriv is created. The SNMP manager reads the public value of the modem in tceDCMlOSKickstartMyPublic (via a SNMP "Get" command) using this user name. In addition, a SNMPv3 user named "docsisProv" of security level AuthPriv created. The SNMP manager generates its random number and uses its random number and the public value of the modem to compute a secret key (which is the same secret key computed by the modem using its random number and public value of the SNMP manager). The secret key is then converted into a readable 16 character password. The SNMP manager may then create other SNMPv3 users by accessing the SNMP-USER- BASED-SM-MIB and SNMP-VIEW-BASED-ACM-MIB using the user name "docsisProv" and the password for both authentication and privacy in the AuthPriv security level. It is to be appreciated that with the preferred Diffie-Hellman key exchange process, the configuration file may pass the Diffie-Hellman public value of the SNMP manager to the cable modem in one of several ways:

1) Using an SNMP MIB Object (Configuration file element type 11) to set tceDCMlOSKickstartMgrPublic; 2) Using a proprietary DHCP option type referred to as tceDCM105KicktartMgrPublic (182) (which is passed in the DHCP response); or 3) Using a proprietary configuration file object type tceKickStartMgrPublic (180). These 3 methods produce the equivalent results but using the proprietary configuration file object has the advantage of not causing SNMPvl/v2c capable only modems to reject the configuration file because they do not understand the SNMP MIB object that sets tceDCMlOSKickstartMgrPublic MIB element.

Another process for initializing the cable modem into SNMPv3 mode comprises translating the content of the docsDevNmAccessTable into the appropriate SNMPv3 MIB elements of the NOTIFICATION-MEB, TARGET-MIB, USER-BASED-SM-MIB, VTEW- BASED-ACM-MIB AND COMMUNITY-MIB modules (step 106). The details of this translation process are described below with reference to Figs. 4a and 4b. Preferably, this translation process is triggered by the presence of a proprietary configuration element referred to herein as tceKickStartMgrPublic2 (configuration file element 181). It is to be understood that the tceKickStartMgrPublic2 may also comprise the configuration parameters to pass the public value of the manager as per the Diffie-Hellman key exchange process described above.

After the translation process (step 106), the SNMPv3 cable modem will operate in SNMPv3 mode and process SNMPvl/vc2 packets using the MIB elements generated from the translation of the docsDevNmAccessTable (step 107). In the SNMPv3 mode, the USM and VACM are used to control access to MIB elements in the cable modem. In addition, the SNMP-NOTIFICATION-MIB is used to determine where to send traps and whether a trap or inform shall be sent. When the SNMPv3 modem receives an SNMPvl/v2c packet, the packet is processed using known methods as described in RFC 2576. For instance, SNMP- COMMUNITY-MIB is used to map the SNMPvl/v2c community strings into user names. An SNMPvl/v2c request will only be processed if there are entries in the SNMPV3 User, Group, View and Access Tables allowing the community string in the SNMPvl/v2c packet to be used in the NoAuthNoPriv security level. It is to be understood that in the SNMPv3 mode, the docsDevNmAccessTable will have no effect and will be disregarded. The cable modem will remain in the SNMPv3 mode until a reboot or reset event (step 108).

Figs. 4a and 4b comprise a flow diagram of a method for translating a SNMPvl/v2c access control MIB element of a cable modem to SNMPv3 MIB elements to allow the modem to operate in a SNMPv3 mode in a SNMPvl/v2c network according to one aspect of the present invention. In particular, the method of Fig. 4 illustrates details of the translation process (step 106, Fig. 3) for translating the contents of the docsDevNmAccessTable into the SNMPv3 User tables and NOTIFICATION-MIB. As indicated above, this method allows concurrent operation of SNMPvl /v2 modems and SNMPv3 modems in an SNMPvl/v2c network. The following steps are performed by the cable modem if the tceKickStartMgrPublic2 configuration element is present in the configuration file.

The first phase of a preferred translation process (steps 200-208) comprises translating the parameters in the docsDevNmAccessTable associated with managers that are authorized to receive traps (wherein the associated securityNames referred to herein being with "@").

Referring now to Fig. 4a, initially, an entry (snmpNotifyEntry) is created in the table snmpNotifyTable to specify the management targets set forth in the docsDevNmAccessTable that are authorized to receive traps (step 200). As in known in the art, the snmpNotifyTable (which is part of the SNMP-Notification-MIB module) is a table that comprises entries that are used to select of set of management targets which should receive notifications, as well as the type of notification which should be sent to each of the selected management targets. In particular, the snmpNotifyEntry generated (in step 200) comprises the following object values:

snmpNotifyName is set to "(^docsDevNmAccessTable"; snmpNotifyTag is set to a tag value of "@ docsDevNmAccessTable"; and snmpNotifyType is set to "Trap" (which is the value " 1 " as per the ^' NOTIFICATION-MIB).

Next, the entries (rows) in the docsDevNmAccessTable are searched in order of index to find an entry (i.e., docsDevNmAccessEntry) for which the authorized access of the manager comprises traps and an IP address that is not set to the default value (step 201). In particular, the docsDevNmAccessEntry?, are examined to find an entry having a value of docsDevNmAccessControl that specifies (i) traps only (i.e., value "6"), (ii) read with traps (i.e., value "4"), or (iii) read-write with traps (.e., value "5"), and a trap receiver (i.e., docsDevNmAccessIp) with IP address equal to a particular value, a.b.c.d., and not the default value of 255.255.255.255. If an entry is found having the above specified object values (affirmative result in step

202), a corresponding entry is generated in the snmpT rgetAddrTable to specify the_. transport address of the manager (step 203). More specifically, an entry, snmpTargetAddrTableEntry, is created in the snmpTar get Addr able comprising the following object values:

snmpTargetAddrName is set to "@ docsDevNmAcess.a.b.c.d"; - snmpTargetAddrTDomain is set to "IP"; snmpTargetAddrTAddress is set to "a.b.c.d:<port>; snmpTargetAddrTimeout is set to "0"; snmpTargetAddrRetryCount is set to "0"; snmpTargetAddrTagList is set to "©docsDevNmAccessTable"; and - snmpTargetAddrParams is set to "@docsDevNmAccess.a.b.c.d."

The value "<port>" in the object snmpTargetAddrTAddress specifies the port at the target address to send for traps. This value is preferably determined by the value of a proprietary

MIB element referred to herein as tceDCMlOSTrapPort which is initialized to a default value by the configuration file. In addition, this value may also be set via an SNMP "Set" command. Alternatively, this value may be set to the default value of "162" if such element does not exist (i.e., port 162 is typically used for listening for traps)..

Next, a corresponding entry, snmpTargetParamsEntry, is created in the snmpTargetParamsTable to specify the SNMP message parameters associated with the manager (step 204). More specifically, an entry is generated in the snmpTargetParamsTable comprising the following object values:

snmpTargetParamsName is set to " @docsDevNmAccess.a-b.c.d. "; snmpTargetParamsMP Model is set to "SNMPvl " or SNMPv2c (depending on the MIB element tceDCM105TrapType); snmpTargetParamsSecurity Model is set to "SNMPvl " or "SNMPv2C" (depending on the MIB element tceDCM105TrapType) nmpTargetParamsSecurityName is set to "@<community_string><n>" where "n" is the index of the entry in the docsDevNmAccessTable being processed; and snmpTargetParamsSecurityLevel is set to "NoAuthNoPriv". It is to be appreciated that steps 201, 203, and 204 are used for translating the parameters (associated with managers that receive traps) in the docsDevNmAccessTable into the appropriate elements in the SNMP-NOTIFICATION-MIB and SNMP-TARGET-MIB. These MIB modules provide a mechanism for the SNMPv3 agent to identify the management targets to which notifications are sent. It is to be noted that the snmpNotifyTag (set in step 200) of the snmpNotifyTable points (i.e., is linked) to the snmpTargetTagList (set in step 203) in the snmpTargetAddrTable (i.e., the are the same value ©docsDevNmAccessTable). It is to be further noted that the snmpTargetAddrParams value (set in step 203) in the snmpTargetAddrTable points to the snmpTargetParamsName (set in step 204) in the snmpTargetParamsTable (i.e., they are the same value @docsDevNmAccess.a.b.c-d.).

Next, a corresponding entry, snmpCommunityEntry, is created in the snmpCommunityTable to allow the outgoing SNMPvl /v2c trap to contain the correct community string (step 205). Community strings are used in outgoing traps as a way of tagging the data so the trap receiver can limit which traps it processes (e.g., the trap receiver can be set to only process traps that comprise a particular community string). The community string is derived from the docsDevNmAccessCommunity (octet string) parameter in the given docsDevNmAccessEntry. More specifically, an entry is generated in the snmpCommunityTable comprising the following object values:^'

snmpCommunitylndex is set to "@docsDevNmAccess<n>" (where the value of <n> is the line number of the entry from the docsDevNmAccessTable); snmpCommunityName is set to "<community_string>"; snmpCommunitySecurityName is set to "@ <community_string><n>"; - snmpContextEnginelD is set to the local snmpEnginelD (of the agent's

SNMP engine); snmpCommunityContextName is set to the "empty string"; and snmpCommunityTransportTag is set to the "empty string".

It is to be appreciated that step 205 allows the outgoing SNMPvl /v2c trap to contain the community string specified in the docsDevNmAccessCommunitv parameter in the given docsDevNmAccessEntry. It is to be noted that the snmpCommunitySecurityName (set in step 205) in the snmpCommunityTable is linked to the smnpTargetParamsSecurityName

(set in step 204) in the snmpTargetParamsTable (i.e., they are the same value

@community_string><n>). The next step is to generate a corresponding entry, usmUserEntry, in the usmUserTable to specify the manager as an authorized user for the USM (step 206). More specifically, an entry in generated in the usmUserTable comprising the following object values:

- usm UserEnginelD is set to the agent's own snmpEnginelD value; usmUserName is set to "@<community_stringXn>" usmSecurityName is set to @<community_string><ιι>"; usmUserAuthProtocol is set to "usmNoauthProtocol; and usmUserPrivProtocol is set to "usmNoPrivProtocol" .

It is to be noted that the usmSecurityName is linked to the smnpTargetParamsSecurityName in the snmpTargetParamsTable.

Next, a corresponding entry, vacmSecurityToGroupEntry, is created in the vacmSecurityToGroupTable to map the SNMPv3 parameters of the manager to a group name, wherein the entry comprises the following object values:

vacmSecurityModel is set equal to the snmpSecurit Model value associated with SNMPvl or SNMPv2C (depending on MIB element tceDCMl 05TrapType); - vacmSecurityName is set equal to "@<community_stringXn>"; vacmGroupName is set_. to "@<communϊty_string><n>".

This step maps a combination of the securityModel and securityName into the groupName @<commιmity_string><n> which is used as an index into the vacmAccessTable to select an access control policy. Note that the vacmSecurityName in the vacmSecurityToGroupTable is linked to the snmpTargetParamsSecurityName in the snmpTargetParamsTable. The next step is to generate a corresponding entry, vacmAccessEntry, in the vacmAccessTable, to define the access rights of the manager via VACM (step 208) with respect to receiving traps. This entry, which is indexed by the objects vacmGroupName,

"@<community_string><n>" , vacmAccessContextPrefix, vacmAccessSecurityModel, and vacmAccessSecurityLevel, comprises the following object values:

vacmContextPrefix is set to the "empty string"; vacmSecurityModel is set to the value of snmpSecurityModel associated with

SNMPvl or SNMPv2C (depending on MIB element tceDCM105TrapType); - vacmSecurityLevel is set equal to "noAuthNoPriv"; vacmContextMatch is set equal to "exact" (which is integer value 1); vacmAccessReadViewName is set equal to the "empty string" (i.e., no access granted); vacmAccessWriteViewName is set equal to the "empty string" (i.e., no access granted); and vacmAccessNotifyViewName is set equal to "docsDevNmAccessTable".

This step establishes that the manager has access to a MIB view called docsDevNmAccessTable, which links to the vacmViewTreeFamilyTable (discussed below). In other words, the value of vacmAccessNotifyViewName identifies the MIB view of the

SNMP context to which this row authorizes access for notifications. The identified MIB view is that one for which the vacm ViewTreeFamilyviewName has the same values of the instance of this object.

This process of translating the parameters associated with trap receivers (steps 203- 208) is repeated for each entry in the docsDevNmAccessTable having a value of docsDevNmAccessControl that specifies (i) traps only (i.e., value "&'), (ii) read with traps (i.e., value "4"), or (iii) read-write with traps (,e., value "5"), and a trap receiver (i.e., docsDevNmAccessIp) with IP address equal to a.b.c.d. (i.e., not a default value 255.255.255.255) (step 201). This iterative process ends when no entries are found in the docsDevNmAccessTable having these specified values (negative determination in step 202). The next phase of the docsDevNmAccessTable translation process comprises replicating the Management stations that are allowed access (wherein the associated security names start with "$"). Referring to Fig. 4b, this process begins with the step of creating one entry in the vacmViewTreeFamilyTable to specify the OID view of the MIB view for all the managers (step 209). More specifically, a single entry in generated in the vacmViewTreeFamilyTable comprising the following object values:

vacmViewTreeFamilyViewName is set to "docsDevNmAccessTable"; vacm ViewTreeFamilySubtree is set to " 1.3."; - vacmViewTreeFamilyMask is set to the "empty string"; and vacm ViewTreeFamilyType is set to "included".

This entry established that the managers are provided an MIB view to all subviews in the Internet (i.e., IOD 1.3). This is consistent with the access policy of the docsDevNmAccessTable which does not allow restriction of access to certain portions of an MIB view tree (i.e., the only option is all read or all read/write). Only one row is created in the vacmViewTreeFamilyTable because all managers have the same view (in accordance with the access policy of docsDevNmAccessTable). It is to be noted that the vacmAccessNotifyViewName (set in step 208) in the vacmAccessTable is linked to the vacm ViewTreeFamilyViewName (set in step 209) in the vacmViewTreeFamilyTable (i.e., they are both set to docsDevNmAccessTable).

Then, the entries in the docsDevNmAccessTable are searched in order of index to find an entry for which the authorized access of the manager comprises read and/or write access (step 210). More specifically, the entries are searched for an entry having a docsDevNmAccessControl object that specifies (i) read with traps 4), (ii) read/write with traps (5), (iii) read (2) or (iv) read/write (3) access in docsDevNmAccessTable. If an entry is found with the one of the above specified parameters (affirmative result in step 211), then a corresponding entry, snmpCommunityEntry, is created in the snmpCommunityTable to map the community string of the manager to the SNMPv3 parameters required for VACM (step 212). The community string is derived from the docsDevNmAccessCommunity (octet string) parameter in the given docsDevNniAccessEntry. More specifically, an corresponding entry is generated in the snmpCommunityTable comprising the following object values:

snmpCommunitylndex is set equal to "$docsDevNmAccess<n>", where <n> is the row number of the corresponding entry in the docsDevNmAccessTable; snmpCommunityName is set equal to " <community_string>"; snmpCommunitySecurityName is set equal to "$<community_string><n>", where <n> is equal to the row number in docsDevNmAccessTable; snmpCommunityContextEnginelD is set equal to the value of agent's snmpEnginelD; and snmpCommunityContextName is set equal to the "empty string".

Furthermore, if the associated docsDevNmAccessIP field is set to 255.255.255.255 (affirmative result in step 213), then the value of snmpCommunityTransportTag is set to the "empty string" (step 214) and the process commences with step 219. On the other hand, if the docsDevNmAccessIP field is not set to 255.255.255.255 (negative determination in step 213), the value of snmpCommunityTransportTag is set equal to "$docsDevNmAccess<n>".

Next, a corresponding entry is generated in the snmpTargetAddrTable to specify, e.g., the transport address of the associated manager (step 216), wherein the entry comprises the following object values with the following values of object instances:

snmpTargetAddrName is set to "$docsDevNmAccess<n>"; snmpTargetAddrTDomain is set to IP; snmp Target AddrTaddr ess is set to "a.b.c.d:00", where a.b.c.d is the docsDevNmAccessIP field value; snmpTargetAddr Timeout is set to "0"; snmpTargetAddrRetryCount is set to "0 " ; snmpTargetAddrTaglist is set to "$docsDevNmAccess<n>"; and snmpTargetAddrParams is set equal to the "empty string". Next, to augment the associated entry in the snmpTargetAddrTable, an entry, snmpTargetAddrExtEntry, is created in the snmpTar get AddrExtT able (step 217). This allows certain fields of the allowed IP address to be masked as is known in the art. More specifically, an entry is generated comprising the following values of object instances:

snmpTargetAddrName set to "$docsDevNmAccess<n>"; snmpTargetAddrTMask is set equal to the corresponding value of docsDevNmAccessIpMask (in the given entry of the docsDevNmAccessTable) plus two zero bytes at the end (for the port number position); and - snmpTargetAddrNMS is set equal to 0.

Next, a corresponding entry, usmlfserEntry, is generated in the usmUserTable to specify the associated manager as a user for USM (step 218). More specifically, an entry is generated in the usmUserTable comprising the following object values:

usmUserName is set to "$<community_string><n>"; usmSecurityName is set to "$<community_string><n>"; usmUserAuthProtocol is set to "usmNoauthProtocol; and usmUserPrivProtocol is set to "usmNoPrivProtocol" .

Next, a corresponding entry, vacmSecurityToGroupEntry, is generated in the vacmSecurityToGroupTable to map the SNMPv3 parameters of the associated manager to a group name (step 219), wherein the entry comprises the following object values:

- vacmSecurityModel is set equal to the snmpSecurityModel value associated with SNMPv2C; vacmSecurityName is set equal to "$<community_striEg><n>"; and vacmGroupName = "$<community_string><n>". This step maps a combination of the securityModel and securityName into the groupName

$<community_stringXn> which is used as an index into the vacmAccessTable to select an access control policy.

The next step is to create an entry, vacmAccessEntry, in the vacmAccessTable, to define the access rights of the manager via VACM (step 208) with respect to read and/or write access (step 22). This entry, which is indexed by the objects vacmGroupName,

"$<community_string><n>", vacmAccessContextPreβx, vacmAccessSecurityModel, and vacmAccessSecurityLevel, comprises the following object values:

- vacmContextPrefix is set equal to the "empty string"; vacmSecurityModel is set equal to the value of snmpSecurityModel associated with SNMPv2C; vacmSecurityLevel is set equal to "noAuthNoPriv"; vacmContextMatch is set equal to "exact" (which is integer value 1); - vacmAccessReadViewName is set to either the "empty string" (i.e., no access granted) or docsDevNmAccessTable (depending on the value of docsDevNmAccessControl); vacmAccessWriteViewName is set to the "empty string" (i.e., no access granted) or docsDevNmAccessTable (depending on the value of docsDevNmAccessControl); and vacmAccessNotifyViewName is set to "docsDevNmAccessTable".

This process of translating the parameters associated with the read/write access rights of the managers (steps 212-220) is repeated for each entry in the docsDevNmAccessTable having at least one value of docsDevNmAccessControl as specified in step 210 above. This iterative process ends when no entries are found in the docsDevNmAccessTable having these specified values (negative determination in step 211), in which instance, the docsDevNmAccessTable translation process terminates.

The following illustrates experimental results of a test of the implementation of the preferred translation process of the docsDevNmAccessTable as described above. Initially, -a reboot process was executed on a DOCSIS-enabled CM1 modem comprising the proprietary CM15 software code loaded into it. Next, a test menu, which is accessible by the serial port on the modem, was used to print the contents of the docsDevNmAccessTable as set forth in the following Table:

docsDevNmA ccessTable

The following Tables illustrate the relevant contents of the SNMPv3 tables that were printed out from the modem after the translation process, wherein the term "0-LOS" refers to Zero Length Octet String:

snmpCommunityTable

snmpNotify Table

snmpTargetAddrTable

snmp Tar get A ddrExtTable

snmpTargetParamsTable

SnmpNotifyFiUerProfileTable

snmpNotifyFϊlterTable

usmUserTable

vacmSecurityTo Group Table

GroupName SecurityModel SecurityName

©publicl SNMPvl ©publicl

$public2 SNMPv2c $public2

$private3 SNMPv2c $private3

vacmAccessTable (Match; l=Exact)

vacm View TreeFamilyTable

The configuration file read by the modem sets up the docsDevNmAccessTable as it was printed out above. The configuration file.also contains a TCE proprietary element named tceDCM105KickStart2 which places the modem in SNMPv3 mode and translates the content of the docsDevNmAccessTable to the above SNMPv3 tables. By comparing the printout of tceDCM105KickStart2 which places the modem in SNMPv3 mode and translates the content of the docsDevNmAccessTable to the above SNMPv3 tables. By comparing the printout of the above docsDevNmAccessTable and the SNMPv3 tables, it is shown that the translation process operates as designed. Advantageously, the present invention allows concurrent operation of both

SNMPvl/v2c capable only modems and SNMPv3 modems with the SNMPv3 modems automatically capable of accepting SNMPvl/v2c commands as well as SNMPv3 commands.

This method allows SNMPv3 cable modems to process and receive SNMPvl/v2c commands, enforcing the same access rules as specified by the docsDevNmAccessTable using VACM, notwithstanding that the docsDevNmAccessTable is not utilized for checking access rights of managers during a SNMPv3 mode of operation..

Another advantage associated with the present invention is that the inclusion of proprietary program code in the SNMPv3 modem to automatically control the translation of the docsDevNmAccessTable to the appropriate SNMPv3 MIB elements relieves the network operator of the burdensome responsibility of having to manually set up the appropriate MIB tables and elements via MIB elements in the configuration file, wherein the configuration file would require a multitude of MIB elements to perform this process. With the present invention, the only responsibility of the network operator is to insert the necessary command elements in the configuration file to trigger the translation process in the modem. Moreover, the present invention readily provides backward compatibility to existing

DOCSIS cable modem system infrastructures which implement SNMPvl/v2c managers since the configuration file will not be rejected by cable modems that solely implement SNMPvl/v2c. Indeed, the SNMPvl/v2c modems will simply ignore the proprietary command element in the configuration file that is read by the SNMPv3 modems to initialize the modem and commence the translation process.

Claims

1. A method for initializing a SNMP (simple network management protocol) v3 device to operate on a SNMPvl /v2c network, comprising the steps of: generating an SNMPvl/v2c access control object in the SNMPv3 device; translating parameters of the SNMP l/v2c access control object to corresponding parameters of an SNMPv3 access control object; and utilizing the SNMPv3 access control object to process SNMPvl/v2c commands.

2. The method of claim 1, wherein the SNMPv3 device- comprises a DOCSIS (data over cable service interface specifications) cable modem and wherein the SNMPvl/v2c access control object comprises a docsDevNmAccessTable.

3. The method of claim 2, wherein the step of generating the SNMPvl/v2c access control object comprises downloading a configuration file from a remote entity, and dynamically generating the SNMPvl/v2c access control object using elements comprising the configuration file.

4. The method of claim 3, wherein the step of translating comprises setting an element in the configuration file that causes the SNMPv3 device to automatically begin the translation process.

5. The method of claim 2, wherein the step of translating comprises the steps of: identifying an entry in the docsDevNmAccessTable for which authorized access of an associated SNMP manager comprises receiving traps; and generating corresponding values for all identified entries, if any, in objects comprising an SNMP-NOTIFICATION-MIB, SNMP-TARGET-MIB, SNMP-COMMUNITY-MIB, USER-BASED-SM-MIB AND VIEW-BASED-ACM-MIB modules.

6. The method of claim 5, wherein a corresponding value for an identified entry is determined based on a proprietary MIB element in the SNMPv3 device.

7. The method of claim 2, wherein the step of translating comprises: identifying an entry in the docsDevNmAccessTable for which authorized access of an associated SNMP manager comprises one of read access, write access, and a combination thereof; and generating corresponding values for all identified entries, if any, in objects comprising an SNMP-TARGET-MIB, SNMP-COMMUNITY-MIB, USER-BASED-SM-MIB AND VIEW-BASED-ACM-MIB modules.

8. A program storage device readable by a SNMPv3 device, tangibly embodying a program of instructions executable by the SNMPv3 device to perform method steps for initializing the SNMPv3 device to operate on a SNMPvl/v2c network, the method steps comprising: generating an SNMPvl/v2c access control object in the SNMPv3 device; translating parameters of the SNMPvl/v2c access control object to corresponding parameters of an SNMPv3 access control object; and utilizing the SNMPv3 access control object to process SNMPvl/v2c commands.

9. The program storage device of claim 8, wherein the SNMPv3 device comprises a

DOCSIS (data over cable service interface specifications) cable modem and wherein the SNMPvl/v2c access control object comprises a docsDevNmAccessTable.

10. The program storage device of claim 9, wherein the instructions for generating the SNMPvl/v2c access control object comprises instructions for performing the steps of: downloading a configuration file from a remote entity; and dynamically generating the SNMPvl/v2c access control object using elements comprising the configuration file.

11. The program storage device of claim 10, wherein the instructions for translating comprise instructions for reading an element in the configuration file; and automatically commencing the translation process upon reading the element.

12. The program storage device of claim 9, wherein the instructions for translating comprise instructions for performing the steps of: identifying an entry in the docsDevNmAccessTable for which authorized access of an associated SNMP manager comprises receiving traps; and generating corresponding values for all identified entries, if any, in objects comprising an SNMP-NOTIFICATION-MIB, SNMP-TARGET-MIB, SNMP-COMMUNITY-MIB, USER-BASED-SM-MIB AND VIEW-BASED-ACM-MIB modules.

13. The program storage device of claim 12, wherein the instructions for generating a corresponding value for an identified entry comprises instructions for reading a proprietary

MIB element residing in the SNMPv3 to determine the corresponding value.

14. The program storage device of claim 9, wherein the instructions for translating comprise instructions for performing the steps of: identifying an entry in the docsDevNmAccessTable for which authorized access of an associated SNMP manager comprises one of read access, write access, and a combination thereof; and generating corresponding values for all identified entries, if any, in objects comprising an SNMP-TARGET-MIB, SNMP-COMMUNITY-MIB, USER-BASED-SM-MIB AND VIEW-BASED-ACM-MIB modules.