tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 1095


Common Management Information Services and Protocol over TCP/IP (CMOT)

Part 2 of 3, p. 18 to 48
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 18 
5.  Management Information

   The description of management information has two aspects.  First, a
   structure of management information (SMI) defines the logical
   structure of management information and how it is identified and
   described.  Second, the management information base (MIB), which is
   specified using the SMI, defines the actual objects to be managed.
   The purpose of this section is to show how CMIP is used in the CMOT
   architecture to convey information defined in the Internet MIB.

Top      Up      ToC       Page 19 
5.1.  The Structure of Management Information

   The SMI supplies the model for understanding management information,
   as well as templates and ASN.1 macros that can be used for defining
   actual management information.  The following sections discuss the
   ISO SMI, the Internet SMI, and a way of interpreting the Internet SMI
   in terms of the ISO SMI so that CMIP can be used to carry management
   information defined in terms of the Internet SMI.

5.1.1.  The ISO SMI

   The ISO SMI [19] is based on the abstraction of a "managed object"
   and the various kinds of relationships objects can be involved in.
   The following discussion does not purport to be a complete and
   accurate description of the latest ISO SMI work.  It is intended to
   be a clear presentation of the basic ISO SMI concepts essential for
   understanding the CMIP-specific interpretation of the Internet SMI
   presented in section 5.3.  Managed Objects and Attributes

   Management Information is modeled using object-oriented techniques.
   All "things" in the network that are to be managed are represented in
   terms of managed objects.  A "managed object" is an abstraction (or
   logical view) for the purposes of network management of a
   "manageable" physical or logical resource of the network.  In this
   context, "manageable" means that a particular resource can be managed
   by using CMIP.  Examples of managed objects are protocol entities,
   modems, and connections.

   Each managed object belongs to a particular object class.  An "object
   class" represents a collection of managed objects with the same, or
   similar, properties.  A particular managed object existing in a
   particular network is defined as an "object instance" of the object
   class to which it belongs.  Thus, an object instance represents an
   actual realization of an object class (i.e., a managed object of a
   particular class bound to specific values).  An example of an object
   class is "transport connection." In an actual network, there are a
   number of managed objects (specific transport connections) that are
   instances of this class.  In summary, a managed object type, which is
   called an "object class," is the collection of all actual and
   potential instances of that type.

   Managed objects are fully defined by specifying the "attributes" or
   properties the object has, the CMIS operations that can be performed
   on the object (e.g., M-SET, M-CREATE) and any constraints on those
   operations, specific actions (e.g., self-test) that can be performed
   on the object, events that the object can generate, and information

Top      Up      ToC       Page 20 
   about various relationships the object may be involved in.  All of
   this information relevant to a managed object is typically provided
   by filling in an object template.

   Managed objects contain properties that are referred to as
   attributes.  Attributes are atomic items of information that can only
   be manipulated as a whole.  An example of an attribute is a counter
   providing a specific piece of information, such as the number of
   packets retransmitted.

   Each object class and attribute is assigned a unique identifier (an
   ASN.1 OBJECT IDENTIFIER) for purposes of naming by a registration
   authority.  Management Information Hierarchies

   Managed objects participate in relationships with each other.  There
   are two relationships that are of particular importance for
   management information: the containment relationship and the
   inheritance relationship.  These relationships can be used to
   construct hierarchies of managed objects.  In addition, there is
   another hierarchy defined by the registration process for registering
   identifiers for object classes and attributes.  The Registration Hierarchy

   The registration hierarchy is determined by the ASN.1 registration
   tree [5] for assigning OBJECT IDENTIFIERs.  An OBJECT IDENTIFIER is
   an administratively assigned name composed of a series of integers
   traversing a path from the root of the ASN.1 registration tree to the
   node or leaf to be identified.  For example, the sequence of integers
   { iso(1) standard(0) ips-osi-mips(9596) cmip(2) } (1.0.9596.2) can be
   used to uniquely identify the CMIP standard.  Each node of this tree
   has an associated registration authority that determines how numbers
   in the subtree defined by that node are allocated.  In the context of
   management, these OBJECT IDENTIFIERs are used for identifying object
   classes and attributes.  The registration hierarchy is not based on
   any particular relationship between managed objects or between
   managed objects and their attributes.  It is independent of both the
   inheritance and containment relationships described below.  Its
   purpose is simply to generate universally unique identifiers.  The Containment Hierarchy

   The containment hierarchy is constructed by applying the relationship
   "is contained in" to objects and attributes.  Objects of one class
   may contain objects of the same or different class.  Objects may also
   contain attributes.  Attributes cannot contain objects or other

Top      Up      ToC       Page 21 
   attributes.  For example, objects of the class "transport entity" may
   contain objects of the class "transport connection"; an object of the
   class "management domain" may contain objects of the class "node." An
   object class that contains another object class is called the
   "superior" object class; an object class that is contained in another
   object class is called the "subordinate" object class.  The
   containment relationships that an object may participate in are part
   of the definition of the object class to which that managed object
   belongs.  All object classes (except the topmost) must have at least
   one possible superior in the containment tree.  The definition of a
   class may permit it to have more than one such superior.  However,
   individual instances of such a class are nevertheless contained in
   only one instance of a possible containing class.

   The containment hierarchy is important because it can be used for
   identifying instances of a managed object.  For example, assume there
   is an object class "domain" that contains an object class "node" that
   contains an object class "transport entity" that contains an object
   class "transport connection." A particular instance of a transport
   connection can be identified by the concatenation of "instance
   information" for each object class in the containment path: {
   domain="organization," node="herakles," transport entity=tp4,
   transport connection=<TSAP-AddressA, TSAP-AddressB> }.

   What constitutes appropriate "instance information" for each object
   class is part of the definition of that object class and is known as
   the "distinguished attribute(s)." A distinguished attribute is
   composed of an OBJECT IDENTIFIER naming the attribute and the value
   of the attribute.  For each object class, the distinguished
   attributes that differentiate instances of that class are
   collectively called the "relative distinguished name." A sequence of
   relative distinguished names (one for each class in the containment
   path) is the "distinguished name" of a managed object.  The example
   given above represents the distinguished name of a transport
   connection.  The containment hierarchy is sometimes referred to as
   the "naming tree", because it is used to "name" a particular instance
   of a managed object.

   The containment relationship also defines an existence dependency
   among its components; an object or attribute can "exist" only if the
   containing object also "exists." Deletion of an object may result in
   deletion of all objects and attributes contained within it.
   Alternately, depending on the definition of the managed object,
   deletion may be refused until all contained managed objects have been

Top      Up      ToC       Page 22  The Inheritance Hierarchy

   The inheritance hierarchy is constructed by applying the relationship
   "inherits properties of" to object classes.  An object class may
   inherit properties of another object class; refinement is obtained by
   adding additional properties.  In this relationship, the parent class
   is called the "superclass" and the inheriting class the "subclass."
   For example, the class "layer entity" may be a superclass of "network
   entity," which in turn is a superclass of "X.25 network entity."
   Attributes defined for "network entity" (e.g., the number of packets
   sent) are automatically defined for "X.25 network entity" without
   having to explicitly include them in the definition for the class
   "X.25 network entity." Thus, inheritance serves as a shorthand for
   defining object classes using object-oriented methodology.  Each
   class (except the topmost) has at least one superclass, but may have
   zero, one, or many subclasses.  Subclasses may in turn have further
   subclasses, to any degree.  A special object called "top" is the
   ultimate superclass.  It has no properties of its own.

   The inheritance hierarchy has no relevance to the naming of object
   instances.  It is useful only insofar as it leads to a manageable and
   extensible technique for the definition of object classes.

5.1.2.  The Internet SMI

   The Internet SMI [2] is designed to be a protocol-independent SMI
   that can be used with both SNMP and CMIP.  For this reason, it is
   necessary for any management protocol that uses this SMI to show how
   it is to be interpreted in a protocol-specific manner.  This is done
   for CMIP in this memo.

   The Internet SMI indicates both how to identify managed objects and
   how to define them.  The Internet SMI defines a registration subtree
   rooted at { iso(1) org(3) dod(6) internet(1) } for the sake of
   registering OBJECT IDENTIFIERs to be used for uniquely identifying
   managed objects.  The current Internet SMI specifies the format for
   defining objects in terms of an "object type" template and an
   associated OBJECT-TYPE ASN.1 macro.  An object type definition
   contains five fields: a textual name, along with its corresponding
   OBJECT IDENTIFIER; an ASN.1 syntax; a definition of the semantics of
   the object type; an access (read-only, read-write, write-only, or
   not-accessible); and a status (mandatory, optional, or obsolete).
   The current Internet SMI does not provide any mechanism for defining
   actions or events associated with a managed object.

   In describing management information, the current Internet SMI does
   not use the notions of "object class" and "attribute" found in the
   ISO SMI.  Only the concepts of "object type" and "object instance"

Top      Up      ToC       Page 23 
   are used.  The Internet SMI shows how to define object types; it
   leaves the specification of object instances as a protocol-specific
   matter.  The current Internet structure of management information is
   simpler and less rich than the corresponding ISO structure. The ISO
   SMI makes a distinction between simple "attributes," which can be
   viewed as "leaf objects" that are the lowest elements of the
   containment hierarchy, and composite "managed objects" that belong to
   an "object class" and have a structure associated with them (that is,
   can contain attributes).  The Internet SMI does not draw this
   distinction; both simple and composite "objects" are defined as
   "object types." What structure is associated with objects in the
   Internet SMI is defined through the deliberate attempt to structure
   the lower part of the Internet registration tree according to
   containment principles.  (Objects that are considered "attributes" of
   other containing objects are defined directly below them in the
   object registration tree.) This results in a certain lack of
   flexibility, since the registration hierarchy is implicitly used to
   define the containment hierarchy.  This means that the Internet SMI
   does not contain a mechanism for defining containment relationships
   that do not happen to coincide with the registration hierarchy.  In
   interpreting the Internet SMI for use with CMIP, it is necessary to
   overcome this limitation.

5.2.  The Management Information Base

   The Management Information Base (MIB) is a "conceptual repository of
   management information." It is an abstract view of all the objects in
   the network that can be managed.  Note that the MIB is conceptual in
   that it does not carry any implications whatsoever about the physical
   storage (main memory, files, databases, etc.) of management
   information.  The SMI provides the guidelines for defining objects
   contained in the MIB.

   The CMOT approach will use the Internet MIB based on the Internet SMI
   described above.  The first version of the Internet MIB, which is the
   product of the IETF MIB working group, is defined in RFC 1066 [3].
   It contains objects divided into eight groups: system, interfaces,
   address translation, IP, ICMP, TCP, UDP, and EGP.  In addition, the
   Internet SMI provides for future versions of the Internet MIB and a
   means for otherwise extending the MIB through the registration of
   managed objects under "private" and "experimental" branches of the
   object registration tree.  Appendix B provides a protocol-specific
   interpretation of the first version of the TCP/IP MIB defined in [3]
   so that it can be used with CMOT.  This interpretation is based on a
   straightforward mapping of the current Internet SMI to the ISO SMI
   (section 5.3).

   The initial version of the Internet MIB concentrates on defining

Top      Up      ToC       Page 24 
   objects associated with various Internet protocols.  It is expected
   that future versions of the Internet MIB and various extensions will
   provide a much richer set of objects to manage, including management
   information about a variety of network devices and systems.  Thus, an
   expanded MIB will allow wide-ranging and powerful management using
   the CMOT approach.

5.3.  An Interpretation of the Internet SMI

   In order to use CMIP to convey information defined in terms of the
   Internet SMI, it is necessary to show how object instances are
   specified and to provide the necessary structure for differentiating
   object class and attributes.  These objectives are both met by
   separating the containment hierarchy used for naming objects from the
   registration hierarchy and by imposing an "object class" structure on
   the Internet SMI.  Using the technique of imposing an object class
   structure does not replace or redefine the object definitions in the
   Internet MIB; it merely provides a necessary gloss or commentary on a
   MIB defined in terms of the Internet SMI.  For example, Appendix B
   references the "object type" definitions found in [3], but imposes
   additional structure on them.

   This object class definition derives from a simplified version of the
   OBJECT-CLASS macro defined in the ISO SMI [19].  The more complex
   definition is not needed for present purposes.  (The object class
   definition presented here could be extended in the future to show
   what actions and events are associated with a managed object.) The
   object class definition has the following fields:

      A textual name, termed the OBJECT CLASS DESCRIPTOR, for the object
      class, along with its corresponding OBJECT IDENTIFIER.

      A textual description of the object class.

   Subclass Of:
      The OBJECT CLASS DESCRIPTOR of the object class that is the
      superclass of this object class. This field is used for indicating
      the inheritance relationship.

      A list of OBJECT CLASS DESCRIPTORs of the possible superior object
      classes of this object class. This field is used for indicating
      the containment relationship.

Top      Up      ToC       Page 25 
      A list of OBJECT DESCRIPTORs identifying the OBJECT TYPES that are
      the distinguished attributes of this object class. (The OBJECT-
      TYPE macro is defined in RFC 1065). Attributes listed here will
      normally be present in the Attribute field of the object class
      definition.  This field is used for indicating what attributes
      must be present in the relative distinguished name that indicates
      an instance of this object class.

      A list of OBJECT DESCRIPTORs identifying the OBJECT TYPES that are
      attributes of this object class. (The OBJECT-TYPE macro is defined
      in RFC 1065). This field is used for indicating the attributes
      that are contained in this object class.

      This object class definition satisfies our objectives for
      interpreting the Internet SMI for use by CMIP.  The Attributes
      field shows what attributes are contained in this object class;
      this makes the necessary distinction between object classes and
      attributes required by CMIP.  Instead of referencing an
      "attribute" def inition (as is done in the ISO SMI), the
      Attributes field references the "object type" definition found in
      RFC 1065 and used to define the Internet-standard MIB in RFC 1066.
      The name, syntax, and access information required for attributes
      is contained in the "object type" definition.  Two things are
      required for specifying an instance of a managed object: a
      containment relationship determining a sequence of object classes
      and a means for specifying the distinguished attributes for an
      object class.  The Superiors field makes the containment
      relationship explicit; it is no longer merely a function of the
      registration tree.  The Names field makes it possible to indicate
      the distinguished attributes for an object class required for
      giving instance information.  Thus, the object class definition
      makes it possible to specify an object instance using CMIP.

5.3.1.  Object Class and Attributes

   The mapping of management information to the CMIS parameters Managed
   Object Class and Attribute Identifier List now becomes apparent.  Object Class

   The CMIS Managed Object Class parameter is the OBJECT IDENTIFIER
   assigned to the particular object class.  For example, the Managed
   Object Class for the object class "ip" (as defined in Appendix B) is

        { mib 4 } =

Top      Up      ToC       Page 26  Attribute Identifier

   The CMIS Attribute Identifier List parameter is a list of Attribute
   Identifiers.  An Attribute Identifier can be either global or local.
   If it is global, then it is the OBJECT IDENTIFIER assigned to the
   attribute (i.e., "object type") that is being indicated.  For
   example, the global Attribute Identifier for the attribute
   "ipForwarding" (as defined in [3]) is

        { ip 1 } =

   If the Attribute Identifier is local, it is an integer that is the
   last component in the OBJECT IDENTIFIER identifying the object.  For
   ipForwarding, the local Attribute Identifier is 1.  In the case where
   the local identifier is used, the leading components of the OBJECT
   IDENTIFIER for the attribute must be the OBJECT IDENTIFIER of the
   containing object class.  This is true for the interpreted Internet
   MIB defined in Appendix B, but may not be true generally.  The local
   identifier is intended to be interpreted relative to the Managed
   Object Class field of the CMIP PDU.  When a local Attribute
   Identifier is encountered in a CMIP PDU, the global form of the
   identifier is formed by prepending the OBJECT IDENTIFIER in the
   Managed Object Class field to the local identifier.  This is valid
   only when scoping is not used (i.e., scoping is "baseObject").  If
   scoping is used, then the global form of the Attribute Identifier
   must be used instead of the local form.

5.3.2.  Management Information Hierarchies

   The following sections show how the three management information
   hierarchies are to be understood for the interpreted Internet SMI.  The Registration Hierarchy

   The registration hierarchy is the global object registration tree
   described in [2].  It is used merely for assigning identifiers for
   object classes and attributes (i.e., "object types" in RFC 1065).  The Containment Hierarchy

   As described above, the containment hierarchy is used to specify an
   object instance.  The Names field of the object class definition
   contains the distinguished attributes for the object class.  The
   OBJECT IDENTIFIER naming the "attribute" together with its value is
   called an attribute value assertion.  A set of attribute value
   assertions (one for each distinguished attribute) is the relative
   distinguished name associated with that object class.  The sequence
   of relative distinguished names for each of the object classes in the

Top      Up      ToC       Page 27 
   containment hierarchy to which a managed object belongs is the
   distinguished name of the object.  An object instance is fully
   specified by a distinguished name.

   Let us take a concrete example from Appendix B.  How would we
   represent an instance of an entry in the IP routing table?  We begin
   by examining the object class in question (ipRouteEntry) and use the
   Superiors field to find the superior class in the containment
   hierarchy (ipRoutingTable).  This process continues until we
   construct the following containment path of object classes: system,
   ip, ipRoutingTable, ipRouteEntry.  Now for each of these object
   classes, we inspect the Names field to find the distinguished
   attribute for that object class.  If no Names field is present (as is
   the case for "ip" and "ipRoutingTable"), then no instance information
   is required at that level.  Both "system" and "ipRouteEntry" have
   Name fields to show what information is expected at that level.  With
   this information, we can construct the following distinguished name
   specifying an instance of an IP routing table entry:

                  baseManagedObjectInstance {
                     distinguishedName {
                        relativeDistinguishedName {    -- system
                           attributeValueAssertion {
                              attributeType { cmotSystemID }
                              attributeValue ""
                        relativeDistinguishedName {    -- ipRouteEntry
                           attributeValueAssertion {
                              attributeType { ipRouteDest }

   If the system instance information is not present, then it is assumed
   to be the system with which the management association is established
   (i.e., the system receiving the request).

   Note that the object instance tree can contain components of the
   distinguished name that are outside the managed system (node).  This
   enables referencing of objects across management domains (there could
   be an object class "domain") and across a collection of nodes.  In a
   network where several intermediate managers may be involved in a
   request, each intermediate manager can use the "system" portion of

Top      Up      ToC       Page 28 
   the name to determine where to send a request or result.  This
   technique of naming treats each intermediate managing system as a
   proxy manager.  The proxy manager resolves the address of the next
   node in the chain and may use a different protocol to transfer the
   request or result.  Thus, the "system" instance information can be
   used to name devices being managed by proxy.  The Inheritance Hierarchy

   The Internet SMI does not use the inheritance relationship. The
   "Subclass Of" field is present in the object class definition to show
   how the inheritance relationship would be represented and to allow
   for future extensibility.  It is not used for any of the object
   classes defined in Appendix B.

5.4.  Scoping, Filtering, and Synchronization

   Within some services, CMIS provides additional capabilities that are
   related to the SMI.  These are the scoping, filtering,
   synchronization, and linked-reply facilities.  The presence of these
   facilities are indicated by the Multiple Object Selection Functional
   Unit defined in CMIS [11].

   These facilities provide the manager with the ability to operate on a
   collection of managed objects, rather than a single object.  The
   selection of multiple objects occurs in two phases: scoping and
   filtering.  Scoping is used to identify the managed objects to which
   a filter is to be applied.  Then filtering is used to select a subset
   of managed objects that satisfy certain conditions.  If scoping is
   not used, only the "base" managed object indicated by the CMIS
   Managed Object Class parameter is implied.  An example of the use of
   scoping and filtering for selecting a particular managed object (a
   table entry) is given in one of the sample protocol exchanges found
   in Appendix C.

5.4.1.  Scoping

   Scoping is meant to be understood in terms of the containment
   hierarchy.  A position at a certain level of the containment tree is
   defined by the CMIS Managed Object Class parameter.  The CMIS Scope
   parameter is then interpreted relative to this "base" managed object
   (defined by both object class and object instance).  The Scope
   parameter can be used to select the base object alone, all managed
   objects in the entire subtree (of the containment tree) below the
   base object, or all managed objects in the "n"th level (n = 1, 2,
   3,...) below the base object.

Top      Up      ToC       Page 29 
5.4.2.  Filtering

   Within the objects selected as a result of the scope parameter, it is
   possible to further refine the selection of managed objects through
   the use of filtering.  Filtering provides the ability to select a
   subset of these objects based on conditions applied to attributes
   (e.g., IP routing table entries with the "ipRouteAge > 100") and
   logical operations (and, or, not).

5.4.3.  Synchronization

   When multiple managed objects have been selected using scoping and
   filtering, the question of synchronization across object instances
   (such as multiple IP routing table entries) arises.  The two possible
   choices are "best effort" and "atomic." If "best effort"
   synchronization is selected, the failure to apply an operation (e.g.,
   M-SET) to one instance of an object does not affect the effort to
   apply this operation to other instances of the object.  If "atomic"
   synchronization is selected, then the operation is either performed
   on all object instances selected or none.  The default
   synchronization is best effort.

5.4.4.  Linked Replies

   If the reply to a single request for a set of managed objects results
   in more than one managed object being returned, all of these managed
   objects cannot be returned together in a single CMIP response PDU.
   The reason for this is that the structure of the CMIP response PDU
   only has a single field for containing object instance information.
   Since each managed object has its own instance information, each
   managed object must be returned in a separate CMIP PDU.  In such a
   case, the CMIP Linked Reply PDU is used.  The Linked Reply PDU
   provides a means of associating each of the multiple replies with the
   original request that generated them.  Thus, a single CMIP Get
   Request PDU that uses scoping and filtering would result in zero or
   more CMIP Linked Reply PDUs being returned before a final CMIP Get
   Result PDU.

   A linked reply can also be used to segment a CMIP response pertaining
   to a single managed object.  This would only be necessary if UDP is
   being used as the underlying transport and it is not possible to
   return all the information requested about the managed object in a
   single response PDU subject to the size limitations described in
   section 10.2.

5.5.  Accessing Tables

   This section explains how to use the interpreted Internet SMI and MIB

Top      Up      ToC       Page 30 
   to access tables.

5.5.1.  Accessing Whole Tables

   A whole table is accessed by specifying the object class of the
   table, indicating a scoping level of one, and not providing an
   attribute identifier list. The CMIS standard [11] specifies that if
   the attribute identifier parameter is not present, then all attribute
   identifiers are assumed.  The following CMIS parameters would be used
   to return the entire TCP connection table:

        Object Class: { tcpConnTable }
        Object Instance: "empty" (unless proxy management is used)
        Scope: oneLevel(1)
        Filter: not present
        Attribute Identifier List: not present

   By scoping one level below "tcpConnTable," all managed objects of the
   class "tcpConnEntry" are selected.  (The object class "tcpConnEntry"
   is the only object class one level below the object class
   "tcpConnTable" in the containment hierarchy.) The absence of an
   attribute identifier list signals that all attributes of the managed
   object are to be returned (i.e., all fields of the TCP connection
   table entry).

   In reply to this request, each entry of the table will be returned in
   a separate CMIP PDU (either a Linked Reply PDU or a Get Result PDU).
   Each reply CMIP PDU will specify the Object Class "tcpConnEntry" and
   the appropriate Object Instance information for that entry, as well
   as an Attribute List giving the values of each of the fields of the
   table entry.

5.5.2.  Accessing Table Entries

   An entire table entry is accessed by specifying the object class of
   the table entry, providing a distinguished name specifying the
   instance of the table entry, and not providing an attribute
   identifier list. As seen above, the absence of the attribute
   identifier list parameter indicates that all attributes are assumed.
   The absence of a scope parameter indicates that the base managed
   object class is intended.  The following CMIS parameters would be
   used to return the entire IP routing table entry for which the field
   "ipRouteDest" has the value

        Object Class: { ipRouteEntry }
        Object Instance: { ipRouteDest, }
        Scope: not present
        Filter: not present

Top      Up      ToC       Page 31 
        Attribute Identifier List: not present

   The result is returned in a single CMIP Get Result PDU with an
   attribute list consisting of all of the attributes (i.e., fields) of
   the table entry and their corresponding values.

   If the object class field refers to a table entry and no instance
   information is provided to select a particular entry, then a
   "noSuchObjectInstance" CMIP error should be returned.

Top      Up      ToC       Page 32 
                       Part II: Protocol Agreements

6.  CMOT Protocol Overview

   This part of the document is a specification of the protocols of the
   CMOT 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 the CMOT 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 CMOT 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 TCP/IP-based internets.

   In addition to the Netman working group, there are at least two other
   bodies actively engaged in defining profiles for interoperable OSI
   network management: the National Institute of Science and Technology
   (NIST) Network Management Special Interest Group (NMSIG) and the OSI
   Network Management Forum.  Both of these groups are similar to the
   Netman 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 of underlying ISO protocols, while the Netman
   working group is concerned with using OSI management in TCP/IP
   networks.  In the interest of greater future compatibility, the
   Netman working group has attempted to make the CMOT profile conform
   as closely as possible to the ongoing work of these two bodies.

6.1.  The CMOT Protocol Suite

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

Top      Up      ToC       Page 33 
                 |       Management Application Processes       |

                             |       CMISE       |
                             | ISO DIS 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

6.2.  Conformance Requirements

   A CMOT-conformant system must implement the following protocols:
   ACSE, ROSE, CMIP, LPP, and IP.  A 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 conformant system
   need not support all CMIS operations.  A conformant system must,
   however, support at least one of the functional unit groups
   (indicating a set of supported services) defined in section 7.1.3.
   The service and protocol selections are described in greater detail
   in the following sections.

6.3.  Abstract Syntax Notation

   The abstract syntax notation for all of the application service
   elements of the CMOT protocol suite is Abstract Syntax Notation One
   (ASN.1) [5].  The LPP is also defined using ASN.1.  The basic

Top      Up      ToC       Page 34 
   encoding rules used for ASN.1 are specified in [6].  Both definite-
   length and indefinite-length encodings are expressly permitted.

7.  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 DIS
   9595-2 [11].  The protocol specification for the Common Management
   Information Protocol (CMIP) is found in ISO DIS 9596-2 [12].

7.1.  CMIS Services

7.1.1.  CMIS Services Overview

   All of the CMIS services listed in Table 1 are allowed with the CMOT
   M-SET, M-ACTION, M-CREATE, and M-DELETE.  The specific services
   supported by a system will be determined by the functional unit group
   or groups to which a system belongs.

7.1.2.  Functional Units

   The CMIS services supported are designated in terms of functional
   units [11].  Each functional unit corresponds to the invoker or
   performer aspect of a particular service.  (The terms "invoker" and
   "performer" are taken from ROSE and refer to the caller of and
   responder to a remote operation, respectively.) The "stand alone"
   functional units associated with each of the management services are
   given in Table 2 as functional units 0-17.  The number following the
   name of each functional unit in the table is defined by CMIP [12] to
   identify that particular functional unit.  The functional units are
   used by the CMISE-service-user at the time of association
   establishment to indicate which services it is willing to support.

Top      Up      ToC       Page 35 
   | Functional Unit                 | Service Primitives     | Mode |
   | conf. event report invoker(0)   | M-EVENT-REPORT Req/Conf| C    |
   | conf. event report performer(1) | M-EVENT-REPORT Ind/Rsp | C    |
   | event report invoker(2)         | M-EVENT-REPORT Req     | U    |
   | event report performer(3)       | M-EVENT-REPORT Ind     | U    |
   | confirmed get invoker(4)        | M-GET Req/Conf         | N/A  |
   | confirmed get performer(5)      | M-GET Ind/Rsp          | N/A  |
   | confirmed set invoker(6)        | M-SET Req/Conf         | C    |
   | confirmed set performer(7)      | M-SET Ind/Rsp          | C    |
   | set invoker(8)                  | M-SET Req              | U    |
   | set performer(9)                | M-SET Ind              | U    |
   | confirmed action invoker(10)    | M-ACTION Req/Conf      | C    |
   | confirmed action performer(11)  | M-ACTION Ind/Rsp       | C    |
   | action invoker(12)              | M-ACTION Req           | U    |
   | action performer(13)            | M-ACTION Ind           | U    |
   | confirmed create invoker(14)    | M-CREATE Req/Conf      | N/A  |
   | confirmed create performer(15)  | M-CREATE Ind/Rsp       | N/A  |
   | confirmed delete invoker(16)    | M-DELETE Req/Conf      | N/A  |
   | confirmed delete performer(17)  | M-DELETE Ind/Rsp       | N/A  |
   | multiple reply(18)              | Linked Identification  | N/A  |
   | multiple object selection(19)   | Scope, Filter, Sync.   | N/A  |
   | extended service(20)            | Extended Presentation  | N/A  |
    C = confirmed, U = non-confirmed, N/A = not applicable

                          Table 2.  Functional Units

   In addition to the stand alone functional units, there are three
   additional functional units.  If any of these additional functional
   units are selected, then at least one of the stand alone functional
   units must be selected.  The multiple reply functional unit makes
   available the use of the linked identification parameter in the
   selected stand alone functional units.  This makes possible the use
   of linked reply (multiple CMIP PDU responses to a single request).
   The multiple object selection functional unit makes available the use
   of the scope, filter, and synchronization parameters in the selected
   stand alone functional units.  If the multiple object selection
   functional unit is selected, then the multiple reply functional unit
   must also be selected.  The extended services functional unit makes
   available presentation layer services in addition to the P-DATA
   service.  Selecting this functional unit has no effect in the context
   of CMOT, since the lightweight presentation layer provides only
   minimal ISO presentation services.

Top      Up      ToC       Page 36 
7.1.3.  Functional Unit Groups

   In order to assist in the reduction of code size and complexity for
   different types of devices, a number of "functional unit groups" have
   been defined.  Each of these groups indicates a set of services
   defined for either a manager or an agent.  The "negotiation"
   concerning which functional unit groups are supported is done by
   means of the Functional Units parameter of the M-INITIALISE service
   (see section  There are five functional unit groups for
   managers: Event Monitor, Monitoring Manager, Simple Manager,
   Controlling Manager, and Full Manager.  Each functional unit group is
   a superset of the preceding group.  There are five functional unit
   groups for agents: Event Sender, Monitored Agent, Simple Agent,
   Controlled Agent, and Full Agent.  Again, each functional unit group
   is a superset of the preceding group.  The operations supported for
   each functional unit group are summarized in Table 3.

   |                    |Event | Get | Set |Create/|Action|Mult.|Mult. |
   |Functional Unit     |Report|     |     |Delete |      |Reply|Object|
   |Groups              |      |     |     |       |      |     |Select|
   | 1. Event Monitor   | U    | no  | no  | no    | no   | no  | no   |
   | 2. Event Sender    | U    | no  | no  | no    | no   | no  | no   |
   | 3. Monitoring Mgr. | U    | yes | no  | no    | no   | no  | no   |
   | 4. Monitored Agent | U    | yes | no  | no    | no   | no  | no   |
   | 5. Simple Manager  | U    | yes | C   | no    | no   | yes | no*  |
   | 6. Simple Agent    | U    | yes | C   | no    | no   | yes | no*  |
   | 7. Controlling Mgr.| U    | yes | U/C | yes   | no   | yes | yes  |
   | 8. Controlled Agent| U    | yes | U/C | yes   | no   | yes | yes  |
   | 9. Full Manager    | U/C  | yes | U/C | yes   | U/C  | yes | yes  |
   |10. Full Agent      | U/C  | yes | U/C | yes   | U/C  | yes | yes  |
    C = confirmed, U = non-confirmed
    * Simple Managers and Agents must support "oneLevel" scoping for all
      and only those cases where it is required to access a whole table
      and may support synchronization other than "best effort"; no support
      for filtering is required.

                       Table 3.  Functional Unit Groups

   A conformant system must support at least one of these functional
   unit groups.  A system may support both a manager group and an agent
   group.  A system only needs to implement the services and service
   primitives required for the groups that it supports.  In addition, a
   system may support services that are not required by any group that

Top      Up      ToC       Page 37 
   it supports.

7.1.4.  M-INITIALISE Parameters

   The M-INITIALISE service is provided by the ACSE A-ASSOCIATE service.
   The parameters for the M-INITIALISE service are defined in [11] and
   summarized in Table 4.

                 | Parameter Name    | Req/Ind   | Rsp/Conf  |
                 | Functional Units  | Mandatory | Mandatory |
                 | User Information  | Optional  | Optional  |
                 | Access Control    | Optional  | Optional  |

                       Table 4. M-INITIALISE Parameters

   Notice that the further agreement has been made that the Functional
   Units parameter is mandatory at all times.  The M-INITIALISE
   parameters are conveyed as ACSE user information in the ACSE request
   PDU.  Functional Units

   The exchange of functional units between the initiating CMISE-
   service-user and the responding CMISE-service-user is required.  This
   allows the CMIS-service-users to inform each other which functional
   units are supported.  CMIP [12] defines a 21-bit BIT STRING to
   communicate which functional units are supported.  A functional unit
   is supported if the corresponding bit in this bit string is one.  The
   correspondence between functional units and functional unit groups is
   given in Table 5.  The left column gives the functional unit
   corresponding to a particular bit position. The numbers along the top
   of the table indicate the functional unit group (the numbers of the
   functional unit groups are given in Table 3).  The various columns
   indicate the value of each bit for a particular functional unit

Top      Up      ToC       Page 38 
|Functional Unit               | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10|
|conf. event report invoker(0) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
|conf. event report perf.(1)   | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
|event report invoker(2)       | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 |
|event report performer(3)     | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 |
|confirmed get invoker(4)      | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 |
|confirmed get performer(5)    | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 |
|confirmed set invoker(6)      | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 |
|confirmed set performer(7)    | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 1 |
|set invoker(8)                | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 |
|set performer(9)              | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 |
|confirmed action invoker(10)  | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
|confirmed action performer(11)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
|action invoker(12)            | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
|action performer(13)          | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
|confirmed create invoker(14)  | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 |
|confirmed create performer(15)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 |
|confirmed delete invoker(16)  | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 |
|confirmed delete performer(17)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 |
|multiple reply(18)            | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 |
|multiple object selection(19) | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 |
|extended service(20)          | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|                              | M | A | M | A | M | A | M | A | M | A |
        1 = supported, 0 = not supported, M = manager, A = agent

                     Table 5.  Functional Unit Group Values

   The "negotiation" using functional units proceeds as follows.  The
   initiating CMISE-service-user (manager or agent) sends the functional
   units representing the functional unit group to which it belongs.
   The responding CMISE-service-user sends the functional units
   representing the functional unit group to which it belongs.  (If an
   application process belongs to both a manager and an agent functional
   unit group, then both functional unit groups are indicated using the
   same functional unit bit string.) If the functional unit groups
   supported by the two application entities do not allow meaningful
   communication, then either entity may refuse the association.
   Meaningful communication is defined as the ability of the entity to
   invoke or perform at least one CMIS operation supported by the other
   entity (i.e., some "complementary" set of functional units exists).
   After an association has been established, a system must provide the
   proper response for functional units that it has indicated it can
   support and should gracefully refuse other requests in accordance

Top      Up      ToC       Page 39 
   with the protocol.  User Information

   The User Information parameter is optional.  No entity is required to
   send this parameter, but all entities are expected to tolerate
   receipt of it.

   One possible use of the User Information parameter is to convey
   information describing MIB extensions supported by the manager or
   agent.  This can be viewed as a further way of refining the
   application context.  The mechanism for doing this is not defined at
   this time.  Access Control

   The CMIS M-INITIALISE Access Control parameter is optional.  Access
   control is supported on a per association basis using ACSE.  It is
   recommended (but not required) that the access control parameter be
   used for each A-ASSOCIATE request (via M-INITIALISE).

   Access control is also possible on a per request basis with the CMIS
   Access Control parameter. This parameter might be used to implement
   security similar to the community access rights mechanism provided by
   SNMP [4].  It is expected that the Access Control parameter will be
   used to implement the standard TCP/IP authentication mechanism once
   this has been defined.

7.2.  Supporting Services

   The M-INITIALISE, M-TERMINATE, and M-ABORT services assume the use of
   ACSE.  The following ACSE services are required: 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.

7.3.  CMIP Agreements

   The following sections contain specific CMIP agreements in addition
   to those specified in the CMIP standard [12].

7.3.1.  Invoke Identifier

   It is required that there be a unique invoke identifier (present in
   the ROSE PDU) for successive invocations on the same association.
   The invoke identifier is provided by the invoking CMISE-service-user.
   Invoke identifiers should increase monotonically during the lifetime
   of an association.  Semantically, the invoke identifier is a Counter
   as defined in [2].  Unique identifiers will allow the detection of

Top      Up      ToC       Page 40 
   lost and duplicate requests.

7.3.2.  Object Class

   The object class field of all CMIP PDUs shall be limited to the
   "globalForm" choice:

           ObjectClass ::=
                CHOICE {
                     globalForm    [0] IMPLICIT OBJECT IDENTIFIER

7.3.3.  Object Instance

   The object instance field of all CMIP PDUs is limited to the
   "distinguishedName" choice:

           ObjectInstance ::=
                CHOICE {
                     distinguishedName  [2] IMPLICIT DistinguishedName

   The definition for DistinguishedName is imported from CCITT X.500 and
   ISO DIS 9594-2 [26]:

   DistinguishedName ::= RDNSequence
   RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
   RelativeDistinguishedName ::= SET OF AttributeValueAssertion

   The definition for AttributeValueAssertion is contained in CMIP [12]:

   AttributeValueAssertion ::= SEQUENCE { AttributeId, AttributeValue }
   AttributeId ::=
        CHOICE {
              globalId   [0] IMPLICIT OBJECT IDENTIFIER
              localId    [1] IMPLICIT INTEGER
   AttributeValue ::= ANY DEFINED BY attributeId

   Those attributes to be used as the distinguished attributes of a
   managed object are defined at the time of registration of the object
   class and are identified in the NAMES clause of the OBJECT-CLASS

Top      Up      ToC       Page 41 
   When there is no instance information to convey about a managed
   object, then the following "empty" object instance shall be used: The
   "distinguishedName" choice of ObjectInstance shall be an RDNSequence
   consisting of a SEQUENCE of one RelativeDistinguishedName. That
   RelativeDistinguishedName shall be an empty SET of

7.3.4.  Access Control

   The access control parameter is optional.  The receipt of this
   parameter must be tolerated (i.e., gracefully accepted), but a
   receiving entity is free to ignore this information.  The Access
   Control field is defined in [12] as EXTERNAL.  Until a more
   sophisticated access control mechanism is defined, simple
   authentication can be accomplished by using an unencrypted password
   in the access control field.  The definition of this EXTERNAL is the
   same as that for the ACSE Access Control field (section 8.3.2).

7.3.5.  Synchronization

   Support for "best effort" synchronization is required.  Atomic
   synchronization may also be supported, but is not required.

7.3.6.  Scope

   Scoping is supported if the multiple object selection functional unit
   is selected.  If scoping is supported, all values of the scope field
   shall be supported.

7.3.7.  Filter

   Filtering is supported if the multiple object selection functional
   unit is selected.  If filtering is supported, it is not required that
   all features of filtering be supported.  The following are the
   minimal filtering requirements for any system that supports
   filtering.  In the CMIP field CMISFilter, at least two instances of
   the binary operators ("and," "or") must be supported.  Support for
   additional instances of these operators is not required.  Double
   "not" need not be supported.  In FilterItem, the arithmetic
   operations ("equality", "greaterOrEqual," "lessOrEqual") must be
   supported.  The "present" choice of FilterItem must also be
   supported.  It is not required to support string operations (namely,
   the "substrings" choice of the FilterItem type).  Thus, the minimal
   requirements for filtering yield this restricted definition of

Top      Up      ToC       Page 42 
              FilterItem ::=
                   CHOICE {
                        equality       [0] AttributeValueAssertion,
                        greaterOrEqual [2] AttributeValueAssertion,
                        lessOrEqual    [3] AttributeValueAssertion,
                        present        [4] AttributeID

7.3.8.  Attribute Identifier

   Both choices for the CMIP AttributeId field are allowed:

              AttributeId ::=
                   CHOICE {
                        globalId  [0] IMPLICIT OBJECT IDENTIFIER,
                        localId   [1] IMPLICIT INTEGER

   The "globalId" form of AttributeId is required if scoping is used
   (i.e., the value of the scope field is other than "baseObject").

7.3.9.  Event Type Identifier

   Both choices for the CMIP EventTypeId field are allowed:

              EventTypeId ::=
                   CHOICE {
                        globalId  [6] IMPLICIT OBJECT IDENTIFIER,
                        localId   [7] IMPLICIT INTEGER

7.3.10.  Action Type Identifier

   Both choices for the CMIP ActionTypeId field are allowed:

              ActionTypeId ::=
                   CHOICE {
                        globalId  [2] IMPLICIT OBJECT IDENTIFIER,
                        localId   [3] IMPLICIT INTEGER

Top      Up      ToC       Page 43 
   The "globalId" form of ActionTypeId is required if scoping is used
   (i.e., the value of the scope field is other than "baseObject").

7.3.11.  Time Fields

   The "eventTime" field of the m-EventReport Invoke PDU and the m-
   EventConfirmedReport Invoke PDU must be present.

   The "currentTime" field of the following PDUs must be present: the
   m-EventReport Confirmed Result PDU, the m-Get Result PDU, the m-Set
   Result PDU, the m-Action Confirmed Result PDU, the m-Create Result
   PDU, the m-Delete Result PDU, the GetListError Error PDU, and the
   SetListError Error PDU.

   All CMIP time fields shall use the ASN.1 GeneralizedTime type defined
   in [5] with 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.

7.3.12.  Response PDUs

   Both the "managedObjectClass" and "managedObjectInstance" fields must
   be present in the following CMIP response PDUs: the m-EventReport
   Confirmed Result PDU, the m-Get Result PDU, the m-Set Result PDU, the
   m-Action Confirmed Result PDU, the m-Create Result PDU, the m-Delete
   Result PDU, the GetListError Error PDU, and the SetListError Error
   PDU.  The "managedObjectInstance" field must be present in the
   ProcessingFailure Error PDU.  The "managedObjectClass" field must be
   present in the NoSuchArgument Error PDU.

7.3.13.  Error PDUs

   The "globalId" form of AttributeId is required for the
   NoSuchAttributeId Error PDU and the InvalidAttributeValue Error PDU.

8.  Association Control Service Element

   The Association Control Service Element (ACSE), which is necessary

Top      Up      ToC       Page 44 
   for establishing and releasing application associations, is defined
   in [7] and [8].

8.1.  ACSE Services

   The ACSE service description is detailed in ISO 8649 [7].  All of the
   defined ACSE services are mandatory:

       o  A-ASSOCIATE: This confirmed service is used to initiate an
          application association between application entities.

       o  A-RELEASE: This confirmed service is used to release an
          application association between application entities without
          loss of information.

       o  A-ABORT: This unconfirmed service causes the abnormal release
          of an association with a possible loss of information.

       o  A-P-ABORT: This provider-initiated service indicates the
          abnormal release of an application association by the
          underlying presentation service with a possible loss of

   Mappings of the ACSE services to presentation services and ACSE APDUs
   are shown in Table 6, along with a section reference to ISO 8649 [7].

      |    ACSE     |  ISO 8649  |        Related       |  Associated |
      |   Service   |  Reference | Presentation Service |    APDUs    |
      | A-ASSOCIATE |     9.1    |       P-CONNECT      | AARQ, AARE  |
      | A-RELEASE   |     9.2    |       P-RELEASE      | RLRQ, RLRE  |
      | A-ABORT     |     9.3    |       P-U-ABORT      | ABRT        |
      | A-P-ABORT   |     9.4    |       P-P-ABORT      | (none)      |

                     Table 6.  Mapping of ACSE Services

8.2.  Supporting Services

   ACSE will make use of the following ISO presentation layer services:
   P-CONNECT, P-RELEASE, P-U-ABORT, and P-P-ABORT.  These presentation
   services will be provided by the LPP [13].

Top      Up      ToC       Page 45 
8.3.  ACSE Protocol

   The ACSE protocol specification is found in ISO 8650 [8]. All five
   ACSE APDUs specified in the standard are mandatory.

8.3.1.  Application Context Name

   The Application Context Name takes the form of an OBJECT IDENTIFIER.
   The value of this OBJECT IDENTIFIER includes both the version of CMOT
   being used for this association and the version number of the highest
   version of the Internet-standard MIB supported by the manager or
    agent.  The application context name has the following generic form:

                 { iso(1) org(3) dod(6) internet(1) mgmt(2) mib(n)
                   cmot(9) cmotVersion(1) version-number(v) }

                 where n = highest MIB version supported and
                       v = version of CMOT supported

   For the version of CMOT defined in these agreements, "version-number"
   has the value of one (1). This version of CMOT implies the versions
   of the ISO protocols specified in this memo (see Figure 2).

8.3.2.  User Information

   The following CMIS M-INITIALISE parameters are all mapped onto the
   ACSE User Information parameter: Functional Units, User Information,
   and Access Control.  (See section 7.1.4 for more information on the
   CMIS M-INITIALISE parameters.) ACSE User Information is defined in
   ISO 8650 as follows:

              Association-information ::= SEQUENCE OF EXTERNAL

   The ASN.1 defined type EXTERNAL, which is defined in section 35 of
   ISO 8824 [5], requires both an OBJECT IDENTIFIER for identification
   and an associated ASN.1 encoding.

   The OBJECT IDENTIFIER and syntax associated with the ACSE Functional
   Units EXTERNAL definition are found in [12]. The OBJECT IDENTIFIER is
   defined as { iso(1) standard(0) ips-osi-mips(9596) cmip(2) version(1)
   acse(0) functional-units(0) } and the syntax is a BIT STRING.

   The EXTERNAL definition for User Information is left unspecified at
   this time; it will be defined in a future memo.

   If some form of access control is required, a simple unencrypted

Top      Up      ToC       Page 46 
   password can be used.  The EXTERNAL for this simple access control
   will use the OBJECT IDENTIFIER { cmotAcseAccessControl } (Appendix A)
   and the syntax OCTET STRING. A more sophisticated authentication
   mechanism will be defined with another EXTERNAL definition in a
   future memo.

8.3.3.  Presentation Service Parameters

   The values and defaults of parameters to the ACSE primitives that are
   given to the presentation service are specified in RFC 1085 [13].

   For the Presentation Context Definition List parameter to the P-
   CONNECT service [13, p. 10], the value of the Abstract Syntax Name
   associated with the Presentation Context Identifier of value one (1)
   shall be identical to the OBJECT IDENTIFIER used for the Application
   Context Name (section 8.3.1).

   The Quality of Service parameter shall have the value of either
   "tcp-based" or "udp-based."

9.  Remote Operations Service Element

   The Remote Operations Service Element (ROSE), which provides the
   ability to invoke remote operations, is specified in ISO 9072-1 [9]
   and 9072-2 [10].  ROSE can only be used once an association has been
   established between two application entities.  ROSE is used to
   support CMISE; it is not intended to be used directly by management
   application processes.

9.1.   ROSE Services

   The ROSE service definition is detailed in ISO 9072-1 [9].  All of
   the defined ROSE services are mandatory:

       o  RO-INVOKE: This unconfirmed service is used by an invoking
          ROSE-user to cause the invocation of an operation to be
          performed by an invoked ROSE-user.

       o  RO-RESULT: This unconfirmed service is used by an invoked
          ROSE-user to reply to a previous RO-INVOKE indication in the
          case of a successfully performed operation.

       o  RO-ERROR: This unconfirmed service is used by an invoked
          ROSE-user to reply to a previous RO-INVOKE indication in the
          case of an unsuccessfully performed operation.

       o  RO-REJECT-U: This unconfirmed service is used by a ROSE-user
          to reject a request (RO-INVOKE indication) of the other

Top      Up      ToC       Page 47 
          ROSE-user if it has detected a problem.  It may also be used
          by a ROSE-user to (optionally) reject a reply (RO-RESULT
          indication, RO-ERROR indication) from the other ROSE-user.

       o  RO-REJECT-P: This provider-initiated service is used to advise
          a ROSE-user of a problem detected by the ROSE-provider.

   Mappings of ROSE services to ISO presentation services and ROSE APDUs
   are shown in Table 7, along with a section reference to ISO 9072-1

      |    ROSE     | ISO 9072-1 |        Related       |  Associated |
      |   Service   | Reference  | Presentation Service |    APDUs    |
      | RO-INVOKE   |    10.1    |        P-DATA        |    ROIV     |
      | RO-RESULT   |    10.2    |        P-DATA        |    RORS     |
      | RO-ERROR    |    10.3    |        P-DATA        |    ROER     |
      | RO-REJECT-U |    10.4    |        P-DATA        |    RORJ     |
      | RO-REJECT-P |    10.5    |        P-DATA        |    RORJ     |

   Table 7.  Mapping of ROSE Services

9.2.  Supporting Services

   ROSE will only make use of the presentation layer service P-DATA.
   This service is provided by the LPP.  The following restrictions are
   a consequence of the use of the LPP: First, mappings to the Reliable
   Transfer Service Element (RTSE) are not possible, since no RTSE is
   present.  Second, no data token is used with the presentation

9.3.  ROSE Protocol

   The protocol specification for ROSE shall follow ISO 9072-2 [10].
   All four APDUs specified in the standard are mandatory.  In addition,
   the ability to support the correct origination and reception of the
   linked-id protocol element is required if the multiple reply
   functional unit has been selected (section 7.1.2).

9.3.1.  Operation Class

   Since no turn management is required by ROSE, the Operation Class
   parameter may be ignored.

Top      Up      ToC       Page 48 
9.3.2.  Priority

   ROSE will deliver each APDU in a "first in, first out" manner.  Since
   no turn management is required by ROSE, the Priority parameter may be

(page 48 continued on part 3)

Next RFC Part