TIME-SHARED LINK

1
TIME-SHARED LINK DRNI LEARNING
2
From axbq-haddock-intra-das-link-0711-v02.pdf
the use case we are considering

• The difference between case 2a and 2b is that
  there is no predetermined link selection.
• When transmitting to the DRNI this means the link
  selected is on the first DRNI node encountered by
  the frame. In terms of gateway selection this
  means a DRNI node is the gateway for any frame
  received on any link that is not directly
  connected to the other DRNI node.
• When receiving from the DRNI node that receives
  the frame is also the gateway for that frame.

3
From axbq-haddock-intra-das-link-0711-v02.pdf-
The Steady State Problem

• Every frame of the A ? Z conversation is
  propagated on-net, and also along the B ? C link,
  thence to X where it is discarded (2nd Gateway)
• Every frame of the Z ? A conversation is
  propagated on-net, and also along the Y ? X link,
  thence to C where it is discarded (2nd Gateway)
• Net-net, the entire A?C conversation gets
  replicated on the IPL / Network Link of the
  remote network to no purpose.

4
axbq-haddock-intra-das-link-0711-v02.pdfSo what ?

• Mitigation possibilities include (in no
  particular order)
• eliminate the IPL / Network Link timeshare mode.
• impose topology restrictions associated with the
  use of the IPL / Network Link timeshare mode
• e.g. only p2p service between over DRNI is
  supported in this mode
• no MAC learning needed, simple VLAN forwarding
  rules just work
• others ?
• re-visit MAC learning synchronisation
• Exchange MACs learned from DRNI enables
  Gateways to learn unicast routes for all
  conversations.
• there must be others ?

5
From axbq-haddock-intra-das-link-0711-v02.pdf-
Step 2 the problem summary

• Learning phase 2
• Y propagates Zs reply on learned route (via B),
• it must also replicate it to the DRNI (towards
  X), because the route could originate at S (top
  L), and Y is 1st Gateway for route to S
• To solve this, B must communicate to Y whence the
  original packet with SA A came.

6
From axbq-haddock-intra-das-link-0711-v02.pdf -
a possible solution.

• A simple solution would be to use a modified MAC
  learning process
• When B learns a source MAC in the normal way on
  any non-IPL link,
• it unicasts a control packet (?) on the IPL only,
  qualifying the source
• as on-net, from-DRNI, local-time-out,
  unknown ,
• which is used to modify the attributes of the SA
  MAC also learned at Y by normal mechanisms (so
  MAC aging is handled by normal means).
• This MAC source communication does not need to be
  totally reliable
• a lost packet results only in inefficiency, not
  failure (see slide 3),
• but transmission x 3 on first learning a MAC
  would be sensible,
• and repeating the MAC source qualification packet
  at infrequent intervals(e.g. MAC age-out time /
  3 ?) will ensure sync in long term

7
REPRESENTING THE RELATIONSHIP BETWEEN DRNI (MASK)
VARIABLES
8
Trying to make sense of the Conversation-sensitive
frame collection and distributionVariables
Port Algorithm TLV
Port Conv ID Digest TLV
aAggConversationAdminPort
Conversation Mask TLV
Port Conv Svc Map TLV
Service ID
? Conversation-sensitive LACP

aAggAdminServiceConvMap
per port ? aggregate
Collection_Conv_Mask


Port Conversation ID
?
Actor_Oper_Port_State.Dist

updateConversationMask
per port ? aggregate
Comp_Oper_Conv_Mask
receivedConversationMaskTLV
? updateConversationMask
?
?
Port_Oper_Conv_Mask
Partner_Oper_Conv_Mask
Per Agg. Port Variables
Per Aggregator Variables
Per Aggregator Attributes