Internet protocol suite |
The Internet protocol suite is the set of (IP), which were also the first two defined.
The Internet protocol suite can be described by analogy with the OSI model, which describes the layers of a protocol stack, not all of which correspond well with internet practice. In a protocol stack, each layer solves a set of problems involving the transmission of data, and provides a well-defined service to the higher layers. Higher layers are logically closer to the user and deal with more abstract data, relying on lower layers to translate data into forms that can eventually be physically manipulated.
The Internet model was produced as the solution to a practical engineering problem. The OSI model, on the other hand, was a more theoretical approach. Therefore, some consider the OSI model as easier to understand, and the TCP/IP model as the one that fits with actual use. Some consider it helpful to have an understanding of the OSI model before learning TCP/IP, as the same principles apply, but are easier to understand in the OSI model.
=Layers in the TCP/IP stack=
There is some discussion about how to map the TCP/IP model onto the OSI model. Since the TCP/IP and OSI protocol suites do not match precisely, there is no one correct answer.
In addition, the OSI model is not really rich enough at the lower layers to capture the true layering; there needs to be an extra layer (the Internetworking layer) between the Transport and Network layers. Protocols specific to a particular network type, but which are run on top of the basic hardware framing, ought to be at the Network layer. Examples of such protocols are Address resolution protocol, and the Spanning Tree Protocol (used to keep redundant Network bridges idle until they are needed). However, they are local protocols and operate beneath the internetwork functionality. Admittedly, placing both groups (not to mention protocols which are logically part of the internetwork layer, but run on top of the internetwork protocol, such as ICMP) all at the same layer can be confusing, but the OSI model is not complex enough to do a better job.
The following diagram attempts to show where various TCP/IP and other protocols would reside in the original OSI model:
Commonly, the top three layers of the OSI model (Application, Presentation and Session) are considered as a single Application Layer in the TCP/IP suite. Because the TCP/IP suite has no unified session layer on which higher layers are built, these functions are typically carried out (or ignored) by individual applications. The most notable difference between TCP/IP and OSI models is the Application layer, as TCP/IP integrates a few steps of the OSI model into its Application layer. A simplified TCP/IP interpretation of the stack is shown below:
==The Network Access layer==
===The physical layer===
The Physical layer describes the physical characteristics of the communication, such as conventions about the nature of the medium used for communication (such as wires, fiber optic links or radio links), and all related details such as connectors, channel codes and modulation, signal strengths, wavelength, low-level sychronization and timing and maximum distances. The Internet protocol suite does not cover the physical layer of any network; see the articles on specific network technologies for detail on the physical layer of each particular technology.
===The data link layer===
The data link layer specifies how packets are transported over the physical layer, including the framing (i.e. the special bit patterns which mark the start and end of packets). Ethernet, for example, includes fields in the packet header which specify which machine or machines on the network a packet is destined for. Examples of Data link layer protocols are Ethernet, IEEE 802.11, SLIP, Token Ring and Asynchronous Transfer Mode.
Point-to-point protocol is a little more complex, as it was originally specified as a separate protocol which ran on top of another data link layer, HDLC/SDLC.
This layer is sometimes further subdivided into Logical Link Control and Media Access Control.
==The Internetwork layer==
As originally defined, the Network layer solves the problem of getting packets across a single network. Examples of such protocols are X.25, and the ARPANET s Host/IMP Protocol.
With the advent of the concept of internetworking, additional functionality was added to this layer, namely getting data from the source computer network to the destination network. This generally involves routing the packet across a network of networks, known as an Internet.
In the internet protocol suite, Internet Protocol performs the basic task of getting packets of data from source to destination. IP can carry data for a number of different higher level protocols; these protocols are each identified by a unique IP Protocol Number . ICMP and IGMP are protocols 1 and 2, respectively.
Some of the protocols carried by IP, such as Internet Control Message Protocol (used to transmit diagnostic information about IP transmission) and Internet Group Management Protocol (used to manage Multicast data) are layered on top of IP but perform network layer functions, illustrating an incompatibility between the internet and OSI models. All routing protocols, such as Border Gateway Protocol, OSPF, and Routing information protocol are also really part of the network layer, although they might seem to belong higher in the stack.
==The transport layer==
The protocols at the Transport layer can solve problems like reliability ( did the data reach the destination ) and ensure that data arrives in the correct order. In the TCP/IP protocol suite, transport protocols also determine which application any given data is intended for.
The dynamic routing protocols which technically fit at this layer in the TCP/IP Protocol Suite (since they run over IP) are generally considered to be part of the Network layer; an example is OSPF (IP protocol number 89).
Transmission control protocol (IP protocol number 6) is a reliable , connection-oriented, transport mechanism providing a reliable byte stream, which makes sure data arrives complete, undamaged, and in order. TCP tries to continuously measure how loaded the network is and throttles its sending rate in order to avoid overloading the network. Furthermore, TCP will attempt to deliver all data correctly in the specified sequence. These are its main differences from UDP, and can become disadvantageous in real-time streaming or routing applications with high internetwork layer loss rates.
The newer Stream Control Transmission Protocol is also a reliable , connection-oriented, transport mechanism. It is record rather than byte oriented, and provides multiple sub-streams multiplexed over a single connection. It also provides multi-homing support, in which a connection end can be represented by multiple IP addresses (representing multiple physical interfaces), such that if one fails the connection is not interrupted. It was developed initially for telephony applications (to transport SS7 over Internet Protocol), but can also be used for other applications.
User datagram protocol (IP protocol number 17) is a connectionless datagram protocol. It is a best effort or unreliable protocol - not because it is particularly unreliable, but because it does not verify that packets have reached their destination, and gives no guarantee that they will arrive in order. If an Application requires these characteristics, it must provide them itself, or use Transmission Control Protocol.
UDP is typically used for applications such as streaming media (audio and video, etc) where on-time arrival is more important than reliability, or for simple query/response applications like DNS lookups, where the overhead of setting up a reliable connection is disproportionately large.
DCCP is currently under development by IETF. It provides TCP s flow control semantics, while keeping UDP s datagram service model visible to the user.
Both TCP and UDP are used to carry a number of higher-level applications. The applications at any given network address are distinguished by their TCP or UDP port number . By convention certain well known ports are associated with specific applications.
Real-time Transport Protocol is a datagram protocol that is designed for real-time data such as streaming audio and video. Although RTP uses the UDP packet format as a basis, it provides a function that is at the same protocol layer.
==The application layer==
The Application layer is the layer that most common network-aware programs use in order to communicate across a network with other programs. Processes that occur in this layer are application specific; data is passed from the network-aware program, in the format used internally by this application, and is encoded into a standard protocol.
Some specific programs are considered to run in this layer. They provide services that directly support user applications. These programs and their corresponding protocols include HTTP (The World Wide Web), File Transfer Protocol (File transport), Simple Mail Transfer Protocol (Email), Secure shell (Secure remote login), DNS (Name IP Address lookups) and many others.
Once the data from an application has been encoded into a standard application layer protocol it will be passed down to the next layer of the IP stack.
At the Transport Layer, applications will most commonly make use of TCP or UDP, and server applications are often associated with a List of well-known ports (computing). Ports for server applications are officially allocated by the Internet Assigned Numbers Authority (IANA) but developers of new protocols today often choose the port numbers themselves. As it is rare to have more than a few server applications on the same system, problems with port conflicts are rare. Application software also generally allows users to specify arbitrary port numbers as Runtime parameters.
=Development=
The Internet protocol suite came from work done by DARPA in the early 1970s. After doing the pioneering ARPANET, DARPA started work on a number of other data transmission technologies, including packet radio, and satellite links. Wanting to be able to communicate across them, Robert E. Kahn of DARPA recruited Vint Cerf of Stanford University to work with him on the problem of connecting multiple networks, using different access protocols.
By the summer of 1973, they had soon worked out a fundamental reformulation, where the differences between network protocols were hidden by using a common internetwork protocol, and instead of the network being responsible for reliability, as in the ARPANET, the hosts became responsible. (Cerf credits Hubert Zimmerman and Louis Pouzin (designer of the CYCLADES network) with important influences on this design.)
With the role of the network reduced to the bare minimum, it became possible to join almost any networks together, no matter what their characteristics were, thereby solving Kahn s initial problem. (One popular saying has it that TCP/IP, the eventual product of Cerf and Kahn s work, will run over two tin cans and a string .) A computer called a gateway (later changed to Router to avoid confusion with other types of gateway ) is provided with an interface to each network, and forwards packets back and forth between them.
The idea was worked out in more detailed form by Cerf s networking research group at Stanford in the 1973–1974 period. (The early networking work at Xerox PARC, which produced the PARC Universal Packet protocol suite, much of which was contemporaneous, was also a significant technical influence; people moved between the two.)
DARPA agreed to fund development of prototype software, and after several years of work, the first somewhat crude demonstration of what had by then become TCP/IP occurred in July 1977.
=Implementation=
*KA9Q
=Related topics=
=External links=
|
|