1.Character- Oriented protocols
2. Bit-Oriented protocols
Figure(1) - Synchronous Protocols
Character-Oriented protocols (Also called byte-Oriented protocols) interpret a transmission frame or packet as a succession of characters, each usually composed of one byte (Eight bits). All control information is in the form of an existing character encoding system (Ex: ASCII characters).
Bit-Oriented protocols interpret a transmission frame or packet as a succession of individual bits, made meaningful by their placement in the frame and by their juxtaposition with other bits. Control information in a bit-oriented protocol can be one or multiple bits depending on the information embodied in the pattern.
In a character-Oriented protocol the frame or packet is interpreted as a series of characters. In a bit-Oriented protocol the frame or packet is interpreted as a series of bits.
I. Character - Oriented Protocols
For reasons ,we will examine later in this section, the character-Oriented protocols are not as efficient as bit-Oriented protocols and therefore are now seldom used. They are however is easy to comprehend and employ the same logic and organization as the bit-Oriented protocols. An understanding of character-Oriented protocols provides and essential foundation for an examination of bit-oriented protocols.
In all Data Link protocols, the control information is inserted into the data stream either as separate control frames or as additions to existing data frames. In character-Oriented discipline, Flow control, and error control of the several existing character-Oriented protocols, the best known is IBM's binary Syncronous communication (BSC).
1. Binary Syncronous Communication (BSC)
Binary Synchronous communication (BSC) is a popular character-Oriented Data Link protocol developed by IBM in 1964. Usable in both point-to-point and multipoint configurations. It supports half-duplex transmission using stop-and-wait ARQ flow control and error correction. BSC does not support full-duplex transmission or sliding window protocol.
A popular character-Oriented Data Link protocol is binary Synchronous communication (BSC) which specified half-duplex transmission with stop-and-wait ARQ. I was developed by IBM.
Control Characters
The below Table is a list of standard control characters used in a BSC frame. Note that the character ACK is not used in this protocol. Remember that BSC uses stop-and-wait ARQ : Acknowledgements must be either ACK 0 or ACK 1 to specify alternating data frames.
Table (1) - Control characters for BSC
ASCII Codes
The characters in Table (1) are represented differently in different coding systems.Often they must be represented by two or three characters, the ASCII Codes are also shown in Table (1) for a complete list of the ASCII code.
BSC Frames
The BSC protocol divides a transmission into frames. If a frame is used strictly for control purposes. It is called a control frame, Control frames are used to exchange information between communicating devices, for example : To establish the initial connection, to control the flow of the transmission, to request error corrections, and to disconnect the devices at the close of a session. If a frame contains part or all of the message data itself, It is called a data frame. Data frames are used to transmit information, but may also contain control information application to that information, see in Figure (2).
Figure (2) - BSC frames
Data Frames
The arrow shows the direction of transmission. The frame begins with two or more Synchronization (SYN) characters. These characters alert the receiver to the arrival of a new frame and provide a bit pattern used by the receiving device to Synchronize its timing with that of the sending device.In this page, we will discover that the ASCII code for SYN is 0010110. The leading (Eighth) bit of byte is usually filled out by an additional 0. Two SYN characters together look like this : 0001011000010110.
After the two synchronization characters comes a start of text (STX) character. This character signals to the receiver that the control information is ending and the next byte will be data. Data or text can consist of varying numbers of characters. An end of text (ETX) character indicates the transition between text and more control characters.
Finally, one or two characters called the block check count (BCC) are included for error detection. A BCC field can be a one-character longitudinal redundancy check (LRC) or a two-character cyclic redundancy check (CRC).
Header Fields
A frame as simple as the one described above is seldom useful. Usually we need to include the address of the receiving device, the address of the sending device, and the identifying number of the frame (0 or 1) for stop-and-wait ARQ (see in Figure(4) )
Figure(3) - A Simple BSC data frame
Figure (4) - A BSC frame with a header
This information is included in a special field called a header which before the STX character, everything received after the SOH field but before the STX character is header information.
Multi-block Frames
The probability of an error in the block of text increases with the length of the frame. The more bits in a frame, the greater the likelihood that one of them will be corrupted in transit, and the greater the likelihood that changes in several bits will cancel each other out and make detection difficult. For this reason, text in a message is often divided between several blocks. Each block, except the last one, starts with an STX character and ends with an intermediate text block (ITB). The last block starts with an STX but ends with an ETX. Immediately after each ITB or ETX, a BCC field is sent. In that way, the receiver can check each block separately for errors, thereby increasing the likelihood of detection. If any block contains an error, however, the entire frame must be retransmitted. After the ETX has been reached and the last BCC checked, the receiver sends a single acknowledgment for the entire frame, see in Figure (5) shows the structure of a multi-block frame : the example includes two blocks ,but actual frames can have more than two.
Figure (5) - A multi-block frame
Multi-Frame Transmission
In the examples explored above, a single frame carries an entire message. After each frame, the message is complete and control of the line passes to the secondary device (half-duplex mode). Some messages, however may be too long to fit into the format of a single frame. In such cases, the sender can split the message not only among blocks but among frames. Several frames can carry continuations of a single message. To let the receiver know that the end of the frame is not the end of the transmission. the ETX character in all frames but the last one is replaced by an end of transmission block (ETB). The receiver must acknowledge each frame :
Control Frames
A Control frame should not be confused with a control character. A control frame is used by one device to send commands to, or solicit information from, another device. A control frame contains control characters but no data. It carries information specific to the functioning of the Data Link layer itself. The figure (7) is shows the basic format of a BSC control frame.
Figure (7) - BSC control frame
Control frames serve three purposes : Establishing connections, maintaining flow and error control during data transmission, and terminating connections (See Figure (8) ).
Data Transparency
BSC was originally designed to transport only textual messages(words or figures composed of alphanumeric characters). Today, however, a user is just as likely to want to send binary sequences that contain non-textual information and commands, Like programs and graphics. Unfortunately, messages of this sort can create problems for BSC transmission. If the text field of a transmission includes an eight-bit pattern that looks like a BSC control character, the receiver interprets it as one, destroying the sense of the message. For example : a receiver seeing the bit pattern 0000011 reads it as an ETX characters. As we learned from the control frames above, whenever a receiver finds an ETX. It expects the next two bytes to be the BCC and begins an error check. But the pattern 0000011,here is intended as data and not as control information. Confusion between control information and data is called a lack of data transparency.
For a protocol to be useful, it must be transparent - It must be able to carry any combination of bits as data without their being confused with control information.
Data transparency in data communication means we should be able to send any combination of bits as data.
Data transparency in BSC is achieved by a process called byte stuffing. It involves two activities : Defining the transparent text region with Data Link escape (DLE) characters and preceding any DLE characters within the transparent region by an extra DLE character.
To define the transparent region, we insert one DLE character just before the STX character at the beginning of the text field and another just before the ETX (or ITB ) may contain control characters and to ignore them. The last DLE tells the receiver that the transparent region has ended.
Problems may still arise if the transparent region contains a DLE character as text. In that case, we insert an additional DLE just before each DLE within the text. See in Figure (9), shows an example of a transparent frame.
Figure (9) - Byte stuffing
2. BIT-ORIENTED PROTOCOLS
In character-Oriented protocols, bits are grouped into predefined patterns forming characters. By comparison, Bit-Oriented protocols can pack more information into shorter frames and avoid the transparent or problem of character information given the advantages of Bit-Oriented protocols and the lack of any preexisting coding system (like ASCII) to tie them to, It is no under that over the last two decade many different Bit-Oriented protocols have been developed. All vying to become the standard, see in Figure (10). Most of these offerings have been proprietary, designed the manufactures to support their own products. One of them, HDLC, is the design of the ISO and has become the basis for all Bit-Oriented protocols in use today.
Figure (10) - Bit-Oriented protocols
In 1975, IBM pioneered the development of bit-oriented protocols with synchronous data link control (SDLC), and lobbied the ISO to make SDLC the standard. In 1979, the ISO answered with high-level data link control (HDLC), which was based on SDLC. Adoption of HDLC by the ISO committees led to its adoption and extension be other organizations. The ITU-T was one of the first organizations to embrace HDLC since 1981. ITU-T has developed a series of protocols called link access protocol (LAPs : LAPB, LAPD, LAPM, LAPX, etc.), all based on HDLC. Other protocols (Such as frame relay, PPP, etc.) developed by both ITU-T and ANSI also derive from HDLC as do most LANs access control protocols. In short, all bit-oriented protocols in use today either derive from or are sources for HDLC. Through HDLC, therefore, we have a basis for understanding the others.
All bit-Oriented protocols are related to high-level data link control (HDLC), a bit-oriented protocol published by ISO. HDLC supports both half-duplex and full-duplex modes in point.
HDLC
HDLC is a bit-oriented data link protocol designed to support both half-duplex and full-duplex communication over point-to-point and multipoint links. Systems using HDLC can be characterized by their station types, their configurations, and their response modes.
Station Types
HLDC differentiates between three different types of stations : primary, Secondary, and combined.
A primary station in HDLC functions in the same way as the primary devices in the discussions of flow control in the last article. The primary is the device in either a point-to-point or multipoint line configuration that has complete control of the link.
The primary sends commands to the secondary, A primary issues commands, a secondary issues responses. An example of the relation of a primary to a secondary is that of computer to terminal.
A combined station can both command and respond. A combined station is one of a set of connected peer devices programmed to behave either as a primary or as a secondary depending on the nature and direction of the transmission.
Stations in HDLC are of three types: Primary , Secondary, and Combined. A primary station sends commands, A secondary station sends responses, A Combined station sends commands and responses.
Configurations:
The word configuration refers to the relationship of hardware devices on a link, Devices may be organized as primary and secondary or as peers. Peer devices must be able to act as both primary or secondary, depending on the mode selected for the exchange (See the section Modes of Communication. Primary, Secondary, and Combined stations can be configured in three ways : Unbalanced, Symmetrical, and balanced (See Figure 11). Any of these configurations can support both half-duplex and full-duplex transmission.
An unbalanced configuration ( also called a master/slave configuration) is one in which one device is primary and the others are secondary. Unbalanced configurations can be point-to-point if only two devices are involved : more often they are multipoint with one computer controlling several peripherals. An example of an unbalanced configuration is a computer and one or more terminals.
A symmetrical configuration is one in which each physical station on a link consists of two logical stations, one a primary and the other a secondary. Separate lines link the primary aspect of one physical station to the secondary aspect of another physical station. A symmetrical configuration behaves like an unbalanced configuration except that control of the link can shift between the two stations.
A balanced configuration is one in which both stations in a point-to-point topology are of the combined type. The stations are linked by a single line that can be controlled by either station.
Figure (11) - HDLC Configurations
HDLC does not support balanced multipoint. This necessitated the invention of media access protocols for LANs.
Modes of Communication
A mode in HDLC is the relationship between two devices involved in an exchange : the mode describes who controls the link. Exchanges over unbalanced configurations are always conducted in normal response mode. Exchanges over symmetrical or balanced configurations can be set to a specific mode using a frame designed to deliver the command (discussed in the section on U-frames). HDLC supports three modes of communication between stations : normal response mode (NRM), Asynchronous response mode (ARM), and Asynchronous balanced mode (ABM).
NRM : Normal Response mode (NRM) refers to the standard primary-secondary relationship. In this mode, a secondary device must have permission from the primary device before transmitting. One permission has been granted, the secondary may initiate a response transmission of one or more frame containing data control information or data, might contain the pattern 01111110, If that were to happen in the data, for example, the receiver would find it and assume that the end of the frame had been reached (With disastrous results).
To guarantee that a flag does not appear inadvertently anywhere else in the frame. HDLC uses a process called bit stuffing. Every time a sender wants to transmit a bit sequence having more than five consecutive 1s, it inserts (stuffs) one redundant 0 after the fifth 1. For example, the sequence 011111111000 becomes 0111110111000. This extra 0 is inserted regardless of whether the sixth bit is another 1 or not. Its presence tells the receiver that the current sequence is not a flag. Once the receiver has been the stuffed 0. It is dropped from the data and the original bit stream is restored.
Bit stuffing is the process of adding one extra 0 whenever there are five consecutive 1s in the data so that the receiver does not mistake the data for a flag.
With three exceptions, bit stuffing is required whenever five 1s occur consecutively. The exceptions are when the bit sequence really is a flag. When the transmission is being aborted, when the Channel is being put into idle. The flowchart in Figure (12) shows the process the receiver follows to identify and discard a stuffed bit.
As the receiver reads the incoming bits, it counts 1s. When it finds five consecutive 1s after a 0. It checks the next (Seventh) bit. If the seventh bit is a 0, the receiver recognizes it as a stuffed bit, discards it, and resets its counter. If the seventh bit is a 1, the receiver checks the eighth bit, if the eighth bit is a 0, the sequence is recognized as a flag and treated accordingly. If the eighth bit is another 1, the receiver continues counting. A total of 7 to 14 consecutive 1s indicates an abort, A total of 15 or more 1s indicates an idle channel.
Address Field
The second field of an HDLC frame contains the address of the secondary station that is either the
originator or destination of the frame (Or the station acting as secondary in the case of combined stations).
If a primary station creates a frame, it contains a top address. If a secondary creates the frame, it contains
a from address. An address field can be one byte or several bytes long, depending on the needs of the
network. One byte can identify up to 128 stations (because one bit is used for another purpose).
Larger networks require multiple-byte address fields. Figure (13) shows the address field in relation to the rest of the frame.
If the address field is only one byte, the last bit is always a 1, If the address is more that one byte, all bytes but the last one will end with 0; Only the last will end with 1. Ending each intermediate byte with 0 indicates to the receiver that there are more address bytes to come.
Control Field
The control field is a one- or two-byte segment of the frame used for flow management. We will limit our discussion to the one-byte case. The two-byte case is similar.
Control fields differ depending on frame type, If the first bit of the control field is 0, the frame is an 1 and the second bit is 0, it is an S-frame.
An I-frame contains two 3-bit flow and error control sequences, called N(S) and N(R), flanking the P/F bit, N(S) specifies the number of the frame being sent (its own identifying number). N(R) indicates the number of the frame expected in return in a two-way exchange; thus N(R) is the acknowledgement field. If the last frame received was error-free, the N(R) number will be that of the next frame in the sequence. If the last frame was not received correctly, the N(R) number will be the number of the damaged frame, indicating the need for its retransmission.
The control field of an S-frame contains an N(R) field but not an N(S) field. S-frames are used to return N(R) when the receiver does not have data of its own to send. Otherwise the acknowledgement is contained in the control field of an I-frame (above). S-frames do not transmit data and so do not require N(S) fields to identify them. The two bits preceding the P/F bit in an S-frame are used to carry coded flow and error control information, which we will discuss later in this chapter.
U-frames have neither N(S) nor N(R) fields, and are not designed for user data exchange or acknowledgement. Instead, U-frames have two code fields, one two bits and the other three, flanking the P/F bit. These codes are used to identify the type of U-frame and its function (eg., establishing the mode of an exchange), if the control field of a U-frame is two bytes long instead of one, the modes NRM, ARM , and ABM are called NRME, ARME and ABME, the E standing for extended. The control fields of all three types of frames are show in figure (14).
Figure (14) - HDLC control fields
The P/F field is a single bit with a dual purpose. It has meaning only when it is set (bit=1) and can mean poll or final. It means poll when the frame is sent by a primary station to a secondary (when the address field contains the address of the receiver). It means final when the frame is sent by a secondary to a primary(when the address field contains the address of the sender); see Figure (15) :
Figure (15) - Poll final field in HDLC
Figure (16) - Information field in HDLC
As we have seen in several cases above, it is often possible to include flow, error, and other control information in an I-frame that also contains data. For example: In a two-way exchange of data ( either half- or full-duplex) , station 2 can acknowledge receipt of data from station 1 in the control field of its own data frame rather than sending a separate frame just for the acknowledgement, Combining data to be sent with control information this way is called piggybacking.
Piggybacking means combining data to be sent and acknowledgement of the frame received in one single frame.
FCS Field
The frame check sequence (FCS) is HDLC's error detection field. It can contain either a two- or four-byte CRC (See Figure (17).
Figure (17) - Frame check sequence (FCS) field in HDLC
More about Frames
Of the three frames used by HDLC, the I-frame is the most straightforward. I-frames are designed for user information transport and piggybacked acknowledgements and nothing else. For this reason the range of variation in I-frames is small, All differences relate either to the data (content and CRC), to the identifying number of the frame, or to the acknowledgment of received frames (ACK or NAK).
S-frames and U-frames, however, contain subfields within their control fields. As meaning of the frame, For example, and S-frame coded for selective-reject (SREJ) cannot be used in the same context as an S-frame coded for receive ready (RR). In this section, we will examine the different type of and uses for S- and U-frames.
S-frames
Supervisory frames are used for acknowledgement, flow control, and error control whenever piggybacking that information onto an I-frame is either impossible or inappropriate (when the station either has no data of its own to send, or needs to send a command or response other than an acknowledgement), S-frames do not have information fields, yet each one carries messages to the receiving station. These messages are based on the type of the S-frame and the context of the transmission. The type of each S-frame is determined by a two-bit code set into its control field just before the P/F bit. There are four types of S-frames : Receive ready (RR) , Receive not Ready (RNR), Reject (REJ), and Selective-Reject(SREJ) : Please see Figure (18) .
Figure (18) - S-frame control field in HDLC
Receive Ready(RR) : A S-frame containing the code for RR (00) can be used in four possible ways, each having a different significance.
- ACK, RR is used by a receiving station to return a positive acknowledgement of a received I-frame when the receiver has no data of its own to send (no I-frame on which to piggyback the acknowledgement). In this case, the N(R) field of the control frame contains the sequence number of the next frame expected by the receiver. An N(R) field can have from one to three bits. Three bits allow an S-frame to acknowledgement up to eight frames.
- Poll, when transmitted by the primary (or acting primary in a combined station) with the P/F bit (now functioning as the P bit) set, RR asks the secondary if it has anything to send.
- Negative response to poll, when sent by a secondary with the P/F bit (now functioning as the F bit) set, RR tells the primary that the secondary has nothing to send. If the secondary does have data to transmit, it responds to the poll with an I-frame, not an S-frame.
- Positive response to select, When a secondary is able to receive a transmission from the primary, it returns an RR frame with the P/F (used as F) bit set to 1. (For a description of selection, See RNR below. )
- ACK, RNR returned by a receiver to a sending station acknowledges receipt of all frames up to, but not including, the one indicated in the N(R) field but requests that no more frames be sent until an RR frame is issued.
- Select, when a primary wishes to transmit data to a specific secondary, it alerts the secondary by sending an RNR frame with the P/F (used as P) bit set. The RNR code tells the secondary not to send data of its own, that the frame is a select and not a poll.
- Negative response to select, When a selected secondary is unable to receive data, it returns an RNR frame with the P/F (used as F) bit set.
Selective Reject : A selective-reject (SREJ) frame is a negative acknowledgment in a selective-reject ARQ system. It is sent by the receiver to the sender to indicate that a specific frame (the number in the N(R) field) has been received damaged and must be resent, Please see Figure (19) shows the use of the P/F bit in polling and selecting.
Figure (20) - Use of P/F bit in Polling and Selecting
U-Frames
Unnumbered frames are used to exchange session management and control information between connected devices. Unlike S-frames, U-frames contain an information field but one used for system management information not user data. As with S-frames however, much of the information carried by U-frames is contained in codes include in the control field. U-frame codes are divided into two sections, a two-bit prefix before the P/F bit and a three-bit suffix after the P/F bit. Together, these two segments (five bits) can be used to create up to 32 different types of U-frame. Some of the more common combinations are shown in Figure 21.
Figure 21 - U-frame control field in HDLC
The U-frame commands and responses listed in Table 22 can be divided into five basic functional categories : Mode setting, Unnumbered-exchange, Disconnection, Initialization and miscellaneous.
Mode Setting : Mode-Setting commands are sent by the primary station, or by a combined station wishing to control an exchange, to establish the mode of the session. A mode-setting U-frame tells the receiving station what format the transmission will take. For example: If a combined station wishes to establish a temporary primary-to-secondary relationship with another station. It sends a U-frame containing the code 00001(for set normal response mode). The addressed station understands that it is being selected to receive a transmission (as if from a primary) and adjusts itself accordingly ,see in Table 22 above.
Unnumbered-Exchange : Unnumbered-Exchange codes are used to send or solicit specific pieces of data link information between devices. The unnumbered poll (UP) code (00 100) is transmitted by the primary station on a link (or the combined station acting as a primary) to establish the send/receive status of the addressed station in an unnumbered exchange. The unnumbered information (UI) code (00 000) is used for the transmission of specific pieces of information such as time/date for synchronization, UI frames can be sent either as commands (Ex.: a list of parameters for the coming transmission) or as responses (Ex.: a destination of the capabilities of the addressed station to receive data). The unnumbered acknowledgement (UA) code(00 110) is returned by the addressed station in answer to an unnumbered poll, to acknowledgement one of the unnumbered request frames (Ex: RD : Request Disconnect) , or to accept a set-mode command (See Table 22).
Disconnection : There are three disconnect codes, one a command from the acting primary or combined station, the other two responses from the receiving station. The first of these , disconnect (DISC. 00 010), is sent by the first station to the second to terminate the connection. The second, request disconnect (RD. 00 010), is a request by the second station to the first that a DISC be issued. The third, disconnect mode (DC. 11 000), is transmitted by the addressed station to the initiating station as a negative response to a mode setting command (See Table 22).
Initialization Mode : The code 10 000, used as a command (First system to second system), means set initialization mode (SIM). SIM prepared the addressed station to initialize its data link control functions. The SIM command is then followed by UI frames containing, for example, a new program or a new parameter set. The same code, mode (RIM) and solicits a SIM command from the first station. It is used to respond to a mode setting command when the second station cannot act upon the command without first receiving a SIM (See Table 22).
Miscellaneous of the final three commands, the first two-reset (RSET. 11 001) and exchange ID (XID. 11 101) are commands from the initiating system to the addressed system. The third frame reject(FRMR. 10 001) is a response sent from the addressed system to the initiating system.
RSET tells the second station the first station is resetting its send sequence numbering and instructs the second system to do likewise. It is usually issued in response to an FRMR.
XID requests an exchange of identifying data from the second station ( What is your address?).
FRMR tells the first system that a U-frame received by the second system contains a syntax error (This doesn't look like an HDLC frame!). It is returned by the addressed system when, for example : a frame is identified as an S-frame but contains an information field (See in Table 22).
Example 1: Poll/ Response
In figure 23, the Primary device (the mainframe) on a multipoint link polls the secondary device (A) with an S-frame containing the codes for poll, The flag field is first control, contains the code identifying the frame as an S-frame followed by the codes indicating the RR (Receive Ready) status of the sender, the P/F bit set to poll, and an N(R) = 0 field. After the control field, comes the error detection code (FCS) and the ending flag field.
Station A has data to send, So it responds with two I-frames numbered 0 and 1. The second of these has the P/F bit set for final to indicate the end of the data. The primary acknowledges both frames at once with an S-frame containing the number 2 in its N(R) field to tell station A that frames 0 and 1 have been received, and that if A sends additional frames, the primary expects number 2 to arrive next.
Example 2 : Selecting / Response
This example uses the same multipoint configuration to show a primary device selecting a secondary device, station B, to receive a transmission (See Figure 24).
First, the primary sends out an S-frame addressed to station B that contains the codes for select. The select frame is identical to the poll frame in the previous example, except that the RR status in the control field has been changed to RNR, telling the secondary to be ready but not to send. Station B responds with another S-frame, addressed from B, that contains the code for RR as well as the final bit set, to indicate that the station is ready to receive and that this frame is the last.
The primary sends and I-frame containing its data. The frame is addressed to B, the N(S) field identifies it as frame number 0, the P bit is not set to indicate that the frame is not a poll, and the N(R) field indicates that if an I-frame is returned, It is expected also to be number 0. Station B responds with an RR frame with a dual purpose, the set final bit tells the primary that B does not have anything to send, and the I in the N(R) field acknowledges the receipt of frame 0 and indicates that B next expects to receive frame 1.
Example 3 : Peer Devices
The example in Figure 25 shows an exchange in asynchronous balanced mode (ABM) using piggybacked acknowledgements. The two stations are of equal status and are connected by a point-to-point link.
Station A issues a U-frame containing the code for SABM to establish a link in asynchronous balanced mode. The P bit is set to indicate that station A expects to control the session and to transmit first. Station B accepts the request by returning a U-frame containing the code for UA, with the F bit set. By agreeing to transmit in asynchronous balanced mode, both stations are now of combined type, rather than primary secondary, so the P/F bit is no longer valid and can be ignored in the frames that follow both frames onto an I-frame of its own. Station B's first I-frame is also numbered 0 (N(S) field) and contains a 2 in its N(R) field, acknowledging the receipt of A's frames 1 and 0 and indicating that it expects frame 2 to arrive next. Station B transmits its second and third I-frames (numbers 1 and 2) before accepting further frames from station A. Its N(R) information, therefore, has not changed : B frames 1 and 2 indicate that station B is still expecting A frame 2 to arrive next.
Station A has sent all of its data. Therefore, it cannot piggyback an acknowledgement onto an I-frame and sends an S-frame instead. The RR code indicates that A is still ready to receive. The number 3 in the N(R) field tells B that frames 0, 1, and 2 have all been accepted and that A is now expecting frame number 3.
Link Access Procedures
Several protocols under the general category link access procedure (LAP) have been developed. Each of these protocols is a subset of HDLC tailored for a specific purpose. LAPB, LAPD and LAPM are the most common of these.
LAPB
Link Access Procedure Balanced (LAPB) is a simplified subset of HDLC used only for connecting a station to a network. It therefore provides only those basic control functions required for communication between a DTE and a DCE (Ex.: it does not include poll and select characters).
LAPB is used only in balanced configurations of two devices, where both devices arer of the combined type. Communication is always in asynchronous balanced mode. LAPB is used today in Integrated Services Digital Network (ISDN) on B channels.
LAPD
Link Access Procedure for D channel (LAPD) is another simplified subset of HDLC used in Integrated Services Digital Network (ISDN). It is used for out-of-band (Control) signalling. It used asynchronous balanced mode (ABM).
LAPM
Link Access Procedure for Modems (LAPM) is a simplified subset of HDLC for modems. It is designed to do asynchronous-Synchronous conversion, error detection, and retransmission. It has been developed to apply HDLC features to modems.
0 comments:
Post a Comment
If there is any comments,Please leave a comment at here.