Oh dear, but I have completely confused you. To be honest, the term "bit-synchronous" isn't very common. I couldn't find anything about it when searching with Google. I took it to mean "bit-oriented" which is a common term to refer to a protocol where control information is encoded using individual bits. If you search for that term in Google, you can learn a lot.
Contrast it with a byte-oriented protocol (also known as a character-oriented protocol). With byte-oriented protocols, all control information and data are encoded using entire bytes. Bisync is a specific character-oriented protocol developed by IBM. It's also known as BSC. I used to know it quite well, but it's been years since I used it. But the gist of it is that it sends characters to get the link up and keep it up. For example, it sends PAD and SYN characters. The other side sends ACKs (hopefully), or maybe NAKs or WACKs. Before sending, a side has to send an ENQ, if I recall. It's half-duplex. Each of these "characters" is one byte with a particular pattern of ones and zeroes. Now for bit-oriented protocols such as SDLC, HDLC, etc. They start by sending one or more instances of the flag field, which is 0111110, then send an address, then the 8-bit or 16-bit Control field, as I mentioned before. Individual bits within the Control field have meaning. The info field follows, then FCS, then the ending flag. It's usually full duplex. A transmitter can send continuously, serially, one bit at a time. The other side takes in bits and figures out what's going on. It doesn't wait to receive an entire control character which it then needs to acknowledge. PPP's heritage is this bit-oriented world. So, it is sort of debatable, as Scott mentioned near the beginning of this discussion. But if you read my previous message, you'll see why I don't think it's quite right to say that it's bit-oriented. All its fields are one byte long. Although it has a Control field due to its HDLC heritage, there's only one valid value for it. On the other hand, the recipient probably does synch up to the 01111110 flag in some implementations, so that sort of makes it bit-oriented. At 11:26 AM 2/7/02, Steven A. Ridder wrote: >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? You are totally lost. ;-) All protocols have fields. Are they processed in byte chunks (like Ethernet and BSC) or as a serial stream of bits like in HDLC? > 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? IBM BSC has fields. >If a L2 protocols sends acks, does that make it a bi-synch protocol? No. >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. All protocols have fields. PPP is debatable due to its HDLC heritage but the design goal of its developers to make it simple, modern, easy to process, interoperable (it can even run on Ethernet these days) causes it to behave more like a byte-oriented protocol, although not like BSC. Sorry that I completely confused you. Here's some more tidbits to chew on! This will really get your brain creating new synapses in a mangled flurry. What is TCP? How is a SYN represented in TCP? What is HDLC? How is a GET represented in HDLC? What is FTP? How is a RETR represented in FTP? And how about Token Ring with its starting delimiter and ending delimiters? And how should one interpret the Ethernet preamble? Also, aren't all protocols at some level processed a bit at a time? This is bad as the 7-layer discussions! ;-) Priscilla >""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=34784&t=34629 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
