Subject: [6tisch] architectural document comments

From: Michael Richardson <[email-masked]>
Date: Sun, 04 May 2014 15:45:39 -0400

I am re-reading architecture-01 as I write 6tisch-security document, so
as to leverage the right pieces.  My appologies if some of this is obvious,
but I can say that I didn't manage to read to the end of every thread.

My minor comments/questions:

section 6.1.0 of architecture-01 says:

   As a result, as
   long as the TSCH MAC (and Layer 2 security) accepts a frame, that
   frame can be switched regardless of the protocol, whether this is an
   IPv6 packet, a 6LoWPAN fragment, or a frame from an alternate
   protocol such as WirelessHART of ISA100.11a.

(btw: typo: "s/HART of/HART or/")

and while I agree with the fact that the frame can be forwarded, is it the
case that no "this frame is for me" checks are done on tracks which do not
end on the forwarding node?  In tunnel mode, it is clear that this is the
case, but I'm asking about transport mode.

Is there a real desire to build these tunnel mode tracks for "legacy" users
of 15.4(e), such as ISA100.11a?  Or is just a conceptual statement that this
could be done?  The appeal to drop-in 6tisch technology into an existing
ISA100 network is appealing; but I wonder if it really work in practice due
to security and addressing issues.  Can someone imagine mapping ISA100 nodes
into an abstracted (proxied) IPv6 address space?

When forwarding in transport mode,  it appears that 6lo HC is not
undone/redone.  Is that correct?

ps: EB is used before it is defined, and "Enhance Beacon" is used
    as well as "Extended Beacons"

In section 7.2, I might read that broadcast DIO and DAO are not contained in
ICMPv6 messages, but rather that the payload is put into a "Data Packet"
without an IPv6 header and ICMPv6 header.  Is that intended?

section 7.3 s/bit sin/bits in/

section 7.5 seems jumbled... maybe just not done yet.

7.6 (and probably other places) say:
    "the RPL routing protocol"

which if you expand the acronym says:

      Routing Protocol for Low-power and lossy networks routing protocol

I think that it should be just "the RPL".  (I'm sure that this isn't the only
document that does this)

>   6TiSCH limits that interaction to RPL parents that will only
>   negotiate with other RPL parents, and performs that negotiation by
>   groups of cells as opposed to individual cells.  The 6TiSCH

Since "parent" is a relative term, inserting some ascii art:

     P1         P2      P3
      \        /       /
       \__  __/       /
          N1_________/
         /
        /
       C2

so, P1-P3 are potential parents for N1, and N1 is C2's parent.
(of course, N1 picks a specific parent, but the unpicked parents never find
out that were *not* picked, only the parent that was picked gets the DAO.)

So, if I limit "RPL parents that will only negotiate with other RPL parents"
am I limiting things to:
   P1<->P2, P1<->P3, P2<->P3

or am I limiting things to:
   N1<->P1, N1<->P2, N1<->P3?

======

Please clarify that a TSCH Schedule is a *set* of 2D matrices. Each matrices
is [slotOffset,channelOffset] sized slotframe, and determines how a
particular node assigns the chunks.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 5 May 2014 15:06:40 +0000

Hello Michael:

> (btw: typo: "s/HART of/HART or/")

[PT] Fixed for next rev :)

> end on the forwarding node?  In tunnel mode, it is clear that this is the case,
> but I'm asking about transport mode. 

[PT] The text in section 6.1 applies to both 6.1.1 and 6.1.2 which describe the 2 modes.

   "along the Track the short address for the
   destination is set to 0xFFFF.

   Conversely, a frame that is received along a Track with a destination
   MAC address set to this node is extracted from the Track stream and
   delivered to the upper layer."

So a frame with a dmac of this node is passed to the upper layer regardless of whether it is received on a track timeslot.
A frame with a dmac of 0xFFFF is switched if the track information is set to do so. In the terminating point of a track in transport mode, the track information indicates to punt to upper layer.
  
If you think that some edition is needed to clarify, please let me know and eventually please propose some text.

> Is there a real desire to build these tunnel mode tracks for "legacy" users of
> 15.4(e), such as ISA100.11a?  Or is just a conceptual statement that this
> could be done?  

[PT] This takes inspiration from the real world. 
E.g. ISA100 is explicitly designed to tunnel other protocols (wired or wireless) over an ISA100 wireless mesh, and that is an important feature for their customers.

> The appeal to drop-in 6tisch technology into an existing
> ISA100 network is appealing; but I wonder if it really work in practice due to
> security and addressing issues.  Can someone imagine mapping ISA100
> nodes into an abstracted (proxied) IPv6 address space?

[PT] As Tom points out, ISA100.11a is already IPv6 and 6LoWPAN, and have an IPv6 routing table  - but that's about it in terms of IPv6. 
Routing and Addressing are centralized. We could imagine a model with a common PCE, but interworking with RPL would be complicated

I think your question applies better to WirelessHART or HART. Yes, we could imagine a gateway that presents and IPv6 address for individual devices and maps them.
But the model of tunneling arbitrary protocols seems simpler and more generic.

> undone/redone.  Is that correct?

[PT] Yes, it is Correct

>     as well as "Extended Beacons"

[PT] Fixed, thanks

> without an IPv6 header and ICMPv6 header.  Is that intended?
[PT] There is an ICMP header; let me reword that. What about: 

"
            To broadcast ICMPv6 control messages used by RPL such as DIO or DAO,
            6top uses the payload of a Data frames. The message is inserted into the
            queue associated with the cells which LinkType is set to ADVERTISING.
            Then, taking advantage of the broadcast cell feature established with
            FrameAndLinkIE (as described above), the RPL control message can be 
            received by neighbors, which enables the maintenance of RPL DODAGs.
"
> section 7.3 s/bit sin/bits in/
[PT] yup

> section 7.5 seems jumbled... maybe just not done yet.
[PT] Yes, we need to raise an issue on this 

> I think that it should be just "the RPL".  (I'm sure that this isn't the only

[PT] Probably best to just say "RPL" ?

>    N1<->P1, N1<->P2, N1<->P3?

[PT] In your picture N1 is a parent that's all of the above P1<->P2, P1<->P3, P2<->P3, N1<->P1, N1<->P2, N1<->P3
This mechanism is yet TBD, but will probably look a lot like a ND DAD but applied to chunks as opposed to IPv6 addresses.

> ======
> 
> Please clarify that a TSCH Schedule is a *set* of 2D matrices. Each matrices is
> [slotOffset,channelOffset] sized slotframe, and determines how a particular
> node assigns the chunks.

[PT] Yes, there can be multiple matrices formatted globally in chunks that are later appropriated by devices

I'll need a number of issues : ) Let me open them.

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 May 2014 15:33:28 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    >    Conversely, a frame that is received along a Track with a
    > destination MAC address set to this node is extracted from the Track
    > stream and delivered to the upper layer."

    > So a frame with a dmac of this node is passed to the upper layer
    > regardless of whether it is received on a track timeslot.  A frame with
    > a dmac of 0xFFFF is switched if the track information is set to do
    > so. In the terminating point of a track in transport mode, the track
    > information indicates to punt to upper layer.

    > and eventually please propose some text.

I'll have to think about this.

    >> The appeal to drop-in 6tisch technology into an existing ISA100
    >> network is appealing; but I wonder if it really work in practice due
    >> to security and addressing issues.  Can someone imagine mapping ISA100

    > [PT] As Tom points out, ISA100.11a is already IPv6 and 6LoWPAN, and
    > have an IPv6 routing table - but that's about it in terms of IPv6.
    > Routing and Addressing are centralized. We could imagine a model with a
    > common PCE, but interworking with RPL would be complicated

    > I think your question applies better to WirelessHART or HART. Yes, we
    > could imagine a gateway that presents and IPv6 address for individual
    > devices and maps them.  But the model of tunneling arbitrary protocols
    > seems simpler and more generic.

yes, I was thinking of WirelessHART, but I wrote ISA100.

    >> In section 7.2, I might read that broadcast DIO and DAO are not
    >> contained in ICMPv6 messages, but rather that the payload is put into
    >> a "Data Packet" without an IPv6 header and ICMPv6 header.  Is that
    >> intended?
    >>

    > " To broadcast ICMPv6 control messages used by RPL such as DIO or DAO,
    > 6top uses the payload of a Data frames. The message is inserted into
    > the queue associated with the cells which LinkType is set to
    > ADVERTISING.  Then, taking advantage of the broadcast cell feature
    > established with FrameAndLinkIE (as described above), the RPL control
    > message can be received by neighbors, which enables the maintenance of
    > RPL DODAGs.  "

yes, works for me.

    >> 7.6 (and probably other places) say: "the RPL routing protocol"
    >>
    >> I think that it should be just "the RPL".  (I'm sure that this isn't
    >> the only document that does this)

    > [PT] Probably best to just say "RPL" ?

Yes.