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 <[email protected]> On Behalf Of Haoyu Song
Sent: Monday, October 18, 2021 12:11 PM
To: Michael Richardson <[email protected]>; [email protected]
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%2Ficnp20.cs.ucr.edu%2Fproceedings%2Fnipaa%2FAdaptive%2520Addresses%2520for%2520Next%2520Generation%2520IP%2520Protocol%2520in%2520Hierarchical%2520Networks.pdf&data=04%7C01%7Chaoyu.song%40futurewei.com%7C023d95d26e22445b5d6608d9926b2342%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637701811141856874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=nEGmDFjRHO2ouowt9an5h1mneyP0WxVhCtezy86mcAg%3D&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 <[email protected]>
Sent: Monday, October 18, 2021 11:26 AM
To: Haoyu Song <[email protected]>; [email protected]
Subject: Short Hierarchial IPv6 addresses
Haoyu Song <[email protected]> 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&data=04%7C01%7Chaoyu.song%40futurewei.com%7C023d95d26e22445b5d6608d9926b2342%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637701811141856874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ctNHIfM9cKlNOuLsxvxPd63XIsT1tCD5UICXDGTM63I%3D&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 <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
6lo mailing list
[email protected]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6lo&data=04%7C01%7Chaoyu.song%40futurewei.com%7C023d95d26e22445b5d6608d9926b2342%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637701811141856874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=XoiNoRafEZc1zZpno7J3iA%2FV%2BujVPIwGCr1HDpGOk9M%3D&reserved=0
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
