Internet DRAFT - draft-bcheng-r2ri-framework
draft-bcheng-r2ri-framework
INTERNET-DRAFT B. Cheng
Intended Status: Informational L. Veytser
Expires: August 15, 2012 D. Ward
MIT Lincoln Laboratory
February 13, 2012
Radio to Router Interface Framework and Requirements
draft-bcheng-r2ri-framework-00
Abstract
In highly dynamic, heterogeneous radio MANET environments where links
are constantly changing, standardizing information exchange between
the radio and router such that routers can make informed routing
decision based on link layer information over heterogeneous link
types becomes a key area to address. This document defines the basic
framework for radio-to-router interface communications as well as
requirements and considerations for evaluating radio-to-router
interface technologies for use in MANETs.
Disclaimer
This work is sponsored by the United States Air Force under Air Force
Contract FA8721-05-C-0002. Opinions, interpretations, conclusions
and recommendations are those of the authors and are not necessarily
endorsed by the United States Government.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
B. Cheng et al. Expires August 15, 2012 [Page 1]
INTERNET DRAFT R2RI Framework and Requirements January 2012
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2. R2RI Framework Description . . . . . . . . . . . . . . . . . . 4
2.1 R2RI Scope . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Radio Bridge-Mode Capability . . . . . . . . . . . . . . . 5
3.2 Radio Broadcast and Multicast 1 Hop Support . . . . . . . . 6
3.3 Radio Provisions to Obtain Required Link Metrics . . . . . 6
3.4 Radio Provisions to Exchange IPv4, IPv6 and MAC-level
Identifiers . . . . . . . . . . . . . . . . . . . . . . . . 6
3.5 Radio Transmit Buffer Size . . . . . . . . . . . . . . . . 6
3.6 Router Provisions for Utilizing Link Metrics . . . . . . . 6
3.7 Router Provisions for Supporting Flow Control . . . . . . . 7
3.8 Router Logically Separate from Radio . . . . . . . . . . . 7
3.9 Radio-to-Router Connection Bandwidth vs. Over-the-Air
Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 R2RI MUST operate over multiple link layer formats . . . . 7
4.2 R2RI MUST REQUIRE a small (less than 7) subset of
REQUIRED link metrics . . . . . . . . . . . . . . . . . . . 7
4.3 R2RI SHOULD provide for optional link metrics . . . . . . . 8
4.4 R2RI SHOULD be extensible for new optional link metrics . . 8
4.5 R2RI MUST provide transparent unicast and multicast
bridging . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.6 R2RI SHOULD NOT REQUIRE additional "over-the-air" overhead
in coordination or header information . . . . . . . . . . . 8
B. Cheng et al. Expires August 15, 2012 [Page 2]
INTERNET DRAFT R2RI Framework and Requirements January 2012
4.7 R2RI SHOULD NOT REQUIRE on both local and remote ends
running the protocol . . . . . . . . . . . . . . . . . . . . 8
4.8 R2RI SHOULD NOT REQUIRE a need to modify radio and router
connection hardware . . . . . . . . . . . . . . . . . . . . 8
4.9 R2RI MUST provide ability to exchange bi-directional link
metrics . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.10 R2RI SHOULD clearly define REQUIRED link metrics and
default values if configurable for required link metrics . 9
4.11 R2RI SHOULD should gracefully handle crashes . . . . . . . 9
4.12 R2RI SHOULD support separate or concurrent control
channel operation . . . . . . . . . . . . . . . . . . . . . 9
4.13 R2RI SHOULD NOT send additional headers over-the-air . . . 9
4.14 R2RI SHOULD provide flow control between the radio and
router . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.15 R2RI SHOULD authenticate session between radio and router . 10
5 Additional Considerations . . . . . . . . . . . . . . . . . . . 11
5.1 Variable Rate and Power Radio Systems . . . . . . . . . . . 11
5.2 R2RI Handling of Multicast Flows . . . . . . . . . . . . . . 11
5.3 Link Metric Dampening and Hysteresis . . . . . . . . . . . . 11
5.4 Radio and Router Bi-Determination of Link Availability . . . 11
5.5 Link Load Affect on Link Metrics . . . . . . . . . . . . . . 12
5.6 Flow Control Issues . . . . . . . . . . . . . . . . . . . . 12
5.7 Connection-Based vs. Connection-Less Radios . . . . . . . . 12
5.8 Multi-Topology QoS Routing . . . . . . . . . . . . . . . . . 13
6 Security Considerations . . . . . . . . . . . . . . . . . . . . 13
7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1 Normative References . . . . . . . . . . . . . . . . . . . 13
8.2 Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
B. Cheng et al. Expires August 15, 2012 [Page 3]
INTERNET DRAFT R2RI Framework and Requirements January 2012
1 Introduction
In a highly dynamic MANET environment where links and link quality
are constantly changing, link-layer feedback has become increasingly
important in enabling effective dynamic multi-hop routing decisions.
Additionally, due to instabilities in the wireless domain, often
times, a heterogeneous mixture of radio systems are needed to provide
adequate connectivity. The result is an increasing need to
standardize information exchange between the radio and the router
such that routers can make informed and uniform routing decisions of
heterogeneous wireless link types.
The goal of this document is to define the radio-to-router interface
framework architecture as well as lay out a set of requirements for
which to evaluate proposed radio-to-router interface technologies for
use in heterogeneous MANETs.
1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. R2RI Framework Description
|-----Local Neighbor-----| |-----Remote Neighbor----|
| | | (far-end device) |
+--------+ +-------+ +-------+ +--------+
| Router |=======| Radio |{~~~~~~~~}| Radio |=======| Router |
| Peer | | Peer | | Peer | | Peer |
+--------+ +-------+ +-------+ +--------+
| | | Link | | |
|--R2RI-| | Protocol | |-R2RI--|
| | | (e.g. | | |
| | | 802.11) | | |
Figure 1: R2RI Framework
The radio-to-router interface (R2RI) defines the communications
signalling between the radio which describes a one-hop link and the
router which performs multi-hop routing. Figure 1 describes the R2RI
framework. Given two physical nodes communicating over a wireless
medium through radios running a generic link protocol, we define:
o Router Peer - The end-point of the radio-to-router interface
that resides logically on the router side. In previous work such
B. Cheng et al. Expires August 15, 2012 [Page 4]
INTERNET DRAFT R2RI Framework and Requirements January 2012
as [RFC5578], the Router Peer has been referred to as the Server.
o Radio Peer - The end-point of the radio-to-router interface that
resides logically on the radio side. In previous work such as
[RFC5578], the Radio Peer has been referred to as the Client. The
radio peer can reside either physically on the radio system or on
a proxy system that translates radio information into R2RI
language.
o Local Neighbor - The node comprising of a radio and its
associated router pair existing on one logical platform. The radio
and router pair are connected through wired connections
o Remote Neighbor - The node comprising of a router and radio pair
existing on one logical platform on the far-end of the RF link
Based on the previous definitions, the radio-to-router interface
(R2RI), therefore, is a protocol comprised of a set of messages,
message exchanges, and actions dedicated to passing layer 2 link
and radio information obtained by the radio to the router and
layer 3 network information about traffic flows and requests to
the radio. The goal of the R2RI is to provide a common and
extendable framework to share key information between the radio
and router to enable effective multi-hop routing and flow control
in a heterogeneous wireless network.
2.1 R2RI Scope
The R2RI framework SHOULD define only transmissions between the
radio and the router including the metrics required to be supplied
by the radio and the transport mechanism between radio and router.
The R2RI framework does not define how the multi-hop routing
protocol utilizes link metrics in routing nor does it define how
the radio should obtain link metric information. Additionally,
several pieces of information from remote neighbors are at times
required for link setup and informing the R2RI radio peer. The
R2RI framework does NOT define any additional over-the-air
signaling between local and remote radio pairs and leaves
individual implementations to the over-the-air link protocol.
3. Assumptions
The R2RI framework makes several assumptions on both the radio and
router side. These are listed in the following subsections.
3.1 Radio Bridge-Mode Capability
B. Cheng et al. Expires August 15, 2012 [Page 5]
INTERNET DRAFT R2RI Framework and Requirements January 2012
Many current military and some commercial radio systems have
built-in routers that perform layer-2 (intra-subnet) or layer-3
multi-hop routing. While there are techniques that can be used to
bypass these built-in routers, we assume that in the future,
functionality will be built into radio systems to allow bypassing
of built-in multi-hop routing techniques and allow the radio to
act as a layer 2 one RF hop bridge.
3.2 Radio Broadcast and Multicast 1 Hop Support
We assume that given IP broadcast and IP multicast packets, the
radio has the ability to pass the data to its 1-hop neighbors and
does NOT do additional relaying without passing the packet to the
multi-hop router.
3.3 Radio Provisions to Obtain Required Link Metrics
Although any proposed R2RI will define required link metrics for
radio systems to provide, it will NOT define provisions for
acquiring or measuring the RF link for required metrics. It is
assumed that radio systems will measure or acquire the information
directly or indirectly through radio-specific signaling.
3.4 Radio Provisions to Exchange IPv4, IPv6 and MAC-level Identifiers
To be able to allow the radio to act as a transparent layer-2
bridge, the remote router MAC addresses and IPv4/IPv6 addresses
need to be known. Although R2RI might require this information to
initialize per neighbor R2RI link metric sharing between the radio
and router, we assume that the radio obtains this information
through its own signaling.
3.5 Radio Transmit Buffer Size
Managing flow control and QoS at multiple layers of the network
stack is an extremely complicated process. Ideally, QoS should be
managed at the layer which handles multi-hop transmissions and
short queues implemented in lower layers. R2RI protocols can
therefore assume that flow control is managed top-down and not
additionally re-managed at lower layers.
3.6 Router Provisions for Utilizing Link Metrics
R2RI only defines the interface for the radio and router to
exchange link metric and other relevant information. It does not,
however, define how the router should use this information. There
are many techniques employed today in industry and military radio
systems. R2RI assumes that routers either have a provision to
B. Cheng et al. Expires August 15, 2012 [Page 6]
INTERNET DRAFT R2RI Framework and Requirements January 2012
utilize this per link information in routing, or can be put in a
state to simply ignore this information.
3.7 Router Provisions for Supporting Flow Control
R2RI will define metrics for providing flow control between the
radio and router based on radio queues and other information. The
R2RI will NOT, however, define how the router utilizes queue
information to provide flow control. R2RI will assume that the
router is capable of utilizing this information to provide flow
control as needed or have the ability to discard the information
elegantly if not needed.
3.8 Router Logically Separate from Radio
The primary benefit of R2RI is the ability to make routing
decisions regarding different radio links, including links from
disparate heterogeneous radio technologies.
3.9 Radio-to-Router Connection Bandwidth vs. Over-the-Air Bandwidth
It is assumed that the available bandwidth between the radio and
router physical connection is significantly higher than the over-
the-air bandwidth available for data transmission. This ensures no
bottleneck in control traffic transmission between the radio and
router.
4. Requirements
To evaluate the R2RI framework, any proposed R2RI protocols MUST
satisfy all requirements listed in the following subsections.
4.1 R2RI MUST operate over multiple link layer formats
Radio systems utilize various connection technologies between a
radio and router system from Ethernet (802.3), Serial link (RS-
232), and others. R2RI MUST be adaptable to all connection
technologies between a radio and router and function independently
of the underlying technology.
4.2 R2RI MUST REQUIRE a small (less than 7) subset of REQUIRED link
metrics
Radios provide a wide range of link information depending on the
underlying link layer technology. Some of the link metrics are
specific to the link layer technology and others are standard
across the varying format. These include link latency, operating
B. Cheng et al. Expires August 15, 2012 [Page 7]
INTERNET DRAFT R2RI Framework and Requirements January 2012
data rate, signal-to-noise ratio, and others. Requiring a small
number of required link metrics keeps the list manageable and
allows router manufacturers to be able to provide apples-to-apples
comparison of different radio links.
4.3 R2RI SHOULD provide for optional link metrics
In addition to standard radio link metrics all radio systems
provide, certain radio systems provide link metrics unique to
their system that can potentially be leveraged to enhance multi-
hop routing. R2RI should provide the option for these link
metrics.
4.4 R2RI SHOULD be extensible for new optional link metrics
Custom link metrics a radio provides should be future-proof and
allow new metrics to be passed through standard type-length-
vectors (TLVs). Although these metrics are optional and not
required, it allows radios to provide additional radio-specific
information the router to aid in routing decisions.
4.5 R2RI MUST provide transparent unicast and multicast bridging
In order for many standard and MANET routing protocols to
function, the router must see the radio link as a single layer-2
hop. Multi-hop routing is performed on top of this 1-hop link.
4.6 R2RI SHOULD NOT REQUIRE additional "over-the-air" overhead in
coordination or header information
Because R2RI deals with information sharing between a radio and
router on the same platform, no state synchronization between
local and remote routers should be required. In particular, R2RI
functionality should not be dependent on remote R2RI state.
4.7 R2RI SHOULD NOT REQUIRE on both local and remote ends running the
protocol
Because many systems run legacy radios that cannot be easily
modified to support R2RI, a use case might occur where a local
platform might connect to a radio that does not run R2RI. In such
cases, a connection should still be able to be formed. The affect
on routing protocols in this case is beyond the scope of R2RI.
4.8 R2RI SHOULD NOT REQUIRE a need to modify radio and router connection
hardware
Any R2RI should be primarily a software modification and not
B. Cheng et al. Expires August 15, 2012 [Page 8]
INTERNET DRAFT R2RI Framework and Requirements January 2012
require hardware changes.
4.9 R2RI MUST provide ability to exchange bi-directional link metrics
R2RI must provide ability to exchange link metrics from radio-to-
router (feed back) and should also provide link metrics from
router-to-radio (feed forward). In order to provide proper flow
control the radio must be able to tell the router to throttle data
being sent to it. At the same time, if the router has a large
amount of data to send to a particular neighbor, it might need to
request additional bandwidth from the radio as is the case in TDMA
schemes. The router, therefore, should be able to communicate its
need to the radio, requiring bi-directional link metric exchange.
Other examples exist of the need for bi-directional metrics
exchange between radio and router.
4.10 R2RI SHOULD clearly define REQUIRED link metrics and default values
if configurable for required link metrics
One of the goals of required link metrics is to be able to give
the router the ability to compare disparate link technologies in a
standard way. Overly broad definitions of metrics leads radio
systems to interpret how to form their metrics. As such, link
metrics should be accompanied by specific definitions and default
values.
4.11 R2RI SHOULD should gracefully handle crashes
Any R2RI relies on communication between Radio Peer and Router
Peer. If one side stops communications, a method is required to
re-establish the communications to continue passing of metrics.
4.12 R2RI SHOULD support separate or concurrent control channel
operation
Radio-to-Router communications should be able to occur between the
Radio Peer and Router Peer on the same or separate physical
channel as the data path. This allows for potential separation of
data traffic vs. R2RI signaling traffic on platforms where
separate connections can occur.
4.13 R2RI SHOULD NOT send additional headers over-the-air
The radio-to-router communication should be between the radio and
router alone and should not require any additional headers to be
sent by packets over the air. Additionally, R2RI should not
require additional headers on data packet flows between radio and
router
B. Cheng et al. Expires August 15, 2012 [Page 9]
INTERNET DRAFT R2RI Framework and Requirements January 2012
4.14 R2RI SHOULD provide flow control between the radio and router
Because the radio typically operates at a lower data rate than the
radio-to-router interface, the radio needs to be able to provide
some sort of flow control to the router to throttle data. Many
mechanisms are available including credit based flow control, rate
based flow control, and pause-frame based flow control. Although
these mechanisms provide a good first-cut at limiting data from
the router, broadcast radios where the medium is shared, offer
unique challenges. In short, operating current data rate does not
accurately correlate to achievable data throughput. R2RI should
adopt some notion of flow control that attempts to accurately
throttle traffic between the router and radio.
4.15 R2RI SHOULD authenticate session between radio and router
Although the radio and router are typically on the same platform,
there is potential for an adversary to compromise the connection
between radio and router. R2RI SHOULD provide some rudimentary
session authentication between the radio and router or point to
other standards implemented by the underlying link layer between
radio and router.
B. Cheng et al. Expires August 15, 2012 [Page 10]
INTERNET DRAFT R2RI Framework and Requirements January 2012
5 Additional Considerations
In addition to the assumptions and requirements given in previous
sections, there are some additional considerations for R2RI that
are potential issues for discussion
5.1 Variable Rate and Power Radio Systems
Although R2RI should support dynamic link metrics between a pair
of neighbors (local and remote), it is unclear how R2RI would
support cases where radio systems have the ability to dynamically
adjust rate and power levels for various traffic patterns between
one pair of neighbors as with many DoD radio systems. The R2RI
framework should ideally define a set of link metrics shared
between the radio and router, but how those link metrics translate
to the multiple power/rate options is unclear. Additional work is
necessary to understand how R2RI can accommodate radio links that
support multiple rates and multiple power levels for one pair of
neighbors at one time.
5.2 R2RI Handling of Multicast Flows
It is possible that radios systems can potentially send multicast
and unicast traffic at differing rates. While R2RI effectively
describes potential unicast traffic flow between a pair of
neighbors, rates provided by multicast flows might differ due to
resource availability, desire to reach additional neighbors, etc.
There has been some thought to provide additional radio-to-router
connections based on multicast groups, but additional work is
needed to clarify whether this approach or another is more
appropriate.
5.3 Link Metric Dampening and Hysteresis
Providing instantaneous link metric information from radio to
router can potentially be disadvantageous if routing protocols act
immediately on highly jittery link metrics. Additional discussion
is needed in link metric dampening and hysteresis and whether it
should be done prior to the radio reporting to the router or by
the routing protocol. If it is the R2RI's responsibility to
provide link metric hysteresis and dampening, a clear description
of the what metrics need what dampening factors are needed.
5.4 Radio and Router Bi-Determination of Link Availability
R2RI can potentially cause an inconsistent view on link state
between the router and radio. For example, if the R2RI reports a
link to be down due to high link loss, and the router, using
B. Cheng et al. Expires August 15, 2012 [Page 11]
INTERNET DRAFT R2RI Framework and Requirements January 2012
router-level hello packets manages to send data over the air
successfully, the router can potentially think the link is
available while the R2RI does not. This causes an inconsistent
view on link up/down state. It is important, therefore, for either
the radio or the router to determine link availability, but not
both. Additional work is needed to ensure consistent state or to
limit traffic to what the R2RI reports.
5.5 Link Load Affect on Link Metrics
If routing decisions are made in part due to report link metrics,
and some link metrics (such as latency) are potentially affected
by link traffic load, a potential issue could occur whereby load
is transferred from link to link causing route flapping. Ideally,
defined metrics should not be affected by traffic load, but
additional work is needed to understand traffic load affect on
link metrics.
5.6 Flow Control Issues
Previous work has focused on using either credit-based or rate-
based flow control to throttle traffic between the radio and
router. Rate-based flow control, while effective for fixed links,
result in difficulties in estimating accurate goodput across the
link in shared medium random access environments. In short, the
available data rate is time varying and affected heavily by
neighboring traffic loads. Credit-based flow control, on the other
hand, requires synchronization between the radio and router and
can potentially provide uneven data send due to credit grant
intervals. Additionally, multicast credit estimation is difficult.
5.7 Connection-Based vs. Connection-Less Radios
Radio systems are either connection-based or connection-less. In
connection-based systems, link discovery, neighbor establishment,
link metrics are exchanged by the radio irrespective of traffic
flow. When the radio senses the availability of a link, the R2RI
client can initiate an R2RI neighbor session with the router and
inform the router of the link status and metrics. In a
connectionless system such as 802.11 operating in adhoc mode,
however, no link layer exchanges occur until traffic is sent over
the link. As such, the radio does not know when a link is
available to initiate an R2RI neighbor session with the router. If
the router is relying on an initiated R2RI session to establish a
route with a neighbor and send data across, and the R2RI session
cannot be established without traffic flow, then a chicken and egg
problem occurs where no R2RI session will be established and no
data will be sent across. Additional work is needed to understand
B. Cheng et al. Expires August 15, 2012 [Page 12]
INTERNET DRAFT R2RI Framework and Requirements January 2012
how the R2RI paradigm can be fit into connectionless radio
systems.
5.8 Multi-Topology QoS Routing
While providing per link metrics from radio to router is helpful
in dynamic routing, when multiple radio systems and links are
used, routing protocols should take advantage of each
link/interface/system simultaneously and use QoS to map certain
traffic toward certain end-to-end routes. For example, if the R2RI
reports link latency and operating data rate, the router should
use the two metrics provided to generate multiple routes (one
based on highest data rate and one based on lowest latency) and
map select traffic to high data rate paths and select traffic to
low latency paths. This area needs to be explored in greater
detail.
6 Security Considerations
This document does not address security considerations.
7 IANA Considerations
This document does not address IANA considerations but assumes
that any standardized radio-to-router interface will obtain the
proper IANA numbering requests
8 References
8.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5578] Berry, B., Ed., Ratliff, S., Paradise, E., Kaiser, T., and
M. Adams, "PPP over Ethernet (PPPoE) Extensions for Credit
Flow and Link Metrics", RFC 5578, February 2010.
8.2 Informative References
Authors' Addresses
Bow-Nan Cheng
B. Cheng et al. Expires August 15, 2012 [Page 13]
INTERNET DRAFT R2RI Framework and Requirements January 2012
MIT Lincoln Laboratory
244 Wood Street
Lexington, MA 02420
USA
EMail: bcheng@ll.mit.edu
Leonid Veytser
MIT Lincoln Laboratory
244 Wood Street
Lexington, MA 02420
USA
EMail: veytser@ll.mit.edu
David Ward
MIT Lincoln Laboratory
244 Wood Street
Lexington, MA 02420
USA
EMail: david.ward@ll.mit.edu
B. Cheng et al. Expires August 15, 2012 [Page 14]
