跳到主要内容

RFC 3031 - MPLS 架构的核心组成部分（Detailed MPLS Architecture）

3. MPLS 基础 (MPLS Basics)​

在本节中, 我们介绍 MPLS 的一些基本概念, 并描述将要采用的一般方法.

3.1 标签 (Labels)​

标签 (label) 是一个短的, 定长的, 具有本地意义的标识符, 用于标识一个 FEC. 加在特定分组上的标签, 代表该分组被归入的转发等价类.

最常见的情况是, 分组基于 (全部或部分) 其网络层目的地址被归入某个 FEC. 然而, 标签绝不是该地址的一种编码.

如果 Ru 和 Rd 是两个 LSR, 它们可以约定: 当 Ru 向 Rd 发送分组时, 当且仅当该分组属于特定 FEC F, Ru 才用标签值 L 加标该分组. 也就是说, 对于从 Ru 发往 Rd 的分组, 它们可以就标签 L 与 FEC F 之间的 "绑定" 达成一致. 这种约定的结果是: L 成为 Ru 的代表 FEC F 的 "出标签", 并且 L 成为 Rd 的代表 FEC F 的 "入标签".

注意, 对于除从 Ru 发往 Rd 的分组之外的其他任何分组, L 不一定代表 FEC F. L 是一个任意值, 它与 F 的绑定仅为 Ru 和 Rd 本地所知.

上文提到分组从 Ru "发往" Rd 时, 我们并不暗示该分组起源于 Ru, 也不暗示其目的地是 Rd. 更确切地说, 我们的意思是包括那些在一个或两个 LSR 处都属于 "过境分组" (transit packets) 的分组.

有时, Rd 可能难以甚至无法判断: 在携带标签 L 的到达分组中, 标签 L 是由 Ru 加上去的, 而不是由其他某个 LSR 加上去的. (当 Ru 和 Rd 不是直接邻居时, 情况通常如此.) 在这种情况下, Rd 必须确保标签到绑定的映射是一对一的. 也就是说, Rd 在与 Ru1 约定把 L 绑定到 FEC F1 的同时, 禁止再与其他某个 LSR Ru2 约定把 L 绑定到不同的 FEC F2, 除非 Rd 在收到携带入标签 L 的分组时总能分辨出: 该标签是 Ru1 加上去的, 还是 Ru2 加上去的.

每个 LSR 有责任确保自己能够唯一地解释自己的入标签.

3.2 上游与下游 LSR (Upstream and Downstream LSRs)​

假设 Ru 和 Rd 已经约定, 对于从 Ru 发往 Rd 的分组, 把标签 L 绑定到 FEC F. 那么就这一绑定而言, Ru 是 "上游 LSR", Rd 是 "下游 LSR".

说一个节点相对于给定绑定是上游, 另一个是下游, 只意味着: 在从上游节点流向下游节点的分组中, 某个特定标签代表某个特定 FEC. 这并不意味着该 FEC 中的分组实际上会被从上游节点路由到下游节点.

3.3 带标签分组 (Labeled Packet)​

"带标签分组" (labeled packet) 是一个编码了标签的分组. 在某些情况下, 标签位于专为此目的而存在的封装头部之中. 在另一些情况下, 标签可能位于现有的数据链路层或网络层头部之中, 只要其中有一个可用于此目的的字段. 所使用的具体编码技术必须由编码标签的实体与解码标签的实体双方约定.

3.4 标签分配与分发 (Label Assignment and Distribution)​

在 MPLS 架构中, 把特定标签 L 绑定到特定 FEC F 的决定, 由相对于该绑定处于下游 (DOWNSTREAM) 的 LSR 做出. 然后由下游 LSR 把该绑定告知上游 LSR. 因此, 标签是 "下游分配" 的 (downstream-assigned), 标签绑定按 "下游到上游" 的方向分发.

如果一个 LSR 的设计使它只能查找落在某个数值范围内的标签, 那么它只需确保自己只绑定该范围内的标签.

3.5 标签绑定的属性 (Attributes of a Label Binding)​

由 Rd 分发给 Ru 的一个特定标签 L 到 FEC F 的绑定, 可以带有相关的 "属性". 如果 Ru 作为下游 LSR 也分发一个标签到 FEC F 的绑定, 那么在某些条件下, 它可能被要求同时分发它从 Rd 收到的相应属性.

3.6 标签分发协议 (Label Distribution Protocols)​

标签分发协议是一套规程, 借助它, 一个 LSR 把自己已做出的标签/FEC 绑定告知另一个 LSR. 使用标签分发协议交换标签/FEC 绑定信息的两个 LSR, 就它们交换的绑定信息而言被称为 "标签分发对等体" (label distribution peers). 如果两个 LSR 互为标签分发对等体, 我们就说它们之间存在 "标签分发邻接" (label distribution adjacency).

(注意: 两个 LSR 可以就某组绑定互为标签分发对等体, 而就另一组绑定则不是.)

标签分发协议还包括两个标签分发对等体为相互了解对方的 MPLS 能力而需要进行的任何协商.

本架构不假定只存在单一的标签分发协议. 事实上, 若干不同的标签分发协议正在被标准化. 现有协议已被扩展, 使得标签分发可以搭载其上 (见 [MPLS-BGP], [MPLS-RSVP-TUNNELS]). 也定义了一些以分发标签为明确目的的新协议 (见 [MPLS-LDP], [MPLS-CR-LDP]).

在本文档中, 我们尽量把缩写 "LDP" 专指 [MPLS-LDP] 定义的协议; 在泛指标签分发协议时, 我们尽量避免使用该缩写.

3.7 下游自主与按需下游 (Unsolicited Downstream vs. Downstream-on-Demand)​

MPLS 架构允许 LSR 就特定 FEC 向其下一跳显式请求该 FEC 的标签绑定. 这称为 "按需下游" (downstream-on-demand) 标签分发.

MPLS 架构也允许 LSR 向未显式请求绑定的 LSR 分发绑定. 这称为 "下游自主" (unsolicited downstream) 标签分发.

预期某些 MPLS 实现只提供按需下游标签分发, 某些只提供下游自主标签分发, 还有一些两者都提供. 提供哪种可能取决于特定实现所支持接口的特性. 然而, 这两种标签分发技术可以在同一网络中同时使用. 在任何给定的标签分发邻接上, 上游 LSR 与下游 LSR 必须就使用哪种技术达成一致.

3.8 标签保留模式 (Label Retention Mode)​

LSR Ru 可能收到 (或已经收到) 来自 LSR Rd 的针对特定 FEC 的标签绑定, 即使 Rd 不是 (或不再是) Ru 在该 FEC 上的下一跳.

Ru 可以选择跟踪这类绑定, 或者丢弃这类绑定. 如果 Ru 跟踪这类绑定, 那么一旦 Rd 最终成为该 FEC 的下一跳, 它就可以立即重新开始使用该绑定. 如果 Ru 丢弃这类绑定, 那么如果 Rd 后来成为下一跳, 就必须重新获取绑定.

如果 LSR 支持 "宽松标签保留模式" (Liberal Label Retention Mode), 它会维护从并非其该 FEC 下一跳的 LSR 收到的标签与 FEC 之间的绑定. 如果 LSR 支持 "保守标签保留模式" (Conservative Label Retention Mode), 它会丢弃这类绑定.

宽松标签保留模式可以更快地适应路由变化, 但保守标签保留模式要求 LSR 维护的标签少得多.

3.9 标签栈 (The Label Stack)​

到目前为止, 我们的讨论仿佛带标签分组只携带单个标签. 我们将会看到, 采用一个更一般的模型更有用: 带标签分组携带多个标签, 组织为一个后进先出的栈. 我们称之为 "标签栈" (label stack).

虽然我们将会看到 MPLS 支持层次结构, 但对带标签分组的处理完全独立于层次级别. 处理总是基于栈顶标签, 而不管过去是否曾有若干其他标签 "在它之上", 也不管当前是否有若干其他标签在它之下.

未打标签的分组可以看作标签栈为空 (即标签栈深度为 0) 的分组.

如果分组的标签栈深度为 m, 我们把栈底的标签称为第 1 层标签, 把它之上的标签 (如果存在) 称为第 2 层标签, 把栈顶的标签称为第 m 层标签.

标签栈的用途将在我们引入 LSP 隧道与 MPLS 层次结构的概念时 (第 3.27 节) 变得清晰.

3.10 下一跳标签转发表项 (NHLFE)​

"下一跳标签转发表项" (NHLFE, Next Hop Label Forwarding Entry) 用于转发带标签分组. 它包含以下信息:

  1. 分组的下一跳

  2. 对分组标签栈执行的操作; 它是以下操作之一:

    a) 用指定的新标签替换标签栈顶的标签

    b) 弹出标签栈

    c) 用指定的新标签替换标签栈顶的标签, 然后把一个或多个指定的新标签压入标签栈.

它还可以包含:

d) 传输分组时使用的数据链路封装

e) 传输分组时对标签栈的编码方式

f) 为妥善处置分组所需的任何其他信息.

注意, 在给定的 LSR 处, 分组的 "下一跳" 可能就是该 LSR 自身. 在这种情况下, LSR 需要弹出顶层标签, 然后把所得分组 "转发" 给自己. 随后它会基于弹出标签栈之后剩下的内容再做一次转发决策. 此时它可能仍是带标签分组, 也可能是原生 IP 分组.

这意味着, 在某些情况下, LSR 可能需要操作 IP 头部才能转发分组.

如果分组的 "下一跳" 是当前 LSR, 那么标签栈操作必须是 "弹出栈".

3.11 入标签映射 (ILM)​

"入标签映射" (ILM, Incoming Label Map) 把每个入标签映射到一组 NHLFE. 它用于转发那些以带标签分组形式到达的分组.

如果 ILM 把某个标签映射到包含多个元素的 NHLFE 集合, 那么在转发分组之前必须恰当地选出该集合中的一个元素. 从集合中选择元素的规程不在本文档的范围之内. 让 ILM 把标签映射到包含多个 NHLFE 的集合, 可能在例如希望跨多条等价路径做负载均衡时有用.

3.12 FEC 到 NHLFE 映射 (FTN)​

"FEC 到 NHLFE" 映射 (FTN, FEC-to-NHLFE Map) 把每个 FEC 映射到一组 NHLFE. 它用于转发那些以未打标签形式到达, 但将在转发前被打上标签的分组.

如果 FTN 把某个 FEC 映射到包含多个元素的 NHLFE 集合, 那么在转发分组之前必须恰当地选出该集合中的一个元素. 从集合中选择元素的规程不在本文档的范围之内. 让 FTN 把 FEC 映射到包含多个 NHLFE 的集合, 可能在例如希望跨多条等价路径做负载均衡时有用.

3.13 标签交换 (Label Swapping)​

标签交换 (label swapping) 是指使用以下规程来转发分组.

为了转发带标签分组, LSR 检查标签栈顶的标签. 它使用 ILM 把该标签映射到一个 NHLFE. 利用 NHLFE 中的信息, 它确定把分组转发到哪里, 并对分组的标签栈执行一项操作. 然后它把新的标签栈编码进分组, 并转发结果.

为了转发未打标签的分组, LSR 分析网络层头部, 以确定分组的 FEC. 然后它使用 FTN 把该 FEC 映射到一个 NHLFE. 利用 NHLFE 中的信息, 它确定把分组转发到哪里, 并对分组的标签栈执行一项操作. (当然, 在这种情况下弹出标签栈是非法的.) 然后它把新的标签栈编码进分组, 并转发结果.

非常重要的一点是: 当使用标签交换时, 下一跳总是取自 NHLFE; 在某些情况下, 这可能与不使用 MPLS 时的下一跳不同.

3.14 标签的作用域与唯一性 (Scope and Uniqueness of Labels)​

给定的 LSR Rd 可以把标签 L1 绑定到 FEC F, 并把该绑定分发给标签分发对等体 Ru1. Rd 也可以把标签 L2 绑定到 FEC F, 并把该绑定分发给标签分发对等体 Ru2. L1 是否等于 L2 不由架构决定; 这是本地事务.

给定的 LSR Rd 可以把标签 L 绑定到 FEC F1, 并把该绑定分发给标签分发对等体 Ru1. Rd 也可以把标签 L 绑定到 FEC F2, 并把该绑定分发给标签分发对等体 Ru2. 当且仅当 RD 在收到顶层标签为 L 的分组时能够分辨该标签是 RU1 放上去的还是 RU2 放上去的, 架构才不要求 F1 == F2. 在这种情况下, 我们可以说 Rd 为分发到 Ru1 的标签使用了与分发到 Ru2 的标签不同的 "标签空间" (label space).

一般而言, 只有在以下条件成立时, Rd 才能分辨把特定标签值 L 放到标签栈顶的是 Ru1 还是 Ru2:

  • Ru1 与 Ru2 是 Rd 向其分发过标签值 L 绑定的仅有的两个标签分发对等体, 并且

  • Ru1 与 Ru2 各自通过点对点接口与 Rd 直接相连.

当这些条件成立时, LSR 可以使用具有 "每接口" (per interface) 作用域的标签, 即仅在每接口内唯一的标签. 我们可以说该 LSR 正在使用 "每接口标签空间" (per-interface label space). 当这些条件不成立时, 标签必须在分配它们的 LSR 范围内唯一, 我们可以说该 LSR 正在使用 "每平台标签空间" (per-platform label space).

如果特定 LSR Rd 通过两个点对点接口与特定 LSR Ru 相连, 那么 Rd 可以向 Ru 分发标签 L 到 FEC F1 的绑定, 以及标签 L 到 FEC F2 (F1 != F2) 的绑定, 当且仅当每个绑定仅对 Ru 经某一特定接口发往 Rd 的分组有效. 在所有其他情况下, Rd 禁止向 Ru 分发把同一标签值绑定到两个不同 FEC 的绑定.

这条禁令即使在绑定被视为处于不同 "层次级别" 时也成立. 在 MPLS 中, 不存在为不同层次级别使用不同标签空间的概念; 在解释一个标签时, 标签的层次级别无关紧要.

