QOS DISTRIBUTION MONITORING FOR PERFORMANCE MANAGEMENT IN MULTIMEDIA NETWORKS

Transcription

1 QOS DISTRIBUTION MONITORING FOR PERFORMANCE MANAGEMENT IN MULTIMEDIA NETWORKS Yumng Jang, Chen-Khong Tham, Ch-Chung Ko Department Electrcal Engneerng Natonal Unversty Sngapore Sngapore Emal: {engp7450, eletck, ABSTRACT In multmeda networks, performance management s requred to ensure that the agreed qualty servce (QoS) s sustaned. To detect possble QoS degradaton and locate the cause the degradaton, end-to-end QoS montorng s not suffcent. Instead, QoS dstrbuton, the dstrbuton QoS experenced by a real-tme flow n dfferent network segments, should be montored. However, few current montorng systems can provde QoS dstrbuton montorng. Ths paper presents two schemes, relevant montor (RM) based and mproved relevant montor (IRM) based, for QoS dstrbuton montorng. Wth these schemes, when montorng a real-tme flow, a network manager can locate relevant montors that are meterng the flow. By retrevng and consoldatng traffc nformaton from these montors embedded n dfferent network segments, not only the end-toend QoS but also QoS dstrbuton the flow are derved. In addton, wth the IRM-based scheme, QoS dstrbuton montorng can be performed n multple network management domans. In ths paper, CORBA-based mplementaton for the IRM-based scheme s also ntroduced to show ts feasblty. KEYWORDS: NETWORK MANAGEMENT, PERFORMANCE MANAGEMENT, QUALITY OF SERVICE, QOS MONITORING, CORBA-BASED MANAGEMENT

2 1. INTRODUCTION Provdng qualty servce (QoS) guarantees s a prncpal requrement for multmeda networks. To mantan the agreed QoS, t s not suffcent to just commt resources because QoS degradaton s a common event and ten unavodable. Any fault or weakenng the performance a network element may result n the degradaton the contracted QoS. Thus, performance management s requred to ensure that the contracted QoS s sustaned [1]. To date, whle a consderable amount research has been done wthn QoS management provson such as QoS control [2] and QoS archtecture [3], one lmtaton remans. The lmtaton s the lack dstrbuted montorng mechansms to support QoS guarantees [3]. The ntenton QoS montorng research s to allow a network manager to track the ongong QoS, compare the montored QoS aganst the expected performance, detect possble QoS degradaton, and then tune network resources accordngly to sustan the delvered QoS [3]. Compared wth traffc montorng n tradtonal data networks, to provde QoS montorng n multmeda networks mposes the followng problems. Frstly, QoS montorng requres applcaton-level montorng. In tradtonal networks, the montored objects traffc montorng are bascally the total traffc nto and out the devce that a montorng agent (e.g. SNMP [4] agent) attaches to. Thus, tradtonal traffc montorng s usually lmted to the network-layer n the Open Systems Interconnect (OSI) model. In contrast, n multmeda networks, real-tme applcatons wth dfferent QoS requrements are an mportant part network traffc and the montored objects are real-tme flows. Thus, applcaton-level montorng [5] that performs montorng above the network-layer s requred. S flow n 1 n j n k Q n j Q Fgure 1. QoS dstrbuton montorng R Secondly, t s QoS dstrbuton that should be montored rather than end-to-end QoS. Consder the example shown n Fgure 1. Q denotes the QoS experenced by flow n network segment n j ; Q denotes the end-to-end QoS seen by flow ; and P = n,..., n,..., n ) s the set ( 1 j k network segments that flow passes. Then, we have Q = F( Q,..., Q ). Ths equaton means n1 nk that the end-to-end QoS flow s a functon the QoS experenced by the flow n each network segment. Gven that all, n P, are known, Qn j t s easy to derve Q. However, f only the endto-end QoS Q s known, t s not possble to determne Q n each segment. In order to detect n j possble QoS degradaton and locate the cause the degradaton, not only does the network manager need to know the Q, but also the Q, n j P. Thus, end-to-end QoS montorng s not suffcent. Instead, QoS dstrbuton Q,..., ) should be montored. ( n Q 1 n k Thrdly, snce dfferent real-tme flows usually cross dfferent network segments, the montors nvolved n QoS montorng these flows may be dfferent. Thus, when montorng a certan realtme flow, traffc nformaton needs to be collected from ts relevant montors that are meterng the flow. Lastly, snce the network manager may be moble, for example Web-based, the scheme adopted for QoS montorng should provde mechansms for the moble manager to locate relevant montors and vce versa. Over the past few years, several mechansms have been proposed for applcaton-level montorng and QoS montorng [5-11]. Waldbusser [5], Brownlee, Mlls and Ruth [6], and Brownlee [7] consdered the problem applcaton-level montorng and showed that applcaton-level montorng s possble and feasble. Mourelatou, Bouloutas and Anagnostou [8] proposed an agent-based approach to dentfyng QoS problems based on the nformaton collected by all agents that were assumed to be capable provdng endto-end QoS montorng. Ehab Al-Shear [9] proposed an event-drven dynamc montorng approach for multmeda networks. An event mght be the QoS degradaton a multmeda applcaton. Dfferent from [8], ths approach requres that pror to any montorng operaton, a system manager must descrbe the physcal or j n j n j

3 geographcal dstrbuton the multmeda applcaton that the manager ntends to montor. Chen et al. [10] ntroduced a stware approach to montorng end-to-end QoS n ATM networks. A key requrement for ths approach s that a parallel test connecton wth the same route and QoS class s set up to test the selected user connecton. In addton, another possble scheme for end-to-end QoS montorng s to use RTCP montors [11] to retreve end-to-end traffc nformaton from RTCP messages. Generally, [5-11] have proposed several QoS montorng approaches from dfferent perspectves and showed that QoS montorng can be acheved f certan requstes or assumptons are satsfed. However, none these mechansms addresses the problem QoS dstrbuton montorng drectly and no means has been provded for a network manager to locate relevant montors. Ths paper presents two schemes, the relevant montor (RM) and mproved relevant montor (IRM) based schemes, for QoS dstrbuton montorng. Wth these schemes, when montorng a real-tme flow, relevant montors the flow can be located and thus traffc nformaton can be retreved from them. Based on the retreved traffc nformaton, network managers may control the network to ensure that the QoS provded to the flow s sustaned. In addton, wth the IRM-based scheme, these operatons can be performed by network managers from dfferent network management domans smultaneously. The rest ths paper s organzed as follows. Secton 2 presents the RM-based and IRM-based schemes for QoS dstrbuton montorng. Secton 3 descrbes the CORBA-based mplementaton the IRM-based scheme. Secton 4 presents a qualtatve comparson among montorng mechansms revewed so far and the two proposed schemes. Secton 5 concludes the paper. 2. QOS DISTRIBUTION MONITORING Ths secton presents two relevant montor based schemes for QoS dstrbuton montorng. They are the relevant montor (RM)-based scheme and mproved relevant montor (IRM)-based scheme. In these schemes, when montorng a real-tme flow, traffc nformaton s collected from relevant montors that are meterng the flow n dfferent network segments. By consoldatng the nformaton from these montors, not only can end-to-end QoS the flow be montored, but the QoS dstrbuton n dfferent network segments for ths flow can also be derved. In addton, n the IRM-based scheme, such collecton can be done from several network management domans, so that network managers from all network management domans can montor the QoS dstrbuton the real-tme flow. Analyss applcaton (Network manager) Analyss applcaton Montor () 2.1 Modules Fgure 2: RM-based scheme Doman 1 Montor ()... Montor (j) Doman n Analyss applcaton Fgure 3: IRM-based scheme Montor (j) Fgures 2 and 3 show the structure RM-based scheme and IRM-based scheme respectvely. In both schemes, the structure comprses three modules: the analyss applcaton module, the montor module and the real-tme applcaton name server () module. An analyss applcaton s usually a part the network manager program that analyzes traffc nformaton and provdes analyss results such as QoS related parameters and QoS dstrbuton certan real-tme flows to users. In the IRM-based scheme, there can be more than one analyss applcatons from dfferent network management domans. The montors (e.g. RTFM [6] montors) resdng n dfferent network segments provde real-tme measurement real-tme flows. When a real-tme flow s selected for montorng, only the montors that are meterng ths flow wll be nvolved n ts traffc nformaton collecton and reportng. A real-tme flow s dentfed by ts source and destnaton addresses at varous layers the OSI

4 model [6], whch may nclude ts source and destnaton IP addresses and transmsson port number (e.g. UDP port). Each montor provdes traffc nformaton (such as numbers packets and bytes) the flow to analyss applcatons that have selected ths flow to montor. The montor module n the IRM-based scheme s slghtly dfferent from that n the RM-based scheme. In the IRM-based scheme, each montor mantans a lst generated automatcally by the regstraton each new. The montor uses the lst to fnd wth whch s the montor should regster metered real-tme traffc attrbutes and correspondng references. In contrast, n the RM-based scheme, there s only one and each montor s pre-confgured to know where the s. The module provdes a mechansm to brdge montors and analyss applcatons, whch enables analyss applcatons to locate relevant montors and retreve traffc nformaton from them. Whle the RM-based scheme has only one for the network, there can be more than one n the IRM-based scheme, each whch belongs to a dfferent management doman and s made known only to ts own doman. In addton, nstead pre-confguraton n the RMbased scheme, n the IRM-based scheme, each new must make tself known to all montors by regsterng wth them. Despte the above dfference, each n the IRM-based scheme functons lke the only n the RM-based scheme. Each mantans a real-tme applcaton (RTA) lst from whch an analyss applcaton can fnd the references relevant montors that are montorng certan flows and hence locate and retreve traffc nformaton from them. Fgure 4 and Table 1 llustrate an example the RTA lst. In Fgure 4, there are two real-tme 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 fve network devces wth montors embedded. Then, the RTA lst generated n the wll look lke Table 1. Flow A Real-tme Flows (sender, recever) Flow A (Snd A, Rcv A) Flow B (Snd B, Rcv B) 2.2 Interactons Relevant Montors S1, SW, S2 S3, SW, S4 Table 1: RTA lst n Fgures 2 and 3 also show nteractons between modules the RM-based scheme and the IRMbased scheme respectvely. In the RM-based scheme, all montors are pre-confgured to know the only. In the IRM-based scheme, a new regsters ts reference to the lst n each montor. The montor wll use the references to locate the s. Durng the montorng, montors regster attrbutes real-tme flows and ther references wth all s. In the IRM-based scheme, the n each network management doman s used by analyss applcaton(s) wthn ts same doman to fnd whch real-tme flows are beng montored and whch montors are meterng the same flows. An analyss applcaton retreves the references relevant montors from the RTA lst n the so as to montor a real-tme flow. Once the analyss applcaton locates the relevant montors a real-tme flow, t adds ts reference to a network manager lst n each montor. Ths lst stores the references all analyss applcatons that are collectng traffc nformaton the same real-tme flow. Then, the montor uses these references to locate correspondng analyss applcatons and report traffc nformaton to them. 2.3 Trade-f There are the followng three prncpal dfferences between the RM-based scheme and IRM-based scheme. Snd A S1 S2 Flow B SW Snd B S3 S4 Fgure 4: A sample network Rcv A Rcv B 1. In the RM-based scheme, there s only one common for the network, whle n the IRM-based scheme there are more than one, each for a dfferent management doman. 2. In the RM-based scheme, pror to all QoS montorng operatons, each montor s

5 confgured to know where the only s. In contrast, n the IRM-based scheme, each regsters ts reference wth all montors durng run-tme. 3. In addton, n the IRM-based scheme, each montor can report traffc nformaton to multple analyss applcatons belongng to dfferent network management domans. These dfferences contrbute to the mprovement the IRM-based scheme over the RM-based scheme. Wth the IRM-based scheme, not only can relevant montors be found and the traffc nformaton retreved, but these operatons can also be performed by analyss applcatons from dfferent management domans. There s a tradef between the mprovement and the system complexty. The RM-based scheme s less complex but only supports one network management doman. The IRM-based scheme s more flexble but more complex. Thus, when there s only one management doman, the RM-based scheme s preferred. However, f more than one management domans exst n the network, the adopted scheme should be IRM-based. 3. CORBA-BASED IMPLEMENTATION OF IRM-BASED SCHEME module { // Real-Tme Applcaton Name Server Struct RtAttrbutes {...}; Struct RtItem { Montor::ForManager monref; RtAttrbutes trattr;}; Typedef sequence <RtItem> RtaLst; Interface ForManager { vod getrtalst ( out RtaLst rtalst ); }; Interface ForMontor { vod regster ( n RtAttrbutes rtattr, n Montor::ForManager montorref ); }; }; // End module Table 2: Interfaces module module Montor { // Montor Interface For { vod regster ( n ::ForMontor ansref ); }; Interface ForManager { vod regster ( n Manager::ForMontor mngref ); vod setupdateinterval ( n long nterval ); }; }; // End Montor module Table 3: Interfaces Montor module module Manager { // Manager Struct Record {...}; Typedef sequence <Record> Records; Interface ForMontor { vod updatetraffcinfo ( n Records records );}; }; // End Manager module Table 4: Interface Manager module 3.1 IDL Interfaces The Common Object Request Broker Archtecture (CORBA) [13] fers an envronment for buldng dstrbuted object-orented applcatons. Its Interface Defnton Language (IDL) and dfferent programmng language mappngs to nterfaces defned by the IDL enable clent/server objects to nteract among dfferent Object Request Brokers (ORBs). Recently, researchers have adopted CORBA technque n network management [12,14-20]. Ther experences and achevements show that CORBA s a sutable technologcal framework for network management. For smplcty, ths secton only ntroduces the CORBA-based mplementaton the IRM-based scheme. In partcular, ts IDL nterfaces and correspondng object nteractons are descrbed. The CORBA-based mplementaton the RMbased scheme s smlar to ths and can be found n [12]. Tables 2, 3 and 4 defne IDL nterfaces between the three modules the IRM-based scheme. These IDL nterfaces are abstracted from the nteractons descrbed n Secton Interactons among CORBA objects Fgure 5 shows the nteractons among CORBA objects, whch correspond to the clent-sde and server-sde objects the nterfaces defned n Tables 2, 3 and 4. In the followng descrpton, nterface I n module M wll be wrtten as M::I. The nteractons can be summarzed n the followng sx steps. (1) Settng up a new nvokes the regstraton ts reference, type ::ForMontor, to each montor through the clent object Montor::For. Correspondngly, the mplementaton object Montor::For adds the reference to the lst n the montor. (2) Detectng a new real-tme flow causes the regstraton correspondng parameters from a montor to all s that are n the montor's lst.

6 3. regster 1. regster 4. getrtalst ORB Core 6. updatetraffcinfo 5. regster :: ForManager :: ForMontor Clent Montor:: For Montor:: For Clent :: ForMontor Clent Manager:: ForMontor Montor:: ForManager Clent Montor:: ForManager Manager:: ForMontor Clent :: ForManager 2. RTA Lst Lst Meter Manager Lst Analyss Applcaton Montor Manager Fgure 5: Interactons among CORBA objects The parameters nclude traffc attrbutes, type ::RtAttrbutes, and the reference the mplementaton object Montor::ForManager. (3) Ths operaton s done through the clent object ::ForMontor. Accordngly, the mplementaton object the ::ForMontor adds the attrbutes and reference to ts RTA lst. (4) A network manager nvokes the operaton getrtalst to get the RTA lst through the clent and mplementaton objects ::ForManager. The manager selects one real-tme flow from the RTA lst to montor. As n the RM-based scheme, the manager fnds the references, type Montor::ForManager, relevant montors from the RTA lst and starts to retreve traffc nformaton from them. Ths results n the generaton several groups CORBA objects n the manager. Each group, responsble for communcatng wth one montor, conssts a clent object Montor::ForManager and an mplementaton object Manager::ForMontor. (5) After these steps, the manager regsters the reference the mplementaton object Manager::ForMontor wth the correspondng montor. Ths s acheved through the clent object Montor::ForManager. The mplementaton object Montor::ForManager n the montor adds the manager's reference to ts manager lst. In addton, the nterval for the montor to report traffc nformaton s set by the operaton setupdateinterval. (6) Lastly, each montor uses the references, type Manager::ForMontor, n ts manager lst to locate all managers and update traffc nformaton to them perodcally n the requred nterval. 3.3 Sample pages Fgure 6 and Fgure 7 show two sample pages from dfferent network manager programs, whch correspond to two network management domans: Doman 1 and Doman 2 n Fgure 8. The two sample pages show the traffc graphs a realtme flow montored by the two network managers, whch started montorng the flow at dfferent tmes. Fgure 6 and Fgure 7 also show that there s QoS degradaton between Montor 1 and Montor 3. In addton, from Fgure 7, the cause the degradaton can be further located,.e. the network segment between Montor 1 and Montor 2. Clearly, through the above-mentoned steps, network managers from dfferent domans can locate and communcate wth relevant montors smultaneously, and the montors can report traffc nformaton to these managers drectly. Montored Traffc From Montor 1 Traffc Average From Montor 3 QoS Degradaton Fgure 6: Sample page from Doman 1

7 From Montor 1 From Montor 2 From Montor 3 Fgure 7: Sample page from Doman 2 Table 5 presents a comparson current montorng mechansms revewed n Secton 1 and the two new QoS dstrbuton montorng schemes descrbed n ths paper. Except for SNMP [4], the others provde mechansms for QoS montorng from dfferent perspectves; SNMP [4] can only provde network-layer montorng and s thus not sutable for QoS montorng. We can vew other mechansms at three levels: measurement level, QoS montorng level, and hgher analyss level. The measurement level, ncludng RMON-2 [5] and RTFM [6, 7], s capable performng applcaton-level montorng and provdng montored nformaton to the QoS montorng level. The QoS montorng level comprses the RTCP-based scheme, the RM-based and IRM-based schemes and the scheme proposed by Chen et al. [10]. Except for Chen et al. [10], schemes at ths level are responsble for fndng relevant montors for each Doman 1 Manager 1 1 Sender & Montor 1 Montor 2 Recever & Montor 3 Internet Manager 2 Doman 2 2 ATM Gateway Ethernet Fgure 8: Testbed Montorng NLM ALM Route EtE QM QoS-DM Mult-NMD Mechansm Fndng SNMP [4] Supported Not Supported Supported RMON-2 [5] Supported Supported Supported RTFM [6,7] Supported Supported Supported RTCP [11] - Requred - Supported Not Supported Supported RM-based - Requred Supported Supported Supported Not Supported IRM-based - Requred Supported Supported Supported Supported Chen et al. [10] - - Requred Supported Not Supported - Mourelatou et al. [8] - - Requred Requred - - Ehab Al-Shaer [9] - - Requred Requred Requred - -: not applcable/not mentoned NLM: network-layer montorng ALM: applcaton-level montorng EtE QM: end-to-end QoS montorng DM: dstrbuton montorng NMD: network management doman Table 5: Comparson montorng mechansms 4. COMPARISON real-tme flow. They support end-to-end QoS montorng as well as QoS dstrbuton montorng

8 except for Chen et al. [10] and the RTCP-based scheme. In addton, they can also detect possble QoS degradaton. The hgher analyss level uses the results generated by the QoS montorng level to perform further analyss or operatons, such as dentfyng QoS problems n Mourelatou et al. [8] and dynamcally adjustng the montorng system n Ehab Al-Shaer [9]. Generally, although the measurement level does not provde QoS montorng drectly, t collects all necessary traffc nformaton for the upper levels. The QoS montorng level uses the nformaton from the measurement level to fnd the route each montored real-tme flow, locates relevant montors meterng the flow, and traces the ongong QoS and ts dstrbuton. The hgher analyss level provdes further analyss or operatons based on nformaton from the QoS montorng level. 5. CONCLUSIONS Provdng sustaned QoS to real-tme applcatons mposes requrements on performance management. We have argued that performance management multmeda networks requres QoS dstrbuton montorng rather than end-toend QoS montorng. Also, we have presented two schemes, the RM-based and IRM-based schemes, for QoS dstrbuton montorng. In addton, a CORBA-based mplementaton the IRM-based scheme has been ntroduced to show ts feasblty. Because the mplementaton was a prototype and the scale the testng system was small, many ssues reman open, such as the scalablty the montorng system and the amount management traffc caused by the montorng. Nevertheless, from the prototype mplementaton, we can have the followng conclusons. Wth the RM-based and IRM-based schemes, a network manager can locate relevant montors the flow that has been selected to montor and retreve traffc nformaton the flow from them. By consoldatng such nformaton, not only the endto-end QoS but also the QoS dstrbuton the flow can be derved. Based on these schemes, a network manager can locate the cause possble QoS degradaton and may thus control networks accordngly. In addton, wth the IRM-based scheme, QoS dstrbuton montorng can be performed n multple network management domans. Moreover, the two proposed schemes are per-flow based, whch s dentfed by ts source and destnaton addresses. Snce these addresses are not lmted to certan layers the OSI model, the two proposed schemes should also be sutable for montorng flow aggregates f flows n one aggregate have the same source and destnaton addresses at a certan OSI layer. REFERENCES [1] G. Pacfc and R. Stadler, An Archtecture for Performance Management Multmeda Networks, IFIP/IEEE Internatonal Symposum on Integrated Network Management, May [2] C. M. Aras, J. F. Kurose, D. S. Reeves and H. Schulzrnne, Real-Tme Communcatons n Packet- Swtched Networks, Proceedngs the IEEE, v82 n1, Jan [3] C. Aurrecoechea, A.T. Campbell and L. Hauw, A Survey QoS Archtectures, Multmeda Systems Journal, v6 n3, , [4] J. Case, M. Fedor, M. Schfstall and J. Davn, A Smple Network Management Protocol (SNMP), RFC1157, May [5] S. Waldbusser, Remote Network Montorng Management Informaton Base Verson 2 usng SMIv2, RFC2021, Jan [6] N. Brownlee, C. Mlls and G. Ruth, Traffc Flow Measurement: Archtecture, RFC 2063, [7] N. Brownlee, Traffc Flow Measurement: Experences wth NeTraMet, RFC 2123, [8] K. E. Mourelatou, A. T. Bouloutas and M. E. Anagnostou, An Approach to Identfyng QoS Problems, Computer Communcatons n17, , [9] Ehab Al-Shaer et al., Dynamc Montorng Approach for Mult-pont Multmeda Systems, 2 nd IFIP/IEEE MMNS'98, France, Nov [10] T. M. Chen et al., INQIRE: A Stware Approach to Montorng QoS n ATM Networks, IEEE Network, Mar. - Apr [11] H. Schulzrnne, S. Casner, R. Frederck and V. Jacobson, RTP: A Transport Protocol for Real- Tme Applcatons, RFC1889, 1996.

9 [12] Y. Jang, C. K. Tham and C. C. Ko, A Web-based Real-tme Traffc Montorng Scheme Usng CORBA, 2 nd IFIP/IEEE MMNS'98, France, Nov [13] OMG, The Common Object Request Broker: Archtecture and Specfcaton, v2.0, July [14] OMG, Interworkng between CORBA and TMN System, RFP, [15] OMG, JIDM Interacton Translaton - SNMP Part: Fnal Submsson to OMG's CORBA/TMN Interworkng, RFP, May [16] S. Mazumdar and K. Swanson, WEB Based Management - CORBA/SNMP Gateway Approach, IFIP/IEEE DSOM, Italy, [17] A. A. Lazar, S. K. Bhonsle and K. S. Lm, A Bndng Archtecture for Multmeda Networks, Journal Parallel & Dstrbuted System, vol. 30, no. 2, [18] G. Chen, M. Nevlle and Q. Kong, Dstrbuted Network Management Usng CORBA/TMN, 7th IFIP/IEEE DSOM, [19] S. Maffes, and D. C. Schmdt, Constructng Relable Dstrbuted Communcaton Systems wth CORBA, IEEE Communcatons Magazne, Feb [20] J. Pavon, J. Tomas, Y. Bardout and L. H. Hauw, CORBA for Network and Servce Management n the TINA Framework, IEEE Communcatons Magazne, March 1998.