rfc1095.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   The Association Control Service Element (ACSE) is used to establish
   and release associations between application entities. Before any
   management operations can be performed using CMIP, it is necessary
   for the two application entities involved to form an association.
   Either the manager or the agent can initiate association
   establishment.  ACSE allows the manager and agent to exchange
   application entity titles for the purpose of identification and
   application context names to establish an application context. As
   stated above, an application context defines what service elements
   (for instance, ROSE and CMISE) may be used over the association.
   After the association is established, ACSE is not used again until
   the association is released by the manager or agent.

3.3.2.  ROSE

   The Remote Operation Service Element (ROSE) is the ISO equivalent of
   remote procedure call.  ROSE allows the invocation of an operation to
   be performed on a remote system.  The Remote Operation protocol
   contains an invoke identifier for correlating requests and responses,
   an operation code, and an argument field for parameters specific to
   the operation.  ROSE can only be invoked once an application
   association has been established.  CMIP uses the transaction-oriented
   services provided by ROSE for all its requests and responses.  CMIP
   also uses the error response facilities provided by ROSE.

3.3.3.  CMISE

   The Common Management Information Service Element (CMISE) is the
   service element that provides the basic management services.  The



Warrier & Besaw                                                [Page 10]

RFC 1095                          CMOT                        April 1989


   CMISE is a user of both ROSE and ACSE.  The CMISE provides both
   confirmed and unconfirmed services for reporting events and
   retrieving and manipulating management data. These services are used
   by manager and agent application entities to exchange management
   information.  Table 1 provides a list of the CMISE services.  In
   addition, the CMISE also provides the ability to issue a series of
   (multiple) linked replies in response to a single request.


           +-----------------+-------------------------+
           |    Service      |     Type                |
           +-----------------+-------------------------+
           |  M-INITIALISE   | confirmed               |
           |  M-TERMINATE    | confirmed               |
           |  M-ABORT        | non-confirmed           |
           |  M-EVENT-REPORT | confirmed/non-confirmed |
           |  M-GET          | confirmed               |
           |  M-SET          | confirmed/non-confirmed |
           |  M-ACTION       | confirmed/non-confirmed |
           |  M-CREATE       | confirmed               |
           |  M-DELETE       | confirmed               |
           +-----------------+-------------------------+

                Table 1.  CMISE Service Summary


   CMIS services can be divided into two main classes: management
   association services and information transfer services.  Furthermore,
   there are two types of information transfer services: management
   notification services and management operation services.  In addition
   to the other CMIS services, the CMISE provides facilities that enable
   multiple responses to confirmed operations to be linked to the
   operation by the use of a linked identification parameter.

3.3.3.1.  Management Association Services

   CMIS provides services for the establishment and release of
   application associations.  These services control the establishment
   and normal and abnormal release of a management association. These
   services are simply pass-throughs to ACSE.

   The M-INITIALISE service is invoked by a CMISE-service-user to
   establish an association with a remote CMISE-service-user for the
   purpose of exchanging management information. A reply is expected.
   (A CMISE-service-user is that part of an application process that
   makes use of the CMISE.)

   The M-TERMINATE service is invoked by a CMISE-service-user to release



Warrier & Besaw                                                [Page 11]

RFC 1095                          CMOT                        April 1989


   an association with a remote CMISE-service-user in an orderly manner.
   A reply is expected.

   The M-ABORT service is invoked by a CMISE-service-user or a CMISE-
   service-provider to release an association with a remote CMISE-
   service-user in an abrupt manner.

3.3.3.2.  Management Notification Services

   The definition of notification and the consequent behavior of the
   communicating entities is dependent upon the specification of the
   managed object which generated the notification and is outside the
   scope of CMIS.  CMIS provides the following service to convey
   management information applicable to notifications.

   The M-EVENT-REPORT service is invoked by a CMISE-service-user to
   report an event about a managed object to a remote CMISE-service-
   user.  The service may be requested in a confirmed or a non-confirmed
   mode.  In the confirmed mode, a reply is expected.

3.3.3.3.  Management Operation Services

   The definition of the operation and the consequent behavior of the
   communicating entities is dependent upon the specification of the
   managed object at which the operation is directed and is outside the
   scope of CMIS.  However, certain operations are used frequently
   within the scope of management and CMIS provides the following
   definitions of the common services that may be used to convey
   management information applicable to the operations.

   The M-GET service is invoked by a CMISE-service-user to request the
   retrieval of management information from a remote CMISE-service-user.
   The service may only be requested in a confirmed mode.  A reply is
   expected.

   The M-SET service is invoked by a CMISE-service-user to request the
   modification of management information by a remote CMISE-service-
   user.  The service may be requested in a confirmed or a non-confirmed
   mode.  In the confirmed mode, a reply is expected.

   The M-ACTION service is invoked by a CMISE-service-user to request a
   remote CMISE-service-user to perform an action.  The service may be
   requested in a confirmed or a non-confirmed mode.  In the confirmed
    mode, a reply is expected.

   The M-CREATE service is invoked by a CMISE-service-user to request a
   remote CMISE-service-user to create another instance of a managed
   object.  The service may only be requested in a confirmed mode.  A



Warrier & Besaw                                                [Page 12]

RFC 1095                          CMOT                        April 1989


   reply is expected.

   The M-DELETE service is invoked by a CMISE-service-user to request a
   remote CMISE-service-user to delete an instance of a managed object.
   The service may only be requested in a confirmed mode.  A reply is
   expected.

4.  The CMOT Architecture

   The CMOT (CMIP Over TCP/IP) architecture is based on the OSI
   management framework [15] and the models, services, and protocols
   developed by ISO for network management.  The CMOT architecture
   demonstrates how the OSI management framework can be applied to a
   TCP/IP environment and used to manage objects in a TCP/IP network.
   The use of ISO protocols for the management of widely deployed TCP/IP
   networks will facilitate the ultimate migration from TCP/IP to ISO
   protocols.  The concept of proxy management is introduced as a useful
   extension to the architecture.  Proxy management provides the ability
   to manage network elements that either are not addressable by means
   of an Internet address or use a network management protocol other
   than CMIP.

   The CMOT architecture specifies all the essential components of a
   network management architecture.  The OSI management framework and
   models are used as the foundation for network management.  A
   protocol-dependent interpretation of the Internet SMI [2] is used for
   defining management information.  The Internet MIB [3] provides an
   initial list of managed objects.  Finally, a means is defined for
   using ISO management services and protocols on top of TCP/IP
   transport protocols.  Management applications themselves are not
   included within the scope of the CMOT architecture.  What is
   currently standardized in this architecture is the minimum required
   for building an interoperable multivendor network management system.
   Applications are explicitly left as a competitive issue for network
   developers and providers.

4.1.  Management Models

   The following sections indicate how the CMOT architecture applies the
   OSI managements models and point out any limitations the CMOT
   architecture has as it is currently defined in this memo.

4.1.1.  The Organizational Model

   It is beyond the scope of this memo to define the relations and
   interactions between different management domains.  The current CMOT
   architecture concerns itself only with the operations and
   characteristics of a single domain of management.  The extension of



Warrier & Besaw                                                [Page 13]

RFC 1095                          CMOT                        April 1989


   the mechanisms defined here to include multiple domains is left for
   further study.

4.1.2.  The Functional Model

   The CMOT architecture provides the foundation for carrying out
   management in the five functional areas (fault, configuration,
   performance, accounting, and security), but does not address
   specifically how any of these types of management are accomplished.
   It is anticipated that most functional requirements can be satisfied
   by CMIS.  The greatest impact of the functional requirements in the
   various areas will likely be on the definition of managed objects.

4.1.3.  The Information Model

   There are two different SMI specifications that are important to the
   CMOT architecture. The first is the SMI currently being defined by
   ISO [19].  This SMI is important to the CMOT approach because the ISO
   management protocol CMIP has been designed with the ISO model of
   management information in mind.  The second SMI of importance is the
   that defined by the IETF MIB working group for use in defining the
   Internet MIB [3].  This Internet SMI, which is loosely based on a
   simplified version of the ISO SMI, is important because the managed
   objects defined for TCP/IP networks to be used by CMOT are defined in
   terms of it.  Thus, in order to make the CMOT architecture complete,
   it will be necessary to show how the Internet SMI maps into CMIP in
   such a way as to enable it to convey the management information
   defined in the Internet MIB.  This is done in the section devoted to
   management information (section 5).

4.2.  Protocol Architecture

   The objective of the CMOT protocol architecture is to map the OSI
   management protocol architecture into the TCP/IP environment.  The
   model presented here follows the OSI model at the application layer,
   while using Internet protocols at the transport layer.  The ISO
   application protocols used for network management are ACSE, ROSE, and
   CMIP.  Instead of implementing these protocols on top of the ISO
   presentation, session, and transport layer protocols, the protocol
   data units (PDUs) for ACSE, ROSE, and CMIP are carried using the
   Internet transport protocols UDP [20] and TCP [21].  This is made
   possible by means of the lightweight presentation protocol defined in
   RFC 1085 [13] that maps ROSE and ACSE onto TCP/UDP/IP.  The use of
   Internet transport protocols is transparent to network management
   applications, since they are presented with real ISO services.






Warrier & Besaw                                                [Page 14]

RFC 1095                          CMOT                        April 1989


4.2.1.  The Lightweight Presentation Layer