Network Working Group J. Schoenwaelder
Internet-Draft University of Osnabrueck
Expires: November 30, 2002 Jun 2002
On the Future of Internet Network Management Standards
draft-schoenw-iab-nm-ws-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 30, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
There have been ongoing debates during the past few years on the
direction for the evolution of various Internet management
technologies and standards such as SNMP, COPS, PCIM. This memo has
been written in preparation of the IAB network management workshop to
be help in June 2002. It documents some of the author's views and
visions and as such it does not even try to be objective.
Schoenwaelder Expires November 30, 2002 [Page 1]
Internet-Draft Future of Internet Network Management Standards Jun 2002
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. General Aspects . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Aspects . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 COPS-PR . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 CIM/PCIM . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Industrial Aspects . . . . . . . . . . . . . . . . . . . . . . 6
5. Standardization Aspects . . . . . . . . . . . . . . . . . . . 7
6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8
References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10
Schoenwaelder Expires November 30, 2002 [Page 2]
Internet-Draft Future of Internet Network Management Standards Jun 2002
1. Introduction
There is always a need to manage networks. However, the specific
management tasks change over time as the underlying networking
technologies evolve. As a consequence, the technologies used to
manage networks have to adapt to new requirements.
There have been several more or less competing proposals within the
IETF in recent years on how to evolve or complement the original
Internet management framework defined in the late 1980s, ranging from
evolutions of the SNMP technologies (EOS, SMIng, SNMPconf) over the
addition of new provisioning technologies (COPS-PR) to policy-based
management technologies (PCIM).
This memo looks at the current situation from four different
viewpoints:
1. General Aspects
2. Protocol Aspects
3. Industry Aspects
4. Standardization Aspects
The author believes that it is necessary to discuss all these aspects
and understand the interrelationships in order to develop a sound
vision for the future of the Internet management technologies.
1.1 Terminology
This section introduces some terminology as it is being used in this
memo.
Monitoring: Activities to collect status data or statistics.
Configuration: Activities which establish the long-term core
configuration of network devices.
Control: Activities to change parameters which influence the
behaviour of network devices. (This is sometimes also called
short-term configuration.)
Alarming: Determination and reporting of problematic situations
(alarms) in the network.
Schoenwaelder Expires November 30, 2002 [Page 3]
Internet-Draft Future of Internet Network Management Standards Jun 2002
2. General Aspects
It is important to understand which technologies are being managed,
which technologies can be used for management and what the overall
context is in which Internet management takes place.
o Today's network devices can perform rather complex management
operations at reasonable costs. In general, it can be expected
that devices get more and more programmable and that it will be
possible at some point in time to execute control software
directly on the devices.
o Most of the time when management operations are performed, it is
safe to assume connectivity (also called the myths of the
collapsing network). In case connectivity is lost, other out of
band mechanisms are usually used to bring back connectivity first
before management operations continue.
o It is crucial to reduce the implementation and education costs
involved with management functions. This implies that existing
general purpose technologies should be adopted for management
wherever possible.
3. Protocol Aspects
This section discusses some of the protocols that have been used for
generic network management. There are additional special purpose
protocols for specific problem domains (such as routing protocols)
which perform management functions but will not be discussed here.
3.1 SNMP
SNMP was developed in the late 1980s. SNMPv1 is widely deployed and
heavily used for monitoring, fault isolation and to some extend for
control and alarming. It is not widely used for configuration,
although there are some notable configuration applications for
enterprise networks.
The basic operations supported by SNMP did not change significantly
since the late 1980s, even though the dimension of devices in terms
of available processing power and complexity of networking functions
did chance radically. As such, SNMP suffers from several problems:
o Efficiency: Retrieving bulky data via SNMP is way too slow due to
the lock-step nature of SNMP operations, the lack of reasonable
flow control and pipelining.
Schoenwaelder Expires November 30, 2002 [Page 4]
Internet-Draft Future of Internet Network Management Standards Jun 2002
o Complexity: While the operations supported by SNMP are simple (and
in fact too simple), the complexity of the overall protocol is
rather large. In order to write SNMP agents or management
application, one usually has to invest several months of time.
o Semantic Mismatch: Today's networks require more complex control
and configuration interactions. SNMP's model of simple typed
variables with side-effects requires to break a semantically rich
management operation down into a sequence of micro-management
actions that are performed by a sequence of SNMP interactions. On
the managed element side, these SNMP interactions have to be
analyzed in order to discover what the manager was actually trying
to achieve.
o Data Model: The underlying data model and the language to express
data models has several restrictions (such as no reusable
structured data types). The model of simple typed variables that
can be organized in simple conceptual tables is not adequate to
describe complex systems. The data definition language itself
relies on ASN.1 which is hardly being used in new protocol work
today.
o Organizational Model: The assumption of multiple managers
coordinating their control and configuration activities through
the network devices themself does not work with most existing SNMP
MIBs. There is no general notification mechanism for
configuration changes and there is absolutely no guarantee that
information installed via control or configuration operations
stays unchanged on the devices.
It should be noted that some of the problems listed above are not
relevant for monitoring.
3.2 COPS-PR
COPS-PR was defined to better support the provisioning of control and
configuration information. While COPS-PR was trying to address some
important shortcomings of SNMP, it did not go far enough.
o The SPPI data definition language has only minor improvements.
There are still no reusable structured data types which are needed
to describe complex programmatic interfaces.
o Using TCP as a transport is a reasonable choice as it simplifies
the protocol significantly and allows larger transactions without
worrying about message size constraints.
o The total lack of an access control model is problematic. Having
Schoenwaelder Expires November 30, 2002 [Page 5]
Internet-Draft Future of Internet Network Management Standards Jun 2002
to revert to a different protocol to read data while a COPS-PR
session is alive does not make much sense.
o The efficiency improvements on the wire are a nice side-effect,
although less important in the context of COPS-PR compared to SNMP
where message size constraints are a real issue.
o One can question whether the design choice to use BER encodings in
COPS-PR was pointing into the right direction. It might have been
more appropriate to adopt a simpler encoding. In addition, OID
naming could have been replaced by a more human friendly naming
mechanism.
A more detailed comparison between COPS-PR and SNMP can be found in
[xxx].
3.3 CIM/PCIM
Policies are commonly defined as a set of rules to administer,
manage, and control access to network resources. Policy-based
network management has the advantage of being goal-driven and more
declarative rather than procedural. The Policy Core Information
Model (PCIM) is an extension of the Common Information Model (CIM)
developed by the DMTF.
o CIM and PCIM are frequently used as a starting point by designers
of management applications. It is not uncommon that CIM/PCIM
definitions are copied and modified to meet the specific needs and
then implemented in management applications. As these models are
used internally, there is usually little desire to actually gain
interoperability at the CIM layer.
o The CIM/PCIM specifications follow a strict top-down design
philosophy and thus require concrete extensions to become useful.
Some of them are being worked on in the IETF and the DMTF.
4. Industrial Aspects
There are several industrial aspects to consider when evaluating
management protocols.
o Branding: SNMP has a bad recognition in a large user potential
base of system administrators or network operators. It is
nevertheless used for monitoring by these people, although mainly
because it is the only option to get easily access to the relevant
data. Many people associate with SNMP the terms "insecure",
"cryptic", "complex", "slow" and "limited interoperability".
Schoenwaelder Expires November 30, 2002 [Page 6]
Internet-Draft Future of Internet Network Management Standards Jun 2002
o Market Control and Protection: It is a normal desire of companies
to control and protect their markets. This is also true for
management technologies. Some companies contribute to standards
in order to gain or keep technology control and thus market
control. Other may choose to not contribute to standards
processes in order to protect their markets via protection of
their management interfaces.
o Market Improves Management Applications: Open management
interfaces can create a competitive market where competing
companies provide a stream of improving management applications.
In reality, this model does not seem to work very well. After
more than 12 years of SNMP, we have a reasonable market for MIB
browser kind of applications and data collectors. The number of
real network management applications which are able to manage
networks and to abstract from the MIB specifics is rather limited
(perhaps because it is rather difficult to develop such
applications).
o Market Decisions: Management aspects usually have little influence
on buyment decisions. The main factors are the primary network
functions supported and of course the price. It is not uncommon
that people prefer to save a few bucks when they buy devices even
if they have to spend quite a bit of money in the operational
phase due to missing, incompatible non-standard management
interfaces.
o Skills: Since management functions are not considered to be of
prime importance, it is not uncommon that new employees are tasked
to work on management issues. If they are good, it is likely that
they will change position to work on primary device functions.
5. Standardization Aspects
There are several aspects that are related to the way standards are
being developed in the IETF.
o Standardization efforts generally take too long. For management
interfaces, it is crucial to have a good timing. If reasonable
specifications are available early enough, then there is a good
chance that vendors will adopt and implement them. Standards that
come out after vendors have implemented their own proprietary
solutions are pretty unlikely to be adopted.
o Management data definitions need maintenance. Although the SMI
has clear rules on how to evolve definitions while retaining
interoperability with fielded implementations, we see little
Schoenwaelder Expires November 30, 2002 [Page 7]
Internet-Draft Future of Internet Network Management Standards Jun 2002
interest in the community to update definitions and to adopt
updated definitions in real products.
o Some of the standard process rules impact the clarity of data
models. It is not uncommon that related definitions are spread
across several modules just to be able to pass complete modules
along the standards process. This results in confusion and it is
not unlikely that people outside the IETF fail to reassemble
fragmented related definitions.
o Design by committee does in general not work well. Trying to
accomodate every preference equally well usually leads to data
definitions that are relatively vague and which make it difficult
to write interoperable management implementations.
6. Recommendations
Below is a list of recommendations.
o Reduce the amount of special purpose technology developed for
managing networks.
o It is desirable to integrate the main good improvements of COPS-PR
into SNMP in order to avoid two competing standard-track protocols
addressing almost identical requirements.
o A new mechanism is needed to support long-term configuration. It
should use a declarative document-oriented approach in describing
configurations and configuration templates and distributing them.
XML might be a reasonable infrastructure for such a mechanism.
o The approach of defining formalized universal information models
which can be used to derive high-quality data models for various
protocols is unlikely to work in practice.
o There is a need for separate specific data models for long-term
configuration as well as monitoring and control. These data
models should be aligned by defining apropriate IETF procedures.
o The data definition revision process must be streamlined. It must
be possible to make minor modifications and additions to published
data definitions without destabilizing large completely unrelated
parts of a specification.
o The work on policy-based extensions of the CIM model should be
hosted in one organization. Since the DMTF is the owner of the
CIM, it is suggested to move change control of PCIM over to the
Schoenwaelder Expires November 30, 2002 [Page 8]
Internet-Draft Future of Internet Network Management Standards Jun 2002
DMTF.
o Work should be started to move to an exception-driven fault
detection and isolation model. The work being done in the DISMAN
working group is constrainted by the limits of the SMIv2 data
definition language. In order to move to an exception-driven
fault detection and isolation model, it might be necessary to make
alarms first class object of the data definition language and to
provide a proper extensible infrastructure for alarm forwarding
and logging.
References
[1] Saperia, J. and J. Schoenwaelder, "Policy-Based Enhancements to
the SNMP Framework", Informatikbericht 00-02, May 2000.
Author's Address
Juergen Schoenwaelder
University of Osnabrueck
Albrechtstr. 28
49069 Osnabrueck
Germany
Phone:
EMail: schoenw@ibr.cs.tu-bs.de
Schoenwaelder Expires November 30, 2002 [Page 9]
Internet-Draft Future of Internet Network Management Standards Jun 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schoenwaelder Expires November 30, 2002 [Page 10]