Subject: Re: [RSN] industrial requirements

From: Zach Shelby <[email-masked]>
Date: Sat, 17 Nov 2007 13:07:31 +0200

Hi Kris,

Very complete req draft. Here are my comments:

draft-pister-rl2n-industrial-routing-reqs-05

Overall comments

Very well written. The requirements are however encompassing some issues 
far beyond the scope of IP routing and rl2n, e.g. MAC-layer slotting, 
QoS priority mechanisms etc. which yes are encompassed by ISA100 as a 
whole. But should the requirements for an r2ln draft be so broad? I'd 
like to hear justification on this, although I see reason for some of 
it. Others may have the same feeling?

How do these requirements relate to ISA100, are they taken directly or 
do we have something special for rl2n here?

Section 2.1

In addition to mentioning equipment monitoring, the general class of 
asset monitoring and tracking can be mentioned as belonging to classes 
4-5. Also access control could be mentioned as an application, although 
it has overlap of course with commercial building automation.

Section 3

Can we demand 10ms timeslots from the r2ln point of view? What if the L2 
protocol is not able to provide that? Do 10ms time-slots make sense for 
classes 3-5 at all? They at least don't make sense for sparse events and 
bulk non-critical transfers.

Section 8

We have also seen lots of applications for field device mobile 
monitoring and for mounting on mobile equipment. Very happy to see both 
here as requirements.

Looking forward to the expansion of Section 9.

- Zach

Kris Pister wrote:
 > Version 0 of the routing requirements for industrial automation is 
now available.
 > Comments and questions are eagerly awaited.
 >
 > 
http://www.ietf.org/internet-drafts/draft-pister-rl2n-indus-routing-reqs-00.txt
 >
 > ksjp
 >
 >
 > _______________________________________________
 > RSN mailing list
 > [email-masked]
 > https://www1.ietf.org/mailman/listinfo/rsn

-- 
Zach Shelby | CTO | +358 40 7796297
Sensinode Ltd.   www.sensinode.com

_______________________________________________
RSN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rsn

---

From: Kris Pister <[email-masked]>
Date: Wed, 28 Nov 2007 15:42:11 -0800

Zach - thanks for the positive feedback.  Your questions about MAC-layer 
slotting and QoS are a great starting point for discussion.  I 
understand that traditionally these issues do not belong in a routing 
discussion, but at the same time I feel that provisioning of layer 2 
must both inform and be directed by routing decisions at layer 3, and 
transport requirements at layer 4. 
Just to be clear, this is what I'm calling L2 provisioning: Most/all of 
the low power MAC protocols have a way to trade off power consumption 
against performance.  Provisioning is setting the parameter(s) that 
govern that tradeoff on a mote-by-mote basis.
Provisioning could in principle happen automatically at each node or 
pair of nodes based on traffic level and queue length.  But what if what 
Holger&Karl have called Topology Management has segregated the network 
so that my discovery protocols can't discover the path that I'm looking 
for without reprovisioning the network?  I'm not saying that we'll be 
that stupid, rather that we need to consider provisioning early on to 
avoid traps like that.

As for ~10ms time slots, clearly they are not a requirement for L2Ns, 
but they are what industrial automation has adopted in the existing 
standard (HART) and the in-development standard (sp100).  If 15.4E goes 
according to the PAR (not at all a sure bet), then they'll be a part of 
the IEEE standard that underlies much of what we're trying to achieve.

I'm happy to take the specifics of TSMP out of the draft, but I think 
that it's very important that they be replaced with some L2 abstractions 
that we can work with.  I think that Phil was interested in talking 
about this in 6LoWPAN.  Maybe a group of us can get together thursday 
morning in Vancouver?

ksjp

Zach Shelby wrote:
> Very well written. The requirements are however encompassing some 
> issues far beyond the scope of IP routing and rl2n, e.g. MAC-layer 
> slotting, QoS priority mechanisms etc. which yes are encompassed by 
> ISA100 as a whole. But should the requirements for an r2ln draft be so 
> broad? I'd like to hear justification on this, although I see reason 
> for some of it. Others may have the same feeling?
>
> 4-5. Also access control could be mentioned as an application, 
> although it has overlap of course with commercial building automation.
>
> Section 3
>
> Can we demand 10ms timeslots from the r2ln point of view? What if the 
> L2 protocol is not able to provide that? Do 10ms time-slots make sense 
> for classes 3-5 at all? They at least don't make sense for sparse 
> events and bulk non-critical transfers.
>
> Section 8
>
> monitoring and for mounting on mobile equipment. Very happy to see 
> both here as requirements.
>

---

From: Zach Shelby <[email-masked]>
Date: Fri, 30 Nov 2007 00:01:40 +0200

Kris,

No we're talking, no arguments on a theoretical basis, cross-layer is 
the way to go here. But I am definitely for using a reasonable L2 
abstraction rather than such specific coupling as the text has now. 
Would also rather see the TSMP specifics behind that abstraction.

I think the L2 abstraction is out of scope from 6lowpan these days, so 
it lies on rl2n's shoulders. JP: Should the L2 abstraction actually be a 
separate draft shared between req drafts?

- Zach

Kris Pister wrote:
> transport requirements at layer 4. Just to be clear, this is what I'm 
> calling L2 provisioning: Most/all of the low power MAC protocols have a 
> way to trade off power consumption against performance.  Provisioning is 
> setting the parameter(s) that govern that tradeoff on a mote-by-mote basis.

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 29 Nov 2007 21:07:13 -0700

Actually L2 is out of the scope of the IETF.  I do not think that L2
lies in ROLL.

	geoff