跳到主要内容

2. Diff-Serv LSR 的标签转发模型与隧道模型

2.1. Diff-Serv LSR 的标签转发模型​

由于给定 FEC 的不同有序聚合可能在不同 LSP 上传输, Diff-Serv LSR 的标签交换决策显然取决于被转发分组的行为聚合. 此外, 由于被转发分组的 IP DS 字段对 LSR 可能不可直接可见, 确定将应用于接收分组的 PHB 以及将 PHB 编码到发送分组中的方式, 与非 MPLS Diff-Serv 路由器不同.

因此, 为描述 Diff-Serv LSR 的标签转发, 我们将 LSR Diff-Serv 标签交换行为建模为包含四个阶段:

  • 入向 PHB 判定 (Incoming PHB Determination) (A)

  • 可选流量调节下的出向 PHB 判定 (Outgoing PHB Determination with Optional Traffic Conditioning) (B)

  • 标签转发 (Label Forwarding) (C)

  • 将 Diff-Serv 信息编码到封装层 (EXP, CLP, DE, User_Priority) (D)

每个阶段在后续各节中更详细描述.

显然, 为强制实现 Diff-Serv 服务区分, LSR MUST 还应用与出向 PHB 相对应的转发处理.

该模型图示如下:

   --Inc_label(s)(*)------------------------>I===I--Outg_label(s)(&)-->
\ I I \
\---->I===I I C I \-->I===I--Encaps->
I A I I===I--Outg_PHB->I===I I D I (&)
-Encaps->I===I--Inc_PHB->I B I \ /->I===I
(*) I===I \--------+
\----Forwarding-->
Treatment
(PHB)

"Encaps" 指定在 MPLS 封装层中编码的与 Diff-Serv 相关的信息 (例如 EXP 字段, ATM CLP, Frame Relay DE, 802.1 User_Priority)

(*) 当 LSR 作为 MPLS 入口节点行为时, 入向分组可能以无标签方式接收.

(&) 当 LSR 作为 MPLS 出口节点行为时, 出向分组可能以无标签方式发送.

此处给出该模型是为描述 Diff-Serv LSR 的功能操作, 并不约束实际实现.

2.2. 入向 PHB 判定​

本阶段确定接收到的分组属于哪个行为聚合.

2.2.1. 考虑标签栈项的入向 PHB 判定​

第 3.3 与 4.3 节详细说明如何根据入向 LSP 类型以及入向 MPLS 封装, 在考虑给定接收标签栈项和/或接收到的入向 MPLS 封装信息时执行入向 PHB 判定.

第 2.6 节根据所支持的 Diff-Serv 隧道模式, 详细说明为入向 PHB 判定应考虑哪个标签栈项.

2.2.2. 考虑 IP 头的入向 PHB 判定​

第 2.6 节根据所支持的 Diff-Serv 隧道模型, 详细说明何时应将 IP 头用于入向 PHB 判定. 在需要使用 IP 头的情况下, 本阶段的操作与非 MPLS IP Diff-Serv 路由器完全相同, 并使用 DS 字段来确定入向 PHB.

2.3. 可选流量调节下的出向 PHB 判定​

流量调节阶段是可选的, 可在 LSR 上用于执行流量调节, 包括行为聚合的降级 (demotion) 或升级 (promotion). 其细节超出本规范范围. 为规定基于 MPLS 的 Diff-Serv 转发, 我们仅指出: LSR 实际将强制执行并传达给下游 LSR 的 PHB (称为 "出向 PHB"), 可能与前一 LSR 与该分组关联的 PHB (称为 "入向 PHB") 不同.

当不存在流量调节阶段时, "出向 PHB" 与 "入向 PHB" 完全相同.

2.4. 标签转发​

  • [MPLS_ARCH] 描述了 LSR 如何使用入向标签映射 (Incoming Label Map, ILM) 对入向带标签分组执行标签交换, 其中每个入向标签映射到一个或多个 NHLFE. [MPLS_ARCH] 还描述了 LSR 如何使用 FEC-to-NHLFEs Map (FTN) 对入向无标签分组执行标签压入 (imposition), 其中每个入向 FEC 映射到一个或多个 NHLFE.

标签的 Diff-Serv Context 由下列内容组成:

  • `LSP type (i.e., E-LSP or L-LSP)'

  • `supported PHBs'

  • 入向标签的 `Encaps-->PHB mapping'

  • 出向标签的 `Set of PHB-->Encaps mappings'

本规范定义: 在 ILM 中为每个入向标签存储 Diff-Serv Context.

  • [MPLS_ARCH] 指出 `NHLFE may also contain any other information needed in order to properly dispose of the packet'. 与此一致, 本规范定义: 对每个被交换或压入的出向标签, 在 NHLFE 中存储 Diff-Serv Context.

该 Diff-Serv Context 信息在标签建立时填充到 ILM 与 FTN 中.

如果标签对应于未在 LSP 建立时显式信令 EXP<-->PHB mapping' 的 E-LSP, 则 supported PHBs' 填充为预配置 `EXP<-->PHB mapping' 的 PHB 集合, 该映射在下文第 3.2.1 节讨论.

如果标签对应于在 LSP 建立时已显式信令 EXP<-->PHB mapping' 的 E-LSP, 则 supported PHBs' 填充为所信令 `EXP<-->PHB mapping' 的 PHB 集合.

如果标签对应于 L-LSP, 则 `supported PHBs' 填充为在 LSP 建立时信令的组成 PSC 的 PHB 集合.

Encaps-->PHB mapping' 或 Set of PHB-->Encaps mappings' 如何填充的细节在下文第 3 与 4 节定义.

  • [MPLS_ARCH] 还指出:

"If the ILM [respectively, FTN] maps a particular label to a set of NHLFEs that contain more than one element, exactly one element of the set must be chosen before the packet is forwarded. The procedures for choosing an element from the set are beyond the scope of this document. Having the ILM [respectively, FTN] map a label [respectively, a FEC] to a set containing more than one NHLFE may be useful if, e.g., it is desired to do load balancing over multiple equal-cost paths."

与此一致, 本规范允许: 为 Diff-Serv 目的, 一个入向标签 [相应地, FEC] 可映射到多个 NHLFE (例如, 不同 NHLFE 对应于支持不同 PHB 集合的出口标签). 当标签 [相应地, FEC] 映射到多个 NHLFE 时, Diff-Serv LSR MUST 选择其 Diff-Serv Context 表明支持该被转发分组出向 PHB 的 NHLFE 之一.

当标签 [相应地, FEC] 映射到多个支持出向 PHB 的 NHLFE 时, 在这些 NHLFE 中选择其一的规程超出本文档范围. 在希望将行为聚合在多条 LSP 上负载均衡时, 可能遇到此情况. 在此类情况下, 为遵守排序约束, 给定微流的所有分组 MUST 在同一 LSP 上传输.

2.5. 将 Diff-Serv 信息编码到封装层​

本阶段确定如何对发送分组中传达 Diff-Serv 信息的字段进行编码 (例如 MPLS Shim EXP, ATM CLP, Frame Relay DE, 802.1 User_Priority).

2.5.1. 将 Diff-Serv 信息编码到发送的标签项​

第 3.5 与 4.5 节详细说明如何根据对应的出向 LSP 类型以及 MPLS 封装, 将 Diff-Serv 信息编码到给定发送标签栈项和/或发送的 MPLS 封装信息中.

第 2.6 节根据所支持的 Diff-Serv 隧道模式, 详细说明应在哪个标签栈项中执行 Diff-Serv 信息编码.

2.5.2. 将 Diff-Serv 信息编码到发送的 IP 头​

为将 Diff-Serv 信息编码到发送分组的 IP 头中, 本阶段的操作与非 MPLS IP Diff-Serv 路由器完全相同, 并将出向 PHB 的 DSCP 编码到 DS 字段中.

第 2.6 节根据所支持的 Diff-Serv 隧道模式, 详细说明何时应将 Diff-Serv 信息编码到发送的 IP 头中.

2.6. 基于 MPLS 的 Diff-Serv 隧道模型​

2.6.1. Diff-Serv 隧道模型​

  • [DIFF_TUNNEL] 考虑了差分服务与各种形式 IP 隧道的交互. MPLS LSP 不是 "IP 隧道" 的一种形式, 因为 MPLS 封装头不包含 IP 头, 因此 [DIFF_TUNNEL] 未考虑 MPLS LSP. 然而, 尽管不是 "IP 隧道" 的一种形式, MPLS LSP 是一种 "隧道" 形式.

从 Diff-Serv 角度看, LSP 与 IP 隧道共享若干共同特征:

  • 中间节点 (即位于 LSP 跨度某处的节点) 仅看到并操作 "外层" Diff-Serv 信息.

  • LSP 是单向的.

  • "外层" Diff-Serv 信息可在任一中间节点被修改.

然而, 从 Diff-Serv 角度看, 与 IP 隧道相比, LSP 也有一个显著特性:

  • 一般不存在与 IP 隧道中使用的倒数第二跳弹出 (Penultimate Hop Popping, PHP) 相类似的行为. 此外, PHP 会导致与 LSP 关联的 "外层" Diff-Serv 信息对 LSP 出口不可见. 在该信息在 LSP 出口无意义的情况下, 这显然完全不成问题. 在该信息在 LSP 出口有意义的情况下, 则必须以某种其他方式携带.

  • [DIFF_TUNNEL] 中为基于 IP 隧道的 Diff-Serv 隧道定义的两个概念模型, 对基于 MPLS 的 Diff-Serv 也适用且有用, 但其各自的详细操作在 MPLS 上有所不同. 这两个模型是管道模型 (Pipe Model) 与统一模型 (Uniform Model). 它们在 MPLS 上的操作在后续各节规定. 替代隧道模型的讨论与定义超出本规范范围.

2.6.2. 管道模型​

在管道模型中, 从 Diff-Serv 角度看, MPLS 隧道 (即 LSP) 用于对位于 LSP 入口与出口之间的中间 MPLS 节点进行隐藏.

在此模型中, 被隧道传输的分组必须传达两份有意义的 Diff-Serv 信息:

  • 对沿 LSP 跨度 (包括 LSP 出口) 的中间节点有意义的 Diff-Serv 信息 (我们称之为 "LSP Diff-Serv Information"). 该 LSP Diff-Serv Information 在 LSP 出口之外无意义: 无论 LSP 跨度上中间节点的流量调节是否影响 LSP Diff-Serv 信息, 该更新后的 Diff-Serv 信息在 LSP 出口之外都不被视为有意义, 并被忽略.

  • 在 LSP 出口之外有意义的 Diff-Serv 信息 (我们称之为 "Tunneled Diff-Serv Information" ). 该信息由 LSP 入口传达给 LSP 出口. 该 Diff-Serv 信息对 LSP 跨度上的中间节点无意义.

无 PHP 时管道模型的操作图示如下:

            ========== LSP =============================>

---Swap--(M)--...--Swap--(M)--Swap----
/ (outer header) \
(M) (M)
/ \
>--(m)-Push.................(m).....................Pop--(m)-->
I (inner header) E (M*)

(M) represents the "LSP Diff-Serv information" (m) represents the "Tunneled Diff-Serv information" (*) The LSP Egress considers the LSP Diff-Serv information received in the outer header (i.e., before the pop) in order to apply its Diff-Serv forwarding treatment (i.e., actual PHB) I represents the LSP ingress node E represents the LSP egress node

在管道模型中, "LSP Diff-Serv Information" 需要被传达给 LSP 出口, 以便其据此应用转发处理. " Tunneled Diff-Serv information" 也需要被传达给 LSP 出口, 以便其可进一步向下游传达.

由于两者都要求将 Diff-Serv 信息传达给 LSP 出口, 管道模型仅在无 PHP 时操作.

管道模型尤其适用于下列环境:

  • LSP 入口入接口上游云与 LSP 出口出接口下游云处于使用同一套 Diff-Serv 服务供给策略与 PHB 定义的 Diff-Serv 域中, 而该 LSP 跨越使用不同 Diff-Serv 服务供给策略与 PHB 定义的一个 (或多个) Diff-Serv 域

  • LSP 出口的出接口位于该 LSP 所跨越的 (最后一个) Diff-Serv 域中.

作为示例, 考虑服务提供商提供 MPLS VPN 服务 (MPLS VPN 架构示例见 [MPLS_VPN]) 并包含 Diff-Serv 区分的情况. 假设一组站点通过此类 MPLS VPN 服务互联. 再假设该组站点在统一管理下, 也支持 Diff-Serv 服务区分. 如果 VPN 站点管理与服务提供商不共享完全相同的 Diff-Serv 策略 (例如不支持相同数量的 PHB), 则在 MPLS VPN 服务上以管道模型操作 Diff-Serv, 将允许 VPN 站点的 Diff-Serv 策略在整个入口 VPN 站点与出口 VPN 站点中一致地操作, 并在服务提供商 Diff-Serv 域上透明地操作. 将此类 LSP 视为通过使其端点在虚拟上相邻 (尽管它们可能被中间网络节点在物理上分隔) 从而将端点处的 Diff-Serv 域链接成单一 Diff-Serv 区域, 可能是有用的.

管道模型 MUST 被支持.

为在给定无 PHP 的 LSP 上支持管道模型, LSR 按下列方式执行入向 PHB 判定与 Diff-Serv 信息编码:

  • 当接收无标签分组时, LSR 考虑接收到的 IP 头执行入向 PHB 判定.

  • 当接收带标签分组时, LSR 考虑接收标签栈中的外层标签项执行入向 PHB 判定. 特别地, 当要对所考虑的 LSP 执行 pop 操作时, LSR 在 pop 之前执行入向 PHB 判定.

  • 当对所考虑的 LSP 执行 push 操作时, LSR:

    • 在与被压入标签对应的发送标签项中, 编码与 OUTGOING PHB 相对应的 Diff-Serv 信息.

    • 在被封装的头 (被交换的标签项或 IP 头) 中, 编码与 INCOMING PHB 相对应的 Diff-Serv 信息.

  • 当对所考虑的 LSP 仅执行 swap 操作时, LSR 在包含被交换标签的发送标签项中编码 Diff-Serv 信息.

  • 当对所考虑的 LSP 执行 pop 操作时, LSR 不对因 pop 操作而暴露的头执行 Diff-Serv 信息编码 (即 LSR 使暴露的头 "保持原样").

2.6.2.1. 短管道模型​

短管道模型是上述管道模型的可选变体. 唯一区别在于: 在短管道模型中, 在 LSP 出口处应用的 Diff-Serv 转发处理基于 " Tunneled Diff-Serv Information" (即在被封装头中传达的 Diff-Serv 信息), 而不是基于 "LSP Diff-Serv information" (即在封装头中传达的 Diff-Serv 信息).

无 PHP 时短管道模型的操作图示如下:

            ========== LSP =============================>

---Swap--(M)--...--Swap--(M)--Swap----
/ (outer header) \
(M) (M)
/ \
>--(m)-Push.................(m).....................Pop--(m)-->
I (inner header) E

(M) represents the "LSP Diff-Serv information" (m) represents the "Tunneled Diff-Serv information" I represents the LSP ingress node E represents the LSP egress node

由于 LSP 出口基于 "Tunneled Diff-Serv Information" 应用其转发处理, 倒数第二节点不需要将 "LSP Diff-Serv information" 传达给 LSP 出口. 因此短管道模型也可与 PHP 一起操作.

有 PHP 时短管道模型的操作图示如下:

           =========== LSP ============================>

---Swap--(M)--...--Swap------
/ (outer header) \
(M) (M)
/ \
>--(m)-Push.................(m).............Pop-(m)--E--(m)-->
I (inner header) P (M*)

(M) represents the "LSP Diff-Serv information" (m) represents the "Tunneled Diff-Serv information" (*) The Penultimate LSR considers the LSP Diff-Serv information received in the outer header (i.e., before the pop) in order to apply its Diff-Serv forwarding treatment (i.e., actual PHB) I represents the LSP ingress node P represents the LSP penultimate node E represents the LSP egress node

短管道模型尤其适用于下列环境:

  • LSP 入口入接口上游云与 LSP 出口出接口下游云处于使用同一套 Diff-Serv 服务供给策略与 PHB 定义的 Diff-Serv 域中, 而该 LSP 跨越使用不同 Diff-Serv 服务供给策略与 PHB 定义的一个 (或多个) Diff-Serv 域

  • LSP 出口的出接口与其下游云处于同一 Diff-Serv 域中.

