ISO/IEC 9596:1990
(Main)Information technology - Open Systems Interconnection - Common management information protocol specification
Information technology - Open Systems Interconnection - Common management information protocol specification
Technologies de l'information — Interconnexion de systèmes ouverts — Spécification du protocole commun d'information de gestion
General Information
Relations
Frequently Asked Questions
ISO/IEC 9596:1990 is a standard published by the International Organization for Standardization (ISO). Its full title is "Information technology - Open Systems Interconnection - Common management information protocol specification". This standard covers: Information technology - Open Systems Interconnection - Common management information protocol specification
Information technology - Open Systems Interconnection - Common management information protocol specification
ISO/IEC 9596:1990 is classified under the following ICS (International Classification for Standards) categories: 35.100.70 - Application layer. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO/IEC 9596:1990 has the following relationships with other standards: It is inter standard links to ISO/IEC 9596-1:1991/Cor 5:1994, ISO/IEC 9596-1:1991. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO/IEC 9596:1990 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
Standards Content (Sample)
ISOIIEC
I NTER NAT1 O NAL
STANDARD
First edition
1990-05- 1 5
Information technology - Open Systems
Interconnection - Common management
information protocol specification
Technologies de l'information - Jnterconnexion de systèmes ouverts -
Spécification du protocole commun d'information de gestion
Reference number
IS0 9596 : 1990 (E)
ISO/IEC 9596 : 1990 (E)
Contents Page
........................................
Foreword iii
1Scope 1
.........................................
2 Normative references . 1
.....................................
3 Definitions 1
3.1 Basic Reference Model definitions . 1
3.2 Management Framework definitions . 1
3.3 Remote Operations definitions . 2
................................
3.4 CMIS definitions 2
................................
3.5 ACSE definitions 2
3.6 Presentation definitions . 2
4 Symbols and abbreviations . 2
.......................................
5 Overview 2
................................. 2
5.1 Service provided
5.2 Underlying services .
5.3 Management infomiation definitions . 3
................................
6 Elements of procedure 3
6.1 Association establishment .
6.2 Remote operations . 3
6.3 Event reporting procedure . 3
6.4 Get procedure .
6.5 Set procedure .
.................................
6.6 Action procedure 5
6.7 Create procedure .
6.8 Delete procedure . 6
6.9 Association orderly release . 6
6.10 Association abrupt release . 6
7 Abstract syntax .
................................... 6
7.1 Conventions
7.2 Correspondence between CMISE primitives and CMIP operations . 7
..................................
7.3 ACSE user data 7
7.4 CMIP data units . 8
7.5 Definition of abstract syntax for CMIP . 14
.....................................
8 Conformance 14
8.1 Static requirements . 15
8.2 Dynamic requirements . 15
8.3 PICS requirements . 15
8.4 PICS proforma . 15
Annexes
A (normative) Association rules for CMISE . 18
B (informative) Expanded ASN.l syntax
...................... 20
C (informative) Examples of CMISE ROSE APDUs . 28
O ISO/IEC 1990
Ali rights reserved . No part of this publication may be reproduced or utilized in any form
or by any means. electronic or mechanical. including photocopying and microfilm.
without permission in writing from the publisher .
ISO/IEC Copyright Office Case postale 56 CH-1211 Genève Switzerland
Printed in Switzerland
ii
ISOAEC 9596 : 1990 (E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the International
Electrotechnical Commission) form the specialized system for worldwide standardiz-
ation. National bodies that are members of IS0 or IEC participate in the development
of International Standards through technical committees established by the respective
organization to deal with particular fields of technical activity. IS0 and IEC technical
committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with IS0 and IEC, also take part in the
work.
In the field of information technology, IS0 and IEC have established a joint technical
committee, ISO/IEC JTC 1. Draft International Standards adopted by the joint
technical committee are circulated to national bodies for voting. Publication as an
International Standard requires approval by at least 75 Yo of the national bodies casting
a vote.
International Standard ISOAEC 9596 was prepared by Joint Technical Committee
ISO/IEC JTC 1, information technology.
Annex A forms an integral part of this International Standard. Annexes B and C are
for information only.
iii
INTERNATIONAL STANDARD ISO/IEC 9596 : 1990 (E)
Information technology - Open Systems Interconnection -
Common management information protocol specification
1 Scope IS0 8650 : 1987, Information processing systems - Open
Systems interconnection - Protocol specification for the
Association Control Service Element.
This International Standard specifies a protocol which is used
by application layer entities to exchange management
IS0 8822 : 1987, Information processing systems - Open
information.
System Interconnection - Connection oriented presentation
service definition.
This International Standard specifies
IS0 8823 : 1987, Information processing systems - Open
- procedures for the transmission of management
Systems Interconnection - Connection oriented presentation
information between application entities;
protocol specification.
0 - the abstract syntax of the Common Management
IS0 8824 : 1987, Information processing systems - Open
Information Protocol and the associated encoding niles to be
Systems Interconnection - Specification of Abstract Syntax
applied
Notation One (ASN.1).
- procedures for the correct interpretation of protocol
IS0 8825 : 1987, Inforination processing systems - Open
control information:
Systenrs Interconnection - Specification of Basic Encoding
Rules for Abstract Syntax Notation One (ASN.1).
- the conformance requirements to be met by
implementation of this International Standard.
ISO/IEC 9072-1 : 1989, Information processing systems - Text
Communication - Remote Operations - Part 1 : Model, Notation
This International Standard does not specify
and Service Definition.
- the structure or meaning of the management information
ISO/iEC 9072-2 : 1989, Information processing systems - Text
that is transmitted by means of CMIP,
Communication - Remote Operations - Part 2: Protocol
Specification.
- the manner in which management is accomplished as a
result of CMlP exchanges;
ISO/reC 9595 : 1989, Inforntation tecknology - Open Systems
Interconnection - Common Management Inforination Servicc
- the interactions which result in the use of Ci".
Definition.
2 Normative references
3 Defimitions
The following International Standards contain provisions
For the purposes of this International Standard, the following
which, through reference in this text, constitute provisions of
definitions apply.
this International Standard. At the time of publication, the
editions indicated were valid. All standards are subject to
3.1 Basic Reference Model definitions
revision, and parties to agreements based on this International
Standard are encouraged to investigate the possibility of
This International Standard makes use of the following terms
applying the most recent editions of the standards listed below.
defined in IS0 7498.
Members of IEC and IS0 maintain registers of currently valid
International Standards.
a) application-service-element;
IS0 7498 : 1984, Information processing systems - Open b) application-process;
c) real open system;
Systeins Interconnection - Basic Reference Model.
d) systems-management.
ISO/IEC 7498-4 : 1989, Information processing systems -
3.2 Management Framework definitions
Open Systems Interconnection - Basic Reference Model - Part
4: Management Framework.
This International Standard makes use of the following terms
defmed iii ISO/IEC 7498-4.
IS0 8326 : 1987, Information processing systems - Open
Systems Interconnection - Basic connection oriented session
service definition. a) managed object;
b) management information;
c) management information base;
IS0 8649 : 1987, Information processing systems - Open
Systems Interconnection - Service definition for the d) systems management application-entity.
Association Control Service Element.
ISO/IEC 9596 : 1990 (E)
3.3 Remote Operations definitions PICS protocol implementation conformance statement
RO remote operations
This International Standard makes use of the following terms
defined in ISO/JEC 9072-1.
ROSE Remote Operations Service Element
a) association-initiator;
b) association-responder; SMAE systems management application-entity
c) linked-operations:
d) Remote Operations;
e) Remote Operation Service Element. 5 Overview
3.4 CMïS definitions
The Common Management Information Protocol (CMIP)
specifies protocol elements that may be used to provide the
This International Standard makes use of the following terms operation and notification services described in ISOmC 9595,
defined in ISO/DEC 9595.
which defines the Common Managenient Information Services
(CMIS).
attribute;
common management information service element;
5.1 Service provided
common management information services;
CMISE-service-pir>vider;
The protocol specified in this International Standard supports
CMISE-service-user;
the services defined in ISO/IEC 9595. These services are
invoker; summarized in table 1.
invoking CMISE-service-user:
performer:
Table 1 -
performing CMSE-service-user.
Common Management Idormation Services
3.5 ACSE definitions
I Type
Service
M-EVENT-REPORT I confirmed/non-confired
This International Standard makes use of the following terms
M-GET confirmed
defined in IS0 8649.
M-SET confirmed/non-confirmed
M-ACTTON confirmed/non-confirmed
a) application context;
M-CREATE confirmed
b) application-association;
confirmed
M-D-
c) association.
5.2 Underlying services
3.6 Presentation definitions
This International Standard uses the RO-INVOKE, RO-RESULT,
This International Standard makes use of the following terms
RO-ERROR and RO-REJECT-U services of the Remote
defined in IS0 8822.
Operations Service Element (ROSE) defined in ISO/IEC 9072-1.
ROSE assumes the use of the presentation service defined in
a) abstract syntax:
IS0 8822. The confirmed operations of CMIF' are class 2
b) transfer syntax.
(asynchronous) or class 1 (synchronous) as required by the
application. The unconfirmed operations of CMIP are Class 5
(synchronous, outcome not reported). CMIP uses association
4 Symbols and abbreviations
class 3.
ACSE Association Control Service Element
If the extended service functional unit is successfully
negotiated, ROSEapdus may be mapped on to presentation
APDU Application Protocol Data Unit
services other than the P-DATA service.
ASE Application Service Element
NOTE - For example, it may be necessary to modify the presentation
defined context set (DCS) when the CMIP operation is sent to the peer
ASN.l Abstract Syntax Notation One
CMISE-service-user. In this carie, the ROSE APDU which carries the
CMIP operation will be mapped onto the P-ALTER-CONTEXT service
CMIP Common Management Information Protocol
which is also used to perform the changes to the DCS.
CMIPM Common Management Information Protocol
Details of which other presentation services are required and
Machine
how they are used, are described in the description of the
application context in use on the association.
CMIS Common Management Information Service
5.2.1 Service assumed from the ACSE
CMEE Common Management Information Service Element
This International Standard assumes the use of the
DCS defined context set
A-ASSOCIATE, A-RELEASE, A-ABORT, and A-P-ABORT
services of the Association Control Service Element.
PCI protocol control information
PDU protocol data unit
L
~~
ISO/IEC 9596 : 1990 (E)
5.2.2 Service assumed from the presentation layer 6.2.2 RO-Reject problem parameters
ISO/IEC 9072-2 assumes the use of the P-DATA service of the The RO-Reject problem parameters are mapped or processed as
presentation layer for the transfer of the RO-INVOKE, follows
RO-RESULT. RO-ERROR and RO-RETE0 PDUS.
6.2.2.1 RO-Reject-User.Invoke-problem mapping to CMIS
5.3 Management information definitions error codes is as follows
This International Standard defines the abstract syntax of the Table 2 -
Common Management Information Protocol. Attributes Mapping RO-Reject-User.ïnvoke-problem
specific to a particular managed object are specified by the to CMI[SE error codes
International Standard which defines that object.
6 Eiements of procedure
This clause provides definition for the procedural elements of
the CMIP. The procedures define the transfer of CMIP PDUs
whose structure, coding and relationship with the CMIS service
Other Invoke-problem parameters are a local matter
primitives is specified in clause 7.
6.2.2.2 Other RO-Reject parameters will be handled as a local
The Common Management Information Protocol Machine
matter.
(CMIPM) accepts CMIS request and response service
primitives, and issues CMIP PDUs initiating specific elements
6.3 Event reporthg procedure
of procedure as specified in this clause.
6.3.1 invocation
A CMIPM shall accept any well-formed CMIP PDU, and pass it
to the performing CMISE-service-user for processing, by
The event reporting procedures are initiated by the M-EVENT-
means of CMIS indication and confirmation service primitives.
REPORT request primitive.
If the received PDU is not well formed or does not contain a
supported notification or operation, a PDU is returned
On receipt of the M-EVENT-REPORT request primitive, the
indicating that the received PDU has been rejected.
CMIPM shall
The procedures indicate only how to interpret the various fields
a) in the confirmed mode, construct an APDU requesting the
in the CMIP PDU, not what an invoking CMISE-service-user
m-EventReport-Confirmed operation, otherwise, construct an
should do with the information it requests nor how a
APDU requesting the m-EventReport operation;
performing CMISE-service-user should process the invocation.
b) send the APDU using the RO-WOKE procedure.
6.1 Association establishment
6.3.2 Receipt
The establishment of an association involves two CMISE-
service-users, one that is the association-initiator and one that
On receipt of an APDU requesting either the m-EventReport or
is the association-responder.
m-EventReport-Confirmed operation, the CMIPM shall, if the
APDU is well formed, issue an M-EVENT-REPORT indication
A CMISE-service-user may initiate an association
primitive to the CMISE-service-user with the mode parameter
establishment by using the A-ASSOCIATE service of IS0
indicating whether or not confirmation is requested, otherwise,
8649.
construct an APDU containing notification of the error and
send it using the RO-REJECT-U procedure.
The application context specifies, among other things, the
rules required for the coordination of initialisation information
6.3.3 Response
corresponding to different ASES. The association rules for
CMISE are specified in annex A.
In the confirmed mode, the CMIPM shaii accept an M-EVENT-
REPORT response primitive and shall
6.2 Remote operations
a) construct an APDU confirming the M-EVENT-REPORT
6.2.1 RO elements of procedure
notification:
The CMIP elements of procedure rely on the following
b) if the parameters in the M-EVENT-REPORT response
underlying Remote Operations eiemenis of procedure
primitive indicate that the notification was accepted, send the
APDU using the RO-RESULT procedure, otherwise, send the
a) invocation;
APDU using the RO-ERROR procedure.
b) return-result;
c) return-error;
6.3.4 Receipt of response
d) user-reject;
e) provider-reject.
On receipt of an APDU responding to an M-EVENT-REPORT
notification, the CMIPM shall, if the APDU is well formed,
These elements of procedure are described fully in ISO/TEC
issue an M-EVENT-REPORT confirmation primitive to the
9072-2,
CMISE-service-user, thus completing the notification
ISOAEC 9596 : 1990 (E)
procedure, otherwise, construct an APDU containing c) if the APDU is not well formed, construct an APDU
notification of the error and send it using the RO-REJECT-U containing notification of the error and send it using the
procedure. RO-RE3ZCT-U procedure.
6.4 Get procedure 6.5 Set procedure
6.4.1 invocation 6.5.1 Invocation
The Get procedures are initiated by the M-GET request The Set procedures are initiated by the M-SET request primitive.
primitive.
On receipt of the M-SET request primitive, the CMIPM shall
On receipt of the M-GET request primitive, the CMIPM shall
a) in the confirmed mode, construct an APDU requesting the
a) construct an APDU requesting the m-Get operation; m-Set-Confirmed operation, otherwise, construct an APDU
requesting the m-Set operation;
b) send the APDU using the RO-INVOKE? procedure.
b) send the APDU using the RO-INVOKE? procedure.
6.4.2 Receipt
6.5.2 Receipt
On receipt of an APDU requesting the m-Get operation, the
if the APDU is well formed, issue an M-GET
CMIPM shall, On receipt of an APDU requesting the ni-Set or m-Set-
indication primitive to the CMISE-service-user, otherwise, Confirmed operation, the CMIPM shall, if the APDU is well
construct an APDU containing notification of the error and formed, issue an M-SET indication primitive to the CMISE-
it using the RO-REJECT-U procedure.
send service-user, with the mode parameter indicating whether or not
confirmation is requested, otherwise, construct an APDU
6.4.3 Response
containing notification of the error and send it using the
RO-REJECT-U procedure.
The CMIPM shall
6.5.3 Response
a) accept zero or more M-GET response primitives containing
a linked-ID followed by a single M-GET response primitive Ln the confirmed mode, the CMPM shall
without a linked-JD;
a) accept zero or more M-SET response primitives containing
b) for each M-GET response primitive containing a linked-ID a linked-ID followed by a single M-SET response primitive
the CMIPM shall without a linked-D,
- construct an APDU requesting the m-Linked-Reply
b) for each M-SET response primitive containing a linked-ID
operation with LinkedReplyArgument set appropriately as
the CMPM shall
either getListError, getResuit or processingFailure;
- construct an APDU requesting the m-Linked-Reply
- send each APDU using the RO-INVOKE procedure. operation with LinkedReplyArgument set appropriately as
either setListError, setResult or processingFailure;
c) for the M-GET response primitive not containing a
linked-ID the CMIPM shall - send each APDU using the RO-INVOKE procedure.
- construct an APDU confirming the m-Get operation; c) for the M-SET response primitive not containing a
linked-ID the CMIPM shall
- if the parameters in the M-GET response primitive
indicate that the operation was performed correctly, send - construct an APDU confirming the ni-Set operation;
the APDU using the RO-RESULT procedure. If the
parameters in the M-GET response primitive indicate that - if the parameters in the M-SET response primitive
the operation was performed with partial success or was not indicate that the operation was performed correctly, send
perfomied because of an error, send the APDU using the the APDU using the RO-RESULT procedure. If the
RO-ERROR procedure. parameters in the M-SET response primitive indicate that
the operation was performed with partial success or was not
6.4.4 Receipt of response perfomied because of an error, send the APDU using the
RO-ERROR procedure.
On receipt of an APDU responding to an m-Get operation, the
6.5.4 Receipt of response
CMIPM shall
a) if the APDU included a Linked-IT) and is well formed, issue On receipt of an APDU responding to an ni-Set-Confirmed
operation, the CMIPM shall
an M-GET confirm primitive to the CMISE-service-user;
b) if the APDU is the last response (i.e. not containing a
a) if the APDU incltided a linked-ID and is well fomied, issue
linked-ID) and is well formed, issue an M-GET confirmation an M-SET confimi primitive to the CMISE-service-user;
primitive to the CMISE-service-user, thus completing the
M-GET procedure; b) if the APDU is the last response (i.e. iint containing a
linked-ID) and is well formed, issue an M-SET confirmation
ISO/IEC 9596 : 1990 (E)
primitive to the CMISE-service-user, thus completing the
b)if the APDU is the last response (i.e, not containing a
M-SET procedure; linked-ID) and is well formed, issue an M-ACTION
confirmation primitive to the CMISE-service-user, thus
c) if the APDU is not well formed, construct an APDU
complethg the M-ACTION procedure;
containing notification of the error and send it using the
RO-REJECT-U procedure. c) if the APDU is not well formed, construct an APDU
it using the
containing notification of the error and send
6.6 Action procedure
RO-REJECT-U procedure.
6.6.1 Invocation
6.7 Create procedure
The Action procedures are initiated by the M-ACTION request 6.7.1 invocation
primitive.
The Create procedures are initiated by the M-CREATE request
On receipt of the M-ACTION request primitive, the CMJPM primitive.
shall
On receipt of the M-CREATE request primitive, the CMIPM
a) in the confirmed mode, construct an APDU requesting the shall
m-Action-Confinned operation otherwise, construct an APDU
requesting the m-Action operation: a) construct an APDU requesting the m-Create operation:
-
b) send the APDU using the RO-INVOKE procedure.
b) send the APDU using the RO-INVOKE procedure.
6.6.2 Receipt
6.7.2 Receipt
On receipt of an APDU requesting the m-Action or m-Action- On receipt of an APDU requesting the m-Create operation, the
Confirmed operation, the CMIPM shall, if the APDU is well CMPM shall, if the APDU is weii formed, issue an M-CREATE
formed, issue an M-ACTION indication primitive to the indication primitive to the CMISE-service-user. otherwise,
CMISE-service-user, with the mode parameter indicating construct an APDU containing notification of the error and
whether or not confirmation is requested, otherwise, constmct send it using the RO-REJECT-U procedure.
an APDU containing notification of the error and send it using
the RO-REIECT-U procedure.
6.7.3 Response
6.6.3 Response The CMlPM shall accept an M-CREATE response primitive and
shall
In the confinned mode, the CMIPM shall
a) construct an APDU confirming the m-Create operation:
a) accept zero or more M-ACTION response primitives
containing a linked-ID followed by a single M-ACTION b) if the parameters in the M-CREATE response primitive
response primitive without a linked-ID; indicate that the operation was performed correctly, send the
APDU using the RO-RESULT procedure, otherwise, send the
b) for each M-ACTION response primitive containing a
APDU using the RO-ERROR procedure.
linked-ID the CMIPM shall
6.7.4 Receipt of response
a
- construct an APDU requesting the m-Linked-Reply
operation with LinkedReplyÂrgum& set appropriately ai On receipt of an APDU responding to an m-Create operation,
either actionarror, actionResult or processingtjailure; the CMPM shall, if the APDU is well formed, issue an
M-CREATE confirmation primitive to the CMISE-service-user,
- send each APDU using the RO-INVOKE procedure.
thus completing the M-CREATE procedure, otherwise,
construct an APDU containing notification of the error and
c) for the M-ACTION response primitive not containing a
send it using the RO-REJECT-U procedure.
linked-ID the CMJPM shall
6.8 Delete procedure
- construct an APDU confirming the m-Action operation;
6.8.1 Invocation
- if the parameters in the M-ACTION response primitive
indicate that the operation was performed correctly, send The Delete procedures are initiated by the M-DELETE request
the APDU using the RO-RESULT procedure, otherwise, send primitive.
the APDU using the RO-ERROR procedure.
On receipt of the M-DELETE request primitive. the CMIPM
6.6.4 Receipt of response shall
On receipt of an APDU responding to an m-Action-Confirmed
a) construct an APDU requesting the m-Delete operation:
operation, the CMJPM shall
b) send the APDU using the RO-INVOKE procedure.
a) if the APDU included a linked-ID and is well formed, ismie
an M-ACTION confirm primitive to the CMISE-service-user;
ISO/IEC 9596 : 1990 (E)
c) if the APDU is not well formed, construct an APDU
6.8.2 Receipt
containing notification of the error and send it using the
RO-RETECT-U procedure.
On receipt of an APDU requesting the m-Delete operation, the
CMiPM shall, if the APDU is Weil formed, issue an M-DELETE
6.9 Association orderly release
indication primitive to the CMISE-service-user, otherwise,
an APDU containing notification of the error and
construct
Either CMISE-service-user may initiate an orderly release of the
send it using the RO-REJECT-U procedure.
association by using the A-RELEASE service of IS0 8649.
6.8.3 Response
NOTE - This specification is different from the ROSE use of the BIND
operation in which only the association-initiator may use the
The CMIPM shall
A-REBASE pro~ed~n.
a) accept zero or more M-DELETE response primitives
6.10 Association abrupt release
containing a linked-ID followed by a single M-DELETE
response primitive without a linked-ID;
Either CMSE-service-user may initiate an abmpt release of the
IS0 8649.
association using the A-ABORT service of
b) for each M-DELETE response primitive containing a
linked-ll) the CMlPM shall
The CM[SE-service-provider may initiate an abrupt release of
the association using *the A-P-ABORT service of IS0 8649.
- construct an APDU requesting the m-Linked-Reply
as
operation with LinkedReplyArgument set appropriately
e
either deleteError, deleteResult or processisgFailure;
7 Abstract syntax
-send each APDU using the RO-INVOKE procedure.
This clause specifies the abstract syntax for the CMIP PDUs.
c) for the M-DELETE response primitive not containing a
7.1 Conventions
linked-ID the CMIPM shall
- construct an APDU confirming the m-Delete operation;
The abstract syntax is defined using the notation specified in
IS0 8824. The ASN.1 MACRO productions used or referenced
- if the parameters in the M-DELETE response primitive by this international Standard do not exercise the ambiguous
indicate that the operation was performed correctly, send aspects of the grammar.
the APDU using the RO-RESULT procedure, otherwise, send
the APDU using the RO-ERROR procedure. For each of the CMISE service parameters which is to be
transferred by a CMIP PDU, there is a PDU field (an ASN.l
6.8.4 Receipt of response NamedType) with the same name as the corresponding service
parameter (see ISO/IEC 9595), except for the differences
On receipt of an APDU responding to an m-Delete operation, required by the use of ASN.1, which are that blanks between
the CMIPM shall words are removed and the first letter of the following word is
capitalized, e.g. "managed object class" becomes
a) if the APDU included a linked-ID and is well formed, issue "managedObjectClass". To make some of the names shorter,
an M-DELETE confirm primitive to the CMISE-service-user;
some words are abbreviated as follows
b) if the APDU is the last response (i.e. not containing a
ack = acknowledgement
linked-ID) and is well formed, issue an M-DELETE
arg = argument
confirmation primitive to the CMISE-service-user, thus id = identifier
completing the M-DELETE procedure; info = information
sync = synchronization
ISOAEC 9596 : 1990 (E)
7.2 Correspondence between CMïSE primitives and CMIP operations
Table 3 - Correspondence between CMLSE primitives and CMIP operations
NOTE - The mapping from the OPERATION macro to ROSE is as defined in ISO/reC 9072-1.
7.3 ACSE user data
The ACSE protocol (IS0 8650) is described using ASN.1. The "user information" is defined using the EXTERNAL data type.
7.3.1 A-ASSOCIATE user data
The encoding of the CMIP user infomation to be passed to A-ASSOCIATE in the "user information" parameter is defined as follows
CMP-A-ASSOCIATE-Information 1 joint-iso-ccitt ms(9) cmip( 1) versionl( 1) aAssociateUserhfo( I))
DEFINITIONS ::=BEGIN
FunctionalUnits ::= BIT STRING multipleObjectSelection (O),
filter (11,
muItipleReply (Z),
extendedservice (3)
-- Functional unit i is supported if and only if bit i is one.
-- information canled in user-information parameter of A-ASSOCIATE
CMIPUserInfo ::= SEQUENCE ( protocolVersion
[O] IMPLICIT ProtocolVersion DEFAULT 1 versioril ),
functionalUnits [l J IMPLICIT FunctionalUnits DEFAULT ),
[Z] OPTIONAL,
accessContro1
userhfo [3J EX"& OPTIONAL )
ProtocolVersion ::= BIT STRING ( version1 (O) )
EM)
The encoding of other "user information" supplied by the CMISE-service user is not defined by this International Standard.
ISOIIEC 9596 : 1990 (E)
7.3.2 A-ABORT user data
The encoding of the CMIP user information to be passed to A-ABORT in the "user information" parameter is defined as follows
CMIP-A-ABORT-Information { joint-iso-ccitt ms(9) cmip( 1) versionl( 1) aAbortUserInfo(2))
DEF"i0NS ::= BEGIN
-- information carried in user-information parameter of A-ABORT
CMPAbortInfo ::= SEQUENCE 1 abortSource [O] IMPLICIT CMPAbortSource,
userInfo [ 1 J FKïERNAL OFITONAL )
CMIPAbortSource ::= ENUMERATED ( cmiseServiceUser
(O),
cmiseServiceProvider (1) )
END
The encoding of other "user information" supplied by the CMISE-service user is not defined by this International Standard.
7.4 CMIP data units
The protocol is described in terms of Common Management Information Protocol Data Units exchanged between the peer CMISEs. The
PDUs are specified using ASN.l and the Remote Operations Protocol OPERATION and ERROR external macros defined in ISO/IEC
9072-1.
-- Common Management Information Protocol (CMIP)
CMIP-1 { joint-iso-ccitt ms(9) cmip(1) versiotil(1) protocol(3))
DEF2NITIONS ::= BEGIN
-- Remote Operations definitions
IMPORTS OPERATION, ERROR FROM Remote-Operation-Notation joint-iso-ccitt remoteOperations(4) notation(0) )
-- Directory Service definitions
DistinguishedName, RDNSequence FROM InformationFramework ( joint-iso-ccitt ds(5) modules( 1) infomationFramework( 1) ] :
-- CMISE operations
-- in the following operations, the argument type is mandatory in the corresponding ROSE APDU
-- Action operations (M-ACTION)
m-Action OPEXATION
ARGUMENT ActionArgument
::= IocalValue 6
m- Action-Confïhed OPERATION
ARGUMJ3" ActionArgument
RESULT ActionResult
-- this result is conditional; for conditions see ISO/IEC 9595 subclause 8.3.3.2,9
EBRORS ( accessDenied, classInstanceConflict, complexityliniitation, invalidScope, invalidArgunientValue,
invalidFilter, noSuchAction, noSuchArgument, noSuchObjectClass, noSuchObjectInstarice,
processingFailure, syncNotSupported )
-( m-Linked-Reply )
::= IocalValue 7
-- Create operation (M-CREATE)
m-Create OpERATlON
ARGUMl3NT CreateArgument
RESULT CreateResult
-- this result is conditional; for conditions see ISO/JEC 9595 subclause 8.3.4.1.3
ERRORS ( accessDenied, classInstanceConflict, duplicateManagedObjecthstance, invalidAttributevalue,
invalidobjecthstance, missingAttributeValue, noSuchAttribute, noSuchObjectClass,
noSuchObjectInstance, noSuchReferenceObject, processingFailure 1
::= IocalValue 8
ISO/IEC 9596 : 1990 (E)
-- Delete operation (M-DELETE)
ni-Delete OPERATION
ARGüMiWï DeleteArgument
RESULT DeleteResult
-- this result is conditional; for conditions see ISO/reC 9595 subclause 8.3.5.2.8
EBRORS { accessDenied, classJnstanceConflict, complexityLimitation, invalidFilter, invalidScope,
noSuchObjectClass, noSuchObjectInstance, processingFailure, syncNotSupported )
-( m-Linked-Reply )
::= localvalue 9
-- Event Reporting operations (M-EVENT-REPORT)
m-EventReport OPERATiON
ARGUMENT EventReportArgument
::= IocalValue O
m-EventReport-Confird OPERATION
ARGUMENT EventReportArgument
RESULT EventReportResult -- optional
0 ERRORS ( invalidArgumentValue, noSuchArpument, noSuchEventType, noSuchObjectClass,
noSuchObjectInstance, processingFailure )
::= IocalValue 1
-- Get operation (M-GET)
ni-Get OPERATION
ARGUMEBT GetArgunient
RESULT GetResult
-- this result is conditional; for conditions see ISO/EC 9595 subclause 8.3.1.2.8
ERRORS (
accessDeiiied, classInstanceConflict, coniplexityLiniitatioii, getListError, invalidFilter,
invalidScope, noSucliObjectClass, noSucliObjectInstance, processingFailure, syncNotSupported )
-1 m-Linked-Reply )
. ._
..- IocalValue 3
-- Linked operation to M-GET, M-SET (Confirmed), M-ACTION (Confhned), and M-DELETE
m-Linked-Reply OPERATiON
ARGüMENï LinkedReplyArgument
::= IocalValue 2
-- Set operations (M-SET)
m-Set OPERATION
ARGUMENT SeîArgument
::= IocalValue 4
m-Set-Confinned OPERATION
ARGUMENT SetArgument
mtnT SetResult
-- this result is conditional; for condiiions see ISO/lEC 9595 subclause 8.3.2.2.9
ERRORS [
accessDenied, classInstanceConflict, complexityLimitation, invalidFilter, invalidscope,
noSuchObjectClass, noSuchObjectInstaiice, processiiigFailure, setListError, syncNotSupported )
-( m-Linked-Reply )
::= IocalValue 5
-- CMIS error definitions
-- in the following errors, unless otherwise indicated, the parameter type is mandatory in the corresponding ROSE APDU
accessDenied ERROR
::= IocalValue 2
classInstanceConflict ERROR
PARAMETER BaseManagedObjectId
::= IocalValue 19
ISO/IEC 9596 : 1990 (E)
compiexityLimitation ERROR
PARAMETER ComplexityLimitation -- optional
::= IocalValue 20
duplicateManagedObjecthstance ERROR
PARAMETER Objecthstance
::= IocalValue 11
getListError ERROR
PARAMETER GetListError
::= IocalValue 7
invalidArgumentVdue ERROR
PARAMETER InvalidArgumentVdue
::= IocalValue 15
invalidAttributevalue ERROR
PARAMETER Attribute
::= IocalValue 6
invalidFilter ERROR
PARAMETER CMISFilter
::= localvalue 4
invalidScope ERROR
PAMMETER Scope
::= IocalValue 16
invalidobjecthstance ERROR
PARAMETER Objecthstance
::= iocalValue 17
missingAttributeVdue ERROR
PARAMETER SET OF AttributeId
::= 1ocalValue 18
noSuchAction ERROR
PARAMETER NoSuchAction
::= localvalue 9
noSuchArgument ERROR
PARAMETER NoSuchArfpment
::= 1ocalValue 14
noSuchAttribute ERROR
PARAMETER AttributeId
::= IocdVdue 5
noSuchEventType ERROR
PARAMETER NoSuchEventSpe
::= IocalValue 13
noSuchObjectClass ERROR
PARAMETER ObjectClass
::= locdValue 0
noSuchObjecthstance ERROR
PARAMETER Objecthstance
::= IocalValue 1
noSuchReferenceObject ERROR
PARAMETER Objecthstance
::= 1ocalVdue 12
processingFailure ERROR
PARAMETER ProcessingFailure -- optional
::= 1ocalValue 10
ISO/IEC 9596 : 1990 (E)
setListError ERROR
PARAMETER SetListError
::= IocalValue 8
syncNotSupported ERROR
PARAMETER CMISSync
::= IocaIValue 3
-- Supporting type definitions.
AccessControl ::= EXTERNAL
ActionArgument ::=SEQUENCE ( COMPONENTS OF BaseManagedObjectId,
accesscontrol [S] AccessControl OPTIONAL,
synchronization [6] IMPLICIT CMISSync DEFAULT bestEffort,
scope [7] Scope DEFAULT baseobject,
filter CMISFiiter DEFAULT and ( ) ,
actionInfo [ 121 IMPLICIT ActionInfo )
ActionError ::= SEQUENCE ( managedObjectClass Objectclass OPTIONAL,
managedObjectInstance ObjectInstance OPTIONAL,
e
cumentTinie [SI IMPLICIT GeneralizedTime OPTZONAL,
nctionErrorInfo [6] ActionErrorInfo ]
ActionErrorInfo ::= SEQUENCE ( emorstatus ENUMERATED ( accessDenied (2),
noSuchAction (9),
noSuchArgument (1419
invalidArgumentValue (15) ),
errorhfo CHOICE ( actionType ActionTypeId,
actionArgument [O] NoSuchArpument,
argumentvalue [il InvalidArgumentValue ) )
ActionInfo ::= SEQUENCE actionType ActionTypeId,
actionInfoArg [4] ANY DEFINED BY actionType OPTIONAL )
ActionReply ::= SEQUeNCE ( actionType Ac tionTypeId,
actionReplyInfo [4] ANY DEFiNED BY actionTyp )
::= SEQUENCE ( managedObjectClass
ActionResult Objectclass OM'IONAL,
maiiagedObjectInstance ObjectInstance OPTIONAL,
currentTime [5] IMPLICIT GeneralizedTime OPIIONAL,
actionReply [6] IMPLIClT ActionReply OPTIONAL )
ActionTypeld ::= CHOICE ( globdFonn [2] IMPLICIT OBJECT II)ENTIpIER,
IocalForm [3] IMPLICIT INTEGER )
-- This International Standard does not allocate any values for IocaiForm
-- where this alternative is used, the peimissible values for the integers and their meanings
-- shall be defined as part of the application context in which they are used
Attribute ::= SEQUENCE ( attributeId Attribu teId ,
attributevalue
ANY DEi?iN€W BY atîributeId )
AtînbuteError ::= SEQUENCE ( errorstatus ENUMERATED accessDenied (21,
noSuch Attribute (5),
invalidAttributevalue (6) ),
attributeId AttributeId,
ANY DEFINED BY attributeId ]
attributevalue
AttnbuteId ::= CHOICE ( globdForm [O] ïMPLICIT OBJECT IDENTIFIER,
IocalForm [il IMPLIcllT INTEGER )
-- This International Standard does not allocate any values for IocaiFom
-- where. this alternative is used, the permissible values for the integers and their meanings
-- shall be defined as part of the application context in which they are used
AttributeIdError ::= SEQUENCE ( errorStatus ENLJh4ERATED ( accesshnied (2),
noSuchAttribute (5) ),
attributeId AttnbuteId )
ISO/IEC 9596 : 1990 (E)
BaseManagedObjectId ::= SEQUENCE { baseManagedObjectC1ass Objectclass,
baseManagedObjectInstance ObjectInstance ]
CMISFiiter ::= CHOICE ( item [8] FilterItem,
and [9] IMPLICIT SET OF CMISFilter,
or [lo] IMPLIClT SET OF CMISFilter,
not [il] CMISFilter )
CMISSync ::= EEiUMERATED ( bestEffort
(O),
atomic (1) 1
ComplexityLimitation ::= SET ( scope [O] Scope OPTIONAL,
filter [I] CMISFilter OPTIONAL,
sync [Z] CMzSSync OPTIONAL )
CreateArgument ::= SEQUENCE (
managedObjectClass ObjectClass,
CHOICE ( managedobjecthstance ObjectInstance,
superiorObjectInstance [8] ObjectInstance ) OPTIONAL,
accessContro1 [SI AccessControl OPTIONAL,
referenceobjecthstance [6] Objecthstance OPTIONAL,
)
attributeList [7] IMPLICIT SET OF Attribute OPTIONAL
CreateResult ::= SEQUENCE ( managedObjectClass ObjectClass OPTIONAL,
managedObjectJnstance Objectliistance OPTIONAL,
-- shall be returned if omitted from CreateArgument
currentTime [SI IMPLICIT GenemiizedTime OPTIONAL,
attributeList [6] IMPLIClT SET OF Attribute OPTIONAL ]
DeleteArpment ::= SEQUENCE { COMPONENTS OF BaseManagedObjectId,
accesscon trol [SI AccessControl OPTZONAL,
synchronization [6] IMPLICIT CMISSync DEFAULT bestEffort,
scope [7] Scope DEFAULT baseobject,
( ) 1
filter CMISFiiter DEFAULT and
DeleteError ::= SEQUENCE ( managedObjectClass Objectclass OPTIONAL,
managedObjectlnstance ObjectInstance OF'TlONAL,
cumntTime [5] IMPLICIT GeneralizedTime OPTIONAL,
deleteErrorInfo [6] EMTMERATED { accessDenied (2) ) )
Objectclass OPTIONAL,
DeleteResult ::= SEQUENCE ( managedObjectClass
managedObjectInstance ObjectInstance OPTIONAL,
[5] IMPLICIT GeneraüzedTime OPTIONAL )
currentTime
EventReply ::= SEQUENCE ( eventType Even tTypeld,
eventReplyInfo [SI ANY DEF2NED BY event'ïype OPTIONAL 1
EventReportArgument ::= SEQWNCE ( managedObjectClass Objectclass,
managedObjectInstance ObjectInstance,
eventTime [SI IMPLICIT GeneralizedTime OPTIONAL,
even tType Even tTypeId,
eventInfo [SI ANY DEPINED BY eventType OPTIONAL )
EventReportResult ::= SEQUENCE ( managedOhjectClass Objectclass OPTIONAL,
managedobjectlnstance ObjectInstance OPTIONAL,
currentTime [5] IMPLICIT GeneraijzedTinie OPTIONAL,
eventReply EventReply OPTIONAL )
EventTypeId ::= CHOICE ( globaLForm [6] IMPLICIT OBJECT IDENTIFIER,
1ocalForm [7] UlPLIClT "EGER )
-- This International Standard does not allocate any values for IocalForm
-- where this alternative is used, the permissible values for the integers and their meanings
-- shall be defined as part of the application context in which they are used
ISO/IEC 9596 : 1990 (E)
FilterItem ::= CHOICE (
equality [O] IMPLICIT Attribute,
substrings [ 11 IMPLICIT SEQUENCE OF CHOICE [
initialString [O] IMPLICIT SEQUENCE (
attilbuteId AttributeId,
string ANY DEFINED BY attributeId ),
anystring [l] lMPLICiTSEQUENC!El(
attributeld AttributeId,
string ANY DEFINED BY attributeId ) ,
finalstring [2] IMPLICiTSEQuENcE {
attributeId AttributeId,
string ANY DEPINED BY attributeId) ),
greatetOrEqua1 [2] IMPLICIT Attribute, -- asserted value 2 attribute value
IessOrEqual [3] IMPLICIT Attribute, -- asserted value 2 attribute value
present [4] AttributeId,
subsetof [5] IMPLICIT Attribute, -- asserted value is a subset of attribute value
supersetof [6] IMPLICIT Attribute, -- asserted value is a superset of attribute value
nonNullSetIntersection [7] IMPLICIT Attribute ]
GetArgument ::= SEQUENCE { COMpoNEpIvrS OF BaseManagedObjectId,
accessContro1 [5 ] AccessControl OPTIONAL,
synchronization [6] IMPLICIT CMISSync DEFAULT bestEffort,
scope [7] Scope DEFAULT baseobject,
filter CMISFilter DEFAULT and [ ) ,
attributeIdList [ 121 IMPLICIT SET OF AttributeId OPTIONAL )
GetInfoStatus ::= CHOICE { attributeIdError
[O] IMPLICIT AttributeIdError,
attribute [l] IMPLICIT Attribute )
GetListError ::= SEQUENCE ( managedObjectClass Objectclass OPTIONAL,
managedObjectInstance ObjectInstance OPTIONAL,
currentTinie [5] IMpLIclT GeneralizedTime OPTIONAL,
get InfoLi s t [6] IMPLICIT SET OF GetInfoStatus )
GetResult ::= SEQUENCE ( managedObjectClass Objectclass OPTIONAL,
managedObjectInstance ObjectInstance OPTIONAL,
currentTime [5] WLIClT GeneraiizedTinie OPTIONAL,
attributeList [6] IMPLICIT SET OF Attribute OFTIONAL )
InvaiidArgumentVdue ::= CHOICE ( actionvalue [O] IMPLICIT ActionInfo,
eventvalue [1 ] IMPLICIT SEQUENCE (
eventType EventTypeId,
eventhfo [8] ANY DE- BY eventType OPTIONAL 1 )
LinkedReplykgument ::= CHOICE ( getResult [O] IMPLICIT GetResult,
ge tLi stError [ 1 ] IhPLICIT GetListError,
setResult
[2] iMPLICIT SetResult,
setListError [3] IMPLICIT SetListError,
actionResult [4] IMPLICIT ActionResult,
processingFailure [5] IMPLICIT ProcessingFailure.
deleteResult [6] IMPLICIT DeleteResult,
actionError
[7] IMPLICIT ActionError,
dele teError [I?] IMPLICIT DeleteError )
NoSuchAction ::= SEQUENCE [ managedObjectClass
Objectclass,
actionType ActionTypeId )
NoSuchkgurnent ::= CHOICE ( actionId
[O] IMPLICIT SEQUENCE [
managedObjectClass Objectclass OPTIONAL,
),
ac tionType ActionTypeId
eventId [l] iMPLICIT SEQUENCE [
managedObjectClass Objectclass OPTIONAL,
even tType EventTypeId ) )
NoSuchEventType ::= SEQUENCE ( managedObjectClass
Objectclass,
eventType EventTypeId )
ISOAEC 9596 : 1990 (E)
[O] IMPLICIT OBJECT ID-,
Objectclass ::= CHOICE ( globalPonn
localForm [ 11 IMPLICIT INTEGER J
-- This International Standard does not allocate any values for 1ocalForm.
-- where this alternative is used, the permissible values for the integers and their meanings
-- shall be defined as pari of the application context in which they are used
::= CHOICE ( distinguishedh'ame [2] IMPLICIT Distinguishername,
Objecthstance
nonSpecificForm [3] IMPLICIT OCTET STRING,
[4] JMPLICl" RDNSequence )
1ocalDistinguishedName
-- IocalDistinguishedName is that portion of the distinguished name that is necessary to unambiguously
-- identify the managed object within the context of communication between the open systems
ProcessingFaiiure ::= SEQUENCE ( managedObjectClass Objectclass,
managedobjecthstance ObjectInstance OPTIONAL,
[SI ANY DEFINED BY managedObjectClass
specificErrorIn f o
Scope ::= CHOICE ( INTEGER ( baseobject (O),
firstLevelOnly (l),
wholesubtree (2) 1,
individualLevels [il IMPLICïï INTEGER, -- POSITIVE integer indicates the level to be selected
-- POSITIVE integer N indicates that the range of levels
baseToNthLeve1 [2] IMpLI(ITT INTEGER J
-- (O - N) is to be selected
-- with individuallevels and baseToNthLeve1, a value of O has the sanie semantics as baseobject
-- with individuallevels, a value of 1 has the same semantics as firstLevelOnly
SetArgument ::= SEQUENCE ( COMPONENTS OF BaseManagedObjectId,
acce s sCon trol [5] AccessControl OIPIIONAL,
[6] IMPLICIT CMISSync DEFAULT bestEffort,
synchronization
scope [7] Scope DEFAULT baseobject,
f
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...