TOPICS IN INTERNET TECHNOLOGY

On the Future of
Internet Management Technologies
Jürgen Schönwälder, International University Bremen
Aiko Pras, University of Twente
Jean-Philippe Martin-Flatin, CERN

ABSTRACT normalized into a set of interrelated conceptual

MIB tables. It does not currently support con-
As the Internet continues to grow, it becomes cepts such as structured data types, objects, or
more and more apparent that existing Internet methods.
management technologies need to be improved, Although SNMP technology is now well
extended or replaced in order to extend func- understood and widely deployed, it is still con-
tionality and reduce development time and oper- fined to network devices and rarely used for
ational costs. Within the IETF, IRTF, and IAB, managing systems (PCs, servers) or applications.
several new approaches are currently under dis- Even within network element management,
cussion. Evolutionary approaches aim at improv- there are several functional areas where SNMP
ing currently used technologies, whereas has played only a minor role so far (e.g., config-
revolutionary approaches try to replace existing uration management).
management-specific technologies with standard Since SNMP technology is primarily used in a
distributed systems technologies. This article sur- small number of management areas, it is not sur-
veys the research and development work under prising that a number of alternative technologies
way to develop future Internet management have been proposed recently. This article surveys
technologies. these proposals and presents the results of relat-
ed discussions that took place within the Inter-
INTRODUCTION net Engineering Task Force (IETF), Internet
Research Task Force (IRTF), and Internet
The standard management framework currently Architecture Board (IAB).
used in the Internet is named after its main The rest of this article is organized as follows.
building block: the Simple Network Manage- We start by presenting the mismatch between
ment Protocol (SNMP) [1]. It was devised in the requirements of Internet network operators
the late 1980s and is widely supported by net- and the way SNMP has evolved since its incep-
work devices. SNMP is a special-purpose man- tion. Next, we describe evolutionary approaches
agement protocol that can be used to read and to improve the SNMP framework. Last, we
write simple typed variables. The software com- review more revolutionary approaches based on
ponent that handles the associated Get/Set Extensible Markup Language (XML) and Web
requests and accesses the internal data struc- services.
tures on managed devices is called an agent. In
addition to processing such requests, an agent
can also generate notifications under certain
MANAGEMENT BACKGROUND
circumstances and send them as unsolicited Some background information is necessary to
messages to the management application (man- understand and assess the relative merits of dif-
ager). This architecture is known as the manag- ferent proposals for new or enhanced manage-
er-agent paradigm. ment technologies. First of all, the requirements
Concrete data models for managing specific expressed by Internet network operators must be
technologies or protocols are defined and stan- understood by protocol developers and applica-
dardized in management information base tion implementors. A number of nonfunctional
(MIB) modules, which are written in a language aspects also have an impact on the selection of
called Structure of Management Information network management technologies. The main
(SMI) [2]. SMI is a data-oriented language based nonfunctional aspect is the environment in which
on Abstract Syntax Notation 1 (ASN.1). It management takes place. Other key aspects
requires that complex nested data structures be include market and standardization.

90 0163-6804/03/$17.00 © 2003 IEEE IEEE Communications Magazine • October 2003

 REQUIREMENTS OF
INTERNET NETWORK OPERATORS Policy management Service management
systems systems
The Operations and Management Area of
the IETF organized several meetings in 2001 to
identify and outline a set of requirements for Network Network
Network-wide
Internet network operators in order for manage- topology configuration status and
ment protocol and application developers to bet- information database performance
ter meet their needs. In June 2002 the IAB information
organized a workshop on the configuration
aspects of network management [3].
During these meetings, it became clear that, Configuration data
from the operators’ standpoint, configuration translator
management is the most important problem to
be addressed to date. Operators of large back-
bone networks maintain their network-wide con-

configuration

configuration

configuration

configuration

configuration
figuration data in a logically centralized
database, as depicted in Fig. 1 [4]. Change

Device

Device

Device

Device

Device
requests leading to configuration changes in net-
work devices (e.g., new routing policies) trigger
transactions on the logically centralized database.
Once a new network-wide configuration has
been established in the database, complete con-
figuration files or incremental configuration ■ Figure 1. A configuration management model.
updates for specific network devices are first
generated by a configuration data translator, MANAGEMENT ENVIRONMENT
then distributed to all devices, and finally acti-
vated. It is not unusual for Internet network The SNMP framework was designed to:
operators to write these translators themselves. • Minimize the number and complexity of
Due to a lack of well established standards, net- management functions realized by the
work operators have to update their translators agents
when new network devices are released, or when • Be extensible to accommodate additional
new firmware needs to be installed in already and unanticipated aspects of network oper-
deployed devices. ation and management
The requirements of the Internet network • Be as much as possible independent of the
operators can be summarized as follows: implementation of particular hosts or gate-
• It is crucial to make a clear distinction ways [5]
between configuration data (which is rather As a result, the main strengths of SNMP are its
static) and data that describes operational simplicity, interoperability, and low footprint on
state (which is dynamic by nature). agents [6].
• There must be basic operations to download SNMP must also work effectively when the
and upload complete configuration files. It network is not fully operational. This reflects in
is desirable to be able to download or the selection of a connectionless transport proto-
upload only parts of the configuration data. col (UDP), which allows management applica-
• The configuration data should be in a textu- tions to exercise full control over the
al format to allow the usage of a wide range retransmission strategy.
of text-processing tools (e.g., the UNIX Another design choice was to keep SNMP as
command diff) and version management independent as possible of other network ser-
systems. vices. This is one of the main reasons why, in
• It is necessary to distinguish between the SNMP version 3 (SNMPv3), security is self-con-
distribution of configurations and the acti- tained and does not rely on other external secu-
vation of a certain configuration. Devices rity services such as key exchange or certification
should be able to hold multiple configura- services.
tions and enable management applications But the environment in which management
to activate any of them (only one configura- operations take place has dramatically changed
tion is active at a time). since SNMP was devised. Looking at today’s net-
• The coordinated activation of configura- work technologies and the actual usage patterns
tions could be dramatically simplified by of SNMP, it is obvious that devices could per-
having a transaction mechanism for upload- form more complex management operations at
ing new configurations and activating them low cost. It is reasonable to expect that devices,
“simultaneously” on multiple devices. Such especially high-end routers and switches, will
a transaction mechanism must take into become increasingly programmable, and that it
account that connectivity might be lost in will become possible to execute more control
the middle of the transaction. software directly on the devices.
• Finally, ease of use of the management Furthermore, as described by Wellens and
technology is of paramount importance. Auerbach [7], SNMP need not use UDP. When
Configuration management interfaces must network connectivity is lost, non-SNMP mecha-
be designed such that developing and nisms are usually used to bring back connectivity
debugging configuration data translators is before management operations can resume.
cost effective. Finally, SNMP was standardized at a time

IEEE Communications Magazine • October 2003 91

 when it was customary for the IETF to invent an the years, the software engineering market has
