AN IMPROVED REAL-TIME TRAFFIC FLOW MONITORING SCHEME

AN IMPROVED REAL-TIME TRAFFIC FLOW MONITORING SCHEME Yuming Jiang, Chen-Khong Tham, Chi-Chung Ko Department Electrical Engineering National University Singapore, Singapore 119260 Email: engp7450, eletck, elekocc@nus.edu.sg ABSTRACT Real-time traffic flow monitoring is essential to the management multimedia networks and services. This paper presents an improved scheme and its CORBA-based implementation based on our previous work [1]. This scheme can be used to simultaneously locate relevant traffic monitors along the path a certain real-time flow and retrieve traffic information from them. By consolidating traffic information from these monitors embedded in different network segments, it is easy to derive quality service (QoS) related parameters, such as delay jitter and loss ratio this flow in different network segments. The improvement the new scheme over the scheme in [1] is that the new scheme can be performed in multiple network management domains. 1 INTRODUCTION Management multimedia networks is different from management traditional data networks in that managed objects in multimedia networks and in traditional data networks are different. In traditional networks, textual data comprise most network traffic. These data, like FTP file data and email, are not time-critical but correctness-critical. However, in multimedia networks, real-time multimedia applications, such as Internet telephony and video conferencing, make up an important part network traffic. These applications are time-critical and may have different QoS requirements. Hence, QoS management is central to multimedia network management [2]. In order to provide QoS management, realtime traffic flow monitoring is essential: only with real-time flow monitoring can QoS related parameters and its distribution in different network segments be monitored and used as basis for QoS control. To date, there are three possible real-time flow monitoring models. Figure 1 shows the RTCP (real time control protocol [3]) based model, Figure 2 shows the TM (total monitor [4]) based model, and Figure 3 shows the RM (relevant monitor [1]) based model. Analysis application RTCP Monitor Figure 1. RTCP-based model Analysis application Monitor (1)... Monitor (n) Figure 2. TM-based model Analysis application Monitor (i)... Monitor (j) Figure 3. RM-based model In RTCP-based model, traffic information and QoS parameters are directly retrieved from multimedia transmission control message, i.e. RTCP message [3], from RTCP monitors [3]. However, because the QoS parameters retrieved in this model are between sender(s) and receiver(s) [3], it is difficult to derive their distribution in different network segments, which is necessary in locating possible QoS degradation. In contrast, in TM-based and RM-based models, traffic information is collected from monitors resid-

ing in different network segments. Thus, with the consolidation such information, not only can endto-end QoS parameters be derived but also QoS distribution is provided. With the QoS distribution, network managers can locate possible QoS degradation and apply QoS control accordingly. The difference between TM-based model and RM-based model is as follows. In TM-based model, an analysis application collects traffic information from all monitors that are inside a network regardless their involvement in the monitoring a certain real-time traffic flow. However, in RM-based model, only relevant monitors that are monitoring the same real-time traffic flow are selected to retrieve traffic information from. An example using TM-model is [4]. Theoretically, with traffic information from all possible monitors, including related and non-related, QoS parameters and its distribution can be derived. But, this results in more calculation and higher management traffic than the other two models. In RM-based model, only monitors that are monitoring the same real-time traffic flow will be involved in its QoS monitoring. The feasibility the RMbased scheme is validated by the prototype implementation in [1]. However, there are two limitations in this scheme. One is that this scheme is not applicable when there are more than one network management domains. Another is that in RM-based scheme, each monitor must be pre-configured to know where the only is. This paper presents an improved relevant monitor (IRM) based scheme and its CORBA-based implementation for real-time traffic flow monitoring. With the new IRM-based scheme, not only can realtime traffic information be collected from relevant monitors, but also such collection can be performed from different network management domains simultaneously. Thus, all network management domains can access the QoS distribution a certain real-time flow. This paper is organized as follows. Section 2 presents the new IRM-based scheme in detail. Section 3 describes its CORBA-based implementation and Section 4 gives the conclusion marks. 2 IRM-BASED SCHEME 2.1 Modules Figure 4 shows the structure the IRM-based scheme. As in RM-based scheme [1], there are three principle modules in this structure. They are the analysis application module, monitor module and real-time application name server () module. Analy. appl. Domain 1 Monitor (i)... Domain n Analy. appl. Figure 4. IRM-based model Monitor (j) An analysis application is usually a part the network manager program that analyzes traffic information retrieved from different monitors and provides analysis results such as QoS related parameters and QoS distribution certain real-time flows to users. In the IRM-based scheme, there can be more than one analysis applications from different network management domains. The monitors (e.g. RMON-2 [5]) residing in different network segments provide real-time measurement real-time flows. When a real-time flow is selected for monitoring, only those 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 address, destination address, transmission port number (e.g. UDP port) and real-time transport protocol (e.g. RTP [3]). Each monitor can provide traffic information (such as numbers packets and bytes) the real-time flow to analysis applications that have selected this real-time flow to monitor. The monitor module in IRM-based model is slightly different from that in RM-based model. In IRM-based model, 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 RM-based model, there is only one and each monitor is pre-configured to know where the is. The module provides a mechanism as in RM-based scheme to bridge monitors and analysis applications. Such mechanism enables analysis applications to locate relevant monitors a certain real-time flow and retrieve traffic information from them. Unlike RM-based model, there can be more than one s in IRM-based model. Each the s belongs to a different network management domain and is made well known only to its corresponding domain. In addition, instead pre-configuration, each new should make it-

self known to all monitors by registrating with them. Despite the above difference, each in IRMbased model functions like the in RM-based model: each dynamically maintains a realtime application (RTA) list from which an analysis application can find the references relevant monitors that are monitoring certain flows and hence retrieve traffic information from these monitors. Figure 5 and Table 1 illustrate an example the RTA list. In Figure 5, 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 1. Snd A Snd B Flow A Flow B S1 S3 SW S2 S4 Figure 5. A sample network Real-time Flows (sender, receiver) Flow A (Snd A, Rcv A) Flow B (Snd B, Rcv B) 2.2 Interactions Table 1. RTA list in Rcv A Rcv B Relevant Monitors S1, SW, S2 S3, SW, S4 Figure 4 also shows interactions between modules the IRM-based scheme. Different from RM-based scheme where all monitors are pre-configured to know the, in IRMbased 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 corresponding 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 can retrieve references all relevant monitors from the RTA list in the to monitor a real-time flow. Once the analysis application locates the relevant monitors a real-time flow, it will add 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 realtime flow. Then, the monitor can use these references to locate corresponding analysis applications and report traffic information to them. 2.3 Improvement and tradef There are the following differences between the IRM-based scheme and RM-based scheme. (1) In RM-based scheme, there is only one common for the whole network, while in IRM-based scheme there are more than one s, each for a different network management domain. (2) In RM-based scheme, prior to all monitoring operations, each monitor is configured to know where the is. In contrast, in IRM-based scheme, each registers its reference with all monitors during run-time. (3) In addition, in IRM-based scheme, each monitor can report traffic information a certain real-time flow 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 network 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 a network, the adopted scheme should be IRM-based. 3 CORBA-BASED IMPLEMENTATION The IRM-based scheme described in Section 2 can be implemented using CORBA technique. The Common Object Request Broker Architecture (CORBA) [6] fers an environment for building distributed object-oriented applications. The CORBA 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). To date,

4. getrtalist ORB Core 3. register 6. updatetrafficinfo 1. register 5. register & startretrieveinfo :: :: For For :: Manager:: Manager:: :: 2. RTA List List Meter Manager List Analysis Application Monitor Manager Figure 6. Interactions among CORBA objects a lot work in the context network control and management has been done in the academic and industrial domains. Examples are [1], [7] and [8]. Their experiences and achievements show that CORBA is a suitable technological framework for network management. 3.1 IDL interfaces Tables 2, 3 and 4 define IDL interfaces between the three modules the IRM-based scheme, which are abstracted from the interactions described in Section 2.2. 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 Table 2. Interfaces module 3.2 Interactions among CORBA objects Figure 6 shows interactions among CORBA objects. These objects correspond to the client-side and server-side objects, i.e. proxy object and implementation object respectively, the interfaces defined in Tables 2, 3 and 4. module MONf //MONitor Interface For f void register ( in :: ansref);g; Interface f void register ( in RTFM:: mngref); void startretrieveinfo(); g; g; //End MON module Table 3. Interfaces monitor module module RTFM f //Real-Time Flow Monitoring Struct Recordf...;g; Typedef sequence hrecordi Records; Interface f void updatetrafficinfo ( in Records records);g; g; //End RTFM module Table 4. Interfaces manager module The interactions can be summarized in the following six steps. (1) Setting up a new invokes the registration its reference, type ::, with each monitor through the proxy object For. Correspondingly, the implementation object For adds 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 corresponding reference, type. (3) This operation is done through the proxy ::. Accordingly, the implementation object the :: adds the attributes and reference to its RTA list. (4) An analysis application

invokes the operation getrtalist to get the RTA list through proxy object and implementation object ::. Then the manager can select one real-time flow from the RTA list to monitor. (5) This causes the analysis application to register its reference, type RTFM::, with relevant monitors. This is achieved through the proxy object. The corresponding implementation object adds the manager s reference to its manager list. (6) Lastly, these monitors use the references, type RTFM::, to locate all managers and update traffic information to them. 3.3 Sample pages Monitor 3. In addition, from Figure 8, the cause such degradation can be further located, i.e. the network segment between Monitor 1 and Monitor 2. NM_1 NM_2 Internet Sender & Monitor 1 _1 _2 Monitor 2 ATM LAN Gateway Ethernet Figure 9. Testbed Receiver Monitor 3 4 CONCLUSION From Monitor 1 From Monitor 3 QoS degradation Figure 7. Sample page from Domain 1 This paper presented a new scheme, the IRMbased scheme, for real-time traffic flow monitoring. With this scheme, when monitoring a real-time flow, a network manager can locate relevant monitors and retrieve traffic information from them simultaneously. By consolidating traffic information from these monitors embedded in different network segments, not only the end-to-end QoS but also the QoS distribution this flow can be derived. In addition, such monitoring can be performed in multiple network management domains. Moreover, CORBAbased implementation this scheme has also been introduced to show its feasibility. References From Monitor 1 From Monitor 2 From Monitor 3 Figure 8. Sample page from Domain 2 Figures 7 and 8 show two sample pages from two different network manager programs, NM 1and NM 2 in Figure 9. The two sample pages show the traffic graphs a real-time flow monitored by the two network managers, which started monitoring the flow at different time. Figures 7 and 8 also show that there is QoS degradation between Monitor 1 and [1] Y. Jiang, C.K. Tham and C.C. Ko, A Webbased Real-time Traffic Monitoring Scheme Using CORBA, MMNS 98, France, Nov. 16-18, 1998. [2] G. Pacifici and R. Stadler, An Architecture for Performance Management Multimedia Networks, IFIP/IEEE ISINM, May 1995. [3] H. Schulzrinne et al., RTP: A Transport Protocol for Real-Time Applications, RFC1889, 1996. [4] XACCT, XACCT Systems, http//www.xacct.com/ [5] S. Waldbusser, Remote Network Monitoring Management Information Base Version 2 using SMIv2, RFC2021, 1997. [6] OMG, The Common Object Request Broker: Architecture and Specification, v2.0, July 1996. [7] S. Mazumdar, and K. Swanson, WEB based management - CORBA/SNMP gateway approach, 7th IFIP/IEEE DSOM Italy, October 28-30, 1996. [8] OMG, Interworking between CORBA and TMN System, RFP, Sept. 1997.