Addressing the Scalability of Ethernet with MOOSE

Document Sample
Addressing the Scalability of Ethernet with MOOSE Powered By Docstoc
					Addressing the Scalability of Ethernet with MOOSE
                Malcolm Scott, Daniel Wagner-Hall, Andrew Moore and Jon Crowcroft
                          University of Cambridge Computer Laboratory
                       {Malcolm.Scott, daw63, Andrew.Moore, Jon.Crowcroft}

                        Abstract                               necessity for virtualised infrastructure [3]. While IP Mo-
                                                               bility [4] addresses the problem of maintaining higher-
Ethernet does not scale well to large networks. The flat        layer connections when roaming between subnets, it re-
MAC address space, whilst having obvious benefits for           quires client support that is neither ubiquitous or reli-
the user and administrator, is the primary cause of this       able. Common practice sees the provision of one phys-
poor scalability; other recent efforts to improve upon         ical Ethernet network covering an entire data centre, or
Ethernet’s scalability have addressed symptoms, rather         even an entire WAN of data centres.
than this underlying cause. In this paper we present              Our approach, Multi-level Origin-Organised Scalable
MOOSE, Multi-level Origin-Organised Scalable Ether-            Ethernet (MOOSE), provides all the advantages of an
net, an Ethernet switch architecture that performs in-         Ethernet network without the capital and running costs
place rewriting of MAC addresses in order to impose            and administrative overhead of a IP router-based ap-
a hierarchy upon the address space without reconfigu-           proach. MOOSE does this by providing a hierarchical
ration or modification of connected devices. This re-           addressing scheme without requiring host reconfigura-
moves the need for switches to maintain large forward-         tion or modification.
ing databases, is of direct use in implementing improved          Ethernet’s scalability is limited firstly by the forward-
routing, and allows for a variety of other scalability         ing database that every switch in an Ethernet network
and security innovations. We also present a globally-          must maintain [5, §7.8–7.9]. A switch’s forwarding
scalable, distributed and resilient protocol for the auto-     database contains one entry per source address seen in
matic assignment of addresses to switches, and for de-         any frame passing through that switch, and stores that
tecting and cheaply resolving addressing conflicts.             MAC address together with the learnt location of that
                                                               address—the port on which packets from that address
1   Introduction                                               were last seen. This is later used to determine on which
Ethernet has lasted well since its inception in the ’70s [1]   port to transmit frames destined for that address. De-
with Ethernet frame-structure and addressing remaining         vices frequently broadcast frames throughout the net-
ubiquitous in the data centre environment as in many           work (e.g. ARP queries) so active devices on the net-
others. Alongside IP and IP-transported services such as       work are listed in most switches’ forwarding databases
iSCSI, it is now commonplace to see converged network          most of the time.
services such as physical disk interfaces and cluster in-         In modern switches the capacity of this database is
terconnects layered directly over Ethernet (e.g. ATA-          generally of the order of 16,000 entries [6]. (Higher-
over-Ethernet and variants of Infiniband). However, Eth-        capacity forwarding databases exist but are currently
ernet exhibits scalability issues on networks of more          constrained to very high-end switches.) On a moderately
than a few thousand devices, such as costly and energy-        large network, full databases are a serious risk. If the
dense address table logic and storms of broadcast traffic.      database becomes full, entries will be discarded; frames
   Aside from more physical devices, virtualised infras-       for unknown addresses are flooded to all ports and the
tructure further increases the density of Ethernet ad-         resulting traffic storm could cause major problems, es-
dresses in data centres. Widely-used layer-2 virtualisa-       pecially in the presence of low-capacity edge links.
tion mandates a unique Ethernet address per virtual ma-           Traditionally the forwarding database has been stored
chine [2]. This means that each physical machine in a          in a content-addressable memory (CAM) as lookups
data centre may represent many tens of Ethernet devices.       must be very fast, particularly as 10 Gbit/s Ethernet be-
   The traditional method of avoiding such problems is         comes ubiquitous. As networks grow, the number of en-
the artificial subdivision of a network, but this introduces    tries in a switch’s forwarding database must naturally in-
an administrative burden, requires significant routing          crease; however, increasing the capacity of CAMs with-
equipment and also precludes seamless migration—a              out sacrificing speed whilst constraining energy con-
sumption is proving to be challenging [7, 8]. Cheaper         wireless LANs are the one remaining vestige of Ethernet
switches use DRAM in place of a CAM, but this is likely       operating over shared media, where one switch (access
to remain slower especially for large tables.                 point) serves many hosts on the same radio channel.
   Secondly, Ethernet’s inability to handle networks con-        Ethernet’s poor scalability arises in various guises, as
taining loops also presents a scalability problem. The        outlined in section 1. It would seem at first glance that
Rapid Spanning Tree Protocol, RSTP [5, §17], must re-         these are entirely distinct and unrelated. However, there
move loops by disabling any redundant links. On a dense       is a common underlying cause: that MAC addresses pro-
mesh network, RSTP will disable a large proportion of         vide no location information.
links; this constrains frames to suboptimal routes and           Globally-unique MAC addresses are structured such
may introduce bottlenecks in the network, particularly        that the first three bytes of a device’s address contain an
around the root of the spanning tree. In a data centre en-    organisationally unique identifier (OUI) allocated to the
vironment, this potentially amounts to a very large pro-      device’s manufacturer by the IEEE, with the remaining
portion of capacity being wasted wherever redundant fi-        three bytes allocated by the manufacturer. This hierar-
bres are installed, e.g. between cabinet switches and be-     chy exists solely for the purpose of allocating unique ad-
tween data centres.                                           dresses in a decentralised fashion, and is of no use to
   Thirdly, not only does Ethernet flood frames des-           Ethernet switches, which must treat the unicast address
tined for unknown hosts, but it also uses—and encour-         space as flat.
ages higher-layer protocols to use—broadcast for con-            A flat address space has the advantage that no configu-
trol messages. For example, ARP [9] performs address          ration of devices is required; a device can use its unique,
resolution via broadcast queries, and DHCP [10] uses          manufacturer-assigned MAC address anywhere on any
broadcast messages for automatic configuration. It is im-      network. However, this leaves each switch with the task
practical to replace these protocols entirely as this would   of discovering and storing the location of every address-
require software upgrades to every device, but it would       able device.
be desirable for the network to minimise the amount of           If the MAC address space were not flat, but instead
broadcast traffic required to be forwarded.                    contained enough information to locate the device pos-
   In this paper we identify the relevant underlying prob-    sessing the address, several advantages would be gained.
lems in the design of Ethernet (section 2), review pre-       Firstly, large forwarding databases would no longer have
vious work (section 3) and present the MOOSE switch           to be maintained on every switch. This location infor-
architecture, which addresses inadequacies in the funda-      mation could instead be distributed across the network
mental operation of Ethernet in a novel yet backwards-        so that frames are directed towards their destinations ac-
compatible way (section 4). By revisiting the address-        cording to successive stages of a hierarchy.
ing scheme itself, rather than simply addressing symp-
                                                                 Secondly, a hierarchical MAC address space would
toms of the problem as many previous proposed solu-
                                                              also make the addition of shortest-path routing consid-
tions have done, we can go about solving all of the above
                                                              erably easier. Shortest-path routing is clearly a desir-
scalability problems and more.
                                                              able property for a network, yet it is one that Ethernet
   A working high-level software implementation of            does not provide. Flat addressing does not lend itself
MOOSE is described and evaluated in section 6.                to easy routing: any address can be located anywhere on
   This work expands on our previous paper presented          the network, which means either advertising every host’s
at the First Workshop on Data Center – Converged and          MAC address via the routing protocol—which scales
Virtual Ethernet Switching (DC CAVES) [11]. We have           very poorly—or providing some other location lookup
added a crucial piece of the architecture—an automatic        service. The use of hierarchical addresses, with each
addressing scheme with cheap conflict resolution—and           switch handling a block of sequential addresses akin to
have better addressed the key issue of compatibility with     an IP subnet, would reduce the routing problem to the
existing protocols.                                           one that routing protocols were designed to solve.
                                                                 Thirdly, this would allow for reduction of broadcast
2   Ethernet’s Underlying Problem                             traffic in a variety of different ways. Hierarchical MAC
The original Ethernet was a shared-medium network,            addresses could, for example, be mapped directly and
where every frame was broadcast and no switching took         deterministically onto the IP address space, if appro-
place. Modern-day wired Ethernet-based networks in-           priate for the specific deployment. This would allow
stead consist almost entirely of point-to-point links; as     switches to respond directly and simply to DHCP and
a result of this, the distinction between unicast, broad-     ARP queries, avoiding the need to forward the most
cast and multicast has become more important. 802.11          common sources of broadcast frames. Alternatively, a
distributed directory service can be used, which is less       sulating switches must obtain a new destination address
limiting and is thus our preferred approach as detailed in     for every frame using a lookup table that—like Ether-
section 4.5.                                                   net’s forwarding database—must contain every transmit-
   The facility for network administrators to assign lo-       ting MAC address. Due to its heavy basis on Ethernet,
cally administered addresses (LAAs) to devices has ex-         this shares many of Ethernet’s scalability problems.
isted for as long as Ethernet. However, configuring and            SmartBridge [14] and Rbridges [15] both encapsu-
maintaining the LAA on every device based upon where           late Ethernet frames in a new inter-switch protocol, and
they are connected would be a considerable and unwel-          run a link-state routing protocol between switches. The
come administrative overhead. In this paper we there-          link state graph includes the location of every MAC
fore present MOOSE, a system for applying hierarchical         address—necessary because the address space remains
addressing to an Ethernet transparently and without any        flat and any address could appear anywhere—i.e. it again
configuration to edge devices.                                  contains every host. Furthermore, switches must per-
                                                               form expensive computation to update routing tables
3   Related Work                                               whenever a MAC address joins or leaves the network.
It is well-known that traditional Ethernet scales poorly,         Myers et al. [16] suggest that Ethernet’s main failing
and there have been various attempts in recent years           is its broadcast service, and propose a new architecture
to rectify this. The most widely-used of these in              in which hosts make explicit use of directory services
real-world networks is MPLS-VPLS (Multiprotocol La-            operated by switches rather than broadcasting queries.
bel Switching—Virtual Private LAN Service) [12].               It is clear that switches’ participation is necessary in
This connects Ethernet islands together through tunnels        order to deal with the broadcast problem; however the
across a MPLS cloud. MPLS works by adding one or               modifications to Ethernet suggested are not backwards-
more labels to the start of every frame, i.e. encapsulat-      compatible and would require at least software modifi-
ing the frame inside its own protocol.                         cations to all connected devices. Ethernet is, perhaps un-
                                                               fortunately, too widespread for this to be practical; trans-
   In MPLS-VPLS, the label edge routers (LERs) must
                                                               parent interception of broadcast frames and subsequent
determine the frame’s initial label(s) based upon the des-
                                                               local handling or redirection via multicast or unicast re-
tination address via a lookup table. Frames follow prene-
                                                               mains the only practical solution. The use of hierarchical
gotiated label-switched paths (LSPs) that, unlike Ether-
                                                               addressing is a useful stepping-stone to such a system,
net, are not constrained to follow a spanning tree; LSPs
                                                               and our architecture includes a transparent directory ser-
are precomputed at connection setup time and the rele-
                                                               vice (ELK, section 4.5) for this purpose.
vant next hop is stored in a lookup table on each interme-
diate switch. Each switch must hence use each frame’s             SEATTLE [17] takes a more scalable approach. A
label to index into this lookup table to determine how to      routing protocol is operated between switches, but in
switch the frame.                                              contrast to the approaches described above and in com-
                                                               mon with MOOSE, the routing protocol only propagates
   The effect, once the connection has been negotiated,
                                                               switch location information, rather than every MAC ad-
is to provide what appears to be one or more large
                                                               dress on the network. Flat MAC addresses are still
Ethernet networks, transparently overlaid on the MPLS
                                                               used, and hence a mechanism is required to look up the
cloud. Whilst this solves effectively the problem of
                                                               switch to which a given address is connected. This is
shortest-path routing across the MPLS cloud, the over-
                                                               achieved by using a distributed hash table (DHT) op-
lay Ethernets are still susceptible to the usual scalability
                                                               erating on participating switches with local caching to
problems—and in fact VPLS adds further large lookup
                                                               alleviate load. This is certainly a step in the right direc-
tables on every switch that can in some configurations
                                                               tion but introduces considerable complexity to switches,
scale even worse than Ethernet’s forwarding databases.
                                                               since they now must maintain and update the DHT con-
LERs must map every MAC address to a LSP; label
                                                               tinually, and it is clear that a SEATTLE switch would
switch routers (LSRs) must store the next hop for ev-
                                                               have a significant software component in the data path.
ery LSP in which they participate, which in the core of
                                                               MOOSE alleviates some of the complexity of SEATTLE
the network could scale as O(hosts2 ).
                                                               by a combination of hierarchical addresses and delega-
   A similar scheme is proposed by Hadˇ i´ [13], with the
                                                               tion to a separate directory service.
difference that Ethernet-inside-Ethernet encapsulation is
used rather than a new protocol. This has the advantage
                                                               4   MOOSE Architecture
that less processing is required on intermediate switches
in the backbone network. However, routes across the            The basic operation of MOOSE is to assign a new hier-
backbone are constrained to a spanning tree, and encap-        archical MAC address to each host on the network, as-
signed dynamically and automatically from the unicast
                                                                                      02:22:22:00:00:02    hosts
LAA space. This dynamically-assigned address is re-
                                                                                      02:22:22:00:00:03   02:33:33:00:00:01
ferred to as a MOOSE address to avoid confusion with                                  ...
hosts’ static, manufacturer-assigned MAC addresses.           switch       switch
                                                             02:11:11     02:22:22                        02:33:33:00:00:03
   Every frame entering the network has its source ad-                                                    02:33:33:00:00:04
                                                                                             switch       ...
dress rewritten in-place to the sending host’s MOOSE                                        02:33:33
address by the first MOOSE-aware switch it traverses;
the new source address becomes the sending host’s              Figure 1: Assignment of MOOSE addresses by switches
MOOSE address. The switch that performs address                • some constant delimiter to appear between the
rewriting for a host—i.e. the closest MOOSE switch to            switch identifier and host identifier, with switch
that host—is the host’s home switch and is responsible           identifiers not allowed to contain the delimiter.
for assigning a MOOSE address to that host. (If non-
MOOSE switches or hubs are in use, a host may have              The former is simple and gives 8 classes of switch
more than one “closest” MOOSE switch, in which case          identifier. Because the size of a MOOSE network is lim-
an RSTP-like protocol must be used to elect a switch to      ited by the placement of IP routers, these classes should
handle each edge segment.)                                   be sufficient. Additionally, because switches are free
                                                             to change their identifier, they may trivially switch to
   The destination address is left intact in the expecta-
                                                             a larger class if they have too many attached hosts, or a
tion that it already is a MOOSE address. Hosts’ ARP
                                                             smaller class becomes full.
caches will already contain the MOOSE addresses of
any hosts being communicated with as any packet re-             The latter removes the fixed classes, allowing for
ceived will already have had its source address rewritten;   more flexibility with the sizes of switch identifiers, at
a host’s manufacturer-assigned MAC address is never          the cost of complexity, and a reduction in the available
seen outside of the segment containing that host. This       address space.
is a crucial point since encapsulation-based technolo-          Each switch can select for itself a unique switch
gies such as MPLS do not reveal to the destination host      identifier, as identifier conflict resolution is cheap (sec-
the address used for routing; as a result, switches must     tion 4.2). When first joining the routing protocol (sec-
also convert destination as well as source addresses of      tion 4.1), conflict should be very unlikely, as the switch
frames entering the network. In other words, once again      will in the process gain an up-to-date list of in-use iden-
switches must maintain large tables of remote hosts          tifiers. Depending on requirements, the switch identi-
on the network. The only destination rewriting that          fier may itself be a hierarchical address—e.g. six bits to
MOOSE switches perform, however, is of the destina-          identify a network area followed by two bytes to identify
tion addresses of frames destined for local hosts back to    a switch within that area—which could then be used to
their manufacturer-assigned MAC addresses; this is sim-      aid routing decisions.
ple as the required information is already known, and           Each host is assigned a host identifier by its home
necessary because otherwise that host’s network inter-       switch from the pool of identifiers available to that
face card would discard the frame as misaddressed.           switch. Only a host’s home switch ever bases a switch-
   A MOOSE address consists of a switch identifier fol-       ing decision on the host identifier, so the detail of how
lowed by a host identifier. For our examples, we sim-         these are allocated can vary from switch to switch. Suit-
ply use a fixed three-byte switch identifier followed by a     able schemes include:
fixed three-byte host identifier, as illustrated in figure 1.     • sequential assignment;
Since these two identifiers when concatenated must form         • the port number followed by a sequential portion
a unicast LAA, the settings of two bits in the first byte         (to allow for multiple hosts connected to one port);
of the switch identifier are fixed: the least significant bit     • a hash of the host’s real MAC address.
must be 0 to indicate a unicast address, and the second-        The latter two approaches are preferable to a sim-
least significant bit must be 1 to indicate a LAA. To cater   ple sequential assignment, as they better isolate certain
for variable length switch identifiers, some means of in-     kinds of denial-of-service attack in which a malicious
troducing separation between the switch and host iden-       host attempts to use up all available host identifiers on
tifiers is required. Two possible implementations would       the switch. They also require less state to be shared be-
be for:                                                      tween ports. The third option has the further advantage
  • the first three bits of the address indicate how many     that it is deterministic and hence can be recovered easily
    of the following 5-bit blocks make up the switch         in the event of a crash.
    prefix;                                                      It is hence possible to route frames through the net-
work to remote hosts by simply inspecting the switch          4.2   Address Selection and Conflict Resolution
identifier in the destination address, and ignoring the
host identifier until the frame reaches the destination        For reasons akin to those of the flaws of Ethernet,
host’s home switch. Switches no longer need to keep a         it is undesirable to guarantee universally unique pre-
table of all MAC addresses seen recently; they only need      determined MOOSE switch identifiers. Due to the re-
store the locations of other switches and of any directly-    duced size of the switch ID space compared to the MAC
connected hosts.                                              address space, this would also be infeasible. We there-
                                                              fore propose that each switch selects an initial address
   As well as reducing the amount of data that must be        for itself during startup. This could result in more than
consulted in order to make switching decisions, this pro-     one switch claiming an address, which would be un-
vides extra resilience by making this data much more          desirable, so to mitigate the potential for MOOSE ad-
predictable. The number of MAC addresses in a net-            dresses to find themselves in conflict we additionally
work can increase unexpectedly in the event of an ad-         propose a simple and inexpensive conflict resolution
dress flooding attack [18] or even under normal opera-         protocol.
tion if the network contains open wireless access points;
                                                                 Suppose two switches each have the same identifer.
relying on the MAC address list for forwarding leads
                                                              We note that if these switches are on separate MOOSE
to some of the vulnerabilities of Ethernet. The set of
                                                              networks (on disconnected networks, or separated by an
switch identifiers participating in MOOSE switching, on
                                                              IP router), this situation brings no issue. Should they be
