Subject: [Roll] Need quantitative requirements in draft-ietf-roll-applicability-ami-01

From: "Wei-Peng Chen" <[email-masked]>
Date: Thu, 28 Jul 2011 18:23:23 -0700

Hi Daniel,

To judge the applicability of RPL in AMI networks, in my opinion, we need to specify a few key quantitative requirements of AMI networks. But I cannot find quantitative requirements in neither your ID and RFC5548. Do you think whether we should specify some key requirements such as: 

- What is the interval each meter reports its reading?

- The quantitative requirements for the latency, reliability, packet payload, etc. of UL/DL connections, in particular DL connections such as demand response, distribution automation. (You can find those numbers specified in UCAIAG’s  <http://www.google.com/url?sa=t&source=web&cd=2&ved=0CBsQFjAB&url=http%3A%2F%2Fosgug.ucaiug.org%2FUtiliComm%2FShared%2520Documents%2FLatest_Release_Deliverables%2FSG%2520Network%2520System%2520Requirements%2520Specification%2520v4.0.xls&rct=j&q=SG%20network%20system%20requirement%20filetype%3Axls&ei=DAgyTtjVJZPKiALrwvTDCA&usg=AFQjCNH8obIMMJGEoOD-PzW3YLhil8Fexw> SG Network System Requirements Specification and IEEE P2030 specification.)

If I miss any previous draft which has already covered these quantitative requirements, please let me know. 

Regards,

Wei-Peng

---

From: JP Vasseur <[email-masked]>
Date: Thu, 28 Jul 2011 22:36:05 -0400

Dear Wei-Peng,

On Jul 28, 2011, at 9:23 PM, Wei-Peng Chen wrote:

> - The quantitative requirements for the latency, reliability, packet payload, etc. of UL/DL connections, in particular DL connections such as demand response, distribution automation. (You can find those numbers specified in UCAIAG’s SG Network System Requirements Specification and IEEE P2030 specification.)

Just an important clarification: this is an RPL applicability statement, thus many of the items list above
are out of the scope of such a document.

Thanks.

JP.

>  
> Regards,
> Wei-Peng
>  
>  
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: C Chauvenet <[email-masked]>
Date: Thu, 28 Jul 2011 19:42:15 -0700

Hi Wei-Peng

This would be indeed usefull informations.

The document you pointed out gives usefull and very precise requirements.

But, I'm wondering if this specification could be taken as a global rule for most of AMI applications.

As I'm not a SmartGrid expert, is this specification approved by most of the AMI actors ?

Cédric.

Le 28 juil. 2011 à 21:23, Wei-Peng Chen a écrit :

Hi Daniel,

To judge the applicability of RPL in AMI networks, in my opinion, we need to specify a few key quantitative requirements of AMI networks. But I cannot find quantitative requirements in neither your ID and RFC5548. Do you think whether we should specify some key requirements such as:
- What is the interval each meter reports its reading?
- The quantitative requirements for the latency, reliability, packet payload, etc. of UL/DL connections, in particular DL connections such as demand response, distribution automation. (You can find those numbers specified in UCAIAG’sSG Network System Requirements Specification<http://www.google.com/url?sa=t&source=web&cd=2&ved=0CBsQFjAB&url=http%3A%2F%2Fosgug.ucaiug.org%2FUtiliComm%2FShared%2520Documents%2FLatest_Release_Deliverables%2FSG%2520Network%2520System%2520Requirements%2520Specification%2520v4.0.xls&rct=j&q=SG%20network%20system%20requirement%20filetype%3Axls&ei=DAgyTtjVJZPKiALrwvTDCA&usg=AFQjCNH8obIMMJGEoOD-PzW3YLhil8Fexw> and IEEE P2030 specification.)
If I miss any previous draft which has already covered these quantitative requirements, please let me know.

Regards,
Wei-Peng

<ATT00001..txt>

---

From: Don Sturek <[email-masked]>
Date: Thu, 28 Jul 2011 20:28:32 -0700

Hi JP,

The OpenSG SG-NET, and additional NIST PAP 2 work, are important contributions to the requirements for AMI routing.  I think both are applicable to the use of ROLL RPL for AMI applications.

Don

Sent from my iPad

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 28 Jul 2011 23:22:10 -0400

> are out of the scope of such a document.

Just to clarify, you are saying that RPL is not applicable for AMI, and therefore these considerations are out of scope. I agree with that,.

I, then, wonder why draft-ietf-roll-applicability-ami exists as WG document - as you say that AMI is out of scope for RPL.

Thomas

---

From: Ietf Roll <[email-masked]>
Date: Thu, 28 Jul 2011 20:22:20 -0700 (PDT)

JP,
This is completely illogical. This is an Applicability Statement 
\about AMI/ so specifying some quantitative requirements of the AMI netork is completely within scope.How can you judge any applicability without specifying what you are saying it is applicable to.

Without some concrete requirements all you have is a marketing / sales document.

Rav

--- On Fri, 7/29/11, JP Vasseur <[email-masked]> wrote:

> From: JP Vasseur <[email-masked]>
> Subject: Re: [Roll] Need quantitative requirements in draft-ietf-roll-applicability-ami-01
> To: "Wei-Peng Chen" <[email-masked]>
> Cc: [email-masked]
> Date: Friday, July 29, 2011, 2:36 AM
> Dear
> Wei-Peng,
> Hi Daniel,  To judge the applicability of RPL in AMI networks, in
> my opinion, we need to specify a few key quantitative
> requirements of AMI networks. But I cannot find quantitative
> requirements in neither your ID and RFC5548. Do you think
> whether we should specify some key requirements such
> as:- What is the interval each meter reports its
> reading?- The quantitative requirements for the latency,
> reliability, packet payload, etc. of UL/DL connections, in
> particular DL connections such as demand response,
> distribution automation. (You can find those numbers
> specified in UCAIAG’s SG
> Network System Requirements Specification and
> IEEE P2030 specification.)If I miss any previous draft which has already
> covered these quantitative requirements, please let me
> know.
> Just an important clarification: this is an RPL
> applicability statement, thus many of the items list
> aboveare out of the scope of such a
> document.
> Thanks.
> JP.
>   Regards,Wei-Peng  
>  
> -----Inline Attachment Follows-----
>

---

From: JP Vasseur <[email-masked]>
Date: Fri, 29 Jul 2011 00:03:13 -0400

> Just to clarify, you are saying that RPL is not applicable for AMI, and therefore these considerations are out of scope. I agree with that,.

Thomas, where do you see that I said this ?
I said that "interval each meter reports its reading", "packet payload", … are not routing parameters, thus there are of the scope of this document, which is a RPL AMI applicability statement. In other words, the objective is to explain how RPL can be used for AMI purposes. Non routing related issues are thus out of the scope. I am just stating the obvious here.

Thanks.

JP.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 29 Jul 2011 00:27:53 -0400

> I said that "interval each meter reports its reading", "packet payload", … are not routing parameters, thus there are of the scope of this document, which is a RPL AMI applicability statement. In o…

Traffic patterns are important to understand the applicability (if any) of a given routing protocol. I am also just stating the obvious here.

Thomas

---

From: Ietf Roll <[email-masked]>
Date: Thu, 28 Jul 2011 21:37:23 -0700 (PDT)

This is what you are saying now in your revisionist history, but certainly not what you said.

It is important to understand the total communications environment that the routing protocol must work in or do you forget the now abandoned draft on protocol survey made a big deal about the routing maintenance overhead (as computed by comparing data vs maintenance packets.)

If I'm only sending a packet once in a long while and latency isn't an issue I could search for path on each packet, could I not.

In a "good" applicability statement it would seem beneficial to well specify the network you are claiming applicability to.

--- On Fri, 7/29/11, JP Vasseur <[email-masked]> wrote:

> To: "Thomas Heide Clausen" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "Wei-Peng Chen" <[email-masked]>
> Date: Friday, July 29, 2011, 4:03 AM
> 
> Just to clarify, you are saying that RPL is not
> applicable for AMI, and therefore these considerations are
> out of scope. I agree with that,.
> 
> Thomas, where do you see that I said this
> ?I said that "interval each meter reports
> its reading", "packet payload", … are not
> routing parameters, thus there are of the scope of
> this document, which is a RPL AMI applicability statement.
> In other words, the objective is to explain how RPL can be
> used for AMI purposes. Non routing related issues are thus
> out of the scope. I am just stating the obvious
> here.
> Thanks.
> JP.
> 
> I, then, wonder
> why draft-ietf-roll-applicability-ami exists as WG
> document - as you say that AMI is out of scope for
> RPL.
> Thomas
> 
> Thanks.
> JP.
>   Regards,Wei-Peng  
>

---

From: "Wei-Peng Chen" <[email-masked]>
Date: Thu, 28 Jul 2011 22:09:03 -0700

Hi Cédric,

I never attended OpenSG before. But according to my colleague who attended
OpenSG before, there are many representatives from major utilities in the
states. 

I participated in IEEE P2030 briefly and part of the requirements are
contributed by utility experts.

BTW, I also agree with Don’s comment.

Regards,

Wei-Peng

From: C Chauvenet [mailto:[email-masked]] 
Sent: Thursday, July 28, 2011 7:42 PM
To: Wei-Peng Chen
Cc: [email-masked]; [email-masked]
Subject: Re: [Roll] Need quantitative requirements in
draft-ietf-roll-applicability-ami-01

Hi Wei-Peng

But, I'm wondering if this specification could be taken as a global rule for
most of AMI applications.

As I'm not a SmartGrid expert, is this specification approved by most of the
AMI actors ?

Cédric.

Hi Daniel,

To judge the applicability of RPL in AMI networks, in my opinion, we need to
specify a few key quantitative requirements of AMI networks. But I cannot
find quantitative requirements in neither your ID and RFC5548. Do you think
whether we should specify some key requirements such as:

- The quantitative requirements for the latency, reliability, packet
payload, etc. of UL/DL connections, in particular DL connections such as
demand response, distribution automation. (You can find those numbers
specified in UCAIAG’s
<http://www.google.com/url?sa=t&source=web&cd=2&ved=0CBsQFjAB&url=http%3A%2F
%2Fosgug.ucaiug.org%2FUtiliComm%2FShared%2520Documents%2FLatest_Release_Deli
verables%2FSG%2520Network%2520System%2520Requirements%2520Specification%2520
v4.0.xls&rct=j&q=SG%20network%20system%20requirement%20filetype%3Axls&ei=DAg
yTtjVJZPKiALrwvTDCA&usg=AFQjCNH8obIMMJGEoOD-PzW3YLhil8Fexw> SG Network
System Requirements Specification and IEEE P2030 specification.)

If I miss any previous draft which has already covered these quantitative
requirements, please let me know.

Regards,

Wei-Peng

<ATT00001..txt>

---

From: "Wei-Peng Chen" <[email-masked]>
Date: Thu, 28 Jul 2011 22:09:14 -0700

Hi JP,

As I am a newbie to IETF, what I said may not make sense to the community. And I appreciate your comment.  
However, I agree with Thomas and Ietf that traffic patterns of the targeted applications and communication environments are important to understand the applicability of a given routing protocol. We need to consider any quantitative requirements specified by utilities. In particular, meters, once installed, would last for 20+ years. It is important to consider the requirements of the potential applications in the near future. 

Regards,
Wei-Peng

---

From: JP Vasseur <[email-masked]>
Date: Fri, 29 Jul 2011 07:45:32 -0400

Hi,

> As I am a newbie to IETF, what I said may not make sense to the community. And I appreciate your comment. 
Thanks for understanding, and your comments are very much welcome and appreciated.
> However, I agree with Thomas and Ietf that traffic patterns of the targeted applications and communication environments are important to understand the applicability of a given routing protocol. We…
You see what I meant, the objective here is to make sure that we limit the scope to the routing aspects,
that's all, this is why I took the example of "packet load", please continue to comment, this does help.

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 29 Jul 2011 07:46:38 -0400

On Jul 29, 2011, at 12:27 AM, Thomas Heide Clausen wrote:

> Traffic patterns are important to understand the applicability (if any) of a given routing protocol.

The "interval" is not a traffic pattern.

JP.

> I am also just stating the obvious here.
> 
> Thomas
> 
>> Thanks.
>> 
>> JP.
>> 
>>

---

From: JP Vasseur <[email-masked]>
Date: Fri, 29 Jul 2011 07:56:51 -0400

JP.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 29 Jul 2011 07:46:38 -0400

JP.

---

From: Martin Heusse <[email-masked]>
Date: Fri, 29 Jul 2011 14:21:53 +0200

For really long intervals between reports, reactive routing would be better. So the traffic pattern/frequency/structure/incidence/regularity is somewhat relevant I think. 

As a side note, i'd think that being able to establish downward routes to a subset of nodes could be useful (especially for a metering application), but it seems (...my understanding is that...) RPL precludes this (unless P2P is used). 

> The "interval" is not a traffic pattern.

Martin Heusse

---

From: Jiazi Yi <[email-masked]>
Date: Fri, 29 Jul 2011 09:19:51 -0400

Agree with Martin. From the "traffic pattern" point of view, the interval of the traffic should be considered. Generating 1 packet per month (with is possible in ami), is certainly different from 1 packet in 10 seconds (which is also possible). 

Even regarding the p2mp, p2p patterns, I can see that it is "proposed" in section 2.2, traffic characteristic, with possibly latency requirements, but I can't tell how those can be properly addressed By reading this document, which is surely interesting for some of us.

Regards

Jiazi YI

Sent from my iPad

---

From: Don Sturek <[email-masked]>
Date: Fri, 29 Jul 2011 06:17:47 -0700

Hi Wei-Peng (and Cedric),

I actually chair the OpenSG SG-Communications group on behalf of Pacific Gas
and Electric.  In addition, Matt Gillmore (Consumers Energy, a Michigan
based electric and gas utility) chairs the SG-NET task group in
SG-Communications that produced the requirements.

Participation in the OpenSG SG-NET group is mainly from 15 large US electric
and gas utilities with many vendor companies.  I would not say these
requirements capture international requirements but are pretty
representative of requirements in US smart grid deployments.  Please note
that the SG-NET requirements capture all smart grid requirements, not just
AMI.

I think the details of the data payloads in the SG-NET requirements are not
really important.  I think the throughput and latency requirements should be
relevant information to applicability for any candidate routing protocol.  I
think the ongoing work to define densities of devices to support should also
be of interest (NIST SGIP PAP 2) to any candidate routing protocol.

Don Sturek

From:  Wei-Peng Chen <[email-masked]>
Date:  Thu, 28 Jul 2011 22:09:03 -0700
To:  'C Chauvenet' <[email-masked]>
Cc:  <[email-masked]>
Subject:  Re: [Roll] Need quantitative requirements in
draft-ietf-roll-applicability-ami-01

Hi Cédric,
 
BTW, I also agree with Don¹s comment.
 
Regards,
Wei-Peng

Hi Wei-Peng

Cédric.

Hi Daniel,
 
specified in UCAIAG¹sSG Network System Requirements Specification
yTtjVJZPKiALrwvTDCA&usg=AFQjCNH8obIMMJGEoOD-PzW3YLhil8Fexw>  and IEEE P2030
specification.)
 
Regards,
Wei-Peng

<ATT00001..txt>
 
_______________________________________________ Roll mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 29 Jul 2011 15:54:26 +0200

Hi Martin:

It is very sad you believe so. Let's see
 
> As a side note, i'd think that being able to establish downward routes
to a
> subset of nodes could be useful (especially for a metering
application), but it
> seems (...my understanding is that...) RPL precludes this (unless P2P
is used).

[Pascal] Richard made it clear to us long ago that in some case, nodes
need only be reachable for small periods of time and thus we designed
RPL so that DAO routes can be short lived, thus reducing the memory
requirements on nodes in storing mode. So the question becomes, when and
upon which events are those routes populated?

Basically, that's the traditional push and pull story, where the push is
the application up there or some controller in the network trying to
reach to the device, and the pull is the device timely advertising its
existence probably because it has a schedule to do so. The push being
the case where you indicate that reactive is an interesting model.

The RPL spec does NOT PRECLUDE any of those. It does NOT provide all the
means to do everything either; the discussion on the ML indicated that
we had to limit the number of methods in the main spec in order to
contain its apparent complexity. So we defined the pull in the initial
core spec and the push in the P2P spec. Both methods are still RPL,
based on the same tool set.

 It is a bit late to change what the main spec defines but there's
probably a way to change the packaging of the work in progress to make
it more clear that the push can apply to RPL as a whole, not just
specific to use cases for which P2P is explicitly more suited. The push
is basically composed of a DIO that indicates a (list of) targets and
optionally a range for the lookup. P2P adds specific information for
source routing and DAG information persistence, which are not needed
when the lookup happens on a preexisting DODAG.

I'm really open to the packaging discussion but please do not convey the
wrong impression that RPL would preclude push.

Cheers,

Pascal

---

From: "Popa, Daniel" <[email-masked]>
Date: Fri, 29 Jul 2011 07:13:02 -0700

Hi Wei-Peng,

Thanks for good questions.

Please remind that a routing protocol will not be a standalone mechanism for AMI solution, and so it will not be THE MECHANISM that shall meet the requirements you are referring to.

Let me take an example: latency. I challenge you to explain how someone can design a system where the routing protocol in the access segment – alone - is required to achieve the desired latency, without taking into account the PHY Layer characteristics (i.e., link capacity, error rate, and error correction capabilities), the MAC protocol characteristics (i.e., throughput), channel characteristics (interferences), interferences mitigation mechanisms, coexistence with other systems when operating in unlicensed bands, regulation, and so on.

IMHO, the routing protocol is the mechanism that tries to pick the right path – as a function of metrics, link characteristics, routing objectives - and – in latency example – will try to minimize the latency.

Let me take a further example: reliability. I challenge again to explain how someone will design a system where the routing protocol alone has to provide the required reliability. IMHO, the reliability of a system is a sum of several mechanisms deployed at different OSI layers (MAC, Transport and Application most of the time, eventually Net layer) that - integrated into a solution – will eventually provide the desired reliability.

Remember that in this document we only focus on routing for the access segment of an AMI system. I think you expect this Applicability document to describe a whole system design and how different network components & functionalities are integrated into AMI systems. Am I right?

Daniel

From: Wei-Peng Chen [mailto:[email-masked]]
Sent: Thursday, July 28, 2011 9:23 PM
To: Popa, Daniel
Cc: [email-masked]
Subject: Need quantitative requirements in draft-ietf-roll-applicability-ami-01

Hi Daniel,

To judge the applicability of RPL in AMI networks, in my opinion, we need to specify a few key quantitative requirements of AMI networks. But I cannot find quantitative requirements in neither your ID and RFC5548. Do you think whether we should specify some key requirements such as:
- What is the interval each meter reports its reading?
- The quantitative requirements for the latency, reliability, packet payload, etc. of UL/DL connections, in particular DL connections such as demand response, distribution automation. (You can find those numbers specified in UCAIAG’s SG Network System Requirements Specification<http://www.google.com/url?sa=t&source=web&cd=2&ved=0CBsQFjAB&url=http%3A%2F%2Fosgug.ucaiug.org%2FUtiliComm%2FShared%2520Documents%2FLatest_Release_Deliverables%2FSG%2520Network%2520System%2520Requirements%2520Specification%2520v4.0.xls&rct=j&q=SG%20network%20system%20requirement%20filetype%3Axls&ei=DAgyTtjVJZPKiALrwvTDCA&usg=AFQjCNH8obIMMJGEoOD-PzW3YLhil8Fexw> and IEEE P2030 specification.)
If I miss any previous draft which has already covered these quantitative requirements, please let me know.

Regards,
Wei-Peng

---

From: "Popa, Daniel" <[email-masked]>
Date: Fri, 29 Jul 2011 07:20:32 -0700

Hi Wei-Peng, 

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Wei-Peng Chen
> Sent: Friday, July 29, 2011 1:09 AM
> To: 'Ietf Roll'; 'Thomas Heide Clausen'; 'JP Vasseur'
> Cc: [email-masked]
> As I am a newbie to IETF, what I said may not make sense to the
> community. And I appreciate your comment.
> However, I agree with Thomas and Ietf that traffic patterns of the
> targeted applications and communication environments are important to
> understand the applicability of a given routing protocol. We need to
> consider any quantitative requirements specified by utilities. In
> particular, meters, once installed, would last for 20+ years. 

DP> The hardware yes, it would last for 20 years. But not the software (in particular the embedded networking software), because an AMI system has the capability of doing firmware upgrade and so upgrade/install new features. What you mention is a trade-off between cost and flexibility.   

It is
> important to consider the requirements of the potential applications in
> the near future.
> 
> Regards,
> Wei-Peng
> 
> It is important to understand the total communications environment that
> the routing protocol must work in or do you forget the now abandoned
> draft on protocol survey made a big deal about the routing maintenance
> overhead (as computed by comparing data vs maintenance packets.)
> 
> If I'm only sending a packet once in a long while and latency isn't an
> issue I could search for path on each packet, could I not.
> 
> In a "good" applicability statement it would seem beneficial to well
> specify the network you are claiming applicability to.
> 
>

---

From: "Wei-Peng Chen" <[email-masked]>
Date: Fri, 29 Jul 2011 07:58:03 -0700

Hi Daniel,

From: Popa, Daniel [mailto:[email-masked]] 
Sent: Friday, July 29, 2011 7:13 AM
To: Wei-Peng Chen
Cc: [email-masked]
Subject: RE: Need quantitative requirements in draft-ietf-roll-applicability-ami-01

Hi Wei-Peng, 

WC> I fully agree with you that routing is NOT the only mechanism to be considered to meet the application requirements. All layers and communication environments are also important factors. But do you agree that routing will be the key component to decide whether the whole solution can meet the requirements? (We could lose job if you say no J) In analogy to solving an optimization problem, the design of a given routing protocol could be considered as one of the constraints to maximize users’ satisfaction. IMHO, the purpose of AMI applicability document should consider whether the constraint of a given routing protocol is too tight, in particular, from the aspects of latency and overheads. In other word, given these constraints of quantitative requirements, our job is to evaluate whether the constraint of the given routing is active or inactive constraint function. 

I know it is challenging to evaluate the applicability with consideration of all network components. But still these quantitative requirements are important to consider. I am happy to work with you or other colleagues to make contribution. 

Wei-Peng

Daniel

Hi Daniel,

Regards,

Wei-Peng

---

From: "Wei-Peng Chen" <[email-masked]>
Date: Fri, 29 Jul 2011 08:01:56 -0700

Hi Daniel,

-----Original Message-----
From: Popa, Daniel [mailto:[email-masked]] 
Sent: Friday, July 29, 2011 7:21 AM
To: Wei-Peng Chen; 'Ietf Roll'; 'Thomas Heide Clausen'; 'JP Vasseur'
Cc: [email-masked]
Subject: RE: [Roll] Need quantitative requirements in draft-ietf-roll-applicability-ami-01

Hi Wei-Peng, 

WC> Thanks. I fully agree with you. Therefore the hardware requirement of a routing protocol is very important to consider. My main point is: the design of AMI routing should meet the requirements of the future applications (of course with consideration of reasonable cost) and then prepare the hardware platform for 20+ years.

Wei-Peng 

It is