跳到主要内容

RFC 9026 - 组播 VPN 快速上游故障切换 (Multicast VPN Fast Upstream Failover)

  • 状态: Proposed Standard
  • 发布日期: April 2021
  • Stream: IETF
  • 勘误: 无勘误

摘要 (Abstract)​

本文档定义组播虚拟专用网 (Multicast Virtual Private Network, VPN) 扩展与规程, 通过允许下游提供商边缘 (Provider Edge, PE) 在为 VPN 组播流选择上游 PE 时考虑提供商隧道 (Provider-Tunnel, P-tunnel) 的状态, 从而实现上游故障的快速切换. 快速切换通过使用 "多点网络的双向转发检测 (Bidirectional Forwarding Detection, BFD)" (RFC 8562) 以及新的 BGP 属性 BFD Discriminator 启用. 此外, 本文档引入新的 BGP Community Standby PE, 扩展 BGP 组播 VPN (MVPN) 路由, 使 C-multicast 路由可朝向备用上游 PE 通告.

本备忘录状态 (Status of This Memo)​

这是一份 Internet Standards Track 文档.

本文档是互联网工程任务组 (Internet Engineering Task Force, IETF) 的产物. 它代表 IETF 社区的共识. 它已接受公开审阅, 并已获互联网工程指导组 (Internet Engineering Steering Group, IESG) 批准发布. 有关 Internet Standards 的更多信息, 见 RFC 7841 第 2 节.

有关本文档当前状态、任何勘误以及如何提供反馈的信息, 见 https://www.rfc-editor.org/info/rfc9026.

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

