Subject: [RSN] BOF Schedule, proposed agenda and WG charter

From: JP Vasseur <[email-masked]>
Date: Mon, 12 Nov 2007 13:33:06 -0500

Dear all,

So the BOF will be held on Thursday:

1510-1610 Afternoon Session II
Oak    INT    mip4    Mobility for IPv4 WG
Salon 2    RAI    peppermint    Provisioning Extensions in Peering
Registries for Multimedia INTerconnection BOF
Salon 1    RTG    isis    IS-IS for IP Internets WG
Salon A/B    RTG    rl2n    Routing For Low Power and Lossy Networks BOF
Cypress    SEC    btns    Better-Than-Nothing Security WG

I uploaded the BOF Agenda:
http://www3.ietf.org/proceedings/07dec/agenda/rl2n.txt

And we updated the Proposed WG Charter: http://www.employees.org/~jvasseur/

Comments welcome.

Thanks.

JP and David.

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

---

From: "Ian Chakeres" <[email-masked]>
Date: Tue, 13 Nov 2007 20:05:25 +0530

RSN/RL2N,

I think the WG charter is still fuzzy, perhaps it will gel after the
pre-BOF meetup.

Have you considered using an exploratory group? It would perhaps help
create the focus needed.

http://www.ietf.org/internet-drafts/draft-aboba-sg-experiment-04.txt

Ian

---

From: Philip Levis <[email-masked]>
Date: Tue, 13 Nov 2007 10:37:53 -0800

> http://www.ietf.org/internet-drafts/draft-aboba-sg-experiment-04.txt

Ian,

Let me try a rewording of the 4th paragraph that does not change the  
content in any way:

The Working Group has two goals. The first is to survey and establish  
the requirements for the applications described above. The second is  
to design and develop routing solutions for these applications that  
meet the key RL2N requirements of being energy efficient, dealing  
with dynamic link loss rates, and having small routing state.

What do you feel is fuzzy here?

Phil

---

From: JP Vasseur <[email-masked]>
Date: Tue, 13 Nov 2007 13:54:54 -0500

Ian,

You asked several relevant questions in a previous email thread to which we
replied and that we took into account in the proposed WG charter. There are
still clarifications to be made (IPv4 / v6, ...). We plan to post early next
week the minutes of the pre-WG meeting that will take place this coming
Thursday in order to get additional feed-back and adjust the proposed
charter before the BOF.

As matter of fact, we have a good set of people with the required background
and level of energy to make relevant contribution that are in clear
agreement on what needs to be done. We have received so far lots of positive
and constructive feed-backs. That being said, since you pointed to
draft-aboba-sg-experiment-04.txt, I'm tempted to provide a concise reply to
these questions, which will also allow the people on the list to express
their opinion and make sure that we are all on the same page.

      - Are the issues that the working group plans to address
        clear and relevant to the Internet community?

JP> Based on the number of feed-backs received so far and the comments that
we got during the Routing area meeting, it seems quite clear but if there is
anything unclear, we will be more happy to clarify.

      - Are the goals specific and reasonably achievable, and
        achievable within a reasonable time frame?

JP> One of the challenges with L2Ns is that the scope may potentially be
wide. We had initially started to collect the requirements in an ID but we
decided to adopt an application-specific approach, which has proven to be
quite efficient in several other WGs:

" There is wide scope of application areas for L2Ns, including industrial
monitoring, building HVAC and lighting control, connected home, healthcare,
environmental monitoring, agricultural, smart cities, logistics, and
refrigeration. The L2N WG will focus on routing solutions for a subset of
these deployment scenarios, namely industrial, connected home/building and
smart cities." 

There are already two ID for Industrial and Connected Home driven by authors
with a strong expertise in each area and deployment background.

Thus the work is SCOPED and WELL UNDERSTOOD.

      - What are the risks and urgency of the work, to determine
        the level of effort required?

JP> See our presentation during the Routing Area meeting in Chicago.
Proprietary solutions are being deployed TODAY. It is thus urgent to specify
an IP standard based solution. The problem is well understood and solutions
are deployed so the level of risk is minor.

      - Do the working group's activities overlap with those of
        another working group?
        ...

