Talk:Internet protocol suite

From Wikipedia, the free encyclopedia

	This article is part of WikiProject Computer networking, an attempt to build a comprehensive and detailed guide to Computer networking on Wikipedia. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion.	Computer networking Portal
B	This article has been rated as B-Class on the assessment scale.
High	This article is on a subject of high priority within Computer networking for inclusion in Wikipedia 1.0.
Computer networking To-do: edit  Computer networking Collaboration of the week: Wikipedia:Computer networking Collaboration of the week/current Template:Cnbox contents

Contents 1 Layers 2 Why 7 layers? 3 Confusing layers 4 OSI was practical 5 Tanenbaum 6 IPstack 7 Readings typo 8 Some Clarification 9 It would be great... 10 MPLS 11 List of common ports 12 SIP As Transport Protocol in OSI? 13 Scheme vs. protocol 14 Take OSI Out (of the top area) 15 drivers comment 16 TCP/IP redirection change 17 Layers in the Internet Protocol stack 18 How IP Kills and Eats Competitive Networks 19 DoD model 20 The "stack" has how many layers? 21 overlap 22 Capitalization of standard protocols - Transmission Control Protocol vs Transmission control protocol 23 A comment about the article 24 TCP/IP a 5 Layer Model? 25 OSI Model and SSL 26 Session layer description missing 27 Web services model? Do we need an extra layer in the future? 28 Please emphasize the five layer model 29 Typical implementation 30 RSVP and RTP?

[edit] Layers

Isn't UDP and TCP in the same layer ? --arcade

Yes, you are right... changing it now. -- SJK

Isn't ARP and RARP in the datalink Layer? (FD)

I've know idea how this wiki things works, but I've been implementing TCP/IP since the 1980s, so I'll plead forgiveness for presenational issues in this comment. I think that the mention of layers in this article is so excessive as to be harmful. It obscures the major point: TCP/IP is the protocol of the Internet. It was designed to interconnect disparate networks, so it runs over a wide variety of media and can be implemented on a wide range of hardware. It made some interesting, and mainly correct, design choices: packetised, packet loss as a signal for flow control, heirarchical network addresses, a simple and robust directory mechanism, in-band routing and management, intelligence in the hosts rather than in the switches. The design of the protocol was a large factor in the success of the Internet, and in turn the success of the Internet is driving out all competing protocols to IP (such as IPX, AppleTalk, most SNA). There's so much more to TCP/IP than this overboiled layering discussion.

The discussion of OSI v IETF politics is naive and is best left out. An article introducing TCP/IP to the public need not get bogged down in decade-old minutia. The more significant event from that era was ARPA's funding of the TCP/IP implementation of BSD UNIX. This made a free TCP/IP implementation readily available for porting to other platforms: to the extent that most operating system's initial implementation of TCP/IP were ports of the BSD UNIX software (Windows NT, Linux, OS/370, etc).

Just to put a nail in the layering coffin, consider HTTP. The language negotiation there is OSI Presenation Layer. The ability to do multiple concurrent transfers in HTTP 1.1 is OSI Session Layer. The HTML content is obviously Application Layer. See how confusing it all gets. Such standards lawyering is fun, but it doesn't help the reader understand your point.

The discussion should mention layers only so far as they illustrate other important points. Such as the following. TCP/IP has a network layer: IP. That layer gives every machine at least one unique address (in either version 4 addresses or version 6 addresses or both). Then it has an thin adaption layer to the link layer (for example, ARP for ethernet). A major reason for TCP/IP's success is that IP was designed so this layer is thin, efficient and simple to implement. Then it has a variety of transport protocols that offer varying services: unreliable datagrams (UDP), reliable datagrams (DCCP), reliable ordered connections (TCP), reliable unordered connections (SCP), and reliable memory transfer (RDMA). Part of the reason for TCP/IP's success is that these services mapped well to what programmers needed to write applications. Such as the DNS and HTML applications you are using right now. Unlike some protocols, TCP/IP mainly implements routing, signalling and network management using TCP/IP as though they were applications; this makes routing cheap to implement and allows competition for software which supervises network elements.

Finally, to the person below that thinks OSI is well designed: it doesn't matter anymore. OSI was designed for a world of 48Kbps links and then further development stalled. TCP/IP has evolved to handle the gigabit world where bandwidth is no longer a limitation but there's a hard limit to latency, that is, on the speed of light in fiber (so TCP has evolved the TCP window scaling and TCP timestamp features). OSI had a great deal of session startup time as each layer performed feature and profile negotiation, negligble at 48Mbps but the dominant performance barrier at 10Mbps. Sure, this could be designed out of OSI, but as I noted further design work has long ceased.

What ISO wasn't was cheap: both to purchase and to run. There were no free implementations for a very long time. The telephone comanpies saw OSI working just like phones: want to do the equivalent of a DNS lookup: that's US$0.05 (in 1990) to the phone company. The phone companies all wanted regional variations too: thus the notorious GOSIP profile, where governments had to mandate a minimal set of profile contents to get some sort of interoperability. TCP/IP offered the same facilities for a lot less, on a wider variety of machines, uniformly across the world. --gdt 2006-07-31

[edit] Why 7 layers?

Why are there 7 layers in the stack? I thought that TCP/IP only had 5.

5. Application - DNS, HTTP, FTP, Telnet, etc.
4. Transport - TCP, UDP
3. Network - IP
2. LAN/Link - network address (physical or MAC)
1. Physical - low-level signal

—The preceding unsigned comment was added by 64.247.79.58 (talk • contribs) 03:48, 8 June 2003.

TCP is best looked at is 5 layers but some companies such as cisco try and shoehorn it into the OSI 7 layer model Plugwash 20:10, 22 September 2005 (UTC)

[edit] Confusing layers

When I think about it, I think ICMP is on the same layer as those too .. IGMP I know nothing about, though. --Wikipedians/arcade

Yes, that's right: Even although ICMP is a required protocol for the TCP/IP stack, it is still implemented as a Transport layer protocol, not as a Network layer protocol. This can be easily seen by the fact that ICMP has a protocol number (it being protocol number 1). The same is true for IGMP (except that it has protocol number 2).

In fact, there is only one network layer protocol in the TCP/IP stack: IP itself. -- Wouter Verhelst 12:42, 9 February 2004

Hmm, when I think a bit more about it. The Internet Protocol Suite doesn't follow the OSI layering all the way, so the stack is quite simply ... wrong, as it is portrayed.

The 3 bottom layers are pretty okay. However, IMCP is dependent on IP, so it needs to be pushed higher up on the stack. HTTP/STMP/SNMP and so forth are _NOT_ dependent on the layer that is presented as beneath it, and thus needs to be bumped down.

Roughly, something like:

7. Protocols that are tunnelled through those in layer 6. Say an XML protocol served through a HTTP server.
6. HTTP/SMTP/SNMP/FTP/and-so-forth
5. TCP/UDP/ICMP/Whatever
4. Transport (IP, for the internet protocol)
3. Network
2. Data Link
1. Physical

--Wikipedians/arcade

No, you're applying the OSI network concept to the TCP/IP network stack. That isn't correct. -- Wouter Verhelst 12:42, 9 February 2004

No, OSI/ISO is the standard, so applying it is standard when talking about TCP/IP layers. What they say goes, they say seven, then there are seven.

Not sure about that... How about:

=> Application (telnet, ftp, http, dns, ...)
4. Transport (TCP, UDP...)
3. Network (IP)
2. Data Link (Ethernet, Token-ring, ISDN...)
1. Physical

Labelling formats like JPEG (or EBCDIC / ASCII) as a presentation layer is a bit of a hack to force the square peg of real world networking into the round hole of OSI protocol stackery (IMHO, of course).

Sometimes the Application Layer is still called layer 7 for "compatibility", but there is no real unified layer 5 or 6 -- sessions, presentation and data formats are considered the task of applications, and are absolutely not part of the TCP/IP protocol suite. --Paul 16:28, 23 July 2003

ICMP is definitely not part of the transport layer. Layers in the OSI model are defined by functionality, not by dependencies between protocols (think modules). Layer != Protocol! So everything which is related to getting packets from one host to another is logically part of the Network layer. That includes routing - which in at least one case has a protocol (BGP) runs on top of TCP (which is at the transport layer)! Look, I know this all seems totally crazed - it is totally crazed. The ISO model has only limited usefulness. It divides things up into functional layers, it is not a module dependency diagram.

It's for these reasons that I removed ICMP from Template:IPstack. It was at the wrong layer, and since it is such a confusing case, it seemed better not to include any of these confusing cases in the diagram. Noel 13:02, 14 Sep 2004 (UTC)

I think the German suite diagram clears up some of these confusing elements. Also, following some of the protocol links like de:HTTP shows the implementation dependencies via another diagram. Dols 13:04, 2004 Oct 6 (UTC)

I don't understand this comment. I looked at the pages you mention, and their diagrams look pretty much identical to Template:IPstack, except that it has a few more protocols. Noel (talk) 05:33, 16 Dec 2004 (UTC)

Back in October the diagram looked different. http://de.wikipedia.org/w/wiki.phtml?title=TCP/IP-Referenzmodell&oldid=2921843 I'll try to stop adding confusion into the confusing layers discussion. Dols 00:01, 2004 Dec 18 (UTC)

Ooops! My fault for coming by and adding a comment so much later! Yes, now I understand your comment.

