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 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:vinton.g.cerf@wcom.com] > > > >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 payload. His comment that PPP > and Ethernet are functionally equivalent is interesting if you mull over > all the ramifications of that statement. > > Brian Lloyd > brian@lloyd.com > +1.530.676.1113 - voice > +1.360.838.9669 - fax