Subject: [Roll] downward routing?

From: Thomas Herbst <[email-masked]>
Date: Wed, 12 May 2010 16:39:06 -0700

Haven't seen anything on this for almost a month. 

Is there progress on some flavor of hop-by-hop or source routing downward from the DAG Root?

RH0 going once, going twice...?

Tom

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

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

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

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

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.
 
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,
 
On Apr 8, 2010, at 4:59 PM, Don Sturek wrote:
 
I think the issue is this:
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?
 
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. 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
Robert Cragie (Pacific Gas & Electric)
Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com

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.
 
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,
 
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:
  
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:
    
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.
 
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:
 
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 :)
 
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
 
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

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

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

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

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

---

From: JP Vasseur <[email-masked]>
Date: Fri, 14 May 2010 19:24:33 +0200

Hi Tom,

> downward from the DAG Root?

Routing from the root is already supported thanks to the DAO as you  
know (by the way, the new agreed
DAO mechanism will be incorporated with the coming rev-08 (along with  
Security, P2P, ...)). As far as
source routing is concerned, this is also an item for rev08.

> RH0 going once, going twice...?

Right, since deprecated, it will more than like be a RH0-like, opened  
ticket is #35.

Thanks.

JP.

> Of JP Vasseur
> 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
> 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
>
>
> 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. 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 don't see how ROLL completes its charter or addresses its  
> requirements without adding source routing.
>
> Don
>
>
> Of Daniel Gavelle
> 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:
>
> 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
>
> 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
>
>
>
>
> Since source routing explicitly gives forwarding instruction to each  
> intermediate node, it can make sense to use only (MAC address based)
>
>
> L2
>
>
> 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
>
>
> 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
>
>

---

From: JP Vasseur <[email-masked]>
Date: Sun, 23 May 2010 10:52:12 +0200

Hi Tom,

> RH0 going once, going twice...?

VERY close, stay tuned Jonathan and David are working on an ID to be  
shared with the WG very soon.

Thanks for your feed-back.

JP.