## 4 Our System Design
### Labeling Tables, Forwarding Tables, and Data Flow Control Policy Enforcement  
Our method starts with a network representing an application layer configuration of directly connected application entities, defining a _Channel_ relation. Following the principles presented in Section 3 and in the papers cited there, the equivalence classes of entities in the network are identified, and the resulting reduced graph is a partial order of equivalence classes. Labels are then assigned to the equivalence classes, which become the labels of the entities in each class. These labels can be simply obtained by set union, proceeding from source to sink. For example, if the label of a source equivalence class contains the name _BobPulse_, then all equivalence classes that dominate it will also contain this name in their labels. As mentioned, the necessary calculations are automatic, starting with the _Channel_ relation [20]. The network obtained in this way will not be in the form of a _centralized_ cloud-based configuration since application entities will be shown as communicating directly and not through the Cloud. So, the next step, in addition to the method described above, is to create the cloud infrastructure. This will be done by assigning at least one _storage entity_ (in practice, a server or database) to each equivalence class of entities. Hence, in our architecture, data are sent simultaneously to application entities and their associated storage entities for permanent storage. The partial order of equivalence classes will be unchanged, with storage entities added to equivalence classes. The collection of these storage entities forms the Cloud and implements the Networking Layer of the IoT. At this point, we note that names in labels can be replaced by entity names. For example, if a name such as _BobPulse_ denotes data originating from an entity (a sensor) named \(A\), then each occurrence of _BobPulse_ in labels can be replaced by the name \(A\). The label-inclusion relationship remains the same. These new labels based on entity names will directly provide the routing information needed to configure the SDN routers. They are compiled in labeling tables in the following way: For entities \(x\) and \(y\), we say that _x_\(\in\)_Holds_(_y_) _iff Label_(_x_) _\(\subseteq\) Label_(_y_). A labeling table will have a line for each entity \(y\) in the network and a column _Holds_ containing, for each \(y\), the set of \(x\) such that _x_\(\in\)_Holds_(_y_). For the controller, _x_\(\in\)_Holds_(_y_) means that data in entity \(x\) can be forwarded to entity \(y\). The programming of SDN routers is then immediate. Forwarding tables contain the command _forward_ if a packet should be forwarded from one entity to another. For each router, we implement a forwarding table that includes the entities that are connected to it. We assume that we deal with routers with arbitrarily large capacities. Average routers in use today can have up to 250 entities connected to them [31], but this number can be increased by connecting routers sequentially (in cascade). Many modern routers adapt automatically if a port is connected to another router. These technical details are ignored here because they depend on the technology available, which is rapidly evolving. Of the several columns a forwarding table may have, we need only the columns _Match Rules_ and _Action_. Each packet will have a source and a destination header. If in the labeling table _x_\(\in\)_Holds_(_y_), then the controller will create in the router a flow entry using the _IPAD_ (_x_) source (_IP src_) and _IPAD_ (_y_) destination (_IP dst_) in match rules and define the forward action for such a pair since this is an authorized flow. When a packet arrives at the router, the router will compare the _IP src_ and _IP dst_ in the packet headers. If there is a forwarding rule, the router will perform it. Otherwise, the packet will be dropped.