Still, the old version (the one you linked to above) of the diagram has many of the problems I mentioned above - e.g. it lists BGP as being at the application layer (yes, I know it uses TCP, but...) and also DNS as an application (Email and HTTP will be astonished to hear that), shows ICMP as a tranport protocol (it's entirely part of the internet layer), etc. Noel (talk) 00:57, 18 Dec 2004 (UTC)

[edit] OSI was practical

Can't agree with "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."

Internet architecture developed as a means of internetworking on a "non-sectarian" basis-- a practical engineering problem.

The OSI Reference Model likewise developed as a means for networking systems on a "non-sectarian" basis. More specifically, there was a clear understanding at the time that the goal was to interconnect computers and/or devices in a way that did not depend on IBM intellectual property. Witness the striking similarities between the OSI Reference Model and IBM's SNA. Anyone working for DEC or NEC or HP or Siemens or the like at the time will assure you it was a VERY practical engineering problem.

OSI protocols became ungainly and arcance in toto not because the work was theoretical but because the work was done in government-entangled standards bodies. Anyone familiar with the total output of the internet community knows it's output is likewise full of a lot of unused junk and nonsense besides the successful and critical parts, regardless of it's requirement for "working code". —The preceding unsigned comment was added by 172.208.215.173 (talk • contribs) 05:43, 27 December 2003.

This, in my ever-so-humble opinion, is a load of hooey. As even a brief googling can show (e.g. [1]), it was intended as a research effort - and its myriad layers were there from the start, not due to standards bodies' meddling. --moof 00:37, 29 October 2005 (UTC)

[edit] Tanenbaum

I'm looking at a Dutch translation from Andrew S. Tanenbaum's "Computer Networks, Third edition" right now. On pages 29 to 36, it describes the ISO model; then, on pages 37 to 39, it gives an introduction in the TCP/IP reference model.

Tanenbaum names the following layers in TCP/IP:

• Application layer (functionally similar to OSI's application layer)
• Transport layer (similar to OSI's transport layer)
• Internet layer (similar to OSI's network layer)
• Host-to-network layer (implementing functionality from OSI's datalink- and physical layer).

The paragraph about the host-to-network layer transcribes approximately to the following:

"Under the Internet layer is a big empty space. The TCP/IP reference model doesn't say a lot about what happens here, except that it specifies that the host has to connect to the network using a protocol that allows it to send IP packets. This protocol isn't defined; it varies from host to host and from network to network. In books and articles about the TCP/IP model, this protocol is rarely ever mentioned"

As examples, Tanenbaum mentions ARPANET, SATNET, Packet radio, and LAN. -- Wouter Verhelst 10:59, 5 May 2004

There are only FOUR layers in the TCP/IP suite! The Tantenbaum citing is correct. Please fix your main definition page. -- MJ Foy Sr. MCSE, MCT, Net+ A+, CCNA, CNA, Security+, BS 16:39, 21 July 2004

The TCP/IP suite does not have a fixed number of layers, nor are protocols formally assigned to any layer. It only talks about protocol dependencies (i.e. protocol A uses protocol B). In fact, with some of the ISO protocols which have been adopted to run over TCP, there are in fact more than 4 levels of protocol involved, since the ISO session/etc protocols are used as well as the application. Noel (talk) 05:19, 16 Dec 2004 (UTC)

[edit] IPstack

Guys, can anyone tell me how the {{IPstack}} tag works, where it is defined and how to edit it? Thanks. Sridev 13:48, 25 Sep 2004 (UTC)

It's at Template:IPstack. The way it works is that when the page-rendering code reads the {{IPstack}}, it replaces it with the contents of the Template:IPstack page. May I suggest you mention your proposed change(s) at Template_talk:IPstack first? Thanks... Noel (talk) 05:14, 16 Dec 2004 (UTC)

[edit] Readings typo

Surely we can recommend additional readings besides a MS Windows 2003 book?

In any event, the citation contained 2 typos: The corrected version appears below

Davies, Joseph and Lee, Thomas. (2003). Microsoft® Windows® Server 2003 TCP/IP Protocols and Services Technical Reference. Microsoft Press, Redmond Washington, USA.

Hopefully these corrections will also eventually filter down to derivitive sites such as: http://www.domainsarefree.com/glossary/Internet_protocol_suite.html (They also need to change their character set from utf-8 to iso-8859-1 so the ® marks render properly.) —The preceding unsigned comment was added by 65.88.178.10 (talk • contribs) 19:30, 4 November 2004.

Wish granted. Replaced book list with more representative "classic" titles. - Dmeranda 05:10, 23 Nov 2004 (UTC)

[edit] Some Clarification

The reference above stating there are only four layers in the TCP/IP model is accurate. The "Host-to-network" layer is often refered to as the Network Access layer. The TCP/IP model has no Physical layer because LAN and WAN protocols operate partly at the OSI Physical layer and partly at the IEEE 802.3 Media Access Control (MAC) sublayer of the OSI Data Link layer. The TCP/IP model was designed to be completely independent of the LAN/WAN protocol frames that encapsulate IP packets. Thus, an IP packet can be encapsulated in an Ethernet frame, a Token Ring frame, or any other type of frame, and the IP packet is not changed, nor is the function of the TCP protocol affected in any way. By extension, the TCP segment encapsulated inside the IP packet is not changed either.

The upper half of the OSI Data Link layer, the IEEE Logical Link Control (LLC) sublayer, can be said to loosely correspond to the TCP/IP Network Access layer. The lower half of the OSI Data Link layer, the IEEE MAC sublayer, and the OSI Physical layer, can only be said to correspond to the TCP/IP Network Access layer in a general sense. The Network Access layer is necessary to allow an IP packet to make a physical link to the network media. Generally, this is done by maping IP addresses to physical hardware addresses and encapsulating IP packets into frames. The physical media connection is defined based on the hardware type and network interface, as well as the LAN/WAN protocol in use. Jim Elms, CCNA, CCAI 05:55, 24 December 2004

It's true that in some rough sense, the IP model has only 4 layers (particular network, internetwork, transport and application), but that's only in a rough sense.

For one thing, in understanding the particular network at hand, that network is usually structured as a series of layers - at least 2, and in some cases more. E.g for 802.* networks, there's a physical layer (what voltage correspond to 1 and 0, bit rate) which differs from technology to technology, as well as framing layer (what a packet looks like), and some of them have a (third) MAC layer as well. ATM is another good example; above the physical layer, and the framing layer, there are protocols (AAL is their name, IIRC) for breaking up a large packet into 48-byte chunks, other protocols for setting up PVC's, etc.

And then there's MPLS, which is its own little complication - since it is intended to carry a packet across multiple networks, its an internetworking protocol, but it's below IP...

The second way in which that 4-layer model is only roughly correc is that IP is starting to use more than 1 layer above the transport. A good example doesn't come to mind off the top of my head, but if e.g. some application uses a standard remote procedure call protocol on top of TCP, then there are two layers on top of the application. One might view both email (822 header and SMTP) and the web (HTML and HTTP) as having several layers. Etc, etc... Noel (talk) 12:58, 22 September 2005 (UTC)

[edit] It would be great...

It would be great if this article had some practical info. I'm currently struggling with TCP/IP settings. Chamaeleon 18:04, 2 Mar 2005 (UTC)

This is an encyclopaedia, not a "how to" manual. Noel (talk) 12:58, 22 September 2005 (UTC)

Regardless, practical info is a good way to relate technical content. Chamaeleon, what would you like to see added that isn't in the land of tutorials? Cburnett 02:44, 6 March 2006 (UTC)

[edit] MPLS

Not really sure where MPLS fits into this picture. From ISO Model Talk I Wrote:

MPLS is considerd to be a switching techonology, i.e. layer 2. However it runs on other layer 2 technologies such as Ethernet or ATM, then why is it not considerd layer 3. Then again is what defines a layer 2 Protocol one that specifies the next hop in the path while layer 3 specifies the final destination.

Possibily could MPLS be considerd a sub-layer of Layer 2, so if MPLS ran over Ethernet there would be 3 sub-layers LLC layer, MAC layer and MPLS layer. Vec 19 April 2005

MPLS is definitely a layer-3 protocol; in fact, it's actually an "internetwork layer" protocol - albeit a lower-sublayer of the internetwork layer, underneath IP, etc. That's because MPLS is used (potentially) to deliver a packet across multiple networks, so it's inherently an internetworking protocol. Noel (talk) 19:35, 14 September 2005 (UTC)

Some consider MPLS to be layer '2.5' - mostly because it contains hints to the layer 2 fabric while remaining primarily level 3.

[edit] List of common ports

I was just skimming this article, and as I got near the bottom found my screen filled with the list of port numbers; it rather surprised me. Now, firstly, do we need this list at all? We already have a List of well-known ports (computing), which is naturally more comprehensive, and port numbers aren't directly relevant to this article. And secondly, if it is kept, it should be pruned mercilessly (why, for instance, is QOTD mentionned in such a short list?) and formatted to take up less space (while the number-in-a-square trick looks kinda cool, its main effect is to spread the list right down the page; ugly). Anyone any thoughts? - IMSoP 20:32, 2 August 2005 (UTC)

I say remove the whole list. Port numbers are useless without specifying TCP or UDP. And QOTD and gopher hardly belong in such a short list. Rather than redo it to include TCP/UDP, I say just provide a link to the main article listing well-known ports. Pfalstad 18:33, 3 August 2005 (UTC)

[edit] SIP As Transport Protocol in OSI?

In the TCP model, Session Initiation Protocol is at application layer because there really is nothing else over the transport layer. But given what is listed on OSI, it seems SIP should be included at the transport layer there. This is especially true with its growing importance of SIP in VoIP.

It just seems like it should be here somewhere... —The preceding unsigned comment was added by 157.127.124.134 (talk • contribs) 12:51, 26 August 2005.

[edit] Scheme vs. protocol

HTTPS (actually https:) is a URI scheme, not a protocol. The scheme describes a different protocol stack that includes SSL or TLS, but the protocol is no different. For that reason, might it be better to keep the distinction clear? —The preceding unsigned comment was added by 47.153.233.240 (talk • contribs) 05:15, 29 August 2005.

See Talk:HTTPS Hrvoje Šimić 06:55:44, 2005-09-13 (UTC)

[edit] Take OSI Out (of the top area)

Sorry to re-open the layers issue, but I have a real problem with the page as it stands. When I click on "Internet protocol suite", one of the first things I would expect to find would be a (rough) diagram of the IP/etc stack, showing how things relate to each other. What do I actually find? The first diagram is of the OSI stack, with IP-related protocols jammed into the OSI layers.

Now, if the IP stack was even attempting to be an implementation of the OSI model, this would be valid -- but it isn't! IP follows its own model, which is not the OSI model. The IP layers do not map onto OSI layers (exactly). So, for the discussion to begin with "IP in terms of OSI" is, in my opinion, just plain wrong, as well as misleading. My feeling is that the whole "Layers in the TCP/IP stack" section should not even mention OSI, as it's not really relevant -- IP is IP, not OSI. The "Layers" section should be rewritten in terms of IP/etc. alone, and with a nice diagram showing how the bits relate. I'm thinking of something along the lines of the old German suite diagram, maybe enhanced to include more stuff. I like it because it doesn't just arbitrarily split things into layers; it shows how things actually relate to each other, and how some things (eg. ARP) span layers, which is closer to the truth.

Now, clearly there is some correspondence between the IP stack and the OSI stack, and the OSI stack is often presented as an "idealised" networking model in textbooks etc. (regardless of how valid this may be). So, I think a later section titled something like "The IP Suite as it relates to OSI" would be appropriate for that material; maybe after the "Development" section. I think this should include virtually all of the current "Layers in the TCP/IP stack" section.

So any comments? I'll go ahead and do it if there are no objections. -- Johantheghost

Objection from me. TCP/IP is commonly taught using the OSI layers. My University taught it as such (Oxford Brookes), and Cisco's certification process teaches it as such. It may not have been originaly developed as an OSI model network, but it has served very well to describe it within that model. To quote Tanenbaum in Computer Networks, pp44 third international edition, on his choice to teach with a OSI Hybrid model, "In Summary, despite its problems, the OSI model (minus the session and presentation layers) has proven to be exceptionaly useful for discussing computer networks. ... The reverse is true of TCP/IP: the model is practicaly nonexistant."

So I'm for keeping of the full OSI model, since some teaching methods use that, and Tanenbaum's hybrid model, since some teaching methods use that. --John R. Barberio ^{talk, contribs} 12:41, 17 September 2005 (UTC)

Just because other people do things in a confusing way doesn't mean we have to. I fully approve of relegating the (semi-useless, and certainly confusing) OSI model to a secondary position. Noel (talk) 12:58, 22 September 2005 (UTC)

OSI isn't *entirely* useless - just *mostly* useless. That said, if there isn't a Comparison of TCP and OSI protocol stacks article, or something along those lines, that the material should go there; as it stands, the content is out-of-context and should be removed. --moof 18:12, 6 November 2005 (UTC)

I recently rewrote the article and put the IP stack first and then pushed all the OSI stuff into it's own section. Primarily because this article is about the IP stack, not the OSI model nor a comparison between the two — so the IP stack comes first. I think an OSI comparison is definitely warranted but after explaining what the IP stack is first. Cburnett 02:51, 6 March 2006 (UTC)

[edit] drivers comment

As the text stands it still implies that all the logic for handling say ethernet is part of the driver for the individual card. If this really is the case it needs to be stated explicitly if as i suspect it is not then it needs to be clarified that it is not. Plugwash 22:56, 6 November 2005 (UTC)

As far as Ethernet goes - yes, the drivers can and do directly affect the link layer; an example would be PHY management, or the injection of arbitrary Ethernet packets. DHCP discovery doesn't work too well if your OS isn't able to sniff packets directly at the link level. --moof 01:53, 7 November 2005 (UTC)

[edit] TCP/IP redirection change

I changed the redirection of "TCP/IP" to go to the in-depth article on "Transmission_Control_Protocol". I think that is more appropriate. There is a cross-reference to this article on the "suite" of protocols there. But I feel that if someone is specifically looking for information on TCP, then they should be driven to the specific page, rather than this more general article on all all the protocols.

I've changed the redirect back in my experiance when people talk about tcp/ip they usually reffer to the protocol suite as a whole not TCP specifically. Plugwash 04:34, 5 January 2006 (UTC)

I originally disagreed with you, but then did a little research into original sources for the term "TCP/IP". In particular, RFC 1180 (Jan 1991) states that "TCP/IP" is meant to be inclusive of everything related to TCP and IP. And so, also includes UDP, ARP, ICMP. User:mckoss 5-Jan-06

But what about Trusted Computing Platform/Intellectual Property? --Damian Yerrick (☎) 08:14, 21 January 2006 (UTC)

I wanted to make TCP/IP a link, even if it links back to the same page, because users might wonder why it is redirected here, with another name, not TCP/IP. Logictheo 09:09, 3 October 2006 (UTC)

A section regarding various names of the protocol could be added. Logictheo 08:04, 11 November 2006 (UTC)

[edit] Layers in the Internet Protocol stack

The above captioned section groups a lot of TCP/IP and non TCP/IP protocols in the OSI model. There should be something to identify the TCP/IP protocols from these, especially when the article does not provide a list of TCP/IP protocols anywhere else. RMehra 25 January 2006

[edit] How IP Kills and Eats Competitive Networks

Just wonderig what the value of the section How IP Kills and Eats Competitive Networks is? Written by someone with a personal gripe about the loss of a proprietary protocol?? Seems to me that common standards (such as adopting IP over a proprietary protocol) is a Good Thing (TM), but that might be my POV. In either case, the title and style of that paragraph does not look very professional, or NPOV. Comments? --CodeGeneratR 21:34, 17 February 2006 (UTC)

I agree, it is unprofessional and looks like it was written by someone with a grudge. I think the section should be deleted; it pretty much states the obvious anyway. --RobertStar20 07:32, 20 February 2006 (UTC)

I also saw this and 'wondered' is this a good or a bad thing? It does seem slightly grudge based but is also informative at the same time. I suggest that it be kept in some form, but perhaps with a better, neutral title. "How IP can spread to replace other networks" --Markavian 18:27, 1 March 2006 (UTC)

Agree to keep and reword. I don't know if it's grudge-based, but that'd have to be a looooong grudge to hold it still. Cburnett 18:58, 1 March 2006 (UTC)

Also wondering - had to prevent myself from deleting it wholesale. The title and text seem to be irrelevant, unsupported, and unnecessary. I vote for deleting it...  DavidDouthitt  (Talk) 03:09, 14 March 2006 (UTC)

Remove. It's worth mentioning that the Internet Protocols have replaced other, proprietary protocol suits, but it's not worth elaborating over more than a few senteces. --Gosub 23:32, 21 March 2006 (UTC)

[edit] DoD model

I'd have to read around some more, but is the IP suite/stack based on the DoD model? Cburnett 05:32, 6 March 2006 (UTC)

I'm wondering if its more a case of the DOD model being based on the ip stack.......... Plugwash 01:18, 19 March 2006 (UTC)

[edit] The "stack" has how many layers?

I am confused (a common state for me).

Under the heading, "Layers in the internet protocol suite stack," in the first paragraph, last sentence, it says:

"The stack consists of four layers:"

Under the heading, "OSI model comparison," second paragraph, third sentence, it says:

"The IP stack uses five layer..."

Is the significance in the words, "uses" and "consists"?

I found this to be somewhat confusing.Lord Pumpkin 01:01, 28 April 2006 (UTC)

I understand it better in this way "The IP stack 'is made up of' five layers..."? I put the words in which explain the word "consists". My learning experience declines when I read difficult words like consists. Logictheo 09:02, 4 October 2006 (UTC)

[edit] overlap

the diagram "Sample encapsulation of data within a UDP datagram within an IP packet" overlaps with the list to it's left, on medium sized windows. I suggest moving the diagram downwards, or replacing it with something smaller.

[edit] Capitalization of standard protocols - Transmission Control Protocol vs Transmission control protocol

There is a discussion and survey underway at Talk:Border_gateway_protocol#Requested_move about how standard protocols should be named in wikipedia. E.g. Transmission Control Protocol vs Transmission control protocol or Border Gateway Protocol vs Border gateway protocol . Please contribute if you can. --NealMcB 22:30, 23 May 2006 (UTC)

[edit] A comment about the article

To a reader uneducated about the array of capitalized Alpha abbreviations the article presents very much too much complexity before presenting the basic ideas. The basic idea is to uniformly transmit information in packets from a source to a remote receipient, isn't it? The theory of building a packet of reliable information is incredibly lost deep in the article after a reader wades through quantities of layers and all kinds of specialized abbreviations. The article could be presented for a common reader to understand how internet information is exchanged, instead it has elements of being a highly technical article which would not be useful to a common person. Couldn't the basics of (header information (data information) end of packet) be presented to a reader instead of involving a reader with 4, 5, 6 or 7 data layers? Terryeo 06:09, 26 June 2006 (UTC)

I think that the editors working on this article are trying to avoid redundancy with other articles on networking (notably OSI). If we have too many expository explanations of basic concepts at the beginning of all networking protocol articles, they will be too long. But I agree with you that the links to the basic concepts should be better emphasized in the first few paragraphs so that people unfamiliar with them can read about them first. --Coolcaesar 16:29, 26 June 2006 (UTC)

[edit] TCP/IP a 5 Layer Model?

Guys, great work on this article. I can see that a lot of time has been put in here. I do see where some confusion has entered the picture in regards to the layers of the TCP/IP model. I believe The RFC's define TCP/IP as a 5 layer model 1 - Hardware, 2 - Network Interface, 3 - Internet, 4 - Transport, 5 - Applicaton.

The OSI model was developed after TCP/IP was created this is why TCP/IP doesn't necessarily conform to the OSI Model. (the developement of TCP/IP staretd way back with the very begginigs of the internet itself).

My understanding the four layer model is the DOD (Department of Defense) Model.

I concur. TCP/IP has its own funny model which does not correspond with OSI very well. OSI is used primarily as a teaching tool but then one has to study the actual pre-OSI protocol suite models on their own terms to really understand how they work. --Coolcaesar 21:38, 5 July 2006 (UTC)

Fixed layer models suck for a network as complex and varied as the internet. TCP/IP itself has two layers internet (IP) and transport (TCP,UDP and friends). There is an application above it and a link system below it each of which may have any number of layers. Plugwash 23:01, 5 July 2006 (UTC)

[edit] OSI Model and SSL

SSL does not belong only to the session layer as it is explained in the main article. SSL is also used in the transport layer. SSL uses two protocols: one operates in a lower portion of the session layer and the other at the transport layer.

I believe that it should be explained that different references can place specific protocols at different layers.

For instance, the OSI model wikipedia article reports SSL in the presentation layer because also data encryption is involved at that layer.

SSL is the typical example of OSI multi-layer protocol.

--Rygar81 04:24, 15 July 2006 (UTC)

[edit] Session layer description missing

The article is missing a description of the session layer. Can anyone supply one? Tim Watson 17:25, 29 September 2006 (UTC)

The protocol suite is missing a session-layer protocol. Can anyone supply one? :-)

I.e., the reason is why the article is missing a description of the session layer is that the TCP/IP model doesn't have a session layer; there's no standard session-layer protocol in the Internet protocol suite.

Note that the session layer page says the session layer is typically unused, and indicates that it's mainly used for synchronizing multiple data sequences. However, the OSI model standard (ISO/IEC 7498-1) seems to be speaking of "synchronization" as a function of a single session, and doesn't seem to indicate what sort of "synchronization" is done. The OSI session protocol standard (ISO/IEC 8327-1) doesn't do a much better job of describing what sort of synchronization this is.

In addition, that page has a motley collection of "examples" containing a large number of protocols most of which do things that don't appear to be concerned primarily with the sort of functions that the OSI session layer performs.

So it's not exactly clear to me, for example, what the session layer is - and I'm not sure to whom, if anybody, it is clear. Guy Harris 09:53, 30 October 2006 (UTC)

The session layer corresponds to Telnet in most internet protocols (HTTP, SMTP, FTP, IRC, etc), to my understanding. These protocols use text based commands separated by a new line on top of what can be described as a simplified telnet version. Therefor it is possible to fake a web client, mail client, irc client, etc, by means of telnet. Sometimes a separate pseudo terminal process handles the telnet communication, but normally it is simply a piece of code copied into the application protocol implementation, without a standardized API. Therefor it can not be considered as a separate protocol layer.

The OSI model session layer also corresponds to some functions in the TCP/UDP transport protocols, for example the port numbering.

The session layer deals with the dialog, and may ensure that an answer it associated with correct request, if several outstanding questions may be allowed, i.e. several parallell tasks. There is no standard for this in the Internet as it was in the OSI/X.25 world. In telnet it is up to the operational system or the application. In HTTP this is done by creating a new socket for simultaneous file tranfers.

Perhaps this should be added to the article?

Mange01 10:35, 30 October 2006 (UTC)

How does Telnet correspond to the session layer in the text-based protocols? About the only part of Telnet used is the Network Virtual Terminal character set.

Don't ports in the Internet protocol suite's transport protocols correspond to TSAP's in the OSI transport protocols, so aren't they a transport-layer function? Guy Harris 18:07, 30 October 2006 (UTC)

There is no section in this article about the "session layer" because there is really no such thing in the internet protocol suite, its only brief mention is as part of how people shoehorn TCP/IP into the OSI model. With the TCP/IP everything above TCP or UDP is the responsibility of the application. Plugwash 16:57, 31 October 2006 (UTC)

[edit] Web services model? Do we need an extra layer in the future?

Where are SOAP-over-HTTP and WSDL-over-HTTP? At the application layer or above? Should it be considered as tunnelling/encapsulation, meaning that the order of the layers are changed?

Should we expect a sixth layer in the future in the TCP/IP model, above the application layer, correspodning to presentation layer in the OSI model? That layer would also include MIME, XML, HTML, JPEG, GIF, etc.

Perhaps the TCP/IP model one day will end up as a seven layer model...

Mange01 09:23, 30 October 2006 (UTC)

Perhaps, but, for better or worse, there aren't any "standard" protocols in the Internet protocol suite at that layer - the choice is somewhat ad hoc - so you're more likely to get into arguments about what layer the higher-level protocols fit into. (How, for example, would NFS's layering be described above the transport layer? XDR as the presentation layer? If so, what layer is ONC RPC at?) Guy Harris 09:35, 30 October 2006 (UTC)

Okay. But in the Template:IPstack, there should be a row for "Internet standards above the application layer". I think about MIME and others. Only protocols and other standards that has an RFC should be included there. Or do you think that MIME is not part of the TCP/IP protocol suite? Mange01 10:16, 30 October 2006 (UTC)

It's part of the suite in the sense of being defined by RFCs. Whether it's "above the application layer" is another matter; if the application layer is "whatever is above the transport layer", then it's arguably part of the application layer, but that means that the TCP/IP model doesn't have much to say about protocols above the transport layer. I suspect that, in order to say anything meaningful about protocols above the application layer, you might have to abandon the notion that there is a model with a stack of layers, and, instead, treat different applications as having different layering. With mail transport, for example, you'd have SMTP or SMTP-over-SSL, and then you'd have RFC 822 for the lowest layer of the message format, and then you'd have MIME for messages using it, and then you'd have all the different data formats used for text, images, etc.. (Of course, at that point, you either have to accept, for example, all the variants of Microsoft Word format, or you have to restrict yourself to data formats with public standards of some sort.) For NFS, you'd have the TCP record marking mechanism for NFS-over-TCP, and then ONC RPC, and then NFS - with XDR inside the ONC RPC and NFS layers (it underlies ONC RPC, in that the RPC headers are encoded using XDR, but it also underlies the protocols that run atop ONC RPC). Guy Harris 18:03, 30 October 2006 (UTC)

Right, the layering of protocols above TCP or UDP is dependent on the application and likewise the layering of protocols below IP is dependant on the network type. TCP/IPs big achivement was establishing two standard layers that could sit between a wide variety of applications and a wide variety of interconnected networks. Plugwash 17:05, 31 October 2006 (UTC)

[edit] Please emphasize the five layer model

Most text books have abandoned the old four layer TCP/IP model (and also the OSI model to some extent) in aid for the five layer TCP/IP model. It is time the pictures and text in this article are revised to reflect this. Mange01 09:09, 30 October 2006 (UTC)

[edit] Typical implementation

Can we add something like this?

Normally the application programmes are in charge of layer 5 protocols (the appliction layer), while the layer 3 and 4 protocols are services provided by the operational system processes. Microcontroller firmware in the network adapter typically handle layer 2 issues, supported by a driver software in the operational system. Non-programmable analog and digital electronics are normally in charge of the physical layer, typically using oneapplication specific integrated circuit (ASIC) chipset for each radio 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 exent based on fast non-programmable digital electronics, carrying out layer 3 switching. In modern modems and wireless equipment, the physical layer may partly be implemted usign programmable DSP processors or software radio (soft radio) programmable chipsets, allowing the chip to be reused in several alternative standards and radio interfaces instead of separate circuits for each standard, and facilitating. The Apple Geoport concept was an example of CPU software implementation of the physical layer, making it possible to emulate some modem standards.

Mange01 00:16, 9 November 2006 (UTC)

[edit] RSVP and RTP?

Searching on the Internet and in various text books, I have found that RSVP sometimes is called a network layer protocol, sometimes transport layer (seemes to be most common) and sometimes application layer. What is the truth hear? And what about the RTP protocl?

Mange01 02:13, 15 November 2006 (UTC)

The truth is quite simply that fixed layer count models like OSI do not fit all that well with the way real life networks work. Plugwash 16:10, 15 November 2006 (UTC)