A QOS FRAMEWORK DESIGN BASED ON DIFFSERV AND SNMP FOR TACTICAL NETWORKS

Transcription

1 A QOS FRAMEWORK DESIGN BASED ON DIFFSERV AND SNMP FOR TACTICAL NETWORKS Bong Chan Kim +, Youngchul Bang, Yongi Kim, Jae Young Lee +, Dong Gu Kwak, Hwang Soo Lee, and Joong Soo Ma ++ + Samsung Electronics, Suwon, South Korea School of Electrical Engineering & Computer Science, KAIST, Daejeon, South Korea ++ School of Engineering, ICU, Daejeon, South Korea {eeman, bang, artist, goodljy, dgkwak}@mcl.kaist.ac.kr, hwanglee@ee.kaist.ac.kr, jsma@icu.ac.kr ABSTRACT In the theater of war, mission-critical information is delivered over tactical networks, and a brigade dynamically conducts close combats and tactical operations on the basis of the military information. Therefore, the quality of service (QoS) of military information should be guaranteed to successfully perform tactical operations in the battle field. In this paper, the concern is a QoS framework design, not QoS algorithms such as packet scheduling and buffer management. As existing studies on QoS framework have focused on wired and fixed networks such as the Internet, it is difficult to apply them to tactical environment where network topology dynamically changes. Currently, applying commercial technologies to military communication system is a key issue due to low development cost and short development time. Thus, a tactical QoS framework is designed based on differentiated service (DiffServ) and simple network management protocol (SNMP) in this paper. The proposed QoS framework consists of tactical QoS information exchange, QoS module configuration, and DiffServ code point (DSCP) marking and is suitable for dynamic tactical environment. To test the operation of the proposed QoS framework, we simply established a tactical QoS framework testbed in real environment. Test results show that, by the proposed QoS framework, packets with a high priority experiences a shorter delay and a lower delay jitter than packets with a low priority. I. INTRODUCTION In the theater of war, mission-critical information is delivered over tactical networks, and a brigade dynamically conducts close combats and tactical operations based on the military information. Therefore, the quality of service (QoS) of military information should be guaranteed to successfully perform tactical operations in the battle field. Among many research areas, the concern on this paper is a QoS framework design. A number of studies on QoS framework have been accomplished for wired and fixed networks such as the Internet. Typically, there are differentiated service (DiffServ) and policy-based management methods. However, because existing works have focused on wired and fixed networks, they are not suitable for dynamic tactical networks. In addition, existing works were accomplished without taking military requirements into account, and thus it is difficult to apply them to tactical environment. Currently, applying commercial technologies to military communication system is a key issue due to low development cost and short development time. Thus, a tactical QoS framework is designed based on DiffServ and simple network management protocol (SNMP) in this paper. The proposed QoS framework consists of tactical QoS information exchange, QoS module configuration, and DiffServ code point (DSCP) marking and is suitable for tactical environment. To test the operation of the proposed QoS framework, we simply establish a tactical QoS framework testbed. Test results show that packets with a high priority have a shorter round trip delay and a lower round trip delay jitter than packets with a low priority. The remaining sections of this paper are presented as follows: previous works related to tactical QoS framework are presented in Section II. Tactical QoS considerations are described in Section III. We propose a tactical QoS framework based on DiffServ and SNMP in Section IV and outline a method to implement the proposed QoS framework in Section V. In Section VI, a tactical QoS framework testbed and test results are given. Finally, we make a conclusion in Section VII. II. RELATED WORKS DiffServ [1], [2] is one of typical QoS frameworks for wired and fixed networks such as the Internet. In the DiffServ, nodes are classified into host, edge router (ER), and core router (CR). ERs and CRs perform a differentiated service code point (DSCP) marking and a packet forwarding in order to guarantee the QoS of traffic flows, respectively. As the DiffServ is originally designed for fixed networks, nodes perform special roles and their roles are fixed. Thus, the conventional DiffServ /08/$ IEEE 1 of 7

2 MeR Division (DLL) MeR Table 1 DSCP values according to combination of traffic types and precedence Brigade (BRLL) H Company (CLL) MeR Platoon (PLL) H Battalion (BLL) Figure 1. Tactical network architecture MeR Traffic precedence Traffic type DSCP value Flash (1) Real-time (1) 0x28 Flash (1) Non-real-time (2) 0x30 Immediate (2) Real-time (1) 0x50 Immediate (2) Non-real-time (2) 0x58 Priority (3) Real-time (1) 0x78 Priority (3) Non-real-time (2) 0x88 Routine (4) Don t care (any) 0x00 tactical networks. Besides, detailed technical approaches were not studied extensively. is not suitable for tactical network with a multi-layered architecture and a dynamic network topology. Recently, a number of QoS testbeds have been developed. For example, the QBone [3] established a large-scale testbed using Diffserv and bandwidth broker. Moreover, in [4], J. Maniyeri et al. developed a Linux software router based on common open policy service (COPS) [5], [6], and it supports policy-based traffic control. However, the QoS testbeds are for wired and fixed networks, not for mobile wireless networks such as tactical networks. In [7], K. S. Phanse et al. proposed a method to apply policy-based management to mobile ad hoc network (MANET). Then, the authors took only general MANET into account, and thus it is difficult to apply their proposed method to tactical network with a multi-layered architecture. In [8], J. L. Kingston introduced a guideline about military QoS research; as military traffics contain mission-critical information, both traffic type and precedence should be considered, when handling military traffics in the scheduler. In addition, in [8], J. L. Kingston suggested a queuing and scheduling algorithm based on the above guideline. Then, the proposed method is for fixed network such as military backbone network. In [9], M. Kwiatkowski introduced a military-oriented QoS framework based on COPS and DiffServ (M-QoS). By the policy-based QoS framework, command center can control traffics throughout military network. In the M-QoS, it is possible to deal with military information according to the importance of traffic via Diffserv. However, as the target network of the M-QoS is military core network, the M-QoS is not suitable for dynamic III. TACTICAL QOS CONSIDERATIONS When designing a tactical QoS framework, major considerations are presented in this section. A. Tactical Network Architecture A division-level tactical structure consists of division, brigade, battalion, company, and platoon. In [10], we proposed tactical network architecture based on the division-level tactical structure. As shown in Fig. 1, the tactical network architecture consists of five layers; platoon-level layer (PLL), company-level layer (CLL), battalion-level layer (BLL), brigade-level layer (BRLL), and division-level layer (DLL). The detailed explanation of each layer refers to the literature [10]. As shown in Fig. 1, the tactical network has a multi-layered architecture, and joint nodes connect adjacent two layers. For example, header of mobile node () in Fig. 1 connects between PLL and CLL. As nodes and partial networks in a tactical network systematically move according to tactical operations, the range of their movements is limited. In [10], we described major movement patterns in detail. Therefore, when designing a tactical QoS framework, dynamic network topology and hierarchical multi-layered architecture should be taken into account. B. Military Traffic and DSCP Current IP networks can support a variety of real-time and non-real-time applications via various QoS mechanisms [11]. What is missing in these commercial solutions is a precedence scheme which minimizes the probability of mission-critical calls and data streams being rejected or negatively affected by background traffic [8]. Therefore, when military traffics are handled in the packet scheduler, traffic type and precedence 2 of 7

3 should be considered simultaneously. In our tactical QoS framework, traffic types are classified into real-time and non-real-time traffics, and traffic precedence is distinguished to flash, immediate, priority, and routine. In this paper, all packets have DS fields, and nodes set the DSCP values of packets to the DS fields. Table 1 shows DSCP values according to the combination of traffic type and precedence in the tactical QoS framework. C. IntServ and DiffServ In general, the integrated service (IntServ) [12] and DiffServ [1] methods are used to support the QoS of traffic flows. The IntServ was proposed to support the strict QoS of traffic flows. Because each flow is controlled separately, the IntServ has a high processing overhead and a limited scalability. In the IntServ, a traffic flow is transmitted after a bandwidth for the traffic flow is first reserved via a signaling mechanism (path and resv messages exchange). Therefore, the IntServ results in a bandwidth waste due to the signaling mechanism. In the DiffServ, as traffic flows are aggregated to some classes such as expedited forwarding (EF), assured forwarding (AF), and best effort (BE), a heavy processing overhead and limited scalability resulting from controlling each traffic flow separately in the IntServ can be solved. In addition, a signaling mechanism for bandwidth reservation and maintenance is not required in the DiffServ. However, the DiffServ guarantees only the soft QoS of traffic flows by aggregating traffic flows to some classes. Tactical networks are established using the radio interfaces for flexibly deploying networks according to dynamic network situations. Tactical network components (hosts and routers) are portable, and they use a battery as a power supply. Therefore, when designing a tactical QoS framework, the efficiency of power and bandwidth should be considered simultaneously. Thus, the DiffServ is more suitable than the IntServ for tactical network environment. In the DiffServ, routers are fixed, and hosts are definitely distinguished with routers. In addition, routers are classified into ERs and CRs according to the roles of routers. Then, a tactical network has a hierarchical multilayered architecture, and network components dynamically move in a tactical network. Therefore, it is difficult to apply the conventional DiffServ to tactical environment without any modification. IV. TACTICAL QOS FRAMEWORK DESIGN In this section, we propose a tactical QoS framework that considers the tactical QoS considerations, which are Platoon Member PLL CLL BLL BRLL Multi-hop Multi-hop Multi-hop Single hop P C B BR Platoon Leader/ Company Members Company Leader/ Battalion Members Battalion Leader/ Brigade Members Figure 2. Tactical QoS network architecture Brigade Leader mentioned in Section III. The proposed QoS framework is designed based on DiffServ and SNMP. A. Tactical QoS Network Architecture Figure 2 shows the tactical network architecture from the tactical QoS framework perspective. As a tactical network was designed based on the tactical structure (platoon, company, battalion, and brigade), it has the hierarchical multi-layered architecture, as shown in Fig. 1. Each layer consists of a leader and members. The leader controls members and establishes a tactical QoS framework with members in the same layer. At the same time, it acts as members in a higher layer and is controlled by the leader in the higher layer. Figure 2 shows the member-leader relationship in the tactical QoS framework. By this hierarchical member-leader relationship, the multi-layers are combined to an integrated architecture. For example, a PLL consists of a platoon leader ( in Fig. 1) and platoon members (mobile nodes (MNs) in Fig. 1). In a PLL, the platoon leader controls the platoon members. The platoon leader has tactical QoS information for the PLL. The platoon members obtain the tactical QoS information from the platoon leader and configure their QoS modules according to the tactical QoS information. In a CLL, the company commander (mobile router () in Fig. 1) controls the platoon leaders ( in Fig. 1) as the leader of the CLL. The company commander has tactical QoS information for the CLL. The platoon leaders obtain the tactical QoS information from the company commander and configure their QoS modules according to the tactical QoS information. B. Tactical QoS Configuration In this section, a tactical QoS configuration procedure is described. The tactical QoS configuration procedure is accomplished by three steps: tactical QoS information exchange, QoS module configuration, and DSCP marking. Figure 3 shows the tactical QoS configuration procedure between member and leader. 3 of 7

4 DSCP marking program Member Part 5. DSCP marking information NET-SNMP Agent send_snmptrap() MIB Tree TIConfigTable MIB object 4. Configuration User Space QoS Modules (Hierarchical scheduling and DSCP marking part) Kernel Space 1. snmptrap (community: security) 2. Triggering 3. snmpset (tactical QoS configuraiton information ) Leader Part NET-SNMP Manager User Space Kernel Space recv_snmptrap() Military QoS configuration send_snmpset() Figure 3. Tactical QoS configuration procedure 1) Tactical QoS information exchange: In the initialization procedure, a member in a layer sends a request message to the leader in order to obtain tactical QoS information for the layer. Once the leader receives the request message from the member, the leader performs the member authentication procedure. If the member authentication is passed, the leader responds to the member with a reply message containing tactical QoS information. If tactical QoS information is changed, the leader can send the changed QoS information to the members in the layer. In the tactical QoS configuration, members and leader exchange tactical QoS information via SNMP [13]. As the SNMP is based on the agent-manager paradigm, it is suitable to apply the SNMP to tactical network with member-leader relationship. The tactical QoS information exchange procedure can be implemented by adding a new management information base (MIB) object related to tactical QoS information to existing MIB tree. The detailed QoS information exchange procedure is as follows: 1. A member in a layer sends a snmptrap message to the leader in the layer. The snmptrap message contains community information and object identification (OID). The community information is used to authenticate the member. The OID is used by the leader to identify a specific function requested by the member. 2. The leader receives the snmptrap message from the member and performs a specific function related to the OID. If the received OID corresponds to the tactical QoS information request, the leader obtains tactical QoS information from a military QoS configuration file and sends the tactical QoS information via a snmpset message. The snmpset input message contains the OID of a target MIB object as well as the tactical QoS information. 3. The member receives the snmpset message from the leader, and then it sets the tactical QoS information to the target MIB object specified by the OID in the snmpset message. 2) QoS module configuration: After a member receives tactical QoS information from the leader, it configures QoS module in kernel according to the tactical QoS information. The QoS module configuration is classified into the hierarchical scheduling and DSCP marking parts, as shown in Fig. 4. The hierarchical scheduling part contains packet filter and packet scheduler. After receiving a packet, the packet filter identifies the type and precedence from the DSCP value in the packet and stores the packet in the corresponding to the DSCP value. The packet scheduler selects a packet according to the traffic precedence and type, respectively and transmits the packet over the egress interface. The DSCP marking part contains DSCP marking information base (DMB), DSCP marking filter, and DSCP markers. The DMB is the collection of DSCP marking information for traffic flows in use. DSCP marking information contains destination IP address/port, DSCP value, and egress interface name. The DMB is used by the DSCP marking filter to obtain the DSCP value of a packet. The DSCP marking filter obtains the DSCP value of a packet by looking up the DMB with the destination IP address/port information in the header of the packet, and then the packet is sent to a corresponding DSCP marker. The DSCP marker marks the DS field of the packet to the specific DSCP value. The DS field of a packet is marked only by the DSCP marker of the traffic source (traffic generator). The value of DS field cannot be changed by intermediate nodes until the packet reaches the destination. Intermediate nodes perform only the packet forwarding according to the DSCP values of packets. Figure 4 shows the result of QoS module configuration. As shown in the figure, members perform the functions of ER and CR in the DiffServ. The hierarchical scheduling part corresponds to the function of CR and performs packet forwarding according to the DSCP values of packets. The DSCP marking part corresponds to the function of ER. When transmitting a packet, the DSCP marking part sets the DSCP value of the packet to the DS field. The allocated bandwidth for the DSCP marking and hierarchical scheduling parts can be adjusted statically or dynamically according to current network situation. 4 of 7