the other hand, is kept predictable and manageable by
                                                              on the same MOOSE network, however, a conflict ex-
ensuring that neighbouring switches (discovered using
                                                              ists and must be resolved. Any routing protocol would
LLDP [19]) are authenticated before they can partici-
                                                              require a switch to know which port other switches are
pate in the routing protocol. This authentication can be
                                                              connected to, for instance by OSPF neighbour lists, or
achieved at layer 3 using the security features found in
                                                              simply by receiving frames and noting the switch port
most popular routing protocols and/or at layer 2 using
                                                              and source MOOSE address. When a switch receives
802.1X [20]. As the switch identifier is the only address
                                                              a MOOSE frame, it looks up the source switch in its
consulted for forwarding decisions, a MOOSE switch
                                                              forwarding database, which is likely in fast Content Ad-
is likely to remain reliable in the face of attacks that
                                                              dressable Memory. If it finds that source switch to be on
could have brought down a traditional Ethernet. Fur-
                                                              a port other than that which it recognises from its table,
thermore, any attacks based upon MAC address spoof-
                                                              one of three situations may be possible:
ing cannot function on a MOOSE network as the user-
provided MAC address is translated immediately.                 • the source switch may be the same as the known
                                                                  switch, and have physically moved, or a topology
4.1   Shortest Path Routing                                       change has occurred;
                                                                • the source switch may be a different one to the
As described so far, MOOSE switches must still forward            known switch, and they are in conflict;
frames along a spanning tree. As discussed in section 1,        • the source switch may be the same as the known
this is an undesirable property of Ethernet as it can cause       switch, but is sending frames down a different route
frames to take a highly suboptimal path through the net-          to the last used route.
work. The foundations are in place to do much better             To avoid disruption to the network in the first case,
than this using shortest-path routing.                        and to give scope for switches to migrate within the net-
   For the purpose of frame forwarding, a MOOSE               work, the switch which detected the possible conflict
switch can be considered akin to a layer 3 router; it has     should ascertain whether the known switch is still alive
one locally-connected subnet—containing all addresses         and present. The conflict-resolving switch thus attempts
starting with its switch identifier—and delivers frames to     to send a unicast frame to the known switch, via the port
other subnets by passing them to an appropriate neigh-        stored in the forwarding database, asking whether it is
bouring switch. Bearing this in mind, the switch can          there at a regular interval until a timeout. This will reach
run a routing protocol of the kind normally used for IP,      the known switch rather than the new switch if it is still
such as a variant of OSPF [21]. This allows frames to         present as other switches beyond that port must not have
be routed along the shortest available path, rather than      detected the conflict yet. The nature of the timeout we
being constrained to a spanning tree. OSPF-OMP [22]           leave unspecified, and can be implementation specific.
may be particularly desirable due to its ability to make      It may, for instance, be a pre-defined constant, or it may
use of multiple equal-cost routing paths in order to im-      vary based on QoS information gathered if such capa-
prove performance [23].                                       bilities are supported. When a MOOSE switch receives
such a frame, it should promptly respond with an ac-         Algorithm 2 Conflict resolution timer
knowledgement frame, showing that it is alive.
                                                               foreach clock tick do
   If, within the timeout period, the conflict resolver             if timer > 0 then
finds the known host not to be alive, no conflict exists, so              timer = timer − 1;
the switch updates its view of the network by removing             else
the old entry from its forwarding database and triggering               counter = 0;
a routing protocol refresh.                                        end
   If, on the other hand, the host is found to be alive, a     end
conflict exists. The conflict resolver then sends a frame
to the more recently found switch indicating that it is
in conflict and should change its address. That switch,       timeout, and/or having both switches in conflict select
upon receiving this frame, changes its address and sends     new addresses.
a gratuitous ARP for each of its connected hosts, so that       The conflict resolution algorithm brings a marked im-
the rest of the network is aware of the change. To mit-      provement on the equivilent vulnerability of Ethernet,
igate the risks of a denial of service attack, or faulty     that MAC addresses can be spoofed. We build in a flex-
equipment sending out conflict frames, an exponential         ible, well-defined system of recovery. The decentralised
backoff algorithm should be used when receiving con-         nature of the system makes it much less open to denial
flict notification frames.                                     of service attack than any centralised directory may be.
   A switch should have a timer, and counter influenc-        Having every MOOSE switch acting as a barrier to the
ing the maximum value of the timer, both initialised to      propagation of packets from addresses in conflict pro-
0. When a conflict notification frame is received, the         vides a strong separation between recently bridged net-
counter is incremented (subject to a saturation value to     works with conflicting addresses, so that communica-
avoid excessive timeouts). After a conflict has been          tion within the individual networks may continue with-
resolved—i.e. the switch has changed its address—a           out modification, until bridge-crossing traffic appears, at
timer starts counting down from some time exponential        which point resolution quickly happens. We also re-
in that counter; subsequently the switch will only change    move the possibility for forwarding databases to fre-
its address if the timer has returned to 0 by the time the   quenty have to switch their entry for a conflicted ad-
conflict frame is received. The counter should be re-         dress, which can happen with MAC conflicts in tradi-
set to 0 when the timer reaches 0. Using this scheme         tional Ethernet. Additionally, in the case of a switch
the event of true conflict is handled quickly, even in the    identifier spoofing attack, the conflict resolver acts as a
unlikely case that the newly acquired address is also in     hard boundary for the effects of such an attack.
conflict. Any node emitting malicious or erroneous con-          It is possible that the switch performing conflict res-
flict notifications, however, is rate-limited enough that      olution could send a suggested replacement switch ad-
their damage potential is much restricted, subject to a      dress to the switch in conflict, known by the conflict
sufficient timer being chosen.                                resolver to have a low probability of being present on
                                                             the network (because it is not present in its forwarding
Algorithm 1 Conflict resolution backoff
                                                             database). This would reduce the chance of repeated col-
  if timer > 0 then                                          lisions, and potentially allow for longer backoff periods,
       if counter < counter max then                         but may be premature optimisation.
           counter = counter + 1;
                                                                Because multi-path routing is often desirable, we
                                                             could introduce an extra datum during the source ad-
       // Discard conflict notification frame
                                                             dress rewriting performed by MOOSE switches. When
  else                                                       an ingress MOOSE switch rewrites the source address
       timer = k counter ;
                                                             of an Ethernet frame to a MOOSE address, it could also
       change address();
                                                             prepend some hash of its manufacturer-assigned MAC
                                                             address to the data field, and increment the length field
                                                             as necessary. The egress switch, when rewriting the
  This could be further enhanced by detecting repeated       MOOSE destination address to a host’s MAC address,
