Additionally, for the RTM aspect of our collaboration framework, we focus on Multi-Criteria Decision Making (MCDM) techniques for quantifying trust and computing reputation values. In the second part of the thesis, we address the challenges in service life cycle management.
Cloud Computing
Finally, the network can be programmed through software applications running on top of the SDN controller. In addition, applications can dynamically take action and reconfigure any part of the network at any time.
Service Life-Cycle Management
In such frameworks, the efficiency, reliability and trustworthiness of the service and its provider can be quantified and provided to users. This can be done with trust algorithms using a combination of service monitoring data and user ratings so that a quantified metric can represent the quality of service and the quality of experience (QoE) of users using the service. This can be achieved by using consensus mechanisms that ensure the outcome in a secure manner.
Challenges & Motivation
In addition to the possibility of trusted marketplaces, it is easily concluded that a trust management framework also assists the user in the selection stage. Mitigating Malicious Actors: Since the manipulation of assessment values of the resources has huge economic incentives for adversaries, it is of great importance to provide mechanisms to protect honest providers and users. Service Provisioning, Discovery and Leasing: In a multi-tenant multi-vendor environment, it is important to provide mechanisms for users to provision self-lease services in an automated manner.
Contributions
The use of heterogeneous resources poses complex demands at every stage of the life cycle. Service Level Agreements specifically establish the consensus on the characteristics of the service to be provided between the service provider and the user of the cloud service. In the cloud application lifecycle, trust management facilitates resource selection and performance evaluation of the cloud application or provider.
Related Work
- Cloud SLA Management
- Trust Management for Web Services
- Trust Management for Ad-Hoc Networks
- Trust Management for Cloud Computing
- Trust Management for SDN and NFV
- Trust Management for Peer to Peer Networks
- Trust Management for Heterogeneous Resources
Both solutions have a collaborative SLA and a reputation-based approach to trust management, which we call Hybrid Reputation Systems. Several approaches have been proposed for reputation and trust management in wireless sensor and ad hoc networks. The ROCQ mechanism [63] proposed a reputation-based trust management system that produced reputation values to represent the trustworthiness of peers in P2P networks.
Contribution & Outline
The vast majority of the approaches mentioned above focused only on a certain type of resource. The reputation score consequently facilitates the selection of appropriate services and resources for future users based on their needs. Credibility mechanisms are developed to protect the results of RTM frameworks from biased evaluations and attacks.
Cloud Application Life-Cycle and Collaborative SLA-RTM architecture
Cloud Application Life-Cycle Management
This functionality enables the optimal redistribution of resources after application decommissioning, termination or termination of the application. During the deployment of the application, the SLA is activated and continuously evaluates the performance of the application (audit level). The RTM service is also included in the audit process, as it periodically invites users to submit their evaluations about the status of the application.
Collaborative SLA and Reputation Architecture
Finally, in the final stage, the SLA ends and the final rating is sent to RTM service. As for the RTM service, the Reputation Dashboard provides a GUI to both customers and administrators. HRS is the core component of the reputation service and is responsible for calculating the reputation score of each supplier.
Service Level Agreement Management
SLA components
Overview of the SLA Life-cycle
Notifier Adapter is a custom component responsible for communicating events (eg violations and penalties) to interested entities through the SLA Collector. Subsequently, the SLA Collector sends the agreement to the SLA Management module of the selected supplier to be stored internally and evaluated to the cloud. The detected violations are stored internally and sent to the SLA Collector component, which includes a notification/subscription service to communicate violations to any interested entity, i.e.
SLA Assessment
After the application instantiation, the assessment of the agreement starts and the customer is notified. Depending on the type of cloud application, there is flexibility regarding the configuration and execution of the assessment. In addition, the evaluation can be performed using single values (e.g. response time for a specific time stamp) or by aggregated values (e.g. average availability of the service).
Fuzzy VIKOR based Trust Management
- Fuzzy VIKOR
- User’s Credibility
- Evaluation
- Fuzzy VIKOR Evaluation
- Comparison with FTUE framework
Thus, for the QoS KPIs, the user's opinion is correctly modified to x˜ by the credibility mechanism in the following subsection. Then, the evaluation index Q˜i contains the fuzzy reputation score of the cloud user and . Figure 2.7 also shows that the credibility mechanism plays a key role in the robustness of the reputation system.
Modified Fuzzy AHP based Trust Management
- Modified Fuzzy Analytical Hierarchical Process
- Credibility Mechanism
- Evaluation
- Proof of Concept
- Effect of Credibility Mechanism
The cloud provider determines the technical (QoS) and user experience (QoE) KPIs and attributes used in calculating the reputation score of the offered application. For each cloud provider KPI, the threshold and correction vectors are initialized (lines 4-5). As can be seen, the activation of the credibility mechanism for both testbeds leads to an increase in the reputation score by 20%.
Conclusions
It was also shown that using the credibility mechanism improves the performance of the reputation service by 20%. The next layer down is responsible for processing the high-level information of each service chain and automating the resource orchestration of the network services. The process by which the blocks are produced guarantees the immutability, data integrity, non-repudiation and security of the Blockchain ledger.
Related Work
In [100], a Blockchain-based resource broker mechanism is proposed for end-to-end deployment to secure transactions in the resource auction procedure. In [103], a proof of concept Blockchain-based implementation is presented using distributed applications in the context of operational phases to support multi-administrative domain networks for multi-domain service orchestration. The authors also analyze three use case scenarios (MEC, 3GPP and ETSI-NFV standards) that discuss standardization opportunities around Blockchain-based DApps as enablers of multi-domain network services.
Contribution & Outline
This mechanism is built on top of the Open Platform for Network Function Virtualization (OPNFV) [102]. At the user layer, we specify the essential functions, i.e. registration, service discovery, service rental and billing, for both network service providers and consumers to become market stakeholders. We provide proof of concept results that demonstrate the applicability and efficiency of the proposed approach in terms of deployment time and reserved resources.
Network Service Marketplace Architecture
NFV-Related Definitions
A network service consists of one or more VNFs, in which the required functionality of the service is implemented. This segment will contain two new NSs, namely Network Service-2-1 and Network Service-2-2, and the shared NS of the first network segment, Network Service-Shared. A shared NS connection point is needed to create a virtual link between the shared NS and the vld-2, the virtual network of the second network slice.
System Architecture
The user layer provides the essential functionality required for users to interact with the NSM, as shown in the left panel of Figure 3.2. The Blockchain layer also forwards all cross-service orchestration requests and information to the NFV layer's Service Orchestrator, which is thoroughly analyzed in Section 3.5.2. In line with the ETSI-NFV architecture, the NFV layer is responsible for instantiating network services and establishing cross-service communication.
Network Service Marketplace Operations
Marketplace Functionality
As depicted in Figure 3.3, when a user requests a lease, the client invokes the registry function of the smart contract. Then the smart contract checks if the requested service for leasing exists in the ledger. If any of the above validations fail, the smart contract returns the appropriate error message to the client.
Service Data Store-Blockchain Functionality
In particular, the NsdName argument indicates the name of the service's network slice descriptor, which contains all the information and descriptions for deploying the slice. A slice object in the ledger that contains information about the provider's network slice and the tenant it belongs to. The Grantor and Recipient attributes refer to the provider and consumer network slice descriptors for orchestration purposes.
Network Service Lease and Orchestration
Network Service Lease
Second, by storing only the name of the descriptor, rather than all or part of its information, we maintain the minimum amount of data in the data store.
Network Service Lease Orchestration
To update the client's NSTD, we need the information stored in thenetslice-subnet object, which corresponds to the iattribute, and thenetslice-vld objects for the corresponding connection points of the desired service. The updates in the descriptor refer to the addition of the shared service object of the net slice subnet field in the JSON file, and the corresponding connection point attachment on a management network and a data network of the client slice. The additions are made in the consumers' YAML NSTD file, in the corresponding fields.
Experimentation and Results
Furthermore, the proposed architecture focuses on minimizing the necessary computing and network resources for inter-service orchestration. For example, in typical interleaved communication solutions, an intermediary network part is deployed to establish communication between the provider part and the consumer part [86]. However, the resources of an EC are limited and the existence of many parts with CSC peers leads to the allocation of a significant number of resources to the core parts of the intermediate network.
Conclusions
The rest of the time is consumed by the operations done by OSM and the according VIM to instantiate the CSC. Throughout this thesis, we have discussed and addressed challenges in the lifecycle management of services in a federated edge cloud environment, while enabling trust between involved parties in such a context. Experimentation on real infrastructure and simulations demonstrate the better performance compared to others proposed in literature, the importance and robustness of the credibility mechanisms and the high importance of mixing various numerical and fuzzy metrics in the calculation of the.
Future work
Everything you need to know about fog computing and related edge computing paradigms: a complete overview. On multi-access edge computing: An overview of emerging 5G network edge cloud architecture and orchestration.IEEE Communications Surveys & Tutorials. Where there's fire, there's SMOKE: a scalable edge computing framework for early fire detection.
Brief comparison of CC and EC
Fog/Edge and cloud trade-offs and Layered architecture
Network slicing with EC for different applications
Cloud Application Life-Cycle in Federated Clouds
Architecture of SLA and RTM Service in cloud federation
SLA Management Module
SLA Life-cycle sequence diagram
SLA assessment sequence diagram
Modified Fuzzy VIKOR Reputation Model for Federated Clouds
Credibility mechanism effect in fuzzy VIKOR reputation system
The effect of α parameter on the modified fuzzy VIKOR method
Comparison of fuzzy reputation system with FTUE framework
HRS Model for Federated Clouds
Graphical Presentation of the degree of possibility
Scenario 1 Architecture
Scenario 2 Architecture
Application’s Response Time
Credibility Mechanism’s Effect in HRS
Cross-Slice Communication Using a Shared Network Service
Network Service Management Architecture
Register Lease Smart Contract Function