Table of Contents Chapter 7 Chapter 9 Netguru.net Glossary
Chapter 8 - Software Protocols
Once we move above the Physical and Data Link layers, we get into the realm of protocols (packet types) used by the various network operating systems. Sometimes the systems stand alone (like Novell's NetWare). Sometimes they are part of another type of operating system (like TCP/IP support in UNIX OSs). Whatever the case, these NOSs are responsible for bridging the gap between applications running on a machine and it's Physical and Data Link layers.
Novell NetWare
It is appropriate that we start with NetWare because the NOS is the most popular for PC based networks today. Starting in the 1980s NetWare grew in popularity mainly due to its speed and its pretty solid file and print services. The Novell company has made some good decisions concerning acquisitions and has done a good job at positioning themselves in the marketplace much to the chagrin of other would-be network behemoths (i.e. Microsoft). The credit for Novell's success with their NetWare product should go to the team of forward-thinking programmers and Ray Noorda, President and CEO.
NetWare's design is fairly straightforward from a networking point of view. The NOS appears fairly transparent to the user. Printers are easily accessible through "captures" which simply re-route data from external ports to a spooler system on a file server. The file server itself appears as just another drive letter to the user. This transparency was not new with the NetWare product. A company called Corvus provided transparency for users around 1980.
The goal of Novell is the have NetWare run on any machine platform. That way NetWare becomes the common denominator to all systems. That's what Novell's marketing people want, and through a series of partnerships and agreements, the company has moved a long way toward accomplishing this goal. Almost weekly, the trade mags announce another joint effort between Novell and some other vendor. NetWare does seem to be reaching a certain degree of "common denominatorness" in the networking industry.
In order to have NetWare run on and co-exist with such diverse platforms as DOS, OS/2, Macintosh, UNIX and DEC's VMS, special attention has to paid to what services are being provided by the NetWare protocols at what level of the OSI model.
The components of the NetWare OS fall into the layers above the first two of the OSI model. Not all the layers' services are provided by NetWare, but enough are required to be able to categorize NetWare in the OSI model.
NetWare supports about every major network type there is. ARCnet, token ring, Ethernet, FDDI, and others are all operable with the NOS. The direct interface with these network types on the network layer is the IPX packet type. IPX stands for Internet Packet eXchange. This basic building block of networking messages allows us to provide a number of different LAN types with numerous applications.
The SPX packet type used in NetWare allows us to benefit from the services provided on the transport layer. SPX stands for Sequenced Packet eXchange. Through this packet type, we can set up very reliable and fault-tolerant dialogues across a NetWare LAN.
In filling out the rest of the OSI model, Novell has provided a protocol called the NetWare Core Protocol (NCP) that operates on the file server running the NOS. In a nutshell, NCP is a series of application functions that interact with a workstation to create the client/server environment. It allows a whole host of services including file and printing.
NetWare provides a NETBIOS emulator for applications requiring the session and presentation layer services. NETBIOS, as you recall, was IBM's contribution to LANs. For applications requiring these layers' services via NETBIOS calls, the emulator allows things to operate seamlessly.
Novell's packet types are based on a set of packet protocols developed by Xerox in the late 70s and released in 1981. These protocols were called XNS (Xerox Networking Systems) protocols. A close examination will show the similarities. XNS served as a model for the protocols of other companies as well including Banyan. Let's look more closely at the packets that are created before the Physical and Data Link layers might receive them.
1. The IPX Packet
The IPX packet provides a means of communication that uses no special relationship between sender and receiver and does not provide any data transfer reliability like sequence numbers in a packet. Technically, this is called connectionless, unacknowledged service and is analogous to what is called a datagram (see Chapter 4). When the IPX packet is used there is no real guarantee that the data will be successfully sent or received, but the packet does provide very rapid service due to the fact that no overhead is required for connections and acknowledgments.
IPX makes sure that data gets to the right place regardless of what network the destination machine is on. The packet can be routed and is used for doing so since it contains a destination address as well as a network address for where the destination node is. IPX relies on information provided by a protocol known as Routing Information Protocol (RIP) to make decisions about proper routing. RIP basically is a special protocol used by routing devices. The protocol lets the device known how many different pathways there are to the destination and which are the shortest paths. This typically updates a routing table inside a routing device. Let's look more closely at the IPX frame.
Figure 8-1: The IPX Frame
The frame begins with a checksum field that is 16 bits in length. All the bits in that field are set to 1.
The length field follows and it is also 16 bits in length. The size of the entire IPX frame is contained here. Sizes range from 30 bytes to unlimited size as long as the packet is not routed, at which point, the limit for the IPX frame is 576 bytes.
The transport control field keeps up with the "hop count" of the packet. The hop count is how many times the IPX packet goes through a routing device. After 16 hops, a packet is discarded. This is necessary to prevent endlessly circulating packets. This field is one byte in size.
Next, the packet type field holds data determining to what other higher layer protocol the data in the IPX frame will be passed to. For instance, if this field contained a 17, the data would be passed to the NetWare Core Protocol. Other choices would include SPX, PEP (Packet Exchange Protocol) and an indicator that the message should go to an unknown packet type. This field is 8 bits in length.
The destination network field contains a 32 bit address for a network that the packet is bound to. The network of the receiver may or may not be the same as that of the sender. If the nets are the same, then this field is zeroed out.
The next field, the destination host field, requires 6 bytes of information. This space is filled with 1s for packets to be sent to all destinations. If all of this space is not required, then some bytes may be padded with 0s. ARCnet has five bytes padded and one byte used for addressing.
The destination socket follows specifying which higher layer process will be utilizing the data contained in the packet. Each process has been given a unique socket number. This field specifies whether the packet will require file services, RIP services, NETBIOS services, etc. This field is 16 bits in length.
The next field specifies the source network, followed by the source host field and the source socket (process) field. These fields are 32 bits, 48 bits and 16 bits respectively.
Finally, there's the actual data field. It can be from 0 to infinite length. This information will be used by applications or services running on the receiver.
2. The SPX Packet
As you recall from the OSI model section, the transport layer allows us to ensure delivery reliability. Novell uses the SPX packet type to carry out the functions of this layer. As mentioned earlier, SPX stands for sequenced packet exchange. The SPX packet provides connection-oriented, acknowledged services. This ensures message transfer reliability, but there is overhead involved. Most commonly the SPX packet is used for the NetWare printing facilities and for the administrative remote connection to the console (RCONSOLE).
If an entity would like to use the SPX packet to communicate with another, the relationship (or virtual connection) must be established. Effectively a pathway is set up between the two entities that will not change while the two are maintaining the connection.
Figure 8-2: The SPX Frame
The SPX packet is identical to the IPX packet except that is adds 12 bytes to the header. The IPX look-alike portion has only minor differences including a special value in the packet type field indicating an SPX packet, and the destination address is restricted so that broadcasts are not allowed.
The connection control field is one byte in size containing four bits which control data flow. The bits represent an End of Message, Request for Acknowledgment, Attention Message, or System Packet. This is followed by a second byte called the datastream type field. This field identifies what type of data is contained in the frame. It also can carry data that creates and tears down connections.
The source connection ID follows with an identification of a specific connection number (required to create a virtual connection) at the source and the same for the destination follows. These connection numbers are analogous to mailboxes with specific address. The sender may transmit data from its mailbox to the mailbox connection of the receiver. The receiver can then reply to the specific mailbox number of the original sender. If the server was the sender, it may be maintaining virtual connections with several workstations at once. The destinations would all be different, but the source would be the same.
A sequence number follows uniquely identifying each packet. This field is 2 bytes in length. This field is followed by a two byte acknowledgment number field that contains the sequence number of the next packet that the receiver should expect.
Since each node only has a limited amount of memory resources available to accommodate incoming packets, an allocation field is necessary to help keep the sender apprised of available receiving buffers (memory locations for holding received packets). The allocation field is two bytes in length and follows the acknowledgment number.
Finally, the data field rounds out the SPX frame providing data for the higher levels of the OSI model.
NetWare provides numerous services. Many of them fall under the responsibility of the NetWare Core Protocols (NCP). Here is a brief summary of the many services provided by NetWare:
As you can see the services are many and varied, but the above list is by no means exhaustive. NetWare has several value-added applications that can extend its functionality. These applications are called VAPs (Value Added Processes) and NLMs (NetWare Loadable Modules). These services might include additional print services, SNA gateway, E-mail, database support, remote communication services, other transport protocols, etc. These programs are supplied by Novell and third-party vendors.
Just The Fax, Ma'am
Recently our company decided to install a fax NLM into one of our file servers. We learned the hard way that throwing on a value-added service may prove to be less valuable than it seems at first. The NLM allowed us to have access to a fax card in the server from anywhere on our LAN. Plus, incoming faxes could be routed to us individually. The system worked like a charm, except for one minor problem. Utilization shot up to 90+ percent whenever an incoming fax was being processed. That file server really slowed down, and so did anything you were doing on it at the time. Be careful about throwing extra loads on a file server. If you need to have shared faxing capabilities, why not consider a fax server. Users may be grateful for the faxing and the continued LAN performance.
One of the most important elements of NetWare is the client applications referred to as the "workstation shell". At this point, NetWare has two different types of shell files in existence for DOS users. One is called the DOS Workstation Shell and the other is called The DOS/ODI Workstation Shell. The former which is the older of the two creates a hardware interface to LAN cards and provides the various types of NetWare packets through one application called IPX.COM. The latter is modular and is designed to allow multiple types of packets to use a single LAN card in a machine. DOS/ODI will continue to be serviced by Novell in the future, where IPX.COM will likely not be.
The shell file called NETX.COM or NETX.EXE functions as a redirector or gatekeeper. This means each application request is screened to see if it needs to be routed to the network or dropped to the local operating system. For instance, if we were on a DOS machine and we typed in DIR C:, the request would be dropped to the local OS. If, however, we typed NDIR F:, the request would be passed to the IPX.COM application where it would be converted into NetWare Core Protocol requests and subsequently transmitted tot he file server. The NCP requests would be fulfilled, and the resultant data is transmitted back to the workstation for display. The user or application does not have to worry about whether the information came from a local OS or a network. This transparency, pioneered by Corvus Systems in the late 70s, has been implemented quite nicely into the NetWare scheme.
Figure 8-3: The Novell NetWare Network Operating System is comprised of applications that run on both the file server and at the workstation (client).
This transparency is extended in the NetWare environment to resources other than just the file server. This is accomplished via NetWare Remote Procedure Calls (RPCs). This system, developed for Novell by a company called NetWise, allows external applications to have easy and transparent access to NetWare.
Maintaining shared files can be a challenge in any networking environment due to the possibilities of conflicts and lock-ups. NetWare is certainly no exception. In order to reduce the chances of two people editing the same record at once, NetWare jumps through a few hoops. First of all, synchronization services are provided through NCP that allows accurate tracking of file and record locks. Also, NetWare transmits shared files around the LAN using a very small packet size and disables background caching of shared files to workstations. These are just safety precautions. In addition, NetWare offers a package with makes use of NetWare's file and record locking capabilities called BTRIEVE. This package grants speedy access to database structures based on binary trees.
NetWare has been gradually evolving to a more open and modular structure over the last few years. This is necessary in order to implement the "NetWare running on anything and everything" strategy Novell is shooting for. One such modular structure is support for STREAMS technology. This mechanism requires us to think of data passing through the OSI layers like a stream. We can put various modules into the stream and alter what comes out.
Let's say we have an application that must send data to another node. This sets up a flow through the OSI layers. We would use what is known as a "stream head" to handle application requests. The stream head would hand this data off to what is known as a "Transport Layer Interface" or TLI. This could place the data in the proper format for NetWare SPX or IPX, or even TCP/IP. The final step is to send this new stream to the driver for the LAN card we're using. Each phase of this process can be altered by plugging in or removing different modules (i.e. a different driver). NetWare Streams allows for efficient, modular delivery of data through the OSI layers.
Novell has to date attempted to provide what compatibility they have felt necessary in order to assure their corporate success. There are plenty of competitors out there (like Microsoft) who would like to push Novell out of the market, but the company's deep roots will keep it thriving for a long time. Being compatible with a competitor is tough to do sometimes, but the consumer can be better served that way. Novell's NETBIOS emulator is a good example.
In the mid 80s when IBM was getting full swing into PC LANs, the largest computer company on earth decided to introduce a set of protocols called the NETwork Basic Input Output System. NETBIOS combined several functions on the session and presentation layers of the OSI model that NetWare didn't really use or need. However, NETBIOS was a significant force in the marketplace. Novell responded by writing an emulator for NETBIOS found in the NetWare file called NETBIOS.EXE.
This emulator serviced the various calls made by applications designed to use NETBIOS. Therefore, NETBIOS apps were fully functional within the NetWare environment.
Novell has also pushed forward to provide compatibility with other standards as well. Novell's Message Handling System (MHS) follows the X.400 standard set by the American National Standards Institute (ANSI). This global message schema will be or currently is supported by several E-mail packages. X.400 specifies the format of messages for global delivery.
In addition, NetWare 4.X products support ANSI's X.500 standards for global directories. In fact, many experts agree that the adoption of this standard was facing a fair amount of resistance until Novell tossed their hat into the X.500 ring. Though Novell altered the official specification a little bit in NetWare's implementation, the final product boasts a hierarchical structure of organizations, resources and users that fits into the global standard.
The future of NetWare appears to be good now, but no one has proven to be an accurate judge of the marketplace. Novell's earlier attempt at providing control of a network, not just a server, was a dismal failure. This product was called NetWare Naming Services. Many insiders agree that the Naming Services product should have never been marketed as it was crippled to begin with by its limitations. Novell will continue to hope that this second attempt at supporting internetworks will be successful.
TCP/IP Protocols
Perhaps no other protocols designed to work above the Data Link and Physical OSI layers are as popular as TCP/IP. That's primarily because this global protocol suite has been used by and continually promulgated by thousands of government and educational institutions world-wide.
TCP/IP is the major protocol used on the global Internet created by the US government to facilitate computer load distribution and exchange of defense-related information. Not surprisingly, the government announced some time ago that it was going to focus on converting its entities to another type of protocol based directly on the OSI model called Government OSI Profile (GOSIP). Recently, this move has been questioned and the move toward GOSIP is under reconsideration.
TCP/IP was designed to allow any type of computer communicate with any other computer. A brief recap of TCP/IP might prove helpful in understanding its offerings and structure now.
In the mid 70s the US Department of Defense (DoD) sponsored funding of a protocol development project by Bolt, Beranek and Newman as well as Stanford University. The funding came through the DoD's Advanced Research Projects Agency (DARPA). At that time, DARPA had set up a network called ARPANET that connected government agencies, educational institutions and research sites together. Its mission was to allow the rapid flow of ideas and data concerning defense projects from one entity to another. This task was daunting because so many different types of machines were in use. The answer was to create a protocol that worked on top of any physical structure. That's why TCP/IP functions on layers above the Data Link and Physical OSI layers.
In the early 80s TCP/IP was fully implemented across the ARPANET. This new level of interoperability resulted in incredible growth on the system. The Internet is now the largest internetworking collection in the world offering packet-switched services to millions of individuals. The Internet grew out of ARPANET that still exists as a subset of the larger entity.
Managing this giant became cumbersome so an independent organization called the Internet Activities Board (IAB) was formed. This group coordinates the various research projects on the Internet. Each project is overseen by a task force that offers suggestions for facilitating and/or improving the project. The IAB also doles out access to the Internet by providing Internet addresses.
A major development for TCP/IP occurred in 1982 when developers at Berkeley University in California added TCP/IP support to their UNIX operating system (known as Berkeley UNIX). Since this OS was so popular among universities, TCP/IP became the overnight choice for these institutions.
Today TCP/IP is a commercial success almost becoming the defacto standard for internetworks. The continual development by universities and research sites has led to literally zillions of TCP/IP-supporting applications available for free on the Internet.
The TCP/IP protocol suite (also known as the Internet protocol suite), provides services that function on all layers above the Data Link layer on the OSI model. There are a myriad of different protocols each designed to provide a specific service for a host of environment. Some of these were originally developed in the late 70s. Others have been added by third-party vendors more recently.
1. The IP Packet
Very similar to NetWare's IPX packet type is the IP packet (that's the IP part of TCP/IP). This packet type simply moves data from point A to point B and does not provide any special relationship between the sender and receiver. Nor does it guarantee delivery of data from sender to receiver with acknowledgments. For this reason, the IP packet type is referred to as an unacknowledged, connectionless protocol.
Information placed into an IP packet is known as a datagram. Datagrams carry data that has filtered down from the network layer. This data along with transport layer information comprises what is called a Transport Protocol Data Unit (TPDU). The TPDU is routed across the network, visiting routers that determine the best path on which to send the packet.
Sometimes, proper routing requires that the TPDU be downsized and broken apart. The IP protocols allow for this process and the subsequent reconstruction of the TPDUs at the receiver. Reconstruction is accomplished via sequence numbers.
The IP packet is composed of several fields. Instead of referring to the length of IP packets according to bits and bytes, the IP frame uses a length measurement of 32 bits referring to that grouping as a word. Consequently, any diagrams used to illustrate IP frame construction will divide the frame into 32-bit words.
The first field is four bits in length and is called the version field. It contains the version number of the IP software used to create the datagram so that any device along the way that looks at the datagram will know what format it is in.
Figure 8-4: The IP Frame
The IP header length follows (HLEN) gives the total length of the datagram header. The type of service field is next. It is divided into five distinct sections. The first 3 bits comprise the precedence section. Though data in this section is rarely used, it details the importance of the data contained within the datagram. The range is 0 through 7 with 7 being the highest priority. Eventually, devices will utilize this data to allow control information to pass more quickly than data. Intelligent management of data routing will be aided by this.
In addition, the next three bits comprise yet another management aid. Referred to as the D, T and R bits, respectively, the fourth through sixth bit of the precedence requests a specific type of transmission pathway. D stands for low delay. This is used for data that requires minimal delay such as control information. T stands for high throughput. This is requested by applications that need to move a large amount of data very quickly (i.e. voice communications). Finally R stands for high reliability. This request asks for very fault tolerant and reliable pathways. Electronic monetary transactions might be benefited by this. Though the routers along the path may not be able to accommodate the datagram's request, at least there is some degree of control of pathways taken by the sender. The last two bits of the precedence field are unused at this time.
The total length field appearing next, contains the total length of the entire datagram in bytes. The IP datagram is virtually unlimited in size. It can be as large as 65,535 bytes, a size which few applications can even begin to approach. However, in the future, higher speed networks may suffer from this limitation.
We have already mentioned that datagrams may be broken up or "fragmented" to accommodate routing. When this occurs, each portion of the original datagram gets its own copy of the datagram header information. Each portion then becomes its own mini-datagram and is treated accordingly being routed individually to the destination.
The next field is the identification field containing a combination of an integer and the internet source address. Together these create a unique ID for the datagram. This same information is used to keep the fragments of a datagram together.
Once a datagram has been fragmented, the datagrams created from the original have virtually the same header. The only difference lies in the next field -- the flags field. Only the last two of the three bits in this field control fragmentation. The first of the two is called the "do not fragment" (DF) field. If this bit is on, then a datagram does not get fragmented. The next bit is the "more fragments" bit specifying whether or not the current fragment is the last fragment.
The fragment offset is next signifying what portion of the overall datagram is contained in a fragment. Each successive fragment will have a higher offset than the previous. The first fragment has an offset of zero. The fragments will not have to arrive in order, but will eventually be reassembled into the original datagram.
The next eight bits comprise what is known as the "time to live" field. This field is a safety preventative to keep data packets from swarming around an internet forever. Each datagram is given a lifetime length when first transmitted. This value is in seconds and gets decremented whenever the packet reaches a routing device. These devices must decrement the field by at least a value of one. Most record the amount of time that a packet has been held by the device and then decrement the field accordingly before transmitting the packet on out along a pathway.
Next we have the protocol field that contains eight bits specifying what higher layer functions are being used. These higher layer protocols might be TCP/IP protocols or some other protocol type. Since the higher layer protocol is specified by this field we may have several protocols active at the receiver and this data would ensure the packet was used by the correct one.
The header checksum follows. This 16 bit field assures the integrity of the IP header itself. Every time the datagram gets routed, the time to live field gets decremented. Consequently the checksum must be recalculated at each hop.
The source and destination fields are next. Each address is 32 bits in size and contains a unique IP address. Which bits within these fields are used for what is determined by the class of the internetwork entity. For instance, the Internet groups their members into three distinct classes. Class A sites have 24 bits of the address available for designating different hosts (a large number of them). Class B sites have 16 bits available to designate hosts, and Class C sites have only 8 bits. Obviously the last of these has the fewest possible combinations of bit patterns, so therefore fewer hosts are allowed. The address field may be divided up to accommodate subnetworks of a network. This is often utilized when a company or institution wants to route data to individual network segments.
The next to last field is a variable length field known as the options field. It is used to allow additions to the header information such as time stamps or security designations. This field is often used in experimentation and tracking functions.
Finally there is the data itself.
2. The TCP Packet
The Transmission Control Protocol (TCP) is analogous to NetWare's SPX protocol. Both involve the establishment of a relationship between sender and receiver, sequencing of packets, and flow control. Also like SPX, the protocol allows several relationships between entities to exist at once therefore servicing several application requests at once.
The construction of TCP, like IP, is based on 32 bit words. The components of TCP include full addressing and acknowledgments. Let's take a closer look.
The first field is known as the source port field. This 16 bit grouping of bits uniquely identifies the type of upper layer protocol that issued the TCP frame to begin with. There are several upper layer protocols and each has been assigned a unique number. The destination port follows, also 16 bits in length, specifying the upper layer protocol that will receive the data.
The sequence number follows identifying the unique frame in the stream of data from sender to receiver. The sequence field is 32 bits in length.
Next is the acknowledgment number. This field represents the se-quence number of the next packet the sender expects to receive. Acknowledgments are often delayed in TCP implementation. Several packets may be acknowledged in a single acknowledgment in order to speed the communication process.
Figure 8-5: The TCP Frame
The data offset field indicates the size of the total TCP header in 32 bit words. This is necessary because of the headers variable length. In essence, this field tells the receiver how far within the packet is the data located. This field is four bits in size.
The reserved field follows. It has no specific function as yet. In the future this field will be used. It's six bits in length.
Next is the code bits (CB) field (called Flags field by Novell). The CB field contains bits that when set, indicate the proper way to interpret other fields within the frame.
Code Bit (Flag) Settings
The window field follows with a length of 16 bits. This field advertises the amount of buffer space available at the sender each time a packet is sent. This is an important concept as TCP utilizes the "sliding window" concept described previously in this book. If a sender, by advertising fewer buffers, controls how many packets its communication partner will send in the next transmission before waiting for an acknowledgment. This equates to real-time flow control, and is highly effective in the connection-oriented environment of TCP.
After the window field a 16 bit checksum is added to ensure the integrity of the frame header. This is followed by what is called the urgent pointer. This pointer works in conjunction with the urgent code bit in the code bit (or flags) field. This 16 bit field contains the location of the byte immediately following the last byte of urgent material bound for the upper layer protocols.
Next we have the options field that, like the IP packet, can be of variable length. It too can store all sorts of data including that for experimentation, tracking and security procedures.
The final field is the data field.
3. Additional TCP/IP-Related Protocols
There are several additional protocols designed to assist TCP and IP. Since routing is so important on a packet-switched network like the Internet, specialized protocols have been designed to assist in this function. Special protocols for determining addressing on the Internet have also been devised. Additionally, some additional protocols may be involved in error-checking and flow control, just to name a few. Let's explore some of these additional protocols that are included in the TCP/IP suite of protocols.
That's an overview of some of the better known additional protocols. Because NFS has affected the TCP/IP world so much, it would serve us to discuss it a little more fully.
To understand the import of NFS, we have to go back to the original goal of DARPA. The idea behind the ARPANET and the Internet was to provide communication between machines of incredible diversity. NFS has moved the TCP/IP much closer to achieving that goal.
By providing a standard interface, NFS allows machines to use each other's filing systems transparently as if the machines were local and of the same species. This feat is accomplished using Remote Procedure Calls (RPC) and eXternal Data Representation (XDR).
RPC provides a mechanism by which programmers can distribute an application over multiple resources. Effectively what happens is that a programmer divides an application up into a client and server section. These two will communicate normally except that RPC provides the communication link. He or she then integrates RPC code into both sections and the job is done. RPC handles the gathering of data and transmission of it from one section to the other.
As RPC handles the transparent application execution, XDR provides transparent data flow from one hardware platform to another. Since different hardware platforms may require different representation of data, XDR acts as the common denominator. One machine encodes data and hands it off to XDR which in turn formats it correctly for the recipient machine. XDR is highly automated and greatly enhances and speeds the work of programmers who must move data between diverse platforms.
NFS is only one contribution to a protocol suite that has found usage in nearly every sector of networking. It's continued acceptance and evolution will ensure that it stays around as am internetworking standard for a while.
SNA (Systems Network Architecture)
SNA was and is being continually developed by IBM. Around since the early 70s, this broad collection of networking modules served as a reference for creation of the OSI model by the ISO in the late 70s. It, too, follows a layered structure fairly analogous to the OSI model. Through the years, SNA has seen numerous additions and enhancements which have made it widely accepted and implemented today. Plus, being developed by the world's largest mainframe manufacturer didn't hurt.
SNA offers many features which were designed to be forward compatible with new offerings from IBM. That is, they were open enough to support future enhancements, yet still backwards compatible. Fortunately, that left a large number of IBM customers with the ability to upgrade painlessly.
One of SNAs strong features is its ability to allow resource sharing. As mentioned in Chapter 1 of this book, networking allows us to make better, more efficient use of our resources. By using common communication methods between all SNA-supporting devices, the overhead of supporting diverse platforms is eliminated. Like Sun's NFS protocols, SNA provides transparent linkage between SNA resources.
SNA features Remote Operation and Advanced Program-to-Program Communication (APPC). Remote Operations provides remote management capabilities allowing machines to be controlled from a remote site and saving money spent on personnel. APPC allows applications to move information among themselves dynamically thus enabling distributed processing. In effect, two machines can share the same application. The load of running the program is shared between the two.
The open construction of SNA allows for a modularity that eases expandability. The purpose of the OSI model was to classify the networking functions on each layer. SNA essentially does the same thing with communications. Future enhancements can be made on a certain SNA layer without affecting the other layers, and development of applications can take place without new communication methods having to be written.
Highly reliable and dependable data delivery is the motivation behind SNA's construction. The architecture allows for the collection and reporting of network error statistics. In addition, operators may re-route data around a problem area until the situation is resolved.
Flow control is provided in several ways. Priority levels allow users to specify the urgency of data. For instance, keyboard input would be high priority material, while a background-processed batch job would only require low priority. Data flow is managed between devices and nodes to prevent data overruns and congestion. Backup data pathways and hosts can be configured to provide fault-tolerance.
Two SNA networks can communicate with one another even if there happens to be a public switched network in between. Appropriate interfaces exist to allow this. In addition, transparency to the user is such that execution of an application between hosts and communications between hosts and terminals may take place without the user knowing where the physical resources are.
Security is provided in two main ways within the SNA structure. Logins are required for users along with passwords. Plus the data traveling from one node to another can be encrypted. Encryption is extremely important to highly secure establishments such as government agencies or defense contractors. The encryption method used is designed to be nearly indecipherable.
SNA began as a hierarchical architecture. Components were classified as host processors, communications controllers and peripheral nodes. The hierarchy structure later gave way to a peer-to-peer structure that allowed all classes of machines interact with one another. Host processors usually controlled all aspects of the SNA network. These hosts could function independently or be tied together to form what appeared to be one large processor entity.
Communication controllers served the needs of the lower layer elements of SNA. The controllers are in charge of creating and controlling links, routing and general SNA network management. These devices additionally could control data flow by accepting data at different rates from various sources and supplying it over high-speed links to the host processor.
The peripheral nodes could include IBM workstations (terminals) or other devices such as scanners and modems. These nodes would have reliable data delivery guaranteed by SNA. They might also include cluster controllers and distributed processors.
In the hierarchy, host processors were the ones typically initiating and controlling any communication between communication and peripheral nodes. Today, however, advanced systems like Advanced Peer-to-Peer Networking (APPN) allows any device to initiate its own dialogue. This new structure is tremendously flexible.
Roughly analogous to OSI's Data Link and network layer are the Data Link control and path control layers of the SNA structure. These two layers comprise what is known as the "path control network". The path control layer is responsible for routing, address translation, and segmenting, while the Data Link control layer allows Data Link frame construction and transit along with error detection and correction. These functions are controlled by IBM's Advanced Communications Function/Network Control Program (NCP). NCP is run on communication controllers.
Above the path control network, we have Network Addressable Units which function on the transmission control, data flow control, and presentation services, comparable to the OSI transport, session and presentation levels, respectively. The transmission control layer keeps data flowing at the appropriate speed to support the processor being used and generally controls data traffic on the network. The data flow control layer establishes data synchronization and exchanges. It also in charge of placing data into units. The presentation services format data for various media and oversee resource sharing.
The software that controls the network addressable unit function is called VTAM which is short for Advanced Communications Function/Virtual Telecommunications Access Method. VTAM runs on the host nodes to manage the SNA network. It is interesting to note that VTAM is designed to run on several mainframe and mini operating systems.
Network addressable units each have a unique address. There are three different kinds:
System Services Control Points are capable of establishing sessions between other SSCPs, PUs or LUs. If a SSCP establishes a session with another SSCP, then processing loads may be shared between the two. One of the SSCPs in such a situation could also function as a backup for the other SSCP. In the event there was a problem within one domain, the backup SSCP can take over processing loads until the problem is resolved. An SSCP session established to a PU will allow control of all SNA devices within the PUs area of responsibility. An SSCP to LU connection will allow the SSCP to set up and control LU sessions that allow users on to the network.
Remember that LUs control user access to the network. The SNA network doesn't interact with a user, but rather the Logical Unit the user is making use of. LUs communicate to one another via sessions. The session is initiated when one LU requests a session with another. The SSCP must create the session between the two LUs.
Sessions take place between a primary LU and a secondary LU referred to as PLU and SLU, respectively. The PLU is responsible for error recovery in the event of a transmission failure.
Logical Units are categorized according to their features and abilities. Here is a summary:
SNA Logical Units (LUs)
APPN is the newer incarnation of SNA released in the mid 80s. It supports a peer-to-peer relationship. Sessions may be initiated between LUs without the supervision of an SSCP. In addition, APPN allows a LU to create multiple sessions at once which was not the case with older SNA limitations. APPN has enhanced security features such as password options for data transfers. It also spreads the tasks associated error recovery to both the PLU and the SLU. In addition, LU 6.2 used by APPN optimizes data transferred eliminating keyboard, CRT, formatting and control information not needed.
SNA networks may now be managed through an IBM package called NetView. NetView is supported by several vendors and offers broad problem tracking and solving capabilities. NetView constantly monitors all network resources and can take action if performance falls below optimal limits. It may disable defective resources and re-route data around problem spots. It also tracks the complete process of solving problems and performing hardware or software changes from start to finish.
SNA is a modern state-of-the-art networking system under continual development with IBM. Its functionality has remained high despite its long history. Continued vendor support for SNA and SNA-related products will ensure SNA's existence for a long time.
GOSIP (Government OSI Profile) and OSI
GOSIP is a specification set up by the US government requiring the government to use a special set of protocols developed around the OSI model presented by the ISO. The adoption of GOSIP gave supporters of these protocols the hope that the protocols might see widespread acceptance in the near future. However, recent reconsiderations on the part of the government may derail such acceptance.
The Physical and Data Link layers of the OSI make use of several diverse protocols in use today while the upper layers have been specially developed to follow the OSI model very closely. The ultimate goal is a universal and international set of protocols which are open to the point of allowing anything to communicate with anything. Some experts argue that the amount of overhead in basing protocols directly on the model is unacceptable.
There are three different versions of GOSIP implementation. The first allows the usage of the X.400 Message handling Services and the File Transfer, Access & Management (FTAM) at the application layer. Connection-oriented services are provided through the use of the X.25 Packet Layer Protocol. Connectionless services are provided through CLNP (ConectionLess Network Protocol). The Data Link and Physical layer specification already exist and offering support for Ethernet, token ring, ARCnet, FDDI, etc.
Version 2 will feature the addition of ODA (Office Documentation Architecture) above the application layer. The idea behind ODA is the separation of sections of each document (headings, body, title, etc.) into separate objects which can be manipulated. Therefore they could be placed in any format.
Version 3 will feature support for the X.500 Global Directory Services. This feature will allow users from anywhere on the global network to consult a hierarchical directory in order to locate other users or resources. NetWare 4.X's NetWare Directory Services is based on X.500. In the future, you'll be able to consult the equivalent of the yellow pages to find anything or anyone you want due to this specification, within reason of course. Some access will have to be restricted for security reasons.
An "ES" in OSI terminology is short for End System. It is defined as the absolute endpoint of a data transmission or reception. ESs connect to an Intermediate System (IS). ISs may route data from one ES to another on the same network, or ISs may route the data to another IS for routing to another network where the intended receiver is. The IS itself must make the routing decisions if data must travel to another network.
As mentioned earlier, the Data Link and Physical layers of the OSI protocols were already in existence. OSI specifies the IEEE Logical Link Control (802.2) on the Data Link layer. Physical specifications like RS-232 and X.21 are supported along with popular LAN protocols like token ring and Ethernet.
The OSI transport layer is implemented in five protocols called TP0, TP1, TP2, TP3, and TP4.
OSI Transport Protocols
OSI's session layer can support multiple dialogues. Each one is grouped into message entities known as activities. Activities can be tracked through the session layer protocols to provide error recovery. "Checkpoints" exist within the activities such that if a failure to receive a message occurred the activity could be rolled back to a checkpoint and the two communication entities could be re-synchronized. NetWare employs that same technique for their Transaction Tracking System. Checkpoints in OSI are hierarchical in nature. Major and minor checkpoints may exist and be utilized according to severity of the communication interruption.
A separate protocol exists on OSI's presentation layer that is involved in expressing the data types and structures being transmitted. It is called Abstract Syntax Notation One (or ASN.1). This specification describes whether data ID a real number, integer, character, etc.
On the application layer several services are available, each with a unique function such as allowing remote procedure calls or providing reliable data transfer. These services are called Application Service Elements (ASEs). There are three important ones with diverse functionality.
OSI Application Layer ASEs
There are several key applications that provide the functionality of the OSI protocols. FTAM (File Transfer, Access & Management) provides transparent file sharing across diverse hardware platforms. This is accomplished by using what is called the "virtual filestore". In essence, a universal file system is used as a common denominator between the two different machines. File structures of each are associated with file structures of the universal virtual filestore. Then data can easily be translated from one platform to the other.
A Virtual Terminal (VT) application is employed to allow host sessions with devices running terminal emulation software. This feature is similar to TELNET in the TCP/IP suite. A VT maintains a data structure in common with VT application on a remote machine. Data passes back and forth between the VTs either synchronously using a token-like mechanism or asynchronously where each transmission drives a reply.
The management agent of the OSI protocols is the Common Management Information Protocol (CMIP). The reporting element in CMIP is known as a "manager". The manager collects information about network resources from "agents" which run on individual network resources. The manager then creates statistics based on the data and displays it. The manager also functions as an interface to a management information database called "MIB".
Obviously, the OSI protocols are many and varied. There are friends and foes alike of this protocol suite in the marketplace. Although the government may be reconsidering its mandate for OSI compliant networks, OSI protocols will continue to influence future networking directions.
Other Protocols
There are several other protocols used in a widespread fashion. We'll discuss a couple of those in this section beginning with Apple's proprietary software protocol called AppleTalk.
1. AppleTalk
AppleTalk found birth in 1983 as a proprietary offering designed to network Macintoshes. As a protocol, it has grown up though the years to offer support for the UNIX environment as well as connectivity to DOS and IBM or DEC mainframes. The "feel" of AppleTalk is oriented toward workgroups. Every Macintosh has a built-in LocalTalk (physical) port and comes with the AppleTalk protocols.
AppleTalk has traditionally been supported by numerous third-party vendors. Some of these have complained about the restrictions that the AppleTalk had such as only allowing 254 network nodes. Now such restrictions have been removed in the latest incarnation of AppleTalk called AppleTalk II.
AppleTalk II has added better compatibility with external systems. It still functions on top of the LocalTalk Physical and Data Link specifications available on each Macintosh. In addition, AppleTalk runs on top of Ethernet (called EtherTalk) and token ring (called TokenTalk).
In order to offer functionality to different Data Link layer addresses, the machine running AppleTalk must be able to determine the link layer address of an intended recipient. Though the link layer address may not be available, the higher layer protocol address will be. Basically this is accomplished via the AppleTalk Address Resolution Protocol.
Each node maintains a special table called an Address Mapping Table (AMT). It is used to hold associations between higher layer protocol addresses and link layer addresses. If a node wants to communicate with another, it first checks its own AMT to see of there is a match. If not it "arps" the network by sending out a packet containing the higher layer protocol address. When it is received by the intended node, that node sends back its link layer address to the original node. The initial inquiry is made via a Request packet. The response with link layer information follows.
AppleTalk Protocols & The OSI model
| Application | AppleShare File Server, Print Server & PC |
| Presentation | AFP |
| Session | ASP, PAP |
| Transport | ADSP, ATP |
| Network | DDP, RTMP, ZIP, NBP |
| Physical and Data Link | LocalTalk, EtherTalk, TokenTalk, AARP |
One other type of packet is known as a probe packet. It is used when a node first enters the network. It chooses its own hardware ID number then sends a packet to itself. If it receives a response, then it knows there is another device on the net with the same address, so the new node creates another address and repeats the process. This continues until no response is received from another device. Thus the node can assume that it has chosen a unique code.
On the network level AppleTalk implements the Data Delivery Protocol (DDP). DDP is responsible for making sure data gets to the upper layer processes (sockets) on each node. If you will recall, a datagram infers connectionless service, so there's an element of reliability missing. Sockets are designated by number in AppleTalk. Those numbered 1-127 are reserved for AppleTalk low level processes. Those numbered from 128 to 254 are allocated dynamically.
Since the DDP contains addressing information, a distinction must be made between LocalTalk networks, where node IDs are unique (nonextended), and extended networks where a network and node ID together are unique. An example of an extended network would be an Ethernet LAN. DDP can support either. The addressing is accomplished via a 16 bit network address followed by an 8 bit node ID. The network number is zero if the receiving node is on the same network as the sender. A value of FF signifies a broadcast to every node on the network.
A special version of the DDP supports internetworks. In order to manage the flow of data around an internetwork, extra information is required that is implemented in the extended DDP. This includes network sources and destinations along with a hop count field and checksum for error detection.
On the transport layer, AppleTalk uses four different protocols. Novell, in its materials, considers only the first of these on the transport layer. The other three are grouped by Novell onto the network layer. The first is the AppleTalk Transaction Protocol. The basic structure of this protocol is to provide reliable delivery service of packets from one socket to another. This is accomplished via a Transaction Request (TReq), a Transaction Response (TResp) and a Transaction Release (TRel). The release simply tells ATP that the transaction has been completed. Built in features allow ATP to specify that a transaction only be allowed to occur once or occur at least once.
The Name Binding Protocol (NBP) is used to associate a name describing a specific upper layer process with a network address. Naming is used because it is more convenient for users. As a part of this naming process, entity names are defined, each having unique attributes. These are sometimes referred to as Network Visible Entities or NVEs. NBP provides services that include name lookup, name confirmation, name registration and name deletion. AppleTalk devices are grouped into logical groupings called zones. Looking up names in a zone would be a function of NBP.
Another transport layer protocol is AppleTalk Echo Protocol. It basically only serves the function of echoing back data that has been sent to a node. This is done to determine if a node is located on an internetwork or to determine the amount of time required to send to and receive from a particular node.
The Routing Table Maintenance Protocol is used to maintain information about internetwork connections and addresses. Routers connect local networks as well as WANs. It functions to service multiple protocols with the aid of RTMP, NBP and the Zone Information Protocol.
An entry exists for each network in the router. This entry consists of a Data Link port number, the destination network number, the node ID of the next router, the number of hops to reach the destination network, and a cross-reference to the Zone Information Table, which holds information about a zone's contents. RTMP uses a data, request and response packet. The data packet is used in maintaining up-to-date routing tables. The request and response are used by other nodes to query the router as to pathways.
The Zone Information Protocol (ZIP) is considered to be a higher layer protocol by some, though Novell groups it onto the network layer. ZIP primarily has two functions which include allowing routers to update their routing tables and to assist NBP in determining which networks belong to what zones.
The AppleTalk Session Protocol is responsible for allowing workstations and servers to set up communication. It allows the opening, closing, session request handling, and also session management of the communication. The ASP frame is contained within the data field of a ATP packet. The ASP protocol includes a request for a session, a close session command, and socket IDs for the workstation and the server.
AppleTalk's Printer Access Protocol (PAP) is designed to allow access to printers for printer-dependent applications. PAP works hand-in-hand with NBP and ATP. When an application wants to send data to a printer, a PAPOpen command is used to gain access to the printing device. During the data transmission phase, PAPReads and PAPWrites are executed terminating in a PAPClose. One PAP connection is initiated for each print job. Novell considers this protocol to function on the session layer as it involves a dialogue between application and printer.
The AppleTalk Data Stream Protocol is a very reliable connection-oriented, acknowledged protocol similar in function to TCP. It uses sliding-window technology and allows two-way simultaneous transfers of data between sockets. Novell considers this protocol to be on the transport layer.
AppleTalk's presentation layer protocol is the AppleTalk Filing Protocol (AFP). It is very similar in function to Sun's NFS. In a nutshell, AFP intercepts requests for files from local applications. If the file access will be on the local machine, it routes it accordingly. If bound for a network file server, AFP will drop the request through lower layers and route it through the network. Lower layer protocols are accessed via the AppleTalk Filing Interface (AFI). AFP also provides security like login n names, passwords and directory access control (including search, write and read access).
On the application layer, AppleShare File Server, AppleShare PC and AppleShare Print Server are often found running. AppleShare File Server allows access to files on remote file servers. AppleShare Print Server allows access to shared network printers. AppleShare PC allows compatibility between DOS and Macintosh users by allowing the DOS user to access AppleTalk's filing system and shared printers.
AppleTalk is an expansive suite of protocols that has migrated from a workgroup functionality to compatibility with global networks. Apple will continue to benefit by providing continual expandability to these protocols and their machines.
2. DNA (Digital Network Architecture)
Digital Equipment Corporation's DNA is similar to IBM's SNA in that it is proprietary and pre-dates the OSI model. It has continued to expand over the years providing more and more support for network activities and components.
The DNA (now called Phase V DNA) system is extremely OSI compliant. Its various protocols can be neatly broken down according to OSI model layers. Here is a summary:
There are a few new protocols that come into play with this network type. They are proprietary to DEC and are utilized on various layers.
DEC's oldest and original protocol is Digital Data Communications Message Protocol (DDCMP). This multipurpose protocol supports both commands and data in a synchronous or asynchronous communication. It may be used in direct communication between nodes or with primaries and secondaries, where the primary polls the secondaries. The messages are created from bytes which in turn are constructed by bits grouped by stop bits or sync bits. DDCMP protocols require acknowledgments for messages. However, several packets may be acknowledged at once.
DEC also provides X.25 compatibility through its X.25 services which include Level 2, Level 3, Server Access and Gateway Access modules. The Gateway Access module interfaces with an application and communicates with the Server module running on an X.25 network gateway device. The server application communicates with the network via the X.25 Level 3 module which functions on the transport layer. Next, messages are handed down to a X.25 Level 2 module which allows a session between the X.25 gateway and the X.25 modem device (DCE).
NSP (Network Services Protocol) is DEC's own transport layer protocol. It can provide connection-oriented, controlled-flow services providing high reliability. NSP can also provide fragmentation and defragmentation services. Data flow is controlled a couple of different means involving the sender or receiver. NSP assists in congested networks by informing senders to back off.
DNA's Session Control services provide connections between entities on the network. In addition, address resolution is provided along with address selection. Address resolution involves finding the match for DNA processes in other protocols, then associating them. Once this is accomplished then the processes can be easily selected.
DNA also provides a naming service used to allow hierarchical arrangement of network entities and to access control to them. The naming services make use of a database in which all network entities are stored as objects with properties. The database is divided up into what are known as directories which are often duplicated and spread across several DNA machines. The DNA naming system is very similar to the NetWare Directory Services (NDS) now available with NetWare 4.X.
On the application level DNA offers file transfer services along with terminal emulation, management functions and several gateway services. File transfer is handled by DEC's Data Access Protocol (DAP). It offers basic file manipulation and transfer services.
Terminal Emulation is offered through NVTS (Network Virtual Terminal Service). This system is composed of a module that converts requests from the client into a network format which in turn gets converted to the host format at the host. When the host communicates with the client, the process is reversed.
Management is carried out through DEC's Enterprise Management Architecture. This system uses OSI's Common Management Information Protocol (CMIP) to communicate between a "director" that displays management-related information and agents, which collect data from network entities. Alarms may be configured for any serious situations detected by the management system. Another component of management is the Maintenance Operations Protocol (MOP) used to assist in maintaining a DNA system.
DNA's connectivity to other systems is accomplished through various gateways. DNA systems may communicate with SNA systems via the SNA gateway. This gateway supports full data transfers between DEC systems and IBM systems, user application access to SNA sessions, 3270 terminal emulation for DEC users, and SNA Remote Job Entry (allowing batch processing on an IBM host).
DNA also has a DOS component which allows DOS users to use a DEC host as a file server. In addition, DEC offers extensive support for a myriad of OSI applications.
Lastly, electronic mail is handled by DEC's Mail-11 system. It can interface with numerous other systems including X.400.
DNA is likely to be around a while due to its large installed base and ever-increasing expandability and compatibility. DEC should be saluted for taking a leadership role in trying to implement the OSI services to such degree. It's obvious that the company's leadership believes that OSI is the future of networking, a belief shared by many in this industry.
Chapter 8 Study Tips
1. Know the primary features of NetWare.
2. Know the construction and function of the IPX frame.
3. Know the construction and function of the SPX frame.
4. Know what services NetWare provides on the application layer.
5. Know the function of NetWare's shell files.
6. Know the history behind TCP/IP.
7. Know the construction and function of the IP frame.
8. Know the construction and function of the TCP frame.
9. Be able to briefly list and explain other key TCP/IP-related protocols.
10. Know the contributions and functions of Sun's NFS.
11. Know the history behind SNA.
12. Know SNA's primary features.
13. Know the SNA terminology including "SSCP", "PU", "LU" and others.
14. Know the SNA LU types.
15. Understand the motivating force behind GOSIP.
16. Know the OSI protocol components.
17. Specifically know the OSI transport layer protocols and what services they provide.
18. Know the application layer ASEs.
19. Know who developed AppleTalk and how it differs from other network offerings.
20. Briefly list some of the AppleTalk protocols and mention what layer they fall on according to the OSI model.
21. Know who developed DNA (and I don't mean God).
22. Know what services DNA provides on each layer of the OSI model.
23. Know that DNA closely supports the OSI protocols.
Table of Contents Chapter 7 Chapter 9 Netguru.net Glossary
Copyright© 1993 & 1997 by Atrium Technical Inc. All rights reserved. Illegal to copy without written permission of ATI.