This section provides information and examples to help you configure the long-term SLA Local Enforcement policies at the requester level, service level, and operation level.
At the core of the long-term SLA implementation is the concept of a fixed window that is defined by a combination of two policies (message.sla.TimeWindow and message.sla.TimeUnit). The guiding principle is that in any given time window, the system will not allow more tokens to be consumed than what is allowed by the most granular rate policy defined for the request: either the message.sla.LocalOperationRate, message.sla.LocalServiceRate, or message.sla.LocalRequesterRate policy (in that order).
All three examples apply only to the SLA Local Enforcement mediation primitive.
In this example, a telecom network operator has exposed Terminal Location (TL) and Terminal Status (TS) services to a client (Requester1) using TWSS. Assume that the network operator assigns a weight of 10 to each TL and TS operation, and wants to restrict Requester1 to send at most 10 requests (of either TL or TS) within a time window of 600 seconds.
<requesterID>Requester1</requesterID> <policies> <policy attribute="message.sla.LocalEnabled" value="true"/> <policy attribute="message.sla.LocalWeight" value="10"/> <policy attribute="message.sla.LocalRequesterRate" value="100"/> <policy attribute="message.sla.TimeUnit" value="Second"/> <policy attribute="message.sla.TimeWindow" value="600"/> </policies>
With these policies in effect, here is an example of what would happen to a set of requests originating with Requester1. Some of the requests are rejected because the SLA policy is defined at the requester level for a time window of 600 seconds.
Time (seconds) | Request | Disposition |
---|---|---|
60 | TL (50) | Accepted |
180 | TS (50) | Accepted |
360 | TL (10) | Rejected, because the total number of tokens (100) has been exhausted for the 600 second window. |
540 | TS (10) | Rejected |
620 | TL (10) | Accepted, because a new time window has begun and no tokens have been consumed–therefore, enough tokens are available to accommodate this request. |
680 | TS (30) | Accepted, because only 10 tokens have been consumed during the present 600-second window–therefore enough tokens are available to accommodate this request. |
820 | TS (50) | Accepted |
In this example, a telecom network operator has exposed short messaging (SMS), Terminal Location (TL), and Terminal Status (TS) services to a client (Requester1) using TWSS. Assume that the network operator assigns a weight of 1 to each SMS request and a weight of 10 to each TL and TS operation. Also assume that the network operator wants to restrict Requester1 to send at most 10 TL and 10 TS requests (each of them counted separately) and any number of SMS requests provided the total consumed capacity does not exceed 500 tokens, within a time window of 600 seconds.
For Requester1, message.sla.LocalRequesterRate (at requester level) is defined to be 500. Note that this allows any request from Requester1 to consume up to 500 tokens collectively. The message.sla.LocalServiceRate policy is defined for both TS and TL to be 100. This policy overrides the requesterRate policy and allows each TL and TS to consume 100 tokens each.
<requesterID>Requester1</requesterID> <policies> <policy attribute="message.sla.LocalEnabled" value="true"/> <policy attribute="message.sla.LocalWeight" value="10"/> <policy attribute="message.sla.LocalRequesterRate" value="500"/> <policy attribute="message.sla.LocalServiceRate" value="100"/> <policy attribute="message.sla.TimeUnit" value="Second"/> <policy attribute="message.sla.TimeWindow" value="600"/> </policies>
<requesterID>Requester1</requesterID> <policies> <policy attribute="message.sla.LocalEnabled" value="true"/> <policy attribute="message.sla.LocalWeight" value="1"/> <policy attribute="message.sla.LocalRequesterRate" value="500"/> <policy attribute="message.sla.TimeUnit" value="Second"/> <policy attribute="message.sla.TimeWindow" value="600"/> </policies>
With these policies in effect, and assuming that message.sla.LocalServiceRate is defined for both TL and TS services, here is an example of what would happen to a set of requests originating with Requester1.
Time (seconds) | Request | Disposition |
---|---|---|
60 | TL (50) | Accepted |
180 | TS (100) | Accepted, because both TL and TS are allowed to consume 100 tokens each over the interval. |
360 | TL (50) | Accepted; however, now the 100-token limit has been reached for both TL and TS. |
540 | TS (10) | Rejected, because TS has used its limit of 100 tokens within the present 600-second window. |
620 | TL (10) | Accepted, because a new time window has begun and no TL tokens have been consumed. |
680 | TL (30) | Accepted, because only 10 tokens have been consumed by TL during the present 600-second window–therefore enough tokens are available to accommodate this request. |
750 | TS (50) | Accepted, because no tokens have been consumed by TS during the present 600-second window–therefore enough tokens are available to accommodate this request. |
810 | TS (50) | Accepted, because only 50 tokens have been consumed by TL during the present 600-second window–therefore enough tokens are available to accommodate this request. |
This example demonstrates how to set up policies for different operations within a service. Consider a telecom network operator who has exposed TL service to a client (Requester1) using TWSS. Assume that the network operator assigns a weight of 10 to each TL operation. Also assume that the network operator wants to allow Requester1 to send at most 10 getLocation and 10 getLocationForGroup requests within a time window of 600 seconds.
For Requester1, service TL, and operation getLocation, the message.sla.LocalOperationRate policy is defined to be 100. For Requester1, service TL, and operation getLocationForGroup, the message.sla.LocalOperationRate policy is also defined to be 100. Note that if a message.sla.LocalServiceRate policy is defined, then that policy is enforced for all operations other than getLocation and getLocationForGroup. Thus both getLocation and getLocationForGroup requests are allocated 100 tokens each. In a similar way, if a message.sla.LocalRequesterRate policy is defined, that policy will apply for all services other than TL.
<requesterID>Requester1</requesterID> <policies> <policy attribute="message.sla.LocalEnabled" value="true"/> <policy attribute="message.sla.LocalWeight" value="10"/> <policy attribute="message.sla.LocalRequesterRate" value="500"/> <policy attribute="message.sla.LocalServiceRate" value="50"/> <policy attribute="message.sla.LocalOperationRate" value="100"/> <policy attribute="message.sla.TimeUnit" value="Second"/> <policy attribute="message.sla.TimeWindow" value="600"/> </policies>In this case, the LocalOperationRate (100) overrides both LocalServiceRate (50) and LocalRequesterRate (500). This allows Requester1 to send 100 getLocation requests. The LocalServiceRate (50) value applies to all operations for which no LocalOperationRate is defined. The LocalRequesterRate (500) value applies to all other services for which LocalServiceRate is not defined.
With these policies in effect, here is an example of what would happen to a set of requests originating with Requester1.
Time (seconds) | Request | Disposition |
---|---|---|
60 | getLoc (50) | Accepted |
180 | getLocGroup (100) | Accepted |
360 | getLoc (50) | Accepted; however, now the 100-token limit has been reached for both getLocation and getLocationForGroup. 300 tokens remain for other request types, based on the difference between the LocalRequesterRate value (500) and the 200 tokens already consumed. |
540 | getLocGroup (10) | Rejected, because getLocationForGroup has used its limit of 100 tokens within the present 600-second window. |
620 | getLoc (10) | Accepted, because a new time window has begun–therefore enough tokens are available to accommodate this request. |
680 | getLoc (30) | Accepted, because only 10 tokens have been consumed by getLocation during the present 600-second window–therefore enough tokens are available to accommodate this request. |
750 | getLocGroup (50) | Accepted, because no tokens have been consumed by getLocationForGroup during the present 600-second window–therefore enough tokens are available to accommodate this request. |
810 | getLocGroup (50) | Accepted, because only 50 tokens have been consumed by getLocationForGroup during the present 600-second window–therefore enough tokens are available to accommodate this request. |