由此产生一个问题: LSR 是否可能使用多个每平台标签空间, 或者对同一接口使用多个每接口标签空间. 架构不禁止这一点. 然而, 在这种情况下, LSR 必须拥有某种架构未规定的手段, 来确定特定入标签属于哪个标签空间. 例如, [MPLS-SHIM] 规定单播分组与组播分组使用不同的标签空间, 并使用数据链路层代码点来区分这两个标签空间.

3.15 标签交换路径 (LSP), LSP 入口, LSP 出口 (Label Switched Path (LSP), LSP Ingress, LSP Egress)​

针对特定分组 P 的 "级别 m 的标签交换路径 (LSP)" 是一列路由器:

                               <R1, ..., Rn>

具有如下性质:

  1. R1 即 "LSP 入口" (LSP Ingress), 是一个把标签压入 P 的标签栈, 从而形成深度为 m 的标签栈的 LSR;

  2. 对所有 i (1<i<n), 当 P 被 LSR Ri 收到时, P 拥有深度为 m 的标签栈;

  3. 在 P 从 R1 传到 R[n-1] 的过程中, 其标签栈深度从不少于 m;

  4. 对所有 i (1<i<n): Ri 借助 MPLS 把 P 传给 R[i+1], 即使用标签栈顶的标签 (第 m 层标签) 作为 ILM 的索引;

  5. 对所有 i (1<i<n): 如果某个系统 S 在 P 被 Ri 发出之后、被 R[i+1] 收到之前接收并转发 P (例如 Ri 与 R[i+1] 可能经由一个交换式数据链路子网相连, 而 S 可能是其中的一个数据链路交换机), 那么 S 的转发决策既不基于第 m 层标签, 也不基于网络层头部. 这可能是因为:

    a) 该决策根本不基于标签栈或网络层头部;

    b) 该决策基于一个压入了额外标签的标签栈 (即基于第 m+k 层标签, 其中 k>0).

换言之, 我们可以把分组 P 的级别 m LSP 说成是这样一列路由器:

  1. 它始于一个压入第 m 层标签的 LSR ("LSP 入口"),

  2. 其所有中间 LSR 都通过对第 m 层标签的标签交换来做出转发决策,

  3. 当转发决策通过对第 m-k 层标签 (k>0) 的标签交换做出时, 或者当转发决策由 "普通" 的非 MPLS 转发规程做出时, 它结束 (于 "LSP 出口").

这样做的一个结果 (或许也是一个前提) 是: 每当 LSR 把标签压入一个已打标签的分组时, 它需要确保新标签对应的 FEC, 其 LSP 出口正是分配了现在位于栈中第二位标签的那个 LSR.

如果一列 LSR 在特定分组 P 的第 m 层标签是对应 FEC F 的标签时, 构成 P 的级别 m LSP, 我们就称这列 LSR 为 "特定 FEC F 的 LSP".

考虑可以作为 FEC F 的 LSP 入口节点的节点集合. 那么以这些节点中的每一个为起点, 都存在一条 FEC F 的 LSP. 如果这些 LSP 中有若干条拥有相同的 LSP 出口, 那么可以把这组 LSP 看成一棵树, 其根是 LSP 出口. (由于数据沿这棵树流向根, 可以称之为多点到点树.) 因此我们可以谈论特定 FEC F 的 "LSP 树".

3.16 次末跳弹出 (Penultimate Hop Popping)​

注意, 按照第 3.15 节的定义, 如果 <R1, ..., Rn> 是分组 P 的级别 m LSP, P 从 R[n-1] 传给 Rn 时标签栈深度可以是 m-1. 也就是说, 标签栈可以在 LSP 的次末 LSR 处弹出, 而不是在 LSP 出口处弹出.

从架构角度看, 这完全合理. 第 m 层标签的目的是把分组送到 Rn. 一旦 R[n-1] 决定把分组发给 Rn, 该标签就不再有任何功能, 也就无需再携带.

做次末跳弹出还有一个实际的好处. 如果不做次末跳弹出, 那么 LSP 出口收到分组时, 它首先查找栈顶标签, 并根据查找结果确定自己确实是 LSP 出口. 然后它必须弹出栈, 检查分组剩下的部分. 如果栈上还有另一个标签, 出口将查找该标签并基于此查找转发分组. (在这种情况下, 分组级别 m LSP 的出口同时也是其级别 m-1 LSP 的中间节点.) 如果栈上没有其他标签, 则分组按其网络层目的地址转发. 注意, 这将要求出口做两次查找: 要么两次标签查找, 要么一次标签查找加一次地址查找.

反过来, 如果使用次末跳弹出, 那么当次末跳查找标签时, 它会确定:

  • 自己是次末跳, 并且

  • 下一跳是谁.

次末节点随后弹出栈, 并基于查找原先位于栈顶的那个标签所获得的信息转发分组. 当 LSP 出口收到分组时, 此时位于栈顶的标签正是它做出自己的转发决策所需查找的标签. 或者, 如果分组原先只携带单个标签, LSP 出口将直接看到网络层分组, 这恰好是它做出转发决策所需看到的东西.

这种技术让出口只需一次查找, 同时也只要求次末节点做一次查找.

如果能够事先知道最多只需要一次查找, 那么在标签交换产品中构建转发 "快速路径" (fastpath) 将得到极大帮助:

  • 如果代码可以假定最多只需要一次查找, 代码可以得到简化

  • 代码可以基于假定最多只需要一次查找的 "时间预算" 来构建.

事实上, 当做了次末跳弹出时, LSP 出口甚至不必是 LSR.

然而, 某些硬件交换引擎可能无法弹出标签栈, 所以不能普遍强制要求这一点. 也可能存在一些次末跳弹出并不合意的情形. 因此, 只有当出口节点明确请求时, 或者当 LSP 中的下一个节点不支持 MPLS 时, 次末节点才弹出标签栈. (如果 LSP 中的下一个节点支持 MPLS 但没有提出这种请求, 次末节点无从得知自己实际上就是次末节点.)

凡是具备弹出标签栈能力的 LSR, 在其下游标签分发对等体提出请求时, 必须执行次末跳弹出.

初始的标签分发协议协商必须允许每个 LSR 确定其相邻 LSR 是否具备弹出标签栈的能力. LSR 禁止请求不具备该能力的标签分发对等体弹出标签栈.

有人可能会问: 如果使用次末跳弹出, 出口节点是否总能正确解释收到分组的栈顶标签. 只要遵守第 3.14 节的唯一性与作用域规则, 总是能够无歧义地解释收到分组的栈顶标签.

3.17 LSP 下一跳 (LSP Next Hop)​

特定 LSR 处特定带标签分组的 LSP 下一跳 (LSP Next Hop), 是为转发该分组所用的 NHLFE 表项所选出的下一跳 LSR.

特定 FEC 的 LSP 下一跳, 是由对应该 FEC 的标签所索引的 NHLFE 表项选出的下一跳.

注意, LSP 下一跳可能不同于网络层路由算法会选出的下一跳. 我们把后者称为 "L3 下一跳" (L3 next hop).

3.18 无效入标签 (Invalid Incoming Labels)​

