Multi-Topology Routing for Improved Network Resource Utilization in ...

The 2010 Military Communications Conference - Unclassified Program - Networking Protocols and Performance Track

Multi-Topology Routing for Improved Network Resource Utilization in Mobile Tactical Networks Mariann Hauge, Margrete A. Brose, Jostein Sander

Jon Andersson

Norwegian Defence Research Establishment (FFI) Kjeller, Norway {Mariann.Hauge, Margrete-Allern.Brose, Jostein.Sander}@ffi.no

Thales Norway AS Oslo, Norway [email protected]

Abstract—This paper shows how Multi-Topology routing can be used in highly heterogeneous tactical mobile ad hoc networks to improve the network resource utilization. We suggest the usage of a QoS model where a routing protocol maintains several, distinctive network topologies. Each topology is tailored to support either single or multiple QoS-classes. With this model, traffic flows requiring a QoS-class that cannot be supported endto-end due to limited resources in the present network topology, can be dropped at the source. This QoS architecture reduces the amount of traffic that is forwarded in the network and then dropped somewhere on the route to the destination due to limited network resources. Consequently, some of the scarce network resources are freed for other flows. We demonstrate this mechanism with test and measurements on a highly heterogeneous lab network. Keywords—Multi-Topology routing; QoS; MANET; OSPF; IPv6

I.

INTRODUCTION

In a modern tactical network many different transmission media can be used to link the various units and command posts together in the battlefield. To provide a reliable network for different operation types and in varying terrains, the tactical mobile network infrastructure will consist of a variety of wireless network types, e.g., long-range communication for reach back connections and a higher bandwidth network for local communication. Robust communication for highly mobile nodes is a requirement, and there is a constant need for higher bandwidths. A single transmission technology, e.g., a VHF network, will not be able to support all communication types and bandwidth requirements. It is also important to merge different generations of radio networks in a common infrastructure to best utilize all communication resources that is available to a military unit. Multiple transmission technologies and routing paths will also improve the network reliability by providing alternative routing paths during e.g., jamming attempts. The transmission equipments used in tactical networks have large variations in capabilities and transmission range, thus it is challenging to administer, admit, and route the traffic flows in these networks. It is desirable that the users/applications on the network have a common interface to the different transmission technology(ies) available on the platform. Consequently, the network’s routing mechanisms must find the best path through

978-1-4244-8179-8/10/$26.00 ©2010 IEEE

the heterogeneous wireless network to the destination. Traffic load on a tactical wireless network will vary from short text messages to bandwidth consuming sensor feeds. The traffic must be classified into a set of QoS-classes. In a mobile tactical network the network will have little capacity (most likely for many years to come). It is therefore crucial to support prioritization of operational critical traffic. It is also desirable to use the tactical network in the most optimal manner and thus make sure that only traffic that has a high chance of reaching the destination is admitted into the network. One way to increase the network throughput is to take advantage of parallel paths in the heterogeneous network and efficiently exploit all bandwidth resources. Since the transmission means used in tactical networks have large variations in capabilities, we find it advantageous to define multiple routing topologies in the network to support different QoS-classes. These topologies are then used to ensure that data packets are only forwarded on topologies with sufficient capabilities to support the requirements of the dataflow. We combine Multi-Topology (MT) routing [1][2] and traditional DiffServ-like [3][4] mechanisms to utilize all available transmission means in the tactical network and increase the robustness of the network. We show that this architecture gives a more predictable service quality than a reference architecture utilizing single topology routing, DiffServ mechanisms and a blocking rule on certain links to block traffic from some QoS-classes from utilizing that link (e.g., video traffic over a narrow band waveform). The rest of the paper is organized as follows: In Section II we point the reader to related work. In Section III we describe the Multi-Topology routing solution in detail. The QoS architecture is explained in Section IV. In Section V we discuss the test bed, measurements and results, and finally we give a short conclusion in Section VI. II.

RELATED WORK

During the last 10 years much research has been done to achieve predictable QoS in mobile ad hoc networks (MANET). This is a difficult task due to the agile changes in the network topology, and the fluctuating channel quality in such networks. Much focus has been put in the area of QoS-routing. QoSrouting aims to find a route which provides the required service quality for a traffic type. This can be done using routing

1517

metrics based on parameters like delay, data rate, signal to noise ratio, route stability, etc. These protocols must be combined with a resource manager and a traffic classifier (e.g., DiffServ-like classification) to support end-to-end QoS in the network. Two survey papers [5][6] give a comprehensive overview of many of the available QoS-routing proposals. Most of the QoS protocols covered in the two survey papers discover a single path that supports a certain QoS requirement. This QoS requirement can be described by one parameter (e.g., maximum bottle neck data rate), or by several parameters (e.g., maximum bottle neck data rate and lowest end-to-end delay). Some protocols also maintain multiple paths to the destination for the purpose of e.g., load balancing, fault tolerance, higher aggregated bandwidth and reduced route discovery latency after link breaks. In [7] important multipath protocols are covered. In [8][9][10][11] multipath is established explicitly for QoS support. Some of these also make a point of combining DiffServ and multipath routing. However, most of the QoS-routing schemes, and all the mentioned multipath protocols are reactive routing protocols. We believe proactive protocols will be necessary in tactical MANETs to reduce the routing response time and increase the predictability of the network availability. We also think it is beneficial to store several routes with different characteristics to support separate QoS requirements. This is important for a heterogeneous wireless network that is established with radios that utilize different transmission technologies. We propose a simple but powerful scheme with a proactive routing protocol that maintains multiple topologies in the routing domain and consequently provides multiple paths from source to destination. Each topology/path is associated with a single or multiple QoS-class(es). Similar ideas (based on a very different routing scheme) are presented in [12]. Here network information is maintained proactively, and different paths for the required QoS-classes can be calculated with different metrics based on a single routing database. III.

MULTI-TOPOLOGY ROUTING

A traditional link state routing protocol maintains one routing table with one entry for “the best route” to all destinations in a network domain (or several of the best routes for load balancing purposes). The best route is calculated based on the chosen metric (e.g., shortest path first (SPF) or lowest cost, where the cost parameter can be established based on any set of link parameters). A Multi-Topology routing (MT-routing) protocol maintains several topologies within the network domain at the cost of a few extra bytes in the routing packets. Each topology spans a subset of the physical topology. A shortest path first calculation (other metrics can be used if available) is performed for each topology to discover the best routes within the topology. Only the links belonging to the actual topology are included in the calculation. The results of the SPF calculation are stored in one forwarding table for each topology. In Fig. 1 we show a network where three topologies are defined on the physical topology. A number of topologies can be defined on a single physical link. All the physical links in the domain must be part of the default topology.

Figure 1. This figure shows a network with three different topologies.

During network configuration, topologies can be tailored to represent many different purposes. Among others, the following are interesting cases:  A specific topology can be created to be used for transit traffic through the network.  Topologies can be created that has sufficient (maximum) capacity to support a certain QoS-class, or multiple QoSclasses. MT-routing is a very useful tool that can be used to solve many situations where a certain end-to-end behavior is needed in tactical networks. This comes at the cost of a more complex network configuration. In this paper we focus on the use of MT-routing for QoS support and network resource management in a mobile tactical network. In previous work we conducted a field experiment with Multi-Topology OSPF (OSPF-MT) on five routers with four different radio networks/links with varying characteristics in a forest terrain. More information about the background for that work, and the experiment can be found in [13]. The MultiTopology routing protocol used in that experiment was based on the RFC 4915 [2], which reuses the Type of Service (TOS) field in the OSPF Link State Advertisements (LSA) packets to advertise multiple topologies. Based on the subjective results from the field test, we have proceeded to conduct performance measurements on the system in our lab. We report on these measurements in this article. To make the protocol better suited for MANETs we also decided to extend one of the suggested mobile extensions to OSPFv3 (RFC 5614 [14]) to support MTrouting in the manner described below. We have based this MT extension on [1]. The protocol operation of MANET OSPF-MT is similar to MANET OSPF. After the routers have formed adjacencies with their selected neighbors, and the Hello-protocol has been initiated, link state information is flooded in the OSPF area. The LSAs include information about the link cost, IP address and subnet mask. To avoid problems with backward compatibility, a new LSA has been defined for MT-OSPFv3. In the new LSA, the entry of each interface is defined in a typelength-value field (TLV) in the LSA. The new Link Description TLV (LD-TLV) is used for this. The LD-TLV holds a set of sub-TLVs called Router Multi-Topology subTLV (RMT-sTLV) (ref Fig. 2). The RMT-sTLV carries the Multi-Topology identifier(s) (MT-id) for each neighbor. One link may belong to multiple topologies; this requires multiple

