RFC 1189 HISTORIC NETWORK MANAGEMENT · ISO · CMIP

Common Management Information Services and Protocols for the Internet (CMOT and CMIP)

How ISO's network management standards were fitted onto the Internet, over TCP/IP and over OSI.

On rfc-editor.org ↗
PUBLISHED
October 1990
AUTHORS
U.S. Warrier, L. Besaw, L. LaBarre, B.D. Handspicker
STREAM
IETF
BUILDS ON
RFC 1095 — CMOT
PROTOCOLS IN THE CMOT SUITE
7
PROTOCOLS IN THE CMIP SUITE
6
ASSOCIATION TYPES
4
APPLICATION CONTEXT NAMES REGISTERED
7
MAXIMUM LPP PDU LENGTH OVER UDP
484 octets
TIME GRANULARITY FOR EVENT TIMES
1 millisecond
DOI
10.17487/RFC1189

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Network Working Working Group                                 U. Warrier
Request for Comments: 1189                                       Netlabs
Obsoletes:  RFC 1095                                            L. Besaw
                                                         Hewlett-Packard
                                                              L. LaBarre
                                                   The Mitre Corporation
                                                          B. Handspicker
                                           Digital Equipment Corporation
                                                            October 1990


              The Common Management Information Services
                     and Protocols for the Internet
                            (CMOT and CMIP)

Status of this Memo

   This memo defines a network management architecture that uses the
   International Organization for Standardization's (ISO) Common
   Management Information Services/Common Management Information
   Protocol (CMIS/CMIP) in the Internet.  This RFC specifies an IAB
   standards track protocol for the Internet community, and requests
   discussion and suggestions for improvements.  Please refer to the
   current edition of the "IAB Official Protocol Standards" for the
   standardization state and status of this protocol.

   Distribution of this memo is unlimited.

Table of Contents

   1. Overview ...................................................    2
   2. Introduction ...............................................    3
   3. Protocol Overview ..........................................    4
   3.1. The CMOT Protocol Suite ..................................    5
   3.2. The CMIP Protocol Suite ..................................    6
   3.3. Conformance Requirements .................................    6
   4. Common Management Information Service Element ..............    7
   4.1. Association Policies .....................................    7
   4.2. CMIS Services ............................................    9
   4.2.1 General Agreements on Users of CMIS .....................    9
   4.2.2 Specific Agreements on Users of CMIS ....................   10
   4.3. CMIP Agreements ..........................................   10
   5. Services Required by CMIP ..................................   10
   6. Acknowledgements ...........................................   11
   7. References .................................................   11
   8. Security Considerations.....................................   14
   9. Authors' Addresses..........................................   14

1.  Overview

   This memo is a revision of RFC 1095 - "The Common Management
   Information Services and Protocol over TCP/IP" [27].  It defines a
   network management architecture that uses the International
   Organization for Standardization's (ISO) Common Management
   Information Services/Common Management Information Protocol
   (CMIS/CMIP) in the Internet.  This architecture provides a means by
   which control and monitoring information can be exchanged between a
   manager and a remote network element.  In particular, this memo
   defines the means for implementing the International Standard (IS)
   version of CMIS/CMIP on top of both IP-based and OSI-based Internet
   transport protocols for the purpose of carrying management
   information defined in the Internet-standard management information
   base.  Together with the relevant ISO standards and the companion
   RFCs that describe the initial structure of management information
   and management information base, these documents provide the basis
   for a comprehensive architecture and system for managing both IP-
   based and OSI-based internets, and in particular the Internet.

   In creating this revision of RFC 1095, the following technical and
   editorial changes were made:

      1) The tutorial section on OSI Management included in RFC 1095
         has been removed from this document.  After some revisions,
         the tutorial material may be published as another RFC.

      2) The sections in RFC 1095 which discussed the semantics of how
         to interpret requests in the context of Internet MIBs has been
         removed from this protocol document.  This topic is now
         discussed in the OIM-MIB-II draft document.  This protocol
         should be useable with MIB-I or MIB-II.  But, it will also be
         able to exploit the new features of the OIM-MIB-II.

      3) This document is based on the final International Standards
         for CMIS/CMIP (ISO 9595/9596) rather than the Draft
         International Standards.

      4) Many of the original agreements defined in RFC 1095 have been
         accepted and included in the OIW NMSIG implementers agreements.
         Rather than duplicating these agreements, they have been removed
         from this memo.  This document should be read in conjunction
         with ISO 9595/9596 (CMIS/CMIP) and the OIW Stable Agreements
         document.

      5) The Association Negotiation describe in RFC 1095 has been
         changed to align with current international and national
         agreements.  But, it has retained backwards compatibility with
         the assignment of an Application Context Name which is identical
         to the Application Context Name specified in RFC 1095.

2.  Introduction

   This memo is the output of the OSI Internet Management Working Group
   of the Internet Engineering Task Force (IETF).  As directed by the
   Internet Activites Board (IAB) in RFC 1052, it addresses the need for
   a long-term network management system based on ISO CMIS/CMIP.  This
   memo contains a set of protocol agreements for implementing a network
   management system based on these ISO Management standards.  Now that
   CMIS/CMIP has been voted an International Standard (IS), it has
   become a stable basis for product development.  This profile
   specifies how to apply CMIP to management of both IP-based and OSI-
   based Internet networks.  Network management using ISO CMIP to manage
   IP-based networks will be refered to as "CMIP Over TCP/IP" (CMOT).
   Network management using ISO CMIP to manage OSI-based networks will
   be refered to as "CMIP".  This memo specifies the protocol agreements
   necessary to implement CMIP and accompanying ISO protocols over OSI,
   TCP and UDP transport protocols.

   This memo must be read in conjunction with ISO and Internet documents
   defining specific protocol standards.  Documents defining the
   following ISO standards are required for the implementor: Abstract
   Syntax Notation One (ASN.1) [5, 6], Association Control (ACSE) [7,
   8], Remote Operations (ROSE) [9, 10], Common Management Information
   Services (CMIS) [11] and Common Management Information Protocol
   (CMIP) [12] with their addenda [32-35].  The specification of a
   lightweight presentation layer protocol is required for use with the
   CMOT section of this profile (see RFC 1085 [13]).  The SMI (see RFC
   1065 [2]), the MIB-I (see RFC 1066 [3]), the MIB-II (see RFC 1156
   [28]), and the OIM-MIB-II (see [29]) are used with this management
   system.

   This memo is divided into sections for each of the protocols for
   which implementors' agreements are needed: CMISE, ACSE, ROSE, and,
   for CMOT, the lightweight presentation protocol.  The protocol
   profile defined in this memo draws on the technical work of the OSI
   Network Management Forum [14] and the Network Management Special
   Interest Group (NMSIG) of the National Institute of Standards and
   Technology (NIST) (formerly the National Bureau of Standards) [30].
   Wherever possible, an attempt has been made to either directly
   reference or remain consistent with the protocol agreements reached
   by these groups.

3.  Protocol Overview

   This part of the document is a specification of the protocols of the
   OIM architecture.  Contained herein are the agreements required to
   implement interoperable network management systems using these
   protocols.  The protocol suite defined by these implementors'
   agreements will facilitate communication between equipment of
   different vendors, suppliers, and networks.  This will allow the
   emergence of powerful multivendor network management based on ISO
   models and protocols.

   The choice of a set of protocol standards together with further
   agreements needed to implement those standards is commonly referred
   to as a "profile."  The selection policy for this profile is to use
   existing standards from the international standards community (ISO
   and CCITT) and the Internet community.  Existing ISO standards and
   draft standards in the area of OSI network management form the basis
   of this profile.  Other ISO application layer standards (ROSE and
   ACSE) are used to support the ISO management protocol (CMIP).  To
   ensure interoperability, certain choices and restrictions are made
   here concerning various options and parameters provided by these
   standards.   Internet standards are used to provide the underlying
   network transport.  These agreements provide a precise statement of
   the implementation choices made for implementing ISO network
   management standards in IP-based and OSI-based internets.

   In addition to the OIM working group, there are at least two other
   bodies actively engaged in defining profiles for interoperable OSI
   network management: the OSI Implementors Workshop (OIW) and the OSI
   Network Management Forum.  Both of these groups are similar to the
   OIM working group in that they are each defining profiles for using
   ISO standards for network management.  Both differ in that they are
   specifying the use only of underlying ISO protocols, while the OIM
   working group is concerned with using OSI management in both OSI and
   TCP/IP networks.  In the interest of greater future compatibility,
   the OIM working group has attempted to make this profile conform as
   closely as possible to the ongoing work of these two bodies.

   This section will describe the CMOT Protocol Suite, the CMIP Protocol
   Suite and Conformance Requirements common to both CMOT and CMIP.
   Later sections will specify the implementers agreements for specific
   layer protocols that comprise the CMOT and CMIP Protocol Suites.

3.1.  The CMOT Protocol Suite

   The following seven protocols compose the CMOT protocol suite: ISO
   ACSE, ISO DIS ROSE, ISO CMIP, the lightweight presentation protocol
   (LPP), UDP, TCP, and IP.  The relation of these protocols to each
   other is briefly summarized in Figure 2.

                 +----------------------------------------------+
                         Management Application Processes
                 +----------------------------------------------+

                             +-------------------+
                                     CMISE
                                 ISO 9595/9596
                             +-------------------+

                 +------------------+       +--------------------+
                          ACSE                       ROSE
                   ISO IS 8649/8650           ISO DIS 9072-1/2
                 +------------------+       +--------------------+

                 +-----------------------------------------------+
                       Lightweight Presentation Protocol (LPP)
                                     RFC 1085
                 +-----------------------------------------------+

                 +------------------+       +--------------------+
                         TCP                         UDP
                       RFC 793                     RFC 768
                 +------------------+       +--------------------+

                 +-----------------------------------------------+
                                       IP
                                     RFC 791
                 +-----------------------------------------------+

                      Figure 2.  The CMOT Protocol Suite

