Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[RPRWG] Topology stabilization timer



All,

 

In D3.3 clause 11.2.1.2.3, the topology stabilization time (default 40

ms) is defined as the amount of time required for the topology to stabilize across all stations on the ring. This timer is important for the total experienced restoration time for strict order traffic.

 

Upon notification of an error, context containment is declared, and not cleared until the topology is deemed stable when a topology checksum is calculated after the topology stabilization timer expires. During context containment, all strict mode frames are discarded upon entering and leaving a station. This way, frame reordering is avoided.

 

My question is: What is the rationale for setting the topology stabilization time to 40 ms (configurable from 10 ms to 100 ms)? To avoid packet reordering, it should be sufficient to wait long enough for the STQ to empty. Back-of-the-envelope calculations show that for a ring with 1Gb/s links, 256kB transit buffers and 50% non-fe traffic, this does not require more than worst-case about 8 ms.

 

Would it be an idea to set the topology stabilization timer as a function of the STQ size, STQ thresholds, the link capacity and the rate of non-fe traffic?

 

Regards,

Amund Kvalbein

PhD student, Simula Research Laboratory, Oslo