CSE 555Protocol Engineering

Dr. Mohammed H. SqalliComputer Engineering Department

King Fahd University of Petroleum & Minerals

Credits: Dr. Abdul Waheed (KFUPM)

Spring 2004 (Term 032)

Protocol Design

Term 032 5-1-3 COE555-Sqalli

Topics (Ch. 7)

Service specification Assumptions about the channel Protocol vocabulary Message format Procedure rules

We use an example protocol as a running case study to explain the above protocol design steps

Term 032 5-1-4 COE555-Sqalli

Protocol Design So far, we have focused on:

Protocol specification Validation against a set of standard correctness problems

How can we apply this knowledge to a real design problem?

Use an example for a file transfer protocol Use systematic protocol specification Procedure rules with explicit correctness criteria

Important design rule: Before implementing, build a high level prototype

A validation model is going to be our prototype Verify that the design criteria are met

Term 032 5-1-5 COE555-Sqalli

Main Focus

We make two crucial assumptions about the design process

Protocol design is an iterative process Each time a design phase is completed, we, the designers,

will be convinced that it is error-free

Our concern is design and correctness

Important to keep in mind that we are building a validation model, not an implementation

The model is an abstraction, and as such it is a design tool in itself

Term 032 5-1-6 COE555-Sqalli

File Transfer Protocol One sender and one receiver

It is a point-to-point protocol Protocols with multiple receivers are called multi-point or

broadcast protocols Provides end-to-end service

Two users on two different machines Communicating through possibly many intermediate machines

Procedure rules Will be specified through validation models Models can be checked on their correctness properties individually

or in combination Models can be refined and adjusted with the help of verification

tools Other protocol specifications:

Service specifications Assumptions about environment (i.e., transmission channel) Protocol vocabulary Message format

Term 032 5-1-7 COE555-Sqalli

Service Specifications

Reliable end-to-end file transfer service is needed: Connection establishment Connection termination Recovery from transmission errors Flow control strategy (to prevent overflowing the receiver)

Transmission characteristics of the protocol: Must be able to transfer ASCII text files

One at a time Probability of undetected bit error < 1 in 108 bits

transmitted User should be able to abort a file transfer in progress Protocol should be able to recover from message loss

Term 032 5-1-8 COE555-Sqalli

Assumptions About the Channel Full-duplex channel using a voice-grade switched telephone

line Dedicated line does not require routing, congestion control, etc. This assumption allows us to focus on concurrency control

Assume that transfers take place over a distance of 4500 Km

Propagation time of a signal in a cable ~ 30,000 Km/sec Minimum time for a message to propagate = 0.15 sec Signaling speed = 1200 bps (using a standard modem)

Assume that transmission is character-oriented Using ASCII character encoding

Error characteristics of the channel: Most errors are caused by:

Noise spikes Echoes Cross-talk

Term 032 5-1-9 COE555-Sqalli

Assumptions About the Channel (Cont’d)

Bit error rates are not uniformly distributed Errors occur in bursts Assuming Poisson distribution of errors, the error-free

interval (EFI) is given as:

where 1/f is the average duration of the error-free interval

We use f = 8x10-6, which corresponds to: An average error-free interval of 125,000 bit transmissions or An EFI of about 100 sec

Term 032 5-1-10 COE555-Sqalli

Assumptions About the Channel (Cont’d)

Error bursts: We need to predict the probability that a given burst lasts

at least n bit transmissions Using Mandelbrot’s function:

where a and g are parameters

Precise values of these parameters should be derived from measurements on the telephone channel used

Values determine the type of error control method to be used We assume a = 0.9 and g = 0.009

Term 032 5-1-11 COE555-Sqalli

Assumptions About the Channel (Cont’d)

Average duration of burst error: 12 bit transmission time About 10 msec

At error rate of no more than 1 in 108 transmitted bits, at 1200 bps:

Expected EFI = 23 hours

Probability of a burstDepends on its length

Term 032 5-1-12 COE555-Sqalli

Protocol Vocabulary

Protocol environment A data link to communicate with the remote system Internal message channels to communicate with:

Local user and Local file server

Term 032 5-1-13 COE555-Sqalli

Protocol Vocabulary (Cont’d)

Four phases of a file transfer, in a specific order: Connection establishment with local file server Connection establishment with remote system Data transfer Orderly termination of the connection

Types of messages from local user: Initiation of file transfer:

transfer (file_descriptor) Must trigger a message (i.e., open) to the local file server to

verify that the file exists and finds out its size Message from user to interrupt a transfer:

abort

Term 032 5-1-14 COE555-Sqalli

Protocol Vocabulary (Cont’d) Types of message to/from the local file server:

A message to the local file server to verify that the file exists and get its size: open (file_descriptor)

An incoming connect, at remote side, triggers a message to file server to verify that the file with the given size an be storedcreate(size)

File server response: accept(size): returns the file size to the calling process or reject(status): returns a parameter indicating the reason

To transfer count bytes of data from buffer ptr: data(count, ptr)

End of file: eof

Term 032 5-1-15 COE555-Sqalli

Protocol Vocabulary (Cont’d) Type of messages to/from remote system:

connect (size): If file can be opened, its size is determined, and a connection request is made from the local to the remote system

Accept Reject Data Ack: used to implement a simple flow control discipline

that acknowledges correctly received data Sync: for flow control layers to agree on initial seq #s Sync_ack: acknowledgement of the above Eof Close: Confirms correct completion of a file transfer, with

the eof message

Term 032 5-1-16 COE555-Sqalli

Protocol Vocabulary (Cont’d)

Assume synchronous local communication Use rendezvous communication between local system and

local file server Six messages:

open, create, accept, reject, data, and eof Equivalent to local procedure calls Guarantees that unused data messages to/from the file

server do not accumulate Data transfer

Requires successful local open and remote create requests

Use data messages to transfer data from local file server to remote file server using the protocol to be developed

Term 032 5-1-17 COE555-Sqalli

Message Format

Minimal message format requirements: A type field An optional data field A sequence number to implement flow control A checksum field to implement error control

Each message can be formatted as a sequence of bytes Byte oriented channel At the highest level, a message is encoded into a series of bytes Message length will vary depending on h1, h2, D, and t1 The lowest level (physical layer) inserts delimiters using ASCII 8-bit

patterns Start of text: STX End of text: ETX Uses byte stuffing

Term 032 5-1-18 COE555-Sqalli

Message Format (Cont’d) Message type field

We have 13 different types of messages Need 4 bits to represent them h1 = 4

Sequence number field Message propagation time = 0.15 sec 180 bits Time until ack arrives with no delays = 0.3 sec 360 bits So, 360 bits long message can be transmitted without any delay to

receiver before receiving the acknowledgement Value of h2 depends on:

Round-trip propagation delay; and Number of bytes in header, trailer, and data field Example: Selective repeat continuous ARQ method 2(h2-1) outstanding

messages with a sequence number field of h2 bits. If h2=2, 2 messages may be outstanding sender can transmit one message while awaiting ack for another. If message is at least 360 bits long, no time is lost

Term 032 5-1-19 COE555-Sqalli

Message Format (Cont’d) The data field:

It can have variable length Too long data field probability of errors increases with bits

Average EFI was estimated at 125,000 bits Too small data field overhead due to header and trailer is large

Minimum size of message that is transmitted without any delay: 360 bits Optimal data length: 45 < D < 15625 Doptimal = 376 bytes

Checksum field Error rate is low no need for an error correcting code For message length well below 125Kbits, most messages get through

without transmission errors Needs to catch burst errors. Depends on the length of the burst (in this case: 12bits) and target residual

bit-error rate (in this case: 10-8) Choosing 16-bit checksum t1 = 16

Summary:struct {

unsigned type : 4;unsigned seqno : 2;unsigned char data[376];unsigned char checksum[2];

} message;

Term 032 5-1-20 COE555-Sqalli

Procedure Rules

Need complete and consistent rules To be verified before implementation We can use PROMELA model to design and debug rules PROMELA was designed for this purpose

Issues: How to abstract messages Protocol layering and global structure Refine all the layers to combine into final design

Term 032 5-1-21 COE555-Sqalli

Abstraction for Messages Level of representation

We need a model and not an implementation We can abstract out unnecessary details Consider only the semantics of the protocol, not its precise

syntax Many details are irrelevant for validation model:

Low level data encoding details Contents of transferred files Variable length of Data field Use of checksum field

We can represent a message using only two fields: A message type; and A sequence number

Both fields can be of type byte

Term 032 5-1-22 COE555-Sqalli

Layers

Protocol design is structured into three layers: Presentation layer

User interacts with this layer Session control layer

