CSE 555 Protocol Engineering Dr. Mohammed H. Sqalli Computer Engineering Department King Fahd...

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 (Cont.)

Term 032 5-2-3 COE555-Sqalli

Design of Layers

We have completed formalizing assumptions about the environment

We now consider the design of three core protocol layers:

Presentation layer Session layer Flow control layer


Presentation Layer Design Function of the presentation layer:

Interface with the user Takes care of file transfer details:

Example: resubmission of a file transfer request when a non-fatal error results in failure of previous request

Possible reasons of failure of a transfer request: Local system is busy serving an incoming file transfer request

Transient cause Local file server rejects request because file does not exist Remote file server rejects request due to lack of storage

space A collision between incoming and outgoing requests

Transient case User aborted file transfer requests

Presentation layer needs to protect itself from duplicates due to repeated aborts


Presentation Layer Design (Cont’d)

Presentation layer has two states: Idle state Transfer state

Transition: idletransfer state Occurs upon the arrival of user’s transfer request Transition back to idle state when request is completed or

on detection of a fatal error

Validation model for presentation layer in PROMELA


Presentation Layer Design (Cont’d)

File transfer request is repeated until:

It succeeds; or Triggers a fatal

error


Presentation Layer: Correctness Criteria

Valid end states for the presentation layer Only one valid end state (i.e., idle state)

Replace IDLE with endIDLE in the model Presentation state should be in the end state when a

transfer terminates It can be proved with SPIN that this requirement is met

when assumptions about session and link layer hold


Session Layer Design

Protocol will have four phases: Initialization of the file server Connection establishment Data transfer Call completion

Messages have an ordering requirement: A transfer request should precede a connection

confirmation A connection establishment precedes data transfer

We can use a state transition diagram to understand some of the above relationships and ordering requirements


Session Layer Design (Cont’d)

Writing state diagram forced further design decisions: A connection request may come from remote system directly after processing of local

connection request has started collision We chose to reject both colliding calls

Successful file transfer ends with eof (6) Otherwise abort (4)

Expected events foroutgoing messages

Normal incoming file transfer

? Incoming messages! Outgoing messages

Message types:1: Transfer2: Connect3: Accept4: Reject5: Close6: Eof


Session Layer: Call Establishment Phase Session layer tasks after receiving local transfer

request from the presentation layer: It must try to open the file on the local system It must establish a connection with the remote system It must create a file on the remote system

All of the above three tasks can potentially fail Local file server must take care of all file accesses Only two messages can trigger a file transfer

Local transfer Remote connect Everything else should be ignored by the session protocol

Model for session layer follows…


Session Layer: Modelproctype session(bit n){ bit toggle;

byte type, status;IDLE:

do:: pres_to_ses[n]?type ->

if:: (type == transfer) -> goto DATA_OUT:: (type != transfer) /* ignore*/fi

:: flow_to_ses[n]?type ->if:: (type == connect) -> goto DATA_IN:: (type != connect) /* ignore */fi

od;

DATA_OUT:...

DATA_IN:...

} Incoming and outgoing data transfer phases are modeled

separately with labels DATA_IN and DATA_OUT, respectively


Session Layer: Model for Incoming Data

DATA_IN: /* prepare local file server */ses_to_fsrv[n]!create;do:: fsrv_to_ses[n]?reject ->

ses_to_flow[n]!reject;goto IDLE

:: fsrv_to_ses[n]?accept ->ses_to_flow[n]!accept;break

od;

… incoming data transfer …… close connection at end …

Model for outgoing data follows…


Session Layer: Model for Outgoing Data An outgoing transfer takes three steps:

Handshake with local file server on local open request Initialization of the flow control layer Handshake with remote system on connect request

All of the above steps may fail The first step is modeled as follows:

DATA_OUT: /* 1. Prepare local file */ses_to_fsrv[n]!open;if:: fsrv_to_ses[n]?reject ->

ses_to_pres[n]!reject(FATAL);goto IDLE

:: fsrv_to_ses[n]?accept ->skip /* proceed */

