4.1. Packet Flow Sequence (分组流序列)

本节在以下条件给出单播分组流的示例:

源主机 "host1.abc.example.com" 向 "host2.xyz.example.com" 发送分组, 与站点未使用 LISP 时 host1 的行为完全相同.
每个站点均为多宿主, 因此每个隧道路由器对于其连接的每个提供商, 都从该提供商的地址块分配一个地址 (RLOC).
ITR 与 ETR 分别直接连接源与目的地, 但源与目的地可位于 LISP 站点内任意位置.
Map-Request 可在底层路由系统拓扑上发送, 发往映射数据库系统, 或直接通过 Alternative Logical Topology (替代逻辑拓扑) [RFC6836] 发送. 当转发表中找不到外部目的地或匹配默认路由时, 发送 Map-Request.
Map-Reply 在底层路由系统拓扑上发送.

客户机 host1.abc.example.com 希望与服务器 host2.xyz.example.com 通信:

host1.abc.example.com 希望与 host2.xyz.example.com 建立 TCP 连接. 它对 host2.xyz.example.com 执行 DNS 查找. 返回 A/AAAA 记录. 该地址是目的 EID. host1.abc.example.com 的本地分配地址用作源 EID. 构建 IPv4 或 IPv6 分组并在 LISP 站点内作为普通 IP 分组转发, 直到到达 LISP ITR.
LISP ITR 必须能够将目的 EID 映射到目的站点某个 ETR 的 RLOC. 本示例不描述所用具体方法. 可能方案见 [RFC6836] 或 [CONS].
ITR 将发送 LISP Map-Request. Map-Request 应该被限速.
当未使用替代映射系统时, Map-Request 分组通过底层路由系统路由. 否则, Map-Request 分组在替代逻辑拓扑上路由, 例如 [RFC6836] 数据库映射系统. 无论哪种情况, 当 Map-Request 到达目的站点的某个 ETR 时, 它将把该分组作为控制消息处理.
ETR 查看 Map-Request 的目的 EID, 并将其与 ETR 已配置的 EID-to-RLOC 映射数据库中的前缀匹配. 这是 ETR 为其所在站点支持的 EID-Prefix 列表. 若无匹配, 则丢弃 Map-Request. 否则, 向 ITR 返回 LISP Map-Reply.
ITR 接收 Map-Reply 消息, 解析消息 (以检查格式有效性), 并存储来自分组的映射信息. 该信息存储在 ITR 的 EID-to-RLOC 映射缓存中. 注意 map-cache 是按需缓存. ITR 将以优化其资源约束的方式管理其 map-cache.
随后从 host1.abc.example.com 到 host2.xyz.example.com 的分组将由 ITR 添加 LISP 首部, 使用从 ETR 获知的适当 RLOC 作为 LISP 首部目的地址. 注意, 由于源站点的哈希策略或目的站点的 Locator-Set 策略, 分组可能被发送到与返回 Map-Reply 的 ETR 不同的 ETR.
ETR 直接接收这些分组 (因为目的地址是其分配的 IP 地址之一), 检查地址有效性, 剥离 LISP 首部, 并将分组转发给所连接的目的主机.

为推迟反方向映射查找的需求, ETR 可以创建缓存条目, 将源 EID (内层首部源 IP 地址) 映射到在收到的 LISP 分组中的源 RLOC (外层首部源 IP 地址). 此类缓存条目称为 "gleaned (收集得到的)" 映射, 且仅包含该 EID 的单个 RLOC. 关于额外 RLOC 的更完整信息应通过为该 EID 发送 LISP Map-Request 来验证. ITR 与 ETR 也可影响对方在 RLOC 选择上的决策. 更多细节见第 6 节.

4.1. Packet Flow Sequence (分组流序列)​

4.1. Packet Flow Sequence (分组流序列)