Hi Jonathan >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. >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? >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. Thanks Mukul -- Jonathan Hui -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
