On Dec 22, 2011, at 7:04 AM, Mukul Goyal wrote: >> And by the same logic, when forwarding a message, there is no guarantee that >> all neighboring nodes reachable via an interface belong to the same RPL >> routing domain. > > The receiving router could check if it belongs to the RPL domain listed in > the SRH. If not, it can drop the packet.
And what information does the SRH provide that indicates what RPL routing domain it is coming from? A node now has to know what neighbors are in its RPL routing domain? >> The *entire* point of the RPL Instance concept is to support MTR. The RPL >> Instance is used to distinguish between different DODAGs from the same root. >> It gives you the ability to have multiple different routes to the same >> destination (e.g. one that minimizes latency vs. one that minimizes energy >> consumption). If you don't have the RPL Instance information when >> forwarding a packet, how do you know whether to forward along the path that >> minimizes latency vs. the path that minimizes energy? > > Suppose a tunnel exit point knows that the SRH that carried the packet so far > had RPL Instance ID 'x' which happens to be associated with OF0. What > information does that give to the tunnel exit point? Is OF0 associated with > minimizing of latency or of energy? What is preventing this particular RPL > Instance ID 'x' with OF0 to be associated with two different DAGs - one > minimizing latency and the other minimizing energy? The tunnel exit-point knows what kind of paths the tunnel entry-point is forwarding the packet along. Again, the whole purpose of RPL Instances is to allow multiple paths optimized with different OFs towards the same destination. If a forwarding device has no idea of what path to choose, then why bother with a RPL Instance? >> See slide 18 of >> http://www.iab.org/wp-content/IAB-uploads/2011/04/Vasseur.pdf if you want >> one such reference of MTR and RPL Instances. > >> As I mentioned above, the RPL Instance allows you to have multiple distinct >> paths towards the same destination. The RPL hop-by-hop option includes a >> RPL Instance ID so that a forwarding node knows which routing topology to >> use. If RPL did not allow multiple routes to the same destination, then why >> bother having a RPL Instance? You would only need the DODAGID to uniquely >> identify a DODAG (whereas the existing definition is the "tuple >> (RPLInstanceID, DODAGID) uniquely identifies a DODAG". > > All this discussion is really besides the point. If we could just have the > RPL domain and not the RPL Instance as the scope for an SRH, that will solve > my problem. Limiting to a RPL Instance is well-defined. Limiting to a RPL routing domain requires a little more thought. Can you propose the exact processing rules that would clearly limit a routing header to a RPL routing domain? -- Jonathan Hui -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
