Template talk:IPstack

From Wikipedia, the free encyclopedia

"Bus" network topology This article is part of WikiProject Computer networking, an attempt to build a comprehensive and detailed guide to Computer networking on Wikipedia. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion.
Computer networking Portal
Computer networking To-do:


Contents

[edit] Confusing?

I am unconvinced that this diagram makes any sense. Its organization as a table belies the fact that the column information is strictly meaningless. FTP and SMTP are not bound to any particular version of IP, nor is IRC any more bound to Wi-Fi than UDP is to a token ring. -Peter Farago

If you read the comments at the end of Talk:Internet_protocol_suite#Confusing layers, you'll find the rationale behind this better explained. (Hmm, maybe I should put that text in OSI model....) Noel 12:33, 18 Sep 2004 (UTC)
Welcome to 2005. The ISO/OSI model may have made sense in 1990, but it's not applicable to the TCP/IP protocol suit. Example: IPv6-over-UDP.
Hah. It didn't make sense in 1980, let along 1990. Noel (talk) 17:48, 14 September 2005 (UTC)
You mispelt suite ha ha!!!!
You misspelled misspelled. Or was that ironic? I thought maybe, or maybe not, considering the four idiotic exclamation points. Uh...ha? -D.D. —Preceding unsigned comment added by 76.172.145.248 (talk) 20:53, 24 March 2008 (UTC)

[edit] Colors

I just changed the colors in the table. They were way too dark in my browser (especially the blue). I suggest we not go below "CC" for any of the 3 color components in bgcolor="#RRGGBB". - dcljr 08:46, 31 Jul 2004 (UTC)

[edit] Confusing protocols

I removed ICMP in part because it was at the wrong layer, but mostly since it is such a confusing case. See Talk:Internet protocol suite for more. It seemed better not to include any of these confusing cases (like ICMP or any routing protocol) in the diagram (where there is of course no room to explain). Noel 13:08, 14 Sep 2004 (UTC)

Concur about DHCP, although if I had to put it at a layer, it too would go at the network/internetwork layer. I'm wary of adding SNMP, because that might be confusing too. Noel 12:33, 18 Sep 2004 (UTC)

[edit] ARP

(copied from Talk:IPv6 -- JTN)

Wise to have someone second this before changing it, but in the table in the top right which lists protocols, ARP is given in the Network Layer. This is incorrect - ARP does not use IP datagrams, it uses Ethernet frames, and is part of the Data Link Layer. Toby Douglass 16:33, May 26, 2005 (UTC)

ARP is a bridge (sic) function that indeed uses ethernet frames to translate IP(v4) addresses to MAC addresses. But it is not a data link layer protocol but works on top of the data link layer. W. Richard Stevens however does classify then as data link layer. I guess the template should be fixed thus. They are a bit odd tho, as is ICMP. Spearhead 21:15, 26 May 2005 (UTC)
In a properly designed model, we'd not only have a "network" layer above the "data link layer", but an "internetwork" layer above that, before getting to "transport". In that model, ARP would be assigned to the "network" layer (as would things like X.25, various MAC functions, etc).
People keep doing stupid things like putting ARP in the "data link layer" because they are trying to cram 10 pounds of you-know-what into a 3 pound sack. Noel (talk) 17:48, 14 September 2005 (UTC)

[edit] DHCP

129.67.23.117 has placed DHCP in the network layer. I'm not convinced, given that it runs on top of the UDP transport protocol. -- JTN 12:58, 2005 Jun 2 (UTC)

I concur. DHCP definitely does not belong in the network layer, due, if nothing else, to the reason mentioned above. — Itai (f&t) 18:40, 4 Jun 2005 (UTC)
Actually, as long as Internet Protocol is in the "network" layer (the 7-layer model is a piece of cr-you-know-what), DHCP does belong there, because it's part of the "internetwork layer" functionality, along with ICMP, routing protocols, etc. Noel (talk) 17:48, 14 September 2005 (UTC)

[edit] Physical layer

Why are only largely oblsoete serial standards, RS-232, EIA-422, RS-449, EIA-485 mentioned? I'd drop all but one and add 10Base-T etc. --agr 1 July 2005 03:39 (UTC)

RS 232 does not belong in the template, it has as much relevance to the "stack" as IEC 320 has - after all, every piece of hardware needs a power plug, right? --Wtshymanski 14:20, 7 November 2005 (UTC)
Perhaps many of these are obsolete for end users in countries with broadband, but they are decidedly not obsolete in a number of embedded/dedicated computer systems (e.g., NMEA 0183, a variant on RS-423, is the basic protocol between shipboard sensors and computers), and in third world countries that still use modems. Howard C. Berkowitz (talk) 00:00, 17 November 2007 (UTC)

[edit] Major change

I am not sure what is the point of this template. I removed some unrelated protocols. For example, when using HTTP, you don't have to think about IPv4 or IPv6. Those belong to the different universes. -- Taku 11:29, July 31, 2005 (UTC)

This is to illustrate network layers and provide links between them. See OSI Model. The protocols you listed are all on the application layer. Reverting. --ChrisRuvolo (t) 16:59, 2 August 2005 (UTC)
Not different universes, but different protocol layers. This is exactly the point of this template. --Betterworld 17:42, 2 August 2005 (UTC)
By different universes, I wanted to mean different protocol layers. I think each article about a protocol has to talk about the protocol first and foremost not layers. Of course, it is important to note how those protocols can be implemented but that can be done by writing a text not by putting a table. -- Taku 22:52, August 2, 2005 (UTC)
First, the template is named "IPstack" not "ApplicationProtocols". Secondly, a box showing protocols at various layers is useful and informative: a reader can see the larger picture and context for the protocol. A box showing only a set of unrelated application protocols (as you would have it) is not very useful because you gain little information about the protocol in question. Please don't revert again until you've gained some consensus for your change. — Matt Crypto 23:03, 2 August 2005 (UTC)
I am not saying that the table makes no sense. What I want to try to say is that it makes little sense to put the table to every single article about a protocol; I have no problem having a table like this in one place. In wikipedia a box either eases the navigation and gives a summary not provides the big picture. Besides, I don't think the box helps understand about a protocol in question. As I said above, when you want to learn about HTTP, it is not necessary to know about protocols at other layers. That's the whole point of layering. Because the width of a template is too long, at least can we agree on moving the template to the bottom of an article? -- Taku 23:45, August 2, 2005 (UTC)

[edit] Choice of layers

Right, I'm no expert on this, but there seems to be a lot of contention about the way the layers are labelled in this template. The main issue seems to be that the OSI model, as it currently uses, doesn't really map well to the TCP/IP stack; individual issues we need to agree on include:

  • Does it make sense to split this template at all? The protocols involved can often be used in all sorts of odd combinations (one user pointed out that "You can do ICMP-over-IP-over-HTTPS-over-TCP-over-IP-over-IPv6-over-UDP-over-IP for example"), but does that negate the usefulness of this as an "overview" and navigational aid? And if we don't have layers, would that mean deleting the template, having removed its only useful attribute?
    • A logged-out user writes: While that ICMP-over-IP-over-HTTPS... is a bit overkill, there are some "real world" examples I know of:
      • icmpchat - Custom IM protocol over ICMP over IP
      • Teredo - IPv6 tunneling that works via NATs; IPv6 over UDP over IP
  • Is there a better set of layers we could use? PioM has been suggesting one in which there is an "Internetwork layer" instead of a "Network layer", with a merged "Network access layer" beneath it, and cites Cisco as his source for this. If we do go with a different layering model, we should do so consistently, and link to descriptions of or appropriate to that layering model. The Internet protocol suite article should also be updated to refer to said model, and discuss protocols with reference to it.

So, what do people think? - IMSoP 21:07, 19 August 2005 (UTC)

I'm studing telecommunication (last year) we were teached that in OSI model there are 7 layers but in TCP/IP stack there are 4 layers.
I have also certify at CISCO CCNA and there was also 4 layers in TCP/IP stack: 1. Network Access layer 2. Internet(called also Internetwork) layer 3. Transport layer 4. Application layer. -PioM EN DE PL 21:25, 19 August 2005 (UTC)
1. Network Access layer (agregates functionality of 1st, 2nd, and some 3th from OSI)
2. Internetwork layer (agregates funct. of 3th OSI layer)
3. Transport layer (agregates funct. of 4th, and some funct. from 5th. session layer)
4. Application layer (agregates some funct. of 5th layer, 6th and 7th)
I will be accessible since Monday. -PioM EN DE PL 21:30, 19 August 2005 (UTC)
Hm; looking back at Internet protocol suite, I see this assertion:
"There is some discussion about how to map the TCP/IP model onto the OSI model. Since the TCP/IP and OSI protocol suites do not match precisely, there is no one correct answer."
The diagram there actually shows 5 layers, although you have altered this to label two of them "1"; the text isn't entirely clear which version is being referred to.
Now, I'm not saying you're wrong - this really isn't my field of expertise, though I am a computer scientist - but it's not clear to me that this arrangement of layers is as well defined as the OSI model. If there is a standard Cisco definition, though, that is probably worth describing, and labelling as such, with references.
Hm, I'm beginning to wish I'd started this thread at Talk:Internet protocol suite instead... - IMSoP 21:48, 19 August 2005 (UTC)

I'd love to discard the ISO 7-layer model, as it is totally useless and confusing for describing everything below transports (such as TCP) and above framing (e.g. HDLC). Cramming X.25, MAC, ARP, IP, ICMP, etc all into one layer is worse than useless. However, the model is widely known, and for some reason (terminal brain damage?) people keep using it, so we at least have to talk about it.

However, we don't have to use it in our articles. It just confuses the heck out of naive readers. If someone can locate a better model we can cite (heck, I could whip up one, but that won't do us much good), that would be perfect. Basically, it just needs to be the ISO model with one extra layer ("internetwork").

I don't like the Cisco model for several reasons. For one, it's a company proprietary thing, and much as Cisco propaganda would have us believe otherwise, there's more to networking than Cisco. For another, it's too simple: cramming everything under "internetworking" into a single layer makes it harder to explain all sort of things. (E.g. how MPLS relates to everything else, how the various 802.* things can be bridged together because they all use a common packet format/address-space across different technologies, etc.) Noel (talk) 17:48, 14 September 2005 (UTC)

Here's my $0.02... I think the problem is that you're trying to show structure in the IPstack template, when it is really just supposed to be a bunch of links to the individual articles. To make it right would make it huge and over-complex. So make it simpler. I guess it still needs some layering, but chuck out the ISO terminology (irrelevant) -- in fact don't label the rows at all, just use dividers (kind of like Template:History_of_China). OTOH, I think a real diagram showing the true structure -- ie. what runs over what -- would be useful in the actual "IP Suite" page. -- Johantheghost 22:11, 16 September 2005 (UTC)
All of them sound good to me! Do you want to do the diagram showing what runs on top of what, or shall I? (Reply at my talk page.) Noel (talk) 23:26, 19 September 2005 (UTC)
I think there needs to be some kind of notation in here for people taking Cisco tests that by Cisco standards there are only 4 layers. It may be proprietary, but it wouldn't be good for someone to start getting confused. —The preceding unsigned comment was added by Phren79 (talk • contribs) 02:31, 16 January 2007 (UTC).

[edit] Template overuse

Why is the IPstack template placed on so many other pages? It makes sense to put it on pages about IP related protocols such as TCP/UDP/etc. but not on the physical layer pages such as Ethernet and Token Ring. If someone is looking for information on Ethernet or Token Ring they probably don't want to know about the IP stack -- just one of many protocols which can run over the medium they're reading about. Mention of the IP stack in a "see also" section should be sufficient.

Is anyone against removing the IPstack template from Ethernet & Token Ring's pages (and others)? Sfisher 00:39, September 8, 2005 (UTC)

So what if people don't expect stuff to show up they don't want to see? Are we going to hide the truth , just because people don't want to know about it? This is an encyclopedia. Logictheo 18:48, 20 November 2006 (UTC)
I just visited the Ethernet page in order to learn about the Ethernet, and I found the IPstack template helpful.Rouencpucelle

Navboxes like this one are just a bad idea altogether. Navboxes work in very limited cases, where one has a set of tightly related articles where readers of any one of the articles are likely to want to review the others. That is not the case here. I have removed this navbox from Optical fiber.--Srleffler 04:01, 13 November 2007 (UTC)

