A systematic approach for constructing gateways

79

A Systematic Approach for Constructing Gateways E r n s t W. B I E R S A C K Bell Communications Research, Inc., 445 South Street, Morristown, NJ 07960, USA

Abstract. Numerous homogeneous and heterogeneous networks coexist today. Cooperation between users connected to different networks, which can only be achieved by interconnecting these networks, is necessary in many situations. After introducing the notation used, we present our approach to performing network interconnection in a systematic way. The approach is based on a set of basic components and a toolkit of solutions. The set of basic components fosters systematic detection of the problems one has to deal with when designing a gateway. The toolkit presents an extensive set of solutions for a large number of these problems and provides assistance in selecting the most appropriate solution. We demonstrate the use of the toolkit for the problem of interconnecting error-control mechanisms.

Keywords.Network interconnection, gateway, protocol conversion, interconnection problems, interconnection approaches, interconnection of error-control mechanisms.

:g

1. Introduction 1.1. M o t i v a t i o n

With the current proliferation of communications networks, their interconnection by gateways becomes an urgent necessity. The same reasons that foster the interconnection of single computers into computer networks hold for the interconnection of individual networks to internetworks. Moreover, the broad acceptance of certain services such as electronic mail and news services depends heavily on the participation of a large number of users. This acceptance can only be achieved by interconnecting networks. Up to now, the interconnection of networks has been performed in a rather ad hoc fashion. The objective of this paper is to demonstrate how to approach the problem of interconnecting networks in a more systematic way. 1.2. Notation

--

Ernst Biersack received his M.S. and Ph.D. degrees in Computer Science from the Technische Universit~it Miinthen, Munich, West Germany. For the academic year 1982-1983, he was awarded a fellowship from the Graduate School of the University Of North Carolina at Chapel Hill. From 1983 to 1989 he was a research scientist at the Technische Universit~it Miinchen performing research in distributed systems, performance evaluation, and network interconnection. Since March 1989, he has been a Member of Technical Staff with the Computer Communications Research District of Bell Communications Research. His current research interests include protocols for high-speed networks, intemetworking, and performance evaluation of protocols. Dr. Biersack is a member of the ACM, the IEEE, and the German Association of Computer Scientists. * The work presented in this paper was done while the author was with the Institut fiir Informatik der Technischen Universit~it Miinchen, Munich, FRG. North-Holland Computer Networks and ISDN Systems 18 (1989/90) 79-95

We assume an open system with a layered structure as defined by the ISO OSI reference model for Open Systems Interconnection (OSI) and use a terminology that is consistent with the one defined by the ISO [1]. Nevertheless, the techniques we introduce are not restricted to the OSI architecture but apply to any layered architecture. We consider a scenario as depicted in Fig. 1. The two networks U and V - - r e f e r r e d to as subnets U and V - - h a v e to be interconnected to allow for the communication between the endsystems S (Source) and D (Destination). The two subnets being interconnected form an internet. The scenario can easily be extended to an internetwork comprising more than two subnets. The systems communicating with each other are organized in a layered fashion with X v denoting layer X of architecture Y. The term architecture means a hierarchy of consistent protocols. In the internet depicted in Fig. 1, three different

0169-7552/90/$3.50 © 1990, Elsevier Science Publishers B.V. (North-Holland)

E. IV. Biersack / Constructing gateways

80 Endsystem S

Endsystem D 7c *

Gateway

Iv

C

NA

N~

Ms

1A

1.4

1B

1B

11 Subnet U

Subnet V

1

J Internet Fig. 1. Architecture of the internetwork.

architectures A, B, and C are in use. The interconnection itself takes place between layer NA and layer M B. A K entity denotes an active unit within layer K that executes the protocol of this layer. Above the layer of interconnection, the same protocols have to be used by two entities that communicate with each other. The system interconnecting the two subnets is referred to as a gateway. The part of the gateway that actually performs the interconnection of the layer NA and layer M 8 is referred to as an interconnection unit Protocol mapping and service mapping are the two principal techniques for designing an interconnection unit. A detailed description of both is given in [2]. According to the principles of a layered architecture, an L c entity uses the services of the layer underneath to communicate with its L c peer-entity. For an L c entity, only the services provided by the layer underneath are of relevance and not the protocol providing these services. Therefore, protocols of the layers 1A-NA can be replaced by the protocols of the layers 1B-M B as long as the services provided by the layer NA are also provided by the layer M B. Two special cases of the scenario presented above are of great practical relevance. In both cases, two of the three architectures in Fig. 1 are identical:

1 We prefer the term interconnection unit since it avoids the connotations of the term converter. Conversion is one particular way to interconnect networks. We use the term converter when interconnection by conversion is meant.

Architectures C and A or C and B are identical, i.e. the layers L c - 7 c are identical to either the layers ( N + 1)A-7A or the layers ( M + 1 ) s - 7 B. This is the case, for instance, when within one subnet the higher layers of the ISO protocols are used on top of the transport protocol of the DARPA internetwork, while the second subnet runs ISO protocols only. In this scenario, the layers 1A-NA may correspond to l o s l - 4 o s I, the layers L c - 7 c may correspond to 5osl-7os I and the layers 1B-M B may correspond to the layers IDAR?A--4DAReA.

The architectures A and B are identical, i.e. the layers 1A-NA are identical to the layers 1B-M B. Green [3] refers to this case as substitution. At the gateway, the interconnection takes place between two identical protocols. Note, however, that building such an interconnection unit is not necessarily a trivial task. One example of a substitution is the use of the ISO protocols for the layers 5 - 7 on top of the transport protocol of the DARPA internet, as suggested by the National Research Council [4]. In this case, the layers 1A-NA and I ~ - M , correspond to the layers 1DAReA--4DaRe,~ and the layers L c - 7 c correspond to the layers 5ost-7os ~. In this situation, the services provided by layer 40,4 ReA must be adjusted to match the services expected by layer 5os r Rose [5] discusses the necessary adaptations.

1.3. Preview

Section 2 will introduce the decomposition of a protocol and its service interface into smaller units, referred to as basic components. These basic components have to be considered when constructing an interconnection unit. Section 3 categorizes and illustrates problems typically encountered in network interconnection and presents the two principal techniques for their solution. In Sections 4 and 5, various alternatives for interconnecting error-control mechanisms will be discussed and a toolkit will be introduced that assists classification of the solutions in different ways, makes the interdependencies between the solutions explicit, and presents the solutions in a cohesive way.

E. W. Biersack / Constructing gateways 2.

B a s i c

2.1. General Aspects of Communication The basic components that describe the syntactical aspects of transmission at the lower protocol layers, the address structure, and the types of services provided are - Encoding technique, such as Manchester encoding or N R Z encoding. Data transparency method, e.g. bit or character stuffing. Signal transmission, e.g. digital or analog. Message length indication, e.g. by length field or end of message indicator. - Transmission of blocks of bits or blocks of octets. - Bit ordering within an octet, e.g. high bit first or low bit first. - A d d r e s s , e.g. length or structure such as hierarchical, partitioned, or fiat. - Type of service provided to service user, such as unconfirmed service, confirmed service with -

