|
Network Working Group Request for Comments: 3535 Category: Informational |
J. Schoenwaelder International University Bremen May 2003 |
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright © The Internet Society (2003). All Rights Reserved.
This document provides an overview of a workshop held by the Internet
Architecture Board (IAB) on Network Management. The workshop was
hosted by CNRI in Reston, VA, USA on June 4 thru June 6, 2002. The
goal of the workshop was to continue the important dialog started
between network operators and protocol developers, and to guide the
IETFs focus on future work regarding network management. This report
summarizes the discussions and lists the conclusions and
recommendations to the Internet Engineering Task Force (IETF)
community.
1. Introduction
2. Network Management Technologies
2.1 SNMP / SMI / MIBs
2.2 COPS-PR / SPPI / PIBs
2.3 CIM / MOF / UML / PCIM
2.4 CLI / TELNET / SSH
2.5 HTTP / HTML
2.6 XML
3. Operator Requirements
4. SNMP Framework Discussions
5. Consolidated Observations
6. Recommendations
7. Security Considerations
8. Acknowledgments
Normative References
Informative References
Appendix - Participants
Author's Address
Full Copyright Statement
The IETF has started several activities in the operations and management area to develop technologies and standards that aim to help network operators manage their networks. The main network management technologies currently being developed within the IETF are:
During 2001, several meetings have been organized at various events (NANOG-22 May 2001, RIPE-40 October 2001, LISA-XV December 2001, IETF-52 December 2001) to start a direct dialog between network operators and protocol developers. During these meetings, several operators have expressed their opinion that the developments in the IETF do not really address their requirements, especially for configuration management. This naturally leads to the question of whether the IETF should refocus resources, and which strategic future activities in the operations and management area should be started.
The Internet Architecture Board (IAB), on June 4 thru June 6, 2002, held an invitational workshop on network management. The goal of the workshop was to continue the important dialog started between network operators and protocol developers, and to guide the IETFs focus on future work regarding network management.
The workshop started with two breakout session to (a) identify a list of technologies relevant for network management together with their strengths and weaknesses, and to (b) identify the most important operator needs. The results of these discussions are documented in Section 2 and Section 3. During the following discussions, many more specific characteristics of the current SNMP framework were identified. These discussions are documented in Section 4. Section 5 defines a combined feature list that was developed during the discussions following the breakout sessions. Section 6 gives concrete recommendations to the IETF.
The following text makes no explicit distinction between different versions of SNMP. For the majority of the SNMP related statements, the protocol version is irrelevant. Nevertheless, some statements are more applicable to SNMPv1/SNMPv2c environments, while other statements (especially those concerned with security) are more applicable to SNMPv3 environments.
During the breakout sessions, the protocol developers assembled a list of the various network management technologies that are available or under active development. For each technology, a list of strong (+) and weak (-) points were identified. There are also some characteristics which appear to be neutral (o).
The list does not attempt to be complete. Focus was given to IETF specific technologies (SNMP, COPS-PR, PCIM) and widely used proprietary technologies (CLI, HTTP/HTML, XML). The existence of other generic management technologies (such as TL1, CORBA, CMIP/GDMO,
TMN) or specific management technologies for specific problem domains (such as RADIUS, DHCP, BGP, OSPF) were acknowledged, but were not the focus of discussion.
The SNMP management technology was created in the late 1980s and has since been widely implemented and deployed in the Internet. There is lots of implementational and operational experience, and the characteristics of the technology are thus well understood.
+ SNMP works reasonably well for device monitoring. The stateless
nature of SNMP is useful for statistical and status polling.
+ SNMP is widely deployed for basic monitoring. Some core MIB
modules, such as the IF-MIB [RFC2863], are implemented on most
networking devices.
+ There are many well defined proprietary MIB modules developed by
network device vendors to support their management products.
+ SNMP is an important data source for systems that do event
correlation, alarm detection, and root cause analysis.
- There are scaling problems with regard to the number of objects in
a device. While SNMP provides reasonable performance for the
retrieval of a small amount of data from many devices, it becomes
rather slow when retrieving large amounts of data (such as routing
tables) from a few devices.
- There is too little deployment of writable MIB modules. While
there are some notable exceptions in areas, such as cable modems
where writable MIB modules are essential, it appears that router
equipment is usually not fully configurable via SNMP.
- The SNMP transactional model and the protocol constraints make it
more complex to implement MIBs, as compared to the implementation
of commands of a command line interface interpreter. A logical
operation on a MIB can turn into a sequence of SNMP interactions
where the implementation has to maintain state until the operation is complete, or until a failure has been determined. In case of a failure, a robust implementation must be smart enough to roll the device back into a consistent state.
- SNMP does not support easy retrieval and playback of
configurations. One part of the problem is that it is not easy to
identify configuration objects. Another part of the problem is
that the naming system is very specific and physical device
reconfigurations can thus break the capability to play back a
previous configuration.
- There is often a semantic mismatch between the task-oriented view
of the world usually preferred by operators and the data-centric
view of the world provided by SNMP. Mapping from a task-oriented
view to the data-centric view often requires some non-trivial code
on the management application side.
- Several standardized MIB modules lack a description of high-level
procedures. It is often not obvious from reading the MIB modules
how certain high-level tasks are accomplished, which leads to
several different ways to achieve the same goal, which increases
costs and hinders interoperability.
A more detailed discussion about the SNMP management technology can be found in Section 4.
The COPS protocol [RFC2748] was defined in the late 1990s to support policy control over QoS signaling protocols. The COPS-PR extension allows provision policy information on devises.
+ COPS-PR allows high-level transactions for single devices,
including deleting one configuration and replacing it with
another.
+ COPS-PRs non-overlapping instance namespace normally ensures that
no other manager can corrupt a specific configuration. All
transactions for a given instance namespace are required to be
executed in-order.
+ Both manager and device states are completely synchronized with
one another at all times. If there is a failure in communication,
the state is resynchronized when the network is operating properly
again and the device's network configuration is valid.
+ The atomicity of transactions is well-defined. If there is any
failure in a transaction, that specific failure is reported to the
manager, and the local configuration is supposed to be
automatically rolled-back to the state of the last "good"
transaction.
+ Capability reporting is part of the framework PIB which must be
supported by COPS-PR implementations. This allows management
applications to adapt to the capabilities present on a device.
+ The focus of COPS-PR is configuration, and the protocol has been
optimized for this purpose (by using for example TCP as a
transport mechanism).
- As of the time of the meeting, there are no standardized PIB
modules.
- Compared to SNMP, there is not yet enough experience to understand
the strong and weak aspects of the protocol in operational
environments.
- COPS-PR does not support easy retrieval and playback of
configurations. The reasons are similar as for SNMP.
- The COPS-PR view of the world is data-centric, similar to SNMP's
view of the world. A mapping from the data-centric view to a
task-oriented view and vice versa, has similar complexities as
with SNMP.
The development of the Common Information Model (CIM) [CIM] started in the DMTF in the mid 1990s. The development follows a top-down approach where core classes are defined first and later extended to model specific services. The DMTF and the IETF jointly developed policy extensions of the CIM, known as PCIM [RFC3060].
+ The CIM technology generally follows principles of object-
orientation with full support of methods on data objects, which is
not available in SNMP or COPS-PR.
+ The MOF format allows representation of instances in a common
format. No such common format exists for SNMP or COPS-PR. It is
of course possible to store instances in the form of BER encoded
ASN.1 sequences, but this is generally not suitable for human
readability.
+ There is support for a query facility which allows the locating of
CIM objects. However, the query language itself is not yet
specified as part of the CIM standards. Implementations currently
use proprietary query languages, such as the Windows Management
Instrumentation Query Language (WQL).
+ The information modeling work in CIM is done by using Unified
Modeling Language (UML) as a graphical notation. This attracts
people with a computer science background who have learned to use
UML as part of their education.
- The CIM schemas have rather complex interrelationships that must
be understood before one can reasonably extend the set of existing
schemas.
- Interoperability between CIM implementations seems to be
problematic compared to the number of interoperable SNMP
implementations available today.
- So far, CIM schemas have seen limited implementation and usage as
an interface between management systems and network devices.
Most devices have a builtin command line interface (CLI) for configuration and troubleshooting purposes. Network access to the CLI has traditionally been through the TELNET protocol, while the SSH protocol is gaining momentum to address security issues associated with TELNET. In the following, only CLIs that actually parse and execute commands are considered. (Menu-oriented interfaces are difficult for automation and thus not relevant here.)
+ Command line interfaces are generally task-oriented, which make
them easier to use for human operators.
+ A saved sequence of textual commands can easily be replayed.
Simple substitutions can be made with arbitrary text processing
tools.
+ It is usually necessary to learn at least parts of the command
line interface of new devices in order to create the initial
configuration. Once people have learned (parts of) the command
line interface, it is natural for them to use the same interface
and abstractions for automating configuration changes.
+ A command line interface does not require any special purpose
applications (telnet and ssh are readily available on most systems
today).
+ Most command line interfaces provide context sensitive help that
reduces the learning curve.
- Some command line interfaces lack a common data model. It is very
well possible that the same command on different devices, even
from the same vendor, behaves differently.
- The command line interface is primarily targeted to humans which
can adapt to minor syntax and format changes easily. Using
command line interfaces as a programmatic interface is troublesome
because of parsing complexities.
- Command line interfaces often lack proper version control for the
syntax and the semantics. It is therefore time consuming and
error prone to maintain programs or scripts that interface with
different versions of a command line interface.
- Since command line interfaces are proprietary, they can not be
used efficiently to automate processes in an environment with a
heterogenous set of devices.
- The access control facilities, if present at all, are often ad-hoc
and sometimes insufficient.
Many devices have an embedded web server which can be used to configure the device and to obtain status information. The commonly used protocol is HTTP, and information is rendered in HTML. Some devices also expect that clients have facilities such as Java or Java Script.
+ Embedded web servers for configuration are end-user friendly and
solution oriented.
+ Embedded web servers are suitable for configuring consumer devices
by inexperienced users.
+ Web server configuration is widely deployed, especially in boxes
targeted to the consumer market.
+ There is no need for specialized applications to use embedded web
servers since web browsers are commonly available today.
- Embedded web servers are management application hostile. Parsing
HTML pages to extract useful information is extremely painful.
- Replay of configuration is often problematic, either because the
web pages rely on some active content or because different
versions of the same device use different ways to interact with
the user.
- The access control facilities, if present at all, are often ad-hoc
and sometimes insufficient.
In the late 1990's, some vendors started to use the Extensible Markup Language (XML) [XML] for describing device configurations and for protocols that can be used to retrieve and manipulate XML formatted configurations.
+ XML is a machine readable format which is easy to process and
there are many good off the shelf tools available.
+ XML allows the description of structured data of almost arbitrary
complexity.
+ The basic syntax rules behind XML are relatively easy to learn.
+ XML provides a document-oriented view of configuration data
(similar to many proprietary configuration file formats).
+ XML has a robust schema language XSD [XSD] for which many good off
the shelf tools exist.
- XML is rather verbose. This either increases the bandwidth
required to move management information around (which is an issue
in e.g., wireless or asymmetric cable networks) or it requires
that the systems involved have the processing power to do on the
fly compression/decompression.
- There is a lack of commonly accepted standardized management
specific XML schemas.
During the breakout session, the operators were asked to identify needs that have not been sufficiently addressed. The results produced during the breakout session were later discussed and resulted in the following list of operator requirements.
So far, there is no published document that clearly defines the requirements of the operators.
During the discussions, many properties of the SNMP framework were identified.
The workshop also discussed the following items and achieved rough consensus, but did not make a recommendation.
This document is a report of an IAB Network Management workshop. As such, it does not have any direct security implications for the Internet.
The editor would like to thank Dave Durham, Simon Leinen and John Schnizlein for taking detailed minutes during the workshop.
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002.
[CIM] Distributed Management Task Force, "Common Information
Model (CIM) Specification Version 2.2", DSP 0004, June
1999.
[RFC3060] Moore, B., Ellesson, E., Strassner, J. and A. Westerinen,
"Policy Core Information Model -- Version 1
Specification", RFC 3060, February 2001.
[RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.
[XML] Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible
Markup Language (XML) 1.0", W3C Recommendation, February
1998.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[XSD] David, D., "XML Schema Part 0: Primer", W3C
Recommendation, May 2001.
Ran Atkinson Extreme Networks Rob Austein InterNetShare Andy Bierman Cisco Systems Steve Bellovin AT&T Randy Bush AT&T Leslie Daigle VeriSign David Durham Intel Vijay Gill Wes Hardaker Network Associates Laboratories Ed Kern Simon Leinen Switch Ken Lindahl University of California Berkeley David Partain Ericsson Andrew Partan UUnet/Verio/MFN Vern Paxson ICIR Aiko Pras Univeristy of Twente Randy Presuhn BMC Software Juergen Schoenwaelder University of Osnabrueck John Schnizlein Cisco Systems Mike St. Johns Ruediger Volk Deutsche Telekom Steve Waldbusser Margaret Wassermann Windriver Glen Waters Nortel Networks Bert Wijnen Lucent
Comments should be submitted to the <nm-ws@ops.ietf.org> mailing list.
Juergen Schoenwaelder
International University Bremen
Phone: +49 421 200 3587
EMail: j.schoenwaelder@iu-bremen.de
Copyright © The Internet Society (2003). 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 assignees.
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.
Funding for the RFC Editor function is currently provided by the Internet Society.