WO2015086877A1 - Procedimiento de establecimiento y borrado de caminos y de reenvio de tramas para conexiones de transporte y puente de red - Google Patents
Procedimiento de establecimiento y borrado de caminos y de reenvio de tramas para conexiones de transporte y puente de red Download PDFInfo
- Publication number
- WO2015086877A1 WO2015086877A1 PCT/ES2014/070905 ES2014070905W WO2015086877A1 WO 2015086877 A1 WO2015086877 A1 WO 2015086877A1 ES 2014070905 W ES2014070905 W ES 2014070905W WO 2015086877 A1 WO2015086877 A1 WO 2015086877A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- frame
- bridge
- tcp
- port
- destination
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/12—Discovery or management of network topologies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
Definitions
- the present invention falls within the field of communications and electronic devices and / or computer applications that establish communications between transparent network bridges. STATE OF THE TECHNIQUE
- the path establishment protocols known as Fast-Path and ARP-Path [G. are known. Ibá ⁇ ez, JA Carral, A. Garcia-Martinez, JM Arco, D. Rivera, and A. Azcorra, "Fast Path Ethernet Switching: On-demand, Efficient Transparent Bridges for Data Center and Campus Networks", 17th IEEE Workshop on Local and Metropolitan Area Networks (LANMAN), New Jersey, USA, May 2010.] [G. Ibá ⁇ ez, J.A. Carral, J.M. Arco, D. Rivera, and A. Montalvo. "ARP Path: ARP-Based, Shortest Path Bridges". IEEE Communications Letters, 201 1, pp. 770-772.], Which establish paths by simultaneously exploring the entire network through a broadcast frame such as the ARP Request and learning on the bridges across the source MAC addresses and their association to the port where the broadcast plot is received first.
- the procedure for establishing roads mentioned operates as follows: In a network of ARP-Path bridges, two terminals A and C establish to communicate two paths from A to C and from C to A. These roads are learned in the bridges of the network by broadcasting all links in a frame such as ARP Request or through its response, a unicast frame such as ARP Reply.
- the bridges associate to the MAC address of the frame the port through which the frame is first received and block this association preventing its modification for a sufficient time so that copies received in other ports of each bridge are discarded because they are not associated your source MAC address to the port through which they are received.
- protocols and mechanisms that allow the establishment of paths in the network through direct exploration of the network with multicast frames replicated in the network, but more specifically, associating each path with a data flow, taking into consideration to identify Each flow additional fields transported in frames such as transport ports (TCP, UDP or others) used in the connection between the two terminals.
- transport ports TCP, UDP or others
- the present invention describes mechanisms that allow searching, establishing, using and deleting a specific path for each TCP connection established between two terminals and a network bridge that implements these mechanisms.
- the diversity of the paths created is parameterizable.
- the invention includes a procedure for establishing network paths associated with each new TCP transport layer flow by establishing a new TCP connection between two terminals, a frame forwarding procedure through said paths and a method for deleting them to the Close TCP connections. These procedures will be applied by TCP-Path bridges that have this functionality activated, configurable according to the network requirements.
- the ARP-Path path between two terminals A and C being created receives a TCP SYN segment at the border bridge of the sending terminal (A) the segment is encapsulated in a frame Special PathRequest with origin address the MAC address of the sending terminal A and the protocol identifier (Ethertype) the specific one assigned to TCP-Path and are associated, in a table, for forwarding purposes, the source MAC addresses and source TCP port, as well as the identifier of the TCP-Path connection, the identity of the bridge port that first received the frame, an expiration indicator and the moment of arrival of the frame; and the ports except the receiving port are broadcasted by broadcast.
- a frame Special PathRequest with origin address the MAC address of the sending terminal A and the protocol identifier (Ethertype) the specific one assigned to TCP-Path and are associated, in a table, for forwarding purposes, the source MAC addresses and source TCP port, as well as the identifier of the TCP-Path connection
- the bridge associates (learns) the MAC address of C, the MAC address of A, the transport port of C and the transport port of A to the port through which it was received, identified as the tupia ⁇ C, A, pC, pA ⁇ (abbreviated, CA tupia), associating them with the previously created expiration identifier of the AC tupia, updating the arrival time, confirming and renewing the validity of the association.
- the port In each bridge crossed the port is also associated of reception to said CA tupia and it is forwarded by the port associated to the tupia AC, associated to the connection from C to terminal A, confirming and renewing the road in the direction towards A, associating them with the previously created expiration identifier of the tupia AC , updating the arrival time, confirming and renewing the validity of the association ..
- a bridge when a bridge receives the PathRequest packet through the same port that it already had associated with the generic ARP-Path path for A, that bridge can associate the transport path to a different port whenever it receives the Duplicate PathRequest with a reduced and limited time difference from the port that first receives it.
- the PathReply packet finally arrives in unicast to the destination border bridge, to which the destination terminal A is connected directly.
- the bridge uncapsulates the frame containing the original SYN + ACK segment and forwards it to terminal A.
- Terminal A will respond with a frame containing a transport segment with the ACK indicator activated, which will be forwarded as a normal segment, without encapsulating, along the path associated with that pair of MAC addresses and the pair of TCP ports of the connection.
- the successive segments of data sent from terminal A to C. will be routed.
- the TCP-Path protocol encapsulates the transport segments that contain the activated SYN indicator (only the SYN indicator or the activated SYN and ACK indicators), and establishes and confirms with them alternative paths to those already existing, previously established by one of the Known protocols: ARP-Path or Flow-Path.
- He Path from A to C may exist previously or not, both as an ARP-Path path associated only with the MAC address A or as a two-way Flow-Path path associated with the A and C addresses, the difference is that TCP-Path only establishes a new path associated with the connection if there is no previous path between A and C or, if it exists, it is different from the one being created (that is, the port associated with the tupia is different from the existing one).
- the TCP-Path transport path established between A and C may partially, completely, or not at all coincide with pre-existing roads. There will only be one path between A and C established by ARP-Path and Flow-Path, while TCP-Path can create as many additional roads as transport connections exist at any time.
- This soda can be forward and optionally bidirectional, as configured.
- the frames received renew the association of the destination MAC of the frame forwarded to the output port.
- the bidirectional they also renew the association of the source MAC address to the input port.
- the paths are not used by the frames associated with them (with transport port and MAC addresses in the forwarding table) for a period longer than the persistence timer (cache) of the bridges, they expire automatically, being erased from memory the ports associated with the road.
- persistence timer cache
- TCP-Path paths can be explicitly deleted by the terminals when they send a FIN segment in each direction to close the TCP connection.
- a terminal will send a FIN segment that is answered by the destination terminal with an ACK segment.
- This FIN segment will close the TCP-Path connection in the direction of the sent FIN segment. It will also happen from the remote end when a FIN segment answered with an ACK segment is issued towards the end remote to close the connection in the remote-near direction.
- the receiving end can answer with a combined FIN + ACK segment (the so-called three-way TCP shutdown), which will be answered with an ACK segment to confirm the close in the near-near direction.
- This ACK segment is not encapsulated.
- the border bridge when the border bridge receives a TCP segment with the FIN indicator activated, it encapsulates the segment in a PathFlush packet with source and destination addresses equal to those of the received segment, which is forwarded in unicast to the destination following the path established by CA, in order to erase the path from A to C associated with that TCP connection.
- the next bridge crossed upon receiving said PathFlush unicast frame with the protocol type field, containing the value assigned to the "TCP-Path" protocol, deletes from the table, for forwarding purposes, the association of destination MAC address and port transport destination to the bridge port and the associated expiration timer contents, without modifying other associations of said MAC address to other ports on the bridge; it also checks whether the destination MAC address of the encapsulated frame within the PathFlush frame corresponds to a terminal directly connected to the bridge receiving the frame and, if so, uncapsulates the frame and forwards it to the destination terminal through the bridge port associated with said terminal. If the destination MAC address of the encapsulated frame is not associated with a terminal directly connected to the bridge that receives the frame, the bridge forwards the PathFlush frame in unicast through the port associated with the newly deleted "TCP connection fields".
- the TCP connection fields are consulted: source and destination MAC addresses, source and destination transport ports, and verify if there is a port associated with that connection as a destination; if it exists, the frame is forwarded by the port associated to said connection to the destination terminal and the timer associated to the destination MAC address and associated TCP-Path connection is renewed for an additional period; if it does not exist, it is checked, in a less restrictive way, if there is any bridge port associated with the destination MAC address of the frame or the destination MAC address and MAC origin of the frame; if it exists, the frame is forwarded through said port; In other cases, the road repair process will begin by sending a multicast frame.
- TCP-Path specific path when there is no TCP-Path specific path, another TCP-Path specific path destined to the same destination MAC address or a generic path associated only to said MAC address (created by ARP-Path or Flow-Path) can be used by the frames received. If there is no active generic path, one of the specific TCP-Path paths will become generic, associating it with the destination MAC address, to be used by all frames with that destination.
- the mechanisms for establishing roads, deleting roads and forwarding described frames can be implemented in a network bridge that has the corresponding tables to associate the ports to tupias formed by pairs of MAC addresses and source and destination transport ports.
- Figure 1 shows the flow chart of the protocol for establishing the paths by TCP flow.
- Figure 2 shows the previous establishment, in a network of TCP-Path switches, of ARP-Path paths between two terminals A and C, associated to the MAC addresses of both, by exchanging the ARP Request and ARP Reply messages.
- Figure 3 shows the search for a TCP-Path path after receiving a TCP transport segment with SYN enabled (PathRequest).
- Figure 4 shows the confirmation of the path in the opposite direction with the TCP transport segment with SYN and ACK activated (PathReply).
- Figure 5 shows the ACK segment (third phase of the three-way agreement) issued by terminal A in response to the SYN + ACK forwarded by the new TCP-Path path established.
- Figure 6 shows a case where no additional TCP-Path path is created on the network because the pre-existing generic ARP-Path path is the fastest.
- Figure 7 shows the case in which a new TCP-Path additional path totally disjoint from the pre-existing generic ARP-Path path is created.
- Figures 8 and 9 show the erase of paths with FIN segments (PathFlush).
- Figure 10 shows the network after the TCP-Path paths have been deleted.
- Figure 1 1 shows the learning that is carried out in the routing tables of a bridge that has TCP-Path functionality activated.
- Figure 1 shows the operating logic of the bridge to establish the paths in the form of a flow chart.
- the first thing to look at is whether it is a transport segment with the SYN or FIN flags activated, encapsulating in the corresponding PathRequest (SYN), PathReply (SYN + ACK) or PathFlush (FIN) package if so . If it is not a segment of the previous type, it is analyzed if it is a special All-Path frame (PathRequest, PathReply or PathFlush), in which case the path is learned or cleared following the logic of TCP-Path. Finally, if it is none of the above cases, the operating logic of the generic ARP-Path and Flow-Path protocols is used.
- Terminals A, B and C are connected respectively to border bridges 1, 7 and 3. These bridges have established paths between them by means of the ARP-Path protocol, based on learning the source MAC address of the ARP Request and ARP packets Reply issued by these terminals when beginning to communicate. It is indicated with a circle circling a letter next to each bridge, the port to which the address of that terminal is associated (learned address).
- the road to A is established in certain ports of bridges 3, 2 and 1, while the road to C has been created over bridges 1, 6, 5 and 3. The direction of the frames in in case of communication traffic between terminals A and C.
- the expiration timers of each tupia associated to the port are activated and in force when the time limit for deletion has not elapsed.
- Figure 3 shows the learning done when receiving the first transport segment with the SYN flag active from terminal A.
- This segment has origin A and destination C.
- border bridge 1 On border bridge 1 it is encapsulated in a PathRequest frame that is spread throughout the network. Thus, all the bridges receive a copy of the frame and point the AC bus (road to A) in one of its ports (except bridge 1 which is the border of terminal A), discarding the slow copies which are indicated in the figure with an X.
- bridges 1, 2 and 3 had a previous path towards A, so bridge 3 learns the AC bussiness because it receives it through a different port than the current entrance of A, the port connected to bridge 4, however bridge 2 will discard it having been received by the same port as the current input of A, which is through the port through which it is connected to bridge 1.
- figure 4 shows the behavior when receiving a transport segment with the active SYN + ACK flags.
- a segment of this type is received from terminal C (in response to the previous SYN that was directed from A to C) and it is the border bridge 3 that is responsible for encapsulating it in a PathRepIy frame.
- This frame is forwarded in unicast through the port associated with the previously learned AC, that is, it is routed through bridges 3, 4 and 1.
- bridges 4 and 1 you learn the CA tupia (road to C) because there is no previous generic entry associated with C and therefore cannot coincide in port with any of them.
- Figure 5 we can see the last part of the TCP connection start, which is a transport segment with the ACK flag active.
- Figures 8, 9 and 10 show the deletion of the AC and AC inputs by means of the All-Path frames of the PathFlush type. These frames are created by encapsulating transport segments that contain the active FIN flag (either FIN or FIN + ACK).
- a FIN segment from terminal A is sent to C, deleting the AC spike, while in Figure 9 the FIN segment goes from terminal C to A, deleting the remaining spike, the AC.
- figure 10 shows how the network would look after deleting the TCP-Path paths in the previous figures using the PathFlush frame.
- each circle means (A, C, AC or CA), that is, each of the table entries of a bridge that works according to the TCP-Path specification.
- Figure 1 1 (a) shows the entries of an ARP-Path type bridge after building a path between hosts A and C. These entries consist of a search key (in this case the MAC address), an associated port , a timer or timer and a 'Locked' or 'Learnt' status.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Abstract
La presente invención describe mecanismos que exploran una red de puentes transparentes para establecer un camino específico por cada nueva conexión TCP establecida entre dos terminales. El nuevo camino lo inicia el puente frontera conectado al terminal origen al recibir un segmento TCP de tipo SYN para establecer una conexión TCP, encapsulando dicho segmento dentro de un paquete especial de petición de camino que es difundido por todos los enlaces de la red hasta el puente frontera destino. El camino es confirmado por el puente frontera del terminal destino mediante un paquete de aceptación en unidifusión que transporta encapsulado el segmento SYN+ACK de respuesta del terminal B, confirmando tanto la conexión TCP entre terminales como el camino elegido entre A y B. El camino se borra automáticamente cuando pasa un tiempo determinado sin utilizarse la conexión o al enviar el terminal un segmento FIN en ambos sentidos de la conexión.
Description
PROCEDIMIENTO DE ESTABLECIMIENTO Y BORRADO DE CAMINOS Y DE REENVIO DE TRAMAS PARA CONEXIONES DE TRANSPORTE Y PUENTE DE RED
SECTOR DE LA TÉCNICA
La presente invención se encuadra dentro del sector de las comunicaciones y de los dispositivos electrónicos y/o aplicaciones informáticas que establecen las comunicaciones entre puentes de red transparentes. ESTADO DE LA TÉCNICA
Son conocidos los protocolos de establecimiento de caminos denominados Fast-Path y ARP-Path [G. Ibáñez, J. A. Carral, A. Garcia-Martinez, J. M. Arco, D. Rivera, and A. Azcorra, "Fast Path Ethernet Switching: On-demand, Efficient Transparent Bridges for Data Center and Campus Networks", 17° IEEE Workshop on Local and Metropolitan Area Networks (LANMAN), New Jersey, USA, May 2010.] [G. Ibáñez, J.A. Carral, J.M. Arco, D. Rivera, and A. Montalvo. "ARP Path: ARP-Based, Shortest Path Bridges". IEEE Communications Letters, 201 1 , pp.770-772.], que establecen caminos mediante la exploración simultánea de toda la red mediante una trama de difusión como el ARP Request y realizan el aprendizaje en los puentes atravesados de las direcciones MAC origen y su asociación al puerto por donde se recibe primero la trama difundida.
El procedimiento de establecimiento de caminos mencionado opera como sigue: En una red de puentes ARP-Path, dos terminales A y C establecen para comunicarse sendos caminos de A a C y de C a A. Estos caminos son aprendidos en los puentes de la red mediante la difusión por todos los enlaces de una trama como ARP Request o mediante su respuesta, una trama unidifusión como ARP Reply. Los puentes asocian a la dirección MAC origen de la trama el puerto por el que se recibe primero la trama y bloquean esta asociación impidiendo su modificación durante un tiempo suficiente de forma que las copias recibidas en otros puertos de cada puente son descartadas por no estar asociada su dirección MAC origen al puerto por el que se reciben.
Estos caminos también pueden establecerse de la forma ya conocida como Flow-Path al enviar un ARP Request (del cual se registra MAC origen e IP origen y destino en el
puente frontera origen) y un ARP Reply de respuesta que confirma el camino bidireccional y simétrico asociado a las direcciones MAC origen y destino. [Elisa Rojas, Guillermo Ibanez, Diego Rivera, Juan A. Carral, "Flow-Path: An AHPath flow-based protocol", Proceedings of the 2012 IEEE 37th Conference on Local Computer Networks (October 2012) pp. 244-247].
Asimismo son conocidos los protocolos que asocian bajo ciertas condiciones la dirección MAC origen de tramas unidifusión a un puerto de entrada y verifican cuando reciben una trama unidifusión o multidifusión si el puerto está asociado o no a dicha trama [Minkenberg et al. US201 1/0032825A1 . Multipath discovery in switched Ethernet networks. Fecha de publicación, 10 de febrero de 201 1.] [Tanaka et al. First arrival port learning method, relay apparatus, and computer product. US 7760667 B2] [Mack-Crane et al. Media access control bridging in a mesh network. US 2010/0272108 A1 ]. Estos protocolos solamente aprenden direcciones MAC por lo cual tampoco pueden distribuir el tráfico por flujos ni por aplicaciones o procesos usuarios dentro de una misma máquina.
Los anteriores protocolos presentan, entre otros, el inconveniente de que todas las aplicaciones comunicándose entre dos máquinas, por lo tanto enviando y recibiendo tramas con una misma dirección MAC destino o par de direcciones origen y destino, probablemente compartan los mismos caminos y no pueden distribuir la carga de los flujos entre dos terminales por caminos distintos con una granularidad más fina diversificando los caminos según dichos flujos.
Por ello son de utilidad protocolos y mecanismos que permitan establecer caminos en la red mediante exploración directa de la misma con tramas de multidifusión replicadas en la red, pero de forma más específica, asociando cada camino a un flujo de datos, tomando en consideración para identificar cada flujo campos adicionales transportados en las tramas tales como los puertos de transporte (TCP, UDP u otros) utilizados en la conexión entre los dos terminales.
DESCRIPCIÓN DE LA INVENCIÓN
La presente invención describe mecanismos que permiten buscar, establecer, utilizar y borrar un camino específico para cada conexión TCP establecida entre dos terminales y
un puente de red que implementa dichos mecanismos. La diversidad de los caminos creados es parametrizable. La invención incluye un procedimiento de establecimiento de caminos en la red asociados a cada nuevo flujo de la capa de transporte TCP al establecer una nueva conexión TCP entre dos terminales, un procedimiento de reenvío de tramas a través de dichos caminos y un procedimiento para borrarlos al cerrar las conexiones TCP. Estos procedimientos se aplicarán por parte de los puentes TCP-Path que tengan activada dicha funcionalidad, configurable según los requerimientos de la red.
Establecimiento de caminos
Cuando, según se describe en el estado de la técnica más arriba, estando creado el camino ARP-Path entre dos terminales A y C se recibe un segmento TCP SYN en el puente frontera del terminal emisor (A) el segmento se encapsula en una trama especial PathRequest con dirección origen la dirección MAC del terminal emisor A e identificador de protocolo (Ethertype) el específico asignado a TCP-Path y se asocian, en una tabla, a efectos de reenvío, las direcciones MAC origen y puerto TCP origen, así como el identificador de la conexión TCP-Path, a la identidad del puerto del puente que primero recibió la trama, a un indicador de caducidad y al instante de llegada de la trama; y se reenvía en difusión por tados los puertos excepto el puerto de recepción. En cada puente de red atravesado se realiza la asociación de la misma forma y,si el puerto de recepción de la trama proveniente de A es diferente al asociado al camino hacia A ya existente, se registra un camino alternativo asociando dicho puerto a la tupia formada por la dirección MAC origen A, dirección MAC destino C, puerto de transporte TCP usado por A y puerto de transporte TCP usado por C {A,C,pA,pC} (abreviadamente, tupia AC) , a un identificador de caducidad y al instante de llegada de la trama. Se comprueba en cada puente si la dirección MAC destino de la trama encapsulada dentro de la trama PathRequest es la de algún terminal conectado directamente al puente atravesado. Las tramas PathRequest duplicadas que llegan después por otros puertos son descartadas por no estar su dirección MAC origen asociada al puerto de recepción. Finalmente, solamente un paquete PathRequest conteniendo el segmento SYN llegará al puente frontera, conectado directamente al terminal C. El puente desencapsulará la trama y la reenviará al terminal C, asociando igualmente un identificador de caducidad a las direcciones MAC y TCP origen y al instante de llegada de la trama. El terminal C contestará con un segmento SYN+ACK confirmando el establecimiento de la conexión
TCP. El puente frontera destino (conectado a C) encapsula el segmento SYN+ACK en un paquete PathReply con dirección MAC origen C, dirección MAC destino A e identificador de protocolo (Ethertype) el asignado al protocolo TCP-Path, y lo reenvía en unidifusión por el puerto asociado a la tupia AC, previamente asociada a dicho puerto cuando se recibió el paquete PathRequest. A su vez, el puente asocia (aprende) la dirección MAC de C, la dirección MAC de A, el puerto de transporte de C y el puerto de transporte de A al puerto por donde se ha recibido, identificados como la tupia {C,A,pC,pA} (abreviadamente, tupia CA) , asociándolos al identificador de caducidad anteriormente creado de la tupia AC, actualizando el tiempo de llegada, confirmando y renovando la validez de la asociación.. En cada puente atravesado se asocia igualmente el puerto de recepción a dicha tupia CA y se reenvía por el puerto asociado a la tupia AC, asociada a la conexión desde C hacia el terminal A, confirmando y renovando el camino en dirección hacia A , asociándolos al identificador de caducidad anteriormente creado de la tupia AC, actualizando el tiempo de llegada, confirmando y renovando la validez de la asociación..
Con el fin de aumentar la diversidad de caminos, cuando un puente recibe el paquete PathRequest por el mismo puerto que ya tenía asociado al camino genérico ARP-Path para A, dicho puente puede asociar el camino de transporte a un puerto distinto siempre que reciba el PathRequest duplicado con una diferencia de tiempo reducida y limitada respecto al puerto que primero lo recibe.
El paquete PathReply llega finalmente en unidifusión hasta el puente frontera de destino, al cual está conectado directamente el terminal destino A. El puente desencapsula la trama conteniendo el segmento original SYN+ACK y la reenvía al terminal A. El terminal A responderá con una trama conteniendo un segmento de transporte con el indicador ACK activado, el cual será reenviado como un segmento normal, sin encapsular, por el camino asociado a esa pareja de direcciones MAC y al par de puertos TCP de la conexión. De la misma forma serán encaminados los sucesivos segmentos de datos enviados del terminal A al C.
El protocolo TCP-Path encapsula los segmentos de transporte que contienen el indicador SYN activado (solamente el indicador SYN o bien los indicadores SYN y ACK activados), y establece y confirma con ellos caminos alternativos a los ya existentes, previamente establecidos mediante alguno de los protocolos conocidos: ARP-Path o Flow-Path. El
camino de A a C puede existir previamente o no, tanto como camino ARP-Path asociado solamente a la dirección MAC A o como camino bidireccional Flow-Path asociado a las direcciones A y C, la diferencia radica en que TCP-Path sólo establece un camino nuevo asociado a la conexión si no existe camino previo entre A y C o, si existiendo, éste es diferente del que está siendo creado (es decir, el puerto asociado a la tupia es diferente del ya existente). Como consecuencia, el camino de transporte TCP-Path establecido entre A y C puede parcial, completamente, o en absoluto coincidir con los caminos preexistentes. Sólo habrá un camino entre A y C establecido por ARP-Path y Flow-Path, mientras que TCP-Path puede crear tantos caminos adicionales como conexiones de transporte existan en cada momento.
Los caminos establecidos se refrescan, prolongando su validez, automáticamente al recibirse tramas del flujo asociado al camino. Este refresco puede ser hacia delante y opcionalmente bidireccional, según se configure. En el refresco hacia delante las tramas recibidas renuevan la asociación de la MAC destino de la trama reenviada al puerto de salida. En el bidireccional renuevan también la asociación de la dirección MAC origen al puerto de entrada.
Borrado de caminos
Si los caminos no se utilizan por las tramas asociadas a ellos (con tupias de puertos de transporte y direcciones MAC en la tabla de reenvío) durante un tiempo superior al temporizador de persistencia (caché) de los puentes, expiran automáticamente, borrándose de la memoria los puertos asociados al camino. Asimismo, cuando un camino establecido se interrumpe, por fallo de un enlace o de puente, se produce el borrado inmediato de las direcciones aprendidas en el puerto, asociadas en la tabla de reenvío al puerto conectado al enlace o puente en fallo.
De manera similar al establecimiento, los caminos TCP-Path pueden ser borrados explícitamente por los terminales cuando envían un segmento FIN en cada dirección para cerrar la conexión TCP. Un terminal enviará un segmento FIN que es respondido por el terminal destino con un segmento ACK. Este segmento FIN cerrará la conexión TCP-Path en el sentido del segmento FIN enviado. Igualmente sucederá desde el extremo remoto cuando se emita un segmento FIN contestado con un segmento ACK hacia el extremo
remoto para cerrar la conexión en el sentido remoto-cercano. Alternativamente, el extremo receptor puede contestar con un segmento combinado FIN+ACK (el denominado cierre TCP de tres vías), que será contestado con un segmento ACK para confirmar el cierre en el sentido remoto-cercano. Este segmento ACK no se encapsula.
Más concretamente, cuando el puente frontera recibe un segmento TCP con el indicador FIN activado, encapsula el segmento en un paquete PathFlush con direcciones origen y destino iguales a las del segmento recibido, el cual es reenviado en unidifusión hacia el destino siguiendo el camino establecido por CA, para así borrar el camino de A hacia C asociado a esa conexión TCP. El siguiente puente atravesado, al recibir dicha trama de unidifusión PathFlush con el campo de tipo de protocolo, conteniendo el valor asignado al protocolo "TCP-Path", borra de la tabla, a efectos de reenvío, la asociación de dirección MAC destino y puerto de transporte destino al puerto del puente y el contenido del temporizador de caducidad asociado, sin modificar otras asociaciones de dicha dirección MAC a otros puertos del puente; comprueba asimismo si la dirección MAC destino de la trama encapsulada dentro de la trama PathFlush corresponde a un terminal conectado directamente al puente que recibe la trama y, en caso afirmativo, desencapsula la trama y la reenvía al terminal destino por el puerto del puente asociado a dicho terminal. Si la dirección MAC destino de la trama encapsulada no está asociada a un terminal conectado directamente al puente que recibe la trama, el puente reenvía la trama PathFlush en unidifusión por el puerto asociado a los "campos de la conexión TCP" recién borrados.
Reenvío de tramas
Cuando una trama de datos se recibe en un puente TCP-Path, se consultan los campos de conexión TCP: direcciones MAC origen y destino, puertos de transporte de origen y destino, y se verifica si existe un puerto asociado a dicha conexión como destino; si existe, se reenvía la trama por el puerto asociado a dicha conexión hacia el terminal destino y se renueva por un período adicional el temporizador asociado a la dirección MAC destino y conexión TCP-Path asociada; si no existe, se comprueba, de forma menos restrictiva, si existe algún puerto del puente asociado a la dirección MAC destino de la trama o al par dirección MAC destino y MAC origen de la trama; si existe se reenvía la trama por dicho puerto; en los demás casos se iniciará el proceso de reparación de caminos mediante el envío de una trama de multidifusión. Es decir, cuando no existe un
camino específico TCP-Path, puede ser utilizado por las tramas recibidas otro camino específico TCP-Path destinado a la misma dirección MAC destino o bien un camino genérico asociado solamente a dicha dirección MAC (creado mediante ARP-Path o Flow- Path). Si no hay camino genérico activo, uno de los caminos específicos TCP-Path pasará a ser genérico, asociándolo a la dirección MAC destino, para ser utilizado por todas las tramas con ese destino.
Si no existe ningún camino genérico, se repara el camino genérico con la reparación habitual de ARP-Path o Flow-Path descrita en [Elisa Rojas, Guillermo Ibanez, Diego Rivera, Juan A. Carral, "Flow-Path: An AHPath flow-based protocol", Proceedings of the 2012 IEEE 37th Conference on Local Computer Networks (October 2012) pp. 244-247].
Puente de red para caminos TCP-path
Los mecanismos de establecimiento de caminos, borrado de caminos y reenvío de tramas descritos pueden implementarse en un puente de red que disponga de las correspondientes tablas para asociar los puertos a tupias formadas por parejas de direcciones MAC y de puertos de transporte origen y destino.
DESCRIPCIÓN BREVE DE LOS DIBUJOS
La figura 1 muestra el diagrama de flujo del protocolo para establecer los caminos por flujo TCP.
La figura 2 muestra el establecimiento previo, en una red de conmutadores TCP-Path, de caminos ARP-Path entre dos terminales A y C, asociados a las direcciones MAC de ambos, mediante el intercambio de los mensajes ARP Request y ARP Reply.
La figura 3 muestra la búsqueda de un camino TCP-Path tras la recepción de un segmento de transporte TCP con SYN activado (PathRequest).
La figura 4 muestra la confirmación del camino en sentido contrario con el segmento de transporte TCP con SYN y ACK activados (PathReply).
En la figura 5 se muestra el segmento ACK (tercera fase del acuerdo de tres vías) emitido por el terminal A como respuesta al SYN+ACK reenviado por el nuevo camino TCP-Path establecido. La figura 6 muestra un caso en que no se crea ningún camino adicional TCP-Path en la red porque el camino genérico ARP-Path preexistente es el más rápido.
La figura 7 muestra el caso en que se crea un camino adicional TCP-Path nuevo totalmente disjunto del camino genérico ARP-Path preexistente.
Las figuras 8 y 9 muestran el borrado de caminos con segmentos FIN (PathFlush).
La figura 10 muestra la red tras ser borrados los caminos TCP-Path. La figura 1 1 muestra el aprendizaje que se realiza en las tablas de encaminamiento de un puente que tenga la funcionalidad TCP-Path activada.
MODO DE REALIZACIÓN
Se describe un modo de realización de la invención. La figura 1 muestra la lógica de funcionamiento del puente para establecer los caminos en forma de diagrama de flujos. Al recibir una trama lo primero que se mira es si se trata de un segmento de transporte con los flags SYN o FIN activados, encapsulándose en el correspondiente paquete PathRequest (SYN), PathReply (SYN+ACK) o PathFlush (FIN) de ser así. Si no es un segmento del tipo anterior, se analiza si se trata de una trama especial All-Path (PathRequest, PathReply o PathFlush), en cuyo caso se aprende o se borra el camino siguiendo la lógica de TCP-Path. Por último, si no es ninguno de los anteriores casos, se utiliza la lógica de funcionamiento de los protocolos ARP-Path y Flow-Path genérica.
En la figura 2 se muestra una red de ejemplo para examinar el mecanismo de aprendizaje, borrado y reparación de TCP-Path. Los terminales A, B y C están conectados respectivamente a los puentes frontera 1 , 7 y 3. Estos puentes tienen establecidos caminos entre ellos mediante el protocolo ARP-Path, basado en el aprendizaje de la dirección MAC origen de los paquetes ARP Request y ARP Reply emitidos por dichos terminales al comenzar a comunicarse. Se indica con un círculo
rodeando una letra junto a cada puente, el puerto al que está asociada la dirección de dicho terminal (dirección aprendida). Por ejemplo, el camino hacia A está establecido en ciertos puertos de los puentes 3, 2 y 1 , mientras que el camino hacia C se ha creado sobre los puentes 1 , 6, 5 y 3. Se muestra así la dirección de las tramas en caso de haber tráfico de comunicación entre los terminales A y C. Los temporizadores de caducidad de cada tupia asociada al puerto están activados y vigentes al no haber transcurrido el tiempo límite para el borrado.
En la figura 3 se muestra el aprendizaje realizado al recibir el primer segmento de transporte con el flag SYN activo desde el terminal A. Este segmento tiene como origen A y como destino C. En el puente frontera 1 se encapsula en una trama PathRequest que es difundida por toda la red. Así pues, todos los puentes reciben una copia de la trama y apuntan la tupia AC (camino hacia A) en uno de sus puertos (excepto el puente 1 que es el frontera del terminal A), descartando las copias lentas las cuales se indican en la figura con una X. En este caso, sólo los puentes 1 , 2 y 3 tenían un camino previo hacia A, por lo que el puente 3 aprende la tupia AC porque la recibe por un puerto diferente que la actual entrada de A, el puerto conectado al puente 4, sin embargo el puente 2 la descartará al haber sido recibida por el mismo puerto que la actual entrada de A, que es por el puerto por el cual está conectado al puente 1.
A continuación, en la figura 4 se expone el comportamiento al recibir un segmento de transporte con los flags SYN+ACK activos. En este caso se recibe un segmento de dicho tipo desde el terminal C (como respuesta al SYN previo que iba dirigido de A a C) y es el puente frontera 3 el que se encarga de encapsularlo en una trama PathRepIy. Esta trama se reenvía en unidifusión por el puerto asociado a la tupia previamente aprendida AC, es decir, se encamina a través de los puentes 3, 4 y 1 . En los puentes 4 y 1 se aprende la tupia CA (camino hacia C) porque no hay ninguna entrada genérica anterior asociada a C y por lo tanto no puede coincidir en puerto con ninguna de ellas. Finalmente en la figura 5 podemos ver la última parte del inicio de conexión TCP, que es un segmento de transporte con el flag ACK activo. Este último segmento con origen A y destino C no tiene el flag SYN activo, por lo que el puente frontera 1 no lo encapsula y lo trata como a cualquier otra trama de tráfico de dicha conexión recién iniciada, encaminándolo por los puertos asociados a la tupia CA y pasando por los puentes 1 , 4 y
3, hasta llegar a C. Nótese que en el puente 3 no existe una entrada asociada a la tupia CA por ser el puente frontera de C, por lo que se utiliza la entrada genérica C para encaminar, aprendida en el primer paso por el protocolo ARP-Path. Las figuras 6 y 7 muestran dos casos extremos de posibles caminos creados mediante TCP-Path. En la figura 6 los caminos A y C creados por ARP-Path coinciden en dirección, atravesando ambos los puentes 1 , 2 y 3, y además los caminos AC y CA creados por TCP-Path también. En la práctica lo que sucedería en este caso es que las tupias AC y CA no se anotarían, al coincidir con los puertos de las entradas genéricas A y C ya existentes, por lo que no habría camino alternativo, situación que puede darse en caso de que el camino 1 , 2 y 3 siga siendo el camino más rápido y no esté muy utilizado todavía. En el caso de la figura 7 se muestra el extremo contrario, aquel en el que los caminos genéricos de ARP-Path A y C no comparten puentes (salvo los puentes frontera 1 y 3), y además el camino TCP-Path entre A y C atraviesa también puentes diferentes (pasando por el puente 4). Este último caso podría darse cuando todos los caminos son igual de rápidos y se distribuirían por igual por toda la red. Nótese que los caminos TCP-Path son simétricos, por lo que las tupias AC y CA siempre comparten puentes en uno y otro sentido (en este caso 1 , 4 y 3), mientras que los caminos genéricos ARP-Path no tienen por qué serlo.
Las figuras 8, 9 y 10 muestran el borrado de las entradas AC y CA mediante las tramas All-Path de tipo PathFlush. Estas tramas se crean al encapsular segmentos de transporte que contengan el flag FIN activo (ya sean FIN o FIN+ACK). En la figura 8 se envía un segmento FIN del terminal A hasta el C, borrando la tupia CA, mientras que en la figura 9 el segmento FIN va desde el terminal C hasta el A borrando la tupia que queda, la AC. Finalmente la figura 10 muestra cómo quedaría la red tras el borrado de los caminos TCP-Path en las figuras anteriores mediante la trama PathFlush.
En la figura 1 1 podemos ver qué significa cada círculo (A, C, AC o CA), es decir, cada una de las entradas en tabla de un puente que funcione siguiendo la especificación de TCP-Path. La figura 1 1 .a) muestra las entradas de un puente de tipo ARP-Path tras construir un camino entre los hosts A y C. Estas entradas se componen de una clave de búsqueda (en este caso la dirección MAC), un puerto asociado, un temporizador o timer y un estado 'Locked' (Bloqueado) o 'Learnt' (Aprendido). Cuando llega una nueva trama
PathRequest asociada a un mensaje SYN del protocolo TCP y con origen A y destino C, si la primera copia llega por un puerto diferente al ya asociado, se produce un aprendizaje de tipo TCP-Path y se apuntará su clave dentro de la tabla tal y como muestra 1 1 .b). Es decir, la entrada con clave A será la entrada genérica para alcanzar el destino A, mientras que AC-* será la clave concreta del camino de TCP-Path con destino A, pero que sólo se utilizará cuando el origen sea C y se cumplan otra serie de parámetros (especificados con *) como pueden ser números de puertos, etc. Con la respuesta de C hacia A, SYN+ACK encapsulado en un mensaje PathReply, si ésta llega por un puerto diferente al ya asociado a C, se realizará un aprendizaje análogo (figura 1 1.c).
Por lo tanto, además del camino base, se crearán caminos adicionales con claves más concretas, mientras que el resto de entradas de la tabla serán análogas.
Por otro lado, cuando llegue una trama de datos con destino A, se realizarán ahora dos búsquedas, una específica de clave y otra genérica si no se encontró la primera. Pero a su vez, si el camino específico sí existía y se borró por un fallo de enlace, esto garantiza que seguirá siendo posible el uso del camino base, o genérico, para el encaminamiento.
Claims
REIVINDICACIONES Procedimiento de establecimiento de caminos, reenvío de tramas y borrado de caminos de tramas de datos que comprende:
- recibir, a través de un puerto de un puente de red donde dicho puerto tiene una identidad de puerto asignada, una trama que comprende una dirección MAC origen y una dirección de difusión destino;
- asociar, en una tabla, a efectos de reenvío del puente, la dirección MAC origen de la trama recibida a la identidad del puerto que primero recibió la trama en dicho puente, a un indicador de caducidad de dicha asociación y al instante de llegada de la trama;
- bloquear esta asociación durante un tiempo determinado, impidiendo la asociación de dicha dirección origen a otro puerto del puente;
- descartar las tramas recibidas por puertos distintos al asociado a la dirección origen de la trama durante el tiempo en que esté bloqueada esa asociación;
- reenviar las tramas unidifusión recibidas por el puerto del puente que esté asociado a la dirección MAC destino de la trama
- borrar, en la tabla, a efectos de reenvío, las asociaciones de direcciones que tenga un puerto de un puente cuando detecte la caída de un enlace en dicho puerto o expire el temporizador de validez de la dirección;
- solicitar la reparación del camino mediante una trama de multidifusión cuando una trama con destino unidifusión llega a un puente que no tiene ningún puerto asociado en la tabla, a efectos de reenvío para dicha dirección MAC. caracterizado por
- La existencia de una etapa de establecimiento en la que, al recibir en un puerto de un puente de red con una identidad asignada a cada uno de sus puertos una trama que transporta un segmento TCP que tiene el indicador de solicitud de conexión SYN activado y el indicador ACK desactivado,
- crear una nueva conexión, asignándole un identificador interno único de conexión TCP-Path y asociar dicho identificador a la combinación exacta de los campos siguientes contenidos en la trama que transporta el
segmento TCP: dirección MAC origen, dirección MAC destino de la trama que transporta el segmento TCP y puertos de transporte TCP origen y destino de la cabecera del segmento TCP, en lo sucesivo "campos de la conexión TCP";
- asociar, en una tabla, a efectos de reenvío, las direcciones MAC origen y puerto TCP origen, así como el identificador de la conexión TCP-Path, a la identidad del puerto del puente que primero recibió la trama, a un indicador de caducidad de la trama y al instante de llegada de la trama;
- encapsular la trama conteniendo el segmento TCP dentro de una trama especial de multidifusión PathRequest con dirección destino la dirección de grupo multicast compartida por "todos los puentes TCP-Path" y con dirección origen la dirección MAC del puente que encapsula la trama.
La existencia de una etapa de confirmación y renovación, en la que, al recibir en un puente de red una trama conteniendo un segmento TCP con el indicador de solicitud de conexión SYN activado y el indicador ACK activado (segmento SYN- ACK),
- confirmar y renovar la conexión, en la tabla, a efectos de reenvío, renovando durante un tiempo determinado la vigencia de la asociación, creada previamente en el puente al recibirse el paquete PathRequest, de los "campos de la conexión TCP" de la trama recibida mencionados anteriormente (direcciones MAC origen y destino e identidades de puerto TCP origen y TCP destino) con el identificador de conexión, con la identidad del puerto del puente que primero recibió la trama, con un indicador de caducidad de la trama y con el instante de llegada de la trama;
- encapsular la trama conteniendo el segmento TCP SYN-ACK dentro de una trama especial de unidifusión PathReply, con dirección MAC origen la del puente que la encapsula y destino la dirección MAC del puente que fue asociado en el puente a dicha conexión tras la recepción del PathRequest para dicha conexión.
La existencia de una etapa de borrado, en la que, al recibir en un puente de red una trama conteniendo un segmento TCP con el indicador de solicitud de conexión FIN activado;
- encapsular el segmento TCP dentro de una trama especial de unidifusión PathFlush dirigida al puente frontera destino por el puerto asociado a la dirección del terminal destino, con el campo de tipo de protocolo, Ethertype, con el valor asignado a "TCP-Path";
- borrar, de la tabla, a efectos de reenvío, la asociación de los "campos de la
conexión TCP" asociados al destino y los contenidos de los temporizadores asociados.
-Al recibir en un puente de red una trama no incluida en los casos anteriores:
- verificar su pertenencia a una conexión existente en el puente consultando los campos de conexión TCP: direcciones MAC origen y destino, puertos de transporte de origen y destino;
- en caso afirmativo: reenviar la trama por el puerto asociado a dicha conexión hacia el terminal destino y renovar el temporizador asociado a la dirección MAC destino;
- en los demás casos: si existe un camino específico TCP-Path asociado a la dirección MAC destino pero vinculado a un puerto del puente distinto al puerto en fallo, reenviar dicha trama por dicho puerto de salida.
- en los demás casos: comprobar si existe algún puerto del puente asociado a la dirección MAC destino de la trama;
- en caso afirmativo: reenviar la trama por dicho puerto;
- en los demás casos: enviar una trama multidifusion para iniciar el mecanismo de reparación de caminos.
2. Procedimiento según la reivindicación 1 , caracterizado por, en la etapa de establecimiento, al recibir en un puente de red una trama de multidifusion PathRequest dirigida a la dirección de grupo de multidifusion "todos los puentes TCP- Path" y tipo de protocolo, campo en la trama usualmente conocido como Ethertype, con el valor de "TCP-Path";
- asociar, en una tabla, a efectos de reenvío, las direcciones MAC origen y destino e identidades de puertos de transporte origen y destino de la trama original encapsulada dentro de la trama recibida ("campos de la conexión TCP") a la identidad del puerto del puente que primero recibió la trama, a un indicador de caducidad de la trama y al instante de llegada de la trama;
- asociar, en una tabla, a efectos de reenvío, la dirección MAC origen de la trama PathRequest a la identidad del puerto del puente que primero recibió la trama;
- comprobar si la dirección MAC destino de la trama encapsulada dentro de
la trama PathRequest corresponde a un terminal conectado directamente al puente que recibe la trama;
- en caso afirmativo: desencapsular la trama y reenviarla al terminal destino
por el puerto del puente asociado a dicho terminal;
- en los demás casos: reenviar la trama por todos los puertos excepto el puerto donde se recibió primero;
- encolarla en las colas de salida de los puertos del puente según criterios de prioridad configurados previamente.
Procedimiento, según la reivindicación 1 , caracterizado por, en la etapa de confirmación y renovación, al recibir en un puente de red una trama de unidifusion PathReply con destino una dirección MAC de puente y con el tipo de protocolo, campo en la trama usualmente conocido como Ethertype, conteniendo el valor asociado a "TCP-Path";
- asociar, en una tabla, a efectos de reenvío, las direcciones MAC origen y destino e identidades de puertos de transporte origen y destino de la trama original encapsulada dentro de la trama recibida ("campos de la conexión TCP"), a la identidad del puerto del puente que primero recibió la trama, a un indicador de caducidad de la trama y al instante de llegada de la trama;
- comprobar si la dirección MAC destino, del encapsulado exterior de la trama corresponde al puente que está procesando la trama;
- en caso afirmativo: desencapsular la trama y reenviarla al terminal destino por el puerto del puente asociado a dicho terminal;
- en los demás casos: reenviar la trama por el puerto asociado a las direcciones MAC origen y destino y puertos de transporte origen y destino de la conexión TCP-Path y renovar la asociación de los "campos de la conexión TCP" al puerto de reenvío.
Procedimiento según la reivindicación 1 , caracterizado por, en la etapa de borrado, al recibir en un puente de red una trama de unidifusion PathFlush con el campo de tipo de protocolo, Ethertype, con el valor asignado al protocolo "TCP-Path"; borrar, de la tabla, a efectos de reenvío, la asociación de los "campos de la conexión TCP" asociados al destino y los contenidos de los temporizadores asociados, sin modificar otras asociaciones de dichas direcciones MAC a puertos del puente que no estén vinculadas a los puertos origen y destino indicados;
comprobar si la dirección MAC destino de la trama encapsulada dentro de la trama PathFlush corresponde a un terminal conectado directamente al puente que recibe la trama;
en caso afirmativo: desencapsular la trama y reenviarla al terminal destino por el puerto del puente asociado a dicho terminal;
en los demás casos: reenviar la trama PathFlush en unidifusion por el puerto asociado a los "campos de la conexión TCP" recién borrados.
Puente de red caracterizado porque dispone de los medios de procesamiento apropiados para implementar el procedimiento de las reivindicaciones 1 a 4.
Red de telecomunicaciones conmutada caracterizada por comprender al menos un puente de red definido según la reivindicación 5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US15/103,049 US20160308727A1 (en) | 2013-12-10 | 2014-12-10 | Method for establishing and clearing paths and forwarding frames for transport connections, and network bridge |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| ESP201301133 | 2013-12-10 | ||
| ES201301133A ES2540595B2 (es) | 2013-12-10 | 2013-12-10 | Procedimiento de establecimiento y borrado de caminos y de reenvio de tramas para conexiones de transporte y puente de red |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2015086877A1 true WO2015086877A1 (es) | 2015-06-18 |
Family
ID=53370657
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/ES2014/070905 WO2015086877A1 (es) | 2013-12-10 | 2014-12-10 | Procedimiento de establecimiento y borrado de caminos y de reenvio de tramas para conexiones de transporte y puente de red |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US20160308727A1 (es) |
| ES (1) | ES2540595B2 (es) |
| WO (1) | WO2015086877A1 (es) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109462591A (zh) * | 2018-11-19 | 2019-03-12 | 中国科学院信息工程研究所 | 一种数据传输方法、接收方法、装置及系统 |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2015102468A1 (en) * | 2014-01-06 | 2015-07-09 | Samsung Electronics Co., Ltd. | Method and apparatus for relaying packet transmission and updating network address information in communication system |
| US9912616B2 (en) * | 2015-12-02 | 2018-03-06 | Nicira, Inc. | Grouping tunnel endpoints of a bridge cluster |
| US10164885B2 (en) | 2015-12-02 | 2018-12-25 | Nicira, Inc. | Load balancing over multiple tunnel endpoints |
| US10719341B2 (en) | 2015-12-02 | 2020-07-21 | Nicira, Inc. | Learning of tunnel endpoint selections |
| US10069646B2 (en) | 2015-12-02 | 2018-09-04 | Nicira, Inc. | Distribution of tunnel endpoint mapping information |
| US20170195218A1 (en) * | 2015-12-30 | 2017-07-06 | Qualcomm Incorporated | Routing in a hybrid network |
| ES2638292B2 (es) * | 2016-03-18 | 2018-04-17 | Universidad De Alcalá | Procedimiento de establecimiento y borrado de caminos múltiples disjuntos, de reenvío de tramas y puente de red |
| CN108024291B (zh) * | 2016-11-01 | 2023-02-24 | 中兴通讯股份有限公司 | 一种移动网络中共享上网检测的方法及装置 |
| KR102015735B1 (ko) * | 2018-12-28 | 2019-08-28 | 주식회사 모파스 | P2p 핸드쉐이킹 제어를 위한 피어의 통신 방법 및 장치 |
| CN110572438A (zh) * | 2019-08-14 | 2019-12-13 | 北京天融信网络安全技术有限公司 | 一种网络连接建立方法、装置、网络设备和存储介质 |
| US11743191B1 (en) | 2022-07-25 | 2023-08-29 | Vmware, Inc. | Load balancing over tunnel endpoint groups |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030016624A1 (en) * | 1998-05-04 | 2003-01-23 | Bare Ballard C. | Path recovery on failure in load balancing switch protocols |
| US7760668B1 (en) * | 2006-06-20 | 2010-07-20 | Force 10 Networks, Inc. | Self-reconfiguring spanning tree |
-
2013
- 2013-12-10 ES ES201301133A patent/ES2540595B2/es active Active
-
2014
- 2014-12-10 WO PCT/ES2014/070905 patent/WO2015086877A1/es active Application Filing
- 2014-12-10 US US15/103,049 patent/US20160308727A1/en not_active Abandoned
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030016624A1 (en) * | 1998-05-04 | 2003-01-23 | Bare Ballard C. | Path recovery on failure in load balancing switch protocols |
| US7760668B1 (en) * | 2006-06-20 | 2010-07-20 | Force 10 Networks, Inc. | Self-reconfiguring spanning tree |
Non-Patent Citations (1)
| Title |
|---|
| IBANEZ GUILLERMO ET AL.: "All-path bridging: Path exploration as an efficient alternative to path computation in bridging standards.", IEEE INTERNATIONAL CONFERENCE ON COMMUNICATIONS WORKSHOPS (ICC, pages 1280 - 1285 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109462591A (zh) * | 2018-11-19 | 2019-03-12 | 中国科学院信息工程研究所 | 一种数据传输方法、接收方法、装置及系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20160308727A1 (en) | 2016-10-20 |
| ES2540595A1 (es) | 2015-07-10 |
| ES2540595B2 (es) | 2016-02-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2540595B2 (es) | Procedimiento de establecimiento y borrado de caminos y de reenvio de tramas para conexiones de transporte y puente de red | |
| US6701361B1 (en) | Enhanced mobility and address resolution in a wireless premises based network | |
| ES2361545B1 (es) | Procedimiento de encaminamiento de tramas de datos y puente de red. | |
| Sajassi et al. | Bgp mpls-based ethernet vpn | |
| ES2268165T3 (es) | Optimacion de agente local para manipular ip movil y mpls estaticas (conmutacion de etiquetas multiprotocolo). | |
| US6847620B1 (en) | Mobile virtual LAN | |
| US8717934B2 (en) | Multicast source move detection for layer-2 interconnect solutions | |
| ES2614614T3 (es) | Igualación de carga en dominios de capa-2 | |
| US9060331B2 (en) | Home virtual local area network identification for roaming mobile clients | |
| EP3451596A1 (en) | Multicast flow overlay using registration over a reliable transport | |
| EP3035592B1 (en) | Enhanced protocol independent multicast source registration over a reliable transport | |
| CN106341327A (zh) | 一种bier报文的传输方法及系统 | |
| KR20140027455A (ko) | 이더넷 패킷을 인터넷 프로토콜 네트워크를 통해 라우팅하는 집중 시스템 | |
| US20100202344A1 (en) | Mobile communication control method, data communication device, mobile base station, and mobile terminal | |
| EP3599745B1 (en) | Method and apparatus for preventing loops in a network topology | |
| JP2009530907A5 (es) | ||
| JPWO2006093299A1 (ja) | トンネリング装置及びそれに用いるトンネルフレーム振分方法並びにそのプログラム | |
| ES2388597T3 (es) | Método para la comunicación en una red que comprende un dispositivo ZigBee sin batería, red y dispositivo para ello | |
| US6868086B1 (en) | Data packet routing | |
| JP2010517344A (ja) | ルート最適化手順によるデータパケットのヘッダ縮小の方法 | |
| Aggarwal et al. | RFC 7432: BGP MPLS-Based Ethernet VPN | |
| JP2006005607A (ja) | ネットワークシステムおよび移動ルータ | |
| ES2638292B2 (es) | Procedimiento de establecimiento y borrado de caminos múltiples disjuntos, de reenvío de tramas y puente de red | |
| ES2647665B2 (es) | Procedimiento cooperativo, entre puentes y controlador, de reparación de caminos en fallo y puente de red | |
| JP4660346B2 (ja) | ブリッジ装置及びブリッジ装置の制御方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 14869528 Country of ref document: EP Kind code of ref document: A1 |
|
| WWE | Wipo information: entry into national phase |
Ref document number: 15103049 Country of ref document: US |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 14869528 Country of ref document: EP Kind code of ref document: A1 |