Few remarks on CS144...

I'm teaching computer networks for the past 10 or so years, and during that time I got used to a certain approach in teaching this subject. But as I already noted in the post about e2e design principle and middleboxes, I'm watching course Introduction to Computer Networks (CS144), given on Stanford university. The main reason being that I wanted to see how others are doing it. While I was watching the part of the first lecture, What is Internet - 4 layers, I had some comments, so I decided to write a post about it. But then, I decided to comment on the whole course, not just a single lecture. At least that is my intention at this moment.

One very important thing before I start. Note that every course has to simplify things and remove as much details as possible in order to make things "learnable". So, sometimes lecturers don't tell complete truth, or even they say something that isn't truth. This is acceptable as long as they correct themselves eventually. But because of this it means that there are many approaches to teach something, potentially very different, and I'm looking from the viewpoint of one specific approach, namely the one I'm using. This, in turn, might mean that some, or even majority, will not agree with my comments on CS144 in this post. That's perfectly OK, but anyone reading this post should bear that in mind and not take things for granted!

What is Internet - 4 Layers

The purpose of this lecture is to teach you about layering in the networks. This is a very important concept that is a mandatory knowledge for anyone doing anything that touches networking.

But there are few things that I don't like in the approach taken by CS144. First, more correctness problem than something major, is when the lecturer notes where particular layers are implemented. He doesn't give a complete information in this case because he says that everything below application layer is implemented in the operating system. But, the truth is that parts of "link layer" are implemented in hardware, which definitely isn't an operating system, and within firmware which also isn't part of an operating system. Also, where is the line between hardware/firmware and operating system greatly varies. There are, for example, hardware accelerators for TCP, and in that case hardware/firmware reaches almost up to application layer.

Next, ISO/OSI RM is mentioned only briefly, and the comment was "... that was widely used." It was introduced because network layer is frequently called Layer 3, while in model used in this course it is in layer 2. Before continuing, let me just note that Layer 2 is also frequently used, and Layer 7 (L7) isn't so rarely used, either. Anyway, first ISO/OSI has never been widely used for the purpose it was created, unless you count bureaucratic work done within OSI, which is a lot of (bureaucratic) work! On the other hand, it is widely used as a reference model, i.e. it is used to compare different networks. And also it is widely used when we try to be a general, not tied to a specific network. After all, Internet is only one instance of many other networks, past and future. Now, I agree that it is good policy these days to stick to the Internet when teaching basics of networking. But it should be clear that Internet isn't the only network around. If OSI did something right (well, truth to be told, they did several things right), than it is the stuff around network model (or architecture). Note that there are some things that are not right (e.g. number of layers), but in general it is very well thought subject. By the way, physical layer has much more to do than only wires and connectors, if nothing else because there are three main ways of communication (wireless, wired and optical) and then there are countless number of variations within each of those.

Now, when the lecturer compares the 4 layer model he uses with ISO, he says that TCP covers transport and session layers of ISO/OSI RM. This is the first time ever that I heard that TCP covers session layer. This is based on his premise that the purpose of session layer is connection establishment. But, that's simply not true. The purpose of session layer is management of multiple connections, which can degrade into a single connection and in that case session layer is very thin - in terms of the functionality. On the other hand, connection establishment for a single connection is part of the specific protocol within transport layer (there are of course those that don't have connection establishment). Take for example OSI transport protocol TP4 which has connection establishment, transfer and disconnect phases, just like TCP and OSI definitely places it in transport layer, not session layer!

Finally, the lecture implies that layers are the same thing as protocols, i.e. that transport layer is TCP. But, the layer is just a concept, while TCP is an entity, implementation, that logically belongs to a certain layer.

What is Internet - IP Service Model

This lecture is about IP service, which, as the lecturer says at the beginning is what IP offers to layer above and what it expects from layer below. But I think that this lecture actually mixes services expected from layers below and above, with the inner workings of the IP that are invisible to higher/lower layers:

• Packet fragmenting isn't visible outside of the IP protocol because it is the task of the IP itself to defragment fragmented packets before handing data to the protocol in the layer above. Also, when IP fragmets packets the protocols in lower layers don't know, neither they care, if those are fragments or not. They are treated as opaque data by the lower layer protocols.
• Feature to prevent packets from looping forever is also internal mechanism to IP protocol, and not something that higher or lower layers should know or care about. True, there is ICMP message that informs sender that this happened, but as I said, it is not intended for other layers. If nothing else, because those layers don't determine the value of TTL field. It is a sole discretion of IP protocol itself.
• Checksum in the IP packet isn't used to prevent IP packet to be delivered to wrong destination. Let me cite RFC791 which says that:
  

  This checksum at the internet level is intended to protect the internet header fields from transmission errors.

  So it is intended to protect header from errors, not to prevent deliver of IP packet to wrong destination. True, it might happen that the error occurs in destination address and that, in that case, delivery is prevented but this is only a special case, a consequence, not something specifically targeted.
  Furthermore, while I'm at checksum, it uses simple addition and thus it is a very weak protection mechanism. Actually, it was so useless, and also it was slowing routers, so it was removed in IPv6. By the way, the same version of checksum is equally useful in TCP.
• Options within IPv4 are, again, specific to IPv4 protocol and not something offered as a service to higher layers.

I have to admit that the bullet "Allows for a new versions of IP" totally confused me?

Next, the definition of connectionless service is that no state is established in the network. That is true, but the point is that it is not the feature of a service but of the protocol operation, and thus protocols above (i.e. in higher layers) simply don't care about that. It is possible for some protocol to offer connection oriented service while operating over connectionless "subnetwork" (e.g. TCP over IP) as it is possible to offer connectionless service over connection oriented "subnetwork (e.g. IP over ATM). More about connectionless vs. connestion oriented you can read in my other post.

Note, the term IP layer is somewhat wrong, or at least discussable  Namely, there is no IP layer but network layer in which one of the protocols is IP protocol. Now, I'm aware that many say IP layer so, if we assume that the majority is right, then I'm wrong. :)

Also, for the end of this part it was interesting to see the mixed use of the terms datagram and a packet. I'm almost always using the term packet, rarely datagram, but I'll have to take a look at this more closely.

Anyway, could be that the lectures of this course and I have different view on what "service model" is, but I didn't notice that they defined what they mean by it, they just started to explain service model of different protocols.

Now, while solving quizzes the following questions surprised me:

• An Internet router is allowed to drop packets when it has insufficient resources -- this is the idea of "best effort" service. There can also be cases when resources are available (e.g., link capacity) but the router drops the packet anyways. Which of the following are examples of scenarios where a router drops a packet even when it has sufficient resources?
  
  I thought that the answer was a, c and d (corrupted packet). But, d was rejected.
• In an alternative to the Internet Protocol called "ATM" proposed in the 1990s, the source and destination address is replaced by a unique "flow" identifier that is dynamically created for each new end-to-end communication. Before the communication starts, the flow identifier is added to each router along the path, to indicate the next hop, and then removed when the communication is over. What are the consequences of this design choice?
  
  Here, I thought that the answers are a and c. But apparently, a and d were accepted. Now, c says that  there is a need for control entity to manage flow labels. Might be that I misunderstood "control entity", that it actually means something centralized. In that case probably I'm wrong. And d says there is no more need for transport layer. I would like to hear some arguments for that. Anyway, I'll have to read a bit more details about ATM, after all.

What is internet - TCP UDP

This video starts with the introduction in which the following sentence is stated: ... two different transport layer services, one of them is TCP and the other is UDP. The problem is that TCP and UDP are not services but protocols that offer some service.

"TCP is an example of transport layer". As I said, TCP is protocol, not a layer!

I wouldn't say that the property "stream of bytes" means that the bytes will be delivered in order. That's more the property of reliability. What "stream of bytes" means, in the case of TCP, is that there is no concept of the message and message boundaries. So, if the application sends two times 500 octets, it can be delivered on the other end in one go of 1000 octets, in three rounds, etc.

Source port isn't only used so that TCP knows where to send back data, but also for receiving entity to know how to demultiplex incoming TCP segment. Namely, every connection is uniquely identified by a four tuple (IP src addr, src port, IP dst addr, dst addr) and so source port is used for demultiplexing.

Checksum in TCP is quite weak, as I already argued, so it is not particularly good mechanism for detecting errors.

It is possible that TCP connection is closed in three exchanges, but could be that this will be explained later.

What is the Internet - ICMP

I have to admit that placing ICMP in transport layer is quite a novel approach to layering Internet protocols. The lecturer says that strictly speaking it uses IP and thus it belongs to transport layer. The truth is that it is far from clear where this protocol is, but the point is that when you place protocols in different layers it is not only what the protocol uses, but also what it offers and for what it is used - with respect to layer functionality. So, when we talk about ICMP, it doesn't offer services to layer above, that would be application layer, but it doesn't offer services to transport layer, either. Also, transport layer offers end-to-end communication services to application layer. Note that ICMP, on the other hand, allows communication of network layer entities (IP protocols) between any two nodes within the network. It is produced and consumed by IP protocol implemenations.

Two additional things have to be clarified that someone might take out now and counter argument me. First, there are applications that use ICMP, ping and traceroute. The truth is that ICMP actually was never designed to be used by applications, neither ping nor traceroute (especially not traceroute, search for the word "jelaous" on this page, its an interesting story). It just turned out that something can be used for the purpose not intended initially and so we now have those applications. But, I think that ping and traceroute access directly network layer, that is ICMP.

The second thing that someone might use to say that ICMP isn't in the network layer is OSPF. Namely, OSPF uses directly IP for a transfer service, not UDP nor TCP. So, someone might say that by placing ICMP into the network layer I'm placing OSPF to network layer too. There are those that think that OSPF is there. But, I think that OSPF is in application layer, along with other routing protocols. And that is for two reasons:

1. Routing protocols communicate from end-to-end. It doesn't matter that "end" in this case might be, and is, a network router somewhere within the network, the point is that OSPF application treats that as intended destionations, ends. With ICMP, any node might - for example - drop a packet and generate Time Exceeded message. Note that the node generating error message isn't an end point of the communication!
2. The functionality of the protocols is vastly different. And not only that, but also who is consuming the packets. ICMP is consumed, and generated, by IP protocol. (minus ping/traceroute for whom I already said that they are a special cases). OSPF on the other hand, is quite a complex protocol and IP protocol directly hands data to OSPF application process. IP doesn't consume those messages, neither it produces them.

So, I think OSPF is in application layer, while ICMP is in top part of the network layer.

Additionally, let me return to the lecture slides. Slide number 3 shows data for ICMP coming from the application. It's not true, data comes from the network layer itself, and ping and traceroute are misusing layering.

On slide 5 ICMP is treated as a network protocol in a sense like IP is. But I think that it's misleading. This actually leads me to one more argument why ICMP belongs to the network layer. Namely, ICMP doesn't have any separate implementation, there is no ICMP module within an operating system. There is IP module (protocol implementation) that produces and consumes ICMP messages.

Ok, so much about that lecture. Finally, when I was trying to solve quizzes, I had a problem with a first question: Which of the following statements are true about the ICMP service model? The offered answers were:

1. ICMP messages are typically used to diagnose network problems. This is true, but it's not service model.
2. Some routers would prioritize ICMP messages over other packets. This one isn' true. The routers treat ICMP messages as any other message (unless specifically configured to do so).
3. ICMP messages are useless, since they do not transport actual data. ICMP is definitely not useless.
4. ICMP messages can be maliciously used to scan a network and identify network devices. Yes, they can, but it's not a service model what this question asks.
5. ICMP messages are reliably transmitted over the Internet. They are transferred in IP which is unreliable.

After trial and error it turned out that b is also true!? But then again, I can say that I made mistake because I didn't read that "some would" prioritize, which could be true, and "would" doesn't mean it is necessarily so. Huh, I hate when someone plays with words.

Ok, I'll stop here because this post is brewing for too long, and as I'm having much other work to do, it will take time until I watch all the lectures. Not to mention that it becomes quite large. So, I decided to publish this, and expect new posts eventually...

End2end design principle, middleboxes and a bit about TCP...

I was just watching guest lecture given by Jana Iyengar to the students of CS144 course on Stanford. In his lecture he talks about e2e design principle, and the rise of middleboxes. He then goes on to conclude that middleboxes (especially NATs) are a problem of today's Internet. And I couldn't agree more! It's known fact that Internet was built in such a way that the network is dumb, while end nodes are smart. When I say smart, it means that functionality is placed within smart part of the whole system, while when I say dumb, it means it only performs one simple function. In the case of the Internet, network only moves data from one end to the other, and almost nothing else. This design principle was a key feature that allowed Internet to evolve to today's form and become ubiquitous network. To better illustrate this point, contrast Internet with telephone network. Telephone network was built so that the network itself is smart, while the end nodes (telephones!) are dumb. There is a nice illustration of this difference I saw once I liked very much. Here is the reconstruction of the illustration I saw:

Now, when you wanted something new from your telephone, which included telephone network, you had to wait your telephone company to introduce the service in the network, and only after that you could use it. Contrast that to the Internet, you just had to install a server/service on you computer and whoever wanted to access it had to install client on its machine. And that's it, no changes necessary in the network. Actually, the network doesn't know, neither care, what you are doing and everything works. There is a great example of this: the Web. The Web wouldn't succeed if Tim Berners-Lee had to wait for telephone companies to do something. And since the Internet is popular thanks to the Web, the Internet itself wouldn't succeed. Note that the telephone network functions in such a way because of a historical reasons. But, the telephone provides don't have incentive to change that. When/if they control network, they have revenues. The moment they only transfer data, the revenues are with someone else. And that's the case today with content providers (Google, Yahoo, Microsoft, Youtube, ...) and ISPs.

There is also one additional reason to design network by pushing  functionality to the edge and that's for scalability reasons. I think that it's quite obvious that the simpler something is, the bigger it can be, and it's easier to increase size, so I won't argue this any more.

What is happening now, and for some time, is that NATs are proliferating throughout the network. And since NATs heavily inspect the packets that pass through them and they depend on knowing higher layer protocols, it means they have to have built-in knowledge of higher layer protocols. What that means in turn is that if you are introducing a new service, you have to have support built into NATs. And there are two problems there. First, abundance of installed NATs that can not be changed, and second, bugs within those devices. So, in essence, we are approaching the way telephone networks work. Of course, there are other problems with NATs, but this one is a huge one!

Jana Iyengar then talks about SCTP, and the fact that this protocol exists from 2000 and it still didn't manage to take some ground. And middleboxes, more specifically NATs, are to blame. They pass TCP, fiddling with it, but nothing else. So, one of the things he was doing is using TCP as a communication substrate. In other words, he relied on TCP being passed through middleboxes, and then he went to built protocol on top of it. This protocol then could be used to build another protocols that will work across middleboxes. The modification that they did to TCP allowed it to deliver out-of-order data which they termed as uTCP, unreliable TCP. And, it seems no-one thought of that before.

But, I have to say that in 2011. I worked with a student and we were trying to introduce certain QoS parameters into TCP. The motivation were streaming services. As a part of this we allowed TCP to be unreliable, i.e. it could drop data in order to meet other QoS parameters. The work is described in diploma thesis available online, unfortunately, only in Croatian. But, I intend now to rewrite it into a paper as it was an interesting experiment...

Network troubleshooting...

Yesterday, I was giving a lecture to a third year students of computer science within a course Communication networks. Of course, that is not the only computing module on the Faculty, i.e. there are also modules computer engineering and software engineering, but other lecturers are giving lectures to them. Anyway, the topic of the lecture was Internet's networking layer and, among other things I was talking about autonomus systems, BGP routing protocol, and forwarding process. As a part of ICMP protocol, ping and traceroute commands were mentioned as an important addition to troubleshooting tool. I also mentioned several times to the students that ping and traceroute are the main troubleshooting tools of any network technician. I also told them that after they finish with this course they should be able to do basic troubleshooting and never ever again say something like "Internet isn't working"! Finally, I mentioned that there is a Routeviews project on the Internet that provides (read only) access to BGP routers that can be used to see routes exchanged on certain parts of the Internet.

So, the reason I'm writing this post is that I stumbled on a post Why Google Went Offline Today and a Bit about How the Internet Works which is highly recommended read for them, but also for anyone else learning about networking, with an emphasis on the Internet. They (students) should be able to follow and understand this post now after they learned basic terminology and mechanisms of the Internet layer. To fully understand it, they'll have to wait until we explain how DNS works.

Routeviews

Let me (mis)use this post to say more about Routeviews. Actually, there is also Looking Glass which is very similar, i.e. it allows to peek at certain points on the Internet, but it doesn't offer direct access to BGP routers so, its a bit less interesting, at least to me.

Before I continue with description of Routeviews let me state that Internet is highly irregular network, connecting autonomous systems, with the main irregularity coming from the peering relations between autonomous systems. This peering is largely kept confidential, and besides BGP routing is mainly driven by politics not by technology. What this means is that the real topology if the Internet is not known to anybody. And besides, it's a dynamic and constantly moving target. There are attempts of mapping Internet, but nevertheless they are only approximations.

So, how Internet looks depends on where are you looking from. The routeviews allow one to look on the Internet from different points and this is used for troubleshooting purposes, as well for research purposes. There are also historical data and that's very valuable information.

Anyway, if you go to Routeviews project you'll see a table with a list of DNS names. For each name there is additional information, how to access it (mainly telnet), what type of software/hardware it is running, and where it is. So, you can telnet to one of those routers, and using command show ip bgp determine BGP routing table of that router. Note that Cisco IOS (as well as Zebra/Quagga which are modelled after IOS) offer help command in the form of a question mark. At any point in the command you can type ? and the OS will show you what can you type at that point.

Here is a c/p from a session I made. It's obviously edited to be short and up to the point. First, I logged in to one of the routers:

$ telnet route-views.routeviews.org
Trying 128.223.51.103...
Connected to route-views.routeviews.org.
Escape character is '^]'.
 **********************************************************************
                    Oregon Exchange BGP Route Viewer
          route-views.oregon-ix.net / route-views.routeviews.org
 route views data is archived on http://archive.routeviews.org
 This hardware is part of a grant from Cisco Systems.
 Please contact [email protected] if you have questions or
 comments about this service, its use, or if you might be able to
 contribute your view.
 This router has views of the full routing tables from several ASes.
 The list of ASes is documented under "Current Participants" on
 http://www.routeviews.org/.
                          **************
 route-views.routeviews.org is now using AAA for logins.  Login with
 username "rviews".  See http://routeviews.org/aaa.html
 **********************************************************************

User Access Verification
Username: rviews
route-views>

What I typed is in bold, and what I received is in ordinary text. Note that I used username rviews, as specified in a greeting message. Here is a bit of using help:

route-views>?
Exec commands:
  <1-99>           Session number to resume
  access-enable    Create a temporary Access-List entry
  access-profile   Apply user-profile to interface
  clear            Reset functions
  connect          Open a terminal connection
  crypto           Encryption related commands.
  disable          Turn off privileged commands
...
route-views>show ?
  aaa                   Show AAA values
  aal2                  Show commands for AAL2
  adjacency             Adjacent nodes
  alps                  Alps information
  appfw                 Application Firewall information
  aps                   APS information
  arp                   ARP table
  auto                  Show Automation Template
  backup                Backup status
  bfd                   BFD protocol info
  bgp                   BGP information
...
route-views>show i?
if-mgr  ima           inventory  ip
ipc     iphc-profile  ipv6    

Again, in bold is what I typed, and with three dots I marked output that was cutted not to clutter this post. Finally, here is part of the show bgp command output (note, show ip bgp is equivalent form):

route-views>show bgp
BGP table version is 3000708321, local router ID is 128.223.51.103
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network     Next Hop         Metric LocPrf Weight Path
r> 0.0.0.0  208.74.64.40                        0 19214 12989 2828 i
*  1.0.0.0/24  217.75.96.60          0             0 16150 15169 i
*              154.11.98.225         0             0 852 15169 i
*              129.250.0.11          6             0 2914 3356 15169 i
*              4.69.184.193          0             0 3356 15169 i
*              194.85.102.33                       0 3277 15169 i
*              194.85.40.15                        0 3267 15169 i
*              193.0.0.56                          0 3333 3356 15169 i
*              209.124.176.223                     0 101 101 15169 i
*              216.218.252.164                     0 6939 15169 i
*              114.31.199.1          0             0 4826 15169 i
*              207.172.6.20          0             0 6079 15169 i
*              208.51.134.254        1             0 3549 15169 i
...

Let me give you a short description of what you see here. First line is some general data (table version, and router's ID). Then there are status codes and origin code that are used later. Finally, the BGP table is dumped (and piped through more, use q to quit).

What you see in BGP table is:

1. Network destination, i.e. some network on the Internet that is reachable from that particular BGP router who's tables you are examining. Note that the multiple lines belong to a single destination network and in that case, network isn't repeated. This is the case for network 1.0.0.0/24 in the previous output.
2. Each line in the output is one possible path to reach given network. Each path consists of a next hop (second column), and exact path (last column with numbers). The path that was found to be the best is marked with greater-then (>) in the first column (also, note the legend in the beginning of the output).
3. Exact path is a sequence of autonomous systems through which destination network is reachable. Note that each path ends with a same number, i.e. same autonomous system number. That's because given network belongs to that autonomous system.
4. At the end of each path there is letter that informs us from where this route was obtained. In this case i means it came from the peering BGP router in the same autonomous system as the router we are examining.

Finally, to exit use exit command. :) And that's it. I suppose you can play and research for yourself from this point on...

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.