Network Virtualization in open-esb (1)

Simple Network Management Protocol is used traditionally for managing the network though with several drawbacks. Some of the drawbacks are

  • Security -- basic SNMP has only trivial authentication. It does not talk about either aaa or radius which are of Network Management standard.

  • There is no interchange format for configuration data. Inability for configuration management. Thus, if two or more agents shall receive the same configuration, the same sequence of SNMP set messages have to be sent to all the agents. There are no “setConfig” or “ copyConfig” operations in SNMP.

  • SNMP is a low level technology. The protocol is simple, leaving the complexity to the management application. This is especially problematic for configuration, because configuration tasks are per se more complex than monitoring tasks.

  • Talking in XML

  • Not reflecting the Native device closely -- i.e. the MIBs exposed by any of the device does not reflect all of the data of the device its only a portion of the data

  • Does not speak of 'Syslog'

  • SNMP MIB model is limited and does not readily support applications that make sophisticated management queries based on object values or types

  • Does not support manager to Manager communications which makes for us tough to integrate with either IBM Tivoli or HP OpenView which are like some standard in the industry.

  • Does not support truly large networks -- because of lack of data structures and other limitations

Though some of the limitations are addressed in later versions of SNMP it still has issues while we talk about large networks. NetConf protocol tries to address the limitations of SNMP and defines a simple mechanism through which a network device can be managed, configuration data information can be retrieved, and new configuration data can be uploaded and manipulated. Lets look at the key aspects of NetConf.

  • Allows the device to expose a full,formal, application programming interface (API).

  • Applications can use this straight-forward API to send and receive full and partial configuration data sets

  • NETCONF uses a remote procedure call (RPC) paradigm to define a formal API for the network device.

  • It allows the functionality of the API to closely mirror the native functionality of the device. In addition, applications can access both the syntactic and semantic content of the device's native user interface.

  • NETCONF allows a client to discover the set of protocol extensions supported by a server.  These "capabilities" permit the client to adjust its behavior to take advantage of the features exposed by the device.

  • XML is the lingua franca of interchange, providing a flexible but fully specified encoding mechanism for hierarchical content.

  • What makes NETCONF all the more attractive is that it can be used in concert with XML-based transformation technologies such as XSLT to provide a system for automated generation of full and partial configurations. This gives the NMS using NetConf the power of  querying one or more databases for data about networking topologies, links, policies, customers, and services.  This data can be transformed using one or more XSLT scripts from a task-oriented, vendor-independent data schema into a form that is specific to the vendor, product, operating system, and software release.  The resulting data can be passed to the device using the NETCONF protocol.

The glitch for the success of NetConf is that there are no standard data models for NETCONF comparable to those defined in SMI MIB modules within the SNMP framework. In order to start using the protocol, data models for NETCONF must be designed, which can be a quite difficult task. Currently, there is a draft specification for a data model framework (Chisholm, S. and Adwankar, S., 2005) but there are no data models. For the SNMP framework, a lot of data models in form of SMI MIBs have already been specified. In order to save development time and money, it would be useful to be able to reuse these data models. But there are some issues involved in mapping datamodels as discussed by Torsten Klie:

  • An important difference between SNMP and NETCONF is the separation between state data and configuration data. SNMP does not distinguish between these two kinds of data. Therefore, SMI does not provide any means to specify whether an object shall be considered a configuration object or state data. Thus, a simple straight-forward mapping from SMI MIB modules to NETCONF modules is not possible.How can we decide, to which kind of data an object in a MIB belongs? -- Separation can be based upon datatypes and read-only objects.

  • The structure of the data representation in XML is geared to the SMI to W3C XML Schema (Fallside, C.and Walmsley, P., 2004) mapping described in (Strauß, F. and Klie, T., 2003), which uses a flattened element hierarchy and does not convert the OID tree hierarchy to deeply nested elements. This improves readability a lot, compared to a straight forward mapping. However, the mapping must be slightly modified.

If we think carefully from a Network Management Perspective there can be one more level of abstraction. NetConf protocol does not talk of the Payload in the Application Layer in the following figure, and leaves the implementation details to the NMS implementation.

Layer Example
+-------------+ +-----------------------------+
(4) | Content | | Configuration data |
+-------------+ +-----------------------------+
| |
+-------------+ +-----------------------------+
(3) | Operations | | <get-config>,
<edit-config> |
+-------------+ +-----------------------------+
| |
+-------------+ +-----------------------------+
(2) | RPC | | <rpc>, <rpc-reply>
+-------------+ +-----------------------------+
| |
+-------------+ +-----------------------------+
(1) | Application | | BEEP, SSH, SSL, console |
| Protocol | | |
+-------------+ +-----------------------------+

This gives the NMS developer the flexibility to have his own pay load and shield the implementation details from the user but at the same time can confirm to a standard data in the form of XSD's. Confirming to XSDs would ensure that the data is inter-operable amongst different Applications like IBM Tivoli and HP Open View etc. You visualize the application as below" style=";text-align:left" width="545">

We will continue with exploration of the above Architecture in my next blog in this series.


Post a Comment:
  • HTML Syntax: NOT allowed

I was part of Sun R&D in Java CAPS and later Glassfish ESB. I moved from R&D to Consulting. I am currently working as a Solution Architect in Oracle Consulting Services (India). I was sharing my experience w.r.t. Java CAPS and other technologies during Sun period. Now in Oracle world I share my experiences with Oracle FMW product line as well as other Oracle Technologies and products.


« July 2016