ovs-docker: Enhance documentation to handle pre-programmed interfaces.

Currently, Controllers and CMSes that integrate with Open vSwitch
after following the IntegrationGuide.md, expect to start VMs after
the underlying network infrastructure is ready. I have been asked
a few times on how to handle the same with containers. This commit
provides documentation on one way to achieve it.

Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Thomas Graf <tgraf@noironetworks.com>
ovs-docker: Ability to set the default gateway.

ovs-docker currently lets one add the ability to set the
IP address on an OVS interface. Ability to set the default
gateway too can be an useful addition. (orchestrators
who plan to use OVS interfaces can do this from a single
utility instead of multiple utilities)

Requested-by: Marvin Pascual <marvin@pascual.com.ph>
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Thomas Graf <tgraf@noironetworks.com>
ovs-docker: Add the ability to set VLANs.

For containers containing multiple ports and spawned by
orchestrators without openflow flows configured, it can be quite
useful to distinguish their traffic with vlans. This can be useful
when containers are spawned inside VMs instead of hypervisors.

Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Thomas Graf <tgraf@noironetworks.com>
dpctl: Add support for using UFID to add/del flows.

Parse "ufid:<foo>" at the beginning of a flow specification and use it
for flow manipulation if present.

Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Change Travis CI notification email to ljakab@ac.upc.edu
userspace: add support for pop_eth and push_eth actions

These actions will allow L2->L3 and L3->L2 switching, and are supposed
to be added to flows installed in the datapath transparently by
ovs-vswitchd.

Signed-off-by: Lorand Jakab <lojakab@cisco.com>
userspace: add layer 3 flow and switching support

This commit relaxes the assumption that all packets have an Ethernet
header, and adds support for layer 3 flows.  For each packet received on
the Linux kernel datapath the l2 and l3 members of struct ofpbuf are
intialized appropriately, and some functions now expect this (notably
flow_extract()), in order to differentiate between layer 2 and layer 3
packets.  struct flow has now a new 'base_layer' member, because we
cannot assume that a flow has no Ethernet header when eth_src and
eth_dst are 0.  For layer 3 packets, the protocol type is still stored
in the eth_type member.

Switching L2->L3 and L3->L2 are both implemented by adding the pop_eth
and push_eth actions respectively when a transition is detected.  The
push_eth action puts 0s on both source and destination MACs.  These
addresses can be modified with mod_dl_dst and mod_dl_src actions.

Added new prerequisite MFP_ETHERNET for fields MFF_VLAN_TCI,
MFF_DL_VLAN, MFF_VLAN_VID and MFF_DL_VLAN_PCP.

Signed-off-by: Lorand Jakab <lojakab@cisco.com>
datapath: add layer 3 flow/port support

Implementation of the pop_eth and push_eth actions in the kernel, and
layer 3 flow support.

Signed-off-by: Lorand Jakab <lojakab@cisco.com>
userspace: add layer 3 support to packet metadata

This is needed for sending a packet back to the datapath after a miss upcall
was processed.  The presence of a layer 2 packet is signaled by adding
OVS_KEY_ATTR_ETHERNET to the packet metadata sent with the ovs_packet netlink
message.  Layer 3 packets need to be accompanied by OVS_KEY_ATTR_ETHERTYPE to
indicate network protocol.

Signed-off-by: Lorand Jakab <lojakab@cisco.com>
datapath: add layer 3 support to ovs_packet_cmd_execute()

Packet metadata for layer 3 packets is expected to contain
OVS_KEY_ATTR_ETHERTYPE to indicate the network protocol.

Signed-off-by: Lorand Jakab <lojakab@cisco.com>