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=34716&t=34629
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
