Four Logics and a Protocol

The Internet Protocol (IP) is the protocol used to provide connectionless communication between hosts connected to the Internet. It provides a basic internetworking service to transport protocols such as Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). These in turn provide both connection-oriented and connectionless services to applications such as file transfer (FTP) and WWW browsing. In this paper we present four separate specifications of the interface to the internetworking layer implemented by IP using four types of logic: classical, constructive, temporal and linear logic.


Introduction
The Internet Protocol (IP) [1] is used to implement a connectionless internet based on an arbitrary collection of interconnected physical networks.As such, IP provides a virtual internetworking service which allows hosts connected to different physical networks (possibly based on different network technologies) to communicate by exchanging packets of data.The functionality provided by IP is deliberately limited to the connectionless exchange of individual packets of data so as not to require the underlying physical networks to support complex functionality.In particular, IP is defined to be unreliable so that underlying physical networks may (if need be) discard packets, duplicate packets or deliver packets in a different order to which they were sent 1 .As we show in this paper, connectionless transfer and unreliability makes the interface to IP very simple, but makes it difficult to prove strong properties about an IP internet.The unreliability of IP also makes it impractical to implement applications that use IP directly and therefore, most Internet applications use Transmission Control Protocol (TCP) [2].TCP provides a connection-oriented transport service between hosts, i.e., two hosts communicate by setting up a connection and exchanging data.Unlike IP, TCP is reliable; all data that is sent arrives exactly once in the same order it was sent.Since TCP uses IP to send and receive data over an internet, it needs to incorporate complex protocol mechanisms to overcome the inherent unreliability of IP 2 .In this paper we specify the service offered by IP using a number of different formalisms.In particular, we look at how unreliability can be captured and what properties can be established about the service offered by IP.Our longer term goal is to specify the services offered by TCP and prove that these TCP services can be realized by using TCP over IP.

Four Logics and a Protocol
There is presently a vast range of formal specification techniques and methods, based on logic, algebraic and settheoretic approaches, as well as various specialised formalisms for particular application areas.In this paper we deal with logic-based specification and, in particular, present specifications based on four main types of logic: Classical Logic supported by set theory and logic-based modularisation constructs, and expressed here using the Z notation Temporal Logic allowing for reasoning about a system in terms of states, and proving for quantification over transitions between these states; here we use the TLA formalism Constructive Logic a variation of classical logic via an elimination of proof-by-contradiction and an enhanced role for induction; in this paper we use the Coq proof assistant Linear Logic a resource-sensitive logic where the use of formulae as assumptions and conclusions of proofs mirrors the consumption and production of resources by a computational process In presenting these specifications we hope to provide: a case study in the use of various logics a basis for comparison between the logics a formal foundation for further work with higher-level protocols In what follows we informally review the fundamentals of IP, provide a description using each of the four logics, and compare the results.We assume a familiarity with first-order predicate logic; a brief overview of each formalism is given with the specification.

