These core routers used a special routing protocol to communicate called the Gateway-To-Gateway Protocol (GGP). GGP was originally developed in the early 1980s by Bolt, Beranek, and Newman (BBN) one of the pioneers of the Internet and TCP/IP. It was documented in RFC 823 and published in September 1982.

The modern Internet is based on the concept of independent autonomous systems (ASes) that run interior routing protocols within them, and exterior routing protocols between them. The early Internet, however, was somewhat simpler; it consisted of a relatively small number of core routers that carried detailed information about the Internet as a whole, and non-core routers located around the core that knew only partial information.

This protocol is now obsolete, but it played an important role in the early Internet, and also introduced certain concepts that were used in routing protocols developed years later. This makes knowing a little bit about it worthwhile.

GGP is similar in general operation to the Routing Information Protocol (RIP) in that it uses a distance-vector algorithm to determine the best routes between devices. Like RIP, the metric is a simple hop count, so GGP will select a route with the shortest number of hops.

As in RIP, that hop count is not always the best metric of cost for a router, it was actually a pretty good method of route determination back then. This is because the early Internet used both computers and links that would be considered glacially slow by today’s standards, making each hop fairly “expensive” compared to modern routing.

A router using GGP initially starts out in a null state, assuming that all links to other routers and local networks are down. It then tests the status of its local networks by seeing if it can send and receive messages on the network. Every 15 seconds, the router sends a GGP Echo message to each of its neighbors. If the neighbor receives the message, it responds with a GGP Echo Reply message. The router sending the Echo messages considers the neighbor up if it receives back replies to a certain percentage of messages, defaulting to 50%.

Actual routing information is communicated by sending GGP Routing Update messages. These are similar in nature to RIP Response messages used in RIP. Each Routing Update message contains the information in the sending router’s routing table, which specifies which networks the router can reach and at what cost (in hops) for each. Each router receiving a Routing Update message knows that since it can reach the router that sent the update, it can also reach all of those router’s reachable networks at the cost of an additional hop. It uses the information to update its own internal tables of destinations and metrics. It then sends out its own Routing Update on its own attached networks, to propagate the information learned from other routers on its own networks. This process continues until eventually, routes to all GGP routers spreads across the internetwork, just as they do in RIP.

One interesting difference between GGP and RIP is that in GGP, networks, and costs aren’t sent in pairs. Instead, a GGP router sends its routing table to groups. If it has three networks it can reach at a cost of 1 it sends those in a group with distance value 1, then if it has a few at a cost of 2 it sends those in a group with distance value 2, and so on. Another difference is that GGP Routing Update messages are acknowledged. Each Routing Update message is sent with a sequence number, which is used to ensure that out-of-date information is not propagated. If the Routing Update is received and has a new sequence number (indicating that it is recent information), the router processing it sends back a GGP Acknowledgment message back to the originator. If the sequence number indicates the message is stale, a Negative Acknowledgment is sent instead and the message discarded.

As a distance-vector algorithm using hop count as a metric, GGP shared most of the same pros and cons as RIP. It had simplicity on its side but had various problems such as slow convergence and issues such as the “counting to infinity” problem. GGP was a much more rudimentary protocol than RIP, however, and did not include many of the features included in RIP to handle such issues, such as split horizon. GGP was also limited to unsubnetted classful networks, due to its age.

When Internet architecture moved to the use of autonomous systems, GGP was obsolete. While it was an important part of TCP/IP history, it is today not formally considered a part of the TCP/IP protocol suite.