Just so I make sure I'm not lost, a bit-sync. protocol is one that has
predefined fields that signify SOF/delimiters/protocol type (like Ethernet)
and a bi-sync. protocol does not?  It just sends characters, and after a
predetermined number of bytes have been sent receives an ack of some sort
(L2).  Do bi-synch protocols have fields?

If a L2 protocols sends acks, does that make it a bi-synch protocol?

So, wouldn't PPP still be a bit-sync. protocol because of the fields it does
have fields (address, control, etc,.)?  Or am I confused.

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

Reply via email to