Radio-to-router interface technology and its applicability on the tactical edge

IEEE Communications Magazine • October 201270 0163-6804/12/$25.00 © 2012 IEEE

This work is sponsored bythe Assistant Secretary ofDefense Research andEngineering (ASD-R&E)through Air Force Con-tract #FA8721-05-C-0002. Opinions,interpretations, recom-mendations and conclu-sions are those of theauthors and are not nec-essarily endorsed by theUnited States Govern-ment.

1 RFC 5578 supersedesRFC 4938 with a fewminor changes. We useRFC4938 and RFC5578interchangeably in thisarticle.

INTRODUCTION

Tactical wireless networks are the primary net-working infrastructure used to provide GlobalInformation Grid (GIG) connectivity towarfighters at the tactical edge. Based on theGIG net-centricity vision, all networks shouldconverge toward an IP-based network infra-structure both from the bottom up using differ-ent types of links and from the top down with allapplication transport converging on IP. Whilerouting IP over fixed infrastructure is well under-stood, the tactical edge poses unique challengesdue to its disconnected, intermittent, and low-bandwidth (DIL) nature. The highly dynamicnature of tactical edge networks provides a num-

ber of challenges related to data transport andservice delivery. These issues include: • Uncompensated channel variation degrad-

ing application performance and prioritiza-tion (quality of service, QoS)

• Routing decision made at IP layer withoutconsidering the underlying channel charac-teristics

• Increased overhead and slower convergencedue to rapid changes in link characteristicsand route information

• A heterogeneous mix of single-purposeradio systems To address the DIL nature of the tactical

edge, researchers and developers have oftenattempted to leverage link layer information(link quality, data rate, latency, etc.) to makebetter multihop routing decisions. In the Depart-ment of Defense (DoD), this has unfortunatelyled to monolithic single-purpose systems thatencompass the entire network stack, makingmixing systems and operating multiple radio sys-tems on a single platform extremely difficult. Inrecent years, there has been a big push in theDoD to modularize systems to provide heteroge-neous networking. One concept is to separatethe radio functionality, which provides one-radiofrequency (RF)-hop links and medium accesscontrol, from the router functionality, which for-mulates end-to-end multihop routes.

To allow for separation of radio and routerwhile leveraging link layer information for bettermultihop routing decisions, standardizing infor-mation exchange between the radio and routersuch that routers can make an informed and uni-form routing decision over heterogeneous linktypes becomes a key area to address. The Inter-net Engineering Task Force (IETF) Request forComment (RFC) 4938 [1] was one of the firstradio-to-router interface (R2RI) mechanismsproposed and backed by industry. Although RFC4938 (now RFC 55781 [2]) represents a goodfirst step toward standardization of the R2RI todynamically share link layer information with thenetwork layer, some issues have been identifiedincluding inefficient medium reuse for broadcastradios, lack of clear radio link metric definitions,and lack of bidirectional communications(router-to-radio as well as radio-to-router).

ABSTRACT

Tactical wireless and mobile networks arethe primary networking infrastructure in theGlobal Information Grid (GIG) to provide end-to-end connectivity to the warfighters at thetactical edge. The highly dynamic nature of tac-tical edge networks raise a number of challeng-ing issues related to data transport and servicedelivery in the tactical environment. To addresssome of these issues, DoD waveforms haveincreasingly leveraged layer 2 link informationto make smart cross-layer multihop routingdecisions. Although there has been some mea-sure of success in providing higher end-to-enddata delivery, the lack of standard interfacesbetween the radio and router have led to inter-operability issues in environments with a het-erogeneous mix of radio systems. As a result,there has been increased desire to standardizeradio-to-router interfaces (R2RIs) as a meansto separate radio and router functionality andto allow greater interoperability between sys-tems. In this article, we examine three R2RIprotocols currently being vetted through theInternet Engineering Task Force and currentlyintegrated or under consideration in DoD radiosystems (RFC 5578, R2CP, and DLEP), andidentify their current use and applicability inthe tactical edge. Furthermore, we identifysome challenges in implementing any R2RIscheme into emerging systems.

TOPICS IN MILITARY COMMUNICATIONS

Bow-Nan Cheng, James Wheeler, and Leonid Veytser, MIT Lincoln Laboratory

Radio-to-Router Interface Technology and ItsApplicability on the Tactical Edge

CHENG2 LAYOUT _Layout 1 9/20/12 4:02 PM Page 70

IEEE Communications Magazine • October 2012 71

Due to the limitations of RFC 4938/5578,new R2RI standards are emerging such asDynamic Link Exchange Protocol (DLEP) [3]and Radio-Router Control Protocol (R2CP) [4]for use in both DoD and commercial applica-tions. As depicted in Fig. 1, R2RIs can be con-densed into three major elements:• The link information the radio can provide• The transport mechanism to get this infor-

mation to the router• How the router makes use of the informa-

tion to make routing decisionsIn this article, we survey the three major

R2RIs being pushed through the IETF (Point-to-Point Protocol over Ethernet [PPPoE] RFC5578, R2CP, and DLEP), identifying thestrengths and weaknesses of each protocol aswell as considerations for integrating R2RI tech-nology into current and emerging tactical edgeradio systems. We briefly describe each of thethree R2RI protocols, and compare and contrasteach, while we examine implications of applyingR2RI to current and emerging DoD radio sys-tems and potential use cases. Finally, we con-clude the article.

POTENTIAL R2RI SOLUTIONSIn the following subsections, we overview RFC5578, R2CP, and DLEP, highlighting advantagesand disadvantages of each at the tactical edge.

PPPOE RFC4938/5578One of the first radio-to-router interfaces usedfor transferring link metrics to an external routeris PPPoE with credit flow and link metrics exten-sions (RFC 4938 [1]). RFC 4938 was supersededby RFC 5578 [2], which added larger reportedrates and a few other small changes. For practi-cal purposes, we utilize RFC 4938 and RFC5578 interchangeably. PPPoE is defined in RFC2516 and uses a series of Active Discovery Pack-ets to dynamically create PPPoE sessions, whichthen allows PPP connections to be formed. RFC4938/5578 defines extensions to PPPoE to pro-vide credit-based flow control and link metrics.The extensions consist of new, optional type-length values (TLVs), and both enhanced andnewly defined discovery packets.

Figure 2 illustrates the basic concept behindRFC 5578. When an RF link is established, theradio, running a PPPoE client, initiates a PPPoEsession with the router running a PPPoE server.Then the router negotiates an end-to-end PPPconnection with the node router on the otherside of the link. At periodic intervals, the radioprobes the link and sends PPPoE Active Discov-ery Quality (PADQ) packets to its local routercontaining link information such as per linklatency, current and maximum data rate(CDR/MDR), relative link quality (RLQ),resources, and neighbor up/down state. Fromthis information, the routers dynamically calcu-late a link cost based on the quality of the linkand the congestion, then weight the path choicesaccordingly. The radio periodically sends creditsand credit grants to the server to throttle therate of data send, implementing a flow controlmechanism. As credits are used up, the packetsare queued per link.

RFC 5578 is currently implemented in HarrisCorporation’s Highband Networking Radio(HNR) system where commercial Cisco routers[5] serve as the PPPoE server, and the radio sub-system acts as the PPPoE client. For legacy sys-tems that do not support RFC 5578, proxysystems were developed that interfaced to vari-ous radio technologies to convert radio inter-faces to RFC 5578-compliant systems as part ofthe Communications AirBorne Layer Expansion(CABLE) Joint Capabilities Technical Demon-stration (JCTD) [6, 7].

Advantages — RFC 5578 is an elegant methodof utilizing existing connections (Ethernetbetween radio and router and PPPoE) to allowradio-to-router information exchange. It wasdesigned primarily for higher-capacity (2 Mb/s+)directional links due to its need to build router-to-router PPP tunnels. The advantages of RFC5578 are as follows: • Easy bypassing of built-in layer 3 routers:

Because RFC5578 builds PPP tunnels fromrouter to router (over radio links), internallayer 3 routers inside radios can easily bebypassed.

• Implementation on commercial routers:RFC 5578 is already implemented on selectCisco and Juniper routers.

• Flow control: Radio systems operate at mul-tiple data rates depending on link quality.RFC 5578 provides a credit-based flow con-trol system to adjust the flow of data fromrouter to radio so as not to overrun theradio with data.

Disadvantages — Although RFC 5578 is usefulfor higher-capacity directional links, there areseveral limitations. These include: • Inefficiency with broadcast radios: The cur-

rent implementation of RFC 5578 repli-cates multicast and broadcast packets acrosseach PPP tunnel associated with each one-hop neighbor. This causes a significantincrease in traffic in networks with broad-cast radios.

