LISP Delegated Mappings

As new compute system environments emerge, routing networks have been adapting to serve their communication needs. In many of these cases, network controllers or orchestration engines are used to organize resources or enforce network policies in a centralized manner. Examples of these types of systems range from wireless systems in enterprise environments, Software-Defined Networks (SDN) (e.g., in WAN, Datacenter, or Campus environments), and include public (or private) cloud networks. In all these cases, it is common that a centralized controller or orchestrator drives how endpoints authenticate, join, leave, or move within the network. In many cases, this centralized controller is also the point of reference that determines the policies that need to be enforced. Networks running the LISP protocol can exploit the vantage point of these controllers for early and faster onboarding and movement of endpoints at selected locations of the network. Controllers that deploy or authenticate sites and endpoints can interface directly with the Mapping System to distribute this information to selected locations (xTRs). This document specifies Delegated Mappings, where a controller can use its interface to a LISP Mapping System to delegate ownership of specific EIDs to selected xTRs of the network. The document provides a detailed description of the mechanisms used to distribute this type of mappings in a network running the LISP protocol. In particular, the specification describes: How a controller may use the LISP Map-Register and Map-Notify interfaces to distribute Delegated Mappings to LISP sites that should take ownership of specific EIDs. The procedures that an ETR follows to take ownership of a Delegated Mapping so that an EID can be resolved using LISP protocol procedures. Finally, it also details how the controller can make use of specific LCAF encodings such as ELPs and multiple data-planes (see ), to convey EID access information to the corresponding ETR. Note also that Delegated Mappings can be combined with the procedures specified in to support controller-based mobility in a network running the LISP protocol.

The document uses the terms defined in Section 3 of documents and . Additionally, this document introduces the following terms:

Delegated Mapping:: This is the term used in this document to identify a Mapping record registered with the Mapping system so that it is relayed (delegated) to a corresponding xTR (or xTRs) of a LISP site.
xTR-Controller:: This term designates a network element that uses Delegated Mappings to distribute EID records to the corresponding LISP sites where they are connected to.

illustrates a reference system model used to support the discussion of Delegated Mappings through this section.

A xTR-controller implements LISP control-plane interfaces so that it can interact with the LISP Mapping System, represented with a single Map-Server in the figure. The interconnection between the xTR-controller and the Map-Server is out of the scope of this specification, but the Map-Server MUST be able to handle Map Registration procedures through this connection. The network running the LISP protocol has two sites (A and B) with the corresponding xTRs providing access to them. There is a local endpoint on each one of the sites (host 1 and 2) For the purpose of this specification the xTR-Controller knows when endpoints are connected, authenticated or released from each one of the sites. The controller is also aware of the xTRs (and their corresponding RLOC addresses) that provide access to each one of the sites.

When a xTR-Controller attempts to use the process of Delegated Mappings to distribute EID Mappings to target LISP sites, it MUST know beforehand the RLOCs of the xTRs providing access to those sites. Using as reference, the xTR-controller knows that IP_A is the RLOC of xTR A, associated to site A. Using this information, the xTR-controller uses Delegated Mappings to distribute information about Host 1 to Site A using the following procedures:

The xTR-Controller builds a Map-Register with the EID record information it wants to distribute. The Map-Register carries the Delegated Mapping (D) bit set (see ). Using the reference example, the xTR-Controller sends a Map-Register to the Map-Server that carries the EID-to-RLOC mapping of EID=<10.0.0.1> -> RLOC=IP_A and is built with the D-bit set.
When a Map-Server receives a Map-Register with the D-bit set, it prepares a Map-Notify with the same EID record that also has the D-bit set. This Map-Notify is sent to all the RLOCs in the RLOC record of the Mapping. Following the example, the Map-Server sends a Map-Notify with the D-bit set to IP_A (RLOC of xTR A).
When an ETR receives a Map-Notify with the D-bit set, it verifies that its own RLOC is in the RLOC record of the Mapping in the message. When that is the case, the ETR creates an entry for the EID in its database mapping. Continuing with the example, xTR A receives the Map-Notify with the D-bit set and learns that EID=<10.0.0.1> is local to site A.
Once the ETR verifies the presence of the EID in the site, it confirms the EID with a new Map-Register to the Map-Server. This is a regular Map-Register, without the D-bit and marked as authoritative. In the example the ETR sends an authoritative Map-Register with EID-to-RLOC mapping of EID=<10.0.0.1> -> RLOC=IP_A.

This operation repeats for every EID and for every site that the xTR-Controller wants to distribute information to.

The distribution of Delegated Mappings relies on the use of the D-bit (see ) both in the Map-Register and Map-Notify messages. The xTR-Controller sending a Delegated Mapping MUST NOT set the authoritative bit in the EID record. Only the site ETR, after accepting a Delegated Mapping can set this bit when registering the EID prefix. Equally, a Map-Register carrying a Delegated Mapping MUST NOT have the Proxy Map-Reply bit (P-bit) or the security-capable (S-bit) set. Since the xTR-controller is not authoritative for the Mapping, it cannot set either of these bits. Only the authoritative ETR for the destination site can set these bits with its corresponding Map-Register, when accepting the Delegated Mapping. A Delegated Mapping can also be removed. In that case the xTR-Controller MUST send the Map-Register with the D-bit and with a TTL with value 0 in the EID record. This removal MUST carry the RLOC record corresponding to the site that the Delegated Mapping is being removed from. The Map-Notify with the D-bit set is sent to all the RLOCs in the RLOC record with the same TTL of value 0.

A Map-Server that supports Delegated Mappings, SHOULD send a Map-Notify with the D-bit to all the RLOCs in the RLOC record of the Delegated Mapping. A Map-Server MAY record in its registration table a Delegated Mapping, but it MUST NOT use a Delegated Mapping Record to send a proxy Map-Reply in response to a Map-Request for the EID in the Mapping. In such a case, the Map-Server MAY forward the Map-Request to one of the RLOCs in the record, following . This restriction extends to the procedures described in . A Map-Server MUST NOT send Map-Notify with a Delegated Mapping as a publication message for EID subscribers. Only the Map-Register from the authoritative ETR can be published following LISP Publish/Subscribe procedures. In order to avoid periodic Map-Register and Map-Notification messages, Delegated Mappings MAY be distributed using a reliable transport as described in .

When an ETR receives Map-Notify with a Delegated Mapping (D-bit set) that carries its own RLOC in the RLOC record it SHOULD verify the reachability of the EID in the site before accepting the mapping. The verification process is out of scope of this document. Once the Mapping is accepted the ETR adds the EID in its local mapping database and it MUST send a Map-Register with the EID Record setting the authoritative bit (A-bit). The ETR MUST be able to follow procedures described in and when handling EID records learned through the Delegated Mapping procedure. When the ETR receives a Map-Notify with a Delegated Mapping with a TTL of value 0 it SHOULD remove the EID from the local mapping database. When the ETR receives a Delegated Mapping that does not carry its own RLOC in the RLOC record it MUST follow the procedures described in and handle this as a mobility event.

This document proposes an extension of the Map-Register and Map-Notify messages to carry the notion that a Mapping is being distributed as a Delegated Mapping. This information is used by both Map-Server and ETRs to implement the procedures described in this specification.

The Map-Register header, as defined in is extended with an additional field, the Delegated Mapping bit (D-bit). This is the Delegated Mapping bit in the Map-Register header. It should be set to 1 when Map-Register messages carry Delegated Mappings. When D-bit is set the P-bit and S-bit MUST be 0.

a The Map-Notify header, as defined in , is extended with an additional field, the Delegated Mapping bit. This is the Delegated Mapping bit in the Map-Notify header. It should be set to 1 when the Map-Notify message carries a Delegated Mapping.

In many cases a controller using Delegated Mappings needs to convey EID access information to the ETRs that receive the EID record. This access information indicates what is the path that the ETR can take to reach the EID within the local site. As a reference example, if we take site B in the reference system, illustrates the case when there is an intermediate router (r) between xTR B and Host 2. In this example xTR B must route traffic through the intermediate router to reach the endpoint:

A xTR-Controller MAY use ELPs (LCAF type 10 in ) in Delegated Mappings to convey information to the ETR about how to access the EID, when required. The ETR can use this information to program a forwarding path to the EID and also to verify reachability of the EID before accepting a Delegated Mapping. The First locator in the ELP sequence MUST correspond to the RLOC of the ETR and the rest of locators MUST correspond to the sequence of hops that the ETR should follow to reach the EID. It is worth noting also that local site reachability between the ETR and the endpoint may not require encapsulation or alternative encapsulations to the one used in the rest of the network. To solve this case each locator in the ELP is sent using the Multiple Data-Planes LCAF (Type 16 in ) and selecting the bit corresponding to the encapsulation type. When no encapsulation is needed Type 16 is also used but with all encapsulation bits set to 0. In order to illustrate this, exemplifies the use of the ELP and Multiple Data-Plane LCAFs for the figure above. In this reference encoding, the ELP carries both the IP address of xTR B and the intermediate router r. The IP of the intermmediate router is disttribured indicating that no encapsulation is needed and xTR B can access Host 2 routing packets through IP_r.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E | Locator Count | EID mask-len | ACT |A| Reserved | I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D | Rsvd | Map-Version Number | EID-AFI = 1 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | EID-Prefix (10.1.1.2) | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c /| Priority | Weight | M Priority | M Weight | o | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r R | Unused Flags |L|p|R| AFI = 16387 | d L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | O | Rsvd1 | Flags | Type = 10 | Rsvd2 | | C +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Length | Rsvd3 |L|P|S| | R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | E | AFI = 1 or 2 | IP_B ~ | C +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | O ~ IP_B | | R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | D | Rsvd3 |L|P|S| AFI = 16387 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | E | Rsvd1 | Flags | Type = 16 | Rsvd2 | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P | Length | 0 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 0 | AFI = 1 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| IP_r | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]>

Delegated Mappings can be used in environments running the LISP protocol that implement VPN based segmentation () and EID mobility ().

Delegated Mappings can be distributed using VPN segmentation procedures, following the procedures described in . When the xTR-controller intents to distribute EIDs within specific VPN segments, it MUST use the same IID that is used in the target LISP site for that segment. Following the same procedures, a Map-Register and Map-Notify with the D-bit set carry the XEID encoded using the Instance-id LCAF () in the EID record. An ETR receiving a Map-Notify with the D-bit set and with an IID that is not known or used, SHOULD ignore the Map-Notify. It is NOT RECOMMENDED to use Delegated Mappings with extranet encoding to distribute Mappings across IID boundaries. The Map-Server SHOULD prevent this distribution.

When Delegated Mappings are combined with the procedures of , a controller can be used to drive the mobility of EIDs through the network. A Map-Server that receives a Map-Register with the D-bit set, SHOULD generate a Map-Notify with the D-bit set to all ETRs that have an active registration of the Mapping. When an ETR receives a Delegated Mapping with a RLOC record that does not have any local RLOC on the ETR, it must treat the Mapping as a mobility event and follow the procedures in

Delegated Mappings can be distributed using a reliable transport as described in . Since both Map-Register and Map-Notify encodings are reuse when sending Reliable Registrations and Reliable Notifications, the same D-bit is used in this case to indicate the distribution of a Delegated Mapping.

Map-Register and Map-Notify messages MUST be authenticated following the procedures specified in . XTR-Controllers follow the same procedures. Map-Notify messages carrying Delegated Mappings are handled by ETRs as unsolicited Map-Notify messages, following . The Map-Server MUST use the pre-shared key associated to the target Site of the Delegated Mapping to authenticate the Map-Notify.

This memo includes no request to IANA.