Subject: [Roll] I-D Action:draft-ietf-roll-building-routing-reqs-02.txt

From: [email-masked]
Date: Wed, 14 Jan 2009 15:00:02 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF.

	Title           : Building Automation Routing Requirements in Low Power and Lossy Networks
	Author(s)       : J. Martocci, et al.
	Filename        : draft-ietf-roll-building-routing-reqs-02.txt
	Pages           : 27
	Date            : 2009-01-14

The Routing Over Low power and Lossy network (ROLL) Working Group has 
been chartered to work on routing solutions for Low Power and Lossy 
networks (LLN) in various markets: Industrial, Commercial (Building), 
Home and Urban. Pursuant to this effort, this document defines the 
routing requirements for building automation. 

Requirements Language 

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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-building-routing-reqs-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: JP Vasseur <[email-masked]>
Date: Thu, 15 Jan 2009 06:56:49 +0100

Dear WG,

WG Last Call for this I-D ended on Dec 5, and we received several  
comments that have been addressed in this revision on the document (to  
be confirmed by the authors of these comments of course). We had in- 
depth discussion on this document (good !) and now need to move on.  
The objective is to send the document to the IESG for publication  
(informational track) at the latest by end of next week. Thanks for  
the authors of the comments to provide some feed-back by June 22,  
preferably earlier.

Thanks.

JP.

Begin forwarded message:

> From: [email-masked]
> Date: January 15, 2009 12:00:02 AM CEST
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Roll] I-D Action:draft-ietf-roll-building-routing- 
> reqs-02.txt
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 15 Jan 2009 14:54:47 -0000

> WG Last Call for this I-D ended on Dec 5, and we received several
comments
> that have been addressed in this revision on the document (to be
confirmed
> by the authors of these comments of course). We had in-depth
discussion on
> this document (good !) and now need to move on. The objective is to
send
> the document to the IESG for publication (informational track) at the
latest
> by end of next week. Thanks for the authors of the comments to provide
some
> feed-back by June 22, preferably earlier.

January 22 I assume ;)

I have read through it and, subject to all the comments previously
made about interpretation, future plans etc., I didn't find anything
that I felt required an -04. I did find a couple of things that I was
going to say "if doing an -04 for some other reason, you might consider
this". As the DTN comments made elsewhere may suggest an -04, I'll
note them here.

Abstract. Personally I would delete "novel". The remaining text still
makes it clear that things are different, but it's not really that
the requirements are novel, it's the combination and the importance
that are different.

Section 1 third paragraph. When I see "Furthermore" I assume that the
second point builds on the first, but here it is quite independent.
But I wouldn't like to try to defend that assumption as being definitely
correct.

Section 1 fifth paragraph, "extenuating" is I think the wrong word.
It suggests that using a new protocol is a guilty action, but you
may get let off. Maybe some see it that way!

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: JP Vasseur <[email-masked]>
Date: Fri, 16 Jan 2009 10:33:50 +0100

Hi Christopher,

>> feed-back by June 22, preferably earlier.

yes indeed, thanks.

> this". As the DTN comments made elsewhere may suggest an -04, I'll

Let me make sure I understand. You mean a version -03 ? Yes, within  
the next few days
to address potential last comments.

> may get let off. Maybe some see it that way!

That should be easy to address by the authors.

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 16 Jan 2009 16:05:03 +0100

Sorry ... the comment was right but for the wrong I-D. Of course this  
email was for the protocol survey, not draft-ietf-roll-building- 
routing-reqs-02.txt that was just last called.

Thanks.

JP.

On Jan 15, 2009, at 6:56 AM, JP Vasseur wrote:

> comments that have been addressed in this revision on the document  
> (to be confirmed by the authors of these comments of course). We had  
> in-depth discussion on this document (good !) and now need to move  
> on. The objective is to send the document to the IESG for  
> publication (informational track) at the latest by end of next week.  
> Thanks for the authors of the comments to provide some feed-back by  
> June 22, preferably earlier.
>
> Thanks.
>
> JP.
>
> Begin forwarded message:
>
> Content-Type: text/plain<BR>Content-ID: &lt;[email-masked] 
> &gt;<BR><BR>
>

---

From: JP Vasseur <[email-masked]>
Date: Tue, 20 Jan 2009 11:22:04 +0100

Hi,

First of all thanks for the hard work and several revisions addressing  
many comments. There are still several comments to address.

Please find below my WG LC comments:

1) Section 1

"For description of the terminology used in this specification, please
    see the Terminology ID referenced in Section 10.1. "
Please add the reference instead of mentioning Section 10.1.
s/"see the Terminology ID referenced in Section 10.1"/"see [I-D.ietf- 
roll-terminology]"
2) Section 2
Right after "Sensing devices may be battery or mains powered.   
Actuators and area
    controllers will be mains powered. "
Please add: "Still it is envisioned to see a mix of wired and wireless  
sensors and actuators in buildings".
3) Section 2
"Facility Management Systems (FMS) are deployed in a large set of
    vertical markets including universities; hospitals; government
    facilities; Kindergarten through High School (K-12); pharmaceutical
    manufacturing facilities; and single-tenant or multi-tenant office
    buildings."
JP> Shouldn't you replace the ";" by "," ?
4) Section 2
Right after "The following sections describe the sensor, actuator,  
area controller
    and zone controller layers of the topology.  (NOTE: The Building
    Controller and Enterprise layers of the FMS are excluded from this
    discussion since they typically deal in communication rates  
requiring
    WLAN communication technologies).  "
JP> Please add a note to mention that this material is provided mainly  
for educational purposes and the routing requirements are detailed in  
section 3.
JP> Then add "The aim of this document is to provide the set of IPv6  
routing requirements for LLN in buildings".

5) I would suggest a slightly different organization ...
* Leave the introduction (up to section 2.1 not included) and make the  
suggested changes above,
* Rename section 2.1 (Facility Management System (FMS) Topology ) =>  
Section 3
* Move the current Section 3 to Appendix B ("An example of building  
automation: the art centre of Vooruit". As such it comes a bit out of  
the blue.

6) On Section 3 (to become appendix):
* s/""popcorn effect" draft"/"popcorn effect"
* There is no word on routing: could you provide some routing  
characteristics in this network (number of hops, devices, ...) ?

Comments on the routing requirements
################################

7) "It MUST be possible to fully commission network devices without
    requiring any additional commissioning device (e.g. laptop). The
    device MAY support up to sixteen integrated switches to uniquely
    identify the device on the network. "
JP> How does the "MAY" translate to routing requirements ?
8) Please reword "Routing
    MUST recognize the constraints associated the power budget of such
    low duty cycle devices."
The routing protocol MUST take into account device characteristics  
such as "power budget".
9) "If the mechanisms for duty cycling dictate very long response  
times or specific temporal
    scheduling, routing and forwarding will need to take such  
constraints
    into account. "
JP> Please remove "forwarding"
10) "Communication to these mostly sleeping devices MUST be  
bidirectional."
JP> Please be more specific. Do you mean by the routing protocol MUST  
be able to compute bi-directional route to sleeping devices ? Why ?
11) "In such cases, routing MUST recognize the selected proxy
    for the sleeping device. "
JP> "recognize" in which way ? Can you be more specific ?
12) "Routing must allow for temporary ad hoc paths to be
    established that are updated as the network physically and
    functionally expands. "
JP> This can be a very stringent requirements (although there is no  
normative language).
13) Section 4.1.4: not a routing requirements
14) Section 4.2
"The routing protocol MUST be able to support networks with at least
    1000 routers and 1000 hosts. "
If a host is not "routing" no need to mention the number of hosts.  
What matters in this section is the number of routers in the LLN. Same  
comments for the number of sensors.
15) Section 4.3
"Mobile devices SHOULD be capable of unjoining (handing-off) from an
    old network joining onto a new network within 15 seconds.
"
JP> You may want to elaborate a little bit on hat you mean by  
"unjoining". Does that mean that the routing protocol must converge  
within 15s after the removal of the device ?

16) "The routing mechanisms MUST
    therefore be tailored to fit these resource constrained devices.  "
JP> This is certainly true but how does this translate to a routing  
requirement ? 10000 times less memory than a several GBytes routers ?  
Since you provide number hereafter, please delete this sentence.
17) In Sections 4.4.1 and 4.4.2, what do you mean by "software stack":  
OS+entire protocol stack ?
18) "Routing MUST support anycast, unicast, multicast and broadcast
    services (or IPv6 equivalent). "
JP> This must be changed ... there is no broadcast in IPv6 (and we are  
exclusively working on IPv6) but IPv6 is using multicast (RFC2373).  
Just remove "broadcast".
19) "4.6.1. Firmware Upgrades

    To support high speed code downloads, routing MUST support  
transports
    that provide parallel downloads to targeted devices yet guarantee
    packet delivery. "
JP> This is clearly a device requirement not a routing requirements. I  
would suggest to delete.
20) "4.6.2. Diagnostics

    To improve diagnostics, the network layer SHOULD be able to be  
placed
    in and out of 'verbose' mode.  Verbose mode is a temporary debugging
    mode that provides additional communication information including at
    least total number of packets sent, packets received, number of
    failed communication attempts, neighbor table and routing table
    entries. "
JP> This is an important requirement. Please just keep the routing  
aspects.
21) "4.6.3. Route Tracking

    Route diagnostics SHOULD be supported providing information such as
    path quality; number of hops; available alternate active paths with
    associated costs. "
JP> Please define "path quality".
22) Section 4.7
JP> I understand your concern but this is not a routing requirement  
either. The IETF specifies IP-based protocol and cannot depend on non- 
IP protocols. I would suggest to remove that section.
23) Section 4.7.1
Per our charter, we exclusively focus on IPv6. Furthermore, the term  
intercommunication is ambiguous. I would suggest to delete 4.7.1
24) Section 4.7.2
"Routing MUST support packet sizes to 1526 octets (to be backwards
    compatible with 802.3 subnetworks) "
JP> Please remove the text in parenthesis. Strictly speaking the ROLL  
protocol(s) will not be backward compatible with 802.3.
25) "Route discovery occurring during packet
    transmission MUST not exceed 120 msecs."
JP> I would suggest to slightly reword since it gives the impression  
that you mandate a reactive routing mechanism.
26) "4.8.5. Route Preference

    The route discovery mechanism SHOULD allow a source node (sensor) to
    dictate a configured destination node (controller) as a preferred
    routing path. "
JP> mmm ... what do you mean by "dictate a configured destination node  
as a preferred path ?". Do you mean that the routing protocol SHOULD  
allow for routing along a configured path on the source ?
27) "4.8.6. Path Persistence

    To eliminate high network traffic in power-fail or brown-out
    conditions previously established routes SHOULD be remembered and
    invoked prior to establishing new routes for those devices  
reentering
    the network. "
JP> This is a device / implementation-specific choice. Should be  
removed.
28) Please remove Section 6
29) Security.
JP> Don't you have any security requirements ? Could you please look at:
http://www.ietf.org/internet-drafts/draft-ietf-roll-urban-routing-reqs-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-roll-indus-routing-reqs-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-06.txt
to see if you do not have security requirements along those lines ?
30) Please remove (see comments number 32 below)
     See Appendix A for additional requirements
    that have been deemed outside the scope of this document yet will
    pertain to the successful deployment of building automation systems.
31) References

Please reformat the references section to list the relevant details of  
each document + add a normative reference to RFC 2119.

For example:

10.  References

10.1.  Normative References

    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2.  Informative References

    [I-D.ietf-roll-home-routing-reqs]
               Brandt, A., Buron, J., and G. Porcu, "Home Automation
               Routing Requirements in Low Power and Lossy Networks",
               draft-ietf-roll-home-routing-reqs-06 (work in progress),
               November 2008.

32) Appendix A
The requirements will need to
    be addressed by ROLL or other WGs before adoption by the building
    automation industry will be considered.
JP> Please remove, since ROLL is about routing, thus we will not be  
chartered to address non routing requirements.
Giving more thoughts, this appendix does provide very useful and well  
documented data. That being said, they do not really belong to this  
document and may introduce confusion. I would suggest to remove this  
appendix from the document.

Thanks.

JP.

---

From: [email-masked]
Date: Fri, 23 Jan 2009 15:29:54 -0600

JP, 

Sorry I missed you before your vacation started.  I am emailing it on 
Friday as you requested, but I forgot until now you're already asleep.  So 
if for some ungodly reason you are reading this during your vacation 
please immediately close this file and have fun!!!  I can assure you this 
document will be just as boring to read when you return from vacation. :-)

I've made most changes as you requested, and noted why i didn't accept the 
comments in a few cases.  I will immediately embark on posting this 
document as -03.  I have interlaced all the comments below and attached 
the .doc file with 'change tracking' turned on so you can more readily 
review the updates.

Regards,

Jerry

JP Vasseur <[email-masked]> 
01/20/2009 04:22 AM

To
[email-masked], ROLL WG <[email-masked]>
cc
"David E. Culler" <[email-masked]>
Subject
Comments on draft-ietf-roll-building-routing-reqs-02.txt

Hi,

1) Section 1

"For description of the terminology used in this specification, please 
   see the Terminology ID referenced in Section 10.1. "
Please add the reference instead of mentioning Section 10.1.
s/"see the Terminology ID referenced in Section 10.1"/"see 
[I-D.ietf-roll-terminology]"
done.

2) Section 2
Right after "Sensing devices may be battery or mains powered.  Actuators 
and area 
   controllers will be mains powered. "
Please add: "Still it is envisioned to see a mix of wired and wireless 
sensors and actuators in buildings".
added as noted.

3) Section 2
"Facility Management Systems (FMS) are deployed in a large set of 
   vertical markets including universities; hospitals; government 
   facilities; Kindergarten through High School (K-12); pharmaceutical 
   manufacturing facilities; and single-tenant or multi-tenant office 
   buildings."
JP> Shouldn't you replace the ";" by "," ?
The nuns taught me that if you have compound items (i.e. 'single-tenant or 
multi-tenant)as members of a list, then you use semicolons to reduce 
ambiguity.  I didn't change it, but am not willing to die on this 
mountain.  Let me know if you want commas :-).

4) Section 2
Right after "The following sections describe the sensor, actuator, area 
controller 
   and zone controller layers of the topology.  (NOTE: The Building 
   Controller and Enterprise layers of the FMS are excluded from this 
   discussion since they typically deal in communication rates requiring 
   WLAN communication technologies).  "
JP> Please add a note to mention that this material is provided mainly for 
educational purposes and the routing requirements are detailed in section 
3.
JP> Then add "The aim of this document is to provide the set of IPv6 
routing requirements for LLN in buildings".

Text added ...

Section 3 describes FMS architectures commonly installed in commercial 
buildings.  Section 4 describes installation methods deployed for new and 
remodeled construction.  Appendix B describes various FMS use-cases and 
the interaction with humans for energy conservation and life-safety 
applications. 
Sections 3, 4, and Appendix B are mainly included for educational 
purposes.  The aim of this document is to provide the set of IPv6 routing 
requirements for LLNs in buildings as described in Section 5.

5) I would suggest a slightly different organization ...
* Leave the introduction (up to section 2.1 not included) and make the 
suggested changes above,
done
* Rename section 2.1 (Facility Management System (FMS) Topology ) => 
Section 3
done.  I also converted Section 2.2 to Section 4 (Installation Methods) .
* Move the current Section 3 to Appendix B ("An example of building 
automation: the art centre of Vooruit". As such it comes a bit out of the 
blue.
done. 

done

The routing protocol is not a function of use case, but more a function of 
spacial device placement and network anomolies.  Rather than add routing 
information in Appendix B, I have added the following two paragraphs to 
the 'Traffic Pattern' section...

Initial system startup after a controlled outage or unexpected power 
failure puts tremendous stress on the network and on the routing 
algorithms.  An FMS system is comprised of a myriad of control algorithms 
at the room, area, zone, and enterprise layers.  When these control 
algorithms are at quiescence, the real-time data changes are small and the 
network will not saturate.  However, upon any power loss, the control 
loops and real-time data quickly atrophy.  A ten minute outage may take 
many hours to regain control.
Upon restart all lines-powered devices power-on instantaneously.  However 
due to application startup and self tests, these devices will attempt to 
join the network randomly.  Empirical testing indicates that routing paths 
acquired during startup will tend to be very oblique since the available 
neighbor lists are incomplete.  This demands for an adaptive path protocol 
to allow for path optimization as the network stabilizes.
Comments on the routing requirements
################################

It's really a commissioning constraint.  The document notes 'zero 
commissioning' time.  This requirement further states that the sensor 
cannot afford the expense of commissioning beyond that of setting a switch 
bank. (This gets back to the abilities of an electrician and the cost and 
size of adding too many switches).

8) Please reword "Routing 
   MUST recognize the constraints associated the power budget of such 
   low duty cycle devices."
The routing protocol MUST take into account device characteristics such as 
"power budget".
Done.

9) "If the mechanisms for duty cycling dictate very long response times or 
specific temporal 
   scheduling, routing and forwarding will need to take such constraints 
   into account. "
JP> Please remove "forwarding"
Done.

10) "Communication to these mostly sleeping devices MUST be 
bidirectional."
JP> Please be more specific. Do you mean by the routing protocol MUST be 
able to compute bi-directional route to sleeping devices ? Why ?
Yes and No.  You're actually asking two questions in your question... 

With regard to sleeping devices, the routing protocol must allow for 
delivering messages to an assigned (awake) proxy device who will later 
transmit the information to the sleeping device upon its awaking.  I've 
actually addressed this as a separate requirement.

With regard to bidirectionality, I am simply saying that sensors must be 
able to receive application ACKs and other configuration data from its 
controller.  Some protocols (such as EnOcean) support only unidirectional 
messaging from the sensor to the controller.  This might work for a 
lightweight application such as a wireless light switch turning on a 
light, but will not work for most of the commercial applications where the 
sensor must know that the packet has been successfully transmitted to the 
controller (say in a Fire application).

I've changed the text to read ...

Communication to  sleeping devices MUST be bidirectional to allow for 
guaranteed packet delivery from the sensor to the controller.   

11) "In such cases, routing MUST recognize the selected proxy 
   for the sleeping device. "
JP> "recognize" in which way ? Can you be more specific ?
This is actually an implementation issue which arguably may not be the 
province of the routing protocol.  As I just mentioned above, sleeping 
devices must have a mechanism to receive packets.  However since they 
sleep the vast majority of the time, they will need a proxy device to hold 
the packet until the next awake cycle.  The question is which layer must 
be cognizant of the proxy device.  The APP layer could do it, but it would 
need to constantly be checking to see if the proxy device has changed.  I 
would prefer that the routing layer recognize that the destination address 
is for a sleeping device and reroute the packet to its assigned proxy with 
forwarding information added to its sleeping device.

The text now reads ...

In such cases, the routing protocol MUST recognize the assigned proxy for 
the sleeping device; deliver the packet to the assigned proxy for later 
delivery to the sleeping device upon its next awake cycle.

This is more an implementation item.  Here the idea is that when 
performing initial room level testing, there needs to be some simple 
network that can be formed to verify local operation (not unlike 802.11 Ad 
Hoc mode or 802.3 crossover cable).  I actually don't want to foist 
normative language onto the implementers.  I changed the 'must' to 
'should' in the text.

I disagree.  Device replacement must have zero configuration and 
immediately join the network as does a new device.  The installer can't 
wait around for a 1/2 hour until the ARP tables flush and the new MAC 
address be recognized.  Because the new device will necessarily have a new 
MAC, the routing protocol will somehow have to deal with routing without 
using MAC addressing.  To me, the text as drafted is clear in this regard. 
 Let me know if I need more clarity to better express my point.

14) Section 4.2
"The routing protocol MUST be able to support networks with at least 
   1000 routers and 1000 hosts. "
If a host is not "routing" no need to mention the number of hosts. What 
matters in this section is the number of routers in the LLN. Same comments 
for the number of sensors.

I think we have a nomenclature issue here.  What I am trying to say is 
that a network (PAN) needs to support at least 1000 powered application 
devices that can also act as routers.  The PAN must additionally support 
1000 sleeping devices which typically have no routing capability.  I would 
think all 2000 of these devices would be termed 'hosts' in the IT 
parlance.  I am in no way thinking that there are application hosts that 
don't route and then traditional standalone routers in the WPAN.  The 
routing protocol needs to be software that resides within the application 
device.

I changed the nomenclature to reference 'hosts' and 'routers' at David's 
request on the last version.  I probably bolixed it up!!!  Please help me 
draft this requirement so it's clear for the IETF reader.

I changed the text to read ...

The routing protocol MUST be able to support networks with at least 2000 
nodes supporting at least 1000 routing devices and 1000 nonrouting device. 

15) Section 4.3

"
JP> You may want to elaborate a little bit on hat you mean by "unjoining". 
Does that mean that the routing protocol must converge within 15s after 
the removal of the device ?

Section 5.4 is a brief introduction of the section upon which the 
requirements are then stated in Sections 5.4.1 and 5.4.2.  I agree that I 
should not therefore be putting normative requirements in the introductory 
section.  What I did is change the 'MUST' to a 'must' thereby making the 
intro only informative.

17) In Sections 4.4.1 and 4.4.2, what do you mean by "software stack": 
OS+entire protocol stack ?
Yes, the entire operating environment other than the end-application.   I 
changed these paragraphs to read ...

5.4.1.  Limited Processing Power for Non-routing Devices.
The software size requirement for non-routing devices (e.g. sensors and 
actuators) MUST be implementable in 8-bit devices with no more than 128KB 
of flash memory (including at least 32KB for the application code) and no 
more than 8KB of RAM (including at least 1KB RAM available for the 
application). 
5.4.2.  Limited Processing Power for Routing Devices
The software size requirements for routing devices (e.g. room controllers) 
SHOULD be implementable in 8-bit devices with no more than 256KB of flash 
memory (including at least 32KB for the application code) and no more than 
8KB of RAM (including at least 1KB RAM available for the application).

18) "Routing MUST support anycast, unicast, multicast and broadcast 
   services (or IPv6 equivalent). "
JP> This must be changed ... there is no broadcast in IPv6 (and we are 
exclusively working on IPv6) but IPv6 is using multicast (RFC2373). Just 
remove "broadcast".
done.   I presume that there is a form of multicast that will deliver a 
discovery packet to every node on the subnetwork.  BACnet requires a 
network wide broadcast to discover nodes and objects anywhere on the 
internetwork.  It has intrinsic support for unicasting across subnetworks.

   To support high speed code downloads, routing MUST support transports 
   that provide parallel downloads to targeted devices yet guarantee 
   packet delivery. "
JP> This is clearly a device requirement not a routing requirements. I 
would suggest to delete.

I'm not willing to give in on this one.  I agree that as stated this is 
more of an implementation approach (i.e. how to do it) rather than a 
requirement (i.e. what needs to be done).  The point I am trying to make 
is that firmware upgrades must be very fast to not lose building control.  
This has been implemented by supporting QoS and a special version of 
multicast (end of transmission ACKs) that allows all devices to be 
downloaded in parallel yet guarantee delivery.

20) "4.6.2. Diagnostics 

   To improve diagnostics, the network layer SHOULD be able to be placed 
   in and out of 'verbose' mode.  Verbose mode is a temporary debugging 
   mode that provides additional communication information including at 
   least total number of packets sent, packets received, number of 
   failed communication attempts, neighbor table and routing table 
   entries. "
JP> This is an important requirement. Please just keep the routing 
aspects.
Not sure if you're asking for some deletion. no change to text.

Whatever means we employ to select one path over other paths.  In 
debugging, it's sometime unclear why one path is selected in lieu of other 
paths.  This info should be available.

I added the sentence...

Path quality is the relative measure of ?goodness? of the selected source 
to destination path as compared to alternate paths.  This  composite value 
may be measured as a function of hop count, signal strength, available 
power, existing active paths or any other criteria deemed by ROLL as the 
path cost differentiator.

22) Section 4.7
JP> I understand your concern but this is not a routing requirement 
either. The IETF specifies IP-based protocol and cannot depend on non-IP 
protocols. I would suggest to remove that section.
BACnet is an application protocol that sits atop of UDP.  Hence it is an 
IP protocol!!!.   To me, this is no different than assuring that 
ROLL/6LoWPAN supports FTP. 
I don't know if LON has intrinsic IP support.  I will drop the LON 
requirement.  The text now reads ...

The building automation industry adheres to BACnet, a UDP/IP application 
layer protocol, to achieve vendor interoperability.  It is estimated that 
fully 80% of customer bid requests received world-wide will require 
compliance to this ISO standard within five years.  ROLL routing SHOULD 
support this application protocol to assure acceptance in the building 
automation industry.  