JP> There is no overlap but of course RL2N *will* have to work with other
WGs for sure such as 6lowpan (see the consensual decision wrt to routing),
MANET, ...  

      - Is there sufficient interest within the IETF in the working
        group's topic with enough people willing to expend the effort
        to produce the desired result (e.g., a protocol specification)?
        ...

JP> Looking at the number of people involved, it is much look like it is.

      - Is there enough expertise within the IETF in the working
        group's topic, and are those people interested in
        contributing in the working group?
        ...

JP> This is a key question particularly relevant here since L2Ns are quite
specific and require a set of areas of expertise. When we first started this
initiative we spent time making sure to have experts in L2N (Sensor) and
Routing with a different backgrounds (end user, Service Providers,
Sensor/L2N/Router Vendors, academic). If you look at the various IDs and
active participants, we will see a good representation of each category.

      - Does a base of interested consumers (end-users) appear to
        exist for the planned work?
        ...

JP> Yes although I would prefer them to express themselves here.

      - Does the IETF have a reasonable role to play in the
        determination of the technology?
        ...

JP> If we want to see IP in L2Ns, it is definitely the case, I do not think
that we need to argue here.

      - Are all known intellectual property rights relevant to
        the proposed working group's efforts issues understood?

JP> The WG may of course have to deal with IPR issues. Nothing specific to
the area of L2Ns. 

      - Is the proposed work plan an open IETF effort or is it an
        attempt to "bless" non-IETF technology where the effect of
        input from IETF participants may be limited?

JP> With no restriction, an open IETF effort. Should a WG be formed, we may
want to establish liaison with other SDOs/Alliance (e.g. Zigbee) but the
work is an open IETF effort and by no means an attempt to "bless" non IETF
technology.

      - Is there a good understanding of any existing work that is
        relevant to the topics that the proposed working group is to
        pursue?  This includes work within the IETF and elsewhere.

JP> Yes, see the protocol overview draft. Furthermore the participants also
have a strong knowledge on what being done elsewhere (SP100, Zigbee, Zwave,
..)

      - Do the working group's goals overlap with known work in
        another standards body, and if so is adequate liaison
        in place?

JP> This is the point that I was mentioning before. We're planning to
discuss potential liaisons during the pre-WG meeting this week.

Thanks.

JP.  

> From: Ian Chakeres <[email-masked]>
> Date: Tue, 13 Nov 2007 20:05:25 +0530
> To: JP Vasseur <[email-masked]>
> Cc: <[email-masked]>
> Subject: Re: [RSN] BOF Schedule, proposed agenda and WG charter
> 
> RSN/RL2N,
>

---

From: "Ian Chakeres" <[email-masked]>
Date: Wed, 14 Nov 2007 00:28:48 +0530

I don't think that the group has agreement on the
challenges/requirements that will be addressed. Right now, the group
is seems to be flushing out a large wish list for requirements in many
sensor network areas, but I haven't seen any discussion on which of
these requirements MUST be accomplished by a proposed protocol.

Also, given the multiple conflicting goals (energy efficient, dynamic
loss rates, small routing sate) it would be nice if the group could
determine the priority among them. As proposed solutions will probably
each tradeoff one goal for another.

I think the exploratory group concept seems to match the current state
of RSN/RL2N.

Ian

---

From: JP Vasseur <[email-masked]>
Date: Tue, 13 Nov 2007 14:01:29 -0500

Ian,

> Date: Wed, 14 Nov 2007 00:28:48 +0530
> To: Philip Levis <[email-masked]>
> Cc: JP Vasseur <[email-masked]>, <[email-masked]>

Did you read the application specific requirement IDs?

> each tradeoff one goal for another.

Same comment. 

> I think the exploratory group concept seems to match the current state

See my previous email.

Thanks.

JP.

---

From: Philip Levis <[email-masked]>
Date: Tue, 13 Nov 2007 11:29:28 -0800

Ian,

The challenges are:

1) Dealing with dynamic loss rates
2) Being energy efficient
3) Have small routing state

Of course, once you start ultra-optimizing any of these three, you  
will enter a realm of tradeoffs and possibly a suite of protocols to  
choose from. But experience has shown that something which is good  
and general is the key step: it's pretty clear that one can design  
protocols that simultaneously beat existing standardized protocols on  
all three requirements.

Given how many real applications there are out there, how much  
vendors are clamoring for good open protocols, and how many real  
protocols have been analyzed, implemented, and evaluated, it seems to  
me that the period of exploration is over. Today, there are working  
protocols that meet all three requirements and run on hundreds of  
thousands of nodes. The goal is to transition and evolve this work  
into a set of standards that enable IP connectivity to the next 10  
billion nodes.

I also feel like you're applying a double standard here. What are the  
requirements that MANETs MUST meet? We have to be careful with MUST  
statements for normative reasons...

Phil

---

From: "Dominik Kaspar" <[email-masked]>
Date: Wed, 14 Nov 2007 13:55:01 +0900

Philip,

Talking about the three challenges/requirements you listed (are these
terms "challenges" and "requirements" interchangeable anyway?)

Philip: "[...] it's pretty clear that one can design protocols that
simultaneously beat existing standardized protocols on all three
requirements."

Would you mind to clarify why this is so clear? I think it is indeed
still a challenge. Are there any studies to support your statement?

Philip: "Today, there are working protocols that meet all three
requirements and run on hundreds of thousands of nodes. The goal is to
transition and evolve this work into a set of standards that enable IP
connectivity to the next 10 billion nodes".

I am curious about the names of any working protocol or implemented
system that meets all three routing requirements on a 100'000 network
of low-power nodes.

Dominik

---

From: Philip Levis <[email-masked]>
Date: Tue, 13 Nov 2007 21:55:27 -0800

> still a challenge. Are there any studies to support your statement?

Two easy cases are Arch Rock's routing layer and Wireless HART.

> system that meets all three routing requirements on a 100'000 network

I apologize for being unclear. I didn't intend to claim that there  
are protocols running on 100,000 node networks (I don't know of any).  
Rather, there are hundreds of thousands of nodes running energy  
efficient, loss-adaptive, limited routing state protocols. I wanted  
to make it clear that there are real working protocols out there  
running on a lot of hardware: this isn't a problem of the future, it  
is a problem of the now.

Phil

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 14 Nov 2007 09:10:45 +0100

Can I check the presentation on RL2N at the Routing Area meeting IETF-69?
I cannot find it on IETF site or anywhere else. Maybe it was sent on RSN ML,
but not stored in archives.
Teco.

---

From: "DOHLER Mischa RD-TECH-GRE" <[email-masked]>
Date: Wed, 14 Nov 2007 23:27:14 +0100

Dear JP, dear all,

Thanks for your efforts in getting all this together. After some
FT/Orange internal discussions and having had you on the phone today, we
have decided to actively participate in RL2N. I will try hard to call in
tomorrow. 

To aid tomorrow's discussion, we have a few comments/questions, some of
which may have been addressed before. Our comments on the formulation of
the charter have been sent to you offline a few hours ago. Rather as an
input to tomorrow's discussion, some of our general technical comments
as well as comments on the excellent drafts can be found below.

Many thanks and with kind regards,
Mischa, Christian and Gabriel.

_______________________________________

Dr Mischa Dohler
France Telecom R&D
Senior Research Expert

Tel: +33 4 76 76 45 14
Fax: +33 4 76 76 44 50
Mob: +33 6 74 70 86 75

http://perso.rd.francetelecom.fr/dohler
_______________________________________

... visit http://www.pimrc2008.org/ ...
_______________________________________

General comments:

1) The current technical requirements and also the charter very much
focus on wireless solutions. Do you exclude wired solutions, i.e. mixed
networks?

2) IETF focuses on routing, but you will agree that multihop is
inherently a routing + MAC problem. We have seen the discussion on doing
routing at layer 2 (mesh under) or layer 3 (route over); however, we
believe that key is 'and' and not 'or'. Energy consumption of a routing
protocol will strongly depend on the chosen MAC and vice-versa, where
not all MACs go plug-'n-play with all routing protocols. How do you plan
to handle this problematic?

