This specification involves two resources: Service Level Agreement "SLA" and "SLA Violation"
This Service Level Agreement "SLA" Resource Model aims at illustrating the way to translating "SLA Resource Model" in JSON representation, reflecting the resource aspect described in the "SLA API Profile" (Management Requirements) document V0.2. Service Level Agreement (SLA) Resource Model and associate attributes are aligned with those described in SID Service Level Agreement modeling. Meaning no Resources are imported from other sources. Besides, the entities are represented in terms of roles, each with its rights & duties covering Multi-partner model illustrating B2BX model (SLA Provider, SLA Consumer, SLA Auditor, EndUser roles). In this model, "SLA Provider" is referring to a CSP while "SLA Consumer" is referring to a DSP. The "EndUser" is referring to the customer of the DSP, in some cases he could be a customer of both (CSP and DSP). "SLA Auditor" role is to monitor SLA as described in TR178V2. It could be played either by the CSP himself or delegated to a 3rd party. The "Agreed" or "Approved SLA" is described in terms of SLA rules which contains the Metrics, their related values or range, thresholds, valid period or date, consequences in case of violation of any clause of the SLA. It is also assumed all Metrics are the existing ones which are stored in the Service Provider "Metrics Library" with their attached references. Besides, each metric is attached to a given Product in the Catalogue with a dedicated reference e.g. "URL". The Service Level Agreement "SLA" resource model is also characterized by its "validity period". This use case covers the situation where the validity period is pre-determined (planned) which excludes the case of Time-variant SLA that could be attached to a "SLA on-Demand" use case. The latter could be considered in another release for specific use cases (Cloud, virtualization) for instance.
In order to optimize the SLA resource, there is a need for defining a common pattern or Template "rule". This pattern is structured as following: the Id of the metric, its name, the measurement unit attached to the considered metric, its reference value, the tolerance value when the threshold is crossed and the consequence in case of violation. Regarding the financial-related aspect and penalties associated to a consequence, a pointer is simply mentioned to the Service Level Agreement "SLA" contract.
Example of the JSON representation of an Service Level Agreement "SLA" resource
{ |
Field | Description |
id | Unique identifier of the Service level Agreement (SLA) |
name | Name of the Service level Agreement (SLA) |
description | Description of the Service level Agreement (SLA) |
version | Version of the Service level Agreement (SLA) |
validityPeriod | Period where the clauses of the SLA are applicable |
startTime | Date/Time of the beginning of the validityPeriod |
endTime | Date/Time of the end of the validityPeriod |
template | SLA Template characteristics |
href | Reference of the Template |
name | Name of the template |
description | Description of the template |
relatedParty | Parties engaged in the SLA (SLA provider, SLA consumer, …) |
Role | Role attached to each party (SLA provider, SLA consumer, …) |
href | Reference of the party |
state | Service Level Agreement state |
approved | Indicates if the service level agreement is approved or not (True or false) |
rule | Common pattern or Template for the SLA parameters, metrics, and thresholds |
id | Unique identifier of the metric |
metric | Reference of metric stored in the Service Provider "Metrics Library" |
unit | Unit of measure of metric |
referenceValue | Reference value of metric |
operator | Operator used when calculating the rule |
tolerance | Allowable variation of metric |
consequence | defines the action to be applied as a result of a threshold crossing |
This "SLAViolation" is the second resource considered in this translation into JSON representation. The same representation used for "SLA" resource is applied and is aligned with the SID modeling as well.
It is assumed all Metrics are the ones already stored in the Service Provider "Metrics Library" with their attached references and associated with products on-boarded in the Catalogue.
The "violation" is defined in terms of ID, description (Metrics, reported date, period). Besides, the RelatedParty such as SLA Provider (CSP), SLA Consumer (DSP) and SLA Auditor (for SLA monitoring) is represented in the same way as for Service Level Agreement "SLA" resource. The same goes for "EndUser" role. Two levels of event representation could be useful to introduce:
Example of the JSON representation of an SLAViolation
{ |
Field | Description |
id | The id of the resource model (SLAViolation) |
SLA |
|
description | Description of the Service level Agreement (SLA) |
href | Reference of the Service Level Agreement |
RelatedParty | Party engaged in the SLA (SLA provider, SLA consumer, …) |
role | Role attached to each party (SLA provider, SLA consumer, …) |
href | Reference of the party |
Violation | A discrepancy identified by applying rules to Service Level Agreement related entities. |
rule | The rule represents the value of the threshold of the metric. Once crossed it triggers a violation. |
description | Description of the rule |
href | Reference of the rule |
unit | Unit of measure of metric |
referenceValue | Reference value of metric |
operator | Operator used when calculating the rule |
actualValue | Actual value of the metric |
tolerance | Allowable variation of metric |
violationAverage | TBD |
Comment | Comment about violation |
consequence | defines the action to be applied as a result of a threshold crossing |
attachment | represents statistics, a dashboard or reporting data to be presented to the target parties |
description | Description of the attachment |
href | Reference of the attachment |
© TM Forum 2015. All Rights Reserved