Priscilla, Thanks for taking the time for the long answer. Having fought PPP at the LCP level so many times between different vendor platforms and as a result of just generally misconfiguring things (esp. authentication), the idea that PPP was character-oriented in that regard was intuitive to me. I have had plenty of opportunity to observe 'debug ppp neg' and 'debug ppp auth' and will no doubt have more in the future.
I had never given the data frames as character-oriented concept much thought until today. It all makes good sense the way you explained it though. I guess it has a lot less in common with HDLC than the casual observer might be led to believe. The reference to the HDLC frame structure seems obligitory in ppp literature. Maybe somebody will get a CCIE written question right as a result of this little discussion. It was certainly interesting either way! Regards, Scott Priscilla Oppenheimer wrote: > > At 06:53 PM 2/6/02, s vermill wrote: > > >I wonder if you, and others, would comment on ppp as a > character-oriented > >protocol. I did a search on the internet and found some > university teaching > >papers that characterize synchronous ppp as character-oriented > while at the > >same time acknowleging the fact that it is based on the > bit-synchronous HDLC > >frame format. I guess the LCP is the culprit? > > PPP has many components, including framing (encapsulation), > LCP, and NCP. > It's best to consider the components separately. The short > answer to your > question, though, is that all the components are > character-oriented > (byte-oriented). In other words, they identify their operations > with entire > bytes, rather than using bits within bytes. And here's the long > answer: > > PPP encapsulation is based on HDLC framing, except that PPP > adds two bytes > for a Protocol field. The Protocol field is not a bit-oriented > field. The > two bytes are taken together to mean IP, AppleTalk, DECnet, etc. > > Also, the other fields in the PPP header, even though based on > HDLC, are > also not really bit-oriented because PPP doesn't do much > compared to other > HDLC derivatives. (sort of like Cisco's HDLC which also doesn't > do much) > > Take the Control field, for example. In PPP, it's always a > single byte that > contains the binary sequence 00000011, which calls for > transmission of user > data in an unsequenced frame. > > Other HDLC-based protocols allow for a few different binary > values for this > field and, in fact, the field can be two bytes. These protocols > can send > Supervisory, Information (with sequence numbers), and > Unnumbered Frames. > They offer reliability and are bit-oriented. LLC2 is an > example. Other > examples are LAPB and LAPD. > > PPP acts like LLC1 and doesn't really do much and doesn't > really need to be > bit-oriented, (with the exception that PPP devices have to know > the one > valid binary value of the Control field.) > > Now, as far as LCP is concerned.... It's in the control plane. > It's pretty > complex, but you could learn more about it by turning on debug > ppp or > reading RFC 1548. > > Per RFC 1548, "The LCP is used to automatically agree upon the > encapsulation format options, handle varying limits on sizes of > packets, > authenticate the identity of its peer on the link, determine > when a link is > functioning properly and when it is defunct, detect a > looped-back link and > other common misconfiguration errors, and terminate the link." > > Despite the complexity, the frame format for LCP appears to be > simple and > character-oriented. Here's probably way more than you ever > wanted to know: > > The Code field is one octet and identifies the kind of LCP > packet. This > specification concerns the following values: > > 1 Configure-Request > 2 Configure-Ack > 3 Configure-Nak > 4 Configure-Reject > 5 Terminate-Request > 6 Terminate-Ack > 7 Code-Reject > 8 Protocol-Reject > 9 Echo-Request > 10 Echo-Reply > 11 Discard-Request > > Identifier > > The Identifier field is one octet and aids in matching requests > and > replies. When a packet is received with an invalid Identifier > field, the > packet is silently discarded. > > Length > > The Length field is two octets and indicates the length of the > LCP packet > including the Code, Identifier, Length and Data fields. Octets > outside the > range of the Length field are treated as padding and are > ignored on > reception. When a packet is received with an invalid Length > field, the > packet is silently discarded. > > Data > > The Data field is zero or more octets as indicated by the > Length field. The > format of the Data field is determined by the Code field. > > > > And we haven't even gotten to the other major component of PPP, > the NCP > part. ;-) > > Priscilla > > > > > > ________________________ > > Priscilla Oppenheimer > http://www.priscilla.com > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=34727&t=34629 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
