A Test-bed for Topological Routing in 4-regular Grid Structures

A Test-bed for Topological Routing in 4-regular Grid Structures
of 5
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
  A Test-bed for Topological Routing in 4-regularGrid Structures Tahir M. Riaz, Jens M. Pedersen, Jose G. Lopez, Rasmus H. Nielsen and Ole B. MadsenCenter for Network Planning, Center for TeleInFrastruktur, Aalborg University, Denmarkemail:,,,, Abstract—  The paper presents a test-bed developed forthe visual analysis and demonstration of topological rout-ing in 4-regular grid structures. The 4-regular grid struc-tures are simple, node and line symmetric, planar, yieldgood table free, less complex adaptive routing properties,and have been analyzed extensively to use for the next gen-eration large-scale ICT infrastructures. The test bed wasnamed i3 (intelligent ICT Infrastructure) test-bed. One of the aims was to make it publically available for academicuse and demonstrations. The i3 test-bed consists of 37nodes/computers, among them 36 are local nodes intercon-nected each other in peer to peer fashion, and 37th node isa master node used for controlling and monitoring the lo-cal nodes. The local nodes can be regarded as autonomousmachines making all the routing routing decisions locally.All the nodes are equipted with individual displays in or-der to visualize or monitor the various events. The test-bedprovides a powerfull tool to visually analyze routing andrestoration scenarios. The test-bed is also a proof of con-cept for topological routing in 4-regular grid structures. Index Terms—  Communication Network Topology, Test-bed, 4-regular Grid, Network Planning, Next GenerationNetworks, Topological Routing I. Introduction The large-scale networks, such as Internet, are growingrapidly. There are several factors which are causing thegrowth of the Internet. The most noticeable are addi-tion of new users, increasing number of network devicesper user, convergence of networks and applications, anduser independent network devices such sensor networks etc.Internet is mainly operated on a best effort QoS basis,which has been sufficient for applications such as email,web-browsing, file transfer, but as the realtime applica-tions such as VoIP, video streaming, remote monitoringand control started to use the QoS and reliability demandincreased significantly.Routing and restoration are one of the main impactingfactors for the performance of QoS and reliability. It hasbeen shown in experiments, done in 2001, that it took onaverage three minutes to recover from interdomain pathfailovers, and for some path failovers it even took up tofifteen minutes before the routing tables were established[1]. The dependency on exact and updated tables is a ma- jor problem for the routing schemes, since the size of theInternet makes it impossible to maintain updated tablesof the complete Internet topology; not only would this re-quire huge tables, it would also be extremely bandwidthand resource demanding to keep them updated [2] In or-der to reduce the needs for large tables and easy ways todetermince independent path, networks can be design withglobal structural and topological properties such as the 4-regular grid network structure, and also been suggested abase for a future access network [3], [4], [5], [6].The work for topological routing for 4-regular structurespresented at only theoretical level. There was no workingprototype available to demonstrate the proof of concept.The main aim to develop the test-bed named i3 (intelli-gent ICT Infrastructure) was to realize a working proto-type and also conducting further experiments with creatingvarious scenarios of failures and restoration. The test-beddemonstrator made available publically for academic useand demonstrations. The i3 test-bed consists of total 37nodes/computers (among them are one master and 36 lo-cal nodes). All 36 nodes are interconnected peer to peer,each having four separated gigabit ethernet interfaces witha 4-regular grid structure topology. Apart from the fournetwork interfaces a fifth one is dedicated for communi-cating to master nodes in order to perform various controlfunctions. The local nodes can be seen as autonomous ma-chines making routing decisions locally. Each local nodeis equipted with its own disply in order to visualize ormonitor the events happening on the nodes. A conceptualdiagram of the test-bed is depicted in figure 1.The structure for the rest of the paper is as follows:In Section II definitions for 4-regular grid structures aregiven. The concept of topological routing in 4-regular gridstructures is presented in Section III. Section IV describesvarious test scenarios. In Section V implementation of the test-bed is explained. Results and conclusion are thengiven in Section VI, and finally acknowledgement is madein Section VII. II. Definition for 4-regular Grid Structure As from [7] a 4-regular grid structure  S   can be definedwith node set  V    and line set  E  . Let  dim x  and  dim y  be pos-itive integers. In structure  S   the nodes of   V    are associatedwith a pair of coordinates ( x,y ) such that 0 ≤ x ≤ dim x and 0 ≤ y  ≤ dim y , and every such coordinate pair is as-sociated to a node. There are no two nodes associatedto the same pair of coordinates. So, there are exactly( dim x  +1)( dim y  +1) nodes in  S  . If a node  u  is associ-ated to a coordinate pair ( x u ,y u ), we write  u = ( x u ,y u ) toease the notation. The lines of the grid structure are givenas follows: two nodes ( x u ,y u ) and ( x v ,y v ) connected by aline if and only if   | x u ,y v | + | x u ,y v | = 1. III. Topological Routing Routing in large networks is usually based on tables.However, as network size increases, so do the tables, to- ISBN 978-89-5519-136-3-550-Feb. 17-20, 2008 ICACT 2008  Switch 40" display Cable forSidebandNetwork  Grid Network Monitoring/ConfigNode Fig. 1. A conceptual diagram of the test bed with 3x3 grid structure, controlled by an additional master node connected through a switch,along with a bigger 40 inch display. gether with the overheads created by managing, storingand updating them. The information stored in the tablesis usually insufficient for supporting end-to-end protectedtraffic, making it difficult to provide sufficiently strongguarantees for critical traffic.Topological Routing allows routing based on node ad-dresses only. A simple calculation is performed each timea packet is received by a node, determining the next hop.For Topological Routing to work, the network topologyand addressing scheme must be designed according to aset of guidelines. An example of a topology satisfying therequirements is the 4-regular grid, well known from multi-processor systems.The i3 demonstrator uses this topology to demonstrateTopological Routing in operation. Topological Routingis especially beneficial in large-scale networks, becausemaintaining tables of the complete network topology is aresource-consuming task.For the basic structures, routing as described in [8] isused. Let  p  be a packet with destination ( x v ,y v ). When-ever  p  is received by a node ( x u ,y u ) it is determined if ithas reached its destination. If this is not the case, it is for-warded using the following algorithm, which also applies if ( x u ,y u ) is the source node: •  Let ∆ x = x v − x u  and ∆ y  = y v − y u . •  If ∆ y <  0,  p  can be forwarded to ( x u ,y u − 1), and if ∆ y > 0 to ( x u ,y u  +1). •  If ∆ x <  0,  p  can be forwarded to ( x u − 1 ,y u ), and if ∆ x> 0 to ( x u  +1 ,y u ).If ∆ y  = 0 or ∆ x  = 0, the path is uniquely determined.Otherwise two possibilities exist and a choice must bemade. A random choice can be made, one direction canbe given highest priority such that it is followed wheneverpossible, or the packet can be sent in the direction with Fig. 2. An example of Topological routing in grid structure, a pathis shown for source node  u (1 , 2) to destination node  v (5 , 5). the highest value of ∆. The advantage of the latter ap-proach is that the number of potential paths is the highestpossible in every intermediate node, i.e. in case of an arbi-trary failure the risk of having to route along a longer pathis minimized. This choice can also be used by protectionschemes. In figure 2 an example of topological routing isshown. ISBN 978-89-5519-136-3-551-Feb. 17-20, 2008 ICACT 2008  A. Restoration  If no node or line faillure occurs then the topologicalrouting scheme will always find a shortest path in the net-work. However, failures occur frequently and a routingscheme is therefore important. Considerting the classicaltable based protection approach will again lead to complex-ity in routing. In [4] we have introduced a lake algorithmfor restoration. The algorithm is however not a fully tablefree, but still uses very small size of tables depending uponthe number of nodes or lines fails. The lake algorithm pre-sented in [4] has to be tested with all possible scenarios toensue if it works fully. The test-bed will be able to testvarious trivial and non trivial set of combinations, and canbe monitored visually. IV. Test Scenarios A. Simple topological routing  The addressing scheme is obtained from a classical ( x,y )coordinate system. Each packet is marked by its destina-tion, and in each intermediate node along the route thedistance to the destination is calculated in  x  and  y  direc-tions. In the current implementation, packets are routed inthe  x  direction if possible, and in the  y  direction otherwise. B. SQoS and topological routing  Topological Routing is a part of the concept of Struc-tural Quality of Service (SQoS) based network planning[9]. The aim of SQoS based planning is to design networkinfrastructure with good and well describable structuralproperties. The support for Topological Routing is onesuch property. Other properties include algorithmic sup-port for restoration/protection, robustness and short dis-tances even in case of failures and/or multiple independentpaths. C. Traffic distribution  An other test subject is to test different traffic scenarios.One of the basic traffic petterns is to generate all to alltraffic, which means each node is sending and receivingpackets to/from all other nodes. The traffic load on eachlocal node is displayed on the node’s corresponding display. V. Implementation The core Topological routing functionality is imple-mented by employing C-programming language in the userspace rather than the kernel space using TCP/IP sockets.Linux with gentoo distribution was chosen for the operat-ing system environment. Linux is open source and easyto modify to fulfil the implementation requirements. Thesoftware implementation has been done in a modular fash-ion so that in future upgrades for any other network struc-tures and any new functionality are made easily possiblewithout tearing apart whole software implementation. Allthe local nodes are controlled by the master node from aGUI. For the GUI C++ programming language has beenused, and QT library used for the rendering all kind of graphical objects on the display. A. Functional demands  Following general functional demands are set: •  Local monitoring for routing is done in every node •  Global monitoring is done on the master node •  Logging of the routing protocol document •  Logging of software errors •  Logging of manual packet generation •  Packet generation by the following methods:Stochastic packet generatorPre-programmed sequence - traffic patternsManual packet generation •  Centralized setup of topological addresses of nodes •  Automatic start up of the sideband network •  Support for the lake algorithms •  Support for the hierarchical routingBesides that there some display related demands are settoo. Such as the GUI display must provide information onthe routing both at a distance viewing the whole demon-strator and close up for each node. The global overviewmust be intuitive and provide at-a-glance information. Theclose up information is to be more detailed. Details oneach node are seen on the attached screen. The GUI dis-play must also enable both the display of the progress of asingle packet and of packet streams. B. Interfaces  B.1 User interfaceThe user interfaces are the screens of the system display-ing data. The control interfaces can be either a commandprompt or a command prompt supplemented with a sim-ple graphical interface with checkboxes and menus. Anexample is a combo box for creating a packet. Optionally,the graphic interface should be made intuitive to enableconference participants to use selected functionality.B.2 Communication interfaceThe main interfaces are TCP for the sideband networkand Ethernet on the LLC for the routing algorithms.B.3 Software interfaceThe system interfaces with the Linux windowing system,with Gentoo distribution. C. System modes  The routing of a single packet is performed on a timescale of at most milliseconds. The requirement that thiscan be displayed necessitates control of the time scale. Dis-play of single packets and traffic streams carrying payloadsalso differ; payload usually requires too large a number of packets for individual display. Finally, the packet gener-ation methods are separated. The stochastic method andthe pre-programmed sequences are similar, but conflicting,and the manual input method can be combined with both,given that this is logged. It is thus chosen to give thesystem different modes of functionality. ISBN 978-89-5519-136-3-552-Feb. 17-20, 2008 ICACT 2008  C.1 Routing modes Delay mode:  The packets are routed with sufficient de-lay to display the progress of each packet; the delaycan be configured for each sequence. The display canbe on a hop-by-hop basis or for the whole path. Real time mode:  Data is streamed from one node to an-other at maximum performance and individual pack-ets are not displayed. The main focus is on function-ality and on node and link load.C.2 Packet generation modes Stochastic mode:  Traffic is generated by a stochasticprocess on each node. Controlled mode:  Traffic is generated by the controllernode either manually, by stochastic process or by file. Manual only:  Input is manually only at the particularnode. This is mostly useful for testing of the softwareand finding errors in hardware. This is the easies toimplement and does not require much managementfunctionality. Logging mode:  Traffic can be logged with different de-grees of detail, and both locally on each node and onthe control node. Complete logging:  For each hop all routing data con-cerning a packet is logged on the control node andon the local node. Statistic logging:  General traffic data is logged, such asnumber of packets on a node or link per second.Specifics of each packet is only logged if specificallyselected as an option for the given packet, or in caseof routing failure. D. Configuration and setup Of these the first, configuring the sideband network, isthe least coupled with the others. It is chosen that this isdone separately employing scripting in Linux. It is chosenthat each PC has a static name and a static IP numberon the sideband network. This enables a simple setup andidentification of each node and ensures that a topology canbe planned and mapped to the sideband network. If a dy-namic scheme was chosen, it would become a problem toidentify the individual node to which a configuration is tobe sent for a particular test or demonstration sequence. Forsupport for addition of further nodes it is recommendedthat the assignment is present on the controller node inthe form of a table in a file to which further nodes can beadded. It is not intended that the test nodes should com-municate directly on the sideband network, only controllerto test node communication is foreseen; thus no list is nec-essary on test nodes, only the address of the controllernode. E. Initializing the software on each node  This functionality initializes the specific i3 software oneach node and tests that it is ready to run. The initializa-tion includes reading in configuration files and commandsfrom the controller node. Common data structures are cre-ated and initialized, and pointers are handed to the other Fig. 3. A screenshot of Test-bed showing 36 local nodes setup in-cluding the displays. processes. After this module has run, the other modulesmust be ready to run or error reports must be displayed onthe controller node. It is in this module the test topologyis mapped to physical interfaces on each node. F. Graphical display  This module handles the graphical display of data fromthe routing. The prime function is to convert the numbereddata into easy to grasp graphics on the screens, and toreceive non-command prompt input and return it to therouting mechanisms. G. Routing modules  This module contains the actual routing functionality.Algorithms and local packet generation is located here. H. Management and routing  This functionality performs the communication of log-ging data to the control node and of control informationfrom the control node. On the control node this modulestores the data and processes it. Functionality of this mod-ule is to manage the system environment and to allow agracious halt to routing and re-configuration for a differ-ent test. This module handles changes between differentmodes of the system. Such changes must be possible runtime and by pre-emption of running sequences. VI. Results and Conclusion In figure 3 a screenshot for the 36 local nodes is shown.The nodes are stacked in a rack along the displays in a waythat they could represent the grid topology too. Figure 4shows the display for an individual node. The node ren-ders incoming packets on the display as a small animatedrectangles. The delay between incoming packets and ren-dering on display has been tried to be minimum as possible.To achieve the routing (sending and receiving packets) hasbeen therefore slowed down considerably. The display forthe master node is shown in figure 5. The GUI for master ISBN 978-89-5519-136-3-553-Feb. 17-20, 2008 ICACT 2008  Fig. 4. A screenshot of a local node showing the rendering of packetsmoving in and out of the node.Fig. 5. A screenshot of the master node display showing ControlGUI. nodes provides an overview of whole setup. The status of local nodes, for instance, if a node or line goes down thenit is updated at the master node GUI. It is also possible tomimic a node of line failure using the master node GUI.The implementation of test-bed was done successfully.The test-bed provides a powerfull tool to visually analyzerouting and restoration scenarios. The test-bed is also aproof of concept for topological routing in 4-regular gridstructures. At the moment the topological routing is im-plemented in user space. A kernel space implementationis to be implemented in future to fully test the routingperformance for real world applications. VII. Acknowledgement The author would like to acknowledge Thomas PhillipKnudsen, Johan Christiansen, Lasse Riis for helping duringthe implementation of the test-bed. References [1] Craig Labovitz, Abha Ahuja, Abhijit Bose, and Farnam Ja-hanian, “Delayed internet routing convergence,”  IEEE/ACM Transactions on Networking  , vol. 9, no. 3, pp. 293–306, June2001.[2] Jens M. Pedersen, Thomas P. Knudsen, and Ole B. Madsen, “Onhierarchical extensions of large-scale 4-regular grid network struc-tures,”  Proceedings of PDPTA’04, The International Conference on Parallel and Distributed Processing techniques and Applica-tions, Las Vegas, USA , vol. 2, pp. 738–743, June 2004.[3] Jens M. Pedersen, Thomas P. Knudsen, and Ole B. Madsen,“Topological routing in large-scale networks,”  Proceedings of IEEE/ICACT 2004, The 6th International Conference on Ad-vanced Communication Technology, Korea  , vol. 2, pp. 911–916,2004.[4] Jens M. Pedersen, Ahmed P., Thomas P. Knudsen, and Ole B.Madsen, “Applying 4-regular grid structures in large-scale accessnetworks,”  Computer Communications , October 2006.[5] Tahir M. Riaz, Jens M. Pedersen, and Ole B. Madsen, “Sqosbased planning using 4-regular grid for optical fiber networks,” Proceedings of IEEE/ICACT 2005, The 7th International Con- ference on Advanced Communication Technology, Korea  , vol. 2,pp. 1287–1291, February 2005.[6] Sheng-De Wang and Po-Hwa Sui, “Fault-tolerant routing in two-dimensional mesh networks with less-restricted fault patterns,” Proceedings of the 2001 Pacific Rim International Symposium on Dependable Computing  , pp. 111–118, December 2001.[7] Tahir M. Riaz, Rasum H. Nielsen, Jens M. Pedersen, and Ole B.Madsen, “On line segment length and mapping 4-regular gridstructures in network infrastructures,”  Proceedings of The 5th In-ternational Symposimum on Communication Systems, Networksand Digital Signal Processing  , 2006.[8] Jie Wu, “A fault-tolerant and deadlock-free routing protocol in2d meshes based on odd-even turn model,”  IEEE Transactionson Computers , vol. 52, no. 9, pp. 1154–1158, September 2003.[9] Ole B. Madsen, Thomas. P. Knudsen, and Jens. M. Peder-sen, “SQoS as the Base for Next Generation Global Infrastruc-ture,”  Proceedings of IT&T 2003, Information Technology and Telecommunications Annual Conference 2003, Letterkenny, Ire-land  , pp. 127–136, October 2003. ISBN 978-89-5519-136-3-554-Feb. 17-20, 2008 ICACT 2008
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks