Method and system for managing a directory service

Abstract

A method and system for managing a distributed directory service. The method includes defining a plurality of objects operative to maintain information about a plurality of partitions in a MIB, implementing the MIB in an agent, loading the agent on a managed server, interfacing the agent with a directory service, and sending a management request from a management station to the agent to access one of the objects. The MIB maintains information about each partition on the managed server, and allows access to such information through conventional network management software.

Claims

What is claimed is:

1. A method for managing a directory service, comprising:

defining a first plurality of objects operative to maintain information about a plurality of partitions in a MIB;

implementing the MIB in an agent;

loading the agent on a managed server;

interfacing the agent with a directory service operative to perform at least one of a directory split partition, a directory join partition and a directory replica;

sending management request from a management station to the agent to access one of the objects.

2. A method according to claim 1, further comprising collecting a second plurality of objects operative to maintain information about replicas associated with the plurality of partitions.

3. A method according to claim 2, wherein the first plurality of objects comprise a plurality of partition operation objects, each partition operation object being operative to maintain information identifying the last successful partition operation completed against a respective partition, and a plurality of current operation objects, each current operation object being operative to maintain information identifying a current operation being performed on a respective partition.

4. A method according to claim 3, further comprising a partition table object, wherein the partition table object is operative to maintain a plurality of rows for maintaining information about respective partitions on the managed server, each row containing one of the partition operation objects and one of the current operation objects.

5. A method according to claim 4, wherein each row further comprises a replica count object operative to maintain a count of the number of replicas of a respective partition, a counter object operative to maintain the number of objects maintained in the respective partition, and a collision object operative to maintain a count of the number of collisions on the respective partition.

6. A method according to claim 2, wherein the second plurality of objects comprise a plurality of replica state objects, each replica state object being operative to maintain a state of the respective replica, and a plurality of replica type objects, each replica type object being operative to maintain a type of the respective replica.

7. A method according to claim 6, further comprising a replica table object, wherein the replica table object is operative to maintain a plurality of rows, each row being operative to maintain information for a respective replica and including one of the replica state objects and one of the replica type objects.

8. A method according to claim 7, wherein each row further comprises a partition identifier object operative to identify a partition on the managed server associated with the respective replica, and a replica server status object operative to maintain information identifying a status of a server on which the respective replica exists.

9. A method according to claim 2 further comprising a partition table object, wherein the partition table object is operative to maintain a plurality of rows for maintaining information about respective partitions on the managed server, each row containing one of the partition operation objects and one of the current operation objects, and a replica table object, wherein the replica table object is operative to maintain a plurality of rows, each row being operative to maintain information for a respective replica and including one of the replica state objects and one of the replica type objects.

10. A method according to claim 9, wherein the sending step comprises sending the management request to access the partition table object, further comprising accessing the partition table object, and for each row in the partition table object, returning to the management station information from at least one object in each row about a respective partition, and displaying the returned information on a display device.

11. A method for providing to a management station operational information related to a distributed directory on a managed server, comprising:

associating an agent with a managed server, the agent implementing an information base including a partition table operative to maintain partition information about each partition on the managed server;

interfacing the agent with a directory service module operative to perform at least one of a directory split partition, a directory join partition, and a directory replica, and associated with the managed server;

and sending a request to the agent to access the partition table.

12. A method according to claim 11, wherein the information base further comprises a container usage table operative to maintain container usage information about each container object in each partition on the managed server.

13. A method according to claim 12, wherein the partition information is maintained in the form of a first plurality of objects, the partition table has a row of the first plurality of objects for each respective partition on the managed server, and wherein the first plurality of objects comprises a replica count object being operative to maintain a count of the number of replicas associated with a respective partition, and a current operation object being operative to maintain information identifying a current operation being performed on the respective partition.

14. A method according to claim 13, wherein the container usage information is maintained in the form of a second plurality of objects, the container usage table has a row of the second plurality of objects for each respective object maintained in a partition on the managed server, and wherein the second plurality of objects comprises a write operations object operative to maintain a count of write accesses performed against the respective object, and a read operations object operative to maintain a count of read accesses performed against the respective object.

15. A system for managing a distributed directory, comprising:

a data communications link;

an interface to a distributed directory service;

an agent implementing an information base, the agent being operative to interface with the distributed directory service via the interface wherein the distributed directory service is operative to perform at least one of a directory split operation, a directory join partition, and a directory replica, and being operative to communicate with a management station via the data communications link;

the agent being operative to access the first plurality of objects upon request from the management station.

16. A method according to claim 15, wherein the information base further comprises a second plurality of objects operative to maintain information about a plurality of replicas associated with the plurality of partitions.

17. A method according to claim 16, wherein the first plurality of objects comprise a plurality of partition operation objects, each partition operation object being operative to maintain information identifying the last successful partition operation completed against a respective partition, and a plurality of current operation objects, each current operation object being operative to maintain information identifying a current operation being performed on a respective partition.

18. A method according to claim 17, further wherein the information base further comprises a partition table object, and wherein the partition table object is operative to maintain a plurality of rows for maintaining information about respective partitions on the managed server, each row containing one of the partition operation objects and one of the current operation objects.

19. A method according to claim 18, wherein the second plurality of objects comprise a plurality of replica state objects, each replica state object being operative to maintain a state of the respective replica, and a plurality of replica type objects, each replica type object being operative to maintain a type of the respective replica, the information base further comprising a replica table object, the replica table object begin operative to maintain a plurality of rows, each row being operative to maintain information for a respective replica and including one of the replica state objects and one of the replica type objects.

20. A method for obtaining access to internal events associated with a directory service on a managed server, comprising:

defining a plurality of trap objects in a MIB, each trap object being associated with a directory service event;

implementing the MIB in an agent;

loading the agent on a managed server;

interfacing the agent with a directory service wherein the directory service is operative to perform at least one of a directory split operation, a directory join partition, and a directory replica; and

communicating at least one of the traps to an external software program.

21. A method for managing a directory service, comprising:

defining a first plurality of objects operative to maintain information about a plurality of partitions in a MIB;

implementing the MIB in an agent;

loading the agent on a managed server;

interfacing the agent with a directory service; and

sending a management request from a management station to the agent to access one of the objects; and

defining a plurality of partition traps in the MIB operative to provide the management station with information relating to partition operations, including a completed partition split trap operative to provide information relating to the completion of a split partition operation, and a completed partition join trap operative to provide information relating to the completion of a join partition operation.

22. A method for managing a directory service, comprising:

defining a first plurality of objects operative to maintain information about a plurality of partitions in a MIB;

implementing the MIB in an agent;

loading the agent on a managed server;

interfacing the agent with a directory service;

sending a management request from a management station to the agent to access one of the objects; and

defining a plurality of replica traps in the MIB operative to provide the management station with information relating to replica operations, including an add replica trap operative to provide information relating to the addition of a new replica, and a remove replica trap operative to provide information relating to the removal of a replica.

23. A method for obtaining access to internal events associated with a directory service on a managed server, comprising:

defining a plurality of trap objects in a MIB, each trap object being associated with a directory service event, wherein the trap objects defined in the MIB comprise a completed partition split trap operative to provide information relating to the completion of a split partition operation, and a completed partition join trap operative to provide information relating to the completion of a join partition operation;

implementing the MIB in an agent;

loading the agent on a managed server;

interfacing the agent with a directory service; and

communicating at least one of the traps to an external software program.

24. A method for obtaining access to internal events associated with a directory service on a managed server, comprising:

defining a plurality of trap objects in a MIB, each trap object being associated with a directory service event, wherein the trap objects defined in the MIB comprise a completed partition split trap operative to provide information relating to the completion of a split partition operation, and a completed partition join trap operative to provide information relating to the completion of a join partition operation, the trap objects defined in the MIB further comprising an add replica trap operative to provide information relating to the addition of a new replica, and a remove replica trap operative to provide information relating to the removal of a replica;

implementing the MIB in an agent;

loading the agent on a managed server;

interfacing the agent with a directory service; and

communicating at least one of the traps to an external software program.

25. A method for obtaining access to internal events associated with a directory service on a managed server, comprising:

defining a plurality of trap objects in a MIB, each trap object being associated with a directory service event, wherein the trap objects defined in the MIB comprise a completed partition split trap operative to provide information relating to the completion of a split partition operation, and a completed partition join trap operative to provide information relating to the completion of a join partition operation, the trap objects defined in the MIB further comprising an add replica trap operative to provide information relating to the addition of a new replica, and a remove replica trap operative to provide information relating to the removal of a replica;

implementing the MIB in an agent;

loading the agent on a managed server;

interfacing the agent with a directory service; and

communicating at least one of the traps to an external software program, wherein the external software program comprises management station software.

Description

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyrights whatsoever.

A microfice appendix is attached. The total number of microfiche is 2 and the total number of frames is 162.

FIELD OF THE INVENTION

This invention relates to distributed directory services, and more particularly relates to management of distributed directory services using standard network management protocols.

BACKGROUND OF THE INVENTION

Networks have traditionally been relatively difficult to administer, especially as they grow in physical size and in the number of network-attached entities. One relatively recent advance in administering networks is the directory service. A directory service organizes network entities, such as users, printers, servers and the like into a manageable hierarchy, and simplifies overall management of such entities. The advantages of a good directory service has become such an important aspect of a network operating system that network operating systems are frequently purchased solely on the strength of their directory service capabilities.

A directory service typically organizes the network entities into a hierarchical tree structure, or directory, which can be graphically presented to visually illustrate the parent/child relationships between such entities. Some vendors' directory service products allow the distribution of the directory across various servers on a network. The ability to distribute a directory across several servers can reduce network traffic and access time by allowing an administrator to place heavily used portions of a directory on the servers from which they are most frequently accessed. Of course, a distributed directory service is typically more complex to administer than a non-distributed directory service.

One directory service product, NOVELL DIRECTORY SERVICES (NDS), refers to each node in the directory tree as an object, and categorizes each object in the tree as either a container object or a leaf object. A container object can be a parent to other container objects, and to zero or more leaf objects. Container objects are typically used to provide a logical organization to the tree, while the leaf objects represent actual network elements such as servers, printers, facsimile machines, and users. The directory can be divided into distinct portions, referred to as partitions, and each partition can be located on a different network server. Multiple copies of partitions can be made, and each copy of a partition is referred to as a replica. Thus, each partition has one or more replicas.

As is apparent, the software to implement such a distributed directory service can be quite complex. The directory service is responsible for splitting and joining partitions, making and synchronizing updates to replicas, providing a coherent view of the distributed directory to an administrator, providing a mechanism for adding, modifying and removing objects, and a host of other functions. While having a directory service eases the overall administration of a network, it still requires specialized training to understand when and how to split partitions, where to place the partitions, when and how to make replicas, how to organize the objects in a tree, and other administrative issues. Moreover, it is frequently necessary to monitor the directory service to uncover potential problems before they grow to the point that service is interrupted. Administration and monitoring are typically accomplished with vendor-supplied administration software specially developed for use with that vendor's directory service. Use of these tools typically requires special training of administration personnel. Such training can be expensive, and since vendors' directory service products differ from one another, training on one such product does not necessarily help in administering another vendor's directory service. Thus, transitioning from one vendor's directory service to another typically requires costly retraining.

The difficulty in administering a directory service also arises, to a lesser extent, in the management of individual network-attached devices. Years ago, network-attached devices typically came with their own software for monitoring and maintaining the device on the network. This required familiarity with many different programs, and as the average size of networks grew, this approach became unwieldy. To ease the management of such network- attached devices, management protocols, such as the Simple Network Management Protocol (SNMP), were established which created a uniform and standard protocol for managing devices on a network. Under SNMP, each managed device implements a Management Information Base (MIB), which is a database of managed objects associated with the managed device. Each managed object in the MIB is syntactically defined in a MIB listing. The MIB listing is used by management station software running on a computer to determine what objects are implemented in a particular managed device. Through the definitions of the objects in the MIB listing, the management station can generate and communicate to the managed device with SNMP GET, SET and GET NEXT requests, to view and/or modify, as appropriate, the objects in the managed device. Thus, SNMP defines a protocol which establishes a uniform mechanism for communicating with an agent associated with a network-attached device. One of the many advantages of such a uniform mechanism is that individuals familiar with SNMP and management station software can typically, at least to some extent, manage any SNMP-enabled device, without being specially trained to manage each respective device. Another advantage of using a standardized management protocol, such as SNMP, to manage devices, is that the use of such a standard management protocol ensures that software written to interact with the managed device will run on any network which supports the SNMP protocol.

At least one attempt has been made to simplify the management of a directory service through SNMP. The CCITT has published RFC 1567 which defines a MIB for use with X.500 compliant directory services. The RFC 1567 MIB defines several objects useful for maintaining summary statistics at the Directory Service Agent (DSA) level, but provides no objects or other means for monitoring or otherwise managing a directory service at a more detailed level which includes partitions, replicas, container objects and the like, and which can provide an administrator with object-level statistics regarding network usage. Moreover, the RFC 1567 MIB does not provide any mechanism for monitoring or otherwise managing other aspects of a directory service, such as the state of the DSA, or the various types of traffic and relative amounts of traffic handled by the directory service.

SUMMARY OF THE INVENTION

It is one object of this invention to provide a method and system which enables administration of a distributed directory service using standard network management protocols.

It is another object of this invention to provide a method and system for managing a distributed directory service which reduces the amount of training required to administer a distributed directory service.

It is yet another object of this invention to provide a method and system for managing a distributed directory service which uses standard network management protocols to generate notifications of events occurring within the distributed directory service.

Additional objects, advantages and other novel features of the invention will be set forth in part in the description that follows and, in part, will become apparent to those skilled in the art upon examination of the invention. To achieve the foregoing and other objects and in accordance with the purposes of the present invention as described above, a method and system for managing a directory service is provided. The directory maintained by the directory service preferably includes a plurality of partitions. A plurality of objects operative to maintain information about the plurality of partitions are defined in a Management Information Base (MIB). The plurality of objects can comprise a partition table object which maintains a row of objects for each partition on the managed server. Each row in the table can contain a partition operation object which is operative to maintain information identifying the last successful partition operation completed against a respective partition, and a current operation object which is operative to maintain information identifying a current operation being performed on a respective partition. The MIB is implemented in a network agent, and the agent is loaded on a managed server. The agent interfaces with a directory service module. Standard network management software can be used to interact with the agent by sending standard management requests to the agent, directing the agent to access one or more of the objects. The agent can retrieve information from the appropriate object, or change the appropriate object as a function of the request from the network management software.

According to another embodiment of this invention, a second plurality of objects which are operative to maintain information about replicas associated with the plurality of partitions are defined in the MIB. The second plurality of objects can be maintained in a replica table object, each row in the replica table object containing information regarding a respective replica. Each replica row can contain a replica state object operative to maintain a state of the respective replica, and a replica type object operative to maintain a type of the respective replica.

