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

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

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 09:41:12 -0800

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]