Talk:Internet protocol suite/Archive 1

message: 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. ), 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)
thread_title:  OSI was practical 

message: Guys, can anyone tell me how the  tag works, where it is defined and how to edit it? Thanks. Sridev 13:48, 25 Sep 2004 (UTC)
replies: text: It's at :Template:IPstack. The way it works is that when the page-rendering code reads the , 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)

text: If anyone would like to help me tweak this article, I would appreciate it.
Wisepiglet 05:03, 7 December 2006 (UTC)
thread_title:  IPstack 

message: (This seems like a logical place, but I'm not quite sure where it should be...)
There is a stub article, Rwin, in which I added some things.
I am recommending that a link be created from this article to the Rwin stub, even if the link does not fit with this article. The reason being is, it was quite difficult to navigate to the Rwin article without seraching. For someone who is looking for information about how to tweak their TCP/IP settings but does not know to search for the term 'Rwin' etc. to learn more, they might be kind of lost. Either way, I tried to find the information. I did find it after a while, but I already knew about the term 'rwin'.
I also created a redirect from Tcp receive window and TCP Receive Window to Rwin because that was what I was using for my search terms. I could only find the rwin article by using 'rwin' as my search term.
If anyone here is considered to be a network guru, the Rwin article is looking for an expert.
Is there an article in Wikipedia which talks about tweaking the stack? TCP/IP Tweaks maybe? I have yet to find one. -- After much reading and searching, I finally found the article that I was seeking at first, TCP tuning. However, it didn't have the information that I added to Rwin. I'll let someone who actually knows where things are supposed to be, arrange the information accordingly.
I strongly suggest that a link about tuning/tweaking and rwin as a sub-heading, be placed in the table of contents of the article page (for this article).
Somewhat related:
:If anyone would like to help me tweak this article, I would appreciate it.
Wisepiglet 05:03, 7 December 2006 (UTC)
thread_title: Rwin

message: 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)
thread_title:  Readings typo 

message: 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)
thread_title:  Some Clarification 

message: 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)
replies: text: This is an encyclopaedia, not a "how to" manual. Noel (talk) 12:58, 22 September 2005 (UTC)
replies: text:  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)
thread_title:  It would be great... 

message: 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)
replies: text: 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)
thread_title:  List of common ports 

message: 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)
replies: text: 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)
replies: text:  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)
thread_title:  Take OSI Out (of the top area) 

message: 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)
replies: text: 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)
thread_title:  drivers comment 

message: 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)
replies: text: 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)

text: 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)
replies: text: 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)

text: 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... <SPAN STYLE="font-family:monospace; color:#006666; background-color:#ffff99; border-color:#ff0000; border-width:1px; border-style:solid; "> DavidDouthitt </SPAN> (Talk) 03:09, 14 March 2006 (UTC)

text: 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)
thread_title:  How IP Kills and Eats Competitive Networks 

message: 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)
replies: text: 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)
thread_title:  DoD model 

message: 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)
replies: text: 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)
thread_title:  The "stack" has how many layers? 

message: 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)
thread_title:  Capitalization of standard protocols - [[Transmission Control Protocol]] vs [[Transmission control protocol]] 

message: 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)
replies: text: 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)
thread_title:  A comment about the article 

message: 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. -[unsigned], June/July 2006
: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)
replies: text: 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)
replies: text: TCP/IP, at least RFC1122 defining its layers, is not pre-OSI. RFC 1122 was written after the OSI model was published. For the nth time, TCP/IP does not, did not, and will not follow the OSI model and efforts to force it to do so are futile. In the protocol world, OSI has been assimilated. Howard C. Berkowitz 03:04, 16 September 2007 (UTC)
thread_title:  TCP/IP a 5 Layer Model? 

message: 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)
thread_title:  OSI Model and SSL 

message: 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 (July 2006)
: There are a lot of inaccuracies in the comments above.  To the extent that they relate to the commercial failure of OSI, that doesn't matter much.  To the extent they relate to creating an accurate technical description, they do.  For example, misguided business practices of telco's have no connection to the efficiency of OSI.  An OSI network, run by TCP/IP business practices, would look quite similar.  In fact, this is not surprising, considering that quite a lot of TCP/IP comes from OSI, or shares ancestry with OSI.  Paul Koning 21:46, 2 July 2007 (UTC)
thread_title:  Layers 

message: 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)
replies: text: 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)
replies: text:  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)
replies: text: 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)
replies: text: 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)
thread_title:  Web services model? Do we need an extra layer in the future? 

message: 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)
replies: text: Correct textbooks have not, and neither has the IETF. Are you suggesting that textbooks are more authoritative than the standards? Which is more appropriate for an encyclopedia? Howard C. Berkowitz 03:02, 16 September 2007 (UTC)
thread_title:  Please emphasize the five layer model 

