Converging the Evolution of Router Architecturesand IP Networks

András Császár, Gábor Enyedi, Markus Hidell, Gábor Rétvári, Peter Sjödin

Abstract—Although IP is widely recognized as theplatform for next-generation converged networks, it is,unfortunately, heavily burdened by its heritage of al-most 30 years. Nowadays, network operators must devotesignificant resources to carry out tasks so essential liketraffic engineering, policy enforcement and security. Inthis paper, we argue that one of the principal reasonsfor this lies in the way control and forwarding planesare interspersed in today’s IP networks. We review thearchitectural developments that led to the present situationand we reason that centralization of network controlfunctionality can constitute a solution to the pressingproblems of contemporary Internet.

I. INTRODUCTION

Over the past decades, the Internet, and the accompa-nying Internet Protocol (IP) suite, has come through atremendous progress. In the beginning, the ARPANETwas a closed academic network serving as a playgroundfor network research. To our days, this rudimentarynetwork has formed into a critical communications in-frastructure supporting significant economic, educationaland social activities. Nowadays, we deem email and theWorld Wide Web as elemental parts of our everydaylives, and new killer applications just continue to emerge.But rarely do we ponder on the large-scale evolutionaryprogress that made the Internet what it is today.

One factor that played a key role in this continuousprogress is the evolution of the Internet as a globalnetwork. The elementary network architecture of theARPANET, basically a set of packet forwarding com-puters interconnected by long-haul links, has grown intoa complex network of autonomously operated domainsinterconnected by a sophisticated inter-domain control

A. Császár is with TrafficLab, Ericsson Research, H-1037, Laborcu. 1., Budapest, Hungary, E-mail: Andras.Csaszar@ericsson.com.

G. Rétvári and G. Enyedi are with the High Speed NetworksLaboratory, Department of Telecommunications and Media Infor-matics, Budapest University of Technology and Economics, H-1117,Magyar Tudósok körútja 2., Budapest, Hungary, E-mail: {retvari,enyedi}@tmit.bme.hu.

M. Hidell and P. Sjödin are with KTH–the Royal Institute ofTechnology, School of Information and Communication Technol-ogy, Electrum 229, SE-164 40 Kista, Sweden, E-mail:{mahidell,psj}@kth.se.

infrastructure. This diversification of responsibility en-abled service providers to shape their networks accordingto their own taste, relatively isolated one from another,while, thanks to the end-to-end service model, it alsoallowed the Internet to continue to function as a whole.

A second enabler of the unpaired growth of the Inter-net is the evolution of IP router architectures. Throughoutthe years, the IP router has developed from simplisticpacket manipulating software implemented on a generalpurpose computer to a sophisticated network equip-ment that fully utilizes the capabilities of specializedhardware and integrates an endless suit of function-alities, ranging from raw packet forwarding throughtraffic shaping, packet queuing, access control, NetworkAddress Translation (NAT) with connection tracking allthe way to distributed network protocols. Lately, it hasbeen proposed to modularize these interspersed functionsand organize them into administratively and physicallydistinct modules, yielding what is called thedistributedrouter. Such distributed routers are expected to improvescalability of IP routers, open up new markets for devicevendors and foster rapid innovation in the area.

We see the coevolution of theIP network architectureand theIP router architectureas a crucial constituent inthe unrivaled success of IP and, because the Internet isconstantly facing new challenges as new applications andcontent are introduced, we believe that this evolutionaryprogress will persist in the foreseeable future. Therefore,instead of aiming at a clean slate redesign of the Internetin response to these challenges (see e.g., the FINDproject [1]), we rather believe that it is more naturalto track the continuous evolution of IP network androuter architectures and think over where the currentdevelopments are heading.

The most important goal of this paper is to overviewthe ongoing efforts of network systems engineers toadvance the design of IP routers and shape up theInternet architecture to keep up with the ever-growingexpectations. We point out the shortcomings of con-temporary network and router architectures and arguethat, at some point, the architectural developments mustconverge. In particular, we reason that this point couldbe theunification of all the network control and man-

agement functionalityat one central administrative unit.Centralized control would ease network management andthe deployment of new services, it would allow oper-ators to extract better performance from their networkinfrastructure and it would improve the overall security,scalability and price-efficiency of IP networks as well.In Section II we describe state-of-the-art IP networkarchitectures, while Section III is devoted to router ar-chitectures and the ForCES framework of IETF, a recentdevelopment in this field. In Section IV we introduce theIP network architecture based on the centralized controlmodel, discuss how this model solves a large part of theproblems of contemporary IP networks and give a sideby side comparison. Finally, Section IV-B concludes thepaper.

II. T HE EVOLUTION OF THE IP NETWORK

ARCHITECTURE

The Internet finds its roots in the ARPANET,the world’s first operational packet switching networkfunded by the Advanced Research Projects Agency prin-cipally for research purposes. The ARPANET consistedof a small but steadily growing number of end-hostsinterconnected by store-and-forward switching comput-ers known as Interface Message Processors (IMPs), thatlater evolved into IP routers. These IMPs were connectedby low-speed long-haul leased lines and point-to-pointsatellite links into a peer network. Over the decadesthis rudimentary network architecture has sophisticatedinto a two-level hierarchy [2]. Hosts, subnets, and theirinterconnects are organized into independent domainscalled Autonomous Systems (ASs), each one operatedunder the authority of a single administrative entity.These ASs are glued together by a complex, policy basedinter-domain routing mechanism, implemented by theBorder Gateway Protocol (BGP) [3]. A simple modelof a state-of-the-art transit AS is shown in Fig. 1.

Today’s Internet architecture is inherently distributed.On the one hand, it is distributed in the way packets getforwarded in the network: each router hands a packet onto the neighboring IP router it sees best fitting to get thatpacket to its destination. Coordinating the forwardingdecisions to achieve global reachability and a consistentloop-free routing is the routing control functionality,which is again fundamentally distributed in nature. Thismeans that forwarding tables emerge through a complexinteraction of the routers instead of being computedby a central management entity. Within an AS thisinteraction is carried on by means of an Interior GatewayProtocol (IGP), and involves the automatic discoveryof the network topology based on which each routercomputes the best next hop towards each destination

Figure 1: The state-of-the-art hierarchical IP networkarchitecture with 3 ASs. Inside an AS, an IGP providesdistributed control, while inter-AS control is managed byan Exterior Gateway Protocol (EGP) like BGP.

address prefix. Usually, this next hop is the one that lieson the shortest path towards the destination.

Due to its distributed nature, the IP network architec-ture is extremely tolerant to failures and it is unique inits capability to coordinate a large number of heteroge-neous networks. However, distributed operation comeswith its own prize. Most notably, the monitoring andmanagement of the network is difficult and prone toerrors. Furthermore, network performance optimizationusually requires central overview of the network stateand coordinated corrective actions taken by the routers,which hardly fits into a distributed architecture.

III. T HE EVOLUTION OF THE IP ROUTER

ARCHITECTURE

In this section we turn to discuss the architecturaldevelopment of the most important elements that makeup the Internet: the evolution of IP routers [4].

The Internet stems from a time when the links were thebottlenecks in the network. Routers were built accord-ing to a regular, single-storage von Neumann computerarchitecture with packet processing in software, in away very similar to PC-based routers today. Figure 2aillustrates such a first generation router with a processor,a central memory bank, line cards, and a shared businterconnect.

As the amount of traffic increased and links becamefaster, it turned out that the shared memory bus and thecentralized packet processing in software limit perfor-mance. In the second generation routers, as shown inFig. 2b, buffer memory and packet processing logic aredistributed onto each line card, which helps to increase

(a) First generation IP router (b) Second generation IP router

(c) Third generation IP router

Figure 2: The evolution of IP router architectures.

capacity by sharing the packet processing load overmultiple units.

With local memory on each line card, packets donot need to traverse the shared bus in order to reachthe buffer memory, which saves bus bandwidth. But theshared bus can only be used for one transfer at a time, soas a way to further increase capacity the shared bus canbe replaced with a switching fabric—an interconnectionwith parallel data paths—allowing multiple transfers totake place the same time. Such a third generation routeris depicted in Fig. 2c. Many of today’s high-end routerscan be characterized as variants of the third generationarchitecture, with buffer memory and packet processinglogic on the line cards, and a switching fabric withparallel data paths.

