WO2015086877A1

WO2015086877A1 - Method for establishing and clearing paths and forwarding frames for transport connections, and network bridge

Info

Publication number: WO2015086877A1
Application number: PCT/ES2014/070905
Authority: WO
Inventors: Elisa ROJAS SÁNCHEZ; Guillermo Ibáñez Fernández; Isaías MARTÍNEZ YELMO; Arturo AZCORRA SALOÑA
Original assignee: Universidad De Alcalá; Institute Imdea Networks
Priority date: 2013-12-10
Filing date: 2014-12-10
Publication date: 2015-06-18
Also published as: ES2540595B2; ES2540595A1; US20160308727A1

Abstract

The present invention describes mechanisms which examine a network of transparent bridges for establishing a specific path for each new TCP connection established between two terminals. The new path is initiated by the edge bridge connected to the source terminal upon receiving a TCP segment of the type SYN for establishing a TCP connection, with said segment being encapsulated inside a special path request packet which is transmitted by all the network links to the destination edge bridge. The path is confirmed by the edge bridge of the destination terminal by means of a unicast acceptance packet which transports the response SYN+ACK segment from the terminal B in an encapsulated manner, confirming both the TCP connection between terminals and the path chosen between A and B. The path is automatically cleared when a particular time passes without the connection being used or when the terminal sends a FIN segment in both directions of the connection.

Description

PROCEDURE FOR ESTABLISHING AND DELETING ROADS AND FORWARDING SECTIONS FOR TRANSPORT CONNECTIONS AND NETWORK BRIDGES

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

These paths can also be established in the manner known as Flow-Path by sending an ARP Request (of which MAC source and IP origin and destination are registered in the origin border bridge) and an ARP Reply 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 AHPath 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 origin of unicast frames to an input port and verify when they receive a unicast or multicast frame whether or not the port is associated with said frame [Minkenberg et al. US201 1 / 0032825A1. Multipath discovery in switched Ethernet networks. Date of publication, February 10, 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]. These protocols only learn MAC addresses, so they cannot distribute traffic either by flows or by user applications or processes within the same machine.

The previous protocols have, 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 cannot distribute the load of the flows between two terminals on different roads with a finer granularity diversifying the roads according to these flows.

Therefore, 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.

DESCRIPTION OF THE INVENTION

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.

Road establishment

When, as described in the state of the art above, 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. In each network bridge crossed the association is made in the same way and, if the reception port of the frame from A is different from the one associated with the path to existing A, an alternative path is registered associating said port with the formed tupia 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 dump), to an expiration identifier and to instant of arrival of the plot. It is checked on each bridge if the destination MAC address of the frame encapsulated within the PathRequest frame is that of a terminal directly connected to the bridge crossed. Duplicate PathRequest frames that arrive later through 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 border bridge, directly connected to terminal C. The bridge will uncapsulate the frame and forward it to terminal C, also associating an expiration identifier with the source MAC and TCP addresses and at the instant of plot arrival Terminal C will reply with a SYN + ACK segment confirming the connection establishment TCP The destination border bridge (connected to C) encapsulates the SYN + ACK segment in a PathReply packet with MAC address source C, 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 bus, previously associated with that 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 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. 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 ..

In order to increase the diversity of roads, 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. In the same way, 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). As a consequence, 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.

The established paths are refreshed, prolonging their validity, automatically upon receiving frames of the flow associated with the path. This soda can be forward and optionally bidirectional, as configured. In the forward refresh, the frames received renew the association of the destination MAC of the frame forwarded to the output port. In the bidirectional they also renew the association of the source MAC address to the input port.

Road erase

If 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. Likewise, when an established road is interrupted, due to a link or bridge failure, the immediate erasure of the addresses learned in the port, associated in the forwarding table to the port connected to the failed link or bridge, occurs.

Similar to the establishment, 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. Alternatively, 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.

More specifically, 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".

Frame forwarding

When a data frame is received on a TCP-Path bridge, 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. That is, 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.

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 AHPath flow- 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 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.

BRIEF DESCRIPTION OF THE DRAWINGS

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.

MODE OF REALIZATION

An embodiment of the invention is described. Figure 1 shows the operating logic of the bridge to establish the paths in the form of a flow chart. When receiving a frame, 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.

An example network to examine the learning, deletion and repair mechanism of TCP-Path is shown in Figure 2. 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). For example, 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. 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. In this case, only 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.

Next, figure 4 shows the behavior when receiving a transport segment with the active SYN + ACK flags. In this case, 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. In 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. Finally in Figure 5 we can see the last part of the TCP connection start, which is a transport segment with the ACK flag active. This last segment with origin A and destination C does not have the active SYN flag, so border bridge 1 does not encapsulate it and treats it like any other traffic frame of said newly initiated connection, routing it through the ports associated to the tupia CA and going through bridges 1, 4 and 3, until you reach C. Note that in bridge 3 there is no entrance associated to the CA tupia because it is the border bridge of C, so the generic entry C is used to route, learned in the first step by the protocol ARP-Path. 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 direction, crossing both bridges 1, 2 and 3, and also the AC and CA paths created by TCP-Path as well. In practice, what would happen in this case is that the AC and CA tupias would not be noted, coinciding with the ports of the existing generic A and C entrances, so there would be no alternative route, a situation that may occur in case of that the path 1, 2 and 3 remains the fastest path and is not yet widely used. In the case of figure 7, the opposite end is shown, the one in which the generic paths of ARP-Path A and C do not share bridges (except border bridges 1 and 3), and also the TCP-Path path between A and C also crosses different bridges (through bridge 4). This last case could occur when all roads are equally fast and would be distributed equally throughout the network. Note that TCP-Path paths are symmetric, so AC and CA tupias always share bridges in both directions (in this case 1, 4 and 3), while generic ARP-Path paths do not have to be. .

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). In Figure 8, 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. Finally, figure 10 shows how the network would look after deleting the TCP-Path paths in the previous figures using the PathFlush frame.

In Figure 1 1 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 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. When a new plot arrives PathRequest associated with a SYN message of the TCP protocol and with origin A and destination C, if the first copy arrives through a port other than the one already associated, a TCP-Path type learning takes place and its key will be noted inside the table as and as 1 1 .b) shows. That is, the entry with key A will be the generic entry to reach destination A, while AC- ^* will be the specific key of the TCP-Path path to destination A, but it will only be used when the origin is C and they are met another set of parameters (specified with ^* ) such as port numbers, etc. With the response from C to A, SYN + ACK encapsulated in a PathReply message, if it arrives through a different port than the one already associated with C, an analogous learning will be carried out (Figure 1 1.c).

Therefore, in addition to the base path, additional paths will be created with more specific keys, while the rest of the entries in the table will be similar.

On the other hand, when a data frame with destination A arrives, two searches will now be performed, one specific and one generic if the first one was not found. But in turn, if the specific path did exist and was deleted due to a link failure, this guarantees that the use of the base or generic path for routing will still be possible.

Claims

CLAIMS Procedure for establishing roads, forwarding frames and deleting roads from data frames, comprising:

- 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 purpose of forwarding the bridge, the origin 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 instant of arrival of the plot;

- block this association for a certain time, preventing the association of said origin address to another port of the bridge;

- discard the frames received by ports other than the one associated with the originating address of the frame during the time in which that association is blocked;

- resend the unicast frames received by the bridge port that is associated with the destination MAC address of the frame

- delete, in the table, for the purposes of forwarding, the associations of addresses that a port of a bridge has when it detects the drop of a link in said port or the validity timer of the address expires;

- request the repair of the path by means of a multicast frame when a frame with a unicast destination reaches a bridge that has no associated port in the table, for the purpose of forwarding for said MAC address. characterized by

- The existence of an establishment stage in which, upon receiving at 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 SYN connection request indicator activated and the ACK indicator off,

- create a new connection, assigning it a unique internal TCP-Path connection identifier and associate said 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 transporting the TCP segment and TCP transport ports origin and destination of the header of the TCP segment, hereinafter "fields of the TCP connection";

- associate, in a table, for the purpose of forwarding, 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 instant of arrival of the plot;

- encapsulate the frame containing the TCP segment within a special PathRequest multicast frame with the destination address the multicast group address shared by "all TCP-Path bridges" and with the source address the MAC address of the bridge encapsulating the frame.

The existence of a confirmation and renewal stage, in which, upon receiving on a network bridge a frame containing a TCP segment with the SYN connection request indicator activated and the ACK indicator activated (SYN-ACK segment),

- confirm and renew the connection, in the table, for the purpose of forwarding, renewing for a certain period the validity of the association, previously created on the bridge when the PathRequest package is received, from the "TCP connection fields" of the frame received previously mentioned (source and destination MAC addresses and source TCP and destination TCP port identities) with the connection identifier, with the identity of the bridge port that first received the frame, with a frame expiration indicator and with the instant of arrival of the plot;

- encapsulate the frame containing the TCP segment SYN-ACK within a special PathReply unicast frame, with the MAC address originating from the bridge that encapsulates it and destination the MAC address of the bridge that was associated in the bridge to said connection after receipt of the PathRequest for that connection. The existence of an erase stage, in which, upon receiving on a network bridge a frame containing a TCP segment with the FIN connection request indicator activated;

- encapsulate the TCP segment within a special PathFlush unicast frame directed to the destination border bridge by 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 the purpose of forwarding, the association of the "fields of the

TCP connection "associated to the destination and the contents of the associated timers.

-When receiving in a network bridge a frame not included in the previous cases:

- verify your 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 yes: forward the frame through the port associated with that connection to the destination terminal and renew the timer associated with the destination MAC address;

- in all other cases: if there is a specific TCP-Path path associated with the destination MAC address but linked to a port on the bridge other than the failed port, forward said frame through said output port.

- in all other cases: check if there is any bridge port associated with the destination MAC address of the frame;

- if yes: forward the frame through that port;

- in all other cases: send a multicast frame to start the road repair mechanism.

2. Method according to claim 1, characterized in that, at the establishment stage, upon receiving a PathRequest multicast frame addressed to the multicast group address "all TCP-Path bridges" and protocol type, on a network bridge, 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 identities of the source and destination transport ports 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, to an indicator of expiration of the frame and at the moment of arrival of the frame;

- associate, 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;

- check 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 yes: uncapsulate the frame and forward it to the destination terminal

by the bridge port associated with said terminal;

- in all other cases: forward the frame through all ports except the port where it was first received;

- glue it on the output queues of the bridge ports according to previously configured priority criteria.

Method, according to claim 1, characterized in that, at the confirmation and renewal stage, upon receiving a PathReply unicast frame on a network bridge with destination a bridge MAC address and with the protocol type, 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 identities of the source and destination transport ports of the original frame encapsulated within the received frame ("TCP connection fields"), to the identity from the port of the bridge that first received the frame, to an indicator of expiration of the frame and at the moment 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 yes: uncapsulate the frame and forward it to the destination terminal through the bridge port associated with that terminal; - in all other cases: forward the frame through the port associated to the source and destination MAC addresses and source and destination transport ports of the TCP-Path connection and renew the association of the "TCP connection fields" to the forwarding port .

Method according to claim 1, characterized in that, at the erase stage, upon receiving a PathFlush unicast frame with the protocol type field, Ethertype, with the value assigned to the "TCP-Path" protocol on a network bridge; delete, from the table, for the purposes of forwarding, the association of the "TCP connection fields" associated with the destination and the contents of the associated timers, without modifying other associations of said MAC addresses to ports of the bridge that are not linked to the indicated source and destination ports;

checking 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;

if so: uncapsulate the frame and forward it to the destination terminal through the bridge port associated with that terminal;

in all other cases: resend the PathFlush frame in unidifusion through the port associated with the "TCP connection fields" just deleted.

Network bridge characterized in that it has the appropriate processing means to implement the procedure of claims 1 to 4.

Switched telecommunications network characterized by comprising at least one network bridge defined according to claim 5.