The role of standards

Insightful analysis by consultants Steve Taylor and Jim Metzler, plus links to the latest WAN news headlines

The last newsletter began to address the topic of what is a standard and used the Bell System and IBM's SNA as examples of standards that came to life without a standards committee. This newsletter will drill down as to why we have standards.

In the early 1980s Jim was an engineering manager for X.25 services for a major service provider. At the time, the phrase X.25 networks was commonly used. That phrase, however, was terribly misleading in terms of the role of X.25. The phrase makes it sounds as if the networks were built around X.25. In actual fact, the X.25 specification defines only the interface between a subscriber’s DTE (data terminal equipment) and an X.25 network’s Data circuit-terminating equipment, (DCE). It was, for example, the protocol used between the PAD (Packet Assembler/Disassembler) at the customer site and the switch at the service provider’s point of presence. 

The role of the standard was to ensure that any X.25 customer premises equipment that supported X.25 could connect to any service provider network that supported X.25. This was important because it meant that the service provider could not dictate the equipment that the customer used on their site. The standard did not cover how the service provider built their network because of the desire to let the service providers build what they believed to be the best network and let the marketplace choose which service provider provided the best service.

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

The last newsletter began to address the topic of what is a standard and used the Bell System and IBM's SNA as examples of standards that came to life without a standards committee. This newsletter will drill down as to why we have standards.

In the early 1980s Jim was an engineering manager for X.25 services for a major service provider. At the time, the phrase X.25 networks was commonly used. That phrase, however, was terribly misleading in terms of the role of X.25. The phrase makes it sounds as if the networks were built around X.25. In actual fact, the X.25 specification defines only the interface between a subscriber’s DTE (data terminal equipment) and an X.25 network’s Data circuit-terminating equipment, (DCE). It was, for example, the protocol used between the PAD (Packet Assembler/Disassembler) at the customer site and the switch at the service provider’s point of presence. 

The role of the standard was to ensure that any X.25 customer premises equipment that supported X.25 could connect to any service provider network that supported X.25. This was important because it meant that the service provider could not dictate the equipment that the customer used on their site. The standard did not cover how the service provider built their network because of the desire to let the service providers build what they believed to be the best network and let the marketplace choose which service provider provided the best service.

The X.25 protocol worked relatively well. There were, however, some complications. For example, the X.25 standard was updated every four years. Hence, it was not enough to know that a vendor supported X.25, but you had to know which version of X.25; i.e., the 1980 standard? The 1984 standard? The 1988 standard? Another factor that complicated interoperability was that in addition to the standard, most vendors also supported extensions to the standard. Hence, a user would have to know which extensions to the standard both their DCE as well as their service provider supported.

Related to X.25 was a protocol referred to as X.75. X.75 is what we would now call an NNI (Network to Network Interface). X.75 defined the interface between two X.25 networks with the goal of allowing users on one X.25 network to communicate with users on the other X.25 network.

X.25 and X.75 highlight the fact that a primary role of standards is to enable interoperability amongst the products and services of disparate vendors. Interoperability applies at multiple levels. At one level, interoperability applies to basic connectivity – can you successfully move bits end-to-end over a heterogeneous network? Interoperability also applies at levels other than just basic connectivity. For example, can you more the bits securely end-to-end across a network?

In our next newsletter we will discuss the standards process. In the meantime, we want to hear from you. We all know that standards are important. However, how important are proprietary extensions to standards? How long into the standards process is it before there actually is a working standard that enables interoperability? Do you choose one vendor over another based on their support for standards?

Steve Taylor is president of Distributed Networking Associates and publisher/editor-in-chief of Webtorials. Jim Metzler is vice president of Ashton, Metzler & Associates.