We have seen that during the course of the de-velopment of the Internet, IP routers have gone fromrather ordinary, single-CPU systems to highly specializedmultiprocessing systems. Curiously, this dramatic archi-tectural development has taken place almost exclusivelyfor the data plane, while the control plane has remainedvirtually the same: software running on a commodity,general-purpose CPU. The few modifications that havebeen made to the control plane are mainly confined

to hardware upgrades to deal with the growth of thenetwork. In particular, more processing power has beenadded to tackle larger shortest path tree computation in-stances in intra-domain routing, while, for inter-domainrouting, storing more peering information and more en-tries in the forwarding tables has required more memoryat the routers.

However, this relative changelessness of the controlplane should not be perceived as an indication thatthe requirements on the control plane have remainedunchanged. On the contrary, as the requirements onmore advanced network services increase, functionalitysupporting new protocols and services is added to therouter control software.

To summarize, we conclude that the demands on thecontrol and data planes of a router are vastly different.For control, on the one hand, we need software thatsupports flexibility and extensibility while always main-taining backwards compatibility without jeopardizingavailability. For data plane packet forwarding, on theother hand, we need high-speed packet switching hard-ware that can deal with the data feeds from high-capacityoptical links. Since forwarding and control, while inter-related, perform functions that are largely independent

Figure 3: The ForCES framework

Figure 4: Overview of a distributed router.

of each other, we conclude that it is time to rethinkthe traditional, monolithic architecture of routers, whererouting control and packet forwarding are intertwinedinto a single complex system, and advance IP routerarchitectures in the direction of separating control andforwarding functions.

A. ForCES and Distributed Routers

The IETF ForCES (Forwarding and Control ElementSeparation) Working Group takes a first step of separat-ing the control and forwarding plane functionalities asForCES specifies a standardized interface between thetwo planes within a router [5]. The ForCES architecture(illustrated in Fig. 3) is defined in terms of exchangeof information between Control Elements (CEs) andForwarding Elements (FEs). A group of CEs and FEstogether form a Network Element (NE), which appearas an integrated piece of network equipment to externalentities, quite similar to a router in the traditional sense.In such an architecture, a CE is typically based on ageneral purpose CPU executing control software (routingprotocols, management, etc), while an FE can be basedon a variety of hardware platforms performing packet

forwarding functions (classification, metering, forward-ing, etc).

The ForCES protocol executes over the CE-FE inter-face and is responsible for the association establishmentbetween CEs and FEs, as well as for steady state commu-nication. In steady-state, an FE is continuously updatedwith configuration information from the CE, queriedfor information by the CE, or spontaneously sendingasynchronous event notifications to the CE. Accordingto ForCES, an FE is represented as a set of logicalfunctional blocks (LFB) connected together to form adata path along which a packet travels. By configuringthese individual LFBs, a CE can decide how an FEshould process packets.

The ForCES framework can be seen as a first impor-tant step towards the visionary concept of adistributedrouter, where forwarding and control get separated insiderouters both physically and administratively, with a stan-dardized communications interface between the two (seeFig. 4). This modularization delivers several potentialbenefits. Separate components allow component vendorsto specialize in one component without having to becomeexperts in all components. A standard protocol allowsinteroperability between the components of differentvendors, which translates into increased design flexibilityand rapid innovation in both the control and forwardingplanes. Scalability is also provided by this architecturein that additional forwarding or control capacity can beadded to, or removed from, the NE without disruptingthe operation of the rest of the NE.

IV. CENTRALIZED CONTROL ARCHITECTURES INIP

The distributed router architecture holds muchpromise for network operators and device vendors. Forthe former, it brings better device scalability and price-efficiency. For the latter, it has the potential to openup new markets and business models. However, froma pure systems engineering standpoint, an IP networkequipped with distributed routers still remains to beplagued by the shortcomings today’s IP networks sufferfrom, including the complex and error-prone networkmanagement and difficulties in optimizing performance.In this section, we argue that the vast majority of theseproblems originate in one very important design conceptinherent to the IP protocol suite, namely, the distributedimplementation of the control functionality. We furtherargue that overcoming this problem requiresconvergingthe evolution of the IP network and router architectures,and we discuss an advanced architecture that, in ourview, represents the next logical step in this process.In this architecture, control functionality is decoupled

from ordinary network devices and unified at a centraladministrative unit.

Initiatives for centralizing network control have keptshowing up in the last decade in diverse areas of net-working. Central network management applications areextensively used to remotely monitor and administernetwork devices via standardized protocols, like theSimple Network Management Protocol (SNMP). In thearea of routing control, BGP Route Reflectors have beenstandardized to allow for routers in an AS to negotiateinter-domain routes through a central element, instead ofhaving to establish a full mesh of BGP sessions amongthemselves. This idea is improved upon in [6], whereallthe control functionality related to inter-domain routingis centralized at a single module called “Routing ControlPlatform”. In the area of Differentiated Services over IP,the concept of Bandwidth Brokers [7] has been intro-duced. A Bandwidth Broker is a central node keepingtrack of available resources in a network in order to makeadmission control decisions on behalf of the edge nodes.In telecommunication networks and wherever required,centralized AAA servers perform authentication, autho-rization and accounting. Other examples in this area arecentralized Operational and Business Support Systems(OSS/BSS). It seems that only one important piece ismissing from the puzzle right now: bringing togetherall these widely scattered control functionalities at onededicated central control module.

An IP network following such a centralized controlapproach is depicted in Fig. 5. This architecture retainsthe concept of IP ditributed routers as NEs consisting ofFEs and CEs. The main difference is that the controlmechanisms in each NE have been reduced to theminimum functionality that is hard to centralize due toits local scope, including

• a Hello protocol or similar for neighbor discoveryand keepalive/failure detection

• rapid fail-over mechanism to alternative forwardingtables in case of a failure

• a “slow path” for forwarding packets that need spe-cial handling like PDUs or difficult-to-NAT protocolmessages, etc.

All remaining control functions are stripped from the NEand delegated to a central module, which we callCen-tralized Control Platform(CCP). These functionalitiescan include:

• discovering and keeping track of the topology ofthe network

• computing and downloading forwarding tables tothe routers

• running the inter-domain routing protocol

Figure 5: Model of an AS consisting of 3 NEs andan CCP module providing centralized network-globalcontrol functions. NEs consist of a CE module for localcontrol and several FEs responsible for data forwarding.CE-FE interaction inside an NE is managed by theForCES protocol.

• running the signaling protocol and manipulating theQoS infrastructure (packet filters, queues, etc.)

• central administration and network management• admission control, AAA, policy enforcement• interoperation with legacy network protocols, re-

mote network management applications, AAA andBSS/OSS systems, etc.

A. A comparison of central and distributed control

As our networks are steadily getting larger and morecomplex,maintenance and administrationbecomes moreand more of a challenge. This is especially so in dis-tributed architectures, where network state informationand administration databases need to be maintained inan inherently heterogeneous and multi-vendor networkenvironment. This is further complicated by the everlagging behind standardization and commercial supportof management information bases. Therefore, a typicalIP management software is complex and costly, requir-ing significant amount of management in itself. In acentralized architecture, however, where all the relevantinformation is readily available at the CCP, networkmanagement boils down to executing simple queriesto the management information bases at the CCP, andbringing management decisions into effect is as easy asmodifying some entries in the administration database.Note that network management did not just magicallydisappear, it is just delegated to the control information

exchange protocol operating between the CCP and theNE, a mechanism that is an intrinsic component of thenetwork architecture itself.

Another important question is that ofscalability andprice-efficiency. Scalability in this context does not con-note how the global network copes with the exponen-tially increasing amount of traffic or the growing numberof users. We know that the Internet scales extremely well.Instead, by scalability we mean how network devicesthemselves can be scaled to cope with the increasingburden, and what capital and operational expenditures(CAPEX/OPEX) are involved in this process. This isimportant as a more economical network architecturecould be one of the few reasons to consider a newarchitecture at all [2]. In this regard, the separationof control functionality from forwarding functionalityyields important benefits. Under the restrictions of themonolithic design of today’s IP routers, upgrading arouter involves substantial expenditures, especially aswe enter into the reign of top-notch IP routers. In con-trast, in an architecture where forwarding modules andcontrol modules can be scaled separately, dimensioningof the necessary resources is much easier, which yieldssmoother and less expensive upgrade paths.