1518

advertisements with an MT-id and an MT metric per topology. Still, only a single adjacency is formed with each of the selected neighboring nodes even if the interface participates in multiple topologies. The same link may have a different MT metric for each of the topologies it participates in. All physical links in the network domain belong to the default topology. The default topology is used for routing traffic and ensures that routing information is flooded to the whole network. All link advertisements are stored in the link state database. The calculation of the forwarding table for each topology is based on the information in this database. IV.

QOS ARCHITECHTURE

In this paper we have chosen to discuss QoS in the context of a minimal but efficient QoS architecture that divides the QoS operations in two functional entities:  One entity that supervises the resource management. This mechanism is needed at the ingress of the network.  One entity that handles network congestion, packet forwarding and packet prioritizing required by the different dataflows. This mechanism is needed in all forwarding elements in the network. The resource management entity decides if a new traffic flow can be supported by the network. This mechanism must identify the network resources required by the flow associated with a specific QoS-class. If there are enough network resources available, the session will be admitted. Thus, there is a need for a resource management mechanism that attempts to estimate the available capacity of the network. If mechanisms are available to support resource reservation, this will be done by the resource manager. 0 0

Link Description TLV (LD-TLV) 2

1 1

2

3

4

5

6

7

0

1

2

3

4

5

6

7

0

1

2

3

4

3 5

1 (LD-TLV)

6

7

0

1

2

3

4

5

6

7

TLV length

Link-Block length

0

Link-Type

0

Link-Type

Interface ID Neighbor Interface ID Neighbor Router ID Sub-TLVs

Link-Block length Interface ID Neighbor Interface ID Neighbor Router ID Sub-TLVs

0 0

Multi-Topology sub-TLV (RMT-sTLV) 2

1 1

2

3

4

5

6

7

0

1

2

3

4

5

6

7

0

1

2

3

4

1 (RMT-sTLV) MT-ID

5

3 6

7

0

1

2

3

4

5

6

7

TLV length 0

MT- ID metric Sub-TLVs

Figure 2. The new TLV/sTLVs for MT transport in OSPFv3. 0

1 SBC

SBC: IP MPL: TFC: ECN:

2

3

4

IP MPL

5 TFC

6

7 ECN

Service-based Class (QoS-class) IP Military Precedence Level Traffic Flow Confidentiality Explicit Congestion Notification

Figure 3. Suggested use of the IPv6 traffic class field or IPv4 DS field.

The prerequisites for admittance of a session may change after a session is admitted. A session of very high importance may try to access a fully loaded network. Then, pre-emption of a low importance session may be required. Similarly, due to node mobility, jamming, etc., the network capacity may change over time. This must be acted on by the resource manager. Short term network congestion due to fluctuations in the radio channel capacities and temporary overload of the network must be handled by the forwarding component of the network routers. This component must also tailor packet queues and packet scheduling to effectuate the delay requirements of the packet’s QoS-class, and the military priority of the packet. In overload situations this mechanism makes sure that the important traffic is prioritized by the network at the expense of less important traffic which might then experience a very high packet loss due to queue overflow. For this architecture a set of QoS-classes must be defined that describe the network requirements (in terms of data rate, jitter, delay, reliability, etc.) needed by the dataflows labeled with the specific QoS-class. Flow priorities associated with the role of the end user must also be defined. The traffic flows must be tagged with this information. For the experiment described in this paper we choose to use the traffic class field in the IPv6 header, and the differentiated services (DS) field in the IPv4 header to mark the packets. We use this field to code the QoS-class (named Service-based Class in [15]), traffic priority (IP Military Precedence Level) and its requirement for Traffic Flow Confidentiality as suggested in [15]. Fig. 3 shows the chosen format. The Servicebased Classes (SBCs) defined in [15] do not make a clear distinction between bit rate requirements for the different classes. We need this distinction for the tests we want to run in this experiment. In Section V we describe our chosen experimental SBCs . The characteristics of a tactical MANET can vary significantly depending on available radio equipment and the present network topology. Some of the links in a mobile tactical network might have very limited data rates, and be unable to support the data rate requirements of high data rate applications (e.g., video streaming). Other links have long forwarding delay and cannot support applications that require short delay (e.g., Voice over IP). The QoS architecture must ensure that only data traffic that can be supported by the present network topology is allowed to enter the network. We show that an architecture offering a combination of DiffServlike mechanisms and MT-routing based on the packets’ QoSmarks can improve the resource utilization in tactical networks with limited bandwidth and highly varying link characteristics. In the MT supported QoS architecture, we configure and maintain several network topologies that each spans a subset of the physical topology. Each topology has its own forwarding table that is used to forward packets classified as belonging to the specific topology. If a destination address is not available in the forwarding table associated with the QoS-class, then no path exists in the network where the specific QoS-class is allowed to be transported. Thus the flow should not be admitted to the network. Traffic is stopped at the network edge and not (in a worst-case scenario) forwarded through the entire

