A QOS DISTRIBUTION MONITORING SCHEME FOR PERFORMANCE MANAGEMENT OF MULTIMEDIA NETWORKS

Transcription

1 A QOS DISTRIBUTION MONITORING SCHEME FOR PERFORMANCE MANAGEMENT OF MULTIMEDIA NETWORKS Yuming Jiang, Chen-Khong Tham, Chi-Chung Ko Department Electrical Engineering, National University Singapore, Singapore engp7450, eletck, Abstract To detect possible quality service (QoS) degradation and locate the cause the degradation, end-to-end QoS monitoring is not sufficient. Instead, QoS distribution should be monitored, i.e., the distribution QoS experienced by a real-time flow in different network segments should be monitored. However, few current monitoring systems can provide QoS distribution monitoring. This paper presents an improved relevant monitor (IRM) based scheme for QoS distribution monitoring. With this scheme, when monitoring a real-time flow, a network manager can locate relevant monitors that are metering the flow. By retrieving and consolidating traffic information from these monitors embedded in different network segments, not only the end-to-end QoS but also QoS distribution the flow are derived. In addition, with this scheme, QoS distribution monitoring can be performed in multiple network management domains. In this paper, CORBA-based implementation for this scheme is also introduced to show its feasibility. Keywords: Network management, Quality service, QoS monitoring, CORBA-based management I. INTRODUCTION Providing quality service (QoS) guarantees is a principal requirement for multimedia networks. To maintain the agreed QoS, it is not sufficient to just commit resources because QoS degradation is a common event and ten unavoidable. Any fault or weakening the performance a network element may result in the degradation the contracted QoS. Thus, performance management is required to ensure that the contracted QoS is sustained [1]. To date, while a considerable amount research has been done within QoS management provision such as QoS control [2] and QoS architecture [3], one limitation remains. The limitation is the lack distributed monitoring mechanisms to support QoS guarantees [3]. The intention QoS monitoring research is to allow a network manager to track the ongoing QoS, compare the monitored QoS against the expected performance, detect possible QoS degradation, and then tune network resources accordingly to sustain the delivered QoS [3]. Compared with traffic monitoring in traditional data networks, to provide QoS monitoring in multimedia networks imposes the following problems. Firstly, QoS monitoring requires application-level monitoring. In traditional networks, the monitored objects traffic monitoring are basically the total traffic into and out the device that a monitoring agent (e.g. SNMP [4] agent) attaches to. Thus, traditional traffic monitoring is usually limited to the network-layer in the Open Systems Interconnect (OSI) model. In contrast, in multimedia networks, real-time applications with different QoS requirements are an important part network traffic and the monitored objects are real-time flows. Thus, application-level monitoring [5] that performs monitoring above the network-layer is required. S flow i n 1 n j n k Q i n j Q i Fig. 1. QoS distribution monitoring Secondly, it is QoS distribution that should be monitored rather than end-to-end QoS. Consider the example shown in Fig. 1. Qin j denotes the QoS experienced by flow i in network segment nj; Qi denotes the end-to-end QoS seen by flow i; and Pi = (n 1 ::: nj ::: nk) is the set network segments that flow i passes. Then, we have Qi = F(Qin 1 ::: Qin k ). This equation means that the end-to-end QoS flow i is a function the QoS experienced by it in each network segment. Given that all Qin j, nj 2 Pi, are known, it is easy to derive Qi. However, if only the end-toend QoS Qi is known, it is not possible to determine Qin j in each segment. In order to detect possible QoS degradation and locate the cause the degradation, not only does the network manager need to know the Qi, but also the Qin j, nj 2 Pi. Thus, end-to-end QoS monitoring is not sufficient. Instead, QoS distribution (Qin 1 ::: Qin k ) should be monitored. Thirdly, since different real-time flows usually cross different network segments, the monitors involved in QoS monitoring them may be different. Thus, when monitoring a certain real-time flow, traffic information needs to be collected from its relevant monitors that are metering the flow. Lastly, since the network manager may be mobile, for example Web-based, the scheme adopted for QoS monitoring should provide mechanisms for the mobile manager to locate relevant monitors and vice versa. Over the past few years, several mechanisms have been proposed for application-level monitoring and QoS monitoring [5-11]. Waldbusser [5], Brownlee, Mills and Ruth [6], and Brownlee [7] considered the problem application-level monitoring and showed that application-level monitoring is R