A notable difference between the distributed controlmodel and the centralized model lies in the differingorganization of the routing functionality. Conventionally,a laborious interaction of the IGP and EGP protocolinstances at distant network elements assures compre-hensive intra- and inter-domain forwarding. In the cen-tralized model, however, the situation is quite different.On the one hand, the IGP functionality in the centralizedmodel is comparted between the NEs and the CCP: whileneighbor discovery runs at the NEs, topology discov-ery and computation of the forwarding tables occur atthe CCP. On the other hand, the EGP functionality iscompletely integrated into the CCP, which speaks BGPwith neighboring ASs to exchange inter-domain routinginformation [6]. Similar compatibility interfaces couldmanage the interaction between the CCP and legacynetwork applications, like AAA systems or OSS/BSSmodules.

In order to maximize the profitability of the valuablenetwork infrastructure, it is essential to optimize the pathtraffic takes as it traverses the network. This process isusually referred to as network performance optimization,or Traffic Engineering(TE). Unfortunately, performingTE under distributed control is uneasy. First, monitoringthe network is hard. Moreover, since distributed routingprotocols usually implement some sorts of shortest pathrouting, the range of applicable paths is rather limited,and load-balancing schemes (like Equal-Cost-MultiPath,

ECMP) do not help much here either. In contrast, centralcontrol is much better suited for TE. First, all relevantnetwork state information is readily available at the CCP,which is therefore a plausible choice to host TE func-tionality. In addition, a centralized control architectureis not confined to shortest path routing, but insteadis free to adopt a much wider range of sophisticatedpath assignment and load-balancing strategies throughencoding them into the forwarding tables. It turns outthat, with central control, it is possible to realize theoptimal traffic allocation in an IP network (the oneyielded by the minimum cost multicommodity flow lin-ear program), which is in sharp contrast with the shortestpath model where attaining the optimum can be shownto be theoreticallyimpossible in many cases.

Every now and then, network device outages, link cutsand other failures inevitably show up in an operationalnetwork, and the network must be able to cope. Thetraditional approach to IPresilienceis global response:the router incident to the failed component floods anadvertisement throughout the network, so that routersseveral hops away from the failed component can ad-just their forwarding tables appropriately. While globalresponse has proven quite reliable, it is intrinsicallyslow. Additionally, this approach is not suitable forcentralized control, because it makes it impossible toreact to failures without the intervention of the CCP,which makes the process fragile and even more cum-bersome. To cut the all-important response time, theIETF initiated the IP Fast Reroute (IPFRR) frameworkto introduce local-response to IP networks similar toMPLS Fast ReRoute [8]. In IPFRR, routers adjacentto the failure take local measures to mitigate it—likeinstalling a precomputed alternativebackwardingtable orredirecting incoming packets to pre-established tunnelsthat circumvent the failure. With the advent of IPFRR,handling of failures has become possible without theimmediate involvement of the control functionality, andthis means that IPFRR is readily applicable with centralcontrol.

Providing Quality of Service(QoS) by implement-ing per-flow admission control has been an importantchallenge for quite some time now. Unfortunately, thedistributed hop-by-hop admission control scheme im-plemented by thede facto IP signaling protocol suite,the Resource reSerVation Protocol (RSVP), does notscale really well to large networks, since each routerneeds to maintain per-flow state information. In contrast,centralized admission control and resource management(similarly to the way Bandwidth Brokers operate) seemsa better fit for providing QoS in IP networks and, at thesame time, it also opens up the possibility of integrating

Control: Centralized DistributedManagement: easy to manage, deployment of new features

and software updates are straight-forwarddistributed management is hard and error-prone, new features are hard to deploy

Scalability: highly scalable – generally, FEs are the bottle-necks, but FEs scale well

less scalable – forwarding and control areentangled

Price-efficiency: FEs are the bottlenecks, but FEs are simple andas such, "cheap”

price/capacity figure of monolithic routers risesexponentially

Forwarding: stand-alone forwarding tables at the routers –routing decisions for different destinations aredecoupled one from another

