>Oh dear, but I have completely confused you. Perhaps not. There is a danger in assuming that some feature in a protocol design is there because of something incredibly subtle and nuanced, when it really had to do with some technical or political compromise.
> >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. BSC was probably the most common byte-oriented protocol. Others include Burroughs Poll-Select, the synchronous version of Uniscope, etc. I wouldn't rule out still seeing these in a legacy financial network, because the end terminals are old, stupid, and fully amortized. > >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. Now, we get into compromises. At the time PPP was developed, there were commercial chipsets for byte-oriented protocols. By byte-aligning everything, these chipsets could be reused. I can't remember what mailing list this was on, but this is straight from Bill Simpson, the primary designer of PPP. So PPP is conceptually a bit-oriented protocol implemented to work in a byte-oriented environment. There is some interest in having non-bit-aligned protocols as alternatives to PPP over SONET, but I'm not sure the few bits of saving are significant at 10 or 40 Gbps, or compared with the ATM cell tax. > >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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=34795&t=34629 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
