What is?

Network protocols come in many flavors. The following is a discussion of five different but common network protocols that are either in use or were in use in the past. The five that I will be discussing are Ethernet, Local Talk, Token Ring, FDDI, and ATM. Each one has their own set of rules for communicating over the network.

Ethernet

Ethernet is probably the most common protocol that is seen today. Most new network implementations use this protocol due to its popularity and flexibility of mediums. The mediums that can be used in implementing an Ethernet network are twisted pair coaxial cable, fiber optic, and radio waves.

The basis of Ethernet is CSMA/CD or Carrier Sense Multiple Access/ Collision Detection. This means the protocol is aware of the traffic on the communication medium. The protocol uses a routine of checking the line for traffic before transmitting the packet. If traffic is detected, the communications device will hold the packet until there is no congestion on the line. The packet is then sent to the receiver node. If the packet is sent while another packet is on the line, a collision will occur. If this happens the packet will be resent only after a random amount of time.

One of the other reasons Ethernet is favored for implementations is due to the available speed that the network can handle. Ethernet initially could only handle about 10 Megabits per second. This speed has been dramatically increased due to the introductions of Fast Ethernet and Gigabit Ethernet. Fast Ethernet increases the potential speed to 100 Megabits per second. While Gigabit Ethernet does exactly as it name says, it increases the speed up to 1 Gigabit per second. The only limiting factor for these two implementations is the medium that needs to be installed. Category 5 copper cables are the minimum needed for Fast Ethernet. Gigabit Ethernet requires at least Category 5 enhanced cables or fiber optic cabling.

Local Talk

Local Talk is another protocol used in communications across mediums. This one was developed by Apple and is used with Appletalk, though historical installations are not completely related. This protocol uses CSMA/CA, or Carrier Sense Multiple Access with Collision Avoidance. This protocol uses a similar routine as Ethernet does of checking the line for congestion. The difference lies with the protocol using a precursor signal to broadcast its intent to send a packet. This reduces collisions on the mediums to almost nothing.

The positives with Local Talk is it’s easy to install and inexpensive to run. This is mainly due to its flexibility for implementations on multiple topologies, including bus, star, and tree. This is the reason for its popularity. The biggest downfall for the protocol is speed. The maximum speed it can achieve is 230 Kilobits per second. This places it far behind Ethernet in terms of bandwidth.
Token Ring

Token Ring was a common technology in the 1980’s when it was developed by IBM. The protocol uses an electronic token that is passed between nodes. The physical setup of the network is in a star pattern, but the logical topology is a ring. The token moves around the logical setup being passed from node to node. If there is a packet that needs to be moved, it is attached to the token and continues to be passed around the ring until it reaches the destination node. The issue that arises is when one node has data attached to the token; no other node can attach data to that token. If an empty token arrives at a node that has no data to send, the node simply passes the token on to the next node. This process the protocol uses eliminates collisions within the network.

The limiting factor of this protocol is speed. The maximum speed of the network is either 4 Megabits per second or 16 Megabits per second, depending on configuration. This gained popularity when it was developed due to the reliability of transmission. For a time it also rivaled Ethernet in terms of speed, though its 16 Mbps bandwidth limitation has caused it to fall out of favor. Though I have heard that there are a few installations of is left (scary thought).

FDDI

FDDI, or Fiber Distributed Data Interface, is the next protocol that I will discuss. It is a fiber optic network that is somewhat similar to token ring. An electronic token is still passed from one node to another in a similar manner as token ring. The major difference is speed. The maximum bandwidth is 100 Megabits per second, which rivals Ethernet. Another major advantage is the distance between nodes can be miles instead of only few hundred feet. This allows for connections in remote high speed transfer between networks.

The topology of a FDDI network is a ring. Actually, it is composed of two rings. The data in each ring travels in opposite directions. This setup is used for reliability. If the link is broken on one ring, then the other ring is used to continue the flow data.

ATM

ATM, or Asynchronous Transfer Mode, is a high speed protocol that is gaining popularity. This protocol uses a fixed length packet to send and receive data. This is especially helpful in reducing overhead on the network systems, as less processing is need to move data to the next node. This is one of the reasons internet service providers are increasing their use of ATM. A secondary reason is speed. ATM can send data at the speed of 155 Megabits per second, or even higher depending on the network medium. Another use for ATM is connectivity between local area networks. An ATM link between more remote locations is becoming very popular.

The only real downside to ATM is cost. This protocol is expensive to implement and is one of the reason it is not widespread as yet. Though, the cost is beginning to decrease and the speed is increasing. There is a good possibility that ATM implementations could become commonplace even in small local area networks.

EdrawSoft.(2009). "Network Protocol - Types of Network Protocols." Retrieved August 23, 2009, from http://www.edrawsoft.com/Network-Protocol.php

RFC 2616

RFC 2616 is the update to the specifications of Hypertext Transfer Protocol, or HTTP, to version 1.1. This document was published in June 1999. This formalized standard is the basis on how the current internet browsers read data transferred over the World Wide Web. The basis behind this protocol is to create a generic language for communication. This RFC provides the specifications in which Hypertext Transfer Protocol operates across all medium.

One of the main points of this RFC is the Universal Resource Identifier, or URI. The URI is a simple way of identifying a resource. Most people will recognize these as web addresses. On the onset of a person typing in a web address, the DNS server uses the URI to determine the location of the site. One of the more interesting things that can be done with the URI is using a secondary port. The standard port of HTTP is 80. If a colon and a number are added to the end of the URI, the system changes the access port to the corresponding number. There is one other standard port and that is 443. This is the Secure Socket port used in HTTP. Any data that is sent and received while this port is in use will be encrypted.

The actual operation of HTTP is based on methods. Methods are simple commands that query the server for the data needed in retrieving the requested site. For example, one of the methods is GET. GET is a retrieval method that finds and returns whatever information has been requested by the URI. The other methods that are used are OPTIONS, HEAD, POST, PUT, DELETE, TRACE, and CONNECT. These commands can actually be used in the command prompt to test a site if a user has noticed a problem.

Retrieval errors in HTTP are also very common. I know I have seen many over the years. The three main ones I see though are 403, 404, and 500. 403 is the Forbidden error. Usually this is caused by incorrect permissions being set on the requested page or the typed URI is in the root directory. 404 is the Not Found error. This one is caused by a page being deleted or a URI that is incorrectly typed. The 500 error is the worst one if you are the webmaster. This is the Internal Service Error. Basically, the user was able to connect and the server responded, but the database or other background service failed. This is a problem on the side of the company and is not fixable on the user side.

The simplicity of HTTP makes it very favorable to be used across networks. The server only needs to respond when a request has been made. The request themselves are extremely simple, allowing for only a small amount of overhead on the system. This means that a server handling HTTP requests does not need to be as powerful as a Domain Controller. In hardware terms though the more RAM the better.

Berners-Lee, T, et al. (June 1999). "Hypertext Transfer Protocol -- HTTP/1.1." Retrieved August 19, 2009, from http://www.ietf.org/rfc/rfc2616.txt?number=2616

RFC 1035

RFC 1035 is the modern specifications of Domain Name Service, or DNS. This document was published in November 1987, as a replacement of three other RFCs. The Domain Name Service was created to provide users with an easier system of locating addresses over networks. This document provides an overview of the implementation of the service and then drills down into the specifications of how Domain Name Service operates on a network. The following is a brief review of this RFC documentation.

The basic process of the DNS is to convert domain name, such as a web address, into an IP address. Let’s begin the process at a client node. The client node starts with the basic knowledge of one DNS server. This server is in the configuration that client receives when being assigned an IP address by the DHCP server. When the user requests a domain, for example a web address, the client node looks up the IP address from the DNS server that it has been assigned. If that DNS server cannot resolve the name and address, it passes the request onto the next DNS server. This process continues until either a localized DNS server can resolve the name or the request reaches the Master Domain Name Servers. There are currently 13 of these servers around the world. Once the IP address is resolved, it is sent back to the client node, and further communication can take place.

One of the most important activities that these DNS servers can perform is name caching. When a request is returned from the Master Domain Name Servers, it passes back through each of the preliminary DNS servers. Each one of these servers records the name to IP address link in its own cache. If another client requests the same domain name, the request will be resolved at the initial DNS server, and not have to be forward to the top level domains.
Within a DNS server entry, there are several different types of records. The most important of these are A, NS, CNAME, SOA, PTR, and MX. Each of these serves a different function. For example, the MX type is for mail exchange. This entry holds commonly used addresses that are used for email servers. When an email is sent, the DNS server looks for this entry. If one is not found, it uses the resolution process as described above to determine the location of the destination server.

Personally, DNS is one the best developments that has been made. Think about it, if DNS had not been developed, we would have to memorize IP addresses to surf the internet. It would not make it as much fun.

If the client machine is running Windows, there is a way to clear the DNS locally in case of corruption. If the user brings up a command prompt, using the command IPCONFIG /flushdns will clear the local DNS cache. The client machine will then start rebuilding its cache automatically as the machine is being used.

Mockapetris, P. (November 1987). "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION." Retrieved August 19, 2009, from http://www.ietf.org/rfc/rfc1035.txt?number=1035

RFC 2131

RFC 2131 is the introduction of Dynamic Host Configuration Protocol, or DHCP, in its current incarnation. This document was published in March 1997. This formalized standard is used in describing how IP, or Internet Protocol, addresses are assigned in a dynamic form. This is accomplished by using the Client-Server model of networking. This document provides an overview of the purpose and then drills down into the specifications of how Dynamic Host Configuration Protocol functions. The following is a brief review of this document.

DHCP can use three different methods assigning addresses. These are automatic allocation, dynamic allocation, and manual allocation. The most common mechanism that is used is dynamic allocation. This function assigns the IP address to a node temporally. This temporary assignment is called a lease. The lease is set for a configurable amount of time by the administrator, usually 12 hours. Once the lease time is expired, the client needs to request a new IP address. For the sake of ease, the DHCP server will usually re-assign the same address to the client.

The process that the clients and DHCP server go through for address assignment has basically six steps. In the first step, the client sends out a broadcast of a DHCPDISCOVER message. This broadcast is received by one or more DHCP servers. In the second step of the process, the DHCP servers that received the initial DHCPDISCOVER message will respond with a DHCPOFFER message to the client. This leads to the third step, the DHCPREQUEST message that is sent by the client. This is a direct response to the offer with the client using the IP address within the packet response. If the IP address has not been assigned by the time the DHCPREQUEST has been returned, the server will respond to the request with a DHCPACK message. Otherwise, the server will send a DHCPNAK message and the client will have to start the process over. If the DHCPACK message is sent in step four, the client will use the parameters contained in the packet to configure itself. The sixth and final step in the process is the process is the DHCPRELEASE message that is sent by the client to resign control of that IP address.

The IP address that is assigned during this process is kept by the client only for the period of the lease time. This time, typically 12 hours, can be configured to meet the needs of the network. Using the example of the 12 hour lease, a lease renewal will be sent by the server at half the lease time. In this example, the message will be sent at six hours remaining. This is sent to the client as another DHCPACK message. If accepted by the client, the lease is renewed. This is repeated until either the lease expires or the DHCPRELEASE message is sent by the client.
On a side note to the DHCP process, the address on a Microsoft Windows’ client can be released and renewed manually. This is done by using the commands IPCONFIG /release and IPCONFIG /renew in the command prompt window.

Droms, R. (March 1997). "DYNAMIC HOST CONFIGURATION PROTOCOL." Retrieved August 19, 2009, from http://www.ietf.org/rfc/rfc2131.txt?number=2131

RFC 793

RFC 793 is the introduction of Transmission Control Protocol, or TCP, as it is currently being used. This document was published in September 1981. This formalized standard that has been in use for the past 30 years. The document provides an overview of the purpose and then drills down into the specifications of how Transmission Control Protocol works. The following is a brief review of this document.

Transmission Control Protocol was developed to provide a reliable connection between hosts. This is accomplished by using an acknowledgement of a received packet. The acknowledgment is only given if the packet was received and the checksum is correct. The destination node will request a new packet if there is a problem. Other than reliability, TCP also has a Basic Data Transfer. This provides a constant flow of packets to the destination. The next facility that TCP has is Flow Control. This allows each end node the ability to control the number of packets being sent. Also, Transmission Control Protocol has multiplexing ability. This allows any nodes to send and receive simultaneously on multiple ports. The next facility that TCP uses is Connections. Both the source and destination nodes create a common link that help provide the reliability of the communication. Precedence and Security are also available but are optional to a TCP connection.

The middle of the RFC deals with the specifications of the header. The header consists of 11 parts. The first two parts of the header are the 16 bits of the source port and the 16 bits of the destination port. The next two sections of the header are the 32 bit sections of the sequence number and acknowledgement number. The acknowledgement number is the sequence number of the next packet. The next part of the header is the 4 bits in the data offset. This indicates the length of the entire header. Following the data offset, there is a 6 bit reserved section which, according to the RFC, is to be set to zero for future use. The next section is the group of six control bits. These are the Urgent Pointer field significant, or URG, the Acknowledgment field significant, or ACK, the Push Function, or PSH, the Reset, or RST, Synchronize sequence numbers, or SYN, and finally the final bit, or FIN. Following the control bits, the 16 bit Window indicts the number of octets that can be sent back to the sender. The next segment is the 16 bit checksum. The final fixed length section of 16 bits is the Urgent pointer. The variable length of the Options section and the padding finish off the header.

The remainder of the RFC describes how the communications works between the source and the destination. This process uses SYN, ACK and the rest of the control bits to establish the connection, communicate, and terminate the connection. The RFC also describes how the protocol handles error processing during communication. These processes are fairly complicated and are would be too much for this blog.

Postel, J. (September 1981). "TRANSMISSION CONTROL PROTOCOL." Retrieved August 19, 2009, from http://www.ietf.org/rfc/rfc0793.txt?number=793

RFC 791

RFC 791 is the introduction of Internet Protocol, or IP, as it is known today. The publication of this document occurred in September 1981. It is an amalgamation of six prior RFCs, into a formalized standard that has been in use for almost the past 30 years. The document provides an overview of the protocol and then drills down into the specifications of how Internet Protocol works. The following is a brief review of this document.
Internet Protocol is the addressing scheme that is used to move packets between connected systems. The packets, referred to as datagrams in this document, are moved from one node to another by stripping off and adding local network headers as needed. These are then passed to the next node in the network. This is continued until the packet reaches its destination.
The most prevalent subject of this RFC is the header of the packet. The header that is created within this protocol, provide routing support throughout local networks and across the internet. The basis of this header is the four octet address. These are 32-bit sections of the header that are used to list out the source address of the packet, and the destination module that the packet is being routed to.
There are 11 other field specifications of the header. The first is the version field, which is a four bit representation of the protocol header version. The next field is the internet header length, or IHL, which is a four bit representation of the length of the header. Following that is the type of service field. This is an eight bit section of the header that indicates the packet priority. The next field is the representation of the total length. This is a 16 bit field that measures the number of octets in the packet. On a side note, the maximum standard size of a packet is 576 octets, unless the receiver node has been prepared to accept larger packets. The next field is the Identification field. This is also a 16 bit field that directs the destination node in reassembling the fragment of the packet. The next field is the Flags field, which is a three bit control field. Following the flag field is the Fragment Offset field. This is the location of the fragment in a series of packets. Next is the eight bit time to live field. This is the maximum amount of time a packet can have to reach its destination. The next field is the Protocol field, or the representation of the protocol that the packet is being sent with. Currently the most popular is TCP. The last field before the addresses is the Header Checksum. This is a 16 bit field that is recalculated and verified at each intermediate node.
The packet header also has an Options field. This field is located after the source and destination addresses. It can be of variable length or non-existent. The rest of the RFC is comprised of usage procedures and options. These are organized as examples in the Appendices. Overall, this is nice reference material for network architecture.

Postel, J.,(September 1981). "INTERNET PROTOCOL." Retrieved August 19, 2009, from http://www.ietf.org/rfc/rfc0791.txt?number=791

What is Enterprise Architecture?

To begin my foray into my Master’s studies, I must begin by asking “What is Enterprise Architecture?” The answer to this question is simply: “how the organization is structured.” This simple answer though does not even scratch the surface of the complex nature of the operations of an enterprise size organization.

The real question that needs to be addressed is how Enterprise Architecture correlates to the Information Technology field. Microsoft breaks down this view into four perspectives: business, application, information, and technology (Platt, 2002). I am not going to go into full detail about each perspective, but I will say that an information technology specialist needs to be aware of each part. A connection also needs to be established between each view for an enterprise to run efficiently.

Software systems that deal with enterprise resource planning, or ERP, have done a great deal with increasing the communication between each perspective. This is happening in all departments of companies not just I.T. Technology, when implemented properly, can have an ever increasing positive effect on the structure of an company.


Platt, Michael (July 2002). Microsoft Architecture Overview. Retrieved August 16, 2009, from http://msdn.microsoft.com/en-us/architecture/ms978007.aspx