An efficient approach for token-ring LAN emulation over ATM

computer communicatbns

ELSEVIER Computer Communications 20 ( 1997) 1133- 1145

An efficient approach for token-ring LAN emulation over ATM

Reuven Cohen*, Eli Stein

Department of Computer Science, Technion, Haifa 32000, Israel

Received 13 November 1996; accepted 19 May 1997

Abstract

The LAN emulation service defined by the ATM Forum provides a mechanism for running existing LAN applications in the ATM environment. Each Emulated LAN (ELAN) is one of two types: Ethernet/IEEE-802.3 or IEEE-802.5 token-ring. The interaction of the LAN Emulation with the 802.5 Source Routing protocol may lay heavy broadcast load over the ATM backbone. The paper presents an efficient

scheme for connecting remote 802.5 token-ring LANs through an ATM backbone. The proposed scheme uses intelligence at the ATM- bridges in order to minimize the ATM broadcast load. 0 1997 Elsevier Science B.V.

Keywords: Token-ring; Source-Routing: ATM; LAN-Emulation; Learning-Bridges

1. Introduction

Most data traffic in existing Local Area Networks (LANs) is sent over an Ethernet/IEEE 802.3 [l] and IEEE 802.5 [2]

networks. In order to enable existing applications to access an ATM network via protocol stacks like APPN, NetBIOS,

IPX, AppleTalk etc., as if they were running over traditional LANs, the LAN emulation service was defined by the ATM

Forum [3]. This service is defined at the MAC layer in order to provide support for the maximum number of existing applications.

This article presents an efficient approach to use the LAN emulation service in order to enable MAC layer connectivity among remote 802.5 token-rings across an ATM backbone, thus creating a token-ring emulated LAN. The

considered network model is presented in Fig. 1. The figure

shows three domains of bridged token-ring networks connected to an ATM backbone by means of ATM-bridges

al - u3. Each token-ring domain consists of one or more token-rings connected by source routing (SR) bridges. The

communication between every two stations in the ELAN is performed at the MAC layer. If the two stations reside at the same domain, MAC layer connectivity is provided by means of the SR bridges [2,4]. If the two stations reside in different token-ring (TR) domains, MAC layer connectivity is provided by means of SR bridges along with the LAN Emulation service as defined in ref. [3].

* Corresponding author.

0140-3664/97/$17.00 0 1997 Elsevier Science B.V. All rights reserved PII SO140-3664(97)00132-l

According to [3], an ELAN is composed of a single LE service and a set of LAN Emulation (LE) clients. Every LE client is a part of an ATM end station representing a set of users identified by their MAC addresses. In terms of Fig. 1,

the LE client functionality is performed by the ATM- bridges al - u3. Each ATM-bridge provides this functionality to the legacy TR stations residing in its domain.

The LE service consists of an LE server (LES), an

LE Configuration Server (LECS), and a Broadcast and Unknown Server (BUS). The LE Server provides the facility

for registering MAC addresses and resolving such addresses into ATM addresses of the appropriate LE client. The LECS implements the assignment of individual LE clients to different ELANs. The BUS handles data frames sent via the LE

clients to the broadcast address or to any Multicast address. In addition, it handles unicast data frames sent by a source

LE client before the latter is able to forward them directly to the destination LE client. Communication among LE cli-

ents, and between LE clients and the various components of the LE Service is performed over data and control ATM VCCs (Virtual Channel Connections).

The predominate bridging technology in token-ring networks is source routing (SR). In SR the source station is

responsible for determining the entire route to its destination. In order to find a route, the source invokes an instance of the Route Determination Protocol [2,4] before sending data frames to the destination. A description of the route discovered by the protocol is attached to the routing information field in the header of each frame, and is used by the SR bridges in order to make routing decisions.

1134 R. Cohen, E. Stein/Computer Communicarions 20 (1997) 1133- 1145

#------- _____________~ SR domain #2 ;

SR domain # 1:

/$&

r________________________,

: \ i SR domain #3

=4

3

6

Fig. 1. An ELAN consisting of three SR domains

The SR Route Determination Protocol was designed for

private local networks with an inherent broadcast capability, such as those consisting of a small number of token-rings. Executing this protocol in a SR ELAN with a public wide

area ATM backbone would be expensive and slow. This is because the LE clients of the SR ELAN will have to use the LAN Emulation BUS service very often, in order to multicast ROUTE_DISCOVERY frames over the ATM back-

bone to the other LE clients. This article presents a scheme whereby intelligence at the ATM-bridges is used

in order to minimize the number of messages needed to be

transmitted over the ATM backbone. The main idea is to use the ATM-bridge of each domain as a proxy for destinations of remote segments. An indispensable component to the proposed scheme is a distributed Remote Search Protocol (RSP) that allows an ATM-bridge to locate a remote destination while, on the average, exploring a minimum number

of ATM-bridges. The proposed scheme minimizes the number of accesses

to the BUS without sacrificing the main advantage of SR. Namely, if there are several possible paths between a source/destination pair, the source does not necessarily use the same route for all the sessions it has with the destination. Rather, the source invokes the SR Route Determina- tion Protocol periodically in order to locate the best route available for every session.

The rest of the article is organized as follows. Section 2 describes the execution of the SR Route Discovery Protocol

in an ELAN as dictated by the LAN Emulation standard [3],

and the main concepts of the proposed scheme. Section 3 describes the functionality of an ATM-bridge in the new scheme. Section 4 describes the Remote Search Protocol (RSP) executed by the ATM-bridges. Section 5 proves the correctness of the RSP and analyzes its cost in terms of number of messages needed to be sent over the ATM backbone. Section 6 presents simulation results and Section

7 concludes the article.

2. Source routing in an ELAN

In an SR bridged LAN, a source station must determine in advance the route to the LAN of its destination, and include a description of this route in the header of each frame. A route description consists of a list of ring number and bridge

number pairs. For instance, if station s4 in Fig. 1 wants to send a data frame to station s5, it can use two possible routes: through be, or through b4 and b5. The route description list of the first route is (t-6, be, r-7,}, and of the second route is { r6, b4, I-5, b5, r7,).

In order to determine a route to the destination, a source station invokes the following Route Determination Protocol [2,4]. The source sends on its local ring a ROUTE_ DISCOVERY frame containing the MAC address of its destination. If the destination is in the local ring, the source receives a response to its ROUTE_DISCOVERY frame. In

R. Cohen, E. Stein/Computer Communications 20 (1997) 1133-l 145 1135

such a case it will not have to specify routing information in

the data frames sent to the destination. If the destination

does not reside in the local ring, the source has to broadcast

a ROUTE_DISCOVERY frame over all the rings in the entire bridged-LAN. As the frame is copied by every bridge from the ring over which it was received to the other rings connected to the bridge, the bridge appends routing infor-

mation to the header of the frame. Consequently, each route between the source and the destination is traversed by exactly one ROUTEDISCOVERY frame’. When the destination receives a ROUTE_DISCOVERY, it responds with a RESPONSE frame, and the latter is routed back to

the source through the route discovered by the received ROUTE_DISCOVERY frame. Upon receiving a

RESPONSE frame, the source can send data frames to the

destination using the routing information found in the

received RESPONSE. An SR host does not have to know whether it is connected

to a regular, stand alone, token-ring domain which consists of only token-rings and SR bridges, or to an ATM ELAN.

This transparency is provided by means of the LAN Emula- tion. According to ref. [3], when a host in an SR TR domain wants to send a frame, it initiates a regular Route Determi- nation Protocol. The ROUTE_DISCOVERY frame broadcast by the Route Determination Protocol traverses all the rings in the local TR domain, including the one of the ATM- bridge. Like a regular SR bridge, the ATM-bridge has to

read all the ROUTE_DISCOVERY frames and broadcast them to all the rings to which it is connected through the

ATM backbone. To this end, the ATM-bridge uses the BUS of the LAN Emulation. It sends the ROUTE_DISCOVERY frame to the BUS over a Multicast Send VCC. The BUS fotwards the frame to all the LE clients associated with the

ELAN, namely to all the ATM-bridges2, over a Multicast Forward VCC. Then, the frame is broadcast to all the rings of every domain as a regular ROUTE_DISCOVERY frame. If the destination hosts resides in a remote domain, the RESPONSE frame is routed to the ATM-bridge of the destination host, then forwarded over the ATM backbone to the ATM-bridge of the source host, and finally forwarded to the

source host. This scheme is very inefficient if a permanent multicast

connection from the BUS to the LE clients is expensive, or

if the LE clients are located far from each other. In both cases, which are likely to prevail if the ATM backbone is a wide area network, it is necessary to minimize the use of the BUS. This article presents a scheme whereby intelligence at the ATM-bridges is used in order to minimize the number of ROUTE_DISCOVERY messages broadcast by the BUS.

’ A ROUTE_DISCOVERY frame can be sent using either ‘all-route broadcast’ or ‘single-route broadcast’ [41, [2]. In the latter, which applies when the bridges form a spanning tree, only one route is traversed.

’ Note than SR ELAN may contain ATM hosts connected directly to the ATM backbone. An ATM host can be considered as an ATM-bridge connected to an empty ring.

The main concepts of the proposed scheme are as follows.

When an ATM-bridge a receives a local ROUTE_

DISCOVERY frame for destination d, it uses cached

information and the Remote Search Protocol (RSP) described later, in order to determine whether d exists in the ELAN, and whether it is a local station (i.e. residing in the same TR domain, though not necessarily in the same token-ring of the source) or a remote station.

If a has a fresh information indicating that d is located on a remote domain, a acts as a proxy, and sends the source station a RESPONSE message on behalf of d without laying any burden on the ATM backbone. If a has an old cached information indicating that d

is located on a remote domain, a sends a unicast

ROUTE_DISCOVERY frame only to the ATM-bridge of this particular remote domain.

If a has no cached information regarding d, it invokes a

local instance of the Route Determination Protocol. This instance is executed over the rings of the local domain only. If d is not found in the local domain, a invokes

the RSP by broadcasting over the ATM BUS a ROUTE_DISCOVERY frame to every remote domain. However, further search instances for the same destination initiated by any station in the ELAn will not have to use the BUS, because all the ATM-bridges will know

that ATM-bridge a has fresh information regarding d.

3. The ATM-bridge

Consider an ELAN with N TR domains, where every

domain is connected to the ATM backbone by means of an ATM-bridge. Let 9I = {at, u2 ... uw} be the set of ATM-bridges and S = (s,, s2 ... sK} be the set of LAN stations connected to the entire ELAN. We shall say that Sj E Ui if station sj is located on the TR domain connected to the ATM by ATM-bridge ai. This TR domain is referred to as TR domain number i.

The proposed ATM-bridge employs both learning and

searching techniques. In order to function efficiently, it needs to learn the MAC addresses and locations of local

and remote stations participating in the ELAN. To this end, the ATM-bridge maintains a database, with location

information for active stations in 5. The state of station s, in the database of ATM-bridge Ui, ai[sj].state, represents the knowledge of ai about the location of Sj. This state has one of the following values:

l LOCAL-This indicates that s1 is powered-on and located on the local TR domain (Sj E Ui). Associated

with this value is a description of a route from ai to sj, through 0 or more SR bridges.

l WAS-LOCAL-This indicates that Sj was a local station, but was silent for some pre-specified time period, either because it had nothing to send or because it was powered-off.

1136 R. Cohen, E. Stein/Computer Communications 20 (1997) 1133-l 145

IN_BRIDGE(ak)-This indicates that Sj E ak, where k # i. Associated with this value is a description of a route from ak to Sj in the TR domain of ak. WAS_IN_BRIDGE(uk)-This indicates that s, was recently connected to ak. Resulting from the low prob-

ability of a LAN station to change its TR domain, this also indicates that with a high probability sj is either still connected to ok or is temporarily down and will be

reconnected to uk in the future. REFER_TO_BRIDGE(uk)-This indicates that a, does not know the location of sj. However, ai knows that si is

not a local station and that ak, where k f i, is supposed

to know where Sj is. This is because ak has recently broadcast using the BUS a search message for sj.

SEARCHING-This indicates that a i is in the middle of

the execution of a search for sj. NOT-EXIST-This indicates that sj does not exist in the entire ELAN. UNKNOWN-This indicates that ui has no information regarding the location of sJ.

Consider an instance of the Route Determination Proto- col, initiated by station s , in TR domain number 1 in Fig. 1. Let si be the destination station. When ATM-bridge aI

receives a copy of the ROUTE_DISCOVERY frame, the route description list is { r ,,b , ,Y>}. Consider now the follow-

ing possible values of a, [s,].state when u, receives the frame:

1.

2.

3.

4.

5.

If ur[sJ.state = LOCAL (e.g. si = s?), al ignores the ROUTE_DISCOVERY frame because it should not be involved in the routing between sI and si. When si receives the ROUTE_DISCOVERY frame, it sends s, a RESPONSE frame with a description of a route between them (e.g. {I,, b,, r2, b2, r3} ifs, =s2). If ul[sJ.state = WAS-LOCAL, al ignores the frame. If

si is already powered-on, it will respond as in the previous case. Otherwise, s 1 will receive no RESPONSE for

this route discovery instance and deduce that si does not exist in the entire ELAN.

If a l[si].state = NOT-EXIST, a 1 ignores the frame. The source sr will receive no RESPONSE frame and will deduce that s, does not exist in the entire ELAN. If ur[sJ.state = INBRIDGE( a I acts as a proxy for si and sends s , a RESPONSE frame with a description of the route from s, to si. The latter is a concatenation of the

route description list in the ROUTE_DISCOVERY frame received by a ,, and a description of the route

from ak to Si obtained by Si using the remote search protocol (RSP) described later. If al[sJ.state = UNKNOWN, u 1 has to search for si. It starts searching in its local TR domain, using an instance of the route discovery protocol. If the destination is not found, the search is extended to remote TR domains using the RSP.In order to search for si in the local TR domain, a I invokes an instance of the Route Determina- tion Protocol. The instance invoked by a, runs in parallel

to the one invoked by s , . For the instance invoked by a ,, a, is the source and si is still the destination. After the Route Determination Protocol ends, a, knows whether s i exists in the local domain or not. If it exists, a, sets

a ,[sJ.state - LOCAL and associates with this entry

the description of the route to si as found by the Route Determination Protocol. Then, as in case (1) a, has nothing else to do because routing from s, to si is per-

formed without the intervention of the ATM.If, however, s, is not found by a, in the local domain, a I invokes the RSP as described in Section 4. When this protocol ends,

ATM-bridge a, knows whether or not, and in what TR

domain, Si exists in the ELAN. If s, exists in some TR

domain, number j say, the output of the RSP is a descrip-

tion of the route from aj to Si. After receiving this

response, a 1 performs aI [sJ.state - IN_BRIDGE(u,). Then as in case (4), it acts as a proxy of si and sends s, an SR RESPONSE frame with a description of the entire route from s, to s,. If the output of the RSP is that s, does not exist in the ELAN, or that si is disconnected at some remote TR domain, number j say, then a, per-

forms ul[sJ.state - NOT-EXIST or ul[sJ.state - WAS_IN_BRIDGE(aj) respectively. As in case (3) ai

has nothing else to do.Note that when an SR source invokes the route discovery protocol in order to locate a destination, it uses a timer that determines the period of

time during which a response message should be received before the destination is considered inaccessible [2,4]. In the proposed scheme, this time period should be sufficiently large to allow the ATM-bridge of the source to invoke another instance of the route discovery protocol and then, if needed, to invoke an instance of the RSP. In contrast, the time period during which the ATM- bridge needs to wait for a response from the destination after initiating the second instance of the Route Determi-

nation Protocol, is considerably smaller. This is because the ATM-bridge does not have to wait for another local or remote search.

If a l[si].state = WAS_IN_BRIDGE(ak) or u,[s,].state = REFER_TO_BRIDGE(uk), a, initiates the RSP. As explained in Section 4 there are differences between the execution of the RSP in each of these two cases. How- ever, when the RSP ends, a I continues as in case (5). If a,[si].state = SEARCHING, meaning that a, has already invoked an instance of the RSP for s,, no further

action is taken until the RSP ends. When the RSP ends, a, continues as in case (5).

The remote search protocol

As explained in the previous section, the RSP is invoked by an ATM-bridge when it receives a ROUTE_ DISCOVERY frame for a non-local station, in order to determine whether and how to respond. Two, broadcast- based, possible approaches for the RSP are as follows.

R. Cohen, E. Stein/Computer Communications 20 (1997) 1133-I 145 1137

l An RSP_SEARCH message is broadcast using the BUS

to all the ATM-bridges participating in the ELAN. Upon

receiving an RSP_SEARCH, an ATM-bridge invokes a

local instance of the Route Determination Protocol. If

the searched station is found, an RSP_RESPONSE is sent back to the searching ATM-bridge. As explained in Section 1, this approach is not suitable for a wide area

ATM backbone, where the traffic broadcast by the BUS must be minimized. In addition, such an approach would

overload the TR domains with many ROUTE_ DISCOVERY frames originated by sources in remote TR domains.

l Every ATM-bridge periodically broadcasts to the other

ATM-bridges a list of its local stations with a description of a route to each of them. This approach has the follow-

ing drawbacks. Firstly, the overhead for BUS traffic has to be paid even if no data frame is exchanged by remote

stations. Secondly, the list sent by every ATM-bridge will not contain passive (quite) stations, but only those from which a message was recently received on the local

domain. Thirdly, if the lists are exchanged frequently, the overhead in terms of BUS traffic will be significant, whereas if the lists are not exchanged frequently, the databases kept by the ATM-bridges might be obsolete.

The RSP proposed in this article is an efficient version of

the first approach, that uses learning ATM-bridges in order to minimize the traffic broadcast by the BUS during the

RSP. To this end, the ATM-bridges accumulate up-to-date information regarding the location of stations even if an

RSP instance is invoked by another ATM-bridge. The most important and useful observation is as follows. Sup- pose that ATM-bridge Ui invokes the RSP in order to resolve the MAC address of s,. Suppose also that during the execution of the RSP, a, uses the BUS in order to broadcast an RSP_SEARCH for Sj to all the ATM-bridges. Consider now an ATM-bridge ak, where Sj @ ak. ATM-bridge ak does not respond to ai because Sj does not reside in its domain. How-

ever, ak remembers that Ui has invoked an RSP for Sj. If within some pre-determined time ak invokes the RSP for Sj,

it does not use the BUS, but sends a unicast RSP_SEARCH

message directly to ai. AS proven later, this strategy signifi- cantly reduces the average number of RSP_SEARCH messages needed to be sent over the ATM.

ATM-bridge a, initiates an instance of the RSP in order to find a route to s, only if a,[s,].state is (1) WAS-IN_

BRIDGE(a k), or (2) REFER_TO_BRIDGE(uk), or (3) UNKNOWN. Upon initiating the RSP, ai changes ai[sj].- state to SEARCHING. In cases (1) and (2), a single copy of RSP_SEARCH is sent by Ui to ATM-bridge ak. In case (3),

an RSP_SEARCH is broadcast by ui to every ATM-bridge. As will be shown, the response of an ATM-bridge receiving a broadcast RSP_SEARCH message may be different from the response of an ATM-bridge receiving a unicast ATM- bridge. Thus, in what follows a broadcast RSP_SEARCH message will be referred to as B_RSP_SEARCH, whereas a

unicast RSP_SEARCH message will be referred to as

U_RSP_SEARCH. We will continue using ‘RSP_

SEARCH’ only in those cases where the exact type (unicast

or broadcast) of the message is not important.

Consider case (1) first. As proven later, ai[sj].state = WAS_IN_BRIDGE(uk) implies that ak[sj].state is either LOCAL or WAS-LOCAL. This invariance is achieved

by means of a timer dictating a transition from WAS_ IN_BRIDGE(Uk) t0 UNKNOWN before ak[s,].state

changes to UNKNOWN. If ak[sJ.state = LOCAL, ak responds by informing ui that this is the case. If ak[sj].state = WAS-LOCAL, a local instance of the SR Route Determination Protocol is invoked by ak. If Sj is

found, ak[sj].state changes to LOCAL3. After the local search ends, ak responds by sending a, the value of ak[sj].-

state (LOCAL or WAS-LOCAL). When ai receives the response from ak, it continues as follows. If ak[sj].state =

LOCAL then sj E ak and the RSP terminates successfully. Therefore, ai[sj].state changes from SEARCHING to IN_BRIDGE(uk). Since we assume that LAN stations rarely move among TR domains, then when ak[sj].state =

WAS-LOCAL, a, deduces that sj is currently disconnected

and that it will be re-connected in the future to +. Thus, ai[sj].state changes from SEARCHING to WAS-IN_ BRIDGE(uk), and the RSP ends unsuccessfully. In order to avoid unnecessary RSP instances for a disconnected LAN station, when ui receives an RSP_RESPONSE indicating that the state of Sj in ak is WAS-LOCAL, it avoids for a

pre-defined time (T-3) further RSP instances for Sj. During

this time, though ai[sj].state is WAS_IN_BRIDGE(ak), ak disregards all ROUTE_DISCOVERY frames it receives for

sj on its local domain. Next, consider case (2). Since ai[sj].state = REFER_

TO_BRIDGE(u& ATM-bridge ak has ‘recently’ broadcast a B_RSP_SEARCH in order to locate Sj. As explained later, the exact meaning of ‘recently’ depends on a pre-defined

timer value (7’_6) which dictates upon expiration a transition from REFER_TO_BRIDGE(uk) to UNKNOWN. If ak

receives the RSP_SEARCH of ui after its own RSP instance for Sj has terminated (ak[sj].state f SEARCHING), it sends

the value of ak[sj].state to Ui. The possible values are:

ak[sj].state = WAS_IN_BRIDGE(uJ. In such a case Ui

continues the RSP by sending an U_RSP_SEARCH to al. As for case (1) above, ui will be the last ATM-bridge to receive an RSP_SEARCH from ai during this RSP instance. ak[sj].&ite = UNKNOWN or REFER-TO_ BRIDGE(uJ. In such a case ai continues by broadcasting a B_RSP_SEARCH to all the ATM-bridges. If no

3 If the local search fails, aJs,].state does not change to UNKNOWN but remains WAS-LOCAL. This is because we assume that with high probability a disconnected station will be connected to the same TR domain it was previously connected. A transition from WAS-LOCAL into UNKNOWN is dictated only if the station does not respond within some pre-defined time (T,) after WAS-LOCAL was entered.

1138 R. Cohen, E. SreinKompurer Communications 20 (1997) 1133-1145

response is received during a time-out period, a, changes ai[sj].state to NOT-EXIST. If a response is received, from al say, it will indicate that s, is either LOCAL or

WAS-LOCAL. Hence, a, continues as specified in (1) for each of these cases.

a,Js,].state = IN_BRIDGE(uJ. In such a case the RSP ends successfully and a, changes a,[sj].state to IN_ BRIDGE(a,). uJs,].state = NOT-EXIST. In such a case the RSP ends unsuccessfully, and Ui changes u,[s,].state to NOT_ EXIST.

aiJs,].state = LOCAL. In such a case the RSP ends successfully and ai changes a,[sj].state to IN_

BRIDGE(u& ak[sj].state = WAS-LOCAL. In such a case the RSP ends unsuccessfully, and a, changes ai[sj].state to

WAS_IN_BRIDGE(utJ. As in case (l), ui suspends for a pre-defined time (T3) further RSP executions for sj.In a first glance it seems that cases (2.5) and (2.6) should be excluded: uk[s,].state = LOCAL or WAS-LOCAL means that s, is now or was a short time ago connected

to ak, whereas a,[s,].state = REFER_TO_BRIDGE(uk) means that ui received from ak and RSP_SEARCH for s,. However, this is a possible combination if sj has recently

joined TR domain number j.

As already mentioned, many of the transitions in the finite

state machine associated with the state of every station at each ATM-bridge are driven by a timer. Thus, depending on the initial value assigned to the timer in every state, some of the cases listed above might be excluded.

Recall that cases (l)-(6) are applicable only if ak receives the RSP_SEARCH from uj while Uk[sj].State # SEARCH- ING. If ak receives the RSP_SEARCH while Uk[sj].State =

SEARCHING, it responds with UNKNOWN. Upon receiving this response, Ui continues as in (2).

Next, consider case (3), where ai initiates an RSP for Sj

while a,[sj].state = UNKNOWN. In this case ai uses the BUS in order to broadcast a B_RSP_SEARCH to all the

ATM-bridges, and continues as in (2). The following two events cause state transitions though

they are not concerned with the RSP:

l Regardless of ai[sj].state, if sj is the source of a frame received by ai on the local TR domain, which indicates that Sj is a local station, aj sets ai[sj].state to LOCAL.

l Regardless of ai[sj].state, if s, is the source of a frame received by ui over the ATM from ak, which indicates that Sj is in the TR domain of ak, U, sets ai[sj].State to IN_BRIDGE(uk).Fig. 2 shows the state transitions of ui[s,].state at ATM-bridge ai. Fig. 3 shows the actions performed by a, upon receiving an U_RSP_SEARCH message. The actions performed by ai upon receiving a B_RSP_SEARCH message are similar with one exception: a B_RSP_RESPONSE is sent back only if the state of the searched host is either LOCAL or WAS-LOCAL.

The performance of the RSP as we define is the average number of RSP_SEARCH messages needed to be sent per an RSP instance, while counting a unicast U_RSP_

SEARCH as one message and a broadcast B_RSP_ SEARCH as N messages. This performance depends on

the timer values T, ... Ts. Small values imply that ATM- bridges will quickly forget what they have learned about the location of LAN stations and, therefore, the performance of the RSP will be hurt. On the other end, if timer values are

too long, incorrect information might be maintained in the databases of the ATM-bridges. In what follows we present

the considerations for determining proper timer values, and explain the dependencies among the various values. This

discussion is summarized in Fig. 4. Note that 7 is an upper

bound on the time needed to exchange a message over the ATM backbone. Namely, to send an U_RSP_SEARCH or to broadcast using the BUS a B_RSP_SEARCH and to get back an RSP_RESPONSE.

(Tj) If ai[s,].state is LOCAL and ai does not receive on the local TR domain any frame from s, during at most T1 seconds, then uj[sj].state changes to WAS-LOCAL. AS long as a,[sj].state is LOCAL, ui discards all ROUTE_ DISCOVERY frames received on the local TR domain for

Sj, and accepts data frames received from remote TR domains and destined for sj. Thus, the value of T, should

be equal to the ‘age value’ of a route in a SR station database [2], which is a couple of seconds.

( T2) When a I receives a data frame from ak whose source station is s,, it sets Ui[sj].state to IN_BRIDGE(ak) and ui[sj].- timer to TZ. Before forwarding this frame to a,, ak sets ak[s,].state to LOCAL and ak[sj].timer to Ti. Thus in order to maintain the invariant that ai[sJ.state = IN_ BHDGE(uk)

- a,Js,].state = LOCAL, T2 = T, - T must hold. (7-3) If an RSP instance for sj terminates unsuccessfully

because of an RSP_RESPONSE with (WAS_LOCAL,

timer} received from uk, Ui deduces that Sj is currently disconnected and that it will be reconnected in the future to ak.

Therefore, ai[sj].state changes to WAS_IN_BRIDGE(uk) and a,[sj].timer to ak[Sj].timer - 7. During the next Tj seconds a, will not initiate RSP instances for s, and will ignore any ROUTE_DISCOVERY frame for Sj. Thus, a reasonable value of T3 would be a couple of minutes.

(T4) If aJs,].state is NOT-EXIST, a, considers sj as a disconnected station and does not initiate RSP instances for this station for at most T4 seconds. A reasonable value

of TJ is, therefore, several minutes. (Ts) When u,[s,].state is set to WAS-LOCAL, ui[sj].timer

is set to a value which is bounded by Tg. As long as

Ui[sj].State = WAS-LOCAL, ui assumes that Sj will be re-connected as a local station. If Ui does not receive any frame from s, on the local TR domain before ui[sj].timer expires it changes a,[sj].state to UNKNOWN. Therefore, the value of T5 dictates the locality of LAN stations within a TR domain. Since we assume that the location of a LAN station rarely changes, the value of T5 can be in the order of several hours.

R. Cohen, E. Stein/Computer Communications 20 (1997) 1133-1145 1139

an RSP_SEARCH for sj is received and the local search fails.

an RSP_SEARCH

an RSP_SEARCH

an RSP_SEARCH a ROUTE_DISCOVERY hmc for a nmklocal

a ROU1F_DISCOVERY fmmc for a non-local

an RSP_RESPONSE with (NOTJXDT, timer) is received from u,/ a,ls,l.limer + timer

an RSP_RESPONSE with (u)CAL timer) is received from aJ u~sjl.rimer+timer

for s, is received from a, or

an RSP_RESPONSE with ( fNBRIDGE(o,~. l&r) icr received from u, / a&l. timer+ timer

(1) In every state: if a frame whose source station is sj is received on the local domain, aJsJ.sture changes to LOCAL and ajs,J.timer is set to T,.

(2) In every state: if a frame whose source station is sj is received from uk , ui[siJ.stute changes to IN_BRIDGE(ab and ai[sil.tim::r is set to T2..

(3) In REFER_TO_BRlDGE: if an RSP_SEARCH from a remote ATM-bridge or a ROUTE_DISCOVERY frame on the local domain for sj is received more than T, seconds after the last local search for sj was performed, a new local search for sj is invoked. If s, is found, a transition is made to WCAL and ads,_l.timer is set to T,. If sj is not found, the state does not change.

Fig. 2. ATM-bridge algorithm, part (a): state transitions (for a,[s,]).

1140 R. Cohen, E. Stein/Computer Communications 20 (1997) 1133-l 145

ai(sjJ.st~le before an RSPSEARCH

is received from a[

LOCAL

WAS-LOCAL

UNKNOWN

REFER_ TO_BRID GE( ak)

NOT-EXIST

v SEARCHING

Action

An RSPRESPONSE with {LOCAL, ai[s,].limer-7} is sent. A local search for s, is performed. If s, is found (thus, ai[s,].state is changed to LOCAL and ai[s,].timet is set to T;), an RSP-RESPO~~~E with {LOCAL, ai[al].limer-T} is sent. If s, is not found (thus, ai[sj].atate remains WAS-LOCAL), an RSPRESPONSE with {WAS-LOCAL, ai[sl].timer-7)

is sent. A local search for s, is performed. Ifs, is found (thus, aifs,j.stale is changed to LOCAL and a,[i3].limer is set to T;), an RSPktESPO‘N%E with - {LOCAL, ai[sj].timer-7) is sent. If s3 is not found (thus, ai[sJ].slate is changed to REFER_TO_BRZDGE(al) and a;ls,l.iimer is set to Ts). an RSPkESPONSE with UNKNObVN~& sent. _ I*

-I

If more than T4 seconds have Dassed since the mevious local search for 8.. a local search for sj is performed. If s, is found (thus, ai(sJ].state is chdged to LOCAL and ai[sj].limet is set to Tl), an RSP-RESPONSE with {LOCAL, a;[sI].timer-7) is sent. If s, is not found, or the previous local search was less than T4 seconds ago (thus, a,[sJ.state is changed to REFER_TO_BRIDGE(ai) and ai[s,l.timer is set to Ts), an RSPRESPONSE with {REFER_TO_BRIDGE(ak)} is sent. An RSPRESPONSE with {NOT-EXIST, ai[sj].timer-7) is sent. An RSPRESPONSE with {IN-BRIDGE(Q), ai[si].timer-s} is sent An RSPRESPONSE with { WAS_IN_BRIDGE(ak), ai[sj].limer-7) is sent. An RSPRESPONSE with { UNKNO WNj is sent.

Fig. 3. ATM-bridge algorithm, part (b): The actions performed by a, upon receiving an U_RSP_SEARCH for s,. The actions performed upon receiving a

B_RSP_SEARCH over the BUS are similar, except that an RSP_RESPONSE is sent back only with LOCAL or WAS-LOCAL.

(2’6) When ai[sj].state is set to REFER_TO_BRIDGE(ak), ai[sJ.timer is set to T6. If ai does not receive an R.SP_ SEARCH for Sj before ai[sJ.timer expires, ai[sJ.state changes to UNKNOWN. Thus, T6 indicates the time period

during which an ATM-bridge needs to remember the identity of the last sender of an RSP_SEARCH for sj. Its

value can be as long as one desires (even several hours),

because it only indicates the first ATM-bridge to which an RSP_SEARCH should be sent during an RSP instance, and it does not require a global consistency among several

ATM-bridges. (TT) If ai[sj].state is WAS_IN_BRIDGE(U~) and ai does

not succeed to locate Sj within at most T7 seconds, ui[sJ.-

state changes to UNKNOWN. By the same considerations

stated above regarding the value of T2, the value of T7 should be T5 - 7, in order to maintain the invariant

ai[sj].state = WAS_IN_BRIDGE(U~) + ak[s,].state = LOCAL or WAS-LOCAL where 7 is some constant upper

Timer 1 Value

Fig. 4. Recommended timer values.

bound on the delivery time of an RSP_RESPONSE message from ak to a,.

(Tg) This timer is employed when a B_RSP_SEARCH is broadcast over the BUS to the ATM-bridges. It determines

the period of time the sending ATM-bridge waits for a response before considering the searched station as NOT_

EXIST. Hence T8 = T, + 7 should hold.

Recall that an ATM-bridge a, enters REFER-TO_ BRIDGE state for LAN station Sj after making sure that s, is not a local station. However, since the time interval T6 during which ai stays in this state can be arbitrary long, ai must invoke occasionally a local search for s, (every T4 seconds). To understand the need for the occasional local searches, consider the following scenario. ATM-bridge ak initiates an RSP instance for Sj and broadcast a B_RSP_ SEARCH message to all the ATM-bridges in the ELAN.

However, no RSP_RESPONSE is received and ak changes ak[sj].state to NOT-EXIST. The state of Sj in the database of every other ATM-bridge is REFER_TO_BRIDGE(uk).

After T4 seconds (a couple of minutes) ak[sj].state changes to UNKNOWN, while the state of Sj in the other ATM- bridges remains REFER_TO_BRIDGE(uk) for a couple of hours ( T6). The reason for having T4 << T6 is to let the ATM- bridge find stations a short time after the latter are connected to their TR domain, while, in contrast, keeping valuable information as long as possible. Suppose that s, is reconnected to the TR domain of ui. If a local search is not performed by ai while ai[sj].state is REFER-TO_ BRIDGE(uk), ATM-bridges will fail to locate sJ a long time after sj becomes connected.

R. Cohen, E. Stein/Computer Communications 20 (1997) 1133-I 145 1141

In order to address this problem, another timer called

ai[sj].tmp is used while ai[sJ.state is REFER-TO_

BRIDGE(ak). This timer is set to Td. If ai receives an RSP_SEARCH for Sj from a remote ATM-bridge or a

ROUTE_DISCOVERY frame for sj on its local domain, while Ui[sj].State is REFER_TO_BRIDGE(ak) and aJs,].tmp has expired, it performs a local search before responding to these messages. If the local search fails, ai[s,].tmp is set again to T4 and ai[sj].state remains REFER_

TO_BRIDGE(uk). If, however, sj is found, a transition is

made into LOCAL.

5. Correctness proof and amortized cost analysis

The properties of the RSP are proven in this section. We start by proving two global consistencies. Then, we prove that if a LAN station is connected for a given time, it will be found by each RSP instance. Finally we show that the aver-

age number of connections needed for an RSP instance converges to one. Throughout this section we shall assume

the following.

5.1. Assumption 1

If LAN station sj disconnects from its TR domain, it takes at least T, + T5 seconds until it may be connected to a new

TR domain (there is no assumption regarding the time period between disconnection and reconnection to the

same TR domain).

5.2. Assumption 2

7 is an upper bound on the time needed to exchange a

message over the ATM backbone. Namely, to send an U_RSP_SEARCH or to broadcast using the BUS a B_RSP_ SEARCH message and to get back an RSP_RESPONSE

message.

5.3. Assumption 3

T2 = T, -7, T7 = T5 - r, T8 = T, + 7 and T6 =

max (T, - T5, T7 - Ts}. The proofs for Lemmas l-5 and to Invariants l-2 can be found in Appendix A.

Lemma 1. If ai[sJ.state = LOCAL, the only state transition that can occur is to WAS-LOCAL.

Lemma 2. If ai[sj].state = WAS-LOCAL, the only state transitions that can occur are to LOCAL or UNKNOWN.

Invariant 1. If there exists an ATM-bridge ai for which

uJs,].state = IN_BRIDGE(uk) holds, then ak[sj].state = LOCAL.

Invariant 2. If there exists an ATM-bridge ai for which Ui[sj].State = WAS_IN_BRIDGE(uJ holds, then ak[sj].state = LOCAL or WAS-LOCAL.

Lemma 3. If ai[sj].state is LOCAL or WAS-LOCAL, then (a) there is no ak # a, for which ak[s,].state is also

LOCAL or WAS-LOCAL; and (b) station sI is either connected to the TR domain of ui or disconnected.

In the following we shall use Tc to denote the upper

bound on the time of an RSP execution. r* is equal to the time needed in order to send 2 messages, both unicast messages or one unicast and the other broadcast, over the ATM backbone plus the time needed in order to execute the source routing Route Discovery protocol twice.

Lemma 4. If sj is connected for at least 2T4 + 2r* sec-

onds, there is no ATM-bridge ai for which ai[sj].state is NOT-EXIST.

Lemma 5. If ui invokes an RSP instance for sj while sj is connected to some TR domain, the output of this instance

will not be WAS_IN_BRIDGE(ak). Theorem 1. A LAN station connected for at least 2T4 +

2r” seconds will be discovered by the RSP.

Proof. ?From Fig 2 follows that when the RSP instance of ai terminates, ai[sj].state is NOT-EXIST, or WAS-IN_ BRIDGE(uk), or IN_BRIDGE(uk). By lemmas 4 and 5 we

conclude that NOT-EXIST and WAS_IN_BRIDGE(uk) are not possible. Therefore, when the RSP instance of a, termi-

nates ai[sj].state = IN_BRIDGE(uk). By Invariant I, at that time a,[sj].state = LOCAL, and by Lemma 3 sj is indeed

connected to ak. RSP executions for different LAN stations are indepen-

dent. Therefore, in order to analyze the number of RSP_ SEARCH messages needed during the execution of each instance, we can consider an arbitrary destination Sj* The number of RSP_SEARCH messages needed during an RSP instance depends on the state of sj in the databases of the searching ATM-bridge and the other ATM-bridges. For

example, if the state of sj in all the databases is

UNKNOWN, one B_RSP_SEARCH message is sent. In what follows we find an upper bound on the average number of RSP_SEARCH messages sent when the RSP is invoked

in order to locate a remote station during T7 seconds, the time during which an ATM-bridge ‘remembers’ the location of a station. Recall that for the sake of this analysis we count

a unicast U_RSP_SEARCH as one message and a broadcast B_RSP_SEARCH as N messages.

Theorem 2. (a) The aggregate cost of a RSP instances initiated during a time interval of T, seconds by /3 ATM- bridges, for a station connected for at least 2T, + 2F seconds is 5 N + /3 + cr RSP_SEARCH messages. Thus, the

amortized (worst case average) cost of an instance is 1 + (N

+ /3)/o, and the asymptotic amortized cost is 1. (b) The aggregate number of RSP_SEARCH messages sent during a RSP instances initiated during a time interval of TJ seconds

by fl ATM-bridges for a non-existing station which is dis-

connected for at least TI + Ts seconds, during a time interval of T4 seconds, is 5 N + p - 1. Thus, the amortized (worst case average) cost of an instance is (N + /3 - 1)/a! RSP_SEARCH messages, and the asymptotic amortized cost is 0.

Proof. In the following we shall assume that at most one RSP instance is executed at any time for every LAN

1142 R. Cohen. E. Stein/Computer Communicaiions 20 (1997) 1133- 1145

destination. Thus, an ATM-bridge does not receive an RSP_ the aggregate number of RSP_SEARCH messages sent for

SEARCH message in SEARCHING state. s, during [t ,, t I + T4] by p ATM-bridges is N + P - 1. (a) Suppose the searched station s, is connected to ATM-

bridge ff k (for at least 2Td + 2r* seconds). By Lemma 4, no ATM-bridge is in NOT-EXIST state at that time. By Invar-

iants 1 and 2 and by Lemma 3 follows that the state of s, is

LOCAL or WAS-LOCAL only in the database of ak and

that no ATM-bridge is in IN_BRIDGE(ai) or WAS_

IN-BRIDGE@) for any a, f &.

At time tl + T4, the timers of all the ATM-bridges in NOT-EXIST state will expire, and the UNKNOWN state

is entered. The next RSP instance for s, will require a broad-

cast of a B_ARP_SEARCH message, and the next /3 - 1

instances will require one message each. Thus, the above analysis holds for a time period of TJ seconds starting at any

RSP instance for s,.

Let a = {a,,az,u3, . . . a,) be the sequence of ATM- bridges that initiated an RSP instance for s,. Each ATM- bridge in 2 appears once for each RSP instance it initiated. Thus, fl has a-elements from /3 different types. We first count the number of RSP_SEARCH messages sent in the /3 RSP instances initiated in the first time by the /3 ATM-

bridges in a. An ATM-bridge that receives a B_RSP_

SEARCH message for ak changes its state to REFER_

TO_BRIDGE(uk), and by Theorem 1 each searching ATM-bridge changes its state to IN_BRIDGE(uk) when its RSP instance terminates. In each of these p RSP instances, an RSP_SEARCH message is sent to an ATM-

bridge that has not received an RSP_SEARCH message yet, or to an ATM-bridge that has already received such a message, or to an ATM-bridge that had already initiated its own search for sj. During each RSP instance at most two RSP_SEARCH messages can be sent to ATM-bridges that have already received an RSP_SEARCH message for Sj: the first to an ATM-bridge in WAS-IN_ BRIDGE state, and the

second to the ATM-bridge were s, is connected (uk). There- fore, the maximum number of messages sent by all the considered fl instances is N + 20.

6. Simulation results

This section presents simulation results that illuminate

the advantage of the proposed scheme over the direct one. The simulated network consists of 100 ELAN segments

connected to an ATM backbone by means of 100 ATM-

bridges. We have concentrated upon a single destination station s,, and counted the number of RSP_SEARCH mes-

sages sent by each instance as a function of the timer value and the RSP execution rate. For all the simulations of the proposed scheme Th is either equal to TX or set to zero. By setting Tb to 0 we eliminate the REFER-TO-BRIDGE state and can therefore check the contribution of this state to the

RSP performance. The rate of the RSP executions for sI is a Poisson process with an average of X instances per time interval of T5 seconds.

The remaining a-/3 instances will use at most one RSP_SEARCH message per instance, since during T7 seconds they still remember the location of sj. Therefore, the total number of RSP_SEARCH messages sent by the cy instances is not larger than N + 20 + 01 - @ = cy + N

+ P, and the average per instance is not larger than 1 + (N + 26)/o, which converges to 1 for a large (Y.

The simulation results of the proposed scheme are pre-

sented in Fig. 5. Four cases are considered: 50 searching bridges, 30 searching bridges, 10 searching bridges and one

searching bridge. These cases are depicted in graphs (a)-(d) respectively. Each graph shows the number of ARP_ SEARCH messages sent by every RSP instance as a function of time for T6 = T5 (the black line) and for T6 = 0 (the gray line). The left-hand side of the ‘time’ axis represents the first search, where no bridge knows anything about Sj, whereas the right-hand side represents the last search.

(b) Let t be the time T, + T5 seconds after s, is disconnected. At this time the state of Sj at every ATM-bridge is

either UNKNOWN, or REFER-TO-BRIDGE. Let t, be the time the first RSP instance for sj is initiated after t. We will

show that the aggregate number of RSP_SEARCH messages sent by /3 ATM-bridges during [t ,, t , + T4] in indeed not larger than N + /3 - 1.

The ATM-bridge, a, say, that initiates the RSP instance at tl uses the BUS in order to broadcast an RSP_SEARCH message to all the other ATM-bridges, and terminates in NOT_ EXIST state. After its instance terminates, the state of sj in each other ATM-bridge is REFER-TO_ BRIDGE(u,).

ATM-bridge Ui sets its timer to T4 and therefore does not initiate more RSP instances for Sj during [tr, t 1 + 7’41. Each ATM-bridge that initiates an RSP instance for Sj sends its first RSP_SEARCH message to a,, terminates in NOT_ EXIST and sets its timer to the value of ai[sj].timer. Thus,

In graph (a), 50 ATM-bridges initiated 52 RSP instances for sj. The total number of search messages sent with

REFER-TO-BRIDGE state was 190 (an average of 3.65 messages per instance) and the total number of messages sent without the REFER-TO-BRIDGE state was 376 (an

average of 7.23 messages per instance). In graph (b), 30 ATM-bridges initiated 50 RSP instances for Sj. The total

number of search messages sent with REFER-TO_ BRIDGE state was 195 (an average of 3.9 messages per instance) and the total number of messages sent without the REFER-TO-BRIDGE state was 276 (an average of 5.52 messages per instance). In graph (c), 10 ATM-bridges initiated 50 RSP instances for Sj. The total number of search messages sent with REFER_TO_BRIDGE state was 148 (an average of 2.96 messages per instance) and the total number of messages sent without the REFER-TO-BRIDGE state was 211 (4.22 messages per instance). In graph (d), only one ATM-bridge initiated 52 RSP instances for $1. The total

R. Cohen, E. Stein/Computer Communications 20 (1997) 1133-1145 1143

r

Time

0

Time

(c) IO.sahing ATM&i&es

Time

(d) 1 sxching ATM-Wge

Fig. 5. Simulation results for the RSP.

number of search messages was 35, with and without the

REFER-TO-BRIDGE state (an average of 0.67 messages per instance).

For all the cases considered before, the average number of search messages sent by the ATM-bridges is indeed smaller than the upper bound proved in Theorem 2. Consider for example case (b), where N = 100, 0 = 30 and CY = 50. For this case, the average number of sent messages (3.0) is smaller than 5 1 + (100 + 2*30)/50. It is also evident

from the simulations that when the number of searching ATM-bridges (/3) is reduced, the advantage of the REFER_

TO-BRIDGE sate decreases. The reason is that a smaller /3 implies that each searching ATM-bridge initiates more instances, and therefore has an up-to-date local information

regarding the whereabout of the destination s,. Finally, note that in case (d) the average number of RSP_SEARCH messages is smaller than 1. The reason is that all the instances

are performed by a single ATM-bridge, and many of them are initiated while this bridge is in IN-BRIDGE state, so no RSP_SEARCH message is actually sent.

We have also performed simulations in order to compare the previous results with the direct approach that uses the BUS to broadcast a search message whenever such a message is received by an ATM bridge. In the latter case, the average number of search messages was always very close to N (IOO), irrespective of the value of /3. This number, which is 20-25 times larger than the number of messages

sent by the proposed scheme, decreases only if the rate of the search instances substantially increases.

7. Conclusions

This article presented a scheme which uses intelligence at

the ATM-bridges in order to minimize the number of messages needed to be transmitted over the ATM backbone when a remote station is searched in a token-ring emulated LAN. The main idea in the scheme is that the ATM-bridge

of each domain functions as a proxy for destination of remote segments. An indispensable component to the proposed scheme is a distributed Remote Search Protocol

(RSP). This protocol allows an ATM-bridge to lcoate a remote destination while avoiding the need to use the BUS of the ELAN too often. If the BUS is used in order

to locate a station by some ATM-bridge, the other ATM-

bridges remember the identity of the searching ATM-bridge for later use. Then, if another ATM-bridge needs to locate the same station, it contacts the first ATM-bridge using a unicast VCC instead of broadcasting another search message. If the first search has conducted recently, no more search messages need to be sent over the ATM backbone. Otherwise, another unicast message has to be sent to the ATM-bridge in the domain of the destination. In both cases the resulting load over the ATM backbone is

1144 R. Cohen, E. Stein/Computer Communications 20 (1997) 1133-1145

considerably smaller than the case where every ROUTE_ DISCOVERY frame is automatically forwarded to the BUS and broadcast to all the ATM-bridges.

Appendix A

Proof of Lemma 1 By Fig. 2 only two events may cause state transitions

when ai[sj].state is LOCAL: (1) the expiration of ai[sj].timer changes the state to WAS-LOCAL; (2) the reception of a data frame from ak whose source is Sj changes the state to IN_BRIDGE(ak). In the following we show that the second event is impossible. Let f2 be the time when ak sends the

data frame, and t3 be the time when ai receives this frame. Let tl be the last time before 23 when ai[sj].state is set to

LOCAL or ai[sj].timer is set to Tj while ai[sj].state is LOCAL (because of event (1) in Fig. 2). By Assumption

1 t2 5 tl + T1 + T5. From the definition of tl follows that tj < t j + Tj. This leads to t3 < t2 which is impossible.

Proof of Lemma 2 By Fig. 2 only four events may cause state transitions

when ai[sj].state is WAS-LOCAL: (1) the expiration of ai[sj].timer changes the state to UNKNOWN; (2) a success- ful local search changes the state to LOCAL; (3) the reception of a frame whose source address is sj on the local

domain changes the state to LOCAL; (4) the reception of a frame whose source is Sj from ak changes the state to IN_BRIDGE(uk). In the following we show that the fourth

case is impossible. Let t2 be the time when ak sends the data frame, and t3 the time when ai receives it. Let t, be the last

time before t3 when ai[sj].state is set to WAS-LOCAL. By Assumption 1 t2 2 11 + Tg. Since at rI ai[sj.timer - TS and ak[sj].state -WAS-LOCAL, t, < tl + T5 holds. Thus, T3 < t2, in contradiction to the definition of t2 and t3.

Proof of Invariant 1 The value of ai[sj].state may change to IN_BRIDGE(uk)

in one of the following ways: (1) after receiving from uk an RSP_RESPONSE with {LOCAL, timer}; (2) after receiving from ak a data frame whose source is Sj; (3) after receiving

from another ATM-bridge aI an RSP_RESPONSE with

(IN_BRIDGE(uk), timer]. In case (l), when ui receives from ak an RSP_

RESPONSE with (LOCAL, timer], it sets ai[sj].timer to

ak[sj].timer -7. Following Assumption 2, at this time

&[Sj].timer 2 ui[sj].timer. By Lemma 1, uk[.~j].state

changes from LOCAL only when ak[sj].timer expires.

Since ak[sj].timer will not expire before ai[sj].timer, the invariant holds. In case (2) when ak sends the data frame it sets ak[sj].state to LOCAL and ak[sj].timer to Tl. When Ui

receives this data frame, it sets ai[sj].timer to T2. Since T2 = TI - 7 (Assumption 3), at this time ai[sj].timer 5 ak[sj].-

timer and as in case (1) the invariant holds. Case (3) is proven by induction assuming that the invariant holds for ai and proving it for ai. The basis of the induction holds by cases (1) and (2). When ai receives the RSP_RESPONSE with {IN_BRIDGE(uk), timer) from al, it changes Ui[Sj].-

state to IN_BRIDGE(ak) and sets the value of ui[sj].timer to uj[sj].timer - r. At this time, ai[sj].timer 5 uj[sj].timer 5 ak[sj].timer. The first inequality holds by Assumption 2, and the second one by the induction assumption. Resulting from

the induction assumption, at this time ak[Sj].state is LOCAL,

and by Lemma 1 it may leave this state only after its timer expires. Thus, the invariant holds.

Proof of Invariant 2 The value of uJs,].state may change to WAS-IN_

BRIDGE(uk) in one of the following ways: (1) after receiving an RSPRESPONSE with (WAS-LOCAL, timer] from ak; (2) when ai[sj].state = IN_BRIDGE(ak) and a i[sj].timer expires.

In case (1) when ai receives the RSP_RESPONSE with {WAS-LOCAL, timer] from ak, the value of timer is the

value of ak[sj].timer at the time when the message is sent minus 7. Since Ui sets ui[sj].timer to timer, then by Assump-

tion 2 at this time ak[sj].timer 2 ai[sj].timer. Thus, ak[sj].-

timer will not expire before ai[sj].timer. Since, by Lemma 2, as long as ak[sj].timer does not expire, ak[sj].state must be

either LOCAL or WAS-LOCAL, the invariant holds. In case (2), note that by Invariant 1 when ai[sj].state changes from IN_BRIDGE(uk) to WAS_IN_BRIDGE(uk), at time t, say, ak[sj].state is LOCAL. At this time ai[sj].timer is set to T7. By the ATM-bridge algorithm (Figs 2 and 3) and by

Lemma 2, ak[sj].state can change to a state other than LOCAL or WAS-LOCAL not before tj + Ts. Since T5 > T7 (Assumption 3), the invariant holds.

Proof of Lemma 3 (a) Assume the claim is not true. Thus, there exists a time

tj when both ai[sj].state and ak[sj].state are either LOCAL or WAS-LOCAL. By the ATM-bridge algorithm, the state of a LAN station change to WAS-LOCAL only from LOCAL, upon the expiration of timer. Therefore, both ai[sj].state and ak[sj].state are LOCAL during some time before f 1. Let ti be the last time before t 1 when ai[sj].state is set to LOCAL and tk be the last time before t 1 when a k[Sj] state is set to LOCAL. Without loss of generality assume that ti < t k. From Assumption 1 follows that ti -I- T1 + TS 5 tk. Since tk <

tj, (1) fi + Tj + Ts < tj must hold. However, since ti is the last time before fl when ai[sj].state is set to LOCAL whereas

in’tj ai[sj].state is either LOCAL or WAS-LOCAL, we get ti + T1 + Ts > tl, in contradiction to (1).

(b) Assume the claim is not true. Thus, there exists a time tj, when ai[sj].state is either LOCAL or WAS-LOCAL and

Sj is connected to some ATM-bridge ak f Ui. Let fi be the last time before t 1 when ui[sj].state was set to LOCAL and tk be the time when Sj was connected to ak. By Assumption 1 ti + T, -I- Ts 5 fk. Since tk 5 tj (1) ti + TI + T5 5 t 1 holds. However, since ti is the last time before TI when ai[sj].state changes to LOCAL, and since at tj ai[s,].state is either LOCAL or WAS-LOCAL, tl + TI + T5 > t I holds, in contradiction to (1).

Proof of Lemma 4 Assume the claim is not true. Thus, there exists an ATM-

bridge a, for which a i[sj] .state = NOT-EXIST holds more

R. Cohen, E. Stein/Computer Communications 20 (1997) 1133-l 145 1145

than 2T4 + 2p seconds after Sj was connected to some TR

domain, of aI say. From the ATM-bridge algorithm follows

that an ATM-bridge can be in NOT-EXIST state no more

than T, seconds. This implies that Sj is connected to al for at

least T4 + 2r* seconds before ai[sj].state changes to NOT-EXIST. The value of ai[sj].state may change to NOT-EXIST in one of the following two ways.

During the execution of an RSP instance for Sj, ATM-

bridge ai broadcasts an RSP_SEARCH messages to sall the ATM-bridges, but receives no RSP_RESPONSE

message. Since station Sj is connected to the ELAN, to the domain of ATM-bridge al say, for at least T4 + 2T* seconds before ai[sj].state changes to NOT-EXIST, it is

connected for at least T4 + r* seconds before al receives the B_RSP_SEARCH from ai. Since al sends no RSP_RESPONSE, al[sj].state must be one of the follow-

ing (see Fig. 3): REFER_TO_BRIDGE, UNKNOWN SEARCHING, IN-BRIDGE or WAS-IN-BRIDGE.

The last two cases are not possible because of Invariant 2. If al[sj].state is REFER-TO-BRIDGE then, since Sj is

connected to al more than T4 seconds, when al receives the RSP_SEARCH message, it performs a local search for sj before sending its RSP_RESPONSE, finds Sj, and

changes a,[s,].state to LOCAL-in contradiction to our assumption. If a,[sj].state is UNKNOWN then al performs a local search, finds Sj, and changes al[sj].state to LOCAL-contradicting our assumption. If al[sj].state is SEARCHING, then al is in the middle of an RSP

instance for si. Since Sj is connected to al at least T4 +

7v seconds before al receives the RSP_SEARCH message from a,, and since p is an upper bound on the time

of an RSP instance, it implies that Sj was connected to al

at least T4 seconds before the RSP instance of a, had started. By the ATM-bridge algorithm (Fig. Z), when al started its RSP instance al[sj].state was WAS-IN_

BRIDGE(u& or REFER-TO-BRIDGE(Q), or

UNKNOWN. If al[sj].state was WAS_IN_BRIDGE(uk) then, by Invariant 2, at that time ak[sj].state was either LOCAL or WAS-LOCAL, and by Lemma 3 Sj was connected to uk, in a contradiction to our assumption. If

al[sj].state was REFER_TO_BRIDGE(uJ, then since Sj was connected to al more than T4 seconds before the RSP instance of a, has begun, ai should have initiated a local

search for Sj before starting an RSP instance, found Sj+ and not started an RSP instance. If al[sj].state was UNKNOWN, then before initiating an RSP instance, al

should have performed a local search for sj, found it, and not initiated an RSP instance.

During the execution of the RSP instance for sj, ai received from ak an RSP_RESPONSE with {NOT_ EXIST, timer]. To prove the lemma in this case, we define a directed tree whose vertices are the ATM bridges in NOT-EXIST state, and a directed edge exists from ak to Ui if Ui is in NOT-EXIST due to the receipt of an RSP_RESPONSE with (NOT-EXIST, timer} from

ak. The root of this tree is an ATM-bridge, a, say,

that entered NOT-EXIST after broadcasting a B_RSP_

SEARCH to all the ATM-bridges and receiving back no

RSP_RESPONSE message. When ATM-bridge ak sends to ai an RSP_RESPONSE with {NOT-EXIST, timer} the value of the Sent timer is ak[sj].timer - 7. When ai receives this response it sets ui[s,].timer to the value of the received timer. By Assumption 2, at this time

Ui[sj].timer 5 ak[sj].timer. This implies that in the

directed tree the timer of every ATM-bridge is not larger than the timer of its parent. Thus, as long as ai[sj].state is NOT-EXIST, a,[sj].state must also be NOT-EXIST, in

contradiction to case (1) before.

Proof of Lemma 5 The output of an RSP instance initiated by ai can be

WAS_IN_BRIDGE(uk) only if ai receives an RSP_ RESPONSE with {WAS-LOCAL, timer} from ak. Assume

that such a message is indeed sent by ak while Sj is not

disconnected. By lemma 3 sj is connected to ak. However, ATM-bridge ak sends an RSP_RESPONSE with (WAS_

LOCAL, timer} only after performing a failed local search for sj, which leads to a contradiction.

References

[I] Institute of Elecuical and Electronics Engineers Inc. ANSI/IEEE stan-

dards 802.3-1985 (IS0 8802-3): CSMAKD access method and phy-

sical layer specifications, 1985.

[2] Institute of Electrical and Electronics Engineers Inc. ANSI/IEEE stan-

dards 802.5-1989 (IS0 8802-5): Token ring access method and phy-

sical layer specifications, 1989.

[3] ATM Forum Technical Committee, LAN Emulation Sub-Working

Group. LAN Emulation Over ATM: Version 1.0 Specification,

January 1995.

[4] D. Pitt, J. Winkler, Table-free bridging, IEEE Journal on Selected

Areas in Communications 5(9) (1987) 1454-1462

Reuven Cohen: Received the B.Sc., MSc. and Ph.D. degrees in Computer Science from the Technion, Israel Institute of Technology in 1986, 1988 and 1991 respectively. From 1991 to 1993, he was with IBM T.J. Watson Research Center working on protocols for ATM and high speed LAN& From 1993, he has been with the Department of Computer Science, at the Tech- nion, Israel Institute of Technology. His most recent work focuses on the design of protocols for routing, multicast and transport. In the last three years he has also been working with HP Labs on residential broadband networking.

Eli Stein: Received the B.Sc and M.Sc degrees in Computer Science from the Technion, lsrael Institute of Technology in 1993 and 1995 respectively. From 1995 he has been working in the R&D center of NBase communications in Israel. He has participated in the design and develop- ment of Ethernet, Fast Ethernet and IP switches as well as ATM LAN Emulation module.

Documents

An efficient approach for token-ring LAN emulation over ATM