A GUIDE TO TCP/IP INTERNETWORKING

Standard HTML 4.01 document

RFC Index: www.c-extra.com

Origin: Rutgers University

APPENDIX: Selected Readings

Clic on the article:

      •  Douglas Comer: "Internetworking with TCP/IP", Prentice-Hall, 1991.
      •  Salvatore Salamone: "OSPF routing: Better but not good enough", Data Communications, October 1992.
      •  Todd Tannenbaum: "The Point-to-Point Protocol", Communications Week, January 1994.
      •  Chip Sparling: "Plugging into TCP/IP with Windows Sockets", Data Communications, October 1993.
      •  John Windham: "APPN and TCP/IP: Plotting a backbone strategy", Data Communications, March 1994.
      •  Steven King: "The enterprise network: Backbone or black hole?", Data Communications, January 1993.
      •  Robin Layland: The end of IP as we know it, Data Communications, October 1994.
      •  John Till Johnson: Doubts about IPng could create TCP/IP chaos, Data Communications, November 1994

Douglas Comer: "Internetworking with TCP/IP", Prentice-Hall, 1991.

Vector Distance (Bellman-Ford) Routing
The term vector-distance refers to a class of algorithms routers use to propagate routing information. The idea behind vector-distance algorithms is quite simple. We assume that each router begins with a set of routes for those networks to which it attaches. It keeps the list of routes in a table, where each entry identifies a destination network and gives the distance to that network measured in hops. Table below is an initial vector-distance routing table for a router K with an entry for each directly connected network. Entries contain the IP address of a network and an integer distance to that network.
A routing table
Destination
Distance
Route
Net 1
0
direct
Net 2
0
direct

Periodically, each router sends a copy of its routing table to any other router it can reach directly. When a report arrives at router K from router J, K examines the set of destinations reported and the distance to each. If J knows a shorter way to reach a destination, or if J lists a destination that K does not have in its table, or if K currently routes to a destination through J and J's distance to that destination changes, K replaces its table entry. For example, table below shows (a) an existing table in router K, and an update message (b) from another router J. The marked entries ( will be used to update existing entries or add new entries to K's table.

                                Updating routing table

        Destination    Distance    Route             Destination    Distance
        Net  1            0        direct            Net  1             2
        Net  2            0        direct     -->    Net  4             3
        Net  4            8        router L          Net 17             6
        Net 17            5        router M   -->    Net 21             4
        Net 24            6        router J          Net 24             5
        Net 30            2        router Q          Net 30            10
        Net 42            2        router J   -->    Net 42             3

-------------------------------------------------------------------------
                 (a)                                 (b)

Note that if J reports distance N, an updated entry in K will have distance N+1 (the distance to reach the destination from J plus the distance to reach J). Of course, the routing table entries contain a third column that specifies a route. Initial entries are all marked direct dellvery. When router K adds or updates an entry in response to a message from router J, it assigns router J as the route for that entry. The term vector-distance comes from the information sent in the periodic messages. A message contains a list of pairs (V,D), where V identifies a destination (called the vector) and D is the distance to that destination. Note that vector-distance algorithms report routes in the first person (i.e., we think of a router advertising: "I can reach destination V at distance D"). In such a design, all routers must participate in the vector-distance exchange for the routes to be efficient and consistent. Although vector-distance algorithms are easy to implement, they have disadvantages. In a completely static environment, vector-distance algorithms propagate routes to all destinations. When routes change rapidly, however, the computations may not stabilize. When a route changes (i.e. a new connection appears or an old one fails), the information propagates slowly from one router to another. Meanwhile, come routers may have incorrect routing infonnation.

Link-State (SPF) Routing
The main disadvantage of vctor-distance algorithms is that they do not scale well. Besides the problem of slow response to change mentioned earlier, the algorithm requires large message exchanges. Because routing update messages contain an entry for every possible network, message size is proportional to the total number of networks in an internet. Furthermore, because a vector-distance protocol requires every router to participate, the volume of information exchanged can be enormous. The primary aItemative to vector-distance schemes is a class of algorithms known as link state, Shortest Path First, or SPF. The name "shortest path first" is an unfortunate misnomer, because most route computations choose shortest paths. However, it seems to have gained wide acceptance.

SPF algorithms require each participating router to have complete topology info rmation. The easiest way to think of the topology information is to imagine tbat every router has a map that shows all other routers and the networks to which t hey connect. In abstract terms, the routers correspond to nodes in a graph and n etworks that connect routers correspond to edges. There is an edge (link) between two nodes if and only if the corresponding routers can communicate directly. Instead of sending messages that contain lists of destinations, a router participating in an SPF algorithm performs two tasks. First, it actively tests the status of all neighbor routers. In terms of the graph, two routers are neighbors if they share a link; in network terms, two neighbors conneet to a common network. Second. it periodically propagates the link status information to all other routers. To test the status of a directly conneeted neighbor, a router periodically exchanges short messages that ask whether the neighbor is alive and reachable. If the neighbor replies, the link between them is said to be "up". Otherwise, the link is said to be "down". In practice, to prevent oscillations between the up and down states, most protocols use a k-out-of-n rule to test liveness, meaning that the link remains up until a significant percentage of requests have no reply, and then it remains down until a significant percentage of messages receive a reply. To inform all other routers, each router periodically broadcasts a message that lists the status (state) of each of its links. The status message does not specify routes; it simply reports whether communication is possible between pairs of routers. Protocol software in the routers arranges to deliver a copy of each link status message to all participating routers (if the underlying networks do not support broadcast, delivery is done by forwarding individual copies of the message point-to-point). Whenever a link status message arrives, a router uses the information to update its map of the internet by marking links "up" or "down". Whenever link status changes, the router recomputes routes by applying the well-known Dijkstra's shortest path algorithm to the resulting graph. Dijkstra's algorithm computes the shortest paths to all destinations from a single source.

One of the chief advantages of SPF algorithms is that each router computes routes independently using the same original status data; they do not depend on the computation of intermediate machines. Because link status messages propagate unchanged, it is easy to debug problems. Because routers perform the route computation locally, it is guaranteed to converge. Finally, because link status messages only carry information about the direct connections from a single router, the size does not depend on the number of networks in the internet. Thus, SPF algorithms scale better than vector-distance algorithms.

Routing Information Protocol (RIP)

RIP is one of the most widely protocol, also known by the name of a program that implements it, "routed". The routed software was originally designed at the University of California at Berkeley to provide consistent routing and reachability information among machines on their local networks. It relies on physical network broadcast to make routing exchanges quickly. It was never intended to be used on large, long haul networks (although it now is). The popularity of RIP does not arise from its technical merits. Instead, it is the result of Berkeley distributing routed software along with their popular 4BSD UNIX systems. Thus, many TCP/IP sites adopted and installed routed and started using RIP without even considering its technical merits or limitations. Once installed and running, it became the basis for local routing, and research groups adopted it for larger networks. Perhaps the most startling fact about RIP is that it was built and widely adopted before a formal standard was written. Most implementations were derived from the Berkeley code, with interoperability among them limited by the programmer's understanding of undocumented details and subtleties. As new versions appeared, more problems arose. An RFC standard finally appeared in June 1988 (RFC 1058).

The underlying RIP protocol is a straightforward implementation of vector-distance routing for local networks. It partitions participants into active and passive (silent) machines. Active routers advertise their routes to others; passive machines listen and update their routes based on advertisements, but do not advertise. Typically, routers run RIP in active mode, while hosts use passive mode. A router running RIP in active mode hroadcasts a message every 30 seconds. The message contains information taken from the router's current routing database. Each message consists of pairs where each pair contains an IP network address and an integer distance to that network. RIP uses a "hop count metric" to measure the distance to a destination. In the RIP metric, a router is defined to be one hop from directly connected networks, two hops from networks that are reachable through one other router, and so on. Thus, the number of hops or the hop count along a path from a given source to a given destination refers to the number of routers that a datagram encounters along that path. It should be obvious that using hop counts to calculate shortest paths crosses three Ethernets may be substantially faster than a path with hop count 2 that crosses two slow speed serial lines. To compensate for differences in technologies, many RIP implementations use artificially high hop counts when advertising connections to slow networks.

Both active and passive RIP participants listen to all broadcast messages and update their tables according to the vector-distance algorithm described earlier. For example, in the internet of figure below, router R1 will broadcast a message on network 2 that contains the pair (1,1), meaning that it can reach network 1 at cost 1. Routers R2 and R5 will receive the broadcast and install a route to network 1 through R1, (at cost 2). Latert routers R2 and R3 will include the pair (1,2) when they broadcast their RIP messages on network 3. Eventually, all routers and hosts will install a route to network 1.

                                           Net 1
                                         ________ ________
                                                 |
                                              ___|___
                                             |       |
                                             |  R 1  |
                                             |___ ___|
                           Net 2                 | 
 ________ _______________________________________|_________________
         |
      ___|___
     |       |
     |  R 2  |
     |___ ___|
         |                 Net 3
 ________|________________________ ________________________ ________
                                  |                        |    
                               ___|___                  ___|___ 
                              |       |                |       |
                              |  R 3  |                |  R 4  |
                              |___ ___|                |___ ___|
                                  |                        |    
                          ________|________        ________|________

                                     An Internet for RIP

RIP specifies a few rules to improve performance and reliability. For example, once a router learns a route from another router, it must keep that route until it learns of a better one. In our example, if routers R2 and R3 both advertise network 1 at cost 2, routers R3 and R4 will install a route through the one that happens to advertise first. We can summarize: "To prevent routes from oscillating between two or more equal-cost paths, RlP specifes that existing roules should be retained until a new route has strictly lower cost".

What happens if the first router to advertise a route fails (e.g., if it crashe s)? RIP specifies that all listeners must timeout routes they learn via RIP. Whe n a router installs a route in its table, it starts a timer for each route. The timer must be restarted whenever the router receives another RIP message advertising the route. The route becomes invalid if 180 seconds pass without the route being advertised again. RIP must handle three kinds of errors caused by the underlying algorithm. First, because the algorithm does not explicitly detect routing loops, RIP must either assume participants can be trusted or take precautions to prevent such loops. Second, to prevent instabilities RIP must use a low value for the maximum possible distance (RIP uses 16). Thus, managers must use an alternative protocol for internets in which legitimate hop counts approach 16. (Indeed, the small limit on hop counts makes RIP unsuitable for the largest corporate internets). Third, the vector-distance algorithm used by RIP creates a slow convergence or count to infinity problem in which inconsistencies arise, because routing update messages propagate slowly across the network. Choosing small infinity (16) helps limit slow convergence, but does not eliminate it. Routing table inconsistency is not unique to RIP. It is a fundamental problem that occurs with any vector-distance protocol in which update messages carry only pairs of destination network and distance to that network. To understand the problem consider the set of routers shown in figure below, which depicts routes to network 1 for 3 LANs. As the figure shows, router R1 has a direct connection to network 1, so it has a route in its table with distance 1; it includes the route in its periodic broadcasts. Router R2 has learned the route from R1 installed the route in its routing table, and advertises the route at distance 2. Finally, R3 has learned the route from R2 and advertises it at distance 3. Now suppose that R1's connection to network 1 fails. R1 will update its routing table immediately to make the distance 16 (infinity). In the next broadcast, R1 will report the higher cost route.

                 ________         ________         ________
                |        |       |        |       |        |
Network 1 <---- |   R1   | <---- |   R2   | <---- |   R2   |
                |________|       |________|       |________|

                     Advertising Routes

However, unless the protocol includes extra mechanisms to prevent it, some other router could broadcast its routes before R1. In particular, suppose R2 happens to advertise routes just after R1's connection fails. If so, R1 will receive R2's message and follow the usual vector-distance algorithm: it notices that R2 has advertised a route to network 1 at lower cost, calculates that it now takes 3 hops to reach network 1 (2 for R2 to reach network 1 plus 1 to reach R2), and installs a new route through R2. Figure below depicts the result.

                 ________         ________         ________
                |        | <---- |        |       |        |
Network 1       |   R1   |       |   R2   | <---- |   R2   |
                |________| ----> |________|       |________|

                    RIP with link failure

At this point, if either R1 or R2 receives a datagram destined for network 1, they will route the datagram back and forth until its time-to-live counter expires. Subsequent RIP broadcasts by the two routers do not solve the problem quickly. In the next round of routing exchanges, R1 broadcasts its routing table entries. When R2 learns that R1's route to network 1 has length 3, it calculates a new length for its route, making it 4. In the third round, R1 receives a report of the increase from R2 and increases the distance in its table to 5. They continue counting to RIP infinity.

For the previous example, it is possible to solve the slow convergence problem by using a teehnique known as split horizon update. When using split horizons, a router records the interface over which it received a particular route and does not propagate its information about that route back over the same interface. In the example, router R2 would not advertise its length 2 route back to router R1, so when R1 loses connectivity to network 1, it would stop advertising a route. After a few rounds of routing updates, all machines would agree that the network is unreachable. However, splitting the horizon does not cover all topologies. Another way to think of the slow convergence problem is in terms of information flow. If a router advertises a short route to some network, all receiving routers respond quickly to install that route. If a router stops advertising a route, the protocol must depend on a timeout mechanism before it considers the route unreachable. Once the timeout occurs, the router finds an alternative route and starts propagating that information. Unfortunately, a router cannot know if the alternate route depended on the route that just disappeared. Thus, negative information does not always propagate quickly. A short epigram captures the idea and explains the phenomenon: "Good news travels quickly; bad news travels slowly".

Another technique used to solve the slow convergence problem employs hold do wn. Hold down forces a participating router to ignore information about a ne twork for a fixed period of time following receipt of a message that claims the network is unreachable. Typically. the hold down period is set to 60 seconds. Th e idea is to wait long enough to ensure that all machines receive the bad news a nd not to mistakenly accept a message that is out of date. It should be noted th at all machines participating in a RIP exchange need to use identical notions of hold down, or routing loops can occur. The disadvantage of a hold down techniqu e is that if routing loops occur, they will be preserved for the duration of the hold down period. More important, the hold down technique preserves all incorrect routes during the hold down period, even when alternatives exist. A final technique for solving the slow convergence problem is called poison reverse. Once a connection disappears, the router advertising the connection retains the entry for several update periods, and includes an infinite cost in its broadcasts. To make poison reverse most effective, it must be combined with triggered updates. Triggered updates force a router to send an immediate broadcast when receiving bad news, instead of waiting for the next periodic broadcast. By sending an update immediately, a router minimizes the time it is vulnerable to believing good news. Unfortunately, while triggered updates, poison reverse, hold down and split horizon techniques all solve some problems, they introduce others. Por example, consider what happens with triggered updates when many routers share a common network. A single broadcast may change all their routing tables, triggering a new round of broadcasts. If the second round of broadcasts changes tables, it will trigger even more broadcast. A broadcast avalanche can result. The use of broadcast, potential for routing loops, and use of hold down to prevent slow convergence can make RIP extremely inefficient in a wide area network. Broadcasting always takes substantial bandwidth. Even if no avalanche problems occur, having all machines broadcast periodically means that the traffic increases as the number of routers increases. The potential for routing loops can also be deadly when line capacity is limited. Once lines become saturated by looping packets, it may be difficult or impossible for routers to exchange the routing messages needed to break these loops. Also, in a wide area network, hold down periods are so long that the timers used by higher level protocols can expire and lead to broken connections. Despite these well known problems, many groups continue to use RIP in wide area networks.

The Open SPF Protocol (OSPF)
We said that the SPF route propagation algorithm scales better than vector distance algorithms. A working group of the Internet Engineering Task Force has proposed a new interior router protocol that uses the SPF algorithm. Called the Open SPF Protocol, the new protocol tackles several ambitious goals:
•  The specification is available in the published literature, making it an open standard that anyone can implement without paying license fees. The specification authors hope many vendors will support OSPF and make it a popular standard that replaces proprietary protocols.
•  OSPF includes type of service routing. Managers can install multiple routes to a given destination, one for each type of service (e.g., Iow delay or high throughput). When routing a datagram, a router running OSPF uses both the destination addrss and type of service fields in an IP header to choose a route. OSPF is among the first TCP/IP protocols to use type of service routing.
•  OSPF provides load balancing. If a manager specifies multiple routes to 3 given destination at the same cost, OSPF distributes traffic over all routes equally. Again, OSPF is among the first open IGPs to offer load balancing; protocols like RIP compute a single route to each destination.
•  To permit growth and make the networks at a site easier to manage, OSPF allows a site to partition its networks and routers into subsets called areas. Each area is self-contained; knowledge of an area's topology remains hidden from other areas. Thus, multiple groups within a given site can cooperate in the use of OSPF for routing even though each group retains the ability to change its internal network topology independently.
•  The OSPF protocol specifies that all exchanges between routers are authenticated. OSPF allows a variety of authentication schemes, and even allows one area to choose a different scheme than another area. The idea behind authentication is to guarantee that only trusted routers propagate routing information. To understand why this might be a problem, consider what can happen when using RIP, which has no authentication. If a malicious person uses a personal computer to propagate RIP messages advertising low-cost routes, other routers and hosts running RIP will change their routes and start sending datagrams to the personal computer.
•  OSPF supports host-specific routes as well as network-specific routes. It also supports subnet routes.
•  To accommodate multi-access networks like Ethernet, OSPF extends the SPF algorithm described above. We described the algorithm using a point-to-point graph an said that each router running SPF would periodically broadcast link status messages ahout each reachable neighbor. If K routers attach to an Ethernet, they will broadcast K2 reachability messages. OSPF minimizes broadcasts by allowing a more complex graph topology in which every multi-access network has a designated router that sends link-status messages on behalf of all routers on the net. It also uses hardware broadcast capabilities, where they exist, to deliver link status messages.
•  To permit maximum flexibility, OSPF allows managers to describe a virtual network topology that abstracts away from details of physical connections. For example, a manager can configure a virtual link between two routers in the routing graph even if the physical connection between the two routers requires communication across a transit network.
•  OSPF allows routers to exchange routing information learned from other (external) sites. Basically, one or more routers with connections to other sites learn information about those sites and include it when sending update messages. The message format distinguishes between information acquired from external sources and information acquired from routers interior to the site, so ther is no ambiguity about the source or reliability of routes.

Salvatore Salamone: "OSPF routing: Better but not good enough", Data Communications, October 1992.

The open shortest path first (OSPF) routing protocol, expected by many to be th e predominant router-to-router protocol for years to come, now appears destined to fill only a limited role in LAN internetworking. Although it is a marked impr ovement over the routing information protocol (RIP) it is intended to replace, OSPF has critical weaknesses that will keep it from serving as the linchpin protocol in large internetworks. In fact, even as router vendors roll out OSPF offerings, developers are working on next-generation protocols that address issues that OSPF can't handle. OSPF has two main drawbacks when it comes to large internetworks: It handles only internet protocol (IP) traffic, and its routing algorithm isn't powerful enough for the larger internetworks envisioned by many corporate network managers. Because of these limitations, OSPF is likely to settle in as a complementary routing protocol in LAN internetworks. The internetworking scenario now envisioned by many network planners has routing protocols such as OSPF, RIP, and Cisco Systems Inc.'s IGRP handling traffic in specific segments, or domains, in a larger internetwork. These domains will be linked by protocols built specifically to handle interdomain traffic. One such protocol, the exterior gateway protocol (EGP), has been in use on the Internet since 1984. The Internet Engineering Task Force (IETF) is now developing a replacement for EGP, called the border gateway protocol (BGP). BGP uses a new type of algorithm to make routing decisions. This algorithm, the policy-based algorithm, enables network managers to factor a wider range of information into the routing process. With policy-based algorithms, for example, routers can take into account such factors as the relative importance of network traffic in determining paths through the network. The possibility also exists that tomorrow's routing protocols will be based on proprietary technology. One proprietary protocol worth watching is Digital Equipment Corp.'s Integrated IS-IS, which is based on the OSI intermediate system-to-intermediate system (IS-IS) protocol. DEC's Integrated IS-IS is one of the few routing protocols that can handle both intradomain and interdomain routing.

PROTOCOL SHIFT. Despite the inherent limitations in OSPF, significant num bers of users are installing the routing protocol, according to router makers. S ome vendors report that as many as 30 percent of their customers are using OSPF, even thoughmost vendors are just now getting around to offering OSPF implementa tions. Proteon Inc. introduced the first OSPF router two years ago, and others h ave joined the market since. Cisco Systems and Wellfleet Communications have bee n shipping OSPF routers for more than a year. The interest in OSPF reflects the fact that corporate internetworks are fast outgrowing RIP. The main difference b e tween OSPF and RIP is the type of algorithm each uses to determine the optimal network path between two nodes. RIP uses a distance-vector algorithm; OSPF is b ased on a link-state algorithm. Link-state protocols outperform distance-vector protocols in a number of ways. With distance-vector protocols such as RIP, the m ain factor that determines the optimal network path is the number of hops. This means, for instance, that a six-hop link always will be selected over a seven-ho p link, even if the latter uses higher-bandwidth connections that can send the d ata more rapidly. Link state protocols take factors such as link speed into cons ideration when determining optimal paths. Link-state algorithms also calculate o ptimal paths faster than distance vector algorithms and use much less bandwidth when exchanging routing-table in formation. Distance-vector routers share inform ation with neighboring routers about network destinations and the distance to th ose destinations. Routers do not store entire paths in their tables; they record only the next hop on the way to the destination. Through repeated exchanges of routing tables between neighboring routers, all routers on a network eventually know how to reach every destination. RIP routers are limited to 15 hops; OSPF, i n contrast, can accommodate many more hops (the theoretical limit is 1,024, alth ough the practical limit is lower). Link-state protocols such as OSPF do not bro adcast entire routing tables at regular intervals. Instead, they broadcast advis ories containing information about changes in the links in the internetwork. The information garnered from these advisories is used to build a link-state data b ase that contains information about all destinations and paths on the inter netw ork. Once all routers have the same link-state database, each router builds its own routing table. Link-state advisories are broadcast only when a change occurs in the network. Typically, the time between broadcasts is about 30 minutes. Wha t's more, only the changes are broadcast, rather than entire routing tables. Thi s results in some dramatic bandwidth savings. Routers using RIP may exchange 10 Mbytes of routing information every 30 seconds for a moderately sized network. W ith OSPF, a 76-byte packet containing a new path would be transmitted only when a change in the network has occurred. Link-state algorithms do require more rout er processing power and memory than distance-vector algorithms. The time it take s to calculate shortest paths using a link-state algorithm is proportional to th e number of routers. Doubling the number of routers on an internetwork (or conne cting one internetwork with an other to double the number of routers), doubles t he amount of time it takes to calculate the paths. More memory is needed because the link-state database grows with the size of the internetwork. Unlike RIP, OS PF allows for network load sharing: When two paths between two nodes are deemed to be of equal value, OSPF allows both links to be used to send data. Another ke y advantage that OSPF holds over RIP is that OSPF offers routing based on upper- layer types of service (TOS). That enables the router to calculate separate sets of routes based on relative throughput, reliability, and delay in each link. OS PF contains three IP TOS bits, one for each of these parameters. Network managers can set these bits to produce up to eight separate routing tables. For example, one table could calculate a path for low delay, high throughput, and high reliability. Such criteria might send the data over a T1 circuit instead of a slower link, or it might route traffic over a more reliable, but more expensive, circuit. Despite all these advantages, OSPF comes up short on two key counts. It handles only IP traffic, which means it cannot be used with such common proprietary LAN protocols as Internet Packet Exchange (IPX) from Novell and Appletalk from Apple Computer. Neither can OSPF handle traffic from OSI's connectionless network protocol (CLNP), which may replace IP on the Internet. Although OSPF can handle bigger networks than RIP, the practical limit on OSPF network hops is a concern for larger internetworks. The limit depends on how often changes occur in the network, the complexity of the paths within the network, and the time it takes to calculate new paths. The larger the network and the more complicated the routing paths, the longer it takes to calculate the paths. If changes occur faster than the time it takes for paths to be calculated, the network cannot function properly. Because of these limitations, many users have been reluctant to replace their RIP routers with OSPF gear. One distance-vector protocol that continues to score high marks with users is Cisco's IGRP. In terms of functionality, IGRP falls somewhere between RIP and OSPF. Cisco's protocol can make routing decisions based on factors other than the number of network hops, such as internetwork delay, available bandwidth, traffic load, reliability, and the maximum packet size for a link. Like OSPF, IGRP permits multipath routing to a destination so that packets can take more than one path to reach a destination if the paths have equal value in terms of length, bandwidth, reliability, and delay.