From the network ad hoc protocol each time a new problem had to learned that implementation and education
be solved. As we will see, this resulted in a lack costs can be reduced significantly by using
operators’ of skilled developers for writing increasingly domain-independent technologies rather than
complex management applications. Since the domain-specific ones. Management applica-
standpoint,
late 1980s the environment has changed, and the tions are no exception to this rule. The number
configuration goal is now to reuse standard technologies wher- of highly experienced SNMP developers is
ever possible. rather small, notably because students and
management is employees are more interested in learning
the most MARKET ASPECTS generic protocols than SNMP. One outcome of
Independent of any technical considerations, this lack of skills is that many of the tools
important several market aspects must also be considered available to date for implementing manage-
when evaluating proposals for future Internet ment applications are rather primitive. To
problem to be
management technologies [6]. overcome this issue, general-purpose technolo-
addressed to date. The first aspect is branding. SNMP has a bad gies should be adopted for management wher-
reputation among network administrators and ever possible. They reduce both development
Internet network operators. Even though it is and training costs, and increase the chances of
still widely used for monitoring network devices, having smart people develop smart manage-
many people associate SNMP with the terms ment applications.
insecure, cryptic, complex, slow, and limited func-
tionality; whether these terms are technically jus- STANDARDIZATION ASPECTS
tified or not is irrelevant to them. In addition to technical and market issues, one
A second aspect is market control and pro- should also take standardization issues into con-
tection. It is normal for companies to try to sideration when evaluating new Internet man-
secure lucrative niche markets. This is true of agement technologies. The first observation is
the management technologies market as well. that standardization efforts at the IETF often
Some companies contribute to standards mostly take too much time. The short cycles of the late
to keep control over key technologies and their 1980s have been replaced by long (and some-
associated markets. Others prefer to use propri- times hard) negotiations between vendors. For
etary management interfaces in order to lock in management interfaces, it is crucial to have a
their customers. good timing. If reasonable specifications are
The third aspect is that there does not seem available early enough, there is a good chance
to be a sustainable market for open manage- that vendors will adopt and implement them.
ment. When SNMP was created, one of the orig- Conversely, standards that are published after
inal ideas was that open network management vendors have implemented and fielded their own
standards would create a competitive market, proprietary solutions are unlikely to be adopted
which would lead to improved management — there is generally no business case for sup-
applications. After more than a decade of field porting multiple interfaces.
experience with SNMP, we must acknowledge A second aspect is data modeling. Manage-
that this model does not seem to work very well. ment data models need continued mainte-
We have a reasonable market for low-end, rea- nance as the underlying technology evolves.
sonably open management applications whose Although SMI has clear rules on how to evolve
main components are MIB browsers and data definitions while retaining interoperability
collectors. But systems management and applica- with deployed implementations, we see little
tion management are still to a large extent pro- interest in the IETF Working Groups (WGs)
prietary, and the number of management to update existing MIB module definitions.
applications that are able to manage complex Network device vendors are also relatively
networks rather than individual devices is quite slow in implementing updated definitions in
limited. real products, because the marketing impact of
The fourth aspect has to do with purchase announcing support for a new version of an
decisions. Management capabilities usually have MIB is very small.
little influence on decisions to buy a device: the Some of the IETF rules to progress standards
main criteria are technological features and also impact the clarity of data models. In some
price. Very few businesses are able to compute cases, related definitions are spread across sever-
the total cost of ownership (TCO) of a piece of al MIB modules just to be able to pass existing
equipment. As a result, most people prefer to modules unchanged along the standards process.
save money during the purchase phase, even if A good example is the IF-INVERTED-STACK-
they have to spend much more during the opera- MIB, which contains a table that semantically
tional phase due to missing, incompatible, or belongs in the IF-MIB. The main outcome of
nonstandard management interfaces. splitting modules to cope with the IETF stan-
The fifth aspect has to do with developers’ dard process rules is confusion. It is easy for
skills. Because management often comes second people outside the IETF to miss a fragment of
to technological features, the employees related definitions.
assigned by equipment vendors to develop man- Last, design by committee rarely works well.
agement instrumentation are often inexperi- The understandable attempt to accommodate
enced. After a few years, they quickly move to every preference or resource constraint usually
more attractive functions. It is therefore difficult leads to data models that are difficult to under-
for a vendor to grow in-house expertise in Inter- stand, relatively vague in some areas, and not
net management. easy to use for developing robust and interoper-
The last aspect has to do with reuse. Over able management applications.

92 IEEE Communications Magazine • October 2003

 EVOLUTION OF THE class BasicInOutErrStats {
SNMP FRAMEWORK attribute inOctets { type Counter32; ... }; The IRTF Network
attribute inErrors { type Counter32; ... };
Management
attribute outOctets { type Counter32; ... };
One approach to solve these problems and meet attribute outErrors { type Counter32; ... }; Research Group
the above mentioned requirements is to gradual- ...
ly improve the existing Internet management }; has developed a
framework. class Interface {
new data
attribute index { type InterfaceIndex; ... };
EVOLUTION OF THE attribute stats { type BasicInOutErrStats; definition
DATA DEFINITION LANGUAGE ... };
... language called
The IRTF Network Management Research };
SMIng.
Group (NMRG) has developed a next-genera- snmp {
tion data definition language called SMIng [8]. table ifTable {
SMIng improves the expressive power of the oid interfaces.2;
current SMI language by introducing arbitrarily index (ifIndex);
nested data structures. It facilitates reusability of object ifIndex { implements
complex structured types in order to achieve Interface.index; ... };
more commonality in MIB module designs. It object ifInOctets { implements
also provides a language extensibility mechanism Interface.stats.inOctets; ... };
to allow for incremental language enhancements. object ifInErrors { implements
The SMIng development was driven by the Interface.stats.inErrors; ... };
goal to stop the proliferation of different data object ifOutOctets { implements
Interface.stats.outOctets; ... };
modeling languages within the IETF and to har-
object ifOutErrors { implements
monize management models at a higher concep-
Interface.stats.outErrors; ... };
tual level. SMIng therefore separates
...
management protocol-independent data type };
definitions from the protocol-specific mappings. ...
The example in the upper half of Fig. 2 shows };
how a reusable data structure for physical or log-
ical network interfaces can be defined in the ■ Figure 2. SMIng definition of an interface and
SMIng language. The class Basic- the mapping to SNMP.
InOutErrStats defines a collection of counters
for basic traffic statistics. (We ignore here the
fact that 32 bits might not be sufficient for high- EVOLUTION OF THE
speed traffic streams). The class Interface has SNMP PROTOCOL OPERATIONS
an index attribute and a statistics attribute hold-
ing basic traffic statistics for an interface. The The IETF Evolution Of SNMP (EOS) WG was
bottom half of Fig. 2 shows an SNMP protocol chartered in February 2001 to work on new
mapping. The columns of the ifTable are SNMP protocol operations that basically improve
explicitly listed in the object statements. Several the efficiency of bulk data retrievals [10]. Several
SNMP objects are needed to represent the options have been investigated.
stats attribute, which has a composite type. In The first option uses compression mecha-
general, attributes that are defined using other nisms that reduce the noticeable overhead
SMIng classes are “flattened out” in the SNMP caused by redundant object identifier (OID)
protocol mapping, following the structure of the fragments in SNMP protocol data units (PDUs).
underlying composite type. The variants of this option differ in how much
In November 2000 the SMIng effort was computation is needed and how much compres-
moved from the IRTF to the IETF. An IETF sion is achieved. One of them, OID delta com-
Working Group (WG) called SMIng was char- pression [8], is a relatively lightweight algorithm
tered to develop a standards track specification that achieves good compression ratios on tables
for the next-generation data definition language, with simple and complex indexing schemes. The
starting from the NMRG proposal. The SMIng advantage of the compression proposals is that
WG, in the first phase, documented the objec- compression can be applied to existing SNMP
tives for a new data definition language [9]. In PDUs, which requires minimal changes to exist-
the second phase, proposals to meet the objec- ing protocol operations.
tives were requested, and after some discussion The second option leverages suppression
two strong proposals remained in the list of can- mechanisms where common OID fragments are
didates. One of them was the SMIng language suppressed. This works by introducing new pro-
developed by the NMRG. An attempt to merge tocol operations that operate on complex data
the two competing proposals into what would structures rather than primitive lists of named
have become SMIv3 failed, primarily because no variables. The various proposals for achieving
consensus could be reached on the syntax of the this differ in the data selection and filtering
SMIv3 language and, more important, how much mechanisms supported.
the SNMP naming system should be changed to The third option is based on new MIB mod-
identify nested data types on the wire. The ules that facilitate bulk data transfers at the MIB
SMIng WG was finally shut down in April 2003 level rather than the protocol level. These
without producing a standards track specifica- approaches have lost support because there are
tion. serious implications with regard to security and

IEEE Communications Magazine • October 2003 93

 (DMTF), who developed the Web-Based Enter-
prise Management (WBEM) architecture and its
CLI

