RSTP - Decoupling of port roles from port states

[rrajmohan]

RSTP states that "port roles are decoupled from port state".

I am not able to completely understand this statement.

The role of a port is determined earlier by the exchange of BPDUs prior to fixing the state of a port

A port which assumes the role of either Designated / Root are always going to land up in  Forwarding state

Similariy, a port which assumes the role of either Alternate / Backup are always going to land up in Discarding state.

How the decoupling can be defined in RSTP in comparison to Legacy 802.1D STP

[Peter Paluch]

Hi Rajmohan,

RSTP states that "port roles are decoupled from port state".

Yes, this is true, because in RSTP you can have your Designated port role jump from the Forwarding state to the Discarding state and back - not because its role has been changed but because for safe transition from one active topology to another (or to reconfirm the current topology), it is necessary to block it for some time. This is what happens during the Proposal/Agreement procedure when on a link, the upstream switch (the one closer to the root) sends a Proposal, the downstream switch will move all its non-edge Designated role ports into Discarding state and then send back an Agreement.

Would this perhaps be helpful?

Best regards,
Peter

[rrajmohan]

Thank you Peter.

That means, In RSTP the state of a port is not having a one-to-one relationship with the role of a port as that of in legacy STP.

Can you also please clarify, how this decoupling helps better in faster convergence ?

[Peter Paluch]

Hi Rajmohan,

That means, In RSTP the state of a port is not having a one-to-one relationship with the role of a port as that of in legacy STP.

Well, not quite. Not even STP had a one-to-one relationship between the role and the state of a port. If a port is Forwarding, what is it? A Designated port? A Root port? It can be both of them. RSTP helps to clarify things by more clearly distinguishing between two different qualities of a port - its role (what purpose does it have in the topology) and its state (what is it allowed to do with incoming and outgoing data).

Can you also please clarify, how this decoupling helps better in faster convergence ?

It is the necessary requirement for the Proposal/Agreement mechanism to exist. Without this decoupling, Proposal/Agreement as defined in RSTP would not be possible to implement.

Best regards,
Peter