Rights:
Atribución-NoComercial-SinDerivadas 3.0 España
Abstract:
La presente Tesis propone una arquitectura para la provisión de una solución de multihoming escalable y de la exploración de distintos enfoques. La solución actualmente disponible en IPv4 para el soporte de multihoming basada en la inyección de rutas de sitio La presente Tesis propone una arquitectura para la provisión de una solución de multihoming escalable y de la exploración de distintos enfoques. La solución actualmente disponible en IPv4 para el soporte de multihoming basada en la inyección de rutas de sitio en el sistema global de rutas impone una carga que crece linealmente con el número de sitios multihomed, lo que limita su escalabilidad y las posibilidades de crecimiento. La presente Tesis plantea una solución alternativa que garantice la escalabilidad del sistema global de rutas basada en el uso de direcciones agregables por proveedor (PA). En una configuración basada en direcciones PA, un sitio multihomed obtiene tantos bloques de dirección como proveedores tiene lo que plantea las dificultades con los filtros de ingreso, con el iniciar una nueva comunicaciones después de un fallo y la preservación de comunicaciones ante la ocurrencia de un fallo. La presente Tesis Doctoral plantea una arquitectura para solventar estos problemas basada en el encaminamiento basado en dirección origen para proveer compatibilidad con los filtros de ingreso, y una nueva capa de identificación dentro de la capa IP para brindar las capacidades requeridas de tolerancia de fallos.
________________________________________________[+][-]
In this Thesis we propose an architecture for the provision of scalable IPv6 multihoming support. In the multihoming solution currently deployed in the IPv4 Internet, the multihomed site announces a route to its address blocks through all the providers using BIn this Thesis we propose an architecture for the provision of scalable IPv6 multihoming support. In the multihoming solution currently deployed in the IPv4 Internet, the multihomed site announces a route to its address blocks through all the providers using BGP. The result is that
multiple routes towards the multihomed site are available in the inter-domain routing system.
While this solution provides the fault tolerance and path selection features required to a
multihoming solution, it presents limited scalability, since each multihomed site contributes with
at least one routing table entry in the already oversized inter-domain routing tables.
Because the support of the multihoming solution currently deployed in the IPv4 Internet is
becoming challenging even for the current number of multihomed sites, this approach is deemed
unsuitable for the expected number of multihomed sites in the future IPv6 Internet, especially
when considering that the wide adoption of low-budget broadband access technologies such as
ADSL or CATV will enable multihoming in SOHO environments. As a consequence, an
alternative multihoming solution for IPv6 is needed. The requirements imposed to the new
solution essentially include all the benefits provided by the incumbent solution, i.e. fault tolerance
and traffic engineering capabilities, and also an enhanced scalability with respect to the number of
multi-homed sites and other relevant Internet parameters. In order to preserve routing system
scalability, aggressive route aggregation can be achieved through provider-based aggregation,
precluding the injection of routes associated with individual multi-homed end-sites. When
Provider Aggregatable (hereafter PA) addressing is used, multi-homed sites obtain one prefix per
each one of their providers. Consequently, as each provider will only announce its own prefix to
the rest of the Internet, a given provider will be used to reach the multihomed site only when the
destination addresses used belong to the prefix associated with the provider. So, in order to be
reachable through all of the providers of the site, each host within the multihomed site will have
to configure multiple addresses, one per provider.
Even if this setup guarantees the scalability of the multihoming solution, such multi-addressed
configuration is not without difficulties of its own when attempting to provide the additional
features mentioned above. In particular, this configuration presents the following problems:
- Incompatibility with ingress filtering techniques: The incompatibility is caused by the
lack of coordination between the IPv6 source address selection mechanism, performed by
the host, and the path selection mechanism, performed by the intra-site routing system.
As long as outgoing packets are routed through the provider that has delegated the prefix
contained in the source address, packets will flow freely; but when those packets are
routed through a different ISP, they will be discarded by the ingress filtering mechanism
x
due to source address incompatibility. It must be noted that because of this issue, packets
may be discarded even in a scenario without failures.
- Difficulties when establishing new communications after an outage. The difficulties arise
because not all of the addresses available for a multihomed host are reachable, so in order
to be able to communicate, hosts need to properly discard unreachable addresses and
select those addresses that are reacahable. Current address selection mechanisms are
unable to cope with such situation.
- Difficulties when preserving established communications. In order to preserve
established communications through outages, the endpoints of the communication have to
adapt the addresses used during the lifetime of the communication according to the
available providers. Moreover, this address replacement has to be performed in a
transparent fashion with respect to transport and application layers, in order to actually
preserve the established communication. Current applications and transport layers, such
as TCP and UDP, identify the endpoints of a communication through the IP addresses of
the nodes involved, implying that the IP addresses selected at the communication
establishment time must remain invariant through the lifetime of the communication. But
as it has been presented earlier, once that an outage has occurred in one of the available
ISPs, the associated address becomes unreachable, so an alternative address has to be
used in order to convey packets to the multi-homed host. These two constraints impose
that after an outage, packets must carry a different address, corresponding to an available
ISP, but they have to be presented to transport and application layers as if they contained
the original address, in order to be recognized as belonging to the established
communication. Such approach requires additional mechanisms in both ends of the
communication in order to preserve a coherent mapping between the IP addresses
presented to the transport and application layers and those addresses actually contained in
the packets.
- Difficulties when providing traffic engineering capabilities. The usage of multiple
prefixes pre multihomed site imply that those traffic engineering techniques will no
longer apply, and alternative mechanisms that provide equivalent capabilities are
required.
In this Thesis we describe an architecture for the provision of multihoming in IPv6 that deals with
all the aforementioned concerns. The proposed IPv6 multihoming architecture introduces the
following components:
- An intra-site routing paradigm that takes into account the source address, so that source
hosts can determine through the selection of the source address, the exit path of the
packets. Such feature provides ingress filtering compatibility.
- An address selection mechanism that takes into account address reachability information
acquired through a trial and error procedure.
- A new Multihoming Sub-Layer within the IP layer that will perform the required
mapping between the addresses that are presented to the upper layer protocols and the
addresses that are actually used for exchanging packets in the network. Such layer allows
the usage of different addresses for exchanging packets during the lifetime of a
communication, while keeping unchanged the address presented to the upper layers,
preserving the established communication.
- A mechanism for the configuration of the policy table defined in the default address
selection procedure, for the provision of traffic engineering capabilities.
A detailed presentation of the aforementioned mechanisms is preceded by an exhaustive
analysis of the solution space that justifies the selected approach.[+][-]