TCP/IP model: Difference between revisions

Revision as of 02:59, 25 March 2012

Revision as of 03:27, 25 March 2012

Line 1:

{{See also |Internet Protocol Suite}}

The '''TCP/IP model''' is a descriptive framework for [[Protocol (computing)|computer network protocols]] created in the 1970s by [[DARPA]], an agency of the [[United States Department of Defense]].

The '''TCP/IPname model'''derives (Transmissionfrom Controlthe Protocol/Internettwo Protocol)most isimportant aprotocols descriptive framework forof the Internetnetworking Protocolprotocol Suitesuite, ofthe [[ProtocolTransmission (computing)|computerControl network protocolsProtocol]] created(TCP) inand the 1970s by [[DARPAInternet Protocol]], an(IP). agencyThe ofmodel evolved from the [[Unitedoperational States Departmentprinciples of Defense]]. It evolved fromthe [[ARPANET]], which was an early [[wide area network]] and a predecessor of the [[Internet]]. The [[TCP/IP]] Modelmodel is formalized in the [[Internet Protocol Suite]] and is sometimes called the ''Internet Model'' or less often the ''[[United States Department of Defense|DoD]] Model.

The TCP/IP model describes a set of general design guidelines and implementations of specific networking protocols to enable computers to communicate over a [[Computer network|network]]. TCP/IP provides end-to-end connectivity specifying how data should be formatted, addressed, transmitted, [[routing|routed]] and received at the destination. Protocols exist for a variety of different types of communication services between computers.

Line 47:

The following is a description of each layer in the TCP/IP networking model starting from the lowest level.

===Physical Layer===

The [[Physical Layer]] is tangible hardware in any network infrastructure. This includes the cable, satellite or any other connection medium, and the network interface card, which transmits electrical signals, and so on.

===Link Layer===

The [[Link Layer]] (or Network Access Layer) is the networking scope of the local network connection to which a host is attached. This regime is called the ''link'' in Internet literature. This is the lowest component layer of the Internet protocols, as TCP/IP is designed to be hardware independent. As a result TCP/IP is able to be implemented on top of virtually any hardware networking technology.

The Link Layer is used to move packets between the Internet Layer interfaces of two different hosts on the same link. The processes of transmitting and receiving packets on a given link can be controlled both in the [[software]] [[device driver]] for the [[network card]], as well as on [[firmware]] or specialized [[chipsets]]. These will perform [[Data Link Layer|data link]] functions such as adding a [[packet header]] to prepare it for transmission, then actually transmit the frame over a [[Physical Layer|physical]] [[transmission medium|medium]]. The TCP/IP model includes specifications of translating the network addressing methods used in the Internet Protocol to data link addressing, such as [[Media Access Control]] (MAC), however all other aspects below that level are implicitly assumed to exist in the Link Layer, but are not explicitly defined.

Line 59 ⟶ 56:

===Internet Layer===

