Talk:Internet protocol suite

Layers

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

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

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

— Preceding unsigned comment added by 64.247.79.58 (talk • contribs) 03:48, 8 June 2003 (UTC)[reply]

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)[reply]

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/enwiki/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)

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". — Preceding unsigned comment added by 172.208.215.173 (talk • contribs) 05:43, 27 December 2003 (UTC)[reply]

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)[reply]

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)

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)

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.) — Preceding unsigned comment added by 65.88.178.10 (talk • contribs) 19:30, 4 November 2004 (UTC)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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... — Preceding unsigned comment added by 157.127.124.134 (talk • contribs) 12:51, 26 August 2005 (UTC)[reply]

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? — Preceding unsigned comment added by 47.153.233.240 (talk • contribs) 05:15, 29 August 2005 (UTC)[reply]

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

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)}[reply]

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)[reply]

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)[reply]

I think it's wrong.

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]