-

confirmation generated by the local service provider 2, or confirmed service with confirmation by the remote service user. Connection-less or connection-oriented transmission service.

C o m p o n e n t s

Designing an interconnection unit requires an understanding of how the protocols being interconnected operate and what their service interfaces look like. To facilitate this step, we propose the decomposition of the protocol and the service interface into smaller units, referred to as basic components. Using the set of basic components as a checklist, the designer of an interconnection unit can proceed more systematically and is able to identify the problems dearly and deal with each one individually. The following subsections present the basic components that we have identified. The elements identified as basic components may vary with the protocols being considered. Such a list can never be complete, since there may be protocols the author was not aware of that have distinctive features not contained in the protocols considered. However, the basic components have been extracted by studying a wide range of protocols and should prove helpful in many cases. The enumeration of items that belong to a single basic component should be read as instances of this basic component one might encounter when building an interconnection unit.

81

2.2. Connection Establishment - S y n c h r o n i z a t i o n during connection establishment by two-way handshake, three-way handshake, or timer-based connection establishment without exchange of additional messages [7]. Connection establishment with or without the transmission of user data. Treatment of connect collisions, i.e. of the attempt of two entities to establish a connection with each other simultaneously. - Quality-of-service characteristics, such as throughput, transmission delay, connection setup/release delay, priority, protection, reliability, cost, message lifetime, and rate of reported and non-reported errors. Negotiation of transfer syntax, message length, window size, average transmission rate, or message separation, i.e. the interval of time between the transmission of two successive messages [8]. -

-

-

2.3. Data Transfer - T r a n s m i s s i o n mode, e.g. full-duplex, halfduplex, or simplex. - Delimiting of service data units (SDUs), e.g. transmission of SDUs as an unstructured octet stream or delimiting of SDUs. - Sequence numbers, e.g. for individual octets or entire messages. Segmenting/reassembling of data units. - Blocking/deblocking of service data units. - C o n c a t e n a t i o n / s e p a r a t i o n of protocol data units. Multiplexing/demultiplexing of connections. Splitting of a connection. - F l o w - c o n t r o l mechanisms such as stop-andwait, sliding window with static or dynamic window size, rate-based flow control [8], response bits for Token Ring and Slotted Ring, -

-

-

2 This type of service is offered by the LLC Type 2 protocol, which does not provide a .response service primitive [6].

E. W. Biersack / Constructing gateways

82

backpressure between adjacent layers, and backoff parameter for C S M A / C D LANs. - C o n g e s t i o n control by buffer preallocation, source-quench messages [9], implicit or explicit feedback [10], and discarding of messages. - Error-control mechanisms such as checksum, monotonic or sequential sequence numbers, positive acknowledgment (ACK), negative acknowledgment (NAK), implicit acknowledgments [11], selective retransmission of a single message or go-back-N strategy, response bits to realize a hardware ACK, checkpointing by poll/final bit [12] or probe packet [11], static timeout, dynamic timeout, reset of a connection, error messages, duplicate detection, (re-) sequencing, and indication of non-recoverable errors to the service user. and dialogue control, e.g. m i n o r / m a j o r synchronization point, resynchronize, activity s t a r t / r e s u m e / i n t e r r u p t / d i s c a r d / end, and token management. - Other services provided, such as reliable/unreliable broadcast or multicast, expedited data transmitted either in-band or out-of-band. -

S

y

n

c

h

r

o

n

i

z

a

t

i

o

n

-

-

2.4. Connection Release

- Implicit close at layer N by termination of the layer N - 1 connection. See for example the ISO Transport Protocol Class 0 [13]. Graceful disconnect, with or without the the possibility to enclose user data within the disconnect PDU. Abrupt disconnect, with or without the possibility to enclose user data within the disconnect PDU. Connection release after timeout [11]. Transmission of management information associated with the released connection such as the amount of resources utilized or the cost for the connection. -

-

-

-

reports, charging information, or flow control information concerning a connection. The layer operation is normally integrated into the normal communications protocols, e.g. the X.25 Clear packet for carrying charging information or the X.25 Reset packet [15]. Layer management, consisting of those activities necessary to manage all resources within a particular layer. Components of the layer management are routing and mapping of layer N addresses onto layer N - 1 addresses. The layer management can either be achieved by protocol elements that are part of the normal communications protocol, e.g. the X I D or T E S T protocol data units of the LLC Type 1 protocol [6] or by separate layer management protocols 3 such as the DARPAnet Address Resolution Protocol (ARP) [16] or the Internet Control Message Protocol (ICMP) [17]. Systems management, consisting of those activities needed to manage the resources within some or all layers of an open system. Parts of the systems management are the exchange of accounting information and the modification of configuration data. Systems management is provided by an application running at layer 7. A number of basic components for network management have already been described in the previous subsections. In addition to these, the following basic components are part of network management: Configuration management, e.g. initialize protocol, initialize variable, set value, read value, delete value, perform action, or perform routing. Routing can be implicit, explicit, static, dynamic, or source-driven. The routing function is further characterized by the algorithm used for route computation, the information exchanged between nodes, and the information used to make a route selection. Fault management, e.g. report fault, perform action, and perform loopback test. Security management, e.g. use visas [18] and cryptographic techniques such as public keys and symmetric cryptographic methods for authentication. -

-

-

-

-

2.5. Network Management Functions

The ISO management framework [14] identifies three levels of management: - Layer operation, consisting of the mechanisms necessary to control a single instance of communication at one of the 7 layers. Components of the layer operation are the exchange of error

3 The management protocols that exist at the interconnection layer and are essential for the proper operation of the normal communications protocol have to be interconnected too.

E. W. Biersack / Constructing gateways

- Accounting, e.g. reverse charging, flat rating, use stamp and ticket mechanisms. - Performance management, e.g. report event, set value, and read value.

3. Intereonnection

Problems

and Their

Solutions

We can use the list of basic components to identify the problems that arise during the design of an interconnection unit. Problems can be classified as mapping problems that only occur when interconnecting different protocols and interconnection problems that occur when interconnecting identical or different protocols. We illustrate the range of these two problem classes by a non-exhaustive list of typical examples and introduce two principal techniques to solve the problems encountered.

3.1. Mapping Problems Most problems are mapping problems, which stem from differences between the protocols being interconnected. These problems may be caused by: - Different address structures, such as flat vs. partitioned addresses or different ranges for addresses that have the same structure. -Different ranges--either overlapping or not - - f o r the same quality of service parameter. - Different techniques to realize error detection and recovery, e.g. positive acknowledgments (ACKs) vs. negative acknowledgments (NAKs), static vs. dynamic timers, or selective retransmission vs. retransmission of the last k unacknowledged messages. - Different techniques for flow control, e.g. dynamic vs. static windows or rate-based vs. window-based flow control. -Different synchronization techniques during connection establishment, such as three-ways vs. two-way handshake or implicit, i.e. timer based, vs. explicit connection establishment. - Different characteristics of the services being provided, e.g. absence of loss, duplication and reordering vs. the possibility of loss, duplication, or reordering.

83

3.2. Concatenation Problems Concatenation problems can occur when interconnecting either identical or different protocols. The term concatenation used in this context means splicing of protocols. In the context of the ISO OSI reference model [1], concatenation means something different, namely assembling several protocol data units into one bigger unit. Concatenation problems m a y concern: - Quality of service parameters such as error rate or transmission time, since the values for these parameters in an internet environment are calculated by adding up the values of these parameters for the subnets being passed. - Static timeouts, since the transmission time for an internet connection m a y be considerably higher than for a subnet connection, making a timer expire too early and causing unnecessary retransmissions. - Dynamic timeouts, since due to the higher coefficient of variation for the end-to-end delay a timer may adapt too slowly or even converge to a wrong value [19]. See [20] for an algorithm that avoids convergence to a wrong value. - Addresses that are no longer unique. Uniqueness is lost if the same address is used in more than one subnet for denoting different service access points. -Options available for interconnecting the error-control and flow-control mechanisms. - Configuration parameters such as window size and packet size, if they are chosen differently and are non-negotiable.

3.3. Mismatches The two classes of problems described above result in mismatches [3] between the - protocols to be interconnected, - services expected and the services being provided. As far as the second mismatch is concerned, the following cases can occur: - The protocols being interconnected are identical, and the services being provided may not contain all the services being expected, or the services being provided before the network interconnection contain all the services that are expected, but the services being provided after the network interconnection do not. An exam-

84

E. W. Biersack / Constructing gateways

pie for the second is guaranteed delivery within a certain interval of time. The protocols being interconnected are different, and at least one of the two protocols being interconnected does not provide a service that is expected.

3.4. Principal Techniques The two fundamental techniques that can be applied to resolve mismatches are enhancement and deenhancement. The underlying principle of enhancement is to exploit the concept of layered architectures for building more "powerful" services on top of less powerful services. Enhancement can be done in different ways: If the protocol being enhanced is accessible, the necessary modifications may be directly incorporated into the protocol. Otherwise, an additional layer may be put on top of the existing protocol. For examples, see [3]. If the service required is provided by the next higher layer, it is sufficient to move the boundary between the two layers to include the required service. An example where the boundary is moved is given by Groenbaek [21]: In order to provide the graceful close service at the OSI layer 4, which is originally provided by the OSI layer 5, Groenbaek recommends moving up the boundary between layers 4 and 5. Making an enhancement may sometimes be impossible or be restricted to a certain layer. For instance, increasing the throughput is only possible by an enhancement at layers 2 - 4 but not at layers 5-7. Such an enhancement consists in using additional physical links (splitting), in selecting high-bandwidth links (routing), or in using a larger window size (flow control). The technique of deenhancement can be realized in two different ways: - If a basic component such as segmenting, sequencing, or expedited data transfer is not provided by all the protocols to be interconnected, it is not available for internetwork connections. In this case nothing has to be done. - The quality of a service that is provided by all protocols to be interconnected is reduced by introducing an additional layer. This may be adequate if the service requested is a connectionless service and the service provided is con-

nection-oriented. Comer and Korb [22] describe a scenario where the connectionless Internet Protocol (IP) [23] is provided on top of the connection-oriented protocol X.25 layer 3. A deenhancement may only be suitable if it results in services that meet the requirements of the service user. Otherwise an enhancement must be made. Making an enhancement or deenhancement may be expensive in terms of the number of systems where changes have to be made. Changes may affect one or more systems within one or more subnets. Therefore, the applicability of these techniques is restricted to environments in which the systems affected are accessible for changes. The two techniques introduced are generally applicable to the solution of mismatches. Due to limitations of space, we will restrict the presentation that follows to the approaches and solutions for the interconnection of error-control mechanisms. The area of error control is particularly interesting due to the great diversity of existing error-control mechanisms. A description of solutions for mismatches between other basic components is contained in [24].

4.

Solutions

for

Interconnecting

Error-control

Mechanisms

4.1. Introduction This section deals with the interconnection of error-control mechanisms. We introduce three different approaches for interconnecting error-control mechanisms and apply them when presenting various solutions to problems typically encountered during this process.

EndsystemS

EndsystemD

~

~nterconnectionunJt Lower

layers

I

[

~

Lowerlayers

Fig.2. Refinedarchitectureoftheinternet.

E. W. Biersack / Constructing gateways

Before we can start our discussion, we refine the model introduced in Fig. 1. The refinement concerns the layer of interconnection, namely the layer NA and the layer M s and the gateway itself. Figure 2 depicts two entities SEN, located at layer NA of the endsystem S and DEMs located at layer M B of the endsystem D communicating with each other across the internet. The subscript of an entity name denotes the protocol being executed by that entity.

4.2. Approaches Mechanisms

to Interconnect

Error-control

In the following, we assume that the interconnection is performed by protocol mapping i.e. converting the protocol data units of the NA and M B protocol within the interconnection unit 4, which will be referred to as Conv. To realize this type of interconnection, the NA and M B protocol within the interconnection unit have to be directly accessible. Throughout this subsection we make a few assumptions about the protocols to be interconnected, which allow us to make the presentation more precise. These assumed characteristics are met by a wide class of protocols such as the X.25 Protocol, the ISO Transport Protocol [13], and the Transmission Control Protocol [25]. Moreover, the approaches discussed in the following subsections apply to any scenario in which the error-control mechanisms of two protocols are to be interconnected. We assume that the NA and the M B protocol have the following properties: 1. The protocols are connection-oriented. 2. The error detection and recovery mechanisms are implemented by means of sequence numbers, acknowledgments, and retransmission on timeout. A failure to transmit a message successfully is indicated to the upper layer. 3. The number of retransmissions per message is finite. 4. Sequence numbers are used to detect duplicates.

85

mitted and not yet acknowledged. The expiration of the ack-timer will trigger the retransmission of that message and the reset of the ack-timer. We also generate a separate acknowledgment for each message that is received properly, i.e. there is no acknowledgment accumulation. All the essential details are explained by studying the transmission of a single message. To be more specific, we consider the message transfer from SEN~ to DEMa. The NA protocol is used between SE~, and Cony and the M e protocol is used between Conv and DEM. The interconnection is performed by mapping protocol data units. Cony has three alternatives to implement the error-control mechanisms. The alternatives discussed differ by the way they interconnect the error-control mechanisms of the two protocols and by their impact on the end-to-end significance of the error control.

4.2.1. No Interconnection of the Error-control Mechanisms The control information of the NA and M B protocols concerning error control is not interconnected by the interconnection unit: Cony generates an acknowledgement as soon as it has properly received the message from SENA. This approach will be referred to as M1. See Fig. 3 for an illustration of the case where the transmission between Conv and DEMB goes wrong the first time. A complete algorithmic description is given in the appendix. This approach changes the semantics of an acknowledgment for an internet message. An acknowledgment for an internet message arriving at SENA indicates only that the message has been successfully transmitted to Cony. An acknowledgment for an intranet message arriving at SENA means that the message has been successfully received by its peer-entity at the destination. Acknowledgements for internet messages have lost

SEN~

Conv

DEMn

MsgNA

To keep the presentation more concise, we have an ack-timer running for each message trans-

Acklva

)

MsgM~ L~

Timeout 4 W h e n doing service mapping on top of the layers N,4 and M B, the error-control mechanisms are normally not accessible.

L.

11

MsgM8 Ack~

Fig. 3. lnterconnection according to method M1.

86

E. W. Biersack / Constructing gateways

their end-to-end significance. Compared to an interconnection of error-control mechanisms, M1 allows SEN~ to release and reuse resources, such as buffers, faster. M1 also results in a smaller round-trip delay for acknowledgments, which may help increase the end-to-end throughput, depending on the window size. The implications of this change in the semantics depend on the kind of service expected by the service user located at layer L c of the endsystem S and the kind of errors the upper layers Lc-7 c can recover from. If the upper layers rely on the correct transmission of messages through SENA and do not recover from loss, their proper operation and service provision can not be guaranteed. Messages that can not be successfully transmitted between Cony and DEM8 are lost without notifying SEre~. This will impair the service provided by the application layer. On the other hand, if the upper layers have their own error control and ignore the acknowledgments generated by SEN~, the proper operation and service provision of the upper layers are not affected. However, doing error control exclusively at the upper layers may well have an impact on performance, as it can increase the end-to-end delay and reduce the achievable throughput [26,27]. The following two approaches preserve the endto-end significance of error control. For both approaches, the NA and M B protocols executed by Conv must be modified. 5

4.2.2. Partial lnterconnection of the Error-control Mechanisms The converter performs the error control according to the N4 and M B protocol and interconnects the control mechanism for acknowledgments of messages and indications of non-recoverable errors. This implies that the converter does not acknowledge the receipt of a message before it has received the acknowledgment for this message from DEMB. This approach, referred to as M2, has the advantage of preserving the end-to-end significance of the error control for internet connections. SEN~ does not get an acknowledgment before a message 5 We discuss only the modifications necessary to preserve end-to-end significance when transmitting from SEN~ to DEMj. The changes necessary when transmitting from DEMB to SENA are analogous. Note that the modifications are confined to the interconnection unit.

SENA

Cony Msg ~va

Timeout

Msg Na

DEMB

ijrI Timeout

MsgM~ ~

P"

MSgMB L

ACkMB AckNA

.4 [ Section covered by Cony I

Section covered by SE~rA

J

Fig. 4. Interconnection according to method M2.

has been successfully delivered to DEMB and acknowledged by it. Figure 4 illustrates the case where the transmission between Cony and DEMB goes wrong the first time. A complete algorithmic description is given in the appendix. When this method is applied, two problems must be solved: (1) The ack-timers in SENA and Cony have to be properly initialized. This is difficult, because the interval of time that passes between the dispatching of Msg and the receipt of an acknowledgment for Msg depends in part on the number of networks Msg has to traverse and of the network characteristics such as bandwidth and propagation delay. Static timers cannot cope with greatly varying transmission times. (2) The acknowledgments received by Cony must be converted into acknowledgments that will be passed to SEN. To do this conversion, it must be possible to establish a correlation between the acknowledgments received by Conv and the messages to acknowledge that were generated by SEN~ and successfully received by Cony [28]. This can be difficult if Cony fragments messages received from SENA before transmitting them to DEM. Also, the NA and M B protocol may acknowledge different units of information. For instance, the Transmission Control Protocol (TCP) acknowledges individual bytes, while other protocols such as the ISO Transport Protocol or X.25 [29] acknowledge entire messages. Concatenating the error control as described above causes an inherent inefficiency in the way resources, such as buffer space and transmission bandwidth, are used. The following example illustrates this. We assume that Msg has been suc-

E. W. Biersack / Constructinggateways SENa

DEM~

Cony Msg~A

Tiraeout MsgNa

~

MsgMn~

*

MsgMB AckM~

AckNa

4

'4

Fig. 5. Interconnection according to method M3.

cessfully transmitted to Cony and that there are problems transmitting Msg from Cony to DEM. In this case, both Cony and SENA start the retransmission of Msg on expiration of their ack-timers for Msg. We assume that the ack-timers are properly set and do not expire prematurely. What we observe (see Fig. 4) is an overlap in the sections that are managed by the error control of SENA and Cony. In fact, the latter section is fully contained in the former one. Method M2 causes unnecessary retransmissions between SENA and Cony that may reduce the achievable throughput and increase the end-to-end delay. Also, additional CPU-time is consumed and buffer space at SENA is occupied by messages that have already been successfully transmitted to Cony but have not yet been acknowledged to SEN. The waste of resources is even more severe if we consider an internet connection extending across J gateways. In this case, there will be J nested sections.

4.2.3. Complete Interconnection of the Error-control Mechanisms This approach, referred to as M3, avoids the inefficiency of the previous method M2, while retaining the end-to-end significance of the error control. The converter does not perform any error control. Cony passes the entire protocol information that concerns the error control on to the endsystem. Figure 5 illustrates the case where the transmission between Cony and DEMB goes wrong the first time. A complete algorithmic description is given in the appendix. This approach can only be applied if the NA and M 8 protocol are "sufficiently similar" 6--i.e. all of the protocol information concerning the 6 Whether or not the protocols are sufficiently similar has to be decided for each individual scenario with the help of the basic components of the error-control mechanisms.

87

error control of the two protocols has the same semantics. As already observed for the previous method, this method also has to cope with the problems of (1) properly initializing the timers and (2) correlating the protocol information about the acknowledgments. If we compare the three methods introduced, we notice that M1 is the easiest to i m p l e m e n t - - a n d that it allows for a greater difference between the two protocols to be interconnected than the other methods. Method M1 may be appropriate if static timers are used that can be neither set individually nor made dynamic, or if the two protocols interconnected are dissimilar to a degree where the other two methods cannot be applied. The disadvantage of M1 is the loss of the end-to-end significance of the error control. Method M3 is superior to method M2. However, M3 requires a good match of the error-control mechanisms of the two protocols. M2 requires only that the error-control mechanisms can be converted. The different requirements determine the applicability of the methods. For instance, method M3 is not applicable if one protocol uses negative acknowledgments (NAKs) and the other does not. However, method M2 is applicable to this scenario. The impact of the three methods on performance, measured in terms of throughput or delay, is an open question. It needs to be further evaluated to provide the designer of a gateway with more precise advice. The decision whether to choose M1, M2, or M3 mainly depends on the requirements of the service user, on the way the error control is performed, and on the gain in performance achieved by interconnecting the error-control mechanisms at that layer [26].

4.3, Solutions to Mapping Problems of Error-control Mechanisms There are numerous possibilities for implementing error control, giving rise to various mapping problems. We will discuss some typical problems and present solutions for them. For our discussion, we consider an internet connection between SENA and DEMB and assume that the error-control mechanisms are interconnected by applying either method M2 or M3. The solutions presented will depend on the method selected. We do not consider M1, since it does not interconnect the error-control mechanisms.

88

E. IV. Biersack / Constructing gateways

4. 3.1. Error-detection and Recovery Mechanisms In what follows, we describe some typical scenarios that cause mapping problems for errordetection and recovery mechanisms. Detection of transmission errors. The NA protocol detects errors, the M B protocol does not. An evaluation of the situation must consider the provisions for error detection at the other layers. Doing error detection at the lower layers 1 B - ( M 1)s may be sufficient when the error rate caused by gateway error is negligible. If there is error detection at the higher layers L c - 7 c, this fully compensates for the lack of error detection at layer M s and also has the advantage of being able to detect errors introduced by the interconnection unit. If there is no error detection at either layer ls-(M-1)s or L c - 7 c and if the error rate is unacceptably high, only an enhancement of one of these layers can help. -

-

Checkpointing. The NA protocol applies checkpointing, the M s protocol does not. The checkpointing mechanism allows the sender to inquire about the status of a transmission. The receiver of a checkpointing-message is expected to either respond with a positive or negative acknowledgment. Depending on which method (M2 or M3) is used for interconnecting the error controls, Cony reacts as follows: - If method M2 is applied, Cony generates either a positive or negative acknowledgment, depending on the state of the transmission to DE~B. If method M3 is applied, the appropriate way to react is to generate a negative acknowledgment N a k ~ and send it to SEN. This preserves the correctness of the interconnection at the expense of a higher retransmission rate because of unnecessary retransmissions of messages that have been checkpointed before their successful transmission could be acknowledged. See Fig. 6 for an illustration. -

Negative acknowledgments vs. positive acknowledgments. The M s protocol uses both positive and negative acknowledgments, the NA protocol uses only positive acknowledgments. Negative acknowledgments (NAKs) allow the receiver to indicate that it did not successfully receive a certain message. Generating a N A K helps to shorten the time needed for error re-

SEN~

Cony

DEM.

M s g~r,~ ChmsgNA q

Nak1~a

MsgMB

.

*

Msglva '-

Ms g MB D

Fig. 6. Mapping of a checkpointing message ChmsgN, ' if method M3 is applied.

covery compared to a scheme that only uses sender-based error detection via timers and retransmission on timeout. The use of N A K s increases the throughput [30]. The way this situation must be handled depends on which method, M2 or M3, is used for interconnecting the error controls. - If M2 is applied, the N A K is processed by Cony and the messages not properly received by DEMB are retransmitted to DEMB. If M3 is applied, the N A K must be passed to SE~A. Therefore, it is necessary to enhance the NA protocol to generate and handle NAKs. -

Reset vs. disconnect: The NA protocol generates a Reset to indicate a non-recoverable error, the M 8 protocol generates a Disconnect. While a Reset only re-initializes the state-machine of the protocol and drops all messages in transit, the Disconnect immediately terminates a connection with all messages in transit lost. If a Reset Indication generated by SENA arrives at Cono, it can be dealt with in the following ways: Deenhancement: Both connections between SEN~ and Cony and between Cony and DEMB are disconnected: - Cony confirms the Reset Indication by a Reset Response. - Cony generates a Disconnect Request for transmission to SEN~ and DEM: respectively. - Enhancement: When the generation of a Disconnect Request in response to a non-recoverable error is not acceptable, 7 the M B protocol -

7 This may, for instance, be the case if the Disconnect for a layer M B connection leads to an Disconnect of the layer L c connection of the service user, for example, when the M s protocol is X.25 and the L c protocol is the ISO Transport Protocol Class 0.

E. W. Biersack / Constructing gateways

of all endsystems and the gateway must be enhanced to provide the Reset. Duplicate suppression, missequencing, and protection against loss. T h e N A protocol suppresses

duplicates, retains the sequence, and protects against loss. The M a protocol does not. If any of these functions is required by the upper layers to guarantee their proper operation, the only way to provide it is by enhancing the M B protocol.

89

protocols to be interconnected are accessible for an enhancement that allows the protocols to generate and handle these newly introduced error messages. Error messages that are meant f o r error logging.

This type of error message is mainly of interest to the operator of a subnetwork, indicating to him the kind and quantity of errors that have occurred. If the error logging is centralized, it is best to forward these messages through the gateway without any conversion.

Static timeouts vs. dynamic timeouts. T h e N A pro-

tocol uses static timeouts, the M B protocol dynamic timeouts. Static timeouts may come in the following variations. - The timeout interval can be individually set for each connection at connection establishment. If there is a way to properly estimate the roundtrip delay for this connection, e.g. b y discovery messages at connection set-up time, static timeouts may be sufficient. Otherwise, the NA protocol must be enhanced to provide dynamic timeouts. - The timeout interval is the same for all connections. Due to the great variation in transmission times for internet connections, this kind of static timeout can only be used to control intranet connections. If the error control is interconnected by applying method M2 or M3, this restriction is not acceptable, and the NA protocol must be enhanced either to use static timeouts that are specific for each connection or, even better, to use fully dynamic timeouts. 4.3.2. Error Messages

Error messages can be used for different purposes: -

Error messages that are meant to be acted upon.

This type of error message is used to inform an entity about an error that occurred. The entity can either take appropriate action or forward this information to the service user. Error messages are generally intrinsic to the protocol they are used with or even to the particular implementation of a protocol. Normally, there is little hope in mapping error messages between different protocols. If a direct mapping does not work, one can, as a last resort, introduce an additional layer with protocol-independent error messages. This can only be done if the

4. 4. Converter as a Source o f Errors

Besides the errors introduced by the various hardware and software components of the subnets, the interconnection unit itself can introduce errors in three different ways. Because of limited resources such as buffer space and CPU time, it may not always be possible to process all incoming messages, causing a loss of messages. Except for performance considerations, this does not matter. - I f the service provided by the NA and M B protocols does not provide for protection against loss, 8 the upper layers L c - 7 c must do it anyway. - I f the N A and the M B protocol provide for protection and recovery against loss, they will deal with messages lost by the interconnection unit the same way they do with messages lost during transmission over lines. - T h e interconnection unit can, because of hardware malfunction, unintentionally change d a t a - - f o r example, by swapping bytes in main memory [26]. If messages are transformed by the interconnection unit, their checksum loses its end-to-end significance. The N A and M B protocols can offer no protection against this type of error. The only way to detect and recover from this error is by performing error control in one of the upper layers L c - 7 c or by introducing an additional layer on top of the layer of interconnection that performs error detection and recovery. - During execution of the protocol by Cony, a non-recoverable error may occur. If the NA and 8 This is, for example, the case for the layer 2a protocols for the CSMA/CD, Token Ring and Token Bus LANs standardized by the ISO [31-33].

90

E. W. Biersack / Constructinggateways

M B protocols allow generation of Reset Indication or Disconnect Indication protocol data units, Cony must use them.

5. Toolkit of Solutions 5.1. Introduction

In the last section, we discussed solutions for a limited number of problems. If we proceed by presenting solutions for more problems, we will end up with an overwhelming number of individual solutions. What we need is a scheme that allows us to present the solutions to the designer of a gateway in a more amenable way. We define a comprehensive set of generally applicable criteria for evaluating the available solutions. Using these criteria allows us to present the solutions in a cohesive way, while providing addition information. 5.2. Criteria for Evaluating a Solution

In this subsection, a number of criteria will be defined that can be applied to each solution to state the assumptions made, express its cost, evaluate its implications, and describe the mutual interdependencies between solutions. The criteria presented are generally applicable for evaluating any solution for an interconnection problem. They enable the designer of the gateway to carefully evaluate and compare his solutions. Criteria. (a) The original service quality is preserved at the interconnection layer--i.e, there is no reduction of the overall quality of the services provided. (b) The assessment of whether or not the solution is appropriate, depends on the requirements of the service user. 9 (c) The assumptions and preconditions that must be met either to be able to implement the

9 For example, a solution may imply a degradation of the service quality such that a proper sequencing of messages is no longer guaranteed, or may imply a restriction such that a message is only transmitted and delivered if it does not exceed a certain length. If the constraints are clearly stated (see criterion (c)), it can be decided whether a solution is acceptable to a service user.

solution or to make the solution a reasonable choice. (d) If this solution is combined with another solution, for a different problem, the internet will be inoperable. Therefore, the two solutions rule each other out and must not be implemented together. (e) A useful combination of solutions exists, so that this solution complements other solutions in a favorable way. (f) There exists a mutual interdependency between two solutions for two different problems such that if one solution is chosen, the other solution must also be chosen. This is necessary to ensure the consistency of the solutions selected. (g) The systems affected by changes necessary to implement this solution have been identified. A solution may affect all systems of one or more subnets, all systems of the internet, the gateways of one or more subnets, or the gateways of the internet. (h) The additional resources such as bandwidth, links, buffer space, or CPU-time that are necessary to implement this solution have been identified. (i) The impact of the solution on the overall performance of the internet has been stated. Table 1 shows the result of applying criteria (a)-(i) to the solutions presented in the Subsections 4.2, 4.3, and 4.4. Since these subsections contain only that part of the entire set of solutions dealing with error-control mechanisms, we only get the interrelationships that exist between the solutions for error-control mechanisms. Table 1, together with the information provided in the Subsections 4.2-4.4, makes up a toolkit of solutions for the problems related to error-control mechanisms. Annotations to Table 1 The columns a - i of Table 1 contain the results of applying the criteria (a)-(i) to the solutions listed. The following abbreviations are needed to evaluate the solutions. Abbreviations used in column a + The original quality of service is preserved. o The original quality of service may possibly be preserved. From case to case one has to check

E. W. Biersack / Constructing gateways

91

Table 1 Evaluation of the solutions presented Criteria for evaluating a solution

Solution

a

whether

or

not

the

b

c

d

-

+

1

user.

-

-

-

Bu

2

1

2

1

Gs

Bw

1

+

-

3

2, 3

3

2, 3

Gs

Bw

2

-

+

4

-

1'

-

-

+

-

5, 6

-

2',

-

Es, G s

C

3

+

-

7

2'

-

1'

-

-

-

o

+

7

-

2'

Gs

Bw

1

+

-

+ o o +

+ + -

-

-

-

-

o

3'

2'

2'

6 8 9 6

1', 2 ' -

-

2'

1'

4

Es, G s -

2',3"

-

-

2', 3'

-

Es, G s

-

-

+

10

1', 2 '

1'

5

-

-

-

+

-

6

-

2'

2'

Es, G s

C, Bu

4

o

+

11

-

1'

6

-

-

-

o

+

12

-

2', 3'

-

-

1

+

-

6

-

2', 3'

-

C

5

o

+

13

3'

1'

7

-

-

o1

+

14

-

2'

-

Es, G s

C

-

oI

+

-

3'

Ei, G i

C, B w

-

-

-

C, B w

-

-

6, 15

-

.

.

.

.

Es, G s

1'

quality

of whether depends

i

-

o

+

+

-

of

16

-

6, 17

service

is pre-

A b b r e v i a t i o n s used in column b

the service

6',7'

2', 3' 1' 2', 3'

-

-

The

-

Ei, G i

assessment

of whether

is appropriate

assessment

h

+

-

is appropriate

g

C,

The original quality of service is not preserved. o 1 The result depends on the quality of the mapping of the error messages. The

1

-

served.

+

f

e

4P~ 5'

No interconnection of the error control (method M1) P a r t i a l i n t e r c o n n e c t i o n o f the error control (method M2) Complete interconnection of the error control (method M3) No detection of transmission errors: Do nothing No detection of transmission errors: Enhancement No checkpointing: Generate positive/negative ACK No checkpointing: Generate negative ACK N A K s vs. A C K s : Do nothing N A K s vs. A C K s : Enhancement N o Reset: D o n o t h i n g N o Reset: G e n e r a t e D i s c o n n e c t N o Reset: E n h a n c e m e n t N o d u p l i c a t e s u p p r e s s i o n etc.: Do nothing N o d u p l i c a t e s u p p r e s s i o n etc.: Enhancement N o n - i n d i v i d u a l s t a t i c t i m e o u t s vs. dynamic timeouts: Do nothing I n d i v i d u a l s t a t i c t i m e o u t s vs. dynamic timeouts: Do nothing S t a t i c t i m e o u t s vs. d y n a m i c timeouts: Enhancement Different error messages: Do nothing Different error messages: Mapping Different error messages: Enhancement Hardware malfunction: Do nothing Hardware malfunction: Additional layer

on

ments

does

of the service

or not

the

solution

requirements

of

or not

depend

on

the

solution

the require-

user.

A b b r e v i a t i o n s used in c o l u m n c 1 The

upper

layers

transmission the

not

layer 2 The must

since

do not

service they

problems be solved.

do (1)

their and

depend

of

the own

(2)

of

on the correct interconnection

error

control.

Subsection

4.2.2

92

E. W. Biersack / Constructing gateways

3 The problems (1) and (2) of Subsection 4.2.2 must be solved and the protocols to be interconnected must be sufficiently similar. 4 The error detection must be made at one of the other layers. 5 The errors detected can either be corrected or reported. The two protocols interconnected provide for the recovery of detected transmission errors, e.g. by error correction a n d / o r retransmission of garbled messages. Alternatively, it would be sufficient if the two protocols are allowed to report the errors detected to the service user that has to take appropriate action. 6 The endsystems and the gateways are accessible for the changes necessary to implement the enhancement. 7 The protocol that provides for checkpointing is allowed to generate negative acknowledgments. 8 The service user expects neither the indication of errors nor the loss-free transmission of data. 9 A Reset Indication occurs only rarely. A Disconnect Indication does not lead to a disconnect of the connection of the service user. 10 The service user does not expect duplicate suppression, sequencing, and protection from loss. 11 The timeout interval can not be individually set for each connection. 12 The timeout interval can be individually set for each connection, and there is a way to properly estimate the round-trip delay. 13 There is no need to interconnect the error messages, or the error messages are used for error-logging purposes only. 14 The error messages must be acted upon. 15 The error messages must be acted upon, and there is no way to directly map the error messages. 16 The upper layers do not depend on a error-free transmission service or the end-to-end significance of the error detection is retained, since the interconnection unit does not transform messages. 17 There is no error detection and recovery at the upper layers. Abbreviations used in column d

If one chooses the solution marked with the number n in this column, the solution marked

with the number n ' in this column is ruled out. 1' This solution must not be chosen if method M2 is applied. 2' This solution must not be chosen if method M3 is applied. 3' This solution must not be chosen if method M3 is applied and the error messages are meant to be acted upon. Abbreviations used in column e

The solution marked with the number n in this column may be combined with the solution marked with the number n ' in this column. 1' This solution might be chosen if method M1 is applied. 2' This solution might be chosen if method M2 is applied. 3' This solution might be chosen if method M3 is applied. Abbreviations used in column f

If one chooses the solution marked with the number n in this column, the solution marked with the number n ' in this column must also be chosen. 3' This solution must be chosen if method M3 is applied and the error messages are meant to be acted upon. 7' This solution must be chosen if the error messages are meant to be acted upon. Abbreviations used in column g

Es Gs Ei Gi

All endsystems of a subnet must be modified. All gateways of a subnet must be modified. All endsystems of the internet must be modified. All gateways of the internet must be modified.

Abbreviations used in column h

C CPU time. Bw Bandwidth. Bu Buffer space. Abbreviations used in column i

1 Unnecessary retransmissions may cause lower throughput and higher end-to-end delay. 2 Depending on the error rate of the interconnected subnets and the loss rate of the gateways, doing error control only for the entire end-to-end connection m a y be less efficient than doing it for each subnet individually. 3 This solutions leads to higher throughput and

E. IV. Biersack / Constructing gateways

lower end-to-end delay if the layer of interconnection is the lowest layer where error detection can be made. 4 This solution, if implemented at the interconnection layer, leads to higher throughput and lower end-to-end delay as compared to doing it at a higher layer. 5 This solutions leads to higher throughput and lower end-to-end delay, because unnecessary retransmissions are avoided.

5.3. Applying the Toolkit The designer of a gateway first uses the set of basic components to evaluate the two protocols being interconnected and to identify the problems he has to deal with. He then applies the toolkit by iterating the following two steps:

93

different circumstances. Throughout this paper, the intricate field of error-control mechanisms is used to demonstrate the application of the techniques introduced. Numerous solutions are given to problems encountered when interconnecting error-control mechanisms. A list of criteria is defined that can be used to check any solution. The criteria allow the designer to impose a common structure and to evaluate the suitability of a solution within a certain context and with respect to the other solutions available for other problems. Finally, we supply a toolkit of solutions that is easy to apply and provides comprehensive guidance in selecting the most appropriate solution for a problem.

Acknowledgment

1. For each open problem, a solution is selected from the toolkit and criteria (a)-(c) and (g)-(i) of Subsection 5.2 are applied to this solution. 2. The criteria (d)-(f) of Subsection 5.2 are applied to the solutions chosen to ensure that all solutions match. The solutions for which this is not the case are abandoned, leaving some problems unsolved. To these problems, step 1 is applied again, followed by step 2. After a finite number of iterations, for all problems, there will be selected solutions that match.

6.

Conclusion

Interconnecting networks by gateways is a difficult task. We have demonstrated how to tackle this task by introducing several general techniques and explaining their usage: - The basic components provide a comprehensive checklist of items the designer of a gateway must consider. They help him grasp the scope of the task and provide guidance in identifying the mapping and concatenation problems to be solved. - There are two principal techniques, enhancement and deenhancement, that are generally applicable for solving mismatches. - Different solutions can be devised for the problems encountered, each being appropriate under

I thank H.-J. Siegert and H.-G. Hegering for their support and many fruitful discussions during the course of this work. Comments of H.-J. Siegert, R.F. Valta, E.N. Boetsch, C.J. Cotton, W.E. Leland, and P. Regan helped improve the presentation. Also, the detailed comments of one anonymous reviewer are highly appreciated.

Appendix

The appendix contains for all three methods M 1 - M 3 an algorithmic description of their interconnection of the error-control mechanisms. First, we take a closer look at the individual steps during the transmission of a message Msg from SENA to DEMB.We assume that SENA acts as follows: - SEN~ receives from Cony an acknowledgment for Msg: - SEN~ cancels the ack-timer for Msg and discards the copy of Msg. - The ack-timer for Msg expires: - If Msg has been transmitted less than kN~ times: SEN~ retransmits Msg and restarts the ack-timer. - If Msg has already been transmitted kNA times: SEN~ discards Msg and informs the service user that there is a non-recoverable transmission error concerning Msg. We describe the sequence of possible actions right after the following events have occurred:

E. W. Biersack / Constructinggateways

94

- M s g has been t r a n s m i t t e d from SENA to Cony. SENA retains a copy of Msg a n d starts an ack-timer. - Cony has received a copy. Interconnection of the Error-control Mechanism According to Method M1 Cony sends a n a c k n o w l e d g e m e n t for Msg to SEN,, transmits Msg to DEM~, retains a copy of Msg, a n d starts a n ack-timer. After M s g has been t r a n s m i t t e d b y Cony, the following events m a y occur: Cony receives from DEM~ a n a c k n o w l e d g e m e n t for Msg: - Cony cancels the ack-timer for Msg a n d discards the copy of Msg. - Cony receives a reply of Msg: - Msg will be identified as a duplicate a n d discarded. - A t Cony the ack-timer for Msg expires: If Msg has b e e n t r a n s m i t t e d less t h a n kM~ times: Cony retransmits Msg a n d restarts the ack-timer. If Msg has already been t r a n s m i t t e d kM~ times: Cony discards Msg.

Interconnection of the Error-control Mechanism According to Method M3 Cony transmits Msg to DEMB. After Msg has b e e n t r a n s m i t t e d b y Cony, the following events m a y occur: - Cony receives from DEMB a n a c k n o w l e d g e m e n t for Msg: - Cony sends an a c k n o w l e d g e m e n t for Msg to

SEN/ - Cony receives a reply of Msg: - It t r a n s m i t s Msg to D E M .

-

-

-

lnterconnection of the Error-control Mechanism According to Method M2 Cony t r a n s m i t s Msg to DEM~, retains a copy of Msg, a n d starts a n ack-timer. After Msg has b e e n t r a n s m i t t e d by Cony, the following events m a y occur: - Cony receives from DEM, a n a c k n o w l e d g e m e n t for Msg: - Cony cancels the ack-timer for Msg a n d discards the copy of Msg. - Cony sends a n a c k n o w l e d g e m e n t for Msg to

SEN/ - Cony receives a reply of Msg: Msg will be identified as a duplicate a n d -

-

discarded. A t Cony the ack-timer for Msg expires: If Msg has b e e n t r a n s m i t t e d less t h a n kM~ times: Cony r e t r a n s m i t s Msg a n d restarts the ack-timer. If Msg has already b e e n t r a n s m i t t e d kMB times: Conv discards Msg a n d i n f o r m s SENA that it has n o t b e e n able to successfully t r a n s m i t Msg. -

-

R

e

f

e

r

e

n

c

e

s

[1] International Organization for Standardization, Information Processing Systems - Open Systems Interconnection Basic Reference Model, ISO, ISO 7498, 1984. [2] E.W. Biersack, Principles of Network Interconnection, in: Proc. EFOC/LAN 89, Amsterdam, The Netherlands (Information Gatekeepers, Boston, MA, 1989) 37-43. [3] P.E. Green, Protocol Conversion, IEEE Trans. Comm. 34 (3) (1986) 257-268. [4] National Research Council, Transport Protocols for the Department of Defense Data Networks, Internet Request for Comments, RFC 942, Network Information Center, SRI International, Menlo Park, CA, 1985. [5] M.T. Rose and D.E. Cass, OSI Transport Services on Top of TCP, Comput. Networks ISDN Systems 12 (1987) 159-173. [6] Institute of Electrical and Electronics Engineers, Logical Link Control, IEEE Std 802.2-1985, IEEE, New York, 1985. [7] R. Watson, Timer-based Mechanisms in Reliable Transport Protocol Connection Management, Comput. Networks 5 (1981) 47-56. [8] D.D. Clark, M.L. Lambert and L. Zhang, NETBLK: A Bulk Data Transfer Protocol, Internet Request for Comments, RFC 998, Network Information Center, SRI International, Menlo Park, CA, 1987. [9] J. Nagle, Congestion Control in TCP/IP lnternetworks, Comput. Comm. Rev. 14 (4) (1984) 11-17. [10] K.K. Ramakrishnan and R. Jain, An Explicit Binary Feedback Scheme for Congestion Avoidance in Computer Networks with a Connectionless Network Layer, in: Proc. ACM SIGCOMM 88, Stanford, CA (1988) 303-313. [11] A.D. Birrel and B.J. Nelson, Implementing Remote Procedure Calls, ACM Trans. Comput. Systems 2 (1) (1984) 39-59. [12] A. Tanenbaum, Computer Networks (Prentice-Hall, Englewood Cliffs, NJ, 2nd ed., 1988). [13] International Organization for Standardization, Information Processing Systems - Open Systems Interconnection Connection Oriented Transport Protocol Specification, ISO, ISO/DP 8073, 1984. [14] International Organization for Standardization, Information Processing Systems - Open Systems Interconnection Basic Reference Model - Part 4: Management Framework, ISO, ISO 7498-4, 1988. -

-

-

E. W. Biersack / Constructing gateways

[15] International Organization for Standardization, Data Communication - X.25 Packet Level Protocol for Data Terminal Equipment, ISO, ISO/DIS 8208, 1984. [16] D. Plummer, An Ethernet Address Resolution Protocol, Internet Request for Comments, RFC 826, Network Information Center, SRI International, Menlo Park, CA, 1982. [17] J.B. Postel, Internet Control Message Protocol, Internet Request for Comments, RFC 792, Network Information Center, SRI International, Menlo Park, CA, 1981. [18] D. Estrin and G. Tsudik, Visa Scheme for Inter-organization Network Security, in: Symposium on Security and Privacy '87, Oakland, CA (1987) 174-183. [19] L. Zhang, Why TCP Timers Don't Work Well, in: Proc. A C M SIGCOMM 86, Stowe, VT (1986) 397-405. [20] P. Karn and C. Patridge, Improving Round-Trip Time Estimates in Reliable Transport Protocols, in: Proc. ACM SIGCOMM 87, Stowe, VT (1987) 2-7. [21] I. Groenbaek, The TCP and ISO Transport Service, a Brief Description and Comparison, Technical Report Report TM-726, Shape Technical Center, The Hague, The Netherlands, 1984. [22] D. Comer and J.T. Korb, CSNET Protocol Software: The IP-to-X.25 Interface, in: Proc. A C M SIGCOMM 83, Austin, TX 1983, 154-159. [23] Department of Defense, Internet Protocol, MIL-STD1777, 1983. [24] E.W. Biersack, Techniken zum Zusammenschlug yon Rechnernetzen und deren Anwendung auf Protokolle des Transportsystems, Technical Report TUM-I8802, Ph.D. Thesis, Technische Universit~it Miinchen, Munich, West Germany, 1988.

95

[25] Department of Defense, Transmission Control Protocol, MIL-STD-1778, 1983. [26] J.H. Saltzer, D.P. Reed and D.D. Clark, End-to-end Arguments in System Design, A CM Trans. Comput. Systems 2 (4) (1984) 277-288. [27] S.W. Edge, Comparison of the Hop-by-hop and Endpoint Approaches to Network Interconnection, in: J.-L. Grange and M. Gien, eds., Proc. Flow Control in Computer Networks, Versailles, France (North-Holland, Amsterdam, 1979) 359-373. [28] L. Pouzin, Internetworking, in: W. Chou, ed., Computer Communications, Vol. H (Prentice-Hall, Englewood Cliffs, NJ, 1985) 180-221. [29] Corrfit6 Consultatif International de T616graphique et T616phonique, Recommendation X.25 - Interface between DTE and DCE for Terminals Operating in the Packet Mode on Public Data Networks, Orange Book, 7, Geneva, Switzerland, 1980. [30] B. Meister, A Performance Study of the ISO Transport Protocol, in: Proc. 7th Int. Conf. on Distributed Computing Systems, Berlin, West Germany (1987) 398-405. [31] Institute of Electrical and Electronics Engineers, Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, IEEE Std 802.3-1985, IEEE, New York, 1985. [32] Institute of Electrical and Electronics Engineers, Tokenpassing Bus Access Method and Physical Layer Specifications, IEEE Std 802.4-1985, IEEE, New York, 1985. [33] Institute of Electrical and Electronics Engineers, Token Ring Access Method and Physical Layer Specifications, IEEE Std 802.5-1985, IEEE, New York, 1985.