Subject: [6lo] Call for agenda items - 6Lo session at IETF 112

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Mon, 18 Oct 2021 16:31:20 +0200

Dear 6Lo WG,

As you may have seen, a 6Lo WG session has been scheduled for IETF 112.
The coordinates for the session are:

- Day:   Monday, 8th of November 2021
- Time:  14:30-15:30 (UTC)
- Room:  2

If you want to present updates of existing drafts or new drafts at the 6Lo
session, please send your requests by Tuesday, 26th of October 2021.

Please include:

- Draft name and a short description.
- Presenter name.
- Purpose of the presentation.
- Time needed for the presentation.

Thanks,

Shwetha and Carles

---

From: Haoyu Song <[email-masked]>
Date: Mon, 18 Oct 2021 16:01:36 +0000

Hi 6lo WG chairs,

I'm resending this new draft presentation request to make the WG be aware of it.
The draft is about a short addressing scheme and its implications on the network architecture and routing which should be of interest to the WG. The proposed addressing scheme is orthogonal to existing 6LoWPAN header compression (RFC 6282) or SCHC header compression (RFC 8724). It's not limited to the network topology, requires no states, and allows edge nodes to directly communicate with each other. 

Thank you for the consideration! 

Title: Short Hierarchical IP Addresses at Edge Networks https://datatracker.ietf.org/doc/draft-song-ship-edge/.
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
Time request: 15min

Best regards,
Haoyu

-----Original Message-----
From: 6lo <[email-masked]> On Behalf Of Carles Gomez Montenegro
Sent: Monday, October 18, 2021 7:31 AM
To: [email-masked]
Subject: [6lo] Call for agenda items - 6Lo session at IETF 112

Dear 6Lo WG,

If you want to present updates of existing drafts or new drafts at the 6Lo session, please send your requests by Tuesday, 26th of October 2021.

Please include:

Thanks,

Shwetha and Carles

_______________________________________________
6lo mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6lo&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7Cc6dcd733ac884048377f08d99243fc08%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637701642986264384%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=HzJrYiwpHvwtXBIeD3UPuR5WasQtXb0SYJFjTZVz1hM%3D&amp;reserved=0

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Oct 2021 14:26:12 -0400

> 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-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Haoyu Song <[email-masked]>
Date: Mon, 18 Oct 2021 19:11:26 +0000

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://icnp20.cs.ucr.edu/proceedings/nipaa/Adaptive%20Addresses%20for%20Next%20Generation%20IP%20Protocol%20in%20Hierarchical%20Networks.pdf
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-masked]> 
Sent: Monday, October 18, 2021 11:26 AM
To: Haoyu Song <[email-masked]>; [email-masked]
Subject: Short Hierarchial IPv6 addresses

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.

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?