[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/