51-20-02 Enterprise Networks—The Challenges Previous screen Keith G. Knightson Payoff Establishing an enterprise network is a difficult and complex task. This article recommends that time and effort be spent in thoroughly analyzing the networking options and vendor offerings. Such investment and the production of a blueprint for the enterprise network architecture will prevent expensive surprises and disruptions in communications within the enterprise. Introduction “Enterprise networks” and “entrprise networking” are buzz buzz phrases of the 1990s. They are on every salesperson's lips, together of course with “open” and “open systems.” Many products are glowingly described with these phrases. Creating an enterprise network, however, requires more than just a knowledge of buzzwords. This article explains the basic subtleties of an enterprise network and the challenges of establishing one. The Next Generation of Enterprises There is nothing particularly mysterious about the word enterpriseor its intent. This is nothing more than a fancy name for a given company or organization. It conveys, however, the notion of a geographically dispersed, multifaceted organization, an organization comprising many branches, departments, and disciplines (e.g.,marketing, manufacturing, finance, administration). It represents an organization with some overall business objective—making automobiles or banking, for example. So, the word enterprise really represents the totality of an organization. In the past, the networking and information technologies deployed in an enterprise were many and various. In some cases, this occurred because of local departmental or work group autonomy, or simply because of accidental ignorance among different parts of the enterprise as to what information systems were being used, or it was an artifact of historical equipment acquisition procedures. The allegiance of specific departments to particular vendors, either because of previous successful projects, political decisions, or better local salesmanship by a particular vendor, was also a factor. The simple passing of time causes different parts of an organization to be playing leap-frog in terms of product life cycles and acquisition financing. Because acquisition of capital equipment usually is performed gradually rather than implemented all at once, across the board, so it has been difficult to make sure that all equipment is mutually compatible. Finally, the lack of an enterprisewide view, strategy, or policy with respect to networking and information technology, and unawareness of the possible convergence solutions, are contributing considerations. What IS an Enterprise Network? In the same sense that the word enterprise conveys the totality of an organization's operations, the phrase enterprise network means combining all the networking and information technology and applications within a given enterprise into a single, seamless, consolidated, integrated network. The degree of integration and consolidation may vary; total integration and Previous screen consolidation may not be always achievable, as this article will show. The first example is an organization that has an System Network Architecture network from IBM Corp. and a DECnet from Digital Equipment Corp. In all probability, these two networks have their own communications components; there might be one set of leased lines serving the SNA network and another completely independent set of leased lines serving the DECnet. It would be useful if all the IBM users could intercommunicate with all Digital Equipment Corporation users, but a first and evolutionary step might be to have both the SNA network and DECnet share the same leased lines. Now, only one physical network has to be managed instead of two separate ones, and more efficient and cost-effective sharing of the physical communications plant can be achieved. A second step might be to interconnect the mail systems of the two networks to achieve at least the appearance of a single enterprisewide electronic mail system. A third step might be to unify the data and information and its representation as used within the organization. This would enable basic forms of data to be operated on by many applications. The challenges of building an enterprise network fall into two distinct categories: getting the data (i.e., information) from A to B; and enabling B to understand the data when it receives it from A. These two categories are referred to in this article as the“networking challenge,” and the “beyond the networking challenge.” In this context, network is used as it is in the Open Systems Interconnection (OSI) reference model, that is, layer 3 and below. The Networking Challenge The networking part of the problem has three major components:

á Choosing from and integrating the many network technologies.

á Selecting from the many vendor solutions.

á Moving information from a local to a global environment. Network Technologies The first basic problem with networks is that there are so many of them. In this context, networks are taken to mean the raw network technologies—leased lines (i.e., T1 and T3), X.25, Integrated Services Digital Network, frame relay, Asynchronous Transfer Mode, and t he many and various LAN access methods. If all the users in an enterprise are connected to the same network technology, there is no problem. Unfortunately, this is never likely to be the case, and communication between users on dissimilar networks (e.g., two different LANs) is where the problem occurs. Each network technology has its own characteristics and inherent protocols. From an enterprise viewpoint, this is very bad news. For example, users connected to an X.25 network cannot easily be connected to those already connected to a LAN. How, for example, would the X.25 user indicate the destination's Media Access Control address, and vice-versa? X.25 networks understand only X.25 addresses, and LANs understand only MAC addresses. The differences between network technologies and native protocols almost invariably prevent their direct interconnection. Differences in addressing schemes present another difficulty. Addressing considerations alone will typically dictate the use of a Previous screen Network Interconnection Device at the point at which two network technologies come together. Exhibit 1 illustrates several network technologies, represented by N1,N2, N3,N4. Each of these technologies has its own native protocol (i.e., P1, P2,P3,P4).

The Interoperability Problem A way must be found to integrate all these disparate technologies into a single supernetwork, with globally uniform and globally understood characteristics and a single addressing scheme. This is achieved by operating an integrating, unifying protocol(shown in Exhibit 2 as Px), sometimes known as an protocol, over the top of all the possible basic communications networks. The (IP) of TCP/IP is one such protocol. The Connectionless Network Layer Protocol (CNLP)specified in the Open Systems Interconnection International Standard (IS) 8473 is another. Proprietary systems have their own internet protocols (e.g., Novell uses its Internetwork Packet eXchange and Banyan uses Vines).

The Interoperability Solution From the architectural standpoint, the technical term for such an internet protocol is independent convergence protocol(SNICP). The protocols used on real-world communications networks (e.g., leased lines, X.25, frame relay, LANs) are known as subnetwork access control protocols (SNACP). Readers interested in obtaining a more detailed technical understanding about the network layer architecture and principles of internetworking should consult IS 8648,Internal Organization of the Network Layer. The basic internetworking architecture is shown in Exhibit 3.

Network Layer Architecture Unification does not mean simplification. Two protocols operating over a given subnetwork still require two address schemes. Routing tables are then needed in the Network Interconnection Device to map the global enterprise address to the address to be used by the network interconnection device (NID) for the next link in the composite path. Exhibit 4 is a simplification of how the two addresses are used. In practice, the “next” address may be more complex, depending on the internetworking protocols under consideration. A network interconnection device (NID) of this type is called a .

Simplified View of Addressing

Vendor Solutions The second basic problem is that each system vendor has a vendor-specific idea of how to build the supernetwork—the type of supernetwork protocol, theglobal addressing scheme, and the internal routing protocols to be used. At worst, this leads to a multiprotocol network, which amounts to several separate operating in parallel over the same physical communications plant. Previous screen Previous screen Previous screen Previous screen An alternative to the multiprotocol network is to choose a single protocol for the Previous screen entire enterprise supernetwork. This inevitably requires finding techniques to accommodate the systems that do not inherently operate this chosen protocol. Such techniques include encapsulation (sometimes called tunneling) at the edges of the single-protocol network, or other techniques (e.g., transport service interfaces and application gateways). However, even with a single protocol, tunneling permits only the coexistence of incompatible systems; there can be little or no interaction between each of the tunneled applications. The major advantage of tunneling is that the core of the network is unified, optimizing network management and networking skills. The disadvantage is the effort required to set up the tunneling configurations at the edges. The best solution is for all vendors to use the same internet protocol. This solution is, however, some way off, and in the meantime some degree of multiprotocol networking must be tolerated. Many vendors do offer versions of their own internetworking protocols over tunneled TCP/IP. Thus, an appropriate choice for the enterprise network might be a dual-protocol network comprising the native routing of both IP (of TCP/IP) and OSI's Connectionless Network Layer Protocol. Going Global Many LAN-based systems include internal protocols that advertise the existence of various LAN-based servers. Such a protocol is sometimes known as a Service Advertising Protocol. Such protocol exchanges, frequently broadcast over the LAN, ensure that the availability and addresses of various servers are known throughout the LAN user community. This is useful when the geographic area is confined to a work group or a floor of a building; for example, the knowledge of a set of available printers is useful only in the area that has ready access to one of them. Thus local messages must be constrained to local environments by putting adequate filtering at the point of access to the wide area portion of the enterprise network. There is no point in telling a user on a LAN in New York that there is a printer available on a LAN in Seattle. Another global problem relates to the extra transit delay involved in transport over a WAN, particularly for nonroutable protocols. Many protocol stacks used in local environments do not contain a Network Layer protocol, in other words they have no routing layer. Such protocols cannot be routed directly in a router-based enterprise network. Where it is necessary for such an application to be networked outside a particular local environment, the local protocol stack must be encapsulated within an interworking protocol. Then it can be launched onto the wide area part of the enterprise network. Many of the local or nonroutable protocols are designed for very rapid acknowledgment. The transfer of these types of protocols across a wide area may cause problems; applications may prematurely time-out, or suffer poor throughput because of lack of a windowing mechanism adequate for the wide area transit delay. To accommodate such applications, it is necessary to “spoof” the acknowledgments. This means that acknowledgments must be generated by the local encapsulation device. This requires the extra complication of adding a reliable transport protocol on top of the internetworking protocol across the wide area portion of the enterprise network. Once a local acknowledgment has been given, the originator will discard the original so it is no longer available for retransmission. Having given the local acknowledgment, the spoofing device must ensure reliable delivery to the remote end by employing a transport protocol of some sort (e.g., Transmission Control Protocol or OSI Transport Class 4). The scheme is shown in Exhibit 5. This avoids the end-to-end round trip delay Tr for every packet of data, by providing an acknowledgment at time T1. Previous screen Previous screen Spoofing Going global also poses some challenges in the area of Network Layer addressing, particularly with regard to achieving enterprisewide uniqueness and structuring addresses for scaleability and ease of routing. Addressing Usually, addresses of stations within a local work group are allocated locally. This can present problems when subsequently the local work groups must be integrated into a single enterprisewide address scheme. If several work group addresses, or parts of an address (e.g., an area or server name), are the same, clearly some changes will have to be made. From an operational perspective, changing addresses is not a trivial matter. It is best to avoid address allocation clashes right from the outset by having an enterprisewide address registration authority set up within the organization. Some addressing schemes do have some hierarchy associated within them. This can be used to avoid address encoding clashes by ensuring that local addresses are only the low-order part of the total address. Even in this case, however, an enterprisewide perspective is necessary to avoid clashes in the high-order part of the address. Some vendors achieve uniqueness by allocating unique addresses when the equipment is shipped. However, this usually results in a flat, random address space that makes routing considerably more complex because there is no structure in the address to help“scale” the enterprise network from the routing perspective. If the enterprise network is to be interconnected to the Internet, IP addresses must be obtained from a central authority (i.e., the Internet SOCiety). This is not so simple either, because the Internet is running out of addresses and the form of an Internet address dictates to some extent the degree of scaling that is achievable. Furthermore, Internet addresses are not hierarchical in a meaningful way, because they are more or less randomly allocated. The most widely recognized and hierarchically administered address available today is the OSI address space available for OSI Network Service Access Point (NSAP) addresses. This permits an address of as many as 40 digits, which allows good scaling potential and simplified routing. The reason that a hierarchical (i.e., scaled) address scheme is so important has to do with the way that routers operate and the size of the associated routing tables. If addresses were allocated completely randomly, but uniquely from a large address space, every router would need a table with every address in it. Not only would the table be extremely large, but the time needed to find an entry could also be a problem. Routing is thus better arranged on the basis of hierarchical distinctions that are implicit in the address scheme. So, to service a local work group or other limited geographical area, a local router must know only whether the destination address is internal or external. If it is internal, the router knows how to get the message to the destination; if it is external, the router can pass it on to the next-level router. This leads to the concept of areas, groups of areas, domains, and countries being components of a hierarchical address. When legacy systems must be accommodated with conflicting address schemes and re-allocation of addresses is impossible, tunneling may have to be employed merely to avoid interaction between the conflicting addresses. Because conflicting networks are divided into separate Virtual Private Network, the protocol under consideration cannot be routed natively even if the backbone routers are capable of doing so. Routing Previous screen To reduce the amount of time devoted to setting up routing tables manually, and to allow dynamic rerouting and a degree of self-healing, routing protocols are often employed to distribute Routing Information throughout the enterprise network. These protocols are in addition to the internetworking protocol itself but are related to it. For every internetwork protocol routed in a multiprotocol network, there may be a specific routing protocol (or set of protocols). This also means in general that there will also be a separate routing table for each internetworking protocol. The situation in which several routing protocols are used simultaneously, but independently, is sometimes known as a “ships in the night” situation because sets ofrouting information pass each other and are seemingly oblivious to each other even though there is only one physical network. Some router manufacturers operate a single proprietary routing protocol between their own routers and convert to individual protocols at the edges of the network. There have been some attempts to define a single standard routing protocol based on the International Standards Organization's (ISO) Intermediate System to Intermediate System (IS-IS) standard. In an enterprise network, end systems (e.g., terminals, workstations, mainframes) usually announce their presence and their own addresses to the nearest local router. The local routers record all the local addresses within their area and inform all neighboring higher-level routers of their own area address. In this way, a router at the next and higher level in the hierarchy only needs to know about areas. Recursive application of these principles to a hierarchical configuration can lead to efficient routing by minimizing the amount of routing information to be transmitted and by keeping the size of routing tables small. As the process of promulgating routing information proceeds across the network, every router in the enterprise network will obtain a table of reachability that it can then use for choosing optimum routes. Route optimality may be based on a number of independent metrics (e.g., transmit delay, throughput, monetary cost). Invariably, a Shortest Path First algorithm is used to determine the optimal route for any particular metric chosen as the basis for routing. Both the Internet and OSI routing protocols use an shortest path first (SPF) algorithm. Routers Routers are the key interconnection devices in the enterprise network; subsequently, the router market has been one of the key growth areas during this decade. Some router vendors have grown from small $10 million companies to $1 billion companies. In most cases, routers are purpose-built communications processor platforms with hardware architectures specifically designed for high-speed switching. Several possible pitfalls await the unwary purchaser of routers. Such a purchase involves four important considerations:

á The capacity and architecture, in terms of the number of ports accommodated and throughput achievable.

á Internetwork protocols supported and their associated routing protocols.

á Support of technologies for the connected . á Interoperability between different vendors. Previous screen Capacity and Architecture The number of ports required determines to a large extent the size of the router required, which in turn affects the architecture and throughput of the router. Physical size of circuit boards dictates how many ports can be placedon a single board. The greater the number of ports, the greater the number of boards required and the more critical the architecture. Routing between ports on the same board is usually faster than routing between ports on different boards, assuming that there are on-board routing functions. Boards are usually interconnected by means of some kind of backplane. Backplane speeds can vary greatly between vendors. Routing functions and tables may be distributed across all boards or may be centralized. The bottom line is that the architecture affects the performance, and performance figures are sometimes slanted toward some particular facet of the architecture. Thus, some routers may be optimal for certain configurations and not so good for others. When making comparisons, the data communications manager must carefully analyze vendor throughput and transit delay figures. Although worst cases are helpful for the user and network designer, some vendors specify either the best cases or averages. Other metrics involved in measurement may also be different (e.g., packet size assumed, particular internetwork protocol, particular subnetwork). Other architectural considerations include extensibility and reliability. For example, is hot-swapping of boards possible? If the router must be powered down and reconfigured to change or add new boards, the disruption to a live network can have severe ripple effects elsewhere in the network. Can additional routing horsepower be added easily, as loads increase, by simply inserting an additional routing processor? The question of using standalone or hub-based routers may also be relevant. This is a difficult problem because of the traditional split between the hub and router manufacturers. Hub vendors tend not to be routing specialists, and router vendors tend not to be experts at hub design. Alliances between some vendors have been made, but the difference in form factors (of circuit boards) can result in some baroque architectures and poor performance. Except in the simple, low-end cases, purpose-built standalone routers usually perform better and are more easily integrated with the rest of the network. Some standalone routers can directly handle the multiplexed input streams from T1 and T3 links, making voice and data integration possible. This is unlikely to be the case for a hub that has been designed mainly for operation in a LAN. Many of the router manufacturers make several sizes of router, which could be referred to as small, medium, and large. All of one vendor's routers may, regardless of size, offer the same functions, but the circuit boards may not be interchangeable between the different models. This can make a big difference when it comes to stocking an inventory of spare parts. There may also be differences in network management capabilities. Internetwork Protocols Supported Most router vendors claim that they support a large number of internetworking protocols. In some cases, however, there may be restrictions on the number of protocols that can be supported simultaneously. There may also be restrictions on the use of multiple protocols over certain network technologies, or hidden subnetwork requirements. An example of the latter might be the need for a separate X.25 Permanent Virtual Circuit for every individual protocol, as opposed to operating all the protocols over a singlepermanent virtual circuit Previous screen (PVC). Some vendors may also use a proprietary routing protocol scheme for internal routing, only making the standard protocols available at the periphery of the network. This will make it difficult to mix different vendors' router products on the same backbone or within a single routing domain. Network Technologies Supported Most manufacturers provide interfaces to a large number of network technologies (e.g., X.25, Integrated Services Digital Network, frame relay, T1, T3, Ethernet, Token Ring). The method of support may also vary. For example, in the case of leased circuits, it may or may not be possible to directly connect the carrier's line to the router. Some routers may accept the carrier's framing mechanism directly, others may require an external converter to provide a simple serial interface (e.g., V.35) before connection can be achieved. As stated previously, however, the interaction between these interfaces and the multiple internetwork protocols may not be clearly reported by the vendor. Interoperability In general, there is little interoperability between routers from different vendors. The reason often cited is lack of standards for operating multiple protocols over a given subnetwork technology. There is a need in these cases to specify how the various protocols are encapsulated in the subnetwork protocol and how each protocol is to be separately distinguished. The only case in which interoperability may be more or less guaranteed is over a LAN, using OSI's Subnetwork Access Protocol(SNAP) identification scheme, so LANs are frequently used to interconnect islands of routers. An example is shown in Exhibit 6. Two islands of routers from different manufacturers, A and B, are interconnected over a LAN. This scheme works well when the respective backbone routers can be physically located near to an existing LAN cluster, as depicted by the dotted ellipse.