shortest path routing – implies an inherentcoupling between forwarding paths towardsdifferent destinations

TE algorithm: more complex routing algorithms can be im-plemented, since all computation occurs at oneplace

only simpler algorithms, designed from scratchfor distributed operations

Path assignment: more freedom to assign paths only shortestpath(s) can be employedLoad sharing: arbitrary traffic splitting ratios can be chosen only ECMP can be usedResilience: IPFRR global response or IPFRRQoS: Bandwidth Broker solutions hop-by-hop signaling protocols (e.g. RSVP or

NSIS)Consistency: forwarding tables might be inconsistent during

an update, but this can be avoided with cleverconfiguration

unavoidable inconsistencies and micro-loopsduring routing table recomputations

Robustness: backups for assuring fault tolerance robust bynatureSecurity: no service disruptions as long as the CCP runs,

though, a single CCP might pose a target tocentral attack vectors

compromising a router could render all itsprotocol functionality unavailable

Comp. requirements: all computation at one place – CCP mightbea bottleneck

computations are essentially distributed, whichmay or may not cause replication

Standardization status: with possible exception of ForCES, not stan-dardized

standardized, tested out and deployed in largequantity

Table I: A comparison of distributed and centralized control architectures.

admission control with AAA and network-wide policyenforcement. Again, the CCP proves a plausible choiceto host all these functions.

Networks operate under rapidly and persistently vary-ing conditions, and it must be guaranteed that packetforwarding remains intact by the disruptions. In today’sInternet it is the clever design of distributed routing pro-tocols that assures that forwarding tables at routers, apartfrom temporary transients, areconsistentand loopfree.While this consistency of forwarding tables is inherentlyguaranteed in a central control architecture (since the for-warding tables get computed at one place), it seems thatcentralized control has hard times matching the intrinsicrobustnessof a distributed architecture. This is becausethe CCP poses a single point of failure. However, underthe authority of the local CE and endued with theirdefault forwarding tables, routers can keep up normalforwarding operations even if central control goes awaytemporarily. Additionally, at least in routing control,there is no state that a backup CCP must share with theprimary CCP, which makes it possible to invoke coldbackups: once the primary CCP becomes unavailablea backup CCP kicks in, it quickly associates with therouters, learns the network topology and takes controlover. This graceful restartmechanism ensures that acentralized control architecture can be as reliable and

fault-tolerant as the distributed architecture of today’sInternet.

An extensive comparison of control architectures mustnot leave out the differingcomputational requirementsinvolved in setting up the forwarding tables. In the caseof a distributed IGP, routers need to solve the all-pairsshortest path problem cooperatively to set up consistentrouting tables. Curiously, this computation is parallelizedefficiently: each router computes the shortest path treerouted at itself, so computational load is nicely balancedamongst the routers and no replication of computationsoccurs. On the other hand, distributed operations in thecase of BGP brings in a lot of unnecessary replicationof computations at the routers. In contrast, centralizationopens up the possibility of deploying sophisticated TEalgorithms at the CCP, which are computationally inten-sive but heavily optimized for the specific task. It mustbe noted, however, that centralization of computationsmight render the CCP a bottleneck.

Another important issue is that ofnetwork security.One might think that a distributed control architecture isintrinsically well equipped against attacks. The truth is,however, that compromising just a single router mightinduce a chain reaction rendering the entire distributedcontrol service unreachable, and induce a wave of com-promises spreading along the lengthy chains of trust. Ad-

ditionally, these chains of trust are rather management-intensive, and will keep getting worse with the advent ofForCES where CEs and FEs must authenticate each otherone by one. In contrast, central control alleviates mostof these shortcomings, but again, one must not forgetattack vectors that could pose threats to the CCP as asingle point of failure.

Table I summarizes the discussions in this section.

B. Open issues

Introducing central control in IP networks raises anumber of important questions. First and foremost, ameans for arranging the CCP-NE communications mustbe worked out, preferably on the basis of the ForCESprotocol. Next, it must be clarified how differently archi-tected islands of IP networks, either being complete ASsor IP subdomains inside an AS, can be operated side-by-side. For some pointers on the non-disruptive deploymentof centralized control, the interested reader is referredto [6]. Additionally, it is also of question how the CCPinteroperates with legacy network applications, designedfor a distributed environment but already working in acentrailzed fashion, like BSS/OSS and AAA systems orremote network management applications.

Another issue is how to implement load sharing be-tween multiple CCPs if, for improving survivability ordecreasing processing load, an operator wishes to usemultiple CCPs in parallel. In [9], the authors propose amethod to run multiple BGP modules parallelly, but it isof question how exactly this method could be extendedto other routing and control protocols.

Finally, we mention a perplexing problem concerningthe organization of the control and the data plane: ifcontrol communication takes place directly over the datanetwork (in-band signaling) then we have an interestingchicken and egg problem. Namely, an NE can be re-motely configured no sooner than it becomes reachablefrom the CCP, but reachability is hard to assure withoutfirst configuring the NE [10]. A solution would be toprovide routers with some default forwarding table toassure minimal reachability. Alternatively, establishing adedicated control network (out-of-band signaling) wouldbe a viable solution as well, like it is the case with theSignaling System No. 7 (SS7/C7) architecture.

In this paper, we reviewed the most important archi-tectural developments of the past 25 years leading tothe unrivaled success of the Internet we are witnessingtoday: the evolution of IP networks from the ARPANETto today’s hierarchically structured Internet, and the evo-lution of IP router design from an essentially monolithicarchitecture towards the modern concept of distributed

routers with separated control and forwarding function-ality. We argued that this coevolution of network androuter architectures must converge at some point, and weidentified the centralization of the control functionalityas the next logical step in this process. As [6] phrasesit: “IP routers should be lookup-and-forward switches,forwarding packets as rapidly as possible without beingconcerned about path selection. A separate entity shouldbe responsible for computing the best [...] paths onbehalf of all the routers in a domain and disseminatingthe results to the routers”. We compared distributedand central control architectures from different aspectsof systems engineering and we concluded that centralcontrol brings important benefits, like improved man-ageability and security, more economical operations andbetter performance.

REFERENCES

[1] “Future Internet Network Design – FIND program.” availableonline: http://find.isi.edu.

[2] M. Handley, “Why the Internet only just works?,”BritishTelecom Technology Journal, vol. 24, July 2006.

[3] S. H. Y. Rekhter, T. Li, “A Border Gateway Protocol 4 (BGP-4).” Internet Engineering Task Force: RFC 4271, January 2006.

[4] J. Aweya, “On the design of IP routers part 1: Router architec-tures,” Journal of Systems Architectures, vol. 46, pp. 483–511,April 2000.

[5] Y. Lang, R. Dantu, T. Anderson, and R. Gopal, “Forwardingand control element separation (ForCES) framework.” InternetEngineering Task Force: RFC 3746, April 2004.

[6] N. Feamster, H. Balakrishnan, J. Rexford, A. Shaikh, andK. van der Merwe, “The Case for Separating Routing fromRouters,” inACM SIGCOMM Workshop on Future Directionsin Network Architecture (FDNA), (Portland, OR), September2004.

[7] Z.-L. Zhang, “Decoupling QoS control from core routers:Anovel bandwidth broker architecture for scalable support ofguaranteed services,” inSIGCOMM, pp. 71–83, 2000.

[8] A. Raj and O. C. Ibe, “A survey of IP and multiprotocol labelswitching fast reroute schemes,”Comput. Networks, vol. 51,no. 8, pp. 1882–1907, 2007.

[9] M. Hidell, Decentralized Modular Router Architectures. PhDthesis, Royal Institute of Technology (KTH), Sept. 2006.TRITA-EE 2006:036.

[10] A. Greenberg, G. Hjálmtýsson, D. A. Maltz, A. Myers, J. Rex-ford, G. Xie, H. Yan, J. Zhan, and H. Zhang, “A clean slate4D approach to network control and management,”SIGCOMMComput. Commun. Rev., vol. 35, no. 5, pp. 41–54, 2005.

Fig. 1 enlarged

Fig. 2a enlarged

Fig. 2b enlarged

Fig. 2c enlarged

Fig. 3 enlarged

Fig. 4 enlarged

Fig. 5 enlarged