Subject: [Roll] Proposal for Source Routing Header Format and Source Routing Operations

From: "JeongGil Ko (John)" <[email-masked]>
Date: Wed, 7 Apr 2010 13:05:22 -0700

Hi!

Great to see all this discussions on downwards route establishment! To add one more to the conversations here is a proposal for source routing headers. In non-storing mode (where only the root has individual path information) the root will be attaching a source routing header to the data packet that a source node wants to send to a specific destination. We can always make the header super fancy but in my opinion I think we only need two fields in this header and here it is! Feel free to break the stuff and mangle with it so that it looks great in the specs later on. FYI, this is the format that I am using in my implementations so it does work :)

1. Source Routing Header Format

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   NEntry (8 bits)   |                                                                                  |
+-+-+-+-+-+-+-+-+                                                                                  +
|                       Source Route Entry (128*NEntry bits)                                  |
+                                                                                                              +
|                                                                                                               |

      Figure 1. Proposed Source Routing Header Format; each line is 32 bits:)

- NEntry: Indicates the number of 128 bit addresses that the source route entry field is carrying.

- Source Route Entry: List of 128 bit address that consist the route to the destination. Here, the address of the node that is one hop away from the *destination* comes first. 

2. Source Routing Packet Operations

When source routing is initiated at a storing node (e.g., root of the DODAG), the header is attached on the data packet for the entire route (i.e., from next hop node to the destination). This header is positioned in front of the user payload. When the next hop node receives a packet that is not destined to itself AND the network is NOT provisioned to be in 'storing mode' then it checks NEntry to find what the next hop is in the source route entry. Since the 'Source Route Entry' is ordered in 'farthest -> closest' (in terms of hops) order, a node can figure out what the next hop address is with only the NEntry value (since it already knows how big an ipv6 address is). After collecting the next hop node's address, the node erases this address element from the entry and decreases NEntry by one. This assures that we avoid the overhead of carrying the entire source route throughout the data path. 

The approach itself should be very simple and trivial for everyone to follow. So we can start from here and build on!

Thanks.

-John

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 8 Apr 2010 11:15:12 +0200

Hi John:

IPv6 already has a number of routing headers, in particular RH0, though
it is being deprecated for general use in the Internet.
And there are reasons why the fields in RH0/1 are there and we need to
make sure we lose none of that. In particular a RH is recoverable, and
it is easy to spot the consumed entries.

On top of this our new problems are:
- make sure the RH stays within the RPL network (since it is used
downwards that should be doable)
- control the size (that probably means compress)

Cheers,

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> JeongGil Ko (John)
> Sent: Wednesday, April 07, 2010 10:05 PM
> To: ROLL WG
> Subject: [Roll] Proposal for Source Routing Header Format and Source
> RoutingOperations
> 
> Hi!
> 
> Great to see all this discussions on downwards route establishment! To
add
> one more to the conversations here is a proposal for source routing
headers.
> In non-storing mode (where only the root has individual path
information)
> the root will be attaching a source routing header to the data packet
that a
> source node wants to send to a specific destination. We can always
make the
> header super fancy but in my opinion I think we only need two fields
in this
> header and here it is! Feel free to break the stuff and mangle with it
so that it
> looks great in the specs later on. FYI, this is the format that I am
using in my
> implementations so it does work :)
> 
> |   NEntry (8 bits)   |
|
> +-+-+-+-+-+-+-+-+
+
> +
+
> |
|
> - NEntry: Indicates the number of 128 bit addresses that the source
route
> entry field is carrying.
> 
> - Source Route Entry: List of 128 bit address that consist the route
to the
> destination. Here, the address of the node that is one hop away from
the
> *destination* comes first.
> 
> When source routing is initiated at a storing node (e.g., root of the
DODAG),
> the header is attached on the data packet for the entire route (i.e.,
from
> next hop node to the destination). This header is positioned in front
of the
> user payload. When the next hop node receives a packet that is not
destined
> to itself AND the network is NOT provisioned to be in 'storing mode'
then it
> checks NEntry to find what the next hop is in the source route entry.
Since
> the 'Source Route Entry' is ordered in 'farthest -> closest' (in terms
of hops)
> order, a node can figure out what the next hop address is with only
the
> NEntry value (since it already knows how big an ipv6 address is).
After
> collecting the next hop node's address, the node erases this address
> element from the entry and decreases NEntry by one. This assures that
we
> avoid the overhead of carrying the entire source route throughout the
data
> path.
> 
> The approach itself should be very simple and trivial for everyone to
follow.
> So we can start from here and build on!
> 
> Thanks.
> 
> -John
> 
> ------
> JeongGil Ko (John)
> Ph.D. Student
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Popa, Daniel" <[email-masked]>
Date: Thu, 8 Apr 2010 05:40:12 -0400

Hi Pascal, John,

Since source routing explicitly gives forwarding instruction to each
intermediate node, it can make sense to use only (MAC address based) L2
forwarding instead of (IPv6 address based) L3 forwarding. 

This brings two advantages: 
 - avoid processing each transit packets up to L3. 
 - use MAC addresses that - in ROLL environment - have inherently
shorter length than an IPv6 address. 

Cheers,
Daniel   

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Pascal Thubert (pthubert)
Sent: jeudi 8 avril 2010 11:15
To: JeongGil Ko (John); ROLL WG
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations

Hi John:

Cheers,

Pascal

Of
add
headers.
information)
that a
make the
in this
so that it
using in my
|
+
+
|
route
to the
the
DODAG),
from
of the
destined
then it
Since
of hops)
the
After
we
data
follow.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 8 Apr 2010 11:57:56 +0200

Hi Daniel:

Routers might have multiple interfaces of multiple MAC types. Internet 0
even has a MAC-less format.
So the result of you proposal, which looks like a great idea in a pure
802.15.4 world with short addresses, becomes a nightmare to define in a
fully generic fashion.

OTOH, a locally significant opaque tag in which the parent could hide a
short address of the child - if it cares to do it that way - looks like
a way more acceptable approach

So it seems to me that you can get what you want as long as we can make
the tag big enough for short addresses. When the tag is too small to
contain what the parent really needs, then the parent will have to store
a state with the full information in memory, and then place an index of
some sort in the tag.

What do you think?

Pascal

> From: Popa, Daniel [mailto:[email-masked]]
> Sent: Thursday, April 08, 2010 11:40 AM
> To: ROLL WG
> Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
> Subject: RE: [Roll] Proposal for Source Routing Header Format and
> SourceRoutingOperations
> 
> Hi Pascal, John,
> 
shorter
> length than an IPv6 address.
> 
> Cheers,
> Daniel
> 
> 
> 
Of
> IPv6 already has a number of routing headers, in particular RH0,
though it is
> being deprecated for general use in the Internet.
it is
> easy to spot the consumed entries.
> 
downwards
> that should be doable)
> >       Figure 1. Proposed Source Routing Header Format; each line is
32
> bits:)

---

From: "Popa, Daniel" <[email-masked]>
Date: Thu, 8 Apr 2010 06:46:56 -0400

Hi Pascal: 

Some further thoughts between you lines. 

Daniel 

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
Sent: jeudi 8 avril 2010 11:58
To: Popa, Daniel; ROLL WG
Cc: JeongGil Ko (John)
Subject: RE: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations

Hi Daniel:

--
DP: Indeed, I was thinking at 802.15.4 interfaces. The idea was that the
routing protocol might have several instances of source routing scheme,
for specific interfaces, and so it can use for 802.15.4 interface(s) the
short MAC addresses instead of the IPv6 addresses.
--

--
DP:   You read my mind! :)  A generic tagging mechanisms can efficiently
hide multiple addressing and forwarding schemes, from various layers.
The generic tag can then have different meanings for different
interfaces. What do you think ?
--

---
DP: It seems to me that there is always a trade-off between the depth of
the tree (i.e., number of intermediate hops between source and
destination) and the efficiency of source routing protocol, irrespective
of using tagging or IPv6 address. I would have a preference for defining
a maximum size of the tag big enough to accommodate short addresses (but
I think these will not be a problem if the maximum size of the tag is
chosen as a function of IPv6 address length).
---

shorter
Of
though it is
it is
downwards
32

---

From: Robert Cragie <[email-masked]>
Date: Thu, 08 Apr 2010 12:53:03 +0100

Hi Pascal,

Source routing should of course use the IPv6 addresses which means a lot 
of overhead for certain underlying link layers, e.g. 802.15.4. I think 
it is generally cleaner to do the compression at a layer which may 
require it only, e.g. define it in the 6lowpan HC. This is then free to 
some extent to specify how the compression is done. Although I doubt 
this would go down well in the 6lowpan WG...

The tag scheme would work but it specifically scopes the source routing 
to nodes which operate the scheme. This is probably acceptable 
practically but doesn't 'smell right' somehow.

With regard to the original proposal: it is probably necessary to carry 
the full source route all the way to at least the penultimate node and 
use an index to show the current position in the route for potential 
backtrace and error reporting back along the same route (assuming link 
symmetry). This is how RH0 works.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com <http://www.gridmerge.com/>

On 08/04/2010 10:57 AM, Pascal Thubert (pthubert) wrote:
>> intermediate node, it can make sense to use only (MAC address based)
>>      
> L2
>    
>>> Great to see all this discussions on downwards route establishment!
>>>        
> To
>    
>> add
>>      
>>> the root will be attaching a source routing header to the data
>>>        
> packet
>    
>> that a
>>      
>>> header and here it is! Feel free to break the stuff and mangle with
>>>        
> it
>    
>> so that it
>>      
>>> |                       Source Route Entry (128*NEntry bits)
>>>        
>> |
>>      
>>> +
>>>        
>> +
>>      
>>> |
>>>        
>> |
>>      
>>> When source routing is initiated at a storing node (e.g., root of
>>>        
> the
>    
>> DODAG),
>>      
>>> the header is attached on the data packet for the entire route
>>>        
> (i.e.,
>    
>> from
>>      
>>> next hop node to the destination). This header is positioned in
>>>        
> front
>    
>> of the
>>      
>>> checks NEntry to find what the next hop is in the source route
>>>        
> entry.
>    
>> Since
>>      
>>> the 'Source Route Entry' is ordered in 'farthest ->  closest' (in
>>>        
> terms
>    
>> of hops)
>>      
>>> element from the entry and decreases NEntry by one. This assures
>>>        
> that
>    
>> we
>>      
>>> avoid the overhead of carrying the entire source route throughout
>>>        
> the
>    
>> data
>>      
>>> path.
>>>
>>> The approach itself should be very simple and trivial for everyone
>>>        
> to
>    
>> follow.
>>

---

From: Daniel Gavelle <[email-masked]>
Date: Thu, 08 Apr 2010 14:11:30 +0100

Rob,

I agree that the source routing for the data frames should be done as 
part of the 6LowPAN HC.  This already has a stateful IPV6 address 
compression based on contexts.  It should be possible to compress the 
addresses down to two bytes per address if IPv6 addresses are derived 
from the 16 bit short address are being used in the LowPAN.

We don't want to hold up the current HC draft that is going through last 
call but the work could be done as a new RFC / amendment.  Source 
routing compression may need a fix for the problem of HC compression 
extending beyond the first fragment.

Doing the work in the 6LowPAN group means that the compression can 
easily be used for any source routing protocol, not just ROLL.  It could 
be done as a compression for the existing R0 routing header.  Maybe this 
thread needs moving to the 6LowPAN reflector.

Daniel.

Robert Cragie wrote:
> ------------------------------------------------------------------------
> 

-- 
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371  Registered In England
http://www.jennic.com
__________________________________________________

---

From: "Popa, Daniel" <[email-masked]>
Date: Thu, 8 Apr 2010 09:32:48 -0400

Hi Robert, Daniel, 

I believe that a tagging mechanism can efficiently accommodate our needs
by designing a generic tagging scheme with different scopes for source
routing (e.g., one of them can be source routing using 6lowPAN HC,
another using uncompressed L2 addressing, another can use uncompressed
L3 addressing, and so on ). This helps with link layers that do not
need/use 6lowPAN HC (because they can transport large MTU) but for which
using source address with IPv6 addressing might generate lot of
overhead.  

OTOH, we can have a generic tagging mechanism for routing with a scope
different from source routing. 

Concerning the error reporting along the route for the source routing
scheme where the next-hop addresses are specified: We do not need to
carry the full source route all the way to the penultimate node. 

We can do it easier irrespective of link symmetry/asymmetry:  Even if
each node among the path towards the destination removes its own address
from the packet header, the node where the link (towards next-hop) is
broken still has enough information to send back to the source (i.e.,
root ): The tuple (source_address, final_destination_address,
intermediate_hop_address). This information should be enough for the
source of that message to identify the "broken link".

What do you think ? 

Cheers, 

Daniel  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Robert Cragie
Sent: jeudi 8 avril 2010 13:53
To: [email-masked]
Subject: Re: [Roll] Proposal for Source Routing Header Formatand
SourceRoutingOperations

Hi Pascal,

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

Hi Daniel:

 
 
What do you think?
 
Pascal

	-----Original Message-----
	From: Popa, Daniel [mailto:[email-masked]]
	Sent: Thursday, April 08, 2010 11:40 AM
	To: ROLL WG
	Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
	Subject: RE: [Roll] Proposal for Source Routing Header Format
and
	SourceRoutingOperations
	 
	Hi Pascal, John,
	 
	Since source routing explicitly gives forwarding instruction to
each
	intermediate node, it can make sense to use only (MAC address
based)

L2

	This brings two advantages:
	 - avoid processing each transit packets up to L3.
	 - use MAC addresses that - in ROLL environment - have
inherently

shorter

	Cheers,
	Daniel

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On
Behalf

Of

	Pascal Thubert (pthubert)
	Sent: jeudi 8 avril 2010 11:15
	To: JeongGil Ko (John); ROLL WG
	Subject: Re: [Roll] Proposal for Source Routing Header Format
and
	SourceRoutingOperations
	 
	Hi John:

though it is

	being deprecated for general use in the Internet.
	And there are reasons why the fields in RH0/1 are there and we
need to
	make sure we lose none of that. In particular a RH is
recoverable, and

it is

	On top of this our new problems are:
	- make sure the RH stays within the RPL network (since it is
used

downwards

	that should be doable)
	 
	Cheers,
	 
	Pascal

		-----Original Message-----
		From: [email-masked]
[mailto:[email-masked]] On Behalf

	Of

		JeongGil Ko (John)
		Sent: Wednesday, April 07, 2010 10:05 PM
		To: ROLL WG
		Subject: [Roll] Proposal for Source Routing Header
Format and Source
		RoutingOperations
		 
		Hi!
		 
		Great to see all this discussions on downwards route
establishment!

To

	add

		one more to the conversations here is a proposal for
source routing

	headers.

		In non-storing mode (where only the root has individual
path

	information)

		the root will be attaching a source routing header to
the data

packet

	that a

		source node wants to send to a specific destination. We
can always

	make the

		header super fancy but in my opinion I think we only
need two fields

	in this

		header and here it is! Feel free to break the stuff and
mangle with

it

	so that it

		looks great in the specs later on. FYI, this is the
format that I am

	using in my

	|

		+-+-+-+-+-+-+-+-+

	+

		|                       Source Route Entry (128*NEntry
bits)

	|

		+

	+

		|

	|

		      Figure 1. Proposed Source Routing Header Format;
each line is

32

	bits:)

		- NEntry: Indicates the number of 128 bit addresses that
the source

	route

		entry field is carrying.
		 
		- Source Route Entry: List of 128 bit address that
consist the route

	to the

		destination. Here, the address of the node that is one
hop away from

	the

		 
		When source routing is initiated at a storing node
(e.g., root of

the

	DODAG),

		the header is attached on the data packet for the entire
route

(i.e.,

	from

		next hop node to the destination). This header is
positioned in

front

	of the

		user payload. When the next hop node receives a packet
that is not

	destined

		to itself AND the network is NOT provisioned to be in
'storing mode'

	then it

		checks NEntry to find what the next hop is in the source
route

entry.

	Since

		the 'Source Route Entry' is ordered in 'farthest ->
closest' (in

terms

	of hops)

		order, a node can figure out what the next hop address
is with only

	the

		NEntry value (since it already knows how big an ipv6
address is).

	After

		collecting the next hop node's address, the node erases
this address
		element from the entry and decreases NEntry by one. This
assures

that

	we

		avoid the overhead of carrying the entire source route
throughout

the

	data

		path.
		 
		The approach itself should be very simple and trivial
for everyone

to

	follow.

		Thanks.
		 
		-John
		 
		------
		JeongGil Ko (John)
		Ph.D. Student

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 8 Apr 2010 06:35:19 -0700

I can't see why 6LowPAN (and specifically the HC draft) would concern itself
with source routing.

Surely source routing is a concern of ROLL (and not 6LowPAN).

I don't see how ROLL completes its charter or addresses its requirements
without adding source routing.

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Daniel Gavelle
Sent: Thursday, April 08, 2010 6:12 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations

Rob,

Daniel.

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 8 Apr 2010 06:40:22 -0700

Hi Daniel,

I think the scope of ROLL covers multiple MAC/PHYs.  I don't see how the
proposal below works with multiple MAC/PHYs.

Also, what forwarding are you talking about?  In the MAC/PHYs that I am
familiar with, forwarding is done by a higher layer above the MAC.  

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Popa, Daniel
Sent: Thursday, April 08, 2010 2:40 AM
To: ROLL WG
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations

Hi Pascal, John,

Cheers,
Daniel   

-----Original Message-----

Hi John:

Cheers,

Pascal

Of
add
headers.
information)
that a
make the
in this
so that it
using in my
|
+
|
+
|
route
to the
the
DODAG),
from
of the
destined
then it
Since
of hops)
the
After
we
data
follow.

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 8 Apr 2010 06:59:43 -0700

I cannot imagine the proposal below working in a practical network
deployment (different scopes for source routing).  

I think we should address just one scope, at L3, and get that to work.

Don

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Popa, Daniel
Sent: Thursday, April 08, 2010 6:33 AM
To: [email-masked]; [email-masked]
Subject: Re: [Roll] Proposal for Source Routing Header Formatand
SourceRoutingOperations

Hi Robert, Daniel, 

I believe that a tagging mechanism can efficiently accommodate our needs by
designing a generic tagging scheme with different scopes for source routing
(e.g., one of them can be source routing using 6lowPAN HC, another using
uncompressed L2 addressing, another can use uncompressed L3 addressing, and
so on ). This helps with link layers that do not need/use 6lowPAN HC
(because they can transport large MTU) but for which using source address
with IPv6 addressing might generate lot of overhead.  

Concerning the error reporting along the route for the source routing scheme
where the next-hop addresses are specified: We do not need to carry the full
source route all the way to the penultimate node. 

We can do it easier irrespective of link symmetry/asymmetry:  Even if each
node among the path towards the destination removes its own address from the
packet header, the node where the link (towards next-hop) is broken still
has enough information to send back to the source (i.e., root ): The tuple
(source_address, final_destination_address, intermediate_hop_address). This
information should be enough for the source of that message to identify the
"broken link".

What do you think ? 

Cheers, 

Daniel  

Hi Pascal,

Source routing should of course use the IPv6 addresses which means a lot of
overhead for certain underlying link layers, e.g. 802.15.4. I think it is
generally cleaner to do the compression at a layer which may require it
only, e.g. define it in the 6lowpan HC. This is then free to some extent to
specify how the compression is done. Although I doubt this would go down
well in the 6lowpan WG...

The tag scheme would work but it specifically scopes the source routing to
nodes which operate the scheme. This is probably acceptable practically but
doesn't 'smell right' somehow.

With regard to the original proposal: it is probably necessary to carry the
full source route all the way to at least the penultimate node and use an
index to show the current position in the route for potential backtrace and
error reporting back along the same route (assuming link symmetry). This is
how RH0 works.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

Hi Daniel:

 
 
What do you think?
 
Pascal

-----Original Message-----
From: Popa, Daniel [mailto:[email-masked]]
Sent: Thursday, April 08, 2010 11:40 AM
To: ROLL WG
Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
Subject: RE: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations
 
Hi Pascal, John,

L2

shorter

Cheers,
Daniel

-----Original Message-----

Of

Hi John:

though it is

it is

downwards

that should be doable)
 
Cheers,
 
Pascal

-----Original Message-----

Of

JeongGil Ko (John)
 
Hi!

To

add

headers.

information)

packet

that a

make the

in this

it

so that it

using in my

 

|

+-+-+-+-+-+-+-+-+

+

|

+

+

|

|

32

bits:)

route

entry field is carrying.

to the

the

 

the

DODAG),

(i.e.,

from

front

of the

destined

then it

entry.

Since

terms

of hops)

the

After

that

we

the

data

path.

to

follow.

Thanks.
 
-John
 
------
JeongGil Ko (John)
Ph.D. Student

---

From: Daniel Gavelle <[email-masked]>
Date: Thu, 08 Apr 2010 15:25:07 +0100

There is already support for source routing in IPv6, using the routing 
R0 extension header. Roll can use this in the same way as any other IPv6 
routing algorithm.

If MAC/PHYs can't use this because they haven't got the spare bandwidth 
to carry the full 128 bit address in line, they need to use compression. 
If compression is needed, it would also be needed for the source and 
destination addresses as well as the intermediate hops.  6LowPAN header 
compression can be used by any MAC/PHY, even if fragmentation is not 
required.

The R0 routing extension header is stable and has some nice features. 
For example, the addresses swap places within the header and so the IPv6 
check sum does not need to be calculated or the IPv6 packet re-written 
beyond the extension header.  I don't think we need to create a new IPv6 
source routing extension header just for Roll.

Daniel.

---

From: Robert Cragie <[email-masked]>
Date: Thu, 08 Apr 2010 15:51:40 +0100

Hi Don,

It's not so much that 6lowpan is concerning itself with source routing, 
it is concerning itself with efficient header compression, which would 
include IPv6 extension headers such as RH0 
<http://tools.ietf.org/html/rfc2460#page-12>. Whatever ends up getting 
used for source routing needs to be some sort of IPv6 extension header. 
Source routing for IPv6 would naturally contain IPv6 addresses. The 
question is whether we want to invent some new extension header 
specifically for ROLL which uses something other (i.e. smaller) than 
IPv6 addresses, e.g. the tag scheme mentioned.

I agree, ROLL must accommodate source routing one way or another.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

On 08/04/2010 2:35 PM, Don Sturek wrote:
>> Robert Cragie (Pacific Gas&  Electric)
>>
>> Gridmerge Ltd.
>> 89 Greenfield Crescent,
>> Wakefield, WF4 4WA, UK
>> +44 (0) 1924 910888
>> http://www.gridmerge.com<http://www.gridmerge.com/>
>>
>>

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 8 Apr 2010 07:57:57 -0700

To make the source route header compact, I favor the tag/label  
approach over some other compaction mechanism that operates directly  
on a list of IPv6 addresses.  Tags/labels can be made general enough  
such that they can be derived in different ways.  Because the tags/ 
labels have scope local to each node, the mechanism is pretty general  
already.  For those that are already managing unique 802.15.4 short  
addresses across a network, I can see that it is attractive to utilize  
the short address directly and reduce state on devices.  In other  
cases, it may be best for the node to dynamically assign tags/labels  
for its neighbors.

Either way, while the tag/label mechanism is simple, it is far more  
flexible than an approach to compacting a list of IPv6 addresses.  And  
note that the idea of using tags/labels is nothing new.  Of course we  
will adapt the basic mechanism a bit (label distribution, headers  
formats, etc), but the core ideas have been deployed in traditional IP  
networks for quite some time.

I reiterated a lot of what was already stated before by others, but  
that is what I think.

--
Jonathan Hui

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 8 Apr 2010 07:59:24 -0700

I think the issue is this:

1)       ROLL cannot meet its charter without source routing

2)       Claiming the feature is now to be addressed in 6LowPAN seems a bit
wrong.  ROLL has as its scope MAC/PHYs other than IEEE 802.15.4.  How are
those addressed?

Don

From: Robert Cragie [mailto:[email-masked]] 
Sent: Thursday, April 08, 2010 7:52 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations

Hi Don,

It's not so much that 6lowpan is concerning itself with source routing, it
is concerning itself with efficient header compression, which would include
IPv6 extension headers such as RH0
<http://tools.ietf.org/html/rfc2460#page-12> . Whatever ends up getting used
for source routing needs to be some sort of IPv6 extension header. Source
routing for IPv6 would naturally contain IPv6 addresses. The question is
whether we want to invent some new extension header specifically for ROLL
which uses something other (i.e. smaller) than IPv6 addresses, e.g. the tag
scheme mentioned.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

 

Don

-----Original Message-----
 
Rob,

 
 
Daniel.

Robert Cragie wrote:

Hi Pascal,

 
 
Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com  <http://www.gridmerge.com/>
<http://www.gridmerge.com/>

Hi Daniel:

 
 
What do you think?
 
Pascal

-----Original Message-----
From: Popa, Daniel [mailto:[email-masked]]
Sent: Thursday, April 08, 2010 11:40 AM
To: ROLL WG
Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
Subject: RE: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations
 
Hi Pascal, John,

L2

shorter

Cheers,
Daniel

-----Original Message-----

Of

Hi John:

though it is

it is

downwards

that should be doable)
 
Cheers,
 
Pascal

-----Original Message-----

Of

JeongGil Ko (John)
 
Hi!

To

add

headers.

information)

packet

that a

make the

in this

it

so that it

using in my

 

|

+-+-+-+-+-+-+-+-+

+

|

+

+

|

|

32

bits:)

route

entry field is carrying.

to the

the

 

the

DODAG),

(i.e.,

from

front

of the

destined

then it

entry.

Since

terms

of hops)

the

After

that

we

the

data

path.

to

follow.

Thanks.
 
-John
 
------
JeongGil Ko (John)
Ph.D. Student

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 8 Apr 2010 08:04:42 -0700

I would prefer the tag/label approach defined in ROLL.  This can be
addressed in ROLL as a solution suitable over multiple MAC/PHYs.

I do not support the notion that each MAC/PHY will somehow create their own
scheme for source route forwarding.  I cannot see how that would scale or
work.

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Hui
Sent: Thursday, April 08, 2010 7:58 AM
To: Pascal Thubert (pthubert)
Cc: ROLL WG; Popa, Daniel
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations

--
Jonathan Hui

---

From: "Popa, Daniel" <[email-masked]>
Date: Thu, 8 Apr 2010 11:38:01 -0400

I reiterate my preference for a generic tagging mechanism with the
capability of using "short addressing" for forwarding. For nodes belong
to the same subnet (i.e., same Network ID) we may want to allow the use
of the "Host ID" information from the IPv6 address - i.e., MAC/Link
Layer Address - (w/r/t IPv6 stateless address auto-configuration) to
create short address for forwarding rather than using the full IPv6
address. By doing so, the overhead reduction for source routing scheme
with explicit route specification can be significant.  

Thanks. 

Cheers, 
Daniel 

-----Original Message-----
From: Jonathan Hui [mailto:[email-masked]] 
Sent: jeudi 8 avril 2010 16:58
To: Pascal Thubert (pthubert)
Cc: Popa, Daniel; ROLL WG
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations

--
Jonathan Hui

---

From: Robert Cragie <[email-masked]>
Date: Thu, 08 Apr 2010 16:42:22 +0100

Hi Don,

I am not suggesting source routing is done in 6lowpan at all. I am 
suggesting source routing is done using standard IPv6 extension headers. 
These would naturally include IPv6 addresses. It is precisely this point 
which makes it not only MAC/PHY agnostic but also routing scheme 
agnostic. Using some sort of tag scheme would potentially make it 
MAC/PHY agnostic but I can't see how it would make it routing scheme 
agnostic.

What I am then suggesting is that these standard IPv6 extension headers 
can be compressed using the 6lowpan adaptation layer just as it 
compresses the rest of the IPv6 header. The fact that it contains source 
routing data is immaterial to 6lowpan; it is just a load of IPv6 
addresses it can make smaller.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

On 08/04/2010 3:59 PM, Don Sturek wrote:
> wrong.  ROLL has as its scope MAC/PHYs other than IEEE 802.15.4.  How 
> are those addressed?
>
> Don
>
> *From:* Robert Cragie [mailto:[email-masked]]
> *Sent:* Thursday, April 08, 2010 7:52 AM
> *To:* [email-masked]
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [Roll] Proposal for Source Routing Header Format and 
> SourceRoutingOperations
>
> Hi Don,
>
> It's not so much that 6lowpan is concerning itself with source 
> routing, it is concerning itself with efficient header compression, 
> which would include IPv6 extension headers such as RH0 
> used for source routing needs to be some sort of IPv6 extension 
> header. Source routing for IPv6 would naturally contain IPv6 
> addresses. The question is whether we want to invent some new 
> extension header specifically for ROLL which uses something other 
> (i.e. smaller) than IPv6 addresses, e.g. the tag scheme mentioned.
>
> From:[email-masked]  <mailto:[email-masked]>  [mailto:[email-masked]] On Behalf Of
> Daniel Gavelle
> To:[email-masked]  <mailto:[email-masked]>
> Cc:[email-masked]  <mailto:[email-masked]>
>             From:[email-masked]  <mailto:[email-masked]>  [mailto:[email-masked]] On Behalf
>
>                  
>
>                      
>
>         Of
>
>            
>
>                
>
>                 From:[email-masked]  <mailto:[email-masked]>  [mailto:[email-masked]] On Behalf
>
>                        
>
>                            
>
>             Of
>
>                  
>
>                      
>
>                 JeongGil Ko (John)
>
>                 http://www.cs.jhu.edu/~jgko  <http://www.cs.jhu.edu/%7Ejgko>
>
>                   
>
>                 [email-masked]  <mailto:[email-masked]>
>
>             [email-masked]  <mailto:[email-masked]>
>
>         [email-masked]  <mailto:[email-masked]>
>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: Philip Levis <[email-masked]>
Date: Thu, 8 Apr 2010 08:35:36 -0700

> without adding source routing.

The basic guideline is that ROLL (or WGs in general) shouldn't replicate functionality or mechanisms that already exist, and that given WGs operate within a particular layer of the protocol stack.

In this particular case, the reason why 6lowpan was brought up is the RH0 header. In terms of charter, it's not ROLL's job to specify a way to compress the RH0 header. From ROLL's perspective, there are IPv6 addresses and nothing less. 6lowpan, however, can specify ways in which IPv6 headers are compressed. 

Does that make sense?

Phil

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 8 Apr 2010 09:39:30 -0700

Hi Phil,

It does make sense unless we see that ROLL creates different dependencies
with different MAC/PHYs.  

If we don't expect there to be dependencies on lower layer support for each
MAC/PHY then creating a dependency on RH0 support in 6LowPAN makes sense.
If instead each MAC/PHY will require similar changes then I still prefer to
use a MAC/PHY independent solution (like tags).

Don

-----Original Message-----
From: Philip Levis [mailto:[email-masked]] 
Sent: Thursday, April 08, 2010 8:36 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations

> without adding source routing.

The basic guideline is that ROLL (or WGs in general) shouldn't replicate
functionality or mechanisms that already exist, and that given WGs operate
within a particular layer of the protocol stack.

In this particular case, the reason why 6lowpan was brought up is the RH0
header. In terms of charter, it's not ROLL's job to specify a way to
compress the RH0 header. From ROLL's perspective, there are IPv6 addresses
and nothing less. 6lowpan, however, can specify ways in which IPv6 headers
are compressed. 

Does that make sense?

Phil=

---

From: "JeongGil Ko (John)" <[email-masked]>
Date: Thu, 8 Apr 2010 09:43:45 -0700

Hi!

We can't always assume that RPL will be running along with 6LoWPAN in all cases so we should be careful about this. Even the specs in some places say that 'if the implementation is using address compression like 6LoWPAN then it can chose to do <whatever>'. So it's not a must :) It will, however, be a nice optimization for those networks which do use 6LoWPAN with RPL. Another positive aspect is that if we reduce the size of the neighbor status as well. So yes it is a nice optimization approach that is implementation specific. 

I am happy that the discussions got going and I am not trying to argue that my simple header is the answer. With that said, I like Jonathan's approach of using tags/labels as well which can significantly decrease the overhead in a more 'general' way. 

Thanks.

-John

On Apr 8, 2010, at 9:01 AM, Popa, Daniel wrote:

> Hi John, 
> 
> 
> I like the principles of your proposal. I believe is something that
> should be adopted for source routing in ROLL. 
> 
> I was thinking at the following scenario: When nodes belong to the same
> subnet it can be interesting to extend your proposal with the capability
> of using some short addresses for forwarding (i.e., the MAC/Link Layer
> address from the "Host ID" field of an IPv6 address - w/r/t IPv6
> stateless address auto-configuration) rather than the full IPv6
> addresses.   
> 
> What do you think? 
> 
> Thanks. 
> Daniel 
> 
> Sent: mercredi 7 avril 2010 22:05
> To: ROLL WG
> add one more to the conversations here is a proposal for source routing
> headers. In non-storing mode (where only the root has individual path
> information) the root will be attaching a source routing header to the
> data packet that a source node wants to send to a specific destination.
> We can always make the header super fancy but in my opinion I think we
> only need two fields in this header and here it is! Feel free to break
> the stuff and mangle with it so that it looks great in the specs later
> on. FYI, this is the format that I am using in my implementations so it
> does work :)
> 
> route entry field is carrying.
> 
> - Source Route Entry: List of 128 bit address that consist the route to
> the destination. Here, the address of the node that is one hop away from
> the *destination* comes first. 
> 
> DODAG), the header is attached on the data packet for the entire route
> (i.e., from next hop node to the destination). This header is positioned
> in front of the user payload. When the next hop node receives a packet
> that is not destined to itself AND the network is NOT provisioned to be
> in 'storing mode' then it checks NEntry to find what the next hop is in
> the source route entry. Since the 'Source Route Entry' is ordered in
> 'farthest -> closest' (in terms of hops) order, a node can figure out
> what the next hop address is with only the NEntry value (since it
> already knows how big an ipv6 address is). After collecting the next hop
> node's address, the node erases this address element from the entry and
> decreases NEntry by one. This assures that we avoid the overhead of
> carrying the entire source route throughout the data path. 
> 
> follow. So we can start from here and build on!
> 
> Thanks.
> 
> -John
> 
> ------
> JeongGil Ko (John)
> Ph.D. Student

------
JeongGil Ko (John)
Ph.D. Student

---

From: "Popa, Daniel" <[email-masked]>
Date: Thu, 8 Apr 2010 12:59:38 -0400

We may want to consider a tagging approach with the following (non
exhaustive) contexts:
 
  - When RPL will be running along with 6lowPAN the tag/label will/can
be generated by the 6lowPAN HC.
  - when RPL will be running alone the tag/label will/can be generated
by the mechanism "To Be Defined".
  - When RPL will be running along with some adaptation layer (other
than 6lowPAN) the tag/label will/can be generated by the adaptation
layer.

So the system designers can chose whatever context fits their
requirements. 

Thanks.
Daniel 

-----Original Message-----
From: JeongGil (John) Ko [mailto:[email-masked]] On Behalf Of
JeongGil Ko (John)
Sent: jeudi 8 avril 2010 18:44
To: Popa, Daniel
Cc: ROLL WG
Subject: Re: [Roll] Proposal for Source Routing Header Format and Source
RoutingOperations

Hi!

We can't always assume that RPL will be running along with 6LoWPAN in
all cases so we should be careful about this. Even the specs in some
places say that 'if the implementation is using address compression like
6LoWPAN then it can chose to do <whatever>'. So it's not a must :) It
will, however, be a nice optimization for those networks which do use
6LoWPAN with RPL. Another positive aspect is that if we reduce the size
of the neighbor status as well. So yes it is a nice optimization
approach that is implementation specific. 

I am happy that the discussions got going and I am not trying to argue
that my simple header is the answer. With that said, I like Jonathan's
approach of using tags/labels as well which can significantly decrease
the overhead in a more 'general' way. 

Thanks.

-John

Of
to

------
JeongGil Ko (John)
Ph.D. Student

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 8 Apr 2010 14:45:18 +0200

On Apr 8, 2010, at 13:53, Robert Cragie wrote:

> Although I doubt this would go down well in the 6lowpan WG...

I can't speak for the 6LoWPAN WG, as I don't think we have discussed this in sufficient detail.
So far, we seem to have assumed that protocols designed for constrained networks would be frugal enough with their space requirements that we didn't have anything additional to do.  However, where IPv6 addresses are needed, this is hard to optimize at the higher level protocol alone.

I personally could imagine that 6LoWPAN could define a compression scheme specifically for protocols that contain lots of IPv6 addresses.  In a 6LoWPAN, it is quite likely that many of these would contain prefixes that are in the context, so the 16-byte addresses could be compressed down to 8.5 or even 2.5 bytes.
A decoder would not need to know anything about the formats where the addresses occur if the positions are indicated explicitly (which would cost maybe another byte per address plus a byte per frame); this makes sure we don't have to change the adaptation layer compression each time ROLL comes up with a new field.
6LoWPAN as it is has a limitation that would limit this scheme to compression within a fragment (HC-07 can compress only in the first fragment, but the scheme I'm talking about now could easily be extended to other fragments -- just not between fragments, but that should never be necessary with proper alignment).
This scheme could also get rid of MBZ fields.  We could even generalize it to an LZ77 (much simpler than it sounds), if we expect repetitions. 
The possibilities for adding more complexity are endless.

Yes, doing compression at the adaptation layer has the advantage that it is only done where it is needed.
The disadvantage may be that this introduces some complexity at a place where that may be expensive.

Gruesse, Carsten

---

From: Kris Pister <[email-masked]>
Date: Thu, 08 Apr 2010 11:45:41 -0700

+1

Jonathan Hui wrote:
> such that they can be derived in different ways.  Because the 
> tags/labels have scope local to each node, the mechanism is pretty 
> general already.  For those that are already managing unique 802.15.4 
> short addresses across a network, I can see that it is attractive to 
> utilize the short address directly and reduce state on devices.  In 
> other cases, it may be best for the node to dynamically assign 
> tags/labels for its neighbors.
>

---

From: Robert Cragie <[email-masked]>
Date: Thu, 08 Apr 2010 22:06:06 +0100

Hi Jonathan,

A couple of questions:

    * I presume the source route header using these tags/labels is an
      IPv6 extension header. What value for extension header type would
      this be? Would we need to specify a LOWPAN_NHC value for this so
      we can still use LOWPAN_NCH for UDP frames?
    * Can you point to where the 'core ideas have been deployed in
      traditional IP networks for quite some time'?

Thanks

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 8 Apr 2010 14:17:50 -0700

Hi Robert,

On Apr 8, 2010, at 2:06 PM, Robert Cragie wrote:

> A couple of questions:
> 	• I presume the source route header using these tags/labels is an  
> this be? Would we need to specify a LOWPAN_NHC value for this so we  
> can still use LOWPAN_NCH for UDP frames?

We already have a draft requesting a new IPv6 Hop-by-Hop Option and  
presented it at 6man in Anaheim.  The option is designed to carry RPL- 
specific information.  6lowpan-hc already has a LOWPAN_NHC value for  
the IPv6 Hop-by-Hop Option header.

> 	• Can you point to where the 'core ideas have been deployed in  

MPLS.  Again, I think the mechanisms will need to be adapted, but the  
core ideas are not new.

--
Jonathan Hui

> http://www.gridmerge.com
>> approach over some other compaction mechanism that operates  
>> directly on a list of IPv6 addresses.  Tags/labels can be made  
>> general enough such that they can be derived in different ways.   
>> Because the tags/labels have scope local to each node, the  
>> mechanism is pretty general already.  For those that are already  
>> managing unique 802.15.4 short addresses across a network, I can  
>> see that it is attractive to utilize the short address directly and  
>> reduce state on devices.  In other cases, it may be best for the  
>> node to dynamically assign tags/labels for its neighbors.
>>
>> flexible than an approach to compacting a list of IPv6 addresses.   
>> And note that the idea of using tags/labels is nothing new.  Of  
>> course we will adapt the basic mechanism a bit (label distribution,  
>> headers formats, etc), but the core ideas have been deployed in  
>> traditional IP networks for quite some time.
>>

---

From: Robert Cragie <[email-masked]>
Date: Thu, 08 Apr 2010 22:34:19 +0100

OK, sounds good. End of topic as far as I am concerned. +1

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

On 08/04/2010 10:17 PM, Jonathan Hui wrote:
> presented it at 6man in Anaheim.  The option is designed to carry 
> RPL-specific information.  6lowpan-hc already has a LOWPAN_NHC value 
> for the IPv6 Hop-by-Hop Option header.
>
>>> general already.  For those that are already managing unique 
>>> 802.15.4 short addresses across a network, I can see that it is 
>>> attractive to utilize the short address directly and reduce state on 
>>> devices.  In other cases, it may be best for the node to dynamically 
>>> assign tags/labels for its neighbors.
>>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 9 Apr 2010 10:35:36 +0200

I read this as a consensus to use tags J If anyone disagree please speak
up now!

There have been plenty iterations/versions of tagging since Frame Relay
(pure switching), IBM's HPR (pure source route), Cisco's tag switching
and MPLS. More often than not, a combination of the 2 models is used so
that tags can be both swapped and stacked. 

-          In pure switching, there's only one tag in the packet. A tag
can be locally significant, in which case it has to be swapped as the
packet progresses. For RPL, it means that a node uses as many tags as it
has children that use it has DAO targets in its subdag.

-          In the pure source route model, tags are stacked in an
ordered list that forms a strict routing header. A tag can be locally
significant to the interpreter and is consumed (marked or removed) as
the packet progresses. For RPL, it means that a node uses as many tags
as it has children that use this node as DAO parent. 

It also appears that the 2 tagging models map quite well with the DAO
models we have in RPL since the split that we decided with issue #26.
The fact that the combination of the 2 models is possible in the real
world today gives us a hint that we are not closing the door to the
mixed model in the future.

The next step I wish to agree upon:

-          Use locally significant tags which implies tag assignment by
the node that uses it later and tag swapping for the stateful case.

-          Tag distribution in DAO (there are options there that we need
to dig further)

-          Tag content and size (people have asked for at least 2 octets
to fit 15.4 short addresses, do we need some control field as well?)

-          RH format (inherit RH0 fields with labels instead of
addresses? What about the tag swapping  case, RH as well?)

Advice?

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Robert Cragie
Sent: Thursday, April 08, 2010 11:34 PM
To: Jonathan Hui
Cc: [email-masked]
Subject: Re: [Roll] Proposal for Source Routing Header Formatand
SourceRoutingOperations

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

Hi Robert, 

A couple of questions: 
    * I presume the source route header using these tags/labels is an
IPv6 extension header. What value for extension header type would this
be? Would we need to specify a LOWPAN_NHC value for this so we can still
use LOWPAN_NCH for UDP frames? 

We already have a draft requesting a new IPv6 Hop-by-Hop Option and
presented it at 6man in Anaheim.  The option is designed to carry
RPL-specific information.  6lowpan-hc already has a LOWPAN_NHC value for
the IPv6 Hop-by-Hop Option header. 

-- 
Jonathan Hui 

Thanks 

Robert 

Gridmerge Ltd. 
89 Greenfield Crescent, 
Wakefield, WF4 4WA, UK 
+44 (0) 1924 910888 
http://www.gridmerge.com 

To make the source route header compact, I favor the tag/label approach
over some other compaction mechanism that operates directly on a list of
IPv6 addresses.  Tags/labels can be made general enough such that they
can be derived in different ways.  Because the tags/labels have scope
local to each node, the mechanism is pretty general already.  For those
that are already managing unique 802.15.4 short addresses across a
network, I can see that it is attractive to utilize the short address
directly and reduce state on devices.  In other cases, it may be best
for the node to dynamically assign tags/labels for its neighbors. 

I reiterated a lot of what was already stated before by others, but that
is what I think. 

-- 
Jonathan Hui 

Hi Daniel: 

What do you think? 

Pascal 

-----Original Message----- 
From: Popa, Daniel [mailto:[email-masked]] 
Sent: Thursday, April 08, 2010 11:40 AM 
To: ROLL WG 
Cc: Pascal Thubert (pthubert); JeongGil Ko (John) 
Subject: RE: [Roll] Proposal for Source Routing Header Format and 
SourceRoutingOperations 

Hi Pascal, John, 

L2 

shorter 

Cheers, 
Daniel 

-----Original Message----- 

Of 

Hi John: 

though it is 

it is 

downwards 

that should be doable) 

Cheers, 

Pascal 

-----Original Message----- 

Of 

JeongGil Ko (John) 

Hi! 

To 

add 

headers. 

information) 

packet 

that a 

make the 

in this 

it 

so that it 

using in my 

| 

+-+-+-+-+-+-+-+-+ 

+ 

| 

+ 

+ 

| 

| 

32 

bits:) 

route 

entry field is carrying. 

to the 

the 

the 

DODAG), 

(i.e., 

from 

front 

of the 

destined 

then it 

entry. 

Since 

terms 

of hops) 

the 

After 

that 

we 

the 

data 

path. 

to 

follow. 

Thanks. 

-John 

------ 
JeongGil Ko (John) 
Ph.D. Student

---

From: "Anders Brandt" <[email-masked]>
Date: Fri, 9 Apr 2010 10:42:38 +0200

Admitted, I have been absent from this thread; trying to catch up on
others...
 
> I read this as a consensus to use tags J If anyone disagree please
speak up now!

I have to comment respectfully but loudly that this may at best some
sort of rough concensus..
 
In a non-storing mode, I see no way of storing and/or swapping
labels/tags in each node.
For this kind of nodes we need a complete routing stack in the frame. As
mentioned earlier, I am perfectly
fine with limitations such as max n entries; Compression of addresses to
16 bits and a common subnet.
 
Just my $0.05

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pascal Thubert (pthubert)
	Sent: Friday, April 09, 2010 10:36
	To: [email-masked]; Jonathan Hui
	Cc: [email-masked]
	Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations

	I read this as a consensus to use tags J If anyone disagree
please speak up now!

	There have been plenty iterations/versions of tagging since
Frame Relay (pure switching), IBM's HPR (pure source route), Cisco's tag
switching and MPLS. More often than not, a combination of the 2 models
is used so that tags can be both swapped and stacked. 

	-          In pure switching, there's only one tag in the
packet. A tag can be locally significant, in which case it has to be
swapped as the packet progresses. For RPL, it means that a node uses as
many tags as it has children that use it has DAO targets in its subdag.

	-          In the pure source route model, tags are stacked in
an ordered list that forms a strict routing header. A tag can be locally
significant to the interpreter and is consumed (marked or removed) as
the packet progresses. For RPL, it means that a node uses as many tags
as it has children that use this node as DAO parent. 

	It also appears that the 2 tagging models map quite well with
the DAO models we have in RPL since the split that we decided with issue
#26. The fact that the combination of the 2 models is possible in the
real world today gives us a hint that we are not closing the door to the
mixed model in the future.

	-          Use locally significant tags which implies tag
assignment by the node that uses it later and tag swapping for the
stateful case.

	-          Tag distribution in DAO (there are options there that
we need to dig further)

	-          Tag content and size (people have asked for at least
2 octets to fit 15.4 short addresses, do we need some control field as
well?)

	Advice?

	Pascal

Behalf Of Robert Cragie

	Robert

	Gridmerge Ltd.
	89 Greenfield Crescent,
	Wakefield, WF4 4WA, UK
	+44 (0) 1924 910888

	Hi Robert, 

	

	A couple of questions: 
	    * I presume the source route header using these tags/labels
is an IPv6 extension header. What value for extension header type would
this be? Would we need to specify a LOWPAN_NHC value for this so we can
still use LOWPAN_NCH for UDP frames? 

	We already have a draft requesting a new IPv6 Hop-by-Hop Option
and presented it at 6man in Anaheim.  The option is designed to carry
RPL-specific information.  6lowpan-hc already has a LOWPAN_NHC value for
the IPv6 Hop-by-Hop Option header. 

	    * Can you point to where the 'core ideas have been deployed
in traditional IP networks for quite some time'? 

	MPLS.  Again, I think the mechanisms will need to be adapted,
but the core ideas are not new. 
	
	-- 
	Jonathan Hui 

	Thanks 
	
	Robert 
	
	Gridmerge Ltd. 
	89 Greenfield Crescent, 
	Wakefield, WF4 4WA, UK 
	+44 (0) 1924 910888 
	http://www.gridmerge.com 

	
	
	To make the source route header compact, I favor the tag/label
approach over some other compaction mechanism that operates directly on
a list of IPv6 addresses.  Tags/labels can be made general enough such
that they can be derived in different ways.  Because the tags/labels
have scope local to each node, the mechanism is pretty general already.
For those that are already managing unique 802.15.4 short addresses
across a network, I can see that it is attractive to utilize the short
address directly and reduce state on devices.  In other cases, it may be
best for the node to dynamically assign tags/labels for its neighbors. 
	
	Either way, while the tag/label mechanism is simple, it is far
more flexible than an approach to compacting a list of IPv6 addresses.
And note that the idea of using tags/labels is nothing new.  Of course
we will adapt the basic mechanism a bit (label distribution, headers
formats, etc), but the core ideas have been deployed in traditional IP
networks for quite some time. 
	
	I reiterated a lot of what was already stated before by others,
but that is what I think. 
	
	-- 
	Jonathan Hui 

	

	Hi Daniel: 
	
	Routers might have multiple interfaces of multiple MAC types.
Internet 0 
	even has a MAC-less format. 
	So the result of you proposal, which looks like a great idea in
a pure 
	802.15.4 world with short addresses, becomes a nightmare to
define in a 
	fully generic fashion. 
	
	OTOH, a locally significant opaque tag in which the parent could
hide a 
	short address of the child - if it cares to do it that way -
looks like 
	a way more acceptable approach 
	
	So it seems to me that you can get what you want as long as we
can make 
	the tag big enough for short addresses. When the tag is too
small to 
	contain what the parent really needs, then the parent will have
to store 
	a state with the full information in memory, and then place an
index of 
	some sort in the tag. 
	
	What do you think? 
	
	Pascal 

	-----Original Message----- 
	From: Popa, Daniel [mailto:[email-masked]] 
	Sent: Thursday, April 08, 2010 11:40 AM 
	To: ROLL WG 
	Cc: Pascal Thubert (pthubert); JeongGil Ko (John) 
	Subject: RE: [Roll] Proposal for Source Routing Header Format
and 
	SourceRoutingOperations 
	
	Hi Pascal, John, 

	L2 

	shorter 

	Cheers, 
	Daniel 

	-----Original Message----- 

	Of 

	Hi John: 

	though it is 

	it is 

	downwards 

	that should be doable) 
	
	Cheers, 
	
	Pascal 

	-----Original Message----- 

	Of 

	JeongGil Ko (John) 
	Sent: Wednesday, April 07, 2010 10:05 PM 
	To: ROLL WG 
	Subject: [Roll] Proposal for Source Routing Header Format and
Source 
	RoutingOperations 
	
	Hi! 

	To 

	add 

	one more to the conversations here is a proposal for source
routing 

	headers. 

	information) 

	packet 

	that a 

	source node wants to send to a specific destination. We can
always 

	make the 

	header super fancy but in my opinion I think we only need two
fields 

	in this 

	header and here it is! Feel free to break the stuff and mangle
with 

	it 

	so that it 

	looks great in the specs later on. FYI, this is the format that
I am 

	using in my 

	| 

	+-+-+-+-+-+-+-+-+ 

	+ 

	| 

	+ 

	+ 

	| 

	| 

	     Figure 1. Proposed Source Routing Header Format; each line
is 

	32 

	bits:) 

	- NEntry: Indicates the number of 128 bit addresses that the
source 

	route 

	entry field is carrying. 
	
	- Source Route Entry: List of 128 bit address that consist the
