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]