如果 LSR 收到一个携带特定入标签的带标签分组, 但自己没有该标签的绑定, 应该怎么办? 人们很容易认为, 只需移除标签, 把分组当作未打标签的 IP 分组转发即可. 然而, 在某些情况下这样做可能导致环路. 如果上游 LSR 认为该标签绑定到一条显式路由, 而下游 LSR 认为该标签什么也没绑定, 并且该未打标签 IP 分组的逐跳路由把分组带回了上游 LSR, 那么就形成了环路.

标签原本要代表的还可能是一条无法从 IP 头推断出的路由.

因此, 当收到入标签无效的带标签分组时, 必须将其丢弃, 除非通过某种手段 (不在本文档范围之内) 确定把它作为未打标签分组转发不会造成任何危害.

3.19 LSP 控制: 有序与独立 (LSP Control: Ordered versus Independent)​

有些 FEC 对应于通过动态路由算法分发的地址前缀. 为这些 FEC 建立 LSP 可以用两种方式之一完成: 独立 LSP 控制 (Independent LSP Control) 或有序 LSP 控制 (Ordered LSP Control).

在独立 LSP 控制下, 每个 LSR 一旦识别出特定 FEC, 就独立地决定为该 FEC 绑定一个标签, 并把该绑定分发给它的标签分发对等体. 这对应于传统 IP 数据报路由的工作方式: 每个节点独立决定如何处理每个分组, 并依赖路由算法快速收敛, 以确保每个数据报被正确投递.

在有序 LSP 控制下, LSR 只有在自己是该 FEC 的出口 LSR, 或者已经从自己在该 FEC 上的下一跳收到该 FEC 的标签绑定时, 才为该 FEC 绑定标签.

如果想确保特定 FEC 中的流量沿着具有某组指定性质的路径走 (例如流量不两次经过任何节点, 为流量保留指定数量的资源, 流量沿显式指定的路径走等), 就必须使用有序控制. 在独立控制下, 某些 LSR 可能在 LSP 完全建立之前就开始对该 FEC 中的流量做标签交换, 因此该 FEC 中的某些流量可能走上不具备指定性质的路径. 如果对 FEC 的识别是相应 LSP 建立的结果, 也需要使用有序控制.

有序 LSP 建立可以由入口发起, 也可以由出口发起.

有序控制与独立控制完全可互操作. 然而, 除非 LSP 中的所有 LSR 都使用有序控制, 否则对网络行为的总体影响基本等同于独立控制, 因为无法确保 LSP 在完全建立之前不被使用.

本架构允许独立控制与有序控制之间的选择成为本地事务. 由于两种方法可以互通, 给定的 LSR 只需支持其中之一. 一般而言, 独立与有序控制的选择似乎对需要定义的标签分发机制没有任何影响.

3.20 聚合 (Aggregation)​

把流量划分成 FEC 的一种方法, 是为路由表中出现的每个地址前缀创建一个单独的 FEC. 然而, 在特定的 MPLS 域内, 这可能产生这样一组 FEC: 所有这些 FEC 中的所有流量都走同一条路由. 例如, 一组不同的地址前缀可能都拥有同一个出口节点, 标签交换可能仅用于把流量送到出口节点. 在这种情况下, 在该 MPLS 域内, 这些 FEC 的并集本身就是一个 FEC. 这就产生了一个选择: 是为每个分量 FEC 绑定一个单独的标签, 还是把单个标签绑定到并集, 并把该标签应用于并集中的所有流量?

把单个标签绑定到 (在某个域内) 自身构成 FEC 的 FEC 并集, 并把该标签应用于并集中的所有流量, 这一规程称为 "聚合" (aggregation). MPLS 架构允许聚合. 聚合可以减少处理特定分组集合所需的标签数量, 还可以减少所需的标签分发控制流量.

给定一组可 "聚合" 为单个 FEC 的 FEC, 可以 (a) 把它们聚合为单个 FEC, (b) 把它们聚合为一组 FEC, 或者 (c) 完全不聚合. 因此我们可以谈论聚合的 "粒度" (granularity), 其中 (a) 是 "最粗粒度", (c) 是 "最细粒度".

使用有序控制时, 对于给定的一组 FEC, 每个 LSR 应当采用其下一跳为这些 FEC 所使用的粒度.

使用独立控制时, 可能出现两个相邻 LSR Ru 与 Rd 对某组 FEC 采用不同聚合方式的情况.

如果 Ru 的粒度比 Rd 细, 这不会造成问题. Ru 为该组 FEC 分发的标签比 Rd 多. 这意味着当 Ru 需要把这些 FEC 中带标签的分组转发给 Rd 时, 它可能需要把 n 个标签映射为 m 个标签, 其中 n > m. 可选地, Ru 可以撤回它已分发的 n 个标签, 然后分发一组 m 个标签, 对应于 Rd 的粒度级别. 这样做并非确保正确运行所必需, 但它确实减少了 Ru 分发的标签数量, 而 Ru 分发较多标签也并没有带来任何特别的好处. 做与不做的决定是本地事务.

如果 Ru 的粒度比 Rd 粗 (即 Rd 为该组 FEC 分发了 n 个标签, 而 Ru 分发了 m 个, 其中 n > m), 它有两种选择:

  • 它可以采用 Rd 更细的粒度. 这将要求它撤回已分发的 m 个标签, 并分发 n 个标签. 这是首选方案.

  • 如果它能确定这样做会产生相同的路由, 它可以简单地把自己的 m 个标签映射为 Rd 的 n 个标签的一个子集. 例如, 假设 Ru 对所有需要经过某个特定出口 LSR 的流量应用单个标签, 而 Rd 依据分组的各个目的地址为这类流量绑定了若干不同的标签. 如果 Ru 知道出口路由器的地址, 并且 Rd 已把一个标签绑定到由该地址标识的 FEC, 那么 Ru 可以直接应用那个标签.

无论如何, 每个 LSR 都需要 (通过配置) 知道自己分配标签时使用的粒度. 使用有序控制时, 这只要求每个节点知道从该节点离开 MPLS 网络的那些 FEC 的粒度. 使用独立控制时, 确保所有 LSR 被一致地配置为知道每个 FEC 的粒度, 可能获得最佳效果. 然而, 在许多情况下, 这可以通过使用适用于所有 FEC 的单一粒度级别来完成 (例如 "转发表中每个 IP 前缀一个标签", 或 "每个出口节点一个标签").

3.21 路由选择 (Route Selection)​

路由选择 (route selection) 是指为特定 FEC 选择 LSP 的方法. 拟议的 MPLS 协议架构支持两种路由选择方案: (1) 逐跳路由, (2) 显式路由.

逐跳路由允许每个节点为每个 FEC 独立地选择下一跳. 这是当今现有 IP 网络中的常见模式. "逐跳路由的 LSP" 是指其路由通过逐跳路由选出的 LSP.

在显式路由的 LSP 中, 每个 LSR 不独立选择下一跳; 而是由单个 LSR (通常是 LSP 入口或 LSP 出口) 指定 LSP 中的若干 (或全部) LSR. 如果单个 LSR 指定了整个 LSP, 该 LSP 是 "严格" 显式路由的. 如果单个 LSR 只指定了 LSP 的一部分, 该 LSP 是 "松散" 显式路由的.

显式路由 LSP 所经过的 LSR 序列可以通过配置选定, 也可以由单个节点动态选择 (例如, 出口节点可以利用从链路状态数据库学到的拓扑信息, 计算以该出口节点为终点的整棵树的路径).

显式路由对多种目的都有用, 例如策略路由或流量工程. 在 MPLS 中, 显式路由需要在分配标签时指定, 但不必随每个 IP 分组指定. 这使得 MPLS 的显式路由比 IP 源路由这一替代方案高效得多.

使用显式路由 (无论严格还是松散) 的规程不在本文档的范围之内.

3.22 缺少出标签 (Lack of Outgoing Label)​

当带标签分组沿 LSP 行进时, 偶尔可能出现这样的情况: 它到达某个 LSR, 尽管入标签本身有效, 但该 LSR 的 ILM 并未把分组的入标签映射到任何 NHLFE. 这可能由瞬态条件引起, 也可能由本应是分组下一跳的那个 LSR 上的错误引起.

在这种情况下, 人们很容易想剥掉标签栈, 基于网络层头部尝试用常规转发继续转发该分组. 然而, 一般而言这并不安全:

  • 如果分组一直在沿显式路由的 LSP 行进, 这样做可能导致环路.

  • 分组的网络头部所含信息可能不足以让这个特定的 LSR 正确转发它.

除非能够 (通过本文档范围之外的某种手段) 确定上述两种情况都不存在, 否则唯一安全的规程就是丢弃该分组.

3.23 生存时间 (TTL)​

在常规 IP 转发中, 每个分组的头部都携带一个 "生存时间" (TTL) 值. 分组每经过一台路由器, 其 TTL 就减 1; 如果在分组到达目的地之前 TTL 减到 0, 分组就会被丢弃.

这为对抗可能因配置错误, 或路由算法故障或收敛缓慢而存在的转发环路提供了一定程度的保护. TTL 有时也用于其他功能, 例如组播范围界定, 以及支持 "traceroute" 命令. 这意味着 MPLS 需要处理两个与 TTL 相关的问题: (i) TTL 作为抑制环路的手段; (ii) TTL 作为完成其他功能 (例如限制分组的作用范围) 的手段.

当分组沿 LSP 行进时, 它浮现出来时的 TTL 值应当与它在未经标签交换的情况下穿越同一路由器序列时应有的 TTL 值相同. 如果分组沿 LSP 层次结构行进, 那么它从该层次结构中浮现出来时, 其 TTL 值应当反映出所穿越的 LSR 跳的总数.

TTL 的处理方式可能因 MPLS 标签值是承载在 MPLS 专用的 "垫片" (shim) 头部 [MPLS-SHIM] 中, 还是承载在 L2 头部 (例如 ATM 头部 [MPLS-ATM] 或帧中继头部 [MPLS-FRMRLY]) 中而有所不同.

如果标签值编码在位于数据链路层头部与网络层头部之间的 "垫片" 中, 那么该垫片必须有一个 TTL 字段, 该字段应当最初从网络层头部的 TTL 字段装入, 应当在每一 LSR 跳处递减, 并应当在分组从其 LSP 浮现时复制进网络层头部的 TTL 字段.

如果标签值编码在数据链路层头部中 (例如 ATM 的 AAL5 头部中的 VPI/VCI 字段), 且带标签分组由 L2 交换机 (例如 ATM 交换机) 转发, 而该数据链路层 (如 ATM) 自身没有 TTL 字段, 那么就不可能在每个 LSR 跳处递减分组的 TTL. 由一列无法递减分组 TTL 的 LSR 组成的 LSP 段将被称为 "非 TTL LSP 段" (non-TTL LSP segment).

不过, 当分组从非 TTL LSP 段中浮现出来时, 应当给它一个反映其所穿越 LSR 跳数的 TTL. 在单播情形下, 这可以通过向入口节点传播有效的 LSP 长度来实现, 使入口在把分组转发进非 TTL LSP 段之前先递减 TTL 值.

有时可以在进入非 TTL LSP 段时就断定: 特定分组的 TTL 会在分组到达该非 TTL LSP 段出口之前过期. 在这种情况下, 处于该非 TTL LSP 段入口的 LSR 禁止对该分组做标签交换. 这意味着必须开发特殊规程来支持 traceroute 功能, 例如, traceroute 分组可以用常规逐跳转发来转发.

3.24 环路控制 (Loop Control)​

在非 TTL LSP 段上, 根据定义, TTL 无法用于防范转发环路. 环路控制的重要性可能取决于在非 TTL LSP 段上提供 LSR 功能所使用的特定硬件.

举例来说, 假设使用 ATM 交换硬件来提供 MPLS 交换功能, 标签承载于 VPI/VCI 字段. 由于 ATM 交换硬件不能递减 TTL, 因此对环路没有任何防护. 如果 ATM 硬件能够为携带不同 VPI/VCI 值的入信元公平地分配缓冲池访问, 那么这种环路可能不会对其他流量产生任何有害影响. 但是, 如果 ATM 硬件不能提供这种公平的缓冲访问, 那么即使是瞬时的环路也可能导致 LSR 整体性能的严重劣化.

即便能够提供公平的缓冲访问, 拥有某种手段来检测 "持续得比可能的时间更长" 的环路仍然是有价值的. 此外, 即使 TTL 和/或每 VC 公平排队提供了在环路中存活的手段, 在可行的情况下避免建立会成环的 LSP 仍可能是可取的. 因此, 所有可能接入非 TTL LSP 段的 LSR 都将被要求支持一种公共的环路检测技术; 不过, 环路检测技术的使用是可选的. 环路检测技术规定于 [MPLS-ATM] 与 [MPLS-LDP].

3.25 标签编码 (Label Encodings)​

为了把标签栈连同标签栈所属的分组一起传输, 需要定义标签栈的一种具体编码. 架构支持若干不同的编码技术; 编码技术的选择取决于用于转发带标签分组的设备的特定种类.

3.25.1 MPLS 专用硬件和/或软件 (MPLS-specific Hardware and/or Software)​

如果使用 MPLS 专用的硬件和/或软件来转发带标签分组, 编码标签栈最显而易见的方式是定义一个新协议, 用作数据链路层头部与网络层头部之间的 "垫片" (shim). 这个垫片实际上只是网络层分组的一种封装; 它是 "协议无关" 的, 从而可以用来封装任何网络层. 因此我们把它称为 "通用 MPLS 封装" (generic MPLS encapsulation).

通用 MPLS 封装随后又被封装进数据链路层协议之中.

MPLS 通用封装规定于 [MPLS-SHIM].

3.25.2 把 ATM 交换机用作 LSR (ATM Switches as LSRs)​

可以注意到, MPLS 转发规程与传统的 "标签交换" 交换机 (例如 ATM 交换机) 的转发规程相似. ATM 交换机使用入端口和入 VPI/VCI 值作为 "交叉连接" 表的索引, 从中得到出端口和出 VPI/VCI 值. 因此, 如果一个或多个标签能够直接编码进这些传统交换机所访问的字段, 那么这些传统交换机在经过适当的软件升级之后就可以用作 LSR. 我们把这类设备称为 "ATM-LSR".

在 ATM 信元头部中编码标签有三种显而易见的方式 (假定使用 AAL5):

  1. SVC 编码 (SVC Encoding)

    用 VPI/VCI 字段编码位于标签栈顶的标签. 这种技术可用于任何网络. 采用这种编码技术时, 每条 LSP 都实现为一条 ATM SVC, 标签分发协议成为 ATM 的 "信令" 协议. 采用这种编码技术时, ATM-LSR 无法对标签栈执行 "压入" 或 "弹出" 操作.

  2. SVP 编码 (SVP Encoding)

    用 VPI 字段编码位于标签栈顶的标签, 用 VCI 字段编码栈中的第二个标签 (如果存在). 这种技术相对前一种有一些优势, 因为它允许使用 ATM 的 "VP 交换" (VP-switching). 也就是说, LSP 实现为 ATM SVP, 标签分发协议充当 ATM 信令协议.

    然而, 这种技术并不总是可用. 如果网络经由一个非 MPLS 的 ATM 网络包含一条 ATM 虚拟通路 (Virtual Path), 那么 VPI 字段就不一定可供 MPLS 使用.

    采用这种编码技术时, 位于 VP 出口的 ATM-LSR 实际上执行 "弹出" 操作.

  3. SVP 多点编码 (SVP Multipoint Encoding)

    用 VPI 字段编码位于标签栈顶的标签, 用 VCI 字段的一部分编码栈中的第二个标签 (如果存在), 并用 VCI 字段的其余部分标识 LSP 入口. 如果采用这种技术, 传统的 ATM VP 交换能力就可以用来提供多点到点 VP. 来自不同分组的信元将携带不同的 VCI 值. 正如我们将在第 3.26 节看到的, 这使我们能够在能够提供多点到点 VP 但不具备 VC 合并能力的 ATM 交换机上做标签合并, 而不会遇到任何信元交错问题.

    这项技术依赖于这样一种能力: 为每台 ATM 交换机分配 16 位 VCI 值, 使得没有任何单个 VCI 值被分配给两台不同的交换机. (如果能够为每台交换机分配足够数量的此类值, 那么也可以把 VCI 值当作栈中的第二个标签.)

如果栈上的标签数量超出了 ATM 头部所能编码的数量, 那么 ATM 编码必须与通用封装结合使用.

3.25.3 编码技术间的互通 (Interoperability among Encoding Techniques)​

如果 <R1, R2, R3> 是某条 LSP 的一段, 可能出现的情况是: R1 在向 R2 传输分组 P 时使用一种标签栈编码, 而 R2 在向 R3 传输分组 P 时使用另一种编码. 一般而言, MPLS 架构支持在不同跳上使用不同标签栈编码的 LSP. 因此, 当我们讨论处理带标签分组的规程时, 我们以抽象的方式谈论对分组标签栈的操作. 当收到一个带标签分组时, LSR 必须将其解码以确定标签栈的当前值, 然后对标签栈执行操作以确定栈的新值, 然后在把带标签分组传输给其下一跳之前恰当地编码新值.

遗憾的是, ATM 交换机不具备从一种编码技术转换到另一种的能力. 因此, MPLS 架构要求: 只要两台 ATM 交换机有可能沿某个分组的级别 m LSP 成为相继的 LSR, 那么这两台 ATM 交换机就必须使用相同的编码技术.

自然, 会出现同时包含用作 LSR 的 ATM 交换机和使用 MPLS 垫片头部的其他 LSR 的 MPLS 网络. 在这种网络中, 可能存在一些既拥有 ATM 接口又拥有 "MPLS Shim" 接口的 LSR. 这正是一个 LSR 在不同跳上拥有不同标签栈编码的例子. 这样的 LSR 可以在入接口上换掉 ATM 编码的标签栈, 而在出接口上代之以 MPLS 垫片头部编码的标签栈.

3.26 标签合并 (Label Merging)​

假设某个 LSR 已经把多个入标签绑定到特定 FEC. 在转发该 FEC 中的分组时, 人们希望有一个单一出标签, 应用于所有这样的分组. 该 FEC 中两个不同分组以不同入标签到达这一事实无关紧要; 人们希望用相同的出标签转发它们. 做到这一点的能力称为 "标签合并" (label merging).

如果一个 LSR 能够从不同的入接口和/或以不同的标签接收两个分组, 并把两个分组都从同一出接口以相同标签发出, 我们就说它具备标签合并能力. 一旦分组被发送, 它们来自不同接口和/或以不同入标签到达的信息就丢失了.

如果对从不同接口到达或以不同标签到达的任意两个分组, LSR 必须或者把它们从不同接口发出, 或者给它们打上不同的标签, 我们就说该 LSR 不具备标签合并能力. 使用 SVC 或 SVP 编码的 ATM-LSR 无法执行标签合并. 这将在下一节更详细讨论.

如果特定 LSR 不能执行标签合并, 那么当同一 FEC 中的两个分组以不同入标签到达时, 它们必须以不同出标签转发. 有标签合并时, 每 FEC 所需的出标签数量只需为 1; 没有标签合并时, 每 FEC 所需的出标签数量可能多达网络中的节点数.

有标签合并时, 特定 LSR 为每 FEC 所需的入标签数量绝不会超过标签分发邻接的数量. 没有标签合并时, 特定 LSR 为每 FEC 所需的入标签数量与向上游节点转发该 FEC 流量到该 LSR 的上游节点数量一样多. 事实上, LSR 甚至很难确定自己针对特定 FEC 必须支持多少个这样的入标签.

MPLS 架构同时容纳可合并与不可合并的 LSR, 但也考虑到了可能存在不支持标签合并的 LSR. 这带来了确保可合并 LSR 与不可合并 LSR 之间正确互操作的问题. 这个问题在数据报媒体的情况下与在 ATM 的情况下有所不同. 因此将对不同媒体类型分别讨论.

3.26.1 不可合并的 LSR (Non-merging LSRs)​

MPLS 转发规程与 ATM 和帧中继等技术使用的转发规程非常相似. 也就是说, 一个数据单元到达, 在 "交叉连接表" 中查找一个标签 (VPI/VCI 或 DLCI), 基于该查找选定一个输出端口, 并重写标签值. 事实上, 可以把这类技术用于 MPLS 转发; 标签分发协议可以用作建立交叉连接表的 "信令协议".

遗憾的是, 这些技术不一定支持标签合并能力. 在 ATM 中, 如果尝试执行标签合并, 结果可能是来自不同分组的信元相互交错. 如果来自不同分组的信元发生交错, 就无法重组分组. 一些帧中继交换机在背板上使用信元交换. 这些交换机也可能出于同样的原因无法支持标签合并 -- 不同分组的信元可能交错, 之后便无法重组分组.

我们提议针对这一问题支持两种解决方案. 首先, MPLS 将包含允许使用不可合并 LSR 的规程. 其次, MPLS 将支持使某些 ATM 交换机能够充当可合并 LSR 的规程.

由于 MPLS 同时支持可合并与不可合并的 LSR, MPLS 还包含确保它们之间正确互操作的规程.

3.26.2 可合并与不可合并 LSR 的标签 (Labels for Merging and Non-Merging LSRs)​

支持标签合并的上游 LSR, 每个 FEC 只需发给它一个标签. 不支持标签合并的上游邻居, 每个 FEC 需要发给它多个标签. 然而, 没有办法先验地知道它需要多少个标签. 这取决于相对于所讨论的 FEC, 它的上游有多少个 LSR.

在 MPLS 架构中, 如果某个特定的上游邻居不支持标签合并, 那么除非它为某个 FEC 显式索要标签, 否则不会向它发送该 FEC 的任何标签. 该上游邻居可以多次提出这种请求, 并且每次都会得到一个新标签. 当下游邻居收到来自上游的这种请求, 而该下游邻居自身也不支持标签合并时, 它必须转而向自己的下游邻居为所讨论的 FEC 再索取一个标签.

可能存在一些支持标签合并, 但只能把有限数量的入标签合并为单一出标签的节点. 举例来说, 假设由于某种硬件限制, 一个节点能够把四个入标签合并为一个出标签. 再假设该特定节点针对某个 FEC 有六个入标签到达. 在这种情况下, 该节点可以把它们合并为两个出标签.

标签合并是否适用于显式路由的 LSP, 有待进一步研究.

3.26.3 在 ATM 上合并 (Merge over ATM)​

3.26.3.1 消除信元交错的方法 (Methods of Eliminating Cell Interleave)​

有几种方法可以用来消除 ATM 中的信元交错问题, 从而让 ATM 交换机支持流合并:

  1. VP 合并, 采用 SVP 多点编码

    使用 VP 合并时, 多条虚拟路径被合并成一条虚拟路径, 但来自不同源的分组通过在该 VP 内使用不同的 VCI 来区分.

  2. VC 合并

    使用 VC 合并时, 要求交换机缓存来自某个分组的信元, 直到整个分组被接收完毕 (可以通过寻找 AAL5 帧结束指示来判断).

VP 合并的优点是与现有 ATM 交换机实现的兼容比例更高. 这使得 VP 合并更有可能用于现有网络. 与 VC 合并不同, VP 合并不会在合并点引入任何时延, 也不施加任何缓冲要求. 然而, 它的缺点是要求在每个 VP 内协调 VCI 空间. 做到这一点有多种方法. 选择其中一种或多种方法有待进一步研究.

这种 "与现有设备的兼容性" 与 "协议复杂度和可扩展性" 之间的权衡意味着, MPLS 协议最好同时支持 VP 合并与 VC 合并. 为此, 每台参与 MPLS 的 ATM 交换机都需要知道其直接 ATM 邻居执行的是 VP 合并, VC 合并, 还是不合并.

3.26.3.2 互通: VC 合并, VP 合并与不合并 (Interoperation: VC Merge, VP Merge, and Non-Merge)​

描述 ATM 上各种合并形式的互通, 最容易的方法是先描述 VC 合并与不合并之间的互通.

在 VC 合并节点与不合并节点互联的情况下, 信元的转发在所有情况下都基于一条 VC (即 VPI 与 VCI 的拼接). 对每个节点而言, 如果上游邻居在做 VC 合并, 那么该上游邻居针对特定流只需要一个 VPI/VCI (这类似于帧媒体环境下需要单个标签的要求). 如果上游邻居不做合并, 那么该邻居将需要为它自己每流一个 VPI/VCI, 外加足以传递给其上游邻居的 VPI/VCI. 所需数量通过允许上游节点从其下游邻居请求额外的 VPI/VCI 来确定 (这又与帧合并所用的方法类似).

类似的方法可以用来支持执行 VP 合并的节点. 在这种情况下, VP 合并节点不是向其下游邻居请求单个 VPI/VCI 或若干 VPI/VCI, 而是请求单个 VP (由一个 VPI 标识) 但该 VP 内的若干 VCI. 此外, 假设一个不合并节点位于两个不同的 VP 合并节点的下游. 该节点可能需要请求一个 VPI/VCI (用于自己发起的流量) 外加两条 VP (每个上游节点一条), 每条 VP 关联一个指定的 VCI 集合 (按上游节点的请求).

为了同时支持 VP 合并, VC 合并与不合并, 因此有必要允许上游节点请求以下组合: 零个或多个 VC 标识符 (由 VPI/VCI 组成), 加上零个或多个 VP (由 VPI 标识), 每个 VP 包含指定数量的 VC (由在 VP 内有效的 VCI 集合标识). 因此, VP 合并节点会请求一条 VP, 内含用于其自身发起流量 (如果适用) 的 VCI, 外加针对从上游请求的每个 VC 的一个 VCI (无论该 VC 是否属于某条包含它的 VP). VC 合并节点只请求单个 VPI/VCI (因为它们可以把所有上游流量合并进单个 VC). 不合并节点把从上游得到的任何请求向下传递, 外加为自己发起的流量请求一个 VPI/VCI (如果适用).

3.27 隧道与层次化 (Tunnels and Hierarchy)​

有时, 路由器 Ru 会采取显式动作, 使特定分组被投递给另一台路由器 Rd, 即便 Ru 与 Rd 并不是该分组逐跳路径上的相继路由器, 且 Rd 也不是该分组的最终目的地. 例如, 这可以通过把该分组封装进一个目的地址为 Rd 自身地址的网络层分组来实现. 这就创建了一条从 Ru 到 Rd 的 "隧道" (tunnel). 我们把任何这样处理的分组称为 "被隧道化的分组" (Tunneled Packet).

3.27.1 逐跳路由隧道 (Hop-by-Hop Routed Tunnel)​

如果被隧道化的分组沿着从 Ru 到 Rd 的逐跳路径行进, 我们就说它处于一条 "逐跳路由隧道" (Hop-by-Hop Routed Tunnel) 之中, 该隧道的 "发送端点" 是 Ru, "接收端点" 是 Rd.

3.27.2 显式路由隧道 (Explicitly Routed Tunnel)​

如果被隧道化的分组沿一条不同于逐跳路径的路径从 Ru 到 Rd, 我们就说它处于一条 "显式路由隧道" (Explicitly Routed Tunnel) 之中, 该隧道的 "发送端点" 是 Ru, "接收端点" 是 Rd. 例如, 我们可以通过把分组封装进一个源路由的分组, 使它穿过一条显式路由隧道.

3.27.3 LSP 隧道 (LSP Tunnels)​

可以把隧道实现为一条 LSP, 用标签交换而非网络层封装来使分组穿过隧道. 该隧道是一条 LSP <R1, ..., Rn>, 其中 R1 是隧道的发送端点, Rn 是隧道的接收端点. 这称为 "LSP 隧道" (LSP Tunnel).

要通过该 LSP 隧道发送的分组集合构成一个 FEC, 隧道中的每个 LSR 都必须为该 FEC 分配一个标签 (即必须为该隧道分配一个标签). 把特定分组归入某个 LSP 隧道的判据, 是隧道发送端点上的本地事务. 要把分组放入 LSP 隧道, 发送端点把该隧道的标签压入标签栈, 并把带标签分组发给隧道中的下一跳.

如前文所讨论, 如果隧道的接收端点无需能够区分它通过隧道收到的是哪些分组, 那么标签栈可以在隧道中倒数第二个 LSR 处弹出.

