GMPLS Control of Ethernet IVL Switches

1
GMPLS Control of Ethernet IVL Switches draft-fedyk
-gmpls-ethernet-ivl-00 GELS BOF, IETF 64 Don
Fedyk, dwfedyk_at_nortel.com, Dave Allan,
dallan_at_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 (VIDMAC)
• 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,
  dont 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
MACB
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
VID12 delegated to ESPs
1/X 1/Y can diverge
VID(1)/MAC(X)
MAC X
MACQ
MACP
MACB
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
• VIDMAC 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
Signalling Bi-Directional Paths
SA/VID/DA
MAC X
MAC B
MAC Y
MAC C
11
Applicability

• Use of MACVID 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-bottorf
  f-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