Hi Pascal:
On Oct 10, 2008, at 10:02 AM, Pascal Thubert (pthubert) wrote:
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?
[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.
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.
[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.
Then again, I see that the spec needs edition to be clearer but not a
change in the formats. What do you think?
[jhui] Agree.
--
JOnathan Hui
Pascal
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
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.
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?
[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?
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'?
[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
- Zach
Jonathan Hui wrote:
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 PROTECTED]>
Date: October 8, 2008 7:15:35 PM PDT
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
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 protected]
https://www.ietf.org/mailman/listinfo/6lowpan
--
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 protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
