DRNI

1
DRNI Intra-DAS LinkVersion 01

• Stephen Haddock
• July 20, 2011

2
Objective

• Given two adjacent bridges in a network, it is
  highly desirable to be able to configure them to
  support a DRNI
• Without requiring two physical links
• (One for normal network traffic and one dedicated
  as the Intra-DAS Link), and
• Without requiring encapsulation of data frames
  traversing the Intra-DAS Link
• Support for this scenario should be specified in
  the standard and should be mandatory.
• Provides a level of guaranteed interoperability
  that is highly likely to be implementable on the
  majority of existing 802.1Q bridges.

3
DRNI with virtual Intra-DAS Link

• It is conceivable to create a DRNI when there is
  no direct physical connection between the devices
  implementing the Distributed LAG Sublayer.
• In this case the Intra-DAS Link is a virtual link
  (or tunnel) between the two devices.
• Requires encapsulation of any data frames that
  traverse the Intra-DAS Link
• Should the standard support this?
• I think yes, but as an option not a requirement.
• The encapsulation method should be specified in
  the standard.
• It should use PBB encapsulation.

See http//www.ieee802.org/1/files/public/docs201
1/new-farkas-RNI-data-plane-0111-v02.pdf
4
DRNI with physical link between devices
1.

• Given a DRNI with a direct physical connection
  between the devices implementing the DLAG
  Sublayer, what are the options for creating the
  Intra-DAS Link?
• It is a virtual link overlaying the network link
  (no different than case where there is no direct
  link, including encapsulation).
• The physical link becomes the Intra-DAS link and
  is no longer available as a network link.
• Two separate physical links are provided, one as
  the network link and one as the Intra-DAS Link.
• Find some other way to share the same physical
  link without forcing encapsulation of data frames
  traversing the Intra-DAS link.

2.
Intra-DAS Link
DLAG
3.
Intra-DAS Link
DLAG
4.
5
Goal for Intra-DAS Link

• A directly-connected physical link serves as both
  
• a network link (available to be part of the
  active topology of the network), and
• an Intra-DAS Link
• without requiring encapsulation of data frames.
• This should be specified in the standard.
• Support should be required by the standard.
• A common required behavior enhances
  interoperability.
• Not requiring encapsulation facilitates backwards
  compatibility goal and increases probability that
  it could be supported on existing equipment
  without a hardware change.
• Proprietary multi-chassis LAG implementations
  have set market expectation that a dedicated link
  is not necessary.
• Can still have option to implement a virtual
  Intra-DAS Link.
• Can still have option to implement a dedicated
  Intra-DAS Link.

6
Issue 1

• The primary issue is distinguishing data frames
  traversing the network link from data frames
  traversing the Intra-DAS Link.
• When a physical link is dedicated to either the
  network link or Intra-DAS Link (examples 2 and
  3), the frames are distinguished by which link
  they are received from.
• For a virtual Intra-DAS Link (example 1), frames
  are distinguished by the encapsulation of data
  frames on the Intra-DAS Link.
• For the target case of a shared physical link
  without encapsulation (example 4), frames will be
  distinguished by time-sharing the physical link
  as a network link and a Intra-DAS Link.
• This means that at any given time, both devices
  know whether the physical link is being used as a
  network link or an Intra-DAS link.

7
Time-Sharing the Physical Link

• The key to time sharing the Physical Link is
  whether the network link is or is not part of the
  active topology of the network at any point in
  time.
• When the network link is not in the active
  topology (i.e. blocked
  by RSTP, G.8032, or other loop prevention
  algorithm)
  then the
  physical link IS NOT used for network data frames
  and IS available for data frames traversing the
  Intra-DAS Link.
• Both devices must recognize that the network link
  is blocked and inhibit transmission of any data
  frames intending to traverse the network link.
• When the network link is in the active topology
  then the physical link IS
  used for network data frames and IS NOT available
  for data frames traversing the Intra-DAS Link.
• Since data frames cannot traverse the Intra-DAS
  Link, the DRNI gateway selection and link
  selection must be coordinated such that the
  selected gateway and selected link are always on
  the same physical device.
• Time sharing only affects use of Intra-DAS Link
  for data.
• Intra-DAS Link is always available for control
  frames.

8
Review of DRNI Gateways and Links
Network Link
b
a
Gateways
b
a
Network
DRNI
Interconnect Links
Intra-DAS Link
The functionality of the Gateways, a, and b are
all in the Distributed Link Aggregation Sublayer
9
Objectives for Gateway and Link Selection

• Gateway selection objectives/requirements
• Assure that at most one copy of any frame is
  delivered between the network and the DRNI.
• For bridges, gateway selection must be compatible
  with the learning processes within the network.
• Link selection objectives/requirements
• The same link must be selected for all frames
  belonging to any given conversation
  (traditional Link Aggregation constraint).
• A DRNI must support a means to select the same
  link in both directions for all frames belonging
  to a single service (reverse path congruent
  per-service link selection).
• Constraint added by time-sharing proposal
• When the link between devices is part of the
  active topology of the network, the selected link
  and selected gateway must be on the same device.

10
Time Share -- Case 1

• Case 1 Network link is not part of active
  topology, so physical link is used only as
  Intra-DAS Link
• Gateway Selection MUST be based on VID.
• Assures single copy of frame between Network and
  Interconnect
• Since all frames received from the Interconnect
  with a given VID enter the Network through the
  same Gateway, no problems learning addresses in
  the Network.
• Link Selection is flexible.
• Link Selection MAY be per conversation.
• Link Selection MAY be per service.
• Service Identifier could be VID, I-SID,
• Link Selection MAY be reverse path congruent
• Selected Gateway and Selected Link do not
  necessarily need to be on the same device.
• If Selected Gateway and Selected Link are on
  different devices then the frame will traverse
  the Intra-DAS Link.

11
Frame Flow Example for Case 1
Tx Frame
Network Link
b
a
Selected Gateway
Network
Unselected Gateway
a
b
Intra-DAS Link

Selected Link
Rx Frame
Note that if two frames received from the
Interconnect with the same VID and same source
MAC address had different selected gateways,
those frames would take different paths through
the network. This would cause problems with the
Learning process in the Network. Therefore the
Gateway selection MUST be based on VID (or
source MAC address) for Case 1.
12
Time Share -- Case 2

• Case 2 Network link is part of active topology,
  so physical link is not available for forwarding
  data frames on the Intra-DAS Link.
• Two sub-cases to consider
• Sub-case 2a Link Selection IS negotiated
  between the Networks on opposite sides of the
  DRNI.
• Link Selection is likely, though not necessarily,
  to be based on a service identifier in the frame
  (e.g. C-VID, S-VID, I-SID)
• To make the Time-sharing proposal work in this
  case, the Link Selection MUST be symmetric
  (reverse path congruent).
• Sub-case 2b Link Selection IS NOT negotiated
  between the Networks on opposite sides of the
  DRNI.
• Each Distributor is free to send any frame on any
  DRNI link subject only to the constraint that all
  frames of a given conversation take the same
  link.

13
Time Share -- Case 2a

• Case 2a Network link is part of active
  topology Link Selection is negotiated and
  symmetric.
• Gateway selection uses the same criteria as Link
  Selection.
• For frames to be transmitted on a DRNI link, the
  selected Gateway will be the Gateway on the same
  device as the selected DRNI link.
• For frames received on a DRNI link, the selected
  Gateway is always on the same device as that DRNI
  link.
• Therefore no data frames need to traverse the
  Intra-DAS Link.
• The Link Selection MUST be symmetric (reverse
  path congruent) and MUST be enforced by
  discarding any frame received on a DRNI link that
  would not be the selected link for that frame.
  Otherwise the combination of rules 1 and 2 above
  would permit a frame received on one DRNI link to
  be subsequently transmitted back on another DRNI
  link.

14
Time Share -- Case 2b

• Case 2b Network link is part of active
  topology Link Selection is not negotiated.
• Gateway selection is based on ingress port.
• The Gateway on a given device is never selected
  for frames received from the Network Link that is
  time-shared as an Intra-DAS link.
• The Gateway on a given device is always selected
  for frames received from any other link
  (including DRNI links).
• Since Gateway selection is not based on VID there
  are potential learning issues, but only on the
  network link that is time-shared with the
  Intra-DAS Link. These issues are resolved in the
  control plane.
• Link Selection and Gateway selection are
  inter-dependent.
• For frames to be transmitted on a DRNI link, the
  selected link may be any DRNI link on the same
  device as the selected Gateway.
• For frames received on a DRNI link, the selected
  Gateway is always on the same device as that DRNI
  link (by rule 2 above).
• Therefore no data frames need to traverse the
  Intra-DAS Link.

15
Frame Flow Example for Case 2
Tx Frame
b
a
Network Link
Selected Gateway
Network
Unselected Gateway
a
b
Intra-DAS Link

Rx Frame
Selected Link
Note that two frames with the same VID entering
the network through different gateways will
follow the same path in the same direction
everywhere in the network except for the link
between the DRNI nodes. Therefore there is no
chance of causing learning problems at any of the
other network nodes. Therefore Gateway
selection does not need to be based on VID for
Case 2.
16
Time-Shared Link Summary
NOTE 1 The frame forwarding of Case 1 is the
same as for a dedicated Intra-DAS Link, and is
basically the same as what is currently described
in the draft. NOTE 2 The frame forwarding of
Case 2b is the same as for most proprietary
Multi-chassis LAG implementations. NOTE 3 The
applicable column is determined by configuration.
The applicable row changes with topology changes
in the Network, but does not cause changes in the
Interconnect.
17
Failure Scenarios

• Failure of an external DRNI link
• Obviously forces a change in Link Selection.
• In Case 1 there need not be any change in Gateway
  Selection.
• In Case 2a the change in Link Selection drives a
  corresponding change in the Gateway.
• In Case 2b the only change is if all external
  DRNI links attached to a single node fail, in
  which case the other node becomes the gateway for
  all frames.
• Failure of the Time-shared Intra-DAS Link
• Assuming there is another path through the
  network (for data and for DRNI control frames)
  then the aggregation can be maintained when Link
  Selection is negotiated and symmetric.
• May require a change in gateway selection to
  match Link Selection.
• Frame forwarding behavior is then the same as
  Case 2a.
• When Link Selection is not negotiated the
  aggregation cannot be maintained.

18
gt2 Nodes in Distributed Aggregation

• Needs more investigation
• I think everything works out pretty easily when
  Link Selection is negotiated and symmetric.
• I think time-sharing the Intra-DAS Link can work
  when Link Selection is unilateral when there is a
  full mesh of Intra-DAS links, but may get fairly
  complex.
• Is it worth it?
• May be reasonable to require virtual Intra-DAS
  Link support or dedicated Intra-DAS Links to
  support more than two nodes.

19
Conclusion

• It is possible to configure DRNI on two adjacent
  bridges without requiring either a dedicated
  Intra-DAS Link or encapsulation of data frames on
  the Intra-DAS Link.
• This is likely to be the sweet-spot of DRNI
  application.
• Support for this should be specified in the DRNI
  standard, and should be required for bridges
  implementing DRNI.