How the Internet Came to Be - Page 11

I had certain technical ambitions when this project started, but they were all oriented toward highly flexible, dynamic communication for military application, insensitive to differences in technology below the level of the routers. I have been extremely pleased with the robustness of the system and its ability to adapt to new communications technology.

One of the main goals of the project was "IP on everything." Whether it is frame relay, ATM, or ISDN, it should always be possible to bring an Internet Protocol up on top of it. We've always been able to get IP to run, so the Internet has satisfied my design criteria. But I didn't have a clue that we would end up with anything like the scale of what we have now, let alone the scale that it's likely to reach by the end of the decade.

On scaling

The somewhat embarrassing thing is that the network address space is under pressure now. The original design of 1973 and 1974 contemplated a total of 256 networks. There was only one LAN at PARC, and all the other networks were regional or nationwide networks. We didn't think there would be more than 256 research networks involved. When it became clear there would be a lot of local area networks, we invented the concept of Class A, B, and C addresses. In Class C there were several million network IDs. But the problem that was not foreseen was that the routing protocols and Internet topology were not well suited for handling an extremely large number of network IDs. So people preferred to use Class B and subnetting instead. We have a rather sparsely allocated address space in the current Internet design, with Class B allocated to excess and Class A and C allocated only lightly.

The lesson is that there is a complex interaction between routing protocols, topology, and scaling, and that determines what Internet routing structure will be necessary for the next ten to twenty years.

When I was chairman of the Internet Activities Board and went to the IETF and IAB to characterize the problem, it was clear that the solution had to be incrementally deployable. You can deploy something in parallel, but then how do the new and old interwork? We are seeing proposals of varying kinds to deal with the problem. Some kind of backward compatibility is highly desirable until you can't assign 32-bit address space. Translating gateways have the defect that when you're halfway through, half the community is transitioned and half isn't, and all the traffic between the two has to go through the translating gateway and it's hard to have enough resources to do this.

It's still a little early to tell how well the alternatives will satisfy the requirements. We are also dealing not only with the scaling problem, but also with the need not to foreclose important new features, such as concepts of flows, the ability to handle multicasting, and concepts of accounting.

<- Previous | Next ->