1、 International Telecommunication Union ITU-T Y.2901TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (12/2006) SERIES Y: GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS AND NEXT-GENERATION NETWORKS Next Generation Networks The carrier grade open environment reference model ITU-T Recommend
2、ation Y.2901 ITU-T Y-SERIES RECOMMENDATIONS GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS AND NEXT-GENERATION NETWORKS GLOBAL INFORMATION INFRASTRUCTURE General Y.100Y.199 Services, applications and middleware Y.200Y.299 Network aspects Y.300Y.399 Interfaces and protocols Y.400Y.499 N
3、umbering, addressing and naming Y.500Y.599 Operation, administration and maintenance Y.600Y.699 Security Y.700Y.799 Performances Y.800Y.899 INTERNET PROTOCOL ASPECTS General Y.1000Y.1099 Services and applications Y.1100Y.1199 Architecture, access, network capabilities and resource management Y.1200Y
4、.1299 Transport Y.1300Y.1399 Interworking Y.1400Y.1499 Quality of service and network performance Y.1500Y.1599 Signalling Y.1600Y.1699 Operation, administration and maintenance Y.1700Y.1799 Charging Y.1800Y.1899 NEXT GENERATION NETWORKS Frameworks and functional architecture models Y.2000Y.2099 Qual
5、ity of Service and performance Y.2100Y.2199 Service aspects: Service capabilities and service architecture Y.2200Y.2249 Service aspects: Interoperability of services and networks in NGN Y.2250Y.2299 Numbering, naming and addressing Y.2300Y.2399 Network management Y.2400Y.2499 Network control archite
6、ctures and protocols Y.2500Y.2599 Security Y.2700Y.2799 Generalized mobility Y.2800Y.2899 For further details, please refer to the list of ITU-T Recommendations. ITU-T Rec. Y.2901 (12/2006) i ITU-T Recommendation Y.2901 The carrier grade open environment reference model Summary ITU-T Recommendation
7、Y.2901 presents the carrier grade open environment reference model. Source ITU-T Recommendation Y.2901 was approved on 14 December 2006 by ITU-T Study Group 13 (2005-2008) under the ITU-T Recommendation A.8 procedure. ii ITU-T Rec. Y.2901 (12/2006) FOREWORD The International Telecommunication Union
8、(ITU) is the United Nations specialized agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to stan
9、dardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is c
10、overed by the procedure laid down in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts 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 in
11、dicate both a telecommunication administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure e.g. interoperability or applicability) and compliance with the Recommendation is achiev
12、ed when all of these mandatory provisions are met. The words “shall“ or some other obligatory language such as “must“ and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party. INTELLECTUAL P
13、ROPERTY RIGHTS ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether ass
14、erted by ITU members or others outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned
15、 that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2007 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU.
16、ITU-T Rec. Y.2901 (12/2006) iii CONTENTS Page 1 Scope 1 2 References. 1 3 Definitions 1 4 Abbreviations and acronyms 3 5 The CGOE ecosystem. 5 6 The COTS ecosystem . 5 7 CGOE general concepts 5 8 CGOE reference model. 8 8.1 The NGN architecture 8 9 Understanding the CGOE reference model 9 9.1 Indust
17、ry application 9 9.2 Operating platform . 10 9.3 Server hardware 16 10 Security considerations. 17 Appendix I CGOE principles 18 Bibliography. 19 ITU-T Rec. Y.2901 (12/2006) 1 ITU-T Recommendation Y.2901 The carrier grade open environment reference model 1 Scope This Recommendation presents the carr
18、ier grade open environment (CGOE) reference model that is used to categorize CGOE components. These CGOE components are intended for use in commercial off the shelf (COTS) components. 2 References The following ITU-T Recommendations and other references contain provisions which, through reference in
19、 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; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent
20、edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation. ITU-T Y.2012 ITU-T Recomme
21、ndation Y.2012 (2006), Functional requirements and architecture of the NGN release 1. 3 Definitions This Recommendation defines the following terms: 3.1 application: An application is a piece of software answering a set of users requirements using telecommunication network services via an IT system.
22、 3.2 application programming interface (API): A boundary across which a software application uses facilities of programming languages to invoke software services. NOTE These facilities may include procedures or operations, shared data objects and resolution of identifiers. 3.3 building block: A logi
23、cal unit, composed of components, characterized by its ability to deliver certain self-contained service functionality. 3.4 carrier grade: Colloquially, a “carrier grade“ implementation of a solution, building block, or a COTS component exhibits particular qualities beyond regular information techno
24、logy (IT) reliability, availability, serviceability, and manageability (RASM) features, enabling its mission-critical use in a service providers offering. NOTE COTS component can be called “carrier grade“ with respect to a particular building block if it meets all of the necessary and sufficient non
25、-functional requirements of a COTS category for such a building block. 3.5 CGOE category: A unit of description of the CGOE reference model. It comprises one or more CGOE components. NOTE This method of abstraction keeps the size of the framework manageable and understandable. It avoids being too sp
26、ecific or leaning towards the needs of a certain building block. For example, the alarm management category consists of several components, e.g., alarm generation and alarm clearance. 3.6 CGOE component: A CGOE component is an abstract description of technical tasks, interfaces and properties. 2 ITU
27、-T Rec. Y.2901 (12/2006) 3.7 CGOE reference model: A model that organizes the CGOE categories. NOTE 1 Each category is intended to be independent in the sense that it does not require the existence of the categories above it; however, to produce carrier grade functionality, functions may be needed f
28、rom more than one category. NOTE 2 Multiple categories are logically grouped and referred to as the server hardware and the operating platform. 3.8 COTS component: A hardware or a software component instantiation of one or more CGOE components. NOTE 1 Existing or new components may instantiate CGOE
29、components. NOTE 2 The following are examples of components: database system, operating system and management middleware. 3.9 component instance: A component instance is a specific representation of a component, which satisfies the needs of building a specific building block. NOTE Technology provide
30、rs develop component instances. During the engineering process within the solution providers, instances are chosen according to the requirements, and are integrated to eventually stage the entire building block. Examples of component instances: Linux, management middleware for Q3-access. 3.10 contro
31、l plane: The control plane performs the call/session control and connection control functions. 3.11 diameter: An IETF protocol that may be used to provide an authentication, authorization and accounting (AAA) framework for applications. 3.12 framework: A framework is an environment that provides a p
32、artial solution, usually automating a particularly tedious or difficult part of an application project. 3.13 functional requirements: The set of interfaces, capabilities and features developed with respect to a service architecture associated with a building block. 3.14 lifecycle management: The man
33、agement of a component, including loading it into memory, allocating the system resources it needs and removing it when it is complete. NOTE The lifecycle management of a component also comprises the software management functions, i.e., first installation of the component, the management of upgrades
34、 and updates of new releases/versions of the component. 3.15 management plane: The management plane performs management functions for the transport plane, the control plane and the system as a whole. It may also provide coordination between all the planes. 3.16 middleware: The mediating entity betwe
35、en two information elements. Such an element can be, for example, an application, an infrastructure component or another mediating entity. 3.17 non-functional requirements: A list of features that a building block must provide in order to ensure certain behaviour within the service architecture. NOT
36、E This list mostly represents requirements to allow for smooth operations and lifecycle management. 3.18 open component: A component can be called “open“ when it is capable of being accepted, rejected, extended and replaced in a building block with minimal restriction and regulation, following commo
37、nly-accepted, publicly-available criteria and open standards for the interfaces. 3.19 open standards: Standards made available to the general public which are developed (or approved) and maintained via a collaborative and consensus-driven process. Other elements of “open standards“ include, but are
38、not limited to: Collaborative process voluntary and market-driven development (or approval) following a transparent consensus-driven process that is reasonably open to all interested parties. Reasonably balanced ensures that the process is not dominated by any one interest group. ITU-T Rec. Y.2901 (
39、12/2006) 3 Due process includes consideration of, and response to, comments by interested parties. Intellectual property rights (IPRs) IPRs essential to implement the standard to be licensed to all applicants on a worldwide, non-discriminatory basis, either 1) for free and on other reasonable terms
40、and conditions, or 2) on reasonable terms and conditions (which may include monetary compensation). Negotiations are left to the parties concerned and are performed outside the SDO. Quality and level of detail sufficient to permit the development of a variety of competing implementations of interope
41、rable products or services. Standardized interfaces are not hidden and are not controlled other than by the SDO promulgating the standard. Publicly available easily available for implementation and use at a reasonable price. Publication of the text of a standard by others is permitted only with the
42、prior approval of the SDO. On-going support maintained and supported over a long period of time. NOTE “Open standards“ facilitate interoperability and data exchange among different products or services and are intended for widespread adoption. 3.20 operating platform: An operating platform is an ama
43、lgam of many different infrastructure technologies that host application systems. NOTE The following are examples of key components of an operating platform: operating system, programming language, human interface representation, database server, security infrastructure and management infrastructure
44、. 3.21 service plane: The service plane comprises: a) service presentation functionality being presented to the end user; b) service implementation aspects with which the end user interacts. 3.22 service provider: A company that offers end-to-end telecommunication services (fixed/mobile, voice/data)
45、 to customers. 3.23 solution provider: A company that engineers and produces building blocks and solutions and sells them to service providers. 3.24 technical task: The functional work performed by a component. 3.25 technology provider: A company that develops component instances, which solution pro
46、viders integrate into building blocks. 3.26 transport plane: The transport plane provides bidirectional or unidirectional transfer of user information from one location to another. It can also provide transfer of control and network management information. 4 Abbreviations and acronyms This Recommend
47、ation uses the following abbreviations and acronyms: API Application Programming Interface BGP Border Gateway Protocol CGOE Carrier Grade Open Environment CIM Common Information Model COPS Common Open Policy Service CORBA Common Object Request Broker Architecture COTS Commercial Off-The-Shelf 4 ITU-
48、T Rec. Y.2901 (12/2006) CSR Customer Service Representative DNS Domain Name System EJB Enterprise JavaBeans Enum Enumeration HA High Availability HTTP HyperText Transfer Protocol HW Hardware IP Internet Protocol ISV Independent Service Vendor IT Information Technology J2EE Java 2 Platform Enterprise
49、 Edition JDBC Java DataBase Connectivity JSP Java Server Page JVM Java Virtual Machine LDAP Lightweight Directory Access Protocol MTTF Mean Time To Failure ODBC Object Database Connectivity OS Operating System PDA Personal Digital Assistant PIN Personal Identification Number RASM Reliability, Availability, Serviceability and Manageability RDD Relational Database Descriptor RMI Remote Method Invocation RTP Real Time Protocol SAF Service Availability Forum SCTP Stream Control Transmission Protocol SIGTRAN S
