Subject: [Roll] RPL hop-by-hop and source route

From: Richard Kelsey <[email-masked]>
Date: Tue, 03 Aug 2010 19:33:22 -0400

A question came up in the planning for the next ZigBeeIP
interop.  If a packet has a source route, must it also have
a RPL hop-by-hop option?  What purpose would the hop-by-hop
option serve?
                                   -Richard Kelsey

---

From: Philip Levis <[email-masked]>
Date: Tue, 3 Aug 2010 16:47:24 -0700

> a RPL hop-by-hop option?  What purpose would the hop-by-hop

Good question. My 2 cents:

I don't think there's a purpose to having Rank in the hop-by-hop header.

There may be a purpose to having the RPLInstanceID, though. E.g., if the source routed packet results in an ICMP error, which RPLInstance should the ICMP error use? It would be a bit weird if an error in RPL instance X resulted in an ICMP error from RPL instance Y.

Phil

---

From: Richard Kelsey <[email-masked]>
Date: Wed, 04 Aug 2010 10:42:34 -0400

> From: Philip Levis <[email-masked]>
> Date: Tue, 3 Aug 2010 16:47:24 -0700

> There may be a purpose to having the RPLInstanceID,
> though. E.g., if the source routed packet results in an
> ICMP error, which RPLInstance should the ICMP error use?
> It would be a bit weird if an error in RPL instance X
> resulted in an ICMP error from RPL instance Y.

RPL doesn't require that RPLInstances provide two-way
routing, so ICMP errors may need to use some other
instance whether or not there is a source route in the
packet.
                             -Richard

---

From: Philip Levis <[email-masked]>
Date: Wed, 4 Aug 2010 08:13:44 -0700

> instance whether or not there is a source route in the

All RPLInstances provide upward routes; not all instances provide downward routes. A source routing header is used for downward routes. So... or are you thinking about the current proposal for lower stretch P2P communication?

The intent of my reply was *not* to say that there MUST be a hop-by-hop header when there's a source routed packet. It was to answer the question "What purpose would the hop-by-hop option serve?" To answer was "To ensure that a resulting ICMP error uses the same RPLInstance when possible." It's an open questions whether this is important.

Phil

---

From: Richard Kelsey <[email-masked]>
Date: Thu, 05 Aug 2010 12:30:39 -0400

> Date: Wed, 4 Aug 2010 08:13:44 -0700
> 
> All RPLInstances provide upward routes; not all instances provide
> downward routes. A source routing header is used for downward
> routes. So... or are you thinking about the current proposal for lower
> stretch P2P communication?

No, I was just thinking of the more general,
non-source-routing case.

> The intent of my reply was *not* to say that there MUST be a
> hop-by-hop header when there's a source routed packet. It was to
> answer the question "What purpose would the hop-by-hop option serve?"
> To answer was "To ensure that a resulting ICMP error uses the same
> RPLInstance when possible." It's an open questions whether this is
> important.

Yes.  At the ZigBee/IP interop we can try running without a
hop-by-hop header when a source router header is present and
see if the IETF black helicopters show up.

                                 -Richard Kelsey

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 9 Aug 2010 11:25:14 +0200

Hi Richard:

The RPL option in HbH hdr serves not only as loop avoidance but also as
an error detection mechanism.
If you do not use it, Rank errors will not be detected, and the root
cannot be updated with DAO that fix its view of the network.
That view of the network is per instance. So if we wish to report any
error to the root, we need the instanceID.
The text is lacking details about the "Error in Source Routing Header"
ICMP message that is used to carry the error. The message should at
least echo the packet in error up to HpH and Routing headers. I'd expect
that in the RPL option therein, the flags will be set to indicate a Rank
error (R bit) of the impossibility to forward down because the next
entry in the RH is not reachable (F bit).
Makes sense?

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Richard Kelsey
> Sent: Wednesday, August 04, 2010 1:33 AM
> To: [email-masked]
> Subject: [Roll] RPL hop-by-hop and source route
> 
> A question came up in the planning for the next ZigBeeIP interop.  If
a packet
> has a source route, must it also have a RPL hop-by-hop option?  What
purpose
> would the hop-by-hop option serve?
>                                    -Richard Kelsey
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Richard Kelsey <[email-masked]>
Date: Mon, 09 Aug 2010 08:27:23 -0400