Instrumentation
Management main building block, the Common Information
Rendering daemon
Model (CIM). CIM schemas define management
information for users, applications, networks,
XML systems, events, policies, and so on. They are
XML parser
defined in a language called Managed Object
Format (MOF) and can be viewed in the form
of UML class diagrams. To transfer manage-
ment information over the wire, WBEM uses
■ Figure 3. The structure of the agent's implementation. XML encoding.
Despite the fact that a number of vendors
have been working on XML-based management
access control — especially if other protocols for several years, the traditional Internet man-
such as FTP or HTTP are used for the actual agement community (IAB and IETF) has
bulk data transfers. ignored it for a long time. Activities in this area
The first two options generally benefit from were limited to those of the NMRG, where a
larger PDU sizes. The default SNMP over UDP mapping from SNMP MIB modules into XML
transport only guarantees the transport of SNMP Document Type Definitions (DTDs) was defined
messages of a size up to 484 bytes, which is too [8] and an XML-based management application
small for bulk data transfers over most layer 2 prototyped [6].
technologies. The NMRG therefore defined a The situation has changed, however. At the
transport mapping for SNMP over TCP to allow June 2002 IAB workshop, one of the interesting
for larger SNMP messages with a minimum conclusions was the unanimous support to inves-
guaranteed message size of 8192 bytes [11]. tigate XML-based network management. At the
As in the SMIng case, the EOS WG could 54th IETF meeting in Yokohama, Japan, there
not reach consensus on the proposals and was was also a well-attended Birds of a Feather
closed down in April 2003. (BOF) meeting to discuss the use of XML in
configuration management. As a result of this
COPS-PR AND SPPI interest, a new WG called Network Configura-
The IETF Resource Allocation Protocol (RAP) tion (NetConf) was formed in May 2003.
WG defined the Common Open Policy Services Independent of standardization, some ven-
Protocol — Policy Provisioning (COPS-PR) pro- dors already support XML-based management
tocol [12] and its associated data definition lan- in their routers.
guage, the Structure of Policy Provisioning
Information (SPPI) [13]. COPS-PR was designed JUNOSCRIPT
to provision complex and continuously changing In January 2001, Juniper introduced its JUNO-
device configurations generated from policy- Script application programming interface (API)
based management systems. for the JUNOS network operating system [14].
The design of COPS-PR addresses well-known This API gives management applications full
issues in SNMP. In particular, COPS-PR uses access to the agent’s management data using a
TCP as its transport, which makes it possible to lightweight remote procedure call (RPC) mecha-
support large message sizes and use transport- nism encoded in XML. As opposed to SNMP,
layer security mechanisms. COPS-PR also assumes JUNOScript uses a connection-oriented trans-
that only one entity can have exclusive control for port mechanism (e.g., ssh or telnet). A major
a given subject category on a device. This assump- advantage of this approach is that related man-
tion makes it easier to share state between man- agement interactions can be grouped into ses-
agers and agents, and thus reduces complexity. sions, which makes locking and recovery
The SPPI language is a variant of SMI adapt- relatively simple. In addition, management infor-
ed to COPS-PR. It does not support SMIng fea- mation is no longer limited in size and can be
tures such as complex nested data types. In fact, exchanged reliably.
the release of SPPI was one of the motivations Figure 3 shows the internal management
to develop a protocol-neutral data definition lan- structure of a Juniper router. It is interesting to
guage within the NMRG. note that the Command Line Interface (CLI)
So far, COPS-PR and SPPI have failed to and XML interface rely on the same pieces of
gain significant market acceptance. One reason software. The main difference between the two
is that Internet network operators are concerned is that an additional rendering component is
about the increased complexity and maintenance needed for the CLI to translate between the
costs associated with yet another management human-readable CLI interface and the more ver-
technology, which only partially fulfills their bose XML-based messages. It is possible to
requirements. Another reason is that these pro- switch rendering off with a single command,
tocols only provide minor improvements over which may be useful for debugging purposes.
SNMP, which could easily be integrated into the Although there are many XML parsers on the
SNMP framework. market today, Juniper decided to implement
their own parser for performance reasons. This
parser understands only a subset of XML.
XML-BASED APPROACHES Interactions between a manager and an agent
XML-based management has been around for are based on XML messages, which can be
several years now. One of the pioneers in this regarded as RPCs. Although several XML-based
area is the Distributed Management Task Force RPC standards already exist (e.g., XML-RPC),

94 IEEE Communications Magazine • October 2003

