rfc1189.txt

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

Warrier, Besaw, LaBarre & Handspicker                           [Page 5]

RFC 1189                     CMOT and CMIP                  October 1990


3.2.  The CMIP Protocol Suite

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

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

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

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

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

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

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

                      Figure 3.  The CMIP Protocol Suite

3.3.  Conformance Requirements

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

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




Warrier, Besaw, LaBarre & Handspicker                           [Page 6]

RFC 1189                     CMOT and CMIP                  October 1990


4.  Common Management Information Service Element

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

4.1.  Association Policies

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

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

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

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

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

      Full Mgr/Agent      all functions must be supported

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

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




Warrier, Besaw, LaBarre & Handspicker                           [Page 7]

RFC 1189                     CMOT and CMIP                  October 1990


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

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

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

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

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

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

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

   The following negotiation rules are to be used:

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

      2.   Managing systems may request any association type.

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





Warrier, Besaw, LaBarre & Handspicker                           [Page 8]

RFC 1189                     CMOT and CMIP                  October 1990


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

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

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

4.2.  CMIS Services

4.2.1  General Agreements on Users of CMIS

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

   The following additional agreements are specified.

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

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

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




Warrier, Besaw, LaBarre & Handspicker                           [Page 9]

RFC 1189                     CMOT and CMIP                  October 1990


4.2.2  Specific Agreements on Users of CMIS

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

   The following additional agreements are specified:

      o Event time shall be mandatory for all events.

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

4.3.  CMIP Agreements

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

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

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


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

5.  Services Required by CMIP

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

   The following additional agreements are specified:

      o ASCE Requirements:  Application contexts shall be as defined
        in section 4.1 of these agreements.  The values and defaults



Warrier, Besaw, LaBarre & Handspicker                          [Page 10]