Overview of Edge Virtual Bridging

Edge virtual bridging is an evolving IEEE standard for a host to exchange virtual link information with an external switch. With EVB, more information about virtual link configurations can be advertised on the network beyond, for example, bandwidth share or priority definitions for physical links that DCB features provide.

In general, EVB can be used for the following operations:

• Enable reflective relay on the external bridge port. See Reflective Relay Capability.

• Automate virtual port configuration on the bridge. See Automatic Virtual Port Configuration on the Bridge.

To understand the mechanism of EVB, note the following terminology used with EVB.

• Station refers to the system or host.

• Bridge refers to the external switch that is connected to the station.

• Virtual station instance (VSI) refers to a VNIC that is configured on the station.

• Virtual machine (VM) is a general term to refer to zones, Oracle VM VirtualBox, and other software-implemented machines on the system.

The following sections describe in detail the functions of EVB.

Reflective Relay Capability

With network virtualization, a station can be configured with multiple virtual network interface cards (VNICs) over a single physical NIC. The VNICs are assigned to virtual machines on the station. In this setup, communication among the virtual machines can occur without packets having to leave the station. Instead, packets are routed from one VM to another VM by the virtual switch of the physical link. For an illustration of a system configuration that includes, VNICs, a virtual switch, and virtual machines, see Components of Network Virtualization in Using Virtual Networks in Oracle Solaris 11.1.

In certain cases, internal communication between VMs might require the use of an external bridge. For example, internal communication might need to be subjected to access control lists (ACLs) that are configured on the external bridge. The packets from the originating VM would therefore exit the station through a port to the external bridge. Those packets are then sent from the bridge back to the station to the receiving VM.

By default, a bridge cannot send packets on the same port where the packets are received. Thus, for communications between VMs that uses an external bridge, the bridge must have reflective relay capability. This capability enables the bridge to relay packets from the sending VM back to the receiving VM on the same link as it received the packets.

EVB defines a new organization-specific LLDP TLV unit to inform network peers about reflective relay capability, while the EVB TLV unit serves as the vehicle for the information The information exchange consists of a station first requesting the bridge to enable reflective relay if it is supported on the bridge. The bridge enables the capability, if it is supported, and informs the requesting host of that capability. If the bridge does not support reflective relay, then a disabled status is sent back to the station. In that case, communications between virtual machines simply use the physical link's virtual switch.

Automatic Virtual Port Configuration on the Bridge

LLDP and DCBX enable a station to exchange configuration information with the nearest bridge. With this exchange, the bridge can detect, for example, priorities that have been defined for traffic classes on the station. Based on this information, the bridge is automatically configured to process packets based on their 802.1p priority value.

Without the information exchange and automatic configuration, the bridge would need to be manually configured separately from the station to mirror the station configuration on traffic class priorities. Manual configuration risks bridge misconfiguration and might cause inconsistencies between the station and the bridge.

With EVB, the exchange mechanism is extended to include information about the station's VSIs to the bridge. In this manner, the configuration of the VNICs can be extended to the bridge. For example, suppose that a VNIC has been configured with a specific bandwidth limit. With EVB, the bridge can enforce the bandwidth limit on packets that are destined for that VNIC.

EVB Components for VSI Information Exchange

The following EVB components enable the station to advertise VSI information to the bridge:

• The VSI profile consists of link properties that have been configured for the specific VNIC. Thus, a station can have as many VSI profiles as there are configured VNICs.

• A VSI identifier consists of a VSI Type ID and VSI Version ID pair that uniquely identifies a VSI profile.

• The VSI Manager manages the multiple VSI profiles on the station by mapping the VSI Type ID-VSI Version ID identifier with a specific set of VNIC properties.

• VSI Manager ID identifies the VSI Manager that is relevant to a specific VSI Type ID - VSI Version pair. The VSI Manager ID is represented as an IPv6 address.

The combined VSI Manager ID, VSI Type ID, and VSI Version constitute a tuple that identifies a set of properties of a specific VNIC..

VSI information is exchanged by using the VSI discovery and configuration protocol (VDP), while the VDP TLV unit serves as the vehicle for the information. The bridge receives the VDP TLV unit from the station. The bridge then uses the tuple contained in the TLV unit to obtain the set of properties that are associated with the VSI. After the bridge obtains the properties for the VSI profile or type, then the bridge can apply the property configurations on packets for that VSI.

Before VSI information can be advertised to the bridge, the following requirements must be met:

• The station must know what VSI Manager ID to use when sending VSI discovery protocol requests.

• The bridge must recognize and support the VSI Manager ID that is sent by the station.