Betreff:
Re: WG: [Roll] RPL Next Steps
Von:
Tim Winter <wintert@acm.org>
Datum:
Tue, 8 Sep 2009 15:59:58 +0200
An:
Guido Moritz <guido.moritz@uni-rostock.de>

Re: WG: [Roll] RPL Next Steps

Hi Guido,

It is a charter item of the ROLL working group that the routing solution should
operate at layer 3- you may be interested to have a look at the charter here:
http://tools.ietf.org/wg/roll/charters   In this sense, the `route over'
approach is a fixed core principal.

ROLL/RPL thus does not presume the presence/absence of any underlying
mechanisms such as `L2 mesh'.  An architectural principle we have been
following is that, from the point of vew of routing at least, it should not
matter what L2 technology is being employed, i.e. that RPL should be L2 agnostic.

The ROLL solution is also chartered to give consideration to IPv6 multicast;
although this has not yet been thoroughly handled in the current proposal it
should be addressed soon.  I would expect to see some flexible multicast
support due to the fact that it is required by the defined ROLL application
scenarios (http://tools.ietf.org/wg/roll)

You may also be interested in an effort that has recently started to look at
recommendations for application protocols running over constrained
nodes/networks: 6lowapp
https://www.ietf.org/mailman/listinfo/6lowapp
http://tools.ietf.org/html/draft-bormann-6lowpan-6lowapp-problem-01

I do hope that this is useful in your considerations for DPWS / WS-Discovery
1.2, please let me know if I can provide any additional clarifications/assistance.

Regards,

-Tim


Guido Moritz wrote:
> Dear Mr. Winter,
>
> some time ago I wrote you the mail to be found below. Unfortunately I
> received now answer up to now. Did you receive my last mail?
>
> Regards,
> Guido Moritz
>
>> -----Ursprüngliche Nachricht-----
>> Von: Guido Moritz [mailto:guido.moritz@uni-rostock.de]
>> Gesendet: Dienstag, 25. August 2009 13:26
>> An: 'Tim Winter'
>> Betreff: AW: [Roll] RPL Next Steps
>>
>> Dear Mr. Winter,
>>
>> I found this mail in the ROLL mailing list. My University (of Rostock) is
>> member in the OASIS WS-DD Technical Committee (see http://www.oasis-
>> open.org/committees/tc_home.php?wg_abbrev=ws-dd), which is standardizing
> DPWS,
>> SOAP-over-UDP and WS-Discovery.
>> Our research group (see http://www.ws4d.org) already has spent high
> efforts in
>> the Devices Profile for Web Services (DPWS) and related issues. One of our
>> current main topics is the deployment of DPWS in wireless sensor networks
> and
>> thus on top of 6LoWPAN. To push the upcoming WS-Discovery 1.2 standard
> into
>> the right direction, we trying to investigate coming routing strategies of
> the
>> ROLL WG. WS-Discovery for finding devices in a network makes use of IP
>> multicast. IP multicast differs between link-local, site-local,... scopes.
> To
>> define an optimal scope for WS-Discovery multicast groups, we are highly
>> interested in the routing strategies planed by ROLL. Is the statement
> below
>> (routing is performed over IP) a proposal or is this a fixed core decision
> of
>> the ROLL? The WS-DD TC requires a clear definition for further work around
>> this.
>>
>> Thank you for your time in advance,
>>
>> Regards,
>> Guido Moritz
>>
>> -------------------------
>> Dipl. Ing. Guido Moritz
>> Universitaet Rostock, Fakultaet f. Informatik und Elektrotechnik
>> Institut f. Angewandte Mikroelektronik und Datentechnik
>> University of Rostock, Department of CS and EE
>> Institute of Applied Microelectronics and Computer Engineering
>> Richard-Wagner Str. 31, 18119 Rostock-Warnemuende
>> Phone:  +49 (0)381 498 - 7269
>> http://www.imd.uni-rostock.de
>> http://www.aal-rostock.de
>>
>> [...]
>>>
>>>         -is it the 6LoWPAN route over or mesh-under?
>>> DT: RPL intends to operate purely at L3, and it is the intention of RPL
> to
>>> be L2 agnostic, so it "routes over".  If it were over, e.g. switched
>>> ethernet or 802.11 mesh or 802.15.4 mesh underneath, it should work.  It
>>> should also work on, e.g., ethernet, 802.11, and 802.15.4 where no
>>> "meshing" is done at layer 2.
>>>
>> [...]
>
>