> >> > >> Pascal> [Pascal] The FL based proposal for RPL uses 12 mutable > > bits. > >> > >> Pascal> They are used as an in-band control plane that checks the > >> Pascal> consistency of routing states along a path. Those states > > can > >> Pascal> easily get out of sync due to the nature of the links, but > >> Pascal> the maintenance can be costly. We want to accelerate the > >> Pascal> repairs on those links that are actually used when an > >> Pascal> inconsistency is detected that will impact the delivery. > >> > >> I don't understand how the FL helps us on this! Probably I missed > > something > >> important. What you write below was my entire understanding of our > > need for > >> an in-band tag. > > > > [Pascal] This point is not about the flow label specifically but about > > the RPL strategy, and it works whether we use the flow label or the > > hop by hop techniques to transport the info. In short, the mere fact > > that there is a packet on the broken path causes us to 1) detect and > > 2) fix the issue. If there's no packet on a broken path then it can > > stay broken for a while. There will probably be many broken paths at > > any point of time in the network, due to transient link interference, > > movement, and all sorts of routing desyncs. Considering the cost of > > proactive rapid resolution, we have chosen not to fix the routing > > issues as soon as they appear but 1) lazily and 2) on-demand. > > The lazy piece is a global reconstruction of the DAG that happens > > periodically. The on-demand piece is a data path validation that > > allows us to fix a path as it is being used, either using a mutable > > flow label field or the Hop by Hop header. > > Maybe a rewording might make this clearer. > > Basically, RPL puts up to two pieces information in packets that it routes. The > first is which routing topology this packet should be routed on: RPL supports > multiple parallel topologies, e.g., one optimized for low latency and a second > optimized for low energy. This information is called the RPLInstanceId. > > The second is information about the "cost" of the forwarder's route to the > destination. This hop-by-hop "cost" information is called Rank. Rank is needed > to detect routing loops: if a router receives a packet whose prior router's Rank > is less than or equal to its own, Rank is not strictly decreasing and there may be > a routing loop. > > Being able to embed this information in the flow label, rather than requiring > additional headers and IP-in-IP, would greatly reduce header overhead. In RPL, > we're often concerned about very short, such as 10 byte, packets, so this could > be a big savings. > > The challenge is that the RPLInstanceId is 8 bits and Rank is 16 bits. > > Does that make sense?
[Pascal] Agreed. We'll note that the Hop by Hop + IP in IP is costly but solves the generic problem *within* the RPL network. The use of the Flow label *within* the RPL network would be an alternate so it could have a more limited applicability, like a more limited number of instances or a Rank floor that can be expressed in 1 octet or less, which is probably more than enough considering that infinity is 16 in RIP. This could cover a large number of foreseeable deployments. There is certainly a strong benefit in Low Power Lossy Networks to make the flow label mutable. Still, making it all mutable will definitely block a communication path between the app and the network, which I feel is a mistake. Pascal -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