fi


Session Layer: Model for Outgoing Data Precaution necessary for the second phase:

An old sync_ack should not be accepted accidentally May arrive due to a previous initialization attempt

/* 2. Initialize flow control */ses_to_flow[n]!sync, toggle;do:: flow_to_ses[n]?sync_ack, type ->

if:: (type != toggle) /* ignore */:: (type == toggle) -> break;fi

:: timeout -> /* failed */ses_to_fsrv[n]!close;ses_to_pres[n]!reject(FATAL);goto IDLE

od;toggle = 1 – toggle;


Session Layer: Model for Outgoing Data The third step for outgoing data:

Possibility of collision should be considered

/* 3. Prepare remote file */ses_to_flow[n]!connectif:: flow_to_ses[n]?accept ->

skip /* success */:: flow_to_ses[n]?reject ->

ses_to_fsrv[n]!close;ses_to_pres[n]!reject(FATAL);goto IDLE

:: flow_to_ses[n]?connect -> /* collisions */ ses_to_fsrv[n]!close;

ses_to_pres[n]!reject(NON_FATAL);goto IDLE

:: timeout -> /* got disconnected */ses_to_fsrv[n]!close;ses_to_pres[n]!reject(FATAL);goto IDLE

fi;… Outgoing data transfer and then close connection …


Session Layer: Data Transfer Phases Outgoing data transfers:

Obtain data from file server and transfer them to the flow control Two messages can interrupt transfer: timeout or abort

Model:do /* outgoing data */:: fsrv_to_ses[n]?data ->

ses_to_flow[n]!data:: fsrv_to_ses[n]?eof ->

ses_to_flow[n]!eof;status = COMPLETE;break /* goto call termination

*/:: pres_to_ses[n]?abort -> /* user aborts */

ses_to_fsrv[n]!close;ses_to_flow[n]!close;status = FATAL;break /* goto call termination

*/od;


Session Layer: Data Transfer Phases (Cont’d) Incoming data transfers:

From flow control to presentation layer Only remote user can abort an incoming transfer

Local system receives a close when remote user aborts Model:

do /* incoming data */:: flow_to_ses[n]?data ->

ses_to_fsrv[n]!data:: flow_to_ses[n]?eof ->

ses_to_fsrv[n]!eofbreak

:: pres_to_ses[n]?transfer -> /* busy */ses_to_pres[n]!reject(NON_FATAL)

:: flow_to_ses[n]?close -> /* remote user aborts */

break:: timeout /* got disconnected */

ses_to_fsrv[n]!close;goto IDLE

od;


Session Layer: Call Termination Phase This phase is reached only from transfer phase Model for a normal termination of outgoing transfer session:

/* close connection, outgoing transfer */do:: pres_to_ses[n]?abort /* too late, ignored */:: flow_to_ses[n]?close ->

if:: (status == COMPLETE) ->

ses_to_pres[n]!accept:: (status != COMPLETE) ->

ses_to_pres[n]!reject(status)fi;break;

:: timeout -> /* disconnected? */ses_to_pres[n]!reject(FATAL);Break

od;goto IDLE


Session Layer: Call Termination Phase (Cont’d)

Code for responding to termination of an incoming:

/* close connection, incoming transfer */ses_to_flow[n]!close /* confirm it */goto IDLE


Session Layer: Correctness Requirements

Session layer correctness requirements are based on satisfying the assumptions made by the presentation layer protocol

Two requirements: Session layer responds to a transfer message, within a

finite amount of time, with either an accept or a reject message to local presentation layer

A remote connect message should be followed by an accept or a reject message to remote presentation layer, within a finite amount of time

The above requirements are expressed as temporal claims by defining behavior that is required to be absent


Session Layer: Correctness Criterianever {

do:: !pres_to_ses[n]?[transfer] && !flow_to_ses[n]?[connect]:: pres_to_ses[n]?[transfer] ->

goto accept0:: flow_to_ses[n]?[connect]->

goto accept1od;

accept0:do:: !ses_to_pres[n]?[accept] && !ses_to_pres[n]?[reject]od;

accept1:do:: !ses_to_pres[1-n]?[accept] && !ses_to_pres[1-n]?[reject]od

} n is either zero or one

The IDLE state is marked as end-state as: endIDLE


Design of Data Link Layer

It has two parts: Flow control layer Error control layer

Error control layer is not important for validation model Not modeled

Flow control layer uses a sliding window protocol Window size (W) and sequence # range (M) have to be

defined in the model


Design of Flow Control Layer

Flow control (fc) model definitions:#define true 1 /* for convenience */#define false 0#define M 4 /* range sequence number */#define W 2 /* window size: M/2 */

proctype fc (bit n){ bool busy[M]; /* outstanding messages */

byte q; /* seq # oldest unacked msg */

byte m; /* seq # last msg received */byte s; /* seq # next msg to send */byte window; /* # of outstanding msgs */byte type; /* msg type */bit received[M]; /* receiver housekeeping */bit x; /* scratch variable */Byte p; /* seq # of last msg acked */byte I_buf[M], O_buf[M]; /* message buffers */...

}


Design of Flow Control Layer (Cont’d) Need to model independent sender and receiver actions

Full duplex communication Need to keep track of incoming and outgoing messages

Outgoing messages are stored in O_buf, indexed by seq # Buffering allows protocol to retransmit unack’ed messages Boolean array busy is used to keep track of empty and used

slots for outgoing messages Main functions of flow control layer:

Checks for outgoing messages from session layer Adds sequence numbers Forwards message to (lower) error control layer Keeps track of message acks

Checks for incoming messages from error control layer Strips sequence #s Forwards remainder of messages to session layer


FC Layer: Model for Outgoing Messages A message can be sent only when it is available

i.e., message channel ses_to_flow is non-empty Also, the lower protocol layer should be free to accept it

i.e., message channel flow_to_dll is non-full

Model for outgoing message from flow control layer:do:: (window < W && len(ses_to_flow[n]) > 0

&& len(flow_to_dll[n]) < QSZ) ->

ses_to_flow[n]?type;window = window+1;busy[s] = true;O_buf[s] = type;flow_to_dll[n]!type, s;


FC Layer: Outgoing Sync Messages Session layer uses sync message to reset flow control protocol

All busy flags are cleared Sequence number returns to zero

if:: (type != sync) ->

s = (s+1)%M:: (type == sync) ->

window = 0;s = M;do:: (s > 0) ->

s = s+1;busy[s] = false

:: (s == 0) ->Break

odfi


FC Layer: Acks for Outgoing messages

Arrival of an ack message results in following: Sequence number m of ack message points to the message

which is being acknowledged Status of that message kept in busy[m] is reset to zero

(i.e., slot has become free)

Model of the corresponding receiver code::: dll_to_flow[n]?type,m ->

if:: (type == ack) ->

busy[m] = false…


FC Layer: Acks for Oldest Outgoing Msg

Arrival of an ack belonging to the oldest outstanding message results in:

Window sliding up multiple notches to make room for more messages to be transmitted

Advancement of window is guarded with a timeout clause against lost messages

Model:

:: (window > 0 && busy[q] == false) ->window = window – 1;q = (q+1)%M

:: (timeout && window > 0 && busy[q] == true) ->flow_to_dll[n]!O_buf[q],q


FC Layer: Modeling Incoming Messages

Messages are received in a generic clause:

:: dll_to_flow[n]?type,m ->

This is followed by a switch on the message type

Incoming messages are buffered Out of order messages can be handled These messages are forwarded to session layer in order A boolean array received is used to keep track of arrived

and pending messages


FC Layer: Modeling Incoming Sync and Sync_ack Messages The sync message initializes the flow control layer

Incoming message comes from remote peer It should be acknowledged with sync_ack after re-initialization

completes Incoming sync_ack from remote peer are passed to the session

layer protocol Model:

if...:: (type == sync) ->

m = 0;do:: (m < M) ->

received[m] = 0;m = m + 1;

