c.
A ring node accepting an R-APS (FS) message, without any local
higher priority requests unblocks any blocked ring port. This action
subsequently unblocks the traffic channel over the RPL.
d.
The ring node accepting an R-APS (FS) message, without any local
higher priority requests stops transmission of R-APS messages.
e.
The ring node receiving an R-APS (FS) message flushes its FDB.
■
Protection switching on a forced switch request is completed when the
above actions are performed by each ring node. At this point, traffic
flows around the ring are resumed. From this point on the following
rules apply regarding processing of further forced switch commands:
■
While an existing forced switch request is present in a ring, any new
forced switch request is accepted, except on a ring node having a
prior local forced switch request. The ring nodes where further
forced switch commands are issued block the traffic channel and R-
APS channel on the ring port at which the forced switch was issued.
The ring node where the forced switch command was issued
transmits an R-APS message over both ring ports indicating FS. R-
APS (FS) messages are continuously transmitted by this ring node
while the local FS command is the ring node’s highest priority
command. As such, two or more forced switches are allowed in the
ring, which may inadvertently cause the segmentation of an ring. It
is the responsibility of the operator to prevent this effect if it is
undesirable.
Ring protection requests, commands and R-APS signals have the
priorities as specified in the following table.
Table 28: ERPS Request/State Priority
To Next Page
Loading...