conflicts involving the same switch or switches, in           then strips out this added datum. This allows the conflict
a manner similar to BGP Route Flap Damping [24],             resolver to check whether conflicts actually exist by lo-
and performing more aggressive steps to avoid further        cal lookup, rather than probing other switches, at the cost
conflicts—for example using a significantly increased          of added memory requirements in every switch. This
        MAC address:              Switch ID:              Switch ID:                  Switch ID:            MAC address:
      00:16:17:6D:B7:CF            02:11:11                02:22:22                    02:33:33           00:0C:F1:DF:6A:84

              Host                                                                                             Host
               A                                                                                                B
                 00:16:17:6D:B7:CF      source
                                       rewritten
                                                              frame broadcast using reverse path forwarding

                                                                                 source      00:0C:F1:DF:6A:84
                                                                               rewritten             
                                         frame routed to 02:11:11
                          destination                               02:33:33:00:00:01
                            rewritten                                      

                      Figure 2: Sequence diagram of a broadcast query and subsequent unicast response
may push the frame to be larger than Ethernet’s maxi-               4.4     Example
mum, so may require fragmenting the packet into two, at
small added cost. Alternatively, assuming jumbo frames              To illustrate the basic behaviour of MOOSE switches,
are permitted by the hardware, the maximum frame size               before we go on to describe further features, we will
could be marginally reduced to allow for this in the same           offer a simple example. We will describe the steps in-
manner as for 802.1Q VLAN tags.                                     volved in forwarding a broadcast frame containing a
   From the cheapness of conflict resolution, certain                query in some higher-layer IPv4-based protocol, and
other address management tasks become simple. A                     subsequent unicast frame containing the response, be-
switch is free to choose its address when it joins the net-         tween two hosts A and B via three MOOSE switches
work however it wishes—attempting to re-use its last-               02:11:11, 02:22:22 and 02:33:33; see figure 2.
used address, from a list of preferred addresses, or by
generating an address entirely at random. More intricate            4.4.1    Query
addressing schemes may be used on managed networks
                                                                      i) Host A transmits the broadcast query frame as
if desired, perhaps encapsulating deeper layers of hier-
                                                                         it would on any Ethernet network, with its own
                                                                         manufacturer-assigned MAC address in the Ether-
4.3   Broadcast and Multicast                                            net header’s source field and the broadcast address
                                                                         (FF:FF:FF:FF:FF:FF) in the destination field.
Since Ethernet does still need to support arbitrary broad-           ii) The frame is received by switch 02:11:11, which
cast frames, these must still be forwarded along a span-                 observes the non-MOOSE address in the frame’s
ning tree in order that they reach each host exactly once.               source field, and rewrites the source field into a
An explicit spanning tree protocol is not required how-                  MOOSE address containing the switch identifier
ever, as the tree can be deduced from the routing ta-                    and the appropriate host identifier. As this is Host
ble via reverse path forwarding in a similar manner to                   A’s first frame, the switch must allocate a host iden-
Protocol-Independent Multicast (PIM) [25]. In other                      tifier (in this case 00:00:01, making Host A’s com-
words, broadcast packets are routed as if they had been                  plete MOOSE address 02:11:11:00:00:01).
sent to the all-hosts multicast group.                              iii) The three switches broadcast the frame using re-
   More general multicast groups can be implemented                      verse path forwarding away from Host A.
using a combination of IGMP snooping [26] as used                   iv) The frame is received by Host B (and any other
by modern Ethernet switches, and participation of the                    hosts on the network) in its current form; no fur-
MOOSE switches in PIM routing.                                           ther rewriting is performed.
4.4.2    Response                                                               Host
                                                                                 B                gratuitous ARP
  i) Host B looks up Host A’s IP address in its ARP
                                                                                                  sent by new
     cache to determine a suitable destination address                                             home switch
     for the response frame. Since the rewritten query
     frame arrived at Host B with the source field con-
     taining the MOOSE address 02:11:11:00:00:01,
     this is the address returned by the cache lookup.                                   
 ii) As above, switch 02:33:33 assigns a MOOSE ad-                                 data forwarded
     dress to Host B (02:33:33:00:00:01) and rewrites                             by care-of switch
     the source address of the frame.
iii) The frame is now routed through the network based
     solely on the destination switch identifier—the host                                                 
     identifier is ignored for now. The routing table is                      host relocated to new switch       Host
     consulted for the location of switch 02:11:11 and                                                           A
     the frame is forwarded accordingly.
iv) On receiving the frame, switch 02:11:11 observes           Figure 3: Two ways to handle a host A roaming onto another
                                                               switch whilst maintaining communication with another host B
     that it is destined for a host directly connected to
     itself (02:11:11:00:00:01). It prepares the frame         tain the answer to a query is when answering an ARP re-
     for transmission along its final hop by rewriting          quest for a host that is not configured to use DHCP and
     the destination address to Host A’s manufacturer-         that has not yet itself sent an ARP packet (i.e. has not yet
     assigned MAC address. The source field of the              communicated via IP). This must be dealt with by flood-
     frame is again left as the MOOSE address of Host          ing the query to every active switch port, in a manner
     B in order that this address is used for any further      akin to current Ethernet switches, and caching the result
     communication with Host B.                                in the ELK directory. Although this is not ideal, it is nec-
                                                               essary in order to deal with this scenario in a compatible
4.5     Directory Service                                      manner, and is unlikely to happen frequently.
A directory service, Enhanced Lookup (ELK), runs in
                                                               4.6   Mobility
conjunction with the basic MOOSE switch described so
far. ELK exists to handle ARP and DHCP queries in              A consequence of introducing location-based hierarchy
a broadcast-free manner by learning mappings from IP           into MAC addresses is the need to explicitly handle host
addresses to MOOSE addresses. The master ELK direc-            mobility. In a traditional Ethernet, hosts can migrate be-
tory is served by one or multiple systems for resilience       tween switches as the switches will learn the host’s new
and is reached using an anycast MOOSE address; the             location as soon as it sends a frame. With MOOSE, if
layer-2 anycast feature is a convenient side-effect of run-    a host relocates to a new switch its address changes and
ning a routing protocol. Slave copies of the directory can     any ARP cache entries on other hosts pertaining to the
be held nearer the edge of the network in order to take        migrated host become incorrect; frames will continue to
load away from the masters; slaves can be reached for          be sent to the host’s old location for a while. There are
lookups via a separate anycast address, and the entire         two strategies for dealing with this, as illustrated in fig-
herd of ELK can be kept synchronised via the masters           ure 3, which can be used separately or in conjunction:
using a combination of multicast and unicast.                    i) The previous home switch of the migrated host can
   MOOSE switches intercept ARP and DHCP packets                    forward frames sent to the host’s old address until
