rfc1095.txt

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

   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].  RFC 1085 [13] is required for the
   specification of a lightweight presentation layer protocol used in
   this profile.  In addition, RFC 1065 [2] and RFC 1066 [3] are
   required for a definition of the initial SMI and MIB to be used with
   the CMOT management system.

   This memo is divided into two main parts.  The first part presents
   concepts and models; the second part contains the protocol agreements
   necessary for implementation of the CMOT network management system.
   The first part of the memo is divided into three sections: section 3



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


   contains tutorial information on the OSI management framework;
   section 4 defines the basic CMOT approach; and section 5 discusses
   the area of management information and specifies how the abstract
   management information defined in the Internet-standard SMI and MIB
   map into CMIP.  The second part of this memo is divided into sections
   for each of the protocols for which implementors' agreements are
   needed: CMISE, ACSE, ROSE, and the lightweight presentation protocol.
   The protocol profile defined in this part 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).
   Wherever possible, an attempt has been made to remain consistent with
   the protocol agreements reached by these groups.






































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


                        Part I: Concepts and Models

3.  The OSI Management Framework

   The OSI management framework [15] presents the basic concepts and
   models required for developing network management standards.  OSI
   management provides the ability to monitor and control network
   resources, which are represented as "managed objects." The following
   elements are essential for the description of a network management
   architecture and the standardization of a network management system:
   a model or set of models for understanding management; a common
   structure of management information for registering, identifying, and
   defining managed objects; detailed specifications of the managed
   objects; and a set of services and related protocols for performing
   remote management operations.

3.1.  Architectural Overview

   The basic concepts underlying OSI network management are quite simple
   [16].  There reside application processes called "managers" on
   managing systems (or management stations).  There reside application
   processes called "agents" on managed systems (or network elements
   being managed).  Network management occurs when managers and agents
   conspire (via protocols and a shared conceptual schema) to exchange
   monitoring and control information useful to the management of a
   network and its components.  The terms "manager" and "agent" are also
   used in a loose and popular sense to refer to the managing and
   managed system, respectively.

   The shared conceptual schema mentioned above is a priori knowledge
   about "managed objects" concerning which information is exchanged.
   Managed objects are system and networking resources (e.g., a modem, a
   protocol entity, an IP routing table, a TCP connection) that are
   subject to management. Management activities are effected through the
   manipulation of managed objects in the managed systems.  Using the
   management services and protocol, the manager can direct the agent to
   perform an operation on a managed object for which it is responsible.
   Such operations might be to return certain values associated with a
   managed object (read a variable), to change certain values associated
   with a managed object (set a variable), or perform an action (such as
   self-test) on the managed object.  In addition, the agent may also
   forward notifications generated asynchronously by managed objects to
   the manager (events or traps).

   The terms "manager" and "agent" are used to denote the asymmetric
   relationship between management application processes in which the
   manager plays the superior role and the agent plays the subordinate.




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


   However, the specification of the management protocol (CMIP) defines
   a peer protocol relationship that makes no assumptions concerning
   which end opens or closes a connection, or the direction of
   management data transfer.  The protocol mechanisms provided are fully
   symmetric between the manager and the agent; CMIS operations can
   originate at either the manager or agent, as far as the protocol is
   concerned.  This allows the possibility of symmetric as well as
   asymmetric relationships between management processes.  Most devices
   will contain management applications that can only assume the agent
   role.  Applications on managing systems, however, may well be able to
   play both roles at the same time.  This makes possible "manager to
   manager" communication and the ability of one manager to manage
   another.

3.2.  Management Models

   Network management may be modeled in different ways.  Three models
   are typically used to describe OSI management [17, 18].  An
   organizational model describes ways in which management can be
   administratively distributed.  The functional model describes the
   management functions and their relationships.  The information model
   provides guidelines for describing managed objects and their
   associated management information.

3.2.1.  The Organizational Model

   The organizational model introduces the concept of a management
   "domain." A domain is an administrative partition of a network or
   internet for the purpose of network management.  Domains may be
   useful for reasons of scale, security, or administrative autonomy.
   Each domain may have one or more managers monitoring and controlling
   agents in that domain.  In addition, both managers and agents may
   belong to more than one management domain.  Domains allow the
   construction of both strict hierarchical and fully cooperative and
   distributed network management systems.

3.2.2.  The Functional Model

   The OSI Management Framework [15] defines five facilities or
   functional areas to meet specific management needs. This has proved
   to be a helpful way of partitioning the network management problem
   from an application point of view.  These facilities have come to be
   known as the Specific Management Functional Areas (SMFAs): fault
   management, configuration management, performance management,
   accounting management, and security management.  Fault management
   provides the ability to detect, isolate, and correct network
   problems.  Configuration management enables network managers to
   change the configuration of remote network elements.  Performance



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


   management provides the facilities to monitor and evaluate the
   performance of the network.  Accounting management makes it possible
   to charge users for network resources used and to limit the use of
   those resources.  Finally, security management is concerned with
   managing access control, authentication, encryption, key management,
   and so on.

3.2.3.  The Information Model

   The OSI Management Framework considers all information relevant to
   network management to reside in a Management Information Base (MIB),
   which is a "conceptual repository of management information."
   Information within a system that can be referenced by the management
   protocol (CMIP) is considered to be part of the MIB.  Conventions for
   describing and uniquely identifying the MIB information allow
   specific MIB information to be referenced and operated on by the
   management protocol.  These conventions are called the Structure of
   Management Information (SMI).  The information model is described
   more fully in section 5.

3.3.  ISO Application Protocols

   The following ISO application services and protocols are necessary
   for doing network management using the OSI framework: ACSE, ROSE, and
   CMIS/CMIP.  All three of these protocols are defined using ASN.1 [5].
   The ASN.1 modules defining each of these protocols are found in the
   relevant standards documents.  The encoding rules for ASN.1 [6]
   provide a machine-independent network representation for data.

   A brief overview of the terminology associated with the OSI
   application layer structure is presented here.  A complete treatment
   of the subject can be found in the OSI Application Layer Structure
   document [22].

   In the OSI environment, communication between "application processes"
   is modeled by communication between application entities.  An
   "application entity" represents the communication functions of an
   application process.  There may be multiple sets of OSI communication
   functions in an application process, so a single application process
   may be represented by multiple application entities.  However, each
   application entity represents a single application process.  An
   application entity contains a set of communication capabilities
   called "application service elements." An application service element
   is a coherent set of integrated functions.  These application service
   elements may be used independently or in combination.  Examples of
   application service elements are X.400, FTAM, ACSE, ROSE, and CMISE.

   When communication is required between two application entities, one



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


   or more "application associations" are established between them.
   Such an association can be viewed as a connection at the level of the
   application layer.  An "application context" defines the set of
   application service elements which may be invoked by the user of an
   application association.  The application context may prescribe one
   or more application service elements.

   Generally, an "application layer protocol" is realized by the use of
   the functionality of a number of application service elements.  This
   functionality is provided by the specification of a set of
   application protocol data units (APDUs) and the procedures governing
   their use.  In general, the operation of an application layer
   protocol may require the combination of APDUs from different
   application service elements.  The application entity makes direct
   use of presentation context identifiers for the specification and
   identification of APDUs.

3.3.1.  ACSE