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
Distributed Linked Data Structures for Efficient

Access to Information within Routers
Pier Luca Montessoro, Member, IEEE
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
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 speedup 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
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:
montessoro@uniud.it, www.montessoro.it).
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, oldfashion 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
Pier Luca Montessoro, Distributed Linked Data Structures for Efficient Access to Information within Routers, Proceedings of IEEE 2010
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 receivergenerated 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-DLDSaware 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 (HBDSR) [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.
TABLE I
ESTIMATED NUMBER OF PACKETS FOR COMMON FILE TRANSFERS AND
MULTIMEDIA STREAMS
Data type
average quality JPEG picture

four-minutes MP3 song
one-hour video streaming
one-hour video streaming
two-hours DVD movie
Bitrate
size (kB)
(still)
1,500
128 kb/s
3,840
300 kb/s
135,000
1Mb/s
450,000
4 Mb/s
1,800,000
#packets
1,000
2,560
90,000
300,000
1,200,000
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]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
IETF Congestion Exposure (conex) working group web site,

http://datatracker.ietf.org/wg/conex/charter/
Donald Knuth, The Art of Computer Programming, Vol. 1, 1968 (first
edition)
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
David B. Johnson and David A. Maltz, Protocols for Adaptive Wireless
and Mobile Networking, IEEE Personal Communications, 3(1):34-42,
February 1996
Ping Ji, Zihui Ge, Jim Kurose and Don Towsley. A Comparison of Hardstate and Soft-state Signaling Protocols. Proc. SIGCOMM03,
Karlsruhe, Germany, August 2529, 2003.
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.
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.
Claude Castelluccia, Pars Mutaf, Hash-Based Dynamic Source
Routing, NETWORKING 2004, Book Series Lecture Notes in
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
Computer Science, Volume 3042/2004, pp. 1012-1023, Springer Berlin /

Heidelberg, 2004
Y. Hu, D. Maltz, The Dynamic Source Routing Protocol, Request for
Comments 4728, February 2007
Pier Luca Montessoro, Daniele De Caneva. REBOOK: a deterministic,
robust and scalable resource booking algorithm, DOI 10.1007/s10922010-9167-8, Journal of Network and Systems Management (Springer)
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
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.
Yoichi Hariguchi, ART Allotment Routing Table A Fast Free
Multibit Trie Based Routing Table, http://www.hariguchi.org/art/art.pdf
Hsieh, Sun-Yuan; Huang, Chao-Wen; Huang, Yi-Ling; Yang, YingChi; A Novel Dynamic Router-Tables Design for IP Lookup and
Update, Proc. International Conference on Future Information
Technology (FutureTech 2010)
CYGWIN web site <http://www.cygwin.com>
http://www.xorp.org/
A
R3
R1
B
packet
3 2 4
0
1
2
3
4
R2
R4
Router R1 table
0
1
2
3
4
0
1
2
3
4
Router R2 table
Router R4 table
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
0
1
2
3
4
packet
3 2 4
R3
Router R3 table
R1
B
0
1
2
3
4
R2
R4
Router R1 table
0
1
2
3
4
0
1
2
3
4
Router R2 table
Router R4 table
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
0
1
2
3
4
packet
packet
R3
Router R3 table
R1
B
0
1
2
3
4
R2
R4
2
Router R1 table
0
1
2
3
4
4
Router R2 table
Fig. 4. Route change detection in the stateful approach.
0
1
2
3
4
Router R4 table
packet
R3
3
R1
packet
2
0
1
2
3
4
packet
4
R2
R4
2
Router R1 table
0
1
2
3
4
4
Router R2 table
0
1
2
3
4
Router R4 table
Fig. 3. Stateful routers: the next pointer is stored in the routers table and copied in the packet when it traverses the router.

Distributed Linked DS For Routing Proto

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Distributed Linked DS For Routing Proto

Enviado por

Direitos autorais:

Formatos disponíveis

Pier Luca Montessoro, Distributed Linked Data Structures for Efficient Access to Information within Routers, Proceedings of IEEE

Distributed Linked Data Structures for Efficient

AbstractA key requirement in packet switching networks is

An important issue is how to keep the pointers consistent in

HIS paper introduces the Distributed Linked Data

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

A fundamental underlying concept behind DLDS is the

collected resembles the source routing approaches, used in the

pointer stored in the routers table is set to a conventional

from router Ri+1 the DLDS pointers collection request coming

requires trust. Just like the TCP congestion-control

provided by DLDS overcome the overhead of building and

This DLDS application can be implemented as a new IP

system from unauthorized receiver-driven reservations: during

route to the destination we are looking for, the port

Theoretically, the frequency of route changes should be

average quality JPEG picture

To fully evaluate the potential gain of this approach, Table

IETF Congestion Exposure (conex) working group web site,

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

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

Você também pode gostar