3.2.  The CMIP Protocol Suite

   The following six protocols compose the CMIP protocol suite: ISO
   ACSE, ISO DIS ROSE, ISO CMIP, ISO Presentation, ISO  Session and ISO
   Transport.  The relation of these protocols to each other is briefly
   summarized in Figure 3.

                 +----------------------------------------------+
                         Management Application Processes
                 +----------------------------------------------+

                             +-------------------+
                                     CMISE
                                 ISO 9595/9596
                             +-------------------+

                 +------------------+       +--------------------+
                          ACSE                       ROSE
                     ISO 8649/8650            ISO DIS 9072-1/2
                 +------------------+       +--------------------+

                 +-----------------------------------------------+
                                ISO Presentation
                                    ISO
                 +-----------------------------------------------+

                 +-----------------------------------------------+
                                ISO Session
                                    ISO
                 +-----------------------------------------------+

                 +-----------------------------------------------+
                                ISO Transport
                                    ISO
                 +-----------------------------------------------+

                      Figure 3.  The CMIP Protocol Suite

3.3.  Conformance Requirements

   A CMOT-conformant system must implement the following protocols:
   ACSE, ROSE, CMIP, LPP, and IP.  A CMOT-conformant system must support
   the use of the LPP over either UDP or TCP.  The use of the LPP over
   both UDP and TCP on the same system may be supported.

   A CMIP-conformant system must implement the following protocols:
   ACSE, ROSE, CMIP, ISO Presentation, ISO Session and ISO Transport.

4.  Common Management Information Service Element

   The Common Management Information Service Element (CMISE) is
   specified in two ISO documents.  The service definition for the
   Common Management Information Service (CMIS) is given in ISO 9595
   [11].  The protocol specification for the Common Management
   Information Protocol (CMIP) is found in ISO 9596 [12].  In addition,
   the addenda for add/remove support in M-SET [32, 34] must be
   supported for both CMOT and CMIP.  The addenda for M-CANCEL-GET [33,
   35] may be supported by an implementation, but it's use is negotiated
   as part of association negotiation.

4.1.  Association Policies

   The following ACSE services are required by CMISE: A-ASSOCIATE, A-
   RELEASE, A-ABORT, and A-P-ABORT.  The rest of the CMIP protocol uses
   the RO-INVOKE, RO-RESULT, RO-ERROR, and RO-REJECT services of ROSE.

   There are four types of association that may be negotiated between
   managing and managed systems.  These types are:

      Event               M-EVENT-REPORTs may be sent by the
                          managed system; no other CMIP PDUs
                          are allowed

      Event/Monitor       same as Event type except that, in
                          addition, the managing system may
                          also issue M-GET requests and
                          receive M-GET responses over the
                          association

      Monitor/Control     managing system may issue M-GET,
                          M-SET, M-CREATE, M-DELETE and
                          M-ACTION requests over the
                          association; no event reporting is
                          allowed

      Full Mgr/Agent      all functions must be supported

   A conformant system  must support at least one of these Association
   types.  Note that a system may play both managing and managed system
   roles, but not on the same association.

   The negotiation process uses the A-ASSOCIATE and A-RELEASE services.
   Application Context Name is used to determine the requestor's "role"
   in an association (as managing or managed system) and to determine
   the type of the association.

   The following values for Application Context Name are registered for
   for CMOT and CMIP:

      {iso(1) identified-organization(3) dod(6)
           internet(1) mgmt(2) mib(1) oim(9) acn(1)
           cmot1095(1)}
           (for backwards compatible negotiation with RFC 1095 CMOT
           implementations)

      {iso(1) identified-organization(3) dod(6)
           internet(1) mgmt(2) mib(1) oim(9) acn(1)
           manager-event-association(2)}

      {iso(1) identified-organization(3) dod(6)
           internet(1) mgmt(2) mib(1) oim(9) acn(1)
           manager-event-monitor-association(3)}

      {iso(1) identified-organization(3) dod(6)
           internet(1) mgmt(2) mib(1) oim(9) acn(1)
           manager-monitor-control-association(4)}

      {iso(1) identified-organization(3) dod(6)
           internet(1) mgmt(2) mib(1) oim(9) acn(1)
           manager-full-association(5)}

      {iso(1) identified-organization(3) dod(6)
           internet(1) mgmt(2) mib(1) oim(9) acn(1)
           agent-event-association(6)}

   The following negotiation rules are to be used:

      1.   A managed system may only request an Event
           association and, in fact, must create an Event
           association if it has an event to report and no
           suitable association already exists.

      2.   Managing systems may request any association type.

      3.   An association is created by the requesting system
           issuing an A-ASSOCIATE request with the
           requestor's AE-TITLE and the desired application
           context.  The responding system then returns
           either 1) an A-ASSOCIATE response with the
           requestor's AE-TITLE and the application context
           which it wishes to accept or 2) an A-ASSOCIATE
           response rejecting the association.

      4.   Managed systems may negotiate "downward" from
           Full to Monitor/Control, Event/Monitor or Event by
           returning the new application context in the
           A-ASSOCIATE response to the managing system during
           the association creation process.  In the same
           fashion, managed systems may negotiate from
           Event/Monitor to Event.

      5.   When a managing system receives an application
           context in an A-ASSOCIATE response that differs
           from the context sent in an A-ASSOCIATE request it
           may either proceed with the new context or refuse
           the new context by issuing an A-RELEASE request.

   A-RELEASE is used when the requestor does not agree with the new
   context.  A-ABORT is used for invalid negotiation.  If A-ABORT were
   to be used to terminate an association, there exists the potential
   for loss of information, such as pending events or confirmations.
   A-ABORT must be used, however, when a protocol violation occurs or
   where an association is not yet established.