Juniper considered these standards too complex
<rpc>
and decided to use their own encoding. The
<get-interface-information>
Juniper encoding is indeed quite simple. Figure
<statistics/>
4 shows an example of an RPC call performed </get-interface-information>
by a manager to get statistics about an interface </rpc>
of a device. The call is embedded within rpc
start and end tags. After the start tag come one <rpc-reply>
or more methods; in this example there is just a <interface-information>
single get-interface-information method. <InOctets>123456</InOctets>
Each method may have a number of arguments; <InErrors>789</InErrors>
in this example there is only one: statistics. <OutOctets>654321</OutOctets>
The reply to the RPC call looks quite similar <OutErrors>0</OutErrors>
and includes the requested statistics (InOctets, </interface-information>
InErrors, OutOctets, and OutErrors). The </rpc-reply>
manager can analyze this response by using
XPath. This makes it possible to find specific ■ Figure 4. An example of an XML-encoded
information (e.g., to identify the interfaces for RPC call.
which the number of errors exceeds a certain
threshold). The response can be translated by
using Extensible Stylesheet Language Transfor- Description Language (WSDL, pronounced wis-
mations (XSLT), or formatted using Cascading dle), which is used to define the actual Web ser-
Style Sheets (CSS). vices. WSDL files include the operations
supported by a particular service, the parameters
of these operations, the type of the returned
WEB SERVICES FOR MANAGEMENT value, the protocol binding (usually SOAP), and
Outside the traditional Internet management the location of the service (expressed in the form
community, a number of technologies are being of a Uniform Resource Identifier, URI).
developed that may become important for Inter- In the example given in Fig. 6, two messages
net management. Web services are perhaps the are defined: Statistics and StatisticsRe-
most interesting of all. sult. The first message does not contain any
This technology is being standardized by the parameters. As in the example presented in Fig.
World Wide Web Consortium (W3C). It promis- 4, the second message contains four integer
es to provide a single uniform software infra- parameters: InOctets, InErrors, OutOctets,
structure to support a wide range of distributed and OutErrors. Additionally, the WSDL file
services, thereby reducing training and software includes a section that assigns a name (Inter-
development costs. According to some, the real faceInfoService) to this service, the mapping
power of Web services is that they are expected onto the underlying protocol, and the URI of
to become standard components of future oper- the service. Note that several lines have been
ating systems. As such, Web services may omitted in Fig. 6 for the sake of readability. Just
become easy to use and integrated within com- like SOAP, WSDL uses XML for encoding.
mon office applications such as spreadsheets and Note that a companion standard, Universal
databases. Description, Discovery, and Integration (UDDI),
Although Web services have not been specifi- is often considered a building block of Web ser-
cally designed for management purposes, people vices, although it is defined by a vendor consor-
may find them attractive to develop manage- tium called OASIS and not formally endorsed by
ment applications. Spreadsheets, for example, the W3C. UDDI is supposed to be useful for
may be used to retrieve usage figures from the discovering WSDL files.
network and inform the administrator if certain As mentioned already, Internet management
usage figures exceed certain thresholds. Databas- is traditionally based on the manager-agent
es may be used to periodically retrieve usage paradigm. In this approach, the manager sends
statistics and plot them over time. Web services Get and Set commands to the agent, and
could also facilitate the integration of network, receives responses from the agent. With Web
application, and systems management by offer- services we have three different possibilities.
ing a unified communication model [6]. If we do a straightforward mapping, the agent
Despite all the recent marketing announce- runs an HTTP server, the manager runs an
ments, it should be noted that Web services are HTTP client, and the manager performs Get
still very much under development. This technol-
ogy is not yet mature, and its applicability in the
area of Internet management is still an object of
research. WDSL
Web services consist of several building
blocks built on top of XML (Fig. 5). The first
one is the Simple Object Access Protocol
(SOAP). SOAP is fundamentally a stateless one- SOAP XML-RPC
way message exchange mechanism that uses
XML for encoding. SOAP messages can be
exchanged over different underlying transfer HTTP SMTP BEEP
protocols (e.g., HTTP and SMTP). Most people
currently envision using SOAP over HTTP/1.1.
The second standard is the Web Services ■ Figure 5. Web services: a layered view.

IEEE Communications Magazine • October 2003 95

 als from IBM (Web Services Flow Language)
