4. 基于 Decent-Push 的映射系统

在基于 push 的系统中, xTR 被组织成由 IPv4 或 IPv6 组播地址标识的 Mapping System group, 或通过基于 pull 的方法引导. LISP Map-Register 消息可发送到该 group, 成员作为 Map-Server 保持同步的映射状态.

LISP-Decent xTR 运行 ITR, ETR, Map-Resolver 和 Map-Server 功能. Figure 1 展示了该模型:

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

若实现将 Map-Register 消息发送到组播 group 而不是特定 Map-Server 单播地址, 则必须调用数据平面组件, 使 ITR 功能能够把 Map-Register 封装为发往每个 group member RLOC 的单播数据包. 除非使用 RFC 9437 的 PubSub 接收成员变化通知, ITR 应该定期查找自己的 Mapping System group 地址.

当 xTR 加入组播 group 时, 站点注册配置以及策略/认证密钥材料必须在所有成员之间保持一致.

core seed-group 用于引导去中心化层. Figure 2 展示了示例映射状态:

____________                 -----------
             /   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   |
             \_________/

   在 xTR A, B 和 C 中配置 (它们组成 core seed-group):
     233.252.1.1 -> RLE: A, B, C

   core seed-group DMS, A, B 和 C 中的映射状态:
     233.252.2.2 -> RLE: I, J, K
     233.252.3.3 -> RLE: X, Y, Z

   layer-1 seed-group DMS (洲际), I, J, K 中的映射状态:
      EID1 -> RLOCs: i(1), j(2)
      ...
      EIDn -> RLOCs: i(n), j(n)

   layer-2 seed-group DMS (洲内), X, Y, Z 中的映射状态:
      EIDa -> RLOCs: x(1), y(2)
      ...
      EIDz -> RLOCs: x(n), y(n)

                                  Figure 2

为了填充 233.252.2.2 的 map-cache 条目, 数据平面必须发送 Map-Request, 使 RLOC I, J 和 K 被缓存以便复制. 要使用 core seed-group Mapping System, 数据平面必须至少知道 RLOC A, B 或 C 中的一个.