> Date: Mon, 9 Aug 2010 11:25:14 +0200
> From: "Pascal Thubert (pthubert)" <[email-masked]>
> 
> The RPL option in HbH hdr serves not only as loop
> avoidance but also as an error detection mechanism.  If
> you do not use it, Rank errors will not be detected, and
> the root cannot be updated with DAO that fix its view of
> the network.

Pascal,

Detecting a rank error with a source-routed packet doesn't
mean that there is a rank error in the DODAG, or even that
the root has outdated information.  The root may have
received new information after sending the packet, or it may
have created the source route using other data or a
different algorithm.  I don't think we should require that
the root precisely echo back the routing data it receives in
DAOs.

> That view of the network is per instance.

Why?  Why restrict the source routes in this way?

                                  -Richard Kelsey

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 9 Aug 2010 16:17:21 +0200

Hi Richard
> >
> > The RPL option in HbH hdr serves not only as loop avoidance but also
> > as an error detection mechanism.  If you do not use it, Rank errors
> > will not be detected, and the root cannot be updated with DAO that
fix
> > its view of the network.
> 
> Pascal,
> 
> Detecting a rank error with a source-routed packet doesn't mean that
there is a
> rank error in the DODAG, or even that the root has outdated
information.  The
> root may have received new information after sending the packet, or it
may
> have created the source route using other data or a different
algorithm.  I don't
> think we should require that the root precisely echo back the routing
data it
> receives in DAOs.

[Pascal] Agreed. This is very classical to ICMP errors in general that
are throttled. 
If the node receives a source routed packet from a supposed parent that
actually has a higher Rank, this means that at the time of the
generation of the routing header, the root had a perception of the
network that is now obsolete

> Why?  Why restrict the source routes in this way?
 
[Pascal] Mostly the same answer as in storing mode. If a root could
(source) route over mixed instances, it'd lose the benefits of the
constraints. Even in storing, a strict hierarchy of instances could have
allowed a packet to switch instances in a loopless fashion, but the
group decided not to go there. Please do not ask me to defend that
position, I was in the other camp : )

Pascal

---

From: Richard Kelsey <[email-masked]>
Date: Tue, 10 Aug 2010 08:42:49 -0400

> Date: Mon, 9 Aug 2010 16:17:21 +0200
> constraints.

Yes, but that is a choice that the root can make.  Why
should we make that decision for it?

> Even in storing, a strict hierarchy of instances could have

Routing upwards using the DODAG is a completely different
issue.  The source route forwarding is distinct from RPL
and it seems wrong for RPL to put constraints on it.

                                   -Richard Kelsey

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 11 Aug 2010 11:15:32 +0200

Hi Richard:

> > Even in storing, a strict hierarchy of instances could have allowed
a
> > packet to switch instances in a loopless fashion, but the group
> > decided not to go there. Please do not ask me to defend that
position,
> > I was in the other camp : )
> 
> Routing upwards using the DODAG is a completely different issue.  The
source
> route forwarding is distinct from RPL and it seems wrong for RPL to
put
> constraints on it.

The point does not have to do with up or down routing. It has to do with
the capabilities of the path and the respect of the constraints.

If the Source Route uses hops from multiple instances that are computed
for different OFs then the result is admittedly loopless, but
unconstrained as well.

Like I said, the enforcement of this limitation does not come from me. I
support allowing the instance switching as long as there's a policy that
makes it loopless, and the deployment guys understand what they are
doing and the result they can expect from doing it. The source routing
by the root is one example of that whereby the policy is to enforce that
the root checks at least that it builds a loopless source route (that's
actually specified in the 6MAN draft so I'm fine).

Pascal

> From: Richard Kelsey [mailto:[email-masked]]
> Sent: Tuesday, August 10, 2010 2:43 PM
> To: Pascal Thubert (pthubert)
> Cc: [email-masked]
> Subject: Re: [Roll] RPL hop-by-hop and source route
> 
> Yes, but that is a choice that the root can make.  Why should we make
that
> decision for it?
> 
> > Even in storing, a strict hierarchy of instances could have allowed
a
> > packet to switch instances in a loopless fashion, but the group
> > decided not to go there. Please do not ask me to defend that
position,
> > I was in the other camp : )
> 
> Routing upwards using the DODAG is a completely different issue.  The
source
> route forwarding is distinct from RPL and it seems wrong for RPL to
put
> constraints on it.