<definitions name=”InterfaceInformation”
Although Web and Microsoft (XLANG).
...
Although many general-purpose Web services
services have not technologies are already available, it is important
<message name=”Statistics”>
to standardize specific Web services for network
been specifically </message>
management. These standards could take the
designed for <message name=”StatisticsResult”> form of XML schemas or WSDL files. An impor-
<part name=”InOctets” tant decision to be made is the level at which
management these standards should operate. Two extreme
element=”xsd:unsignedInt”/>
purposes, people <part name=”InErrors” ... approaches are possible:
<part name=”OutOctets” ... •The WSDL files define just a set of basic
may find them <part name=”OutErrors” ... operations, such as Get and Set. In this
</message> approach, parameters are passed as opaque
attractive to
types, which means the WSDL file does not
develop <service name=”InterfaceInfoService”> specify or interpret the types of the various MIB
<port ... object values. It is possible, however, to define
management {mapping on underlying protocol} these types in a higher-level XML schema.
{URI of web service} •The WSDL files define separate messages
applications.
</port> for each MIB object. Examples of such messages
</service> are GetIfInOctets and ChangeIfOpera-
tionalStatus. A parameter that belongs to
</definitions> both messages could be ifIndex. In this
approach, WSDL files specify all the details that
■ Figure 6. An example of a WSDL file. are necessary to manage a device. There is no
need to define a higher-level XML schema. In
fact, these WSDL files include the same kind of
and Set RPCs via SOAP. Polling is implement- details as current MIB modules.
ed by invoking Get on the same attribute on a Since the second approach requires no addi-
regular basis. tional XML schema, it would be relatively easy
Web services also support publish-subscribe. to use the resulting Web services from standard
In this case, a manager may express its interest applications, like spreadsheets and databases. A
in certain attributes published by an agent in a risk, however, is that performance may be
WSDL registry. The agent then sends the data adversely affected in case such applications rely
to a message queue, and the manager receives for their type checking on generic parsers that
these events from that message queue. support all XML features.
Last, Web services enable managers to invoke The NMRG and the OASIS Management
advanced operations on agents. These opera- Protocol Technical Committee have just begun
tions may perform statistical computations, investigating the use of Web services for Internet
update a routing table, perform load balancing, management. The Parlay Group has recently
and so on. translated its open service provisioning APIs into
In any case, the capabilities of the agent WSDL definitions. Unfortunately, these defini-
can be described in a WSDL file, which tions are still difficult to use, since they require
enables a manager to discover them at runtime detailed knowledge of intelligent networks. Par-
(e.g., by retrieving them from a central UDDI lay-X took another approach and defined easy-
registry implemented as a relational database). to-use Web services for open service
For performance reasons, it may be necessary provisioning. Examples of such services include
for the manager to locally cache the WSDL “connect A to B,” “give status of X (on/off),”
files of all the agents in its management “send SMS,” and “recharge prepaid card.” Par-
domain (which poses the problem of when to allel to standards groups and vendor consortia,
update them). many research projects are also investigating the
In addition to this typical request-response use of Web services for Internet management
interaction pattern, agents should also be able to (e.g., the Dutch Freeband WASP project). Fur-
send notifications to the manager. With a ther research is needed, for example, in the
straightforward mapping, the manager should areas of object naming and performance.
thus also implement an HTTP server, and the
agent an HTTP client. With publish-subscribe,
notifications are sent via the same message
CONCLUSIONS
queue mechanism as subscribed data. SNMP has been around for almost 15 years now.
As opposed to SNMP, which operates over Although it is widely used for monitoring net-
UDP, Web services can operate over TCP, which work devices, it has not been very successful for
means the maximum size of requests, responses, performing other important management func-
and notifications is no longer an issue. tions such as configuration management. To dis-
As mentioned earlier, an important problem cuss the situation, the IETF, IRTF and IAB
for network operators is configuration manage- organized various meetings in which they pro-
ment of multiple devices. This form of manage- posed future directions for Internet manage-
ment requires support for atomic transactions. A ment. This article presents the main outcome of
relatively new technology that may be useful for these meetings and gave an overview of the
this purpose is the Business Process Execution approaches that were investigated. These
Language for Web Services (BPEL4WS [15]), approaches fall into two categories: evolutionary
which seems likely to supersede previous propos- and revolutionary. Evolutionary approaches were

96 IEEE Communications Magazine • October 2003

