1、I INTERNATIONAL TELECOMMUNICATION UNION ITU-T TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU SERIES Q: SWITCHING AND SIGNALLING Q3 interface Q.816 (O1 /zoo1 ) CORBA-based TMN services ITU-T Recommendation Q.816 (Formerly CCIlT Recommendation) ITU-T Q-SERIES RECOMMENDATIONS SWITCHING AND SIGNALLING
2、SIGNALLING IN THE INTERNATIONAL MANUAL SERVICE INTERNATIONAL AUTOMATIC AND SEMI- AUTOMATIC WORKING FUNCTIONS AND INFORMATION FLOWS FOR SERVICES IN THE ISDN SPECIFICATIONS OF SIGNALLING SYSTEMS No. 4 AND No. 5 SPECIFICATIONS OF SIGNALLING SYSTEM No. 6 SPECIFICATIONS OF SIGNALLING SYSTEM R1 SPECIFICAT
3、IONS OF SIGNALLING SYSTEM R2 DIGITAL EXCHANGES INTERWORKING OF SIGNALLING SYSTEMS CLAUSES APPLICABLE TO ITU-T STANDARD SYSTEMS Q.1-Q.3 Q.4-Q.59 Q. 60-4.99 Q. 100-Q. 119 Q.120-Q.249 4.250-4.309 4.3 10-4.399 4.400-4.499 Q.500-Q.599 0.600-0.699 . SPECIFICATIONS OF SIGNALLING - SYSTEM - - _ _I No. - 7 -
4、 - - - I - I Q.700-Q. 799 DIGIT SUBSCRIBER SIGNALLING SYSTEM-NO. i Q.%IQ. profiling CORBA services for use by the telecommunications industry; easing the definition of new services for TMN, reusing the semantics of the existing rich set of models; and - harmonizing the modeling approach across group
5、s using a single source similar to ITU-T X.720, ITU-T X.721 and ITU-T X.722 for CMIP. - - ITU-T Q.816 (01/2001) 1 Re-using a common framework and generic information model for a variety of network technologies and network management applications will speed the introduction of new network services wh
6、ile keeping network management system development costs down. The telecommunications industry has invested a great deal of time and energy in the development of information models for the CMIP network management protocol. A primary goal of this framework is the reuse of these information models by e
7、nabling their translation to CORBA Interface Definition Language (IDL) with little change in semantics (see ITU-T X.780). As a result, initial IDL information models are expected to be derived from CMIP models. In addition to taking advantage of CMIP information models, another purpose of the framew
8、ork is to take advantage of CORBA. The framework leverages the functions defined in the CORBA specifications, including a set of Common Object Services. Also, the framework tries to reuse CORBA approaches and design patterns wherever they fit. Finally, while re-using existing models is important, it
9、 is equally important that the framework support the development of new models. This framework does not require a GDMO model to be developed prior to the development of an IDL model. In fact, developing a new IDL information model for use within this framework is straightforward and guidelines for d
10、oing so are provided. 1.2 Application As CORBA is introduced in TMN, different scenarios are possible that range from the use of gateways performing translations between systems using different network management protocols to cases where CORBA is natively supported by the communicating systems. The
11、application of this framework is intended for scenarios where both the managed system and the managing system provide CORBA interfaces. The framework does not address other interworking scenarios requiring “gateway“ systems where protocol and information model conversions are necessary for achieving
12、 interoperability. In particular, this fiamework is not specifically designed to support the construction of gateways between CORBA and CMIP network management applications even though the semantics of the existing models are retained by this framework. A management system, however, might have to su
13、pport multiple protocols, to interwork in different environments. A gateway approach has already been developed and standardized by the Joint Inter-Domain Management (JIDM) group. This gateway approach provides a one-to-one mapping of all constructs and capabilities available with CMIP and GDMO. How
14、ever, many of the CORBA services and capabilities are not reused by this approach because the problem solved is to facilitate interworking with systems that have been deployed using CMIP. In contrast, the problem domain for applying this framework is to support standards-based native COMA network ma
15、nagement interfaces. Such an approach takes advantage of the benefits offered by CORBA as a technology used by multiple industries. ITU-T X.780 13 accompanies this Recommendation and defines object modeling guidelines, superclasses for all managed objects and managed object factories for use with th
16、is framework, and a standard set of notifications. Together, UT-T X.780 and this Recommendation define a framework for CORBA-based TMN interfaces. Also, ITU-T M.3120 provides a CORBA IDL version of the generic network information model originally defined in ITU-T M.3 100. The IDL version follows the
17、 object modeling guidelines in ITU-T X.780 and is designed to fit with the services defined here. 2 ITU-T Q.816 (01/2001) 1.3 Recommendation Roadmap This Recommentation has the following structure: Clause 1 Clause 2 Clause 3 Clause 4 Clause 5 Clause 6 Clause 7 Clause 8 Annex A Appendix I Appendix II
18、 Appendix III Introduction, Recommendation roadmap, updates, and list of issues References Definitions of terms and abbreviations used throughout the rest of the Recommendation Requirements for the TMN CORBA-based services. These are the design goals the services must meet CORBA ORB and Service vers
19、ion requirements. Also provided is an overview of the services Requirements on the use of CORBA Common Object Services for network management interfaces Definition of TMN-specific support services. IDL interfaces for the support services are defined in Annex A Compliance and conformance guidelines T
20、MN-specific support service IDL Interworking Scenarios Between Models Using ITU Framework and ADSUATMF Compliant Models Filtering native and translated structured events Bibliography 1.4 Recommendation Conventions A few conventions are followed in this Recommendation to make the reader aware of the
21、purpose of the text, While most of the Recommendation is normative, paragraphs succinctly stating mandatory requirements to be met by a management system (managing andor managed) are preceded by a boldface “R“ enclosed in parentheses, followed by a short name indicating the subject of the requiremen
22、t, and a number. For example: (R) EXAMPLE-1 An example mandatory requirement. Requirements that may be optionally implemented by a management system are preceded by an “O“ instead of an “R.“ For example: (O) OPTION-1 An example optional requirement. The requirement statements are used to create comp
23、liance and conformance profiles. Many examples of CORBA IDL are included in this Recommendation, and IDL specifying the TMN specific services, and supporting data types, included in a normative annex. The IDL is written in a 9-point courier typeface: / Example IDL interface foo 1; void operation1 O;
24、 ITU-T 4.816 (01/2001) 3 Instructions for extracting the IDL from an electronic version of this Recommendation and compiling it are presented in the next clause. 1.5 Compiling the IDL An advantage of using IDL to specify network management interfaces is that IDL can be “compiled“ into programming co
25、de by tools that accompany an ORB. This actually automates the development of some of the code necessary to enable network management applications to interoperate. This Recommendation has one annex that contains code that implementers will want to extract and compile. Annex A is normative and should
26、 be used by developers implementing systems that conform with this standard. The IDL in this Recommendation has been checked with two compilers to ensure its correctness. A compiler supporting the CORBA version specified in 5.2 must be used. Annex A has been formatted to make it simple to cut and pa
27、ste it into a plain text file that may then be compiled. Below are tips on how to do this. 1) Cutting and pasting seems to work better from the Microsoft Word version of this Recommendation. Cutting and pasting from the Adobe Acrobat file format seems to include page headers and footers, which canno
28、t be compiled. All of Annex A, beginning with the line I/* This IDL code .“ through the end should be stored in a file named “itut-q816.idl“ in a directory where it will be found by the IDL compiler. The headings embedded in Annex A need not be removed. They have been encapsulated in IDL comments an
29、d will be ignored by the compiler. Comments that begin with the special sequence “/*“ are recognized by compilers that convert IDL to IML. These comments often have special formatting instructions for these compilers. Those that will be working with the IDL may want to generate HTML as the resulting
30、 HTML files have links that make for quick navigation through the files. Annex A has been formatted with tab spaces at 8-space intervals and hard line feeds that should enable almost any text editor to work with the text. 2) 3) 4) 5) 2 References The following ITU-T Recommendations and other referen
31、ces 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 in
32、vestigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published. i 2 3 4 5 6 7 ITU-T X.780 (2001), Guidelinesfor defining CORBA managed objects. OMG Document formaV1999-
33、 10-07, The Common Object Request Broker: Architecture and Specification, Revision 2.3.1. OMG Document formaV2000- 11 -1, Interoperable Naming Service Specification. OMG Document formaV2000-06-20, Notification Service Specification, Version 1 .O. OMG Document fomaV00-01-04, Telecom Log Service Speci
34、fication, Version 1 .O. OMG Document formaV2000-06-25, Security Services Specification, Version 1.5. OMG Document formall2000-06-28, Transaction Service Specification, Version 1.1. 4 ITU-T Q.816 (01/2001) OMG Document formaV2000-10-58, CORBA Messaging. OMG Document formaY2000-08-01, Interworking bet
35、ween CORBA and TMN Systems Specification. IETF RFC 2246 (1999), The TLS Protocol Version 1 .O. IEEE/ANSI Std 1003.2- 1992, Information Technology - Portable Operating System Zntegace (POSZX) Part 2: Shell and Utilities. IETF RFC 2253 (1997), Lightweight Directory Access Protocol (v3): UTF-8 String R
36、epresentation of Distinguished Names. ETSI TS 132 106-3 (2000), Universal Mobile Telecommunications System (UMTS), Telecommunication Management; Configuration Management; Pari 3: Notification Integration Reference Point: CORBA solution set version 1.1 (3G TS 32 106-3 Release ITU-T X.701 (1997), Info
37、rmation technology - Open Systems Interconnection - Systems management overview. ITU-T X.703 (1997), Information technology - Open Distributed Management Architecture. 1999). Definitions and abbreviations Definitions from ITU-T X.701 The following terms used in this Recommendation are defined in ITU
38、-T X.701: - managed object class; - manager; - agent. 3.2 Definitions from ITU-T X.703 The following term used in this Recommendation is defined in ITU-T X.703: - notification. 3.3 Additional definitions 3.3.1 managing system to receive notifications from that managed system. NOTE - There are two mo
39、dels for event channel delivery of notifications (see ITU-T X.703): event channel: a support object in a managed system with one or more interfaces allowing a o In the push model of event delivery, the managing system uses one or more event channel interface In the pull model of event delivery, the
40、managing system uses one or more event channel interface instances to register one or more managing system interface references that may be used by the channel to invoke event push operations. references to invoke operations which return notification information. o 3.4 Abbreviations This Recommendat
41、ion uses the following abbreviations: AMI Asynchronous Messaging Invocation ITU-T Q.816 (01/2001) 5 API ASN. 1 ATM AVA CMIP CORBA cos DN EMS FIFO GDMO GIOP HTML ID IDL IEEE IETF IIOP IOR ITU-T JIDM MO MOO NE NMS OAM a a Information model transparency. Common usage of CODA common object services; Thi
42、s clause elaborates on these three goals. 4.1.1 Application interoperability A key goal of the TMN architecture, and in particular the information architecture, is to promote a standard framework for providing interoperability and information exchange between systems from a diverse set of network ma
43、nagement system suppliers. Interoperability between systems involves many aspects of development. At its lowest layer, a common communication mechanism must be in place to support a common syntax, the establishment of connectivity and the exchange of operation requestsheplies between systems. This a
44、spect of interoperability is inherently supported by the CORB A specification. For TMN, there is the need to provide application interoperability. That is, management systems from diverse suppliers will be utilized within a single administrations TMN to support different functions necessary to suppo
45、rt management of its networks. To simplify integration of these various ITU-T 4.816 (01/2001) 7 suppliers systems, they must agree on the semantics of the information being exchanged. This is accomplished with the specification of an information model. Guidelines for the definition of CORBA-based in
46、formation models are specified in ITU-T X.780, but the services defined here must support those guidelines. 4.1.2 A second aspect of this framework is the definition of common usage and profiling of the distributed processing environment of choice. This aspect of the framework should indicate the re
47、asonable expectations network management system suppliers may have for one another. Rather than redefining the interface capabilities needed to support common network management functions such as object naming and notification filtering with each information model, the modeling guidelines in ITU-T X
48、.780 rely upon a set of support services. These support services enable the information models to be simpler, and also enhance interoperability. In defining these services, special effort will be taken to make use of the CORBA common object services. Specifically, this Recommendation will address th
49、e use of the CORBA ORB and CORBA Common Object Services (COS) that will impact system interoperability (i.e., issues involving the use of CORBA within a single system are outside the scope of this Recommendation). Where network management needs cannot be met by CORBA COS, additional services will be defined. 4.1.3 Information model transparency If CORBA is used in places within the TMN architecture where existing information models (e.g., GDMO) are well established, then the framework must support the reuse of those models without any major changes. The focu