Interacts with the file server Data link layer

Enforces general flow control discipline It is physical data line with modems and responsible for

encoding and error detection using checksum Data link can lose but not distort the messages

Each layer is represented as a PROMELA process

Term 032 5-1-23 COE555-Sqalli

Assumptions About Protocol Environment

We now need to formalize all assumptions about the environment

The environment consists of three entities: User process File server Data link

Assumptions about environment can be formalized in PROMELA

User behavior Message channels File server behavior Data link behavior

Term 032 5-1-24 COE555-Sqalli

Assumptions: User Behavior We can consider two user level processes

One at each end of the data link

User interactions: Submits a transfer request at any time to presentation layer

Passes file descriptor to the presentation layer May decide to abort a transfer at any time

Protocol response: Successful or unsuccessful transfer Lower layers pass this response to the user

Assumption: After submitting a command user waits for the response

We model this behavior with following PROMELA code…

Term 032 5-1-25 COE555-Sqalli

Assumptions: User Behavior (Cont’d) We model assumptions using following process:

proctype userprc(bit n){ use_to_pres[n]!transfer;

if:: pres_to_use[n]?accept goto Done:: pres_to_use[n]?reject goto Done:: use_to_pres[n]!abort goto Abortedfi;

Aborted:if:: pres_to_use[n]?accept goto Done:: pres_to_use[n]?reject goto Donefi;

Done:skip

} Binary argument n identifies the user and the channels it

accesses Message transfer will carry a file descriptor

Not important for validation model

Term 032 5-1-26 COE555-Sqalli

Assumptions: Message Channels

Channels are defined globally, and represent communication between layers

chan use_to_pres[2] = [QSZ] of { byte };chan pres_to_use[2] = [QSZ] of { byte };chan pres_to_ses[2] = [QSZ] of { byte };chan ses_to_pres[2] = [QSZ] of { byte, byte };chan ses_to_flow[2] = [QSZ] of { byte, byte };chan flow_to_ses[2] = [QSZ] of { byte, byte };chan dll_to_flow[2] = [QSZ] of { byte, byte };chan flow_to_dll[2] = [QSZ] of { byte, byte };

Channels for synchronous communication between session layer and file server

chan ses_to_fsrv[2] = [0] of { byte };chan fsrv_to_ses[2] = [0] of { byte };

Term 032 5-1-27 COE555-Sqalli

Assumptions: File Server Behavior

We can eliminate unnecessary details Parameters, such as fd, size, cnt, and ptr do not contribute to validation process Specify how these two modules interact (file server and session layer) Important to specify when data is passed rather than which data is passed

Term 032 5-1-28 COE555-Sqalli

Assumptions: File Server Behavior (Cont’d) A better way to model file server:

proctype fserver (bit n){ do

:: ses_to_fsrv[n]?create -> /* incoming */if:: fsrv_to_ses[n] !reject:: fsrv_to_ses[n] !accept ->

do:: ses_to_fsrv[n]?data:: ses_to_fsrv[n]?eof -> break:: ses_to_fsrv[n]?close -> breakod

fi:: ses_to_fsrv[n] ?open -> /* outgoing */

…}

Term 032 5-1-29 COE555-Sqalli

Assumptions: File Server Behavior (Cont’d)

Model for outgoing data: :: ses_to_fsrv[n]?open -> /* outgoing */

if:: fsrv_to_ses[n]!reject:: fsrv_to_ses[n]!accept ->

do

:: fsrv_to_ses[n]!data:: fsrv_to_ses[n]!eof -> break:: ses_to_fsrv[n]?close -> breakod

fi

Term 032 5-1-30 COE555-Sqalli

Assumptions: Data Link Behavior

Data link is assumed to be protected by an error detection protocol

It is a calculation and does not involve any interaction Calculation of checksum is not important for validation

model It is not modeled in PROMELA

The interest is in the external behavior of the data link Data link can lose an arbitrarily selected message This loss is non-deterministic

Modeled by the following PROMELA process

Term 032 5-1-31 COE555-Sqalli

Assumptions: Data Link Behavior (Cont’d)

Proctype data_link(){ byte type, seq;

do:: flow_to_dll[0]?type,seq ->

if:: dll_to_flow[1]!type,seq:: skip /* lose */fi

:: flow_to_dll[1]?type,seq ->if:: dll_to_flow[0]!type,seq:: skip /* lose */fi

od}