Access architecture for a multiprotocol broadband backbone

ELSEVIER Computer Networks and ISDN Systems 29 (1997) I37- 155

Access architecture for a multiprotocol broadband backbone

W. Doeringer a**p’, D. Dykeman a, M. Peters b, H. Sandick b, IS. Vu b, J. Derby b a IBM Research Diuision, Zurich Research Luborutory. CH-8803 R&h&n, Switzerland

b IBM Networking Systems, P.O. Box 12195. Reseurch Triungle Purk. NC 27709, USA

Accepted 16 April 1996

Abstract

We present a comprehensive architectural model of a modular communication infrastructure for providing interconnection between a wide variety of networks with like protocols across a common backbone network. Our concepts are demonstrated to be an appropriate framework for the provision of (a-)synchronous virtual channels, LAN interconnection, and standard bernetworking, thus covering the most typical current connectivity requirements. The base architecture has been implemented, and first products are being offered with interfaces for Frame Relay, Fiber Channel Standard, ATM, voice and clear channel services.

Keywor& Intemetworkmg; Multi-protocol routing; Multi-protocol backbone; Port-to-Port connectivity; LAN interconnection; Directory services; Address resolution; Access architecture; Encapsulation; Tunneling

1. Introduction

Owing to increased competitive pressure [ZO, 79,951 and growing connectivity expectations in the user community [67,94,107], network service providers have begun in recent years to use their installed equilpment not only to provide connectivity between end nodes, i.e., end systems, native 2 to their networks, but also as a platform for the interconnection of external local and wide area networks with mutually compatible architecture and protocols as depicted in Fig. 1 [1,3--5,15,43,69,71].

Interconnecting multiple networks over a common backbone system provides significant advantages compared to building multiple disjoint networks. Pri- marily the cost of installing, operating, and maintain- ing a single backbone is much less than that of supporting multiple independent interconnection facilities (e.g., multiple dedicated leased lines). Addi- tionally, through the use of standard network management protocols, the backbone system and the networks being interconnected can be managed from a central point, as opposed to each individual network being managed separately [104].

* Corresponding author. ’ Present address: Palatinate State College, D-67549 Worms,

Germany. ’ Native end nodes are those implementing the protocols speci-

fied by the network provider’s architecture.

Early examples of backbone systems providing connectivity for multiple protocols are X.25 networks with PAD and BSC access functions [13,21], and the IBM SNA/XI products [52] which allow SNA networks to provide access services to standard X.25 DTEs. 3 Existing ISDN and planned B-ISDN networks allow for the provision of connectivity

0169-7552/97/$17.00 Copyright 0 1997 Elsevier Science B.V. All rights reserved PII SO169-7552(96)00079-7

138 W. Doeringer et al./Computer Network and ISDN Systems 29 (1997) 137-155

Fig. I. Connectivity is provided between networks of compatible architecture.

between external networks, by defining basic access services for non-ISDN equipment via the R interfaces [22]. Further, past years have witnessed the introduction of a multitude of LAN interconnection schemes [90,98], and most recently, multi-protocol routers [16,25] have been introduced and met tremendous success in the market place 1911.

This paper presents a novel and comprehensive architectural model of a modular system for providing interconnection between a wide variety of networks with like protocols. We view such facilities as being comprised of access services built around a broadband backbone network. The access services, which mediate between the external protocols and those of the backbone, are described in full detail. In contrast, the backbone network is regarded in an abstract sense in that we only identify its relevant components and give a definition of the services to be provided to enable the proposed access services.

3 We use the CCITT-defined terms DTE, for Data Terminal

Equipment, and DCE, for Data Circuit Terminating Equipment.

It is the modularity of the design - with its resulting flexibility to interconnect a very wide range of networks through the access services over a single backbone network - that distinguishes our architecture most pronouncedly from the currently available interconnectivity solutions which focus on LAN interconnection or multi-protocol routing [3,10,16,25, 981.

Existing solutions provide connectivity to a lim- ited set of networks. For example, LAN bridges provide interconnectivity to protocols that locate resources using broadcast address resolution procedures. The bridges either return a list of traversed bridges that can be used to send subsequent point- to-point frames (i.e., as a source route), or they learn the location of MAC addresses in the interconnected LANs so that subsequent point-to-point frames can be routed transparently. Multi-protocol routers provide connectivity by implementing the network-layer (routing and relaying) protocols of each of the protocol architectures being interconnected. Thus while lower-layer facilities (e.g., communication links and memory for buffers) in and between routers are

W. Doeringer et al./Computer Networks ad ISDN Systems 29 (1997) 137-155 139

potentiaily shared for multiple protocols, there is no sense a bias towards packet switching since broad- sharing of routing information bases, because the band networks are based on such a technology, for different routing protocols are supported indepen- convincingly good reasons [ 1,45,72,78,99]. We also dently. However,, since such coexisting protocols are need not differentiate between connection-oriented not genuinely isolated in practice, it has been argued and connectionless backbones, unless dictated other- in [28] that this approach raises serious issues of wise by particular requirements, such as bandwidth management, non-interference, coordination and fair- reservation which in principle requires some form of ness in real networks. a connection-oriented architecture.

The above approaches do not extend well to other forms of interconnection. For example, neither of these architectures can provide DCE functions (e.g., to support Frame Relay, (B-)ISDN, and SMDS interfaces) that require protocols for routing and data relaying between DCEs. Existing internetworking systems are also tied to a particular backbone network. Some designs have appeared for providing LAN interconnection over specific networks such as ISDN [SS], X.25 [lOOI, and MANS [18], but these are dependent on the backbone technology, and are not directly useful for providing interconnection over modem broadband networks. Our architecture speci- fies the services to be provided by the backbone network, but is otherwise technology-independent.

The design of the access services architecture applies equally well to circuit and packet-switched backbone networks. Some readers may, however.

In the following section we present the principle structure of a generic broadband backbone network and discuss the services we assume as a basis for the access architecture presented thereafter. We focus on the details of the access services, and merely specify the services to be provided by the backbone in order to guarantee that the access services are kept independent of specific network technologies. While we do not focus on the design of broadband networks, comparisons with the current state of broadband networking technology, products and architectures serve to demonstrate that our assumptions are not only technically viable, but also that the services required by our access architecture will emerge in the very near future. Next we describe the structure of the entities performing the access functions, called access agents, and finally we present case studies of concrete issues related to the interconnection of some

Fig. 2. Backbone components. Communication is required only between access agents attached to external networks of compatible architecture.

140 W. Doeringer et al./Computer Networks ud ISDN Systems 29 (1997) 137-155

real example networks to illustrate the role of access agents for the three most typical types of access services: * Provision of DCE functions for standard inter-

faces with widely varying complexities of signalling schemes and services for the data transfer phase,

. distributed or split intelligent bridge services for LAN interconnection, and

. intemet routing functions for participating in standard internetworking protocols. We want to alert the reader to the fact that some

of the present architectural concepts cannot be fully appreciated without an understanding of the motivat- ing issues discussed in the case studies. Since we cannot summarize all of the key aspects of the networks referenced here, we assume that the reader is familiar with current network architectures in wide and local area environments (e.g., IP [29], and Net- BIOS [50]), which will also provide a better appreci- ation of our particular choices in the large design space.

2. Base architecture

Regardless of the networks to be connected, the principal components of a broadband backbone and the access services are as depicted in Fig. 2. The diagram illustrates two different types of external networks with incompatible protocols whose individ-

ual components are interconnected via the access services over a single backbone.

External networks are attached to the backbone via access agents which reside in access nodes. Access nodes are native network or end nodes of the backbone, i.e., intermediate or end systems, that reside at the edge of the backbone network. They are connected via the backbone, and can thus provide interconnectivity to the access agents and external networks. They communicate only with other access nodes attached to external networks of the same type, since only like-to-like connectivity is provided in accordance with our perspective of the future environment of general backbone networks: The growing availability of bandwidth makes full encapsulation of external protocols feasible, and the ex- tremely high transmission rates require very short instruction paths for data relaying to exploit the available physical transmission capacity [27,36] and to support data traffic with real-time constraints [66,102]. This rules out any attempt to bridge unlike external networks, which would increase the overall connectivity at the expense of the additional processing required in protocol-converting systems [76]. In- terconnection of incompatible network routing protocols would also necessitate proxy schemes and ex- plicit mappings between the nonmatching addresses and protocols [106]. This was excluded from our design to provide maximum transparency of the backbone network and to preserve the consistency of the external protocols. As a result of these considera- tions, we narrowed the design space to the present

. .-- External Nehvork

Architectures Access

Architecture Backbone

Afchltecture

Fig. 3. Access node components and access agents. Multiple access agents supporting different protocols may reside in one access node.

W. Doeringer ef al./Computer Nehvorks and ISDN Systems 29 (1997) 137-155 141

Internet (3C)

“PI”’ a

Link P-9

MAC FM

madband Backbon

(A) - - --.-L-B

c” ‘0 End- to. End UC Connections

$ (W ( i ----------fee---*

i MAC Protocol Encapsulation MAC Protocol

@) m----

Fig. 4. Layers of data routing. The signalling flows typically use more elaborate protocols than the subsequent data

approach of connecting only networks of compatible architecture with full encapsulation of data packets via the backbone network.

The structure of an access node is illustrated in Fig. 3. As will be demonstrated later in the discussion, the interfaces between the backbone components and the access agents for any specific external network do not depend upon the protocols of that external network, which is obviously of vital impor- tance for the (economic) viability of a multiprotocol backbone.

The access agents provide the access services functions by mediating between the protocols in the external networks and those services provided to them as users of the fransport, direcrory, and network management services of the backbone.

Transport services provide data transport between access agents through the backbone with an appropriate quality of service. One key aspect of our access architecture is that it does not dictate a common layer 4 in the external protocol architectures at which access agents will be interconnected, since

4 Throughout this document the notion of layers refers to the OS1 seven-layer model of communications [56].

UilfhC.

this layer will naturally vary depending on the specific protocols as exemplified in Fig. 4.

There we see that bit-level connectivity, link-layer connectivity, and traditional network layer intemetworking are all provided at different layers in the external network’s architecture. The contents of the depicted signal flows also depend upon the types of external networks. Some networks use such flows to locate remote partners dynamically, and hence they generate the requirement for a backbone network to distribute search requests and responses between a suitable set of access agents for further probing into attached networks. This distribution function is accomplished by the directory services. Finally, the network management services provide the interface to a common management scheme encompassing the backbone and all of the attached networks.

Fig. 4 also illustrates another fundamental design point of our access architecture: The high-level signailing, low-level switching paradigm. That is, access agents participate - where appropriate - in signalling protocols to perform routing and to establish connections at a higher layer than the subsequent data relaying. As an example, LAN access agents typically use layer 3 (network) addresses to locate resources and establish connections, but then relay

142 W. Doeringer et al./ComputerNefworks und ISDN Systems 29 (19971 137-155

Table 1 Access services and matching quality of data transport (see also [14,86])

Access services Quality of Service of data transport Examples

Bit stream, video

MAC Layer Bridging, SMDS

ATM Cell Relaying

Frame Relay

Low latency, small delay variance, bandwidth reservation, low reservation, low error rate Low latency, high bandwidth, multicast, low error rate Low latency, small delay variance, low error rate, in-sequence delivery Low latency, bandwidth reservation congestion control, low error rate, in-sequence delivery

Connectionless Network Services Best effort datagram-like services, low error rate

Connection Oriented Network Services Reliable data transfer, low error rate

Support of standard interfaces such as V.24, X.21, ISDN SONET, DC-3

LAN Interconnection, SMDS access functions

Provision of ATM network services

CCITT DTEs operating according to the I. 122 interface specification

IP

X.25, SNA, APPN

data based on MAC header information (this is explained in detail in the LAN Interconnection Ac- cess Agent case study that follows).

Access agents, directory and network management services could be implemented as users of the transport services of an already existing backbone network as value-added functions. The services of the access node components are described in detail in the remainder of this section.

2.1. Transport services

The primary purpose of the transport services component is to satisfy the communication requirements between its users such that the required quality of service is best matched with the underlying transmission facilities. The major functions implemented in such a transport system are hence the selection of optimal routes between communicating transport users, the transport of user data with a specified quality of service, and the management of resources such as the available bandwidth. Access agents are users of the transport services, and are identified to the backbone network by individual transport addresses. 5

’ The term transport address is used from the viewpoint of the backbone network and does not imply that the backbone connectivity is used at tire transport layer of the external architecture.

To make a backbone useful for the interconnection of a wide range of external networks, its transport services must meet a wide spectrum of service requirements. For example some external networks may support real-time applications which require tight bounds on packet latency and the variance of packet delays [66]. Other networks expect reliable delivery virtually without delay constraints, and most datagram networks assume only best-effort delivery and can tolerate some level of packet loss, duplica- tion, or resequencing. Yet others may assume that multicast communication be provided between arbitrary sets of end users. The requirements placed on the transport services by the different types of access services are summarized in Table 1. The backbone must be able to provide the specified quality of service in order to support the particular type of interconnection.

Our confidence that providers of backbone networks are able to meet such a variety of service requirements is based on the observation that the service descriptions of emerging and installed broadband networks [1,6,17,23,31,42,47,55,65,101] include real-time services, bandwidth reservation, and multicasting as standard features, and that switching devices are being deployed with similar functionality [24,33,41]. In particular, it is consistent with current networking trends and products to assume that broadband networks allow the dynamic creation of groups of transport users, identified by group ad-

W. Doeringer er al. / Computer Networks und ISDN Systems 29 f 1997) 137-155 143

dresses, and that they support multicast communication to and within such groups [7,23,32,35,97,103]. Given the early and strong focus on the choices of quality of service for data transmission, as reflected in the wide range of adaptation layers (being) defined, ATM networks are well-suited as a base technology for multiprotocol backbone networks [ 1.8, 39,40,7 1,981.

2.2. Directory services

When signalling procedures indicate that an external station is attempting to communicate with a remote partner, the local access agent needs to derive from the signalled external address information which peer access age&s> to contact in order to reach the desired destination resource. However, the backbone transport s stem in general does not understand the addresses P employed by the external networks. Ad- ditional procedures are hence required to map the particular addresses of external resources dynamically to the backbone transport address of peer access agent&) through which communication with the respective resources may be accommodated. Such proceduhs are commonly referred to as address resolution, and are particularly well established in LAN environments where network-layer entities are allowed free mobility among LAN stations, and therefore their addresses need to be mapped dynamically to respective MAC-layer addresses of the stations in which they reside [50,59,82].

In a backlbone, address resolution in the above sense is the responsibility of the directory services components, which together implement the directory services in a ldistributed fashion. To meet their objec- tive, these components rely on the registration of external network addressing information by the access agents via appropriate protocols 1371. It is not feasible, however, to register information about all individual external resources, or to distribute information regarding the servicing access agents for each resource, dule to the explosive growth of mapping tables and the attendant communications overhead.

6 Following the definitions in [56,58,60], the term address

denotes here a unique identifier of network entities and service access points.

Address patterns distributed

u-+ between routing domains (Prefix)

f between areas of one domain (Prefix)

) within an area (Full Address)

Fig. 5. Example of OSI network addresses and network topology.

In cases where the registered information is insuffi- cient to determine the location of an external resource, directory service components must execute an algorithm to distribute searches to suitable sets of access agents, which relay such address resolution procedures into the external networks to locate the resource. In these cases the all-station broadcasts used in LAN environments do not provide a suitable framework for search distribution in large backbone networks 11041. The design of the directory service algorithms must strike a good balance between the overhead of locating resources and the provislon of full connectivity to the external networks.

An analogous problem has to be solved by the routing protocols of all network architectures de- signed to scale well to large networks of general topology. Recall that all such network architectures perform routing based on structured addresses which closely mirror the network topology (see [22,29,58] for examples). The routing protocols of these networks distribute or configure reachability iEforma- tion in the form of address patterns, which grow increasingly generic (i.e., less specific, and therefore representative of larger sets of end nodes) the farther they are distributed. Routing to individual network entities is guided by “best” matches of the specified individual addresses and the advertised address patterns [87]. A typical use of network addresses by OSI routing protocols [62,64] is depicted in Fig. 5.

Note that the address patterns of these routing protocols take the form of variable length prefixes

144 W. Doeringer et d/Computer Networks und ISDN Systems 29 (1997) 137-155

whose generality increases with decreasing length. The OS1 network nodes base their routing on the “longest matching prefix” rule. As another example, compare the current partition of the Internet Protocol addresses into Netid and Hostid.

Following common practice we refer to the address patterns distributed by the external network routing protocols as netid( accepting the fact that multiple netids may apply to the same external network.

In order to exploit the address structures of external routing protocols for our purposes, access agents register external reachability information with the directory services in the form of resource identifiers which consist of a protocol type indicator and protocol-specific address patterns, i.e., netids. Access agents may learn the netids of attached external networks through participation in external routing protocols. In cases where this is not possible, this reachability information must be provided to the access agents by the network administrator, for example by configuring them locally. Observe that such identifiers cover the full range from those that consist of only the protocol indicator, thus indicating potential reachability to all addresses of the specified type, to those indicating reachability to groups of addresses with a common prefix, and those that contain a full specific, i.e., individual, address. The structured addresses of external network protocols allow a sufficient reduction in the amount of information to be supplied to and managed by directory services, and the algorithms of modem distributed directories [5 1,61,74] illustrate that efficient search navigation can be achieved based on such structured information, and sufficient resource mobility is thus guaranteed.

In cases where only a single access agent registers a given resource identifier, address resolution for an address with a matching netid is simple. All appropriate signalling and data flows are sent to the access agent that registered the matching identifier. In cases where multiple access agents have registered a given resource identifier, the directory service distributes a search for a specific address with a matching netid to all access agents that have registered the matching reachability information. These agents may then propagate the search into the attached networks by means appropriate to the particular external protocol.

Based on dynamically acquired, cached, or configured information, the access agents will report their findings to the respective local directory service components, which send suitable responses back to the search initiator. In some of these cases the access agents may need to implement private protocols to further coordinate received searches. We refer the reader to [37] for a full description of the algorithmic details.

In cases where external network protocols use unstructured addresses, ’ which do not reflect the network topology, reachability information cannot be meaningfully condensed since only complete addresses are useful in locating resources. For such protocols, dynamic routing and address resolution become infeasible for any sizeable network. A static decision must therefore be made as to where their frames may be distributed to limit the dissemination of address information and the scope of directory searches. In order to integrate such networks into our general framework based on structured addresses, a network administrator must statically identify collections of subnetworks that are to be interconnected, forming a uirtual network. This virtual network is assigned a virtual netid that is then registered with directory services as the only address pattern describ- ing all resources located on the virtual network. All access agents attached to a given virtual network register the same virtual netid, and therefore searches for resources in that virtual netid are distributed to each of them. Such a virtual netid is not part of the subnetwork’s native nonstructured address, however the access agents attached to the virtual network treat all frames as if they had specified me assigned virtual netid as part of the address information. Thus an external network that uses unstructured addresses can only be a part of a single virtual network. The virtual netid is always passed to directory services when a search for an address is required, and therefore the external addresses are perceived as being structured. Searches of virtual networks are scoped to their component subnetworks because unrestricted connectivity to other networks is not possible with-

-ample LAN protocols with their unstructured (IEEE) MAC addresses, standard NetBIOS protocol implementations, or

the LAT from DEC.

W. Doeringer ef al. / Computer Networks und ISDN Systems 29 (1997) 137-155 145

out the use of structured addresses by the external protocols. This is an intrinsic limitation of networks with unstructured addresses, not a limitation of our access architecture.

To give a recent example, the scoping dilemma is reflected in the design of the ATM Forum LAN Emulation [98], which consequently also employs a virtual network concept. The standard represents a very particular embodiment of our general architecture for the specific purpose of LAN MAC-layer emulation over an ATM-based transport network. The basic ATM services are augmented to the required level via dedicated multicast and directory servers, thus rrendering on overall solution scaled to small to medium-sized user populations. The access points to the emulated LAN services are placed within the end stations, *vhose soft- and hardware need to be modified prior to attachment. Hence, the transparency of interconnection is lost at the lower two protocol layers of the attached stations, in contrast with our proposed design.

The size of a virtual network is left to the discre- tion of the network administrator. In the most ex- treme case a single virtual network might comprise all LANs attached to a backbone. In practice a trade-off must be found between the loss of connectivity due to partitioning subnetworks with unstructured addresses into virtual networks, and the cost of locating resources in large virtual networks. Such resource location is costly since all component net-

works of a virtual network must be searched to locate a resource in that network.

In summary, we note that our assumption that all attached external networks use structured addresses represents the weakest requirement to make efficient directory services and dynamic address resolution viable for large backbone network. The above discussion also demonstrates that this assumption is not in conflict with the majority of general-topology network architectures, and that it can be extended to protocols using unstructured addresses with reason- able effort through the formation of virtual networks.

2.3. Network management services

In a heterogeneous environment it is important to provide users with a cohesive network management scheme to manage the entire interconnected network rather than having to manage individual subnetworks separately [104]. Fig. 6 illustrates a conceptual framework for such integrated network management services. There a user connects private management facilities via standard interfaces to one (or several) management focal points of the backbone network, which communicate with the network management entities in the access nodes. The access agents participate in the external management protocols and mediate between the external and internal management procedures. The managing user is thus presented with a common view of the backbone and the attached external networks.

Fig. 6. Management framework. FPx denotes a management focal pointer for network x.

146 W. Doeringer el d/Computer Networks and ISDN Systems 29 (1997) 137-155

Apart from first small-scale, mostly proprietary, approaches to solve the management problems of heterogeneous intemets, a consistent management architecture has not yet appeared [48]. Standards activities have started and there appears to be a trend to integrate network management schemes into the Common Management Information Protocol framework currently defined by OS1 [63], which promises to provide a suitable base for backbone management protocols [75,85]. Other approaches are based on the Internet Simple Network Management Protocol [19] or, more recently, are distributed on object-oriented technology [53,93]. These issues are not addressed further in this paper, and are left as a very promising area for future research [z].

2.4. Access agents

Access agents form the point of attachment between the backbone and external networks. Hence their principle purpose is to mediate between the external network protocols and those of the backbone to achieve transparent interconnection of like external networks. Fig. 7 outlines a possible internal architecture of access agents which aligns with our general model, and which justifies our claim that the interfaces to the components of the backbone network do not depend upon the external protocols. The primary functions of the depicted components are explained below, and further details are discussed in Section 3.

The protocol components are cognizant of the external network protocol formats and semantics. They map between the external signalling and broadcast procedures and the services provided by the other access agent and backbone components, thus hiding any protocol particulars from the rest of the backbone network. For example, in cases where the external protocols perform search procedures, the protocol component registers reachability information for local resources with directory services and initiates searches for resources not found locally with directory services. Reciprocally, directory services invoke the protocol components in the appropriate access agents in order to have them search the attached networks to determine the location of a resource when multiple access agents register a given resource identifier.

Depending upon the particular type of access agent, this component may send datagrams or request connections from the connection component to access agents through which specified external resources can be reached, and it may also encapsulate external protocol signalling packets through the backbone in order to establish end-to-end connectivity. When the external protocol indicates that a particular instance of communication is complete, this component initiates the release of all associated resources, such as transport connections over the backbone network.

The connection component is present if the backbone supports connection-oriented communication.

To/from other

Backbone Nodes

Fig. 7. Access agent functional decomposition. The distinction between signalling and data packets depends on the particular external protocol and access agent, see Section 3. The tables are shared between the depicted components.

W. Doeringer et al./Computer Networks awl ISDN Systems 29 (1997) 137-155 147

Backbone Network DCE DCE

Access Node Access Node DTE

SOUKX

Fig. 8. Clear charnel interconnection. The signalling flows are not encapsulated, but translated into the backbone signals as indicated by the dotted line.

This component uses transport services to establish and manage connections between peer access agents as requested by the protocol component and in accordance to its local policies regarding the reuse of existing connections. It creates entries in the internal connection tables which are used by the relay component to perform data relaying as appropriate for the respective external network architecture. This component also adapts to changes in bandwidth requirements and terminates obsolete connections and connection table entries.

The relay components forward data packets between the external networks and the backbone as appropriate for the particular access agents. External packets received by an access agent contain specific identification, e.g., a destination address, .a connection identifier, or a label, which the relay component

can interpret. This allows the packets to be forwarded through the backbone based on entries in the connection and routing tables established by the connection and protocol components.

3. Access agents case studies

The relevance of an architecture is best demonstrated by showing its applicability to a representative sample of real-world scenarios. Hence we now illustrate how our general concepts apply to the provision of DCE functions, intelligent split-bridge services, and intemet routing. We thus illustrate how the most important existing interconnectivity requirements can be provided by our architecture, as well as how the architecture can be used to support sig-

DTE RS232 Interface DCE (Access Agent)

i ;:

r---l

I 1 RTS I

Payload Transmitted:

Interface Signal Bits k Data Bytes

Fig. 9. RS232 access agent.

148 W. Doeringer et nl./Computer Networks and ISDN Systems 29 (1997) 137-155

Fig. 10. B-ISDN access agent.

nailing and data relaying at different layers. Empha- sis is placed on tiidging, since the LAN access agents require the most comprehensive set of access functions, and thus provide a blueprint to derive similar details for the other cases.

3.1. DCE functions

DCE-DTE interfaces include a signalling protocol through which data transmission is enabled, and a data transmission protocol which provides a virtual channel service for continuous bit stream, packet or cell-based transmission between the DTEs and DCEs.

For example, an access agent may act as the DCE of a locally terminated signalling protocol, with the subsequent data transport being performed at the physical layer as illustrated in Fig. 8. a Since the data transmission is synchronous, packet-switching backbones need to compensate for the delay jitter and limit the packetization delay. The problems related to this are well understood, e.g., for voice and video transmission, and various solutions exist or are being proposed [66,77,102].

Typical examples of DCE-type access agents are those that support interfaces employing separate sig-

8 The following discussion applies with appropriate terminol- ogy changes to DCE access agents that perform data transfer at the link or network layer, such as for Frame Relay, ATM or X.25.

nalling and data transfer entities, such as RS232, V.35, X.21, ISDN R and S, Frame Relay, and the B-ISDN User-Network Interface (UNI). The interfaces cover an entire spectrum of signalling protocols, ranging from simple on-off signalling on interface leads for RS232 (or V.241, to the elaborate message-based signalling procedures at the ISDN S-interfaces or the B-ISDN UNI. They all allow a DTE to request or accept the establishment of a communication channel with a remote DTE attached to the same type of interface.

For an RS232 interface, the access agent may establish a connection to a pre-configured destination access agent upon activation of the DTR signal, 9 and encapsulate information regarding the status of the relevant interface signals within the data stream, in order to comply with the RTS, CTS, and DCD protocol (Fig. 9).

In contrast, B-ISDN UNI [61 access agents need to implement the full signalling protocol and employ the backbone directory services address resolution procedures to locate the peer agent for a given call based on the externally-signalled, well-structured address. Once identified, the pair of access agents establish a communication path of a suitable quality of service, and then relay ATM cells received at

‘-This simple signalling interface does not allow a destination to be specified.

W. Doeringer et d/Computer Networks and ISDN Systems 29 (1997) 137-155 149

either interface. Data transmission continues until user signalling indicates that it should be terminated (Fig. 10).

The reader may wish to contrast the mobility gained for ISDN users attached to ISDN access agents, and the flexibility of routing between such agents, with the static call-routing tables of conven- tional carrier networks, which are downloaded via the Signalling System Number 7 protocols [38].

3.2. M interconnection

The advantages of Local Area Networks CLANS) over other cabling schemes include any-to-any connectivity, low..cost broadcast capability provided by a shared medium, and free user mobility between the attachment ports. However, as a LAN grows larger in user population and in geographic distance, it becomes more difficult to share the medium because of signal propagation delay [l ,lOSl, and more difficult to control the flooding caused by broadcast traffic [12,30;68,87]. The LAN access agents provide a graceful way of interconnecting multiple LANs into a single logical one, while avoiding the above problems. The interconnection is accomplished in a manner that is transparent to the LAN end stations.

common to all bridging devices [9,84]: Since the MAC-layer addresses have no topological signifi- cance, in the absence of additional routing information the agents have no other choice but to distribute each received MAC frame to all other LAN access agents and thus into all attached LANs. Such poten- tially enormous broadcast overhead is, however, highly undesirable for a backbone network, and hence it needs to be scoped for signalling procedures and avoided completely for steady-state data transmission [104]. Our solution follows the high-level signalling, low-level switching design approach cited earlier: The LAN access agents monitor the broadcast-based address resolution procedures of the higher-layer protocols on the LAN [50,59,82], and extract information to perform the address resolution over the backbone, which locates a suitable peer agent that can route MAC frames to the desired destination entity, and which also provides the specific MAC-layer address of the destination end station.

In order to provide LAN interconnection, the backbone network must preserve many of the LAN characteristics. In particular the latency it introduces must be small, especially with respect to signalling functions such as location of a resource, since the LAN-based protocols rely on this. Multicast through the backbone is required to support LAN-based multicast, and the backbone must be able to provide a bandwidth that is sufficiently high for forwarding traffic between the interconnected LANs.

Since address resolution procedures in a backbone network rely on structured addresses, the connected LAN components need to form a virtual network with a virtual netid for protocols using unstructured addresses [50,54], or those for which the higher-layer address information is not understood by the access agents. The address resolution for these protocols and subsequent data transfer are then confined to a single virtual LAN, in contrast to protocols with structured higher-layer addresses [59,82], for which LAN access agents can provide unlimited connectivity between all subnetworks supporting like protocols. We refer the reader to [37] for details of the implementation of such an address resolution procedure.

LAN acoess agents face an additional problem In either case, over time the LAN access agents

LAN Source

Signalling

r-l

(Address +--w Resolution)

Backbone Network

Access Node Access Node LAN Destination

Fig. 11, LAN interconnection. Note that the signailing flows are not encapsulated but rather translated into address resolution procedures of the backbone network.

150 W. Doeringer et al./Computer Networks and ISDN Systems 29 (1997) 137-155

establish tables which map MAC-layer destination addresses to peer agents through which the respective LAN stations may be reached. lo The established connection tables allow LAN access agents to relay point-to-point MAC frames without interpret- ing the higher-layer protocol headers, i.e., to perform low-level switching. The agents can thus achieve sufficient performance for the steady-state data transfer, and hardware implementations of the relay functions become feasible. The principles of LAN interconnection are illustrated in Fig. 11.

For the interconnected LANs the backbone takes the appearance of an additional LAN segment, and the LAN access agents resemble MAC layer bridges. This holds true for source-routing as well as transparent-bridging LAN architectures. Note however that the MAC-layer protocols are terminated at the access agents. For example, a source route at the source side includes the path only up to and includ- ing the source access agent. If the destination LAN is also a source-routing-based LAN, a new source route is used from the destination access agent to the destination end stations. Thus different types of LANs can be interconnected (e.g., source-routing Token Rings on one side and transparent-bridging Ethemets on the other). The existence of the LAN access agents is transparent to the end-station protocols above the MAC layer, which are encapsulated through the backbone. In particular, in this scenario, LAN access agents do not participate in intemet layer routing protocols, and hence cannot interoper- ate with intemet-layer access agents such as for OS1 and IP, which are described in the next section.

A particular problem is created by LAN interconnection in the case where multiple LAN access agents are attached to the same physical LAN. For efficiency reasons these access agents should coordinate their operation (see also [9,92]), such that only one of them forwards LAN address resolution requests to the backbone. Furthermore coordination of initiating searches in the destination LAN is man- dated by some LAN protocols, such as for transparent bridges with their spanning-tree algorithms. The same arguments apply for supporting user datagrams.

10 Note the resemblance of this procedure with the learning process of bridges on transparent-bridging LANs.

Fig. 12. Multiple attachment group.

The corresponding situation does not exist for DCE access agents since DTEs are always directly attached to a single DCE, and the addresses actually identify a DCE port and not a DTE (think of a telephone number which is associated with a particular port and not with the phone plugged into that port). Also, internetworking routers forward connection requests and datagrams point-to-point to the next router on the path to a given destination (as opposed to the broadcast-based LAN procedures) and therefore additional coordination is not required.

Coordination between LAN access agents requires constant mutual awareness of their connectivity through the attached LANs. That is, LAN access agents need to implement a distributed algorithm which maps the external LAN topology back into the backbone in the form of dynamically adjusted collections of the access agents that are attached to the same LAN. Access agents attached to the same LAN join a multicast group called a multiple attachment group (MAG), exploiting the multicast capabilities we assumed to be provided by the transport services. To illustrate, consider the situation shown in Fig. 12 of a LAN with two bridged segments.

All three access agents in the diagram are part of the same multiple attachment group since they are attached to the same physical (bridged) LAN. Hence, search requests received from the backbone are only forwarded by one of the agents. Let us now assume

W. Doeringer et al. /Computer Networks und ISDN Systems 29 (1997) 137-I-U 151

Fig. 13. Mulliple attachment group after bridge failure.

that the bridge fails and the segments become separated (see Fig. 13). Following this, any search request (or datagram) from the backbone must be forwarded to both segments, since the destination resource may reside on either one. It thus becomes obvious that a group-forming algorithm based on the LAN protocols must constantly adjust the multiple attachment groups to reflect the actual LAN topology. Fig. 13 depicts the results of the operation in which, after the bridge failure, two groups are established, one consisting of AA1 and AA2 and the other of AA3. Once the bridge is repaired, the algorithm has to join the two groups back into one restoring the situation depicted in Fig. 12. The multiple attachment groups form the basis of all coordination within the various collections of access agents. The coordination algorithms are straightforward (e.g., the access agent with the lowest address or lowest load is selected) and are not discussed further here [34].

3.3. Internet routing

Yet a different case is represented by the access agents supporting internetworking protocols such as the OS1 inter and intra-domain routing protocols [62,64], which are used to route OS1 CLNP datagrams 1571, or the various routing protocols [46,49,70,73] developed for routing Internet Protocol datagrams [83]. Here signalling and data transport are performed hop-by-hop at the same layer, i.e., at the intemet layer (3~1, which is implemented in the access agents. The access agents thus effectively become (multi-protocol) routers which communicate by encapsulating the data and routing-protocol packets of the external protocols over the backbone network. This standard procedure results in an overall structure as depicted in Fig. 14.

Multiprotocol backbones provide substantial advantages over existing WAN subnetworks, such as X.25, and current multi-protocol routing solutions. As noted in [8 11. all network standards gloss over the issue of first contact between routing devices, and assume that sufficient “initial knowledge” is available regarding the network topology and pertinent subnet points of attachment, i.e., the subnetwork addresses that the routing devices use to exchange data. For backbones with access services, the requirement for such extensive configured information can be completely eliminated. Upon initialization a particular router access agent need only issue a (wild-card) directory search with the destination resource identifier specifying the particular intemet protocol type. Directory services will distribute such searches to all active peer router agents, which may then establish communication with the issuing agent as appropriate. Similar schemes are currently used for enabling contact between routers in a LAN environment [59].

Backbone Network

Access Node (Router)

Access Node (Router) End Node

1 (3c Routing) 1 1 (3c Routing) ] 1 (3.12 Routing) 1 / (3c Routing) 1

Fig. 14. Routing interconnection via the backbone. The access agents implement the external routing protocols and use the backbone as

subnetwork.

152 W. Doeringer et ol./ Computer Networks and ISDN Systems 29 (19971137- 155

Once initial contact between the access-agent routers is established, those routers implement the routing and relaying protocols specified by the external network. No additional use is made of backbone directory services, except when a new router of that same type becomes active. The backbone transport services need only provide a best effort delivery of the external protocol’s datagrams.

3.4. Routing and bridging

We note that with some protocol suites, interconnection via backbones is possible at different layers. For example, IP-based LANs can be connected at the network layer via IP routing, or via bridging at the MAC layer. In the former case the backbone takes the role of an ordinary IP subnet, whereas in the latter the LANs are interconnected transparently to IP. The advantages of routing are that traffic may be filtered and flow-controlled, and that policy-based routing procedures may be easily introduced [96]. These capabilities are achieved through the operation of the external routing protocols which accommodate arbitrary network topologies [26]. The advantage of bridging is that desirable LAN characteristics are preserved, such as broadcasting, high-speed transmission with small variance of delay, ease of instal- lation, and increased user mobility, the latter however at the expense of broadcast searches on all segments of the interconnected (virtual) LAN [891.

Hence, whenever multiple options exist for the interconnection of a given protocol suite, the best choice will depend on the anticipated application profiles and requirements. A detailed analysis of the respective merits of routing and bridging warrants a separate discussion. The interested reader may wish to consult [ 11,44,80,87,100] for a first reading on this subject.

3.5. Summary

In the examples presented in this section, we have demonstrated how our architecture for providing interconnection can be applied in several real scenarios. In particular we have shown how a single set of backbone services can be used to support this architecture. For example, both DCE and LAN access agents register prefixes of structured addresses with

directory services. LAN access agents register virtual netids in cases where structured addresses are not used in the higher-layer protocols. Directory services can then be used to locate an application identified by a specific address with the given prefix. Access agents supporting internetworking protocols need only register a protocol type with directory services, which then supports establishing contact between all such access agents. In all cases the directory search is conducted using the same protocols. The transport service requirements of the different types of access agents were specified in Table 1. From existing and developing standards we can see that such services will be supported by the respective broadband networks.

4. Conclusion

This paper has presented a comprehensive architectural model for interconnection of a large class of protocols over a common backbone network. We have argued that by providing connectivity only between compatible protocols, the performance requirements of very high-speed networks can be satis- fied, and that the semantics of the interconnected networks are preserved, thus protecting all applications deployed in such networks.

We have demonstrated that our architecture ac- commodates a wide range of external protocols which is not readily supported by existing internetworking solutions. This flexibility was gained through our modular design approach which separated out the two essential system components: 1. First, there are the access services, which build on

the high-level signalling, low-level switching paradigm to achieve minimal-overhead steady- state data paths, and which rely on a single well-defined set of backbone services irrespective of the attached external networks. All protocol- specific functions are confined to this component.

2. The second component, the backbone network, provides the protocol-independent services to the access agents. The backbone was described in terms of the functions that must be performed by the common network management, transport and directory services. It is important to note that the access agents,

directory services, and network management func-

W. Doeringer et al. /Computer Networks and ISDN Systems 29 (1997) 137-155 153

tions are independent of transport services, and thus could be implemented as value-added functions on top of any backbone network that can meet the requirements specified in Table 1. Thus our architecture could be implemented on emerging or deployed broadband networks to provide a general “vendor- independent” solution for interconnectivity, includ- ing compliance with any economically relevant standard.

Acknowledgements

It is a pleasure to acknowledge the reviewers’ comments and the fruitful cooperation with many colleagues during our design work, such as Liz Hervatic, John Drake, and Gary Dudley to name only a few. Also, discussions with Liba Svobodova and Phil Janson contributed invaluably to the clarity of our presentation. Special thanks go to them for their quest for better quality in technical publica- tions.

References

[II

Dl

[31

(41

[51

if31

AS. Acampora, An Introduction to Broadband Networks

(Plenum Press, New York and London, 1994).

A. Albanese, T.N. Devetzis, M. Maszczak, L. Ambrosoli and M. Marini, A network and services integrated management system prototype, in: V.A. Monaco and R. Negrini,

eds., Proc. CompEuro Con&, Bologna (IEEE Computer Society Press, Silver Spring, MD, 1991). ATC, Special reports on multiport Intemetworking systems

and virtual networks, LOCALNetter 11 (2) (1991). ATC, Special reports on Cisco Systems Netscape paradigm,

LOCALNerter 12 ( 1) ( 1992). ATC, Special report on Motorola Codex’s networking architecture plan, LOCALNetter 13 (9) (1993).

ATM Forum, ATM: User-Network Interfice Specification. Version 3.0 (Prentice-Hall, Englewood Cliffs, NJ, 1993).

[7] J. Auerbach et al., Multicast group membership manage-

ment in tligh speed wide area networks, in: Proc. llrh Conf. on Distributed Comput. Systems. Arlington, TX (1991) 23 l-238.

[S] A. Badack, E. Hoffmann and D. Knauer, High Speed

Internetworking (Addison-Wesley, Reading, MA, 1994). 191 F. Baker, The point-to-point protocol extensions for bridg-

ing, RFC 1220, NIC, April 1991.

(101 E.W. Biersack, Annotated bibliography on network interconnection, IEEE JSAC 8 (1) (1990) 22-41.

[I I] J. Bion, IJser interface, The Packet 3 (2) (1991).

1121

(131

[I41

[ISI

1161

[I71

iI81

[191

1201

Dll [221

1231

[241

[251

[%I

[271

I281

[291

ml

L. Bosack and C. Hedrick, Problems in large LANs, IEEE

Network 2 (1) (1988) 49-57. R. Braden et al., A distributed approach to the interconnection of heterogeneous computer networks. in: Proc. ACM

SIGCOMM Symp. (1983). R. Braden and D. Clark, Integrated services in the Internet

architecture: An overview, RFC 1633, NIC, June 1994.

T. Bradley. C. Brown and A. Malis, Multiprotocol interconnect over frame relay, RFC 1294, NIC, January 1992.

S.O. Bradner, Testing multiprotocol routers, Dam Commun.

Vol. 20 (2) (1991) 70-86. S. Bradner and A. Mankin. The recommendation for the IP

next generation protocol, RFC 1752, NIC, January 1995. A. Buhmann, Metropolitan Area Network (MAN) high

speed LAN interconnection, in: V.A. Monaco and R. Ne-

grini, eds., Proc. CumpEuro Co& Bologna (IEEE Com- puter Society Press, Silver Spring, MD, 1991).

J.D. Case, M. Fedor, M.L. Schoffstall and C. Davin, Simple

Network Management Protocol (SNMP), RFC 1157, NIC, May 1990.

L. Cattell, The economic benefits of intelligent FRADs as a frame relay alternative, Telecomnzun. (January 1993) 64-68.

CCITT, X25 Recommendation (CCITT Blue Books, 1988). CCllT, ISDN Recommendations (CCITT Blue Books, 1988).

P.F. Chimento et al., Broadband Nehvork Seroice fi)r

High-Speed Multimedia Networks (IBM Corporation, 1993). I. Cidon and I. Gopal, PARIS: An approach to integrated

high-speed private networks, Internat. 1. Digital & Analog Cubled Systems 1 (1988) 77-85.

cisco, Gateway systems, Document DOC-GSR-8.1, cisco systems Inc. May 1990. D.D. Clark, Policy routing in Internetworks, fnternetwork-

ing: Research and Experience 1 (1990) 35-52. D.D. Clark, V. Jacobson, J. Romkey and H. Salwen, An

analysis of TCP processing overhead, IEEE Commun. Mug. 27 ( 1989) 23-29.

D. Clark, L. Chapin. V. Cerf, R. Braden and R. Hobby, Towards the future Internet architecture, RFC 1287. NIC, December 1991.

D. Comer, Internenvorking with TCP/ IP. Principles, Pro- tocds and Architecture (Prentice Hall, Englewood Cliffs,

NJ, 1989). R.P. Davidson and N.J. Muller, Inrernetworking LANs:

Operufion. Design und Munugement (Artech House, Boston, 1992).

[31] M. De Pryker, ATM technology: A backbone for high

speed computer networking, Computer Networks ISDN Sys- tems 25 (4-S) (1992) 357-362.

1321 SE. Deering and D.R. Cheriton, Multicast routing in datagram Internetworks and extended LANs, ACM Trans. Compur. Systems 8 (2) (1990) 85- 110.

[33] W.E. Denzel. A.P.J. Engbersen, I. lliadis and Cl. Karlsson, A highly modular packet switch for Gb/s rates, in: Proc. 14th Internut Switch. Symp. (ISS’92). Yokohama, Japan

(I 992) 237-240. [34] W. Doeringer et al., Forming and monitoring access groups

154 W. Doeringer et al. / Computer Networks and ISDN Systems 29 (1997) 137-155

at the LAN/WAN interface, European Patent Application 93, 480, 165.5, December 1993.

1351 W. Doetinger et al., Inter-domain multicast routing, United States Patent 5, 361, 256, November 1, 1994.

[36] W. Doeringer, D. Dykeman, M. Kaiserswerth, B. Meister, H. Rudin and R. Williamson, A survey of light-weight transport protocols for high-speed networks, lEEE Truns.

Commun. 38 (11) (1990) 2025-2039. 1371 W. Doeringer, D. Dykeman, M. Peters, H. Sandick and K.

Vu, Efficient, real-time address resolution in backbone networks, in: Proc. 1st Internut. Co@ LAN Interconnection,

Research Triangle Park, NC (Plenum, New York, 1993) 183-192.

Metropolitan Area Network (MAN), P802.6/D14, IEEE, 1990.

[56] ISO. Information processing systems - Open system interconnection - Basic reference model, IS0 7498, 1984.

[57] ISO, Information processing systems - Data communications - Protocol for providing the connectionless-mode network service, IS0 8473, IS0 SC 6, 1988.

[58] ISO, Network service defmition, ISO/8348, 1988. 1591 ISO, End system to intermediate system routing exchange

protocol for use in conjunction with the protocol for providing the connectionless mode network service (IS0 8473), ISO/DIS 10598, 1988.

[38] G. Funke, SS7 - A universal signalling system for today, tomorrow, . . . the day after tomorrow?, Philips Telecommun. Reu. 48 (3) (1990) I l-23.

[39] M. Gerla, ATM Local Area Networks, IEEE Commun.

Msg. (March 1994) 86-98.

[60] ISO, Information technology - Telecommunications and information exchange between systems - OS1 routing framework, ISO/IEC/TR 9575, 1989.

[61] ISO, IS0 X.500 series of recommendations, IS0 9594 I-8, 1989.

[40] M. Gerla, C. Tai and G. Gallassi, Intemetting LAN’s and MAN’s to B-ISDN’s for connectionless traffic support, IEEE JSAC ll(8) (1993) 1145-l 159.

[41] J.N. Giacopelli, J.J. Hickey, W.S. Marcus, W.D. Sincoskie and M. Littlewood, Sunshine: A high-performance self-routing broadband packet switch architecture, IEEE JSAC 9 (8) (1991) 1289-1298.

[42] A. Gopal, I. Guerin and S. Kutten, Broadcast in fast networks, in: Proc. Infocom’90, San Francisco, CA, June 1990.

[43] 1. Gopal, R. Guerin, J. Janniello and V. Theodorakis, ATM support in a transparent network, IEEE Network Mag. 6 (6) (1992) 62-68.

[44] M. Grimshaw, LAN interconnections technology, Telecom-

mun. (June 1991) 37-46.

[62] ISO, Intermediate system to intermediate system intra-domain routing protocol for use in conjunction with the protocol for providing the connectionless-mode network service (IS0 84731, ISO/DIS 10589, 1990.

(631 ISO, Information processing systems - Open system interconnection - Management information protocol specification - Part 2, Common Management Information Protocol (CMIP), IS0 9596/2, January 1991.

[64] ISO, Information processing systems - Telecommunica- tions and information exchange between systems - Protocol for exchange of inter-domain routing information among intermediate systems to support forwarding of IS0 8473 PDUs, ISO/DIS CD 10747, 1991.

[65] JDACS, Special Issue, Exchange network-premises network interface, J. Digital and Analog Commun. Systems (April- June 1991).

[45] 2. Haas and D.R. Cheriton. A case for packet switching in high-performance wide-area networks, ACM (1988) 402- 409.

[46] CL. Hedrick, Routing information protocol, RFC 1058, NIC, June 1988.

[47] J. Heinanen, Frame relay as a multiprotocol backbone interface, Computer Networks 1SDN Systems 25 (4-5) (1992)

363-369.

[66] G. Karlsson and M. Vetterli, Packet video and its integra- tion into the network architecture, IEEE JSAC 7 (5) (1989).

[67] A. Kuendig, From computer communication to computer supported co-operative work, in: V.A. Monaco and R. Negrini, eds., Proc. CompEuro Con&. Bologna, Italy (IEEE Computer Society Press, Silver Spring, MD, 1991).

[68] LANView, The attack of the killer keep-alives, LAN View

(October 1991). [48] J. Herman, Smart LAN hubs take control. Dam Commun.

(June 1991) 66-79. [49] R.M. Hinden and A. Shehzer, DARPA Internet gateway,

RFC 823, NIC, September 1982. [SO] IBM, NetBIOS application development guide, Document

S68X-2270, IBM Corporation, 1987. [Sl] IBM, SAA distributed directory, IBM Systems J. 27 (3)

( 1988).

[69] N. Lippis and J. Herman, The Internetwork Decade, North- east Consulting Resources and Data Communications (Mc- Graw-Hill, New York, 1991).

[70] K. Lougheed and Y. Rekhter, Border gateway protocol 3 (BGP-31, RFC 1267, NIC, October 1991.

[71] D. Martinez, Frame relay and SMDS services on a common ATM-based platform, Computer Networks ISDN Systems 25 (4-S) (1992) 370-376.

[52] IBM, XI implementation, IBM Document 6624-3668, IBM [72] J.M. McQuillan, Broadband networks - The end of dis- International Support Center (Raleigh, NC), 1989. tance?, Data Commun. (June 1990) 62-74.

[53] IBM, System view: Karat, IBM Document, IBM Corpora- [73] D.L. Mills, Experimental multiple-path routing algorithm, tion, 1995. RFC 981, NIC, March 1986.

[54] IEEE, Project 802 - Logical link control, 802.2, IEEE, 1989.

[55] IEEE, Project 802 - Local & Metropolitan Area Networks Distributed Queue Dual Bus (DQDB) subnetwork of a

1741 P. Mockapetris and K. Dunlap, Development of the Domain Name System, in: Proc. ACM SIGCOMM Symp., Stanford, CA (1988) 123-133.

[75] N. Modiri, An implementation of the common network

W. Doeringer et (11. /Computer Networks and ISDN Systems 29 (1997) 137-155 155

management information service element interfaces, ZEEE

Commun. Msg. (July 1991) 29-38. [76] M. Padlipsky, Gateways, architectures, and heffalumps, in:

Elements of Networking Sry!e (Prentice-Hall, Englewood Cliffs, NJ, 198;s).

[77] C. Partridge, lsochronous applications do not require jitter- controlled networks, RFC 1257, NIC, September 1991.

[78] G.M. Parulkar and J.S. Turner, Towards a framework for high-speed communication in a heterogeneous networking environment, IEEE Network Mug. (March 1990) 19-27.

[79] C. Pentland, LAN interconnection set-vices and requirements: A European perspective, Telecommun. (August 1992) 40-43.

1801 R. Perlman. A. Harvey and G. Varghese, Choosing the appropriate IS0 layer for LAN interconnection, IEEE Net- work 2 (1) (1988) 81-87.

[81] D.M. Piscitello and J. Lawrence, Transmission of IP datagrams over the SMDS service, RFC 1209, NIC, March 1991.

[82] D.C. Plummer, An Ethernet address resolution protocol, RFC 862, NIC, November 1982.

[83] J. Postel, Internet Protocol, RFC 791, NIC, September 1981.

[84] J. Pastel, Multi-LAN address resolution, RFC 925, NIC. October 1984.

(851 R. Presuhn, Considering CMIP, Dutu Commun. (March 1991) 55-M).

[86] 3. Russell, Multimedia networking requirements, in: Proc. TriCOMM’9.3, Raleigh, NC ( 1993) 187- 197.

1871 H. Salwen, R. Bottle and N.J. Chippa, Examination of the applicability of router and bridging techniques, IEEE Ner- work 2 (1) (I 988) 77-80.

[88] S. Saunders, Using ISDN for LAN Interconnect, Dafu

Commun. (June 1991) 4850. [89] W.M. Seifert, Bridges and routers, IEEE Network 2 (1)

(1988) 57-64. [90] R. L. Sharma, Interconnecting LANs, IEEE Spectrum (1991)

32-38,

]91] E. Smalley, Reports cite growth of LAN Internet market, Network Wc~rld (March 1991) 19.

]92] C.-M. Smoot and J.S. Quarterman, Using ARP to implement transparent subnet gateways, RFC 1027, NIC, October 1987.

[93] R.M. Soley. Object Manugement Architecture Guide, Revi- sion 2.0 (Object Management Group, 2nd ed., 1992).

1941 M.D. Stahhnan and S.L. Eskenazi, Social computing: The beginning of a new era, Inveshnenr Newsletter Alex Brown and Sons, Inc., Baltimore, MD (March 1990).

]95] E.E. Summr, Data network trends, in: V.A. Monaco and R.

Negrini, eds., Proc. CvmpEuro Con& Bologna (IEEE Computer Society Press, Silver Spring, MD, 1991).

[96] C.A. Sunshine, Network interconnection & gateways, IEEE JSAC8(1)(1990)4-11.

[97] C. Topolcic, Experimental Internet stream protocol, Version 2 (ST-II), RFC 1190, NIC, October 1990.

(981 H.L. Truong et al., LAN Emulation on an ATM network, IEEE Commun. Mug. 33 (5) (1995) 70-85.

[99] J.S. Turner, Design of an integrated services packet net- world, in: Proc. 9th ACM Dam Comm. Symp., Whither Mountain, BC (1985) 123-133.

]lOO] M. Valiant, Implementing enterprise networking, Telecom- mun. (June 1991) 25-32.

[loll H.R. van As, W.W. Lemppenau, P. Zatiropulo and E.A. Zurfhrh, CRMA-II: A Gbit/s MAC protocol for ring and bus networks with immediate access capability, in: Proc.

9th EFOC,XAN Co@.. London, UK (IGI Europe, Boston, 1991) 262-277.

[IO21 D. Verma, L. Zhang and D. Ferrari, Guaranteeing delay jitter bounds in packet switched networks, in: Proc. Tri- Comm 91, Chapel Hill. NC, 1991.

[IO31 D. Waitzman, C. Partridge and S. Deering, Distance vector multicast routing protocol, RFC 1075, NIC, November 1988.

[104] J.S. Yaplee and R.O. Denney, Building a large network at the Boeing company, in: Proc. 13th Conf: on Local Com-

puter Networks, Minneapolis (1988) 20-26. ]105] P. Zafiropulo, From LANs to MANS, in Proc. 8th EFOC/

UN Exposirion (LAN’901, Munich, Germany (1990) 15-22. [IO61 S. Zatti and P. Janson, Interconnecting OS1 and non-OS1

networks using an integrated directory service, Computer Networks ISDN Systems 15 (1988) 268-283.

11071 T.G. Zerbiec, Considering the past and anticipating the future for private data networks, IEEE Commun. Mug. (March 1992) 36-46.

Willibald Doeringer received the Ph.D. degree in mathematics from the Frideri- ciana University in Karlsruhe, Germany, in 1983. After more than ten years of professional careers in the computer in- dustry, he joined the faculty of the Palatinate State College in Worms, Ger- many, where he lectures in mathematics, computer science and communication. He is interested in all aspects of computer science education and of net- worked systems, with a recent research

focus on internetworking and routing in large computer networks. Dr. Doeringer is a member of the Cusanus-We&, the ACM and a Senior Member of the IEEE.

Access architecture for a multiprotocol broadband backbone

Documents

Transcript of Access architecture for a multiprotocol broadband backbone