2 possible and feasible. Mourelatou, Bouloutas and Anagnostou [8] proposed an agent-based approach to identifying QoS problems based on the information collected by all agents that were assumed to be capable providing end-to-end QoS monitoring. Ehab Al-Shear [9] proposed an event-driven dynamic monitoring approach for multimedia networks. An event might be the QoS degradation a multimedia application. Different from [8], this approach requires that prior to any monitoring operation, a system manager must describe the physical or geographical distribution the multimedia application that the manager intends to monitor. Chen et al. [10] introduced a stware approach to monitoring endto-end QoS in ATM networks. A key requirement for this approach is that a parallel test connection with the same route and QoS class is set up to test the selected user connection. In addition, another possible scheme for end-to-end QoS monitoring is to use RTCP monitors [11] to retrieve end-to-end traffic information from RTCP messages. Generally, [5-11] have proposed several QoS monitoring approaches from different perspectives and showed that QoS monitoring can be achieved if certain requisites or assumptions are satisfied. However, none these mechanisms addresses the problem QoS distribution monitoring directly and no means has been provided for a network manager to locate relevant monitors. In [12], Jiang, Tham and Ko proposed a relevant monitor (RM) based scheme for real-time flow monitoring. This scheme can also be used for QoS distribution monitoring. However, there are two limitations in it. One is that this scheme is not applicable when there are more than one network management domains. Another is that in this scheme, each monitor must be pre-configured. This paper presents a new scheme, the improved relevant monitor (IRM) based scheme, for QoS distribution monitoring. With this scheme, when monitoring a real-time flow, relevant monitors the flow can be located and thus traffic information can be retrieved from them. In addition, these operations can be performed by network managers from different network management domains simultaneously. Moreover, based on the retrieved traffic information, these network managers may control the network to ensure that the QoS provided to this flow is sustained. This paper is organized as follows. Section 2 presents the IRM-based scheme. Section 3 describes its CORBA-based implementation and Section 4 concludes the paper. II. IRM-BASED SCHEME A. Modules Fig. 2 shows the structure the IRM-based scheme. As in the RM-based scheme [12], it comprises three modules: the analysis application module, the monitor module and the real-time application name server () module. An analysis application is usually a part the network Domain 1 Analysis application Monitor (i)... Fig. 2. IRM-based scheme Domain n Analysis application Monitor (j) manager program that analyzes traffic information and provides analysis results such as QoS related parameters and QoS distribution certain real-time flows to users. In the IRMbased scheme, there can be more than one analysis applications from different network management domains. The monitors (e.g. RTFM [6] monitors) residing in different network segments provide real-time measurement real-time flows. When a real-time flow is selected for monitoring, only the monitors that are metering this flow will be involved in its traffic information collection and reporting. A real-time flow is identified by its source and destination addresses at various layers the OSI model [6], which may include its source and destination IP addresses and transmission port number (e.g. UDP port). Each monitor provides traffic information (such as numbers packets and bytes) the flow to analysis applications that have selected this flow to monitor. The monitor module in the IRM-based scheme is slightly different from that in the RM-based scheme. In the IRM-based scheme, each monitor maintains a list generated automatically by the registration each new. The monitor uses the list to find with which s the monitor should register metered real-time traffic attributes and corresponding references. In contrast, in the RM-based scheme, there is only one and each monitor is pre-configured to know where the is. The module provides a mechanism as in the RMbased scheme to bridge monitors and analysis applications, which enables analysis applications to locate relevant monitors and retrieve traffic information from them. Unlike the RM-based scheme that only has one for the network, there can be more than one in the IRM-based scheme, each which belongs to a different management domain and is made known only to its own domain. In addition, instead pre-configuration, each new must make itself known to all monitors by registering with them. Despite the above difference, each in the IRM-based scheme functions like the only in the RM-based scheme: each maintains a real-time application (RTA) list from which an analysis application can find the references relevant monitors that are monitoring certain flows and hence locate and retrieve traffic information from them. Fig. 3 and Table I il-

3 Snd A Snd B Flow A Flow B S1 S3 SW S2 S4 Fig. 3. A sample network Real-time Flows (sender, receiver) Flow A (Snd A, Rcv A) Flow B (Snd B, Rcv B) TABLE I RTA LIST IN Rcv A Rcv B Relevant Monitors S1, SW, S2 S3, SW, S4 lustrate an example the RTA list. In Fig. 3, there are two real-time flows, Flow A from Snd A to Rcv A through S1, SW and S2, and Flow B from Snd B to Rcv B through S3, SW and S4, where S1, S2, S3, S4 and SW are five network devices with monitors embedded. Then, the RTA list generated in the will look like Table I. B. Interactions Fig. 2 also shows interactions between modules the IRM-based scheme. Unlike the RM-based scheme where all monitors are pre-configured to know the only, in the IRM-based scheme, a new registers its reference to the list in each monitor. The monitor will use the references to locate the s. During the monitoring, monitors register attributes real-time flows and their references with all s. The in each network management domain is used by analysis application(s) within its same domain to find which real-time flows are being monitored and which monitors are metering the same flows. An analysis application retrieves the references relevant monitors from the RTA list in the so as to monitor a real-time flow. Once the analysis application locates the relevant monitors a real-time flow, it adds its reference to a network manager list in each monitor. This list stores the references all analysis applications that are collecting traffic information the same real-time flow. Then, the monitor uses these references to locate corresponding analysis applications and report traffic information to them. C. Improvement and tradef There are the following three principal differences between the IRM-based scheme and RM-based scheme. (1) In the RM-based scheme, there is only one common for the network, while in the IRM-based scheme there are more than one, each for a different management domain. (2) In the RM-based scheme, prior to all QoS monitoring operations, each monitor is configured to know where the only is. In contrast, in the IRM-based scheme, each registers its reference with all monitors during run-time. (3) In addition, in the IRM-based scheme, each monitor can report traffic information to multiple analysis applications belonging to different network management domains. These differences contribute to the improvement the IRM-based scheme over the RM-based scheme. With the improved scheme, not only can relevant monitors be found and the traffic information retrieved, but these operations can also be performed by analysis applications from different management domains. However, there is a tradef between the improvement and the system complexity. The RM-based scheme is less complex but only supports one network management domain. The IRM-based scheme is more flexible but more complex. Thus, when there is only one management domain, the RM-based scheme is preferred. However, if more than one management domains exist in the network, the adopted scheme should be IRM-based. III. CORBA-BASED IMPLEMENTATION The Common Object Request Broker Architecture (CORBA) [13] fers an environment for building distributed objectoriented applications. Its Interface Definition Language (IDL) and different programming language mappings to interfaces defined by the IDL enable client/server objects to interact among different Object Request Brokers (ORBs). Recently, researchers have adopted CORBA technique in network management [12,14-16]. Their experiences and achievements show that CORBA is a suitable technological framework for network management. This section introduces a CORBA-based implementation the IRM-based scheme. In particular, its IDL interfaces and corresponding object interactions are described. A. IDL interfaces Tables II, III and IV define IDL interfaces between the three modules the IRM-based scheme. These IDL interfaces are abstracted from the interactions described in Section II-B. B. Interactions among CORBA objects Fig. 4 shows the interactions among CORBA objects, which correspond to the client-side and server-side objects the interfaces defined in Tables II, III and IV. The interactions can be summarized in the following six steps. (1) Setting up a new invokes the registration its reference, type, to each monitor through the client object For. Correspondingly, the implementation object For adds

4 3. register 1. register 4. getrtalist ORB Core 6. updatetrafficinfo 5. register For For Manager:: Manager:: 2. RTA List List Meter Manager List Analysis Application Monitor Manager Fig. 4. Interactions among CORBA objects module f // Real-Time Application Name Server Struct RtAttributesf...;g; Struct RtItem f monref; RtAttributes rtattr;g; Typedef sequence hrtitemi RtaList; Interface f void getrtalist ( out RtaList rtalist);g; Interface f void register ( in RtAttributes rtattr, in monitorref);g; g; //End module module Monitorf // Monitor TABLE II INTERFACES OF MODULE Interface For f void register ( in ansref);g; Interface f void register ( in Manager:: mngref); void setupdateinterval ( in long interval ); g; g; //End Monitor module TABLE III INTERFACES OF MONITOR MODULE module Manager f // Manager Struct Recordf...;g; Typedef sequence hrecordi Records; Interface f void updatetrafficinfo ( in Records records);g; g; //End Manager module TABLE IV INTERFACE OF MANAGER MODULE (WITH ANALYSIS APPLICATION) the reference to the list in the monitor. (2) Detecting a new real-time flow causes the registration corresponding parameters from a monitor to all s that are in the monitor s list. The parameters include traffic attributes, type RtAttributes, and the reference the implementation object. (3) This operation is done through the client object. Accordingly, the implementation object the adds the attributes and reference to its RTA list. (4) A network manager invokes the operation getrtalist to get the RTA list through the client and implementation objects. The manager selects one real-time flow from the RTA list to monitor. As in the RM-based scheme, the manager finds the references, type, relevant monitors from the RTA list and starts to retrieve traffic information from them. This results in the generation several groups CORBA objects in the manager. Each group, responsible for communicating with one monitor, consists a client object and an implementation object Manager::. (5) After these steps, the manager registers the reference the implementation object Manager:: with the corresponding monitor. This is achieved through the client object. The implementation object in the monitor adds the manager s reference to its manager list. In addition, the interval for the monitor to report traffic information is set by the operation setupdateinterval. (6) Lastly, each monitor uses the references, type Manager::,in its manager list to locate all managers and update traffic information to them periodically in the required interval. C. Sample pages Fig. 5 and Fig. 6 show two sample pages from different network manager programs, which correspond to two network management domains: Domain 1 and Domain 2. The two

