Computersight -

Having already discussed much about protocols from a generic perspective we will complete this overview and prepare ourselves to take a closer look at a number of select protocols. We have taken a quick look at protocol design and introduced ourselves to a class of protocols known as computer, communications and networking protocols.

We will now continue with a quick look at the primary types and “families” of protocols and some other basic terminology in preparation for a more detailed look into a range of “select” protocols.

Protocol Types

Basically protocols fall into either one of two types; open standard or proprietary standard.

Open Protocols

Open simply means that all of the nitty-gritty details, nuts and bolts are all laid out in a set of documents that is “openly” available to whoever may want to use them.

The biggest advantage of using an open protocol is that it ensures a greater degree of compatible interoperability between end-systems. It was for this very reason that the OSI Reference Model was developed in the first place.

Proprietary Protocols

Proprietary protocols; on the other hand, means that someone or something “owns” them. Think of them as being patented. The proprietor (owner) of a proprietary standard or protocol is under no obligation to disclose the details of “their” proprietary standards and proprietary protocols.

Furthermore; other parties are expressly prohibited from using a proprietary standard or protocol in any manner shape or form, without the prior, express consent of the proprietor (owner).

• Dead Bodies – Computer, network and communications technologies are littered with the dead or dying bodies of untold numbers of truly great protocols and technologies. In terms of their capabilities they outshone all of their peers and contemporaries. Yet they failed commercially. The reason was more often than not due to their proprietary nature.

For Example – Consider the two competing “hot swappable” device buses that have been with us for a few years now. I am talking about the open standard Universal Serial Bus (USB) and Apple® Computer’s IEEE 1394 (FireWire™) standards.

• Open – USB being an open standard has meant that manufacturers wishing to make USB devices can refer to the open standards for the specifications that they need to comply with. If they do so and do make their product in compliance with these standards then their device will work in millions upon millions of USB enabled computer systems the world over.
• Proprietary – The scenario is totally different when it comes to Apple’s® IEEE 1394 – FireWire™. Any manufacturer wishing to make a FireWire™ capable device must first approach Apple® computers and negotiate a royalties package before Apple® will even let them see the specifications data sheets.

With this royalty being very much like any other surcharge or tax the price of the products will undoubtedly be higher. This was and still is the case. FireWire™ devices are much dearer than their USB counterparts.

• Consumers have voted with their pocketbooks and so millions upon millions of USB devices are turned out every year and only a miniscule fraction of that in numbers of FireWire™ devices are produced annually.

Compound this with the economies of scale and mass production and it doesn’t take a brave man to say that FireWire™ will never overtake USB end of story. Yes FireWire™ may hang around for a while yet but it is still doomed none-the-less.

Protocol Families (Stacks)

Protocols; particularly communications and networking protocols are not just one protocol rather they are a bunch of individual protocols that are interrelated. That is to say that each one can do its own job independently of the other protocols in the bunch. However; not much that we humans call worthwhile will ensue.

In order for this bunch of protocols to collectively take input, perform their own individual tasks and to collectively produce output that we humans can use or make use of the entire bunch of protocols needs to be orchestrated. That is they all need to do their jobs in a particular sequence.

Protocol Stack Processing

A protocol stack; or to be more accurate we should say protocol processing stack, is a layered set of protocols which work together to provide a set of network functions. [Source: RFC1392]

The really nice bit about using a protocol processing stack (layered model) is that each layer’s output becomes the next layer’s input. That is the output from one layer of a processing stack is the input of its immediately adjacent layers. It gets even better because the layers of a processing stack can function in both directions. In short:

• Transmission – When transmitting, each layer will take as input the complete output of its neighbour and treat that as a unit. It will then do its thing and wrap this unit into a new package which it passes onto to the next layer which does likewise in turn and so on the process goes.
• Reception – The opposite happens when the protocol stack is receiving. The protocol at each layer; unwraps the unit given to it by its neighbouring protocol, then passes the unwrapped unit to the next layer in the sequence, which does likewise and so on the process goes.

Open Standard Protocols

• Internet Protocol Suite (TCP/IP)
• Open Systems Interconnection (OSI)
• File Transfer Protocol (FTP)
• UPnP (Universal Plug and Play)
• iSCSI
• Network File System (protocol)

Proprietary Standard Protocols

• AppleTalk
• DECnet
• IPX/SPX (from Novell)
• Server Message Block (SMB) and CIFS
• Systems Network Architecture (SNA)
• Distributed Systems Architecture (DSA)
• Apple Filing Protocol (AFP)
• RSYNC
• Unison

In the next issue we will continue our discussion of protocols by examining some of their attributes standards and standards organisations along with the networking and communications aspects and considerations. Until then enjoy!