It is always nice when a plan comes together, by John Day (with help)

One goal of RINA is to distill a theory based on fundamental principles, on what the problem tells us. Largely, this has come down to finding the invariances. The RINA Reference Model describes that theory, as we now understand it. We have found that by not breaking the invariances we don’t encounter “devils in the details,” but quite the opposite, the theory tends to yield simpler results for thorny problems. But we are always testing it. Trying to uncover things we haven’t seen. Trying to find holes in the theory.  As Miguel Ponce de Leon said at a recent workshop, “The purpose of the PRISTINE project [actually all of our projects] is to prove [RINA][1] wrong!”  We can’t prove a theory right; we can only prove them wrong. So we are always looking for questions, requirements that might uncover something that will break the theory.

This past Spring an advanced networking course[2] at Boston University took as a class project to survey so-called IoT protocols (Internet of Things)[3] to test the claim that the RINA EFCP (Error and Flow Control Protocol) can be configured to cover any requirement. Or would some necessary requirement of IoT break the theory?

Because IoT protocols have limited functionality, there is a tendency to include only the functionality absolutely necessary. Consequently, they operate under very tight constraints of cost, bandwidth, power, tight resources on computing and memory, etc. IoT protocols try to be as minimal as possible, to cut every possible corner. If any protocols would provide exceptions to claims that EFCP was a universal data transfer protocol, IoT should be prime candidate.  The class surveyed over 10 different IoT protocols, including Bluetooth, WiFi, Zigbee, Modbus, Wireless Hart, ISA100.11a, Near Field Communication, Z-wave, etc.

At first glance, it might appear that IoT protocols easily invalidate the claim.  A number of IoT devices and their protocols are defined to support a single application, which does a request/response (or stop-and-wait, depending on one’s perspective) over a point-to-point media, without any kind of connection-id, i.e. no port-ids or connection-endpoint-ids and seldom bother with connection establishment.  This certainly doesn’t sound like it is consistent with EFCP.

But it is.  They are a very neat degenerate case.  Lets consider it more carefully.

Probably the most important aspect of the IPC Model applicable to this analysis is Richard Watson’s proof that the necessary and sufficient condition for synchronization for reliable data transfer is impose an upper bound on 3 times:  Maximum Packet Lifetime, MPL; Maximum time to wait before an Acknowledgement is sent, A; and the Maximum time to exhaust retries, R. Watson’s result also implies that port allocation and synchronization should be distinct.[4] This is fundamental to all data transfer prtocools. Building on that result, the EFCP for RINA separates mechanism and policy and uses the distinction between abstract and concrete syntax to create a configurable error and flow control protocol that naturally cleaves between data transfer and data transfer control, i.e. retransmission and flow control. Our claim is this protocol can be configured so that it is the only data transfer protocol needed.

Now lets look at each of the three phases of the communication:

Enrollment consists of the operations necessary to create sufficient state in the network to support allocating an instance of communication. The Enrollment Phase determines whether the IoT device is allowed to join a layer and, if so, to assign it an address for use in that layer and any initial parameters required.  For this, the device needs a serial number assigned at manufacture.[5] Identifiers should not be overloaded with different semantics. A device identifier should not be used as a network address.[6]  The global scope of MAC addresses has led to their wide use as both device-id and address.  This constitutes a security threat. We strongly suggest moving away from even wireless addresses with large scope. Some IoT protocols, e.g. WiFi and Bluetooth have explicit enrollment phases,[7] which improves their security. For some, enrollment is an ad hoc procedure.[8]

Allocation creates the shared state to support a particular instance of communication, also called establishment.  With only a single application with a single point-to-point flow, addresses are sufficient to identify the flow.  Explicit connection-endpoint-ids are not required.  Similarly, port-ids are not required between the application and the protocol state machine because there are not multiple flows to distinguish.  Addresses will be required for multi-access media, but for wired point-to-point no addresses are required. Also, no “establishment phase” is required. Port allocation is implicit. When there is data to send, it is simply sent. Synchronization and reliability is assured by the bounds on the 3 times.  It just works.

Data Transfer:  It is straightforward to show that any stop-and-wait protocol with rules similar to 802.11 operating directly over the physical media satisfies the requirements of Watson’s necessary and sufficient conditions, so the data transfer is reliable or fails completely.[9]

IoT is simply a degenerate case of the more general EFCP.  The only real reason for different protocols is as a barrier to competition.

The most important result from this exercise is that the IoT environment is a degenerate case of the EFCP structure. No special cases occur. When the aspects not needed are null, the protocol is not affected. Every thing just works in a very nice and satisfying way. We had not recognized the possibility of implicit CEP-ids or port-ids nor of synchronization in the degenerate case.[10]  While not earthshattering, it is yet another ‘failure’ to prove the theory wrong, and increase our confidence that it is ‘right.’ Until next time!

It is always nice when a plan comes together.[11]