LAN Interconnect Approach Efforts are under way to improve standardization. For example, the Internet community has defined the Point-to-Point Protocol, designatedPPP, which defines encapsulation and discrimination methods for multiprotocol operation over leased circuits. Unfortunately, this standard is not fully complete with respect to many of the internetwork protocols already in existence. In theory, at some future date it will be possible to use PPP between a backbone comprising routers from one vendor and access routers from another vendor. An arrangement such as that shown in Exhibit 7 then could be configured. Such an arrangement may be practical now if the protocols routed are restricted to those that have been standardized for use with PPP.

Access Routers Approach Where no standard wide area interoperability solution can be used, an alternative for large numbers of access routers is a variation of the LAN interconnect technique. Use of this technique may increase the number of routers required (as shown in Exhibit 8) but may be Previous screen Previous screen Previous screen necessary where existing local islands that contain a set of routers of type R(B) must be Previous screen accommodated.

Access with LAN Interconnect A standard for using frame relay is also under development in the Internet community, and a generic standard for encapsulation and discrimination is under development by the International Standards Organization. The latter is intended for use over most subnetwork technologies. Network Management It is extremely unlikely that a common set of management features will apply to all vendors' routers. Thus, if several manufacturers' routers are deployed in a given enterprise network, several management systems probably will be required. In the best case, these systems can be run on the same hardware platform. In the worst case, different hardware platforms may be required. Filtering Filtering was mentioned in the context of preventing local traffic uselessly flooding the enterprise network. The degree of filtering that can be applied may vary with the manufacturer. Various parameters can be used as the basis for filtering, for example, source address, destination address, protocol type, and security codes. The disadvantage of using filtering is the labor involved in setting up the filter tables in all the routers. Beyond the Networking Challenge—The Applications All the considerations discussed so far apply to the internetworking protocols. Multiprotocol networks serve only to share bandwidth, they do not allow applications to interoperate. Where that is necessary, with completely different stacks of protocols, an application gateway must be used, as shown in Exhibit 9. Exhibit 9 shows an Open Systems Interconnection-based mail (X.400) application interoperating with aTCP/IP- based mail application, over an application gateway.

Mail Application Gateway Such gateways may be sited either centrally or locally. The use of local gateways makes it possible to deploy an application backbone with a single standard application operating over the wide area portion of the enterprise network (e.g., an X.400 mail backbone). This reduces the number of gateways needed for conversion between all the different applications. Only one conversion is necessary for each application (i.e., to the one used on the backbone). A considerable number of different local systems could interoperate through the“standard” backbone application. The encapsulation technique already mentioned in the context of IP tunneling allows all applications that can be so configured to operate across the enterprise network. A tunneled System Network Architecture application is shown in Exhibit 10. Previous screen Previous screen Tunneled SNA Application Previous screen Another solution that may help in the future is the availability of transport service interfaces for end systems (e.g., workstations, terminals, servers). A transport service interface allows a given application to be operated over any underlying communications protocol stack. In other words, applications and communications stacks can be mixed and matched as necessary. The so-called open operating systems(e.g., Portable Operating System Inferface for UNIX and X/Open) adopt this approach. The transport layer is a fundamental dividing line in the system architecture. Network-related functions are separate from application-related functions, so that applications work with many communications protocols. Exhibit 11 shows an end system containing both an open OSI/TCP/IP stack (shaded) and a proprietary stack (unshaded). Within an end system, protocol stacks can generally be separated into the communications- specific lower-layer parts and the application-specific upper-layer parts. The two stacks communicate through a Transport Layer Interface.

Transport Layer Interface

Conclusions Setting up an enterprise network rarely involves starting with a blank piece of paper. In practice, legacy systems or other requirements result in the existence of a variety of heterogeneous systems. Several techniques can be applied to, at least, make the heterogeneous systems networkable over a single physical network. Varying degrees of interoperability between them may also be possible. This article has addressed only the bare essentials of enterprise networking. The subject is highly technical. Setting up a large enterprise network is not for the fainthearted. The pitfalls are many and are difficult to anticipate because of vendors' exaggerations and sheer technical complexity. For the moment, a single “pure” multivendor network is out of reach. A successful convergence of the ISO's Connectionless Network Layer Protocol and the next generation IP into a single common internetworking protocol would be a tremendous advance. A project within the Internet SOCiety, known as Transmission Control Protocol and UPD with Bigger Addresses (TUBA), is currently focusing on this issue. However, it is essential to create an enterprise network architecture. An overall plan for the network will minimize confusion and put in place a timed migration strategy toward a completely integrated network. Central control has lately fallen into disrepute, but without some control over how networking is to be achieved, all the real benefits of an enterprise network will not be realized. Finally, it is probably fair to say that enterprise networking is still something of a black art and is bound to present all data communications managers with some surprises and disappointments. Author Biographies Keith G. Knightson Keith G. Knightson is associate director of the Telecom Architect program at Canada's Government Telecommunications Agency. He has had extensive data communications and system experience in both the public and private sectors, having worked for Gandalf Data Ltd., Bell Northern Research, and the United Kingdom Department of Trade and Industry.