ES2540960T3 - Método de distribución de información de enrutado para conexiones redundantes - Google Patents

Método de distribución de información de enrutado para conexiones redundantes Download PDF

Info

Publication number
ES2540960T3
ES2540960T3 ES09852211.3T ES09852211T ES2540960T3 ES 2540960 T3 ES2540960 T3 ES 2540960T3 ES 09852211 T ES09852211 T ES 09852211T ES 2540960 T3 ES2540960 T3 ES 2540960T3
Authority
ES
Spain
Prior art keywords
routing
bgp4
information
established
additional
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES09852211.3T
Other languages
English (en)
Inventor
Pedro Andrés ARANDA GUTIÉRREZ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonica SA
Original Assignee
Telefonica SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonica SA filed Critical Telefonica SA
Application granted granted Critical
Publication of ES2540960T3 publication Critical patent/ES2540960T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/46—Cluster building
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H04L45/04—Interdomain routing, e.g. hierarchical routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/24—Multipath
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/54—Organization of routing tables
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/618—Details of network addresses
    • H04L2101/659—Internet protocol version 6 [IPv6] addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/22—Alternate routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/825—Involving tunnels, e.g. MPLS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08—Mobility data transfer
    • H04W8/085—Mobility data transfer involving hierarchical organized mobility servers, e.g. hierarchical mobile IP [HMIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]

Abstract

Se aplica en redes jerarquizadas de protocolo de Internet (IP) versión IPv6 que comprenden una pluralidad de diferentes sistemas autónomos (AS) que utilizan un protocolo de enrutado de pasarela fronteriza (BGP-4) para su comunicación, el cual no permite establecer sesiones de enrutado automáticamente, lo que impide crear servicios multiproveedor. El método de la invención permite la creación de servicios multiproveedor en las redes anteriormente comentadas mediante el uso del protocolo BGP-4 establecido por las normas y tecnologías actuales. De esta forma se puede aumentar la oferta de servicios por parte de los proveedores.

Description

E09852211
29-06-2015
Método de distribución de información de enrutado para conexiones redundantes
DESCRIPCIÓN
5
Objeto de la invención
El objeto del método de la invención es la provisión de conexiones multiproveedor en redes jerarquizadas que usan la versión IPv6 del protocolo de Internet (IP).
10 Antecedentes de la invención
Las redes de conmutación de paquetes identifican sus nodos a través de una dirección de nodo. Los nodos de conmutación transfieren los paquetes de datos desde una fuente a unos destinos identificados por sus respectivas 15 direcciones de nodo. Para ello, usan la información de enrutado que puede ser tanto calculada centralmente para toda la red, como calculada de forma independiente y distribuida por cada uno de los nodos en la red de conmutación de paquetes. El enrutado distribuido se usa por ejemplo en redes IP. Para converger en una configuración de red estable, los nodos intercambian su visión de la red con sus vecinos mediante los protocolos de enrutado. Esta visión incluye información sobre la topología (es decir, enlaces entre nodo) y los nodos servidos por
20 un enrutador (es decir, el espacio de direcciones o conjunto de direcciones adyacentes que funcionan mediante un enrutador).
La red de Internet es una red extremadamente compleja, que interconecta territorios conocidos tales como sistemas autónomos (AS). Un AS se define como un conjunto de nodos configurados con patrones de funcionamiento 25 comunes y coherentes con relación a un conjunto de redes. Los protocolos de enrutado en la redes IP, pueden clasificarse por su alcance. Los protocolos de enrutado interiores, tales como el protocolo de información de enrutado (RIP), el protocolo de primero el trayecto más corto abierto (OSPF) etc. se usan dentro del alcance de un AS. Los protocolos de enrutado exteriores se usan para intercambiar información entre los diferentes AS. Actualmente, el único protocolo de enrutado exterior conocido es el protocolo de pasarela fronteriza (BGP4, del
30 inglés Border Gateway Protocol). Para proporcionar redundancia, la mayoría de los AS y la Internet actual se conectan a otros dos o más AS. Esta práctica es conocida como multiproveedor en el nivel AS.
Dado el gran éxito comercial que ha tenido Internet, ello ha conducido a que se agoten las direcciones de la versión IPv4. Para superar este problema y preservar el principio punto a punto establecido en Internet, se está
35 introduciendo y usando en la red una nueva versión del protocolo IP, que se conoce como la versión IPv6. Esta nueva versión aumenta el espacio de direcciones disponible mediante el aumento de la longitud del campo de direcciones IP de 32 a 128 bits. El protocolo BGP4 se usa en las redes IPv4 y se ha extendido para tratar con la versión de protocolo IPv6.
40 El espacio de direccionamiento de la Internet IPv4 actual no está estructurado lo que conduce a una serie de efectos adversos, como el crecimiento excesivo del número de rutas en los enrutadores del núcleo de Internet. Por ello el IPv6 propone una delegación jerárquica del espacio de direccionamiento, en el que los AS de IPv6 enrutan el tráfico siguiendo una regla simple: enviar el tráfico al espacio de direcciones que se delegó a los AS de abajo, nivel jerárquico inferior, o al proveedor AS de arriba, nivel jerárquico superior, del que se recibió el espacio de direcciones.
45 Las especificaciones IPv6 no proporcionan la posibilidad de algún otro tipo de enrutado, lo que significa que en el nivel del AS, la Internet IPv6 consiste en una serie de árboles de enrutado conectados a una malla completa de dominios de alto nivel. A los proveedores AS de arriba se les asigna un espacio de direcciones suficientemente amplio, que se usa parcialmente por ellos y parcialmente por sus clientes AS (situados en un nivel jerárquico inferior) a los que se delega el espacio de direcciones mediante agregación, una vez tienen sus propios clientes. Todos los
50 AS pasan una entrada con su espacio de direcciones agregado asignado a sus proveedores AS de arriba e informan a sus clientes AS de que ellos son la ruta por defecto de Internet. Así las tablas de enrutado se mantienen pequeñas por agregación, tal y como se representa en la figura 1.
Para evitar estos inconvenientes el grupo de trabajo de ingeniería de Internet (IETF) ha producido una arquitectura
55 detallada para conectar los sitios con IPv6 a más de un proveedor AS, y no se ha abordado el nivel multiproveedor AS.
Ello significa que el nivel del multiproveedor AS para IPv6 tal y como se propone por el IETF, solo se prevé en el nivel de cliente final, ya sea este último un nodo (es decir, un enrutador ADSL) o un sitio (es decir, una red de nodos
60 con un punto de conexión único), determinando los siguientes inconvenientes:
1. Dejar toda la responsabilidad técnica del multiproveedor al usuario final del AS. En el caso de una organización más grande, la tarea se lleva a cabo por el centro de operaciones de red o por el departamento de TI a expensas de un equipo mayor y altamente cualificado.
E09852211
29-06-2015
2. Usar soluciones tecnológicamente avanzadas, que no son cómodas para el usuario y no son viables para servicios al por menor: un proveedor de servicios multiproveedor con clientes finales tendría que manejar una gran cantidad de dispositivos de cliente final con múltiples direcciones, y no puede seguir aguardando a que los clientes finales comprendan las implicaciones de tener múltiples direcciones IP asignadas a sus dispositivos.
5 3. Poner en peligro una parte significativa del negocio de los proveedores de servicios de IP al por mayor (como TIWS (servicios completos internacionales de telefónica), representando que cualquier pérdida de un AS frente a un proveedor competidor se habrá perdido virtualmente para siempre, dado que la conmutación entre proveedores significa una pérdida de conectividad y periodos de transición más largos.
10 El multiproveedor en el nivel AS y la Internet IPv6 es técnicamente posible, pero no ha sido provisto aún por las normas porque puede ser una fuente de problemas graves, y rompería el principio de delegación de direcciones como se ha descrito.
Véase, por ejemplo, el documento de KIIL Y COL.: “Novel scheme for efficient and scalable multihoming support in
15 IPv6”, THE 8TH INTERNATIONAL CONFERENCE ON COMMUNICATION SYSTEMS, 2002, vol. 2, 25 de noviembre de 2002 (25 11 2002), 28 de noviembre de 2002 (28 11 2002), páginas 656 660, PISCATAWAY, NJ, EE. UU., que divulga una arquitectura escalonable de multidireccionamiento de red.
Además surgiría una fuente potencial de crecimiento incontrolado de las tablas de enrutado de la red medular de la
20 Internet IPv6 si los AS que dependen de otro AS tuvieran permitido propagar su información de enrutado a un AS de abajo. El tamaño de la tabla de enrutado es un factor clave tanto para el coste como para el rendimiento de un enrutador. Con un espacio de direcciones de 128 bits en lugar de 32 bits, el tamaño de la tabla de enrutado podría reducir la cantidad de memoria física que puedan manejar los procesadores de los enrutadores. El manejo de las estructuras de datos del tamaño necesario para superar esta situación podría ser inviable debido al tiempo de
25 respuesta de los algoritmos necesario para recorrer las tablas de enrutado.
Otra solución al problema descrito consiste en la implementación del BGP basándose en un marcado y en un filtrado que dependen de las comunidades BGP que son atributos de BGP4 opcionales. Las comunidades tienen un significado local para un AS específico y se usan para marcar anuncios procedentes del BGP4. Este marcado se
30 usa entonces a través de unos filtros que determinan si un anuncio avanza o no hacia el proceso de enrutado. Esta propuesta de implementación no permite que el multiproveedor AS tenga un único espacio de direcciones. La propuesta completa requiere que el direccionamiento se delegue por parte de los AS de arriba.
Adicionalmente, el multiproveedor AS ha de marcar sus prefijos con un marcador dado en la forma de una
35 comunidad BGP que ha de aceptarse y filtrarse correctamente por todos los AS. Esto implica una estrategia de despliegue coherente con ediciones de software uniformes en todos los equipos de Internet IPv6. Actualmente hay un pequeño conjunto de comunidades bien conocidas, que son uniformemente aceptadas por todos los vendedores. Es improbable que se añadan nuevos valores bien conocidos a esta lista, dado que el IETF no respaldará la aplicación en un futuro próximo.
40 Por tanto, la implementación ha de tener lugar como un acuerdo entre proveedores y no puede ser despreciado el riesgo de errores de configuración.
Otra solución que se ha propuesto consiste en realizar el enrutado virtual y reenvío (VRF), que es una metodología
45 introducida por los vendedores de enrutadores para asignar tablas de enrutado diferentes, independientes y aisladas en un enrutador. El aislamiento es la característica esencial de los VRF.
El VRF es la piedra angular para servicios como las redes privadas virtuales (VPN). En un entorno VPN, varios clientes podrían tener el mismo espacio de direcciones y la característica esencial es que las diferentes redes de
50 cliente coexisten en un enrutador y que están aisladas entre sí. No se prevé la mezcla de espacios de direcciones de diferentes redes para proporcionar una fuente principal y otra para respaldar la información de enrutado. De hecho, esta característica va contra el concepto básico de las VPN basadas en VRF y la información de enrutado ha de estar disponible en una forma redundante, se usan mecanismos tradicionales de enrutado.
55 Descripción de la invención
Para conseguir los objetivos y resolver los inconvenientes anteriormente indicados, la invención proporciona un nuevo método que se aplica en redes jerarquizadas que usan la versión IPv6 del protocolo de Internet (IP), en el que las redes comprenden una pluralidad de diferentes sistemas autónomos (AS) que funcionan como proveedores y
60 que están constituidos por un conjunto de nodos configurados con patrones de funcionamiento comunes y coherentes con relación a un conjunto de redes, de manera que la comunicación entre cada AS usa un protocolo de enrutado de pasarela fronteriza (BGP4) en el que la información de enrutado para establecer sesiones de intercambio de información se calcula de manera distribuida por cada uno de los nodos de la red mediante una primera instancia de protocolo de enrutado BGP4.
E09852211
29-06-2015
La novedad del método de la invención radica en el hecho de que comprende las siguientes fases:
introducir información en los enrutadores de un primer proveedor AS y de un segundo proveedor AS con el que
5 previamente no tiene establecida conexión y que está situado en un nivel jerárquico superior correspondiente al nivel de un tercer AS que es el proveedor principal del primer AS, teniendo a su vez el segundo AS y el tercer AS un cuarto proveedor AS común a ambos perteneciente a un nivel superior al nivel jerárquico del segundo AS y del tercer AS; para establecer comunicación entre el primer AS y el segundo AS;
generar en el primer AS una petición de servicio multiproveedor al segundo AS;
10 el segundo AS genera una petición al cuarto AS para que autorice sesiones de intercambio de información; el cuarto AS genera dos sesiones BGP4 de emparejamiento nuevas e independientes al recibir una autorización de intercambio de información siendo la primera sesión BGP4 una sesión establecida entre el cuarto AS y el segundo AS, y siendo la segunda sesión BGP4 una sesión establecida entre el segundo AS y el primer AS;
15 el primer AS, el segundo AS y el cuarto AS establecen una sesión BGP4 adicional e independiente, para enviar la nueva información multiproveedor solicitada, generar una tabla de enrutado adicional e independiente en el primer AS, el segundo AS y el cuarto AS con una prioridad más baja respecto a la tabla de enrutado principal provista convencionalmente en el protocolo de enrutado BGP4,
20 al recibir una información de enrutado, acceder a la tabla principal para establecer la dirección de enrutado a seguir, acceder a una tabla de enrutado adicional cuando se detecta que la dirección de enrutado recibida no se corresponde con el enrutado establecido en dicha tabla principal, usar la dirección de enrutado establecida en la tabla adicional en el caso de acceder a dicha tabla adicional. 25 enviar la dirección de enrutado establecida a seguir, obtenida de la primera tabla o de la segunda tabla, dependiendo de si la dirección se ha obtenido en la primera o en la segunda tabla.
Por consiguiente la invención se basa en las características de las sesiones de emparejamiento establecidas en el protocolo BGP4, entendiéndose por sesiones de emparejamiento el hecho de que dos enrutadores que estén
30 usando el protocolo BGP4 tienen que conocer tanto la dirección IP y el identificador del propio AS, como la dirección IP y el identificador del AS del enrutador con el que están intercambiando información de enrutado a través del protocolo.
Por tanto, mediante el procedimiento descrito desde el punto de vista del primer AS es posible realizar el
35 funcionamiento multiproveedor con el segundo AS y el tercer AS usando el espacio de direcciones recibido del tercer AS. Esto implica una gran simplificación en la gestión de los AS, así como en la oferta de servicios que pueda hacer a sus AS finales, ya que internamente solamente tendrá que gestionarse un espacio de direcciones y sus AS finales tendrán también que hacerse cargo de una única dirección.
40 Adicionalmente, cualquier fallo que se produzca en el enlace ascendente entre el primer AS y el tercer AS no será detectado por los AS finales situados en una jerarquía más baja dado que el tráfico se direcciona entre el primer AS y el segundo AS mediante el protocolo de enrutado. Más aún, incluso un fallo en el enlace ascendente entre el tercer AS no se nota por los clientes AS del primer AS en virtud del protocolo de enrutado.
45 Esta circunstancia no se da en las soluciones actuales, ya que cualquier fallo en el enlace ascendente entre el primer AS y el tercer AS aislará al primer AS y al cuarto AS del resto de la infraestructura. En el caso de un fallo en el enlace ascendente de un quinto AS que está situado en un nivel jerárquico correspondiente al nivel del primer AS, y cuyo proveedor principal es el tercer AS, dicho quinto AS solo podrá comunicarse con el tercer AS y el primer AS.
50 Desde el punto de vista del multiproveedor constituido por el segundo AS según el método descrito de la invención, se permite que el segundo AS comience a ofertar servicios al por menor al primer AS directamente, a diferencia de lo permitido en la actualidad ya que cualquier AS aguas abajo es esclavo del AS situado en un nivel superior que está proporcionando la conectividad a Internet. Para el manejo de la tabla principal y la tabla adicional, de acuerdo con el procedimiento descrito, se prevé que dichas tablas principal y adicional estén determinadas por bases de
55 información de enrutado (RIB) paralelas de distinta prioridad, en tanto que el proceso de envío de la dirección de enrutado establecida se realiza mediante una base de información de reenvío (FIB) que favorece la información de enrutado que procede de la tabla principal respecto de la adicional, de forma que mediante estas bases de datos e información de reenvío se permite la ejecución de las fases del método señaladas de forma simplificada dado que el uso de FIB favorece siempre la información de enrutado que procede de la Internet IPv6 (tabla principal) sobre la
60 información de enrutado relacionada con el multiproveedor en el nivel AS (tabla adicional paralela a la tabla principal) usando la tabla adicional solo cuando en la tabla principal ha desaparecido el enlace debido a un fallo en los enlaces principales, por tanto mediante el uso de este mecanismo, el AS que necesita multiproveedor solo necesita una delegación de direcciones desde un AS.
E09852211
29-06-2015
Opcionalmente, la invención prevé que, aparte de las fases descritas anteriormente, puedan incorporarse unas nuevas fases para establecer una segunda vía de comunicación redundante entre el primer AS y el tercer AS, y una segunda vía de comunicación entre el tercer AS y el cuarto AS que consisten en:
5 generar en el primer AS una petición de servicio multiproveedor al tercer AS; generar en el tercer proveedor una petición al cuarto proveedor para que autorice sesiones de intercambio de información; el cuarto AS genera dos sesiones BGP4 de emparejamiento nuevas e independientes al recibir una autorización de intercambio de información;
10 siendo la primera sesión BGP4 una sesión establecida entre el cuarto AS y el tercer proveedor, y siendo la segunda sesión BGP4 una sesión establecida entre el tercer AS y el primer AS; el primer AS, el tercer AS y el cuarto AS establecen una sesión BGP4 adicional e independiente para enviar la
nueva información multiproveedor solicitada; generar una tabla de enrutado independiente adicional en el primer AS, el tercer AS y el cuarto AS con una 15 pluralidad más baja respecto a la tabla de enrutado principal provista convencionalmente en el protocolo de enrutado BGP4. al recibir una información de enrutado, acceder a la tabla principal para establecer la dirección de enrutado a seguir. acceder a la tabla de enrutado adicional cuando se detecta que la información de enrutado recibida se
20 corresponde con el enrutado establecido en dicha tabla principal; usar la dirección de enrutado establecida en la tabla adicional en el caso de acceder a dicha tabla adicional. enviar la dirección de enrutado establecida a seguir, obtenida de la primera tabla o de la segunda tabla,
dependiendo de si la dirección se ha obtenido en la primera o en la segunda tabla.
25 Por tanto, mediante estas fases opcionales se establece una segunda vía de comunicación entre el primer AS con el tercer AS y una segunda vía de comunicación del tercer AS con el cuarto AS, que constituyen una comunicación redundante en el caso en el que se precise.
Para facilitar una mejor comprensión de esta memoria descriptiva, se adjunta a continuación una serie de figuras 30 que forman una parte integrante de la misma, en las que el objeto de la invención se ha representado con carácter ilustrativo y no limitativo.
Breve descripción de las figuras
35 La figura 1 muestra una vista esquemática de una red de protocolo de Internet jerarquizada en la versión IPv6, tal y como se prevé en el estado de la técnica, en la que no se permite el servicio multiproveedor. La figura 2 muestra una figura equivalente a la figura anterior, pero en la que se ha aplicado el método de la invención para permitir el servicio multiproveedor en el primer AS. En esta figura se muestra, mediante una línea de trazos, la opción que establece una comunicación redundante entre el primer AS con el tercer AS, y entre el
40 tercer AS con el cuarto AS. La figura 3 muestra una representación esquemática de una implementación de la tabla principal y la tabla adicional mediante el uso de bases de información de enrutado (RIB) paralelas, que se manejan mediante una base de información de reenvío (RIB).
45 Descripción de la forma de realización preferida
A continuación se describe la invención basándose en las figuras anteriormente mencionadas.
La figura 1 muestra una representación esquemática de una infraestructura para enrutado jerárquico como Internet 50 IPv6.
La representación de las nubes referenciadas con los números 1 a 6, representan dominios de enrutado independientes, es decir, sistemas autónomos (AS) que fueron descritos en el apartado de Antecedentes de la Invención. Los rectángulos 7 representan las tablas que contienen la información de enrutado que está disponible en 55 cada AS 16, y que en la invención se denominan tablas principales 7, las flechas dobles representan las sesiones de intercambio de información de enrutado que se establecen entre los AS 16 para intercambiar la información de enrutado según la jerarquía establecida por la IPv6, en tanto que las líneas de flecha simple indican la delegación de direcciones que tiene lugar en las diferentes sesiones BGP4. Esta delegación de direcciones se representa mediante distintas zonas marcadas en las memorias principales 7 y representan los diferentes rangos de direcciones
60 de la jerarquía, que se delegan en el AS del nivel más bajo, en el que ha representado el mismo tipo de marcado.
En este entorno, existe un primer AS 1 mediante el que no hay comunicación con un segundo AS 2 y por tanto no pueden existir sesiones de intercambio de información de enrutado entre los mismos, lo que no permite ofrecer un servicio multiproveedor al primer AS 1.
E09852211
29-06-2015
En este entorno, al mismo nivel jerárquico que el segundo AS 2 se encuentra un tercer AS 3, y en un nivel superior a ambos se encuentra un cuarto AS 4. Al mismo nivel que el primer AS 1 se encuentra un quinto AS 5 y un sexto AS
6.
5 En esta configuración, el cuarto AS 4 intercambia información con sus clientes, el segundo AS 2 y el tercer AS 3. A su vez, el tercer AS 3 intercambia información con su proveedor, el cuarto AS 4, y con sus clientes, el primer AS 1 y el quinto AS 5, y así sucesivamente para el caso en el que se representará un mayor número de AS. El segundo AS 2 intercambia información de enrutado con, su proveedor, el cuarto AS 1 y con su cliente, el sexto AS 6. En este
10 caso cuando se produce un fallo en el enlace ascendente, es decir, el enlace con su proveedor, cualquier AS 16 y todos sus clientes del resto de la infraestructura de enrutado dependiente de ellos quedarán aislados de la infraestructura, ya que no hay posibilidad del servicio multiproveedor.
Para evitar este inconveniente, la invención proporciona un nuevo método para permitir el servicio multiproveedor, 15 tal y como se muestra en la figura 2.
El nuevo método comprende una primera fase en la que se introduce información en los enrutadores del primer AS 1 y del segundo AS 2 con el que previamente no ha establecido una conexión y que se encuentra situado en un nivel jerárquico superior, para permitir que se establezca comunicación entre el primer AS 1 y el segundo AS 2.
20 Esta información se introduce en los enrutadores mediante la programación del funcionamiento del protocolo BGP4 mediante el que convencionalmente se comunican los AS. Esta información indica a los enrutadores a qué AS pertenecen y con qué enrutador y a partir de qué AS se establece la sesión, dado que no basta solo con activar el protocolo BGP4, ya que este último no puede descubrir con quien tiene que hablar si no se especifica tal y como se
25 ha descrito, ya que el BGP4 no tiene medios para el descubrimiento de un vecino y nunca establece sesiones de enrutado automáticamente, sino que estas se establecen explícitamente y cuando es necesario entre dos enrutadores específicos que se configuran para ello por los operadores.
Seguidamente el método comprende generar en el primer AS 1 una petición de servicio multiproveedor al segundo
30 AS 2, de forma que cuando este último la recibe genera una petición al cuarto proveedor AS 4 para que autorice sesiones de intercambio de información, de manera que si el cuarto AS 4 autoriza el intercambio de información se generan dos sesiones BGP4 de emparejamiento nuevas e independientes. La primera sesión BGP4 es una sesión que se establece entre el cuarto AS 4 y el segundo AS 2, en tanto que la segunda sesión BGP4 se establece entre el segundo AS 2 y el primer AS 1.
35 A continuación se establece una sesión BGP4 adicional e independiente por parte del primer AS 1, el segundo AS 2 y el cuarto AS 4 para enviar la nueva información multiproveedor solicitada, y se genera una tabla de enrutado adicional e independiente 8 en el primer AS 1, el segundo AS 2 y el cuarto AS 4 con una prioridad más baja respecto a la tabla de enrutado principal 7 provista convencionalmente en el protocolo de enrutado BGP4.
40 Estas características permiten que al recibir una información de enrutado, se acceda a la tabla principal 7 para establecer la dirección de enrutado a seguir, de modo que cuando se detecta que la dirección de enrutado recibida no se corresponde con el enrutado establecido en dicha tabla principal 7, se accede a la tabla de enrutado adicional 8 en cuyo caso se usa la dirección de enrutado establecida en dicha tabla adicional 8. Esta circunstancia se
45 representa mediante el módulo 9 de la figura 3.
Para realizar esta funcionalidad, la invención usa el concepto de bases de información de enrutado (RIB) paralelas 7 y 8 para permitir la implementación de multiproveedor en el nivel AS en entornos de enrutado altamente jerárquicos como Internet IPv6. En este caso la información de enrutado relacionada con el enrutado de la IPv6 se gestiona
50 usando el protocolo BGP4 como se indica por las normas, en tanto que la información de enrutado relacionada con el multiproveedor en el nivel AS se gestionan en la tabla de enrutado 8 aislada separada adicional y mediante una instancia separada y aislada del protocolo de enrutado BGP4. Por consiguiente ambas estancias conservan y mantienen su propia tabla de enrutado como se muestra en la figura 3.
55 Seguidamente la información se envía según la dirección de enrutado establecida, el envío de la cual se lleva a cabo mediante una base de información de reenvío RIB 10 consolidada a partir de la RIB, lo que favorece siempre la información de enrutado que procede de la Internet IPv6 representada mediante la tabla principal 7 sobre la información de enrutado relacionada con el multiproveedor en el nivel AS, referenciada con la tabla adicional 8, usando la tabla adicional 8 solo cuando en la tabla principal 7 ha desaparecido la dirección de enrutado debido a un
60 fallo en los enlaces principales. Mediante el uso de este mecanismo, el AS que necesita un multiproveedor solo necesita una delegación de direcciones desde un AS.
Por tanto, la sesión BGP4 multiproveedor solo es obligatoria cuando el prefijo delegado al AS en multiproveedor no se transmite mediante la sesión BGP4 convencional. Dado que el tercer AS 3 delega el espacio de direcciones en el
E09852211
29-06-2015
primer AS 1, esta información de enrutado se encuentra presente en la tabla BGP4 convencional y se sobreescribirá la información recibida a través de la sesión multiproveedor. Este no es el caso para el segundo AS 2, al que no se le permite anunciar la información de enrutado desde el primer AS 1 a la tabla de enrutado principal 7 debido a las normas actuales, por tanto la implementación del mecanismo de priorización de enrutado no quedará
5 afectada por la presencia o la ausencia del trayecto del protocolo de enrutado (opcional); este último siempre usa un primer prefijo de RIB principal en la tabla 7 y se desvían los prefijos de RIB paralela 8 solo cuando no se halla entrada de enrutado alguna en el proceso de búsqueda.
La figura 2 muestra la opción en la que además de establecer las sesiones indicadas anteriormente, también se
10 establecen sesiones redundantes entre el primer AS 1 y el tercer AS 3 al mismo tiempo que este último establece una sesión redundante con el cuarto AS 4, para ello el método incorpora las siguientes fases: generar en el primer AS 1 una petición de servicio multiproveedor al tercer AS 3, para a continuación generar en el tercer AS 3 una petición al cuarto AS 4 para que autorice sesiones de intercambio de información, generándose dos sesiones BGP4 de emparejamiento nuevas e independientes al recibirse una autorización de
15 intercambio de información por parte del cuarto AS. La primera sesión es una sesión establecida entre el cuarto AS 4 y el tercer AS 3, por lo que la segunda sesión BGP4 es una sesión establecida entre el tercer AS 3 y el primer AS 1.
Seguidamente se establece una sesión BGP4 adicional e independiente por parte del primer AS 1, el tercer AS 3 y
20 el cuarto AS 4, para enviar la nueva información multiproveedor solicitada. A continuación se genera una tabla de enrutado adicional e independiente en el primer AS, el tercer AS 3 y el cuarto AS 4, con una prioridad más baja en cuanto a la tabla de enrutado principal provista convencionalmente en el protocolo de enrutado BGP4.
Esto permite que al recibirse una información de enrutado, se acceda a la tabla principal para establecer la dirección
25 de enrutado a seguir, y se acceda a la tabla de enrutado adicional cuando se detecta que la dirección de enrutado recibida no se corresponde con el enrutado establecido en dicha tabla principal.
Por último se usa la dirección de enrutado establecida en la tabla adicional en el caso de que se haya accedido a la misma de forma similar a como fue descrito para las fases esenciales del método descritas con anterioridad, y se
30 envía la dirección de enrutado establecida a seguir, obtenida en la primera tabla o en la tabla adicional, de acuerdo con la descripción realizada.
Desde un punto de visa práctico, la invención puede ser implementada mediante un demonio de enrutado BGP4 modificado sobre una plataforma Linux, que implementa un mecanismo RIB priorizado que permite la ejecución de
35 las fases descritas.
La solución propuesta sigue las mismas etapas que la implementación de las sesiones BGP4 convencionales, y los parámetros adicionales que es necesario incluir en la configuración son el RIB usado por el demonio BGP4 modificado y el puerto TCP usado por la sesión BGP4 modificada. Cabe señalar que este puerto ha de ser diferente
40 del puerto TCP 179 convencional usado por las implementaciones BGP4, para permitir la coexistencia de las sesiones de emparejamiento convencional y modificada.
Otra posibilidad de implementación de la invención proviene de la posibilidad de definir un conjunto nuevo de capacidades BGP4 multiprotocolo (mpBGP) que es una opción que el protocolo BGP4 permite para que se
45 transporte información de enrutado que no es IP en el sentido más estricto. En este caso se requiere realizar el intercambio de información de enrutado para familias de direcciones especiales, como por ejemplo las usadas en la redes IPv6, de forma que la información de enrutado multiproveedor IPv6 puede intercambiarse por medio del mpBGP usando una nueva familia de direcciones definida para este fin. El requisito principal en esta disposición es para que el demonio de enrutado BGP4 pueda manejar la RIB priorizada.
50

Claims (2)

  1. REIVINDICACIONES
    1. Método de distribución de información de enrutado para conexiones redundantes, aplicable en redes jerarquizadas de protocolo de Internet (versión IP IPv6) que comprende una pluralidad de diferentes sistemas 5 autónomos (AS) que funcionan como proveedores y que están constituidos por un conjunto de nodos configurados con patrones de funcionamiento comunes y coherentes con relación a un conjunto de redes, usándose en la comunicación entre cada AS un protocolo de enrutado de pasarela fronteriza, BGP4, mediante el que la información de enrutado se calcula de manera distribuida por cada uno de los nodos de la red mediante una primera instancia de protocolo de enrutado BGP4 para establecer sesiones de intercambio de información, caracterizado por que
    10 comprende las siguientes fases:
    introducir información en enrutadores de un primer AS (1) y de un segundo AS (2) en el que previamente no se había establecido conexión alguna entre el primer AS (1) y el segundo AS (2) y en el que el segundo AS (2) está situado en un nivel jerárquico superior que el primer AS (1), correspondiendo el nivel jerárquico superior al 15 nivel jerárquico de un tercer AS (3) que es el proveedor principal del primer AS (1), teniendo a su vez el segundo AS (2) y el tercer AS (3) un cuarto proveedor AS (4) común a ambos perteneciente a un nivel jerárquico superior al primer nivel jerárquico del segundo AS (2) y el tercer AS (3) para establecer comunicación entre el primer AS
    (1) y el segundo AS (2); generar en el primer AS (1) una petición de servicio multiproveedor al segundo AS (2);
    20 generar en el segundo AS (2) una petición al cuarto AS (4), determinando este último si se autoriza la sesión de intercambio de información; el cuarto AS (4) genera dos sesiones BGP4 de emparejamiento nuevas e independientes al recibir una autorización de intercambio de información ; siendo la primera sesión una sesión establecida entre el cuarto AS (4) y el segundo AS (2), y
    25 siendo la segunda sesión BGP4 una sesión establecida entre el segundo AS (2) y el primer AS (1); el primer AS (1), el segundo AS (2) y el cuarto AS (4) establecen una sesión BGP4 adicional e independiente para enviar la nueva información multiproveedor solicitada, generar una tabla de enrutado adicional e independiente (8) en el primer AS (1), el segundo AS (2) y el cuarto AS (4) con una prioridad más baja respecto a la tabla de enrutado principal (7) provista convencionalmente en el
    30 protocolo de enrutado BGP4, al recibir una información de enrutado, acceder a la tabla principal (7) para establecer la dirección de enrutado a seguir, acceder a la tabla de enrutado adicional (8) cuando se detecta que la dirección de enrutado recibida no se corresponde con el enrutado establecido en dicha tabla principal (7),
    35 usar la dirección de enrutado establecida en la tabla adicional (8) en el caso de acceder a dicha tabla adicional (8); y enviar la dirección de enrutado establecida a seguir, obtenida de una tabla seleccionada entre la primera tabla (7) y la segunda tabla (8), dependiendo de las fases anteriores.
    40 2. Método de distribución de información de enrutado para conexiones redundantes según la reivindicación 1, caracterizado por que la tabla principal (7) y la tabla adicional (8) están determinadas por bases de información de enrutado (RIB) paralelas de distinta prioridad, y la dirección de enrutado establecida se está enviando mediante una base de información de reenvío (10) (FIB) que favorece la información de enrutado que procede de la tabla principal
    (7)
    respecto de la de la tabla adicional (8). 45
  2. 3. Método de distribución de información de enrutado para conexiones redundantes según la reivindicación 1, caracterizado por que comprende:
    generar en el primer AS (1) una petición de servicio multiproveedor a un tercer AS (3);
    50 generar en el tercer AS (3) una petición al cuarto AS (4) para que autorice sesiones de intercambio de información; el cuarto AS (4) genera dos sesiones BGP4 de emparejamiento nuevas e independientes al recibir una autorización de intercambio de información; siendo la primera sesión BGP4 una sesión establecida entre el cuarto AS (4) y el tercer AS (3), y
    55 siendo la segunda sesión BGP4 una sesión establecida entre el tercer AS (3) y el primer AS (1); el primer AS (1), el tercer AS (3) y el cuarto AS (4) establecen una sesión BGP4 adicional e independiente para enviar la nueva información multiproveedor solicitada; generar una tabla de enrutado independiente adicional en el primer AS (1), el tercer AS (3) y el cuarto AS (4) con una prioridad más baja respecto a la tabla de enrutado principal provista convencionalmente en el protocolo
    60 de enrutado BGP4; al recibir una información de enrutado, acceder a la tabla principal para establecer la dirección de enrutado a seguir; acceder a la tabla de enrutado adicional cuando se detecta que la dirección de enrutado recibida no se corresponde con el enrutado establecido en dicha tabla principal;
    8
    autorizar la dirección de enrutado establecida en la tabla adicional en el caso de acceder a dicha tabla adicional; enviar la dirección de enrutado establecida a seguir, obtenida en una tabla seleccionada entre la primera tabla y la segunda tabla, dependiendo de las fases anteriores.
    9
ES09852211.3T 2009-12-15 2009-12-15 Método de distribución de información de enrutado para conexiones redundantes Active ES2540960T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/ES2009/070586 WO2011073459A1 (es) 2009-12-15 2009-12-15 Método de distribución de información de enrutado para conexiones redundantes

Publications (1)

Publication Number Publication Date
ES2540960T3 true ES2540960T3 (es) 2015-07-15

Family

ID=44070403

Family Applications (1)

Application Number Title Priority Date Filing Date
ES09852211.3T Active ES2540960T3 (es) 2009-12-15 2009-12-15 Método de distribución de información de enrutado para conexiones redundantes

Country Status (8)

Country Link
US (1) US8856274B2 (es)
EP (1) EP2515485B1 (es)
CN (1) CN102763377B (es)
AR (1) AR079168A1 (es)
BR (1) BR112012013678A2 (es)
ES (1) ES2540960T3 (es)
UY (1) UY33042A (es)
WO (1) WO2011073459A1 (es)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8880729B2 (en) * 2010-10-22 2014-11-04 Cisco Technology, Inc. Method and apparatus for routing requests for service using BGP community attributes
US10389595B2 (en) * 2012-01-26 2019-08-20 Siemens Aktiengesellschaft Controller and method for controlling communication services for applications on a physical network
CN103001877A (zh) * 2012-12-11 2013-03-27 太仓市同维电子有限公司 一种用于家庭网关产品上的数据绑定方法
US9124652B1 (en) * 2013-03-15 2015-09-01 Google Inc. Per service egress link selection
ES2678950T3 (es) * 2015-09-14 2018-08-21 Siemens Aktiengesellschaft Procedimiento para la configuración de un aparato de control modular de un sistema de automatización industrial y aparato de control modular
CN107911339B (zh) * 2017-10-20 2020-08-11 新华三技术有限公司 信息维护方法及装置
FR3074388A1 (fr) * 2017-11-28 2019-05-31 Orange Procede d'etablissement automatique par un premier dispositif d'une session conforme a un protocole de routage dynamique avec un deuxieme dispositif
CN114374642B (zh) * 2021-12-29 2023-06-16 中国电信股份有限公司 一种路由信息的维护方法及装置

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6584093B1 (en) * 1998-08-25 2003-06-24 Cisco Technology, Inc. Method and apparatus for automatic inter-domain routing of calls
US7286479B2 (en) * 2001-07-13 2007-10-23 Nortel Networks Limited Routing for a communications network
US7688714B2 (en) * 2004-04-28 2010-03-30 Cisco Technology, Inc. Network routing apparatus that performs soft graceful restart
US7590119B2 (en) * 2005-01-27 2009-09-15 Cisco Technology, Inc. Method and apparatus for context-based prefix updates in border gateway protocol
US7864669B2 (en) * 2005-10-20 2011-01-04 Cisco Technology, Inc. Method of constructing a backup path in an autonomous system
US8199642B2 (en) * 2006-09-14 2012-06-12 Cisco Technology, Inc. Dynamically and efficiently forming hierarchical tunnels
EP2109965B1 (en) * 2007-02-02 2015-04-08 Groupe Des Ecoles Des Telecommunications (GET) Institut National Des Telecommunications (INT) Autonomic network node system

Also Published As

Publication number Publication date
BR112012013678A2 (pt) 2017-10-10
EP2515485A4 (en) 2013-10-23
CN102763377A (zh) 2012-10-31
US8856274B2 (en) 2014-10-07
WO2011073459A1 (es) 2011-06-23
UY33042A (es) 2011-05-31
CN102763377B (zh) 2015-11-25
EP2515485A1 (en) 2012-10-24
EP2515485B1 (en) 2015-04-01
AR079168A1 (es) 2011-12-28
US20120324044A1 (en) 2012-12-20

Similar Documents

Publication Publication Date Title
ES2540960T3 (es) Método de distribución de información de enrutado para conexiones redundantes
USRE49485E1 (en) Overlay management protocol for secure routing based on an overlay network
US11805045B2 (en) Selective routing
US8488491B2 (en) Compressed virtual routing and forwarding in a communications network
ES2830182T3 (es) Controladores centrales de elementos de cálculo de rutas (PCECC) para servicios de red
US9912577B2 (en) Segment routing—egress peer engineering (SP-EPE)
US7486659B1 (en) Method and apparatus for exchanging routing information between virtual private network sites
CN106165322B (zh) 向冗余控制器路由协议的代理
CN114363115B (zh) 多区域虚拟覆盖广域网
EP3886378B1 (en) Seamless end-to-end segment routing across metropolitan area networks
WO2006002598A1 (fr) Systeme vpn de reseau federateur hybride a site hybride et son procede de mise en oeuvre
US20180309594A1 (en) Systems and Methods for Creating an Integrated Layer 2-Layer 3 Hybrid VPN Network
Wu et al. YANG data model for L3VPN service delivery
US9407544B1 (en) Network virtualization using IP map and encapsulation
WO2022061798A1 (en) Label deduction with flexible-algorithm
Filsfils et al. SRv6 Network Programming draft-filsfils-spring-srv6-network-programming-06
Cisco Glossary
Cisco Glossary
Cisco Glossary
Cisco Glossary
JP2006514496A (ja) 非接続モードにおける仮想私設網の相互接続方法
Azher et al. Virtual private network implementation over multiprotocol label switching
Farota et al. DMVPN (dynamic multipoint VPN): A solution for interconnection of sites IPV6 over an IPV4 transport network
Przygienda et al. RFC 9377 IS-IS Flood Reflection
Filsfils et al. RFC 8670 BGP Prefix Segment in Large-Scale Data Centers