The role of the other port in a non-root bridge may be Designated Port if it propagates along the BPDUs issued by the Root Bridge and received by its Root Port, or otherwise Non-Designated Port if it does not propagate them any further, and that will depend on the STP algorithm calculations.
Accordingly, BPDUs are sent from all Designated Ports to the other end of each link depending on the HelloTimer settings, which is 2 seconds by default.
As far as STP operation is concerned, when a bridge first gets connected to other bridges, it assumes it is the Root Bridge, therefore its ports are all in Designated role and they start sending BPDUs out to its neighbour bridges.
As long as those other bridges receive those BPDUs, they run the STP algorithm in order to check whether the values received are better than theirs referring to the election of the Root Bridge and all port roles within the bridge loop, including the Non-Designated Port.
--sending BPDUs to its neighbour bridges, but only when the HelloTimer goes off and only if the port looking at a particular neighbour is in Designated role,
Also, there are other two fields for SuppIierBridges that will be known during the first exchange of BPDUs, as neighbouring bridges do not change whilst they are on.
If the value related to the port role is zero, that port will be sending BPDUs along the link and it might also be receiving them at early stages of the STP process, but it will not send them if that value is greater than zero, as it will only be receiving them.
Those values included in BPDUs are BridgelD (BID), RootID (RID) and RootPathCost (RPATH) corresponding to bridge i and they are carried by the structure [A.sub.i] from that bridge i to both of its neighbouring bridges.
With those points in mind, we proceed to derive (12), considering that at the very beginning all ports are in Designated role and will be sending BPDUs, therefore