Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-hc-01

From: Jonathan Hui <[email-masked]>
Date: Wed, 8 Oct 2008 19:20:51 -0700

http://tools.ietf.org/html/draft-ietf-6lowpan-hc

This new version reflects the recent discussions on the list. The  
changes are:
- HC back to 1 byte by default by stealing a few bits from the  
dispatch field.
- Added better support for multicast address compression.
- Fixed alignment for UDP port compression.
- Better support for Traffic Class and Flow Label compression.
- Pascal joined as an author.

Happy reading!

--
Jonathan Hui

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: October 8, 2008 7:15:35 PM PDT
> To: [email-masked]
> Cc: [email-masked]
> Subject: New Version Notification for draft-ietf-6lowpan-hc-01
>
>
> A new version of I-D, draft-ietf-6lowpan-hc-01.txt has been  
> successfuly submitted by Jonathan Hui and posted to the IETF  
> repository.
>
> Filename:	 draft-ietf-6lowpan-hc
> Revision:	 01
> Title:		 Compression Format for IPv6 Datagrams in 6LoWPAN Networks
> Creation_date:	 2008-10-09
> WG ID:		 6lowpan
> Number_of_pages: 15
>
> Abstract:
> This document specifies an IPv6 header compression format for IPv6
> packet delivery in 6LoWPAN networks.  The compression format relies
> on shared context to allow compression of arbitrary prefixes.  This
> document specifies compression of multicast addresses and a framework
> for compressing next headers.  This framework specifies UDP
> compression and is prepared for additional transports.
>
>
>
> The IETF Secretariat.
>
>

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

---

From: Zach Shelby <[email-masked]>
Date: Fri, 10 Oct 2008 15:58:24 +0300

Hi,

Here are my comments on hc-01. Overall I think we are quite close with 
the comments from Pascal and Julien.

I found the DDF name confusing. Now it has been renamed CTX in the 
latest formats on the list, great.

As Pascal pointed out, nodes need to be able to decode all these 
options. One thing that worries me in having 16 contexts, is that nodes 
are forced to store them all. That is worst case 272 bytes of memory 
consumption. Worth it? Is it possible that an ultra-simple node would 
only have to understand the default context?

The default context identifier '0000' could be clarified more in the 
draft. When CTX is '10' then the default context identifier '0000' is 
used. It should be made clear that this is the prefix advertised in RAs 
as useable for SAA.

Regarding the ND for 6lowpan draft, HC-01 means we need to add a 4-bit 
context identifier flag to the 6LoWPAN Prefix Information Option. To 
make things clear that should always be '0000' if the A flag is '1'?

- Zach

Jonathan Hui wrote:
> - HC back to 1 byte by default by stealing a few bits from the dispatch 
> field.
>> successfuly submitted by Jonathan Hui and posted to the IETF repository.
>>

-- 

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti
FINLAND

mobile: +358 40 7796297

This e-mail and all attached material are confidential and may contain 
legally privileged information. If you are not the intended recipient, 
please contact the sender and delete the e-mail from your system without 
producing, distributing or retaining copies thereof.
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 10 Oct 2008 09:11:18 -0700

Hi Zach,

On Oct 10, 2008, at 5:58 AM, Zach Shelby wrote:
> Here are my comments on hc-01. Overall I think we are quite close  
> with the comments from Pascal and Julien.
>
> options. One thing that worries me in having 16 contexts, is that  
> nodes are forced to store them all. That is worst case 272 bytes of  
> memory consumption. Worth it? Is it possible that an ultra-simple  
> node would only have to understand the default context?

[jhui] The number of contexts is an issue I raised on the list a few  
weeks ago. Many seemed to think that two contexts was okay. However, I  
wanted us to be sure that 2 was enough and as a result there was no  
change in the number of contexts from hc-00 to hc-01. With an extra  
bit (13 bits total) we can certainly support 2 contexts without a  
context identifier extension. With two extra bits (14 bits) we can  
support 3 contexts. Any more would require an extra byte, I think. Of  
course, we can stick with the current encoding but we can limit use to  
X < 16 contexts. What do people think?

