SLA? Don’t forget FRF.13

Opinion
Mar 30, 20113 mins

One of the most important and most often-discussed aspects of ensuring that you have a robust infrastructure is making sure there is an appropriate accompanying Service Level Agreement (SLA). And in a recent newsletter,  we discussed the fact that adding cloud-based services to transmission services that are already dynamically shared can make any service “guarantees” difficult to define and to enforce quite a challenge.

One of the most important and most often-discussed aspects of ensuring that you have a robust infrastructure is making sure there is an appropriate accompanying service-level agreement (SLA). And in a recent newsletter,  we discussed the fact that adding cloud-based services to transmission services that are already dynamically shared can make any service “guarantees” difficult to define and to enforce quite a challenge.

The Frame Relay Forum’s most significant contribution to the industry

So it seems most appropriate to look back roughly 13 years at what is arguably the best singular document ever produced by an industry body, FRF.13 – the Services Level Definitions Implementation Agreement that was produced by the Frame Relay Forum in 1998, with Ken Rehbehn as the editor.

This document is as notable – and timeless – more because of what it does not do than because of what it does do. In particular, it is not a document that specifies what a Frame Relay SLA should include. Rather, it defined the various parts of the service and establishes a common set of terminology and reference so that an appropriate SLA may be devised.

One of the fundamental benefits that this document brings to the table is that it does not give the consumer or the service provider an inherent “advantage.” Rather, the network architecture is described, and there is consistent definition of what may and what may not be reasonably assumed to be within the realm of control for each party. Additionally, the possible consequences for exceeding guidelines – such as bursting faster than one might have as a contracted maximum rate – are explicitly addressed.

Other key points within the document address measurement points, measurement methodologies and measurement aggregation for various parameters. These parameters are defined for delivery of information, delay, and for service availability.

The concepts here are fundamental to all services, and, in reality, frame relay isn’t all that different from any other technology. The difference is that, at least to our knowledge, no other technology (or organization) has painstakingly documented exactly what it is and is not reasonable to include in the scope of an SLA.

If you remember FRF.13, it’s worth a refresher. If you’ve never studied this document, it’s a classic and should be “required reading.”

Jim has a broad background in the IT industry. This includes serving as a software engineer, an engineering manager for high-speed data services for a major network service provider, a product manager for network hardware, a network manager at two Fortune 500 companies, and the principal of a consulting organization. In addition, Jim has created software tools for designing customer networks for a major network service provider and directed and performed market research at a major industry analyst firm. Jim’s current interests include both cloud networking and application and service delivery. Jim has a Ph.D. in Mathematics from Boston University.

More from this author