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://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 Sent: Monday, October 18, 2021 11:26 AM To: Haoyu Song ; 6lo@ietf.org Subject: Short Hierarchial IPv6 addresses Haoyu Song wrote: > 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 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. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
[6lo] Short Hierarchial IPv6 addresses
Haoyu Song wrote: > 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 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. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] Call for agenda items - 6Lo session at IETF 112
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 <6lo-boun...@ietf.org> On Behalf Of Carles Gomez Montenegro Sent: Monday, October 18, 2021 7:31 AM To: 6lo@ietf.org Subject: [6lo] Call for agenda items - 6Lo session at IETF 112 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 ___ 6lo mailing list 6lo@ietf.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6lodata=04%7C01%7Chaoyu.song%40futurewei.com%7Cc6dcd733ac884048377f08d99243fc08%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637701642986264384%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=HzJrYiwpHvwtXBIeD3UPuR5WasQtXb0SYJFjTZVz1hM%3Dreserved=0 ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
[6lo] Call for agenda items - 6Lo session at IETF 112
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 ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02
Dear all, This is a gentle reminder that the call for adoption below is currently open (note: the call will end this Thursday, EOB). Please state on the mailing list whether you are in favor of adopting the document. Thanks, Shwetha and Carles > Dear 6Lo WG, > > Considering the need and the urgency for the functionality defined in > draft-thubert-6lo-multicast-registration-02, along with the interest from > the Wi-SUN Alliance, this message starts a 10-day call for WG adoption for > draft-thubert-6lo-multicast-registration-02. > > (Link below: > https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration) > > The call will end on the 21st of October, EOB. > > Please state whether you are in favor of adopting this document. > > Also, any comments you may have, and/or expressions of interest to review > the document, will be very much appreciated. > > Thanks, > > Shwetha and Carles > > > ___ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
[6lo] FW: New Version Notification for draft-li-6lo-native-short-address-00.txt
Hi all, Thanks for feedbacks from Pascal, Dominique, Carles and others. After we (three new authors and I) discussed the solution (original draft is draft-li-native-short-address-00) after communicating with Pascal and Carles, some significant modifications were made. First of all, the document clarifies that NSA is suitable for Low power and Lossy Networks and every NSA node may be aware of IPv6 address of them. So the NSA technology fall into the scope of 6lo working group. Secondly, in this document, we generalized the address allocation function definition and added description of '4.1 NSA addresses and IPv6 Addresses' and 'Limitation of Number of Children Node'. Those should be sufficient to distinguish the NSA allocation from algorithms like IEEE 802.15.5 and its variants. Thirdly and most importantly, to avoid drawbacks brought by renumbering, we added a new mechanism to avoid the renumbering during the topology change, by adding/updating routing entries along the affected path. The cost is comparable with the local repair of RPL. Routing related procedures is refined according to this design, see Section 5, 6 and 8. We also modify IANA part to apply for new registry and ICMP NSA control message. Considering lacking of large bulk of dispatch type space in page 0&1, we suggest to apply for dispatch type values in Page 10. Please have a look at this document and do not hesitate to reply here if you have comments Best regards, Guangpeng -Original Message- From: internet-dra...@ietf.org Sent: Monday, October 18, 2021 9:00 PM To: Zhe Lou ; Liguangpeng (Roc, Network Technology Laboratory) ; Luigi IANNONE ; Peng Liu ; Zhe Lou Subject: New Version Notification for draft-li-6lo-native-short-address-00.txt A new version of I-D, draft-li-6lo-native-short-address-00.txt has been successfully submitted by Guangpeng Li and posted to the IETF repository. Name: draft-li-6lo-native-short-address Revision: 00 Title: Native Short Addressing for Low power and Lossy Networks Expansion Document date: 2021-10-18 Group: Individual Submission Pages: 21 URL: https://www.ietf.org/archive/id/draft-li-6lo-native-short-address-00.txt Status: https://datatracker.ietf.org/doc/draft-li-6lo-native-short-address/ Htmlized: https://datatracker.ietf.org/doc/html/draft-li-6lo-native-short-address Abstract: This document specifies mechanisms of NSA (Native Short Address) that enables IP packet transmission over links where the transmission of a full length address may not be desirable. This document focuses on carrying IP packets across a LLN (Low power and Lossy Network), in which the nodes' location is fixed and changes in the logical topology are caused only by unstable radio connectivity (not physical mobility). The specifications include NSA allocation, routing mechanisms, header format design including length-variable fields, and IPv6 interconnection support. The IETF Secretariat ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
