RFC 6388 - LDP 扩展: 点对多点与多点对多点标签交换路径

Internet Engineering Task Force (IETF)                 IJ. Wijnands, Ed.
Request for Comments: 6388                           Cisco Systems, Inc.
Category: Standards Track                                  I. Minei, Ed.
ISSN: 2070-1721                                              K. Kompella
                                                        Juniper Networks
                                                               B. Thomas
                                                           November 2011


               Label Distribution Protocol Extensions for
 Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths

摘要 (Abstract)

本文档描述了对标签分发协议 (LDP) 的扩展, 用于在 MPLS 网络中建立点对多点 (P2MP) 与多点对多点 (MP2MP) 标签交换路径 (LSP). 这些扩展也称为多点 LDP (multipoint LDP). 多点 LDP 构造 P2MP 或 MP2MP LSP 时, 不与其他任何组播树构造协议交互, 也不依赖它们. 本方案用于以接收方发起 (receiver-initiated) 的方式建立此类 LSP 的协议元素与规程在本文档中给出. 多点 LSP 可以有多种应用, 例如 IP 组播, 或者对 BGP/MPLS 三层虚拟专用网 (L3VPN) 中组播的支持. 此类应用如何使用 LDP 信令的多点 LSP, 不在本文档的范围之内.

本文档状态 (Status of This Memo)

这是一份互联网标准跟踪文档.

本文档是互联网工程任务组 (IETF) 的成果. 它代表了 IETF 社区的共识. 它已经过公开评审, 并由互联网工程指导组 (IESG) 批准发布. 有关互联网标准的更多信息见 RFC 5741 第 2 节.

有关本文档当前状态, 任何勘误以及如何提供反馈的信息, 可在 http://www.rfc-editor.org/info/rfc6388 获取.

版权声明 (Copyright Notice)

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

本文档受 BCP 78 以及发布时有效的 IETF 信托关于 IETF 文档的法律条款 (http://trustee.ietf.org/license-info) 的约束. 请仔细审阅这些文档, 它们描述了您对本文档的权利与限制. 从本文档中提取的代码组件必须包含信托法律条款第 4.e 节所述的简化 BSD 许可证文本, 并且按简化 BSD 许可证的描述不提供任何保证.

本文档可能包含 2008 年 11 月 10 日之前发布或公开提供的 IETF 文档或 IETF 贡献中的材料. 控制此类材料版权的人可能未授予 IETF 信托允许在 IETF 标准流程之外修改此类材料的权利. 在未从控制此类材料版权的人处获得足够许可的情况下, 本文档不得在 IETF 标准流程之外修改, 也不得在 IETF 标准流程之外创建其衍生作品, 除非是为了将其排版为 RFC 出版, 或者将其翻译为英语以外的语言.

目录 (Table of Contents)

• 1. 引言
• 2. 使用 LDP 建立 P2MP LSP
• 3. 使用 LDP 建立 MP2MP LSP
• 4. MP LSP 中的微环路
• 5. LDP MP Status TLV
• 6. LAN 上的上游标签分配
• 7. 根节点冗余
• 8. 先建后断 (MBB)
• 9. mLDP FEC Element 的 Typed Wildcard
• 10. 安全考虑
• 11. IANA 考虑
• 12. 致谢
• 13. 贡献作者
• 14. 参考文献

1. 引言

LDP 协议在 [RFC5036] 中描述. 它定义了在网络中建立点对点 (P2P) 和多点对点 (MP2P) LSP 的机制. 本文档描述了对 LDP 的扩展, 用于建立点对多点 (P2MP) 和多点对多点 (MP2MP) LSP. 这两者统称为多点 LSP (MP LSP). P2MP LSP 允许来自单个根 (root, 或入口 ingress) 节点的流量被送达多个叶 (leaf, 或出口 egress) 节点. MP2MP LSP 允许来自多个入口节点的流量被送达多个出口节点. 经过该 MP LSP 的每一个 LDP 邻居, 分组只会向其发送一份副本. 这一切无需在网络中使用组播协议即可完成. 以给定入口节点为根可以存在多个 MP LSP, 每个都有自己的标识符.

该方案假定 MP LSP 的叶节点知道自己所属 MP LSP 的根节点和标识符. 分发这些信息的机制不在本文档的范围之内. 应用程序如何使用由 LDP 信令的 MP LSP, 其规范同样不在本文档的范围之内.

可能引起兴趣的相关文档包括 [RFC6348], [L3VPN-MCAST] 和 [RFC4875].

1.1 本文档中的约定 (Conventions Used in This Document)

本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" 和 "OPTIONAL" 按 RFC 2119 [RFC2119] 所述进行解释.

本文档中所有标为 "reserved" (保留) 的新字段, 发送时必须置为零, 接收时必须忽略.

1.2 术语 (Terminology)

下列术语中的一部分取自 [RFC6348].

mLDP: LDP 的多点扩展.

P2P LSP: 拥有一个入口 LSR 和一个出口 LSR 的 LSP.

P2MP LSP: 拥有一个入口 LSR 和一个或多个出口 LSR 的 LSP.

MP2P LSP: 拥有一个或多个入口 LSR 和唯一一个出口 LSR 的 LSP.

MP2MP LSP: 拥有一个可区分的根节点并连接一组节点的 LSP, 使得 LSP 中任意节点发送的流量都被送达所有其他节点.

MP LSP: 多点 LSP, 即 P2MP 或 MP2MP LSP.

入口 LSR (Ingress LSR): 对于特定 LSP 而言, 入口 LSR 是能够沿该 LSP 发送数据分组的 LSR. MP2MP LSP 可以有多个入口 LSR; P2MP LSP 只有一个, 该节点通常被称为 "根节点".

出口 LSR (Egress LSR): 对于特定 LSP 而言, 出口 LSR 是能够把数据分组从该 LSP 中取出以做进一步处理的 LSR. P2P 和 MP2P LSP 只有一个出口节点, 但 P2MP 和 MP2MP LSP 可以有多个出口节点.

中间 LSR (Transit LSR): 通过一个直连的上游 LSR 到达 MP LSP 根节点, 且有一个或多个直连下游 LSR 的 LSR.

分叉 LSR (Bud LSR): 既是出口, 又有一个或多个直连下游 LSR 的 LSR.

叶节点 (Leaf node): 在 P2MP LSP 的语境下, 叶节点可以是出口 LSR 或分叉 LSR. 在 MP2MP LSP 的语境下, 叶节点既是同一 MP2MP LSP 的入口也是出口, 并且还可以是分叉 LSR.

CRC32: 包含对未压缩数据按网络字节序计算的循环冗余校验值, 依照 ISO 3309 标准 [ISO3309] 以及 ITU-T 建议 V.42 第 8.1.1.6.2 节 [ITU.V42.1994] 中使用的 CRC-32 算法计算.

FEC: 转发等价类 (Forwarding Equivalence Class).

1.3 可管理性 (Manageability)

MPLS LSR 可以使用 [RFC3813] 定义的 MIB 模块进行建模和管理. 该 MIB 模块完全能够处理支持 P2MP LSP 所需的入段 (in-segment) 到出段 (out-segment) 的一对多关系, 无需进一步的改动.

[RFC3815] 为 LDP 定义了被管对象. 该 MIB 模块允许按 [RFC5036] 所定义的协议对 LDP 和 LDP 发言者进行建模和管理. 本文档为在 LDP 中支持 P2MP 而定义的协议扩展可能需要额外的 MIB 模块, 或者需要对 [RFC3815] 定义的模块进行扩展. 这有待未来研究, 且在撰写本文时, 尚未有人表示对这项工作的兴趣.

未来的可管理性工作应当关注本文档定义的协议扩展, 特别是其中可配置和可变的元素, 以及报告标识各个 P2MP LSP 的新协议字段.

2. 使用 LDP 建立 P2MP LSP (Setting Up P2MP LSPs with LDP)

P2MP LSP 由单个根节点, 零个或多个中间节点以及一个或多个叶节点组成. 叶节点发起 P2MP LSP 的建立与拆除. 叶节点还安装转发状态, 以便把在 P2MP LSP 上收到的流量送到它需要去的地方; 具体如何完成不在本文档的范围之内. 中间节点安装 MPLS 转发状态, 并把 P2MP LSP 的建立 (和拆除) 向根的方向传播. 根节点安装转发状态, 把流量映射进 P2MP LSP; 根节点如何确定哪些流量应当经过该 P2MP LSP, 不在本文档的范围之内.

2.1 对使用 LDP 建立 P2MP LSP 的支持 (Support for P2MP LSP Setup with LDP)

对建立 P2MP LSP 的支持使用 [RFC5561] 定义的 LDP 能力 (capabilities) 来通告. 支持本文档所规定的 P2MP 规程的实现必须实现 Initialization 消息中能力参数 (Capability Parameters) 的规程.

定义了一个新的能力参数 TLV, 即 P2MP 能力 (P2MP Capability). 以下是 P2MP 能力参数的格式.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0| P2MP Capability (0x0508)  |      Length (= 1)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S| Reserved    |
      +-+-+-+-+-+-+-+-+

S: 按 [RFC5561] 的规定.

P2MP 能力 TLV 必须在 LDP Initialization 消息中通告. 通告 P2MP 能力表示支持本文档中详述的 P2MP LSP 建立规程. 如果对端没有通告相应的能力, 则不应向该对端发送使用 P2MP FEC Element 的标签消息.

2.2 P2MP FEC Element (The P2MP FEC Element)

为了用 LDP 建立 P2MP LSP, 我们定义一个新的协议实体, 即 P2MP FEC Element, 用作 FEC TLV 中的一个 FEC Element. 注意, P2MP FEC Element 不一定标识必须映射到该 LSP 的流量, 因此从这个角度看, 使用 FEC 这个术语是一种误称. P2MP FEC Element 的描述如下.

P2MP FEC Element 由 P2MP LSP 根节点的地址和一个不透明值 (opaque value) 组成. 不透明值由一个或多个 LDP MP 不透明值元素组成. 不透明值在根节点的上下文中是唯一的. (根节点地址类型, 根节点地址, 不透明值) 的组合在 MPLS 网络中唯一地标识一个 P2MP LSP.

P2MP FEC Element 编码如下:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |P2MP Type(0x06)|        Address Family         | Address Length|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                       Root Node Address                       ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Opaque Length              |    Opaque Value ...           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      ~                                                               ~
      |                                                               |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: P2MP FEC Element 的类型为 0x06.

Address Family: 两字节量, 包含 IANA "Address Family Numbers" 注册表中的一个值, 用于编码根 LSR 地址的地址族.

Address Length: 根 LSR 地址的长度, 以八位组计.

Root Node Address: 按 Address Family 字段编码的主机地址.

Opaque Length: 不透明值的长度, 以八位组计.

Opaque Value: 一个或多个 MP 不透明值元素, 在根节点的上下文中唯一地标识该 P2MP LSP. 这在下一节描述.

如果 Address Family 为 IPv4, 则 Address Length 必须为 4; 如果 Address Family 为 IPv6, 则 Address Length 必须为 16. 目前没有定义其他地址长度.

如果 Address Length 与 Address Family 定义的长度不符, 接收方应当中止处理包含该 FEC Element 的消息, 并向其 LDP 对端发送 "Unknown FEC" Notification 消息以指示错误.

如果一个 FEC TLV 包含 P2MP FEC Element, 则 P2MP FEC Element 必须是该 FEC TLV 中唯一的 FEC Element.

2.3 LDP MP 不透明值元素 (The LDP MP Opaque Value Element)

LDP MP 不透明值元素用于后文定义的 P2MP 与 MP2MP FEC Element 中. 它携带对入口 LSR 和叶 LSR 有意义的信息, 但不需要被中间 LSR 解释.

LDP MP 不透明值元素的基本类型 (basic type) 编码如下:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Type < 255    | Length                        | Value ...     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
      ~                                                               ~
      |                                                               |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: LDP MP 不透明值元素的类型. IANA 维护基本类型注册表 (见第 11 节).

Length: Value 字段的长度, 以八位组计.

Value: 长度为 Length 八位组的字符串, 按 Type 字段的规定解释.

LDP MP 不透明值元素的扩展类型 (extended type) 编码如下:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Type = 255    |        Extended Type          | Length (high) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
      | Length (low)  |                Value                          |
      +-+-+-+-+-+-+-+-+                                               |
      ~                                                               ~
      |                                                               |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: Type = 255.

Extended Type: LDP MP 不透明值元素的扩展类型. IANA 维护扩展类型注册表 (见第 11 节).

Length: Value 字段的长度, 以八位组计.

Value: 长度为 Length 八位组的字符串, 按 Type 字段的规定解释.

2.3.1 通用 LSP 标识符 (The Generic LSP Identifier)

通用 LSP 标识符是不透明值元素的一种基本类型, 编码如下:

Type: 1

Length: 4

Value: 一个 32 位整数, 在以根节点地址标识的根的上下文中唯一.

当流量到 LSP 的映射是非算法式的, 并且是通过 LDP 之外的方式完成时, 推荐使用这种类型的不透明值元素.

2.4 使用 P2MP FEC Element (Using the P2MP FEC Element)

本节定义处理和传播 P2MP FEC Element 的规则. 处理规则中使用如下记法:

1. P2MP FEC Element <X, Y>: 根节点地址为 X, 不透明值为 Y 的 FEC Element.

2. P2MP Label Mapping <X, Y, L>: 一条 Label Mapping 消息, 其 FEC TLV 中只有一个 P2MP FEC Element <X, Y>, 其 Label TLV 中的标签为 L. 标签 L 必须从发送该 Label Mapping 消息的 LSR 的每平台标签空间 (per-platform label space, 见 [RFC3031] 第 3.14 节) 中分配. 接口标签空间的使用不在本文档的范围之内.

3. P2MP Label Withdraw <X, Y, L>: 一条 Label Withdraw 消息, 其 FEC TLV 中只有一个 P2MP FEC Element <X, Y>, 其 Label TLV 中的标签为 L.

4. P2MP LSP <X, Y> (或简写为 <X, Y>): 根节点地址为 X, 不透明值为 Y 的 P2MP LSP.

5. 记法 L' -> {<I1, L1> <I2, L2> ..., <In, Ln>} 作用于 LSR X 上, 表示: 当 X 收到一个标签为 L' 的分组时, X 为该分组制作 n 份副本; 对于第 i 份副本, X 把 L' 换成 Li, 并从接口 Ii 发送出去.

下述规程按照节点在 P2MP LSP 中扮演的角色来组织. 节点 Z 通过一个不在本文档范围之内的发现过程得知自己是叶节点. 在协议运行过程中, 根节点认识到自己的角色, 因为它拥有根节点地址. 中间节点是除根节点之外, 收到 P2MP Label Mapping 消息 (即其下游有叶节点) 的任何节点.

注意, 中间节点 (实际上还有根节点) 也可能同时是叶节点.

2.4.1 Label Mapping (标签映射)

本节其余部分给出产生 P2MP Label Mapping 消息, 以及处理针对特定 LSP 收到的 P2MP Label Mapping 消息的规程. 特定 LSR 的规程取决于该 LSR 在 LSP 中扮演的角色 (入口, 中间或出口).

本文讨论的所有标签都是下游分配的 [RFC5332], 使用第 6 节规程分配的标签除外.

2.4.1.1 确定自己的 "上游 LSR"

作为 MP LSP 的叶或中间 LSR 的每个节点, 都需要使用下述规程来选择一个上游 LSR. 想要加入 MP LSP <X, Y> 的节点 Z, 确定 LDP 对端 U: U 是 Z 在从 Z 到根节点 X 的最佳路径上的下一跳. 如果存在多个这样的 LDP 对端, 则只挑选其中一个. U 就是 Z 相对于 <X, Y> 的 "上游 LSR".

当存在多个候选上游 LSR 时, LSR 必须选择其中一个上游 LSR. 用于 LSR 选择的算法是本地事务. 如果 LSR 选择是在 LAN 接口上进行的, 并且应用了第 6 节的规程, 那么应当应用下述规程, 以确保在该 LAN 上的一组候选接收方之中选举出相同的上游 LSR.

1. 把候选上游 LSR 按 IP 地址从低到高编号.

2. 执行如下哈希: H = (CRC32(Opaque Value)) modulo N, 其中 N 是上游 LSR 的数量. "Opaque Value" 是 FEC Element 中紧跟 "Opaque Length" 之后的字段. "Opaque Length" 指示本次计算所用不透明值的大小.

3. 选出的上游 LSR U 就是编号为 H 的 LSR.

这一规程将确保在 LAN 上, 对于特定 LSP 只有一个转发者.

2.4.1.2 确定通往某个 LSR 的转发接口

假设 LSR U 收到来自下游 LSR D 的 MP Label Mapping 消息, 其中指定了标签 L. 再假设 U 与 D 之间通过多个启用了 LDP 的接口或 RSVP-TE 隧道接口相连. 如果 U 需要向 D 发送一个顶层标签为 L 的数据分组, U 可以从这些接口中任选一个发送. 它为特定分组选择特定接口和下一跳所用的算法是本地事务. 为完整起见, 可以使用下述规程. LSR U 可以在单播路由表中查找, 以找到到达 LSR D 的最佳接口和下一跳. 如果该下一跳和接口也是 LSR D 通过 LDP 会话通告的, 就可以用它把分组发送给 LSR D.

2.4.1.3 叶节点操作 (Leaf Operation)

P2MP LSP <X, Y> 的叶节点 Z 按第 2.4.1.1 节确定自己相对于 <X, Y> 的上游 LSR U, 分配标签 L, 并向 U 发送 P2MP Label Mapping <X, Y, L>.

2.4.1.4 中间节点操作 (Transit Node Operation)

假设中间节点 Z 收到来自 LSR T 的 P2MP Label Mapping <X, Y, L>. Z 检查自己是否已有 <X, Y> 的状态. 如果没有, Z 按第 2.4.1.1 节确定自己相对于 <X, Y> 的上游 LSR U. 只要 LSR T 等于 LSR U, 就禁止用该 Label Mapping 更新标签转发表. 如果 LSR U 与 LSR T 不同, Z 将分配标签 L', 安装状态: 在与 LSR T 相关联的接口 I 上把 L' 换成 L, 并向 LSR U 发送 P2MP Label Mapping <X, Y, L'>. 接口 I 通过第 2.4.1.2 节的规程确定.

如果 Z 已有 <X, Y> 的状态, 则 Z 不为 P2MP LSP <X, Y> 发送 Label Mapping 消息. 如果 LSR T 不是 <X, Y> 的上游 LSR, 且 <I, L> 尚不存在于转发状态中, 则更新转发状态. 假设其旧转发状态为 L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, 则其新转发状态变为 L'-> {<I1, L1> <I2, L2> ..., <In, Ln>, <I, L>}. 如果 LSR T 等于已安装的上游 LSR, 则必须保留来自 LSR T 的 Label Mapping, 并且禁止用它更新标签转发表.

2.4.1.5 根节点操作 (Root Node Operation)

假设根节点 Z 收到来自 LSR T 的 P2MP Label Mapping <X, Y, L>. Z 检查自己是否已有 <X, Y> 的转发状态. 如果没有, Z 创建转发状态, 把标签 L 压入 Z 希望经该 P2MP LSP 转发的流量 (这些流量如何确定不在本文档的范围之内).

如果 Z 已有 <X, Y> 的转发状态, 则 Z 向下一跳添加 "压入标签 L, 从接口 I 发送", 其中 I 是与 LSR T 相关联的接口, 通过第 2.4.1.2 节的规程确定.

2.4.2 Label Withdraw (标签撤销)

本节列出参与 P2MP LSP 的节点产生和处理 P2MP Label Withdraw 消息的规程. LSR 应当根据自己的角色, 应用那些适用于自己的规程.

2.4.2.1 叶节点操作 (Leaf Operation)

如果叶节点 Z 发现自己在该 LSP 中没有下游邻居, 并且不需要为该 LSP 充当出口 LSR (通过不在本文档范围之内的手段得知), 那么它应当向自己相对于 <X, Y> 的上游 LSR U 发送 Label Withdraw <X, Y, L>, 其中 L 是它先前向 U 通告的, 用于 <X, Y> 的标签.

2.4.2.2 中间节点操作 (Transit Node Operation)

如果中间节点 Z 收到来自节点 W 的 Label Withdraw 消息 <X, Y, L>, 它从自己的转发状态中删除标签 L, 并向 W 发送携带标签 L 的 Label Release 消息.

如果从 Z 的转发状态中删除 <X, Y> 的标签 L 之后, <X, Y> 不再有任何状态, 那么 Z 通过向自己的上游 T 发送 Label Withdraw <X, Y, L1> 来传播 <X, Y> 的 Label Withdraw, 其中 L1 是 Z 先前向 T 通告的, 用于 <X, Y> 的标签.

2.4.2.3 根节点操作 (Root Node Operation)

当 P2MP LSP 的根节点收到 Label Withdraw 消息时, 规程与中间节点相同, 只是它不会向上游传播 Label Withdraw (因为它没有上游).

2.4.3 上游 LSR 变更 (Upstream LSR Change)

假设参与 P2MP LSP <X, Y> 的某个节点 Z, 按第 2.4.1.1 节其上游 LSR 从 U 变为 U'. Z 必须按如下方式更新其转发状态. 它为 <X, Y> 分配一个新标签 L'. L' 的转发状态从 L 的转发状态复制而来, 有一个例外: 如果 U' 已存在于 L 的转发状态中, 则禁止把它安装进 L' 的转发状态. 然后删除 L 的转发状态, 安装 L' 的转发状态. 此外, Z 必须向 U' 发送 Label Mapping <X, Y, L'>, 并向 U 发送 Label Withdraw <X, Y, L>. 注意, 如果存在来自 U 的下游映射, 但因第 2.4.1.4 节定义的规程而未被安装进转发状态, 现在可以安装它了.

在变更上游 LSR 时, 必须考虑以下几点. 如果在移除 L 之前添加 L', 存在分组重复和/或产生瞬时数据平面转发环路的风险. 如果在添加 L' 之前移除 L, 可能导致分组丢失. 理想情况下, 从 L 到 L' 的变更应当原子地完成, 使得既不发生分组丢失也不发生分组重复. 如果做不到, 推荐的默认行为是在添加 L' 之前先移除 L.

3. 使用 LDP 建立 MP2MP LSP (Setting up MP2MP LSPs with LDP)

MP2MP LSP 与 P2MP LSP 非常相似: 它由单个根节点, 零个或多个中间节点以及一个或多个叶 LSR 组成, 叶 LSR 平等地充当入口或出口 LSR. 叶节点通过同时建立一条下游 LSP 和一条上游 LSP 来参与 MP2MP LSP 的建立: 下游 LSP 与从根出发的 P2MP LSP 非常相似; 上游 LSP 用于把流量发往根节点和其他叶节点. 中间节点通过把上游和下游 LSP 的建立向根的方向传播, 并安装必要的 MPLS 转发状态来支持建立. 从 MP2MP LSP 根节点向接收方传输分组的方式与 P2MP LSP 完全相同. 来自下游节点的流量沿上游 LSP 走向根节点, 并按需要沿下游 LSP 向下分支, 以到达其他叶节点. 从某个下游节点收到的分组, 绝不允许再被转发回那个节点. 把流量映射到 MP2MP LSP 可以发生在任何叶节点. 该映射如何建立不在本文档的范围之内.

由于 MP2MP LSP 的构建方式, 正在 MP2MP LSP 上发送分组的叶 LSR 不会收到自己的分组. 根 LSR 或中间 LSR 也无需任何额外机制来把上游流量与下游转发状态匹配起来. 如果没有应用 [RFC5331] 的规程, 经 MP2MP LSP 转发的分组不会穿越同一条链路超过一次, LAN 链路可能是例外 (见第 3.3.1 节).

3.1 对使用 LDP 建立 MP2MP LSP 的支持 (Support for MP2MP LSP Setup with LDP)

对建立 MP2MP LSP 的支持使用 [RFC5561] 定义的 LDP 能力来通告. 支持本文档所规定的 MP2MP 规程的实现必须实现 Initialization 消息中能力参数的规程.

定义了一个新的能力参数 TLV, 即 MP2MP 能力 (MP2MP Capability). 以下是 MP2MP 能力参数的格式.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0| MP2MP Capability (0x0509) |      Length (= 1)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S| Reserved    |
      +-+-+-+-+-+-+-+-+

S: 按 [RFC5561] 的规定.

MP2MP 能力 TLV 必须在 LDP Initialization 消息中通告. 通告 MP2MP 能力表示支持本文档中详述的 MP2MP LSP 建立规程. 如果对端没有通告相应的能力, 则不应向该对端发送使用 MP2MP 上游和下游 FEC Element 的标签消息.

3.2 MP2MP 下游与上游 FEC Element (The MP2MP Downstream and Upstream FEC Elements)

为了用 LDP 建立 MP2MP LSP, 我们定义两个新的协议实体: MP2MP 下游 FEC 与上游 FEC Element. 两者都用作 FEC TLV 中的 FEC Element. 注意, MP2MP FEC Element 不一定标识必须映射到该 LSP 的流量, 因此从这个角度看, 使用 FEC 这个术语是一种误称. MP2MP FEC Element 的描述如下.

MP2MP 下游与上游 FEC Element 的结构, 编码和错误处理与第 2.2 节描述的 P2MP FEC Element 相同. 区别在于使用了两个新的 FEC 类型: MP2MP 下游类型 (0x08) 和 MP2MP 上游类型 (0x07).

如果一个 FEC TLV 包含 MP2MP FEC Element, 则 MP2MP FEC Element 必须是该 FEC TLV 中唯一的 FEC Element.

注意, 除使用 [RFC5331] 规程的情形之外, 所使用的 MPLS 标签都是 "下游分配" 的 [RFC5332], 即便它们绑定在 "上游 FEC Element" 上也是如此.

3.3 使用 MP2MP FEC Element (Using the MP2MP FEC Elements)

本节定义处理和传播 MP2MP FEC Element 的规则. 处理规则中使用如下记法:

1. MP2MP 下游 LSP <X, Y> (或简写为 downstream <X, Y>): 根节点地址为 X, 不透明值为 Y 的 MP2MP LSP 下游路径.

2. MP2MP 上游 LSP <X, Y, D> (或简写为 upstream <X, Y, D>): 针对下游节点 D, 根节点地址为 X, 不透明值为 Y 的 MP2MP LSP 上游路径.

3. MP2MP 下游 FEC Element <X, Y>: 根节点地址为 X, 不透明值为 Y, 用于下游 MP2MP LSP 的 FEC Element.

4. MP2MP 上游 FEC Element <X, Y>: 根节点地址为 X, 不透明值为 Y, 用于上游 MP2MP LSP 的 FEC Element.

5. MP2MP-D Label Mapping <X, Y, L>: 一条 Label Mapping 消息, 其 FEC TLV 中只有一个 MP2MP 下游 FEC Element <X, Y>, 其标签 TLV 中的标签为 L. 标签 L 必须从发送该 Label Mapping 消息的 LSR 的每平台标签空间 (见 [RFC3031] 第 3.14 节) 中分配. 接口标签空间的使用不在本文档的范围之内.

6. MP2MP-U Label Mapping <X, Y, Lu>: 一条 Label Mapping 消息, 其 FEC TLV 中只有一个 MP2MP 上游 FEC Element <X, Y>, 其标签 TLV 中的标签为 Lu. 标签 Lu 必须从发送该 Label Mapping 消息的 LSR 的每平台标签空间 (见 [RFC3031] 第 3.14 节) 中分配. 接口标签空间的使用不在本文档的范围之内.

7. MP2MP-D Label Withdraw <X, Y, L>: 一条 Label Withdraw 消息, 其 FEC TLV 中只有一个 MP2MP 下游 FEC Element <X, Y>, 其标签 TLV 中的标签为 L.

8. MP2MP-U Label Withdraw <X, Y, Lu>: 一条 Label Withdraw 消息, 其 FEC TLV 中只有一个 MP2MP 上游 FEC Element <X, Y>, 其标签 TLV 中的标签为 Lu.

9. MP2MP-D Label Release <X, Y, L>: 一条 Label Release 消息, 其 FEC TLV 中只有一个 MP2MP 下游 FEC Element <X, Y>, 其标签 TLV 中的标签为 L.

10. MP2MP-U Label Release <X, Y, Lu>: 一条 Label Release 消息, 其 FEC TLV 中只有一个 MP2MP 上游 FEC Element <X, Y>, 其标签 TLV 中的标签为 Lu.

下述规程按照节点在 MP2MP LSP 中扮演的角色来组织. 节点 Z 通过一个不在本文档范围之内的发现过程得知自己是叶节点. 在协议运行过程中, 根节点认识到自己的角色, 因为它拥有根节点地址. 中间节点是除根节点之外, 收到 MP2MP Label Mapping 消息 (即其下游有叶节点) 的任何节点.

注意, 中间节点 (实际上还有根节点) 也可能同时是叶节点, 并且根节点不必是 MP2MP LSP 的入口 LSR 或叶节点.

3.3.1 MP2MP Label Mapping (MP2MP 标签映射)

本节其余部分给出产生 MP2MP Label Mapping 消息, 以及处理针对特定 LSP 收到的 MP2MP Label Mapping 消息的规程. 特定 LSR 的规程取决于该 LSR 在 LSP 中扮演的角色 (入口, 中间或出口).

本文讨论的所有标签都是下游分配的 [RFC5332], 使用第 6 节规程分配的标签除外.

3.3.1.1 确定自己的上游 MP2MP LSR

为 MP2MP LSP <X, Y> 确定上游 LDP 对端 U, 遵循第 2.4.1.1 节为 P2MP LSP 描述的规程.

3.3.1.2 确定自己的下游 MP2MP LSR

从 LDP 对端 D 收到 MP2MP-D Label Mapping 的 LDP 对端 U, 会把 D 视为下游 MP2MP LSR.

3.3.1.3 安装 MP2MP LSP 的上游路径

有两种方法可以把 MP2MP LSP 的上游路径安装到下游邻居.

1. 我们可以基于从下游邻居收到 MP2MP-D Label Mapping 来安装 (通往该下游邻居的) 上游 MP2MP 路径. 这将按逐跳方式安装上游路径.

2. 我们可以基于从上游邻居收到 MP2MP-U Label Mapping 来安装 (通往下游邻居的) 上游 MP2MP 路径. 如果 LSR 是 MP2MP LSP 的根, 或者它已经从上游邻居收到过 MP2MP-U Label Mapping, 则它无需等待该 MP2MP-U Label Mapping. 我们把这种方法称为有序模式 (ordered mode). 这种模式的典型结果是: MP2MP 的下游路径逐跳向根的方向建立. 一旦到达根, 根节点就会触发向下游邻居发送 MP2MP-U Label Mapping.

为建立 MP2MP LSP 的上游路径, 应当使用有序模式. 由于有序模式, MP2MP LSP 的上游路径会在通往根的路径完成之后才安装在叶节点上. 这样做的好处是: 当叶节点在上游路径安装完成后立即开始发送时, 分组能够到达根节点, 而不会因 LSP 不完整而被丢弃. 方法 1 无法保证在叶节点开始发送之前上游路径已经完成.

3.3.1.4 MP2MP 叶节点操作 (MP2MP Leaf Node Operation)

MP2MP LSP <X, Y> 的叶节点 Z 按第 3.3.1.1 节确定自己相对于 <X, Y> 的上游 LSR U, 分配标签 L, 并向 U 发送 MP2MP-D Label Mapping <X, Y, L>.

叶节点 Z 期望节点 U 以一条 MP2MP-U Label Mapping <X, Y, Lu> 作为对它发送给 U 的 MP2MP-D Label Mapping 的响应. Z 检查自己是否已有 upstream <X, Y> 的转发状态. 如果没有, Z 创建转发状态, 把标签 Lu 压入 Z 希望经该 MP2MP LSP 转发的流量. 它如何确定在该 MP2MP LSP 上转发哪些流量, 不在本文档的范围之内.

3.3.1.5 MP2MP 中间节点操作 (MP2MP Transit Node Operation)

假设节点 Z 收到来自 LSR D 的 MP2MP-D Label Mapping <X, Y, L>. Z 检查自己是否有 downstream <X, Y> 的转发状态. 如果没有, Z 按第 3.3.1.1 节确定自己相对于 <X, Y> 的上游 LSR U. 只要 LSR D 等于 LSR U, 就禁止用该 Label Mapping 更新标签转发表. 如果 LSR U 与 LSR D 不同, Z 将分配标签 L', 安装下游转发状态: 在与 LSR D 相关联的接口 I 上把标签 L' 换成标签 L, 并向 U 发送 MP2MP-D Label Mapping <X, Y, L'>. 接口 I 通过第 2.4.1.2 节的规程确定.

如果 Z 已有 downstream <X, Y> 的转发状态, 那么这种情况下 Z 所需做的只是检查 LSR D 不等于 <X, Y> 的上游 LSR, 并更新其转发状态. 假设其旧转发状态为 L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, 则其新转发状态变为 L'-> {<I1, L1> <I2, L2> ..., <In, Ln>, <I, L>}. 如果 LSR D 等于已安装的上游 LSR, 则必须保留来自 LSR D 的 Label Mapping, 并且禁止用它更新标签转发表.

节点 Z 检查上游 LSR U 是否已为 <X, Y> 分配了标签 Lu. 如果没有, 中间节点 Z 等待, 直到它从 LSR U 收到 MP2MP-U Label Mapping <X, Y, Lu> (见第 3.3.1.3 节). 一旦从 LSR U 收到 MP2MP-U Label Mapping, 节点 Z 检查自己是否已有 upstream <X, Y, D> 的转发状态. 如果有, 则无需进一步动作. 如果没有, 它分配标签 Lu', 并创建一个新的标签交换: 在接口 Iu 上把 Lu' 与 Lu 交换. 接口 Iu 通过第 2.4.1.2 节的规程确定. 此外, 它还把 downstream <X, Y> 转发状态中的标签交换加入进来, 但省略针对节点 D 的接口 I 上的交换. 省略针对节点 D 的接口 I 上的交换, 是为了防止 D 发出的分组被转发回 D.

节点 Z 按第 3.3.1.2 节确定下游 MP2MP LSR, 并向节点 D 发送 MP2MP-U Label Mapping <X, Y, Lu'>.

3.3.1.6 MP2MP 根节点操作 (MP2MP Root Node Operation)

3.3.1.6.1 根节点同时也是叶节点 (Root Node Is Also a Leaf)

假设根/叶节点 Z 收到来自节点 D 的 MP2MP-D Label Mapping <X, Y, L>. Z 检查自己是否已有 downstream <X, Y> 的转发状态. 如果没有, Z 创建下游转发状态, 把标签 L 压入 Z 希望沿该 MP2MP LSP 向下转发的流量. 它如何确定在该 MP2MP LSP 上转发哪些流量, 不在本文档的范围之内. 如果 Z 已有 downstream <X, Y> 的转发状态, 则 Z 会把 "经接口 I 压入标签 L" 加入其中. 接口 I 通过第 2.4.1.2 节的规程确定.

节点 Z 检查自己是否有 upstream <X, Y, D> 的转发状态. 如果没有, Z 分配标签 Lu', 并创建上游转发状态: 用 Lu' 与 downstream <X, Y> 转发状态中的标签交换相交换, 但针对节点 D 的接口 I 上的交换除外. 这使得上游流量能够沿 MP2MP LSP 到达其他节点, 但收到该流量的节点除外. 节点 Z 按第 3.3.1.2 节确定下游 MP2MP LSR, 并向节点 D 发送 MP2MP-U Label Mapping <X, Y, Lu'>. 由于 Z 是树的根, Z 不会发送 MP2MP-D Label Mapping, 也不会收到 MP2MP-U Label Mapping.

3.3.1.6.2 根节点不是叶节点 (Root Node is Not a Leaf)

假设根节点 Z 收到来自节点 D 的 MP2MP-D Label Mapping <X, Y, L>. Z 检查自己是否已有 downstream <X, Y> 的转发状态. 如果没有, Z 创建下游转发状态, 并在接口 I 上安装出标签 L. 接口 I 通过第 2.4.1.2 节的规程确定. 如果 Z 已有 downstream <X, Y> 的转发状态, 则 Z 会把 "接口 I 上的标签 L" 加入现有状态.

节点 Z 检查自己是否有 upstream <X, Y, D> 的转发状态. 如果没有, Z 分配标签 Lu', 并创建转发状态: 用 Lu' 与 downstream <X, Y> 转发状态中的标签交换相交换, 但针对节点 D 的交换除外. 这使得上游流量能够沿 MP2MP LSP 到达其他节点, 但收到该流量的节点除外. 根节点 Z 按第 3.3.1.2 节确定下游 MP2MP LSR D, 并向其发送 MP2MP-U Label Mapping <X, Y, Lu'>. 由于 Z 是树的根, Z 不会发送 MP2MP-D Label Mapping, 也不会收到 MP2MP-U Label Mapping.

3.3.2 MP2MP Label Withdraw (MP2MP 标签撤销)

本节列出参与 MP2MP LSP 的节点产生和处理 MP2MP Label Withdraw 消息的规程. LSR 应当根据自己的角色, 应用那些适用于自己的规程.

3.3.2.1 MP2MP 叶节点操作 (MP2MP Leaf Operation)

如果叶节点 Z 发现 (通过不在本文档范围之内的手段) 自己在该 LSP 中没有下游邻居, 并且不需要为该 LSP 充当出口 LSR (同样通过不在本文档范围之内的手段得知), 那么它应当向自己相对于 <X, Y> 的上游 LSR U 发送 MP2MP-D Label Withdraw <X, Y, L>, 其中 L 是它先前向 U 通告的, 用于 <X,Y> 的标签. 叶节点 Z 还会向 U 发送一条未经请求的标签释放 <X, Y, Lu>, 以表明上游路径不再使用, 标签 Lu 可以移除.

叶节点 Z 期望上游路由器 U 以针对 L 的下游标签释放作为响应.

3.3.2.2 MP2MP 中间节点操作 (MP2MP Transit Node Operation)

如果中间节点 Z 收到来自节点 D 的 MP2MP-D Label Withdraw 消息 <X, Y, L>, 它从自己的 downstream <X, Y> 转发状态以及自己全部的 <X, Y> 上游状态中删除标签 L. 节点 Z 向 D 发送携带标签 L 的 MP2MP-D Label Release 消息. 由于节点 D 已不再是下游转发状态的一部分, Z 清理 upstream <X, Y, D> 的转发状态. 无需向 D 发送 MP2MP-U Label Withdraw <X, Y, Lu>, 因为节点 D 已经移除了 Lu, 并向 Z 发送了针对 Lu 的标签释放.

如果从 Z 的 downstream <X, Y> 转发状态中删除标签 L 之后, <X, Y> 不再有任何状态, 那么 Z 把 MP2MP-D Label Withdraw <X, Y, L> 传播给自己相对于 <X, Y> 的上游节点 U, 并且还会向 U 发送一条未经请求的 MP2MP-U Label Release <X, Y, Lu>, 以表明上游路径不再使用, 标签 Lu 可以移除.

3.3.2.3 MP2MP 根节点操作 (MP2MP Root Node Operation)

当 MP2MP LSP 的根节点收到 MP2MP-D Label Withdraw 消息时, 规程与中间节点相同, 只是根节点不会向上游传播 Label Withdraw (因为它没有上游).

3.3.3 MP2MP 上游 LSR 变更 (MP2MP Upstream LSR Change)

变更上游 LSR 的规程与第 2.4.3 节所述相同, 只是将它应用于 MP2MP FEC, 并使用第 3.3.1 节至第 3.3.2.3 节描述的规程.

4. MP LSP 中的微环路 (Micro-Loops in MP LSPs)

单播路由协议在收敛期间产生的微环路也可能影响 mLDP MP LSP. 由于 mLDP 的建树逻辑基于单播路由, 单播路由环路也可能在 MP LSP 中导致微环路. 涉及 2 个直连路由器的微环路不会在 mLDP 中形成环路. mLDP 能够防止这种不一致: 它绝不允许把一个上游 LDP 邻居作为下游 LDP 邻居添加进同一 FEC 的标签转发表 (LFT). 涉及超过 2 个 LSR 的微环路则无法防止.

涉及超过 2 个 LSR 的微环路, 可能在 MP2MP 或 P2MP LSP 的下游路径以及 MP2MP LSP 的上游路径中形成微环路. 这些环路是瞬时的, 一旦单播路由协议收敛并且 mLDP 相应地更新了转发状态, 它们就会消失. MP2MP LSP 上游路径中出现的微环路, 可以通过在 MP2MP-U Label Mapping 消息中包含 LDP 路径向量 (path vector) 来检测. 这些规程目前仍在研究之中, 有待进一步研究.

5. LDP MP Status TLV (The LDP MP Status TLV)

支持 LDP MP 的路由器可以使用 LDP MP Status TLV 向其远端对端指示某个 MP LSP 的附加状态. 这包括向上游或下游的 LDP MP 支持对端发信号. LDP MP Status TLV 的值对 LDP 而言保持不透明, 其中可以编码一个或多个状态元素.

LDP MP Status TLV 编码如下:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0| LDP MP Status Type(0x096F)|            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Value                               |
      ~                                                               ~
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

LDP MP Status Type: LDP MP Status (0x096F).

Length: LDP MP Status Value 的长度, 以八位组计.

Value: 一个或多个 LDP MP Status Value 元素.

5.1 LDP MP Status Value 元素 (The LDP MP Status Value Element)

包含在 LDP MP Status TLV Value 中的 LDP MP Status Value 元素具有如下编码.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Type          | Length                        | Value ...     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
      ~                                                               ~
      |                                                               |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: LDP MP Status Value 元素的类型. IANA 维护状态值类型注册表 (见第 11 节).

Length: Value 字段的长度, 以八位组计.

Value: 长度为 Length 八位组的字符串, 按 Type 字段的规定解释.

5.2 包含 LDP MP Status 消息的 LDP 消息 (LDP Messages Containing LDP MP Status Messages)

LDP MP Status TLV 可以出现在 Label Mapping 消息或 LDP Notification 消息中.

5.2.1 在 LDP Notification 消息中发送 LDP MP Status (LDP MP Status Sent in LDP Notification Messages)

在 notification 消息中发送的 LDP MP Status TLV 必须伴随一个 Status TLV, 如 [RFC5036] 所述. 带有 LDP MP Status TLV 的 Notification 消息的一般格式是:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|   Notification (0x0001)     |      Message Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Message ID                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Status TLV                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   LDP MP Status TLV                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Optional LDP MP FEC TLV                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Optional Label TLV                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Status TLV 的状态码用于指示: LDP MP Status TLV 以及任何附加信息跟随在 Notification 消息的 "optional parameter" 部分之后. 根据 LDP MP Status TLV 的实际内容, 消息中还可以带有 LDP P2MP 或 MP2MP FEC TLV 和 Label TLV, 以便为 LDP MP Status TLV 提供上下文.

由于该 notification 不指向任何特定消息, Message ID 与 Message Type 字段被置为 0.

5.2.2 Label Mapping 消息中的 LDP MP Status TLV (LDP MP Status TLV in Label Mapping Message)

下面给出 [RFC5036] 定义的 Label Mapping 消息的一个示例, 以说明带有可选 LDP MP Status TLV 的消息.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|   Label Mapping (0x0400)    |      Message Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Message ID                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     FEC TLV                                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Label TLV                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Optional LDP MP Status TLV                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Additional Optional Parameters            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6. LAN 上的上游标签分配 (Upstream Label Allocation on a LAN)

在 LAN 上, 前文讨论的规程将要求上游 LSR 向每个接收方单独发送一份分组副本. 如果 LAN 上有多个接收方, 我们就没有充分利用网络的多路访问能力. 我们可以通过使用上游标签分配 [RFC5331] 来优化 LAN 上的带宽消耗和上游 LSR 的复制开销. 关于如何使用 LDP 分发上游标签的规程见 [RFC6389].

6.1 LAN 上的 LDP 多点对多点 (LDP Multipoint-to-Multipoint on a LAN)

在 LAN 上分配上下文标签 (context label) 的规程定义于 [RFC5331]. 该规程使得给定 LAN 上的每个 LSR 都拥有一个上下文标签, 在该 LAN 上, 它可以用来唯一地标识自己. 每个 LSR 按 [RFC6389] 的规程把它的上下文标签作为上游分配标签通告出去. 任何把该 LAN 作为某个 P2MP 或 MP2MP LSP 下游链路的 LSR, 都会分配一个标识该 LSP 的上游分配标签. 当该 LSR 沿这些 LSP 之一向下游转发分组时, 分组的顶层标签必须是该 LSR 的上下文标签, 分组的第二个标签是标识该 LSP 的标签. 我们把顶层标签称为 "上游 LSR 标签" (upstream LSR label), 把第二个标签称为 "LSP 标签" (LSP label).

6.1.1 MP2MP 下游转发 (MP2MP Downstream Forwarding)

MP2MP LSP 的下游路径与普通的 P2MP LSP 非常相似, 因此我们使用与 [RFC6389] 中定义相同的规程. 针对某个 LSP 标签的标签请求被发送给上游 LSR. 从上游 LSR 收到的 Label Mapping 包含该 MP2MP FEC 的 LSP 标签以及上游 LSR 的上下文标签. MP2MP 下游路径 (对应于 LSP 标签) 将被安装在对应于该上游 LSR 标签的上下文相关转发表中. 上游路由器发送的分组可以基于双标签查找, 使用这一转发状态向下游转发.

6.1.2 MP2MP 上游转发 (MP2MP Upstream Forwarding)

MP2MP LSP 还有上游转发路径. 上游分组需要向根的方向转发, 并且在 LAN 上任何拥有该 LSP 下游接口的节点上向下游转发. 对于给定 LAN 上的给定 MP2MP LSP, 恰好有一个 LSR 被视为上游 LSR. 如果 LAN 上的一个 LSR 从它针对该 LSP 的某个下游接口收到一个分组, 并且它需要把该分组转发到 LAN 上, 那么它确保: 分组的顶层标签是上游 LSR 的上下文标签, 分组的第二个标签是由上游 LSR 分配的 LSP 标签.

收到该分组的其他 LSR 无法判断分组是否真的来自上游路由器, 但这并不影响对分组的处理. 上游 LSR 将在标签中看到它自己的上游 LSR, 这使它能够判定该分组正在向上游行进.

7. 根节点冗余 (Root Node Redundancy)

无论 MP LSP 是 P2MP 还是 MP2MP, 根节点都是 MP LSP 的单点故障. 这个问题对 MP2MP LSP 尤其严重. 对于 MP2MP LSP, 所有叶节点必须使用同一个根节点来建立 MP2MP LSP, 否则某些叶发出的流量不会被其他叶收到. 由于根节点是 MP LSP 的单点故障, 我们需要一个快速高效的机制来从根节点故障中恢复.

MP LSP 在网络中由不透明值和根节点地址唯一标识. MP LSP 的根节点很可能是静态定义的. 根节点地址可以在每个叶上静态配置, 或者通过动态协议学习. 叶节点如何得知根节点不在本文档的范围之内.

假设对于同一个不透明值, 我们定义了两个 (或更多) 根节点地址, 并使用相同的不透明值建立通往每个根的树. 实际上, 它们在网络中将被视为不同的 MP LSP. 一旦这些树建立起来, P2MP 与 MP2MP LSP 的规程就有所不同. 不同的规程在下文各节中说明.

7.1 根节点冗余 -- P2MP LSP 的规程 (Root Node Redundancy - Procedures for P2MP LSPs)

由于所有叶都建立了通往所有根的 P2MP LSP, 它们已经准备好在其中任意一条 LSP 上接收分组. 然而, 在任一时刻只有一个根应当转发流量, 原因是: 1) 为了节省网络带宽; 2) 为了确保接收叶不会收到重复分组 (因为不能假定接收叶能够丢弃重复分组). 各根如何确定哪一个是活跃发送者, 不在本文档的范围之内.

