[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Call for contributions
Dear All,
> We are still looking for talks, drafts and papers on both problem
> analysis and proposed solutions. We are not only interested in fully
> worked out schemes, but are also interested in new ideas and are
> especially interested in seeing proposals from researchers.
The locator-id split can be implemented in various ways (shim6, HIP,
LISP, ...). One of the motivations for this split is to reduce the size
of the BGP routing tables. However, I would like to point out that there
are other advantages of such a split, notably from a traffic engineering
viewpoint. We have worked on such schemes during the last years, both
from a shim6 perspective and a LISP perspective and I would like to
summarize some of our results. Several of them have been published in
the scientific literature. I propose to present a summary of our current
work during the RRG meeting in Prague.
A first advantage of locator-id split is that this increases the number
of paths available for the stub ASes or the endsystems. Assuming shim6,
we have shown that when PA addresses are used, the number of disjoint
paths available to the endystems is much larger with a locator-id split
solution than with traditionnal IPv4 multihoming. Our simulations also
show that the end-to-end delay can be significantly reduced. See e.g. :
C. de Launois, B. Quoitin, and O. Bonaventure. Leveraging network
performances with IPv6 multihoming and multiple provider-dependent
aggregatable prefixes. In 3rd International Workshop on QoS in
Multiservice IP Networks (QoSIP 2005), Catania, Italy, February 2-4th
2005, extended version appeared in Computer Networks
Second delay is a traffic engineering objective to be minimised, we have
also shown that virtual coordinate systems could be used to select the
path with the lowest delay without exchanging too many messages, see :
- C. de Launois, S. Uhlig, and O. Bonaventure. Scalable route selection
for IPv6 multihomed sites. In Proceedings of Networking 2005, Waterloo,
Ontario, Canada, May 2-6th 2005.
Third, a common traffic engineering problem for stub ASes is to load
balance their interdomain traffic among its providers. A key advantage
of the locator-id split solutions is that they allow to control both the
incoming and the outgoing traffic while curent IPv4-based multihoming
solutions are only able to efficiently control the flow of the outgoing
traffic. We have addressed this problem by assuming a shim6-like
solution in :
C. de Launois, O. Bonaventure, and M. Lobelle. The NAROS approach for
IPv6 multihoming with traffic engineering. In 4th COST 263 International
Workshop on Quality of Future Internet Services (QoFIS 2003), volume
LNCS 2811, pages 112-121, Stockholm, Sweden, October 1-3rd 2003.
Springer-Verlag.
These papers are available from
http://totem.info.ucl.ac.be/publications.html
For a LISP-like solution, similar resultats have been obtained in
chapter 5 of Bruno Quoitin's PhD thesis entitled "BGP-based Interdomain
Traffic Engineering" and published in September 2006
( http://www.info.ucl.ac.be/~bqu/academic.html )
This chapter is a revised version of earlier work on the utilization of
tunnels :
B. Quoitin and O. Bonaventure. A cooperative approach to interdomain
traffic engineering. In 1st Conference on Next Generation Internet
Networks Traffic Engineering (NGI 2005), Rome, Italy, April 18-20th 2005
See also
O. Bonaventure, C. de Launois, B. Quoitin, M. Yanuzzi, Improving the
quality of interdomain paths by using IP tunnels and the DNS,
unpublished technical report, January 2005, available from
http://www.info.ucl.ac.be/~obo/papers/tr-improving.pdf
From an implementation viewpoint, we are interested in both shim6-like
solutions and LISP-like solutions. We are currently implementing shim6
in the Linux kernel, see http://gforge.info.ucl.ac.be/projects/shim6
We are also interested in developing an implementation for a LISP-like
solution.
We are willing to contribute to the work of the RRG. Due to time
constraints, we could not write an internet draft in ASCII format but
are ready to write one for the next RRG meeting.
Best regards,
Olivier Bonaventure
--
CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/~obo
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg