Part 5: Protocol Specification, Verification (PSV)

1
Part 5 Protocol Specification, Verification (PSV)

• Overview
• finite state machines
• petri net models
• temporal logic
• Goal
• a flavor of the approaches and proof techniques

• Motivation
• Q how to specify a protocol, verify its
  correctness properties?
• want formalism for unambiguously describing,
  reasoning about their properties

2
PSV using Finite State Machines (FSM)

• each protocol entity (e.g., sender, receiver)
  and channel connecting them have states
• protocol entity states typically correspond for
  times when entity waiting for some event
• channel state indicates contents of channel
• for each state zero or more transitions out of
  state (to a new state) when event occurs
• protocol entity typically when msg received or
  timeout
• channel msg sent into channel, received from
  channel

3
PSV using FSMs example

• reliable data transfer protocol
• channel can lose, corrupt messages
• assume maximum channel delay known, so no
  premature timeouts
• at most one message in channel at a time
• assume new messages always available to be sent

event causing state transition
actions taken on state transition
state when in this state next state uniquely
determined by next event
4
PSV using FSMs example sender FSM
L
rdt_rcv(rcvpkt) ( corrupt(rcvpkt)
get_data(data)
sndpkt make_pkt(0, data, checksum) udt_send(sndp
kt) start_timer
L
rdt_rcv(rcvpkt) notcorrupt(rcvpkt)
timeout
udt_send(sndpkt) start_timer
stop_timer
get_data(data)
sndpkt make_pkt(0, data, checksum) udt_send(sndp
kt) start_timer
timeout
rdt_rcv(rcvpkt) notcorrupt(rcvpkt)
udt_send(sndpkt) start_timer
stop_timer
get_data(data)
rdt_rcv(rcvpkt) ( corrupt(rcvpkt)
sndpkt make_pkt(1, data, checksum) udt_send(sndp
kt) start_timer
L
5
PSV using FSMs example receiver FSM
rdt_rcv(rcvpkt) corrupt(rcvpkt)
L
rdt_rcv(rcvpkt) notcorrupt(rcvpkt)
has_seq1(rcvpkt)
Wait for DATA0
rdt_rcv(rcvpkt) notcorrupt(rcvpkt)
has_seq1(rcvpkt)
deliver_data1
sndpkt make_ack(checksum) udt_send(sndpkt)
sndpkt make_ack(checksum) udt_send(sndpkt)
rdt_rcv(rcvpkt) notcorrupt(rcvpkt)
has_seq0(rcvpkt)
Wait for DATA1
rdt_rcv(rcvpkt) notcorrupt(rcvpkt)
has_seq0(rcvpkt)
sndpkt make_ack(checksum) udt_send(sndpkt)
deliver_data0
rdt_rcv(rcvpkt) corrupt(rcvpkt)
sndpkt make_ack(checksum) udt_send(sndpkt)
L
6
PSV using FSMs example summary

• sender FSM is in state 0 or 1 (sending 0 or 1)
• receiver FSM is in state 0 or 1 (waiting for 0 or
  1)
• channel state
• empty
• ACK
• 0 data message propagating
• 1 message propagating
• Note 0/1 sequence numbers not needed here (not
  used by receiver). Will be used to state
  correctness properties shortly

7
PSV using FSMs global system state

• sender, receiver, channel each have individual
  states
• generate global system state 3 tuple indicating
  sender state, receiver state, channel state
• global state is cross product of sender,
  receiver, channel state

sender state (0 or 1)
channel state (0, 1, A ack, - empty)
receiver state (0 or 1)
8
PSV using FSMs global system FSM
pkt delivered up at Rcvr?
0
transition event
who runs
pkt input
pkt output
7
7
0
0
5
1
2
4
3
6
0
8
0
0
8
9
Proving properties using FSMs

• proofs of protocol properties reasoning about
  paths thru global FSM
• deadlock-free is there a transition out of every
  state?
• livelock free transition out of every subset of
  states?
• correctness criteria 1 never deliver two 1-pkts
  up without an intervening 0-pkt delivered up
• true for all paths through graph
• correctness criteria 2 sender never changes
  states 0-to-1-to-0 without receiver also changing
  state
• true for all paths through graph

10
Potential Drawbacks of PSV with FSMs

• how do we know specification is correct?
• maybe code (or implementation itself) is a
  better way to specify. Can generate FSM
  automatically from implementation.
• coming up with correctness criteria is hard (no
  mechanical way to determine the criteria), and
  the criteria can be stated and proved multiple
  ways
• FSM can not deal with certain behaviors (e.g.,
  unbounded number of variable values)
• And even if values is bounded, need a state for
  every value state space explosion

11
Petri net models

• Petri net models have 4 basic elements
• places represents states of system
• tokens dots, that move between places
• transitions
• indicated by horizontal or vertical bar or box
• zero or more input arcs coming from input places
• zero or more output arcs going to output places
• transition is enabled IFF one or more tokens all
  input places
• enabled transitions fire remove one token from
  each input place, put one token in each output
  place
• multiple transitions can be enabled firing
  choice is non deterministic

12
Petri net models
Petri net with two places, two transitions,
before firing
after firing
13
Petri Net Structures

• sequence of events/actions
• concurrent execution

14
Petri Net Structures

• Non-deterministic events - conflict, choice or
  decision choice of either e1, e2 or e3, e4 ...

15
Petri Net Structures

• synchronization

16
Example Restaurant Scenario
17
Petri net example of reliable data transfer
protocol
C data0 in channel D ACK in channel E data1 in
channel
send ACK
get ACK1 send data0
1
10
C
8
2
A
F
wait ACK0
wait data1
timeout
5
reject 0
loss
D
send ACK
get ACK0 send data1
3
11
6
loss
4
9
B
G
wait ACK1
wait data0
E
timeout
reject 1
7
loss
receiver state
sender state
channel
18
Proving properties using Petri nets

• as with FSMs, prove properties of protocols by
  reasoning about paths to reachable markings of
  Petri net
• deadlock-free transition always enabled?
• livelock free transition out of every subset of
  states?
• correctness never deliver two 1-pkts up without
  an intervening 0-pkt delivered up
• true for all paths through all reachable markings
• correctness sender never changes states
  0-to-1-to-0 without receiver also changing state

19
PSV using program verification

• consider protocols as programs
• use program verification techniques
• logical assertions attached to program (e.g.,
  invariant property) allow reasoning about sets
  of states, avoiding state space explosion
• safety properties bad things will not happen
• Invariants that are always true
• liveliness properties good things will happen
• e.g., recurrent protocol properties
• temporal logic provides operators to reason about
  future states

20
PSV using program verification

• consider programs as flowcharts, with logical
  assertions attached to arcs
• assertions must be true when execution passes
  through arc
• execution of program statement determines
  assertion on output arc, based on assertion
  attached to input arc

start
i1
S0
i gt n ?
no
S S ai
i i1
program to compute
21
Temporal Logic

• Provide operators for reasoning about future
  sequence of states arising from program execution
• Two basic operators
• w eventually wP means that condition P will
  eventually be true in all future executions of
  the program
• henceforth 0P means that will always be true for
  all future executions of the program
• Examples
• 0P is the same as wP
• 0w(the buffer is not full) infinitely often the
  case that in the future that the buffer is not
  full
• w0(all process are waiting) means ??

22
Temporal Logic History variables

• History variables will record sequence of
  messages sent, received from channel
• If A, B are history variables, A lt B means that
  A is a prefix of B
• u(A) means that A is unbounded
• u(A) for all n (0(lAln g wlAlgtn))
• c(A,m) equals number of occurrences of m in A
• uc(A,m) for all n (w(c(A,m) gt n)

23
A simple data transfer protocol sender
process ACK if (mrt.ExistsM) then
mrt.receive(ackno,ack) if (ackno
WaitingForAck) timer.cancel
WaitingForAck fi fi service timeout
if (timer.TimeoutsExists) then
timer.cancel mtr.send(HighestSent,data)
timer.start fi End loop
Begin Sender initialize WaitingForAck
1 HighestSent 0 Loop send message If
HighestSent lt WaitingFor Ack then
HighestSent X.read(data)
mtr.send(HighestSent,data) timer.start fi
24
A simple data transfer protocol receiver
Begin Receiver initialize NextRequired
1 Loop get message mtr.receive(messno,data
) if (messno NextRequired) then
service new message Y.write(data)
NextRequired fi send ACK
mrt.send(NextRequired-1,ack) End loop
25
A simple data transfer protocol channels
ExistsM Receive
X
send
Y
mtr
X read
a
b
Y write
transmitter
receiver
g
d
mrt
ExistsM Receive
send
medium
26
Assumed channel properties
Nothing out that wasnt sent in
ExistsM Receive
send
X
Y
mtr
(mtr1)
a
b
(mrt1)
transmitter
receiver
g
d
Unbounded msgs sent implies msgs infinitely
often available
mrt
send
ExistsM Receive
u(a) g 0w(mtr.ExistsM) (mtr2)
u(g) g 0w(mrt.ExistsM) (mrt2)
If same message sent infinitely often, it will
eventually get through
27
Channel operations
send(m)
ExistsM Receive
send
X
Y
mtr
precondition a A
a
b
postcondition a A ltmgt liveliness
w(after mtr.send)
transmitter
receiver
g
d
mrt
send
ExistsM Receive
receive( var m)
precondition b B
postcondition b B ltmgt liveliness
wmtr.ExistsM g w(after mtr.receive)
28
Proving Safety Properties

• Safety property an invariant assertions about
  variables in sender, receiver, message histories
• Proof technique
• assume assertion holds initially
• show that assertion is preserved by each action
• example prove
• lXl gt k gt 1 g Ak-1 d
• (sender will not send data item k until ACKk-1
  has been received).
• prove by going to program

29
Proving Safety Properties

• Goal prove Y lt X
• data that is passed up at receiver is a
  subsequence of data passed down at sender
• Note does not require that any data be passed up

30
Proving Liveliness Properties

• Proof technique
• reason based on liveliness assumptions of program
  statements
• Example can prove u(a) by inspecting transmitter
  program, noting
• transmitter never blocks
• assume a non-blocking statement eventually
  executes
• Given no blocking, timeout guarantees a msg
  (original or retransmission) sent once every
  timeout interval

31
Proving Liveliness Properties

• Example can prove u(b) by inspecting receiver
  program, noting
• u(a) proven
• Where last statement is proven by inspection of
  receiver code
• Ultimate goal prove u(Y)
• Getting close by proving histories unbounded

u(a) g 0w(mtr.ExistsM) (mtr2)
0w(mtr.ExistsM) g u(b)
32
Protocol Specification, Verification Summary

• Provided overview (flavor) of protocol
  specification and verification techniques
• finite state machines
• petri net models
• temporal logic
• Comments
• state space explosion with state model
• knowing right program assertions requires art,
  expertise in protocol. Hard to automate