A logical Ethernet switch, whose implementation may span physical
and virtual media, possibly crossing L3 domains via tunnels; a
logical layer-2 domain; an Ethernet broadcast domain.
Summary:
Per Logical-Switch Tunnel Key:
tunnel_key optional integer
Replication Mode:
replication_mode optional string, either
service_node or source_node
Identification:
name string (must be unique within
table)
description string
Common Column:
other_config map of string-string pairs
Details:
Per Logical-Switch Tunnel Key:
Tunnel protocols tend to have a field that allows the tunnel to
be partitioned into sub-tunnels: VXLAN has a VNI, GRE and STT
have a key, CAPWAP has a WSI, and so on. We call these
generically ``tunnel keys.'' Given that one needs to use a tunnel
key at all, there are at least two reasonable ways to assign
their values:
• Per Logical_Switch+Physical_Locator pair. That is,
each logical switch may be assigned a different
tunnel key on every Physical_Locator. This model is
especially flexible.
In this model, Physical_Locator carries the tunnel
key. Therefore, one Physical_Locator record will
exist for each logical switch carried at a given IP
destination.
• Per Logical_Switch. That is, every tunnel
associated with a particular logical switch carries
the same tunnel key, regardless of the
Physical_Locator to which the tunnel is addressed.
This model may ease switch implementation because
it imposes fewer requirements on the hardware
datapath.
In this model, Logical_Switch carries the tunnel
key. Therefore, one Physical_Locator record will
exist for each IP destination.
tunnel_key: optional integer
This column is used only in the tunnel key per
Logical_Switch model (see above), because only in that
model is there a tunnel key associated with a logical
switch.
For vxlan_over_ipv4 encapsulation, when the tunnel key per
Logical_Switch model is in use, this column is the VXLAN
VNI that identifies a logical switch. It must be in the
range 0 to 16,777,215.
Replication Mode:
For handling L2 broadcast, multicast and unknown unicast traffic,
packets can be sent to all members of a logical switch referenced
by a physical switch. There are different modes to replicate the
packets. The default mode of replication is to send the traffic
to a service node, which can be a hypervisor, server or
appliance, and let the service node handle replication to other
transport nodes (hypervisors or other VTEP physical switches).
This mode is called service node replication. An alternate mode
of replication, called source node replication involves the
source node sending to all other transport nodes. Hypervisors are
always responsible for doing their own replication for locally
attached VMs in both modes. Service node replication mode is the
default and considered a basic requirement because it only
requires sending the packet to a single transport node.
replication_mode: optional string, either service_node or
source_node
This optional column defines the replication mode per
Logical_Switch. There are 2 valid values, service_node and
source_node. If the column is not set, the replication
mode defaults to service_node.
Identification:
name: string (must be unique within table)
Symbolic name for the logical switch.
description: string
An extended description for the logical switch, such as
its switch login banner.
Common Column:
The overall purpose of this column is described under Common
Column at the beginning of this document.
other_config: map of string-string pairs