5 sample pages show the traffic graphs a real-time flow monitored by the two network managers, which started monitoring the flow at different times. Fig. 5 and Fig. 6 also show that there is QoS degradation between Monitor 1 and Monitor 3. In addition, from Fig. 6, the cause the degradation can be further located, i.e. the network segment between Monitor 1 and Monitor 2. Clearly, through the abovementioned steps, network managers from different domains can locate and communicate with relevant monitors simultaneously, and the monitors can report traffic information to these managers directly. Monitored Traffic From Monitor 1 From Monitor 1 From Monitor 2 From Monitor 3 Traffic Average From Monitor 3 QoS Degradation Fig. 5. Sample page from Domain 1 Fig. 6. Sample page from Domain 2 IV. CONCLUSIONS Providing sustained QoS to real-time applications imposes requirements on performance management. In this paper, we have argued that performance management multimedia networks requires QoS distribution monitoring rather than end-to-end QoS monitoring. Also, we have presented a new scheme, the IRM-based scheme, for QoS distribution monitoring. In addition, a CORBA-based implementation the scheme has been introduced to show its feasibility. Because the implementation was a prototype and the scale the testing system was small, many issues remain open, such as the scalability the monitoring system and the amount management traffic caused by the monitoring. Nevertheless, from the prototype implementation, we can have the following conclusions. With the IRM-based scheme, a network manager can locate relevant monitors the flow that has been selected to monitor and retrieve traffic information the flow from them. By consolidating such information, not only the end-to-end QoS but also the QoS distribution the flow can be derived. Based on this scheme, a network manager can locate the cause possible QoS degradation and may thus control networks accordingly. In addition, with the IRM-based scheme, QoS distribution monitoring can be performed in multiple network management domains. Moreover, the IRM-based QoS monitoring scheme is per-flow based, which is identified by its source and destination addresses. Since these addresses are not limited to certain layers the OSI model, the IRM-based scheme should also be suitable for monitoring flow aggregates if flows in one aggregate have the same source and destination addresses at a certain OSI layer. REFERENCES [1] G. Pacifici and R. Stadler, An Architecture for Performance Management Multimedia Networks, IFIP/IEEE ISINM 95, May [2] C.M. Aras, J.F. Kurose, D.S. Reeves and H. Schulzrinne, Real-Time Communications in Packet-Switched Networks, Proceedings the IEEE, v82 n1, Jan [3] C. Aurrecoechea, A.T. Campbell, and L. Hauw, A Survey QoS Architectures, Multimedia Systems Journal, v6 n3, , [4] J. Case, M. Fedor, M. Schfstall and J. Davin, A Simple Network Management Protocol (SNMP), RFC1157, May [5] S. Waldbusser, Remote Network Monitoring Management Information Base Version 2 using SMIv2, RFC2021, Jan [6] N. Brownlee, C. Mills, G. Ruth, Traffic Flow Measurement: Architecture, IETF RFC 2063, [7] N. Brownlee, Traffic Flow Measurement: Experiences with Ne- TraMet, IETF RFC 2123, [8] K.E. Mourelatou, A.T. Bouloutas, M.E. Anagnostou, An Approach to Identifying QoS Problems, Computer Commun. n17, , [9] Ehab Al-Shaer et al., Dynamic Monitoring Approach for Multi-point Multimedia Systems, IFIP/IEEE MMNS 98, France, Nov [10] T.M. Chen et al., INQIRE: A Stware Approach to Monitoring QoS in ATM Networks, IEEE Network, Mar.-Apr [11] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: A Transport Protocol for Real-Time Applications, RFC1889, [12] Y. Jiang, C.K. Tham and C.C. Ko, A Web-based Real-time Traffic Monitoring Scheme Using CORBA, MMNS 98, France, Nov [13] OMG, The Common Object Request Broker: Architecture and Specification, v2.0, July [14] S. Mazumdar, and K. Swanson, WEB Based Management - CORBA/SNMP Gateway Approach, IFIP/IEEE DSOM, Italy, [15] OMG, Interworking between CORBA and TMN System, RFP, [16] OMG, JIDM Interaction Translation - SNMP Part: Final Submission to OMG s CORBA/TMN Interworking, RFP, May 1998.