Chapter 6 Fog Computing Trust Management
6.2 Fog Computing Trust Management Model
Before we dive into the Fog COMputIng Trust manageMENT (COMITMENT) details, it is worth mentioning the network environment adopted for the fog computing. The network topology adopted a distributed-based fog topology where nodes are physically distributed over different locations and connected to each other via a communication protocol forming a mesh networks. Thus every node has a unique identity address (e.g., IP), so the fog nodes are reachable to each other without a central controller to help resource sharing and service requests offloading. In addition, there is no centralised trust authority among fogs to point out the trusted nodes within the network, hence each fog node compute the trust evaluation periodically to its neighbouring fog nodes and stores the generated list of trusted fog nodes locally through COMITMENT. Here are some importance preliminaries that are required for COMITMENT.
• Fog Quality of Service (QoS): we refer to fog QoS as the ability of fog to achieve max- imum bandwidth (associated with the time to upload and download a packet τ) and deal with the service requests with minimal latency and low error rate. The problem preliminaries associated with QoS are the fog’s workload (fx), service workload on
fog (sfi
w) and the total time required to process a service (τs).
• Fog Quality of Protection (QoP): we refer to fog QoP as the degree to which the fog protects the received data during processing as well as transferring or sharing the data with other fogs. The QoP properties (e.g., service integrity and confidential- ity) are defined according to the type of processes and services provided by the fog. QoP problem preliminaries are associated with the proposed trustworthiness model and based on direct trust (τa,bd ) and recommendation/indirect trust (τa,br ).
• Fog Secure Service Level Agreement (SSLA): this refers to the commitment between two fogs in delivering a service according to a certain level of quality, availability and
protection. Thus, SSLA includes the problem preliminaries associated with both QoS and QoP. Thus, service requirements of both QoS and QoP should be provided by the collaborating fog nodes.
• Fog Requirements of Protection (RoP): is a set of security requirements which includes the security factors required for delivering the desired services, thus RoP defines and measures the QoP for a fog node.
• Level of Trust (LoT): is a score that refers to the trustworthiness among fogs. LoT is computed based on the previous coordinations experiences, and is periodically up- dated after each coordination. The problem preliminaries associated with LoT are the experience satisfaction score ESa,b, the α and β which logs the satisfied and un-
satisfied experience, respectively. LoT indicates the level of trust or distrust between the fogs, therefore, the LoT score used is based on a fuzzy logic where the score one is an indicator of absolute trust and the score zero is an indicator of absolute distrust.
COMITMENT is a software-based approach that is installed on each fog node within the fog layer. COMITMENT is responsible for providing a secure and trusted environment for fog nodes to share their resources and exchange data packets, COMITMENT architec- ture is shown in Figure 6.1. Thus, COMITMENT provides a concise decision for the fog node to point out the best fog node that it can cooperate with, more precisely the fog node that provide lowest latency (for best QoS and QoE) and secure data sharing and process- ing (for best QoP) during the f og-2-f og coordination. The decision not only includes the best fog node that can handle the jobs efficiently but also the most trusted fog nodes that could offer/provide best QoS (e.g., low latency) and best QoP (e.g., meeting the SSLA). The offloading model is to balance the workload and service traffic within the fog layer by distributing service requests from the congested fog node to another fog node in a secure manner. In order to enable COMITMENT to select the trusted node, it essential to assess both the QoP and QoS provided by the fog nodes that are possibly hosting the service deliv- ery. This can be achieved through checking the trust level of each fog node. The trust level is evaluated based on; i) a direct experiences which is based on direct interaction among the collaborating fog nodes in the past and/or present interactions along with different
Figure 6.1: Architecture of the proposed COMITMENT approach, including the different types of fog’s statuses and interactions
from neighbouring fog nodes in case of no previous experiences between the two fog nodes that are intended to collaborate with each other.
Obviously, the trust level will be computed based on the previous coordinations sat- isfactions, hence the self experiences obtained from direct interactions will always have a higher weight than recommendations from neighbouring fogs because the trustworthiness among fogs is subjective and asymmetric as per fog security requirements in Section 3.3. The most used notations in this chapter are given in Table 6.1. The main procedures and processes run by COMITMENT are categorised as follows:
1. Fog performance: COMITMENT periodically monitors fog’s resources (e.g., CPU consumption), active processes (e.g., stakeholder’s services processes), and the in- coming services requests traffic on the fog node. This process is to monitor fog per-
formance to identify resource exhausted services that potentially can be an attack. COMITMENT will trigger the load balancing function via offloading upon fog’s over- load detection, thus a trustworthy fog node can be called upon to handle the overload. This process is discussed further in Section 6.3.
2. Fog interactions: upon overload detection, COMITMENT has the responsibility to handle the process of finding the best neighbouring nodes that can handle the over- load securely and efficiently. This process includes assessing the trust level of the nominated fog nodes for sharing the overload. This process ensures that the QoP and QoS provided by the hosted fog node meets the SSLA standard of the service and user expectations about the desired service, for example, service run with no delay and assured data protection. This process is discussed further in Section 6.4. It worth noting that fog node’s failures during or before a cooperation is establishing is handled by FRAMES, as discussed in previous chapter (Section 5.2), the fog pinger utility will notify FRAMES upon a fog node being unresponsive (i.e., failure) and unable to handle processes, hence other fog nodes in the domain will be notified to act accordingly with both data feeds from FRAMES and COMITMENT.
Table 6.1: Notations used in the paper
Symbol
Description
t, n, T
thing, index of t, set of things
f , i, F
fog, index of f , set of fogs
λ
service arrival rate to fog layer
µ
fog node service rate
S, s
set of services, one service
s
wservice workload
s
fiw
service workload for fog node (f
i)
s
dservice deadline
τ
stotal time required to process a service
t
sservice’s tasks
rs
fog node resources
τ
queis the queuing time
τ
proservice processing time
ρ
system usage
τ
quesiqueuing time for s at the resources of fog f
if
cfog capacity
f
wfog workload
f
icprocessing capacity of the fog node f
if
rsstotal fog resources (rs) allocated to processes service (s)
D
ppropagation delay
τ
time to upload and download a packet
α
fa,fblogs the satisfied experience from f og
ato f og
bβ
fa,fblogs the unsatisfied experience from f og
ato f og
bES
a,bexperience satisfaction from f og
ato f og
bn
intnumber of direct interactions between the two fogs
r
fa,fbrecommendation of f og
atoward f og
bLoT (f
a, f
b) level of trust score of f og
atoward f og
bC
fits