ISO/IEC 13712-3:1995
(Main)Information technology — Remote Operations: OSI realizations — Remote Operations Service Element (ROSE) protocol specification
Information technology — Remote Operations: OSI realizations — Remote Operations Service Element (ROSE) protocol specification
Specifies the protocol and procedures for the Remote Operation Service Element. The ROSE procedures are defined in terms of the interactions between peer ROSE protocol machines through the use of RTSE services or the Presentation service and the interactions between the ROSE protocol machine and its service-user. Specifies conformance requirements for systems implementing these procedures.
Technologies de l'information — Opérations distantes: Réalisations OSI — Spécification du protocole de l'élément de service d'opérations distantes (ROSE)
General Information
Relations
Standards Content (Sample)
INTERNATIONAL
ISOAEC
STANDARD
13712-3
First edition
1995-04-15
Corrected and reprinted
1995-09-15
Information technology - Remote
Operations: OSI realizations - Remote
Operations Service Element (ROSE) protocol
specification
Technologies de l’information - Opkations ti distance: R6alisations
OS/ - Spkcification du protocole pour l%le’ment de Service des
ope’ra tions 5 distance (ROSE)
Reference number
PSO/IEC 13712-3:1995(E)
ISO/IEC 13712-3: 1995(E)
Conte&
Page
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.*.
1 Scope
Normative references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 Identical Recommendations I International Standards
. . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Paired Recommendations I International Standards equivalent in technical content
2.3 Additional references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.*.*.
3.1 Reference model definitions
Service conventions definitions . . . . . . . . . . .‘.
3.2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
3.3 Presentation Service definitions
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Association control definitions
3.5 Reliable transfer definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6 ROSE Service definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7 Remote Operation protocol specification definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
4.1 Data units . . . . . . . . . . . . . . . . . . . .*.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Types of application-protocol-data-units
4.3 Other abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
Service Provision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62 . Association and transfer Services
63 . Protocol model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 Basic ROSE elements of procedure
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .~.
7.1 Association-establishment
7.2 Association-release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3 Association-abort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4 Invocation
7.5 Return-result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .~.
7.6 Return-error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .~.
7.7 User-reject .
7.8 Provider-reject .
Association realizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .~.
8.1 Introduction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 Association realization by ACSE
8.3 Association realization by RTSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
o ISO/IEC 1995
All rights reserved. Unless otherwise specified, no gart of this publication may be
reproduced or utilized in any form or by any means, electronie or mechanical, including
photocopying and microfilm, without Permission in writing from the publisher.
ISO/IEC Copyright Office l Case postale 56 l CH-121 1 Geneve 20 l Switzerland
Printed in Switzerland
o ISO/IEC ISO/IEC 13712-3: 1995(E)
Page
9 Transfer realizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1 Introduction
9.2 P-DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3 RT-TRANSFER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10 Abstract syntaxes .
10.1 Introduction . 23
10.2 Bind Operation . 23
................................................................................................................................ 24
10.3 Unbind Operation
10.4 Other operations .
10.5 Defining the abstract syntaxes .
11 Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.1 Statement requirements
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.2 Static requirements
. . . . . . . . . . . . .*.*. 25
11.3 Dynamit requirements
Annex A - ROPM State Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A. 1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.3 Actions to be taken by the ROPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.4 Tables
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Annex B - ASN.1 Modules
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Annex C - Guidelines for the use of the notation
. . . . . . . . . . . . . . . . . . . .*.
Annex D - Assignment of Object identifier values
. . .
ISO/IEC 13712-3: 1995(E) o ISO/IEC
Foreword
ISO (the International Organization for Standardization) and IEC (the Inter-
national Electrotechnical Commission) form the specialized System for worldwide
standardization. National bodies that are members of ISO 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.
ISO and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with
ISO and IEC, also take part in the work.
In the field of information technology, ISO 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 % of the national
bodies casting a vote.
International Standard ISO/IEC 137 12-3 was prepared by Joint Technical
Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 21, Open
Systems Interconnection, data management and open distributed processing, in
collaboration with ITU-T. The identical text is published as ITU-T
Recommendation X.882.
This part of ISO/IEC 137 12 is a partial revision of ISO/IEC 9072-2: 1989.
ISO/IEC 137 12 consists of the following Parts, under the general title Information
technology - Remote operations:
- Part 1: Concepts, model and notation
- Part 2: OSI realizations - Remote Operations Service Element (ROSE)
Service definition
- Part 3: OSI realizations - Piernote Operations Service Element (ROSE)
protocol specification
Annexes A and B form an integral part of this part of ISOKIEC 137 12. Annexes C
and D are for information only.
IV
o ISO/IEC
ISO/IEC 13712-3: 1995(E)
Introduction
Remote operations (ROS) is a paradigm for interactive communication between objects. As such it tan be used in the
design and specification of distributed applications. The basic interaction involved is the invocation of an Operation by
one Object (the invoker), its Performance by another (the Performer), possibly followed by a report of the outcome of the
Operation being returned to the invoker.
The concepts of ROS, as specified in ITU-T Rec. X.880 1 ISOLIEC 13712-1, are abstract, and may be realized in many
ways. For example, objects whose interactions employ ROS concepts may be separated by a Software interface or by an
OS1 network.
ITU-T Rec. X.881 I ISO/IEC 13712-2 provides the framework for the realization of an association contract as an OS1
application context. Such an application context is specified primarily in terms of a collection of application Service
elements. From a ROS perspective, these ASEs fall into three broad categories:
Operation-specific ASEs, which embody knowledge of the definitions of the operations in the contract;
a>
b) the Remote Operations ASE (ROSE) which drives the general-purpose protocol required to invoke and
report returns of arbitrary operations;
information transfer ASEs concerned with the establishment and release of associations where necessary,
C>
and the communication of the ROSE protocol information.
This Recommendation I International Standard describes the behaviour of ROSE itself, and the way in which different
collections of information transfer ASEs (specifically, the Reliable Transfer Service Element (RTSE) and the
Association Control Service Element (ACSE)) are employed to transfer its protocol control information (PCI) in an OS1
realization.
This Recommendation I International Standard is a revision of CCITT Rec. X.229 I ISO/IEC 9072-2. The existing usage
of ROSE in conjunction with ACSE, RTSE and the Presentation layer as defined in CCITT Rec. X.229 I
ISO/IEC 9072-2 remains valid after this revision. In addition, this revision makes no Change to the ROSE PCI.
This page intentionally left blank
ISO/IEC 13712-3 : 1995 (E)
INTERNATIONAL STANDARD
IT&T RECOMMENDATION
REMOTE OPERATIONS: OS1 REALIZATIONS -
INFORMATION TECHNOLOGY -
REMOTE OPERATIONS SERVICE ELEMENT (ROSE) PROTOCOL SPECIFICATION
1 Scope
This Recommendation I International Standard specifies the protocol (abstract Syntax) and procedures for the Remote
Operation Service Element. The terms, definitions and mechanisms defined in ITU-T Rec. X.880 I ISO/IEC 13712-1
apply here and are specialized for an OS1 realization as specified in this Recommendation I International Standard. The
ROSE Services, defined in ITU-T Rec. X.88 1 I ISO/IEC 137 12-2, at-e provided in conjunction with the Association
Control Service Element (ACSE) Services (ITU-T Rec. X.217 I ISO 8649) and the ACSE protod (ITU-T
Rec. X.227 I ISO 8650), optionally the Reliable Transfer Service Element (RTSE) Services (ITU-T Rec. X.218 I
ISO/IEC 9066-1) and the RTSE protocol (ITU-T Rec. X.228 I ISO/IEC 9066-2), and the Presentation Service (ITU-T
Rec. X.216 I ISOLIEC 8822 ).
The ROSE procedures are defined in terms of:
the interactions between peer ROSE protocol machines through the use of RTSE Services or the
a>
Presentation Service;
the interactions between the ROSE protocol machine and its service-user.
b)
International Standard specifies conformance requirements for Systems implementing these
This Recommendation I
procedures.
2 Normative references
The following ITU-T Recommendations and International Standards contain provisions which, through reference in this
text, constitute provisions of this Specification. At the time of publication, the editions indicated were valid. All Recom-
mendations and Standards are subject to revision, and Parties to agreements based on this Specifkation are encouraged
to investigate the possibility of applying the most recent editions of the Recommendations and Standards indicated
below. Members of IEC and ISO maintain registers of currently valid International Standards. The Telecommunications
Standardization Bureau of the ITU maintains a list of currently valid ITU-T Recommendations.
. Identical Recommendations I International Standards
-
ITU-T Recommendation X.200 (1994) l ISOLIEC 7498-1: 1994, Informution technology - Open Systems
Interconnection - Basic Reference Model: The Basic Model.
-
ITU-T Recommendation X.210 (1993) I ISO/IEC 1073 1: 1994, Information technology - Open Systems
- Basic Reference Model - Conventions for the definitions of ON Services.
Interconnection
-
‘>, Informution processing systems - Open Systems
ITU-T Recommendation X.215 (1994) I ISO 8326:-
Interconnection - Basic connection oriented Session Service decfinition.
-
ITU-T Recommendation X.216 (1994) I ISO/IEC 8822: 1994, Information technology - Open Systems
Interconnection - Presentation Service definition.
- ITU-T Recommendation X.217 (1995) I ISO 8649:- 2), Informution processing systems - Open Systems
Interconnection - Service definition for the Association Control Service Element.
-
3), Informution processing systems - Open Systems
ITU-T Recommendation X.227 (1995) I ISO 8650:-
Interconnection - Protocol specljkation for the Association Control Service Element.
-
ITU-T Recommendation X.680 (1994) I ISOLIEC 8824-1: 1995, Information technology - Abstract Syntax
Notation One (ASN.1): Specijkation of basic notation.
1) To be published. (Revision of ISO 8326: 1987)
2) To be published. (Revision of ISO 8649:1988)
3) To be published. (Revision of ISO 8650:1988)
ITU-T Rec. X.882 (1994 E) 1
ISO/IEC 13712-3 : 1995 (E)
-
ITU-T Recommendation X.68 1 (1994) I ISO/IEC 8824-2: 1995, Information technology - Abstract Syntax
Notation One (ASN. I): Information Object speciflcation.
-
ITU-T Recommendation X.682 (1994) I ISO/IEC 8824-3: 1995, Information technology - Abstract Syntax
Notation One (ASN. 1): Constraint specification.
-
ITU-T Recommendation X.683 (1994) I ISO/IEC 8824-4: 1995, Information technology - Abstract Syntax
Notation One (ASN. 1): Parametrization of ASN. 1 specifications.
-
ITU-T Recommendation X.690 (1994) I ISO/IEC 8825- 1: 1995, Information technology - ASN. I encoding
rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER}.
-
ITU-T Recommendation X.880 (1994) I ISOLIEC 13712-1:1995, Information technology - Remote
Operations: Concepts, model and notation.
-
ITU-T Recommendation X.881 (1994) I ISO/IEC 13712-2:1995, Information technology - Remote
Operations: OSI realizations - Remote Operations Service Element (ROSE} Service deflnition.
.
22 . Paired Recommendations I International Standards equivalent in technical content
-
ITU-T Recommendation X.2 18 (1993), Reliable transfer: Model and Service definition.
ISO/IEC 9066-1: 1989, Information processing Systems - Text communication - Reliable transfer -
Part 1: Model and Service definition.
-
ITU-T Recommendation X.228 (1988), Reliable transfer: Protocol specification.
ISOIIEC 9066-211989, Information processing Systems - Text communication - Reliable transfer -
Part 2: Protocol specifkation.
-
CCITT Recommendation X.219 (1988), Remote operations: Model, notation and Service definition.
ISO/IEC 9072-1: 1989, Information processing Systems - Text communication - Remote operations -
Part 1: Model, notation and Service definition.
-
CCITT Recommendation X.229 (1988), Remote operations: Protocol specification.
ISO/IEC 9072-2:1989, Information processing Systems - Text communication - Remote operations -
Part 2: Protocol specification.
23 . Additional references
-
CCITT Recommendation X.410 (1984), Message handling Systems: Remote operations and reliable
transfer Service
3 Definitions
Reference model definitions
31 .
This Recommendation I International Standard is based on the concepts developed in ITU-T Rec. X.200 I ISO/IEC 7498-1
and makes use of the following terms defined in it:
application layer;
a>
application-process;
b)
application-entity;
application-service-element;
application-protocol-data-unit;
application-protocol-control-information;
presentation-Service;
h) presentation-connection;
Session-Service;
.
Session-connection; and
J)
transfer Syntax.
k)
2 ITU-T Rec. X.882 (1994 E)
ISO/IEC 13712-3 : 1995 (E)
32 . Service conventions definitions
This Recommendation I International Standard makes use of the following terms defined in ITU-T Rec. X.210 I
ISO/IEC 1073 1:
service-provider;
a>
service-user;
W
confirmed Service;
C>
non-confirmed Service;
d)
provider-initiated Service;
e)
primitive;
request (primitive);
g)
indication (primitive);
h)
response (primitive); and
.
tonfirm (primitive).
J)
33 . Presentation Service definitions
This Recommendation I International Standard makes use of the following terms defined in ITU-T Rec. X.216 I
ISO/IEC 8822:
abstract Syntax;
a>
b) abstract Syntax name;
c) presentation context;
d) defined context set.
34 . Association control definitions
This Recommendation I International Standard makes use of the following terms defined in ITU-T Rec. X.217 I
ISO 8649:
application-association; association;
a>
b) application context;
association control Service element.
Cl
35 .
Reliable transfer defmitions
This Recommendation l International Standard makes use of the following terms defined in CCITT Rec. X.218 I
ISO/IEC 9066- 1:
-
Reliable Transfer Service Element.
. ROSE Service definitions
This Recommendation I International Standard makes use of the following terms defined in ITU-T Rec. X.881 I
ISO/IEC 13712-2:
association-initiating-application-entity; association-initiator;
a>
b) association-responding-application-entity; association-responder;
invoking-application-entity; invoker;
C)
d) performing-application-entity; Performer;
requestor;
d
acceptor;
g) linked-operations;
h) parent-Operation;
ITU-T Rec. X.882 (1994 E) 3
ISO/IEC 13712-3 : 1995 (E)
Child-Operation;
.
remote Operation Service element;
J)
k) ROSE-provider;
ROSE-User;
1)
m) RTSE-User.
37 . Remote Operation protocol specification definitions
For the purpose of this Recommendation I International Standard the following definitions apply:
3.7.1 remote-Operation-protocol-machine: The protocol machine for the remote Operation Service element
specified in this Recommendation I International Standard.
3.7.2 requesting-remote-Operation-protocol-machine: The remote-Operation-protocol-machine whose service-
user is the requestor of a particular remote Operation Service element Service.
3.7.3 accepting-remote-Operation-protocol-machine: The remote-Operation-protocol-machine whose service-user
is the acceptor for a particular remote Operation Service element Service.
4 Abbreviations
Data units
41 .
APDU Application-protocol-data-unit
PC1 Protocol control information
PDV Presentation data value
42 . Types of application-protocol-data-units
The following abbreviations have been given to the application-protocol-data-units defined in this Recommendation I
International Standard:
Invoke RO-INVOKE Service application-protocol-data-unit
ReturnResult RO-RESULT Service application-protocol-data-unit
ReturnError RO-ERROR Service application-protocol-data-unit
Reject RO-REJECT-U/P Service application-protocol-data-unit
43 . Other abbreviations
The following abbreviations are used in this Recommendation I International Standard:
AE Application entity
ACSE Association control Service element
ASE Application Service element
ASN. 1 Abstract Syntax Notation One
RO (or ROS) Remote Operations
Remote Operations Protocol Machine
ROPM
Remote Operations Service Element
ROSE
RT (or RTS) Reliable Transfer
RTSE Reliable Transfer Service Element
4 ITU-T Rec. X.882 (1994 E)
ISO/IEC 13712-3 : 1995 (E)
5 Conventions
This Recommendation I International Standard employs a tabular presentation of the Parameters of its pseudo-primitives
and for the fields of its APDUs. In clause 7, tables are presented for each pseudo-primitive and each ROSE APDU. Esch
Parameter or field is summarized using the following notation:
blank Not applicable
M Presence is mandatory
U Presence is a ROSE-User Option
C Conditional
Source is related request primitive
req
ind Sink is related indication primitive
resp Source is related response primitive
conf Sink is related tonfirm primitive
Source or sink is the ROPM
SP
In addition, the notation (=) indicates that a Parameter value is semantically equal to the value to its left in the table.
This Recommendation I International Standard employs ASN. 1, as specified in ITU-T Rec. X.681 I ISO/IEC 8824-2, to
define the REALIZATION information Object class. It also provides notation by which designers of ROS realizations tan
specify particular instances of the class.
The structure of each ROSE APDU is specified in ITU-T Rec. X.880 I ISO/IEC 13712-1 using ASN.l.
6 Overview
61 . Service Provision
The protocol specified in this Recommendation I International Standard provides the ROSE Services defined in ITU-T
Rec. X.881 I ISO/IEC 13712-2. These Services are listed in Table 1 reproduced from Table 1 of ITU-T Rec. X.881 I
ISO/IEC 13712-2.
Table 1 - ROSE Services
Service
Type
RO-INVOKE Non-confirmed
RO-RESULT Non-confirmed
RO-ERROR Non-confirmed
Non-confirmed
RO-REJECT-U
RO-REJECT-P Provider-initiated
RO-BIND Confirmed
RO-UNBIND Confirmed
62 . Association and transfer Services
The ROSE protocol specified herein needs a transfer Service to pass information in the form of ROSE APDUs between
peer application-entities, and, if a connection package is involved in the association contract, an association Service to
establish and release associations between the application-entities. These Services are provided by use of various ASEs
together with the OS1 Presentation Service.
ITU-T Rec. X.882 (1994 E) 5
ISO/IEC 13712-3 : 1995 (E)
This specification is structured into the description of a generic protocol (see clause 7), together with a number of
specific realizations of the association Service (see clause 8) and of the transfer Service (see clause 9). The generic
protocol is independent of the particular realizations Chosen.
NOTE - It is envisaged that other association and transfer realizations may be defined, both as future extensions to this
Standard, and on a proprietary basis.
Two specific association realizations are included, one based upon ACSE and one on RTSE. Two specific transfer
realizations are included, based respectively on the use of P-DATA and RT-DATA to transfer the APDUs.
63 . Protocol model
The Services of ROSE, as defined in ITU-T Rec. X.881 I ISO/IEC 13712-2, are provided by the Remote Operations
Protocol Machine (ROPM). The ROPM uses the Services provided by the OS1 Presentation Service provider, together
with a collection of ASEs which shall include an a-ASE, may include a z-ASE, and may also include ASEs supporting
these. The collection always includes ACSE. Different OS1 realizations of ROS result from the use of different
collections.
This model is depicted in Figure 1.
ti
PRESENTATION-SERVICE PROVIDER
I
TIS04470-94/dOl
ASE providing association establishment and release
a-ASE
z-ASE ASE providing information transfer
ROPM
Remote Operations protocol machine
O-ASEs Operation-specific ASEs
Figure 1 - Protocol model
In general, ROSE does not assume that it has exclusive use of the Services of the a-ASE, z-ASE, supporting ASEs, or
the Presentation layer. Furthermore, the use of Service Parameters whose values are unconstrained by the ROSE protocol
specification tan be specified as appropriate by the application context designer. Any exceptions to this are indicated in
the specification of the appropriate realization.
6 ITU-T Rec. X.882 (1994 E)
ISO/IEC 13712-3 t 1995 (E)
7 Basic ROSE elements of procedure
The basic ROSE protocol consists of the following elements sf procedure:
association-establishment;
a)
b) association-release;
association-abort;
C>
d) invocation;
return-result;
e>
return-error;
fl
g) user-reject;
h) provider-reject.
In the following subclauses, a specification of each of these elements of procedure is presented. In so doing, a number of
nseudo-mimitives are used to describe the use of the association and transfer Services. Esch realization of these Services
I
in clauses 8 and 9 describes the actual primitives which are used if that realization is employed.
For the association Services, the pseudo-primitives are shown in Table 2.
Table 2 - Pseudo-primitives for association realizations
Pseudo-primitive conf.
Assumed Service req. ind. resp.
Association establishment ESTABLISH
application context M
MC=)
release tan fail M C
C(=>
user data U U
c(=)
C(=>
M
result
W=)
Association release RELEASE
user data U
c(=>
c(=>
result M
M(=)
Association abort-user ABORT
M
Source
user data
C(=>
ABORT-P
Association abort-provider
provider reason C
The result Parameter of ESTABUSH takes the symbolic values “accepted” and “rejected”.
In successive primitives of this Service, the
The release tan fail Parameter takes the symbolic values “true” and “false”.
value of the Parameter tan Change from “true” to “false” but not vice versa. This Parameter is present on the response or
tonfirm if and only if the result Parameter takes the value “accepted”.
“rejected-released” and “rejected-not-
The result Parameter of RELEASE takes the three symbolic values “accepted”,
released”.
The Source Parameter of the ABORT takes the symbolic values “association-control service-user” or “association-control-
service-provider.
The value of user information Parameter depends on the application context in place.
The provider-reason Parameter of the ABORT-P takes the symbolic values defined in ITU-T Rec. X.216 I ISOLIEC 8822.
ITU-T Rec. X.882 (1994 E) 7
ISO/IEC 13712-3 : 1995 (E)
For the transfer Services, the pseudo-primitives are shown in Table 3.
Table 3 - Assumed primitives for transfer realizations
Pseudo-primitive ind.
Assumed Service req.
Information transfer TRQNSFER
user-data M
MC=)
L.
The use of the components of the various APDUs are described in this clause. In ITU-T Rec. X.880 I ISO/IEC 13712-1,
the data types corresponding to these APDUs are specified using ASN. 1.
Association-establishment
71 .
7.1.1 Purpose
The attempted establishment of an association through the invocation of a bind Operation.
7.1.2 APDUs used
The association-establishment procedure uses the BindInvoke, BindResult, and BindError APDUs. These APDUs are
defined if and only if, respectively, the &ArgumentType, &ResultType and &ParameterType fields are defined for the
bind Operation and its associated error used in the connection package that is used for dynamic association control
(see ITU-T Rec. X.880 I ISO/IEC 13712-1 for a definition of the corresponding information Object classes).
7.1.2.1 BindInvoke
The BindInvoke APDU is used in the request to establish an association. The fields of this APDU are listed in Table 4.
Table 4 - BindInvoke APDU Gelds
Field name Presence Source Sink
Argument U req. ind.
, 4
The Argument field is derived from the &ArgumentType field of the bind Operation.
7.1.2.2 BindResult
The BindResult APDU is used to indicate the successful establishment of an association. The fields of this APDU are
listed in Table 5.
The Result field is derived from the &ResultType field of the bind Operation.
Table 5 - BindResult APDU fields
Presence Source Sink
Field name
U resp. conf.
Result
ITU-T Rec. X.882 (1994 E)
ISO/IEC 13712-3 : 1995 (E)
7.1.2.3 BindError
The BindErrorAPDU is used to indicate that the attempt to establish an association was unsuccessful. The fields of this
APDU are listed in Table 6.
The Error-Parameter field is derived from the &ParameterType field of the error associated with the bind Operation.
Table 6 - BindError APDU fields
Field name Presence Source Sink
Error-Parameter U resp. conf.
7.1.3 Association-establishment procedure
This procedure is driven by the following events:
an RO-BIND request;
a>
b) a BindInvoke APDU as user data on an ESTABLZSH indication primitive;
an RO-BIND response with outcome of “result”;
Cl
d) a BindResult APDU as user data on an ESTABLZSH tonfirm primitive with result of “accepted”.
an RO -BIND response with outcome of “error”;
e>
a BindError APDU as user data on an ESTABLZSH tonfirm primitive with result of “rejected”.
f)
Sending the BindInvoke APDU or BindResult APDU or BindError APDU is optional when, respectively, the
&argumentTypeOptional or &resultTypeOptional or ¶meterTypeOptional fields of the bind Operation and error are
set to TRUE.
7.1.3.1 RO-BIND request
The requesting ROPM forms a BindInvoke APDU from the Argument Parameter of the RO-BIND request, and conveys
it in the user-data Parameter of an ESTABLZSH request. The release tan fail Parameter takes its settings from the
&unbindCanFail field of the connection package identified by the application context Parameter.
7.1.3.2 BindInvoke APDU
The accepting ROPM issues an RO-BIND indication, whose Argument Parameter is derived from the BindInvoke
APDU.
7.1.3.3 RO-BIND response with outcome of “result”
The accepting ROPM forms a BindResult APDU from the Bind-Result Parameter of the RO-BIND response, and
conveys it in the user-data Parameter of an ESTABLZSH response whose result Parameter takes the value “accepted”. The
unbind tan fail Parameter of the RO-BIND response governs the setting of the release tan fail Parameter of the
ESTABLZSH response.
7.1.3.4 BindResult APDU
The requesting ROPM issues an RO-BIND tonfirm, whose Bind-Result Parameter is derived from the BindResult
APDU.
7.1.3.5 RO-BIND response with outcome of “error”
The accepting ROPM forms a BindError APDU from the Bind-Error Parameter of the RO-BIND response, and conveys
it in the user-data Parameter of an ESTABLZSH response.
ITU-T Rec. X.882 (1994 E) 9
ISO/IEC 13712-3 : 1995 (E)
7.1.3.6 BindError APDU
The requesting ROPM issues an RO-BIND tonfirm, whose Bind-Error Parameter is derived from the BindError APDU.
72 . Association-release
7.2.1 Purpose
The attempted release of an association through the invocation of an unbind Operation.
7.2.2 APDUs used
The association-release procedure uses the UnbindInvoke, UnbindResult, and UnbindError APDUs. These APDUs are
&ArgumentType, &ResultType and &ParameterType Felds are defined for the
defined if and only if, respectively, the
unbind Operation and its associated error used in the connection package that is used for dynamic association control
(see ITU-T Rec. X.880 I ISO/IEC 13712-1 for a definition of the corresponding information Object classes).
7.2.2.1 UnbindInvoke
The UnbindInvoke APDU is used in the request to release an association. The Felds of this APDU are listed in Table 7.
The Argument field is derived from the &ArgumentType field of the unbind Operation.
Table 7 - Unbindhvoke APDU fields
Presence Source Sink
Field name
U req. ind.
Argument
7.2.2.2 UnbindResult
The UnbindResult APDU is used to indicate the successful release of an association. The fields of this APDU are listed
in Table 8.
The Result field is derived from the &ResultType field of the unbind Operation.
Table 8 - UnbindResult APDU fields
Sink
Field name Presence Source
Result U resp. conf.
7.2.2.3 UnbindError
The UnbindErrorAPDU is used to indicate that the request to release an association is refused. The fields of this APDU
are listed in Table 9.
The Parameter field is derived from the &ParameterType field of the error associated with this unbind Operation.
Table 9 - UnbindError APDU Felds
Presence Source Sink
Field name
U resp. conf.
Parameter
ITU-T Rec. X.882 (1994 E)
ISOLIEC 13712-3 : 1995 (E)
Association-release procedure
7.2.3
This procedure is driven by the following events:
an RO-UNBIND request;
a>
b) an UnbindInvoke APDU as user data on an RELEASE indication primitive;
c) RO-UNBIND response with outcome of “result”;
d) an UnbindResult APDU as user data on an RELEASE tonfirm primitive with result of “success”.
e) RO-UNBIND response with outcome of “error-beund” or “error-unbeund”
an UnbindError APDU as user data on an RELEASE tonfirm primitive with result of “failure”.
fl
Sending the UnbindInvoke APDU or UnbindResult APDU or UnbindError APDU is optional when, respectively, the
&argumentTypeOptional or &resultTypeOptional or ¶meterTypeOptional fields of the unbind Operation or its
associated error is set to TRUE.
7.2.3.1 RO-UNBIND request
The requesting ROPM forms an UnbindInvoke APDU from the Argument Parameter of the RO-UNBIND request, and
conveys it in the user data Parameter of a RELE’ASE request.
7.2.3.2 UnbindInvoke APDU
The accepting ROPM issues an RO-UNBIND indication, whose Argument Parameter is derived from the UnbindInvoke
APDU.
7.2.3.3 RO-UNBIND response with outcome of “result”
The accepting ROPM forms an UnbindResult APDU from the Unbind-Result Parameter of the RO-UNBIND response
and conveys it in the user-data Parameter of a RELEASE response.
7.2.3.4 UnbindResult APDU
whose Unbind-Result Parameter is derived from the
The requesting ROPM issues an RO-UNBIND tonfirm,
UnbindResult APDU.
7.2.3.5 RO-UNBIND response with outcome of “error-beund” or “errorunbeund”
The accepting ROPM forms an UnbindError APDU from the Unbind-Error Parameter of the RO-UNBIND response,
and conveys it in the user-data Parameter of an RELEASE response. If the outcome of “error-beund” occurs, the
association continues to exist.
7.2.3.6 UnbindError APDU
The requesting ROPM issues an RO-UNBIND tonfirm with outcome of “error-beund” or “error-unbeund”, and whose
Unbind-Error Parameter is derived from the UnbindError APDU. If the outcome of “error-beund” occurs, the association
continues to exist.
73 . Association-abort
7.3.1 Association-abort purpose
The abnormal release of an association by the association control Service user or the association control Service provider.
NOTE - This may also occur as a result of an event signalled by the underlying communications infrastructure.
7.3.2 Association-abort-procedures
The association abort procedures is driven by the following events:
an ABORT request or indication primitive; or
b) an ABORT-P indication primitive.
Case a) Signals the abnormal release of an association by the association service-user or the association-control-Service
provider. Case b) Signals the release of the association because of an abnormal event signalled by the underlying
communications infrastructure. The association is released immediately and any PDUs in transit are lost.
ITU-T Rec. X.882 (1994 E) 11
ISO/IEC 13712-3 : 1995 (E)
74 Invocation
.
7.4.1 Purpose
The invocation procedure is used by one AE (the invoker) to request an Operation to be performed by the other AE (the
Performer).
APDUs used
7.4.2
The invocation procedure uses the Invoke APDU. The fields of the Invoke APDU are listed in Table 10.
Table 10 - Invoke APDU fields
Presence Source Sink
Field name
M req. ind.
Invoke-id
ind.
Linked-id U req.
M req. ind.
Operation-id
ind.
Argument U req.
7.4.3 Invocation procedure
This procedure is driven by the following events:
an RO-INVOKE request primitive from the requestor;
a>
b) an Invoke APDU as user-data of a 7KWSFER indication primitive.
7.4.3.1 RO-INVOKE request primitive
The requesting ROPM forms an Invoke APDU from the Parameter values of the RO-INVOKE request primitive. It
issues a TRANSFER request primitive. The user-data Parameter of the TRANSFER request primitive contains the I
...
NORME
ISO/CEI
INTERNATIONALE
13712-3
Première édition
1995-04-15
Technologies de l’information -
Opérations distantes: Réalisations OSI -
Spécification du protocole de l’élément de
service d’opérations distantes (ROSE)
Information technology - Remote Opera tions: OSI realizations -
Remote Operations Service Element (ROSE) protocol specification
Numéro de référence
ISO/CEI 13712-3:1995(F)
ISOKEI 13712-3: 1995(F)
Sommaire
Page
Domaine d’application .
...................................................................................................................................
Références normatives
2.1 Recommandations I Normes internationales identiques .
....... 2
2.2 Paires de Recommandations I Normes internationales équivalentes par leur contenu technique
Références additionnelles .
2.3
Définitions .
....................................................................................................
3.1 Définitions du modèle de référence
3.2 Définitions des conventions du service .
................................................................................................ 3
3.3 Définitions du service de présentation
Définitions du contrôle d’association .
3.4
3.5 Définitions du transfert fiable .
..............................................................................................................
3.6 Définitions du service ROSE
....................................................
3.7 Définitions de la spécification du protocole d’opérations distantes
Abréviations .
4.1 Unités de données .
4.2 Types d’unités de données de protocole d’application .
4.3 Autres abréviations .
....................................................................................................................................................
Conventions
Vue d’ensemble .
..........................................................................................................................
6.1 Fourniture du service
6.2 Services d’association et de transfert .
6.3 Modèle de protocole .
......................................................................................
Eléments de procédure du protocole ROSE de base
7.1 Etablissement d’association .
......................................................................................................................
7.2 Libération d’association
.....................................................................................................
7.3 Rupture intempestive d’association
7.4 Invocation .
7.5 Retour du résultat .
Retour d’erreur .
7.6
7.7 Rejet par l’utilisateur .
7.8 Rejet par le fournisseur .
............................................................................................................................... 19
Réalisation d’associations
Introduction .
8.1
............................................................... 20
82 Réalisation d’une association au moyen de l’élément ACSE
...............................................................
8:3 Réalisation d’une association au moyen de l’élément RTSE
ISOKEI 1995
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publi-
cation ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun
procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans
l’accord écrit de l’éditeur.
ISO/CEI Copyright Office l Case Postale 56 l CH- 12 11 Genève 20 l Suisse
Version française tirée en 1996
Imprimé en Suisse
ii
ISOKEI 13712-3: 1995(F)
@ ISOKEI
9 Réalisation de transferts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*. 23
9:2 Réalisation d’un transfert au moyen du service P-DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3 RT-TRANSFER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Syntaxes abstraites
10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2 Opération de rattachement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3 Opération de détachement
..,................................................................................................................ 27
10.4 Autres opérations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.5 Définition des syntaxes abstraites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
,.,.,.*.
11 Conformité 28
11.1 Spécifications de déclaration . . . . . . . . . . . . . . . . . . . . .*. 28
11.2 Spécifications statiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3 Spécifications dynamiques 28
Annexe A - Tables d’états des machines protocolaires ROPM . 29
.....................................................................................................................
A. 1 Considérations générales 29
A.2 Conventions . 30
A.3 Actions devant être exécutées par la machine protocolaire ROPM . 30
A.4 Tables . 31
Annexe B - Modules ASN.l . 48
Annexe C - Directives pour l’utilisation de la notation . 50
Annexe D - Affectation des valeurs d’identificateur d’objets . 53
. . .
ISO/CEI 13712-3: 1995(F) @ ISOKEI
Avant-propos
L’ISO (Organisation internationale de normalisation) et la CE1 (Commission
électrotechnique internationale) forment ensemble un système consacré à la
normalisation internationale considérée comme un tout. Les organismes
nationaux membres de I’ISO ou de la CE1 participent au développement de
Normes internationales par l’intermédiaire des comités techniques créés par
l’organisation concernée afin de s’occuper des différents domaines particuliers de
l’activité technique. Les comités techniques de 1’ISO et de la CE1 collaborent
dans des domaines d’intérêt commun. D’autres organisations internationales,
gouvernementales ou non gouvernementales, en liaison avec 1’ISO et la CE1
participent également aux travaux.
Dans le domaine des technologies de l’information, PIS0 et la CE1 ont créé un
comité technique mixte, I’ISOKEI JTC 1. Les projets de Normes internationales
adoptés par le comité technique mixte sont soumis aux organismes nationaux
pour approbation, avant leur acceptation comme Normes internationales. Les
Normes internationales sont approuvées conformément aux procédures qui
requièrent l’approbation de 75 % au moins des organismes nationaux votants.
La Norme internationale ISOKEI 137 12-3 a été élaborée par le comité technique
mixte ISOKEI JTC 1, Technologies de Z’information, sous-comité SC 21,
Interconnexion des systèmes ouverts, gestion des données et traitement distribué
ouvert, en collaboration avec l’IUT-T. Le texte identique est publié en tant que
Recommandation IUT-T X.882.
La présente partie de 1’ISOKEI 13712 est une révision partielle de
1’ISOKEI 9072-2: 1989.
L’ISOKEI 137 12 comprend les parties suivantes, présentées sous le titre général
Technologies de 1 ‘information - Opérations distantes:
Partie 1: Concepts, modèle et notation
- Partie 2: Réalisations OSI - Défînition du service de l’élément de service
d’opérations distantes (ROSE)
- Partie 3: Réalisations OSI - Spécijkation du protocole de l’élément de
service d’opérations distantes (ROSE)
Les annexes A et B font partie intégrante de la présente partie de
I’ISOKEI 13712. Les annexes C et D sont données uniquement à titre
d’information.
iv
0 ISOKEI ISOKEI 13712-3: 1995(F)
Introduction
Le concept d’opérations distantes (ROS) est un paradigme de la communication interactive entre objets. En tant que tel,
il peut être utilisé pour la conception et la spécification des applications réparties. L’interaction de base mise en jeu est
l’invocation d’une opération par un objet (l’invocateur), son exécution par un autre (l’exécutant), éventuellement suivie
par un rapport sur le résultat de l’opération retourne a l’invocateur.
Les concepts d’opérations distantes (ROS), tels qu’ils sont spécifiés dans la Rec. UIT-T X.880 I ISOKEI 13712-1, sont
abstraits et peuvent être réalisés de multiples manieres. Ainsi, les objets dont les interactions mettent en jeu les concepts
d’opérations distantes peuvent être separes par une interface logicielle ou par un réseau OSI.
La Rec. UIT-T X.881 I ISO/CEI 13712-2 fournit le cadre pour la réalisation d’un contrat d’association formant un
contexte d’application OSI. Un tel contexte d’application est spécifié fondamentalement en termes d’une collection
d’éléments de service application (ASE). Dans une optique ROS, ces éléments ASE relèvent de trois grandes catégories:
les éléments ASE propres aux opératio ns, qui contiennent la connaissance relative aux définitions des
a)
opérations du contrat d’association;
b) les éléments ASE d’opérations distantes (ROSE), qui pilotent le protocole général nécessaire à
l’invocation d’opérations quelconques et à l’annonce de leurs résultats;
c) les éléments ASE de transfert d’information qui interviennent dans l’établissement et la libération des
associations, si besoin est, et dans la communication des informations de protocole ROSE.
La présente Recommandation I Norme internationale décrit le comportement de l’elément de service d’opérations
distantes (ROSE) proprement dit, et la manière dont différentes collections d’éléments de service d’application (ASE) de
transfert d’information [et plus précisément l’élément de service de transfert fiable (RTSE) et l’élément de service de
contrôle d’association (ACSE)] sont utilisées pour transférer son information de contrôle de protocole (PCI) dans une
réalisation OSI.
La présente Recommandation I Norme internationale est une révision de la Rec. X.229 du CCITT I ISOKEI 9072-2.
L’utilisation actuelle de l’élément ROSE, conjointement avec les éléments ACSE et RTSE et la couche présentation
définie dans la Rec. X.229 du CCITT I ISOKEI 9072-2, reste valide après cette révision. En outre, cette révision ne
modifie en rien l’information PC1 de l’élément ROSE.
L’Annexe A fait partie intégrante de la présente Recommandation I Norme internationale.
L’Annexe B fait partie intégrante de la présente Recommandation I Norme internationale.
L’Annexe C ne fait pas partie intégrante de la présente Recommandation I Norme internationale.
L’Annexe D ne fait pas partie intégrante de la présente Recommandation I Norme internationale.
Page blanche
ISOKEI 13712-3 : 1995 (F)
NORME INTERNATIONALE
RECOMMANDATION UIT-T
TECHNOLOGIES DE L’INFORMATION -
OPÉRATIONS DISTANTES: RÉALISATIONS OS1 -
SPÉCIFICATION DU PROTOCOLE DE L’ÉLÉMENT DE
SERVICE D’OPÉRATIONS DISTANTES (ROSE)
1 Domaine d’application
La présente Recommandation I Norme internationale spécifie le protocole (syntaxe abstraite) et les procédures
applicables à l’élément de service d’opérations distantes (ROSE). Les termes, définitions et mécanismes définis dans la
Rec. UIT-T X.880 I ISOKEI 13712-1 sont applicables ci-après et sont spécifiques d’une réalisation OS1 conforme à la
présente Recommandation I Norme internationale. Les services ROSE, définis dans la Rec. UIT-T X.881 I ISOKEI
13712-2, sont fournis en liaison avec les services de l’élément de service de contrôle d’association (ACSE) (Rec. UIT-T
X.217 I ISO/CEI 8649) et le protocole ACSE (Rec. UIT-T X.227 I ISOKEI 8650-l), optionnellement avec les services
de l’élément de service de transfert fiable (RTSE) (Rec. UIT-T X.21 8 I ISOKEI 9066- 1) et le protocole RTSE
(Rec. UIT-T X.228 I ISOKEI 9066-2), ainsi qu’avec le service présentation (Rec. UIT-T X.216 I ISOKEI 8822).
Les procédures ROSE sont définies en termes:
a) d’interactions entre machines protocolaires ROSE homologues par l’emploi des services de l’élément
RTSE ou du service de présentation;
d’interactions entre la machine protocolaire ROSE et l’utilisateur de ce service.
b)
La présente Recommandation I Norme internationale spécifie les conditions de conformité applicables aux systèmes qui
mettent en œuvre ces procédures.
2 Références normatives
Les Recommandations UIT-T et les Normes internationales suivantes contiennent des dispositions qui, par suite de la
référence qui y est faite, constituent des dispositions valables pour la présente Spécification. Au moment de la
publication, les éditions indiquées étaient en vigueur. Toutes Recommandations et Normes sont sujettes à révision et les
parties prenantes aux accords fondés sur la présente Spécification sont invitées à rechercher la possibilité d’appliquer les
éditions les plus récentes des Recommandations et Normes indiquées ci-après. Les membres de la CE1 et de I’ISO
possèdent le registre des Normes internationales en vigueur. Le Bureau de la normalisation des télécommunications tient
à jour une liste des Recommandations UIT-T en vigueur.
21 .
Recommandations I Normes internationales identiques
-
Recommandation UIT-T X.200 (1994) I ISOKEI 7498-l : 1994, Technologie de I?nformation -
Interconnexion de systèmes ouverts
- Modèle de référence de base: Le modèle de base.
-
Recommandation UIT-T X.210 (1993) I ISOKEI 1073 1: 1994, Technologie de Z’information -
Interconnexion de systèmes ouverts
- Conventions relatives à la déjkition des services OSI.
-
Recommandation UIT-T X.215 (1994) I ISOKEI 8326:- ‘), Technologie de l’information -
Interconnexion de systèmes ouverts - Définition du service de couche session.
-
Recommandation UIT-T X.21 6 (1994) I ISOKEI 8822: 1994, Technologie de I?nformation -
Interconnexion de systèmes ouverts - Définition du service de présentation.
-
Recommandation UIT-T X.217 (1995) I ISOKEI 8649:
-2), Technologie de l’information -
Interconnexion de systèmes ouverts - Définition du service de l’élément de service de contrôle
d’association.
1) À publier (Révision de I’ISO 8326:1987)
2) À publier (Révision de 1’ISO 8649: 1988)
Rec. UIT-T X.882 (1994 F) 1
ISOKEI 13712-3 : 1995 (F)
-
Recommandation UIT-T X.227 (1995) I ISOKEI 8650-l: -“), Technologie de l’information -
Interconnexion de systèmes ouverts - Spécification du protocole de l’élément de service de commande
d’association en mode connexion.
-
Recommandation UIT-T X.680 (1994) I ISOKEI 8824-1:1995, Technologie de l’information - Notation
de syntaxe abstraite numéro un (ASN. I): Spécification de la notation de base.
-
Recommandation UIT-T X.681 (1994) I ISOKEI 8824-2:1995, Technologie de l’information - Notation
de syntaxe abstraite numéro un (ASN. I): Spécification des objets informationnels.
-
Recommandation UIT-T X.682 (1994) I ISOKEI 8824-3:1995, Technologie de l’information - Notation
de syntaxe abstraite numéro un (ASN. I): Spécifîcation des contraintes.
-
Recommandation UIT-T X.683 (1994) I ISOKEI 8824-4:1995, Technologie de l’information - Notation
de syntaxe abstraite numéro un (ASN. 1): Paramétrage des spécifications ASN. I.
.
-
Recommandation UIT-T X.690 (1994) I ISOKEI 8825-1:1995, Technologie de l’information -
Spécification des règles de codage de base (BER), des règles de codage en métalangage canonique et des
règles de codage en métalangage distinctif.
-
Recommandation UIT-T X.880 (1994) I ISOKEI 137 12-1: 1995, Technologie de l’information -
Opérations distantes: Concepts, modèle et notation.
-
Recommandation UIT-T X.88 1 (1994) I ISOKEI 13712-2: 1995, Technologie de l’information -
Opérations distantes: Réalisations OSI - Définition du service de l’élément de service d‘opérations
distantes.
22 . Paires de Recommandations I Normes internationales équivalentes par leur contenu technique
-
Recommandation UIT-T X.218 (1993), Transfertfiable: Modèle et définition du service.
ISOKEI 9066- 1: 1989, Systèmes de traitement de l’information - Communication de texte - Transfert
fiable - Partie I: Modèle et définition du service.
-
Recommandation UIT-T X.228 (1988), Transfert fiable: Spécification du protocole.
ISOKEI 9066-2: 1989, Systèmes de traitement de l’information - Communication de texte - Transfert
fiable - Partie 2: Spécification du protocole.
-
Modèle, notation et définition du
Recommandation X.219 du CCITT (1988), Opérations distantes:
service.
ISOKEI 9072-l : 1989, Systèmes de traitement de l’information - Communication de texte - Opérations à
distance - Partie I: Modèle, notation et définition du service.
-
Recommandation X.229 du CCITT (1988), Opérations distantes: Spécification du protocole.
ISOKEI 9072-2: 1989, Systèmes de traitement de l’information - Communication de texte - Opérations à
distance - Partie 2: Spécifkation du protocole.
23 . Références additionnelles
-
Recommandation X.410 du CCITT (1984), Systèmes de messagerie: Opérations distantes et serveur de
transfert fiable.
3 Définitions
. Définitions du modèle de référence
La presente Recommandation I Norme internationale s’appuie sur les concepts présentés dans la Rec. UIT-T X.200 I
ISOKEI 7498-l et utilise les termes suivants qui y sont définis:
couche application;
a)
processus d’application;
b)
3) À publier (Révision de I’ISO 8650:1988)
2 Rec. UIT-T X.882 (1994 F)
ISOKEI 13712-3 : 1995 (F)
entité d’application;
d
élément de service d’application;
dl
unité de données de protocole d’application;
e)
information de contrôle du protocole d’application;
f)
service de présentation;
g)
connexion de présentation;
h)
service de session;
.
connexion de session; et
J)
syntaxe de transfert.
k)
32 . Définitions des conventions du service
utilise les termes suivants définis dans la Rec. UIT-T x.210 I
La présente Recommandation I Norme internationale
ISO/CEI 1073 1:
a) fournisseur de service;
b) utilisateur de service;
service confirmé;
C)
d) service non confirmé;
service à l’initiative du fournisseur;
e)
f) primitive;
g) (primitive de) demande;
h) (primitive d’)indication;
(primitive de) réponse;
j) (primitive de) confirmation.
33 . Définitions du service de présentation
La présente Recommandation I Norme internationale utilise les termes suivants définis dans la Rec. UIT-T X.216 I
ISOKEI 8822:
syntaxe abstraite;
a>
b) nom de syntaxe abstraite;
contexte de présentation;
C)
d) ensemble des contextes définis.
34 0 Définitions du contrôle d’association
La présente Recommandation l Norme internationale utilise les termes suivants définis dans la Rec. UIT-T X.217 I
ISOKEI 8649:
association d’application; association;
a)
b) contexte d’application;
c) élément de service de contrôle d’association.
35 . Définitions du transfert fiable
La présente Recommandation I Norme internationale utilise le terme suivant défini dans la Rec. X.218 du CCITT I
ISOKEI 9066- 1:
-
élément de service de transfert fiable.
Rec. UIT-T X.882 (1994 F) 3
ISOKEI 13712-3 : 1995 (F)
36 . Définitions du service ROSE
La présente Recommandation I Norme internationale utilise les termes suivants définis dans la Rec. UIT-T X.881 I
ISOKEI 137 12-2:
entité d’application initiant l’association; initiateur d’association;
a>
entité d’application répondant à la demande d’association; répondeur d’association;
b)
entité d’application invocatrice; invocateur;
entité d’application exécutrice; exécutant;
e) demandeur;
accepteur;
f)
g) opérations liées;
h) opération mère;
opération fille;
.
élément de service d’opérations distantes;
J)
k) fournisseur ROSE;
1) utilisateur ROSE;
m) utilisateur RTSE.
37 . Définitions de la spécifïcation du protocole d’opérations distantes
Pour les besoins de la présente Recommandation I Norme internationale, les définitions suivantes s’appliquent:
3.7.1 machine protocolaire d’opérations distantes: Machine protocolaire pour l’élément de service d’opérations
distantes spécifié dans la présente Recommandation I Norme internationale.
3.7.2 machine protocolaire d’opérations distantes demandeuse: Machine protocolaire d’opérations dis tantes dont
l’utilisateur de service est le demandeur d’un service donné d’élément de service d .‘opérations distantes.
aire d’opérations distantes dont
3.7.3 machine protocolaire d’opérations distantes accepteuse: Machine protocol
l’utilisateur de service est l’accepteur d’un service donné d’élément de service d’opérations distantes
4 Abréviations
41 . Unités de données
APDU Unité de données de protocole d’application (application-protocol-data-unit)
PC1 Information de contrôle de protocole (protocol control information)
PDV
Valeur de données de présentation (presentation data value)
42 . Types d’unités de données de protocole d’application
Les noms abrégés suivants ont été attribués aux unités de données de protocole d’application définies dans la présente
Recommandation I Norme internationale:
Invoke (invocation) Unité de données de protocole d’application du service RO-INVOKE
(invocation d’opération distante)
ReturnResult (résultat en retour) Unité de données de protocole d’application du service RO-RESULT
(résultat d’opération distante)
Rec. UIT-T X.882 (1994 F)
ISOKEI 13712-3 : 1995 (F)
ReturnError (erreur en retour) Unité de données de protocole d’application du service RO-ERROR (erreur
d’opération distante)
Reject (rejet) Unité de données de protocole d’application du service RO-REJECT-U/P
(rejet d’opération distante par l’utilisateur/le fournisseur)
Autres abréviations
43 .
Les abréviations suivantes sont utilisées dans la présente Recommandation I Norme internationale:
AE Entité d’application (application entity)
ACSE Elément de service de contrôle d’association (association control service element)
ASE Elément de service d’application (application service element)
ASN. 1 Notation de syntaxe abstraite numéro un (abstract syntax notation one)
RO (ou ROS) Service d’opérations distantes (remote operations)
ROPM Machine protocolaire d’opérations distantes (remote operations protocol machine)
ROSE Elément de service d’opérations distantes (remote operations service element)
RT (ou RTS) Service de transfert fiable (reliable transfer)
RTSE Elément de service de transfert fiable (reliable transfer service element)
5 Conventions
La présente Recommandation I Norme internationale utilise une présentation tabulaire pour les paramètres de ses
pseudo-primitives et pour les champs de ses APDU. Dans l’article 7, des tableaux sont présentés pour chaque pseudo-
primitive et chaque APDU de l’élément ROSE. Une des indications suivantes est donnée pour chaque paramètre ou
champ:
blanc Sans objet
M Présence obligatoire (mandatory)
U Présence sur option de l’utilisateur de l’élément ROSE
C Conditionnel
dem. La source est la primitive de demande correspondante
ind. Le puits est la primitive d’indication correspondante
rép. La source est la primitive de réponse correspondante
conf. Le puits est la primitive de confirmation correspondante
La source ou le puits est la machine protocolaire ROPM
SP
En outre, la notation (=) indique qu’une valeur de paramètre est sémantiquement égale à la valeur située à sa gauche dans
le tableau.
La présente Recommandation I Norme internationale utilise I’ASN. 1, telle qu’elle est spécifiée dans la Rec. UIT-T
X.681 I ISOKEI 8824-2, pour définir la classe d’objets informationnels REALIZATION (réalisation). Elle fournit
également une notation permettant aux concepteurs de réalisations ROS de spécifier des instances particulières de cette
classe.
La structure de chaque APDU de l’élément ROSE est spécifiée en ASN.l dans la Rec. UIT-T X.880 I ISOKEI 13712-1.
6 Vue d’ensemble
61 . Fourniture du service
Le protocole spécifié dans la présente Recommandation I Norme internationale fournit les services ROSE définis dans la
Rec. UIT-T X.881 I ISOKEI 13712-2. Ces services sont énuméres dans le Tableau 1 qui reprend le Tableau 1 de la
Rec. UIT-T X.881 I ISOKEI 13712-2.
Rec. UIT-T X.882 (1994 F) 5
ISOKEI 13712-3 : 1995 (F)
Tableau 1 - Services ROSE
Service
TYPe
RO-INVOKE (invocation d’opération distante) Non confirmé
Non confirmé
RO-RESULT (résultat d’opération distante)
RO-ERROR (erreur d’opération distante) Non confirmé
Non confirmé
RO-REJECT-U (rejet d’opération distante par l’utilisateur)
A l’initiative du fournisseur
RO-REJECT-P (rejet d’opération distante par le fournisseur)
RO-BIND (rattachement de service d’opération distante) Confirmé
RO-UNBIND (détachement de service d’opération distante) Confirmé
62 . Services d’association et de transfert
Le protocole ROSE spécifié ici nécessite un service de transfert pour la passation de l’information sous la forme d’APDU
de l’élément ROSE entre entités d‘application homologues et, si un lot de connexion est mis en œuvre dans le contrat
d’association, un service d’association pour établir des associations entre les entités d’application et les libérer. Ces
services sont assurés au moyen des divers éléments ASE ainsi que du service de présentation OSI.
La présente Spécification décrit un protocole générique (voir l’article 7), ainsi qu’un certain nombre de réalisations
particulières du service d’association (voir l’article 8) et du service de transfert (voir l’article 9). Le protocole générique
est indépendant des réalisations particulières choisies.
NOTE - Il est possible de définir ultérieurement d’autres applications d’association et de transfert, que ce soit sous forme
d’extensions à la présente norme ou d’applications propriétaires non normalisées.
Cette Norme décrit deux réalisations d’association particulières, fondées pour l’une sur l’élément ACSE et pour l’autre sur
l’élément RTSE, ainsi que deux réalisations particulières pour le transfert des APDU utilisant l’une le service de données
de présentation P-DATA et l’autre le service de transfert fiable RT-DATA.
63 . Modèle de protocole
Les services de l’élément ROSE, tels qu’ils sont définis dans la Rec. UIT-T X.881 I ISOKEI 13712-2, sont fournis par la
machine protocolaire d’opérations distantes (ROPM). Cette machine utilise les services fournis par le fournisseur du
service présentation OSI, ainsi qu’une collection d’éléments ASE devant inclure un élément a-ASE, pouvant inclure un
élément T-ASE et des éléments ASE pour en assurer le support. Cette collection inclut toujours l’élément ACSE.
L’utilisation de collections différentes aboutit a différentes réalisations OS1 du service d’opérations distantes (ROS).
Ce modèle est décrit dans la Figure 1.
En général, l’élément ROSE ne présume pas être l’utilisateur exclusif des services de l’élément a-ASE, de l’élément
T-ASE, des éléments ASE supports, ou de la couche de présentation. En outre, le concepteur du contexte d’application
peut spécifier au besoin l’utilisation de paramètres de service dont les valeurs ne dépendent pas des spécifications du
protocole ROSE. Toute exception à cette règle est indiquée dans la spécification de l’application correspondante.
7 Eléments de procédure du protocole ROSE de base
Le protocole ROSE de base comprend les éléments de procédure suivants:
a) établissement d’association;
b) libération d’association;
Rec. UIT-T X.882 (1994 F)
ISOKEI 13712-3 : 1995 (F)
rupture intempestive d’association;
Cl
d) invocation;
renvoi de résultat;
e)
renvoi d’erreur;
f)
g) rejet par l’utilisateur;
h) rejet par le fournisseur.
ROPM de base
FOURNCSSEUR DU SERVICE DE PRÉSENTATION
TISO4470-94/dOl
a-ASE Eknent de service d’application assurant IWblissement et la libkation de l’association
vASE El6ment de service d’application assurant le transfert de l’information
ROPM Machine protocolaire d’opérations distantes
0-ASE El&nents de service d’application propres aux opdrations
Figure 1 - Modèle de protocole
Ces éléments de procédure sont spécifiés dans ce qui suit. Un certain nombre de pseudo-primitives ont été introduites
pour décrire l’utilisation des services d’association et de transfert. Les différentes réalisations de ces services sont décrites
dans les articles 8 et 9 avec les primitives effectivement utilisées qui leur correspondent.
Les pseudo-primitives correspondant aux services d’association sont indiquées dans le Tableau 2.
Le paramètre result (résultat) de la pseudo-primitive d’établissement ESTABLZW prend les valeurs symboliques
«accepted» (accepté) et «rejected» (rejeté).
Le paramètre release cari fail (la libération peut échouer) prend les valeurs symboliques «truc» (vrai) et «false» (faux).
Dans des primitives successives de ce service, la valeur du paramètre peut passer de «truc» à «false» mais pas l’inverse.
Ce paramètre est présent dans la réponse ou la confirmation si et seulement si le paramètre result a la valeur «accepted».
Rec. UIT-T X.882 (1994 F) 7
ISOKEI 13712-3 : 1995 (F)
Tableau 2 - Pseudo-primitives correspondant aux réalisations d’association
Service assuré Pseudo-primi tive dem.
ind. rép. conf.
Etablissement d’association ESTABLISH
application context M
M(=)
(contexte d’application)
release cari fail M C
cc=>
(la libération peut échouer)
user data U U
CC=) c(=>
(données d’utilisateur)
result M
M(=)
(résultat)
Libération de l’association RELEASE
user data U U
C(=l CC=)
(données d’utilisateur)
result M
M(=l
(résultat)
Rupture de l’association du fait de ABORT
l’utilisateur
source M
(source)
user data U
cc=>
(données d’utilisateur)
Rupture de l’association du fait du ABORT-P
fournisseur
provider reason C
(motif du fournisseur)
Le paramètre result de la pseudo-primitive de libération RHEASE prend les trois valeurs symboliques «accepted»
(accepté), «rejected-released» (rejeté et libéré) et «rejected-not-released» (rejeté et non libéré).
Le paramètre source de la pseudo-primitive de rupture du fait de l’utilisateur ABORT prend les valeurs symboliques
«association-control-service-user» (utilisateur du service de commande d’association) ou «association-control-service-
provider» (fournisseur du service de commande d’association).
La valeur du paramètre user information (information d’utilisateur) dépend du contexte d’application mis en œuvre.
Le paramètre provider-reason (motif du fournisseur) de la pseudo-primitive de rupture du fait du fournisseur ABORT-P
prend les valeurs symboliques définies dans la Rec. UIT-T X.216 l ISOKEI 8822.
Les pseudo-primitives correspondant aux services de transfert sont indiquées dans le Tableau 3.
Tableau 3 - Pseudo-primitives correspondant aux réalisations de transfert
Service assuré Pseudo-primitive dem. ind.
I
Transfert d’information TRANSFER
user-data
(données d’utilisateur)
Rec. UIT-T X.882 (1994 F)
ISOKEI 13712-3 : 1995 (F)
Le présent article décrit l’utilisation des éléments des diverses APDU. Dans la Rec. UIT-T X.880 I ISOKEI 13712-1, les
types de données correspondant à ces APDU sont spécifiés en ASN. 1.
71 . Etablissement d’association
7.1.1 Objet
Tentative d’Établissement d’une association par l’invocation d’une opération de rattachement.
7.1.2 APDU utilisées
La procédure d’établissement d’association utilise les APDU BindInvoke (invocation de rattachement), BindResult
(résultat de rattachement) et BindError (erreur de rattachement). Ces APDU sont définies si et seulement si les champs
respectifs &ArgumentType (type d’argument), &ResultType (type de résultat) et &ParameterType (type de
paramètre) sont définis pour l’opération de rattachement bind et l’erreur qui lui est associée dans le lot de connexion
utilisé pour la commande dynamique d’association (voir la Rec. UIT-T X.880 I ISOKEI 13712-l pour la définition des
classes d’objets informationnels correspondantes).
7.1.2.1 APDU BindInvoke
L’APDU BindInvoke (invocation de rattachement) sert à demander l’établissement d’une association. Le Tableau 4 en
énumère les champs.
Tableau 4 - Champs de I’APDU BindInvoke
Présence Source Puits
Nom du champ
Argument U dem. ind.
Le champ Argument est dérivé du champ &ArgumentType (type d’argument) de l’opération bind (rattachement).
7.1.2.2 APDU BindResult
L’APDU BindResult (résultat de rattachement) sert à indiquer l’établissement avec succès d’une association. Le
Tableau 5 en énumère les champs.
Le champ Result (résultat) est dérivé du champ &ResultType (type de résultat) de l’opération bind (rattachement).
Tableau 5 - Champs de I’APDU BindResult
Nom du champ Présence Source Puits
Result (résultat) U rép. conf.
7.1.2.3 APDU BindError
L’APDU BindError (erreur de rattachement) sert à indiquer que la tentative d’établissement d’une association a échoué.
Le Tableau 6 en énumère les champs.
Le champ Error-Parameter est dérivé du champ &ParameterType (type de paramètre) de l’erreur associée a l’opération
de rattachement bind.
Tableau 6 - Champs de I’APDU BindError
Présence Source Puits
Nom du champ
rép. conf.
Error-Parameter (paramètre d’erreur) U
Rec. UIT-T X.882 (1994 F)
ISOKEI 13712-3 : 1995 (F)
7.1.3 Procédure d’établissement d’association
Cette procédure est commandée par les événements suivants:
une primitive de demande RO-BIND (rattachement d’opération distante);
a>
b) une APDU BindInvoke (invocation de rattachement) sous forme de données d’utilisateur dans une
primitive d’indication ESTABLZSH (établissement);
une primitive de réponse RO-BIND avec pour issue «result» (résultat = succès);
C)
d) une APDU BindResult (résultat de rattachement) sous forme de données d’utilisateur dans une primitive
de confirmation ESTABLZSH avec comme résultat «accepted» (accepté);
une primitive de réponse RO-BIND avec pour issue «errer» (erreur);
e>
une APDU BindError (erreur de rattachement) sous forme de données d’utilisateur dans une primitive de
f-l
confirmation ESTABLZSH avec comme résultat «rejected» (rejet).
L’envoi de 1’APDU BindInvoke (invocation de rattachement), BindResult (résultat de rattachement) ou BindError (erreur
de rattachement) est optionnel lorsque les champs respectifs SzargumentTypeOptional (type d’argument optionnel),
&resultTypeOptional (type de résultat optionnel) ou ¶meterTypeOptional (type de paramètre optionnel) de
l’opération et de l’erreur de rattachement bind portent la valeur TRUE (vrai).
7.1.3.1 Primitive de demande RO-BIND
A partir du paramètre Argument de la primitive de demande RO-BIND (rattachement d’opération distante), la machine
protocolaire ROPM demandeuse forme une APDU d’invocation de rattachement BindInvoke qu’elle véhicule dans le
paramètre user-data (données d’utilisateur) d’une primitive de demande d’établissement ESTABLZSH. La valeur du
paramètre release cari fail (la libération peut échouer) est déduite du champ &unbindCanFail (le détachement peut
échouer) du lot de connexion identifié par le paramètre de contexte d’application.
7.1.3.2 APDU BindInvoke
La machine protocolaire ROPM accepteuse émet une primitive d’indication RO-BIND (rattachement d’opération
distante), dont le paramètre Argument est dérivé de I’APDU d’invocation de rattachement BindInvoke.
7.1.3.3 Primitive de réponse RO-BIND positive «resulh
A partir du paramètre de résultat de rattachement Bind-Result de la primitive de réponse RO-BIND (rattachement
APDU de résultat de rattachement
d’opération distante), la machine protocolaire ROPM accepteuse forme une
BindResult qu’elle véhicule dans le paramètre user-data (données d’utilisateur) d’une primitive de réponse ESTABLZSH
dont le paramètre result prend la valeur «accepted» (accepté). Le paramètre unbind cari fail (le détachement peut
échouer) de la primitive de réponse RO-BIND détermine la valeur du paramètre release cari fail (la libération peut
échouer) de la primitive de réponse ESTABLZSH.
7.1.3.4 APDU BindResult
La machine protocolaire ROPM demandeuse émet une primitive de confirmation RO-BIND, dont le paramètre de
résultat de rattachement Bind-Result est dérivé de 1’APDU de résultat de rattachement BindResult.
7.1.3.5 Primitive de réponse RO-BIND négative «errer»
A partir du paramètre Bind-Error (erreur de rattachement) de la primitive de réponse RO-BIND, la machine protocolaire
ROPM accepteuse forme une APDU d’erreur de rattachement BindError qu’elle véhicule dans le paramètre user-data
(données d’utilisateur) d’une primitive de réponse ESTABLZSH.
7.1.3.6 APDU BindError
La machine protocolaire ROPM demandeuse émet une primitive de confirmation RO-BIND, dont le paramètre
Bind-Error (erreur de rattachement) est dérivé de I’APDU d’erreur de rattachement BindError.
Libération d’association
72 .
7.2.1 Objet
Tentative de libération d’une association par l’invocation d’une opération de détachement unbind.
10 Rec. UIT-T X.882 (1994 F)
ISOKEI 13712-3 : 1995 (F)
7.2.2 APDU utilisées
La procédure de liberation d’association utilise les APDU UnbindInvoke (invocation de détachement), UnbindResult
(résultat de detachement) et UnbindError (erreur de detachement). Ces APDU sont définies si et seulement si les champs
respectifs &ArgumentType (type d’argument), &ResultType (type de résultat) et &ParameterType (type de
paramètre) sont définis pour l’opération de détachement unbind et l’erreur qui lui est associée dans le connection
package (lot de connexion) utilise pour la commande dynamique d’association (voir la Rec. UIT-T X.880 I
ISOKEI 137 12- 1 pour la définition des classes d’objets informationnels correspondantes).
7.2.2.1 APDU UnbindInvoke
L’APDU UnbindInvoke (invocation de détachement) sert à demander la libération d’une association. Le Tableau 7 en
enumère les champs.
Le champ Argument est dérive du champ &ArgumentType (type d’argument) de l’opération de détachement unbind.
Tableau 7 - Champs de I’APDU UnbindInvoke
Nom du champ Présence Source Puits
U dem. ind.
Argument
7.2.2.2 APDU UnbindResult
L’APDU UnbindResult (résultat de détachement) sert a indiquer la liberation avec succès d’une association. Le Tableau 8
en énumère les champs.
Le champ Result est dérivé du champ &ResultType (type de résultat) de l’opération de détachement unbind.
Tableau 8 - Champs de I’APDU UnbindResult
Présence Source Puits
Nom du champ
U rép. conf.
Result (résultat)
7.2.2.3 APDU UnbindError
L’APDU UnbindError (erreur de détachement) sert à indiquer que la demande de libération d’une association est refusée.
Le Tableau 9 en énumère les champs.
Le champ Parameter est dérivé du champ &ParameterType (type de paramètre) de l’erreur associée à l’opération de
détachement unbind considérée.
Tableau 9 - Champs de I’APDU UnbindError
Présence Source Puits
Nom du champ
rép. conf.
Parameter (paramètre) U
7.2.3
Procédure de libération d’association
Cette procédure est commandée par les événements suivants:
une primitive de demande RO-UNBIND (détachement d’opération distante);
a)
b) une APDU UnbindInvoke (inv
...
NORME
ISO/CEI
INTERNATIONALE
13712-3
Première édition
1995-04-15
Technologies de l’information -
Opérations distantes: Réalisations OSI -
Spécification du protocole de l’élément de
service d’opérations distantes (ROSE)
Information technology - Remote Opera tions: OSI realizations -
Remote Operations Service Element (ROSE) protocol specification
Numéro de référence
ISO/CEI 13712-3:1995(F)
ISOKEI 13712-3: 1995(F)
Sommaire
Page
Domaine d’application .
...................................................................................................................................
Références normatives
2.1 Recommandations I Normes internationales identiques .
....... 2
2.2 Paires de Recommandations I Normes internationales équivalentes par leur contenu technique
Références additionnelles .
2.3
Définitions .
....................................................................................................
3.1 Définitions du modèle de référence
3.2 Définitions des conventions du service .
................................................................................................ 3
3.3 Définitions du service de présentation
Définitions du contrôle d’association .
3.4
3.5 Définitions du transfert fiable .
..............................................................................................................
3.6 Définitions du service ROSE
....................................................
3.7 Définitions de la spécification du protocole d’opérations distantes
Abréviations .
4.1 Unités de données .
4.2 Types d’unités de données de protocole d’application .
4.3 Autres abréviations .
....................................................................................................................................................
Conventions
Vue d’ensemble .
..........................................................................................................................
6.1 Fourniture du service
6.2 Services d’association et de transfert .
6.3 Modèle de protocole .
......................................................................................
Eléments de procédure du protocole ROSE de base
7.1 Etablissement d’association .
......................................................................................................................
7.2 Libération d’association
.....................................................................................................
7.3 Rupture intempestive d’association
7.4 Invocation .
7.5 Retour du résultat .
Retour d’erreur .
7.6
7.7 Rejet par l’utilisateur .
7.8 Rejet par le fournisseur .
............................................................................................................................... 19
Réalisation d’associations
Introduction .
8.1
............................................................... 20
82 Réalisation d’une association au moyen de l’élément ACSE
...............................................................
8:3 Réalisation d’une association au moyen de l’élément RTSE
ISOKEI 1995
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publi-
cation ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun
procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans
l’accord écrit de l’éditeur.
ISO/CEI Copyright Office l Case Postale 56 l CH- 12 11 Genève 20 l Suisse
Version française tirée en 1996
Imprimé en Suisse
ii
ISOKEI 13712-3: 1995(F)
@ ISOKEI
9 Réalisation de transferts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*. 23
9:2 Réalisation d’un transfert au moyen du service P-DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3 RT-TRANSFER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Syntaxes abstraites
10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2 Opération de rattachement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3 Opération de détachement
..,................................................................................................................ 27
10.4 Autres opérations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.5 Définition des syntaxes abstraites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
,.,.,.*.
11 Conformité 28
11.1 Spécifications de déclaration . . . . . . . . . . . . . . . . . . . . .*. 28
11.2 Spécifications statiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3 Spécifications dynamiques 28
Annexe A - Tables d’états des machines protocolaires ROPM . 29
.....................................................................................................................
A. 1 Considérations générales 29
A.2 Conventions . 30
A.3 Actions devant être exécutées par la machine protocolaire ROPM . 30
A.4 Tables . 31
Annexe B - Modules ASN.l . 48
Annexe C - Directives pour l’utilisation de la notation . 50
Annexe D - Affectation des valeurs d’identificateur d’objets . 53
. . .
ISO/CEI 13712-3: 1995(F) @ ISOKEI
Avant-propos
L’ISO (Organisation internationale de normalisation) et la CE1 (Commission
électrotechnique internationale) forment ensemble un système consacré à la
normalisation internationale considérée comme un tout. Les organismes
nationaux membres de I’ISO ou de la CE1 participent au développement de
Normes internationales par l’intermédiaire des comités techniques créés par
l’organisation concernée afin de s’occuper des différents domaines particuliers de
l’activité technique. Les comités techniques de 1’ISO et de la CE1 collaborent
dans des domaines d’intérêt commun. D’autres organisations internationales,
gouvernementales ou non gouvernementales, en liaison avec 1’ISO et la CE1
participent également aux travaux.
Dans le domaine des technologies de l’information, PIS0 et la CE1 ont créé un
comité technique mixte, I’ISOKEI JTC 1. Les projets de Normes internationales
adoptés par le comité technique mixte sont soumis aux organismes nationaux
pour approbation, avant leur acceptation comme Normes internationales. Les
Normes internationales sont approuvées conformément aux procédures qui
requièrent l’approbation de 75 % au moins des organismes nationaux votants.
La Norme internationale ISOKEI 137 12-3 a été élaborée par le comité technique
mixte ISOKEI JTC 1, Technologies de Z’information, sous-comité SC 21,
Interconnexion des systèmes ouverts, gestion des données et traitement distribué
ouvert, en collaboration avec l’IUT-T. Le texte identique est publié en tant que
Recommandation IUT-T X.882.
La présente partie de 1’ISOKEI 13712 est une révision partielle de
1’ISOKEI 9072-2: 1989.
L’ISOKEI 137 12 comprend les parties suivantes, présentées sous le titre général
Technologies de 1 ‘information - Opérations distantes:
Partie 1: Concepts, modèle et notation
- Partie 2: Réalisations OSI - Défînition du service de l’élément de service
d’opérations distantes (ROSE)
- Partie 3: Réalisations OSI - Spécijkation du protocole de l’élément de
service d’opérations distantes (ROSE)
Les annexes A et B font partie intégrante de la présente partie de
I’ISOKEI 13712. Les annexes C et D sont données uniquement à titre
d’information.
iv
0 ISOKEI ISOKEI 13712-3: 1995(F)
Introduction
Le concept d’opérations distantes (ROS) est un paradigme de la communication interactive entre objets. En tant que tel,
il peut être utilisé pour la conception et la spécification des applications réparties. L’interaction de base mise en jeu est
l’invocation d’une opération par un objet (l’invocateur), son exécution par un autre (l’exécutant), éventuellement suivie
par un rapport sur le résultat de l’opération retourne a l’invocateur.
Les concepts d’opérations distantes (ROS), tels qu’ils sont spécifiés dans la Rec. UIT-T X.880 I ISOKEI 13712-1, sont
abstraits et peuvent être réalisés de multiples manieres. Ainsi, les objets dont les interactions mettent en jeu les concepts
d’opérations distantes peuvent être separes par une interface logicielle ou par un réseau OSI.
La Rec. UIT-T X.881 I ISO/CEI 13712-2 fournit le cadre pour la réalisation d’un contrat d’association formant un
contexte d’application OSI. Un tel contexte d’application est spécifié fondamentalement en termes d’une collection
d’éléments de service application (ASE). Dans une optique ROS, ces éléments ASE relèvent de trois grandes catégories:
les éléments ASE propres aux opératio ns, qui contiennent la connaissance relative aux définitions des
a)
opérations du contrat d’association;
b) les éléments ASE d’opérations distantes (ROSE), qui pilotent le protocole général nécessaire à
l’invocation d’opérations quelconques et à l’annonce de leurs résultats;
c) les éléments ASE de transfert d’information qui interviennent dans l’établissement et la libération des
associations, si besoin est, et dans la communication des informations de protocole ROSE.
La présente Recommandation I Norme internationale décrit le comportement de l’elément de service d’opérations
distantes (ROSE) proprement dit, et la manière dont différentes collections d’éléments de service d’application (ASE) de
transfert d’information [et plus précisément l’élément de service de transfert fiable (RTSE) et l’élément de service de
contrôle d’association (ACSE)] sont utilisées pour transférer son information de contrôle de protocole (PCI) dans une
réalisation OSI.
La présente Recommandation I Norme internationale est une révision de la Rec. X.229 du CCITT I ISOKEI 9072-2.
L’utilisation actuelle de l’élément ROSE, conjointement avec les éléments ACSE et RTSE et la couche présentation
définie dans la Rec. X.229 du CCITT I ISOKEI 9072-2, reste valide après cette révision. En outre, cette révision ne
modifie en rien l’information PC1 de l’élément ROSE.
L’Annexe A fait partie intégrante de la présente Recommandation I Norme internationale.
L’Annexe B fait partie intégrante de la présente Recommandation I Norme internationale.
L’Annexe C ne fait pas partie intégrante de la présente Recommandation I Norme internationale.
L’Annexe D ne fait pas partie intégrante de la présente Recommandation I Norme internationale.
Page blanche
ISOKEI 13712-3 : 1995 (F)
NORME INTERNATIONALE
RECOMMANDATION UIT-T
TECHNOLOGIES DE L’INFORMATION -
OPÉRATIONS DISTANTES: RÉALISATIONS OS1 -
SPÉCIFICATION DU PROTOCOLE DE L’ÉLÉMENT DE
SERVICE D’OPÉRATIONS DISTANTES (ROSE)
1 Domaine d’application
La présente Recommandation I Norme internationale spécifie le protocole (syntaxe abstraite) et les procédures
applicables à l’élément de service d’opérations distantes (ROSE). Les termes, définitions et mécanismes définis dans la
Rec. UIT-T X.880 I ISOKEI 13712-1 sont applicables ci-après et sont spécifiques d’une réalisation OS1 conforme à la
présente Recommandation I Norme internationale. Les services ROSE, définis dans la Rec. UIT-T X.881 I ISOKEI
13712-2, sont fournis en liaison avec les services de l’élément de service de contrôle d’association (ACSE) (Rec. UIT-T
X.217 I ISO/CEI 8649) et le protocole ACSE (Rec. UIT-T X.227 I ISOKEI 8650-l), optionnellement avec les services
de l’élément de service de transfert fiable (RTSE) (Rec. UIT-T X.21 8 I ISOKEI 9066- 1) et le protocole RTSE
(Rec. UIT-T X.228 I ISOKEI 9066-2), ainsi qu’avec le service présentation (Rec. UIT-T X.216 I ISOKEI 8822).
Les procédures ROSE sont définies en termes:
a) d’interactions entre machines protocolaires ROSE homologues par l’emploi des services de l’élément
RTSE ou du service de présentation;
d’interactions entre la machine protocolaire ROSE et l’utilisateur de ce service.
b)
La présente Recommandation I Norme internationale spécifie les conditions de conformité applicables aux systèmes qui
mettent en œuvre ces procédures.
2 Références normatives
Les Recommandations UIT-T et les Normes internationales suivantes contiennent des dispositions qui, par suite de la
référence qui y est faite, constituent des dispositions valables pour la présente Spécification. Au moment de la
publication, les éditions indiquées étaient en vigueur. Toutes Recommandations et Normes sont sujettes à révision et les
parties prenantes aux accords fondés sur la présente Spécification sont invitées à rechercher la possibilité d’appliquer les
éditions les plus récentes des Recommandations et Normes indiquées ci-après. Les membres de la CE1 et de I’ISO
possèdent le registre des Normes internationales en vigueur. Le Bureau de la normalisation des télécommunications tient
à jour une liste des Recommandations UIT-T en vigueur.
21 .
Recommandations I Normes internationales identiques
-
Recommandation UIT-T X.200 (1994) I ISOKEI 7498-l : 1994, Technologie de I?nformation -
Interconnexion de systèmes ouverts
- Modèle de référence de base: Le modèle de base.
-
Recommandation UIT-T X.210 (1993) I ISOKEI 1073 1: 1994, Technologie de Z’information -
Interconnexion de systèmes ouverts
- Conventions relatives à la déjkition des services OSI.
-
Recommandation UIT-T X.215 (1994) I ISOKEI 8326:- ‘), Technologie de l’information -
Interconnexion de systèmes ouverts - Définition du service de couche session.
-
Recommandation UIT-T X.21 6 (1994) I ISOKEI 8822: 1994, Technologie de I?nformation -
Interconnexion de systèmes ouverts - Définition du service de présentation.
-
Recommandation UIT-T X.217 (1995) I ISOKEI 8649:
-2), Technologie de l’information -
Interconnexion de systèmes ouverts - Définition du service de l’élément de service de contrôle
d’association.
1) À publier (Révision de I’ISO 8326:1987)
2) À publier (Révision de 1’ISO 8649: 1988)
Rec. UIT-T X.882 (1994 F) 1
ISOKEI 13712-3 : 1995 (F)
-
Recommandation UIT-T X.227 (1995) I ISOKEI 8650-l: -“), Technologie de l’information -
Interconnexion de systèmes ouverts - Spécification du protocole de l’élément de service de commande
d’association en mode connexion.
-
Recommandation UIT-T X.680 (1994) I ISOKEI 8824-1:1995, Technologie de l’information - Notation
de syntaxe abstraite numéro un (ASN. I): Spécification de la notation de base.
-
Recommandation UIT-T X.681 (1994) I ISOKEI 8824-2:1995, Technologie de l’information - Notation
de syntaxe abstraite numéro un (ASN. I): Spécification des objets informationnels.
-
Recommandation UIT-T X.682 (1994) I ISOKEI 8824-3:1995, Technologie de l’information - Notation
de syntaxe abstraite numéro un (ASN. I): Spécifîcation des contraintes.
-
Recommandation UIT-T X.683 (1994) I ISOKEI 8824-4:1995, Technologie de l’information - Notation
de syntaxe abstraite numéro un (ASN. 1): Paramétrage des spécifications ASN. I.
.
-
Recommandation UIT-T X.690 (1994) I ISOKEI 8825-1:1995, Technologie de l’information -
Spécification des règles de codage de base (BER), des règles de codage en métalangage canonique et des
règles de codage en métalangage distinctif.
-
Recommandation UIT-T X.880 (1994) I ISOKEI 137 12-1: 1995, Technologie de l’information -
Opérations distantes: Concepts, modèle et notation.
-
Recommandation UIT-T X.88 1 (1994) I ISOKEI 13712-2: 1995, Technologie de l’information -
Opérations distantes: Réalisations OSI - Définition du service de l’élément de service d‘opérations
distantes.
22 . Paires de Recommandations I Normes internationales équivalentes par leur contenu technique
-
Recommandation UIT-T X.218 (1993), Transfertfiable: Modèle et définition du service.
ISOKEI 9066- 1: 1989, Systèmes de traitement de l’information - Communication de texte - Transfert
fiable - Partie I: Modèle et définition du service.
-
Recommandation UIT-T X.228 (1988), Transfert fiable: Spécification du protocole.
ISOKEI 9066-2: 1989, Systèmes de traitement de l’information - Communication de texte - Transfert
fiable - Partie 2: Spécification du protocole.
-
Modèle, notation et définition du
Recommandation X.219 du CCITT (1988), Opérations distantes:
service.
ISOKEI 9072-l : 1989, Systèmes de traitement de l’information - Communication de texte - Opérations à
distance - Partie I: Modèle, notation et définition du service.
-
Recommandation X.229 du CCITT (1988), Opérations distantes: Spécification du protocole.
ISOKEI 9072-2: 1989, Systèmes de traitement de l’information - Communication de texte - Opérations à
distance - Partie 2: Spécifkation du protocole.
23 . Références additionnelles
-
Recommandation X.410 du CCITT (1984), Systèmes de messagerie: Opérations distantes et serveur de
transfert fiable.
3 Définitions
. Définitions du modèle de référence
La presente Recommandation I Norme internationale s’appuie sur les concepts présentés dans la Rec. UIT-T X.200 I
ISOKEI 7498-l et utilise les termes suivants qui y sont définis:
couche application;
a)
processus d’application;
b)
3) À publier (Révision de I’ISO 8650:1988)
2 Rec. UIT-T X.882 (1994 F)
ISOKEI 13712-3 : 1995 (F)
entité d’application;
d
élément de service d’application;
dl
unité de données de protocole d’application;
e)
information de contrôle du protocole d’application;
f)
service de présentation;
g)
connexion de présentation;
h)
service de session;
.
connexion de session; et
J)
syntaxe de transfert.
k)
32 . Définitions des conventions du service
utilise les termes suivants définis dans la Rec. UIT-T x.210 I
La présente Recommandation I Norme internationale
ISO/CEI 1073 1:
a) fournisseur de service;
b) utilisateur de service;
service confirmé;
C)
d) service non confirmé;
service à l’initiative du fournisseur;
e)
f) primitive;
g) (primitive de) demande;
h) (primitive d’)indication;
(primitive de) réponse;
j) (primitive de) confirmation.
33 . Définitions du service de présentation
La présente Recommandation I Norme internationale utilise les termes suivants définis dans la Rec. UIT-T X.216 I
ISOKEI 8822:
syntaxe abstraite;
a>
b) nom de syntaxe abstraite;
contexte de présentation;
C)
d) ensemble des contextes définis.
34 0 Définitions du contrôle d’association
La présente Recommandation l Norme internationale utilise les termes suivants définis dans la Rec. UIT-T X.217 I
ISOKEI 8649:
association d’application; association;
a)
b) contexte d’application;
c) élément de service de contrôle d’association.
35 . Définitions du transfert fiable
La présente Recommandation I Norme internationale utilise le terme suivant défini dans la Rec. X.218 du CCITT I
ISOKEI 9066- 1:
-
élément de service de transfert fiable.
Rec. UIT-T X.882 (1994 F) 3
ISOKEI 13712-3 : 1995 (F)
36 . Définitions du service ROSE
La présente Recommandation I Norme internationale utilise les termes suivants définis dans la Rec. UIT-T X.881 I
ISOKEI 137 12-2:
entité d’application initiant l’association; initiateur d’association;
a>
entité d’application répondant à la demande d’association; répondeur d’association;
b)
entité d’application invocatrice; invocateur;
entité d’application exécutrice; exécutant;
e) demandeur;
accepteur;
f)
g) opérations liées;
h) opération mère;
opération fille;
.
élément de service d’opérations distantes;
J)
k) fournisseur ROSE;
1) utilisateur ROSE;
m) utilisateur RTSE.
37 . Définitions de la spécifïcation du protocole d’opérations distantes
Pour les besoins de la présente Recommandation I Norme internationale, les définitions suivantes s’appliquent:
3.7.1 machine protocolaire d’opérations distantes: Machine protocolaire pour l’élément de service d’opérations
distantes spécifié dans la présente Recommandation I Norme internationale.
3.7.2 machine protocolaire d’opérations distantes demandeuse: Machine protocolaire d’opérations dis tantes dont
l’utilisateur de service est le demandeur d’un service donné d’élément de service d .‘opérations distantes.
aire d’opérations distantes dont
3.7.3 machine protocolaire d’opérations distantes accepteuse: Machine protocol
l’utilisateur de service est l’accepteur d’un service donné d’élément de service d’opérations distantes
4 Abréviations
41 . Unités de données
APDU Unité de données de protocole d’application (application-protocol-data-unit)
PC1 Information de contrôle de protocole (protocol control information)
PDV
Valeur de données de présentation (presentation data value)
42 . Types d’unités de données de protocole d’application
Les noms abrégés suivants ont été attribués aux unités de données de protocole d’application définies dans la présente
Recommandation I Norme internationale:
Invoke (invocation) Unité de données de protocole d’application du service RO-INVOKE
(invocation d’opération distante)
ReturnResult (résultat en retour) Unité de données de protocole d’application du service RO-RESULT
(résultat d’opération distante)
Rec. UIT-T X.882 (1994 F)
ISOKEI 13712-3 : 1995 (F)
ReturnError (erreur en retour) Unité de données de protocole d’application du service RO-ERROR (erreur
d’opération distante)
Reject (rejet) Unité de données de protocole d’application du service RO-REJECT-U/P
(rejet d’opération distante par l’utilisateur/le fournisseur)
Autres abréviations
43 .
Les abréviations suivantes sont utilisées dans la présente Recommandation I Norme internationale:
AE Entité d’application (application entity)
ACSE Elément de service de contrôle d’association (association control service element)
ASE Elément de service d’application (application service element)
ASN. 1 Notation de syntaxe abstraite numéro un (abstract syntax notation one)
RO (ou ROS) Service d’opérations distantes (remote operations)
ROPM Machine protocolaire d’opérations distantes (remote operations protocol machine)
ROSE Elément de service d’opérations distantes (remote operations service element)
RT (ou RTS) Service de transfert fiable (reliable transfer)
RTSE Elément de service de transfert fiable (reliable transfer service element)
5 Conventions
La présente Recommandation I Norme internationale utilise une présentation tabulaire pour les paramètres de ses
pseudo-primitives et pour les champs de ses APDU. Dans l’article 7, des tableaux sont présentés pour chaque pseudo-
primitive et chaque APDU de l’élément ROSE. Une des indications suivantes est donnée pour chaque paramètre ou
champ:
blanc Sans objet
M Présence obligatoire (mandatory)
U Présence sur option de l’utilisateur de l’élément ROSE
C Conditionnel
dem. La source est la primitive de demande correspondante
ind. Le puits est la primitive d’indication correspondante
rép. La source est la primitive de réponse correspondante
conf. Le puits est la primitive de confirmation correspondante
La source ou le puits est la machine protocolaire ROPM
SP
En outre, la notation (=) indique qu’une valeur de paramètre est sémantiquement égale à la valeur située à sa gauche dans
le tableau.
La présente Recommandation I Norme internationale utilise I’ASN. 1, telle qu’elle est spécifiée dans la Rec. UIT-T
X.681 I ISOKEI 8824-2, pour définir la classe d’objets informationnels REALIZATION (réalisation). Elle fournit
également une notation permettant aux concepteurs de réalisations ROS de spécifier des instances particulières de cette
classe.
La structure de chaque APDU de l’élément ROSE est spécifiée en ASN.l dans la Rec. UIT-T X.880 I ISOKEI 13712-1.
6 Vue d’ensemble
61 . Fourniture du service
Le protocole spécifié dans la présente Recommandation I Norme internationale fournit les services ROSE définis dans la
Rec. UIT-T X.881 I ISOKEI 13712-2. Ces services sont énuméres dans le Tableau 1 qui reprend le Tableau 1 de la
Rec. UIT-T X.881 I ISOKEI 13712-2.
Rec. UIT-T X.882 (1994 F) 5
ISOKEI 13712-3 : 1995 (F)
Tableau 1 - Services ROSE
Service
TYPe
RO-INVOKE (invocation d’opération distante) Non confirmé
Non confirmé
RO-RESULT (résultat d’opération distante)
RO-ERROR (erreur d’opération distante) Non confirmé
Non confirmé
RO-REJECT-U (rejet d’opération distante par l’utilisateur)
A l’initiative du fournisseur
RO-REJECT-P (rejet d’opération distante par le fournisseur)
RO-BIND (rattachement de service d’opération distante) Confirmé
RO-UNBIND (détachement de service d’opération distante) Confirmé
62 . Services d’association et de transfert
Le protocole ROSE spécifié ici nécessite un service de transfert pour la passation de l’information sous la forme d’APDU
de l’élément ROSE entre entités d‘application homologues et, si un lot de connexion est mis en œuvre dans le contrat
d’association, un service d’association pour établir des associations entre les entités d’application et les libérer. Ces
services sont assurés au moyen des divers éléments ASE ainsi que du service de présentation OSI.
La présente Spécification décrit un protocole générique (voir l’article 7), ainsi qu’un certain nombre de réalisations
particulières du service d’association (voir l’article 8) et du service de transfert (voir l’article 9). Le protocole générique
est indépendant des réalisations particulières choisies.
NOTE - Il est possible de définir ultérieurement d’autres applications d’association et de transfert, que ce soit sous forme
d’extensions à la présente norme ou d’applications propriétaires non normalisées.
Cette Norme décrit deux réalisations d’association particulières, fondées pour l’une sur l’élément ACSE et pour l’autre sur
l’élément RTSE, ainsi que deux réalisations particulières pour le transfert des APDU utilisant l’une le service de données
de présentation P-DATA et l’autre le service de transfert fiable RT-DATA.
63 . Modèle de protocole
Les services de l’élément ROSE, tels qu’ils sont définis dans la Rec. UIT-T X.881 I ISOKEI 13712-2, sont fournis par la
machine protocolaire d’opérations distantes (ROPM). Cette machine utilise les services fournis par le fournisseur du
service présentation OSI, ainsi qu’une collection d’éléments ASE devant inclure un élément a-ASE, pouvant inclure un
élément T-ASE et des éléments ASE pour en assurer le support. Cette collection inclut toujours l’élément ACSE.
L’utilisation de collections différentes aboutit a différentes réalisations OS1 du service d’opérations distantes (ROS).
Ce modèle est décrit dans la Figure 1.
En général, l’élément ROSE ne présume pas être l’utilisateur exclusif des services de l’élément a-ASE, de l’élément
T-ASE, des éléments ASE supports, ou de la couche de présentation. En outre, le concepteur du contexte d’application
peut spécifier au besoin l’utilisation de paramètres de service dont les valeurs ne dépendent pas des spécifications du
protocole ROSE. Toute exception à cette règle est indiquée dans la spécification de l’application correspondante.
7 Eléments de procédure du protocole ROSE de base
Le protocole ROSE de base comprend les éléments de procédure suivants:
a) établissement d’association;
b) libération d’association;
Rec. UIT-T X.882 (1994 F)
ISOKEI 13712-3 : 1995 (F)
rupture intempestive d’association;
Cl
d) invocation;
renvoi de résultat;
e)
renvoi d’erreur;
f)
g) rejet par l’utilisateur;
h) rejet par le fournisseur.
ROPM de base
FOURNCSSEUR DU SERVICE DE PRÉSENTATION
TISO4470-94/dOl
a-ASE Eknent de service d’application assurant IWblissement et la libkation de l’association
vASE El6ment de service d’application assurant le transfert de l’information
ROPM Machine protocolaire d’opérations distantes
0-ASE El&nents de service d’application propres aux opdrations
Figure 1 - Modèle de protocole
Ces éléments de procédure sont spécifiés dans ce qui suit. Un certain nombre de pseudo-primitives ont été introduites
pour décrire l’utilisation des services d’association et de transfert. Les différentes réalisations de ces services sont décrites
dans les articles 8 et 9 avec les primitives effectivement utilisées qui leur correspondent.
Les pseudo-primitives correspondant aux services d’association sont indiquées dans le Tableau 2.
Le paramètre result (résultat) de la pseudo-primitive d’établissement ESTABLZW prend les valeurs symboliques
«accepted» (accepté) et «rejected» (rejeté).
Le paramètre release cari fail (la libération peut échouer) prend les valeurs symboliques «truc» (vrai) et «false» (faux).
Dans des primitives successives de ce service, la valeur du paramètre peut passer de «truc» à «false» mais pas l’inverse.
Ce paramètre est présent dans la réponse ou la confirmation si et seulement si le paramètre result a la valeur «accepted».
Rec. UIT-T X.882 (1994 F) 7
ISOKEI 13712-3 : 1995 (F)
Tableau 2 - Pseudo-primitives correspondant aux réalisations d’association
Service assuré Pseudo-primi tive dem.
ind. rép. conf.
Etablissement d’association ESTABLISH
application context M
M(=)
(contexte d’application)
release cari fail M C
cc=>
(la libération peut échouer)
user data U U
CC=) c(=>
(données d’utilisateur)
result M
M(=)
(résultat)
Libération de l’association RELEASE
user data U U
C(=l CC=)
(données d’utilisateur)
result M
M(=l
(résultat)
Rupture de l’association du fait de ABORT
l’utilisateur
source M
(source)
user data U
cc=>
(données d’utilisateur)
Rupture de l’association du fait du ABORT-P
fournisseur
provider reason C
(motif du fournisseur)
Le paramètre result de la pseudo-primitive de libération RHEASE prend les trois valeurs symboliques «accepted»
(accepté), «rejected-released» (rejeté et libéré) et «rejected-not-released» (rejeté et non libéré).
Le paramètre source de la pseudo-primitive de rupture du fait de l’utilisateur ABORT prend les valeurs symboliques
«association-control-service-user» (utilisateur du service de commande d’association) ou «association-control-service-
provider» (fournisseur du service de commande d’association).
La valeur du paramètre user information (information d’utilisateur) dépend du contexte d’application mis en œuvre.
Le paramètre provider-reason (motif du fournisseur) de la pseudo-primitive de rupture du fait du fournisseur ABORT-P
prend les valeurs symboliques définies dans la Rec. UIT-T X.216 l ISOKEI 8822.
Les pseudo-primitives correspondant aux services de transfert sont indiquées dans le Tableau 3.
Tableau 3 - Pseudo-primitives correspondant aux réalisations de transfert
Service assuré Pseudo-primitive dem. ind.
I
Transfert d’information TRANSFER
user-data
(données d’utilisateur)
Rec. UIT-T X.882 (1994 F)
ISOKEI 13712-3 : 1995 (F)
Le présent article décrit l’utilisation des éléments des diverses APDU. Dans la Rec. UIT-T X.880 I ISOKEI 13712-1, les
types de données correspondant à ces APDU sont spécifiés en ASN. 1.
71 . Etablissement d’association
7.1.1 Objet
Tentative d’Établissement d’une association par l’invocation d’une opération de rattachement.
7.1.2 APDU utilisées
La procédure d’établissement d’association utilise les APDU BindInvoke (invocation de rattachement), BindResult
(résultat de rattachement) et BindError (erreur de rattachement). Ces APDU sont définies si et seulement si les champs
respectifs &ArgumentType (type d’argument), &ResultType (type de résultat) et &ParameterType (type de
paramètre) sont définis pour l’opération de rattachement bind et l’erreur qui lui est associée dans le lot de connexion
utilisé pour la commande dynamique d’association (voir la Rec. UIT-T X.880 I ISOKEI 13712-l pour la définition des
classes d’objets informationnels correspondantes).
7.1.2.1 APDU BindInvoke
L’APDU BindInvoke (invocation de rattachement) sert à demander l’établissement d’une association. Le Tableau 4 en
énumère les champs.
Tableau 4 - Champs de I’APDU BindInvoke
Présence Source Puits
Nom du champ
Argument U dem. ind.
Le champ Argument est dérivé du champ &ArgumentType (type d’argument) de l’opération bind (rattachement).
7.1.2.2 APDU BindResult
L’APDU BindResult (résultat de rattachement) sert à indiquer l’établissement avec succès d’une association. Le
Tableau 5 en énumère les champs.
Le champ Result (résultat) est dérivé du champ &ResultType (type de résultat) de l’opération bind (rattachement).
Tableau 5 - Champs de I’APDU BindResult
Nom du champ Présence Source Puits
Result (résultat) U rép. conf.
7.1.2.3 APDU BindError
L’APDU BindError (erreur de rattachement) sert à indiquer que la tentative d’établissement d’une association a échoué.
Le Tableau 6 en énumère les champs.
Le champ Error-Parameter est dérivé du champ &ParameterType (type de paramètre) de l’erreur associée a l’opération
de rattachement bind.
Tableau 6 - Champs de I’APDU BindError
Présence Source Puits
Nom du champ
rép. conf.
Error-Parameter (paramètre d’erreur) U
Rec. UIT-T X.882 (1994 F)
ISOKEI 13712-3 : 1995 (F)
7.1.3 Procédure d’établissement d’association
Cette procédure est commandée par les événements suivants:
une primitive de demande RO-BIND (rattachement d’opération distante);
a>
b) une APDU BindInvoke (invocation de rattachement) sous forme de données d’utilisateur dans une
primitive d’indication ESTABLZSH (établissement);
une primitive de réponse RO-BIND avec pour issue «result» (résultat = succès);
C)
d) une APDU BindResult (résultat de rattachement) sous forme de données d’utilisateur dans une primitive
de confirmation ESTABLZSH avec comme résultat «accepted» (accepté);
une primitive de réponse RO-BIND avec pour issue «errer» (erreur);
e>
une APDU BindError (erreur de rattachement) sous forme de données d’utilisateur dans une primitive de
f-l
confirmation ESTABLZSH avec comme résultat «rejected» (rejet).
L’envoi de 1’APDU BindInvoke (invocation de rattachement), BindResult (résultat de rattachement) ou BindError (erreur
de rattachement) est optionnel lorsque les champs respectifs SzargumentTypeOptional (type d’argument optionnel),
&resultTypeOptional (type de résultat optionnel) ou ¶meterTypeOptional (type de paramètre optionnel) de
l’opération et de l’erreur de rattachement bind portent la valeur TRUE (vrai).
7.1.3.1 Primitive de demande RO-BIND
A partir du paramètre Argument de la primitive de demande RO-BIND (rattachement d’opération distante), la machine
protocolaire ROPM demandeuse forme une APDU d’invocation de rattachement BindInvoke qu’elle véhicule dans le
paramètre user-data (données d’utilisateur) d’une primitive de demande d’établissement ESTABLZSH. La valeur du
paramètre release cari fail (la libération peut échouer) est déduite du champ &unbindCanFail (le détachement peut
échouer) du lot de connexion identifié par le paramètre de contexte d’application.
7.1.3.2 APDU BindInvoke
La machine protocolaire ROPM accepteuse émet une primitive d’indication RO-BIND (rattachement d’opération
distante), dont le paramètre Argument est dérivé de I’APDU d’invocation de rattachement BindInvoke.
7.1.3.3 Primitive de réponse RO-BIND positive «resulh
A partir du paramètre de résultat de rattachement Bind-Result de la primitive de réponse RO-BIND (rattachement
APDU de résultat de rattachement
d’opération distante), la machine protocolaire ROPM accepteuse forme une
BindResult qu’elle véhicule dans le paramètre user-data (données d’utilisateur) d’une primitive de réponse ESTABLZSH
dont le paramètre result prend la valeur «accepted» (accepté). Le paramètre unbind cari fail (le détachement peut
échouer) de la primitive de réponse RO-BIND détermine la valeur du paramètre release cari fail (la libération peut
échouer) de la primitive de réponse ESTABLZSH.
7.1.3.4 APDU BindResult
La machine protocolaire ROPM demandeuse émet une primitive de confirmation RO-BIND, dont le paramètre de
résultat de rattachement Bind-Result est dérivé de 1’APDU de résultat de rattachement BindResult.
7.1.3.5 Primitive de réponse RO-BIND négative «errer»
A partir du paramètre Bind-Error (erreur de rattachement) de la primitive de réponse RO-BIND, la machine protocolaire
ROPM accepteuse forme une APDU d’erreur de rattachement BindError qu’elle véhicule dans le paramètre user-data
(données d’utilisateur) d’une primitive de réponse ESTABLZSH.
7.1.3.6 APDU BindError
La machine protocolaire ROPM demandeuse émet une primitive de confirmation RO-BIND, dont le paramètre
Bind-Error (erreur de rattachement) est dérivé de I’APDU d’erreur de rattachement BindError.
Libération d’association
72 .
7.2.1 Objet
Tentative de libération d’une association par l’invocation d’une opération de détachement unbind.
10 Rec. UIT-T X.882 (1994 F)
ISOKEI 13712-3 : 1995 (F)
7.2.2 APDU utilisées
La procédure de liberation d’association utilise les APDU UnbindInvoke (invocation de détachement), UnbindResult
(résultat de detachement) et UnbindError (erreur de detachement). Ces APDU sont définies si et seulement si les champs
respectifs &ArgumentType (type d’argument), &ResultType (type de résultat) et &ParameterType (type de
paramètre) sont définis pour l’opération de détachement unbind et l’erreur qui lui est associée dans le connection
package (lot de connexion) utilise pour la commande dynamique d’association (voir la Rec. UIT-T X.880 I
ISOKEI 137 12- 1 pour la définition des classes d’objets informationnels correspondantes).
7.2.2.1 APDU UnbindInvoke
L’APDU UnbindInvoke (invocation de détachement) sert à demander la libération d’une association. Le Tableau 7 en
enumère les champs.
Le champ Argument est dérive du champ &ArgumentType (type d’argument) de l’opération de détachement unbind.
Tableau 7 - Champs de I’APDU UnbindInvoke
Nom du champ Présence Source Puits
U dem. ind.
Argument
7.2.2.2 APDU UnbindResult
L’APDU UnbindResult (résultat de détachement) sert a indiquer la liberation avec succès d’une association. Le Tableau 8
en énumère les champs.
Le champ Result est dérivé du champ &ResultType (type de résultat) de l’opération de détachement unbind.
Tableau 8 - Champs de I’APDU UnbindResult
Présence Source Puits
Nom du champ
U rép. conf.
Result (résultat)
7.2.2.3 APDU UnbindError
L’APDU UnbindError (erreur de détachement) sert à indiquer que la demande de libération d’une association est refusée.
Le Tableau 9 en énumère les champs.
Le champ Parameter est dérivé du champ &ParameterType (type de paramètre) de l’erreur associée à l’opération de
détachement unbind considérée.
Tableau 9 - Champs de I’APDU UnbindError
Présence Source Puits
Nom du champ
rép. conf.
Parameter (paramètre) U
7.2.3
Procédure de libération d’association
Cette procédure est commandée par les événements suivants:
une primitive de demande RO-UNBIND (détachement d’opération distante);
a)
b) une APDU UnbindInvoke (inv
...
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...