ALTERNATIVES FROM NOVELL AND DEC. Besides IGRP, two other proprietary pro tocols have garnered the interest of network managers. Novell is developing a pr oprietary link-state protocol for routing IPX. The new protocol is called Netwar e Link State Protocol (NLSP). Novell will not say much about NLSP except that th e OSI IS-IS protocol may be a technology source for NLSP. The other proprietary protocol worth watching is DEC's Integrated IS-IS. DEC's protocol uses a link-st ate algorithm based on the OSI IS-IS routing protocol standard. While Integrated IS-IS is proprietary, the University of Wisconsin has developed an implementati on of the protocol that is available via the Internet. Integrated IS-IS handles both IP and OSI routing protocols and DECnet. DEC also may bring other protocols into the fold, including IPX and Appletalk. As internetworks grow, even the fas test converging, most efficient protocol will not be able to assimilate informat ion about the entire internetwork. Rather than try to accomplish the virtually i mpossible, developers are now focusing efforts on dividing the internetwork into smaller areas (domains) that are then connected to one another. Specific router s within a given domain are assigned to link to similar routers in other domains . These routers get updates from their counterparts in other domains to determin e the best path for data moving from one domain to another. The use of domains i n internetworks offers several big advantages. For one, the intradomain routing tables in a given domain are not affected by changes in other domains. If a rout er is added to one site, this information does not have to be relayed back to ev ery router in every site. Only the routers responsible for interdomain routing w ould need this information. This helps cut routing table calculations considerab ly. Within each domain, network managers can set routing policies specific to th at domain. For instance, a site that is using OSPF routing can set TOS bits to u se less costly, less reliable routes to handle what has been determined to be lo w-priority traffic. At another site in the same inter network, RIP routers can b e used for non-IP traffic. The corporate backbone that connects these sites may be administered by yet another set of criteria. As noted, OSPF's use of TOS enab les managers to base routing selections on reliability, delay, and throughput va riables. But there are other factors that could affect routing decisions, such as source and destination address restrictions, time of day, authentication requirements, and actual link charges. Policy based algorithms enable routers to make routing decisions based on this type of information. Routers that exchange this type of information with routers in other domains must run interdomain routing protocols. Since 1984, the exterior gateway protocol has been the most common interdomain routing protocol used on the Internet. EGP is used for communications between the core Internet routers that form the Internet's backbone. EGP has very limited policy-based functions. It allows domains to define portions of their connectivity databases that can be shared, but it does not allow the use of TOS options in other domains. EGP updates are sent to neighboring routers at regular intervals. In the update, each router tells the other which networks it is directly connected to. This "reachability" information is used to calculate routing paths. To bring interdomain protocols in line with more sophisticated internetworking requirements, the IETF has developed a new interdomain routing protocol, the border gateway protocol. BGP uses IP as its transport protocol and it communicates with BGP peer routers, which can either be within the same domain or in another domain. The primary role of BGP is to exchange network reachability information vtith other BGP routers. The reachability information includes such things as the full path that a packet must traverse to reach a network. BGP is expected to replace EGP as the main interdomain protocol on the In ternet. It addresses some of EGP's shortcomings. For example, it uses policy criteria to determine the best path. Many router vendors now have development programs for BGP under way. BBN Communications, Cisco, Proteon and Wellfleet all are working on or have developed implementations of the IETF's third version of the BGP standard.

Todd Tannenbaum: "The Point-to-Point Protocol", Communications Week, January 1994.

Using PPP, you effectively transform a PC or workstation's serial port and attached modem into a network adapter. This is a substantial conceptual departure from what most people think of as dial-up computing. It's important to understand the difference. One type of remote computing is limited to file transfer and text character terminal emulation. Examples include many PC remote control programs, such as Symantec Corp.'s Norton pcANYWHERE and Microcom's Carbon Copy, and various X-Window over serial line solutions incorporating Network Computing Devices' XRemote or Tektronix's Serial Xpress. These terminal emulators all perform the same function: They transfer keyboard and screen information from one machine to another. The application still runs on the remote host. In contrast, remote protocol implementations, such as PPP and Novell's Remote Shell, actually send network packets, or datagrams, just as a local workstation or router would. A machine equipped with a modem and connected to a remote office LAN with PPP can behave identically to a machine located on the office network. But, like everything else in life, there is a catch: even today's fastest modems operate at a fraction of the speed of local networks, and loading remote programs over dial-up links can take a long time. When using PPP, it is best to place commonly uses programs in a local disk and make sure this directory is in a PC's PATH first. Even strictly licensed software can be accommodated, since employees could install any company-owned commercial software on their home machines, but the software would not run unless it could "check out" a license from the company network. By using PPP to extend the network into the home so that the company software metering server can be connected transparently, these packages can run equally well at home and in the office.

In addition to connecting a workstation to a remote LAN, PPP can be used to form an internetwork, connecting multiple remote LANs to each other. Using PPP over ordinary phone lines can provide an enterprise-wide network solution, potentially at a fraction of the cost of using leased lines or public data networks. Of course, a single PPP link can be agonizingly slow for loading large programs, but is useful for many lower-bandwidth uses, such as electronic mail, news, infrequent client/server database lookups, software license authentication, terminal-style logins and remote system administration (for example, SNMP and RCONSOLE). Dial-up routers from such vendors as Telebit and Cisco Systems support PPP, and some of these products support load-balancing over multiple dial-up lines ta improve performance. Perhaps less dramatic but still very useful, is PPP's ability to connect a workstation to a workstation. For instance, Unix workstation-to-workstation connections traditionally have involved the use of Unix-to-Unix Copy (UUCP). But PPP has many advantages over UUCP, including full-duplex support (sending data in both dircctions simultaneously) and full TCP/IP support, instead of simply shuffling mail and news. Finally, PPP is growing in popularity for Internet access.

