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? 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? 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) <pthub...@cisco.com> Sent: Monday, November 8, 2021 10:08 PM To: Haoyu Song <haoyu.s...@futurewei.com> Cc: 6...@ietf.org 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 <haoyu.s...@futurewei.com> 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 <6lo-boun...@ietf.org> On Behalf Of Haoyu Song > Sent: Monday, October 18, 2021 12:11 PM > To: Michael Richardson <mcr+i...@sandelman.ca>; 6...@ietf.org > 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&data=04%7C01%7Chaoyu.song%40futurewei.com%7C95bdf073 > 45f94c84ae6a08d9a3475653%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C > 637720349052868783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo > iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=g8JFn7V2%2B3i > cgPEF7ADTaTcPr9DQNOeZjwyRrZR8i24%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 <mcr+i...@sandelman.ca> > Sent: Monday, October 18, 2021 11:26 AM > To: Haoyu Song <haoyu.s...@futurewei.com>; 6...@ietf.org > Subject: Short Hierarchial IPv6 addresses > > > Haoyu Song <haoyu.s...@futurewei.com> 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%7C95bdf07345f94c84ae6a08d9a3475653%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637720349052868783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=QI%2Bz2Aabf%2BiwCdcTcFVzRx%2BeOkOOO0iIvLFTqLznsiQ%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 <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > _______________________________________________ > 6lo mailing list > 6...@ietf.org > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > ietf.org%2Fmailman%2Flistinfo%2F6lo&data=04%7C01%7Chaoyu.song%40fu > turewei.com%7C95bdf07345f94c84ae6a08d9a3475653%7C0fee8ff2a3b240189c753 > a1d5591fedc%7C1%7C1%7C637720349052868783%7CUnknown%7CTWFpbGZsb3d8eyJWI > joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&a > mp;sdata=YjW5oU3MLyJdq2LXYgOXxLNU4qSyWTcXGPNyk6vcoL8%3D&reserved=0 > > _______________________________________________ > 6lo mailing list > 6...@ietf.org > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > ietf.org%2Fmailman%2Flistinfo%2F6lo&data=04%7C01%7Chaoyu.song%40fu > turewei.com%7C95bdf07345f94c84ae6a08d9a3475653%7C0fee8ff2a3b240189c753 > a1d5591fedc%7C1%7C1%7C637720349052868783%7CUnknown%7CTWFpbGZsb3d8eyJWI > joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&a > mp;sdata=YjW5oU3MLyJdq2LXYgOXxLNU4qSyWTcXGPNyk6vcoL8%3D&reserved=0 _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
