Subject: Re: [Roll] industrial requirements (was...)

From: Kris Pister <[email-masked]>
Date: Tue, 08 Apr 2008 22:01:23 -0700

Telemaco -
Multi-path routing: definitely needed for reliability in industrial
Multi-topology routing: definitely needed to handle different traffic 
classes.
Having different routes for different traffic classes with different 
metrics is important, as you point out.
Consider a case where I have many nodes sharing bandwidth allocated for 
alarms. The alarms happen infrequently, and are uncorrelated, but when 
they happen I need to know within some number of seconds. This is a case 
where a route with lots of multi-path redundancy on CSMA or aloha links 
makes a lot of sense, and I will allocate some of my precious microAmps 
to making available some low-latency bandwidth which may never be used. 
In this same network, I may need to do a daily upload of a 30kB log file 
from each node. I definitely do not want that traffic clogging up my 
low-latency bandwidth. The individual log file data can probably be sent 
over a direct route with little or no multi-path redundancy, since over 
the time of the upload the link reliabilities should be relatively static.
So I have different flows with different routing requirments, and 
different layer 2 provisioning to support them. I know that we're not 
supposed to talk about layer 2 here, but I think that it's a critical 
part (and a novel part?) of the challenge for RoLL to solve these 
different routing problems in the context of this very weird layer 2.
Another example: it's simple for a node to announce "I can only support 
X microAmps average current", or maybe report that in terms how how many 
packets per second it can forward, or how many times per second it can 
listen for a packet. Turning that into a optimal routes, for regular 
data or alarms, which respect the limits of all of the nodes in the 
network seems like it's probably a well-understood problem. But when I 
throw in a route request for a high-speed file transfer, which only 
happens once every 24 hours for just a handful of seconds, but burns way 
more than X microAmps during that time... Do I deny the routing request? 
Or provide routes and then delete them after a certain amount of packets 
have flowed over them?

ksjp

Telemaco Melia (tmelia) wrote:
> HI all,
> Sorry to jump in the middle of this discussion but I would like to 
> clarify the difference between multi path routing and multi topology 
> routing.
> The former is the ability to maintain, mainly for reliability 
> purposes, different routing paths between a source and destination.
> The latter, as stated by JP, refers to the ability to maintain 
> multiple topologies for different purposes.
> Correct?
> Would it also be correct to assume that between a source a destination 
> you might have several paths depending on the metric you are considering:
> - reliability
> - low latency
> - bandwidth
> - ...
> If yes then I guess the text of section 5.1 and 5.7 should be clarified.
> What do you think?
> Cheers
> Telemaco
>
> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Jean Philippe Vasseur (jvasseur)
> *Sent:* Tuesday, April 01, 2008 12:24 AM
> *To:* Kris Pister
> *Cc:* [email-masked]
> *Subject:* Re: [Roll] industrial requirements (was...)
>
> Hi Kris,
>
> See JP2>
>
>
> ------------------------------------------------------------------------
> *From: *Kris Pister <[email-masked]>
> *Date: *Mon, 31 Mar 2008 14:29:07 -0700
> *To: *JP Vasseur <[email-masked]>
> *Cc: *<[email-masked]>
> *Subject: *Re: [Roll] industrial requirements (was...)
>
> JP Vasseur wrote:
>
>     Re: [Roll] [manet] Discussion on draft [...]
>     The early deployments in industrial are all around getting data
>     back to one or more sinks. Increasingly over time, these sinks
>     will be a part of a backbone (today they're often
>     fragmented/isolated). This function is likely to always be an
>     important function of the network.
>
>     JP> Which means that you need both in the requirement document.
>
> They're both in there. e.g. " Most low power and lossy network systems 
> [in industrial] in the near future will be for low frequency data 
> collection."
> "The routing protocol MUST support multiple paths (a tree-based 
> solution is not sufficient)."
> "Thus, the routing protocol for L2Ns MUST support multi-topology 
> routing (e.g especially critical for critical control applications)."
>
>
>     JP2> Multi-topology routing is different though: it refers to the
>     ability to support multiple topologies (e.g., one for low latency,
>     one for high bandwidth): is this what you want ?
>
>     On-demand internal routes will become more prevalent over time.
>     Some of the on-demand routes will last for years/decades. Internal
>     routes will often be the most critical, optimized and
>     well-maintained (I think that this was where I lost sync: with
>     your statement that they might be less optimized and less well
>     maintained).
>
>     JP> Just make sure to stay solution-agnostic in the requirement
>     document.
>
> I think that we're largely solution-agnostic in -00, but a lot of 
> people of appropriately complained about the repeated references to 
> L2. I'm not trying to make this a HART-like document, or an 
> ISA100-like document, so I'll yank all of the slotted-link and 
> 15.4-specific stuff out of there. At the same time, I think that there 
> are important underlying issues here that require some clever thinking 
> at layer 3 to deal with what's going on in layer 2,
>
> JP2> The following WG item should help you there:
> Nov 2008 Submit Routing metrics for LLNs document to the IESG to be 
> considered as a Proposed Standard.
> Link routing metric could be derived from the layer-2 characteristics.
>
> and relate both to what layer 4 needs.
> Zach's email from 11/29 asked if routing metrics can serve as enough 
> of an L2 abstraction, or if we need some kind of interactive 
> relationship. I don't know the answer to that question, but I'd sure 
> like to hear some good ideas.
>
> JP2> For sure, we’ll need to have some discussions on this in the 
> document referenced above. I tend to suggest to first progress on the 
> requirements documents though.
>
> Thanks,
>
> Cheers.
>
> JP.
>
> ksjp
>
>
> ------------------------------------------------------------------------
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll