End-Site Routing Support for IPv6 Multihoming

Multihoming is currently widely used to provide fault tolerance and traffic engineering capabilities. It is expected that, as telecommunication costs decrease, its adoption will become more and more prevalent. Current multihoming support is not designed to scale up to the expected number of multihomed sites, so alternative solutions are required, especially for IPv6. In order to preserve interdomain routing scalability, the new multihoming solution has to be compatible with Provider Aggregatable addressing. However, such addressing scheme imposes the configuration of multiple prefixes in multihomed sites, which in turn causes several operational difficulties within those sites that may even result in communication failures when all the ISPs are working properly. In this paper we propose the adoption of Source Address Dependent routing within the multihomed site to overcome the identified difficulties.Publicad

The use of maxLength in the RPKI

This document recommends that operators avoid using the maxLength attribute when issuing Route Origin Authorizations (ROAs) in the Resource Public Key Infrastructure (RPKI). These recommendations complement those in [RFC7115].https://datatracker.ietf.org/doc/draft-yossigi-rpkimaxlen/First author draf

BGP-like TE Capabilities for SHIM6

In this paper we present a comprehensive set of mechanisms that restore to the site administrator the capacity of enforcing traffic engineering (TE) policies in a multiaddressed IPv6 scenario. The mechanisms rely on the ability of SHIM6 to securely perform locator changes in a transparent fashion to transport and application layers. Once an outgoing path has been selected for a communication by proper routing configuration in the site, the source prefix of SHIM6 data packets is rewritten by the site routers to avoid packet discarding due to ingress filtering. The SHIM6 locator preferences exchanged in the context establishment phase are modified by the site routers to influence in the path used for receiving traffic. Scalable deployment is ensured by the stateless nature of these mechanisms.Publicad

Traffic engineering in multihomed sites

It is expected that IPv6 multihomed sites will obtain as many global prefixes as direct providers they have, so traffic engineering techniques currently used in IPv4 multihomed sites is no longer suitable. However, traffic engineering is required for several reasons, and in particular, for being able to properly support multimedia communications. In this paper we present a framework for traffic engineering in IPv6 multihomed sites with multiple global prefixes. Within this framework, we have included several tools such as DNS record manipulation and proper configuration of the policy table defined in RFC 3484. To provide automation in the management of traffic engineering, we analyzed the usage of two mechanisms to configure the policy table.This work has been partly supported by the European Union under the E-Next Project FP6-506869 and by the OPTINET6 project TIC-2003-09042-C03-01.Publicad

Combined Intra- and Inter-domain Traffic Engineering using Hot-Potato Aware Link Weights Optimization

A well-known approach to intradomain traffic engineering consists in finding the set of link weights that minimizes a network-wide objective function for a given intradomain traffic matrix. This approach is inadequate because it ignores a potential impact on interdomain routing. Indeed, the resulting set of link weights may trigger BGP to change the BGP next hop for some destination prefixes, to enforce hot-potato routing policies. In turn, this results in changes in the intradomain traffic matrix that have not been anticipated by the link weights optimizer, possibly leading to degraded network performance. We propose a BGP-aware link weights optimization method that takes these effects into account, and even turns them into an advantage. This method uses the interdomain traffic matrix and other available BGP data, to extend the intradomain topology with external virtual nodes and links, on which all the well-tuned heuristics of a classical link weights optimizer can be applied. A key innovative asset of our method is its ability to also optimize the traffic on the interdomain peering links. We show, using an operational network as a case study, that our approach does so efficiently at almost no extra computational cost.Comment: 12 pages, Short version to be published in ACM SIGMETRICS 2008, International Conference on Measurement and Modeling of Computer Systems, June 2-6, 2008, Annapolis, Maryland, US

Internet routing paths stability model and relation to forwarding paths

Analysis of real datasets to characterize the local stability properties of the Internet routing paths suggests that extending the route selection criteria to account for such property would not increase the routing path length. Nevertheless, even if selecting a more stable routing path could be considered as valuable from a routing perspective, it does not necessarily imply that the associated forwarding path would be more stable. Hence, if the dynamics of the Internet routing and forwarding system show different properties, then one can not straightforwardly derive the one from the other. If this assumption is verified, then the relationship between the stability of the forwarding path (followed by the traffic) and the corresponding routing path as selected by the path-vector routing algorithm requires further characterization. For this purpose, we locally relate, i.e., at the router level, the stability properties of routing path with the corresponding forwarding path. The proposed stability model and measurement results verify this assumption and show that, although the main cause of instability results from the forwarding plane, a second order effect relates forwarding and routing path instability events. This observation provides the first indication that differential stability can safely be taken into account as part of the route selection process