4. Decent-Push-Based Mapping System

In the push-based system, xTRs are organized in a Mapping System group identified by an IPv4 or IPv6 multicast address, or bootstrapped through the pull-based approach. LISP Map-Register messages can be sent to the group, and members keep synchronized mapping state as Map-Servers.

A LISP-Decent xTR runs ITR, ETR, Map-Resolver, and Map-Server functions. Figure 1 is preserved from the RFC:

xTR1
 Map-Request    +--------------------+
(always local)  |  +-----+  +-----+  |
   +---------------| ITR |  | ETR |-------------+
   |            |  +-----+  +-----+  |          |
   |            |                    |          |  Map-Register to
   |            |      +-------+     |          |  EID 233.252.1.1
   +------------------>| MR/MS |<---------------+  encapsulated to
                |      +-------+     |          | RLOCs xTR1, xTR2,
                +--------------------+          |     and xTR3
                                                |
                           +--------------------+------------+
                           |                                 |
                           |                                 |
                +----------v---------+            +----------v---------+
                |     +--------+     |            |     +--------+     |
                |     |  MR/MS |     |            |     |  MR/MS |     |
                |     +--------+     |            |     +--------+     |
                |  +-----+  +-----+  |            |  +-----+  +-----+  |
                |  | ITR |  | ETR |  |            |  | ITR |  | ETR |  |
                |  +-----+  +-----+  |            |  +-----+  +-----+  |
                +--------------------+            +--------------------+
                         xTR2                              xTR3

                               Figure 1

An implementation that sends Map-Register messages to a multicast group rather than a specific Map-Server unicast address MUST call the data-plane component so ITR functionality can encapsulate the Map-Register as unicast to each group member RLOC. An ITR SHOULD periodically look up its Mapping System group address unless PubSub from RFC 9437 supplies membership changes.

When xTRs join a multicast group, site registration configuration and policy/authentication key material MUST be consistent among all members.

Core seed-groups bootstrap decentralized layers. Figure 2 and its example mapping state are preserved:

____________                 -----------
             /   core     \  233.252.2.2  /  layer-1  \
            | seed-group   | ----------> |      I      |
            |  233.252.1.1 |             |     / \     |
             \____________/              |    J---K    |
                  |                       \___________/
                  | 233.252.3.3
                  |
                  v
              ---------
             / layer-2 \
            |     X     |
            |    / \    |
            |   Y---Z   |
             \_________/

   Configured in xTRs A, B, and C (they make up the core seed-group):
     233.252.1.1 -> RLE: A, B, C

   core seed-group DMS, mapping state in A, B, and C:
     233.252.2.2 -> RLE: I, J, K
     233.252.3.3 -> RLE: X, Y, Z

   layer-1 seed-group DMS (inter-continental), mapping state in I, J, K:
      EID1 -> RLOCs: i(1), j(2)
      ...
      EIDn -> RLOCs: i(n), j(n)

   layer-2 seed-group DMS (intra-continental), mapping sate in X, Y, Z::
      EIDa -> RLOCs: x(1), y(2)
      ...
      EIDz -> RLOCs: x(n), y(n)

                                  Figure 2

For the map-cache entry to be populated for 233.252.2.2, the data plane MUST send a Map-Request so RLOCs I, J, and K are cached for replication. To use the core seed-group Mapping System, the data plane MUST know at least one of RLOCs A, B, or C.