A Brief Description of IP
IP is a protocol that defines how two hosts connected by an internet can format and exchange packets of data known as datagrams.In particular, it defines: How hosts are addressed.
The format of datagrams, i.e., it defines how a datagram is constructed from a header containing various protocol fields and a body containing the data being exchanged between hosts.
The rules for how datagrams should be handled.
Each host will contain software that implements IP and this software will provide a service to other software within that host; typically this other software will implement TCP and UDP.The definition of IP [1] does not define an interface between an implementation of IP and other software, but gives a general description of what such an interface should look like.
In this paper, we are interested in specifying the services that are made available via such an interface, so in this section we give an informal description of these services.It should be noted that certain functionality of IP is not required to be visible across such an interface 3 .Therefore, the description of the services offered and the protocol fields in the header of an IP datagram, are limited to those that are visible across an interface.
The services offered by IP can be described as follows: Each host is identified by means of an IP address; this is a 32-bit integer value.IP addresses have an internal structure, but this is transparent to the user of the IP services.
The header of a datagram has source and destination fields containing the IP addresses of the source and destination hosts of the datagram.These fields are used internally by IP to route a datagram from its source to its destination.How this routing is achieved is irrelevant.
The header of a datagram has a Time-To-Live (TTL) field; this is an 8-bit integer value.This value determines how long a datagram can remain within an internet before being discarded 4 .Here we consider the TTL field to be the maximum time in seconds that a datagram can remain within an internet.
It should be noted that (internally) IP decrements TTL values of datagrams, i.e., the TTL value in a datagram received will be less than or equal to the value when sent.In addition, it should be noted that IP does not require hosts (or internal nodes) to keep synchronised time.However, for simplicity, we assume that each host (and node) has an accurate internal clock that can record one-second intervals.
The service offered by IP supports two operations; send and receive.
-send allows a host to send a datagram to another host.The datagram being sent will contain the IP addresses of the source 5 and destination hosts and a suitable TTL value.
-receive allows a host to receive a datagram that was sent by another host.The datagram received will contain the IP addresses of the source and destination hosts.
IP implements a connectionless internet.Each datagram is sent and received independently and there are no facilities in the protocol for flow control, sequencing or acknowledgements.
IP implements an unreliable internet.Datagrams may be lost, duplicated or delivered in a different order to which they were sent and no corrective action will be taken by the IP software.
To protect against data errors, IP supports a checksum calculated over the header of a datagram, i.e., the header of a datagram contains a checksum field that is calculated from the other header fields.
IP software ensures that checksums are valid and discards datagrams that have invalid checksums.Therefore, we assume that if a host receives a datagram, then the header fields are valid and can never be corrupt 6 .However, since the body is not protected by the checksum, we may receive a datagram with corrupt user data.
However little the IP specification guarantees, it does say that: -a message which has been received with an uncorrupted header must have originated from the source indicated in that header -if you wait sufficiently long enough between sending two message, and if both messages are received then an ordering of the received messages is guaranteed.
In each of the following four sections we present a specification of IP along with these two consistency results.

Specification of IP using Z
In the Z [3][4] specification of IP, we present a schema (Datagram) describing a datagram and a schema (IP) describing the state of an entire IP system.We then present operations (Send, Receive and Tick) that transform the state of an IP system and prove properties about these transformations.

IP Datagrams
We can define an IP datagram in terms of some simple types.

IP
The state of an IP system can be captured as the bag7 of datagrams that have been sent but not received and which still have a non-zero TTL value.An IP system is initialised by setting transfer to the empty bag.

The Send Operation
If IP were reliable, we could send a datagram by simply adding it to the bag of datagrams in transit.However, since datagrams can be corrupted, discarded or duplicated, we need to define Send so that each datagram in the final state is derived from either the datagram being sent or from one of the datagrams in the original state 8 .We specify this by using bag derivation () as follows: A formal definition of is given below.Informally, t 1 t 0 if every member of t 1 is derived from some member of t 0 , i.e., t 1 can be obtained from t 0 by corrupting, discarding or duplicating members of t 09 .Thus, in the definition of Send, transfer 0 is derived from transfer and d? by corrupting, discarding or duplicating datagrams.

The Receive Operation
Again, if IP were reliable, we could receive a datagram by simply removing it from the bag of datagrams in transit.However, to allow for unreliability, we permit a copy of a datagram to be received and the bag of datagrams in transit to be changed so that any datagram can be corrupted, discarded or duplicated.In particular, there is no requirement that the datagram received should be removed from the bag of datagrams in transit.Of course, one would expect a good implementation to do its best to remove the received datagram. ,transfer

Datagram Derivation
To allow for the possibility of the body of a datagram being corrupted or its TTL value being reduced, we define a relation which specifies when one datagram is derived from another datagram, i.e., d 1 d 0 if d 1 is the same as d 0 , except that some small amount of corruption has occurred to the data of d 0 or the TTL value of d 0 has been reduced.
To do this, we assume that we can define when the data segments of two datagrams are approximately equal ().
: seq Byte $ seq Byte 8s 1 ; s 2 : seq Byte s 1 s 2 , We can extend datagram derivation to define bag derivation as follows:

