BrowseAtWork.com:   [ UP ]   [Manage cookies]

Template talk:IPstack

From Wikipedia, the free encyclopedia

Jump to: navigation, search
WikiProject Computing / Network (Rated Template-Class)
Information technology portal
This template is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of Computing on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Template page Template  This template does not require a rating on the project's quality scale.
Bus icon.svg
 This template is supported by WikiProject Computer networking.

Archives
Archive 1

Contents

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


[edit] TCP/IP model

In the past week I have taken the initiative to resurrect the correct version of this successful model (as if there ever was another) and exposed myself to possible high-blood pressure problems. I have read RFCs for 20some years and found it not only shocking, but quite insulting to the founders of the Internet and every expert that helped along the way to deface their work, insights, and legacy by confusion rooted in pure ignorance of facts it seems. Promptly, someone tried to restore the misrepresentations today. I hope, that this knowledgeable community will be in support of the only IP model, as was as expressed here by others. Kbrose (talk) 19:58, 11 July 2008 (UTC)

Thank you. Excellent work. Indeterminate (talk) 04:54, 15 July 2008 (UTC)


[edit] Layer names and number of layers in the literature

The following table shows the layer names and the number of "Internet layers" in the "TCP/IP reference model" as presented in widespread university course literature on computer networking used today.

Forouzan [1] Comer [2] Stallings [3] Tanenbaum [4] Kurose [5] Cisco Academy [6]
Five layers Five layers Five layers Four layers Four layers Four layers
L5 Application Application Application Application Application Application
L4 Transport Transport Host-to-host or transport Transport Transport Transport
L3 Network Internet Internet Internet Internet Internet
L2 Data link Data link (Network interface) Network access Host-to-network Link Network interface
L1 Physical Physical Physical
  1. ^ Behrouz A. Forouzan, Data Communications and Networking
  2. ^ Douglas E. Comer, Internetworking with TCP/IP: Principles, Protocols and Architecture, Pearson Prentice Hall 2005, ISBN:0131876716
  3. ^ William Stallings, Data and Computer Communications, Prentice Hall 2006, ISBN:0132433109
  4. ^ Andrew S. Tanenbaum, Computer Networks, Prentice Hall 2002, ISBN:0130661023
  5. ^ James F. Kurose, Keith W. Ross, Computer Networking: A Top-Down Approach, 2007, ISBN:0321497708
  6. ^ Mark Dye, Mark A. Dye, Wendell, Network Fundamentals: CCNA Exploration Companion Guide, 2007, ISBN:1587132087

Mange01 (talk) 22:19, 16 July 2008 (UTC)


[edit] Analysis

Well, let's pick them apart and see the merits (in no particular order)

[edit] KUROSE&ROSS

Let's start with the easy one. Don't have access to this one right now, but Mr. Kurose and Ross seem to be doing something right. They get 100 points for getting the layers right if one can trust this table.

Pretty bad state of affairs, only 1 out of 6 actually read the literature and can report it correctly.


[edit] TANNENBAUM

bottom layer: "Host-to-network Layer"

QUOTE: (this is the ENTIRE chapter on this topic)

  The Host-to-Network Layer
Below the internet layer is a great void. The TCP/IP model does
not really say much about what happens here, except to point out that the host has
to connect to the network using some protocol so it can send IP packets to it. This
protocol is not defined and varies from host to host and network to network.
Book and papers about the TCP/IP model rarely discuss it.

Well, certainly a well known author. But his insight into TCP/IP is truly mind-blowing. Is this all he can come up with? Apparently he hasn't read RFC 1122, where the layer is defined as Link layer, and populated with very well known protocols (ARP) and ETHERNET and IEEE 802 Encapsulation. Or perhaps, RFC 2328 (INTERNET STANDARD 54) and RFC 2740 that clearly place OSPF into the Link Layer, consistantly talking about Link State (as all link-state routing protocols should). Quoting: "OSPF now runs on a per-link basis, instead of on a per-IP-subnet basis." which make this point very clear.

But then, of course, Mr. Tannenbaum, wasn't searching for references to the Link Layer, as he should have, but for some strange layer called Host-to-Network. Didactically very smooth and very pedagogical. Just save himself a whole chapter to write.

Of course there isn't much to write about, if you insist to move the Link Layer protocols into the Network Layer, as the OSI fanatics do. How more obvious can it be that this OSI layer stuff is more a brain cancer than intellectual discussion. But at least he is honest about that TCP/IP doesn't intend to cover the physical layer and he doesn't invent things, like non-existent layers.

[edit] CISCO

Just happened to look at their entire bookshelf recently, about 3 or 4 feet long, and opened the TCP/IP stuff. Discussion of models was pretty bad and when it seemed to move on to the lower than IP level(s) it abruptly stopped and suddenly slipped into CISCO-lese, in time-warp fashion. I thought I must have skipped a page or something, but hadn't. Hardly a worthy candidate to reference.

[edit] STALLINGS

-tba-

[edit] COMER

-tba-

[edit] FOROUZAN

-tba-


[edit] HOWEVER: RFC 3315

RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", July 2003 STANDARDS TRACK Authors from CISCO(!) Hewlett-Packard, Ericsson, Nominum (!), Nokia, Sun Microsystem Page 8 states as definition for terminology which is used throughout the text:

     link                      A communication facility or medium over
                               which nodes can communicate at the link
                               layer, i.e., the layer immediately
                               below IP.  Examples are Ethernet (simple
                               or bridged); Token Ring; PPP links,
                               X.25, Frame Relay, or ATM networks; and
                               Internet (or higher) layer "tunnels",
                               such as tunnels over IPv4 or IPv6
                               itself.

     link-layer identifier     A link-layer identifier for an
                               interface.  Examples include IEEE 802
                               addresses for Ethernet or Token Ring
                               network interfaces, and E.164 addresses
                               for ISDN links.


It seems like the original terminology is very much alive in STANDARD TRACK! And there seems to be no confusion what is contained in the link layer or what the layers name is. Clearly these authors don't need a physical layer to create STANDARDS for TCP/IP. Already they have more to say about the link layer than TANNENBAUM.

Kbrose (talk) 02:31, 17 July 2008 (UTC)


[edit] Vote: Four or five layers

This template has had five layers for over a year now, but recently it has changed to four layers. Also someone has without previous discussion tried do delete mentioning of a five-layer TCP/IP model in several articles. Please vote if this template should have four or five layers, and give short arguments. And what is the name of the bottom layer in case of four layers? "Link layer", "Data link layer", "Network access layer" or "Host-to-network layer"? See the table above. And is it okay to mention both the four and five layer models in wikipedia articles? Mange01 (talk) 22:21, 16 July 2008 (UTC)

  • Five layers gets my vote. At least both the four layer and five layer TCP/IP models should be mentioned in wiki articles on the topic. Arguments: See the table above. The original four layer DoD model has evolved into a five layer model, according to several course books in computer networking that are widely used in today's university courses, because of pedagogical reasons, and because of shortcomings in the RFC terminology. It would be confusing for today's students if wikipedia does not mention this. The physical layer is mentioned in several RFC:s. In case of four layers, I would prefer that the bottom layer is not called link layer, since that can be confused with data link layer - it is not clear if it involves physical layer issues or not. Mange01 (talk) 10:22, 13 July 2008 (UTC)
  • Four. Look, I sympathize. Times change; people want the TCP/IP model to reflect ideas they liked in the OSI model. But this contentious physical layer is, as your lovely table points out, still not standardized across the industry. A few textbook authors don't make any kind of consensus. We can add a section to the TCP/IP model page about the controversy, but I think this template should reflect the original model until an authoritative, industry-standard source publishes an updated version. Just my opinion. Indeterminate (talk) 23:37, 18 July 2008 (UTC)
  • Comment: as long as this template is based on RFC 1122, which clearly it is at the moment, it needs to stay four. If an alternate source of equal or greater weight is found which states five, then the template can be updated to include the five layers along with a link to that source. But in either case, the template must agree with what its primary source says. --WayneMokane (talk) 02:20, 28 August 2008 (UTC)

[edit] RE

Please cite the RFC's you mention that constitute a physical level for TCP/IP and that don't directly relate to ISO or IEEE design. I can't remember where teaching-course books have advanced or "evolved" the state of affairs in the sciences or engineering, that's not done through text-books. There is no primary, normative, peer-review literature that advocates a 5 layer TCP/IP model (that I know of, please show us otherwise). TCP/IP never has been concerned with hardware design or physical issues. It only cares about receiving data frames from a link technology. It's not a top-down architecture for the design of networks and hardware, but a description of the methods that operate the Internet. Why don't you stick to using the OSI model for teaching, rather than forcing it into TCP/IP or vice versa? Ah, of course the students will ask why doesn't the most successful network ever use these principles? Well, you can explain the failings of OSI better perhaps, but don't blame IETF and the RFC-editor system for shortcomings that don't exist. How pedagogical is it really, when a student would pick up RFC 1122 and discover that the original creators of this technology use terms like "Link layer" that they never heard of in class and that all this text-book stuff is made up? Most of wiki articles already state that this layer non-sense is against the design intentions of TCP/IP and what the common comparisons are. They can read and there should be no confusion. Oh, confused they will be, why they are being taught rubbish in class. The most "pedagogical" education is the accurate reflection of sources. You seem to have some vested interest against that. Kbrose (talk) 03:25, 17 July 2008 (UTC)

[edit] OSPF and BGP

About OSPF, considering it under data link layer is really confusing. whatever the RFC says, it does not necessarily mean that it is a Dala-Link Layer anyway. Because OSPF functionality is not just a Layer 2 functionality. and we have to take this in consideration. OSPF acts as layer 4 protocol. I think what you say that the RFC says ( I did not see the RFC, but ppl above talked about it) does not mean exactly that the OSPF is a layer 2 protocol. You can review the OSPF header to be sure that it is not a layer 2 anyway.

about BGP, Why is it considered as Application Layer Protocol?? All what I know and all what I have studied indicates that It is a transport layer protocol. any reference?? any ideas why is that???

Amjad Abdullah (talk) 19:19, 9 December 2008 (UTC)

TCP/IP doesn't have a 'data link layer' and OSPF is therefor not considered as data link layer, but as Link Layer, as it operates only on the local link, does not traverse routers (although OSPF routers handle more than one link). BGP a transport layer protocol? please, study some more. It's simply an application trading network path information between hosts. It uses the transport layer to do so. Kbrose (talk) 21:23, 9 December 2008 (UTC)
Trying to align TCP/IP protocols into the OSI reference model can not be done satisfactorily. The placement of the OSPF into the data link layer is just one example. That being said, I also strongly disagree with placing the OSPF into the data link layer. Kbrose has pointed out that the OSPF does not traverse routers. That is only partially true (actually, the LSAs in LSUs are flooded throughout an area or OSPF domain, the virtual links use addressed OSPF packets), moreover, it is not a defining property of a Layer3 protocol to traverse routers. The OSI layers are defined by their functionality. The Layer2 layer functionality is to provide communication means between neighboring devices, i.e. between devices on a common (not necessarily shared) medium (segment). Obviously, the OSPF does not have anything to do with communication of two devices on a common hub/switch/broadcast domain, on the contrary, it relies on the prior possibility of neighboring devices to communicate! I personally tend to see the OSPF in the application layer.Paluchpeter (talk) 06:54, 15 April 2009 (UTC)
You correctly state that aligning TCP/IP protocols into the OSI reference model cannot be done satisfactorily. Yet, you continue on to use OSI terms and the OSI model here. This article, the template, concerns the TCP/IP model, not OSI. In addition, OSPF has always been developed and described within the TCP/IP suite. Please see the talk page Talk:Open Shortest Path First for prior discussions. Kbrose (talk) 17:52, 15 April 2009 (UTC)
Hi Kbrose. You are right about my OSI-ness :-) I let myself talk in OSI terms. Sorry about that, and thanks for pointing it out. I have read your discussion in the OSPF article about its placement. It was a very interesting reading and while I can't say you have convinced me, you made me think about a couple of things that I took for granted:
  1. How shall a protocol be classified into a layer? Very often, it is classified by the services it depends on. Quite logically, they must be provided already by other layers, and within our usual hierarchical models, the services are provided by the lower layers than the layer in which the protocol under dispute is located. From this viewpoint, many people including me use to place the OSPF into the application layer, as it presently depends on services provided by IPv4 or IPv6 protocol. However, a second way to classify a protocol (and this is what you seem to prefer) is to classify it by the services it provides itself. Now, the OSPF clearly provides services to Internet layer, but not the usual "transport" service as, say, Ethernet does, but rather it provides control information on how shall the Internet layer operate. This would move the OSPF down to or under the Internet layer, maybe even to the Link layer as you have placed it. This second approach essentially tries to avoid the implementation dependencies. Clearly, the OSPF could be encapsulated directly into Link layer frames in a similar fashion to the IS-IS and it would work, so the Internet layer is not really necessary to deliver OSPF packets. Still, the Internet layer provides, for example, the addressing semantics (address formats et al.) used inside the OSPF messages... so even an OSPF placed on the Link layer (that should be agnostic about the Internet layer) needs to be Internet layer specific, at least in the addressing issues. That, in my opinion, moves the OSPF to the Internet layer, not as a user protocol used to transport user data, but rather as a support (or service) protocol used for purposes of the Internet layer itself.
  2. You have yourself said earlier that the BGP is simply an application protocol. What makes you think differently about the OSPF?
  3. May I contact you directly, using the e-mail function on the Wikipedia? This looks to be a longer debate and I am not sure if the Wiki talk page is the best place for us to discuss these subtleties.
Looking forward to your answer.Paluchpeter (talk) 06:47, 19 April 2009 (UTC)

[edit] Navbox

This template could slowly use some re-designing via Navbox.--Kozuch (talk) 21:24, 11 February 2009 (UTC)

I think it works better as a sidebar; there is an emerging meta-template for this purpose, but I'm a bit wary of deploying it right now. It works well as a sidebar for two reasons. The first is that it fills the top-right corner of related articles in lieu of a lede image (as few of the subjects have fitting images). The second is that a vertical layout is a nice analogue to the "stack" concept. Chris Cunningham (not at work) - talk 09:45, 12 February 2009 (UTC)
Sorry, I just dont agree with you. Sidebars templates are really disturbing in the articles and I see no good enough reason why this could not move over to nav-box. Such a navigational templates should be at the bottom of articles.--Kozuch (talk) 10:02, 12 February 2009 (UTC)
I don't think we're going to see the back of sidebar-style nav templates any time soon. As it stands, I reckon this is one of the better uses for the layout. Fancy taking this to a wider value to see what kind of support it has? Chris Cunningham (not at work) - talk 12:02, 12 February 2009 (UTC)
no navbox - When this template was recently converted from a blob into an infobox, I checked into other templates. I think the infobox is fine and I really don't want to see a navbox. I hadn't thought clearly whey, but I think Chris's comments above make sense to me. Wrs1864 (talk) 13:09, 12 February 2009 (UTC)
I have nothing against side-boxes, as long as you do not put on top of articles - which is impossible though.--Kozuch (talk) 14:01, 12 February 2009 (UTC)

[edit] template bloat

I am a little concerned about how many protocols are listed directly in this template. At each layer, there is a "(more)" link that shows all the protocols in the relevant category, so I don't think it is critical that every moderately-used protocol gets a spot directly on the template. I have hacked it back once, but I have concerns over how we now have two MGCP entries, GTP, RTSP, STUN, DCCP, NDP, "device drivers", etc. I guess in my opinion, we need enough of the very best known protocols at each layer so that someone looking at it can say "Oh! I understand which protocols fit where", and can click the appropriate "(more)" link if the protocol they are interested in isn't listed. Thoughts? Wrs1864 (talk) 20:37, 24 February 2009 (UTC)

In general terms, I couldn't agree more. I did have the concern when adding Megaco, I think that could be reverted. MGCP, on the other hand, is such a major protocol still to leave it out. I would say STUN could be eliminated, although in wide-spread use, it is a support protocol at best (now actually a potpourri of methods), and perhaps GTP is not well known by many, but the remainder in the template really represent the core of TCP/IP protocols and probably deserve their top exposure here. 'Device drivers' probably doesn't need the status here. Too remote from real TCP/IP concerns. Kbrose (talk) 21:19, 24 February 2009 (UTC)
I guess my point isn't whether MGCP is too much of a major protocol to leave out, but rather is MGCP well known enough to the typical reader of this template help as a guide to understanding. Most network/computer aware people recognize HTTP, TCP, IPv4, Ethernet, etc., and those help people understand the layers. The more clutter we have, the harder it is for people to scan the infobox and understand it. Does it really help people to have three e-mail protocols listed (SMTP, POP, IMAP)? Do we need SIP, MGCP, and SDP? Would it be better if the application layer was grouped by topic instead of alphabetical, so that IRC and XMPP are together, instead of picking one as a representative protocal or listing both? Wrs1864 (talk) 16:51, 25 February 2009 (UTC)
I think topical grouping within the layers might make a lot of sense, and I think it may have been tried before to a degree until someone alphabetized the list again. But grouping is probably only good for people that already know the protocols somewhat, not for people looking to find an acronym they haven't heard of before, but then, as you point out, there is the category page (more) linked in every group. I am not advocating that only protocols well know by everyone should be displayed, but those that are actually in wide-spread use (which would be the ones everyone should know). MGCP is a major protocol for VoIP still today, given that some of the largest consumer voice networks use it (BT, AT&T, Cablevision/OptimumVoice). If someone sees MGCP in this list and doesn't know it already, they have a chance to discover a major protocol that they should know, rather it being buried in the category page where they will likely not discover it. I think that's an important function of a navigation box like this. I think we should have all three e-mail protocols listed, yes, they are perhaps the busiest protocol group of the Internet. We should also have all major VoIP protocols, and we are still missing H323 for some reason, SDP might be secondary (support) priority. Kbrose (talk) 18:53, 25 February 2009 (UTC)
As I mentioned above, one solution to the "glob of protocols" at the app layer is to categorize them. I have created a possible IPstack template to show this idea on Template talk:IPstack/IPstack-categorized. I don't think this template is finished, far from it. I don't particularly like the layout, and I did not put a huge amount of thought into what the categories should be, their names, or exactly which protocols should go where. Still, I think it gives everyone an idea and makes things clearer to people who don't know most of these protocols. Thoughts? Wrs1864 (talk) 17:23, 5 March 2009 (UTC)
Looks great. I've moved it to template:IPstack/sandbox, the standard location for sandbox code. Chris Cunningham (not at work) - talk 09:21, 9 March 2009 (UTC)
Chris, looking at your edit history, you seem to do a lot with templates. Could you review how I implemented this idea if you have time? I tried several different things, none seem to be very clean (most didn't even work). Thanks. Wrs1864 (talk) 13:12, 9 March 2009 (UTC)
I think your implementation is about as clean and semantically sound as is possible with the {{infobox}} base template. If you have any questions regarding template coding please feel free to ping me and I'll see what I can do. Chris Cunningham (not at work) - talk 13:51, 9 March 2009 (UTC)

(outdent) OK, I've hacked on the template some more. I think it looks fairly good, but it is larger than the old one and I'm a little concerned about that. Anyone care to comment and/or improve it? Again, see template:IPstack/sandbox If no one objects, I may well more this to production soon. Wrs1864 (talk) 14:27, 9 March 2009 (UTC)

I think it's a fine looking design, but now that it's been presented, I think the old version with no categorization is preferable and quite adequate. Afterall this is meant to be quick-link navigation template with only the most important protocols. Application specific categories were never defined or mentioned in the TCP/IP model (with one exception, there is a notion of support protocols at the application level) and this opens the avenue for other editors to create more topics for their favorite protocols, as well as for controversies of interpreting which group a protocol belongs to. I don't like the concept of stuffing ever more information into templates instead of writing well composed articles about a subject matter. If someone wants to find, say, e-mail protocols, they ought to look for the e-mail article or a wikipedia category. We can only list a few examples in the template here, and categorizing it expands the task of choosing which ones are the most important. The categoriziation of the application protocols should be attempted in the article 'Application Layer', where there is plenty of space and where discussion can take place, not here. That article is a total mess currently. The template provides direct links into each layer article. This template is also linked into so many articles that have nothing do to with application layer protocols, and for those the categorization in that layer adds greatly to the template bloat mentioned in the past. Kbrose (talk) 15:36, 9 March 2009 (UTC)

[edit] Physical Layer protocols

I think it is necessary to add physical layers and protocols under the same. Widely used are RS232, RS485, RS422 & Physical layers of Ethernet, SPI & CAN. We can also expand this list based on the discussions. Also change the topic to ISO model which is more informative & Internet protocol suite as per RFC can be colored using a different color code under the sameFahidka (talk) —Preceding undated comment added 06:58, 28 August 2009 (UTC).

TCP/IP doesn't concern itself with the physical layer, perhaps you might like to read OSI model instead. Kbrose (talk) 16:45, 28 August 2009 (UTC)

[edit] OSPF is a layer 3 protocol not a link layer protocol

The current table lists OSPF as a link layer protocol. It is a layer 3 protocol (IP protocol 89) which works on top of other layer 2 technologies (ex. Ethernet, Frame-Relay, PPP). From the RFC (2328)

  4.3.  Routing protocol packets
       The OSPF protocol runs directly over IP, using IP protocol 89.
       OSPF does not provide any explicit fragmentation/reassembly
       support.  —Preceding unsigned comment added by 64.102.254.33 (talk) 23:24, 6 October 2009 (UTC)
You're mixing terms with OSI; Encapsulation sequence is not a criterion in TCP/IP, only for OSI. OSPF runs on the local link only, see OSPF article and discussions there. Also, in OSPFv3 all IP specific address info is removed from the protocol. Kbrose (talk) 01:53, 7 October 2009 (UTC)

I think the above needs some work. It isn't clear to me (I am not an OSFP expert), but from reading several other sources it sure seems to run on top of IP...and thus would be a layer 3 (ISO) protocol. 192.91.173.42 (talk) 18:46, 15 October 2009 (UTC) Greg Edwards 15 October 2009

Again, this is a template for TCP/IP not OSI. TCP/IP does not use strict encapsulation layering as OSI is supposed to do, and whether OSPF runs on IP is not important, it's the fact that it only runs on the local network, by subnet as in OSPFv2, or by link as in OSPFv3. Kbrose (talk) 19:45, 15 October 2009 (UTC)

[edit] dns

what is dns? —Preceding unsigned comment added by 122.162.71.43 (talk) 02:46, 10 October 2009 (UTC)

[edit] RTP protocol layer

Hi, there is a RTP protocol listed under application layer (7), but RTP is on the 5th layer - session. It provides a support for adding QoS at application layer (RTP alone does not ensure QoS), so it's a nonsense to list it under 7th layer. http://nsgn.net/osi_reference_model/the_internet_protocol_suite_a_lesson_in_protocol_stacks.htm —Preceding unsigned comment added by 88.146.86.251 (talk) 21:20, 18 January 2010 (UTC)

The TCPIP model only has 4 layers, so your comment is nonsense too. Kbrose (talk) 00:49, 19 January 2010 (UTC)

[edit] Including RADIUS and DIAMETER

Can we include RADIUS and DIAMETER in this info-box, as both of these protocols pages display it on top. EngineerFromVega (talk) 08:15, 27 January 2010 (UTC)

There are hundreds of protocols based on IP, we can only include the core protocols as stated in the guidelines for the template. Make sure others have a category for the layer and they will show up on the 'more' link. Kbrose (talk) 14:42, 27 January 2010 (UTC)
Retrieved from "http://en.wikipedia.org/wiki/Template_talk:IPstack"