route 

	to the 

	destination. Here, the address of the node that is one hop away
from 

	the 

	
	When source routing is initiated at a storing node (e.g., root
of 

	the 

	DODAG), 

	(i.e., 

	from 

	front 

	of the 

	user payload. When the next hop node receives a packet that is
not 

	destined 

	to itself AND the network is NOT provisioned to be in 'storing
mode' 

	then it 

	entry. 

	Since 

	terms 

	of hops) 

	order, a node can figure out what the next hop address is with
only 

	the 

	NEntry value (since it already knows how big an ipv6 address
is). 

	After 

	collecting the next hop node's address, the node erases this
address 
	element from the entry and decreases NEntry by one. This assures

	that 

	we 

	the 

	data 

	path. 
	
	The approach itself should be very simple and trivial for
everyone 

	to 

	follow. 

	Thanks. 
	
	-John 
	
	------ 
	JeongGil Ko (John) 
	Ph.D. Student

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 9 Apr 2010 10:51:51 +0200

Hi Anders:

You did not miss much. But maybe the fact that the tag could be
stateless as long as the node knows how to do that. 

For instance a short address could be encoded in there, as long as this
is opaque to the rest of the L3 network.

One question though. In your case, do you / can you maintain any
information about neighbors? Like security ?

Pascal

From: Anders Brandt [mailto:[email-masked]] 
Sent: Friday, April 09, 2010 10:43 AM
To: Pascal Thubert (pthubert); [email-masked]; Jonathan Hui
Cc: [email-masked]
Subject: RE: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations

speak up now!

Just my $0.05

	

	Advice?

	Pascal

	
	Robert

	Gridmerge Ltd.
	89 Greenfield Crescent,
	Wakefield, WF4 4WA, UK
	+44 (0) 1924 910888

	Hi Robert, 

	A couple of questions: 

	
	-- 
	Jonathan Hui 

	Thanks 
	
	Robert 
	
	Gridmerge Ltd. 
	89 Greenfield Crescent, 
	Wakefield, WF4 4WA, UK 
	+44 (0) 1924 910888 
	http://www.gridmerge.com 

	

	
	-- 
	Jonathan Hui 

	Hi Daniel: 

	
	
	What do you think? 
	
	Pascal 

	-----Original Message----- 
	From: Popa, Daniel [mailto:[email-masked]] 
	Sent: Thursday, April 08, 2010 11:40 AM 
	To: ROLL WG 
	Cc: Pascal Thubert (pthubert); JeongGil Ko (John) 
	Subject: RE: [Roll] Proposal for Source Routing Header Format
and 
	SourceRoutingOperations 
	
	Hi Pascal, John, 

	L2 

	shorter 

	Cheers, 
	Daniel 

	-----Original Message----- 

	Of 

	Hi John: 

	though it is 

	it is 

	downwards 

	that should be doable) 
	
	Cheers, 
	
	Pascal 

	-----Original Message----- 

	Of 

	JeongGil Ko (John) 
	
	Hi! 

	To 

	add 

	headers. 

	information) 

	packet 

	that a 

	make the 

	in this 

	it 

	so that it 

	using in my 

	| 

	+-+-+-+-+-+-+-+-+ 

	+ 

	| 

	+ 

	+ 

	| 

	| 

	32 

	bits:) 

	route 

	entry field is carrying. 

	to the 

	the 

	

	the 

	DODAG), 

	(i.e., 

	from 

	front 

	of the 

	destined 

	then it 

	entry. 

	Since 

	terms 

	of hops) 

	the 

	After 

	that 

	we 

	the 

	data 

	path. 

	to 

	follow. 

	Thanks. 
	
	-John 
	
	------ 
	JeongGil Ko (John) 
	Ph.D. Student

---

From: "Popa, Daniel" <[email-masked]>
Date: Fri, 9 Apr 2010 05:45:29 -0400

Hi Pascal, 

I have first set of proposals concerning the tag/label size and content:

-          Tag/Label size:

o   As 802.15.4-2006 defines addressing modes with 16-bit short address and 64-bit extended address for Src and Dest Addressing Mode, I think we should have the same flexibility for tag/label addressing mode => tag/label should potentially accommodate values represented on a field with a length up to 64 bits. 

o   Currently, there are ongoing activities to amend MAC Layer for 802.15.4-2006 (TG 4e) that might alter the aforementioned values for MAC address size. I will try have some further information about MAC Addr Length issue and be back on the mailing list asap.   

-          Tag/Label contents:

-------------------------------------

| Control fields | Label Value | 

-------------------------------------

o   Control fields

§  2 bits to signal labeling/tagging mode:  short/extended labels  => the bit-length of the "Label Value (LV)"  field 

·         2 bits => 4 modes for LV length : 8, 16, 32 and 64 bits. 

§  Eventually, few bits (e.g., 1 or 2) for priority (e.g., to map IPv6 priority field into label priority).

§  Eventually, 1 bit for bottom of the stack flag - for source routing;  if set to 1 => the current label/tag is last in the stack.

§  1 or 2 bits RFU.

§  Eventually, some bits for hop counts (?).

o   Label Value (LV) field

§  The value of the label/tag

Thanks.

Cheers,

Daniel 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: vendredi 9 avril 2010 10:36
To: [email-masked]; Jonathan Hui
Cc: [email-masked]
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand SourceRoutingOperations

I read this as a consensus to use tags J If anyone disagree please speak up now!

There have been plenty iterations/versions of tagging since Frame Relay (pure switching), IBM's HPR (pure source route), Cisco's tag switching and MPLS. More often than not, a combination of the 2 models is used so that tags can be both swapped and stacked. 

-          In pure switching, there's only one tag in the packet. A tag can be locally significant, in which case it has to be swapped as the packet progresses. For RPL, it means that a node uses as many tags as it has children that use it has DAO targets in its subdag.

-          In the pure source route model, tags are stacked in an ordered list that forms a strict routing header. A tag can be locally significant to the interpreter and is consumed (marked or removed) as the packet progresses. For RPL, it means that a node uses as many tags as it has children that use this node as DAO parent. 

It also appears that the 2 tagging models map quite well with the DAO models we have in RPL since the split that we decided with issue #26. The fact that the combination of the 2 models is possible in the real world today gives us a hint that we are not closing the door to the mixed model in the future.

-          Use locally significant tags which implies tag assignment by the node that uses it later and tag swapping for the stateful case.

-          Tag distribution in DAO (there are options there that we need to dig further)

-          Tag content and size (people have asked for at least 2 octets to fit 15.4 short addresses, do we need some control field as well?)

-          RH format (inherit RH0 fields with labels instead of addresses? What about the tag swapping  case, RH as well?)

Advice?

 

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Cragie
Sent: Thursday, April 08, 2010 11:34 PM
To: Jonathan Hui
Cc: [email-masked]
Subject: Re: [Roll] Proposal for Source Routing Header Formatand SourceRoutingOperations

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

Hi Robert, 

A couple of questions: 
    * I presume the source route header using these tags/labels is an IPv6 extension header. What value for extension header type would this be? Would we need to specify a LOWPAN_NHC value for this so we can still use LOWPAN_NCH for UDP frames? 

We already have a draft requesting a new IPv6 Hop-by-Hop Option and presented it at 6man in Anaheim.  The option is designed to carry RPL-specific information.  6lowpan-hc already has a LOWPAN_NHC value for the IPv6 Hop-by-Hop Option header. 

    * Can you point to where the 'core ideas have been deployed in traditional IP networks for quite some time'? 

MPLS.  Again, I think the mechanisms will need to be adapted, but the core ideas are not new. 

-- 
Jonathan Hui 

Thanks 

Robert 

Gridmerge Ltd. 
89 Greenfield Crescent, 
Wakefield, WF4 4WA, UK 
+44 (0) 1924 910888 
http://www.gridmerge.com 

To make the source route header compact, I favor the tag/label approach over some other compaction mechanism that operates directly on a list of IPv6 addresses.  Tags/labels can be made general enough such that they can be derived in different ways.  Because the tags/labels have scope local to each node, the mechanism is pretty general already.  For those that are already managing unique 802.15.4 short addresses across a network, I can see that it is attractive to utilize the short address directly and reduce state on devices.  In other cases, it may be best for the node to dynamically assign tags/labels for its neighbors. 

Either way, while the tag/label mechanism is simple, it is far more flexible than an approach to compacting a list of IPv6 addresses.  And note that the idea of using tags/labels is nothing new.  Of course we will adapt the basic mechanism a bit (label distribution, headers formats, etc), but the core ideas have been deployed in traditional IP networks for quite some time. 

I reiterated a lot of what was already stated before by others, but that is what I think. 

-- 
Jonathan Hui 

Hi Daniel: 

What do you think? 

Pascal 

-----Original Message----- 
From: Popa, Daniel [mailto:[email-masked]] 
Sent: Thursday, April 08, 2010 11:40 AM 
To: ROLL WG 
Cc: Pascal Thubert (pthubert); JeongGil Ko (John) 
Subject: RE: [Roll] Proposal for Source Routing Header Format and 
SourceRoutingOperations 

Hi Pascal, John, 

L2 

shorter 

Cheers, 
Daniel 

-----Original Message----- 

Of 

Hi John: 

though it is 

it is 

downwards 

that should be doable) 

Cheers, 

Pascal 

-----Original Message----- 

Of 

JeongGil Ko (John) 

Hi! 

To 

add 

headers. 

information) 

packet 

that a 

make the 

in this 

it 

so that it 

using in my 

| 

+-+-+-+-+-+-+-+-+ 

+ 

| 

+ 

+ 

| 

| 

32 

bits:) 

route 

entry field is carrying. 

to the 

the 

the 

DODAG), 

(i.e., 

from 

front 

of the 

destined 

then it 

entry. 

Since 

terms 

of hops) 

the 

After 

that 

we 

the 

data 

path. 

to 

follow. 

Thanks. 

-John 

------ 
JeongGil Ko (John) 
Ph.D. Student

---

From: "Anders Brandt" <[email-masked]>
Date: Fri, 9 Apr 2010 12:03:49 +0200

Pascal,

Typically a network key is shared among all nodes. A few nodes (e.g.
electronic door locks with extra high security requirements) may have
dedicated link keys.
The link keys work end-to-end and do not require storage in all other
nodes.
Thus, the most simple nodes need only storage for a network key.
 
- Anders

	From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
	Sent: Friday, April 09, 2010 10:52
	To: Anders Brandt; [email-masked]; Jonathan Hui
	Cc: [email-masked]
	Subject: RE: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations

	Hi Anders:

	For instance a short address could be encoded in there, as long
as this is opaque to the rest of the L3 network.

	Pascal

	From: Anders Brandt [mailto:[email-masked]] 
	Sent: Friday, April 09, 2010 10:43 AM
	To: Pascal Thubert (pthubert); [email-masked];
Jonathan Hui
	Cc: [email-masked]
	Subject: RE: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations

	Admitted, I have been absent from this thread; trying to catch
up on others...

please speak up now!

	I have to comment respectfully but loudly that this may at best
some sort of rough concensus..

	For this kind of nodes we need a complete routing stack in the
frame. As mentioned earlier, I am perfectly
	fine with limitations such as max n entries; Compression of
addresses to 16 bits and a common subnet.

	Just my $0.05

		

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
		Sent: Friday, April 09, 2010 10:36
		To: [email-masked]; Jonathan Hui
		Cc: [email-masked]
		Subject: Re: [Roll] Proposal for Source Routing
HeaderFormatand SourceRoutingOperations

		I read this as a consensus to use tags J If anyone
disagree please speak up now!

		There have been plenty iterations/versions of tagging
since Frame Relay (pure switching), IBM's HPR (pure source route),
Cisco's tag switching and MPLS. More often than not, a combination of
the 2 models is used so that tags can be both swapped and stacked. 

		-          In pure switching, there's only one tag in
the packet. A tag can be locally significant, in which case it has to be
swapped as the packet progresses. For RPL, it means that a node uses as
many tags as it has children that use it has DAO targets in its subdag.

		-          In the pure source route model, tags are
stacked in an ordered list that forms a strict routing header. A tag can
be locally significant to the interpreter and is consumed (marked or
removed) as the packet progresses. For RPL, it means that a node uses as
many tags as it has children that use this node as DAO parent. 

		It also appears that the 2 tagging models map quite well
with the DAO models we have in RPL since the split that we decided with
issue #26. The fact that the combination of the 2 models is possible in
the real world today gives us a hint that we are not closing the door to
the mixed model in the future.

		-          Use locally significant tags which implies
tag assignment by the node that uses it later and tag swapping for the
stateful case.

		-          Tag distribution in DAO (there are options
there that we need to dig further)

		-          Tag content and size (people have asked for
at least 2 octets to fit 15.4 short addresses, do we need some control
field as well?)

		-          RH format (inherit RH0 fields with labels
instead of addresses? What about the tag swapping  case, RH as well?)

		Advice?

		Pascal

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Robert Cragie
		Sent: Thursday, April 08, 2010 11:34 PM
		To: Jonathan Hui
		Cc: [email-masked]
		Subject: Re: [Roll] Proposal for Source Routing Header
Formatand SourceRoutingOperations

		OK, sounds good. End of topic as far as I am concerned.
+1
		
		Robert

		Gridmerge Ltd.
		89 Greenfield Crescent,
		Wakefield, WF4 4WA, UK
		+44 (0) 1924 910888

		Hi Robert, 

		A couple of questions: 
		    * I presume the source route header using these
tags/labels is an IPv6 extension header. What value for extension header
type would this be? Would we need to specify a LOWPAN_NHC value for this
so we can still use LOWPAN_NCH for UDP frames? 

		We already have a draft requesting a new IPv6 Hop-by-Hop
Option and presented it at 6man in Anaheim.  The option is designed to
carry RPL-specific information.  6lowpan-hc already has a LOWPAN_NHC
value for the IPv6 Hop-by-Hop Option header. 

		    * Can you point to where the 'core ideas have been
deployed in traditional IP networks for quite some time'? 

		MPLS.  Again, I think the mechanisms will need to be
adapted, but the core ideas are not new. 
		
		-- 
		Jonathan Hui 

		Thanks 
		
		Robert 
		
		Gridmerge Ltd. 
		89 Greenfield Crescent, 
		Wakefield, WF4 4WA, UK 
		+44 (0) 1924 910888 
		http://www.gridmerge.com 

		
		To make the source route header compact, I favor the
tag/label approach over some other compaction mechanism that operates
directly on a list of IPv6 addresses.  Tags/labels can be made general
enough such that they can be derived in different ways.  Because the
tags/labels have scope local to each node, the mechanism is pretty
general already.  For those that are already managing unique 802.15.4
short addresses across a network, I can see that it is attractive to
utilize the short address directly and reduce state on devices.  In
other cases, it may be best for the node to dynamically assign
tags/labels for its neighbors. 
		
		Either way, while the tag/label mechanism is simple, it
is far more flexible than an approach to compacting a list of IPv6
addresses.  And note that the idea of using tags/labels is nothing new.
Of course we will adapt the basic mechanism a bit (label distribution,
headers formats, etc), but the core ideas have been deployed in
traditional IP networks for quite some time. 
		
		I reiterated a lot of what was already stated before by
others, but that is what I think. 
		
		-- 
		Jonathan Hui 
		
		On Apr 8, 2010, at 2:57 AM, Pascal Thubert (pthubert)
wrote: 

		Hi Daniel: 
		
		Routers might have multiple interfaces of multiple MAC
types. Internet 0 
		even has a MAC-less format. 
		So the result of you proposal, which looks like a great
idea in a pure 
		802.15.4 world with short addresses, becomes a nightmare
to define in a 
		fully generic fashion. 
		
		OTOH, a locally significant opaque tag in which the
parent could hide a 
		short address of the child - if it cares to do it that
way - looks like 
		a way more acceptable approach 
		
		So it seems to me that you can get what you want as long
as we can make 
		the tag big enough for short addresses. When the tag is
too small to 
		contain what the parent really needs, then the parent
will have to store 
		a state with the full information in memory, and then
place an index of 
		some sort in the tag. 
		
		What do you think? 
		
		Pascal 

		-----Original Message----- 
		From: Popa, Daniel [mailto:[email-masked]] 
		Sent: Thursday, April 08, 2010 11:40 AM 
		To: ROLL WG 
		Cc: Pascal Thubert (pthubert); JeongGil Ko (John) 
		Subject: RE: [Roll] Proposal for Source Routing Header
Format and 
		SourceRoutingOperations 
		
		Hi Pascal, John, 
		
		Since source routing explicitly gives forwarding
instruction to each 
		intermediate node, it can make sense to use only (MAC
address based) 

		L2 

		forwarding instead of (IPv6 address based) L3
forwarding. 

		shorter 

		Cheers, 
		Daniel 

		-----Original Message----- 

		Of 

		Pascal Thubert (pthubert) 
		Sent: jeudi 8 avril 2010 11:15 
		To: JeongGil Ko (John); ROLL WG 
		Subject: Re: [Roll] Proposal for Source Routing Header
Format and 
		SourceRoutingOperations 
		
		Hi John: 
		
		IPv6 already has a number of routing headers, in
particular RH0, 

		though it is 

		being deprecated for general use in the Internet. 
		And there are reasons why the fields in RH0/1 are there
and we need to 
		make sure we lose none of that. In particular a RH is
