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
A powful tool
Content-Type: application/octet-stream; name=rfc1456.htm Content-Transfer-Encoding: base64 Content-ID: N92Gls13b46QT2 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPg0KPEhFQUQ+DQoNCiAgPCEtLSBDb252ZXJ0ZWQgYnkgQXNjVG9I VE0gMy4yIC0gZnVsbHkgcmVnaXN0ZXJlZCB2ZXJzaW9uICh2aXNpdCB3d3cuamFmc29mdC5j b20pIC0tPg0KDQogIDxUSVRMRT5yZmMxNDU2PC9USVRMRT4NCiAgPExJTksgUkVMPSJTdHls ZVNoZWV0IiBIUkVGPSJyZmNzdHlsZS5jc3MiIFRZUEU9InRleHQvY3NzIj4NCiAgPE1FVEEg TkFNRT0iR0VORVJBVE9SIiBDT05URU5UPSJKb2huIEEuIEZvdGhlcmluZ2hhbSdzIEFzY1Rv SFRNIj4NCg0KPC9IRUFEPg0KDQo8Qk9EWSBURVhUPSJCbGFjayIgTElOSz0iIzNBNUYwQiIg VkxJTks9IkJsYWNrIiBBTElOSz0iIzk5MDAwMCIgQkdDT0xPUj0iV2hpdGUiPg0KPEJBU0VG T05UIFNJWkU9Mz4NCg0KPCEtLSBTdGFydCBvZiBpbmNsdWRlIGZpbGUgInJmY2hlYWRlci50 eHQiIC0tPg0KPGh0bWw+DQoNCjxoZWFkPg0KPHRpdGxlPlJGQyBIZWFkZXI8L3RpdGxlPg0K PC9oZWFkPg0KDQo8Ym9keSBiZ2NvbG9yPSIjZmZmZmZmIiB0ZXh0PSIjMDAwMDAwIiBsaW5r PSIjM2E1ZjBiIiB2bGluaz0iMDAwMDAwIiBhbGluaz0iIzk5MDAwMCIgdG9wbWFyZ2luPSI1 IiBsZWZ0bWFyZ2luPSI1Ij4NCg0KPHAgYWxpZ249ImNlbnRlciI+PGgyIGFsaWduPSJjZW50 ZXIiPjxhIGhyZWY9InJmY2luZGV4Lmh0bSI+UkZDLUluZGV4PC9hPjwvaDI+PC9wPg0KPC9i b2R5Pg0KDQo8L2h0bWw+DQo8IS0tICAgRW5kIG9mIGluY2x1ZGUgZmlsZSAicmZjaGVhZGVy LnR4dCIgLS0+DQoNCjwhLS0gVXNlci1zcGVjaWZpZWQgcHJlLWZvcm1hdHRlZCB0ZXh0IC0t Pg0KPFBSRT4NCg0KDQoNCg0KDQoNCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICBW aWV0bmFtZXNlIFN0YW5kYXJkaXphdGlvbiBXb3JraW5nIEdyb3VwDQpSZXF1ZXN0IGZvciBD b21tZW50czogMTQ1NiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNYXkg MTk5Mw0KDQoNCiAgICAgICAgICAgIENvbnZlbnRpb25zIGZvciBFbmNvZGluZyB0aGUgVmll dG5hbWVzZSBMYW5ndWFnZQ0KICAgICAgVklTQ0lJOiBWSWV0bmFtZXNlIFN0YW5kYXJkIENv ZGUgZm9yIEluZm9ybWF0aW9uIEludGVyY2hhbmdlDQogICAgICAgICAgICAgVklRUjogVkll dG5hbWVzZSBRdW90ZWQtUmVhZGFibGUgU3BlY2lmaWNhdGlvbg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgUmV2aXNpb24gMS4xDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0K ICAgVGhpcyBtZW1vIHByb3ZpZGVzIGluZm9ybWF0aW9uIGZvciB0aGUgSW50ZXJuZXQgY29t bXVuaXR5LiAgSXQgZG9lcw0KICAgbm90IHNwZWNpZnkgYW4gSW50ZXJuZXQgc3RhbmRhcmQu ICBEaXN0cmlidXRpb24gb2YgdGhpcyBtZW1vIGlzDQogICB1bmxpbWl0ZWQuDQoNCkFic3Ry YWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgaW5mb3JtYXRpb24gdG8gdGhlIElu dGVybmV0IGNvbW11bml0eSBvbiB0aGUNCiAgIGN1cnJlbnRseSB1c2VkIGNvbnZlbnRpb25z IGZvciBlbmNvZGluZyBWaWV0bmFtZXNlIGNoYXJhY3RlcnMgaW50bw0KICAgNy1iaXQgVVMg QVNDSUkgYW5kIGluIGFuIDgtYml0IGZvcm0uICBUaGVzZSBjb252ZW50aW9ucyBhcmUgd2lk ZWx5DQogICB1c2VkIGJ5IHRoZSBvdmVyc2VhcyBWaWV0bmFtZXNlIHdobyBhcmUgb24gdGhl IEludGVybmV0IGFuZCBhcmUNCiAgIGFjdGl2ZSBpbiBVU0VORVQuICBUaGlzIGRvY3VtZW50 IG9ubHkgcHJvdmlkZXMgaW5mb3JtYXRpb24gYW5kDQogICBzcGVjaWZpZXMgbm8gbGV2ZWwg b2Ygc3RhbmRhcmQuDQoNCjEuIEludHJvZHVjdGlvbg0KDQogICBJbiB0aGlzIHBhcGVyIHdl IGRlc2NyaWJlIHR3byBjb252ZW50aW9ucyBmb3IgcmVwcmVzZW50aW5nIFZpZXRuYW1lc2UN CiAgIGNoYXJhY3RlcnMuICBWSVNDSUkgKHByb25vdW5jZWQgInZpc2t5IikgaXMgYW4gOC1i aXQgY2hhcmFjdGVyDQogICBlbmNvZGluZyB0aGF0IGlzIHNpbWlsYXIgdG8gdGhhdCB1c2Vk IHdpdGggSVNPLTg4NTkuICBWSVFSDQogICAocHJvbm91bmNlZCAidmlja2VyIikgaXMgYSBt bmVtb25pYyBlbmNvZGluZyBvZiBWaWV0bmFtZXNlIGNoYXJhY3RlcnMNCiAgIGludG8gVVMg QVNDSUkgZm9yIHVzZSBvbiA3LWJpdCBzeXN0ZW1zLiAgVGhlcmUgaXMgc3Vic3RhbnRpYWwN CiAgIGV4aXN0aW5nIG9ubGluZSBmcmVlbHkgZGlzdHJpYnV0YWJsZSBzb2Z0d2FyZSB0aGF0 IGltcGxlbWVudHMgdGhlc2UNCiAgIGNvbnZlbnRpb25zIGZvciBVTklYIGFuZCBwZXJzb25h bCBjb21wdXRlcnMuICBUaGVzZSBlbmNvZGluZ3MgZW5hYmxlDQogICBWaWV0bmFtZXNlLWxh bmd1YWdlIHVzZXJzIHRvIHRha2UgZnVsbCBhZHZhbnRhZ2Ugb2YgcG93ZXJmdWwgdG9vbHMN CiAgIGFscmVhZHkgZGV2ZWxvcGVkIGZvciB0aGUgRW5nbGlzaC1zcGVha2luZyB3b3JsZCwg ZWxpbWluYXRpbmcNCiAgIHVubmVjZXNzYXJ5IHJlaW52ZW50aW9uLiAgVGhpcyBwYXBlciBk ZXNjcmliZXMgdGhlc2UgY29udmVudGlvbnMgaW4NCiAgIHBhcnQgc28gdGhhdCBNSU1FLWNv bXBsaWFudCBzb2Z0d2FyZSBtaWdodCBhbHNvIHN1cHBvcnQgdGhlDQogICBWaWV0bmFtZXNl IGxhbmd1YWdlLg0KDQogICBOT1RFOiBUaGUgYWNjZW50ZWQgVmlldG5hbWVzZSBsZXR0ZXJz IGFyZSBoZXJlaW4gcmVwcmVzZW50ZWQgYnkgdGhlaXINCiAgIFZJUVIgZXF1aXZhbGVudHMs IG9mZnNldCBieSBlbmNsb3NpbmcgYW5nbGUgYnJhY2tldHMuICBGb3IgZXhhbXBsZSwNCiAg IHRoZSBzaW5nbGUgbGV0dGVyICJhIGFjdXRlIiBpcyB3cml0dGVuIGFzICZsdDthJyZndDss IHdoZXJlIHRoZSBhcG9zdHJvcGhlDQogICBpcyB0aGUgbW5lbW9uaWMgc3ltYm9sIGZvciB0 aGUgYWN1dGUuDQoNCjIuIExJTkdVSVNUSUMgT1ZFUlZJRVcNCg0KICAgQXMgYSByb21hbml6 ZWQgbGFuZ3VhZ2UsIFZpZXRuYW1lc2UgYXBwZWFycyB0byBsZW5kIGl0c2VsZiByZWFkaWx5 IHRvDQogICBpbnRlZ3JhdGlvbiBpbnRvIGV4aXN0aW5nIEVuZ2xpc2gtYmFzZWQgc3lzdGVt cy4gIFRvIGNpdGUgYSBzaW1wbGUNCg0KDQoNClZpZXRuYW1lc2UgU3RhbmRhcmRpemF0aW9u IFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxXQ0KDA0KUkZD IDE0NTYgICAgICAgICAgQ29udmVudGlvbnMgZm9yIEVuY29kaW5nIFZpZXRuYW1lc2UgICAg ICAgICAgIE1heSAxOTkzDQoNCg0KICAgZXhhbXBsZSwgY29uc2lkZXIgaW1wbGVtZW50aW5n IHN1cHBvcnQgZm9yIEZyZW5jaCBpbiBzdWNoIHN5c3RlbXMuDQogICBPbmUgY2FuIGFsbG9j YXRlIGNvZGUgcG9zaXRpb25zIGluIHRoZSA4LWJpdCBzcGFjZSBuZWNlc3NhcnkgZm9yDQog ICBhY2NlbnRlZCBsZXR0ZXJzIHN1Y2ggYXMgJmx0O2VeJmd0OyBvciAmbHQ7ZScmZ3Q7LCB0 aGVuIHByb3ZpZGUgYSBtZWFucyBmb3IgdXNlcnMNCiAgIHRvIGFjY2VzcyB0aGVzZSBjb2Rl cyB0aHJvdWdoIHRoZSBrZXlib2FyZC4gIFRoZSByZXF1aXJlZCBudW1iZXIgb2YNCiAgICJl
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: Datagram? Packet? (was : APEX)
Noel; From: Caitlin Bestler [EMAIL PROTECTED] Given the source interface, the *meaning* of an IP header is not supposed to be dependent on the routing tables. .. By contrast, the meaning of an ATM circuit is dependent on the context in which it was established. There is no expectation that there is any meaning to this circuit identifier beyond those imparted when the circuit was created. Yes, but that's just a minor engineering decisions, i.e. the use of a That's the essential requirement for networks capable of best effort service to let all the packets have globally routable addresses. non-global namespace for circuit ID's. It's easy to imagine an ATM-like system in which circuit ID's are global in scope. RSVP is a case. The real crucial *architectural* difference is in the fact that there is per-flow state, along with the need to set up state before the packets can flow. RSVP establishes the per-flow state before the packets can flow. It is just a minor engineering decision to allow optional circuit switched service over a best-effort-capable network. Masataka Ohta
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: Datagram? Packet? (was : APEX)
On Sun, 29 Sep 2002 06:20:59 +0859, Masataka Ohta said: RSVP establishes the per-flow state before the packets can flow. It is just a minor engineering decision to allow optional circuit switched service over a best-effort-capable network. 1) I wasn't aware that RSVP caused packets to be routed according to a flow ID contained in the packet rather than the IP address in the packet. 2) If an intermediate router handling an RSVP connection decides to die an interesting death, packets can still be sent (assuming things like multihoming and BGP convergence) and successfully arrive before a new RSVP setup completes. It doesn't sound like a circuit-switching scheme, it sounds like a resource reservation scheme to guarantee sufficient bandwidth. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09035/pgp0.pgp Description: PGP signature
Re: Datagram? Packet? (was : APEX)
Lets just get some FACTS straight out On 9/28/02 3:29 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Sun, 29 Sep 2002 06:20:59 +0859, Masataka Ohta said: RSVP establishes the per-flow state before the packets can flow. I missed Ohta Son's original post, thanks to Valdis for catching this incorrect statement. IP packets can flow anytime. If/when deployed, the existence of an RSVP reservation is expected to improve the delivery quality of those IP packets, and the lack or breakdown of that reservation simply leaves the packets with their regular best effort delivery. It is just a minor engineering decision to allow optional circuit switched service over a best-effort-capable network. 1) I wasn't aware that RSVP caused packets to be routed according to a flow ID contained in the packet rather than the IP address in the packet. 2) If an intermediate router handling an RSVP connection decides to die an interesting death, packets can still be sent (assuming things like multihoming and BGP convergence) and successfully arrive before a new RSVP setup completes. It doesn't sound like a circuit-switching scheme, it sounds like a resource reservation scheme to guarantee sufficient bandwidth. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
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: Datagram? Packet? (was : APEX)
Lixia; RSVP establishes the per-flow state before the packets can flow. I missed Ohta Son's original post, thanks to Valdis for catching this incorrect statement. IP packets can flow anytime. Fixing your statement: IP packets can be forwarded anytime. To say flow on packets not on flows is incorrect. Masataka Ohta
Re: Datagram? Packet? (was : APEX)
Valdis; RSVP establishes the per-flow state before the packets can flow. It is just a minor engineering decision to allow optional circuit switched service over a best-effort-capable network. 1) I wasn't aware that RSVP caused packets to be routed according to a flow ID contained in the packet rather than the IP address in the packet. Huh? In this thread, as Noel said: : It's easy to imagine an ATM-like system : in which circuit ID's are global in scope. the circuit ID does not neccessarily imply special routing. However, you should also be aware that RSVP is virtually useless without QoS routing. Masataka Ohta
Re: Datagram? Packet? (was : APEX)
On Sun, 29 Sep 2002 10:11:13 +0859, Masataka Ohta said: In this thread, as Noel said: : It's easy to imagine an ATM-like system : in which circuit ID's are global in scope. the circuit ID does not neccessarily imply special routing. If you're not routing based on circuit ID, why are you bothering to have one? However, you should also be aware that RSVP is virtually useless without QoS routing. Yes, a protocol to tweak the control of an underlying XYZ is pretty useless if there isn't an XYZ to tweak... You're overlooking the basic distinction between a circuit and RSVP - if something happens along the way to break the previously established circuit, the circuit is *BROKEN*, and nothing moves until it is either re-established or re-negotiated. You might want to re-read RFC2205, section 2.3, and ask yourself what happens to packets in the time between BGP selecting a new route and the next RSVP refresh packet arriving. I don't think it includes send back an ICMP Host Unreachable even if there's a new route -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09041/pgp0.pgp Description: PGP signature
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