4.2.  CMIS Services

4.2.1  General Agreements on Users of CMIS

   The general agreements on users of CMIS shall be as specified in the
   OIW Stable Agreements [30] section 18.6.2.

   The following additional agreements are specified.

      o A system need only implement the services and service
        primitives required for the association types (section 4.1)
        that it supports.

      o Current/Event times shall be fields shall use 1 millisecond
        granularity.  If the system generating the PDU does not have
        the current time, yet does have the time since last boot, then
        GeneralizedTime can be used to encode this information.  The
        time since last boot will be added to the base time "0001
        Jan 1 00:00:00.00" using the Gregorian calendar algorithm.
        (In the Gregorian calendar, all years have 365 days except
        those divisible by 4 and not by 400, which have 366.)  The use
        of the year 1 as the base year will prevent any confusion
        with current time.

        If no meaningful time is available, then the year 0 shall be
        used in GeneralizedTime to indicate this fact.

4.2.2  Specific Agreements on Users of CMIS

   The specific agreements on users of CMIS shall be as specified in the
   OIW Stable Agreements [30] section 18.6.3.

   The following additional agreements are specified:

      o Event time shall be mandatory for all events.

      o  Both the "managed Object Class" and "managed Object
         Instance" parameters must be present in the following CMIS
         Service Response/Confirmation primitives: the
         M-EVENT-REPORT Confirmed, the M-GET, the M-SET, the
         M-ACTION, the M-CREATE, and the M-DELETE.

4.3.  CMIP Agreements

   The CMIS and CMIP implementers agreements documented in the OIW
   Stable Implementers Agreements [30] plus those mandated by the CMIP
   standard will be used for both CMOT and CMIP.  In addition to these
   implementers agreements, the following specific agreements must be
   observed:

      o An implementation is required to support all filter items
        except subsetOf, supersetOf, nonNullSetIntersection, and
        substrings.

      o The "managedObjectInstance" field must be present in the
        ProcessingFailure Error PDU.  The "managedObjectClass"
        field must be present in the NoSuchArgument Error PDU.


   [Temporary Note:  The CMIS/P implementers agreements have reach a
   fairly stable status in the OIW working agreements document.  It is
   expected that the CMIS/P agreements (18.6.2 and 18.6.3) will be
   recommended to be moved into the stable agreements document during
   either the June 1990 meetings.  Reference [30] points to the presumed
   June 1990 updated version of the stable agreements document.]

5.  Services Required by CMIP

   The services required by CMIP shall be as specified in the OIW Stable
   Implementors Agreements [30] section 18.6.5.

   The following additional agreements are specified:

      o ASCE Requirements:  Application contexts shall be as defined
        in section 4.1 of these agreements.  The values and defaults
        of parameters to the ACSE parameters given to the presentation
        service are specified in RFC 1085 [13] for CMOT and in the NIST
        Stable Implementers Agreements [30] for CMIP.

      o Presentation Requirements:  CMOT implementations shall be
        supported by the Lightweight Presentation Protocol (LPP)
        [13].  The LPP may use either TCP or UDP.  When UDP is used,
        an implementation need not accept LPP PDUs whose length
        exceeds 484 octets.

      o Session Requirements:  CMOT implementations will not
        require the session protocol.

