Distributed Linked DS for Routing Proto

Pier Luca Montessoro, Distributed Linked Data Structures for Efficient Access to Information within Routers, Proceedings of IEEE 2010 International Conference on Ultra Modern Telecommunications, 18-20 October 2010, Moscow (Russia), pp. 335-342, ISSN: 2157-0221, print ISBN 978-1-4244-7285-7, DOI: 10.1109/ICUMT.2010.5676616 Authors private draft do not distribute

AbstractA key requirement in packet switching networks is

an efficient way to access information stored within the routers. The most obvious example is the routing table and its associated forwarding information, accessed at least once for each packet traversing the router, but advanced protocols may require to store and access flow state information too, adding scalability problems as well.

This paper introduces an innovative, highly efficient way to exploit the cooperation between end nodes and intermediate systems based on Distributed Linked Data Structures. When integrated in network protocols (for example as a new IP option field), they provide the router the memory addresses needed to access the required information without the need of searching. This leads to constant cost procedures, increasing performance and overcoming scalability problems.

DLDS may support several different applications, some of which are presented in the paper; prototypal implementations have been developed to validate the technique and to measure performance.

Index Termsdistributed data structures; linked data structures; routing tables lookup; resource reservation; dynamic source routing

I. INTRODUCTION HIS paper introduces the Distributed Linked Data Structure(s): an efficient software solution to the limits in

efficiency and scalability of the conventional search-based techniques to access information stored in the intermediate systems (typically routers) of a packet network.

DLDS are linked data structures that keep pointers to memory locations or to table entries containing information stored in the routers that are very likely to be accessed in the future since needed to process all the packets of a flow. They are distributed too, since each pointer is not stored within the router it addresses. And, at last, they are dynamic, since the collection of pointers is dynamically built and travels along the routes between the end nodes attached to transmitted data packets.

P. L. Montessoro is with the Dep. of Electrical, Managerial and Mechanical

Engineering, University of Udine, Via delle Scienze 208, 33100 Udine, Italy (phone: +39 0432 558286; fax: +39 0432 558251; e-mail: [email protected], www.montessoro.it).

An important issue is how to keep the pointers consistent in a dynamic environment, and in the following a specific integrity check will be introduced.

DLDS have many applications; routing table lookup, dynamic source routing, and resource reservation for QoS guaranteed services represent the most evident ones and are discussed in this paper. For all of them, DLDS provide access to the stored information at constant cost, drastically reducing the need for searching and overcoming the scalability problems when the amount of stored information increases. DLDS can be used in several directions, for example to speed-up cheap software-based routers. But DLDS management is not complex and can be implemented in hardware; so, dedicated hardware solutions may be used to implement in core routers scalable dynamic resource reservation protocols.

In the following, after a summary of related work in Section II, Section III discusses DLDS building and management and Section IV presents the three applications cited above. Implementation issues and experimental results are presented in Section V, whereas Section VI draws some conclusions.

II. RELATED WORK A fundamental underlying concept behind DLDS is the

need for more cooperation between intermediate systems and end nodes in a packet network. The IETF Congestion Exposure (conex) working group [1], for example, represents a recent effort to increase this cooperation in order to enable a form of communication between senders and network nodes about the levels of congestion.

The DLDS idea comes from the old, powerful, dynamic linked data structures [2] that are so familiar to every good programmer. Linked data structures are today quite common in distributed environment since are the basis for distributed file systems, parallel and distributed database systems, etc. However, for these applications the links are often loose, in the sense that they are based on keys and strings rather than on memory addresses. Instead, the proposed DLDS are real, old-fashion linked data structures because they make use of pointers to memory locations and table entries within the routers.

The way DLDS are used once the pointers have been

Distributed Linked Data Structures for Efficient Access to Information within Routers

Pier Luca Montessoro, Member, IEEE

T


collected resembles the source routing approaches, used in the old Token Ring network (IEEE 802.5 standard) and in the much more recent Dynamic Source Routing protocol (DSR) [3][4] for mobile wireless networks. The distributed storage of pointers in stateful routers, described in Section III.B, is somewhat similar to the label swapping techniques of Asynchronous Transfer Mode (ATM, limited to a specific and almost obsolete context) or to Multi-Protocol Label Switching (MPLS). DLDS, however, do not require complex control protocols nor any change in the underlying routing, are scalable, and provide fast information retrieval in the internal routers data structures.

DLDS may be used to support existing protocols or to implement new features. In the latter case, new, ad hoc protocols can be developed, but most applications require only that a new IP option field be designed.

III. DISTRIBUTED LINKED DATA STRUCTURES The basic idea of the proposed technique is to build a

Distributed Linked Data Structure containing pointers to the memory addresses in routers tables where are stored information that are likely to be frequently accessed in the future. Routing information within the routing tables probably represent the most obvious example. For each packet belonging to a data flow (longer than a single packet), a stateless router will look up in its routing table each time searching for the same information. Forwarding tables in stateful routers reduce the space of search but require flow information handling. DLDS can provide direct access to the target routing table entry without any special hardware or software architecture.

A DLDS can be built with different levels of impact on the routers, depending on the stateless or stateful nature of the application and on the design of possible future protocols exploiting the proposed approach. Similar considerations apply about the direction in which the route is traversed to collect the memory addresses.

In the following are presented at first the stateless and stateful approaches and then the forward and backward techniques to collect the memory pointers.

A. Stateless routers Figure 1 shows a DLDS for stateless routers. The packet

contains (for example in a new DLDS IP option field) an ordered array of pointers; with the hop counter each router selects the pointer to be used. With this pointer the information is read from memory, saving the cost of searching. Of course something could have changed the tables within the router and the retrieved information could be no longer valid. To confirm its validity a simple but crucial integrity check is performed: the pointer must point to a valid location (see below) and the target information in the packet

must match the one stored in the table. For example, the destination address contained in the { destination address, output port } pair retrieved from the routing table must match the destination address stored in the packet. Or, for a flow oriented or virtual circuit routing, the flow/circuit ID in the table must match the ID in the packet.

Figure 2 shows what happens in case of mismatch due to a route change. The same array of pointers seen in Figure 1 is rerouted through router R3 instead of R2. The integrity check fails because (in the same example as above) the destination stored in the packet does not match the one found in the addressed routing table entry. The pointers within the packet are invalidated and this will trigger a new pointer collection procedure at the end nodes. Please note the importance, in the integrity check, of the verification that the pointer is within the range mentioned above. In a router different from the correct one the table can be smaller and a memory access violation can occur. Another range that must be checked is the hop counter vs. the size of the array of pointers: if a route change makes the path become longer than the original one, the pointer selection must fail if the hop counter exceeds the number of pointers stored in the packet.

B. Stateful routers The stateless approach does not require any additional

information to be stored within the routers, but the packet must make room for an array whose size increases linearly with the route length. If some per-flow information is already (or can be) stored in the router tables, the pointers can be stored in these tables too, reducing the packet size increase to a single pointer.

Figure 3 shows an example of such a DLDS for stateful routers for the same network depicted above. Each time a DLDS-aware packet traverse a router, the pointer it contains is used to access both the information and the next pointer; then, the next pointer is copied in the packet to replace the one just used.

Stateful approaches suffer the problem of possible obsolete entries that must be identified and removed. Benefits and limitations of hard and soft state approaches have been discussed in literature [5] and lie beyond the purpose of this paper. However, for our purposes, a simple and effective solution is using a soft-state approach, providing a time stamp associated to each table entry that is updated each time a packet addresses that entry. A background, low-priority process is used to cleanup the table removing the entries whose timestamps are older than a given threshold.

The integrity check for the stateful approach is simpler than the stateless one since the hop counter is no longer used. If a route change occurs in the middle of the path, the information accessed using the next pointer will not match, as shown in Figure 4. If a route change affects the last hop, the next


pointer stored in the routers table is set to a conventional invalid value (e.g., -1, the white field in router R4 table) and in the next router this pointer will be found out of range.

C. Forward pointers collection In order to have a usable DLDS, a pointers collection

phase is required. Depending on the application and on routing, it can work from source to sink or vice versa (in respect of the direction of the packets the descriptions above refer to).

