Networking architectures and network devices, such as routers and switches, as well as their configurations, are becoming increasingly complex both in structure and functionality. Such complexities require network engineers or other personnel to know hundreds or thousands of vendor-specific command or syntaxes and to master both the hardware and software idiosyncrasies of each differently manufactured networked device in order to successfully configure and manage a network. But traditional network management techniques, which include network device configuration and maintenance processes, fail to amply provide network administrators (or any network user) with a means to control the creation, the deployment, or the modification of each device configuration in a scalable and consistent manner.
Rather, network operators often configure devices without regard to any of the business processes affected by implemented configurations, which can lead to a disruption of network services. Without any mechanism for tying business processes and network management processes together, a newly applied configuration to a device just becomes a mere setting on a device. Consequently, the entire functionality of the configured device is not performed with business considerations prior to or after this configuration, which in turn, isolates the network processes from an organization's business processes. This hinders network efficiency. As most existing networking tools (e.g., provisioning tools) do not offer a view of the entire network, they typically offer only a limited view into, for example, an individual interface of a device.
The combined increase in network users and in sophistication of networked applications further militates integrating network management and business processes by establishing business rules that govern the usage of shared network resources. For example, a set of business rules can determine which user or network traffic has priority in using those shared network resources. But to control networking processes, each network resource's structure and functionality should be normalized to share and to reuse application data.
To normalize the structure and functionality of each network resource requires at least abstracting the resource's functionality. But abstracting resource functionality is difficult because most networks are built using different devices, each of which have many different capabilities and command syntaxes. Further, different vendors use different programming models for their vendor-specific network devices. The use of different programming models often leads to an inoperable or suboptimal networking of resources. For example, the use of varied programming models tends to impair a network operator's ability to determine whether a certain traffic conditioning used to separate different classes of traffic is correct.
FIG. 1 is a diagram showing network resources as sources of network information, each of which is associated with a different programming model. For example, a network portion 100 includes a first router manufactured by vendor one having a set of vendor-specific command line interface (“CLI”) commands 102, a second router built by vendor two having another set of vendor-specific CLI commands 104, and one or more repositories of one or more Policy Information Bases (“PIBs”) and/or Management Information Bases (“MIBs”) 106. If FIG. 1 represents a portion of a conventional network, some routers support CLI 102 and 104 for provisioning while other routers employ Simple Network Management Protocol (“SNMP”) for monitoring, which includes information from MIBs and PIBs 106.
Without an underlying uniform data representation 110 that relates the CLI commands to SNMP commands, it is in general impossible to correlate the commands of one programming model to the commands of another programming model. And since many network vendors build separate applications for managing different sets of features present in the same vendor-specific device, a minimum number of multiple applications are required to manage and to provision devices from not only different devices from different vendors, but also from the same vendor as well. An example of an instance where multiple applications are necessary is the case where two or more billing applications collect data differently and use different metrics to determine an amount that a network customer should be billed. This determination is complicated further if there are different devices supporting different proprietary MIBs to generate data, which are typically not in a suitable form for the billing applications to process.
Although present devices and techniques for managing networks are functional, they are not sufficiently accurate or otherwise satisfactory. Accordingly, a system and method are needed to address the shortfalls of present technology and to provide other new and innovative features.