INTERNATIONAL TELECOMMUNICATION UNION

STUDY GROUP 4

TELECOMMUNICATION
STANDARDIZATION SECTOR

STUDY PERIOD 2001-2004

TD 86 Rev.1 (PLEN)

English only

Original: English

Question(s):

18/4

27 October - 7 November 2003

TEMPORARY DOCUMENT

Source:

EDITOR OF Q.812

Title:

DRAFT REVISION OF RECOMMENDATION Q.812

 

This document is a draft revision of Recommendation Q.812.  It supports the work plan of Q18/4 to revise Q.811 and Q.812 to split at the layer 3/4 boundary.  It has a figure and place holder section for the discussion of SNMP.  Other issues that need to be address are the use of RFC2126 and the use of the Q versus the Qx terminology. 

 

 

 


 

INTERNATIONAL  TELECOMMUNICATION  UNION

 

 

 

ITU-T

Q.812

TELECOMMUNICATION
STANDARDIZATION  SECTOR
OF  ITU

(2003)  

 

 

 

 

 

SERIES Q: SWITCHING AND SIGNALLING

Specifications of Signalling System No. 7 – Q interface

 

 

Upper layer protocol profiles for the Q and X interfaces

 

ITU-T  Recommendation  Q.812

(Previously  CCITT  Recommendation)

 


 

ITU-T  Q-SERIES  RECOMMENDATIONS

SWITCHING AND SIGNALLING

 

 

 

SIGNALLING IN THE INTERNATIONAL MANUAL SERVICE

Q.1–Q.3

INTERNATIONAL AUTOMATIC AND SEMI-AUTOMATIC WORKING

Q.4–Q.59

FUNCTIONS AND INFORMATION FLOWS FOR SERVICES IN THE ISDN

Q.60–Q.99

CLAUSES APPLICABLE TO ITU-T STANDARD SYSTEMS

Q.100–Q.119

SPECIFICATIONS OF SIGNALLING SYSTEMS No. 4 AND No. 5

Q.120–Q.249

SPECIFICATIONS OF SIGNALLING SYSTEM No. 6

Q.250–Q.309

SPECIFICATIONS OF SIGNALLING SYSTEM R1

Q.310–Q.399

SPECIFICATIONS OF SIGNALLING SYSTEM R2

Q.400–Q.499

DIGITAL EXCHANGES

Q.500–Q.599

INTERWORKING OF SIGNALLING SYSTEMS

Q.600–Q.699

SPECIFICATIONS OF SIGNALLING SYSTEM No. 7

Q.700–Q.849

General

Q.700

Message transfer part (MTP)

Q.701–Q.709

Signalling connection control part (SCCP)

Q.711–Q.719

Telephone user part (TUP)

Q.720–Q.729

ISDN supplementary services

Q.730–Q.739

Data user part

Q.740–Q.749

Signalling System No. 7 management

Q.750–Q.759

ISDN user part

Q.760–Q.769

Transaction capabilities application part

Q.770–Q.779

Test specification

Q.780–Q.799

Q interface

Q.800–Q.849

DIGITAL SUBSCRIBER SIGNALLING SYSTEM No. 1

Q.850–Q.999

General

Q.850–Q.919

Data link layer

Q.920–Q.929

Network layer

Q.930–Q.939

User-network management

Q.940–Q.949

Stage 3 description for supplementary services using DSS 1

Q.950–Q.999

PUBLIC LAND MOBILE NETWORK

Q.1000–Q.1099

INTERWORKING WITH SATELLITE MOBILE SYSTEMS

Q.1100–Q.1199

INTELLIGENT NETWORK

Q.1200–Q.1999

BROADBAND ISDN

Q.2000–Q.2999

 

 

For further details, please refer to ITU-T List of Recommendations.


ITU-T  RECOMMENDATION  Q.812

 

upper layer protocol profiles for the Q and x interfaceS

 

 

Summary

This Recommendation provides the upper layer (5-7) protocol profiles for the Q and X interfaces as defined in the M.3000-Series of Recommendations

 

 

Source

ITU-T Recommendation Q.812 was revised by ITU-T Study Group 11 (1997-2000) and was approved under the WTSC Resolution No. 1 procedure on the 5th of June 1997.

 

 

Keywords

ACSE, ASN.1, CMISE, FTAM, Protocol Profiles, Q Interface, TMN, X Interface.

 


FOREWORD

ITU (International Telecommunication Union) is the United Nations Specialized Agency in the field of telecommunications. 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 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 Recommendations by the Members of the ITU‑T is covered by the procedure laid down in WTSC Resolution No. 1.

In some areas of information technology which fall within ITU-T’s purview, the necessary standards are prepared on a collaborative basis with ISO and IEC.

 

 

 

 

 

NOTE

In this Recommendation, the expression "Administration" 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 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/had not received 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.

 

 

 

 

 

γ  ITU  2003

All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the ITU.


CONTENTS

1         Scope. 14

2         References. 14

3         Definitions. 18

3.1........ International Standardized Profile (ISP) 18

3.2........ Interactive Agent (IA) (Q.814) 18

3.3........ Transport Layer Security (Q.814) 18

3.4........ Distinguished Encoding Rules (DER) (X.690) 18

3.5........ Interactive Agent Transfer Protocol (IATP) (Q.814) 19

3.6........ Electronic Data Interchange (EDI) Translator (Q.814) 19

4         Abbreviations. 19

5         Upper layer protocol specifications for the OSI paradigm.. 21

5.1........ Introduction to Upper layer protocol specifications for the OSI paradigm.. 21

5.2........ Upper layer protocol specification for Interactive Class services. 22

5.3........ Upper layer protocol specification for File-oriented Class services. 23

5.4........ Upper layer protocol specification for Directory services. 23

5.5........ Upper layer protocol specification for store and forward services. 24

6         Upper layer protocol specification for Interactive Class services using the OSI paradigm.. 25

6.1........ Transport layer profiles. 25

6.1.1..... Transport layer profile for CLNS1, CLNS2 and CLNS3. 25

6.1.1.1.. Services profile. 25

6.1.1.2.. Protocol profile. 25

6.1.1.3.. Class of service. 25

6.1.1.4.. Transport layer attributes. 25

6.1.2..... Transport layer profile for CONS1, CONS2, CONS3 and CONS5. 26

6.1.2.1.. The section defines the transport layer profile for use with CONS1c CONS2, CONS3, CONS4 and CONS5 as defined in ITU-T Rec. Q.811 [45].Services profiles. 26

6.1.2.2.. Protocol profile. 27

6.1.3..... ISO TP0/TCP/IP Profile For use with the IP service. 30

6.2........ Session layer 30

6.2.1..... Service definition. 30

6.2.1.1.. Functional units. 30

6.2.2..... Protocol specification. 30

6.2.2.1.. User data. 30

6.3........ Presentation layer 30

6.3.1..... Service definition. 30

6.3.1.1.. Functional units. 31

6.3.2..... Protocol specification. 31

6.3.3..... Encoding rules for transfer syntax. 31

6.4........ Application layer 31

6.4.1..... Application layer architecture. 31

6.4.2..... Association control service element 31

6.4.2.1.. Service definition. 31

6.4.2.2.. Protocol specification. 31

6.4.2.3.. Use of the SACF for association control 32

6.4.2.4.. Abstract Syntax Name. 32

6.4.3..... Remote operations. 32

6.4.3.1.. Service definition. 32

6.4.3.2.. Protocol specification. 32

6.4.4..... Common management information. 33

6.4.4.1.. Service definition. 33

6.4.4.2.. Protocol specification. 33

6.4.4.3.. Abstract Syntax. 33

6.5........ Security support for interactive applications. 33

7         Upper layer protocol specification for File-oriented Class functions using the OSI paradigm.. 34

7.1........ Session layer 34

7.1.1..... Service profile. 34

7.1.1.1.. Functional units. 34

7.1.2..... Protocol profile. 34

7.2........ Presentation layer 34

7.2.1..... Service definition. 34

7.2.1.1.. Functional units. 34

7.2.2..... Protocol specification. 34

7.2.3..... Encoding rules for transfer syntax. 34

7.3........ Application layer profile. 35

7.3.1..... Application layer architecture. 35

7.3.2..... File transfer, access and management 35

7.3.2.1.. Service profile. 35

7.3.2.2.. Protocol profile. 35

7.3.2.3.. Abstract Syntax. 36

7.3.2.4.. Support of document types. 36

7.4........ Security Support for FTAM Services. 37

8         Upper layer protocol specification for Directory services using the OSI paradigm.. 37

8.1........ Session layer 37

8.1.1..... Service definition. 37

8.1.1.1.. Functional units. 37

8.1.2..... Protocol specification. 37

8.1.3..... User Data. 37

8.2........ Presentation layer 37

8.2.1..... Service definition. 37

8.2.2..... Protocol specification. 37

8.3........ Application layer 38

8.3.1..... Application Layer architecture. 38

8.3.2..... Directory protocol Abstract Syntaxes. 38

8.3.3..... Directory application contexts. 38

8.3.4..... Association control service element 38

8.3.4.1.. Service definition. 38

8.3.4.2.. Protocol specification. 38

8.3.5..... Remote operations. 38

8.3.5.1.. Service definition. 38

8.3.5.2.. Protocol specification. 38

8.4........ Security Support for Directory Services. 38

9         Conformance for the OSI paradigm.. 39

10       Protocol profile for CORBA-based services. 39

10.1...... Scope of CORBA protocol profile. 39

10.2...... Overview of profile for CORBA-based services. 39

10.3...... Service definition. 40

10.4...... GIOP protocol specification. 41

10.5...... Secure IOP protocol specification. 41

10.6...... IIOP protocol specification. 41

10.7...... TCP/IP protocol profile for use with IIOP. 41

11       Protocol Profile for EDI/EDIFACT Based Services. 41

11.1...... Scope of EDI/EDIFACT Protocol Profile. 41

11.2...... Layer Summary. 42

11.3...... TCP/IP protocol profile for use with IA.. 42

11.4...... TLS Protocol Profile for Use With IA.. 42

11.5...... IA Profile. 42

11.6...... Security Module For Whole Message Protection Profile. 42

11.7...... EDI/EDIFACT Translator Protocol 43

12       Protocol profile for the SNMP paradigm.. 44

13       Protocol Profile for the Telecommunications Markup Language (tML) Paradigm.. 45

Appendix I 46

I.1 Introduction. 46

I.1.1...... Overview.. 46

I.2.1...... Creating managed objects. 47

I.2.1.1... Explicit creation – Manager role. 47

I.2.1.2... Explicit creation – Agent role. 48

I.2.1.3... Summary. 49

I.2.1.4... Automatic creation – Agent role. 49

I.2.1.5... Automatic creation – Manager role. 49

I.2.1.6... Summary for AutoCreation. 50

I.2.2...... Get operation. 50

I.2.2.1... Manager role. 50

I.2.2.2... Agent role. 51

I.2.2.3... Summary GET operation. 52

I.2.3...... Set operation. 52

I.2.3.1... Manager role. 52

I.2.3.3... Summary SET operation. 54

I.2.4...... Action operation. 54

I.2.4.1... Manager role. 55

I.2.4.2... Agent role. 55

I.2.4.3... Summary of ACTION operation. 56

I.2.5...... Delete operation. 56

I.2.5.1... Manager role. 56

I.2.5.3... Summary of DELETE operation. 57

I.3 CMIP notification. 57

I.3.1...... Manager role. 57

I.3.3...... Summary for NOTIFICATION.. 58

I.4 Implementation issues. 58

I.4.1...... Protocol stack related. 58

I.4.2...... Permitted and required values. 58

I.4.3...... Initial value. 59