The Point-to-Point Protocol consists of a method of encapsulating datagrams on serial lines, as well as a set of subprotocols and mechanisms to negotiate confi guration information dynamically. PPP encapsulation is based on High-Level Da ta Link Control (HDLC), an ISO standard, with a few modifications. The delim iter field is used to mark the start and end of packet. The address and control fields are basically leftover from HDLC, and upon establishing the link, PPP wi ll use Link Control Protocol (LCP) to negotiate to drop these fields. PPP supports multiple network-layer protocols simultaneously, and the protocol fiel d indicates which network-layer protocol should be used to interpret the data fo und in the Information field. For instance, the protocol field may indicate that the information field contains an IP, IPX or AppleTalk packet, or a packet spec ific to a PPP-protocol, such as LCP or Password Authentication Protocol ( PAP). The Information field is variable in length, growing up to a negotiated Maximum Receive Unit (MRU) size. All PPP packets contain a checksum stored in the Frame Check Sequence (FCS) field. The FCS field is calculated over the entire packet (excluding the delimiter and FCS field itself) and thus guard s against corrupted data due to faults, such as noisy phone lines. By default on ly 8 additional bytes are required for encapsulation, and, with typical header c ompression negotiated, this is reduced to 4 bytes. The establishment of a PPP co mmunications link follows a predefined procedure. Once the physical layer has ma de a connection (for instance, two modems have linked successfully), the two PPP nodes send each other a small flurry of LCP packets to configure the data link. If either end of the link requests authentication, PPP negotiates using either PAP or the Challenge Handshake Authentication Protocol (CHAP). PAP sends an ID/password pair, and the end of the link requesting authentication either gr ants or refuses access. But PAP is not secure: passwords are sent in clear text and can fall victim to record-and-playback attacks even if they are encrypted. B y comparison, CHAP relies on a "secret" known only to the authenticator and legi timate users. The secret is never sent over the link. Instead, with CHAP authent ication, the authenticator sends a "challenge" message to the other end of the l ink, which responds by taking that message and applying a one-way hash function that incorporates the secret. The authenticator then compares the response against its own calculation of the expected answer; if they differ, the link is terminated. Furthermore, the authenticator can periodically (with a frequency and timing of its own choosing) rechallenge the other end of the link. Repeated and differing challenges provide protection against record-and-playback attacks. After successful authentication, PPP exchanges Network Control Protocol (NCP) packets. Each network layer protocol supported by PPP has a corresponding NCP, such as Internet Protocol Control Protocol (IPCP), ATCP (AppleTalk), IPXCP (Novell's IPX) and DNCP (DECnet Phase IV). NCPs take care of negotiating whatever configuration options are required by their respcctive network layers. For example, the IPCP NCP Configuration Options allow for dynamic assignment of IP address and agreement on whether or not to use Van Jacobson (VJ) TCP/IP header compression. The VJ algorithm takes advantage of the fact that only a few bytes in the TCP/IP header actually change from one packet to the next in a TCP connection. VJ compresses the TCP/IP header at the start of every TCP/IP packet from its typical 40 bytes down to an average 3 or 4 bytes, significantly improving interactive performance over slower modems. By using saved-state information, only the bytes that change need to be transferred. Work is under way to develop VJ compression for IPX packets as well, and an option for VJ header compression of IPX packets is expected to make its way into the still-awaited IPXCP. NCP is a good example of PPP's extensibility; allowing PPP to support future network-layer protocols effectively requires implementation of an additional NCP option. Following the NCP negotiation phase, PPP is ready to transport network-layer packets. Although there is potential for a significant start-up delay while PPP performs all this negotiation, in practice initial PPP negotiations take only a couple of seconds at 9.6 kbps.

When shopping for a product that supports PPP, first check how much of the PPP protocol a particular implementation supports. Many parts of the PPP protocol can be included or left out at the implementor's discretion. For instance, does the product support PPP Link Quality Monitoring? What NCl's docs it handle besides IPCP? Does the product support both PAP and CHAP? How complete are its NCP implementations for the network-layer protocols you care about? For example, an IPCP implementation should support VJ header compression. Can the product suggest an IP address and/or accept a remotely offered IP address? Next, consider the PPP implementation's hardware support and requirements. What is the maximum bandwidth supported? If it is a l'C implementation, does it take advantage of the superior National Semiconductor 16550A-compatible Universal Asynchronous Receiver/Transmitter (UART) chip on the I'C's serial port? Also investigate what percentage of CPU cycles the product demands under high link speeds. CPU usage is easy to quantify in a Unix environment, which provides commands to display usage statistics, but may be more difficult to quantify in a PC cnvironment. For example, a poor PPP implementation may calculate the packet cheeksum very inefficiently, resulting in a sluggish PC when using high-speed serial links. Finally, besides looking at compliance/completeness with the PPP protocol, note that many PPP implementations offer extra functionality. All these extras are outside the PPP protocol itself, so don't expect compatibility among different vendors in these areas. Also, many extras may not be helpful in a given environment.

Several factors are holding PPP back. For instance IPCP (IP over PPP) is the only widely supported NCP. Althoug Novell has a temporary but working solution (tunneling IPX into IP), the IPXCP specification itself has not been formalized nor widely distributed, let alone implemented. In SLIP and CSLIP, IP over PPP has a widely accepted (albeit inferior) competitor. If you are planning the future of your dial up or WAN links, you should look carefully at PPP, as many organizations are reaping its benefits with relatively small investments. Perhaps the time is right for you to join them.

Chip Sparling: "Plugging into TCP/IP with Windows Sockets", Data Communications, October 1993.

TCP/IP is the glue that holds the Internet (or just about any internetwork, for that matter) together. More often than not, the PCs being attached to TCP/IP ne tworks run the world's most dominant graphical user interface, Microsoft Windows . So it's only inevitable that technology be developed to bring glue and GUI tog ether for application developers and end-users alike. Inevitable, but not necess arily easy. TCP/IP and Windows may be the respective technologies of choice for internetworking and operating environments, but they are far from being natural complements. Although Windows runs under DOS (no stranger to the world of TCP/IP networking), its cooperative multitasking and memory management were, at first, beyond the scope of DOS-based network software developed for the most part befo re the arrival of Windows. In addition to these kinds of "mechanical" problems, Windows presents a fundamental challenge that conventional network application p rogram interfaces (APIs) were not meeting. Network software is geared toward str aight-ahead, sequential operation; Windows, a message-based operating environmen t that allows tasks to coexist, requires a different approach. The Windows Socke ts API embodies that approach. Windows Sockets bridges the architectural gap betweeen network applications and Windows through the use of Windows-supported dynamic link libraries (DLLs). DLLs are libraries of executable functions that link with a network application at run time, rather than when the application is created, thus separating the application from the API. The main attraction of using DLLs for a Windows API is that DLLs provide a standard application binary interface (ABI). Binary compatibility makes it possible to create a single version of an application that will run over any DLL providing the same entry points to the network. Windows Sockets is based on the popular Berkeley Sockets network interface, as defined in version 4.1c of the Berkeley Software Distribution (BSD) of the Unix operating system. While the current Windows Sockets specification focuses on TCP/IP, like Berkeley Sockets, it is protocol-independent. Because of this, Windows Sockets offers a migration path not only for existing application source code but also for the development of network applications that are more Windows-friendly. Version 1.1 of Windows Sockets: "An open interface for network programming under Microsoft Windows" was released in January 1993. Since then, most vendors of TCP/IP network software have added Windows Sockets DLLs to their network protocol stack software. Microsoft offers Windows Sockets APIs for its LAN Manager, Workgroup for Windows, and Windows NT products. The best indication of Windows Sockets' acceptance is the number of compatible network applications that are now available for the API. Developers have been quick to recognize the reduced effort and maintenance overhead (read that "cost savings") that Windows Sockets offers. The API's wide acceptance may ultimately give network managers what they have long been waiting for-network applications that have just one disk set, one installation procedure, and one configuration setting for any number of protocol stacks.

Understanding the importance of Windows Sockets requires some background in the nature of TCP/IP and the roles that APIs play in developing network software. T he main hallmark of the TCP/IP protocol suite is its flexibility--it is built to work with different network media and has been implemented on many different co mputer systems. A comparison of the TCP/IP protocol suite and the OSI network re ference model illustrates the layering within the suite and its flexible, modula r architecture. The formal TCP/IP protocol suite corresponds to layers 3 and 4 ( the network and transport layers) of the OSI model. Because TCP/IP stacks do not necessarily provide the two lowest layers (data link and physical) in the OSI m odel, TCP/IP is capable of operating independently of network interface drivers and physical media (X.25, Ethernet, and token ring, for example). Driver indepen dence means TCP/IP can run alongside other protocol stacks (such as DECnet, Nove ll IPX/SPX, Banyan Vines, and others), as well as APIs created for those stacks. Most TCP/IP stacks for DOS run over drivers with de facto standard inter faces, such as the Network Device Interface Specification (NDIS), Open Datalink Interface (ODI), and the Packet Driver Specification, all o f which can accommodate multiple protocol stacks simultaneously. Media independe nce means TCP/IP can provide network and transport protocols that can communicat e over any media. The internet protocol (IP) part of TCP/IP has a mechanism for the fragmentation and reassembly of packets; this mechanism allows dynamic adapt ation to different media limitations. For example, IP can fragment data in a 1,5 14-byte Ethernet packet into smaller packets for transmission over an X.25 netwo rk. (X.25 allows 256 byte packets only). Vendors of TCP/IP stack software typica lly include in their products applications that use the higher-level protocols o f TCP/IP. These applications provide basic network services, such as distributed file systems, remote login, file transfer, and electronic mail. However, they a re not the only services that TCP/IP can support. This is where TCP/IP APIs come in. APIs in essence give developers a way to plug into the lower levels of the network to create custom applications that provide new network services. There a re many network APIs available for creation of TCP/IP network applications. Amon g conventional APIs fol TCP/IP, the most commonly used are Berkeley Sockets, Transport Layer Interface (TLI), remote procedure calls (RPCs), and N etbios. Berkeley Sockets, considered the most popular of the TCP/IP APIs, actual ly is an all-purpose API because it's protocol protocol. Berkeley Sockets provid es developers with access to TCP and UDP. The Berkeley Sockets API made its debu t in the early 1980s, with the release of BSD Unix version 4.1c. BSD Unix is wid ely available and very popular, so the emergence of Berkeley Sockets as the de f acto standard for TCP/IP application designers was no surprise. Most vendors of Unix hardware and software have implemented Berkeley Sockets. TLI, developed by AT&T for Unix System V and released in the mid-1980s, runs a close second to Berkeley Sockets for popularity among conventional TCP/IP APIs. Like Berkeley Sockets, TLI offers access to TCP and UDP transport protocols. RPCs handle data translation, which means they work higher up in the OSI model than Berkeley Sockets and TLI. Specifically, RPCs are APIs for the presentation layer (layer 6) of the OSI model. RPCs do a lot for an application developer automatically: For instance, they find network connection ports and assign them, defaulting to UDP for transport. RPC implementations are widely avail ablc the two best known are the Distributed Computing Environment (DCE) from Open Software Foundation Inc. (OSF) and Open Network Computing (ONC) from Sun Microsystems Inc. The differences in the two RPC versions limit portability but do not effect the porting of an application written with one type of RPC to another operating system. The goal of the RPC approach is to make a network function call as simple as any local function call. However, because RPCs function at a higher level in the networking model, developers often must tweak the RPC code, accessing lower-level APIs like Berkeley Sockets or TLI to create more efficient applications. The fourth commonly used conventional API for TCP/IP, Netbios, is the closest thing to a standard network API for PCs. Although Netbios provides a session-layer API (OSI layer 5) and is protocol-independent, it often is used over TCP/IP. Many of the verbs that make up the Netbios API are functionally similar to those used in TLI and Sockets. Netbios is available for DOS, Windows 3.X, Windows NT, and OS/2, but not Unix. Because Netbios does not work with Unix, Netbios applications are not as portable as those created using Berkeley Sockets or TLI.

Information about the Windows Sockets API is available from several sources over the Internet. The specification itseself can be obtained for anonymous FTP access over the Internet. There also is an Internet Network News group and a mailing list. Subscriptions may be forwarded to the following addresses: winsock-request@sunsite.unc.edu (for general Windows Sockets information) and winsnmp-request@microdyne.com (for Windows SNMP API information).

John Windham: "APPN and TCP/IP: Plotting a backbone strategy", Data Communications, March 1994.

To bring the past and future together, most enterprise network plans must addre ss two key architectural challenges. The first is to figure out how to link a wi de variety of departmental LANs with one another as well as with established cor porate IS resources, usually based on IBM's SNA. The second is to come up with a plan for the eventual migration of mission-critical applications from mainframe s to powerful LAN-based servers and workstations. More often than not, the way t o meet both these challenges is to create a network based on an enterprise-wide backbone protocol that cuts across disparate WAN and LAN boundaries to deliver e nd-to-end connectivity. The two most likely candidates to tackle this task are A PPN and TCP/IP. From a theoretical viewpoint, the choice between the two protoco ls is clear cut. Networks based on conventional SNA are a perfect match for APPN , IBM's anointed successor to SNA, while TCP/IP is the best choice for networks made up primarily of interconnected LANs. However, between those black-and-white choices are many shades of gray. For networks with a mix of SNA and LAN installations, the choice of backbone protocol can hinge on a wide range of factors that include not only the current state of the network but also long-term plans for resource deployment. In general, enterprise networks need backbone protocols for one simple reason: The protocols already in place aren't equipped to deal with the intricacies of sophisticated, heterogeneous network designs. On the LAN side, protocols like Netbios, XNS, Netware IPX, and Appletalk thrive in environments where bandwidth is cheap and plentiful. Meanwhile, in conventional IBM SNA environments, all connections are handled by mainframe hosts under domains known as subarea networks. SNA hosts running VTAM/SSCP (Virtual Telecommunications Access Method/System Services Control Point) software control downstream 37XX communication controllers running NCP (Network Control Program), as well as cluster controllers, workstations, or PCs. Because subarea SNA is host-centric, all routing decisions are made by VTAM and NCP, making distributed applications involving peer comuters virtually impossible to develop. Compounding the need to supplant hostcentric SNA is the decision by many companies to move important applications off mainframe hosts and onto distributed servers, workstations and PCs. In the mid-1980s, IBM began its long migration away from host-based networking with the debut of Advanced Peer-to-Peer Networking (APPN). When it is fully in place, APPN will allow host-independent communications between all strategic IBM processors and operating platforms, from hosts and 3745 front-end processors to AS/400s midrange computers, RS/6000 workstations, and PCs. The final significant host piece to the APPN puzzle is scheduled to fall into place soon, with IBM's release of VTAM 4.2. The new VTAM release will provide Dependent LU (Logical Unit) Server/Requester functions over APPN, enabling APPN to accommodate 3270 applications.

According to zealots on both sides ol the issue, APPN and TCP/IP are separated by a world of differences. After all, the two protocols evolved in completely dissimilar environments under vastly different conditions. APPN belongs to IBM, although the vendor has published the APPN spec and incorporates recommendations made by third parties through the PPN Implementer's Workshop. In contrast, TCP/IP is an open standard govrned by the nonaligned Internet Engineering Task Force. Every major vendor supports TCP/IP, making it the lingua franca of networking. Yet the gap that separates APPN and TCP/IP is not as wide as surface differences suggest. While the two protocols have evolved from unique philosophical and technology bases, they both deliver the means to handle client-server and host-based communications. Each can be used in single-LAN segments, multi-LAN segments, or LAN internetworks that traverse WAN links. A comparison of APPN and TCP/IP shows some striking similarities between the two protocols. Despite the arguments on both sides of the APPN and TCP/IP debate, it's clear that the two backbone protocols are growing closer in terms of functionality and performance. Still, the differences between the two are significant enough that each protocol is best suited to specific network deslgns. In general, companies that rely on mainframe-based mission-critical applications requiring subsecond response times and high reliability probably will look to APPN. Those with a predominance of LAN-based ad hoc query applications, including file transfers and electronic mail, will move to TCP/IP. And many large organizations with a miz of both equipments may decide to adopt both APPN and TCP/IP as backbone protocols.

Steven King: "The enterprise network: Backbone or black hole?", Data Communications, January 1993.

One currently popular cosmology tells us the universe is expanding outward fro m a big (and probably spectacular) bang. Another popular cosmology (moving a little closer to home) tells us that LAN protocols are expanding outward from the workgroup, eventually to dominate the enterprise. But client-server protocols like IPX/SPX, Netbios, and Appletalk, with their excessive broadcasts and limited addressing schemes, are hardly suited to corporate LAN/WAN architectures. This leaves much of the industry looking ta TCP/IP as an enterprise-wide backbone protocol for LAN and SNA traffic. Unfortunately, TCP/IP services are based on routing and addressing principles that are decades old. Their limitations can already be seen in demanding corporate environments, and there's no guarantee that the ad hoc Internet community can transform TCP/IP into an enterprise-ready protocol in our lifetimes. Though it may still be a force in the industry, OSI is fighting entropy. Thus, it's giving TCP/IP little to worry about. This leaves IBM's Advanced Peer-to-Peer Networking (APPN) as the only architecture with a chance to assert itself in a big way. With highly integrated routing and directory services, APPN scales well from very small to very large networks and delivers both LAN interconnect and host access. Despite its technical strengths, APPN has yet to come into its own. A recent study of mainframe sites from International Data Corp concluded that there's three times more interest in TCP/IP than APPN. Is all this attention based on TCP/IP's stellar performance? Or is it more a matter of the protocol's tremendous mass and inertia? Those are weighty questions. The right enterprise architecture will enable a network infrastructure that continues to expand, unifying increasingly distant users. The wrong architecture will likely collapse in on itself in what astrophysicists aptly term the "big crunch". Fortunately, it's possible to assess the options without resorting to quantum mechanics or other equally esoteric criteria:

Addressing: One of the most time-consuming administrative chores is assigning unique addresses to network devices and logical subnetworks. TCP/IP uses a 32-bit IP address, and some organizations are already running out of designations for end-nodes and subnets. APPN addressing uses one to eight alphanumeric characters for subnet IDs (NETID) and one to eight alphanumeric characters for nodes and other resources (LUs). APPN can accommodate millions or even billions of nodes, subnets, and resources. IP addresses are tied to router ports and LAN segments, which forces network managers to change an IP address each time a node is moved. APPN addresses, in contrast, are independent of ports and links. Moving a node within a NETID subnet doesn't usually necessitate an address change, and APPN subnets can have more than 10,000 nodes.

Directory services: When an APPN node is added to the network, its resources are automatically registered in a network directory. If a node is moved or modified, the changes also are automatically registered. TCP/IP nodes are located with a simple directory service call to the Domain Name Service (DNS). IP nodes must be individually added to or deleted from DNS. Net managers who fall behind in this tedious task end up playing hide and seek with resources. Users end up with a barrage of HOST NOT FOUND messages.

Topology updates: TCP/IP maintains its routing table with RIP (routing information protocol) or OSPF (open shortest path first). RIP periodically sends large amounts of redundant update data through the network. OSPF reduces this overhead by sending only necessary changes between routers. APPN goes further, keeping a running history of the topology updates that have been exchanged between each pair of network nodes and assigning each update a sequence number. In the event of a failure, APPN network nodes can quickly reconstruct the current topology.

Congestion control. When IP routers become congested, they drop packets, relying on the TCP layer for end-to-end error detection and retransmission. As long as there's plenty of clean bandwidth available, few packets are dropped and routers are spared the overhead of maintaining pacing windows and acknowledgments. But when link resources are less than ideal, congestion means lost packets, delays, and lower utilization. APPN's ISR (Intermediate Session Routing) layer uses a hop-by-hop adaptive pacing technique that puts congestion control on every node in an end-to-end virtual circuit. Yes, this increases the overhead at network nodes, but packets aren't dropped and link utilization is far higher.

Class of service: Each time an application requests an APPN session, it stipulates a class of service based on security, propagation delay, cost, bandwidth, and other communications characteristics. Once a session is established, APPN packets always take the same path along a virtual circuit. TCP/IP has the potential to do some limited class-of service routing, but few, if any, router vendors support it.

Automatic rerouting: One decided advantage of TCP/IP is its ability to automatically reroute around a link failure without involving application programs. When an APPN link fails, the session is terminated and applications must request new session (unless link-layer rerouting exists, as with frame relay and X.25).

TCP/IP's automatic rerouting and connectionless network layer put APPN at a disadvantage in some contexts. But IBM has recently revealed details of its coming high-speed routing architecture: APPN+, a protocol suite aimed directly at TCP/IP's strengths. APPN+ is based on a technology IBM calls High Performance Routing (HPR), which comprises both Layer 3 and Layer 4 protocols. Automatic Network Routing (ANR), at Layer 3, delivers a source-routed, connectionless service that can drop packets when overcongested. Rapid Transport Protocol (RTP), at Layer 4, furnishes end-to-end error handling and rate-based flow control to govern the rate at which trafflc is offered by end-nodes. The beauty of HPR is that it's completely interchangeable with ISR within a single network. HPR is for links with low bit-error rates, typically high-speed fiber and digital lines from fractional T1 to T3. ISR is used for links with higher error rates, typically slower digital or analog lines. APPN automatically adapts to any mix of ISR and HPR. (The routing efficiencies of HPR become apparent with two or more consecutive links). Like ISR, it delivers full class-of-service routing. Unlike ISR, it reroutes automatically. APPN, though proprietary, is technically superior to TCP/IP for complex internetworks.

TCP/IP, though outdated, is the de facto standard. Choosing one or the other will become a quandary of cosmic proportions for some organizations. But for others, the two architectures will coexist and intermingle indefinitely. Vendors are already hard at work on tunneling, protocol conversion, spoofing, and all manner of messy dual-protocol contrivances, creating, in the process, a cosmology of confusion

Robin Layland: The end of IP as we know it, Data Communications, October 1994.

The technology that's supposed to be a key component of the information superhighway is about to be paved over. The Internet Engineering Task. Force has earmarked IP for obsolescence, signaling the beginning of the end of the beloved protocol's golden age. Of course, the IETF hasn't actually come out and admitted that it's phasing out IP. In fact, the Internet watchdog is adamant about keeping the IP name alive, giving its replacement protocol innocuous labels like IP version 6 and IPng (for "next generation"). But make no mistake: IPng is much more than an upgrade. It's a whole new protocol. Now, I don't mean to imply that the IETF is trying to pull a fast one on the growing legions of IP loyalists. In fact, I'm not even sure the IETF fully realized that it was crossing that imaginary line separating upgrade from overhaul. But intentionally or not, the line has been crossed. And once IPng wins formal IETF approval -which may come as early as this December- there will be no turning back.

VICTIM OF SUCCESS. Ironically, IP's incredible success has helped seal its fate. Because of the surging popularity of the Internet, the 8-byte addressing scheme now used in IP networks is in danger of running out of room. To fix this problem, the IETF has decided to boost the size of IP addresses to 16 bytes (more than enough to handle demand for at least the next decade). The new address size is the most prominent feature of IPng, but the IETF has built several other improvements into the new IP as well. IPng will include an autoconfiguration feature intended to ease the burden on network administrators by automating such tasks as address tracking and network numbering. The new IP also includes a traffic prioritization provision that the IETF calls "grade of service" (in the SNA/APPN world, it's known as "class of service"). The grade of service specification should bring some much-needed order to Internet traffic. Other improvements to come with IPng include encryption-based security and flow control.