5 3) DSCP marking: In the DSCP marking part, DSCP marking information is required by the DSCP marking filter to find a proper DSCP value for a packet. Therefore, it is required to configure the DMB in the DSCP marking part. Even in the DiffServ standard [1], there are no comments about a method to configure the DMB. In general, there are two types of approaches: static and dynamic approaches. The static approach is a way to configure DSCP marking information in the initial QoS module configuration procedure. This approach is easy to implement, and it enables leader to control traffics. However, in the static approach, because leader should see all expected traffic information in advance, it is difficult to apply the static approach to dynamic tactical network in reality. In the dynamic approach, DSCP marking information is directly configured by traffic source before sending traffics. Traffic sources can select an appropriate DSCP value for traffic according to current operation situation, and it is impossible for leader to see all expected traffic information in advance. Therefore, the dynamic approach is suitable for tactical environment. However, in the dynamic approach, because traffic source configures DSCP values directly, it is difficult for leader to absolutely control traffics within its own control area. Military performs tactical operations according to systematic rules. Therefore, special rules for DSCP marking can also be standardized, and thus traffic control can be solved with respect to military working, not technology. The detailed rules for DSCP marking are out of the scope of this paper. The dynamic approach is used to configure DSCP marking information in our tactical QoS framework. The DSCP marking program in Fig. 3 provides DSCP marking information to the DMB in Fig. 4. V. TACTICAL QOS FRAMEWORK IMPLEMENTATION The tactical QoS framework presented in Section VI is implemented using the NET-SNMP software [14], DiffServ module [15], and DSCP marking program in Linux environment. A. Tactical QoS MIB in NET-SNMP We add a table-based MIB object denoted TIConfigTable to existing MIB tree. The TIConfigTable MIB object stores tactical QoS information. For the experimental purposes, the OID of is assigned to the TIConfigTable MIB object. A procedure to add the TIConfigTable MIB object to existing MIB tree consists of two steps as follows: First, the TIConfigTable MIB object is registered to existing MIB tree. After that, the handler functions for the Filter fw DSCP marking part DMB DSCP marking filter Hierarchical scheduling part Filter u32 tos Class 1 Class 2 Class 7 TIConfigTable MIB object are added to process SNMP commands such as snmpset and snmptrap. The NET- SNMP provides a mib2c program [16] to support these two steps. We added the TIConfigTable MIB object to existing MIB tree using the mib2c program. More detailed explanations about the mib2c program refer to the literature [17]. B. Member and Leader Application Programs To exchange tactical QoS information using the NET- SNMP [14], we developed member and leader application programs. Figure 3 shows the relationship between NET-SNMP agent and manger from the snmptrap operation perspective. As shown in Fig. 3, in the tactical QoS framework, NET- SNMP agent corresponds to the member part, and NET- SNMP manager to the leader part. A member part transmits a snmptrap message to a specific leader part by typing the following command: snmptrap v 1 c mcl : In this command, the v 1 represents that the version of SNMP is 1. The c mcl indicates that community corresponds to mcl. The community argument (mcl) is used for user authentication. The :162 indicates the IP address of a leader part and the port number of snmptrap daemon in the leader part. The 0 0 represents the coldstart. The warmstart can be used by replacing 0 0 with 1 0. The coldstart or warmstart means that a NET-SNMP agent is started or restarted, respectively. When a leader part receives a snmptrap message from a member part, the trap handler of the leader part performs a specific operation in order to reply to the snmptrap message from the member part. This operation is implemented by a shell script (tactical_qos_cfg.sh). According to the shell script, the leader part reads tactical QoS information from a military QoS configuration file (MQoSCfg.txt), and it sends the tactical QoS information to the member part via a snmpset message. Class 1 Class 2 Class 7 DSCP #1 DSCP #2 DSCP #7 Figure 4. Result of tactical QoS configuration Round Robin Priority 5 of 7

6 Leader olsrd essid: area11 channel: 1 Member olsrd essid: area12 channel: 6 Member Node1 Node2 Node / / / /24 1. snmptrap/snmpset: QoS configuration 2. snmptrap/snmpset: QoS configuration 3. dmtsource/dmtsink: cbr traffic ( = precedence 1, type 1) 3. dmtsource/dmtsink: ftp traffic ( = precedence 3, type 2) Figure 5. Tactical QoS framework testbed topology C. QoS Module Configuration After receiving tactical QoS information from a leader part via a snmpset message, the member part configures its QoS module in Linux kernel according to the tactical QoS information. The tactical QoS information consists of QoS commands, which corresponds to Linux traffic control (tc) commands [18]. In the set-processing of NET-SNMP, we implemented a method to apply tactical QoS commands to the Linux QoS module using the system() function. D. DSCP Marking Program DSCP marking program adds or deletes DSCP marking information to or from the DMB of the DSCP marking part in Fig. 4. The DSCP marking program is implemented using the libnetlink of iproute2 on Linux kernel 2.6 environments. The add and delete commands are as follows: add/del dev [dev name] dst [dest IP] dport [dest port] prec [traffic precedence] type [traffic type] VI. TACTICAL QOS FRAMEWORK TESTBED To test the operation of the proposed tactical QoS framework, we established a testbed, which consists of nodes 1, 2, and 3, as shown in Fig. 5. Three laptops are used to implement leader and members. The Fedora 5.0 is used as operating system, and it provides QoS module in Linux kernel. For the laptop to operate to leader or member we install and run the NET-SNMP and application programs introduced in Section V. In Fig. 5, node 1 has one IEEE b interface card. Node 2 has two interface cards; one (IEEE b) is used to communicate with node 1, and the other (IEEE g) is used to communicate with node 3. Node 3 has one IEEE g interface card. To easily make multi-hop between nodes 1 and 3, the channel between nodes 1 and 2 is orthogonal with that between nodes 2 and 3, and all nodes run the optimized link state routing protocol daemon (olsrd) [19]. As a result, two hop distances are physically made between nodes 1 and 3. Figure 6. Round trip delay of CBR packet Figure 7. Round trip delay jitter of CBR packets We test the operation of the tactical QoS framework based on DiffServ and SNMP. First, nodes 2 and 3 request tactical QoS information to node 1 via snmptrap messages. After receiving snmptrap messages from nodes 2 and 3, node 1 sends snmpset messages to nodes 2 and 3. The snmpset messages contain tactical QoS information. Nodes 2 and 3 store the tactical QoS information in the TIConfigTable MIB object, and then they configure QoS module in Linux kernel according to the tactical QoS information in the TIConfigTable MIB object. Next, node 3 sends both constant bit rate (CBR) packets with the size of 512 bytes at a rate of 1pkt/sec and file transport protocol (FTP) packets to node 1 for 100 seconds and measures the round trip delay and round trip delay jitter of CBR packets. To generate CBR and FTP packets and measure the performance of CBR packets, we use the dmt program, which was developed to evaluate the performance of protocols in our laboratory. In this test scenario, CBR packets have the precedence of 1 and type of 1, whereas FTP packets have the precedence of 3 and type of 2. That is, CBR packets have 6 of 7

7 higher priority than FTP packets. Before sending CBR and FTP packets, node 3 sets their priorities using the DSCP marking program as follows: For CBR traffic, add dev eth1 dst dport 1998 prec 1 type 1 For FTP traffic, add dev eth1 dst dport 1999 prec 3 type 2 Figures 6 and 7 show the round trip delay and round trip delay jitter of CBR packets between nodes 1 and 3 in test environment with the proposed QoS framework and without it, respectively. In the test environment with the QoS framework, because CBR packets are marked to a higher priority than FTP packets in the DSCP marking part, the CBR packets are handled faster than FTP packets in the hierarchical scheduling part. Thus, the round trip delay of the CBR packets maintains a low value without fluctuation during testing time, as shown in Figs. 6 and 7. VII. CONCLUSION In the battle field, because mission-critical information is delivered over tactical networks, the QoS of military information should be guaranteed to successfully perform tactical operations. In this paper, the concern is a QoS framework design based on the commercial technologies. We proposed a tactical QoS framework based on DiffServ and SNMP. In the proposed QoS framework, the tactical QoS information exchange is accomplished using SNMP, and the QoS module configuration and DSCP marking are performed using DiffServ. The proposed QoS framework is suitable for dynamic tactical network with a multi-layered architecture. The operation of the QoS framework was tested by establishing a tactical QoS framework testbed in the real environment. Test results showed that the QoS framework works well and packets with a high priority experience a shorter delay and a lower delay jitter than packets with a low priority by the proposed QoS framework. ACKNOWLEDGMENT This research was supported by the MIC (Ministry of Information and Communication), Korea, under the ITRC (Information Technology Research Center) and MMPC (Mobile Media Platform Center) support programs supervised by the IITA (Institute of Information Technology Advancement). In addition, this work was partially supported by Samsung Electronics. [2] S. Blake, D. Blake, M. Carlson, E. Davies, Z. Wang, and W. Weiss, An Architecture for Differentiated Services, IETF Networking Group, RFC 2475, Dec [3] B. Teitelbaum, S. Hares, L. Dunn, R. Neilson, V. Narayan, and F. Reichmeyer, Internet2 QBone: Building a Testbed for Differentiated Services, IEEE Network, vol. 13, no. 5, pp. 8-16, Sep.-Oct [4] J. Maniyeri, Z. Zhang, R. Pillai.R, and P. Braun, A Linux Based Software Router Supporting QoS, Policy Based Control and Mobility, in Proc. IEEE ISCC, vol. 1, pp , [5] D. Durham, RFC 2748: The COPS (Common Open Policy Service) Protocol, IETF Network Working Group, Jan [6] R. Yavatkar, RFC 2753: A Framework for Policy-based Admission Control, IETF Network Working Group, Jan [7] K. S. Phanse, L. A. DaSilva, and S. F. Midkiff, Design and Demonstration of Policy-based Management in a Multi-hop Ad Hoc Network, ELSEVIER Ad Hoc Networks vol. 3, no. 3, pp , May [8] J. L. Kingston, Dynamic Precedence for Military IP Networks, in Proc. IEEE MILCOM, vol. 1, pp , Oct [9] M. Kwiatkowski, A Concept of Defence Core Communication Infrastructure Supporting M-QoS, DSTO-TR [10] B. C. Kim, J. S. Lee, Y. C. Bang, J. K. Lee, H. S. Lee, and J. S. Ma, Design of IPv6 Tactical Network based on Commercial Technologies: Architecture, Routing, and Mobility Management, in Proc. IEEE ICACT, Feb [11] H. J. Chao and X. Guo, Quality of Service Control in High-Speed Networks, Wiley, [12] J. Wroclawski, The Use of RSVP with IETF Integrated Service, IETF Network Working Group, RFC 2210, Sep [13] J. Case, M. Fedor, M. Schoffstall, and J. Davin, Simple Network Management Protocol (SNMP), IETF Network Working Group, RFC 2362, Jun [14] NET-SNMP. [Online]. Available: [15] K. Wehrle, F. Pahlke, H. Ritter, D. Muller, and M. Bechler, Linux Networking Architecture Design and Implementation of Network Protocols in the Linux Kernel, Prentice Hall, [16] Mib2c General Overview. [Online]. Available: al_overview. [17] NET-SNMP-FAQ. [Online]. Available: MIB_. [18] Differentiated Service on Linux HOWTO. [Online]. Available: [19] OLSR Daemon (olsrd). [Online]. Available: REFERENCES [1] Differentiated Services (DiffServ) Charter. [Online]. Available: 7 of 7