The [[Internet Layer]] solveshas the problemresponsibility of sending packets across onepotentially or moremultiple networks. [[Internetworking]] requires sending data from the source [[computer network|network]] to the destination network. This process is called [[routing]].<ref>[http://www.comsci.us/datacom/ippacket.html IP Packet Structure]</ref>

In the Internet Protocol Suite, the Internet Protocol performs two basic functions:

* ''Host addressing and identification'': This is accomplished with a hierarchical addressing system (see [[IP address]]).

* ''Packet routing'': This is the basic task of gettingsending packets of data (datagrams) from source to destination by sending them to the next network node (router) closer to the final destination.

IP can carry data for a numbervariety of different [[upper layer protocol]]s. These protocols are each identified by a unique [[List of IP protocol numbers|protocol number]]: for example, [[Internet Control Message Protocol]] (ICMP) and [[Internet Group Management Protocol]] (IGMP) are protocols 1 and 2, respectively.

Some of the protocols carried by IP, such as ICMP (used to transmit diagnostic information about IP transmission) and IGMP (used to manage [[IP Multicast]] data) are layered on top of IP but perform internetworking functions. This illustrates the differences in the architecture of the TCP/IP stack of the Internet and the OSI model.

===Transport Layer===

The responsibility of the [[Transport Layer]]'s responsibilities includeincludes end-to-end message transfer capabilities independent of the underlying network, along with error control, segmentation, flow control, congestion control, and application addressing (port numbers). End to end message transmission or connecting applications at the transport layer can be categorized as either [[connection-oriented]], implemented in [[Transmission Control Protocol]] (TCP),

or [[connectionless]], implemented in [[User Datagram Protocol]] (UDP).

Line 93 ⟶ 90:

===Application Layer===

The [[Application Layer]] refers tocontains the higher-level protocols used by most applications for network communication. Examples of application layer protocols include the [[File Transfer Protocol]] (FTP) and the [[Simple Mail Transfer Protocol]] (SMTP).<ref>[http://www.kohala.com/start/tcpipiv1.html ''TCP/IP Illustrated: the protocols''], ISBN 0-201-63346-9, W. Richard Stevens, February 1994</ref> Data coded according to application layer protocols are then [[encapsulation (networking)|encapsulated]] into one or (occasionally) more transport layer protocols (such as the [[Transmission Control Protocol]] (TCP) or [[User Datagram Protocol]] (UDP)), which in turn use [[lower layer protocol]]s to effect actual data transfer.

Since the IP stack defines no layers between the application and transport layers, the application layer must include any protocols that act like the OSI's presentation and session layer protocols. This is usually done through [[Library (computer science)|libraries]].

Application Layer protocols generally treat the transportTransport layerLayer (and lower) protocols as "[[Black Box|black boxes]]" which provide a stable network connection across which to communicate, although the applications are usually aware of key qualities of the transport layer connection such as the [[Transport Layer|end point]] [[IP Address|IP addresses]] and [[port number]]s. As noted above, layers are not necessarily clearly defined in the Internet protocol suite. Application layer protocols are most often associated with [[client–server]] applications, and the commoner [[server (computing)|servers]] have specific [[TCP and UDP port|ports]] assigned to them by the [[Internet Assigned Numbers Authority|IANA]]: [[HyperText Transfer Protocol|HTTP]] has port 80; [[Telnet]] has port 23; etc. [[client (computing)|Clients]], on the other hand, tend to use [[ephemeral port]]s, i.e. port numbers assigned at random from a range set aside for the purpose.

Transport and lower level layers are largely unconcerned with the specifics of application layer protocols. [[Router (computing)|Router]]s and [[network switch|switches]] do not typically "look inside" the encapsulated traffic to see what kind of application protocol it represents, rather they just provide a conduit for it. However, some [[Firewall (computing)|firewall]] and [[bandwidth throttling]] applications do try to determine what's inside, as with the [[Resource Reservation Protocol]] (RSVP). It's also sometimes necessary for [[Network Address Translation]] (NAT) facilities to take account of the needs of particular application layer protocols. (NAT allows hosts on private networks to communicate with the outside world via a single visible IP address using [[port forwarding]], and is an almost ubiquitous feature of modern domestic [[broadband router]]s).

==Hardware and software implementation==

Normally, application programmers are concerned only with interfaces in the Application Layer and often also in the Transport Layer, while the layers below are services provided by the TCP/IP stack in the operating system. Microcontroller firmware in the network adapter typically handles link issues, supported by driver software in the operational system. Non-programmable analog and digital electronics are normally in charge of the physical components inbelow the Link Layer, typically using an [[application-specific integrated circuit]] (ASIC) chipset for each network interface or other physical standard.

However, hardware or software implementation is not stated in the protocols or the layered reference model. High-performance routers are to a large extent based on fast non-programmable digital electronics, carrying out link level switching.

==OSI and TCP/IP layering differences==

The three top layers in the OSI model—the [[Application Layer]], the [[Presentation Layer]] and the [[Session Layer]]—are not distinguished separately in the TCP/IP model where it is just the Application Layer. While some pure OSI protocol applications, such as [[X.400]], also combined them, there is no ''requirement'' that a TCP/IP protocol stack needs tomust impose monolithic architecture above the Transport Layer. For example, the [[Network File System]] (NFS) application protocol runs over the [[External Data Representation|eXternal Data Representation]] (XDR) presentation protocol, which, in turn, runs over a protocol with Session Layer functionality,called [[Remote Procedure Call]] (RPC). RPC provides reliable record transmission, so it can run safely over the best-effort [[User Datagram Protocol]] (UDP) transport.

The Session Layer roughly corresponds to the Telnet [[virtual terminal]] functionality{{Citation needed|date=June 2009}}, which is part of text based protocols such as the [[HTTP]] and [[SMTP]] TCP/IP model Application Layer protocols. It also corresponds to TCP and UDP port numbering, which is considered as part of the transport layer in the TCP/IP model. Some functions that would have been performed by an OSI presentation layer are realized at the Internet application layer using the [[MIME]] standard, which is used in application layer protocols such as [[HTTP]] and [[SMTP]].

Since theThe IETF protocol development effort is not concerned with strict layering, and some of its protocols may not appear to fit cleanly into the OSI model. These conflicts, however, are moreapparent frequentalso when one only looks atin the original OSI model, ISO 7498, withoutwhen lookingnot atconsidering the annexes to this model (e.g., ISO 7498/4 Management Framework), or the ISO 8648 Internal Organization of the Network Layer (IONL). When the IONL and Management Framework documents are considered, the [[Internet Control Message Protocol|ICMP]] and [[Internet Group Management Protocol|IGMP]] are neatly defined as layer management protocols for the network layer. In like manner, the IONL provides a structure for "subnetwork dependent convergence facilities" such as [[Address Resolution Protocol|ARP]] and [[Reverse Address Resolution Protocol|RARP]].

IETF protocols can be encapsulated recursively, as demonstrated by tunneling protocols such as [[Generic Routing Encapsulation]] (GRE). While basic OSI documents do not consider tunneling, there is some concept of tunneling in yet another extension to the OSI architecture, specifically the transport layer gateways within the International Standardized Profile framework.<ref>[http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=30726 Framework and taxonomy of International Standardized Profiles], ISO 10000, October 1998</ref> The associated OSI development effort, however, has been abandoned given the overwhelming adoption of TCP/IP protocols.

Line 197 ⟶ 194:

These textbooks are secondary sources that may contravene the intent of RFC 1122 and other IETF primary sources such as RFC 3439.<ref name=R3439 />

Different authors have interpreted the RFCs differently regarding the question whether the Link Layer (and the TCP/IP model) covers [[Physical Layer]] issues, or ifwhether athe hardware layer is assumed belowoutside the Linkscope Layerof TCP/IP. Some authors have tried to use other names for the Link Layer, such as ''network interface layer'', in view to avoid confusion with the [[Data Link Layer]] of the seven -layer [[OSI model]]. Others have attempted to map the Internet Protocol model onto the OSI Model. The mapping oftensometimes results in a hybrid model with five layers where the Link Layer is split into a Data Link Layer on top of a Physicalphysical Layerlayer. In literature with a bottom-up approach to Internet communication,<ref name=Forouzan/><ref name=Comer/><ref name=Stallings/> in which hardware issues are emphasized, those are often discussed in terms of physicalthe layerOSI and data link layermodel.

The Internet Layer is usually directly mapped into the OSI Model's [[Network Layer]], a more general concept of network functionality. The Transport Layer of the TCP/IP model, sometimeswhich alsomay be described as thea host-to-host layer, is mapped to OSI Layer 4 (Transport Layer), sometimes also including aspects of OSI Layer 5 ([[Session Layer]]) functionality. OSI's [[Application Layer]], [[Presentation Layer]], and the remaining functionality of the Session Layer are collapsed into TCP/IP's Application Layer. The argument is that these OSI layers do usually not exist as separate processes and protocols in Internet applications.{{Citation needed|date=April 2009}}

However, the Internet protocol stack has never been altered by the Internet Engineering Task Force from the four layers defined in RFC 1122. The IETF makes no effort to follow the OSI model although RFCs sometimes refer to it and often use the old OSI layer numbers. The IETF has repeatedly stated{{Citation needed|date=April 2009}} that Internet protocol and architecture development is not intended to be OSI-compliant. RFC 3439, addressing Internet architecture, contains a section entitled: "Layering Considered Harmful".<ref name=R3439>{{citation

| url = http://www.isi.edu/in-notes/rfc3439.txt

| title = Some Internet Architectural Guidelines and Philosophy