In traditional routing protocols, the control plane facilitates the exchange of routing information between routers. This information is then used in the data plane to forward packets. LISP used a different architecture and mechanism in building the control plane; routers (Egress Tunnel Router (ETR)) send EID-to-RLOC mappings to the  MAP server which is then published into a mapping database. Ingress Tunnel Router (ITR) then sends a map-request to the Map-Resolver, which initiates the process of  EID-to-RLOC mapping resolution. 

This process of:

  • The ETR updating the Map-Server with EID-to-RLOC mappings,
  • The Map-Server publishing this into a mapping database,
  • The Map-Resolver accepting Map-Requests from an Ingress Tunnel Router (ITR) and resolving the EID-to-RLOC mapping by consulting a mapping database system, 

constitutes the control plane operation in LISP.

This LISP control plane and mapping service can be used by data planes like LISP [RFC9300], Virtual eXtensible Local Area Networks (VXLANs) [RFC7348], GRE [RFC2890], and Segment Routing (SRv6) [RFC8402].

To build this control plane, LISP leverages a number of messages. These control plane messages facilitate the exchange of mapping information between various network entities. In this article, we discuss the messages that are used to build the LISP control plane.

Map-Request: The Map-Request message serves as the initiation point for resolving EID-to-RLOC mappings. This is sent by the ITR. When an ITR needs to communicate with another device whose location is unknown by the ITR, it sends out a Map-Request message to the Map-Resolver (MR). This message contains the EID for which mapping information is requested. A map-request can also be sent if an ITR wants to test an RLOC for reachability, or wants to refresh a mapping before Time to Live (TTL) expiration. The Map-Request is a UDP message with a random source port number and a well-known destination port number of 4342. Upon receipt of the map-request, the MR checks its local database if it has an entry for the requested mapping. If it does (statically configured or learned from associated ETRs if the Map-Resolver is also a Map-Server offering proxy reply service), it (MR) responds with a Map-Reply. If the MR doesn’t have an entry, it forwards the Map-Request to a Map-Server (MS). The MS then forwards the Map-Request to the ETR which registered the EID-prefix, which answers the Map-Request with a Map-Reply directly to the ITR.

Map-Reply:  The Map-Reply is sent in response to a Map-Request. This can be sent from the ETR directly to the ITR, from the MR to the ITR if MR has a mapping entry in its local database for the map-request, or from the MS if the ETR has requested the MS to answer the Map-Request on its behalf. For this to happen, the ETR has to enable the “proxy Map-Reply” flag (P-bit) in the Map-Register message (Map-Register message will be discussed later in this article). The map-reply is a  UDP message with a  source port number of  4342, and a destination port number being the source port of the Map-Request message. After this ITR receives a map-reply with the EID-to-RLOC mapping, it installs this locally in its map-cache.  The ITR can then use the entry in the local map-cache for future communications to the destination EID.

Negative Map-Reply: This is sent by the MR in response to a map-request for which the destination IP address is not part of the EID namespace; that is the destination EID does not exist in the mapping database. Typically, this means that the EID being requested is an IP address connected to a non-LISP site.In essence, this is a Map-Reply that contains an empty Locator-Set. The ITR saves the EID-Prefix returned in the Map-Reply in its cache, marks it as non-LISP-capable, and knows not to attempt LISP encapsulation for destinations matching it.

Map-Register: The Map-Register message is sent by an ETR to a Map-Server to register its associated EID-Prefixes. This is done every 60 seconds. A Map-Server times out and removes an ETR’s registration if it has not received a valid Map-Register message within the past three minutes. The map-register is a UDP message with a random source port number. and a well-known destination port number of 4342. An ETR may request that a Map-Server explicitly acknowledge receipt and processing of a Map-Register message by setting the “want-map- notify” (M-bit) flag. A Map-Register message includes Authentication Data, so prior to sending a Map-Register message, the ETR and Map-Server must be configured with a pre-shared secret used to derive Map-Register authentication keys. 

Map-Notify message:  A LISP message sent by a Map-Server to an ETR to confirm that a Map-Register has been received and processed.  An ETR requests that a Map-Notify be returned by setting the “want-map-notify” flag (M-bit) in the Map-Register message.  Unlike a Map-Reply, a Map-Notify uses UDP port 4342 for both source and destination.  Map-Notify messages are also sent to ITRs by Map-Servers when there are RLOC-Set changes.To provide

reliability for Map-Notify messages, a Map-Notify-Ack message is sent by the ETR in response to the Map-Notify message.

Encapsulated Map-Request/Map-Reply: In scenarios where a LISP-capable device needs to communicate with a non-LISP device, encapsulation and decapsulation of Map-Request and Map-Reply messages occur. The LISP-capable device encapsulates the messages within standard IP packets, allowing them to traverse non-LISP networks. Upon reaching the destination, the packets are decapsulated, and the original Map-Request or Map-Reply message is processed.

In summary, if an ITR needs to resolve an EID-to-RLOC mapping in order to send a packet to a destination EID, the following occurs;

  1. ITR does a lookup for destination EID in its local map-cache. If there’s an entry, it LISP encapsulates the packet and sends the packet to destination (ETR).
  2. If there is no entry in the ITR’s local map-cache, it sends a map-request to the MR.
  3. The MR may respond if it has an entry in its local database. If not, the MR forwards this message to the MS.
  4. The MS may respond on behalf of the ETR if the ETR has requested the MS to do so. If not, the MS forwards this message to the ETR.
  5. The ETR searches its mapping database for the RLOC of the requested EID.
  6. ETR returns the RLOC in a Map-Reply directly to the ITR.
  7. ITR updates its local map-cache with mapping, and uses this to LISP encapsulate and send subsequent packets directly to ETR

For EID-to-RLOC mapping to be registered to the mapping systems;

  1. ETR sends periodic Map-Register messages containing EID-to-RLOC mappings to Map-Server
  2. MS receives the map-register messages, saves this for the LISP site, and sends a map-notify to ETR if this was requested by the ETR.
  3. The ETR sends a Map-Notify-Ack to the MS.

References:

– [RFC 9301](https://datatracker.ietf.org/doc/rfc9301): “Locator/ID Separation Protocol (LISP) Control Plane “

– [RFC 6830](https://datatracker.ietf.org/doc/html/rfc6830): “The Locator/ID Separation Protocol (LISP)”

LISP (Locator/ID Separation Protocol) Control Plane
Tagged on:                     

Leave a Reply

Your email address will not be published. Required fields are marked *