MOBILE ROUTING ARCHITECTURES IN THE TRANSFORMATIONAL COMMUNICATIONERA

Howard FeilWilliam Metler

The Aerospace Corporation15049 Conference Center Drive, CH3-430

Chantilly, VA 20151 USA

Copyright 2005 The Aerospace CorporationCopyright 2005 IEEE

ABSTRACT

With the communication evolution to the all Internet Pro-tocol (IP) architecture to support tactical environmentsusing Joint Tactical Radio System (JTRS), significant newIP routing challenges exist. Mobile Ad-Hoc Networking(MANET) has been in development for many years now,however, existing MANET protocols have not been de-signed to scale to the size or proportions of the Transfor-mation Communication Architecture (TCA) vision [1].This paper describes a potential IPv6 addressing and rout-ing architecture vision for tactical users in a notional TCAera where satellite and aircraft routing gateways exist.The paper also identifies routing protocol deficiencies thatexist in current and planned MANET"4 and traditionalrouting protocols.

INTRODUCTION

This paper describes a notional all Internet Protocol v6(IPv6) addressing and routing architecture vision for tacti-cal users in the Transformational Communication Archi-tecture (TCA) era where satellite and aircraft routinggateways exist as described in [1]. The unique tacticalmilitary environment centers upon the intention to lever-age satellite and air gateways in order to maintain the op-erational viability of the network infrastructure in the faceof movement by space gateways, air gateways, and earthsurface nodes. Essentially all nodes in a tactical militaryregion are mobile. These concerns can be summarized asbeing requirements for range extension such as leveragingsatellites and drones to improve the network availability orto extend the effective radius within which a mission mayoperate.

The term MANET, as used in this paper, should not necessarily beequated with IETF M\ANET protocols (seehttp:Hwww.ietf.org/html.charters/manet-charter.html). Rather, the in-tended meaning of that term within this paper is in regards to the ge-neric class of mobile ad hoc network protocols, without reference toany specific protocol instance.

In this paper, we will provide a recommended IPv6 ad-dressing scheme that will support route consolidation. Ourarchitecture assumes High Assurance IP Encryption

Space Gateways

CONUS '

GIGTransport Aeateways

T ea aseI

Figure 1 COTM Reference Model

(HAIPE) devices to provide the required information as-surance security and to also provide IPv6 Plain Text toCipher Text (PT/CT) address separation. We will alsodiscuss several options for solving the HAIPE PT/CT ad-dress discovery problem. The paper will primarily focuson CT IP routing and addressing. We will attempt to pro-vide possible IP routing options, and the paper will iden-

1 of 6

tify known protocol deficiencies that exist in the currentand planned MANET and traditional routing protocols.

ARCHITECTURE GOALS

There are many aspects to a Communications on the Move(COTM) architecture shown in Figure 1 that are differentfrom traditional IP networks. Perhaps the most significantdifference with the COTM architecture is the existence ofmultiple or no air/space gateways in line of sight. Also,over time the air/space gateways orientation and availabil-ity will change. The COTM architecture at the high gate-way levels should provide optimized routing when multi-ple gateways exist. At the lower tactical node level, thearchitecture must also deal with mobility protocols onsmall handhelds with minimal resources, e.g., power andbandwidth. The end goal of the COTM architecture is tominimize the impact on users of the network itself movingas well as the user. Logically, COTM users want theirnetwork availability and connectivity to be just as predict-able and easy to use as traditional fixed-point networks.This is a challenge because of the impacts of mobilityevents such as disruption of service and handoffs betweenspace and air gateways. Other requirements include as-sured access [2], point-to-point communications [2], rapidmovement, covert operations (emissions control), security(Link Layer, header authentication), and unidirectionallink support.

MOBILE ROUTING THEATER REFERENCEARCHITECTURE

The communications Concept of Operations (CONOPS)principles that guide our IPv6 tactical reference model ar-chitecture shown in Figure 2 are the following:

The air gateway drone aircraft (or space gateway satellite)can act as relays and constitute a logical backbone ofgateway routers tying together (terrestrial or water surface)mobile subnets or clusters. If a mobile cluster does nothave an IP route in its routing table, then it will send thepacket to the default air gateway. If the air gateway is notavailable, then send the packet to the space gateway. Themobile cluster need not learn routes from the air/spacegateways, but they can pass routes to the air/space gate-ways.

Our architecture assumes that the military's CONOP con-sists of members likely to move as a group, e.g., a brigadeon a battlefield. In our reference architecture, we refer tothese groups as clusters with a cluster head. The clusterheads will use a MANET protocol with the other clusterheads to exchange information that takes advantage of thisclustering behavior as described in [3] or [4]. In Figure 2,the cluster based MANET protocol that takes advantage ofthis cluster behavior is referred to as C-MANET. If aroute is advertised via the C-MANET protocol, it will be

the longest prefix match and used instead of routing to-wards the air/space gateways.

Mobile nodes or cluster members will usually remain withtheir cluster, but they can roam from cluster to cluster join-ing other cluster heads. Nodes will get routing informationfrom their cluster using an efficient cluster distributionprotocol such as [5]. Using the routing information, nodeswill route their communication towards the cluster head,that advertised the route as explained in [3] and [4]. Usingprotocols such as [3] or [4] a node's traffic does not needto go directly through cluster heads if a more direct pathexists.

Air/space gateways will be used primarily for range exten-sion of the mobile clusters and nodes. Air gateways, spacegateways, and theater bases will not be severely limited byCPU power and may exchange detailed routing tables us-ing traditional routing protocols amongst themselves. Toreceive detailed routing information from the clusters orautonomous nodes, the air/space gateways can exchangemessages using a MANET protocol or external BorderGateway Protocol (eBGP) with the cluster heads. Theair/space gateways will only advertise a default gateway

,' ,/'Air Gatew$.,

C-MA'ET

C-MANET*OSPF Area 0 F-Fstfly1er

)hir Gateway

C-MANJET* //C-MANETC-MANET _

Air Link

Figure 2 Mobile Routing Theater Reference Architecture

route and a link cost back to the cluster heads. By onlyadvertising gateway routes, the air/space gateways willminimize the burden of processing large routing tables bymobile user devices.

In addition to a CT routing function, each tactical node inthe network hierarchy has its own HAIPE - a special de-vice gateway that provides encryption and authenticationof traffic. The HAIPE also provides conversion of PT ad-dressing to CT addressing.

These principles limit the CT routing tables on the mobilenodes to only those routes learned via the C-MANET pro-tocol. The gateway of last resort is either the air gateways

2 of 6

>%C,leI/ C, ,

--,.jov.1-1 ---

and/or the space gateways acting as gateway routers. Inmany tactical mobile routing environments, most of thetraffic sessions will occur within the MANET cluster.

There are still numerous issues supporting and buildingthis architecture with current technology. Some of the is-sues will be discussed and analyzed in the body of this pa-per; for example, what is the addressing scheme, how willHAIPEs resolve PT/CT addressing, what is the associatedrouting approach, and how are the mobility capabilitiesrealized.

THEATER IPV6 ADDRESSING

A clever hierarchical IPv6 addressing plan as shown inFigure 3 will result in significant route summarization forthe air and space gateway in a region without requiring theregion to re-address for the gateways.

Space Gateway2001:0:FFFF:1::/EU1-64 >

2001:0:1:0::/EUI-64

2001:0:1 :FFD0: :/EUI-64

Cluster }{ead

2001:0:1:1::/EUI-64

Cluste UISubnet I

2001:0:1:1::/EUI-64

2001:0:1:FFDI::/EUI-64

'\ F ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~I14 Cluster Head2001:0:1:2::/EUI-64

FT,

,()luster.}vubnet,

2001:0:1:2::/EUI-64

Figure 3 Theater Cipher Text (CT) Addressing Scheme

In our proposed addressing scheme, we suggest that everynode receive a default unique CT IPv6 address for the re-gion such as

2001:0:1 :0::/EUI-64

where :1:0::/EUI-64 is the hexadecimal for the region andthe EUI-64 is the unique (MAC) layer-2 address. Nodesthat are not preconfigured to be cluster head capable willalways revert back to their default unique CT addresseswhen they become isolated or autonomous. Static uniqueaddressing may be the norm for nodes capable of rapidmovement such as a fighter aircraft assigned to a region.

A cluster head node is elected or preconfigured in eachcluster with an automated election backup capability bycluster or IP subnet members. The cluster head's CTrouter maintains a MANET protocol exchange with other

participating cluster heads, gateways, or fixed (theater basecamps) routing nodes. Nodes capable of being clusterheads will be reconfigured with a cluster head addresssuch as:

2001:0:1 :xxxx::/EUI-64

where xxxx is a Cluster head node for the range 2**16-1theoretical cluster heads. When a node joins a cluster orroams from one cluster to another, the node will auto-address to the cluster head's address. Auto-addressing ofcluster members will result in the cluster head only need-ing to advertise one /64 address to other clusters, to theair/space gateways, or to theater bases.

Regional air gateways can be preconfigured to a desig-nated well-known address such as:

2001:0:1:FFD0::/EUI-64 to 2001:0:1:FFFF::/EUI-64

Tactical nodes can be preconfigured to route towards thesewell known addresses for gateway services, Domain NameServers (DNS), or Mobile IP home agents.

Space gateways can also be preconfigured with wellknown addresses with a unique region code such as

2001 :0:FFFF:1 ::/EUI-64

and similarly tactical and air gateways can be preconfig-ured to know these addresses. The entire region being as-signed a regional code such as 2001:0:1::/80 will makeroute summarization for the space nodes and even thetheater bases conceptually easy when exchanging eBGProutes with other theaters or CONUS.

In summary, the hierarchical addressing scheme providesstrong route summarization at the gateway level. The clus-ter heads providing auto-addressing of the cluster memberssupports strong route summarization at the cluster level.There will always be some isolated nodes or pre-designated autonomous nodes such as fast flyers causingsome /128 addresses to appear in the routing tables at thetheater level. Although /128 address are thought to be un-desirable, some amount of /128 routes appear to be a ne-cessity in tactical mobile routing environment.

HAIPE PT/CT DISCOVERY

The hierarchical addressing requires nodes to auto-addresstheir CT address as they roam from cluster to cluster orbecome autonomous. Readdressing the CT interface canbecome a challenge for the already challenging problem ofHAIPE PT/CT address translation and discovery. In tradi-tional fixed networks, HAIPE CT addresses are static. TheHAIPEs perform PT/CT address translation with precon-figured static routes. HAIPE PT/CT address discovery canbe done with multicast probes or emerging pear enclavediscovery techniques. Static routing and multicast

3 of 6

PROBES are mature HAIPE PT/CT address translationand discovery techniques. The emerging pear enclave dis-covery protocol is too immature to be fully understood yetand may not be applicable to the large scale mobile routingenvironment.

In the mobile routing world, just as in the traditional fixednetwork world, several HAIPE PT/CT discovery solutionsdepending on the scenarios may need to be employed si-multaneously. We will attempt to discuss the pros andcons of several options. The options for PT to CT addresstranslation and discovery to be discussed and seem mostappropriate are static routes, multicast probes, use of DNSservers, and mobile IP.

Static routes for PT/CT address translation are not scalableto the large theaters that are envisioned. Static routes forPT/CT address translation will not support the dynamicauto-addressing described in our hierarchical addressingscheme. Nevertheless, static routes have a clear place insome mobility scenarios such as: small autonomous groupsof users, communication with fixed nodes, communicationwith nodes that will not re-address (e.g. rapid movers), andother limited connectivity scenarios.

Many early adopters of TACLANE (HAIPE) technologycould not implement the multicast probes dynamic discov-ery technique because they were using the commercialInternet as their CT routing infrastructure that does notsupport multicast. This fact may remain an issue if thecommercial infrastructure became part of a mobile routingCT infrastructure. However, multicast probes may makesense at some levels within the architecture hierarchy. Forexample, within a mobile cluster, multicast probes may bean excellent solution for discovering your local neighbors.Multicast probes and even the multicast protocol itselfmaybe a challenge for inter cluster communication or broadtheater communication.

A special DNS like server that could provide PT to CTaddress translation within a theater could provide the scal-ability needed for large theaters. The DNS server, unlike acommercial DNS server, would provide the CT addressesassociated with a PT address or domain name. The DNSserver itself could be located behind a HAIPE at a well-known address on the air gateways or at the theater base.The DNS should be redundant in the architecture and havea mechanism for maintaining synchronization of the DNSdatabases. HAIPE devices when roaming and readdress-ing would have to notify the DNS server upon readdress-ing. The DNS server could store the most recent addressupdate as well as the HAIPE node's unique default CTaddress. When queried, the DNS server could provideboth PT/CT translations for the querying HAIPE to try.When a HAIPE device roams and readdresses its CT inter-face, the HAIPE would be required to notify all other

HAIPEs within its current active security association data-base of its new CT address to maintain active TCP/UDPsessions.

The DNS concept marries very well with static and multi-cast PROBES. In a multi-level discovery, the HAIPEcould first try a pre-configured static route. If no success,it could then try a multicast PROBE, and again if no suc-cess, it could try the DNS server. One drawback of DNSserver approach is that it requires some HAIPEs to haveconnectivity to a DNS server.

Mobile IPv6 would also fit into many mobility scenarios.The correspondent HAIPEs could have static routes orDNS routes to the mobile node's home agent. The homeagent could then point the correspondent HAIPE to thecare-of address (COA) of the destination HAIPE. The cor-respondent and COA HAIPE CT interfaces could then per-form mobile IP binding and communicate directly. Theycould maintain communication even in the event of re-addressing using mobile IP protocol. Similar to the DNSserver approach, one drawback of mobile IP is that it re-quires both the correspondent HAIPE and the COAHAIPE to have connectivity to the home agent. Also simi-lar to the DNS server approach, a technique for providingredundant mobile IP home agents with matching databasesmay also be required. Mobile IP also marries well with thestatic and multicast probe techniques.

In summary, a new technique for HAIPE PT to CT addresstranslation and discovery is required. PT to CT addresstranslation and discovery has been very challenging in thetraditional fixed network and mobility only makes discov-ery a harder problem. As new solutions for PT/CT discov-ery are engineered care should be given to understand theirapplicability to extending into the mobile routing envi-ronment.

ROUTING DISCUSSION

One of the major solutions that has been developed forscaling of Interior Gateway Protocols (IGPs) such as OpenShortest Path First (OSPF) or Intermediate System to In-termediate System (IS-IS) was the development of a back-bone area that all sub-areas route through. The backbonearea is also used for address summarization so that stubareas with less powerful routing engines get less routesand less route updates. As noted in [6], it is very hard topredefine the backbone area in many mobile routing sce-narios. As MANET protocols evolve, other solutions areemerging in an attempt to solve the scalability issues suchas [7] or [4], but these solutions will unlikely scale to largetheaters conceived of in TCA without some backboneprinciple. In the reference architecture concept depicted inFigure 2, the air gateways appear to be a logical backbone.To achieve route summarization with the tactical nodes,

4 of 6

we propose that the air gateway backbone should only re-ceive MANET routes, and only advertise a limited set ofroutes (e.g. default gateway) to its tactical MANETneighbors. The tactical MANET neighbors can route be-tween themselves if the longest prefix match is foundwithin their MANET protocol tables, otherwise, theyshould route towards the air gateways if available. If theair gateways are unavailable, then the MANET nodesshould route towards the space gateways.

Communication between air gateways and theater bases,will not exhibit many MANET features because they willhave long and sometimes predictable intervals for connec-tions with other air gateways and theater bases. In our ref-erence architecture, we propose that inter air gateway andbase routing could use a traditional routing protocols andcould be considered one backbone area such as OSPF area0.

The tactical MANET nodes will not normally have randomad-hoc behavior. Most nodes will move in groups or clus-ters related to their mission function. This behavior andMANET protocols that take advantage of this behaviorhave been well documented and studied in [7], [3], and [8].In the COTM architecture, we recommend a MANET pro-tocol that takes advantage of the natural clustering in themilitary CONOP and can exploit this behavior such as de-scribed in [8].

ROUTING ISSUES

Protocol convergence can be an overwhelming issue inMANET networks. MANET node neighbor relationshipscan be constantly changing due to mobility or link avail-ability. The reference architecture tries to minimizeneighbor changes by noting the military's CONOP willoften involve clusters that move as units with logical clus-ter heads.

Clusters, however, will not solve all the problems of verylarge theaters (e.g. Iraq during major operations) with asignificant number of logical cluster heads that are collec-tively in line of sight of each other. As hop distances growlarge, routing information can become inaccurate due tomobility events. Also even concepts such as [3] could re-sult in significant routing protocol overhead in a poten-tially large military network. The concept of a backbone istraditionally used to scale networks to large sizes.

The challenge of using a backbone in the mobile environ-ment is significant. Traditionally backbones require allinter area routing to flow through the backbone except forpredefined backdoors. Within the TCA vision, air gate-ways and space gateways are primarily for range extensionor for when it is the shortest (or least congested) path. Inthe reference architecture the MANET clusters will requirerange extension through the air gateways, and they will

also require direct cluster-to-cluster communication. Innormal IGP operations, direct node-to-node communica-tion without going through the backbone would require thetwo clusters to be in the same area/level of the IGP. Justas [6] describes the challenges for defining the backbonearea, there is a similar challenge defining the non-backbone areas a-priori. This issue requires further study,but in our reference architecture, we will assume that thecluster-to-cluster direct communication is possible and willbe provided by a MANET protocols such as [3] or [4].

However, additional problems still persist. If the air gate-ways only provide summary routes or default gatewaysroutes, most of the time when inter cluster communicationis possible (i.e. the route has been advertised via aMANET protocol) it will be the longest prefix match, andtherefore, the router will prefer the inter cluster route re-gardless of the route cost instead of using the shorter prefixmatch through the air gateway. This represents an issue ofdeciding when an inter cluster route is cost prohibitive ver-sus using the air gateway. Limiting router hop countsnormally solves this, but limiting router hops will intro-duce new problems. Because the air/space gateway hasnot explicitly advertised that the gateway has a better pathto the route destination, there is no guarantee that thegateway has a better path than the multi-hop path throughthe clusters. Thus, the end result could potentially be arouting loop. Traditional IGP avoids this issue by requir-ing all non-backbone areas to have a direct connection tothe backbone area, but this condition cannot be guaranteedin MANET scenarios.

A possible solution would be to include the air gatewayswithin the MANET protocol or to distribute more routes tothe mobile clusters. With currently identified MANETprotocols these alternatives are not desirable. Includingthe air gateways within the MANET protocol would bedesirable if protocol scalability could be achieved to thou-sands of routes and hundreds of routers. However, no ex-isting traditional IGP can scale to such proportions withoutthe concept of routing areas. CPU, bandwidth and batterylimited MANET devices are also not likely to handle thealgorithm intensity of traditional IGPs let alone an overlycomplex network. Redistributing more routes to the mo-bile clusters has similar issues of consuming MANETnode resources.

