WO2011073459A1 - 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
WO2011073459A1
WO2011073459A1 PCT/ES2009/070586 ES2009070586W WO2011073459A1 WO 2011073459 A1 WO2011073459 A1 WO 2011073459A1 ES 2009070586 W ES2009070586 W ES 2009070586W WO 2011073459 A1 WO2011073459 A1 WO 2011073459A1
Authority
WO
WIPO (PCT)
Prior art keywords
routing
information
bgp
established
additional
Prior art date
Application number
PCT/ES2009/070586
Other languages
English (en)
French (fr)
Inventor
Pedro Andrés ARANDA GUTIÉRREZ
Original Assignee
Telefonica, S.A.
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, S.A. filed Critical Telefonica, S.A.
Priority to US13/516,111 priority Critical patent/US8856274B2/en
Priority to CN200980162874.4A priority patent/CN102763377B/zh
Priority to ES09852211.3T priority patent/ES2540960T3/es
Priority to EP09852211.3A priority patent/EP2515485B1/en
Priority to BR112012013678A priority patent/BR112012013678A2/pt
Priority to PCT/ES2009/070586 priority patent/WO2011073459A1/es
Priority to UY0001033042A priority patent/UY33042A/es
Priority to ARP100104414A priority patent/AR079168A1/es
Publication of WO2011073459A1 publication Critical patent/WO2011073459A1/es

Links

Classifications

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

Definitions

  • the method of the invention is intended to provide multi-provider connections in hierarchical networks using the IPv6 version of the Internet Protocol (IP).
  • IP Internet Protocol
  • Packet switching networks identify their nodes by a node address.
  • the switching nodes transfer the data packets from a source to destinations identified by their respective node addresses. To do this, they use the routing information that can be calculated centrally for the entire network, and independently calculated and distributed by each of the nodes in the packet switching network. Distributed routing is used for example in IP networks.
  • the nodes exchange their network vision with the neighbors through routing protocols. This view includes information about the topology (i.e. links between nodes) and the nodes served by a router (i.e. the address space or set of adjacent addresses that are served by a router).
  • the Internet network is an extremely complex network, which interconnects territories known as autonomous systems (AS).
  • AS is defined as a set of nodes configured with common and consistent operating patterns in relation to a set of networks.
  • the routing protocols in the IP networks can be classified by their scope. Internal routing protocols, such as the routing information protocol (RIP), the first shortest path (OSPF) protocol etc. They are used within the scope of an AS. External routing protocols are used to exchange information between the different AS.
  • RIP routing information protocol
  • OSPF first shortest path
  • External routing protocols are used to exchange information between the different AS.
  • the only known exterior routing protocol is the border gateway protocol (BGP-4 of the English "Borden Gateway Protocol").
  • Border gateway protocol BGP-4 of the English "Borden Gateway Protocol”
  • IPv6 version a new version of the IP protocol is being introduced and deployed on the network, which is known as the IPv6 version.
  • This new version increases the available address space by increasing the length of the IP address field from 32 to 128 bits.
  • the BGP-4 protocol is used in IPv4 networks and has been extended to address the IPv6 version protocol.
  • IPv6 proposes a hierarchical delegation of the address space, in which the IPv6 ASs route the traffic following a simple rule: send the traffic to the address space that was delegated to the ASs below, lower hierarchical level, or to the AS provider from above, upper hierarchical level, from which the address space was received.
  • the IPv6 specifications do not provide the possibility of any other type of routing, which means that at the AS level, the IPv6 Internet consists of a series of routing trees connected to a complete mesh of high-level domains.
  • AS above are assigned a sufficiently large address space, which is partially used by them and partially by its client AS (located at a lower hierarchical level) to which the address space is delegated by aggregation, once they have their own clients. All ASs pass an entry with their aggregate address space assigned to their AS providers above and inform their AS customers that they are the default route to the Internet. Thus the routing tables are kept small by aggregation, as shown in Figure 1.
  • the Internet Engineering Working Group (IETF) has produced a detailed architecture to connect sites with IPv6 to more than one AS provider, and the multi-provider AS level has not been addressed.
  • IPv6 as proposed by the IETF, is only envisaged at the end client level, be it a node (i.e. an ADSL router) or a site (i.e. a network of nodes with a single connection point), which determines the following disadvantages:
  • the multiprovider at the AS level is technically possible and the Internet IPv6, but it has not yet been foreseen by the standards because it can be a source of serious problems, and would break the principle of delegation of addresses as described.
  • routing tables of the core network of the IPv6 Internet would arise if ASs that depend on another AS were allowed to propagate their routing information to an AS below.
  • the size of the routing table is a key factor for both the cost and the performance of a router. With an address space of 128 bits instead of 32 bits, the size of the routing table could make the amount of physical memory that router processors can handle small. The management of data structures of the size necessary to cope with this situation could be unfeasible due to the response time of the algorithms needed to traverse the routing tables.
  • Another solution to the problem described is the implementation of the BGP based on the marking and filtering that depend on the BGP communities that are optional BGP-4 attributes. Communities have a meaning that is local to a specific AS and is used to mark BGP-4 announcements. This marking is then used by filters that determine whether or not to advance an advertisement towards the routing process.
  • This implementation proposal does not allow the multi-provider AS to have a single address space. The complete proposal requires that the address be delegated by the ASs above.
  • multi-provider AS must mark their prefixes with a given marker in the form of a BGP community that needs to be admitted and correctly filtered by all AS. This implies a deployment strategy consistent with uniform software editions on all IPv6 Internet computers. There are currently a small set of well known communities, which are uniformly admitted by all vendors. It is unlikely that new well-known values will be added to this list, since the IETF will not support the application in the near future.
  • VRF virtual sending and routing
  • the VRF is the cornerstone for services such as virtual private networks (VPNs).
  • VPNs virtual private networks
  • clients could have the same address space and the essential feature is that different client networks coexist on a router and are isolated from each other. There is no provision for mixing address spaces from different networks, to provide a primary and backup source of the routing information. In fact, this feature goes against the basic concept of VRF-based VPNs and if routing information is to be available in a redundant way, traditional routing mechanisms are used.
  • the invention provides a new method that is applied in hierarchical networks that use the IPv6 version of the Internet Protocol (IP), in which the networks comprise a plurality of different autonomous systems (AS ) that function as providers and that are constituted by a set of nodes configured with common and coherent patterns of operation in relation to a set of networks, so that communication between each AS uses a border gateway routing protocol (BGP- 4) in which the routing information to establish information exchange sessions is calculated in a distributed manner by each of the nodes of the network by means of a first instance of BGP-4 routing protocol.
  • IP Internet Protocol
  • AS autonomous systems
  • BGP- 4 border gateway routing protocol
  • the novelty of the method of the invention is that it comprises the following phases:
  • the second session being BGP-4 a session established between the second AS and the first AS;
  • pairing sessions being understood as the fact that two routers that are using the BGP-4 protocol have to know both the IP address and the own AS identifier, IP address and router AS identifier with the They are exchanging routing information through the protocol.
  • any failure that occurs in the uplink between the first AS and the third AS will not be detected by the final AS located in a lower hierarchy since the traffic is routed between the first AS and the second AS by means of the protocol of routed Moreover, even an uplink failure between the third AS is not noticed by the AS clients of the first AS under the routing protocol.
  • the multipurpose provider constituted by the second AS allows the second AS to begin offering retail services to the first AS directly, unlike what is currently allowed since any AS down is AS captive located at a higher level that is providing Internet connectivity.
  • main and additional table are determined by parallel routing information bases (IB) of different priority, as long as the sending process of the established routing address is done through a sending information base (FIB) that favors the routing information from the main table with respect to the additional one, so that through these databases and sending information, the Execution of the phases of the method indicated in a simplified way since the use of FIB always favors the routing information that comes from the IPv6 Intern (main table) on the routing information related to the multiprovider at the AS level (additional table parallel to main table) using the additional table only when the link has disappeared in the main table due to a link failure main, therefore by using this mechanism, the AS that needs multi-vendor only needs an address delegation from an AS.
  • IB parallel routing information bases
  • FIB sending information base
  • the invention provides that apart from the phases described above, it may incorporate new phases to establish a second redundant communication path between the first AS and the third AS, and a second communication path between the third AS and the fourth AS consisting in:
  • the second session being BGP-4 a session established between the third AS and the first AS;
  • the main table Upon receiving a routing information, the main table is accessed to establish the routing address to follow.
  • a second communication path is established between the first AS with the third AS and a second communication path between the third AS and the fourth AS, which constitutes a redundant communication for the case in which it is required.
  • Figure 1. It shows a schematic view of a hierarchical network of Internet protocol in the IPv6 version, as foreseen in the state of the art, in which the multi-vendor service is not allowed.
  • Figure 2. Shows a figure equivalent to the previous figure, but in which the method of the invention has been applied to allow the multi-vendor service in the first AS.
  • the dashed line shows the option that establishes redundant communication between the first AS and the third AS, and between the third AS and the fourth AS.
  • FIG. 3 Shows a schematic representation of an implementation of the main table and the additional table through the use of parallel routing information bases (RIBs), which are managed by means of a sending information base (RIB).
  • ROBs parallel routing information bases
  • Figure 1 shows a schematic representation of a hierarchical routing infrastructure such as the IPv6 Internet.
  • Rectangles 7 represent the tables that contain the routing information that is available in each AS 1-6, and which in the invention are called main tables 7, the double arrows represent the routing information exchange sessions that are established between the AS 1-6 to exchange routing information according to hierarchy established by IPv6, while simple arrow lines indicate the delegation of addresses that takes place in the different BGP-4 sessions.
  • This delegation of addresses is represented by different striped areas in the main memories 7 and represents the different address ranges of the hierarchy, which are delegated to the AS of the lowest level, in which it has represented the same type of scratch.
  • a third AS 3 At the same hierarchical level as the second AS 2 is a third AS 3, and at a higher level than both is a fourth AS 4.
  • the fourth AS 4 exchanges information with the second AS 2 and the third AS 3 that are its customers.
  • the third AS 3 exchanges information with the fourth AS 4 as its supplier and with the first AS 1 and the fifth AS 5 as its customers. And so on for the case in which a greater number of ASs will be represented.
  • the second AS2 exchanges routing information with the fourth ASI as its provider and with the sixth AS 6 as its client. In this case, when there is a failure in the uplink, that is, the link with your provider, any AS1-6 and all its clients of the rest of the routing infrastructure dependent on them will be isolated from the infrastructure, as they do not have the possibility of the multi-vendor service.
  • the invention provides a new method for allowing multiprovider service, as shown in Figure 2.
  • the new method comprises a first phase in which information is entered in the routers of the first ASI and the second AS2 with which it has not previously established a connection and is located at a higher hierarchical level, to allow communication between the first AS 1 and the second AS 2.
  • this information in the routers is carried out by means of programming of operation of the BGP-4 protocol by means of which the AS are conventionally communicated.
  • the routers are indicated to which AS they belong and with which router and which AS the session is established, because it is not enough just to activate the BGP-4 protocol, since it cannot discover who it has to talk to if not It is specified as described, since the BGP-4 has no means for the discovery of a neighbor and never establishes routing sessions automatically, but these are explicitly established and when necessary between two specific routers that are set up for it by operators.
  • the method includes generating in the first
  • the first session BGP-4 is a session that is established between the fourth AS 4 and the second AS 2, while the second session BGP-4 is established between the second AS 2 and the first AS 1.
  • An additional and independent BGP-4 session is then established by the first ASI, second AS2 and fourth AS4 to send the new requested multi-vendor information, and an additional and independent routing table 8 is generated in the first ASI, second AS2 and fourth AS4 with a lower priority with respect to the main routing table 7 conventionally provided in the BGP-4 routing protocol.
  • the main table 7 is accessed to establish the routing address to follow, so that when it is detected that the received routing address does not correspond to the routing established in said main table 7, the additional routing table 8 is accessed in which case the routing address established in said additional table 8 is used.
  • This circumstance is represented by the module 9 of Figure 3.
  • the invention uses the concept of parallel routing information bases (RIBs) 7 and 8 to allow the implementation of multi-vendor at the AS level in highly hierarchical routing environments such as the IPv6 Internet.
  • the routing information related to the IPv6 routing is managed using the BGP-4 protocol as indicated by the standards, while the routing information related to the multi-provider at the AS level is managed in the routing table Additional 8 separate isolated and by a separate and isolated instance of the BGP-4 routing protocol. Therefore both rooms remain and maintain their own routing table as shown in Figure 3.
  • the information is then sent according to the established routing address, which is done through a RIB 10 sending information base consolidated from the RIBs, which always favors the routing information that comes from the IPv6 Internet represented by the main table 7 on the routing information related to the multi-provider at the AS level, referenced with the additional table 8, using the additional table 8 only when in the main table 7 the routing address has disappeared due to a failure in the main links.
  • the AS that needs a multi-vendor only needs an address delegation from an AS.
  • the BGP-4 multi-provider session is only mandatory when the prefix delegated to the AS in multi-provider is not transmitted by the standard BGP-4 session. Since the third AS 3 delegates the address space to the first AS 1 this routing information is present in the standard BGP-4 table and will overwrite the information received through the multiprovider session. This is not the case for the second AS 2, which is not allowed to announce the routing information from the first AS 1 to the main routing table 7 by the current rules therefore the implementation of the routing prioritization mechanism will not remain affected by the presence or not of the route of the routing protocol (optional); it always uses a primary RIB first prefix in table 7 and parallel RIB prefixes 8 are diverted only when no routing entry is found in the search process.
  • Figure 2 shows the option in which in addition to establishing the sessions indicated above, redundant sessions are also established between the first AS 1 and the third AS 3 at the same time that it establishes a redundant session with the fourth AS 4 for it
  • the method incorporates the following phases:
  • the first session is a session established between the fourth AS 4 and the third AS 3
  • the second session BGP-4 is a session established between the third AS 3 and the first AS 1.
  • An additional and independent BGP-4 session is then established by the first AS 1, third AS 3 and fourth AS 4, to send the new requested multi-vendor information.
  • An additional and independent routing table is then generated in the first AS, third AS 3 and fourth AS 4, with a lower priority as regards the main routing table conventionally provided in the BGP-4 routing protocol.
  • the main table is accessed to establish the routing address to follow, and the additional routing table is accessed when it is detected that the received routing address does not correspond to the established routing in said main table.
  • routing address established in the additional table is used in the event that it has been accessed in an equivalent manner as described for the essential phases of the method described above, and the established routing address is sent to continue, obtained in the first or in the additional table, according to the description made.
  • the invention can be implemented by means of a modified BGP-4 routing daemon on a linux platform, which implements a prioritized RIB mechanism that allows the execution of the described phases.
  • the proposed solution follows the same steps as the implementation of the standard BGP-4 sessions, and the additional parameters that need to be included in the configuration are the RIB used by the BGP-4 daemon modified and the TCP port used by the modified BGP-4 session. It should be noted that this port must be different from the standard TCP 179 port used by BGP-4 implementations, to allow for the coexistence of standard and modified pairing sessions.
  • Another possibility of implementing the invention comes from the possibility of defining a new set of multiprotocol BGP-4 capabilities (mpBGP) which is an option that the BGP-4 protocol allows for transporting non-IP routing information in the most sense. strict. In this case, it is required to exchange routing information for families of special addresses, such as those used in IPv6 networks, so that IPv6 multi-vendor routing information can be exchanged through mpBGP using a new defined address family for this purpose
  • the main requirement in this provision is that the BGP-4 routing daemon can handle the prioritized RIBs.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

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

MÉTODO DE DISTRIBUCIÓN DE INFORMACIÓN DE ENRUTADO
PARA CONEXIONES REDUNDANTES OBJETO DE LA INVENCIÓN
El método de la invención tiene por objeto proporcionar conexiones multiproveedor en redes jerarquizadas que utilizan la versión IPv6 del protocolo de Internet (IP) .
ANTECEDENTES DE LA INVENCIÓN
Las redes de conmutación de paquetes identifican sus nodos por una dirección de nodo. Los nodos de conmutación transfieren los paquetes de datos desde una fuente a unos destinos identificado por sus respectivas 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 los vecinos por medio de los protocolos de enrutado. Esta visión incluye información sobre la topología (es decir enlaces entre nodo) y los nodos servidos por un enrutador (es decir el espacio de direcciones o conjunto de direcciones adyacentes que sirven mediante un enrutador) .
La red Internet es una red extremadamente compleja, que interconecta territorios conocidos como sistemas autónomos (AS) . Un AS se define como un conjunto de nodos configurados con patrones de funcionamiento 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 (BGP-4 del inglés "Borden Gateway Protocol"). Para proporcionar redundancia, la mayoría de los AS y la actual Internet 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 la colmatación de las direcciones de la versión IPv4. Para tratar este problema y preservar el principio punto a punto establecido en Internet, se está introduciendo y desplegando una nueva versión del protocolo IP en la red, 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 BGP-4 se usa en las redes IPv4 y se ha extendido para tratar el protocolo de la versión IPv6.
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. Las especificaciones IPv6 no proporcionan la posibilidad de cualquier 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 AS clientes (situado 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 AS pasan una entrada con su espacio de direcciones agregadas asignadas a sus proveedores AS de arriba e informan a sus clientes AS de que ellos son la ruta por defecto a la Internet. Asi las tablas de enrutado se mantienen pequeñas por agregación, tal y como se representa en la figura 1.
Para tratar de evitar estos inconvenientes el grupo de trabajo de ingeniería de Internet (IETF) ha producido una arquitectura detallada para conectar los sitios con IPv6 a más de un proveedor AS, y no se ha direccionado el nivel AS multiproveedor .
Ello significa que el nivel del AS multiproveedor para
IPv6 tal y como se propone por el IETF, solo se prevé en el nivel de cliente final, sea éste un nodo (es decir un enrutador ADSL) o un sitio (es decir una red de nodos con un punto de conexión único) , lo que determina los siguientes inconvenientes:
1. Deja toda la carga 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 informática a expensas de un equipo mayor y altamente cualificado.
2. Usa soluciones técnicamente avanzadas, que no son amigables 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 esperarse que los clientes finales comprendan las implicaciones de tener múltiples direcciones IP asignadas a sus dispositivos.
3. Destruye una parte significativa del negocio de los proveedores de servicios de IP al por mayor (como TIWS (servicios completos internacionales de telefónica) , lo que representa que cualquier pérdida de un AS frente a un proveedor competidor se perderá prácticamente para siempre, dado que la conmutación entre proveedores significa pérdida de conectividad y periodos de transición más largos.
El multiproveedor en el nivel AS es técnicamente posible y la Internet IPv6, pero no se ha previsto aun por las normas porque puede ser una fuente de serios problemas, y rompería el principio de delegación de direcciones como se ha descrito.
Además surgiría una fuente potencial de crecimiento incontrolado de las tablas de enrutado de la red núcleo de la 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 dejar pequeña 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 hace frente a esta situación podría ser inviable debido al tiempo de respuesta de los algoritmos necesarios para recorrer las tablas de enrutado.
Otra solución al problema descrito consiste en la implementación del BGP basadas en el marcado y filtrado que dependen de las comunidades BGP que son atributos del BGP-4 opcionales. Las comunidades tienen un significado que es local para un AS específico y se usan para marcar anuncios del BGP-4. Este marcado se usa entonces por filtros que determinan si avanzar o no un anuncio hacia el proceso de enrutado. Esta propuesta de implementación no permite que el AS multiproveedor tenga un único espacio de direcciones. La propuesta completa requiere que el direccionamiento se delegue por parte de los AS de arriba.
Adicionalmente, los AS multiproveedor han de marcar sus prefijos con un marcador dado en la forma de una comunidad BGP que necesita ser admitido y correctamente filtrado por todos los AS. Esto implica una estrategia de despliegue coherente con ediciones de software uniformes en todos los equipos de la Internet IPv6. Actualmente hay un pequeño conjunto de comunidades bien conocidas, que son uniformemente admitidas por todos los vendedores. Es improbable que se añadan nuevos valores bien conocidos a esta lista, dado que el IETF no va a respaldar la aplicación en un próximo futuro.
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 envió y enrutado virtual (VRF) , que es una metodología 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 coexistan las diferentes redes de clientes en un enrutador y que estén aisladas entre sí. No existe previsión para la mezcla de espacios de direcciones de diferentes redes, para proporcionar una fuente principal y otra de respaldo de la información de enrutado. De hecho, esta característica va contra el concepto básico de las VPN basadas en VRF y si la información de enrutado ha de estar disponible en una forma redundante, se usan mecanismos tradicionales de enrutado.
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 utilizan 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 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 se emplea un protocolo de enrutado de pasarela fronteriza (BGP-4) en el que la información de enrutado para establecer sesiones de intercambio de información se calcular de manera distribuida por cada uno de los nodos de la red mediante una primera instancia de protocolo de enrutado BGP-4.
La novedad del método de la invención radica en que comprende las siguientes fases:
introducir información en los routers de un primer AS proveedor y de un segundo AS proveedor con el que 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 ve el segundo AS y el tercer AS un cuarto AS proveedor 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;
generar el segundo AS una petición al cuarto AS para que autorice sesiones de intercambio de información;
generar dos sesiones BGP-4 de emparejamiento nuevas e independientes al recibir una autorización de intercambio de información por parte de cuarto AS; siendo la primera sesión BGP-4 una sesión establecida entre el cuarto AS y el segundo AS, y
siendo la segunda sesión BGP-4 una sesión establecida entre el segundo AS y el primer AS;
- establecer una sesión BGP-4 adicional e independiente por parte del primer AS, segundo AS y cuarto AS, para enviar la nueva información multiproveedor solicitada, generar una tabla de enrutado adicional e independiente en el primer AS, segundo AS, y cuarto AS con una prioridad más baja respecto a la tabla principal de enrutado prevista convencionalmente en el protocolo de enrutado BGP-4,
al recibir una información de enrutado, acceder a la tabla principal para establecer la dirección de enrutado a seguir,
acceder en una tabla de enrutado adicional cuando se detecta que la dirección de enrutado recibida no se corresponden con el enrutado establecido en dicha tabla principal ,
- utilizar 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.
Por consiguiente la invención se basa en las características de las sesiones de emparejamiento establecidas en el protocolo BGP-4, entendiéndose por sesiones de emparejamiento el hecho de que dos routers que estén utilizando el protocolo BGP-4 tienen que conocer tanto la dirección IP y el identificador del AS propio, la dirección IP y el identificador del AS del router con el que están intercambiando información de encaminamiento a través del protocolo.
Por tanto, mediante el procedimiento descrito desde el punto de vista del primer AS es posible realizar el funcionamiento multiproveedor con el segundo AS y tercer AS usando el espacio de direcciones recibido del tercer AS. esto implica una gran simplificación en la gestión de los AS, asi como en la oferta de servicios que pueda hacer a sus AS finales, ya que internamente solamente tendrá que gestionar un espacio de direcciones y sus AS finales tendrán también que hacerse cargo de una única dirección.
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 aun, 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.
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 dejará al primer AS y el cuarto AS aislado 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á comunicar con el tercer AS y el primer AS.
Desde el punto de vista del multiproveedor constituido por el segundo AS según el método descrito de la invención permite al segundo AS comenzar a ofertar servicios al por menor al primer AS directamente, a diferencia de lo permitido en la actualidad ya que cualquier AS hacia abajo es cautivo del AS situado en un nivel superior que está proporcionando la conectividad con Internet. Para el manejo de la tabla principal y la tabla adicional, de acuerdo con el procedimiento descrito, se prevé que dicha tabla principal y adicional estén determinadas por bases de información de enrutado paralelas ( IB) de distinta prioridad, en tanto que el proceso de envió de la dirección de enrutado establecida se realiza mediante una base de información de envió (FIB) que favorece la información de enrutado procedente de la tabla principal respecto de la adicional, de forma que mediante estas bases de datos y de información de envió se permite la ejecución de las fases del método señaladas de forma simplificada pues el uso de FIB favorece siempre la información de enrutado que procede de la Internar IPv6 (tabla principal) sobre la 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.
Opcionalmente la invención prevé que aparte de las fases descritas anteriormente, pueda incorporar unas nuevas fases para establecer una segunda via de comunicación redundante entre el primer AS y el tercer AS, y una segunda via de comunicación entre el tercer AS y el cuarto AS que consisten en:
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;
generar dos sesiones BGP-4 de emparejamiento nuevas e independientes al recibir una autorización de intercambio de información por parte del cuarto AS; siendo la primera sesión BGP-4 una sesión establecida entre el cuarto AS y el tercer proveedor, y
siendo la segunda sesión BGP-4 una sesión establecida entre el tercer AS y el primer AS;
- establecer una sesión BGP-4 adicional e independiente por parte del primer AS, tercer AS y cuarto AS para enviar la nueva información multiproveedor solicitada; generar una tabla de enrutado adicional independiente en el primer AS, tercer AS y cuarto AS con una pluralidad más baja respecto a la tabla principal de enrutado prevista convencionalmente en el protocolo de enrutado BGP-4.
al recibir una información de enrutado, se accede 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 corresponde con el enrutado establecida en dicha tabla principal ;
- utilizar 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.
Por tanto, mediante estas fases opcionales se establece una segunda via de comunicación entre el primer AS con el tercer AS y una segunda via de comunicación del tercer AS con el cuarto AS, que constituye una comunicación redundante para el caso en el que se precise.
A continuación para facilitar una mejor comprensión de esta memoria descriptiva, y formando parte integrante de la misma se acompañan una serie de figuras en las que con carácter ilustrativo y no limitativo se ha representado el objeto de la invención.
BREVE ENUNCIADO DE LAS FIGURAS
Figura 1.- Muestra una vista esquemática de una red jerarquizada de protocolo de Internet en la versión IPv6, tal y como se prevé en el estado de la técnica, en el que no se permite el servicio multiproveedor .
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 linea de trazos la opción que establece comunicación redundante entre el primer AS con el tercer AS, y entre el tercer AS con el cuarto AS.
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 paralelas (RIB) , que se manejan mediante una base de información de envió (RIB) .
DESCRIPCIÓN DE LA FORMA DE REALIZACIÓN PREFERIDA
A continuación se realiza una descripción de la invención basada en las figuras anteriormente comentadas.
En la figura 1 se muestra una representación esquemática de una infraestructura de enrutado jerárquica como la Internet 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 cada AS 1-6, 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 1-6 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 BGP-4. Esta delegación de direcciones se representa mediante distintas zonas rayadas en las memorias principales 7 y representan los diferentes rangos de direcciones de la jerarquía, que se delegan en el AS del nivel más bajo, en el que ha representado el mismo tipo de rayado.
En este entorno, existe un primer ASI mediante el que no existe comunicación con un segundo AS2 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.
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.
En esta configuración el cuarto AS 4 intercambia información con el segundo AS 2 y el tercer AS 3 que son sus clientes. A su vez el tercer AS 3 intercambia información con el cuarto AS 4 como su proveedor y con el primer AS 1 y el quinto AS 5 como sus clientes. Y así sucesivamente para el caso en el que se representaran un mayor número de ASs. El segundo AS2 intercambia información de enrutado con el cuarto ASI como su proveedor y con el sexto AS 6 como su cliente. En este caso cuando se produce un fallo en el enlace ascendente, es decir el enlace con su proveedor, cualquier AS1-6 y todos sus clientes del resto de la infraestructura de enrutado dependiente de ellos quedarán aislados de la infraestructura, al no tener la posibilidad del servicio multiproveedor.
Para evitar este inconveniente, la invención proporciona un nuevo método para permitir el servicio multiproveedor, 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 routers del primer ASI y del segundo AS2 con el que previamente no tiene establecida conexión y que se encuentra situado a un nivel jerárquico superior, para permitir establecer comunicación entre el primer AS 1 y el segundo AS 2.
La introducción de esta información en los routers se realiza mediante programación de funcionamiento del protocolo BGP-4 mediante el que convencionalmente se comunican los AS. Mediante esta información se indica a los routers a que AS pertenecen y con que router y de qué AS se establece la sesión, pues no basta solo con activar el protocolo BGP-4, ya que éste no puede descubrir con quien tiene que hablar si no se encuentra especificado tal y como se ha descrito, ya que el BGP-4 no tiene medios para el descubrimiento de un vecino y nunca establece sesiones de enrutado automáticamente, si no que éstas 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
ASI una petición de servicio multiproveedor al segundo AS 2, de forma que cuando éste 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 BGP-4 de emparejamiento nuevas e independientes. La primera sesión BGP-4 es una sesión que se establece entre el cuarto AS 4 y el segundo AS 2, en tanto que la segunda sesión BGP-4 se establece entre el segundo AS 2 y el primer AS 1.
A continuación se establece una sesión BGP-4 adicional e independiente por parte del primer ASI, segundo AS2 y cuarto AS4 para enviar la nueva información multiproveedor solicitada, y se genera una tabla de enrutado adicional 8 e independiente en el primer ASI, segundo AS2 y cuarto AS4 con una prioridad más baja respecto a la tabla principal de enrutado 7 prevista convencionalmente en el protocolo de enrutado BGP-4.
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 utiliza la dirección de enrutado establecida en dicha tabla adicional 8. Esta circunstancia se representa mediante el módulo 9 de la figura 3.
Para realizar esta funcionalidad, la invención utiliza 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 la Internet IPv6. En este caso la información de enrutado relacionada con enrutado de la IPv6 se gestiona usando el protocolo BGP-4 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 adicional 8 separada aislada y mediante una instancia separada y aislada del protocolo de enrutado BGP-4. Por consiguiente ambas estancias quedan y mantienen su propia tabla de enrutado como se muestra en la figura 3.
Seguidamente se realiza el envío de la información según la dirección de enrutado establecida, lo cual se efectúa mediante una base de información de envío RIB 10 consolidada a partir de las RIB, lo que favorece siempre la información de enrutado que procede de la Internet IPv6 representado 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 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 BGP-4 multiproveedor solo es obligatoria cuando el prefijo delegado al AS en multiproveedor no se transmite mediante la sesión BGP-4 estándar. Dado que el tercer AS 3 delega el espacio de direcciones en el primer AS 1 esta información de enrutado se encuentra presente en la tabla BGP-4 estándar y 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 por las normas actuales por tanto la implementación del mecanismo de priorización de enrutado no quedará afectada por la presencia o no del trayecto del protocolo de enrutado (opcional) ; éste siempre usa un prefijo primero de RIB principal en la tabla 7 y se desvian los prefijos RIB paralelo 8 solo cuando no se halla ninguna entrada de enrutado en el proceso de búsqueda.
En la figura 2 se muestra la opción en la que además de establecerse las sesiones indicadas anteriormente, además se establecen sesiones redundantes entre el primer AS 1 y el tercer AS 3 al mismo tiempo que éste 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 BGP-4 de emparejamiento nuevas e independientes al recibirse una autorización de cambio 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, en tanto que la segunda sesión BGP-4 es una sesión establecida entre el tercer AS 3 y el primer AS 1.
Seguidamente se establece una sesión BGP-4 adicional e independiente por parte del primer AS 1, tercer AS 3 y 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 , tercer AS 3 y cuarto AS 4, con una prioridad más baja en cuanto a la tabla principal de enrutado prevista convencionalmente en el protocolo de enrutado BGP-4.
Esto permite que al recibirse una información de enrutado, se acceda a la tabla principal para establecer la dirección de enrutado a seguir, y se accede 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 utiliza la dirección de enrutado establecida en la tabla adicional en el caso de que se haya accedido a la misma de forma equivalente a como fue descrito para las fases imprescindibles del método descritas con anterioridad, y se envia la dirección de enrutado establecida a seguir, obtenida en la primera 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 daemon de enrutado BGP-4 modificado sobre una plataforma linux, la cual implementa un mecanismo RIB priorizado que permite la ejecución de las fases descritas.
La solución propuesta sigue las mismas etapas que la implementación de las sesiones BGP-4 estándar, y los parámetros adicionales que es necesario incluir en la configuración son el RIB usado por el daemon BGP-4 modificado y el puerto TCP usado por la sesión BGP-4 modificado. Cabe señalar que este puerto ha de ser diferente del puerto TCP 179 estándar utilizado por las implementaciones BGP-4, para permitir la coexistencia de las sesiones de emparejamiento estándar y modificada.
Otra posibilidad de implementación de la invención viene por la posibilidad de definir un conjunto nuevo de capacidades BGP-4 multiprotocolo (mpBGP) que es una opción que el protocolo BGP-4 permite para que transporte información de encaminamiento 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 utilizadas en la redes IPv6, de forma que la información de enrutado IPv6 multiproveedor puede intercambiarse por medio del mpBGP usando una nueva familia de direcciones definida para esta finalidad. El requisito principal en esta disposición es que el daemon de enrutado BGP-4 pueda manejar las RIB priori zadas .

Claims

REIVINDICACIONES
1.- MÉTODO DE DISTRIBUCIÓN DE INFORMACIÓN DE ENRUTADO PARA CONEXIONES REDUNDANTES, aplicable en redes jerarquizadas de protocolo de Internet (IP versión IPv6) que comprende una pluralidad de diferentes sistemas 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, empleándose en la comunicación entre cada AS un protocolo de enrutado de pasarela fronteriza (BGP-4) mediante 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 BGP-4, se caracteriza porque comprende las siguientes fases:
introducir información en los routers de un primer AS (1) y de un segundo AS (2) con el que previamente no tiene establecida conexión y que está situado en un nivel jerárquico superior, correspondiente al nivel 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 AS (4) proveedor común a ambos pertenecientes a un nivel superior al primer jerárquico del segundo AS (2) y 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);
generar en el segundo AS (2) una petición al cuarto AS (4) para que autorice sesiones de intercambio de información;
generar dos sesiones BGP-4 de emparejamiento nuevas e independientes al recibir una autorización de intercambio de información por parte de cuarto AS (4); siendo la primera sesión una sesión establecida entre el cuarto AS (4) y el segundo AS (2), y
siendo la segunda sesión BGP-4 una sesión establecida entre el segundo AS (2) y el primer AS (1);
- establecer una sesión BGP-4 adicional e independiente por parte del primer AS (1), segundo AS (2) y cuarto AS (4), para enviar la nueva información multiproveedor solicitada,
generar una tabla de enrutado adicional (8) e independiente en el primer AS (1), segundo AS (2), y cuarto AS (4) con una prioridad más baja respecto a la tabla de enrutado principal (7) prevista convencionalmente en el protocolo de enrutado BGP-4, 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 ) ,
utilizar la dirección de enrutado establecida en la tabla adicional (8) en el caso de acceder a dicha tabla adicional ( 8 )
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.
2.- MÉTODO DE DISTRIBUCIÓN DE INFORMACIÓN DE ENRUTADO PARA CONEXIONES REDUNDANTES, según reivindicación 1, caracterizado porque la tabla principal (7) y la tabla adicional (8) están determinadas por bases de información de enrutado paralelas (RIB) de distinta prioridad, y en procedo de envió de la dirección de enrutado establecida se realiza mediante una base de información de envió (10) (FIB) que favorece la información de enrutado procedente de la tabla principal (7) respecto de la tabla adicional (8) .
3.- MÉTODO DE DISTRIBUCIÓN DE INFORMACIÓN DE ENRUTADO PARA CONEXIONES REDUNDANTES, según reivindicación 1, caracterizado porque comprende:
generar en el primer AS (1) una petición de servicio multiproveedor a un tercer AS (3) ;
generar en el tercer AS (3) una petición al cuarto AS (4) para que autorice sesiones de intercambio de información;
generar dos sesiones BGP-4 de emparejamiento nuevas e independientes al recibir una autorización de intercambio de información por parte del cuarto AS (4); siendo la primera sesión BGP-4 una sesión establecida entre el cuarto AS (4) y el tercer AS (3), y
siendo la segunda sesión BGP-4 una sesión establecida entre el tercer AS (3) y el primer AS (1);
establecer una sesión BGP-4 adicional e independiente por parte del primer AS (1), tercer AS (3) y cuarto AS (4) para enviar la nueva información multiproveedor solicitada;
generar una tabla de enrutado adicional independiente en el primer AS (1), tercer AS (3) y cuarto AS (4) con una prioridad más baja respecto a la tabla principal de enrutado prevista convencionalmente en el protocolo de enrutado BGP-4;
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 ; 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 .
PCT/ES2009/070586 2009-12-15 2009-12-15 Método de distribución de información de enrutado para conexiones redundantes WO2011073459A1 (es)

