Talk:Internet protocol suite/Archive 2

Archive 1

Archive 2

Archive 3

Which is it, four layers or five?

The article says four. The sidebar says five. Tom NM (talk) 13:13, 25 March 2008 (UTC)

Errors in the 'The five-layer TCP/IP model' box ?

There seem to be some inconsistencies in the right-top box showing the TCP/IP model: is 'IP' supposed to be in the application layer, and why is there a lingering opening bracket ? 19:04, 4 May 2008 (UTC)

History of TCP/IP v4

It is not clear from the article when TCP/IP V4 was complete. From the article:

...a split into TCP v3 and IP v3 in the spring of 1978, and then stability with TCP/IP v4 — the standard protocol still in use on the Internet today.

Is that 1978 or 1979 or even later? It seems that TCP/IP v4 was being used by 1980.

--66.92.218.124 (talk) 02:26, 8 July 2008 (UTC)

Vote: Four and/or five layers in the TCP/IP model template and wiki articles?

Give your vote here. Should the TCP/IP model template have four or five layers? And what is the name of the bottom layer in case of four layers? And is it okay to mention both the four and five layer models in wikipedia articles? Mange01 (talk) 18:17, 17 July 2008 (UTC)

Inaccurate Quote in Subsection Layer Names and Number of Layers

This apparent quote from the RFC is inaccurate: Emphasizing layering as the key driver of architecture is not a feature of the TCP/IP model, but rather of OSI. Much confusion comes from attempts to force OSI-like layering onto an architecture that minimizes their use. The original source RFC does not contain this statement or anything like it. In fact, the OSI model is only mentioned a few times in the RFC and the authors are cautious about NOT drawing an unflattering comparison between the TCP/IP model and the OSI model. I've therefore removed the offending quote and left the reference to the RFC section titles Layering Considered Harmful, which is still germaine to the points being made in this section of the article. Ross Fraser (talk) 01:39, 29 July 2008 (UTC)

OSPF layer position

Someone has misread RFC 2740.

Quote from the rfc, section 1.1. Terminology (page 4):

  Most of the terms used
  both by OSPF and IPv6 have roughly the same meaning (e.g.,
  interfaces). However, there are a few conflicts. IPv6 uses "link"
  similarly to IPv4 OSPF's "subnet" or "network". In this case, we have
  chosen to use IPv6's "link" terminology. "Link" replaces OSPF's
  "subnet" and "network" in most places in this document, although
  OSPF's Network-LSA remains unchanged (and possibly unfortunately, a
  new Link-LSA has also been created).

OSPF is a rounting protocol. It cannot simply 'move' to a lower layer, in any kind of scheme (Internet, OSI, whatever), either logically or in practice.

Just use common sanse people. Routing protocol and routed protocol exist *always* on the same layer! Where IP is, thats where OSPF/IS-IS/RIP is!

IP (routed protocol) is the passive part, OSPF (Routing protocol) is the 'active' part. TOGETHER they make the "Internet" (/network/internetwork) layer!

IPv6 didn't change that.

212.25.76.140 (talk) 11:22, 23 October 2008 (UTC)

Layers aren't physical places to go to, they are just interpretations of network functions. What goes into a layer is just a definition of the layer. OSPF does not belong into the Internet Layer, as the protocol is a link state protocol and only operates on the local link (no matter what the encapsulation scheme is), i.e. it does not reach across routers. A border router between two networks maintains distinct routing maps for each area. But OSPF does not route anything, it's IP that does the routing, OSPF just provides the best information to do so. The protocols in the Internet Layer, as the term implies internetworking, do operate across routers and therefor connect networks into an internet. Kbrose (talk) 14:20, 23 October 2008 (UTC)

More to the point, OSPF runs over IP. It's protocol 0x59 in either IPv4 (as a Protocol Number) or IPv6 (as a Next Header number). The point is, for a strict layering interpretation, it runs over IP. That does not imply it's a layer 4 protocol in any sense -- it's not a transport protocol. It's just a client of the Network layer. However, IS-IS was mentioned above, and while it is, like OSPF, a link-state routing protocol that supports IP, it runs directly over the link layer with no intervening IP header. The layer it runs over doesn't change the fact that it gathers information to support IP routing/forwarding. And finally, some routing protocols operate over TCP (e.g., BGP). They all facilitate the operation of the IP layer (gathering information necessary to support connectionless forwarding of packets based on their destination address) but are independent of the IP layer. If you drew IS-IS as "inside" the IP layer, you'd be wrong...physically it doesn't use IP packets at all. It is, like all other routing protocols, logically part of the IP layer.