taken by three IETF Working Groups: SMIng, [2] K. McCloghrie et al., “Structure of Management Infor-
mation Version 2 (SMIv2),” RFC 2578, Apr. 1999.
EOS, and RAP. The goal of the SMIng WG was [3] J. Schönwälder, “Overview of the 2002 IAB Network Currently, most
to produce an improved version of the SMI data Management Workshop,” RFC 3535, May 2003.
definition language; the goal of the EOS WG [4] L. Sanchez, K. McCloghrie, and J. Saperia, “Require- activities in
was to produce new SNMP protocol operations ments for Configuration Management of IP-Based Net-
works,” RFC 3139, June 2001 Internet
for efficient bulk data retrievals. Both groups [5] J. Case et al., “A Simple Network Management Protocol
leveraged previous work by the IRTF-NMRG. (SNMP),” RFC 1157, May 1990. management
In addition, the RAP WG defined SPPI and [6] J.P. Martin-Flatin, Web-Based Management of IP Net-
COPS-PR, which enable the provisioning of net- works and Systems, Wiley, 2002. center around
[7] C. Wellens and K. Auerbach, “Towards Useful Manage-
work devices with policy-based configuration ment,” The Simple Times, vol. 4, no. 3, July 1996. XML-based
data. [8] Internet drafts produced by the IRTF NMRG: http://
So far, the evolutionary approaches have www.ibr.cs.tu-bs.de/projects/nmrg/. approaches.
failed or had limited market acceptance. The [9] C. Elliot et al., “SMIng Objectives,” RFC 3216, Dec. 2001.
[10] R. Sprenkels and J. P. Martin-Flatin, “Bulk Transfer of Several vendors
IETF accepted this failure recently. In early MIB Data,” The Simple Times, vol. 7 no. 1, Mar. 1999.
2003, it relaxed its requirement that new MIB [11] J. Schönwälder, “Simple Network Management Proto- already ship
modules should also contain writable objects. col (SNMP) over Transmission Control Protocol (TCP)
The IETF still encourages the development of Transport Mapping,” RFC 3430, Dec. 2002 products that
[12] K. Chan et al., “COPS Usage for Policy Provisioning
read-only MIB modules, however. (COPS-PR),” RFC 3084, Mar. 2001. offer easy-to-use
Also, various participants of the June 2002 [13] K. McCloghrie et al., “Structure of Policy Provisioning
IAB workshop expected failure of the evolu- Information (SPPI),” RFC 3159, Aug. 2001. XML-based
tionary approaches; it is therefore not surpris- [14] P. Shafer, “XML-Based Network Management, White
paper, Juniper Networks, Aug. 2001. Available at interfaces for
ing that an important outcome of the workshop http://www.juniper.net/techcenter/techpapers/200017.h
was to focus more on revolutionary approaches. tml. configuration
Currently, most activities in Internet manage- [15] F. Curbera et al., “Business Process Execution Lan-
ment center around XML-based approaches. guage for Web Services,” v. 1.0, July 2002; http://www. management; to
ibm.com/developerworks/library/ws-bpel/.
Several vendors already ship products that offer standardize such
easy-to-use XML-based interfaces for configu-
ration management; to standardize such inter- BIOGRAPHIES interfaces, a new
faces, a new IETF WG (NetConf) was recently JÜRGEN SCHÖNWÄLDER [M] (j.schoenwaelder@iu-bremen.de) IETF Working
created. is associate professor of computer science at International
Web services also seem to be a promising University Bremen, Germany. He received his diploma in Group (NetConf)
computer science in 1990 and his doctoral degree in 1996
technology. Research in this area has just begun; from Technical University Braunschweig, Germany. His
further work is needed to investigate its merits was recently
research interests are network management, distributed
in Internet management. systems, and network security. He is an active member of created.
the IETF and chair of the NMRG of the IRTF.
ACKNOWLEDGMENTS
AIKO PRAS (pras@cs.utwente.nl) is a senior researcher at the
Many ideas presented in this article were dis- Telematics Architecture Group of the University of Twente
cussed at the June 2002 IAB workshop on net- (UT), the Netherlands. From this university, he received in
work management and at various meetings of 1995 a Ph.D. degree in network management architec-
tures. His research interests include Web services, network
the IRTF Network Management Research measurements, and accounting. He participates within the
Group. We would like to thank the participants WASP and M2C research projects, and is a member of the
of these meetings for their contributions, espe- IRTF NMRG.
cially Phil Shafer and Bert Wijnen.
JEAN-PHILIPPE MARTIN-FLATIN [SM] (jp.martin-flatin@ieee.org)
Part of this research was sponsored by the is technical manager of the European DataTAG project
Telematica Instituut (TI) in the Netherlands. (http://www.datatag.org) at CERN. He coordinates research
activities in networking and middleware for data-intensive
REFERENCES transoceanic Grids. Prior to that he wrote a book on Web-
based management and was a principal MTS with AT&T
[1] D. Harrington, R. Presuhn, and B. Wijnen, “An Architec- Laboratories Research, Florham Park, New Jersey. He holds
ture for Describing Simple Network Management Pro- a Ph.D. degree in computer science from EPFL, Switzerland.
tocol (SNMP) Management Frameworks,” RFC 3411, He is a co-chair of the GGF Data Transport Research Group
Dec. 2002. and a member of the IRTF NMRG.

IEEE Communications Magazine • October 2003 97