📄 rfc1189.txt
字号:
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]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -