DRNI – Intra-DAS Link
Version 01
Stephen Haddock
July 20, 2011
1
Objective
• Given two adjacent bridges in a network, it is
highly desirable to be able to configure them to
support a DRNI …
1. Without requiring two physical links
(One for normal network traffic and one dedicated as the
Intra-DAS Link), and
2. 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.
2
DRNI with virtual Intra-DAS Link
Intra-DAS Link
DLAG
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?
•
•
See http://www.ieee802.org/1/files/public/docs2011/newfarkas-RNI-data-plane-0111-v02.pdf
•
I think yes, but as an option not a
requirement.
The encapsulation method should be
specified in the standard.
It should use PBB encapsulation.
3
DRNI with physical link between devices
1.
Intra-DAS Link
DLAG
2.
Intra-DAS Link
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?
1.
DLAG
2.
3.
Intra-DAS Link
3.
DLAG
4.
4.
Intra-DAS Link
DLAG
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.
4
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.
5
Issue #1
• The primary issue is distinguishing data frames traversing
the network link from data frames traversing the IntraDAS 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 IntraDAS link.
6
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.
1.
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.
2.
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.
7
Review of DRNI Gateways and Links
Network Link
a
b
a’
b’
Gateways
Network
DRNI
Interconnect Links
Intra-DAS Link
The functionality of the Gateways, a’, and b’ are all in the Distributed Link Aggregation Sublayer
8
Objectives for Gateway and Link Selection
• Gateway selection objectives/requirements
1.
2.
•
Link selection objectives/requirements
1.
2.
•
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.
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.
9
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.
1.
2.
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.
1. Link Selection MAY be per conversation.
2. Link Selection MAY be per service.
–
Service Identifier could be VID, I-SID, …
3. 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.
10
Tx Frame
Frame Flow Example for Case 1
Network Link
a
b
Selected Gateway
Unselected Gateway
Network
a’
Intra-DAS Link
b’
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.
11
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.
12
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.
1. 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.
2. 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.
13
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.
1. 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.
2. 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.
1. 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.
2. 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.
14
Tx Frame
Frame Flow Example for Case 2
a
Network Link
b
Selected Gateway
Unselected Gateway
Network
a’
Rx Frame
Intra-DAS Link
b’
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.
15
Time-Shared Link Summary
Link IS
in active
topology
Link IS NOT
in active
topology
Negotiated, symmetric
Link Selection
Unilateral
Link Selection
CASE 2a
CASE 2b
Gateway selection based
on Link Selection
Gateway selection
based on ingress port
CASE 1
Gateway selection based on VID
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.
16
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.
17
>2 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.
18
Conclusion
• It is possible to configure DRNI on two adjacent
bridges without requiring either a dedicated IntraDAS 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.
19