Explanation

+ accepts LISP encapsulated map requests: LISP map resolver
+ learns of EID prefix mapping entries from an ETR: LISP map server
+ receives traffic from LISP sites and sends it to non-LISP sites: LISP proxy ETR
+ receives packets from site-facing interfaces: LISP ITR
Explanation
ITR is the function that maps the destination EID to a destination RLOC and then encapsulates the original packet with an additional header that has the source IP address of the ITR RLOC and the destination IP address of the RLOC of an Egress Tunnel Router (ETR).
After the encapsulation, the original packet become a LISP packet.
ETR is the function that receives LISP encapsulated packets, decapsulates them and forwards to its local EIDs. This function also requires EID-to-RLOC mappings so we need to point out an "map-server" IP address and the key (password) for authentication.
A LISP proxy ETR (PETR) implements ETR functions on behalf of non-LISP sites. A PETR is typically used when a LISP site needs to send traffic to non-LISP sites but the LISP site is connected through a service provider that does not accept no routable EIDs as packet sources. PETRs act just like ETRs but for EIDs that send traffic to destinations at non-LISP sites.
Map Server (MS) processes the registration of authentication keys and EID-to-RLOC mappings. ETRs sends periodic Map-Register messages to all its configured Map Servers.
Map Resolver (MR): a LISP component which accepts LISP Encapsulated Map Requests, typically from an ITR, quickly determines whether or not the destination IP address is part of the EID namespace

Explanation

Explanation
https://community.cisco.com/t5/networking-documents/how-to-configure-a-gre-tunnel/ta-p/3131970#toc-hId--14

Explanation
The Southbound API is used to communicate with network devices.

Explanation
A Cisco lightweight wireless AP needs to be paired with a WLC to function.
An AP must be very diligent to discover any controllers that it can join-all without any preconfiguration on your part. Toaccomplish this feat, several methods of discovery are used. The goal of discovery is just to build a list of live candidatecontrollers that are available, using the following methods: + Prior knowledge of WLCs
+ DHCP and DNS information to suggest some controllers (DHCP Option 43) + Broadcast on the local subnet to solicit controllers Reference: CCNP and CCIE Enterprise Core ENCOR 350-401 Official Cert Guide If you do not tell the LAP where the controller is via DHCP option 43, DNS resolution of
"Cisco-capwap-controller.local_domain", or statically configure it, the LAP does not know where in the network to find the managementinterface of the controller.
In addition to these methods, the LAP does automatically look on the local subnet for controllers with a
255.255.255.255local broadcast.
Reference:
https://www.cisco.com/c/en/us/support/docs/wireless/5500-series-wireless-controllers/119286-lap-notjoin-wlc-ts