recoverable, and 

		it is 

		On top of this our new problems are: 
		- make sure the RH stays within the RPL network (since
it is used 

		downwards 

		that should be doable) 
		
		Cheers, 
		
		Pascal 

		-----Original Message----- 

		Of 

		JeongGil Ko (John) 
		
		Hi! 

		To 

		add 

		headers. 

		information) 

		packet 

		that a 

		make the 

		in this 

		it 

		so that it 

		using in my 

		| 

		+-+-+-+-+-+-+-+-+ 

		+ 

		| 

		+ 

		+ 

		| 

		| 

		32 

		bits:) 

		route 

		entry field is carrying. 

		to the 

		the 

		

		the 

		DODAG), 

		(i.e., 

		from 

		front 

		of the 

		destined 

		then it 

		entry. 

		Since 

		terms 

		of hops) 

		the 

		After 

		that 

		we 

		the 

		data 

		path. 

		to 

		follow. 

		Thanks. 
		
		-John 
		
		------ 
		JeongGil Ko (John) 
		Ph.D. Student

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Fri, 9 Apr 2010 13:17:13 +0300

Small comments on that…

To be able to re-distribute (update) keys, it is sometimes customary to
maintain two network keys.

One key for regular communication and one in case a node for some reason
didn’t receive the new network key (for example, wasn’t online).

Another thing is the freshness counters vs. replay attacks…

For MAC priorities – it is best to maintain freshness counters per priority
(since packets may replace order of transmissions).

So that’s two network keys and a set of freshness counters (per priority per
key).

Thanks,

Yoav

*From:* [email-masked] [mailto:[email-masked]] *On
Behalf Of *Anders
Brandt
*Sent:* Friday, April 09, 2010 1:04 PM
*To:* Pascal Thubert (pthubert); [email-masked]; Jonathan Hui
*Cc:* [email-masked]
*Subject:* Re: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations

Pascal,

Typically a network key is shared among all nodes. A few nodes (e.g.
electronic door locks with extra high security requirements) may have
dedicated link keys.
The link keys work end-to-end and do not require storage in all other nodes.
Thus, the most simple nodes need only storage for a network key.

- Anders

 ------------------------------

*From:* Pascal Thubert (pthubert) [mailto:[email-masked]]
*Sent:* Friday, April 09, 2010 10:52
*To:* Anders Brandt; [email-masked]; Jonathan Hui
*Cc:* [email-masked]
*Subject:* RE: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations

Hi Anders:

You did not miss much. But maybe the fact that the tag could be stateless as
long as the node knows how to do that.

For instance a short address could be encoded in there, as long as this is
opaque to the rest of the L3 network.

One question though. In your case, do you / can you maintain any information
about neighbors? Like security ?

Pascal

*From:* Anders Brandt [mailto:[email-masked]]
*Sent:* Friday, April 09, 2010 10:43 AM
*To:* Pascal Thubert (pthubert); [email-masked]; Jonathan Hui
*Cc:* [email-masked]
*Subject:* RE: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations

up now!

I have to comment respectfully but loudly that this may at best some sort of
rough concensus..

In a non-storing mode, I see no way of storing and/or swapping labels/tags
in each node.

For this kind of nodes we need a complete routing stack in the frame. As
mentioned earlier, I am perfectly
fine with limitations such as max n entries; Compression of addresses to 16
bits and a common subnet.

Just my $0.05

 ------------------------------

*From:* [email-masked] [mailto:[email-masked]] *On
Behalf Of *Pascal
Thubert (pthubert)
*Sent:* Friday, April 09, 2010 10:36
*To:* [email-masked]; Jonathan Hui
*Cc:* [email-masked]
*Subject:* Re: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations

I read this as a consensus to use tags J If anyone disagree please speak up
now!

There have been plenty iterations/versions of tagging since Frame Relay
(pure switching), IBM’s HPR (pure source route), Cisco’s tag switching and
MPLS. More often than not, a combination of the 2 models is used so that
tags can be both swapped and stacked.

-          In pure switching, there’s only one tag in the packet. A tag can
be locally significant, in which case it has to be swapped as the packet
progresses. For RPL, it means that a node uses as many tags as it has
children that use it has DAO targets in its subdag.

-          In the pure source route model, tags are stacked in an ordered
list that forms a strict routing header. A tag can be locally significant to
the interpreter and is consumed (marked or removed) as the packet
progresses. For RPL, it means that a node uses as many tags as it has
children that use this node as DAO parent.

It also appears that the 2 tagging models map quite well with the DAO models
we have in RPL since the split that we decided with issue #26. The fact that
the combination of the 2 models is possible in the real world today gives us
a hint that we are not closing the door to the mixed model in the future.

-          Use locally significant tags which implies tag assignment by the
node that uses it later and tag swapping for the stateful case.

-          Tag distribution in DAO (there are options there that we need to
dig further)

-          Tag content and size (people have asked for at least 2 octets to
fit 15.4 short addresses, do we need some control field as well?)

-          RH format (inherit RH0 fields with labels instead of addresses?
What about the tag swapping  case, RH as well?)

Advice?

Pascal

*From:* [email-masked] [mailto:[email-masked]] *On
Behalf Of *Robert
Cragie
*Sent:* Thursday, April 08, 2010 11:34 PM
*To:* Jonathan Hui
*Cc:* [email-masked]
*Subject:* Re: [Roll] Proposal for Source Routing Header Formatand
SourceRoutingOperations

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com

Hi Robert,

A couple of questions:
    • I presume the source route header using these tags/labels is an IPv6
extension header. What value for extension header type would this be? Would
we need to specify a LOWPAN_NHC value for this so we can still use
LOWPAN_NCH for UDP frames?

We already have a draft requesting a new IPv6 Hop-by-Hop Option and
presented it at 6man in Anaheim.  The option is designed to carry
RPL-specific information.  6lowpan-hc already has a LOWPAN_NHC value for the
IPv6 Hop-by-Hop Option header.

MPLS.  Again, I think the mechanisms will need to be adapted, but the core
ideas are not new.

-- 
Jonathan Hui

Thanks

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com

To make the source route header compact, I favor the tag/label approach over
some other compaction mechanism that operates directly on a list of IPv6
addresses.  Tags/labels can be made general enough such that they can be
derived in different ways.  Because the tags/labels have scope local to each
node, the mechanism is pretty general already.  For those that are already
managing unique 802.15.4 short addresses across a network, I can see that it
is attractive to utilize the short address directly and reduce state on
devices.  In other cases, it may be best for the node to dynamically assign
tags/labels for its neighbors.

Either way, while the tag/label mechanism is simple, it is far more flexible
than an approach to compacting a list of IPv6 addresses.  And note that the
idea of using tags/labels is nothing new.  Of course we will adapt the basic
mechanism a bit (label distribution, headers formats, etc), but the core
ideas have been deployed in traditional IP networks for quite some time.

I reiterated a lot of what was already stated before by others, but that is
what I think.

-- 
Jonathan Hui

Hi Daniel:

What do you think?

Pascal

 -----Original Message-----
From: Popa, Daniel [mailto:[email-masked] <[email-masked]>]
Sent: Thursday, April 08, 2010 11:40 AM
To: ROLL WG
Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
Subject: RE: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations

Hi Pascal, John,

L2

shorter

Cheers,
Daniel

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]<[email-masked]>]
On Behalf

Of

Hi John:

though it is

it is

downwards

that should be doable)

Cheers,

Pascal

 -----Original Message-----
From: [email-masked]
[mailto:[email-masked]<[email-masked]>]
On Behalf

Of

JeongGil Ko (John)

Hi!

To

add

headers.

information)

packet

that a

make the

in this

it

so that it

using in my

|

+-+-+-+-+-+-+-+-+

+

|

+

+

|

|

32

bits:)

route

entry field is carrying.

to the

the

the

DODAG),

(i.e.,

from

front

of the

destined

then it

entry.

Since

terms

of hops)

the

After

that

we

the

data

path.

to

follow.

Thanks.

-John

------
JeongGil Ko (John)
Ph.D. Student

---

From: "Anders Brandt" <[email-masked]>
Date: Fri, 9 Apr 2010 12:31:59 +0200

Yoav,

>So that's two network keys and a set of freshness counters (per
priority per key).

The two network keys may make sense but freshness counters are
problematic - in home control at least.
Some targets may be controlled by a high number of controllers. Counters
would require targets to hold many
instances. Since many controllers may be battery operated it is not an
option to keep the counters synchronized.
Challenge-response is also replay-proof and it requires no additional
state in nodes - except for a temporary nonce.
 
Cheers,
  Anders

	From: Yoav Ben-Yehezkel [mailto:[email-masked]] 
	Sent: Friday, April 09, 2010 12:17
	To: Anders Brandt; Pascal Thubert (pthubert);
[email-masked]; Jonathan Hui
	Cc: [email-masked]
	Subject: RE: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations

	Small comments on that...

	To be able to re-distribute (update) keys, it is sometimes
customary to maintain two network keys.

	One key for regular communication and one in case a node for
some reason didn't receive the new network key (for example, wasn't
online).

	Another thing is the freshness counters vs. replay attacks...

	For MAC priorities - it is best to maintain freshness counters
per priority (since packets may replace order of transmissions).

	So that's two network keys and a set of freshness counters (per
priority per key).

	Thanks,

	Yoav

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Anders Brandt
	Sent: Friday, April 09, 2010 1:04 PM
	To: Pascal Thubert (pthubert); [email-masked];
Jonathan Hui
	Cc: [email-masked]
	Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations

	Pascal,

	>One question though. In your case, do you / can you maintain
any information about neighbors? Like security ?

	Typically a network key is shared among all nodes. A few nodes
(e.g. electronic door locks with extra high security requirements) may
have dedicated link keys.
	The link keys work end-to-end and do not require storage in all
other nodes.
	Thus, the most simple nodes need only storage for a network key.

	- Anders

		From: Pascal Thubert (pthubert)
[mailto:[email-masked]] 
		Sent: Friday, April 09, 2010 10:52
		To: Anders Brandt; [email-masked]; Jonathan
Hui
		Cc: [email-masked]
		Subject: RE: [Roll] Proposal for Source Routing
HeaderFormatand SourceRoutingOperations

		Hi Anders:

		You did not miss much. But maybe the fact that the tag
could be stateless as long as the node knows how to do that. 

		For instance a short address could be encoded in there,
as long as this is opaque to the rest of the L3 network.

		One question though. In your case, do you / can you
maintain any information about neighbors? Like security ?

		Pascal

		From: Anders Brandt [mailto:[email-masked]] 
		Sent: Friday, April 09, 2010 10:43 AM
		To: Pascal Thubert (pthubert);
[email-masked]; Jonathan Hui
		Cc: [email-masked]
		Subject: RE: [Roll] Proposal for Source Routing
HeaderFormatand SourceRoutingOperations

		Admitted, I have been absent from this thread; trying to
catch up on others...

		I have to comment respectfully but loudly that this may
at best some sort of rough concensus..

		In a non-storing mode, I see no way of storing and/or
swapping labels/tags in each node.

		For this kind of nodes we need a complete routing stack
in the frame. As mentioned earlier, I am perfectly
		fine with limitations such as max n entries; Compression
of addresses to 16 bits and a common subnet.

		Just my $0.05

			

			I read this as a consensus to use tags J If
anyone disagree please speak up now!

			There have been plenty iterations/versions of
tagging since Frame Relay (pure switching), IBM's HPR (pure source
route), Cisco's tag switching and MPLS. More often than not, a
combination of the 2 models is used so that tags can be both swapped and
stacked. 

			-          In pure switching, there's only one
tag in the packet. A tag can be locally significant, in which case it
has to be swapped as the packet progresses. For RPL, it means that a
node uses as many tags as it has children that use it has DAO targets in
its subdag.

			-          In the pure source route model, tags
are stacked in an ordered list that forms a strict routing header. A tag
can be locally significant to the interpreter and is consumed (marked or
removed) as the packet progresses. For RPL, it means that a node uses as
many tags as it has children that use this node as DAO parent. 

			It also appears that the 2 tagging models map
quite well with the DAO models we have in RPL since the split that we
decided with issue #26. The fact that the combination of the 2 models is
possible in the real world today gives us a hint that we are not closing
the door to the mixed model in the future.

			-          Use locally significant tags which
implies tag assignment by the node that uses it later and tag swapping
for the stateful case.

			-          Tag distribution in DAO (there are
options there that we need to dig further)

			-          Tag content and size (people have
asked for at least 2 octets to fit 15.4 short addresses, do we need some
control field as well?)

			-          RH format (inherit RH0 fields with
labels instead of addresses? What about the tag swapping  case, RH as
well?)

			Advice?

			Pascal

Header Formatand SourceRoutingOperations

			OK, sounds good. End of topic as far as I am
concerned. +1
			
			Robert

			Gridmerge Ltd.
			89 Greenfield Crescent,
			Wakefield, WF4 4WA, UK
			+44 (0) 1924 910888
			http://www.gridmerge.com

			Hi Robert, 

			A couple of questions: 
			    * I presume the source route header using
these tags/labels is an IPv6 extension header. What value for extension
header type would this be? Would we need to specify a LOWPAN_NHC value
for this so we can still use LOWPAN_NCH for UDP frames? 

			We already have a draft requesting a new IPv6
Hop-by-Hop Option and presented it at 6man in Anaheim.  The option is
designed to carry RPL-specific information.  6lowpan-hc already has a
LOWPAN_NHC value for the IPv6 Hop-by-Hop Option header. 

			    * Can you point to where the 'core ideas
have been deployed in traditional IP networks for quite some time'? 

			MPLS.  Again, I think the mechanisms will need
to be adapted, but the core ideas are not new. 
			
			-- 
			Jonathan Hui 

			Thanks 
			
			Robert 
			
			Gridmerge Ltd. 
			89 Greenfield Crescent, 
			Wakefield, WF4 4WA, UK 
			+44 (0) 1924 910888 
			http://www.gridmerge.com 

			
			To make the source route header compact, I favor
the tag/label approach over some other compaction mechanism that
operates directly on a list of IPv6 addresses.  Tags/labels can be made
general enough such that they can be derived in different ways.  Because
the tags/labels have scope local to each node, the mechanism is pretty
general already.  For those that are already managing unique 802.15.4
short addresses across a network, I can see that it is attractive to
utilize the short address directly and reduce state on devices.  In
other cases, it may be best for the node to dynamically assign
tags/labels for its neighbors. 
			
			Either way, while the tag/label mechanism is
simple, it is far more flexible than an approach to compacting a list of
IPv6 addresses.  And note that the idea of using tags/labels is nothing
new.  Of course we will adapt the basic mechanism a bit (label
distribution, headers formats, etc), but the core ideas have been
deployed in traditional IP networks for quite some time. 
			
			I reiterated a lot of what was already stated
before by others, but that is what I think. 
			
			-- 
			Jonathan Hui 
			
			On Apr 8, 2010, at 2:57 AM, Pascal Thubert
(pthubert) wrote: 

			Hi Daniel: 
			
			Routers might have multiple interfaces of
multiple MAC types. Internet 0 
			even has a MAC-less format. 
			So the result of you proposal, which looks like
a great idea in a pure 
			802.15.4 world with short addresses, becomes a
nightmare to define in a 
			fully generic fashion. 
			
			OTOH, a locally significant opaque tag in which
the parent could hide a 
			short address of the child - if it cares to do
it that way - looks like 
			a way more acceptable approach 
			
			So it seems to me that you can get what you want
as long as we can make 
			the tag big enough for short addresses. When the
tag is too small to 
			contain what the parent really needs, then the
parent will have to store 
			a state with the full information in memory, and
then place an index of 
			some sort in the tag. 
			
			What do you think? 
			
			Pascal 

			-----Original Message----- 
			From: Popa, Daniel
[mailto:[email-masked]] 
			Sent: Thursday, April 08, 2010 11:40 AM 
			To: ROLL WG 
			Cc: Pascal Thubert (pthubert); JeongGil Ko
(John) 
			Subject: RE: [Roll] Proposal for Source Routing
Header Format and 
			SourceRoutingOperations 
			
			Hi Pascal, John, 
			
			Since source routing explicitly gives forwarding
instruction to each 
			intermediate node, it can make sense to use only
(MAC address based) 

			L2 

			This brings two advantages: 
			- avoid processing each transit packets up to
L3. 
			- use MAC addresses that - in ROLL environment -
have inherently 

			shorter 

			Cheers, 
			Daniel 

			-----Original Message----- 

			Of 

Header Format and 
			SourceRoutingOperations 
			
			Hi John: 

			though it is 

			being deprecated for general use in the
Internet. 
			And there are reasons why the fields in RH0/1
are there and we need to 
			make sure we lose none of that. In particular a
RH is recoverable, and 

			it is 

			On top of this our new problems are: 
			- make sure the RH stays within the RPL network
(since it is used 

			downwards 

			that should be doable) 
			- control the size (that probably means
compress) 
			
			Cheers, 
			
			Pascal 

			-----Original Message----- 

			Of 

			JeongGil Ko (John) 
			Sent: Wednesday, April 07, 2010 10:05 PM 
			To: ROLL WG 
			Subject: [Roll] Proposal for Source Routing
Header Format and Source 
			RoutingOperations 
			
			Hi! 
			
			Great to see all this discussions on downwards
route establishment! 

			To 

			add 

			one more to the conversations here is a proposal
for source routing 

			headers. 

			In non-storing mode (where only the root has
individual path 

			information) 

			the root will be attaching a source routing
