Implementation of CORBA Management Interface for B-PON System

Transcription

1 Implementation of CORBA Management Interface for B-PON System Hironori Terauchi (Mitsubishi Electric), Kouji Sato (Mitsubishi Electric), Taichi Kawabata (NTT), Eisaku Morita (NTT-AT) 1 Abstract FTTx has been expected to be the major broadband access service in near future. B-PON (Broadband Passive Optical Network) based on the ATM technology is one of candidates for FTTx, and has been standardized by ITU-T. Although B-PON system supports various communication services and provides various functionalities, the operations for B-PON system are complicated. Therefore, to solve this problem, easy-to-develop management interface is one of the key issues for B-PON system. ITU-T SG4 has defined some standard documents based on CORBA for telecom management, because CORBA enables to define management interface flexibly and to reduce development period and cost. FSAN (Full Service Access Network) has been organized by operators and nominated vendors to finalize B-PON specifications in ITU-T. In FSAN OAM-WG (Operation and Maintenance - Working Group), the management interface based on CORBA between NMS and EMS especially for B-PON system has been studied. FSAN OAM-WG discusses the new management interface for B-PON system as a ITU-T Q Recommendation. To promote the standardization, authors have provided the most advanced prototype system based on Q specification and tested them in order to clarify its feasibility, functionality and interoperability. In the prototyping, software for NMS and EMS have been developed, and successfully completed the connectivity tests. This paper introduces the Q.834 series of ITU-T Recommendations and summarizes the most advanced prototype systems based on Q Moreover it shows the result of the tests between NMS and EMS. 1