The end result of all these improvements is a brand-new protocol. Sure, IPng is based on IP version 4. But anyone who wants to run both IP version 4 and IPng applications is going to need separate stacks for those applications. Separate stacks means separate protocols - no matter what they're called.

None of this means IP will be legislated out of existence overnight. In fact, the IETF's plans call for a gradual migration from IP to IPng, allowing for an indefinite period of peaceful coexistence. After all, it's going to take a few years for IPng software to become fully available, and even more time for it to become affordable.

PARALLEL PROBLEMS. There's no doubt that the IETF is right in moving forward with its protocol. The problem I see isn't so much what the IETF is doing, but how it's doing it. By linking the new IP so closely wiLh the old, the IETF may be setting itself up for the same kind of trouble that has plagued IBM's efforts to get users to migrate from SNA to APPN (Advanced Peer-to-Peer Networking).

Back in the mid-1980s, IBM realized that SNA simply couldn't thrive in the emerging PC-based computing environment. The decade-old protocol was built for the big-iron world populated by master mainframes and slave terminals. It lacked any facility for the peer-to-peer communications driving the LAN revolution. SNA also needed better flow control for handling high-volume applications and directory services for locating devices. But while IBM knew SNA had to be replaced, it also knew that a wholesale change in architecture would be tantamount to suicide. Loyal SNA users would be stuck with billions of dollars worth of instantly obsolete gear. Worse, they would no longer have to toe the IBM line when it came to implementation decisions. So IBM billed APPN, its next-generation protocol, as an extension to SNA. Rather than announce a strategy and a timetable for phasing out SNA, IBM went to great lengths to make sure SNA applications could coexist with APPN for years to come.

