On Aug 11, 2010, at 3:00 AM, Pascal Thubert (pthubert) wrote: >> >> 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? Phil -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