:: (m == M) -> break;od;flow_to_dll[n] !sync_ack, m

:: (type == sync_ack) ->flow_to_ses[n] !sync_ack, m


FC Layer: Incoming Data Messages All messages other than sync and sync_ack are

considered data messages When a data message arrives:

We need to check whether or not it is a duplicate If it was received before, we have received[m] == true

We need to check whether it has been acknowledged Messages are acknowledged after they have been passed to

the session layer protocol (and freed up buffer space they held)

If the message has not been received before: It needs to be stored in the buffer Appropriate flags need to be set

If we are certain that the message is not a duplicate: Only then reset the appropriate received flag True for messages that are one full window size away form last

received message


FC Layer: Model for Incoming Data Msgs

:: (type != ack && type != sync && type != sync_ack) ->

if:: (received[m] == true) ->

x = ((0<p-m && p-m<=W) || (0<p-m+M && p-m+M<=W));if /* lost

ack */:: (x) -> flow_to_dll[n]!

ack,m:: (!x) /* skip */fi

:: (received[m] == false) ->I_buf[m] = type;received[m] = true;received[(m-W+M)%M] = false

fi


FC Layer: Accepting Incoming Messages

Arriving message is internally copied to an input buffer

Model::: (received[p] == true && len(flow_to_ses[n]) < QSZ && len(flow_to_dll[n]) < QSZ) ->

flow_to_ses[n]!I_buf[p];flow_to_dll[n]!ack,p;p = (p+1)%M

od


FC Layer: Correctness Criteria Two correctness requirements for flow control protocol:

Transfers messages without deletions Transfers messages without reordering

Expressing correctness requirements: Label each message at the sender side Check at the receiver side that:

No label has been lost Relative ordering of the labels is unchanged

Question: given a FC protocol with window size W and a range of seq #s M, how many distinct labels would minimally be needed to check the above correctness requirements?

Answer: only three!! (due to Pierre Wolper) This number is independent of W or M


FC Layer: Correctness Checking Labels Consider following checking scenario:

We transmit sequences of messages through FC layer Messages carry only the label and no other data Three labels are arbitrarily called: red, white, and blue Corresponding messages are called red, white, and blue

messages We construct a range of test sequences:

An infinite sequence of white messages One red and one blue message are placed randomly in above

sequence of white messages We can restate the correctness criteria as:

If FC protocol can lose a message, it will be able to lose red or blue message in at least one of the test sequences

If FC protocol can ever reorder two messages, it will be able to change the order of red and blue messages in at least one sequence


FC Layer: Test Sequence Generators FC layer sender module:

proctype test_sender(bit n){do:: ses_to_flow[n]!white:: ses_to_flow[n]!red ->breakod;do:: ses_to_flow[n]!white:: ses_to_flow[n]!blue ->breakod;do:: ses_to_flow[n]!white:: breakod}

FC layer receiver module at remote end:proctype test_receiver(bit n){do:: flow_to_ses[n]?white:: flow_to_se[n]?red ->breakod;do:: flow_to_ses[n]?white:: flow_to_ses[n]?blue ->breakod;do:: flow_to_ses[n]?white:: breakod

}


FC Layer: Correctness Criteria Correctness criteria can be specified using assertions at receiver

end:

proctype test_receiver (bit n){ do

:: flow_to_ses[n]?White:: flow_to_ses[n]?red -> break:: flow_to_ses[n]?blue -> assert(0) /* error */od;do:: flow_to_ses[n]?white:: flow_to_ses[n]?red -> assert(0) /* error */:: flow_to_ses[n]?blue -> breakod;do:: flow_to_ses[n]?white:: flow_to_ses[n]?red -> assert(0) /* error */:: flow_to_ses[n]?blue -> assert(0) /* error */od

}

CSE 555 Protocol Engineering Dr. Mohammed H. Sqalli Computer Engineering Department King Fahd...

Documents

Transcript of CSE 555 Protocol Engineering Dr. Mohammed H. Sqalli Computer Engineering Department King Fahd...