None of this changed the reality that APPN was a totally new protocol. After all, to use it, IBM customers had to install new protocol stacks and rewrite existing applications -the same thing IP users will face once IPng hits the streets. Given the choice of staying with SNA or moving to APPN, most IBM shops have decided to stand pat. The result: Even though APPN has been available for more than five years now, it's still struggling for acceptance among corporate networkers, even IBM diehards.

I can't prove beyond a reasonable doubt that IBM's reluctance to break with the past is the main reason for APPN's cold reception. But it couldn't have helped. Old-line SNA users came to view APPN as a luxury upgrade that could be put off as long as needed, while potential new customers saw the SNA/APPN confusion as one more reason to stay away from Big Blue.

I hope the IETF has more luck with IPng than IBM has had with APPN. The new IP does have a few things going for it. One of IP's biggest strengths is that it still is perceived as an up-and-coming technology. Then there's the installed base of IP users, which seems to be growing exponentially. But 10 years ago, we could have said pretty much the same things about SNA. IBM's architecture was seen as a rising star back in 1984, and at its height of popularity it commanded an installed base that included a significant portion of corporate America.
Another key advantage is that IP users have a lot less invested in their applications than SNA users had when APPN came to life. The lower the investment, the easier the decision to phase out existing applications and build for the future.

BREAKING AWAY. Still, I can't help but think that a clean break with the past-painful and disruptive though it may be in the near term would have been the better way to go. Instead of spending its creative capital on coming up with an airtight migration plan, the IETF may have been better off facing the emerging realities of high-speed networking and multimedia starting with a clean slate.

I'm convinced that IBM could have reached its goals for APPN a lot sooner, and with a lot fewer problems, if it had presented APPN as a new protocol for a new networking age. Users who didn't need peer-to-peer networking could stay with SNA; those who did need to modernize would have to move ahead. Instead, IBM worried too much about its migration plan and not enough about adapting to PC networking.

Right now, it looks as though IP will thrive no matter how IPng is presented or accepted. There isn't any protocol available today or on the horizon that poses a threat to IP's dominance. Then again, 10 years ago who would have thought that IBM would have any trouble maintaining its stranglehold on corporate networks?

John Till Johnson: Doubts about IPng could create TCP/IP chaos, Data Communications, November 1994.

Even as the Internet Engineering Task Force nears final approval of IPng, its heir apparent to the 15-year old Internet Protocol, some members of the committee that developed IPng continue to question the value of the protocol they helped create. The ongoing acrimony raises the possibility that the migration to IPng will be less than smooth, creating the potential for TCP/IP interoperability problems that may reach well into the next decade.