broadcast by hosts and convert them into anycast ELK                outdated ARP cache entries expire. This is simi-
queries to the nearest slave (for ARP) or master (for               lar to IP Mobility [4]: the previous home switch
DHCP). (DHCP handling could make use of the proto-                  essentially becomes a care-of agent for the host.
col’s existing DHCP relay mechanism.) The ELK slave                 However, unlike IP Mobility, it requires no host
answers ARP queries directly using information in the               support. A handover protocol is necessary for the
directory; as it does so, if the query is from a host not in        old and new home switches to set up such forward-
the directory, it learns the sender’s IP address to MOOSE           ing: on the arrival of a new host at a switch, that
address mapping. The ELK master can also act as a                   switch would ask all other switches (via multicast)
DHCP server, populating the ELK directory as it grants              whether any had seen this host before, identifying it
IP address leases to clients.                                       using its manufacturer-assigned MAC address, and
   The one case in which the ELK directory will not con-            would instruct such switches to redirect frames.
    ii) A broadcast ARP announcement (or “gratuitous           Such a mechanism could be deployed incrementally as
        ARP”) can be sent by the new home switch to im-        needed, with switches able to perform address rewriting
        mediately update remote ARP caches and the ELK         for hosts which are not able to do this themselves. This
        directory with the new MOOSE address. This is          is, however, a very long-term solution, and protocol-
        the technique used by Xen when migrating live vir-     specific rewriting on the switch is likely to be required
        tual machines [3]. Unlike the previous approach,       for the foreseeable future.
        this works even if the previous switch is no longer       FCoE in particular is unusual, however, as it already
        reachable, for example if this host migration was as   does its own dynamic allocation of MAC address to de-
        a result of a switch failure. This is a simpler ap-    vices. It is conceivable that an extension to FCoE could
        proach as a handover protocol is not required, but     be developed which allows a network-wide dynamic ad-
        results in additional broadcast traffic.                dress assignment scheme such as MOOSE to be ex-
   Unless the frequency of host migrations is very high,       ploited to provide addresses directly to fibre channel de-
the additional load introduced by either mobility ap-          vices.
proach is expected to be negligible.                           5.2   Edge Virtual Bridging

5      Interoperability Considerations                         The rise of virtualisation has caused an unanticipated
                                                               proliferation of software switches, usually in the host
5.1     Layer-violating Protocols                              operating system or hypervisor which provides network
In an ideal world, free from layering violations, all layer    connectivity to multiple virtual machines. Since soft-
3 protocols would operate correctly on top of MOOSE in         ware switches are almost always neither fast nor cen-
exactly the same way that they currently operate on top        trally manageable in the same way as hardware switches,
of Ethernet, with no protocol-specific handling neces-          there is ongoing work to standardise—by Cisco as Port
sary in the switch. In reality, however, protocols abound      Extension [28] and by the IEEE as P802.1Qbg [29]—a
which use hosts’ MAC addresses for purposes other than         means of making these software switches act merely as
layer 2 addressing or which place MAC addresses in the         additional ports which are logically part of a more cen-
frame payload. DHCP and ARP have already been men-             tral hardware switch. This reduces the work required
tioned as such protocols which must be specifically han-        by a virtual edge switch: frames from local virtual edge
dled by edge switches in order to operate; luckily, the        ports can be forwarded straight out via the uplink to a
rewriting required for these important protocols is sim-       physical switch without consideration, and frames from
ple.                                                           the uplink will arrive simply tagged with a virtual edge
   Of particular concern are recent standards for layering     port identifier.
on top of Ethernet protocols which were previously used           (The scope of Port Extension in particular is greater
solely on dedicated hardware interconnects, such as Fi-        than this, and allows for physical port extenders to exist
bre Channel over Ethernet (FCoE) [27]. In order to sup-        in place of switches where a large number of ports but
port FCoE and similar protocols on a MOOSE network,            a small amount of processing is required, but virtualisa-
each edge switch will need to be able to interpret and         tion is likely to be the most significant use case.)
rewrite individual protocols that are in use. A produc-           Edge Virtual Bridging and Port Extension require
tion MOOSE switch would, therefore, need to be imple-          very little adaptation to be implemented on a MOOSE
mented such that it is possible to add rewriting support       switch. It is unlikely, although too early in the standard-
for additional protocols after manufacture, for example        isation process to say for certain, that the virtual bridge
by loading an additional software or FPGA configura-            will need to be MOOSE-aware. A virtual-bridging-
tion module.                                                   aware physical MOOSE switch will thus simply need
   Ultimately, in the general case, this problem could         to take into account the possibility that one physical port
be addressed more satisfactorily by extending the Eth-         may hide a large number of virtual ports when allocating
ernet standard to provide a protocol-agnostic method           host identifiers, as it would if it had an Ethernet switch
for a layer 2 network to inform hosts of their own ad-         connected on that port. If, however, the virtual bridge
dresses; LLDP [19] would make a good basis for this ex-        is made MOOSE-aware, the hierarchical addressing of
tension. This would allow the use of network-assigned          MOOSE could be exploited to allow the virtual bridge
MAC addresses for any protocol, with some rewriting            to allocate host identifiers itself, given that it is likely to
performed either partially (within the frame payload)          be aware of the exact number and nature of virtual edge
or fully by the host itself, and furthermore would al-         ports. The parent MOOSE switch would accordingly al-
low higher-layer protocols to respond to changes of the        locate an address prefix to each child virtual bridge, and
host’s network-assigned address (e.g. due to mobility).        hosts’ full MOOSE addresses could be formed as:
      switch ID    :    child ID     :    host ID                                          Port
       (parent)         allocated        allocated
                        by parent         by child                              Forwarding database

6     Implementation                                                             Frame           Frame
                                                                                receiver      transmitter
We have implemented a MOOSE switch in threaded,
object-oriented Python as a proof-of-concept. The archi-                        Source
tecture is intended for clarity and modularity rather than                     rewriting
raw performance, but this implementation is still capa-
ble of switching data at 100 Mbps on a modern desktop                                raw sockets
                                                                               Network interface card
   Data forwarding and control functions are kept sepa-