6.  Acknowledgements

   This RFC is the result of the work of many people.  The following
   members of the IETF OSI Internet Management and preceding Netman
   working groups made important contributions:

             Amatzia Ben-Artzi, Synoptics
             Asheem Chandna, AT&T Bell Laboratories
             Ken Chapman, Digital Equipment Corporation
             Anthony Chung, Sytek
             George Cohn, Ungermann-Bass
             Gabriele Cressman, Sun Microsystems
             Tom Halcin, Hewlett-Packard
             Pranati Kapadia, Hewlett-Packard
             Lee LaBarre, The MITRE Corporation (co-chair)
             Dave Mackie, 3Com
             Keith McCloghrie, Hughes/InterLan
             Jim Robertson, 3Com
             Milt Roselinsky, CMC
             Marshall Rose, PSI
             John Scott, Data General
             Lou Steinberg, IBM

7.  References

   [1] Cerf, V., "IAB Recommendations for the Development of Internet
       Network Management Standards", RFC 1052, IAB, April 1988.

   [2] Rose, M., and K. McCloghrie, "Structure and Identification of
       Management Information for TCP/IP-based internets", RFC 1065,
       TWG, August 1988.

   [3] McCloghrie, K., and M. Rose, "Management Information Base for
       Network Management of TCP/IP-based internets", RFC 1066, TWG,
       August 1988.

   [4] Case, J., M. Fedor, M. Schoffstall, and J. Davin, "A Simple
       Network Management Protocol (SNMP)", RFC 1098, (Obsoletes RFC
       1067), University of Tennessee at Knoxville, NYSERNet, Inc.,
       Rensselaer Polytechnic Institute, MIT Laboratory for Computer
       Science, April 1989.

   [5] ISO 8824: "Information Processing Systems - Open Systems
       Interconnection, Specification of Abstract Syntax Notation One
       (ASN.1)", Geneva, March 1988.

   [6] ISO 8825: "Information Processing Systems - Open Systems
       Interconnection, Specification of Basic Encoding Rules for
       Abstract Notation One (ASN.1)", Geneva, March 1988.

   [7] ISO 8649: "Information Processing Systems - Open Systems
       Interconnection, Service Definition for Association Control
       Service Element".

   [8] ISO 8650: "Information Processing Systems - Open Systems
       Interconnection, Protocol Specification for Association Control
       Service Element".

   [9] CCITT Recommendation X.219, Working Document for ISO 9072-1:
       "Information processing systems - Text Communication, Remote
       Operations: Model, Notation and Service Definition", Gloucester,
       November 1987.

  [10] CCITT Recommendation X.229, Working Document for ISO 9072-2:
       "Information processing systems - Text Communication, Remote
       Operations: Protocol Specification", Gloucester, November 1987.

  [11] ISO 9595: "Information Processing Systems - Open Systems
       Interconnection, Management Information Service Definition - Part
       2: Common Management Information Service", 22 December 1988.

  [12] ISO 9596: "Information Processing Systems - Open Systems
       Interconnection, Management Information Protocol Specification -
       Part 2: Common Management Information Protocol", 22 December
       1988.

  [13] Rose, M., "ISO Presentation Services on top of TCP/IP-based
       internets", RFC 1085, TWG, December 1988.

  [14] OSI Network Management Forum, "Forum Interoperable Interface
       Protocols", September 1988.

  [15] ISO DIS 7498-4: "Information Processing Systems - Open Systems
       Interconnection, Basic Reference Model - Part 4: OSI Management
       Framework".

  [16] ISO/IEC JTC1/SC21/WG4 N571: "Information Processing Systems -
       Open Systems Interconnection, Systems Management: Overview",
       London, July 1988.

  [17] Klerer, S. Mark, "The OSI Management Architecture: An Overview",
       IEEE Network Magazine, March 1988.

  [18] Ben-Artzi, A., "Network Management for TCP/IP Networks: An
       Overview", Internet Engineering Task Force working note, April
       1988.

  [19] ISO/IEC JTC1/SC21/WG4 N3324: "Information Processing Pystems -
       Open Systems Interconnection, Management Information Services -
       Structure of Management Information - Part I: Management
       Information Model", Sydney, December 1988.

  [20] Postel, J., "User Datagram Protocol", RFC 768, USC/Information
       Sciences Institute, August 1980.

  [21] Postel, J., "Transmission Control Protocol", RFC 793,
       USC/Information Sciences Institute, September 1981.

  [22] ISO DP 9534: "Information processing systems - Open Systems
       Interconnection, Application Layer Structure", 10 March 1987.

  [23] Rose, M., and D. Cass, "ISO Transport Services on top of the TCP,
       Version: 3", RFC 1006, Northrop Research and Technology Center,
       May 1987.

  [24] ISO 8822: "Information Processing Systems - Open Systems
       Interconnection, Connection Oriented Presentation Service
       Definition", June 1987.

  [25] Postel, J., "Internet Protocol", RFC 791, USC/Information
       Sciences Institute, September 1981.

  [26] CCITT Draft Recommendation X.500, ISO 9594/1-8: "The Directory",
       Geneva, March 1988.

  [27] Warrier, U. and L. Besaw, "The Common Management Information
       Services and Protocol over TCP/IP (CMOT)", RFC 1095, Unisys
       Corporation, Hewlett-Packard, April 1989.

  [28] McCloghrie, K., and M. Rose, "Management Information Base for
       Network Management of TCP/IP-based internets", RFC 1156, Hughes
       LAN Systems, Performance Systems International, May 1990.

  [29]  LaBarre, L., "OIM MIB-II", working note, December 1989.

  [30] NIST NMSIG, "NIST Stable Implementers Agreements", NIST Special
       Publication 500-162, as ammended by June 1990.

  [31] NIST NMSIG, "NIST Working Implementers Agreements", December
       1989.

  [32] ISO IS 9595 1989: DAD1: "CMIS Add/Remove Addendum".

  [33] ISO IS 9595 1989: DAD2: "CMIS Cancel-Get Addendum".

  [34] ISO IS 9596 1989: DAD1: "CMIP Add/Remove Addendum".

  [35] ISO IS 9596 1989: DAD2: "CMIP Cancel-Get Addendum".

8.  Security Considerations

   Security issues are not discussed in this memo.

9.  Authors' Addresses

   Unnikrishnan S. Warrier
   NetLabs
   11693 San Vicente Blvd
   Suite 348
   Los Angeles, CA 90049

   Phone: (213) 476-4070
   Email: unni@netlabs.com


   Larry Besaw
   Hewlett-Packard
   3404 East Harmony Road
   Fort Collins, CO 80525

   Phone: (303) 229-6022
   Email: lmb%hpcndaw@hplabs.hp.com


   Lee LaBarre
   Mitre
   Burlington Road
   Bedford, MA 01730

   Phone: (617) 271-8507
   Email: cel@mbunix.mitre.org
   Brian D. Handspicker
   Digital Equipment Corporation
   550 King St.
   Littleton, Ma. 01460

   Phone: (508) 486-7894
   Email: bd@vines.enet.dec.com

ISO Plain Language

On this page
PROBLEMISO's Common Management Information Services and Protocol had become an International Standard, but the standards did not say how to run them over IP networks, and implementers had to agree on the choices.
MECHANISMRFC 1189 defines a profile: which protocols each suite uses, which association types may be negotiated, which application context names identify them, and the agreements on CMIS and CMIP services.
STATUS TODAYCMOT is ISO CMIP over TCP/IP and CMIP is ISO CMIP over OSI networks. RFC 1189 revised RFC 1095 and has not been obsoleted, but is Historic.

§1What CMOT and CMIP Are

RFC 1189 is a revision of RFC 1095, The Common Management Information Services and Protocol over TCP/IP. It defines a network management architecture that uses the International Organization for Standardization's Common Management Information Services and Common Management Information Protocol (CMIS/CMIP) in the Internet. The architecture gives a means by which control and monitoring information can be exchanged between a manager and a remote network element. In particular, the memo defines the means for implementing the International Standard version of CMIS/CMIP on top of both IP-based and OSI-based Internet transport protocols, for the purpose of carrying management information defined in the Internet-standard management information base.

Together with the relevant ISO standards and the companion RFCs that describe the initial structure of management information and the management information base, these documents provide the basis for a comprehensive architecture and system for managing both IP-based and OSI-based internets, and in particular the Internet.

The revision made five changes. The tutorial section on OSI management included in RFC 1095 was removed, on the understanding that it might be published as another RFC after revision. The sections discussing how to interpret requests in the context of Internet MIBs were removed and are now discussed in the OIM-MIB-II draft. The document is based on the final International Standards for CMIS/CMIP, ISO 9595 and 9596, rather than the draft versions. Many of the original agreements in RFC 1095 were accepted and included in the OIW NMSIG implementers agreements, so rather than duplicating them they were removed and the document should be read with ISO 9595/9596 and the OIW Stable Agreements document. And the Association Negotiation described in RFC 1095 was changed to align with current international and national agreements, while retaining backwards compatibility with the assignment of an Application Context Name identical to the one specified in RFC 1095.

This document is the list of choices that make ISO's management protocol usable on the Internet. It was rewritten in 1990 to point at the finished ISO standards and to drop material that had moved elsewhere.

§2Why the ISO Management Standards Were Chosen

The memo is the output of the OSI Internet Management Working Group of the IETF, and as directed by the Internet Activities Board in RFC 1052 it addresses the need for a long-term network management system based on ISO CMIS/CMIP. Now that CMIS/CMIP had been voted an International Standard, it had become a stable basis for product development.

