Electronics and Telecommunications Research Institute
The Design and Development of Service Level Agreement Supporting System for Various Network Services in Korea
Eunjin Ko, BooSun Jeon, Gilhaeng Lee
Electronics and Telecommunications Research Institute
161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA
Phone:+82-42-860-1258 Fax:+82-42-860-6342
{ejko, bsjeon,ghlee}@etri.re.kr
Keyword : SLAS, Information Module, Monitoring Module, .NET Framework
Abstract
As demands of network users are increasing in network performance and the other things, NSP(Network Service Provider)s are trying to provide several ways to satisfy the demand of network users. In these ways, many network service providers support high quality network service acceptingSLA(Service Level Agreement).
The structure of SLA System is very flexibility, because several network services are provided by NSPs not only one network service and each network service have to provide to network users with SLA.
Also, SLA system is interworking with many other systems, gathering a lot of information from those systems, monitoring whether the condition that is agreed between network users and network service provider.
In this paper, we design and develop SLAS(Service Level Agreement Supporting) System which is composed with several modules and depended on .NET framework to accept these conditions to provide SLA service.
1. Overview
In the early network area, Network Service Providers were just providing network service without regarding network performance, how long it would take a time to open network service or recover network trouble situation. But in these days, network users who have variety demands in many aspects are requesting high quality of network performance and side-effect serviced quality, i.e. open processing time or trouble processing time.
Also, recently there is a ambiguous situation when network is down or the performance of network is below the common standards.
In these circumstances, there are needs to more clearly define the demand of network users and the limit of network performance provided by NSP. SLA is a formal negotiated agreement between two parties to accommodate these requirements[7]. In SLA, if Network Service Provider doesn’t provide network service quality, they have to pay back to network users [8].
In Korea, there are few big network service companies whose service categories are variety. And national institutes like KRNIC(Korea Network Information Center) or NCA(National Computerized Agency) let network service companies provide SLA service in Korea[1][5]. With considering to adept these policies in Korea, we design and develop a system that provides SLAservice in Korea. In Korea, because there are big network service companies providing diverse network service, SLAS system provides various levels and categories of SLA with modularized structure. We explain the structure of SLAS system and the process scenario to provide SLA to network users.
This paper is written in the following steps. In Chapter 2, this paper describes the condition of design SLAS system. We explain the function of each module that is composed of SLAS system in chapter 3 and describe the process scenario on the each SLA metrics. In chapter 5, we will mention about the conclusion to design and develop of SLAS system.
2. The conditions of designing SLAS system
All of process in SLAS system depends on the contract between Network Service Provider and Network Service Users. There are three categories on SLA considering current SLA trend: Open Metrics, Trouble Metrics and Network Metric[2][6].
The first SLAcategory is Open Metrics. Open Metric is related with a process that monitors how long network service provider need a time to open network service to network service user from open request day to completed open process. The value of open metrics depends on the contract or customer request day to open if possible.
The Second SLA category is Trouble Metrics. Trouble Metrics is related with a process which monitors how long network service provider spend a time to recover network trouble situation and how open and long network fault situation has been occurred. It also depends on the contract.
To guarantee trouble metrics, it has to monitor every single trouble occurrence from network management system or other system which controls network that SLAS system. Also, SLAS gathers and counts how many troubles occur and total trouble times.
The third SLA category is Network Metrics. Network Metrics is the most important category to network users and there is a gap between the network performance users have and the NSP provides.
In SLAS system, it is interworking with each network performance gathered system for collecting network performance data and monitoring network performance data which is produced by DS(Data Statistic) Module in SLAS every midnight.
To receive raw data, SLAS system have to interwork among COP(Customer Open Processing) System, CSG(Customer Service Guarantee) System, each NMS(Network Management System) and EC(Equipment Control) System.
The COP system takes charge of Customer open request and The CSG system controls and manages every network trouble notification. The NMS collects network performance data and the EC system manages network equipments. With interworking many other systems, SLAS system gathers every network trouble information and network performance data periodically.
To consider these conditions, we design SLAS system consisted of inner-outer communication module, data management module, data statistic module, monitor module, data gathering module, service specific processing module and accept .NET framework and C# programming language provided by Microsoft development solution [3].
In the communication with other systems, SLAS system uses XML document to persistent data consistency and accuracy [9].
3. SLAS System
SLAS system consists of total 6 modules as you see figure 1. In this chapter we explain the function of each module.
3. 1. Information Distributor module
ID(Information Distributor) Module provides a communication function. To transfer XML document, we have to register mapping information that presents the relation between XML document format and target system before SLAS system loading.
After receiving XML document, ID module checks the type of XML document, find out the target system and transfer XML document to the target system. In transfer processing, ID module creates a SLAS common XML document from outer XML document for control XML document more easily in inner modules. When receiving and sending XML document, SLAS system uses queues with EAI(Enterprise Application Integration)[4].
The way of sending a XML document to the outer systems is much like when receiving a XML document from outer system.
Figure 2. Dynamically deploying
Service-specific web service
3.2. Service Specific Module
SS(Service Specific) Module checks contents of XML document from ID module and retrieves information from it which SS module needs. In the case of processing open metrics, SS modules save information using library provided by DS(Data Supporting) Module in the SLAS database.
In the case of receiving Open Completed Order or Open Changed Order, SS module finds out initial open order that is related with the received order. If there is any unmatched information in the Open Completed or Open Changed Order, SS module throws it to the DS module to save error log information.
Also, SS module sends it to the service-specific process web service if there is a need to process service specific control. In that case, SS module receives the result of processing service-specific process web service and request DS module to save the information and log. In the process open metric, it is important to keep the status of processing each customer and SS module takes charge of it. Because SLAS system has to accommodate network service dynamically, we design that SS module consists of common web service part and service specific web service part in figure 2.
So, if SLAS system receives a XML document, SS module checks the type of XML document, finds out the mapping information in the XML creation web service list table and calls related web service for processing service specific scenario. Otherwise, if there is no need to use a web service, SS module deletes a web service that is no more used. All of these processing is working without shutdown of SLAS system.
3.3. Data Supporting Module
DS(Data Supporting) module provides libraries related with Data Base to other modules in SLAS system. In SLAS system, there is a lot of information from other systems and are many database tables depended on the type of information. And, there are many changes in the schema of tables. So, if there is allowed to access database, every access routine have a dependency on the status of database tightly.
Because it is nonsense policy that all of modules in SLAS system control database individually, we design a module thatwholly controls database to guarantee information consistency in database. Using DS module, it is easy to access data base without considering the structure of DB table or other things and possible to access database efficiently.
3.4. Data Monitoring Module
SLAS system monitors all information related with SLA metrics and forecasts the violation of contract between two parties. If there is a sign to violate the contract, SLAS system alarms it to the operator or other systems that control each network.
To support these operations, DM(Data Monitoring) module monitors periodically all of data which is saved in data base which is related with Open, Trouble, Network metrics. The standard value of each metrics is already saved in metric table before SLAS system support that network service.
To monitor all of information is very difficult, so DM module has a monitoring policy which is based on the time when each data occurred and generated by SS module.
In Open metric, DM module gets open request day and open hope day in the step of receiving open request and compares current time and the value of open metric every day in each network service. In Trouble metric, it has trouble occurred time and the value of trouble metric and compares these time to check whether trouble violation is happened or not.
Also, after received a trouble recovery information from CSG system, DM module calculates how long it spent time to recovery network fault event and finds out there is a violation or not. If there is a alarm notification or violation notification, DM module sends a alarm message or violation message to UI System immediately. In Network metric, DM module checks whether there is a violation in network metric or not depended on billing period and notifies alarm or violation message to UI system. To do this operation, DM module cooperates this function with DST(Data Statistics) module every midnight.
3.5. Data Statistics Module
DST(Data Statistics) module generates statistic information which is used by SLAS system. The statistic units are day, week and month because normal billing unit is month. In statistic information, there are two types. The first type is general information which is needed to represent the state of SLAS operation. The other type is specific information thatis used to manage Trouble or Network metric. When SLAS system checks and finds out whether there is a violation or not, statistic information produced by DST module is used.
Because it is not necessary to operate all day long, DST module works on every midnight to generate statistic information based on gathered information which is collected.
3.6. Data Gathering Module
In providing SLA service in SLAS system, SLAS system has to gather bulk data from other systems. The amount of bulk data is very huge and each interworked system has its own interworking method. Considering these conditions, we design DG(Data Gathering) module which has a charge to gather information with adapting individual interworking method instead of ID module. There are several types to interwork with other systems, i.e. NMS. DG module provides a container which accommodates interworking sub-modules.
4. SLAS Processing Scenario
In the case of two of three SLA metrics defined in SLAS system, the open and trouble metric, there are two-step processes which are occurrence ad completion to provide SLA service. In this chapter, we explain the processing scenario including these two metrics.
4.1. Process of open metric
As you see in the figure 3, after receiving a initial open order from COP system through EAI, ID module gets that XML document, finds out the target module based on the type and contents of received information and sends translated information to the target module. All of Open ordersare sent to the SS module and SS module calls the web service that processes that XML document. After end of processing, SS module notifies the result to DM module and requests DS module to save information for deciding the violation of open metric.
DM module requires deleting a monitored list if there are no violation reports. If there are violations, DM module notifies it to SLAS Web UI system. When it monitors open metric, DM module gets scheduler and the standard value of open metric.
4.2. Process of network metric
There are many systems that collect network performance information and have its own interworking methods. So, after gathering network performance information, Service
Specific module notifies the end of gathering to ID module. As you see figure 4, DST module collects network performance information and generates statistic information from network performance information. When DST module accesses the database, it uses library provided by DS module. If there is violation of network metric, DM module notifies it to SLAS web UI system. If there is a sign to violate network metric, it is needed to inform alarm message to operator to prevent violation.
4.3. Process of Trouble metric
In processing of trouble metric, there are two steps of it: receiving trouble occurrence and trouble recovery. When it receives troubleoccurrence through ID module, SS module sets a new monitoring schedule depended on trouble information. In DM module, it periodically monitors the violation of trouble metric based on the monitoring schedule produced by SS module and saves log information after the end of monitoring process.
If there is a violation of trouble metric, DM module notifies violation notification to SLAS web UI system through ID module. After receiving notification from DM module, operator controls the recovery process of network trouble.
When it receives trouble recovery information, DM module checks the total time of recovery trouble situation. If the total time of recovery is over the limit of trouble metric, DM module notifies it.
In figure 5, we can see the steps of processing scenario that shows you the detail of processing scenario of trouble metric.
5. Conclusions
To design and development of SLAS system which provides SLA service, there are many conditions that we have to consider to design.
So, in this paper, we explain many conditions to design SLAS system firstly. To accept these conditions, we have to design SLAS system that consists of several modules that control and manage its own function.
In the step of explaining the function of each module, this paper describes why we create that module and how that module operates with other system. And then, we explain the processing scenario of SLA metrics. To provide SLA service, we know that SLAS system is interworking with other systems, i.e. COP, CSG, NMS and EC system. In the future, we will test the performance of SLAS system with massive raw data generated by simulator. Depending on the result of simulation test, we will modify the functions of SLAS system to adjust utilization of SLAS system.
6. References
[1] KRNIC,
[2] MCI, Customer Service: SLA,
[3]Microsoft, MS .NET,
[4] Microsoft, HOW TO : MSMQ,
[5] NCA,
[6] Sprint, Sprint SLA,
[7] TM Forum,
[8] TM Forum, “Service Level Agree Management Handbook”, GB917, v1.5, June, 2001
[9] W3C, XML 1.0 W3C Recommendation 6 Oct. 2000