RE: PPP RFCs
Start with 1661 - PPP 1331 The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links 1332 IPCP (N/w Control Protocol) 1333 PPP Link Quality Monitoring 1334 PPP Authentication Protocols. 1994 PPP Challenge Handshake Authentication Protocol (CHAP) Hope this helps. Thanks, Srivatsan -Original Message- From: Bill Cunningham [mailto:[EMAIL PROTECTED]] Sent: Thu 6/27/2002 1:10 AM To: [EMAIL PROTECTED] Cc: Subject:PPP RFCs Are there RFC's or drafts on the various LCP's that PPP uses or the Network Control Protocol of PPP?
RE: PPP RFCs
Start with RFC 1661, which obsoletes 1548. -Original Message- From: Bill Cunningham [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 26, 2002 9:40 AM To: [EMAIL PROTECTED] Subject: PPP RFCs Are there RFC's or drafts on the various LCP's that PPP uses or the Network Control Protocol of PPP?
Re: PPP RFCs
* From [EMAIL PROTECTED] Wed Jun 26 12:55:35 2002 * X-Authentication-Warning: ietf.org: majordom set sender to [EMAIL PROTECTED] using -f * From: Bill Cunningham [EMAIL PROTECTED] * To: [EMAIL PROTECTED] * Subject: PPP RFCs * Date: Wed, 26 Jun 2002 15:40:23 -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 * * Are there RFC's or drafts on the various LCP's that PPP uses or the Network * Control Protocol of PPP? * We suggest that you go to the RFC Editor web page and search for PPP. You will get 81 hits. RFC Editor
Re: PPP RFCs
You know, I have been wondering about cable modems and their analog usage...:-) - Original Message - From: Lloyd Wood [EMAIL PROTECTED] To: Bill Cunningham [EMAIL PROTECTED] Cc: ietf [EMAIL PROTECTED] Sent: Wednesday, June 26, 2002 4:41 PM Subject: Re: PPP RFCs On Wed, 26 Jun 2002, Bill Cunningham wrote: Are there RFC's or drafts on the various LCP's that PPP uses or the Network Control Protocol of PPP? Yes. You're quite capable of finding them, you know. L. Hoping to forestall another 'modems' thread. http://www.ee.surrey.ac.uk/Personal/L.Wood/[EMAIL PROTECTED]
RE: PPP
* switching but a rose by any other name ...). So all of these, including * PPP, exist at layers 1-2 in the TCP/IP model (link, network, internetwork, * transport, application) ... * (catching up on old email) Note that this is not the common-accepted definition of the Internet layering model. The Host Requirements working grouip went through this in detail in 1988, and agreed on the definitions in section 1.1.3 of RFC 1122. Strictly speaking, there IS no network layer in the Internet model, although we commonly tolerate calling the Internet layer (layer 3) the network layer. Layer 2 is the link layer. Bob Braden
Re: PPP
Brian Lloyd wrote: At 11:59 PM 3/6/2002, you wrote: sigh It has been many years since I argued this with Karl Fox back when he chaired the L2TP WG. Karl chaired only the pppext WG. Then at the time L2TP or the precursor discussions were done within the PPPEXT WG because the discussion was with Karl. At that time he agreed but also said that there was too much water under the bridge to fix L2TP at that time so it was going to go forward in its subtlely-broken form. I haven't looked at it since then. I don't even remember the lexicon so I will undoubtedly sound uninformed. The LCP negotiation should take place with the L2TP equivalent of the NAS. That is independent of anything else that happens and nothing associated with that needs to be communicated to the edge device at the target network. The authentication phase then takes place so you can do authorization and configuration. That would have been nice, but, the requirements were that it be possible for user authorization be completed at the LNS (the edge device at the target network), and at the LAC (NAS). Thank you for reminding me. LNS and LAC were the terms I was looking for. WRT authentication, there is no reason not to do it in both places. Let the protocol carry the information. In addition, we could not require the user to enter a username and password twice. You simply had to be able to drop in L2TP, and everything look the same as it did before to the end user. I agree that is the more desirable scenario. Once that is complete you can do the MLPPP and NCP negotiation(s) because then and only then do you know what the end system is authorized to do. Yup, that would have been nicer. Yes, it would. But MLPPP is negotiated during LCP, you say! Right. That is broken and I helped make it broken and, in retrospect, I am *really* sorry I did. That's OK, we'll forgive you ;-) Thank you. It may seem silly but that has really bugged me for a number of years. I hate the thought of having done flawed work. Barring redesign of PPP, getting around the wrong things being located in the LCP negotiation would have been made a little easier if we had been allowed to go through LCP negotiation twice. So, you could have LCP negotiated at the LAC, But you wouldn't have needed to do LCP negotiation twice. The LAC negotiates LCP because that is the terminus of the link. Not just that, the LAC may also need to get authentication information from the user so that it can know which LNS to forward to. The LAC communicates the options negotiated back to the LNS. That's what we do now. Please read section 4.4.5 of RFC2661. Remember, the LCP options negotiate only indicate what the client is willing to accept therefore it doesn't really matter what it negotiates. It is just there to prevent its peer from sending something it can't handle. But, if the LNS, say, want's to do some different authentication... Say, PAP with an OTP but the LAC negotiated CHAP, then, well... We have to start over PPP LCP, which should be OK except that it used to break a lot of PPP clients. forward any necessary link parameters to the LNS so that it could set them correctly during LCP round 2, and then renegotiate LCP at the LNS to get things like MLPPP and perhaps authentication type which should have been designed into the negotiation process later. Right. That is the crux of the problem. But -- and here is the point about broken PPP stacks -- at the time there were a lot of PPP stacks which would simply roll over and die if you tried to reneogtiate LCP after you had already begun (yes, in great violation to what it says in RFC 1661). This wasn't discovered until L2TP came along because before that, you really didn't see LCP renegotiation occur very much. sigh But we did know. The argument was that it took too long to negotiate PPP as it was so anything we did to speed it up was necessary. I have kicked myself for caving in to that argument for many years now. Then let me give you a collective kick from all of the l2tp developers out there ;-) I thought it was just a bug. I remember telling Robert Webster about this little problem at a pacbell bakeoff many years ago. His jaw dropped, and he went back and made an on-the-fly bugfix for it and afterwards it worked great. Note that Robert worked at Shiva then, and maintained code for the PPP stack that for a while was the original code base for much of the dialup client industry (e.g. Windows, OS/2, and probably some others...). But, it was way too late as there were so many clients in the field with this bug. So, we ended up with Proxy LCP and Proxy Authentication like you see them today. I know: add more ugliness in order to deal with other ugliness. I preferred the old days where people found problems, fixed them, and the fixes then found their ways into new versions,
Re: PPP
That top-layer-calls-next-layer etc ad-nauseam model seems to have been one of the original ideas for how to implement a stack. Actual current implementations do all kinds of wierd stuff, but mostly pass around accumulating collections of buffers; so the payload buffer doesn't get copied to accomodate each new header, instead the kernel has a second buffer to contain the header (and later layers can add more). What gets passed around (by way of various queues and internal plumbing schemes) is a structure of pointers to pieces of packet, which gets put together on transmission, often by the DMA engine in the device or by the device driver. The layering is just a conceptual model for the logic of what is going on, and has no resemblance to the flow of control in a typical actual implementation. There are simple educational implementations that follow the layering fairly closely, and they are interesting to read but tend not to be practical for high performance applications. --On Tuesday, 5 March 2002 11:02 p.m. -0800 Christopher Evans [EMAIL PROTECTED] wrote: Here is a question that will tax your synapes to bursting point! How is PPP and TCP/IP libs wired together? Like, DO I (OSI 8) call TCP and it calls IP and down the chain till it spills over and gets real physical (OSI 1)? I am confused. At 10:02 AM 3/5/02 -0500, you wrote: whoa, it's in the TCP/IP suite, it's not. So let me get this straight. TCP and UDP are part of IP. TCP provides error sum UDP doesn't and is therefore faster than TCP. They are encapsulated in IP, which is put into the data bitstream of a PPP frame. Layer 1 is the physical layer, are bitstreams sent at that level. BTW I have 56K dial-up no ISDN or DSL. - Original Message -
Re: PPP
At 11:59 PM 3/6/2002, you wrote: sigh It has been many years since I argued this with Karl Fox back when he chaired the L2TP WG. Karl chaired only the pppext WG. Then at the time L2TP or the precursor discussions were done within the PPPEXT WG because the discussion was with Karl. At that time he agreed but also said that there was too much water under the bridge to fix L2TP at that time so it was going to go forward in its subtlely-broken form. I haven't looked at it since then. I don't even remember the lexicon so I will undoubtedly sound uninformed. The LCP negotiation should take place with the L2TP equivalent of the NAS. That is independent of anything else that happens and nothing associated with that needs to be communicated to the edge device at the target network. The authentication phase then takes place so you can do authorization and configuration. That would have been nice, but, the requirements were that it be possible for user authorization be completed at the LNS (the edge device at the target network), and at the LAC (NAS). Thank you for reminding me. LNS and LAC were the terms I was looking for. WRT authentication, there is no reason not to do it in both places. Let the protocol carry the information. In addition, we could not require the user to enter a username and password twice. You simply had to be able to drop in L2TP, and everything look the same as it did before to the end user. I agree that is the more desirable scenario. Once that is complete you can do the MLPPP and NCP negotiation(s) because then and only then do you know what the end system is authorized to do. Yup, that would have been nicer. Yes, it would. But MLPPP is negotiated during LCP, you say! Right. That is broken and I helped make it broken and, in retrospect, I am *really* sorry I did. That's OK, we'll forgive you ;-) Thank you. It may seem silly but that has really bugged me for a number of years. I hate the thought of having done flawed work. Barring redesign of PPP, getting around the wrong things being located in the LCP negotiation would have been made a little easier if we had been allowed to go through LCP negotiation twice. So, you could have LCP negotiated at the LAC, But you wouldn't have needed to do LCP negotiation twice. The LAC negotiates LCP because that is the terminus of the link. The LAC communicates the options negotiated back to the LNS. Remember, the LCP options negotiate only indicate what the client is willing to accept therefore it doesn't really matter what it negotiates. It is just there to prevent its peer from sending something it can't handle. forward any necessary link parameters to the LNS so that it could set them correctly during LCP round 2, and then renegotiate LCP at the LNS to get things like MLPPP and perhaps authentication type which should have been designed into the negotiation process later. Right. That is the crux of the problem. But -- and here is the point about broken PPP stacks -- at the time there were a lot of PPP stacks which would simply roll over and die if you tried to reneogtiate LCP after you had already begun (yes, in great violation to what it says in RFC 1661). This wasn't discovered until L2TP came along because before that, you really didn't see LCP renegotiation occur very much. sigh But we did know. The argument was that it took too long to negotiate PPP as it was so anything we did to speed it up was necessary. I have kicked myself for caving in to that argument for many years now. But, it was way too late as there were so many clients in the field with this bug. So, we ended up with Proxy LCP and Proxy Authentication like you see them today. I know: add more ugliness in order to deal with other ugliness. I preferred the old days where people found problems, fixed them, and the fixes then found their ways into new versions, usually with a backward-compatibility switch. I reject the argument, but we have lots of systems in the field; we can't fix them now. Engineers from Microsoft (among others but they come immediately to mind) has been known to use that argument. It is specious because they then turn around and reissue code on a regular basis to fix other bugs in their products. There's not much else you can do if you want to complete PPP negotiation at the LNS, but *start* it at the LAC so that you can get the @domain portion of the username to determine where to tunnel the user. Sigh... Yes, if we had thought about running PPP over IP from the beginning, things might have looked very different in general... A more seperate link layer negotiation would have been one of them. But, PPP isn't nearly as difficult as, say, TDM over IP ;-) This reared its ugly head when we started to do multilink PPP. The problem was *very* clear then. Pointing out that LCP and NCP were really completely separate protocols and represented different layers
Re: PPP
Brian Lloyd wrote: At 03:12 AM 3/4/2002, you wrote: I couldn't say it shorter and more clearly than Vint : PPP does NOT belong to the TCP/IP protocol suite. Other than it was designed for IP and the other stuff came along for the ride. PPP was a relatively early product of the IETF and specifically designed for IP. It's a Layer 2(*) protocol, intended to carry multiple Layer 3 protocols (like IP, IPX,...) over a point-to-point connection (like PSTN, ISDN,...). PPP succeeded SLIP by bringing extended features : SLIP could only encapsulate IP while PPP can encapsulate several protocols, PPP supports authentication while SLIP didn't, etc. Remember that TCP/IP only covers Layer 3 up to Layer 7 : it's designed to be implemented on existing lower layers (1 and 2) : LAN (Ethernet, Token Ring, Wireless Lans,...) or WAN (ISDN, ATM, Frame Relay,...). This is a common misconception. The lower layers (1 and 2) that you mention are often completely routable networks in and of themselves. You can even encapsulate IP within IP therefore IP is operating at layer 2 from that interpretation. Ethernet is regularly routed now (people call it switching but a rose by any other name ...). So all of these, including PPP, exist at layers 1-2 in the TCP/IP model (link, network, internetwork, transport, application) or layers 1-3b in the ISORM. This problem plagues developers working with PPP for the first time because they keep thinking in terms of PPP being only a link-layer protocol. If they would remember that PPP operates at the network layer then they would stop making stupid mistakes like a badly-designed L2TP. I don't see how classification of PPP as a layer 2, layer 3, or any other layer would have had an affect on how we designed L2TP (perhaps it would have affected the name of the protocol though). Layers aside, PPP was already deployed and it was pretty obvious what we wanted to do - make it run over IP without the installed base of PPP clients being made aware of it. How would you have done this that is substantially different than L2TP? (As an aside, of the list of obscene things we did have to do to make L2TP work, the worst were more due to badly implemented PPP stacks than anything else.) Tunneling, particularly L2 tunneling, is by its very definition a layer violation. The perfect world where this is not necessary or desirable does not exist beyond textbooks and laboratories. So here we are in the real world, tunneling not just PPP but a plethora of L2 or L2-like layers. - Mark E.T. (*) Those layers always refer to the OSI model. Think of a Layer 2 or 3 or 4 Switch : it doesn't depend on the protocol suite above, so we always refer to the vendor- technology- protocol-independent OSI reference model. I love watching people slavishly adhere to this or that model of layering. Layering is a convenience, not a religion. (Actually, I got that backwards.) With the widespread use of encapsulating one networking or internetworking protocol in another, the whole concept of rigid layering goes out the window. The cry of, its a network layer; its a link layer, should be right up there with, its a dessert topping; its a floor wax! --- The basic answer ends here --- Now a small yet technical recall : when data comes from an application to be transported on a physical medium (copper cable, fiber optics, radio waves, infra-red,...), on its way from Layer 7 to Layer 1 it reaches IP (Layer 3) ISO spent a lot of time trying to sell the 7-layer model and then didn't know how to backtrack when they discovered that there were really two network layers when you interconnect dissimilar networks using an internetworking protocol. ATM, FR, Ethernet, etc., are all routable layer-3 protocols in their own regard so they opted to break layer three into three sublayers. (It is really three layers by their reckoning but ISO already had so much invested in the ISO Seven Layer Reference Model [tm] that they couldn't really switch to the ISO Nine Layer Reference Model Formerly Known As The Seven Layer Reference Model [tm].) that encapsulates it in a datagram/packet and specifies the destination network+host address. Then it's forwarded to PPP (Layer 2) that encapsulates it in a frame and specifies the way bits are organized to travel through the physical medium. Then it's forwarded to some Layer 1 technology that converts the bits into a specific signal using a specific encoding scheme (V.90 on PSTN, I.430 on ISDN BRI,...) and finally reaches the physical medium to be physically transported through the network. To some extent you are right but your model needs to accommodate things like L2TP which tunnels traffic at layer 1|2 (depending on the model of the day) in a layer 4 (transport) protocol, or IP tunneled in IP. It is probably better to be able to keep the concept of duality in your mind, i.e. when you hold you tongue one way it
RE: PPP
WARNING : this answer will be very basic. My intention is not to go deep into the details but to give a short answer. Suppose you have an Operating System supporting TCP/IP, whatever applications you run. Suppose you have a modem and you use PPP to talk to a remote server. Then data coming from an application on your system will be transported by either TCP segments or UDP segments and use port numbers. Then those segments will be encapsulated into IP datagrams/packets and use IP addresses. Then those datagrams/packets will be encapsulated into PPP frames with no particular addresses (HDLC broadcast address will be used, always set to FF Hex - this is normal, since this is a point-to-point connection, so only 2 DCEs are communicating and there's no particular need for individual physical addressing, like in a multi-point shared Ethernet network). Then all those bits (frames actually represent organized groups of bits) will be converted into a particular signal (signal = electricity, light, micro-waves,...) using a particular encoding scheme (encoding scheme = AMI, Manchester, NRZI,...) able to be transported on a specific medium (medium = copper cable, fiber optics, air,...). That's it. I know, I know : this is a VERY basic answer. Some people will not forgive me for this, but when asked a basic question I can't do anything but give a basic answer. And BTW, when facing a very complex question, I don't even think of answering it. I gladly leave it up to a more competent guy to answer it. Then I sit down and listen, too. ;) -Original Message- From: Christopher Evans [mailto:[EMAIL PROTECTED]] Here is a question that will tax your synapes to bursting point! How is PPP and TCP/IP libs wired together? Like, DO I (OSI 8) call TCP and it calls IP and down the chain till it spills over and gets real physical (OSI 1)? I am confused. At 10:02 AM 3/5/02 -0500, you wrote: whoa, it's in the TCP/IP suite, it's not. So let me get this straight. TCP and UDP are part of IP. TCP provides error sum UDP doesn't and is therefore faster than TCP. They are encapsulated in IP, which is put into the data bitstream of a PPP frame. Layer 1 is the physical layer, are bitstreams sent at that level. BTW I have 56K dial-up no ISDN or DSL.
Re: PPP
At 02:42 AM 3/6/2002, you wrote: I don't see how classification of PPP as a layer 2, layer 3, or any other layer would have had an affect on how we designed L2TP (perhaps it would have affected the name of the protocol though). PPP actually consists of two distinct and separate sets of protocols. The LCP and its negotiation should be totally separate from the NCPs and their negotiation. Layers aside, PPP was already deployed and it was pretty obvious what we wanted to do - make it run over IP without the installed base of PPP clients being made aware of it. Do it right would not have changed that. How would you have done this that is substantially different than L2TP? (As an aside, of the list of obscene things we did have to do to make L2TP work, the worst were more due to badly implemented PPP stacks than anything else.) sigh It has been many years since I argued this with Karl Fox back when he chaired the L2TP WG. At that time he agreed but also said that there was too much water under the bridge to fix L2TP at that time so it was going to go forward in its subtlely-broken form. I haven't looked at it since then. I don't even remember the lexicon so I will undoubtedly sound uninformed. The LCP negotiation should take place with the L2TP equivalent of the NAS. That is independent of anything else that happens and nothing associated with that needs to be communicated to the edge device at the target network. The authentication phase then takes place so you can do authorization and configuration. Once that is complete you can do the MLPPP and NCP negotiation(s) because then and only then do you know what the end system is authorized to do. But MLPPP is negotiated during LCP, you say! Right. That is broken and I helped make it broken and, in retrospect, I am *really* sorry I did. So, as I said, this is water under the bridge and it isn't going to change. Any attempt to do so would be met with a barrage of but we have lots of systems in the field and this would break them arguments. Tunneling, particularly L2 tunneling, is by its very definition a layer violation. The perfect world where this is not necessary or desirable does not exist beyond textbooks and laboratories. So here we are in the real world, tunneling not just PPP but a plethora of L2 or L2-like layers. There is nothing wrong with tunneling per-se. In fact, it solves many problems. IMHO tunneling is a good thing. My comments had only to do with the fallacy of rigid layering, how many people don't really understand layering, and as a side issue, how PPP was really a suite of protocols at different layers and how that affects MLPPP and L2TP. YMMV Brian Lloyd [EMAIL PROTECTED] +1.530.676.1113 - voice +1.360.838.9669 - fax
Re: PPP
Brian Lloyd wrote: At 02:42 AM 3/6/2002, you wrote: I don't see how classification of PPP as a layer 2, layer 3, or any other layer would have had an affect on how we designed L2TP (perhaps it would have affected the name of the protocol though). PPP actually consists of two distinct and separate sets of protocols. The LCP and its negotiation should be totally separate from the NCPs and their negotiation. Layers aside, PPP was already deployed and it was pretty obvious what we wanted to do - make it run over IP without the installed base of PPP clients being made aware of it. Do it right would not have changed that. How would you have done this that is substantially different than L2TP? (As an aside, of the list of obscene things we did have to do to make L2TP work, the worst were more due to badly implemented PPP stacks than anything else.) sigh It has been many years since I argued this with Karl Fox back when he chaired the L2TP WG. Karl chaired only the pppext WG. At that time he agreed but also said that there was too much water under the bridge to fix L2TP at that time so it was going to go forward in its subtlely-broken form. I haven't looked at it since then. I don't even remember the lexicon so I will undoubtedly sound uninformed. The LCP negotiation should take place with the L2TP equivalent of the NAS. That is independent of anything else that happens and nothing associated with that needs to be communicated to the edge device at the target network. The authentication phase then takes place so you can do authorization and configuration. That would have been nice, but, the requirements were that it be possible for user authorization be completed at the LNS (the edge device at the target network), and at the LAC (NAS). In addition, we could not require the user to enter a username and password twice. You simply had to be able to drop in L2TP, and everything look the same as it did before to the end user. Once that is complete you can do the MLPPP and NCP negotiation(s) because then and only then do you know what the end system is authorized to do. Yup, that would have been nicer. But MLPPP is negotiated during LCP, you say! Right. That is broken and I helped make it broken and, in retrospect, I am *really* sorry I did. That's OK, we'll forgive you ;-) Barring redesign of PPP, getting around the wrong things being located in the LCP negotiation would have been made a little easier if we had been allowed to go through LCP negotiation twice. So, you could have LCP negotiated at the LAC, forward any necessary link parameters to the LNS so that it could set them correctly during LCP round 2, and then renegotiate LCP at the LNS to get things like MLPPP and perhaps authentication type which should have been designed into the negotiation process later. But -- and here is the point about broken PPP stacks -- at the time there were a lot of PPP stacks which would simply roll over and die if you tried to reneogtiate LCP after you had already begun (yes, in great violation to what it says in RFC 1661). This wasn't discovered until L2TP came along because before that, you really didn't see LCP renegotiation occur very much. But, it was way too late as there were so many clients in the field with this bug. So, we ended up with Proxy LCP and Proxy Authentication like you see them today. There's not much else you can do if you want to complete PPP negotiation at the LNS, but *start* it at the LAC so that you can get the @domain portion of the username to determine where to tunnel the user. Sigh... Yes, if we had thought about running PPP over IP from the beginning, things might have looked very different in general... A more seperate link layer negotiation would have been one of them. But, PPP isn't nearly as difficult as, say, TDM over IP ;-) There are even other bugs in the field we have had to code around with IPCP negotiation, and don't even get me started on ACCM mapping So, as I said, this is water under the bridge and it isn't going to change. Any attempt to do so would be met with a barrage of but we have lots of systems in the field and this would break them arguments. Right. The same argument that led to some of the choices we had to make in L2TP. Tunneling, particularly L2 tunneling, is by its very definition a layer violation. The perfect world where this is not necessary or desirable does not exist beyond textbooks and laboratories. So here we are in the real world, tunneling not just PPP but a plethora of L2 or L2-like layers. There is nothing wrong with tunneling per-se. In fact, it solves many problems. IMHO tunneling is a good thing. My comments had only to do with the fallacy of rigid layering, how many people don't really understand layering, and as a side issue, how PPP was really a suite of protocols at different layers and how that affects MLPPP and L2TP. Then we agree more than we
RE: PPP
Brian (and anyone concerned), I humbly think that before practicing literature, you need to learn ABC. I'm not a researcher, not a great expert, not a guru : I'm a trainer and a consultant. (Well actually I AM a guru... for my wife and my children! But this is out of purpose... ;) I don't intend to develop new complex things but to explain the existing ones and make them understandable. My answer tried to respect the same basic level as Bill's question's. That's my job, teaching LAN WAN technologies (and Datacom in general). My humble experience led me to teach such matters in different steps. First you teach ABC, then you teach grammar, then you can teach literature. Trying to teach literature without preparation can create confusion. Sorry if I shocked you with such a basic view on PPP compared to OSI and TCP/IP. [May I recommend 2 basic books? A World of Protocols and Computer Networks...] One can read that PPP is a suite - a combination of several protocols. Among them : BCP, CHAP, LCP, MLP, PAP, PPPoE,... But seriously, does Bill care? And also a different Network Control Protocol for each network layer supported. If I had to go deeply into such details, my answer would have been too long - and out of purpose. Hope you understand the need for basic ABC and don't only tolerate complex literature. :) -Original Message- From: Brian Lloyd [mailto:[EMAIL PROTECTED]] Sent: lundi 4 mars 2002 17:49 To: TOMSON ERIC Cc: [EMAIL PROTECTED] Subject: RE: PPP At 03:12 AM 3/4/2002, you wrote: I couldn't say it shorter and more clearly than Vint : PPP does NOT belong to the TCP/IP protocol suite. Other than it was designed for IP and the other stuff came along for the ride. PPP was a relatively early product of the IETF and specifically designed for IP. It's a Layer 2(*) protocol, intended to carry multiple Layer 3 protocols (like IP, IPX,...) over a point-to-point connection (like PSTN, ISDN,...). PPP succeeded SLIP by bringing extended features : SLIP could only encapsulate IP while PPP can encapsulate several protocols, PPP supports authentication while SLIP didn't, etc. Remember that TCP/IP only covers Layer 3 up to Layer 7 : it's designed to be implemented on existing lower layers (1 and 2) : LAN (Ethernet, Token Ring, Wireless Lans,...) or WAN (ISDN, ATM, Frame Relay,...). This is a common misconception. The lower layers (1 and 2) that you mention are often completely routable networks in and of themselves. You can even encapsulate IP within IP therefore IP is operating at layer 2 from that interpretation. Ethernet is regularly routed now (people call it switching but a rose by any other name ...). So all of these, including PPP, exist at layers 1-2 in the TCP/IP model (link, network, internetwork, transport, application) or layers 1-3b in the ISORM. This problem plagues developers working with PPP for the first time because they keep thinking in terms of PPP being only a link-layer protocol. If they would remember that PPP operates at the network layer then they would stop making stupid mistakes like a badly-designed L2TP. E.T. (*) Those layers always refer to the OSI model. Think of a Layer 2 or 3 or 4 Switch : it doesn't depend on the protocol suite above, so we always refer to the vendor- technology- protocol-independent OSI reference model. I love watching people slavishly adhere to this or that model of layering. Layering is a convenience, not a religion. (Actually, I got that backwards.) With the widespread use of encapsulating one networking or internetworking protocol in another, the whole concept of rigid layering goes out the window. The cry of, its a network layer; its a link layer, should be right up there with, its a dessert topping; its a floor wax! --- The basic answer ends here --- Now a small yet technical recall : when data comes from an application to be transported on a physical medium (copper cable, fiber optics, radio waves, infra-red,...), on its way from Layer 7 to Layer 1 it reaches IP (Layer 3) ISO spent a lot of time trying to sell the 7-layer model and then didn't know how to backtrack when they discovered that there were really two network layers when you interconnect dissimilar networks using an internetworking protocol. ATM, FR, Ethernet, etc., are all routable layer-3 protocols in their own regard so they opted to break layer three into three sublayers. (It is really three layers by their reckoning but ISO already had so much invested in the ISO Seven Layer Reference Model [tm] that they couldn't really switch to the ISO Nine Layer Reference Model Formerly Known As The Seven Layer Reference Model [tm].) that encapsulates it in a datagram/packet and specifies the destination network+host address. Then it's forwarded to PPP (Layer 2) that encapsulates it in a frame and specifies the way bits are organized to travel through the physical medium. Then it's forwarded to some Layer 1 technology
RE: PPP
At 03:12 AM 3/4/2002, you wrote: I couldn't say it shorter and more clearly than Vint : PPP does NOT belong to the TCP/IP protocol suite. Other than it was designed for IP and the other stuff came along for the ride. PPP was a relatively early product of the IETF and specifically designed for IP. It's a Layer 2(*) protocol, intended to carry multiple Layer 3 protocols (like IP, IPX,...) over a point-to-point connection (like PSTN, ISDN,...). PPP succeeded SLIP by bringing extended features : SLIP could only encapsulate IP while PPP can encapsulate several protocols, PPP supports authentication while SLIP didn't, etc. Remember that TCP/IP only covers Layer 3 up to Layer 7 : it's designed to be implemented on existing lower layers (1 and 2) : LAN (Ethernet, Token Ring, Wireless Lans,...) or WAN (ISDN, ATM, Frame Relay,...). This is a common misconception. The lower layers (1 and 2) that you mention are often completely routable networks in and of themselves. You can even encapsulate IP within IP therefore IP is operating at layer 2 from that interpretation. Ethernet is regularly routed now (people call it switching but a rose by any other name ...). So all of these, including PPP, exist at layers 1-2 in the TCP/IP model (link, network, internetwork, transport, application) or layers 1-3b in the ISORM. This problem plagues developers working with PPP for the first time because they keep thinking in terms of PPP being only a link-layer protocol. If they would remember that PPP operates at the network layer then they would stop making stupid mistakes like a badly-designed L2TP. E.T. (*) Those layers always refer to the OSI model. Think of a Layer 2 or 3 or 4 Switch : it doesn't depend on the protocol suite above, so we always refer to the vendor- technology- protocol-independent OSI reference model. I love watching people slavishly adhere to this or that model of layering. Layering is a convenience, not a religion. (Actually, I got that backwards.) With the widespread use of encapsulating one networking or internetworking protocol in another, the whole concept of rigid layering goes out the window. The cry of, its a network layer; its a link layer, should be right up there with, its a dessert topping; its a floor wax! --- The basic answer ends here --- Now a small yet technical recall : when data comes from an application to be transported on a physical medium (copper cable, fiber optics, radio waves, infra-red,...), on its way from Layer 7 to Layer 1 it reaches IP (Layer 3) ISO spent a lot of time trying to sell the 7-layer model and then didn't know how to backtrack when they discovered that there were really two network layers when you interconnect dissimilar networks using an internetworking protocol. ATM, FR, Ethernet, etc., are all routable layer-3 protocols in their own regard so they opted to break layer three into three sublayers. (It is really three layers by their reckoning but ISO already had so much invested in the ISO Seven Layer Reference Model [tm] that they couldn't really switch to the ISO Nine Layer Reference Model Formerly Known As The Seven Layer Reference Model [tm].) that encapsulates it in a datagram/packet and specifies the destination network+host address. Then it's forwarded to PPP (Layer 2) that encapsulates it in a frame and specifies the way bits are organized to travel through the physical medium. Then it's forwarded to some Layer 1 technology that converts the bits into a specific signal using a specific encoding scheme (V.90 on PSTN, I.430 on ISDN BRI,...) and finally reaches the physical medium to be physically transported through the network. To some extent you are right but your model needs to accommodate things like L2TP which tunnels traffic at layer 1|2 (depending on the model of the day) in a layer 4 (transport) protocol, or IP tunneled in IP. It is probably better to be able to keep the concept of duality in your mind, i.e. when you hold you tongue one way it looks like a link protocol but when you hold your tongue a different way it looks like a transport protocol. I suspect that something like this gave early physicists fits when they were faced with the duality of nature. So trying to be rigid in your categorization of any protocol is likely to cause you heartburn down the road (ask ISO). It is far better to understand where it makes sense to put interfaces and then perform the functions that need to be performed. --- The extended answer ends here --- -Original Message- From: vint cerf [mailto:[EMAIL PROTECTED]] IP is encapsulated in PPP for all practical purposes. PPP can support multiple protocols on a single point to point link in the same way ethernet can support multiple protocols And, no, as the above quote shows, Vint did not say that PPP does not belong to the TCP/IP protocol suite. He just says that PPP usually encapsulates/transports IP datagrams as its
Re: PPP
whoa, it's in the TCP/IP suite, it's not. So let me get this straight. TCP and UDP are part of IP. TCP provides error sum UDP doesn't and is therefore faster than TCP. They are encapsulated in IP, which is put into the data bitstream of a PPP frame. Layer 1 is the physical layer, are bitstreams sent at that level. BTW I have 56K dial-up no ISDN or DSL. - Original Message - From: Brian Lloyd [EMAIL PROTECTED] To: TOMSON ERIC [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, March 04, 2002 11:49 AM Subject: RE: PPP At 03:12 AM 3/4/2002, you wrote: I couldn't say it shorter and more clearly than Vint : PPP does NOT belong to the TCP/IP protocol suite. Other than it was designed for IP and the other stuff came along for the ride. PPP was a relatively early product of the IETF and specifically designed for IP. It's a Layer 2(*) protocol, intended to carry multiple Layer 3 protocols (like IP, IPX,...) over a point-to-point connection (like PSTN, ISDN,...). PPP succeeded SLIP by bringing extended features : SLIP could only encapsulate IP while PPP can encapsulate several protocols, PPP supports authentication while SLIP didn't, etc. Remember that TCP/IP only covers Layer 3 up to Layer 7 : it's designed to be implemented on existing lower layers (1 and 2) : LAN (Ethernet, Token Ring, Wireless Lans,...) or WAN (ISDN, ATM, Frame Relay,...). This is a common misconception. The lower layers (1 and 2) that you mention are often completely routable networks in and of themselves. You can even encapsulate IP within IP therefore IP is operating at layer 2 from that interpretation. Ethernet is regularly routed now (people call it switching but a rose by any other name ...). So all of these, including PPP, exist at layers 1-2 in the TCP/IP model (link, network, internetwork, transport, application) or layers 1-3b in the ISORM. This problem plagues developers working with PPP for the first time because they keep thinking in terms of PPP being only a link-layer protocol. If they would remember that PPP operates at the network layer then they would stop making stupid mistakes like a badly-designed L2TP. E.T. (*) Those layers always refer to the OSI model. Think of a Layer 2 or 3 or 4 Switch : it doesn't depend on the protocol suite above, so we always refer to the vendor- technology- protocol-independent OSI reference model. I love watching people slavishly adhere to this or that model of layering. Layering is a convenience, not a religion. (Actually, I got that backwards.) With the widespread use of encapsulating one networking or internetworking protocol in another, the whole concept of rigid layering goes out the window. The cry of, its a network layer; its a link layer, should be right up there with, its a dessert topping; its a floor wax! --- The basic answer ends here --- Now a small yet technical recall : when data comes from an application to be transported on a physical medium (copper cable, fiber optics, radio waves, infra-red,...), on its way from Layer 7 to Layer 1 it reaches IP (Layer 3) ISO spent a lot of time trying to sell the 7-layer model and then didn't know how to backtrack when they discovered that there were really two network layers when you interconnect dissimilar networks using an internetworking protocol. ATM, FR, Ethernet, etc., are all routable layer-3 protocols in their own regard so they opted to break layer three into three sublayers. (It is really three layers by their reckoning but ISO already had so much invested in the ISO Seven Layer Reference Model [tm] that they couldn't really switch to the ISO Nine Layer Reference Model Formerly Known As The Seven Layer Reference Model [tm].) that encapsulates it in a datagram/packet and specifies the destination network+host address. Then it's forwarded to PPP (Layer 2) that encapsulates it in a frame and specifies the way bits are organized to travel through the physical medium. Then it's forwarded to some Layer 1 technology that converts the bits into a specific signal using a specific encoding scheme (V.90 on PSTN, I.430 on ISDN BRI,...) and finally reaches the physical medium to be physically transported through the network. To some extent you are right but your model needs to accommodate things like L2TP which tunnels traffic at layer 1|2 (depending on the model of the day) in a layer 4 (transport) protocol, or IP tunneled in IP. It is probably better to be able to keep the concept of duality in your mind, i.e. when you hold you tongue one way it looks like a link protocol but when you hold your tongue a different way it looks like a transport protocol. I suspect that something like this gave early physicists fits when they were faced with the duality of nature. So trying to be rigid in your categorization of any protocol is likely to cause you heartburn down the road (ask ISO). It is far better to understand where it makes sense
Re: PPP
Here is a question that will tax your synapes to bursting point! How is PPP and TCP/IP libs wired together? Like, DO I (OSI 8) call TCP and it calls IP and down the chain till it spills over and gets real physical (OSI 1)? I am confused. At 10:02 AM 3/5/02 -0500, you wrote: whoa, it's in the TCP/IP suite, it's not. So let me get this straight. TCP and UDP are part of IP. TCP provides error sum UDP doesn't and is therefore faster than TCP. They are encapsulated in IP, which is put into the data bitstream of a PPP frame. Layer 1 is the physical layer, are bitstreams sent at that level. BTW I have 56K dial-up no ISDN or DSL. - Original Message -
RE: PPP
I couldn't say it shorter and more clearly than Vint : PPP does NOT belong to the TCP/IP protocol suite. It's a Layer 2(*) protocol, intended to carry multiple Layer 3 protocols (like IP, IPX,...) over a point-to-point connection (like PSTN, ISDN,...). PPP succeeded SLIP by bringing extended features : SLIP could only encapsulate IP while PPP can encapsulate several protocols, PPP supports authentication while SLIP didn't, etc. Remember that TCP/IP only covers Layer 3 up to Layer 7 : it's designed to be implemented on existing lower layers (1 and 2) : LAN (Ethernet, Token Ring, Wireless Lans,...) or WAN (ISDN, ATM, Frame Relay,...). E.T. (*) Those layers always refer to the OSI model. Think of a Layer 2 or 3 or 4 Switch : it doesn't depend on the protocol suite above, so we always refer to the vendor- technology- protocol-independent OSI reference model. --- The basic answer ends here --- Now a small yet technical recall : when data comes from an application to be transported on a physical medium (copper cable, fiber optics, radio waves, infra-red,...), on its way from Layer 7 to Layer 1 it reaches IP (Layer 3) that encapsulates it in a datagram/packet and specifies the destination network+host address. Then it's forwarded to PPP (Layer 2) that encapsulates it in a frame and specifies the way bits are organized to travel through the physical medium. Then it's forwarded to some Layer 1 technology that converts the bits into a specific signal using a specific encoding scheme (V.90 on PSTN, I.430 on ISDN BRI,...) and finally reaches the physical medium to be physically transported through the network. --- The extended answer ends here --- -Original Message- From: vint cerf [mailto:[EMAIL PROTECTED]] IP is encapsulated in PPP for all practical purposes. PPP can support multiple protocols on a single point to point link in the same way ethernet can support multiple protocols vint At 08:01 AM 3/1/2002 -0500, Bill Cunningham wrote: Is IP actually encapsulated in PPP, or is PPP and IP sent out at the same time at different protocol layers? Kinda holding hands in a sense to each other.
Re: PPP
Layering dogma get all confused and convoluted when faced with engineering ingenuity At what layer is ATM in the old Cells in Frames spec? Or PPP when running ppp sessions over TCP? Or blah over MPLS frames over PPP (over TCP)? Or? PPP is a layer below the one it serves, and a layer above the one it uses Just like most other protocols cheers, gja -- Grenville Armitage http://gjaspace4mecom
Re: PPP
Is IP actually encapsulated in PPP, or is PPP and IP sent out at the same time at different protocol layers? Kinda holding hands in a sense to each other. - Original Message - From: vint cerf [EMAIL PROTECTED] To: Christopher Evans [EMAIL PROTECTED]; Bill Cunningham [EMAIL PROTECTED]; Brian Lloyd [EMAIL PROTECTED] Sent: Friday, March 01, 2002 7:16 AM Subject: Re: PPP christopher, it is called tcp/ip because the encapsulation was read left to right so, for example: smtp/tcp/ip telnet/tcp/ip ftp/tcp/ip http/tcp/ip and ip/ppp/ethernet ip/ethernet ip/ppp/dial-up ip/ppp/dsl and so on the ordering is arbitrary, of course - we just picked higher level protocol to the left as in higher order bit to the left as a way of presenting the protocol layers. vint cerf At 11:58 PM 2/28/2002 -0800, Christopher Evans wrote: Why do they call it TCP/IP ? that sound reversed. it should be IP/TCP-UDP as that makes sense in my head.
Re: PPP
IP is encapsulated in PPP for all practical purposes PPP can support multiple protocols on a single point to point link in the same way ethernet can support multiple protocols vint At 08:01 AM 3/1/2002 -0500, Bill Cunningham wrote: Is IP actually encapsulated in PPP, or is PPP and IP sent out at the same time at different protocol layers? Kinda holding hands in a sense to each other
Re: PPP
On Thu, 28 Feb 2002, Bill Cunningham wrote: In what layer is PPP in the TCP/IP suite? The top of Layer 1 - it's part of the Network Interface layer of the TCP/IP conceptual model PD -- Paul Day Web: wwwburst/~bonfire
RE: PPP
Bill - It is essentially a Data Link Layer protocol, operating at Layer 2. /Michel -Original Message-From: Bill Cunningham [mailto:[EMAIL PROTECTED]]Sent: Thursday, February 28, 2002 6:55 AMTo: [EMAIL PROTECTED]Subject: PPP In what layer is PPP in the TCP/IP suite?
RE: PPP
PPP is a link layer protocol based on the TCO/IP model. In the OSI model, PPP spans Data link and Network layer. Hope this helps. Regards, Paul -Original Message-From: Bill Cunningham [mailto:[EMAIL PROTECTED]]Sent: Thursday, February 28, 2002 6:55 AMTo: [EMAIL PROTECTED]Subject: PPP In what layer is PPP in the TCP/IP suite?
RE: PPP
On Thu, 28 Feb 2002, Michel Gilbert wrote: It is essentially a Data Link Layer protocol, operating at Layer 2 Bill was after where it fits into the TCP/IP model I think you've got that mixed up with the OSI model? :) Layer 2 under the TCP/IP model is the Internet layer, which corresponds to layer 3, Network, of the OSI model If we want to get picky though, you could say PPP overlaps layer 1 and 2 of the TCP/IP model, so saying Layer 2 isn't incorrect, but by using the term Data Link as opposed to Internet fot layer 2 makes me think you're referring of the OSI model *Back in his box now* PD -- Paul Day Web: wwwburst/~bonfire
Re: PPP
DIVFONT face=3DArial size=3D2In what layer is PPP in the TCP/IP= =20suite?/FONT/DIV/BODY/HTML Layer 271828
RE: PPP
Title: RE: PPP Paul - Yep! Didn't read closely enough. Layer 2 in the OSI Reference Model, top of Layer 1 in TCP/IP - except for all of the places it appears elsewhere! :) How's THAT for clarity? /Michel -Original Message- From: Paul Day [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 28, 2002 10:49 AM Cc: [EMAIL PROTECTED] Subject: RE: PPP On Thu, 28 Feb 2002, Michel Gilbert wrote: It is essentially a Data Link Layer protocol, operating at Layer 2. Bill was after where it fits into the TCP/IP model. I think you've got that mixed up with the OSI model? :) Layer 2 under the TCP/IP model is the Internet layer, which corresponds to layer 3, Network, of the OSI model. If we want to get picky though, you could say PPP overlaps layer 1 and 2 of the TCP/IP model, so saying Layer 2 isn't incorrect, but by using the term Data Link as opposed to Internet fot layer 2 makes me think you're referring of the OSI model. *Back in his box now* PD -- Paul Day Web: www.bur.st/~bonfire
Re: PPP
At 03:55 AM 2/28/2002, you wrote: In what layer is PPP in the TCP/IP suite? I have read some of the other responses and it reinforces my belief that most people don't understand PPP's relationship to IP and either the 5-layer (internet) or 7-layer (ISO) models. PPP is really both the link and lower network layers. (The ISORMites discovered that layer three was really several layers in itself but found it difficult to say that the 7-layer model was really a 9-layer model so they created sublayers, i.e. layers 3A, 3B, and 3C. Something about Padlipsky comes to mind here.) The best way to think of PPP is a degenerate network of two nodes, not a link between two devices. If you think of it in this way, things like multilink and L2TP begin to make some sense. The problem occurs when people forget this. The way that I think of it is that the LCP negotiation represents configuration of the link layer while the NCP negotiation configuration at the network layer. And I continue to kick myself for allowing negotiation of multilink as part of LCP instead of doing it after authentication. I fear that this helped screw up L2TP too. I admit I caved to people who were worried about how long it took PPP to complete negotiation, something that just isn't very important. Brian Lloyd [EMAIL PROTECTED] +1.530.676.1113 - voice +1.360.838.9669 - fax
Re: PPP
On Thu, 2002-02-28 at 12:20, Matt Crawford wrote: DIVFONT face=3DArial size=3D2In what layer is PPP in the TCP/IP= =20suite?/FONT/DIV/BODY/HTML Layer 271828 I should have exp()ected that
Re: PPP
From: Brian Lloyd [EMAIL PROTECTED] When all you have is a hammer, everything looks like a nail. ... I must admit, we all laughed when Karl Fox indicated that he had implemented PPP over TELNET back in 1993 or so. We thought it a hilarious joke. I guess my blood should have run cold back then. And to think that, the reason for PPP was a response to the limitations of SLIP and, oh by the way, we can use it to encapsulate IP over T1 lines between dissimilar routers. Why are you surprised? Simple tools (e.g. a screwdriver) have always had the characteristic that they can be used for more things than complex ones (e.g. a mortise-cutting bit for a drill press - now there's a cool tool, BTW - but I digress). The ability of people to use tools for the wrong things (e.g. using a screwdriver as a chisel) is somewhat independent of the complexity of the tool, but does seem to be more common for simple ones, which are more protean. Anyway, simple protocols, like PPP and ARP (another canonical subject of abuse) get reused in vile ways because the architecture which they are components of is fundamentally under-provisioned with mechanisms. But, oh, I forgot, the IPv4 architecture is basically fine, it just needs some engineering refinements. And Eastasia is at war with Oceania... Noel
Re: PPP
From: J. Noel Chiappa [EMAIL PROTECTED] Why are you surprised? Simple tools (e.g. a screwdriver) have always had the characteristic that they can be used for more things than complex ones (e.g. a mortise-cutting bit for a drill press - now there's a cool tool, BTW - but I digress). ... That may be a digression, but it is a good elaboration of the all the world's a nail saying. Screwdrivers and hammers are not only more flexible, but they are a lot harder to break and vastly easier to repair or just sharpen when they get worn. A mortise-cutting bit is an awesome improvement over the alternative, even if you are crazy about grinding your chisels to two angles, diamond stones, strops, and so forth. However, as far as I can tell, hand sharpening a mortise-cutting bit calls for real talent and skill, and don't even think about the equivalent of grinding a new end onto a wrecked screwdriver. ... Anyway, simple protocols, like PPP and ARP (another canonical subject of abuse) get reused in vile ways because the architecture which they are components of is fundamentally under-provisioned with mechanisms. But, oh, I forgot, the IPv4 architecture is basically fine, it just needs some engineering refinements. And Eastasia is at war with Oceania... That's backwards. The architectures that are not under-provisioned with mechanisms are total disasters, as anyone who was even slightly technically involved with TP1-4 knows instinctively, unless they're repressing painful memories. In fact, absolutely everything is fundamentally under-provisioned with mechanisms next year when someone comes up with a new application or other idea. It is a fraud and a deceit to claim to be able to architect provisions for a significant or even noticable part of the unforeseen future. If your design covers any of the real future, as opposed to the future you predicted, you're very lucky. It is not honest to confound great luck with great skill or talent. Vernon Schryver[EMAIL PROTECTED]
RE: PPP
I think Matt really meant PiPiPi which is layer 3.1415926535897932384626433832795(and just keeps on going) John Buda -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Crawford Sent: Thursday, February 28, 2002 12:21 PM To: Bill Cunningham Cc: [EMAIL PROTECTED] Subject: Re: PPP DIVFONT face=3DArial size=3D2In what layer is PPP in the TCP/IP= =20suite?/FONT/DIV/BODY/HTML Layer 2.71828
Re: PPP
From: Vernon Schryver [EMAIL PROTECTED] Anyway, simple protocols, like PPP and ARP (another canonical subject of abuse) get reused in vile ways because the architecture which they are components of is fundamentally under-provisioned with mechanisms. The architectures that are not under-provisioned with mechanisms are total disasters, as anyone who was even slightly technically involved with TP1-4 knows instinctively Ahem. Just because your name is Vern doesn't mean my name is not-Vern. Similarly, not all architectures which are not under-provisioned are over-provisioned. There is a space in the middle... It is a fraud and a deceit to claim to be able to architect provisions for a significant or even noticable part of the unforeseen future. If your design covers any of the real future, as opposed to the future you predicted, you're very lucky. It is not honest to confound great luck with great skill or talent. I don't agree with your contention that it's luck. Let's take as an example Unix, which I would argue has lasted as long as it has for two reasons: first, it was written in a basically portable language, and second, the initial system provided basically the right set of fundamental mechanisms/objects. Looking at the latter point, I think Unix V6 had the things it had not through luck, but because Ken Thompson et al displayed *exactly* great skill and talent. It is true that if you're striking off into a new area, it's more of a gamble - and when you have a success, sometimes there is some luck involved. For instance, in TCP/IP, I think it's lucky that the system has working congestion control - because we certainly didn't understand how to do it right when we went down the no congestion control in the switches road back in the mid/late-70's. It's to some degree luck that there was a workable solution for someone clever to figure out. So when people are moving into a new area, it often takes a while before you find out what the envelope of what's viable is. However, outside things like that, there is clearly a great part of system layout where study of past systems and how they failed and succeeded, along with some guidelines, allows people to design great architecture. If you look, you will actually find that quite often they knew that they had created a successful architecture, and knew how and why they had done it, a long time before it became obvious. Go look at the classic Thompson/Richie paper on V6 Unix for an example; and there are numerous others. The System/360 architects, and the PDP-11 architects, for example, both knew they had great designs at a very, very early stage in the life cycle. Also, you need to distinguish between commercially successful and technically successful. Sometimes systems fail to succeed in the market, but not because they are poorly architected (i.e. a technical failure), but because the company screws up in other ways. Multics is a classic example; I was involved with one in the router business. Someone (maybe Napoleon - or maybe someone said it of Rommel) once said that great generals make their own luck. So it is with system architects. Noel
Re: PPP
I have received several responses and most people say it's in the data layer, and a couple of people think it's in the network layer. I don't really pay much attention to the OSI model, I think it complicates the complicated. I try to focus more on TCP/IP. Does PPP establish a link, then terminate, or continue throughout session in UDP and TCP? I posted this question on the PPP mailing list with less familiaritive response than ietf general list. - Original Message - From: Brian Lloyd [EMAIL PROTECTED] To: Bill Cunningham [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, February 28, 2002 11:52 AM Subject: Re: PPP At 03:55 AM 2/28/2002, you wrote: In what layer is PPP in the TCP/IP suite? I have read some of the other responses and it reinforces my belief that most people don't understand PPP's relationship to IP and either the 5-layer (internet) or 7-layer (ISO) models. PPP is really both the link and lower network layers. (The ISORMites discovered that layer three was really several layers in itself but found it difficult to say that the 7-layer model was really a 9-layer model so they created sublayers, i.e. layers 3A, 3B, and 3C. Something about Padlipsky comes to mind here.) The best way to think of PPP is a degenerate network of two nodes, not a link between two devices. If you think of it in this way, things like multilink and L2TP begin to make some sense. The problem occurs when people forget this. The way that I think of it is that the LCP negotiation represents configuration of the link layer while the NCP negotiation configuration at the network layer. And I continue to kick myself for allowing negotiation of multilink as part of LCP instead of doing it after authentication. I fear that this helped screw up L2TP too. I admit I caved to people who were worried about how long it took PPP to complete negotiation, something that just isn't very important. Brian Lloyd [EMAIL PROTECTED] +1.530.676.1113 - voice +1.360.838.9669 - fax
Re: PPP
I kinda working on my own tcp/ip lib and this is how I interprete it. Your dumb terminal scripter makes connection that activates PPP (with LCP confsync) if that get an IP and return good then you can splat (encapulate) IP/TCP/UDP packets out the line er. and I must warn you I havnt got a working version so dont listen to me, I am a techno moron. Why do they call it TCP/IP ? that sound reversed. it should be IP/TCP-UDP as that makes sense in my head. At 02:25 AM 3/1/02 -0500, Bill Cunningham wrote: I have received several responses and most people say it's in the data layer, and a couple of people think it's in the network layer. I don't really pay much attention to the OSI model, I think it complicates the complicated. I try to focus more on TCP/IP. Does PPP establish a link, then terminate, or continue throughout session in UDP and TCP? I posted this question on the PPP mailing list with less familiaritive response than ietf general list. - Original Message - From: Brian Lloyd [EMAIL PROTECTED] To: Bill Cunningham [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, February 28, 2002 11:52 AM Subject: Re: PPP At 03:55 AM 2/28/2002, you wrote: In what layer is PPP in the TCP/IP suite? I have read some of the other responses and it reinforces my belief that most people don't understand PPP's relationship to IP and either the 5-layer (internet) or 7-layer (ISO) models. PPP is really both the link and lower network layers. (The ISORMites discovered that layer three was really several layers in itself but found it difficult to say that the 7-layer model was really a 9-layer model so they created sublayers, i.e. layers 3A, 3B, and 3C. Something about Padlipsky comes to mind here.) The best way to think of PPP is a degenerate network of two nodes, not a link between two devices. If you think of it in this way, things like multilink and L2TP begin to make some sense. The problem occurs when people forget this. The way that I think of it is that the LCP negotiation represents configuration of the link layer while the NCP negotiation configuration at the network layer. And I continue to kick myself for allowing negotiation of multilink as part of LCP instead of doing it after authentication. I fear that this helped screw up L2TP too. I admit I caved to people who were worried about how long it took PPP to complete negotiation, something that just isn't very important. Brian Lloyd [EMAIL PROTECTED] +1.530.676.1113 - voice +1.360.838.9669 - fax
Re: PPP in HDLC framing
Title: PPP in HDLC framing Actually the sender will see to it that it will not send any packet which exceeds the MRU. If the packet size is more than MRU then it isfragmented into the packets which are less than of MRU and sent by the sender. Chandra - Original Message - From: Sunil Shukla To: [EMAIL PROTECTED] Sent: Wednesday, September 12, 2001 3:10 PM Subject: PPP in HDLC framing Hi !! I am working on PPP in HDLC like framing. I have a doubt.. In case packet length exceeds MRU , then what is the fate of the packet and how it is handled.. Regards, sunil The Information contained and transmitted by this E-MAIL is proprietary to Wipro and/or its Customer and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Company. If you are not the intended recipient, an agent of the intended recipient or a person responsible for delivering the information to the named recipient, you are notified that any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have received this communication in error, please delete this mail notify us immediately at [EMAIL PROTECTED]
