Hi Haoyu,
Your idea might be interesting, but I did not get it, still trying to absorb it in the context of 6lo, but I think it conflicts with other exsiting 6lo standards. Just few comments 1- is it possible if you make a scenario in the next draft? Because you did not answer about the ownership of border router. Can you check how PIOs are shared in LLNs and how your idea deal with them? Note PIOs not a single PIO. 2- how you can define the scalability and flexibility, in context of a multiple operators, I think rfc6282 is far more simple and flexible. 3- you are just targeting the common prefix problem (which is bearable) but putting alot of complexity in the LLN by making LGRs and new addressing scheme. A suggestion, read 6LoWPAN-ND and RPL may be after reading you can analyze conflicts. Regards, Adnan Rashid On Fri, Nov 12, 2021, 01:52 Haoyu Song <[email protected]> wrote: > 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 <[email protected]> > *Sent:* Thursday, November 11, 2021 4:07 PM > *To:* Haoyu Song <[email protected]> > *Cc:* Uma Chunduri <[email protected]>; Kerry Lynn <[email protected]>; > [email protected]; Alexander Pelov <[email protected]>; [email protected] > *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 <[email protected]> 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 <[email protected]> > *Sent:* Thursday, November 11, 2021 9:08 AM > *To:* Haoyu Song <[email protected]> > *Cc:* Kerry Lynn <[email protected]>; [email protected]; Alexander Pelov < > [email protected]>; [email protected] > *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 <[email protected]> > 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 <[email protected]> > *Sent:* Wednesday, November 10, 2021 9:04 AM > *To:* Haoyu Song <[email protected]> > *Cc:* Alexander Pelov <[email protected]>; Pascal Thubert (pthubert) < > [email protected]>; [email protected]; [email protected] > *Subject:* Re: [6lo] Short Hierarchial IPv6 addresses > > > > On Tue, Nov 9, 2021 at 7:15 PM Haoyu Song <[email protected]> > 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 > [email protected] > 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 > [email protected] > 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> > >
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