本文档受 BCP 78 以及 IETF Trust 关于 IETF 文档的法律条款 (https://trustee.ietf.org/license-info) 约束 (以本文档发布之日有效者为准). 请仔细审阅这些文件. 从本文档提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节所述的 Simplified BSD License 文本, 并按该许可证所述不提供保证.

目录 (Table of Contents)​

    1. 引言 (Introduction)
    1. 本文档中使用的约定 (Conventions Used in This Document)
    1. 基于隧道状态的 UMH 选择 (UMH Selection Based on Tunnel Status)
    1. 备用 C-Multicast 路由 (Standby C-Multicast Route)
    1. 热根备用 (Hot Root Standby)
    1. 重复分组 (Duplicate Packets)
    1. IANA 考虑 (IANA Considerations)
    1. 安全考虑 (Security Considerations)
    1. 参考文献 (References)
  • 致谢 (Acknowledgments)
  • 贡献者 (Contributors)
  • 作者地址 (Authors' Addresses)

1. 引言 (Introduction)​

假定读者熟悉 [RFC6513] 与 [RFC6514] 中所述的组播 MPLS/BGP IP VPN 工作方式.

在 BGP/MPLS VPN 中的组播 [RFC6513] 场景下, 希望提供机制以允许在不同类型故障时快速恢复连通性. 本文档针对提供商网络中位于连接到带接收方的 VPN 站点的 PE 上游的元素故障.

第 3 节描述本地规程, 允许出口 PE (连接到接收方站点的 PE) 在确定给定 (C-S,C-G) 的上游组播跳 (Upstream Multicast Hop, UMH) 时考虑 P-tunnel 的状态. 可选方法之一使用 [RFC8562] 与新的 BGP 属性 BFD Discriminator. 这些方法单独使用时均不构成完整的 "快速切换" 方案, 但可与第 4 节所述机制一起用于 "快速切换" 方案.

第 4 节描述可选 BGP 扩展——新的 Standby PE Community, 可通过在恢复时无需任何 Multicast VPN (MVPN) 路由消息交换来加速故障切换.

第 5 节描述可用于改善 MVPN 故障切换时间的 "hot root standby" 机制. 该方法结合第 3 与第 4 节定义的机制, 并与 [RFC7431] 中在给定拓扑与度量约束下使用 PIM 路由时改善故障切换时间的方案有相似之处.

2. 本文档中使用的约定 (Conventions Used in This Document)​

2.1. 需求语言 (Requirements Language)​

关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" 和 "OPTIONAL" 的解释见 BCP 14 [RFC2119] [RFC8174], 且仅当它们全部大写出现时适用.

2.2. 术语 (Terminology)​

本文档使用的术语为 [RFC6513] 与 [RFC6514] 中定义的术语.

2.3. 缩写 (Abbreviations)​

本文档使用以下缩写:

  • BFD: Bidirectional Forwarding Detection
  • MVPN: Multicast Virtual Private Network
  • NLRI: Network Layer Reachability Information
  • PE: Provider Edge
  • PMSI: Provider Multicast Service Interface
  • RPT: Rendezvous Point Tree
  • SPT: Shortest Path Tree
  • UMH: Upstream Multicast Hop
  • VPN: Virtual Private Network
  • VRF: VPN Routing and Forwarding

3. 基于隧道状态的 UMH 选择 (UMH Selection Based on Tunnel Status)​

RFC 6513 第 5.1 节描述 MVPN 下游 PE 确定给定 (C-S,C-G) 的 Upstream Multicast Hop (UMH) 所使用的规程.

对给定下游 PE 与给定 VRF, 给定上游 PE 对应给定 (C-S,C-G) 状态的 P-tunnel 是: 该上游 PE 为该 (C-S,C-G) 通告并导入该 VRF 的 S-PMSI 隧道; 若不存在此类 S-PMSI, 则为该 PE 通告并导入该 VRF 的 I-PMSI 隧道.

此处描述的规程是可选的, 基于下游 PE 在将每个给定 PE 纳入或不纳入给定 (C-S,C-G) 状态的候选 UMH 列表时, 考虑以每个可能上游 PE 为根的 P-tunnel 状态. 若无法确定 P-tunnel 的当前状态是否为 Up, 则该状态应视为 "未知为 Down", 并可按 Up 处理, 以便尝试使用该隧道是可接受的. 结果是: 若 P-tunnel 为 Down (见第 3.1 节), 则作为该 P-tunnel 根的 PE 将不被考虑用于 UMH 选择. 这将导致下游 PE 故障切换到候选列表中的下一个上游 PE. 某些下游 PE 可能因故障仅影响部分分支而对隧道状态得出不同结论. 因此, 在使用 I-PMSI P-tunnel 时适用 RFC 6513 第 9.1.1 节的规程. 该文档是本文档的基础, 其过程均适用于此.

RFC 6513 第 5.1 节为下游 PE 选择上游 PE 规定了三种选项.

前两种选项基于 IP 地址或哈希算法从候选 PE 集合中选择上游 PE. 当与本文档中考虑 P-tunnel 状态的可选规程一起使用时, 候选上游 PE 在以下情况之一被纳入集合:

  • 通告绑定到隧道的 x-PMSI, 且指定隧道状态未知为 Down; 或
  • 未通告适用于给定 (C-S,C-G) 的任何 x-PMSI, 但已将 VRF Route Import BGP Extended Community 关联到 S 的单播 VPN 路由. 这是为了避免错误地使在给定 VRF 不使用 I-PMSI 且仅使用 S-PMSI 的策略下的 UMH PE 失效. S-PMSI 可仅在上游 PE 收到要通过所通告 S-PMSI 承载的 (C-S,C-G)/(C-*,C-G) 的 C-multicast 路由之后才通告.

若结果候选集合为空, 则在不考虑 P-tunnel 状态的情况下重复该规程.

第三种选项使用已安装的 UMH Route (即朝向 C-root 的 "最佳" 路由) 作为 Selected UMH Route, 其始发 PE 为所选上游 PE. 在采用本文档考虑 P-tunnel 状态的可选规程时, Selected UMH Route 是那些始发 PE 的 P-tunnel 不为 "down" 之中的最佳路由. 若不存在, 则无论 P-tunnel 状态如何都选择已安装的 UMH Route.

3.1. 确定隧道状态 (Determining the Status of a Tunnel)​

可考虑不同因素来确定 P-tunnel 的 "状态", 并在以下小节描述. 本节描述的可选规程还处理下游 PE 并非都应用相同规则来定义 P-tunnel 状态的情况 (见第 6 节), 其中一些会产生对下游 PE 可能不同的结果. 因此, 本节中 P-tunnel 的 "状态" 不是隧道本身的特征, 而是特定下游 PE 所见的隧道状态. 此外, 以下某些方法确定的是下游 PE 在 P-tunnel 上接收流量的能力, 而非 P-tunnel 本身的状态. 这可称为 "P-tunnel reception status", 但为简单起见, 对所有这些方法我们都使用 P-tunnel "status" 术语.

取决于用于确定 P-tunnel 状态的标准, 可能与用于 P-tunnel 本身的另一弹性机制存在交互, UMH 更新可能立即发生, 也可能需要延迟. 每种具体情况在以下各小节覆盖.

实现可支持本节所述方法的任意组合, 并为网络运营商提供控制以选择在特定部署中使用哪一种.

3.1.1. MVPN 隧道根跟踪 (MVPN Tunnel Root Tracking)​

在确定 P-tunnel 状态是否为 Up 时, 要考虑的条件是: x-PMSI Tunnel 属性中指定的隧道根是否可通过单播路由表到达. 在此情况下, 下游 PE 可在可达性条件变化时立即更新其 UMH.

这类似于 VPN 路由的 BGP next-hop tracking, 只是所考虑的地址不是 BGP next-hop 地址, 而是 x-PMSI Tunnel 属性中的根地址.

3.1.2. 到 PE-CE 链路的跟踪​

在某些部署中, 可跟踪到 CE 的 PE-CE 链路状态, 以确定上游 PE 是否仍能转发给定组播流.

3.1.3. 通过 BFD 监测 P-tunnel​

可使用 BFD 监测 P-tunnel 的健康. 本文档定义的 BFD Discriminator 属性可将 BFD 会话与 P-tunnel 关联.

3.1.4. 叶发起的 P-tunnel​

对叶发起的 P-tunnel, 状态可由用于建立隧道的信令协议状态确定.

3.1.5. (C-S,C-G) 计数器信息​

P-tunnel 状态也可从特定 (C-S,C-G) 的流量统计推断. 若流量速率降至某阈值以下, 可将 P-tunnel 状态视为 Down.

3.1.6. BFD Discriminator 属性​

本文档定义新的 BGP 属性 BFD Discriminator, 可用于将 BFD 会话与 P-tunnel 关联. BFD 会话的状态确定 P-tunnel 的状态.

3.1.7. 每 PE-CE 链路的 BFD Discriminator​

在某些情况下, 将 BFD discriminator 与特定 PE-CE 链路关联可能有用. 这允许下游 PE 使用 BFD 监测到 CE 的链路状态.

3.1.8. 监测 P-tunnel 状态的运维考虑​

在监测 P-tunnel 状态时, 必须注意避免误报, 并确保监测机制不引入过多开销.

4. 备用 C-Multicast 路由 (Standby C-Multicast Route)​

本节描述可选 BGP 扩展——新的 Standby PE Community, 可通过在恢复时无需任何 MVPN 路由消息交换来加速故障切换.

4.1. 下游 PE 行为​

支持 Standby PE Community 的下游 PE 可向备用上游 PE 通告 C-multicast 路由. 这允许备用上游 PE 预编程转发 (C-S,C-G) 流量所需的状态.

4.2. 上游 PE 行为​

收到带有 Standby PE Community 的 C-multicast 路由的上游 PE MUST 安装 (C-S,C-G) 的状态, 但 MUST NOT 在被选为 UMH 之前转发流量.

4.3. 可达性判定​

下游 PE 使用第 3 节所述机制确定上游 PE 与备用上游 PE 的可达性.

4.4. Inter-AS​

本节描述 Inter-AS 场景下的规程.

4.4.1. 下游 PE 的 Inter-AS 规程, ASBR 快速切换​

在 Inter-AS 场景中, 下游 PE 可使用 Standby PE Community 向 ASBR 通告 C-multicast 路由.

4.4.2. ASBR 的 Inter-AS 规程​

ASBR 可使用 Standby PE Community 向其他 ASBR 或上游 PE 通告 C-multicast 路由.

5. 热根备用 (Hot Root Standby)​

本节描述可用于改善 MVPN 故障切换时间的 "hot root standby" 机制. 该方法结合第 3 与第 4 节定义的机制, 并与 [RFC7431] 中在给定拓扑与度量约束下使用 PIM 路由时改善故障切换时间的方案有相似之处.

6. 重复分组 (Duplicate Packets)​

在使用本文档所述快速切换机制时, 可能向接收方投递重复分组. 本节讨论重复分组的影响以及如何缓解.

7. IANA 考虑 (IANA Considerations)​

7.1. Standby PE Community​

IANA 已为 Standby PE Community 分配 BGP Community 值.

7.2. BFD Discriminator​

IANA 已为 BFD Discriminator 属性分配 BGP Attribute 类型码.

7.3. BFD Discriminator Optional TLV Type​

IANA 已在 BGP Tunnel Encapsulation Attribute 中为 BFD Discriminator Optional TLV 分配 Type 值.

8. 安全考虑 (Security Considerations)​

本文档的安全考虑与 [RFC6513] 与 [RFC6514] 类似. 此外, 使用 BFD 引入与 BFD 分组认证与完整性相关的新安全考虑.

9. 参考文献 (References)​

9.1. 规范性引用 (Normative References)​

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.

[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, https://www.rfc-editor.org/info/rfc6513.

[RFC6514] Aggarwal, R., Ed., Rosen, E., Ed., Morin, T., Ed., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, https://www.rfc-editor.org/info/rfc6514.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.

[RFC8562] Katz, D., Ward, D., and S. Pallagatti, Ed., "Bidirectional Forwarding Detection (BFD) for Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, April 2019, https://www.rfc-editor.org/info/rfc8562.

9.2. 资料性引用 (Informative References)​

[RFC7431] Karan, A., Wijnands, IJ., Ed., and E. Rosen, "Multicast-Only Fast Reroute", RFC 7431, DOI 10.17487/RFC7431, August 2015, https://www.rfc-editor.org/info/rfc7431.

[RFC7841] Halpern, J., Ed., Resnick, P., Ed., and O. Kolkman, Ed., "RFC Streams, Headers, and Boilerplates", RFC 7841, DOI 10.17487/RFC7841, May 2016, https://www.rfc-editor.org/info/rfc7841.

致谢 (Acknowledgments)​

作者谨致谢意...

贡献者 (Contributors)​

...

作者地址 (Authors' Addresses)​

Thomas Morin (editor) Orange Email: [email protected]

Robert Kebler (editor) Juniper Networks Email: [email protected]

Greg Mirsky (editor) ZTE Corp. Email: [email protected]

最后于 更新