Alcatel-Lucent 7210 SAS-X - Credit Based Algorithm

Virtual Leased Line Services
7210 SAS-X, R6 OS Services Guide Page 159
The CLI commands to configure control channel status requests are shown, below:
[no] control-channel-status
[no] refresh-timer <value> //0,10-65535, default:0
[no] request-timer
[timeout-multiplier <value>]
[no] shutdown
exit
request-timer <timer1>: 0, 10-65535, defaults: 0.
• This parameter determines the interval at which PW status messages, including a reliable
delivery TLV, with the “request” bit set (see below) are sent. This cannot be enabled if
refresh-timer not equal to zero (0). retry-timer : 3-60s
• This parameter determines the timeout interval if no response to a PW status is received.
This defaults to zero (0) when no retry-timer. timeout-multiplier <value> - 3-15.
• If a requesting node does not hear back after retry-timer times multiplier, then it must
assume that the peer is down. This defaults to zero (0) when no retry-timer.
Credit Based Algorithm
In order to constrain the CPU resources consumed processing control channel status messages, the
system should implement a credit-based mechanism. If a user enables control channel status on a
PW[n], then a certain number of credits c_n are consumed from a CPM-wide pool of max_credit
credits. The number of credits consumed is inversely proportional to the configured refresh timer
(the first three messages at 1 second interval do not count against the credit). If the current_credit
<= 0, then control channel status signaling cannot be configured on a PW (but the PW can still be
configured and no shut).
The following is an example algorithm:
If refresh timer > 0, c_n = 65535 / refresh_timer
Else c_n = 0.
For n=1, current_credit[n] = max-credits – c_n
Else current_credit [n] = current_credit [n-1] – c_n
If a PE with a non-zero refresh timer configured does not receive control channel status refresh
messages for 3.5 time the specified timer value, then by default it will time out and assume a PW
status of zero. A proprietary optional extension to the [RFC6478] protocol should be implemented
to enable a node to resolve such a stale PW status condition by requesting the status from the far
end node in certain cases.