1519

network just to find that the last hop to the destination is a very low data rate link not able to support the application's requirements. A traditional routing protocol is capable of taking into account a single network parameter or multiple parameters as defined by the routing metric, when selecting the best route from source to destination. However, a traditional protocol that does not support multiple topologies is not able to make different route choices based on service requirements. Instead it selects one route between the source and destination for all types of traffic. MT-routing on the other hand allows specification of several routes that can be tuned to best support different QoS-classes. MT-routing provides a higher flexibility in the design of QoS enabled mobile wireless networks where traditionally few efficient resource management mechanisms are available. As of now, we build topologies based on static predefined network/link characteristics. We cannot use dynamic parameters such as network/link load or channel quality in the topology calculation. In future work we want to investigate if dynamic parameters can be incorporated efficiently with the MT-routing protocol to better support the resource management mechanism in the mobile tactical network. The cost associated with more frequent updates and reconfigurations should be looked into. The validity of such routes based on dynamic parameters in a proactive protocol must also be explored. When there is a route to the destination in the correct topology and the traffic flow is admitted to the network, the DiffServ mechanisms come into play. A queue hierarchy and packet scheduling mechanism prioritizes the sequence of transmitted packets on each interface. For each network interface we also define a traffic shaper, whose purpose is to keep the traffic transmitted on the wireless network below a certain threshold, to avoid network congestion. We use queue and scheduling tools to tailor the queue to the requirements of the associated QoS-class, and to implement packet scheduling for traffic priorities. Queue length, head/tail drop and dropprecedence are important queue parameters, while the packet scheduler could be designed for a strict priority scheme or a situation with more fairness in the scheduling process.

supports configuration of static MT-routes. Both MT-id and MT metrics can be configured for the static routes. The data packets that are not classified by the source are marked with the correct QoS-class by using the iptables/ip6tables functionality in Linux. This interface is also used to associate the QoS-classes with the forwarding table for the correct topology. The Linux traffic control (tc) tool is used to setup the queuing and scheduling mechanisms. A. Network The test bed network can e.g., represent a small scale mobile tactical network with three moving nodes and a deployed local headquarter (HQ). The network is pictured in Fig. 4. To improve the robustness of the network, the satellite link and the HF link are installed on different vehicles. The different transmission technologies present in the test bed network have substantially different characteristics when it comes to e.g., transmission delay, transmission range and data rate. For this experiment we have chosen to focus on the differences in data rate. The high data rate radios are set to provide a common channel UHF network with a maximum bit rate of 920 kb/s. The low data rate radios are tuned to represent a narrowband VHF network with a maximum common channel bit rate of maximum 64 kb/s. The HF link transmits with a bit rate of 9.6 kb/s and the emulated satellite connection (SatCom) is set to 250 kb/s. Given the heterogeneous network as described above, the end-to-end network capacity could change from several hundred kb/s to less than 10 kb/s when a node moves from UHF/SatCom coverage to a path that includes one or more VHF/HF links. This large variation in available data rate is difficult to handle for the resource management entity. In such a scenario it is also important that the network is able to prioritize the mission critical data traffic in overload situations. SA-Data

Mobile node 1

VoIP

Sensor

SA-Data

VoIP

Low data-rate network

Router1

Router2

Mobile node 2

CON 1 FIG 2 3 4

POW ER 24 V D C

ACCESS PORT 1 CH 1

IN T PO FA RT IL

7 4 1 ENT ER A EXIT

8 5 2 0

9

F

6

E

D 3 DEL B C LOA HEL D P

13

24

HF

The implementation is done by Thales Norway AS

O N

O N

OF F

OF F

CON 1 FIG 2 3 4

ON OFF

High data-rate network

PORT 1 -4 5288 POWE R ON

TERMI NAL

ACCESS PORT 1 CH 1

IN T PO FA RT IL

7 4 1 ENT ER A EXIT

8 5 2 0

9

F

6

E

D 3 DEL B C LOA HEL D P

13

24

O N

O N

OF F

OF F

Mobile node 3

24 V D C

PORT S

We have implemented the proposed QoS architecture in our lab. The implementation 1 of Multi-Topology support for MANET OSPFv3 and OSPFv2 was done using the Vyatta [16] Linux distribution. This is based on the Quagga [17] open source routing application running Debian Linux 2.6.31. The MANET OSPFv3 base protocol was fetched from [18]. The router implementation allows easy configuration of OSPFv2MT and MANET OSPFv3-MT information, MT-ids and MT metrics for each interface. The Linux platform is set up to utilize multiple forwarding tables and Quagga's interface towards forwarding tables in Linux has been adjusted to allow the use of multiple routing tables. In addition to OSPFv2-MT and MANET OSPFv3-MT routing, the implementation also 1

POWE R ON TERMI NAL

TEST BED POW ER

V.

PORT 1 -4 5288

PORT S

ON OFF

Router3

Router4

Deployed HQ

SatCom

SA-Data

VoIP

VoIP

SA-Data

Figure 4. The test bed.

We interconnect the different links and networks present in the network with an OSPF-MT routing protocol in one flat routing domain. This allows full dynamics in the network and also supports situations where the deployed HQ can be used to

1520

relay traffic from one reconnaissance unit to the other mobile units. Consequently, we also run routing over the point-to-point HF and SatCom connections. Especially HF does neither have excess capacity for routing traffic, nor perform very well for short periodic messages. However, since the SatCom and HF links are installed on different vehicles (routers) we need routing to distribute the availability of one or the other of these capabilities. (Furthermore we want to gain experience with routing traffic over an HF link.)

SBC 1 2 3 4 5 a.

TABLE II. SBC

Application

2

SA-data (position)

3

Video (MPEG4)

4

VoIP (half dupelx)

THE LINK BETWEEN TOPOLOGY AND SBC (QOS-CLASS) Traffic

Low data High data Default rate topology rate topology topology Routing N/A N/A X Situation Awareness (SA) data X Sensor (Video streaming) X VoIP (MELPe 2400)[19] Xa Best Effort X -

VoIP is in general allowed on the low data rate topology, but must be blocked on the HF connection.

B. Measurements and Results We choose to emulate a minimum set of traffic types with the Multi-Generator (MGEN v 5.01b) [20] traffic generator. MGEN is able to generate IPv4/IPv6 UDP traffic with a range of patterns, and can also set the differentiated service/traffic class fields with the specified QoS-class. Table II shows how we create the chosen traffic types. For the test we describe here we use only point-to-point distribution of data. All the applications listed in table II can also be targets for multicast distribution in tactical networks. Efficient multicast in the proposed MT supported QoS architecture is for future work. We simulate a situation in our lab where three mobile nodes are in the vicinity of a deployed HQ. At t0 all nodes are

Required IPv4 bandwidth 28.4 b/s

Pkts/s 0.05 regular 0.8 burst 8 burst 12 burst 5.5 burst

99.4 kb/s 4.4 kb/s

High bit-rate Low bit-rate

om

Mobile node 3 rate Low bit-rate

Low bitLo w

bit-ra te. HF

Mobile node 1

-rate

For the low data rate interfaces we choose to configure a strict priority queue with no fairness in the packet scheduling. This ensures that the highest priority traffic types are given enough resources. For the high data rate interfaces we use the hierarchical token bucket (HTB) queuing structure for Linux, and associate a share of the shaping bandwidth to each of the QoS-classes. This support traffic priority but also provide some fairness in the packet scheduling. QoS-classes that need low delay are set up with short queues, as is QoS-classes with periodic traffic where it is important to always get the most recent message. This QoS-class can also benefit from a drop head mechanism.

