|
The IETF has recently standardized the NETCONF configuration management protocol and is currently in the process of standardizing a NETCONF-oriented data modeling language called YANG. These two new technologies promise to drastically simplify network configuration management. This paper shows how NETCONF and YANG can be employed to make next-generation configuration management systems considerably simpler, more understandable, and also more robust than current systems.
Why NETCONF and YANG?
The NETCONF protocol makes it possible for network management software to orchestrate transactional changes to several devices of different types. Even complex changes that affect several devices can be executed in an all-or-nothing mode. This means that a large class of error-prone recovery code in the network management system can be eliminated.
The NETCONF protocol moves the responsibility of consistency checks and error recovery to the managed devices, thus making the manager code simpler and the network management system more robust. The fact that the managed devices participate in the two-phase commit issued by the manager allows for implementing in-service configuration updates, spanning several devices in a transactional manner.
The YANG model specification language has two major implications for network management systems. First and foremost, if the managed device publishes a strict XML-based data model that it promises to adhere to, the network management system can reuse that very same model. We will see how the strict data model at the managed device is explicitly used at all layers in the network management system.
Secondly, the advent of standard YANG models for common networking tasks, such as assigning IP addresses to interfaces or changing DNS servers, means that a manager can leverage that by executing identical code towards different types of devices (assuming they all implement the same standard capability). Compare this to how standard SNMP MIBs have made it possible for network management systems to perform several tasks independently of the device model.
With YANG as a modeling language, device vendors and network management system designers now speak a common language. Prior to the introduction of NETCONF in the managed devices, vendors defined the capabilities of their devices largely through a set of CLI commands with an accompanying user guide. YANG models give the vendors a means to communicate a precise data model of the device to network management system designers. The YANG model works as formal glue between the team that designs the device and the network management design team.
YANG provides a more concise and readable notation of XML data models. There is symmetric mapping between YANG and the corresponding XML notation, allowing XML-based tools to validate, transform or filter the data model information.
Let us define a Configuration Manager (CM) as the aspects of an OSS, NMS or EMS solution that reconfigures and provisions managed devices. Many CM solutions have a layered approach with the following three layers.
At the top resides the Service Layer. Here typical concepts are tasks like "provision a new customer" or "increase bandwidth for customer X".
The Service Layer defines concepts that relate to the day-to-day business flows for a service provider. Thus it must be easy and fast to make changes to the service models as new business scenarios emerge. The service models are typically modeled with SID, UML, or proprietary languages. The Service Layer also maintains an inventory of service instances in persistent storage.
Below the Service layer resides the Resource Layer. This is where individual devices are modeled. Usually this is done in XML Schema, UML, or proprietary languages. The task of the Resource Layer is to provide a mapping from the Service Layer to actual device manipulations. Thus the Service Layer task "provision new customer" in, for example, an ADSL provider scenario includes a series of manipulations of switches, routers, and DSLAMs. The individual devices and their configurations that are involved in the configuration change are represented in abstract form as data structures local to the CM.
At the Resource Layer, the CM maintains a database of network resource instances. Thus, this layer has a database of all managed devices, their current configurations, their models, and also the version of the software on the devices.
|