The dispute over IPng - (known as IP version 6 (IPv6) in IETF circles - could create major long-term headaches for managers of corporate networks. The basic problem is that IPng, the "version 6" label notwithstanding, is more than an upgrade to IP; it's a new protocol, which means all network software must be changed to implement it. And IPng is not backward-compatible with IP - if some vendors and users decide to forgo or delay IPng deployment and stick with IP, the end result could be the existence of separate networks, effectively eliminating one of the key attractions of TCP/IP. It's too early to tell how vendors and users will react to the new protocol once it's formally adopted and ready for use. A draft standard from IETF's IPng Working Group is expected by year's end, which means products containing the IPng protocol stack won't hit the shelves until 1996. But the early rhetoric suggests that universal acceptance of IPng is far from certain. In fact, at least one member of the IPng Area Directorate, the group overseeing the development of the new protocol, says he won't be deploying IPng in his company's internal network anytime soon.

TRIPLE THREAT. Criticisms of IPng fall into three general categories. Dissenters in one camp contend that the wholesale replacement of existing network software to accommodate a new protocol stack will create immense and costly migration problems that will take many years to sort through.

A second group of detractors argues that the issues addressed in IPng (including the need for more network addresses and the addition of features like encryption, user authentication, automatic network configuration, and the ability to handle delay-sensitive traffic), aren't compelling enough to warrant scrapping IP for a new protocol.

And then there are those critics who say that some of the technologies on which IPng is based are inherently flawed and will eventually fall victim to the same problems that now plague IP In particular, IPng's new addressing scheme has come under some heavy fire. Although the new protocol expands the address space from IP's 4 bytes to 16 bytes, some observers believe that the IPng scheme isn't large enough or flexible enough to handle the kinds of routing protocols likely to develop in the future.

For their part, supporters of IPng counter that criticisms of the new protocol are minor compared with the benefits IPng will yield.

ADDRESS CRUNCH. Chief among those very real problems is the impending shortage of IP addresses. The addressing structure used in the current version of IP known as IP version 4 (or IPv4), is running out of addresses that can be allocated to IP networks and their attached hosts (which in TCP/IP parlance are any devices running an IP stack). All TCP/IP hosts (including not only those connected to the Internet but also any TCP/IP device on any private corporate network) must have a unique IP address assigned to it by the Internet Network Information Center (InterNIC).

The IETF projects that under the current addressing scheme, IP will run out of addresses within the next 10 to 15 years. If that were to happen, net managers would not be able to build new TCP/IP networks or add hosts to networks already in place. Obviously, this couldn't be allowed to happen.

Enter the IPng Area Directorate, a group formed in late 1993 to solve the addressing problem. After evaluating three different proposed addressing schemes, the group voted to back one of the proposals. The IPng Area issued the directorate's recommendation to the IETF this past August as part of its overall plan for IP version 6. The new addressing scheme is one of four key changes to be implemented in the new protocol. The IPng Area's proposal also calls for improved security in the form of encryption and user authentication, an autoconfiguration feature to ease the creation of new networks, and a mechanism to route delay-sensitive traffic like voice and video.

WHAT WILL IT BUY? Proponents of IPng contend that while the new protocol's expanded addressing space is far and away its main attraction, the other changes will yield important advantages for managers of corporate networks. For instance, although security features like encryption and user authentication can be deployed in IP networks today via software, having those features built into the protocol means users can send encrypted packets without having to worry about whether devices at the other end are equipped with matching algorithms.

With IPng's autoconfiguration feature, network devices will be able to find and claim their own network address as soon as they are installed on the network. With today's IP networks, a net manager or technician typically has to assign an address to each new device and configure that device manually. Autoconfiguration is going to make a dramatic difference for people who run a network on a day-to-day basis.

For handling delay-sensitive traffic, IPng specifies a mechanism called the flow ID, a field in the IPng packet header. The flow ID tells routers which packets are delay-sensitive, making it easier to expedite the processing of those packets. While it's possible to send voice and video traffic over IP networks today, performance is erratic because routers have no way of distinguishing delay-sensitive packets.

WHAT WILL IT COST? The big problem with all these changes is that they make IPng incompatible with the current version of IP. To use the new protocol, net managers will have to change the protocol stack software in every networked device. Since the protocol stack is part of the operating system in many machines (including PCs running Unix and the latest versions of Windows NT and OS/2), upgrading the IP stack means replacing the operating system.

Some supporters of IPng acknowledge that the transition to the new protocol is going to be tough. Contributing to the complexity is the fact that changes must be made at several levels, including routers, hosts, and domain name servers (DNS), devices that sit at the edge of an Internet connection and that translate IP's numerical addresses into Internet format. One possible migration plan is to follow a dual-stack strategy in which IPng deployment is strictly controlled. Net managers would install the new protocol on routers first, then move to DNSs and finally to hosts. Such an approach would ensure that as each component is upgraded, it can still communicate with all other components in the network using the older protocol. Once all upgrades are complete, the changeover to IPng can occur. But the dual-stack scheme can work only if all vendors agree to implement both IP version 4 and IPng stacks on their products, a requirement the IETF is reluctant to make and a step that vendors may not take.

Even if vendors commit to IPng, chances are that a number of older devices, such as low-end PCs or printers, won't be part of the migration. That means net managers may face the prospect of scrapping usable equipment that doesn't make the cut.

To minimize this kind of displacement, the IPng working group is now considering a few different coexistence schemes. One proposal is to define an encapsulation protocol that would enable IP traffic to "tunnel" through an IPng network. The protocol would define a way to map an IP address into an IPng address for handling by IPng routers. Similarly, a protocol could be defined to enable IPng traffic to tunnel through an IP network. Another solution would be to provide gateways that would translate addresses between IP and IPng networks. The problem with such solutions is that they are either cumbersome to implement or inefficient-or both.

NAT-PICKING. Underlying the angst about the eventual migration to IPng is the assertion by a number of observers that the new protocol doesn't present net managers with enough new features to justify a complete network overhaul. But some critics contend that even 1 IP's pending address shortage can be solved without scrapping IP version 4. The main assumption that drove the IPng initiative was that the only way to prevent an address calamity was to expand the address space in the packet header. But several vendors are now said to be working on a technology that could solve IP's address problem indefinitely-and without replacing the protocol.

The key to this effort is a device called a Network Address Translation (NAT) box. In essence, the NAT box would serve as a buffer between global and local (subnet) networks. Network addresses on the global side would be globally unique, while on the local side addresses would have to be unique only at the subnet level. Devices on different subnets could have the same local address, as long as the global addresses for those two sites are different. Hosts on the subnet side of a NAT box would have local addresses that are never sent out over the Internet. When one of those hosts sends traffic over the Internet, the NAT box strips out the local address and replaces it with the globally unique address assigned to that subnet. With this change, one of the chief reasons for the IP address shortage would disappear. The catch is that mapping between the globally unique and locally unique addresses presents a stiff technical challenge, and no one has publicly demonstrated a NAT box that can solve that challenge. In fact, although several major vendors are rumored to be investigating the commercial development of NAT boxes, no one will admit to doing so.

WHAT ABOUT TOMORROW? Along with citing potential solutions like NAT boxes, some IPng critics argue that the addressing scheme defined in IPng may not be large enough or flexible enough to accommodate future routing protocols, which means IPng could be only a temporary solution to the address problem. The problem is that in today's networks, backbone routers must keep track of every route in the Internet. As the Internet continues to grow, that could become impossible (the IETF once estimated that the size of routing tables is outpacing the rate of growth of memory technology by 150 percent). Eventually, developers will have to come up with a new routing scheme.

The most likely approach that developers will take to reduce the size of routing tables will be to create more layers of subnets, as known as layers of abstraction or levels of aggregation. As layers of subnets are added, they take up more of the address space in the packet header. If the Internet continues to grow at its current pace, it's conceivable that IPng's 32-byte address space, as expansive as it now seems, could prove inadequate.

Aggregation causes you to have a very low utilization of the address space. People should have been thinking a little further ahead. One sure way to prevent an address shortage from ever occurring is to use a variable-length addressing scheme. Two such schemes were proposed to the IPng Area Directorate. The group rejected both proposals, deeming one insufficiently developed and the other unnecessarily complex. Instead, it opted for a fixed-length approach called Simple Internet Protocol Plus (SIPP).

Proponents of the variable-length addressing proposals (many of whom remain critical of IPng) argue that their plans were dismissed too readily. But those in the IPng camp insist they made the right move in backing SIPP.

IPng supporters also assert that variable-length addressing has one serious tlaw that can drag down network performance: processing complexity. Fixed-length addresses are much faster to process. Quick processing is critical to a protocol that has to be handled by routers.

But opponents counters that variable-length addresses add very little to processing overhead. One of the schemes presented to the IPng group is based on connectionless network protocol (CLNP), the OSI equivalent to IP; CLNP uses variable-length addresses. Cisco's routers already handle CLNP with no trouble.

LESS THAN UNIQUE. IPng's detractors don't necessarily have anything against the other key features being added to the new protocol. But as far as security and autoconfiguration are concerned, similar features already are available-or could be made available - for IP version 4.

On the security side, IPng ensures user authentication by means of an authentication header. The header includes a 32-bit field that contains a Security Association Identifier (SAID) and a variable-length field that contains authentication data. The SAID enables two hosts to negotiate a variety of security parameters (including the type of encryption algorithm and the key size used by the algorithm) for each session. But all this could be accomplished with the current version of IP, using the optional extended headers the protocol supplies. These headers are now rarely used. Defining precisely how security would work over IPv4 would take some effort, but no more than is currently being put into IPng.

Another IPng feature that is available - at least to a degree - in IPv4 is autoconfiguration. An Internet spec for autoconfiguration already has been defined. And one of its biggest users is Microsoft.

"The biggest barrier to deploying TCP/IP on our internal network was the lack of autoconfiguration," says Microsoft's Allard. To solve the problem, Allard helped develop DHCP (dynamic host control protocol), which allows a server to automatically configure all attached hosts. It's already been used to configure more than 10,000 host deviccs in Microsoft's internal network and is shipping as part of Windows NT

As for IPng's ability to handle delay-sensitive traffic, right now there's one catch with the flow ID scheme: No one knows exactly how it will work. The current IPng spec does not address the procedures -or semantics-needed for handling real-time traffic. Until the semantics is defined, the flow ID is just baggage.