Re: [6lo] Short Hierarchial IPv6 addresses

[Alexander Pelov <[e-mail]>]

Dear Haoyu,

Thanks for the questions.

A couple of thoughts inline.


On Tue, Nov 9, 2021 at 10:25 PM Haoyu Song <[e-mail]> wrote:

> Copied to INTAREA WG because this was also discussed in it.
>
> Hi Pascal,
>
> Thank you very much for the suggestions which are very helpful! The high
> level idea is indeed drawn from PSTN and PNNI, the proven technologies.
>
> Our P4 prototype evaluation shows that the extra router processing is
> doable with little impact on forwarding performance. Meanwhile, both data
> plane and control plane are significantly simplified (e.g., smaller and
> regular FIB, simplified routing protocols) which actually leads to lower
> router cost. So from the implementation point of view, I have confidence on
> it.
>
> The scheme is applicable to other environments as well, for example, data
> center networks, where east-west low-latency communication is dominant. I
> agree with you that the discussion is more an IAB one, but some folks in
> INTAREA also suggest I may go to 6lo. This makes me a little confused. I
> need more advices on how to proceed with the work, and welcome people who
> are interested in this work to join me.
>
> I also have some questions for the 6lowpan and LPWAN header compression
> schemes. Aren't  the context  storage and compression/decompression
> computing a source for resource/energy consumption? Is there any evaluation
> results on their impact?


The energy cost of a couple of "for" cycles is negligible compared to the
energy necessary for wireless communications. In a more generic setup, the
Static Context Header Compression will depend on the number of static
contexts you have. If I understand correctly the short address proposal,
that would mean roughly one context per address length. Assuming a subnet
has the same 'address length' would mean a single context would suffice,
which means - unmeasurably-small energy consumption (not to say 0).


