Re: [6lo] [Int-area] Short Hierarchial IPv6 addresses

[Haoyu Song <[e-mail]>]

Hi Adnan,

Thank you for the question! In our architecture, the edge network follows a strict hierarchical tree structure. The root represents the entire edge network, each tree node represents a lower level network, and each branch represents a section of prefix.
Thus, while we allow each lower level network to have multiple gateway routers (aka LGR), they must own and advertise one same subnet prefix. Only if we guarantee this, we can safely prune the destination address prefix off from a packet when it enters into this lower level network (or augment the source address with this prefix when a packet exits this lower level network).

In general, we assume one edge network is totally under a single operator. If not, then each operator should own a separate lower level network. In your scenario, node A and B should be in two different lower level networks, and they can communicate  using the approaches we laid out. Hopefully I understand your question correctly. If not, please feel free to elaborate it. Thanks!

Best regards,
Haoyu

From: Adnan Rashid <[e-mail]>
Sent: Thursday, November 11, 2021 4:07 PM
To: Haoyu Song <[e-mail]>
Cc: Uma Chunduri <[e-mail]>; Kerry Lynn <[e-mail]>; [e-mail]; Alexander Pelov <[e-mail]>; [e-mail]
Subject: Re: [6lo] [Int-area] Short Hierarchial IPv6 addresses

Hi Haoyu,

Consider if you have multi tenant network, then will your scheme work?

If yes then how can node A from Service Provider-A can communicate with node B from Service Provider-B and both are under the same border router or edge node?
Regards,

Adnan Rashid

On Thu, Nov 11, 2021, 20:10 Haoyu Song <[e-mail]<mailto:[e-mail]>> wrote:
Thanks Uma, those are really great use cases. I would like to include them in the new revisions. My feeling is that a universal scheme like this can benefit many applications/networks (some yet to be explored) and won't introduce unnecessary conflicts and burdens to well-developed HC techniques for 6loWPAN and LPWAN.
We look forward to collaborations and suggestions on where we should land this work. Please let me know if you are interested.

Best regards,
Haoyu

From: Uma Chunduri <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, November 11, 2021 9:08 AM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: Kerry Lynn <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Alexander Pelov <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Int-area] [6lo] Short Hierarchial IPv6 addresses


Great discussion and inputs from many header compression experts.

>So maybe for the networks or applications where low latency is a critical requirement in addition to the bandwidth efficiency, we could find such context-less scheme more compelling.


I can with certainty give 2 such examples where I was involved multiple times w.r.t IPv6 usage:

1. A subset of mIOT UEs (this is a huge swath of UEs we are talking about) which needs low latency, high bandwidth and is sensitive to battery power. For example, a V2X UE, cares for low latency and high bandwidth but is not necessarily constrained by low battery power (though saving is always good). However, an AR/VR UE (advanced handset or 5G enabled headset) cares for all 3 (high BW, low latency and battery).

2. Another  one is with LEO satellite constellations and communication from the end points. Here also only a subset of use cases/devices cares for all 3.

regards!
--
Uma C.


On Wed, Nov 10, 2021 at 2:26 PM Haoyu Song <[e-mail]<mailto:[e-mail]>> wrote:
Hi Kerry and Alexander,

Thank you very much for the information. It seems the existing standards serve their purpose well. But Kerry did mention an interesting point: both these networks have low data rate and are insensitive to latency. So maybe for the networks or applications where low latency is a critical requirement in addition to the bandwidth efficiency, we could find such context-less scheme more compelling. This is very helpful discussion. Thanks a lot!

Best regards,
Haoyu

From: Kerry Lynn <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, November 10, 2021 9:04 AM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: Alexander Pelov <[e-mail]<mailto:[e-mail]>>; Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [6lo] Short Hierarchial IPv6 addresses

On Tue, Nov 9, 2021 at 7:15 PM Haoyu Song <[e-mail]<mailto:[e-mail]>> wrote:
Hi Alexander,

Thanks for the clarification! It seems you suggest that the bandwidth efficiency (i.e., the header overhead) is much more important than the cost of storage and processing in wireless. It would be great if we could find some quantitative research results. Is there any such info available?  It's also good to know that SCHC already supports direct device communications.  How about 6loWPAN? Same?

It is important to note that there are several 6lo data links that employ RFC6282
header compression including RFC8163, which is wired. (Indeed, I believe 6282
is a common denominator of published 6lo RFCs.) So, from my perspective, I'd
like your proposal to show why RFC6282 _won't_ work for your application.

Re: quantitative research results for the comparative energy costs of different
6lo design tradeoffs, I believe these studies do exist and folks in t2trg might be
able to point you to specific papers. Most (all?) 6lo data links are characterized
by low data rates, so it's important to consider the latency win of IPv6 header
compression as an additional consideration.

Regards, Kerry

<snip>
_______________________________________________
Int-area mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/int-area<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fint-area&data=04%7C01%7Chaoyu.song%40futurewei.com%7C17610663cd644dcaafa408d9a5705f24%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637722724340866448%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bF%2BNjIh%2BUAzrpghrC1B3Ej1S%2BSbMRY16OC9MKb46V%2B4%3D&reserved=0>
_______________________________________________
6lo mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/6lo<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6lo&data=04%7C01%7Chaoyu.song%40futurewei.com%7C17610663cd644dcaafa408d9a5705f24%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637722724340876398%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2bSTwq6a3am%2B5D4iIAnFD0tqHpGJgd1TzqkuajUL%2Bzg%3D&reserved=0>