Properties
Given the operations defined above, we can use composition to derive new schemas to explore the behaviour of an IP system.For example, given datagrams d 0 and d 1 , we can define the behaviour (A 0 ) of sending these datagrams, followed by a single Receive.
The schema A 0 can be rewritten as: Third Irish Workshop in Formal Methods, 1999 Four Logics and a Protocol A 0 states that if we send two datagrams on an IP system with no datagrams in transit, then if we receive a datagram it will be derived from one of the two datagram that were sent.In addition, there may be any number of datagrams (derived from the two datagrams sent) waiting to be received.

TTL Handling and the Tick Operation
The definition of datagram derivation given above, requires the TTL value in the derived datagram to be less than or equal to the TTL value in the original datagram 10 .Therefore, with the operations Send and Receive, datagrams in transit can have their TTL values reduced; provided that they are always greater than zero11 .For TTL handling, we have a stronger requirement, i.e., TTL values must be reduced every second.Therefore, we define strict derivation ( ) for both datagrams and bags. : Using strict derivation we can define an operation Tick, which is performed every second, to reduce the TTL values of datagrams in transit.

Tick
IP transfer 0 transfer

Useful Relations and Functions
For convenience, we define a useful relation (in) and a useful function ( ).The relation in determines if a bag of datagrams contains a datagram that was (or could have been) derived from a given datagram.
The function returns the maximum TTL value of the datagrams in a bag that have been derived from a given datagram, i.e., d b is the maximum TTL of any datagram in b that was (or could have been) derived from d.
Note that in returns 0 if there are no datagrams in the bag that were derived from the given datagram.
Four Logics and a Protocol

Properties involving Tick
All operations on IP (Send, Receive and Tick) are non-deterministic12 .The specifications of Send and Receive are very weak in that they only require the output bag of datagrams transfer 0 to be derived from the input bag transfer and (in the case of Send) the datagram being sent.This leads to the possibility of states that would, in practice, not be produced by an implementation.For example, a Send of a datagram d, followed by an infinite number of Receive operations each returning d, is a possible behaviour.
However, the Tick operation is much more constrained.Like Send and Receive, Tick requires its output bag transfer 0 to be derived from its input bag transfer, but the TTL value of each datagram in transfer is strictly less than the TTL value of the datagram from which it was derived.Thus, while each Tick operation can result in a datagram being corrupted and replicated an arbitrary number of times, after a suitably large number of Tick operations, all these replicates will have been received or discarded.
For example, consider the schema A 1 specified by the composition a Send operation followed by a number of Tick operations: where N is the TTL value of the datagram d? sent by the Send operation.
For each Tick operation, we can show that the maximum TTL value of datagrams derived from d? is reduced, i.e., A 1 states that datagrams derived from the sent datagram d? will only be present in transfer 0 if they were already in transfer, i.e., all datagrams introduced by the Send operation will have been removed from IP after N (d?:ttl) Ticks.

Tick
We can also express this as follows: A 1 IP d? : Datagram transfer 0 transfer : d? in transfer : d? in transfer 0

Ordering of Received Messages
As shown by A 0 above, in general, if two datagrams are sent and one is received, then the received datagram will be derived from either of the two datagrams that were sent.This result can easily be extended to show that in general, if two datagrams are sent and received, the order of reception is not fixed.

Four Logics and a Protocol
However, if two datagrams are sent with a sufficient number of intervening Tick operations, then if they are received, they must be received in the order in which they were sent.To express this property in Z requires us to consider all sequences of operations characterised by this requirement.
Let use assume that we send d 0 and d 1 in that order, i.e., we are interested in sequences of operations of the form: where: A is the composition of one or more receive operations with one of the form Receive d 0 0 d!; first delivered! ,interleaved with at least d 0 :ttl Tick operations.
B is the composition of one or more receive operations with one of the form Receive d 0 1 d!; second delivered! ,interleaved with Tick operations.
For any such sequence A 2 , we can show: 3 Specification of IP using the Temporal Logic of Actions 3.1 A Quick Overview of TLA

Introduction
Temporal logic extends classical logic by handling modalities such as fairness and eventuality.TLA [7] is a temporal logic of actions for specifying and reasoning about concurrent systems.Systems and their properties are specified in the same logic, so the assertion that a system meets its specification and the assertion that one system implements another are both expressed by logical implication.TLA has four levels: Stuttering steps are steps in which specified variables do not change.These are used to help show equivalences between behaviours.For an action A and a state function f , a stuttering step is written as follows: Third Irish Workshop in Formal Methods, 1999 A f , A _ f 0 = f A step corresponding to an action A in which the variables in a state function f do change is written as follows: A f , A f 0 6 = f 4. Sequences of States: the fourth level allows reasoning about behaviours, which are infinite sequences of states.
A behaviour is denoted by s 0 ; s 1 ; s 2 ; ::: , where s 0 is the first state, s 1 is the second, etc.
An action A is true iff the first pair of states in the behaviour is an A step. s 0 ; s 1 ; s 2 ; ::: A , s 0 A s 1

TLA Formulas
A TLA formula can include the following forms: P Satisfied by a behaviour iff P is true for the initial state.
2 A f Satisfied by a behaviour iff every step satisfies A or leaves f unchanged.
WF f A , 23 A f _23:Enabled A f SF f A Satisfied by a behaviour iff A f 0 6 = f is only finitely often enabled, or infinitely many A f 0 6 = f steps occur (strong fairness).
The specification of a system in TLA has the following form: where Initial is a state predicate describing the initial state, N is a transition predicate describing the possible steps, x is a state function indicating the variables which cannot change in any step other than a N step, and F is the conjunction of fairness conditions.

Specification of the IP Layer Interface Using TLA+
We now give a specification 13 of the IP layer interface using TLA+, a specification language which is an extension of TLA and includes additional data types, operators and modules.constants DATAGRAMS DATAGRAMS is the set of valid datagrams variables sent; received; transit These three variables represent the current state: sent is a set containing all the datagrams which have been sent so far, transit is a set containing all the valid datagrams which are still in transit, and received is a set containing all the 13 The proofs have been banished to the appendices Third Irish Workshop in Formal Methods, 1999 Four Logics and a Protocol datagrams which have been received so far.A datagram is represented as a four-tuple giving its source, destination, time to live and message.The actions which can be performed are as follows: When a datagram is sent, it is added to the set of sent datagrams, and also to the set of valid datagrams which are currently in transit.The set of received datagrams is not affected.
Receivedatagram , ^datagram 2 transit ^let dg , choose d : ^d 2 transit ^d = datagram in received 0 = received f dgg ^UNCHANGED sent; transit A datagram which is received must be one which is currently in transit.This is not removed from the set of datagrams in transit as it may have been duplicated.The datagram is added to the set of those which have been received.Here, we model the corruption of datagrams which are currently in transit.We only include the case where the header of the datagram remains unchanged, as these are the only ones which will be valid.Although the actual message will not be changed very much, we do not specify this.The original uncorrupted datagram is not removed from the set of datagrams in transit as it may have been duplicated.If the result of corruption produces invalid datagrams, the set of datagrams in transit will therefore not be affected.
Each transition within a behaviour must be a send, receive, timeout or change action.Specification , Init ^2 Transition hsent;transit;receivedi ^Fairness

No Message Creation
In order to prove that no messages are created, we prove that if a message is received with a specified source and destination, then a message must also have been sent with the same source and destination.This property is stated as follows:

Ordering of Received Messages
Here we prove that if two datagrams are received, then if they are sent far enough apart they will be received in the same order in which they were sent.This property can be stated as follows: Third Irish Workshop in Formal Methods, 1999 Four Logics and a Protocol 3 2 dg 1 2 sent ^dg 1 2 received ^dg 2 2 received 3 2 dg 2 6 2 sent dg 1 2 received ^dg 2 6 2 received Before we can prove this property, we need to make the following assumption: dg 6 2 sent ^3 2 dg 2 received dg 6 2 received (1)   This states that any message which is eventually received and has not yet been sent cannot have already been received.We can now prove the bounded reliability property as follows: 3. 3

