Re: TCP/IP Terms
At 11:38 PM 10/7/2002 +0700, Robert Elz wrote: Attempting to give these things absolute numbers, other than for ease of reference in some particular context is lunacy. Not that I disagree with your primary point, it is worth noting that there is some basis for hovering about 7, for an *overall* model. It's that memory limit thing (7, plus or minus 2.) The plus or minus is statistical, so if you want to make sure that people really have no trouble grokking the total set, 5 is a better choice. d/ Dave Crocker mailto:[EMAIL PROTECTED] TribalWise, Inc. http://www.tribalwise.com tel +1.408.246.8253; fax +1.408.850.1850
RE: TCP/IP Terms
Cynicism I always figured it was based on the number of managers that you have on the project, one manager for each layer... At least that is how it was done at a previous company I worked for... /Cynicism Models are very nice to help you get people to think about something the same way. Of course the best engineers that I know, understand the model, but think way outside it... Letting unique solutions that break the model, but deliver better results... Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dave Crocker Sent: Tuesday, October 08, 2002 12:25 PM To: Robert Elz Cc: [EMAIL PROTECTED] Subject: Re: TCP/IP Terms At 11:38 PM 10/7/2002 +0700, Robert Elz wrote: Attempting to give these things absolute numbers, other than for ease of reference in some particular context is lunacy. Not that I disagree with your primary point, it is worth noting that there is some basis for hovering about 7, for an *overall* model. It's that memory limit thing (7, plus or minus 2.) The plus or minus is statistical, so if you want to make sure that people really have no trouble grokking the total set, 5 is a better choice. d/ Dave Crocker mailto:[EMAIL PROTECTED] TribalWise, Inc. http://www.tribalwise.com tel +1.408.246.8253; fax +1.408.850.1850
Re: TCP/IP Terms
--On Tuesday, 08 October, 2002 12:25 -0700 Dave Crocker [EMAIL PROTECTED] wrote: At 11:38 PM 10/7/2002 +0700, Robert Elz wrote: Attempting to give these things absolute numbers, other than for ease of reference in some particular context is lunacy. Not that I disagree with your primary point, it is worth noting that there is some basis for hovering about 7, for an *overall* model. It's that memory limit thing (7, plus or minus 2.) The plus or minus is statistical, so if you want to make sure that people really have no trouble grokking the total set, 5 is a better choice. I would suggest that this particular situation has almost nothing to do with the Miller result. In particular, that hypothesis derives from work with short-term memory and the number of things one can keep track of at a time. The purpose of layering is, to some extent, similar to that of modularization of other types, i.e., to reduce the number of things you need to think of at a time. And, from that standpoint, kre's observation to the effect that the one you are looking at, one up, and one down is what is relevant is exactly the right short-term memory analysis. And that number is lots smaller than seven. Or even five. But this is getting very far afield from anything relevant to the IETF or network modelling. john
Re: TCP/IP Terms
At 08:19 PM 10/8/2002 -0400, John C Klensin wrote: I would suggest that this particular situation has almost nothing to do with the Miller result. In particular, that hypothesis derives from work with short-term memory and the number of things one can keep track of at a time. for serially related data, yes. data that might be termed independent contexts probably is down to one for each of the information bits that he postulated, namely 3. 2 if you want to be safe. At any rate, juggling a model, for doing real-time work -- like discussion -- seems to involve short-term memory issues. Hence the limit still seems to apply. But this is getting very far afield from anything relevant to the IETF or network modelling. that was why I hadn't gone into citing Miller's paper, which is, by the way, a really fun read. It was published in the preeminant psych journal, yet he open it with a discussion of his being stalked by a number... d/ -- Dave Crocker mailto:[EMAIL PROTECTED] TribalWise, Inc. http://www.tribalwise.com tel +1.408.246.8253; fax +1.408.850.1850
TCP/IP Terms
Vint, I'm sure you've been following the discussion concerning the confusion that has been arising inside and especially outside the IETF community about TCP/IP terminology. In reading RFCs 793,1122-3 it seems to me that TCP/IP doesn't center so much around layering as it does protocols. Datagrams at the transport and Internet layer, for example. Micheal Py is a follower of the OSI model and while I believe in innovative freedom and eveyone or anyone can design a model, I'm behind TCP/IP. I've even been thinking about writing a draft that would be a call to the internet community for more standardization of TCP/IP to clear up terms and layering discrepancies, at least discrepancies to me anyway. For example Vint, If someone said to me datagram. I would have no idea what he was talking about unless he said UDP or TCP datagram or IP datagram. Then knowing the model I would understand. I have been criticized for being too particular about things and too trolling. I only want TCP/IP to be able to survive and compete. In a world of IPX, SPX, OSI, NetBUEI, etc. TCP/IP should be able to run on any Intranet, Extranet, and of course the Internet, with the best of them. - Bill
RE: TCP/IP Terms
Bill, I think that such terms as Internet, Intranet and Extranet DO owe their existence to the wide implementation and use of TCP/IP. So - IMHO - you don't have to worry about TCP/IP to survive and compete (particularly against SPX/IPX and NetBIOS/NetBEUI). ;) TCP/IP DOES RUN on any Intranet, Extranet and Internet, because - by definition - they DO RUN TCP/IP. Regarding OSI, just consider it as a theoretical reference model particularly well-fitted for training purposes (even if it's NOT limited to that), if this can ease your mind. :) P.S.: on the other hand, I don't think TCP/IP needs to be protected. It only needs a smooth migration to IPv6. -Original Message- From: Bill Cunningham [mailto:[EMAIL PROTECTED]] (...) I have been criticized for being too particular about things and too trolling. I only want TCP/IP to be able to survive and compete. In a world of IPX, SPX, OSI, NetBUEI, etc. TCP/IP should be able to run on any Intranet, Extranet, and of course the Internet, with the best of them. (...)
RE: TCP/IP Terms
Eric Tomson wrote: I think that such terms as Internet, Intranet and Extranet DO owe their existence to the wide implementation and use of TCP/IP. So - IMHO - you don't have to worry about TCP/IP to survive and compete (particularly against SPX/IPX and NetBIOS/NetBEUI). ;) TCP/IP DOES RUN on any Intranet, Extranet and Internet, because - by definition - they DO RUN TCP/IP. Regarding OSI, just consider it as a theoretical reference model particularly well-fitted for training purposes (even if it's NOT limited to that), if this can ease your mind. :) P.S.: on the other hand, I don't think TCP/IP needs to be protected. It only needs a smooth migration to IPv6. I Agree with Eric (BTW Eric I stole your PDU names for the OSI model, they're better than mine). This has nothing to do with the protocol suite, but with model semantics. Michel.
RE: TCP/IP Terms
Mastaka / Bill, Michel Py wrote: In terms of design, if you do TCP/IP *only* design, the TCP/IP model is probably enough. However, the Internet is not only TCP/IP. Carriers, for example, don't care much if their fiber transports TCP/IP or IPX or voice or video or GigE. Masataka Ohta wrote: No. Anything at or above transport layer is a layer internal to end systems and has nothing to do with networking or network protocols. Seperation of transport and application layers is a overkill for a best effort network, though it may help standardize the internal design of end systems such that anything supported by kernel belong the transport layer. You can check the reality that application and transport areas of IETF are now almost identical, though, historically, trasnsport area was working on protocols likely to be implemented in kernel. In addition, defining a thin transport layer may be useful over a hypothetical port-number-aware network such as that supporting RSVP. However, forcibly defining a session-layer-aware network is a layer violation. I don't disagree for the upper part of the model, but all the examples I have used in this thread were about the lower part of the model. Michel Py wrote: And, there are complex multi-protocol networks that a) don't use only TCP/IP and b) would not be able to use the TCP/IP model anyway because it's too simple. Bill Cunnigham wrote: * Would not be able to use TCP/IP.* How can that be changed? If I had to design a model it would be: Michel's TCP/IPOSI model model model +--+ +---+ +---+--+ ! ! ! ! ! 7 ! Application ! ! ! ! ! +---+--+ ! Application ! ! Application ! ! 6 ! Presentation ! ! ! ! ! +---+--+ ! ! ! ! ! 5 ! Session ! +--+ +---+ +---+--+ ! Transport! ! Transport ! ! 4 ! Transport! +--+ +---+ +---+--+ ! Network ! ! Internet ! ! 3 ! Network ! +--+ +---+ +---+--+---+ ! Logical Link ! ! ! ! ! Data ! LLC ! +--+ ! Network ! ! 2 ! Link +---+ ! Media Access ! ! Interface ! ! ! ! MAC ! +--+ ! ! +---+--+---+ ! Physical ! ! ! ! 1 ! Physical ! +--+ +---+ +---+--+ I understand that people that have used the TCP/IP model don't care much of what's inside the Network Interface layer, but there is a bunch of stuff there that could use layering. That's why, short of having my very own model drawn above, I keep using the OSI one for explanatory/educational purposes. Michel.
RE: TCP/IP Terms
Folks, I would like to suggest that it is (well past) time to stop feeding the trolls on this topic. Bob Braden
RE: TCP/IP Terms
Vint, vinton g. cerf wrote: Michel, your drawing of TCP/IP is NOT the model I used in the design of TCP/IP. [Thanks for the historical precisions] My understanding is that the TCP/IP model is de-facto, opposed to de jure for the OSI model. Below are the top ten matches searching for tcp/ip model on google; basically none is the same; some have four layers, some have five, the names are not consistent. Some years ago I tried to teach the TCP/IP model and I had to spend hours explaining why my vision of the TCP/IP model was not the same as they have seen somewhere else (you know, if they've seen it on the Internet, same as they've seen it on CNN, it must be true). I'm having trouble explaining to students why a reference model has variable definitions. If this: +---+-+ ! 5 ! Application ! +---+-+ ! 4 ! Transport ! +---+-+ ! 3 ! Internet! +---+-+ ! 2 ! Link! +---+-+ ! 1 ! Physical! +---+-+ Is what you define as being the TCP/IP model (I don't think anybody would challenge *you* on this), would you please write an RFC about it so we can avoid what is below? http://www.pku.edu.cn/academic/research/computer-center/tc/html/TC0102.h tml http://www.indianest.com/computing/networking/n003.htm http://www2.themanualpage.org/networks/networks_tcpip.php3 http://www.8052.com/tcpip/ http://www.microsoft.com/windows2000/en/server/help/default.asp?url=/win dows2000/en/server/help/sag_TCPIP_ovr_model.htm http://dast.nlanr.net/Training/DCWJuly99/kai_tcpip/sld005.htm http://www.unm.edu/~network/presentations/course/chap2/sld018.htm http://academic.regis.edu/jguhlke/osi.ppt http://www.interex.org/pubcontent/enterprise/jul99/f1eltoft.html http://www.linuxsa.org.au/meetings/1998-02/conflinux/tcpipmodel.html Regards, Michel.
Re: TCP/IP Terms
Michel; In terms of design, if you do TCP/IP *only* design, the TCP/IP model is probably enough. However, the Internet is not only TCP/IP. Carriers, for example, don't care much if their fiber transports TCP/IP or IPX or voice or video or GigE. No. Anything at or above transport layer is a layer internal to end systems and has nothing to do with networking or network protocols. Seperation of transport and application layers is a overkill for a best effort network, though it may help standardize the internal design of end systems such that anything supported by kernel belong the transport layer. You can check the reality that application and transport areas of IETF are now almost identical, though, historically, trasnsport area was working on protocols likely to be implemented in kernel. In addition, defining a thin transport layer may be useful over a hypothetical port-number-aware network such as that supporting RSVP. However, forcibly defining a session-layer-aware network is a layer violation. And, there are complex multi-protocol networks that a) don't use only TCP/IP and b) would not be able to use the TCP/IP model anyway because it's too simple. Unless you are trying to standardize internal design of application layer gateways, which is like defining standardizing the way of structured programming and is hopeless, the separation of upper layers is meaningles. The bottom line is: lots of people are going to continue using the OSI model. We don't need two different models. I am having no difficulty in teaching my students, even though I often forget the names of two OSI layers between transport and application. In writing this mail, I only remember one: session. New comers don't need two different models. Masataka Ohta
Re: TCP/IP Terms
- Original Message - From: Masataka Ohta [EMAIL PROTECTED] To: Michel Py [EMAIL PROTECTED] Cc: Bill Cunningham [EMAIL PROTECTED]; Robert Elz [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, October 04, 2002 5:20 PM Subject: Re: TCP/IP Terms Michel; In terms of design, if you do TCP/IP *only* design, the TCP/IP model is probably enough. However, the Internet is not only TCP/IP. Carriers, for example, don't care much if their fiber transports TCP/IP or IPX or voice or video or GigE. No. Anything at or above transport layer is a layer internal to end systems and has nothing to do with networking or network protocols. Seperation of transport and application layers is a overkill for a best effort network, though it may help standardize the internal design of end systems such that anything supported by kernel belong the transport layer. You can check the reality that application and transport areas of IETF are now almost identical, though, historically, trasnsport area was working on protocols likely to be implemented in kernel. In addition, defining a thin transport layer may be useful over a hypothetical port-number-aware network such as that supporting RSVP. However, forcibly defining a session-layer-aware network is a layer violation. And, there are complex multi-protocol networks that a) don't use only TCP/IP and b) would not be able to use the TCP/IP model anyway because it's too simple. * Would not be able to use TCP/IP.* How can that be changed? Unless you are trying to standardize internal design of application layer gateways, which is like defining standardizing the way of structured programming and is hopeless, the separation of upper layers is meaningles. The bottom line is: lots of people are going to continue using the OSI model. We don't need two different models. I am having no difficulty in teaching my students, even though I often forget the names of two OSI layers between transport and application. In writing this mail, I only remember one: session. New comers don't need two different models. Masataka Ohta
Re: TCP/IP Terms
Date:Mon, 30 Sep 2002 16:04:35 -0700 From:Michel Py [EMAIL PROTECTED] Message-ID: 2B81403386729140A3A899A8B39B046405E327@server2000 | kre wrote: | It's the root of the Internet, not OSI or anything else. | Maybe TCP/IP needs to be more competative. No he didn't... kre
Re: TCP/IP Terms
At 03:46 PM 9/30/02 -0700, Ari Ollikainen wrote: At 1:30 PM -0700 9/30/02, Joe Touch wrote: Bill Cunningham wrote: I think the main goal is to compete with OSI's much more defined model. What's wrong with the OSI model? See Padlipsky's Elements of Network Style, again available in print. It's as relevent now as it was when it was written in 1984: http://www.iuniverse.com/bookstore/book_detail.asp?isbn=0%2D595%2D08879%2D1 Or, at the very least, read RFC 871 ... [[ Perhaps the most significant point of all about Layering is that the most frequently-voiced charge at NWG protocol committee design meetings was, That violates Layering! even though nobody had an appreciably-clearer view of what Layering meant than has been presented here, yet the ARMS exists. We can only guess what goes on in the design meetings for protocols to become members of the ISORM suite (ISORMS), but it doesn't seem likely that having more layers could possibly decrease the number of arguments ]] ... seems kind-of apposite ;-) #g --- Graham Klyne [EMAIL PROTECTED]
Re: TCP/IP Terms
Take a reality check: go to Border's or any bookstore and browse books about networking or internetworking. Tell me if you find the TCP/IP model there or the OSI model. As I said before, the time to design according to a model is way passed. What I do today as a protocol designer is based on my and other people's experience, not on a model that was invented 20 years ago before nobody could really envision today's Internet. In other words: I am not preaching for the ISO or any other model being a set of design guidelines. What I am trying to say is that when defining terms (read the subject of this thread) the OSI model is more precise than the TCP/IP one and is still the one used by people including myself that have a broader horizon than TCP/IP or the Internet. Michel. I can't disagree there, every book on networking I've ever read mentions TCP/IP and goes into detail concerning OSI, unless you read a book specificly about TCP/IP.
TCP/IP Terms
I think the main goal is to compete with OSI's much more defined model. I for one, don't want to see OSI overtake in any way TCP/IP, even in definitions. But Bill S. is correct, all you have to do is mention the layer and protocol. But there are so many new protocol's out there now, as I've mentioned before PPP is an example written since rfc 1122-23. It is now its own suite, with a family of link and network control protocols.
RE: TCP/IP Terms
Bill, This slide is confusing, for sure. The reason I posted the link was the comparison between the OSI and the TCP/IP models. Michel. From: Bill Cunningham [mailto:[EMAIL PROTECTED]] http://dast.nlanr.net/Training/DCWJuly99/kai_tcpip/sld008.htm I looked at this page of one of the links you sent me. Notice at the Internet and Transport levels it simply says, Application data (datagram ?), TCP header, could this be a datagram, or maybe a packet. Then at the Internet level, application data, TCP header and IP header. Now according to rfc 1122, we know that - o application data, tcp header o application data, tcp header, and ip header. Are both datagrams. Wow IMHO what a mix up. Unless you know the name of the protocol and where you know (or think) it is in TCP/IP, you're lost.
Re: TCP/IP Terms
Date:Mon, 30 Sep 2002 11:01:56 -0400 From:Bill Cunningham [EMAIL PROTECTED] Message-ID: 000701c26892$52428400$5844903f@a | I think the main goal is to compete with OSI's much more defined model. Why? | I for one, don't want to see OSI overtake in any way TCP/IP, even in | definitions. I'd actually much prefer for OSI to win the war of the definitions. Rigid definitions tend to constrain thinking to fit into the patterns defined. We're much better off just having a rough idea what things mean when it gets to this level. kre
RE: TCP/IP Terms
Bill, Bill Cunningham wrote: I think the main goal is to compete with OSI's much more defined model. What's wrong with the OSI model? Michel.
RE: TCP/IP Terms
I'd actually much prefer for OSI to win the war of the definitions. Rigid definitions tend to constrain thinking to fit into the patterns defined. We're much better off just having a rough idea what things mean when it gets to this level. While the concept of layering is fine (more or less), the specific layers adopted in the OSI model have only a moderate relation with actual practice, and are a poor fit for the Internet architecture. Specifically: 1) OSI's modeling of the lower layers was driven by the need to accommodate X.25 split between physical transmission, HDLC/LAP-B, and virtual circuits. This does not describe well the situation in the Internet, in which IP is often layered on top of what OSI considers a network layer, e.g. X.25 or ATM; the same problem arose when attempting to layer CLNP on top of these networks; this led to Byzantine discussions of sub-layers 3a, 3b and 3c. 2) OSI's modeling of the upper layers was driven by the need to accommodate the Teletex application, which used a pass-through transport (class zero) and required a session layer to handle check-pointing and restart. In the real world, check-pointing and other synchronization tasks are performed a layer above marshalling and un-marshalling, i.e. above the presentation layer. Again, OSI's response to the reality check has been a Byzantine decomposition of the application layer into application service elements that would what we usually understand as session control. The main problem with OSI is that they drew the layers in 1980, i.e. before the client server architectures based on RPC stabilized, before we gained experience with internetworking. The TCP-IP architecture choice of having an internet layer on top of a subnet layer, and single layer for the application were, at the time, much more practical. They withstood time much better. -- Christian Huitema
Re: TCP/IP Terms
| I for one, don't want to see OSI overtake in any way TCP/IP, even in | definitions. I'd actually much prefer for OSI to win the war of the definitions. Rigid definitions tend to constrain thinking to fit into the patterns defined. We're much better off just having a rough idea what things mean when it gets to this level. kre I don't want to see TCP/IP be overtaken either. It's the root of the Internet, not OSI or anything else. Maybe TCP/IP needs to be more competative.
Re: TCP/IP Terms
- Original Message - From: Michel Py [EMAIL PROTECTED] To: Bill Cunningham [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, September 30, 2002 1:28 PM Subject: RE: TCP/IP Terms Bill, Bill Cunningham wrote: I think the main goal is to compete with OSI's much more defined model. What's wrong with the OSI model? Michel. In and of itself, nothing. But it's not the Internet's true roots, and I don't think it works as well for the net's architecture.
Re: TCP/IP Terms
In the four-layer model, Application encompasses Layer 7, Layer 6, and Layer 5 from the seven-layer OSI model. I always considered TCP headers or IP headers as data formats that make up the overall protocol. They have to be processed. Therefore, they are essentially application data. Anyway, it gets confusing when you start trying to differentiate between what is an algorithm, what is a data format, what is a file format, and what is a protocol. The terms should be a lot clearer. For instance, some people think algorithms and protocols are the same. Other people think data formats and protocols are the same. Additionally, some people have trouble differentiating between what is a data format and a file format. Does data format mean the data is generated on-the-fly whereas a file format is a static file? In the logical sense, something like XML still has to be processed so to me it's just another data format but if you think of it in its statically and physically stored sense it's a file format. Mind boggling... :-) Brian B. Bill Cunningham [EMAIL PROTECTED] 09/30/02 12:34AM http://dast.nlanr.net/Training/DCWJuly99/kai_tcpip/sld008.htm I looked at this page of one of the links you sent me. Notice at the Internet and Transport levels it simply says, Application data (datagram ?), TCP header, could this be a datagram, or maybe a packet. Then at the Internet level, application data, TCP header and IP header. Now according to rfc 1122, we know that - o application data, tcp header o application data, tcp header, and ip header. Are both datagrams. Wow IMHO what a mix up. Unless you know the name of the protocol and where you know (or think) it is in TCP/IP, you're lost. - This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio.
Re: TCP/IP Terms
Bill Cunningham wrote: - Original Message - From: Michel Py [EMAIL PROTECTED] To: Bill Cunningham [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, September 30, 2002 1:28 PM Subject: RE: TCP/IP Terms Bill, Bill Cunningham wrote: I think the main goal is to compete with OSI's much more defined model. What's wrong with the OSI model? See Padlipsky's Elements of Network Style, again available in print. It's as relevent now as it was when it was written in 1984: http://www.iuniverse.com/bookstore/book_detail.asp?isbn=0%2D595%2D08879%2D1 Joe
Re: TCP/IP Terms
At 1:30 PM -0700 9/30/02, Joe Touch wrote: Bill Cunningham wrote: I think the main goal is to compete with OSI's much more defined model. What's wrong with the OSI model? See Padlipsky's Elements of Network Style, again available in print. It's as relevent now as it was when it was written in 1984: http://www.iuniverse.com/bookstore/book_detail.asp?isbn=0%2D595%2D08879%2D1 Or, at the very least, read RFC 871 ...
RE: TCP/IP Terms
kre / Bill, kre wrote: I'd actually much prefer for OSI to win the war of the definitions. Rigid definitions tend to constrain thinking to fit into the patterns defined. We're much better off just having a rough idea what things mean when it gets to this level. Bill Cunningham wrote: I for one, don't want to see OSI overtake in any way TCP/IP, even in definitions. I don't want to see TCP/IP be overtaken either. Nobody's ever suggested this. kre wrote: It's the root of the Internet, not OSI or anything else. Maybe TCP/IP needs to be more competative. In terms of design, if you do TCP/IP *only* design, the TCP/IP model is probably enough. However, the Internet is not only TCP/IP. Carriers, for example, don't care much if their fiber transports TCP/IP or IPX or voice or video or GigE. And, there are complex multi-protocol networks that a) don't use only TCP/IP and b) would not be able to use the TCP/IP model anyway because it's too simple. Also, the Internet can be used to tunnel other protocols. How would you describe the subtilities of Token-Ring DLSW+ with the TCP/IP model? I understand that we are the *Internet* Engineering Task Force. However, I don't see the incompatibility between TCP/IP and the OSI model. The bottom line is: lots of people are going to continue using the OSI model. We don't need two different models. Michel.
RE: TCP/IP Terms
Thanks man.. that clear up confusion on PPP ! mentioned before PPP is an example written since rfc 1122-23. It is now its own suite, with a family of link and network control protocols.
Re: TCP/IP Terms
I don't want to see TCP/IP be overtaken either. It's the root of the Internet, not OSI you have a problem with your email system. ten year old mail is being resent from you, but somehow it has current dates. randy
Re: TCP/IP Terms
- Original Message - From: Ari Ollikainen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 30, 2002 6:46 PM Subject: Re: TCP/IP Terms At 1:30 PM -0700 9/30/02, Joe Touch wrote: Bill Cunningham wrote: I think the main goal is to compete with OSI's much more defined model. What's wrong with the OSI model? See Padlipsky's Elements of Network Style, again available in print. It's as relevent now as it was when it was written in 1984: http://www.iuniverse.com/bookstore/book_detail.asp?isbn=0%2D595%2D08879%2D1 Or, at the very least, read RFC 871 ... Thanks Ari, I'll take a look at it.
Re: TCP/IP Terms
In terms of design, if you do TCP/IP *only* design, the TCP/IP model is probably enough. However, the Internet is not only TCP/IP. Carriers, for example, don't care much if their fiber transports TCP/IP or IPX or voice or video or GigE. And, there are complex multi-protocol networks that a) don't use only TCP/IP and b) would not be able to use the TCP/IP model anyway because it's too simple. Also, the Internet can be used to tunnel other protocols. How would you describe the subtilities of Token-Ring DLSW+ with the TCP/IP model? I understand that we are the *Internet* Engineering Task Force. However, I don't see the incompatibility between TCP/IP and the OSI model. The bottom line is: lots of people are going to continue using the OSI model. We don't need two different models. Michel. Fine let them use OSI or whatever they choose. But if TCP/IP has incompatibilies with token-ring LANS, this should probably be worked on. I believe in freedom to choose whatever model you wish, but TCP/IP is the Internet's model. Why does TCP/IP have trouble passing a token ring around hosts? I've never really got into that issue. I thought TCP/IP worked fine in Intranets.
RE: TCP/IP Terms
Bill, Michel Py wrote: The bottom line is: lots of people are going to continue using the OSI model. We don't need two different models. Fine let them use OSI or whatever they choose. But if TCP/IP has incompatibilies with token-ring LANS, this should probably be worked on. I believe in freedom to choose whatever model you wish, but TCP/IP is the Internet's model. Why does TCP/IP have trouble passing a token ring around hosts? I've never really got into that issue. I thought TCP/IP worked fine in Intranets. It's not a matter of compatibility, it's a matter of semantics. The point is *not* if TCP/IP works fine in Intranets; it does and it is becoming the only protocol suite on Intranets as well (faster in my dreams than in reality). The point I am trying (with difficulties ;-) to make here is: The OSI model as of today is a conceptual model. In the past, some good stuff came out of it and some real junk too; that was in the past. Today, if your protocol maps nicely to it, fine. If it does not, though. That being said, the Internet is not the only network out there and even on the Internet itself there are parts where the 4 1/2 layers TCP/IP model is way too simple. Take a reality check: go to Border's or any bookstore and browse books about networking or internetworking. Tell me if you find the TCP/IP model there or the OSI model. As I said before, the time to design according to a model is way passed. What I do today as a protocol designer is based on my and other people's experience, not on a model that was invented 20 years ago before nobody could really envision today's Internet. In other words: I am not preaching for the ISO or any other model being a set of design guidelines. What I am trying to say is that when defining terms (read the subject of this thread) the OSI model is more precise than the TCP/IP one and is still the one used by people including myself that have a broader horizon than TCP/IP or the Internet. Michel.
RE: TCP/IP Terms
Bill, Bill Cunnigham wrote: When someone says to me 'datagram.' I don't know what level of TCP/IP they're talking about. It could be IP datagrams at Internet layer, or UDP datagrams at Transport layer. Datagram only defines a connectionless protocol according to rfc 1122. This is a good point. IMHO, datagram could be: [ISO layers] - UDP datagram (transport layer) - ICMP datagram (network layer) - IP datagram = a network layer animal that contains data encapsulated from a connectionless transport protocol such as UDP. - I think that broadcasts would fall into the datagram category, too. And: - IP packet = a network layer animal that contains data encapsulated from a connection-oriented transport protocol such as TCP. That being said, I would think that datagram without the UDP before it is a network layer animal because this is the way it is understood in the ISO world. Now if someone says to me 'frame.' I think PPP first off, not necessarily Network layer, if that's where it is, rfc 1661 looks like it was written in accordance with the OSI model. I'm not sure of that one. The problem is that, IMHO, there is no such thing as a TCP/IP layered model. Even the number of layers seems to be floating between 4 and 5. [here are the first matches searching google for tcp/ip model] http://www.pku.edu.cn/academic/research/computer-center/tc/html/TC0102.h tml http://www.indianest.com/computing/networking/n003.htm http://www2.themanualpage.org/networks/networks_tcpip.php3 http://www.8052.com/tcpip/ http://www.unm.edu/~network/presentations/course/chap2/sld018.htm http://dast.nlanr.net/Training/DCWJuly99/kai_tcpip/sld005.htm In any case, lots of definitions seem to agree on the lower layer encompassing the data link and physical OSI layers. This might be a problem trying to define frame. This is one of the reasons I stick to the OSI model, because it is more precise. I even like the definition of the two sub-layers that form the data link layer: +---+--++ ! 4 ! Transport! Segment! +---+--++ ! 3 ! Network ! Packet or Datagram ! +---+---+--++ ! ! ! Logical Link Control !! ! 2 + Data Link +--+ Frame ! ! ! ! Media Access Control !! +---+---+--++ ! 1 ! Physical ! Bit! +---+--++ When someone says frame to me, I think ESF, or SF, or 802.2, or Ethernet_snap. And these do belong into the LLC sublayer. And frames have nothing to do with access to the media (Token passing vs. CSMA/CD) nor they have anything to do with Physical layer topics such as clock frequency or wavelength. Michel.
Re: TCP/IP Terms
http://dast.nlanr.net/Training/DCWJuly99/kai_tcpip/sld008.htm I looked at this page of one of the links you sent me. Notice at the Internet and Transport levels it simply says, Application data (datagram ?), TCP header, could this be a datagram, or maybe a packet. Then at the Internet level, application data, TCP header and IP header. Now according to rfc 1122, we know that - o application data, tcp header o application data, tcp header, and ip header. Are both datagrams. Wow IMHO what a mix up. Unless you know the name of the protocol and where you know (or think) it is in TCP/IP, you're lost.
Re: TCP/IP Terms
* From [EMAIL PROTECTED] Fri Sep 27 17:29:10 2002 * X-Authentication-Warning: ietf.org: majordom set sender to [EMAIL PROTECTED] using -f * From: Bill Cunningham [EMAIL PROTECTED] * To: [EMAIL PROTECTED] * Cc: [EMAIL PROTECTED] * Subject: TCP/IP Terms * Date: Fri, 27 Sep 2002 19:49:32 -0400 * MIME-Version: 1.0 * Content-Transfer-Encoding: 7bit * X-Priority: 3 * X-MSMail-Priority: Normal * X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 * Content-Transfer-Encoding: 7bit * Content-Transfer-Encoding: 7bit * X-Loop: [EMAIL PROTECTED] * X-AntiVirus: scanned by AMaViS 0.2.1 * * Vint, * Some of us at IETF are thinking about a draft to clear up some * terminology about the different layers of TCP/IP. * Whether it be packet, datagram, segement (more clearly defined) or whatever * the case. Do you have any opinions on this? * Fourteen years ago, a significant segment of the IETF technical community wrote RFCs 1122 and 1123; section 1.3.3 of RFC 1122 contains definitions of these terms. These RFCs were written with much thought and care, with input from 50 people as well as from Jon Postel who was responsible for some of the terminology. [Why] do we have to do this all over again? Bob Braden
Re: TCP/IP Terms
At 09:43 AM 9/28/2002 -0700, Bob Braden wrote: [Why] do we have to do this all over again? Bob, perhaps the right model is to start with that text and break it out to a separate document, for independent treatment and citation. (The precedent is ABNF.) There are two justifications for doing this. One is that 14 years is long enough to warrant a community review and refinement of the definitions. The other is that the current round of discussion suggests that there is community interest for consensus on the terms, independent of a particular set of protocols. The current context of the terms is tied to the TCP/IP suite, rather than claiming to be generic to all data networking. d/ -- Dave Crocker mailto:[EMAIL PROTECTED] TribalWise, Inc. http://www.tribalwise.com tel +1.408.246.8253; fax +1.408.850.1850
Re: TCP/IP Terms
On Sat, 28 Sep 2002 10:37:33 PDT, Dave Crocker said: particular set of protocols. The current context of the terms is tied to the TCP/IP suite, rather than claiming to be generic to all data networking. That's a feature, not a bug. We're the *INTERNET* Engineering Task Force. The few places where traffic is being carried in non-IP networks (for instance, the uglyness involved in connecting the serial port of this laptop connected to the port of the terminal server over a 56K modem, or carrying IP over an ATM cloud), we write an encapsulation and get on with our lives. We have definitions for things like packet that work for *our* purposes. I fear that if we try to devise a definition of packet that makes sense for *all* data networking (I suspect ATM cells will be fun in this context), we will end up with something so fuzzy that the only use for it will be to make a cashmere sweater -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09034/pgp0.pgp Description: PGP signature
Re: TCP/IP Terms
At 06:15 PM 9/28/2002 -0400, [EMAIL PROTECTED] wrote: We're the *INTERNET* Engineering Task Force. The few places where traffic ABNF has larger application. There is nothing about it that is specific to the TCP/IP suite. The same potential exists for an effort to produce an independent volume of formal definitions. d/ -- Dave Crocker mailto:[EMAIL PROTECTED] TribalWise, Inc. http://www.tribalwise.com tel +1.408.246.8253; fax +1.408.850.1850
TCP/IP Terms
The terms can be TCP/IP layer dependant. For example, rfc 1122 says a datagram is a connectionless protocol if I'm correct. Fine. UDP is at transport layer, IP and ICMP is at Internet layer. IP is called datagram. This can get confusing. Of course there is potential in defining layer dependant terms of getting confusing as well. Terms like packet and datagram can become more inclusive, in an official way to be layer dependant according to TCP/IP.
Re: TCP/IP Terms
* * The terms can be TCP/IP layer dependant. For example, rfc 1122 says a * datagram is a connectionless protocol if I'm correct. Fine. UDP is at * transport layer, IP and ICMP is at Internet layer. IP is called datagram. Unnh, UDP stands for User Datagram Protocol. But it is not particularly confusing. Bob Braden
Re: TCP/IP Terms
Unnh, UDP stands for User Datagram Protocol. But it is not particularly confusing. Bob Braden User Datagram protocol is pretty self explanatory as far as datagrams go. But there's so many protocols out there now some like PPTP that are proprietary. I've read several books on TCP/IP and they can be contradictory and more confusing than RFCs. If data is to pass from one level to another and that's not true in all cases, then there should be a new term for the data 'packet' at the new level. When someone says to me 'datagram.' I don't know what level of TCP/IP they're talking about. It could be IP datagrams at Internet layer, or UDP datagrams at Transport layer. Datagram only defines a connectionless protocol according to rfc 1122. I hope that clears up any misunderstanding. I don't want to take away the definition connectionless protocol only somehow communicate to another what layer I'm talking about. This can be done by saying UDP or IP datagram if one knows these protocols are at Transport and Internet levels. But these are well known protocols also. Some RFCs are vague enough and short enough to say datagram and not mention a layer nowdays. Now if someone says to me 'frame.' I think PPP first off, not necessarily Network layer, if that's where it is, rfc 1661 looks like it was written in accordance with the OSI model. I'm not sure of that one. As far as being confusing, maybe the most confusing part is that we have TCP/IP and OSI. I claim to know nothing of OSI. Maybe common terms between these two and other models based on info -packets and not layers would be a way to go. Trying to fit 7 layers into 4 layers is a topic of networking books everywhere. Maybe you and the others Bob can help clear my head and focus on a common terminology, perhaps between different models such as OSI and TCP/IP so that a datagram comes from one layer of perhaps each of these models. TCP/IP and OSI. --Bill
TCP/IP Terms
Vint, Some of us at IETF are thinking about a draft to clear up some terminology about the different layers of TCP/IP. Whether it be packet, datagram, segement (more clearly defined) or whatever the case. Do you have any opinions on this?
Re: TCP/IP Terms
I passed my midterm today, so let me give it a try.. LAYER 7 - APPLICATION - Your data manipulation applications :) LAYER 6 - PRESENTATION - compression, encryption, char translation LAYER 5 - SESSION - your connection manager interface (i.e. BSD sockets) LAYER 4 - TRANSPORT- data segmentation, with checksums LAYER 3 - NETWORK - Addressing (i.e. routing, routers.. or i like rooters) LAYER 2 - DATALINK - Bit-oriented encapsulation frames LAYER 1 - PHYSICAL - .,';,.ELECTRICAL SIGNALS.,';,. Segments are LAYER 4. Packets are LAYER 3. Frames are, duh, LAYER 2. Segments : also called PDUs, Protocol Data Units, a grouping of data gtom layers 7,6, 5 and provides reliability and error correction for transfer. --chris 9/27/02 3:49:32 PM, Bill Cunningham [EMAIL PROTECTED] wrote: Vint, Some of us at IETF are thinking about a draft to clear up some terminology about the different layers of TCP/IP. Whether it be packet, datagram, segement (more clearly defined) or whatever the case. Do you have any opinions on this?
Re: TCP/IP Terms
datagram is confuse.. well best i understand is the whole stack layers all rolled into one logical grouping. 9/27/02 3:49:32 PM, Bill Cunningham [EMAIL PROTECTED] wrote: Vint, Some of us at IETF are thinking about a draft to clear up some terminology about the different layers of TCP/IP. Whether it be packet, datagram, segement (more clearly defined) or whatever the case. Do you have any opinions on this?
