• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    The present invention describes mechanisms that explore a network of transparent bridges to establish a specific path for each new tcp connection established between two terminals. The new path is initiated by the border bridge connected to the originating terminal by receiving a tcp segment of type syn to establish a tcp connection, encapsulating said segment within a special path request packet that is broadcast by all the links in the network to the destination border bridge. The path is confirmed by the frontier bridge of the destination terminal by means of a unicast acceptance packet that transports the syn ack segment of the terminal b response encapsulated, confirming both the tcp connection between terminals and the chosen path between a and b. The path is it automatically deletes when a certain time passes without using the connection or sending the terminal a fin segment in both directions of the connection. (Machine-translation by Google Translate, not legally binding)
    公开号:ES2540595A1
    申请号:ES201301133
    申请日:2013-12-10
    公开日:2015-07-10
    发明作者:Elisa ROJAS SÁNCHEZ；Guilermo IBÁÑEZ FERNÁNDEZ；Isaías MARTINEZ YELMO；Arturo Azcorra Saloña
    申请人:INSTITUTE IMDEA NETWORKS；INST IMDEA NETWORKS；Universidad de Alcala de Henares UAH；
    IPC主号:
    专利说明:

    5 PROCEDURE FOR ESTABLISHING AND DELETING ROADS AND FORWARDING OF PAFTA SECTIONS AND TRANSFER CONNECTIONS AND NETWORK BRIDGE SECTOR OF THE TECHNIQUE 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 ART The protocols for establishing roads called Fast-Path and ARP-Path [G. Ibanez, JA Carral, A. Garcia-Martinez, JM Arco, D. Rivera, and A. Azcorra, "Fast Path Ethernet Switching: On-demand, Efficient Transparent Bridges for Data 15 Center and Campus Networks", 17th IEEE Workshop on Local and Metropolitan Area Networks (LANMAN), New Jersey, USA, May 2010.] [G. Ibanez, J.A. Carral, J.M. Arco, D. Rivera, and A. Montalvo. "ARP Path: ARP-Based, Shortest Path Bridges". IEEE Communications Letters, 2011, pp.770-772.], Which establish paths through the simultaneous exploration of the entire network by means of a broadcast frame such as the ARP 20 Request and perform the learning on the crossed bridges of the source MAC addresses and their association to the port where the broadcast frame is first received. The aforementioned path establishment procedure operates as follows: In an ARP-Path bridge network, two terminals A and C establish to communicate 25 paths of Aa Cy from C to A. These paths are learned in the bridges of the network by means of the diffusion through all the links of a frame like ARP Request or through its response, a unidifusion frame like ARP Reply. The bridges associate to the origin MAC address of the frame the port through which the frame is first received and they block this association by asking for its modification for a sufficient time so that the copies received in other ports of each bridge are discarded because they are not associated its source MAC address to the port through which it is received. These paths can also be established in the form known as Flow-Path by sending an ARP Request (from which MAC source is registered and source IP and destination in bridge 2).
    Nº application28 / 11 / 2014F.OEPM28 / 11 / 2014F.Efectiva
    source border) and an answer ARP Reply that confirms the bidirectional and symmetric path associated with the source and destination MAC addresses. [Elisa Rojas, Guillermo Ibanez, Diego Rivera, Juan A. Carral, "Flow-Path: An AIIPath flow-based protocol", Proceedings of the 2012 IEEE 37th Conference on Local Computer Networks (October 2012) pp. 244-247].
    Also known are the protocols that associate under certain conditions the MAC address of unicast frames to an input port and verify when they receive a unicast or multicast frame if the port is associated or not with said frame [Minkenberg et al. US2011 / 0032825A1. Multipath discovery in switched Ethernet networks. Date of publication, February 10, 2011.] [Tanaka et al. First arrival port leaming method, relay apparatus, and computer product. US 7760667 82] [Mack-Crane et al. Media access control bridging in a mesh network. US 2010/0272108 A1]. These protocols only learn MAC addresses, so they can not distribute traffic by flows or by applications or user processes within the same machine.
    The previous protocols present, among others, the disadvantage that all applications communicating between two machines, therefore sending and receiving frames with the same destination MAC address or pair of source and destination addresses, probably share the same paths and can not distribute the load of the flows between two terminals by different roads with a finer granularity diversifying the roads according to said flows.
    For this reason, protocols and mechanisms are useful to establish paths in the network through direct exploration of the same with multicast frames replicated in the network, but more specifically, associating each path to a data flow, taking into consideration to identify each flow additional fields transported in the frames such as the transport ports (TCP, UDP or others) used in the connection between the two terminals.
    DESCRIPTION OF THE INVENTION
    The present invention describes mechanisms that allow to search, establish, use and delete a specific path for each TCP connection established between two terminals and a network bridge that implements said mechanisms. The diversity of the created roads is parametrizable. The invention includes a procedure for establishing paths in the network associated with each new flow of the TCP transport layer when establishing a new TCP connection between two terminals, a procedure for forwarding frames through said paths and a procedure for deleting them at close TCP connections. These procedures will be applied by TCP-Path bridges that have activated this functionality, configurable according to the requirements of the network.
    Nº application28 / 11 / 2014F.OEPM28 / 11 / 2014F.Efectiva
    Establishment of roads
    When, as described in the prior art, when the ARP-Path path between two terminals A and C is created, a TCP segment SYN is received at the frontier bridge of the sending terminal (A) the segment is encapsulated in a frame special PathRequest with source address the MAC address of the sending terminal A and protocol identifier (Ethertype) the specific assigned to TCP-Path and associated, in a table, for forwarding purposes, the source MAC addresses and the origin 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 it is forwarded in diffusion through all the ports except the reception port.
    In each crossed network bridge the association is made in the same way and, if the port of reception of the frame coming from A is different from that associated to the path to A already existing, an alternative path is registered associating said port to the tuple formed by the source MAC address A, destination MAC address C, TCP transport port used by A and TCP transport port used by C {A, C, pA, pC} (abbreviated, AC tuple), an expiration identifier and moment of arrival of the plot. It is checked in each bridge if the destination MAC address of the frame encapsulated within the PathRequest frame is that of a terminal connected directly to the bridge crossed. Duplicated PathRequest frames arriving later for other ports are discarded because their source MAC address is not associated with the receiving port. Finally, only a PathRequest packet containing the SYN segment will arrive at the frontier bridge, directly connected to terminal C. The bridge will de-encapsulate the frame and forward it to terminal C, also associating an expiration identifier with the MAC and TCP origin and at the same time arrival of the plot. Terminal C will answer with a SYN + ACK segment confirming the establishment of the TCP connection. The destination boundary bridge (connected to C) encapsulates the SYN + ACK segment in a PathReply packet with MAC source C address, destination MAC address A and protocol identifier (Ethertype) assigned to the TCP-Path protocol, and forwards it in unicast by the port associated with the AC tuple, previously associated with said port when the PathRequest package was received. In turn, 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 tuple {C, A, pC, pA} (abbreviated, tuple CA), associating them with the previously created expiration identifier of the AC tuple, updating the arrival time, confirming and renewing the validity of the association .. In each bridge crossed the port is also associated reception to said CA tuple and it is forwarded by the port associated with the tuple AC, associated with the connection from C to terminal A, confirming and renewing the path in the direction towards A, associating them with the previously created expiration identifier of the tuple AC , updating the arrival time, confirming and renewing the validity of the association.
    Nº application28 / 11 / 2014F.OEPM28 / 11 / 2014F.Efectiva
    In order to increase the diversity of paths, when a bridge receives the PathRequest packet by the same port that it already had associated with the generic path ARP-Path for A, said bridge can associate the transport path to a different port as long as it receives the Duplicated PathRequest with a reduced and limited time difference with respect to the port that first receives it.
    The PathReply packet finally arrives in unicast to the destination boundary bridge, to which the destination terminal A is directly connected. The bridge de-encapsulates the frame containing the original segment SYN + ACK 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, by the path associated with that pair of MAC addresses and the pair of TCP ports of the connection. In the same way, the successive data segments sent from the AaIC terminal 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 the already existing ones, previously established by means of any of the Known protocols: ARP-Path or Flow-Path. The path from A to C can exist previously or not, both as an ARP-Path path associated only with the MAC A address or as a bidirectional Flow-Path associated with the A and C directions, the difference being that TCP-Path only establishes a new path associated with the connection if there is no previous path between A and C or, if existing, it is different from the one being created (that is, the port associated with the tuple is different from the existing one). As a consequence, the TCP-Path transport path established between A and C can partially, completely, or 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 paths as transport connections exist at any time.
    Nº application28 / 11 / 2014F.OEPM28 / 11 / 2014F.Efectiva
    Established roads are refreshed, prolonging their validity, automatically upon receiving frames of the flow associated with the path. This refresh can be forward and optionally bidirectional, as configured. In the forward refresh, the received frames renew the association of the destination MAC of the frame forwarded to the output port. In the bidirectional also renew the association of the source MAC address to the input port.
    Erasing roads
    If the paths are not used by the frames associated with them (with tuples of transport ports and MAC addresses in the forwarding table) for a time longer than the bridge persistence timer (cache), they expire automatically, erasing from memory the ports associated with the road.
    Likewise, when an established path is interrupted, due to the failure of a link or bridge, the addresses learned in the port are immediately erased, associated in the forwarding table to the port connected to the link or bridge in failure.
    Similar to the establishment, TCP-Paths can be explicitly deleted by terminals when they send an FIN segment in each direction to close the TCP connection. A terminal will send an 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 an FIN segment answered with an ACK segment is sent to the remote end to close the connection in the remote-near sense. Alternatively, the receiving end can answer with a combined segment FIN + ACK (the so-called three-way TCP closure), which will be answered with an ACK segment to confirm the closure in the remote-near sense. This ACK segment is not encapsulated.
    Nº application28 / 11 / 2014F.OEPM28 / 11 / 2014F.Efectiva
    More specifically, when the frontier 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 the destination MAC address and port association from the table for forwarding purposes. transport destination to the bridge port and the content of the associated expiration timer, without modifying other associations of said MAC address to other bridge ports; it also checks whether the destination MAC address of the frame encapsulated within the PathFlush frame corresponds to a terminal directly connected to the bridge receiving the frame and, if so, de-encapsulates the frame and forwards it to the destination terminal by the bridge port associated with it. 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 by the port associated with the "fields of the TCP connection" just deleted. Frame forwarding
    When a data frame is received in a TCP-Path bridge, the TCP connection fields are consulted: source and destination MAC addresses, origin and destination transport ports, and it is verified if there is a port associated with that connection as a destination; if it exists, the frame is forwarded by the port associated with said connection to the destination terminal and the timer associated with 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 to the destination MAC address of the frame or to the destination MAC address pair and MAC origin of the frame; if it exists, the frame is forwarded by said port; in other cases, the road repair process will be initiated by sending a multicast frame. That is, when there is no specific path TCPPath, it can be used by the received frames another specific path TCP-Path destined to the same destination MAC address or a generic path associated only to said MAC address (created by means of ARP-Path or Flow -Path). 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 the frames with that destination.
    Nº application28 / 11 / 2014F.OEPM28 / 11 / 2014F.Efectiva
    If there is no generic path, the generic path is repaired with the usual repair of ARP-Path or Flow-Path described in [Elisa Rojas, Guillermo Ibanez, Diego Rivera, Juan A. Carral, "Flow-Path: An AIIPath f1ow- based protocol ", Proceedings of the 2012 IEEE 37th Conference on Local Computer Networks (October 2012) pp. 244-247].
    Network bridge for TCP-path paths
    The path establishment, path clearing and frame forwarding mechanisms described can be implemented in a network bridge that has the corresponding tables to associate the ports to tuples formed by MAC address pairs and origin and destination transport ports.
    SHORT DESCRIPTION OF THE DRAWINGS
    Figure 1 shows the flow diagram of the protocol to establish 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 with the MAC addresses of both, through the exchange of the ARP Request and ARP Reply messages.
    Figure 3 shows the search for a TCP-Path after receipt of a TCP transport segment with SYN activated (Path Request).
    Figure 4 shows the path confirmation in the opposite direction with the TCP transport segment with SYN and ACK activated (PathReply).
    Figure 5 shows the segment ACK (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.
    Nº application28 / 11 / 2014F.OEPM28 / 11 / 2014F.Efectiva
    Figure 6 shows a case in which no additional TCP-Path path is created in the network because the pre-existing ARP-Path generic path is the fastest.
    Figure 7 shows the case in which a new TCP-Path path is created totally disjoint from the pre-existing ARP-Path generic path.
    Figures 8 and 9 show the clearing of paths with segments FIN (PathFlush).
    Figure 10 shows the network after the TCP-Path paths have been deleted.
    Figure 11 shows the learning that takes place in the routing tables of a bridge that has the TCP-Path functionality activated. MODE OF REALIZATION
    An embodiment of the invention is described. Figure 1 shows the operating logic of the bridge to establish the roads in the form of a flow diagram. When receiving a frame, the first thing that is looked at is whether it is a transport segment with the SYN or FI N f1ags activated, encapsulating in the corresponding PathRequest (SYN), PathReply (SYN + ACK) or PathFlush (FIN) package to be A) Yes. If it is not a segment of the previous type, it is analyzed if it is a special AII-Path (PathRequest, PathReply or PathFlush), in which case the path is learned or cleared following the TCP-Path logic. Finally, if it is not one of the above cases, the logic of operation of the ARP-Path and generic Flow-Path protocols is used.
    Figure 2 shows an example network to examine the mechanism of learning, erasing and repairing TCP-Path. Terminals A, B and C are respectively connected to the frontier bridges 1, 7 and 3. These bridges have established paths between them through the ARP-Path protocol, based on the learning of the MAC address origin of the ARP Request and ARP Reply packets issued by said terminals when they begin to communicate. It is indicated by a circle surrounding a letter next to each bridge, the port to which the address of said terminal is associated (address learned). For example, the path to A is established in certain ports of bridges 3, 2 and 1, while the path to C has been created over bridges 1, 6, 5 and 3. This shows the direction of the frames in if there is communication traffic between terminals A and e. The expiration timers of each tuple associated with the port are activated and valid when the time limit for the deletion has not elapsed.
    Nº application28 / 11 / 2014F.OEPM28 / 11 / 2014F.Efectiva
    Figure 3 shows the learning performed when receiving the first transport segment with the active SYN flag from terminal A. This segment has as origin A and as destination e.:. In the frontier bridge 1 it is encapsulated in a PathRequest frame that is spread throughout the network. Thus, all bridges receive a copy of the frame and point tuple Ae (way 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. In this case, only bridges 1, 2 and 3 had a previous path to A, so bridge 3 learns the tuple Ae 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 entrance of A, which is through the port through which it is connected to bridge 1.
    Next, Figure 4 shows the behavior when receiving a transport segment with the active SYN + AeK flags. In this case, a segment of this type is received from the terminal e (in response to the previous SYN that was directed from A to C) and it is the frontier bridge 3 that is responsible for encapsulating it in a PathReply frame. This frame is forwarded in unicast by the port associated with the tuple previously learned Ae, that is, it is routed through bridges 3, 4 and 1. On bridges 4 and 1 the tuple CA (road to e) is learned because there is no previous generic entry associated with it and therefore it can not match in port with any of them.
    Finally in figure 5 we can see the last part of the TCP connection start, which is a transport segment with the active AeK flag. This last segment with origin A and destination e does not have the active SYN flag, so the frontier bridge 1 does not encapsulate it and treat it as any other traffic frame of said newly initiated connection, routing it through the ports associated with the tuple CA and passing by bridges 1, 4 and 3, until you reach e. Note that in bridge 3 there is no entry associated with the tuple CA because it is the frontier bridge of e, so the generic entry e is used to route, learned in the first step by the ARP-Path protocol.
    Nº application28 / 11 / 2014F.OEPM28 / 11 / 2014F.Efectiva
    Figures 6 and 7 show two extreme cases of possible paths created by TCP-Path. In figure 6 the paths A and C created by ARP-Path coincide in the direction, crossing both the bridges 1, 2 and 3, and also the AC and CA paths created by TCPPath as well. In practice what would happen in this case is that the AC and CA tuples would not be annotated, as they coincide with the ports of the existing generic A and C entries, so there would be no alternative way, a situation that can occur in case of that the road 1, 2 and 3 is still the fastest road and is not very used yet. In the case of figure 7, the opposite extreme is shown, the one in which the generic roads of ARPPath A and C do not share bridges (except for bridges border 1 and 3), and also the TCP-Path between A and C crosses also different bridges (going through bridge 4). The latter case could occur when all roads are equally fast and would be distributed equally throughout the network. Note that the TCP-Path paths are symmetric, so the AC and CA tuples always share bridges in one direction or another (in this case 1, 4 and 3), while the generic ARP-Path paths do not have to be bridges. .
    Figures 8, 9 and 10 show the deletion of the AC and AC inputs using the AIIPath frames of the PathFlush type. These frames are created by encapsulating transport segments that contain the active FIN flag (either FIN or FIN + ACK). In figure 8, a segment FIN of terminal A is sent to C, deleting the tuple CA, while in figure 9 segment FIN goes from terminal C to A by deleting the remaining tuple, the AC. Finally figure 10 shows how the network would be after the TCP-Path paths were erased in the previous figures by the PathFlush frame.
    In figure 11 we can see what each circle means (A, C, AC or CA), that is, each of the table entries of a bridge that works according to the TCPPath specification. Figure 11.a shows the inputs of an ARP-Path bridge after building a path between hosts A YC. These entries consist of a search key (in this case the MAC address), an associated port, a timer or timer and a 'Locked' or 'Learned' state. When a new PathRequest frame associated with a SYN message of the TCP protocol arrives and with origin A and destination C, if the first copy arrives through a different port than the one already associated, a TCPPath type of learning occurs and its key will be written into the table as shown in 11.b). That is, the entry with key A will be the generic entry to reach destination A, while AC- * will be the concrete key of the TCP-Path path with destination A, but will only be used when the
    Nº application28 / 11 / 2014F.OEPM28 / 11 / 2014F.Efectiva
    source is C and another set of parameters (specified with *) are met as they can be
    be port numbers, etc. With the response of C to A, SYN + ACK encapsulated in
    a PathReply message, if it arrives through a port other than the one already associated with C, it will be
    an analogous learning (figure 11.c).
    s
    Therefore, in addition to the base path, additional paths with more keys will be created
    concrete, while the other entries in the table will be analogous.
    On the other hand, when a data frame with destination A arrives, two data will now be made
    10 searches, one specific to a key and another generic if the first one was not found. But to his
    Once, if the specific path did exist and was deleted by a link failure, this guarantees that
    the use of the base, or generic, path for routing will still be possible.
    Nº application28 / 11 / 2014F.OEPM28 / 11 / 2014F.Efectiva
    权利要求:
    Claims (5)
    [1]
    1. Procedure for establishing trails, forwarding frames and deleting data frames trails that includes:
    receiving, through a port of a network bridge where said port has an assigned port identity, a frame comprising a source MAC address and a destination broadcast address; associate, in a table, for the purposes of forwarding the bridge, the source MAC address of the received frame to the identity of the port that first received the frame in said bridge, to an expiration indicator of said association and to the moment of arrival of the plot; block this association for a certain time, preventing the association of said source address to another port of the bridge; discard the frames received by ports other than the one associated with the source address of the frame during the time that association is blocked; forward the unicast frames received by the bridge port that is associated with the frame's destination MAC address delete, in the table, for forwarding purposes, the address associations that a bridge port has when it detects a link drop on that port or the address validity timer expires; request path repair using a multicast frame when a frame with a unicast destination reaches a bridge that does not have an associated port in the table, for forwarding purposes for that MAC address.
    characterized by -The existence of an establishment stage in which, upon receiving in a port of a network bridge with an identity assigned to each of its ports a frame that carries a TCP segment that has the connection request indicator SYN on and the ACK indicator off,
    create a new connection, assigning it a unique internal identifier for the TCP-Path connection and associate this identifier with the exact combination of the following fields contained in the frame that carries the TCP segment: source MAC address, destination MAC address of the frame that transports the TCP segment and source and destination TCP transport ports of the TCP segment header, hereinafter "TCP connection fields"; associate, in a table, for forwarding purposes, the source MAC addresses and source TCP port, as well as the identifier of the TCP-Path connection, to the identity of the bridge port that first received the frame, to an expiration indicator of the plot and the time of arrival of the plot; encapsulate the frame containing the TCP segment within a special PathRequest multicast frame with destination address the multicast group address shared by "all TCP-Path bridges" and with source address the MAC address of the bridge that encapsulates the frame.
    - The existence of a confirmation and renewal stage, in which, upon receiving a frame in a network bridge containing a TCP segment with the SVN connection request indicator activated and the ACK indicator activated (SVNACK segment),
    confirm and renew the connection, in the table, for forwarding purposes, renewing
    during a certain time the validity of the association, created
    previously on the bridge when the PathRequest packet is received, from the
    "TCP connection fields" of the received frame mentioned
    above (source and destination MAC addresses and port identities
    TCP source and TCP destination) with the connection identifier, with the identity
    from the bridge port that first received the frame, with a
    expiration of the frame and with the moment of arrival of the frame;
    encapsulate the frame containing the TCP SVN-ACK segment within a
    special PathReply unicast frame, with source MAC address that of the
    bridge that encapsulates it and destination the MAC address of the bridge that was
    associated in the bridge to said connection after receiving the PathRequest
    for that connection.
    - The existence of an erasure stage, in which, upon receiving in a bridge of
    network a frame containing a TCP segment with the request flag for
    connection FIN activated; encapsulate the TCP segment within a special PathFlush unicast frame directed to the destination border bridge through the port associated with the destination terminal address, with the protocol type field, Ethertype, with the value assigned to "TCP-Path"; delete, from the table, for forwarding purposes, the association of the "TCP connection fields" associated with the destination and the contents of the associated timers.
    - When receiving a frame not included in the previous cases in a network bridge:
    verify its membership in an existing connection on the bridge by consulting the TCP connection fields: source and destination MAC addresses, source and destination transport ports; if so: forward the frame through the port associated with said connection to the destination terminal and renew the timer associated with the destination MAC address; otherwise: if there is a specific TCP-Path associated with the destination MAC address but linked to a bridge port other than the port in failure, forward said frame through said output port. in all other cases: check if there is any bridge port associated with the frame destination MAC address; if so: forward the frame through that port; otherwise: send a multicast frame to start the path repair mechanism.
    [2]
    Method according to claim 1, characterized by, in the establishment stage, upon receiving in a network bridge a PathRequest multicast frame addressed to the multicast group address "all TCP-Path bridges" and protocol type, field in the frame usually known as Ethertype, with the value of "TCP-Path";
    associate, in a table, for forwarding purposes, the source and destination MAC addresses and source and destination transport port identities of the original frame encapsulated within the received frame ("TCP connection fields") to the port identity from the bridge that first received the frame, to a frame expiration indicator and the instant of frame arrival; associating, in a table, for forwarding purposes, the source MAC address of the PathRequest frame to the identity of the bridge port that first received the frame; checking if the destination MAC address of the encapsulated frame within the PathRequest frame corresponds to a terminal directly connected to the bridge that receives the frame; if so: de-encapsulate the frame and forward it to the destination terminal through the bridge port associated with said terminal; in all other cases: forward the frame through all ports except the port where it was received first; queue it in the exit queues of the bridge ports according to previously configured priority criteria.
    [3]
    3. Method according to claim 1, characterized by, in the confirmation and renewal stage, when a PathReply unicast frame is received in a network bridge with destination a bridge MAC address and with the type of protocol, field in the frame usually known as Ethertype, containing the value associated with "TCP-Path";
    associate, in a table, for forwarding purposes, the source and destination MAC addresses and source and destination transport port identities of the original frame encapsulated within the received frame ("TCP connection fields"), to the identity of the port of the bridge that first received the frame, at a frame expiration indicator and at the time of arrival of the frame; check if the destination MAC address of the outer encapsulation of the frame corresponds to the bridge that is processing the frame; if so: de-encapsulate the frame and forward it to the destination terminal through the bridge port associated with said terminal; in the other cases: forward the frame through the port associated with the source and destination MAC addresses and source and destination transport ports of the TCP-Path connection and renew the association of the "fields of the TCP connection" to the forwarding port.
    [4]
    Four. Method according to claim 1, characterized by, in the erasing step, when
    receive on a network bridge a PathFlush unicast frame with the type field
    protocol, Ethertype, with the value assigned to the "TCP-Path" protocol;
    5 delete, from the table, for forwarding purposes, the association of the "connection fields
    TCP "associated with the destination and the contents of the associated timers, without
    modify other associations of these MAC addresses to bridge ports that do not
    are linked to the indicated origin and destination ports;
    check if the destination MAC address of the encapsulated frame within the frame
    10 PathFlush corresponds to a terminal connected directly to the bridge that receives
    the plot;
    if so: de-encapsulate the frame and forward it to the destination terminal through the
    port of the bridge associated with said terminal;
    in otherscases:resend theplotPathFlush inunicast by port
    fifteen associated with the "TCp connection fields · just deleted.
    [5]
    5. Bridgeofnetcharacterizedwhyhasofthemediaofprosecution
    appropriate to implement the procedure of claims 1 to 4.
    twenty 6.Switched telecommunications network characterized by comprising at least one
    network bridge defined according to claim 5.
    类似技术:
    公开号 | 公开日 | 专利标题
    ES2540595A1|2015-07-10|Procedure for establishing and deleting roads and forwarding of trams for transportation connections and network bridge |
    ES2268165T3|2007-03-16|OPTIMATION OF LOCAL AGENT TO MANIPULATE MOBILE IP AND STATIC MPLS |.
    ES2361545B1|2012-05-08|PROCEDURE OF FURNITURE OF DATA SECTIONS AND NETWORK BRIDGE.
    ES2614614T3|2017-06-01|Load matching in layer-2 domains
    Sajassi et al.2015|Bgp mpls-based ethernet vpn
    JP6009553B2|2016-10-19|A centralized system for routing Ethernet packets over Internet protocol networks
    US6701361B1|2004-03-02|Enhanced mobility and address resolution in a wireless premises based network
    US9060331B2|2015-06-16|Home virtual local area network identification for roaming mobile clients
    KR101146139B1|2012-05-16|Method for providing mobility of mobile node in packet transport network, packet transport network system and Gateway switch
    CN106341327A|2017-01-18|BIER | message transmission method and system
    US20100202344A1|2010-08-12|Mobile communication control method, data communication device, mobile base station, and mobile terminal
    ES2428547T3|2013-11-08|Management of connectivity failure in the domain of the Supplier Backbone Network Traffic Engineering |
    JP2009530907A5|2012-05-10|
    ES2437070T3|2014-01-08|Bridging media access control in a mesh network
    US20180034722A1|2018-02-01|Distributed HSRP Gateway in VxLAN Flood and Learn Environment with Faster Convergence
    EP3035592B1|2018-11-07|Enhanced protocol independent multicast source registration over a reliable transport
    US6868086B1|2005-03-15|Data packet routing
    JP3838363B2|2006-10-25|Mobile network and communication method thereof
    JP2010517344A|2010-05-20|Data packet header reduction method by route optimization procedure
    Ibáñez et al.2010|Fast Path Ethernet Switching: On-demand, efficient transparent bridges for data center and campus networks
    ES2638292B2|2018-04-17|Procedure for establishing and deleting multiple disjoint paths, frame forwarding and network bridge
    JP2005006264A|2005-01-06|Mobile ip network system
    JP2005323316A|2005-11-17|Gateway apparatus
    US10523466B1|2019-12-31|Aliasing in an active-active multi-homed PBB-EVPN network
    WO2017008514A1|2017-01-19|Clos network load balancing method and device
    同族专利:
    公开号 | 公开日
    WO2015086877A1|2015-06-18|
    US20160308727A1|2016-10-20|
    ES2540595B2|2016-02-02|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    WO2017158226A1|2016-03-18|2017-09-21|Universidad de Alcalá de Henares|Method for establishing and deleting multiple frame-forwarding disjoint paths, and network bridge|US7430164B2|1998-05-04|2008-09-30|Hewlett-Packard Development Company, L.P.|Path recovery on failure in load balancing switch protocols|
    US7760668B1|2006-06-20|2010-07-20|Force 10 Networks, Inc.|Self-reconfiguring spanning tree|EP3092751A4|2014-01-06|2017-10-18|Samsung Electronics Co., Ltd.|Method and apparatus for relaying packet transmission and updating network address information in communication system|
    US10069646B2|2015-12-02|2018-09-04|Nicira, Inc.|Distribution of tunnel endpoint mapping information|
    US10164885B2|2015-12-02|2018-12-25|Nicira, Inc.|Load balancing over multiple tunnel endpoints|
    US9912616B2|2015-12-02|2018-03-06|Nicira, Inc.|Grouping tunnel endpoints of a bridge cluster|
    US10719341B2|2015-12-02|2020-07-21|Nicira, Inc.|Learning of tunnel endpoint selections|
    US20170195218A1|2015-12-30|2017-07-06|Qualcomm Incorporated|Routing in a hybrid network|
    CN109462591B|2018-11-19|2020-07-03|中国科学院信息工程研究所|Data transmission method, receiving method, device and system|
    KR102015735B1|2018-12-28|2019-08-28|주식회사 모파스|Communication method and apparatus of peer for peer to peer handshaking control|
    CN110572438A|2019-08-14|2019-12-13|北京天融信网络安全技术有限公司|network connection establishing method, device, network equipment and storage medium|
    法律状态:
    2016-02-02| FG2A| Definitive protection|Ref document number: 2540595 Country of ref document: ES Kind code of ref document: B2 Effective date: 20160202 |
    优先权:
    申请号 | 申请日 | 专利标题
    ES201301133A|ES2540595B2|2013-12-10|2013-12-10|PROCEDURE FOR ESTABLISHING AND DELETING ROADS AND FORWARDING SECTIONS FOR TRANSPORT CONNECTIONS AND NETWORK BRIDGES|ES201301133A| ES2540595B2|2013-12-10|2013-12-10|PROCEDURE FOR ESTABLISHING AND DELETING ROADS AND FORWARDING SECTIONS FOR TRANSPORT CONNECTIONS AND NETWORK BRIDGES|
    PCT/ES2014/070905| WO2015086877A1|2013-12-10|2014-12-10|Method for establishing and clearing paths and forwarding frames for transport connections, and network bridge|
    US15/103,049| US20160308727A1|2013-12-10|2014-12-10|Method for establishing and clearing paths and forwarding frames for transport connections, and network bridge|
    [返回顶部]