rfc1095.txt

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

   Given that it is desired to put ISO application protocols on top of
   TCP/IP, how is this best accomplished?  It is necessary somehow to
   fill the "gap" between the ISO protocols (ACSE and ROSE) and the
   Internet protocols (UDP and TCP).  Two basic approaches were
   considered.

   One possible approach [23] is to extend the ISO portion of the
   protocol stack down to the transport layer.  The ISO Transport
   Protocol Class 0 (TP 0) then uses TCP instead of an ISO network
   protocol.  Effectively, this treats TCP as a reliable network
   connection analogous to X.25.  This approach allows us to operate
   "standard" ISO applications over TCP regardless of their service
   requirements, since all ISO services are provided.  In this case,
   network management is just another such application.  The major
   drawback with this approach is that full ISO presentation, session,
   and transport layers are expensive to implement (both in terms of
   processing time and memory).

   Another approach is presented in RFC 1085.  Since the service
   elements required for network management (ACSE, ROSE, CMISE) do not
   require the use of full ISO presentation layer services, it is
   possible to define a "streamlined" presentation layer that provides
   only the services required.  This lightweight presentation protocol
   (LPP) allows the use of ISO presentation services over both TCP and
   UDP.  This approach eliminates the necessity of implementing ISO
   presentation, session, and transport protocols for the sake of doing
   ISO network management in a TCP/IP environment.  This minimal
   approach is justified because this non-ISO presentation protocol used
   is very small and very simple.  Thus, the LPP defined in RFC 1085
   provides a compact and easy to implement solution to the problem.
   The resulting CMOT protocol stack is shown in Figure 1.


















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


                   Manager                              Agent
           +-----------------------+           +-----------------------+
           |                       |           |                       |
           | +----+ +----+ +-----+ | <-------> | +----+ +----+ +-----+ |
           | |ACSE| |ROSE| |CMISE| |    CMIP   | |ACSE| |ROSE| |CMISE| |
           | +----+ +----+ +-----+ |           | +----+ +----+ +-----+ |
           |                       |           |                       |
           +-----------------------+           +-----------------------+
           |         LPP           |           |         LPP           |
           +-----------------------+           +-----------------------+
           |   TCP    |    UDP     |           |   TCP    |   UDP      |
           +-----------------------+           +-----------------------+
           |         IP            |           |         IP            |
           +-----------------------+           +-----------------------+
           |         Link          |           |         Link          |
           +-----------------------+           +-----------------------+
                      |                                   |
                      |                                   |
                      |                                   |
           =========================================================
                                  Network
           =========================================================

                     Figure 1.  The CMOT Protocol Architecture


   It is important to note that the presentation services provided by
   the LPP are "real" (but minimal) ISO presentation services [24].
   This provides a clear migration path to "full ISO" in the future.
   Such a migration would be accomplished by substituting ISO protocols
   for the Internet protocols TCP, UDP, and IP [25], and replacing the
   LPP with ISO presentation and session protocols.  No changes will be
   required in the ISO application layer protocols.  For this reason,
   investments in application development will be well preserved.

4.2.2.  The Quality of Transport Service

   The quality of transport service needed for network management
   applications is an issue that has caused much controversy, yet it has
   never been resolved.  There are two basic approaches: datagram-
   oriented and connection-oriented.  There are advantages and
   disadvantages to both of these two approaches. While the datagram-
   oriented approach is simple, requires minimal code space, and can
   operate under conditions where connections may not be possible, the
   connection-oriented approach offers data reliability and provides
   guaranteed and consistent service to the driving application.

   This memo does not take sides on this issue.  Rather it passes such



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


   resolution to the network management applications, which are
   ultimately the point where the requirements from the underlying
   service need to be determined.  As such, the CMOT protocol
   architecture provides both services.  The presentation layer service
   allows the application to select either high or low quality service
   for the underlying transport.  Depending on this choice, the LPP will
   use either UDP (low quality) or TCP (high quality) to establish the
   application association and carry the application data.  It is
   important, however, for the application to be aware of the quality of
   service that it is using: low quality means low quality!  The use of
   an unreliable transport like UDP necessarily puts more burden on the
   application.

4.3.  Proxy Management

   Proxy is a term that originated in the legal community to indicate an
   entity empowered to perform actions on behalf of another.  In our
   context, a proxy is a manager empowered to perform actions on behalf
   of another manager.  This may be necessary because the manager cannot
   communicate directly with the managed devices either for security or
   other administrative reasons or because of incompatible communication
   mechanisms or protocols.  In either case, the proxy assumes the agent
   role with respect to the requesting manager and the manager role with
   respect to the managed device.

   Some network elements, such as modems or bridges, may not be able to
   support CMIP and all the associated protocols.  In addition, such
   devices may not have Internet addresses.  Such devices are called
   "limited systems".  It may be possible to manage these devices using
   proprietary mechanisms or other standard protocols (such as the IEEE
   802.1 management protocol for managing bridges).  In cases where it
   is desirable to integrate the management of such devices with the
   overall CMOT management of an internet, it is necessary to use proxy
   management.  Some network elements that are not "limited systems" as
   described above may still benefit from the use of proxy management.
   If the management protocol supported by such a system is proprietary
   or some standard protocol other than CMIP (such as SNMP), then CMOT
   proxy management can be used to integrate the management of such
   systems.

   A proxy operates in the following manner.  When a CMOT manager wants
   to send a request to a managed device that it cannot communicate with
   directly, it routes the request to the proxy.  The proxy maps the
   CMIP request into the information schema understood by the managed
   device and sends the appropriate request to the managed device using
   the native management protocol of the device.  When the proxy
   receives the response from the managed device, it uses CMIP to return
   the information to the manager that made the original request.



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


   The use of proxy management can be largely transparent to the
   requesting manager, which appears to be exchanging information
   directly with the selected device.  The only thing that is known to
   the manager is that additional "instance" information is required to
   select a particular device managed by the proxy.  Each proxy may
   support many managed devices, using the "instance" information to
   multiplex CMIP requests and responses among them.  The mapping
   between a specific instance and an actual managed device is a local
   matter.  (The use of the CMIP Object Instance field to select a
   particular system to manage by proxy is explained below in section
   5.3.2.2.)

   A proxy may also serve as an "intermediate manager" in another less
   transparent sense.  The proxy manager may be requested to calculate
   summary statistics on information gathered from many different
   managed systems (e.g., the average number of PDUs transmitted or the
   distribution of PDUs transmitted over time).  The proxy may be
   requested to log events transmitted by the managed systems under its
   control and to send to the requesting manager only those events of
   specific types.  When this use of proxy management is made, the
   conceptual schema for managed objects known to both the requesting
   manager and proxy must include definitions of these aggregate managed
   objects (i.e., objects that do not belong to any one managed system).
   How the aggregate statistics would be calculated and logging
   performed based on information from the different devices managed by
   the proxy would be part of the definition of these aggregate managed
   objects.

4.4.  Directory Service

   RFC 1085 specifies the use of a minimal (or "stub") directory
   service.  It specifies how the service name for an OSI application
   entity is converted into an "application entity title." The
   application entity title is then mapped into a presentation address.
   The form of a service name, an application entity title, and a
   presentation address can be found in RFC 1085.

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.





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


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.

5.1.1.1.  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.