Another point: Routing protocols mostly operate between directly connected neighbors, in the sense that they share the same broadcast LAN, point-to-point or point-to-multipoint connection. However, this is not necessarily a requirement: BGP has multi-hop support. OSPF can have "virtual links" between routers that don't share a common subnet. Tmaufer (talk) 19:39, 23 October 2008 (UTC)

So, let me see if I get what you're all saying - OSPF operates above and under the internet layer at the same time?! If you are to separate the 'path facilities' (IP) to the 'path determination' (routing) than you HAVE TO move all routing protocols to the application layer.

Otherwise it is just a logical mess - in this specific case (OSPF): distinguishing between the date (routing table), date collecting/sharing (Hallo, LSA), the date processing (OSPF algorithm), and the use of the date itself (packet forwarding).

ROUTING is the COLLECTION of the above. If you choose to understand/interpret *routing* simply as 'packet forwarding' all routing protocols (or any other process that create/modify the routing table) MUST exist on the application level.

As it is right now, OSPF spans over several layers.

  they are just interpretations of network functions... as the protocol is a link state protocol and     
  only operates on the local link

I have the distinct feeling that that while writing the above that author misunderstood the network function that is routing, and its complexity. In order to route, in the form modern routers (the physical equipment) do, these devices (assuming there is more then one) needs to share their date, so they can, in turn, process it. This is an inherent part of routing protocols!

To put it in other words, "operates on the local link" should be replaced with "SHARE local link information". In order to "operate", OSPF needs local date ("local link" date), actively maintain it (hallo), SHATE IT, and process the sum of collected date. In the simple form: "operates on the local link" ... INFORMATION.

Clarification: you need to distinguish between the mechanism in which information propagate to the scope of information propagation. The mechanism in which information propagate is, in this case, a single hope; the scope in which the information is propagated is not. A single hope propagation mechanism will propagate information to the entire network, one hope at a time.

Sharing information in this manner, single hope propagation, is how routers share information.

Another clarification: the routing/forwarding table is what makes routing, as we know it today, possible. Packet forwarding use it. Routing protocols update it (in one way or another), that is their entire purpose, their sole reason of existence. It is the (missing) link between _IP_ and _routing protocols_.

One way to make this mess clear is to look at the routing (and forwarding) table as the starting point. IP (packet forwarding) is useless without it (with the exception of static forwarding table); routing protocols are useless without it. Routing, as a whole, in its base, is the routing table, and every function or mechanism that has a strong, direct connection to it must exist on the same logical layer.

This is what I tried to communicate in my original post. This point of view may very well look over simplified, but it does seem however, that the implementation specifics of some routing protocols have managed to confuse some people here, to a point that some replies to my OP imply that _path selection_ is done by the _IP_.

This cannot be more wrong! _Path selection_ is determined by the process that updates the routing/forwarding table, which is, in turn, used by the packet forwarding mechanism. The IP standard (RfC 791 and 2460) is, more then anything else, a detailed specification of the IP header structure and content. Not only that, but from the moment a packet is created, only a few fields in the IP header are changed throughout it lifetime, if at all. So the claim that _path selection_ is done by the _IP_, from a logically point of view is just wrong.

OP 77.126.112.104 (talk) 06:15, 24 October 2008 (UTC)

Please let's not label things for the sake of labeling them. Labels sometimes just cause confusion. Routing protocols enable routers to discover each other and exchange information about what they are each connected to and this information, when processed, facilitates packet forwarding. What layer the routing protocol operates at is completely irrelevant (or at most academic). This is even more academic in modern MPLS-based routing topologies that have an underlying structure that is independent of what the routers see at the IP layer. The concepts of path selection and neighbor discovery and routing information sharing are completely generalized from what traditional IP routing would indicate.

Just as ARP is an Ethernet client (as is IPv4) and they work together (IPv4 can't work without ARP, or statically defined IP-to-MAC-address mappings), routing protocols provide information so the IP layer can do its job. Note that IPv6 uses ICMPv6 in lieu of ARP. It's a self-bootstrapping protocol. The job of mapping IPv6 addresses to MAC addresses is still being performed, though now it's happening *inside* the IPv6 layer instead of by a parallel helper protocol.

Tmaufer (talk) 18:56, 24 October 2008 (UTC)

"What layer the routing protocol operates at is completely irrelevant" - No, but I'll meet you half way through, you think routing protocols are layer orthinological, remove them from the layers all together, because OSPF is sure as hell not a 'link' layer protocol.

I don't know what is the general approach that people take when editing entries here but, but I can tall you my approach (I'm not going to edit this entry): better to omit then to mislead.

OP 77.126.112.104 (talk) 20:38, 24 October 2008 (UTC)

Retrofit topic year headers/subpages