23) Section 4.7.1
Per our charter, we exclusively focus on IPv6. Furthermore, the term 
intercommunication is ambiguous. I would suggest to delete 4.7.1
I  moved this requirement to Appendix A as being out of scope for ROLL. 
However, the FMS industry has been installing IPv4 devices into buildings 
for at least 10 years.  These devices have a lifetime of at least 25 years 
and will need to communicate to newer devices.  If we (the IETF) don't 
provide a seamless interface across IPv4 and IPv6 we can expect little 
interest in this market.

24) Section 4.7.2
Done.

25) "Route discovery occurring during packet 
   transmission MUST not exceed 120 msecs."
JP> I would suggest to slightly reword since it gives the impression that 
you mandate a reactive routing mechanism.
I tried to clarify the need and changed the MUST to SHOULD.  It now reads 
...

Route discovery occurring during packet transmission SHOULD not add more 
than 120 msecs latency to the packet mean delivery time.

   The route discovery mechanism SHOULD allow a source node (sensor) to 
   dictate a configured destination node (controller) as a preferred 
   routing path. "
JP> mmm ... what do you mean by "dictate a configured destination node as 
a preferred path ?". Do you mean that the routing protocol SHOULD allow 
for routing along a configured path on the source ?
The word 'dictate' is probably too strong.  Maybe 'suggest' would be 
better.  What I'm trying to note is that many FMS applications have 
apriori knowledge of the spatial placement of the client and server 
devices.  Yet the 'route cost' algorithms don't  account for this 
knowledge in the costing algorithm calculations.  As an example, a room 
temperature sensor and its associated room controller are always within 
point-to-point distance.  Yet empirical data shows that many times the 
path will have additional hops.  The added latency of a couple additional 
hops isn't at issue.  It's just the extra load on the network to hop 
across extraneous devices.

I changed the text to read ...

Route cost algorithms SHOULD allow the installer to optionally select 
'preferred' paths based on the known spatial layout of the communicating 
devices.

   To eliminate high network traffic in power-fail or brown-out 
   conditions previously established routes SHOULD be remembered and 
   invoked prior to establishing new routes for those devices reentering 
   the network. "
JP> This is a device / implementation-specific choice. Should be removed.
I disagree.  We're dealing with a LLNs that can ill-afford to have 
hundreds of nodes simultaneously purge their neighbor lists and routing 
tables just because of a 1 second brownout!  I think at some point the 
IETF has to take into account that LLNs are very limited data highways and 
mandate certain operational modes.

28) Please remove Section 6
Hmmm,  little confused here since prior comments changed the section 
numbers.  I am assuming this comment references the 'Open Issues' section. 
 I've deleted that section. 

29) Security.

Yes.  My first draft had 10 pages of security requirements!  However, we 
deemed them out of scope since these requirements do not affect routing. 
What we seemed to agree to in the email exchanges is that a node must be 
trusted (and possibly authenticated) upon joining the network, but once a 
trusted node joins the network, it can move packets across the network 
unimpeded by security concerns.

The text now reads ...

7.      Security Considerations
Security policies, especially wireless encryption and device 
authentication needs to be considered, especially with concern to the 
impact on the processing capabilities and additional latency incurred on 
the sensors, actuators and controllers.
FMS systems are typically highly configurable in the field and hence the 
security policy is most often dictated by the type of building to which 
the FMS is being installed.   Single tenant owner occupied office 
buildings installing lighting or HVAC control are candidates for 
implementing low or even no security on the LLN.  Antithetically, military 
or pharmaceutical facilities require strong security policies.  As noted 
in the installation procedures above, security policies must be facile to 
allow no security during the installation phase (prior to building 
occupancy), yet easily raise the security level network wide during the 
commissioning phase of the system.
7.1.    Security Requirements
7.1.1.  Authentication
Authentication MUST be optional on the LLN.  Authentication MUST be fully 
configurable on-site. Authentication policy and updates MUST be 
transmittable over-the-air.  Authentication MUST occur upon joining or 
rejoining a network.  However, once authenticated devices SHOULD not need 
to reauthenticate themselves with any other devices in the LLN.
7.1.2.  Encryption
7.1.2.1.        Encryption Levels
Encryption MUST be optional on the LLN.  Encryption MUST be fully 
configurable on-site.  Encryption policy and updates MUST be transmittable 
over-the-air and in-the-clear. 
7.1.2.2.        Security Policy Flexibility
In most facilities authentication and encryption will be turned off during 
installation. 
More complex encryption policies might be put in force at commissioning 
time.  New encryption policies MUST be allowed to be presented to all 
devices in the LLN over the network without needing to visit each device.
7.1.2.3.        Encryption Types
Data encryption of packets MUST optionally be supported by use of either a 
network wide key and/or application key.    The network key would apply to 
all devices in the LLN.  The application key would apply to a subset of 
devices on the LLN. 
The network key and application keys would be mutually exclusive. 
Forwarding devices in the mesh MUST be able to forward a packet encrypted 
with an application key without needing to have the application key.
7.1.2.4.        Packet Encryption 
The encryption policy MUST support encryption of the payload only or the 
entire packet.  Payload only encryption would eliminate the 
decryption/re-encryption overhead at every hop.
7.1.3.  Disparate Security Policies
Due to the limited resources of an LLN, the security policy defined within 
the LLN MUST be able to differ from that of the rest of the IP network 
within the facility yet packets MUST still be able to route to or through 
the LLN from/to these networks.

See below

31) References

Done.

For example:

10.  References

32) Appendix A

In my mind the requirements noted in  Appendix A are as important to the 
successful deployment of IP wireless sensor networks than most of those 
still in the body of the document.  It's only because of the 
compartmentalized nature of the IETF that you feel they are out of scope. 
I think it's very important that we continue to look at the requirement 
set holistically even if our current mission is more tightly focused.  I 
would like to leave Appendix A included in this document.

Thanks.

JP.

Begin forwarded message:

From: [email-masked]
Date: January 15, 2009 12:00:02 AM CEST
To: [email-masked]
Cc: [email-masked]
Subject: [Roll] I-D Action:draft-ietf-roll-building-routing-reqs-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Routing Over Low power and Lossy networks 
Working Group of the IETF.

Title           : Building Automation Routing Requirements in Low Power 
and Lossy Networks
Author(s)       : J. Martocci, et al.
Filename        : draft-ietf-roll-building-routing-reqs-02.txt
Pages           : 27
Date            : 2009-01-14