2 1. Introduction FTTH = Fiber To The Home Internet SNI B-PON (Broadband Passive Optical Network) UNI Internet (Data) PSTN Max 32 ONT TEL (Voice) Video SONET (TDM) OLT TV (Video Dist) PON Section (155M/622Mbps) Multi Services Platform by ATM technology Exclusive Line(DS1/E1) 2 1. Introduction The FTTx( e.g., FTTH ) is one of the most popular broadband access systems. B-PON system provides an economical solution for FTTx services, especially in high density of population area, such as metropolitan or big cities. The advantages of B-PON system are shown below. 1) Accommodate many users (e.g., 32 or 64) per one optical fiber 2) Requires a small space for equipment in Central Office. 3) Provides Multi Service on one platform (Ethernet, leased line emulation (e.g., DS1 and E1), Video distribution and POTS *1. *1:POTS(Plain Old Telephone Service) B-PON has been deployed for Broadband access services. However, B-PON is very powerful, efficient system which can provide various services, the management functions are very complicated. FSAN[1] is the group for studying and discussing about the B-PON standards. One of the FSAN group is OAN-WG (Optical Access Network - Working Group) which mainly handles physical interface between OLT and ONT and standardizes them as ITU-T G.983 series of Recommendation[2][3][4]. The interface for PON section up to 622Mbps/1.2Gbps (upstream/downstream) and one more downstream for video distribution (analog and digital CATV) are defined in G.983 series. The other group is OAM-WG where the B-PON management interface between NMS and EMS has been discussed. OAM-WG has standardized ITU-T Q.834 series of Recommendation[5][6][7], and has been studying about the CORBA-based B-PON management interface which will be standardized as ITU-T Q Recommendation. This paper introduces both legacy and new management Interface. Then, this paper presents the Q.834 series of Recommendations, and describes about the most advanced prototype system based on Q Recommendation. After showing the feasibility and interoperability study, this paper presents the conclusion. 2

3 2. Management Interface 2.1 Legacy Approach For example Individual Management Interface. OMS (NMS) CMIP SNMP TL1 SMS (EMS) CMIP SNMP ATM LAN TDM(DS3) more Management interface between OMS(=NMS) and SMS(=EMS) depends on network element Management Interface 2.1 Legacy Approach There are many types of management interface for each service equipment. For example, OMS for TDM(SDH) network equipment uses TL1 interface especially in the United States. OMS for LAN network equipment uses SNMP interface. Management topologies are also very different from each systems. TDM equipment has no SMS and an OMS directly communicates with the NE in TL1. TL1 Interface is a very old character based management protocol. This legacy OMS systems can not manage any equipment if the equipment does not support TL1 interface. B-PON equipment have native interfaces on both OLT and ONT, and provide rather complicated management interfaces to the management system. Because the TL1 interface functions are very limited for a B-PON system, B-PON SMS has to pretend Network Equipment. Even in that case, the legacy OMS can not manage the new B-PON functions because of the lack of the management interface in TL1. In addition to the difference of the management protocols, there are also another problems when the management system has to provide the integrated management functions. The locations of the required information are fragmented and there are no standardized management system application framework. In this situation, the management system software are highly specialized software, and are not be able to implemented by the engineers who are not familiar with the network management. Also the development of such kind of specialized management system software takes much costs and time. 3

4 2. Management Interface 2.2 New Approach 1. Requirements are Interoperability Time to market Cost 2. OSS components are connected by generic software bus CORBA HTTP/XML 3. B-PON management discussed in FSAN standardized as ITU-T Q New Approach For the cost reduction and the improvement of the efficiency of OSS, new OSS frameworks have been proposed. NGOSS by the TeleManagement Forum is one of the most actively discussed one. It provides business solution framework and architecture for creating the next generation OSS. One of the major characteristics of NGOSS is to provide the system architecture with re-usable components and commercial off-the-shelf technologies connected by the software communication bus. The software communication bus connects each software components and makes them a loosely coupled distributed system. For the communication software bus, CORBA[8] and the combination of HTTP/XML are commonly used. CORBA has many advantages like below. Supports various programming languages such like C, C++ and Java. Object Oriented. Enables easy development. Widely used not only for the network management. Therefore CORBA is one of the best technology for the network management system and there already exists some standardized specifications based on CORBA such like ITU-T X.780 Recommendation[9][10]. 4

5 2. Management Interface 2.2 Structure of Q.834 series Q UML description for management interface requirements - Provisioning installed network resources - Provisioning uninstalled network resources including capacity reservation - Service provisioning - Archive management - NE software management - NE configuration data backup and restore - Performance management - NE event publication - Profile management - Testing - Activity scheduling - Bulk transfer management - NE-EMS synchronization - Access control NMS (OMS) Q CORBA I/F (IDL) EMS (SMS) Network View Q Q Q Network Element View Q The specifications of B-PON OAM are standardized as the ITU-T Q.834 series of Recommendations. Q and Q are already finished its standardizing process in ITU-T. Q defines managed objects for B-PON system from network element point of view, and Q defines them from network point of view. Q provides a UML description for the management interface between a Supplier Management System(SMS) and an Operator Management System(OMS). In general, SMS is a Element Management System(EMS) and OMS is a Network Management System(NMS). In Q.834.3, the following three kind of objects are classified. Service Objects provides access to the management services implemented in the SMS. Domain Objects defines the B-PON specific management information which are identified in Q and Q based on X.780. Internal Objects represents SMS internal logic. Q is now under standardization process and provides a CORBA IDL definition for the management interface between a SMS and OMS. In Q.834.4, the following are specified as IDL. Provisioning installed network resources Provisioning uninstalled network resources including capacity reservation Service provisioning Archive management NE software management NE configuration data backup and restore Performance management NE event publication Profile management Testing Activity scheduling Bulk transfer management NE-EMS synchronisation Access control 5

6 3.1 B-PON: Multi-Service Platform 3. Prototype System TL1 NMS ISEM FTTB FTTX FTTP FTTH 6 3. Prototype system 3.1 B-PON For the prototype system, a real full service B-PON system[11] and SMS are used. B-PON OLT and ONT have following features. 1) Supports up to 32 Interface Cards including APON/OC3/DS3 2) 1 APON Interface can be connected to maximum 32 ONTs 3) maximum 2 LIM (Line Interface Module) cards for an ONT 4) Supports maximum 2,457,600 connections(in the case of LAN-OC) 5) NEBS (Network Equipment Building System)[12] [13] Certified 6) based on G.983.3(PON card uses 3 wavelengths, 2 for data and 1 for Video downstream) Integrated Service Element Manager (ISEM) is a SMS for the B-PON system. 1) Implemented in Java 2) Scalable/Highly Available Configuration 3) Manages more than 200 OLTs by 1 ISEM. 4) Using JINI/RMI for internal communication 5) Using CMIP/FTP/... for NE-side communication 6) Using TL1 for OMS-side communication 7) OSMINE (Operations System Modifications for the Integration of Network Elements )[14] Certified. ISEM has a very flexible architecture for adding new components and functions. Each components of ISEM are implemented as pure Java applications (except Database) and behave as a loosely coupled distributed systems. The followings are major characteristics of ISEM. 1) ISEM can be run on any platform which supports Java 2) Each components can be run on different machines. 3) Each VM has no static location information for other VM because Jini is used between them. 4) It is very easy to add/delete/change its functions, because Java RMI is used for ISEM internal S/W Bus. 6