In the forward pointer collection, a packet with an empty DLDS option field is sent by the source. Each router performs the conventional table lookup and, before forwarding the packet, it stores in the option field the pointer resulting from the table lookup procedure. At the end of the route the sink sends back to the source the collection of pointers.

The sink will monitor the DLDS option field in subsequent packets to check if pointers are invalidated. If so, a request for a new pointer collection activation is sent to the source.

It is worth notice that the forward collection is compatible with asymmetrical routing since the messages from sink to source need not to be processed by routers belonging to the path.

For stateful routers the DLDS pointers collection packet does not store the pointers (thus its size is reduced). Instead, it triggers a backward pointer notification message that communicates to the previous router (or to the source in case of the first router) the pointer to be stored in the table entry. It is not required that this communication is reliable. If the backward message is lost, the pointer in the previous router is left unassigned (initialization value). When it will be received by the router in subsequent data packets a conventional lookup will take place and the resulting pointer is sent back (again) to the previous router.

D. Backward pointers collection For some applications a backward pointer collection is

preferable. Typical examples are the receiver-initiated protocols, like RSVP [12].

A backward pointers collection can be very efficient when routing is symmetrical, that is, forward and backward communications between two end nodes traverse the same routers in reverse order. For our purposes, symmetrical routing allows to collect the pointers in reverse order while a single packet travels from the sink to the source. This eliminates the need of the final message from the sink to the source to send the collection of pointers. Moreover, for the stateful approach, a router can communicate its pointer to the previous router in the path in the same pointers collection message, without the need for the additional backward pointer notification message described above.

Here is how it works for stateful routers. Router Ri in the path (routers are enumerated from source to sink) receives

from router Ri+1 the DLDS pointers collection request coming from the sink. This message contains the pointer Pi+1 to the table in the router Ri+1. Router Ri performs a flow information table lookup to access the information belonging to the flow whose identifier is written in the DLDS pointer collection request. If the request is embedded in the flow setup packets, this information is not yet available, and a new entry in flow information table is created. In any case, the pointer to the entry is written in the DLDS packet. The packet is then forwarded to router Ri-1, toward the source of the flow.

To speed-up both the access to flow information and the packets forwarding process, the entry in the flow information table should contain a link to the routing table information used to forward the data packets to the sink. To store this information at this time (the current packet is directed to the source) an additional routing table lookup is required. However, this information can be left unassigned and set the first time a data packed belonging to this flow is routed.

In case of stateless routers, the backward pointers collection process is similar, but no flow information table is used. Pointers are collected in the DLDS pointers collection request packet routed to the sink. The sink will reverse the order of the pointers in the received array and will copy them in the DLDS option field of subsequent data packets.

If symmetrical routing is not available, the receiver-generated pointers collection must be arranged in a two-pass process, the first signalling from sink to source the need for pointer collection and the second performing a standard forward collection.

E. Reliability and robustness Every programmer experienced the dramatic consequences

of a broken link in a dynamic data structure. In a distributed, dynamic environment this event can occur and must be handled. (Luckily, it is not frequent, since if it occurred very often the speed-up provided by the DLDS would be overridden by the pointers collection cost).

The procedures described above to manage the DLDS are tolerant to errors, node faults and loss of messages. The integrity check performed before using the information obtained by the DLDS pointers preserves the integrity of the system, invalidating the data structure when necessary. The soft state approach and the background table cleanup process remove obsolete information. Conventional table lookup procedures are used when the DLDS fail to provide direct access, thus preserving the overall system functionality.

In the future, advanced DLDS designs could be developed to increase the speed-up provided that the integrity of DLDS links is guaranteed by the network, but this is left to further investigations.

F. Security Cooperation between intermediate systems and end systems


requires trust. Just like the TCP congestion-control mechanism, DLDS work as soon as all the participating nodes behave as expected.

A very nice security-related aspect of DLDS is that each router stores in the packets, and later reads, its own pointer; no other entity needs to understand the content of that information. This means that a fast and robust symmetrical cryptographic schema can be used to protect the pointer. No key exchange is needed.

However, most of the foreseen applications use DLDS to speed-up the access to information stored in the routers, so there is no advantage for an unfaithful node that stores or communicates invalid pointers. The only security issue comes from possible DoS (Denial of Service) attacks. Anyhow, conventional lookup procedures are still available, and the effects of a possible DoS attack would be very limited: the first node failing the consistency check would invalidate or remove the DLDS option field and the remaining of the route would be traversed in the conventional DLDS-unaware manner.

However, several possible applications are related to specific highly controlled environment such as wireless sensor networks (WSN), video-on-demand distribution (where end nodes are proprietary set-top boxes), etc. For most critical applications, nodes authentication and data encryption mechanisms already developed for other protocols can be applied. More detailed studies will be required after the applications have been designed, but this is beyond of the scope of this paper.

G. Deployment DLDS-unaware routers can coexist with DLDS-aware

routers in the same network. The hop counter update and the pointer selection will take place in DLDS-aware routers only, whereas DLDS-unaware routers will ignore the DLDS option field and behave as normally. In [10] an experiment of partial deployment is described for the specific application of resource reservation.

In case of DLDS-unaware hosts the DLDS building procedure would not even be initiated. However, progressive and partial deployment of applications exploiting the proposed techniques can be foreseen. For example, access routers, firewalls or proxy servers can be used to intercept data packets and create and handle the DLDS option field. Moreover, DLDS can become synergic to some higher level techniques like traffic shaping and stateful packet inspection.

IV. APPLICATIONS DLDS can provide an efficient support to several

applications, some of which are discussed below. In general, whenever some information stored in intermediate nodes must be accessed often, the benefits coming from direct access

provided by DLDS overcome the overhead of building and maintaining the links. This tradeoff is analyzed in the next section.

A. Routing information Making faster the access to routing information has been

addressed by many research projects; [6] and [7] represent some interesting recent examples. The common, basic consideration is that the main computational cost in routers comes from accessing the routing tables to forward the incoming packets. Here is where packet switching pays for its simplicity and robustness. To increase efficiency both software solutions based on advanced data structures [6] and specialized hardware architectures [7] have been developed.

DLDS can speed up this fundamental task by recording at the beginning of a flow the memory addresses where the target routing information has been found, and later using these addresses to avoid repeated, identical, table lookups. Although DLDS management can be implemented in hardware, its adoption in hardware-based routers may require some router redesign. On the other hand, its implementation on software-based routers (e.g., routers based on XORP [15]) is straightforward.

Both stateless and stateful approaches can be used. The first requires that the data packets store the whole list of addresses in the DLDS option field, in a sort of source routing fashion. With the stateful approach a flow information entry must be stored within the router. Apparently, this is wasteful if limited to serve the routing table lookup only, but in case of long flows, such as multimedia streams, it may yield large savings. Moreover, for multimedia streams the same DLDS can be shared by routing table lookup and QoS management procedures (see resource reservation, below).

The longest prefix match problem plays a key role in routing table lookup efficiency, and it becomes an issue with the increased length of IPv6 addresses. As long as the routing is stable, with DLDS this problem is reduced from once per packet to once per flow (only the first packet triggers a table lookup using the IPv6 address as search key). Since in today networks routing is quite stable for the duration of a flow (especially for fixed or low-mobility nodes) many packets will benefit from DLDS before a route change (if any) triggers a new DLDS setup.

It must be kept in mind that DLDS are not used to take decision about forwarding, but only to quickly access the information on which the decision is taken. This means that if the routing changes or a pointer becomes corrupted, the integrity check will invalidate the DLDS and a conventional table lookup will be activated. Therefore, the packet will be always forwarded to the up-to-date route (in Figure 2, R3 is the right node to be traversed, even if the DLDS is no longer valid).


This DLDS application can be implemented as a new IP

packet option and used only by the DLDS-aware routers when the sender and the receiver are DLDS-aware as well. Therefore, it can be easily deployed gradually; non-DLDS-aware traversed routers will be transparent to the option field.

In conclusion, DLDS can speed-up conventional routers, reduce the need of expensive and energy-consuming dedicated hardware architectures and allow the development of software-based high-performance routers.

B. DSR enhancement Dynamic Source Routing (DSR) [3][4] is a routing protocol

