Connection Management for the Transport Layer: Service - IEEE Xplore

IEEE TRANSAC TIONS ON COMMUNICATIONS, VOL. 39, NO, 12, DECEMBER 1991

1762

Connection Management for the Transport Layer: Service Specification and Protocol Verification Sandra L. Murphy, M em ber, IEEE, and A Udaya Shankar, M em ber, IEEE

Abstract- We specify a symmetric connection management

user

user 2

1

service between two service access points, using a state transition system and safety and progress requirements. At each access point, the user can request connection establishment, request connection termination, and signal whether or not it is willing to accept connection requests from the remote user. The protocol can indicate connection establishment, connection termination, and rejection of a connection establishment request. The safety and progress requirements ensure that the data exchanged during a connection is uncorrupted by data from past connections. They

Fig. 1.

also ensure that a connection establishment request is eventually

The protocol system,

foDowed by a connection establishment indication or a reject indication; the latter can happen only if the distant user was not willing to accept connections at some point after the connection establishment request was made. We then specify a protocol and verify that it otTers the service, given communication channels between the access points that can lose, reorder, and duplicate messages, but which guarantee de­ livery of a message that is repeatedly sent. Our protocol achieves the service using 2-way and 3-way handshakes. Our protocol can be directly combined with

any

existing single-connection data

transfer protocols to provide a transport layer protocol that otTers both connection management and data transfer services.

A transport protocol has two functions:

data between connected users, while connection management provides the establishment and termination of these connec­ tions. Typically, when a user is not involved in a connection, it is not allocated communication resources such as port numbers, buffers, etc. These resources are freshly acquired each time the user enters a connection. This is crucial for efficiency and crash recovery. When a user wants a connection established with a distant

We compare our protocol and service to TCP and its intended service, and to ISO TP Class

4 and its intended service. Our

service is equivalent to the intended service of TCP. We point out several behaviors of TCP where it does not otTer its intended service. We also identify inadequacies with TCP's mechanisms for crash recovery and reuse of sequence numbers.

N

I

I.

user, it is the responsibility of the connection management function to determine whether the distant user is willing to accept a connection, and if so to establish a communication path between the users that is free of messages from past connections. The data transfer function builds upon this

n ection managem ent service to

INTRODUCTION

a computer network, the transport protocol provides

reliable communication between user processes on any two

hosts of the network, Typical user processes are electronic mailers, file transfer protocols, remote login, etc, The transport protocol entities communicate by message passing, using virtual channels that are offered by the network layer. (See Fig. 1) Because of the effects of store-and-forward routing and intermediate node crashes, the virtual channels display numerous errors. Throughout this paper, we assume that the channels may lose, duplicate, and reorder messages in transit. Paper approved by the Editor for Network Protocols of the IEEE Commu­ nications Society. Manus cript received June 20, 1988; revised December 22, 1989 and March 1, 1990. This work was supported by the Nati ona l Science Foundation under Grants ECS 85·02113 and NCR 89·04590, S. L. Murphy was supported by a Graduate School fellowship, University of Maryland. This paper was presented in part at the ACM SIGCOMM'87 Workshop: Frontiers in Computer Communications Technology, Stower, VT, August 11-13, 1987. S. L. Murphy is with the Department of Computer Science, University of Maryland, College Park, MD 20742. A. U, Shankar is with the Department of Computer Science, University of Maryland, College Park, MD 20742, He is also with the I nstitute for Advanced Computer Studies, University of Maryland, College P ark , MD 20742, IEEE Log Number 9103830.

connection manage­

ment and data transfer. Data transfer handles the exc�nge of

offer the

con­ data transfer service,

i.e., insequence delivery of current connection data, without any loss, duplication, or reordering. In this paper, we first specify a connection management service. Then we specify a protocol that is verified to offer the service, Our service is equivalent to the intended service of

TCP

(except for security classes). Our protocol is simpler

than TCP. We show that

TCP

can violate its intended service.

Our formalism for specifying protocols, specifying services, and establishing that a protocol offers a service is based on the approach of

[8], [11]. (A

preliminary version of this protocol

was presented in [10].) The service of

S

input events,

is defined by a set of

a set of

output events,

access points, a set a l lowed

and a set of

sequences of the input and output events, Each allowed event sequence represents one possible interaction between the users and the protocol. Each event is associated with an access point.

An input event is controlled by the user at the associated access point. An output event is controlled by the protocol entity at the associated access point. The protocol P is defined by a state transition system and certain fairness assumptions. The protocol events are classified

0090-6778/91$01.00 © 1991

IEEE

1763

MURPHY AND SHANKAR: CONNECTION MANAGEMENT FOR THE TRANSPORT LAYER

into entity events, which can send and receive messages, and channel events, which model channel errors. Some of the protocol entity events are defined to corre­ spond to certain service events. This induces a correspondence between behaviors of the protocol and sequences of service events. The protocol P offers the service S iff every allowed protocol behavior corresponds to an allowed event sequence of the service. Although it is conceptually simple to view the service as a set of allowed event sequences, some convenient way of specifying this set is needed in practice. We specify the service S by a state transition system, a set of invariant requirements, and a set of progress requirements using the leads-to operator. Then, P offers S if the state transition system of P is a refinement of the state transition system of S, and satisfies the safety and progress requirements S given the fairness assumptions of P. (These notions are defined precisely in Section II.) Our service specification is realistic. It gives equal capability to each user. It handles the client/server model of users, where one user is a client, the other is a server, and only the client can request connection establishment. It also handles balanced opening, in which both users can request connection establishment. Our service is equivalent to the intended service of the Internet TCP [13], [14], except for the following: in our service, a connection can be terminated as soon as one of the users requests it; in TCP, the termination is delayed until the other user also requests termination and all data in transit has been delivered. We chose our service for the sake of brevity. The users can easily achieve the TCP termination service over our service (see Section V). It is harder to compare our service to the ISO Transport Service (ISO TS) [2], [4] because ISO TS allows multiple incarnations to be active at an access point, and treats each connection request independently. In particular, if the two users simultaneously request a connection, then ISO TS offers two connections to the users, whereas a single connection is formed in our service and TCP. In the ISO network architecture, it is the (session) layer above the transport layer that solves the nontrivial problem of merging the two connections into one connection. (Note that this problem would not arise in a client/server environment.) Our protocol uses two-way and three-way handshakes to achieve the service. In particular, for connection establishment we use a three-way handshake which differs from those in [13], [4], [20] in that our connection request messages also indicate whether the sending entity's user is requesting a connection or accepting a remote connection request. We discovered during our verification that without this distinction, an old duplicate connection request in a channel can cause a connection attempt to fail even though the other user is willing to accept the connection. TCP does not make the distinction and suffers from this problem (see Section V). Our protocol satisfies the following quiescence property: if the users stop requesting connections, then eventually the channels become empty of messages provided the channels impose a maximum message lifetime. This implies the absence of infinite chatter, i.e., where both entities are busy retransmit­ ting their requests, expecting a response that the other entity

will never send. Infinite chatter is worse than deadlock because in addition to not making progress, the protocol is consuming precious network resources. TCP can display infinite chatter (see Section V). A. Organization of the Rest of This Paper

In Section II, we describe how we specify services and protocols, and how we establish that a protocol offers a service. In Section III, we specify the connection management service. In Section IV, we specify the connection management protocol and establish that it offers the service. We also outline how to incorporate data transfer protocols and crash recovery mechanisms. In Section V, we compare our protocol and service to TCP and its intended service, and to ISO TP Class 4 and its intended service. In Section VI, we compare our specification and verification approach to other approaches in the literature. In Section VII, we point out other work and future research directions. II.

SPECIFICATION MODEL

Our specifications have three kinds of components: state transition systems, safety assertions, and progress assertions. A state transition system consists of a set of state variables tJ = {VI, V2, . . . }, a set of events { eJ, e2, . . .}, and an initial condition on the state variables. Each variable takes values from a specified domain. The system state is represented by the values assumed by the state variables. The initial condition defines the initial states of the system. Each event is specified by an enabling condition and an action. An event can occur only when the values of the state variables satisfy its enabling condition. Its occurrence atom­ ically updates the state variables as specified by the action, resulting in a new system state . If more than one event is enabled in a system state, one of them is nondeterministically chosen to occur. Note that each event specifies a set of state transitions. A behavior of the state transition system is a sequence (T = (so, fo, 81, ft,···) where the 8i'S are system states, the Ii's are event names, So is an initial state, and for each i � 0, ( Si, Si+l ) is a transition of k A behavior can be finite or infinite. By definition, a finite behavior ends in a state. Thus, a state transition system defines a set of finite and infinite behaviors. Safety and progress assertions are another way to describe sequences of the form (T = (so,jo,s1,h,"')' We usc the term state formula to mean a formula that can be evaluated in each system state to either true or false. The safety assertions in this paper are restricted to invariant assertions, which are statements of the form A is invariant where A is a state formula. By definition, A is invariant for (T iff every system state Si in (T satisfies A. We use two types of progress assertions in this paper. The first type is of the form A leads-to B where A and Bare state formulas. By definition, A leads-to Bis satisfied by (T iff for every Si in (T that satisfies A, there is some Sj, j � i, in (T such that Sj satisfies B. The second type of progress assertion is of the form A leads-to n V {ej} where A and

IEEE TRANSACTIONS ON COMMUNICATIONS, VOL 39. NO. 12, DECEMBER 1991

1764

B are state formulas and {ej} is a set of event names. By definition, A leads-to B V {ej} is satisfied by 17 iff for every 8i in 17 that satisfies A, there is a j � i such that 8j is in 17 and satisfies B or Ii is in 17 and belongs to {ej}. Note that of the three types of assertions described above, this is the only type that constrains the events of 17. Also note that A leads-to Bimplies A leads-to B V {ej}.

A. Specifying Services

A service specification •

•

•

5 consists of the following. A set of access points. A state transition system 5, each of whose events is associated with an access point, and is either an input or an output event. A set of invariant assertions, referred to as invariant requirements As. A set of progress assertions, referred to as progress requirements Ls.

The set of allowed event sequences of the service 5 is defined as follows. An allowed behavior of the service 5 is a behavior of the state transition system 5 that also satisfies the invariant requirements As and the progress requirements Ls. An event sequence is allowed if it is the event sequence of an allowed behavior. B. Specifying Protocols

We consider protocols that are networks of entities and one-way communication channels. A protocol specification P consists of a state transition system P and certain fairness assumptions, as explained below. The state transition system P satisfies certain conditions concerning the network topology. For each channel, there is a state variable that indicates the sequence of messages traveling in the channel, and a set of events that model the channel errors. These events can only access (read or update) the channel state variable. For each entity, there is a set of state variables and events. The events of an entity can access the state variables of that entity and the state variables of channels incident on that entity, but only as follows: they can append messages to the tails of outgoing channel state variables, and remove messages from the heads of incoming channel state variables. We assume that there is always an entity event enabled to receive the message at the head of a channel. The system can also have a set of auxiliary state variables, which are needed for specification and verification only, and do not have to be implemented. Thus, they need not satisfy the above topology constraints. However, the set of auxiliary variables must satisfy the following conditions: 1) they do not affect the enabling condition of any event, and 2) they do not affect the update of any nonauxiliary state variable. I Note that it is acceptable for an event of entity i to read nonauxiliary state variables of other entities provided the values read affect the updates of auxiliary variables only.

Formally, auxiliary variables appear only in assignment statements; if they in the right-hand side of an assignment statement, then the left-hand side must be an auxiliary variable also [15]. 1

appear

Fairness assumptions are (special types of) progress asser­ tions that are assumed. In this paper, we have two types of fairness assumptions. First, an entity event e can have weak fairness. A behavior 17 of the state transition system of P satisfies this assumption iff 1) 17 is finite and e is not enabled in the last state of IT, or (2) IT is infinite and either e occurs infinitely often or is disabled infinitely often in a. Second, a channel i can have fair progress. A behavior 17 of the state transition system of P satisfies this assumption iff 1) 17 is finite, or 2) 17 is infinite and for any set M of messages sent into channel i, if messages from M are sent infinitely often in IT, then messages from M are received infinitely often in IT. An allowed behavior of the protocol P is a behavior of the state transition system of P that also satisfies the specified fairness assumptions. By definition, an invariant assertion is satisfied by protocol P iff it is satisfied by every finite behavior of the state transition system P. A progress assertion is satisfied by protocol P iff it is satisfied by every allowed behavior of the state transition system of P. C. Specifying that a Protocol Offers a Service

Suppose we have a service specification 5 and a protocol specification P. In the Introduction, we mentioned informally what it means for P to offer 5. We now make that precise. First, a correspondence is specified between events of P and events of 5, as follows. Each access point i of 5 corresponds to a unique entity of P, referred to as entity i. There can be entities of P that do not correspond to access points, although this is not the case in this paper. Each input event h of 5 at access point i corresponds to a unique event e of entity i. (This means that e is executed in the entity whenever h is executed by the user.) Let e be an event of entity i that does not correspond to an input event. Each transition (s, t) of e either corresponds to an output event h at access point i, or does not correspond to any service event. (In the former case, h is executed at the access point whenever the entity executes the transition (8, t) of e.) The above correspondence extends naturally to behaviors of P and event sequences of 5. A behavior 17 = (so, 10, 81, h, ... ) of P corresponds to the sequence of events of 5 obtained as follows: 1) replace every Ii that corresponds to an input event by the input event, 2) replace every remaining ( Si' Ii, 8i+l ) that corresponds to an output event by the output event, and 3) delete all remaining states and events of P from •

•

•

17.

Defin ition: P offers 5 if 1) every allowed behavior of P corresponds to an allowed event sequence of 5, and 2) whenever an input event of 5 can occur, its corresponding

entity event in P is enabled. The second constraint above ensures that P is not a vacuous implementation of 5. Recall that in our formalism 5 is specified by a state transition system 5, invariant requirements As, and progress requirements Ls. We now present convenient sufficient con-

1765

MURPHY AND SHANKAR: CONNECTION MANAGEMENT FOR THE TRANSPORT LAYER

ditions SPl-SP5 for P to offer S. These conditions are a special case of the refinement relation in [8], [11]. For any event e, we use enabled( e) to denote its enabling condition. SPl: Every state variable in S is also a state variable in P, with the same domain. Thus, there is a projection mapping from the states of P to the states of S. For each state s of P, we use 7i to denote its image in S. 2

SP2: Initialp ::::} Initials where Initialp and Initials are the initial conditions of P and S, respectively. Thus, the image of every initial state of P is an initial state of S. SP3: If input event h corresponds to entity event e then: (a) if (s, t) is a transition of e, then (s, I) is a transition of h. (b) enabled(h) ::::} enabled(e) SP4: If entity event e does not.correspond to an input event, then for each transition (s, t) of e: (a) if ( s, t) corresponds to an output event 11" then (s, t) is a transition of h. ( b) if (s, t) does not correspond to any service event, then s

=

t.

SP5: The invariant requirements As and the progress requirements Ls of the service are satisfied by the state transition system of P, given the fairness assumptions. Condition SP3(b) implies part (2) of the definition of P offers S. The remaining conditions imply part (1), as follows. Conditions SPI, SP2, SP3(a), and SP4 ensure that for every behavior 17 = (so, fo, S1, II, ...) of the state transition system of P, its image (j = (to, go, h, g1 , . . . ) is a behavior of S where the image (j is defined in the obvious way, Le., (go, 91, . . . ) is the corresponding event sequence of 17, and if Ii corresponds to gj, then tj is s;. This and condition SP5 ensure that for every allowed behavior a of P, the image (j is an allowed behavior of S. Hence, the event sequence corresponding to a is an allowed sequence of S. III.

CONNECTION MANAGEMENT SERVICE

In this section, we specify the connection management service. A protocol that offers it will be presented in the next section. The service has two access points, denoted 1 and 2. (See Fig. 1.) During the course of system execution, at each access point, incarnations of the local user are created and terminated. Each connection is an association between two incarnations, one at each access point. A new incarnation of user i is created whenever user i requests connection establishment or becomes willing to accept remote connection requests. It is possible that the incarnation is terminated without entering into a connection, e.g., if its request is rejected, or if user i becomes unwilling to accept requests before a connection is formed. If the incarnation enters into a connection, then entity i informs it of the identity of the remote incarnation to which it is connected. Once an incarnation is connected, it 2To be precise, s denotes a value assignment to the variables of P, and s denotes the subset of the value assignment corresponding to the variables of S.

is terminated when the connection is terminated. Each access point i can have at most one incarnation active at any time. We now formally specify the service. Its state transition system and set of requirements are symmetric with respect to the access points. Below, we use i and j to range over the access points such that i i= j. A. State Transition System

We have the following state variables at access point i. A Pascal-type notation is used to indicate their domains. Initial values, if any, are indicated. (Note that each variable has a subscript identifying the associated access point.)

State;: {closed, listening, aopening, popening, open, closing}. Initially closed. Closed means user i is not willing to accept connection establishment requests from user j. Listening means user i is willing to accept such requests. Active opening

means user i has requested connection establishment. Passive opening means entity i has indicated a possible

connection establishment attempt by the remote user. We use opening to denote active or passive opening. Open means entity i has indicated the establishment of a connection. Closing means user i has requested connection termination. Lin;: {a, 1", . } . Initially O. Local incarnation number. Equals the number of times the user i has left the closed state (to become either active opening or listening). Serves to identify the current incarnation of user i. Din;: {null} U { a, 1,·· . } . Initially null. Distant incarnation number. Dini is null if Statei is closed or listening. We say that user i knows of incarna­ tion n of user j if Dini = n. We want Din, to equal Linj whenever user i is open. oppo.5ed;: boolean. If user i is active opening, then opposedi is true iff user j was closed at some time since i last became active opening. If opposedi is true, we say i's current attempt has been opposed. The service specification allows user i's connection establishment attempt to be rejected only if it has been opposed. The events at access point i are specified in Table I. Note every input event has the suffix Req and every output has the suffix Inri. Fig. 2 indicates the effect of these events on

Statei. B. Safety and Progress Requirements

We require the following state formula to be invariant:

Ro

==

Statei

Statej Dini

=

E

=

open

::::}

{aopening, popening, open, closing} 1\

Linj

1\

Dinj

=

Lini

That is, if one user is open, then the other user must be opening, open, or closing, and each user must know the other user's incarnation number. This information is needed for the data transfer protocol to ensure that data of this connection is

1760

IEEE TRANSACTIONS ON COMMUNICATIONS, VOL 39, NO. 12, DECEMBER 1991

TABLE

I

SERVICE EVENTS AT ACCESS POINT i

CuunReqi

enabled

State,

==

i willing to accept conne ctiuns} Statr, = do. Din, State; closed; Din, ...... null; opposed) (State) = aopening) ->

State; = listening

->

+-

+-

-+

+-

---t

---t

->

=

DistantReqI nd, (sin ) Connlnd ; (Din, ) IConnlnd,(sin)1 IDistantReqI nd, (sin) I

->

-+

+-

IClosedlndi I

+-

SendCRPO;

State. = p opening action == Send;(CRPO, Lin;, Din;) RecCRPO, enabled ==

enabled == action ==

Head(z)

z)

+-

State,

o o

D o o

= (CRPO,sin,rin)

Tail(zj); =

closed

Send;(REJ, Lin;, sin) Send. (RESET,Lin " sin) State, = popening 1\ sm> Din; State, +- listening; Din, null; Scnd,(RESET, Lini, sin) Statei = aopening A sin 2: Dint 1\ rin Lint Stute, ...... open; Din, ...... sin; Sendi(CRACK, Lini, Din ; ) State, = open II sin 2: Din, 1\ rin = Lin; Sendi(CRACK, Lin" Dini) State, = closing II sin> Din, Statei ...... do.

State, = li.• tening

->

->

IList en lnd i I

+-

=

�

IConnlnd;(sin)1

->

-+

IClosedlndi I

+-

thus, SP4(b) is satisfied, (2) If update; corresponds to output event h, then (8, I) is a transition of h; Thus, SP4(a) is satisfied. Finally, we have the following fairness assumptions: All SendM; events have weak fairness, and both channell and channel 2 have fair progress. All that remains is to show that SP5 holds, i.e., that the protocol satisfies the invariant and progress requirements Ro -R4• A proof of this may be found in [12]; it is not included here for reasons of space. We have also established in [12] that the protocol satisfies the following, which corresponds to the quiescence property mentioned in the Introduction:

Statel

E

{clo,sed, listening} I\State2 E {closed, listening} Z2 empty V { ConnReql , ConnReQ2} .

leads - to Zl

=

=

We have summarized in Fig. 3 the transitions at entity i due to user requests and message receptions; only the Statei

component is shown. Each transition has one or more labels of the form x/y where x lists the causes of the transition and y lists the actions done by the transition (other than the change in State;). A message type M in x means that reception of an M message with acceptable sin and Tin fields causes the transition. A request event in x means that execution of the request by user i causes the transition. A "---" in x means that the transition can be done at any time. A message type M in y means that an M message with appropriate sin and Tin fields is sent by the transition. An indication event in y means that the indication is issued to user i by the transition. Also, y can be "---", which means that no additional actions are done by the transition. A.

Incorporating a Data Transfer Protocol

The literature contains several data transfer protocols for the scenario of Fig. 1 (e.g., [17], [16], [19]). In these protocols,

1769

MURPHY AND SHANKAR: CONNECTION MANAGEMENT FOR THE TRANSPORT LAYER

TABLE II

(continued) RecCRACKi enabled:= action:=

Head(z]) = (CRACK, sin, Tin) z]

+-

Tail(zi);

Statei

o

E

{closed, lisinung, open, closing}

E

Statei State,

{popening, aopening}1\ sin

�

open; Dint

--+

�

Iino update

11

Din, 1\ Tin = Lin,

IConnInd,(sin)1

�

sin

t-

RecRESET, enabled: Head(zj) action:

=

(RESET,sin,Tin)

Zj +- Tail(z);

State; E {closed, listening, aopening, open}

D

o

"no update"

�

Statei = popening A sin> Dinl 1\ Tin = Linl -

I Li"tenIndi I

Stafe1 ....... listening: Dint ....... null

IClosedIndd

Statei = dosing 1\ sin> Din; 1\ Tin =Lin; --+ State;

+-

closed; Din,

rml!; oppo, Din; State,

+-

listening; Din,

+-

+-

closed; Din;

opposedj +- (Statej

=

+-

f-

opposedj

closed: Dini +-

IClusedlndi l

�

null;

aopening);Send,(DRACK,Lini,Din,)

Statei E {aopening, open, closing} 1\ sin Statei

IListenIndd

--+

null; Send, (RESET, Lin;, sin)

State; = popening 1\ sin =Din, 1\ Tin =Lini State;

o

--+

Stutei = listening --+ Send; (RESET, Lin" sin)

f-

�

Din, 1\ Tin = Lin,

--+

null;

IClosedInd; I

(Statej = aupening); Send,(DRACK, Lini, Din;)

ReeDRACK, enabled: action:

Head(zj) =(DRACK, 8in, Tin)

Zj +- Tail(zj); Statf'-1

o

E

{dosed, listening, aopening, popening, open}

State1 = closlng" sin

Statei +- closed; Din,

�

D-ini A rln = Lin1

t-

null; opposed)

the entities accept data from their local users, and transfer it reliably to the distant users using data and acknowledgment messages. However, all these protocols assume that the entities are initialized correctly and are always open. In [11], we have shown how such single-connection data transfer protocols, can be incorporated with the above connection management protocoL A brief summary follows. Modify the data transfer protocol as follows: include State; open in the enabling condition of each event; in­ clude the sin and rin fields with every message sent; discard a received message unless sin = Dini and r'ln = Lini. Modify the connection management protocol so that entity i initializes its data transfer state variables (e,g" send and receive windows) whenever State; becomes aopening or listening. Consider the union of the modified data transfer and connection management protocols. We have proved in =

+-

---+

"no update"

-+

IClosedlnd,1

(Statej = aopening)

[11] that this combined protocol satisfies the safety and progress requirements of both data transfer and connection management.

B. Bounding the Incarnation Numbers and Handling Entity Crashes

For our connection management protocol to work correctly, we want the following identifier not-in-use condition to hold: When an incarnation number l; is assigned to a new incarnation at i, there is no message in transit from i to j with .�in 2: li, there is no message in transit from j to i with rin = li, and Dinj 1= li. In our protocol as currently specified, this condition is achieved because each entity i remembers the incarnation number of the last active incarnation at i (in the variable Lini), and obtains a new incarnation number by adding 1 to the old one,

1770

IEEE TRANSACTIONS ON COMMUNICATIONS, VOL.

CR.A.O,ORPO

� O1IAOK

� 2\ ------� DR

i.

We now outline how to modify our protocol so that the incarnation numbers can be made modulo-N, for any N > 0, without falsifying the identifier not-in-use condition. First, we assume each channel has a maximum message lifetime and each entity has a maximum response time. Define the maximum roundtrip time TR as the sum of the maximum message lifetimes of channels 1 and 2 and the maximum response time. Second, each entity i has an inactivity timeout T[. If entity i is not closed or listening, and T[ seconds elapses without any message reception, it becomes closed or listening (and sets Dini to null). 3 Third, if Din; I- null and entity i receives a message (M, sin, Tin), it considers sin> Dini iff sin E {D' i ni + 1, . . . , Dini + LN/2J} where the additions are modulo-No Fourth, an incarnation number Ii is assigned to a new incarnation only if at least TR + T[ seconds have elapsed since the incarnation number (Ii - LN /2J) modulo N was last used. (A detailed exposition of this approach for data transfer protocols may be found in [17].) We now outline how to modify our protocol so that it han­ dles entity crashes. We assume that when an entity i crashes, it does nothing for an arbitrary amount of time, and then enters a recovery stage where one of the following hold: (Rl) Lini is set to a value higher than the value just before the crash, or (R2) it retains no information about the old value of Lini' Rl holds if Lini was not lost in the crash, or if Lini is assigned the time from a reliable clock that is incremented faster than the maximum rate at which incarnations can be created. The objective is to set Lini to a value that satisfies the identifier not-in-use condition. Notice that this implies that if there was an incarnation Ij that was connected to an incarnation at i at the time of crash, then incarnation Ij should be closed by the time entity i completes recovery. The following modifications suffice, First, if entity i recovers under Rl, it enters closed with the new value of Lini. Second, if it recovers under R2, it enters a quiet state where it does nothing for TR + TJ seconds, after which it chooses an arbi­ trary value for Lin; and enters the closed state. (If it entered the quiet state at time to, and if TL denotes the maximum 3Thus, if a con nection is idle and the users want it to remain open, then the enlllIes have 10 perIOdIcally send some dummy message, such as a eRA C ".

NO. 12, DECEMBER 1991

message lifetime, then we have the following: a) by to + TL, there are no messages in the channel from i to j; b) by to + TL + T[, entity j has set Dinj to null, and any message it sends after this has Tin = null; c) by to + TL + T[ + TL( to + TR)' only messages with Tin null can be in the channel from j to i,) Third, if entity i is open and receives a message with sin> Dini, it becomes closed. (This happens iff j crashed and recovered under Rl.) =

=

V. COMPARISON

Fig. 3. State transitions at entity

39,

WITH

TCP

AND

ISO TP

TCP and ISO TP4 are two well-known transport protocol standards that are intended for use over channels that can lose, reorder, and duplicate messages in transit. TCP [13], [14] is the transport protocol used in the Internet, an international interconnection of networks that has evolved from the Arpanet. ISO TP4 [4] is a transport protocol standard of the Interna­ tional Standards Organization, In this section, we compare our protocol and its service with TCP and its intended service, A similar comparison with ISO TP4 and its intended service, ISO TS [2], may be found in [12J; it is not included here for reasons of space. Conventions: We use Ii to refer to an incarnation at access point i. We say Ii does action X to mean that user i or entity i does X on behalf of Ii, for example, Ii requests a connection (Le" user i requests a connection and Ii is created as a result), Ii accepts a connection request of lj, etc. We say user j has opposed a connection attempt of Ii to mean that user j was unwilling to accept connections at some instant after l;'s connection request was made. Recall that our protocol satisfies the following progress properties. PI) If Ii requests connection establishment and user j is willing to accept connections and has not opposed Ii'S attempt, then eventually Ii and an incarnation lj are connected (assuming neither closes prematurely), P2) If lJ and 12 simultaneously request connection estab­ lishment and neither user i has opposed l/s attempt, then eventually hand h are connected (assuming neither closes prematurely). P3) If Ii requests connection establishment, then eventually entity i indicates either that Ii is connected or that the request is rejected (and Ii terminated). P4) If it and 12 are connected and Ii requests connec­ tion termination, then eventually both /1 and 12 are terminated. P5) If the users are not connected and refrain from re­ questing connection establishment, and messages in the channels have a maximum lifetime, then eventually the channels become empty. The intended service of TCP has never been specified, although it can be inferred, with some ambiguity, by carefully analyzing the actions in [13], [14]. Except for connection termination, TCP's intended service appears to be almost exactly the same as our service. Each user can request con­ nection establishment, request connection termination, and signal whether or not it is willing to accept remote connection requests. Each entity can indicate connection establishments, connection termination, remote connection requests, and re-

MURPHY AND SHANKAR: CONNECTION MANAGEMENT FOR THE TRANSPORT LAYER

mote termination requests. At most one incarnation can be active at an access point at any time. TCP' s connection termination service differs from ours in two ways. Recall that a connection between incarnations it and 12 has two data transfer paths, one from h to 12, and the other from l2 to h. In TCP, each li can only request termination of its outgoing data path, not its incoming data path. After requesting termination, Ii does not send any more data to lj, but it must continue to accept data of lj until lj issues a termination request. li is terminated only after both data paths are terminated. Another difference is that when Ii requests termination, TCP delays the termination until all outgoing data in transit is delivered to lj. These features can be easily achieved over our service if each user obeys the following protocol: when it has no more data to send and all its data has been acknowledged, it sends a "ready-to-quit" message to the other user; an l, can request connection termination only after receiving this message from lj. There are some other differences between TCP's service and ours that are relatively minor. In our service, a new incarnation is created at i when user i becomes willing to accept connection requests. Whereas in TCP, it is created when a remote connection request is accepted; note that if the request is from an old duplicate then the incarnation becomes terminated without becoming connected. In TCP, an opening user can issue a close request without waiting to become open. A user can immediately terminate an incarnation at any time, by issuing an abort. It appears that the intended service of TCP includes the properties P 1 -P5 of our service specification. This concludes our description of the intended service of TCP. We now describe how TCP attempts to offer its intended service. One major difference between TCP and our protocol (and ISO TP) is in the sequence number spaces used for identifying incarnations and data blocks. In our protocol (augmented with data transfer as described in Section IV) and in ISO TP, two distinct spaces are used. Each data transfer message has sequence numbers identifying data blocks, in addition to the sin and rin fields identifying the incarnations of the connection. Each entity i has counters indicating the next insequence data blocks to be sent and received, in addition to the incarnation number identifiers. TCP uses one cyclic sequence number space (of 232 num­ bers) to identify both incarnations and data blocks. Each TCP message sent by entity i has the form (M, seg.seq, seg.ack) where M indicates the message type, seg.seq indicates the sequence number of the message, and seg.ack indicates the next sequence number expected by entity i. (There are ad- , ditional fields, such as data, segment length, and receive window size, but they need not concern us here.) If M is a primary message type (Le., requiring acknowledgment), then the message (M, n, m) is considered to use up the sequence number n. This means that the next new message (primary or secondary) sent by entity i would have seg.seq equal to n + 1 . Entity j can acknowledge (M, n, m) by sending any message with ,geg.ack equal to n + 1; note that the type of the message sent by j is not important for this purpose.

1771

Each entity i has a state variable Snd. nxt; , which indicates the sequence number of the next message to be sent by i, and a state variable RCV.nxti, which indicates the sequence number of the next message expected from j . Snd.nxti and RCV.nxti are null if there is no active incarnation at i. When an incarnation is created at i, entity i chooses an initial sequence number and assigns it to Snd.nxti. Rcv,nxti is assigned an initial sequence number from a received connection request of j. After this point, any received message with seg.seq i= RCV.nxti is discarded.4 Snd.nxti is incremented whenever a primary message is sent. Rcv.nxti is incremented whenever a primary message is received. Thus, the initial sequence numbers correspond to our incarnation numbers, Snd.nxt corresponds to our Lini and data send counter, and Rnd.nxt to our Dini and data receive counter. We now briefly describe the connection management mes­ sages sent by entity i: Connection request. Ii is an initial (SYN, ii , null) sequence number identifying the re­ questing incarnation. Primary mes­ sage. Connection request sent in response (SY N -ACK, ii , ij) to a (SYN, lj , null). li is an initial sequence number identifying the in­ carnation accepting lj 's request. Pri­ mary message. Acknowledgment only. Secondary (ACK, n, m) message. Reset. Sent when entity i receives a (RST, n, m) message (M, m 1, n) and either i is closed or the message is intended for an extinct incarnation of i. In some cases, the seg.ack field of the RST can be null, instead of m. Secondary message. Request to close outgoing data path . (FIN, n, m) If Ii is the initial sequence number of the local incarnation and k is the number of outgoing data blocks sent, then n = ii + k + 1 ; the sequence numbers {Ii + 1 , , . . . , li + k } have been used to identify the data blocks. -

We next describe the handshakes used in TCP, by con­ sidering some serial behaviors. A description of concurrent behaviors, with the resulting interaction between handshakes, is beyond the scope of this paper. A connection, establishment initiated by it and accepted by 12 is achieved by a three-way handshake of (SY N, 11, null), (SYN -ACK, 12 , II + 1), and (ACK)l + 1 , 12 + 1) mes­ (12 ) becomes open at the end of sages. Incarnation it the second (third) stage. Simultaneous connection requests initiated by h and i2 achieve a connection by a three-way handshake of either ( SYN, i t , null), (SYN-ACK, 12, ll + 1), and (ACK, it + 1 12 + 1) messages, or (SY N, [2 , null), ,

4 Actually, entity i maintains a window of acceptable sequence numbers, {Rc1!.nxt, " ' , Rev.nxt + Rev.wnd} where Rcv,wnd is another variable. However, we need not be concerned with this, because Rev. wnd always equals 1 during connection management.

1772

IEEE TRANSACTIONS ON COMMUNICATIONS, VOL. 39, NO. 12, DECEMBE R 1991

t .-Hert In any �tate �ause� tran.sltJcr. to CLOSE!) ReceptJL>1l 1 cu�rentRsr III any state except LISTENO� SYN_RECEIVED

User reques

Reception of cu�rent SYNlll any state except

Rece�'tIDu ()f CUfrtnt 5TN ,n

Fig. 4.

and

(SY N -ACK, I t , l2 + 1),

(ACK, [2 +

1,

II

nL\]�'" I.r:>n'>lt1 Rcv.nxt.

the handshake,) Later on, suppose 12 requests closing of its

This simplifies the identifier not-in-use condition for TCP:

outgoing data path when

when an initial sequence number Ii is assigned to a new

Snd.nxt2 = 71.2. Then there is a two­ way handshake of (FIN, 71.2 , 71.1 + 1) and (N, nl + 1 , 71.2 + 1 ) messages where N can b e either ACK o r RST a s follows. When It receives the FIN, it sends an AC K response and enters a TIMEWAIT state, in which it responds to further

incarnation at with with

seg.seq seg.ack

there is no message in transit from i to j

i,

= =

li,

there is no message in transit from

Ii, and

Rcv.nxtj =I Ii +

j

to

i

1.

This condition can b e enforced b y ensuring that

TR

+

TJ

It stays in this state until a roundtrip

seconds have elapsed since Ii was last used. It appears that this

time has elapsed since the last FIN received, at which point

is the intention in TCP, but as we now see, there is a somewhat

it becomes closed. In the closed state, entity i sends a

RST

subtle flaw in how TCP implements the wait. TCP specifies

The purpose of the TIMEWAIT state appears to be to

from a 32-bit clock that cycles around once every 4.5 hours

12 gets the ACK response to its RST response. The AC K allows entity

is chosen for an initial sequence number, then it has been at

FIN's

with

response to a

AC K's.

that when an initial sequence number is needed, it is obtained

FIN.

increase the probability that

FIN,

rather than the

2 to learn that all its data has been received by entity the

RST

1,

while

does not convey this assurance. If this interpretation

is correct, then the TIMEWAIT state could be avoided if

l2

issued its close request only after all its outgoing data had been acknowledged. Simultaneous connection termination is achieved by concur­ rently executing the two handshakes above, In this case, both

II

and

12

go through the TIMEWAIT state.

In Fig. 4, we have summarized the state transitions at entity

i

due to user requests and message receptions, The reader

may wish to compare this figure with the corresponding Fig. 3 for our protocol. The states CLOSED, LISTEN, and ESTABLISHED, correspond to the states

closed, listening,

(presumably,

4.5

hours � T] +

TR).

This ensures that if

l;

least 4.5 hours since Ii was last chosen for an initial sequence number. However, because TCP uses the same sequence number space for data also, it is possible for a recently terminated connection of long duration (say 5 hours) and very slow data transfer rate to have used

li

to identify data in the

very recent past. We point out that such a connection would not be unlikely with remote login users. Although TCP does not completely enforce the identifier not-in-use condition, it appears that this does not cause many problems in practice because the environment where TCP is used, the Internet, reorders messages infrequently. Of course, if a problem does arise, it would result in a garbled user-level

5 Remember lhal during connection management, R£v .U!nd equals 1 .

1773

MURPHY AND SHANKAR: CONNECTION MANAGEMENT FOR THE TRANSPORT LAYER

message, which would be either rejected (e.g., by file transfer

and

users) or tolerated (e.g., by mail or remote login users).

whose reception causes entity 1 to become closed. (This

TCP has a crash recovery mechanism similar to ours de­ scribed above. However, there is a problem. In the case of an

R2

recovery, TCP specifies a quiet time equal to the

maximum message lifetime, which is significantly less than the required

+

TR

In fact, TCP suggests a value of

T/ .

2 min, and then leaves it up to "engineering considerations." Also, the TCP specification has some ambiguity regarding the inactivity timer.

satisfy its intended service. These examples do not exploit entity crashes or violation of the identifier not-in-use condition. Recall that connection establishment is achieved by a three­ way handshake, in both TCP and our protocol. For the second

SY N - A CK , whereas

our protocol has two message types, CRAG, and CRPO, to distinguish whether the sender is active or passive opening

IV). We now demonstrate that TCP

cannot guarantee the progress property PI.

Example 1 : Suppose entity 2 is listening, entity 1 has re­ quested a connection with

(SYN, h , null), and the SYN is lost. If entity 1 now receives an old (SYN, x2, null) message, it enters SYN- RECEIVED, sets Rcv.nxt1 to X2, and sends a (SYN-ACK, ll , .1: 2 + 1). When entity 2 receives (SYN-ACK, h , X2 + 1), it sends a (RST, X2 + 1 , null) response, whose reception causes entity

1

example also shows that, in Example for the

to become closed.

Above, entity 2 does not know whether the received

(SY N, ;Vj, null) message, it enters RCV.nxti to Xj + 1 and Snd.nxti to some li, and starts sending (SYN -ACK, Ii , Xj + 1 ) . Because l i =1= Rcv.nxtj, each SYN -ACK reception causes entity j to send a (ACK, lj + 1 , xi + 1) message. Because the ACK's i

receives an old

SYN-RECEIVED, sets

ACK

( SYN, h , null)

it requires two old

problem cannot be solved by specifying that entity

2 ignore the

message; if that were the case, simultaneous

connection requests would lead to livelock. We now present another source of incorrect behavior in

Xj + 1

duplicates to be received, one at

environment.) The crux of the problem is that when entity SYN-RECEIVED,

RCV.nxti

i

is in

may have been set to an extinct

incarnation of j, and yet entity i uses tl1is value to filter out incoming messages. Perhaps it would be better to process a received

(M, Yj Yi) ,

message as follows (altl1ough further

analysis would be required to be sure that this solves the problem): if

Yj

=

RCV.nxti,

process the message as in the TCP

specification; if if

Yj =1= Rcv.nxti and Yi = Snd.nxti, set Rcv.nxti to Yj· Yj =1= RCV.nxti and Yi =1= Snd.nxti, ignore the message

and send no response;

if no message with seg.seq

=

RCV.nxti

is received for a

specified time, return to LISTEN.

VI. COMPARISON WITH RELATED PROTOCOL VERIFICATION W ORK

i is in LISTEN or SYN- SENT states (SYN, Xj , null) message, it sets RCV.nxti to

and enters the SYN-RECEIVED state. In this state, if

connection management, only a few of these are concerned [6], [9], [ 1 8] . The approaches o f Kurose and Yemini [6] and Lin [9] are closest in style to ours. Both these references consider a connection establishment protocol starting with one entity

YJ =1= Rcv.nxti, it (ACK, Snd.nxti , Xj + 1).

active opening and the other entity listening. They do not allow

This can cause problems i f xj i s a n extinct incarnation and 11j

thereby obtaining a significantly simpler system. They allow

is the current incarnation of j . We illustrate two of them.

channels that can lose, reorder, and duplicate messages. They

it receives a message

(1'vI, Yj, z)

While the literature contains many examples of service specifications and protocol specifications for transport layer with proving that the protocol offers the service [ 1 ] , [3], [5],

TCP. When entity and receives a

SY N

each entity. Also, this would not happen in a client/server

is not necessary,

below demonstrates. Finally, note that this

(SYN, X2, null)

to be sent, and so on, leading to infinite chatter!

(We point out that this is less likely than Example 2, because

i n which case i t should be rejected. It chooses the safer second

2

it is not necessary

is from an active opening I I , in

(SYN-ACK, h , ]: ;2 + 1)

as Example

1,

message to be lost.)

(SYN, lI , null)

which case it should be accepted, or from a passive opening ll, option. The loss of the

(RST, X2 + 1, null),

Example 3: Suppose entity 1 and 2 are listening. If each entity

another

We now point out several examples where TCP does not

(as pointed out in Section

and sends a

suffer from the same problem, each ACK reception causes

B. Correctness Problems in Normal Operation of rcp

stage, TCP has only one message type,

X2 + 1 =1= Snd.nxt2),

such that

discards the message and sends an

Example 2: Suppose entity 1 requests a connection with

(SYN, ll , null),

entity

but the response not

yet

reached

and

l2

entity

1.

Snd.nxt2 (SYN -ACK, l2 , II + 1)

At

this

point,

entity 1

connected.

(SY N, X2 , null)

However,

X2

the safety property that if an entity is open, then it knows the

has

other entity's incarnation number. They establish the progress

in

property that a connection is eventually established. These

is

expect

if entity

1

message, then the connection

will not be formed as follows: entity 1 sets

RCV.nxtl

to

and enters SYN-RECEIVED. In this state, whenever

(SYN- ACK, l2 , l1

+ 1) is received, it is discarded and an (ACK, ll + 1 , x2 + 1 ) response sent. When entity 2 receives the ACK, it returns to LISTEN ( because II + 1 Rcv.n:l;t2 =

have incarnation numbers as in our protocol. They establish

l2,

=

2 is in SYN-RECEIVED, and we

to become

receives an old

accepts it with

message

SYN-SENT, entity II

2

connection termination nor simultaneous connection attempts,

properties are special cases of our

Ro

and

RI-3 •

Jurgensen and Vuong [5], Courtiat et al. [3], and Billington

et af. [ 1] consider Petri net models of the ISO TP. These references assume perfect channels that do not lose, reorder, or duplicate messages, and do not consider event parameters. They verify general properties of the Petri nets, such as: at most one token exists in each place, each transition is fired at least once, no unspecified receptions are present, etc. In

1774

IEEE TRANSACfIONS ON COMMUNICATIONS, VOL 39, NO. 12, DECEMBER 1991

addition, references [5], [3] verify some properties specific

delivery of current incarnation data, etc. The comparison of

to connection management, such as: a receiver only receives

our protocol and service to TCP and ISO TP shows that in the

messages sent by the sender, at most one message is in

absence of such convenient representation of properties, both

transit in each direction, and a request at one entity leads

users and protocol designers may be unsure of the properties

to a corresponding indication at the other entity. In [ 1 ], [3],

that a protocol is supposed to offer.

the event sequences generated by the protocol's Petri net are compared with the event sequences generated by the service's Petri net. Sidhu and Blumer [ 1 8] present an automated verification of a finite state machine model of the NBS Transport Protocol Class

4, which

is very similar to ISO TP Class

ACKNOWLEDGMENT

The paper has benefited greatly from the constructive and detailed criticisms of the anonymous reviewers.

4 . They assume

channels that may reorder messages, but do not duplicate or lose messages. As in the Petri net models above, they consider events without parameters. They verify the absence of unspecified receptions and deadlocked states, and the fol­ lowing properties specific to connection management: absence of nonproductive looping through system states; guaranteed progress to the final state; and an upper bound on the number of messages in the channel. The properties verified in the above references are either

REFERENCES [ 1 ] J. Billington, M . e. Wilburham, and M. Y. Bearman, "Automated proto· col verifications," in Protocol Specification, Testing, and Verification V,

M. Diaz. Ed. New York: North-Holland, 1986. [2] CCITT, Transport service definition for open systems interconnection (OSI) for

(e.g., the property that a channel has at most one message in transit).

applications, International Telegraph and Telephone

protocols," in Proc. ACM SIGCOMM '84, June 1984. [4] International Standards Organization, Information processing sys­ tems- Open systems interconnection -Transport protocol specifica­ tion,

included in the properties that we verify in this paper, or do not hold given channels that lose, reorder, and duplicate messages

ccnT

Consultative Committee Recommendation X.2l4, 1 985. [3] J . P. Courtiat, J. M. Ayache, and B. Algayres, "Petri nets are good for

ISO

DIS

8073,

1985.

And

Transport protocol specification

addendum 2: Class fouT operation over connectionless network sen'ice,

ISO 8073IDAD 2, Apr. 1989. [5] W. Jurgensen and S. T. Vuong, "Formal specification and validation of ISO transport protocol components, using Petri nets," in Proc. ACM

SIGCOMM '84, June 1984. [6J J. F. Kurose and Y. Yemini, "The specification and verification of a

connection establishment protocol using temporal logic," in Protocol

VII.

Specification, Testing and Verification II, e. A. Sunshine, Ed.

CONCLUSION

We have presented a connection management service speci­ fication, consisting of a state transition system, a set of invariant requirements, and a set of progress requirements. We have presented a protocol specification, consisting of another state transition system and fairness assumptions. We have defined a correspondence between the protocol events and the service events, and established that the protocol offers the service. The service provided by our protocol is realistic, and is adequate for designing real-life applications that use the transport service. It is not a trivial matter to obtain protocols that achieve desired services given channels that can lose, reorder, and duplicate messages in transit. Verification is important, not only as an end, but as a means to simplify the protocol. Our protocol is as efficient as TCP and ISO TP, and avoids correctness problems that TCP has. For example, it was only through verification that we observed the need for two connection request messages, namely,

CRAG

and

CRPG.

A transport service has both connection management ser­ vice and data transfer service. We are currently developing

[8]

TR-88-60A, Aug. 1988, revised January 1991. To appear in Distributed

Computing. [9] H. P. Lin, "Modeling a transport layer protocol using first-order logic,"

in Proc. ACM SIGCOMM '86, Stowe, VT, Aug. 1986. [10] S. L. Murphy and A. U. Shankar, "A verified connection management protocol for the transport layer," in Proc. ACM SIGCOMM

Maryland, May 1990. [ l 2] S. L. Murphy and A.

and protocol properties, such as eventual establishment of connections between cooperating incarnations, connections be­ ing uncorrupted by messages from past incarnations, eventual

U. Shankar, "Connection management for the

transport layer: Service specification and protocol verification," Comput.

Sci. Dep., Univ. Maryland, CS-TR-205 1 . 1 or UMIACS-TR-88-45.1,

June 1988, revi,eu Dec. 1989. [ 1 3 J Network Information Center, Transmission Control Protocol: DARPA Internet Program Protocol Specification, International, 1981 .

RFC

793, J. Postel, Ed.

SRI

[ l 4] Network Information Center, Requirements for Internet Hosts-Com­ munications Layers,

DRAFT RFC, R. Braden, Ed.

ing Task Force, SRI International, May

[ lS] S. Owicki and D. Gries,

"

22, 1989.

Internet Engineer­

An axiomatic proof technique for parallel

programs I," Acta Informatica, vol. 6, pp. 319-34U, 1976. [ 1 6] A. U. Shankar and S. S. Lam, "A stepwise refinement heuristic for protocol construction," Dep. Comput. Sci., Univ. Maryland, CS-TR1812, Mar. 19�7, revised May 1990. An abbreviated version, entitled

"Construction of network protocols by stepwise refinement," appears

in Proceedings REX Workshop in Stepwise Refinement of Distributed

[ I 7]

stepwise refinement heuristic presented in [ 1 6] . convenient mathematical representations of real-life service

Work­

layered architecture," Ph.D. dissertation, Dep. Compu!. Sci., Univ.

types of entity failures, and different types of connection

This work shows that safety and progress assertions provide

'87

shop, Stowe, VT, Aug. 1 987. [ l 1] S. L. Murphy, "Service specification and protocol construction for a

types of network services ( perfect, loss-only, etc.), different

are constructing protocols from service specifications, using a

IEEE Trans. Software Eng., vol. SE- lO, pp. 325- 342, July 1984. __ , "Specifying modules to satisfy interfaces: A state transition system approach," Compu!. Sci. Dep., Univ. Maryland, Tech. Rep. CS­

specifications of transport services and protocols for different

management service (master/slave, symmetric, etc.) [ l 1 ] . We

New

York: North-Holland, 1982. [7J S. S. Lam and A. U. Shankar, "Protocol verification via projections,"

Systems, Plasmolen-Mook, The Netherlands, May 1989. A. U. Shankar, "Verified data transfer protocols with variable flow control," A.CM Trans. Comput. Syst., no. 3, vol. 7, Aug. 1989. An abbreviated version appeared in Proc. ACM SIGCOMM Stowe , VT, Aug. 1986.

[18]

D. P. Sidhu and T. P. Blumer, "Verification

'86

Symp.,

of NBS class 4 transport

protocol," IEEE Trans. Commun., vol. COM-34, Aug. 1986.

[19] N .

V. Stenning, "A data transfer protocol," Comput. Networks, vol. 1,

pp. 99- 1 10, Sept. 1976. [20] C. A. Sunshine and Y. K. Dallal, "Connection management in transport protocols," Cnmput. Networks, vol. 2, no. 6, Dec. 1978.

MURPHY AND SHANKAR: CONNECTION MANAGEMENT FOR TIlE TRANSPORT LAYER

Sandra L. Mnrphy (S'85-M'90) received the

B.S. degree in mathematics from Purdue University, West Lafayette, IN, the M.S. degree in computer science applications from Virginia Polytechnic Institute and State University, Blacksburg, VA, and the Ph.D. degree in computer science from the University of Maryland, College Park, MD, in 1973, 1976, and 1990, respectively. From 1973 to 1982, she was a computer scientist at the Defense Communications Agency in Reston, VA. Since January 1990, she has been with Trusted Information Systems, Glenwood, MD. Her research interests include the specification, verification, and analysis of concurrent systems, particularly computer network protocols. Dr. Murphy is a member of the IEEE Computer Society and ACM.

1775

A.

Udaya Shankar (S'81 - M'82) received the B.Tech. degree in electrical engineering from the Indian Institute of Technology, Kanpur, the M.S. degree in computer engineering from Syracuse University, Syracuse, NY, and the Ph.D. degree in electrical engineering from the University of Texas at Austin, in 1976, 1978, and 1982, respectively. Since January 1983, he has been with the University of Maryland, College Part, where he is now an Associate Professor of Computer Science. Since September 1985, he has been with the Institute for Advanced Computer Studies at the University of Maryland. His current research interests include the modeling and analysis of distributed systems and network protocols, from both correctness and performance aspects. Dr. Shankar is a member of ACM.