Subject: [manet] R2RI Framework and Requirements

From: "Darrel Beach (dbeach)" <[email-masked]>
Date: Sun, 12 Feb 2012 18:17:21 -0600

To add an additional thought......
I believe that the context of the Radio to Router information exchange
over an
Ethernet is actually applicable across another segment.  Traditionally
we've used 
routers with integrated interfaces for all the types underlying networks
such as
ISDN, Serial, Frame Relay, etc.   By using a R2R framework it looks
workable to have
such interfaces which could now be separate from a router and have the
interface to the
router abstracted to occur over Ethernet.  From a flexibility
standpoint, and as an example, 
I see no reason why an ISDN interface card from vendor A couldn't use
the R2R framework
where it could establish a connection over ISDN and signal the
connection information
over the Ethernet using R2R protocols.   This could be extended across
virtually any 
connection type, including media or methods not normally seen.   The
Neighbor TLVs
under discussion also provide an interesting mechanism for nonstandard
connections 
to easily advertise connected devices.   One prime example is the bus
technology such as 1553.
It's unlikely to see 1553 interfaces integrated into routers, but it
looks quite feasible to
abstract such an interface to the R2R framework for the transmission of
IP packets.

/d

---

From: "Cheng, Bow-Nan - 0665 - MITLL" <[email-masked]>
Date: Mon, 13 Feb 2012 10:57:05 -0500

Thanks Darrel and Lloyd for your helpful comments.

Indeed the concept of R2RI/R2M can be applied in many contexts to help
throttle networks (and as you guys mentioned, have already been done to
some extent).

I'm wondering if its possible to de-scope the work for various
applications. For example, in the MANET context, perhaps the role of the
R2RI protocol is to simply 1) define the link layer (1 RF hop) information
(a small subset) the radio/modem should provide to the multi-hop routing
layer (MANET Routing), and 2) define the transport mechanism to get this
to the router.

How the router utilizes the link layer information (to make better
multi-hop routing decisions, reduce link flapping, etc.) is probably a
different problem and beyond the scope of R2RI.

I guess what I'm wondering is if its possible to scope out R2RI in the
MANET context as providing information about 1-hop neighbors to a
multi-hop routing scheme.. Understanding that R2RI/R2M can be applied to
throttling entire networks and also be used a virtual interface over
Ethernet (which would be scoped as a different piece of work)

--
Bow-Nan Cheng, Ph.D.
MIT Lincoln Laboratory
Airborne Networks Group
244 Wood St Lexington MA 02420
781-981-4997

On 2/12/12 7:17 PM, "Darrel Beach (dbeach)" <[email-masked]> wrote:

>_______________________________________________
>manet mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/manet

---

From: Rex Buddenberg <[email-masked]>
Date: Mon, 13 Feb 2012 09:48:54 -0800

Bow-Nan,

what you're calling 'descoping' is a good idea, IMHO.  

Getting the right data available and 2) figuring out how to use it are
indeed two different problems.  And they've been around the internet,
manet and otherwise, for years, so I vote for the generalization idea
too.  

more...

> layer (MANET Routing), and 2) define the transport mechanism to get this
A couple 'how' thoughts.  Does not #1 here describe a bunch of MIB
variables?  And does not SNMP already provide for #2?  

> different problem and beyond the scope of R2RI.
Agreed.  We need one mechanism to make the data visible; there may be
more than one right answer regarding how the data is used.

---

From: "Cheng, Bow-Nan - 0665 - MITLL" <[email-masked]>
Date: Tue, 14 Feb 2012 10:42:08 -0500

Hi Rex,

Thanks for your helpful comments. With regards to the thought on
potentially using SNMP, not being as familiar with the protocol as perhaps
I should (though others can chime in), here're a few reasons that
potentially precludes us from using it:

1. Time scale  radio link metrics change in sub-second timescales. SNMP
typically operates in multiple-second timescales. Polling multiple radio
systems in small timescales can impact performance on the radio systems

2. Flow control  SNMP doesn't have any provisions for flow control (such
as the credit-based or pause-frame based concepts we're looking at) on a
link

3. Bi-directionality - Not sure if SNMP supports bi-directional
query/response. Ie. The Router requesting more bandwidth, the radio
responding with more timeslots. My impression is that SNMP doesn't have
built-in "ACK" functionality. In SNMP, to request more bandwidth from the
radio, you would probably need to "SET" the bandwidth and then "GET" the
operating data rate to see if the changes took.

These are just some of my initial thoughts.. Though the authors of

http://tools.ietf.org/html/draft-sratliff-dlep-02

http://tools.ietf.org/html/rfc5578

http://tools.ietf.org/html/draft-dubois-r2cp-00

http://tools.ietf.org/html/draft-ivancic-mobopts-modemlpa-00

Could probably give more justifications.

Perhaps a section comparing SNMP and R2RI in the Framework and
Requirements document is needed.

-Bow-Nan