LISP GPE: initial CP commit and DP improvements 54/654/5
authorFlorin Coras <fcoras@cisco.com>
Thu, 18 Feb 2016 21:20:01 +0000 (22:20 +0100)
committerGerrit Code Review <gerrit@fd.io>
Sat, 2 Apr 2016 17:20:44 +0000 (17:20 +0000)
commite127a7e4528472a320bf1cc343d3656dcdd4b108
tree0a577faa62d883d0c8a2f223f216ed9c5df69882
parent28e3db9dd617324a3196f369788d62cc72b5903b
LISP GPE: initial CP commit and DP improvements

Control Plane
-------------
In essence, this introduces basic support for map-request/reply
processing, the logic to generate and consume such messages, including
SMRs, a control-plane backend, consisting of an eid-table, locator and
locator-set tables, and CLI to interact with it. Naturally, we can now
serialize/deserialize LISP specific types: addresses, locators,
mappings, messages. An important caveat is that IPv6 support is not
complete, both for EIDs and RLOCs.

Functionally, the DP forwards all packets it can't handle to the CP
(lisp_cp_lookup node) which takes care of obtaining a mapping for the
packet's destination from a pre-configured map-resolver using the LISP
protocol. The CP then caches this information and programs the DP such
that all new packets with the same destination (or within the covering
prefix) are encapsulated to one of the locators retrieved in the
mapping. Ingress traffic-engineering is not yet supported.

Data Plane
----------
First of all, to enable punting to the CP, when LISP GPE is turned on a
default route that points to lisp_cp_lookup is now inserted. The DP
also exposes an API the CP can use to program forwarding for a given
mapping. This mainly consists in allocating a tunnel and programming the
FIB such that all packets destined to the mapping's prefix are forwarded
to a lisp-gpe encapsulating node.

Another important change done for lisp forwarding is that both source
and destination IP addresses are considered when encapsulating a packet.
To this end, a new FIB/mtrie is introduced as a second stage, src
lookup, post dst lookup. The latter is still done in the IP FIB but for
source-dest entries, in the dest adjacency the lookup_next_index points
to a lisp lookup node and the rewrite_header.sw_if_index points to the
src FIB. This is read by the lisp lookup node which then walks the src
mtrie, finds the associated adjacency, marks the buffer with the index
and forwards the packet to the appropriate next node (typically,
lisp-gpe-encap).

Change-Id: Ibdf52fdc1f89311854621403ccdd66f90e2522fd
Signed-off-by: Florin Coras <fcoras@cisco.com>
19 files changed:
vnet/Makefile.am
vnet/vnet/ip/udp.h
vnet/vnet/lisp-cp/control.c [new file with mode: 0644]
vnet/vnet/lisp-cp/control.h [new file with mode: 0644]
vnet/vnet/lisp-cp/gid_dictionary.c [new file with mode: 0644]
vnet/vnet/lisp-cp/gid_dictionary.h [new file with mode: 0644]
vnet/vnet/lisp-cp/lisp_cp_messages.h [new file with mode: 0644]
vnet/vnet/lisp-cp/lisp_msg_serdes.c [new file with mode: 0644]
vnet/vnet/lisp-cp/lisp_msg_serdes.h [new file with mode: 0644]
vnet/vnet/lisp-cp/lisp_types.c [new file with mode: 0644]
vnet/vnet/lisp-cp/lisp_types.h [new file with mode: 0644]
vnet/vnet/lisp-cp/packets.c [new file with mode: 0644]
vnet/vnet/lisp-cp/packets.h [new file with mode: 0644]
vnet/vnet/lisp-gpe/decap.c
vnet/vnet/lisp-gpe/encap.c
vnet/vnet/lisp-gpe/lisp_gpe.c
vnet/vnet/lisp-gpe/lisp_gpe.h
vnet/vnet/lisp-gpe/lisp_gpe_error.def
vnet/vnet/lisp-gpe/lisp_gpe_packet.h