Carrier Class Defined


Many of the vendors and carriers who advertise (or request) “carrier class” or “carrier grade” products, really do not know of what they speak! In most cases this is said as though it were some worldwide unspoken standard. This is not the case. In our experience the need to develop a standard by which you can measure or compare independent solutions sets, against a defined expectation, is a must, if you wish to be successful in selecting, deploying and managing support system solutions.

In our work in the past we have been asked for definitions of carrier class (or grade) standards. We think there is a range of options that any carrier might find acceptable. So at the risk of being considered buffoons, here goes:

Best class:

  • Uptime of 99.999 (5.3 minutes of unscheduled down time per year),
  • Defects at no more than .01 per KLOC (Probably limited to severity 1&2),
  • Throughput at up to 110% of rated capacity for all interfaces and applications,
  • Updates done on-line for all application software (not O/S), with no application restart,
  • Scalability - invocation times remain constant as the number of objects increase, and
  • Latency - meets a defined latency standard (application UI and transaction) 99.999% of time.

Acceptable class:

  • Uptime of 99.99 (53 minutes of unscheduled down time per year),
  • Defects at no more than 0.1 per KLOC (Probably limited to severity 1&2),
  • Throughput at up to 100% of rated capacity for all interfaces and applications,
  • Updates - Less than 1 hour offline for updates of all application software (not O/S),
  • Scalability - invocation times remain near constant as the number of objects increase, and
  • Latency - meets a defined latency standard (application UI and transaction) 99.99% of time.

Measures which are unique to any Support System

There are other aspects of capability that might be considered in the context of your business needs;

Useability is usually measured by customer proxy testing of the product. It is usually focused on UIs, but also may extend to other human interfaces such as a configuration language, bulk loading applications, and API’s.

Operational reliability is achieved by design of the software for defect handling (mitigation). Typical mechanisms include trapping and handling errors, and providing process supervision and restart on failure. This can range from the simple—data retention during a refresh of the screen, to the complex—journaling all character entry.

Performance depends on the operational environment. It will be captured as part of the product or solution specifications. Basics of performance benchmarking require a standard hardware environment. A configuration  standard and an implementation of the software to meet a certain set of operating conditions.

Scalability will deliver constant or linear growth of the resources (time, memory, disk space) required by the deployed product with increasing numbers of customers being handled. Incremental addition of the millionth customer should not be substantially worse than the first one.

Compatibility has an expectation that a new version of the software has the same features as the previous version, and that customer visible interfaces and API’s are “backwards compatible”. The new version is no slower or less reliable than the previous version. Notice of at least 1 year is given for deprecation of features and loading of existing data in the database can be done within a defined service window.

System capability requires that the product will provide open interfaces to permit integration with other OSSs, including ones that don’t exist when the product is first deployed. The OSS is manageable as part of a larger system, and it provides interfaces so that it can be remotely monitored and controlled using systems management products.

Your comments welcome

We’d be interested in what you have to say about our views on this topic so feel free to comment.

Send this article to:
  • Digg
  • del.icio.us
  • Facebook
  • Tumblr
  • Google
  • StumbleUpon
  • Technorati
  • E-mail this story to a friend!
  • Print this article!

2 Comments

  1. Ken Donoghue:

    Thanks for bringing clarity to much-abused terms. Stratus Technologies wages the same battle, having competed for 30 years in both enterprise computing and telecommunciations. Fault tolerance could be substituted for carrier best-in class, and high availability for acceptable class, with many of the same defiing features you suggest. So, from one buffoon to another …!

  2. Carrier Grade Linux | Shulist Group Inc.:

    [...] specs now) and have been adopted by a number of manufacturers. For a short review you can read our previous post about Carrier Grade systems. It’s been six long years of CGL slogging and only recently is [...]

Leave a comment