What is Routing architecture...

I decided to write a post about Nimrod routing architecture but then I realized that I first have to define, or at least describe, what is meant by routing architecture. I searched a bit for a definition, and to my surprise, I wasn't able to find one. So, I decided to give my own view, and possibly definition. But when I started to write it, it turned out that the substantial part of the post about Nimrod will be about routing architecture. After a bit of thinking, I decided to split the text into two posts and the goal of this new post is to define routing architecture. I'll start by dissecting both words, routing and architecture, separately and then I'll combine them.

One note before proceeding. You have to keep one thing in mind when reading this post. My primarily viewpoint is from data networks, and I don't know much about voice, a.k.a. telephone, networks. So I don't claim, nor do I believe, this will be valid for them. In any case, I would gladly hear comments you might have about my view, or, you own views about this particular topic.

Routing

The term routing denotes a process who's purpose is to determine path, or route, through the network between two users, obeying some (possibly more that one) constraints and optimality requirements. This process, in essence, enables any two users to communicate. User might be on any node in the network, as is in the Internet, or only on a certain subset of nodes, as is in telephone network where only telephones can communicate and not telephone with some internal network switch. The example with a telephone isn't actually very good, since we are confined in the network layer (as per OSI RM) and telephone network doesn't have concept of a layer but instead uses interfaces! Anyway, users of routing are entities within a network layer, which in turn allow their users (transport layer) to communicate.

Closely related to routing, and frequently mixed with routing, is forwarding, but forwarding is actually concerned with moving data packets through the network, in contrast to routing that only determines where packets should go. In other words, forwarding is on data path, while routing is in control path. Note that users of routing are performing forwarding! There are two additional differences between forwarding and routing. First, routing, in order to work, needs a certain data about the network, and of course, decisions have to be taken somewhere. On the other hand, forwarding needs only a subset of that data to perform its function. In general this is so, but there are some cases it might not be a true subset. For example, RIP protocol has only data about destination, next hop and distance, and that data is passed to forwarding process. On the other hand OSPF routing process knows the complete topology of the network, and it passes only a subset of this data to forwarding process. The second difference is that routing is a global process, i.e. it needs a coordination throughout the whole network, while forwarding is a local process with no explicit coordination with other nodes.

Note that inseparable part of routing is addressing, i.e. how to identify nodes for the purposes of routing. There is also a concept of a name, but it is not directly related to routing. For an early discussion on distinction between names, addresses and routing take a look at Shoch's note from 1978.

So, strictly speaking we have two different things, routing and forwarding. But those two are inseparable, meaning that when you define a new routing it has an impact on forwarding too. After all, routing process has to give instructions to forwarding process what it has to do and also, when routing process tells forwarding process for nodes it has to do so via addresses, so, they have to agree about address structure and whatever information is embedded in them. In any case, by only finding routes, without being able to deliver data because you don't communicate with forwarding process, you didn't achieved much. So, I'll use the term routing  with two different meanings, routing in a strict sense, and routing in general. Routing in general will include also forwarding process and from now on I'll use this meaning of the word routing, unless specifically told otherwise.

For the end of this section let me just note that the routing process can have different characteristics:

• centralized vs. distributed,
• static vs. dynamic

Architecture

Architecture is nowadays very heavily (mis)used word in computer science and related disciplines. Traditional architecture is a very old discipline and different fields of computer science borrow a lot of ideas from it. Probably the first use of word architecture in computer science was in relationship with computer organization, or more precisely, computer architecture and it appeared during the development of IBM's 7030 computer. Here is a definition, given by Frederic P. Brooks, Jr., of the purpose of computer architecture taken from the document Planning a Computer System - Project Stretch:

Computer architecture, like other architecture, is the art of  determining the needs of  the user of  a structure and then designing to meet those needs as effectively as possible  within economic and technological  constraints. Architecture must include engineering  considerations, so that the design will be economical and feasible; but the emphasis in architecture is upon the needs of  the user, whereas in engineering the emphasis is upon  the needs of  the fabricator.

