vtep/vtep.xml

   1 <?xml version="1.0" encoding="utf-8"?>
   2 <database name="vtep" title="Hardware VTEP Database">
   3   <p>
   4     This schema specifies relations that a VTEP can use to integrate
   5     physical ports into logical switches maintained by a network
   6     virtualization controller such as NSX.
   7   </p>
   8
   9   <p>Glossary:</p>
  10
  11   <dl>
  12     <dt>VTEP</dt>
  13     <dd>
  14       VXLAN Tunnel End Point, an entity which originates and/or terminates
  15       VXLAN tunnels.
  16     </dd>
  17
  18     <dt>HSC</dt>
  19     <dd>
  20       Hardware Switch Controller.
  21     </dd>
  22
  23     <dt>NVC</dt>
  24     <dd>
  25       Network Virtualization Controller, e.g. NSX.
  26     </dd>
  27
  28     <dt>VRF</dt>
  29     <dd>
  30       Virtual Routing and Forwarding instance.
  31     </dd>
  32  </dl>
  33
  34   <table name="Global" title="Top-level configuration.">
  35     Top-level configuration for a hardware VTEP.  There must be
  36     exactly one record in the <ref table="Global"/> table.
  37
  38     <column name="switches">
  39       <p>
  40         The physical switch or switches managed by the VTEP.
  41       </p>
  42
  43       <p>
  44         When a physical switch integrates support for this VTEP schema, which
  45         is expected to be the most common case, this column should point to one
  46         <ref table="Physical_Switch"/> record that represents the switch
  47         itself.  In another possible implementation, a server or a VM presents
  48         a VTEP schema front-end interface to one or more physical switches,
  49         presumably communicating with those physical switches over a
  50         proprietary protocol.  In that case, this column would point to one
  51         <ref table="Physical_Switch"/> for each physical switch, and the set
  52         might change over time as the front-end server comes to represent a
  53         differing set of switches.
  54       </p>
  55     </column>
  56
  57     <group title="Database Configuration">
  58       <p>
  59         These columns primarily configure the database server
  60         (<code>ovsdb-server</code>), not the hardware VTEP itself.
  61       </p>
  62
  63       <column name="managers">
  64         Database clients to which the database server should connect or
  65         to which it should listen, along with options for how these
  66         connection should be configured.  See the <ref table="Manager"/>
  67         table for more information.
  68       </column>
  69     </group>
  70   </table>
  71
  72   <table name="Manager" title="OVSDB management connection.">
  73     <p>
  74       Configuration for a database connection to an Open vSwitch Database
  75       (OVSDB) client.
  76     </p>
  77
  78     <p>
  79       The database server can initiate and maintain active connections
  80       to remote clients.  It can also listen for database connections.
  81     </p>
  82
  83     <group title="Core Features">
  84       <column name="target">
  85         <p>Connection method for managers.</p>
  86         <p>
  87           The following connection methods are currently supported:
  88         </p>
  89         <dl>
  90           <dt><code>ssl:<var>ip</var></code>[<code>:<var>port</var></code>]</dt>
  91           <dd>
  92             <p>
  93               The specified SSL <var>port</var> (default: 6640) on the host at
  94               the given <var>ip</var>, which must be expressed as an IP address
  95               (not a DNS name).
  96             </p>
  97             <p>
  98               SSL key and certificate configuration happens outside the
  99               database.
 100             </p>
 101           </dd>
 102
 103           <dt><code>tcp:<var>ip</var></code>[<code>:<var>port</var></code>]</dt>
 104           <dd>
 105             The specified TCP <var>port</var> (default: 6640) on the host at
 106             the given <var>ip</var>, which must be expressed as an IP address
 107             (not a DNS name).
 108           </dd>
 109           <dt><code>pssl:</code>[<var>port</var>][<code>:<var>ip</var></code>]</dt>
 110           <dd>
 111             <p>
 112               Listens for SSL connections on the specified TCP <var>port</var>
 113               (default: 6640).  If <var>ip</var>, which must be expressed as an
 114               IP address (not a DNS name), is specified, then connections are
 115               restricted to the specified local IP address.
 116             </p>
 117           </dd>
 118           <dt><code>ptcp:</code>[<var>port</var>][<code>:<var>ip</var></code>]</dt>
 119           <dd>
 120             Listens for connections on the specified TCP <var>port</var>
 121             (default: 6640).  If <var>ip</var>, which must be expressed as an
 122             IP address (not a DNS name), is specified, then connections are
 123             restricted to the specified local IP address.
 124           </dd>
 125         </dl>
 126       </column>
 127     </group>
 128
 129     <group title="Client Failure Detection and Handling">
 130       <column name="max_backoff">
 131         Maximum number of milliseconds to wait between connection attempts.
 132         Default is implementation-specific.
 133       </column>
 134
 135       <column name="inactivity_probe">
 136         Maximum number of milliseconds of idle time on connection to the
 137         client before sending an inactivity probe message.  If the Open
 138         vSwitch database does not communicate with the client for the
 139         specified number of seconds, it will send a probe.  If a
 140         response is not received for the same additional amount of time,
 141         the database server assumes the connection has been broken
 142         and attempts to reconnect.  Default is implementation-specific.
 143         A value of 0 disables inactivity probes.
 144       </column>
 145     </group>
 146
 147     <group title="Status">
 148       <column name="is_connected">
 149         <code>true</code> if currently connected to this manager,
 150         <code>false</code> otherwise.
 151       </column>
 152
 153       <column name="status" key="last_error">
 154         A human-readable description of the last error on the connection
 155         to the manager; i.e. <code>strerror(errno)</code>.  This key
 156         will exist only if an error has occurred.
 157       </column>
 158
 159       <column name="status" key="state"
 160               type='{"type": "string", "enum": ["set", ["VOID", "BACKOFF", "CONNECTING", "ACTIVE", "IDLE"]]}'>
 161         <p>
 162           The state of the connection to the manager:
 163         </p>
 164         <dl>
 165           <dt><code>VOID</code></dt>
 166           <dd>Connection is disabled.</dd>
 167
 168           <dt><code>BACKOFF</code></dt>
 169           <dd>Attempting to reconnect at an increasing period.</dd>
 170
 171           <dt><code>CONNECTING</code></dt>
 172           <dd>Attempting to connect.</dd>
 173
 174           <dt><code>ACTIVE</code></dt>
 175           <dd>Connected, remote host responsive.</dd>
 176
 177           <dt><code>IDLE</code></dt>
 178           <dd>Connection is idle.  Waiting for response to keep-alive.</dd>
 179         </dl>
 180         <p>
 181           These values may change in the future.  They are provided only for
 182           human consumption.
 183         </p>
 184       </column>
 185
 186       <column name="status" key="sec_since_connect"
 187               type='{"type": "integer", "minInteger": 0}'>
 188         The amount of time since this manager last successfully connected
 189         to the database (in seconds). Value is empty if manager has never
 190         successfully connected.
 191       </column>
 192
 193       <column name="status" key="sec_since_disconnect"
 194               type='{"type": "integer", "minInteger": 0}'>
 195         The amount of time since this manager last disconnected from the
 196         database (in seconds). Value is empty if manager has never
 197         disconnected.
 198       </column>
 199
 200       <column name="status" key="locks_held">
 201         Space-separated list of the names of OVSDB locks that the connection
 202         holds.  Omitted if the connection does not hold any locks.
 203       </column>
 204
 205       <column name="status" key="locks_waiting">
 206         Space-separated list of the names of OVSDB locks that the connection is
 207         currently waiting to acquire.  Omitted if the connection is not waiting
 208         for any locks.
 209       </column>
 210
 211       <column name="status" key="locks_lost">
 212         Space-separated list of the names of OVSDB locks that the connection
 213         has had stolen by another OVSDB client.  Omitted if no locks have been
 214         stolen from this connection.
 215       </column>
 216
 217       <column name="status" key="n_connections"
 218               type='{"type": "integer", "minInteger": 2}'>
 219         <p>
 220           When <ref column="target"/> specifies a connection method that
 221           listens for inbound connections (e.g. <code>ptcp:</code> or
 222           <code>pssl:</code>) and more than one connection is actually active,
 223           the value is the number of active connections.  Otherwise, this
 224           key-value pair is omitted.
 225         </p>
 226         <p>
 227           When multiple connections are active, status columns and key-value
 228           pairs (other than this one) report the status of one arbitrarily
 229           chosen connection.
 230         </p>
 231       </column>
 232     </group>
 233
 234     <group title="Connection Parameters">
 235       <p>
 236         Additional configuration for a connection between the manager
 237         and the database server.
 238       </p>
 239
 240       <column name="other_config" key="dscp"
 241                 type='{"type": "integer"}'>
 242         The Differentiated Service Code Point (DSCP) is specified using 6 bits
 243         in the Type of Service (TOS) field in the IP header. DSCP provides a
 244         mechanism to classify the network traffic and provide Quality of
 245         Service (QoS) on IP networks.
 246
 247         The DSCP value specified here is used when establishing the
 248         connection between the manager and the database server.  If no
 249         value is specified, a default value of 48 is chosen.  Valid DSCP
 250         values must be in the range 0 to 63.
 251       </column>
 252     </group>
 253   </table>
 254
 255   <table name="Physical_Switch" title="A physical switch.">
 256     A physical switch that implements a VTEP.
 257
 258     <column name="ports">
 259       The physical ports within the switch.
 260     </column>
 261
 262     <column name="tunnels">
 263       Tunnels created by this switch as instructed by the NVC.
 264     </column>
 265
 266     <group title="Network Status">
 267       <column name="management_ips">
 268         IPv4 or IPv6 addresses at which the switch may be contacted
 269         for management purposes.
 270       </column>
 271
 272       <column name="tunnel_ips">
 273         <p>
 274           IPv4 or IPv6 addresses on which the switch may originate or
 275           terminate tunnels.
 276         </p>
 277
 278         <p>
 279           This column is intended to allow a <ref table="Manager"/> to
 280           determine the <ref table="Physical_Switch"/> that terminates
 281           the tunnel represented by a <ref table="Physical_Locator"/>.
 282         </p>
 283       </column>
 284     </group>
 285
 286     <group title="Identification">
 287       <column name="name">
 288         Symbolic name for the switch, such as its hostname.
 289       </column>
 290
 291       <column name="description">
 292         An extended description for the switch, such as its switch login
 293         banner.
 294       </column>
 295     </group>
 296     <group title="Error Notification">
 297       <p>
 298         An entry in this column indicates to the NVC that this switch
 299         has encountered a fault. The switch must clear this column
 300         when the fault has been cleared.
 301       </p>
 302
 303       <column name="switch_fault_status" key="mac_table_exhaustion">
 304         Indicates that the switch has been unable to process MAC
 305         entries requested by the NVC due to lack of table resources.
 306       </column>
 307
 308       <column name="switch_fault_status" key="tunnel_exhaustion">
 309         Indicates that the switch has been unable to create tunnels
 310         requested by the NVC due to lack of resources.
 311       </column>
 312
 313       <column name="switch_fault_status" key="unspecified_fault">
 314         Indicates that an error has occurred in the switch but that no
 315         more specific information is available.
 316       </column>
 317
 318     </group>
 319   </table>
 320
 321   <table name="Tunnel" title="A tunnel created by a physical switch.">
 322     A tunnel created by a <ref table="Physical_Switch"/>.
 323
 324     <column name="local">
 325       Tunnel end-point local to the physical switch.
 326     </column>
 327
 328     <column name="remote">
 329       Tunnel end-point remote to the physical switch.
 330     </column>
 331
 332     <group title="Bidirectional Forwarding Detection (BFD)">
 333       <p>
 334         BFD, defined in RFC 5880, allows point to point detection of
 335         connectivity failures by occasional transmission of BFD control
 336         messages. VTEPs are expected to implement BFD.
 337       </p>
 338
 339       <p>
 340         BFD operates by regularly transmitting BFD control messages at a
 341         rate negotiated independently in each direction.  Each endpoint
 342         specifies the rate at which it expects to receive control messages,
 343         and the rate at which it's willing to transmit them.  An endpoint
 344         which fails to receive BFD control messages for a period of three
 345         times the expected reception rate will signal a connectivity
 346         fault.  In the case of a unidirectional connectivity issue, the
 347         system not receiving BFD control messages will signal the problem
 348         to its peer in the messages it transmits.
 349       </p>
 350
 351       <p>
 352         A hardware VTEP is expected to use BFD to determine reachability of
 353         devices at the end of the tunnels with which it exchanges data. This
 354         can enable the VTEP to choose a functioning service node among a set of
 355         service nodes providing high availability. It also enables the NVC to
 356         report the health status of tunnels.
 357       </p>
 358
 359       <p>
 360         In most cases the BFD peer of a hardware VTEP will be an Open vSwitch
 361         instance. The Open vSwitch implementation of BFD aims to comply
 362         faithfully with the requirements put forth in RFC 5880.  Open vSwitch
 363         does not implement the optional Authentication or ``Echo Mode''
 364         features.
 365       </p>
 366
 367       <group title="BFD Local Configuration">
 368         <p>
 369           The HSC writes the key-value pairs in the
 370           <ref column="bfd_config_local"/> column to specifiy the local
 371           configurations to be used for BFD sessions on this tunnel.
 372         </p>
 373
 374         <column name="bfd_config_local" key="bfd_dst_mac">
 375           Set to an Ethernet address in the form
 376           <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>
 377           to set the MAC expected as destination for received BFD packets.
 378           The default is <code>00:23:20:00:00:01</code>.
 379         </column>
 380
 381         <column name="bfd_config_local" key="bfd_dst_ip">
 382           Set to an IPv4 address to set the IP address that is expected as destination
 383           for received BFD packets.  The default is <code>169.254.1.0</code>.
 384         </column>
 385
 386       </group>
 387
 388       <group title="BFD Remote Configuration">
 389         <p>
 390           The <ref column="bfd_config_remote"/> column is the remote
 391           counterpart of the <ref column="bfd_config_local"/> column.
 392           The NVC writes the key-value pairs in this column.
 393         </p>
 394
 395         <column name="bfd_config_remote" key="bfd_dst_mac">
 396           Set to an Ethernet address in the form
 397           <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>
 398           to set the destination MAC to be used for transmitted BFD packets.
 399           The default is <code>00:23:20:00:00:01</code>.
 400         </column>
 401
 402         <column name="bfd_config_remote" key="bfd_dst_ip">
 403           Set to an IPv4 address to set the IP address used as destination
 404           for transmitted BFD packets.  The default is <code>169.254.1.1</code>.
 405         </column>
 406
 407       </group>
 408
 409       <group title="BFD Parameters">
 410         <p>
 411           The NVC sets up key-value pairs in the <ref column="bfd_params"/>
 412           column to enable and configure BFD.
 413         </p>
 414
 415         <column name="bfd_params" key="enable" type='{"type": "boolean"}'>
 416           True to enable BFD on this tunnel.
 417           The default is False.
 418         </column>
 419
 420         <column name="bfd_params" key="min_rx"
 421                 type='{"type": "integer", "minInteger": 1}'>
 422           The shortest interval, in milliseconds, at which this BFD session
 423           offers to receive BFD control messages.  The remote endpoint may
 424           choose to send messages at a slower rate.  Defaults to
 425           <code>1000</code>.
 426         </column>
 427
 428         <column name="bfd_params" key="min_tx"
 429                 type='{"type": "integer", "minInteger": 1}'>
 430           The shortest interval, in milliseconds, at which this BFD session is
 431           willing to transmit BFD control messages.  Messages will actually be
 432           transmitted at a slower rate if the remote endpoint is not willing to
 433           receive as quickly as specified.  Defaults to <code>100</code>.
 434         </column>
 435
 436         <column name="bfd_params" key="decay_min_rx" type='{"type": "integer"}'>
 437           An alternate receive interval, in milliseconds, that must be greater
 438           than or equal to <ref column="bfd" key="min_rx"/>.  The
 439           implementation switches from <ref column="bfd" key="min_rx"/> to <ref
 440           column="bfd" key="decay_min_rx"/> when there is no obvious incoming
 441           data traffic at the interface, to reduce the CPU and bandwidth cost
 442           of monitoring an idle interface.  This feature may be disabled by
 443           setting a value of 0.  This feature is reset whenever <ref
 444           column="bfd" key="decay_min_rx"/> or <ref column="bfd" key="min_rx"/>
 445           changes.
 446         </column>
 447
 448         <column name="bfd_params" key="forwarding_if_rx" type='{"type": "boolean"}'>
 449           True to consider the interface capable of packet I/O as long as it
 450           continues to receive any packets (not just BFD packets).  This
 451           prevents link congestion that causes consecutive BFD control packets
 452           to be lost from marking the interface down.
 453         </column>
 454
 455         <column name="bfd_params" key="cpath_down" type='{"type": "boolean"}'>
 456           Set to true to notify the remote endpoint that traffic should not be
 457           forwarded to this system for some reason other than a connectivty
 458           failure on the interface being monitored.  The typical underlying
 459           reason is ``concatenated path down,'' that is, that connectivity
 460           beyond the local system is down.  Defaults to false.
 461         </column>
 462
 463         <column name="bfd_params" key="check_tnl_key" type='{"type": "boolean"}'>
 464           Set to true to make BFD accept only control messages with a tunnel
 465           key of zero.  By default, BFD accepts control messages with any
 466           tunnel key.
 467         </column>
 468
 469       </group>
 470
 471      <group title="BFD Status">
 472       <p>
 473         The VTEP sets key-value pairs in the <ref column="bfd_status"/>
 474         column to report the status of BFD on this tunnel.  When BFD is
 475         not enabled, with <ref column="bfd_params" key="enable"/>, the
 476         HSC clears all key-value pairs from <ref column="bfd_status"/>.
 477       </p>
 478
 479       <column name="bfd_status" key="enabled"
 480         type='{"type": "boolean"}'>
 481         Set to true if the BFD session has been successfully
 482         enabled. Set to false if the VTEP cannot support BFD or has
 483         insufficient resources to enable BFD on this tunnel. The NVC
 484         will disable the BFD monitoring on the other side of the tunnel
 485         once this value is set to false.
 486       </column>
 487
 488       <column name="bfd_status" key="state"
 489         type='{"type": "string",
 490               "enum": ["set", ["admin_down", "down", "init", "up"]]}'>
 491         Reports the state of the BFD session.  The BFD session is fully
 492         healthy and negotiated if <code>UP</code>.
 493       </column>
 494
 495       <column name="bfd_status" key="forwarding" type='{"type": "boolean"}'>
 496         Reports whether the BFD session believes this tunnel
 497         may be used to forward traffic.  Typically this means the local session
 498         is signaling <code>UP</code>, and the remote system isn't signaling a
 499         problem such as concatenated path down.
 500       </column>
 501
 502       <column name="bfd_status" key="diagnostic">
 503         In case of a problem, set to an error message that reports what the
 504         local BFD session thinks is wrong.  The error messages are defined
 505         in section 4.1 of [RFC 5880].
 506       </column>
 507
 508       <column name="bfd_status" key="remote_state"
 509         type='{"type": "string",
 510               "enum": ["set", ["admin_down", "down", "init", "up"]]}'>
 511         Reports the state of the remote endpoint's BFD session.
 512       </column>
 513
 514       <column name="bfd_status" key="remote_diagnostic">
 515         In case of a problem, set to an error message that reports what the
 516         remote endpoint's BFD session thinks is wrong.  The error messages
 517         are defined in section 4.1 of [RFC 5880].
 518       </column>
 519
 520       <column name="bfd_status" key="info">
 521         A short message providing further information about the BFD status
 522         (possibly including reasons why BFD could not be enabled).
 523       </column>
 524       </group>
 525     </group>
 526   </table>
 527
 528   <table name="Physical_Port" title="A port within a physical switch.">
 529     A port within a <ref table="Physical_Switch"/>.
 530
 531     <column name="vlan_bindings">
 532       Identifies how VLANs on the physical port are bound to logical switches.
 533       If, for example, the map contains a (VLAN, logical switch) pair, a packet
 534       that arrives on the port in the VLAN is considered to belong to the
 535       paired logical switch.
 536     </column>
 537
 538     <column name="vlan_stats">
 539       Statistics for VLANs bound to logical switches on the physical port.  An
 540       implementation that fully supports such statistics would populate this
 541       column with a mapping for every VLAN that is bound in <ref
 542       column="vlan_bindings"/>.  An implementation that does not support such
 543       statistics or only partially supports them would not populate this column
 544       or partially populate it, respectively.
 545     </column>
 546
 547     <group title="Identification">
 548       <column name="name">
 549         Symbolic name for the port.  The name ought to be unique within a given
 550         <ref table="Physical_Switch"/>, but the database is not capable of
 551         enforcing this.
 552       </column>
 553
 554       <column name="description">
 555         An extended description for the port.
 556       </column>
 557     </group>
 558     <group title="Error Notification">
 559       <p>
 560         An entry in this column indicates to the NVC that the physical port has
 561         encountered a fault. The switch must clear this column when the errror
 562         has been cleared.
 563       </p>
 564       <column name="port_fault_status" key="invalid_vlan_map">
 565         <p>
 566           Indicates that a VLAN-to-logical-switch mapping requested by
 567           the controller could not be instantiated by the switch
 568           because of a conflict with local configuration.
 569         </p>
 570       </column>
 571       <column name="port_fault_status" key="unspecified_fault">
 572         <p>
 573           Indicates that an error has occurred on the port but that no
 574           more specific information is available.
 575         </p>
 576       </column>
 577     </group>
 578
 579   </table>
 580
 581   <table name="Logical_Binding_Stats" title="Statistics for a VLAN on a physical port bound to a logical network.">
 582     Reports statistics for the <ref table="Logical_Switch"/> with which a VLAN
 583     on a <ref table="Physical_Port"/> is associated.
 584
 585     <group title="Statistics">
 586       These statistics count only packets to which the binding applies.
 587
 588       <column name="packets_from_local">
 589         Number of packets sent by the <ref table="Physical_Switch"/>.
 590       </column>
 591
 592       <column name="bytes_from_local">
 593         Number of bytes in packets sent by the <ref table="Physical_Switch"/>.
 594       </column>
 595
 596       <column name="packets_to_local">
 597         Number of packets received by the <ref table="Physical_Switch"/>.
 598       </column>
 599
 600       <column name="bytes_to_local">
 601         Number of bytes in packets received by the <ref
 602         table="Physical_Switch"/>.
 603       </column>
 604     </group>
 605   </table>
 606
 607   <table name="Logical_Switch" title="A layer-2 domain.">
 608     A logical Ethernet switch, whose implementation may span physical and
 609     virtual media, possibly crossing L3 domains via tunnels; a logical layer-2
 610     domain; an Ethernet broadcast domain.
 611
 612
 613
 614     <group title="Per Logical-Switch Tunnel Key">
 615       <p>
 616         Tunnel protocols tend to have a field that allows the tunnel
 617         to be partitioned into sub-tunnels: VXLAN has a VNI, GRE and
 618         STT have a key, CAPWAP has a WSI, and so on.  We call these
 619         generically ``tunnel keys.''  Given that one needs to use a
 620         tunnel key at all, there are at least two reasonable ways to
 621         assign their values:
 622       </p>
 623
 624       <ul>
 625         <li>
 626           <p>
 627             Per <ref table="Logical_Switch"/>+<ref table="Physical_Locator"/>
 628             pair.  That is, each logical switch may be assigned a different
 629             tunnel key on every <ref table="Physical_Locator"/>.  This model is
 630             especially flexible.
 631           </p>
 632
 633           <p>
 634             In this model, <ref table="Physical_Locator"/> carries the tunnel
 635             key.  Therefore, one <ref table="Physical_Locator"/> record will
 636             exist for each logical switch carried at a given IP destination.
 637           </p>
 638         </li>
 639
 640         <li>
 641           <p>
 642             Per <ref table="Logical_Switch"/>.  That is, every tunnel
 643             associated with a particular logical switch carries the same tunnel
 644             key, regardless of the <ref table="Physical_Locator"/> to which the
 645             tunnel is addressed.  This model may ease switch implementation
 646             because it imposes fewer requirements on the hardware datapath.
 647           </p>
 648
 649           <p>
 650             In this model, <ref table="Logical_Switch"/> carries the tunnel
 651             key.  Therefore, one <ref table="Physical_Locator"/> record will
 652             exist for each IP destination.
 653           </p>
 654         </li>
 655       </ul>
 656
 657       <column name="tunnel_key">
 658         <p>
 659           This column is used only in the tunnel key per <ref
 660           table="Logical_Switch"/> model (see above), because only in that
 661           model is there a tunnel key associated with a logical switch.
 662         </p>
 663
 664         <p>
 665           For <code>vxlan_over_ipv4</code> encapsulation, this column
 666           is the VXLAN VNI that identifies a logical switch.  It must
 667           be in the range 0 to 16,777,215.
 668         </p>
 669       </column>
 670     </group>
 671
 672     <group title="Identification">
 673       <column name="name">
 674         Symbolic name for the logical switch.
 675       </column>
 676
 677       <column name="description">
 678         An extended description for the logical switch, such as its switch
 679         login banner.
 680       </column>
 681     </group>
 682   </table>
 683
 684   <table name="Ucast_Macs_Local" title="Unicast MACs (local)">
 685     <p>
 686       Mapping of unicast MAC addresses to tunnels (physical
 687       locators). This table is written by the HSC, so it contains the
 688       MAC addresses that have been learned on physical ports by a
 689       VTEP.
 690     </p>
 691
 692     <column name="MAC">
 693       A MAC address that has been learned by the VTEP.
 694     </column>
 695
 696     <column name="logical_switch">
 697       The Logical switch to which this mapping applies.
 698     </column>
 699
 700     <column name="locator">
 701       The physical locator to be used to reach this MAC address. In
 702       this table, the physical locator will be one of the tunnel IP
 703       addresses of the appropriate VTEP.
 704     </column>
 705
 706     <column name="ipaddr">
 707       The IP address to which this MAC corresponds. Optional field for
 708       the purpose of ARP supression.
 709     </column>
 710
 711   </table>
 712
 713  <table name="Ucast_Macs_Remote" title="Unicast MACs (remote)">
 714     <p>
 715       Mapping of unicast MAC addresses to tunnels (physical
 716       locators). This table is written by the NVC, so it contains the
 717       MAC addresses that the NVC has learned. These include VM MAC
 718       addresses, in which case the physical locators will be
 719       hypervisor IP addresses. The NVC will also report MACs that it
 720       has learned from other HSCs in the network, in which case the
 721       physical locators will be tunnel IP addresses of the
 722       corresponding VTEPs.
 723     </p>
 724
 725     <column name="MAC">
 726       A MAC address that has been learned by the NVC.
 727     </column>
 728
 729     <column name="logical_switch">
 730       The Logical switch to which this mapping applies.
 731     </column>
 732
 733     <column name="locator">
 734       The physical locator to be used to reach this MAC address. In
 735       this table, the physical locator will be either a hypervisor IP
 736       address or a tunnel IP addresses of another VTEP.
 737     </column>
 738
 739     <column name="ipaddr">
 740       The IP address to which this MAC corresponds. Optional field for
 741       the purpose of ARP supression.
 742     </column>
 743
 744   </table>
 745
 746   <table name="Mcast_Macs_Local" title="Multicast MACs (local)">
 747     <p>
 748       Mapping of multicast MAC addresses to tunnels (physical
 749       locators). This table is written by the HSC, so it contains the
 750       MAC addresses that have been learned on physical ports by a
 751       VTEP. These may be learned by IGMP snooping, for example. This
 752       table also specifies how to handle unknown unicast and broadcast packets.
 753     </p>
 754
 755     <column name="MAC">
 756       <p>
 757         A MAC address that has been learned by the VTEP.
 758       </p>
 759       <p>
 760         The keyword <code>unknown-dst</code> is used as a special
 761         ``Ethernet address'' that indicates the locations to which
 762         packets in a logical switch whose destination addresses do not
 763         otherwise appear in <ref table="Ucast_Macs_Local"/> (for
 764         unicast addresses) or <ref table="Mcast_Macs_Local"/> (for
 765         multicast addresses) should be sent.
 766       </p>
 767     </column>
 768
 769     <column name="logical_switch">
 770       The Logical switch to which this mapping applies.
 771     </column>
 772
 773     <column name="locator_set">
 774       The physical locator set to be used to reach this MAC address. In
 775       this table, the physical locator set will be contain one or more tunnel IP
 776       addresses of the appropriate VTEP(s).
 777     </column>
 778
 779     <column name="ipaddr">
 780       The IP address to which this MAC corresponds. Optional field for
 781       the purpose of ARP supression.
 782     </column>
 783   </table>
 784
 785   <table name="Mcast_Macs_Remote" title="Multicast MACs (remote)">
 786     <p>
 787       Mapping of multicast MAC addresses to tunnels (physical
 788       locators). This table is written by the NVC, so it contains the
 789       MAC addresses that the NVC has learned. This
 790       table also specifies how to handle unknown unicast and broadcast
 791       packets.
 792     </p>
 793     <p>
 794       Multicast packet replication may be handled by a service node,
 795       in which case the physical locators will be IP addresses of
 796       service nodes. If the VTEP supports replication onto multiple
 797       tunnels, then this may be used to replicate directly onto
 798       VTEP-hyperisor tunnels.
 799     </p>
 800
 801     <column name="MAC">
 802       <p>
 803         A MAC address that has been learned by the NVC.
 804       </p>
 805       <p>
 806         The keyword <code>unknown-dst</code> is used as a special
 807         ``Ethernet address'' that indicates the locations to which
 808         packets in a logical switch whose destination addresses do not
 809         otherwise appear in <ref table="Ucast_Macs_Remote"/> (for
 810         unicast addresses) or <ref table="Mcast_Macs_Remote"/> (for
 811         multicast addresses) should be sent.
 812       </p>
 813     </column>
 814
 815     <column name="logical_switch">
 816       The Logical switch to which this mapping applies.
 817     </column>
 818
 819     <column name="locator_set">
 820       The physical locator set to be used to reach this MAC address. In
 821       this table, the physical locator set will be either a service node IP
 822       address or a set of tunnel IP addresses of hypervisors (and
 823       potentially other VTEPs).
 824     </column>
 825
 826     <column name="ipaddr">
 827       The IP address to which this MAC corresponds. Optional field for
 828       the purpose of ARP supression.
 829     </column>
 830
 831   </table>
 832
 833   <table name="Logical_Router" title="A logical L3 router.">
 834     <p>
 835       A logical router, or VRF. A logical router may be connected to one or more
 836       logical switches. Subnet addresses and interface addresses may be configured on the
 837       interfaces.
 838     </p>
 839
 840     <column name="switch_binding">
 841       Maps from an IPv4 or IPv6 address prefix in CIDR notation to a
 842       logical switch. Multiple prefixes may map to the same switch. By
 843       writing a 32-bit (or 128-bit for v6) address with a /N prefix
 844       length, both the router's interface address and the subnet
 845       prefix can be configured. For example, 192.68.1.1/24 creates a
 846       /24 subnet for the logical switch attached to the interface and
 847       assigns the address 192.68.1.1 to the router interface.
 848     </column>
 849
 850     <column name="static_routes">
 851       One or more static routes, mapping IP prefixes to next hop IP addresses.
 852     </column>
 853
 854     <group title="Identification">
 855       <column name="name">
 856         Symbolic name for the logical router.
 857       </column>
 858
 859       <column name="description">
 860         An extended description for the logical router.
 861       </column>
 862     </group>
 863   </table>
 864
 865   <table name="Arp_Sources_Local" title="ARP source addresses for logical routers">
 866     <p>
 867       MAC address to be used when a VTEP issues ARP requests on behalf
 868       of a logical router.
 869     </p>
 870
 871     <p>
 872       A distributed logical router is implemented by a set of VTEPs
 873       (both hardware VTEPs and vswitches). In order for a given VTEP
 874       to populate the local ARP cache for a logical router, it issues
 875       ARP requests with a source MAC address that is unique to the VTEP. A
 876       single per-VTEP MAC can be re-used across all logical
 877       networks. This table contains the MACs that are used by the
 878       VTEPs of a given HSC. The table provides the mapping from MAC to
 879       physical locator for each VTEP so that replies to the ARP
 880       requests can be sent back to the correct VTEP using the
 881       appropriate physical locator.
 882     </p>
 883
 884     <column name="src_mac">
 885       The source MAC to be used by a given VTEP.
 886     </column>
 887
 888     <column name="locator">
 889       The <ref table="Physical_Locator"/> to use for replies to ARP
 890       requests from this MAC address.
 891     </column>
 892   </table>
 893
 894   <table name="Arp_Sources_Remote" title="ARP source addresses for logical routers">
 895     <p>
 896       MAC address to be used when a remote VTEP issues ARP requests on behalf
 897       of a logical router.
 898     </p>
 899
 900     <p>
 901       This table is the remote counterpart of <ref
 902       table="Arp_sources_local"/>. The NVC writes this table to notify
 903       the HSC of the MACs that will be used by remote VTEPs when they
 904       issue ARP requests on behalf of a distributed logical router.
 905     </p>
 906
 907     <column name="src_mac">
 908       The source MAC to be used by a given VTEP.
 909     </column>
 910
 911     <column name="locator">
 912       The <ref table="Physical_Locator"/> to use for replies to ARP
 913       requests from this MAC address.
 914     </column>
 915   </table>
 916
 917   <table name="Physical_Locator_Set">
 918     <p>
 919       A set of one or more <ref table="Physical_Locator"/>s.
 920     </p>
 921
 922     <p>
 923       This table exists only because OVSDB does not have a way to
 924       express the type ``map from string to one or more <ref
 925       table="Physical_Locator"/> records.''
 926     </p>
 927
 928     <column name="locators"/>
 929   </table>
 930
 931   <table name="Physical_Locator">
 932     <p>
 933       Identifies an endpoint to which logical switch traffic may be
 934       encapsulated and forwarded.
 935     </p>
 936
 937     <p>
 938       For the <code>vxlan_over_ipv4</code> encapsulation, the only
 939       encapsulation defined so far, all endpoints associated with a given <ref
 940       table="Logical_Switch"/> must use a common tunnel key, which is carried
 941       in the <ref table="Logical_Switch" column="tunnel_key"/> column of <ref
 942       table="Logical_Switch"/>.
 943     </p>
 944
 945     <p>
 946       For some encapsulations yet to be defined, we expect <ref
 947       table="Physical_Locator"/> to identify both an endpoint and a tunnel key.
 948       When the first such encapsulation is defined, we expect to add a
 949       ``tunnel_key'' column to <ref table="Physical_Locator"/> to allow the
 950       tunnel key to be defined.
 951     </p>
 952
 953     <p>
 954       See the ``Per Logical-Switch Tunnel Key'' section in the <ref
 955       table="Logical_Switch"/> table for further discussion of the model.
 956     </p>
 957
 958     <column name="encapsulation_type">
 959       The type of tunneling encapsulation.
 960     </column>
 961
 962     <column name="dst_ip">
 963       <p>
 964         For <code>vxlan_over_ipv4</code> encapsulation, the IPv4 address of the
 965         VXLAN tunnel endpoint.
 966       </p>
 967
 968       <p>
 969         We expect that this column could be used for IPv4 or IPv6 addresses in
 970         encapsulations to be introduced later.
 971       </p>
 972     </column>
 973
 974   </table>
 975
 976 </database>