[Roll] 6LoRH

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Martin:

I’d gladly exchange with you on all the topics you raise, all relevant and interesting. But for this particular discussion on whether we should move forward with 6LoRH, I would not discuss the workings of RPL. Whether RPL or something else sets the RH is irrelevant to this draft; what’s relevant is the exact semantics of the entries in the RH, e.g. loose vs. strict, address compression technique, etc… Yet certainly, if you wish, we can have a chat on RPL at ROLL.

From your mail I read a desire to split the original question in 2:

1)      Should we be doing 6LoRH at all

2)      If we do, where do we take the bits

Can I read that you’d answer yes to question 1) but propose an alternate from the draft approach for 2) ?

I would add to the picture that regardless of the specific formats of the RFC 4944 mesh header and RH3-6LoRH, there is a need to define an interoperable operation on setting the entries in the RH, and then forwarding frames based on what’s there. This is certainly something that I want to see detailed in 6LoRH, though admittedly it’s not done yet.

This may not have been so clearly spelled out in RFC 4944, either, but, because 6LoWPAN was chartered for 802.15.4, it was implicitly 802.15.4 addresses, which were expressed either as short addresses, PANID + short address, or full MAC64. With this in mind, interoperation was effectively guaranteed as should be for any RFC. This is why I take that baseline as the reference for claiming 6LoWPAN compliance and do not buy an overload to L3 addresses as compliant.

OTOH, with 6lo, we are extending 6LoWPAN beyond 802.15.4. Locking 1/3 of the dispatch space to 802.15.4 specific formats is just not acceptable, and for that reason, I completely agree with your suggestion to reuse those bits for L3 operations.

The caveat is whether one makes the choice to look and feel like the standard, but, at the same time, accepts not to interoperate with devices that implemented the standard as it was intended and implemented originally. If a given implementation places a compressed –or worse, uncompressed- IPv6 address in a MH, and some other expects only compressed MAC addresses, compliance to the format may be ensured, but interoperation is not achieved, and the purpose of the standard is defeated.

I think in fact that it is critical for the IETF to preserve its role as  a standard body that defines interoperable standards, and part of that is to control when a breakage is happening in backward compatibility. And effectively, the 6LoRH proposing a break, though the way it is spelled out, we try to respect existing implementations of 802.15.4 mesh networks, whether they are fully compliant to 6LoWPAN or not. The only way to do that is to accept that incompatible networks are segregated. On the way, we need a clear statement of what is compatible. And we trust standard compliance to indicate compatibility.

We’d need the answer to Carsten’s question about existing implementations that use the RFC 4944 MH and claim compliance in order to assess the damage, if any.  If we are already in a situation where we cannot expect interoperation between all existing implementations, but only between those with a special agreement that, by the way, was not validated by the IETF, then already we have implementations that cannot be deployed in a same network. 6LoRH would not be changing that picture, but is clearly an attempt to avoid it in the future by providing an extensible framework.

Cheers,

Pascal

From: 6lo [mailto:[e-mail]] On Behalf Of Martin Turon
Sent: mardi 2 décembre 2014 09:36
To: Carsten Bormann; James Woodyatt; [e-mail]; Routing Over Low power and Lossy networks; [e-mail]
Subject: Re: [6lo] Roll Digest, Vol 83, Issue 3


Hi Carsten,

I think the semantics of the mesh header are clear: the source inserts it's own address, and the address of a multi-hop final destination address, and then sends it to the best next hop on "the path".  Each node that receives it, also forwards to the next best hop on "the path", decrementing hops left as it does.


                           1                   2                   3

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |1 0|V|F|HopsLft| originator address, final address

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                 Figure 3: Mesh Addressing Type and Header

How the best path is determined depends on the routing protocol running on that node.  If RPL is running, it could use the tree for upstream or unknown paths, or cached best-next-hop for downstream paths.  My understanding of the wide research in this area is that local route decisions are much more efficient and scalable than source routing, and I'm frankly surprised RPL doesn't use the mesh header more!  Why not?  Just call it a highly compressed layer 3 ip-in-ip encapsulation within 6lo.

It certainly isn't any less clear than how RPL does source routing:

      0                   1

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-    -+-    -+ ... +-    -+

      |1|0|0|  Size   |6LoRH Type 0..4| Hop1 | Hop2 |     | HopN |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-    -+-    -+ ... +-    -+



            Size indicates the number of compressed addresses



                          Figure 3: The RH3-6LoRH
The answers to many questions would be the same:  How are the hopN addresses determined in RPL source routing?  Which node inserts those addresses?  How does a single node know the optimal path through the mesh?  How is that use any more clear than the mesh header?  I would argue that all that knowledge, coupled with an assumption that intermediate hops can be determined locally within the mesh, could just as easily generate a valid mesh header usable by RPL.

Regarding other candidate dispatch bits for repurposing in RFC4844, how about 010 xxxx 0?  We know LOWPAN_HC1 has been deprecated.  Any LOWPAN_BC0 fans out there?

My personal preference with all this would be to stabilize 6lo, preserve backwards compatibility as much as possible, similar to how x86 did, and extend it very carefully with new, full byte dispatch sequences:


           Pattern    Header Type

         +------------+-----------------------------------------------+

         | 00  xxxxxx | NALP       - Not a LoWPAN frame               |

         | 01  000001 | IPv6       - Uncompressed IPv6 Addresses      |

         | 01  000010 | LOWPAN_HC1 - LOWPAN_HC1 compressed IPv6       |

         | 01  000011 | reserved   - Reserved for future use          |

         |   ...      | reserved   - Reserved for future use          |

         | 01  001111 | reserved   - Reserved for future use          |

         | 01  010000 | LOWPAN_BC0 - LOWPAN_BC0 broadcast             |

         | 01  010001 | reserved   - Reserved for future use          |

         |   ...      | reserved   - Reserved for future use          |

         | 01  011111 | LOWPAN_RH  - draft-thubert-6lo-routing-dispatch-00         |

         | 01  1xxxxx | LOWPAN_IPHC - RFC6282                         |

         | 01  111111 | ESC        - Additional Dispatch byte follows |

         | 10  xxxxxx | MESH       - Mesh Header                      |

         | 11  000xxx | FRAG1      - Fragmentation Header (first)     |

         | 11  001000 | reserved   - Reserved for future use          |

         |   ...      | reserved   - Reserved for future use          |

         | 11  011111 | reserved   - Reserved for future use          |

         | 11  100xxx | FRAGN      - Fragmentation Header (subsequent)|

         | 11  101000 | reserved   - Reserved for future use          |

         |   ...      | reserved   - Reserved for future use          |

         | 11  111111 | reserved   - Reserved for future use          |

         +------------+-----------------------------------------------+

As everyone seems to agree, IoT is maturing, 6lo is growing in adoption, and we don't want to create a confused situation before it even gets started by forking the protocol arbitrarily.  Changes should stay on the conservative side, and adding a clear versioning method needs to be strongly considered.

Martin

Message: 2
Date: Tue, 2 Dec 2014 06:41:17 +0100
From: Carsten Bormann <[e-mail]<mailto:[e-mail]>>
To: James Woodyatt <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Routing Over Low power and
        Lossy networks <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Roll] [6tisch] [6lo] FW: New Version Notification for
        draft-thubert-6lo-routing-dispatch-00.txt
Message-ID: <[e-mail]<mailto:[e-mail]>>
Content-Type: text/plain; charset=utf-8

On 01 Dec 2014, at 20:20, James Woodyatt <[e-mail]<mailto:[e-mail]>> wrote:
>
> RFC 4944 is a Proposed Standard, which puts it into the same category as "Transmission of IPv6 Packets over Ethernet Networks" [RFC 2464],

That argument would be more convincing if the situations were indeed comparable.

RFC 2464 is the basis for widely deployed plug-and-play interoperability.
*That* is what makes it mostly immutable, not the standards status.
(Which probably should be upgraded to match reality.)

With RFC 4944, we haven?t reached that level of interoperability yet.
In particular, there is *no* way to achieve out-of-the-box interoperability with the old mesh header ? there is no defined way to use it, or even to find out that (and how) it should be used.
So you already have to add configuration (as in, "use mesh forwarding mechanism X") to use it.
Pascal?s proposal does not change this situation one iota: It doesn?t jeopardize interoperability where there was interoperability before.

(Note also that we already discarded LOWPAN_HC1 and LOWPAN_HC2 from RFC 4944 and replaced them with RFC 6282.)

Again, I believe we need to learn more about those reported usages of the old Mesh Header before we can meaningfully continue this argument.

Gr??e, Carsten