MPLS and RSVP
7210 SAS M, T, X, R6, Mxp MPLS Configuration Guide Page 43
PW control channel status notifications use a similar model to T-LDP status signaling. That is, in
general, status is always sent to the nearest neighbor T-PE. To achieve this, the PW label TTL is
set to 1 for the G-ACh packet containing the status message.
Control channel status notifications are disabled by default on a spoke-sdp. If they are enabled,
then the default refresh interval is set to zero (although this value should be configurable in CLI).
That is, when a status bit changes, three control channel status packets will be sent consecutively
at one-second intervals, and then the transmitter will fall silent. If the refresh timer interval is non-
zero, then status messages will continue to be sent at that interval. The system supports the
configuration of a refresh timer of 0, or from 10-65535 seconds. The recommended value is 600
seconds.
In order to constrain the CPU resources consumed processing control channel status messages, the
system implements 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 shutdown).
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 trap is generated if the refresh timer times-out.
If PW redundancy is configured, the system will always consider the literal value of the PW
status; a time-out of the refresh timer will not impact the choice of the active transit object for the
VLL service. The result of this is that if the refresh timer times-out, and a given PW is currently
the active PW, then the system will not fail-over to an alternative PW if the status is zero and some
lower-layer OAM mechanism for example, BFD has not brought down the LSP due to a
connectivity defect. It is recommended that the PW refresh timer be configured with a much
longer interval than any proactive OAM on the LSP tunnel, so that the tunnel can be brought down
before the refresh timer expires if there is a CC defect.
Note that a unidirectional continuity fault on a RSVP TE LSP may not result in the LSP being
brought down before the received PW status refresh timer expires. It is therefore recommended
that either bidirectional static MPLS-TP LSPs with BFD CC, or additional protection
mechanisms. For example, FRR be used on RSVP-TE LSPs carrying MPLS-TP PWs. This is
particularly important in active/standby PW dual homing configurations, where the active /
standby forwarding state or operational state of every PW in the redundancy set must be
accurately reflected at the redundant PE side for the configuration.
Note that a PW with a refresh timer value of zero is always treated as having not expired.
The 7210 SAS implements a hold-down timer for control-channel-status pw-status bits in order to
suppress bouncing of the status of a PW. For a specific spoke-sdp, if the system receives 10 pw-
To Next Page
Loading...
