1. CSE 555 Protocol Engineering Dr. Mohammed H. Sqalli Computer Engineering Department King Fahd University of Petroleum & Minerals Credits: Dr. Abdul Waheed (KFUPM) Spring 2004 (Term 032)

2. Protocol Design (Cont.)

3. COE555-SqalliTerm 0325-2-3 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

4. COE555-SqalliTerm 0325-2-4 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

5. COE555-SqalliTerm 0325-2-5 Presentation Layer Design (Cont’d)  Presentation layer has two states:  Idle state  Transfer state  Transition: idle  transfer 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

6. COE555-SqalliTerm 0325-2-6 Presentation Layer Design (Cont’d)  File transfer request is repeated until:  It succeeds; or  Triggers a fatal error

7. COE555-SqalliTerm 0325-2-7 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

8. COE555-SqalliTerm 0325-2-8 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

9. COE555-SqalliTerm 0325-2-9 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 for outgoing messages Normal incoming file transfer ? Incoming messages ! Outgoing messages Message types: 1:Transfer 2:Connect 3:Accept 4:Reject 5:Close 6:Eof

10. COE555-SqalliTerm 0325-2-10 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…

11. COE555-SqalliTerm 0325-2-11 Session Layer: Model proctype session(bit n) {bit toggle; bytetype, 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

12. COE555-SqalliTerm 0325-2-12 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…

13. COE555-SqalliTerm 0325-2-13 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

14. COE555-SqalliTerm 0325-2-14 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;

15. COE555-SqalliTerm 0325-2-15 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]!connect if :: 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 …

16. COE555-SqalliTerm 0325-2-16 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;

17. COE555-SqalliTerm 0325-2-17 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]!eof break :: 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;

18. COE555-SqalliTerm 0325-2-18 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

19. COE555-SqalliTerm 0325-2-19 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

20. COE555-SqalliTerm 0325-2-20 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

21. COE555-SqalliTerm 0325-2-21 Session Layer: Correctness Criteria never { do :: !pres_to_ses[n]?[transfer] && !flow_to_ses[n]?[connect] :: pres_to_ses[n]?[transfer] -> goto accept0 :: flow_to_ses[n]?[connect]-> goto accept1 od; 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

22. COE555-SqalliTerm 0325-2-22 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

23. COE555-SqalliTerm 0325-2-23 Design of Flow Control Layer  Flow control (fc) model definitions: #define true1/* for convenience */ #define false0 #define M4/* range sequence number */ #define W2/* window size: M/2*/ proctype fc (bit n) {boolbusy[M];/* outstanding messages */ byteq;/* seq # oldest unacked msg */ bytem;/* seq # last msg received */ bytes;/* seq # next msg to send */ bytewindow;/* # of outstanding msgs */ bytetype;/* msg type */ bitreceived[M];/* receiver housekeeping */ bitx;/* scratch variable */ Bytep;/* seq # of last msg acked */ byteI_buf[M], O_buf[M]; /* message buffers */... }

24. COE555-SqalliTerm 0325-2-24 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

25. COE555-SqalliTerm 0325-2-25 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 0 && len(flow_to_dll[n]) ses_to_flow[n]?type; window = window+1; busy[s] = true; O_buf[s] = type; flow_to_dll[n]!type, s;

26. COE555-SqalliTerm 0325-2-26 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 od fi

27. COE555-SqalliTerm 0325-2-27 FC Layer: Ack s 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 …

28. COE555-SqalliTerm 0325-2-28 FC Layer: Ack s 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

29. COE555-SqalliTerm 0325-2-29 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

30. COE555-SqalliTerm 0325-2-30 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 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

31. COE555-SqalliTerm 0325-2-31 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

32. COE555-SqalliTerm 0325-2-32 FC Layer: Model for Incoming Data Msgs :: (type != ack && type != sync && type != sync_ack) -> if :: (received[m] == true) -> x = ((0 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

33. COE555-SqalliTerm 0325-2-33 FC Layer: Accepting Incoming Messages  Arriving message is internally copied to an input buffer  Model: :: (received[p] == true && len(flow_to_ses[n]) flow_to_ses[n]!I_buf[p]; flow_to_dll[n]!ack,p; p = (p+1)%M od

34. COE555-SqalliTerm 0325-2-34 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

35. COE555-SqalliTerm 0325-2-35 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

36. COE555-SqalliTerm 0325-2-36 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 ->break od; do :: ses_to_flow[n]!white :: ses_to_flow[n]!blue ->break od; do :: ses_to_flow[n]!white :: break od }  FC layer receiver module at remote end: proctype test_receiver(bit n) { do :: flow_to_ses[n]?white :: flow_to_se[n]?red ->break od; do :: flow_to_ses[n]?white :: flow_to_ses[n]?blue ->break od; do :: flow_to_ses[n]?white :: break od }

37. COE555-SqalliTerm 0325-2-37 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 -> break od; do :: flow_to_ses[n]?white :: flow_to_ses[n]?red -> assert(0)/* error */ :: flow_to_ses[n]?blue -> assert(0)/* error */ od }