I.4.4...... Filtering on single object 59

I.4.5...... Scoping only. 60

I.4.6...... Scoping and filtering. 60

I.5 Examples of the use of allomorphism.. 61

Appendix 2  63

1         Introduction. 10

1.1........ Scope. 10

1.2........ References. 10

1.2.1..... Publicly available specification references. 14

1.3........ Abbreviations. 14

1.4........ Terms. 15

1.4.1..... International Standardized Profile (ISP): 15

1.4.2..... Interactive Agent (Q.814) 15

1.4.3..... Transport Layer Security (Q.814) 15

1.4.4..... Distinguished Encoding Rules (DER) (X.690) 16

1.4.5..... Interactive Agent Transfer Protocol (IATP) (Q.814) 16

1.4.6..... EDI Translator (Q.814) 16

2         Upper layer protocol specifications for the OSI paradigm.. 16

2.1........ Introduction. 16

2.2........ Upper layer protocol specification for Interactive Class services. 17

2.3........ Upper layer protocol specification for File-oriented Class services. 18

2.4........ Upper layer protocol specification for Directory services. 18

2.5........ Upper layer protocol specification for store and forward services. 19

3         Upper layer protocol specification for Interactive Class services using the OSI paradigm.. 20

3.1........ Transport layer profiles. 20

3.1.1..... Transport layer profile for CLNS1, CLNS2 and CLNS3. 20

3.1.1.1.. Services profile. 20

3.1.1.2.. Protocol profile. 20

3.1.1.3.. Class of service. 20

3.1.1.4.. Transport layer attributes. 20

3.1.2..... Transport layer profile for CONS1, CONS2, CONS3 and CONS5. 21

3.1.2.1.. The section defines the transport layer profile for use with CONS1c CONS2, CONS3, CONS4 and CONS5 as defined in ITU-T Rec. Q.811 [xx].Services profiles. 21

3.1.2.2.. Protocol profile. 22

3.1.3..... Transport Layer Protocol Profile For use with the IP service. 25

3.2........ Session layer 25

3.2.1..... Service definition. 25

3.2.1.1.. Functional units. 25

3.2.2..... Protocol specification. 25

3.2.2.1.. User data. 25

3.3........ Presentation layer 25

3.3.1..... Service definition. 25

3.3.1.1.. Functional units. 26

3.3.2..... Protocol specification. 26

3.3.3..... Encoding rules for transfer syntax. 26

3.4........ Application layer 26

3.4.1..... Application layer architecture. 26

3.4.2..... Association control service element 26

3.4.2.1.. Service definition. 26

3.4.2.2.. Protocol specification. 26

3.4.2.3.. Use of the SACF for association control 27

3.4.2.4.. Abstract Syntax Name. 27

3.4.3..... Remote operations. 27

3.4.3.1.. Service definition. 27

3.4.3.2.. Protocol specification. 27

3.4.4..... Common management information. 28

3.4.4.1.. Service definition. 28

3.4.4.2.. Protocol specification. 28

3.4.4.3.. Abstract Syntax. 28

3.5........ Security support for interactive applications. 28

4         Upper layer protocol specification for File-oriented Class functions using the OSI paradigm.. 29

4.1........ Session layer 29

4.1.1..... Service profile. 29

4.1.1.1.. Functional units. 29

4.1.2..... Protocol profile. 29

4.2........ Presentation layer 29

4.2.1..... Service definition. 29

4.2.1.1.. Functional units. 29

4.2.2..... Protocol specification. 29

4.2.3..... Encoding rules for transfer syntax. 29

4.3........ Application layer profile. 30

4.3.1..... Application layer architecture. 30

4.3.2..... File transfer, access and management 30

4.3.2.1.. Service profile. 30

4.3.2.2.. Protocol profile. 30

4.3.2.3.. Abstract Syntax. 31

4.3.2.4.. Support of document types. 31

4.4........ Security Support for FTAM Services. 32

5         Upper layer protocol specification for Directory services using the OSI paradigm.. 32

5.1........ Session layer 32

5.1.1..... Service definition. 32

5.1.1.1.. Functional units. 32

5.1.2..... Protocol specification. 32

5.1.3..... User Data. 32

5.2........ Presentation layer 32

5.2.1..... Service definition. 32

5.2.2..... Protocol specification. 32

5.3........ Application layer 33

5.3.1..... Application Layer architecture. 33

5.3.2..... Directory protocol Abstract Syntaxes. 33

5.3.3..... Directory application contexts. 33

5.3.4..... Association control service element 33

5.3.4.1.. Service definition. 33

5.3.4.2.. Protocol specification. 33

5.3.5..... Remote operations. 33

5.3.5.1.. Service definition. 33

5.3.5.2.. Protocol specification. 33

5.4........ Security Support for Directory Services. 33

6         Conformance for the OSI paradigm.. 34

7         Protocol profile for CORBA-based services. 34

7.1........ Scope of CORBA protocol profile. 34

7.2........ Overview of profile for CORBA-based services. 34

7.3........ Service definition. 36

7.4........ GIOP protocol specification. 36

7.5........ Secure IOP protocol specification. 36

7.6........ IIOP protocol specification. 36

7.7........ TCP/IP protocol profile for use with IIOP. 36

8         Protocol Profile for EDI/EDIFACT Based Services. 36

8.1........ Scope of EDI/EDIFACT Protocol Profile. 36

8.2........ Layer Summary. 37

8.3........ TCP/IP protocol profile for use with IA.. 37

8.4........ TLS Protocol Profile for Use With IA.. 37

8.5........ IA Profile. 37

8.6........ Security Module For Whole Message Protection Profile. 37

8.7........ EDI/EDIFACT Translator Protocol 38

9         Protocol profile for the SNMP paradigm.. 39

Appendix I 41

I.1 Introduction. 41

I.1.1...... Overview.. 41

I.2.1...... Creating managed objects. 42

I.2.1.1... Explicit creation – Manager role. 42

I.2.1.2... Explicit creation – Agent role. 43

I.2.1.3... Summary. 44

I.2.1.4... Automatic creation – Agent role. 44

I.2.1.5... Automatic creation – Manager role. 44

I.2.1.6... Summary for AutoCreation. 45

I.2.2...... Get operation. 45

I.2.2.1... Manager role. 45

I.2.2.2... Agent role. 46

I.2.2.3... Summary GET operation. 47

I.2.3...... Set operation. 47

I.2.3.1... Manager role. 47

I.2.3.3... Summary SET operation. 49

I.2.4...... Action operation. 49

I.2.4.1... Manager role. 50

I.2.4.2... Agent role. 50

I.2.4.3... Summary of ACTION operation. 51

I.2.5...... Delete operation. 51

I.2.5.1... Manager role. 51

I.2.5.3... Summary of DELETE operation. 52

I.3 CMIP notification. 52

I.3.1...... Manager role. 52

I.3.3...... Summary for NOTIFICATION.. 53

I.4 Implementation issues. 53

I.4.1...... Protocol stack related. 53

I.4.2...... Permitted and required values. 53

I.4.3...... Initial value. 54

I.4.4...... Filtering on single object 54

I.4.5...... Scoping only. 55

I.4.6...... Scoping and filtering. 55

I.5 Examples of the use of allomorphism.. 56

Appendix 2  58

 

 


Recommendation Q.812

UPPER LAYER PROTOCOL PROFILES FOR THE Q and X INTERFACES

(revised in 2003)

1Introduction

1           Scope

This Recommendation defines the characteristics of protocol profiles for the Q and X interfaces, as defined in the M.3000-Series of Recommendations. The interface will support bidirectional data transfer for the management of telecommunications systems.

The need for security functionality is recognized, but is not fully addressed in this Recommendation and is for further study. Users may need to use mechanisms outside this Recommendation in order to address their specific security needs. Security mechanisms chosen may depend on the network configuration being used.

This Recommendation defines:

–           the layer services profiles;

–           the layer protocols profiles;

–           the application service and protocols profiles;

–           the conformance requirements to be met by an implementation of this interface.

This Recommendation does not define:

–           the structure or meaning of the management information that is transmitted by means of the protocol suite;

–           the manner in which management is accomplished as a result of the application protocol exchanges;

–           the interactions which result in the use of the application layer protocols.

The profiles in this Recommendation align with equivalent ISPs.

2           References

The following ITU-T Recommendations, and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision, all users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendation and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published.

[1]         ISO/IEC/TR 10000-1:1995, Information technology – Framework and taxonomy of International Standardized Profiles – Part 1: General principles and documentation framework.

[2]         ITU-T Recommendation X.200 (1994) | ISO/IEC 7498-1:1994, Information technology – Open Systems Interconnection – Basic reference model: The basic model.

[3]         ITU-T Recommendation M.3010 (19962000), Principles for a telecommunications management network.


[4]         ISO/IEC 8073:1997, Information technology – Open Systems Interconnection – Protocol for providing the connection-mode transport service.

[5]         ITU-T Recommendation X.225 (1995) | ISO/IEC 8327-1:1996, and Amd.1 (1997), Information technology – Open Systems Interconnection – Connection-oriented session protocol: Protocol specification.

[6]         ISO/IEC ISP 11183-1:1992, Information technology – International Standardized Profiles AOM1n OSI Management – Management Communications – Part 1: Specification of ACSE, presentation and session protocols for the use by ROSE and CMISE.

[7]         ITU-T Recommendation X.216 (1994) | ISO/IEC 8822:1994, Presentation service definition.

[8]         ITU-T Recommendation X.226 (1994) | ISO/IEC 8823-1:1994, Information technology – Open Systems Interconnection – Connection-oriented presentation protocol: Protocol specification.

[9]         CCITT Recommendation X.209 (1988), Specification of basic encoding rules for Abstract Syntax Notation One (ASN.1).

             ISO/IEC 8825:1990, Information technology – Open Systems Interconnection – Specification of basic encoding rules for Abstract Syntax Notation One (ASN.1).

[10]       ITU-T Recommendation X.680 (1994) | ISO/IEC 8824-1:1995, Information technology – Abstract Syntax Notation One (ASN.1): Specification of basic notation.

[11]       ITU-T Recommendation X.681 (1994) | ISO/IEC 8824-2:1995, Information technology – Abstract Syntax Notation One (ASN.1): Information object specification.

[12]       ITU-T Recommendation X.682 (1994) | ISO/IEC 8824-3:1995, Information technology – Abstract Syntax Notation One (ASN.1): Constraint specification.

[13]       ITU-T Recommendation X.683 (1994) | ISO/IEC 8824-4:1995, Information technology – Abstract Syntax Notation One (ASN.1): Parametrization of ASN.1 specifications.

[14]       CCITT Recommendation X.208 (1988) | ISO/IEC 8824:1990, Specification of Abstract Syntax Notation One (ASN.1).

[15]       ISO/IEC 9545:1994, Information technology – Open Systems Interconnection – Application Layer structure.

[16]       ITU-T Recommendation X.217 (1995) | ISO/IEC 8649:1996, Information technology – Open Systems Interconnection – Service definition for the association control service element.

[17]       ITU-T Recommendation X.227 (1995) | ISO/IEC 8650-1:1996, Information technology – Open Systems Interconnection – Connection-oriented protocol for the association control service element: Protocol specification.

[18]       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.

[19]       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.


[20]       CCITT Recommendation X.710 (1991), Common management information service definition for CCITT applications.

             ISO/IEC 9595:1991, Information technology – Open Systems Interconnection – Common management information service definition.

[21]       CCITT Recommendation X.711 (1991), Common management information protocol specification for CCITT applications.

             ISO/IEC 9596-1:1991, Information technology – Open Systems Interconnection – Common management information protocol – Part 1: Specification.

[22]       ISO/IEC ISP 11183-3:1992, Information technology – International Standardized Profiles AOM1n OSI management – Management Communications – Part 3: CMISE/ROSE for AOM11 – Basic Management Communications.

[23]       ISO/IEC ISP 11183-2:1992, Information technology – International Standardized Profiles AOM1n OSI management – Management Communications – Part 2: CMISE/ROSE for AOM12 – Enhanced Management Communications.

[24]       ISO/IEC ISP 10607-1:1995, Information technology – International Standardized Profiles AFTnn – File Transfer, Access and Management – Part 1: Specification of ACSE, Presentation and Session protocols for the use of FTAM.

[25]       ISO 8571-1:1988, Information processing systems – Open Systems Interconnection – File Transfer, Access and Management – Part 1: General Introduction.

[26]       ISO 8571-2:1988, Information processing systems – Open Systems Interconnection – File Transfer, Access and Management – Part 2: Virtual Filestore Definition.

[27]       ISO 8571-3:1988, Information processing systems – Open Systems Interconnection – File Transfer, Access and Management – Part 3: File Service Definition.

[28]       ISO 8571-4:1988, Information processing systems – Open Systems Interconnection – File Transfer, Access and Management – Part 4: File Protocol Specification.

[29]       ITU-T Recommendation X.500 (1997) | ISO/IEC 9594-1:1997, Information technology – Open Systems Interconnection – The Directory: Overview of concepts, models and services.

[30]       ITU-T Recommendation X.501 (1997) | ISO/IEC 9594-2:1997, Information technology – Open Systems Interconnection – The Directory: Models.

[31]       ITU-T Recommendation X.511 (1997) | ISO/IEC 9594-3:1997, Information technology – Open Systems Interconnection – The Directory: Abstract service definition.

[32]       ITU-T Recommendation X.518 (1997) | ISO/IEC 9594-4:1997, Information technology – Open Systems Interconnection – The Directory: Procedures for distributed operation.

[33]       ITU-T Recommendation X.519 (1997) | ISO/IEC 9594-5:1997, Information Technology – Open Systems Interconnection – The Directory: Protocol specifications.

[34]       ITU-T Recommendation X.520 (1997) | ISO/IEC 9594-6:1997, Information technology – Open Systems Interconnection – The Directory: Selected attribute types.

[35]       ITU-T Recommendation X.521 (1997) | ISO/IEC 9594-7:1997, Information technology – Open Systems Interconnection – The Directory: Selected object classes.

[36]       ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1997, Information technology – Open Systems Interconnection – The Directory: Authentication framework.


[37]       ITU-T Recommendation X.880 (1994) | ISO/IEC 13712-1:1995, Information technology – Remote Operations: Concepts, model and notation.

[38]       ITU-T Recommendation X.881 (1994) | ISO/IEC 13712-2:1995, Information technology – Remote Operations: OSI realizations – Remote Operations Service Element (ROSE) service definition.

[39]       ITU-T Recommendation X.830 (1995), Information technology – Open Systems Interconnection – Generic upper layers security: Overview, models and notation.

[40]       ISO/IEC ISP 10607-3:1995, Information technology – International Standardized Profiles AFTnn – File Transfer, Access and Management – Part 3: AFT11 – Simple File Transfer Service (unstructured).

[41]       ITU-T Recommendation X.214 (1995) | ISO/IEC 8072:1996, Information technology – Open Systems Interconnection – Transport service definition.

[42]       ITU-T Recommendation X.882 (1994) | ISO/IEC 13712-3:1995, Information technology – Remote Operations: OSI realizations – Remote Operations Service Element (ROSE) protocol specification.

[43]       CCITT Recommendation X.800 (1991), Security architecture for Open Systems Interconnection for CCITT applications.

[44]       ITU-T Recommendation X.803 (1994), Information technology – Open Systems Interconnection – Upper layers security model.

[45]       ITU-T Recommendation Q.811 (20031997), Lower layer protocol profiles for the Q and X interfaces.

[46]       Recommendation Q.814 (2000)- Specification of an electronic data interchange interactive agentSpecification of an electronic Electronic data Data interchange Interchange interactive Interactive agentAgent

[47]       Recommendation Q.815 (2000)- Specification of a security model for whole message protectionSpecification of a security Security module Module to be used in association with Q.814 For Whole Message Protection

[48]       IETF RFC 3410 (2002)"Introduction and Applicability Statements for Internet Standard Management Framework"

[49]       IETF RFC 3411 (2002) "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks

[50]       IETF RFC 3412 (2002) "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)"

[51]       IETF RFC 3413 (2002) "Simple Network Management Protocol (SNMP) Applications"

[52]       IETF RFC 3414 (2002) "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)"

[53]       IETF RFC 3415 (2002) "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)"

[54]       IETF RFC 3416 (2002) "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)"

[55]       IETF RFC 3417 (2002) "Transport Mappings for the Simple Network Management Protocol (SNMP)"

[56]       IETF RFC 3584 (2003) “Coexistence between Version 1, Version 2, and Version 3 of the

             Internet-standard Network Management Framework”

[57]       IETF RFC 2578 (1999), "Structure of Management Information Version 2 (SMIv2)"

[58]       IETF RFC 3430 (2002) “Simple Network Management Protocol Over Transmission Control

             Protocol Transport Mapping”

[59]       IETF RFC 2401 (1998) “Security Architecture for the Internet Protocol”

[60]    ISO/IEC ISP 10608-1 (1992) “Connection-mode Transport Service over Connectionless-mode Network Service - Part 1: General overview and subnetwork-independent requirements”

[61]     ISO/IEC ISP 10609-1 (1992) “Connection-mode Transport Service over connection-mode Network Service -- Part 1: Subnetwork-type independent requirements for Group TB”

[60]       ITU-T Recommendation X.920 (1997) - Information technology – Open Distributed Processing – Interface Definition Language

 

Publicly available specification references

All references in this subclause were correct at the time of approval of this Recommendation. The provisions of the referenced specifications, as identified in this subclause, are valid within the context of this Recommendation. The reference to a specification within this Recommendation does not give it any further status within ITU-T; in particular, it does not give the referenced specification the status of a Recommendation.

[62]–     CORBA GIOP Specification, Chapter 15 of The Common Object Request Broker: Architecture and Specification, Revision 2.3, Object Management Group (OMG Doc. Number: Formal/98-12-01).

[63]–     CORBA Security Service Specification, Chapter 15 of CORBAservices: Common Object Services Specification, Object Management Group (OMG Doc. Number: Formal/98-12-17).

[64]       ITU-T Recommendation M.3030 (2002) Telecommunications Markup Language (tML) framework  

 

3           Definitions

3.1         International Standardized Profile (ISP)

An internationally agreed-to, harmonized document which identifies a standard or group of standards, together with options and parameters, necessary to accomplish a function or a set of functions [1].

3.2         Interactive Agent (IA) (Q.814)

The IA supports the exchange of electronic data interchange (UN/EDIFACT or ASC X12 EDI) transactions between peer entities. The IA functions as an interface between its direct user (normally an EDIFACT/ASC X12 EDI translator or a security module) and the transport layer security. Various implementation approaches may be taken ranging from a simple API (Application Program Interface) through a stand‑alone program. The IA is described in draft Recommendation Q.814 and the Security Module is described in draft Recommendation Q.8sm815.

3.3         Transport Layer Security (Q.814)

The Transport Layer Security (TLS) protocol optionally provides communications privacy. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, and intrusion. The TLS protocol also provides strong peer authentication and data flow integrity.

3.4         Distinguished Encoding Rules (DER) (X.690)

DER for ASN.1 are a subset of Basic Encoding Rules (BER), and give exactly one way to represent any ASN.1 value as an octet string. DER are intended for applications in which a unique octet string encoding is needed, and is the case when an ASN.1 message is encoded for transport via TLS. DER are described in X.690. In this profile the definite‑length method of constructing IA messages must be employed.

3.5         Interactive Agent Transfer Protocol (IATP) (Q.814)

The IATP protocol is utilized between peer Interactive Agents wishing to exchange Electronic Data Interchange transactions/messages via Transmission Control Protocol/Internet Protocol utilizing Transport Layer Security. The IATP is described in ITU-T Recommendation Q.814.

3.6         Electronic Data Interchange (EDI) Translator (Q.814)

A computer software module or program that translates private data formats and representations to/from standard formats and standard data representations such as those specified by ISO 9735 or ANSI ASC X12.

4           Abbreviations

This Recommendation uses the following abbreviations.

ACSE          Association Control Service Element

AE               Application Entity

APDU         Application Protocol Data Unit

ASE             Application Service Element

ASN.1         Abstract Syntax Notation One

ASO            Application Service Object

BER             Basic Encoding Rules

CCITT         International Telegraph and Telephone Consultative Committee

CF               Control Function

CMIP          Common Management Information Protocol

CMISE        Common Management Information Service Element

CORBA      Common Object Request Broker Architecture

DAP            Directory Access Protocol

DCN           Data Communication Network

DER            Distinguished Encoding Rules

DSA            Directory System Agent

DUA            Directory User Agent

EDI              Electronic Data Interchange

EDIFACT   United Nations rules for Electronic Data Interchange For Administration, Commerce and Transport

FTAM         File Transfer, Access and Management

GULS          Generic Upper Layer Security

IA                Interactive Agent

IATP           Interactive Agent Transfer Protocol

IEC              International Electrotechnical Commission

IDL              Interface Definition Language

IETF            Internet Engineering Task Force

IP                 Internet Protocol

IPSec           Security Architecture for the IP Protocol

ISO             International Organization for Standardization

ISP              International Standardized Profile

ITU              International Telecommunication Union

ITU-T          International Telecommunication Union – Telecommunication Standardization Sector

NBS            National Bureau of Standards

NE               Network Element

OS               Operations System

OSI             Open Systems Interconnection

PDU            Protocol Data Unit

RFC             Request for Comments

ROS            Remote Operations Service

ROSE          Remote Operations Service Element

SACF          Single Association Control Function

SMASE       Systems Management Application Service Element

SNMP         Simple Network Management Protocol

SPDU          Session ProtcolProtocol Data Unit

TCP             Transmission Control Protocol

TLS             Transport Layer Security

tML             Telecommunications Markup Language

TMN           Telecommunications Management Network

UDP            User Datagram Protocol

USM            User-based Security Model

1Terms

1.4.11.1.1International Standardized Profile (ISP):

An internationally agreed-to, harmonized document which identifies a standard or group of standards, together with options and parameters, necessary to accomplish a function or a set of functions [1].

1.4.21.1.1Interactive Agent (Q.814)

The IA supports the exchange of electronic data interchange (UN/EDIFACT or ASC X12 EDI) transactions between peer entities. The IA functions as an interface between its direct user (normally an EDIFACT/ASC X12 EDI translator or a security module) and the transport layer security. Various implementation approaches may be taken ranging from a simple API (Application Program Interface) through a stand‑alone program. The IA is described in draft Recommendation Q.814 and the Security Module is described in draft Recommendation Q.8sm815.

1.4.31.1.1Transport Layer Security (Q.814)

The Transport Layer Security (TLS) protocol optionally provides communications privacy. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, and intrusion. The TLS protocol also provides strong peer authentication and data flow integrity.

1.4.41.1.1Distinguished Encoding Rules (DER) (X.690)

DER for ASN.1 are a subset of Basic Encoding Rules (BER), and give exactly one way to represent any ASN.1 value as an octet string. DER are intended for applications in which a unique octet string encoding is needed, and is the case when an ASN.1 message is encoded for transport via TLS. DER are described in X.690. In this profile the definite‑length method of constructing IA messages must be employed.

1.4.51.1.1Interactive Agent Transfer Protocol (IATP) (Q.814)

The IATP protocol is utilized between peer Interactive Agents wishing to exchange Electronic Data Interchange transactions/messages via Transmission Control Protocol/Internet Protocol utilizing Transport Layer Security. The IATP is described in ITU-T Recommendation Q.814.

1.4.61.1.1EDI Translator (Q.814)

A computer software module or program that translates private data formats and representations to/from standard formats and standard data representations such as those specified by ISO 9735 or ANSI ASC X12.

25       Upper layer protocol specifications for the OSI paradigm

2.15.1       Introduction to Upper layer protocol specifications for the OSI paradigm

The communication services and protocols referred to in this Recommendation are in accordance with the Open Systems Interconnection (OSI) Reference Model [2].

The protocols for the different layers are based on ITU-T Recommendations and/or ISO Standards, CORBA Specifications form the OMG and Internet Protocol Specifications from the IETF.

Three types of protocol profiles are defined in this Recommendation:

–           upper layer protocol profile for Interactive Class services;

–           upper layer protocol profile for File-oriented Class services;

–           upper layer protocol specification for Directory services.

The three protocol profiles can be applied to applications using DCN, as defined by Recommendation M.3010 [3].

Interface Q is defined to intend to connect Mediation Devices to Operations Systems (OSs), Q Adapters to OSs, NEs to OSs, and OSs to OSs via a DCN. The X Interface is defined to connect the TMNs of two Administrations.

Other ASEs will be added in the identified protocol profiles as new requirements develop.


2.25.2       Upper layer protocol specification for Interactive Class services

Figure 1 illustrates the protocol stack of the upper layer protocol profile for Interactive Class services. The profile for TMN function sets corresponding to the SMASE for Interactive Class of services may be specified as part of Recommendations defining the information models and services.

 

 


Figure 1/Q.812 – Protocol stack of the upper layer protocol profile
for Interactive Class services for the OSI Paradigm

2.35.3       Upper layer protocol specification for File-oriented Class services

Figure 2 illustrates the protocol stack of the upper layer protocol profile for File-oriented Class services.


 

 


Figure 2/Q.812 – Protocol stack of the upper layer protocol profile for
File-oriented Class services for the OSI Paradigm

2.45.4       Upper layer protocol specification for Directory services

Figure 3 illustrates the protocol stack of the upper layer protocol profile for Directory services.


 

 

 


Figure 3/Q.812 – Protocol stack of the upper layer protocol profile for Directory services in the OSI paradigm

2.55.5       Upper layer protocol specification for store and forward services

The upper layer protocols to be used for store and forward services (e.g. for exchange of EDI formatted information) is for further study.

36       Upper layer protocol specification for Interactive Class services using the OSI paradigm

3.16.1       Transport layer profiles

3.1.16.1.1        Transport layer profile for CLNS1, CLNS2 and CLNS3

The section defines the transport layer profile for use with CLNS1, CLNS2 and CLNS3 as defined in ITU-T Rec. Q.811 [45xx].

3.1.1.16.1.1.1         Services profile

It is mandatory that for the connectionless-mode Network service, the Transport service shall conform to ITU-T Rec. X.214 | ISO/IEC 8072 [41].

3.1.1.26.1.1.2         Protocol profile

Operation of the Transport protocol over the connectionless-mode Network layer Service (CLNS), as described in CCITT Rec. X.213 | ISO/IEC 8348 [6], shall use the elements of ISO/IEC 8073 [42] and Recommendation X.224 [43], Class 4 operation over the CLNS. Provisions in 5.7.4.1.2, 5.7.4.1.3, 5.7.4.1.4, 5.7.4.2.4, 5.7.4.2.6, 5.7.4.2.7, and 5.7.4.2.8 of CONS1 profile Transport protocol also apply here.

3.1.1.36.1.1.3         Class of service

Support of Class 4 operation of ISO/IEC 8073 [42] and Recommendation X.224 [43] is mandatory.

3.1.1.46.1.1.4         Transport layer attributes

Transport layer attributes for Class 4 operation over the Connectionless-mode Network layer Service shall be as shown in Table 1.


 

Table 1/Q.812 – Transport layer attributes
[for use with Connectionless-mode Network layer Service (CLNS)]

 

Value/Range/Option

Default

Maximum TPDU (Octets)

128, 256, 512, 1024
(2048, 4096, 8192 optional)

(128)

TSAP-ID (Note 1)
Class of service
Preferred class
Alternative Class
Expedited Data

Up to 32 octets
4
4
None
Non-use

–
–
–
–
–

Options:

 

 

Security Parameters
Data TPDU numbering (Note 2)
Checksum (Note 3)

Optional
Normal, extended
Use, non-use

–
(Normal)
(Non-use)

Parameters:

 

 

T1 – Retransmission time

0.25-64 seconds (Note 4)

(8)

N – Retransmissions
L – Bound on reference
I – Inactivity time

2-15
1-256 seconds
2-512 seconds

(2)
(32)
(64)

NOTE 1 – Some systems may require TSAP-IDs. However, all systems shall be capable of generating called TSAP‑IDs in CR TPDUs and capable of receiving calling and called TSAP-IDs in received CR and CC TPDUs, respectively.

NOTE 2 – Extended format option shall be implemented. Non-use of this option shall be negotiable. The responder shall honour the initiator’s request whenever possible. Negotiation to other than what has been requested shall only occur under abnormal conditions, for example, severe congestion, as determined by the implementor. Initiators shall be prepared to operate in the mode confirmed by the responder.

NOTE 3 – Use of checksum is required for the CR TPDU. An additional requirement is that all implementations shall support the negotiated "non-use" of the checksum. Initiators shall request and responders shall agree to "non-use" of the checksum.

NOTE 4 – The Transport layer T1 timer value should always be greater than the link layer T1 timer value.

 

 

3.1.26.1.2        Transport layer profile for CONS1, CONS2, CONS3 and CONS5

3.1.2.16.1.2.1         The section defines the transport layer profile for use with CONS1c CONS2, CONS3, CONS4 and CONS5 as defined in ITU-T Rec. Q.811 [45xx].Services profiles

The Protocol Profiles described in this Recommendation provide the Connection-mode Transport Service (COTS) to the OSI upper layers that is defined in ITU-T Rec. X.214 | ISO/IEC 8072 [41].

3.1.2.1.16.1.2.1.1          Splitting

Responders may refuse Network connections which could impose an unnecessary restriction on the ability to establish outgoing Network connections. To prevent repeated ineffective attempts during splitting, initiators shall refrain from immediately requesting additional Network connections for a Transport connection after a Network connection has been refused. The time delay before requesting additional Network connections is for further study.

3.1.2.1.26.1.2.1.2          Quality of Service negotiation

Quality of Service negotiation is outside the scope of this Recommendation. If Quality of Service negotiation is not supported, receipt of the parameters "throughput", "residual error rate", "priority", and "transit delay" in the CR and CC TPDUs shall be ignored.

3.1.2.1.36.1.2.1.3          TPDU size negotiation

Interoperability is achieved by having the initiator propose a TPDU size from the set specified in Table 2 and by the responder selecting the most appropriate TPDU size between 128 and the proposed TPDU size. The rules for negotiation of the size of the TPDU to be used in a given instance of communication are specified in ISO/IEC 8073 [42] and Recommendation X.224 [43].

The choice of TPDU size is a local implementation issue.

3.1.2.1.46.1.2.1.4          Negotiation of protection

Negotiation of protection is outside the scope of this Recommendation. If negotiation of protection is not supported, receipt of the protection parameters in any CR TPDU and any CC TPDU shall be ignored.

3.1.2.26.1.2.2         Protocol profile

It is mandatory that for the connection-mode Network service, the Transport protocol shall conform to Recommendation X.224 [43] and to those provisions of ISO/IEC 8073 [42] and Recommendation X.224 [43] that apply to the use of the Connection-Mode Network layer Service (CONS).

3.1.2.2.16.1.2.2.1          Class of service

Classes 4, 2, and 0 shall be supported as shown in Table 2 in countries requiring the features of Transport layer Class 4. The conformance rules of Recommendation X.224 [43] require that Classes 0 and 2 be supported as well when Class 4 is specified. For existing equipment and in countries not requiring Class 4, support of Class 0 is mandatory and Class 2 is optional.

The default values shall be part of a vendor's offering. That is, unless otherwise specified by the user, the default parameters shall be the initial values supplied. They can be subsequently changed by the user within the specified range.

In addition to the requirements specified in Recommendation X.224 [43], equipment shall meet the following requirement: if a responder receives an alternate class of "none", it shall respond with the preferred class. Rules for responders are specified in Table 3.

User options shall be provided to designate the preferred and alternate classes (see Table 3/X.224 [43]). When all of the classes are supported, the preferred class for connection is Class 4.


 

Table 2/Q.812 – Transport layer attributes
[for Connection-mode Network layer Service (CONS)]

Attribute

Range

Default

Maximum TPDU (octets)

128, 256, 512, 1024
(2048, 4096, 8192 optional)

(128)

Class of Service
Preferred Class
Alternative Class
Expedited Data

4, 2, 0
4, 2, 0
4, 2, 0, none
Non-use


(4)
(None)

Options for Class 4
Data TPDU numbering (Note 2)


Normal, extended


(Normal)

Options for Class 2
Data TPDU numbering (Note 2)


Normal, extended


(Normal)

Flow control

Explicit

 

Parameters for Class 4
T1 – Retransmission time


0.25-64 seconds (Note 4)


(8)

N – Retransmissions

L – Bound on reference

I – Inactivity time

2 (other values for further study)

1-256 seconds

2-512 seconds



(32)

(64)

NOTE 1 – Some systems may require TSAP-IDs. However, all systems shall be capable of generating called TSAP-IDs in CR TPDUs and capable of receiving calling and called TSAP-IDs in received CR and CC TPDUs, respectively.

NOTE 2 – Extended format option shall be implemented. Non-use of this option shall be negotiable. The responder shall honour the initiator’s request whenever possible. Negotiation to other than what has been requested shall only occur under abnormal conditions, for example, severe congestion, as determined by the implementor. Initiators shall be prepared to operate in the mode confirmed by the responder.

NOTE 3 – Use of the checksum is required for the CR TPDU. An additional requirement is that all implementations shall support the negotiated "non-use" of the checksum. Initiators shall request and responders shall agree to "non-use" of the checksum.

NOTE 4 – The Transport layer T1 timer should always be greater than the link layer T1 timer.

 

Table 3/Q.812 – Valid response corresponding to preferred and any alternative class proposed in the CR TPDU

Preferred class

Alternative class

 

0

2

4

None

0

Not valid

Not valid

Not valid

Class 0

2

Classes 0, 2

Class 2

Not valid

Class 2

4

Classes 0, 2, 4

Classes 2 or 4

Class 4

Classes 2 or 4

3.1.2.2.26.1.2.2.2          Protocol identification

For the purpose of Transport layer protocol identification, the procedures specified in Annex B of ISO/IEC 8073 [42] and Recommendation X.224 [43] and ISO/IEC 11570 [55] shall be used. The
conventions for protocol identification given in ISO/IEC TR 9577 [21] should be followed. Selection of codes not specified in the referenced standards is for further study. The absence of call user data in a call request or call accept packet of Recommendation X.25 [12] and ISO/IEC 8208 [16] indicates the operation of the Transport layer procedures of ISO/IEC 8073 [42] and Recommendation X.224 [43].

3.1.2.2.36.1.2.2.3          Attributes

Attributes of the Transport layer for use with CONS are summarized in Table 2. The selection of values within required and optional ranges depends on characteristics of the messages.

NOTE – The need to support high priority messages that require low transit delay on a given Transport connection must be reflected in the Quality of Service parameters requested when the Transport connection is established. A properly implemented Transport entity should not multiplex high priority messages that require low transit delay if it cannot provide the requested Quality of Service. Since this is an implementation detail, it is not subject to standardization.

3.1.2.2.46.1.2.2.4          User data in connection request and connection confirm TPDUs

User data in the connection request and connection confirm TPDUs are optional in Recommendation X.224 [43]. No Transport service user shall send it: all protocol implementations shall be prepared to receive it and all implementations may ignore it, i.e. it shall not cause a disconnect.

3.1.2.2.56.1.2.2.5          Class 0 Error-TPDU

When Transport Class 0 has been negotiated, the Error Transport Protocol Data Unit (ER-TPDU) may be used at any time and upon receipt requires that the recipient disconnect the network connection and, by extension, the Transport connection.

3.1.2.2.66.1.2.2.6          Unknown CR TPDU parameters

An unknown parameter in any received CR TPDU shall be ignored.

When all of the classes are supported, the preferred class, when initiating a CR TPDU, shall be Class 4.

If a responder receives an alternative class of "none", implicit negotiation is enforced.

3.1.2.2.76.1.2.2.7          Invalid values of known CR TPDU

Known parameters with valid lengths but with invalid values in a CR TPDU shall be handled as depicted in Table 4.

Table 4/Q.812 – TPDU parameters

Parameter

Action

TSAP id
TPDU size
Version
Checksum
Alternate protocol classes

Send DR TPDU
Ignore parameter, use default
Ignore parameter, use default
Discard CR TPDU
Protocol error

3.1.2.2.86.1.2.2.8          Additional options parameter

Unrecognized or not applicable bits of the "additional options" shall be ignored.


3.1.2.2.96.1.2.2.9          Network Connection Management Subprotocol (NCMS)

The use of the NCMS, as specified in Annex B of ISO/IEC 8073 [42] and Recommendation X.224 [43], is optional. Implementations that support the NCMS shall be able to communicate with implementations that do not support the NCMS.

3.1.36.1.3        Transport Layer ProtocolISO TP0/TCP/IP Profile For use with the IP service.

This section defines the transport protocol profile for use with OSI paradigm when the lower layer IP service defined in ITU-T Recommendation Q.811 [45x] is used.

-        For the top of Layer 4 – STD0035 "ISO Transport Service on top of the TCP (Version: 3)." May 1987. (Includes RFC2126). This document defines how to provide the TP0, ISO Transport Services over TCP.

-        For the bottom of Layer 4 – STD0007 "Transmission Control Protocol", J. September 1981. (Includes RFC0793.)

It should be noted that STD0035 (RFC2126) implements the ISO TP0 protocol on top of TCP/IP, not on top of the ISO/CCITT Network protocol. Since the Transport class 0 protocol is used over the TCP/IP connection, it achieves identical functionality as Transport Class 4. Hence, ISO/CCITT higher level layers (all session, presentation, and application entities) can operate fully without knowledge of the fact that they are running on a TCP/IP internetwork.

3.26.2       Session layer

3.2.16.2.1        Service definition

The session layer conforms to the service definition in ITU-T Rec. X.215 | ISO/IEC 8326.

The default values shall be part of a vendor's offering. That is, unless otherwise specified by the user, the default parameters shall be the initial values supplied. They can be subsequently changed by the user within the specified range.

A conflict in the code values for subsequent number and flow control confirmation exists between ISO and ITU-T. The conflict is expected to be resolved as specified in ISO/IEC 8073 [4].

3.2.1.16.2.1.1         Functional units

Two session layer Functional Units (FUs) are required in this Recommendation:

1)          Kernel;

2)          Duplex.

3.2.26.2.2        Protocol specification

The session layer conforms to the protocol definition in ITU-T Rec. X.225 | ISO/IEC 8327-1 [5]. The specific options and parameter values that shall be supported for Telecommunications Systems Management application are specified in ISO/IEC ISP 11183-1 [6].

3.2.2.16.2.2.1         User data

The maximum length of the session user data shall be 10 240 octets. This restriction implies that the Overflow Accept and Connect Data Overflow SPDUs are not required to be supported. "Session-selector" parameter values shall have a maximum length of 16 octets.

3.36.3              Presentation layer

3.3.16.3.1        Service definition

It is mandatory that the presentation layer conform to the services specified in ITU-T Rec. X.216 | ISO/IEC 8822 [7].

3.3.1.16.3.1.1         Functional units

One presentation layer Functional Unit (FU) is required in this Recommendation:

–           Kernel.

3.3.26.3.2        Protocol specification

It is mandatory that the presentation layer conform to the protocols specified in ITU-T Rec. X.226 | ISO/IEC 8823-1 [8] (normal mode). The specific options and parameter values that shall be supported for Telecommunications system Management application are specified in ISO/IEC ISP 11183-1 [6].

3.3.36.3.3        Encoding rules for transfer syntax

The encoding rules defined in CCITT Rec. X.209 and ISO/IEC 8825 [9] shall be applied to derive the transfer syntax for the Application Protocol Data Units (APDUs). The ASN.1 [10] to [13] OBJECT IDENTIFIER [joint-iso-itu-t asn1 (1) basic-encoding (1)] shall be used as the value for the transfer syntax name. The maximum value of an ASN.1 basic encoding tag that needs to be handled for conformance to this Recommendation is 16 383. This is the largest unsigned integer that can be represented in 14 bits. Hence the identifier octets shall consist of an initial octet and up to two more octets, thus occupying a maximum of three octets. Also, the largest number of octets in the "contents octets" component of an ASN.1 data value encoding that needs to be handled for conformance to this Recommendation is 4,294,967,295. This is the largest unsigned integer that can be represented in 32 bits. Hence in the "long form" encoding, the length octets shall consist of an initial octet and up to four more octets, thus occupying a maximum of five octets. (Note that this restriction does not apply to "indefinite length" encodings.)

3.46.4              Application layer

The application layer protocol data unit presentation is described by using Abstract Syntax Notation One (ASN.1), as defined in CCITT Rec. X.208 | ISO/IEC 8824 [14].

3.4.16.4.1        Application layer architecture

It is mandatory that the application layer conforms to the architecture for the application layer outlined in ISO/IEC 9545 [15].

The concepts of Application Entity (AE), Application Entity Invocation, Application Service Object (ASO), Control Function (CF) and Application Context will be used to describe the relationship between ROSE, ACSE, CMISE, SMASE.

3.4.26.4.2        Association control service element

3.4.2.16.4.2.1         Service definition

The ACSE service description is detailed in ITU-T Rec. X.217 | ISO/IEC 8649 [16]. All of the defined ACSE services (see Table 1) are mandatory. The value of mode parameter of A‑ASSOCIATE shall be "normal".

3.4.2.26.4.2.2         Protocol specification

The protocol specification for ACSE shall follow ITU-T Rec. X.227 | ISO/IEC 8650-1 [17]. All five APDUs (see Table 1) specified in the standard are mandatory. The specific options and parameter values that shall be supported for Interactive Class Telecommunications Systems Management application are specified in ISO/IEC ISP 11183-1 [6].


 

Table 1/Q.812 – ACSE services and associated APDUs

ACSE Service

Associated APDUs

Related P-Service

A-ASSOCIATE

A-RELEASE

A-ABORT

A-P-ABORT

AARQ, AARE

RLRQ, RLRE

ABRT

(None)

P-CONNECT

P-RELEASE

P-U-ABORT

P-P-ABORT

3.4.2.36.4.2.3         Use of the SACF for association control

The CF is defined to control the interactions among ASEs and/or ASO within the containing ASO in ISO/IEC 9545 [15] with DAM 1.

Thus it controls the association establishment, release and abort in respect to the rules defined in the Application Context available for the association.

Then it allows the joint use of several ASEs on the same association.

3.4.2.46.4.2.4         Abstract Syntax Name

The ACSE abstract syntax name has the ASN.1 type OBJECT IDENTIFIER. The following value shall be used to identify the ACSE abstract-syntax-definition:

 

{

joint-iso-itu-t association-control (2)
abstract-syntax (1) apdu's (0) version (1)

 

}

3.4.36.4.3        Remote operations

3.4.3.16.4.3.1         Service definition

The Remote Operations Service Element (ROSE) shall be a mandatory service element. The ROSE service description is detailed in CCITT Rec. X.219 and ISO/IEC 9072-1 [18]. All of the defined ROSE services (see Table 2) are mandatory.

3.4.3.26.4.3.2         Protocol specification

The protocol specification for ROSE shall follow CCITT Rec. X.229 and ISO/IEC 9072-2 [19]. All four APDUs specified in the standard (see Table 2) are mandatory. In addition, the ability to support correct origination and reception of the linked-id protocol element is required.

The requirement specified in Table 2 implies association Class 3 in ROSE.

Table 2/Q.812 – ROSE services and associated APDUs

ROSE Service

Associate APDUs

Relate Underlying Service

RO-INVOKE

ROIV

P-DATA

RO-RESULT

RORS

P-DATA

RO-ERROR

RORE

P-DATA

RO-REJECT-U

RORJ

P-DATA

RO-REJECT-P

RORJ

P-DATA

3.4.46.4.4        Common management information

Network management applications shall use the Common Management Information Service Element (CMISE).

3.4.4.16.4.4.1         Service definition

The CMISE service description is detailed in CCITT Rec. X.710 and ISO/IEC 9595 [20]. The CMISE services are listed in Table 3.

Multiple object selection, filter, multiple reply and cancel get functional units as defined in CCITT Rec. X.710 and ISO/IEC 9595 [20] are optional. Their use is application dependent. The negotiation during association establishment to use or not use the functional units shall be supported.

Support of the extended service functional unit defined in CCITT Rec. X.710 and ISO/IEC 9595 [20] is not required for conformance to this Recommendation and negotiation shall be supported, at association establishment, for its non-use.

Table 3/Q.812 – CMISE services

Service

Type

M-EVENT-REPORT

Confirmed/non-confirmed

M-GET

Confirmed

M-SET

Confirmed/non-confirmed

M-ACTION

Confirmed/non-confirmed

M-CREATE

Confirmed

M-DELETE

Confirmed

M-CANCEL-GET

Confirmed

3.4.4.26.4.4.2         Protocol specification

Implementations shall support those operations defined in CCITT Rec. X.711 and ISO/IEC 9596-1 [21], that are required by specific applications. All mandatory parameters defined in CCITT Rec. X.711 and ISO/IEC 9596-1 [21] for the required operations are mandatory parameters for this Recommendation. The specific options and parameter values that shall be supported are specified in ISO ISP 11183-3 [22] for basic Telecommunications Systems Management and in ISO/IEC ISP 11183-2 [23], for enhanced Telecommunications Systems Management.

3.4.4.36.4.4.3         Abstract Syntax

The abstract syntax name for CMISE is {joint-iso-ccitt ms(9) cmip(1) abstract syntax(4)}.

3.56.5       Security support for interactive applications

For X-Interface, the support for authentication and access control security services are mandatory, For Q, the support for these services are optional. The authentication service shall be supported using Authentication Functional Unit specified in ACSE. The actual mechanism(s) to be used for the X-Interface is for further study.

The access control service shall be supported by using the access control parameter defined in CMIP operations. The syntax for this parameter depends on the specific mechanism and is for further study. When specific mechanisms are defined, an additional abstract syntax defining the syntax of the access control shall be included in the Definition Context Set (DCS) for the Presentation Protocol.

47       Upper layer protocol specification for File-oriented Class functions using the OSI paradigm

The profiles for each layer are the same as described in clause 3; this clause only documents the differences required for FTAM support.

4.17.1       Session layer

4.1.17.1.1        Service profile

4.1.1.17.1.1.1         Functional units

Four session layer Functional Units (FUs) are required in this Recommendation:

1)          Kernel;

2)          Duplex;

3)          Minor Synchronize;

4)          Resynchronize.

4.1.27.1.2        Protocol profile

The specific options and parameter values that shall be supported for file transfer service are specified in ISO/IEC ISP 10607-1 [24].

4.27.2       Presentation layer

4.2.17.2.1        Service definition

It is mandatory that the presentation layer conform to the services specified in ITU-T Rec. X.216 | ISO/IEC 8822 [7].

4.2.1.17.2.1.1         Functional units

One presentation layer Functional Unit (FU) is required in this Recommendation:

–           Kernel.

4.2.27.2.2        Protocol specification

It is mandatory that the presentation layer conform to the protocols specified in ITU-T Rec. X.226 | ISO/IEC 8823-1 [8] (normal mode). The specific options and parameter values that shall be supported for Telecommunications system Management application are specified in ISO/IEC ISP 11183-1 [6].

4.2.37.2.3        Encoding rules for transfer syntax

The encoding rules defined in CCITT Rec. X.209 and ISO/IEC 8825 [9] shall be applied to derive the transfer syntax for the Application Protocol Data Units (APDUs). The ASN.1 OBJECT IDENTIFIER [joint-iso-itu-t asn1 (1) basic-encoding (1)] shall be used as the value for the transfer syntax name. The maximum value of an ASN.1 basic encoding tag that needs to be handled for conformance to this Recommendation is 16 383. This is the largest unsigned integer that can be represented in 14 bits. Hence the identifier octets shall consist of an initial octet and up to two more octets, thus occupying a maximum of three octets. Also, the largest number of octets in the "contents octets" component of an ASN.1 data value encoding that needs to be handled for conformance to this Recommendation is 4,294,967,295. This is the largest unsigned integer that can be represented in 32 bits. Hence in the "long form" encoding, the length octets shall consist of an initial octet and up to four more octets, thus occupying a maximum of five octets. (Note that this restriction does not apply to "indefinite length" encodings.)

4.37.3       Application layer profile

4.3.17.3.1        Application layer architecture

The description of ACSE and FTAM as part of the application layer architecture is to be provided.

4.3.27.3.2        File transfer, access and management

4.3.2.17.3.2.1         Service profile

The mandatory file service class is file transfer class.

In this class the following functional units are mandatory:

–           the kernel functional unit;

–           both the read and write functional units;

–           the limited file management functional unit;

–           the grouping functional unit;

–           and, in the internal file service, the recovery functional unit and optionally the restart functional unit.

4.3.2.27.3.2.2         Protocol profile

The functional units of the file protocol are equivalent to the functional units of the supported service described above.

The functional units retained and their PDUs associated are listed in Table 4.

This file protocol assumes the session services described in 6.1.1.14.1.1.1 with the following details:

–           the recovery or restart functional unit implicates the use of minor synchronize session service;

–           the restart functional unit implicates in addition to minor synchronize session service the resynchronize session service.

Table 4/Q.812 – FTAM functional units and PDUs associated

Name

Functional units

F-INITIALIZE request
F-INITIALIZE response
F-TERMINATE request
F-TERMINATE response
F-P-ABORT request
F-U-ABORT request
F-SELECT request
F-SELECT response
F-DESELECT request
F-DESELECT response
F-CREATE request
F-CREATE response
F-DELETE request
F-DELETE response
F-READ-ATTRIB request
F-READ-ATTRIB response

Kernel
Kernel
Kernel
Kernel
Kernel
Kernel
Kernel
Kernel
Kernel
Kernel
Limited file management
Limited file management
Limited file management
Limited file management
Limited file management
Limited file management

F-OPEN request
F-OPEN response
F-CLOSE request
F-CLOSE response
F-READ request
F-WRITE request

Read, write
Read, write
Read, write
Read, write
Read
Write

F-DATA-END request
F-TRANSFER-END request
F-TRANSFER-END response
F-CANCEL request
F-CANCEL response

Read, write
Read, write
Read, write
Read, write
Read, write

 

Table 4/Q.812 – FTAM functional units and PDUs associated (concluded)

Name

Functional units

F-BEGIN-GROUP request
F-BEGIN-GROUP response
F-END-GROUP request
F-END-GROUP response
F-RECOVER request
F-RECOVER response

Grouping
Grouping
Grouping
Grouping
Recovery
Recovery

F-RESTART request
F-RESTART response

Restart
Restart

4.3.2.37.3.2.3         Abstract Syntax

The abstract syntax names for FTAM are:

            

             {iso standard 8571 abstract syntax(2) ftam-fadu(2)}

             {iso standard 8571 abstract syntax(2) ftam-pci(1)}

             {iso standard 8571 abstract syntax(2) unstructured-text(3)}

             {iso standard 8571 abstract syntax(2) unstructured-binary(4)}

4.3.2.47.3.2.4         Support of document types

The nature of the file structures to be transferred involves the use of the suitable document types.

Three types of file structures are retained:

–           unstructured binary files;

–           unstructured text files;

–           sequentially ordered files (these files are made of a sequence of records without any possibility of having direct access to a given record, each record is made of fields of different types).

So three document types at least are mandatory:

–           ISO FTAM unstructured text (FTAM.1);

–           ISO FTAM unstructured binary (FTAM.3);

–           NBS sequential file (NBS-6).

FTAM.1 and FTAM.3 are allowed by FTAM hierarchical file model defined in ISO 8571-2 [26] as constrained by the unstructured constraint set.

NBS-6 is allowed by FTAM hierarchical file model defined in ISO 8571-2 [26] as constrained by the sequential flat constraint set.

4.47.4       Security Support for FTAM Services

For X-Interface, the support for authentication service is mandatory. For Q, the support for these services are optional. The authentication service shall be supported using Authentication Functional Unit specified in ACSE. The actual mechanism(s) to be used for the X-Interface is for further study.

Security support for FTAM services in TMN is for further study.

58       Upper layer protocol specification for Directory services using the OSI paradigm

The profiles for each layer are the same as described in clause 3; this clause only documents the differences required directory support.

5.18.1       Session layer

5.1.18.1.1        Service definition

This layer conforms to the service definition in ITU-T Rec. X.215 | ISO/IEC 8326.

5.1.1.18.1.1.1         Functional units

Two session layer FUs are required in this Recommendation:

a)          Kernel;

b)          Duplex.

5.1.28.1.2        Protocol specification

The session layer conforms to the protocol definition in ITU-T Rec. X.225 | ISO/IEC 8327-1 [5].

5.1.38.1.3        User Data

DUAs shall be capable of sending request APDUs of any size up to 32 767 (32k-1) octets in length. DSAs shall be capable of accepting and processing operation request APDUs of any size up to 32 767 octets in length. DSAs shall be capable of sending response APDUs of any size up to 262 143 (256k-1) octets in length. DSAs shall be capable of accepting and processing response APDUs of any size up to 262 143 octets in length and shall be capable of sending request APDUs of any size up to 32 767 octets in length.

5.28.2       Presentation layer

5.2.18.2.1        Service definition

The presentation-service is defined in ITU-T Rec. X.216 | ISO/IEC 8822 [7].

The ACSE is the sole user of the P-CONNECT, P-RELEASE, P-U-ABORT and P-P-ABORT services of the presentation-service.

The ROSE is the sole user of the P-DATA service of the presentation service.

Presentation default context, context restoration, and context management are not used.

5.2.28.2.2        Protocol specification

It is mandatory that the presentation layer conform to the protocols specified in ITU-T Rec. X.226 | ISO/IEC 8823-1 [8] (normal mode).

5.38.3       Application layer

5.3.18.3.1        Application Layer architecture

It is mandatory that the application layer conforms to the architecture for the application layer outlined in ISO/IEC 9594 [29] to [36].

5.3.28.3.2        Directory protocol Abstract Syntaxes

The ASN.1 type from which the values of the abstract syntaxes are derived is specified using the parameterized types of ROS {DAP-InvokeIDSet | DAP-Invokable | DAP-Returnable | DSP-InvokeIDSet | DSP-Invokable | DSP-Returnable}, Bind { dSABind | directoryBind}, and Unbind {dSAUnbind | directoryUnbind} which are defined in ITU-T Rec. X.880 | ISO/IEC 13712-1 [37].

The DAP abstract syntax is called the directoryAccessAbstractSyntax. The DSP abstract syntax is called the directorySystemAbstractSyntax.

5.3.38.3.3        Directory application contexts

The DAP application context is called the directoryAccessAC. The DSP application context is called the directorySystemAC.

5.3.48.3.4        Association control service element

The abstract-syntax of ACSE, acse-abstract-syntax is required for DAP and DSP.

The ACSE supports the establishment, release and abort of an application-association between a pair of AEs. Associations between a DUA and a DSA may be established only by the DUA. Only the initiator of an established association can release it.

5.3.4.18.3.4.1         Service definition

The ACSE service description is detailed in ITU-T Rec. X.217 | ISO/IEC 8649 [16].

The RO-BIND and RO-UNBIND services are the sole users of the A-ASSOCIATE and A‑RELEASE services of the ACSE. The application-process is the user of the A-ABORT and A‑P‑ABORT services of the ACSE.

5.3.4.28.3.4.2         Protocol specification

The protocol specification for ACSE shall follow ITU-T Rec. X.227 | ISO/IEC 8650-1 [17].

5.3.58.3.5        Remote operations

5.3.5.18.3.5.1         Service definition

ROSE shall be a mandatory service element. The ROSE service description is detailed in ITU-T Rec. X.881 | ISO/IEC 13712-2 [38].

The Directory ASEs are users of the RO-INVOKE, RO-RESULT, RO-ERROR, RO-REJECT-U, and RO-REJECT-P services of the ROSE.

5.3.5.28.3.5.2         Protocol specification

The DAP and DSP are the Directory protocols used to provide communications between a pair of application processes.

5.48.4       Security Support for Directory Services

ITU-T Rec. X.509 | ISO/IEC 9594-8 [36] defines a framework for the provision of authentication services by the Directory to its users. Security support for Directory services in TMN is for further study.

The upper layer protocols to be used for store and forward services (e.g. for exchange of EDI formatted information) is for further study.

This Recommendation specifies partial support for security requirements across the Q and X interfaces. To support security services such as data integrity, confidentiality and non-repudiation and management of security information (such as key management procedures and protocols), the use of Generic Upper Layer Security Recommendations (X.830-Series of Recommendations) will be required. Guidelines for using GULS in applications are specified in Annex A/X.830 [39]. Details for using GULS in both interactive and file transfer classes of TMN applications are for further study.

69       Conformance for the OSI paradigm

Requirements for items not specifically referenced in this Recommendation shall be per ISPs as identified below:

-        Transport:

-        For CLNS1 (see Q.811 [45x]) the transport layer shall conform to ISO/IEC ISP 10608-1 [60y] Subnetwork Type Independent requirements.