"逐跳路由 LSP 隧道" (Hop-by-Hop Routed LSP Tunnel) 是实现为发送端点与接收端点之间一条逐跳路由 LSP 的隧道.

"显式路由 LSP 隧道" (Explicitly Routed LSP Tunnel) 是同时也是显式路由 LSP 的 LSP 隧道.

3.27.4 层次化: LSP 内的 LSP 隧道 (Hierarchy: LSP Tunnels within LSPs)​

考虑一条 LSP <R1, R2, R3, R4>. 假设 R1 收到未打标签的分组 P, 并把使它沿这条路径行进的标签压入其标签栈, 而且这条路径实际上就是逐跳路径. 不过, 再假设 R2 与 R3 并不直接相连, 而是凭借作为一条 LSP 隧道的端点而互为 "邻居". 于是 P 实际穿越的 LSR 序列是 <R1, R2, R21, R22, R23, R3, R4>.

当 P 从 R1 行进到 R2 时, 它有一个深度为 1 的标签栈. R2 在做标签交换时判定 P 必须进入隧道. R2 首先把入标签替换为对 R3 有意义的标签. 然后它压入一个新标签. 这个第 2 层标签的值对 R21 有意义. R21, R22, R23 在第 2 层标签上做交换. R23 是 R2-R3 隧道的次末跳, 它在把分组转发给 R3 之前弹出标签栈. 当 R3 看到分组 P 时, P 只有一个第 1 层标签, 此时已经离开隧道. 由于 R3 是 P 的级别 1 LSP 的次末跳, 它弹出标签栈, R4 收到未打标签的 P.

标签栈机制允许 LSP 隧道嵌套到任意深度.

3.27.5 标签分发对等关系与层次化 (Label Distribution Peering and Hierarchy)​

假设分组 P 沿级别 1 LSP <R1, R2, R3, R4> 行进, 并且在从 R2 到 R3 时沿级别 2 LSP <R2, R21, R22, R3> 行进. 从级别 2 LSP 的角度看, R2 的标签分发对等体是 R21. 从级别 1 LSP 的角度看, R2 的标签分发对等体是 R1 和 R3. 在层次结构的每一层都可以有标签分发对等体. 我们将在第 4.6 和 4.7 节看到利用这种层次结构的一些方式. 注意, 在这个例子中, R2 与 R21 必须是 IGP 邻居, 但 R2 与 R3 不必是.

当两个 LSR 是 IGP 邻居时, 我们称它们为 "本地标签分发对等体" (local label distribution peers). 当两个 LSR 可以互为标签分发对等体但不是 IGP 邻居时, 我们称它们为 "远程标签分发对等体" (remote label distribution peers). 在上面的例子中, R2 与 R21 是本地标签分发对等体, 而 R2 与 R3 是远程标签分发对等体.

MPLS 架构支持在层次结构的不同层分发标签的两种方式: 显式对等 (Explicit Peering) 与隐式对等 (Implicit Peering).

与自己的本地标签分发对等体进行标签分发的方式, 是发送以该对等体为地址的标签分发协议消息. 与自己的远程标签分发对等体进行标签分发可以采用以下两种方式之一:

  1. 显式对等 (Explicit Peering)

    在显式对等中, 通过发送以对等体为地址的标签分发协议消息向对等体分发标签, 与对本地标签分发对等体的做法完全一样. 当远程标签分发对等体的数量较少, 或者更高层标签绑定的数量很大, 或者远程标签分发对等体位于不同的路由区域或域中时, 这种技术最为有用. 当然, 需要知道向哪个对等体分发哪些标签; 这在第 4.1.2 节中讨论.

    使用显式对等的例子见第 4.2.1 节和第 4.6 节.

  2. 隐式对等 (Implicit Peering)

    在隐式对等中, 不发送以对等体为地址的标签分发协议消息. 而是为了向远程标签分发对等体分发更高层的标签, 把高层标签编码为低层标签的一个属性, 然后把该低层标签连同这个属性一起分发给自己的本地标签分发对等体. 本地标签分发对等体随后把该信息传播给它们的本地标签分发对等体. 这一过程持续进行, 直到信息到达远程对等体.

    当远程标签分发对等体的数量很大时, 这种技术最为有用. 隐式对等不需要一个 n 方形的对等网格来向远程标签分发对等体分发标签, 因为信息搭载在本地标签分发对等关系之上传递. 然而, 隐式对等要求中间节点存储一些它们可能并不直接感兴趣的信息.

    使用隐式对等的例子见第 4.3 节.

3.28 标签分发协议传输 (Label Distribution Protocol Transport)​

标签分发协议用于 MPLS 网络中的节点之间, 以建立和维护标签绑定. 为了让 MPLS 正确运行, 标签分发信息需要可靠地传输, 并且与特定 FEC 相关的标签分发协议消息需要按序传输. 流量控制也是需要的, 在单个数据报中携带多条标签消息的能力同样如此.

满足这些目标的一种方法是使用 TCP 作为底层传输, 正如 [MPLS-LDP] 与 [MPLS-BGP] 中所做的那样.

3.29 为什么不止一种标签分发协议? (Why More than one Label Distribution Protocol?)​

本架构不为在何种情况下使用哪种标签分发协议制定硬性的规则. 不过, 可以指出一些需要考虑的因素.

3.29.1 BGP 与 LDP (BGP and LDP)​

在许多场景中, 期望把标签绑定到可以用通往地址前缀的路由标识的 FEC (见第 4.1 节). 如果存在一个标准的, 广泛部署的路由算法来分发这些路由, 那么可以说, 把标签分发搭载在路由本身的分发之上是实现标签分组的最佳途径.

例如, BGP 分发这类路由, 如果 BGP 发言者还需要向其 BGP 对等体分发标签, 那么用 BGP 来做标签分发 (见 [MPLS-BGP]) 有许多优势. 特别是, 它允许 BGP 路由反射器分发标签, 相比于用 LDP 在 BGP 对等体之间分发标签, 这提供了显著的可扩展性优势.

3.29.2 RSVP 流说明的标签 (Labels for RSVP Flowspecs)​

当 RSVP 被用于为特定流建立资源预留时, 期望给这些流中的分组打上标签, 使得 RSVP 过滤说明 (filterspec) 不需要在每一跳都应用. 可以认为, 让 RSVP 作为其路径/预留建立过程的一部分来分发标签, 是为此目的分发标签的最高效方法.

3.29.3 显式路由 LSP 的标签 (Labels for Explicitly Routed LSPs)​

在 MPLS 的某些应用中, 特别是与流量工程相关的应用中, 期望建立一条从入口到出口的显式路由路径, 同时也期望沿该路径应用资源预留.

可以设想两种途径:

  • 从一个现有的用于建立资源预留的协议出发, 扩展它以支持显式路由和标签分发.

  • 从一个现有的用于标签分发的协议出发, 扩展它以支持显式路由和资源预留.

第一种途径催生了 [MPLS-RSVP-TUNNELS] 规定的协议, 第二种途径催生了 [MPLS-CR-LDP] 规定的方案.

3.30 组播 (Multicast)​

本节有待进一步研究 (for further study).