IP payload 43Byte 1429Byte 1044Byte 220Byte 74 Byte

bit Low

To improve the traffic control in this heterogeneous network we define two topologies in the OSPF-MT domain: A high data rate topology and a low data rate topology. The high data rate topology includes the SatCom link and the high data rate UHF network. The low data rate topology includes all links. The high data rate links are also included in this topology to increase connectivity and network robustness; however, the topology cannot guarantee more than a low data rate capacity. Traffic from the different QoS-classes (SBCs) defined for the test environment is allocated to the different topologies as shown in Table I. The best path within each topology is calculated based on the MT-cost parameter for each link between source and destination.

THE EMULATED TRAFFIC FLOWS

SatC SatCom

TABLE I.

reachable via both the high bit rate network and the low bit rate network, and the SatCom and HF links are up. SA-data are transmitted from all nodes to all nodes. The video stream at node 1 is transmitted to node 2. We also sustain full duplex voice call between node 2 and node 1, and node 2 and node 3.

w Lo

e at t-r bi

Deployed HQ

Mobile node 2

Figure 5. Network topology at time: t1.

Next, node 1 and node 3 leave on a reconnaissance task. At the same time node 2 leaves for a different destination. At time t1 the network connectivity is as depicted in Fig. 5. We start our measurements at t1. In this topology the video stream from node 1 to node 2 cannot be supported any longer, but all other communication can be sustained. We run this scenario with two different QoS architectures. In the basic QoS situation we block the QoS-classes (SBC 3, Video streaming) that cannot be supported by the current network topology, at the bottleneck link. We compare the throughput for this architecture with the situation with MT-routing support, where traffic tagged with the unsupported QoS-class is blocked at the source. We identify the amount of “garbage” traffic in this scenario. By garbage traffic we mean traffic that is forwarded in the network, but must be dropped somewhere on the route to the destination due to limited network resources. We also investigate if we can see an improvement in packet throughput for the traffic flows that can be supported end-to-end, when we use the MT supported QoS architecture. The scenario is run five times for each QoS architecture, and the duration of each run is 300s. The average results are presented. The Linux routers and the data sources keep their clocks synchronized with the network time protocol (ntp). Table III shows the measured garbage traffic in the two different cases. The traffic is summarized over all links in the network. There is as expected, substantially less garbage traffic in the MT supported QoS setup. The garbage traffic present in this network is mainly a result of erroneous routing information during the delay from a link break is detected, until the routing tables are updated.

1521

TABLE III. Garbage traffic

GARBAGE TRAFFIC (IP PAYLOAD) IN THE NETWORK2 MT supported QoS 4.4 Mb

supported QoS architecture to incorporate dynamic changes in e.g., channel quality and traffic load to further improve the scheme for admission control purposes. The resource mechanism must be executed for all defined topologies.

Basic QoS 38.4 Mb

10 % 8%

ACKNOWLEDGMENT

MT supported QoS

We would like to acknowledge the Norwegian Army Transformation and Doctrine Command Signals Branch represented by Maj. A. B. Enger and Maj. M. Gjellerud for the initiative to develop a router demonstrator for QoS experimentation in tactical networks.

Basic QoS

6% 4% 2% 0% SA-data

REFERENCES

VoIP

[1]

2

Figure 6. Packet loss for the two different QoS architectures .

We also observe (Fig. 6) a small improvement in the throughput for the admitted traffic in the network for the MT supported QoS architecture. Note that the packet loss varies significantly between the different test-runs (as is often the case with wireless test beds with topology changes). The variation is visualized with the standard deviation marks on the graph. We believe that the reduction in packet loss will be more evident in a larger network. In our future work we plan to design a simulation platform for the MT supported QoS solution to study the effect on networks with more nodes, and more traffic flows. VI.

[3] [4] [5] [6] [7] [8]

[9]

CONCLUSION

