DRNI – Intra-DAS Link Version 01 Stephen Haddock July 20,

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 3 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. DLAG Intra-DAS Link See farkas-RNI-data-plane-0111-v02.pdfhttp:// farkas-RNI-data-plane-0111-v02.pdf

DRNI with physical link between devices 4 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.It is a virtual link overlaying the network link (no different than case where there is no direct link, including encapsulation). 2.The physical link becomes the Intra-DAS link and is no longer available as a network link. 3.Two separate physical links are provided, one as the network link and one as the Intra-DAS Link. 4.Find some other way to share the same physical link without forcing encapsulation of data frames traversing the Intra-DAS link. DLAG Intra-DAS Link DLAG Intra-DAS Link DLAG Intra-DAS Link DLAG Intra-DAS Link

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 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. 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 8 ba ba DRNI Network Intra-DAS Link Network Link Gateways Interconnect Links The functionality of the Gateways, a, and b are all in the Distributed Link Aggregation Sublayer

Objectives for Gateway and Link Selection Gateway selection objectives/requirements 1.Assure that at most one copy of any frame is delivered between the network and the DRNI. 2.For bridges, gateway selection must be compatible with the learning processes within the network. Link selection objectives/requirements 1.The same link must be selected for all frames belonging to any given conversation (traditional Link Aggregation constraint). 2.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.Assures single copy of frame between Network and Interconnect 2.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

Frame Flow Example for Case 1 11 Network Unselected Gateway Selected Gateway Tx Frame Rx Frame Selected Link Intra-DAS Link ba ab Network Link 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.

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

Frame Flow Example for Case 2 15 Network Unselected Gateway Selected Gateway Tx Frame Rx Frame Selected Link Intra-DAS Link ba ab Network 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.

Time-Shared Link Summary 16 Negotiated, symmetric Link Selection Unilateral Link Selection Link IS in active topology Link IS NOT in active topology CASE 1 Gateway selection based on VID CASE 2a Gateway selection based on Link Selection CASE 2b Gateway selection based on ingress port 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.

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 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. 19