Subject: [6tsch] layering vs protocols

From: Tom Phinney <[email-masked]>
Date: Wed, 17 Apr 2013 11:45:52 -0700

I'd like to support Michael Richardson's view on
this subject. Consider a standard IPv4 or IPv6 protocol stack,
with some kind of PHY+DL for moving bytes between physically
separated devices, IPv4 or IPv6 for routing, UDP or TCP (etc) for
data conveyance, and various application protocols that use those
lower layers to transport information between those applications.
In diagramatic form, where the numbers are the layers of the OSI
reference model, what we usually see is

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

|
Application protocols     | 7

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

|
End-to-end
transport
| 4

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

|
Routing (packet switching)   | 3

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

| Point-to-point data conveyance | 2

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

|
Physical symbol signaling   | 1

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

It is possible to add a sublayer to any of these, either above or
below the primary layer. For example, one could add forward error
correction between layers 1 and 2, or 6LoWPAN subrouting between
layers 2 and 3, or actively-redundant multi-path transmission for
diversity between layers 3 and 4, or fountain coding of multicast
messaging between layers 4 and 7.

When any such sublayer is present there must be information in the
PDUs (protocol data units) that are sent and received by a layer to
indicate whether the sublayer is to be invoked, or not. That
information could take the form of explicit symbols in the layer PDU
(i.e., bit fields or code points when at layer 2 or above), or it
could be associated by configuration with specific destination or
source address information contained within the PDU.

By way of analogy, HTML that is to be exchanged between humans might
specify the human language in which the message is written (e.g, use
of XML to designate the language) or the language might be known by
prior agreement based on the addressees. Many of us on this list
read and write multiple languages, but by prior agreement we use US
or UK English for postings to this list.

When considering the protocol stack shown in the above figure, or of
any derived stack that also contains additional sublayers, those
layers and sublayers often require management, both before and
during use. Thus there will be management protocols for those layers
and sublayers. Those management protocols do not themselves
constitute additional sublayers, even though packet sniffing will
produce evidence of their use, and may often find PDUs at some layer
that contain specific messaging for a management protocol.

-Tom

---

From: <[email-masked]>
Date: Thu, 18 Apr 2013 09:21:17 +0000

Sorry I missed your mail (with new, appropriate Subject) before replying to the “minutes WebEx 12 April 2013” thread.
>When considering the protocol stack shown in the above figure, or of any derived stack that also contains additional sublayers, those layers and sublayers often require >management, both before and during use. Thus there will be management protocols for those layers and sublayers. Those management protocols do not themselves >constitute additional sublayers, even though packet sniffing will produce evidence of their use, and may often find PDUs at some layer that contain specific messaging for >a management protocol.
I believe my post concurs with you statement.

Dominique

De : [email-masked] [mailto:[email-masked]] De la part de Tom Phinney
Envoyé : mercredi 17 avril 2013 20:46
À : [email-masked]
Objet : [6tsch] layering vs protocols

I'd like to support Michael Richardson's view on this subject. Consider a standard IPv4 or IPv6 protocol stack, with some kind of PHY+DL for moving bytes between physically separated devices, IPv4 or IPv6 for routing, UDP or TCP (etc) for data conveyance, and various application protocols that use those lower layers to transport information between those applications. In diagramatic form, where the numbers are the layers of the OSI reference model, what we usually see is

+--------------------------------+
|      Application protocols     | 7
+--------------------------------+
|       End-to-end transport     | 4
+--------------------------------+
|   Routing (packet switching)   | 3
+--------------------------------+
| Point-to-point data conveyance | 2
+--------------------------------+
|    Physical symbol signaling   | 1
+--------------------------------+

It is possible to add a sublayer to any of these, either above or below the primary layer. For example, one could add forward error correction between layers 1 and 2, or 6LoWPAN subrouting between layers 2 and 3, or actively-redundant multi-path transmission for diversity between layers 3 and 4, or fountain coding of multicast messaging between layers 4 and 7.

When any such sublayer is present there must be information in the PDUs (protocol data units) that are sent and received by a layer to indicate whether the sublayer is to be invoked, or not. That information could take the form of explicit symbols in the layer PDU (i.e., bit fields or code points when at layer 2 or above), or it could be associated by configuration with specific destination or source address information contained within the PDU.

By way of analogy, HTML that is to be exchanged between humans might specify the human language in which the message is written (e.g, use of XML to designate the language) or the language might be known by prior agreement based on the addressees. Many of us on this list read and write multiple languages, but by prior agreement we use US or UK English for postings to this list.

When considering the protocol stack shown in the above figure, or of any derived stack that also contains additional sublayers, those layers and sublayers often require management, both before and during use. Thus there will be management protocols for those layers and sublayers. Those management protocols do not themselves constitute additional sublayers, even though packet sniffing will produce evidence of their use, and may often find PDUs at some layer that contain specific messaging for a management protocol.

-Tom

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 19 Apr 2013 11:06:25 +0000

I think that this discussion misses the point that 6TUS effectively acts on the air and that the time at which a frame is issued is as significant as an actual octet in a frame or an electromagnetical effect on the PHY layer.
One very important aspect of 6TUS is the concept of track. In (G)MPLS parlance, a track is a Label Switch Path, and a 6TSCH router is an LSR.
It is up to the 6TUS layer, based on the time slot a frame is received, to switch it onto another time slot or punt it to L3.

RFC 3945:

   3. Time-Division Multiplex Capable (TDM) interfaces:

      Interfaces that switch data based on the data's time slot in a
      repeating cycle.  An example of such an interface is that of a
      SONET/SDH Cross-Connect (XC), Terminal Multiplexer (TM), or Add-
      Drop Multiplexer (ADM).  Other examples include interfaces
      providing G.709 TDM capabilities (the "digital wrapper") and PDH
      interfaces.

I’ve always seen MPLS considered as a layer.

Now, it is true that there is also a protocol aspect, in particular we need a 6TUS protocol to negotiate a time slot with a next hop…

Let us sync at the call.

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: jeudi 18 avril 2013 11:21
To: Tom Phinney; [email-masked]
Subject: Re: [6tsch] layering vs protocols

Dominique

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] De la part de Tom Phinney
Envoyé : mercredi 17 avril 2013 20:46
À : [email-masked]<mailto:[email-masked]>
Objet : [6tsch] layering vs protocols

-Tom

Thank you.