rate for clarity and to mimic a hardware implementation.
                                                                      Figure 4: Prototype data plane architecture
6.1   Data plane                                                  nected; for example, the host identifier of the first
The software MOOSE switch is intended to be run on                host seen on port 3 will be 03:00:01.
a Linux PC with several network interface cards, and          iv) The locally-connected-host forwarding database is
uses raw sockets to send and receive frames directly              updated where necessary based upon the frame’s
in promiscuous mode, so that all frames are received              source address.
whether or not they are addressed to that PC.                  v) The frame is passed to the relevant forwarding
   Each network interface is managed by two indepen-              database, which obtains the correct destination Port
dent threads: a FrameReceiver and a FrameTransmit-                object from its internal dictionary. The frame is en-
ter. A Port object is maintained in shared memory, con-           queued with the FrameTransmitter of this port.
taining shared data structures such as a per-port for-          The only processing the FrameTransmitter performs
warding database (implemented as two Python dictio-          before sending the frames over the relevant raw socket
naries: one for locally-connected hosts and one for re-      onto the network is to rewrite the destination address to
mote switches). The relation between modules is out-         be the target host’s manufacturer-assigned MAC address
lined in figure 4.                                            if the destination switch ID is this switch’s, i.e. if that
   The FrameReceiver thread does most of the work; the       host is directly connected to this switch.
main steps performed are:                                       The use of threads for parallel transmission to and re-
  i) A received frame is immediately packaged in a           ception from each network interface makes this software
     Frame object, which provides methods for access-        design analogous to a basic hardware design, with sev-
     ing individual fields within the frame’s headers.        eral independently-operating ports interconnected by a
     Some checks are run so that unwanted frames             switch fabric. It is our eventual goal to produce a hard-
     are dropped: for example, frames whose source           ware prototype as described in section 7.
     addresses indicate that they have already passed
                                                             6.2   Control plane
     through this switch, which could be a sign of a rout-
     ing protocol malfunction or a misconfigured switch       The control plane operates largely independently of the
     elsewhere in the network with the same switch           data plane, in a separate thread, as it is much less timing-
     identifier.                                              sensitive than the data plane. In a production implemen-
 ii) If the frame is a DHCP or ARP query, it is trans-       tation, the control plane would likely run in software on
     ferred to the control plane for conversion into an      a microprocessor.
     ELK query.                                                 The main function of the control plane is to run the
iii) Once the frame has been received and checked to         routing protocol in order to determine the location of
     be valid, the source address is rewritten if it is      and best route to every other switch. This implemen-
     not already a MOOSE address. This process re-           tation uses PWOSPF [30], a simple link state routing
     quires a host identifier, which is reused or allocated   protocol based on OSPF version 2 [21], as a proof of
     as appropriate; allocated identifiers are stored in a    concept—the authentication features of OSPF are not
     Python dictionary (hash table). In this implemen-       required for a prototype implementation. A produc-
     tation, in order to allow each port to issue host       tion MOOSE switch would likely require a full-featured
     identifiers independently, each identifier starts with    OSPF implementation (or another routing protocol) to
     a byte identifying to which port this host is con-      ensure security and resilience, and in particular to pre-
Address          HWtype   HWaddress               Iface       7   Conclusions and Future Work      ether    02:00:0c:01:00:01       eth1      ether    02:00:0a:01:00:01       eth1        Ethernet remains popular due to its simplicity and ubiq-      ether    02:00:0a:03:00:01       eth1        uity, but is showing its age and exhibits serious scala-      ether    02:00:0b:02:00:01       eth1        bility issues in large deployments. Previously-proposed
                                                              improvements address either a few of the problems in a
Figure 5: ARP cache of an unmodified Linux PC connected to     simple way, or most of the problems in a highly complex
a network of MOOSE switches (02:00:0a, 02:00:0b, 02:00:0c)    or backwards-incompatible way. We have demonstrated
showing the addresses automatically assigned to other hosts   a simple, novel and easily-implementable approach for
                                                              significantly boosting the scalability of Ethernet, along
vent the unauthorised spoofing of switches by end users.       with a working software implementation.
   As PWOSPF is designed to operate on 4-byte IP                 Our next step will be to produce a true hardware
addresses rather than the 3- or 6-byte identifiers used        prototype. This will be built using the NetFPGA plat-
in MOOSE, the fields intended for IP addresses are             form [32]. The NetFPGA card comprises four gigabit
retrofitted to contain a switch identifier followed by one      Ethernet interfaces connected directly to an FPGA with
null byte of padding. Each switch handles all addresses       full control over everything from the Ethernet PHY and
starting with its switch identifier, which is equivalent to    MAC inwards, plus a PCI interface to allow frames to
each switch routing a subnet of length 24 bits.               be passed to a PC for processing in software (e.g. for
   The routing protocol calculates the shortest path to ev-   running the control plane).
ery other switch using Dijkstra’s algorithm [31]. The            We also intend to implement a more extensive set
results are used to update the remote-switch forwarding       of additional Ethernet features, including in particular
database maintained in each Port object of the local data     802.1Q VLANs and Quality-of-Service provision.
plane with the best Port on which to output frames des-
tined for each switch.                                        8   Acknowledgements
   The control plane would also be responsible for oper-
                                                              We acknowledge the support of the UK EPSRC which
ating the mobility handover protocol; however this pro-
                                                              funded this project through grant EP/D076803/1. We
tocol was unimplemented in the prototype.
                                                              are also grateful for David Simner’s invaluable secu-
                                                              rity insight, and for the countless comments and sug-
6.3   Evaluation
                                                              gestions made by him, Ian Abel, Dave Eyers, Malte
The prototype MOOSE switch was found to behave                Schwarzkopf, Laurence Aitchison and Derek Murray.
transparently to a variety of unmodified devices commu-           Useful feedback and suggestions were provided by
nicating via IP with each other and with other hosts on       several attendees of the ITC 21 First Workshop on Data
the Internet, both with physical and wireless connections     Center – Converged and Virtual Ethernet Switching.
to a network of three MOOSE switches. The only vis-
ible effect was, as intended, that hosts’ individual ARP      References
caches show MOOSE addresses, as shown in figure 5.              [1] R. M. Metcalfe and D. R. Boggs, “Ethernet: dis-
   A second test was run on a virtual network compris-             tributed packet switching for local computer net-