Later, the term architecture spread in use for different levels of abstraction and different domains. For example, there is CPU architecture, as opposed to computer architecture, and just to mention few from software domain: software architecture, service oriented architecture (SOA), client server architecture, and many many others.

I don't think it's necessary to enumerate all the possible uses of this word and their definitions, since it seems to me that it is clear from the original definition what an architecture is and what its purpose is. So, the term architecture denotes a result of a design process, that takes the requirements from the users and outputs definition a system in terms of components, their behavior and interactions that fulfils the initial requirements. Architecture by itself is stripped from unnecessary technical details and from implementation details. It is also a work of art, but I can state that sentence in a more technical terms: it is a search process of a huge space of different possibilities which can not be automated, by current methods, and thus has to rely on experience (which, I believe, is a cause of intuition) of the architect.

Finally, two things have to be noted. First, there could be multiple views of the architecture (thus of a resulting system definition) each of which can represent architecture from different angle. Secondly, architecture is not absolute. As we move through the layers of abstractions, each layer has its architecture and associate implementation!

Routing architecture

So, finally we came to describing what routing architecture is. Routing architecture is

... a system, that consists of components with specified behavior and mutual interaction, built according to some requirements whose purpose is to find a path to a given destination and to allow communication between two users.

This definition is, of course, valid within the networking context. I'm emphasizing this because there is no single word about networks in the previous definition so if it is taken out of the context, it might sound meaningless. Note that by "to allowing communication" I'm also referring to a forwarding process, that is tightly bound to a routing process, as I already explained.

One of the key requirements of routing architecture, at least when Internet-like networks are in question, is scalability.

For additional discussion about routing architecture see this Nimrod presentation that, in the first part, discusses what is routing architecture. Note that this "presentation" is actually text document with titles and bullets, not exactly what should be called presentation.

Examples of routing architectures

There are a dozen of RFCs that deal with different aspect of routing architectures for the Internet. The oldest one I managed to find is The NSFNET Routing Architecture, defined in RFC1093 that was published in 1989. It got addition in 1991 in a form of RFC1222, Advancing the NSFNET Routing Architecture. Also, in 1991. IETF published RFC1287, Towards the Future Internet Architecture. This RFC gives possible directions for the future Internet Architecture, and as such, is much broader than routing architecture we are discussing here. Still, it has a section about future routing architecture. Then, in 1993. ipngwg working group published RFC1550, Next Generation (IPng) White Paper Solicitation, which solicited input on requirements for next generation IP. Noel Chiappa was developing Nimrod at that time and he submitted white paper published as RFC1753, IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture. Basically, he published requirements on Nimrod that he believed will be put on whatever solution will be selected. Nimrod routing architecture was described in RFC1992, Nimrod routing architecture. It was published in 1995 as a possible replacement for IPv4. I'm going to write about that proposal in a separate post.

Lately, IAB recognized that there are serious problems with current routing on the Internet (which are not solved with IPv6). This is documented in report published as RFC4948, Report from the IAB Workshop on Routing and Addressing. To address problems identified in the workshop,  Routing Research Group was established with a goal of evaluating different proposed solutions. This group produced several RFCs related to routing architecture. First, there is RFC5772, A Set of Possible Requirements for a Future Routing Architecture. Because, as we already saw, defining architecture requires some requirements, RRG group produced RFC6227, Design Goals for Scalable Internet Routing, which sets requirements for routing architecture. The requirements defined in this RFC are also used to evaluate different proposals. There are more than dozen proposals. They are listed and shortly surveyed in RFC6115, Recommendation for a Routing Architecture.

For the end I'll mention RFC1958, Architectural Principles of the Internet, and its update RFC3439, Some Internet Architectural Guidelines and Philosophy. While more broader that routing architectures, still apply to them and are very interesting by themselves.

