Reasoning About Active Network Protocols

1. Reasoning About Active Network Protocols Samrat Bhattacharjee Kenneth L. Calvert Ellen W. Zegura

2. Objective • To present a model that supports reasoning about the correctness of • the underlying active network platform • the injected algorithm independent of the injected program

3. Overview • Problem definition and the relationship between the reasoning methods and the network API • Slot based programming model • Example of an underlying program • Example of an injected program

4. Network model • Nodes • Channels • Active node behavior • fixed part • variable part

5. Problem statement • To reason about the global behavior based on • fixed part of each node’s behavior • certain constraints on the injected program • Flexibility of the interface should not be lost

6. Slot based programming model • Slots • Binding to slots • Raising the slot • Form of the Underlying Program • Form of the Injected Program

7. Form of the Underlying Program • Uniform for every node • Union of two programs • N and DS • Interface between Underlying program and the Injected program • Raising of slots ( v.state = slot.i.raise ) • Termination of a slot ( v.state = slot.i.complete ) • Resource accounting • injected program statements can execute only if ( v.rt.i.usage < v.rt.i.bound ) • if ( v.rt.usage = v.rt.i.bound ) DS sets v.state = slot.i.complete • v.Progress.i indicates that slot processing does not deadlock

8. Form of the Underlying Program … • Receptive program • variables partitioned into classes : C, R, W, X • variables read by injected program don’t change ( while the slot is raised ) • injected program increments v.rt.i.usage ( till it reaches v.rt.i.bound ) • slots terminate only when their resources are exhausted • every slot eventually terminates • (compatible with the interface expected by, and is ready to accept injected programs)

9. Form of the Injected Program • Injected program is Acceptable if • all variables named in both N and J are in R or W • no variable in R can be modified in J • Modify program statements (during injection) • in J, to increment v.rt.i.usage • in DS, to check for slot termination • Inj (N, J) – parallel composition of N  DS and J • Properties of Injection • Inj (N, J) is Receptive • P holds inInj ( Inj (N, J), I ) if and only if P holds in Inj (N, I  J) • default slot behavior and program modifications do not affect the parallel composition

10. Properties of Injection … • Pure predicates • Global Safety property • Global Progress property

11. Underlying Program • endpoint • v.outC, v.inC • ErrProc, NullProc • v.state = {idle, slot.i.raise, slot.i.complete, newPkt, routePkt, routeFound} • v.RouteTable(d)

13. Program Node • Initialization • If channel is non-empty read message initialize usage counter • Raise message arrival event • Route message to proper channel • Raise routing done event • Send message on proper channel and update counters

14. Program Node

15. Program DS • Initialization • Set SlotCondition if slot is raised and resource is available • Increase resource usage if no other program active • Terminate slot processing if resource bound is exceeded

16. Program DS

17. Local Node Properties ( Node  DS ) • NP0 – Message processing at any node is bounded • NP1 – All messages in the channel are processed by the Node • NP2 – Messages are routed to the correct next hop Global Node Properties • GP0 – All messages are eventually delivered to their destination

18. Local Node Properties ( Node  DS ) • NP0 –  v.idle  v.idle • NP1 – m i.inC[j]  at(m,i) • NP2 – at(m,v) & D(m) > 0  m  v.outC[j] Global Node Properties • GP0 – at(m,i)  at(m,node(m,d)

19. Injected Program • Identity of Home node for each mobile resource is known at all nodes • State variables in the node indicate the (un)availability of the resource • Each node stores last known location (v.rLoc)and timestamp (v.rLC) • Each resource carries last hop (res.loc)and timestamp (res.ts) • Mobile resource leaves a trail using the Update message • Access message follows the trail • Access messages are stored in v.rQ

20. Transitions for Node State

21. Program - Mobility • Resource r is initially located at r.home; this is known to all other nodes • Re-direct accesses containing stale information • Update local clock and forwarding information if message contains newer information • Resource arrives at node v; Deliver all queued messages • Resource arrived from other node; Increment clock, send message to last known location • Resource migrated back to node v from node v; Increment clock • Access to migrating resource; Queue access, and redirect current message to NullProc • New update; v.rStable detects empty v.rQ • Forward queued messages to new location till queue is empty

22. Program - Mobility

24. Composing Mobility with Node • Safety property specified for writing into v.Msg Stablev.Msg.type  Access & v.Msg = m • From Stable, GP0 we get GP1 GP1 at(m,i) & m.type  Access  at(m, node(m.d)) Properties of Inj(Node, Mobility) • Resource timestamp and logical clocks at each node can only increase • Unstable periods at each node are finite • Each time the resource arrives at a node, the node's logical clock is increased • Periods at which a node is in migration state are always finite.

25. Global properties of Node  Mobility • GP1 at(m,v) & m.type = Access  at(m,m.d) or {  i :: at(m,i) & i.Cur } or { j :: atq(m,j) or j.rLC > m.ts } • Access message always finds the resource, new update or is delivered to its destination • at(m,v) & m.type = Access  at(m,m.d) or {  i :: at(m,i) & i.Cur } or {  j :: atq(m,j) or j.rLC > m.ts } or {  v ::  v.SlotCondition.0 } • Properties of Mobility are preserved unless resource bounds are violated

26. Conclusion • The middle of the road approach seems to be a correct approach to reason about global behavior • Will it be easy to reason about the correctness in a more complex model? • The behavior of the network during the dissemination of the injected code in the network needs to be analyzed