The Internet Protocol is out of date, can RINA save us?

Interesting:

There is, of course, one clear layer violation that NAT has to deal with, but that’s not NAT’s
fault either. Some application protocols put an IP address inside the application layer header.
These have to be modified by NAT, so a NAT has to understand the syntax of all of these layer violating applications that it supports. The original application that did this was FTP, going back to the very early ARPANET days. FTP did this because – remember, this was a lab hack, not meant for production – BBN, who built the original packet switches, had line printers attached to user ports on its Terminal Interface Processor, an early terminal server. The TIP didn’t have enough memory for a name table, so the protocol port number in the TCP header literally identified to the physical port on the TIP. (That’s why they’re called port numbers.) This problem was fixed years before IBM built its first “PC”. But other protocol designers assumed that FTP’s designers must have known something they didn’t, so they blindly copied it. This is rather like passing physical memory addresses in a Java program.

SIP, the popular VoIP control protocol, also allows IP addresses in the header in lieu of names. This is done because telephone sets and other devices may not even have name entries in the DNS, especially if they’re behind a NAT. This points to a second problem with TCP/IP. The real name of an application is not the text form that humans type; it’s really identified by an IP address and its well-known-port number. When an application uses a host name or other text form such as a URI, it is the application that resolves it by querying DNS. This should instead be done by the network layer machinery in the host. That would close off the excuse for putting IP addresses in the application layer, and provide a uniform mechanism for application-entities tofind each other. Again, this was not recognized by the ARPANET developers in 1975, when there were only a small number of hosts on the net and only a few applications, but it’s a case where the TCP/IP architecture has not scaled well. In fact, even host names should not be used in the application. Applications, not hosts should be what’s named! The host simply, er, hosts it! Many applications nowadays run on more than one host; this requires a royal kludge in the TCP/IP architecture.

The original “Internet” concept was one of large-scale networks with limited interconnection
between each other. The term dates back all the way to CYCLADES. It came into widespread
use when the Department of Defense separated its internal MILNET from the more researchoriented ARPANET. The two IP networks remained linked, but under separate administration. The pre-public ARPANET and later the Internet grew by adding organizations such as universities and corporations, each of which managed their own network and which typically had one or two links to the rest of the network outside of the company. Most users had more of a community of interest within their own organizations than with the rest of the world; public Internet access was thus a feature of their network, not the goal itself.

Today’s Internet is used very differently. It functions, like the telephone network, as a consumer and general business service. Corporations often use encrypted links across the public Internet to link their own sites, rather than use private links to access the Internet centrally. But because of the way IP works, interconnection between networks remains largely centralized as it was in the 1980s. With some narrow exceptions, each link between networks must be reported to every router worldwide. So if Comcast in Massachusetts were to create a direct link – that is, peer – with Verizon in Massachusetts, this link and its current status would be reported via the backbone’s “flooding” system to routers in New York, Texas, and Uzbekistan. So network designers have to strike a balance between creating too many links, and thus overburdening the routers, and having too few links, and thus having to send local traffic on a very roundabout route.

…This leads to the first principle of our proposed new network architecture: Layers are recursive.

The same protocol can be used repeatedly in a protocol stack, encapsulating each layer in another instance of itself. There is thus no need for purpose-built protocols for each layer. There is also not a fixed number of layers in the stack. The number of layers between the application and the physical medium is variable; at any given point, there are simply as many as needed, no more, no less. But any given implementation only needs to deal with itself, the layer above it, and the layer below it. The actual depth of the stack is essentially invisible.

Layers are not the same thing as protocols; more than one protocol can make up a layer. Because the same group of protocols is used repeatedly, the implementation is simpler than the TCP/IP stack. There’s no need for separate protocols for “layer 2”, “layer 3”, etc. Because the layers recurse, and can scale to form a large internet, the protocol suite that supports the concept from Patterns in Network Architecture (PNA) is called the Recursive Internetwork Architecture (RINA).

The protocols that make up the basic RINA layer include the Data Transfer Protocol (DTP)
which relays the payload in the forward direction. Its contents includes addressing information and protection information (a checksum and a time-to-live counter which detects routing loops). The Data Transfer Control Protocol (DTCP) performs the error and flow control functions, sending feedback from destination to source. Note that DTP has the payload, which is visible outside of the layer, while DTCP operates entirely within the black box. A layer also has a management protocol.