7.2 根节点冗余 -- MP2MP LSP 的规程 (Root Node Redundancy - Procedures for MP2MP LSPs)

由于所有叶都为该不透明值建立了通往每个根节点的 MP2MP LSP, 发送叶可以选择两条 (或更多) MP2MP LSP 中的任意一条来转发分组. 叶节点在其中一条 MP2MP LSP 上收到分组. MP2MP LSP 的客户并不关心分组是在哪条 MP2MP LSP 上收到的, 只要它们对应相同的不透明值即可. 发送叶在给定时刻必须只在一条 MP2MP LSP 上转发分组. 接收叶无法丢弃重复分组, 因为它们在所有 LSP 上都接受分组. 利用全部可用的 MP2MP LSP, 我们可以用下述规程实现冗余.

发送叶从给定不透明值的可用根中选出单个根节点. 一个不错的策略是查看单播路由表, 选择按单播度量最近的一个根. 一旦活跃根的地址由于根节点或链路故障而从单播路由表中消失 (或变得不再优), 该叶就可以选出一个新的最佳根地址并直接开始向它转发. 如果多个根节点具有相同的单播度量, 可以选择最高的根节点地址, 也可以按会话在多个根节点上做负载均衡.

参与某条 MP2MP LSP 的所有叶必须为给定不透明值加入所有可用的根节点. 由于发送叶可能选择任何一条 MP2MP LSP, 每个叶都必须准备好在其中接收.

为单个不透明值预先建立多条 MP2MP LSP 的好处是: 从根节点故障中恢复的收敛速度与单播路由协议能够通知的一样快. 无需额外的协议向叶节点通告哪个根节点是活跃根. 根的选择是叶节点本地策略, 不需要与其他叶协调. 预先建立多条 MP2MP LSP 的缺点是会使用更多的标签资源, 具体取决于定义了多少个根节点.

8. 先建后断 (Make Before Break, MBB)

LSR 选择通往 LSP 根的下一跳 LSR 作为自己在该 MP LSP 上的上游 LSR. 当通往根的最佳路径发生变化时, LSR 必须选择一个新的上游 LSR. 第 2.4.3 节和第 3.3.3 节描述了这些规程.

当通往根的最佳路径变化时, LSP 可能被暂时破坏, 导致分组丢失, 直到该 LSP "重新收敛" 到一个新的上游 LSR. 这种情况下, MBB 的目标是把分组丢失的持续时间降到最短. 此外, 还存在这样的场景: 从 LSR 到根的最佳路径变了, 但 LSP 仍继续把分组转发到旧的下一跳. 这可能发生在链路恢复上线或路由度量变化时. 在这种情况下, 应当在移除旧 LSP 之前先建立新 LSP, 以限制分组丢失的持续时间. 下述规程同时处理这两种场景, 使得 LSR 无需知道究竟是上述哪种事件导致它针对某个 MBB LSP 的上游路由器发生了变化.

MBB 规程是对本文档所述 MP LSP 建立规程的可选扩展. 本节的规程提供先建后断 (make-before-break) 行为, 但新路径属于涉及超过 2 个 LSR 的瞬时路由环路的情形除外 (另见第 4 节).

8.1 MBB 概述 (MBB Overview)

MBB 规程使用额外的 LDP 信令.

假设某个事件导致下游 LSR-D 为 FEC-A 选择了一个新的上游 LSR-U. 新的 LSR-U 可能已经在为 FEC-A 转发分组; 也就是说, 为 LSR-D 之外的下游 LSR 转发分组. 在 LSR-U 从 LSR-D 收到 FEC-A 的标签之后, 当它得知从根到自身的 FEC-A LSP 已经建立时, 它会通知 LSR-D. 当 LSR-D 收到这个 MBB 通知时, 它会把该 LSP 根的下一跳改为 LSR-U.

这里假定: 如果 LSR-U 已经收到其上游路由器针对 FEC-A LSP 的 MBB 通知并且安装了转发状态, 那么该 LSR 就有能力在该 LSP 上转发分组. 此时, LSR-U 应当通过 MBB 通知向 LSR-D 发信号, 表明它已经成为 FEC-A 所标识的树的一部分, 并且 LSR-D 应当发起向该 LSP 的切换.