• Additional PPP overhead: An additional 2-byte PPP header is added per packet andsent over the air. This adds large overheadto lower-rate links. Additionally, PPP tun-nel setup and maintenance require fairlystable links.

• Requirement of RFC 5578 operation onboth ends: RFC 5578 needs to be run onboth ends of the radio link since end-to-endPPP tunnels need to be formed. This posesproblems for legacy systems that do notsupport RFC 5578.

Figure 1. The three components of the radio-to-router interface.

Routing usinglayer 2 information

Radio-specificlayer 2 information

Radio-to-routertransport mechanism

Radio

1

2

3


IEEE Communications Magazine • October 201272

• Reliance on Ethernet (radio-to-router):Some DoD radios connect to the routerthrough different physical interfaces such asRS-232 serial links and others. The relianceon Ethernet limits the applicability of RFC5578.

• Lack of a proper feed-forward mechanism:Military radio systems often need someinformation about incoming traffic to allo-cate time slots and perform resource man-agement. Currently, RFC 5578 does notallow router-to-radio requests.

• IETF informational: RFC 5578 is only aninformational RFC and is not standardized.

RADIO–ROUTER CONTROL PROTOCOLBecause of the limitations of using RFC 5578 inthe broadcast radio environment, R2CP [4] wasdesigned as an alternative for one-to-many con-nections. R2CP is described in a draft RFC, andprovides sharing radio link metrics between theradio and router using UDP as a control chan-nel. R2CP builds both radio-to-router associa-tions as well as individual sessions to describe aremote neighbor. Unlike RFC 5578, no addition-al overhead is sent over the air.

Figure 3 illustrates the basic concept behindR2CP. When the radio and router are poweredon, the R2CP peer running on the radio formsan association with the R2CP peer running onthe router. This association is kept alive with aheartbeat message, and ties the radio and routertogether. When an actual RF link is establishedbetween local and remote radios, both radiosinitiate an R2CP neighbor session with theirlocal routers to indicate a new link has beenestablished. At periodic intervals, the radioprobes the link and sends to its local routerupdate packets with time-varying link metricssuch as link latency, current and maximum datarate (CDR/MDR), relative link quality (RLQ),resources, and neighbor up/down state. Fromthis information, the routers dynamically calcu-late a link cost based on the quality of the linkand the congestion, then weight the path choicesaccordingly.

R2CP does not have a provision for flow con-

trol and expects the router to perform flow con-trol based on reported data rates. R2CP alsofeatures no feed-forward mechanism for therouter to request additional time slots or band-width, but instead relies on oversubscribing thelink by 10 percent of available data rate in hopesthat the radio will allocate more resources astimes goes on. R2CP is currently specified in theNet-Centric Waveform (NCW) documents withplans to extend to the Highband NetworkingWaveform (HNW).

Advantages — R2CP attempts to address someof the limitations of RFC 5578 and offers thefollowing advantages: • Efficient medium reuse in broadcast radio

environments: Multicast/broadcast packetsare only sent once over the air in broad-cast-capable radios.

• Agnostic physical link technology require-ment: Because R2CP utilizes UDP to per-form radio-to-router communications, it isnot tied to a specific underlying link layer.

• No additional over-the-air overhead: UnlikeRFC 5578, R2CP requires no additionalover-the-air overhead for router-to-routersetup and link maintenance.

• Lack of both ends running R2CP require-ment: R2CP itself does not require bothends of the radio to support R2CP.

• Implementation on commercial routers:R2CP is currently implemented on selectCisco and Juniper routers.

Disadvantages — Although R2CP has manygood characteristics, there are several limita-tions. These include: • Lack of a proper feed-forward mechanism:

Like RFC 5578, R2CP does not have anyfeed-forward mechanism for the router torequest additional time slots or resourcesfrom the radio. Instead, R2CP relies onoversubscribing the link, and the radio toauto-detect oversubscription and allocateresources accordingly.

• Reliance on link-layer-to-IP translation:R2CP requires additional translation

Figure 2. Neighbor setup with RFC5578 and data packet headers.

DataIPPPP

Radio Radio

Point-to-point protocol over Ethernet (PPPoE) RFC5578Neighbor initiate

PPPoE server PPPoE client

1. RF link

4. PADQ5. PADC/PADG

3. Point-to-point protocol (PPP)

RFC5578 Data packet headers

Over-the-air

Radio Hdr Encapsulated data

Router Router

PPPoE client PPPoE server

2. PPPoE2. PPPoE

4. PADQ5. PADC/PADG

RH

Eth Hdr 6B

Router-to-radio

2B IPv4/IPv6 Hdr

Eth PPoE DataIPPPP

Eth Hdr 6B

Radio-to-router

2B IPv4/IPv6 Hdr

Eth PPoE DataIPPPP

Because of the limi-

tations of using RFC

5578 in the broad-

cast radio environ-

ment, R2CP was

designed as an

alternative for one-

to-many connec-

tions. R2CP builds

both radio-to-router

associations as well

as individual sessions

to describe a remote

neighbor. Unlike

RFC5578, no addi-

tional overhead is

sent over-the-air.



between medium access control (MAC)and IP headers using Address ResolutionProtocol (ARP). This can potentially intro-duce additional over-the-air overhead forlink setup, maintenance, and IP data pass-ing.

• Potential requirement to run R2CP on bothends: Although the R2CP protocol itselfdoes not require both ends of the radiorunning the protocol, the draft RFC alsodefines how routers should use the linkmetrics provided by R2CP.

• Lack of flow control mechanism: R2CP relieson reported data rate to implement flow con-trol. In broadcast radio environments, how-ever, the medium is shared, and availabledata rate is heavily dependent on traffic sentby neighbors. As a result, reported currentdata rate (CDR) often does not equate toactual ability to send traffic. Additional flowcontrol mechanisms should be employedwhich examines radio queues and backlog.

• IETF informational: R2CP is only an infor-mational RFC and not standardized.

DYNAMIC LINK EXCHANGE PROTOCOL

Dynamic Link Exchange Protocol [3] was devel-oped to address some of the limitations of bothRFC 5578 and R2CP. DLEP is described in astandards track draft RFC, and defines radiolink metrics between the radio and router usinga generalized mobile ad hoc network (MANET)packet/message format (RFC 5444) [8] as a con-trol channel. DLEP simplifies many of the radio-to-router signaling requirements and generalizesthe interface to other physical media. Becausethe DLEP draft is a standards track RFC, it iscurrently undergoing changes based on discus-sions and implementations. As of draft 02, muchof the functionality of DLEP and R2CP are sim-ilar in that no additional overhead is sent overthe air.

Figure 4 illustrates the basic concept behindDLEP. When the radio and router are poweredon, the DLEP peer running on the radio formsan association with the DLEP peer running onthe router. This association is kept alive with aheartbeat message, and ties the radio and routertogether. When a local radio/modem device

Figure 3. Neighbor setup with R2CP and data packet headers.

Radio-router control protocol (R2CP)Neighbor initiate

Peer session Peer session

Local node Remote node

DataIP

Radio

3. Neighbor update msg 3. Neighbor update msg

Radio

R2CP Router peer R2CP Radio peer

1. RF link

R2CP Data packet headers

Over-the-air


Router Router

R2CP Radio peer R2CP Router peer

2. R2CP2. R2CP

RH

Eth Hdr

Router-to-radio

Eth

Eth Hdr

Radio-to-router

Eth

IPv4/IPv6 Hdr

DataIP

IPv4/IPv6 Hdr

DataIP

Figure 4. Neighbor setup with DLEP and data packet headers.

Dynamic link exchange protocol (DLEP)Neighbor initiate

Peer session Peer session

Local node Remote node

DataIP

Radio

3. Neighbor update msg 3. Neighbor update msg

Radio

DLEP Router peer DLEP Radio peer

1. RF link

DLEP Data packet headers

Over-the-air


Router Router

DLEP Radio peer DLEP Router peer

2. DLEP 2. DLEP

4. Router request msg 4. Router request msg

RH

Eth Hdr

Router-to-radio

Eth

Eth Hdr

Radio-to-router

Eth

IPv4/IPv6 Hdr

DataIP

IPv4/IPv6 Hdr

DataIP

R2CP features no

feed-forward mecha-

nism for the router

to request additional

timeslots or band-

width, but instead

relies on oversub-

scribing the link by

10 percent of avail-

able data rate in

hopes that the radio

will allocate more

resources as times

goes on.



detects the presence of a remote node via theRF connection, it sends an indication to its localrouter via the DLEP session to indicate a neigh-bor up. This neighbor initiate message relays theremote node router’s MAC address and, option-ally, the IPv4 or IPv6 address associated with theinterface facing the remote radio. Upon receiptof the indication, the local router takes theappropriate action (e.g., initiation of discoveryor hello protocols) to converge the network.After notification of the new neighbor, the localmodem/radio utilizes the DLEP session to reportthe characteristics of the link such as latency,current and maximum data rate (CDR/MDR),relative link quality (RLQ), resources, andexpected forwarding time (EFT) via NeighborUpdate messages. If the remote node RF con-nection is lost, the local radio/modem subse-quently notifies the router of the loss of theremote neighbor, shortening the time requiredto reconverge the network.

Draft 02 of DLEP differentiates itself fromR2CP in a number of ways. Unlike R2CP, DLEPallows the router to request additional band-width/time slots and latency constraints from theradio. Additionally, options for credit-based flowcontrol similar to RFC 5578 have been added todraft 02, and its usage is currently being debatedin the IETF MANET working group. Finally,DLEP allows the flexibility to not only describeneighbor relationships with unicast IP addresses,but multicast groups as well, leading to potentialusage in describing multicast group links. DLEPis currently being evaluated by several vendorsand implemented in select Cisco routers.

Advantages — DLEP attempts to addresssome of the limitations of RFC 5578 and R2CP,and offers the following advantages: • Efficient medium reuse in broadcast radio

environments: Multicast/broadcast packetsare only sent once over the air in broad-cast-capable radios.

• Agnostic physical link technology require-ment: Because DLEP utilizes RFC 5444packet/message formats to perform radio-to-router communications, it is not tied to aspecific underlying link layer.

• No additional over-the-air overhead: DLEPrequires no additional over-the-air over-head for router-to-router setup and linkmaintenance.

• Lack of both ends running DLEP require-ment: The DLEP protocol does not requireboth ends of the radio to support DLEP.

• Implementation on commercial routers:DLEP is currently implemented on selectCisco routers.

• IETF proposed standard: DLEP is a stan-dards-track RFC and undergoing revisionsin the IETF MANET working group.

• Feed-forward mechanism: DLEP describesa feed-forward mechanism to allow therouter to request resources from the radio.

• Credit-based flow control mechanism: Draft02 of DLEP includes an optional credit-based flow control system.

• Multicast group neighbors: Draft 02 ofDLEP allows neighbor sessions to describemulticast groups, enabling flexibility.

Disadvantages — Although DLEP has manygood characteristics, there are a few limitations.These include: • Lack of a flow control mechanism: In the

original DLEP draft (00 and 01), DLEPrelied on reported data rate to implementflow control. Unfortunately, in broadcastradio environments, the medium is shared,and reported available data rate is heavilydependent on traffic sent by neighbors. Asa result, reported current data rate (CDR)often does not equate to actual ability tosend traffic. Additional flow control mecha-nisms should be employed that examineradio queues and backlog. In draft 02,DLEP added a credit-based flow controlsystem. Additional research is needed tounderstand whether this system is appropri-ate for MANETs operating in a broadcastmedium.

• Support for various rates and power levelsper neighbor: This issue is described inmore detail later.

• In draft form: DLEP is currently in draftform as a standards track IETF documentin the MANET working group. As a result,there are constant changes in the draft.

SUMMARYTable 1 compares the characteristics of the threeprotocols and current implementations. In com-paring the protocols, there are several key dis-tinctions: • RFC 4938/5578 builds additional PPP tun-

nels router-to-router while R2CP andDLEP does not.

• RFC 4938/5578 was designed primarily forpoint-to-point connections while R2CP andDLEP were designed for point-to-multi-point connections.

• All the protocols define the same metricswith the exception of DLEP experimentingwith other link metrics (EFT).

• RFC 4938/5578 offers a credit-based flowcontrol system, while R2CP and DLEPinherently utilize a rate-based flow controlsystem. The latest DLEP draft (02) offersan optional credit-based system.

• Whereas RFC4938/5578 and R2CP provideradio-to-router communications, DLEPallows for bidirectional communicationsbetween the radio and router, allowinggreater flexibility. Although each of the protocols has its trade-

offs, understanding the operating conditions andunderlying link characteristics are important tochoose the best one.

R2RI CONSIDERATIONS AT THETACTICAL EDGE

