Subject: Re: [6lowpan] Fw: any comments on the proposal from Arch Rock

From: gabriel montenegro <[email-masked]>
Date: Sun, 5 Nov 2006 10:45:34 -0800 (PST)

Each fragment is routed independently of each other by virtue of the mesh header, right?
Each node forwards each individual fragment according to its routing table, exactly the same
as for any unfragmented packet, so there is no additional state for fragments as compared to
non-fragments. The only node that keeps fragments around for reassembly is the end-node, as it
is an e2e reassembly procedure (as in IPv6).

What you're pointing out, I think, is not a lack of extensibility per se, but a lack of
support for source routing at the mesh header, which was a conscious decision, yes. 

Adding support for source routing does not require one to carry the prot_type field in
each fragment. It would require modifying the mesh delivery header to include source routes,
not just mesh origin and mesh destination address. 

I now see that you're doing this a bit differently. Instead of the lowpan adaptation layer
handling source routes, you wish to handle it as different protocol itself. 

-gabriel

----- Original Message ----
From: Jonathan Hui <[email-masked]>
To: gabriel montenegro <[email-masked]>
Cc: [email-masked]
Sent: Sunday, November 5, 2006 9:41:12 AM
Subject: Re: [6lowpan] Fw: any comments on the proposal from Arch Rock

Gabriel,

You are correct that you can use prot_type to allow extensibility above 
both the mesh and fragmentation layer. However, I was trying to get at 
extensibility at layers between the mesh and fragmentation. IPv6 
suggests that hop-by-hop options (e.g. a sequence number for 
broadcast/multicast) and routing headers (for source route) should come 
after addressing but before fragmentation. If these hop-by-hop/routing 
headers help determine how a packet is routed, then this allows 
individual fragments to be routed without having to do any form a 
reassembly at each hop and without requiring nodes to keep state for a 
stream of IP packet fragments. This advantage could be especially useful 
for mesh networks with memory constrained devices. It was unclear to us 
how you would support such functionality cleanly in the current 6lowpan 
format because the prot_type field turns into the datagram_offset field 
in subsequent fragments.

Does that clear things up a bit?

--
Jonathan Hui
[email-masked]

gabriel montenegro wrote:
> Jonathan,
>  
> 
> I'm confused by your paragraph below. I'm not sure what you mean by
> this. The prot_type field disappearing in subsequent packets has no
> bearing on extensibility as I understand it. For example, if you were
> to in the future decide to carry, say, RNP ("random network protocol")
> over the current lowpan encapsulation, you'd have a prot_type value
> assigned for RNP. This would allow you to send RNP over lowpan even if
> you had a mesh configuration underneath (the mesh delivery header being
> a general lowpan layer service), or if your RNP packets were large
> (by using the fragmentation service, again a general lowpan layer
> service). If a receiving station were to receive, say, a fragment
> for an packet, it might not be able to know that it is RNP until
> more fragments arrive. But it wouldn't be able to do anything until
> the entire RNP packet arrives anyways. Just like in IPv4 or v6 
> fragmentation.
>  
> Or did you have something else in mind?
>  
> tnx,
>  
> -gabriel
> ----- Original Message ----
> In the current 6lowpan proposal, the prot_type field disappears in
> packets that are subsequent fragments. Thus, the prot_type field in the
> current proposal only allows extensibility in upper layer protocols and
> possibly in packets that do not require fragmentation. In the current
> 6lowpan proposal it wasn't clear to us how a new mesh protocol that
> wanted to add a field to the header would do so in a clean way. Also,
> what we were trying to convey with the "piggybacking" capability with
> the stacked headers was that it was possible, not that we should promote
> it.

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

---

From: Jonathan Hui <[email-masked]>
Date: Sun, 05 Nov 2006 12:45:50 -0800

What I'm arguing is that there are times where only addressing is not 
enough. This was made clear by the addition of the B-bit in the 6lowpan 
adaptation header, which required changing the 6lowpan adaptation header 
for subsequent fragments because there were no additional reserved bits. 
My argument is that the current adaptation header is relatively 
unforgiving if for some unforseen reason that the 8-bit additional field 
given by setting the B-bit is not enough. Specifically for 
broadcast/multicast protocols, it restricts them to using an 8-bit field 
for whatever extra information they might need. I'm not comfortable with 
making such a bold statement, maybe others are. But once the 6lowpan 
header format has been standardized and adopted widely, it becomes very 
difficult for us to simply modify the header again. In my view, having 
the ability to specify header stacks provides a clean way of extending 
the header, whether or not you view the entire header stack as an 
adaptation header or as a set of separate protocols below the IP layer.

--
Jonathan Hui
[email-masked]