在 LSR-U 处, FEC-A 的 LSP 可能处于以下 3 种状态之一.

1. FEC-A 没有任何状态.

2. FEC-A 的状态存在, 并且 LSR-U 正在等待 MBB 通知, 以确认从根到它的 LSP 已经存在.

3. FEC-A 的状态存在, 并且已经收到 MBB 通知, 或者它就是 FEC-A 的根节点.

在 LSR-U 收到 LSR-D 针对 FEC-A 的 Label Mapping 消息之后, 直到它针对该 LSP 的状态变为上述状态 #3 之前, LSR-U 禁止向 LSR-D 回复 MBB 通知. 如果 LSR-U 处该 LSP 的状态是状态 #1 或 #2, LSR-U 应当记住已收到来自 LSR-D 的 Label Mapping 消息, 同时等待其上游 LSR 发来的针对该 LSP 的 MBB 通知. 当 LSR-U 收到 MBB 通知后, 它转变到 LSP 状态 #3, 并向 LSR-D 发送 MBB 通知.

8.2 MBB 状态码 (The MBB Status Code)

如第 8.1 节所述, 建立 MBB MP LSP 的规程不同于建立普通 MP LSP 的规程.

当下游 LSR 向其上游 LSR 发送针对 MP LSP 的 Label Mapping 消息时, 它可以包含一个携带 MBB 状态码的 LDP MP Status TLV, 以表明 MBB 规程适用于该 LSP. 这个新的 MBB 状态码也可以出现在 LDP Notification 消息中, 供上游 LSR 向下游 LSR 发信号, 表明 LSP 处于状态 #3; 也就是说, 上游 LSR 针对该 LSP 的状态存在, 并且它已经从其上游 LSR 收到通知, 表明该 LSP 处于状态 #3.

