[ovs-dev] [PATCH 2/5] vtep: Initial checkin of vtep schema.
Justin Pettit
jpettit at nicira.com
Fri Oct 11 23:56:23 UTC 2013
From: Bruce Davie <bdavie at vmware.com>
The hardware VTEP OVSDB schema specifies relations that a VTEP can use
to integrate physical ports into logical switches maintained by a
network virtualization controller such as NVP.
Co-authored-by: Ben Pfaff <blp at nicira.com>
Co-authored-by: Kenneth Duda <kduda at aristanetworks.com>
Co-authored-by: Justin Pettit <jpettit at nicira.com>
Signed-off-by: Justin Pettit <jpettit at nicira.com>
---
Makefile.am | 1 +
lib/.gitignore | 3 +
lib/automake.mk | 17 +-
lib/vtep-idl.ann | 9 +
vtep/.gitignore | 4 +
vtep/automake.mk | 62 +++++
vtep/vtep.gv | 34 +++
vtep/vtep.ovsschema | 157 +++++++++++
vtep/vtep.pic | 4 +
vtep/vtep.xml | 726 +++++++++++++++++++++++++++++++++++++++++++++++++++
10 files changed, 1015 insertions(+), 2 deletions(-)
create mode 100644 lib/vtep-idl.ann
create mode 100644 vtep/.gitignore
create mode 100644 vtep/automake.mk
create mode 100644 vtep/vtep.gv
create mode 100644 vtep/vtep.ovsschema
create mode 100644 vtep/vtep.pic
create mode 100644 vtep/vtep.xml
diff --git a/Makefile.am b/Makefile.am
index 5b9e0ac..45eb3c5 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -274,3 +274,4 @@ include xenserver/automake.mk
include python/automake.mk
include python/compat/automake.mk
include tutorial/automake.mk
+include vtep/automake.mk
diff --git a/lib/.gitignore b/lib/.gitignore
index f4c59ad..31346e4 100644
--- a/lib/.gitignore
+++ b/lib/.gitignore
@@ -8,3 +8,6 @@
/vswitch-idl.c
/vswitch-idl.h
/vswitch-idl.ovsidl
+/vtep-idl.c
+/vtep-idl.h
+/vtep-idl.ovsidl
diff --git a/lib/automake.mk b/lib/automake.mk
index da390ab..8fdc162 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -229,7 +229,9 @@ lib_libopenvswitch_a_SOURCES = \
lib/vlog.c \
lib/vlog.h \
lib/vswitch-idl.c \
- lib/vswitch-idl.h
+ lib/vswitch-idl.h \
+ lib/vtep-idl.c \
+ lib/vtep-idl.h
nodist_lib_libopenvswitch_a_SOURCES = \
lib/dirs.c
@@ -334,7 +336,10 @@ MAN_FRAGMENTS += \
OVSIDL_BUILT += \
$(srcdir)/lib/vswitch-idl.c \
$(srcdir)/lib/vswitch-idl.h \
- $(srcdir)/lib/vswitch-idl.ovsidl
+ $(srcdir)/lib/vswitch-idl.ovsidl \
+ $(srcdir)/lib/vtep-idl.c \
+ $(srcdir)/lib/vtep-idl.h \
+ $(srcdir)/lib/vtep-idl.ovsidl
EXTRA_DIST += $(srcdir)/lib/vswitch-idl.ann
VSWITCH_IDL_FILES = \
@@ -344,6 +349,14 @@ $(srcdir)/lib/vswitch-idl.ovsidl: $(VSWITCH_IDL_FILES)
$(OVSDB_IDLC) annotate $(VSWITCH_IDL_FILES) > $@.tmp
mv $@.tmp $@
+EXTRA_DIST += $(srcdir)/lib/vtep-idl.ann
+VTEP_IDL_FILES = \
+ $(srcdir)/vtep/vtep.ovsschema \
+ $(srcdir)/lib/vtep-idl.ann
+$(srcdir)/lib/vtep-idl.ovsidl: $(VTEP_IDL_FILES)
+ $(OVSDB_IDLC) annotate $(VTEP_IDL_FILES) > $@.tmp
+ mv $@.tmp $@
+
lib/dirs.c: lib/dirs.c.in Makefile
($(ro_c) && sed < $(srcdir)/lib/dirs.c.in \
-e 's,[@]srcdir[@],$(srcdir),g' \
diff --git a/lib/vtep-idl.ann b/lib/vtep-idl.ann
new file mode 100644
index 0000000..5ffe585
--- /dev/null
+++ b/lib/vtep-idl.ann
@@ -0,0 +1,9 @@
+# -*- python -*-
+
+# This code, when invoked by "ovsdb-idlc annotate" (by the build
+# process), annotates vswitch.ovsschema with additional data that give
+# the ovsdb-idl engine information about the types involved, so that
+# it can generate more programmer-friendly data structures.
+
+s["idlPrefix"] = "vteprec_"
+s["idlHeader"] = "\"lib/vtep-idl.h\""
diff --git a/vtep/.gitignore b/vtep/.gitignore
new file mode 100644
index 0000000..ce890a9
--- /dev/null
+++ b/vtep/.gitignore
@@ -0,0 +1,4 @@
+/Makefile
+/Makefile.in
+/vtep.5
+/vtep.ovsschema.stamp
diff --git a/vtep/automake.mk b/vtep/automake.mk
new file mode 100644
index 0000000..aca8a7c
--- /dev/null
+++ b/vtep/automake.mk
@@ -0,0 +1,62 @@
+# VTEP schema and IDL
+EXTRA_DIST += vtep/vtep.ovsschema
+pkgdata_DATA += vtep/vtep.ovsschema
+
+# VTEP E-R diagram
+#
+# There are two complications here. First, if "python" or "dot" is not
+# available, then we have to just use the existing diagram. Second,
+# different "dot" versions produce slightly different output for the
+# same input, but we don't want to gratuitously change vtep.pic if
+# someone tweaks the schema in some minor way that doesn't affect the
+# table structure. To avoid that we store a checksum of vtep.gv in
+# vtep.pic and only regenerate vtep.pic if vtep.gv actually changes.
+$(srcdir)/vtep/vtep.gv: ovsdb/ovsdb-dot.in vtep/vtep.ovsschema
+if HAVE_PYTHON
+ $(OVSDB_DOT) --no-arrows $(srcdir)/vtep/vtep.ovsschema > $@
+else
+ touch $@
+endif
+$(srcdir)/vtep/vtep.pic: $(srcdir)/vtep/vtep.gv ovsdb/dot2pic
+if HAVE_DOT
+ sum=`cksum < $(srcdir)/vtep/vtep.gv`; \
+ if grep "$$sum" $@ >/dev/null 2>&1; then \
+ echo "vtep.gv unchanged, not regenerating vtep.pic"; \
+ touch $@; \
+ else \
+ echo "regenerating vtep.pic"; \
+ (echo ".\\\" Generated from vtep.gv with cksum \"$$sum\""; \
+ dot -T plain < $(srcdir)/vtep/vtep.gv \
+ | $(srcdir)/ovsdb/dot2pic -f 2) > $@; \
+ fi
+else
+ touch $@
+endif
+EXTRA_DIST += vtep/vtep.gv vtep/vtep.pic
+
+# VTEP schema documentation
+EXTRA_DIST += vtep/vtep.xml
+dist_man_MANS += vtep/vtep.5
+$(srcdir)/vtep/vtep.5: \
+ ovsdb/ovsdb-doc vtep/vtep.xml vtep/vtep.ovsschema \
+ $(srcdir)/vtep/vtep.pic
+ $(OVSDB_DOC) \
+ --title="vtep" \
+ --er-diagram=$(srcdir)/vtep/vtep.pic \
+ $(srcdir)/vtep/vtep.ovsschema \
+ $(srcdir)/vtep/vtep.xml > $@.tmp
+ mv $@.tmp $@
+
+# Version checking for vtep.ovsschema.
+ALL_LOCAL += vtep/vtep.ovsschema.stamp
+vtep/vtep.ovsschema.stamp: vtep/vtep.ovsschema
+ @sum=`sed '/cksum/d' $? | cksum`; \
+ expected=`sed -n 's/.*"cksum": "\(.*\)".*/\1/p' $?`; \
+ if test "X$$sum" = "X$$expected"; then \
+ touch $@; \
+ else \
+ ln=`sed -n '/"cksum":/=' $?`; \
+ echo >&2 "$?:$$ln: checksum \"$$sum\" does not match (you should probably update the version number and fix the checksum)"; \
+ exit 1; \
+ fi
+CLEANFILES += vtep/vtep.ovsschema.stamp
diff --git a/vtep/vtep.gv b/vtep/vtep.gv
new file mode 100644
index 0000000..a4569bf
--- /dev/null
+++ b/vtep/vtep.gv
@@ -0,0 +1,34 @@
+digraph hardware_vtep {
+ size="6.5,4";
+ margin="0";
+ node [shape=box];
+ edge [dir=none, arrowhead=none, arrowtail=none];
+ Mcast_Macs_Remote [style=bold];
+ Mcast_Macs_Remote -> Physical_Locator_Set [label="locator_set"];
+ Mcast_Macs_Remote -> Logical_Switch [label="logical_switch"];
+ Ucast_Macs_Local [style=bold];
+ Ucast_Macs_Local -> Physical_Locator [label="locator"];
+ Ucast_Macs_Local -> Logical_Switch [label="logical_switch"];
+ Physical_Locator [];
+ Physical_Locator_Set [];
+ Physical_Locator_Set -> Physical_Locator [label="locators+"];
+ Global [style=bold];
+ Global -> Physical_Switch [label="switches*"];
+ Global -> Manager [label="managers*"];
+ Physical_Switch [];
+ Physical_Switch -> Physical_Port [label="ports*"];
+ Logical_Router [style=bold];
+ Logical_Router -> Logical_Switch [label="switch_binding value*"];
+ Manager [];
+ Mcast_Macs_Local [style=bold];
+ Mcast_Macs_Local -> Physical_Locator_Set [label="locator_set"];
+ Mcast_Macs_Local -> Logical_Switch [label="logical_switch"];
+ Logical_Switch [style=bold];
+ Ucast_Macs_Remote [style=bold];
+ Ucast_Macs_Remote -> Physical_Locator [label="locator"];
+ Ucast_Macs_Remote -> Logical_Switch [label="logical_switch"];
+ Physical_Port [];
+ Physical_Port -> Logical_Switch [label="vlan_bindings value*"];
+ Physical_Port -> Logical_Binding_Stats [label="vlan_stats value*"];
+ Logical_Binding_Stats [];
+}
diff --git a/vtep/vtep.ovsschema b/vtep/vtep.ovsschema
new file mode 100644
index 0000000..d03d96d
--- /dev/null
+++ b/vtep/vtep.ovsschema
@@ -0,0 +1,157 @@
+{
+ "name": "hardware_vtep",
+ "cksum": "825115144 5318",
+ "tables": {
+ "Global": {
+ "columns": {
+ "managers": {
+ "type": {"key": {"type": "uuid",
+ "refTable": "Manager"},
+ "min": 0, "max": "unlimited"}},
+ "switches": {
+ "type": {"key": {"type": "uuid", "refTable": "Physical_Switch"},
+ "min": 0, "max": "unlimited"}}
+ },
+ "maxRows": 1,
+ "isRoot": true},
+ "Physical_Switch": {
+ "columns": {
+ "ports": {
+ "type": {"key": {"type": "uuid", "refTable": "Physical_Port"},
+ "min": 0, "max": "unlimited"}},
+ "name": {"type": "string"},
+ "description": {"type": "string"},
+ "management_ips": {
+ "type": {"key": {"type": "string"}, "min": 0, "max": "unlimited"}},
+ "tunnel_ips": {
+ "type": {"key": {"type": "string"}, "min": 0, "max": "unlimited"}}},
+ "indexes": [["name"]]},
+ "Physical_Port": {
+ "columns": {
+ "name": {"type": "string"},
+ "description": {"type": "string"},
+ "vlan_bindings": {
+ "type": {"key": {"type": "integer",
+ "minInteger": 0, "maxInteger": 4095},
+ "value": {"type": "uuid", "refTable": "Logical_Switch"},
+ "min": 0, "max": "unlimited"}},
+ "vlan_stats": {
+ "type": {"key": {"type": "integer",
+ "minInteger": 0, "maxInteger": 4095},
+ "value": {"type": "uuid",
+ "refTable": "Logical_Binding_Stats"},
+ "min": 0, "max": "unlimited"}}}},
+ "Logical_Binding_Stats": {
+ "columns": {
+ "bytes_from_local": {"type": "integer"},
+ "packets_from_local": {"type": "integer"},
+ "bytes_to_local": {"type": "integer"},
+ "packets_to_local": {"type": "integer"}}},
+ "Logical_Switch": {
+ "columns": {
+ "name": {"type": "string"},
+ "description": {"type": "string"},
+ "tunnel_key": {"type": {"key": "integer", "min": 0, "max": 1}}},
+ "isRoot": true,
+ "indexes": [["name"]]},
+ "Ucast_Macs_Local": {
+ "columns": {
+ "MAC": {"type": "string"},
+ "logical_switch": {
+ "type": {"key": {"type": "uuid",
+ "refTable": "Logical_Switch"}}},
+ "locator": {
+ "type": {"key": {"type": "uuid",
+ "refTable": "Physical_Locator"}}},
+ "ipaddr": {"type": "string"}},
+ "isRoot": true},
+ "Ucast_Macs_Remote": {
+ "columns": {
+ "MAC": {"type": "string"},
+ "logical_switch": {
+ "type": {"key": {"type": "uuid",
+ "refTable": "Logical_Switch"}}},
+ "locator": {
+ "type": {"key": {"type": "uuid",
+ "refTable": "Physical_Locator"}}},
+ "ipaddr": {"type": "string"}},
+ "isRoot": true},
+ "Mcast_Macs_Local": {
+ "columns": {
+ "MAC": {"type": "string"},
+ "logical_switch": {
+ "type": {"key": {"type": "uuid",
+ "refTable": "Logical_Switch"}}},
+ "locator_set": {
+ "type": {"key": {"type": "uuid",
+ "refTable": "Physical_Locator_Set"}}},
+ "ipaddr": {"type": "string"}},
+ "isRoot": true},
+ "Mcast_Macs_Remote": {
+ "columns": {
+ "MAC": {"type": "string"},
+ "logical_switch": {
+ "type": {"key": {"type": "uuid",
+ "refTable": "Logical_Switch"}}},
+ "locator_set": {
+ "type": {"key": {"type": "uuid",
+ "refTable": "Physical_Locator_Set"}}},
+ "ipaddr": {"type": "string"}},
+ "isRoot": true},
+ "Logical_Router": {
+ "columns": {
+ "name": {"type": "string"},
+ "description": {"type": "string"},
+ "switch_binding": {
+ "type": {"key": {"type": "string"},
+ "value": {"type": "uuid",
+ "refTable": "Logical_Switch"},
+ "min": 0, "max": "unlimited"}},
+ "static_routes": {
+ "type": {"key": {"type": "string"},
+ "value": {"type" : "string"},
+ "min": 0, "max": "unlimited"}}},
+ "isRoot": true,
+ "indexes": [["name"]]},
+ "Physical_Locator_Set": {
+ "columns": {
+ "locators": {
+ "type": {"key": {"type": "uuid", "refTable": "Physical_Locator"},
+ "min": 1, "max": "unlimited"},
+ "mutable": false}}},
+ "Physical_Locator": {
+ "columns": {
+ "encapsulation_type": {
+ "type": {
+ "key": {
+ "enum": ["set", ["vxlan_over_ipv4"]],
+ "type": "string"}},
+ "mutable": false},
+ "dst_ip": {"type": "string", "mutable": false},
+ "bfd": {
+ "type": {"key": "string", "value": "string",
+ "min": 0, "max": "unlimited"}},
+ "bfd_status": {
+ "type": {"key": "string", "value": "string",
+ "min": 0, "max": "unlimited"}}},
+ "indexes": [["encapsulation_type", "dst_ip"]]},
+ "Manager": {
+ "columns": {
+ "target": {"type": "string"},
+ "max_backoff": {
+ "type": {"key": {"type": "integer",
+ "minInteger": 1000},
+ "min": 0, "max": 1}},
+ "inactivity_probe": {
+ "type": {"key": "integer", "min": 0, "max": 1}},
+ "other_config": {
+ "type": {"key": "string", "value": "string", "min": 0, "max": "unlimited"}},
+ "is_connected": {
+ "type": "boolean",
+ "ephemeral": true},
+ "status": {
+ "type": {"key": "string", "value": "string", "min": 0, "max": "unlimited"},
+ "ephemeral": true}},
+ "indexes": [["target"]],
+ "isRoot": false}},
+ "version": "1.0.0"}
diff --git a/vtep/vtep.pic b/vtep/vtep.pic
new file mode 100644
index 0000000..654b70c
--- /dev/null
+++ b/vtep/vtep.pic
@@ -0,0 +1,4 @@
+.\" Generated from vtep.gv with cksum "401186207 1363"
+.PS
+linethick = 1;
+.PE
diff --git a/vtep/vtep.xml b/vtep/vtep.xml
new file mode 100644
index 0000000..4fc2609
--- /dev/null
+++ b/vtep/vtep.xml
@@ -0,0 +1,726 @@
+<?xml version="1.0" encoding="utf-8"?>
+<database title="Hardware VTEP Database">
+ <p>
+ This schema specifies relations that a VTEP can use to integrate
+ physical ports into logical switches maintained by a network
+ virtualization controller such as NVP.
+ </p>
+
+ <p>Glossary:</p>
+
+ <dl>
+ <dt>VTEP</dt>
+ <dd>
+ VXLAN Tunnel End Point, an entity which originates and/or terminates
+ VXLAN tunnels.
+ </dd>
+
+ <dt>HSC</dt>
+ <dd>
+ Hardware Switch Controller.
+ </dd>
+
+ <dt>NVC</dt>
+ <dd>
+ Network Virtualization Controller, e.g. NVP.
+ </dd>
+
+ <dt>VRF</dt>
+ <dd>
+ Virtual Routing and Forwarding instance.
+ </dd>
+ </dl>
+
+ <table name="Global" title="Top-level configuration.">
+ Top-level configuration for a hardware VTEP. There must be
+ exactly one record in the <ref table="Global"/> table.
+
+ <column name="switches">
+ The physical switches managed by the VTEP.
+ </column>
+
+ <group title="Database Configuration">
+ <p>
+ These columns primarily configure the Open vSwitch database
+ (<code>ovsdb-server</code>), not the hardware VTEP itself.
+ </p>
+
+ <column name="managers">
+ Database clients to which the Open vSwitch database server should
+ connect or to which it should listen, along with options for how these
+ connection should be configured. See the <ref table="Manager"/> table
+ for more information.
+ </column>
+ </group>
+ </table>
+
+ <table name="Manager" title="OVSDB management connection.">
+ <p>
+ Configuration for a database connection to an Open vSwitch database
+ (OVSDB) client.
+ </p>
+
+ <p>
+ The Open vSwitch database server can initiate and maintain active
+ connections to remote clients. It can also listen for database
+ connections.
+ </p>
+
+ <group title="Core Features">
+ <column name="target">
+ <p>Connection method for managers.</p>
+ <p>
+ The following connection methods are currently supported:
+ </p>
+ <dl>
+ <dt><code>ssl:<var>ip</var></code>[<code>:<var>port</var></code>]</dt>
+ <dd>
+ <p>
+ The specified SSL <var>port</var> (default: 6632) on the host at
+ the given <var>ip</var>, which must be expressed as an IP address
+ (not a DNS name).
+ </p>
+ <p>
+ SSL key and certificate configuration happens outside the
+ database.
+ </p>
+ </dd>
+
+ <dt><code>tcp:<var>ip</var></code>[<code>:<var>port</var></code>]</dt>
+ <dd>
+ The specified TCP <var>port</var> (default: 6632) on the host at
+ the given <var>ip</var>, which must be expressed as an IP address
+ (not a DNS name).
+ </dd>
+ <dt><code>pssl:</code>[<var>port</var>][<code>:<var>ip</var></code>]</dt>
+ <dd>
+ <p>
+ Listens for SSL connections on the specified TCP <var>port</var>
+ (default: 6632). If <var>ip</var>, which must be expressed as an
+ IP address (not a DNS name), is specified, then connections are
+ restricted to the specified local IP address.
+ </p>
+ </dd>
+ <dt><code>ptcp:</code>[<var>port</var>][<code>:<var>ip</var></code>]</dt>
+ <dd>
+ Listens for connections on the specified TCP <var>port</var>
+ (default: 6632). If <var>ip</var>, which must be expressed as an
+ IP address (not a DNS name), is specified, then connections are
+ restricted to the specified local IP address.
+ </dd>
+ </dl>
+ </column>
+ </group>
+
+ <group title="Client Failure Detection and Handling">
+ <column name="max_backoff">
+ Maximum number of milliseconds to wait between connection attempts.
+ Default is implementation-specific.
+ </column>
+
+ <column name="inactivity_probe">
+ Maximum number of milliseconds of idle time on connection to the client
+ before sending an inactivity probe message. If Open vSwitch does not
+ communicate with the client for the specified number of seconds, it
+ will send a probe. If a response is not received for the same
+ additional amount of time, Open vSwitch assumes the connection has been
+ broken and attempts to reconnect. Default is implementation-specific.
+ A value of 0 disables inactivity probes.
+ </column>
+ </group>
+
+ <group title="Status">
+ <column name="is_connected">
+ <code>true</code> if currently connected to this manager,
+ <code>false</code> otherwise.
+ </column>
+
+ <column name="status" key="last_error">
+ A human-readable description of the last error on the connection
+ to the manager; i.e. <code>strerror(errno)</code>. This key
+ will exist only if an error has occurred.
+ </column>
+
+ <column name="status" key="state"
+ type='{"type": "string", "enum": ["set", ["VOID", "BACKOFF", "CONNECTING", "ACTIVE", "IDLE"]]}'>
+ <p>
+ The state of the connection to the manager:
+ </p>
+ <dl>
+ <dt><code>VOID</code></dt>
+ <dd>Connection is disabled.</dd>
+
+ <dt><code>BACKOFF</code></dt>
+ <dd>Attempting to reconnect at an increasing period.</dd>
+
+ <dt><code>CONNECTING</code></dt>
+ <dd>Attempting to connect.</dd>
+
+ <dt><code>ACTIVE</code></dt>
+ <dd>Connected, remote host responsive.</dd>
+
+ <dt><code>IDLE</code></dt>
+ <dd>Connection is idle. Waiting for response to keep-alive.</dd>
+ </dl>
+ <p>
+ These values may change in the future. They are provided only for
+ human consumption.
+ </p>
+ </column>
+
+ <column name="status" key="sec_since_connect"
+ type='{"type": "integer", "minInteger": 0}'>
+ The amount of time since this manager last successfully connected
+ to the database (in seconds). Value is empty if manager has never
+ successfully connected.
+ </column>
+
+ <column name="status" key="sec_since_disconnect"
+ type='{"type": "integer", "minInteger": 0}'>
+ The amount of time since this manager last disconnected from the
+ database (in seconds). Value is empty if manager has never
+ disconnected.
+ </column>
+
+ <column name="status" key="locks_held">
+ Space-separated list of the names of OVSDB locks that the connection
+ holds. Omitted if the connection does not hold any locks.
+ </column>
+
+ <column name="status" key="locks_waiting">
+ Space-separated list of the names of OVSDB locks that the connection is
+ currently waiting to acquire. Omitted if the connection is not waiting
+ for any locks.
+ </column>
+
+ <column name="status" key="locks_lost">
+ Space-separated list of the names of OVSDB locks that the connection
+ has had stolen by another OVSDB client. Omitted if no locks have been
+ stolen from this connection.
+ </column>
+
+ <column name="status" key="n_connections"
+ type='{"type": "integer", "minInteger": 2}'>
+ <p>
+ When <ref column="target"/> specifies a connection method that
+ listens for inbound connections (e.g. <code>ptcp:</code> or
+ <code>pssl:</code>) and more than one connection is actually active,
+ the value is the number of active connections. Otherwise, this
+ key-value pair is omitted.
+ </p>
+ <p>
+ When multiple connections are active, status columns and key-value
+ pairs (other than this one) report the status of one arbitrarily
+ chosen connection.
+ </p>
+ </column>
+ </group>
+
+ <group title="Connection Parameters">
+ <p>
+ Additional configuration for a connection between the manager
+ and the Open vSwitch Database.
+ </p>
+
+ <column name="other_config" key="dscp"
+ type='{"type": "integer"}'>
+ The Differentiated Service Code Point (DSCP) is specified using 6 bits
+ in the Type of Service (TOS) field in the IP header. DSCP provides a
+ mechanism to classify the network traffic and provide Quality of
+ Service (QoS) on IP networks.
+
+ The DSCP value specified here is used when establishing the connection
+ between the manager and the Open vSwitch. If no value is specified, a
+ default value of 48 is chosen. Valid DSCP values must be in the range
+ 0 to 63.
+ </column>
+ </group>
+ </table>
+
+ <table name="Physical_Switch" title="A physical switch.">
+ A physical switch that implements a VTEP.
+
+ <column name="ports">
+ The physical ports within the switch.
+ </column>
+
+ <group title="Network Status">
+ <column name="management_ips">
+ IPv4 or IPv6 addresses at which the switch may be contacted
+ for management purposes.
+ </column>
+
+ <column name="tunnel_ips">
+ <p>
+ IPv4 or IPv6 addresses on which the switch may originate or
+ terminate tunnels.
+ </p>
+
+ <p>
+ This column is intended to allow a <ref table="Manager"/> to
+ determine the <ref table="Physical_Switch"/> that terminates
+ the tunnel represented by a <ref table="Physical_Locator"/>.
+ </p>
+ </column>
+ </group>
+
+ <group title="Identification">
+ <column name="name">
+ Symbolic name for the switch, such as its hostname.
+ </column>
+
+ <column name="description">
+ An extended description for the switch, such as its switch login
+ banner.
+ </column>
+ </group>
+ </table>
+
+ <table name="Physical_Port" title="A port within a physical switch.">
+ A port within a <ref table="Physical_Switch"/>.
+
+ <column name="vlan_bindings">
+ Identifies how VLANs on the physical port are bound to logical switches.
+ If, for example, the map contains a (VLAN, logical switch) pair, a packet
+ that arrives on the port in the VLAN is considered to belong to the
+ paired logical switch.
+ </column>
+
+ <column name="vlan_stats">
+ Statistics for VLANs bound to logical switches on the physical port. An
+ implementation that fully supports such statistics would populate this
+ column with a mapping for every VLAN that is bound in <ref
+ column="vlan_bindings"/>. An implementation that does not support such
+ statistics or only partially supports them would not populate this column
+ or partially populate it, respectively.
+ </column>
+
+ <group title="Identification">
+ <column name="name">
+ Symbolic name for the port. The name ought to be unique within a given
+ <ref table="Physical_Switch"/>, but the database is not capable of
+ enforcing this.
+ </column>
+
+ <column name="description">
+ An extended description for the port.
+ </column>
+ </group>
+ </table>
+
+ <table name="Logical_Binding_Stats" title="Statistics for a VLAN on a physical port bound to a logical network.">
+ Reports statistics for the <ref table="Logical_Switch"/> with which a VLAN
+ on a <ref table="Physical_Port"/> is associated.
+
+ <group title="Statistics">
+ These statistics count only packets to which the binding applies.
+
+ <column name="packets_from_local">
+ Number of packets sent by the <ref table="Physical_Switch"/>.
+ </column>
+
+ <column name="bytes_from_local">
+ Number of bytes in packets sent by the <ref table="Physical_Switch"/>.
+ </column>
+
+ <column name="packets_to_local">
+ Number of packets received by the <ref table="Physical_Switch"/>.
+ </column>
+
+ <column name="bytes_to_local">
+ Number of bytes in packets received by the <ref
+ table="Physical_Switch"/>.
+ </column>
+ </group>
+ </table>
+
+ <table name="Logical_Switch" title="A layer-2 domain.">
+ 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.
+
+
+
+ <group title="Per Logical-Switch Tunnel Key">
+ <p>
+ 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:
+ </p>
+
+ <ul>
+ <li>
+ <p>
+ Per <ref table="Logical_Switch"/>+<ref table="Physical_Locator"/>
+ pair. That is, each logical switch may be assigned a different
+ tunnel key on every <ref table="Physical_Locator"/>. This model is
+ especially flexible.
+ </p>
+
+ <p>
+ In this model, <ref table="Physical_Locator"/> carries the tunnel
+ key. Therefore, one <ref table="Physical_Locator"/> record will
+ exist for each logical switch carried at a given IP destination.
+ </p>
+ </li>
+
+ <li>
+ <p>
+ Per <ref table="Logical_Switch"/>. That is, every tunnel
+ associated with a particular logical switch carries the same tunnel
+ key, regardless of the <ref table="Physical_Locator"/> to which the
+ tunnel is addressed. This model may ease switch implementation
+ because it imposes fewer requirements on the hardware datapath.
+ </p>
+
+ <p>
+ In this model, <ref table="Logical_Switch"/> carries the tunnel
+ key. Therefore, one <ref table="Physical_Locator"/> record will
+ exist for each IP destination.
+ </p>
+ </li>
+ </ul>
+
+ <column name="tunnel_key">
+ <p>
+ This column is used only in the tunnel key per <ref
+ table="Logical_Switch"/> model (see above), because only in that
+ model is there a tunnel key associated with a logical switch.
+ </p>
+
+ <p>
+ For <code>vxlan_over_ipv4</code> encapsulation, this column
+ is the VXLAN VNI that identifies a logical switch. It must
+ be in the range 0 to 16,777,215.
+ </p>
+ </column>
+ </group>
+
+ <group title="Identification">
+ <column name="name">
+ Symbolic name for the logical switch.
+ </column>
+
+ <column name="description">
+ An extended description for the logical switch, such as its switch
+ login banner.
+ </column>
+ </group>
+ </table>
+
+ <table name="Ucast_Macs_Local" title="Unicast MACs (local)">
+ <p>
+ Mapping of unicast MAC addresses to tunnels (physical
+ locators). This table is written by the HSC, so it contains the
+ MAC addresses that have been learned on physical ports by a
+ VTEP.
+ </p>
+
+ <column name="MAC">
+ A MAC address that has been learned by the VTEP.
+ </column>
+
+ <column name="logical_switch">
+ The Logical switch to which this mapping applies.
+ </column>
+
+ <column name="locator">
+ The physical locator to be used to reach this MAC address. In
+ this table, the physical locator will be one of the tunnel IP
+ addresses of the appropriate VTEP.
+ </column>
+
+ <column name="ipaddr">
+ The IP address to which this MAC corresponds. Optional field for
+ the purpose of ARP supression.
+ </column>
+
+ </table>
+
+ <table name="Ucast_Macs_Remote" title="Unicast MACs (remote)">
+ <p>
+ Mapping of unicast MAC addresses to tunnels (physical
+ locators). This table is written by the NVC, so it contains the
+ MAC addresses that the NVC has learned. These include VM MAC
+ addresses, in which case the physical locators will be
+ hypervisor IP addresses. The NVC will also report MACs that it
+ has learned from other HSCs in the network, in which case the
+ physical locators will be tunnel IP addresses of the
+ corresponding VTEPs.
+ </p>
+
+ <column name="MAC">
+ A MAC address that has been learned by the NSC.
+ </column>
+
+ <column name="logical_switch">
+ The Logical switch to which this mapping applies.
+ </column>
+
+ <column name="locator">
+ The physical locator to be used to reach this MAC address. In
+ this table, the physical locator will be either a hypervisor IP
+ address or a tunnel IP addresses of another VTEP.
+ </column>
+
+ <column name="ipaddr">
+ The IP address to which this MAC corresponds. Optional field for
+ the purpose of ARP supression.
+ </column>
+
+ </table>
+
+ <table name="Mcast_Macs_Local" title="Multicast MACs (local)">
+ <p>
+ Mapping of multicast MAC addresses to tunnels (physical
+ locators). This table is written by the HSC, so it contains the
+ MAC addresses that have been learned on physical ports by a
+ VTEP. These may be learned by IGMP snooping, for example. This
+ table also specifies how to handle unknown unicast and broadcast packets.
+ </p>
+
+ <column name="MAC">
+ <p>
+ A MAC address that has been learned by the VTEP.
+ </p>
+ <p>
+ The keyword <code>unknown-dst</code> is used as a special
+ ``Ethernet address'' that indicates the locations to which
+ packets in a logical switch whose destination addresses do not
+ otherwise appear in <ref table="Ucast_Macs_Local"/> (for
+ unicast addresses) or <ref table="Mcast_Macs_Local"/> (for
+ multicast addresses) should be sent.
+ </p>
+ </column>
+
+ <column name="logical_switch">
+ The Logical switch to which this mapping applies.
+ </column>
+
+ <column name="locator_set">
+ The physical locator set to be used to reach this MAC address. In
+ this table, the physical locator set will be contain one or more tunnel IP
+ addresses of the appropriate VTEP(s).
+ </column>
+
+ </table>
+
+ <table name="Mcast_Macs_Remote" title="Multicast MACs (remote)">
+ <p>
+ Mapping of multicast MAC addresses to tunnels (physical
+ locators). This table is written by the NVC, so it contains the
+ MAC addresses that the NVC has learned. This
+ table also specifies how to handle unknown unicast and broadcast
+ packets.
+ </p>
+ <p>
+ Multicast packet replication may be handled by a service node,
+ in which case the physical locators will be IP addresses of
+ service nodes. If the VTEP supports replication onto multiple
+ tunnels, then this may be used to replicate directly onto
+ VTEP-hyperisor tunnels.
+ </p>
+
+ <column name="MAC">
+ <p>
+ A MAC address that has been learned by the NSC.
+ </p>
+ <p>
+ The keyword <code>unknown-dst</code> is used as a special
+ ``Ethernet address'' that indicates the locations to which
+ packets in a logical switch whose destination addresses do not
+ otherwise appear in <ref table="Ucast_Macs_Remote"/> (for
+ unicast addresses) or <ref table="Mcast_Macs_Remote"/> (for
+ multicast addresses) should be sent.
+ </p>
+ </column>
+
+ <column name="logical_switch">
+ The Logical switch to which this mapping applies.
+ </column>
+
+ <column name="locator_set">
+ The physical locator set to be used to reach this MAC address. In
+ this table, the physical locator set will be either a service node IP
+ address or a set of tunnel IP addresses of hypervisors (and
+ potentially other VTEPs).
+ </column>
+
+ <column name="ipaddr">
+ The IP address to which this MAC corresponds. Optional field for
+ the purpose of ARP supression.
+ </column>
+
+ </table>
+
+ <table name="Logical_Router" title="A logical L3 router.">
+ <p>
+ A logical router, or VRF. A logical router may be connected to one or more
+ logical switches. Subnet addresses and interface addresses may be configured on the
+ interfaces.
+ </p>
+
+ <column name="switch_binding">
+ Maps from an IPv4 or IPv6 address prefix in CIDR notation to a
+ logical switch. Multiple prefixes may map to the same switch. By
+ writing a 32-bit (or 128-bit for v6) address with a /N prefix
+ length, both the router's interface address and the subnet
+ prefix can be configured. For example, 192.68.1.1/24 creates a
+ /24 subnet for the logical switch attached to the interface and
+ assigns the address 192.68.1.1 to the router interface.
+ </column>
+
+ <column name="static_routes">
+ One or more static routes, mapping IP prefixes to next hop IP addresses.
+ </column>
+
+ <group title="Identification">
+ <column name="name">
+ Symbolic name for the logical router.
+ </column>
+
+ <column name="description">
+ An extended description for the logical router.
+ </column>
+ </group>
+ </table>
+
+ <table name="Physical_Locator_Set">
+ <p>
+ A set of one or more <ref table="Physical_Locator"/>s.
+ </p>
+
+ <p>
+ This table exists only because OVSDB does not have a way to
+ express the type ``map from string to one or more <ref
+ table="Physical_Locator"/> records.''
+ </p>
+
+ <column name="locators"/>
+ </table>
+
+ <table name="Physical_Locator">
+ <p>
+ Identifies an endpoint to which logical switch traffic may be
+ encapsulated and forwarded.
+ </p>
+
+ <p>
+ For the <code>vxlan_over_ipv4</code> encapsulation, the only
+ encapsulation defined so far, all endpoints associated with a given <ref
+ table="Logical_Switch"/> must use a common tunnel key, which is carried
+ in the <ref table="Logical_Switch" column="tunnel_key"/> column of <ref
+ table="Logical_Switch"/>.
+ </p>
+
+ <p>
+ For some encapsulations yet to be defined, we expect <ref
+ table="Physical_Locator"/> to identify both an endpoint and a tunnel key.
+ When the first such encapsulation is defined, we expect to add a
+ ``tunnel_key'' column to <ref table="Physical_Locator"/> to allow the
+ tunnel key to be defined.
+ </p>
+
+ <p>
+ See the ``Per Logical-Switch Tunnel Key'' section in the <ref
+ table="Logical_Switch"/> table for further discussion of the model.
+ </p>
+
+ <column name="encapsulation_type">
+ The type of tunneling encapsulation.
+ </column>
+
+ <column name="dst_ip">
+ <p>
+ For <code>vxlan_over_ipv4</code> encapsulation, the IPv4 address of the
+ VXLAN tunnel endpoint.
+ </p>
+
+ <p>
+ We expect that this column could be used for IPv4 or IPv6 addresses in
+ encapsulations to be introduced later.
+ </p>
+ </column>
+ <group title="Bidirectional Forwarding Detection (BFD)">
+ <p>
+ BFD, defined in RFC 5880, allows point to point detection of
+ connectivity failures by occasional transmission of BFD control
+ messages. It is implemented in Open vSwitch to serve as a more
+ popular and standards compliant alternative to CFM.
+ </p>
+
+ <p>
+ BFD operates by regularly transmitting BFD control messages at a
+ rate negotiated independently in each direction. Each endpoint
+ specifies the rate at which it expects to receive control messages,
+ and the rate at which it's willing to transmit them. An endpoint
+ which fails to receive BFD control messages for a period of three
+ times the expected reception rate, will signal a connectivity
+ fault. In the case of a unidirectional connectivity issue, the
+ system not receiving BFD control messages will signal the problem
+ to its peer in the messages is transmists.
+ </p>
+
+ <p>
+ The Open vSwitch implementation of BFD aims comply faithfully with
+ the requirements put forth in RFC 5880. Currently, the only known
+ omission is "Demand Mode", which we hope to include in future.
+ Open vSwitch does not implement the optional Authentication or
+ "Echo Mode" features.
+ </p>
+
+ <column name="bfd" key="min_rx">
+ The minimum rate, in milliseconds, at which this BFD session is
+ willing to receive BFD control messages. The actual rate may slower
+ if the remote endpoint isn't willing to transmit as quickly as
+ specified. Defaults to <code>1000</code>.
+ </column>
+
+ <column name="bfd" key="min_tx">
+ The minimum rate, in milliseconds, at which this BFD session is
+ willing to transmit BFD control messages. The actual rate may be
+ slower if the remote endpoint isn't willing to receive as quickly as
+ specified. Defaults to <code>100</code>.
+ </column>
+
+ <column name="bfd" key="cpath_down">
+ Concatenated path down may be used when the local system should not
+ have traffic forwarded to it for some reason other than a connectivty
+ failure on the interface being monitored. The local BFD session will
+ notify the remote session of the connectivity problem, at which time
+ the remote session may choose not to forward traffic. Defaults to
+ <code>false</code>.
+ </column>
+
+ <column name="bfd_status" key="state">
+ State of the BFD session. One of <code>ADMIN_DOWN</code>,
+ <code>DOWN</code>, <code>INIT</code>, or <code>UP</code>.
+ </column>
+
+ <column name="bfd_status" key="forwarding">
+ True if the BFD session believes this <ref table="Physical_Locator"/> may be
+ used to forward traffic. Typically this means the local session is
+ up, and the remote system isn't signalling a problem such as
+ concatenated path down.
+ </column>
+
+ <column name="bfd_status" key="diagnostic">
+ A short message indicating what the BFD session thinks is wrong in
+ case of a problem.
+ </column>
+
+ <column name="bfd_status" key="remote state">
+ State of the remote endpoint's BFD session.
+ </column>
+
+ <column name="bfd_status" key="remote diagnostic">
+ A short message indicating what the remote endpoint's BFD session
+ thinks is wrong in case of a problem.
+ </column>
+ </group>
+ </table>
+
+</database>
--
1.7.5.4
More information about the dev
mailing list