1、 STD-ITU-T RECMN X.722 AMD 3-ENGL 1997 m 48b259L Ob44b77 872 m INTERNATIONAL TELECOMMUNICATION UNION ITU-T TELECOMMUNICATION STAN DARD IZATION SECTOR OF ITU X.722 Amendment 3 (08J97) SERIES X: DATA NETWORKS AND OPEN SYSTEM COM M U N I CATI ON OS1 management - Structure of Management Information Info
2、rmation technology - Open Systems Interconnection - Structure of management information: Guidelines for the definition of managed objects Amendment 3: Guidelines for the use of Z in formalizing the behaviour of managed objects ITU-T Recommendation X.722 - Amendment 3 (Previously CCITT Recommendation
3、) STD-ITU-T RECNN X.722 AND 3-ENGL 1777 iBb2.591 Ob44b78 709 ITU-T X-SERIES RECOMMENDATIONS DATA NETWORKS AND OPEN SYSTEM COMMUNICATION ?UBLIC DATA NETWORKS Services and facilities Interfaces Transmission, signalling and switching Network aspects Maintenance Administrative arrangements )PEN SYSTEM I
4、NTERCONNECTION Model and notation Service definitions Connection-mode protocol specifications Connectionless-mode protocol specifications PICS proformas Protocol Identification Security Protocols Layer Managed Objects Conformance testing NTERWORKING BETWEEN NETWORKS General Satellite data transmissi
5、on systems kESSAGE HANDLING SYSTEMS DIRECTORY 3Si NETWORKING AND SYSTEM ASPECTS Networking Efficiency Naming, Addressing and Registration Abstract Syntax Notation One (ASN.l) Systems Management framework and architecture OS1 MANAGEMENT X. 1-X.199 X.l-X. 19 X.20-X.49 X.50-X.89 X.90-X. 149 X. 150-X. 1
6、79 X.180-X. 199 X.200-X.299 X.200-X.209 X.210-X.219 X.220-X.229 X.230-X.239 X.240-X.259 X.260-X.269 X.270-X.279 X.280-X.289 X.290-X.299 X.300-X.399 X.300-X.349 x.350-x.399 X.400-X.499 X.500-X.599 X.600-X.699 X.600-X.629 X.630-X.649 X.650-X.679 X.680-X.699 X.700-X.799 X.700-X.709 Management Communica
7、tion Service and Protocol X.710-X.719 Management functions SECURITY OS1 APPLICATIONS Commitment, Concurrency and Recovery Transaction processing Remote operations OPEN DISTRIBUTED PROCESSING x.730-x.799 X. 800-X. 849 X.850-X.899 X.850-X.859 X.860-X.879 X.880-X.899 X.900-X.999 For further details, pl
8、ease refer to ITU-T List of Recommendations. INTERNATIONAL STANDARD 10165-4 ITU-T RECOMMENDATION X.722 INFORMATION TECHNOLOGY - OPEN SYSTEMS INTERCONNECTION - STRUCTURE OF MANAGEMENT INFORMATION: GUIDELINES FOR THE DEFINITION OF MANAGED OBJECTS AMENDMENT 3 Guidelines for the use of 2 in formalizing
9、the behaviour of managed objects Summary This Amendment to CCITT Rec. X.722 I ISOAEC 10165-4 contains an illustrative example that demonstrates current best practice in the use of the Z formai description language for specifying Managed Object behaviour. It aims to establish a common basis and under
10、standing of this particular formal approach which will help achieve consistency in similar developments. It should provide a useful starting point for GDMO users wishing to use Z to improve their behaviour specifications. Formai specifications of MO behaviour are valuable since they are clear and un
11、ambiguous. The act of producing a formal specification forces the details of the behaviour to be analysed closely. Thus it can also be used as a tool to identify and correct ambiguities in a specification that will remain in natural language. This Amendment contains a technical guide on the use of t
12、he Z language for defining the behaviour of managed objects which support OS1 management interworking. It is informative and not normative. It does not require Formal Definition Techniques (FDTs) to be used to specify MO behaviour. If FDTs are to be used, it does not require 2 to be used; other lang
13、uages such as SDL are also suitable. Source The ITU-T Recommendation X.722, Amendment 3 was approved on the 9th of August 1997. The identical text is also published as ISO/IEC International Standard 10165-4. ITU-T Rec. X.722 (1992)/Amd.3 (1997 E) - i FOREWORD ITU (International Telecommunication Uni
14、on) is the United Nations Specialized Agency in the field of telecommuni- cations. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of the ITU. The ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view
15、 to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Conference (WTSC), which meets every four years, establishes the topics for study by the ITU-T Study Groups which, in their turn, produce Recommendations on these topics. The approval of Recommenda
16、tions by the Members of the IT-T is covered by the procedure laid down in WTSC Resolution No. 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with IS0 and IEC. NOTE In this Recommendation, the expression “Admi
17、nistration“ is used for conciseness to indicate both a telecommunication administration and a recognized operating agency, INTELLECTUAL PROPERTY RIGHTS The ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual
18、Property Right. The ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process. As of the date of approval of this Recommendation, the ITU had not receiv
19、ed notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementors are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database. O ITU 1998 All rights reserved
20、. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the ITU. 11 ITU-T Rec. X.722-(1992)/Amd.3 (1997 E) - - STDmITU-T RECNN X-722 AND 3-ENGL 1997 4b2572 ObY4b1 2T3 m
21、 CONTENTS 1) Table of contents 2) Subclause 2.1 . 3) New subclause 2.3 4) New Annex B . Annex B - Guidelines for the use of Z in formalizing the behaviour of Managed Objects . ITU-T Rec. X.722 (1992)/Amd.3 (1997 E) Page 1 1 1 1 2 . 111 STD-ITU-T RECNN X.722 AND 3-ENGL 1777 48b257L Ob44bA2 L3T ISO/IE
22、C 10165-4 : 1992/Amd.3 : 1998 (E) INTERNATIONAL STANDARD ITU-T RECOMMENDATION INFORMATION TECHNOLOGY - OPEN SYSTEMS INTERCONNECTION - STRUCTURE OF MANAGEMENT INFORMATION: GUIDELINES FOR THE DEFINITION OF MANAGED OBJECTS AMENDMENT 3 Guidelines for the use of Z in formalizing the behaviour of managed
23、objects 1) Table of contents Add the following reference to the table of contents: Annex B - Guidelines for the use of Z in formalizing the behaviour of managed objects 2) Subclause 2.1 Add the following reference to 2.1: - CCITT Recommendation X.731 (1992) I ISOAEC 10164-2: 1992, Information techno
24、logy - Open Systems Interconnection - Systems Management: State management firnetion. 3) New subclause 2.3 Add a new subclause as follows: 2.3 Additional references - ISOAEC 13568: l), Informution technology - Z speccation language. I) Presently at the stage of draft. 4) New Annex B Add a new Annex
25、B, as follows: ITU-T Rec. X.722 (1992)/Amd.3 (1997 E) 1 STD-ITU-T RECNN X-722 AND 3-ENGL 1997 W LiAb2591 Ob4LIb83 07b ISOAEC 10165-4 : 1992/Amd.3 : 1998 (E) Annex B Guidelines for the use of Z in formalizing the behaviour of Managed Objects (This annex does not form an integral part of this Recommen
26、dation I International Standard) B.l Introduction This annex contains a technical guide on the use of the Z language for defining the behaviour of managed objects which support OS1 management interworking. It is informative and not normative. It does not require Formal Definition Techniques (FDTs) t
27、o be used to specify MO behaviour. If FDTs are to be used, it does not require Z to be used; other languages such as SDL are also suitable. Even if Z is to be used, other ways of specifying MO behaviour are possible. Formal specifications of MO behaviour can be directly valuable because they are cle
28、ar and unambiguous. The act of producing a formai specification forces the details of the behaviour to be analysed closely. Thus, it can also be used as a tool to identify and correct ambiguities which might go undetected in a specification relying solely on natural language. For these reasons forma
29、i specification can be useful to improve behaviour specification. This annex contains an illustrative example that demonstrates current best practice. It aims to establish a common basis and understanding of this particular formal approach which will help achieve consistency in similar developments.
30、 It should provide a useful starting point for GDMO users wishing to use Z to improve their behaviour specifications. It is aimed at an audience familiar with the basic concepts of managed object specification using the GDMO templates, and the 2 language. For the remainder of this annex, the terms “
31、managed object” and “MO will be used to refer to a managed object class definition given using the GDMO templates. B.2 Language issues The Z notation is a formai specification notation based on set theory and predicate calculus. It possesses sufficient expressive power to be able to describe single
32、classes of managed objects. However, there exists no notion of encapsulation in Z. A Z specification typically consists of a model of some state and a collection of operations to modify the state. There is no method built into Z to parcel the state and its operations up into a single module and re-u
33、se it in another specification. The consequence of this becomes apparent when it becomes necessary to describe managed objects which inherit variables and behaviour from other managed object class definitions. The effect of inheritance can be achieved by the technique of schema inclusion at the expe
34、nse of some clarity. In ali other respects Z is suitable for expressing single classes of managed objects. B.3 What needs to be translated The behaviour definitions, or parts there of, need to be translated from the informal description into Z. The extent to which the remaining parts of the GDMO tem
35、plates need to be formalized depends largely on the needs of the specifier. The GDMO templates already include a semi-formal definition of data types in ASN.1. It is possible to write a Z specification using these ASN. 1 definitions as a basis for types used in the Z specification, and this saves a
36、significant amount of work. However, if a specification is written in this way, then it makes it a greater task for the specifier to ensure that it is syntactically correct. Without Z specifications of the ASN.l definitions, it is not possible to use existing Z tools which provide support for checki
37、ng the syntax and static semantics of a Z specification. In summary, it is possible to improve the behaviour definitions by using Z without re-writing the ASN.l data types, but there is a significant benefit to be gained by a full translation of the ASN.l data types into Z. Examples of how to conver
38、t ASN. 1 Basic Types into Z are provided in B.7.1. 2 ITU-T Rec. X.722 (1992)/Amd.3 (1997 E) ISO/IEC 10165-4 : 1992lAmd.3 : 1998 (E) B.3.1 From GDMO templates to Z This subclause contains general guidelines of how to go about translating a managed object from its informai description as given in this
39、 Recommendation I International Standard into Z. It should be stressed at the outset that such a translation can only be carried out informally since a formal translation would require, as a minimum, that both the source and target languages be formal. Moreover, as with any mapping between two disti
40、nct languages, there is bound to be some mismatch between their constructs. The problem multiplies when one of the languages happens to be informal or to include informal components. In this subclause some of the main features of the templates defined in this Recommendation I International Standard
41、are listed together with the ways in which they differ from or correspond to constructs in Z. In the process, general ways of resolving the mismatch or advice on how they may be tackled individually on an ad-hoc basis is offered. This annex will concentrate on what is necessary to describe the behav
42、iour of a managed object. Additional information on how to convert ASN.1 types is provided in B.6. B.3.2 Datatypes The first step is to rewrite the datatypes from this Recommendation I International Standard as Z types. ASN.1 provides the usual facilities of datatyping but its constructors are biase
43、d towards the description of datastreams communicated between systems. In ASN.l, the type constructors are defined as forms of list. In Z, types are sets. Although it is possible to model the ASN.l type constructors as sequences in Z, it is sometimes more natural to consider the operations available
44、 on the ASN.l types and to map them to Z types which more clearly describe their structure. The ASN. 1 sequence and set types can be mapped to Z tuples. The ASN.1 sequence-of type can be mapped to a Z sequence. The ASN.1 set-of type can be mapped to a Z set. ASN.1 includes special support for encodi
45、ng, such as type labels and default values. This does not need to be represented in Z since it doesnt affect the behaviour definition. Subclause B.6.2 provides additional information on how to convert ASN. 1 types. B.3.3 MO Attributes Managed objects are defined to have certain management attributes
46、. These attributes have a datatype defined in ASN. 1. They are assigned object identifiers. They also may have a matches-for property. Two ways to model such attributes have been proposed: simple attribute types; and attribute types as Schemas. The simplest is to represent the MO attribute within th
47、e MO as a Z variable with the appropriate datatype. Then separately we will need a constant definition which represents the object identifier of that attribute. This constant will be related to the actual attribute by convention only. We can use the actual fixed matches-for property when matching op
48、erations are defined for that attribute. An example of this is given in B.6.3. It is also possible to encapsulate all these properties of an attribute in a single schema type which will then be the type of the Z variable modelling the MO attribute. Thus, the schema will include the value of the attr
49、ibute as well as the object identifier and the matches-for property if any. An example of this is given in B.6.4. Where matching rules other than equality are required, it is possible to define the matches-for parameter as a Z relation over the type of the value of the attribute. This allows the formal representation of arbitrary ad-hoc matching rules, which may be important for scoping, filtering and object selection. It is difficult to model ASN.l type ANY in Z. One case where this is common is to give lists of attribute values. Thus, a fully formal model will pr