25-Jan-2009: I have added subheaders above as "Topics from 2003" (etc.) to emphasize the dates of topics in the talk-page. Older topics might still apply, but using the year headers helps to focus on more current issues as well. The topic-year boundaries were located by searching from bottom for the prior year#. Afterward, I dated/named unsigned comments and moved 2 entries (including "Layers" & "Vandalism...") into date order for 2006 & 2007.
Then I added a box "Talk-page subpages" beside the TOC. -Wikid77 (talk) 16:44, 25 January 2009 (UTC)

Revising intro mid-1980s and freeware

25-Jan-2009: I think the intro should be reworded, as I have begun, to emphasize that the Internet emerged by the mid-1980s and note that the World Wide Web and "graphical" web browser Mosaic were freeware that "followed" the Internet. Too many articles give the impression that Tim Berners-Lee developed the Internet on "a Friday night" (10 years after reality) rather than added HyperCard-style interfaces to the existing Internet. I don't know if people are POV-pushing Berners-Lee as "Mr. Internet" but the sources indicate he created freeware versions 5 years after existing DECnet & HyperCard-type (1987) systems. Creating freeware is typical for many government employees and helps to quickly spread the software to other groups. In fact, creating a freeware encyclopedia could generate over 2 million articles 5 years later ("Wikipedia"!). -Wikid77 (talk) 17:29, 25 January 2009 (UTC)

Tim Berners-Lee developed ENQUIRE about half a decade before HyperCard and is far more similar to HTML, any reference to HyperCard here seems, well, misplaced. I also don't think there needs to be more elaboration on the web browser. If anything, I could see it being cut back rather than expanded. Wrs1864 (talk) 20:31, 25 January 2009 (UTC)

• Creating a design isn't the same level of work as a marketed product, so I don't think comparing existing LANs of 1984 with use of the term "WorldWideWeb" in 1989 is NPOV neutral. The fairest connection is the "World Wide Web deployed in 1992" and even that might be too soon. The LANs were much earlier: DECnet in 1975 (OSI model by 1982), Novell NetWare in 1983, or AppleTalk by 1984. That's why I set the timing as "mid-1980s". -Wikid77 (talk) 11:51, 26 January 2009 (UTC)

Proposed merge of TCP/IP model and Internet Protocol Suite

Please see Talk:TCP/IP model#Proposed merge for discussion. --Abdull (talk) 21:53, 14 December 2009 (UTC)

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)

Tanenbaum updated

In Andrew S. Tanenbaum book, 4th edition, the author chose to explain the TCP/IP suite as an hybrid model with 5 layers:

• Application
• Transport
• Network
• Data Link
• Physical

I like this. In my opinion I would only change the name of the network layer to either internetwork layer as named by Cisco, or internet layer as named by Stallings.

In my opinion internetwork layer reflects more the nature of this layer since packets may need to traverse several networks, possible of different technologies, in order to arrive to destination.

Miguel 201.58.179.157 05:18, 15 January 2007 (UTC)

As long as you take it as a teaching method only, fine. If Tanenbaum had published this in a IETF Standards Track RFC, it would be authoritative. He didn't, and it's not.

No IETF standard uses 4 layers; RFC 1122 specifies four, and no IETF document depends on OSI. Howard C. Berkowitz 18:56, 15 September 2007 (UTC)

I want to add something to the discussion. In my option there 4 layer in the TCP/IP suite as it is.

• Application
• Transport
• Internet
• Network

Actually Network do not need to be a physical network, it can be virtual network, or loopack device, or anything, it can be satelite link, it can be carrier avian. In case of tunneling we can end in something like this:

• Application
• Transport
• IP:Internet
• TunTap device
• OpenVPN:Application
• TCP:Transport
• IP:Internet
• OtherNetwork

Similary modification can be done up. One can for example consider SSL as being beetwen Transport and Application layer!

• Application (i.e. IMAP,HTTP)
• SSL
• TCP:Transport
• IP:Internet
• Network

And as last word we are talking about Internet Suite, which is called TCP/IP. But TCP in it is not enaugh. We have also ICMP, IGMP, UDP, SCTP, IPIP and houndrets others "transport" protocols (which are on the same level as TCP, as they generally talk to IP layer), and also ARP, IGMP, and sometimes others protocols side by side of IP ("Internet" level), as they generally also want something from the Network directly (mostly broadcast something, or change some other aspect of link). I.e. DHCP is strange in this respect as it slightly violate layering. Sometimes routing protocols also goes here and there (but it can be generally be viewed that thay are application protocols, and are only "modifing" routing information available to the IP layer). So there is many interconections. Not to mention for example that most applications (from Application layer), want to know not only the port from TCP stack, but also IP addresses from IP stack. :)