-        For CLNS2 (see Q.811 [45x] the transport layer shall conform to ISO/IEC ISP 10608-1 [60y].

-        For CLNS3 (see Q.811 [45x]) the transport layer shall conform to ISO/IEC ISP 10608-1 [60y] Subnetwork Type Independent requirements.

-        For CONS1 (see Q.811 [45x] the transport layer shall conform to ISO/IEC ISP 10609-1 [61z] as modified by Table II.1.

-        For CONS6 the transport layer shall conform to ISO/IEC ISP 10609-1 [61z].

-        For ISO TP0/TCP/IPIP stack (see Q.811) transport layer shall conform to class 0 of RFC 2126.

-        Session, Presentation and ACSE layers for Interactive Class services shall conform to ISO/IEC ISP 11183-1 [6].

-        Session, Presentation and ACSE for File-oriented Class services shall conform to ISO/IEC ISP 10607-1 [24].

-        CMIP utilized in Interactive Class services profile shall conform to ISO/IEC ISP 11183-3 [22] for basic services and to ISO/IEC ISP 11183-2 [23] for enhanced services. Applications may override the APDU size of 10K specified in AOM-12 if larger size is required.

-        FTAM profile shall correspond to ISO/IEC ISP 10607-3 [40] "Simple File Transfer service profile".

710   Protocol profile for CORBA-based services

7.110.1   Scope of CORBA protocol profile

TMN applications specified using IDL shall interoperate according to the provisions of this CORBA protocol profile.

7.210.2   Overview of profile for CORBA-based services

Figure 4 illustrates the protocol stack for the profile for CORBA-based services.

TMN services which have object-oriented interfaces specified using ODP IDL (Recommendation X.920) may be accessed through use of this profile.

 


 

 


Figure 4/Q.812 – GIOP upper layer CORBA-based services protocol stack

To support CSI level 1 and above, the SECIOP protocol must be used within this profile. For support of CSI level 0, CORBA Security SSL Interoperability may be used as an alternative to SECIOP within this profile. Systems which support CORBA security must also support the IIOR profile version 1.1 format.

If application fragmentation is required, then GIOP version 1.1 or later must be used within this profile.

Mappings of GIOP onto transports other than TCP is for further study.

NOTE – GIOP mappings to transport profiles require the specification of an Interoperable Object Reference (IOR) profile format, associated with that transport profile, as well as the specification of how binding services of the transport profile are used.

7.310.3   Service definition

Services which use CORBA must have object-oriented interfaces specified using OMG IDL (Recommendation X.920).

NOTE – CORBA-based systems may use standard programming language bindings to access CORBA objects.

7.410.4   GIOP protocol specification

GIOP versions 1.0, 1.1 and 1.2 are to be implemented as specified in [CORBA GIOP Specification]. All systems which act as CORBA servers must support at least GIOP 1.0.

Servers which support GIOP versions 1.1 or 1.2 must also support processing messages with all previous GIOP versions.

7.510.5   Secure IOP protocol specification

All systems which require use of CORBA security services must support GIOP version 1.1 or later.

All systems which require use of CORBA security must support either the "Secure IOP protocol", or "CORBASecurity SSL Interoperability", as defined in [CORBA Security Service Specification].

7.610.6   IIOP protocol specification

For interoperability, all CORBA systems shall support the IIOP mapping protocol of GIOP onto TCP/IP lower layer services, as specified in [CORBA GIOP Specification].

Servers shall indicate their support of GIOP through publishing Interoperable Object References (IOR) which include an Internet IOR (IIOR) profile with IIOP profile version set to the highest level of GIOP protocol version supported by the system acting as server. The IIOR profile format is as specified in [CORBA GIOP Specification].

7.710.7   TCP/IP protocol profile for use with IIOP

IIOP is designed to be used with TCP/IP-based lower layer protocols.

This subclause defines a protocol profile for use as TMN lower layer protocols for CORBA-based systems using IIOP. This profile is based on the use of Internet protocols defined by the Internet Architecture Board (IAB)Internet Engineering Task Force (IETF). The way these documents can be referenced in this Recommendation is for further study. The protocol stack uses the following:

•            For Layer 4 – STD0007 "Transmission Control Protocol", Postel [J.] September 1981. (Includes RFC0793.)

•            For Layer 3 and below the IP protocol profile specified in ITU-T Recommendation Q.811 [45x] is used.

Other lower layer protocol mappings for GIOP are for further study.

811   Protocol Profile for EDI/EDIFACT Based Services

8.111.1   Scope of EDI/EDIFACT Protocol Profile

TMN applications that have X interface definitions for use at the service management layer shall may interoperate according to the provisions of this protocol profile. This Recommendation defines the profile for The Electronic Communication Interactive Agent (IA) and associated layers of functionality. The protocol for the IA itself is found in ITU-T Recommendation Q.814. The IA peer-to-peer interface will support near real‑time bidirectional data transfer between peer entities.

The overall profile described in this addendum is modelled after the seven-layer open system interconnection (OSI) model, that is, the profile layers herein are described in terms of the transport layer (4), the session layer (5), the presentation layer (6), and the application layer (7).

The IA described herein provides layer five (5) services. The other layers, four, six, and seven, provide functionality that interacts directly or indirectly with the IA. This profile describes the interaction and responsibilities of each of these four layers.

8.211.2   Layer Summary

Refer to Figure 5/Q.812 in the following discussions.

8.311.3   TCP/IP protocol profile for use with IA

IA is designed to be used with TCP/IP-based lower layer protocols.

This subclause defines a protocol profile for use as TMN lower layer protocols for IA. This profile is based on the use of Internet protocols defined by the Internet Architecture Board (IAB). The way these documents can be referenced in this Recommendation is for further study. The protocol stack uses the following:

•            For Layer 4 – STD0007 "Transmission Control Protocol", Postel [J.] September 1981. (Includes RFC0793.)

•            For Layer 3 and below the IP protocol profile specified in ITU-T Recommendation Q.811 [45x] is used.

8.411.4   TLS Protocol Profile for Use With IA

Layer four provides transport layer security, and transport services utilizing the Transmission Control Protocol (TCP) (see above).

The transport mechanism specified by the Interactive Agent (IA) requires an individual TLS session.  This session either may be persistent or may be  to be either established or resumed for each message. The communication is essentially one way, from the client to the server. The IA status message is a mechanism that allows peer entities to exchange errors and other types of flow control information. Specific message codes may be defined by the peer entities outside the scope of this document. TLS provides secure handshake and transfer between peer TLS entities. TLS also provides for data flow integrity, peer entity authentication, and, optionally, privacy.

8.511.5   IA Profile

The IA performs the session layer functionality. The IA supports the exchange of Electronic Data Interchange (EDIFACT/ASC X12 EDI/general string) transactions between peer entities. The IA supports this interchange over Transport Layer Security (TLS). The session layer functions provided by the IA include the establishment, management and closing of communications sessions between peer entities. The IA also performs the conversion of EDIFACT/ASC X12 EDI recipient names to network addresses and manages the transport layerTLS session. At the conclusion of a session, the IA will determine whether to close a session or to suspend it in a state whereby it can be resumed.

The IA Service Agreement interface is defined at the boundary between the IA and its direct user.

The protocol supporting the exchange of IA messages is referred to as the interactive agent transfer protocol (IATP), and is defined in Recommendation Q.814.

8.611.6   Security Module For Whole Message Protection Profile

This Security Module functionality is optional depending on the security needs of the transaction. However, if whole message security services are needed, the procedures of Recommendation Q.815 shall be followed.  Secure messages are transferred between security modules providing both non-repudiation of origin and receipt, and message integrity.

The Security Module generates/validates the appropriate security fields and performs the required encoding/decoding depending on whether it is sending/receiving, respectively.

Message flow between the EDI Translator and the IA may or may not require security services. The case where security enhancements are applied to a message is depicted in Figure 5/Q.812.

The security module is not sensitive to the content of messages coming from the EDI Translator or the IA.

8.711.7   EDI/EDIFACT Translator Protocol

EDI/EDIFACT protocol contains the user application that uses the services of both the Interactive Agent and, optionally, the Security Module.

An EDIFACT/ASC X12 EDI translator/gateway is an application service that provides a combination of data format translations and data interchange functions for electronic transaction message data.

An EDIFACT/ASC X12 EDI translator/gateway exchanges transaction data to and fromwith network management applications via intermediate data formats. It translates this data to and from externally defined EDIFACT/ASC X12 EDI data formats using translation maps.

 

 


 


Figure 5/Q.812

Upper Layer EDI/EDIFACT Based Services Protocol Stack

 

 

912   Protocol profile for the SNMP paradigm

 

 

The SNMP paradigm is shown in Figure 6. Version 3 of the Internet Management Framework is described in [48]. This framework consists of a data definition language [57], definitions of management information, a protocol definition [54], security [52][53] and administration [51]. The protocol is primarily run over UDP [55], but can alternatively be run over TCP [58]. Coexistence with previous versions of SNMP is described in [56].

 

Where SNMP is deployed, Version 3 is the preferred version.  Previous versions of the Internet Management Framework may be secured using IPSec [59]

 

 

[Editor’s Note: Contributions are required for this section]

 

Figure 6/Q.812 Protocol Profile for the SNMP Paradigm

 

         

13       Protocol Profile for the Telecommunications Markup Language (tML) Paradigm          

 

A protocol profile to support use of tML[64] encoded management information is for further study.

 

 

 

 

 

 

 



Appendix I

Guidance on using allomorphic management

(Geneva, 1999)

I.1         Introduction

This appendix seeks to provide guidance to the developers of CMIP managers and agents in the use of allomorphism. Allomorphism is a powerful concept that is of increasing value as TMNs are implemented. Allomorphism can be used to address the issue of how to add new capabilities to existing TMN manager and agent implementations. As requirements evolve and models are extended to satisfy those requirements, software in the managing system that takes advantage of allomorphism can be written in such a way that it does not require to be rewritten until the new features in the model are needed.

This appendix attempts to clarify how to cope with allomorphic behaviour in implementations of both manager and agent systems. It clarifies the description of allomorphism found in Recommendation X.720. In particular, managers must be aware of allomorphism to benefit from it. Even if a manager does not plan to use allomorphism, it should have a minimum ability to interface with agents that do implement allomorphism. For example, the manager must support the allomorphs attribute and have the ability to construct filters using allomorphs versus the actual class in the objectClass attribute.

This appendix discusses the issues related to allomorphism for each CMIP operation from both the manager and agent perspective. It then discusses the issues related to CMIP Notifications, again from both the manager and agent perspective. It then provides some protocol stack and implementation considerations. It concludes by answering some frequently asked questions about allomorphism.

In the following discussion, the phrase "if agent supports allomorphism" is used. This should be equated to "if agent supports allomorphism for a specific instance" because it is possible that an agent may support revisions for some object classes and not others. Strictly speaking, even two instances of a class may be different in the support for allomorphism, however, this is considered as an extreme and rare implementation for this discussion. The same is also true for manager side where a specific release of a manager system may recognize multiple definitions for some basic classes and not for others. The decisions to include the different versions are dictated by business objectives (which are out the scope of this appendix).

I.1.1      Overview

Allomorphism is the ability of a managed object that is an instance of a given managed object class to be managed as a member of one or more other managed object classes. Allomorphism allows instances of one managed object class – referred to as the extended class to represent instances of another managed object class – the allomorphic class.

When an extended class is instantiated, the actual class (see Recommendation X.720) of the object stored in the objectClass attribute is the extended class. It is extended with regard to another managed object class, its compatible managed object class. The actual class is that class of which a managed object is an instance. An allomorphic class of a managed object is a managed object class
other than the managed object's actual class; however it can be managed as an instance of that class. A managed object may be allomorphic to one or more of the compatible classes (i.e. instances of the extended class can be managed as instances of compatible managed object class). In other words the terms "allomorphic class" and "compatible managed object class" can be used as synonyms. When an agent creates a managed object that supports allomorphism, the allomorphicPackage (defined as a Conditional Package in the top class in Recommendation X.721) is included. The package contains the allomorphs attribute. This GET‑Only attribute is set‑valued and contains the object identifiers of the classes that this object can represent (is allomorphic with). The objectClass attribute has a value of the actual class used in creating this instance.

The basic idea behind allomorphism is that the extended class supports all the capabilities of the classes it is allomorphic with. It may also support additional capabilities. The extended class may be a subclass of the classes it is allomorphic with but this is not required. In all respects the extended class behaves as the class it actually is. This may mean that the manager could receive information that is not in the allomorphic class. For example, if the extended class has new attributes, a Get all operation from the manager will return values for these. Dealing with this type of issue requires the manager to be aware that allomorphic management is being used. Recommendation X.726 defined Managed Object Conformance tables for use by both agent and manager implementations. Use of these tables to identify the list of allomorphs if supported is recommended to determine the levels of interoperability.

The various interactions between manager and agents using allomorphic management are discussed in the following clauses. Recommendation X.720 also discusses limited interoperability when compatible rules are not completely satisfied. This appendix addresses only the scenarios where compatible rules defined according to Recommendation X.720 to support allomorphism are met (See 5.2.3.2/X.720).

I.2        CMIP operations

This clause discusses allomorphism in relation to the CMIP Operations, m‑Create, m‑Get, m‑Set, m‑Action, and m‑Delete. No impact of allomorphism on the m‑Cancel‑Get operation has been identified.

I.2.1      Creating managed objects

A managed object is created either by the manager issuing an explicit create request on the interface or by automatic create within the agent system. Each case is discussed below. Careful selection of the naming attribute and structure is required. The naming issues are discussed below in a separate subclause.

I.2.1.1   Explicit creation – Manager role

Case 1: The manager issues a CMIP create request providing in the managed object class a value and a set of attribute values appropriate for that class. The manager supplies the actual name of the new object. The resulting action in the agent is one of those defined in I.2.1.2 Explicit creation – Agent role, cases a, b, c. If the response is as defined in case c, the manager must be able to ignore unknown attributes included as a result of creating an extended class.

Case 2: The manager issues a CMIP create request providing in the managed object class a value and a set of attribute values appropriate for that class. The manager supplies the name binding attribute value. The resulting action in the agent is one of those defined in I.2.1.2 Explicit creation – Agent role, cases a, b, d. If the response is as defined in case d, the manager must be able to ignore unknown attributes included as a result of creating an extended class.


Case 3: The manager specifies the class without a specific name in the instance field or a value for the name binding attribute. The resulting action in the agent is one of those defined in I.2.1.2 Explicit creation – Agent role, cases a, b, e. If the response is as defined in case e, the manager must be able to ignore unknown attributes included as a result of creating an extended class.

Case 4: The manager specifies a class and requests it to be a copy of another object, i.e. with reference object. Depending on the value of the class, any of the above three cases are possible.

I.2.1.2   Explicit creation – Agent role

Case a: Agent recognizes the managed object class in the request and supports it as actual class. In this case the requested managed object class is created and allomorphism is not involved. The create succeeds or fails depending on the conditions associated with the behaviour and the attribute values supplied by the manager. The agent uses either the name supplied in case 1 above or assigns a name (using either the name binding rule in case 2 or internally generated based on the schema definition).

Case b: Agent does not support the requested class either as an actual class supported or as an allomorph. The managed object class provided in the request is not recognized. The create request is rejected with the error "no such object class". This is a normal failure to create an unknown class.

Case c: Agent supports allomorphism and it creates a class that is an extended class with the name supplied by the manager. This assumes the name provided by the manager follows the structure rules (name binding) for the extended class [same or extended superior class, same Relative Distinguished Name (RDN)]. If this condition is not met, then the create will fail. If the create succeeds, the agent responds with the value for the actual class in the managed object class field and all the attributes appropriate for the actual class. The object is created according to the behaviour of the extended class. If the agent system is providing the interoperability (see 5.2.3.1/X.720), the agent includes the attribute allomorphs with the value of the class provided in the create request. If manager system is providing the interoperability (see 5.2.3.2/X.720), the manager may query allomorphs attribute and determine that requested object class is allomorphic to the actual class.

Case d: Agent supports allomorphism and it creates a class that is an extended class with the name binding supplied by the manager. This assumes that the name binding supplied is valid for the extended class. This is often true if the extended class is a subclass and the GDMO includes for name binding "WITH SUBCLASSES" clause. The response when create succeeds is the same as for case c. If the name binding is not valid for the extended class (for example, additional behaviour may be included in a different name binding for the extended class even if the naming attribute and structure are the same) the create will fail. Note that if the manager receives invalid value error for the name binding attribute without further information, this will not help in resolving the problem. From the manager's perspective the request is for a class and the name binding is valid. Because the extended class requires a different behaviour, the agent cannot use that name binding. This is why the recommendation is not to supply the name binding attribute in the create request.

Case e: The agent supports allomorphism and creates a class with an appropriate name selected by the agent (for case 3 of I.2.1.1: Explicit creation – Manager role). The assigned name may or may not be understood by the manager depending on chosen name binding definition. Other information in the response is the same as in case c.

For all the above cases, when the manager does not supply a value for an attribute and a default exists, the value chosen for that attribute is according to the created object class. In cases c, d, and e this can result in the manager receiving values for attributes that exist only in the extended class. The manager may not understand these types and should be able to ignore these types without disrupting the association. Note that the manager may wish to take additional management action to record that it is encountering allomorphic agents (e.g. log information not understood).


In addition to default values of attributes, constraints imposed on initial value, permitted and required values may have differences between the allomorphic class and the extended class. See I.4 for further discussions.

I.2.1.3   Summary

The table below summarizes the various cases for explicit creation discussed from manager role and agent role depending on whether allomorphism is supported or not.

 

Manager role

Agent role with allomorphism

 

Supported

Not supported

Case 1

Cases a, b, c

Cases a, b

Case 2

Cases a, b, d

Cases a, b

Case 3

Cases a, b, e

Cases a, b

Case 4

Cases a, b, c, d, e

Cases a, b

I.2.1.4   Automatic creation – Agent role

The agent may create a managed object internally and inform the managers of the creation by the object creation notification.

Case 1: Assume that the agent has implemented the extended class and allomorphic behaviour. In addition to all the attributes appropriate for the created class, the allomorphs attribute containing all the allomorphic (compatible) object classes is included in the created managed object. The agent sends a create notification for the new object.

In this case, the agent then sends a notification to all the managers using the object creation notification containing the actual class. It includes all the attributes of the class referenced in the managed object class field of the create notification. This includes the allomorphs attribute.

Note that the default values used are consistent with the created class.

Case 2: The agent only implements the extended class and does not exhibit allomorphism for the compatible classes. In this case the object creation notification contains only the information pertaining to the extended class and the allomorphs attribute is not present. For such an environment, it is recommended that the managing system provide for interoperability independent of whether the additional features are required or not. Rejecting the notification will not be useful for a practical TMN environment.

I.2.1.5   Automatic creation – Manager role

The manager receives the object creation notification with the allomorphs attribute and an extended class in the managed object class field. Depending on whether the manager supports allomorphism or not, the cases described in a to d are applicable for case 1 above.

Case a: The manager knows about the extended class and the allomorphs attribute is not needed because the manager does not have to perform allomorphic management. All the characteristics associated with recognizing or not of the attribute identifiers and values are the same when no allomorphism is used.

Case b: The manager does not recognize the managed class value in the notification. If the manager understands the allomorphs attribute identifier, then the manager, before ignoring the notification as unrecognized information, should examine the allomorphs attribute value to determine if it can manage using one of the values in this attribute. This implies that at least one object class value in
the allomorph attribute is recognized by the manager. The manager must ignore all the attributes not recognized as belonging to the allomorphic class.

Case c: The manager does not recognize the managed object class value and it has not implemented the ability to recognize the allomorphs attribute identifier. In this case the manager cannot manage this auto created object. If the creation is sent with a confirmation, an error response may be provided by the manager to say unknown object.

Case d: The manager does not recognize the managed object class value in the notification. The manager understands the allomorphs attribute; however it does not recognize any of the classes in the allomorphs attribute. In this case the result is the same as case c. Managing the auto‑created object by that manager is not possible.

The agent sends a notification using the actual class without the allomorphs attribute (agent does not allomorphism). This corresponds to case a above.

Case e: The manager understands the extended class and the behaviour is as in case a above. The absence of allomorphs attribute is not relevant and the manager can manage the auto created object.

Case f: The manager does not recognize the extended class. The manager will not be able to manage this object, given that the allomorphs attribute is not supported by the agent. This is true irrespective of whether the manager supports allomorphism or not.

I.2.1.6   Summary for AutoCreation

The table below summarizes the relationship of the manager and agent cases.

 

Agent case

Manager case

1

a, b, c, d

2

e, f

I.2.2      Get operation

The Get operation may be issued with an explicit set of attribute identifiers, an empty list or a missing list. The two cases (empty list and missing list are treated the same) are further separated in terms of whether the managed object class in the request is the actual class or allomorphic class for the agent. Note that there is a special object identifier (42) that the manager may use in the request to refer to the actual class of the managed object without having to specify the actual class.

I.2.2.1   Manager role

Case 1: Manager issues a get request with a class that is not the actual class of the object but one of the allomorphs supported by the agent. The list of attribute identifiers included are appropriate for this allomorphic class. The response received is according to one of cases a, b, c below. If interoperability is supported by the manager, then receiving a successful response in case b with a different class will be recognized as a valid response. Otherwise, the manager will reject the response (a ROSE reject and not from CMIP).

Case 2: Manager issues a get request with a class which is either the actual class or the special object identifier which implies the actual class. The list of attributes requested may or may not be appropriate for that class. This is because of either conditionally or by using the special object identifier, the manager may include attributes that are not available for the implemented class. The response received is according to case d below.


Case 3: Manager requests specifying a class, name of a managed object and no attribute list. The response received depends on the value in the class, whether allomorphism is supported by agent and the method of interoperability. The response received is one of cases e, f, g given below. If the response in f or g contains attributes, the manager does not understand, they are ignored by the manager.

Case 4: Manager requests specifying either a class supported by the agent and name of a managed object or the special object identifier discussed above and a name. It does not include the attribute list. The response received is according to case h below. The manager should ignore attributes that are not recognized when the class in the response is different from what the manager recognizes (as a result of using the special object identifier).

I.2.2.2   Agent role

Case a: Agent supports allomorphism and recognizes the name of the managed object. The managed object class in the request matches one of the values in the allomorphs attribute. The agent responds with the values of the attributes requested and the class as in the request may or may not be included. If the class is included, it is recommended that the value of the actual class be used in the response. This approach provides for uniform and consistent response irrespective of single object request or multiple object request using scoping. It is also expected that the managed object class parameter in a CMIP response corresponds to the value of the objectClass attribute.

Case b: Agent does not support allomorphism but recognizes the name of the managed object. The agent may either return an error ("no such object class" or "class instance conflict") or respond with the values of the attribute (agent provided interoperability). The latter behaviour is recommended. The class field may be left empty or populated with the actual class. If both class and name are not recognized, an error response is generated (no such object instance or no such object class).

Case c: Agent does not support allomorphism and does not understand the value of the class or the name in the request. An error "no such object class or no such object instance" is returned.

Case d: The agent recognizes the class and the name irrespective of whether it supports allomorphism or not (this corresponds to case 2 where the manager requests using a class that is a compatible class and not the extended class even though the manager knows about the extended class or the simple case where both the manager and agent knows about only one class). Agent responds with attribute values (includes errors if the attributes requested are not suitable for that class or have not been implemented as a result of conditionality). The class field may be omitted or the actual class is included.

Case e: Agent recognizes the class and name in the request (irrespective of allomorphism is supported or not) and returns all the attribute identifiers and values for that object. Class and name may be omitted in the response.

Case f: Agent supports allomorphism. The value of the class in the request does not match the value of the actual class even though the name corresponds to one of the objects contained in the system. The class corresponds to a value in the allomorphs attribute. If the agent