EP2002608B1 - Loop prevention in bridge networks - Google Patents
Loop prevention in bridge networks Download PDFInfo
- Publication number
- EP2002608B1 EP2002608B1 EP07759369.7A EP07759369A EP2002608B1 EP 2002608 B1 EP2002608 B1 EP 2002608B1 EP 07759369 A EP07759369 A EP 07759369A EP 2002608 B1 EP2002608 B1 EP 2002608B1
- Authority
- EP
- European Patent Office
- Prior art keywords
- state
- proposed
- agree
- condition
- agreed
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Not-in-force
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
- H04L12/462—LAN interconnection over a bridge based backbone
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/48—Routing tree calculation
Definitions
- the present invention is related to a bridge and method for ensuring the proper propagation of a cut within a bridged network (e.g., Ethernet-based bridged network).
- a bridged network e.g., Ethernet-based bridged network
- a bridge e.g., IEEE 802.1 bridge
- a method are described herein which ensure the proper propagation of a "cut" within a bridged network (e.g., Ethernet-based bridged network).
- the bridge has a port role transitions (PRT) state machine which uses a first condition represented as (proposed && !agree) to transit to an X_PROPOSED state and a second condition represented as (!proposed && allSynced && !agree)
- the first condition and the second condition are both defined such that the X_PROPOSED state is always entered before the X_AGREED state which ensures the proper propagation of a "cut" within the bridged network.
- IEEE P802.1Q-2004 entitled “IEEE Standard for virtual Bridged Local Area Networks: Revision”, IEEE, 21 September 2004, at pages 143-222 is directed to the Multiple Spanning Tree Protocol (MSTP) and to a port role transitions state machine.
- MSTP Multiple Spanning Tree Protocol
- the present solution basically ensures the proper propagation of a "cut" within a bridged network (e.g., Ethernet-based bridged network) where data loops are prevented by the operation of a spanning tree protocol, such as the ones specified and standardized by the IEEE 802.1 Working Group.
- a spanning tree protocol such as the ones specified and standardized by the IEEE 802.1 Working Group.
- These spanning tree protocols include the Rapid Spanning Tree Protocol (RSTP, as specified and standardized in IEEE Std. 802.1D-2004), the Multiple Spanning Tree Protocol (MSTP, as specified and standardized in IEEE Std. 802.1Q-2005) as well as any other protocol built on and/or expanding the use and scope of the RSTP and/or the MSTP.
- RSTP Rapid Spanning Tree Protocol
- MSTP Multiple Spanning Tree Protocol
- FIGURES 1A-1E are diagrams which are used to help explain the propagation of the "cut” which is a mechanism that is initiated to temporarily prevent data from being communicated over parts of the bridged network 100 when, for example, a bridge 102 is added to an exemplary bridged network 100.
- the bridged network 100 is shown having six bridges 101a, 101b...101f which are interconnected to one another by six links 104a, 104b...104f.
- the bridged network 100 is loop-free because bridge 101d has a discarding port 103. Now, assume the new bridge 102 is added to the bridged network 100.
- bridges 101a and 102 set their respective downstream ports 105 and 106 to a discarding (blocking) state as shown in FIGURE 1B .
- bridges 101a and 102 implement the spanning tree algorithm and protocol to make sure they do not have any data loops above the propagation line labeled 108a. As can be seen, there are no data loops above the propagation line labeled 108a.
- the bridge 101a sets its downstream ports 107a and 107b to a discarding (blocking) state as shown in FIGURE 1C and then the "cut" is propagated to downstream bridges 101b and 101c.
- the bridges 101b and 101c then implement the spanning tree algorithm to make sure there are no data loops above the propagation line labeled 108b. As can be seen, there are no data-loops above the propagation line labeled 108b.
- bridges 101b and 101c set their downstream ports 109a/109b and 111a/111b to a discarding (blocking) state and then the "cut" is propagated to downstream bridges 101d, 101e and 101f which happen to be the leaves of the spanning tree as shown in FIGURE 1D .
- the bridges 101d, 101e and 101f then implement the spanning tree algorithm to make sure there are no data loops above the propagation line labeled 108c. As can be seen, there was a data loop and to address that the port 103 on bridge 101d was set to a discarding (blocking) state.
- FIGURE 1E shows the bridged network 100 including the new bridge 102 and the old bridges 101a, 101b...101f after the propagation of the "cut".
- the "cut” requires that some ports of a bridge transit to the discarding state, where they block data traffic, thus preventing the formation of data loops behind such ports. To ensure that data loops are not created in between this bridge and its downstream bridges, and between these downstream bridges and their downstream bridges, the "cut” is propagated on a spanning tree through the bridges until it reaches the leaves of the spanning tree. It should be appreciated that the "cut” would also be initiated if an old bridge was removed from the bridge network 100.
- the bridges 101a, 101b...101f and 102 need to have their respective port role transitions (PRT) state machines 114 enter and execute various states in a specific sequence.
- PRT port role transitions
- the existing RSTP and MSTP specifications do not explicitly require such a sequence and even expect that these states can be enterable and executable in any order which is problematical. This problem is discussed in detail below with respect to three different port role transitions which are implemented within the PRT state machine 114 as shown in FIGURES 2-4 (PRIOR ART).
- FIGURE 2 there is a diagram illustrating the relevant parts of the traditional root port role transitions 202 which are implemented within the PRT state machine 114 in accordance with the RSTP specified in IEEE Std 802.1D-2004.
- the traditional root port role transitions 202 have a ROOT_PORT state 204 with multiple transitions 206a, 206b...206g of which transitions 206a and 206b are relevant to the present discussion.
- the first transition 206a has a condition 208 shown as (proposed && !agree) which, if it has a boolean value of TRUE, enables the ROOT_PROPOSED state 210 to be entered.
- the second transition 206b has a condition 212 shown as (allsynced && !agree)
- (proposed && agree) which, if it has a boolean value of TRUE, enables the ROOT_AGREED state 214 to be entered.
- (proposed && agree) has a boolean value of FALSE then the ROOT_AGREED state 214 can not be entered.
- the conditions 208 and 212 have symbols which are defined in IEEE Std 802.1D-2004 as follows:
- the traditional root port role transitions 202 are not the only port role transitions implemented within the PRT state machine 114 which is relevant to this discussion.
- the PRT state machine 114 also implements the traditional alternate and backup port role transitions 302 which are shown in FIGURE 3 (PRIOR ART).
- the traditional alternate and backup port role transitions 302 have an ALTERNATE_PORT state 304 with multiple transitions 306a, 306b...306d of which transitions 306a and 306b are relevant to the present discussion.
- the first transition 306a has a condition 308 shown as (proposed && !agree) which, if it has a boolean value of TRUE, enables the ALTERNATE_PROPOSED state 310 to be entered.
- the second transition 306b has a condition 312 shown as (allSynced && !agree)
- (proposed && agree) which, if it has a boolean value of TRUE, enables the ALTERNATE_AGREED state 314 to be entered.
- the traditional alternate and backup port role transitions 302 shown are configured in accordance with the RSTP specified in IEEE Std 802.1D-2004. As can be seen, the alternate and backup port role transitions 302 have similar conditions 308 and 312 and states 310 and 314 as the ones associated with the root port role transitions 202 (compare FIGURES 2 and 3 ).
- the PRT state machine 114 may be configured in accordance with the MSTP specified in IEEE Std 802.1Q-2005.
- the PRT state machine 114 would have root port role transitions which are similar to the RSTP root port role transitions 202.
- the PRT state machine 114 would have alternate and backup port role transitions which are similar to the RSTP alternate and backup port role transitions 302.
- the PRT state machine 114 would have master port role transitions 402 which are used when MSTP is implemented but are not used when RSTP is implemented.
- the master-port role transitions 402 (specified in IEEE Std. 802.1Q-2005) are described next with respect to FIGURE 4 (PRIOR ART).
- the master port role transitions 402 have a MASTER_PORT 404 with multiple transitions 406a, 406b...406g of which transitions 406a and 406b are relevant to the present discussion.
- the first transition 406a has a condition 408 shown as (proposed && !agree) which, if it has a boolean value of TRUE, enables the MASTER_PROPOSED state 410 to be entered.
- the second transition 406b has a condition 412 shown as (allSynced && !agree)
- the master port role transitions 402 have similar conditions 408 and 412 and states 410 and 414 as the ones associated with the root port role transitions 202 and the alternate and backup port role transitions 302 (compare FIGURES 2-4 ).
- Each of these traditional transitions 202, 302 and 402 and in particular their conditions 212, 312 and (412 are problematical when it comes to enabling the proper propagation of a "cut" as is discussed next.
- the RSTP specified in IEEE Std 802.1D-2004 states the following in section 17.16 "[w]here two or more exit conditions with the same level of precedence become TRUE simultaneously, the choice as to which exit condition causes the state transition to take place is arbitrary". This is problematical.
- the first condition 208, 308 and 408 represented as (proposed && !agree) can be satisfied first because the variable "proposed" is TRUE and the variable "agree” is FALSE. If this happens, then the X_PROPOSED state 210, 310 and 410 is entered and the following occurs:
- the second condition 212, 312 and 412 represented as (allSynced && !agree)
- the present invention addresses the problem with the traditional PRT state machine 114 by modifying the second conditions 212, 312 and 412 where variables are inserted whose placement and evaluation at execution time ensure that the X_PROPOSED state 210, 310 and 410 and the X_AGREED state 214, 314 and 414 are entered and executed in the correct sequence.
- the present solution involves the changing of the second condition 212, 312 and 412 from (allSynced && !agree)
- FIGURES 5-7 illustrate the new root port role transitions 502 (e.g., enhancement to IEEE Std 802.1D-2004 and IEEE Std 802.1Q-2005), the new alternate and backup port role transitions 602 (e.g., enhancement to IEEE Std 802.1D-2004 and IEEE Std 802.1Q-2005) and the new master port role transitions 702 (e.g., enhancement to IEEE Std 802.1Q-2005), respectively.
- the new root port role transitions 502 e.g., enhancement to IEEE Std 802.1D-2004 and IEEE Std 802.1Q-2005
- the new alternate and backup port role transitions 602 e.g., enhancement to IEEE Std 802.1D-2004 and IEEE Std 802.1Q-2005
- the new master port role transitions 702 e.g., enhancement to IEEE Std 802.1Q-2005
- the new root port role transitions 502 the new alternate and backup port role transitions 602 and the new master port role transitions 702 have X_PROPOSED states 510, 610 and 710, X_AGREED states 514, 614 and 714, and first conditions 508, 608 and 708 which are the same as those shown in FIGURES 2-4 .
- the new PRT state machine 114' is configured such that the X_PROPOSED state 510, 610 and 710 needs to be entered and executed before the X_AGREED state 514, 614 and 714.
- the aforementioned example is used again where the variables are set as follows:
- the second condition 512, 612 and 712 represented as (!proposed && allSynced && !agree)
- (proposed && agree) will not be satisfied first because of the addition of the new condition "!proposed".
- the new condition "!proposed” can not be evaluated to TRUE in this scenario because the logical negation of the variable "proposed" is FALSE.
- the X_PROPOSED state 510, 610 and 710 is always entered first and the following occurs:
Abstract
Description
- The present invention is related to a bridge and method for ensuring the proper propagation of a cut within a bridged network (e.g., Ethernet-based bridged network).
- Today it is possible for an individual/group to make suggested change(s), deletion(s) and/or addition(s) to a networking standard. For instance, the individual/group could request that a change be made to a particular feature in order to enhance the networking standard. One such change that can enhance a spanning tree protocol which is specified in several networking standards happens to be the subject of the present invention.
- A bridge (e.g., IEEE 802.1 bridge) and a method are described herein which ensure the proper propagation of a "cut" within a bridged network (e.g., Ethernet-based bridged network). In one embodiment, the bridge has a port role transitions (PRT) state machine which uses a first condition represented as (proposed && !agree) to transit to an X_PROPOSED state and a second condition represented as (!proposed && allSynced && !agree) | | (proposed && agree) to transit to an X_AGREED state (where X represents "ROOT", "ALTERNATE" and "MASTER"). The first condition and the second condition are both defined such that the X_PROPOSED state is always entered before the X_AGREED state which ensures the proper propagation of a "cut" within the bridged network.
- IEEE P802.1Q-2004 entitled "IEEE Standard for virtual Bridged Local Area Networks: Revision", IEEE, 21 September 2004, at pages 143-222 is directed to the Multiple Spanning Tree Protocol (MSTP) and to a port role transitions state machine.
- A more complete understanding of the present invention, which is defined by the appended claims, may be obtained by reference to the following detailed description when taken in conjunction with the accompanying drawings wherein:
-
FIGURES 1A-1E are diagrams which are used to help explain the propagation of a "cut" which is a mechanism that is initiated to temporarily prevent data from being communicated over parts of a bridged network when, for example, a bridge is added/removed to/from the bridged network -
FIGURE 2 (PRIOR ART) is a block diagram that illustrates the traditional root port role transitions (specified in IEEE Std 802.1D-2004 and IEEE Std 802.1Q-2005) which are implemented within a PRT state machine of a bridge; -
FIGURE 3 (PRIOR ART) is a block diagram that illustrates the traditional alternate and backup port role transitions (specified in IEEE Std 802.1D-2004 and IEEE Std 802.1Q-2005) which are implemented within a PRT state machine of a bridge; -
FIGURE 4 (PRIOR ART) is a block diagram that illustrates the traditional master port role transitions (specified in IEEE Std 802.1Q-2005) which are implemented within a PRT state machine of a bridge; -
FIGURE 5 is a block diagram that illustrates the new root port role transitions which are implemented within a PRT state machine of a bridge in accordance with the present invention; -
FIGURE 6 is a block diagram that illustrates the new alternate and backup port role transitions which are implemented within a PRT state machine of a bridge in accordance with the present invention; and -
FIGURE 7 is a block diagram that illustrates the new master port role transitions which are implemented within a PRT state machine of a bridge in accordance with the present invention. - The present solution basically ensures the proper propagation of a "cut" within a bridged network (e.g., Ethernet-based bridged network) where data loops are prevented by the operation of a spanning tree protocol, such as the ones specified and standardized by the IEEE 802.1 Working Group. These spanning tree protocols include the Rapid Spanning Tree Protocol (RSTP, as specified and standardized in IEEE Std. 802.1D-2004), the Multiple Spanning Tree Protocol (MSTP, as specified and standardized in IEEE Std. 802.1Q-2005) as well as any other protocol built on and/or expanding the use and scope of the RSTP and/or the MSTP. The contents of these standards are incorporated by reference herein.
-
FIGURES 1A-1E are diagrams which are used to help explain the propagation of the "cut" which is a mechanism that is initiated to temporarily prevent data from being communicated over parts of the bridgednetwork 100 when, for example, abridge 102 is added to an exemplary bridgednetwork 100. InFIGURE 1A , the bridgednetwork 100 is shown having sixbridges links network 100 is loop-free becausebridge 101d has a discardingport 103. Now, assume thenew bridge 102 is added to the bridgednetwork 100. At this point, the "cut" is initiated by havingbridges downstream ports FIGURE 1B . Then,bridges - The
bridge 101a sets itsdownstream ports FIGURE 1C and then the "cut" is propagated todownstream bridges bridges - Finally,
bridges downstream ports 109a/109b and 111a/111b to a discarding (blocking) state and then the "cut" is propagated todownstream bridges FIGURE 1D . Thebridges port 103 onbridge 101d was set to a discarding (blocking) state.FIGURE 1E shows thebridged network 100 including thenew bridge 102 and theold bridges - As can be seen, the "cut" requires that some ports of a bridge transit to the discarding state, where they block data traffic, thus preventing the formation of data loops behind such ports. To ensure that data loops are not created in between this bridge and its downstream bridges, and between these downstream bridges and their downstream bridges, the "cut" is propagated on a spanning tree through the bridges until it reaches the leaves of the spanning tree. It should be appreciated that the "cut" would also be initiated if an old bridge was removed from the
bridge network 100. - To properly implement the "cut", the
bridges state machines 114 enter and execute various states in a specific sequence. However, the existing RSTP and MSTP specifications do not explicitly require such a sequence and even expect that these states can be enterable and executable in any order which is problematical. This problem is discussed in detail below with respect to three different port role transitions which are implemented within thePRT state machine 114 as shown inFIGURES 2-4 (PRIOR ART). - Referring to
FIGURE 2 (PRIOR ART), there is a diagram illustrating the relevant parts of the traditional rootport role transitions 202 which are implemented within the PRTstate machine 114 in accordance with the RSTP specified in IEEE Std 802.1D-2004. As shown, the traditional rootport role transitions 202 have aROOT_PORT state 204 withmultiple transitions transitions first transition 206a has acondition 208 shown as (proposed && !agree) which, if it has a boolean value of TRUE, enables theROOT_PROPOSED state 210 to be entered. And, if thecondition 208 shown as (proposed && !agree) has a boolean value of FALSE then theROOT_PROPOSED state 210 can not be entered. Thesecond transition 206b has acondition 212 shown as (allsynced && !agree) | | (proposed && agree) which, if it has a boolean value of TRUE, enables the ROOT_AGREEDstate 214 to be entered. And, if thecondition 212 shown as (allSynced && !agree) | | (proposed && agree) has a boolean value of FALSE then theROOT_AGREED state 214 can not be entered. Theconditions - ! represents a logical NOT operator.
- && represents a logical AND operator.
- || represents a logical OR operator.
- As indicated above, the traditional root
port role transitions 202 are not the only port role transitions implemented within the PRTstate machine 114 which is relevant to this discussion. The PRTstate machine 114 also implements the traditional alternate and backupport role transitions 302 which are shown inFIGURE 3 (PRIOR ART). As shown, the traditional alternate and backupport role transitions 302 have an ALTERNATE_PORTstate 304 withmultiple transitions 306a, 306b...306d of which transitions 306a and 306b are relevant to the present discussion. The first transition 306a has acondition 308 shown as (proposed && !agree) which, if it has a boolean value of TRUE, enables theALTERNATE_PROPOSED state 310 to be entered. And, thesecond transition 306b has acondition 312 shown as (allSynced && !agree) | | (proposed && agree) which, if it has a boolean value of TRUE, enables theALTERNATE_AGREED state 314 to be entered. The traditional alternate and backupport role transitions 302 shown are configured in accordance with the RSTP specified in IEEE Std 802.1D-2004. As can be seen, the alternate and backupport role transitions 302 havesimilar conditions FIGURES 2 and3 ). - Alternatively, the PRT
state machine 114 may be configured in accordance with the MSTP specified in IEEE Std 802.1Q-2005. In this case, thePRT state machine 114 would have root port role transitions which are similar to the RSTP root port role transitions 202. In addition, thePRT state machine 114 would have alternate and backup port role transitions which are similar to the RSTP alternate and backup port role transitions 302. Moreover, thePRT state machine 114 would have master port role transitions 402 which are used when MSTP is implemented but are not used when RSTP is implemented. The master-port role transitions 402 (specified in IEEE Std. 802.1Q-2005) are described next with respect toFIGURE 4 (PRIOR ART). - As shown in
FIGURE 4 (PRIOR ART), the master port role transitions 402 have aMASTER_PORT 404 withmultiple transitions first transition 406a has acondition 408 shown as (proposed && !agree) which, if it has a boolean value of TRUE, enables theMASTER_PROPOSED state 410 to be entered. And, thesecond transition 406b has acondition 412 shown as (allSynced && !agree) || (proposed && agree) which, if it has a boolean value of TRUE, enables theMASTER_AGREED state 414 to be entered. As can be seen, the master port role transitions 402 havesimilar conditions FIGURES 2-4 ). Each of thesetraditional transitions conditions - To properly propagate the "cut", it is well known that the
X_PROPOSED state X_AGREED state X_PROPOSED state X_AGREED state - The traditional solution is not good because it is not deterministic. For instance, simulations have exhibited the fact that the following variables can at the same time be set as follows:
- agree = FALSE;
- proposed = TRUE; and
- allSynced = TRUE.
- In this situation, anyone of two possible scenarios can occur: (1) the
X_PROPOSED state X_AGREED state X_AGREED state X_PROPOSED state first condition second condition - In the first scenario, the
first condition X_PROPOSED state - The setSyncTree() procedure is executed, which is the first step in the propagation of the "cut" on this particular bridge 102a (or bridge 102b...102f). Again, the first step in the propagation of the "cut" is where the downstream port(s) of that particular bridge 102a (or bridge 102b...102f) is set to be in a discarding (blocking) state (see
FIGURES 1A-1E ). - The variable "proposed" is reset to the boolean value FALSE, and the
X_PROPOSED state - The
X_AGREED state second condition MASER_AGREED state 414 does not set the variable "newInfo" to TRUE). This enables the final step in the propagation of the "cut" to be performed on this particular bridge 102a (or bridge 102b...102f). During, the final step of the propagation of the "cut" the downstream bridges are informed that they should perform the first and second steps of the propagation of the "cut" if deemed necessary by their executing the spanning tree algorithm. - In the second scenario, the
second condition X_AGREED state - The variable "proposed" is reset to the boolean value of FALSE, and the
X_PROPOSED state - In the event, the
X_AGREED state network 100. Because, if data loops are created then this could result in frames (e.g., Ethernet frames) that not only loop but proliferate within the bridgednetwork 100. And, this can lead to a severe loss of available bandwidth in the bridgednetwork 100 such that the bridgednetwork 100 can no longer serve its purpose. Accordingly, there is a need for a solution that can ensure that theX_PROPOSED state X_AGREED state - The present invention addresses the problem with the traditional
PRT state machine 114 by modifying thesecond conditions X_PROPOSED state X_AGREED state second condition FIGURES 5-7 which illustrate the new root port role transitions 502 (e.g., enhancement to IEEE Std 802.1D-2004 and IEEE Std 802.1Q-2005), the new alternate and backup port role transitions 602 (e.g., enhancement to IEEE Std 802.1D-2004 and IEEE Std 802.1Q-2005) and the new master port role transitions 702 (e.g., enhancement to IEEE Std 802.1Q-2005), respectively. As can be seen, the new root port role transitions 502, the new alternate and backup port role transitions 602 and the new master port role transitions 702 have X_PROPOSED states 510, 610 and 710, X_AGREED states 514, 614 and 714, andfirst conditions FIGURES 2-4 . - The new PRT state machine 114' is configured such that the
X_PROPOSED state X_AGREED state - agree = FALSE;
- proposed = TRUE; and
- allSynced = TRUE.
- In this situation, there is just one possible scenario that can occur and that is where the
X_PROPOSED state X_AGREED state X_AGREED state X_PROPOSED state first condition second condition X_PROPOSED state - The setSyncTree() procedure is executed, which is the first step in the propagation of the "cut" on this particular bridge 102a (or bridge 102b...102f). Again, the first step in the propagation of the "cut" is where the downstream port(s) of that particular bridge 102a (or bridge 102b...102f) is set to be in a discarding (blocking) state (see
FIGURES 1A-1E ). - The variable "proposed" is reset to the boolean value FALSE, and the
X_PROPOSED state - The
X_AGREED state second condition MASER_AGREED state 714 does not set the variable "newInfo" to TRUE). This enables the final step in the propagation of the "cut" to be performed on this particular bridge 102a (or bridge 102b...102f). During, the final step of the propagation of the "cut" the downstream bridges are informed that they should perform the first and second steps of the propagation of the "cut" if deemed necessary by their executing the spanning tree algorithm. - It should be appreciated that all of the
conditions 206a...206g, 208, 212, 306a...306d, 308, 312, 406a...406g, 408, 412, 506a...506g, 508, 512, 606a...606d, 608, 612, 706a...706g, 708 and 712 are typically implicitly completed/post fixed with "&& selected && !updtInfo" where the "selected" and "updtInfo" are two variables. - Following are some additional features and advantages of the present solution:
- The present solution places the burden of proper sequencing not on the implementer but on the state machines. This eliminates a potential cause for human error.
- The present solution is easy to implement and is deterministic.
- The present solution applies both to sequential and non-sequential implementations.
- The present solution helps eliminate the risk of creating data loops in the bridged
network 100. This is critical to proper operation of the bridgednetwork 100. - Although the present invention has been illustrated in the accompanying Drawings and described in the foregoing Detailed Description, it should be understood that the present invention is not limited to the description, but its scope is defined by the following claims.
Claims (11)
- A device (101 a-f, 102) comprising:a port role transitions state machine (114') associated with a rapid spanning tree protocol, RSTP, as specified and standardized in IEEE Std. 802.1D-2004, or a multiple spanning tree protocol, MSTP, as specified and standardized in IEEE Std. 802.1Q-2005, the port role transitions state machine (114') having a first condition (508, 608, 708) to transit to an X_PROPOSED state (510, 610, 710) and a second condition (512, 612, 712) to transit to an X_AGREED state (514, 614, 714),wherein said X_PROPOSED state (510, 610, 710) and said X_AGREED state (514, 614, 714) include:a ROOT_PROPOSED state (510) and a ROOT_AGREED state (514);an ALTERNATE_PROPOSED state (610) and an ALTERNATE_AGREED state (614); ora MASTER_PROPOSED state (710) and a MASTER_AGREED state (714), characterized in that said first condition (508, 608, 708) and said second condition (512, 612, 712) are both defined such that the X_PROPOSED state (510, 610, 710) is always entered before the X_AGREED state (514, 614, 714).
- The device of claim 1, wherein said first condition (508, 608, 708) is defined as:(proposed && !agree)where:proposed is a variable;agree is a variable;! represents a logical NOT operator; and&& represents a logical AND operator.
- The device of claim 1, wherein said second condition (512, 612, 712) is defined as:(!proposed && allSynced && !agree) || (proposed && agree)where:proposed is a variable;agree is a variable;allSynced is a parameter;! represents a logical NOT operator;&& represents a logical AND operator; and|| represents a logical OR operator.
- A method for propagating a cut (108a-c) within a bridged network (100), said method comprising the steps of:ensuring that each bridge (101a-f, 102) within said bridged network (100) performs a sequence as follows:entering an X_PROPOSED state (510, 610, 710) within a port role transitions state machine (114') associated with a rapid spanning tree protocol, RSTP, as specified and standardized in IEEE Std. 802.1D-2004, or a multiple spanning tree protocol, MSTP, as specified and standardized in IEEE Std. 802.1Q-2005, upon satisfying a first condition (508, 608, 708) to transit into said X_PROPOSED state (510, 610, 710); andentering an X_AGREED state (514, 614, 714) within the port role transitions statemachine (114') upon satisfying a second condition (512, 612, 712) to transit into said X_AGREED state (514, 614, 714),wherein said X_PROPOSED state (510, 610, 710) and said X_AGREED state (514, 614, 714) includes:a ROOT_PROPOSED state (510) and a ROOT_AGREED state (514);an ALTERNATE_PROPOSED state (610) and an ALTERNATE_AGREED state (614); ora MASTER_PROPOSED state (710) and a MASTER_AGREED state (714),characterized in that said first condition (508, 608, 708) and said second condition (512, 612, 712) are both defined to ensure that the X_PROPOSED state (510, 610, 710) is always entered before the X_AGREED state (514, 614, 714).
- The method of claim 4, wherein said first condition (508, 608, 708) is defined as:(proposed && !agree); andsaid second condition (512, 612, 712) is defined as:(!proposed && allSynced && !agree) || (proposed && agree) where:proposed is a variable;agree is a variable;allSynced is a parameter;! represents a logical NOT operator;&& represents a logical AND operator; and|| represents a logical OR operator.
- The method of claim 5, wherein upon entering said X_PROPOSED state (510, 610, 710) the method further comprises:executing a setSyncTree( ) procedure; andsetting the variable "proposed" to FALSE.
- The method of claim 5, wherein upon entering said X_AGREED state (514, 614, 714) the method further comprises:setting the variable "proposed" and a variable "sync" to FALSE;setting the variable "agree" to TRUE; andoptionally setting a variable "newInfo" to TRUE.
- A network (100) comprising:a plurality of bridges (101a-f) which are coupled to one another by links (104a-f), each bridge (101a-f) configured to ensure propagation of a cut (108a-c) by:entering an X_PROPOSED state (510, 610, 710) within a port role transitions state machine (114') associated with a rapid spanning tree protocol, RSTP, as specified and standardized in IEEE Std. 802.1D-2004, or a multiple spanning tree protocol, MSTP, as specified and standardized in IEEE Std. 802.1Q-2005, upon satisfying a first condition (508, 608, 708) to transit into said X_PROPOSED state (510, 610, 710); andentering an X_AGREED state (514, 614, 714) within the port role transitions statemachine (114') upon satisfying a second condition (512, 612, 712) to transit into said X_AGREED state (514, 614, 714),wherein said X_PROPOSED state (510, 610, 710) and said X_AGREED state (514, 614, 714) includes:a ROOT_PROPOSED state (510) and a ROOT_AGREED state (514);an ALTERNATE_PROPOSED state (610) and an ALTERNATE_AGREED state (614); ora MASTER_PROPOSED state (710) and a MASTER_AGREED state (714),characterized in that said first condition (508, 608, 708) and said second condition (512, 612, 712) are both defined to ensure that the X_PROPOSED state (510, 610, 710) is always entered before the X_AGREED state (514, 614, 714).
- The network of claim 8, wherein said first condition (508, 608, 708) is defined as:(proposed && !agree); andsaid second condition (512, 612, 712) is defined as:(!proposed && allSynced && !agree) || (proposed && agree) where:proposed is a variable;agree is a variable;allSynced is a parameter;! represents a logical NOT operator;&& represents a logical AND operator; and|| represents a logical OR operator.
- The network of claim 9, wherein in each bridge (101a-f, 102), said port role transitions state machine (114') upon entering said X_PROPOSED state (510, 610, 710) performs the following steps:executes a setSyncTree() procedure; andsets the variable "proposed" to FALSE.
- The network of claim 9, wherein said port role transitions state machine (114') upon entering said X_AGREED state (514, 614, 714) performs the following steps:sets the variable "proposed" and a variable "sync" to FALSE;sets the variable "agree" to TRUE; andoptionally sets a variable "newInfo" to TRUE.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/389,700 US7889682B2 (en) | 2006-03-27 | 2006-03-27 | Deterministic operation of rapid spanning tree protocols for proper propagation of a “cut” |
PCT/US2007/064915 WO2007112344A1 (en) | 2006-03-27 | 2007-03-26 | Loop prevention in bridge networks |
Publications (2)
Publication Number | Publication Date |
---|---|
EP2002608A1 EP2002608A1 (en) | 2008-12-17 |
EP2002608B1 true EP2002608B1 (en) | 2013-12-18 |
Family
ID=38259938
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP07759369.7A Not-in-force EP2002608B1 (en) | 2006-03-27 | 2007-03-26 | Loop prevention in bridge networks |
Country Status (3)
Country | Link |
---|---|
US (1) | US7889682B2 (en) |
EP (1) | EP2002608B1 (en) |
WO (1) | WO2007112344A1 (en) |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6262977B1 (en) * | 1998-08-28 | 2001-07-17 | 3Com Corporation | High availability spanning tree with rapid reconfiguration |
US6330229B1 (en) * | 1998-11-09 | 2001-12-11 | 3Com Corporation | Spanning tree with rapid forwarding database updates |
US6771610B1 (en) * | 1999-01-19 | 2004-08-03 | 3Com Corporation | Spanning tree with protocol for bypassing port state transition timers |
US20030065546A1 (en) * | 2001-09-28 | 2003-04-03 | Gorur Ravi Srinath | System and method for improving management in a work environment |
US7324461B2 (en) * | 2003-08-26 | 2008-01-29 | Alcatel Lucent | Selective transmission rate limiter for rapid spanning tree protocol |
-
2006
- 2006-03-27 US US11/389,700 patent/US7889682B2/en not_active Expired - Fee Related
-
2007
- 2007-03-26 EP EP07759369.7A patent/EP2002608B1/en not_active Not-in-force
- 2007-03-26 WO PCT/US2007/064915 patent/WO2007112344A1/en active Application Filing
Non-Patent Citations (2)
Title |
---|
"802.1D - IEEE Standard for Local and metropolitan area networks Media Access Control (MAC) Bridges", 9 June 2004 (2004-06-09), XP055069590, Retrieved from the Internet <URL:http://www.dcs.gla.ac.uk/~lewis/teaching/802.1D-2004.pdf> [retrieved on 20130704] * |
"802.1Q - IEEE Standard for Local and metropolitan area networks Virtual Bridged Local Area Networks", 19 May 2006 (2006-05-19), XP055069604, Retrieved from the Internet <URL:http://www.dcs.gla.ac.uk/~lewis/teaching/802.1Q-2005.pdf> [retrieved on 20130704] * |
Also Published As
Publication number | Publication date |
---|---|
EP2002608A1 (en) | 2008-12-17 |
US7889682B2 (en) | 2011-02-15 |
US20070226485A1 (en) | 2007-09-27 |
WO2007112344A1 (en) | 2007-10-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6771610B1 (en) | Spanning tree with protocol for bypassing port state transition timers | |
EP2436154B1 (en) | Transient loop prevention in a hybrid layer-2 network | |
DE60314935T2 (en) | Method and unit for bit stream decoding | |
DE60301767T2 (en) | Normalization of a Verificationmasses in a device for speaker verification | |
US9042216B2 (en) | Loop prevention mechanism for ethernet ring protection | |
US7564779B2 (en) | Ring rapid spanning tree protocol | |
US7720011B1 (en) | Optimizations and enhancements to the IEEE RSTP 802.1w implementation | |
EP2472795B1 (en) | Method and system for re-building single ring network topology | |
US8583833B2 (en) | Ring topology discovery | |
EP3026852A1 (en) | Loop avoidance method, device and system | |
JP2006025353A (en) | Control packet loop preventive method and bridge device using this method | |
EP2736198B1 (en) | Message processing method and system | |
WO2007131402A1 (en) | A method and device for improving reliability of the shortest route bridge | |
EP1461922A1 (en) | A method to prevent net update oscillation | |
US20090190503A1 (en) | Efficient end-to-end proposal/agreement messaging for spanning tree convergence in a computer network | |
EP2002608B1 (en) | Loop prevention in bridge networks | |
Al-Shaer et al. | ConfigChecker: A tool for comprehensive security configuration analytics | |
JP6369334B2 (en) | In-vehicle network | |
CN101771705A (en) | Processing method based on RRPP and device | |
CN107872331B (en) | Port setting method, device and system | |
CN111526094A (en) | RSTP state machine scheduling method and system | |
EP1727318A1 (en) | Facilitating computation of role and state information for multiple spanning tree instances | |
US8514746B1 (en) | Priority inversion with spanning tree protocol to trigger path switching | |
US9634937B2 (en) | Relay system and relay device | |
Cisco | D1 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20081027 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR |
|
17Q | First examination report despatched |
Effective date: 20091217 |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: ALCATEL LUCENT |
|
DAX | Request for extension of the european patent (deleted) | ||
GRAP | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOSNIGR1 |
|
RIC1 | Information provided on ipc code assigned before grant |
Ipc: H04L 12/46 20060101AFI20130704BHEP Ipc: H04L 12/70 20130101ALI20130704BHEP |
|
INTG | Intention to grant announced |
Effective date: 20130725 |
|
111Z | Information provided on other rights and legal means of execution |
Free format text: AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR Effective date: 20130410 |
|
GRAS | Grant fee paid |
Free format text: ORIGINAL CODE: EPIDOSNIGR3 |
|
GRAA | (expected) grant |
Free format text: ORIGINAL CODE: 0009210 |
|
AK | Designated contracting states |
Kind code of ref document: B1 Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR |
|
REG | Reference to a national code |
Ref country code: GB Ref legal event code: FG4D |
|
REG | Reference to a national code |
Ref country code: CH Ref legal event code: EP |
|
REG | Reference to a national code |
Ref country code: AT Ref legal event code: REF Ref document number: 646005 Country of ref document: AT Kind code of ref document: T Effective date: 20140115 |
|
REG | Reference to a national code |
Ref country code: IE Ref legal event code: FG4D |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R096 Ref document number: 602007034334 Country of ref document: DE Effective date: 20140206 |
|
REG | Reference to a national code |
Ref country code: FR Ref legal event code: GC Effective date: 20140306 |
|
REG | Reference to a national code |
Ref country code: NL Ref legal event code: VDEP Effective date: 20131218 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: LT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20131218 Ref country code: SE Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20131218 Ref country code: FI Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20131218 |
|
REG | Reference to a national code |
Ref country code: AT Ref legal event code: MK05 Ref document number: 646005 Country of ref document: AT Kind code of ref document: T Effective date: 20131218 |
|
REG | Reference to a national code |
Ref country code: LT Ref legal event code: MG4D |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: LV Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20131218 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: EE Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20131218 Ref country code: IS Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20140418 Ref country code: BE Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20131218 |
|
REG | Reference to a national code |
Ref country code: CH Ref legal event code: PCOW Free format text: NEW ADDRESS: 148/152 ROUTE DE LA REINE, 92100 BOULOGNE-BILLANCOURT (FR) |
|
RAP2 | Party data changed (patent owner data changed or rights of a patent transferred) |
Owner name: ALCATEL LUCENT |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: AT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20131218 Ref country code: CZ Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20131218 Ref country code: RO Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20131218 Ref country code: PT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20140418 Ref country code: SK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20131218 Ref country code: NL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20131218 Ref country code: PL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20131218 Ref country code: CY Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20131218 Ref country code: ES Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20131218 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R097 Ref document number: 602007034334 Country of ref document: DE |
|
PLBE | No opposition filed within time limit |
Free format text: ORIGINAL CODE: 0009261 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: LU Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20140326 Ref country code: DK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20131218 |
|
REG | Reference to a national code |
Ref country code: CH Ref legal event code: PL |
|
26N | No opposition filed |
Effective date: 20140919 |
|
REG | Reference to a national code |
Ref country code: FR Ref legal event code: RG Effective date: 20141016 |
|
REG | Reference to a national code |
Ref country code: IE Ref legal event code: MM4A Ref country code: DE Ref legal event code: R097 Ref document number: 602007034334 Country of ref document: DE Effective date: 20140919 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: IE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20140326 Ref country code: LI Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20140331 Ref country code: CH Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20140331 |
|
REG | Reference to a national code |
Ref country code: FR Ref legal event code: PLFP Year of fee payment: 9 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: SI Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20131218 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: MT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20131218 |
|
REG | Reference to a national code |
Ref country code: FR Ref legal event code: PLFP Year of fee payment: 10 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: BG Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20131218 Ref country code: MC Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20131218 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: IT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20131218 Ref country code: GR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20140319 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: TR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20131218 Ref country code: HU Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO Effective date: 20070326 |
|
REG | Reference to a national code |
Ref country code: FR Ref legal event code: PLFP Year of fee payment: 11 |
|
REG | Reference to a national code |
Ref country code: FR Ref legal event code: PLFP Year of fee payment: 12 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: GB Payment date: 20190320 Year of fee payment: 13 Ref country code: DE Payment date: 20190312 Year of fee payment: 13 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: FR Payment date: 20190213 Year of fee payment: 13 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R119 Ref document number: 602007034334 Country of ref document: DE |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: FR Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20200331 Ref country code: DE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20201001 |
|
GBPC | Gb: european patent ceased through non-payment of renewal fee |
Effective date: 20200326 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: GB Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20200326 |