message: 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)
thread_title:  Typical implementation 

message: 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)
replies: text: 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)
thread_title:  RSVP and RTP? 

message: I suggest merging the article Internet Protocols into this article and let that other entry forward here. -- dbu, 29 november 2006
:I agree (and have added appropriate  and  tags to the articles in question). Guy Harris 15:46, 29 November 2006 (UTC)
replies: text: I agree. I see no reason not to do this. Reeves87gmailcom 19:34, 2 December 2006 (UTC)

text: I agree too.  Internet protocol suite is the more widely accepted term for the whole set of protocols that are used together with TCP/IP.--Coolcaesar 23:45, 2 December 2006 (UTC)

text: No Nasz 10:36, 10 January 2007 (UTC)
thread_title:  Merge 

message: The section called Layers in the Internet protocol suite stack seems
to be in contradiction with the box: The five layer TCP/IP model.
Beside this, in the final sentence of the same section I cannot understand how
in a stack with 4 layers, when one of them is splitted in two,
that results in a 7 layer stack.  Isn't it 6?
--201.58.179.157 05:35, 15 January 2007 (UTC)
thread_title:  Seems contradictory 

message: The IPstack template seems to have been vandalised with a link to 'ANUS' inserted at the start. Does anyone know how to revert that particular bit of spuriousness? —The preceding unsigned comment was added by 217.33.127.210 (talk) 10:33, 22 January 2007 (UTC)
thread_title:  Vandalism - ANUS 

message: I believe I have gotten most of the RFC references into the desired cite web format, although there is something quirky about RFC 1149, for which I can't get the URL to stop showing up in the references.
May I make several clarifications, from quite a bit of direct experience in the development of OSI and IETF protocols and architecture?  First, it never was the intention of the IETF to be compliant with the OSI Reference Model. As far as there being a number of layers, it is not seven, not three, but four. Four is the number of the layers, as specified in RFC 1122. Don't argue with me, argue with the Killer Rabbit, and try holding the Holy Hand Grenade of Antioch for a count of 5 or 7.
The IETF, however, has long recognized that strict layering was once useful conceptually, has limited use in teaching to beginners, but no IETF working group in which I've ever participated ever spent more than a few seconds on layer numbers -- other than to say we don't do layer numbers. When getting into recursive layering with such things as stacked MPLS labels, IP in IP, or real-world implementations of things like TCP in IP in PPP in UDP in IP in 802.2/802.3 frames over ATM LAN emulation, layer numbers simply don't work.
For those unconvinced that seven layers aren't struggling to get out, not even ISO insists there are seven layers. Yes, the original OSI Reference Model in ISO document 7498 had seven layers, but the Internal Organization of the Network Layer, in ISO 8648, split the network layer into three sublayers. The lowest of those sublayers blurs when dealing with pre-OSI protocols such the X.25 packet layer protocol, and also with the IEEE Project 802 split of the Data Link Layer into LLC and MAC. LLC, with the SNAP extension, is also used in "layer 2" protocols such as Frame Relay.
No authoritative source anywhere suggests this model has five layers. That appears in a few textbooks, and is flatly wrong. No major vendor describes it as having five layers; I was first a Cisco Certified Instructor in 1991, contributed to many Cisco courses, and was a router designer for Nortel from 1999-2001. I have never seen anyone suggest five layers other than Wikipedia and a few textbooks. If you want to fail a certification exam from any vendor, say this model has five layers. 
Can we all just get along now (and could someone figure out what's wrong with the RFC 1149 cite so that it keeps embedding the URL in the footnote)? Howard C. Berkowitz (talk) 21:42, 20 November 2007 (UTC)
thread_title:  Cat Herding Nearly Complete 

message: I think the link we had pointing to http://www.learn-networking.com/tcp-ip/introduction-to-tcp-ip-protocol-suite.php was very valuable to have. It was taken out by a microsoft address, with no reason provided. Who thinks it should be reincluded? It has a good explanation of TCP from the very beginning- great for newbs.
Zac439 (talk) 20:41, 20 November 2007 (UTC)
replies: text: It's been a couple of days. If no one has any objection, I'm going to re-include the link. Zac439 (talk) 11:41, 22 November 2007 (UTC)
replies: text: I don't see anything wrong with it.  I just added it back to the article. — EagleOne\Talk 22:09, 22 November 2007 (UTC)
replies: text: Thanks for the feedback EagleOne, and happy thanksgiving! - Zac439 (talk) 18:23, 22 November 2007 (UTC)
thread_title:  Reverted External Link Is Valuable to Have