[edit] Websphere MQ

I think Websphere MQ is not so frequently used as to belong on this list. (There are some other protocols which I would like to see added to the list - XMPP and Whois, for instance - but as this really is a matter of personal preferences, it is probably best if we stuck to a representative few.) — Itai (f&t) 18:51, 21 September 2005 (UTC)

  • I agree. There's too many application levels protocols listed that really don't define the internet: IRC, NNTP, SIP, BitTorrent could be axed as well. Also, the transport level is getting burdensome. Is every research protocol going to be listed? Dols 21:08, 24 September 2005 (UTC)

[edit] Combine Data Link and Physical layers

I think the Data Link and Physical layers should be combined on this template. I tried, calling it the Link layer, but the change was reverted so I'll explain my reasoning. The comment on the revert was "ethernet doesn't run over thin air". True enough. But what Ethernet or any other link "runs over" is not part of the IP stack. All IP (v4 or v6) cares about is that sending a packet over a link will get it to the recipient IP stack; whether the links sends it over thin air (Wi-Fi), some type of cable (like Ethernet), or recursively calls the IP stack (like a VPN) is irrelevant. Important, certainly. But this isn't the OSI model; IP doesn't have separate Data Link and Physical layers.

There is no real standard term for the layer below IP. My preference is Link, which is what IPv6 calls it. An older term is Network Access (it actually predates IPv4); I don't like it as well, but would accept it if there are objections to Link. --Rick Sidwell 02:11, 10 November 2005 (UTC)

By that logic it should be removed entirely. At this point, I disagree with the merge. I'll let some others chime in though. --ChrisRuvolo (t) 02:52, 10 November 2005 (UTC)

[edit] Encapsulation

Recently, an anonymous user has added a large number of encapsulation protocols to the template. The list was too extensive, so I have removed it. I am uncertain if we need it at all or if it is indeed relevant. --huwr 23:41, 3 January 2006 (UTC)

[edit] Spam

I've used this infobox as bad example in an infoboxes considered harmful discussion below WP:LEAD. -- Omniplex 23:26, 7 April 2006 (UTC)

[edit] Middleware/Infrastructure for DNS and DHCP, Border Gateway Protocol (BGP) etc.?

Any objection to adding the crucial BGP to the stack template? --NealMcB 22:32, 23 May 2006 (UTC)

This diagram is often used less as a stack reference and more as a list of important protocols. Having a section, perhaps titled "Middleware" or "Infrastructure" might be one place to put stuff like BGP, DHCP, and DNS, for that matter.... --NealMcB 04:43, 28 May 2006 (UTC)

Not sure if BGP is in the right place here as it actually runs on top of TCP(port 179) and should probably be reflected as such. Also what about OSPF, which is IP Protocol Type 89 and should be in there.Sstgfraser 22:00, 18 December 2006 (UTC)
Every one of these is Layer 3 Management, according to the ISO Internal Organization of the Network Layer document. As a participant in the IETF working groups for BGP, ISIS, and IETF, I can say that no one there discusses layering, other than to say that it is the payload, not the encapsulation, that is relevant. BGP and RIP are encapsulated in transport, OSPF/IGRP/EIGRP are internal network layer encapsulation just like IGMP and ICMP, and ISIS is data link encapsulated. Howard C. Berkowitz 09:55, 16 November 2007 (UTC)
First: I noticed someone removed DNS and DHCP from the IP stack, but these are part of the IP stack application layer in the literature. Show me a good reference, and we can discuss it. may Is really DHCP and DNS middleware? Secondly: I don't understand the above. Okay you probably mean that DHCP are machine-to-machine communication application protocols protocols rather than human-to-machine communication, but I thought middleware was about CORBA, RPC, XML, WSDF, etc, i.e. generic distributed systems rather than specific applications. Secondly: Why invent an IPstack that differs from the literature? MIddleware is part of the application layer in the computer engineering tradition. Mange01 22:22, 18 December 2006 (UTC)
Middleware is not a concept used in the IETF, IEEE, or ISO literature. DHCP is considered a management protocol for the network layer, and DNS doesn't fit neatly, especially DNS dynamically linked to DHCP or the IP Control Protocol of PPP. Howard C. Berkowitz 09:55, 16 November 2007 (UTC)
Routing protocols are part of the network layer. Using some OSI management terminology, they are layer management as opposed to application protocols, but, from experience in the IETF, no one in the Routing Area is particularly concerned with coercing them into OSI layering. Hcberkowitz 21:44, 17 May 2007 (UTC)

[edit] Bittorrent?

Why is BitTorrent on this template? It isn't covered by an RFC, like most of the others. -- Mikeblas 01:18, 5 August 2006 (UTC)

I have removed it. Only non-proprietary standards should be included. At the network layer and above this corresponds to RFC:s. At the physical layer and data link layer there are no RFC:s, but IEEE standards, ETSI standards, ANSI standards, etc, should be okay. Mange01 16:34, 6 November 2006 (UTC)

[edit] New navigation for network related topics?

While surfing on wikipedia i came accross several articles on religions such as Christianity and Islam. As you can see, the enormous amounts of pages covering these topics are neatly bundled using the navigation on the right. At the moment we have the IPstack menu for network related topics, but i thought i'd kick it up a notch. BAM! Check out my alternative menu Template:Networks (work in progress) based on the OSI-model. frankly, i don't give a shit if we use tcp/ip or osi, as long as we don't mix those two up in articles which can be quite confusing. discussion is also possible at Template_talk:Networks --Vincent de Ruijter 05:05, 15 October 2006 (UTC)

[edit] Five layer model

The IPstack template should be modified to the more modern five layer model. Most text books have abandoned the old four layer TCP/IP model (and also the OSI model to some extent). Anyone? Mange01 08:55, 30 October 2006 (UTC)

I have now added the physical layer. Mange01 16:32, 6 November 2006 (UTC)

What means under "old four layer TCP/IP model"? TCP/IP stack is DoDs implementation of OSI, so there must be four layers - Physical, Internet, Transport, Application. NTllect 06:29, 20 February 2007 (UTC)

The five layer model is not "more modern" in the sense of appearing in any primary source or major vendor source. It is in a few textbooks. Howard C. Berkowitz 09:55, 16 November 2007 (UTC)

[edit] Internet protocols above the application layer

I suggest that there should be a row for "Internet standards above the application layer". I think about MIME, XML, SOAP, WSDL, etc. 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? See also the discussion under Talk:Internet_protocol_suite#Web_services_model.3F_Do_we_need_an_extra_layer_in_the_future.3F Mange01 10:20, 30 October 2006 (UTC)

I agree these are above the application layer, but not that they are of the same kind. MIME, XML, and HTML are transfer syntaxes while SOAP is an application programming interface and service definition. Hcberkowitz 21:45, 17 May 2007 (UTC)

[edit] Encryption Layer

How about an encryption layer between the transport layer and the application layer? For example, secure web pages use SSL between TCP and HTTP. —The preceding unsigned comment was added by 84.104.229.104 (talk) 19:09, 24 December 2006 (UTC).