Although abstracting the radio (providing thebest one-hop RF link and mediating mediumaccess) from the router (providing the best mul-tihop path based on link metrics) can lead togreater modularity, several considerations mustbe examined as it pertains to DoD tactical edgesystems. In the following subsections, we attempt

DLEP allows the flexi-

bility to not only

describe neighbor

relationships with

unicast IP addresses,

but multicast groups

as well, leading to

potential usage in

describing multicast

group links. DLEP is

currently being eval-

uated by several

vendors and imple-

mented in select

Cisco routers.



to highlight some of the implications of applyingthe R2RI architecture on current and emergingDoD waveforms.

RADIOS’ BRIDGE-MODE CAPABILITYMany current military and some commercialradio systems have built-in routers that performlayer 2 (intra-subnet) or layer 3 multihop rout-ing. While there are techniques that can be usedto bypass these built-in routers, a basic assump-tion of R2RI is that future systems will allowbypassing of built-in multihop routing tech-niques, allowing the radio to merely act as alayer 2 RF link.

UNIFIED LINK METRICSThe DoD employs dozens of radio systems thatdefine link quality in very different ways. Whentranslating link metrics into the five defined linkmetrics in each of the R2RI protocols, it is easy tomap radio link metrics to R2RI link metrics differ-ently for each system. Clearer definition of linkmetrics and default values are needed to ensureapples-to-apples comparison of link metrics. One

potential option is to define a small subset ofrequired link metrics that have very specific defini-tions and are common across radio systems whileproviding options to define vendor-specific metricsthat can potentially be used to aid multihop rout-ing in a homogeneous radio environment.

SMALL RADIO TRANSMIT BUFFEROne difficulty in utilizing several DoD radio sys-tems together is that each system employs sepa-rate QoS and complex queues at the radio. Thegoal of any R2RI architecture is to allow therouter to perform QoS and prioritization andqueuing, and allow radios to build simple andshort queues. Essentially, all complex queuingshould be performed at the router because it canchoose multiple links, while each link is responsi-ble only for keeping enough packets in the bufferfor appropriate medium access negotiations.

FLOW CONTROLBecause the radio typically operates at a lowerdata rate than the R2RI, the radio needs to beable to provide some sort of flow control to the

Table 1. Radio-to-router interface (R2RI) protocol comparison.

RFC 4938/5578 R2CP DLEP

RFC type Informational Informational Standards track

RFC status RFC 5578 Draft 00 Draft 02

Authors’ organization(s) Cisco, Harris, L-3 Cisco, Juniper, GD C4 Systems, L-3 Cisco

PHY and link layer Ethernet, PPPoE Ethernet, 802.1Q VLANs Unspecified external or internal

Control channel PPPoE Frames UDP/IP RFC5444 Messages Transportnot specified

Current radio-sideimplementations

Harris HNR radio, JC4ISR radio(BAE, Harris, L-3), MITLL R2RIproxy

JC4ISR radio (BAE, Harris, L-3),L-3 MPM-1000 NCW SATCOM,MITLL R2RI proxy

MITLL R2RI proxy

Current router-sideimplementations

Select Cisco routers, selectJuniper routers, several opensource implementations

Select Cisco routers, select Juniperrouters, several open sourceimplementations

Select Cisco routers, severalopen source implementations

Suited for media type Point-to-point, layer 2 or layer 3 Broadcast/multicast, point-to-point layer 2

Broadcast/multicast, point-to-point layer 2

Initiated by radio(does not includeresponses or Acks)

Neighbor up/downmetricsFlow control credits

Neighbor up/downmetricsTermination

Neighbor up/downmetrics

Initiated by router toradio Flow control credits Termination Link characteristic request

Metrics MDR, CDR, latency, resources,RLQ

MDR, CDR, latency, resources,RLQ

MDR, CDR, latency, resources,RLQ, EFT

Metric use by router Unspecified for routingcredit-based flow control

Specified OSPF link cost flowcontrol (rate shaping) Unspecified

Flow controlCredit-based(if supported by both client andserver)

Radio informs router of data rateit wants, intentionally oversub-scribing the link. Router sendsamount the radio requested

OptionalCredit-based



router to throttle data. Many mechanisms areavailable including credit-based flow control,rate-based flow control, and pause-frame-based[9] flow control. Although these mechanismsprovide a good first cut at limiting data from therouter, broadcast radios where the medium isshared offer unique challenges. In short, operat-ing data rate does not accurately correlate toachievable data throughput. R2RI should adoptsome notion of flow control that attempts toaccurately throttle traffic between the router andthe radio.

VARIABLE RATE AND POWER RADIO SYSTEMSAlthough R2RI should support dynamic linkmetrics between a pair of neighbors (local andremote), it is unclear how R2RI would supportcases where radio systems have the ability todynamically adjust rate and power levels for vari-ous traffic patterns between one pair of neigh-bors as is the case with many DoD radio systems.The R2RI framework should ideally define a setof link metrics shared between the radio and therouter, but how those link metrics translate tothe multiple power/rate options is unclear. Addi-tional work is necessary to understand howR2RI can accommodate radio links that supportmultiple rates and multiple power levels for onepair of neighbors at one time.

R2RI HANDLING OF MULTICAST FLOWSIt is possible that radios systems can potentiallysend multicast and unicast traffic at differingrates. While R2RI effectively describes potentialunicast traffic flow between a pair of neighbors,rates provided by multicast flows might differdue to resource availability, desire to reach addi-tional neighbors, and so on. Furthermore, manyDoD systems allow different multicast flows tobe sent with different rate and power, resultingin the ability to reach different nodes. There hasbeen some thought to provide additional radio-to-router connections based on multicast groups(as in DLEP draft 02), but additional work isneeded to clarify whether this approach oranother is more appropriate.

LINK METRIC DAMPENING AND HYSTERESISProviding instantaneous link metric informationfrom radio to router can potentially be disadvan-tageous if routing protocols act immediately onhighly jittery link metrics. Additional discussionis needed on link metric dampening and hystere-sis, and whether it should be done prior to theradio reporting to the router or by the routingprotocol. If it is the R2RI’s responsibility to pro-vide link metric hysteresis and dampening, aclear description of which metrics need whatdampening factors is needed. In previous work[6, 7] a combination of a 3 s link up/down hys-teresis, and link metric bucketing and averagingis used to dampen link metric churn.

RADIO AND ROUTER BI-DETERMINATION OFLINK AVAILABILITY

R2RI can potentially cause an inconsistent viewof link state between the router and radio. Forexample, if the R2RI reports a link to be downdue to high packet loss, and the router, using

router-level hello packets, manages to send dataover the air successfully, the router can poten-tially think the link is available while the R2RIdoes not. This causes an inconsistent view of linkup/down state. It is important, therefore, foreither the radio or the router to determine linkavailability, but not both. In recent work [10],the problem was addressed by actively denyingtraffic over a link when the radio believed thelink to be down. While effective in the shortterm, this solution limited some traffic. Addi-tional work is needed to ensure consistent stateor limit traffic to what the R2RI reports.

LINK LOAD AFFECT ON LINK METRICSIf routing decisions are made in part due toreported link metrics, and some link metrics(e.g., latency) are potentially affected by linktraffic load, a potential issue could occur where-by load is transferred from link to link, causingroute flapping. Ideally, defined metrics shouldnot be affected by traffic load, but additionalwork is needed to understand traffic load’s effecton link metrics.

MULTI-TOPOLOGY QOS ROUTINGWhile providing per link metrics from radio torouter is helpful in dynamic routing, when multi-ple radio systems and links are used, routingprotocols should take advantage of each link/interface/system simultaneously and use QoS tomap certain traffic toward certain end-to-endroutes. For example, if the R2RI reports linklatency and operating data rate, the routershould use the two metrics provided to generatemultiple routes (one based on highest data rateand one based on lowest latency), and map selecttraffic to high-data-rate paths and select trafficto low-latency paths. This area needs to beexplored in greater detail.

CONCLUSIONMilitary networks connected to the GIG at thetactical edge operate in a disconnected, intermit-tent, and low-bandwidth environment. In con-trast to wired networks, the radio systems andwaveforms that operate in this environmentoften rely on dynamic and instantaneous linklayer information to effectively route data end toend. In this article, we overview three of themajor radio-to-router interfaces being vettedthrough the IETF (RFC 5578, R2CP, DLEP),comparing and contrasting the strengths andweaknesses of each protocol and usefulness tothe DoD. Additionally, a review of several poten-tial issues and areas to address in integratingR2RI into existing and emerging DoD wave-forms is given. Overall, although the R2RI pro-tocols provide a good step to allowing a commonstandard interface between radio and router,there is still some work needed to apply them toDoD requirements.

REFERENCES[1] B. Berry and H. Holgate, “PPP Over Ethernet (PPPoE)

Extensions for Credit Flow and Link Metrics,” IETF, RFC4938, 2007, http://www.ietf.org/rfc/rfc4938.txt.

[2] B. Berry et al., “PPP Over Ethernet (PPPoE) Extensionsfor Credit Flow and Link Metrics,” IETF RFC 5578, 2010,available: http://www.ietf.org/rfc/rfc5578.txt.

The R2RI framework

should ideally define

a set of link metrics

shared between the

radio and router, but

how those link met-

rics translate to the

multiple power/rate

options is unclear.

Additional work is

necessary to under-

stand how R2RI can

accommodate radio

links that support

multiple rates and

multiple power levels

for one pair of

neighbors at

one time.



[3] S. Ratliff et al., “Dynamic Link Exchange Protocol(DLEP),” IETF Internet draft 02, 2012, work in progress,http://tools.ietf.org/html/draft.ietf-manet-dlep-02.

[4] D. Dubois et al., “Radio-Router Control Protocol(R2CP),” IETF Internet draft 00, 2011, work in progress,http://tools.ietf.org/html/draft-dubois-r2cp-00.

[5] “Mobile Ad Hoc Networks for Router-to-Radio Commu-nications,” Cisco Systems, tech. rep., 2007, http://www.cisco.com/en/US/docs/ios/12_4t/ip_mobility/configura-tion/guide/ip_manet.html.

[6] B.-N. Cheng et al., “Characterizing Routing with Radio-to-Router Information in an Airborne Network,” IEEEMILCOM ’11, Nov. 2011.

[7] B.-N. Cheng et al., “Evaluation of a Multi-hop AirborneIP Backbone with Heterogeneous Radio Technologies,”ACM Mobihoc Airborne Networks and Commun. Wksp.2012, June 2012.

[8] T. Clausen et al., “Generalized Mobile Ad Hoc Network(MANET) Packet/Message Format,” IETF RFC 5444,2009, http://www.ietf.org/rfc/rfc5444.txt.

[9] M.-C. Wang, S. Davidson, and S. Mohan, “Design Con-sideration of Router-to-Radio Interface in Mobile Net-works,” IEEE MILCOM ’11, Nov. 2011.

[10] B.-N. Cheng et al., “Comparing Radio-to-Router Inter-face Implementations on Experimental CoTs and OpenSource Routers,” IEEE MILCOM ’12, Oct. 2012.

BIOGRAPHIESBOW-NAN CHENG ([email protected]) is a member of tech-nical staff in the Airborne Networks Group at MIT LincolnLaboratory. His research interests include design, develop-ment, prototyping, and test and evaluation of next genera-

tion routing solutions for airborne backbone and tacticalnetworks. Recent work has focused heavily on radio-awarerouting which leverages link layer information at the net-work layer to enhance multihop MANET routing. Hereceived M.S. and Ph.D. degrees in computer systems engi-neering from Rensselaer Polytechnic Institute, and holds aB.S. degree in electrical engineering from the University ofIllinois at Urbana-Champaign.

JAMES WHEELER ([email protected]) is a network archi-tect with BT Federal, Inc., and has been a consultant to theAirborne Networks Group at MIT Lincoln Laboratory since2008. Having received his B.S. in mechanical engineeringand a commission as a U.S. Air Force Officer from NorwichUniversity in Vermont in 1986, he served at what was thenthe Electronic Systems Division of Air Force Systems Com-mand at Hanscom AFB, Massachusetts, supporting theacquisition of both airborne and ground radios. He hassubsequently worked in various technical roles related tocommunications and networking accumulating over 25years of experience with both commercial and DoD sys-tems. Among other industry certifications, he has been aCisco Certified Internetwork Expert (CCIE No. 8194) since2001.

LEONID VEYTSER ([email protected]) is a member of the Air-borne Networks Group at MIT Lincoln Laboratory. Hisresearch interests include routing and distributed comput-ing in disadvantaged wireless networks. His recent workhas focused on enhancing application performance at thetactical edge as well as radio-aware routing in airborneand tactical networks. He received his B.A. and M.A.degrees in computer science from Boston University.


Documents

Radio-to-router interface technology and its applicability on the tactical edge