Microprocessor architectures...

One of the tings that interest me a lot, even though only as a spectator, is the architecture of modern processors and techniques used to make them as fast as possible. I stumbled recently on post and analysis of AMD's new processor (micro)architecture Bulldozer, which brought me to this PDF document that summarizes in one place characteristic details of modern processor architectures. Highly recommended read! On the pages of the guy who wrote that PDF document you'll also find a lot of other interesting stuff, mostly low level, for assembly programmers or those who care a lot about every bit of performance.

And while I'm at this low level details, I like to mention one other site also very good source of information. It is Ulrich Drepper's homepage. He's one of maintainters for glibc and on his homepage there is a lot of documentation with description inner workings of glibc. But one of the things I wanted to mention now, related to the topic of microprocessor architecture, is the paper titled Understanding CPU Caches.

New Internet architecture, my take at it no. 1

Reading all those papers about new Internet architecture simply doesn't give me peace. What is the solution? Probably it is a simple one in a concept, though , as always, the devil is in the details. Look at the Internet now. When it was first proposed to use packet switching it looked like lunatics' idea and now it's so normal we don't even think about it and take it for granted. So, it's strange feeling that probably I'm looking and thinking about solution but I'm not aware of it.

So, let me make try number one!

What about making Internet in an onion layered style? The most inner layer, 0th layer, forms the core and makes the most trustfull and protected part of the network. It's not possible for outer layers to access anything inside inner layers (here we could maybe take inspiration from Bell-LaPadula and similar models here?). The infrastructure of the Tier 1 NSPs could form this 0th layer. N-th network layer offers transportation services to (N-1)-th layer. This model would protect inner layers from the outer layers, as outer layers would have no access to inner layers of the network. Something similar is already done with MPLS. But MPLS is deployed inside autonomus system, not as a global concept.

There could be several layers corresponding to current Tier 1, 2 and 3 ISPs. Each layer with more and more participants, and accordingly, more and more untrustworthy. Lower layers could form some kind of isolation layer between all the participants and thus, protect them from the configuration errors. Or mallicius attacks. Note, that this could be problematic as it means that lower layers not only encapsulate higher layers, but also inspect them, or assemble and disassemble. It could be hard to do so it's questionable whether and how this is achiavable.

Each layer could use it's own communication protocol, most suited for the purpose and environemnt it works in. For example, in the core layer there is necessity for fast switching as huge speed could be expected in the years to come with extremly low loss rate, so packet formats best adjusted to that purpose should be used. Probably, the outer - user - layers, would need to have more features, for example, quality of service, access decisions and a like. Futhermore, maybe lossy network is used, e.g. wireless network, so some additional features are necessary.

Communication of request to lower layers could be done withih the format of the packets, as ATM did where it's cells had different format when entering network and inside the network, so called UNI and NNI.

We could further envision (N-1)th layer of the onion for the content distribution. This layer's task could be to distribute content using services from the (N-2)th layer. Content could be anything you can think of, e.g. different documents (openoffice, pdf), video, audio, Web pages, mails, even key strokes and events for remote work and gaming. Those are very different in nature, with probably many more yet to be invented, so, this layer should be extensible. It could take care of access decisions and a like. Note that content layer doesn't work with parts of the objects, but with the whole ones. So, if user requests a movie, this movie is completly transfered to content network ingerent for the user at it's current location.

This could make servers less susceptible to attacks as they wouldn't be directly visible to the users!

Finally, Nth layer could be a user layer. In this layer user connects to the network and requests or sends content addressed with variaty of means. For example, someone could request particular newspaper's article from the particular date. The content network would search for the nearest copy of this contents, and use core network to transfer the object to the user. Someone else could request a particular film, and content network would search for it and present it to the user.

Just as a note, I watched VJ's lecture in Google and this is on the track of what he proposes.