The layers are not for us to decide - there is a standard four-layer Internet stack model (detailed at Internet protocol suite#Layers in the Internet protocol suite stack), and a semi-standard five-layer model, drawing on the older OSI model, in which the network access layer is split into its OSI component layers. The OSI model, by the way, has a layer which takes care of encryption - the presentation layer. — Itai (talk) 20:10, 24 December 2006 (UTC)
Again, IETF didn't concern itself with strict layering because it doesn't use the concept. Consider, however, just IPSec: the transport mode is tunneled between end hosts, while the tunnel mode is stuck on by a security gateway middlebox that breaks a basic layering model. The "3-dimensional" ATM model, which adds a dimension of user, signaling, and management to the protocol choices considers this to some extent. Howard C. Berkowitz 09:55, 16 November 2007 (UTC)

[edit] Diagram is completely broken, since transport layer is misssing

It seems to me that the diagram us broken. The important transport layer (layer 3) with the UDP and TCP protocols are missing. This has to be corrected, but in my opionion, all layers have to be rearranged. (a common model is that layers 1 (physical) and 2 (logic link) do not belong to the TCP/IP protocol family itsel, layer 3 is IP, layer 4 are the transport protocols (UDP, TCP, with some reason ICMP) and the application protocols (TELNET, FTP) are above layer 4 (layer 5 is you want). However, this interpretation reflects the OSI-Model, other models are possbile. But never ever leave out the transport layer! --87.181.51.194 06:12, 23 January 2007 (UTC)

[edit] Six layers ?!

While I can understand the discussions around 4 or 5 layers, I truly don't see the argument behind six layers ! And the explanation "I am going to add one more layer" is not very enlightening... Any clues ? I would revert, but I'm maybe missing something here...

Self-reply: given the contribution coming from the person who passed changed the 5 to a 6, I think I can safely say that this was just some fooling around... Reverting to 5 --15:00, 5 April 2007 (UTC)

[edit] Layer pages

The layer pages are very confusing. If I click on a link from the TCP/IP info box it goes to page with an OSI box on the right, sometimes there is a TCP/IP box under it but not always. While browsing through I ended up clicking OSI links by accident when I was trying to read up on TCP/IP. Needs to be clarified for those that are new to the subject. --AGruntsJaggon 16:42, 7 May 2007 (UTC)

[edit] layers all wrong

the way to get the layers right is as follows. If you are considering all protocols listed at layer N, you should be able to remove all layers above N, and the layer N protocols should be unaffected (i.e. still be able to function). For instance, Ethernet does not depend on IP. Take away IP, ethernet still works (you can still use IPX, Appletalk etc). Take away Ethernet however, and IP won't work.

There are many listed cases that break this rule.

Layer 2: PPTP depends on TCP and GRE, which both depend on IP. So, must be layer 5. Take away IP, and PPTP won't work. L2TP depends on IP Layer 3: IGMP, ICMP, RSVP, BGP, OSPF, IPsec all depend on IP, so must be layer 4. RIP depends on UDP which depends on IP, so must be layer 5

Layer 5: MIME is not a protocol, it is a data format

Add Token Ring to layer 2.

Tunnelling protocols don't really fit anywhere. PPTP, IPSec for instance. Sure, you run IP over them, but it's another copy of IP. PPTP won't work without IP underneath it, so the dependency is clear.

Actually I think the model is wrong, since it does not consider a distinction between transport and management. Strictly speaking ICMP, IGMP, OSPF, BGP etc are infrastructure management protocols, they aren't used to transport data for higher level protocols.

e.g:

The 5 layer TCP/IP model
5. Application layer
HTTP, SMTP, POP3, IMAP, FTP, PPTP, SIP, SNMP, RPC		 Management
DHCP, RIP, OSPF, BGP

ICMP, IGMP, RSVP
4. Transport layer
TCP, UDP, GRE, ESP, IPIP, L2TP
3. Internet layer
IP, ARP, RARP
2. Data link layer
Ethernet, Token Ring, PPP, Frame Relay etc
1. Physical layer
Ethernet Physical layer etc


my 2c. —The preceding unsigned comment was added by 125.237.240.118 (talk • contribs) 21 June 2007 (UTC).

A few comments:
* Your suggestion is interesting, but is it supported in established literature?
Yes. See my comments below for specific citations. See RFC 1122, RFC 1958 and RFC 3426 for the IETF view, which establishes four layers in RFC 1122, but then, in the latter two architectural RFCs, deprecates strict layering. ISO 8648, the Internal Organization of the Network Layer, splits the existing network layer into three sublayers, arguably with some overlap, not complete, with the IEEE 802.1 architecture of the bottom two layers. Howard C. Berkowitz 09:45, 16 November 2007 (UTC)
It isn't extensively considered in tunneling protocols, as the IETF essentially considered the number of layers to be a non-issue. Howard C. Berkowitz 09:45, 16 November 2007 (UTC)
* Does someone have time to search in the literature for the most common five layer TCP/IP model, and present them at this talk page?
The problem is that it only appears in certain textbooks, not any primary source, or even what I'd call a strong secondary source such as vendor documentation from Cisco, Juniper, Nortel, etc. Howard C. Berkowitz 09:45, 16 November 2007 (UTC)
* Perhaps we should remove all tuneling protocols into a separate Template:Tuneling protocol template, with one column (or row) for each of the most common alternative protocol stack. For example, one alternative is IP over PPP over L2TP over TCP over IP.
* It would also be interesting if someone developed a separate Template:SOA protocol stack template, showing alternative protocol stacks for web service in each column or row. I beleive that examples of alternatives are RPC over SOAP over HTTP, XML over HTTP, WSDL over HTTPS/SSL, etc. Okay, XML and WSDL are not protocols, for data formats, similar to MIME, so "protocol stack" may not be an appropriate name.
* Question: What to do about MPLS?
MPLS is yet another reason to show that the idea of strict layering doesn't work. MPLS allows for an arbitrary number of stacked labels, each label level arguably being a "layer". Some simple real-world examples would be to have one level of label at an enterprise connection to its service provider, which is to be preserved at the other end of the connection to the other site(s) of the enterprise. As soon as that labeled MPLS packet hits the ISP, however, the ISP pushes another layer of label onto it so it can group Forwarding Equivalence Classes (a specific MPLS term) variously of the same quality of service and different end users, or different qualities of service for multiple end users. There are many examples of this with RFC 2547 implementation, with FECs or labels or both associated with some of the more complex delivery policies.
Even a single large ISP, however, may push down another layer of labeling if it has a distinct edge-vs.-core architecture. Further, if the first ISP now leases MPLS links (e.g., a regional provider going to a national or transoceanic provider), the latter "wholesale" provider may very well push one or more additional label/layers onto the stack. One is a minimum for carrying "wholesale" traffic; two or more might be used with edge/core organization.
Do note that a simpler but still two label level structure exists when encapsulating user VLAN 802.1q labels into an internal VLAN inside the provider cloud, called "Q-in-Q". Howard C. Berkowitz 09:45, 16 November 2007 (UTC)

Mange01 19:36, 28 June 2007 (UTC)

I would still prefer to see a four layer model. Apparently "modern text books" split the bottom layer into the OSI data link and physical layers. I haven't tried to verify this, but can see how it would be useful for pedagogical purposes, especially since the OSI layer numbers are so commonly used in so many contexts today. But TCP/IP really doesn't include this separation; IP just passes the packets to whatever "link" or "network access" facility is used by the interface, whether it be Ethernet, MPLS, or a tunnel. So the issues of how to handle tunneling protocols and MPLS only exist because the bottom layer is split here. I'd like to see how the text books that use a five layer TCP/IP model address this.
But if someone has time for a literature search, please don't restrict it to five layer TCP/IP models. The (apparently obsolete) four layer model does have advantages!
I've never seen a TCP/IP model that treats management protocols separately. I agree it's an interesting suggestion, but there would need to be literature support before including it here.
--Rick Sidwell 04:44, 30 June 2007 (UTC)
The most common way management was shown in ISO or IEEE work, which considered layering, was as a second parallel vertical stack
OSI user layer OSI management layer
Application CMIP plus layer management protocols for Application itself, such as ACSE and ROSE. SNMP in an IETF stack.
Presentation (null management in basic ISO, although arguably crypto setup in cryptographic encoding rules. Think, for example, of IETF ISAKMP
Session (null in basic ISO)
Transport (null in basic ISO, but non-null in end-to-end tunneling. This is discussed in ISO Technical Report 10000, which is not available online and free)
Network (3 sublayers per ISO 8648 IONL) Multiple management levels. Layer management ("inside the cloud") includes network layer routing protocols regardless of how they are encapsulated. At the "edge", ARP and related Subnetwork Dependent Convergence Protocols
Data Link (MAC/LLC per IEEE) IEEE fuses station management across Data Link and Physical
Physical (split under various names, such as PLS and AUI in Ethernet DIX2, and MII/MDI in later IEEE and ANSI (i.e., FDDI) standards Fused with station management

Howard C. Berkowitz 09:45, 16 November 2007 (UTC)

[edit] No primary or strong secondary source uses five layers

(slightly edited from TCP/IP model talk page; I just learned of this discussion and will address some of the points above).

I quite seriously propose that the five-layer stack drawing, which is not authoritative by any IETF document, be replaced with a four-layer stack consistent with RFC 1122. As far as I can tell, the basis for the five layer argument are only secondary sources, such as Stallings' book.

As long as I am being bold, I'd like an agreement to put strong words in the introduction to this article that it is not OSI-compliant, there is strong historical reason that the designers of this stack did not intend it to be OSI compliant, and that people experienced in using and teaching this stack find that one of the chief barriers to understanding the most widely used stack in the world is that they are trying to force it into an obsolete OSI model. Howard C. Berkowitz 22:29, 13 October 2007 (UTC)

I agree with you that a four-layer stack makes more sense and would be more appropriate... however, I think it's important to keep an article (or part of an article) on the five-layer model, if only because it's so well-known. If you want to create an article for the four-layer model (or maybe better, just expand this article), I think it would be an excellent idea.
But it sounds like you might just be interested in replacing that awkward TCP/IP Model template, which is actually maintained over in the Template area: Template:IPstack. It looks like they've been arguing on the Talk page about the number of layers to include for quite a while. :)
Either way, I approve of both your proposals. Indeterminate 07:18, 16 November 2007 (UTC)
Thank you. I'll try to clone this over at the Template area, but I've become frustrated about making any headway over here, because of loud and unsupported arguments that there is a five-layer model. I'm puzzled by the need to keep an article on the "five-layer model", which does not exist in any IETF documentation, but explicitly defines a four-layer model (RFC1122), and explicitly speaks against strict layering in several statements of architectural principles. ISO does not ever define a five-layer model; ISO started with a seven-layer model in ISO 7498, and then added sublayers in several documents. It does not exist in any IEEE document, which deal only with the bottom two layers and sublayers. These, I believe, constitute the primary sources on networking architecture and layering.
Further, it does not exist in any training material from Cisco, Juniper, or Nortel, and, as far as I know, Microsoft. The major vendors arguably are the chief secondary sources of de facto rather than de jure concepts of layering.
It exists, as far as I can tell, in some textbooks, and in Wikipedia. I've published textbooks myself, and I have asked a number of colleagues who are also networking book authors, and they never used the concept. If one makes use of the sublayering of IEEE or ISO, even ignoring the reorganization of the upper layers by ISO, one might get:
  • 9 layers: OSI basic model plus IEEE sublayering of LLC/MAC and (two layers, but by different names in different documents), medium independent/medium dependent, or PLS/AUI in the original Ethernet documents.
  • 11 layers: OSI plus the additional two layers of the Internal Organization of the Network Layer, plus the additional layers in IEEE 802.1 mentioned just above.
  • 7 layers, IETF plus IEEE, taking the three layers from internetwork on up, and then two two-sublayer models below it.
  • 9 layers, using the three sublayers of the ISO IONL, and the two sublayers of IETF in the bottom two layers, plus IETF end-to-end and application.
In the real world, however, all of these tend to break down when considering protocols that use recursion to create tunnels, such as L2TP, IP in IP, IPSec, MPLS (with arbitrary numbers of stacked labels), 802.1q-in-q, ATM LAN Emulation, etc.
I appreciate your comment, and will try to bring this to the template talk page. Unfortunately, I don't know how to create a revised template and propagate it, and, unless there is first some consensus that no authoritative reference uses five layers, it doesn't seem worth the effort if some people are going to keep citing a textbook or two that, as far as I can tell, is the only source. Howard C. Berkowitz 09:45, 16 November 2007 (UTC)


[edit] OSI Model vs TCP/IP Model

An anonymous user has changed the label on the box to read 'OSI Model' instead of 'TCP/IP Model', apparantly on the grounds that the TCP/IP Model is "only a part of" the OSI model. While the TCP/IP model could be viewed as a more general model whose layers correlate to those of the OSI model, it is not true to call one the other. It would, in fact, still be untrue to call one the other if one was a subset of the other, as claimed. As such, I am reverting this as a major inaccuracy (after originally seeing the rather major mislabeling on a protocol page). I note that this IP has been reverted before on the same change, and would ask them to discuss such a major change here before applying it again. —Preceding unsigned comment added by Namegduf Live (talk • contribs) 19:38, 23 February 2008 (UTC)