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]