OUTLINE:
Whitepaper:
Service Level Agreements Self-Assessment with Hyperledger Fabric
Purpose of This Paper
The purpose of this paper is to define a framework prototype for Service Level Agreements (SLAs) Self-Assessment on Hyperledger Fabric. The proposed approach incorporates SLA Self-Assessment on Hyperledger Fabric using Trusted Execution Environments (TEEs).
Knowledge gathered during earlier collaborative projects is leveraged, such as Fabric Private Chaincode[1].
Intended Audience
The intended audience comprises of various organization representatives, their developers, and their clientele, contracting with different SLA types. The proposed approach aims to cover dissimilar types of SLAs through a generic approach model where the requested actors' roles (e.g. service provider, service vendor, service seller, application provider, application client, customer, end-user, etc.) and contract activity are defined and addressed completely inside the dedicated framework.
1. Introduction
Service Level Agreement (SLA)
A Service Level Agreement (SLA) defines the promised service(s) of a business interrelationship between two (2) actor entities. A promised service is offered by the actor that provides the service to their customer that receives it. Particular parameters and metrics of such services include service availability, minimum Quality of Service (QoS), service up-time commitments (i.e. reliability), technical support responsiveness, etc. In case that the promised service metrics of the provider actor do not match to the actual offered service metrics of the customer actor (i.e. the receiver of the service), SLA violation(s) occur with possible legal consequences for the entity that provides them.
SLA Monitoring and Computation
The process of SLA Monitoring requires specific questions to be answered:
Which parameters are contained in the SLA?
How are SLA parameters computed?
Is the computation of the parameters in line with the definition of the provider actor?
In order to validly monitor an SLA, crucial points are found on the definition of the SLA parameters' values which acknowledge an SLA as violated, and on the ways through which the parameters' values are computed. The respective metrics computation are fully dependent on factors such as the sampling rate, the period of evaluation and the formula that calculates the parameters.
Envisioning the concept of SLA self-assessment, this whitepaper aims to present a securely computational privacy environment where the deployed agreements are monitored and their metrics computed inside the immutable ecosystem.
SLA Self-Assessment
The provider actor is able to propose different parameters that state an SLA definition and its parametric values, while the client actor engages confidently in a secure ecosystem where their metric data related to services consumption and utilization are characterized by integrity and precision. Computational transparency and privacy of metric data is assured through the dedicated computational workflow that adopts TEE properties. The entire SLA intelligence unfolds within TEE-deployed smart contracts ensuring the isolated and protected monitoring and computation of the SLA metric data. This framework prototype allows for the independent assessment of SLAs with agreed metrics rules prior to the contract commitment.
2. Existing Solutions
In relevant scientific research, the following approaches aim to solve important problems in neighboring scientific areas without addressing all the SLA assessment questions through a complete ecosystem that relies on transparency and privacy.
- Nguyen et al. [2] present an evaluating and enforcing architecture for SLA agreements based on distributed ledgers. Their approach relies on keeping the SLA assessment procedure safe and unmodified due to blockchain immutability while utilizing an automated SLA monitoring and computation process that takes place within the blockchain infrastructure and guarantees the successful completion of the SLA evaluation with status acknowledgment for the end-user. However, their solution does not perceive the system in a whole decentralization model, neglecting the possibilities for fairer agreements in terms of transparency and privacy.
Similar approaches are bounded by the same kind of models where the SLA intelligence lacks a holistic view, while privacy and transparency issues should be tackled. Ranchal and Choudhury [3] present an autonomous and trusted framework for unceasing SLA monitoring in multi-cloud ecosystems. In order to fairly detect SLA violations in a hierarchical system structure, their solution is aiming to address the SLA assessment procedure in a multilevel cloud environment with diverse regulations and laws. Furthermore, Alowayed et al. [4] propose a provider evaluation solution according to the providers’ commitments to their interconnection SLA agreements. Through a metric measurement mechanism the SLA scores are verified for each provider towards their on chain evaluation. By endorsing a privacy-preserving protocol for SLA agreements, it is pursued to objectively define the provider's SLA score and privately store it on chain in order for the interested end-user to access. - Other approaches suggest more focused solutions as far as the privacy of the blockchain participants is concerned, however, they still do not tackle entirely the on chain privacy of the user data from third blockchain parties. Uriarte et al. [5] present an SLA management framework that resolves the specification and enforcement of dynamic SLAs that track and define the service parameter which render SLAs changes over time. The proposed architecture manages to convert an SLA to its smart contract equivalent that dynamically unfolds service provisioning and sequentially generates objective measurements for the SLA assessment through a federation of monitoring entities. In similar research, Alzubaidi et al. [6] proposed on chain assessing SLA compliance and consequences enforcement through dependability validation. By employing a diagnostic accuracy method, trust is assumed in service providers in order to acknowledge SLA breach incidents and execute the corresponding compensations.
- Finally, other approaches try to address the related research area, however, they lack the kind of simplicity and utility in the system's workflow as far as the actor users participation is concerned. D’Angelo et al. [7] inspect the challenges for enforcing accountability in Cloud infrastructures where SLA violations form an important and usual circumstance while arguing that blockchains seem to establish a key contributor towards accountable Clouds. Also, Tan et al. [8] propose a novel performing and safe SLA model where the trust among the different actors are addressed through blockchain. There is a clear argument on lack of effective supervision for the third-parties that manage the monitoring and lack of efficient compensation mechanism on SLA violations. The presented model supervises the provider actors on the blockchain with dedicated smart contracts.
Author | Topic | Neighboring Area | SLA Self-Assessment on Hyperledger Fabric |
---|---|---|---|
Nguyen et al. [2] | SLA Assessment | SLA Evaluation | Private from Third-Parties |
Ranchal et al. [3] | Multicloud SLA | SLA Monitoring | Different Rules in Single Blockchain |
Alowayed et al. [4] | Cloud IaaS Evaluation | Privacy-Preserving Protocol | Distributed and Enclaved Operations |
Uriarte et al. [5] | Dynamic SLA | SLA Provisioning | Dynamic SLA Self-Assessment |
Alzubaidi et al. [6] | SLA Compliance | SLA Dependability Validation | Trustless of Cloud IaaS |
D’Angelo et al. [7] | Cloud Accountability | Blockchain SLA Monitoring | SLA Self-Assessment |
Tan et al. [8] | Performant SLA | Cloud IaaS Supervision | Without On-chain Intermediaries |
3. Architectural Approach
To be completed.
4. Framework Prototype Solution
To be completed.
5. Conclusions
To be completed.
References
[1] Hyperledger Fabric Private Chaincode: https://github.com/hyperledger/fabric-private-chaincode
[2] Nguyen, T.-V.; Lê, T.-V.; Dao, B.; Nguyen-An, K. Leveraging Blockchain in Monitoring SLA-Oriented Tourism Service Provisioning. In Proceedings of the International Conference on Advanced Computing and Applications (ACOMP), Nha Trang, Vietnam, 26–28 November 2019; pp. 42–50.
[3] Ranchal, R.; Choudhury, O. SLAM: A Framework for SLA Management in Multicloud ecosystem using Blockchain. In Proceedings of the IEEE Cloud Summit, Harrisburg, PA, USA, 21–22 October 2020; pp. 33–38.
[4] Alowayed, Y.; Canini, M.; Marcos, P.; Chiesa, M.; Barcellos, M. Picking a Partner: A Fair Blockchain Based Scoring Protocol for Autonomous Systems. Proc. Appl. Netw. Res. Workshop 2018, 33–39.
[5] Uriarte, R.B.; Zhou, H.; Kritikos, K.; Shi, Z.; Zhao, Z.; De Nicola, R. Distributed service-level agreement management with smart contracts and blockchain. Concurr. Comput. Pract. Exper 2021, 33, e5800.
[6] Alzubaidi, A.; Mitra, K.; Patel, P.; Solaiman, E. A Blockchain-based Approach for Assessing Compliance with SLA-guaranteed IoT Services. In Proceedings of the IEEE International Conference on Smart Internet of Things (SmartIoT), Beijing, China, 14–16 August 2020; pp. 213–220.
[7] D’Angelo, G.; Ferretti, S.; Marzolla, M. A Blockchain-based Flight Data Recorder for Cloud Accountability. In Proceedings of the 1st Workshop on Cryptocurrencies and Blockchains for Distributed Systems, Munich, Germany, 15 June 2018; pp. 93–98.
[8] Tan, W.; Zhu, H.; Tan, J.; Zhao, Y.; Xu, L.D.; Guo, K. A novel service level agreement model using blockchain and smart contract for cloud manufacturing in industry 4.0. Enterp. Inf. Syst. 2021, 1–26.
License
This work is licensed under a Creative Commons Attribution 4.0 International License, creativecommons.org/licenses/by/4.0.
Acknowledgements
Kapsoulis, Nikolaos
Psychas, Alexandros
OLDER Content
The steps of an SLA can be introduced as follow:
1- Negotiation and agreement: An essential step to agree on an SLA is quantifying the service levels using performance metrics. For instance in ISP/Customer SLAs, the service uptime is typically provided by a percentage e.g., 99.999%.
The other vital part of an SLA is the clear description of the consequences of the breach of contract for the parties involved e.g., penalties, compensations etc.
2- Enforcement: The perfect SLA, if not accompanied by an efficient enforcement tool, would not satisfy the parties involved. The enforcement of the SLAs has many challenges:
a- Different interpretations of the SLA
b- Different measurements of the performance metrics (especially the metrics such as latency which are not very straightforward to measure)
c- Manual monitoring of the SLA parameters at all times.
d- SLA violation detection
Both of the above-mentioned steps to assure the operation of an SLA are currently done manually between the telcos.
1.1 SLA Record-keeping
The distributed ledger technology built into the Hyperledger projects can bring trust to the record-keeping process in SLA monitoring and management. In other words, the measurements of the quality parameters along with the SLA violation incidents can be kept as immutable records in the distributed ledger.
1.2 SLA Enforcement
Smart Contracts could benefit greatly from the smart contract technology through automation of the enforcement process. For instance, a chaincode can define a set of SLA violations and their subsequent penalties (this could be done through a financial transaction built into the chaincode) therefore automating the enforcement process and bypassing the manual process of the SLA enforcement.
1.2 SLA Monitoring Metrics
Typically in addition to the service description, a SLA includes a number of metrics in which the service is measured. In the Telecom industry the metrics based on which the SLA is agreed upon are as follows:
- Mean Time to Respond - The average time it takes to recover from a service failure from the time the failure was detected
- Mean Time to Resolve - The average time it takes to fully resolve a service failure
- Service Availability - The percentage uptime of the service or link
As an example, an SLA between a Tier1 and a Tier2 Telco could specify 20 minutes for Mean Time to Respond, 4 hours for Mean Time for Fault Resolution and 99% for Service Availability.
2. The Blockchain Framework
We use Hyperledger Composer to implement the proof of concept application of SLA Management over the blockchain. The reason behind this choice is:
a- Simplicity of writing chaincodes using Hyperledger Composer
b- Hassle-free application development without worrying about the deployment details of the blockchain network.
c- Hyperledger Composer's features such as the REST API and the Angular APP
3. The Business Network
This business network consists of the following components:
Roles:
Originator
ServiceProvider
Vendor
enum Role { o Originator o ServiceProvider o Vendor }
Participants:
ServiceProvider
ServiceVendor
Customer
participant ServiceProvider identified by providerId { o String providerId o String name } participant ServiceVendor identified by vendorId { o String vendorId o String name } participant Customer identified by custId { o String custId o String name }
Assets:
TroubleTicket
asset TroubleTicket identified by incidentId { o String incidentId o String vendorTicketId optional o String type o Severity severity o String description o DateTime creationDate o String status o DateTime acknowledgedDate optional o DateTime resolutionDate optional o DateTime targetAcceptedTimestamp optional o DateTime targetClosedTimestamp optional o String acceptanceSLA optional o String closureSLA optional o Note[] note optional -->ServiceProvider SP -->ServiceVendor SV optional -->Customer C }
Transactions:
CreateTicket
AssignVendor
UpdateTicket
ResolveTicket
CloseTicket
transaction CreateTicket{ --> Customer C --> ServiceProvider SP --> ServiceVendor SV o String incidentId o String type o Severity severity o String description o DateTime creationDate o String status } transaction AssignVendor{ --> TroubleTicket ticket -->ServiceVendor SV o String status o DateTime statusChangeDate o String statusChangeReason } transaction UpdateTicket{ --> TroubleTicket ticket
-->ServiceVendor SV o String status o DateTime statusChangeDate o String statusChangeReason } transaction ResolveTicket{ --> TroubleTicket ticket
-->ServiceVendor SVo String status o DateTime resolutionDate o String statusChangeReason } transaction CloseTicket{ --> TroubleTicket ticket
--> ServiceProvider SP o String status o DateTime statusChangeDate o String statusChangeReason }
Testing:
To test this Business Network Definition in the Test tab on the playground or in your Angular app:
1- In the Customer
, ServiceProvider
, ServiceVendor
participant registry, create new participants with appropriate input values.
Alternatively, you can also use the SetupDemo
transaction which would populate the network with 2xCustomers, 2xServiceProviders, 2xServiceVendors.
2- Create a ticket using the Submit Transaction
button and fill in the information based on the created participants. Upon submission, you should see a new asset added to the asset lists under 'TroubleTicket'.
4. SLA Back & Front-End
The following figure shows the Participants in the app and the process of creating them.
The following figure shows the Transactions in the app and the process of invoking them.
OLD Content
This section describes an earlier application interface for the SLA solution including prints of the service provider -and vendor screens.
Back-end on Bluemix (Demo Transaction) :
Front-end interface:
Green = Service Provider screen
Purple = Vendor screen
Item 1
Item 2
Item 3
2.1 Ticket creation - service provider
From the provider screen, click 'Create'
2.2 Enter details and save
Enter the ticket details and click 'Save'
2.3 View created ticket
The ticket is created and the details are displayed. Note that the SLA details have been calculated by the blockchain.
2.4 Go back to List view
Vendor view
The Vendor views are displayed below
4.1 Refresh list to see new ticket
4.2 View the ticket
The details have been read from the blockchain
4.3 Accepting vendor ticket
Update the ticket by changing the status to Acknowledged, entering a comment and saving the ticket
Tickets appearing in service provider view
The following screens show the consequent service provider view
5.1 Notification on the service provider ticket
A notification appears indicating that the ticket has been updated
5.3 view the updated service provider ticket
Click on 'show' to see the update and the ticket has been set to acknowledged, and the Acceptance SLA has been calculated - in this case it has failed.
5.4 Vendor Updates
Going back to the Vendor view, we can resolve the ticket and set a comment and save
Note that the closure SLA is also being calculated
5.5 Service Provider move back in progress
On the service provider side you can close the ticket or put it back in progress
If you put it back in progress, the closure SLA status is cleared. You can then resolve the ticket in the vendor system.
Conclusions
This white paper explained... [sum up the white paper briefly. This section “tells them what you told them.” Although this may seem repetitive, some people flip to the back of a document to see “the bottom line” and what they might have missed.]
Further Resources
[In this section, list any further resources or interesting reading that might illuminate the topic more. Include enough detail so that a reader could easily locate that source, including URLs if appropriate.]
Notes
[Although GDocs can’t do Endnotes, the designer will move all your footnotes here. In every footnote, provide the AUTHOR(s), the article or document TITLE, the PUBLISHER, the DATE, and if you have it, the PAGE NUMBER. For a website, include the URL and RETRIEVED ON DATE.]
POINTS TO COVER
- Motivation / Problem
- Barriers
- Customer Groups
- Opportunities
Solution:
Platform
Team
Road map- Mission
- Use Cases
- Conclusion
This work is licensed under a Creative Commons Attribution 4.0 International License
creativecommons.org/licenses/by/4.0
Acknowledgements
[list all the contributors to the white paper in alphabetical order by LAST name. Many working groups keep a list of members or contributors on their wiki pages or their minutes. Don’t include anyone’s name without their okay.]
Whitepaper Standards Contributed by Learning Materials Development Working Group, Gordon Graham and Bobbi Muscara