Enterprise Networking

Inside Whitepaper

• Introduction
• Management Platforms and SNMP
• Web Based Configuration
• XML Interface
• DMTF CIM
• References

• Home »
• Whitepapers »
• Device Management & Remote Network Monitoring

Device Management Functionality - An Analysis

Introduction

This document takes a critical look at the management interfaces provided by networking equipment- routers, switches and VPN devices. Features provided by current products are examined, and evolving trends in the industry are surveyed.

The document doesn't dwell on the configuration of specific features, but only considers the architectural and interface issues. Specific configuration features -say, number of security levels of users, key configuration etc - are better addressed with reference to the specific product functionality.

In the subsequent sections, we consider different aspects of device management, and discuss evolving trends from a device vendor's perspective. Based on this, we offer a few recommendations for implementing appropriate management functionality on the device.

Management Platforms and SNMP

SNMP capability is essential to make the device manageable from standard management platforms. Such platforms have many limitations but are widely deployed for fault and performance management - e.g., HP OpenView and CA Unicenter. These platforms discover the devices through ICMP and use SNMP to query and present more useful information on the map. Support of certain standard MIBs makes devices more manageable. By providing sufficient information in the proprietary traps, we can provide quick integration with platforms like HP OpenView.

Support for Standard MIBs

Apart from providing device specific information by implementing and publishing proprietary MIBs, a SNMP agent has to support SNMPv2 MIB. Under system and SNMP groups, this MIB supports certain very useful parameters like system description (sysDescr) and many SNMP counters.

Entity-MIB (RFC 2737) allows a single SNMP agent to represent multiple logical entities. It stores information about the physical entities (say, different cards), the logical entities and their relationships [7]. This information can be used by the management stations to show a graphical representation too.

IF-MIB (RFC 2863), IP-MIB (RFC 2011), TCP-MIB (RFC 2012) , UDP-MIB (RFC 2013) are other MIBs that are relevant for most networking devices.

RMON

Remote Network Monitoring (RMON) framework defined by IETF consists of a number of related standards. A probe or a monitor is the key element of the framework. It passively monitors the traffic, collecting statistical information about the nature of traffic, including the protocol information at various levels. SNMP is used by the management stations to query the collected data. RMON MIB defines the structure of this information.

RMON agent can be built in to routers/VPN devices. This will consume good amount of memory and CPU power But when processing power is available, providing RMON capability on the device will provide many advantages like proactive problem detection, traffic profiling for capacity planning etc.

RMON 2 implementation provides more information about higher protocol layers, which can be very valuable.

sFlow

This is a sampling technology supported by a few vendors including Hewlett-Packard, Extreme Networks, Foundary Networks and Force10. Traffic data collected by the hardware is forwarded to remote "sFlow Collectors" by a lightweight agent running on the device.

sFlow and RMON essentially address the same problem. RMON agent collects, processes and stores data for retrieval by the management stations. sFlow depends on the data collectors to process and store the information. At this point it is difficult to see to what extent sFlow will be accepted by other vendors. [1] provides a good overview of sFlow.

Cisco offers similar functionality through NetFlow services.

Link Layer Discovery Protocol

This is a protocol from IEEE. 802.1 AB LLDP is a neighbour discovery protocol that involves layer 2 devices advertizing their presence by sending "Type-Length-Value (TLV)" messages to their neighbours. These messages contain the identity of the device, capabilities etc. This protcol is extensible. TIA (Telecommunications Industry Association) has developed an extension to LLDP (LLDP-Media Endpoint Discovery) for VoIP networks.

Support of LLDP will enable prompt discovery of the device in next generation management products.

Web Based Configuration

Web-based configuration has emerged as a necessity in the last few years. With an embedded web server running on the device, configuration is achieved easily with ubiquitous browsers.

Major considerations in providing this feature are selection of an appropriate web server, and ensuring a user-friendly interface. For a nice HTML based user interface, basic web server is sufficient. With XML gaining popularity as well as focus in the web enabled world and in particular, Device and Element Management System, it has become a necessity to provide an XML based standardized interfaces to network elements. The provision for XML interfaces puts an additional criteria of having additional tools for parsing XML documents. Also, tool support should be available to for the SOAP, a lightweight protocol used for exchanging the structured information in XML world.

There are many popular open source/GPL web servers available. Among them, the prominent ones are Apache and GoAhead.

Apache web sever continues to be a product of choice if scalability and full functionality is required. A number of XML based add-on modules are available for Apache web server. On the other hand, the GoAhead web server is very attractive for embedded applications, especially due to its small footprint.

Mbedthis, Allegro and many other vendors have offerings that may suit specific reqirements.

XML Interface

XML has emerged as a powerful language for encoding and transmitting information over the Internet. XML-encoded data is self-describing. Schemas and DTDs make it possible to constrain the data. A large number of tools are available for free download, making it very much affordable to provide XML processing capability in applications and devices. Being a very generic technology, it is also easy to find developers experienced in the technlogy. Due to these reasons XML has already been adopted in the networking industry.

Juniper provided XML based configuration almost 4 years ago. Cisco's new core router CRS-1 has an elaborate XML API. IETF is also working on Netconf, a XML based protocol described more in the next section.

Considering these developments, we believe that XML based API for device configuration will be a strong value-add for any device. It is a little too early to recommend full compliance to Netconf (in terms of SOAP/BEEP, supporting all operations etc), but the architecture should make it easy to support this. Some major issues are discussed below.

Netconf

IETF formed Netconf WG in 2003 to develop a new protocol for uniform, effective configuration of devices. Netconf WG has defined a draft protocol that uses XML for describing and transporting the management data.

Netconf visualizes operations get, edit, copy and delete on the configuration datastores on the device. These operations can be performed on the active (running) configuration or on another configuration. Configuration can be locked and unlocked. A separate get operation is defined to query both configration and state data together. Separation of configuration and state information provides many advantages like minimizing the size of messages, ease of comparison of mutliple configurations.

Edit operation allows modifying the configuration. Netconf allows merging, replacing, creating or deleting of the associated configuration parameters.

Though Netconf does not mandate the use of SOAP, SOAP offers many technical and practical advantages.

A data model is also being developed for Netconf. This aims at making the implementations interoperable, and easing the development of non-trivial applications. This model addresses issues like instance addressing and access control.

At this point, Netconf standards are in the draft stage at IETF.

Coming to the support of this techology on a device, parsing of the XML messages can be handled by 3rd party tools that integrate with the web server. But the back-end API should provide appropriate hooks. Otherwise, it will require lot more development effort and result in inelegant design later

Some key facilities needed in the backend are,

DMTF CIM

Many leading companies have invested a lot of resources for developing management products. Many standard bodies like NMF (now TMF), IETF and ITU-T have tried to develop standards with an attempt to make networks manageable. The goal has been to achieve automated control of the resources. IBM, HP and Sun have put forward new visions like autonomic computing and adaptive computing. They envisage the complete IT infrastructure being fully self-managed.

In reality, there has been very limited success in automating the configuration and management of networks. Powerful element management systems are available to manage collections of uniform devices. Network management systems provide good fault and performance reporting capabilities. But automatic configuration/reconfiguration of a network of heterogeneous devices has been an elusive goal. Major reason has been the complexity of modeling devices in a uniform way. Thus each platform or tool maintains network information in its own format, and is not able to share it in a meaningful way with other tools.

At this point, DMTF's Common Information Model (CIM) is emerging as a promising model to represent all aspects of a network. CIM is a language and a collection of schema to represent devices, networks, applications and policies. Core and common schema are defined by DMTF and these are extended to represent specific resources.

Cisco has been actively working with DMTF. CiscoWorks can now export/import network information as per the CIM model. New CIM to XML mappings will make the model more accessible.

With this background, we believe that vendors should provide Netconf and SNMP interfaces on their devices, supporting all relevant standard MIBs/ XML schemata [5]. We believe that the vendor should utilize the modeling work already done in DMTF while developing the data model for the "proprietary" part the device. Core, value-added functionality of the device can be modeled using CIM's device, network or physical schema. The model can be represented in MoF, XML or SMI based on the requirements.

References

 

Copyright © 2010 Calsoft Labs Incorporated

• Terms Of Use
• Privacy policy
• Sitemap