GMPLS Control of Ethernet IVL Switches draft-fedyk-gmpls-ethernet-ivl-00 GELS BOF, IETF 64 Don Fedyk, Dave Allan, Nortel Networks

Outline What is controlled? Examples Is this different from Ethernet today? Control Plane Aspects Applicability Parallel Work Conclusion

What is controlled? Ethernet as a whole does not fully exploit the standards –Independent VLAN Learning (IVL) switches perform a full 60 bit lookup (VID+MAC) IVL switches do not need both VLAN AND MAC each to be unique, just the concatenation of both We delegate some VLAN IDs (VIDs) to a control plane –We still want bridging as well (ships in the night) so is useful to maintain global uniqueness of MAC addresses Much of Ethernet today uses MAC/VID paradigm, don’t mess with it –BUT we can eliminate the globally unique requirement for the delegated range of VIDs VID PLUS MAC provides uniqueness –VID becomes a switched path instance to a MAC named interface 60 bit globally unique, destination administered “label” Moving to configuration from flooding and learning permits complete route freedom for labelled Ethernet Switched Paths –Loop free constraints removed

Dataplane Example - 1 MAC ‘X’ MAC ‘Y’ VID(1)/MAC(X) VID 1, MAC X configured in a contiguous set of switches produces a configured path from “B” to “X” VID 1 delegated to configured behavior MAC’B’

Dataplane Example - 2 MAC ‘X’ MAC ‘Y’ VID(1)/MAC(X) VID(1)/MAC(Y) VID(2)/MAC(Y) VID(2)/MAC(X) Note that MACs and VIDs can overlap, it is the combination of both that is unique and allows diverse routing VID1+2 delegated to ESPs 1/X & 1/Y can diverge 1/X & 2/X can diverge MAC’B’ MAC’P’ MAC’Q’

Dataplane Example - 3 MAC ‘X’ MAC ‘Y’ MAC(B)/VID(1)/MAC(X) MAC ‘A’ MAC ‘B’ MAC ‘C’ SA/VID/DA MAC(C)/VID(1)/MAC(X) MAC(A)/VID(1)/MAC(X)+ MAC(B)/VID(1)/MAC(X) MAC(A)/VID(1)/MAC(X)+ MAC(B)/VID(1)/MAC(X)+ MAC(C)/VID(1)/MAC(X) For MP2P multiplexes, all traffic self identifies source (SA) Full mesh equals O(N) state in the core (VID/DA), O(N) state at the edges (VID/SA)

Is this different from Ethernet Today? Ethernet standards currently allow –MAC learning to be disabled (by VID range) –STP to be disabled (by VID range) –Forwarding table configuration What is needed? –Enforce UNICAST only for specified VID range Then the dataplane is relatively complete and we can add a control plane –Run bridging and ESPs side by side –This behavior is a “profile” OAM in progress is fully applicable

How Many VIDs are Needed? 802.1p marking means ESPs are analogous to E-LSPs –Required queuing discipline is decoupled from “steering” of traffic, paths can be considered functionally equivalent VID+MAC uniqueness means the number of VIDs required equals the number of MP2Ps we want to root on any given interface Given a 4092 VID range, we only need to repurpose a few VIDs to scale a large resilient mesh –Multiple paths to any given destination –Trivial impact on the number of bridged VLANs a network can support

Control Plane Aspects 60 bit VLAN/DA MAC “label” is invariant –Different from GMPLS today VLAN (local to DA), DA (global to network) means destination can administer labels –DA MAC is effectively an OUI for VID –Destination label administration as per GMPLS today Bi-directional ESPs w. common routing preferred –No impacts on Ethernet OAM (802.1ag CFM/Y.17ethoam) –No impacts on Ethernet clients (e.g ah) –GMPLS supports today (Upstream label) Ethernet interfaces are named –Implications for ERO Multiplexed connections are required

Signalling Bi-Directional Paths MAC ‘X’ MAC ‘Y’ MAC ‘B’ MAC ‘C’ Path (Upstream label = VID:2/MAC:B) ‘B’ offers preferred label for ‘X’ in upstream label object Resv (Label = VID:1/MAC:X) ‘X’ replies with offer of preferred label MAC(B)/VID(1)/MAC(X) MAC(X)/VID(2)/MAC(B) 60 bit entries populated in the FIB Full 108 bit connection IDs constructed from both components SA/VID/DA

Applicability Use of MAC+VID means this is a private sub-network solution –GMPLS is in control of the entire layer network for the VID range –No UNI or E-NNI envisioned or planned Can be combined with 802.1ah MACinMAC, IPv4/6 or “Dry Martini” –Services/clients are explicitly an overlay

Parallel Work This has been introduced to SG15/Q12, and IEEE – bottorff-pbt-for-iee-v pdfwww.ieee802.org/1/files/public/docs2005/ah- bottorff-pbt-for-iee-v pdf –SG13/Q5, and SG15/Q9 shortly… Context is “Provider Backbone Transport” or “PBT” –Complementary to 802.1ah Provider Backbone Bridging (PBB)

Conclusion The CCAMP design team has already identified that GMPLS control of Ethernet could be useful This I-D identifies a simple, useful and scalable technique to add connection management to Ethernet –Configuration of IVL switches GMPLS can be applied to this technique It is not a lot of work…..

For Further Reading draft-fedyk-gmpls-ethernet-ivl-00.txt “Ethernet as Carrier Transport Infrastructure” –Forthcoming in IEEE Communications magazine