Pascal Thubert (pthubert) wrote:
>> For demonstration purposes, let's first assume that every node acts as
>> an L3 forwarder. In this case, no Mesh Addressing header is used and
>> compressed addresses are carried in the compressed L3 header.
>>
> [Pascal] But if there's no mesh, why can't we pick the addresses from
> the MAC header?
I think our ideas of the network are still not matching up. In one case,
I'm assuming that every node is doing L3 forwarding, meaning that each
15.4 hop is an IP hop. Every 15.4 hop decrements the IPv6 Hop Limit by
one. In this case, you can deliver messages over multiple hops without a
Mesh Addressing header. But you still need source and destination
addresses distinct from the MAC header. If you are delivering a message
over a single L2 hop, then the IP addresses can be completely elided and
derived from the 15.4 header.
In the case where nodes are doing L2 forwarding, then a Mesh Addressing
header is required to define the end-points of an IP hop and we can
completely elide the addresses in the IP header. The format defined by
HC1g supports both cases.
I've said this in an earlier email, but I believe the difference between
L2 and L3 forwarding is smaller than we think. In both cases, nodes are
essentially naming each other using MAC addresses. If this is the case,
I would prefer to have the forwarding occur at L3. Doing so allows us to
utilize functionality provided by IP, rather than re-defining
functionality below IP to make L2 hops look like a single IP hop.
--
Jonathan Hui
>> - For communication that stays within the PAN, there is between 4 and
> 16
>> bytes for L3 compressed addresses depending on whether the IID is
>> derived from the short or extended address. The resulting compressed L3
>> header is as small as 6 bytes (HC1, hlim, src, dst).
> [Pascal] Why not use HC1 with link local in that case? Seems not a most
> probable case for HC3.
>
>> - For communication that crosses the PAN boundary, one of the IP
>> addresses is always compressed and the other is not compressed.
> [Pascal] makes sense. I guess that's the right case for HC3?
>
>> Although, I am planning to put in provisions to allow stateful
>> compression by using a reserved short address range as defined in
>> RFC4944 similar to how I've proposed to compress well-known multicast
>> addresses. The resulting compressed L3 header is 20 bytes, but only 6
>> bytes if stateful compression is used.
> [Pascal] great but definitely further work.
>
>> - When the communication occurs over a single IP hop, then the IIDs can
>> be completely compressed and the resulting compressed IP header does
> not
>> contain any addressing information. This also works when L2 forwarding
>> occurs and the Mesh Addressing header is used. The resulting compressed
>> L3 header is only 2 bytes (HC1, hlim).
> [Pascal] I miss the rationale for the single IP hop... I must be tired
> :)
>
>> - To support both link-local and the common routable prefix, two
>> different dispatch values are used. I was originally thinking that the
>> same compression format could be used in both cases. But, as you point
>> out, we might have greater optimizations here. The nice thing with the
>> same compression format is that the same parsing code path can be used
>> for both link-local and routable cases, but comes at the cost of one
>> additional byte per datagram. So there is a tradeoff between code-size
>> and compression efficiency, as discussed early in this thread.
> [Pascal] I agree with that too. Still HC1g needs an HC2. The real issue
> with HC3 seems to be the code-size compression trade off. Maybe writing
> some pseudo code will help figuring that out. If that's one byte in most
> packets it might be worth it. Also, it could mean a fast path though the
> parsing, and thus a better energy-efficiency.
>
>> Do you think this is a reasonable approach?
> [Pascal] It is. Comments:
>
> 1) I'm missing the 2 bits to compress the hop limit though considering
> your assumptions there's a great chance that the PAN is a stub. I'd take
> the next header 2 bits off to HC2 to make room for this.
>
> 2) there's a well identified best case for HC3. I still think we can
> make room in HC3 to indicate this and have a common HC3 for 1 and 1g.
>
> On the side) I fail to see why we can not fully compress a EUI-64 based
> suffix with HC1G.
>
> Pascal
>> --
>> Jonathan Hui
>>
>>> - It seems obvious that the local address suffix can be compressed if
> it
>>> is based on EUI-64 or is unambiguously associated to a 16 bits
> address
>>> using states somewhere (nd, reverse-ND, ...). The prefix can be
>>> compressed if it is the only one on-link, or then again unambiguously
>>> associated to a 16-bits address. I'd assume that for both,
> considering
>>> the value of compressing, people will make sure that the conditions
> are
>>> met for the compression to happen.
>>>
>>> - It seems pretty obvious too that the remote address will not be
>>> compressed: if it was on-link the nodes could and should use link
> local
>>> addresses; So it is arbitrary. So the answer I expect for my question
>>> above is that you expect that most times we will fully compress the
>>> local address and not at all the remote address.
>>>
>>> Would that be your guess too?
>>>
>>> Pascal
>>>
>>>> -----Original Message-----
>>>> From: Jonathan Hui [mailto:[EMAIL PROTECTED]
>>>> Sent: mercredi 5 mars 2008 18:32
>>>> To: Pascal Thubert (pthubert)
>>>> Cc: 6lowpan; [EMAIL PROTECTED]; Jay Werb
>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3
>>>>
>>>>
>>>> Hi Pascal, see below:
>>>>
>>>> Pascal Thubert (pthubert) wrote:
>>>>> Hi Jonathan:
>>>>>
>>>>> I'm certainly not willing to specialize HC3 to mesh-under whatever
>>> your
>>>>> definition of the term. I'm willing to specialize HC3 to elide a
>>> number
>>>>> off "always on" bits so that when these bits are on, HC3 is used
>>> instead
>>>>> of HC1 and HC2. I hope this much is clear by now.
>>>> Yes, this is clear now.
>>>>
>>>>> Consider this: even HC1g is specialized; it is specilized to the
> case
>>>>> when only the terminating networks are LoWPANs. For instance, how
> do
>>> you
>>>>> compress a packet in a LoWPAN that would sit between the source
>>> LoWPAN
>>>>> and the destination LoWPAN - that's ROLL for you?
>>>> I never said that HC1g wasn't specialized. Any compression scheme
> must
>>>> make assumptions about the underlying pattern, otherwise there is no
>>>> compression to be had.
>>>>
>>>> ROLL for me is where every node operates as an IP router. HC1g is
>>> trying
>>>> to address a PAN where each L2 hop is an IP hop. However, it is not
>>>> trying to address cases where the PAN is a transit network for
> external
>>>> networks that can have arbitrary prefixes. In other words, any
> messages
>>>> going into the PAN will be destined for those nodes in the PAN, and
>>>> similarly any messages leaving the PAN will be sourced by a node in
> the
>>>> PAN. But in both cases, the addresses used are routable addresses.
> This
>>>> is the case I'm shooting for. Is this scenario realistic to you?
>>>>
>>>> --
>>>> Jonathan Hui
>>>>
>>>>> Like I said in another mail, this is a pretty difficult issue,
> maybe
>>>>> more complex than laying labels. My point is we do not know what
> ROLL
>>>>> will be made of; it will certainly be very interesting but it would
>>> be
>>>>> hazardous at this point to reserve bits for assumptions we could
> make
>>> on
>>>>> it.
>>>>>
>>>>> Let's look at what we have, which are the most important toggles
> and
>>> fit
>>>>> those in HC3. I'll be glad to define that the address that designs
> a
>>>>> node on this LoWPAN (the local address) is elided but is not a
>>>>> link-local-address and that the remote address is not elided. Or
>>>>> something else that makes sense like the local address is elided
> and
>>> is
>>>>> the one that unabiguously matches the scope of the remote address.
>>>>>
>>>>> So what's the case you're shooting for?
>>>>>
>>>>> Pascal
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Jonathan Hui [mailto:[EMAIL PROTECTED]
>>>>>> Sent: mercredi 5 mars 2008 17:31
>>>>>> To: Pascal Thubert (pthubert)
>>>>>> Cc: 6lowpan; [EMAIL PROTECTED]; Jay Werb
>>>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3
>>>>>>
>>>>>>
>>>>>> I think it's fair to say that we should continue working on IP
>>> header
>>>>>> compression. However, I also think we must evaluate whether we are
>>>>>> willing to specialize such compression schemes for route-over vs.
>>>>>> mesh-under networks. I don't have a problem with such
>>> specialization,
>>>>>> but I would have a problem if we required any 6LoWPAN
> implementation
>>> to
>>>>>> support specialized schemes for both mesh-under and route-over
>>>>>> simultaneously.
>>>>>>
>>>>>> --
>>>>>> Jonathan Hui
>>>>>>
>>>>>>
>>>>>> Pascal Thubert (pthubert) wrote:
>>>>>>> Hi Jonathan
>>>>>>>
>>>>>>> I agree it's great we are having this discussion :)
>>>>>>>
>>>>>>> Multiple thread could spawn from it because there are multiple
>>> topic.
>>>>>>> And some of this might belong to ROLL as you pointed out earlier.
>>>>>>>
>>>>>>> I'd wish to keep this thread for its original question on whether
>>> it
>>>>> is
>>>>>>> desirable, in the context of what we already have, to further
>>>>> compress
>>>>>>> HC1 and HC2 into a single HC3. For that specific thread, I retain
>>>>> that
>>>>>>> you do not oppose but that you vote for retaining some
> information
>>> on
>>>>>>> whether the addresses are elided or not.
>>>>>>>
>>>>>>> Is that fair?
>>>>>>>
>>>>>>> Pascal
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Jonathan Hui [mailto:[EMAIL PROTECTED]
>>>>>>>> Sent: mercredi 5 mars 2008 09:28
>>>>>>>> To: Pascal Thubert (pthubert)
>>>>>>>> Cc: 6lowpan; [EMAIL PROTECTED]; Jay Werb
>>>>>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3
>>>>>>>>
>>>>>>>>
>>>>>>>> Regarding the GW assumption on the link, I think we need to take
> a
>>>>> step
>>>>>>>> back for a second. While it is true that most architectures up
>>> until
>>>>>>>> this point follow this assumption, most architectures that I
> know
>>> of
>>>>>>>> haven't been built using IP. ZigBee nodes, for example, only
>>>>>>> communicate
>>>>>>>> with ZigBee nodes at every hop and there isn't any effort to do
>>>>>>>> internetworking.
>>>>>>>>
>>>>>>>> But now that we actually have IP, we are no longer constrained
> to
>>> a
>>>>>>>> single link technology. Rather, nodes can communicate with each
>>>>> other,
>>>>>>>> directly using 802.15.4, or over other technologies such as
> WiFi,
>>>>>>>> Ethernet, GPRS, etc. This really opens up the network
> architecture
>>>>>>>> possibilities, and there are many cases where adding these
>>>>> additional
>>>>>>>> links are desirable. I know that ISA's proposed backbone routers
>>>>>>> provide
>>>>>>>> this functionality, but I'd rather support such networks at the
> IP
>>>>>>>> layer, rather than abstracting a combination of link
> technologies
>>> as
>>>>>>>> single IP link and defining any new machinery to do so.
>>>>>>>>
>>>>>>>> BTW it's great that we're having this discussion. It is long
>>>>> overdue.
>>>>>>>> --
>>>>>>>> Jonathan Hui
>>>>>>>>
>>>>>>>>
>>>>>>>> Pascal Thubert (pthubert) wrote:
>>>>>>>>> Hi Jonathan:
>>>>>>>>>
>>>>>>>>> You are assuming explicitly that I am assuming implicitly...
> mesh
>>>>>>>>> under... Hum.
>>>>>>>>>
>>>>>>>>> Please have a look at
>>>>>>>>>
> http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router
>>>>>>>>> -00.txt and it should be apparent that I'm not. In particular
> the
>>>>>>>>> backbone router is the device that will set and use the hop
> limit
>>>>>>> bit.
>>>>>>>>> So will all those interconnecting devices used in pseudowire,
>>> split
>>>>>>>>> bridges, IP Mobility, etc... if they are deployed in this
> space.
>>>>>>>>> What I'm really assuming is a gateway or an edge server on the
>>>>> link.
>>>>>>>>> It's there in most architectures that I know of at this point
>>>>> that's
>>>>>>> why
>>>>>>>>> I included it in the case we shoot for and saved 2 bits. Note
>>> that
>>>>>>> when
>>>>>>>>> the ULA and global addresses are used on top of link local, it
>>>>> makes
>>>>>>>>> sense that we define a mechanism to compress them as well. But
>>> this
>>>>>>> is
>>>>>>>>> not what HC3 is about.
>>>>>>>>>
>>>>>>>>> The goal of my initial proposal is illustrative, to foster this
>>>>> very
>>>>>>>>> discussion around the idea that we can shoot for a favorite
> case
>>>>> and
>>>>>>>>> make an HC3 out of HC1 and HC2 for that case. Now, if we as a
>>> group
>>>>>>>>> think that the GW assumption is not reasonable, then, fine, let
>>> us
>>>>>>>>> affect 2 bits in HC3 to indicate whether the addresses are
>>>>>>> compressed.
>>>>>>>>> What do the others think?
>>>>>>>>>
>>>>>>>>> Pascal
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Jonathan Hui [mailto:[EMAIL PROTECTED]
>>>>>>>>>> Sent: mardi 4 mars 2008 18:05
>>>>>>>>>> To: Pascal Thubert (pthubert)
>>>>>>>>>> Cc: 6lowpan; [EMAIL PROTECTED]; Jay Werb
>>>>>>>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi Pascal,
>>>>>>>>>>
>>>>>>>>>> Thanks for sharing your thoughts.
>>>>>>>>>>
>>>>>>>>>> By assuming the first 5 bits in HC1 are '1', you're staking a
>>>>> claim
>>>>>>>>> that
>>>>>>>>>> mesh-under link-local communication within a PAN is going to
> be
>>>>> most
>>>>>>>>>> common case and the one we've "shot for". If link-local is all
>>> we
>>>>>>> focus
>>>>>>>>>> on, then we are missing the point of IP. Frankly, I don't see
>>> much
>>>>>>>>>> benefit of IP if communication is limited to the PAN.
>>>>>>>>>>
>>>>>>>>>> W.r.t mesh-under, there are efforts within the IETF that
> assume
>>>>>>> 6LoWPAN
>>>>>>>>>> nodes will communicate via route-over using routable addresses
>>>>> (e.g.
>>>>>>>>>> ROLL). This brings us back to a broader topic of route-under
> vs.
>>>>>>>>>> mesh-under. While both will probably exist for some time, it
>>>>> raises
>>>>>>> the
>>>>>>>>>> question of whether 6LoWPAN implementations can support one or
>>> do
>>>>>>> they
>>>>>>>>>> have to support both.
>>>>>>>>>>
>>>>>>>>>> W.r.t compressing Hop Limit, I don't quite understand why
> you're
>>>>>>> using
>>>>>>>>> a
>>>>>>>>>> bit in HC3 to indicate where the message originated. If you're
>>>>>>> assuming
>>>>>>>>>> link-local communication, then messages shouldn't be forwarded
>>>>>>> across
>>>>>>>>>> links anyway.
>>>>>>>>>>
>>>>>>>>>> I do agree that there is work to do on compression and agree
>>> that
>>>>>>> there
>>>>>>>>>> are cases where HC1 and HC2 are not sufficient. This is why
> I've
>>>>>>> been
>>>>>>>>>> working, albeit slowly, on HC1g.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Jonathan Hui
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Pascal Thubert (pthubert) wrote:
>>>>>>>>>>> Dear 6LoWPANers,
>>>>>>>>>>>
>>>>>>>>>>> Though HC1 and HC2 provide us with the capability to express
>>> any
>>>>>>>>>>> combination of compression, the most expected (or at least
> shot
>>>>>>> for)
>>>>>>>>>>> case does not lead to a better compression of the HC headers
>>>>>>>>> themselves.
>>>>>>>>>>> Seems that we could define an HC3 that would compress the
> pair
>>> of
>>>>>>> HC1
>>>>>>>>>>> and HC2 for that best case. My proposal for doing this would
> be
>>>>> to:
>>>>>>>>>>> - define a new dispatch
>>>>>>>>>>> | 01 000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed
> IPv6
>>>>> and
>>>>>>>>>>> transport
>>>>>>>>>>>
>>>>>>>>>>> - define HC3 itself to:
>>>>>>>>>>>
>>>>>>>>>>> - implicitly say that the first 5 bits of HC1 are all
>>> ones
>>>>>>>>>>> - carry HC1 bits 5 and 6 (Next Header)
>>>>>>>>>>> - replace HC2 so bit 7 of HC1 is useless
>>>>>>>>>>> - provide transport specific bits such as those defined
>>> for
>>>>>>>>>>> HC-UDP,
>>>>>>>>>>> then again assuming a predefined best case if room is
>>>>>>> missing
>>>>>>>>>>> An example of what the HC3 octet could be:
>>>>>>>>>>>
>>>>>>>>>>> bits 0 1 2-3
>>>>>>>>>>> 4-7
>>>>>>>>>>>
>>>>>>>>>>>
> +------------------+-------------+-----------------+--------------------
>>>>>>>>>>> ---------------------+
>>>>>>>>>>> | reserved | reserved | Next Header |
>>>>>>>>> transport
>>>>>>>>>>> specific control bits |
>>>>>>>>>>>
>>>>>>>>>>>
> +------------------+-------------+-----------------+--------------------
>>>>>>>>>>> ---------------------+
>>>>>>>>>>>
>>>>>>>>>>> Next header: as defined in HC1, bits 5 and 6
>>>>>>>>>>>
>>>>>>>>>>> transport specific control bits for UDP:
>>>>>>>>>>> bit 4 echoes HC-UDP bit 0 on UDP source port
>>>>>>>>>>> bit 5 echoes HC-UDP bit 1 on UDP destination port
>>>>>>>>>>> bit 6 echoes HC-UDP bit 2 on UDP length
>>>>>>>>>>> bit 7 is reserved
>>>>>>>>>>>
>>>>>>>>>>> What do you think?
>>>>>>>>>>>
>>>>>>>>>>> Pascal
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 6lowpan mailing list
>>>>>>>>>>> [email protected]
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