The MIB according to one embodiment of this invention contains a partition table which maintains information about each partition on the managed server, and a replica table which maintains information about each replica associated with each partition in the partition table. Each managed server in the distributed directory service preferably has its own agent and associated MIB. By using standard network management protocols, such as the Simple Network Management Protocol (SNMP), the method and system according to this invention can be used with any network management station software suitable for use in an SNMP environment. Thus, the method and system according to this invention provide a uniform interface suitable for administering a complex distributed directory with standard network management software.

A plurality of objects regarding the usage of the containers in the tree can be defined in the MIB. Preferably, a container usage table object is defined, which maintains a row of container usage objects for each container object. The objects can include a read operations object operative to maintain the number of times the container object has been read, and a write operations object operative to maintain the number of times the container object has been modified. Such low-level statistical information regarding container usage can be useful in determining how to partition a directory, and can help diagnose potential design problems.

According to another embodiment of this invention, the MIB includes a plurality of SNMP traps for providing information about events occurring within the directory service. Upon occurrence of a particular directory service event, the trap associated with the event is generated by the agent and can either be immediately communicated to the network management station, or can be stored and communicated when polled by the network management station. The ability to generate and communicate a trap associated with the occurrence of a distributed directory service event greatly reduces the need to continually monitor the directory service. Traps can also be used by external programs to keep apprised of the internal mechanisms of the directory service. Such traps can include, for example, a completed partition split trap operative to provide information related to the completion of a split partition operation, and a completed partition join trap operative to provide information relating to the completion of a join partition operation. Such traps can be communicated to other software programs and thus can be used by such software programs to synchronize other directory service related systems with the distributed directory service.

The method and system according to this invention use standard and well-known network management protocols to manage a complex distributed directory service, reducing the time and cost typically required to train an individual to administer such a directory service, and simplifying the usually complex programming required to interface with such a distributed directory service.

Still other objects of the present invention will become apparent to those skilled in this art from the following description wherein there is shown and described preferred embodiments of this invention. As will be realized, the invention is capable of other different obvious aspects all without departing from the invention. Accordingly, the drawings and description will be regarded as illustrative in nature and not as restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings incorporated in and forming a part of the specification, illustrate several aspects of the present invention, and together with the description serve to explain the principals of the invention. In the drawings:

FIG. 1 is a schematic view of a distributed directory tree;

FIG. 2 is a block diagram illustrating a system for managing a distributed directory service according to one embodiment of this invention;

FIG. 3 is a diagram illustrating the hierarchical relationship of objects in a MIB according to one embodiment of this invention;

FIG. 4 is a diagram illustrating in greater detail a portion of the MIB shown in FIG. 3;

FIG. 5 is a diagram illustrating in greater detail a portion of the MIB shown in FIG. 4;

FIG. 6 is a diagram illustrating in greater detail another portion of the MIB shown in FIG. 4;

FIG. 7 is a diagram illustrating in greater detail another portion of the MIB shown in FIG. 4;

FIG. 8 is a diagram illustrating in greater detail another portion of the MIB shown in FIG. 3;

FIG. 9 is a user interface window showing summary information obtained from the MIB according to one embodiment of this invention;

FIG. 10 is a user interface window showing partition information obtained from the MIB according to one embodiment of this invention;

FIG. 11 is a user interface window showing replica information relating to a partition shown in FIG. 10;

FIG. 12 is a user interface window showing container usage information relating to a partition shown in FIG. 11; and

FIG. 13 is a user interface window showing partition operation information on a partition-by-partition basis.

Reference will now be made in detail to present preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings, wherein like numerals indicate the same elements throughout the views.

DETAILED DESCRIPTION

The words `container` and `leaf` are used herein as those terms are used in the NOVELL DIRECTORY SERVICES (NDS) product, but are used merely to illustrate the invention and are not intended to limit the invention to directory services which use such terms. It is apparent that the invention has applicability to a variety of distributed directories, regardless of the terminology used to define entities in such systems.

Referring now to the drawings, FIG. 1 is a schematic diagram of a distributed directory tree 30 illustrating a hierarchy of container and leaf objects which compose a distributed directory. A container object is used primarily to organize directory tree 30, and can contain other container objects, and/or leaf objects. Leaf objects represent network entities such as servers, printers, users and the like. Each object in directory tree 30 also has associated with it several different attributes which contain specific information about that object, such as its name, class, and description. A root container object 32 represents the top of the tree, and is named `ACME` to represent that directory tree 30 relates to the ACME Company. Container object 32 contains a plurality of other container objects 34, 36 and 38, each of which represents a state in which the ACME Company has offices. Each of the state container objects has child objects which represent the cities in those states in which the company has offices, as represented by container objects 40, 48, 50, 52, 54 and 56. Although not shown, each of the container objects in directory tree 30 could have leaf objects, and at the city level (e.g., objects 40, 48, 50, 52, 54, and 56), each container object more than likely would have a plurality of leaf objects representing entities maintained at that location, such as leaf objects 42, 44, 45 and 46, which represent a printer, two users and a fax, respectively.

Although directory tree 30 could exist on a single network server, robust directory service products allow an administrator to divide directory tree 30 into several portions, sometimes referred to as partitions, and distribute each partition to a separate network server. One of the roles of the directory service is to maintain and provide a coherent view of the distributed directory tree 30. The ability to partition and distribute directory tree 30 provides several benefits, such as improved security, and greater overall throughput by physically separating the directory data onto different network servers, which allows heavily used partitions to be moved to separate servers. Moreover, if a particular server heavily uses a particular partition, the partition (or a copy thereof) can be physically moved to that server. Directory tree 30 can be partitioned many different ways, and the dashed boxes in FIG. 1 illustrate only one way in which directory 30 could potentially be partitioned. Each dashed box (e.g., 33, 35, 37, 39, 41 and 49) represents a separate partition of directory tree 30 and each such partition can be located on a separate network server.

Certain advanced distributed directory service products allow copies of partitions to be made. Such copies are frequently referred to as replicas. Each partition can have one or more replicas, and each replica is located on a different network server from the other replicas of that partition. Replication provides redundancy, and further increases the ability to duplicate portions of directory tree 30 to respond to potential performance problems associated with accessing directory tree 30. Such distributed directory services must maintain information about each partition and its replicas. Replicas can be designated as one of several types, such as a master replica, a read/write replica or a read-only replica. Each replica may contain hundreds or thousands of different container and leaf objects, as well as the attributes associated with these objects. It is apparent that a directory service must be able to maintain a vast amount of information for directory tree 30.

In addition to maintaining a large quantity of information, a distributed directory service must provide internal mechanisms for synchronizing the various replicas of a partition, providing a coherent view of the overall directory tree, and the processing associated with making, moving and/or deleting partitions and replicas. Such operations include splitting a single partition into multiple partitions, or creating a single partition from multiple partitions. These are only a few of the many different operations required by a distributed directory service.

Typically, each vendor of a distributed directory service provides a proprietary administration program designed to administer that vendor's distributed directory service. Training individuals to use the program can be time consuming, costly, and what is learned is usually not transferable to other administration programs as each vendor's administration program is different. Another problem relates to developing programs for use with the directory service. Vendors typically provide a proprietary interface which allows the development of additional programs which can interface with the directory service to provide additional functionality not offered by the directory service. Because each vendor typically uses a different interface, software programs written for a particular directory service frequently need to be substantially rewritten for use with other directory services.

The method and system for managing a directory service according to this invention allows the management of a complex directory service through conventional network management station software, and allows developers to write software which interfaces with the directory service via conventional management station protocols. Referring now to FIG. 2, a directory service management system according to one embodiment of this invention is shown. A managed server 58 contains an agent 70 which communicates with a management station 80 over a network 78. The communication protocol between agent 70 and management station 80 can comprise any conventional network protocol, including for example, TCP/IP or SPX/IPX.

Managed server 58 can comprise any network computer, such as those available from IBM, COMPAQ, etc., running an operating system capable of supporting a directory service. Agent 70 is preferably a Simple Network Management Protocol (SNMP) agent which communicates with management station 80 using the SNMP protocol. However, it is apparent that other network management protocols, such as CMIP, could also be used. Agent 70 responds to GET, SET, and GET NEXT requests which it receives from management station 80. Management station 80 can comprise any computer upon which management station software, such as NOVELL MANAGEWISE or HEWLETT PACKARD OPENVIEW can execute, such as, for example, PC-compatible computers running WINDOWS operating system software. Network administrators typically use such management software to administer network-attached devices via the SNMP protocol.

Agent 70 implements a Management Information Base (MIB) 71 which contains objects related to the administration of a directory service 62. A MIB, in one sense, is a virtual data base in that the objects defined in the MIB may not exist in the agent itself, but may be located elsewhere, but are accessible by agent 70. However, to management station 80, the actual location of the objects is irrelevant, as it appears to management station 80 that each object is owned and controlled by agent 70.

Agent 70 can be developed using conventional SNMP development software, such as is provided in the NOVELL MANAGEWISE SDK CD Release 9, the contents of which are hereby incorporated herein. Such development environments typically include a MIB compiler that reads a MIB listing, which defines the objects in a MIB such as MIB 71, and generates software instructions suitable for defining and accessing such objects. These software instructions are incorporated into agent 70.

According to one embodiment of this invention, MIB 71 includes both objects and traps, and the objects are implemented in an object module 72, while the traps are implemented in a trap module 74. However, it is apparent that both the objects and the traps could be implemented in one integral software module. To ease the development of SNMP agents, some development systems, such as the MANAGEWISE SDK, separates the logic required to handle SNMP processing from the logic necessary to implement objects and traps. Thus, agent 70 also has an SNMP module 76 which includes the processing logic necessary to handle GET, SET, and GET-NEXT requests from management station 80. SNMP module 76 interfaces with object module 72 and trap module 74 via a predetermined interface defined by the MANAGEWISE SDK. This separation of processing login is provided merely as a convenience for a developer of an SNMP agent, and it is apparent that the invention described herein could be implemented such that the objects, traps and SNMP processing are handled in a single integral software module.

Directory service 62 can comprise any directory service, and preferably comprises a distributed directory service wherein the directory tree can be divided into partitions which can be located on different network servers. According to one embodiment of this invention, directory service 62 comprises NOVELL DIRECTORY SERVICES (NDS). Directory service 62 typically contains a data module 66 which contains the various counters and other data variables used by directory service 62 to maintain the status of the portion of the distributed directory on managed server 58, as well as certain information regarding partitions and replicas located on other network servers. The majority of the data associated with the objects in MIB 71 reside in data module 66. Thus, when agent 70 receives an SNMP request from management station 80, object module 72 accesses data module 66 to either modify the data in object module 66, or to retrieve data from object module 66 and communicate that data to management station 80. Agent 70 can interface with data module 66 either by directly invoking suitable functions in data module 66, or indirectly through, for example, an application programming interface (API) 68. One advantage of using API 68 is the degree of separation it provides from the specific implementation of data module 66. If access to data module 66 is maintained through API 68, data module 66 can be modified without regard to external software, such as agent 70, as long as API 68 is also modified to properly interface with data module 66. Thus, regardless of how data module 66 may be modified, agent 70 can continue to interface with data module 66 through API 68 without modification or recompilation. Because some of the objects implemented in MIB 71 may relate to other aspects of the network operating system, API 68 also interfaces with network operating system 60 to provide access to such data by agent 70.

Directory service 62 can also maintain an event system 64 for communicating events occurring within directory service 62 to external software modules. Event system 64, or other event mechanism, is typically provided in a directory service to allow software modules outside of the directory service to gain access to the various events occurring within the directory service. While event system 64 provides flexibility in allowing external software to gain access to events internal to directory service 62, such conventional event systems typically have a proprietary interface which renders the development of such external software more difficult, and precludes the use of the external software with other event systems. According to one embodiment of this invention, MIB 71 implements a plurality of SNMP traps, each of which corresponds to an event within event system 64, and upon the occurrence of one of such events the corresponding trap is generated which can either be spontaneously communicated to management station 80 or stored to await polling from management station 80. Using the standard SNMP protocol to provide event information to external software, such as management software, eliminates the need to write to a proprietary interface, decreasing the complexity of the software.

Access to the event information from event system 64 can be achieved with a registration and callback mechanism, as is known to those skilled in the art, or other suitable notification mechanism. Thus, trap module 74 registers with event system 64 to receive event notification for each event for which a corresponding trap has been defined. Upon the occurrence of any of such events, event system 64 notifies trap module 74, which in turn generates the appropriate trap.

Referring now to FIG. 3, the objects defined in MIB 71 according to one embodiment of this invention will be described. Objects in a MIB are typically defined using a notation known as the American National Standards Institute (ANSI) ASN.1 syntax. Objects in an SNMP MIB are identified through the use of an object identifier, which comprises a series of digits separated by periods. For example, server object 86 has an object identifier of 1.3.6.1.4.1.23.2.33. Periods are field separators, with each field referring to a parent object in a hierarchy of objects. Thus, server object 86 is the 33rd child object of MIBDOC object 84, which has an object identifier of 1.3.6.1.4.1.23.2. Thus, each object identifier establishes a path through the MIB tree from the respective object to the root of the tree. As is understood by those skilled in the art, the standard hierarchy of objects includes ISO, ORG, DOD, INTERNET, private, and enterprise objects (1.3.6.1.4.1).

Certain objects, such as group objects, are essentially "place holder" objects used to collect a group of related child objects. Server object 86 is such a group object. Server object 86 is a parent object to a plurality of child objects which relate to management of a distributed directory service on a particular managed server. The references herein to locations of objects is with respect to their location within the hierarchy of objects according to one embodiment of this invention, and in general could be located at practically any other location within MIB 71 without departing from the invention. For brevity, in the figures and specification, only the digits and periods of the object identifier which identify the object's immediate parent and the object's location at that level of the tree will be used.

Server object 86 is a parent object to a plurality of child objects, such as partition object 88 and server info object 90, each of which are also group and thus parent objects to a plurality of child objects. Partition object 88 has a plurality of child objects, each of which relates to management of partitions on managed server 58. Referring now to FIG. 4, partition object 88 is a parent object to partition count object 91, partition table object 92, replica table object 93, referenced server table object 94, and partition operations table object 95. Partition count object 91 maintains the total number of partitions that reside on managed server 58. The formal ASN.1 syntax for partition count object 91 is as follows:

nwDSPartitionCount OBJECT-TYPE

SYNTAX INTEGER

ACCESS read-only

STATUS mandatory

DESCRIPTION

"The total number of partitions that reside on this server."

::={nwDSPartition 1}

