Patent Application
20110153788
Network management plays a fundamental role in the operation and well being of today's networks. The configuration of network elements collectively determines the very functionality provided by the network in terms of protocols and mechanisms involved in providing functionality such as basic packet forwarding. Configuration management, or more generically all commands executed via the operational interface of network elements, are also the primary means through which most network operational tasks, e.g., planned maintenance, performance monitoring, fault management, service realization, capacity planning, etc. are performed.
A system includes a memory storing a set of instructions executable by a processor. The set of instructions is operable to receive a process for accomplishing a network management task, the process including a plurality of events including configuration changing events and condition checking events; receive parameters related to the task; include the parameters in the process; and execute the process.
A system includes a memory storing a set of instructions executable by a processor. The set of instructions is operable to record an execution of a network management task by a user, the execution comprising a communication between the user and a network component; extract, from the recording of the task, a plurality of events, the plurality of events including one of a configuration changing event and a condition checking event; and generate, from the events, a process for accomplishing the network management task, the process including the plurality of events.
A system includes means for receiving a process for accomplishing a network management task, the process including a plurality of events including configuration changing events and condition checking events. The system also includes means for receiving parameters related to the task. The system also includes means for including the parameters in the process. The system also includes means for executing the process.
The exemplary embodiments may be further understood with reference to the following description and the appended drawings, wherein like elements are referred to with the same reference numerals. The exemplary embodiments describe methods and systems for performing tasks associated with networks including configuration, monitoring, maintenance, operation and planning tasks.
Network operations are typically managed using libraries of methods of procedure (“MOP”). MOPs describe procedures to be followed in order to accomplish specific tasks. Components of MOPs may include configuration changes (or “actions”) to be performed, operational checks (or “conditions”) that must be satisfied in order for such actions to be deemed successful, and execution logic tying actions and conditions together. MOPS are typically stored as libraries of text.
MOPs, as presently used, possess two main advantageous properties. First, they document structure (e.g., actions, conditions, logical framework) and present a natural way for operators to perform operational activities. Second, the logic therein embodies expert knowledge of the MOP designer to ensure that goals are met, while minimizing unwanted side effects of operational actions. The exemplary embodiments provide an improved alternative to MOPS by using active documents meant for execution in the framework to be discussed below. Active documents (or “ADs”) may formalize the procedures described in MOPs into an executable format, thus forming a building block for automation of network operations. ADs may enable the complete execution of low-level management tasks, and may further be combined into larger-scale ADs to accomplish higher-level goals.
The interaction between actions and conditions is modeled by arrows between nodes. An arrow may be enabled or disabled; enabled arrows are indicated by a dotted line, while a disabled arrow is indicated by a solid line. In
Further, an inter-task policy mechanism 224 may interface with one or more execution tasks 222 to form a composed execution task 226, comprised of multiple ADs executing in coordination. The inter-task policy mechanism may impose a high level constraint for the coordination of multiple execution tasks 222. For example, a user may desire to run two separate maintenance tasks 222 on a network. The inter-task policy mechanism 224 may have a high level constraint that certain subsets of routers may not be taken offline at the same time. However, the two separate maintenance tasks 222 may, in fact, request that these router subsets go offline simultaneously. The inter-task policy mechanism 224 may combine the maintenance sub-tasks 222 into a composed execution task 226 where, for example, the tasks are carried out serially to avoid the rule against the router outages. To carry out the particular policy, the ADs of all the sub-tasks are combined into a composed execution task 226 through the use of additional nodes and arrows as those components have been described above. The policy enforcement logic of the inter-task policy mechanism is embedded within the composed execution task 226.
Those skilled in the art will understand that the above is only exemplary, there may be any number of rules that may be used to combine two or more execution tasks 222 into a composed execution task 226. For example, to provision a VPN customer on a PE router, a composed execution task 226 may be generated from three sub-tasks 222. These three sub-tasks 22 may include (1) configuring a VPN instance, configuring IP addresses on the customer facing interface and verifying layer-3 connectivity; (2) setting up a BGP session connecting to the customer edge router and verifying session establishment; and (3) verifying VPN connectivity. There are any number of tasks that may be combined into a composed execution task 226.
An execution task 222 or a composed execution task 226 may then be passed to an execution environment 230, in which they become running execution tasks 232. Running execution tasks 232 may be executed by execution engine 234, which may be adapted to execute ADs such as that described above. The execution engine 232 may handle API calls and task failures. The execution engine 234 may communicate with network elements 238 in the course of this execution to, for example, perform the configurations specified by the execution task, obtain various types of information, etc. The execution may be further monitored by external entities 236 by, for example, the execution engine 234 exposing APIs for the external entities 236 to call. The external entities 236 may be, for example, a standalone network monitoring tool, a network operator, etc. The execution engine 234 may also be responsible for scheduling multiple tasks to run concurrently. Thus, by following this framework, ADs may be executed with minimal user interaction or supervision.
This performance is monitored and documented by a recorder 350, which performs multiple functions during this performance. First, the recorder 350 logs the interactions between the user 330 and the one or more network elements 340. Typically, the user 330 may interact with the network elements 340 via telnet or ssh, and the recorder 350 may, simply log these interactions without affecting the performance of the task. Second, the recorder 350 may record various state information to augment the interaction logs described above. This may include device logs (e.g., BGP log, syslog, etc.), traffic data (e.g., packet count on interfaces), and trap messages sent when certain events occur.
After the recorder 350 has made a log pertaining to the task governed by MOP 320, an extractor 360 extracts two types of steps from the log: configuration changing steps, which generally correspond to action nodes described above, and condition checking steps, which generally correspond to condition nodes described above. Generally, configuration changing events and condition checking events may be distinguished simply based on the console mode. Each condition checking command may form a single event, while multiple commands may be executed consecutively to effect a configuration change. Commands executed within a same console not interrupted by other commands in another console are interpreted as a single event.
Once the extractor 360 has extracted a sequence of events from the log created by the recorder 350, an editor 370, in consultation with the MOP 320, reviews the events for accuracy. The review may include separating incorrectly combined configuration changing events, deleting redundant condition checking events, etc. The reviewed list of events is then converted to action nodes and condition nodes, both of which have been described above. Configuration change commands are converted to CommitConfigDelta( ) API calls, and condition checking commands are converted to QueryDeviceStatus( ) API calls. The editor 370 will perform four tasks to complete the creation of the AD 310.
First, the editor 370 performs parameter identification. This means, for example, replacing an actual IP address in an extracted event with a parameter representing an IP address. Next, the editor 370 adds arrows among nodes to indicate the interaction between the various action and condition nodes. This may include, for example, identification of iterative processes; the extractor 360 may identify a plurality of condition checking events checking the same condition and repeating a subsequent action event or events until a condition is satisfied, and such condition checking events may then be replaced by a single condition checking event that may be repeated.
Third, the editor 370 specifies the criteria by which decisions are made in condition nodes based on retrieved information. For example, where the user 330 executes a “show interface” command, the editor 370 determines whether the user 330 is checking if the interface is up, checking the encapsulation of the interface, checking a configuration of an IP address, etc. The editor 370 may make these determinations in accordance with information in the MOP 320. Fourth, the editor 370 adds API calls, such as NotifyEntity( ) calls and QueryEntity( ) calls, to action nodes and condition nodes as necessary, as they may not be recorded by the recorder 350.
The result of the above is an AD 310 that performs a function described by the MOP 320. The editor 370 may then verify the performance of the AD 310 in relation to the network elements 340 before it is entered into a library, such as the library 210 of
By performing the method 300 for each of a plurality of MOPs 320, a library of ADs 310 such as the library 210 of
Those skilled in the art will understand that the exemplary embodiments may be implemented as hardware, software or a combination thereof. For example, the exemplary embodiments may be implemented as a memory storing a set of instructions that are executable by a processor to accomplish a particular task.
It will be apparent to those skilled in the art that various modifications may be made in the present invention, without departing from the spirit or the scope of the invention. Thus, it is intended that the present invention cover modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.