designed for use in multi-hop wireless ad hoc networks of mobile nodes. Source nodes discover routes to destinations in the ad hoc network and later use these information to store in data packets the sequence of intermediate nodes to be traversed. A major limitation of DSR is the increase of packets size for large networks. This issue becomes much more evident when IPv6 addresses are used. Some work addressed this problem, e.g. Hash-Based Dynamic Source Routing (HB-DSR) [8].

In [9] the Flow ID option is added. Intermediate nodes store a Flow Table to be used to forward packets along an established flow and the complete list of addresses is no longer stored in the packets. These intermediate nodes become stateful routers: a DLDS built with the forward pointer collection procedure perfectly fits this schema. A simple extension to [9] can avoid the table lookup cost when Flow IDs are used. Since DSR is targeted for wireless mobile networks, the energy saving provided by DLDS may be even more important than the speed-up. Moreover, no additional procedure is required for table cleanup since DSR already provides a mechanism to remove the obsolete entries.

C. Resource reservation In [10] a resource booking algorithm (REBOOK) based on

DLDS is presented. It provides deterministic, fast (real-time) dynamic resource allocation and release. Based on a stateful approach, it handles faults and network errors, and recovers from route changes and unexpected flows shutdown. The DLDS scheme guarantees constant complexity regardless the number of active flows.

The REBOOK implementation discussed in [11] has been used to validate the algorithm and to measure performances; moreover, the feasibility of progressive deployment has been demonstrated in a real-world emulated scenario. However, the presented implementation is sender-driven as the underlying DLDS is built by a forward pointers collection procedure. A natural candidate to play the role of hosting protocol for the REBOOK algorithm is RSVP [12], which is receiver-oriented. Therefore, the backward pointers collection procedure described above should be used. It is worthwhile to notice that in this case the backward pointer collection must preserve the

system from unauthorized receiver-driven reservations: during the backward phase the pointers are collected but no actual reservation is taken; then, after the sender (typically a multimedia server) has authenticated the user and established the due quality (e.g., bandwidth), the reservations are committed by packets travelling from the server to the user.

V. IMPLEMENTATION ISSUES AND PERFORMANCE ANALYSIS Several schemes for DLDS setup and management have

been presented in Section III, and each application can use more than one of them. Every single combination of techniques would require a detailed analysis, far beyond the available space and purposes of this paper. Anyhow, some general considerations can be drawn. The DLDS application to speed-up routing information access will be used as reference.

The parameters that must be considered for performance evaluation are:

DLDS setup overhead CPU time; increase in data packets size; increase in table lookup efficiency.

The first one could be considered marginal, since it affects only the first packet of a flow. Since the sender is responsible for insertion of the option field that will trigger the pointers collection, this option can be omitted if the requested data is small and would produce a very short flow. Anyhow, the overhead would be limited to a deferred memory access to store in the option field the address (or index) obtained by the normal table lookup procedure. (Since the packet has been modified, the checksum must be recalculated, but it is true anyway, because at least the Time To Live field must be updated).

Since the first packet carrying the DLDS option in a flow must reserve enough room for all the pointers along the path, the maximum network diameter should be used to dimension the array of pointers. As soon as this list returns to the sender, the actual route length will be used, and the average packet length increase will be proportional to the average route length in the network. Please note that the DLDS option is inserted by the sender when the packet is assembled, so the increased header size will not require packet fragmentation.

Even the usage of an already established DLDS has some overhead: the pointer must be extracted from the option field, using the hop counter as index. Moreover, the consistency check must compare the hop counter and the route length of the flow (stored in the option field as well), the pointer value with the valid range for a pointer in the current node, and the addressed table entry with the final destination of the packet. Figure 5a summarizes the procedure. The hop counter stored in the option field is used to get the current pointer, and then the hop counter is increased by one. If the pointer is within the valid range and the addressed routing table entry gives the


route to the destination we are looking for, the port information can be immediately used to forward the packet. If not, a conventional table lookup will take place and the DLDS option field will be invalidated.

1. increment the hop counter in the packet; 2. perform the consistency check:

2a. check if the current hop counter is within the path length;

2b. check if the pointer addressed using the hop counter as index is within the routers table size;

2c. check if the destination in the table entry is still the same on the packet;

