hdlc report

38
NUST-SEECS & NEXTEK Services 1 SEECS- NEXTEK Services Joint Internship Program Summer-2011 Muhammad Faizan Khan Ali Hussain August 25, 2011

Upload: faizihaid

Post on 22-Feb-2015

303 views

Category:

Documents


5 download

TRANSCRIPT

Page 1: HDLC Report

NUST-SEECS & NEXTEK Services

1

SEECS- NEXTEK Services Joint

Internship Program

Summer-2011

Muhammad Faizan Khan

Ali Hussain

August 25, 2011

Page 2: HDLC Report

NUST-SEECS & NEXTEK Services

2

ACKNOWLEDGMENTS

First and foremost, we would like to express our sincere gratitude to our advisor Ma’m Saba Zia for

the continuous support of design and development of our internship Project, for her patience,

motivation, enthusiasm, and immense knowledge. We are thankful to NEXTEK services for the

provision of industrial project and guidance.

Lastly, we offer our regards and blessings to all of those who supported us in any respect during the

completion of the project.

Page 3: HDLC Report

NUST-SEECS & NEXTEK Services

3

Contents ACKNOWLEDGMENTS ............................................................................................................................ 2

ABSTRACT .................................................................................................................................................. 5

CHAPTER 1 ................................................................................................................................................. 6

Introduction to Communication Protocols: ............................................................................................... 6

Basic requirements of protocols:............................................................................................................... 7

Protocol design.......................................................................................................................................... 8

The OSI Model ....................................................................................................................................... 8

OSI Stack Protocol Model; ................................................................................................................... 9

CHAPTER 2 ............................................................................................................................................... 10

HDLC Protocol: ...................................................................................................................................... 10

Types of HDLC Stations: ........................................................................................................................ 10

Primary ................................................................................................................................................ 10

Secondary ............................................................................................................................................ 10

Combined ............................................................................................................................................ 11

Configurations of HDLC: ....................................................................................................................... 11

Unbalanced Configuration .................................................................................................................. 11

Balanced Configuration ...................................................................................................................... 11

Symmetrical Configuration ................................................................................................................. 12

HDLC Operation Modes; ........................................................................................................................ 12

1. Normal Response Mode (NRM) ................................................................................................. 12

2. Asynchronous Response Mode (ARM) ...................................................................................... 12

3. Asynchronous Balanced Mode (ABM) ....................................................................................... 12

HDLC Non-Operational Modes; ............................................................................................................. 12

Protocol Structure - HDLC: High Level Data Link Control ................................................................... 13

Frame Format .......................................................................................................................................... 13

The Flag field ...................................................................................................................................... 13

Address field ....................................................................................................................................... 13

Page 4: HDLC Report

NUST-SEECS & NEXTEK Services

4

Control field : ...................................................................................................................................... 14

Information field – .............................................................................................................................. 14

FCS – .................................................................................................................................................. 14

Categories of Frames; ............................................................................................................................. 14

1. Unnumbered frames .................................................................................................................... 15

Unnumbered Format Commands and responses (U-Frame ................................................................ 15

2. Information frames ...................................................................................................................... 16

3. Supervisory frames ..................................................................................................................... 16

The Poll/Final Bit (P/F) ...................................................................................................................... 17

CHAPTER 3 ............................................................................................................................................... 18

Protocol Operation .................................................................................................................................. 18

Link management ................................................................................................................................ 18

Data transfer ........................................................................................................................................ 18

Transparency ........................................................................................................................................... 19

Bit stuffing and removal ..................................................................................................................... 19

FSM of Transparency: ........................................................................................................................ 20

Hardware Implementation: ..................................................................................................................... 20

Detailed Design: .................................................................................................................................. 20

Requirements: ..................................................................................................................................... 21

Framing: .............................................................................................................................................. 21

Design: ................................................................................................................................................ 22

De-Framing: ........................................................................................................................................ 23

Modem Sharing Device: ......................................................................................................................... 23

Modem: ................................................................................................................................................... 24

Data Reception: ....................................................................................................................................... 27

Chapter 4: .................................................................................................................................................... 28

Reception: ............................................................................................................................................... 28

Page 5: HDLC Report

NUST-SEECS & NEXTEK Services

5

ABSTRACT

In the current era networking has played an important role in bringing scientific revolution to mankind.

The whole Computer networks are based on reference model. The data link layer is responsible for link

management and frame transmission. This project briefly explains the higher level data link layer protocol

and it’s operation as well as it’s implementation. Chapter 1 is related to basics of communication

protocols. The detailed description is given in the second chapter where all the terminologies have been

discussed. Types of stations used in HDLC are can be of three types which are generally detected with the

help of frames. There are different types of frames as well and they affect the operation of protocol.

Chapter 3 gives detailed design of protocol implementation and operation. This includes hardware details

and requirements such as modem and modem sharing device.

In the last chapter Verilog code is given for data reception at the monitoring end.

Page 6: HDLC Report

NUST-SEECS & NEXTEK Services

6

CHAPTER 1

Introduction to Communication Protocols:

A communications protocol is a formal description of digital message formats and the rules for

exchanging those messages in or between computing systems and in telecommunications.

Protocols may include signaling, authentication and error detection and correction capabilities. A protocol

defines the syntax, semantics, and synchronization of communication, and the specified behavior is

typically independent of how it is to be implemented. A protocol can therefore be implemented as

hardware or software or both. In computer science the word algorithm is a synonym for the word

procedure so a protocol is to communications what an algorithm is to mathematics.

Communicating systems use well-defined formats for exchanging messages. Each message has an exact

meaning intended to provoke a defined response of the receiver. A protocol therefore describes the

syntax, semantics, and synchronization of communication. A programming language describes the same

for computations, so there is a close analogy between protocols and programming languages: protocols

are to communications what programming languages are to computations. (A less technical reader might

appreciate this similar analogy: protocols are to communications what grammar is to writing.)

The communications protocols in use on the Internet are designed to function in very complex and diverse

settings. To ease design, communications protocols are structured using a layering scheme as a basis.

Instead of using a single universal protocol to handle all transmission tasks, a set of cooperating protocols

fitting the layering scheme is used. The layering scheme in use on the Internet is called the TCP/IP model.

The actual protocols are collectively called the Internet protocol suite. The group responsible for this

design is called the Internet Engineering Task Force (IETF).

The information exchanged between devices on a network or other communications medium is governed

by rules or conventions that can be set out in a technical specification called a communication protocol

standard. The nature of the communication, the actual data exchanged and any state-dependent behaviors

are defined by the specification. Communicating systems have to communicate with each other using

shared transmission media, because there is no common memory. Transmission is not necessarily reliable

and can involve different hardware and operating systems on different systems.

To implement a networking protocol, the protocol software modules are interfaced with a framework

implemented on the machine's operating system. This framework implements the networking

functionality of the operating system. The best known frameworks are the TCP/IP model and the OSI

model.

In communications, message values are transferred using transmission media. By analogy, the equivalent

of a store would be a collection of transmission media, instead of a collection of memory locations. A

valid assignment in a protocol (as an analog of programming language) could be Ethernet:='message' ,

meaning a message is to be broadcast on the local Ethernet.

Page 7: HDLC Report

NUST-SEECS & NEXTEK Services

7

On a transmission medium there can be many receivers. For instance a mac-address identifies an ether

network card on the transmission medium (the 'ether'). In our imaginary protocol, the assignment

Ethernet[mac-address]:=message value could therefore make sense.

Basic requirements of protocols:

Messages are sent and received on communicating systems to establish communications. Protocols should

therefore specify rules governing the transmission. In general, much of the following should be addressed.

Data formats for data exchange. Digital message bit strings are exchanged. The bit strings are divided in

fields and each field carries information relevant to the protocol. Conceptually the bit string is divided

into two parts called the header area and the data area. The actual message is stored in the data area, so

the header area contains the fields with more relevance to the protocol. Bit strings longer than the

maximum transmission unit (MTU) are divided in pieces of appropriate size.

Address formats for data exchange. Addresses are used to identify both the sender and the intended

receiver(s). The addresses are stored in the header area of the bitstrings, allowing the receivers to

determine whether the bitstrings are intended for themselves and should be processed or should be

ignored. A connection between a sender and a receiver can be identified using an address pair (sender

address, receiver address). Usually some address values have special meanings. An all-1s address could

be taken to mean an addressing of all stations on the network, so sending to this address would result in a

broadcast on the local network. The rules describing the meanings of the address value are collectively

called an addressing scheme.

Address mapping. Sometimes protocols need to map addresses of one scheme on addresses of another

scheme. For instance to translate a logical IP address specified by the application to an Ethernet hardware

address. This is referred to as address mapping.

Routing. When systems are not directly connected, intermediary systems along the route to the intended

receiver(s) need to forward messages on behalf of the sender. On the Internet, the networks are connected

using routers. This way of connecting networks is called internetworking.

Detection of transmission errors is necessary on networks which cannot guarantee error-free operation.

In a common approach, CRCs of the data area are added to the end of packets, making it possible for the

receiver to detect differences caused by errors. The receiver rejects the packets on CRC differences and

arranges somehow for retransmission.

Acknowledgements of correct reception of packets is required for connection oriented communication.

Acknowledgements are sent from receivers back to their respective senders.

Loss of information - timeouts and retries. Packets may be lost on the network or suffer from long

delays. To cope with this, under some protocols, a sender may expect an acknowledgement of correct

reception from the receiver within a certain amount of time. On timeouts, the sender must assume the

packet was not received and retransmit it. In case of a permanently broken link, the retransmission has no

effect so the number of retransmissions is limited. Exceeding the retry limit is considered an error.

Direction of information flow needs to be addressed if transmissions can only occur in one direction at

a time as on half-duplex links. This is known as Media Access Control. Arrangements have to be made to

accommodate the case when two parties want to gain control at the same time.

Sequence control. We have seen that long bitstrings are divided in pieces, that are send on the network

individually. The pieces may get lost or delayed or take different routes to their destination on some types

of networks. As a result pieces may arrive out of sequence. Retransmissions can result duplicate pieces.

By marking the pieces with sequence information at the sender, the receiver can determine what was lost

or duplicated, ask for necessary retransmissions and reassemble the original message.

Page 8: HDLC Report

NUST-SEECS & NEXTEK Services

8

Flow control is needed when the sender transmits faster than the receiver or intermediate network

equipment can process the transmissions. Flow control can be implemented by messaging from receiver

to sender.

Getting the data across a network is only part of the problem for a protocol. The data received has to be

evaluated in the context of the progress of the conversation, so a protocol has to specify rules describing

the context. These kind of rules are said to express the syntax of the communications. Other rules

determine whether the data is meaningful for the context in which the exchange takes place. These kind of

rules are said to express the semantics of the communications. Both intuitive descriptions as well as more

formal specifications in the form of finite state machine models are used to describe the expected

interactions of the protocol. Formal ways for describing the syntax of the communications are Abstract

Syntax Notation One (a ISO standard) or Augmented Backus-Naur form (a IETF standard).

Protocol design

Communicating systems operate in parallel. The programming tools and techniques for dealing with

parallel processes are collectively called concurrent programming. Concurrent programming only deals

with the synchronization of communication. The syntax and semantics of the communication governed by

a low-level protocol usually have modest complexity, so they can be coded with relative ease. High-level

protocols with relatively large complexity could however merit the implementation of language

interpreters. An example of the latter case is the HTML language.

Concurrent programming has traditionally been a topic in operating systems theorie texts. Formal

verification seems indispensable, because concurrent programs are notorious for the hidden and

sophisticated bugs they contain. A mathematical approach to the study of concurrency and

communication is referred to as Communicating Sequential Processes (CSP). Concurrency can also be

modelled using finite state machines like Mealy- and Moore machines. Mealy- and Moore machines are

in use as design tools in digital electronics systems, which we encounter in the form of hardware used in

telecommunications or electronic devices in general.

This kind of design can be a bit of a challenge to say the least, so it is important to keep things simple. For

the Internet protocols, in particular and in retrospect, this meant a basis for protocol design was needed to

allow decomposition of protocols into much simpler, cooperating protocols

The OSI Model

The Open Systems Interconnection (OSI) is a seven-layer protocol stack model used as a reference

throughout the computer industry. The ISO was developed as a functional reference model only. One

must note that some well known protocols such as TCP/IP and Signaling System 7 (SS7) were developed

before the OSI model, and therefore do not exactly align with the defined OSI boundaries, where protocol

stacks like IBM’s SNA have a very close relationship. However, when used as a reference, the OSI model

gives us a general idea of what to expect from the various layers of a given protocol stack.

Page 9: HDLC Report

NUST-SEECS & NEXTEK Services

9

OSI Stack Protocol Model;

Page 10: HDLC Report

NUST-SEECS & NEXTEK Services

10

CHAPTER 2

HDLC Protocol:

HDLC (High Level Data Link Control) is one of the most common data link layer (layer 2) protocols.

Many other common layer 2 protocols are heavily based on HDLC, particularly its framing structure. The

HDLC protocol is defined by ISO for use on both point-to-point and multipoint (multidrop) data links. It

supports full duplex transparent-mode operation and is now extensively used in both multipoint and

computer networks.

The rule of HDLC is to ensure that the data has been received without any loss or errors and in the correct

order. HDLC has a flow control function which ensures that the data is transmitted as fast as the receiver

can receive it.

High-level Data Link Control (HDLC) is an enhanced derivative of SDLC from IBM. HDLC is the

default serial link protocol for Cisco routers. Nearly all other routers on the market use PPP for link

control. HDLC is a Data Link layer protocol. These protocols allow computers on either end of a physical

connection (end stations) to communicate.

There are two distinct HDLC implementations: HDLC NRM (also known as SDLC) and HDLC Link

Access Procedure Balanced (LAPB), the later is a more popular implementation. HDLC is usually used

by X.25.

LAPB is a bit-oriented synchronous protocol that provides complete data transparency in a full-duplex

point-to-point operation. It supports a peer-to-peer link in that neither end of the link plays the role of the

permanent master station. HDLC NRM, on the other hand, has a permanent primary station with one or

more secondary stations.

HDLC LAPB is a very efficient protocol, which requires a minimum of overhead to ensure flow control,

error detection and recovery. If data is flowing in both directions (full duplex), the data frames themselves

carry all the information required to ensure data integrity.

The concept of a frame window is used to send multiple frames before receiving confirmation that the

first frame has been correctly been received. This means that data can continue to flow in situations where

there may be long "turn-around" time lags without stopping to wait for an acknowledgement. This kind of

situation occurs, for instance in satellite communication.

Types of HDLC Stations:

Primary

Primary stations manage the connection to all secondary sessions by sending commands. Primary

stations open and close connections and poll remote stations for data, or availability. Primary stations

are used primarilly in multi-point networks or with mainframe applications where the mainframe is

the primary station. The primary station uses unbalanced mode to communicate with the secondary

stations. The primary station is responsible for all error detection, line control and data flow control.

Secondary

Secondary machines respond to commands sent from the Primary. Secondary stations are

usually terminals attatched to mainframes. Communication between secondary stations and

Page 11: HDLC Report

NUST-SEECS & NEXTEK Services

11

primary stations is in unbalanced mode. The secondary station can only respond to the primary

station and only when signaled to do so by the primary station.

Combined

Combined stations can establish and tear down their own connections. A combined station has the

capabilities of both primary and secondary stations. These station types are usually used in point-to-point

serial links such as a V.35 link to a CSU/DSU or between routers connected by a T1 or frame relay.

Communication between two combined stations is in balanced mode.

Configurations of HDLC:

HDLC also defines three types of configurations for the three types of stations. The word configuration

refers to the relationship between the hardware devices on a link. Following are the three configurations

defined by HDLC:

Unbalanced Configuration

Balanced Configuration

Symmetrical Configuration

Unbalanced Configuration

The unbalanced configuration in an HDLC link consists of a primary station and one or more secondary

stations. The unbalanced condition arises because one station controls the other stations. In an unbalanced

configuration, any of the following can be used:

Full-Duplex or Half-Duplex operation

Point to Point or Multi-point networks

An example of an unbalanced configuration can be found below in Fig

Balanced Configuration

The balanced configuration in an HDLC link consists of two or more combined stations. Each of the

stations has equal and complimentary responsibility compared to each other. Balanced configurations can

use only the following:

Page 12: HDLC Report

NUST-SEECS & NEXTEK Services

12

Full - Duplex or Half - Duplex operation

Point to Point networks

An example of a balanced configuration can be found below in Fig

Symmetrical Configuration

This third type of configuration is not widely in use today. It consists of two independent point-

to-point, unbalanced station configurations as shown in Fig.In this configuration, each station has a

primary and secondary status. Each station is logically considered as two stations.

HDLC Operation Modes;

HDLC has three operational modes:

1. Normal Response Mode (NRM)

Normal Response Mode is used in unbalanced configurations, a configuration is which there is only one

primary, controlling station. In this mode, slave stations (or secondary) can only transmit when specially

instructed by the master (primary station). The link may be point-to-point or multipoint. In the latter case

only one primary station is allowed.

2. Asynchronous Response Mode (ARM)

Asynchronous Response Mode is used in unbalanced configurations. It allows a secondary station to

initiate a transmission without receiving permission from the primary station. This mode is normally used

with point-to-point configurations and full duplex links and allows the secondary station to send frames

asynchronously with respect to the primary station.

3. Asynchronous Balanced Mode (ABM)

The Asynchronous Balanced Mode (ABM) is used mainly on full duplex point-to-point links for

computer to computer communications and for connections between a computer and a packed switched

data network, in this case each station has an equal status and performs the role of both primary and

secondary functions. This mode is used in the protocol set known as X.25.

HDLC Non-Operational Modes;

HDLC also defines three non-operational modes. These three non-operational modes are:

Normal Disconnected Mode (NDM)

Asynchronous Disconnected Mode (ADM)

Initialization Mode (IM)

Page 13: HDLC Report

NUST-SEECS & NEXTEK Services

13

The two disconnected modes (NDM and ADM) differ from the operational modes in that the secondary

station is logically disconnected from the link (note the secondary station is not physically disconnected

from the link). The IM mode is different from the operations modes in that the secondary station's data

link control program is in need of regeneration or it is in need of an exchange of parameters to be used in

an operational mode.

Protocol Structure - HDLC: High Level Data Link Control

Frame Format

The standards frame of the HDLC protocol handles both data and control messages.

It has the following format:

Flag Address Control Information FCS Flag

1 Byte 1-2 Bytes 1 Byte variable 2 Bytes 1 Byte

The Flag field

Every frame on the link must begin and end with a flag sequence field (F). Stations attached to the data

link must continually listen for a flag sequence. The flag sequence is an octet looking like 01111110.

Flags are continuously transmitted on the link between frames to keep the link active. Two other bit

sequences are used in HDLC as signals for the stations on the link. These two bit sequences are:

Seven 1's, but less than 15 signal an abort signal. The stations on the link know there is a problem

on the link.

15 or more 1's indicate that the channel is in an idle state.

The time between the transmissions of actual frames is called the interframe time fill. The interframe

time fill is accomplished by transmitting continuous flags between frames. The flags may be in 8 bit

multiples.

HDLC is a code-transparent protocol. It does not rely on a specific code for interpretation of line control.

This means that if a bit at position N in an octet has a specific meaning, regardless of the other bits in the

same octet. If an octet has a bit sequence of 01111110, but is not a flag field, HLDC uses a technique

called bit-stuffing to differentiate this bit sequence from a flag field as we have discussed in the previous

lesson.

At the receiving end, the receiving station inspects the incoming frame. If it detects 5 consecutive 1's it

looks at the next bit. If it is a 0, it pulls it out. If it is a 1, it looks at the 8th bit. If the 8th bit is a 0, it

knows an abort or idle signal has been sent. It then proceeds to inspect the following bits to determine

appropriate action. This is the manner in which HDLC achieves code-transparency. HDLC is not

concerned with any specific bit code inside the data stream. It is only concerned with keeping flags

unique.

Address field

The address of the secondary station which is sending the frame or the destination of the frame sent by the

primary station. The address field contains Service Access Point (6bits), a Command/Response bit to

indicate whether the frame relates to information frames (I-frames) being sent from the node or received

by the node, and an address extension bit which is usually set to true to indicate that the address is of

Page 14: HDLC Report

NUST-SEECS & NEXTEK Services

14

length one byte. When set to false it indicates an additional byte follows. The address field may be

extended to more than one byte by agreement between the involved parties.

Control field :

It identifies the type of the frame. In addition, it includes sequence numbers, control features and error

tracking according to the frame type.

Information field –

Data is transmitted in the information field, which can vary in length depending upon the protocol using

the frame. Layer 3 frames are carried in the information field.

FCS –

The Frame Check Sequence (FCS) is in most cases - 16 bit wide and serves for errors detection, the

generator polynomial used is normally CRC-CCITT: x^16+x^12+x^5+1 .

HDLC uses zero insertion/deletion process (commonly known as bit stuffing) to ensure that the bit pattern

of the delimiter flag does not occur in the fields between flags. The HDLC frame is synchronous and

therefore relies on the physical layer to provide method of clocking and synchronizing the transmission

and reception of frames.

Field Name Size(in bits)

Flag Field( F ) 8 bits

Address Field( A ) 8 bits

Control Field( C ) 8 or 16 bits

Information Field( I ) OR Data Variable; Not used in some frames

Frame Check Sequence( FCS ) 16 or 32 bits

Closing Flag Field( F ) 8 bits

Categories of Frames;

There are three categories of frames:

Information framestransport data across the link and may encapsulate the higher layers of the OSI

architecture.

Supervisory framesperform the flow control and error recovery functions.

Unnumbered framesprovide the link initialization and termination.

In the HDLC protocol three classes of frames are used:

Page 15: HDLC Report

NUST-SEECS & NEXTEK Services

15

1. Unnumbered frames

Unnumbered frames are used for link management. . SNRM and SABM frames, for example, are used

both to set up logical link between the primary and the secondary station and to inform the secondary

station of the mode of operation to be used. A logical link is subsequently cleared by the primary station

sending a DISC frame. The UA frame is used as an acknowledgment to the other frames in this class.

Unnumbered Format Commands and responses (U-Frame) The unnumbered format commands and responses are used to extend the number of data link control

functions. The unnumbered format frames have 5 modifier bits, which allow for up to 32 additional

commands and 32 additional response functions. Below, 13 command functions, and 8 response functions

are described.

Set Normal Response Mode (SNRM) places the secondary station into NRM. NRM does not allow the

secondary station to send any unsolicited frames. Hence the primary station has control of the link.

Set Asynchronous Response Mode (SARM) allows a secondary station to transmit frames without a

poll from the primary station.

Set Asynchronous Balanced Mode (SABM) sets the operational mode of the link to ABM.

Disconnect (DISC) places the secondary station in to a disconnected mode.

Set Normal Response Mode Extended (SNRME) increases the size of the control field to 2 octets

instead of one in NRM. This is used for extended sequencing. The same applies for SARME and SABME.

Set Initialization Mode (SIM) is used to cause the secondary station to initiate a station-specific

procedure(s) to initialize its data link level control functions.

Unnumbered Poll (UP) polls a station without regard to sequencing or acknowledgment.

Unnumbered Information (UI) is used to send information to a secondary station.

Exchange Identification (XID) is used to cause the secondary station to identify itself and provide the

primary station identifications characteristics of itself.

Page 16: HDLC Report

NUST-SEECS & NEXTEK Services

16

Reset (RSET) is used to reset the receive state variable in the addressed station.

Test (TEST) is used to cause the addressed secondary station to respond with a TEST response at the

first response opportunity. It performs a basic test of the data link control.

Unnumbered Acknowledgment (UA) is used by the secondary station to acknowledge the receipt and

acceptance of an SNRM, SARM, SABM, SNRME, SARME, SABME, RSET, SIM, or DISC commands.

Disconnected Mode (DM) is transmitted from a secondary station to indicate it is in disconnected

mode(non-operational mode.)

Request Initialization Mode (RIM) is a request from a secondary station for initialization to a primary

station. Once the secondary station sends RIM, it can only respond to SIM, DSIC, TEST or XID

commands.

Request Disconnect (RD) is sent by the secondary station to inform the primary station that it wishes to

disconnect from the link and go into a non-operational mode(NDM or ADM).

Frame Reject (FRMR) is used by the secondary station in an operation mode to report that a condition

has occurred in transmission of a frame and retransmission of the frame will not correct the condition.

2. Information frames

Information frames are those who carry the actual data. The Information frames can be used to piggyback

acknowledgment information relating to the flow of Information frames in the reverse direction when the

link is being operated in ABM or ARM.

3. Supervisory frames

Supervisory frames are use for error and flow control. They contain, send and receive sequence numbers.

There are four types of supervisory frames but only RR and RNR are used in both NRM and ABM. These

frames are used both to indicate the willingness of a secondary station to receive an information frame

from the primary station, and for acknowledgment purposes. REJ and SREJ frames are used only in ABM

which permits simultaneous two-way communication across a point to point link. The two frames are

used to indicate to the other station that a sequence error has occurred, that is an information frame

containing an out of sequence N(s) has been received. The SREJ frame is used with a selective repeat

transmission procedure, whereas the REJ frame is used with a go back N procedure.

Supervisory Format commands and responses are as follows:

Page 17: HDLC Report

NUST-SEECS & NEXTEK Services

17

Receive Ready (RR) is used by the primary or secondary station to indicate that it is ready to receive an

information frame and/or acknowledge previously received frames.

Receive Not Ready (RNR) is used to indicate that the primary or secondary station is not ready to

receive any information frames or acknowledgments.

Reject (REJ) is used to request the retransmission of frames.

Selective Reject (SREJ) is used by a station to request retransmission of specific frames. An SREJ must

be transmitted for each erroneous frame; each frame is treated as a separate error. Only one SREJ can

remain outstanding on the link at any one time.

In a Nutshell;

Information Transfer Information Transfer

Format Commands Format Responses I - Information I - Information

Supervisory Format Supervisory Format

Commands Responses RR - Receive ready RR - Receive ready

RNR - Receive not ready RNR - Receive not ready

REJ - Reject REJ - Reject

SREJ - Selective reject SREJ - Selective reject

Unnumbered Format Unnumbered Format

Commands Commands SNRM - Set Normal Response Mode UA - Unnumbered Acknowledgment

SARM - Set Asynchronous Response Mode DM - Disconnected Mode

SABM - Set Asynchronous Balanced Mode RIM - Request Initialization Mode

DISC - Disconnect RD - Request Disconnect

SNRME - Set Normal Response Mode Extended UI - Unnumbered Information

SARME - Set Asynchronous Response Mode Extended XID - Exchange Identification

SABME - Set Asynchronous Balanced Mode Extended FRMR - Frame Reject

SIM - Set Initialization Mode TEST - Test

UP - Unnumbered Poll

UI - Unnumbered Information

XID - Exchange identification

RSET - Reset

TEST - Test

The Poll/Final Bit (P/F)

The 5th bit position in the control field is called the poll/final bit, or P/F bit. It can only be recognized

when it is set to 1. If it is set to 0, it is ignored. The poll/final bit is used to provide dialogue between the

primary station and secondary station. The primary station uses P=1 to acquire a status response from the

secondary station. The P bit signifies a poll. The secondary station responds to the P bit by transmitting a

data or status frame to the primary station with the P/F bit set to F=1. The F bit can also be used to signal

the end of a transmission from the secondary station under Normal Response Mode.

Page 18: HDLC Report

NUST-SEECS & NEXTEK Services

18

CHAPTER 3

Protocol Operation

The two basic functions in the protocol are link management and data transfer (which includes error and

flow control).

Link management

Prior to any kind of transmission (either

between two stations connected by a point to

point link or between a primary and

secondary station connected with a

multidrop link) a logical connection between

the two communication parties must be

established.

A logical connection between the two

communication parties is accomplished by the exchange of two unnumbered frames. The procedure for

setting a logical connection (In a multidrop link) is given below:

The SNRM is first sent by the primary station with the poll bit set to 1 and the address of the appropriate

secondary in the address field. The secondary responds with a UA frame with the final bit set and its own

address in the address field. After all the data has been transferred, the link is cleared by the primary

sending a DISC frame and the secondary responding with a UA.

Data transfer

In NRM all data (information frames) is transferred under the control of the primary station. The

unnumbered poll frame with the P bit set to 1 is normally used by the primary to poll a secondary. If the

secondary has no data to transmit, it returns an RNR frame with the F bit set. If data is waiting, it

transmits the data, typically as a sequence of information frames.

The two most important aspects associated with the data transfer phase are error control and flow control.

Essentially, error control uses a continuous RQ procedure with either a selective repeat or a go back N

transmission strategy, while flow controls based on a window mechanism.

Page 19: HDLC Report

NUST-SEECS & NEXTEK Services

19

Transparency

The flag sequence must never occur within the content of a frame otherwise it could be confused with an

intentionally sent flag. A technique known as 0-bit insertion is used to prevent random data synthesising a

flag. The technique is said to make HDLC transparent, since any stream of bits may be present between

the open and closing flag of a frame. The transparency is achieved by encoding the data by inserting a 0-

bit after any sequence of 5 consecutive 1's within the payload, as shown:

Insertion of a "zero-bit" into the content of a frame to ensure transparency

Bit stuffing and removal

Page 20: HDLC Report

NUST-SEECS & NEXTEK Services

20

FSM of Transparency:

Hardware Implementation: HDLC protocol finds its application in vast. It can be used with fax machines. Fax machine needs proper

communication between two ends. The data is being transferred and received is continuously monitored

so that to avoid loss in information and effective operation of protocol. For this HDLC controller is

preferred.

Detailed Design:

Here is a detailed design for HDLC protocol operation. In this design we want to monitor the data

transmitted from both end. As it is clear HDLC is single and multipoint communication protocol so

modem are typically used for proper data management and modem sharing device(MSD) is used to

distribute data among multipoint. These behave like cluster controllers.

We can transmit data serially through to the modem from two computers as well as we can use two

FPGA. Using two FPGA’s is difficult to implement because it needs extensive programming, cost,

circuitry and maintenance. So better approach is by using computers and sending data serially.

Data is de-framed for reception where it is to be monitored. This process is already defined above. Just for

this we need and FPGA interfaced with computer.

Page 21: HDLC Report

NUST-SEECS & NEXTEK Services

21

Requirements:

Computers

FPGA Virtex 5

Modem CX86500

Modem sharing Device 3010

Framing:

The data from transmitting end is framed and send via link. Here is simple FSM of the framing.

Page 22: HDLC Report

NUST-SEECS & NEXTEK Services

22

Design:

Master Modem Modem Slave

Deframing FPGA

Serial Interface with PC for monitoring

Page 23: HDLC Report

NUST-SEECS & NEXTEK Services

23

De-Framing:

De-framing is done on the monitoring end.

Modem Sharing Device:

The Model 3010 Three Port Modem Sharing Device allows three POS terminals, ATMs or similar RS-

232 devices to share a single RS-232 modem or multiplexer. The Model 3010 requires no AC power or

batteries, operates asynchronously or synchronously and is small enough to plug directly into the DB-25

serial port on a modem or multiplexer.

The Model 3010 operates by allowing the modem to pass data and control signals to all three DTE

devices in parallel. Concurrently, the Model 3010 monitors each DTE device to see if it has data to send

to the modem. When a terminal has data to send, it raises RTS and all its data and control signals are

routed to the modem. As soon as that terminal is finished sending data, the Model 3010 resumes

monitoring. If two or three terminals raise RTS simultaneously, the Model 3010 prioritizes the inputs:

DTE channel one has priority over channel two, and channel two has priority over channel three.

The Model 3010 has three DB-25 female DTE ports and on DB-25 male modem port. Either all

connected devices must be asynchronous or they must all be synchronous: The Model 301 performs no

data conversion. The DTE ports are labeled DTE #1, DTE #2 and DTE #3. The modem port is labeled

MODEM. As figure (below) illustrates, input port DTE #1 is on one end of the unit. DTE ports DTE #2

and DTE #3 are on top when the Model 3010 is oriented in a normal fashion.

Page 24: HDLC Report

NUST-SEECS & NEXTEK Services

24

DTE Device Modem

2 (TD) ------------------------------------------2 (RD)

4 (RTS) ----------------------------------------4 (RTS)

5 (CTS) ----------------------------------------5 (CTS)

20 (DTR) --------------------------------------20 (DTR)

Modem:

The typical Modem is CX86500. The CX86500 modem, packaged in a 28-pin TSSOP and 38-pin

TSSOP, includes a Microcontroller (MCU), a Modem Data Pump (MDP), internal ROM, internal

RAM, and SmartDAA interface functions. The modem connects to host via a logical V.24 (EIA/TIA-

232-E) serial DTE interface or a parallel 16550 UART-compatible host interface (38-pin only). The

modem MCU/DSP performs the command processing, host interface functions and telephone line

signal modulation/demodulation which reduces computational load on the host processor.

The SmartDAA Interface communicates with, and supplies power and clock to the LSD through the

DIB.

It has following features.

• Modulations and protocols

− ITU-T V.92

♦ Modem-on-Hold

(MOH)

♦ Quick connect (QC)

♦ PCM upstream

V.90/V.34/V.32bis/V.32

V.22bis/V.22/V.23/V.21

− V.23 reverse, V.23

half-duplex

− Bell 212A/Bell 103

− V.29 FastPOS

− V22bis fast connect

− V.80 Synchronous

Access Mode

• Data compression

− V.44/V.42bis/MNP5

• Error correction

− V.42/MNP 4/MNP 2

• Call Waiting (CW)

detection

• Type I and Type II

Caller ID (CID) decoding

• DTE/host interface

− Serial DTE interface

Page 25: HDLC Report

NUST-SEECS & NEXTEK Services

25

− Parallel 16550 UART-

compatible host interface

(38-pin version)

− Direct Mode

− Synchronous Mode

− Asynchronous Mode

• No external memory

required

• Sixty-three embedded

and upgradeable country

profiles

• Serial NVRAM

interface for optional

permanent country

profile storage (38-pin

version)

• Embedded AT

commands

• Full-duplex Voice Pass-

Through Mode

− Mu-Law, A-Law

(serial and parallel host

interface)

− 14-bit PCM (parallel

host interface only)

• SmartDAA

− Extension pick-up

detection

− Digital line protection

− Line reversal detection

− Line-in-use detection

− Remote hang-up

detection

− Worldwide compliance

• Selectable 28.224 MHz

or 27.000 MHz

frequency of operation

• Low power and voltage

− Single +3.3V supply

− Low power

consumption mode

− +3.3V I/O level

• Compact, robust board

design

− Small, low-profile

modem packages

− SmartDAA and DIB

technologies

Page 26: HDLC Report

NUST-SEECS & NEXTEK Services

26

Some of the applications of modem are:

Set top boxes

Point-of-Sale terminals

ATM machines

Metering terminals

Video game consoles

Internet appliances

Page 27: HDLC Report

NUST-SEECS & NEXTEK Services

27

Data Reception:

Page 28: HDLC Report

NUST-SEECS & NEXTEK Services

28

Chapter 4

Reception:

`timescale 1ns / 1ps

//////////////////////////////////////////////////////////////////////////////////

// Company:

// Engineer:

//

// Create Date: 05:37:42 08/24/2011

// Design Name:

// Module Name: hdlc_recv

// Project Name:

// Target Devices:

// Tool versions:

// Description:

//

// Dependencies:

//

// Revision:

// Revision 0.01 - File Created

// Additional Comments:

//

//////////////////////////////////////////////////////////////////////////////////

module hdlc_recv(ihdlc_RXD,

ihdlc_RXCLK,

ihdlc_RESET,

ohdlc_TXD,

ohdlc_TXCLK,

ohdlc_TXDS

);

/**************************************************************************/

///*** input signals define ***///

/**************************************************************************/

input ihdlc_RXD;

input ihdlc_RXCLK;

input ihdlc_RESET;

/**************************************************************************/

///*** outputs define ***///

/**************************************************************************/

output ohdlc_TXCLK;

Page 29: HDLC Report

NUST-SEECS & NEXTEK Services

29

output [7:0] ohdlc_TXD;

output [2:0] ohdlc_TXDS;

reg ohdlc_TXCLK;

reg [7:0] ohdlc_TXD;

reg [2:0] ohdlc_TXDS;

reg [2:0] ohdlc_TXDS_tmp;

/**************************************************************************/

///*** inner signals define ***///

/**************************************************************************/

reg error; // illegal byte detectived when equal 1

reg error_wire;

reg error_flag;

reg delete_zero; // 5 "1" detectived when equal 1

reg delete_zero_wire;

reg frame_end; // end of a normal frame

reg flag_7e; // "7e" detectived when equal 1

reg [3:0] bit_counter;

reg [6:0] byte_counter;

reg [7:0] shifter1;

reg [7:0] shifter2;

reg [2:0] byte_rst_counter;

reg byte_rst_counter_start;

/**************************************************************************/

///*** 5 "1"& illegal frame detectiver state machine define ***///

/**************************************************************************/

reg [6:0] flagdetc_cur_state;

reg [6:0] flagdetc_next_state;

parameter idle = 7'b000_0001,

flag1 = 7'b000_0010,

flag2 = 7'b000_0100,

flag3 = 7'b000_1000,

flag4 = 7'b001_0000,

flag5 = 7'b010_0000,

flag6 = 7'b100_0000;

/**************************************************************************/

///*** series shifter ***///

/**************************************************************************/

always @(posedge ihdlc_RXCLK or negedge ihdlc_RESET)

begin

if(!ihdlc_RESET)

Page 30: HDLC Report

NUST-SEECS & NEXTEK Services

30

begin

shifter2[7:0] <= 8'b0;

end

else

begin

if(delete_zero_wire)

begin

shifter2[7:0] <= shifter2[7:0];

end

else

begin

shifter2[7:0] <= {shifter2[6:0],shifter1[7]};

end

end

end

always @(posedge ihdlc_RXCLK or negedge ihdlc_RESET)

begin

if(!ihdlc_RESET)

begin

shifter1[7:0] <= 8'b0;

end

else

begin

if(flag_7e)

begin

shifter1[7:0] <= {shifter1[6:0],ihdlc_RXD};

end

else

begin

shifter1[7:0] <= {shifter1[6:0],ihdlc_RXD};

end

end

end

/**************************************************************************/

///*** "7E" detectiver ***///

/**************************************************************************/

always @(shifter1[7:0] or byte_counter[6:0] or bit_counter[3:0] or byte_rst_counter_start)

begin

if(shifter1[7:0]==8'h7e)

begin

if(byte_counter[6:0]!=0)

begin

if(bit_counter[3:0]==4'b1111||bit_counter[3:0]==4'b0111)

Page 31: HDLC Report

NUST-SEECS & NEXTEK Services

31

flag_7e = 1'b1;

else

flag_7e = 1'b0;

end

else

begin

flag_7e = 1'b1;

end

end

else

begin

flag_7e = 1'b0;

end

end

/**************************************************************************/

///*** detectiver state machine ***///

/**************************************************************************/

always @(posedge ihdlc_RXCLK or negedge ihdlc_RESET)

begin

if(!ihdlc_RESET)

begin

delete_zero <= 1'b0;

error <= 1'b0;

flagdetc_cur_state <= idle;

end

else

begin

flagdetc_cur_state <= flagdetc_next_state;

delete_zero <= delete_zero_wire;

error <= error_wire;

end

end

/*************************************************************************/

//*** 5 "1"series & illegal frame detective ***//

/*************************************************************************/

always @(flagdetc_cur_state or shifter1[7])

begin

case (flagdetc_cur_state)

idle :

begin

error_wire = 1'b0;

delete_zero_wire = 1'b0;

if(shifter1[7]==1'b0)

begin

Page 32: HDLC Report

NUST-SEECS & NEXTEK Services

32

flagdetc_next_state = idle;

end

else

begin

flagdetc_next_state = flag1;

end

end

flag1 : //////////////////////////////////1 "1"

begin

if(shifter1[7]==1'b1)

begin

flagdetc_next_state = flag2;

end

else

begin

flagdetc_next_state = idle;

end

end

flag2 : //////////////////////////////////2 "1"

begin

if(shifter1[7]==1'b1)

begin

flagdetc_next_state = flag3;

end

else

begin

flagdetc_next_state = idle;

end

end

flag3 : //////////////////////////////////3 "1"

begin

if(shifter1[7]==1'b1)

begin

flagdetc_next_state = flag4;

end

else

begin

flagdetc_next_state = idle;

end

end

flag4 : ///////////////////////////////////4 "1"

begin

if(shifter1[7]==1'b1)

begin

flagdetc_next_state = flag5;

end

Page 33: HDLC Report

NUST-SEECS & NEXTEK Services

33

else

begin

flagdetc_next_state = idle;

end

end

flag5 : ////////////////////////////////////5 "1"

begin

if(shifter1[7]==1'b1)

begin

flagdetc_next_state = flag6;

end

else

begin

flagdetc_next_state = idle;

delete_zero_wire = 1'b1;

end

end

flag6 : ////////////////////////////////////6 "1" and more

begin

if(shifter1[7]==1'b1)

begin

flagdetc_next_state = flag6;

if(bit_counter==4'b1101) //for test

error_wire = 1'b1;

end

else

begin

flagdetc_next_state = idle;

//if(bit_counter==4'b1101)

error_wire = 1'b1; // for test

end

end

default:

begin

flagdetc_next_state = idle;

end

endcase

end

/**************************************************************************/

////** State Machine end **//

/**************************************************************************/

Page 34: HDLC Report

NUST-SEECS & NEXTEK Services

34

/**************************************************************************/

///*** byte_reset counter ***///

/**************************************************************************/

always @(posedge ihdlc_RXCLK or negedge ihdlc_RESET)

begin

if(!ihdlc_RESET)

begin

byte_rst_counter[2:0] <= 3'b0;

end

else

begin

if(byte_rst_counter_start)

byte_rst_counter[2:0] <= byte_rst_counter[2:0] + 1;

else

byte_rst_counter[2:0] <= 3'b0;

end

end

always @(posedge ihdlc_RXCLK or negedge ihdlc_RESET)

begin

if(!ihdlc_RESET)

begin

byte_rst_counter_start <= 1'b0;

end

else

begin

if(byte_rst_counter[2:0]==3'b111)

byte_rst_counter_start <= 1'b0;

else if(flag_7e)

byte_rst_counter_start <= 1'b1;

end

end

/**************************************************************************/

///*** bit_counter & byte_counter ***///

/**************************************************************************/

always @(posedge ihdlc_RXCLK or negedge ihdlc_RESET) // bit_counter

begin

if(!ihdlc_RESET)

begin

bit_counter[3:0] <= 4'b0;

end

else

begin

if(flag_7e||(shifter1[7:0]==8'b1111_1111&&(byte_counter==7'b0&&bit_counter<=4'b1000)))

begin

Page 35: HDLC Report

NUST-SEECS & NEXTEK Services

35

bit_counter[3:0] <= 4'b0;

end

else

begin

if(bit_counter!=4'b1111)

begin

if(delete_zero_wire!=1'b1)

bit_counter[3:0] <= bit_counter[3:0] + 1;

end

else

begin

if(delete_zero_wire!=1'b1)

bit_counter[3:0] <= 4'b1000;

end

end

end

end

always @(posedge ihdlc_RXCLK or negedge ihdlc_RESET) // byte_counter

begin

if(!ihdlc_RESET)

begin

byte_counter[6:0] <= 7'b0;

end

else

begin

if(byte_rst_counter[2:0]==3'b111)

begin

byte_counter[6:0] <= 7'b0;

end

else

begin

if(bit_counter==4'b1111&&delete_zero!=1'b1)

begin

if(byte_counter[6:0]!=7'b111_1111)

byte_counter[6:0] <= byte_counter[6:0] + 1;

else

byte_counter[6:0] <= byte_counter[6:0] ;

end

end

end

end

/**************************************************************************/

Page 36: HDLC Report

NUST-SEECS & NEXTEK Services

36

///*** TXData Status ***///

/**************************************************************************/

always @(byte_counter[6:0] or error_flag or frame_end or error_wire)

begin

if(frame_end)

begin

if(error_flag||error_wire)

ohdlc_TXDS_tmp[2:0] = 3'b000; // illegal frame_end

else if(byte_counter>64||byte_counter==64&&!delete_zero)

ohdlc_TXDS_tmp[2:0] = 3'b001; // long frame_end

else if(byte_counter<=2||byte_counter==3&&delete_zero)

ohdlc_TXDS_tmp[2:0] = 3'b010; // short frame_end

else if(byte_counter!=0)

ohdlc_TXDS_tmp[2:0] = 3'b011; // normal frame_end

else

ohdlc_TXDS_tmp[2:0] = 3'b111; // unvalued data

end

else

begin

if(!error_flag)

begin

if(byte_counter==1)

ohdlc_TXDS_tmp[2:0] = 3'b110; // first byte

else if(byte_counter==2)

ohdlc_TXDS_tmp[2:0] = 3'b101; // second byte

else if(byte_counter!=0)

ohdlc_TXDS_tmp[2:0] = 3'b100; // other byte

else

ohdlc_TXDS_tmp[2:0] = 3'b111; // unvalued data

end

else

ohdlc_TXDS_tmp[2:0] = 3'b111; // unvalued data

end

end

always @(posedge ihdlc_RXCLK or negedge ihdlc_RESET)

begin

if(!ihdlc_RESET)

begin

ohdlc_TXDS <= 3'b111;

end

else

begin

if(byte_rst_counter_start!=1'b1||flag_7e)

ohdlc_TXDS <= ohdlc_TXDS_tmp;

end

end

Page 37: HDLC Report

NUST-SEECS & NEXTEK Services

37

/**************************************************************************/

///*** Output CLK Generator ***///

/**************************************************************************/

always @(posedge ihdlc_RXCLK or negedge ihdlc_RESET)

begin

if(!ihdlc_RESET)

begin

ohdlc_TXCLK <= 1'b1;

end

else

begin

if(bit_counter[3:0]==4'b1111||ohdlc_TXDS==3'b111||error||error_flag)

begin

ohdlc_TXCLK <= 1'b1;

end

else

if((bit_counter[3:0]==4'b1011||byte_rst_counter[2:0]==3'b100)&&ohdlc_TXDS!=3'b111)

begin

ohdlc_TXCLK <= 1'b0;

end

else ohdlc_TXCLK <= ohdlc_TXCLK;

end

end

/**************************************************************************/

///*** output Data load ***///

/**************************************************************************/

always @(posedge ihdlc_RXCLK or negedge ihdlc_RESET)

begin

if(!ihdlc_RESET)

begin

ohdlc_TXD[7:0] <= 8'b0;

end

else

begin

if(bit_counter[3:0]==4'b1111)

ohdlc_TXD[7:0] <= shifter2[7:0];

end

end

/**************************************************************************/

///*** frame_end signal generator ***///

/**************************************************************************/

always @(shifter1[7:0] or bit_counter[3:0])

begin

begin

if(shifter1[7:0]==8'h7e&&bit_counter[3:0]==4'b1111)

begin

Page 38: HDLC Report

NUST-SEECS & NEXTEK Services

38

frame_end = 1'b1;

end

else

begin

frame_end = 1'b0;

end

end

end

/**************************************************************************/

///*** error_flag generater ***///

/**************************************************************************/

always @(posedge ihdlc_RXCLK or negedge ihdlc_RESET)

begin

if (!ihdlc_RESET)

begin

error_flag <= 1'b0 ;

end

else

begin

if(byte_rst_counter[2:0]==3'b111)

begin

error_flag <= 1'b0 ;

end

else

begin

if(error_wire&&byte_counter[6:0]!=7'b0)

error_flag <= 1'b1;

else if(error_wire&&bit_counter[3:0]==4'b1101) //for test

error_flag <= 1'b1; // for test

else

error_flag <= error_flag;

end

end

end

endmodule