ing six virtual switches each connected to ten Xen virtual         works,” Commun. ACM, vol. 19, no. 7, pp. 395–
machines acting as client hosts. This allows for compar-           404, 1976.
ison with a traditional Ethernet switch (as implemented
                                                               [2] P. Barham, et al., “Xen and the art of virtualiza-
by the Linux bridging driver). The forwarding database
                                                                   tion,” in SOSP, 2003, pp. 164–177.
of each switch was inspected during a period when all
clients were actively transmitting broadcast packets. In       [3] C. Clark, et al., “Live migration of virtual ma-
the case of Ethernet, the switches’ forwarding databases           chines,” in USENIX NSDI, 2005.
each contained sixty entries. In the case of MOOSE,
                                                               [4] C. Perkins, “IP Mobility Support for IPv4,”
each switch’s two forwarding database dictionaries con-
                                                                   RFC 3344 (Proposed Standard), Aug. 2002,
tained five entries for the other switches and ten entries
                                                                   updated by RFC 4721. [Online]. Available:
for the locally-connected hosts respectively. The storage
requirement of the forwarding has been reduced from
O(hosts) to O(switches), assuming that the number of           [5] IEEE, “802.1D: Standard for local and metropoli-
locally-connected hosts is a small constant; this is a sig-        tan area networks: Media access control (MAC)
nificant improvement.                                               bridges,” 2004.
 [6] 3Com Corporation, “Switch 5500G 10/100/1000             [21] J. Moy, “OSPF Version 2,” RFC 2328 (Standard),
     family    data   sheet.”   [Online].    Avail-               Apr. 1998. [Online]. Available: http://www.ietf.
     able:               org/rfc/rfc2328.txt
     en US/400908.pdf                                        [22] C. Villamizar, “OSPF optimized multipath
 [7] F. Yu, et al., “Efficient multimatch packet classifi-          (OSPF-OMP),” IETF Internet Draft, Feb. 1999.
     cation and lookup with tcam,” IEEE Micro, vol. 25,           [Online]. Available:
     no. 1, Jan. 2005.                                            draft-ietf-ospf-omp-02
 [8] K. Pagiamtzis and A. Sheikholeslami, “Content-          [23] G. M. Schneider and T. Nemeth, “A simulation
     Addressable Memory (CAM) circuits and architec-              study of the OSPF-OMP routing algorithm,” Com-
     tures: a tutorial and survey,” IEEE Journal of Solid-        puter Networks, vol. 39, no. 4, pp. 457–468, 2002.
     State Circuits, vol. 41, pp. 712–727, 2006.
                                                             [24] C. Villamizar, R. Chandra, and R. Govindan,
 [9] D. C. Plummer, “Ethernet Address Resolution Pro-             “BGP Route Flap Damping,” RFC 2439 (Proposed
     tocol,” RFC 826 (Standard), Nov. 1982. [Online].             Standard), Nov. 1998. [Online]. Available: http:
     Available:                //
[10] R. Droms, “Dynamic Host Configuration Proto-             [25] A. Adams, J. Nicholas, and W. Siadak, “Protocol
     col,” RFC 2131 (Draft Standard), Mar. 1997,                  Independent Multicast - Dense Mode (PIM-DM):
     updated by RFCs 3396, 4361. [Online]. Available:             Protocol Specification (Revised),” RFC 3973                          (Experimental), Jan. 2005. [Online]. Available:
[11] M. Scott, A. Moore, and J. Crowcroft, “Addressing  
     the scalability of Ethernet with MOOSE,” in ITC         [26] M. Christensen, et al., “Considerations for
     21 First Workshop on Data Center – Converged                 Internet Group Management Protocol (IGMP)
     and Virtual Ethernet Switching (DC CAVES), Sep.              and Multicast Listener Discovery (MLD)
     2009.                                                        Snooping Switches,” RFC 4541 (Informa-
[12] E. Rosen, A. Viswanathan, and R. Callon, “Multi-             tional), May 2006. [Online]. Available: http:
     protocol Label Switching Architecture,” RFC                  //
     3031 (Proposed Standard), Jan. 2001. [Online].          [27] T11 FC-BB-5 working group, “Fibre channel
     Available:               backbone – 5,” Jun. 2009.
[13] I. Hadˇ i´ , “Hierarchical MAC address space in
                                                             [28] J. Pelissier, “Introduction to port extension,” in ITC
     public Ethernet networks,” in IEEE GLOBECOM,
                                                                  21 First Workshop on Data Center – Converged
     vol. 3, 2001.
                                                                  and Virtual Ethernet Switching (DC CAVES), Sep.
[14] T. Rodeheffer, C. Thekkath, and D. Anderson,                 2009.
     “SmartBridge: a scalable bridge architecture,” in
                                                             [29] A. Jeffree, P. Congdon, and J. Pelissier,
     SIGCOMM, 2000.
                                                                  “P802.1Qbg:     Edge virtual bridging,” Un-
[15] R. Perlman, “Rbridges: transparent routing,” in IN-          approved PAR, Sep. 2009. [Online]. Avail-
     FOCOM, vol. 2, 2004.                                         able:
[16] A. Myers, E. Ng, and H. Zhang, “Rethinking                   new-qbg-draft-par-0909-V2.pdf
     the service model: Scaling Ethernet to a million        [30] Stanford       University      High-Performance
     nodes,” in ACM SIGCOMM Workshop on Hot Top-                  Networking       Group,      “Pee-Wee     OSPF
     ics in Networking, Nov. 2004.                                protocol      details.”   [Online].    Available:
[17] C. Kim, M. Caesar, and J. Rexford, “Floodless      
     in SEATTLE: a scalable Ethernet architecture for             // public/docs/pwospf ref.
     large enterprises,” in SIGCOMM, 2008, pp. 3–14.              txt
[18] S. Sipes, “Why your switched network isn’t se-          [31] E. Dijkstra, “A note on two problems in connexion
     cure,” in Intrusion Detection FAQ. The SANS In-              with graphs,” Numerische Mathematik, vol. 1, pp.
     stitute, Sep. 2000. [Online]. Available: http://www.         269–271, 1959. network.php
                                                             [32] J. W. Lockwood, et al., “NetFPGA—an open plat-
[19] IEEE, “802.1AB: Station and media access control             form for gigabit-rate network switching and rout-
     connectivity discovery,” 2009.                               ing,” in IEEE MSE, 2007, pp. 160–161.
[20] ——, “802.1X: Port based network access con-
     trol,” 2004.

Shared By: