A Reservation-based CSMA Protocol for Integrated

0 downloads 0 Views 298KB Size Report
Oct 8, 1992 - address, source address, frame type, data, and a CRC checksum. ...... been typically proposed separately for CSMA/CD or token ring networks.
A Reservation-based CSMA Protocol for Integrated Manufacturing

3

Networks

Technical Report 216-92 Ra jendra Yavatkar, Prashant Pai and Raphael Finkel Department of Computer Science University of Kentucky Lexington, KY 40506

fra j,[email protected] October 8, 1992

Abstract This paper presents PCSMA, an extension to the CSMA/CD protocol (used in the Ethernet) to support both conventional datagram trac and real-time trac. The protocol provides predictable packet-delivery bounds for real-time trac. It does not require changes to existing Ethernet controllers for datagram trac. Under the new protocol, periodic sources follow a variation of the CSMA protocol that requires them to reserve transmission slots before they can begin transmission. This protocol is intended particularly for use in the integrated network in a manufacturing shop. Periodic sources include multiple sensors generating disparate types and rates of data. We have carried out an extensive performance evaluation of the protocol using a simulation model. The results are impressive: PCSMA shows fewer collisions than CSMA, equivalent delays for conventional trac, and no failures to meet deadlines for periodic trac.

3 This

research was supported in part by the National Science Foundation Grant No. NCR-9111323 and by the Center for Advanced Manufacturing and Industrial Automation of the University of Kentucky.

1

Introduction

This paper presents PCSMA, an extension to the CSMA/CD protocol (used in the Ethernet) to support both conventional datagram trac and real-time trac. The protocol provides predictable packet-delivery bounds for real-time trac. It does not require changes to existing Ethernet controllers for datagram trac. This protocol is intended particularly for use in the integrated network in a manufacturing shop. Our simulation of the protocol shows impressive results. Ethernet is a popular LAN technology that uses a CSMA/CD protocol [1] to arbitrate access to a shared channel. The protocol does not guarantee an upper bound on waiting time before a transmitting host gets access to the channel or on packet delivery time. As a result, packets between a pair of hosts may experience a large variance in transmission delays. The Ethernet protocol works well for conventional datagram sources (remote login, le transfer, RPC applications using the Internet TCP/IP protocol suite), even under a wide range of trac load conditions [2], because trac from such sources is bursty, and these applications can tolerate large variances in delay and throughput. However, certain time-critical applications have more stringent requirements on the amount of delay permissible between the time a packet is ready for transmission and the time it is subsequently received at its destination. An important example of an environment with such requirements is an integrated network in a manufacturing shop. In such an environment, all productive activities are controlled automatically, including machining, assembly, packaging, and shipping, along with such related maintenance activities as failure diagnosis and repair, quality control, and record keeping. In particular, the network integrates two types of trac: (1) conventional datagram trac, used for non real-time interaction and data/ le transfer, and (2) trac from periodic sources that demand predictable packet delivery times. In the second category, a shop may have multiple sensors generating disparate types and rates of data: cameras producing images, strain gauges, actuator position monitors, as well as product temperature, velocity, and weight monitors producing real numbers. These sensors are connected to computers, which are in turn interconnected by networks. Individual computers digitize the data and transmit them to the other machines that make use of the information. The shop also has multiple actuators, ranging from machining tools to manipulators to conveyers. These actuators are connected to computers that generate instructions based on programmed plans but in uenced by the data coming from the sensors (possibly on other computers). Thus, the underlying 1

hardware can be described as multiple, independent computers connected to sensors and actuators and interconnected by a network. An integrated communication network that supports transfer of real-time trac from shop- oor controllers as well as voice, images/graphics, and non real-time data transfers is an essential component of such a distributed manufacturing system [3, 4, 5, 6]. In this paper, we consider the problem of satisfying the demands of an integrated manufacturing environment in a local area network (Ethernet). We present an extension to the Ethernet CSMA/CD protocol to also support real-time trac. Our goal is to avoid making any changes to the protocol used by the existing Ethernet controllers that transmit and receive datagram trac, yet, at the same time, provide predictable packet delivery bounds for the real-time trac. Our protocol extends the conventional CSMA/CD protocol to include a bandwidth reservation policy that accommodates the demands of real-time applications with periodic sources. Under the new protocol, called PCSMA, periodic sources follow a variation of the CSMA protocol that requires them to reserve the transmission slots before they can begin transmission. If two reservations con ict, a con ict resolution algorithm shifts the scheduled transmission of one of the colliding parties to the next available slot such that delivery deadlines of both the sources are met. Thus, periodic sources do not collide with each other. Datagram sources continue to use the same CSMA/CD protocol as before without any changes. When a datagram source collides with a periodic source, the datagram source backs o according to the conventional CSMA/CD protocol, but the periodic source persists and thus succeeds in obtaining access to the channel (e ectively, getting a higher priority). The protocol does not require strict clock synchronization among periodic sources and is completely distributed with no centralized control. We have carried out an extensive performance evaluation of the protocol using a simulation model. The results are impressive:



Our protocol guarantees that all the periodic sources will meet their deadlines provided the aggregate load on the network is less than the 100% of the channel capacity.



A comparison with standard CSMA/CD protocol under identical loads shows that the endto-end delay and throughput of datagram sources obtained under PCSMA are comparable to those observed when all the sources (both periodic and datagram) use the same standard 2

CSMA/CD protocol.



Because periodic sources resolve their channel contention without deadlock, fewer collisions occur when periodic sources use PCSMA than when all sources use the standard CSMA/CD protocol, resulting in better channel utilization.

The rest of this paper is organized as follows. Section 2 describes the Ethernet CSMA/CD protocol and PCSMA for periodic sources. Section 3 describes a simulation model used to evaluate PCSMA and the results of experiments conducted to compare its performance against the Ethernet protocol. Section 4 describes related work and summarizes our results.

2

Protocol details

We distinguish two types of trac sources: datagram and periodic sources. We refer to the hosts that run TCP/IP applications and generate Internet Protocol based packets as datagram sources. We refer to the hosts that run applications that generate repeated trac with stringent requirements on delivery time as periodic sources. Examples of periodic sources are those hosts with manufacturing devices (such as sensors, cameras, actuators, and controllers) and those that generate packet-voice trac. Typically, such hosts generate trac at some periodic rate (for instance, a sensor generates samples 60 times a second), and each packet must be delivered before its arrival

deadline (de ned later). 2.1

Protocol for datagram sources

Under PCSMA, datagram sources use the standard CSMA/CD protocol used on an Ethernet [7, 8]: 1. Before transmitting, the source senses the channel. If the channel is busy, the source continues to sense the channel until the channel is idle. 2. Whenever the source nds the channel idle, it begins transmitting immediately. While transmitting, the source continues to sense the channel and stops transmitting if it detects a collision with another source. 3. When a collision occurs, the source stops transmitting, waits for some time for the activity to subside, and tries again. To avoid repeated collisions, the sources use a binary exponential backo algorithm (details omitted here). 3

2.2

Protocol for periodic sources

To obtain predictable performance, periodic sources must avoid channel contention. They achieve this objective through reservation and persistence. Periodic sources must reserve the necessary transmission bandwidth before beginning transmission. The reservation policy, described later, arbitrates channel access among competing periodic sources. When a periodic source collides with a datagram source, it does not back o , but instead continues to transmit. A periodic packet contains enough overhead bits so that a periodic source does not transmit useful data until the collision with the datagram source(s) is resolved. Standard Ethernet Frame Structure

Preamble

Dest. Address

Source Address

64 bits

48 bits

48 bits

Frame Type 16 bits

Frame Data 368-12000 bits

CRC 32 bits

Frame Header

Periodic Frame Structure

Preemption

Frame Header

Next Source

Next Offset

Next Sample Size

Sample Data

CRC

240 bits

Confirmation Header

Figure 1: The structure of standard Ethernet and periodic frames. Figure 1 shows the structure of an Ethernet frame. The frame consists of a preamble, destination address, source address, frame type, data, and a CRC checksum. Figure 1 also shows the structure of a frame transmitted by a periodic source. The frame contains enough additional preemption bits for a datagram source to detect a collision, stop transmitting, and remove the e ect of interfering transmission from the ether before the periodic source starts sending useful data. The proper number of preemption bits depends on three factors. The largest factor is the round trip propagation delay, which is about 20 microseconds on a 1 Km, 10-Base-5 (IEEE 802.3) Ethernet segment. The other two factors, time to stop the transmission after a collision is detected and time it takes for 4

the interfering transmission to subside, take about 8 microseconds, so the preemption interval is about 28 microseconds or 30 bytes1. A periodic source follows the following protocol: 1. Before beginning transmission, the source sends out a reservation packet using the normal CSMA/CD protocol used by the datagram sources. The reservation packet speci es the relative time and frequency at which the source wishes to transmit and the amount of data to be transmitted every time. The reservation policy and contention resolution procedure are described later. 2. Once the reservation is con rmed, the periodic source transmits at its reserved time slot. (Each slot is long enough to hold 100 bytes, that is, 80 microseconds.) If two periodic sources

have reserved the same time slot, one of them waits until a subsequent slot. This contention

resolution algorithm is described in detail in section 2.4.

3. A periodic source always listens to the channel before transmitting. If it nds the channel busy, the periodic source waits for the channel to become idle before beginning to transmit. Because a datagram source may successfully transmit a frame any time it nds the channel idle, the datagram source may start transmission slightly before the scheduled time of a periodic source. In that case, the scheduled periodic source will nd the channel busy when it is ready to transmit and must wait until the channel is idle. More than one periodic source might be ready to transmit when the channel becomes idle again. Therefore, whenever a periodic source misses its slot, it executes a rescheduling procedure (described later in section 2.5) to determine when to begin its transmission. 4. Once a periodic source starts transmitting, it does not abort the transmission if it detects a collision. The protocol guarantees timely delivery subject to two constraints:



The aggregate trac generated by the periodic sources must be less than 100% of available slots.

1

On more popular 10Base-T Ethernet segments (maximum length is 200 meters), the preemption interval is much smaller; 10 to 15 bytes of preemption bits suce.

5



The period of a source must never be less than 16 slots. (The maximum datagram size is 1500 bytes, equivalent to 15 slots.) In general, periodic sources in manufacturing environments have periodicities of 50 slots (4 ms) or more.

In the following, we provide the details of the PCSMA protocol. 2.3

Reservation policy

A periodic source generates and transmits a xed size sample at a pre-speci ed frequency. We characterize the transmission pattern of a periodic source using three terms: sample size, period, and sample deadline. We measure sample size in terms of slots, where one slot corresponds to 100 bytes (80 microseconds of transmission on an 10 Mbps ethernet)2 . The period of a source is the time interval (measured in slots) between two successive sample generation times. The sample

deadline is the time by which a sample must be delivered. Unless otherwise stated, we will take the deadline to be the time when the next sample is generated. An example of such a source is a strain gauge sampler producing 60 samples per second. Each sample contains about 50 bytes of data. The source in this case has a period and sample deadline of 208 slots, and the sample size is rounded up to one slot. Another example is an 8 Kbps packet voice application, where 20 packets, each containing 50 bytes worth of voice samples, are transmitted every second. An old voice sample must arrive at a receiver before a new sample is generated to ensure continuity. The period and sample deadline are 833 slots, and the sample size is one slot. For the purpose of our discussion, we number slots from 0 onwards and assume all periodic sources maintain a notion of the current slot. Also, to simplify the description, we assume that the perceived slot boundaries at all the periodic sources are synchronized. Later, we will show that it is not necessary to have all the slot boundaries synchronized at all the hosts. Reservation packets indicate the period, sample size, and the o set, which is the slot number at which the rst sample will be sent. Each periodic host maintains a reservation table that keeps track of all the reservations and the current slot. The choice of an appropriate o set is based on the reservations already in force: The o set must not collide with any other reservation that has the same period. Failure to nd a reasonable o set implies higher than 100% bandwidth commitment. (Sources with sample sizes greater than 1 slot may need to reserve several non-adjacent slots, 2

For many periodic sources in the manufacturing environment, the sample size is at most 100 bytes.

6

however). Once the reservation is con rmed (described shortly), the periodic source may begin to transmit on its reserved slots, except when there is a con ict (observable in the reservation table) with another periodic source. For instance, a periodic source with period 10 slots will con ict on every 90th reserved slot with another source that has period 9 slots. On such slots that have expected con ict, the source consults a contention resolution algorithm (described shortly) to reschedule its transmission.

2.3.1 Con rmation As shown in Figure 1, each periodic frame contains three header elds (collectively called the

con rmation header), all referring to the perceptions of the source concerning the slot at which the next periodic transmission (by any source) will take place: who will transmit, when it will transmit (relative o set), and the sample size of the transmission (slots). The con rmation header serves several purposes. First, it helps con rm a pending reservation request. Second, it helps other sources keep their local reservation tables consistent. Third, it keeps track of the next expected periodic transmission and its o set with respect to the current slot. After broadcasting a reservation packet, a periodic host monitors the channel to observe the current reservations (and update its local table if necessary) for at least one period (at most one second) until it sees that its reservation request has been accepted and installed at other hosts (including the periodic host that precedes it in periodic transmissions). Given the reliability of the Ethernet, a reservation packet rarely gets lost, and a reservation request is satis ed in one period. However, if the attempt fails, the periodic source must try again until it succeeds. We currently ignore the issues of fault tolerance and are investigating several alternative algorithms for achieving a fast, distributed, and fault tolerant con rmation procedure [9]. 2.4

Contention resolution

As we have seen, two periodic reservations with di erent periodicities will repeatedly and predictably con ict. For example, if source

A

has a period of 5 slots and source

B

has a period of

6 slots, their transmissions will collide every 30th slot. To resolve such a con ict, one of the two sources must delay its transmission by a slot (or more, if the sample size of the other is more than 7

1 slot) when anticipated con ict is going to occur. We have designed two protocols that resolve such a con ict. Both guarantee that deadlines of con icting sources will be met even if the con ict leads to more con icts with other scheduled periodic sources.

2.4.1 Priority-based resolution Con icts are resolved by assigning priorities to periodic hosts and ordering their transmissions in order of priority.

Rule R1. The con icting source with the earliest deadline gets priority. All other con icting periodic sources wait at least one slot. Typically, the source with shortest period has the earliest deadline, but a long-period source that has yielded repeatedly to higher-priority sources will eventually have a short remaining deadline.

Rule R2. If con icting sources have the same deadline, the source with shorter period gets priority. Because two sources with the same period cannot have the same deadline, these rules always nd a unique source with priority at a given slot. The other con icting sources are deferred to the next slot, when they compete again (possibly with additional sources scheduled to transmit then). The following example illustrates the priority-based algorithm. Consider three periodic sources, A

(period 4, o set 0), B (period 6, o set 1), and C (period 5, o set 2). Figure 2 shows the schedule

formed by these sources. At the start of slot 7, both

B

and

C

will be ready to transmit. But since

C

has an earlier

deadline (it must be nished by the start of slot 12 versus slot 13) it is scheduled at slot 7, and B gets delayed to slot 8. However, A is already scheduled at slot 8, with a deadline at the start of slot 12. Therefore, A gets priority over B and is scheduled at slot 8; B is (at last) scheduled at slot 9 and can still meet its deadline (the start of slot 13). At the start of slot 12, both A and C are ready to transmit, but A gets priority due to its closer deadline. Similarly, contention at slot 13 is resolved by giving C priority over B . This contention resolution algorithm must be executed independently by each source (so that B

knows at slot 13 that C con icts with it, even though C 's original schedule would not con ict). 8

A

B

C

0

1

2

A 3

4

5

6

C

A

B

7

8

9

10

11

A

C

B

12

13

14

Figure 2: Example for Priority-based Resolution. The computation may be performed in advance based on the current reservations. It does not require any communication. In the following, we prove that priority-based resolution guarantees successful delivery of every periodic sample within its deadline, provided aggregate trac is less than 100% of available slots. We start by proving a lemma. We will use the notation [A; B ] to denote a set of slots beginning with the slot that starts at time A and ending just before the slot that starts at time B . The length of [A; B ] is B 0 A.

If all the slots in [ ] are occupied by periodic sources, and each source generates its sample in that interval, and each sample has its deadline by the start of the slot at , then the sources occupy more than 100% of the channel bandwidth. Lemma 1

A; B

B

Proof of Lemma 1: If the same source transmits twice in the interval, we will treat it as two sources. If a transmission has sample size more than 1 slot, we treat each slot of the transmission as a separate source sending a one-slot transmission. (Therefore we don't have to worry about the interval ending in the middle of a multi-slot transmission.) Let the sources be corresponding periods

n.

P1 : : : P

S1 ;

1 11

n

S

with

All sample sizes are 1. The length of the interval is n, and each

slot is occupied by one of the Si . Each source has both sample generation and deadline during the interval [A; B ], so Pj



. In

n

fact, only one source can have Pj = n; we cannot have two sources that generate samples at A and have period exactly n. Now P1j is the fraction of channel bandwidth occupied by source Sj . The total portion of channel bandwidth occupied by the sources S1 ; 1 1 1 Sn is

P1jn

1

Pj

>

P1jn 1 = 1. n

Thus, the sources occupy more than 100% of the channel bandwidth. We are now ready for our main result.

Proposition 1

Given that the sample deadline is equal to the period, the priority-based contention 9

resolution protocol guarantees successful delivery for all periodic sources provided the total number of slots occupied is less than 100% of channel bandwidth. Proof of Proposition 1: Let us consider a source Si with period Xi that generates a sample at the start of scheduled slot Ti . Its deadline is at the start of slot Ti + Xi . Let us further assume that source Si misses its deadline and that the total number of slots occupied by all sources is less than 100% of channel bandwidth. We will derive a contradiction. Since Si misses its deadline, all slots in the window [Ti; Ti + Xi ] must be full. All transmissions in that window must have deadlines of Ti + Xi or earlier, or they would not have pre-empted Si . By the lemma, since we are using less than 100% of channel bandwidth, at least one of those transmissions was generated at some time Tx < Ti and was delayed until our interval. It would not have been delayed until our interval if there were any empty slots in [Tx; Ti]. Therefore, the superinterval [Tx; Ti + Xi] must have no empty slots. The same argument shows that some other transmission from some Sy must be delayed until the superinterval, giving rise to a still longer super-superinterval. The same argument may be repeated inde nitely, showing that there has been a transmission in every slot since the beginning of time. In other words, the channel is utilized at 100%.

2.4.2 Gcd-based resolution Another approach to solving contention is to schedule periodic sources so that they never contend. We de ne a set of acceptable periodicities and only assign periodicities from that set. Acceptable periodicities are selected so that all the scheduling con icts are resolved at the time a periodic source makes a reservation, avoiding the need to priortize the sources later. The method works as follows. We choose a highly composite number

N

close to the number

of slots in one second and restrict the acceptable periodicities to be certain factors of

N

. If we

succeed in assigning slots to periodic sources such that there are no con icts over the duration of N

slots, there will be no future con icts as all assigned periodicities are factors of N . We will illustrate the method by an example. Consider

N

= 600 and suppose acceptable

periodicities are 10, 20, 30, 40, 50, 60, 100, 200 and 300. If two sources request periodicities of 10 each, we assign them o sets 10 and 11 respectively (with subsequent transmissions scheduled at 10

slots 20, 21, 30, 31, and so on). If another source requests a period of 20, it will be assigned the rst available o set, which is 22 (with subsequent transmissions at 42, 62, and so on). If a source requests a period p that is not a factor of N , then the largest acceptable period less than

p

(say, n) is assigned as its period. In our example, if a source requests a period of 25, it

will be assigned a period of 20. Because the assigned period is shorter than the one requested, a few scheduled slots may go unused. For example, the source with period 25 may start transmitting at slot 40 and will transmit at slots 40, 60, 80, 100, but will skip slot number 120 because the next sample will not be ready until slot 125. In general, a packet may be delayed by as many as

0 1 slots under this method. However, the deadline for each packet with period ( 0 1) and will not be missed. n

p

is p slots later

p > n

In general, to accommodate K periodic sources with arbitrary periodicities, it suces to restrict acceptable periodicities such that their gcd (greatest common divisor) is greater than or equal to K

, so long as the shortest acceptable period is acceptable to all K sources. In our example, we are

guaranteed to be able to handle 10 sources, so long as none needs a period shorter than 10. In fact, we can do much better if they do not all have such extreme period. To summarize, this method works as follows: 1. Given K (maximum number of expected periodic sources), N (maximum number of available slots), and

P

(shortest period among all the periodic sources), determine the acceptable

periodicities such that their gcd is at least K but not more than P . 2. Given a request for period p, nd the largest acceptable period (n) that is less than

p

and

assign n as the desired period. 3. Starting at o set n, examine o set n, n + 1, ... in sequence to nd the rst available slot. 2.5

Rescheduling

The datagram sources follow the conventional CSMA/CD algorithm under PCSMA. Once a datagram source has a packet ready for transmission, the datagram source transmits it whenever it nds the channel idle (and there are no collisions). However, this transmission can interfere with the scheduled transmissions of a periodic source. For instance, if a periodic source is scheduled to transmit at a slot when the datagram transmission is already in progress, the periodic source 11

must wait until the channel is idle again. Because a datagram transmission may last for as many as 15 slots3, many periodic sources may get queued during this time. Once the channel is idle, the waiting periodic sources must execute a distributed algorithm to reschedule their transmissions (that is, decide who gets to transmit and in what order). A simple method is to shift all the scheduled sources' transmission slot by the number of slots occupied by the datagram source. However, global shifting does not work well, because some waiting sources may have earlier deadlines than others. Therefore, we adopt the earliest deadline rst policy for rescheduling. Because waiting periodic sources already know all the pending reservations and observe the con ict, each of them independently executes the same algorithm to compute its own transmission time and to avoid con icts. As pointed out earlier, many manufacturing applications typically transmit at a period of 200 slots (every 16 milliseconds) or longer, so rescheduling poses no problems. In general, however, our rescheduling algorithm only guarantees timely delivery provided no periodic source has a period shorter than 16 slots (or a frequency of more than 780 samples per second) and the total number of slots occupied at any time is less than 100% of the bandwidth. 2.6

Synchronization

So far, we have assumed that all periodic sources have synchronized clocks and a coordinated notion of current slot. However, it is not necessary to have strict clock synchronization. Each periodic source's notion of slots is relative. A periodic source keeps track of the current slot based on the trac observed from the other periodic sources and must adjust its clock against the clock drift. Across di erent periodic sources, the time at which a particular slot (and the corresponding transmission) begins may vary depending on the location of the source and destination on the Ethernet cable. However, this skew in their notion of slots is limited by the maximum propagation delay on the Ethernet (50 microseconds). Typically, this skew is o set by the contention interval (also 50 microseconds). Thus, if two periodic sources are scheduled to transmit one after another and if the clock of the rst source is 50 microseconds ahead of the second source, there could be a 50 microsecond gap between two transmissions. However, a datagram source will not be able to transmit during the gap and take the channel away from the second source due to the contention bits. Moreover, each periodic source's transmission lasts for at least one slot (100 3

Maximum datagram packet size on Ethernets is 1500 bytes.

12

microseconds) and, therefore, the second source can adjust its transmission during the gap. On the other hand, if the second source's clock is faster than the rst one, it can correct itself because there will be at least a 50 microseconds overlap between two sources' notion of current slots. A waiting datagram source cannot take over the channel during the overlap. In general, the clocks at periodic sources must be synchronized within 100 microseconds. Several ecient algorithms exist [10, 11] to achieve such a synchronization.

3

Performance evaluation

We have carried out an extensive performance evaluation of the proposed protocol with the following objectives: 1. To verify that the periodic sources achieve the desired predictable performance. 2. To investigate the impact on the performance of the datagram sources when they share the channel with periodic sources. 3. To examine the overall performance of the network in terms of the amount of contention (number of collisions) and e ective utilization. In the following, we describe the simulation environment, simulation model, experiments performed, and the results of our evaluation. 3.1

Simulation environment

We evaluated the performance of our protocol using a discrete-event simulation model. The simulations were performed using the MIT Network Simulator (NETSIM) [12]. NETSIM has been used by several researchers [13] and provides a comprehensive platform for performance evaluation of network algorithms and protocols used in both wide and local area networks. NETSIM allows a user to compose a network con guration out of several basic components such as broadcast or point-to-point channels, hosts or gateways, and various protocol layer modules. It allows a user to control the simulation, log various events, and automatically produce various statistics. NETSIM contains a detailed and accurate implementation of the Ethernet CSMA/CD (IEEE 802.3) protocol

13

developed at the University of Washington [14]. It also incorporates an accurate implementation of the slowstart version of the TCP protocol developed at Purdue University [15, 16]. We extended NETSIM to incorporate PCSMA for periodic sources. We veri ed implementations of both our protocol and the standard Ethernet version by extensive low-level tests using packetlevel traces and by careful examination of an event log that logged every event of interest on the Ethernet. We also validated our simulation model by comparing measured performance against a simpli ed theoretical analysis wherever possible. Application

TCP

DHOST

FTP/Rlogin

PSOURCE/ PSINK

Transport Layer

MAC Layer

MAC Layer

PHOST

Ethernet

Figure 3: Network con guration used in our simulations. 3.2

Simulation model

Under our simulation model, a network con guration consists of six components (see Figure 3:

physical network (Ethernet), datagram host (DHOST), periodic host (PHOST), transport protocol (TCP), datagram application layer (both FTP and rlogin), and periodic source (PSOURCE/PSINK). The six components model the essential parts of a manufacturing network environment in the following way:

Ethernet: Models the passive ethernet cable with its physical characteristics such as propagation delay, channel contention, and delivery of packets to the destination interface.

DHOST: The datagram host component implements the standard Ethernet CSMA/CD (IEEE 802.3) protocol at the Medium Access Sublayer (MAC).

PHOST: The periodic host component implements our proposed protocol at the Medium Access Sublayer (MAC) including the reservation, con rmation, rescheduling, and synchronization 14

methods.

TCP: The TCP component is an elaborate implementation of the popular TCP protocol (Transmission Control Protocol) in the DARPA Internet TCP/IP protocol suite [17]. The component implementation includes the latest version of TCP enhancements including the slow-start congestion avoidance [15] and retransmission timer estimation algorithms [17].

Application: The application layer component implements the datagram applications that are common on an Ethernet. Two most commonly used applications are le transfer (FTP) and remote login (interactive sessions using telnet or rlogin protocols). We chose these two applications to model real-world datagram sources. The two protocols use the TCP component as their transport-layer protocol and emulate workload characteristics as described later.

PSOURCE/PSINK: This component implements the application layer for periodic sources.

A

PSOURCE component models a source speci ed by its period and sample size. The PSINK component receives the samples and maintains statistics on missed deadlines (if any) and end-to-end delay (mean and variance) for the given source-sink pair. 3.3

Workload model

The simulation workload consists of two parts: the periodic workload and the datagram workload. The following two sections describe both workload models.

3.3.1 Datagram workload The datagram workload is de ned in terms of conversations (a conversation consists of a sourcedestination pair with trac owing either in one or both directions). Two major contributors of datagram trac are bulk data transfer (FTP) and interactive applications (rlogin). Each datagram conversation is modeled by packet arrival rate and packet size. Several studies have been conducted to examine the datagram trac characteristics on both local area and wide area networks [18, 19, 20, 21]. Instead of the popular Poisson model for packet arrival, Jain and others [20] have shown that the data transfer trac follows a packet train model. The packet train model captures the burstiness of data transfer in which packets appear in groups or trains. The inter-arrival time of the packets within a train is much smaller than the time interval between the last packet of a 15

train and the rst packet in its successor train. In addition, Danzig and others [21] have shown that the TCP/IP trac on both Ethernet and wide-area networks shows a bimodal distribution. FTP conversations send large amount of data (bytes) in a single direction, whereas interactive conversations send small amount of data in a Poisson stream of small packets in both directions. The packet generation in FTP sources is best modeled by a packet train model, and the packet arrival times of interactive conversations follow a constant plus exponential distribution. In our simulations, we selected the datagram workload based on the studies described above. We simulated FTP and rlogin conversations. Rlogin conversations transmit packets in both directions using a constant plus exponential distribution with 5 milliseconds as the constant and 10 milliseconds as the mean for the exponential distribution. A datagram conversation transfers a long le with le size chosen from an exponential distribution with a mean of 30 KB. An FTP source generates packets in a le transfer using a packet train model where the train size is 8 packets, the intertrain gap is exponentially distributed with a mean of 200 milliseconds, and the interarrival time for packets within a train follows a constant plus exponential distribution as in the case of rlogin. These values are based on the systematic studies conducted elsewhere [22]. An FTP source continuously transfers one le after another with an exponentially distributed silence interval (mean of 1 second) between two successive le transfers. Thus, each FTP source o ers an average load of 15 KBps and each rlogin source o ers a load of 3.3 KBps. The TCP/IP measurement described in [21] show that even though interactive conversations contribute only 5-10% of bytes transmitted on the network, they send 25-40% of network packets. A large number of small packets can cause considerable interference (and channel contention) on a multiple access network such as an Ethernet and should be taken into account in any performance evaluation involving datagram trac. Therefore, we have chosen the ratio of number of FTP conversations to rlogin conversations to be 3:1.

3.3.2 Periodic workload Periodic sources are modeled as source-sink pairs. Each pair is speci ed by its period (number of slots between two consecutive sample generations) and sample size (packet size in slots for each transmission). We rst tested the protocol for a wide range of periodicities and sample sizes, each chosen from a uniform distribution. However, for the purpose of evaluating the impact of 16

periodic trac on datagram conversations, we used sources of equal period and sample sizes in a given experiment4. Each periodic source contributed trac load approximately equal to 5% of the channel bandwidth. We increased the aggregate periodic load in a given experiment by increasing the number of periodic sources. We varied the sample sizes and periodicities from one experiment to another as discussed later. Unless speci ed, periodic sources make reservations and start transmitting at the start of an experiment and transmit continuously at their scheduled slots subject to priority-based contention resolution and rescheduling. Our simulation used perfectly synchronized clocks. 3.4

Performance measures

We measured average throughput, delay, load, and number of collisions on the network. In each simulation experiment, we ran the simulation over a long measurement interval to ensure steadystate behavior, and we always ignored the initial startup interval (typically 10 seconds) to eliminate transient e ects. We repeated experiments with several random seeds and computed the 90% con dence interval for each population mean over several samples (typically 50 or so) [23]. Our performance measures are:

Delay:

The interactive datagram applications (rlogin) are sensitive to end-to-end delay (di erence

between the time at which a packet is rst sent by an rlogin source and the time at which the packet is received by its peer in the conversation) and are not sensitive to e ective throughput. Therefore, we measured the average end-to-end delay for rlogin packets.

Throughput:

We measured the average throughput of FTP conversations, computed as total number

of bytes fully acknowledged during the measurement interval divided by the length of the measurement interval.

Load: Three load levels (low, medium, and high) are speci ed in terms of total number of simultaneous FTP and rlogin conversations. They roughly amount to 20%, 40%, and 60% of the network capacity respectively. We measure the load o ered by periodic sources in terms of the fraction of total network band4

For a given load, uniform period does not change the amount of channel bandwidth taken away from datagram sources. However, this choice simpli es our analysis as we need not repeat experiments for di erent distributions of periodicities and sample sizes.

17

Coarse Distribution

1000 bytes

1000 bytes

1000 bytes

32 ms

time

Fine Distribution

500 bytes

500 bytes

500 bytes

500 bytes

500 bytes

500 bytes

16 ms

Figure 4: Network con guration used in our simulations. width. However, for a given load, distribution of slots occupied by periodic sources is also important for the instantaneous channel contention experienced by datagram sources. Figure 4 shows two distributions of periodic slots on the time axis for identical load. The coarse distribution contains wide slots (1000 bytes) of longer period (32 milliseconds), whereas the

ne distribution contains narrow slots (500 bytes) of shorter period (16 milliseconds) 5 . The two distributions represent two di erent channel access patterns from a datagram source's point of view.

Collisions: We measured the total number of collisions for each experiment and we calculate the con dence interval over the samples collected by repeating the same experiment with several seeds. 3.5

Experimental results

Figures 5 through 22 show the delay, throughput, and number of collisions under the proposed protocol compared to those observed under CSMA/CD for identical load conditions. The measurement interval is 30 seconds of simulation time not including the initial startup time. 5

These sample sizes are much bigger than expected in manufacturing applications. However, our simulator limits the number of simultaneous periodic sources and, therefore, we must increase the sample size to increase the amount of periodic trac.

18

3.5.1 Total number of collisions Figures 5 to 10 show the total number of collisions observed on the network with CSMA/CD and PCSMA at di erent levels of both datagram and periodic loads. There are signi cantly fewer collisions under PCSMA than under CSMA/CD. Under PCSMA, only datagram sources collide amongst themselves, whereas under CSMA/CD, all the sources may collide against each other. Thus, under PCSMA, the channel bandwidth is utilized by two distinct types of users. One type of user shares the channel in a disciplined manner avoiding collisions with each other. They always succeed in utilizing the channel by persisting in transmission when they collide with a datagram source. The other users compete amongst themselves for the share of channel bandwidth not utilized by the rst group. The binary exponential backo strategy in CSMA/CD limits repeated collisions.

3.5.2 End-to-end delay for datagram sources Figures 11 to 16 show the average end-to-end delay for datagram sources at increasing levels of o ered datagram load (low, medium, and high) and with both coarse and ne distribution of periodic sources. At low datagram load, increasing periodic load increases the delay for datagram sources under PCSMA compared to delays experienced when all the sources use the conventional CSMA/CD protocol. This is expected because the periodic sources get higher priority under PCSMA. However, the increase is not signi cant, because interactive applications can tolerate delays of up to 100 milliseconds before performance degradation becomes noticeable. At medium and high datagram loads, datagram delays under PCSMA are comparable to those observed when all the sources use the same CSMA/CD protocol. The reason is twofold. First, channel contention is much higher under these loads and, therefore, datagram sources experience much higher delays when all the sources use the same CSMA/CD protocol. Second, datagram sources face similar channel contention under PCSMA, but the periodic sources no longer collide, resulting in better overall channel access discipline. As a result, datagram delays do not increase signi cantly over those faced in the rst scenario.

19

No. of collisions with new protocol No. of collisions with CSMA/CD confidence interval of new protocol confidence interval of CSMA/CD

140000

No. of collisions

120000

100000

80000

60000

40000

20000

0 0

10

20 30 40 50 60 Periodic load with coarse distribution

70

80

Figure 5: Number of collisions of datagram sources under low datagram load and coarse distribution of periodic slots.

3.5.3 Datagram throughput Figures 17 through 22 show throughput of datagram sources under increasing datagram and periodic loads. Under both CSMA/CD and PCSMA, the overall throughput decreases as the channel contention increases and the reserved fraction of total channel bandwidth taken up by the periodic sources increases. As the load increases and periodic sources occupy the channel for a large amount of time, datagram packets su er a large number of collisions and end-to-end delay increases. Under the slow-start algorithm, when end-to-end delays result in retransmission timeouts over a conversation, TCP adjusts the rate of transmission of new packets, reducing the throughput for the conversation. However, the throughput reduction is similar under both the tested protocols, with PCSMA sometimes providing better overall throughput due to fewer collisions.

3.5.4 Performance of the periodic sources Due to the reservation policy and higher priority in channel access over datagram sources, the periodic sources achieve guaranteed delivery within their deadlines. However, end-to-end delay for packets from a periodic source may vary within the upper bound speci ed by their deadline. The variation results from various factors including propagation delay, priority-based contention resolution, and rescheduling. The total delay experienced by a periodic packet can be written as: 20

250000 No. of collisions with new protocol No. of collisions with CSMA/CD confidence interval of new protocol confidence interval of CSMA/CD

No. of collisions

200000

150000

100000

50000

0 0

10

20 30 40 50 60 Periodic load with fine distribution

70

80

Figure 6: Number of collisions under low datagram load and ne distribution of periodic slots. d

T

= tp + tc + tr

The rst component tp is the sum of propagation and transmission delay, which is xed for a given source-sink pair and packet size. The second component tc is the delay due to contention resolution. The third component tr is due to rescheduling whenever a datagram transmission preempts the transmission of a periodic packet at its scheduled slot. This factor cannot be predicted in a deterministic manner and may vary from 0 to the number of slots within the packet's deadline (the datagram packet transmission itself may last for as many as 15 slots, because the maximum length of a datagram packet is 1500 bytes). We ran simulations to measure the average delay of periodic packets against variations in periodic and datagram load. Plots in Figure 23 shows average end-to-end delay of periodic packets for low, medium, and high datagram loads. In general, the average periodic packet delay never exceeds 350 microseconds and is acceptable even for an unusually short period (about 3000 samples per second). As explained before, the maximum delays for periodic packets were always well within their deadlines.

21

250000 No. of collisions with No. of collisions confidence interval with confidence interval

new protocol with CSMA/CD new protocol with CSMA/CD

No. of collisions

200000

150000

100000

50000 0

10

20 30 40 50 Periodic load with coarse distribution

60

70

Figure 7: Number of collisions under medium datagram load and coarse distribution of periodic slots.

350000 No. of collisions with No. of collisions confidence interval with confidence interval

No. of collisions

300000

new protocol with CSMA/CD new protocol with CSMA/CD

250000

200000

150000

100000

50000 0

10

20 30 40 50 Periodic load with fine distribution

60

70

Figure 8: Number of collisions under medium datagram load and ne distribution of periodic slots.

22

250000 No. of collisions with new protocol No. of collisions with CSMA/CD confidence interval of new protocol confidence interval of CSMA/CD

No. of collisions

200000

150000

100000

50000 0

5

10

15 20 25 30 35 40 Periodic load with coarse distribution

45

50

Figure 9: Number of collisions under high datagram load and coarse distribution of periodic slots.

300000 No. of collisions with new protocol No. of collisions with CSMA/CD confidence interval of new protocol confidence interval of CSMA/CD

280000

No. of collisions

260000

240000

220000

200000

180000

160000 0

5

10

15 20 25 30 35 Periodic load with fine distribution

40

45

50

Figure 10: Number of collisions under high datagram load and ne distribution of periodic slots.

23

35000 Dealy with new protocol Dealy with CSMA/CD confidence interval of new protocol confidence interval of CSMA/CD

30000

Delay in micro-secs

25000

20000

15000

10000

5000

0 0

10

20 30 40 50 60 Periodic load with coarse distribution

70

80

Figure 11: Average datagram delay with low datagram load and coarse distribution of periodic slots.

35000 Delay with new protocol Delay with CSMA/CD confidence interval of new protocol confidence interval of CSMA/CD

30000

Delay in micro-secs

25000

20000

15000

10000

5000

0 0

10

20 30 40 50 60 Periodic load with fine distribution

70

80

Figure 12: Average datagram delay with low datagram load and ne distribution of periodic slots.

24

40000 Delay with Delay confidence interval with confidence interval

35000

new protocol with CSMA/CD new protocol with CSMA/CD

Delay in micro secs

30000

25000

20000

15000

10000

5000

0 0

10

20 30 40 50 Periodic load with coarse distribution

60

70

Figure 13: Average datagram delay with medium datagram load and coarse distribution of periodic slots.

40000 Delay with Delay confidence interval with confidence interval

35000

new protocol with CSMA/CD new protocol with CSMA/CD

Delay in micro secs

30000

25000

20000

15000

10000

5000

0 0

10

20 30 40 50 Periodic load with fine distribution

60

70

Figure 14: Average datagram delay with medium datagram load and ne distribution of periodic slots.

25

31000 Delay with new protocol Delay with CSMA/CD confidence interval of new protocol confidence interval of CSMA/CD

Delay in micro-secs

30000

29000

28000

27000

26000

25000 0

5

10

15 20 25 30 35 40 Periodic load with coarse distribution

45

50

Figure 15: Average datagram delay with high datagram load and coarse distribution of periodic slots.

34000 Delay with new protocol Delay with CSMA/CD confidence interval of new protocol confidence interval of CSMA/CD

33000

Delay in micro-secs

32000

31000

30000

29000

28000

27000

26000 0

5

10

15 20 25 30 35 Periodic load with fine distribution

40

45

50

Figure 16: Average datagram delay with high datagram load and ne distribution of periodic slots.

26

4500

Throughput in Kbytes per 20 secs

Throughput with new protocol Throughput with CSMA/CD confidence interval of new protocol confidence interval of CSMA/CD 4000

3500

3000

2500

0

10

20 30 40 50 60 Periodic load with coarse distributiuon

70

80

Figure 17: Datagram throughput with low load and coarse distribution of periodic slots.

4500

Throughput in Kbytes per 20 secs

Throughput with new protocol Throughput with CSMA/CD confidence interval of new protocol confidence interval of CSMA/CD 4000

3500

3000

2500

0

10

20 30 40 50 60 Periodic load with fine distribution

70

80

Figure 18: Datagram throughput with low datagram load and ne distribution of periodic slots.

27

8500 Throughput with new protocol Throughput with CSMA/CD confidence interval of new protocol confidence interval of CSMA/CD

Throughput in Kbytes per 20 secs

8000

7500

7000

6500

6000

5500

5000

4500

4000 0

10

20 30 40 50 Periodic load with coarse distribution

60

70

Figure 19: Datagram throughput with medium load and coarse distribution of periodic slots.

8500 Throughput with new protocol Throughput with CSMA/CD confidence interval of new protocol confidence interval of CSMA/CD

Throughput with fine distribution

8000 7500 7000 6500 6000 5500 5000 4500 4000 3500 3000 0

10

20 30 40 50 Periodic load with fine distribution

60

70

Figure 20: Datagram throughput with medium load and ne distribution of periodic slots.

28

11000 Throughput with new protocol Throughput with CSMA/CD confidence interval of new protocol confidence interval of CSMA/CD

Throughput in Kbytes per 20 secs

10500

10000

9500

9000

8500

8000

7500

7000

6500 0

5

10 15 20 25 30 35 Periodic load with coarse distribution

40

45

Figure 21: Datagram throughput with high load and coarse distribution of periodic slots.

11000 Throughput with new protocol Throughput with CSMA/CD confidence interval of new protocol confidence interval of CSMA/CD

Throughput with fine distribution

10500 10000 9500 9000 8500 8000 7500 7000 6500 6000 0

5

10

15 20 25 30 35 Periodic load with fine distribution

40

45

50

Figure 22: Datagram throughput with high load and ne distribution of periodic slots.

29

400 Delay with low datagram load Delay with medium datagram load Delay with high datagram load

350

Delay in micro-secs

300

250

200

150

100

50

0 0

10

20 30 40 50 60 Periodic load with coarse distribution

70

80

Figure 23: Average end-to-end delay of periodic packets for low, medium, and high datagram loads. 3.6

Summary

Our simulations show that the PCSMA protocol achieves its goals of providing guaranteed delivery to periodic sources while still allowing datagram sources to operate e ectively. To implement PCSMA, one can use ordinary Ethernet transceivers. However, the reservation, contention resolution, and rescheduling algorithms require that each periodic host listen to all periodic messages. Specialized tranceivers could maintain the reservation table without requiring software intervention.

4

Related Work

Our work is related to other research in two areas: (1) protocols and architectures for manufacturing networks and (2) hybrid LAN protocols that combine random access and controlled access methods. 4.1

Manufacturing Networks

Design of distributed data communication and control systems (DDCCS) and investigation of networking issues is an area of considerable continuing research [24, 25, 6, 4, 26, 5, 27, 3]. Both Manufacturing Automation Protocol (MAP) [7, 24] and Technical and Oce Protocol (TOP) [7, 25] suites have been designed to accomplish the goal of creating a single integrated manufacturing 30

Workstation

Workstation

MAP Interface Control Appli. Program Intelligent Device Controller

IDC

(IDC)

Figure 24: An example of a CIM network that consists of MAP-based device controllers, and a set of workstations that use the TCP/IP suite of protocols and run application programs. environment. Our model of an integrated manufacturing network is similar to the MAP/TOP LAN model and is illustrated in Figure 24. Unlike the MAP/TOP environment that assumes two di erent networks (an IEEE 802.4 MAP token bus and an IEEE 802.3 CSMA/CD TOP network) interconnected by a bridge, we assume an integrated CSMA/CD LAN that consists of two types of components: a group of intelligent device controllers dedicated to speci c testing or manufacturing functions [7] and a set of workstations that act as general-purpose hosts for network operators, managers, and for CAD/CAM applications. Above the MAC layer (or the Logical Link Layer), the device controllers may still use the MAP protocols. The workstations typically will use the DARPA TCP/IP protocol suite (or corresponding protocol layers in the TP suite). Our approach provides a truly integrated network and avoids the problems of routing or congestion that can cause large data latency with a detrimental e ect on the performance of some of the control loops sharing the network [27]. In addition, our approach lends itself to network monitoring and debugging, as we have demonstrated by building a high-level network monitoring facility suitable to such environments [28, 29]. Our PCSMA protocol can also be extended for use on other types of networks, including FDDI and token rings [8].

31

4.2

Hybrid LAN Protocols

Because voice trac is a dominant factor in oce communications and because voice requires delivery within certain delay bounds, integration of voice and data on the same local area network has generated considerable interest in the research community [30, 31, 32]. Protocols for voice integration have been typically proposed separately for CSMA/CD or token ring networks. Because token-passing protocols guarantee a nite delay for channel access, token ring networks can e ectively handle voice and data trac in the same network [33]. Because ordinary CSMA/CD networks cannot guarantee a nite delay bound for channel access, complex methods have been designed to integrate voice and data [34, 35, 32]. Typically, these methods involve modifying the basic operation of a CSMA/CD protocol (and the existing controllers) or implementing a complex voice-handling algorithm [36, 37]. The proposals by Maxemchuck [34] and Chlamtac [35] are both related to the PCSMA protocol proposed here. Under Chlamtac's proposal, the existing datagram hosts continue to use the same protocol as before, and the voice sources get a priority by persisting when they collide with a datagram source. The trac from several voice sources is organized into strings, where adjacent sources use a \handshaking" procedure to pass channel control from one to another before giving up channel access to datagram sources. Our protocol is similar to Chlamtac's protocol in that it also requires a periodic source to persist in the face of a collision to get priority. However, our protocol di ers in many respects. First, we do not assume uniform kind of sources (such as requiring all voice sources to have similar bandwidth requirements and trac characteristics). Second, di erent periodic sources (depending on the application) have di erent deadlines and periodicities and, therefore, must be prioritized amongst themselves and their transmissions arranged so that they meet their individual deadlines. A nice feature of Chlamtac's method, however, is that it uses a completely distributed control with no synchronization necessary among the nodes. Maxemchuck [34] has proposed an interesting variation on CSMA/CD called movable-slot TDM or MSTDM (Movable-slot Time Division Multiplexing) to allow voice packets to preempt data packets in the network. There are some important di erences in his work and ours. First, MSTDM only considers sources of one type with same periodicity and frequency. Our protocol is more general and allows sources with di erent periodicities and deadlines to achieve guaranteed performance. 32

Second, we do not assume a xed slot length for periodic transmission and do not limit the packet size for datagram sources to be less than the length of a periodic packet size. Instead, datagram packet size is only limited by the Ethernet limitation. In the case of periodic sources, a source can transmit a sample of any size it chooses. Due to the reservation procedure, the source that follows always knows the expected sample size of its predecessor and can anticipate its own transmission slot in advance without waiting for the predecessor's transmission to subside. Third, our protocol also considers the case when two periodic sources with unequal periodicities may occasionally collide (as in the case of our GCD example) and resolves the contention in advance without violating individual deadlines. MSTDM does not handle such cases and will resolve any such contention when it arises without regard to deadlines. Unlike previous work in this area, we have simulated and tested our protocol with elaborate model that considers a range of realistic datagram trac conditions based on the recent research in performance monitoring and measurement of TCP/IP trac over LANs.

5

Conclusions

We have described a new protocol that extends the CSMA/CD protocol (used in the Ethernet) to support both conventional datagram trac and real-time trac. The Ethernet protocol works well for conventional datagram sources (remote login, le transfer, RPC applications using the Internet TCP/IP protocol suite). However, certain time-critical applications have more stringent requirements on the amount of delay permissible between the time a packet is ready for transmission and the time it is subsequently received at its destination. An important example of an environment with such requirements is an integrated network in a manufacturing shop. We have designed and tested a new protocol, PCSMA, that satis es the demands of an integrated manufacturing environment in a local area network. The PCSMA protocol provides predictable packet-delivery bounds for real-time trac. It does not require changes to existing Ethernet controllers for datagram trac. Under the new protocol, periodic sources follow a variation of the CSMA protocol that requires them to reserve transmission slots before they can begin transmission. We carried out an extensive performance evaluation of the protocol using a simulation model. The results are impressive:



Our protocol guarantees that all the periodic sources will meet their deadlines provided the 33

aggregate load on the network is less than the 100% of the channel capacity.



A comparison with standard CSMA/CD protocol under identical loads shows that the endto-end delay and throughput of datagram sources obtained under PCSMA are comparable to those observed when all the sources (both periodic and datagram) use the same standard CSMA/CD protocol.



Because periodic sources resolve their channel contention without deadlock, fewer collisions occur when periodic sources use PCSMA than when all sources use the standard CSMA/CD protocol, resulting in better channel utilization.

References [1] R. M. Metcalf and D. R. Boggs. Ethernet: Distributed packet switching for local computer networks. Communications of the ACM, 19(7):395{404, July 1976. [2] D.R. Boggs, J.C. Mogul, and C.A. Kent. Measured Capacity of an Ethernet: Myths and Reality. In Proceedings of ACM SIGCOMM '88, pages 222{234, August 1988. [3] A. Ray and S. Phoha, editors.

Proceedings of the National Science Foundation Workshop on Computer

. The Pennsylvania State University, Nov. 1987.

Networking for Manufacturing Systems

[4] A. Ray and S. Phoha. Research Directions in Computer Networking for Manufacturing Systems. Journal of Engineering and Industry, May 1989. [5] A. Ray. Fiber-optic based networks for computer-integrated manufacturing. In INFOCOM '89, pages 210{211. IEEE, April 1989.

ASME

Proccedings of IEEE

[6] R.R. Karpe, S. Mahalingam, and S.N. Dwivedi. Concepts of the Factory of the Future. In R. Raghvan and T.J. Cokonis, editors, Proceedings of the 1987 ASME International Computers in Engineering Conference, pages 47{51, August 1987. [7] G. Kaiser.

. McGraw-Hill Publishing Company, 1989.

Local Area Networks

[8] A. Tanenbaum.

. Prentice Hall, Inc., second edition edition, 1988.

Computer Networks

[9] P. Pai. Operating Systems and Networking Support for Distributed Real-time Applications. Master's thesis, University of Kentucky, August 1992. in preparation. [10] D. Mills. Network time protocol (version 2) speci cationa nd implementation. Network Working Group Requests For Comments RFC 1119, July 1990. [11] F. Cristian. A probabilistic approach to distributed clock synchronization. 3:146{158, 1989. [12] Andrew Heybey.

,

Distributed Computing

. MIT Laboratory for Computer Science, 1988.

MIT Network Simulator

[13] MIT NETSIM mailing list. [email protected]. [14] Hellmut Golde. University of Washington version of MIT Network Simulator. Department of Computer Science and Engineering, University of Washington, October 1991. available by anonymous FTP from june.cs.washington.edu. [15] Van Jacobsen. Congestion avoidance and control. In pages 314{329, August 1988.

34

,

Proceedings of ACM SIGCOMM '88 Symposium

[16] Ken Rodeman. Purdue University version of MIT Network Simulator. Department of Computer Science, Purdue University, April 1990. [17] Douglas Comer. Inc., 1988.

. Prentice Hall,

Internetworking With TCP/IP: Principles, Protocols, and Architecture

[18] Gusella R. A Measurement Study of Diskless Workstation Trac on an Ethernet. on Communications, 38(9):1557{1568, September 1990. [19] Braden RB. A Pseudo-Machine for Pacekt Monitoring and Statistics. In SIGCOMM 88, pages 200{209, August 1988.

IEEE Transactions

In Proceedings of ACM

[20] R. Jain and S.A. Routhier. Packet Trains-Measurements and a New Model for Computer Network Trac. IEEE Journal on Selected Areas in Communications, 4(6):986{995, Sept 1986. [21] Ramon Caceros, Peter B. Danzig, Sugih Jamin, and Danny J. Mitzel. Characteristics of Wide-Area TCP/IP Conversations. In Proceedings of the ACM SIGCOMM Symposium: Communication Architectures and Protocols. ACM, 1991. [22] P. B. Danzig and S. Jamin. tcplib: A Library of TCP Internetwork Trac Characteristics. Technical Report USC-CS-91-495, Computer Science Department, University of Southern California, Los Angeles, California, 1991. [23] Raj Jain.

The Art of Computer Systems Performance Analysis: Techniques for Experimental Design,

. John Wiley and Sons, Inc., 1991.

Measurement, Simulation, and Modeling

[24] M. A. Kaminsky Jr. Protocols for communicating in the factory. [25] S.A. Farowich. Communicating in the technical oce.

, 23:56{62, May 1986.

IEEE Spectrum

, 23:63{67, May 1986.

IEEE Spectrum

[26] A. Ray, S.H. Hong, Y. Halevi, and S. Lee. Communication Networks for Autonomous Manufacturing and Process Control. In R. Raghvan and T.J. Cokonis, editors, Proceedings of the 1987 ASME International Computers in Engineering Conference, pages 39{47, August 1987. [27] A. Ray and A. Ayyagari. Networking for Real-Time Control of Integrated Manufacturing Processes. In Proceedings of the IEEE 1988 Conference on Robotics and Automation, pages 450{452, April 1988. [28] T. Narten and R. Yavatkar. Performance Monitoring and Debugging Tools for a CIM Network. In Proceedings of the IEEE 1991 Conference on Robotics and Automation, April 1991. [29] W. Gruver and J. Boudreaux, editors. Programming Environments for Computer Integrated Manufacturing, chapter EPAN: An Extensible Packet Analysis Utility for CIM Environments. Springer-Verlag, 1992. To appear. [30] O.C. Ibe and D.T. Gibson. Protocols for Integrated Voice and Data Local Area Networks. Communications Magazine, 24:30{36, July 1986. [31] Rubin and Baker. Media Access Control for High-Speed Communications Networks. IEEE, 78(1), January 1990. [32] M. Decina and D. Vlack.

IEEE

Proceedings of the

IEEE Journal on Selected Areas in Communications: Special Issue on Packet

, volume SAC-1. IEEE Communicatiosn Society, December

Switched Voice and Data Communication

1983.

[33] T. Suda and T.T. Bradley. Packetized Voice/Data Integrated Transmission on a Token Passing Ring Local Area Network. IEEE Transactions on Communications, 37(3):238{244, March 1989. [34] N.F. Maxemchuck. A Variation on CSMA/CD That Yields Movable TDM Slots in Integrated Voice/Data Local Networks. Bell System Technical Journal, 61(7):1527{1550, September 1982. [35] I. Chlamtac. An Ethernet compatible protocol for real-time voice/data integration. Computer Networks and ISDN Systems, 10(2):81{86, September 1985. [36] S. Q. Li and J. C. Majithia. Performance analysis of a DTDMA local area network for voice and data. Computer Networks and ISDN Systems, 9:81{91, April 1984.

35

[37] R. K. Goel and A. K. Elkakeem. A hybrid FARA/CSMA/CD protocol for voice-data integration. Computer Networks and ISDN Systems, 9:223{240, March 1985.

36