header to the data 

			packet 

			that a 

			source node wants to send to a specific
destination. We can always 

			make the 

			header super fancy but in my opinion I think we
only need two fields 

			in this 

			header and here it is! Feel free to break the
stuff and mangle with 

			it 

			so that it 

			looks great in the specs later on. FYI, this is
the format that I am 

			using in my 

			| 

			+-+-+-+-+-+-+-+-+ 

			+ 

			|                       Source Route Entry
(128*NEntry bits) 

			| 

			+ 

			+ 

			| 

			| 

			     Figure 1. Proposed Source Routing Header
Format; each line is 

			32 

			bits:) 

			- NEntry: Indicates the number of 128 bit
addresses that the source 

			route 

			entry field is carrying. 
			
			- Source Route Entry: List of 128 bit address
that consist the route 

			to the 

			destination. Here, the address of the node that
is one hop away from 

			the 

			
			When source routing is initiated at a storing
node (e.g., root of 

			the 

			DODAG), 

			the header is attached on the data packet for
the entire route 

			(i.e., 

			from 

			next hop node to the destination). This header
is positioned in 

			front 

			of the 

			user payload. When the next hop node receives a
packet that is not 

			destined 

			to itself AND the network is NOT provisioned to
be in 'storing mode' 

			then it 

			checks NEntry to find what the next hop is in
the source route 

			entry. 

			Since 

			the 'Source Route Entry' is ordered in 'farthest
-> closest' (in 

			terms 

			of hops) 

			order, a node can figure out what the next hop
address is with only 

			the 

			NEntry value (since it already knows how big an
ipv6 address is). 

			After 

			collecting the next hop node's address, the node
erases this address 
			element from the entry and decreases NEntry by
one. This assures 

			that 

			we 

			avoid the overhead of carrying the entire source
route throughout 

			the 

			data 

			path. 
			
			The approach itself should be very simple and
trivial for everyone 

			to 

			follow. 

			Thanks. 
			
			-John 
			
			------ 
			JeongGil Ko (John) 
			Ph.D. Student

---

From: "Popa, Daniel" <[email-masked]>
Date: Fri, 9 Apr 2010 07:09:41 -0400

Pascal, all, 

The proposed 4e MAC Amendment for 802.15.4 introduces a "8-bit simple address" in addition to the 16-bit short and 64-bit extended addresses, from 802.15.4-2006.

So, we need 2 bits to signal the size (e.g., 8, 16, 32, and 64) of the "Label Value" Field. 

Below is the link to the proposed amendment draft (refer to rev6). 

https://mentor.ieee.org/802.15/documents?is_dcn=604&is_group=004e

Thanks.

Cheers, 

Daniel 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Popa, Daniel
Sent: vendredi 9 avril 2010 11:45
To: Pascal Thubert (pthubert)
Cc: [email-masked]
Subject: Re: [Roll] Proposal for Source RoutingHeaderFormatand SourceRoutingOperations

Hi Pascal, 

-          Tag/Label size:

-          Tag/Label contents:

o   Control fields

§  1 or 2 bits RFU.

o   Label Value (LV) field

 

Thanks.

Cheers,

Daniel 

Advice?

 

Pascal

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

Hi Robert, 

A couple of questions: 

-- 
Jonathan Hui 

Thanks 

Robert 

Gridmerge Ltd. 
89 Greenfield Crescent, 
Wakefield, WF4 4WA, UK 
+44 (0) 1924 910888 
http://www.gridmerge.com 

-- 
Jonathan Hui 

Hi Daniel: 

What do you think? 

Pascal 

-----Original Message----- 
From: Popa, Daniel [mailto:[email-masked]] 
Sent: Thursday, April 08, 2010 11:40 AM 
To: ROLL WG 
Cc: Pascal Thubert (pthubert); JeongGil Ko (John) 
Subject: RE: [Roll] Proposal for Source Routing Header Format and 
SourceRoutingOperations 

Hi Pascal, John, 

L2 

shorter 

Cheers, 
Daniel 

-----Original Message----- 

Of 

Hi John: 

though it is 

it is 

downwards 

that should be doable) 

Cheers, 

Pascal 

-----Original Message----- 

Of 

JeongGil Ko (John) 

Hi! 

To 

add 

headers. 

information) 

packet 

that a 

make the 

in this 

it 

so that it 

using in my 

| 

+-+-+-+-+-+-+-+-+ 

+ 

| 

+ 

+ 

| 

| 

32 

bits:) 

route 

entry field is carrying. 

to the 

the 

the 

DODAG), 

(i.e., 

from 

front 

of the 

destined 

then it 

entry. 

Since 

terms 

of hops) 

the 

After 

that 

we 

the 

data 

path. 

to 

follow. 

Thanks. 

-John 

------ 
JeongGil Ko (John) 
Ph.D. Student

---

From: "Don Sturek" <[email-masked]>
Date: Fri, 9 Apr 2010 06:59:58 -0700

4e is a ways away from ratification in IEEE.  I would not assume 8 bit
simple addresses quite yet.  Note that these would only be useful in a
subset of deployed networks given the extremely small address range they
would provide.

Don

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Popa, Daniel
Sent: Friday, April 09, 2010 4:10 AM
To: Pascal Thubert (pthubert)
Cc: [email-masked]
Subject: Re: [Roll] Proposal for Source RoutingHeaderFormatand
SourceRoutingOperations

Pascal, all, 

The proposed 4e MAC Amendment for 802.15.4 introduces a “8-bit simple
address” in addition to the 16-bit short and 64-bit extended addresses, from
802.15.4-2006.

So, we need 2 bits to signal the size (e.g., 8, 16, 32, and 64) of the
“Label Value” Field. 

https://mentor.ieee.org/802.15/documents?is_dcn=604
<https://mentor.ieee.org/802.15/documents?is_dcn=604&is_group=004e>
&is_group=004e

Thanks.

Cheers, 

Daniel 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Popa, Daniel
Sent: vendredi 9 avril 2010 11:45
To: Pascal Thubert (pthubert)
Cc: [email-masked]
Subject: Re: [Roll] Proposal for Source RoutingHeaderFormatand
SourceRoutingOperations

Hi Pascal, 

-          Tag/Label size:

o   As 802.15.4-2006 defines addressing modes with 16-bit short address and
64-bit extended address for Src and Dest Addressing Mode, I think we should
have the same flexibility for tag/label addressing mode => tag/label should
potentially accommodate values represented on a field with a length up to 64
bits. 

o   Currently, there are ongoing activities to amend MAC Layer for
802.15.4-2006 (TG 4e) that might alter the aforementioned values for MAC
address size. I will try have some further information about MAC Addr Length
issue and be back on the mailing list asap.   

-          Tag/Label contents:

o   Control fields

§  2 bits to signal labeling/tagging mode:  short/extended labels  => the
bit-length of the “Label Value (LV)”  field 

§  Eventually, few bits (e.g., 1 or 2) for priority (e.g., to map IPv6
priority field into label priority).

§  Eventually, 1 bit for bottom of the stack flag - for source routing;  if
set to 1 => the current label/tag is last in the stack.

§  1 or 2 bits RFU.

o   Label Value (LV) field

 

Thanks.

Cheers,

Daniel 

Advice?

 

Pascal

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

Hi Robert, 

A couple of questions: 

-- 
Jonathan Hui 

Thanks 

Robert 

Gridmerge Ltd. 
89 Greenfield Crescent, 
Wakefield, WF4 4WA, UK 
+44 (0) 1924 910888 
http://www.gridmerge.com 

-- 
Jonathan Hui 

Hi Daniel: 

What do you think? 

Pascal 

-----Original Message----- 
From: Popa, Daniel [mailto:[email-masked]] 
Sent: Thursday, April 08, 2010 11:40 AM 
To: ROLL WG 
Cc: Pascal Thubert (pthubert); JeongGil Ko (John) 
Subject: RE: [Roll] Proposal for Source Routing Header Format and 
SourceRoutingOperations 

Hi Pascal, John, 

L2 

shorter 

Cheers, 
Daniel 

-----Original Message----- 

Of 

Hi John: 

though it is 

it is 

downwards 

that should be doable) 

Cheers, 

Pascal 

-----Original Message----- 

Of 

JeongGil Ko (John) 

Hi! 

To 

add 

headers. 

information) 

packet 

that a 

make the 

in this 

it 

so that it 

using in my 

| 

+-+-+-+-+-+-+-+-+ 

+ 

| 

+ 

+ 

| 

| 

32 

bits:) 

route 

entry field is carrying. 

to the 

the 

the 

DODAG), 

(i.e., 

from 

front 

of the 

destined 

then it 

entry. 

Since 

terms 

of hops) 

the 

After 

that 

we 

the 

data 

path. 

to 

follow. 

Thanks. 

-John 

------ 
JeongGil Ko (John) 
Ph.D. Student

---

From: "Popa, Daniel" <[email-masked]>
Date: Fri, 9 Apr 2010 10:39:50 -0400

Maybe, but I think the 8-bit simple address will not be THE issue that will stop ratification of the 4e amendment. 

I assume that a generic labeling approach should not close the door for further developments or existing deployments.  So, having variable-size labels (e.g., in steps of octets, but no longer than some M octets) can better adapt to heterogeneous devices, which will have different constraints. One may design shorter labels for some devices and longer labels for some other devices. 

Cheers, 

Daniel 

From: Don Sturek [mailto:[email-masked]] 
Sent: vendredi 9 avril 2010 16:00
To: Popa, Daniel; 'Pascal Thubert (pthubert)'
Cc: [email-masked]
Subject: RE: [Roll] Proposal for Source RoutingHeaderFormatand SourceRoutingOperations

4e is a ways away from ratification in IEEE.  I would not assume 8 bit simple addresses quite yet.  Note that these would only be useful in a subset of deployed networks given the extremely small address range they would provide.

Don

Pascal, all, 

Thanks.

Cheers, 

Daniel 

Hi Pascal, 

-          Tag/Label size:

-          Tag/Label contents:

o   Control fields

§  1 or 2 bits RFU.

o   Label Value (LV) field

 

Thanks.

Cheers,

Daniel 

Advice?

 

Pascal

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

Hi Robert, 

A couple of questions: 

-- 
Jonathan Hui 

Thanks 

Robert 

Gridmerge Ltd. 
89 Greenfield Crescent, 
Wakefield, WF4 4WA, UK 
+44 (0) 1924 910888 
http://www.gridmerge.com 

-- 
Jonathan Hui 

Hi Daniel: 

What do you think? 

Pascal 

-----Original Message----- 
From: Popa, Daniel [mailto:[email-masked]] 
Sent: Thursday, April 08, 2010 11:40 AM 
To: ROLL WG 
Cc: Pascal Thubert (pthubert); JeongGil Ko (John) 
Subject: RE: [Roll] Proposal for Source Routing Header Format and 
SourceRoutingOperations 

Hi Pascal, John, 

L2 

shorter 

Cheers, 
Daniel 

-----Original Message----- 

Of 

Hi John: 

though it is 

it is 

downwards 

that should be doable) 

Cheers, 

Pascal 

-----Original Message----- 

Of 

JeongGil Ko (John) 

Hi! 

To 

add 

headers. 

information) 

packet 

that a 

make the 

in this 

it 

so that it 

using in my 

| 

+-+-+-+-+-+-+-+-+ 

+ 

| 

+ 

+ 

| 

| 

32 

bits:) 

route 

entry field is carrying. 

to the 

the 

the 

DODAG), 

(i.e., 

from 

front 

of the 

destined 

then it 

entry. 

Since 

terms 

of hops) 

the 

After 

that 

we 

the 

data 

path. 

to 

follow. 

Thanks. 

-John 

------ 
JeongGil Ko (John) 
Ph.D. Student

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 9 Apr 2010 07:41:40 -0700

Hi Anders,

> addresses to 16 bits and a common subnet.

The issues of tags vs. storing/non-storing are orthogonal.

For non-storing mode, the use of tags does not require any storage  
within the RPL network as long as you can map some locally unique  
identifier to the tag namespace.  For example, assuming a 16-bit tag,  
it is natural to simply use the 802.15.4 short address since those  
must be at least locally unique and in many cases are unique within  
the entire network.  Source routing then becomes source routing on  
tags rather than on IPv6 addresses.  For storing mode, nodes can  
continue to maintain tags for each destination in their sub-DAG.

The difference is that in both cases, nodes route on tags rather than  
IPv6 addresses.  Tags are smaller than IPv6 addresses, so that means  
smaller source route headers for non-storing mode and smaller routing  
tables for storing mode.  Another nice feature with tags is that you  
can maintain multiple tags for the same destination and using tags to  
perform traffic engineering is the primary reason why tags/labels are  
used in IP networks today.

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 9 Apr 2010 08:00:21 -0700

Hi Daniel,

Some comments:

- I'm not in favor of having variable sized tags.  It complicates  
processing and state maintenance.  It makes dealing with RH0-style  
headers difficult because it causes you to move large portions of the  
header around when you simply need to perform a label swap.  We should  
pick a fixed size that is reasonable (e.g. 16-bits).  Anything too  
large diminishes a primary reason for having tags - a compact  
identifier for the next hop.

- For a source routing header, I'd much rather see something derived  
from the RH0 format.

- For different levels of service, the nice thing with tags is that  
the tag itself can identify not only a destination but also how to get  
there (path, service level, etc.).  That is the primary reason why  
labels are used in traditional IP networks today.  Of course, it means  
that you will have to maintain multiple tags for the same  
destination.  And if you're directly mapping the full 802.15.4 short  
address space into the tag space, then you have to be more careful  
about managing the mapping (e.g. make sure short addresses can be  
encoded within 14 or 15 bits).  Alternatively, maybe 16 bits is not  
enough for what you want to do.  In the end, I'm not sure we want to  
explicitly reserve bits for indicating a service level rather than  
simply keeping a flat tag namespace.  The use case should define what  
to do with the bits.

--
Jonathan Hui

On Apr 9, 2010, at 2:45 AM, Popa, Daniel wrote:

> o   As 802.15.4-2006 defines addressing modes with 16-bit short  
> address and 64-bit extended address for Src and Dest Addressing  
> Mode, I think we should have the same flexibility for tag/label  
> addressing mode => tag/label should potentially accommodate values  
> represented on a field with a length up to 64 bits.
> 802.15.4-2006 (TG 4e) that might alter the aforementioned values for  
> MAC address size. I will try have some further information about MAC  
> Addr Length issue and be back on the mailing list asap.
>
> -          Tag/Label contents:
>
> §  2 bits to signal labeling/tagging mode:  short/extended labels   
> => the bit-length of the “Label Value (LV)”  field
> §  Eventually, few bits (e.g., 1 or 2) for priority (e.g., to map  
> IPv6 priority field into label priority).
> §  Eventually, 1 bit for bottom of the stack flag - for source  
> routing;  if set to 1 => the current label/tag is last in the stack.
> §  1 or 2 bits RFU.
> Of Pascal Thubert (pthubert)
> There have been plenty iterations/versions of tagging since Frame  
> Relay (pure switching), IBM’s HPR (pure source route), Cisco’s tag  
> switching and MPLS. More often than not, a combination of the 2  
> models is used so that tags can be both swapped and stacked.
>
> -          In pure switching, there’s only one tag in the packet. A  
> tag can be locally significant, in which case it has to be swapped  
> as the packet progresses. For RPL, it means that a node uses as many  
> tags as it has children that use it has DAO targets in its subdag.
>
> ordered list that forms a strict routing header. A tag can be  
> locally significant to the interpreter and is consumed (marked or  
> removed) as the packet progresses. For RPL, it means that a node  
> uses as many tags as it has children that use this node as DAO parent.
>
> It also appears that the 2 tagging models map quite well with the  
> DAO models we have in RPL since the split that we decided with issue  
> #26. The fact that the combination of the 2 models is possible in  
> the real world today gives us a hint that we are not closing the  
> door to the mixed model in the future.
>
> -          Use locally significant tags which implies tag assignment  
> by the node that uses it later and tag swapping for the stateful case.
> -          Tag content and size (people have asked for at least 2  
> octets to fit 15.4 short addresses, do we need some control field as  
> well?)
> Of Robert Cragie
>     • I presume the source route header using these tags/labels is  
> an IPv6 extension header. What value for extension header type would  
> labels have scope local to each node, the mechanism is pretty

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Fri, 9 Apr 2010 18:00:26 +0300

I agree freshness counters are problematic (sorry - I thought the question
was about worst case scenario).

Regards,

Yoav

*From:* Anders Brandt [mailto:[email-masked]]
*Sent:* Friday, April 09, 2010 1:32 PM
*To:* Yoav Ben-Yehezkel; Pascal Thubert (pthubert);
[email-masked]; Jonathan Hui
*Cc:* [email-masked]
*Subject:* RE: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations

Yoav,

>So that’s two network keys and a set of freshness counters (per priority
per key).

The two network keys may make sense but freshness counters are problematic -
in home control at least.

Challenge-response is also replay-proof and it requires no additional state
in nodes - except for a temporary nonce.

Cheers,

  Anders

*From:* Yoav Ben-Yehezkel [mailto:[email-masked]]
*Sent:* Friday, April 09, 2010 12:17
*To:* Anders Brandt; Pascal Thubert (pthubert); [email-masked];
Jonathan Hui
*Cc:* [email-masked]
*Subject:* RE: [Roll] Proposal for Source Routing HeaderFormatand
SourceRoutingOperations