Requirements Language 

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft._______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

[attachment "mime-attachment" deleted by Jerald P 
Martocci/CORP/Johnson_Controls] 
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: JP Vasseur <[email-masked]>
Date: Sat, 24 Jan 2009 16:46:36 +0100

Hi Jerry,

On Jan 23, 2009, at 10:29 PM, [email-masked] wrote:

>
> JP,
>
> Sorry I missed you before your vacation started.  I am emailing it  
> on Friday as you requested, but I forgot until now you're already  
> asleep.  So if for some ungodly reason you are reading this during  
> your vacation please immediately close this file and have fun!!!  I  
> can assure you this document will be just as boring to read when you  
> return from vacation. :-)

OK I'll make an exception while I'm still on-line ;-)

Thanks for the quick reply to my comments - We just have a very few  
items to sort out - see in line.

>
>
> I've made most changes as you requested, and noted why i didn't  
> accept the comments in a few cases.  I will immediately embark on  
> posting this document as -03.  I have interlaced all the comments  
> below and attached the .doc file with 'change tracking' turned on so  
> you can more readily review the updates.
>
> Regards,
>
> Jerry
>
>
>
>
>
>
> First of all thanks for the hard work and several revisions  
> addressing many comments. There are still several comments to address.
>

OK

> Please add: "Still it is envisioned to see a mix of wired and  
> wireless sensors and actuators in buildings".
> added as noted.
>
>

OK

> The nuns taught me that if you have compound items (i.e. 'single- 
> tenant or multi-tenant)as members of a list, then you use semicolons  
> to reduce ambiguity.  I didn't change it, but am not willing to die  
> on this mountain.  Let me know if you want commas :-).

This is fine, you are the native English speaker ;-) The RFC editor  
will catch this if needed.

> JP> Please add a note to mention that this material is provided  
> mainly for educational purposes and the routing requirements are  
> detailed in section 3.
> Section 3 describes FMS architectures commonly installed in  
> commercial buildings.  Section 4 describes installation methods  
> deployed for new and remodeled construction.  Appendix B describes  
> various FMS use-cases and the interaction with humans for energy  
> conservation and life-safety applications.
> purposes.  The aim of this document is to provide the set of IPv6  
> routing requirements for LLNs in buildings as described in Section 5.
>
Thanks.
> * Leave the introduction (up to section 2.1 not included) and make  
> the suggested changes above,
> done
> automation: the art centre of Vooruit". As such it comes a bit out  
> of the blue.
> done.
>
>
Thanks.
> The routing protocol is not a function of use case, but more a  
> function of spacial device placement and network anomolies.  Rather  
> than add routing information in Appendix B, I have added the  
> following two paragraphs to the 'Traffic Pattern' section...
>
> algorithms.  An FMS system is comprised of a myriad of control  
> algorithms at the room, area, zone, and enterprise layers.  When  
> these control algorithms are at quiescence, the real-time data  
> changes are small and the network will not saturate.  However, upon  
> any power loss, the control loops and real-time data quickly  
> atrophy.  A ten minute outage may take many hours to regain control.
>
> Upon restart all lines-powered devices power-on instantaneously.   
> However due to application startup and self tests, these devices  
> will attempt to join the network randomly.  Empirical testing  
> indicates that routing paths acquired during startup will tend to be  
> very oblique since the available neighbor lists are incomplete.   
> This demands for an adaptive path protocol to allow for path  
> optimization as the network stabilizes.
>
Fine text, thanks.

> commissioning' time.  This requirement further states that the  
> sensor cannot afford the expense of commissioning beyond that of  
> setting a switch bank. (This gets back to the abilities of an  
> electrician and the cost and size of adding too many switches).
>
>
I am fine with the first sentence but I was referring to the second  
part (MAY). I would strongly suggest to remove the second sentence  
(The device MAY support up to sixteen ...". This is way too specific.  
Thanks.
> The routing protocol MUST take into account device characteristics  
OK
> JP> Please remove "forwarding"
OK
> JP> Please be more specific. Do you mean by the routing protocol  
> MUST be able to compute bi-directional route to sleeping devices ?  
> Why ?
Yes we leave in a constrained environment ;-))
> delivering messages to an assigned (awake) proxy device who will  
> later transmit the information to the sleeping device upon its  
> awaking.  I've actually addressed this as a separate requirement.
>
>
Indeed.
> With regard to bidirectionality, I am simply saying that sensors  
> must be able to receive application ACKs and other configuration  
> data from its controller.  Some protocols (such as EnOcean) support  
> only unidirectional messaging from the sensor to the controller.   
> This might work for a lightweight application such as a wireless  
> light switch turning on a light, but will not work for most of the  
> commercial applications where the sensor must know that the packet  
> has been successfully transmitted to the controller (say in a Fire  
> application).
>
>
Which does not necessarily mean a bi-directional route though. As you  
know most of routing protocols are computing unidirectional routes  
(fortunately!)

> Communication to  sleeping devices MUST be bidirectional to allow  
> for guaranteed packet delivery from the sensor to the controller.
>
Which is clearer but I still have an issue since this is a routing  
requirement. I do not think that you require the routing protocol to  
compute bi-directional routes. I understand that the communication  
must be bi-directional thus this does not add any routing requirements  
in addition to being able to compute routes from a node A to a node B  
(and vice versa of course). Thus this sentence can be deleted, it is  
already covered.
> This is actually an implementation issue which arguably may not be  
> the province of the routing protocol.
>
This is where I was going ...
> As I just mentioned above, sleeping devices must have a mechanism to  
> receive packets.  However since they sleep the vast majority of the  
> time, they will need a proxy device to hold the packet until the  
> next awake cycle.  The question is which layer must be cognizant of  
> the proxy device.  The APP layer could do it, but it would need to  
> constantly be checking to see if the proxy device has changed.  I  
> would prefer that the routing layer recognize that the destination  
> address is for a sleeping device and reroute the packet to its  
> assigned proxy with forwarding information added to its sleeping  
> device.
>
> The text now reads ...
>
> In such cases, the routing protocol MUST recognize the assigned  
> proxy for the sleeping device; deliver the packet to the assigned  
> proxy for later delivery to the sleeping device upon its next awake  
> cycle.
>
Slight disagreement here ...

