--- /dev/null
+==========================
+MPLS encapsulation feature
+==========================
+
+This feature allows to generate packets with standard MPLS L2VPN double stack MPLS labels, where the outer label is transport and the inner label is VPN.
+The top layer of a packets encapsulated inside MPLS L2VPN seems to be an Ethernet layer with the rest of the IP stack inside.
+Please refer to RFC-3031 for more details.
+The whole MPLS packet structure looks like the following:
+
+###[ Ethernet ]###
+ dst = ['00:8a:96:bb:14:28']
+ src = 3c:fd:fe:a3:48:7c
+ type = 0x8847
+###[ MPLS ]### <-------------- Outer Label
+ label = 16303
+ cos = 1
+ s = 0
+ ttl = 255
+###[ MPLS ]### <-------------- Inner Label
+ label = 5010
+ cos = 1
+ s = 1
+ ttl = 255
+###[ Ethernet ]###
+ dst = fa:16:3e:bd:02:b5
+ src = 3c:fd:fe:a3:48:7c
+ type = 0x800
+###[ IP ]###
+ version = 4
+ ihl = None
+ tos = 0x0
+ len = None
+ id = 1
+ flags =
+ frag = 0
+ ttl = 64
+ proto = udp
+ chksum = None
+ src = 16.0.0.1
+ dst = 48.0.0.1
+ \options \
+###[ UDP ]###
+ sport = 53
+ dport = 53
+ len = None
+ chksum = None
+
+Example: nfvbench generates mpls traffic port A ----> port B. This example assumes openstack is at the other end of the mpls tunnels.
+Packets generated and sent to port B are delivered to the MPLS domain infrastructure which will transport that packet to the other end
+of the MPLS transport tunnel using the outer label. At that point, the outer label is decapsulated and the inner label is used to
+select the destination openstack network. After decapsulation of the inner label, the resulting L2 frame is then forwarded to the
+destination VM corresponding to the destination MAC. When the VM receives the packet, it is sent back to far end port of the traffic
+generator (port B) using either L2 forwarding or L3 routing though the peer virtual interface. The return packet is then encapsulated
+with the inner label first then outer label to reach nfvbench on port B.
+
+Only 2 MPLS labels stack is supported. If more than two labels stack is required then these operations should be handled by MPLS transport
+domain where nfvbench is attached next-hop mpls router and rest of the mpls domain should be configured accordingly to be able
+pop/swap/push labels and deliver packet to the proper destination based on an initial transport label injected by nfvbench, VPN label
+should stay unchanged until its delivered to PE (compute node).
+Set nfvbench 'mpls' parameter to 'true' to enable MPLS encapsulation.
+When this option is enabled internal networks 'network type' parameter value should be 'mpls'
+MPLS and VxLAN encapsulations are mutual exclusive features if 'mpls' is 'true' then 'vxlan' should be set to 'false' and vise versa.
+no_flow_stats, no_latency_stats, no_latency_streams parameters should be set to 'true' because these features are not supported at the moment.
+In future when these features will be supported they will require special NIC hardware.
+
+Example of 1-chain MPLS configuration:
+ internal_networks:
+ left:
+ network_type: mpls
+ segmentation_id: 5010
+ mpls_transport_labels: 16303
+ physical_network: phys_sriov0
+ right:
+ network_type: mpls
+ segmentation_id: 5011
+ mpls_transport_labels: 16303
+ physical_network: phys_sriov1
+
+Example of 2-chain MPLS configuration:
+ internal_networks:
+ left:
+ network_type: mpls
+ segmentation_id: [5010, 5020]
+ mpls_transport_labels: [16303, 16304]
+ physical_network: phys_sriov0
+ right:
+ network_type: mpls
+ segmentation_id: [5011, 5021]
+ mpls_transport_labels: [16303, 16304]
+ physical_network: phys_sriov1
+
+Example of how to run:
+nfvbench --rate 50000pps --duration 30 --mpls
Code Review / nfvbench.git / blobdiff