> If shorter addresses are introduced as an additional feature, it may
> improve the situation. Another issue I'm concerned is that in 6lowpan/LPWAN
> (maybe I'm wrong) it seems that an end node can only talk with a server
> through a gateway. I think it may be needed for end nodes to directly
> communicate with each other in many cases. If so, do we need some
> context-free compression schemes?


The initial way of working for SCHC was indeed in the Device<->Gateway
paradigm. However, it has become quite obvious that there is a direct
extension in a "SCHC Peer" mode (when the Device and the Gateway are
equally capable for example), where there is no need for intermediate
elements.

So, the short answer is - SCHC already has what you want to achieve in
terms of reducing the bits on the air/wire.

Best regards,
Alexander






>
>
> Sorry for the lengthy email. I just wanted to gain a better understanding
> on the situation. Thanks!
>
> Best regards,
> Haoyu
>
> -----Original Message-----
> From: Pascal Thubert (pthubert) <[e-mail]>
> Sent: Monday, November 8, 2021 10:08 PM
> To: Haoyu Song <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [6lo] Short Hierarchial IPv6 addresses
>
> Hello Haoyu:
>
> If I get your proposal well, this is a bottom up aggregation approach when
> IP has been traditionally top down. IP  extends the prefix length that the
> router looks into as we dive down the hierarchy as opposed to building the
> address as you extend the reach in this draft.
>
> At a high level, there’s a bright and a dark side.
>
> Bright side:
>
> It can be made to work as proven by other similar mechanisms like domain
> name and PSTN. It simplifies the host knowledge of its domain.
>
> There’s neat routing technology like PNNI that could possibly do a great
> job with bottom up aggregation.
>
> Dark side:
>
> 6lo does not need a new compression. We already have a simple mostly
> stateless one with 6282 and a more complex stateful with SCHC. Too many
> standards kill the standard.
>
> The scheme moves the complexity from the hosts to the network and I’m not
> sure what kind of effort it would take to uplift that. In comparison going
> IPv6 looks a minor step. In any case this is not a 6lo discussion, more an
> IAB one.
>
> In short I do not recommend to use 6lo as the forum. You need a larger
> audience with routing and operations involved.
>
> Keep safe,
>
> Pascal
>
> > Le 9 nov. 2021 à 00:58, Haoyu Song <[e-mail]> a écrit :
> >
> > Hi WG,
> >
> > In today's session  I don't have enough time to finish my presentation.
> I think it's important to highlight the difference between our scheme (aka
> SHIP) and the compression schemes used by 6LoPAN and  LPWAN. Please let me
> know if you have further questions or suggestions.
> >
> > 1. SHIP is hierarchical, extending from edge to core 2. SHIP is
> > applicable to all kinds of networks, in contrast to:
> >    - 6LoPAN: IEEE 802.15
> > 3. SHIP is applicable on arbitrary network topology, in contrast to:
> >    - HC is applicable on "point-to-point" channel only
> >    - Compressed packet is not routable unless decompressed first 4.
> > SHIP only concerns the IP addresses, orthogonal to the compression
> > technique on the other header fields 5. SHIP is solely determined by
> > the subnetworks, needing no dynamic context negotiation or static
> > context configuration 6. SHIP allows communication between any
> > Internet-addressable nodes
> >
> > Best regards,
> > Haoyu
> >
> > -----Original Message-----
> > From: 6lo <[e-mail]> On Behalf Of Haoyu Song
> > Sent: Monday, October 18, 2021 12:11 PM
> > To: Michael Richardson <[e-mail]>; [e-mail]
> > Subject: Re: [6lo] Short Hierarchial IPv6 addresses
> >
> > Hi Michael,
> >
> > Thank you very much for your comments!
> > I said it's orthogonal to RFC6282 due to the fact that this draft only
> concerns about the address part. Since each edge node only needs to keep a
> shorter address, the power and storage associated with it are both reduced.
> It can be combined with shared context between two nodes (as described in
> those context based compression schemes) to achieve further compression. In
> this sense, I said they are "orthogonal".
> >
> > Having said that, I think it can also be a standalone scheme. If the
> resulting overhead due to the short address  can already satisfy the
> application need, then there are merits to use this scheme alone, for the
> following reasons:
> > 1. Because there is no need to maintain the context between peers, the
> storage for context and the computing for compression/decompression can
> both be optimized, which I think is critical in the low power and low
> capacity IoT scenarios.
> > 2. There would be no limitation to the network topology (e.g., star).
> Edge nodes can talk to each other directly and communicate with Internet
> freely. I think this is another advantage that the other compression
> schemes are difficult to achieve but the application may desire to have.
> >
> > Here are some other clarifications to your questions:
> >
> > 1. Based on our evaluation, while retaining all IPv6 header information,
> our scheme can reduce the IPv6 header overhead  from 60% to 70% (i.e., from
> 40B to 12~16B). I'll add the evaluation in the future draft revisions.
> >
> > 2. Yes it can be seen as a static compression scheme, in which the most
> compression benefit is from the size reduction of the IP addresses. Since
> there will be an IPv6 gateway towards external world, some other header
> fields within the edge network can also be reduced or simplified.
> >
> > 3. The edge network below the IPv6 gateway appears to be a subnetwork to
> the Internet. Within the edge network, the network is hierarchical and the
> routing in it is straightforward.  In the following paper, we described how
> the conventional and yet simplified version of IGP and BGP can be used
> within the edge network for routing.
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ficnp
> > 20.cs.ucr.edu%2Fproceedings%2Fnipaa%2FAdaptive%2520Addresses%2520for%2
> > 520Next%2520Generation%2520IP%2520Protocol%2520in%2520Hierarchical%252
> > 0Networks.pdf&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C95bdf073
> > 45f94c84ae6a08d9a3475653%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C
> > 637720349052868783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> > iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=g8JFn7V2%2B3i
> > cgPEF7ADTaTcPr9DQNOeZjwyRrZR8i24%3D&amp;reserved=0
> > Thanks to the hierarchical architecture, the forwarding table and the
> router function will be greatly simplified, which is naturally beneficial
> for power, memory and energy.
> >
> > Best regards,
> > Haoyu
> >
> > -----Original Message-----
> > From: Michael Richardson <[e-mail]>
> > Sent: Monday, October 18, 2021 11:26 AM
> > To: Haoyu Song <[e-mail]>; [e-mail]
> > Subject: Short Hierarchial IPv6 addresses
> >
> >
> > Haoyu Song <[e-mail]> wrote:
> >> Title: Short Hierarchical IP Addresses at Edge Networks
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-ship-edge%2F&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C95bdf07345f94c84ae6a08d9a3475653%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637720349052868783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=QI%2Bz2Aabf%2BiwCdcTcFVzRx%2BeOkOOO0iIvLFTqLznsiQ%3D&amp;reserved=0
> .
> >> Abstract: To mitigate the IPv6 header overhead in edge networks, this
> >> draft proposes to use short hierarchical addresses excluding the
> >> network prefix within edge networks.  An edge network can be further
> >> organized into a hierarchical architecture containing one or more
> >> levels of networks.  The border routers for each hierarchical level
> >> are responsible for address augmenting and pruning.  Specifically,
> >> the top-level border routers convert the internal IP header to and
> >> from the standard IPv6 header.  This draft presents an incrementally
> >> deployable scheme allowing packet header to be effectively compressed
> >> in edge networks without affecting the network interoperability.
> >> Presenter: Haoyu Song
> >> Purpose: gain awareness and interests from the WG, collect feedback
> >> and suggestions for the next step
> >
> > Interesting.  I browsed the document quickly.
> >
> > I'm not sure I understand how it is "orthogonal" to RFC6282.
> > It seems to be an alternative.  If it was orthogonal, then it would work
> on a different basis vector, and I could use both at the same time.
> >
> > It seems like you are doing a static compression scheme by re-encoding
> > the
> > IPv6 header to a new format.
> >
> > I hope to see some table explaining the size of your header compared to
> RFC6282.
> >
> > Since you have assumed some kind of hierarchal network, would you use
> RFC6550 for routing, or is it that you don't need any routing due to your
> architecture?
> >
> > --
> > Michael Richardson <[e-mail]>   . o O ( IPv6 IøT
> consulting )
> >           Sandelman Software Works Inc, Ottawa and Worldwide
> >
> > _______________________________________________
> > 6lo mailing list
> > [e-mail]
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ietf.org%2Fmailman%2Flistinfo%2F6lo&amp;data=04%7C01%7Chaoyu.song%40fu
> > turewei.com%7C95bdf07345f94c84ae6a08d9a3475653%7C0fee8ff2a3b240189c753
> > a1d5591fedc%7C1%7C1%7C637720349052868783%7CUnknown%7CTWFpbGZsb3d8eyJWI
> > joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&a
> > mp;sdata=YjW5oU3MLyJdq2LXYgOXxLNU4qSyWTcXGPNyk6vcoL8%3D&amp;reserved=0
> >
> > _______________________________________________
> > 6lo mailing list
> > [e-mail]
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ietf.org%2Fmailman%2Flistinfo%2F6lo&amp;data=04%7C01%7Chaoyu.song%40fu
> > turewei.com%7C95bdf07345f94c84ae6a08d9a3475653%7C0fee8ff2a3b240189c753
> > a1d5591fedc%7C1%7C1%7C637720349052868783%7CUnknown%7CTWFpbGZsb3d8eyJWI
> > joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&a
> > mp;sdata=YjW5oU3MLyJdq2LXYgOXxLNU4qSyWTcXGPNyk6vcoL8%3D&amp;reserved=0
> _______________________________________________
> 6lo mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo
>