MBB Status 是第 5.1 节所述 LDP MP Status Value 元素的一种类型. 其编码如下:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | MBB Type = 1  |      Length = 1               | Status Code   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      MBB Type:  Type 1

      Length:  1

      Status Code:  1 = MBB 请求 (MBB request)

                    2 = MBB 确认 (MBB ack)

8.3 MBB 能力 (The MBB Capability)

LSR 可以使用 [RFC5561] 定义的能力通告来表明自己能够处理 MBB LSP. LDP MP MBB 能力具有如下格式:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0| LDP MP MBB Capability     |           Length = 1          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S| Reserved    |
      +-+-+-+-+-+-+-+-+

LDP MP MBB Capability: MBB 能力参数 (0x050A).

S: 按 [RFC5561] 的规定.

如果某个 LSR 没有通告自己支持 MBB, 其 LDP 对端禁止向它发送包含 MBB 参数的消息. 如果某个 LSR 从下游 LSR-D 收到带有 MBB 参数的 Label Mapping 消息, 而它的上游 LSR-U 尚未通告自己支持 MBB, 那么该 LSR 必须立即向 LSR-U 发送 MBB 通知 (见第 8.4 节). 如果发生这种情况, 将不会建立 MBB MP LSP, 而是得到一条普通 MP LSP.

8.4 MBB 规程 (The MBB Procedures)

8.4.1 术语 (Terminology)

1. MBB LSP <X, Y>: 根节点地址为 X, 不透明值为 Y 的 P2MP 或 MP2MP 先建后断 (MBB) LSP 条目.

2. A(N, L): 一个接受元素 (accepting element), 由上游邻居 N 和本地标签 L 组成. 本 LSR 为某个特定 MBB LSP 向邻居 N 分配了标签 L. 对于活跃元素, 相应的标签存储在标签转发数据库中.

3. iA(N, L): 一个非活跃接受元素, 由上游邻居 N 和本地标签 L 组成. 本 LSR 为某个特定 MBB LSP 向邻居 N 分配了标签 L. 对于非活跃元素, 相应的标签不存储在标签转发数据库中.

4. F(N, L): 一个转发状态, 由下游邻居 N 和标签 L 组成. 本 LSR 正在针对某个特定 FEC, 向邻居 N 发送带有标签 L 的标签分组.

5. F'(N, L): 一个被标记为需要向邻居 N 发送携带标签 L 的 MBB Notification 消息的转发状态.

6. MBB Notification <X, Y, L>: 一条 LDP notification 消息, 带有 MP LSP <X, Y>, 标签 L 和 MBB 状态码 2.

7. MBB Label Mapping <X, Y, L>: 一条 P2MP Label Mapping 或 MP2MP 下游 Label Mapping, 带有 FEC 元素 <X, Y>, 标签 L 和 MBB 状态码 1.

8.4.2 接受元素 (Accepting Elements)

接受元素表示已经向邻居 N 通告过的, 针对 MBB LSP <X, Y> 的某个特定标签值 L, 它是接受被交换标签分组的候选者. 一个 LSR 可以针对特定 MBB LSP <X, Y> 拥有两个接受元素, 但其中只有一个必须是活跃的. 活跃元素是其标签值已被安装进标签转发数据库的元素. 非活跃接受元素在选定新的上游 LSR 之后、其在标签转发数据库中替换活跃元素尚未完成时创建. 非活跃元素只在切换到新上游 LSR 期间临时存在. 一旦切换完成, 只剩下一个活跃元素. 在网络收敛期间, 可能出现一个非活跃接受元素正在等待时又创建了另一个非活跃接受元素的情况. 如果发生这种情况, 较旧的非活跃接受元素必须被较新的非活跃元素替换. 如果移除了某个接受元素, 则必须向邻居 N 发送针对 <X, Y> 的标签 L 的 Label Withdraw.

8.4.3 上游 LSR 变更的规程 (Procedures for Upstream LSR Change)

假设节点 Z 拥有一个带活跃接受元素 A(N1, L1) 的 MBB LSP <X, Y>. 由于路由变化, 它检测到通往根 X 的新最佳路径, 并选择了新的上游 LSR N2. 节点 Z 分配新的本地标签 L2, 并创建非活跃接受元素 iA(N2, L2). 节点 Z 向 N2 发送 MBB Label Mapping <X, Y, L2>, 并等待新的上游 LSR N2 以针对 <X, Y, L2> 的 MBB Notification 作为响应. 在这一过渡阶段, 存在两个接受元素: 仍在经标签 L1 从 N1 接受分组的元素 A(N1, L1), 以及新的非活跃元素 iA(N2, L2).

在等待来自上游 LSR N2 的 MBB Notification 期间, 可能由于路由变化而发生另一次切换. 假设新的上游 LSR 是 N3. 此时创建非活跃元素 iA(N3, L3), 而旧的非活跃元素 iA(N2, L2) 必须被移除. 必须向 N2 发送针对 <X, Y, L2> 的 Label Withdraw. 来自 N2 的针对 <X, Y, L2> 的 MBB Notification 将被忽略, 因为该非活跃元素已被移除.

由于链路或节点故障, 可能永远收不到来自上游 LSR 的 MBB Notification. 为防止无限期等待 MBB Notification, 应当施加一个超时. 定时器一到期, 就按第 8.4.5 节的规程处理, 就像为该非活跃元素收到了 MBB Notification 一样. 如果下游 LSR 在等待来自新上游 LSR 的 MBB Notification 期间检测到旧上游 LSR 已宕机, 那么下游 LSR 可以立即继续, 无需等待定时器到期.

8.4.4 接收携带 MBB 状态码的 Label Mapping (Receiving a Label Mapping with MBB Status Code)

假设节点 Z 拥有某个 MBB LSP <X, Y> 的状态, 并从 N2 收到 MBB Label Mapping <X, Y, L2>. 如果尚不存在, 将向该 MP LSP 添加新的转发状态 F(N2, L2). 如果该 MBB LSP 拥有活跃接受元素, 或者节点 Z 是该 MBB LSP 的根, 则向节点 N2 发送 MBB 通知 <X, Y, L2>. 如果节点 Z 拥有非活跃接受元素, 它把转发状态标记为 <X, Y, F'(N2, L2)>. 如果路由器 Z 针对 <X, Y> 的上游 LSR 恰好是 N2, 那么 Z 禁止立即向 N2 发送 MBB 通知. 只有当 Z 针对 <X, Y> 的上游不再是 N2 之后, 才能向 N2 发送 MBB 通知.

8.4.5 接收携带 MBB 状态码的 Notification (Receiving a Notification with MBB Status Code)

假设节点 Z 从 N 收到 MBB Notification <X, Y, L>. 如果节点 Z 拥有 MBB LSP <X, Y> 的状态, 并且拥有与 N 和 L 相匹配的非活跃接受元素 iA(N, L), 我们激活这个接受元素, 并把标签 L 安装进标签转发数据库. 如果存在另一个活跃接受元素, 它将从标签转发数据库中移除.

如果该 MBB LSP <X, Y> 还存在被标记为需要发送 MBB Notification 的转发状态, 例如 <X, Y, F'(N2, L2)>, 则向这些下游 LSR 发送 MBB Notification. 如果节点 Z 收到的 MBB Notification 所对应的接受元素不是非活跃的, 或者与标签值和邻居地址不匹配, 则该 MBB 通知被忽略.

8.4.6 MP2MP LSP 的节点操作 (Node Operation for MP2MP LSPs)

上述规程适用于 MP2MP LSP 的下游路径. MP2MP 的上游路径按正常方式建立, 不包含 MBB 状态码. 如果 MBB 规程适用于某个 MP2MP 下游 FEC 元素, 那么通往节点 N 的上游路径只有在节点 N 属于活跃接受元素时才被安装进标签转发数据库. 如果节点 N 属于某个非活跃接受元素, 则上游路径在该非活跃接受元素被激活时安装.

9. mLDP FEC Element 的 Typed Wildcard (Typed Wildcard for mLDP FEC Element)

mLDP FEC Typed Wildcard FEC 的格式如下:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Typed Wcard   |     Type      |   Len = 2     |      AFI      ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~               |
      +-+-+-+-+-+-+-+-+

Typed Wcard: 按 [RFC5918] 的规定.

Type: FEC Element 类型. 为 P2MP FEC Element 或 MP2MP FEC Element, 取本文档定义的这些 FEC Element 在 FEC TLV 中携带时所用的值.

Len: FEC Type Info 的长度, 两字节 (=0x02).

AFI: 地址族, 两字节量, 包含 IANA "Address Family Numbers" 注册表中的一个值.

10. 安全考虑 (Security Considerations)

适用与基础 LDP 规范相同的安全考虑, 如 [RFC5036] 所述.

本文档规定的协议没有提供任何授权机制来控制可能加入给定 MP LSP 的 LSR 集合. 如果需要这样的授权, 则需要本文档范围之外的额外机制. 注意, 授权策略无法只在 LSP 的根节点上实施和/或配置, 因为根节点并不知道所有叶节点的身份.

11. IANA 考虑 (IANA Considerations)

根据本文档, IANA 创建了 3 个新注册表.

1. "LDP MP Opaque Value Element basic type"

   取值范围为 0-255, 本文档分配了以下值:

   • 0: 保留

   • 1: 通用 LSP 标识符 (Generic LSP identifier)

   • 255: 后续两个字节中存在 Extended Type 字段

   该空间的分配策略是 "标准行动与提前分配" (Standards Action with Early Allocation).

2. "LDP MP Opaque Value Element extended type"

   取值范围为 0-65535, 分配策略如下:

   • 0-32767: 标准行动与提前分配

   • 32768-65535: 先到先得 (First Come, First Served)

3. "LDP MP Status Value Element type"

   取值范围为 0-255, 本文档分配了以下值:

   • 0: 保留

   • 1: MBB Status

   该空间的分配策略是 "标准行动与提前分配".

下文列出的代码点由 IANA 通过提前分配 (early allocation) 分配.

IANA 从 LDP 注册表 "Forwarding Equivalence Class (FEC) Type Name Space" 中分配了三个新代码点. 取值为:

• P2MP FEC 类型 -- 请求值 0x06

• MP2MP-up FEC 类型 -- 请求值 0x07

• MP2MP-down FEC 类型 -- 请求值 0x08

IANA 从 LDP 注册表 "TLV Type Name Space" 中为新的能力参数 TLV 分配了三个新代码点, 分别对应 P2MP, MP2MP 和 MBB 能力的通告. 取值为:

• P2MP 能力参数 -- 0x0508

• MP2MP 能力参数 -- 0x0509

• MBB 能力参数 -- 0x050A

IANA 分配了一个 LDP 状态码, 用于指示 Notification 消息中跟随有 LDP MP Status TLV. 在 LDP 注册表 "LDP Status Code Name Space" 中分配的值为:

• LDP MP status -- 请求值 0x00000040

IANA 为 LDP MP Status TLV 分配了一个新代码点. 在 LDP 注册表 "LDP TLV Type Name Space" 中分配的值为:

• LDP MP Status TLV 类型 -- 请求值 0x096F

12. 致谢 (Acknowledgments)

作者感谢以下各位的评审与贡献: Nischal Sheth, Yakov Rekhter, Rahul Aggarwal, Arjen Boers, Eric Rosen, Nidhi Bhaskar, Toerless Eckert, George Swallow, Jin Lizhong, Vanson Lim, Adrian Farrel, Thomas Morin 和 Ben Niven-Jenkins.

13. 贡献作者 (Contributing Authors)

以下是贡献作者名单, 按字母顺序排列:

Shane Amante Level 3 Communications, LLC 1025 Eldorado Blvd Broomfield, CO 80021 US EMail: [email protected]

Luyuan Fang Cisco Systems 300 Beaver Brook Road Boxborough, MA 01719 US EMail: [email protected]

Hitoshi Fukuda NTT Communications Corporation 1-1-6, Uchisaiwai-cho, Chiyoda-ku Tokyo 100-8019, Japan EMail: [email protected]

Yuji Kamite NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo 163-1421, Japan EMail: [email protected]

Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US EMail: [email protected]

Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin Lannion, Cedex 22307 France EMail: [email protected]

Ina Minei Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US EMail: [email protected]

Bob Thomas Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA, 01719 EMail: [email protected]

Lei Wang Telenor Snaroyveien 30 Fornebu 1331 Norway EMail: [email protected]

IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a 1831 Diegem Belgium EMail: [email protected]

14. 参考文献 (References)

14.1 规范性引用 (Normative References)

• [ITU.V42.1994] International Telecommunications Union, "Error-correcting Procedures for DCEs Using Asynchronous-to-Synchronous Conversion", ITU-T Recommendation V.42, 1994. http://www.itu.int/rec/T-REC-V.42-200203-I

• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

• [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.

• [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.

• [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.

• [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009.

• [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)", RFC 5918, August 2010.

• [RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label Assignment for LDP", RFC 6389, September 2011.

14.2 资料性引用 (Informative References)

• [ISO3309] International Organization for Standardization, "ISO Information Processing Systems - Data Communication - High-Level Data Link Control Procedure - Frame Structure", ISO 3309, 3rd Edition, October 1984.

• [L3VPN-MCAST] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", Work in Progress, January 2010.

• [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004.

• [RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 2004.

• [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.

• [RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008.

• [RFC6348] Le Roux, J., Ed., and T. Morin, Ed., "Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol", RFC 6348, September 2011.

作者地址 (Authors' Addresses)

IJsbrand Wijnands (editor) Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium EMail: [email protected]

Ina Minei (editor) Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US EMail: [email protected]

Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US EMail: [email protected]

Bob Thomas 300 Beaver Brook Road Boxborough 01719 US EMail: [email protected]