6.2. Routing Locator Selection (路由定位符选择)

6.2. Routing Locator Selection (路由定位符选择)

客户端与服务器端都可能需要控制彼此会话所用的 RLOC 选择. 通过操纵 EID-to-RLOC Map-Reply 消息中的 Priority 与 Weight 字段实现. 亦可从收到的隧道分组或 EID-to-RLOC Map-Request 消息中 glean RLOC 信息.

选择 RLOC 的若干场景与可用控制如下:

o 服务器端只返回一个 RLOC. 客户端只能使用该 RLOC. 服务器端完全控制选择.

o 服务器端返回 RLOC 列表, 其中子集具有相同最优 Priority. 客户端只能按服务器端赋予的权重使用该子集. 服务器端同时控制子集及其成员间的负载分担. 若客户端判定子集不可达 (除非 RLOC 的 Priority 设为 255), 可使用子集外的 RLOC. 控制部分共享: 服务器端决定目的 RLOC 列表与负载分布, 客户端在列表内 RLOC 不可达时可选用替代.

o 服务器端将 RLOC 子集的 Weight 设为 0. 客户端可自行决定如何在子集上分摊流量. 服务器端定列表, 客户端定负载分布. 客户端仍可在服务器提供列表不可达时使用其他 RLOC.

o 任一侧 (更常见为服务器端 ETR) 决定不发送 Map-Request. 例如服务器端 ETR 不发送 Map-Request 时, 从客户端 ITR glean RLOC, 由客户端 ITR 负责双向 RLOC 可达性与偏好. 服务器端 ETR 通过缓存所收分组的内层源 EID 与外层源 RLOC 实现 glean. 客户端 ITR 控制返回流量方式, 可轮换使用外层源 RLOC, 从而加入服务器端 ETR 用于返回流量的列表. 此方法不提供 Priority 或 Weight, 服务器端 ETR 必须假定每个客户端 ITR RLOC 具有相同最优 Priority 且 Weight 为零. 此外数据分组无法传达 EID-Prefix 编码, Tunnel Router 上 EID-to-RLOC Cache 可能变得很大.

o "gleaned" Map-Cache 项 (从所收封装分组源 RLOC 学到) 仅存储并使用数秒以待验证. 验证通过向所收封装分组的源 EID (内层 IP 源地址) 发送 Map-Request 完成. 对此 "验证用 Map-Request" 的应答用于完整填充 "gleaned" EID 的 Map-Cache 项, 并按所收 Map-Reply 的 TTL 字段存储使用. 验证项存入后, 源 EID 匹配已验证项 EID-Prefix 的后续分组不再进行数据 glean.

EID-to-RLOC Map-Reply 中出现的 RLOC, 当 Locator 记录的 R 位置 1 时假定可达. R 位为 0 时, ITR 或 PITR 不得向该 RLOC 封装. Map-Reply 所含信息或映射数据库系统存储的信息均不提供 RLOC 的路径可达性. 可达性不属于映射系统, 由下一节所述一种或多种 Routing Locator 可达性算法确定.