Malcolm Scott

MOOSE Talklet, SRG NetOS meeting, November 2007

                __  __  ___   ___  ____  _____
               |  \/  |/ _ \ / _ \/ ___|| ____|
               | |\/| | | | | | | \___ \|  _|
               | |  | | |_| | |_| |___) | |___
               |_|  |_|\___/ \___/|____/|_____|

                Boosting Ethernet's Scalability

                         Malcolm Scott

1. Ethernet: where and why?

Increasingly, it's in the core of the Internet

  =>  Multi-purpose international infrastructure:
        transit, multi-site peering, inter-datacentre links...
  =>  Multiple independent IP networks over one infrastructure
  =>  "Zero-hop!"


My use-case: The Intelligent Airport (TINA)
http://intelligentairport.org.uk/

  =>  Unified multi-service wired/wireless airport network
  =>  Mobility
  =>  Based on Ethernet as lowest common denominator

2. Ethernet: it's great, but it doesn't scale

  =>  Spanning tree:

         Shortest path routing would be preferable


  =>  Broadcast: DHCP, ARP, unknown destinations...

         Does every node really need to know?


  =>  MAC address table (switches):

         Learn location of MAC addresses (flat namespace)
         Table has fixed size; things break if it fills

3. Flat MAC address namespace: encapsulation?

Previously proposed solution (MPLS etc.):

  =>  Ingress switch encapsulates every frame within another

  =>  Hides real source MAC address from other switches

  =>  Egress switch undoes encapsulation to find real destination


But how do we find which switch to send encapsulated frame to?

Another large table, or more broadcast...

4. MOOSE (Multi-layer Origin-Organised Scalable Ethernet)

Ingress switches rewrite source address of every frame

        New address:  [Switch ID]:[Node ID]

This address remains in place when the frame reaches its
destination, and will appear in ARP table etc.

  =>  So, replies will go to this hierarchical address


Makes end nodes unwittingly do the job of mapping target
nodes to switch IDs, without breaking compatibility

5. Test implementation: Linux bridging module + Xen

Several Xen domains acting as MOOSE switches or clients

More work than I expected :-)


Implementation challenges:

  =>  Allocation of dynamic node IDs
        (DHCP server in the kernel?)

  =>  Handover for mobility

  =>  Integration
        (I'll also be doing Ethernet routing)

Thanks!

      _/\_       __/\__
      ) . (_    _) .' (
      `) '.(   ) .'  (`
       `-._\(_ )/__(~`
           (   )-.__.--._
           ) o            `-._____
          /                       `---._
         ( ,// )                        \ 
          `''\/-.                        |
                 \                       |
                 |                       |