Several cases:
1) You consider this an an application issue: then reword the text by  
mentioning the functionality as an application issue and remove the  
"MUST" or simply remove the sentence.
2) You want to influence the routing decision to traverse the proxy.  
This is fine and you should reword the text this way: "The routing  
protocol MUST discover the capability of a node to act as a proxy  
during path calculation".
3) You want to change IP routing (which is based on the destination  
and other criteria) and swap destination address ... I guess this is  
not what you propose.
> network that can be formed to verify local operation (not unlike  
> 802.11 Ad Hoc mode or 802.3 crossover cable).  I actually don't want  
> to foist normative language onto the implementers.  I changed the  
> 'must' to 'should' in the text.
>
>
OK
> immediately join the network as does a new device.  The installer  
> can't wait around for a 1/2 hour until the ARP tables flush and the  
> new MAC address be recognized.  Because the new device will  
> necessarily have a new MAC, the routing protocol will somehow have  
> to deal with routing without using MAC addressing.  To me, the text  
> as drafted is clear in this regard.  Let me know if I need more  
> clarity to better express my point.
>
>
In the text you are referring to IP address assignment, use of MAC  
address, ... these are all IP-related issues (not routing !). The  
routing relates issue is covered in 4.1.1
> What matters in this section is the number of routers in the LLN.  
> Same comments for the number of sensors.
>
> I think we have a nomenclature issue here.  What I am trying to say  
> is that a network (PAN) needs to support at least 1000 powered  
> application devices that can also act as routers.  The PAN must  
> additionally support 1000 sleeping devices which typically have no  
> routing capability.  I would think all 2000 of these devices would  
> be termed 'hosts' in the IT parlance.  I am in no way thinking that  
> there are application hosts that don't route and then traditional  
> standalone routers in the WPAN.  The routing protocol needs to be  
> software that resides within the application device.
>
> I changed the nomenclature to reference 'hosts' and 'routers' at  
> David's request on the last version.  I probably bolixed it up!!!   
> Please help me draft this requirement so it's clear for the IETF  
> reader.
>
> The routing protocol MUST be able to support networks with at least  
> 2000 nodes supporting at least 1000 routing devices and 1000  
> nonrouting device.
>
Good, thanks.
> within 15s after the removal of the device ?

?
> requirement ? 10000 times less memory than a several GBytes  
> routers ? Since you provide number hereafter, please delete this  
> sentence.
>
> requirements are then stated in Sections 5.4.1 and 5.4.2.  I agree  
> that I should not therefore be putting normative requirements in the  
> introductory section.  What I did is change the 'MUST' to a 'must'  
> thereby making the intro only informative.
>
>
Good.
>
> 17) In Sections 4.4.1 and 4.4.2, what do you mean by "software  
> stack": OS+entire protocol stack ?
> Yes, the entire operating environment other than the end- 
> application.   I changed these paragraphs to read ...
>
> The software size requirement for non-routing devices (e.g. sensors  
> and actuators) MUST be implementable in 8-bit devices with no more  
> than 128KB of flash memory (including at least 32KB for the  
> application code) and no more than 8KB of RAM (including at least  
> 1KB RAM available for the application).
>
> The software size requirements for routing devices (e.g. room  
> controllers) SHOULD be implementable in 8-bit devices with no more  
> than 256KB of flash memory (including at least 32KB for the  
> application code) and no more than 8KB of RAM (including at least  
> 1KB RAM available for the application).
>
But you see the issue ... since you enter in some implementation  
issue, what if the OS+infra+... code takes 99% of the RAM/Flash. What  
do I have left for the routing component. My strong suggestion here  
would be to use non normative language, usually not a good idea to  
indicate numbers with normative language in IETF I-D (think if the  
authors of RFC791 had done this !).
> JP> This must be changed ... there is no broadcast in IPv6 (and we  
> are exclusively working on IPv6) but IPv6 is using multicast  
> (RFC2373). Just remove "broadcast".
> done.   I presume that there is a form of multicast that will  
> deliver a discovery packet to every node on the subnetwork.
>
Yes:-) Thanks.
>  BACnet requires a network wide broadcast to discover nodes and  
> objects anywhere on the internetwork.  It has intrinsic support for  
> unicasting across subnetworks.
>
> JP> This is clearly a device requirement not a routing requirements.  
> I would suggest to delete.
>
> I'm not willing to give in on this one.  I agree that as stated this  
> is more of an implementation approach (i.e. how to do it) rather  
> than a requirement (i.e. what needs to be done).  The point I am  
> trying to make is that firmware upgrades must be very fast to not  
> lose building control.   This has been implemented by supporting QoS  
> and a special version of multicast (end of transmission ACKs) that  
> allows all devices to be downloaded in parallel yet guarantee  
> delivery.
>
>
It depends of what you mean by "parallel" downloads. If you refer to  
the ability of the application to handle two parallel streams please  
delete. If you want to routing protocol to provide two parallel  
potential disjoint paths then clarify and keep.

> Not sure if you're asking for some deletion. no change to text.
I am proposing to keep the text related to routing (and remove the non  
routing piece): the text should read:

>   least total number of routing packets sent and received, number of
>   routing failure (no route available), neighbor table and routing  
> table
>   entries.

But the total number of packet sent out of an interface is not a  
routing requirements.
> debugging, it's sometime unclear why one path is selected in lieu of  
> other paths.  This info should be available.
>
> I added the sentence...
>
> Path quality is the relative measure of ‘goodness’ of the selected  
> source to destination path as compared to alternate paths.  This   
> composite value may be measured as a function of hop count, signal  
> strength, available power, existing active paths or any other  
> criteria deemed by ROLL as the path cost differentiator.
>
>
>
Good.
> either. The IETF specifies IP-based protocol and cannot depend on  
> non-IP protocols. I would suggest to remove that section.
> BACnet is an application protocol that sits atop of UDP.  Hence it  
> is an IP protocol!!!.
>