Referring now to FIG. 5, partition table object 92 contains a plurality of rows, or sequences, of objects relating to a particular partition on managed server 58. Each row of partition table object 92 includes a partition ID object, a partition name object, a last successful partition operation object, a last successful partition operation start date time object, a last successful partition operation stop date time object, a current operation object, a current operation start date time object, a collision count object, a last collision object name object, a last collision rename object, a last collision date time object, an object count object, a replica per partition count object, a last entry modification time object, a SAP federated name object, a start SAP name mode object, and a partition replica number object. The formal ASN.1 syntax for partition table object 92, according to one embodiment of this invention, is as follows:

    ______________________________________
    DS Partition Table
      nwDSPartitionTable OBJECT-TYPE
              SYNTAX SEQUENCE OF NwDSPartitionEntry
      ACCESS not-accessible
      STATUS mandatory
                DESCRIPTION
                    "A list of all partitions that reside on this server."
    ::= { nwDSPartition 2 }
      nwDSPartitionEntry OBJECT-TYPE
              SYNTAX nwDSPartitionEntry
      ACCESS not-accessible
      STATUS mandatory
                DESCRIPTION
                    "The description of a particular partition
      in the partition table."
    INDEX {nwDSPartitionID}
      ::= { nwDSPartitionTable 1 }
      nwDSPartitionEntry ::= SEQUENCE {
            nwDSPartitionID   DsObjectID,
      nwDSPartitionName ObjectFullDistinquishedName,
    nwDSLastSuccessPartitionOperation
                           INTEGER,
      nwDSLastSuccessPartOperStartDateTime DateAndTime,
      nwDSLastSuccessPartOperStopDateTime DateAndTime,
    nwDSCurrentOperation
                      INTEGER,
    nwDSCurrentOperationStartDateTime
                           DateAndTime,
    nwDSCollisionCount
                      INTEGER,
      nwDSLastCollObjectName ObjectFullDistinquishedName,
      nwDSLastColReName ObjectFullDistinquishedName,
      nwDSLastCollisionDateTime DateAndTime,
      nwDSObjectCount INTEGER,
      nwDSReplicaPerPartitionCount INTEGER,
      nwDSLastEntryModTime DateAndTime,
      nwDSSapFederatedName DisplayString,
      nwDSStartSapNameMode INTEGER,
      nwDSPartReplicaNumber INTEGER
      nwDSPartitionID OBJECT-TYPE
        SYNTAX DsObjectID
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "The object ID which uniquely identifies a partition
      on this server and which maps as an index to
      the partition table."
                ::= { nwDSPartitionEntry 1 }
    nwDSPartitionName OBJECT-TYPE
        SYNTAX ObjectFullDistinquishedName
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "The Distinguished Name of this partition."
                ::= { nwDSPartitionEntry 2 }
    nwDSLastSuccessPartitionOperation OBJECT-TYPE
        SYNTAX INTEGER {
                  idle(1),
      split(2),
      splitChild(3),
      joinUp(4),
      joinDown(5),
      moveSubTreeSource(6),
      moveSubTreeDestination(7),
      repairingTimeStamps(8),
      changingReplicaType(9)
                    }
    ACCESS read-only
      STATUS mandatory
      DESCRIPTION
          "The last successful operation (such as delete, join,
      split, move, etc.) that was performed on this partition.
      Example: Deleted Partition1
      The initial value is 0."
            ::= { nwDSPartitionEntry 3 }
              nwDSLastSuccessPartOperStartDateTime OBJECT-TYPE
                  SYNTAX DateAndTime
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                      "The date and time when the last successful
      operation on this partition was initiated.
      The initial value is 0."
    ::= { nwDSPartitionEntry 4 }
      nwDSLastSuccessPartOperStopDateTime OBJECT-TYPE
            SYNTAX DateAndTime
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "The date and time when the last successful
      operation on this partition was completed.
      The initial value is 0."
    ::= { nwDSPartitionEntry 5 }
      nwDSCurrentOperation OBJECT-TYPE
            SYNTAX INTEGER {
                      idle(1),
      split(2),
      splitChild(3),
      joinUp(4),
      joinDown(5),
      moveSubTreeSource(6),
      moveSubTreeDestination(7),
      repairingTimeStamps(8),
      changingReplicaType(9)
    }
        ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "The operation currently being performed on this partition
               (delete, join, split, move, etc.)."
                ::= { nwDSPartitionEntry 6 }
    nwDSCurrentOperationStartDateTime OBJECT-TYPE
        SYNTAX DateAndTime
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "The date and time when the current operation
      was initiated."
                ::= { nwDSPartitionEntry 7 }
    nwDSCollisionCount OBJECT-TYPE
        SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "The total number of collisions that have occurred
      on this partition since NDSStats.NLM was loaded."
                ::= { nwDSPartitionEntry 8 }
    nwDSLastCollObjectName OBJECT-TYPE
        SYNTAX ObjectFullDistinquishedName
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "The report (by object name) of the last name collision."
                ::= { nwDSPartitionEntry 9 }
    nwDSLastColReName OBJECT-TYPE
        SYNTAX ObjectFullDistinquishedName
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "The report (by renamed object) of the last name collision."
                ::= { nwDSPartitionEntry 10 }
    nwDSLastCollisionDateTime OBJECT-TYPE
        SYNTAX DateAndTime
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "The date and time when the last name collision occurred."
                ::= { nwDSPartitionEntry 11 }
    nwDSObjectCount OBJECT-TYPE
        SYNTAX INTEGER
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "The total number of objects in this partition."
                ::= { nwDSPartitionEntry 12 }
    nwDSReplicaPerPartitionCount OBJECT-TYPE
        SYNTAX INTEGER
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "The total number of replicas of this partition."
                ::= { nwDSPartitionEntry 13 }
    nwDSLastEntryModTime OBJECT-TYPE
        SYNTAX DateAndTime
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "The date and time when an entry in the partition table
               was last modified. Initial value is 0."
                ::= { nwDSPartitionEntry 14 }
    nwDSSapFederatedName OBJECT-TYPE
        SYNTAX DisplayString(SIZE(0..48))
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "SAP and real federated names are the same."
                ::= { nwDSPartitionEntry 15 }
    nwDSStartSapNameMode OBJECT-TYPE
        SYNTAX INTEGER {
                  on(1),
      off(2),
      rootmost(3)
                    }
    ACCESS read-write
      STATUS mandatory
      DESCRIPTION
          "The setting for Service Advertising (SAP)
      on this federated partition (on, off, or
      rootmost). When the setting is rootmost,
      only the rootmost partition object advertises."
            ::= { nwDSPartitionEntry 16 }
              nwDSPartReplicaNumber OBJECT-TYPE
                  SYNTAX INTEGER
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                      "The replica number, which also maps as an index
                       to the partition's replica table."
    ::= { nwDSPartitionEntry 17 }
      .COPYRGT. 1997 Novell Inc.
    ______________________________________

    ______________________________________
    DS Replica Table
      nwDSReplicaTable OBJECT-TYPE
              SYNTAX SEQUENCE OF NwDSReplicaEntry
      ACCESS not-accessible
      STATUS mandatory
                DESCRIPTION
                    "The list of all replicas of this partition
      that reside on other servers."
    ::= { nwDSPartition 3 }
      nwDSReplicaEntry OBJECT-TYPE
              SYNTAX NwDSReplicaEntry
      ACCESS not-accessible
      STATUS mandatory
                DESCRIPTION
                    "The description of a particular replica
      (in the replica table) that resides
      on this partition."
    INDEX {nwDSPartitionRepID,nwDSReplicaNumber}
      ::= { nwDSReplicaTable 1 }
      NwDSReplicaEntry ::= SEQUENCE {
            nwDSPartitionRepID
                              DsObjectID,
      nwDSReplicaNumber INTEGER,
      nwDSReplicaServerID INTEGER,
      nwDSReplicaState INTEGER,
      nwDSReplicaType INTEGER,
    nwDSRepSuccessSyncDateTime
                           DateAndTime,
      nwDSSuccessInBoundSyncCount Counter,
      nwDSSuccessOutBoundSyncCount Counter,
      nwDSReplicaFailSyncDateTime DateAndTime,
    nwDSReplicaFailCondition
                      INTEGER,
      nwDSReplicaFailSyncCount INTEGER,
      nwDSReplicaServerState INTEGER,
      nwDSInBoundObjectCount Counter,
      nwDSOutBoundObjectCount Counter,
      nwDSInBoundSyncTime Counter,
      nwDSOutBoundSyncTime Counter
      nwDSPartitionRepID OBJECT-TYPE
        SYNTAX DsObjectID
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "The object ID that uniquely identifies a particular
      replica on this partition. This ID also maps as an
      index to the partition's replica table."
                ::= { nwDSReplicaEntry 1 }
    nwDSReplicaNumber OBJECT-TYPE
        SYNTAX INTEGER
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "The number that uniquely identifies a particular replica
               on this partition. This number also maps as an index
      to this server's replica table."
                ::= { nwDSReplicaEntry 2 }
    nwDSReplicaServerID OBJECT-TYPE
        SYNTAX INTEGER
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "The object ID that identifies the server on which
      this replica resides. This number also maps as an index
      to the reference server table (nwDSRefServerID)."
                ::= { nwDSReplicaEntry 3 }
    nwDSReplicaState OBJECT-TYPE
        SYNTAX INTEGER {
                  on(0),
      new(1),
      dying(2),
      locked(3),
      changereplicatype0(4),
      changereplicatype1(5),
      transition(6),
      split0(48),
      split1(49),
      join0(64),
      join1(65),
      join2(66),
      move0(80)
                    }
    ACCESS read-only
      STATUS mandatory
      DESCRIPTION
          "The state of this replica (busy, on, join, etc.)."
            ::= { nwDSReplicaEntry 4 }
              nwDSReplicaType OBJECT-TYPE
                  SYNTAX INTEGER {
                          master(0),
      readWrite(1),
      readOnly(2),
      subref(3)
    }
        ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "The type of this replica (master, read-write,
      read-only, or subordinate reference)."
                ::= { nwDSReplicaEntry 5 }
    nwDSRepSuccessSyncDateTime OBJECT-TYPE
        SYNTAX DateAndTime
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "The date and time when this replica was last
      successfully synchronized."
                ::= { nwDSReplicaEntry 6 }
    nwDSSuccessInBoundSyncCount OBJECT-TYPE
        SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "The total number of times that in-bound synchronization
               was successful since NDSStats.NLM was loaded."
                ::= { nwDSReplicaEntry 7 }
    nwDSSuccessOutBoundSyncCount OBJECT-TYPE
        SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "The total number of times that out-bound synchronization
               was successful since NDSStats.NLM was loaded."
                ::= { nwDSReplicaEntry 8 }
    nwDSReplicaFailSyncDateTime OBJECT-TYPE
        SYNTAX DateAndTime
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "The date and time when the last failure
      of replica synchronization occurred."
                ::= { nwDSReplicaEntry 9 }
    nwDSReplicaSyncFailCondition OBJECT-TYPE
        SYNTAX INTEGER
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "The reason (error condition) that the last failure
      of replica synchronization occurred."
                ::= { nwDSReplicaEntry 10 }
    nwDSReplicaFailSyncCount OBJECT-TYPE
        SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "The total number of times that synchronization
      has failed since NDSStats.NLM was loaded."
                ::= { nwDSReplicaEntry 11 }
    nwDSReplicaServerState OBJECT-TYPE
        SYNTAX INTEGER {
                  unknown(0),
      down(1),
      up(2)
                    }
    ACCESS read-only
      STATUS mandatory
      DESCRIPTION
          "The state of the server (up, down, unknown)
      on which this replica resides."
            ::= { nwDSReplicaEntry 12 }
              nwDSInBoundObjectCount OBJECT-TYPE
                  SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                      "The count of all in-bound objects that have been
                       synchronized since NDSStats.NLM was loaded."
    ::= { nwDSReplicaEntry 13 }
      nwDSOutBoundObjectCount OBJECT-TYPE
            SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "The count of all out-bound objects that have been
      synchronized since NDSStats.NLM was loaded."
    ::= { nwDSReplicaEntry 14 }
      nwDSInBoundSyncTime OBJECT-TYPE
            SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "The total time (in seconds) required for
      in-bound objects to synchronize."
    ::= { nwDSReplicaEntry 15 }
      nwDSOutBoundSyncTime OBJECT-TYPE
            SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "The total time (in seconds) for out-bound objects
      to synchronize."
    ::= { nwDSReplicaEntry 16 }
      .COPYRGT. 1997 Novell Inc.
    ______________________________________

    ______________________________________
    Partition Operations Table
      nwDSPartOperationsTable OBJECT-TYPE
              SYNTAX SEQUENCE OF NwDSPartOperationsEntry
      ACCESS not-accessible
      STATUS mandatory
                DESCRIPTION
                    "A list of operations which have partition-level counters
      to record the total number of times each operation has
      been performed since NDSStats.NLM was loaded."
    ::= { nwDSPartition 5 }
      nwDSPartOperationsEntry OBJECT-TYPE
              SYNTAX NwDSPartOperationsEntry
      ACCESS not-accessible
      STATUS mandatory
                DESCRIPTION
                    "The description of an instance of a partition-level
                     operation which has been performed and which is also
                     indexed to this partition table entry."
    INDEX {nwDSPartitionOperationsIndex}
      ::= { nwDSPartOperationsTable 1 }
      NwDSPartOperationsEntry ::= SEQUENCE {
            nwDSPartionOperationsIndex
                                DsObjectID,
      nwDSAnonymousBinds Counter,
      nwDSSimpleAuthenticatedBinds Counter,
      nwDSStrongAuthenticatedBinds Counter,
      nwDSBindSecurityErrors Counter,
      nwDSOperationForwardToThisDs Counter,
      nwDSReadOperations Counter,
      nwDSCompareOperations Counter,
      nwDSAddEntryOperations Counter,
      nwDSRemoveEntryOperations Counter,
      nwDSModifyEntryOperations Counter,
      nwDSModifyRDNOperations Counter,
      nwDSListOperations Counter,
      nwDSSearchOperation Counter,
      nwDSOneLevelSearchOperation Counter,
      nwDSWholeTreeSearchOperation Counter,
      nwDSMoveEntryOperations Counter,
      nwDSTypeReferralReturned Counter,
      nwDSTransportReferralReturn Counter,
      nwDSAliasReferralReturned Counter,
      nwDSOperationsForwarded Counter,
      nwDSOperForwardNoSecurity Counter,
      nwDSOperNotServDueToError Counter
      nwDsPartitionOperationsIndex OBJECT-TYPE
        SYNTAX DsObjectID
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "The object ID that uniquely identifies this partition
      and which also maps as an index to the partition table."
                ::= { nwDSPartOperationsEntry 1 }
    nwDSAnonymousBinds OBJECT-TYPE
        SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "Anonymous binds (the total number of binds to any account
               that does not have a password)."
                ::= { nwDSPartOperationsEntry 2 }
    nwDSSimpleAuthenticatedBinds OBJECT-TYPE
        SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "The total number of binds made with bindery authentication
               since NDSStats.NLM was loaded."
                ::= { nwDSPartOperationsEntry 3 }
    nwDSStrongAuthenticatedBinds OBJECT-TYPE
        SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "The total number of binds made
      with NDS-authenticated connections
      since NDSStats.NLM was loaded."
                ::= { nwDSPartOperationsEntry 4 }
    nwDSBindSecurityErrors OBJECT-TYPE
        SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "Any failed attempt to validate a connection.
      Security errors include failures because of invalid
      login name, bad password, or insufficient rights."
                ::= { nwDSPartOperationsEntry 5 }
    nwDSOperationForwardToThisDSA OBJECT-TYPE
        SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
              "A request from the Directory User Agent (DUA) or client
    [either/or serving as?]
          or another Directory Service Agent (DSA)."
            ::= { nwDSPartOperationsEntry 6 }
              nwDSReadOperations OBJECT-TYPE
                  SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                      "The total number of read operations performed
      in this partition since NDSStats.NLM was loaded."
    ::= { nwDSPartOperationsEntry 7 }
      nwDSCompareOperations OBJECT-TYPE
            SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "The total number of compare operations performed
      in this partition since NDSStats.NLM was loaded."
    ::= { nwDSPartOperationsEntry 8 }
      nwDSAddEntryOperations OBJECT-TYPE
            SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "The total number of entries that were created (added)
                   in this partition since NDSStats.NLM was loaded."
    ::= { nwDSPartOperationsEntry 9 }
      nwDSRemoveEntryOperations OBJECT-TYPE
            SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "The total number of entries that were deleted
      in this partition since NDSStats.NLM was loaded."
    ::= { nwDSPartOperationsEntry 10 }
      nwDSModifyEntryOperations OBJECT-TYPE
            SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "The total number of entries that were modified
      in this partition since NDSStats.NLM was loaded."
    ::= { nwDSPartOperationsEntry 11 }
      nwDSModifyRDNOperations OBJECT-TYPE
            SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "Sum of modify RDN and Modify DN operations
      (changing the name of an object or the name
      of one of its parents) since NDSStats.NLM
      was loaded."
    ::= { nwDSPartOperationsEntry 12 }
      nwDSListOperations OBJECT-TYPE
            SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "The total number of list operations performed
      in this container or partition since
      NDSStats.NLM was loaded."
    ::= { nwDSPartOperationsEntry 13 }
      nwDSSearchOperation OBJECT-TYPE
            SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "Sum of search operations (subtree, one-level,
      and object searches) that have been performed
      in this container or partition since
      NDSStats.NLM was loaded."
    ::= { nwDSPartOperationsEntry 14 }
      nwDSOneLevelSearchOperation OBJECT-TYPE
            SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "The total number of one-level search operations
      performed in this partition since NDSStats.NLM
      was loaded."
    ::= { nwDSPartOperationsEntry 15 }
      nwDSWholeTreeSearchOperation OBJECT-TYPE
            SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "The total number of subtree-level search operations
                   performed in this partition since NDSStats.NLM
      was loaded."
    ::= { nwDSPartOperationsEntry 16 }
      nwDSMoveEntryOperations OBJECT-TYPE
            SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "The total number of times the [operations?] entry
      was moved since NDSStats.NLM was loaded."
    ::= { nwDSPartOperationsEntry 17 }
      nwDSTypeReferralReturned OBJECT-TYPE
            SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "The total number of times a partition type [mixed - up]
                   (such as master, read-write, read-only)
      referral was returned since NDSStats.NLM
      was loaded. For example, a modify request
      to a read-only partition could return
      a referral to a writable copy."
    ::= { nwDSPartOperationsEntry 18 }
      nwDSTransportReferralReturn OBJECT-TYPE
            SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "The total number of times a transport type
      (such as ipx, ip, appletalk) referral was returned
      since NDSStats.NLM was loaded."
    ::= { nwDSPartOperationsEntry 19 }
      nwDSAliasReferralReturned OBJECT-TYPE
            SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "The total number of times an alias referral
      was returned since NDSStats.NLM was loaded.
      For example, a request for object `Bill`
      (an alias for `William`) could return a referral
      to `William's location."
    ::= { nwDSpartOperationsEntry 20 }
      nwDSOperationsForwarded OBJECT-TYPE
            SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "The total number of operations forwarded
      to another DSA (Directory Services Agent).
      Not currently implemented."
    ::= { nwDSPartOperationsEntry 21 }
      nwDSOperForwardNoSecurity OBJECT-TYPE
            SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "The total number of operations forwarded
      to this DSA (Directory Services Agent)
      that do not meet security requirements.
      For example, operations fail without
      sufficient object rights."
    ::= { nwDSPartOperationsEntry 22 }
      nwDSOperNotServDueToError OBJECT-TYPE
            SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "The total number of operations that were not serviced
                   because of errors other than security. For example,
                   requesting information on an object that does not exist."
    ::= { nwDSPartOperationsEntry 23 }



      .COPYRGT. 1997 Novell Inc.
    ______________________________________

    ______________________________________
    DS Server Info Group
      nwDSExternRef OBJECT-TYPE
            SYNTAX INTEGER
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "The total number of referenced objects
      that are not located on this server
      at the time the request was issued."
    ::= { nwDSServerInfo 1 }
      nwDSSapSocketNum OBJECT-TYPE
            SYNTAX INTEGER
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "SAP socket number (4-byte integer)."
    ::= { nwDSServerInfo 2 }
      nwDSServerID OBJECT-TYPE
            SYNTAX DsObjectID
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "The object ID that uniquely identifies a server
      in the server reference table and which also maps
      as an index into this table."
    ::= { nwDSServerInfo 3 }
      nwDSNcpAddress OBJECT-TYPE
            SYNTAX IPXNetNumber
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "NDS NCP Address"
    ::= { nwDSServerInfo 4 }
      nwMajorDSVersion OBJECT-TYPE
            SYNTAX INTEGER
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "NDS major version. Example: 4."
    ::= { nwDSServerInfo 5 }
      nwMinorDSVersion OBJECT-TYPE
            SYNTAX INTEGER
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "NDS minor version. Example: .11."
    ::= { nwDSServerInfo 6 }
      nwDSRevision OBJECT-TYPE
            SYNTAX INTEGER
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "NDS revision number. Example: 397."
    ::= { nwDSServerInfo 7 }
      nwDSContainerUsage OBJECT-TYPE
            SYNTAX INTEGER
      ACCESS read-write
      STATUS mandatory
      DESCRIPTION
                  "A 32-bit flag that controls the collection of data
                   according to the following constants:
      DSS.sub.-- TRK.sub.-- PARTITIONS-0x00000001,
      DSS.sub.-- TRK.sub.-- CONTAINERS-0x00000002,
      DSS.sub.-- TRK.sub.-- ENTRIES-0x00000004,
      DSS.sub.-- TRK.sub.-- XREFS-0x00000008,
      DSS.sub.-- TRK.sub.-- CONDCODES-0x00000010,
      DSS.sub.-- TRK.sub.-- LASTCCODES-0x00000020,
      The default is set to monitor container usage,
      which is all of the above bits. This value
      can be set as to start monitoring container usage
      or any
      of the [other bits] can be set to monitor these types.
      "
    ::= { nwDSServerInfo 9 }
    DS Container Usage Table
      nwDSContainerUsageTable OBJECT-TYPE
              SYNTAX SEQUENCE OF NwDSContainerUsageEntry
      ACCESS not-accessible
      STATUS mandatory
                DESCRIPTION
                    "A list of containers on this server
      that have been written to or read from
      since NDSStats.NLM was loaded."
    ::= { nwDSServerInfo 10 }
      nwDSContainerUsageEntry OBJECT-TYPE
              SYNTAX NwDSContainerUsageEntry
      ACCESS not-accessible
      STATUS mandatory
                DESCRIPTION
                    "A container-level read or write operation
      which has been performed and which is indexed
      to nwDSContainerUsageEntry"
    INDEX {nwContainerUsageID}
      ::= { nwDSContainerUsageTable 1 }
      NwDSContainerUsageEntry ::= SEQUENCE {
            nwContainerUsageID
                              DsObjectID,
      nwContainerUsageName DisplayString,
      nwContainerWriteOperations Counter,
      nwContainerReadOperations Counter
      nwContainerUsageID OBJECT-TYPE
            SYNTAX DsObjectID
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "A object ID that uniquely identifies
      this container in this [partition, server, tree?]."
    ::= { nwDSContainerUsageEntry 1 }
      nwContainerUsageName OBJECT-TYPE
            SYNTAX DisplayString
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "The Relative Distinguished Name (RDN)
      for container usage."
    ::= { nwDSContainerUsageEntry 2 }
      nwContainerWriteOperations OBJECT-TYPE
            SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "Container usage. The total number of write operations
                   performed on this container since NDSStats.NLM
      was loaded."
    ::= { nwDSContainerUsageEntry 3 }
      nwContainerReadOperations OBJECT-TYPE
            SYNTAX Counter
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
                  "Container usage. The total number of read operations
                   performed on this container since NDSStats.NLM
      was loaded."
    ::= { nwDSContainerUsageEntry 4 }
      .COPYRGT. 1997 Novell Inc.
    ______________________________________

    ______________________________________
    TrapTime  OBJECT-TYPE
                  SYNTAX       INTEGER (0..4294967295)
      ACCESS not-accessible
      STATUS mandatory
      DESCRIPTION
              "The total number of seconds since midnight
      (12 am) of 1 January 1970 GMT (UT)."
            ::= { TrapInfo 1 }
    EventType OBJECT-TYPE
                  SYNTAX       INTEGER (0..4294967295)
      ACCESS not-accessible
      STATUS mandatory
      DESCRIPTION
              "The event type that was reported by the NDS
      Event system."
            ::= { TrapInfo 2 }
    Result    OBJECT-TYPE
                  SYNTAX       INTEGER (0..4294967295)
      ACCESS not-accessible
      STATUS mandatory
      DESCRIPTION
              "The result code of a particular NDS operation.
      The constant that is associated with this
      integer is defined in nwdserr.h."
            ::= { TrapInfo 3 }
    ______________________________________

    ______________________________________
    TRAP-TYPE
      ENTERPRISE ndsTrap-MIB
      VARIABLES
              {
                    ndsTrapTime,
      ndsEventType,
      ndsResult,
      ndsTransportAddressType,
      ndsTransportAddress
      DESCRIPTION
          "Remote NDS server down"
                ::= 16
    ______________________________________

    ______________________________________
    TRAP-TYPE
      ENTERPRISE ndsTrap-MIB
      VARIABLES
              {
                    ndsTrapTime,
      ndsEventType,
      ndsResult,
      ndsTransportAddressType,
      ndsTransportAddress
      DESCRIPTION
          "nds client NCP retries exceeding threshold"
                ::= 17
    ______________________________________

    ______________________________________
    TRAP-TYPE
      ENTERPRISE ndsTrap-MIB
      VARIABLES
              {
                    ndsTrapTime,
      ndsEventType,
      ndsResult,
      ndsPerpetratorName,
      ndsProcessID,
      ndsConnID,
      ndsVerbNumber,
      ndsEntryName
      DESCRIPTION
          "Only one replica"
     ndsEntryName = Partition name
      ::= 41
    ______________________________________

    ______________________________________
    TRAP-TYPE
      ENTERPRISE ndsTrap-MIB
      VARIABLES
              {
                    ndsTrapTime,
      ndsEventType,
      ndsResult,
      ndsPerpetratorName,
      ndsProcessID,
      ndsConnID,
      ndsVerbNumber,
      ndsEntryName,
      ndsEntryName2
      DESCRIPTION
          "NDS name collision"
     ndsEntryName = Original entry name
      ndsEntryName2 = Dulicate entry name
     #TYPE "NDS: name collision"
     #SUMMARY "Name collision %s and %s"
     #ARGUMENTS {7,8}
     #SEVERITY MAJOR
     #TIMEINDEX 0
     #HELP "ndstrap.hlp"
     #HELPTAG 56
     #STATE DEGRADED
      ::= 56
    ______________________________________

    ______________________________________
    ndsMergeTree  TRAP-TYPE
                   ENTERPRISE ndsTrap-MIB
      VARIABLES
                          {
                                  ndsTrapTime,
      ndsEventType,
      ndsResult,
      ndsPerpetratorName,
      ndsProcessID,
      ndsConnID,
      ndsVerbNumber,
      ndsEntryName,
      ndsEntryName2
             }
      DESCRIPTION
              "Merge a tree ndsEntryName2) into another tree
                      (ndsEntryName2)"
     #TYPE "NDS: Merge trees"
     #SUMMARY "Merge trees %s and %s"
     #ARGUMENTS {7, 8}
     #SEVERITY MAJOR
     #TIMEINDEX 0
     #HELP "ndstrap.hlp"
     #HELPTAG 97
     #STATE DEGRADED
      ::= 97
    ndsReloadDS
               TRAP-TYPE
                   ENTERPRISE ndsTrap-MIB
      VARIABLES
                          {
                                  ndsTrapTime,
      ndsEventType,
      ndsResult,
      ndsPerpetratorName,
      ndsProcessID,
      ndsConnID,
      ndsVerbNumber,
      ndsEntryName
                }
             DESCRIPTION
              "Reload DS"
     ndsEntryName = Tree root name
     #TYPE "NDS: Reload DS"
     #SUMMARY "%s reload DS"
     #ARGUMENTS {3}
     #SEVERITY MAJOR
     #TIMEINDEX 0
     #HELP "ndstrap.hlp"
     #HELPTAG 116
     #STATE OPERATIONAL
      ::= 116
    ndschangePassword
               TRAP-TYPE
                   ENTERPRISE ndsTrap-MIB
      VARIABLES
                          {
                                  ndsTrapTime,
      ndsEventType,
      ndsResult,
      ndsPerpetratorName,
      ndsProcessID,
      ndsConnID,
      ndsVerbNumber,
      ndsEntryName
             }
      DESCRIPTION
              "Changing Password"
     #TYPE "NDS: Password changed"
     #SUMMARY "%s change %s password"
     #ARGUMENTS {3, 7}
     #SEVERITY MINOR
     #TIMEINDEX 0
     #HELP "ndstrap.hlp"
     #HELPTAG 67
     #STATE OPERATIONAL
      := 67
    ______________________________________

• Inventors
  Willie, David J.; Yang, Cheng; Cummings, Jay R.; Larsen, Kal A.;
• Published
  Apr-18-2000
• Current US Classes:
  707/10
  707/202
  707/203
  707/204
  709/223
  709/226
• Application #
  922207
• International Classes
  G06F 017/30; G06F 015/173
• Field of Search
  707/10 709/201 709/223 709/226 709/202-204
• Examiner
  Luu; Lehien
• US Patent References:
  5291583
  5317568
  5317742
  5331642
  5471617
  5473608
  5491694
  5491796
  5509123
  5517622
  5522042
  5541911
  5548796
  5559958
  5561769
  5566160
  5572195
  5586304
  5588143
  5721909
  5764977
  5799153
  5835757
  5878434