Priority Applications (8)

Application Number Priority Date Filing Date Title
US13/516,111 US8856274B2 (en) 2009-12-15 2009-12-15 Method for distributing of routing information for redundant connections
CN200980162874.4A CN102763377B (zh) 2009-12-15 2009-12-15 用于冗余连接的路由信息的分配方法
ES09852211.3T ES2540960T3 (es) 2009-12-15 2009-12-15 Método de distribución de información de enrutado para conexiones redundantes
EP09852211.3A EP2515485B1 (en) 2009-12-15 2009-12-15 Method for distributing routing information for redundant connections
BR112012013678A BR112012013678A2 (pt) 2009-12-15 2009-12-15 "metodo para a distribuição de informações de roteamento para conexões redundantes"
PCT/ES2009/070586 WO2011073459A1 (es) 2009-12-15 2009-12-15 Método de distribución de información de enrutado para conexiones redundantes
UY0001033042A UY33042A (es) 2009-12-15 2010-11-19 Metodo de distribucion de informacion de enrutado para conexiones redundantes
ARP100104414A AR079168A1 (es) 2009-12-15 2010-11-30 Metodo de distribucion de informacion de enrutado para conexiones redundantes

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
WO2011073459A1 true WO2011073459A1 (es) 2011-06-23

Family

ID=44070403

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/ES2009/070586 WO2011073459A1 (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
EP2795842B1 (en) * 2012-01-26 2016-08-24 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
EP3142296B1 (de) * 2015-09-14 2018-04-18 Siemens Aktiengesellschaft Verfahren zur konfiguration eines modularen steuerungsgeräts eines industriellen automatisierungssystems und modulares steuerungsgerät
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 中国电信股份有限公司 一种路由信息的维护方法及装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060164995A1 (en) * 2005-01-27 2006-07-27 Martin Djernaes Method and apparatus for context-based prefix updates in border gateway protocol
US20060171404A1 (en) * 2004-04-28 2006-08-03 Gargi Nalawade Network routing apparatus that performs soft graceful restart

Family Cites Families (5)

* 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
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

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060171404A1 (en) * 2004-04-28 2006-08-03 Gargi Nalawade Network routing apparatus that performs soft graceful restart
US20060164995A1 (en) * 2005-01-27 2006-07-27 Martin Djernaes Method and apparatus for context-based prefix updates in border gateway protocol

Non-Patent Citations (7)

* Cited by examiner, † Cited by third party
Title
BAGNULO M. ET AL.: "An incremental approach to IPv6 multihoming", COMPUTER COMMUNICATIONS, vol. 29, no. 5, 6 March 2006 (2006-03-06), AMSTERDAM, NL, pages 582 - 592, XP025089785, DOI: doi:10.1016/j.comcom.2005.06.009 *
BAGNULO M. ET AL.: "Multi-homing tunnel broker", PROCEEDINGS OF THE 30TH EUROMICRO CONFERENCE (EUROMICRO'04), 31 August 2004 (2004-08-31) - 3 September 2004 (2004-09-03), RENNES, FRANCE, pages 282 - 289, XP003028103 *
DA-HYE CHOI ET AL.: "Distributed IPv6 multihoming support", TH ASIA-PACIFIC CONFERENCE ON COMMUNICATIONS (IEEE CAT. NO.03EX732), vol. 3, 2003, PISCATAWAY, NJ, USA, pages 1097 - 1101, XP010687972, DOI: doi:10.1109/APCC.2003.1274269 *
KI-IL KIM ET AL.: "Novthe scheme for efficient and scalable multihoming support in IPv6", THE 8TH INTERNATIONAL CONFERENCE ON COMMUNICATION SYSTEMS, 2002. ICCS 2002, vol. 2, 25 November 2002 (2002-11-25) - 28 November 2002 (2002-11-28), PISCATAWAY, NJ, USA, pages 656 - 660, XP010629302 *
SAVOLA P.; CHOWN T. ET AL.: "A survey of IPv6 site multihoming proposals", TELECOMMUNICATIONS, 2005. CONTEL 2005. PROCEEDINGS OF THE 8TH INTERNATIONAL CONFERENCE ON, vol. 1, 15 June 2005 (2005-06-15) - 17 June 2005 (2005-06-17), ZAGREB, CROATIA, pages 41 - 48, XP003028104 *
See also references of EP2515485A4 *
YOUNG-HWAN CHOI ET AL.: "A scalable IPv6 multihoming mechanism based on controlled path advertisement", PCC/MDMC '04. THE 2004 JOINT CONFERENCE OF THE 10TH ASIA-PACIFIC CONFERENCE ON COMMUNICATIONS AND THE 5TH INTERNATIONAL SYMPOSIUM ON MULTI-DIMENSIONAL MOBILE COMMUNICATIONS PROCEEDING. 2004. IEEE, vol. 1, 2004, PISCATAWAY, NJ, USA, pages 108 - 112, XP010765142, DOI: doi:10.1109/APCC.2004.1391662 *

Also Published As

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

Similar Documents

Publication Publication Date Title
ES2540960T3 (es) Método de distribución de información de enrutado para conexiones redundantes
ES2830182T3 (es) Controladores centrales de elementos de cálculo de rutas (PCECC) para servicios de red
US8488491B2 (en) Compressed virtual routing and forwarding in a communications network
EP3529953B1 (en) Elastic vpn that bridges remote islands
US6205488B1 (en) Internet protocol virtual private network realization using multi-protocol label switching tunnels
US7486659B1 (en) Method and apparatus for exchanging routing information between virtual private network sites
US9432213B2 (en) IP forwarding across a link state protocol controlled ethernet network
US10587509B2 (en) Low-overhead routing
US9590850B2 (en) Discovery of connectivity and compatibility in a communication network
CN114363115B (zh) 多区域虚拟覆盖广域网
EP1832083A2 (en) Virtual private networking methods for autonomous systems
CN101455030A (zh) 动态共享风险节点组(srng)成员发现
EP3886378B1 (en) Seamless end-to-end segment routing across metropolitan area networks
CN102891903B (zh) 一种nat转换方法及设备
ES2410366B1 (es) Método para intercambiar información sobre recursos de red
WO2022061798A1 (en) Label deduction with flexible-algorithm
Cisco Glossary
Cisco Glossary
Cisco Glossary
Cisco Glossary
CN115225568A (zh) 对以太网虚拟私有网络—虚拟可扩展局域网的快速重路由
ES2388288B1 (es) Método para comunicaciones entre dominios.
Shen et al. MPLS egress protection framework
Azher et al. Virtual private network implementation over multiprotocol label switching
Przygienda et al. RFC 9377 IS-IS Flood Reflection

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200980162874.4

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09852211

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2009852211

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 13516111

Country of ref document: US

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112012013678

Country of ref document: BR

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
ENP Entry into the national phase

Ref document number: 112012013678

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20120606