1 / 14

GMPLS Control of Ethernet IVL Switches draft-fedyk-gmpls-ethernet-ivl-00 GELS BOF, IETF 64

GMPLS Control of Ethernet IVL Switches draft-fedyk-gmpls-ethernet-ivl-00 GELS BOF, IETF 64 Don Fedyk, dwfedyk@nortel.com , Dave Allan, dallan@nortel.com, Nortel Networks. Outline. What is controlled? Examples Is this different from Ethernet today? Control Plane Aspects Applicability

upton
Download Presentation

GMPLS Control of Ethernet IVL Switches draft-fedyk-gmpls-ethernet-ivl-00 GELS BOF, IETF 64

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. GMPLS Control of Ethernet IVL Switches draft-fedyk-gmpls-ethernet-ivl-00 GELS BOF, IETF 64 Don Fedyk, dwfedyk@nortel.com, Dave Allan, dallan@nortel.com, Nortel Networks

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

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

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

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

  6. Dataplane Example - 3 MAC(A)/VID(1)/MAC(X)+ MAC(B)/VID(1)/MAC(X) SA/VID/DA MAC(A)/VID(1)/MAC(X)+ MAC(B)/VID(1)/MAC(X)+ MAC(C)/VID(1)/MAC(X) MAC ‘A’ MAC(B)/VID(1)/MAC(X) MAC ‘X’ MAC ‘B’ MAC(C)/VID(1)/MAC(X) MAC ‘Y’ MAC ‘C’ 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)

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

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

  9. 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. 802.1ah) • GMPLS supports today (Upstream label) • Ethernet interfaces are named • Implications for ERO • Multiplexed connections are required

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

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

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

  13. 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…..

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

More Related