3. if the consistency check fails: 3a. invalidate the DSDS option field; 3b. perform a conventional table lookup;

4. forward the packet.

Fig. 5a. DLDS usage for routing table lookup ptr_index = pckt.DLDSopt.hop_cnt++; if ( ptr_index > pckt.DLDSopt.path_len || (ptr = pckt.DLDSopt.pointers[ptr_index]) > MAXptr || ptr->dst != pckt.dst) { /* invalidate the DLDS option field */ pckt.DLDSopt.path_len = -1; ptr = table_lookup (pckt.dst); } forward_to (ptr->port);

Fig. 5b. Example of DLDS implementation in C language for routing table lookup

Theoretically, the frequency of route changes should be

taken into account, too. Anyhow, routing in today networks is enough stable (for the duration of a flow) than this issue can be neglected.

According to [13] and [14] some of the best lookup techniques, including ones adopting multibit and multi-prefix trie-based routing tables, perform as follows: 0.63 10 millions table lookups per second on a Pentium III 1 GHz [13] and 5,395-13,352 clock cycles / single lookup [14]. To compare these values with the DLDS approach a linear routing table (array of { destination IP address, output port } pairs) has been populated with 100.000 random-generated entries. Then, 100 millions table lookups have been executed using the code of Figure 5b on a Pentium M, 1.2 GHz tablet PC (this old computer has been chosen in order to get results as much comparable as possible with [13]). Over several runs, in average the total CPU time has been about 1.2 seconds, that means 83 millions routing table accesses per second, more than eight times faster than the best result in [13]. This is not surprising because DLDS, as said, guarantee information access at constant cost, regardless the table size.

Data type Bitrate size (kB) #packetsaverage quality JPEG picture (still) 1,500 1,000four-minutes MP3 song 128 kb/s 3,840 2,560one-hour video streaming 300 kb/s 135,000 90,000one-hour video streaming 1Mb/s 450,000 300,000two-hours DVD movie 4 Mb/s 1,800,000 1,200,000

TABLE I

ESTIMATED NUMBER OF PACKETS FOR COMMON FILE TRANSFERS AND MULTIMEDIA STREAMS

To fully evaluate the potential gain of this approach, Table

1 shows the estimate number of packets generated by some file transfers. The speed-up obtained for a single packet must be multiplied by the number of packets in the flow, with the only additional cost (once per flow) of the pointers collection phase ad the transmission of the array of collected pointer from the receiver to the sender. In a peer-to-peer environment the flow could be split in several partial data transfers; in this case the setup overhead must be considered once per peer instead of once per flow. Anyhow, peer-to-peer networks are used for large data files; the number of packets sent by each peer is still large enough to leave nearly unchanged the obtainable speed-up.

For the stateful approach (Section III.B), another issue about performance is the table cleanup cost. Since table entries can be organized as used and free lists, complexity is linear with the number of used entries. A cleanup procedure have been implemented and tested on a Pentium 4 personal computer, 2.80 GHz, 512 MB RAM running Windows XP SP3 and CYGWIN [16]. With an average number of used entries of 5.000.000, and an average expiration probability of 1%, each table cleanup activation required only 100 ms CPU time.

VI. CONCLUSION AND FUTURE WORK In this paper a way to exploit the cooperation between end

nodes and intermediate systems in a packet switching network have been presented. Based on Dynamic Linked Data Structures (DLDS), it provides efficient and scalable access to information stored in the routers.

Implementation issues to apply DLDS to routing table lookup, Dynamic Source Routing and resource reservation have been discussed. Performance evaluations have been reported.

Future research directions are focused on developing an application framework for DLDS usage based on the definition of a new IP option field; with this framework it will be possible to measure on real networks the speed-up provided by DLDS for routing table access. Another future work direction is the design of an RSVP extension to overcome with DLDS its scalability problems.


REFERENCES

[1] IETF Congestion Exposure (conex) working group web site, http://datatracker.ietf.org/wg/conex/charter/

[2] Donald Knuth, The Art of Computer Programming, Vol. 1, 1968 (first edition)

[3] David B. Johnson and David A. Maltz, Dynamic Source Routing in Ad Hoc Wireless Networks., Mobile Computing, edited by Tomasz Imielinski and Hank Korth, chapter 5, pages 153-181. Kluwer Academic Publishers, 1996

