On Dec 22, 2011, at 8:05 AM, Mukul Goyal wrote: >> 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 simplest option would be for the router to decide before hand which of > its interfaces belong to "the" RPL domain and which not. The SRH need not > have any RPL domain field. The router would drop the packet if received over > an interface not in "the" RPL domain. If the packet was received over an > interface in the RPL domain, it wont be forwarded down the interfaces not in > the RPL domain.
Again, just because you received a message on an interface for which you've enabled RPL doesn't mean you know the message came from a router that is within the same RPL routing domain. A router not running RPL could have sent you that message. > A more complicated scheme would be to allow for multiple RPL domains and list > the RPL Domain ID in the SRH. The router would know which RPL domains its > interfaces belong to and would treat the packet accordingly. Except that there is no such concept. RPL Instance ID is the closest we have. >> The tunnel exit-point knows what kind of paths the tunnel entry-point is >> forwarding the packet along. > > I am trying to say that RPL Instance ID does not give that information to the > tunnel exit point. As per RPL spec, RPL Instance ID would have a mapping to > the OF. It nowhere says that RPL Instance ID also has a mapping to metrics in > use. >From Section 3.2.1 of draft-ietf-roll-rpl: The Objective Function (OF) defines how RPL nodes select and optimize routes within a RPL Instance. The OF is identified by an Objective Code Point (OCP) within the DIO Configuration option. An OF defines how nodes translate one or more metrics and constraints, which are themselves defined in [I-D.ietf-roll-routing-metrics], into a value called Rank, which approximates the node's distance from a DODAG root. An OF also defines how nodes select parents. Further details may be found in Section 14, [I-D.ietf-roll-routing-metrics], [I-D.ietf-roll-of0], and related companion specifications. As you state, RPL Instance maps to OF which, from the cited text, maps to metrics and route selection. By transitivity, RPL Instance ID does map to metrics and how routes are formed. >> Again, the whole purpose of RPL Instances is to allow multiple paths >> optimized with different OFs towards the same destination. > > OF is just a way to calculate the rank. OF does not imply the use of > particular routing metrics. Since RPL Instance ID does not identify the > routing metrics in use, it can not tell what kind of route is being used to > forward a packet. In reality, it doesn't need to care. It just needs to care about sending along routes that were created using the same OF. Having each RPL router choose an arbitrary route created using an arbitrary OF does not make any sense. >> If a forwarding device has no idea of what path to choose, then why bother >> with a RPL Instance? > > RPL Instance is the top level identifier of the DAGs that can be used to > forward the packet. It also maps to a particular OF. In my opinion and as per > RPL spec, RPL instance has no other significance. See above. RPL Instance does map to metrics. >> 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? > > Lets assume that RPL domain is defined as you suggested some time back to be > analogous to the routing domain definition in RFC 1195 (section 1.2). I > interpret it to mean that the RPL router would characterize its interfaces as > either belonging to the RPL domain or outside the RPL domain. The definition I proposed was simply a collection of routers running RPL under the same administrative domain. As mentioned above, that does not mean that every router on an interface belongs 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 --------------------------------------------------------------------