由于 LSP 出口的每个出接口都可能与其下游云处于同一 Diff-Serv 域, 每个出接口都可能潜在地处于不同 Diff-Serv 域中, 且 LSP 出口需要被配置为知晓每个对应的 Diff-Serv 策略. 在某些情况下, 各自的下游 Diff-Serv 策略比在 LSP 跨度上使用的公共 Diff-Serv 策略更适合在每个出口接口上提供服务区分, 此时这种运营开销是合理的. 此类情况的一个例子是: 服务提供商提供 MPLS VPN 服务, 且某些 VPN 用户请求应用其自己的 VPN Diff-Serv 策略来控制从 LSP 出口到目的 VPN 站点的专用链路上的服务区分, 而不是服务提供商的 Diff-Serv 策略.

短管道模型 MAY 被支持.

为在给定无 PHP 的 LSP 上支持短管道模型, LSR 以与管道模型相同的方式执行入向 PHB 判定与 Diff-Serv 信息编码, 但有下列例外:

  • 当接收带标签分组时, LSR 考虑用于实际转发的头 (标签项或 IP 头) 执行入向 PHB 判定. 特别地, 当要对所考虑的 LSP 执行 pop 操作时, LSR 在 pop 之后执行入向 PHB 判定.

为在给定有 PHP 的 LSP 上支持短管道模型, LSR 以与无 PHP 时相同的方式执行入向 PHB 判定与 Diff-Serv 信息编码, 但有下列例外:

  • 倒数第二 LSR 考虑接收标签栈中的外层标签项执行入向 PHB 判定. 换句话说, 当要对所考虑的 LSP 执行 pop 操作时, 倒数第二 LSR 在 pop 之前执行入向 PHB 判定.

注意, 有 PHP 的短管道模式下倒数第二 LSR 的行为, 与管道模式 (必然无 PHP) 下 LSP 出口的行为相同.

2.6.3. 统一模型​

在统一模型中, 从 Diff-Serv 角度看, MPLS 隧道 (即 LSP) 被视为端到端路径的附属物. MPLS 隧道可用于转发目的, 但对 Diff-Serv 没有显著影响. 在此模型中, 任何分组都恰好包含一份有意义的 Diff-Serv 信息, 且始终编码在最外层标签项中 (或在 IP 分组以无标签方式发送时编码在 IP DSCP 中, 例如在 LSP 出口). 编码在其他位置 (例如更深层标签项中) 的任何 Diff-Serv 信息对中间节点或隧道出口都无意义, 并被忽略. 如果 LSP 跨度上中间节点的流量调节影响 "外层" Diff-Serv 信息, 则更新后的 Diff-Serv 信息是在 LSP 出口被认为有意义的那份信息.

无 PHP 时统一模型的操作图示如下:

             ========== LSP =============================>

---Swap--(M)--...-Swap--(M)--Swap----
/ (outer header) \
(M) (M)
/ \
>--(M)--Push...............(x).......................Pop--(M)->
I (inner header) E

(M) represents the Meaningful Diff-Serv information encoded in the corresponding header. (x) represents non-meaningful Diff-Serv information. I represents the LSP ingress node E represents the LSP egress node

有 PHP 时统一模型的操作图示如下:

             ========== LSP =========================>

---Swap-(M)-...-Swap------
/ (outer header) \
(M) (M)
/ \
>--(M)--Push..............(x)............Pop-(M)--E--(M)->
I (inner header) P

(M) represents the Meaningful Diff-Serv information encoded in the corresponding header. (x) represents non-meaningful Diff-Serv information. I represents the LSP ingress node P represents the LSP penultimate node E represents the LSP egress node

基于 MPLS 的 Diff-Serv 统一模型使得从 Diff-Serv 角度看, 其操作与不使用 MPLS 时的操作完全相同. 换句话说, 对 Diff-Serv 操作而言, MPLS 是完全透明的.

使用统一模型允许 LSP 跨越 Diff-Serv 域边界, 而无需采取除 Diff-Serv 域之间物理边界处的域间流量调节协定之外的其他措施, 并且该协定仅对外层头操作, 因为有意义的 Diff-Serv 信息始终在最外层标签项中可见且可修改.

统一模型 MAY 被支持.

为在给定 LSP 上支持统一模型, LSR 按下列方式执行入向 PHB 判定与 Diff-Serv 信息编码:

  • 当接收无标签分组时, LSR 考虑接收到的 IP 头执行入向 PHB 判定.

  • 当接收带标签分组时, LSR 考虑接收标签栈中的外层标签项执行入向 PHB 判定. 特别地, 当要对所考虑的 LSP 执行 pop 操作时, LSR 在 pop 之前执行入向 PHB 判定.

  • 当对所考虑的 LSP 执行 push 操作时, LSR 在与被压入标签对应的发送标签项中编码 Diff-Serv 信息. 被封装头 (被交换的标签项或 IP 头) 中编码的 Diff-Serv 信息并不重要.

  • 当对所考虑的 LSP 仅执行 swap 操作时, LSR 在包含被交换标签的发送标签项中编码 Diff-Serv 信息.

  • 当使用 PHP 时, 倒数第二 LSR 需要知晓与暴露头对应标签的 "Set of PHB-->Encaps mappings" (或 `PHB-->DSCP mapping'), 以便执行 Diff-Serv 信息编码. 提供该映射感知的方法超出本规范范围. 例如, "PHB-->DSCP mapping" 可本地配置. 作为另一示例, 在某些环境中, 倒数第二 LSR 可假定对暴露头中出向标签使用的 " Set of PHB-->Encaps mappings", 就是若该 LSR 不执行 PHP 时将使用的 "Set of PHB-->Encaps mappings". 另请注意, 本规范假定倒数第二 LSR 不对 pop 操作暴露的标签项执行标签交换 (事实上甚至不查看暴露的标签). 因此, 对倒数第二 LSR 可执行的 Diff-Serv 信息编码可能有限制. 例如, 本规范不允许这样的情况: 倒数第二 LSR 弹出对应于支持两个 PSC 的 E-LSP 的标签, 而 pop 所暴露的头包含分别支持一个 PSC 的两条 L-LSP 的标签值, 因为 Diff-Serv 信息编码将需要选择其中一个标签或另一个.

注意, 管道, 短管道与统一模型的 LSR 行为仅在执行 push 或 pop 时不同. 因此, 对 LSP 仅执行 swap 操作的中间 LSR, 无论其行为是管道, 短管道还是统一模型, 都以完全相同的方式行为. 在支持多种隧道模型的 Diff-Serv 实现中, 只有作为 LSP 入口, 倒数第二 LSR 或 LSP 出口行为的 LSR 需要被配置为按特定模型操作. 在每条 LSP 基础上关联 Diff-Serv 隧道模型的信令不在本规范范围内.

2.6.4. 层次结构​

通过标签栈机制, MPLS 允许 LSP 隧道嵌套到任意深度. 我们观察到, 在此类嵌套中, N+1 级的 push 发生在执行 N 级 push 的 LSR 的后续 (或同一) LSR 上, 而 N+1 级的 pop 发生在执行 N 级 pop 的 LSR 的前一 (或同一) LSR 上. 对于给定的 N 级 LSP, 执行 push 的入口 LSR 与执行 pop 的 LSR (倒数第二 LSR 或 LSP 出口) 必须按同一隧道模型 (即管道, 短管道或统一) 操作. 然而, 不要求跨级别的隧道模型一致, 从而不同级别的 LSP 可按不同隧道模型操作.

在两级隧道情况下的层次操作图示如下:

               +--------Swap--...---+
/ (outmost header) \
/ \
Push(2).................(2)Pop
/ (outer header) \
/ \
>>---Push(1)........................(1)Pop-->>
(inner header)

(1) Tunneling Model 1 (2) Tunneling Model 2

隧道模型 2 可与隧道模型 1 相同, 也可不同.

对于给定的 N 级 LSP, LSR 必须根据该 N 级 LSP 的隧道模型, 并独立于其他级别 LSP 的隧道模型, 按第 2.6.2, 2.6.2.1 与 2.6.3 节的规定执行入向 PHB 判定与 Diff-Serv 信息编码.