In this article we show how Multi-Topology routing can aid the design of end-to-end QoS support in a heterogeneous mobile tactical ad hoc network. The MT-routing protocol builds topologies based on static link characteristics that are valid at all times. For a heterogeneous tactical MANET we see the use of multiple topologies paired with a DiffServ-like architecture as a simple but powerful tool to dynamically block traffic, that cannot be supported by the current network topology, at the source and thereby improve the QoS and available capacity for admitted traffic. We show that there is substantially less garbage traffic forwarded in the network supported by MTrouting, and that the packet loss is reduced for the traffic that can be supported by the network topology. Multiple topologies can also be used to support load balancing on a QoS-class basis (i.e., different QoS-classes are transmitted on partly or fully disjoint paths) Since this QoS architecture operates based on the code in the IPv6 traffic class field or the IPv4 differentiated services field, the only requirement to a potential IP encryption device placed between the issuing application and the wireless transport network is that the encrypted tunnel must inherit the QoS tag of the data packet. Additional resource management mechanisms based on e.g., polling techniques [21] can be combined with the MT 2

[2]

[10]

[11]

[12]

[13]

[14] [15]

[16] [17] [18] [19] [20] [21]

The results are measured in a network running OSPFv2-MT.

1522

S. Mirtorabi and A. Roy, "Multi-topology routing in OSPFv3 (MTOSPFv3)." draft-ietf-ospf-mt-ospfv3-03.txt (work in progress), July 2007 P. Psenak, S. Mirtorabi, A. Roy, L. Nguyen, and P. Pillay-Esnault, "Multi-topology (MT) routing in OSPF." RFC 4915, June 2007. S. Blake et al., "An architecture for differentiated serv." RFC2475, 1998. D. Grossman, "New terminology and clarifications for diffserv." RFC 3260, 2002. L. Hanzo-II and R. Tafazolli, "A survey of QoS routing solutions for mobile as hoc networks." COMST, vol. 9, no. 2, pp.50-70, 2007. R. Asokan, "A review of Quality of Service (QoS) routing protocols for mobile Ad hoc networks." ICWCSC, Chennai, India, 2010. N. S. Kulkarni, I. Gupta, and B. Raman, "On demand routing protocols for mobile ad hoc networks: A review." IACC, Patiala, India, 2009. P. Jeon and G. Kesidis, "Pheromone-aided robust multipath and multipriority routing in wireless MANETs." PE-WASUN, pp. 106-113, Montreal, Quebec, Canada, 2005. L. Xuefei and L. Cuthbert, "Multipath QoS routing of supporting DiffServ in mobile ad hoc networks." SNPD/SAWN, pp. 308-313, Baltimore, MD, USA, 2005. S. Venkatasubramanian and N. P. Gopalan, "A QoS-based robust multipath routing protocol for mobile ad hoc networks." AH-ICI, pp. 1-7, Kathmandu, Nepal, 2009. L. Chengyong, L. Kezhong, and L. Layuan, "Research of QoS-aware routing protocol with load balancing for mobile ad hoc networks." WiCOM, pp. 1-5, Dalian, China, 2008. J. A. Stine and G. de Veciana, "A paradigm for quality-of-service in wireless ad hoc networks using synchronous signaling and node states." J-SAC, vol. 22, no. 7, pp.1301-1321, Sept. 2004. B. Rossow, I. Sorteberg, and M. Hauge, "Multi-topology routing in resilient tactical networks." (NATO Unclassified), in proceedings RTOMP-SCI-18, (NATO Unclassified), Amsterdam, The Netherlands, 2008. R. Ogier and P. Spagnolo, "Mobile ad hoc network (MANET) extension of OSPF using CDS flooding." RFC 5614, Aug. 2009. R. M. van Selm, G. Szabo, R. van Engelshoven, and R. Goode, Ip QoS standardisation fo the NII, RD-2933, NC3A,(Nato Unclassified), Apr. 2010. Vyatta, http://www.vyatta.com.. Quagga Routing Suite, http://www.quagga.net. OSPFv3 MANET MDR, Boing, http://hipserver.mct.phantomworks.org/ietf/ospf. STANAG 4591, "The 600 bit/s, 1200 bit/s and 2400 bit/s NATO interoperable narrow band voice coder." (Nato Unclassified), Oct. 2008. Multi-Generator (MGEN), Naval Research Laboratory, http://cs.itd.nrl.navy.mil/work/mgen/index.php A. Mohammad, O. Brewer, and A. Ayyagari, "Bandwidth estimation for network quality of service management." MILCOM, Orlando, FL, USA, 2007.