A Crash Course in Linear Logic
One way to look at a logic is to divide its rules into three categories: 1. Axioms.These are the defined truths of the logical system.In intuitionistic logic, the sole axiom represents the tautology that from hypothesis A one can deduce hypothesis A.
2. Structural rules.These specify how hypotheses can be manipulated.In intuitionistic logic these are the Exchange, Contraction and Weakening rules.
3. Logical rules.These define the logical connectives, which in the case of intuitionistic logic are conjunction(), disjunction(+) and implication( ).
Linear logic [5, 6] belongs to the family of sub-structural logics.These logics remove, or weaken, the structural rules of Exchange, Contraction and Weakening.In order to remain expressive they typically introduce addition logical rules.In the case of linear logic, the Contraction rule, which allows hypothesis to be duplicated and the Weakening rule, which allows hypothesis to be discarded, are removed.The effect of this is to make the logic "resource conscious".Multiplicative conjunction is written as A B and is pronounced "both A and B".When used, both hypothesis are consumed and are no longer available.
Additive conjunction is written ANB and is pronounced "choose from A and B".When used, you have the choice of which hypothesis is consumed and no longer available.
Additive disjunction is written AB and is pronounced "either A or B".When used, it represents an external choice as to which hypothesis is consumed and no longer available.
Third Irish Workshop in Formal Methods, 1999

Four Logics and a Protocol
Exponentiation is written !A and is pronounced "of course A".This is a new form of connective which represents a producer of the hypothesis A. It allows us to represent intuitionistic truth in linear logic.We can also use it to define intuitionistic implication as !A B.
Assumptions can be linear, written A , or intuitionistic, written A .Though assumptions of the form !A are in a sense equivalent to assumptions of the form A there is very important difference.Linear assumption, including those of the form !A , can only be used once in a proof whereas intuitionistic assumptions may be used any number of times.
Judgements are written , `A.Only the assumptions in the judgement are labelled with square or angle brackets and these brackets may only appear on the left hand side of `and never on the right.Alternatively judgements can be written ,; `A which states that with the unrestricted intuitionistic context , and the restricted linear context we can judge A to be a true conclusion.With the combination of intuitionistic and linear hypotheses we need an additional rule called Dereliction to allow us to copy an intuitionistic hypothesis to a linear hypothesis.

Specification of IP Layer Interface
There are two operations available to the user of the IP layer: 1. Sendx; y; ttl; m Sends a message m from node x to node y with a "time to live" value of ttl.

Rcvx; y; ttl; m
Receives a message m from node x to node y with a "time to live" value of ttl.
The equations that define the user interface to the IP layer are: 8x: 8y: 8ttl: 8m: Sendx; y; ttl; m Datagramx; y; lowerttl; m Sending a message adds a single datagram to the system.lower is a function that reduces its operand to some non-zero integer in the range 0; t .
8x: 8y: 8ttl: 8m: If a datagram addressed to node y exists and node y is listening for it, then node y will receive the message m or some corrupted version changem of the message m.

Verification
The IP specification guarantees very little about a message sent from one node to another; however, as mentioned earlier we can prove results relating to the origin of a valid datagram, and the ordering of receipts under certain conditions.
Third Irish Workshop in Formal Methods, 1999 Four Logics and a Protocol

No message appearing from mid-air
If a node receives a properly formatted message some node must have sent a message with the same header (but the message may be corrupted).In fact, if the initial datagram is not lost, a messages sent from node A to node B may result in one or more messages, with correct header, being received by node B.
The unrestricted context , contains the rules for the system, i.e. equations 2,3 and 4. For the remainder of this section we use the following shorthand: There are at least two styles of proofs in linear logic: one which is applicable when there is an overall goal (such as planning), and the other when there is no overall goal but there is an evolution of state.In the latter case the right-hand side of the judgement should be "empty", which is modelled by 0, the impossible goal.Then the following partial derivation shows that, given a set of rules ,, the state 0 can evolve into state 1 .,; If we assume that j,1 copies of the sent message (or a similar message with the correct header) were received then there exits a previous state that can also evolve into the reception of j copies of the sent message.Thus, letting the multiplicative conjunction of N linear assumptions A be denoted by N i=1 A, we can prove

Ordering of received messages
If two messages m 1 and m 2 are sent and successfully delivered then the precondition necessary to guarantee that m 1 arrives before m 2 is that the interval n between sending m 1 and m 2 is greater than m 1 's time to live value.Let T s E be a function that returns the time of an event E as seen by the sender's clock.Events can be either Send or Rcv operations.A corollary of 5 is that before a message is received it must have been sent, and therefore the time a message is sent (as seen by the sender's clock) is less than or equal to the time the message was received (as seen by the sender's clock).
5 Specification of IP using the Calculus of Constructions

Constructive Logic and Coq
Constructive logic can be seen as a restriction of classical logic where we remove the "law of the excluded middle" (A_: A) and related axioms, such as proof by contradiction.This results in a system where a proposition A is true precisely when there exists a proof of A, as opposed to classical logic which will also allow a refutation of : A as evidence.Under the standard Curry-Howard isomorphism we can identify each proof of a proposition A with a program implementing the specification A; logical conjunction, disjunction and implication translate into product, sum and function types respectively.Our specification below was developed using the Coq [8] proof assistant, based on the Calculus of Inductive Constructions [9].As well as the normal benefits of a proof assistant such as uniformity of notation and verification of type-correctness, Coq also provides three enhancements to ordinary constructive logic: Coq implements a higher-order constructive logic, facilitating in particular, the descriptions of object logics within the framework Coq has two type hierarchies: Set of constructive types, and Prop for classical logic.This allows specifications to be developed in ordinary classical logic, and then verified in the same framework against programs written within Set.
Coq supports inductive (and co-inductive) definitions, giving a natural logical extension of the definition-bycases style of programming found in functional languages

Datagrams
The basic unit of communication between the IP layer and the network layer is the datagram, which encapsulates the data being sent, and various pieces of auxiliary information.Since we do not propose to treat the components of a datagram in any great detail, we may take the type of these components as given, declaring: Parameter IPaddress : Set.Parameter data : Set.
Our datagram then can be regarded as a record, the fields of which are described in section 3.1 of [1].Abstracting from this, we specify:

Sending and Receiving
Since we have omitted many details of the internal operation of the IP layer, it is hardly any surprise that we choose a simple interface between the IP and network layers.The IP layer must be able to dispatch and collect datagrams to and from the network layer; we assume that this is achieved via two functions, which we call depart and arrive respectively.Our specification of the IP interface naturally centres on the two main functions: SEND and RECV.In each case the main purpose of the definition is to explicitly link a successful SEND or RECV with a corresponding departure or arrival action.Allowing for the possible error conditions specified in section 3.3 of [1], we given an inductive definition for the SEND function: (src,dst:IPaddress)(tm:nat)(BufPTR:data) (SEND src dst tm BufPTR).

Conclusions
The case study chosen is relatively small and certainly does not cover all aspects of each of the chosen formalisms.However it is an example of a "real" problem that is independent of any of the natural domains of each of the given logics.In addition, the specifications themselves provide a flavour of each of the formalisms, and serve as a basis for some comparative remarks.
In each case the specifications were naturally modularised around the two main proofs: one relating solely to the send and receive functions, the other connecting the two via some kind of ordering.Within these natural sections, we can see that in each case the main units of organisation were the datagram (the main "data-structure") and the two function calls send and receive.
There is a clear dichotomy here between the Z and TLA specifications on the one hand, and the linear and constructive logic based specifications on the other.
The first two are explicitly state-based, and in each case this style of specification seemed to lead naturally to the same basic structures -for example, the Z specification has a bag transfer of datagrams in transit, with a corresponding set transit in the TLA specification.Indeed, we should point out that the choice between using a bag or set here was largely one of individual style, rather than any inherent bias in the formalism used.
On the other hand, the other two specifications can be regarded as being more declarative, eschewing an explicit state and relying on their respective logical structures to provide the necessary links between send and receive actions.In particular, in linear logic the connection between valid receipts and corresponding sends was achieved via an explicit transfer of resources over linear implication, but in constructive logic this was achieved by a direct axiomatic link.
It was in the presentation of the second result that a clear difference emerged between Z and TLA.In particular, significant difficulty was encountered in arriving at a formal specification of this property within the Z schema calculus as the statement of the result was essentially a quantification over sequences of send and receive schemas.On the other hand, the built-in temporal operators in TLA provided a direct route towards reasoning about sequences of operations, and thus towards establishing properties regarding the ordering of receive events.Since neither linear logic nor the constructive formalism used here support temporal operators primitively, the simplest approach in each case was to index events using a relative time-clock, expressed as T s in the linear-logic specification, and as the timeOf function in the Coq specification.Indeed, once this had been introduced the proof of ordering devolved to relations over natural numbers, rather than any distinctive features of the logics used.

Future Work
The results presented above are part of an ongoing collaboration between the authors in the general area of formal methods and communication protocols.Specifically it is hoped that this work can now be used as a basis for the specification of TCP, in particular specifying the TCP/user interface specifying the TCP protocol (based on the IP specification) and verifying implementation consistency between the protocol internals and the TCP/user interface In addition to providing an interesting case study in the use of the four formalisms, it is hoped that this can serve as a basis for an analysis of the suitability of each of the logics for protocol specification, as well as a foundation for further work in the area.

IP transfer 0
transfer 8d : Datagram d transfer 0 6 = 0 d transfer 0 d transfer Therefore, by induction over the maximum values in each intermediate state, we can show: A 1 IP d? : Datagram transfer 0 transfer d? transfer = 0 d? transfer 0 = 0

Fairness , 8
d 2 DATAGRAMS : WFhsent;transit;receivedi Timeoutd Messages which remain in transit are eventually timed out.Third Irish Workshop in Formal Methods, 1999 Four Logics and a Protocol Init , sent = fg ^transit = fg ^received = fg Initially, no messages have been sent, received or are in transit.
1. Constants: this level is concerned with formulas which are state-independent (constant).The variables which are used in this level are called rigid variables and cannot change values between states.2. States: this level allows reasoning about individual states.The formulas in this level can either be state functions (non-boolean functions) or state predicates (boolean expressions).The variables used in this level can be flexible variables, which can change values between states.3. Pairs of States: this level concerns reasoning about pairs of states.The formulas in this level can either be transition functions or transition predicates (actions).The variables used in this level can be primed.Unprimed variables refer to the old state, primed variables to the new.For a state function or predicate f , f 0 is obtained by replacing each flexible variable v in f by v 0 .
Timeoutdatagram , ^datagram 2 transit ^let dg , choose d : ^d 2 transit ^d = datagram in transit 0 = transit , f dgg ^UNCHANGED sent; receivedA datagram which is timed out must be one which is currently in transit.This is removed from the set of datagrams which are in transit, but the sets of datagrams which have been sent and received are not affected.
, 8s; d; t1; m1 : 2 s; d; t1; m1 2 received 9 t2; m2 : s; d; t2; m2 2 sentTo prove this invariant, we prove the following two properties: NoCreation1 ^ sent; transit; received = sent 0 ; transit 0 ; received 0 NoCreation1 0 NoCreation2 ^ sent; transit; received = sent 0 ; transit 0 ; received 0 NoCreation2 0 2 dg 1 2 sent ^dg 1 2 received ^dg 2 2 received 3 2 dg 2 6 2 sent dg 1 2 received ^dg 26 2 received Next we assume that a function to re-calculate a checksum for a datagram is available, and state that this calculation is independent of the value in the checksum field.Based on this, we can specify what is means for a datagram to be valid: Third Irish Workshop in Formal Methods, 1999Here validDG is defined to be a function from datagrams to Prop -i.e. a predicate over datagrams; the square brackets are used to delimit the argument here.We can also define a function newDG that constructs a new datagram from pieces of information, and construct a proof ValidNewDG to demonstrate that a datagram so constructed satisfies the validity property above.14 2.7.Q.E.D. PROOF: follows from 2.1-2.6 3. 3 2 dg 1 2 sent ^dg 1 2 received ^dg 2 2 received 3 2 dg 2 6 2 sent dg 1 2 received ^dg 2 6 2 received L; L ,1 ,; Dm L L Cm; Dm; Dm; L; j,1 i=1 Cm `0 L ,1 ; L ,; Dm; Dm; L; j,1