1. Field of the Invention
Implementations consistent with the principles of the invention relate generally to device management and, more particularly, to the use of hierarchical domains to manage devices.
2. Description of Related Art
All networks are different, but each network is typically built the same way. For example, a network is designed, the necessary equipment is purchased, and the network components are built and customized to operate in a particular way. In an ideal world, that would be the end of the job—the perfect network has perfect uptime, with perfect redundancy, growth potential, etc. The reality is that managing network devices is fast-becoming a full-time job. Ensuring that all devices in the system are up and running, patched against vulnerabilities and exploits, and functioning as expected requires a team of intelligent and committed individuals who understand every aspect of the network. To respond quickly and appropriately to a network situation, information technology (IT) administrators, network administrators, and security administrators need complete control over network connectivity, network access, and network traffic flow.
As the network grows, individual device maintenance can quickly become a logistical nightmare. New devices, new networking technologies, software upgrades—almost every change to the network requires some human and monetary resource. Even in small networks, setting up and maintaining each device individually is time-consuming, prone to error, and likely to require network downtime. Many organizations are now turning towards integrated management solutions to help them configure and manage devices more efficiently.
According to one aspect, a method for managing a network that includes devices, administrators, and objects is provided. The method may include forming a hierarchical tree of domains that semantically organize the network, where each of the domains includes logical groupings of the devices, the administrators, or the objects; and managing the network based on the hierarchical tree of domains.
According to another aspect, a system for managing a network that includes devices and administrators associated with one or more entities is provided. The system may include means for generating a hierarchical tree of domains that reflect a structure of the one or more entities, where the domains include logical groupings of the devices and the administrators. The system may also include means for managing the network based on the hierarchical tree of domains.
According to yet another aspect, a management system may include a memory and a processor. The memory may store a hierarchical tree of domains that resemble a structure of an entity, where the domains include logical groupings of devices, administrators, and objects associated with the entity. The processor may identify an activity that one of the administrators can perform within one of the domains, where the domain is related to a child domain in the hierarchical tree. The processor may permit the administrator to perform the activity in the domain and the child domain.
According to a further aspect, a management system may include a memory and a processor. The memory may store a hierarchical tree of domains that resemble a structure of an entity, where the domains include logical groupings of devices, administrators, and objects associated with the entity. The processor may identify one of the objects as shared within one of the domains, where the domain is related to a child domain in the hierarchical tree. The processor may permit the child domain to use the object.
According to another aspect, a management system may include a memory and a processor. The memory may store a hierarchical tree of domains that resemble a structure of an entity, where the domains include logical groupings of devices, administrators, and objects associated with the entity. The processor may identify an expression within one of the domains, where the domain is related to a child domain in the hierarchical tree. The processor may impose the expression on the child domain.
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate an embodiment of the invention and, together with the description, explain the invention. In the drawings,
The following detailed description of the invention refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Also, the following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims and equivalents.
Systems and methods consistent with the principles of the invention may facilitate the management of network devices associated with one or more entities (e.g., companies, groups, organizations, etc.). The systems and methods may use hierarchical domains to form an organizational delegation model. The organizational delegation model may encode the notion of the structure of an entity, which may reflect the structure of a network associated with the entity, geographical locations associated with the entity, organizations making up the entity, or any other logical representation identified by the entity. For example, an entity may include devices in different locations, and/or associated with different divisions, offices, groups, or departments.
Network 120 may include any type of network, such as a wide area network (WAN), a local area network (LAN), an intranet, the Internet, or a telephone network (e.g., the Public Switched Telephone Network (PSTN)). Alternatively, network 120 may include a combination of networks.
Management system 110 may be implemented within a device, such as a computer, or a combination of devices, such as a combination of computers. Management system 110 may provide functionality to integrate management of devices associated with entities A-C. For example, management system 110 may permit an administrator to identify, configure, manage, monitor, and/or generate reports with regard to devices associated with entities A-C.
In one implementation, management system 110 may permit co-management of devices associated with entities A-C. Co-management means that not only may management system 110 manage devices associated with entities A-C, but management system 110 may permit entities A-C to manage their own devices. For example, an entity may manage its own devices via a network interface (e.g., a web interface) to management system 110 or by installing an application that facilitates device management.
In one implementation, management system 110 includes a server 115 that may store data for the devices associated with entities A-C. Management system 110 may use the data in server 115 to identify, configure, manage, monitor, and/or generate reports with regard to devices associated with entities A-C. Entities A-C may make use of data associated with their respective devices to identify, configure, manage, monitor, and/or generate reports with regard to their respective devices.
Each of entities A-C may represent any type of group or association, such as a company or an organization. Each of entities A-C may include one or more offices in one or more locations and one or more devices in each office and/or location. Each office and/or location may identify, configure, manage, monitor, and/or generate reports with regard to its own set of devices.
In one implementation, entity A connects to management system 110 via network 120, as shown in
As shown in
The North America division may include three departments: a marketing department, an engineering department, and a quality assurance department. These departments may be located in the same or a different physical location. The engineering department may include a hardware group and a software group. These groups may be located in the same or a different physical location.
Associated with the company and each of these divisions, departments, and groups may be a set of devices. These devices might include any network device that can be remotely controlled and/or monitored. In one implementation, the network devices might include security devices (e.g., devices that perform firewall, virtual private network (VPN), denial of service (DoS) protection, traffic management processing, and/or other security-related processing), other types of devices that may permit access to network 200, control access to data within network 200, and/or protect network 200 against malicious traffic or other forms of attack, personal computers, and/or other types of computation or communication devices.
The devices associated with the company, divisions, departments, and groups may connect via any type of connection mechanism. For example, the devices may connect via wired, wireless, and/or optical connections. Alternatively or additionally, the devices may connect via a network, such as a WAN, a LAN, an intranet, the Internet, a telephone network (e.g., the PSTN), or a combination of networks.
At least some of the devices might control access to network 200 from outside of network 200. The devices might also control access to particular types of data within network 200. For example, a device might limit access to marketing-sensitive data to the marketing department. Similarly, a device might limit access to source code to the engineering department, or perhaps, the software group within the engineering department.
As illustrated, device 300 may include a bus 310, a processor 320, a main memory 330, a read only memory (ROM) 340, a storage device 350, an input device 360, an output device 370, and a communication interface 380. Bus 310 may permit communication among the elements of device 300.
Processor 320 may include a conventional processor, microprocessor, or processing logic that may interpret and execute instructions. Main memory 330 may include a random access memory (RAM) or another type of dynamic storage device that may store information and instructions for execution by processor 320. ROM 340 may include a conventional ROM device or another type of static storage device that may store static information and instructions for use by processor 320. Storage device 350 may include a magnetic and/or optical recording medium and its corresponding drive.
Input device 360 may include a conventional mechanism that permits an administrator to input information to device 300, such as a keyboard, a mouse, a keypad, a pen, voice recognition and/or biometric mechanisms, etc. Output device 370 may include a conventional mechanism that outputs information to the administrator, including a display, a printer, a speaker, etc. Communication interface 380 may include any transceiver-like mechanism that enables device 300 to communicate with other devices and/or systems.
Device 300 may perform certain processes in response to processor 320 executing software instructions contained in a computer-readable medium, such as memory 330. A computer-readable medium may be defined as a physical or logical memory device and/or carrier wave. The software instructions may be read into memory 330 from another computer-readable medium, such as storage device 350, or from another device via communication interface 380. The software instructions contained in memory 330 may cause processor 320 to perform processes that will be described later. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes consistent with the principles of the invention. Thus, implementations consistent with the principles of the invention are not limited to any specific combination of hardware circuitry and software.
Implementations consistent with the principles of the invention may model a network while maintaining the notion of the structure of the entities in the network. In one implementation, the model is created and/or maintained by management system 110. The model may be based on a hierarchical tree of domains that semantically organize every aspect of the network, including devices, administrators, and objects. Each domain may have zero or more associated devices, zero or more associated administrators, and zero or more associated objects. An object may be defined as a data structure with one or more sub-fields that may represent reusable information, such as network addresses, individual administrators, administrator groups, and commonly used configuration data.
The model for a network may include one or more domains. Multiple domains may be used for two reasons: (1) to define the structure of an entity or a group of entities; and (2) to control administrator access. Multiple domains may help separate large, geographically distant portions of an entity into smaller, more manageable sections, and to control administrative access to individual sections.
A small entity may include a single domain for their entire network. A large, international entity, on the other hand, might have dozens of domains to represent each of its regional networks across the world. The domains, in this latter situation, may be arranged in a hierarchical tree structure similar to the structure of the entity (see, for example,
Semantic relationships may exist between domains in the same branch of the hierarchical tree. One semantic relationship may be related to recursive permissions, which means that if an administrator has permission to perform an activity at a parent domain, then the administrator also has permission to perform the activity at any of the child domains. Another semantic relationship may be related to object acquisition, which means that if an object is defined at a parent domain, then the object can be used by any of the child domains. A further semantic relationship may be related to imposition, which means that a parent domain can impose constraints on a child domain. Other semantic relationships may also exist.
Permissions specify the exact activities that administrators can perform within a domain. There may be hundreds (or more) possible activities that an administrator can perform within a domain. The permissions may specify which of these activities, if any, the administrator can perform.
There are several ways to define the activities that can be performed within a domain. One such way is based on the well-known Telecommunications Management Network (TMN) model.
The verticals are labeled FCAPS, where F refers to fault management, C refers to configuration management, A refers to accounting management, P refers to performance management, and S refers to security management. Fault management involves identifying and correcting network problems and faults. Configuration management involves locating resources, including failed resources, and keeping track of the types of resources and their details. Accounting management involves tracking service usage and informing relevant users and authorities about the usage of resources and the costs associated with their usage. Performance management involves gathering network statistics, evaluating system performance under both normal and degraded conditions and altering system modes of operation. Security management involves ensuring legitimate use and maintaining confidentiality, data integrity, and auditability.
The horizontals are labeled BML, SML, NML, EML, and NEL, where BML refers to a business management layer, SML refers to a service management layer, NML refers to a network management layer, EML refers to an element management layer, and NEL refers to a network element layer. The business management layer refers to functions, such as budgeting and billing. The service management layer refers to service functions, such as assuring service level agreements and maintaining quality of service. The network management layer refers to functions, such as path management, topology management, and fault isolation. The element management layer refers to device level configuration and fault and performance management functions. The network element layer refers to logical elements within a network.
The intersections of the verticals and horizontals may define certain activities that may be associated with a domain. Permissions may be granted to administrators based on these intersections to permit administrators to perform particular types of activities within a domain.
Another way to define the activities that can be performed within a domain may be based on the well-known Tele-Management (TM) Forum model.
The verticals are labeled FAB, where F refers to fulfillment, A refers to assurance, and B refers to billing. Fulfillment is concerned with setting up customers' service. Assurance is concerned with guaranteeing that services are performed as specified. Billing is concerned with billing or paying for provided services.
The horizontals are labeled CC, SDO, NSM, NEMP, and PNIT, where CC refers to customer care, SDO refers to service development and operation, NSM refers to network and systems management, NEMP refers to network element management processes, and PNIT refers to physical network and information technology. Customer care is concerned with customer relationship management. Service development and operation is concerned with service configuration, activation, and management. Network and systems management is concerned with resource provisioning, allocation, and management. Network element management processes is concerned with the network planning, provisioning, and management. Physical network and information technology refers to the physical network and the technology used.
Similar to the TMS model, the intersections of the verticals and horizontals may define certain activities that may be associated with a domain. Permissions may be granted to administrators based on these intersections to permit administrators to perform particular types of activities within a domain.
Permissions granted to the administrators are recursive in that any activity that an administrator is assigned at a domain is recursively applied to its child domains (if any). For example, assume that administrator Bob is assigned the activity of viewing logs in the engineering department subdomain in
When a permission granted to an administrator includes the ability to add new administrators, the administrator cannot give a new administrator anything more in the way of permissions than the administrator has herself. For example, assume that administrator Mary is assigned the activity of creating new administrators and viewing logs in the marketing department subdomain in
If a permission assigned to the administrator either in the domain or a parent domain identifies the activity, then the administrator is permitted to perform the activity within the domain (block 730). Otherwise, the administrator is refused permission to perform the activity within the domain (block 740).
Objects may be declared as shared objects within a domain. Shared objects can be shared by all devices in the same domain. An object that is declared as shared within a domain can also be used by devices in all child domains related to the domain. An object can be used multiple times in the same domain. For example, assume that an address object is created to represent a host, such as an individual workstation. The address object may also be used in a VPN resource and/or as the source or destination in a firewall policy rule.
Assume that the entity A domain in
As stated above, a child domain may make use of a shared object from a parent domain. Use of the shared object by the child domain is valid for the lifetime of the child domain. If the parent domain changes the shared object, the change is reflected in the child domain.
A domain can impose expressions, such as rules, configuration parameters, login controls, and other forms of constraints, on its child domains. A domain can also enforce or override an expression in one of its child domains.
One form of expressions that can be imposed includes rules. A device has an associated set of rules, called a “rule base,” that it will execute when it has a task to perform. The rule base is an ordered list of rules that the device executes to determine how to perform the task. For example, in the case of a firewall device, the firewall device may execute the list of rules in the rule base every time a packet is received to determine whether to accept or deny the packet.
Rules may be declared within different domains of the hierarchy. Rules in a parent domain may be imposed on devices in child domains. In one implementation, the rule base for a device may include the collection of rule sets that are declared at different levels of the hierarchy. The rule base may be determined and provided to the device at the time of configuring the device. For example, at configuration time, the rules from the domain with which the device is associated and the parent domain(s) may be combined, put in the correct order, and pushed to the device.
Returning to the exemplary diagram of
Domains may declare pre-rules and post-rules. A pre-rule is a rule that is executed prior to other rules. A post-rule is a rule that is executed after other rules. Consider the same example given above, except that in this case, each of the parent domains declares some pre-rules as well as some post-rules. In this case, the rule base for the device in the marketing department subdomain might resemble:
In addition to rules, expressions can be defined at a domain and analyzed or evaluated at the child domains. For example, assume that administrator Carly in the quality assurance department subdomain in
Systems and methods consistent with the principles of the invention may facilitate the management of network devices associated with one or more entities using hierarchical modeling and the notion of domains.
The foregoing description of preferred embodiments of the invention provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention.
For example, while a series of acts has been described with regard to
It will also be apparent to one of ordinary skill in the art that aspects of the invention, as described above, may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement aspects consistent with the principles of the invention is not limiting of the present invention. Thus, the operation and behavior of the aspects were described without reference to the specific software code—it being understood that one of ordinary skill in the art would be able to design software and control hardware to implement the aspects based on the description herein.
No element, act, or instruction used in the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Where only one item is intended, the term “one” or similar language is used. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.
Number | Name | Date | Kind |
---|---|---|---|
5797128 | Birnbaum | Aug 1998 | A |
5907844 | Guay et al. | May 1999 | A |
6031990 | Sivakumar et al. | Feb 2000 | A |
6041347 | Harsham et al. | Mar 2000 | A |
6041374 | Postman et al. | Mar 2000 | A |
6064656 | Angal et al. | May 2000 | A |
6158010 | Moriconi et al. | Dec 2000 | A |
6219829 | Sivakumar et al. | Apr 2001 | B1 |
6226745 | Wiederhold | May 2001 | B1 |
6233686 | Zenchelsky et al. | May 2001 | B1 |
6237036 | Ueno et al. | May 2001 | B1 |
6446077 | Straube et al. | Sep 2002 | B2 |
6985955 | Gullotta et al. | Jan 2006 | B2 |
7103784 | Brown et al. | Sep 2006 | B1 |
7194764 | Martherus et al. | Mar 2007 | B2 |
7219142 | Parekh et al. | May 2007 | B1 |
7269727 | Mukherjee et al. | Sep 2007 | B1 |
7912971 | Dunn | Mar 2011 | B1 |
20010007133 | Moriconi et al. | Jul 2001 | A1 |
20020095499 | Barnett et al. | Jul 2002 | A1 |
20020112155 | Martherus et al. | Aug 2002 | A1 |
20020147801 | Gullotta et al. | Oct 2002 | A1 |
20030115322 | Moriconi et al. | Jun 2003 | A1 |
20060129942 | McCary | Jun 2006 | A1 |
20070214497 | Montgomery et al. | Sep 2007 | A1 |