Small comments on that…

Thanks,

Yoav

Pascal,

- Anders

Hi Anders:

Pascal

up now!

Just my $0.05

Advice?

Pascal

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com

Hi Robert,

A couple of questions:

-- 
Jonathan Hui

Thanks

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com

-- 
Jonathan Hui

Hi Daniel:

What do you think?

Pascal

-----Original Message-----
From: Popa, Daniel [mailto:[email-masked] <[email-masked]>]
Sent: Thursday, April 08, 2010 11:40 AM
To: ROLL WG
Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
Subject: RE: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations

Hi Pascal, John,

L2

shorter

Cheers,
Daniel

-----Original Message-----

Of

Hi John:

though it is

it is

downwards

that should be doable)

Cheers,

Pascal

-----Original Message-----

Of

JeongGil Ko (John)

Hi!

To

add

headers.

information)

packet

that a

make the

in this

it

so that it

using in my

|

+-+-+-+-+-+-+-+-+

+

|

+

+

|

|

32

bits:)

route

entry field is carrying.

to the

the

the

DODAG),

(i.e.,

from

front

of the

destined

then it

entry.

Since

terms

of hops)

the

After

that

we

the

data

path.

to

follow.

Thanks.

-John

------
JeongGil Ko (John)
Ph.D. Student

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 9 Apr 2010 08:19:17 -0700

Hi Pascal,

> door to the mixed model in the future.

Agree with everything here.

> by the node that uses it later and tag swapping for the stateful case.

In favor of local tags.  Just to be clear to others, having local tags  
is more general than global tags in that you can use global tags as  
your local tags as well.  So the case where you directly map 802.15.4  
short addresses into the tag would work as long as the tag has enough  
bits to do so.

> -          Tag distribution in DAO (there are options there that we  

The DAO is a natural place to communicate tags.  There are questions  
of whether a node should know it's own tag, but these are just  
details.  I also would like to see an option record-route header for  
quickly establishing a path along the way - I know I've asked for this  
many times before :).

> octets to fit 15.4 short addresses, do we need some control field as  

I'd prefer to see the tag fixed in size.  One octet seems to be a bit  
small.  When the tag is too small, you have to worry about reusing  
tags prematurely and it limits how many destinations you can  
reasonably identify.  Two octets seems to be more appropriate.  Three  
or Four octets may be even better if you want to have some extra bits  
for service levels.  But I'd want to be extra sure that we *need*  
every bit because it dictates the source route header and routing  
table size.

> addresses? What about the tag swapping  case, RH as well?)

Inheriting RH0 fields for both is fine with me.

--
Jonathan Hui

---

From: "Popa, Daniel" <[email-masked]>
Date: Fri, 9 Apr 2010 12:01:19 -0400

Hi Jonathan, 

Thanks for comments.

Some additional comments between your lines.

Cheers, 
Daniel

-----Original Message-----
From: Jonathan Hui [mailto:[email-masked]] 
Sent: vendredi 9 avril 2010 17:00
To: Popa, Daniel
Cc: Pascal Thubert (pthubert); [email-masked]; [email-masked]
Subject: Re: [Roll] Proposal for Source Routing HeaderFormatand SourceRoutingOperations

Hi Daniel,

Some comments:

---
DP1: Let assume we have X bits for control. The problem with a short tag is that it burdens the management of mapping Link Layer addresses larger 16 bits into a (16-X)-bit field. 
DP2: It will be quite mission impossible to chose the right length for the "Tag Value" field. And I agree a too large tag decreases the reason of having tags. 

DP3: I'm not necessarily in favor of having tags with different sizes within the same network. I'm rather in favor of having the flexibility to chose the size of the label that meets the network design objectives. There were discussions about 802.15.4 address space but there can be many other scenarios that might adopt ROLL, where the Link Layer addressing is different from 802.15.4 MAC addressing. So, having the possibility to chose for your network the size of the label is a "nice to have" feature.
---

destination.  

--
DP: For this reason is nice to have 1 or 2 bits for service level within the tag, to avoid burdening nodes by maintaining multiple tags for the same destination. 
-- 

And if you're directly mapping the full 802.15.4 short  

--
Jonathan Hui

On Apr 9, 2010, at 2:45 AM, Popa, Daniel wrote:

> => the bit-length of the "Label Value (LV)"  field
> Relay (pure switching), IBM's HPR (pure source route), Cisco's tag  
> -          In pure switching, there's only one tag in the packet. A  
>     * I presume the source route header using these tags/labels is

---

From: Robert Cragie <[email-masked]>
Date: Fri, 09 Apr 2010 17:23:53 +0100

I thought the idea was to use the hop-by-hop extension header for source 
routing? Isn't that what 
http://tools.ietf.org/id/draft-hui-6man-rpl-option-00.txt is all about? 
Or are you suggesting using that just for route repair?

I'm confused - can we have a statement regarding the intention behind 
the above draft and how you propose to use the extension headers for 
source routing and whatever else (in the DAO?)?

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

On 09/04/2010 4:00 PM, Jonathan Hui wrote:
>> address and 64-bit extended address for Src and Dest Addressing Mode, 
>> I think we should have the same flexibility for tag/label addressing 
>> mode => tag/label should potentially accommodate values represented 
>> on a field with a length up to 64 bits.
>> §  2 bits to signal labeling/tagging mode:  short/extended labels  => 
>> the bit-length of the “Label Value (LV)”  field
>> tag can be locally significant, in which case it has to be swapped as 
>> the packet progresses. For RPL, it means that a node uses as many 
>> the packet progresses. For RPL, it means that a node uses as many 
>> tags as it has children that use this node as DAO parent.
>>

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 9 Apr 2010 09:34:11 -0700

Hi Robert,

On Apr 9, 2010, at 9:23 AM, Robert Cragie wrote:

> I thought the idea was to use the hop-by-hop extension header for  
> source routing? Isn't that whathttp://tools.ietf.org/id/draft-hui-6man-rpl-option-00.txt 
>  is all about? Or are you suggesting using that just for route repair?
>
> I'm confused - can we have a statement regarding the intention  
> behind the above draft and how you propose to use the extension  
> headers for source routing and whatever else (in the DAO?)?

The intention with the RPL option is to use it for whatever we need  
for RPL.  Detecting inconsistencies is one.  Using it to carry source  
route headers is another.  The point is that we left the RPL option as  
simple container and is flexible in what we put in it.

Note that I said "RH0-style" that doesn't mean using RH0 verbatim.  In  
fact, we can't use RH0 because it is deprecated.  What I meant by "RH0- 
style" is that the fields and format would be derived from RH0.

--
Jonathan Hui

>> headers difficult because it causes you to move large portions of  
>> the header around when you simply need to perform a label swap.  We  
>> should pick a fixed size that is reasonable (e.g. 16-bits).   
>> Anything too large diminishes a primary reason for having tags - a  
>> compact identifier for the next hop.
>>
>> - For a source routing header, I'd much rather see something  
>> derived from the RH0 format.
>>
>> the tag itself can identify not only a destination but also how to  
>> get there (path, service level, etc.).  That is the primary reason  
>> why labels are used in traditional IP networks today.  Of course,  
>> it means that you will have to maintain multiple tags for the same  
>> destination.  And if you're directly mapping the full 802.15.4  
>> short address space into the tag space, then you have to be more  
>> careful about managing the mapping (e.g. make sure short addresses  
>> can be encoded within 14 or 15 bits).  Alternatively, maybe 16 bits  
>> is not enough for what you want to do.  In the end, I'm not sure we  
>> want to explicitly reserve bits for indicating a service level  
>> rather than simply keeping a flat tag namespace.  The use case  
>> should define what to do with the bits.
>>
>> -- 
>> Jonathan Hui
>>
>>> 802.15.4-2006 (TG 4e) that might alter the aforementioned values  
>>> for MAC address size. I will try have some further information  
>>> about MAC Addr Length issue and be back on the mailing list asap.
>>>
>>> -          Tag/Label contents:
>>>
>>> -          In pure switching, there’s only one tag in the packet.  
>>> A tag can be locally significant, in which case it has to be  
>>> swapped as the packet progresses. For RPL, it means that a node  
>>> uses as many tags as it has children that use it has DAO targets  
>>> in its subdag.
>>>
>>> DAO models we have in RPL since the split that we decided with  
>>> issue #26. The fact that the combination of the 2 models is  
>>> possible in the real world today gives us a hint that we are not  
>>> closing the door to the mixed model in the future.
>>>
>>> octets to fit 15.4 short addresses, do we need some control field  
>>> as well?)
>>> an IPv6 extension header. What value for extension header type  
>>> would this be? Would we need to specify a LOWPAN_NHC value for  
>>> this so we can still use LOWPAN_NCH for UDP frames?
>>>
>>> and presented it at 6man in Anaheim.  The option is designed to  
>>> carry RPL-specific information.  6lowpan-hc already has a  
>>> see that it is attractive to utilize the short address directly  
>>> and reduce state on devices.  In other cases, it may be best for  
>>> the node to dynamically assign tags/labels for its neighbors.
>>>
>>> more flexible than an approach to compacting a list of IPv6  
>>> addresses.  And note that the idea of using tags/labels is nothing

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 9 Apr 2010 22:54:17 +0200

On Apr 9, 2010, at 18:34, Jonathan Hui wrote:

> the RPL option as simple container and is flexible in what we put in it

One comment in 6man (was that by Erik?) was that this is not the only place to put it -- we might as well insert a header in front of the IPv6 header like MPLS does.  Now all this talk about forwarding by tags instead of IP addresses puts a pretty eerie ring on that...

Gruesse, Carsten

---

From: Philip Levis <[email-masked]>
Date: Fri, 9 Apr 2010 17:16:42 -0700

On Apr 9, 2010, at 1:35 AM, Pascal Thubert (pthubert) wrote:

> There have been plenty iterations/versions of tagging since Frame Relay (pure switching), IBM’s HPR (pure source route), Cisco’s tag switching and MPLS. More often than not, a combination of the 2 models is used so that tags can be both swapped and stacked.

I think it is very dangerous to start from examples in the wired domain. The long history of wireless research has shown that doing so typically leads to big problems. We should start from the deployed, working examples in the wireless domain.

Phil

---

From: Richard Kelsey <[email-masked]>
Date: Mon, 12 Apr 2010 09:46:14 -0400

> From: Carsten Bormann <[email-masked]>
> Date: Fri, 9 Apr 2010 22:54:17 +0200
> Cc: [email-masked], "Popa, Daniel" <[email-masked]>
> 
> One comment in 6man (was that by Erik?) was that this is not the only
> place to put it -- we might as well insert a header in front of the
> IPv6 header like MPLS does.  Now all this talk about forwarding by
> tags instead of IP addresses puts a pretty eerie ring on that...

Why aren't we inserting a header in front of the IPv6
header like MPLS does?  Especially as the hop-by-hop
option seems to be getting more complicated (alignment,
maximum size)?  I am not advocating doing so, just
wondering why we don't.
                             -Richard Kelsey

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 12 Apr 2010 08:08:56 -0700

> maximum size)?  I am not advocating doing so, just

It was argued to me that we also need to consider the case of source  
routing on full IPv6 addresses for "completeness" or as a "base".  Is  
that no longer the case?  I'm all for simplicity and limiting options...

As for use of an MPLS-like header, here are the arguments I see.   
Inserting a layer below IPv6 means no changes are made to the IPv6  
packet for forwarding within the RPL domain, forwarding is potentially  
simpler if the header is easier to process than the IPv6 + Extension  
header, and convenient if the IPv6 header fields are mostly  
unnecessary for forwarding within the RPL domain.  On the other hand,  
keeping one layer means you can continue to utilize fields in the IPv6  
header (flow label, hop limit, etc.), re-use whatever hop-by-hop  
options we define, and use ICMPv6 directly (e.g. traceroute just  
works).  On the last point, if we decide to go with an MPLS-like  
header, it might be nice to have something like RFC 4950 as well.   
Also, is there precedent on how record-route would work with labels?

My main concern is going down a path where we have to define two  
different ways of implementing the same mechanisms (loop detection,  
source routing, error reporting, etc.).  I don't have a particular  
view at this point on which way to go, but I would prefer limiting it  
to one branch if at all possible.

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 12 Apr 2010 09:31:39 -0700

--
Jonathan Hui

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 12 Apr 2010 22:17:36 +0200

On Apr 12, 2010, at 17:08, Jonathan Hui wrote:

> Inserting a layer below IPv6

Does it have to be a whole layer?  (We might as well do a real meshing protocol then...)
The prepended shim header might work together with the IPv6 header, e.g., use its hop limit, and possibly even other IPv6 fields (including hop-by-hop options that are closer to the usual IPv6 ones, even though I don't know what those would be).

Another way to think about this: as a way to "header-compress" the IPv6 hbh option...

The disadvantage is that we need a stack of "Y over X" documents, where Y is this new shim thing and X are the L2s we want to use.

Gruesse, Carsten

---

From: [email-masked]
Date: Mon, 12 Apr 2010 20:26:35 +0000

Lets try try not to create stacks of y over x documents.  

Don
Sent via BlackBerry from T-Mobile

-----Original Message-----
From: Carsten Bormann <[email-masked]>
Date: Mon, 12 Apr 2010 22:17:36 
To: Jonathan Hui<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Subject: Re: [Roll] Proposal for Source Routing
	HeaderFormatand	SourceRoutingOperations

Gruesse, Carsten

---

From: JP Vasseur <[email-masked]>
Date: Thu, 15 Apr 2010 14:26:20 +0200

Hi Don,

> 1)       ROLL cannot meet its charter without source routing

Absolutely.

> 2)       Claiming the feature is now to be addressed in 6LowPAN  
> seems a bit wrong.  ROLL has as its scope MAC/PHYs other than IEEE  
> 802.15.4.

You are absolutely right. IPHC is 15.4 specific. This is why the idea  
of using a Label a la MPLS would be an interesting approach IMO. The  
labe could be locall significant using DAO as a label distribution  
mechanism. Completely link layer agnostic.

JP.

> How are those addressed?
> which would include IPv6 extension headers such as RH0. Whatever  
> ends up getting used for source routing needs to be some sort of  
> IPv6 extension header. Source routing for IPv6 would naturally  
> contain IPv6 addresses. The question is whether we want to invent  
> some new extension header specifically for ROLL which uses something  
> other (i.e. smaller) than IPv6 addresses, e.g. the tag scheme  
> mentioned.
>

---

From: JP Vasseur <[email-masked]>
Date: Thu, 15 Apr 2010 14:28:21 +0200

On Apr 8, 2010, at 5:35 PM, Philip Levis wrote:

> The basic guideline is that ROLL (or WGs in general) shouldn't  
> replicate functionality or mechanisms that already exist, and that  
> given WGs operate within a particular layer of the protocol stack.
>
> In this particular case, the reason why 6lowpan was brought up is  
> the RH0 header. In terms of charter, it's not ROLL's job to specify  
> a way to compress the RH0 header. From ROLL's perspective, there are  
> IPv6 addresses and nothing less. 6lowpan, however, can specify ways  
> in which IPv6 headers are compressed.
>
> Does that make sense?

Not quite. We as a WG first need to agree on how we would like to  
perform source routing (compresed header, labels, ...), we'll figure  
out where it should be done.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 15 Apr 2010 14:29:45 +0200

> use a MAC/PHY independent solution (like tags).

me too (co-chair hat off).

> replicate
> the RH0

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 15 Apr 2010 14:35:16 +0200

Hi JP and all;

I'm not fully clear what the WG group really wants to do at this point.
I sensed an agreement to endorse something very close to IPv6 RH0 in the
core spec, and provide a separate spec that would enable labels in the
Source route DAO and the hop by hop header.

Is that a honest reading of the mailing list?

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of
JP Vasseur
Sent: Thursday, April 15, 2010 2:26 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Roll] Proposal for Source RoutingHeader Format and
SourceRoutingOperations

Hi Don,

Absolutely.

2)       Claiming the feature is now to be addressed in 6LowPAN seems a
bit wrong.  ROLL has as its scope MAC/PHYs other than IEEE 802.15.4.  

You are absolutely right. IPHC is 15.4 specific. This is why the idea of
using a Label a la MPLS would be an interesting approach IMO. The labe
could be locall significant using DAO as a label distribution mechanism.
Completely link layer agnostic.

JP.

How are those addressed?

Don

Hi Don,

<http://tools.ietf.org/html/rfc2460#page-12> . Whatever ends up getting

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

I can't see why 6LowPAN (and specifically the HC draft) would concern
itself
with source routing.

 
Don

-----Original Message-----
 
Rob,

 

 
Daniel.

Robert Cragie wrote:

	Hi Pascal,
	 
	Source routing should of course use the IPv6 addresses which
means a lot 
	of overhead for certain underlying link layers, e.g. 802.15.4. I
think 
	it is generally cleaner to do the compression at a layer which
may 
	require it only, e.g. define it in the 6lowpan HC. This is then
free to 
	some extent to specify how the compression is done. Although I
doubt 
	this would go down well in the 6lowpan WG...
	 
	The tag scheme would work but it specifically scopes the source
routing 
	to nodes which operate the scheme. This is probably acceptable 
	practically but doesn't 'smell right' somehow.
	 
	With regard to the original proposal: it is probably necessary
to carry 
	the full source route all the way to at least the penultimate
node and 
	use an index to show the current position in the route for
potential 
	backtrace and error reporting back along the same route
(assuming link 
	symmetry). This is how RH0 works.
	 
	Robert

	Gridmerge Ltd.
	89 Greenfield Crescent,
	Wakefield, WF4 4WA, UK
	+44 (0) 1924 910888

		Hi Daniel:

		 
		 
		What do you think?
		 
		Pascal

			-----Original Message-----
			From: Popa, Daniel
			 
			Hi Pascal, John,

		L2

			This brings two advantages:
			 - avoid processing each transit packets up to
L3.
			 - use MAC addresses that - in ROLL environment
- have inherently

		shorter

			Cheers,
			Daniel

			-----Original Message-----

		Of

			Hi John:

		though it is

		it is

		downwards

			that should be doable)
			 
			Cheers,
			 
			Pascal

				-----Original Message-----

			Of

				JeongGil Ko (John)
				Sent: Wednesday, April 07, 2010 10:05 PM
				To: ROLL WG
				Subject: [Roll] Proposal for Source
Routing Header Format and Source
				RoutingOperations
				 
				Hi!
				 
				Great to see all this discussions on
downwards route establishment!

		To

			add

				one more to the conversations here is a
proposal for source routing

			headers.

				In non-storing mode (where only the root
has individual path

			information)

				the root will be attaching a source
routing header to the data

		packet

			that a

			make the

				header super fancy but in my opinion I
think we only need two fields

			in this

				header and here it is! Feel free to
break the stuff and mangle with

		it

			so that it

				looks great in the specs later on. FYI,
this is the format that I am

			using in my

			|

				+-+-+-+-+-+-+-+-+

			+

				|                       Source Route
Entry (128*NEntry bits)

			|

				+

			+

				|

			|

				      Figure 1. Proposed Source Routing
Header Format; each line is

		32

			bits:)

				- NEntry: Indicates the number of 128
bit addresses that the source

			route

				entry field is carrying.
				 
				- Source Route Entry: List of 128 bit
address that consist the route

			to the

				destination. Here, the address of the
node that is one hop away from

			the

				 
				When source routing is initiated at a
storing node (e.g., root of

		the

			DODAG),

				the header is attached on the data
packet for the entire route

		(i.e.,

			from

				next hop node to the destination). This
header is positioned in

		front

			of the

				user payload. When the next hop node
receives a packet that is not

			destined

				to itself AND the network is NOT
provisioned to be in 'storing mode'

			then it

				checks NEntry to find what the next hop
is in the source route

		entry.

			Since

				the 'Source Route Entry' is ordered in
'farthest -> closest' (in

		terms

			of hops)

				order, a node can figure out what the
next hop address is with only

			the

				NEntry value (since it already knows how
big an ipv6 address is).

			After

				collecting the next hop node's address,
the node erases this address
				element from the entry and decreases
NEntry by one. This assures

		that

			we

				avoid the overhead of carrying the
entire source route throughout

		the

			data

				path.
				 
				The approach itself should be very
simple and trivial for everyone

		to

			follow.

				Thanks.
				 
				-John
				 
				------
				JeongGil Ko (John)
				Ph.D. Student

---

From: JP Vasseur <[email-masked]>
Date: Thu, 15 Apr 2010 14:36:22 +0200

On Apr 8, 2010, at 8:45 PM, Kris Pister wrote:

>> And note that the idea of using tags/labels is nothing new.

And has proven to be quite efficient.

>> Of course we will adapt the basic mechanism a bit (label  

Even MPLS has different label distribution (LDP, following the IGP  
path - or RSVP-TE for Source routing). That does not even require  
label stacking to establish LSPs.

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 15 Apr 2010 05:48:11 -0700

Hi Pascal,

I believe what you wrote below was the majority view on the reflector.

Don

From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
Sent: Thursday, April 15, 2010 5:35 AM
To: JP Vasseur; [email-masked]
Cc: [email-masked]
Subject: RE: [Roll] Proposal for Source RoutingHeader Format and
SourceRoutingOperations

Hi JP and all;

I'm not fully clear what the WG group really wants to do at this point. I
sensed an agreement to endorse something very close to IPv6 RH0 in the core
spec, and provide a separate spec that would enable labels in the Source
route DAO and the hop by hop header.

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of JP
Vasseur
Sent: Thursday, April 15, 2010 2:26 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Roll] Proposal for Source RoutingHeader Format and
SourceRoutingOperations

Hi Don,

Absolutely.

2)       Claiming the feature is now to be addressed in 6LowPAN seems a bit
wrong.  ROLL has as its scope MAC/PHYs other than IEEE 802.15.4.  

You are absolutely right. IPHC is 15.4 specific. This is why the idea of
using a Label a la MPLS would be an interesting approach IMO. The labe could
be locall significant using DAO as a label distribution mechanism.
Completely link layer agnostic.

JP.

How are those addressed?

Don

Hi Don,

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

 

Don

-----Original Message-----
 
Rob,

 
 
Daniel.

Robert Cragie wrote:

Hi Pascal,

 
 
Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

Hi Daniel:

 
 
What do you think?
 
Pascal

-----Original Message-----
From: Popa, Daniel [mailto:[email-masked]]
Sent: Thursday, April 08, 2010 11:40 AM
To: ROLL WG
Cc: Pascal Thubert (pthubert); JeongGil Ko (John)
Subject: RE: [Roll] Proposal for Source Routing Header Format and
SourceRoutingOperations
 
Hi Pascal, John,

L2

shorter

Cheers,
Daniel

-----Original Message-----

Of

Hi John:

though it is

it is

downwards

that should be doable)
 
Cheers,
 
Pascal

-----Original Message-----

Of

JeongGil Ko (John)
 
Hi!

To

add

headers.

information)

packet

that a

make the

in this

it

so that it

using in my

 

|

+-+-+-+-+-+-+-+-+

+

|

+

+

|

|

32

bits:)

route

entry field is carrying.

to the

the

 

the

DODAG),

(i.e.,

from

front

of the

destined

then it

entry.

Since

terms

of hops)

the

After

that

we

the

data

path.

to

follow.

Thanks.
 
-John
 
------
JeongGil Ko (John)
Ph.D. Student

---

From: JP Vasseur <[email-masked]>
Date: Thu, 15 Apr 2010 14:48:13 +0200

Sitll co-chair hat off

> compact identifier for the next hop.

Agreed

> - For a source routing header, I'd much rather see something derived  

Agreed

> why labels are used in traditional IP networks today.

TO be accurate this is for VPN too ;-) with stacked labels. But you  
are correct that one can use labels to build Label Switch Paths (LSP),  
with potentially different objectives (traffic engineering).

> Of course, it means that you will have to maintain multiple tags for  
> the same destination.  And if you're directly mapping the full  
> 802.15.4 short address space into the tag space, then you have to be  
> more careful about managing the mapping (e.g. make sure short  
> addresses can be encoded within 14 or 15 bits).  Alternatively,  
> maybe 16 bits is not enough for what you want to do.  In the end,  
> I'm not sure we want to explicitly reserve bits for indicating a  
> service level rather than simply keeping a flat tag namespace.

This is also what I would recommend.

> The use case should define what to do with the bits.
>
> --
> Jonathan Hui
>
>> as the packet progresses. For RPL, it means that a node uses as  
>> would this be? Would we need to specify a LOWPAN_NHC value for this  
>> RPL-specific information.  6lowpan-hc already has a LOWPAN_NHC

---

From: JP Vasseur <[email-masked]>
Date: Thu, 15 Apr 2010 14:49:30 +0200

Hi Daniel,

On Apr 9, 2010, at 6:01 PM, Popa, Daniel wrote:

> DP1: Let assume we have X bits for control. The problem with a short  
> tag is that it burdens the management of mapping Link Layer  
> addresses larger 16 bits into a (16-X)-bit field.
> DP2: It will be quite mission impossible to chose the right length  
> for the "Tag Value" field. And I agree a too large tag decreases the  
> reason of having tags.
>
> DP3: I'm not necessarily in favor of having tags with different  
> sizes within the same network. I'm rather in favor of having the  
> flexibility to chose the size of the label that meets the network  
> design objectives. There were discussions about 802.15.4 address  
> space but there can be many other scenarios that might adopt ROLL,  
> where the Link Layer addressing is different from 802.15.4 MAC  
> addressing. So, having the possibility to chose for your network the  
> size of the label is a "nice to have" feature.

But supporting multiple PHY/MAC does not imply that you need different  
label sizes ?

JP.

> DP: For this reason is nice to have 1 or 2 bits for service level  
> within the tag, to avoid burdening nodes by maintaining multiple  
> tags for the same destination.
> -- 
>

---

From: JP Vasseur <[email-masked]>
Date: Thu, 15 Apr 2010 15:00:30 +0200

Also my reading (again, co-chair hat off).

On Apr 15, 2010, at 2:48 PM, Don Sturek wrote:

> I’m not fully clear what the WG group really wants to do at this  
> point. I sensed an agreement to endorse something very close to IPv6  
> RH0 in the core spec, and provide a separate spec that would enable  
> labels in the Source route DAO and the hop by hop header.
>
> Of JP Vasseur
> You are absolutely right. IPHC is 15.4 specific. This is why the  
> idea of using a Label a la MPLS would be an interesting approach  
> IMO. The labe could be locall significant using DAO as a label  
> distribution mechanism. Completely link layer agnostic.
>
> JP.
>
>
> How are those addressed?
>
> Don
>
>

---

From: "Popa, Daniel" <[email-masked]>
Date: Thu, 15 Apr 2010 09:42:13 -0400

Hi JP, 

> From: JP Vasseur [mailto:[email-masked]]
> Sent: Thursday, April 15, 2010 2:50 PM
> To: Popa, Daniel
> Cc: Jonathan Hui; [email-masked]

[<DP>] You are right: My proposal is to have the possibility to define a scope for the label/tag and choose its size as a function of its scope (global, local, site, etc) and network design objectives. It makes tagging/labeling more powerful when mapping different Link Layer addressing scheme into label/tags. 

 Daniel

> get

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 15 Apr 2010 17:10:57 +0200

> Also my reading (again, co-chair hat off).

I am not sure why you need routing headers, flow labels, hbh.

The routing protocols I know of rarely if ever employ any of these.  (DSR?).

Why don't you (RPL designers) go simply with the ICMP extensions?

I really do not see why a Routing Header is needed for RPL.

(sounds to me like we have a set of hammers available: RH, HbH, Flow
  Labels, MPLS and we're looking for nails.)

Alex

Le 15/04/2010 15:00, JP Vasseur a écrit :
>> *Sent:* Thursday, April 15, 2010 5:35 AM
>> *To:* JP Vasseur; [email-masked] <mailto:[email-masked]>
>> *Cc:* [email-masked] <mailto:[email-masked]>
>> *Subject:* RE: [Roll] Proposal for Source RoutingHeader Format and
>> SourceRoutingOperations
>> Hi JP and all;
>> *From:* [email-masked] <mailto:[email-masked]>
>> [mailto:[email-masked]] *On Behalf Of *JP Vasseur
>> *Sent:* Thursday, April 15, 2010 2:26 PM
>> *To:* [email-masked] <mailto:[email-masked]>
>> *Cc:* [email-masked] <mailto:[email-masked]>
>> *Subject:* Re: [Roll] Proposal for Source RoutingHeader Format and
>> SourceRoutingOperations
>> Hi Don,
>> *To:* [email-masked] <mailto:[email-masked]>
>> *Cc:* [email-masked] <mailto:[email-masked]>;
>> [email-masked] <mailto:[email-masked]>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 15 Apr 2010 17:15:07 +0200

[...]

>>> 1) ROLL cannot meet its charter without source routing

(You will excuse me but I don't know who precisely am I talking to about 
this particular point.)

What particular point in the ROLL Charter makes RPL need Routing 
Headers?  I don't seem to find any.

What do you agree about?

Alex

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 15 Apr 2010 08:22:48 -0700

Hi Alex,

This thread confirms the need, for non-storing ROLL RPL devices, in
supplying source routing from the DAG root to devices in the DAG.

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alexandru Petrescu
Sent: Thursday, April 15, 2010 8:15 AM
To: [email-masked]
Subject: Re: [Roll] Proposal for Source RoutingHeader Format and
SourceRoutingOperations

What do you agree about?

Alex

itself
>> From:[email-masked]  <mailto:[email-masked]>
[mailto:[email-masked]] On Behalf Of
think
routing
Internet 0
define in a
hide a
looks like
can make
to store
index of
and
based)
inherently
and
recoverable, and
used
>>                 From:[email-masked]
<mailto:[email-masked]>  [mailto:[email-masked]] On Behalf
establishment!
source routing
path
can always
mangle with
format that I am
Format; each line is
the source
consist the route
hop away from
route
positioned in
that is not
'storing mode'
route
closest' (in
address is).
this address
assures
throughout
everyone

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 15 Apr 2010 17:36:29 +0200

Le 15/04/2010 17:22, Don Sturek a écrit :
> Hi Alex,
>
> This thread confirms the need, for non-storing ROLL RPL devices,

Non-storing means they do not store routing tables?

If they don't then do we talk IP at all here?  (IP routers w/o routing
tables?)

Routing Headers wouldn't work in the absence of Routing Table entries
either.

I do not see the conceptual link between non-storing devices and the
necessity of Routing Headers.

But not sure whydo we need here RHs.  Simply non-storing is not a reason
I can understand quickly.

Alex
PS: If needed, I can explain the way I understand the reason why the use
of RH was proposed in the context of nesting moving networks - mainly
because all came with their built-in addresses already
preassigned and thus tunnels were everywhere too thick - so RHs were
preferred instead.  But here - how are the addresses?

> in supplying source routing from the DAG root to devices in the DAG.
>
> Don
>
>
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu Sent:
> Thursday, April 15, 2010 8:15 AM To: [email-masked] Subject: Re:
> [Roll] Proposal for Source RoutingHeader Format and
> SourceRoutingOperations
>
> Le 15/04/2010 15:00, JP Vasseur a écrit : [...]
>
> (You will excuse me but I don't know who precisely am I talking to
> about this particular point.)
>
>>> 2) Claiming the feature is now to be addressed in 6LowPAN seems
>>> a bit wrong. ROLL has as its scope MAC/PHYs other than IEEE
>>> 802.15.4. You are absolutely right. IPHC is 15.4 specific. This
>>> is why the idea of using a Label a la MPLS would be an
>>> interesting approach IMO. The labe could be locall significant
>>> using DAO as a label distribution mechanism. Completely link
>>> layer agnostic. JP.
>>>
>>> How are those addressed? Don *From:* Robert Cragie
>>> [mailto:[email-masked]] *Sent:* Thursday, April 08,
>>> 2010 7:52 AM *To:* [email-masked]<mailto:[email-masked]>
>>> *Cc:*
>>> [email-masked]<mailto:[email-masked]>;
>>> [email-masked]<mailto:[email-masked]> *Subject:* Re: [Roll]
>>> Proposal for Source Routing Header Format and
>>> SourceRoutingOperations Hi Don,
>>>
>>> routing, it is concerning itself with efficient header
>>> compression, which would include IPv6 extension headers such as
>>> RH0 <http://tools.ietf.org/html/rfc2460#page-12>. Whatever ends
>>> up getting used for source routing needs to be some sort of IPv6
>>> extension header. Source routing for IPv6 would naturally contain
>>> IPv6 addresses. The question is whether we want to invent some
>>> new extension header specifically for ROLL which uses something
>>> Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK
>>> +44 (0) 1924 910888
>>> On 08/04/2010 2:35 PM, Don Sturek wrote: I can't see why 6LowPAN
>>> (and specifically the HC draft) would concern
> itself
>>> with source routing.
>>>
>>> I don't see how ROLL completes its charter or addresses its
>>> requirements without adding source routing.
>>>
>>> Don
>>>
>>>
>>> From:[email-masked]<mailto:[email-masked]>
>>> Daniel Gavelle Sent: Thursday, April 08, 2010 6:12 AM
>>> To:[email-masked]<mailto:[email-masked]>
>>>
>>>
>>>
>>>
>>>
Cc:[email-masked]<mailto:[email-masked]>
>>> I agree that the source routing for the data frames should be
>>> done as part of the 6LowPAN HC.    This already has a stateful
>>> IPV6 address compression based on contexts.    It should be
>>> possible to compress the addresses down to two bytes per address
>>> if IPv6 addresses are derived from the 16 bit short address are
>>> being used in the LowPAN.
>>>
>>> We don't want to hold up the current HC draft that is going
>>> through last call but the work could be done as a new RFC /
>>> amendment.    Source routing compression may need a fix for the
>>> problem of HC compression extending beyond the first fragment.
>>>
>>> Doing the work in the 6LowPAN group means that the compression
>>> can easily be used for any source routing protocol, not just
>>> ROLL.    It
> could
>>> be done as a compression for the existing R0 routing header.
>>> Maybe
> this
>>> means a
> lot
>>> free
> carry
>>> node
>>> (assuming
> link
>>> a
> pure
>>> small
>>> From:[email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>
>>>
>>> [email-masked]<mailto:[email-masked]>
>>>
>>> [email-masked]<mailto:[email-masked]>
>>>
>>>
>>> Roll mailing list
>>>
>>> [email-masked]<mailto:[email-masked]>
>>>
>>> _______________________________________________ Roll mailing list
>>> [email-masked]<mailto:[email-masked]>
>> _______________________________________________ Roll mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>
>
> _______________________________________________ Roll mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>
>