Although they are routing on top of IP using IP as layer 2 (but this  
is another discussion).
> To me, this is no different than assuring that ROLL/6LoWPAN supports  
> FTP.
> The building automation industry adheres to BACnet, a UDP/IP  
> application layer protocol, to achieve vendor interoperability.  It  
> is estimated that fully 80% of customer bid requests received world- 
> wide will require compliance to this ISO standard within five  
> years.  ROLL routing SHOULD support this application protocol to  
> assure acceptance in the building automation industry.
>
We cannot keep that text. What does it mean "ROLL SHOULD support this  
application ?". ROLL will specific a routing protocol in LLN. Any IP- 
based application will be supported if it relies on IP. This is the  
beauty of layering.
> I  moved this requirement to Appendix A as being out of scope for  
> ROLL.  However, the FMS industry has been installing IPv4 devices  
> into buildings for at least 10 years.  These devices have a lifetime  
> of at least 25 years and will need to communicate to newer devices.   
> If we (the IETF) don't provide a seamless interface across IPv4 and  
> IPv6 we can expect little interest in this market.
>
Good that you moved to the appendix. yes there are already defined  
mechanism between v4 and v6.
> JP> Please remove the text in parenthesis. Strictly speaking the  
> ROLL protocol(s) will not be backward compatible with 802.3.
> Done.
>

OK
> I tried to clarify the need and changed the MUST to SHOULD.  It now  
> reads ...
>
> Route discovery occurring during packet transmission SHOULD not add  
> more than 120 msecs latency to the packet mean delivery time.
>
>
>
Still implicitly implying reactive routing. I would suggest "If route  
discovery occurs during packet transmission time, it SHOULD NOT add  
more than 120ms of latency to the packet delivery time".
> JP> mmm ... what do you mean by "dictate a configured destination  
> node as a preferred path ?". Do you mean that the routing protocol  
> SHOULD allow for routing along a configured path on the source ?
> knowledge in the costing algorithm calculations.  As an example, a  
> room temperature sensor and its associated room controller are  
> always within point-to-point distance.  Yet empirical data shows  
> that many times the path will have additional hops.  The added  
> latency of a couple additional hops isn't at issue.  It's just the  
> extra load on the network to hop across extraneous devices.
>
> Route cost algorithms SHOULD allow the installer to optionally  
> select 'preferred' paths based on the known spatial layout of the  
> communicating devices.
>
>
>
OK
> hundreds of nodes simultaneously purge their neighbor lists and  
> routing tables just because of a 1 second brownout!  I think at some  
> point the IETF has to take into account that LLNs are very limited  
> data highways and mandate certain operational modes.
>
>
I do not disagree with the importance of the requirements and we  
cannot prevent people from wrong implementation.
Clearly we cannot keep that MUST here, this is pure implementation  
issue and cannot stay in the document.
> numbers.  I am assuming this comment references the 'Open Issues'  
> section.  I've deleted that section.
>
>
Yes indeed. Thanks.
> Yes.  My first draft had 10 pages of security requirements!   
> However, we deemed them out of scope since these requirements do not  
> affect routing.  What we seemed to agree to in the email exchanges  
> is that a node must be trusted (and possibly authenticated) upon  
> joining the network, but once a trusted node joins the network, it  
> can move packets across the network unimpeded by security concerns.
>
> The text now reads ...
>
> authentication needs to be considered, especially with concern to  
> the impact on the processing capabilities and additional latency  
> incurred on the sensors, actuators and controllers.
>
> FMS systems are typically highly configurable in the field and hence  
> the security policy is most often dictated by the type of building  
> to which the FMS is being installed.   Single tenant owner occupied  
> office buildings installing lighting or HVAC control are candidates  
> for implementing low or even no security on the LLN.   
> Antithetically, military or pharmaceutical facilities require strong  
> security policies.  As noted in the installation procedures above,  
> security policies must be facile to allow no security during the  
> installation phase (prior to building occupancy), yet easily raise  
> the security level network wide during the commissioning phase of  
> the system.
>
> Authentication MUST be optional on the LLN.  Authentication MUST be  
> fully configurable on-site. Authentication policy and updates MUST  
> be transmittable over-the-air.  Authentication MUST occur upon  
> joining or rejoining a network.  However, once authenticated devices  
> SHOULD not need to reauthenticate themselves with any other devices  
> in the LLN.
>
> 7.1.2.         Encryption
> configurable on-site.
=> See this is another implementation issue.

> Encryption policy and updates MUST be transmittable over-the-air and  
> in-the-clear.
>
> In most facilities authentication and encryption will be turned off  
> during installation.
>
> More complex encryption policies might be put in force at  
> commissioning time.  New encryption policies MUST be allowed to be  
> presented to all devices in the LLN over the network without needing  
> to visit each device.
>
> Data encryption of packets MUST optionally be supported by use of  
> either a network wide key and/or application key.    The network key  
> would apply to all devices in the LLN.  The application key would  
> apply to a subset of devices on the LLN.
>
> Forwarding devices in the mesh MUST be able to forward a packet  
> encrypted with an application key without needing to have the  
> application key.
>
> The encryption policy MUST support encryption of the payload only or  
> the entire packet.  Payload only encryption would eliminate the  
> Due to the limited resources of an LLN, the security policy defined  
> within the LLN MUST be able to differ from that of the rest of the  
> IP network within the facility yet packets MUST still be able to  
> route to or through the LLN from/to these networks.
>
>

Please just add "Routing" whenever appropriate to show that this is  
not applicable to all traffic in this particular document.

> Please reformat the references section to list the relevant details  
> of each document + add a normative reference to RFC 2119.
> Done.
>
> For example:
>
> 10.  References
>

Thanks.

> Giving more thoughts, this appendix does provide very useful and  
> well documented data. That being said, they do not really belong to  
> this document and may introduce confusion. I would suggest to remove  
> this appendix from the document.
>
> In my mind the requirements noted in  Appendix A are as important to  
> the successful deployment of IP wireless sensor networks than most  
> of those still in the body of the document.  It's only because of  
> the compartmentalized nature of the IETF that you feel they are out  
> of scope.  I think it's very important that we continue to look at  
> the requirement set holistically even if our current mission is more  
> tightly focused.  I would like to leave Appendix A included in this  
> document.
>
>
>
OK let's keep it there and we will see during IESG review whether we  
need to remove it.

Thanks to incorporate in rev03 and wait before posting until end of LC  
on January 30 at 9:00am to address potentially other comments.

Thanks.

JP.

> [attachment "mime-attachment" deleted by Jerald P Martocci/CORP/ 
> Johnson_Controls]
> <draft-ietf-roll-building-routing- 
> reqs-03.doc>_______________________________________________
> Roll mailing list
> [email-masked]