3) Albeit touched here and there in the published drafts, we would like
to see stronger statements concerning:
- the need of energy-optimised network ramp-up protocols (when all nodes
are being switched on; nodes are added; etc);
- the directed information flow towards gateways (WLAN, cellular);
- the availability of a heterogeneous set of nodes (battery, plugged
into mains, recharged regularly, recharged irregularly, etc).

4) As an integrated service provider, we would certainly like to see an
all-IP solution. However, despite the usual polemic of IP versus non-IP,
a key question for us is how the addresses are assigned and when. Does
the group also perceive this as an important issue and have solutions
already been hinted at?

5) We think that the three chosen categories makes sense: home
automation (high node type diversity), industrial control (low latency),
smart city (longivity). However, home automation solutions have
relatively low hop-counts; we might be wrong but we believe that routing
is not really an issue and that proposed solutions (e.g. ZigBee Pro)
should do for a commercially viable roll-out. Industrial control
roll-outs hamper today, mainly because of the latency problem; however,
e.g. the recently proposed IEEE 802.15.4e has the minimisation of
latency as a design goal. We agree, however, with the proposed drafts
that there is still a lot of scope in optimising the energy consumption
of the protocols.

In any case, we generally believe that innovative solutions are still
missing for the Smart City. We would like to take the lead on this draft
which we commenced writing and which we hope to be able to issue shortly
via JP for first comments.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Comments on "draft-brandt-rl2n-home-routing-reqs-01.txt":

1) Section "4.3. Support of Mobility": Is it typical to give such a
loose bound on the convergence time, eg "few hundreds of milli-seconds"?

2) Section "5.  Traffic pattern": It is stated that "a tree topology may
prove inefficient for nodes in a distributed system." How does this
relate to "draft-thubert-tree-discovery-06.txt"?

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Comments on "draft-culler-rl2n-routing-reqs-01.txt":

1) Section "3.  "Route over" versus "Mesh under": We would delete
reference to IEEE 802.16.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Comments on "draft-pister-rl2n-indus-routing-reqs-00.txt":

1) Section "2.  Introduction": Should cabeling costs be part of the
draft?

2) Section "2.1.  Applications and Traffic Patterns": What does
"multi-topology routing" exactly imply?

3) Section "5.  Device-Aware Routing Requirements": We would suggest to
mention larger lifetimes than 5 years, eg at least 10-15 years.

4) Section "10.  Security": In the case of an all-IP solution, we would
welcome that solutions MUST support (at least some form of) security.

---

From: Jaudelice Cavalcante de Oliveira <[email-masked]>
Date: Fri, 16 Nov 2007 14:29:20 -0500

Somehow my message was not posted, so I am resending it....

Cheers,

Jaudelice.
---

From: Jaudelice Cavalcante de Oliveira <[email-masked]>
Date: Wed, 14 Nov 2007 19:42:57 -0500
To: <[email-masked]>
Cc: JP Vasseur <[email-masked]>, Ian Chakeres  
<[email-masked]>
Subject: Re: ** ALL, Please read and comment ** Re: [RSN] BOF  
Schedule, proposed agenda and WG charter

I have been following the discussions on the list since its creation  
and have read
the excellent documents posted. I am planning to attend tomorrow's  
meeting and I also
attended the Routing area meeting in Chicago, where I saw strong  
support for this work.

I am excited to finally see this work taking place at the IETF. Long  
ago, I had mentioned
to several colleagues that the community needed a WG at the IETF,  
given the number
of proprietary solutions out there, and the need for good open  
protocols and, moreover,
IP based solutions.

I think the group has come a long way already, taking the right  
steps, (I like the
application-specific approach -- it makes a lot of sense to me,  
specially for sensor networks --
and the three selected deployment scenarios) and I look forward to a  
Working Group being
formed to work on the charter. While the recently proposed charter  
may not be the final one,
I noticed that a long time was allocated to discuss it during the Pre- 
WG meeting tomorrow.

Cheers,

Jaudelice C. de Oliveira
Assistant Professor
ECE Dept., Drexel University
http://www.ece.drexel.edu/faculty/deoliveira/

---

From: Jaudelice Cavalcante de Oliveira <[email-masked]>
Date: Wed, 14 Nov 2007 19:42:57 -0500

Cheers,

Jaudelice C. de Oliveira
Assistant Professor

---

From: "Anders Brandt" <[email-masked]>
Date: Thu, 22 Nov 2007 14:46:22 +0100

>5) We think that the three chosen categories makes sense: home
automation (high node type diversity), industrial control
>(low latency), >smart city (longivity). However, home automation
solutions have relatively low hop-counts; we might be
>wrong but we believe that routing is not really an issue and that
proposed solutions (e.g. ZigBee Pro) should do for a
>commercially viable roll-out. Industrial control roll-outs hamper
today, mainly because of the latency problem; however,
>e.g. the recently proposed IEEE 802.15.4e has the minimisation of
latency as a design goal. We agree, however, with the
>proposed drafts that there is still a lot of scope in optimising the
energy consumption of the protocols.

Our experience with Z-Wave home control over the last 5 years shows that
routing is certainly an issue.

Yes, distances are short, but antenna conditions are often problematic.

Plugin modules may lie on the floor next to a noisy switch-mode
converter or a Wi-Fi router
Built-in wall switches may have metal housing due to safety regulations.
The same applies to ceiling outlets.

All the abovementioned examples causes not only reduced reception
sensitivity but also direction-dependent reception conditions.
An antenna built into a metal box does not show reception properties
even close to omni-directional.

Reinforced concrete, refrigerator doors and other metal objects - and
people too - also may dampen/distort the signal

I would claim that it is a lot easier to do a good antenna design in
industrial devices as you have the room needed and can place a proper
wip antenna on the top of the device in a proper high location without
having to consider the WAF (Wife Acceptance Factor).

Increasing the tx power may not help a lot if the target is almost deaf
in the direction of the sender.

Thus, you should expect to see both 3 and 4 hops in the home control
domain. Extending that to building control, the end-to-end hop count may
grow significantly.
Obviously, you may decide to leave the node hopping to mesh-under
transport in the individual subnets.
ROLL routing may still benefit from data link information, such as the
number of layer-2 hops needed to get to the actual node / the worst case
absolute delay / etc. in case multiple gateways provide access to a
subnet.
(read: subnets may be running different data link technologies)

Cheers,
  Anders

---

From: "DOHLER Mischa RD-TECH-GRE" <[email-masked]>
Date: Thu, 22 Nov 2007 22:44:42 +0100

Dear Anders,

Thanks for your response. It makes, effectively, sense now to me. 

Kind regards, 
Mischa.

PS: I also like ROLL!  

Dr Mischa Dohler
France Telecom R&D
Senior Research Expert

Tel: +33 4 76 76 45 14
Fax: +33 4 76 76 44 50
Mob: +33 6 74 70 86 75

-----Message d'origine-----
De : Anders Brandt [mailto:[email-masked]] 
Envoyé : jeudi 22 novembre 2007 14:46
À : DOHLER Mischa RD-TECH-GRE; [email-masked]
Objet : RE: ** ALL, Please read and comment ** Re: [RSN] BOF Schedule,proposed agenda and WG charter

Our experience with Z-Wave home control over the last 5 years shows that routing is certainly an issue.

Plugin modules may lie on the floor next to a noisy switch-mode converter or a Wi-Fi router Built-in wall switches may have metal housing due to safety regulations.
The same applies to ceiling outlets.

All the abovementioned examples causes not only reduced reception sensitivity but also direction-dependent reception conditions.
An antenna built into a metal box does not show reception properties even close to omni-directional.

Reinforced concrete, refrigerator doors and other metal objects - and people too - also may dampen/distort the signal

I would claim that it is a lot easier to do a good antenna design in industrial devices as you have the room needed and can place a proper wip antenna on the top of the device in a proper high location without having to consider the WAF (Wife Acceptance Factor).

Increasing the tx power may not help a lot if the target is almost deaf in the direction of the sender.

Thus, you should expect to see both 3 and 4 hops in the home control domain. Extending that to building control, the end-to-end hop count may grow significantly.
Obviously, you may decide to leave the node hopping to mesh-under transport in the individual subnets.
ROLL routing may still benefit from data link information, such as the number of layer-2 hops needed to get to the actual node / the worst case absolute delay / etc. in case multiple gateways provide access to a subnet.
(read: subnets may be running different data link technologies)

Cheers,
  Anders