> draft. When CTX is '10' then the default context identifier '0000'  
> is used. It should be made clear that this is the prefix advertised  
> in RAs as useable for SAA.
>
>
> Regarding the ND for 6lowpan draft, HC-01 means we need to add a 4- 
> bit context identifier flag to the 6LoWPAN Prefix Information  
> Option. To make things clear that should always be '0000' if the A  
> flag is '1'?

[jhui] Those that are arguing for more than 2 contexts see it useful  
for renumbering. If that is the case, then SAA must have the  
flexibility for use with contexts other than the default. For now, I  
think it's best to consider having a context identifier included with  
the 6LoWPAN Prefix Information Option.

--
Jonathan Hui

> This e-mail and all attached material are confidential and may  
> contain legally privileged information. If you are not the intended  
> recipient, please contact the sender and delete the e-mail from your  
> system without producing, distributing or retaining copies thereof.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 10 Oct 2008 19:02:27 +0200

Hi Jonathan and Zach;

That's again my bad wording I guess; We can have up to 16 contexts both
directions. Does not mean that all deployments will use 16 context. For
a given deployment, there might be 3 of each. In that deployment, all
nodes are required to allocate memory for 3. Some nodes might be
physically incapable to join a network that requires more contexts than
they can allocate.

Is that acceptable? 

I like Zach's proposal to make the additional context fully optional
(for nodes not routers). But then, the source must know that the
destination does not support it, and we need to describe that.

Then again, I see that the spec needs edition to be clearer but not a
change in the formats. What do you think?

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jonathan Hui
>Sent: vendredi 10 octobre 2008 18:11
>To: Zach Shelby
>Cc: 6lowpan
>Subject: Re: [6lowpan] Fwd: New Version Notification
fordraft-ietf-6lowpan-hc-01

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 10 Oct 2008 10:27:20 -0700

Hi Pascal:

> physically incapable to join a network that requires more contexts  

[jhui] My initial inclination is that this would be a bad idea for the  
market in general. Doing this would essentially create nodes  
(specifically, routers in a route-over configuration) that have  
different capability levels and nodes that are less capable will not  
be able to join those that use extra capabilities. However, it does  
offer more flexibility to implementors on the kinds of networks they  
want to support. WiFi had it easy because APs and clients are in  
direct contact with each other.

> destination does not support it, and we need to describe that.

[jhui] I think this is workable (more so in a mesh-under configuration  
than a route-over one). The definition of "source" could be a bit  
loose - essentially a node along the path could reformat the header to  
something consumable by the destination.

> change in the formats. What do you think?

[jhui] Agree.

--
JOnathan Hui

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Mon, 13 Oct 2008 10:24:18 +0200

Hi Zach, 

I second your concern

There was recently a discussion specifically about the number of
contexts needed.
There seemed to be a consensus that multiple contexts was useful for
renumbering only, which is rare, and that 2 contexts was enough. 
Was there new input since then which justifies the use of 4-bit
contexts?

Cheers,
Julien 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Zach Shelby
Sent: vendredi 10 octobre 2008 14:58
To: Jonathan Hui
Cc: 6lowpan
Subject: Re: [6lowpan] Fwd: New Version Notification
fordraft-ietf-6lowpan-hc-01

Hi,

- Zach

repository.

-- 

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti
FINLAND

mobile: +358 40 7796297

---

From: Zach Shelby <[email-masked]>
Date: Mon, 13 Oct 2008 12:14:09 +0300

Hi,

I don't think the consensus changed from that 2 contexts is enough.. it 
was just mentioned that with more someone may figure out what to do with 
them (renumbering). If renumbering is the only case for having a 4-bit 
context identifier, then I recommend Jonathan tries to integrate a short 
1-2 bit context identifier into the base format as he mentioned is 
possible, thus avoiding the 1 byte extension for 4-bit identifiers. 2-4 
contexts will be plenty, and thus we wouldn't be using memory on all 
nodes, or having to deal with some nodes supporting 16 and some 
supporting 2. Considering that we have only a link-local context in 
RFC4944, having 2-4 global contexts is already a huge improvement!

So I would give like to see 1-2 context ID bits for source/dest in the 
base header, as a priority over supporting a large range of multicast 
address types.

- Zach

-- 

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti
FINLAND

mobile: +358 40 7796297

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 13 Oct 2008 12:15:52 +0200

Hi Zach:

The 2 bits were integrated in HC when we passed the HC to 2 bytes (that
was hc_00). With hc_01, we are back to one byte and not too ready to
bounce again. I mean, there are many things we could do with more bits
in HC but then we're loosing the value of compression in the first
place.

Since most times the default context is the right one, we decided to
handle the exception by putting the context information in an optional
byte that should "almost" never by there if the context is used for
renumbering only. 

At that point we have that additional byte, we can shoot for 16 contexts
both directions. This might not be the best use of that byte, and we
should discuss that furthermore. But a context might not be limited to a
prefix. We can use a context to (state)fully compress an address like
the address of an edge router. One byte against 8 or 16 per packet might
be worth an entry in memory.

Now you made it very clear that not all nodes can support 16 many
contexts. Fine. We need to work on how the option is really optional,
and how a node may not have to support all contexts. OTOH, the consensus
on 2 contexts had to do with the cost in bits in every packet. Now we
moved to a cost that is only paid by exceptional packets, 16 MAX might
become a good value after all.

I think that all this requires more thoughts. Once we really understand
what we do with contexts and what the cost is per type of context entry,
then we can figure out what the right value is, and whether all entries
are globally significant or not.

What do you think?

Pascal

Behalf Of Zach Shelby
>Sent: lundi 13 octobre 2008 11:14
>To: Julien Abeille (jabeille)
>Cc: 6lowpan
>Subject: Re: [6lowpan] Fwd: New Version
Notificationfordraft-ietf-6lowpan-hc-01
>> Here are my comments on hc-01. Overall I think we are quite close
with
>> options. One thing that worries me in having 16 contexts, is that
nodes

---

From: Zach Shelby <[email-masked]>
Date: Mon, 13 Oct 2008 13:52:30 +0300

Hi,

True, in general I am with you here. And I agree that the base format 
should be as compact and simple as possible. I am OK keeping it as is, 
as long as we can make it optional for hosts as below.

> in HC but then we're loosing the value of compression in the first

I also don't want 2 bytes again. I understood that the dispatch space 
could be used for that, but I also think we should be careful using too 
much of that.

> be worth an entry in memory.

I have no problem with the use of the 2nd byte in the current HC-01.

> become a good value after all.

We just need to find a way to make it optional as you pointed out. If we 
can do that, then I am happy. 16 is a fine number, as long as a simple 
host can get by with just understanding and using the default. It might 
be as simple as this:

"6LoWPAN Hosts may choose to make use of the optional 4-bit context IDs 
. A Host must support the default context ID. 6LoWPAN Routers must 
support 4-bit context IDs."

As a simple Host will only receive incoming packets to it using the 
stateless options or global default prefix. A simple host can also 
choose to use only the default context when sending packets. Therefore 
it doesn't have to care about the optional 4-bit context IDs at all.

-- 

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti
FINLAND

mobile: +358 40 7796297

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 13 Oct 2008 08:36:08 -0700

Hi Julien,

So here's the tension that we have now: From what I saw on the list,  
most people were happy with just two contexts. Adding support to the  
*base* encoding (i.e. without need of using a context identifier  
extension) would require adding yet another bit to the base encoding.  
This is in addition to whatever bits we may add depending on whether  
you convince us of those additional cases :-)

Regarding 8 bits to encode address compression, I agree with Pascal in  
that you should compare against what is in ietf-6lowpan-hc-01 (6  
bits). If we find need in supporting your cases, then we should  
compare to what I sent out to the mailing list (7 bits). I think the 7- 
bit version covers all the cases you were asking for, but maybe I  
missed some? Anyways, looking forward to see your 8-bit proposal.

Thanks.

--
Jonathan Hui

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 13 Oct 2008 20:18:24 +0200

On Oct 13 2008, at 17:36, Jonathan Hui wrote:

> most people were happy with just two contexts

Let me just point out that in the example I sent to the list on Jul  
31, I used contexts for both the prefix of the 6lowpan and for  
prefixes of the main correspondent network.  If you add the need for  
state transitions (renumbering, other reconfigurations), two seems low.

I wouldn't mind an update of this example for HC-01.

Gruesse, Carsten

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Mon, 13 Oct 2008 20:41:15 +0200

Hi Jonathan, all,

Sorry for the long email, tell me if not clear:

*******************************************************
I agree with the status and the three possibilities:
- 6 bits, most important cases compressed
- 7 bits, all cases I mentionned compressed
- 8 bits, all cases I mentionned compressed, simpler? 

Time I propose something for 8-bits as you say :-) : 
*****************************************************
8 bit proposal:
*****************************************************
- about contexts: 3 contexts stored, LL context (00), global prefix
context 1 (01), global prefix context 2 (10, used for renumbering)
- encoding:
| SAC | SAM | DAC | DAM |, 2 bits each, as in initial draft.

- meaning
SAC:
00 context 00
01 context 01
10 context 10
11 no context

SAM:
If SAC = 00, 01, 10 prefix fetched from context number "SAC"
  00 64 bits compressed
  01 16 bits compressed
  10 0 bits compressed
If SAC = 11
  00: unspecified
  01: 128 bits inline

DAC:
00 context 00
01 context 01
10 context 10
11 no context

DAM:
If DAC = 00, 01, 10 prefix fetched from context number "DAC"
  00 unicast 64 bits compressed
  01 unicast 16 bits compressed
  10 unicast 0 bits compressed
  11 multicast unicast prefix based FFxx::xxxx:plen:prefix:xxxx:xxxx
If DAC = 11
  00: 128 bits
  01: FF02::xx
  10: FF0x::00xx:xxxx
  11: FF0x::00xx:xxxx:xxxx

******************************************
Comparison of 7 -bit and 8- bit is attached as csv, should open ok in
Excel
******************************************
instead of pseudo code, I do the following: 
- list all cases supported for src and dest formats (A to E for src, 1
to 9 for dest)
- tell which combination of both are possible (e.g. A1, A2 ... Because
not all combinations are accepted by IP)
- for each combination, tell values of CTX and M bit for 7-bit, SAC,
SAM, DAC DAM for 8-bit. I group the 64/16/0 IID cases to be more
concise. 
i.e. for src link local unicast and dest link local unicast  CTX 00, M 0
- based on this, for each src and dest case splitted again, I give
values of CTX, M
i.e. if dest is FF0X::00XX:XXXX, CTX is ...

What you can see:
- with 8 bit, each individual case (A, B,... For src and 1,2... For dest
) corresponds to a unique value of SAC, SAM...
- with 7 bits, some src cases corresponds to multiple values because
they depend on the dest case, and vice versa
For me, merging src and dest context add a lot of complexity.

******************************************
Comparison of 6-bit and 8- bit 
******************************************
I does not make a lot of sense on the complexity side, as they do not
provide the same features.
However, the binding between src and dest context in the 6 bit case
creates the same problem as with 7 bit

Cheers,
Julien

-----Original Message-----
From: Jonathan Hui [mailto:[email-masked]] 
Sent: lundi 13 octobre 2008 17:36
To: Julien Abeille (jabeille)
Cc: Zach Shelby; 6lowpan
Subject: Re: [6lowpan] Fwd: New Version Notification

Hi Julien,

So here's the tension that we have now: From what I saw on the list,
most people were happy with just two contexts. Adding support to the
*base* encoding (i.e. without need of using a context identifier
extension) would require adding yet another bit to the base encoding.  
This is in addition to whatever bits we may add depending on whether you
convince us of those additional cases :-)

Regarding 8 bits to encode address compression, I agree with Pascal in
that you should compare against what is in ietf-6lowpan-hc-01 (6 bits).
If we find need in supporting your cases, then we should compare to what
I sent out to the mailing list (7 bits). I think the 7- bit version
covers all the cases you were asking for, but maybe I missed some?
Anyways, looking forward to see your 8-bit proposal.

Thanks.

--
Jonathan Hui

> memory consumption. Worth it? Is it possible that an ultra-simple node

> would only have to understand the default context?
>
> used. It should be made clear that this is the prefix advertised in 
> RAs as useable for SAA.
>

> please contact the sender and delete the e-mail from your system 
> without producing, distributing or retaining copies thereof.

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 13 Oct 2008 11:56:03 -0700

Hi Julien, everyone:

Thanks for spelling this out in detail. This is exactly what I had in  
mind when I said we could support 2 contexts in the base encoding by  
adding another bit (going from 7 to 8). So you've saved me a bunch of  
work in showing how that could be done. I agree with you in all the  
points.

So the real questions have been raised on the list. Unfortunately,  
they are less technical so there is more room to make subjective  
comments. Let me try to outline them here for discussion:

1) How many contexts to support? Many mentioned that two was enough.  
Carsten raised an issue when you use one of those contexts for the  
correspondent network. With only one context that can be used for the  
LoWPAN's prefix, nodes have to communicate uncompressed during the  
renumbering process. Is this acceptable? What do people think?

2) How much of the dispatch space do we give to HC? The latest  
proposal outlined by Julien requires 5 bits from the dispatch field,  
consuming 32 values. I have to agree that HC will be the most common  
dispatch value used, so it does make sense to give it priority. What  
do others think?

--
Jonathan Hui

On Oct 13, 2008, at 11:41 AM, Julien Abeille (jabeille) wrote:

> you
> bits).
>> node
>> bit
>> contain
> <hc.csv>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 16 Oct 2008 09:27:21 +0200

Hi Carsten and all:

I think we need to define context and usage in the architecture
document, not in HC.

Now, there's this recurrent question about how many contexts and what
they are for:
- It is very hard to know how many we need if we do not know what they
are for in the first place. 
- Another question that is not answered if the scope of a context. 

What we have today:
- The Current version of the HC WG doc uses contexts for anything
stateful
- The Current version of the HC WG doc enables up to 16 contexts.

Following the current HC assumptions, a context can be used to compress
anything down to /128. As Carsten mentions down here that includes
remote prefixes; and it also enables to fully compress a number of much
used addressed such as the application gateways and servers that the
nodes publish to.

There could be a number of those babies, thus the number 16.

My proposal is the following:

- It is the edge router responsibility to maintain the contexts in all
nodes. The contexts are distributed by the edge routers through a new ND
option that the ND draft introduces, valid in RAs and Router
Registration Confirmation. 

- the scope of a context is the set of devices attached to an interface
of that edge router. That is, it is guaranteed that entry 7 will means
the same for all nodes attached to a same interface on a same edge
router. 

- An edge router might use the same table on multiple interfaces.

- For transparent mobility, it is allowed to have a common context table
across the subnet

- a context entry contains a prefix and a prefix length. Length can be
128. 

- entry 0 is the edge router global address

- which context and how many there are (up to 16) is under the
responsibility of the edge router (config, radius, ...)

- if a node can not support as many contexts as the edge router
requires, we can hope that it does not need them.

- nodes should advertise how many contexts they can support max as they
attach to a router (ND)

- the router should store that in it ND cache and expand any address
that the node can not understand
- an new ICMP can be introduced to reject an unknown entry. 

What do you think?

Pascal

>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Carsten Bormann
>Sent: lundi 13 octobre 2008 20:18
>To: Jonathan Hui
>Cc: Carsten Bormann; 6lowpan

---

From: "Laurent Toutain" <[email-masked]>
Date: Thu, 16 Oct 2008 09:46:26 +0200

Hi,

On Thu, Oct 16, 2008 at 09:27, Pascal Thubert (pthubert) <[email-masked]
> wrote:

> - The Current version of the HC WG doc enables up to 16 contexts.

A stupid question, DDF 10 context 0 is the same as the context DDF 01, in
another way can you have up to 17 contexts ?

> Registration Confirmation.

It is something I don't understand. RA is for source prefix not destination
prefix how sensors will know destination context.

> - an new ICMP can be introduced to reject an unknown entry.

I think this compression is good  for sensors that stays in the same WSN, if
a sensor is moving from one network to another (for instance parcel
tracking) it may be very difficult to use that compression.

Laurent

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 16 Oct 2008 14:03:40 +0200

Hi Pascal,

this is a great list of items.
I'll try to explain my current thinking.

 > I think we need to define context and usage in the architecture

Right.  HC just needs to assume that there *is* a way the contexts are
established between sender and receiver of an L2 packet.  HC doesn't
really care what the protocol is that establishes them (except, if
it's not there, contexts can't be used).  Right now, my working
assumption is that the optimized ND will fill that gap.

We cannot, however, ignore the likely properties of that context
establishment protocol (let's call it CEP for now to avoid the
question whether this is done in ND or elsewhere); I'll say some more
about this below.

 > are for in the first place.

Right.  In broken record mode: To go from gut feeling ("640K should be
enough for everyone") to a better (and common) understanding, we need
to agree on an example/a benchmark.  See my message from Jul 31.

(Continuing out of order:)
 > There could be a number of those babies, thus the number 16.

The specific number should be decided when we know the trade-offs.
In the original CBHC draft, I proposed 16 because I conflated the
prefix length with the context number.  I haven't heard any support
for that idea.  So maybe we need fewer than 16.  See below.

 > - a context entry contains a prefix and a prefix length. Length can  
be

Yes.
It might also contain information about what is going to provide the
remaining bits: Are they going to be in the header or are they inferred
(e.g., from L2 addresses)?  Of course, that information can also be in
the header itself as separate bits, but this may be less efficient.
Note that the same prefix can be used beneficially in both these modes.
(We also need to decide how padding works if the bits in the header
can be non-multiples of 8 in length.)

Now, what is the cost of having too many contexts?

-- Assuming that the prefix length is part of the context state, the
cost of a context is: up to 16 bytes for the actual value, one byte (7
bits) for the prefix length, and one or two bytes for state
management.  Providing space for 16 contexts thus would mean that each
node would need to reserve up to ~300 bytes of context state, a value
high enough to merit some further discussion.

-- The context ID needs to be encoded in the context-referencing
header, once for each address.  Since we probably also want to
minimize complexity from variable-length and/or arithmetic encoding,
supporting 16 contexts needs expending 2x4 = 8 bits.

-- Of course, there is also a cost in state management.  300 bytes
don't fit into one L2 MTU, for instance, possibly increasing the
number of L2 packets needed for CEP.

What is the cost of having too little contexts?  Lost opportunities
for compression (or, possibly the need to go for less compression
where more would have been possible).

 > - nodes should advertise how many contexts they can support max as  
they

Hope is not a strategy, and not a protocol either :-)
If we allow heterogeneous context state within an area, we'll need to
establish state between sender and receiver, whether with an explicit
bilateral CEP or by storing per-peer state from error messages.
I don't think we want to do this, so I would propose to go for
homogeneous context state.

 > Registration Confirmation.

As I said, I'll call that "CEP" for now (but I do expect this to be
part of optimized ND and to be controlled by a designated node such as
an edge router).

 > responsibility of the edge router (config, radius, ...)

Yes ("designated node" for this message).

 > [...]

I'll skip the issue of what "attached to a same interface on a same
edge router" means and just call these scopes "areas" for now.

So, again, I'd agree and try to get homogeneous context state for an
area.  The assumption is that a node knows when it enters an area and
can then use a CEP (i.e., ND) to establish the context state for this
area.  I also assume there will be other state associated with an
area, so running a CEP is not going to dominate the cost of
e.g. mobility.

It also makes sense to assume some relationship between the area and
address configuration information (such as prefixes used for stateless
address configuration).

 > used addressed such as the application gateways and servers that the

Yep, but see above for the remaining bits.

 > - For transparent mobility, it is allowed to have a common context  
table

Let me comment that "mobility" can be intra-area mobility (which is
nothing but a routing change, so can be ignored here) or inter-area
mobility (which requires reconfiguration anyway).  Which one do you
mean?

 > - entry 0 is the edge router global address

We can always decide specific meanings for specific contexts, but I
don't know what "the edge router global address" is and how a node
would know it.

 > that the node can not understand

In route-over, all nodes are routers, so I don't understand.

 > - an new ICMP can be introduced to reject an unknown entry.