7 3. Prototype System 3.2 Q Prototype System 1. Prototyping for investigating... Feasibility Functionality Interoperability 2. Test results are applied to Q Focused on Profile Management functions Q Prototype System In the 33rd FSAN OAM-WG meeting, authors decided to implement a prototyping system with the CORBA management interfaces which will be standardized in Q Recommendation. Our major goals of the implementation are to investigate about the feasibility, functionality and interoperability, and make a feedback to Q Recommendation document. In the prototyping, the profile management functions are focused because the functions contain both directions of operations between OMS and SMS. The profile is a set of parameter values which are to be set to the managed entities. For example, many values like PCR(Peak Cell Rate), QoS Class and so on are needed when the communication path is newly provisioned. In this case, a set of these parameter values are defined as a Traffic Descriptor Profile and stored in the management system. The operators can choose one of the already stored Traffic Descriptor Profile and use it when they would like to provision connections. According to Q Recommendation, profiles information are stored and maintained in Profile Object Repository(POR) which is independent from either OMS and SMS. When the operator of the OMS creates a new profile, the profile information is stored in the POR, and the POR sends a profile creation notification to SMS. Then the SMS receives the notification and stores the information of the profile. The information of the profile stored in the SMS is a cache information. The original information of profiles are always stored in the POR. Q Recommendation provides the following operations as the profile management functions. inuse : By this operation, OMS can retrieve the profile usage status from SMS. suspenduse : OMS can lock the profile from further use. rename : OMS can change a name of the profile which is cached in the SMS. deleteprofile : delete the profile information from the SMS. Profile Creation: the notification from POR to SMS, represents the creation of a profile and contains a profile information. retrieve : SMS can obtain the information of the profile from POR. With the operations listed above, some of the provisioning related operations which are defined in the Service Provisioning interface in Q Recommendation are implemented. provisionconnection : newly create a connection deleteconnection : delete a connection 7

8 3. Prototype System 3.3 Q Prototype System Architecture Profile Object Repository Q CORBA I/F RMI/Jini HMI CORBA Navigator (OMS) COS NamingService LAN/ ISDN ISEM(B-PON SMS) CORBA Agent ORB RMI/Jini HMI Agent NE Manager COS NotificationService NE NE NE Q Prototype System Architecture In the prototyping, SMS side functionalities are implemented as a CORBA Agent in already existing B-PON management system named ISEM. Also Profile Object Repository (POR) is implemented as a individual application program. OMS side functionalities are implemented as a generic CORBA testing tool named CORBANavigator. There are also CORBA NamingService and NotificationService. NamingService is used to obtain the object references of the CORBA server object and NotificationService is mainly used to transferring the ProfileCreation notification in this prototype. ISEM is consisted by five components and all of them are implemented in Java. The communications between each components of ISEM are done by Java Remote Method Invocation(RMI). Also each components find the communication partner at the startup time by Jini. There is a GUI component named HMI and its communication partner HMIAgent in ISEM. When the CORBA Agent is added to ISEM, HMIAgent is a good example to refer with. Many part of the HMIAgent can be used to implement CORBA Agent. CORBA related functions which are implemented in the CORBA Agent use Portable Object Adaptor(POA) model which is defined in the OMG s CORBA specification. With a POA model and a Java implementation, it is very easily to change the underlying ORB runtime module without almost no modifications and recompilation. Therefore two different ORB runtime, one is a free software[15] and conforms to CORBA 2.4.2, and the other is a ORB product [16] and conforms to CORBA 2.5, are used for the testing. After implementation, the prototype system is tested with two network configurations using a management scenario for the profile management. The first configurations is a LAN environment, and the second one is a dial-up ISDN connection environment. 8

9 4. Q Interoperability Investigation 4.1 Q Functional Feasibility 1. Testing based on a management scenario create/delete a Traffic Descriptor Profile(TDP) create/delete a connection using a TDP. 2. Implementation issues are... naming conventions in the CosNameService. the granularity difference of TDPs. ambiguous behavior of a exception Q Interoperability Investigation 4.1 Q Functional Feasibility The prototype system is tested using an operation scenario which contains creation/deletion of a Traffic Descriptor Profiles and Connections. And it is verified that the operations defined in Q is fully functional in the real operation sequences. However there are also some difficulties to implement the CORBA Agent. One of the difficulties is the difference of granularity of the Traffic Descriptor Profile definition between Q Recommendation and our management system, ISEM. In the Q Recommendation, the Traffic Descriptor Profile contains parameters for a unidirectional connection, while the Traffic Descriptor Profile in ISEM contains a bidirectional connection. To solve this difficulty, authors add a function to the CORBA Agent which coordinates the relationship between Traffic Descriptor Profiles for bidirectional and unidirectional connection. The second problem is that the description about an exceptional behavior in Q Recommendation document is ambiguous. For example, there is the operation named suspenduse. This operation raises three or four exceptions according to the exceptional situations. One of them is unknownprofile exception which is raised when the SMS does not obtain the specified profile. Because the Q Recommendation describes nothing about the concrete behavior of the SMS when it receives suspenduse operation with the unknown profile, it is possible for the SMS to 1) just return an unknownprofile exception or 2) try to retrieve the profile from POR and then return an unknownprofile if POR also does not have the profile. Authors discussed about these behaviors and concluded that the later behavior should be implemented in the SMS because the behavior 1) can not take care of the situation where the SMS does not have the profile but the POR has. In this case, if the OMS requests the provisionconnection operation after the suspenduse operation, the SMS with the behavior 1) will create the new connection with the profile though the profile should be already suspended As described above, the operations defined in the Q Recommendation is enough functional and it is possible to add the CORBA interface to an already existent management system even if there are small differences about the data representation such like profiles between the management system and the Recommendation. Also in the process of prototyping, implementation guidelines based on Q are highlighted. 9

10 4. Q Interoperability Investigation 4.2 Summary of current interoperability problem 1. OMG s CORBA2.4.*, 2.5 and other version. Interoperability??? 2. The LocateReply Body of GIOP1.2 aligned on an 8-octet boundary (2.4.*, 2.5) marshaled immediately following the LocateReply Header (2.6 and higher version) resulted to 4-octet boundary. without explicit description, however according its marshaling rule, it is 4-octet boundary.(before 2.4) Summary of current interoperability problem During our prototyping tests, some interoperability problems both in the ORB itself and the configuration setting are found. Especially, the problem related to the CORBA specification is a big issue not only for us but also all CORBA application developers. The problem is in the LocateReply message defined in the GIOP1.2. The LocateReply message is a reply message to the LocateRequest message which is a request to ask the location of the server object and get the object reference. For example, when the client starts up, usually it sends the LocateRequest message to the NamingService to obtain the object reference of the server object. After receiving the request, the NamingService returns the LocateReply message to the client and then the client can access to the server object by its object reference returned by the NamingService. As above, LocateRequest/Reply messages are very important for the CORBA applications. In the OMG s CORBA specification documents version 2.4.* and 2.5, the alignment for the LocateReply Body is specified as 8-octet. However in all of other versions of the specification, it is specified as 4-octet while there is no differences between the versions of the GIOP. That means the applications on both communication ends can not know which alignment value is used in the LocateReply message from the other. In the worst case, this makes the client application crash. The prototype system uses two different ORB implementation for the CORBA Agent in ISEM, at first a free ORB software is used not only for the SMS but also for the OMS and other services. In this configuration, no problems are observed. Then the ORB for the SMS is changed from the free ORB software to the product ORB software, and this change causes a communication problem. The free ORB software conforms to CORBA2.4.2, and the product ORB software conforms to CORBA2.5. Authors investigated this problem and finally found that the product ORB software was using 4-octet boundary for the LocateReply Body while the CORBA2.5 specification describes it as a 8-octet boundary. 10

11 4. Q Interoperability Investigation 4.2 Summary of current interoperability problem (cont.) OMG should properly update the latest specifications of CORBA2.4.*,2.5. Interoperability between CORBA systems will be much improved. 11 In OMG, there are some Revision Task Force(RTF) where the revision of the specification documents are discussed. For the interoperability issues, the Interoperability RTF manages the discussions. The problem in the alignment of LocateReply Body as described above were already discussed in the Interoperability RTF and they would already concluded to use 4-octet boundary for all versions of CORBA. After the decision of the RTF, specification document will have to be revised. However description of the alignment of the LocateReply Body is not revised yet. Maybe many of CORBA ORB vendors always incorporate the revised specification which has already determined by RTFs, however the free ORB software which is developed as an open source application only conforms to the CORBA specification document. For this problem, there are two alternatives to make our prototype system work correctly. The first way is to modify the ORB implementation. The free ORB software is a open source application and is implemented in Java. Therefore if the source code is modified to align the LocateReply Body onto a 4-octet boundary, it will successfully work. Authors tested this way only for validation and checked that the communications are successfully made. The second way is to use GIOP1.1. In GIOP1.1, there are no difference about the alignment of the location of LocateReply Body in the GIOP message. Generally it is possible to specify the ORB runtime to use only GIOP1.1 by specifying it in a configuration file or as a startup option. For the product ORB used for the prototype, it can be specified in its configuration file. Therefore this workaround is also tested, and the result is success. 11

12 5. Conclusion Conclusion Authors focused on B-PON management interface specified in Q using CORBA technology. 1. This paper describes the prototype system based on Q specification. In the process of prototyping, implementation guidelines based on Q are highlighted. 2. Using the prototype system, feasibility of Q profile management functions for real operations is verified. 5 Conclusion Authors have been discussing about the CORBA-based management interface for the B-PON system in FSAN OAM-WG, and it is under standardization process. This paper introduces the most advanced prototype system using CORBA management interfaces defined in Q in order to verify their feasibility, functionality and interoperability. And the prototype system was implemented and tested by both B-PON carrier and vendor. The results of the test using the prototype show that the interfaces defined in Q are fully functional for the real operations. The management interfaces specified in Q can be easily added to an already existing management system, and it is also possible to implement them from scratch as well. This paper also shows that there is an interoperability problem between some of the CORBA implementations and there are workarounds for the problem. The problem and the test results are reported to FSAN OAM-WG, and they will be summarized into a implementation guide document which can be helpful for all developers who will implement a management system based on Q References [1] FSAN, [2] ITU-T Recommendation G.983.1, "Broadband optical access systems based on Passive Optical Networks(PON)",1998. [3] ITU-T Recommendation G.983.2, "The ONT Management and Control Interface Specification for ATM-PON",2002. [4] ITU-T Recommendation G.983.3, "A broadband optical access system with increased service capability by wavelength allocation.",2001. [5] ITU-T Recommendation Q.834.1, Network element view information model for ATM-PON system. [6] ITU-T Recommendation Q.834.2, Network view information model for ATM-PON system. [7] ITU-T Recommendation Q.834.3, A UML description for management interface requirements for broadband passive optical networks [8] OMG, [9] ITU-T Recommendation X.780, "TMN guidelines for defining CORBA managed objects", [10] ITU-T Recommendation M.3020(2000), "TMN Interface Specification Methodology [11]FSAN Vendors Presentations on B-PON Systems and components, Proceedings OHAN 2002, [12] NEBS, Bellcore standards GR-63 CORE, "Physical Protection Standards" [13] NEBS, Bellcore standards GR-1089 CORE, "EMC/Electrical Safety" [14] OSMINE Process, Telecordia, [15] OpenORB, [16] IONA OrbixE2A,