CSE 555 Protocol Engineering Dr. Mohammed H. Sqalli Computer Engineering Department King Fahd...
-
Upload
buck-nelson -
Category
Documents
-
view
220 -
download
2
Transcript of 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
Term 032 5-2-4 COE555-Sqalli
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
Term 032 5-2-5 COE555-Sqalli
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
Term 032 5-2-6 COE555-Sqalli
Presentation Layer Design (Cont’d)
File transfer request is repeated until:
It succeeds; or Triggers a fatal
error
Term 032 5-2-7 COE555-Sqalli
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
Term 032 5-2-8 COE555-Sqalli
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
Term 032 5-2-9 COE555-Sqalli
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
Term 032 5-2-10 COE555-Sqalli
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…
Term 032 5-2-11 COE555-Sqalli
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
Term 032 5-2-12 COE555-Sqalli
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…
Term 032 5-2-13 COE555-Sqalli
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
Term 032 5-2-14 COE555-Sqalli
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;
Term 032 5-2-15 COE555-Sqalli
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 …
Term 032 5-2-16 COE555-Sqalli
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;
Term 032 5-2-17 COE555-Sqalli
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;
Term 032 5-2-18 COE555-Sqalli
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
Term 032 5-2-19 COE555-Sqalli
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
Term 032 5-2-20 COE555-Sqalli
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
Term 032 5-2-21 COE555-Sqalli
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
Term 032 5-2-22 COE555-Sqalli
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
Term 032 5-2-23 COE555-Sqalli
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 */...
}
Term 032 5-2-24 COE555-Sqalli
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
Term 032 5-2-25 COE555-Sqalli
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;
Term 032 5-2-26 COE555-Sqalli
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
Term 032 5-2-27 COE555-Sqalli
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…
Term 032 5-2-28 COE555-Sqalli
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
Term 032 5-2-29 COE555-Sqalli
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
Term 032 5-2-30 COE555-Sqalli
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
Term 032 5-2-31 COE555-Sqalli
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
Term 032 5-2-32 COE555-Sqalli
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
Term 032 5-2-33 COE555-Sqalli
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
Term 032 5-2-34 COE555-Sqalli
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
Term 032 5-2-35 COE555-Sqalli
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
Term 032 5-2-36 COE555-Sqalli
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
}
Term 032 5-2-37 COE555-Sqalli
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
}