COVERT COMMUNICAITON

A recommendation for covert communication is beyondthe scope of this paper, however, it is worth noting thechallenges of two-way covert communications. The pri-mary challenge is emissions control. In our COTM archi-tecture, we often assumed proactive routing protocols be-cause they provide faster convergence and more optimalrouting for cluster operations. The disadvantage of proac-

5 of 6

tive routing protocols is that they will periodically send out"hello" and "keep-alive" messages. These messages couldreveal location information to an enemy. Demand basedrouting protocols such as [9] may be better solutions forsolving covert communication problems. Further researchto integrate covert communication into the COTM archi-tecture is required, but the requirement for covert commu-nication will most likely require a more complex hybridarchitecture.

CONCLUSIONS

A strong IPv6 addressing scheme with some dynamicauto-addressing significantly helps solve the challenge ofsummarizing routes amongst the elements in the COTMarchitecture. Dynamically reassigning IP addresses usingauto-addressing may make HAIPE PT/CT route resolutionmore challenging. However, as was discussed in this pa-per, there are potential solutions to the PT/CT route resolu-tion challenges. Existing MANET and non-MANET pro-tocols can be combined to produce somewhat effectiverouting in the reference architecture. However, there arestill significant routing issues that require further investi-gation and engineering.

RECOMMENDATIONS

Historically, the lead time it has taken to make effectivechanges to the HAIPE standard and have vendors imple-ment those changes has taken many years. Therefore, theJTRS program office, e.g., should develop a PT/CT routeresolution plan for use in the TCA era as soon as possible.MANET protocols are still very immature and are continu-ing to rapidly evolve in the multiple Internet EngineeringTask Force (IETF) working groups. It is reasonable toassume that MANET protocols will continue to evolve formany years to come, but it may be advisable for the Gov-ernment to play an active role in the IETF process to try toshape or influence MANET protocols or an IP protocolvariant to meet the size and scalability requirements of themilitary environment.

REFERENCE

[1] Statement by John Stenbit before the Committee onArmed Services Subcommittee, February 11, 2004[2] Captain J. Loiselle, R. Tarleton, J. Ingerski "The NextGeneration Mobile User Objective System (MUOS),"httpenterprise.spawar.navymil/UploadedFiles/next_gen_muos.pdf

[3] G. Pei, M. Gerla and X. Hong, "LANMAR: LandmarkRouting for Large Scale Wireless Ad-Hoc Networks withGroup Mobility," in Proceedings of IEEE/ACM Mobi-HOC 2000, Boston, MA, Aug. 2000, pp. 11-18.

[4] C. Santivanez, R. Ramanathan, L. Stavrakakis "MakingLink-State Routing Scale for Ad Hoc Networks," Interna-tional Symposium on Mobile Ad Hoc Networking &Computing, Long Beach, CA 2001

[5] T. Clausen, P. Jacquet, "Optimized Link State RoutingProtocol (OLSR)", Internet Draft RFC 3626, Oct. 2003

[6] F. Baker et al, "Problem Statement for OSPF Exten-sions for Mobile Ad Hoc Routing," Internet Draft draft-baker-manet-ospf-problem-statement-00, Sep. 2003

[7] G. Pei, M. Gerla, and T.-W. Chen, "Fisheye StateRouting: A Routing Scheme for Ad Hoc Wireless Net-works," in Proceedings of ICC 2000, New Orleans, LA,Jun. 2000.

[8] M. Gerla, X. Hong, K. Xu, Z. Lu, C. Flores"LANMAR + OLSR: A Scalable, Group Oriented Exten-sion of OLSR," in Proceeding of OSLR Introp & Work-shop, San Diego, CA 2004

[9] C. Perkins, E. Belding-Royer, S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing," IETF RFC3561, Jul. 2003

6 of 6