Comment 323

1
Comment 323

• D3.1 (routine DistantStateMax) has a bug that
  results in pre-emption of WTR on a single link
• This by itself can be easily fixed
• However, D3.1 (and all previous versions) have
  inconsistent pre-emption behavior when there are
  non-IDLE protection conditions on multiple links
  on the same ringlet
• TP frames are not forwarded through edge span

2
Pre-emption Scenario 1
A
A
TO
SF
SF
B
D
B
D
SF
WTR
C
C

• Remove one SF
• D3.1 (and all previous drafts) allow SF and WTR
  to be simultaneously present until WTR expires

3
Pre-emption Scenario 2
A
A
TO
MS
MS
B
D
B
D
FS/SF/SD
C
C

• D3.1 (and all previous drafts) allow MS and
  FS/SF/SD to be simultaneously present in certain
  conditions
• A sees idle edge on DC span and takes no action
• A can only preempt MS based on the first TP frame
  sent from C through D to A. If this TP frame is
  lost, A will not preempt MS

4
Pre-emption Scenario 3
A
A
TO
SF
WTR
B
B

• Remove SF
• D3.0a works correctly for this case
• Bug was introduced into D3.1 that causes WTR to
  be pre-empted
• D3.1 attempted to preempt new protection
  conditions in a ring with an idle edge on one
  end, and
• Invalid entry, lack of an edge, or repetition of
  the stations own MAC address on the other end

5
Solutions Option A

• Fix Scenario 3 only
• Accept (and state) that the protection hierarchy
  is not followed consistently if there are
  simultaneous non-IDLE conditions solely on links
  on the same ringlet
• Sounds bad to me
• Ring can break into two pieces (without ability
  to recover) if there is an existing MS on a
  single interface, and an SF occurs on a link on
  the same ringlet
• Does not require new fields to be added to the
  topology database
• Does not require TP frame size to be increased

6
Problems with Option A

• Ambiguity of the neighbor protection state on an
  idle edge forces a guess as to whether to preempt
  protection elsewhere for a protection state lt SF
• Guessing has several problems
• If no pre-emption for state lt SF, then behavior
  described in scenarios 1 and 2 is seen
• If pre-emption for state lt SF, then
• Pre-emption may occur when the neighbor
  protection state on the idle edge is lt SF (even
  WTR). This means that MS can be falsely denied,
  and that an edge can be cleared for SD (and then
  re-instated)

7
Solutions Option B

• Report protection state on the other side of an
  idle edge, based on information received from the
  neighbor station
• Protection state now includes the additional
  options IDLE/non-preemptible, IDLE/pre-emptible,
  and IDLE
• It is used ONLY for removing the ambiguity of an
  idle edge in the routine DistantStateMax (that
  determines the largest protection state on the
  ring)
• This solution requires (at least) one exception
  case to be handled in DistantStateMax
• From Cs perspective, there is a pre-emptible
  idle edge at B
• If C sees WTR on the other side of the ring, it
  must ignore the pre-emptible idle edge

A
WTR
B
D
MS should not be rejected
C
8
Solutions Option C

• Report protection state on the other side of an
  idle edge, based on information received from the
  neighbor station
• There are currently only two unused possibilities
  out of eight in the pse and psw fields in the TP
  frame. This is not sufficient to report the
  actual neighbor protection state
• Field naming needs to be worked out (pseNbr?
  pswNbr?)
• For this solution, one byte needs to be added to
  the TP frame
• The neighbor protection state reported in the TP
  frame is stored in the topology database.
• It is used ONLY for removing the ambiguity of an
  idle edge in the routine DistantStateMax (that
  determines the largest protection state on the
  ring)
• This is the most complete solution