I explained above why I don't like relying on this for normal
operation, but it's certainly a good idea to provide some diagnostic
capability.

So, thanks again, Pascal, for creating a good outline for discussion!

Now, back to that number 16:
I'm assuming that CEP will be extremely lightweight (not two-phase
commit or some such :-).  So whenever the context state for an area
changes (and my assumption is that there is a need to allow it to
change), there will be contexts for which some nodes in the area have
new state and some are still on the old state.  The CEP, of course, is
designed to converge, so the assumption is there is a point in time
when the new state actually can be used.  But way before that point,
nodes need to find out the new state while knowing they can't use it
yet, and they need to stop using the old state.

So, I think each context can have one of the following states:

00 unused (do not use, do not accept)
01 in introduction (do not actively use, but remember the state)
11 in use (i.e., nodes assume all other nodes know the state)
10 in deprecation (do not actively use, but remember the state)

(01 and 10 are very similar in the way a node should handle them, so
it may be possible to combine them in CEP's encoding).  00 does not
have a value associated; the other three need a value and each node
needs to allow receiving headers referencing the context: 01 in case
another node switches to 11 earlier and starts using the context, 10
in case another node hasn't got the memo and still thinks the context
is in 11 state.  This is also the reason a context can't be in 01 and
10 at the same time (i.e., cannot simply get descructively updated
with a new value): a receiving node would not know whether to apply
the old or the new value to a compressed header.  (This can be solved
with any number of methods like generation numbers etc., but this
creates complexity and needs even more bits.)

So if we assume a transition time Tt within which a designated node
can update an area to new values with a level of probability deemed
acceptable, each specific context can be useless for 2*Tt, requiring
the use of another context number if continued context-based
compression during a transition is desired.  This is the reason why we
may need more potential context values than any static context state
configuration might suggest.  How many, of course, depends on our
model of the dynamicity of the context state, which is (broken-record
mode) the reason we need benchmarks to finish this discussion.

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 16 Oct 2008 16:25:17 +0200

Salut Laurent :-)

What we have today:

A stupid question, DDF 10 context 0 is the same as the context DDF 01,
in another way can you have up to 17 contexts ?

[Pascal] You're behind by one version; see
http://tools.ietf.org/id/draft-ietf-6lowpan-hc-01.txt 

	Following the current HC assumptions, a context can be used to
compress
	anything down to /128. As Carsten mentions down here that
includes
	remote prefixes; and it also enables to fully compress a number
of much
	used addressed such as the application gateways and servers that
the
	nodes publish to.

	
	- It is the edge router responsibility to maintain the contexts
in all
	nodes. The contexts are distributed by the edge routers through
a new ND
	option that the ND draft introduces, valid in RAs and Router
	Registration Confirmation.

It is something I don't understand. RA is for source prefix not
destination prefix how sensors will know destination context. 

[Pascal] we need something like Carsten's CEP to sync all the nodes in
the contxet scope/ Now a context entry (say an address) can be used
source or destination.

For instance, if many sensors are publishing their data to server
2001::1 then we could use a context entry for 2001::1. Context 3 would
be the destinarion context for publishing and the source for
subscribing.

Say that the sensor network is 2002::/64 and we have sensor with IP
address is based on EUI-48 following RFC4944 addressing.

I assume here that context 0 is the default context, (and BTW that is
contains the full address of the edge router)  and a prefix length of
64.

We'll end up with a 3 bytes dispatch + HC. For publishin we'll get:

       0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5   6
7   8   9   0   1   2   3
 
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---
+---+---+---+---+---+---+
     | 0 | 1 | 0 | 0 | 1 |  TF   |NH | HLIM  |  DDF  |  SAM  |  DAM  |
src context  | dest context  |
 
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---
+---+---+---+---+---+---+

       0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5   6
7   8   9   0   1   2   3
 
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---
+---+---+---+---+---+---+
     | 0 | 1 | 0 | 0 | 1 |  TF   |NH | HLIM  | 0   1 | 0   1 | 1 | 1 |
0        |       3       |
 
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---
+---+---+---+---+---+---+

DDF: Destination Dependant Field:
  01:  Destination and Source are Global or Unique Local Addresses
         and one additional context octet extends the LOWPAN_IPHC field
         to disambiguate an elided prefix or address described by the
         SAM or DAM fields.

SAM: Source Address Mode:
      When the Destination is a Global or Unique Local Addresses:
       01:  64 bits: the prefix of Source Address is elided.

DAM: Destination Address Mode:
      When the Destination is a Global or Unique Local Addresses:
       11:  0 bit: The Destination Address is fully elided.

	
	
	- the scope of a context is the set of devices attached to an
interface
	of that edge router. That is, it is guaranteed that entry 7 will
means
	the same for all nodes attached to a same interface on a same
edge
	router.
	
	- An edge router might use the same table on multiple
interfaces.
	
	- For transparent mobility, it is allowed to have a common
context table
	across the subnet
	
	- a context entry contains a prefix and a prefix length. Length
can be
	128.

	
	
	- nodes should advertise how many contexts they can support max
as they
	attach to a router (ND)
	
	- the router should store that in it ND cache and expand any
address
	that the node can not understand
	- an new ICMP can be introduced to reject an unknown entry.
	
	What do you think?

I think this compression is good  for sensors that stays in the same
WSN, if a sensor is moving from one network to another (for instance
parcel tracking) it may be very difficult to use that compression. 

Well, the sensor as it moves away from its subnet will have to form a
new address. Part of thart process will be to learn contexts. Hopefully
this can be done within existing flows. 

The context is not supposed to change too often or the node to move very
rapidly between subnets.  There are limits where another technology with
more power becomes necessary.

Laurent

	Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 17 Oct 2008 15:05:48 +0200

Hi Carsten

I'm not sure what you mean by Establishment? I had in mind that the
context is there by untold magic and ND had to Distribute it. If the
"Context Distribution Protocol" is part of ND then we have to specify it
there but I'd not expect ND to tell how the context is built in the
first place.

I can agree that traditional RA might not be the right way, be it only
for reasons of size. OTOH, a node might reactively read the white board
to get the value of a context entry whenever it needs it so it would not
need a table but a cache. RAs could carry a checksum of the entries;
also, failure to compute the right checksum for a packet could indicate
that the cache is obsolete.

What you called an area and I called a scope could be simple if we agree
it's the subnet. The subnet is the set on which we already do DAD and ND
lookup. A node is free to move within its subnet without renumbering.
Maybe mapping the area to a subnet limits number of contexts but for
sure it keeps things simple and cleanly at L3, as opposed to using
concepts like PAN ID .

Anyway we seem to agree that 16 contexts is a good number.

Pascal

>From: Carsten Bormann [mailto:[email-masked]]
>Sent: jeudi 16 octobre 2008 14:04
>To: Pascal Thubert (pthubert)
>Cc: Carsten Bormann; Jonathan Hui; 6lowpan
>Subject: Re: [6lowpan] Use of context / how many contexts
>
>Hi Pascal,
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 17 Oct 2008 18:40:53 +0200

> I'm not sure what you mean by Establishment?

The way the context gets to the node.  I.e., distribution for all  
likely kinds of CEP.

> I had in mind that the

I think the way the context state gets built in the first place (i.e.,  
before it is distributed in the area) is a local matter.
It seems to me we agree here.

> need a table but a cache.

Strikes me as a bad strategy; how do you manage your buffer space in  
this case?
But it's not ruled out by what I have in mind.

> RAs could carry a checksum of the entries;

Internet checksums are rather weak, so this should only be an unlikely  
last resort, or we will have regular cases of bad context not being  
detected.

> it's the subnet.

I just didn't want to make that decision in my message, which was  
trying to separate HC and the CEP and focus on HC.
I agree this is the obvious thing to do.

> The subnet is the set on which we already do DAD and ND

Two other numbers could be considered:
8 (needs 2x3 bits)
11 (needs 7 bits and a division, maybe not so great; leaves 7 patterns  
for special cases).
Also, the number could be 16-n if we reserve n bit patterns for  
specific purposes (e.g., indicating link-local, no context; useful if  
we want to get rid of DDF).

Gruesse, Carsten