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)