[4] David B. Johnson and David A. Maltz, Protocols for Adaptive Wireless and Mobile Networking, IEEE Personal Communications, 3(1):34-42, February 1996

[5] Ping Ji, Zihui Ge, Jim Kurose and Don Towsley. A Comparison of Hard-state and Soft-state Signaling Protocols. Proc. SIGCOMM03, Karlsruhe, Germany, August 2529, 2003.

[6] S. M. Yong, H.T. Ewe, "Robust Routing Table Design for IPv6 Lookup," Third International Conference on Information Technology and Applications (ICITA'05), vol. 1, pp. 531-536, 2005.

[7] Yuan-Sun Chu, Po-Feng Lin, Jia-Huang Lin, Hui-Kai Su, Ming-Jen Chen, ASIC design of fast IP-lookup for next generation IP router, ISCAS 2005, IEEE International Symposium on Circuits and Systems, 23-26 May 2005, pp. 3825 3828, Vol. 4.

[8] Claude Castelluccia, Pars Mutaf, Hash-Based Dynamic Source Routing, NETWORKING 2004, Book Series Lecture Notes in

Computer Science, Volume 3042/2004, pp. 1012-1023, Springer Berlin / Heidelberg, 2004

[9] Y. Hu, D. Maltz, The Dynamic Source Routing Protocol, Request for Comments 4728, February 2007

[10] Pier Luca Montessoro, Daniele De Caneva. REBOOK: a deterministic, robust and scalable resource booking algorithm, DOI 10.1007/s10922-010-9167-8, Journal of Network and Systems Management (Springer)

[11] P. L. Montessoro , D. De Caneva. A Distributed Algorithm for Efficient and Scalable Resource Booking Management, Proceedings of CTRQ 2010 Third International Conference on Communication Theory, Reliability, and Quality of Service, June 13-19, 2010 - Athens/Glyfada (Greece), pp. 128-134

[12] Lixia Zhang, Stephen E. Deering, Deborah Estrin, Scott Shenker and Daniel Zappala. RSVP: A new resource ReSerVation Protocol. IEEE Network, Vol. 7, Issue 5, pp. 8-18, September 1993.

[13] Yoichi Hariguchi, ART Allotment Routing Table A Fast Free Multibit Trie Based Routing Table, http://www.hariguchi.org/art/art.pdf

[14] Hsieh, Sun-Yuan; Huang, Chao-Wen; Huang, Yi-Ling; Yang, Ying-Chi; A Novel Dynamic Router-Tables Design for IP Lookup and Update, Proc. International Conference on Future Information Technology (FutureTech 2010)

[15] CYGWIN web site [16] http://www.xorp.org/

A

R1

R2

R3

R4

B

A

R1

R2

R3

R4

B

A

R1

R2

R3

R4

B

Router R1 table

packet

Router R2 table Router R4 table

01234

01234

01234

3 2 4

Fig. 1. The basic idea: packets traversing the routers belonging to a path contain memory pointers for direct access to stored information. The hop counter is used to select the memory pointer to be used.


A

R1

R2

R3

R4

B

A

R1

R2

R3

R4

B

A

R1

R2

R3

R4

B

Router R1 table

packet


Router R3 table

?

01234

01234

01234

3 2 4

01234

Fig. 2. After a route change some memory pointer will be out of range or will address wrong information. The target information stored in the packet does not match the one addressed in the routers table. Mode is switched back to conventional lookup and pointers are reset.

A

R1

R2

R3

R4

B

A

R1

R2

R3

R4

B

A

R1

R2

R3

R4

B

Router R1 table

packet


Router R3 table

packet

?

01234

01234

01234

3

2

4

2

01234

Fig. 4. Route change detection in the stateful approach.


A

R1

R2

R3

R4

B

A

R1

R2

R3

R4

B

A

R1

R2

R3

R4

B

Router R1 table

packet


packet

01234

01234

01234

3

2

2

4

4

packet

Fig. 3. Stateful routers: the next pointer is stored in the routers table and copied in the packet when it traverses the router.

Documents

Distributed Linked DS for Routing Proto