Witek —Preceding unsigned comment added by 87.239.216.23 (talk) 06:24, 6 April 2010 (UTC)

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)

I agree with all the above commenters that say that there is no session layer because the Internet Protocol Suite model never had a session layer. Session layer functions are in the Application layer, but that layer need not be monolithic. If you want to see an IETF protocol with functionality similar to the OSI Session Layer, see http://www.ietf.org/rfc/rfc1833.txt Remote Procedure Call.Howard C. Berkowitz 19:03, 15 September 2007 (UTC)

Session layer does NOT belong to the Internet Protocol Suite! Even Application layer is beyond IPS. Telnet is not in IPS, FTP is not in IPS, HTTP is not in IPS. There is no need to add any such section. —Preceding unsigned comment added by 87.239.216.23 (talk) 06:35, 6 April 2010 (UTC)

The article title is wrong

The vast majority of sources show Internet protocol suite, not Internet Protocol Suite. That is, only Internet should be capitalized. Someone fix the title please. Thanks. --Coolcaesar (talk) 07:45, 9 September 2008 (UTC)

• 26-Jan-2009: Some sources/books do use the same capitalized title ("Internet Protocol Suite") with acronym "IPS" although Microsoft has published the title with lowercase "suite" noting IPv4 and IPv6. By comparison, over 90% of webpages spell "e-mail" as "email" (without the hypen), which is officially wrong, but that's 90% of the time. Hence, the spelling shouldn't depend on the majority usage. I think the capitalized title is fine, but keep the current 2 redirection titles for lowercase "Internet Protocol suite" and "Internet protocol suite" because both are used in the literature as well. -Wikid77 (talk) 11:51, 26 January 2009 (UTC)

Actually, the correct usage is lowercase ("Internet protocol suite"), as consistently used by the late RFC Editor, Jon Postel. See, e.g., RFCs 1160, 1280, 1360, 1500, 1540, 1600, 1720, 1780, etc. Please read some RFCs before making statements with no basis in the published literature. --Coolcaesar (talk) 15:41, 28 June 2010 (UTC)

Isn't Wikipedia Supposed to be for Everyone?

This article reads like a technical journal. I agree that technical detail is good and necessary, but I don't see a good on-ramp for the average reader to get an idea what this subject is about. Landroo (talk) 15:59, 16 March 2009 (UTC)

On a similar note, how about a schematic of how the layers are mapped into the stream of buts transmitted? The information is probably in the article, but worded so abstractly that it's difficult for a non-expert to extract. A blow-by-blow narration/explanation of flow of the TCP/IP stack diagram would be a tremendous help too. Thanks. JKeck (talk) 17:35, 9 July 2009 (UTC)

I am in favor of above. However, making some abstract concepts easy to understand is really difficult. Wiki's materials are concise and wide-ranged compared with RFCs and textbooks, as what's originally required: it's an introduction, not tutorial or manual. Making things simpler is the goal, but space must be left with the authors of related books and documents. --RFClover (talk) 09:47, 14 February 2010 (UTC)

Layers paragraphs 2 and 3 need tidying

At this point in time paras 2 and 3 read :-

"The Internet Protocol Suite, like many protocol suites, is constructed as a set of layers. Each layer solves a set of problems involving the transmission of data. In particular, the layers define the operational scope of the protocols within.

Often a component of a layer provides a well-defined service to the upper layer protocols and may be using services from the lower layers. Upper layers are logically closer to the user and deal with more abstract data, relying on lower layer protocols to translate data into forms that can eventually be physically transmitted."

1. What is "particular" about the 3rd sentence? (Something "particular" be directing us to focus on a specific point? It doesn't.)
2. "operational scope" seems to be a meaningless phrase that could apply be applied to a say a step in frying eggs.
3. I would have though every component of a layer *must* be well-defined for the protocol to work

So in summary, for such an important umbrella topic, these need to be reworked somehow. Watch this space! martyvis (talk) 13:06, 26 December 2010 (UTC)

You removed the wrong stuff from the lede. It is the concept of scope that governs TCP/IP layering, and not the 'well-defined service' model of providing and receiving upper/lower level functions as is the case in OSI networking. In TCP/IP there are numerous 'violations' of such ideas and the notion of strict layering by services has been dispelled by the IETF. Kbrose (talk) 13:28, 31 December 2010 (UTC)

OK, if "scope" is important then we need to define it more. The other detail on the layers is good, but I am wondering whether this is too much for the introductory section. If this information isn't in "Layer in the Internet Protocol Suite" already we should move it there, and try to pare down what you have to about a third. martyvis (talk) 13:45, 31 December 2010 (UTC)