The profile specifies how to apply CMIP to the management of both IP-based and OSI-based Internet networks. Network management using ISO CMIP to manage IP-based networks is referred to as CMIP Over TCP/IP, or CMOT. Network management using ISO CMIP to manage OSI-based networks is referred to as CMIP. The memo specifies the protocol agreements necessary to implement CMIP and the accompanying ISO protocols over OSI, TCP and UDP transport protocols.

It must be read together with the documents defining the ISO standards an implementor needs: ASN.1, Association Control (ACSE), Remote Operations (ROSE), CMIS and CMIP with their addenda. The specification of a lightweight presentation layer protocol is required for use with the CMOT section of the profile. The SMI, MIB-I, MIB-II and OIM-MIB-II are used with the management system.

The choice of a set of protocol standards together with the further agreements needed to implement them is commonly called a profile. The selection policy is to use existing standards from the international standards community and the Internet community. Existing ISO standards and draft standards in the area of OSI network management form the basis of the profile, and other ISO application layer standards, ROSE and ACSE, support the ISO management protocol. To ensure interoperability, the memo makes certain choices and restrictions about the options and parameters the standards provide. The profile draws on the technical work of the OSI Network Management Forum and of the Network Management Special Interest Group of NIST, and wherever possible references or stays consistent with the agreements those groups reached.

ISO management was chosen because it had become a finished International Standard, which gives product builders something stable to work from. This document is the Internet's set of concrete choices on top of it.

§3The Two Protocol Suites

The CMOT protocol suite is made of seven protocols: ISO ACSE, ISO DIS ROSE, ISO CMIP, the lightweight presentation protocol (LPP), UDP, TCP and IP. The CMIP protocol suite is made of six: ISO ACSE, ISO DIS ROSE, ISO CMIP, ISO Presentation, ISO Session and ISO Transport. The two figures in the RFC show how these stack up, with the management application processes at the top, then CMISE from ISO 9595 and 9596, then ACSE from ISO 8649 and 8650 alongside ROSE from ISO DIS 9072-1 and 9072-2. Below that the CMOT suite uses the Lightweight Presentation Protocol of RFC 1085 over TCP and UDP over IP, while the CMIP suite uses ISO Presentation, ISO Session and ISO Transport in turn.

A CMOT-conformant system must implement ACSE, ROSE, CMIP, LPP and IP, and must support the use of LPP over either UDP or TCP. It may support LPP over both on the same system. A CMIP-conformant system must implement ACSE, ROSE, CMIP, ISO Presentation, ISO Session and ISO Transport.

CMOT puts the ISO management protocol on top of a lightweight presentation protocol over TCP or UDP. CMIP leaves the ISO presentation, session and transport protocols in place. Both share ACSE, ROSE and CMIP.

The CMOT protocol suite (RFC 1189, Figure 2)
  1. Management applicationsThe programs that monitor and control the network
  2. CMISECommon Management Information Service Element, ISO 9595/9596
  3. ACSE and ROSEISO 8649/8650 and ISO DIS 9072-1/2
  4. Lightweight Presentation ProtocolRFC 1085
  5. TCP and UDPRFC 793 and RFC 768
  6. IPRFC 791

§4.1Association Types and Negotiation

CMISE requires four ACSE services: A-ASSOCIATE, A-RELEASE, A-ABORT and A-P-ABORT. The rest of the CMIP protocol uses the RO-INVOKE, RO-RESULT, RO-ERROR and RO-REJECT services of ROSE.

There are four types of association that may be negotiated between a managing and a managed system. In an Event association, the managed system may send M-EVENT-REPORTs and no other CMIP protocol data units are allowed. In an Event/Monitor association, as for Event, the managing system may also issue M-GET requests and receive M-GET responses. In a Monitor/Control association, the managing system may issue M-GET, M-SET, M-CREATE, M-DELETE and M-ACTION requests, and no event reporting is allowed. In a Full Mgr/Agent association all functions must be supported. A conformant system must support at least one of these types. A system may play both the managing and the managed role, but not on the same association.

The negotiation uses the A-ASSOCIATE and A-RELEASE services, and the Application Context Name determines the requestor's role in the association and the type of the association. Seven Application Context Names are registered for CMOT and CMIP: one for backwards compatible negotiation with RFC 1095 implementations, and six for the manager and agent forms of the four association types.

The negotiation rules are these. A managed system may only request an Event association, and must create an Event association if it has an event to report and no suitable association already exists. Managing systems may request any association type. An association is created by the requesting system issuing an A-ASSOCIATE request with the requestor's AE-TITLE and the desired application context, and the responding system returns either an A-ASSOCIATE response with the requestor's AE-TITLE and the application context it wishes to accept, or an A-ASSOCIATE response rejecting the association. Managed systems may negotiate downward, from Full to Monitor/Control, Event/Monitor or Event, by returning the new application context in the A-ASSOCIATE response, and from Event/Monitor to Event. When a managing system receives an application context in an A-ASSOCIATE response that differs from the one it sent, it may proceed with the new context or refuse it by issuing an A-RELEASE request.

