| Message ID | 1444778141-6714-1-git-send-email-blp@nicira.com |
|---|---|
| State | Accepted |
| Headers | show |
Thanks! Acked-by: Justin Pettit <jpettit@nicira.com> --Justin > On Oct 13, 2015, at 4:15 PM, Ben Pfaff <blp@nicira.com> wrote: > > This is a large patch but it is entirely whitespace changes. > > Suggested-by: Justin Pettit <jpettit@nicira.com> > Signed-off-by: Ben Pfaff <blp@nicira.com> > --- > vswitchd/vswitch.xml | 684 ++++++++++++++++++++++++++------------------------- > 1 file changed, 346 insertions(+), 338 deletions(-) > > diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml > index 0ab4a9a..c94f42d 100644 > --- a/vswitchd/vswitch.xml > +++ b/vswitchd/vswitch.xml > @@ -530,7 +530,7 @@ > </column> > > <column name="auto_attach"> > - Auto Attach configuration. > + Auto Attach configuration. > </column> > </group> > > @@ -685,16 +685,16 @@ > </column> > > <column name="protocols"> > - <p> > - List of OpenFlow protocols that may be used when negotiating > - a connection with a controller. OpenFlow 1.0, 1.1, 1.2, and > - 1.3 are enabled by default if this column is empty. > - </p> > + <p> > + List of OpenFlow protocols that may be used when negotiating > + a connection with a controller. OpenFlow 1.0, 1.1, 1.2, and > + 1.3 are enabled by default if this column is empty. > + </p> > > - <p> > - OpenFlow 1.4 is not enabled by default because its implementation is > - missing features. > - </p> > + <p> > + OpenFlow 1.4 is not enabled by default because its implementation is > + missing features. > + </p> > > <p> > OpenFlow 1.5 has the same risks as OpenFlow 1.4, but it is even more > @@ -982,45 +982,45 @@ > <column name="other_config" key="forward-bpdu" > type='{"type": "boolean"}'> > > - <p> > + <p> > Controls forwarding of BPDUs and other network control frames when > NORMAL action is invoked. When this option is <code>false</code> or > unset, frames with reserved Ethernet addresses (see table below) will > not be forwarded. When this option is <code>true</code>, such frames > will not be treated specially. > - </p> > - > - <p> > - The above general rule has the following exceptions: > - </p> > - > - <ul> > - <li> > - If STP is enabled on the bridge (see the <ref column="stp_enable" > - table="Bridge"/> column in the <ref table="Bridge"/> table), the > - bridge processes all received STP packets and never passes them to > - OpenFlow or forwards them. This is true even if STP is disabled on > - an individual port. > - </li> > - > - <li> > - If LLDP is enabled on an interface (see the <ref column="lldp" > - table="Interface"/> column in the <ref table="Interface"/> table), > - the interface processes received LLDP packets and never passes them > - to OpenFlow or forwards them. > - </li> > - </ul> > - > - <p> > - Set this option to <code>true</code> if the Open vSwitch bridge > - connects different Ethernet networks and is not configured to > - participate in STP. > - </p> > - > - <p> > - This option affects packets with the following destination MAC > - addresses: > - </p> > + </p> > + > + <p> > + The above general rule has the following exceptions: > + </p> > + > + <ul> > + <li> > + If STP is enabled on the bridge (see the <ref column="stp_enable" > + table="Bridge"/> column in the <ref table="Bridge"/> table), the > + bridge processes all received STP packets and never passes them to > + OpenFlow or forwards them. This is true even if STP is disabled on > + an individual port. > + </li> > + > + <li> > + If LLDP is enabled on an interface (see the <ref column="lldp" > + table="Interface"/> column in the <ref table="Interface"/> table), > + the interface processes received LLDP packets and never passes them > + to OpenFlow or forwards them. > + </li> > + </ul> > + > + <p> > + Set this option to <code>true</code> if the Open vSwitch bridge > + connects different Ethernet networks and is not configured to > + participate in STP. > + </p> > + > + <p> > + This option affects packets with the following destination MAC > + addresses: > + </p> > > <dl> > <dt><code>01:80:c2:00:00:00</code></dt> > @@ -1036,8 +1036,8 @@ > <dd>Extreme Discovery Protocol (EDP).</dd> > > <dt> > - <code>00:e0:2b:00:00:04</code> and <code>00:e0:2b:00:00:06</code> > - </dt> > + <code>00:e0:2b:00:00:04</code> and <code>00:e0:2b:00:00:06</code> > + </dt> > <dd>Ethernet Automatic Protection Switching (EAPS).</dd> > > <dt><code>01:00:0c:cc:cc:cc</code></dt> > @@ -1099,8 +1099,8 @@ > <column name="external_ids"/> > </group> > </table> > - > - <table name="Port" table="Port or bond configuration."> > + > + <table name="Port" table="Port or bond configuration."> > <p>A port within a <ref table="Bridge"/>.</p> > <p>Most commonly, a port has exactly one ``interface,'' pointed to by its > <ref column="interfaces"/> column. Such a port logically > @@ -1382,7 +1382,7 @@ > </column> > > <column name="other_config" key="lacp-time" > - type='{"type": "string", "enum": ["set", ["fast", "slow"]]}'> > + type='{"type": "string", "enum": ["set", ["fast", "slow"]]}'> > <p> > The LACP timing which should be used on this <ref table="Port"/>. > By default <code>slow</code> is used. When configured to be > @@ -1394,7 +1394,7 @@ > </column> > > <column name="other_config" key="lacp-fallback-ab" > - type='{"type": "boolean"}'> > + type='{"type": "boolean"}'> > <p> > Determines the behavior of openvswitch bond in LACP mode. If > the partner switch does not support LACP, setting this option > @@ -1753,57 +1753,57 @@ > </column> > > <group title="OpenFlow Port Number"> > - <p> > - When a client adds a new interface, Open vSwitch chooses an OpenFlow > - port number for the new port. If the client that adds the port fills > - in <ref column="ofport_request"/>, then Open vSwitch tries to use its > - value as the OpenFlow port number. Otherwise, or if the requested > - port number is already in use or cannot be used for another reason, > - Open vSwitch automatically assigns a free port number. Regardless of > - how the port number was obtained, Open vSwitch then reports in <ref > - column="ofport"/> the port number actually assigned. > - </p> > - > - <p> > - Open vSwitch limits the port numbers that it automatically assigns to > - the range 1 through 32,767, inclusive. Controllers therefore have > - free use of ports 32,768 and up. > - </p> > - > - <column name="ofport"> > - <p> > - OpenFlow port number for this interface. Open vSwitch sets this > - column's value, so other clients should treat it as read-only. > - </p> > - <p> > - The OpenFlow ``local'' port (<code>OFPP_LOCAL</code>) is 65,534. > - The other valid port numbers are in the range 1 to 65,279, > - inclusive. Value -1 indicates an error adding the interface. > - </p> > - </column> > - > - <column name="ofport_request" > - type='{"type": "integer", "minInteger": 1, "maxInteger": 65279}'> > - <p> > - Requested OpenFlow port number for this interface. > - </p> > - > - <p> > - A client should ideally set this column's value in the same > - database transaction that it uses to create the interface. Open > - vSwitch version 2.1 and later will honor a later request for a > - specific port number, althuogh it might confuse some controllers: > - OpenFlow does not have a way to announce a port number change, so > - Open vSwitch represents it over OpenFlow as a port deletion > - followed immediately by a port addition. > - </p> > - > - <p> > - If <ref column="ofport_request"/> is set or changed to some other > - port's automatically assigned port number, Open vSwitch chooses a > - new port number for the latter port. > - </p> > - </column> > + <p> > + When a client adds a new interface, Open vSwitch chooses an OpenFlow > + port number for the new port. If the client that adds the port fills > + in <ref column="ofport_request"/>, then Open vSwitch tries to use its > + value as the OpenFlow port number. Otherwise, or if the requested > + port number is already in use or cannot be used for another reason, > + Open vSwitch automatically assigns a free port number. Regardless of > + how the port number was obtained, Open vSwitch then reports in <ref > + column="ofport"/> the port number actually assigned. > + </p> > + > + <p> > + Open vSwitch limits the port numbers that it automatically assigns to > + the range 1 through 32,767, inclusive. Controllers therefore have > + free use of ports 32,768 and up. > + </p> > + > + <column name="ofport"> > + <p> > + OpenFlow port number for this interface. Open vSwitch sets this > + column's value, so other clients should treat it as read-only. > + </p> > + <p> > + The OpenFlow ``local'' port (<code>OFPP_LOCAL</code>) is 65,534. > + The other valid port numbers are in the range 1 to 65,279, > + inclusive. Value -1 indicates an error adding the interface. > + </p> > + </column> > + > + <column name="ofport_request" > + type='{"type": "integer", "minInteger": 1, "maxInteger": 65279}'> > + <p> > + Requested OpenFlow port number for this interface. > + </p> > + > + <p> > + A client should ideally set this column's value in the same > + database transaction that it uses to create the interface. Open > + vSwitch version 2.1 and later will honor a later request for a > + specific port number, althuogh it might confuse some controllers: > + OpenFlow does not have a way to announce a port number change, so > + Open vSwitch represents it over OpenFlow as a port deletion > + followed immediately by a port addition. > + </p> > + > + <p> > + If <ref column="ofport_request"/> is set or changed to some other > + port's automatically assigned port number, Open vSwitch chooses a > + new port number for the latter port. > + </p> > + </column> > </group> > </group> > > @@ -1858,15 +1858,15 @@ > > <dt><code>vxlan</code></dt> > <dd> > - <p> > - An Ethernet tunnel over the UDP-based VXLAN protocol described in > - RFC 7348. > - </p> > - <p> > - Open vSwitch uses UDP destination port 4789. The source port used for > - VXLAN traffic varies on a per-flow basis and is in the ephemeral port > - range. > - </p> > + <p> > + An Ethernet tunnel over the UDP-based VXLAN protocol described in > + RFC 7348. > + </p> > + <p> > + Open vSwitch uses UDP destination port 4789. The source port used for > + VXLAN traffic varies on a per-flow basis and is in the ephemeral port > + range. > + </p> > </dd> > > <dt><code>lisp</code></dt> > @@ -1887,21 +1887,21 @@ > > <dt><code>stt</code></dt> > <dd> > - The Stateless TCP Tunnel (STT) is particularly useful when tunnel > - endpoints are in end-systems, as it utilizes the capabilities of > - standard network interface cards to improve performance. STT utilizes > - a TCP-like header inside the IP header. It is stateless, i.e., there is > - no TCP connection state of any kind associated with the tunnel. The > - TCP-like header is used to leverage the capabilities of existing > - network interface cards, but should not be interpreted as implying > - any sort of connection state between endpoints. > - Since the STT protocol does not engage in the usual TCP 3-way handshake, > - so it will have difficulty traversing stateful firewalls. > - The protocol is documented at > - http://www.ietf.org/archive/id/draft-davie-stt-06.txt > - > - All traffic uses a default destination port of 7471. STT is only > - available in kernel datapath on kernel 3.5 or newer. > + The Stateless TCP Tunnel (STT) is particularly useful when tunnel > + endpoints are in end-systems, as it utilizes the capabilities of > + standard network interface cards to improve performance. STT utilizes > + a TCP-like header inside the IP header. It is stateless, i.e., there is > + no TCP connection state of any kind associated with the tunnel. The > + TCP-like header is used to leverage the capabilities of existing > + network interface cards, but should not be interpreted as implying > + any sort of connection state between endpoints. > + Since the STT protocol does not engage in the usual TCP 3-way handshake, > + so it will have difficulty traversing stateful firewalls. > + The protocol is documented at > + http://www.ietf.org/archive/id/draft-davie-stt-06.txt > + > + All traffic uses a default destination port of 7471. STT is only > + available in kernel datapath on kernel 3.5 or newer. > </dd> > > <dt><code>patch</code></dt> > @@ -1911,7 +1911,7 @@ > > <dt><code>null</code></dt> > <dd>An ignored interface. Deprecated and slated for removal in > - February 2013.</dd> > + February 2013.</dd> > </dl> > </column> > </group> > @@ -1955,9 +1955,9 @@ > </ul> > > <p> > - The remote tunnel endpoint for any packet received from a tunnel > - is available in the <code>tun_src</code> field for matching in the > - flow table. > + The remote tunnel endpoint for any packet received from a tunnel > + is available in the <code>tun_src</code> field for matching in the > + flow table. > </p> > </column> > > @@ -2079,23 +2079,23 @@ > > <group title="Tunnel Options: vxlan only"> > > - <column name="options" key="exts"> > - <p>Optional. Comma separated list of optional VXLAN extensions to > - enable. The following extensions are supported:</p> > + <column name="options" key="exts"> > + <p>Optional. Comma separated list of optional VXLAN extensions to > + enable. The following extensions are supported:</p> > > - <ul> > - <li> > - <code>gbp</code>: VXLAN-GBP allows to transport the group policy > - context of a packet across the VXLAN tunnel to other network > - peers. See the field description of <code>tun_gbp_id</code> and > - <code>tun_gbp_flags</code> in ovs-ofctl(8) for additional > - information. > - (<code>https://tools.ietf.org/html/draft-smith-vxlan-group-policy</code>) > - </li> > - </ul> > - </column> > + <ul> > + <li> > + <code>gbp</code>: VXLAN-GBP allows to transport the group policy > + context of a packet across the VXLAN tunnel to other network > + peers. See the field description of <code>tun_gbp_id</code> and > + <code>tun_gbp_flags</code> in ovs-ofctl(8) for additional > + information. > + (<code>https://tools.ietf.org/html/draft-smith-vxlan-group-policy</code>) > + </li> > + </ul> > + </column> > > - </group> > + </group> > > <group title="Tunnel Options: gre, ipsec_gre, geneve, and vxlan"> > <p> > @@ -2109,7 +2109,7 @@ > checksums on outgoing packets. Default is disabled, set to > <code>true</code> to enable. Checksums present on incoming > packets will be validated regardless of this setting. > - </p> > + </p> > > <p> > When using the upstream Linux kernel module, computation of > @@ -2122,9 +2122,9 @@ > </p> > > <p> > - This option is supported for <code>ipsec_gre</code>, but not useful > - because GRE checksums are weaker than, and redundant with, IPsec > - payload authentication. > + This option is supported for <code>ipsec_gre</code>, but not useful > + because GRE checksums are weaker than, and redundant with, IPsec > + payload authentication. > </p> > </column> > </group> > @@ -2419,70 +2419,70 @@ > > <group title="Bidirectional Forwarding Detection (BFD)"> > <p> > - BFD, defined in RFC 5880 and RFC 5881, allows point-to-point > - detection of connectivity failures by occasional transmission of > - BFD control messages. Open vSwitch implements BFD to serve > - as a more popular and standards compliant alternative to CFM. > + BFD, defined in RFC 5880 and RFC 5881, allows point-to-point > + detection of connectivity failures by occasional transmission of > + BFD control messages. Open vSwitch implements BFD 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 is willing to transmit them. Open vSwitch uses a detection > - multiplier of three, meaning that an endpoint signals a connectivity > - fault if three consecutive BFD control messages fail to arrive. In the > - case of a unidirectional connectivity issue, the system not receiving > - BFD control messages signals the problem to its peer in the messages it > - transmits. > + 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 is willing to transmit them. Open vSwitch uses a detection > + multiplier of three, meaning that an endpoint signals a connectivity > + fault if three consecutive BFD control messages fail to arrive. In the > + case of a unidirectional connectivity issue, the system not receiving > + BFD control messages signals the problem to its peer in the messages it > + transmits. > </p> > > <p> > - The Open vSwitch implementation of BFD aims to comply faithfully > - with RFC 5880 requirements. Open vSwitch does not implement the > - optional Authentication or ``Echo Mode'' features. > + The Open vSwitch implementation of BFD aims to comply faithfully > + with RFC 5880 requirements. Open vSwitch does not implement the > + optional Authentication or ``Echo Mode'' features. > </p> > > <group title="BFD Configuration"> > - <p> > - A controller sets up key-value pairs in the <ref column="bfd"/> > - column to enable and configure BFD. > - </p> > + <p> > + A controller sets up key-value pairs in the <ref column="bfd"/> > + column to enable and configure BFD. > + </p> > > - <column name="bfd" key="enable" type='{"type": "boolean"}'> > + <column name="bfd" key="enable" type='{"type": "boolean"}'> > True to enable BFD on this <ref table="Interface"/>. If not > specified, BFD will not be enabled by default. > - </column> > + </column> > > - <column name="bfd" key="min_rx" > - type='{"type": "integer", "minInteger": 1}'> > + <column name="bfd" key="min_rx" > + type='{"type": "integer", "minInteger": 1}'> > The shortest interval, in milliseconds, at which this BFD session > offers to receive BFD control messages. The remote endpoint may > choose to send messages at a slower rate. Defaults to > <code>1000</code>. > - </column> > + </column> > > - <column name="bfd" key="min_tx" > - type='{"type": "integer", "minInteger": 1}'> > + <column name="bfd" key="min_tx" > + type='{"type": "integer", "minInteger": 1}'> > The shortest interval, in milliseconds, at which this BFD session is > willing to transmit BFD control messages. Messages will actually be > transmitted at a slower rate if the remote endpoint is not willing to > receive as quickly as specified. Defaults to <code>100</code>. > - </column> > - > - <column name="bfd" key="decay_min_rx" type='{"type": "integer"}'> > - An alternate receive interval, in milliseconds, that must be greater > - than or equal to <ref column="bfd" key="min_rx"/>. The > - implementation switches from <ref column="bfd" key="min_rx"/> to <ref > - column="bfd" key="decay_min_rx"/> when there is no obvious incoming > - data traffic at the interface, to reduce the CPU and bandwidth cost > - of monitoring an idle interface. This feature may be disabled by > - setting a value of 0. This feature is reset whenever <ref > - column="bfd" key="decay_min_rx"/> or <ref column="bfd" key="min_rx"/> > - changes. > - </column> > - > - <column name="bfd" key="forwarding_if_rx" type='{"type": "boolean"}'> > + </column> > + > + <column name="bfd" key="decay_min_rx" type='{"type": "integer"}'> > + An alternate receive interval, in milliseconds, that must be greater > + than or equal to <ref column="bfd" key="min_rx"/>. The > + implementation switches from <ref column="bfd" key="min_rx"/> to <ref > + column="bfd" key="decay_min_rx"/> when there is no obvious incoming > + data traffic at the interface, to reduce the CPU and bandwidth cost > + of monitoring an idle interface. This feature may be disabled by > + setting a value of 0. This feature is reset whenever <ref > + column="bfd" key="decay_min_rx"/> or <ref column="bfd" key="min_rx"/> > + changes. > + </column> > + > + <column name="bfd" key="forwarding_if_rx" type='{"type": "boolean"}'> > When <code>true</code>, traffic received on the > <ref table="Interface"/> is used to indicate the capability of packet > I/O. BFD control packets are still transmitted and received. At > @@ -2490,98 +2490,98 @@ > column="bfd" key="min_rx"/> amount of time. Otherwise, even if > traffic are received, the <ref column="bfd" key="forwarding"/> > will be <code>false</code>. > - </column> > + </column> > > - <column name="bfd" key="cpath_down" type='{"type": "boolean"}'> > - Set to true to notify the remote endpoint that traffic should not be > - forwarded to this system for some reason other than a connectivty > - failure on the interface being monitored. The typical underlying > - reason is ``concatenated path down,'' that is, that connectivity > - beyond the local system is down. Defaults to false. > - </column> > + <column name="bfd" key="cpath_down" type='{"type": "boolean"}'> > + Set to true to notify the remote endpoint that traffic should not be > + forwarded to this system for some reason other than a connectivty > + failure on the interface being monitored. The typical underlying > + reason is ``concatenated path down,'' that is, that connectivity > + beyond the local system is down. Defaults to false. > + </column> > > - <column name="bfd" key="check_tnl_key" type='{"type": "boolean"}'> > + <column name="bfd" key="check_tnl_key" type='{"type": "boolean"}'> > Set to true to make BFD accept only control messages with a tunnel > key of zero. By default, BFD accepts control messages with any > tunnel key. > - </column> > - > - <column name="bfd" key="bfd_local_src_mac"> > - Set to an Ethernet address in the form > - <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var> > - to set the MAC used as source for transmitted BFD packets. The > - default is the mac address of the BFD enabled interface. > - </column> > - > - <column name="bfd" key="bfd_local_dst_mac"> > - Set to an Ethernet address in the form > - <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var> > - to set the MAC used as destination for transmitted BFD packets. The > - default is <code>00:23:20:00:00:01</code>. > - </column> > - > - <column name="bfd" key="bfd_remote_dst_mac"> > - Set to an Ethernet address in the form > - <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var> > - to set the MAC used for checking the destination of received BFD packets. > - Packets with different destination MAC will not be considered as BFD packets. > - If not specified the destination MAC address of received BFD packets > - are not checked. > - </column> > - > - <column name="bfd" key="bfd_src_ip"> > + </column> > + > + <column name="bfd" key="bfd_local_src_mac"> > + Set to an Ethernet address in the form > + <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var> > + to set the MAC used as source for transmitted BFD packets. The > + default is the mac address of the BFD enabled interface. > + </column> > + > + <column name="bfd" key="bfd_local_dst_mac"> > + Set to an Ethernet address in the form > + <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var> > + to set the MAC used as destination for transmitted BFD packets. The > + default is <code>00:23:20:00:00:01</code>. > + </column> > + > + <column name="bfd" key="bfd_remote_dst_mac"> > + Set to an Ethernet address in the form > + <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var> > + to set the MAC used for checking the destination of received BFD packets. > + Packets with different destination MAC will not be considered as BFD packets. > + If not specified the destination MAC address of received BFD packets > + are not checked. > + </column> > + > + <column name="bfd" key="bfd_src_ip"> > Set to an IPv4 address to set the IP address used as source for > transmitted BFD packets. The default is <code>169.254.1.1</code>. > - </column> > + </column> > > - <column name="bfd" key="bfd_dst_ip"> > + <column name="bfd" key="bfd_dst_ip"> > Set to an IPv4 address to set the IP address used as destination > for transmitted BFD packets. The default is <code>169.254.1.0</code>. > - </column> > + </column> > </group> > > <group title="BFD Status"> > - <p> > - The switch sets key-value pairs in the <ref column="bfd_status"/> > - column to report the status of BFD on this interface. When BFD is > - not enabled, with <ref column="bfd" key="enable"/>, the switch clears > - all key-value pairs from <ref column="bfd_status"/>. > - </p> > - > - <column name="bfd_status" key="state" > - type='{"type": "string", > - "enum": ["set", ["admin_down", "down", "init", "up"]]}'> > - Reports the state of the BFD session. The BFD session is fully > - healthy and negotiated if <code>UP</code>. > - </column> > - > - <column name="bfd_status" key="forwarding" type='{"type": "boolean"}'> > - Reports whether the BFD session believes this <ref > - table="Interface"/> may be used to forward traffic. Typically this > - means the local session is signaling <code>UP</code>, and the remote > - system isn't signaling a problem such as concatenated path down. > - </column> > - > - <column name="bfd_status" key="diagnostic"> > - In case of a problem, set to an error message that reports what the > - local BFD session thinks is wrong. The error messages are defined > - in section 4.1 of [RFC 5880]. > - </column> > - > - <column name="bfd_status" key="remote_state" > - type='{"type": "string", > - "enum": ["set", ["admin_down", "down", "init", "up"]]}'> > - Reports the state of the remote endpoint's BFD session. > - </column> > - > - <column name="bfd_status" key="remote_diagnostic"> > - In case of a problem, set to an error message that reports what the > - remote endpoint's BFD session thinks is wrong. The error messages > - are defined in section 4.1 of [RFC 5880]. > - </column> > + <p> > + The switch sets key-value pairs in the <ref column="bfd_status"/> > + column to report the status of BFD on this interface. When BFD is > + not enabled, with <ref column="bfd" key="enable"/>, the switch clears > + all key-value pairs from <ref column="bfd_status"/>. > + </p> > + > + <column name="bfd_status" key="state" > + type='{"type": "string", > + "enum": ["set", ["admin_down", "down", "init", "up"]]}'> > + Reports the state of the BFD session. The BFD session is fully > + healthy and negotiated if <code>UP</code>. > + </column> > + > + <column name="bfd_status" key="forwarding" type='{"type": "boolean"}'> > + Reports whether the BFD session believes this <ref > + table="Interface"/> may be used to forward traffic. Typically this > + means the local session is signaling <code>UP</code>, and the remote > + system isn't signaling a problem such as concatenated path down. > + </column> > + > + <column name="bfd_status" key="diagnostic"> > + In case of a problem, set to an error message that reports what the > + local BFD session thinks is wrong. The error messages are defined > + in section 4.1 of [RFC 5880]. > + </column> > + > + <column name="bfd_status" key="remote_state" > + type='{"type": "string", > + "enum": ["set", ["admin_down", "down", "init", "up"]]}'> > + Reports the state of the remote endpoint's BFD session. > + </column> > + > + <column name="bfd_status" key="remote_diagnostic"> > + In case of a problem, set to an error message that reports what the > + remote endpoint's BFD session thinks is wrong. The error messages > + are defined in section 4.1 of [RFC 5880]. > + </column> > > <column name="bfd_status" key="flap_count" > - type='{"type": "integer", "minInteger": 0}'> > + type='{"type": "integer", "minInteger": 0}'> > Counts the number of <ref column="bfd_status" key="forwarding" /> > flaps since start. A flap is considered as a change of the > <ref column="bfd_status" key="forwarding" /> value. > @@ -2609,9 +2609,9 @@ > </p> > > <p> > - When operating over tunnels which have no <code>in_key</code>, or an > - <code>in_key</code> of <code>flow</code>. CFM will only accept CCMs > - with a tunnel key of zero. > + When operating over tunnels which have no <code>in_key</code>, or an > + <code>in_key</code> of <code>flow</code>. CFM will only accept CCMs > + with a tunnel key of zero. > </p> > > <column name="cfm_mpid"> > @@ -2696,8 +2696,8 @@ > > <column name="cfm_remote_opstate"> > <p>When in extended mode, indicates the operational state of the > - remote endpoint as either <code>up</code> or <code>down</code>. See > - <ref column="other_config" key="cfm_opstate"/>. > + remote endpoint as either <code>up</code> or <code>down</code>. See > + <ref column="other_config" key="cfm_opstate"/>. > </p> > </column> > > @@ -2773,7 +2773,7 @@ > </p> > > <p> > - Demand mode has a couple of caveats: > + Demand mode has a couple of caveats: > <ul> > <li> > To ensure that ovs-vswitchd has enough time to pull statistics > @@ -2811,14 +2811,14 @@ > </column> > > <column name="other_config" key="cfm_ccm_vlan" > - type='{"type": "integer", "minInteger": 1, "maxInteger": 4095}'> > + type='{"type": "integer", "minInteger": 1, "maxInteger": 4095}'> > When set, the CFM module will apply a VLAN tag to all CCMs it generates > with the given value. May be the string <code>random</code> in which > case each CCM will be tagged with a different randomly generated VLAN. > </column> > > <column name="other_config" key="cfm_ccm_pcp" > - type='{"type": "integer", "minInteger": 1, "maxInteger": 7}'> > + type='{"type": "integer", "minInteger": 1, "maxInteger": 7}'> > When set, the CFM module will apply a VLAN tag to all CCMs it generates > with the given PCP value, the VLAN ID of the tag is governed by the > value of <ref column="other_config" key="cfm_ccm_vlan"/>. If > @@ -2926,17 +2926,17 @@ > > <group title="VLAN Splinters"> > <p> > - The ``VLAN splinters'' feature increases Open vSwitch compatibility > - with buggy network drivers in old versions of Linux that do not > - properly support VLANs when VLAN devices are not used, at some cost > - in memory and performance. > + The ``VLAN splinters'' feature increases Open vSwitch compatibility > + with buggy network drivers in old versions of Linux that do not > + properly support VLANs when VLAN devices are not used, at some cost > + in memory and performance. > </p> > > <p> > - When VLAN splinters are enabled on a particular interface, Open vSwitch > - creates a VLAN device for each in-use VLAN. For sending traffic tagged > - with a VLAN on the interface, it substitutes the VLAN device. Traffic > - received on the VLAN device is treated as if it had been received on > + When VLAN splinters are enabled on a particular interface, Open vSwitch > + creates a VLAN device for each in-use VLAN. For sending traffic tagged > + with a VLAN on the interface, it substitutes the VLAN device. Traffic > + received on the VLAN device is treated as if it had been received on > the interface on the particular VLAN. > </p> > > @@ -2978,8 +2978,8 @@ > </p> > > <p> > - VLAN splinters are deprecated. When broken device drivers are no > - longer in widespread use, we will delete this feature. > + VLAN splinters are deprecated. When broken device drivers are no > + longer in widespread use, we will delete this feature. > </p> > > <column name="other_config" key="enable-vlan-splinters" > @@ -3004,12 +3004,12 @@ > > <group title="Auto Attach Configuration"> > <p> > - Auto Attach configuration for a particular interface. > + Auto Attach configuration for a particular interface. > </p> > > <column name="lldp" key="enable" type='{"type": "boolean"}'> > - True to enable LLDP on this <ref table="Interface"/>. If not > - specified, LLDP will be disabled by default. > + True to enable LLDP on this <ref table="Interface"/>. If not > + specified, LLDP will be disabled by default. > </column> > </group> > > @@ -3986,7 +3986,7 @@ > </p> > > <column name="other_config" key="dscp" > - type='{"type": "integer"}'> > + 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 > @@ -4252,11 +4252,11 @@ > </column> > > <column name="status" key="bound_port" type='{"type": "integer"}'> > - When <ref column="target"/> is <code>ptcp:</code> or > - <code>pssl:</code>, this is the TCP port on which the OVSDB server is > - listening. (This is is particularly useful when <ref > - column="target"/> specifies a port of 0, allowing the kernel to > - choose any available port.) > + When <ref column="target"/> is <code>ptcp:</code> or > + <code>pssl:</code>, this is the TCP port on which the OVSDB server is > + listening. (This is is particularly useful when <ref > + column="target"/> specifies a port of 0, allowing the kernel to > + choose any available port.) > </column> > </group> > > @@ -4267,7 +4267,7 @@ > </p> > > <column name="other_config" key="dscp" > - type='{"type": "integer"}'> > + 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 > @@ -4312,18 +4312,18 @@ > > <column name="active_timeout"> > <p> > - The interval at which NetFlow records are sent for flows that > - are still active, in seconds. A value of <code>0</code> > - requests the default timeout (currently 600 seconds); a value > - of <code>-1</code> disables active timeouts. > + The interval at which NetFlow records are sent for flows that > + are still active, in seconds. A value of <code>0</code> > + requests the default timeout (currently 600 seconds); a value > + of <code>-1</code> disables active timeouts. > </p> > > <p> > - The NetFlow passive timeout, for flows that become inactive, > - is not configurable. It will vary depending on the Open > - vSwitch version, the forms and contents of the OpenFlow flow > - tables, CPU and memory usage, and network activity. A typical > - passive timeout is about a second. > + The NetFlow passive timeout, for flows that become inactive, > + is not configurable. It will vary depending on the Open > + vSwitch version, the forms and contents of the OpenFlow flow > + tables, CPU and memory usage, and network activity. A typical > + passive timeout is about a second. > </p> > </column> > > @@ -4650,39 +4650,46 @@ > </table> > > <table name="AutoAttach"> > - <p>Auto Attach configuration within a bridge. The IETF Auto-Attach SPBM > - draft standard describes a compact method of using IEEE 802.1AB Link > - Layer Discovery Protocol (LLDP) together with a IEEE 802.1aq Shortest > - Path Bridging (SPB) network to automatically attach network devices > - to individual services in a SPB network. The intent here is to allow > - network applications and devices using OVS to be able to easily take > - advantage of features offered by industry standard SPB networks.</p> > - > - <p>Auto Attach (AA) uses LLDP to communicate between a directly connected > - Auto Attach Client (AAC) and Auto Attach Server (AAS). The LLDP protocol > - is extended to add two new Type-Length-Value tuples (TLVs). The first > - new TLV supports the ongoing discovery of directly connected AA > - correspondents. Auto Attach operates by regularly transmitting AA > - discovery TLVs between the AA client and AA server. By exchanging these > - discovery messages, both the AAC and AAS learn the system name and > - system description of their peer. In the OVS context, OVS operates as > - the AA client and the AA server resides on a switch at the edge of the > - SPB network.</p> > - > - <p>Once AA discovery has been completed the AAC then uses the > - second new TLV to deliver identifier mappings from the AAC to the AAS. A primary > - feature of Auto Attach is to facilitate the mapping of VLANs defined > - outside the SPB network onto service ids (ISIDs) defined within the SPM > - network. By doing so individual external VLANs can be mapped onto > - specific SPB network services. These VLAN id to ISID mappings can be > - configured and managed locally using new options added to the ovs-vsctl > - command.</p> > - > - <p>The Auto Attach OVS feature does not provide a full implementation of > - the LLDP protocol. Support for the mandatory TLVs as defined by the LLDP > - standard and support for the AA TLV extensions is provided. LLDP > - protocol support in OVS can be enabled or disabled on a port by port > - basis. LLDP support is disabled by default.</p> > + <p> > + Auto Attach configuration within a bridge. The IETF Auto-Attach SPBM > + draft standard describes a compact method of using IEEE 802.1AB Link > + Layer Discovery Protocol (LLDP) together with a IEEE 802.1aq Shortest > + Path Bridging (SPB) network to automatically attach network devices > + to individual services in a SPB network. The intent here is to allow > + network applications and devices using OVS to be able to easily take > + advantage of features offered by industry standard SPB networks. > + </p> > + > + <p> > + Auto Attach (AA) uses LLDP to communicate between a directly connected > + Auto Attach Client (AAC) and Auto Attach Server (AAS). The LLDP protocol > + is extended to add two new Type-Length-Value tuples (TLVs). The first > + new TLV supports the ongoing discovery of directly connected AA > + correspondents. Auto Attach operates by regularly transmitting AA > + discovery TLVs between the AA client and AA server. By exchanging these > + discovery messages, both the AAC and AAS learn the system name and > + system description of their peer. In the OVS context, OVS operates as > + the AA client and the AA server resides on a switch at the edge of the > + SPB network. > + </p> > + > + <p> > + Once AA discovery has been completed the AAC then uses the second new TLV > + to deliver identifier mappings from the AAC to the AAS. A primary feature > + of Auto Attach is to facilitate the mapping of VLANs defined outside the > + SPB network onto service ids (ISIDs) defined within the SPM network. By > + doing so individual external VLANs can be mapped onto specific SPB > + network services. These VLAN id to ISID mappings can be configured and > + managed locally using new options added to the ovs-vsctl command. > + </p> > + > + <p> > + The Auto Attach OVS feature does not provide a full implementation of > + the LLDP protocol. Support for the mandatory TLVs as defined by the LLDP > + standard and support for the AA TLV extensions is provided. LLDP > + protocol support in OVS can be enabled or disabled on a port by port > + basis. LLDP support is disabled by default. > + </p> > > <column name="system_name"> > The system_name string is exported in LLDP messages. It should uniquely > @@ -4695,7 +4702,8 @@ > </column> > > <column name="mappings"> > - A mapping from SPB network Individual Service Identifier (ISID) to VLAN id. > + A mapping from SPB network Individual Service Identifier (ISID) to VLAN > + id. > </column> > </table> > </database> > -- > 2.1.3 >
Thanks, applied. On Tue, Oct 13, 2015 at 04:16:41PM -0700, Justin Pettit wrote: > Thanks! > > Acked-by: Justin Pettit <jpettit@nicira.com> > > --Justin > > > > On Oct 13, 2015, at 4:15 PM, Ben Pfaff <blp@nicira.com> wrote: > > > > This is a large patch but it is entirely whitespace changes. > > > > Suggested-by: Justin Pettit <jpettit@nicira.com> > > Signed-off-by: Ben Pfaff <blp@nicira.com> > > --- > > vswitchd/vswitch.xml | 684 ++++++++++++++++++++++++++------------------------- > > 1 file changed, 346 insertions(+), 338 deletions(-) > > > > diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml > > index 0ab4a9a..c94f42d 100644 > > --- a/vswitchd/vswitch.xml > > +++ b/vswitchd/vswitch.xml > > @@ -530,7 +530,7 @@ > > </column> > > > > <column name="auto_attach"> > > - Auto Attach configuration. > > + Auto Attach configuration. > > </column> > > </group> > > > > @@ -685,16 +685,16 @@ > > </column> > > > > <column name="protocols"> > > - <p> > > - List of OpenFlow protocols that may be used when negotiating > > - a connection with a controller. OpenFlow 1.0, 1.1, 1.2, and > > - 1.3 are enabled by default if this column is empty. > > - </p> > > + <p> > > + List of OpenFlow protocols that may be used when negotiating > > + a connection with a controller. OpenFlow 1.0, 1.1, 1.2, and > > + 1.3 are enabled by default if this column is empty. > > + </p> > > > > - <p> > > - OpenFlow 1.4 is not enabled by default because its implementation is > > - missing features. > > - </p> > > + <p> > > + OpenFlow 1.4 is not enabled by default because its implementation is > > + missing features. > > + </p> > > > > <p> > > OpenFlow 1.5 has the same risks as OpenFlow 1.4, but it is even more > > @@ -982,45 +982,45 @@ > > <column name="other_config" key="forward-bpdu" > > type='{"type": "boolean"}'> > > > > - <p> > > + <p> > > Controls forwarding of BPDUs and other network control frames when > > NORMAL action is invoked. When this option is <code>false</code> or > > unset, frames with reserved Ethernet addresses (see table below) will > > not be forwarded. When this option is <code>true</code>, such frames > > will not be treated specially. > > - </p> > > - > > - <p> > > - The above general rule has the following exceptions: > > - </p> > > - > > - <ul> > > - <li> > > - If STP is enabled on the bridge (see the <ref column="stp_enable" > > - table="Bridge"/> column in the <ref table="Bridge"/> table), the > > - bridge processes all received STP packets and never passes them to > > - OpenFlow or forwards them. This is true even if STP is disabled on > > - an individual port. > > - </li> > > - > > - <li> > > - If LLDP is enabled on an interface (see the <ref column="lldp" > > - table="Interface"/> column in the <ref table="Interface"/> table), > > - the interface processes received LLDP packets and never passes them > > - to OpenFlow or forwards them. > > - </li> > > - </ul> > > - > > - <p> > > - Set this option to <code>true</code> if the Open vSwitch bridge > > - connects different Ethernet networks and is not configured to > > - participate in STP. > > - </p> > > - > > - <p> > > - This option affects packets with the following destination MAC > > - addresses: > > - </p> > > + </p> > > + > > + <p> > > + The above general rule has the following exceptions: > > + </p> > > + > > + <ul> > > + <li> > > + If STP is enabled on the bridge (see the <ref column="stp_enable" > > + table="Bridge"/> column in the <ref table="Bridge"/> table), the > > + bridge processes all received STP packets and never passes them to > > + OpenFlow or forwards them. This is true even if STP is disabled on > > + an individual port. > > + </li> > > + > > + <li> > > + If LLDP is enabled on an interface (see the <ref column="lldp" > > + table="Interface"/> column in the <ref table="Interface"/> table), > > + the interface processes received LLDP packets and never passes them > > + to OpenFlow or forwards them. > > + </li> > > + </ul> > > + > > + <p> > > + Set this option to <code>true</code> if the Open vSwitch bridge > > + connects different Ethernet networks and is not configured to > > + participate in STP. > > + </p> > > + > > + <p> > > + This option affects packets with the following destination MAC > > + addresses: > > + </p> > > > > <dl> > > <dt><code>01:80:c2:00:00:00</code></dt> > > @@ -1036,8 +1036,8 @@ > > <dd>Extreme Discovery Protocol (EDP).</dd> > > > > <dt> > > - <code>00:e0:2b:00:00:04</code> and <code>00:e0:2b:00:00:06</code> > > - </dt> > > + <code>00:e0:2b:00:00:04</code> and <code>00:e0:2b:00:00:06</code> > > + </dt> > > <dd>Ethernet Automatic Protection Switching (EAPS).</dd> > > > > <dt><code>01:00:0c:cc:cc:cc</code></dt> > > @@ -1099,8 +1099,8 @@ > > <column name="external_ids"/> > > </group> > > </table> > > - > > - <table name="Port" table="Port or bond configuration."> > > + > > + <table name="Port" table="Port or bond configuration."> > > <p>A port within a <ref table="Bridge"/>.</p> > > <p>Most commonly, a port has exactly one ``interface,'' pointed to by its > > <ref column="interfaces"/> column. Such a port logically > > @@ -1382,7 +1382,7 @@ > > </column> > > > > <column name="other_config" key="lacp-time" > > - type='{"type": "string", "enum": ["set", ["fast", "slow"]]}'> > > + type='{"type": "string", "enum": ["set", ["fast", "slow"]]}'> > > <p> > > The LACP timing which should be used on this <ref table="Port"/>. > > By default <code>slow</code> is used. When configured to be > > @@ -1394,7 +1394,7 @@ > > </column> > > > > <column name="other_config" key="lacp-fallback-ab" > > - type='{"type": "boolean"}'> > > + type='{"type": "boolean"}'> > > <p> > > Determines the behavior of openvswitch bond in LACP mode. If > > the partner switch does not support LACP, setting this option > > @@ -1753,57 +1753,57 @@ > > </column> > > > > <group title="OpenFlow Port Number"> > > - <p> > > - When a client adds a new interface, Open vSwitch chooses an OpenFlow > > - port number for the new port. If the client that adds the port fills > > - in <ref column="ofport_request"/>, then Open vSwitch tries to use its > > - value as the OpenFlow port number. Otherwise, or if the requested > > - port number is already in use or cannot be used for another reason, > > - Open vSwitch automatically assigns a free port number. Regardless of > > - how the port number was obtained, Open vSwitch then reports in <ref > > - column="ofport"/> the port number actually assigned. > > - </p> > > - > > - <p> > > - Open vSwitch limits the port numbers that it automatically assigns to > > - the range 1 through 32,767, inclusive. Controllers therefore have > > - free use of ports 32,768 and up. > > - </p> > > - > > - <column name="ofport"> > > - <p> > > - OpenFlow port number for this interface. Open vSwitch sets this > > - column's value, so other clients should treat it as read-only. > > - </p> > > - <p> > > - The OpenFlow ``local'' port (<code>OFPP_LOCAL</code>) is 65,534. > > - The other valid port numbers are in the range 1 to 65,279, > > - inclusive. Value -1 indicates an error adding the interface. > > - </p> > > - </column> > > - > > - <column name="ofport_request" > > - type='{"type": "integer", "minInteger": 1, "maxInteger": 65279}'> > > - <p> > > - Requested OpenFlow port number for this interface. > > - </p> > > - > > - <p> > > - A client should ideally set this column's value in the same > > - database transaction that it uses to create the interface. Open > > - vSwitch version 2.1 and later will honor a later request for a > > - specific port number, althuogh it might confuse some controllers: > > - OpenFlow does not have a way to announce a port number change, so > > - Open vSwitch represents it over OpenFlow as a port deletion > > - followed immediately by a port addition. > > - </p> > > - > > - <p> > > - If <ref column="ofport_request"/> is set or changed to some other > > - port's automatically assigned port number, Open vSwitch chooses a > > - new port number for the latter port. > > - </p> > > - </column> > > + <p> > > + When a client adds a new interface, Open vSwitch chooses an OpenFlow > > + port number for the new port. If the client that adds the port fills > > + in <ref column="ofport_request"/>, then Open vSwitch tries to use its > > + value as the OpenFlow port number. Otherwise, or if the requested > > + port number is already in use or cannot be used for another reason, > > + Open vSwitch automatically assigns a free port number. Regardless of > > + how the port number was obtained, Open vSwitch then reports in <ref > > + column="ofport"/> the port number actually assigned. > > + </p> > > + > > + <p> > > + Open vSwitch limits the port numbers that it automatically assigns to > > + the range 1 through 32,767, inclusive. Controllers therefore have > > + free use of ports 32,768 and up. > > + </p> > > + > > + <column name="ofport"> > > + <p> > > + OpenFlow port number for this interface. Open vSwitch sets this > > + column's value, so other clients should treat it as read-only. > > + </p> > > + <p> > > + The OpenFlow ``local'' port (<code>OFPP_LOCAL</code>) is 65,534. > > + The other valid port numbers are in the range 1 to 65,279, > > + inclusive. Value -1 indicates an error adding the interface. > > + </p> > > + </column> > > + > > + <column name="ofport_request" > > + type='{"type": "integer", "minInteger": 1, "maxInteger": 65279}'> > > + <p> > > + Requested OpenFlow port number for this interface. > > + </p> > > + > > + <p> > > + A client should ideally set this column's value in the same > > + database transaction that it uses to create the interface. Open > > + vSwitch version 2.1 and later will honor a later request for a > > + specific port number, althuogh it might confuse some controllers: > > + OpenFlow does not have a way to announce a port number change, so > > + Open vSwitch represents it over OpenFlow as a port deletion > > + followed immediately by a port addition. > > + </p> > > + > > + <p> > > + If <ref column="ofport_request"/> is set or changed to some other > > + port's automatically assigned port number, Open vSwitch chooses a > > + new port number for the latter port. > > + </p> > > + </column> > > </group> > > </group> > > > > @@ -1858,15 +1858,15 @@ > > > > <dt><code>vxlan</code></dt> > > <dd> > > - <p> > > - An Ethernet tunnel over the UDP-based VXLAN protocol described in > > - RFC 7348. > > - </p> > > - <p> > > - Open vSwitch uses UDP destination port 4789. The source port used for > > - VXLAN traffic varies on a per-flow basis and is in the ephemeral port > > - range. > > - </p> > > + <p> > > + An Ethernet tunnel over the UDP-based VXLAN protocol described in > > + RFC 7348. > > + </p> > > + <p> > > + Open vSwitch uses UDP destination port 4789. The source port used for > > + VXLAN traffic varies on a per-flow basis and is in the ephemeral port > > + range. > > + </p> > > </dd> > > > > <dt><code>lisp</code></dt> > > @@ -1887,21 +1887,21 @@ > > > > <dt><code>stt</code></dt> > > <dd> > > - The Stateless TCP Tunnel (STT) is particularly useful when tunnel > > - endpoints are in end-systems, as it utilizes the capabilities of > > - standard network interface cards to improve performance. STT utilizes > > - a TCP-like header inside the IP header. It is stateless, i.e., there is > > - no TCP connection state of any kind associated with the tunnel. The > > - TCP-like header is used to leverage the capabilities of existing > > - network interface cards, but should not be interpreted as implying > > - any sort of connection state between endpoints. > > - Since the STT protocol does not engage in the usual TCP 3-way handshake, > > - so it will have difficulty traversing stateful firewalls. > > - The protocol is documented at > > - http://www.ietf.org/archive/id/draft-davie-stt-06.txt > > - > > - All traffic uses a default destination port of 7471. STT is only > > - available in kernel datapath on kernel 3.5 or newer. > > + The Stateless TCP Tunnel (STT) is particularly useful when tunnel > > + endpoints are in end-systems, as it utilizes the capabilities of > > + standard network interface cards to improve performance. STT utilizes > > + a TCP-like header inside the IP header. It is stateless, i.e., there is > > + no TCP connection state of any kind associated with the tunnel. The > > + TCP-like header is used to leverage the capabilities of existing > > + network interface cards, but should not be interpreted as implying > > + any sort of connection state between endpoints. > > + Since the STT protocol does not engage in the usual TCP 3-way handshake, > > + so it will have difficulty traversing stateful firewalls. > > + The protocol is documented at > > + http://www.ietf.org/archive/id/draft-davie-stt-06.txt > > + > > + All traffic uses a default destination port of 7471. STT is only > > + available in kernel datapath on kernel 3.5 or newer. > > </dd> > > > > <dt><code>patch</code></dt> > > @@ -1911,7 +1911,7 @@ > > > > <dt><code>null</code></dt> > > <dd>An ignored interface. Deprecated and slated for removal in > > - February 2013.</dd> > > + February 2013.</dd> > > </dl> > > </column> > > </group> > > @@ -1955,9 +1955,9 @@ > > </ul> > > > > <p> > > - The remote tunnel endpoint for any packet received from a tunnel > > - is available in the <code>tun_src</code> field for matching in the > > - flow table. > > + The remote tunnel endpoint for any packet received from a tunnel > > + is available in the <code>tun_src</code> field for matching in the > > + flow table. > > </p> > > </column> > > > > @@ -2079,23 +2079,23 @@ > > > > <group title="Tunnel Options: vxlan only"> > > > > - <column name="options" key="exts"> > > - <p>Optional. Comma separated list of optional VXLAN extensions to > > - enable. The following extensions are supported:</p> > > + <column name="options" key="exts"> > > + <p>Optional. Comma separated list of optional VXLAN extensions to > > + enable. The following extensions are supported:</p> > > > > - <ul> > > - <li> > > - <code>gbp</code>: VXLAN-GBP allows to transport the group policy > > - context of a packet across the VXLAN tunnel to other network > > - peers. See the field description of <code>tun_gbp_id</code> and > > - <code>tun_gbp_flags</code> in ovs-ofctl(8) for additional > > - information. > > - (<code>https://tools.ietf.org/html/draft-smith-vxlan-group-policy</code>) > > - </li> > > - </ul> > > - </column> > > + <ul> > > + <li> > > + <code>gbp</code>: VXLAN-GBP allows to transport the group policy > > + context of a packet across the VXLAN tunnel to other network > > + peers. See the field description of <code>tun_gbp_id</code> and > > + <code>tun_gbp_flags</code> in ovs-ofctl(8) for additional > > + information. > > + (<code>https://tools.ietf.org/html/draft-smith-vxlan-group-policy</code>) > > + </li> > > + </ul> > > + </column> > > > > - </group> > > + </group> > > > > <group title="Tunnel Options: gre, ipsec_gre, geneve, and vxlan"> > > <p> > > @@ -2109,7 +2109,7 @@ > > checksums on outgoing packets. Default is disabled, set to > > <code>true</code> to enable. Checksums present on incoming > > packets will be validated regardless of this setting. > > - </p> > > + </p> > > > > <p> > > When using the upstream Linux kernel module, computation of > > @@ -2122,9 +2122,9 @@ > > </p> > > > > <p> > > - This option is supported for <code>ipsec_gre</code>, but not useful > > - because GRE checksums are weaker than, and redundant with, IPsec > > - payload authentication. > > + This option is supported for <code>ipsec_gre</code>, but not useful > > + because GRE checksums are weaker than, and redundant with, IPsec > > + payload authentication. > > </p> > > </column> > > </group> > > @@ -2419,70 +2419,70 @@ > > > > <group title="Bidirectional Forwarding Detection (BFD)"> > > <p> > > - BFD, defined in RFC 5880 and RFC 5881, allows point-to-point > > - detection of connectivity failures by occasional transmission of > > - BFD control messages. Open vSwitch implements BFD to serve > > - as a more popular and standards compliant alternative to CFM. > > + BFD, defined in RFC 5880 and RFC 5881, allows point-to-point > > + detection of connectivity failures by occasional transmission of > > + BFD control messages. Open vSwitch implements BFD 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 is willing to transmit them. Open vSwitch uses a detection > > - multiplier of three, meaning that an endpoint signals a connectivity > > - fault if three consecutive BFD control messages fail to arrive. In the > > - case of a unidirectional connectivity issue, the system not receiving > > - BFD control messages signals the problem to its peer in the messages it > > - transmits. > > + 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 is willing to transmit them. Open vSwitch uses a detection > > + multiplier of three, meaning that an endpoint signals a connectivity > > + fault if three consecutive BFD control messages fail to arrive. In the > > + case of a unidirectional connectivity issue, the system not receiving > > + BFD control messages signals the problem to its peer in the messages it > > + transmits. > > </p> > > > > <p> > > - The Open vSwitch implementation of BFD aims to comply faithfully > > - with RFC 5880 requirements. Open vSwitch does not implement the > > - optional Authentication or ``Echo Mode'' features. > > + The Open vSwitch implementation of BFD aims to comply faithfully > > + with RFC 5880 requirements. Open vSwitch does not implement the > > + optional Authentication or ``Echo Mode'' features. > > </p> > > > > <group title="BFD Configuration"> > > - <p> > > - A controller sets up key-value pairs in the <ref column="bfd"/> > > - column to enable and configure BFD. > > - </p> > > + <p> > > + A controller sets up key-value pairs in the <ref column="bfd"/> > > + column to enable and configure BFD. > > + </p> > > > > - <column name="bfd" key="enable" type='{"type": "boolean"}'> > > + <column name="bfd" key="enable" type='{"type": "boolean"}'> > > True to enable BFD on this <ref table="Interface"/>. If not > > specified, BFD will not be enabled by default. > > - </column> > > + </column> > > > > - <column name="bfd" key="min_rx" > > - type='{"type": "integer", "minInteger": 1}'> > > + <column name="bfd" key="min_rx" > > + type='{"type": "integer", "minInteger": 1}'> > > The shortest interval, in milliseconds, at which this BFD session > > offers to receive BFD control messages. The remote endpoint may > > choose to send messages at a slower rate. Defaults to > > <code>1000</code>. > > - </column> > > + </column> > > > > - <column name="bfd" key="min_tx" > > - type='{"type": "integer", "minInteger": 1}'> > > + <column name="bfd" key="min_tx" > > + type='{"type": "integer", "minInteger": 1}'> > > The shortest interval, in milliseconds, at which this BFD session is > > willing to transmit BFD control messages. Messages will actually be > > transmitted at a slower rate if the remote endpoint is not willing to > > receive as quickly as specified. Defaults to <code>100</code>. > > - </column> > > - > > - <column name="bfd" key="decay_min_rx" type='{"type": "integer"}'> > > - An alternate receive interval, in milliseconds, that must be greater > > - than or equal to <ref column="bfd" key="min_rx"/>. The > > - implementation switches from <ref column="bfd" key="min_rx"/> to <ref > > - column="bfd" key="decay_min_rx"/> when there is no obvious incoming > > - data traffic at the interface, to reduce the CPU and bandwidth cost > > - of monitoring an idle interface. This feature may be disabled by > > - setting a value of 0. This feature is reset whenever <ref > > - column="bfd" key="decay_min_rx"/> or <ref column="bfd" key="min_rx"/> > > - changes. > > - </column> > > - > > - <column name="bfd" key="forwarding_if_rx" type='{"type": "boolean"}'> > > + </column> > > + > > + <column name="bfd" key="decay_min_rx" type='{"type": "integer"}'> > > + An alternate receive interval, in milliseconds, that must be greater > > + than or equal to <ref column="bfd" key="min_rx"/>. The > > + implementation switches from <ref column="bfd" key="min_rx"/> to <ref > > + column="bfd" key="decay_min_rx"/> when there is no obvious incoming > > + data traffic at the interface, to reduce the CPU and bandwidth cost > > + of monitoring an idle interface. This feature may be disabled by > > + setting a value of 0. This feature is reset whenever <ref > > + column="bfd" key="decay_min_rx"/> or <ref column="bfd" key="min_rx"/> > > + changes. > > + </column> > > + > > + <column name="bfd" key="forwarding_if_rx" type='{"type": "boolean"}'> > > When <code>true</code>, traffic received on the > > <ref table="Interface"/> is used to indicate the capability of packet > > I/O. BFD control packets are still transmitted and received. At > > @@ -2490,98 +2490,98 @@ > > column="bfd" key="min_rx"/> amount of time. Otherwise, even if > > traffic are received, the <ref column="bfd" key="forwarding"/> > > will be <code>false</code>. > > - </column> > > + </column> > > > > - <column name="bfd" key="cpath_down" type='{"type": "boolean"}'> > > - Set to true to notify the remote endpoint that traffic should not be > > - forwarded to this system for some reason other than a connectivty > > - failure on the interface being monitored. The typical underlying > > - reason is ``concatenated path down,'' that is, that connectivity > > - beyond the local system is down. Defaults to false. > > - </column> > > + <column name="bfd" key="cpath_down" type='{"type": "boolean"}'> > > + Set to true to notify the remote endpoint that traffic should not be > > + forwarded to this system for some reason other than a connectivty > > + failure on the interface being monitored. The typical underlying > > + reason is ``concatenated path down,'' that is, that connectivity > > + beyond the local system is down. Defaults to false. > > + </column> > > > > - <column name="bfd" key="check_tnl_key" type='{"type": "boolean"}'> > > + <column name="bfd" key="check_tnl_key" type='{"type": "boolean"}'> > > Set to true to make BFD accept only control messages with a tunnel > > key of zero. By default, BFD accepts control messages with any > > tunnel key. > > - </column> > > - > > - <column name="bfd" key="bfd_local_src_mac"> > > - Set to an Ethernet address in the form > > - <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var> > > - to set the MAC used as source for transmitted BFD packets. The > > - default is the mac address of the BFD enabled interface. > > - </column> > > - > > - <column name="bfd" key="bfd_local_dst_mac"> > > - Set to an Ethernet address in the form > > - <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var> > > - to set the MAC used as destination for transmitted BFD packets. The > > - default is <code>00:23:20:00:00:01</code>. > > - </column> > > - > > - <column name="bfd" key="bfd_remote_dst_mac"> > > - Set to an Ethernet address in the form > > - <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var> > > - to set the MAC used for checking the destination of received BFD packets. > > - Packets with different destination MAC will not be considered as BFD packets. > > - If not specified the destination MAC address of received BFD packets > > - are not checked. > > - </column> > > - > > - <column name="bfd" key="bfd_src_ip"> > > + </column> > > + > > + <column name="bfd" key="bfd_local_src_mac"> > > + Set to an Ethernet address in the form > > + <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var> > > + to set the MAC used as source for transmitted BFD packets. The > > + default is the mac address of the BFD enabled interface. > > + </column> > > + > > + <column name="bfd" key="bfd_local_dst_mac"> > > + Set to an Ethernet address in the form > > + <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var> > > + to set the MAC used as destination for transmitted BFD packets. The > > + default is <code>00:23:20:00:00:01</code>. > > + </column> > > + > > + <column name="bfd" key="bfd_remote_dst_mac"> > > + Set to an Ethernet address in the form > > + <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var> > > + to set the MAC used for checking the destination of received BFD packets. > > + Packets with different destination MAC will not be considered as BFD packets. > > + If not specified the destination MAC address of received BFD packets > > + are not checked. > > + </column> > > + > > + <column name="bfd" key="bfd_src_ip"> > > Set to an IPv4 address to set the IP address used as source for > > transmitted BFD packets. The default is <code>169.254.1.1</code>. > > - </column> > > + </column> > > > > - <column name="bfd" key="bfd_dst_ip"> > > + <column name="bfd" key="bfd_dst_ip"> > > Set to an IPv4 address to set the IP address used as destination > > for transmitted BFD packets. The default is <code>169.254.1.0</code>. > > - </column> > > + </column> > > </group> > > > > <group title="BFD Status"> > > - <p> > > - The switch sets key-value pairs in the <ref column="bfd_status"/> > > - column to report the status of BFD on this interface. When BFD is > > - not enabled, with <ref column="bfd" key="enable"/>, the switch clears > > - all key-value pairs from <ref column="bfd_status"/>. > > - </p> > > - > > - <column name="bfd_status" key="state" > > - type='{"type": "string", > > - "enum": ["set", ["admin_down", "down", "init", "up"]]}'> > > - Reports the state of the BFD session. The BFD session is fully > > - healthy and negotiated if <code>UP</code>. > > - </column> > > - > > - <column name="bfd_status" key="forwarding" type='{"type": "boolean"}'> > > - Reports whether the BFD session believes this <ref > > - table="Interface"/> may be used to forward traffic. Typically this > > - means the local session is signaling <code>UP</code>, and the remote > > - system isn't signaling a problem such as concatenated path down. > > - </column> > > - > > - <column name="bfd_status" key="diagnostic"> > > - In case of a problem, set to an error message that reports what the > > - local BFD session thinks is wrong. The error messages are defined > > - in section 4.1 of [RFC 5880]. > > - </column> > > - > > - <column name="bfd_status" key="remote_state" > > - type='{"type": "string", > > - "enum": ["set", ["admin_down", "down", "init", "up"]]}'> > > - Reports the state of the remote endpoint's BFD session. > > - </column> > > - > > - <column name="bfd_status" key="remote_diagnostic"> > > - In case of a problem, set to an error message that reports what the > > - remote endpoint's BFD session thinks is wrong. The error messages > > - are defined in section 4.1 of [RFC 5880]. > > - </column> > > + <p> > > + The switch sets key-value pairs in the <ref column="bfd_status"/> > > + column to report the status of BFD on this interface. When BFD is > > + not enabled, with <ref column="bfd" key="enable"/>, the switch clears > > + all key-value pairs from <ref column="bfd_status"/>. > > + </p> > > + > > + <column name="bfd_status" key="state" > > + type='{"type": "string", > > + "enum": ["set", ["admin_down", "down", "init", "up"]]}'> > > + Reports the state of the BFD session. The BFD session is fully > > + healthy and negotiated if <code>UP</code>. > > + </column> > > + > > + <column name="bfd_status" key="forwarding" type='{"type": "boolean"}'> > > + Reports whether the BFD session believes this <ref > > + table="Interface"/> may be used to forward traffic. Typically this > > + means the local session is signaling <code>UP</code>, and the remote > > + system isn't signaling a problem such as concatenated path down. > > + </column> > > + > > + <column name="bfd_status" key="diagnostic"> > > + In case of a problem, set to an error message that reports what the > > + local BFD session thinks is wrong. The error messages are defined > > + in section 4.1 of [RFC 5880]. > > + </column> > > + > > + <column name="bfd_status" key="remote_state" > > + type='{"type": "string", > > + "enum": ["set", ["admin_down", "down", "init", "up"]]}'> > > + Reports the state of the remote endpoint's BFD session. > > + </column> > > + > > + <column name="bfd_status" key="remote_diagnostic"> > > + In case of a problem, set to an error message that reports what the > > + remote endpoint's BFD session thinks is wrong. The error messages > > + are defined in section 4.1 of [RFC 5880]. > > + </column> > > > > <column name="bfd_status" key="flap_count" > > - type='{"type": "integer", "minInteger": 0}'> > > + type='{"type": "integer", "minInteger": 0}'> > > Counts the number of <ref column="bfd_status" key="forwarding" /> > > flaps since start. A flap is considered as a change of the > > <ref column="bfd_status" key="forwarding" /> value. > > @@ -2609,9 +2609,9 @@ > > </p> > > > > <p> > > - When operating over tunnels which have no <code>in_key</code>, or an > > - <code>in_key</code> of <code>flow</code>. CFM will only accept CCMs > > - with a tunnel key of zero. > > + When operating over tunnels which have no <code>in_key</code>, or an > > + <code>in_key</code> of <code>flow</code>. CFM will only accept CCMs > > + with a tunnel key of zero. > > </p> > > > > <column name="cfm_mpid"> > > @@ -2696,8 +2696,8 @@ > > > > <column name="cfm_remote_opstate"> > > <p>When in extended mode, indicates the operational state of the > > - remote endpoint as either <code>up</code> or <code>down</code>. See > > - <ref column="other_config" key="cfm_opstate"/>. > > + remote endpoint as either <code>up</code> or <code>down</code>. See > > + <ref column="other_config" key="cfm_opstate"/>. > > </p> > > </column> > > > > @@ -2773,7 +2773,7 @@ > > </p> > > > > <p> > > - Demand mode has a couple of caveats: > > + Demand mode has a couple of caveats: > > <ul> > > <li> > > To ensure that ovs-vswitchd has enough time to pull statistics > > @@ -2811,14 +2811,14 @@ > > </column> > > > > <column name="other_config" key="cfm_ccm_vlan" > > - type='{"type": "integer", "minInteger": 1, "maxInteger": 4095}'> > > + type='{"type": "integer", "minInteger": 1, "maxInteger": 4095}'> > > When set, the CFM module will apply a VLAN tag to all CCMs it generates > > with the given value. May be the string <code>random</code> in which > > case each CCM will be tagged with a different randomly generated VLAN. > > </column> > > > > <column name="other_config" key="cfm_ccm_pcp" > > - type='{"type": "integer", "minInteger": 1, "maxInteger": 7}'> > > + type='{"type": "integer", "minInteger": 1, "maxInteger": 7}'> > > When set, the CFM module will apply a VLAN tag to all CCMs it generates > > with the given PCP value, the VLAN ID of the tag is governed by the > > value of <ref column="other_config" key="cfm_ccm_vlan"/>. If > > @@ -2926,17 +2926,17 @@ > > > > <group title="VLAN Splinters"> > > <p> > > - The ``VLAN splinters'' feature increases Open vSwitch compatibility > > - with buggy network drivers in old versions of Linux that do not > > - properly support VLANs when VLAN devices are not used, at some cost > > - in memory and performance. > > + The ``VLAN splinters'' feature increases Open vSwitch compatibility > > + with buggy network drivers in old versions of Linux that do not > > + properly support VLANs when VLAN devices are not used, at some cost > > + in memory and performance. > > </p> > > > > <p> > > - When VLAN splinters are enabled on a particular interface, Open vSwitch > > - creates a VLAN device for each in-use VLAN. For sending traffic tagged > > - with a VLAN on the interface, it substitutes the VLAN device. Traffic > > - received on the VLAN device is treated as if it had been received on > > + When VLAN splinters are enabled on a particular interface, Open vSwitch > > + creates a VLAN device for each in-use VLAN. For sending traffic tagged > > + with a VLAN on the interface, it substitutes the VLAN device. Traffic > > + received on the VLAN device is treated as if it had been received on > > the interface on the particular VLAN. > > </p> > > > > @@ -2978,8 +2978,8 @@ > > </p> > > > > <p> > > - VLAN splinters are deprecated. When broken device drivers are no > > - longer in widespread use, we will delete this feature. > > + VLAN splinters are deprecated. When broken device drivers are no > > + longer in widespread use, we will delete this feature. > > </p> > > > > <column name="other_config" key="enable-vlan-splinters" > > @@ -3004,12 +3004,12 @@ > > > > <group title="Auto Attach Configuration"> > > <p> > > - Auto Attach configuration for a particular interface. > > + Auto Attach configuration for a particular interface. > > </p> > > > > <column name="lldp" key="enable" type='{"type": "boolean"}'> > > - True to enable LLDP on this <ref table="Interface"/>. If not > > - specified, LLDP will be disabled by default. > > + True to enable LLDP on this <ref table="Interface"/>. If not > > + specified, LLDP will be disabled by default. > > </column> > > </group> > > > > @@ -3986,7 +3986,7 @@ > > </p> > > > > <column name="other_config" key="dscp" > > - type='{"type": "integer"}'> > > + 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 > > @@ -4252,11 +4252,11 @@ > > </column> > > > > <column name="status" key="bound_port" type='{"type": "integer"}'> > > - When <ref column="target"/> is <code>ptcp:</code> or > > - <code>pssl:</code>, this is the TCP port on which the OVSDB server is > > - listening. (This is is particularly useful when <ref > > - column="target"/> specifies a port of 0, allowing the kernel to > > - choose any available port.) > > + When <ref column="target"/> is <code>ptcp:</code> or > > + <code>pssl:</code>, this is the TCP port on which the OVSDB server is > > + listening. (This is is particularly useful when <ref > > + column="target"/> specifies a port of 0, allowing the kernel to > > + choose any available port.) > > </column> > > </group> > > > > @@ -4267,7 +4267,7 @@ > > </p> > > > > <column name="other_config" key="dscp" > > - type='{"type": "integer"}'> > > + 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 > > @@ -4312,18 +4312,18 @@ > > > > <column name="active_timeout"> > > <p> > > - The interval at which NetFlow records are sent for flows that > > - are still active, in seconds. A value of <code>0</code> > > - requests the default timeout (currently 600 seconds); a value > > - of <code>-1</code> disables active timeouts. > > + The interval at which NetFlow records are sent for flows that > > + are still active, in seconds. A value of <code>0</code> > > + requests the default timeout (currently 600 seconds); a value > > + of <code>-1</code> disables active timeouts. > > </p> > > > > <p> > > - The NetFlow passive timeout, for flows that become inactive, > > - is not configurable. It will vary depending on the Open > > - vSwitch version, the forms and contents of the OpenFlow flow > > - tables, CPU and memory usage, and network activity. A typical > > - passive timeout is about a second. > > + The NetFlow passive timeout, for flows that become inactive, > > + is not configurable. It will vary depending on the Open > > + vSwitch version, the forms and contents of the OpenFlow flow > > + tables, CPU and memory usage, and network activity. A typical > > + passive timeout is about a second. > > </p> > > </column> > > > > @@ -4650,39 +4650,46 @@ > > </table> > > > > <table name="AutoAttach"> > > - <p>Auto Attach configuration within a bridge. The IETF Auto-Attach SPBM > > - draft standard describes a compact method of using IEEE 802.1AB Link > > - Layer Discovery Protocol (LLDP) together with a IEEE 802.1aq Shortest > > - Path Bridging (SPB) network to automatically attach network devices > > - to individual services in a SPB network. The intent here is to allow > > - network applications and devices using OVS to be able to easily take > > - advantage of features offered by industry standard SPB networks.</p> > > - > > - <p>Auto Attach (AA) uses LLDP to communicate between a directly connected > > - Auto Attach Client (AAC) and Auto Attach Server (AAS). The LLDP protocol > > - is extended to add two new Type-Length-Value tuples (TLVs). The first > > - new TLV supports the ongoing discovery of directly connected AA > > - correspondents. Auto Attach operates by regularly transmitting AA > > - discovery TLVs between the AA client and AA server. By exchanging these > > - discovery messages, both the AAC and AAS learn the system name and > > - system description of their peer. In the OVS context, OVS operates as > > - the AA client and the AA server resides on a switch at the edge of the > > - SPB network.</p> > > - > > - <p>Once AA discovery has been completed the AAC then uses the > > - second new TLV to deliver identifier mappings from the AAC to the AAS. A primary > > - feature of Auto Attach is to facilitate the mapping of VLANs defined > > - outside the SPB network onto service ids (ISIDs) defined within the SPM > > - network. By doing so individual external VLANs can be mapped onto > > - specific SPB network services. These VLAN id to ISID mappings can be > > - configured and managed locally using new options added to the ovs-vsctl > > - command.</p> > > - > > - <p>The Auto Attach OVS feature does not provide a full implementation of > > - the LLDP protocol. Support for the mandatory TLVs as defined by the LLDP > > - standard and support for the AA TLV extensions is provided. LLDP > > - protocol support in OVS can be enabled or disabled on a port by port > > - basis. LLDP support is disabled by default.</p> > > + <p> > > + Auto Attach configuration within a bridge. The IETF Auto-Attach SPBM > > + draft standard describes a compact method of using IEEE 802.1AB Link > > + Layer Discovery Protocol (LLDP) together with a IEEE 802.1aq Shortest > > + Path Bridging (SPB) network to automatically attach network devices > > + to individual services in a SPB network. The intent here is to allow > > + network applications and devices using OVS to be able to easily take > > + advantage of features offered by industry standard SPB networks. > > + </p> > > + > > + <p> > > + Auto Attach (AA) uses LLDP to communicate between a directly connected > > + Auto Attach Client (AAC) and Auto Attach Server (AAS). The LLDP protocol > > + is extended to add two new Type-Length-Value tuples (TLVs). The first > > + new TLV supports the ongoing discovery of directly connected AA > > + correspondents. Auto Attach operates by regularly transmitting AA > > + discovery TLVs between the AA client and AA server. By exchanging these > > + discovery messages, both the AAC and AAS learn the system name and > > + system description of their peer. In the OVS context, OVS operates as > > + the AA client and the AA server resides on a switch at the edge of the > > + SPB network. > > + </p> > > + > > + <p> > > + Once AA discovery has been completed the AAC then uses the second new TLV > > + to deliver identifier mappings from the AAC to the AAS. A primary feature > > + of Auto Attach is to facilitate the mapping of VLANs defined outside the > > + SPB network onto service ids (ISIDs) defined within the SPM network. By > > + doing so individual external VLANs can be mapped onto specific SPB > > + network services. These VLAN id to ISID mappings can be configured and > > + managed locally using new options added to the ovs-vsctl command. > > + </p> > > + > > + <p> > > + The Auto Attach OVS feature does not provide a full implementation of > > + the LLDP protocol. Support for the mandatory TLVs as defined by the LLDP > > + standard and support for the AA TLV extensions is provided. LLDP > > + protocol support in OVS can be enabled or disabled on a port by port > > + basis. LLDP support is disabled by default. > > + </p> > > > > <column name="system_name"> > > The system_name string is exported in LLDP messages. It should uniquely > > @@ -4695,7 +4702,8 @@ > > </column> > > > > <column name="mappings"> > > - A mapping from SPB network Individual Service Identifier (ISID) to VLAN id. > > + A mapping from SPB network Individual Service Identifier (ISID) to VLAN > > + id. > > </column> > > </table> > > </database> > > -- > > 2.1.3 > > >
diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml index 0ab4a9a..c94f42d 100644 --- a/vswitchd/vswitch.xml +++ b/vswitchd/vswitch.xml @@ -530,7 +530,7 @@ </column> <column name="auto_attach"> - Auto Attach configuration. + Auto Attach configuration. </column> </group> @@ -685,16 +685,16 @@ </column> <column name="protocols"> - <p> - List of OpenFlow protocols that may be used when negotiating - a connection with a controller. OpenFlow 1.0, 1.1, 1.2, and - 1.3 are enabled by default if this column is empty. - </p> + <p> + List of OpenFlow protocols that may be used when negotiating + a connection with a controller. OpenFlow 1.0, 1.1, 1.2, and + 1.3 are enabled by default if this column is empty. + </p> - <p> - OpenFlow 1.4 is not enabled by default because its implementation is - missing features. - </p> + <p> + OpenFlow 1.4 is not enabled by default because its implementation is + missing features. + </p> <p> OpenFlow 1.5 has the same risks as OpenFlow 1.4, but it is even more @@ -982,45 +982,45 @@ <column name="other_config" key="forward-bpdu" type='{"type": "boolean"}'> - <p> + <p> Controls forwarding of BPDUs and other network control frames when NORMAL action is invoked. When this option is <code>false</code> or unset, frames with reserved Ethernet addresses (see table below) will not be forwarded. When this option is <code>true</code>, such frames will not be treated specially. - </p> - - <p> - The above general rule has the following exceptions: - </p> - - <ul> - <li> - If STP is enabled on the bridge (see the <ref column="stp_enable" - table="Bridge"/> column in the <ref table="Bridge"/> table), the - bridge processes all received STP packets and never passes them to - OpenFlow or forwards them. This is true even if STP is disabled on - an individual port. - </li> - - <li> - If LLDP is enabled on an interface (see the <ref column="lldp" - table="Interface"/> column in the <ref table="Interface"/> table), - the interface processes received LLDP packets and never passes them - to OpenFlow or forwards them. - </li> - </ul> - - <p> - Set this option to <code>true</code> if the Open vSwitch bridge - connects different Ethernet networks and is not configured to - participate in STP. - </p> - - <p> - This option affects packets with the following destination MAC - addresses: - </p> + </p> + + <p> + The above general rule has the following exceptions: + </p> + + <ul> + <li> + If STP is enabled on the bridge (see the <ref column="stp_enable" + table="Bridge"/> column in the <ref table="Bridge"/> table), the + bridge processes all received STP packets and never passes them to + OpenFlow or forwards them. This is true even if STP is disabled on + an individual port. + </li> + + <li> + If LLDP is enabled on an interface (see the <ref column="lldp" + table="Interface"/> column in the <ref table="Interface"/> table), + the interface processes received LLDP packets and never passes them + to OpenFlow or forwards them. + </li> + </ul> + + <p> + Set this option to <code>true</code> if the Open vSwitch bridge + connects different Ethernet networks and is not configured to + participate in STP. + </p> + + <p> + This option affects packets with the following destination MAC + addresses: + </p> <dl> <dt><code>01:80:c2:00:00:00</code></dt> @@ -1036,8 +1036,8 @@ <dd>Extreme Discovery Protocol (EDP).</dd> <dt> - <code>00:e0:2b:00:00:04</code> and <code>00:e0:2b:00:00:06</code> - </dt> + <code>00:e0:2b:00:00:04</code> and <code>00:e0:2b:00:00:06</code> + </dt> <dd>Ethernet Automatic Protection Switching (EAPS).</dd> <dt><code>01:00:0c:cc:cc:cc</code></dt> @@ -1099,8 +1099,8 @@ <column name="external_ids"/> </group> </table> - - <table name="Port" table="Port or bond configuration."> + + <table name="Port" table="Port or bond configuration."> <p>A port within a <ref table="Bridge"/>.</p> <p>Most commonly, a port has exactly one ``interface,'' pointed to by its <ref column="interfaces"/> column. Such a port logically @@ -1382,7 +1382,7 @@ </column> <column name="other_config" key="lacp-time" - type='{"type": "string", "enum": ["set", ["fast", "slow"]]}'> + type='{"type": "string", "enum": ["set", ["fast", "slow"]]}'> <p> The LACP timing which should be used on this <ref table="Port"/>. By default <code>slow</code> is used. When configured to be @@ -1394,7 +1394,7 @@ </column> <column name="other_config" key="lacp-fallback-ab" - type='{"type": "boolean"}'> + type='{"type": "boolean"}'> <p> Determines the behavior of openvswitch bond in LACP mode. If the partner switch does not support LACP, setting this option @@ -1753,57 +1753,57 @@ </column> <group title="OpenFlow Port Number"> - <p> - When a client adds a new interface, Open vSwitch chooses an OpenFlow - port number for the new port. If the client that adds the port fills - in <ref column="ofport_request"/>, then Open vSwitch tries to use its - value as the OpenFlow port number. Otherwise, or if the requested - port number is already in use or cannot be used for another reason, - Open vSwitch automatically assigns a free port number. Regardless of - how the port number was obtained, Open vSwitch then reports in <ref - column="ofport"/> the port number actually assigned. - </p> - - <p> - Open vSwitch limits the port numbers that it automatically assigns to - the range 1 through 32,767, inclusive. Controllers therefore have - free use of ports 32,768 and up. - </p> - - <column name="ofport"> - <p> - OpenFlow port number for this interface. Open vSwitch sets this - column's value, so other clients should treat it as read-only. - </p> - <p> - The OpenFlow ``local'' port (<code>OFPP_LOCAL</code>) is 65,534. - The other valid port numbers are in the range 1 to 65,279, - inclusive. Value -1 indicates an error adding the interface. - </p> - </column> - - <column name="ofport_request" - type='{"type": "integer", "minInteger": 1, "maxInteger": 65279}'> - <p> - Requested OpenFlow port number for this interface. - </p> - - <p> - A client should ideally set this column's value in the same - database transaction that it uses to create the interface. Open - vSwitch version 2.1 and later will honor a later request for a - specific port number, althuogh it might confuse some controllers: - OpenFlow does not have a way to announce a port number change, so - Open vSwitch represents it over OpenFlow as a port deletion - followed immediately by a port addition. - </p> - - <p> - If <ref column="ofport_request"/> is set or changed to some other - port's automatically assigned port number, Open vSwitch chooses a - new port number for the latter port. - </p> - </column> + <p> + When a client adds a new interface, Open vSwitch chooses an OpenFlow + port number for the new port. If the client that adds the port fills + in <ref column="ofport_request"/>, then Open vSwitch tries to use its + value as the OpenFlow port number. Otherwise, or if the requested + port number is already in use or cannot be used for another reason, + Open vSwitch automatically assigns a free port number. Regardless of + how the port number was obtained, Open vSwitch then reports in <ref + column="ofport"/> the port number actually assigned. + </p> + + <p> + Open vSwitch limits the port numbers that it automatically assigns to + the range 1 through 32,767, inclusive. Controllers therefore have + free use of ports 32,768 and up. + </p> + + <column name="ofport"> + <p> + OpenFlow port number for this interface. Open vSwitch sets this + column's value, so other clients should treat it as read-only. + </p> + <p> + The OpenFlow ``local'' port (<code>OFPP_LOCAL</code>) is 65,534. + The other valid port numbers are in the range 1 to 65,279, + inclusive. Value -1 indicates an error adding the interface. + </p> + </column> + + <column name="ofport_request" + type='{"type": "integer", "minInteger": 1, "maxInteger": 65279}'> + <p> + Requested OpenFlow port number for this interface. + </p> + + <p> + A client should ideally set this column's value in the same + database transaction that it uses to create the interface. Open + vSwitch version 2.1 and later will honor a later request for a + specific port number, althuogh it might confuse some controllers: + OpenFlow does not have a way to announce a port number change, so + Open vSwitch represents it over OpenFlow as a port deletion + followed immediately by a port addition. + </p> + + <p> + If <ref column="ofport_request"/> is set or changed to some other + port's automatically assigned port number, Open vSwitch chooses a + new port number for the latter port. + </p> + </column> </group> </group> @@ -1858,15 +1858,15 @@ <dt><code>vxlan</code></dt> <dd> - <p> - An Ethernet tunnel over the UDP-based VXLAN protocol described in - RFC 7348. - </p> - <p> - Open vSwitch uses UDP destination port 4789. The source port used for - VXLAN traffic varies on a per-flow basis and is in the ephemeral port - range. - </p> + <p> + An Ethernet tunnel over the UDP-based VXLAN protocol described in + RFC 7348. + </p> + <p> + Open vSwitch uses UDP destination port 4789. The source port used for + VXLAN traffic varies on a per-flow basis and is in the ephemeral port + range. + </p> </dd> <dt><code>lisp</code></dt> @@ -1887,21 +1887,21 @@ <dt><code>stt</code></dt> <dd> - The Stateless TCP Tunnel (STT) is particularly useful when tunnel - endpoints are in end-systems, as it utilizes the capabilities of - standard network interface cards to improve performance. STT utilizes - a TCP-like header inside the IP header. It is stateless, i.e., there is - no TCP connection state of any kind associated with the tunnel. The - TCP-like header is used to leverage the capabilities of existing - network interface cards, but should not be interpreted as implying - any sort of connection state between endpoints. - Since the STT protocol does not engage in the usual TCP 3-way handshake, - so it will have difficulty traversing stateful firewalls. - The protocol is documented at - http://www.ietf.org/archive/id/draft-davie-stt-06.txt - - All traffic uses a default destination port of 7471. STT is only - available in kernel datapath on kernel 3.5 or newer. + The Stateless TCP Tunnel (STT) is particularly useful when tunnel + endpoints are in end-systems, as it utilizes the capabilities of + standard network interface cards to improve performance. STT utilizes + a TCP-like header inside the IP header. It is stateless, i.e., there is + no TCP connection state of any kind associated with the tunnel. The + TCP-like header is used to leverage the capabilities of existing + network interface cards, but should not be interpreted as implying + any sort of connection state between endpoints. + Since the STT protocol does not engage in the usual TCP 3-way handshake, + so it will have difficulty traversing stateful firewalls. + The protocol is documented at + http://www.ietf.org/archive/id/draft-davie-stt-06.txt + + All traffic uses a default destination port of 7471. STT is only + available in kernel datapath on kernel 3.5 or newer. </dd> <dt><code>patch</code></dt> @@ -1911,7 +1911,7 @@ <dt><code>null</code></dt> <dd>An ignored interface. Deprecated and slated for removal in - February 2013.</dd> + February 2013.</dd> </dl> </column> </group> @@ -1955,9 +1955,9 @@ </ul> <p> - The remote tunnel endpoint for any packet received from a tunnel - is available in the <code>tun_src</code> field for matching in the - flow table. + The remote tunnel endpoint for any packet received from a tunnel + is available in the <code>tun_src</code> field for matching in the + flow table. </p> </column> @@ -2079,23 +2079,23 @@ <group title="Tunnel Options: vxlan only"> - <column name="options" key="exts"> - <p>Optional. Comma separated list of optional VXLAN extensions to - enable. The following extensions are supported:</p> + <column name="options" key="exts"> + <p>Optional. Comma separated list of optional VXLAN extensions to + enable. The following extensions are supported:</p> - <ul> - <li> - <code>gbp</code>: VXLAN-GBP allows to transport the group policy - context of a packet across the VXLAN tunnel to other network - peers. See the field description of <code>tun_gbp_id</code> and - <code>tun_gbp_flags</code> in ovs-ofctl(8) for additional - information. - (<code>https://tools.ietf.org/html/draft-smith-vxlan-group-policy</code>) - </li> - </ul> - </column> + <ul> + <li> + <code>gbp</code>: VXLAN-GBP allows to transport the group policy + context of a packet across the VXLAN tunnel to other network + peers. See the field description of <code>tun_gbp_id</code> and + <code>tun_gbp_flags</code> in ovs-ofctl(8) for additional + information. + (<code>https://tools.ietf.org/html/draft-smith-vxlan-group-policy</code>) + </li> + </ul> + </column> - </group> + </group> <group title="Tunnel Options: gre, ipsec_gre, geneve, and vxlan"> <p> @@ -2109,7 +2109,7 @@ checksums on outgoing packets. Default is disabled, set to <code>true</code> to enable. Checksums present on incoming packets will be validated regardless of this setting. - </p> + </p> <p> When using the upstream Linux kernel module, computation of @@ -2122,9 +2122,9 @@ </p> <p> - This option is supported for <code>ipsec_gre</code>, but not useful - because GRE checksums are weaker than, and redundant with, IPsec - payload authentication. + This option is supported for <code>ipsec_gre</code>, but not useful + because GRE checksums are weaker than, and redundant with, IPsec + payload authentication. </p> </column> </group> @@ -2419,70 +2419,70 @@ <group title="Bidirectional Forwarding Detection (BFD)"> <p> - BFD, defined in RFC 5880 and RFC 5881, allows point-to-point - detection of connectivity failures by occasional transmission of - BFD control messages. Open vSwitch implements BFD to serve - as a more popular and standards compliant alternative to CFM. + BFD, defined in RFC 5880 and RFC 5881, allows point-to-point + detection of connectivity failures by occasional transmission of + BFD control messages. Open vSwitch implements BFD 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 is willing to transmit them. Open vSwitch uses a detection - multiplier of three, meaning that an endpoint signals a connectivity - fault if three consecutive BFD control messages fail to arrive. In the - case of a unidirectional connectivity issue, the system not receiving - BFD control messages signals the problem to its peer in the messages it - transmits. + 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 is willing to transmit them. Open vSwitch uses a detection + multiplier of three, meaning that an endpoint signals a connectivity + fault if three consecutive BFD control messages fail to arrive. In the + case of a unidirectional connectivity issue, the system not receiving + BFD control messages signals the problem to its peer in the messages it + transmits. </p> <p> - The Open vSwitch implementation of BFD aims to comply faithfully - with RFC 5880 requirements. Open vSwitch does not implement the - optional Authentication or ``Echo Mode'' features. + The Open vSwitch implementation of BFD aims to comply faithfully + with RFC 5880 requirements. Open vSwitch does not implement the + optional Authentication or ``Echo Mode'' features. </p> <group title="BFD Configuration"> - <p> - A controller sets up key-value pairs in the <ref column="bfd"/> - column to enable and configure BFD. - </p> + <p> + A controller sets up key-value pairs in the <ref column="bfd"/> + column to enable and configure BFD. + </p> - <column name="bfd" key="enable" type='{"type": "boolean"}'> + <column name="bfd" key="enable" type='{"type": "boolean"}'> True to enable BFD on this <ref table="Interface"/>. If not specified, BFD will not be enabled by default. - </column> + </column> - <column name="bfd" key="min_rx" - type='{"type": "integer", "minInteger": 1}'> + <column name="bfd" key="min_rx" + type='{"type": "integer", "minInteger": 1}'> The shortest interval, in milliseconds, at which this BFD session offers to receive BFD control messages. The remote endpoint may choose to send messages at a slower rate. Defaults to <code>1000</code>. - </column> + </column> - <column name="bfd" key="min_tx" - type='{"type": "integer", "minInteger": 1}'> + <column name="bfd" key="min_tx" + type='{"type": "integer", "minInteger": 1}'> The shortest interval, in milliseconds, at which this BFD session is willing to transmit BFD control messages. Messages will actually be transmitted at a slower rate if the remote endpoint is not willing to receive as quickly as specified. Defaults to <code>100</code>. - </column> - - <column name="bfd" key="decay_min_rx" type='{"type": "integer"}'> - An alternate receive interval, in milliseconds, that must be greater - than or equal to <ref column="bfd" key="min_rx"/>. The - implementation switches from <ref column="bfd" key="min_rx"/> to <ref - column="bfd" key="decay_min_rx"/> when there is no obvious incoming - data traffic at the interface, to reduce the CPU and bandwidth cost - of monitoring an idle interface. This feature may be disabled by - setting a value of 0. This feature is reset whenever <ref - column="bfd" key="decay_min_rx"/> or <ref column="bfd" key="min_rx"/> - changes. - </column> - - <column name="bfd" key="forwarding_if_rx" type='{"type": "boolean"}'> + </column> + + <column name="bfd" key="decay_min_rx" type='{"type": "integer"}'> + An alternate receive interval, in milliseconds, that must be greater + than or equal to <ref column="bfd" key="min_rx"/>. The + implementation switches from <ref column="bfd" key="min_rx"/> to <ref + column="bfd" key="decay_min_rx"/> when there is no obvious incoming + data traffic at the interface, to reduce the CPU and bandwidth cost + of monitoring an idle interface. This feature may be disabled by + setting a value of 0. This feature is reset whenever <ref + column="bfd" key="decay_min_rx"/> or <ref column="bfd" key="min_rx"/> + changes. + </column> + + <column name="bfd" key="forwarding_if_rx" type='{"type": "boolean"}'> When <code>true</code>, traffic received on the <ref table="Interface"/> is used to indicate the capability of packet I/O. BFD control packets are still transmitted and received. At @@ -2490,98 +2490,98 @@ column="bfd" key="min_rx"/> amount of time. Otherwise, even if traffic are received, the <ref column="bfd" key="forwarding"/> will be <code>false</code>. - </column> + </column> - <column name="bfd" key="cpath_down" type='{"type": "boolean"}'> - Set to true to notify the remote endpoint that traffic should not be - forwarded to this system for some reason other than a connectivty - failure on the interface being monitored. The typical underlying - reason is ``concatenated path down,'' that is, that connectivity - beyond the local system is down. Defaults to false. - </column> + <column name="bfd" key="cpath_down" type='{"type": "boolean"}'> + Set to true to notify the remote endpoint that traffic should not be + forwarded to this system for some reason other than a connectivty + failure on the interface being monitored. The typical underlying + reason is ``concatenated path down,'' that is, that connectivity + beyond the local system is down. Defaults to false. + </column> - <column name="bfd" key="check_tnl_key" type='{"type": "boolean"}'> + <column name="bfd" key="check_tnl_key" type='{"type": "boolean"}'> Set to true to make BFD accept only control messages with a tunnel key of zero. By default, BFD accepts control messages with any tunnel key. - </column> - - <column name="bfd" key="bfd_local_src_mac"> - Set to an Ethernet address in the form - <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var> - to set the MAC used as source for transmitted BFD packets. The - default is the mac address of the BFD enabled interface. - </column> - - <column name="bfd" key="bfd_local_dst_mac"> - Set to an Ethernet address in the form - <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var> - to set the MAC used as destination for transmitted BFD packets. The - default is <code>00:23:20:00:00:01</code>. - </column> - - <column name="bfd" key="bfd_remote_dst_mac"> - Set to an Ethernet address in the form - <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var> - to set the MAC used for checking the destination of received BFD packets. - Packets with different destination MAC will not be considered as BFD packets. - If not specified the destination MAC address of received BFD packets - are not checked. - </column> - - <column name="bfd" key="bfd_src_ip"> + </column> + + <column name="bfd" key="bfd_local_src_mac"> + Set to an Ethernet address in the form + <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var> + to set the MAC used as source for transmitted BFD packets. The + default is the mac address of the BFD enabled interface. + </column> + + <column name="bfd" key="bfd_local_dst_mac"> + Set to an Ethernet address in the form + <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var> + to set the MAC used as destination for transmitted BFD packets. The + default is <code>00:23:20:00:00:01</code>. + </column> + + <column name="bfd" key="bfd_remote_dst_mac"> + Set to an Ethernet address in the form + <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var> + to set the MAC used for checking the destination of received BFD packets. + Packets with different destination MAC will not be considered as BFD packets. + If not specified the destination MAC address of received BFD packets + are not checked. + </column> + + <column name="bfd" key="bfd_src_ip"> Set to an IPv4 address to set the IP address used as source for transmitted BFD packets. The default is <code>169.254.1.1</code>. - </column> + </column> - <column name="bfd" key="bfd_dst_ip"> + <column name="bfd" key="bfd_dst_ip"> Set to an IPv4 address to set the IP address used as destination for transmitted BFD packets. The default is <code>169.254.1.0</code>. - </column> + </column> </group> <group title="BFD Status"> - <p> - The switch sets key-value pairs in the <ref column="bfd_status"/> - column to report the status of BFD on this interface. When BFD is - not enabled, with <ref column="bfd" key="enable"/>, the switch clears - all key-value pairs from <ref column="bfd_status"/>. - </p> - - <column name="bfd_status" key="state" - type='{"type": "string", - "enum": ["set", ["admin_down", "down", "init", "up"]]}'> - Reports the state of the BFD session. The BFD session is fully - healthy and negotiated if <code>UP</code>. - </column> - - <column name="bfd_status" key="forwarding" type='{"type": "boolean"}'> - Reports whether the BFD session believes this <ref - table="Interface"/> may be used to forward traffic. Typically this - means the local session is signaling <code>UP</code>, and the remote - system isn't signaling a problem such as concatenated path down. - </column> - - <column name="bfd_status" key="diagnostic"> - In case of a problem, set to an error message that reports what the - local BFD session thinks is wrong. The error messages are defined - in section 4.1 of [RFC 5880]. - </column> - - <column name="bfd_status" key="remote_state" - type='{"type": "string", - "enum": ["set", ["admin_down", "down", "init", "up"]]}'> - Reports the state of the remote endpoint's BFD session. - </column> - - <column name="bfd_status" key="remote_diagnostic"> - In case of a problem, set to an error message that reports what the - remote endpoint's BFD session thinks is wrong. The error messages - are defined in section 4.1 of [RFC 5880]. - </column> + <p> + The switch sets key-value pairs in the <ref column="bfd_status"/> + column to report the status of BFD on this interface. When BFD is + not enabled, with <ref column="bfd" key="enable"/>, the switch clears + all key-value pairs from <ref column="bfd_status"/>. + </p> + + <column name="bfd_status" key="state" + type='{"type": "string", + "enum": ["set", ["admin_down", "down", "init", "up"]]}'> + Reports the state of the BFD session. The BFD session is fully + healthy and negotiated if <code>UP</code>. + </column> + + <column name="bfd_status" key="forwarding" type='{"type": "boolean"}'> + Reports whether the BFD session believes this <ref + table="Interface"/> may be used to forward traffic. Typically this + means the local session is signaling <code>UP</code>, and the remote + system isn't signaling a problem such as concatenated path down. + </column> + + <column name="bfd_status" key="diagnostic"> + In case of a problem, set to an error message that reports what the + local BFD session thinks is wrong. The error messages are defined + in section 4.1 of [RFC 5880]. + </column> + + <column name="bfd_status" key="remote_state" + type='{"type": "string", + "enum": ["set", ["admin_down", "down", "init", "up"]]}'> + Reports the state of the remote endpoint's BFD session. + </column> + + <column name="bfd_status" key="remote_diagnostic"> + In case of a problem, set to an error message that reports what the + remote endpoint's BFD session thinks is wrong. The error messages + are defined in section 4.1 of [RFC 5880]. + </column> <column name="bfd_status" key="flap_count" - type='{"type": "integer", "minInteger": 0}'> + type='{"type": "integer", "minInteger": 0}'> Counts the number of <ref column="bfd_status" key="forwarding" /> flaps since start. A flap is considered as a change of the <ref column="bfd_status" key="forwarding" /> value. @@ -2609,9 +2609,9 @@ </p> <p> - When operating over tunnels which have no <code>in_key</code>, or an - <code>in_key</code> of <code>flow</code>. CFM will only accept CCMs - with a tunnel key of zero. + When operating over tunnels which have no <code>in_key</code>, or an + <code>in_key</code> of <code>flow</code>. CFM will only accept CCMs + with a tunnel key of zero. </p> <column name="cfm_mpid"> @@ -2696,8 +2696,8 @@ <column name="cfm_remote_opstate"> <p>When in extended mode, indicates the operational state of the - remote endpoint as either <code>up</code> or <code>down</code>. See - <ref column="other_config" key="cfm_opstate"/>. + remote endpoint as either <code>up</code> or <code>down</code>. See + <ref column="other_config" key="cfm_opstate"/>. </p> </column> @@ -2773,7 +2773,7 @@ </p> <p> - Demand mode has a couple of caveats: + Demand mode has a couple of caveats: <ul> <li> To ensure that ovs-vswitchd has enough time to pull statistics @@ -2811,14 +2811,14 @@ </column> <column name="other_config" key="cfm_ccm_vlan" - type='{"type": "integer", "minInteger": 1, "maxInteger": 4095}'> + type='{"type": "integer", "minInteger": 1, "maxInteger": 4095}'> When set, the CFM module will apply a VLAN tag to all CCMs it generates with the given value. May be the string <code>random</code> in which case each CCM will be tagged with a different randomly generated VLAN. </column> <column name="other_config" key="cfm_ccm_pcp" - type='{"type": "integer", "minInteger": 1, "maxInteger": 7}'> + type='{"type": "integer", "minInteger": 1, "maxInteger": 7}'> When set, the CFM module will apply a VLAN tag to all CCMs it generates with the given PCP value, the VLAN ID of the tag is governed by the value of <ref column="other_config" key="cfm_ccm_vlan"/>. If @@ -2926,17 +2926,17 @@ <group title="VLAN Splinters"> <p> - The ``VLAN splinters'' feature increases Open vSwitch compatibility - with buggy network drivers in old versions of Linux that do not - properly support VLANs when VLAN devices are not used, at some cost - in memory and performance. + The ``VLAN splinters'' feature increases Open vSwitch compatibility + with buggy network drivers in old versions of Linux that do not + properly support VLANs when VLAN devices are not used, at some cost + in memory and performance. </p> <p> - When VLAN splinters are enabled on a particular interface, Open vSwitch - creates a VLAN device for each in-use VLAN. For sending traffic tagged - with a VLAN on the interface, it substitutes the VLAN device. Traffic - received on the VLAN device is treated as if it had been received on + When VLAN splinters are enabled on a particular interface, Open vSwitch + creates a VLAN device for each in-use VLAN. For sending traffic tagged + with a VLAN on the interface, it substitutes the VLAN device. Traffic + received on the VLAN device is treated as if it had been received on the interface on the particular VLAN. </p> @@ -2978,8 +2978,8 @@ </p> <p> - VLAN splinters are deprecated. When broken device drivers are no - longer in widespread use, we will delete this feature. + VLAN splinters are deprecated. When broken device drivers are no + longer in widespread use, we will delete this feature. </p> <column name="other_config" key="enable-vlan-splinters" @@ -3004,12 +3004,12 @@ <group title="Auto Attach Configuration"> <p> - Auto Attach configuration for a particular interface. + Auto Attach configuration for a particular interface. </p> <column name="lldp" key="enable" type='{"type": "boolean"}'> - True to enable LLDP on this <ref table="Interface"/>. If not - specified, LLDP will be disabled by default. + True to enable LLDP on this <ref table="Interface"/>. If not + specified, LLDP will be disabled by default. </column> </group> @@ -3986,7 +3986,7 @@ </p> <column name="other_config" key="dscp" - type='{"type": "integer"}'> + 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 @@ -4252,11 +4252,11 @@ </column> <column name="status" key="bound_port" type='{"type": "integer"}'> - When <ref column="target"/> is <code>ptcp:</code> or - <code>pssl:</code>, this is the TCP port on which the OVSDB server is - listening. (This is is particularly useful when <ref - column="target"/> specifies a port of 0, allowing the kernel to - choose any available port.) + When <ref column="target"/> is <code>ptcp:</code> or + <code>pssl:</code>, this is the TCP port on which the OVSDB server is + listening. (This is is particularly useful when <ref + column="target"/> specifies a port of 0, allowing the kernel to + choose any available port.) </column> </group> @@ -4267,7 +4267,7 @@ </p> <column name="other_config" key="dscp" - type='{"type": "integer"}'> + 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 @@ -4312,18 +4312,18 @@ <column name="active_timeout"> <p> - The interval at which NetFlow records are sent for flows that - are still active, in seconds. A value of <code>0</code> - requests the default timeout (currently 600 seconds); a value - of <code>-1</code> disables active timeouts. + The interval at which NetFlow records are sent for flows that + are still active, in seconds. A value of <code>0</code> + requests the default timeout (currently 600 seconds); a value + of <code>-1</code> disables active timeouts. </p> <p> - The NetFlow passive timeout, for flows that become inactive, - is not configurable. It will vary depending on the Open - vSwitch version, the forms and contents of the OpenFlow flow - tables, CPU and memory usage, and network activity. A typical - passive timeout is about a second. + The NetFlow passive timeout, for flows that become inactive, + is not configurable. It will vary depending on the Open + vSwitch version, the forms and contents of the OpenFlow flow + tables, CPU and memory usage, and network activity. A typical + passive timeout is about a second. </p> </column> @@ -4650,39 +4650,46 @@ </table> <table name="AutoAttach"> - <p>Auto Attach configuration within a bridge. The IETF Auto-Attach SPBM - draft standard describes a compact method of using IEEE 802.1AB Link - Layer Discovery Protocol (LLDP) together with a IEEE 802.1aq Shortest - Path Bridging (SPB) network to automatically attach network devices - to individual services in a SPB network. The intent here is to allow - network applications and devices using OVS to be able to easily take - advantage of features offered by industry standard SPB networks.</p> - - <p>Auto Attach (AA) uses LLDP to communicate between a directly connected - Auto Attach Client (AAC) and Auto Attach Server (AAS). The LLDP protocol - is extended to add two new Type-Length-Value tuples (TLVs). The first - new TLV supports the ongoing discovery of directly connected AA - correspondents. Auto Attach operates by regularly transmitting AA - discovery TLVs between the AA client and AA server. By exchanging these - discovery messages, both the AAC and AAS learn the system name and - system description of their peer. In the OVS context, OVS operates as - the AA client and the AA server resides on a switch at the edge of the - SPB network.</p> - - <p>Once AA discovery has been completed the AAC then uses the - second new TLV to deliver identifier mappings from the AAC to the AAS. A primary - feature of Auto Attach is to facilitate the mapping of VLANs defined - outside the SPB network onto service ids (ISIDs) defined within the SPM - network. By doing so individual external VLANs can be mapped onto - specific SPB network services. These VLAN id to ISID mappings can be - configured and managed locally using new options added to the ovs-vsctl - command.</p> - - <p>The Auto Attach OVS feature does not provide a full implementation of - the LLDP protocol. Support for the mandatory TLVs as defined by the LLDP - standard and support for the AA TLV extensions is provided. LLDP - protocol support in OVS can be enabled or disabled on a port by port - basis. LLDP support is disabled by default.</p> + <p> + Auto Attach configuration within a bridge. The IETF Auto-Attach SPBM + draft standard describes a compact method of using IEEE 802.1AB Link + Layer Discovery Protocol (LLDP) together with a IEEE 802.1aq Shortest + Path Bridging (SPB) network to automatically attach network devices + to individual services in a SPB network. The intent here is to allow + network applications and devices using OVS to be able to easily take + advantage of features offered by industry standard SPB networks. + </p> + + <p> + Auto Attach (AA) uses LLDP to communicate between a directly connected + Auto Attach Client (AAC) and Auto Attach Server (AAS). The LLDP protocol + is extended to add two new Type-Length-Value tuples (TLVs). The first + new TLV supports the ongoing discovery of directly connected AA + correspondents. Auto Attach operates by regularly transmitting AA + discovery TLVs between the AA client and AA server. By exchanging these + discovery messages, both the AAC and AAS learn the system name and + system description of their peer. In the OVS context, OVS operates as + the AA client and the AA server resides on a switch at the edge of the + SPB network. + </p> + + <p> + Once AA discovery has been completed the AAC then uses the second new TLV + to deliver identifier mappings from the AAC to the AAS. A primary feature + of Auto Attach is to facilitate the mapping of VLANs defined outside the + SPB network onto service ids (ISIDs) defined within the SPM network. By + doing so individual external VLANs can be mapped onto specific SPB + network services. These VLAN id to ISID mappings can be configured and + managed locally using new options added to the ovs-vsctl command. + </p> + + <p> + The Auto Attach OVS feature does not provide a full implementation of + the LLDP protocol. Support for the mandatory TLVs as defined by the LLDP + standard and support for the AA TLV extensions is provided. LLDP + protocol support in OVS can be enabled or disabled on a port by port + basis. LLDP support is disabled by default. + </p> <column name="system_name"> The system_name string is exported in LLDP messages. It should uniquely @@ -4695,7 +4702,8 @@ </column> <column name="mappings"> - A mapping from SPB network Individual Service Identifier (ISID) to VLAN id. + A mapping from SPB network Individual Service Identifier (ISID) to VLAN + id. </column> </table> </database>
This is a large patch but it is entirely whitespace changes. Suggested-by: Justin Pettit <jpettit@nicira.com> Signed-off-by: Ben Pfaff <blp@nicira.com> --- vswitchd/vswitch.xml | 684 ++++++++++++++++++++++++++------------------------- 1 file changed, 346 insertions(+), 338 deletions(-)