From patchwork Tue Oct 13 23:15:41 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ben Pfaff X-Patchwork-Id: 529946 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from archives.nicira.com (unknown [IPv6:2600:3c00::f03c:91ff:fe6e:bdf7]) by ozlabs.org (Postfix) with ESMTP id 0E655140F99 for ; Wed, 14 Oct 2015 10:15:49 +1100 (AEDT) Received: from archives.nicira.com (localhost [127.0.0.1]) by archives.nicira.com (Postfix) with ESMTP id EC1E9108AF; Tue, 13 Oct 2015 16:15:47 -0700 (PDT) X-Original-To: dev@openvswitch.org Delivered-To: dev@openvswitch.org Received: from mx3v1.cudamail.com (mx3.cudamail.com [64.34.241.5]) by archives.nicira.com (Postfix) with ESMTPS id 13A9E108AB for ; Tue, 13 Oct 2015 16:15:47 -0700 (PDT) Received: from bar3.cudamail.com (bar1 [192.168.15.1]) by mx3v1.cudamail.com (Postfix) with ESMTP id 68A96618579 for ; Tue, 13 Oct 2015 17:15:46 -0600 (MDT) X-ASG-Debug-ID: 1444778145-03dd7b78c521400001-byXFYA Received: from mx3-pf3.cudamail.com ([192.168.14.3]) by bar3.cudamail.com with ESMTP id HlZn0sF40nP3t2lF (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Oct 2015 17:15:45 -0600 (MDT) X-Barracuda-Envelope-From: blp@nicira.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.14.3 Received: from unknown (HELO mail-pa0-f49.google.com) (209.85.220.49) by mx3-pf3.cudamail.com with ESMTPS (RC4-SHA encrypted); 13 Oct 2015 23:15:44 -0000 Received-SPF: unknown (mx3-pf3.cudamail.com: Multiple SPF records returned) X-Barracuda-RBL-Trusted-Forwarder: 209.85.220.49 Received: by pabrc13 with SMTP id rc13so34500535pab.0 for ; Tue, 13 Oct 2015 16:15:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=p8xy8/mfZWtlV722vi31ukk1IwBA1DnticJlKpW7K3s=; b=P1+nJoA9Ud6aAJR4DZE08ioiQ+gtucySXDez7bMBCmc2bFg0DWa1FzueXmfHIR6Fpq KzUv+XXE7IVCl4sqdA4lobANG3wBEmwvNb6XJqiS+QGOhHx2rFlPftzhBVwXcKglr4h4 gbADg7bncYzrclYtyAb8a8PLNF016ciFAuw2uYtND+bWaHN2aCRMUzbLcSzQLP53c+XJ wpzjnJleG0TpgjhGXoSXm9XxXL5sc/Q1O5mu4ReB1+KSJ0HSYB9N1+J8LrZJENl0dqu3 yBbnQpzvDsTBgOoFRtoWOSwjgmSlSgi3H3fgpNe314QES6GG0Ib3VMkgApw6P9e6jdL/ zTMQ== X-Gm-Message-State: ALoCoQloqUMcl6nn9qd+BqWdYu+ooMpQ79XH22RvNEq0OGeJ5A6driJt6REYBmfTF/1BO9zrCyyz X-Received: by 10.66.235.42 with SMTP id uj10mr65619pac.32.1444778144870; Tue, 13 Oct 2015 16:15:44 -0700 (PDT) Received: from sigabrt.benpfaff.org ([208.91.2.4]) by smtp.gmail.com with ESMTPSA id fm3sm5833544pbb.36.2015.10.13.16.15.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 13 Oct 2015 16:15:43 -0700 (PDT) X-CudaMail-Envelope-Sender: blp@nicira.com X-Barracuda-Apparent-Source-IP: 208.91.2.4 From: Ben Pfaff To: dev@openvswitch.org X-CudaMail-Whitelist-To: dev@openvswitch.org X-CudaMail-MID: CM-V3-1012074789 X-CudaMail-DTE: 101315 X-CudaMail-Originating-IP: 209.85.220.49 Date: Tue, 13 Oct 2015 16:15:41 -0700 X-ASG-Orig-Subj: [##CM-V3-1012074789##][PATCH] vswitch.xml: Untabify and reindent. Message-Id: <1444778141-6714-1-git-send-email-blp@nicira.com> X-Mailer: git-send-email 2.1.3 X-Barracuda-Connect: UNKNOWN[192.168.14.3] X-Barracuda-Start-Time: 1444778145 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://web.cudamail.com:443/cgi-mod/mark.cgi X-ASG-Whitelist: Header =?UTF-8?B?eFwtY3VkYW1haWxcLXdoaXRlbGlzdFwtdG8=?= X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at cudamail.com Cc: Ben Pfaff Subject: [ovs-dev] [PATCH] vswitch.xml: Untabify and reindent. X-BeenThere: dev@openvswitch.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: dev-bounces@openvswitch.org Sender: "dev" This is a large patch but it is entirely whitespace changes. Suggested-by: Justin Pettit Signed-off-by: Ben Pfaff Acked-by: Justin Pettit --- 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 @@ - Auto Attach configuration. + Auto Attach configuration. @@ -685,16 +685,16 @@ -

- 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. -

+

+ 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. +

-

- OpenFlow 1.4 is not enabled by default because its implementation is - missing features. -

+

+ OpenFlow 1.4 is not enabled by default because its implementation is + missing features. +

OpenFlow 1.5 has the same risks as OpenFlow 1.4, but it is even more @@ -982,45 +982,45 @@ -

+

Controls forwarding of BPDUs and other network control frames when NORMAL action is invoked. When this option is false or unset, frames with reserved Ethernet addresses (see table below) will not be forwarded. When this option is true, such frames will not be treated specially. -

- -

- The above general rule has the following exceptions: -

- -
    -
  • - If STP is enabled on the bridge (see the column in the 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. -
    • - -
  • - If LLDP is enabled on an interface (see the column in the table), - the interface processes received LLDP packets and never passes them - to OpenFlow or forwards them. -
    • -
- -

- Set this option to true if the Open vSwitch bridge - connects different Ethernet networks and is not configured to - participate in STP. -

- -

- This option affects packets with the following destination MAC - addresses: -

+

+ +

+ The above general rule has the following exceptions: +

+ +
    +
  • + If STP is enabled on the bridge (see the column in the 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. +
    • + +
  • + If LLDP is enabled on an interface (see the column in the table), + the interface processes received LLDP packets and never passes them + to OpenFlow or forwards them. +
    • +
+ +

+ Set this option to true if the Open vSwitch bridge + connects different Ethernet networks and is not configured to + participate in STP. +

+ +

+ This option affects packets with the following destination MAC + addresses: +

01:80:c2:00:00:00
@@ -1036,8 +1036,8 @@
Extreme Discovery Protocol (EDP).
- 00:e0:2b:00:00:04 and 00:e0:2b:00:00:06 -
+ 00:e0:2b:00:00:04 and 00:e0:2b:00:00:06 +
Ethernet Automatic Protection Switching (EAPS).
01:00:0c:cc:cc:cc
@@ -1099,8 +1099,8 @@ - - + +

A port within a .

Most commonly, a port has exactly one ``interface,'' pointed to by its column. Such a port logically @@ -1382,7 +1382,7 @@ + type='{"type": "string", "enum": ["set", ["fast", "slow"]]}'>

The LACP timing which should be used on this . By default slow is used. When configured to be @@ -1394,7 +1394,7 @@ + type='{"type": "boolean"}'>

Determines the behavior of openvswitch bond in LACP mode. If the partner switch does not support LACP, setting this option @@ -1753,57 +1753,57 @@ -

- 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 , 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 the port number actually assigned. -

- -

- 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. -

- - -

- OpenFlow port number for this interface. Open vSwitch sets this - column's value, so other clients should treat it as read-only. -

-

- The OpenFlow ``local'' port (OFPP_LOCAL) 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. -

- - - -

- Requested OpenFlow port number for this interface. -

- -

- 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. -

- -

- If is set or changed to some other - port's automatically assigned port number, Open vSwitch chooses a - new port number for the latter port. -

- +

+ 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 , 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 the port number actually assigned. +

+ +

+ 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. +

+ + +

+ OpenFlow port number for this interface. Open vSwitch sets this + column's value, so other clients should treat it as read-only. +

+

+ The OpenFlow ``local'' port (OFPP_LOCAL) 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. +

+ + + +

+ Requested OpenFlow port number for this interface. +

+ +

+ 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. +

+ +

+ If is set or changed to some other + port's automatically assigned port number, Open vSwitch chooses a + new port number for the latter port. +

+ @@ -1858,15 +1858,15 @@
vxlan
-

- An Ethernet tunnel over the UDP-based VXLAN protocol described in - RFC 7348. -

-

- 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. -

+

+ An Ethernet tunnel over the UDP-based VXLAN protocol described in + RFC 7348. +

+

+ 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. +

lisp
@@ -1887,21 +1887,21 @@
stt
- 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.
patch
@@ -1911,7 +1911,7 @@
null
An ignored interface. Deprecated and slated for removal in - February 2013.
+ February 2013. @@ -1955,9 +1955,9 @@

- The remote tunnel endpoint for any packet received from a tunnel - is available in the tun_src field for matching in the - flow table. + The remote tunnel endpoint for any packet received from a tunnel + is available in the tun_src field for matching in the + flow table.

@@ -2079,23 +2079,23 @@ - -

Optional. Comma separated list of optional VXLAN extensions to - enable. The following extensions are supported:

+ +

Optional. Comma separated list of optional VXLAN extensions to + enable. The following extensions are supported:

-
    -
  • - gbp: 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 tun_gbp_id and - tun_gbp_flags in ovs-ofctl(8) for additional - information. - (https://tools.ietf.org/html/draft-smith-vxlan-group-policy) -
    • -
- +
    +
  • + gbp: 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 tun_gbp_id and + tun_gbp_flags in ovs-ofctl(8) for additional + information. + (https://tools.ietf.org/html/draft-smith-vxlan-group-policy) +
    • +
+ - +

@@ -2109,7 +2109,7 @@ checksums on outgoing packets. Default is disabled, set to true to enable. Checksums present on incoming packets will be validated regardless of this setting. -

+

When using the upstream Linux kernel module, computation of @@ -2122,9 +2122,9 @@

- This option is supported for ipsec_gre, but not useful - because GRE checksums are weaker than, and redundant with, IPsec - payload authentication. + This option is supported for ipsec_gre, but not useful + because GRE checksums are weaker than, and redundant with, IPsec + payload authentication.

@@ -2419,70 +2419,70 @@

- 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.

- 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.

- 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.

-

- A controller sets up key-value pairs in the - column to enable and configure BFD. -

+

+ A controller sets up key-value pairs in the + column to enable and configure BFD. +

- + True to enable BFD on this . If not specified, BFD will not be enabled by default. - + - + 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 1000. - + - + 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 100. - - - - An alternate receive interval, in milliseconds, that must be greater - than or equal to . The - implementation switches from to 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 or - changes. - - - + + + + An alternate receive interval, in milliseconds, that must be greater + than or equal to . The + implementation switches from to 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 or + changes. + + + When true, traffic received on the 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 will be false. - + - - 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. - + + 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. + - + 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. - - - - Set to an Ethernet address in the form - xx:xx:xx:xx:xx:xx - to set the MAC used as source for transmitted BFD packets. The - default is the mac address of the BFD enabled interface. - - - - Set to an Ethernet address in the form - xx:xx:xx:xx:xx:xx - to set the MAC used as destination for transmitted BFD packets. The - default is 00:23:20:00:00:01. - - - - Set to an Ethernet address in the form - xx:xx:xx:xx:xx:xx - 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. - - - + + + + Set to an Ethernet address in the form + xx:xx:xx:xx:xx:xx + to set the MAC used as source for transmitted BFD packets. The + default is the mac address of the BFD enabled interface. + + + + Set to an Ethernet address in the form + xx:xx:xx:xx:xx:xx + to set the MAC used as destination for transmitted BFD packets. The + default is 00:23:20:00:00:01. + + + + Set to an Ethernet address in the form + xx:xx:xx:xx:xx:xx + 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. + + + Set to an IPv4 address to set the IP address used as source for transmitted BFD packets. The default is 169.254.1.1. - + - + Set to an IPv4 address to set the IP address used as destination for transmitted BFD packets. The default is 169.254.1.0. - + -

- The switch sets key-value pairs in the - column to report the status of BFD on this interface. When BFD is - not enabled, with , the switch clears - all key-value pairs from . -

- - - Reports the state of the BFD session. The BFD session is fully - healthy and negotiated if UP. - - - - Reports whether the BFD session believes this may be used to forward traffic. Typically this - means the local session is signaling UP, and the remote - system isn't signaling a problem such as concatenated path down. - - - - 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]. - - - - Reports the state of the remote endpoint's BFD session. - - - - 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]. - +

+ The switch sets key-value pairs in the + column to report the status of BFD on this interface. When BFD is + not enabled, with , the switch clears + all key-value pairs from . +

+ + + Reports the state of the BFD session. The BFD session is fully + healthy and negotiated if UP. + + + + Reports whether the BFD session believes this may be used to forward traffic. Typically this + means the local session is signaling UP, and the remote + system isn't signaling a problem such as concatenated path down. + + + + 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]. + + + + Reports the state of the remote endpoint's BFD session. + + + + 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]. + + type='{"type": "integer", "minInteger": 0}'> Counts the number of flaps since start. A flap is considered as a change of the value. @@ -2609,9 +2609,9 @@

- When operating over tunnels which have no in_key, or an - in_key of flow. CFM will only accept CCMs - with a tunnel key of zero. + When operating over tunnels which have no in_key, or an + in_key of flow. CFM will only accept CCMs + with a tunnel key of zero.

@@ -2696,8 +2696,8 @@

When in extended mode, indicates the operational state of the - remote endpoint as either up or down. See - . + remote endpoint as either up or down. See + .

@@ -2773,7 +2773,7 @@

- Demand mode has a couple of caveats: + Demand mode has a couple of caveats:

  • To ensure that ovs-vswitchd has enough time to pull statistics @@ -2811,14 +2811,14 @@ + 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 random in which case each CCM will be tagged with a different randomly generated VLAN. + 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 . If @@ -2926,17 +2926,17 @@

    - 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.

    - 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.

    @@ -2978,8 +2978,8 @@

    - 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.

    - Auto Attach configuration for a particular interface. + Auto Attach configuration for a particular interface.

    - True to enable LLDP on this . If not - specified, LLDP will be disabled by default. + True to enable LLDP on this . If not + specified, LLDP will be disabled by default.     @@ -3986,7 +3986,7 @@

    + 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 @@ - When is ptcp: or - pssl:, this is the TCP port on which the OVSDB server is - listening. (This is is particularly useful when specifies a port of 0, allowing the kernel to - choose any available port.) + When is ptcp: or + pssl:, this is the TCP port on which the OVSDB server is + listening. (This is is particularly useful when specifies a port of 0, allowing the kernel to + choose any available port.) @@ -4267,7 +4267,7 @@

    + 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 @@

    - The interval at which NetFlow records are sent for flows that - are still active, in seconds. A value of 0 - requests the default timeout (currently 600 seconds); a value - of -1 disables active timeouts. + The interval at which NetFlow records are sent for flows that + are still active, in seconds. A value of 0 + requests the default timeout (currently 600 seconds); a value + of -1 disables active timeouts.

    - 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.

    @@ -4650,39 +4650,46 @@
-

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.

- -

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.

- -

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.

- -

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.

+

+ 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. +

+ +

+ 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. +

+ +

+ 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. +

+ +

+ 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. +

The system_name string is exported in LLDP messages. It should uniquely @@ -4695,7 +4702,8 @@ - A mapping from SPB network Individual Service Identifier (ISID) to VLAN id. + A mapping from SPB network Individual Service Identifier (ISID) to VLAN + id.