A-RELEASE is used when the requestor does not agree with the new context. A-ABORT is used for invalid negotiation, and if it were used to terminate an association there would be the potential for loss of information such as pending events or confirmations. A-ABORT must nevertheless be used when a protocol violation occurs or where an association is not yet established.

When a manager and a managed system connect, they agree how much they will do over that connection: only send alerts, also allow reading values, also allow changing them, or everything. The agreement is carried in a name that both sides recognise.

The four association types (RFC 1189, Section 4.1)
  • EventThe managed system may send M-EVENT-REPORTs. No other CMIP protocol data units are allowed.
  • Event/MonitorAs Event, and the managing system may also issue M-GET requests and receive M-GET responses.
  • Monitor/ControlThe managing system may issue M-GET, M-SET, M-CREATE, M-DELETE and M-ACTION requests. No event reporting is allowed.
  • Full Mgr/AgentAll functions must be supported.
The application context names registered for CMOT and CMIP (RFC 1189, Section 4.1)
Application context names
{iso(1) identified-organization(3) dod(6)
   internet(1) mgmt(2) mib(1) oim(9) acn(1)
   cmot1095(1)}
   (backwards compatible negotiation with RFC 1095 CMOT implementations)
{iso(1) identified-organization(3) dod(6)
   internet(1) mgmt(2) mib(1) oim(9) acn(1)
   manager-event-association(2)}
{iso(1) identified-organization(3) dod(6)
   internet(1) mgmt(2) mib(1) oim(9) acn(1)
   manager-event-monitor-association(3)}
{iso(1) identified-organization(3) dod(6)
   internet(1) mgmt(2) mib(1) oim(9) acn(1)
   manager-monitor-control-association(4)}
{iso(1) identified-organization(3) dod(6)
   internet(1) mgmt(2) mib(1) oim(9) acn(1)
   manager-full-association(5)}
{iso(1) identified-organization(3) dod(6)
   internet(1) mgmt(2) mib(1) oim(9) acn(1)
   agent-event-association(6)}

§5Agreements on CMIS and CMIP Services

The general agreements on users of CMIS are those in the OIW Stable Agreements, with additional agreements here. A system need only implement the services and service primitives required for the association types it supports. Current and Event times shall use 1 millisecond granularity. If the system generating the protocol data unit does not have the current time but does have the time since the last boot, GeneralizedTime can be used, with the time since last boot added to the base time 0001 Jan 1 00:00:00.00 using the Gregorian calendar algorithm, where all years have 365 days except those divisible by 4 and not by 400, which have 366. Using the year 1 as the base year prevents confusion with the current time. If no meaningful time is available, the year 0 shall be used in GeneralizedTime to indicate that fact.

The specific agreements on users of CMIS are those in the OIW Stable Agreements, with more here. Event time shall be mandatory for all events. Both the managed Object Class and managed Object Instance parameters must be present in the M-EVENT-REPORT Confirmed, M-GET, M-SET, M-ACTION, M-CREATE and M-DELETE service response and confirmation primitives.

The CMIS and CMIP implementers agreements in the OIW Stable Implementers Agreements, plus those mandated by the CMIP standard, are used for both CMOT and CMIP, with additional agreements: an implementation is required to support all filter items except subsetOf, supersetOf, nonNullSetIntersection and substrings; the managedObjectInstance field must be present in the ProcessingFailure Error protocol data unit; and the managedObjectClass field must be present in the NoSuchArgument Error protocol data unit.

The services required by CMIP are those in the OIW Stable Implementors Agreements, with more here. Application contexts shall be as defined in Section 4.1, and the values and defaults of parameters given to the presentation service are specified in RFC 1085 for CMOT and in the NIST Stable Implementers Agreements for CMIP. CMOT implementations shall be supported by the Lightweight Presentation Protocol, which may use either TCP or UDP; when UDP is used, an implementation need not accept LPP protocol data units whose length exceeds 484 octets. CMOT implementations will not require the session protocol.

The RFC also pins down small details that would otherwise differ between implementations: how times are written, which fields a reply must carry, and how long a message may be when it travels over UDP.

§8Security Considerations

The Security Considerations section of RFC 1189 says only that security issues are not discussed in this memo. The document defines protocol agreements and conformance requirements rather than behaviour, and it points to the ISO standards and the OIW Stable Agreements document for the rest.

This document has almost nothing to say about security. Its security section says only that security issues are not discussed here.

§7References